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

by CO-OP Sapporo

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

なぜそうなった 

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

AWSアカウントの推移  オンプレから移行済みアカウント: 59 新規システムアカウント: 67 管理系等その他アカウント: 46

Slide 8

Slide 8 text

そんで、なぜそうなった 

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

もう一つの最大の理由 

Slide 12

Slide 12 text

もう一つの最大の理由 

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Before 

Slide 17

Slide 17 text

After 

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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