創業以来継ぎ足されたAWS環境をTerraformで統治した

estie VPoEの青木信(kirin_shi)です。

【プロフィール】青木信（あおきしん）
1991年生まれ横浜育ち。
東京大学数理科学研究科修士課程を修了後、2016年にアクセンチュアデジタル（当時）に入社。
"ビッグデータ"を軸足に、官公庁関連のデータ基盤刷新プロジェクト、小売業界のCRM基盤構築プジェクト、通信業界のグループ会社全体への機械学習プロジェクトなど複数の案件に従事。2019年11月よりestieへVPoEとして参画。
コロナ禍でとてもかわいいハリネズミのerizoと棲み始めた。

私は、2歳過ぎのハリネズミのerizoと暮らしています。ハリネズミは室温をかなり丁寧に管理してあげないと命の危険があるのですが、最近この仕組みを感温ヒーターとNature Remo連動のエアコンで冗長化したので、安心して眠ったり外出したり出来るようになりました。冗長化は安眠の元だなと感じます。

本記事では、AWS(Amazon Web Services)を中心とする既存クラウドインフラのIaC(Infrastructure as Code)化の取り組みについて、どのような戦略・設計で移行を進めてきたか、実際に移行してどのようなメリットを感じているかを書いてみます。

取り組みの必要性は感じつつ具体的なアクションに落とす所にハードルを感じている（1年前の私のような）方や、IaCを導入していて他社の設計や移行方針に興味がある方に、ピンとくるトピックだけでも読んでいただけると幸いです。

背景

事業上の背景

estieでは多くのクラウドインフラリソースをAWS上に構築しています。これらの多くのリソースは、創業初期から3年以上、スピードを重視しながらAWSのConsole画面上でポチポチと作り、必要に応じて過去試行錯誤しながら変更されています。このため、インフラリソースの設計は、場合によっては経緯を知らないと意図が伝わりづらいことがある状態となっており、保守運用作業と改善検討のバス係数を上げる為の障壁となっていました。

また、estieはマルチプロダクト戦略を掲げ、今後新規サービスを複数立ち上げる予定があります。（詳しくは以下の記事をご覧ください）

inside.estie.co.jp

この戦略に基づき2021年末時点で運用していた、estieとestie proに加えて、複数のサービスに向けたクラウドインフラの設計・構築が見込まれていました。

このような状況を踏まえて、既存のクラウドリソースを見通しよく管理し新規サービスの構築を加速するために、IaC化の導入を検討し始めました。

チーム体制

estieでは7月までSRE専任社員はいませんでした。 （マルチプロダクト戦略とサービス信頼性の重要度の変化に伴い、今年の年初より採用活動を初めて8月より念願の1人目SRE専任社員が入社しました！）

クラウドインフラに関連する設計開発・保守運用はVPoEの私が兼任するとともに、長く携わっていただいているフリーランスエンジニアの上水流さん（業務委託古参が estie について語ってみる - estie inside blog）と進めていました。副業として参画している2名のクラウドインフラ経験豊富なメンバにも協力していただき、相談しながら分担して作業を進めてきました。

移行の全体像

「ビジネス価値を生んでいるインフラリソースに再現性がある構築方法が用意されていること」を担保するため、2021年末から本格的にIaCの導入を進め、7月に大部分のビジネス価値を生んでいるインフラリソースに再現性がある構築方法が用意される状態となりました。合わせて、新規サービスについてもIaCのコードを基に高速に基盤構築が可能となりました。

IaCの全体方針の決定

IaCツールの選定

主にTerraform vs CloudFormationで比較検討し、以下の理由でTerraformを選びました。

Datadog、Auth0、部分的に利用しているGCP(Google Cloud Platform)等の設定も同一ツールで管理でき、学習コストを抑えることが出来る
フリーランスおよび副業で参画しているメンバがTerraformの方が習熟度が高かったため、将来性を考慮した設計がしやすく開発の初速も出しやすい

ディレクトリ構成

staging/production等の複数環境をTerraformで管理する方針については、大きく以下の3方針があり、各社毎にそれぞれの事情を踏まえてアプローチを選定している印象です。

