CCoE による Terraform を活用した Infrastructure as Code / IaC by Terraform in CCoE

AWS dev/cloud alliance japan
2021年05月28日(金)
発表資料

セッション:「CCoE による Terraform を活用した Infrastructure as Code」

内容：Visional グループの CCoE (Cloud Center of Excellence) のチームにおける Infrastructure as Code (IaC) の取り組みについてご紹介します。
CCoE の組織では、 IaC として主に Terraform を利用しており、 Terraform を用いてクラウドの信頼性やチームの生産性を高めるために IaC のプラクティスを取り込んでおります。それらのプラクティスについて、AWS アカウントを運用する観点、及び AWS 組織全体を運用する観点で共有させていただきます。

Transcript

1. CCoE による Terraform を活用した Infrastructure as Code 2021/05/28 AWS dev/cloud alliance 株式会社ビズリーチ（Visional グループ） Yuuki Nagahara
2. 2 自己紹介 長原 佑紀（ナガハラ ユウキ） 所属：株式会社ビズリーチ（Visionalグループ） 　　　システム本部 　　　プラットフォーム基盤推進室 経歴：SIer → 株式会社ビズリーチ 好きな AWS サービス：AWS Lambda
3. • 話すこと ◦ Visional グループの CCoE で取り組む IaC（Infrastructure as Code）について ▪ クラウドの IaC に対する考え方 ▪ Terraform を活用した IaC に関するプラクティス ▪ プラクティスを実現するための AWS のアーキテクチャ • 話さないこと ◦ クラウド以外の IaC について（IaaS など） 3 本日の発表内容
4. 4 アジェンダ • グループ・会社紹介 • CCoE の IaC の取り組みについて • AWS アカウント個別 の IaC • AWS 組織全体 の IaC • まとめ
5. グループ・会社紹介 5
6. 6 グループ概要 設立　　 ：2020年2月（ビジョナル株式会社設立） 創業　　 ：2009年4月（株式会社ビズリーチ創業） 代表者　 ：ビジョナル株式会社 代表取締役社長　南 壮一郎 グループ従業員数：1,401名（2021年2月28日時点） 　　　　　　　　　※臨時従業員（契約社員、パートタイマー、アルバイト）を含む 資本金　 ：164億円（資本準備金含む）※2021年5月18日時点 拠点　　 ：東京、大阪、名古屋、福岡
7. 7 グループミッション
8. 8 グループ経営体制について ビジョナル株式会社（ホールディングカンパニー）　 株式会社 ビズリーチ ビジョナル ・ インキュベーション 株式会社 株式会社 BINAR 株式会社 スタンバイ HR Techの プラットフォーム・ SaaS事業の運営 新規事業開発 ハイスキル ITエンジニア 転職プラットフォーム 「BINAR」の運営 求人検索エンジン 「スタンバイ」 の運営 ※Zホールディングス株式会社 との合弁事業会社 トラボックス 株式会社 物流DX プラットフォーム「トラ ボックス」 の運営
9. 9 所属組織について 運営サービス システム本部 プラットフォーム基盤推進室　（株式会社ビズリーチ に帰属） グループのクラウド / SaaS 全体管理、CCoE（Cloud Center of Excellence）活動、 クラウド共通のプラットフォーム開発・運用
10. CCoE の IaC の取り組みについて 10
11. < 役割 > • クラウド戦略計画・推進 • クラウドガバナンス • クラウド組織管理 • ナレッジ管理 • クラウドプラットフォーム開発運用 • 技術支援 • トレーニング • など < 構造 > 11 Visional グループの CCoE について CCoE（Cloud Center of Excellence）は、クラウド活用をより推進するための専門組織。 CCoE （プラットフォーム基盤推進室） クラウド ベンダー セキュリティ 部門 事業部 経営 その他間接部門 （経理、法務、人事） プラクティス、ポリシー クラウドプラットフォーム 連携 相談 問合せ 提供 技術支援 情報提供 相談 フィードバック 監査 統制 連携 連携 フィードバック クラウド関連 レポーティング ※クラウド利用者
12. Visional グループの AWS 組織全体の管理を行っている。AWS 組織を運用するための機能を提 供する AWS Core Account 群と全アカウントの共通的なリソースを管理している。 12 CCoE の管理対象について 管理対象
13. 管理対象 • Core Accounts の種類：4 種類（各Production/Stagingアカウント） ◦ AWS アカウント内の全 AWS リソース ◦ AWS アカウントで利用する CaaS（コンテナ）や FaaS（Lambda 関数） ◦ 運用で利用する SaaS（Datadog） • AWS 組織全体の AWS アカウント数：100+ ◦ AWS アカウント共通のリソース 13 CCoE における IaC の状況 これらのリソースを IaC によって全て構成管理している
14. 運用するリソースは基本的に全て IaC により構成管理を行う 　ソフトウェアのバージョン管理は当たり前の時代。クラウド（インフラ）も同様。 IaC を疎かにすると、構成管理上の問題が発生し、サービスの信頼性やチームの生産性の低下 を招く要因となりえる。 • 環境把握困難 • ヒューマンエラー（作業ミス/漏れ） • 属人化 • 作業効率低下 14 IaC のスタンス
15. 15 IaC のスタンス IaC を目的としない • IaC でサポートされていないリソース ◦ IaC ができない理由でサービス/機能の選定を見送らず、IaC を後回しにしてもメリットが あるかどうかを判断する • 運用を伴わない技術検証やプロトタイプのリソース ◦ サンドボックスアカウント等の IaC なしで気軽に試して良い環境を用意する
16. 16 IaC によって得られるもの ソフトウェア開発のプラクティスをクラウドに適用できる • バージョン管理（Git） • Pull Request（レビュー） • CI（継続的インテグレーション） • CD（継続的デリバリ/デプロイ） サービス信頼性 / チーム生産性向上 • ヒューマンエラー低減 • 把握容易性の担保 • 品質の向上 • 再現性/再利用性の向上 • 作業効率化
17. 17 クラウドの IaC での選択肢 ツール/サービス 提供 特徴 CloudFormation （CFn） AWS • AWS サービスとして提供 • 言語：JSON/YAML Cloud Development Kit （CDK） AWS • プログラマブルな CFn のテンプレートエンジン • 言語：Python, JavaScript, TypeScript, Java, C# Terraform OSS （HashiCorp社） • 言語：HCL（HashiCorpLanguage） • 多くのプロバイダをサポート • クラウド版 Terraform Cloud も提供 Pulumi OSS （Pulumi社） • 言語：Python, JavaScript, TypeScript, Go, C# • 多くのプロバイダをサポート • クラウド版 Pulumi も提供 • チーム利用時は有料 クラウド全般
18. 18 クラウドの IaC での選択肢 ツール/サービス 提供 特徴 Serverless Application Model （SAM） AWS • CFn のサーバレスアプリケーション向け拡張 Serverless Framework OSS • マルチクラウドに対応 クラウドのサーバレス向け 弊社の CCoE では、大部分は Terraform （OSS）を利用 部分的に、サーバレスアプリケーションに限り SAM を利用
19. • 多くのプロバイダが提供されている ※1 ◦ AWS 以外のクラウドや SaaS も Terraform で合わせて構成管理できるため • OSS のためソースコードが公開されており透明性がある ◦ 問題が発生した場合は、ソースコードから原因を調査できるため • OSS コミュニティによる開発が活発でネットの情報量が多い • 社内の多くのプロダクトで利用しておりナレッジと実績が多い 19 Terraform の選定理由 ※1：CloudFormation でもサードパーティープロバイダーのリソース定義は利用可能
20. • 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 Terraform について
21. Terraform 最小構成のリソース作成の流れ（Terraform v0.15.4） 21 Terraform について ## プロバイダの設定 provider "aws" { profile = "myawsprofile" region = "ap-northeast-1" } ## リソース定義 resource "aws_s3_bucket" "hoge" { bucket = "my-hoge-bucket-20210528” acl = "private" } main.tf Write Plan $ terraform init $ terraform plan Apply $ terraform apply S3バケット作成例
22. ここからは、 CCoE で運用している 2 種類の IaC のプラクティスについて説明する 22 AWS アカウント個別 の IaC • それぞれの AWS アカウントの IaC をどの ように取り組んでいるか AWS 組織全体 の IaC • AWS 組織全体でアカウント共通リソースの IaC をどのように取り組んでいるか
23. AWS アカウント個別 の IaC 23
24. 1. アカウント種別単位のリポジトリ構成 2. Workspaces によるマルチステージ対応 3. Terraform 実行の独自ラッパー 4. Terraform ディレクトリ構成 5. IaC のブランチ戦略 6. PullRequest による CI 7. ChatOps による IaC の適用 8. 構成ドリフトの検出 9. Module によるパッケージ化 10. SAM との連携について 24 AWS アカウント個別の IaC に関するプラクティス
25. AWS Core Accounts は、それぞれ Production / Staging ア カウントにて構成され、全て CCoE のエンジニアリングチーム にて運用しているが、アカウントの種別単位の Terraform リポ ジトリを構成している。 アカウントの役割が異なるため、IaC のリポジトリを分離してお くことで、物理的な境界を設けてアカウントの分離レベルを高く 保つことが出来る。 25 1. アカウント種別単位のリポジトリ構成
26. Terraform の Workspaces 機能を用いて、tf ファイルを各ステージ（Production / Staging）へ適 用する。 同じコードベースをワークスペースを切り替えてマルチステージへ適用することで、 コード品質を高め、コードを DRY に保つことが出来る。 26 2. Workspaces によるマルチステージ対応 ### newは初回のみ $ terraform workspace new stg $ terraform workspace select stg $ terraform apply main.tf（workspace名をコード内で利用） resource "aws_s3_bucket" "hoge" { ### S3バケット名: “stg-hoge-bucket” bucket = "${terraform.workspace}-hoge-bucket” acl = "private" } workspace作成/切り替え/適用 stg
27. terraform init による初期化、terraform workspace select で workspace へ切り替え等の 共通的な操作後に目的の terraform コマンドを実行するラッパースクリプト。 共通操作をラップすることでミスを防止し、最小限のパラメータで操作が行える。 27 3. Terraform 実行の独自ラッパー 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 file: tf.sh
28. ワークスペース毎の環境依存の設定を記述した _env ファイルを用意しており、ラッパーでは与 えられた ENV の設定を読み込み、パラメータを自動で付与している。 また、Terraform 実行の排他制御を DynamoDB State Locking にて実施しており、複数人の開 発や CI との Terraform 実行の衝突に備えている。 file: _envファイル（stg.confの例） 28 3. Terraform 実行の独自ラッパー BACKEND_BUCKET=hogehoge-stg-terraform ... バックエンドS3バケット名 BACKEND_REGION=ap-northeast-1 　　... バックエンドS3バケットリージョン BACKEND_PROFILE=hogehoge-stg 　 ... バックエンドS3のAWSプロファイル BACKEND_STATELOCK_TABLE=tfstate_lock ... 排他制御用DynamoDBのステートロックテーブル
29. リソースを定義する tf ファイルは、ディレクトリ（即ち、stateファイル）を適度に分割している。ディ レクトリを分割することで、影響範囲を限定化してチーム開発に対応させ、個々の実行時間を短 縮して効率化している。 tf ファイルのディレクトリ分割は以下の観点。 • 関心事の異なるコンポーネント（機能別） • レイヤー（ネットワーク / バックエンド / データベース など） • ステートフル / ステートレス（イミュータブルリソースか否か） • リソースのライフサイクル（変更の頻度やタイミング） 29 4. Terraform ディレクトリ構成
30. 別のディレクトリのリソース情報は state ファイルの Outputs を経由して参照する。 循環参照が発生すると適用が出来なくなることがあるため、参照関係には注意が必要。 分割ディレクトリ階層にて base（基底リソース）と component（機能リソース）で分け、component から base の単方 向参照のみ許容するルールをディレクトリ構造へ取り入れている。 30 4. Terraform ディレクトリ構成 resource "aws_s3_bucket" "hoge" { bucket = "${terraform.workspace}-log-bucket” acl = "private" } output "bucket_name" { value = aws_s3_bucket.hoge.id } s3/main.tf（ログ出力用バケット定義） data "terraform_remote_state" "hoge_s3" { backend = "local" ### Stateをローカル保管の場合、通常は S3 等に保管 config = { path = "../s3/terraform.tfstate" } } resource "aws_flow_log" "vpc" { traffic_type = "ALL" log_destination_type = "s3" log_destination = data.terraform_remote_state.hoge_s3.outputs.bucket_name } vpc/main.tf（VPCFlowLogs を S3 出力する設定） state に output された値を参照 DataSource にて 別ディレクトリ の state を参照
31. ディレクトリ構成 イメージ 31 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)

