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

Akash Ananthanarayananテクニカルマーケティングマネージャー | F5 NGINX

マルチクラウド環境の導入は、今後も定着していくでしょう。F5の「2022年版アプリケーション戦略の現状」レポートによると、企業の77%が複数のクラウドでアプリケーションを運用しています。マルチクラウドおよびハイブリッドアーキテクチャの採用により、効率の向上、停止リスクの低減、ベンダーロックインの回避といった重要なメリットが得られます。一方で、こうした複雑なアーキテクチャには固有の課題もあります。

F5が調査したソフトウェアおよびIT部門のリーダーは、マルチクラウドに関する主な課題として、次の項目を挙げています。

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

マルチクラウド環境におけるマイクロサービスのAPI管理は、特に複雑です。包括的なAPI戦略がなければ、Platform Opsチームによるセキュリティ確保と管理が追いつかないほどの速さで、APIがパブリッククラウド、オンプレミス、エッジ環境に拡散します。F5では、この問題を「APIスプロール」と呼んでいます。以前の「投稿」では、これが重大な脅威となる理由を説明しました。

複数のクラウドに分散しているマイクロサービスを適切なアプローチで統合し、エンドツーエンドの接続性を確保するには、マルチクラウドAPI戦略が必要です。マルチクラウドおよびハイブリッド環境への導入で一般的なシナリオとして、次の2つが挙げられます。

• マルチクラウド／ハイブリッド環境における異なるサービス – コスト効率を高めるため、またはユーザーグループごとに必要なサービスが異なるため、アプリケーションやAPIをそれぞれ異なる場所で運用する必要があります。
• マルチクラウド／ハイブリッド環境における同一サービス – 異なる場所にデプロイされた同一のアプリケーションについて、高可用性を確保する必要があります。

以下のチュートリアルでは、API Connectivity Manager（F5 NGINX Management Suiteの一部）を使用して、2つ目のシナリオである、高可用性を確保するために同じサービスを複数の環境へデプロイする方法を手順に沿って説明します。これにより、マルチクラウドまたはハイブリッドの本番環境における単一障害点を排除できます。1つのゲートウェイインスタンスに障害が発生した場合は、別のゲートウェイインスタンスが引き継ぐため、1つのクラウドが停止しても、お客さまのサービスが中断することはありません。

API Connectivity Managerは、APIのデプロイ、管理、セキュリティ確保に対応する、クラウドネイティブかつランタイムに依存しないソリューションです。単一の管理画面から、パブリッククラウド、オンプレミス、エッジ環境にデプロイされたNGINX Plus APIゲートウェイと開発者ポータルに関するすべてのAPI運用を管理できます。これにより、プラットフォーム運用チームはAPIトラフィックを包括的に可視化し、すべての環境に一貫したガバナンスとセキュリティポリシーを容易に適用できます。

マルチクラウド環境に導入したAPIゲートウェイの高可用性を実現

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

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

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

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

API Connectivity Managerのインストールと設定

1. NGINX Management Suiteのトライアルまたは有料サブスクリプションを取得します。NGINX Management Suiteには、Instance ManagerとAPI Connectivity Managerに加え、APIゲートウェイとしてのNGINX Plusと、APIを保護するNGINX App Protectが含まれています。まずはNGINX Management Suiteの30日間無料トライアルを開始してください。
2. Install NGINX Management Suiteをインストールします。［Install Management Suite Modules］セクションで、API Connectivity Manager（必要に応じてその他のモジュールも含む）の手順に従います。
3. ライセンスを追加します（インストール済みの各モジュールが対象）。
4. （任意）TLS終端とmTLSを設定します。これにより、NGINX Management Suiteへのクライアント接続と、API Connectivity Managerとデータプレーン上のNGINX Plusインスタンス間のトラフィックをそれぞれ保護できます。

NGINX PlusインスタンスをAPIゲートウェイとしてデプロイ

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

1. NGINX Plusをインストールします。インストール先には、サポート対象のオペレーティングシステムを使用してください。
2. NGINX JavaScriptモジュールをインストールします（njs）。
3. 次のディレクティブを/etc/nginx/nginx.confのmain（最上位）コンテキストに追加します：

load_module modules/ngx_http_js_module.so;load_module modules/ngx_stream_js_module.so;

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

$ nginx -s reload

インフラストラクチャワークスペースのセットアップ

API Connectivity Managerでは、複数のInfrastructure Workspace（執筆時点では最大10個）を作成できます。Workspaceを分離することで、事業部門、開発者チーム、外部パートナー、クラウドなどに固有のポリシーや認証／認可要件を適用できます。

API Connectivity ManagerのGUIで、新しいWorkspaceを作成します。

1. 左側のナビゲーション列で［Infrastructure］をクリックします。
2. Click the + Createをクリックして、新しいワークスペースを作成します（図2を参照）。
   
   図2：新しいInfrastructure Workspaceの作成
