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