知り合いが、mixiの障害に関する細かい原因を記述してあるサイトをつぶやいてくれた。
そのサイトの左の方から、説明なども辿れる。”執筆者個人の環境と経験に基づく”とのことで、mixiの正式見解ではないけど、ミクシィ開発部の人なので貴重な記述。
このような（非公式）公表の仕方には意見あるかもしれないけど、個人的には好感。他の人の再発防止になるし、色んな思惑での公式な見解よりも純粋な技術的な話として参考になる。
で、個人的に実務的な実装を行ってないので細部は良くわかってないけど、分散キャッシュの”memcached”に関連した問題で、起動時のパラメータ変更で対応したとのこと。
高負荷状態のテストと同様に、接続限界数での確認を長く行えば事前に見つかったかもしれない。ただ、接続限界数を色々変えて、しかも日レベルでの動作テストすべきだろう。そうなった時に、確認環境をどうするか。一般的にクラウドのような範疇では、開発、テスト、本番の３システムを要することは言われているが、テストが１システムで良いか???
また今回は、”memcached”の問題とのことで、その点だけだとパラメータの組合せはそう多くない。が、システムには多くのソフトが使われている。各ソフトでの起動のパラメータの種類、そして複数のソフトのことを考えると、これらパラメータの組合せが膨大となる。
あと、今回は障害が長く続いた。”memcached”でのパラメータ変更の確認に時間がかかったとも言えるが、利用ユーザーからすると、もう少し早めに原因究明と確認が出来るべきだろう。
今回のトラブル、そしてその原因の記述が、開発とかテストでの課題を教えてくれた気がした。
