チュートリアル: マルチクラウドおよびハイブリッド環境における API ゲートウェイの高可用性

マルチクラウド展開は今後も継続されます。 F5 の2022 年のアプリケーション戦略の現状レポートによると、企業の 77% が複数のクラウドにまたがってアプリケーションを運用しています。 マルチクラウドおよびハイブリッド アーキテクチャを採用すると、効率性の向上、停止リスクの軽減、ベンダー ロックインの回避など、重要なメリットが得られます。 しかし、これらの複雑なアーキテクチャには、特有の課題も存在します。

F5 が調査したソフトウェアおよび IT リーダーは、マルチクラウドにおける最大の課題として以下を挙げています。

• 可視性（回答者の45％）
• セキュリティ（44％）
• アプリの移行（41%）
• パフォーマンスの最適化（40％）

マルチクラウド環境でのマイクロサービスの API の管理は特に複雑です。 包括的な API 戦略がなければ、パブリック クラウド、オンプレミス、エッジ環境全体で API が急増し、プラットフォーム運用チームが API を保護および管理する速度が追いつかなくなります。 私たちはこの問題をAPI スプロールと呼んでおり、以前の投稿でそれがなぜ重大な脅威なのかを説明しました。

エンドツーエンドの接続性を確保するには、複数のクラウドに分散されているマイクロサービスを統合するための慎重なアプローチを実装できるマルチクラウド API 戦略が必要です。 マルチクラウドおよびハイブリッド展開の一般的なシナリオは次の 2 つです。

• マルチクラウド/ハイブリッド環境におけるさまざまなサービス– コスト効率のため、またはさまざまなサービスがさまざまなユーザー グループに関連しているため、さまざまなアプリケーションと API をさまざまな場所で運用する必要があります。
• マルチクラウド/ハイブリッド環境での同じサービス- 異なる場所に展開された同じアプリケーションの高可用性を確保する必要があります。

次のチュートリアルでは、高可用性を実現するために複数の環境に同じサービスを展開するという 2 番目のシナリオで、 F5 NGINX Management Suiteの一部であるAPI Connectivity Manager を使用する方法を段階的に説明します。 これにより、マルチクラウドまたはハイブリッドの運用環境における単一障害点が排除されます。1 つのゲートウェイ インスタンスに障害が発生した場合、別のゲートウェイ インスタンスが引き継ぎ、1 つのクラウドがダウンしても顧客が停止することはありません。

API Connectivity Manager は、API のデプロイ、管理、保護のためのクラウドネイティブでランタイムに依存しないソリューションです。 パブリック クラウド、オンプレミス、エッジ環境に展開された NGINX Plus API ゲートウェイと開発者ポータルのすべての API 操作を 1 つの画面から管理できます。 これにより、プラットフォーム運用チームは API トラフィックを完全に把握できるようになり、あらゆる環境に一貫したガバナンスとセキュリティ ポリシーを簡単に適用できるようになります。

マルチクラウド展開における API ゲートウェイの高可用性の実現

はじめに述べたように、このチュートリアルでは、複数のデプロイメント環境で実行されるサービスの高可用性を実現するために API Connectivity Manager を構成します。 具体的には、NGINX Plus を API ゲートウェイとして導入し、Google Cloud Platform (GCP) と Amazon Web Services (AWS) という 2 つのパブリック クラウドで実行されている 2 つのサービス ( Service AとService B ) にトラフィックをルーティングします。 (このセットアップは、Microsoft Azure とオンプレミス データ センターを含む、あらゆる展開環境の組み合わせにも同様に適用されます。)

図 1 はチュートリアルで使用されるトポロジを示しています。

チュートリアルを完了するには、次のセクションの手順に従ってください。

• API 接続マネージャーのインストールと構成
• NGINX PlusインスタンスをAPIゲートウェイとしてデプロイする
• インフラストラクチャワークスペースを設定する
• 環境とAPIゲートウェイクラスターを作成する
• グローバルポリシーを適用する

