［速報］mixiが障害の経緯を発表。原因はお盆のアクセス急増ではなく、memcachedの異常終了

8月10日の17時20分頃から12日未明までの長時間にわたり、サービスが利用不能もしくは利用しにくい状況になっていた「mixi」。数度の断続的な復旧ののちに、本日12日午前1時50分頃には復旧が完了し、現時点で全面的に復旧しているようです。

その障害の経緯について株式会社ミクシィの広報からプレスリリース「『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ」として発表されました。

原因はアクセスの急増ではなかった

プレスリリースの中で、今回の障害の原因は以下のように説明されています。

『mixi』のデータベースへの負荷軽減のために導入しているデータキャッシュシステムが複数同時に異常終了したことに伴い、データベースへの負荷が急増したため『mixi』を閲覧しづらい状態となりました。

高負荷かつ特殊な状態でのみデータキャッシュシステムの異常終了が発生していたため、根本的な原因の究明に時間がかかることとなりました。

mixiはキャッシュシステムとしてオープンソースのmemcachedを利用しており、上記の「データキャッシュシステム」もmemcachedのことを指しているようです。

同社CTOの佐藤ニール氏は、Twitterで次のように原因をツイートしています。

mixiの障害の原因として「夏休みやお盆などでアクセスが急増したのでは？」などの推測が一部で流れていましたが、そうしたmixiへのアクセスが急増したためではなく、システム内のサーバ追加によるとのこと。

再発防止策として、以下のような施策を実行するとプレスリリースで説明されています。

1.データキャッシュシステムへの負荷を軽減する措置を施す
2.将来的に負荷が増加した場合に備え、問題が発生した際にもデータキャッシュシステムが異常終了せず処理を継続して高い堅牢性を保つ手法を調査する
3.データキャッシュシステムの障害が『mixi』のシステム全体に影響しないよう、影響範囲の局所化を検討、実施する

memcachedはmixiだけでなく多くの大規模サイトで使われている技術です。今回の障害の原因についてさらに分析をすすめて、共有できるような教訓があればぜひ公開していただきたいと思います。

関連記事

• Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側
• Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
• MySQL+Memcachedの時代は過ぎ、これからはNoSQLなのか、についての議論
• memcached互換のNoSQLデータベース「Membase」がオープンソースで登場