この記事は ex-mixi Advent Calendar 2017 19 日目のエントリーです。
こんにちは。@bonnu と申します。
株式会社ミクシィには2006年１月から2012年３月末までの間、６年と３ヶ月ほど在籍していました。その後株式会社FreakOut（現在はホールディングスとなっています）に転職。そこからさらに転職を重ね、現在は株式会社GameWithでサーバーサイドを主としたエンジニアをやっています。
ミクシィに入社した当時はまだ社名が株式会社イー・マーキュリーで、入った翌月に社名変更したタイミングでした。なので希少な「イー・マーキュリー」の名刺を持っていました。私より後に入社した他のエンジニアのみんなからよく珍しがられたのを覚えています。
今回はOB・OGによるアドベントカレンダーということで、在籍していた頃に体験した障害について少しお話したいと思います。
（※ 当時のログや詳細な記録も今となっては手元に残っておらず、また自身が退職した事もあって社内のドキュメントを漁ることもできないので、記憶を頼りに書いています… 間違いもあるかもしれませんがご了承ください）
大規模memcached障害と私
もう７年も前の話になりますが。
2010年、SNSサービス「mixi」にとっては未曾有の障害と言って差し支えない「大規模memcached障害」が起きました。当時mixiを使っていた方や、はてな界隈・ネットニュースをよく見ていた方であれば記憶に残っている方も多いのではないでしょうか。
（※ お詫びの画面。色々気にしてモザイクをかけたらワケがわからなくなりましたが、詳しくは元の記事をご覧ください）
その時の障害の原因とその解明について、この記事で詳解に話せる事はありません。詳しくは以下のエンジニアブログの記事をご覧ください。
- mixi大規模障害について - mixi engineer blog
- mixi大規模障害について その2 - mixi engineer blog
- mixi大規模障害について 解明編 - mixi engineer blog
当時を振り返る
その当時、私は「アプリ運用チーム」に所属しており、そこではサービスで利用する各種データリソース（RDB、memcached、その他KVSや画像クラスタ）及びミドルウェアの設定・プロビジョニング・運用、デプロイ保守などを主な業務としていました。またその年の春までは「たんぽぽ開発チーム」におり、サービスで利用しているプログラミング言語（Perl）のフレームワーク・共通ライブラリの開発・保守を主な業務としていた事もあり、インフラ運用とソフトウェア開発の中間的な立ち位置にいました。
障害の発生
ニュースサイトのタイムラインを参考にしつつ記憶を掘り返します。
障害の発生はすぐに捕捉されました。
この頃は私自身もmixiを愛用しており、おそらく他の社員の皆さんも同様だったのでしょう。サイトを見ているとレスポンスが返ってこなくなったり、500エラーが発生したりしました。すぐに社内がざわつき、状況を把握すべく、開発部や企画部など各所のマネージャやリーダーが運用グループに伺いにきました。
あの頃はまだSlackやChatWorkのような全社で利用できるコミュニケーションツールがありませんでした。なので開発部は独自でIRCを運用し、任意で活用していました。
どのように調査と対応にあたったか
私自身かなりテンパった事もあり、実は時系列立った記憶があまり残っていません。ですが登場人物については忘れていない気がするので、まずはその構成をリストアップしてみます。（人数は詳細ではありません）
- たんぽぽ開発チーム（約４名）
- アプリ運用チーム（約４名）
- インフラ運用チーム（約５名）
- サービス開発グループエンジニア（５名以上）
- 運用グループマネージャ
- 開発部部長
- 開発部マネージャ（およそ３名？サービス開発グループの方など）
- その他、情報伝達や調整に関わってくださった各部署の皆様（人数不明ですが、たくさんです）
かなり記憶がぼやけてしまっていますが、当時ミクシィが入っていたオフィスがワンフロアあたり120人近く入ったと記憶しているので、そのワンフロアの1/3くらいは、まさに障害現場での対応に追われていたんじゃないかと思います。
そしてこれらの面々が各々に役割を持って対応にあたったわけですが、それは決して過剰な人数ではありませんでした。
当時の役割を思い出すと…
- 初動調査（運用側面、サービスコード側面）
- 詳細調査
- 関連するデータや機能への影響の調査
- 復旧手段の検討・実行計画
- 復旧のための改修
- 復旧対応の実施（リリースやバッチ実行など）
- 関連する機能の復旧手段の検討
- 関連インフラの調査（当時mixiのほぼ全てがオンプレミスでした）
- 関連インフラの影響を鑑みての待機
- 人員のマネージメント
- 関連各所・各部（広報や営業など）との連携
- スケジュール調整
私自身、上記を挙げてみて少し大げさにも感じてしまいました。ですがそれは違います。
オンプレミスで高価なハードを使った高性能なDBや、広く横に並べられたシャーディング・クラスタ、千台規模のアプリケーションサーバ類などを扱っていました。サービスを再稼動させるべくキャッシュへのデータを書き込もうとしても、多くのリソースに接続に行くため、またどこかがボトルネックになってしまう懸念があります。二次被害を起こさず、けれど確実に解消に向かっていくためにも、慎重に事を進めていく必要があったのだと認識しています。
運用グループでの一次対応
当時のアプリ運用チームは障害検知のアラート機構にNagiosを利用していました。そのアラート一覧画面は真っ赤に染まっていたと思います。（あるいは黄色だったかもしれませんが…）通知を受け取る社内携帯も鳴り響いていました。
まずはアプリ運用チームがRRDtoolでmemcachedサーバやアプリケーションサーバなどのグラフを確認します。TCP Establishedが天井に張り付いていることから、memcachedへの接続が過多となった結果、サービスが正常に機能していないというところに辿り着きました。
たんぽぽ開発チームと連携しての調査
先ほど冒頭でも名前を挙げましたが、たんぽぽ開発チームについてご存知でない方も多くいらっしゃると思いますので簡単にご説明します。
検索するとこちらの採用向けインタビュー記事が見つかるのですが、その記事にもある通り、『mixi』のコアアーキテクチャの検討、開発工程の改善、改善のためのツールの導入検討、パフォーマンスチューニング、アルゴリズム改善をミッションとしたチームであり、サービスや新企画・新機能から一歩俯瞰的な立ち位置でシステムの向上・改善に向けた開発を担っていました。
この障害が起きた際も、まずはたんぽぽ開発チームの面々にご協力いただき、問題の解決にあたる事となったのです。その後については前述の mixi engineer blog と採用向けインタビュー記事に書いてある通りです。
選択的な縮退：サービスアクティベーション
ここまで、たんぽぽ開発チームと運用グループの対応を主として話を進めました。ですが対応にあたったのはもちろんその面々だけではありません。
この頃のmixiは既に様々な機能が盛り込まれ、SNSとしては充分と言って良いほど巨大化していました。ですので開発は機能単位で独立して進んでいましたし、その何か一つの機能をボトルネックと言い切ることはできません。この障害でもまさにそうで、初動調査をする際にも「これ！」と言って当たりをつける事はできませんでした。
そこで当時のサービス開発グループとたんぽぽ開発チームでは、設定によって各機能ごとに制限をかけるサービスアクティベーションという機構を一部に実装していました。サービス開発グループのエンジニアはそれによって縮退の設定をし（おそらくまともに動かしたのはその時が初めてだったのではないでしょうか…）、影響箇所を見ながらリリースを行っていきました。
私は何をしていたか？
私は主に初動調査、復旧検討にあたりました。
当時のmixiでは今でいうNew Relicのようなプロファイリングツールが日常的には動いていなかったため、たんぽぽ開発チームやアプリ運用チームの皆でサービスインしているホストを一つずつ割り振って、各々でプロファイリングやコアダンプ、TCPキャプチャリングなどをやってみる所から入りました。
ですが正直な話、私は少しも役に立ちませんでした。
今では開き直って話すこともできるようになったのですが、私と周りの面々との間には、技術レベルに大きな開きがあったのです。
コアダンプのバックトレースやTCPキャプチャリングをしてもなぜそうなっているのかがわからず、勘所が全く掴めなかったので、仕方なくサービスのPerlコードにあたりをつけようとNYTProf（プロファイラ）を仕込んで、別のボトルネックや問題に影響を与えている箇所がないか探ろうと必死になりました。しかしこの時の障害ケースにおいては、そのような調査はほぼ意味がなかったのです。
障害が発生したその日の夜、定時後も残って調査と対応を行っている皆のためにマネージャが出前をとって釜飯を振舞ってくれました。が、力不足を痛感して噛み締めながら食べるご飯はしょっぱくて美味しく感じられなかったのを覚えています（決してまずかった訳ではなく）。
ーーーー
その後、２度、３度に渡って問題の解消作業を進め、翌々日深夜には完全復旧しました。主に使用しているOSのKernelパラメータ変更の反映と、memcachedを利用している一部箇所の改修、および復旧スクリプト複数の計画的な実施による対処だったと記憶しています。
振り返って思うこと
ここまで、かすかな記憶を頼りに当時の障害を振り返ってみました。
後半はだいぶ主観的でしみったれた回想となってしまい申し訳ありません。ですが最後に少しだけ、その当時の体験等から学びとしたいことを挙げて締めたいと思います。
未知の問題に挑む機会を得る
障害対応は予測できていない状況がほとんどです。普段であれば安定して稼働しているストレージやRDB、ミドルウェア、ネットワークであっても、いつ認識していない閾値を超えてボトルネックになるかわかりません。アプリケーションコードについても同様です。予測できないのって、こわいです。
その上で私が常に意識していたいのは「これまで対処した事もないような問題に遭遇できるチャンスと捉える」です。
苦手意識を持ちすぎず、障害が起きたらすぐに頭や手が動く状態を維持するためにも、ポジティブな捉え方は必要だと考えています。
同僚の対応から学ぶ
私は幸運にも、これまでにいたどの環境でも優秀な同僚に恵まれました。今回お話しした障害についてもまさにそうで、周りの面々の迅速な対応や優れた知見に多く触れる事となりました。それはやはり障害対応の現場にいた（参加できた）からこそ、強く感じられるのだと思っています。
様々な役割がある事に気づく
例えば障害の解決そのものは一人の作業で行える程度のものだったとしても、関係者に状況を報告する必要があるかもしれません。または対処に使うスクリプトが複数だったり、実行しながらグラフの監視もする事だって多いでしょう。そういった状況では一人だけが対応するよりも二人、三人で役割を分担した方が確実に負担が軽減します。障害対応は基本的に「いかに一人の負担を軽減するか」がキモです（間違いありません）。
これは捉え方を変えると、仮に障害内容がハードで、自分の力が足りず問題解消に至れなかったとしても、探せば何か協力できる事があるかもしれない。障害対応における役割そのものは無くならないという事です。
さいごに
ここまで読んでくださった方には、とりとめなく稚拙な文章にお付き合いいただき、本当にありがとうございました。
以上が、SRE のバイブルは分厚く内容が非常に濃いため、まだ断片的にしか読めていない…
そんな私による障害体験談でした。
現在ではサービスを運用する環境も当時と大きく様変わりしているため、今回お話しした内容が何かの参考になることはないと思いますが、「あの当時はこんな事があったんだな」程度に感じて、少しでも懐かしんでいただければ幸いです。
明日は @henteko さんのエントリーとなります。
私は冬コミには参加した事がないのですが、一体どんな内容になるのでしょうか…？
それでは引き続き ex-mixi Advent Calendar 2017 をお楽しみください！