SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2018】セッションレポート(AD)

自社開発ツールでNoOpsを目指せ! インフラ運用を自動化し、作業の負荷軽減と効率化を実現【デブサミ2018】

【16-B-6】NoOpsを目指すgumiのインフラ自動化ツール

  • X ポスト
  • このエントリーをはてなブックマークに追加

 ビルドツールなどで自動化が進む、クライアントやサーバーアプリケーションの開発。しかし、インフラはどうだろうか。あらかじめコード化されていたり、必要に応じて環境をすぐに構築できたり、インフラの更新をコードベースで実行できたりするだろうか。多くのソーシャルゲームの開発・運用を行う株式会社gumiでは、それらを支えるインフラ環境が相当なボリュームとなっている。しかしAWS CloudFormationやTerraform、Ansibleといった既存のツールのみでは、大規模なインフラの設計・開発・運用は難しい。この課題を解決すべく、同社はインフラ自動化ツールを独自に開発。ツールが自動的にAWS上にインフラを構築してくれるようになった。その取り組みを、同社の中島孝雄氏が解説した。

  • X ポスト
  • このエントリーをはてなブックマークに追加

株式会社gumi Technical Strategy & Development 中島孝雄氏
株式会社gumi Technical Strategy & Development 中島孝雄氏

インフラチームの負荷軽減と品質向上の両立へ自動化を決意

 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でも可能だ。あえてオリジナルツールを開発した理由の一つには、インターフェースの問題がある。

gdwarfはミドルウェア設定とAWSリソースを対象としている
gdwarfはミドルウェア設定とAWSリソースを対象としている

 というのも、使用ツールは変更される可能性があり、それによって使い方や手順が変わるとオペレーションも変更する必要があるからだ。これではいつまでたってもNoOpsが実現できない。

 「しかしgdwarfで既存のツールをラップしてしまえば、ツールをいくら切り替えたとしても同じオペレーションが維持できるようになります。また、インターフェースがしっかり決められていれば、社内配布やCI(継続的インテグレーション)環境へも組み込みやすいといったメリットがあります」

 さらに手作業で行ってしまいがちな「複数ツールの実行」と「AWSとその他のサービスとの連携」も、gdwarfで自動化している。コードからインフラを構築・更新できるようにするのはもちろん、あらゆる手作業を拾い出して自動化していくという、徹底した方針が採られているのだ。

 もちろん一方では、どうしても自動化できない、または自動化が難しい部分もあった。その代表的なものが「緊急対応・障害対応」だ。こちらはスピードが第一条件なので、どうしても手作業で対応せざるを得ない。その場合は、手作業で行った修正をコードに反映してインフラをリビルドする。

 「同様の緊急事態が起きた時に、これら一連の対応プロセスをいかに効率化するかが次の課題になります。また、この他にもAPIが存在しない場合や、メールなどによる承認作業が必要なプロセスをどのように自動化していくかも課題としてあり、現在解決方法を検討しています」

次のページ
インフラ運用におけるエンジニアの作業負荷が大幅に軽減

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
【デブサミ2018】セッションレポート連載記事一覧

もっと読む

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/10715 2018/04/03 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング