Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Terraformでマルチリージョンデプロイしてみた
Search
Masahiro Iwasaki
December 18, 2023
Technology
1.9k
27
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Terraformでマルチリージョンデプロイしてみた
Masahiro Iwasaki
December 18, 2023
Other Decks in Technology
See All in Technology
ポストモーテム! DDoSからサイトは守れた。 でもビジネスは守れなかった。
bengo4com
0
2.8k
SRE Next 2026 何でも屋からの脱却
bto
0
620
クラウド上のデータ復旧で見落としがちな制約: 医療系 SaaS の BCP 設計から得た教訓
kakehashi
PRO
0
3.4k
GuardrailからGovernanceへ~AIエージェント運用の次の課題~
sbspsy
2
270
SREとQA 二人三脚で進めるSLO運用/sre-qa-slo
sugitak
0
450
「早く出す」より「事業に効く」 ── 顧客の業務サイクルから逆算するAI時代の二重ループ開発と「変化の設計者」 / devsumi2026
rakus_dev
1
210
ruby.wasmとPicoRuby.wasmに対応した仮想DOMライブラリを作ってる話 #kaigieffect_kaigi
sue445
PRO
0
140
「最後に責任を取るのはチーム」— 人間のPRレビューを最小化してアップデートしたメンタルモデル
jnishime_dresscode
0
540
完全自律ロボットを作りたくて、先に開発を自律させた話(ROS Japan UG #63 LT)
rryz09
0
490
LLM/Agent評価:トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜
takkuhiro
1
210
凡エンジニアがこの先生きのこるためには。〜TypeScript完全に理解したい〜
alchemy1115
2
160
ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略
srenext
0
140
Featured
See All Featured
Building an army of robots
kneath
306
46k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Ethics towards AI in product and experience design
skipperchong
2
330
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
500
The SEO Collaboration Effect
kristinabergwall1
1
500
The #1 spot is gone: here's how to win anyway
tamaranovitovic
3
1.1k
Navigating Team Friction
lara
192
16k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
390
Bash Introduction
62gerente
615
220k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
190
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
63
55k
Transcript
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 サービスを構築するには多くの検討事項がある まとめ