32. 32 master / staging / feature の 3 種類で構成し、ステージと合わせたブランチ戦略を取る。 • Production アカウントは、常に master ブランチの状態と一致 • Staging アカウントは、基本的に staging ブランチの状態と一致 ◦ feature ブランチでマージ前の事前検証が必要な場合は staging への適用を許容。 ブランチとステージを合わせることで、適用先を明確化し、期待する状態が把握し易い。 Production 環境を IaC と一致させておくことで、障害や調査の環境把握が容易となる。 5. IaC のブランチ戦略
33. Pull Request を作成 / 更新した際に、CI によって自動的なコード検証を行っている。 • フォーマットチェック：terraform fmt で tf ファイルのフォーマット検証 • plan チェック：terraform plan でターゲットの環境への plan 検証 • 静的解析チェック：tflint（OSS）を使ったリンターの検証 33 6. Pull Request による CI
34. 34 6. Pull Request による CI アーキテクチャ Staging / Production の各アカウントにて Github の webhook をトリガに CI 用の CodeBuild を実行する。 環境分離のため、PR のベースブランチに 従って適切なステージで評価する。 ※ SaaS（Github Actions / CircleCI 等）を利用しない 理由として、Terraform 実行のために強めのポリシー を持った IAM User のクレデンシャルが必要となるた め AWS 内で完結させている。
35. Terraform の環境へ対する全操作は Slack の ChatOps をインタフェースとしている。 35 7. ChatOps による IaC の適用
36. アーキテクチャ 36 7. ChatOps による IaC の適用 Terraform のラッパースクリプトと同等のコマンドを Slash Command で入力し、そのパラメータ で CodeBuild にて Terraform の独自ラッパーを実行する。 ChatOps によって環境へのオペレーションがチームへ共有され、作業が可視化される。 ※GitOps（マージ後自動 Apply）にしない理由は、リリースの内容によりディレクトリの適用順序やリリース手順を考慮 してタイミングを図りたい場合があるため。
37. 構成ドリフトとは、IaC の定義と実際の環境に差異が生じた状況のこと。 開発作業中に構成ドリフトに気づいた場合、変更を行うためにドリフトの解消を余儀なくされて、 スムーズな開発作業を阻害する要因となりえる。 対応を誤ると障害に繋がる可能性があり、最悪はオートメーション恐怖症にも繋がる。 IaC では構成ドリフトを早期に検出して適宜対処することが肝心。 37 8. 構成ドリフトの検出
38. 構成ドリフトを検出する Drift Detection の仕組みを取り入れている。 日次で自動的に IaC 全体の terraform plan を実行し、構成ドリフトやエラーの有無を Slack に て通知する。メッセージスレッドにて差分やエラー内容が確認できる。 38 8. 構成ドリフトの検出
39. アーキテクチャ CodeBuild にて、環境に合わせたブランチのコー ドを取得して、Terraform のディレクトリを再帰的 に plan して結果を通知する。 • Production 環境 = master ブランチ • Staging 環境 = staging ブランチ 39 8. 構成ドリフトの検出
40. CI / ChatOps / DriftDetection 等共通の仕組みは Terraform で Module 化している。 AWS アカウントを追加する場合でも、移植性が高く、効率的に構成を展開できる。 但し、現在は各 Module を共通化しているが各リポジトリにコピーしている状態。 今後の展開として、モジュール単位の Github リポジトリを構成して直接参照する予定。 40 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 も参考となる。 9. Module によるパッケージ化
41. サーバレスアプリケーションを開発する場合、SAM や Serverless Framework は、サーバレスに 特化した機能があるためメリットがある。 API Gateway + Lambda + DynamoDB による構成の場合、ローカルでの動作確認やテストが 可能となる。 CCoE では AWS 組織全体の AWS サポートケースを集約してナレッジとして社内へ公開する サーバレス SPA の Web アプリケーションを提供している。 そのサービスでは、IaC のメインは Terraform を利用しながら、一部のサーバレス関連リソース のみ SAM で IaC を行っている。 41 10. SAM との連携について
42. AWS Support Case Explorer 42 10. SAM との連携について AWS 組織内のサポートケース一覧・検索画面 サポートケースの詳細画面
43. • SAM：API Gateway + Lambda のリソース定義 • Terraform：その他のリソース定義 SAM では sam deploy は行なわず、 sam package で CloudFormation テンプレートファイルを生成して S3 へ PUT する。Terraform にて、そのテンプレートファイルを読 み込んで CloudFormation Stack を作成することで SAM のリソースをデプロイしている。 SAM によりローカルテストが実現出来ることに加え、その 構成管理は Terraform で行っている。 43 10. SAM との連携について SAM の範囲
44. 44 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..