API 接続マネージャーのインストールと構成

1. NGINX Management Suite の試用版または有料サブスクリプションを入手してください。これには、インスタンス マネージャーと API 接続マネージャーに加えて、API ゲートウェイとしての NGINX Plus と、API を保護する NGINX App Protect が含まれています。 まずは、NGINX Management Suite の 30 日間無料トライアルを開始してください。
2. NGINX Management Suiteをインストールします。 「Management Suite モジュールのインストール」セクションで、API Connectivity Manager (およびオプションでその他のモジュール) の手順に従います。
3. インストールされている各モジュールのライセンスを追加します。
4. (オプション) TLS 終端と mTLS を設定して、それぞれ NGINX Management Suite へのクライアント接続と、データ プレーン上の API Connectivity Manager と NGINX Plus インスタンス間のトラフィックを保護します。

NGINX PlusインスタンスをAPIゲートウェイとして導入する

マルチクラウドまたはハイブリッド インフラストラクチャを構成する環境を選択します。 このチュートリアルでは、AWS と GCP を選択し、各クラウドに 1 つの NGINX Plus インスタンスをインストールします。 各環境で、API ゲートウェイとして機能する各データプレーン ホストに対して次の手順を実行します。

1. サポートされているオペレーティング システムにNGINX Plus をインストールします。
2. NGINX JavaScript モジュール (njs) をインストールします。

3. /etc/nginx/nginx.confのメイン（最上位）コンテキストに次のディレクティブを追加します。

   モジュールをロードします。モジュール/ngx_http_js_module.so; モジュールをロードします。モジュール/ngx_stream_js_module.so;
   

4. たとえば次のコマンドを実行して、NGINX Plus を再起動します。

   $ nginx -s リロード
   

インフラストラクチャワークスペースを設定する

API Connectivity Manager では、複数のインフラストラクチャ ワークスペース (執筆時点では最大 10 個) を作成できます。 分離されたワークスペースを使用すると、さまざまな事業部門、開発者チーム、外部パートナー、クラウドなどに固有のポリシーと認証/承認要件を適用できます。

API Connectivity Manager GUI で作業して、新しいワークスペースを作成します。

1. 左側のナビゲーション列で「インフラストラクチャ」をクリックします。

2. 図 2 に示すように、 [+ 作成]ボタンをクリックして新しいワークスペースを作成します。

   

3. 開いた「ワークスペースの作成」パネルで、 「名前」フィールド (図 3 のdemo ) に入力します。 必要に応じて、説明フィールドとワークスペースの連絡先情報セクションのフィールドに入力します。 インフラストラクチャ管理者 (たとえば、プラットフォーム運用チーム) は、連絡先情報を使用して、ワークスペースのユーザーにステータスや問題に関する最新情報を提供できます。

   

4. [作成]ボタンをクリックします。

環境とAPIゲートウェイクラスターを作成する

API Connectivity Manager では、環境は専用リソース (API ゲートウェイや API 開発者ポータルなど) の論理的なグループです。 ワークスペースごとに複数の環境を作成できます (執筆時点では最大 25 個)。環境は通常、コーディング、テスト、本番環境など、アプリの開発と展開のさまざまな段階に対応しますが、任意の目的に使用できます。

環境内で、API ゲートウェイ クラスターは、API ゲートウェイとして機能する NGINX Plus インスタンスの論理グループです。 1 つの環境には、同じホスト名 (このチュートリアルではapi.nginx.comなど) を共有する複数の API ゲートウェイ クラスターを含めることができます。 API ゲートウェイ クラスター内の NGINX Plus インスタンスは、複数のクラウドなど、複数の種類のインフラストラクチャに配置できます。

API ゲートウェイのアクティブ/アクティブ高可用性を実現するために、API Connectivity Manager で環境を構成する方法は 2 つあります。

• 1つのAPIゲートウェイクラスター
• 複数のAPIゲートウェイクラスタ

