Facebookは昨日、2日間で2度目のオフラインに陥りました。木曜日に発生した障害は、一部のユーザーで2時間以上続きました。これはデータベース管理の不具合を物語っており、効果的なテストと変更管理手順の必要性を浮き彫りにしています。
問題の詳細を説明したFacebookのブログ投稿によると、「今回の障害をこれほど深刻なものにした主な欠陥は、エラー状態の処理が不適切だったことです。設定値を検証する自動システムは、修復したよりもはるかに大きな損害を引き起こしてしまいました。」
しかし、これはまだ半分しか解明されていません。データベースの不具合は、設定値の変更によって引き起こされました。データベースのエラー処理は、設定値が無効であることを検出し、指定された設定値に更新するはずです。しかし、Facebookが実装した新しい設定値も無効と判断され、無限ループが発生しました。
Facebookは次のように説明しています。「さらに事態を悪化させたのは、クライアントがデータベースへのクエリ実行時にエラーが発生するたびに、それを無効な値と解釈し、対応するキャッシュキーを削除していたことです。つまり、元の問題が解決した後も、クエリのストリームは継続していました。データベースがリクエストの一部に対応できない限り、データベース自体へのリクエストがさらに増加し続けました。データベースを回復できないフィードバックループに陥っていたのです。」
最終的にFacebookは、ループを断ち切るためにサイトを閉鎖し、影響を受けたデータベースクラスタをオフラインにせざるを得なくなりました。最終的にはユーザーのサイトへの復帰を許可しましたが、問題の原因となった設定エラー修正システムを無効化し、今後同様の問題が再発しないよう新たな解決策を模索しています。
今週初めに発生したTwitterのクロスサイトスクリプティングワーム事件と同様に、Facebookの障害はIT管理者にとっていくつかの教訓となる。Twitterワームは、Twitterが既に特定し修正プログラムを適用していた脆弱性を悪用したものの、その後のウェブサイト更新で意図せず再び露出させてしまったのだ。
Facebookの障害は、適切なテストと検証を行わずにライブウェブサイトに設定値を実装したことが原因でした。Facebookが、実際のデータベースクラスタをミラーリングするように設計されたラボ環境で新しい設定値をテストしていれば、Facebookサイト全体のオフライン化を許可する前に、新しい設定値の問題と、この問題を引き起こしたエラーループを特定できたはずです。
あなたのウェブサイトは、Facebookのような他のウェブサイトよりも5億人のユーザーが長い時間を費やしているわけではないかもしれませんが、それでもウェブサイトに依存しているユーザー、パートナー、そして顧客がいます。安全なコーディングプラクティスを遵守し、堅実なパッチ管理と変更管理手順を遵守することで、サイトがダウンする前にこのような問題を積極的に検出し、解決するようにしてください。