45. 45 AWS アカウント個別の IaC に関するプラクティス まとめ アカウントの分離レベル保護 DRY、コード品質向上 省力化、ミス防止、排他制御 分割による影響局所化、適用時間短縮 ステージ毎の状態把握が容易 自動チェックによる効率化 透明性向上、オぺレーション効率化 問題や作業阻害要因の排除 再利用性向上 サーバレスローカル環境との両立 1. アカウント種別単位のリポジトリ構成 2. Workspaces によるマルチステージ対応 3. Terraform 実行の独自ラッパー 4. Terraform ディレクトリ構成 5. IaC のブランチ戦略 6. PullRequest による CI 7. ChatOps による IaC の適用 8. 構成ドリフトの検出 9. Module によるパッケージ化 10. SAM との連携について
46. AWS 組織全体 の IaC 46
47. CCoE では、AWS 組織全体の AWS アカウ ントの共通リソース（ベースライン）を Terraform にて管理。 SecurityHub / GuardDuty / AWSConfig 等 のガバナンス関連の設定が含まれる。 新規 AWS アカウント作成時に適用し、ま た、組織全体の共通リソースを変更時にも全 体へ対して適用する。 47 ベースラインについて
48. AWS 組織全体の IaC として Terraform を採用した経緯（当時の選択肢） • CloudFormation StackSets ◦ CloudFormation テンプレートをマルチアカウント/リージョンに対して展開可能 • 独自の Terraform によるベースライン管理 ◦ 多少の作り込みが必要となるが自由度は高い 2019年秋選定時点では、StackSets にて「変更セットの作成」「ドリフト検出」の機能が未提供の ため、Terraform を用いた独自方式を選定。 ※現在では StackSets で変更セットの作成やドリフト検出も可能となっているため、今後新たにベースラインを検討/ 導入する場合は、 東京リージョンがサポートされた ControlTower を含め十分な選択肢となる。 48 ベースラインについて
49. ベースラインの活用方法や設定内容については割愛。下記資料を参照。 49 ベースラインについて AWS Summit Online Japan 2020 • 大規模な組織変遷と100以上のAWSアカウントの横 断的セキュリティガードレール運用について Visional Engineering Blog • 100を超えるAWSアカウント運用におけるガードレー ル構築事例
50. 1. マルチアカウント展開 2. マルチリージョン展開 3. ベースラインの適用 4. 構成ドリフトの検出 50 AWS 組織全体の IaC に関するプラクティス
51. ベースライン適用対象アカウント数分並列にCodeBuild を起動し、それぞれ組織内のアカウントに対して Assume Role にて Terraform を実行する。 Lambda で CodeBuild 呼び出し後に実行情報を DynamoDB へ書き込み、CodeBuild の完了イベントを 受信して処理全体の結果判定を行う。 ※現在では、StepFunctions で Map（動的反復）を利用することで、 よりシンプルに実現が可能。 51 1. マルチアカウント展開
52. Terraform の Workspaces 機能を利用し、 AccountID 毎のワー クスペースに切り替えて適用している。 state ファイルは S3 へアカウント ID ごとのパスで保管する。 52 1. マルチアカウント展開
53. マルチリージョンに展開するリソースは Terraform の Modules にてリソース定義し、 リージョン単位でモジュールを呼び出すことで少ないコード量で実現している。 53 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 ... マルチリージョン展開モジュール使用定義
 2. マルチリージョン展開 ディレクトリ構成イメージ マルチリージョン展開モジュール使用定義イメージ 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 が使えないため、対象リージョン分の定義 が必要となり少し冗長な記述になる。
