AWSアカウントをOrganizations配下に入れようとしたらVPCまるごとお引越しをした件 / JAWS PANKRATION 2021 / What makes me to migrate entire VPC

2021/11/21 JAWS PANKRATION 2021で発表した時の資料の日本語版です。
英語版の資料は以下です。
https://www.slideshare.net/naomiyamasaki5/what-makes-me-to-migrate-entire-vpc-jaws-pankration-2021

Transcript

1. AWSアカウントをOrganizations配下に入れようとしたら
 VPCまるごとお引越しをした件
 JAWS-UG アーキテクチャ専門支部 / JAWS-UG 情シス支部
 Naomi Yamasaki

2. AWS SAMURAI 2015 
 JAWS-UG アーキテクチャ専門支部 
 JAWS-UG 情シス支部 
 山﨑 奈緒美
 生活協同組合コープさっぽろ
 デジタル推進本部
 インフラエンジニア
 @nao_spon
 I ♡
 Route53
 IAM
 Organizations

3. なぜそうなった

4. 2020年よりAWS All inを目指すことになりました
 • 190システム、650サーバーがオンプレ環境にある
 • CloudEndure Migrationで移行
 • 新規システムはクラウドファーストで検討

5. AWS Organizationzって良いですよね
 • アカウント管理、サービス利用制限、ユーザーコントロール
 ◦ Control Tower
 ◦ SCP
 ◦ OU
 ◦ AWS SSO
 • 環境の標準化、ポリシーの適用
 ◦ CloudFormation Stack Sets
 ◦ AWS Security Hub
 ◦ AWS Config

6. • 基本的に1システムにつき3アカウント発行
 ◦ 開発環境、検証環境、本番環境でアカウントを分ける
 ◦ 諸事情により少ない環境のみのものもあり
 • ネットワーク
 ◦ 各VPCはTransit Gatewayで接続 
 ◦ AWS とデータセンターはDirect Connectで接続
 設計について

7. AWSアカウントの推移
 オンプレから移行済みアカウント: 59 新規システムアカウント: 67 管理系等その他アカウント: 46
8. そんで、なぜそうなった

9. • 本格開始をする前に作られたアカウント
 • 当時はスモールスタートのつもりがサービスが成長した
 • このアカウント達もOrganizations配下に入れたい
 例外となる3つのアカウント

10. なぜAWS Organizationsに入れるべきか
 これらの設定を各アカウントへ個別に設定しなければならなくなる
 ◦ アカウント管理、サービス利用制限、ユーザーコントロール
 ▪ Control Tower
 ▪ SCP
 ▪ OU
 ▪ AWS SSO
 ◦ 環境の標準化、ポリシーの適用
 ▪ CloudFormation Stack Sets
 ▪ AWS Security Hub
 ▪ AWS Config

11. もう一つの最大の理由

12. もう一つの最大の理由

13. そのままではTransit Gatewayに接続できない

14. そのままではTransit Gatewayに接続できない
 • 拠点とCIDRブロックが重複している
 • リソース量に対してCIDRブロックが大きすぎ

15. • したいこと
 ◦ 開発・検証・本番が相乗りになっているのを分割したい
 ◦ フロントエンド・バックエンドシステムのリソースが
 同居しているのを分割したい
 ◦ 稼働中環境での変更は混乱を生みそうなので避けたい
 • したくないこと
 ◦ CIDRブロックの縮小はしたくない
 ◦ 稼働中の本番環境をあまりいじりたくない
 VPCをまるごと別アカウントへお引越し

16. Before

17. After

18. お引越しの順番
 1st: 検証環境
 2nd: 本番環境
 3rd: 開発環境

19. お引越しで一番苦労したもの…
 Aurora migration
 
 

20. • シンプルで簡単な方法
 • レプリケーション環境の作成が簡単であること
 • binlogレプリケーションは設定が面倒そうだった
 • DMSは簡単そうに見えた
 
 どのようにしてDB移行を行うか

21. • シンプルで簡単な方法
 • レプリケーション環境の作成が簡単であること
 • binlogレプリケーションは設定が面倒そうだった
 • DMSは簡単そうに見えた♡
 
 どのようにしてDB移行を行うか

22. 簡単だと言ったな。
 あれは嘘だ。

