1. Homepage
  2. Runtime Fabric (1.4)

  3. Anypoint Runtime Fabric でのインバウンドトラフィックの有効化

Anypoint Runtime Fabric でのインバウンドトラフィックの有効化

Runtime Fabric は、Mule アプリケーションや API プロキシへのインバウンドトラフィックを管理するための負荷分散を提供します。ネットワークトラフィックは、アプリケーションの複数のレプリカで分散されます。デフォルトでは、レプリカは異なるワーカー VM にデプロイされます。

Runtime Fabric は、複数の環境で共有できます。インストール後、各 Runtime Fabric の 1 つ以上の環境を設定して、アプリケーションデプロイメントを有効にします。Mule アプリケーションや API ゲートウェイをデプロイできるようにするには、1 つ以上の環境を各 Runtime Fabric に関連付ける必要があります。

本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションとは異なる Runtime Fabric のインスタンスにデプロイされる必要があります。

デフォルトでは、不要なリソースをコンシュームしないようにインバウンドトラフィックが無効になっています。Mule アプリケーションや API ゲートウェイでインバウンド接続をリスンできるようにするには、インバウンドトラフィックを有効にします。

ステップ 1: 必要なロールと権限を割り当てる

アプリケーションで使用する Runtime Fabric 環境に必要な権限を持っていることを確認します。

  1. Anypoint Platform から ​[Access Management (アクセス管理)]​ を選択します。

    [Access Management (アクセス管理)]​ にアクセスできない場合、組織の管理者 (システム管理者) に「Manage Runtime Fabrics (Runtime Fabric の管理)」権限をユーザーに付与するよう要求します。アクセスできる場合、次のステップを実行して権限を追加します。

  2. [Users (ユーザー)]​ を選択します。

  3. ユーザー名が含まれる行を見つけ、​[Username (ユーザー名)]​ 列の青いリンクを選択します。

  4. [Runtime Manager]​ タブで、Runtime Fabric 環境の ​[Manage Runtime Fabrics (Runtime Fabric の管理)]​ 権限を有効にします。

    追加した権限が伝播されるまで最大 5 分ほどかかることがあります。

ステップ 2: Runtime Manager を使用してインバウンドトラフィックを設定する

  1. [Runtime Manager] に移動し、​[Runtime Fabric]​ を選択します。

  2. Runtime Fabric の名前を選択して、管理ページを開きます。

  3. [Associated Environments (関連付けられた環境)]​ タブで、Runtime Fabric 環境がアプリケーションをデプロイする環境に関連付けられていることを確認します。

  4. [Inbound Traffic (インバウンドトラフィック)]​ を選択し、​[Enable inbound traffic (インバウンドトラフィックを有効化)]​ をオンに切り替えます。

    [Inbound Traffic (インバウンドトラフィック)] タブを無効にした場合、変更が完了するまで数分かかる場合があります。

  5. [Basic Configuration (基本設定)]​ セクションで、​[Secure Port (セキュアなポート)]​ が ​443​ に設定され、​[Non Secure Port (セキュアでないポート)]​ が ​80​ に設定されていることを確認します。 セキュアでないポートはセキュアなポートにリダイレクトします。

  6. [Resource Allocation (リソース割り当て)]​ セクションでは、次のようになっています。

    インバウンドロードバランサーは、Runtime Fabric で設定された各コントローラーノードで実行されます。詳細は、​「Runtime Fabric の管理」​を参照してください。

    Runtime Fabric で専用のロードバランサーノードを追加していない場合、​[Shared Mode (共有モード)]​ がデフォルト設定です。このモードでは、内部ロードバランサーは指定された CPU およびメモリの量のすべてのコントローラーノードで実行されます。

    [Dedicated Mode (専用モード)]​ では、ノード全体が使用可能であると指定されるため、コアおよびメモリの量を指定することはできません。​[Dedicated Mode (専用モード)]​ が無効の場合、すべてのノードはすでに共有モードになっているため、専用にすることはできません。

    1. 内部ロードバランサーの各コントローラーノードに割り当てるコアの最小数を指定します。

      コアが使用できる場合、Runtime Fabric では表示された最大数まで使用できます。トランスポート層セキュリティ (TLS) の終了は計算コストが高くなるため、十分な量の CPU を割り当ててスループットを増やし、遅延を減らしてください。TLS 非公開キーの種類とサイズが個数に与える影響を含め、CPU 割り当ておよびスループットについての詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。

    2. 内部ロードバランサーの各コントローラーノードに割り当てる最小メモリを指定します。メモリが使用できる場合、Runtime Fabric では表示された最大良まで使用できます。

  7. TLS コンテキストを設定します。

    Anypoint Runtime Fabric へのすべてのインバウンドトラフィックは、TLS を使用して暗号化されます。インバウンドトラフィックを有効にするときに、有効な TLS 証明書を提供する必要があります。インバウンドトラフィックが有効になると、Runtime Fabric に送信される HTTP 要求は、​301​ 応答を受信して、ポート 443 で HTTPS にリダイレクトします。

    次のいずれかの方法で、TLS 対応サーバーの非公開キーおよび公開証明書を設定できます。

    • オプション 1: [Upload PEM (PEM をアップロード)]​

      公開証明書と非公開キーを Privacy-Enhanced Mail (PEM) 形式でアップロードして TLS のデフォルト値を使用するには、このオプションを使用します。PEM ファイルは ​.cer​、​.crt​、または ​.pem​ 拡張子の Base64 でエンコードされた ASCII ファイルです。

      このオプションを使用する場合、TLS バージョン、暗号、その他の TLS 設定オプションのデフォルト値を変更することはできません。TLS のデフォルト値についての詳細は、​「Runtime Fabric ロードバランサーの TLS コンテキストの設定」​を参照してください。

      これは、Runtime Fabric 用に TLS コンテキストが存在しない場合のデフォルトのオプションです。

      1. [Certificate File (証明書ファイル)]​ について、インバウンドトラフィックサーバーの公開証明書を PEM 形式で指定します。​[Derived URL Format (派生した URL 形式)]​ 項目には、​[Application url (アプリケーション URL)]​ に選択可能なドメインがリストされます。これは、アプリケーションへの要求のルーティングに使用されます。デフォルトでは、リストされた最初のドメインが使用されます。その他の値は ​[Applications (アプリケーション)]→[Ingress (イングレス)]​ ページで選択できます。

        証明書はパスフレーズと、Runtime Fabric にデプロイされている各アプリケーションのドメインを指定する共通名 (CN) を使用して設定されている必要があります。

        • 共通名にワイルドカードが含まれている場合、デプロイされている各アプリケーションのエンドポイントの形式は ​{app-name}.{common-name}​ のようになります。

        • 共通名にワイルドカードが含まれていない場合、エンドポイントの形式は ​{common-name}/{app-name}​ のようになります。

      2. [Key File (キーファイル)]​ の値を指定します。これは、証明書の非公開キーを含む PEM 形式のファイルです。

      3. PEM キーファイルをアップロードした後で ​[Key Passcode (キーパスコード)]​ 項目が表示された場合、非公開キーを保護する単語または語句を入力します。

      4. 必要に応じて、​[CA Path Certificate File (Optional) (CA パス証明書ファイル (省略可能))]​ の値を指定します。CA パスには、証明書からルートへのパス (信頼チェーン) を提供する中間証明書とルート証明書が含まれます。この項目で入力を行うと、パスは TLS ハンドシェイク中に証明書と一緒に送信されます。

      5. [Deploy (デプロイ)]​ を選択します。​[Key Passcode (キーパスコード)]​ 項目はセキュリティ上の理由から無効になっています。引き続き、公開証明書の詳細を確認することはできます。新しいキーファイルをアップロードした場合、この項目は再び有効になります。

        公開証明書、非公開キー、キーパスコードはシークレットマネージャーに保存されます。

    • オプション 2: [Upload JKS (JKS をアップロード)]​

      Java Keystore (JKS) ファイルをアップロードして TLS のデフォルト値を使用するには、このオプションを使用します。このオプションを使用する場合、TLS バージョン、暗号、その他の TLS 設定オプションのデフォルト値を変更することはできません。JKS ファイルは認証用のリポジトリまたは公開キー証明書であり、シークレットキーは保存されません。詳細は、​「Runtime Fabric ロードバランサーの TLS コンテキストの設定」​を参照してください。

      1. [Keystore File (キーストアファイル)]​ の値を指定します。少なくとも、キーストアファイルには公開証明書と非公開キーが含まれています。この 2 つはキーペアとも呼ばれています。

      2. [Keystore Passcode (キーストアパスコード)]​ の値、キーストアを保護する単語または語句を指定します。

      3. [Alias (別名)]​ の値を指定します。別名は、特定のキーペアを選択するために使用されます。

        この項目は、キーストアファイルとキーストアパスコードを指定した後で有効になります。

      4. [Choose Alias From Keystore (キーストアから別名を選択)]​ ウィンドウで、別名を選択します。次の情報が表示されます。

        • 証明書の共通名に基づいてアプリケーションに使用される URL 形式。

          証明書はパスフレーズと、Runtime Fabric にデプロイされている各アプリケーションのドメインを指定する共通名を使用して設定されている必要があります。ドメインは、アプリケーションへの要求のルーティングに使用されます。その他の値は ​[Applications (アプリケーション)]→[Ingress (イングレス)]​ ページで選択できます。

          • 共通名にワイルドカードが含まれている場合、デプロイされている各アプリケーションのエンドポイントの形式は ​{app-name}.{common-name}​ のようになります。

          • 共通名にワイルドカードが含まれていない場合、エンドポイントの形式は ​{common-name}/{app-name}​ のようになります。

        • シークレットの有効期限。

      5. [Key Passcode (キーパスコード)]​ の値、非公開キーを保護する単語または語句を指定します。

        この項目は、別名を指定した後で有効になります。

      6. 他のオプションを選択するかデプロイする前に、​[Keystore File (キーストアファイル)]​、​[Keystore Passcode (キーストアパスコード)]​、​[Alias (別名)]​、​[Key Passcode (キーパスコード)]​ の値を入力していることを確認します。

      7. [Deploy (デプロイ)]​ を選択します。​[Keystore Passcode (キーストアパスコード)]​ 項目と ​[Key Passcode (キーパスコード)]​ 項目はセキュリティ上の理由から無効になっています。

        • 異なる ​[Alias (別名)]​ の値を選択した場合、​[Key Passcode (キーパスコード)]​ 項目は再び有効になります。

        • 新しいキーストアファイルをアップロードした場合、​[Alias (別名)]​ 項目と ​[Keystore Passcode (キーストアパスコード)]​ 項目は再び有効になり、​[Alias (別名)]​ 項目のコンテンツがクリアされます。

          JKS ファイルの情報は組織のグローバルシークレットグループに保存されます。

    • オプション 3: [Import from Secrets Manager (シークレットマネージャーからインポート)]​ (高度なユーザー向け)

      このオプションは、PEM および JKS のアップロードオプションが使用できるようになる前にインバウンドトラフィックが有効になった Runtime Fabric では自動的に選択されます。手順については、​「Runtime Fabric ロードバランサーの TLS コンテキストの設定」​を参照してください。

      このオプションはシークレットマネージャーから TLS コンテキストをインポートし、TLS コンテキストの作成、相互認証、暗号化の選択、TLS バージョンの選択などの高度な設定をサポートしています。

      シークレットマネージャーから TLS コンテキストをインポートするには、追加のシークレットマネージャー権限が必要です。詳細は、​「Runtime Fabric ロードバランサーの TLS コンテキストの設定」​を参照してください。

      テスト目的でキー素材を生成してシークレットマネージャーで TLS コンテキストを作成するには、このトピックの後半にある「テストのために TLS 証明書を生成する」の手順に従ってください。

  8. (省略可能) シークレットセキュリティポリシー

    シークレットポリシーを ​[HTTP Limits (HTTP 制限)]​、​[Web Application Firewall (WAF) (Web アプリケーションファイアウォール (WAF))]​、​[IP Whitelist (IP ホワイトリスト)]​、または ​[Denial of Service (DoS) (サービス拒否 (DoS))]​ ドロップダウンリストのオプションとして表示するには、Anypoint Security で定義する必要があります。

    Anypoint Security でセキュリティポリシーを定義するには、Anypoint Platform アカウントの「Anypoint Security - Edge」エンタイトルメントが必要です。​[Management Center]​ で ​[Security (セキュリティ)]​ がリストされていない場合は、アカウントで Anypoint Security を有効にするようにカスタマーサクセスマネージャーに依頼してください。

    詳細は、​「Edge の Anypoint Security ポリシー」​を参照してください。

  9. (省略可能) 詳細オプションを選択する

    次の表では、環境で設定することが必要になる場合がある追加の設定オプションについて説明します。この場合、 ​「Source IP (送信元 IP)」​は要求を行っているクライアントを指します。

    値 説明

    ​Max Connections (最大接続数)​

    最大許容同時接続数。

    デフォルト値​: 512 接続

    ​Max Requests per Connection (接続あたりの最大要求数)​

    接続あたりの最大許容要求数。
    この値の範囲は 1 ～ 4194304 です。
    この値により、接続でどれぐらいの再利用が許可されるのかが決まるため、この値を低くする場合、TLS で暗号化された接続を終了および再確立するのに必要な CPU の量を考慮してください。

    最大許容値​: 接続あたり 1000 要求

    デフォルト値​: 1000。この値で、セキュリティとパフォーマンスのバランスを取ります。詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。

    ​Connection Idle Time-out (接続アイドルタイムアウト)​

    アイドル接続を許可する最大時間。
    この値は、アイドル接続を終了してリソースを解放するのに役立ちます。
    この値は、常に ​[Read Request 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 (プロキシプロトコルを有効化)]​

    適用されるシナリオに基づいて次の値を設定します。

    1. Runtime Fabric がロードバランサーの背後にデプロイされていない。
      次の値を設定する必要はありません。

      Source IP header name (送信元 IP ヘッダー名)​: 空白
      Enable proxy protocol (プロキシプロトコルを有効化)​: オフ

    2. Runtime Fabric がプロキシプロトコルが設定された AWS ロードバランサーの背後にデプロイされている。
      ​[enable proxy protocol (プロキシプロトコルを有効化)]​ オプションをオンにする必要があります。

      Source IP header name (送信元 IP ヘッダー名)​: 空白
      Enable proxy protocol (プロキシプロトコルを有効化)​: オン

    3. Runtime Fabric が AWS 以外のロードバランサーの背後にある。
      Runtime Fabric が別の種別のロードバランサー (F5 や nginx など) の背後にデプロイされている場合、[HTTP Header (HTTP ヘッダー)] 項目で送信元 IP アドレスを指定できます。この場合、送信元 IP ヘッダーが含まれる HTTP ヘッダー名を入力します。

      このヘッダー項目が含まれていない HTTP メッセージは拒否されます。送信元 IP アドレスに使用される 2 つの共通の HTTP ヘッダー名は次のとおりです。

      • Forwarded: RFC7239 準拠の IP ヘッダー。

      • X-Forwarded-For: ロードバランサーの 1 つ以上の IP (「192.16.23.34、172.16.21.36」など) が含まれる 2014 年以前の非標準ヘッダー

        Source IP header name (送信元 IP ヘッダー名)​: 空白以外
        Enable proxy protocol (プロキシプロトコルを有効化)​: オフ

    デフォルト値​: 空白とオフ。

  10. (省略可能) 内部ロードバランサーのログを設定する

    内部ロードバランサーのログレベルを定義できます。Runtime Fabric では、次のログレベル (詳細度の昇順で記載) がサポートされています。

    • FATAL

    • ERROR

    • WARNING

    • INFO

    • VERBOSE

    • DEBUG

    • TRACE

      ログレベルが詳細になるほど (WARNING、INFO、VERBOSE、DEBUG、TRACE など)、各要求でコンシュームする CPU リソースが増えます。ログレベルを調整したり、内部ロードバランサーのリソースを割り当てたりする場合、この点を考慮してください。

      デフォルトでは、エンドポイントの背後にあるすべての IP アドレスのアクティビティが記録されます。より詳細なログレベルを使用する場合、CPU 消費量を減らすには、ログ固有の IP アドレスに IP 検索条件を追加します。また、この機能を使用して、特定の IP アドレスまたは限られた数の IP アドレスの接続をデバッグすると、ログの数量が減少します。

      1. Anypoint Platform から ​[Runtime Manager]​ を選択します。

      2. [Runtime Fabric]​ を選択します。

      3. [Inbound Traffic (インバウンドトラフィック)]​ タブを選択し、​[Logs (ログ)]​ を選択します。

      4. [Add Filter (検索条件を追加)]​ を選択します。

      5. [IP]​ 項目で、CIDR 表記を使用して 1 つの IP アドレスまたはアドレスのサブセットを入力します。

      6. この IP 検索条件に適用するログレベルを選択します。

      7. [OK]​ を選択します。

  11. [Deploy (デプロイ)]​ を選択して内部ロードバランサーをデプロイします。

    デプロイメントが完了するまでには、最大 1 分かかる場合があります。

    検証エラーが発生すると、エラーメッセージが返されます。検証に成功すると、ページの右下にメッセージが緑色のテキストで表示され、デプロイメント要求が受け入れられたことを示します。デプロイメントの状況は、ページの一番上で確認できます。

