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で管理しており、インフラチームの担当領域。この上に乗るコンテナは開発チームの担当領域となっているそうだ。
