インフラチームの負荷軽減と品質向上の両立へ自動化を決意
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が存在しない場合や、メールなどによる承認作業が必要なプロセスをどのように自動化していくかも課題としてあり、現在解決方法を検討しています」
