SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

直近開催のイベントはこちら!

EnterpriseZine編集部ではイベントを随時開催しております

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

規子と哲樹の、おしえて!ミッションクリティカル

パラレルサーバをテーテーしていただきたく。

 前回は「ミッションクリティカルとは一体そもそも何か?」「ミッションクリティカルシステムのデータベースに求められる要件とは?」といったことについて、日立 ITプラットフォーム事業本部 開発統括本部 長江規子さんからTT(テーテー)(※1)を受けた。今回はその続編として、ミッションクリティカルなシステムにふさわしいデータベースのアーキテクチャーとは一体どのようなものなのか、前回と同じく長江さんから徹底的にテーテーしてもらった。テーテー、テーテー……。

 ※1 「Technology Transfer」の略。日本語に訳すと「技術継承」。先輩から後輩、上司から部下に対して、技術を引き継ぐための取り組み全般のことを指す。なお、TTは「ティーティー」ではなく「テーテー」と読むのが日立流。

ミッションクリティカル向けデータベースの肝「パラレルサーバ」

吉村 お世話になっております、吉村です。

長江 ……。

吉村 お世話になっております。

長江 ……。

吉村 (…ハッ!)毎々お世話になっておりますっ!

長江 毎々お世話になっております。

吉村 「毎々」は重要なんですね。

長江 ええ。さて、今回のテーマは「パラレルサーバ」です。

吉村 え? パラなにサーバ…? は、拝承…!

長江 前回は、ミッションクリティカルなシステムで使われるデータベースに求められる要件について説明しましたよね。内容、覚えてますか?

吉村 ええ、もちろん!高負荷トランザクション、大容量、高可用性といったあたりですよね。まあ、ざっくりとは理解できたんですけど、まだ何だか話がぼんやりしてて、イメージがつかめてないんですよね。

長江 なるほど。では今回から何回かに分けて、日立が開発・提供しているミッションクリティカル向けデータベース製品「HiRDB」を例にとりながら、もうちょっと詳しくそのあたりについて説明してきたいと思います。

このうち、今回は、高負荷トランザクションや、大量データを扱う大規模システムで、処理をさばくにはどんなことを考える必要があるか、お話ししたいと思います。

サーバマシンやストレージなど、ハードウェアの性能の進歩は目覚ましいですが、単位時間あたりに処理するトランザクションの数が非常に多かったり、扱うデータ量が多いなど、「大規模」なシステムになってくると、1台のサーバマシンで処理をさばききれないケースがあります。そのような場合は、サーバマシンの台数を増強して「並列処理」をしてチャチャッと片付けちゃおうというわけです。

HiRDBは、インストール時に「パラレルサーバ」として動作するのか、あるいは「シングルサーバ」として動作するのか、選べるようになってるんです。そこで、「パラレルサーバ」を選択することで、並列処理ができるようになります。

吉村 そのパラレルサーバというやつについて、もう少し詳しくご教示いただきたく。まず、パラレルサーバって簡単に言うと何ですか?

長江 簡単にいえば、データベース処理を複数のサーバマシン間で並列実行するための仕組みです。前回、大量処理について説明したときに、「うどん100万杯分」というたとえを使いましたよね。今度は、この100万杯のうどんを、どうやったら早く茹でられるか考えてみてください。

吉村 インドでは毎日10万人のカレーを提供している寺院があるそうですけど、100万杯のうどんですか…インドの寺院はさておき、常識的に考えて、一人が一日当たり100杯茹でられるとすると、軽く一万年はかかりますね。一万年後かあ……そのとき人類はまだ、うどんを食べているのでしょうか? ひょっとしたら、うどんが人類を食べている時代が到来しているかもしれません。

長江 ……じゃあ、一日当たり300杯のうどんを出すお店で考えてみてください。一人100杯では追いつかないですよね? そこで、複数の調理人が同時並行でうどんを茹でていく必要があるわけです。3人が常に同時並行で茹でれば、一日300杯のスピードで茹でることが可能になりますよね? パラレルサーバというのもこれと同じ原理で、複数のデータベース処理を同時並行で実行できるアーキテクチャのことを指すんです。

吉村 なるほど。

長江 もう少し詳しいことを言うと、3人の調理人が同時に茹でるにしても、3人で1つの大きな釜を共用する場合と、それぞれが自分専用の釜を使って茹でる場合とでは、作業効率も多少違ってきますよね。1つの大きな釜を複数人で共用する場合、2、3人までなら特に作業効率が落ちることはないでしょうけど、5、6人で使いまわすとなると順番待ちが発生したり、作業の段取りが難しくなってきたりして、作業効率が低下する恐れがあります。うどんで言うと、作業効率が低下して窯のお湯が冷めてしまったら困りますよね。

吉村 アツアツのうどんが食べたくなってきました。

長江 データベースも同じで、複数のサーバマシンで1つのデータベースを共有する「Shared Everything」というアーキテクチャと、データベースを複数に分割して、それぞれを独立して管理・制御する「Shared Nothing」というアーキテクチャが存在するんです。でHiRDBのパラレルサーバは、後者のShared Nothing方式を採っているんです。データベースやサーバマシンの数を増やしていけば、それに比例してデータベースシステム全体の処理性能もリニアに増強していけるので、大容量・高負荷トランザクションのミッションクリティカルシステムにはこちらの方がふさわしいと判断したのです。

