Red Hat 3scale API ManagementでAPI利用者向けにAPIをパッケージ化する方法

Red Hatでソリューションアーキテクトをしている杉本です。

モバイルアプリとバックエンドシステムあるいはマイクロサービスを連携するためのテクノロジーとしてAPIを利用されている企業は多いかと思います。もちろんAPIはそういった用途で使われるものでもありますが、APIの価値はそれにとどまりません。イノベーションの促進、生産性の向上、顧客体験の向上など、APIからビジネス的な価値を抽出するには、APIがどのように利用されるのか、その利用シナリオを設計しておくことが必要となってきます。そのためにはAPIの提供者はAPIを提供していくためのプランを考えておくことも重要です。

この記事は Red Hat Developer Blog の Packaging APIs for consumers with Red Hat 3scale API Management の日本語訳したもので、Red HatのAPI管理製品である 3scale API Management (Red Hat Integrationに含まれます) を使ってAPIの提供プランを設計していくための方法について解説しています。


API管理プラットフォームの主な機能の1つとして、APIのエンドポイントの保護、ビジネス観点での流量制御、価格設定のルールなどに関するポリシーを定義、適用することがあげられます。場合によっては、APIプロバイダーは、同じAPIであっても異なるユーザセグメントに応じた形で、APIを利用できるようにすることが必要になってきます。この記事では、Red Hat 3scale API Management を使用して、社内外の開発者やパートナー企業など、様々なAPIの利用者に応じて API をパッケージ化する方法について説明します。この記事の最後では 3scale API Management の使い方に関するビデオチュートリアルも紹介しており、この記事で紹介する API パッケージの作成および構成方法を学ぶことができます。

Red Hat 3scale API Management について

3scale API Managementはスケーラブルでハイブリッドクラウドに対応したAPI管理の仕組みで、Red Hat Integration という製品ポートフォリオの一部となっています。図1は、3scale API Management の概要図です。

f:id:tsugimot:20210629170814p:plain
図1: 3scale API Management の概要図

API Manager は、3scale におけるコントロールプレーンです。API Managerは、APIプロバイダーがユーザ、アカウント、ポリシー、サービスを作成するためのインタフェースを提供しています。API Gateway (APIcast)は、データプレーンとしてAPIに対してポリシーを適用します。

APIアクセスに関するポリシー

3scale API Management を使用することで、同じ API に対して異なるポリシーが適用されるようにAPIコンシューマーのセグメントを作成することができます。例えば、1つのAPIエンドポイントを、社内の開発者 (Internal developers)、社外の開発者 (External developers)、パートナー企業 (Strategic partners)という3つの異なるAPIコンシューマーに公開する必要があるとします。表1は、対象となるAPIコンシューマーごとに作成できるパッケージの例を示しています。

表 1: 3種類のAPIコンシューマーに応じた基本的なアプリケーションプラン

パッケージ 流量制御 価格設定ルール フィーチャー (Features)
Internal developers None Free Internal
External developers 10 calls per minute $0.01 per call Basic
Strategic partners 1 million calls per day $100 per month Premium

注:社内の開発者の場合、流量制御は「なし」に設定されていますが、DDoS(Distributed Denial of Service)攻撃を防ぐためには、高いレート制限を設定したほうがよいでしょう。また、パートナー企業の流量制御は1日単位で表示されていますが、1分単位で設定した方がよい場合もあります。そうすることで短時間で大きな負荷がシステムにかかることを防ぐことができます。

図2は表1に従ってAPIをパッケージ化したものを示しています。

f:id:tsugimot:20210629171934p:plain
図2: 社内の開発者、社外の開発者、パートナー企業ごとのAPIをパッケージ化

図2にある流量制御のポリシーにより、APIの呼び出し回数に上限を設けることができます。流量制御はAPIエンドポイントとなるメソッドごとに定義されるので、同一パッケージに含まれるAPIのメソッドごとに異なる制御を適用することが可能になります。また、価格設定のルールを使用することで、APIの呼び出し回数を計測し、それに応じて課金をすることができます。価格設定のルールはAPIメソッドごとに定義され、同一パッケージに含まれるAPIメソッドごとに異なる価格設定のルールを適用することが可能になります。最後に、フィーチャー (Features) ポリシーでは、各パッケージに複数のフィーチャー (Features)を定義することができます。これにより各パッケージにメタデータのタグが追加され、利用可能なフィーチャー (Features)を一意に識別してマッピングできるようになります。

3scale API Managementのパッケージングの考え方は一般的なもので、ほとんどのAPI管理プラットフォームが同様のものをサポートしています。以下のセクションでは、3scale API Managementが提供する様々な種類のプランについて見ていきます。

アプリケーションプラン

アプリケーションプランは、APIを利用するためのルール(流量制御、価格、フィーチャー (Features))を定めたものになります。APIに対するアプリケーションからのリクエストはすべてにおいて、アプリケーションプランの制約が適用されます。3scale API Managementで管理されるAPIはすべて、少なくとも1つのアプリケーションプランに紐づけられます。また、同一のAPIを、異なるユーザーグループを対象として複数のプランを定義することも一般的に行われています。図3は、APIとアプリケーションプラン、対象となるAPI利用者 (Audience)、ポリシーとの関係を示しています。

f:id:tsugimot:20210629172111p:plain
図 3: 1つのAPIに対して複数のアプリケーションプランを定義し、異なるユーザ層に応じて異なるポリシーを適用

APIを呼び出す各アプリケーションは、1つのアプリケーションプランに一意にマッピングされます。アプリケーションからAPIにリクエストが送信されると、3scale API Managementはそのアプリケーションに対して流量制御と価格設定ルールを適用し、APIの使用統計情報を更新します。アプリケーションプランは、3scale API Managementで適用することのできる最も細かい粒度の制御になります。APIごとに1つ以上のアプリケーションプランを使用すれば、APIをパッケージングする上で出てくる要件はほとんど満たすことができます。

アプリケーションプラン以外のプラン

場合によっては、APIや開発者アカウント用に複数のアプリケーションプランのポリシーを定義するために特別なプランを使用する必要があります。デフォルトのプランはすべてのAPIプロバイダーが利用できますが、特別なプランはサービス、アプリケーション、アカウント間の複雑な関係を定義するものであり、明示的に有効にする必要があります。1つまたは複数の特別なプランを使用するかどうかはAPIの設計フェーズの段階で検討すべきであり、予期せぬ結果を避けるためにもその詳細はドキュメント化しておくべきでしょう。次のセクションでは、特別なプランとしてサービスプランとアカウントプランについて紹介します。

訳注:サービスプランとアカウントプランのメニューを有効にするには、3scale の管理コンソールで Audience メニューを選択し、Settings > Usage Rulesを選択した時に表示される ADVANCED PLANS のセクションで、Account Plans と Service Plans のチェックボックスにチェックを入れます。

サービスプラン

API利用者がAPIプロダクト (サービス) にサブスクライブして利用の登録をする際に、サービスプランを使用することができます。3scale API ManagementではAPIプロダクトへのサブスクリプションはデフォルトで有効になっており、各サービスへのサブスクリプションでは1つのサービスプランのみが有効になります。サービスプランを利用すると、そのプランの下でサービスを利用するすべてのアプリケーションに対してサービス全体に関わるフィーチャー (Features) とプランを提供することができるようになります。

例えば表2に記載されているサービスプランでは、前節で定義したアプリケーションプランに新しいフィーチャー (Features) が追加されています。

表2: 3つのベースとなるアプリケーションプランに新規フィーチャー (Features) を追加

パッケージ 流量制御 価格設定ルール フィーチャー (Features)
Internal developers None Free Internal, developers
External developers 10 calls per minute $0.01 per call Basic, developers
Strategic partners 1 million calls per day $100 per month Premium, partners

アプリケーションプランごとに個別にフィーチャー (Features) を設定していくことも可能ではありますが、それよりはサービスプランで「デフォルト」のフィーチャー (Features) を定義し、アプリケーションプランでは必要に応じてアプリケーションプランで定義したフィーチャー (Features) を有効にする方がよいでしょう。

表3の例はより複雑なシナリオになりますが、APIプロバイダーがパートナー企業向けに2つ以上のアプリケーションプランを提供する必要がある場合の例になります。

表3: 複数のアプリケーションプラン

パッケージ 流量制御 価格設定ルール フィーチャー (Features)
Strategic Partners Bronze Plan 100,000 calls per day $30 per month Premium, partners, bronze, developers
Strategic Partners Silver Plan 500,000 calls per day $60 per month Premium, partners, silver, testing
Strategic Partners Gold Plan 1 million calls per day $100 per month Premium, partners, gold, production

このアプリケーションプランの設定例では、1つのパートナーアカウントが複数のプランにサインアップできるようにAPIプロバイダーがプランを設定していることになります。例えば、あるパートナー企業は、開発中のアプリケーションにはブロンズプランを利用し、QA段階のアプリケーションにはシルバープランを利用し、そして本番用のアプリケーションにはゴールドプランを利用することができるようになります。そのパートナー企業に対してすべてのアプリケーションプランで標準となる価格を提供するために、表4に示すようなサービスプランを利用することが可能です。

表 4: サービスプラン

パッケージ 流量制御 価格設定ルール フィーチャー (Features)
Strategic Partners Premium Plan $50 $100 per month Premium, partners, customers

図4は、サービスプランとアプリケーションプランを併用する典型的なシナリオを示しています。

f:id:tsugimot:20210629172852p:plain
図 4: 3scale API Managementでのサービスプランとアプリケーションプランの組み合わせ例

要約すると、以下のようなユースケースにおいては、カスタムのサービスプランの利用を検討するといいでしょう。

  • 複数のアプリケーションプランが継承して利用可能なカスタムのフィーチャー (Features) が存在するケース
  • 複数のアプリケーションプランで適用可能なカスタムのトライアル期間が同一のAPIサービスに存在するケース
  • 複数のアプリケーションプランで適用可能なセットアップ料金または固定料金が同一のAPIサービスに存在するケース
アカウントプラン

アカウントプランは、APIに対するサブスクリプションの条件をAPIコンシューマーのアカウントに適用するケースにおいて使用するものになります。アプリケーションプランやサービスプランのようにAPIへのアクセスを管理するのではなく、このプランではアカウントをパッケージ化し、特定のアカウントがアクセスするすべてのAPIに対してアカウントプランを適用します。アカウントプランを作成すると、開発者ポータル内に利用の「階層」が作成され、それぞれのレベルに応じてパートナーが受けるサポート、コンテンツ、その他のサービスのグレードを区別することができるようになります。

例えば、APIプロバイダーが3つの異なるパートナーレベルに応じて、それぞれに表5のようなポリシーを設定したいとします。

表 5: 3つのパートナーレベルに対応したアカウントプランの例

パッケージ 流量制御 価格設定ルール フィーチャー (Features)
Strategic Partners Bronze Plan Free $30 per month Premium, partners, bronze, no support
Strategic Partners Silver Plan $50 $60 per month Premium, partners, silver, standard support
Strategic Partners Gold Plan $100 $100 per month Premium, partners, gold, 24/7 support, dedicated account

この例では、APIプロバイダーはアプリケーションプランやサービスプランで課金をするのではなく、固定の月額費用とセットアップのための費用を課金することになります。その場合、アカウントレベルでプランを運用し、そのアカウントに関連するすべてのAPIやアプリケーションに同じポリシーが適用されるようにするのが合理的です。APIプロバイダーは、API利用者のアカウントごとに異なるセットアップ費用やサポートプランを作成することも可能です。図5は、そのようなアカウントプランとAPIの関係を示しています。

f:id:tsugimot:20210629173153p:plain
図 5: アカウントプランを利用したアカウントに関連するすべてのAPIやアプリケーションへの同じポリシーの適用

3scale API Managementでは、すべてのAPI利用者のアカウントに対してデフォルトのアカウントプランが提供されています。このデフォルトプランにより、APIへのアクセスは個別のサービスプランとアプリケーションプランによって制御されます。アプリケーションの数に関係なく、複数のAPI利用者のアカウントに対してフィーチャー (Features) を定義する必要がある場合には、アカウントプランの導入を検討するとよいでしょう。また、アカウントプランは、サブスクライブされているAPIの数にかかわらず、セットアップ料金、利用料金、あるいはトライアル期間の長さがそのアカウントにおいて固定である場合にも有効です。

動画による解説

3scale API Managementを使用して、さまざまなAPI利用者向けにAPIの提供プランをパッケージ化して組み合わせる方法については、以下の動画もご覧ください。

結論

これまで紹介してきましたように、3scale API Management の機能であるアプリケーションプラン、サービスプラン、アカウントプランを適切に組み合わせて使用することで、APIをパッケージングする上での多くの複雑なシナリオにも対応することが可能になります。この記事では、1つのAPIバックエンドエンドポイントをパッケージングするための戦略について説明しました。また、3scale API Management はAPIプロダクトの機能をサポートしており、それを利用して複数のバックエンドAPIをパッケージングして同じポリシーとプランを使用することも可能となっています。今後の記事では、APIプロダクトの機能とユースケースを紹介していく予定です。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。