インフラチームの負荷軽減と品質向上の両立へ自動化を決意
gumiがインフラの自動化に取り組んだ背景には、同社のインフラチームならではの組織構成があった。gumiのインフラチームは横断部署として位置付けられ、社内にあるすべてのゲーム開発プロジェクトに対してインフラを提供している。
こうしたプロジェクト横断型のインフラ供給体制のメリットには、「会社全体のインフラ品質が一定に保たれる」「管理が簡単で、問題の展開もすぐに行える」「新技術や成功事例をすぐに横展開できる」といったメリットがある。しかしその一方、インフラチームに業務負荷が集中してしまいがちで、チーム規模を拡大することもすぐには難しかった。そんな中、この課題を根本的に解決するために、インフラの自動化に踏み切ることになったのだ。
では、自動化すべきオペレーションとは具体的にどのようなものがあるのだろうか。
gumiでは創業時からAWS（Amazon Web Services）を業務で利用しており、この上で動くインフラ（AWSリソースとミドルウェア）の構築・更新がインフラチームのメインとなる業務だ。例えば、負荷に応じたEC2インスタンスの増減や一時的な検証環境、エラートラッカー、ロギング、そして監視・通知設定などである。
この程度ならば手作業でも問題ないように思える。しかし2018年2月時点で、社内には「10以上のプロジェクト」「20以上のAWSアカウント」「70以上の開発環境」そして「1200以上の監視対象」が存在している。これを3.5人のインフラチームで管理しているのだ。
ここまで来ると、とても人力による管理では追いつかない。自動化は必然の帰結であり課題だった。中島氏は「自動化されていない部分が運用のボトルネックになる。開発コストとのバランスを検討する必要はあるが、完全な自動化を目指すことで、1割の手作業を残すような妥協を避けたいと考えました」と話す。
NoOpsの実現を目標に自動化ツールを開発
gumiが開発した自動化ツールは「gdwarf（ドワーフ）」と名付けられている。ちなみに頭の「g」はgumiの頭文字だ。
このツールで目指すのはインフラ開発・更新の作業におけるNoOpsの実現だ。NoOpsとはすなわち、「インフラに関するOps（運用）を一切行わない」ことを意味する。
「とはいうものの、さすがに何もしないというのは無理なので、『インフラ構成のコードを書いてgdwarfを実行する。それ以外のOpsをゼロにする』ことを現実的なゴールと設定しました」
gdwarfはミドルウェア設定とAWSリソースをターゲットとするが、これだけならばAnsibleやAWS CloudFormationでも可能だ。あえてオリジナルツールを開発した理由の一つには、インターフェースの問題がある。
というのも、使用ツールは変更される可能性があり、それによって使い方や手順が変わるとオペレーションも変更する必要があるからだ。これではいつまでたってもNoOpsが実現できない。
「しかしgdwarfで既存のツールをラップしてしまえば、ツールをいくら切り替えたとしても同じオペレーションが維持できるようになります。また、インターフェースがしっかり決められていれば、社内配布やCI（継続的インテグレーション）環境へも組み込みやすいといったメリットがあります」
さらに手作業で行ってしまいがちな「複数ツールの実行」と「AWSとその他のサービスとの連携」も、gdwarfで自動化している。コードからインフラを構築・更新できるようにするのはもちろん、あらゆる手作業を拾い出して自動化していくという、徹底した方針が採られているのだ。
もちろん一方では、どうしても自動化できない、または自動化が難しい部分もあった。その代表的なものが「緊急対応・障害対応」だ。こちらはスピードが第一条件なので、どうしても手作業で対応せざるを得ない。その場合は、手作業で行った修正をコードに反映してインフラをリビルドする。
「同様の緊急事態が起きた時に、これら一連の対応プロセスをいかに効率化するかが次の課題になります。また、この他にもAPIが存在しない場合や、メールなどによる承認作業が必要なプロセスをどのように自動化していくかも課題としてあり、現在解決方法を検討しています」
インフラ運用におけるエンジニアの作業負荷が大幅に軽減
gdwarfをインフラ業務に導入した結果、当初の目的だった自動化に関しては一定の成果があがっている。
gdwarfはソーシャルゲーム開発でよく使う構成をモジュール化している。YAMLにモジュール名を追加するだけで、一度に複数のCloudFormationテンプレートを呼び出し、環境を構築することができる。
例えばインフラの追加が必要になった場合、これまでは「（1）アプリケーションエンジニアからインフラエンジニアに開発を依頼」→「（2）インフラエンジニアが手作業でAWS上に構築」→「（3）でき上がったところにアプリケーションエンジニアがデプロイ」といった手順を踏まなくてはならなかった。
これがgdwarfを導入した結果、インフラエンジニアの作業負荷を画期的に減らすことができた。（1）と（3）は変わらないが、手作業で行っていた（2）はYAMLを少し編集するだけで済むのだ。YAMLを編集するとgdwarfがAWS上に新しいインフラを自動構築してくれるので、アプリケーションエンジニアはこれまで通りアプリケーションをデプロイすればいい。中島氏は「今後、このYAMLを書くプロセスも自動化したい」と明かす。
「そのために、この部分をWebアプリ化できないか検討中です。そうなればアプリケーションエンジニアが依頼を出すだけで、インフラエンジニアが介在することなくインフラの自動構築が実行できるようになります。やがてgdwarfは単なる自動化ツールではなく、当社におけるインフラ管理のためのPaaSのレベルに到達できるでしょう」
3つのスローガンと共に、NoOps実現に向けてこれからも前進
最後に中島氏は、まとめとして3つのNoOps実現のためのポイントを紹介した。
オリジナルの自動化ツールを作れ！
既存のツールやサービスだけでは、すべてのオペレーションはカバーできない。しかも、そのオペレーションはチームや会社によって異なってくる。もしインフラの効率化を図ろうと考えるならば、自分たちに最適化されたツールを作らざるを得ない。これまでは主にオペレーションを手がけてきたエンジニアも、これからはコードを書き、自分たちに必要な自動化ツールをどんどん開発したほうがいい。
インフラはモジュール化せよ！
インフラをモジュール化することによって、低コストでいろいろな環境・構成を組めるようになる。また新しいサービスや構成が必要になった際も、その新しい部分だけを追加作成して適用が可能、つまり最低限の実装や変更で済ませることができる。このモジュール化の考え方は、CloudFormationやTerraformといった既存のツールを直接利用する場合にも有効だ。
インフラ自動化はPaaSを目指せ！
インフラの自動化を突き詰めていくと、最終的にはPaaSに到達することが自分たちの経験から分かった。これから自動化に取り組む場合は、PaaSにすることを念頭に置いた上で、ツールやライブラリ、サービスなどを作っていくとより良いものが実現できるのではないか。
中島氏は「私たちgumiもまだ、PaaS化を実現できたわけではありません。これからもこのゴールを目指して努力していきます」と抱負を語り、セッションを終了した。
お問い合わせ
株式会社gumi
