はじめに

アマゾン ウェブ サービス ジャパン合同会社協力の下、AWS Outposts ラック上に立てたEC2インスタンスを利用したHAクラスターの構築を検証し、構築可能であることを確認しました。
AWS Outposts ラック上でCLUSTERPROを利用してHAクラスターを構築することで、低レイテンシーかつ高可用なシステムを構築することができます。
本記事では、AWSリージョン上にHAクラスターを構築する場合と比較して、利用可能なCLUSTERPROの接続先切り替え方式の違いや、AWSリソースの差異による考慮すべき点等を、検証結果と合わせてご紹介します。
検証は以下の3パターンで実施しました。

今回の検証では、AWS Outposts Test Labを利用しています。

【参考】

AWS Outposts Test Lab

https://github.com/aws-samples/otl-getting-started

過去の記事では、AWS Outposts ファミリーの一つであるAWS Outposts サーバー上でのHAクラスターの構築も検証しています。詳細は以下を参照ください。

【参考】

AWS Outposts サーバー上でHAクラスターの構築を試してみました(Linux)

この記事の内容

1. AWS Outpostsとは

AWS Outpostsはお客様のデータセンターや工場、店舗等のロケーションに設置することで、AWSサービスをAWSのデータセンター以外でも実行可能にするフルマネージドサービスです。その実体はAWSが提供する物理的なサーバーやラックから構成されるインフラストラクチャであり、設置条件を満たす環境において利用できます。
これにより、使い慣れたAWSのサービス・ツール・APIを利用して、オンプレミスのシステムと低レイテンシーでの連携や、データのレジデンシー (所在地)の要件を満たすことが出来るようになります。
AWS Outpostsには、AWS Outposts サーバーとAWS Outposts ラックの2種類があり、料金や筐体サイズの他に、プロセッサの種類や使用できるAWSサービスの数に違いがあります。現時点 (2026年1月9日)では、それぞれ以下のプロセッサ、およびAWSサービスを使用することができます。

なお、今回の検証ではAWS Outposts ラックの第1世代を利用しています。

■ AWS Outposts サーバー

■ AWS Outposts ラック

AWS Outpostsの詳細は以下を参照ください。

【参考】

AWS Outposts ファミリー

https://aws.amazon.com/jp/outposts/

2. AWS Outposts ラックのネットワークコンポーネント

AWS Outposts ラックでは、Service link VLANとLocal gateway VLANの2つのVLANが提供されます。

AWS Outposts ラックとAWSリージョン間で通信をするためのVLANです。Amazon Virtual Private Cloud (以降、VPC)内のAWS Outposts ラック上のEC2とAWSリージョン上のEC2間の通信や、AWS Outposts ラック上のリソース管理のAPI操作の通信等に利用されます。
Service linkは、Direct Connect接続またはインターネット接続を利用することができ、通信をする際にはVPN接続が確立されます。

AWS Outposts ラックとオンプレミスネットワーク間や、複数のAWS Outposts ラック間で通信するためのVLANです。VPC内のAWS Outposts ラック上のEC2とオンプレミスネットワーク上の機器の通信や、複数のAWS Outposts ラック上のそれぞれのEC2インスタンス間の通信等に利用されます。
AWS Outposts ラックには1つのLocal gateway (以降、LGW)がアタッチされており、LGWを介してオンプレミスネットワークや異なるAWS Outposts ラックと接続します。

例として、以下ような図の構成の場合の通信の流れをご紹介します。

AWS Outposts ラック1に配置されたEC2インスタンス1は、各コンポーネントに対して以下のように流れで通信をします。

EC2インスタンス1 → Local gateway1 → On-premise Router → Local gateway2 →EC2インスタンス2

EC2インスタンス1 → Service link → EC2インスタンス3
※ 宛先がVPC CIDR内・ターゲットがlocalの経路設定を利用

EC2インスタンス1 → Service link → VPCエンドポイント
※ 宛先がVPC CIDR内・ターゲットがlocalの経路設定を利用

EC2インスタンス1 → Local gateway1 → On-premise Router → On-premise Client

EC2インスタンス1 → Local gateway1 → On-premise Router → Internet

