Comments
Description
Transcript
Web検索を支える大規模分散システムの 安定運用とその課題
Web検索 検索サービス 大規模分散システム 安定運用 特 集 Web検索を支える大規模分散システムの 安定運用とその課題 NTTレゾナントは商用のWeb検索システムの開発と運用を行っています． これは1 000台以上のサーバから構成される大規模分散システムです．本稿 た け の ひろし 竹野 浩 /三浦 史光 み う ら ふみあき では，このようなシステムを運用するうえでの問題点を紹介し，大規模分散 NTTレゾナント システムの安定運用に関して論じます． Web検索システムを安定運用する には NTTレゾナントは商用のWeb検索 ラが収集しなかったWebページは検索 デックスを用いて検索処理を行います． 対象外になるので，高速かつ網羅的に より高い検索精度の要求等にこたえる 収集する必要があります． ために，より高速な検索処理性能を付 加するなど，絶え間ない改良がなされ Webページ解析は，収集したWeb ています． システムの開発と運用を行っています． ページに対して，自然言語処理等を これは， 開 発 ・ 試 験 環 境 を含 めて 行って検索インデックスを生成します． 1 000台以上のサーバから構成され， 初期のWeb検索システムでは，この機 精度の高い全文検索を毎秒1 000回以 能は文字コード正規化等の単純なもの 上実行することが可能な大規模分散シ でしたが，今日では高い検索精度の要 一般に「商用サービス」と呼ばれる ステムです． 求にこたえるため，Webページ内から サービスは少なくとも，①サービスを このシステムでは，良好な検索結果 複数の情報を抽出して検索インデック 停止させないこと，②サービスの品質 を維持するため，全文検索処理以外に スの複数カラムに格納する機能，Web を維持することが必要であり，商用 Webページの収集・自然言語処理・ ページ間の関係を抽出して検索精度の サービスを前提としたWeb検索システ 検索インデックスの生成・検索エンジ 補正情報として検索インデックスに格 ムは，このための機能を持つ必要があ ンへの配布といったジョブが常に複数 納する機能等を有し，重要性が増すと ります．NTTレゾナントの商用サービ 種類非同期で動作しています．これら ともに，システム全体に占める設備の ス用のWeb検索システムの全体構成を の運用にかかわるハードウェア障害， 割合も大きくなっています． 図２に示します． 人為的ミス等の現実の問題を紹介し， 商用サービス用のWeb検索システ ムの構成 検索エンジンは生成された検索イン 検索処理能力不足で検索サービス 大規模分散システムの安定運用に関し て論じます． Web検索システム Web検索システムの仕組みと構成 検索条件 Web検索システムの全体構成を図 １に示します． W e b 検 索 システムは， クローラ， Webページ解析，検索インデックス， Webサーバ Web ページ ① クローラ 検索エンジン ④ ユーザ 検索結果 ② Webページ 解析 ③ 検索 インデックス 検索エンジンから構成されます． クローラは，ネット上のWebサーバ 図１ Web 検索システムの全体構成 からWebページを収集します．クロー NTT技術ジャーナル 2012.5 11 検索サービス 検索系 Webユーザ インタ フェース サービスA 検索条件解析 キャッシュ サービスB 検索条件解析 キャッシュ サービスC 検索条件解析 キャッシュ 検索結果統合 検索 エンジン α 検索条件解析 運用ユーザインタフェース 検索 エンジン β … 検索 エンジン X 検索インデックス更新制御 ニュース 運用システム ・検索結果確認，インデックス修正， ログ集計，システム監視 ブログ Webページ解析・ インデックス生成１-２ カテゴリA 収集・解析系 クローラ カテゴリB チューニングシステム ・アルゴリズム調整，ログ分析 ⋮ カテゴリX Webページ解析・インデックス生成３ 臨時 Webページ解析・インデックス生成４ 運用・検索精度検証系 分散データ処理基盤 図２ 商用サービス用の Web 検索システムの全体構成 を停止させないため，検索サービスを 後述する分散検索処理基盤を用いて 収集解析系で使用されている分散 停止せずにシステムのメンテナンスや更 ファイルシステムとしての冗長化を データ処理基盤は，NTTが開発した 改を可能にするため，検索処理を担当 行っています． 大規模分散データ処理フレームワーク する系（検索系）は，同一のものを複 多様な収集を効率的に行うために， です．これは， ① 並列処理・分散処理を簡単に 数用意して冗長化してあります．また クローラは目的別に複数系統用意して 系の中の機能も必要に応じて冗長化し ありますが，W e b ページ解析とイン 実現でき，数百台のサーバを使用 てあります． デックス生成は特に大量のサーバが必 し，数百TB規模のデータを短時 要であるため，クローラごとには用意 間に処理することが可能． 規模や更新頻度の異なるコンテンツ の検索を効率的に行うために，複数種 せず共有して使用しています． ② サーバダウンに備えてデータが 類の検索エンジンを用意し，これらの NTTレゾナントのWeb検索システム 三重化されているほか，ネット 検索結果を統合して出力しています． には，システムの動作を監視する機能 ワークの故障，データ破損等の障 クローラとWebページ解析を行う系 のほかに，検索結果の品質を監視して 害に自動的に対処することが可能 （収集・解析系）は，障害がただちに 必要に応じて修正する機能，そのため で，耐障害性に優れている． 検索サービスに影響するわけではない にログを分析する機能が用意されてい という特徴を持っており，Webページ ので，コスト面を考慮して系単位の冗 ます．この系を「運用・検索精度検証 解析，インデックス生成に加えて運 長化は行っていません．しかしながら 系」と呼んでいます． 用・検索精度検証系でのログ解析に 12 NTT技術ジャーナル 2012.5 特 集 使用されています． Web検索システムを動作させるた めのジョブとその管理 Web検索の安定運用の定義と安定 運用を妨げる要因 バとネットワーク機器を使用します． サーバが１ 000台あれば，ほぼ毎日ど れかのサーバに障害が発生すると考え 安定運用とは，「サービスが停止せ られます．ソフトウェア側がサーバ障 私たちはWeb検索システムを動作さ ずに品質も良好であること」「運用者 害を想定した機能を有していれば，障 せるためのまとまった処理を「ジョブ」 の作業が非定期ジョブの起動のみであ 害発生が必ずしもサービスに影響を与 と呼んで管理しています．ジョブは並 ること」とします．前者が達成できな えるとは限りませんが，障害を起こし 列かつ非同期に動作します．ジョブに いとユーザの満足度が下がって運用者 たサーバはいずれ修理・交換・撤去し は定期的に実行されるもの，非定期に の収入が減少します．後者が実現でき なければならず，これは非定期ジョブ 実行されるもの（非定期ジョブ）があ ないと運用者の作業が増えてコストが としては処理できないので安定運用の ります．非定期ジョブには，検索イン 上昇します． 妨げとなります． デックスのメンテナンス，障害発生後 のリカバリ処理等があります．障害対 ハードウェア自身の信頼性を向上さ （1） ハードウェア障害 大規模分散システムでは大量のサー せる手 段 はほとんど存 在 しません． 応やソフトウェアのアップデートは含み ません． Web検索システムの基本ジョブの一 部を図３に示します．これは収集・解 ① クローラがWebページを収集する． ② 収集したWebページを解析して検索インデッ クスを生成する． ③ 運用・検索精度検証系からのデータに基づい て検索インデックスを修正する． ④ 完成した検索インデックスを集約して各デー タセンタの検索エンジンのサーバに転送する． ⑤ 検索インデックスを検索エンジンにロードする． 析系で動作するジョブであり，クロー ラの種類ごとに独立に動作しますが， 一部でWebページ解析処理・インデッ クス生成のための設備を共有している ため排他処理が存在します．ジョブの 実行時間はクローラの種類・Webペー ジの収集状況によって大きく変化し 図３ Web 検索システムの基本ジョブ ます． ジョブの管理テーブルの一部を図４ に示 します． これにはすべての定 期 ジョブの動作時間と終了時間の予定を 記述します．このテーブルを用いて定 期ジョブが予定どおり進行しているか の管理を行いますが，静的な管理しか できないこと，実行周期が24時間以内 ジョブ名 動作時間（24時間） 収集データ解析A-1 収集データ解析A-2 インデックス生成方式A-α インデックス転送A-1 のものだけで200種類以上のジョブが インデックス転送A-2 存在し，予定時間で終了しない場合も インデックス生成方式A-β 多いので，システム状況の全体把握は インデックスロードA-1 困難であるといえます． インデックスロードA-2 図４ ジョブの管理テーブル NTT技術ジャーナル 2012.5 13 検索サービス エイジング＊１は故障率がいわゆるバス ジョブではなく安定運用を妨げる要因 あり，安定運用を大きく阻害してしま タブ曲線を描くことを想定しており， でありますが，その失敗はリカバリ作 います． 常に有効であるとは限りません．冗長 業を必要とし，定期ジョブのスケジュー 化はサービスとしての信頼性は向上さ ル調整を招くことが多いので，安定運 せますが，ハードウェア障害の発生確 用を大きく阻害してしまいます． （5） 複合的な要因 大規模分散システム特有の複合的な 要因が重なって想定外の状況が発生す 率は上がるので安定運用には貢献しま ハードウェア障害がなくなることは る場合があります．先日発生した障害 せん．よってハードウェア障害は，もっ ないので，構築・リリース作業も人為 の発生メカニズムを図５に示します． とも深刻な安定運用の阻害要因です． 的ミスもなくなることはありません． （2） ソフトウェア障害 ① あるクローラからWebページ解 析処理にデータがほとんど入力さ （4） 通信要因 適切な手法で開発されたソフトウェ 大規模分散システムにおいては，地 れなかった．その結果，解析処理 アの信頼性はハードウェアの信頼性を 域的に離れた複数のデータセンタでシ が一瞬で終わり，結果がファイル 超えることができます．しかしながら， ステムを構 成 することがあります． に書き込まれた． ハードウェア障害はランダムに発生す NTTレゾナントのWeb検索システムに ② 小規模のファイル書き込みが分 る傾向があるのに対し，ソフトウェア おいては数十個のジョブがデータセン 散データ処理基盤で多数同時に実 障害は，発生件数は少ないものも，特 タ間の通信を行いますが，これらは非 行されたため，サーバの負荷が急 定の機能に集中して発生する傾向があ 同期で動作しています．データセンタ 上昇して反応が遅くなり，ハード ります．この場合，冗長系による可用 間の通信にはインターネットが使用さ ウェア障害であると誤検出された． 性向上施策は効果を発揮しないので， れることが多いので，外部要因で通信 サービスに影響が生じる可能性があり が遅延し，ジョブの実行に遅延が生じ 処機能が働き，ファイル修復のた ます．Web検索サービスの場合，検索 る場合があります．この場合も，定期 めの書き込みが繰り返され，さら 系のソフトウェア障害はサービス停止 ジョブのスケジュール調整，リカバリ に負 荷 が上 昇 した． その結 果 ， につながりかねないので最優先で品質 作業が必要になる場合が多いので，安 Webページ解析処理が機能しな を向上させる必要があります． 定運用を大きく阻害してしまいます． くなったため，これを共有してい プログラムが設計どおり作成されて 大規模分散システムにおいては，シス るすべてのクローラのジョブが終 いても，その動作原理が適切でない場 テム内のデータ転送・制御で大量の 了しなくなった． ＊２ ③ 分散データ処理基盤の障害対 合は，性能不足・機能不足・異常系 ssh（Secure SHell） セッションを この障害から回復するには，分散 の考慮漏れ等が発生する可能性があり 使用します．セッション数の必要量は データ処理基盤をリセットして処理を ます．これは開発の初期段階で検出す 状況次第で大きく変化します．また やり直す必要がありました．多くの ることは困難であるので，商用のサー O S のセッション処理能力も状況次第 ジョブが巻き添えを受けたため，リカ ビスに近い総合試験を十分に行う必要 で大きく変化するため，場合によって バリコストは膨大であり，安定運用を があります． はOSのセッション管理の限界を超えて 大きく阻害してしまいました． （3） 構築・リリース作業ミス しまう場合があります．この場合，い 1 000台のサーバにそれぞれ適切な くつかのプロセスが r e a d / w r i t e 待ち 設定を行ってシステム構築したり，ソ になりジョブが終了しません．これは フトウェアをアップデートしたりするの 外部的にはI/O待ちになるので障害と は意外に複雑な処理であり人為的ミス しての検出は困難です．また，プロセ がもっとも多い作業です．システム構 スおよびジョブの強制終了・リカバリ 築やソフトウェアアップデート自体が 作業が必要になるので，被害が甚大で 14 NTT技術ジャーナル 2012.5 ＊1 ＊2 エイジング：安定動作するまで動作させる こと．本稿では初期故障を発生させる個体 を排除するための工程という意味で使用し ています． ssh：ネットワークを介して別のコンピュー タにログインしたり，遠隔地のマシンでコ マンドを実行したり，ファイルを移動する プログラム． 特 集 害の拡大は防がなければなりません． これには，システム全体を対象とした， １ ３ ２ 「障害の速やかな検知」と「影響範囲 ニュース の特定」が必要です．現状では個々の ブログ 収集・解析系 クローラ Webページ解析・ インデックス生成１-２ カテゴリA ジョブの状態取得すら監視コストの問 題で限定的にしか行われていません． カテゴリB 前述のプロトコルを用いて監視コスト カテゴリX Webページ解析・インデックス生成３ を削減することで障害検知のタイムラ 臨時 Webページ解析・インデックス生成４ グを短縮するとともに，現在静的にし 分散データ処理基盤 か行われていないジョブの管理を動的 に行って，大規模分散システムの複雑 図５ 複合要因による障害発生 な動作状況の確認を容易にすることを 検討しています． 安定運用に近づくための手段と課題 トを作成する運用に変更しましたが， 複数のプログラムを複数のグループの NTTレゾナントではWeb検索サー サーバにリリースする場合で事故が発 ビスの商用運用を継続することで蓄積 生しました．アカウント作成ミスも発 された障害情報を基に，さらなる安定 生しましたし，全体の作業時間も長く 運用を目指して，システムと運用体制 なってしまいました．これよりアカウン の再検討を行っています． ト作成のコストを削減し，必要なサー （1） ハードウェア障害 バに必要な時間だけアカウントを作成 前述したようにハードウェアそれ自 身の信頼性を向上させる手段は存在し ません．よって，ハードウェア障害が する仕組みが必要であることが分かり ました． （3） セッション数の問題 発生した場合，サービスの影響を抑え 今日のサーバ性能でも，大量のサー るだけでなく，復旧措置のコストを下 バに対して同時に通信を行う用途には， げるという観点で，システム構成・運 sshは負荷が高すぎると判断しました． 用体制の検討を行っています． データセンタ間の通信が存在するため （2） 構築・リリース作業ミス 単純なプロトコルに戻ることはできま 人為的ミスも，それ自身の改善は不 せんが，通信の両端の管理者が同一で 可能な要因です．構築・リリース作業 あることを前提として必要最小限のセ における人為的ミスを調査したところ， キュリティ機能を持つプロトコルと，そ 作業すべきサーバの選択ミスが支配的 れを利用した分散システム制御機能の であることが分かりました．これはサー 検討を行っています． バの数が多いことに加えて，どのサー （4） 複合要因の問題 バがどの機能を担うか頻繁に変更され 大規模分散システムで，予想外の問 るのが原因として考えられます．作業 題が発生するのは不可避であると考え を行うサーバのみに作業者のアカウン ます．問題の発生は防げませんが，被 （左から）竹野 浩/ 三浦 史光 Web検索のような大規模分散システムの 安定運用は，ソフトウェアの品質改善だけ では実現できない困難な作業です．今後は， 商用サービスの開発・運用から得られた知 見を活かして，安定運用しやすいシステム の実現に向けて努力したいと考えています． ◆問い合わせ先 NTTレゾナント サーチ事業部 TEL 03-6703-6006 E-mail takeno nttr.co.jp NTT技術ジャーナル 2012.5 15