AWSマルチリージョンにおける高可用性方式を実装してみる

こんにちは、SCSKの茂木です。

昨今、重要なシステムのBCP対策としてマルチリージョンでの冗長化をよく目にします。
障害や災害が発生した際のダウンタイムを最小化やデータを複数の場所に分散することによるシステムの信頼性向上
などを目的としたこの構成ですが、AWS上でどう実装すればいいのか気になりました。

なので、今回はAWS Transit Gatewayを用いてマルチリージョンにおける高可用性方式を実装してみます。

はじめに

本記事では、DRBDでのデータレプリケーションを想定したマルチリージョン構成について解説します。

DRBD（Distributed Replicated Block Device）は、Linuxシステムにおけるストレージレベルのデータレプリケーションソフトウェアで、複数のサーバー間でデータをリアルタイムに同期し、高可用性を実現するために使用されます。

第10回　DRBD × LifeKeeperの高可用性リアルタイムレプリケーションを探る

データのリアルタイムレプリケーションを実現するDRBD（Distributed Replicated Block Device）とLifeKeeperの可能性について説明します。

blog.usize-tech.com

2024.10.25

マルチリージョンでの冗長化を図るために、クラスタノードは3台構成とし、
クライアント及びノード間の通信をを効率的に管理するためにAWS Transit Gatewayを採用しております。

クライアント通信は仮想IPアドレスをターゲットに行われます。この仮想IPアドレスは、複数の拠点やデータセンターからの通信を一元的にハンドリングする役割を果たします。

なお、本稿では一般的なAWSサービス（EC2など）の構築手順や基本的な説明については割愛しています。そのため、AWSサービスの基本的な操作方法については、別途AWSの公式ドキュメントなどをご参照ください。

全体構成

構成要素と役割

構成要素	説明
NATインスタンス (LKDRBD-nat,LKDRBD-nat-2)	Elastic IPを設定し、Publicなサブネットに配置します。 クラスターノードはNATインスタンス経由でAWSのAPIを使ってルートテーブルを制御の内容を書き換えます。 AWSのAPIを使うにはインターネットにアクセスできることが前提となります。 AWSの新機能のPrivate Linkを使うことでインターネットに出ずにAPIをたたけるようになりましたが、本記事では従来通りのNATインスタンスを使う方式を前提としています。
踏み台Windowsサーバー (LKDRBD-windows)	Publicなサブネットに配置します。クラスターノードの設定やメンテナンス作業は全て踏み台サーバー経由で行います。 お手元のPCからRDP接続し、踏み台Windowsサーバーとクラスターノード間はSSHで通信します。
クラスターノード (LKDRBD-1,LKDRBD-2,LKDRBD-3)	インターネットにアクセスできる必要が無いので、Privateなサブネットに配置します。 今回の検証環境ではファイルシステムの冗長化を行っています。
仮想IPアドレス	意図的にVPC外のダミーのIPアドレス（20.1.1.1）をクライアントから参照させることでルートテーブルを参照させて、そのルートテーブルに登録されているターゲットのENIにアクセスさせます。 詳しくは過去の記事をご参照ください。                            第４回　【LifeKeeper】AWSでは仮想IPアドレスが使えない！？をこうして解決する！！ オンプレや仮想環境でHAクラスタを構築する際は仮想IPアドレスを使えましたが、AWSでは仮想IPアドレスの機能が提供されません。この課題をLifeKeeperがどのように解決しているかを解説します。 blog.usize-tech.com 2023.11.29 フェイルオーバーの際には、AWSのAPIをキックしてターゲットを稼動系から待機系にルーティング変更します。この制御により、クライアントは常に稼動系のクラスターノードにアクセスできます。

NWの構成

各サービスのパラメータ

本環境で利用しているNW関連サービスのパラメータを紹介します。
内容が重複するため東京リージョンのリソースのみとします。

ルートテーブル

publicとprivateで分けていますがどちらも大阪に抜ける経路は同じとなります。

Transit Gateway

必要に応じてオプション機能を有効化します。
今回は「DNSサポート」のみ有効化しています。

Transit Gatewayアタッチメント

東京側のアタッチメント(tgw-at-tokyo)では東京のpublicとprivateサブネットを関連付けています。

Transit Gatewayルートテーブル

アタッチメントごとにルートテーブルを作成して関連付けるイメージです。

ルートアナライザーでの疎通確認

ルートアナライザーを使うと簡易的に疎通確認ができます。
疎通が失敗する場合は原因がどこかを特定しましょう。

仮想IPのルーティングシナリオ

仮想IPアドレスを使ったクライアント通信経路に関して、想定されるルーティングシナリオを3パターンご紹介します。
クラスターノードの稼働状況に応じてAWS側でルーティングを切り替える必要があります。
ここでは仮想IPアドレスを「20.1.1.1」とし、東京1号機(LKDRBD-1)から順に障害によるダウンをしたと仮定します。

例ではTGWアタッチメントをサーバと同じプライベートサブネットに配置していますが、
AWSのベストプラクティスはTGWアタッチメント専用のサブネットを分けることが推奨されています。                             

Amazon VPC Transit Gateway 設計のベストプラクティス - Amazon VPC

Transit Gateway 設計のベストプラクティスについて学ぶ。

docs.aws.amazon.com

東京1号機が稼働機の場合

各ルートテーブルは以下のように設定します。
※設定不要なルートテーブルは割愛します。

・rtb-tokyo

・tgw-rtb-tokyo

・tgw-rtb-tokyo-osaka

東京2号機が稼働機の場合

各ルートテーブルは以下のように設定します。
※設定不要なルートテーブルは割愛します。

・rtb-tokyo

・tgw-rtb-tokyo

・tgw-rtb-tokyo-osaka

大阪1号機が稼働機の場合

各ルートテーブルは以下のように設定します。
※設定不要なルートテーブルは割愛します。

・rtb-osaka

・tgw-rtb-osaka

・tgw-rtb-osaka-tokyo

ルーティング切替の実装方針

上述のルーティングシナリオを実現するためにAWSのAPIを使用することでルーティングの切替を行います。
ざっくりした実装方式は以下を想定しており、別記事でスクリプトや挙動のご紹介を予定しています。

①障害が発生
②稼働機に昇格したクラスタノードからスクリプトをキック
③スクリプト内でルートテーブルを差し替えて仮想IPを新稼働機までルーティング
④新稼働機でサービス継続

最後に

以上、駆け足でしたがAWS Transit Gatewayを用いたマルチリージョン構成ができたことになります。
最後までお読みいただき、ありがとうございました。

次回はスクリプトによるルーティング切替の詳細について記事を書こうと思います。