Translated message

A translation of this page exists in English.

Red Hat OpenShift API Management のサービス定義

更新 -

はじめに

アプリケーションプログラミングインターフェース (API) は、アジャイルインテグレーション を行うと共に、デジタル社会にビジネス価値を提供するための鍵となっています。API は企業のイノベーションを助け、企業間での敏捷性を向上させ、新製品の開発および収益構造の構築をシンプルにするための基盤となります。

Red Hat OpenShift API Management サービスにより、API の管理が簡素化されます。パフォーマンスの向上、顧客の管理、および将来的な成長のために構築されたインフラストラクチャープラットフォーム上で、API の共有、保護、配布、および管理を行います。

本サービスは、以下の OpenShift マネージドサービスへのアドオンとして利用することができます。

  • Red Hat OpenShift Dedicated: コンテナー化されたアプリケーションを開発および実行するためのプラットフォーム
  • Red Hat OpenShift Service on AWS: Red Hat と Amazon Web Services (AWS) の両者によって共同で管理およびサポートされるフルマネージド OpenShift サービス

Red Hat OpenShift API Management サービスは、Red Hat が完全に管理する API トラフィック制御および API プログラム管理用のソリューションです。これには、解析機能、アクセス制御、開発者ワークフローなどが含まれます。本サービスは、Red Hat 3scale API Management プラットフォーム を元にしています。

API 管理サービスには、API のセキュリティーを保護するための Red Hat Single Sign-on の実装も含まれています。このサービスは、企業全体の SSO ソリューションとしてではなく、API 管理の枠組みの中で使用する (API および 3scale デベロッパーポータルへのアクセス制限など) ことのみを意図しています。

API 管理サービスの高度な設定

お客様の OpenShift Dedicated IDP

API 管理サービスの開発および通知手順の多くは、電子メールによるコミュニケーションに基づきます。したがって、有効にした各開発者の正しいメールアドレスがアイデンティティープロバイダー (IDP) に含まれていることが重要です。

テナンシーモデル

サブスクリプションでは、事前設定されたプライマリーテナントに加えて、追加のテナントを 20 まで要求することができます。 これらのテナントを要求するには、Red Hat サポート からチケットを作成してください。

マルチテナントへの対応についての詳細は、オンプレミス型 3scale のドキュメントで Red Hat 3scale API Management でのマルチテナントへの対応 に関する情報を参照してください。

注記: 複数テナントを設定しても、サブスクリプションを通じて利用可能なメッセージの合計数には影響を及ぼしません。

パスベースのルーティング

この機能は、3scale の プロダクト および バックエンド 機能に置き換えられています。 この機能の詳細は、『スタートガイド』の「プロダクトとバックエンド」を参照してください。

ステージング環境および実稼働環境用の管理 APIcast

OpenShift API Management サービスには、Red Hat によって管理される 2 つの管理 APIcast インスタンス (ステージング環境および実稼働環境用) が含まれます。これらは Red Hat により事前設定されていて、すぐに使用できることができます。 これらのインスタンスは共に単一のクラスターにインストールされ、3Scale でのコードプロモーションを想定しています。

Self-managed APIcast およびカスタムポリシー

カスタム API を管理する必要がある場合 (Red Hat OpenShift API Management サービスのデプロイメントとは異なる地域やデータセンターなど)、サブスクリプションには、APIcast インスタンスをローカルにインストールして自己管理する機能が含まれます。

注記: カスタムポリシーを使用するには、ポリシーを Self-managed APIcast インスタンスにインストールする必要があります。

サブスクリプションには商業的に妥当な範囲のサポートが含まれていて、Red Hat サポートからチケットを作成することで利用できます。 デプロイした Self-managed APIcast インスタンスの監視および維持は、お客様の責任で実施する必要があります。

詳細は、Red Hat 3scale API Management の Self-managed APIcast に関するドキュメントを参照してください。

請求機能のサポート

Red Hat OpenShift API Management は Payment Card Industry Data Security Standard (PCI DSS) のコンプライアンス認定を取得し、API Management の請求機能をサポートするようになりました。 提供されるサポートの詳細については、ドキュメントで「請求設定の定義」を参照してください。

招待機能

すべてのユーザーは、Red Hat OpenShift API Management サービスを通じて 3scale API Management の管理ポータルにアクセスすることができます。3scale API Management の管理ポータルにユーザーを追加するには、OpenShift Dedicated クラスターのアイデンティティープロバイダーを設定してユーザーを追加する必要があります。詳しくは、『アイデンティティープロバイダーの設定』を参照してください。3scale の管理ポータルには、新しいユーザーを招待して管理ポータルへのアクセスを許可する機能がありますが、この機能は現在 OpenShift API Management ではサポートされていません。

OpenShift Service Registry

以下のサービスのユーザーは、Red Hat OpenShift Service Registry を無償サービスとして利用することができます。

OpenShift API Management で OpenShift Service Registry を使用することで、OpenAPI、GraphQL、WSDL、および AsyncAPI 等の標準に基づく API 定義を保存し、管理することができます。詳細は、「Red Hat OpenShift Service Registry Service Definition」を参照してください。

デプロイメントモデル

Red Hat OpenShift API Management サービスは、AWS バージョンの OpenShift Dedicated でのみ利用することができます (Red Hat OpenShift Service on AWS を含む)。OpenShift の AWS バージョンのオファリングに関する詳細は、以下のドキュメントを参照してください。

OpenShift Dedicated および Red Hat OpenShift Service on AWS 4 は、プライベート、パブリック、またはパブリック/プライベートとして設定することができます。 Red Hat OpenShift API Management は、これらすべての設定で利用することができます。ただし、クラスターへのアクセス可否により、管理可能な API が異なります。 ルートが利用可能で予想どおりに機能することを検証するために、設定を実稼働環境に移行する前にテストを行うことが極めて重要です。

注記: Red Hat OpenShift API Management は、現在 AWS Security Token Service (STS) 対応のクラスターをサポートしていません。

開発、テスト/ステージング、および実稼働環境の分離

Red Hat では、それぞれの環境を個別の OpenShift Dedicated クラスターに分離することを推奨します。この場合、自動ビルドおよびデプロイパイプラインを使用して、開発またはテストクラスターをステージングおよび実稼働クラスターに移行します。

この分離により、開発環境のソフトウェアが実稼働環境のワークロードに影響を与えなくなります。 また、新しいバージョンの OpenShift と API Management サービスの両方を、実稼働前のクラスターでテストすることができます。

セキュリティーおよびコンプライアンス

Red Hat の管理サービスとして、それに含まれるコンポーネントおよびサービスは保護された namespace (redhat-rhoam プレフィックス) にインストールされます。 これらの namespace は、認定された Red Hat SRE チームによって監視および管理されます。 デフォルトでは、お客様によるこれらの namespace へのアクセスは制限されています。dedicated-admins グループのユーザーには、監視用に読み取りアクセス権限が付与されます。 お客様が OpenShift Dedicated の cluster-admin アクセス権限を要求した場合、お客様はこれらの namespace の設定を変更できる点に注意してください。 その場合には、namespace がベースの Red Hat 設定に戻されるまで、サービスの可用性は保証されません。

Red Hat の管理サービスは、OpenShift Dedicated 環境からセキュリティーおよびコンプライアンスのプロトコルを継承します。 したがって、ISO 27001 および PCI の認定は進行中であり、今後は FedRAMP に対応する計画です。

プラットフォームのロギングおよび API メトリクス

オプションの OpenShift Dedicated のロギングスタックを有効にした場合、クラスターのロギングスタックで Red Hat OpenShift API Management サービスのログを利用することができます。ログの保持およびアクセス性は、OpenShift Dedicated のロギングスタックで維持されます。 詳細は、OpenShift Dedicated のサービス定義 を参照してください。

Red Hat OpenShift API Management 固有のメトリクスが保持されるのは、45 日が経過するか、ストレージ消費が 50 GB に達するかのいずれか早い時点までです。 現在、この期間を延ばす、またはストレージの限度を上げる方法はありません。

ユーザーワークロードの監視

マネージド OpenShift の ユーザーワークロードの監視 機能が有効で、Red Hat OpenShift API Management がインストールされている場合、ユーザーは誤ったアラートを受信する場合があります。

スケーラビリティーおよびサービスレベル

ニーズに応じて、メッセージクォータが関連付けられたさまざまなサブスクリプションを利用することができます。 現時点では、クラスターごとに単一の Red Hat OpenShift API Management サービスをデプロイすることができます。この場合、それぞれに 1 つのサブスクリプションを選択する必要があります。個々のクラスターについて、クォータを増やすために複数のサブスクリプションを追加することはできません。

サブスクリプションレベルは、1 日あたりの合計リクエストレートをベースに購入されますが、各サブスクリプションを監視するクォータは、1 分あたりの呼び出し数に基づきます。 詳細については、以下の表 (表 1) を参照してください。