3. 開いた［Create Workspace］パネルで、［Name］フィールドに入力します（図3では「demo」）。必要に応じて、［Description］フィールドと［Workspace Contact Information］セクションの各フィールドにも入力します。インフラストラクチャ管理者（たとえば、Platform Opsチーム）は、この連絡先情報を使用して、Workspaceのユーザーにステータスや問題に関する最新情報を提供できます。
   
   図3：新しいInfrastructure Workspaceの命名と連絡先情報の追加
4. ［Create］をクリックします。

環境とAPI Gatewayクラスターの作成

API Connectivity Managerでは、Environmentは専用リソース（APIゲートウェイやAPI開発者ポータルなど）を論理的にグループ化したものです。Workspaceごとに複数のEnvironmentを作成できます（執筆時点では最大25個）。通常は、コーディング、テスト、本番環境など、アプリの開発およびデプロイの各段階に対応しますが、任意の目的に使用できます。

Environment内のAPI Gateway Clusterは、APIゲートウェイとして機能するNGINX Plusインスタンスを論理的にグループ化したものです。1つのEnvironmentに、同じホスト名（このチュートリアルでは、たとえばapi.nginx.com）を共有する複数のAPI Gateway Clusterを配置できます。API Gateway Cluster内のNGINX Plusインスタンスは、複数のクラウドなど、複数の種類のインフラストラクチャに配置できます。

API Connectivity ManagerでAPIゲートウェイのアクティブ／アクティブ高可用性を実現するようにEnvironmentを構成する方法は、次の2つです。

• 1つのAPI Gateway Clusterを使用
• 複数のAPI Gateway Clusterを使用

複数のAPI Gateway Clusterをデプロイする主な理由は、クラスターごとに異なるセキュリティポリシーのセットを適用できるようにすることです。

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

1つのAPI Gateway Clusterを使用するEnvironmentのデプロイ

図4に示すように、API Gateway Clusterが1つのEnvironmentでは、すべてのNGINX Plus APIゲートウェイインスタンスに同じセキュリティポリシーが適用されます。

環境とAPI Gateway Clusterの作成

1. Workspaceに移動し、 Create Environmentボタンをクリックします（図5を参照）。
   
   図5：Infrastructure Workspaceでの新しいEnvironmentの作成
2. 開いた［Create Environment］パネルで、［Name］フィールド（図6では「prod」）と、必要に応じて［Description］フィールドに入力し、Environmentのタイプを選択します（ここでは［Prod］を選択します）。
   
   図6：新しいEnvironmentの命名とAPI Gateway Clusterの割り当て
3. In the API Gateway Clustersセクションで、NameフィールドとHostnameフィールドに入力します（図6のapi-clusterとapi.nginx.com）。
4. ［Create］ボタンをクリックします。［Environment Created］パネルが開き、各NGINX PlusインスタンスをAPI Gateway Clusterに割り当てるために実行する必要があるコマンドが表示されます。参照しやすいように、これらのコマンドを以下の［Step 7］に示します。

API GatewayインスタンスをAPI Gateway Clusterに割り当てる

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

1. Use sshを使用してインスタンスに接続し、ログインします。
2. NGINX Agentがすでに実行中の場合は、停止します：

$ systemctl stop nginx-agent

1. 任意のコマンド（curlまたはwget）を実行して、NGINX Agentパッケージをダウンロードし、インストールします：

$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent

1. または

$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent

1. 図7に示すように、NGINX PlusインスタンスがInstancesセクション（Clusterウィンドウのapi-cluster）に表示されます。
   
   図7：単一のAPI Gateway Clusterで、複数のクラウドにデプロイされたNGINX Plusインスタンスをグループ化
   • 「API Connectivity Managerのインストールと設定」でmTLSを有効にしていない場合は、以下を追加します。
     • The ‑kフラグをcurlコマンドに追加
     • The --no-check-certificateフラグをwgetコマンドに指定
   • For <NMS_FQDN>には、NGINX Management SuiteサーバーのIPアドレスまたは完全修飾ドメイン名を指定します。
   • For <cluster_name>には、API Gateway Clusterの名前（このチュートリアルでは「api-cluster」）を指定します。
2. 次に「グローバルポリシーを適用」へ進みます。

複数のAPI Gatewayクラスターを使用する環境のデプロイ

複数のAPI Gateway Clusterを含むEnvironmentでは、図8に示すように、NGINX Plus APIゲートウェイのインスタンスごとに異なるセキュリティポリシーを適用できます。

環境とAPI Gateway Clusterの作成

1. Workspaceに移動し、図9に示すように［環境を作成］ボタンをクリックします。
   
   図9：Infrastructure Workspaceでの新しい環境の作成