複数の API ゲートウェイ クラスターをデプロイする主な理由は、各クラスターに異なるセキュリティ ポリシー セットを適用できるようにするためです。

NGINX Plus インスタンスを API ゲートウェイとしてデプロイするでは、2 つの NGINX Plus インスタンスをデプロイしました。1 つは AWS に、もう 1 つは GCP にデプロイしました。 このチュートリアルでは、同じインスタンスを使用して両方の環境タイプ (単一の API ゲートウェイ クラスターまたは複数の API ゲートウェイ クラスター) を説明します。両方の環境タイプを単一のワークスペースにデプロイする場合は、2 番目の環境用に追加の NGINX Plus インスタンスを作成する必要があります。

1 つの API ゲートウェイ クラスターを使用して環境をデプロイする

1 つの API ゲートウェイ クラスターを持つ環境の場合、図 4 に示すように、すべての NGINX Plus API ゲートウェイ インスタンスに同じセキュリティ ポリシーが適用されます。

環境とAPIゲートウェイクラスターを作成する

1. 図 5 に示すように、ワークスペースに移動し、 [環境の作成]ボタンをクリックします。

   

2. 開いた「環境の作成」パネルで、 「名前」フィールド (図 6 のprod ) とオプションで「説明」フィールドに入力し、環境タイプを選択します (ここではProd を選択します)。

   

3. API Gateway クラスターセクションで、名前とホスト名のフィールド (図 6 のapi-clusterとapi.nginx.com ) に入力します。

4. [作成]ボタンをクリックします。

   「環境が作成されました」パネルが開き、各 NGINX Plus インスタンスで実行して API ゲートウェイ クラスターに割り当てる必要があるコマンドが表示されます。 便宜上、以下の手順 7のコマンドを示します。

API ゲートウェイ インスタンスを API ゲートウェイ クラスターに割り当てる

各 NGINX Plus インスタンスで繰り返します。

5. ssh を使用してインスタンスに接続し、ログインします。

6. NGINX エージェントがすでに実行されている場合は、停止します。

   $ systemctl nginx-agentを停止します
   

