AWS Summit Onlineのちょっとしたメモ②

AWS Summit Onlineのメモ

AWS Summit Onlineの気になったセッションを視聴してのちょっとしたメモになります。

・AWS のサービスを使ったオンプレミスからのデータベース移行

◆AWSにデータベースを移⾏する際のパターンと移⾏⽅法
　
　パターン1：Re-Host
　オンプレミスのデータベースをなるべく環境を変えずにAWSに移行すること
　移行に対するリスクが小さい
　
　パターン2：Re-Architecture
　オンプレミスからAWSへの移行に合わせてアーキテクチャの変更をする
　例：ORACLEからPostgreSQLへ変更をすることができる
　エンジンの変更を行うので移行の際は検証をしっかりと行う必要がある
　
　パターン3：(Re-Host or Re-Platform) & Re-Architecture
　AWSへの移行の際はエンジンを変えずに、AWS上でエンジンを変更する
　
　移⾏の流れとAWSで提供するDB移⾏サービス
　　Schema Conversion Tool（SCT）
　　　Assessment（移行難易度の調査）
　　　Schema conversion（スキーマの移行）
　　　Code conversion（SQL、プロシージャーの移行）
　
　　Database Migration Service（DMS）
　　　Data migration（データの移行）
　　　Validation（データ移行の整合性をテスト）

◆SCT/DMSの概要
　
　Schema Conversion Tool
　データベースのスキーマを変換するツール
　ORACLE、MySQLなど様々なデータベースに対応している

　Database Migration Service
　データベースの中に格納されているデータをマイグレーションするサービス
　ダウンタイムを最小化したデータ移行が可能
　S3、Neptune、Kinesisなどのデータベース以外にも適応可能

◆SCT/DMSを活⽤したデータベース移⾏の具体例
　オンプレミスのORACLEからAurora PostgreSQLへの移行
　SCTでAssessment、Schema conversion、Code conversionの3ステップを行う
　DMSでData migration、Validationを行う
　
　SCTはオンプレミス側の端末にインストールしてデータベースに接続する
　DMSはAWS側にインスタンス作成
　AWS側のネットワークからオンプレミス側のデータベースに接続するので、
　VPNやDirect Connectなどのセキュアな接続環境が必要になる

　SCTによるデータベースの移⾏評価
　グラフィカルなアセスメントレポートを出力可能
　自動変換ができる割合や人の手でやらなければいけない割合が出力される

　Database Migration Playbook
　AWSがデータベース移行のベストプラクティスをまとめたもの

　SCTによるスキーマ、コード変換
　SCTで移行後のパフォーマンスが出るかは担保していないのでテストを行う必要あり

　DMSを使ったデータ移⾏⼿順のイメージ
　DMSインスタンスを作成
　DMSインスタンスからソースへ接続、ターゲットのデータベースへも接続する。接続する情報の事をエンドポイントと呼ぶ
　エンドポイントを使用して移行タスクを設定
　　Full Load：ある断面のデータを最初から最後まで移行する
　　Full Load + CDC：移行中にソースで発生する更新データも移行する
　　CDCのみ：ある時点からの差分のみ移行する
　移⾏タスクのモニタリング
　正しくタスクが動いているのか、ソース側で発生した更新データをどのくらいの遅延でレプリケーションできているか

　レプリケーションインスタンスの作成は適切なインスタンスクラス、ストレージ容量を指定する

　DMSを使った最⼩限のダウンタイムのデータ移⾏
　　1.初期データ移⾏（Full Load）
　　2.オンプレミスのデータ更新（CDC）
　　3.トランザクションログを参照し適応
　　4.オンプレミスに向いているアプリケーションの停止
　　5.差分データが無くなることをDMSで確認
　　6.差分データが適用された段階でアプリケーション再開
　4～6が最小限のダウンタイム

　DMSのデータ検証機能
　DMSの場合はデータのValidationはオプション
　データのValidationと移行は非同期

・パケットの気持ちになって辿る Amazon VPC のルーティング

引用資料

◆VPCの主要な概念
　AWSの各種サービスはリージョンというデータセンタークラスタで提供されている
　日本には東京リージョン、大阪ローカルリージョンがある
　リージョンの中にはアベイラビリティゾーン(AZ)というデータセンタクラスタがある
　AZは電源、ネットワークが独立しているので障害発生時に他のAZに影響が無いようにしている
　⾼可⽤性のためにマルチAZ構成を推奨している

　VPC
　リージョンの中でAZを跨いで構成できる独立したプライベートネットワーク領域

　サブネット
　VPCの中にルーティングポリシー単位で定義
　AZ単位で作成

　ルートテーブル
　VPCやサブネットでデフォルトで動作しているルータの経路情報を登録している
　EC2インスタンスから見るとデフォルトゲートウェイとして見える

　VPCには様々なゲートウェイがある(Internet Gateway,NAT Gateway,Virtual Private gateway,AWS Transit Gatewayなど)
　AWSの方で冗長化しているので使う側は考える必要が無い

