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