マルチクラウドの導入は今後も続きます。F5の 2022年版アプリケーション戦略状況レポートによると、企業の77%が複数のクラウドでアプリケーションを運用しています。マルチクラウドやハイブリッドアーキテクチャを採用すると、効率性の向上、障害リスクの軽減、ベンダーロックインの回避など、重要なメリットが得られます。しかし、このような複雑なアーキテクチャには、独自の課題も存在します。
F5が調査を依頼したソフトウェアおよびITのリーダーたちは、以下に示すものがマルチクラウドの最大の課題であるとしています。
- 可視性（回答者の45%）
- セキュリティ（44%）
- アプリケーションの移行（41%）
- パフォーマンスの最適化（40%）
マルチクラウド環境におけるマイクロサービスのAPI管理は、特に複雑です。API戦略が総合的に確立されていないと、Platform Ops（プラットフォーム運用）チームがAPIを保護・管理するよりも、パブリッククラウド、オンプレミス、エッジ環境全体にAPIが早期に拡散されてしまいます。F５ではこの問題を「APIスプロール」と呼んでおり、以前の記事では、それが重大な脅威である理由を説明しています。
複数のクラウドに分散しているマイクロサービスを統合し、エンドツーエンドの接続を実現するための考え抜かれたアプローチを実装するには、マルチクラウドAPI戦略が必要です。マルチクラウドとハイブリッド導入の一般的なシナリオには、以下の2つがあります。
- マルチクラウド／ハイブリッド環境における異なるサービス – コスト削減あるいはユーザーグループごとに異なるサービスを提供するには、異なる場所で異なるアプリケーションやAPIを運用する必要があります。
- マルチクラウド／ハイブリッド環境における同一サービス – 異なる場所に導入された同一アプリケーションの高可用性を確保する必要があります。
次のチュートリアルでは ステップバイステップで、F5 NGINX Management Suiteの一部であるAPI Connectivity Managerを2つ目のシナリオ（高可用性の実現に向けて、複数の環境に同一のサービスを導入する）で使用する方法を説明します。この方法により、マルチクラウドやハイブリッド運用環境における単一の障害点が排除されます。1つのゲートウェイインスタンスに障害が発生した場合、別のゲートウェイインスタンスが引き継ぎ、1つのクラウドがダウンしても、顧客は停止を経験することはありません。
API Connectivity Managerは、APIを導入、管理、および保護するための、クラウドネイティブでランタイムに依存しないソリューションです。パブリッククラウド、オンプレミス、エッジ環境に導入されたNGINX Plus APIゲートウェイ、そして開発者ポータルのすべてのAPI操作を1つの画面で管理できます。これにより、Platform OpsチームはAPIトラフィックを完全に可視化でき、すべての環境に一貫したガバナンスポリシーとセキュリティポリシーを簡単に適用できます。
マルチクラウド導入におけるAPIゲートウェイの高可用性の実現
冒頭で述べたように、このチュートリアルでは、複数の導入環境で動作するサービスの高可用性を実現するために、API Connectivity Managerを設定します。具体的には、NGINX PlusをAPIゲートウェイとして導入し、サービスAとサービスBの2つのサービスにトラフィックをルーティングします。これらは、Google Cloud Platform（GCP）とAmazon Web Services（AWS）という2つのパブリッククラウドで実行されています。（このセットアップは、Microsoft Azureやオンプレミスデータセンターを含む、あらゆる導入環境にも同様に適用できます）。
図1は、チュートリアルで使用するトポロジーを示しています。
これらのセクションの手順に従って、チュートリアルを完了します。
- API Connectivity Managerのインストールと設定
- APIのゲートウェイとしてのNGINX Plusインスタンスの導入
- インフラストラクチャワークスペースのセットアップ
- 環境とAPIゲートウェイクラスタの作成
- グローバルポリシーの適用
API Connectivity Managerのインストールと設定
- NGINX Management Suiteのトライアル版または有料サブスクリプションをご利用ください。これには、Instance ManagerとAPI Connectivity Managerに加え、APIゲートウェイとしてのNGINX Plus、そしてAPIを保護するNGINX App Protectが含まれています。まずは、 NGINX Management Suiteの30日間無償のトライアル版をお試しください。
- NGINX Management Suiteをインストールします。「Install Management Suite Modules（Management Suiteのモジュールのインストール）」セクションでは、API Connectivity Manager (およびオプションで他のモジュール) の指示に従います。
- インストールしたモジュールごとにライセンスを追加します。
- （オプションで）TLSターミネーションと mTLSをセットアップして、NGINX Management Suiteへのクライアント接続と、データ プレーン上のAPI Connectivity ManagerとNGINX Plusインスタンス間のトラフィックをそれぞれ保護します。
APIのゲートウェイとしてのNGINX Plusインスタンスの導入
マルチクラウドまたはハイブリッド インフラストラクチャを構成する環境を選択します。このチュートリアルでは、AWSとGCPを選択し、各クラウドに1つのNGINX Plusインスタンスをインストールしています。 それぞれの環境で、APIゲートウェイとして機能する各データプレーンホストで次の手順を実行します。
- サポートされているオペレーティングシステムにNGINX Plusをインストールします。
- NGINX JavaScriptモジュール（njs）をインストールします。
-
/etc/nginx/nginx.confのメイン（トップレベル）コンテキストに以下のディレクティブを追加します。
load_module modules/ngx_http_js_module.so; load_module modules/ngx_stream_js_module.so; -
以下に示すコマンドを実行するなどして、NGINX Plusを再起動します。
$ nginx -s reload
インフラストラクチャワークスペースのセットアップ
API Connectivity Managerでは、複数のインフラストラクチャのワークスペース（執筆時点では最大10個）が作成できます。ワークスペースを分離することで、さまざまな事業部門、開発者チーム、外部パートナー、クラウドなどに固有のポリシーと認証／承認要件を適用できます。
API Connectivity ManagerのGUIで作業し、新しいWorkspaceを以下のように作成します。
- 左側ナビゲーション列の「Infrastructure（インフラストラクチャ）」をクリックします。
-
「 + Create （+ 作成）」 ボタンをクリックして、図２が示すように新しいワークスペースを作成します。
図2：インフラストラクチャワークスペースの新規作成 -
「Create Workspace（ワークスペースの作成）」パネルの「Name（名前）」フィールドに入力します（図3ではdemo）。オプションで、「Description（説明）」 フィールドと「Workspace Contact Information（ワークスペースの連絡先情報）」セクションの各フィールドを入力します。インフラストラクチャ管理者（たとえば、Platform Opsチーム）は、この連絡先情報を使用して、ワークスペースのユーザにステータスまたは問題に関する最新情報を提供します。
図3：新しいインフラストラクチャーワークスペースに名前を付け、連絡先情報を追加する - 「 Create （作成）」ボタンをクリックします。
環境とAPIゲートウェイクラスタの作成
API Connectivity Managerでは、環境は専用のリソース（APIゲートウェイやAPI開発者ポータルなど）を論理的にグループ化したものです。ワークスペースごとに複数の環境を作成することが可能です (執筆時点では最大25個)。これらは通常、コーディング、テスト、本番など、アプリの開発と導入のさまざまな段階に対応しますが、必要などのような目的にも使用できます。
環境内では、APIゲートウェイクラスタはAPIゲートウェイとして動作するNGINX Plusインスタンスの論理的なグループです。1つのEnvironmentに、同じホスト名を共有する複数のAPIゲートウェイクラスタを持つことができます（たとえば、このチュートリアルではapi.nginx.com）。APIゲートウェイクラスタ内のNGINX Plusインスタンスは、複数の種類のインフラストラクチャ（複数のクラウドなど）に配置できます。
API Connectivity Managerでは、APIゲートウェイのアクティブな高可用性を実現するために、環境を設定する2つの方法があります。
複数のAPIゲートウェイクラスタを導入する主な理由は、各クラスタに異なるセキュリティポリシーを適用できるようにするためです。
「Deploy NGINX Plus Instances as API Gateways（APIゲートウェイとしてNGINX Plusインスタンスを導入する）」では、AWSに1つ、GCPにもう1つ、つまり2つの NGINX Plusインスタンスを導入しました。このチュートリアルでは、同じインスタンスを使用して両方の環境タイプ（1つのAPIゲートウェイクラスタAPIまたは複数のAPIゲートウェイクラスタ）を説明します。1つのワークスペースに両方の環境タイプを導入する場合は、2つ目の環境に対して追加のNGINX Plusインスタンスを作成する必要があります。
1つのAPIゲートウェイクラスタによる環境の導入
図4が示すように、1つのAPIゲートウェイクラスタが存在する環境の場合、すべてのNGINX Plus APIゲートウェイのインスタンスには同一のセキュリティポリシーが適用されます。
環境とAPIゲートウェイクラスタの作成
-
ワークスペースに移動し、図5が示すように「 Create Environment （環境の作成）」ボタンをクリックします。
図5：インフラストラクチャーワークスペースでの環境の新規作成 -
「Create Environment（環境の作成）」パネルが表示されたら、「Name（名前）」フィールド（図6では「prod」）を入力し、オプションで「Description（説明）」フィールドを作成し、環境の種類（ここではProd）を選択します。
図6：新しい環境に名前を付け、APIゲートウェイクラスタをそれに割り当てる - 「API Gateway Clusters（APIゲートウェイクラスタ）」セクションでは、「Name（名前）」フィールドと「Hostname（ホスト名）」のフィールド（図6ではapi-clusterとapi.nginx.com）を入力します。
-
「 Create （作成）」ボタンをクリックします。
「Environment Created（作成済み環境）」パネルが開き、それぞれのNGINX Plusインスタンスで実行してAPIゲートウェイクラスタに割り当てる必要があるコマンドが表示されます。便宜上、以下の「手順7」にはコマンドを示します。
APIゲートウェイインスタンスのAPIゲートウェイクラスタへの割り当て
それぞれのNGINX Plusのインスタンスを以下のように繰り返します
sshを使用してインスタンスに接続し、ログインします。-
NGINX Agentすでに起動している場合は、以下に示すように停止します。
$ systemctl stop nginx-agent -
選択したコマンド（
curlまたはwget）を実行して、NGINX Agentパッケージをダウンロードしてインストールします。-
「Install and Configure API Connectivity Manager（API Connectivity Managerのインストールと設定）」でmTLSを有効にしなかった場合は、以下を追加します。
curlコマンドには‑kフラグwgetコマンドには--no-check-certificateフラグ
<NMS_FQDN>の場合、 NGINX Management SuiteサーバーのIPアドレスまたは完全修飾ドメイン名に置き換えます。<cluster_name>の場合、APIゲートウェイクラスタの名前（このチュートリアルではapi-cluster）に置き換えます。
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agentまたは
$ 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図7が示すように、NGINX Plusインスタンスは、api-clusterの「Cluster（クラスタ）」ウィンドウの「Instances（インスタンス）」セクションに表示されます。
図7：1つのAPIAPIゲートウェイクラスタは、複数のクラウドに導入されているNGINX Plusインスタンスをグループ化する -
- 「Apply Global Policies（グローバルポリシーの適用）」に進みます。
複数のAPIゲートウェイクラスタによる環境の導入
複数のAPIゲートウェイクラスタが存在する環境では、図8が示すように、異なるセキュリティポリシーを異なるNGINX Plus APIゲートウェイインスタンスに適用できます。
異なるセキュリティポリシーが適用できる
環境とAPIゲートウェイクラスタの作成
-
図9が示すように、ワークスペースに移動し、「 Create Environment （環境の作成）」ボタンをクリックします。
図9：インフラストラクチャワークスペースにおける環境の新規作成 -
表示される「Create Environment（環境の作成）」パネルで、「Name（名前）」フィールドに入力し（図10ではprod ）、オプションで、「Description（説明）」フィールドni入力し、環境の種類（ここでは、 Prod）を選択します。
図10：新しい環境に名前を付け、最初のAPIゲートウェイクラスタを割り当てる - 「API Gateway Clusters（APIゲートウェイクラスタ）」 セクションで、「Name（名前）」フィールドと「Hostname（ホスト名）」フィールド（図10では、それぞれaws-clusterとapi.nginx.com）ni入力します。
-
「 Create （作成）」ボタンをクリックします。
「Environment Created（作成された環境）」パネルが開き、APIゲートウェイクラスタを割り当てるために各NGINX Plusインスタンスで実行する必要があるコマンドが表示されます。便宜上、以下の手順10にコマンドを示します。
-
図11が示すように、「Environment（環境）」タブに戻り、「API Gateway Clusters（APIゲートウェイクラスタ）」セクション右上隅の「 + Add （+追加）」ボタンをクリックします。
図 11： 別のAPIゲートウェイクラスタの環境への追加 -
「Create API Gateway Cluster（APIゲートウェイクラスタの作成）」パネルの「Name（名前）」フィールドに２つ目のクラスタ名（図12ではgcp-cluster）を入力し、「Hostname（ホスト名）」 フィールドに1つ目のクラスタと同じホスト名（api.nginx.com）を入力します。
図12：2つ目のAPIゲートウェイクラスタを環境に追加する
図13が示すように、2つのAPIゲートウェイクラスタがProd環境のAPI Gateway Clustersに表示されます。
APIゲートウェイインスタンスのAPIゲートウェイクラスタへの割り当て
それぞれのNGINX Plusのインスタンスを以下のように繰り返します
sshを使用してインスタンスに接続し、ログインします。-
NGINX Agentがすでに起動している場合は、以下に示すように停止します。
$ systemctl stop nginx-agent -
選択したコマンド（
curlまたはwget）を実行して、NGINX Agentパッケージをダウンロードしてインストールします。-
「Install and Configure API Connectivity Manager（API Connectivity Managerのインストールと設定）」でmTLSを有効にしなかった場合は、以下を追加します。
curlコマンドには‑kフラグwgetコマンドには--no-check-certificateフラグ
<NMS_FQDN>の場合、 NGINX Management SuiteサーバーのIPアドレスまたは完全修飾ドメイン名に置き換えます。<cluster_name>の場合、適切なAPIゲートウェイクラスタの名前（このチュートリアルでは、AWSに導入されたインスタンスのaws‑clusterとGCPに導入されたインスタンスのgcp‑cluster）に置き換えます。
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agentまたは
$ 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適切なNGINX Plusインスタンスがaws‑cluster（図14参照）とgcp‑cluster（図15参照）の「Cluster（クラスタ）」ウィンドウの「Instances（インスタンス） 」セクションに表示されます。
図14：複数のクラウドにまたがる環境における2つのAPIゲートウェイクラスタのうち、1つ目のクラスタ 
図15：複数のクラウドにまたがる環境における2つのAPIゲートウェイクラスタのうち、2つ目のクラスタ グローバルポリシーの適用
現在、APIゲートウェイクラスタのすべてのNGINX Plusインスタンスに適用されるグローバルポリシーを追加できます。たとえば、APIへのクライアントアクセスを保護するには、OpenID Connect Relying PartyポリシーまたはTLS Inboundポリシーを適用できます。APIゲートウェイと、APIを公開するバックエンドサービスとの間の接続を保護するには、TLS Backendポリシーを適用します。TLSポリシーの詳細については、API Connectivity Managerのドキュメントをご覧ください。
-
ポリシーを適用するAPIゲートウェイの 「Cluster（クラスタ）」（図16ではapi-cluster）タブに移動します。 「Policies（ポリシー）」テーブル右隅上の「Manage（管理）」ボタンをクリックします。
図16：APIゲートウェイクラスタのポリシー管理 -
左側のナビゲーション列の「Global Policies（グローバルポリシー）」をクリックし、その後、 ポリシー（図17ではTLS Backend（TLSバックエンド））の行右端列の「…」アイコンをクリックします。ドロップダウンリストのメニューから「+ Add Policy（+ ポリシーの追加）」を選択します。
図17：APIゲートウェイクラスタへのグローバルポリシーの追加
結論
マルチクラウドおよびハイブリッドアーキテクチャの管理は簡単ではありません。それらは、アプリケーションが急速に変化する複雑な環境であり、多くの場合、監視や保護は困難です。
ただし、適切なツールを使用すると、新しい機能をより迅速に市場に投入するために必要な機敏性と柔軟性を維持しながら、ベンダーロックインを回避することが可能です。クラウドネイティブツールとして、NGINXのAPI Connectivity Managerは、マルチクラウドおよびハイブリッド環境でAPIを管理するために必要なスケーラビリティ、可視性、ガバナンス、およびセキュリティを提供します。
まずは、NGINX Management Suiteの30日間無料トライアルをお試しください。これには、API Connectivity Manager、APIゲートウェイとしてのNGINX Plus、そしてAPIを保護するNGINX App Protectが含まれています。
-