ステップ 3: インバウンドトラフィックが有効になっていることを確認する

デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。

  1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​[Manage application (アプリケーションを管理)]​ ページの ​[Application url (アプリケーション URL)]​ フィールドにこの情報が含まれます。

  2. 次の cURL コマンドを実行して検証します。

    curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller}

    次の例では、​{application-path-from-runtime-manager}​ は ​https://newapp.example-rtf.dev​ に設定され、​192.168.64.14​ はクラスターのコントローラーマシンの IP アドレスです。

    curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14

ステップ 4: 外部ロードバランサーを設定する

インバウンドトラフィックを有効にしたら、クライアントがデプロイされたアプリケーションに要求を送信できるように、有効になっている各アプリケーションに受信トラフィックをルーティングするよう Runtime Fabric を設定する必要があります。

Runtime Fabric の各コントローラー VM で HTTPS トラフィックを負荷分散するように外部ロードバランサーを設定する必要があります。コントローラー VM は、Anypoint Runtime Fabric を強化するコンポーネントを実行する専用の仮想マシンです。各コントローラー VM は、内部ロードバランサーのレプリカを実行し、ポート 443 でリスンするように設定されています。

外部ロードバランサーの要件

複数のコントローラー VM を実行する場合、各コントローラー VM に直面する Runtime Fabric 外に外部ロードバランサーが必要になります。