7. 任意のコマンド ( curlまたはwget ) を実行して、NGINX エージェント パッケージをダウンロードしてインストールします。

   • API Connectivity Manager のインストールと構成で mTLS を有効にしなかった場合は、以下を追加します。

     • curlコマンドの-kフラグ
     • wgetコマンドの--no-check-certificateフラグ
   • のために <NMS_FQDN>を、NGINX Management Suite サーバーの IP アドレスまたは完全修飾ドメイン名に置き換えます。
   • のために <クラスター名>、APIゲートウェイクラスタの名前を置き換えます（API クラスター (このチュートリアルでは)

   $ カール [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <クラスター名> && sudo systemctl nginx-agentを起動します
   

   または

   $ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <クラスター名> && sudo systemctl nginx-agentを起動します
   

   図 7 に示すように、NGINX Plus インスタンスがapi-clusterのClusterウィンドウのInstancesセクションに表示されます。

   

8. グローバルポリシーの適用に進みます。

複数の API ゲートウェイ クラスターを備えた環境をデプロイする

複数の API ゲートウェイ クラスターがある環境では、図 8 に示すように、異なる NGINX Plus API ゲートウェイ インスタンスに異なるセキュリティ ポリシーを適用できます。

環境とAPIゲートウェイクラスターを作成する

1. 図 9 に示すように、ワークスペースに移動し、 [環境の作成]ボタンをクリックします。

   

2. 開いた「環境の作成」パネルで、 「名前」フィールド (図 10 のprod ) とオプションで「説明」フィールドに入力し、環境タイプを選択します (ここではProd を選択します)。

   

3. API Gateway Clustersセクションで、 Name フィールドとHostnameフィールドに入力します (図 10 では、 aws-clusterとapi.nginx.comです)。

4. [作成]ボタンをクリックします。

   「環境が作成されました」パネルが開き、各 NGINX Plus インスタンスで実行して API ゲートウェイ クラスターに割り当てる必要があるコマンドが表示されます。 便宜上、以下の手順 10のコマンドを示します。

5. [環境] タブに戻り、図 11 に示すように、 [API Gateway クラスター]セクションの右上隅にある[+ 追加]ボタンをクリックします。

   

6. [API Gateway クラスターの作成]パネルで、 [名前]フィールドに 2 番目のクラスター名 (図 12 のgcp-cluster ) を入力し、 [ホスト名]フィールドに最初のクラスターと同じホスト名 ( api.nginx.com ) を入力します。

   

図 13 に示すように、2 つの API ゲートウェイ クラスターがProd環境のAPI ゲートウェイ クラスターに表示されます。

API ゲートウェイ インスタンスを API ゲートウェイ クラスターに割り当てる

各 NGINX Plus インスタンスで繰り返します。

8. ssh を使用してインスタンスに接続し、ログインします。

9. NGINX エージェントがすでに実行されている場合は、停止します。

   $ systemctl nginx-agentを停止します
   

10. 任意のコマンド ( curlまたはwget ) を実行して、NGINX エージェント パッケージをダウンロードしてインストールします。

    • API Connectivity Manager のインストールと構成で mTLS を有効にしなかった場合は、以下を追加します。

      • curlコマンドの-kフラグ
      • wgetコマンドの--no-check-certificateフラグ
    • のために <NMS_FQDN>を、NGINX Management Suite サーバーの IP アドレスまたは完全修飾ドメイン名に置き換えます。
    • のために <クラスター名>適切なAPIゲートウェイクラスタの名前に置き換えてください（このチュートリアルでは、 aws クラスター AWSにデプロイされたインスタンスと gcp クラスタ GCP にデプロイされたインスタンスの場合)。

    $ カール [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <クラスター名> && sudo systemctl nginx-agentを起動します
    

    または

    $ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <クラスター名> && sudo systemctl nginx-agentを起動します
    

    適切な NGINX Plus インスタンスが、 aws-cluster (図 14) およびgcp-cluster (図 15) のClusterウィンドウのInstancesセクションに表示されます。

    

    

    グローバルポリシーを適用する

    これで、API ゲートウェイ クラスター内のすべての NGINX Plus インスタンスに適用されるグローバル ポリシーを追加できるようになりました。 たとえば、API へのクライアント アクセスを保護するには、OpenID Connect Relying PartyまたはTLS 受信ポリシーを適用できます。 API ゲートウェイと API を公開するバックエンド サービス間の接続を保護するには、 TLS バックエンドポリシーを適用します。 TLS ポリシーの詳細については、 API Connectivity Manager のドキュメントを参照してください。

    1. ポリシーを適用する API Gateway のClusterタブに移動します (図 16 のapi-cluster )。 ポリシーテーブルの右上隅にある[管理]ボタンをクリックします。

       

    2. 左側のナビゲーション列で[グローバル ポリシー]をクリックし、ポリシーの行の右端の列にある…アイコンをクリックします (図 17 のTLS バックエンド)。 ドロップダウン メニューから[+ ポリシーの追加]を選択します。

       

    結論

    マルチクラウドとハイブリッド アーキテクチャの管理は簡単な作業ではありません。 これらは、急速に変化するアプリケーションを備えた複雑な環境であり、監視やセキュリティ保護が困難な場合が多くあります。

    ただし、適切なツールを使用すれば、ベンダー ロックインを回避しながら、新しい機能を市場に迅速に提供するために必要な俊敏性と柔軟性を維持できます。 クラウドネイティブ ツールである NGINX の API Connectivity Manager は、マルチクラウドおよびハイブリッド環境で API を管理するために必要なスケーラビリティ、可視性、ガバナンス、セキュリティを提供します。

    NGINX Management Suite の 30 日間無料トライアルを開始します。これには、 API Connectivity Manager 、API ゲートウェイとしてのNGINX Plus 、API を保護するNGINX App Protectへのアクセスが含まれます。