データベース処理とSQL処理をそれぞれ独立してスケールできるHiRDB

吉村 なんだかだんだん難しい話になってきましたけど、要は複数人で仕事を手分けしましょうってことですよね? でもこれ、考えてみたら当たり前のことのような気も。大体Shared Nothingだって、何もHiRDBの専売特許というわけじゃなくて、ほかのデータベース製品でも採用されてるアーキテクチャですよね?

長江 まあ、そうですね。ただHiRDBのパラレルサーバには、他製品にはないユニークな特徴も幾つかあるんですよ。

吉村 ふーん……ではその辺り、詳しくお聞かせいただきたく。うどんでいうと、どんな特徴ですか?

長江 うどんでいうと…。うどん店でお客さんにうどんを出すには、厨房だけでは機能が足りませんよね? ホールで注文を取ったり、配膳したりする店員さんの存在も必要です。この店員さんの数が足りなかったら、どうなると思いますか?

吉村 「一人で二人分働け!」と上から強制された挙句、店員は皆疲弊して次々とダウン、そうした現状がtwitterやFacebookで晒されて世間からブラック企業として散々非難を浴びた挙句、経営陣が謝罪会見を開かざるを得ない事態に追い込まれると思います。

長江 その通り!

吉村 え、正解ですか。

長江 つまり、厨房の人員を増やして調理を同時並行でこなせるようになっても、ホールの店員さんの数が足りなければお客さんからの注文をさばききれないので、結局のところ売上は伸びないということです。データベースでいえば、この「ホールの店員さん」に当たるのが、アプリケーションからのSQL要求を受け付けるサーバということになります。

吉村 「ホールの店員さん」サーバは、「厨房の調理人」サーバとは別に存在するというわけですね?

長江 そう、役割を分担しているんです。先ほど、HiRDDBはデータベースを複数に分割して、それぞれを独立して管理するShared Nothingアーキテクチャを採用していると言いましたが、それぞれのデータベースを管理するサーバのことを「BES(Back End Server:バックエンドサーバ)」と呼びます。一方、アプリケーションからのSQLを受け付けて処理するサーバのことを「FES(Front End Server:フロントエンドサーバ)」といいます。ここで言う「サーバ」とは、データベース内で特定の仕事をするプログラムのことを指していると理解してください

吉村 BESが厨房の調理人、FESがホールの店員ということですね。

長江 そういうことです。FESが注文を受けて、BESが注文されたうどんを作り、FESがうどんをお客さんに出す、です。大規模なシステムのデータベースでデータを処理する際に発生するボトルネックには、大きく分けて「データベース処理の遅延」と「SQL処理の遅延」の2種類があります。で、データベース処理がボトルネックになっている場合には、BESを増設してやればいい。一方、SQL処理がボトルネックになっている場合には、FESを増設してやればSQL受付を同時並行でこなせるようになり、ボトルネックが解消できるというわけです。

吉村 ああ、なるほど。重いバッチ処理なんかは、SQL処理は大したことないけど、たくさんのデータにアクセスするので、データベース処理がえらく重くなってボトルネックになりますもんね。一方、SQLがたくさん細切れで飛んでくるオンライン処理では、SQL処理がボトルネックになることもあるということですね。

長江 そうなんです。その点、HiRDBはBESとFESの構成をうまく設計することで、どんな特徴を持ったシステムでもデータベースパフォーマンスを最適化できるというわけです。しかも、FESはアプリケーションサーバと同じサーバマシン上で動かすことができるので、一般的に問題になりがちな「アプリケーションサーバとデータベースサーバ間の通信ボトルネック」も解消できるんです。アプリケーションとFESの間のデータのやりとりを、サーバマシンのメモリを介して超高速に行うこともできるんですよ。

吉村 ああ、それは何となく便利そうですね! つまり、店員さんが常に自宅でじっと待機してて、いつでもその場でうどんの注文を受け付けてくれるということですよね?

長江 一年中家の中に店員さんにいられても、それはそれで怖いですが……まあ、概ね間違いではないです。

吉村 パラレルサーバ、何となく分かってきましたよ。でも今回の話だけだと、何だか絵に書いた餅のようで、いまいち真実味に欠けるというか……。

長江 疑い深いですねえ。じゃあ次回からは、データベース内部の具体的な仕組みを少しずつ紹介していきますから、頑張って付いてきていただきたく。

吉村 拝承!

パラレルサーバについて、長江さんからのテーテーを受ける吉村

パラレルサーバについて、長江さんからテーテーを受ける吉村

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
規子と哲樹の、おしえて!ミッションクリティカル連載記事一覧

もっと読む

この記事の著者

吉村 哲樹(ヨシムラ テツキ)

早稲田大学政治経済学部卒業後、メーカー系システムインテグレーターにてソフトウェア開発に従事。その後、外資系ソフトウェアベンダーでコンサルタント、IT系Webメディアで編集者を務めた後、現在はフリーライターとして活動中。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/6311 2014/11/14 00:00

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング