CCoE による Terraform を活用した Infrastructure as Code

CCoE による Terraform を活用した Infrastructure as Code 2021/05/28 AWS dev/cloud alliance 株式会社ビズリーチ（Visional グループ） Yuuki Nagahara

自己紹介 長原 佑紀（ナガハラ ユウキ） 所属：株式会社ビズリーチ（Visionalグループ） システム本部 プラットフォーム基盤推進室 経歴：SIer → 株式会社ビズリーチ 好きな AWS サービス：AWS Lambda 2

本日の発表内容 ● 話すこと ○ Visional グループの CCoE で取り組む IaC（Infrastructure as Code）について ■ クラウドの IaC に対する考え方 ■ Terraform を活用した IaC に関するプラクティス ■ プラクティスを実現するための AWS のアーキテクチャ ● 話さないこと ○ クラウド以外の IaC について（IaaS など） 3

アジェンダ ● グループ・会社紹介 ● CCoE の IaC の取り組みについて ● AWS アカウント個別 の IaC ● AWS 組織全体 の IaC ● まとめ 4

グループ・会社紹介 5

グループ概要 設立 ：2020年2月（ビジョナル株式会社設立） 創業 ：2009年4月（株式会社ビズリーチ創業） 代表者 ：ビジョナル株式会社 代表取締役社長 南 壮一郎 グループ従業員数：1,401名（2021年2月28日時点） ※臨時従業員（契約社員、パートタイマー、アルバイト）を含む 資本金 拠点 ：164億円（資本準備金含む）※2021年5月18日時点 ：東京、大阪、名古屋、福岡 6

グループミッション 7

グループ経営体制について 株式会社 ビズリーチ ビジョナル ・ インキュベーション 株式会社 株式会社 スタンバイ BINAR 求人検索エンジン 「スタンバイ」 の運営 ハイスキル ITエンジニア 転職プラットフォーム 「BINAR」の運営 トラボックス 株式会社 株式会社 HR Techの プラットフォーム・ SaaS事業の運営 新規事業開発 ※Zホールディングス株式会社 との合弁事業会社 物流DX プラットフォーム「トラ ボックス」 の運営 ビジョナル株式会社（ホールディングカンパニー） 8

所属組織について 運営サービス システム本部 プラットフォーム基盤推進室 （株式会社ビズリーチ に帰属） グループのクラウド / SaaS 全体管理、CCoE（Cloud Center of Excellence）活動、 クラウド共通のプラットフォーム開発・運用 9

CCoE の IaC の取り組みについて 10

Visional グループの CCoE について CCoE（Cloud Center of Excellence）は、クラウド活用をより推進するための専門組織。 < 役割 > ● クラウド戦略計画・推進 ● クラウドガバナンス ● クラウド組織管理 ● ナレッジ管理 ● クラウドプラットフォーム開発運用 ● 技術支援 ● トレーニング ● など < 構造 > 事業部 監査 統制 セキュリティ 部門 相談 フィードバック （経理、法務、人事） 技術支援 情報提供 提供 プラクティス、ポリシー クラウドプラットフォーム 連携 CCoE （プラットフォーム基盤推進室） 連携 その他間接部門 ※クラウド利用者 相談 問合せ 連携 クラウド ベンダー クラウド関連 レポーティング フィードバック 経営 11

CCoE の管理対象について Visional グループの AWS 組織全体の管理を行っている。AWS 組織を運用するための機能を提 供する AWS Core Account 群と全アカウントの共通的なリソースを管理している。 管理対象 12

CCoE における IaC の状況 管理対象 ● Core Accounts の種類：4 種類（各Production/Stagingアカウント） ○ AWS アカウント内の全 AWS リソース ○ AWS アカウントで利用する CaaS（コンテナ）や FaaS（Lambda 関数） ○ 運用で利用する SaaS（Datadog） ● AWS 組織全体の AWS アカウント数：100+ ○ AWS アカウント共通のリソース これらのリソースを IaC によって全て構成管理している 13

IaC のスタンス 運用するリソースは基本的に全て IaC により構成管理を行う ソフトウェアのバージョン管理は当たり前の時代。クラウド（インフラ）も同様。 IaC を疎かにすると、構成管理上の問題が発生し、サービスの信頼性やチームの生産性の低下 を招く要因となりえる。 ● 環境把握困難 ● ヒューマンエラー（作業ミス/漏れ） ● 属人化 ● 作業効率低下 14

IaC のスタンス IaC を目的としない ● IaC でサポートされていないリソース ○ IaC ができない理由でサービス/機能の選定を見送らず、IaC を後回しにしてもメリットが あるかどうかを判断する ● 運用を伴わない技術検証やプロトタイプのリソース ○ サンドボックスアカウント等の IaC なしで気軽に試して良い環境を用意する 15

IaC によって得られるもの ソフトウェア開発のプラクティスをクラウドに適用できる サービス信頼性 / チーム生産性向上 ● バージョン管理（Git） ● ヒューマンエラー低減 ● Pull Request（レビュー） ● 把握容易性の担保 ● CI（継続的インテグレーション） ● 品質の向上 ● CD（継続的デリバリ/デプロイ） ● 再現性/再利用性の向上 ● 作業効率化 16

クラウドの IaC での選択肢 クラウド全般 ツール/サービス CloudFormation （CFn） 提供 特徴 AWS ● ● AWS サービスとして提供 言語：JSON/YAML Cloud Development Kit AWS （CDK） ● ● プログラマブルな CFn のテンプレートエンジン 言語：Python, JavaScript, TypeScript, Java, C# ● ● ● ● ● ● ● 言語：HCL（HashiCorpLanguage） 多くのプロバイダをサポート クラウド版 Terraform Cloud も提供 言語：Python, JavaScript, TypeScript, Go, C# 多くのプロバイダをサポート クラウド版 Pulumi も提供 チーム利用時は有料 Terraform OSS （HashiCorp社） Pulumi OSS （Pulumi社） 17

• https://www.terraform.io/cloud
• https://www.pulumi.com/cloud-engineering/
• https://www.pulumi.com/pricing/

クラウドの IaC での選択肢 クラウドのサーバレス向け ツール/サービス 提供 Serverless Application Model AWS （SAM） Serverless Framework OSS 特徴 ● CFn のサーバレスアプリケーション向け拡張 ● マルチクラウドに対応 弊社の CCoE では、大部分は Terraform （OSS）を利用 部分的に、サーバレスアプリケーションに限り SAM を利用 18

Terraform の選定理由 ● 多くのプロバイダが提供されている ※1 ○ AWS 以外のクラウドや SaaS も Terraform で合わせて構成管理できるため ● OSS のためソースコードが公開されており透明性がある ○ 問題が発生した場合は、ソースコードから原因を調査できるため ● OSS コミュニティによる開発が活発でネットの情報量が多い ● 社内の多くのプロダクトで利用しておりナレッジと実績が多い ※1：CloudFormation でもサードパーティープロバイダーのリソース定義は利用可能 19

Terraform について ● HashiCorp社が提供 ● OSS（github.com/hashicorp/terraform） ● 数多くのクラウドに対応した プロバイダ を提供 ○ Public Cloud：AWS, GCP, Azure, etc.. ○ SaaS：Datadog, NewRelic, PagerDuty, Github, Okta, SumoLogic, Fastly, etc.. ○ 500+ Providers ● Write, Plan, Apply ○ Write：HCLの宣言型言語を用いて記述 ○ Plan：実行計画を確認して期待する動作を確認 ○ Apply：クラウドプロバイダーへ適用 20

• https://github.com/hashicorp/terraform
• https://www.terraform.io/docs/providers/

Terraform について Terraform 最小構成のリソース作成の流れ（Terraform v0.15.4） Write Plan $ terraform init $ terraform plan main.tf Apply $ terraform apply S3バケット作成例 ## プロバイダの設定 provider "aws" { profile = "myawsprofile" region = "ap-northeast-1" } ## リソース定義 resource "aws_s3_bucket" "hoge" { bucket = "my-hoge-bucket-20210528” acl = "private" } 21

ここからは、 CCoE で運用している 2 種類の IaC のプラクティスについて説明する AWS アカウント個別 の IaC ● それぞれの AWS アカウントの IaC をどの ように取り組んでいるか AWS 組織全体 の IaC ● AWS 組織全体でアカウント共通リソースの IaC をどのように取り組んでいるか 22

AWS アカウント個別 の IaC 23

AWS アカウント個別の IaC に関するプラクティス 1. アカウント種別単位のリポジトリ構成 2. Workspaces によるマルチステージ対応 3. Terraform 実行の独自ラッパー 4. Terraform ディレクトリ構成 5. IaC のブランチ戦略 6. PullRequest による CI 7. ChatOps による IaC の適用 8. 構成ドリフトの検出 9. Module によるパッケージ化 10. SAM との連携について 24

1. アカウント種別単位のリポジトリ構成 AWS Core Accounts は、それぞれ Production / Staging ア カウントにて構成され、全て CCoE のエンジニアリングチーム にて運用しているが、アカウントの種別単位の Terraform リポ ジトリを構成している。 アカウントの役割が異なるため、IaC のリポジトリを分離してお くことで、物理的な境界を設けてアカウントの分離レベルを高く 保つことが出来る。 25

2. Workspaces によるマルチステージ対応 Terraform の Workspaces 機能を用いて、tf ファイルを各ステージ（Production / Staging）へ適 用する。 同じコードベースをワークスペースを切り替えてマルチステージへ適用することで、 コード品質を高め、コードを DRY に保つことが出来る。 workspace作成/切り替え/適用 main.tf（workspace名をコード内で利用） ### newは初回のみ $ terraform workspace new stg $ terraform workspace select stg $ terraform apply resource "aws_s3_bucket" "hoge" { ### S3バケット名: “stg-hoge-bucket” bucket = "${terraform.workspace}-hoge-bucket” acl = "private" stg } 26

3. Terraform 実行の独自ラッパー terraform init による初期化、terraform workspace select で workspace へ切り替え等の 共通的な操作後に目的の terraform コマンドを実行するラッパースクリプト。 共通操作をラップすることでミスを防止し、最小限のパラメータで操作が行える。 file: tf.sh Usage: tf.sh [ENV] [TARGET_DIRS,] [TF_CMD] ([TF_ARGS]..) Options: ENV : Environment [stg/prd/..] TARGET_DIRS : 'ALL' or Directories (csv) TF_CMD : Terraform Command [plan/apply/destroy/..] TF_ARGS : Terraform Command Args (https://www.terraform.io/docs/commands) Example: ./tf.sh stg aws/base/s3 plan ./tf.sh stg aws/base/s3,aws/base/iam apply -auto-approve ./tf.sh prd ALL plan 27

3. Terraform 実行の独自ラッパー ワークスペース毎の環境依存の設定を記述した _env ファイルを用意しており、ラッパーでは与 えられた ENV の設定を読み込み、パラメータを自動で付与している。 file: _envファイル（stg.confの例） BACKEND_BUCKET=hogehoge-stg-terraform ... バックエンドS3バケット名 BACKEND_REGION=ap-northeast-1 ... バックエンドS3バケットリージョン BACKEND_PROFILE=hogehoge-stg ... バックエンドS3のAWSプロファイル BACKEND_STATELOCK_TABLE=tfstate_lock ... 排他制御用DynamoDBのステートロックテーブル また、Terraform 実行の排他制御を DynamoDB State Locking にて実施しており、複数人の開 発や CI との Terraform 実行の衝突に備えている。 28

4. Terraform ディレクトリ構成 リソースを定義する tf ファイルは、ディレクトリ（即ち、stateファイル）を適度に分割している。ディ レクトリを分割することで、影響範囲を限定化してチーム開発に対応させ、個々の実行時間を短 縮して効率化している。 tf ファイルのディレクトリ分割は以下の観点。 ● 関心事の異なるコンポーネント（機能別） ● レイヤー（ネットワーク / バックエンド / データベース など） ● ステートフル / ステートレス（イミュータブルリソースか否か） ● リソースのライフサイクル（変更の頻度やタイミング） 29

4. Terraform ディレクトリ構成 別のディレクトリのリソース情報は state ファイルの Outputs を経由して参照する。 vpc/main.tf（VPCFlowLogs を S3 出力する設定） s3/main.tf（ログ出力用バケット定義） data "terraform_remote_state" "hoge_s3" { resource "aws_s3_bucket" "hoge" { bucket = "${terraform.workspace}-log-bucket” acl = "private" } DataSource にて backend = "local" ### Stateをローカル保管の場合、通常は S3 等に保管 config = { 別ディレクトリ path = "../s3/terraform.tfstate" の state を参照 } } output "bucket_name" { value = aws_s3_bucket.hoge.id } state に output された値を参照 resource "aws_flow_log" "vpc" { traffic_type = "ALL" log_destination_type = "s3" log_destination = data.terraform_remote_state.hoge_s3.outputs.bucket_name } 循環参照が発生すると適用が出来なくなることがあるため、参照関係には注意が必要。 分割ディレクトリ階層にて base（基底リソース）と component（機能リソース）で分け、component から base の単方 向参照のみ許容するルールをディレクトリ構造へ取り入れている。 30

4. Terraform ディレクトリ構成 ディレクトリ構成 イメージ xxxx-terraform/ ┣_env/ ... ステージ（ワークスペース）別アカウントの設定 ┃ ┣ prd.conf ... productionアカウントの設定ファイル ┃ ┗ stg.conf ... stagingアカウントの設定ファイル ┣ tf.sh ... terraform実行用ラッパースクリプト ┣ aws/ ... AWSプロバイダ関連リソースのディレクトリ ┃ ┣ _templates/ ... 実行時にtfファイルのディレクトリへコピーする共通ファイル群 ┃ ┃ ┣ __backend.tf ... バックエンドの定義 ┃ ┃ ┣ __provider.tf ... プロバイダブロックの定義 ┃ ┃ ┣ __version.tf ... Terraform/Provider使用バージョン定義 ┃ ┃ ┗ __globals.tf ... グローバルの変数定義（locals） ┃ ┣ _modules/ ... Terraformモジュールのディレクトリ ┃ ┃ ┗ [Module]/ ┃ ┣ base/ ... 基底リソース群のディレクトリ ┃ ┃ ┣ [Base]/ ┃ ┃ ┗ route53/ ... 基底リソースの一例 ┃ ┃ ┗ xxx.jp/ ... Zone,Record,ACMなど ┃ ┃ ┣ main.tf ... リソースの宣言定義 ┃ ┃ ┗ outputs.tf ... output valuesとして他ディレクトリから参照可能な値の定義 ┃ ┗ component/ ... コンポーネント（サービス/機能）群のディレクトリ ┃ ┣ [Component]/ ┃ ┗ hoge_service/ ...コンポーネントリソースの一例 ┗ datadog/ ... Datadogプロバイダ関連リソースのディレクトリ ┗ ry) 31

5. IaC のブランチ戦略 master / staging / feature の 3 種類で構成し、ステージと合わせたブランチ戦略を取る。 ● Production アカウントは、常に master ブランチの状態と一致 ● Staging アカウントは、基本的に staging ブランチの状態と一致 ○ feature ブランチでマージ前の事前検証が必要な場合は staging への適用を許容。 ブランチとステージを合わせることで、適用先を明確化し、期待する状態が把握し易い。 Production 環境を IaC と一致させておくことで、障害や調査の環境把握が容易となる。 32

6. Pull Request による CI Pull Request を作成 / 更新した際に、CI によって自動的なコード検証を行っている。 ● フォーマットチェック：terraform fmt で tf ファイルのフォーマット検証 ● plan チェック：terraform plan でターゲットの環境への plan 検証 ● 静的解析チェック：tflint（OSS）を使ったリンターの検証 33

• https://github.com/terraform-linters/tflint

6. Pull Request による CI アーキテクチャ Staging / Production の各アカウントにて Github の webhook をトリガに CI 用の CodeBuild を実行する。 環境分離のため、PR のベースブランチに 従って適切なステージで評価する。 ※ SaaS（Github Actions / CircleCI 等）を利用しない 理由として、Terraform 実行のために強めのポリシー を持った IAM User のクレデンシャルが必要となるた め AWS 内で完結させている。 34

7. ChatOps による IaC の適用 Terraform の環境へ対する全操作は Slack の ChatOps をインタフェースとしている。 35

7. ChatOps による IaC の適用 アーキテクチャ Terraform のラッパースクリプトと同等のコマンドを Slash Command で入力し、そのパラメータ で CodeBuild にて Terraform の独自ラッパーを実行する。 ChatOps によって環境へのオペレーションがチームへ共有され、作業が可視化される。 ※GitOps（マージ後自動 Apply）にしない理由は、リリースの内容によりディレクトリの適用順序やリリース手順を考慮 してタイミングを図りたい場合があるため。 36

8. 構成ドリフトの検出 構成ドリフトとは、IaC の定義と実際の環境に差異が生じた状況のこと。 開発作業中に構成ドリフトに気づいた場合、変更を行うためにドリフトの解消を余儀なくされて、 スムーズな開発作業を阻害する要因となりえる。 対応を誤ると障害に繋がる可能性があり、最悪はオートメーション恐怖症にも繋がる。 IaC では構成ドリフトを早期に検出して適宜対処することが肝心。 37

8. 構成ドリフトの検出 構成ドリフトを検出する Drift Detection の仕組みを取り入れている。 日次で自動的に IaC 全体の terraform plan を実行し、構成ドリフトやエラーの有無を Slack に て通知する。メッセージスレッドにて差分やエラー内容が確認できる。 38

8. 構成ドリフトの検出 アーキテクチャ CodeBuild にて、環境に合わせたブランチのコー ドを取得して、Terraform のディレクトリを再帰的 に plan して結果を通知する。 ● Production 環境 = master ブランチ ● Staging 環境 = staging ブランチ 39

9. Module によるパッケージ化 CI / ChatOps / DriftDetection 等共通の仕組みは Terraform で Module 化している。 AWS アカウントを追加する場合でも、移植性が高く、効率的に構成を展開できる。 但し、現在は各 Module を共通化しているが各リポジトリにコピーしている状態。 今後の展開として、モジュール単位の Github リポジトリを構成して直接参照する予定。 module "hogehoge" { source = "git::https://github.com/sample-org/hoge-module.git?ref=v1.2.0" environment = terraform.workspace github_repo_url = local.github_https_url github_target_branch = local.github_branch[terraform.workspace] slack_webhook_url = data.terraform_remote_state.ssm_slack.outputs.webhook_url } ※ 1 Module = 1 リポジトリにて、リポジトリでタグ戦略を取ることで、利用側でタグでバージョンを制御することでモ ジュールの変更への影響にも対応可能とする。 ※ モジュールを活用する際には Terraform Registry に公開された Modules も参考となる。 40

• https://github.com/bizrerach-inc/terraform-hogehoge-module.git?ref=v1.2.0
• https://registry.terraform.io/browse/modules

10. SAM との連携について サーバレスアプリケーションを開発する場合、SAM や Serverless Framework は、サーバレスに 特化した機能があるためメリットがある。 API Gateway + Lambda + DynamoDB による構成の場合、ローカルでの動作確認やテストが 可能となる。 CCoE では AWS 組織全体の AWS サポートケースを集約してナレッジとして社内へ公開する サーバレス SPA の Web アプリケーションを提供している。 そのサービスでは、IaC のメインは Terraform を利用しながら、一部のサーバレス関連リソース のみ SAM で IaC を行っている。 41

10. SAM との連携について AWS Support Case Explorer AWS 組織内のサポートケース一覧・検索画面 サポートケースの詳細画面 42

10. SAM との連携について ● SAM：API Gateway + Lambda のリソース定義 ● Terraform：その他のリソース定義 SAM の範囲 SAM では sam deploy は行なわず、 sam package で CloudFormation テンプレートファイルを生成して S3 へ PUT する。Terraform にて、そのテンプレートファイルを読 み込んで CloudFormation Stack を作成することで SAM のリソースをデプロイしている。 SAM によりローカルテストが実現出来ることに加え、その 構成管理は Terraform で行っている。 43

10. SAM との連携について
Terraform から CFn テンプレート
の Parameters を渡したり、
スタックの Outputs を Terraform
で参照することも可能。
Terraform ⇆ SAM をシームレスに
繋げることが出来る。

### SAM テンプレートの S3オブジェクト読み込み
data "aws_s3_bucket_object" "serverless_template" {
bucket = aws_s3_bucket.artifact.id
key = "sam.yaml"
}
### SAMテンプレートへ Terraform の remote_state のパラメータを与えて CFn スタックを作成
resource "aws_cloudformation_stack" "serverless" {
name
= "${local.name}-serverless"
capabilities = ["CAPABILITY_NAMED_IAM", "CAPABILITY_AUTO_EXPAND"]
parameters = {
ApiName : local.name
DomainName : aws_route53_record.front.fqdn
LambdaRole : data.terraform_remote_state.aes.outputs.support_case_lambda_role_arn
AccessLogDestinationArn : "${aws_cloudwatch_log_group.access.arn}:*"
ElasticsearchHost : "https://${data.terraform_remote_state.aes.outputs.domain_endpoint}"
ElasticsearchDomainName : data.terraform_remote_state.aes.outputs.domain_name
MasterOrgsRoleArn : "arn:aws:iam::${local.g_aws_core_accounts.master}:role/support-case-explorer"
}
template_body = data.aws_s3_bucket_object.serverless_template.body
tags = local.tags
}
### SAMテンプレートにて作成したリソースの outputs を参照して Terraform側でリソース定義
resource "aws_lambda_permission" "collector_permission" {
action
= "lambda:InvokeFunction"
function_name = aws_cloudformation_stack.serverless.outputs.CollectorFunction
principal = "events.amazonaws.com"
source_arn = aws_cloudwatch_event_rule.collector.arn
}
..snip..

44

AWS アカウント個別の IaC に関するプラクティス まとめ 1. アカウント種別単位のリポジトリ構成 アカウントの分離レベル保護 2. Workspaces によるマルチステージ対応 DRY、コード品質向上 3. Terraform 実行の独自ラッパー 省力化、ミス防止、排他制御 4. Terraform ディレクトリ構成 分割による影響局所化、適用時間短縮 5. IaC のブランチ戦略 ステージ毎の状態把握が容易 6. PullRequest による CI 自動チェックによる効率化 7. ChatOps による IaC の適用 透明性向上、オぺレーション効率化 8. 構成ドリフトの検出 問題や作業阻害要因の排除 9. Module によるパッケージ化 再利用性向上 10. SAM との連携について サーバレスローカル環境との両立 45

AWS 組織全体 の IaC 46

ベースラインについて CCoE では、AWS 組織全体の AWS アカウ ントの共通リソース（ベースライン）を Terraform にて管理。 SecurityHub / GuardDuty / AWSConfig 等 のガバナンス関連の設定が含まれる。 新規 AWS アカウント作成時に適用し、ま た、組織全体の共通リソースを変更時にも全 体へ対して適用する。 47

ベースラインについて AWS 組織全体の IaC として Terraform を採用した経緯（当時の選択肢） ● CloudFormation StackSets ○ CloudFormation テンプレートをマルチアカウント/リージョンに対して展開可能 ● 独自の Terraform によるベースライン管理 ○ 多少の作り込みが必要となるが自由度は高い 2019年秋選定時点では、StackSets にて「変更セットの作成」「ドリフト検出」の機能が未提供の ため、Terraform を用いた独自方式を選定。 ※現在では StackSets で変更セットの作成やドリフト検出も可能となっているため、今後新たにベースラインを検討/ 導入する場合は、 東京リージョンがサポートされた ControlTower を含め十分な選択肢となる。 48

ベースラインについて ベースラインの活用方法や設定内容については割愛。下記資料を参照。 AWS Summit Online Japan 2020 ● 大規模な組織変遷と100以上のAWSアカウントの横 断的セキュリティガードレール運用について Visional Engineering Blog ● 100を超えるAWSアカウント運用におけるガードレー ル構築事例 49

• https://pages.awscloud.com/rs/112-TZM-766/images/CUS-06_AWS_Summit_Online_2020_Visional Inc.pdf
• https://engineering.visional.inc/blog/171/awssummit_securityguardrail/

AWS 組織全体の IaC に関するプラクティス 1. マルチアカウント展開 2. マルチリージョン展開 3. ベースラインの適用 4. 構成ドリフトの検出 50

1. マルチアカウント展開 ベースライン適用対象アカウント数分並列にCodeBuild を起動し、それぞれ組織内のアカウントに対して Assume Role にて Terraform を実行する。 Lambda で CodeBuild 呼び出し後に実行情報を DynamoDB へ書き込み、CodeBuild の完了イベントを 受信して処理全体の結果判定を行う。 ※現在では、StepFunctions で Map（動的反復）を利用することで、 よりシンプルに実現が可能。 51

1. マルチアカウント展開 Terraform の Workspaces 機能を利用し、 AccountID 毎のワー クスペースに切り替えて適用している。 state ファイルは S3 へアカウント ID ごとのパスで保管する。 52

2. マルチリージョン展開 マルチリージョンに展開するリソースは Terraform の Modules にてリソース定義し、 リージョン単位でモジュールを呼び出すことで少ないコード量で実現している。 ディレクトリ構成イメージ visional-baseline/ ┣ tf.sh ... Terraform ラッパースクリプト ┗ aws/ ... AWS 関連リソースディレクトリ ┣ _backend.tf ... バックエンドの定義 ┣ _locals.tf ... ローカル変数の定義 ┣ _providrs.tf ... プロバイダブロックの定義（リージョン単位） ┣ _variables.tf ... 外部パラメータ変数定義 ┣ _versions.tf ... Terraform/Provider使用バージョン定義 ┣ modules/ ... マルチリージョン展開用モジュールディレクトリ ┃ ┣ config/ ... AWS Config 関連リソース ┃ ┃ ┣ main.tf ┃ ┃ ┗ variables.tf ┃ ┣ securityhub/ ... SecurityHub 関連リソース ┃ ┃ ┣ main.tf ┃ ┃ ┗ variables.tf ┃ ┗ [OtherModules] ┗ main.tf ... マルチリージョン展開モジュール使用定義 マルチリージョン展開モジュール使用定義イメージ module "securityhub_ap-northeast-1" { providers = { aws = aws.ap-northeast-1 } source = "./modules/securityhub" } module "securityhub_ap-northeast-2" { providers = { aws = aws.ap-northeast-2 } source = "./modules/securityhub" } module "securityhub_ap-south-1" { providers = { aws = aws.ap-south-1 } source = "./modules/securityhub" } ...snip... ※現在の Terraform v0.15系 でも未だ module で for_each が使えないため、対象リージョン分の定義 が必要となり少し冗長な記述になる。 53

3. ベースラインの適用 Systems Manager Automation と Slack を活用している。 CCoE では、エンジニアリングチームと AWS のルートアカウントを管理する特権 を有するチームが分かれている。 Automation の aws:approve アクション では、特権所有者（AdminRole）の承認を 経て実行できる仕組みとしている。 54

4. 構成ドリフトの検出 ベースラインも、日次で AWS 組織全体の構成ドリフトの検出を行 い、結果を Slack へ通知する。 ベースラインのコード変更を全体へ適用する場合、日跨ぎで段階 的に組織全体へ適用するケースもあるため、DynamoDB にスト アした AWS アカウント単位の最終適用コミットバージョンに対し て構成ドリフトを検査している。 ※ ベースライン管理リソースの変更/削除操作については、基本的には AWS Organizations の SCP にて制限をかけている。 55

AWS 組織全体の IaC に関するプラクティス まとめ 1. マルチアカウント展開 並列実行によりスピーディーに全体適用 2. マルチリージョン展開 モジュールにより管理効率化 3. ベースラインの適用 承認ステップにより安全な実行フロー 4. 構成ドリフトの検出 AWS 組織全体のベースライン適用を担保 56

まとめ 57

まとめ ● IaC を疎かにするとサービスの信頼性の問題やチームの活動の課題が生じるケースが多い。 ● 運用するリソースは基本的に全て IaC する。しかし、IaC を目的としない。 ● IaC によりソフトウェア開発のプラクティスをクラウド（インフラ）へ適用できる。 ● Terraform による IaC のプラクティス ● プラクティスを適用することで、昨今のリモートワーク状況下でもチーム開発を円滑に進められ、チー ムの生産性やサービスの信頼性を高められる。 58

Thank you. We are hiring. 一緒に働く仲間を募集中です。 https://www.bizreach.co.jp/recruit/ Visional Tech Blog https://engineering.visional.inc/blog/ 59

• https://hrmos.co/pages/hrmos/jobs/160009210080
• https://www.bizreach.co.jp/recruit/
• https://engineering.visional.inc/blog/