外部ロードバランサーは TCP 負荷分散をサポートしている必要があり、各コントローラー VM の IP アドレスが含まれるサーバープールを使用して設定されている必要があります。また、外部ロードバランサーには、ポート 443 をリスンする状態チェックも設定されている必要があります。

この外部ロードバランサーの設定には、次の利点があります。

  • 高可用性を維持する。

  • 障害から保護する。

  • 内部ロードバランサーのレプリカが再起動するか、削除されて別のコントローラー VM で再スケジュールされた場合に、自動フェールオーバーを適切に処理する。

外部ロードバランサーを設定する手順は、次のとおりです。

  1. 外部ロードバランサーを追加するときは、​「詳細オプション」​で説明している情報を確認してください。

  2. TLS 証明書から取得される共通名を使用する前に DNS を設定します。DNS は、Runtime Fabric にデプロイされている アプリケーションや API ゲートウェイに要求を送信するために必要になります。共通名を外部ロードバランサーまたはコントローラー VM の IP アドレスにマップするために「A レコード」を DNS プロバイダーに追加します。

ステップ 5: アプリケーションをデプロイする

アプリケーションをデプロイする準備ができたら、​「Runtime Fabric に Mule アプリケーションをデプロイする」​の手順に従います。

[Ingress (イングレス)]​ タブでは、アプリケーションでインバウンドトラフィックを許可するかどうかを指定できます。インバウンドトラフィックを有効にすると、デフォルトの動作は新しいアプリケーションのデプロイメントを許可するように変更されます。インバウンドトラフィックを有効にする前に Runtime Fabric にデプロイされたアプリケーションがある場合、この設定が有効になるまでそれらはインバウンド要求を受信しません。