表 1: サブスクリプションレベルおよび関連付けられたクォータ数

サブスクリプションレベル 最大スループット
1 日あたり 10 万 API コール 1 分あたり 69.4 API コール
1 日あたり 100 万 API コール 1 分あたり 695 API コール
1 日あたり 500 万 API コール 1 分あたり 3473 API コール
1 日あたり 1000 万 API コール 1 分あたり 6945 API コール
1 日あたり 2000 万 API コール 1 分あたり 13889 API コール
1 日あたり 5000 万 API コール 1 分あたり 34723 API コール

Red Hat では、平均のペイロードサイズを 1 kB としてコンピュートリソースを指定しています。 API のペイロードサイズが異なる場合、全体的なパフォーマンスおよびスループットに影響を及ぼす可能性があります。 パフォーマンステストを実行して、具体的な API およびカスタム API ペイロードに基づいて実際のスループットを検証することを推奨します。

表 1: サブスクリプションレベルおよび関連付けられたクォータ数 に定義するサブスクリプションの最大スループットに近付くと、電子メールにより通知を受けます。

Self-managed APIcast インスタンスを通じてルーティングされる API コールも、合計のクォータ数にカウントされる点に留意することが重要です。

ベンチマークは以下の条件を前提としています。

  • ライトウェイトなアプリケーション (複雑なコンピュートジョブはない)
  • リクエストの 10% は認証用
  • リクエストの 45% は 3scale APIcast に対する GET リクエスト
  • リクエストの 45% は 3scale APIcast に対する POST リクエスト
  • POST リクエストのペイロードは最大 1 MB
  • 実稼働環境用 APIcast サーバーを使用

注記: Red Hat では、ステージング環境用 APIcast での同等の負荷をサポートしていません。パフォーマンステストでは、実稼働環境用の APIcast を使用する必要があります。

リソース要件

Red Hat OpenShift API Management サービスをインストールおよび設定する場合、サービスは自動的に OpenShift Dedicated のコンピュートノードに配置されます。現在、サービスが配置されるノードを指定する方法はありません。

Multi-AZ OpenShift Dedicated クラスターインスタンスを購入している場合、サービスの中断を最小限に抑えるために、管理サービスは複数のアベイラビリティーゾーンに渡って自動的に分散されます。 Multi-AZ の詳細は、「可用性」セクションを参照してください。

次の表に、Red Hat OpenShift API Management でサポートされる各 SKU のリソース要件の詳細を示します。

表 2: Single-AZ の場合の AWS リソース要件

クォータ 仮想 CPU メモリー ストレージ
10 万 API コール 11 確保 24 GiB 確保 50 GB 確保
100 万 API コール 11 確保 24 GiB 確保 50 GB 確保
500 万 API コール 12 確保 25 GiB 確保 50 GB 確保
1000 万 API コール 13 確保 25 GiB 確保 50 GB 確保
2000 万 API コール 14 確保 27 GiB 確保 50 GB 確保
5000 万 API コール 19 確保 28 GiB 確保 50 GB 確保

表 3: Multi-AZ (3 ゾーンと仮定) の場合の AWS リソース要件 - 合計仮想 CPU

クォータ 仮想 CPU メモリー ストレージ
100 万 API コール 11 確保
16 確保を推奨*		 24 GiB 確保
36 GiB 確保を推奨*		 150 GB 確保
(1 AZ あたり 50 GB 確保)
500 万 API コール 12 確保
17 確保を推奨*		 25 GiB 確保
38 GiB 確保を推奨*		 150 GB 確保
(1 AZ あたり 50 GB 確保)
1000 万 API コール 13 確保
19 確保を推奨*		 25 GiB 確保
38 GiB 確保を推奨*		 150 GB 確保
(1 AZ あたり 50 GB 確保)
2000 万 API コール 14 確保
21 確保を推奨*		 27 GiB 確保
41 GiB 確保を推奨*		 150 GB 確保
(1 AZ あたり 50 GB 確保)
5000 万 API コール 19 確保
27 確保を推奨*		 28 GiB 確保
41 GiB 確保を推奨*		 150 GB 確保
(1 AZ あたり 50 GB 確保)

* 3 アベイラビリティーゾーンのケースの追加仮想 CPU およびメモリーは、ゾーンが失われた場合に合計スループットを確保するためのものです。残りの 2 つのゾーンには、API サービスの要求を満たすのに十分なリソースが必要です。

