- 講演資料：今どきのインフラはペットでは無かった（左近充裕樹氏）
- 講演資料：Spring Bootでマイクロサービス作って苦労したお話（松本宏紀氏）
データセンターのハード更新を好機にIaCの実践へのチャレンジを決意
ブロードリーフがInfrastructure as Codeの実践にチャレンジするきっかけとなったのは、データセンターのサーバーの老朽化だ。左近充氏はそれ以前を振り返って、「当社のオンプレミスの暗黒時代だった」と明かす。
左近充氏が担当になった時点で、すでに構築当時を知る社員は残っておらず、協力会社のベテラン社員に聞いては立ち上げ時の状態を推測していたと言う。また長い間にハードウェア構成が変更され、ベンダーから来た資料と微妙に合わない。緊急対応などで増改築を繰り返した部分も多く、実際の構成を知るには、そのつど現地調査に赴かなくてはならなかった。
「必要なドキュメントがなくブラックボックス状態になっていた上に、当時を知るメンバーが抜けて情報が薄くなっており、まさに"水をつぎ足した秘伝のタレ"のようなありさまでした」
そうしたある日、2か所あるデータセンターの一方のハードウェアが老朽化し、パブリッククラウド（AWS：Amazon Web Services）への移行が決定した。これをインフラチームでは千載一遇のチャンスととらえ、「昨今話題のInfrastructure as Code（IaC）を取り入れようと決めた」と左近充氏は言う。
改めて言うまでもないが、IaCとはシステムのインフラ設計をコードとして記述し、プロビジョニングと構成・設定および変更の自動化を含む、インフラ構築の効率化を図る手法だ。左近充氏は、「人力では避けられないオペレーションミスを回避する上でも、IaCは極めて有効な手段です。このとき参考にした書籍（注1）の、『サーバーはペットではなく畜牛のように扱え』～従来のように大事に維持するのでなく、目的に応じてどんどん使っていけ～という言葉は、プロジェクトを進める指針になりました」と語る。
IaCのサーバーは、畜牛のように目的に応じてどんどん使うもの
注1
『Infrastructure as Code―クラウドにおけるサーバ管理の原則とプラクティス』（オライリー・ジャパン刊）による。
TerraformとAnsibleを組み合わせ、すべてコードで管理できるまでに進化
今回のサーバー移行では、2つのデータセンターを順番に移行していった。最初の移行でインフラ構成管理ツールとして採用されたのが、HashiCorp社のOSSであるTerraformだ。選択理由としては、「（1）Go言語で書かれており、Windows／Mac／Linuxのどれでも動作する」「（2）AWS、Azure、GCP（Google Cloud Platform）、OpenStack、Herokuなどさまざまなプロバイダが提供されている」といった点が挙げられると左近充氏は言う。
「特に注目したのは、OSSでありながら開発が非常に活発なことです。試しに私がイシューを上げてみたところ、1か月もしないうちに修正されるなど、開発のスピード感が感じられました。また同じ構文を異なるプロバイダのパブリッククラウドに適用できるので、ベンダーロックインが避けられるメリットもあります」
1回目の成果をもとに、次のデータセンター移行では、インフラ構成管理ツールにHashiCorp社のOSSであるPackerを採用。また別の新規商材（Webアプリケーション）のインフラ開発ではクラウドプラットフォームにGCPを使うなど、ツールやプラットフォームを変えながら挑戦を重ねた。現在ではOS以上のレイヤのプロビジョニングまでを含む全インフラを、TerraformとAnsibleを組み合わせて、すべてコードで管理できるまでに進化しているという
「この次は自動復旧を目標に、自律型システムの実現を目指していきたいと考えています。これからIaCにチャレンジする方は、前例がないといった批判なども受けると思いますが、経験がないことにPDCAは通用しません。未経験のことをPlanするよりも、いち早くDoを実践することでPlanの糸口もつかめるようになります」