テストのために TLS 証明書を生成する

テスト目的で、次の手順を使用して証明書とキーのペアを生成できます。

  1. マシンで次のコマンドを実行して証明書とキーのペアを生成します。

    openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

  2. キーのパスフレーズを入力します。

  3. 必要な情報を入力します。共通名を求められた場合、Runtime Fabric で使用するドメインを入力します。

共通名にワイルドカード (​*.example.com​ など) を使用する場合、アプリケーション URL では ​{app-name}.example.com​ の形式が使用されます。使用しない場合、アプリケーション URL では ​example.com/{app-name}​ の形式が使用されます。

TLS 証明書の期限切れ

証明書 (自己署名と CA 署名の両方) には必ず有効期限があります。デフォルトでは、証明書は作成されてから 1 年後に有効期限が切れます。

30 日以内に期限が切れる証明書については次の警告が表示され、証明書の期限が切れる前に新しい証明書とキーのペアをアップロードするよう促されます。

  • [Runtime Fabrics]​ ページでは、TLS 証明書が 30 日以内に期限切れになる場合、​TLS Expiring​ が ​[Inbound traffic (インバウンドトラフィック)]​ 列に表示されます。

  • [Runtime Fabrics]​ ページでは、TLS 証明書が期限切れになると、警告がその RTF の ​[Inbound traffic (インバウンドトラフィック)]​ 列に表示されます。

  • [Inbound Traffic (インバウンドトラフィック)]​ タブでは、TLS 証明書が 30 に以内に期限切れになる場合、警告が表示されます。TLS 証明書が期限切れになると、有効期限情報で ​[Certificate File (証明書ファイル)]​ 項目に赤い警告が含まれます。

関連情報