◆オンプレミスネットワークとの⽐較で理解するVPC
　VPCを作ると→オンプレミスではDNSサーバを設定した状態に近い
　サブネットを作ると→オンプレミスではVLANやL2ネットワークを作ることに近い
　EC2を作ると→オンプレミスではスイッチにサーバを接続してOSをインストールした状態に近い

◆VPC通信の実際
　
　EC2 AからEC2 Bに対してHTTPアクセスする場合
　EC2 BのMACアドレスを知るためにEC2 AからブロードキャストでARPが飛ぶ
　Host Aはマッピングサービスという外部のWebサービスへの問い合わせに変換
　マッピングサービスからEC2 BのMACアドレスとHost BのIPアドレスが返ってくる
　返ってきた結果をARP ReplyとしてEC2 Aに渡す
　EC2 Aは実際に送りたいデータパケットを構成してEC2 Bに送る

　Host AからHost Bにパケットを投げる際に元のパケットに対してVPC IDでカプセル化を行う
　VPC内の通信では正規のインスタンスからの通信かどうかValidationしている
　Host Bはマッピングサービスに正規のインスタンスかどうか問い合わせている
　問い合わせの結果から問題が無ければカプセル化を解いてEC2 Bにパケットを渡す
　普段は意識する必要のない通信
　VPCの上ではL2/L3の通信が行われている

◆VPCの全体像
　EC2インスタンスを収容するホスト群

　Edge
　Internet Gateway,Virtual Private Gateway,VPC Endpoint(Gateway)などをホストしている

　Hyperplane
　NAT Gateway,Transit Gateway,VPC Endpoint(Gateway)などをホストしている

◆クラウドネットワークを設計するときは
　主な設計パターン
　VPC←→インターネット
　VPC←→オンプレミス
　VPC←→VPC
　の3パターン
　ルータの役割を果たすコンポーネントがどこにあるか、どういった経路を持っているかを考える

◆パケットの気持ちで辿り設計を考えてみましょう
　1.VPC内からNAT GWを介してInternetにアクセス
　　パブリックサブネットにNAT GWを配置、EC2インスタンスをプライベートサブネットに配置
　　EC2は自分のサブネットの外にあるものはとにかくデフォルトゲートウェイに投げる
　　プライベートサブネットのルートテーブルにパケットを投げる
　　プライベートサブネットのルートテーブルにはNAT GW宛のルーティングを書いておく必要がある
　　ルートテーブルに従ってNAT GWにパケットを投げる
　　パケットを受け取ったNAT GWはパブリックサブネットのルートテーブルにパケットを投げる
　　(NAT GWはルーティングを行わない)
　　パブリックサブネットのルートテーブルはInternet GW宛のルーティングを書いておく必要がある
　　ルートテーブルに従ってInternet GWにパケットを投げる
　　Internet GWはAWSが管理しているのでそれ以降の経路はユーザ側で確認できない(する必要が無い)

　2.VPC内からVGWを介してオンプレミスにアクセス
　　AWS Direct Connect
　　専用線や閉域網を使用して自社とAWSを接続するサービス
　　Direct Connect Locationを介して接続する
　　BGPを使用して経路交換をしている

　　EC2インスタンスはルートテーブルにパケットを投げる
　　ルートテーブルには宛先がオンプレミスのサーバのIPアドレスはVGWにパケットを投げるルーティングを書いておく
　　ルートテーブルに従ってVGWにパケットを投げる
　　VGWにパケットが届くとVGWの経路情報に載っているBGPで通知されたオンプレミスのカスタマーゲートウェイに投げる
　　カスタマーゲートウェイにパケットが届いた後はAWSとは無関係な普通のルーティング

　3.VPC内からTGWを介して他のVPCにアクセス
　　Transit Gateway(TGW)
　　Transit Gatewayを作成するとデフォルトで1つのルートテーブルができる
　　必要に応じて複数のルートテーブルをホストできる
　　VRFのように1つのルータで複数のルーティングテーブルを持たせているイメージ
　　VPCと接続する際はAttachmentを作成
　　アソシエーションという設定でVPCの外に出るアウトバウンドの通信を制御
　　Attachmentから外に出るときにどのルートテーブルを使うかを指定できる
　　プロパゲーションという設定でインバウンドの通信を制御

　　EC2 Aからサブネットのルートテーブルへパケットを投げる
　　ルートテーブルには宛先がVPC BのCIDRはTGWに投げるルーティングを書いておく
　　ルートテーブルに従ってTGWにパケットを投げる
　　パケットはAttachmentを介してTGWに届く
　　TGWはアソシエーションの設定に従ってルートテーブルを選択
　　プロパゲーションの設定でVPC Bへの経路が登録されているルートテーブルを選択する

◆まとめ
　AWSのルーティングに必要な知識はオンプレミスと同じ
　ルータの場所やパケットの動きを理解しておく
　オンプレミスとは違い可用性やスケーラビリティの設計はクラウドに任せられる