インフラ運用におけるエンジニアの作業負荷が大幅に軽減
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