54. Systems Manager Automation と Slack を活用している。 CCoE では、エンジニアリングチームと AWS のルートアカウントを管理する特権 を有するチームが分かれている。 Automation の aws:approve アクション では、特権所有者（AdminRole）の承認を 経て実行できる仕組みとしている。 54 3. ベースラインの適用
55. 55 ベースラインも、日次で AWS 組織全体の構成ドリフトの検出を行 い、結果を Slack へ通知する。 ベースラインのコード変更を全体へ適用する場合、日跨ぎで段階 的に組織全体へ適用するケースもあるため、DynamoDB にスト アした AWS アカウント単位の最終適用コミットバージョンに対し て構成ドリフトを検査している。 ※ ベースライン管理リソースの変更/削除操作については、基本的には AWS Organizations の SCP にて制限をかけている。 4. 構成ドリフトの検出
56. 1. マルチアカウント展開 2. マルチリージョン展開 3. ベースラインの適用 4. 構成ドリフトの検出 56 AWS 組織全体の IaC に関するプラクティス まとめ 並列実行によりスピーディーに全体適用 モジュールにより管理効率化 承認ステップにより安全な実行フロー AWS 組織全体のベースライン適用を担保
57. まとめ 57
58. 58 まとめ • IaC を疎かにするとサービスの信頼性の問題やチームの活動の課題が生じるケースが多い。 • 運用するリソースは基本的に全て IaC する。しかし、IaC を目的としない。 • IaC によりソフトウェア開発のプラクティスをクラウド（インフラ）へ適用できる。 • Terraform による IaC のプラクティス • プラクティスを適用することで、昨今のリモートワーク状況下でもチーム開発を円滑に進められ、チー ムの生産性やサービスの信頼性を高められる。
59. 59 We are hiring. 一緒に働く仲間を募集中です。 https://www.bizreach.co.jp/recruit/ Visional Tech Blog https://engineering.visional.inc/blog/ Thank you.