Case Study
株式会社MIXI
モンスト運用メンバーの3人。左から小池知裕氏、佐藤良祐氏、白川裕介氏
村瀬龍馬氏 執行役員 CTO
白川裕介氏 モンスト事業本部開発室室長
佐藤良祐氏 開発本部XFLAG事業推進室SREグループ
小池知裕氏 開発本部XFLAG事業推進室SREグループ
世界累計利用者数4,500万人を突破（2018年3月現在）した株式会社MIXIのXFLAGが提供するスマホアプリ「モンスターストライク」（以下、モンスト）。2018年10月に開催した「モンスターストライク5周年感謝キャンペーン」や、期間限定で魅力的なキャラクター達とのコラボレーションともなれば、通常の数倍ものレベルにアクセスがスパイクする。このアクセスに応えるのは、綿密な評価検証によってクラウドセンターとの通信遅延を最小にしつつ、負荷に合わせて柔軟にインスタンスを増減させるように設計された、マルチクラウド併用のシステムだ。人気のオンラインのゲームは巨大で複雑なシステムの24時間運用が求められる。システムトラブルでのサービス停止は即事業インパクトへとつながる。その巨大インフラ、システムの運用にPagerDutyを活用しているSREチームのエンジニアに使用感を尋ねた。
―モンストはどんなシステム、どれくらいの規模で運用していらっしゃるのでしょうか？
村瀬：オンプレミスにデータベースとストレージ、アプリケーションサーバの一部などがあり、さらに負荷に応じて増減するクラウド上のアプリケーションサーバを組み合わせています。特に気を配っているのは、データベースとクラウド事業者の距離、レイテンシーを小さくすることです。アプリケーションサーバとデータベースサーバ間の往復が多い場面では、レイテンシーが大きいとユーザーさんが待たされてしまいます。そのため極力センター間のレイテンシーが小さくなるように複数のクラウドを比較しつつアプリケーションサーバを配置しています。
小池：オンプレミスとクラウドのハイブリッド運用は他社でも比較的事例がありますが、2つ以上のクラウドを併用するマルチクラウドでの運用は、私たちが自信を持っているところです。
白川：実は今日、新たなコラボのイベントをちょうどスタートしたところなんです。イベントが始まるとアクセスが急増するので、イベント期間中はアプリケーションサーバをクラウド上に100台単位で、通常時の2倍くらいに増やします。
佐藤：マルチクラウドにする理由には、調達の都合ということもあります。イベントで100台どかっと取りたい時に、1つのクラウドで一気に100台はちょっと取れないというときもあるので、複数のところを使って増やせるような運用方針になっています。
―PagerDutyはどのような経緯で導入されたのでしょうか？
小池：2015年に繁体字版モンスト（香港・マカオ版）ローンチに伴い導入したのが最初です。使いやすかったので、日本リージョンやほかのプロダクトでも使うようになりました。以前はアラート発生時に監視ツールからメールを担当者に送信して通知していたのですが、問題もいろいろあって、もっとうまくやりたいと思っていました。
エスカレーションレベルの頂点にいる執行役員 CTO の村瀬龍馬氏。さすがにこのレベルまでエスカレーションされることは少ないという
村瀬：使用しているクラウドが１つであれば、それぞれの監視サービスで監視していればいいのですが、マルチクラウドの運用では何か監視ツールを使って全体を取りまとめる必要があります。ただ、対応する人へ送るメールや電話に繋げるような仕組み、エスカレーションなどの機能を持ったものを自分たちで保守するのはかなり大変なので、それを包括的に扱えるのがPagerDutyの良いところです。
白川：弊社ではコミュニケーションツールとしてSlackを使っているんですが、サービスの企画運用部門のメンバーが、急遽夜中にサーバサイド・エンジニアのメンバーを呼び出したいというときなど、特定のコマンドをたたくと、それらのメンバーにアラートが飛んで呼び出されるという仕組みになっています。
―すると、エンジニアだけではなく、モンストのプロジェクトに関わる人との連携にも使われているのですね。
―モンストの運用体制はどのようにしているのですか？ PagerDutyはどんなふうに使われているのでしょう？
小池：いまは、NagiosやCloudWatchなどの監視ツールが問題を検出すると、PagerDutyのAPIを通してイベントをポストするようにしていて、アラートが運用チームに通知されます。
白川：ウチは、開発も運用も全部みんなでやりましょうという体制で、垣根がないんです。どちらかだけの人も、両方やっている人もいます。弊社全体ではエンジニアは200名くらい、外部を合わせるとその倍くらいいるのですが、モンストの運用にかかわるメンバーは、日本版、海外版合わせて十数名。このメンバーで、インシデントに24時間対応できるように、日本版、海外版それぞれでアラートを最初に受けるオンコール当番をローテーションしています。このオンコールのスケジュール機能がすごくいいんです。
小池：当番は2人1組で1週間、1か月に4組という仕組みで運用していますが、それらの当番スケジュールを自動生成できるのが便利です。
村瀬：月に1回くらいのアップデートメンテナンスの時も、ローテーションの割り当てを一時的にメンテナンスの時間分だけ上書きして、当番に通知が行かないようにする、代わりにメンテナンスメンバーに通知が行くようにする、そういうことが簡単にできます。GUIで簡単にできるところも良いですね。
―スケジュールはGoogle Calendarにもエクスポートできて便利なんですよ。エスカレーションポリシーは活用されているでしょうか？
白川：エスカレーションは3段階で設定していて、ファーストラインの2人がたまたま対応できない場合、5分後に2段階目の人が呼び出されます。3段階目は役員の村瀬で、そこまで行くことはまずないのですが。
奇しくも取材は、アクセスが急増するコラボイベントの開始直後。さっそく佐藤氏のスマホにアラートが。すぐにAck（対応の意思表示）を返し、ノートPCのWebを覗きこむ同氏。PagerDutyのスマホアプリでアラートが鳴ったあと、5分以内にAckを返さなければ追いかけて電話がかかってくるように設定するなど、アラート通知の受け取り方はメンバー各人の設定にまかされている
小池：問題はほとんどファーストラインで解決しますが、専門の担当者へのエスカレーションというより、2人では対処がたいへんなときに2段階目の助けを呼ぶことがあります。
佐藤：障害が大規模になると、さすがに夜中の2時に2人で作業をするのはたいへんなんです。そういう時には、エスカレーション機能でみんなを招集して、対応にあたります。ボタンをひとつ、ポチッと押すだけでみんなを招集できるのがいいですね。
―コンファレンスブリッジという機能で、何か問題が起きたときにボタンをポチッと押して会議を招集できますので、そちらも使いやすいかもしれません。今後も便利な機能を紹介していきますので、どうぞご期待ください。
小池：イベント等でアクセスがスパイクすると、システム全体でワーニングやアラートが、一気に数百件というレベルで押し寄せることもあります。
―そんなときはアラートのグルーピングという機能を使って、同じインシデントからのアラートを1つにまとめてしまえばいいと思います。同じ瞬間に発生した複数のアラートを自動的にまとめる方法と、人手でこれとこれは同じ原因なので1つにすることをPagerDutyに教えてやる方法とがあります。あとはPagerDutyが機械学習を使って勝手に賢くなって行きます。