2. 開いた［Create Environment］パネルで、［Name］フィールド（図10では「prod」）に入力し、必要に応じて［Description］フィールドにも入力して、Environmentタイプを選択します（ここでは［Prod］を選択します）。
   
   図10：新しいEnvironmentの命名と最初のAPI Gateway Clusterの割り当て
3. ［API Gateway Clusters］セクションで、［Name］フィールドと［Hostname］フィールドに入力します（図10では、それぞれ「aws-cluster」と「api.nginx.com」です）。
4. Click the［Create］をクリックします。［Environment Created］パネルが開き、各NGINX PlusインスタンスをAPI Gateway Clusterに割り当てるために実行する必要があるコマンドが表示されます。参照しやすいように、これらのコマンドを以下のステップ10に示します。
5. ［Environment］タブに戻り、図11に示すように、［ + Add］セクションの右上にある［API Gateway Clusters］ボタンをクリックします。
   
   図11：Environmentへの別のAPI Gateway Clusterの追加
6. On the Create API Gateway Clusterパネルで、Nameフィールドに2つ目のクラスター名（図12では「gcp-cluster」）を入力し、Hostnameフィールドに1つ目のクラスターと同じホスト名（api.nginx.com）を入力します。
   
   図12：Environmentへの2つ目のAPI Gateway Clusterの追加

図13に示すように、2つのAPI Gateway ClusterがAPI Gateway Clustersに表示されます（Prod環境）。

API GatewayインスタンスをAPI Gateway Clusterに割り当てる

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

1. Use sshを使用してインスタンスに接続し、ログインします。
2. NGINX Agentがすでに実行中の場合は、停止します：

$ systemctl stop nginx-agent

1. 任意のコマンド（curlまたはwget）を実行して、NGINX Agentパッケージをダウンロードし、インストールします：

$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent

1. または

$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent

1. 該当するNGINX Plusインスタンスが、［Instances］セクションに表示されます。このセクションは、［Cluster］ウィンドウのaws‑cluster（図14）とgcp‑cluster（図15）にあります。
   
   図14：複数のクラウドにまたがる環境内にある2つのAPI Gateway Clusterのうち1つ目
   
   図15：複数のクラウドにまたがる環境内にある2つのAPI Gateway Clusterのうち2つ目 グローバルポリシーの適用 API Gateway Cluster内のすべてのNGINX Plusインスタンスに適用されるグローバルポリシーを追加できるようになりました。たとえば、APIへのクライアントアクセスを保護するには、OpenID Connect Relying PartyポリシーまたはTLS Inboundポリシーを適用できます。APIゲートウェイと、APIを公開するバックエンドサービスとの接続を保護するには、TLS Backendポリシーを適用します。TLSポリシーの詳細については、API Connectivity Managerのドキュメントをご覧ください。まとめ マルチクラウドおよびハイブリッドアーキテクチャの管理は容易ではありません。これらは、アプリケーションが急速に変化し、可観測性とセキュリティの確保が難しいことも多い複雑な環境です。しかし、適切なツールを使用すれば、新機能をより迅速に市場へ投入するために必要な俊敏性と柔軟性を維持しながら、ベンダーロックインを回避できます。クラウドネイティブツールであるNGINXのAPI Connectivity Managerは、マルチクラウドおよびハイブリッド環境でAPIを管理するために必要なスケーラビリティ、可視性、ガバナンス、セキュリティを提供します。NGINX Management Suiteの30日間無料トライアルを開始してください。このトライアルでは、API Connectivity Manager、APIゲートウェイとしてのNGINX Plus、およびAPIを保護するNGINX App Protectをご利用いただけます。
   • 「API Connectivity Managerのインストールと設定」でmTLSを有効にしていない場合は、次を追加します。
     • The ‑kフラグをcurlコマンドに追加します
     • The --no-check-certificateフラグ（wgetコマンド用）
   • For <NMS_FQDN>には、NGINX Management SuiteサーバーのIPアドレスまたは完全修飾ドメイン名を指定します。
   • For <cluster_name>には、該当するAPI Gateway Clusterの名前を指定します（このチュートリアルでは、AWSにデプロイされたインスタンスにはaws‑cluster、GCPにデプロイされたインスタンスにはgcp‑clusterを指定します）。

1. ポリシーを適用するAPI Gatewayの［Cluster］タブに移動します（図16の「api-cluster」）。［Manage］ボタンは［Policies］テーブルの右上にあります。このボタンをクリックします。
   
   図16：API Gateway Clusterのポリシー管理
2. 左側のナビゲーション列で［Global Policies］をクリックし、ポリシーの行の右端の列にある［…］アイコンをクリックします（図17では［TLS Backend］）。ドロップダウンメニューから［+ Add Policy］を選択します。
   
   図17：API Gateway Clusterへのグローバルポリシーの追加

著者について

Akash Ananthanarayananテクニカルマーケティングマネージャー | F5 NGINX

Akash Ananthanarayananのその他のブログ記事