Terraformでマルチリージョンデプロイしてみた 2023/12/18 JAWS-UG東京 ランチタイムLT会 #6 KDDI株式会社 岩崎正寛

⾃⼰紹介 好きなAWSサービス • Step Functions, Lambda, DynamoDB 受賞 • KDDI Cloud Ambassadors 2021 • KDDI Cloud SAMURAI 2022 • 2023 Japan AWS ALL Certifications Engineers 岩崎正寛 (Masahiro Iwasaki) KDDI 株式会社 クラウドを活⽤したモバイルインフラ開発業務に従事

• Terraformとは • マルチリージョンデプロイが求められるケース • デプロイ⽅法 • やってみた • まとめ アジェンダ

• Terraformとは • マルチリージョンデプロイが求められるケース • デプロイ⽅法 • やってみた • まとめ アジェンダ

• HashiCorp社が提供するIaC(Infrastructure as Code)ツール • インフラをコードで管理でき、数コマンドで環境構築ができる • マルチクラウドに対応 • AWS, Azure, GCP, OCI, Alibabaなど • ドメイン特化⾔語であるHCL⾔語でコードを記述 • 宣⾔型⾔語で理想とする状態を定義 • 無償バージョンでも本番環境でのユースケースに使⽤可能 • 内部的にはGo⾔語で実装され、各プロバイダのSDKを使⽤してリソースを作成 Terraformとは

• Terraformとは • マルチリージョンデプロイが求められるケース • デプロイ⽅法 • やってみた • まとめ アジェンダ

⾼可⽤性が求められる場合 • 東京/⼤阪のマルチリージョン構成にしたい • パイロットライト、ウォームスタンバイ、マルチサイト Act/Act • リージョン間のVPCを接続したい • VPCピアリング、Transit Gateway, VPNコネクション マルチリージョンにまたがってインフラが完全に結合されている場合 • CDNとしてCloudFrontを使⽤し、TLS証明書をACMで発⾏したい • コンテンツを構築するリージョン、TLS証明書を発⾏するバージニア北部リージョン • GuardDutyを使⽤している全リージョンにデプロイしたい マルチリージョンデプロイが求められるケース

• Terraformとは • マルチリージョンデプロイが求められるケース • デプロイ⽅法 • やってみた • まとめ アジェンダ

マルチリージョンを扱うにはProviderの理解が重要 provider "aws" { region = "ap-northeast-1" } Terraform プロバイダ定義

Terraform Google Cloudプロバイダ Azureプロバイダ AWSプロバイダ Terraformコア AWS RPC HTTP Terraformコア • Terraformバイナリであり、Terraformの基本的機能を提供 • CLI(plan, applyなど)、HCLのパーサとインタプリタ、ステートファイルの読み出しと書き込みロジック Terraformプロバイダ • Terraformコアに対するプラグイン。プラットフォーム（AWSなど）ごとに存在する Azure Terraform プロバイダ プラットフォーム Google Cloud HTTP HTTP Terraform コア、プロバイダ

Terraform AWSプロバイダ AWS AWS Cloud ap-northeast-1 シングルリージョンの場合 これまでどおりにproviderを定義する terraform { required_providers { aws = { source = "hashicorp/aws" version = "5.31.0" } } } provider "aws" { region = "ap-northeast-1" } Terraform v1.6.6

terraform { required_providers { aws = { source = "hashicorp/aws" version = "5.31.0" } } } provider "aws" { alias = ”tokyo" region = "ap-northeast-1" } provider "aws" { alias = ”osaka" region = "ap-northeast-3" } AWSプロバイダ AWS AWS Cloud ap-northeast-1 ap-northeast-3 マルチリージョンの場合 リージョンごとにproviderを定義し、それぞれにalias, regionを設定する Terraform Terraform v1.6.6

module ”demo" { source = "../../modules/demo" providers = { aws = aws. tokyo } env = local.env } resource "aws_instance" ”demo" { provider = aws.tokyo ami = "ami-xxxxxxxxxxxxx" instance_type = "t4g.nano" } 作業ディレクトリ(provider.tfと同じ階層)の場合 providerパラメータを指定 モジュール内で使⽤する場合 moduleのprovidersパラメータを指定 resource "aws_instance" ”demo" { provider = aws.tokyo ami = "ami-xxxxxxxxxxxxx" instance_type = "t4g.nano" } Providerパラメータを指定 複数プロバイダの指定⽅法

マルチリージョンを扱う際に気をつけること グローバルリソースの取り扱い • グローバルリソースはモジュールを適切に管理しなければリージョン間でリソースの衝突が⽣じる • IAM, Route53, WAF, CloudFrontなど • ⼯夫⽅法 • 機能単位やライフサイクルごとにモジュールを作り、各リージョンで適切に呼び出す • count と三項演算⼦の利⽤︓ • terraform_remote_stateで別のTerraformステートで管理されているリソースを読み出す マルチリージョン Act/Act構成のアプリケーションの考慮事項⼀例 • リージョン間のレイテンシ • DB書き込みポリシー︓⼀元管理 or 分散管理 • DBレプリケーション • DRポリシー • グローバル認証認可 etc count = var. region == ”ap-northeast-1" ? 1 : 0

アジェンダ • Terraformとは • マルチリージョンデプロイが求められるケース • デプロイ⽅法 • やってみた • まとめ

構成図 AWS Cloud ap-northeast-1 VPC (10.0.0.0/16) Private subnet (10.0.0.0/18) ap-northeast-3 VPC (172.16.0.0/16) Private subnet (172.16.0.0/18) EC2 EC2

Terraform 記述例（⼀部抜粋） terraform { required_providers { aws = { source = "hashicorp/aws" version = "5.31.0" } } } provider "aws" { region = "ap-northeast-1" alias = "tokyo" } provider "aws" { region = "ap-northeast-3" alias = "osaka" } resource "aws_vpc" "vpc_tokyo" { provider = aws.tokyo cidr_block = "10.0.0.0/16" tags = { Name = ”demo-northeast-1-vpc" } } resource "aws_vpc" "vpc_osaka" { provider = aws.osaka cidr_block = "172.16.0.0/16" tags = { Name = ”demo-ap-northeast-3-vpc" } } resource "aws_vpc_peering_connection" "peer_tokyo_to_osaka" { provider = aws.tokyo vpc_id = aws_vpc.vpc_tokyo.id peer_vpc_id = aws_vpc.vpc_osaka.id peer_region = "ap-northeast-3" auto_accept = false } resource "aws_vpc_peering_connection_accepter" "peer_tokyo_to_osaka_accept" { provider = aws.osaka vpc_peering_connection_id = aws_vpc_peering_connection.peer_tokyo_to_osaka.id auto_accept = true } module ”vpc" { source = "../../modules/vpc" providers = { aws.tokyo = aws.tokyo aws.osaka = aws.osaka } } module ”compute_tokyo" { source = "../../modules/compute" providers = { aws = aws.tokyo } } module ”compute_osaka" { source = "../../modules/compute" providers = { aws = aws.osaka } } プロバイダ定義 module呼び出し VPC module ⼀部抜粋

[ec2-user@ip-10-0-2-42 ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone/ ap-northeast-1a [ec2-user@ip-10-0-2-42 ~]$ [ec2-user@ip-10-0-2-42 ~]$ ssh -i osaka-keypair.pem [email protected] , #_ ~¥_ ####_ Amazon Linux 2023 ~~ ¥_#####¥ ~~ ¥###| ~~ ¥#/ ___ https://aws.amazon.com/linux/amazon-linux-2023 ~~ V~' '-> ~~~ / ~~._. _/ _/ _/ _/m/' Last login: Sun Dec 17 15:29:10 2023 from 10.0.2.42 [ec2-user@ip-172-16-41-78 ~]$ [ec2-user@ip-172-16-41-78 ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone/ ap-northeast-3a [ec2-user@ip-172-16-41-78 ~]$ ap-northeast-1(東京) -> ap-northeast-3(⼤阪) 以下のとおり疎通が取れている︕⼤阪->東京も同様 疎通確認

アジェンダ • Terraformとは • マルチリージョンデプロイが求められるケース • デプロイ⽅法 • やってみた • まとめ

• Terraformでマルチリージョンデプロイをしてみた • 複数プロバイダを⽤いてマルチリージョンにリソースを作成するケースは意外と多い • ⾼可⽤性アプリケーション • リージョン間のVPC接続 • CloudFront⽤ TLS証明書 ACM • GuardDuty • etc.. • Providerとリージョンは1対1対応 • 複数プロバイダを利⽤する場合は、リージョンごとにaliasとregionを指定しProviderを定義する • マルチリージョンアプリケーションの構築は簡単ではない • マルチリージョンのデプロイ⾃体は⽐較的簡単に⾏えるが、洗練されたマルチリージョン Act/Act サービスを構築するには多くの検討事項がある まとめ