見出し画像

【動画レポ】AWSアカウントをOrganizations配下に入れようとしたらVPCまるごとお引越しをした件〜JAWS PANKRATION 2021 ~Up till Down~ より #jawspankration

今日は2021年の11月20日から21日にかけて行われた「JAWS PANKRATION 2021 ~Up till Down~」の動画が公開されていたので、セッションとしてはトリを努めた山崎さんの動画「AWSアカウントをOrganizations配下に入れようとしたらVPCまるごとお引越しをした件」を見返そうと思います。
このセッションを取り上げた理由は多分この問題は自分の周辺にも降りかかりそうだから・・・・そう思っていつもの爆速レポートをFacebook宣言、しかも本人に見られて居たのですが、ワタクシの知識不足でスピードについていけずレポートは断念した経緯があります。
このくやしさを来年に持ち越さないためにも、しっかりとレポートしてみたいと思います。

動画はこちらです


JAWS PANKRATION 2021とは?

JAWS PANKRATION 2021はAWS(Amazon Web Service)のユーザーコミュニ的であるJAWS-UG(Japan AWS User Group)の大規模イベントです。JAWS-UGには「JAWS DAYS」という年次のビッグイベントがありますが、それとは別のイベントで前身は昨年オンラインで24時間連続で開催された「JAWS SONIC & Midnight JAWS 2020」です。今年は全世界とのコミュニティイベント「JAWS PANKRATION 2021」とリニューアルし、全世界のスピーカーも参加しての開催となりました。
そうなると問題が「言語の壁」。
それを克服するためにこの「JAWS PANKRATION 2021」では自動翻訳機「ポケトーク」をクラウドの配信システムと連携させています。日本のスピーカーもポケトークにより正しく翻訳してもらうためにゆっくりと正しい日本語で話しをしています。

その様子を見るだけでも価値がありますので、ぜひyoutubeチャンネルに登録して動画を御覧ください。





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


JAWSアーキテクチャ支部と情シス支部の運営をしている山崎(ヤマサキ)さんは「コープさっぽろ」のインフラエンジニアです。


そうなった背景

「コープさっぽろ」では190のシステム650のサーバを保有
 ⇒すべてAWSにCloudEnduneMigrationで移行
 ⇒新規システムはクラウドを使用する方針

たくさんのアカウントを管理
 ⇒AWS Organization を使って組織にアカウントを所属させると便利
・アカウントやサービス、ユーザーロールの制御ができる
・環境の標準化やセキュリティーポリシーを一括で制御

アカウントデザイン
・アカウントは環境ごとに発行(1システム3つ)
・それぞれのVPCはTransit Gatewayを利用して接続
・AWSとデーターセンターの接続はダイレクトコネクト

現在の状況
・すでに170のアカウントが存在
・以前に試行で使った3つのアカウントが取り残される
 ネットワーク接続で無駄や無理が発生

画像1

 ⇒この3つを組織に所属させるのが今回の取組


マイグレーションの実施


VPCのマイグレーションを実施
 ・アカウントを環境ごとに分ける
 ・環境をフロントとバックに分割
 ・稼働している環境での混乱を避ける
 ・Transit Gatewayに接続

画像2

スケジュール
ステージング環境⇒本番環境⇒開発環境の順に実施


Auroraのマイグレージョン(最も難しいポイント)

バイナリレプリケーションは難しそう・・
データベースマイグレーションサービス
の利用が簡単そう?

画像3

しかし
・ユニークキーやデフォルトが消えて整数系の桁数が変わる
⇒フルロード前に定義を新しいAuroraのテーブルにマイグレーションする必要がある 

・メモリ不足でデータのレプリケーションが失敗
⇒その後、時間を書けてレプリケーションは実行されるが遅延が大きい

インスタンスを最大にして再チャレンジ ⇒ やはり失敗
・・・768GBのメモリでも無理

・・・・データベースマイグレーションサービスの利用を断念

・ステージングの1周間前、本番切り替えの3週間前の決断
・バイナリレプリケーションの検証には時間が足りない

問題の解決

・午前2時から4時にかけてが本番システムのダウンタイム
・夜間バッチの実行時間をずらすことも可能

データベーススナップショットの利用
・新しい環境にデータベーススナップショットを共有
・そこから新しい環境で復元

画像4


そのままの鍵では共有できない
・AWSで用意されている鍵では新しい環境に共有できない
 ⇒カスタマーマネージドキーを利用

CloudFormation利用にあたっての課題
・手作業で作成されたリソース
⇒手作業で作ったリソースはCloudFormation Stackにインポート可能
・手作業で変更してしまったリソース
⇒手作業で修正したリソースはテンプレートに書き起こす必要がある

・・・すべてのCloudFormationテンプレートを新たに書き起こす

・CDKの利用も考えたが工数的には変わらない
・YAMLのほうが慣れてい

テンプレートの作成はAWS CLIのdescribeコマンドを利用

・項目名や値がCloudFormationの記述に似ていて書起しやすい
・マッピングを変数のように使用すると名前や環境に依存する部分を簡単に変更できる

・1つのリソースに対し1つのテンプレートを合計100個以上
・同じ役割のリソースはコピー+変更なので楽

切替は成功 

・大きなトラブルはない
・開発環境は大きなアップデートがあるのでそれまで待ち


まとめ

・最初のネットワーク設計は大事
・VPCには大きすぎるネットワークを割り当てない
・データマイグレーションサービスは1度に大量のデータでなければマッチする
・対象データベースの使われ方を理解する必要がある
 ⇒その上で適切な方法を選ぶ
・IaS(infrastracture as Code)は大事

自分たちの状況によってはベストプラクティスとは違った選択がベストなこともある


実は3つの環境のうちの1つだけであと2つ残っています

画像5


画像6


最後に感想

この事例はAWSを始めとするクラウド導入を始めた後にはけっっこういい頻度でぶち当たりそうな話なので、非常にためになりました。
クローズドなオンプレの時代の技術と違って、ユーザーが選択することが出来る方法はいくつもあります。しかも松竹梅みたいなランク状のような形ではなく、それぞれ別々の強みや弱気をもった特性をもった選択肢で、自分たちの環境や置かれた状況、スケジュールやコストをしっかり考えて選択していくのは、マイグレーション以外の場面にも応用できる考え方だと思います。

最後に

こういうノウハウが詰まったJAWS PANKRATION 2021 ~Up till Down~の動画が70以上あります。
気になるテーマもあると思いますのでぜひ見てくださいね


いいなと思ったら応援しよう!

keita
チップもらったらきっとMidjourneyに課金すると思います