-
understeer
- 1286
- 0
- 2
- 0
-
- いいね！0
Sadayuki Furuhashi
@frsyuki
RT @shot6: 今回のAWSでの障害についてのご報告 > http://media.amazonwebservices.com/jp/4-28-11PostMortem_JP_v1.1.pdf
2011-05-02 13:02:42
Sadayuki Furuhashi
@frsyuki
EBSは管理ノードとデータノードで構成される、ハイブリッドなP2Pシステムであるらしい。データは複数のデータノードにレプリケーションされ、その内の一つが "プライマリ" レプリカになっている。データの変更はプライマリレプリカに対してのみ許可される。
2011-05-02 13:21:02
Sadayuki Furuhashi
@frsyuki
プライマリレプリカは、管理ノードとデータノードにクライアント（=EC2インスタンス）を加えた、3者がネゴシエーションすることで決定される。ポイントは、管理ノードはリージョンに1セット存在する点か。AZに1セット存在するのではない。
2011-05-02 13:24:25
Sadayuki Furuhashi
@frsyuki
複数のAZにまたがった管理ノードを置くことで、データを複数AZにまたがってコピーしつつ、一貫性を維持することを（シンプルに）可能にしている。この設計はウマイな。EBSが1台からしか同時に使えない制約を踏まえて。
2011-05-02 13:27:20
Sadayuki Furuhashi
@frsyuki
たぶんプライマリレプリカは常に同じではなく、I/Oリクエストがあったときに動的に決定され、管理ノードがクライアントに一番近いデータノードを指定しているのかなーと予測。データノードの間でトランザクションというか分散合意はしているかもしれない。
2011-05-02 13:29:27
Sadayuki Furuhashi
@frsyuki
レプリケーションは別回線になっているのはいいなぁ。インフラも自前で作っている強みか…。データノードの障害は、プライマリデータを持っているデータノードが、レプリケーションに失敗したタイミングで検出しているようだけど、レプリケーション回線が専用なので障害検出の速度/精度を高めやすい。
2011-05-02 13:33:18
Sadayuki Furuhashi
@frsyuki
管理ノードにはプライマリレプリカの選択時や再選択時（=障害発生時）、あと新規ボリュームの作成時くらいにしかアクセスが来ないので、（普通は）負荷が低い。ノードの管理方法が2段階か。管理ノード→プライマリのデータノード。多くの操作は管理ノードからプライマリのデータノードに委譲できる。
2011-05-02 13:40:32
Sadayuki Furuhashi
@frsyuki
管理ノードも複数のサーバで構成されているハズだけど、どんな設計なんだろな。データノードとの通信プロトコルに"普通"でない分散なにやらを使っているのか、普通にshardingで負荷分散するか。後者か、両方の組み合わせかーという印象。
2011-05-02 13:45:56
Sadayuki Furuhashi
@frsyuki
ここは一貫性が重要なので、分散が難しい。思うには、プライマリのデータノードに管理権限を委譲することで管理ノード（=分散しにくい）の負荷を下げるのがEBSシステムのキモで、それは同時に1台からしか使えない制約のトレードオフとして、一貫性･負荷分散･高可用性を高レベルで実現できる。
2011-05-02 13:51:32
Sadayuki Furuhashi
@frsyuki
で今回は、ネットワーク拡張時の障害によって、レプリケーション回線（=十分な帯域が確保された高品質と仮定できる回線）の負荷が高まってしまったために、障害検出の精度が低下し、管理操作（=一貫性が重要で分散しにくい）の発行件数が増大し、それらを処理しきれなくなったことが原因らしい。
2011-05-02 13:56:25
Sadayuki Furuhashi
@frsyuki
管理操作でも、空き容量の確保がメインか。とりあえずレースコンディションのバグはマズイとか、管理操作をバースト的にリトライするのはヤバイという話があるようだけど、こういう問題をテストで排除できるなり何やら仕組みを誰か作ってくださいという感じで、現在の文明ではまだまだ無理らしい…。
2011-05-02 14:09:31
ARAKI Yasuhiro ☁ AWS Solution Architect
@ar1
@frsyuki 今回のことで分かる人にはだいぶ分かってしまいましたね。
2011-05-02 14:12:56
Sadayuki Furuhashi
@frsyuki
分散のシステム的には、障害検出のアルゴリズムを改善したいか。クラスタ全体の状況を元に閾値を変化させることで、全体の破綻を防ぐ（破綻までの時間を長引かせる）。回線の品質に対する仮定とか、静的な情報に頼った方法では限界があり、アーキテクチャ的に今回のような問題を回避することができない
2011-05-02 14:14:45
Sadayuki Furuhashi
@frsyuki
クラスタの信頼性確保においては、一貫性レベルを保証するメンバーシップ管理と破綻しない障害検出がマジキモなわけで、そこのトコロをうまく設計･実装してくれたシステムなりフレームワークがあるといいのだけど。
2011-05-02 14:27:28
Sadayuki Furuhashi
@frsyuki
理想的な回避方法は前人未踏な問題になるわけで、現実的にはこういう全体的な障害からの復旧とか、上位のサービスレベルでの対応が必要なんだろなぁ。CPUの進歩でプログラムが勝手に速くなる時代が終わったように、サービスの信頼性が自動的に確保される時代は、もう終わったか近いうちに終わる…！
2011-05-02 14:43:04