CloudHub 2.0 ネットワークアーキテクチャ
CloudHub 2.0 は、MuleSoft の完全に管理されコンテナ化されたサービスとしてのインテグレーションプラットフォーム (iPaaS) です。API とインテグレーションを軽量コンテナとしてクラウドにデプロイします。これにより、これらの保守性、安全性、拡張性が確保されます。
このドキュメントでは、CloudHub 2.0 ネットワーク、ネットワークインターフェース、ネットワークサービスの設定と管理に関する情報が提供されます。各種シナリオについては、デプロイメントオプションを参照してください。
CloudHub 2.0 ネットワークアーキテクチャの基本コンポーネントは、HTTP ロードバランサー、Mule レプリカ DNS レコード、非公開スペース、リージョンサービスです。
HTTP ロードバランサー
CloudHub 2.0 はすべてのインテグレーションに負荷分散サービスを提供します。デフォルトのエンドポイントを使用することも、独自の証明書を使用してカスタムエンドポイントをプロビジョニングすることもできます。
アプリケーションを 2 つ以上のレプリカにデプロイすると、CloudHub 2.0 は、割り当てたレプリカで HTTP 要求を自動的に分散する HTTP 負荷分散サービスを提供します。
CloudHub 2.0 負荷分散サービスは、アプリケーションレプリカ間でラウンドロビン方式の負荷分散を実行します。これにより、水平拡張性を確保できます。また、この負荷分散サービスでは、アプリケーションのアップグレード時に切り替えが透過的に実行されます。CloudHub 2.0 にデプロイされたアプリケーションの更新を参照してください。
CloudHub 2.0 にデプロイされる各アプリケーションには、ロードバランサーを参照するデフォルトの公開 DNS レコード (<app>.<space-id>.<region>.cloudhub.io) と内部 DNS レコード (<app>.internal-<space-id>.<region>.cloudhub.io) の両方があります。
CloudHub 2.0 非公開スペース負荷分散サービスは、標準 HTTPS ポート 443 で公開トラフィックを受け入れます。非公開スペースでは、標準 HTTP ポート 80 で HTTP トラフィックを受け入れることもできます。共有スペースでは、80 を受け入れません。
Mule アプリケーションポート
アプリケーションは、予約されたプロパティ ${http.port} を介してホスト 0.0.0.0 とポートをリスンする必要があります。MuleSoft は、このプロパティの値を割り当てます。
負荷分散サービスは、トラフィックをデプロイ済みアプリケーションに転送します。
アップストリーム HTTPS トラフィック
デフォルトでは、負荷分散サービスは HTTP を介してトラフィックをデプロイ済みアプリケーションに転送します。HTTPS を使用する方法:
-
[deployment settings (デプロイメント設定)] の [Ingress (イングレス)] タブで [Last-Mile Security (Last -Mile セキュリティ)] 設定を有効にします。
-
非公開スペースの TLS コンテキストで証明書を指定して、HTTPS をリスンするようにアプリケーションを設定します。
次の例は、HTTPS エンドポイントを公開する Mule アプリケーション設定を示しています。
<http:listener-config name="HTTP_Listener_Configuration" protocol="HTTPS" host="0.0.0.0" port="${http.port}" doc:name="HTTP Listener Configuration" >
<tls:context name="TLS_Context_Custom_Keystore" doc:name="TLS Context">
<tls:key-store type="jks" path="server.jks" keyPassword="" password="" alias="" />
</tls:context>
</http:listener-config>ロードバランサーの接続
クライアントが CloudHub 2.0 ロードバランサー (<app>.<space-id>.<region>.cloudhub.io) を介して実行する要求ごとに、ロードバランサーは 2 つの接続 (クライアントとロードバランサー間の接続とロードバランサーとアプリケーション間の接続) を維持します。接続ごとにロードバランサーは 300 秒のデフォルトのアイドルタイムアウトを管理します。これは、どちらの接続にもデータが送信されていない場合にトリガーされます。この期間にデータが送受信されない場合、ロードバランサーは両方の接続を閉じます。
どちらの側からでも接続の処理に 300 秒を超える時間がかかる場合、処理を非同期で実行します。アイドルタイムアウト値は、Runtime Manager の [private space settings (非公開スペース設定)] の [Advanced (詳細)] タブ、または Mule アプリケーションの Mule 設定ファイルのグローバル設定でカスタマイズできます。
DNS レコード
次の DNS レコードが CloudHub 2.0 アプリケーションに公開されます。
|
非公開スペース内で実行されるアプリケーション。 |
|
ロードバランサーを参照するレコード。このレコードは、カスタムドメイン CNAME の対象として使用します。 |
|
|
|
内部ロードバランサー。このレコードは、カスタムドメイン CNAME の対象として使用します。この DNS レコードの IP アドレスには、非公開スペース内でのみアクセスできます。共有スペース内からはアクセスできません。 |
非公開スペース設定
次の設定は、非公開スペースにのみ適用されます。
アプリケーション間の通信
アプリケーション間の通信方法を次に示します。
-
デフォルトの公開 DNS 名:
app.sxjsip.aus-s1.cloudhub.io -
デフォルトの内部 DNS 名 (非公開スペースのみ):
app.internal-sxjsip.aus-s1.cloudhub.io -
カスタムドメイン名 (設定されている場合):
acme.example.com -
クラスターローカル DNS:
app または app.envid.svc.cluster.local:8081
内部 DNS 名を使用する場合、トラフィックは非公開スペースネットワークに留まります。アプリケーションを非公開スペースにデプロイする場合、外部に公開されるエンドポイントを削除または省略できます。その場合、内部トラフィック用にアプリケーションの内部エンドポイントを使用します。
非公開スペースのローカルエンドポイントを使用する場合、トラフィックは非公開スペース内に留まります。ただし、非公開スペースのローカルエンドポイントは高可用性ではありません。一部の非公開スペース操作 (障害回復など) 中にエンドポイントに到達できなくなることがあります。非公開スペースのローカルエンドポイントでは、同じ環境内のトラフィックのみが許可されます。
カスタムドメイン名
カスタム証明書を非公開スペースに適用できます。CloudHub 2.0 は、証明書の CN および SAN リストを解析して、アプリケーションをデプロイするときにそれらのドメインを使用できるようにします。
公開 DNS レコードまたは内部 DNS レコードのいずれかを CNAME に設定します。次に例を示します。
*.example.com => sxjsip.aus-s1.cloudhub.io *.example.com => internal-sxjsip.aus-s1.cloudhub.io
IP 範囲
インターネットへのエグレストラフィックは、非公開ネットワーク設定の [Outbound Static IPs (アウトバウンド静的 IP)] 項目にリストされている IP アドレスから取得されます。
非公開スペースの有効期間中は、公開 DNS 対象と非公開 DNS 対象の IP は変更されません。
VPN またはトランジットゲートウェイ (TGW) へのエグレストラフィックは、非公開スペースの CIDR ブロックから取得されます。
非公開スペースでは、いくつかのセカンダリ CIDR を内部的に使用します。
BGP ルーティングプロトコルを使用している場合、次の CIDR ブロックをゲートウェイにパブリッシュできます。
100.64.0.0/16 100.66.0.0/16 100.67.0.0/16 100.68.0.0/16
このため、100.64.0.0/10 は非公開スペースではサポートされません。
ルートマップからこれらのプレフィックスから絞り込むことができます。詳細は、 「CloudHub 2.0 VPN から余分な BGP ルートを受信する」を参照してください。
非公開スペースの作成時にオンプレミスネットワークの予約済み範囲を指定することもできます。お客様によって指定された予約済み範囲は、CloudHub 2.0 で使用されません。詳細は、「予約する企業の CIDR 」を参照してください。
接続
非公開スペースでは、仮想プライベートネットワーク (VPN) とトランジットゲートウェイ (TGW) の 2 種類の接続がサポートされています。
各 Anypoint VPN 接続にはトンネルが 2 つあり、リモートロケーションにある 1 件のパブリック IP アドレスに接続できます。エンドポイントで両方のトンネルを設定すると、VPN は高可用性になります。
また、冗長 VPN 接続を定義して弾力性を高めることができます。通常、管理対象サービスとして基盤となる VPN サービスがアップグレードされます。ルーチンメンテナンスによって VPN 接続の 2 つのトンネルの片方が短時間だけ無効になることがあります。このときは VPN 接続が他方のトンネルに自動的にフェールオーバーするため、アクセスは中断されません。このため、エンドポイントで両方のトンネルを設定する必要があります。詳細は、 「Anypoint Dynamic (BGP) VPN の更新でのトンネルの切り替え」を参照してください。
設計上、TGW 接続は高可用性であるため、冗長 TGW 接続を作成しないでください。詳細は、トランジットゲートウェイアタッチメントを参照してください。
CloudHub VPC AWS Direct Connect 接続は、CloudHub 2.0 で非推奨になっています。代わりに、TGW アタッチメントを使用してください。また、TGW がアタッチされている非公開スペースを削除すると、トランジットゲートウェイは保存され、別の非公開スペースに再度アタッチできます。
CloudHub と CloudHub 2.0 間の接続
TGW アタッチメントを使用して、CloudHub の専用 VPC を CloudHub 2.0 非公開スペースに接続します。CloudHub と CloudHub 2.0 で個別にアタッチメントを適用する必要があります。
ファイアウォールルールおよびポートアドレス
- HTTP イングレス
-
デフォルトでは、ポート
443 および 80 は、すべての外部インバウンドトラフィックに公開されます。これらのポートを削除または変更して、インバウンドトラフィックを制限できます。 - 非 HTTP イングレス
-
デフォルトでは、非 HTTP ポートは開いていません。TCP ポート (30500 ～ 32500) の固定リストを開いて、非 HTTP トラフィックが Mule アプリケーションに流れることを許可できます。これらのポートは、非公開スペース内からのみ到達でき、VPN または TGW から取得されます。非公開スペースで TCP トラフィックを許可する方法についての詳細は、Application Manager API を使用した TCP を使用するアプリケーションのデプロイを参照してください。
- エグレス
-
デフォルトでは、アプリケーションは任意の宛先およびポートへのアウトバウンド接続を作成できます。この動作を変更して、エグレストラフィックを制限できます。
インターネットに対するすべてのイングレスルールとエグレスルールを削除できます。その場合、次の制御措置のため、非公開スペースは引き続き通常どおり機能します。
-
Anypoint Monitoring の取り込みトラフィックファイアウォールルールがすべての Mule アプリケーションのファイアウォールルールに暗黙的に追加されます。
-
必要不可欠な AWS サービストラフィックフローは、Mule アプリケーションから常に許可されます。
-
エグレスルールはアプリケーションレベルで適用できます。詳細は、アプリケーションレベルのエグレスルールの設定を参照してください。
-
インターネットゲートウェイへのデフォルトルートを削除できます。ただし、エグレスファイアウォールルールが機能するには、宛先 IP がルーティング可能である必要があります。
-
リージョンサービス
インテグレーションの DNS レコードとロードバランサーは、アプリケーションをデプロイするリージョンによって異なります。 各リージョンでアプリケーションがどの DNS レコードを使用できるかについて次の表にまとめました。
| リージョン | リージョン名 | コントロールプレーン | DNS レコードの例 | 内部 DNS レコードの例 | |
|---|---|---|---|---|---|
北米 |
米国東部 (北バージニア) |
|
US |
|
|
米国東部 (オハイオ) |
|
US |
|
|
|
米国西部 (北カリフォルニア) |
|
US |
|
|
|
米国西部 (オレゴン) |
|
US |
|
|
|
カナダ (中央部) |
|
US |
|
|
|
US GovCloud (西部) |
|
US Gov |
|
- |
|
南米 |
ブラジル (サンパウロ) |
|
US |
|
|
APAC |
Singapore |
|
US |
|
|
オーストラリア (シドニー) |
|
US |
|
|
|
日本 (東京) |
|
US |
|
|
|
ヨーロッパ |
アイルランド |
|
US |
|
|
ドイツ (フランクフルト) |
|
US |
|
|
|
UK (ロンドン) |
|
US |
|
|
|
アイルランド (EU コントロールプレーン) |
|
EU |
|
- |
|
ドイツ (EU コントロールプレーン) |
|
EU |
|
- |