ハイブリッドおよびマルチクラウドAPI管理：課題と選択肢
February 6, 2023
1. マルチクラウドとハイブリッドクラウド
マイクロサービスは、組織が自社のビジネスを理解し、ドメイン駆動設計などの科学的な手法を用いて、製品を個々のマイクロサービスに分解する人気のあるソフトウェアアーキテクチャ手法となっています。組織構造も、Conwayの法則に従ってマイクロサービスアーキテクチャに合わせて調整され、ビジネスの反復的な開発をサポートします。
過去には、組織は自社の製品を展開するために独自のデータセンターを構築していました。これらのデータセンターは、賃貸または購入した施設に設置され、組織はスイッチ、サーバー、ストレージ、ラックなどの複雑なインフラストラクチャを管理する責任を負っていました。また、停電、ラックの高温、サーバーのクラッシュなどによる問題にも対処する必要がありました。このような問題に対処するには、多くの人的・財政的リソースが必要でありながら、良い結果を得ることが難しい場合が多く、組織の自社製品のSLA（サービスレベル契約）が顧客への約束を満たせず、補償が発生することもありました。
クラウドの台頭により、人々はビジネスをパブリッククラウドに展開することにますます慣れてきました。 パブリッククラウドは、ユーザーがハードウェアインフラストラクチャの詳細を抽象化するのを助け、エンジニアがビジネスの展開、維持、開発に集中できるようにします。しかし、クラウドが提供する利便性に加えて、その台頭と使用はユーザーにとって他の問題も引き起こします：
- ロックイン: クラウドプロバイダーの製品がビジネスに深く統合されると、そのビジネスを別のクラウドに移行したり、クラウドから完全に離脱したりすることが非常に困難になります。これは特に、ビジネスと強く結びついているPaaSやSaaS製品でよく見られます。残念ながら、これはビジネスが急速に成長している時期に起こることが多く、意思決定者がクラウド製品の使用による結びつき効果を見落とすことが原因です。
- 可用性の問題: 分散の原則がここに適用されます。つまり、すべての卵を1つのバスケットに入れないということです。ビジネスの拡大フェーズでは、組織は製品を迅速にリリースし、市場シェアを獲得することに優先順位を置き、インフラストラクチャを軽視することがあります。これにより、クラウドリージョンでの停電やケーブル切断が発生し、ビジネスに悪影響を及ぼす可能性があります。
その結果、人々は前述の問題を回避するために、複数のパブリッククラウドを使用したり、パブリッククラウドに加えてプライベートクラウドを構築したりすることにますます慣れてきています。このアプローチは一般的に「マルチクラウド」と「ハイブリッドクラウド」と呼ばれます。
「マルチクラウド」とは、複数のパブリッククラウドを同時に使用し、これらのクラウド上にビジネスをミラーリングまたは異種展開することを指します。可能な限り標準的なサービスを使用します（ベンダーロックインを避けるため）。マルチクラウドを使用することで、1つのクラウドが利用不能になった場合でも、ビジネスへの影響を最小限に抑え、DNS解決を変更してバックアップクラウドを有効にすることでビジネスの継続性を確保できます。
「ハイブリッドクラウド」とは、1つ以上のパブリッククラウドを使用するだけでなく、組織が独自のプライベートクラウド（またはデータセンター）も持っていることを指します。このシナリオでは、一部のサービスはプライベートクラウドに展開され、他のサービスはパブリッククラウドに展開される場合があります。または、すべてのサービスがクラウドに展開され、プライベートクラウドが管理と監視を担当する場合もあります。いずれにせよ、「マルチクラウド」または「ハイブリッドクラウド」モデルを採用した後、ソフトウェア展開の柔軟性と可用性は大幅に向上します。
しかし、「マルチクラウド」と「ハイブリッドクラウド」戦略を実施すると、クラウドベースのマイクロサービスの管理がより複雑になる可能性があります。一般的な課題の1つはAPI管理です。多くのマイクロサービスは通信にAPIを依存しているため、マイクロサービスを展開する際には、それらのAPIを外部に公開して外部との接続を許可し、サービスを提供する必要があります。
2. マルチクラウドとハイブリッドクラウドシナリオにおけるAPI管理の必要性
ご存知の通り、優れたAPIゲートウェイはマイクロサービスAPIを管理するために重要です。APIゲートウェイは、マイクロサービスAPIを安全かつ効率的に公開することを可能にします。しかし、「マルチクラウド」と「ハイブリッドクラウド」戦略を実施する場合、APIゲートウェイの必要性はその基本的な機能を超えます。具体的には、以下のような考慮事項があります：
マルチクラスタ管理をサポートするかどうか
前述のように、「マルチクラウド」または「ハイブリッドクラウド」戦略を実施する場合、各クラウドまたはプライベートデータセンターに展開されるサービスは大きく異なる場合があります。その結果、ユーザーは各クラウドに異なる設定、証明書、APIキーを持つ別々のAPIゲートウェイクラスタを展開する必要があるかもしれません。選択したゲートウェイがマルチクラスタ管理をサポートしていない場合、特にビジネス拡大期にゲートウェイクラスタの数と規模が増加する際に、APIの管理に大きな困難が生じる可能性があります。
このような場合、マルチクラスタ管理をサポートするAPIゲートウェイ製品は、管理者の管理コストを大幅に削減できます。
- ユーザーは、設定および監視したいクラスタを選択できる統一されたコンソールにアクセスできます。また、現在のビジネス展開状況に応じてゲートウェイクラスタをオンラインまたはオフラインにすることもできます。
- ユーザーは、コンソール上でこれらのAPIゲートウェイクラスタの実行ステータスを確認できます。これには、一般的なQPS、レイテンシ、ゲートウェイクラスタのCPUおよびメモリ使用率などが含まれます。
コラボレーションをサポートするかどうか
ビジネスの急速な発展に伴い、少数のAPIゲートウェイ管理者がすべてのAPIゲートウェイクラスタを単独で管理および維持するのは困難になる場合があります。一方、多くのゲートウェイ設定（ルートの追加やプラグインの設定など）は開発者が処理できるため、管理者の関与を大幅に減らすことができます。そのため、「コラボレーション」をサポートするかどうかが管理にとって重要になります。
具体的には、管理者はRBAC（ロールベースのアクセス制御）または他の戦略を使用して、組織の他のメンバーをAPIゲートウェイクラスタの管理に招待し、チームメンバーに異なる権限を割り当てることができます。例えば、管理者にはOrganization Admin（任意の操作を実行可能）の役割を設定し、一般的な開発者にはService Admin（いくつかのサービスとルートのみを維持可能）の役割を設定します。このアプローチにより、操作の安全性を確保しながらコラボレーションを実現します。また、従業員の離職や職位の変更が発生した場合に、アカウントの回復や権限の変更を迅速に行うことが容易になります。
任意のインフラストラクチャで実行できるかどうか
コンテナ化とコンテナオーケストレーション技術が成熟するにつれ、多くのマイクロサービスが仮想マシンからKubernetes上で実行されるようになっています。これは、ユーザーがKubernetes、従来の仮想マシン、またはプライベートデータセンター内の物理マシンを使用する可能性があることを意味します。ユーザーが選択したAPIゲートウェイ製品が機能豊富でビジネスニーズを満たしているが、基盤となるインフラストラクチャに制限がある場合や、成熟したインストールツールがない場合、ユーザーにとって課題となる可能性があります。その場合、そのAPIゲートウェイを使用することを諦めるか、特定のインフラストラクチャ上で実行できるように追加の開発を行う必要があります。いずれにせよ、これにより追加の使用コストが発生します。
3. 決定
前述のように、「マルチクラウド」と「ハイブリッドクラウド」シナリオにおいて、適切なAPIゲートウェイを選択することが極めて重要になります。以下にいくつかの一般的なオプションをリストアップし、ユーザーは実際のシナリオと将来の計画に基づいてそれらを分析する必要があります。
異なるクラウド上の異なるソリューション
通常、各パブリッククラウドプロバイダーは独自の組み込みAPIゲートウェイソリューションを提供しており、ユーザーは各クラウド用のAPIゲートウェイソリューションを購入することを検討できます。
利点は以下の通りです：
- 使用コストが非常に低く、展開やメンテナンスが不要です。
- 通常、従量課金制をサポートしており、初期使用時には最小限のコストしかかかりません。
欠点は以下の通りです：
- 異なるクラウド上のAPIゲートウェイの使用は互換性がないことが多く、同じ設定を完了するために異なる手順が必要です。
- 製品の機能はプロバイダー間で対称的ではありません。例えば、あるプロバイダーはmTLSをサポートしているが、別のプロバイダーはサポートしていない場合があります。
- 「ハイブリッドクラウド」シナリオでは、別のオープンソースまたは商用APIゲートウェイを選択し、ユーザーのプライベートクラウドに展開する必要があるかもしれません。
このアプローチを使用する場合、異なるクラウドプロバイダー間で一貫したユーザーエクスペリエンスを実現するには、製品のカスタマイズ、設定同期ツールの開発、基盤となる詳細の抽象化が必要になる場合があります。これには、ユーザー側での追加の調査、分析、開発が必要になる可能性があります。ユーザーは互換性の問題や機能の制限に直面し、APIゲートウェイ製品のいくつかの共通機能しか使用できない場合があります。また、同期失敗の可能性も考慮する必要があります。
もちろん、ユーザーは各クラウド上の各APIゲートウェイの設定を手動で繰り返すこともできます（それが許容できる場合）。
オープンソースAPIゲートウェイソリューション
異なるクラウド上の異なるソリューションを使用する代わりに、ユーザーはApache APISIX、Kong、Tyk、TraefikなどのオープンソースAPIゲートウェイソリューションを使用することを検討できます。このアプローチにより、ユーザーはすべてのクラウド（プライベートデータセンターを含む）で同じAPIゲートウェイを使用できるため、異なるソリューション間の互換性問題を回避できます。成熟した堅牢なオープンソースAPIゲートウェイは、ユーザーがさまざまなシナリオで多くの問題を解決するのに役立ちます。すべてのシナリオをカバーできない場合でも、これらのAPIゲートウェイは通常、ユーザーがさまざまな方法で拡張できるようにしています。例えば、Apache APISIXは、Go、Java、Python、Lua、WASMなどの言語や技術を使用して拡張することを許可しています。
しかし、これらのオープンソースAPIゲートウェイは通常、Open Coreオープンソース戦略を採用しており、製品のコア機能はオープンソースですが、視覚化されたコンソール、マルチクラスタ管理、監査、SSO（シングルサインオン）などのエンタープライズレベルの管理機能は有料（商用製品に統合されている）であることが多いです。ユーザーがそれらを支払いたくない場合、これらのAPIゲートウェイを管理するための独自の管理プラットフォーム（ゲートウェイのコントロールプレーンとも呼ばれる）を開発するしかありません。つまり、ユーザーはこの開発作業を担当する専任のエンジニアを雇う必要があります。
エンタープライズレベルのAPIゲートウェイSaaSサービスを購入する
オープンソースAPIゲートウェイが機能面で要件を満たしているが、自己研究コントロールのコストが許容できない場合、ユーザーはこれらのオープンソースソフトウェアのオリジナルメーカー（Apache APISIXの背後にあるAPI7.ai、Kongの背後にあるKong Inc、Tykの背後にあるTyk Incなど）に連絡することも検討できます。これらのメーカーは、さまざまなエンタープライズレベルのAPIゲートウェイ製品とサポートサービスを提供しています。特に「マルチクラウド」と「ハイブリッドクラウド」シナリオでは、これらのメーカーは次々にSaaS製品をリリースしています。APIゲートウェイのSaaS製品は、管理側に焦点を当てており、すぐに使用できるコンソールを提供し、APIゲートウェイインスタンスがどこに展開されているかを心配する必要はありません（もちろん、一部のSaaSサービスはAPIゲートウェイインスタンスのホスティングもサポートしていますが、これによりAPIをプロキシする際の遅延などの他の問題が発生する可能性があります）。
SaaSサービスは通常、各テナントにプライベートゲートウェイコントロールパネルを提供し、mTLSなどの戦略を使用してユーザーが展開した（またはSaaSがホストした）ゲートウェイインスタンスに接続し、データのセキュリティとプライバシーを確保し、管理機能を提供します。SaaSサービスを購入するには投資が必要ですが、APIゲートウェイとそのコントロールパネルを維持するための専任エンジニアを雇うよりもコスト効果が高い場合があります。
もちろん、SaaSサービスを購入する際には注意が必要です。そのため、注文を確定する前に、ユーザーは以下の観点からSaaSサービスを評価する必要があります：
- このSaaSサービスは現在および将来の使用ニーズを満たすことができるか？
- このSaaSサービスプロバイダーは専門的で信頼できるか？どのようなユースケースを持っているか？
- このSaaSサービスは準拠しており、GDPRに準拠し、SOC2監査報告書を持っているか？
- このSaaSサービスには明確なSLA条項があるか？
- このSaaSサービスはどのように課金されるか？ユーザーは1年または数年後の将来の支出を見積もることができるか？
完全に自己開発する
オープンソースAPIゲートウェイソリューションがユーザーの実際のニーズを満たしていない場合、ユーザーは独自の専用APIゲートウェイ製品を開発することを検討するかもしれません。これは時間とリソースを要し、ゲートウェイの安定性も大きな懸念事項です。APIゲートウェイの開発は、リレーショナルデータベースやブラウザの実装ほど難しくはありませんが、一夜にしてできるものではありません。そのため、自己開発は「最悪の戦略」と見なすことができます。その結果、これはしばしば最後の手段としてのみ検討されます。
4. 結論
クラウドネイティブ環境では、「マルチクラウド」と「ハイブリッドクラウド」シナリオにおけるAPIの管理は、これらの戦略を採用する前でさえ、すべての組織にとって課題となります。したがって、この記事ではさまざまなオプションを提示していますが、万能の解決策はないことを念頭に置き、ユーザーは特定のビジネスニーズと開発目標に最も適したオプションを選択する必要があります。