Infrastructure as Codeが運用の属人化を防ぐ
左近充氏はまず、ブロードリーフで使用しているインフラ環境の詳細について解説する。同社はGCP、AWS、オンプレミスなど複数のプラットフォームを利用してサービスを提供している。
構築している環境は主に「dev（開発）」「stage（ステージング）」「prod（本番）」の3つ。これが各プロダクトやプロジェクトごとに存在しているため、トータルの環境数は何十もの数になるという。また、使用しているサービスやミドルウェア、ソフトウェアは下図のとおりだ。
インフラのチームの人数は5名（東京3名、福岡1名、札幌1名）。これほどの規模のシステムを、5名で管理するのは大変なことだ。うまくシステムを運用するには、少人数で多くの環境を管理するための仕組みが必要である。それこそが、Infrastructure as Code（IaC）だ。
「ブロードリーフのインフラチームは、ここ数年間でIaCに注力してきました。IaCとは、ソフトウェア開発のプラクティスをインフラのオートメーションに生かすアプローチのこと。コードによるインフラの管理を行うことで、インフラ構築の冪等性を担保し、自動化を可能にします。作業の属人化が排除されますし、作業工数も削減できるのです」（左近充氏）
ブロードリーフではIaC実現のためのツールとして、パブリッククラウドのリソースにはTerraformを、OS以上のレイヤーにはAnsibleを、サーバーイメージのパッケージングにはPackerを使用している。
また、仮想マシンのデプロイのために、CI/CDパイプラインによるイメージの構築を行っている。開発チームがGitLabにモジュールをコミットするだけで、デプロイが可能になっているという。処理フローは以下のとおりだ。
- 開発者がデプロイしたいモジュールをGitのリポジトリにコミット
- パイプラインがキックされ、TerraformやAnsible、Packerが入ったリポジトリからパイプラインを起動
- Workerのインスタンス上で、アップされたモジュールを使って新しいAMIを作成
- 新しく作ったAMIからインスタンスを作成してスケールアウト
- 古いインスタンスを削除してスケールイン。新規作成されたインスタンスだけが残る（ただし本番環境の場合は、スケールアウトとスケールインは事故防止のためマニュアルでパイプラインを実行している）
コンテナのデプロイの場合は、GKE（Google Kubernetes Engine）やAmazon EKSなどのパブリッククラウドはTerraformで管理しており、インフラチームの担当領域。この上に乗るコンテナは開発チームの担当領域となっているそうだ。
より価値の高い仕事に人間がフォーカスできるように
左近充氏は、インフラチームが行っている他のプラクティスについても解説する。まずはコーディングについて。少人数ということを活かし、ブロードリーフではモブプログラミングを採用している。
モブプログラミングとは、チーム全体が同じ場所に集まり、同じコンピュータを使って作業をするソフトウェア開発のアプローチだ。ブロードリーフでは東京、札幌、福岡とそれぞれの拠点が離れているため、音声のやり取りにGoogleハングアウトを、ソースコードの共有のためにVisual Studio LiveShareを使用している。
モブプログラミングの利点として、左近充氏は「プログラムの品質が向上すること」を挙げる。リアルタイムで他のメンバーに見られていることで、「より良いコードを書かなければ」という意識が生まれるためだ。作業中に全員のレビューを受けているのと同じ状態になるため、別途レビューをする必要もなくなる。教える方も教えられる方も学ぶことが多く、チーム全体のスキルも上がる。
また、開発スピードを落とさないための工夫も存在している。ブロードリーフでは、本番環境以外はインフラチームのメンバー以外でもクラウドリソースを触ることができる。ベストプラクティスとしては、すべてのインフラ変更を厳密にIaC管理するべきだが、現実的にはその運用は難しいためだ。だが、この方法には課題がある。Terraformは状態を保持しているため、手作業でクラウドリソースを修正した場合には設定の差分が出てしまうのだ。
ブロードリーフではその課題を、既存のインフラリソースからTerraformのコードを生成してくれるTerraformingやTerraformerなどを用いて解消している。さらに、現環境とIaCの差分を自動的にSlack通知してくれるSlack Botも存在している。通知内容を確認することで、こまめにIaCをメンテナンスできる仕組みが確立されているのだ。
「なるべくマネージドサービスを使い、環境やツールを自作しない」という方針も徹底しているという。何かを自作すると、バージョンアップ対応や脆弱性対応など必ずその後のメンテナンスが必要になってしまうためだ。マネージドサービスを使うことで、運用工数を最小化できる。
また、「チームメンバーが思い思いにCronJobを仕掛けると、どのサーバーで何が動いているかわからなくなる」という課題を解決するために、OSSのジョブ管理ツールであるRundeckを導入したという。RundeckはGUIやAPIを介してジョブの作成や実行、管理、スケジューリングを行える。多種多様なプラグインも存在しており、機能拡張も容易だ。
さらに、適切な運用を行うため、アラート通知の見直しも行った。以前は、ありとあらゆるアラートをすべてメールで通知していたそうだ。その結果、「朝起きると70、80件もメールが来ていたが、ひたすらアーカイブしてみると結局どれもサービス影響はなかった」という事態が多発していたという。まさにメール地獄である。
監視において重要なのは「本当に必要な情報だけを通知すること」だ。狼少年のようなアラートは、必ず無視されるようになってしまう。人が対応する必要のない異変については、データを収集するのみで通知はしないというルールを徹底すべきなのだ。
最後に、左近充氏はセッションをこう総括した。
「IaCはあくまで『手段』です。ツールで解決できることはツールでやって、人間がより価値のある仕事にフォーカスできるようにすることが目的です。例えば、先端技術の検証・導入、ミドルウェア・クラウドの理解向上、可用性・信頼性の向上、コスト削減などに時間を割くべきです。
そうすれば、さらに業務を効率化して、できることを増やして強くなり続けることができます。IaCを使って不要な心配や失敗をなくして、必要な失敗だけをしてチャレンジし続けられるチーム。これこそ、『ぼくのかんがえたさいきょうのいんふらちーむ』となります」
お問い合わせ
株式会社ブロードリーフ
- コーポレートサイト
- 問い合わせメールアドレス： j.event@broadleaf.co.jp