EC2インスタンス1 → Service link → NAT gateway → Internet
※ AWS Outposts ラック2のOutposts サブネット2のVPCルートテーブルのように、「0.0.0.0/0」の宛先をAWSリージョンのNAT gatewayをターゲットにした場合

3. AWS Outposts ラックでCLUSTERPROを利用する際に考慮すべき点

今回の検証で使用するAWS Outpostsは、AWS Outposts ラックの第1世代になります。
AWS Outposts ラック上のEC2インスタンスでHAクラスターを構築する場合、以下の点を考慮する必要があります。

3.1 コントロールプレーンとデータプレーン

AWSの各サービスのAPIには、コントロールプレーンとデータプレーンの2種類があります。コントロールプレーンでは、AWSサービスを作成、読み取り/表示、更新、削除、およびリスト (CRUDL)するための管理 APIを提供します。データプレーンは、コントロールプレーンによって決められたとおりに動作をするサービスの機能を提供します。各プレーンの詳細は以下を参照ください。

【参考】

コントロールプレーンとデータプレーン - AWS 障害分離境界
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html

AWS Outposts ラックでは、コントロールプレーンはAWSリージョンのものを使用するため、AWSサービスの作成、読み取り/表示、更新、削除、およびリスト (CRUDL)の操作は、AWSリージョンと通信できるようにする必要があります。一方、データプレーンはAWS Outposts ラック内のものを使用するため、AWSリージョンとの通信が切断された場合でも動作が可能です。
そのため、ローカルで動作させることが強みであるAWS Outposts ラックでは、AWSリージョンに依存しないデータプレーンのみで運用可能な構成にすることで、より可用性の高いシステムを実現できます。

【参考】

静的安定性 - AWS 障害分離境界
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html

障害モードの観点からの考え方 - AWS Outposts の高可用性設計とアーキテクチャに関する考慮事項
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/thinking-in-terms-of-failure-modes.html

3.2 Application Load Balancer

Application Load Balancer (以降、ALB)は、AWSリージョンで構築する場合、2つのAvailability Zone (以降、AZ)のサブネット上で構築する必要がありますが、AWS Outposts ラック上に構築する場合、1つのOutposts サブネット上で構築する必要があります。
そのため、複数のAWS Outposts ラックのOutposts サブネットにまたがってALBを構築することはできません。

3.3 Amazon S3 on Outposts

Amazon S3 on Outposts (AWS Outposts ラック上で構築したAmazon Simple Storage Service)では、2025年8月検証時点で、静的ウェブサイトホスティングの機能を利用することはできないため、以下の記事で紹介しているCLUSTERPROのHTTP NP解決先として設定することはできません。

【参考】

【2022年版】AWSで両系活性を防止する方法(Windows/Linux)

一方で、AWS Outposts ラック上のEC2インスタンスを利用したHAクラスターはローカルネットワークに接続しているため、業務上必須なオンプレミスの機器を、HTTP NP解決先やPing NP解決先に設定することで両系活性を防止することができます。

3.4 複数のAWS Outposts ラック間の通信

AWS Outposts ラックでは、VPC上に Outposts サブネット (AWS Outposts ラック用の仮想ネットワーク)を作成し、AWSリソースをデプロイします。複数のAWS Outposts ラックそれぞれに作成したOutposts サブネットを、1つのVPCに含めることが可能です。ただし、「2. AWS Outposts ラックのネットワークコンポーネント」のとおり、複数のAWS Outposts ラックそれぞれのOutposts サブネット間で通信をする際は、VPCルートテーブルとLGWルートテーブル、オンプレミス上のルーターに経路設定が必要になります。

今回の検証では、ダイレクトVPCルーティング設定のLGWを利用しています。ダイレクトVPCルーティング設定の場合、VPCルートテーブルでターゲットをLGWに設定しているサブネット情報のみが、LGWルートテーブルに動的に伝播され、静的に経路設定することはできません。そのため、VPC外のCIDRを設定する必要がある仮想IPアドレスは、複数のAWS Outposts ラック間やAWS Outposts ラックとオンプレミスネットワーク間の通信には利用することができません。

【参考】

Outposts ラックの VPC 内ルーティング - AWS Outposts の高可用性設計とアーキテクチャに関する考慮事項
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/intra-vpc-routing.html

4. 検証

