第2回 雲勉LT【オンライン︓中級者向け】 AWSで仮想IPを使ったAZ冗⻑化 アイレット株式会社 ~ 宛先がIP指定しかできないけどIP変更せずにAZ障害に対処したい︕ ~

アジェンダ 2 0. ⾃⼰紹介 1. はじめに 2. どんな設定︖ 3. どんな要件で使ったの︖ 4. 検証してみた 5. おわりに

０. 講師⾃⼰紹介 3 n 阿部 幸司 • クラウドインテグレーション事業部 企画推進セクション インフラ技術グループ • 経歴 オンプレミスインフラエンジニア(構築,運⽤保守) 10年 クラウドインフラエンジニア(構築,運⽤保守) 3年 • マウンテンバイクに乗ったり登⼭しています。⾝体が⾃然と⼭を求めています。

1. はじめに 4

1. はじめに 5 雲勉LTで取り上げた理由 n お客様要件から実現できる⽅法を模索 n 社内にてこのような⽅法で出来るのでは︖という知⾒があったので検証 n 実際にやってみたら出来た n すごくニッチではあるものの、そういうお客様がいるということがわかった n やり⽅によっては応⽤が聞くのでは︖と思い記録も兼ねて雲勉LTで取り上げた

2. どんな設定︖ 6

2. どんな設定︖ 7 n 構成図と動き • AZ冗⻑化構成 • 仮想IPをVPCに設定して1つのIPで両⽅のAZにアクセスさせる︕ • ※同時に両⽅のAZにはアクセスできないよ︕(Active-Standby構成)

2. どんな設定︖ 8 n 構成図と動き • AZ冗⻑化構成 • 仮想IPをVPCに設定して1つのIPで両⽅のAZにアクセスさせる︕ • ※同時に両⽅のAZにはアクセスできないよ︕(Active-Standby構成)

3. どんな要件で使ったの︖ 9

3. どんな要件で使ったの︖ 10 n オンプレからEC2にデータを転送してRDSに保存 n 冗⻑化してAZ障害時でもデータ転送がされない状態は無くしたい、最低でも最⼩時間に留めたい

3. どんな要件で使ったの︖ 11 n オンプレからEC2にデータを転送してRDSに保存 n 冗⻑化してAZ障害時でもデータ転送がされない状態は無くしたい、最低でも最⼩時間に留めたい Network Load Balancerで 冗⻑化出来るんじゃないのかな︖

3. どんな要件で使ったの︖ 12 n オンプレからEC2にデータを転送してRDSに保存 n 冗⻑化してAZ障害時でもデータ転送がされない状態は無くしたい、最低でも最⼩時間に留めたい n EC2への通信で拠点の機器でDNSが使えずにIPで宛先を指定する必要がある ←New n 拠点が多い等の理由で拠点にある機器の宛先IP変更が簡単に出来ない ←New NLBは固定IPでアクセスできるけどAZ-aのENI(IP) への通信はAZ-aにしか⾏かない。。。 これだとAZ障害時に切り替えができない。。。

3. どんな要件で使ったの︖ 13 こんな⽅法だったら 出来るかもしれないよ 検証してみよう︕ n オンプレからEC2にデータを転送してRDSに保存 n 冗⻑化してAZ障害時でもデータ転送がされない状態は無くしたい、最低でも最⼩時間に留めたい n EC2への通信で拠点の機器でDNSが使えずにIPで宛先を指定する必要がある ←New n 拠点が多い等の理由で拠点にある機器の宛先IP変更が簡単に出来ない ←New

4. 検証してみた 14

4. 検証してみた 15 n 検証環境構築 ・左側のVPCを通信先となる<宛先環境>とする ・右側のVPCを<オンプレ環境>と⾒⽴てる ・環境間はお客様環境想定でTransitGateway経由で通信を⾏う ①環境で利⽤していないIPを仮想IPとする ②TransitGatewayのルートテーブルで 仮想IP※へのターゲットを宛先環境:TransitGatewayアタッチメントにする ③ServerA,ServerBにエイリアスで仮想IPを設定する ④宛先環境のサブネットに紐付いたルートテーブルで仮想IPへのターゲットを宛先環境:ServerAがもつENIに向ける ・ServerA,ServerBの「ソース/宛先チェックを変更」→「停⽌」にチェックを付ける ※仮想IP設定例 # cat /etc/sysconfig/network/ifcfg-eth0:0 DEVICE=eth0:0 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.0.10 NETMASK=255.255.255.0 ① ② ③ ③ ④

4. 検証してみた 16 n 平時の通信経路 ・右側のPVCから仮想IPへのルーティングでTransitGatewayに通信を⾏う ・TransitGatewayのルーティングで仮想IPへのルーティングを左側のVPCのTransitGatewayアタッチメントに通信 ・左側のVPCサブネットのルートテーブルより仮想IPをServerAのENIに通信 構成図は 整える

4. 検証してみた 17 n AZ障害発⽣時の動き ・ルートテーブルで向き先のENIを変更する ・ルートテーブルで仮想IPへのターゲットを宛先環境:ServerBがもつENIに向ける

4. 検証してみた 18 n 切り替え後の通信経路 ・右側のPVCから仮想IPへのルーティングでTransitGatewayに通信を⾏う ・TransitGatewayのルーティングで仮想IPへのルーティングを左側のVPCのTransitGatewayアタッチメントに通信 ・左側のVPCサブネットのルートテーブルより仮想IPをServerBのENIに通信

4. 検証してみた 19 n 切り替え⾃動化 # トリガー ・ServerAをCloudWatchで死活監視を⾏い、それをトリガーにSNS→Lambdaを実⾏ # 切り替え ・LambdaにてRouteTableの変更 > aws ec2 --route-table-id “RouteTable ID” --destination-cidr-block 192.168.0.10/32 --network-interface-id “ServerBのENI-ID”

4. 検証してみた 20 n 考慮点 • 仮想IPはお客様環境、VPCで利⽤していないCIDRから割り当てる • EC2の送信元/送信先チェックを停⽌する必要がある 送信元/送信先チェックを停⽌

5. おわりに 21

5. おわりに 22 要件を聞いた当初は考えた末にこんな要件やりようがあるのかな︖と諦めていましたが、社内で相談を⾏ったところ 今回発表している⽅法の提⽰があり、可能性を感じてうまく要件を満たす構成が取れました。 Lambdaでのルートテーブル切り替えについては、ServerAが死活監視で停⽌を検知した場合にServerBに切り替え る単純なものを記載しましたが、確実性を上げるために実⾏結果確認、再実⾏を⾏うといったさらなる検討の余地が ありますので利⽤に応じて変更できればと思います。 アイレットはクラウドに関する知識、経験は国内トップクラスで、もっと多くの⽅に知ってほしいと思い今回の発表 の題材として取り上げました。まだまだ出ていない興味深い構成、経験が多くあるので引き続きこういった場で発表 できればと思っています。

23