Anypoint Runtime Fabric でのインバウンドトラフィックの有効化
Runtime Fabric は、Mule アプリケーションや API プロキシへのインバウンドトラフィックを管理するための負荷分散を提供します。ネットワークトラフィックは、アプリケーションの複数のレプリカで分散されます。デフォルトでは、レプリカは異なるワーカー VM にデプロイされます。
Runtime Fabric は、複数の環境で共有できます。インストール後、各 Runtime Fabric の 1 つ以上の環境を設定して、アプリケーションデプロイメントを有効にします。Mule アプリケーションや API ゲートウェイをデプロイできるようにするには、1 つ以上の環境を各 Runtime Fabric に関連付ける必要があります。
本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションから分離された Runtime Fabric のインスタンスにデプロイされる必要があります。
| デフォルトでは、不要なリソースをコンシュームしないようにインバウンドトラフィックが無効になっています。Mule アプリケーションや API ゲートウェイでインバウンド接続をリスンできるようにするには、インバウンドトラフィックを有効にします。インバウンドトラフィックはデフォルトで無効になっているため、Mule アプリケーションや API ゲートウェイでインバウンド要求を受信できるようにするには、手動で有効にする必要があります。 |
インバウンドトラフィックを有効にする前に、有効な TLS 証明書を提供する必要があります。証明書にはパスフレーズが必要です。また、証明書は Runtime Fabric にデプロイされている各アプリケーションのドメインを指定する共通名 (CN) を使用して設定されている必要があります。
-
共通名にワイルドカードが含まれている場合、デプロイされている各アプリケーションのエンドポイントの形式は
{app-name}.{common-name} のようになります。 -
共通名にワイルドカードが含まれていない場合、エンドポイントの形式は
{common-name}/{app-name} のようになります。
外部ロードバランサーの要件
各コントローラー VM は、内部ロードバランサーのレプリカを実行し、ポート 443 でリスンするように設定されています。複数のコントローラー VM を実行する場合、各コントローラー VM に直面する Runtime Fabric 外に外部ロードバランサーが必要になります。外部ロードバランサーでは、TCP 負荷分散がサポートされている必要があります。ロードバランサーは、各コントローラー VM の IP アドレスが含まれるサーバープールを使用して設定されている必要があります。また、外部ロードバランサーには、ポート 443 をリスンする状態チェックもセットアップされている必要があります。
この外部ロードバランサーの設定では、次のことを実現できます。
-
高可用性を維持する
-
障害から保護する
-
内部ロードバランサーのレプリカが再起動するか、削除されて別のコントローラー VM で再スケジュールされた場合に、自動フェールオーバーを適切に処理する。
| コントローラー VM は、Anypoint Runtime Fabric を強化するコンポーネントを実行する専用の仮想マシンです。 |
Anypoint Runtime Fabric へのすべてのインバウンドトラフィックは、TLS を使用して暗号化されます。次の手順では、インバウンドトラフィックを有効にするために TLS 証明書を設定および使用する方法について説明します。有効になると、Runtime Fabric に送信される HTTP 要求は、301 応答を受信して、ポート 443 で HTTPS にリダイレクトします。
必要なロールと権限を割り当てる
-
Runtime Fabric で実行されるアプリケーションを使用する環境を決定します。
-
必要な権限があることを確認します。
取得した権限が伝播されるまで最大 5 分ほどかかることがあります。
-
Anypoint Platform から [Access Management (アクセス管理)] を選択します。
[Access Management (アクセス管理)] にアクセスできない場合、システム管理者にアクセス権を要求します。
-
[Users (ユーザー)] を選択します。
-
ユーザー名がある行を見つけ、青いリンクを選択します。
-
[Runtime Manager] タブで、Runtime Fabric 環境の [Manage Runtime Fabrics (Runtime Fabric の管理)] 権限を有効にします。
-
[Secrets Manager (シークレットマネージャー)] タブで、Runtime Fabric 環境の [Manage Secret Groups (シークレットグループの管理)]、[Write Secrets (シークレットの作成)]、[Read Secrets Metadata (シークレットメタデータの読み取り)] 権限を有効にします。
-
証明書とキーのペアを生成する
Runtime Fabric の内部ロードバランサーの証明書とキーのペアが必要になります。ペアがすでにある場合、両方のファイルの種類が .pem で、キーストアにパスコードがあり、共通名が Runtime Fabric で使用するドメインと一致している必要があります。
RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。
| 2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。 |
ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。
-
secp521r1 (P-521)
-
secp384r1 (P-384)
-
secp256r1 (prime256v1 (P-256) とも呼ばれる)
評価のために、次の手順を使用して証明書とキーのペアを生成します。
-
マシンで次のコマンドを実行して証明書とキーのペアを生成します。
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
-
キーのパスフレーズを入力します。
-
必要な情報 (国や都道府県など) を入力します。共通名を求められた場合、Runtime Fabric で使用するドメインを入力します。
共通名にワイルドカード (*.example.com など) を使用する場合、アプリケーション URL では {app-name}.example.com の形式が使用されます 。使用しない場合、アプリケーション URL では example.com/{app-name} の形式が使用されます。
TLS コンテキストを作成する
次の手順に従って、証明書とキーのペアを TLS コンテキストに含めるには、それをシークレットマネージャーに保存します。これは、後で Runtime Fabric へのインバウンドトラフィックを暗号化するために使用されます。
-
Anypoint Platform ホームページからシークレットマネージャーに移動します。
適切なビジネスグループに属していることを確認し、左側のサイドバーで Runtime Fabric 環境を選択します。 -
[Create Secret Group (シークレットグループを作成)] を選択します。
-
[General (一般)] で、シークレットグループの名前を入力します。
-
[保存] を選択します。
-
サイドバーで [Keystore (キーストア)] を選択し、キーストアを作成します。
-
[キーストアを追加] を選択します。
[Add Keystore (キーストアを追加)] ボタンが表示されない場合、シークレットグループが編集モードで表示されていることを確認します。[Secret Groups (シークレットグループ)] に戻り、グループの横にある [Edit (編集)] を選択します。
-
キーストアの名前を入力します。
キーストアを以下の TLS コンテキストに追加するときに、この名前でキーストアが識別されます。
-
[Certificate File (証明書ファイル)] で、[Choose File (ファイルを選択)] を選択し、
.pem 証明書ファイルを選択します。 -
[Key File (キーファイル)] で、[Choose File (ファイルを選択)] を選択し、
.pem キーファイルを選択します。 -
キーパスフレーズを入力します。
-
必要に応じて、CA パスが含まれる個別の証明書ファイルをアップロードします。
-
[保存] を選択します。
不明なエラーが発生した場合、証明書ファイルに CA パスが含まれていることが原因である可能性があります。続行する前に、CA パスを独自のファイルに移動して個別にアップロードします。
-
-
[TLS Context (TLS コンテキスト)] を選択し、次の手順を実行します。
[Add TLS Context (TLS コンテキストを追加)] が表示されない場合、シークレットグループが編集モードで表示されていることを確認します。[Secret Groups (シークレットグループ)] ページに戻り、グループの横にある [Edit (編集)] を選択します。 -
TLS コンテキストの名前を入力します。後で Runtime Fabric に適用するときに、この名前で TLS コンテキストが識別されます。
-
デフォルトの TLS バージョン (TLS 1.2) を使用します。
-
[Target (対象)] で、[Anypoint Security] を選択します。これにより、TLS コンテキストが設定され、Runtime Fabric に適用できるようになります。
-
[Keystore (キーストア)] で、以前に設定したキーストアの名前を選択します。
-
[保存] を選択します。
-
-
TLS コンテキストを保存したら、[Secret Groups (シークレットグループ)] を選択し、[Finish (完了)] を選択します。これにより、Runtime Fabric の TLS コンテキストが有効になります。
インバウンドトラフィックを有効にする
Runtime Fabric 内部ロードバランサーでは、OpenSSL 1.1.1 と TLS 1.3 がサポートされており、TLS 1.2 と比較してセキュリティとパフォーマンスが改善されています。
-
2x または TLS 1.2 以降では、OpenSSL 1.0.2 で実行される以前の Runtime Fabric 内部ロードバランサーと比較して接続パフォーマンススループットが強化されています。
-
TLS 1.3 では、TLS 1.2 と比較してフルハンドシェイクが 1 往復減っています。
-
TLS 1.2 および TLS 1.3 ChaCha20-Poly1305 暗号化が追加され、モバイルおよび IoT デバイスのサポートが改善されています。
-
TLS 1.3 は、ダウングレード攻撃を防ぎます。
-
RSA キーと ECDSA キーの両方が引き続きサポートされます。
-
TLS 1.3 では、TLS 1.2 および TLS 1.1 の安全でない不用な機能が削除されています。サポートされている暗号化と非推奨の暗号化の完全なリストについては、「Anypoint セキュリティエッジリリースノート」を参照してください。
TLS 1.3 プロトコルをサポートするクライアントでは、このプロトコルがデフォルトで有効になります。
TLS コンテキストを作成したら、TLS コンテキストを Runtime Fabric に適用して、セキュアな受信トラフィックを有効にします。
-
[Runtime Manager] に移動し、[Runtime Fabric] を選択します。
-
Runtime Fabric の名前を選択して、管理ページを開きます。
-
[Associated Environments (関連付けられた環境)] タブで、Runtime Fabric 環境が Runtime Fabric に関連付けられていることを確認します。
-
[Inbound Traffic (インバウンドトラフィック)] を選択し、[Enable inbound traffic (インバウンドトラフィックを有効化)] 切り替えをオンにします。
-
[Basic Configuration (基本設定)] を選択し、次の手順を実行します。
-
内部ロードバランサーで実行するレプリカの数を設定します。
本番環境では、2 つ以上のレプリカが必要です。これらのレプリカは、コントローラー VM でのみ実行されます。 -
内部ロードバランサーの各レプリカに割り当てる CPU やメモリの量を決定します。
TLS の終了は、計算コストが高くなります。より多くの CPU を割り当てるほど、スループットが向上し、遅延が減少します。
-
-
[TLS Configuration (TLS 設定)] で、次の手順を実行します。
-
[Environment (環境)] メニューから、Runtime Fabric 環境を選択します。
-
[Secrets Group (シークレットグループ)] メニューから、以前に作成した TLS コンテキストが含まれるシークレットグループを選択します。
シークレットグループが表示されない場合、「Manage Runtime Fabrics (Runtime Fabric の管理)」権限がアカウントに割り当てられていることを確認します。 -
[TLS Context (TLS コンテキスト)] メニューから、Runtime Fabric で使用される TLS コンテキストを選択します。
-
-
[Deploy (デプロイ)] を選択して内部ロードバランサーをデプロイします。成功すると、ページの右下にメッセージが表示されます。デプロイメントには、最大 1 分ほどかかることがあります。デプロイメントの状況は、フォームの上部で確認できます。状況が [Applied (適用済み)] に移行すると、内部ロードバランサーが正常にデプロイされ、インバウンドトラフィックが有効になります。
Runtime Manager UI を使用して Mule アプリケーションを Runtime Fabric にデプロイする場合、内部ロードバランサーの証明書で使用されている最初のドメインのみがアプリケーションエンドポイントを作成するために選択されます。Subject Alternative Name または Common Name により証明書で指定されたその他のドメインは使用されません。
|
インバウンドトラフィックが有効になっていることの確認
Runtime Fabric にデプロイされているアプリケーションの共通名 (CN) を解決するには、CN を外部ロードバランサーまたは各コントローラー VM の IP アドレスにマップするように DNS を設定する必要があります。DNS を設定する前にアプリケーションのインバウンドトラフィックをテストするには、ドメインに設定されている IP アドレスとホストヘッダーを使用して要求をアプリケーションに送信します。
ドメインの構造は、証明書の CN でワイルドカードが使用されているかどうかによって異なります。次に例を示します。
-
ワイルドカードが含まれる CN (*.example.com など) では、
Host: {app-name}.example.com という要求ヘッダー形式が使用されます 。次の cURL コマンドを使用して、検証します。curl -Lvk -XGET https://{ip-address}/{path} -H 'Host: {app-name}.example.com' -
ワイルドカードが含まれない CN (example.com など) では、
Host: example.com という要求ヘッダー形式が使用されます 。次の cURL コマンドを使用して、検証します。curl -Lvk -XGET https://{ip-address}/{app-name}/{path} -H 'Host: example.com'`
トラフィックを有効にした後
Runtime Fabric は、有効になっている各アプリケーションに受信トラフィックをルーティングするように設定されている必要があります。クライアントからデプロイ済み アプリケーションに要求を送信するには、次の操作を実行します。
-
Runtime Fabric の各コントローラー VM で HTTPS トラフィックを負荷分散するように外部ロードバランサーを設定する。
-
外部ロードバランサーを追加するときに下記の詳細オプションを確認する。
-
TLS 証明書から取得される共通名を使用する前に DNS を設定する。DNS は、Runtime Fabric にデプロイされている アプリケーションや API ゲートウェイに要求を送信するために必要になります。共通名を外部ロードバランサーまたはコントローラー VM の IP アドレスにマップするために「A レコード」を DNS プロバイダーに追加する必要があります。
新しいアプリケーションをデプロイする場合や、Runtime Fabric の既存のアプリケーションを管理する場合、[Ingress (イングレス)] タブが有効になります。 このタブでは、インバウンドトラフィックを許可すべきかどうかを指定できます。インバウンドトラフィックを有効にすると、 デフォルトの動作は新しいアプリケーションデプロイメントを許可するように切り替わります。インバウンドトラフィックを有効にする前に Runtime Fabric にデプロイされたアプリケーションがある場合、この設定が有効になるまでそれらはインバウンド要求を受信しません。
追加の設定オプション
次の表では、環境で設定することが必要になる場合がある追加の設定オプションについて説明します。この場合、 「Source IP (送信元 IP)」は要求を行っているクライアントを指します。
| 値 | 説明 |
|---|---|
Max Connections (最大接続数) |
最大許容同時接続数。 デフォルト値: 512 接続 |
Max Requests per Connection (接続あたりの最大要求数) |
接続あたりの最大許容要求数。 最大許容値: 接続あたり 1000 要求 デフォルト値: 1000 |
Connection Idle Time-out (接続アイドルタイムアウト) |
アイドル接続を許可する最大時間。 デフォルト値: 15 秒 |
Read Request Time-out (読み取り要求タイムアウト) |
要求の読み取りに費やすことができる最大時間。この時間を超えると終了します。 この値により、大きなペイロードの要求や低速なクライアントを終了して、リソースを使用できる状態を維持できます。 これは、応答の送信後に接続を終了しないクライアントや低速な要求によって接続プールが枯渇することを回避するのに役立ちます。 Mule アプリケーションの応答時間がこれよりも長くなると、接続が自動的に終了します。 この値は、常に上記で設定される [Connection Idle Time-out (接続アイドルタイムアウト)] の値よりも低くする必要があります。 デフォルト値: 10 秒 |
Read Response Time-out (読み取り応答タイムアウト) |
応答の開始に費やすことができる最大時間。この時間を超えると接続が終了します。 この値により、大きなペイロードの要求を終了して、リソースを使用できる状態を維持できます。 デフォルト値: 300 秒 |
Write Response Time-out (書き込み応答タイムアウト) |
要求ヘッダーの読み取りの終了から応答の書き込みの終了までに費やすことができる最大時間。この時間を超えると要求が終了します。 デフォルト値: 10 秒 |
Max pipeline depth (最大パイプライン深度) |
同じクライアントからの最大許容要求数。 デフォルト値: クライアントあたり 10 要求 |
[Source IP header name (送信元 IP ヘッダー名)] と [enable proxy protocol (プロキシプロトコルを有効化)] |
Runtime Fabric がロードバランサーの背後にある場合、これらの設定を行います。 ここで設定する値は、シナリオによって異なります。
デフォルト値: 空白とオフ。 |
内部ロードバランサーのログ
内部ロードバランサーのログレベルを定義できます。Runtime Fabric では、次のログレベル (詳細度の昇順で記載) がサポートされています。
-
FATAL
-
ERROR
-
WARNING
-
INFO
-
VERBOSE
-
Debug (デバッグ)
-
TRACE
ログレベルが詳細になるほど (WARNING から TRACE)、各要求でコンシュームする CPU リソースが増えます。ログレベルを調整したり、内部ロードバランサーのリソースを割り当てたりする場合、この点を考慮してください。
デフォルトでは、エンドポイントの背後にあるすべての IP アドレスのアクティビティが記録されます。より詳細なログレベルを使用する場合、CPU 消費量を減らすには、IP 検索条件を追加して特定の IP アドレスのみを記録します。また、この機能を使用して、特定の IP アドレスまたは限られた数の IP アドレスの接続をデバッグすると、ログの数量が減少します。