注記: クラスターに API Management サービスをインストールした場合、他のワークロードよりも高いリソース優先度が設定されます。 具体的には、他の Pod の優先度は低くなり、上記の表に基づき API Management サービス用に空き領域を確保するために、動作を停止する場合があります。 これを回避するには、OpenShift Dedicated クラスターに十分なコンピュートリソースを割り当てるようにしてください。

Customer Cloud Subscription (CCS) ユーザーの場合、関連するバックアップを含め、Redis および Postgres 用に Red Hat が AWS Multi-AZ サービスを活用する点に留意することが重要です。 これらは必須の要件であり、以下のとおり AWS アカウントからリソースが消費されます。

1 VPC

  • Red Hat は新規の VPC を作成し、これをクラスターのデフォルト VPC のピアに設定します。この VPC には、Red Hat の AWS サービスインスタンスが含まれます。この VPC の CIDR 範囲は、インストール時に指定することができます。

  • 現在、Red Hat OpenShift API Management サービスでは、持ち込み VPC (BYOVPC) の使用はサポートされません。

Redis

  • 3 つの cache.t3.micro インスタンス (2 つの AZ が有効)

Postgres

  • Postgres 用の 3 つの db.t3.small インスタンス (2 つの AZ が有効)
  • デフォルトで 20 GB の AWS ストレージ、100 GB まで自動的にスケールアップ (3 RDS * 20 GB * 2 AZ = 120 GB)

バックアップ

  • メトリクス/バックアップ用の S3 バケット (サイズは消費量に依存します)

CCS 利用者の場合、Red Hat はサービスの SLA を満たすのに必要なリソースを増やす権利を有します。 お客様には、リソースの増加が通知される予定です。サブスクリプションレベルを変更するには、アカウント担当者に直接ご連絡いただくか、https://www.redhat.com/ja/contact からリクエストを送付してください。

クラスターの自動スケーリング

自動スケーリング機能が有効なクラスターについては、Red Hat OpenShift API Management サービスに必要な最少リソース要件が常に満たされるようにしてください。

更新およびアップグレード

Managed API 製品のアップグレードはお客様と共にスケジュールされ、SRE チームから提供されます。
お客様に影響を与えないアップグレード、および弊社管理プラットフォームに対する重大なセキュリティー問題の場合は、SRE チームから自動的にクラスターに提供されます。

可用性

Red Hat の管理サービスについては、ベースとなる OpenShift Dedicated 管理環境を含めて 99.95% の可用性が維持されます。 詳細は、Red Hat Enterprise Agreements の Appendix 4 (Online Subscription Services) を参照してください。

Multi-AZ 高可用性 (HA) デプロイメントは、ベースとなる OSD クラスターが Multi-AZ に設定されている場合にサポートされます。Multi-AZ HA デプロイメントをサポートするために、Red Hat OpenShift API Management サービスは、サービスを構成する Pod の複数のレプリカと共にデプロイされます。これらの Pod には、Kubernetes スケジューラーに影響を及ぼす非アフィニティールールのセットが適用されます。これにより、同じ AZ 内のノードにスケジュールされるのを防ぎます。さらに、Red Hat は Pod の優先順位を使用してこれらの Pod の優先度を上げています。これにより、Kubernetes スケジューラーは、クラスター上の他の非インフラ Pod より先に管理サービスのスケジューリングニーズを考慮するようになります。

バックアップおよび障害復旧

OpenShift Dedicated 環境で行われる日々のバックアップに加えて、そのデータおよび設定を含めて Managed API サービスのスナップショットが追加で生成されます。 致命的な障害が発生した場合には、Red Hat SRE は商業的に妥当な範囲の手段を用いて先ず OpenShift Dedicated 環境を復旧し、続いて Managed API サービスを復旧します。

マネージドサービスの削除

標準のアドオン削除フローを使用して、お客様は Red Hat OpenShift API Management サービスを OpenShift Dedicated クラスターから削除することができます。一度この操作を呼び出したら、取り消して元に戻すことはできない点に注意してください。削除の操作には、すべての Red Hat OpenShift API Management アドオンのデータおよびバックアップの自動削除が含まれます。

サポートの利用

Red Hat のプレミアムオファリングとして、24 時間対応の実稼働および開発者レベルのサポートに加えて、Red Hat カスタマーポータル へのフルアクセスが提供されます。 最善の解決策を得るために、質問または問題があればいつでもチケットを作成してください。Red Hat OpenShift API Management サービスのサポートケースを作成する場合は、製品名に「Red Hat OpenShift API Management Service」を選択します。

詳細は、サポートマトリックス を参照してください。

Comments