Workspaceを利用する
State: Workspaces | Terraform | HashiCorp Developerを用いて、複数環境の設定をそれぞれ異なるWorkspaceとして管理する方針
Moduleを利用する
Creating Modules | Terraform | HashiCorp Developerを用いて、再利用可能なコードの塊をテンプレートとして定義し、Moduleを呼び出す側のコード(各環境に対応したディレクトリのコード）から環境差異を制御する方針
環境毎にディレクトリを完全に分離する
リポジトリのrootディレクトリ直下で環境毎に分離し、コードの共通化は実施しない

estieでは、副業のメンバの経験も生かしていただきながら実際にサンプルコードを書きながら検討し、「2. Moduleを利用する」の方針を採用しました。

他の選択肢を除外した観点

「3. 環境毎にディレクトリを完全に分離する」はスタート時点での学習コストは少し低いが、意図しない環境差異の温床となる
「1. Workspaceを利用する」は環境毎の設定差異が多い場合に、その制御の処理の記載が複雑となってしまう。 →Terraform公式でも、このようなstaging や productionなどの権限などの面で差異が発生することが多い複数環境を制御する用途は推奨していないようです。

State: Workspaces | Terraform | HashiCorp Developer

In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.

実際の移行の流れ

Terraform管理すること、どのようなディレクトリ構成に最終的に移していくかは決めたものの、「既存の大量のリソースをどんな順番で移行すれば良いのか」は少し悩みました。

何名かの有識者の方に聞いた上で、あまり順序を気にせずに好きなところから始めれば良さそうと判断しました。

estieでは、AWS設定を変更したい際に合わせてTerraform管理に移行することとし、順次改善したい内容ベースでTerraformへの移行を進めました。移行初期のフェーズでは、ごく一部のリソースがIaC化されているだけでなかなかメリットを感じづらかったですが、このような方針を採用したことで変更時のレビューや議論が進めやすいというメリットを実感しながら移行作業を進めることができ、結果として良い方針だったと感じています。

例えば、以下のようなプロジェクトでTerraformへの移行を進めました。

estie proのECS移行

EC2→ECS移行とVPC含めたネットワーク設計の見直しに合わせて、メインプロダクトの1つであるestie proの大部分のリソースをTerraform管理に移行するプロジェクトです
1年間ほど前に実施予定だったのですが、ごく一部のページだけエラーが出るという不可思議な障害を引いてしまい断念していたものに、改めて挑戦する取り組みでした
副業で参画している方に大部分を推進していただいたので、大変ありがたかったです。感謝

コーポレートサイトリニューアル

1月のコーポレートサイトリニューアルのタイミングで、EC2+Ansibleでの構築構成からCloudFront + S3をTerraformで管理する構成に変更しました
余談ですが、今回のリニューアルで、とても分かりやすく、かっこいいサイトになったので是非覗いてみてください
株式会社estie

PoCサービス向けのインフラ構築

複数のPoC段階のWebサービス構築に向けて、クラウドインフラ環境を複数用意しました
マルチプロダクト戦略を展開するにあたって今後も同様の対応は発生すると見込んで、GitHubのTemplate Repositoryを整備し、estieの標準的な構成であるWebサービスのAWSリソースを高速に準備できるようにしています

AWS以外のツールの移行

Datadog, Auth0といったサービスの設定もTerraformで同一の構文で管理できるため、Terraform管理に移行して再現可能な手順を用意しました
「Datadogのダッシュボードをインタラクティブにいじった後にそれをまたTerraformに乗せ直す」といった手間を軽減するため、原則サービス信頼性に関連する設定のみをTerraform管理とし、各チームがインタラクティブに構築したダッシュボードなどの設定はTerraform管理外としています

残作業の洗い出しと移行

ここまでで、大部分の移行を完了し、Terraformの取り扱い方の知見もたまってきたので、4月に「ビジネス価値を生んでいるインフラリソースに再現性がある構築方法が用意されていること」という目標を定めて、残りの作業を洗い出しました
IaC化することは手段であって目的ではないので、必ずしも「Terraformに移行する」ことにはこだわらず、サービスの性質に合わせて場合によってはドキュメントの拡充等の他のアプローチで再現性を担保する方針としました
Terraformのコードに落とし込んでいると手を入れて改善したいところなどはいくつか出てくるものですが、このステップでは「せっかくなのでインフラ設定をあるべきにしたい」という想いは一旦抑えてコードにコメントを残すだけにとどめ、まずは移行を進めて改善点を議論できる状態にすることを優先しました

移行して感じるメリット

このような流れを経て、やっと社内の「ビジネス価値を生んでいるインフラリソース」の大部分を移行完了しました。実際に移行された状態で運用してみると、当初予想していた以上のメリットを感じています。いくつか例を挙げてご紹介しようと思います。

Pull Requestベースで変更提案のしやすさ

現状のインフラ設計をコードベースで管理するようになったことで、各開発チームのSWEからも現在のインフラ設計を理解して、Pull Requestベースで変更を提案しやすくなりました。

実際に、各チームのメンバからアプリケーションコードの変更と合わせてTerraformの方もPull Requestを上げてもらうことも増えました。本格的に移行してから数ヶ月の間に10以上のPull Requestを受け取っています。

実際の SWE 活用例について、ぜひ以下ブログもご覧ください

inside.estie.co.jp

これらのPull Requestは、Repository OwnerであるSREユニットのメンバが、コードの一貫性の面での課題やセキュリティ面での懸念がないかをreviewしてからマージするような方針となっています。

ecspresso等のツールとの相性の良さ

estieではウェブアプリケーションやバッチ処理をECSで管理しています。これらのECS serviceやscheduled taskのデプロイ管理には、ecspressoやecscheduleというツールを活用しています。

これらの設定をYAML形式で記載する際、Terraform移行までは、subnetやsecurity groupのarnやid等をベタ書きして定義していました。ただ、当該Pull Requestの内容だけからは利用されているsubnetやsecurity groupがどのような意図で設計されたものか見えず見通しが悪い上に、インフラリソースを再作成した場合にはARNが変更されてしまうため、ecspresso側にも変更が必要となるなど、メンテナンス性が低い状態でした。

対象リソースがTerraform管理されている場合、ecspressoはTerraformが作成するtfstateファイルを読み込んで、Terraform のリソース名指定形式で参照することが可能です。

ecspresso advent calendar 2020 day 19 - Terraform tfstate

これにより、以下のようにリソースのARNを直接指定せずに、見通しの良い設定ファイルの記述へと変更することが可能となりました。

ecscheduleでは同様の機能はなかったのですが、前述の上水流さんがtfstateを参照可能とするPull Requestを提案し、mergeしていただけたので、estie内で多く利用しているscheduled taskの管理も同様に見通しよく実施することが可能となりました。

enable tfstate plugin by gotoeveryone · Pull Request #32 · Songmu/ecschedule · GitHub

現状のインフラ設計の改善点を素早く洗い出し、実装に近い部分にコメントを残せる

Terraformでの管理に移行するまでは、構築時の手順書やその変更の履歴を読んだり、コンソールで構築されたリソースを探索的に確認したりしながら改善点を洗い出し、それらを別のドキュメントやタスク管理ツールで管理していました。

Terraformに移行したことで、全体の見通しよく高速にこのような課題の洗い出せるようになるとともに、コードベースにTODOコメントを残すことも出来るため、変更時にコード上だけからこれまでの経緯を読み取りながら変更することが出来るようになりました。

SREユニットのこれから

ここまで書いてきたようにTerraformを用いて、創業以来継ぎ足しながら構築されてきたインフラリソースに再現性を持った状態への移行が実現できました。

ただ、これは継続的なReliablityの改善という面ではまだスタートラインに立ったばかりです。

8月に入社した経験豊富な頼もしい1人目のSRE専任社員の方と全開発チームのSWEで、これからTerraform化されて見通しが良くなったリソースを基にチームの体制や信頼性の定義を更新しながら改善を進めていきたいと思っています。

まとめ

estieでは、以下の流れで既存のクラウドリソースをIaCベースで再現性がある状態に移行しました。

Terraformをベースに社内のクラウドインフラ設定をIaC化しました
悩むことが多い環境差異の取り扱い方針については、Moduleベースで進めています
順序はあまり気にせず、AWSに手を加えるタイミングベースで対応しました
実際移行してみると、デプロイ周りの処理も含めて見通しが良くなったり、各チームのSWEからも見通し良くなってPull Request沢山出してくれたりと、当初想定していたよりもメリットを感じています