# A survey on reliability in distributed systems > [!abstract] 概要 > 分散システムにおけるソフトウェアの信頼性は、ステークホルダー、とりわけアプリケーションのベンダーと利用者にとって常に大きな関心事である。電子政府、電子商取引、マルチメディアサービス、エンドツーエンドの自動車ソリューションなどの大規模分散アプリケーションの信頼性を評価・予測するために各種のモデルが作られてきたが、これらのシステムの信頼性の問題は依然として残っている。分散システムの信頼性を確保するには、システム全体の信頼性を予測・評価する前に、企業向け分散アプリケーションに関わる個々の構成要素や要因の信頼性を調べる必要があり、さらに、エンドユーザーに切れ目のない対話を提供する透過的な障害検知・障害回復の仕組みを実装する必要がある。このため、個々の構成要素の信頼性を調べる観点から既存の信頼性の方法論を詳細に分析し、分散システム上で動くアプリケーションに包括的な信頼性モデルがなお必要な理由を説明した。本論文は、大規模分散アプリケーションの信頼性の分析と予測に関する近年の研究の詳細な技術的概観を 4 部に分けて述べる。まず、高信頼システムの現実的な要件を述べ、クラウドコンピューティング、グリッドコンピューティング、サービス指向アーキテクチャ(SOA)といった異なる計算環境における信頼性の意義と各種の問題を強調した。次に、高信頼な分散システムにとって自明でない要因と各種の課題を、障害検知、回復、試験や各種レプリケーション技術による除去を含めて説明した。続いて、分散システム上のソフトウェアアプリケーションの信頼性を予測・測定するうえでの要因と課題に取り組む研究モデルを吟味した。最後に、既存モデルの限界を論じ、分析を踏まえて実環境における分散アプリケーションの信頼性を予測・分析する今後の課題を提案した。 ## 論文情報 - タイトル: A survey on reliability in distributed systems - 著者・所属: [[Waseem Ahmed]]、[[Yong Wei Wu]](清華大学 計算機科学技術系、北京) - 媒体: Journal of Computer and System Sciences 79 (2013) 1243–1255(2011-04-15 改訂稿受理、2013-02-22 採録) - DOI: 10.1016/j.jcss.2013.02.006 - 13 ページ。章立ては 1 序論、2 概念的枠組み、3 既存研究、4 議論と既存モデルの限界、5 結論と今後の課題であり、長編サーベイ(30 ページ超)には当たらない ## 概要 分散システム、グリッド、クラウド、SOA の各環境における信頼性の予測手法と耐障害技術を、フォールトライフサイクルの枠に沿って整理したサーベイである。予測モデルをユーザー中心・アーキテクチャ基盤・状態基盤の 3 種に分類し、各モデルが信頼性に効く要因を総合して扱わず、ハードウェア信頼性を定数とみなすことを共通の欠陥として指摘する。結論として、全要因を考慮して実環境で継続的に予測する N ステップ先信頼性予測の必要を述べる。 ## 問題設定 - 対象は、電子政府・電子商取引・マルチメディア・自動車エンドツーエンドなどの大規模な企業向け分散アプリケーションである。 - 高信頼への要求の背景として、著者らは 8 点を挙げる。QoS とデータ量増加への追随、信頼性の低さによる時間・金銭の損失、Web 型エンドツーエンドアプリケーションでの競争激化、顧客の事業損失、同時要求やデータ急増下でも信頼できること、セキュリティ(侵入・サービス拒否・データ漏えい)、資源共有に起因するタイムアウト・ブロッキング・プログラム障害、異種資源の協調の複雑化である。 - 信頼性は、指定時間 t の間に停止せず、要求どおりに動き、障害に耐えて回復し、指定環境で意図した機能を果たす確率と定義される。その 4 次元は、確率(指定の統計的信頼水準で成功する)、意図した機能、時間依存(指定時間内に障害がない)、特定の条件(指定のハードウェア・通信環境)とされる。 - 問いは、個々の構成要素の信頼性を出発点に、システム全体の信頼性を予測・測定する汎用モデルに何が欠けているかである。 ## 提案手法(サーベイの枠組みと分類) 本論文は新規手法を提案せず、既存研究を次の枠で整理する。 - **フォールトライフサイクルの 4 技術**(Lyu の整理に依拠): 障害予防(開発中に誤りを除く)、障害除去(複数の試験段階を経て除く)、耐障害(冗長性による仕様どおりのサービス提供)、障害・故障予測(設計段階や配備前に見積もる)。前 2 者はほぼ全ソフトウェアで使われるのに対し、後 2 者が信頼性の属性として産業界と学界で注目を集めていると述べる。 - **環境ごとの課題**(表 1)。グリッド、SOA、クラウドで信頼性予測を難しくする要因が異なる。 | グリッド基盤のアプリケーション | SOA 基盤のアプリケーション | クラウド基盤のアプリケーション | |---|---|---| | 資源が世界中に分散し地理的制約がないため、地理的に離れた資源が、ネットワーク越しの要求より自ノードの要求を優先する可能性が大きい。 | SOA の複雑な分散アプリケーションでは、Web サービスが他組織の所有・ホストで、予測不能なインターネットのために容易に利用不能になりうるので、サービス信頼性の予測・測定が従来のソフトウェアより難しい。 | クラウドの信頼性は極めて重要だが、大規模なサービス共有、広域ネットワーク、異種のソフト・ハード構成要素、それらの複雑な相互作用のため分析しにくい。各アプリケーションの構成・設定・配備の要件が異なり、状況ごとの信頼性の分析・予測は難題である。 | | 非同期な環境で、構成要素が独立したクロックと、遅延に上限のないメッセージを使うため、資源間の協調に不確実性が生じる。 | 遠隔サービスの試験は時間も費用もかかり、試験を経ずに遠隔 Web サービスの信頼性を保証するのは難しい。 | | | グリッドでは資源が複数の利用者で共有され、単一要求の待ち時間が許容できない値まで増えうる。 | ベンダーやプラットフォームをまたぐ相互運用性の実現に WSDL と SOAP の基本標準を超える機能が使われ、メッセージの信頼性は依然として問題である(接続断、未配送、重複配送、順序誤り、傍受)。 | | | グリッドは異種構成要素の階層構造(グリッドファブリック、コアグリッドミドルウェア、ユーザーレベルグリッドミドルウェア)を持ち、階層ごとにブロッキング・タイムアウト・ネットワーク・プログラム障害などが起こりうる。 | | | (Table 1. 異なる計算環境における各種の課題。) - **技術階層と要因**。企業向け分散アプリケーションの技術を、ハードウェアとソフトウェアの各々で「低水準の詳細」と「広い水準の詳細」に分ける(表 2)。 | | ハードウェア | ソフトウェア | |---|---|---| | 低水準の詳細 | CPU、ストレージ装置、メモリなど計算機の各構成要素の信頼性 | 各種サービスとその下位の OSI 階層構造、アプリケーションのメソッド・関数・ルーチン、応答時間、ネットワーク遅延などの機能・信頼性 | | 広い水準の詳細 | サーバ(ファイル、DB、Web、メールなど)の可用性とスケーラビリティ、通信基盤、接続機器の信頼性 | 分散アプリケーションの各機能全体の信頼性、耐障害・回復技術の信頼性(ユーザー負荷が最大のピーク時か通常実行時) | (Table 2. 分散アプリケーションの信頼性に影響しうる各種の基盤技術。) 図 1 は、分散アプリケーションが正しく信頼できる動作のために依存する要因を示し、どれか 1 つの失敗がアプリケーション層の誤り、不整合、サービス拒否につながりうると述べる。 **Figure 1: 分散アプリケーションが正しく信頼できる動作のために依存する要因** ![[_attachments/2013__JCSS__A-Survey-on-Reliability-in-Distributed-Systems/fig01-factors-dependencies.png]] (Figure 1. クライアントからインターネットを介して、リモートサーバ群、内部サーバ群、外部サービス、中央 DB、計算機システムへ至る構成に、要因 1〜5(アプリケーションの信頼性と配備、ネットワーク・関連機器・接続・通信プロトコルの信頼性、ハードディスク・メモリ・CPU・デバイスドライバの信頼性、外部サービスとの相互作用、サーバクラスタ上のアプリケーションのスケーリングや互換性)を注記した図。図中の注記文は解像度が低く一部のみ判読できた。) - **信頼性に効く要因**(表 3、Zhang と Pham の分析に依拠)。1・2・3・6・7 は SDLC の各段階で詳しく分析でき、試験環境・ハードウェア・プログラム負荷・外部サービスとの相互作用は設計段階や配備前の予測に効く。 | 番号 | 要因 | 番号 | 要因 | |---|---|---|---| | 1 | 不十分な試験 | 6 | 変更管理の問題 | | 2 | 運用上の誤り | 7 | 低品質のソースコード | | 3 | 一貫した品質保証工程の欠如 | 8 | 外部サービス・アプリケーションとの相互作用 | | 4 | 異なる運用条件(高い利用率と過負荷) | 9 | ランダムな事象(セキュリティ障害) | | 5 | ハードウェア障害(ハードディスク、ネットワーク機器、サーバ、電源、メモリ、CPU) | 10 | 運用環境に関する問題 | (Table 3. ソフトウェア信頼性に影響する要因。) - **信頼性モデルの共通仮定と批判**: (1) 測定・予測する試験環境が、モデルをパラメータ化する運用環境と同じ、(2) 社内試験で集めた故障データが実運用の故障を代表する、(3) ハードウェアの信頼性は定数、の 3 つを挙げ、ハードウェア故障でデバイスドライバがハングやクラッシュしうると述べる。ハードウェア故障の特性は、故障率が初期と末期に高いバスタブ曲線で示される(初期は製造欠陥、末期は使用後の劣化)。 **Figure 2: ハードウェア故障の特性を示すバスタブ曲線の例** ![[_attachments/2013__JCSS__A-Survey-on-Reliability-in-Distributed-Systems/fig02-bathtub-curve.png]] (Figure 2. 故障率が減少する期間(初期の「幼児死亡」故障)、一定の期間(ランダム故障)、増加する期間(摩耗故障)に分かれ、観測される故障率は 3 期間の合成としてバスタブ形になる曲線。) ### 耐障害技術(§3.1) - 障害はアプリケーション層、システム層、ネットワーク層の 3 種に分類され、空間的冗長(ハードウェア・ソフトウェアの複製)または時間的冗長(操作の多様化)で対処する。データの複製は大規模分散システムの性能への影響が大きく、マルチメディアオブジェクトの透過的な複製配置について最適解が提案されている(文献 45、28)。 - 大半の技術は障害時にクライアント要求をバックアップサーバへ振り向けるだけで、実行中の要求は事実上捨てられ、その取引を回復する仕組みがない。文献 9 は、Linux カーネルと Apache Web サーバを改変し、実行中の要求の状態をログで監視して正しく処理するとする。 | 文献 | 戦略 | 問題点 | |---|---|---| | [5] | 能動・受動の両方のレプリケーションと業務プロセス仕様を用い、Web サービスのオーケストレーションで耐障害方式を構築。サービスの合成と呼び出し、障害検知、耐障害の 3 モジュールから成り、同一サービスの複数レプリカを提供する。 | [5,41,10,12,11] は、サービス状態を保持せずに新規要求を処理し始めるスタンバイのバックアップサーバを用意するだけである。オンラインバンキングや電子商取引のような金銭取引を扱うリアルタイム分散システムでは、サービス状態の保持が未解決である。 | | [41,10] | 各プロセスの状態を安定記憶に保存するログ方式を提案。誤り検知時に以前のチェックポイントへロールバックして再開し、再開にローカル回復とグローバル回復の仕組みを導入。 | [41,10] のプロセス状態の保存は、遠隔 Web サービスが絡むと、その内部のプロセス状態を管理・追跡できないため実現できない。 | | [12] | Web サーバ向けのクライアント透過な耐障害方式で、サーバ障害時に処理中の要求を正しく扱う。 | (上の [5] 行の問題欄に含まれる) | | [6] | 複数のレプリケーション方式でシステムの可用性を高め、Web サービスの依存性に影響するパラメータを特定。 | (対応する問題点の記載なし) | | [9] | Linux カーネルと Apache Web サーバの変更により、要求を、バックアップサーバと主サーバへ送るマルチキャスト機構を実装。 | カーネルや Web サーバの改変自体が信頼性上のオーバーヘッドで、アプリケーションの信頼性の前にその改変の信頼性を確保する必要がある。文献 46 のモデルはクラウドの選択のみを扱い、クラウド基盤システムの信頼性パラメータを記述しない。 | | [11] | グリッド基盤の通知機構による受動的レプリケーション。同一サービスのレプリカと主・バックアップ方式で、高信頼・高可用なグリッドサービスを提供。 | (下の [9] 行の問題欄に含まれる) | | [46] | 障害のある(信頼できない)クラウドに対する耐障害性と信頼性を高める技術。クラウド環境の選択問題に特化したモデル。 | (下の [9] 行の問題欄に含まれる) | (Table 4. 各種モデル・戦略の分析。原表は問題点欄が複数行にまたがるため、行への割り当ては本文の記述に従って整理した。) ### 障害・故障予測(§3.2) 3 種のモデルを分けて扱う。全般の欠陥は 2 点で、表 3 の要因を総合して扱わないか一部を定数とみなす点と、ハードウェア障害を定数として扱うか無視する点である。 **Figure 3: 各種の信頼性予測モデルでの各要因の利用状況を示すグラフ** ![[_attachments/2013__JCSS__A-Survey-on-Reliability-in-Distributed-Systems/fig03-factor-usage-by-approach.png]] (Figure 3. 運用条件、ハードウェア障害、外部サービスとの相互作用、セキュリティ障害、運用環境の問題の 5 要因を、状態基盤・アーキテクチャ基盤・ユーザー中心の 3 アプローチについて示す 3 次元棒グラフ。本文はこの図を根拠に、ハードウェア障害が定数か無視であると述べる。棒の値は画像から読み取れなかったため転記しない。) - **ユーザー中心の手法**: システムの利用に着目し、サービス利用者とベンダーの双方の尺度で予測する。運用・利用プロファイルなしにはサービスの実影響が分かりにくい。WS-DREAM は、地理的に離れた利用者が中央サーバへ試験結果を共有する協調評価で、ブラックボックス試験に当たる。ただし通信の不確実性や利用者数の変動、データセンターの違いを無視するため、実環境の信頼性を外挿できないと評価される。文献 19 は、合成されるサービス数が増えるとベンダー視点の信頼性は下がり、利用者視点では上がることを示す。グリッドでは文献 17 が、ユーザーレベルのミドルウェアに絞り、GridWay メタスケジューラが Globus 基盤上で利用者に妥当な信頼性を与えるとする。 - **アーキテクチャ基盤の手法**: 設計段階で予測して再設計費用を減らす。文献 3 は類似ユーザー・類似サービスの過去の故障データを Pearson 相関係数で見つけて協調予測するが、類似のインフラも要因であり、類似ユーザーの経験だけでは不十分とされる。SORM(文献 18)は、原子サービスを多数決に基づく群試験で、合成サービスをアーキテクチャ基盤モデルで評価する。文献 1 は、サービス入力パラメータの依存とサービス共有の影響を扱うが、遠隔サービスの信頼性情報の部分公開を前提とする。ATOP(文献 21)は、アクティビティ図を PRISM 確率モデル検査器の解析モデルへ自動変換して設計段階で QoS を評価するが、外部サービスの仕様と PRISM の結果に強く依存する。 - **状態基盤の手法**: マルコフ連鎖を使う。 **Figure 4: マルコフ連鎖過程** ![[_attachments/2013__JCSS__A-Survey-on-Reliability-in-Distributed-Systems/fig04-markov-chain.png]] (Figure 4. 状態 E と状態 A の 2 状態からなり、各状態に自己遷移があり、E から A、A から E へ遷移する連鎖の例。次の状態は現在の状態だけに依存する。) 文献 23 は、タイムアウト・ブロッキング・ネットワークなどの障害を階層ごとに扱う階層モデルで、マルコフ・待ち行列・グラフ・ベイズ解析を併用し、Chapman–Kolmogorov 方程式で定常確率を解く。文献 25 は伝送時間から各プログラムの実行時間を求め、時間制約情報からマルコフ状態を定義する。MFST の生成アルゴリズム(文献 25)は作業時間を考えないため MRST の計算に使えず、文献 24 が資源・要素・作業時間・ノード・リンクを考慮して MRST を探索し、条件付き確率でグリッドプログラムの信頼性を求める。グリッドでは、耐障害向けの故障検知が大規模・異種・動的なグリッドに向かないこと、故障した構成要素が計算に含まれると分散故障検知器が合意できないこと(文献 31)が挙げられる。クラウドでは、来歴情報の標準的な収集と提示、文献 33 のハードウェア故障特性と予測子の予備分析、文献 34 の履歴ログに基づく信頼評価モデル、文献 22 の要求段階と実行段階の 2 段階モデル(通信・DB・ハードウェア・ソフトウェアの誤りは実行段階、タイムアウトやオーバーフローは要求段階)が挙がる。 ## 新規性 - 本論文自身の位置づけは、個々の構成要素の信頼性に着目して既存の方法論を分析し、先行サーベイ(文献 15、16、20、38)が扱わなかった空白を示すこととされる。 - 主張する差分は、既存モデルが信頼性要因を総合しておらず、ハードウェア信頼性を定数とする点を、表 3 の要因と図 3 に対応づけて指摘したことである。ただし、この主張の網羅性を示す文献選択の基準は本文に示されていない。 ## 実験設定・実験結果 実験は行っていない。本論文は文献調査であり、数値評価は含まない。図 3 の棒グラフは、各モデルがどの要因を扱うかの整理である。 ## 考察(§4) - 信頼性を確保する道は、(1) アーキテクチャ段階で早期に予測する、(2) 耐障害システムで想定外の事態に備える、の 2 つとされる。 - SOA の耐障害技術に残る課題は 3 点: 処理中の要求と更新の状態が障害後に回復しないこと、ネットワーク障害でメッセージが時間内に届く保証がないこと、他組織のホストするサービスでカスケード呼び出しのトランザクションログを保持できないこと。ログ保持はバックアップサーバ・カーネル改変・Web サーバモジュール改変のオーバーヘッドを伴う。 - グリッドの課題は 3 点: ネットワーク以外の機能領域の測定基準が少ないこと、耐障害モデルが小規模なグリッドでしか試されていないこと、限られた試験データでしか評価されていないこと。 - クラウドの課題は 3 点: 停止・障害時の代替手段、相互運用性(Cloud Computing Interoperability Forum の設立)、水平・垂直スケーリング技術の機能と費用の区別が進んでいない中での信頼性のあるスケーラブルなストレージ。 - 予測では、初期段階ではユーザー負荷・CPU 負荷・ネットワークトラフィックの影響が小さく、徐々に増すため、すべての要因を使用の影響に応じて考慮する必要がある。ネットワークトポロジー、OSI 階層と通信プロトコルの互換性、通信層がハードウェアの性質を隠すことでバッファ不足からメッセージ配送が失敗しうることも、他の要因と併せて考える必要がある。 ## 強み / 弱点・課題 - 強み: 信頼性の 4 次元、フォールトライフサイクル、要因表(表 3)、予測モデル 3 分類、SOA・グリッド・クラウド別の課題を 1 本にまとめ、初学者向けの見取り図になる。 - 弱点: 結論の「ハードウェアを定数とする」批判は図 3 と文献の記述に依るが、各モデルの原論文を再検証する記述はない。定量比較や検索の方法論(選択基準)が示されない。提案する N ステップ先信頼性予測は具体化されておらず、手法・評価計画がない。本文中の「Fig. 3」の棒の値は本文で数値としては与えられない。 - 本 wiki からの補足: 引用されるクラウドの 2 段階モデル(文献 22)は [[@2009__PRDC__Cloud Service Reliability - Modeling and Analysis]] に取り込み済みである。