システムの課題を解決するために開発、運用を行うSRE
国内版・モンストのインフラはデータセンターとクラウドから構成され、オンプレミスのサーバーマシンだけでなく、クラウドのインスタンスでもサービスのトラフィックを処理している。データセンターの運用を簡易化するため、導入するサーバーはハイスペックのデータベース（DB）用と低価格のmemcached用の2種類に限定。クラウドと2カ所のデータセンターはプライベートネットワークで接続されており、データセンターの一方が障害によりアクセスできなくなったとしても、もう一方にアクセスして短時間で復旧できるように冗長構成をとる。
モンストのアーキテクチャはオーソドックスな構成だ。グローバルIPアドレスを持つロードバランサーがAPIリクエストを受け、アプリケーションサーバーに振り分ける。アプリケーションサーバーはDB、memcached、Redisにアクセスし、ユーザーへのレスポンスを作成する。非同期処理はワーカーノードに分散され、ログ収集はfluentdにより行う。
現在、オンプレミスでは約1,400台のサーバーが稼働している。そのうち、DB用はバックアップ用を含め約300台、アプリケーションサーバーは10,000コアを数える。memcached用は約90台で2テラバイトのプールを2つ作成して冗長構成をとり、ピーク時には秒間600万回ものオブジェクト取得リクエストを受けている。
アプリケーションの開発言語はRubyで、フレームワークはRuby on RailsではなくPadrinoをActiveRecordと組み合わせて使用する。DBはMariaDB、メッセージキューはRedisを利用するResqueを用いている。
伊藤氏はモンストのインフラについて一通り触れたあと、SREがどのような役割を担うかを説明した。
SREは「Site Reliability Engineering」の略であり、システムの信頼性向上やトラブル対応を主なミッションとする。運用業務の一部も担うが、その割合は企業によって異なる。有名なGoogleのSREチームは5割未満、XFLAG スタジオでは人によって異なり20～70％だという。インフラチームとは運用を主業務としないことで一線を画する。システムの運用上の課題をソフトウェアエンジニアリングで解決するため、SREでは開発と運用を明確に分けていない。その意味では呼び名が異なるだけで、DevOpsと同じといえる。
XFLAG スタジオでは、国内版、海外版といったリージョンごとにサーバーサイドアプリケーションが異なるため、かつてはそれぞれ完全に独立したチームが運用していた。2016年7月、各リージョンからインフラ周りを得意とするエンジニアが集まりSREグループを結成。現在は8名が所属している。特徴的なのは（組織上は存在するものの）実質的なマネージャーを配置していないことだ。課題やタスクを特定のメンバーに依頼するのではなく、それぞれのメンバーが自主的に引き受け、それ以外の作業については基本的に各メンバーに任されている。SREグループのアウトプットは個人プレーにより成り立つが、組織としてばらばらにならないようにざっくりとした方向性が示される。
XFLAG スタジオにおけるSREのミッションの一つに、急増するトラフィックに対応できるようにすることが挙げられる。イベント開催時、トラフィック量は通常時の数倍にも膨れ上がる。急増時にもトラフィックをさばけるように、アプリケーションの実装とインフラの両面から対応するのがSREの仕事だ。それ以外にも、データセンターの作業やアプリケーションのデプロイまで、サーバーサイドに関わる作業はすべてSREの担当となる。
XFLAG スタジオでは、システムの障害に対応するため、2人1組の当番体制を整えている。アラートが発行されてから20分以内に対応できるように、当番中は常にオンラインで待機することが求められる。アラートの発生件数は、2017年では1週間あたり最多で11件、最少で0件、平均すると3.9件だった。アラートのシステムにはPagerDutyを採用しており、監視ツールからPagerDutyを経てアラートが発行され、当番に通知される。自分だけでは対応できない場合、PageDutyにエスカレーションを要求すると、当番プール内の全員に通知が届く。万一深夜に重大なインシデントが発生した場合は、全員で対応することになる。
伊藤氏は「モンストの規模拡大によって、インフラ周りに強いエンジニアへのニーズが大きくなり、必要に迫られてSREグループができた」と、その背景を明かした。そして、結成して1年が経過した今、SREを介すことでインフラ周りの知識や知恵がプロダクトを横断して展開しやすくなったと評価している。