今回は以下の3パターンの構成で、AWS Outposts ラックの検証を実施しました。

本検証の全体構成図は以下のとおりです。
WindowsとLinuxどちらも、各検証ごとに2つずつEC2インスタンスを作成して、ミラーディスク型のHAクラスターを構築しました。

全体のネットワーク構成は以下のとおりです。

■ネットワーク構成

各検証のHAクラスターを構成するEC2インスタンスにおいて、共通する設定は以下のとおりです。

■EC2インスタンス

■OS

■CLUSTERPROバージョン

各検証で、以下の5パターンの接続先切り替え方式によるミラーディスク型HAクラスターの構築をしました。ただし、構成によっては使用できない接続先切り替え方式があります。
また、動作確認として各接続先切り替え方式が提供する接続先にアクセスできるか、および各接続先切り替え方式の監視リソースが異常を検出するかを確認しました。

4.1 検証① 1台のAWS Outposts ラックにおける2つのEC2インスタンスでのHAクラスターの構築

4.1.1 検証構成

本検証では、1台のAWS Outposts ラックに立てた2つのEC2インスタンスで、ミラーディスク型のHAクラスターの構築を検証しました。HAクラスターへの接続先切り替え方式として、ALBを利用、ダイナミックDNSリソース、AWS DNSリソース、AWSセカンダリIPリソース、AWS仮想IPリソースの5つを検証しました。
また、HAクラスターを構成するEC2インスタンスは、可用性を高めるために、1つのAWS Outposts ラック上の異なるホストにEC2インスタンスを配置するホスト型スプレッドプレイスメントグループを設定しています。

本検証のHAクラスター構成は以下のとおりです。

■HAクラスターを構成するEC2インスタンス (Windows)

■HAクラスターを構成するEC2インスタンス (Linux)

■CLUSTERPRO設定

4.1.2 検証結果

1台のAWS Outposts ラックにおける2つのEC2インスタンスで構成したHAクラスターの、検証内容および結果は以下のとおりです。

4.2 検証② 2台のAWS Outposts ラック間における2つのEC2インスタンスでのHAクラスターの構築

4.2.1 検証構成

本検証では、2台のAWS Outposts ラックそれぞれに立てた2つのEC2インスタンスで、ミラーディスク型のHAクラスターの構築を検証しました。HAクラスターへの接続先切り替え方式として、ダイナミックDNSリソース、AWS DNSリソース、AWS仮想IPリソースの3つを検証しました。

本検証のHAクラスター構成は以下のとおりです。

■HAクラスターを構成するEC2インスタンス (Windows)

■HAクラスターを構成するEC2インスタンス (Linux)

■CLUSTERPRO設定

4.2.2 検証結果

2台のAWS Outposts ラック間における2つのEC2インスタンスでのHAクラスターでの、検証内容および結果は以下のとおりです。

4.3 検証③ 1台のAWS Outposts ラックとAWSリージョン間における2つのEC2インスタンスでのHAクラスターの構築

4.3.1 検証構成

本検証では、1台のAWS Outposts ラックとAWSリージョンそれぞれに立てた2つのEC2インスタンスで、ミラーディスク型のHAクラスターの構築を検証しました。HAクラスターへの接続先切り替え方式として、ダイナミックDNSリソース、AWS DNSリソース、AWS仮想IPリソースの3つを検証しました。

本検証のHAクラスター構成は以下のとおりです。

■HAクラスターを構成するEC2インスタンス (Windows)

■HAクラスターを構成するEC2インスタンス (Linux)

■CLUSTERPRO設定

4.3.2 検証結果

1台のAWS Outposts ラックとAWSリージョン間における2つのEC2インスタンスでのHAクラスターでの、検証内容および結果は以下のとおりです。

まとめ

今回は、AWS Outposts ラック上でHAクラスターの構築を検証してみました。
AWS Outposts ラックでは、リージョンのコントロールプレーンを使用せず、AWS Outposts ラック上のデータプレーンのみを使用する構成にすることが、より障害の強いシステムを構築するための1つのポイントになります。CLUSTERPROでは、以下の構成パターンでデータプレーンのみを使用したHAクラスターを構築することができます。

利用製品

本記事の環境を構築する際に利用した製品です。

参考

お問い合わせ