Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Terraformでマルチリージョンデプロイしてみた

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

 Terraformでマルチリージョンデプロイしてみた

Avatar for Masahiro Iwasaki

Masahiro Iwasaki

December 18, 2023
Tweet

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 好きなAWSサービス • Step Functions, Lambda, DynamoDB 受賞 • KDDI

    Cloud Ambassadors 2021 • KDDI Cloud SAMURAI 2022 • 2023 Japan AWS ALL Certifications Engineers 岩崎正寛 (Masahiro Iwasaki) KDDI 株式会社 クラウドを活⽤したモバイルインフラ開発業務に従事
  2. • HashiCorp社が提供するIaC(Infrastructure as Code)ツール • インフラをコードで管理でき、数コマンドで環境構築ができる • マルチクラウドに対応 • AWS,

    Azure, GCP, OCI, Alibabaなど • ドメイン特化⾔語であるHCL⾔語でコードを記述 • 宣⾔型⾔語で理想とする状態を定義 • 無償バージョンでも本番環境でのユースケースに使⽤可能 • 内部的にはGo⾔語で実装され、各プロバイダのSDKを使⽤してリソースを作成 Terraformとは
  3. ⾼可⽤性が求められる場合 • 東京/⼤阪のマルチリージョン構成にしたい • パイロットライト、ウォームスタンバイ、マルチサイト Act/Act • リージョン間のVPCを接続したい • VPCピアリング、Transit

    Gateway, VPNコネクション マルチリージョンにまたがってインフラが完全に結合されている場合 • CDNとしてCloudFrontを使⽤し、TLS証明書をACMで発⾏したい • コンテンツを構築するリージョン、TLS証明書を発⾏するバージニア北部リージョン • GuardDutyを使⽤している全リージョンにデプロイしたい マルチリージョンデプロイが求められるケース
  4. 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 コア、プロバイダ
  5. 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
  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
  7. 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パラメータを指定 複数プロバイダの指定⽅法
  8. マルチリージョンを扱う際に気をつけること グローバルリソースの取り扱い • グローバルリソースはモジュールを適切に管理しなければリージョン間でリソースの衝突が⽣じる • IAM, Route53, WAF, CloudFrontなど •

    ⼯夫⽅法 • 機能単位やライフサイクルごとにモジュールを作り、各リージョンで適切に呼び出す • count と三項演算⼦の利⽤︓ • terraform_remote_stateで別のTerraformステートで管理されているリソースを読み出す マルチリージョン Act/Act構成のアプリケーションの考慮事項⼀例 • リージョン間のレイテンシ • DB書き込みポリシー︓⼀元管理 or 分散管理 • DBレプリケーション • DRポリシー • グローバル認証認可 etc count = var. region == ”ap-northeast-1" ? 1 : 0
  9. 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 ⼀部抜粋
  10. [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(⼤阪) 以下のとおり疎通が取れている︕⼤阪->東京も同様 疎通確認
  11. • Terraformでマルチリージョンデプロイをしてみた • 複数プロバイダを⽤いてマルチリージョンにリソースを作成するケースは意外と多い • ⾼可⽤性アプリケーション • リージョン間のVPC接続 • CloudFront⽤

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