23. DMSの罠
 • テーブルのフルロード実行前にスキーマを予め移行すべし
 ◦ デフォルト、ユニークキー、コメントが消えてしまう
 ◦ int型の桁数も変わってしまう
 • 夜間バッチの際にレプリケーションがOOMエラー
 ◦ 夜間バッチ実行帯以外の通常稼働時は問題なし
 ◦ レコードのDeleteとInsertが一度に大量にあると落ちる

24. 悪夢の夜間バッチ
 • 夜間バッチでFailした後、数時間経つとレプリケーションされて くるがビジネス要求に合わない
 • DMSレプリケーションインスタンスを最大までスケールアップし てもダメ
 • メモリ768GiBでOOMってどゆこと
 

25. DMSを使うことは諦めた
 • だがしかし検証環境切替まであと1週間
 • 本番環境切替まであと3週間
 • 検証環境の切替を本番作業時のリハにしたいので
 それぞれで違う方法を取りたくない
 • binlogレプリケーションでやるには時間が足りない…

26. 「やってみなはれ」とは言えない

27. どのように解決したか
 • 夜間バッチがAM2:00-4:00で実施されるため
 そもそもサービス自体がその時間帯は止まっている
 • 夜間バッチ実行時刻をずらして実行することが可能
 • 夜間バッチ実行時間帯を切替作業時間として使える
 • DBスナップショットを共有してAuroraクラスター復元
 • 当時の状況ではこれが一番ベストな方法だった

28. AWS KMS keyによる問題
 デフォルトのaws/rdsキーで暗号化している場合、
 DBスナップショットはそのままでは別アカウントへ共有できない

29. どのようにしたか
 • 既存アカウント側作業
 ◦ KMSでカスタマーマネージドキーを作成する
 ◦ 新アカウント側のIAMユーザーorRoleにKey Policyで権限付与
 ◦ DBスナップショットを作成
 ◦ DBスナップショットを一旦コピーし、その際に
 作ったカスタマーマネージドキーを選ぶ
 ◦ DBスナップショットを新アカウントへ共有する
 • 新アカウント側作業
 ◦ 共有されたDBスナップショットをコピーし、その際にaws/rdsキーを選ぶ
 ◦ コピーしたDBスナップショットでAuroraクラスターを作成する

30. • 手作業で作られたリソース
 • CloudFormationで作った後に
 手作業による変更が加えられているリソース
 CloudFormationでの問題

31. CloudFormationでの問題
 • 作るものはほぼ同じなので各環境でテンプレートを使いまわした い
 • CloudFormation Stackへのインポートもできるが
 そのためには変更点をテンプレートに書き起こす必要有り
 • 結局書き起こすのなら新しく作り直すほうが早い

32. CloudFormation vs CDK
 • 現状を細かく再現しようとするとローコンテキストディスクリプショ ンで書くことになる
 • ローコンテキストディスクリプションで記述する場合
 CloudFormationテンプレートで書くのとほぼ一緒
 • YAMLのほうが書くの慣れてる

33. • AWS CLIのdescribeコマンドはいいぞ
 • 名前や環境に依存する部分はMappingsを
 変数のように使うと同じものを複数作る場合に楽
 • パラメーターだと実行時に何を指定したのかが残らない
 どのようにしてテンプレートを書いたか

34. • 1リソースに付き1テンプレートを作成
 • 作った数: 
 ◦ 検証環境: 44
 ◦ 本番環境: 60
 • 大量だけど大体はコピってMappingsの部分を変えるだけ
 つくったテンプレートの数

35. お引越し当日…
 • 特に大きな問題はなかった
 • 切替後もサービスに関わる大きな問題はなかった
 • 開発環境は大きなリリースがあるのでそれまではPEND

36. まとめ
 • NW設計大事、超大事
 • VPCのCIDRブロックは大きくしすぎない。
 /16は滅多に要らない
 • DMSは一度に大量処理が無いのなら合うと思う
 • 対象DBがどのような処理をしているかを把握する
 • その上でベストな方法を選択する
 • Infrastructure as Code大事、超大事

37. 状況によっては
 ベストプラクティスではない方法が
 ベストなこともある

38. まだ2アカウントあるよ！
 また?!