システムの課題を解決するために開発、運用を行う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を介すことでインフラ周りの知識や知恵がプロダクトを横断して展開しやすくなったと評価している。
サービスを止めずにDBのシャーディング、gemライブラリを改造――2つの事例紹介
伊藤氏は、XFLAG スタジオにおいてSREグループが実際に関わった事例を紹介した。
まず、DBの水平分割（シャーディング）の事例である。更新頻度が高く負荷が増大したDBを、シャーディングにより8分割することになった。サービスを止めないために新しいシャードを作成し、アプリケーションではデータの更新時に旧DBと新シャードに対して二重に書き込みを行い、さらにスクリプトにより旧DBから新シャードへ既存データをコピー。そしてコピー後に検証を行うといった手順で実施した。19日間かけてコピーと検証を行った結果、14億件のうち、検証で問題があったレコードを10件程度に抑えることができた。
この事例でSREは、サービスを動かしながらデータを二重に書き込む処理やデータのコピー・検証を行うスクリプトの実装を行い、さらにDBのキャパシティプランニング、DB用サーバーの用意、シャーディングしたDBへの切り替え作業、アクセス遮断のためのメンテナンス作業、不測の事態が発生したときの切り戻しの用意などを担当。また、関係各所とコミュニケーションをとり、メンテナンスの説明や調整を行った。
もう1つはキャッシュ活用の事例だ。モンストの構成はmemcachedへの依存度が高く、ユーザーが2回目にアクセスする際、基本的にDBへのクエリーは行われない。そのために複数のgemライブラリと独自のキャッシュ実装を組み合わせて使用していたが効率が悪く、memcached用サーバーの容量を無駄に使って台数が増える、アプリケーションとmemcached間のトラフィックが飽和直前といった問題が発生していた。
SREは容量の効率化とトラフィックの削減を図るため、使用しているgemライブラリの改造を実施。この際、サービス停止を招かないために移行中キャッシュプールを破壊しないように気をつけること、切り戻しを念頭に置くこと、既存のインターフェイスと互換性を持たせること、ライブラリの仕組みは説明するが内部の処理は隠蔽することなどに注意した。ライブラリは作って終わりではなく、使ってもらえなければ意味がない。そのため、ライブラリの機能を使う処理を実装したり、コードレビューで使い方を示したりといったことも行った。結果として、開発者から見ると機能は変わっていないが、内部ではキャッシュのシリアライズ方法を大幅に変えることでキャッシュを効率化し、容量面で約60％の削減を実現した。
あくまでSREがやりたいのは「事業」である
伊藤氏はセッションの最後に、SREグループが大事にしていることを3つ挙げた。
まず、「活用されるものを作る」ことだ。作るだけではその成果は3割にも満たない。機能を安全にリリースし、グラフやメトリックスに変化があって初めて意味のある成果となる。
次に、「自分たちの目標を達成することだけにこだわらない」点。SREのミッションを達成するために、機能追加を行わないのは本末転倒だ。機能がリリースされ、システムが変更された状態で、ミッションを達成しなければならない。そのためには直接的なメトリクスを指定しないなど、KPIの設定に気をつける必要がある。
3つ目は、「SREがやりたいのは事業である」こと。何があってもそれを妨げることはしない。新しい機能によってシステムの負荷が高くなるとしても、「事業にメリットをもたらすものであれば、全力で支える」と述べ、伊藤氏はセッションを締めくくった。
お問い合わせ
株式会社ミクシィ
