OCI API Gatewayのルートを 迅速かつ簡単に (2021/09/30)

OCI API Gatewayのルートを 迅速かつ簡単に (2021/09/30)

https://www.ateam-oracle.com/post/oci-api-gateway-routes-quickly-and-easily

投稿者： Gustavo Saurez 

OCI API Gatewayを使用する目的は、APIクライアントからのトラフィックを、複数のタイプのバックエンドエンドポイントやサービスにルーティングすることです。 各API Gatewayは、多くのバックエンド・エンドポイントを、プライベートまたはパブリックの単一のAPIエンドポイントに統合することができます。 バックエンドエンドポイントはいくつまで可能か？ それは後ほど説明します。


まず、API Gatewayを構成する際の重要なコンセプトをいくつか説明しよう。


API デプロイメント： API デプロイメントは、API Gatewayにデプロイされた API の構成を指定します。 各 API デプロイメントには、次のようなパスプレフィックスが必要です。 各 API デプロイメントには、/、/app1、/hrservices、/mywebservice/v2 など、フロントエンドの URL をバックエンドのエンドポイントやサービスのセットにマッピングするためのパスプレフィックスが必要です。 API Gatewayのフロントエンド URL には、この接頭辞 (およびパス、メソッド、ヘッダー、変数など) が含まれ、バックエンドサービスのセットを呼び出すことができます。


            https://myapps.ateam.com/app1


ルート：ルートとは、パス（およびメソッド）とバックエンドサービスとの間のマッピングを意味します。 各ルートには、/service1や/getpriceなどのパスが必要で、これを使って呼び出す特定のバックエンドサービスを選択します。 1つのAPIデプロイメントは複数のルートを持つことができ、各ルートはバックエンドサービスに関連付けられています。 このバックエンドサービスは、OCI ファンクションまたは HTTP バックエンド URL になります。 API クライアントが service1 を呼び出すために呼び出す API ゲートウェイフロントエンド URL は、以下のようになります。


           https://myapps.ateam.com/app1/service1


1つのルートは、パスパラメータやワイルドカードをルートのパスに使用したり、HTTP(s)バックエンドの定義でコンテキスト変数(パス、クエリ、ヘッダ、認証パラメータ)を呼び出したりすることで、複数のバックエンドにリクエストを動的にマッピングすることができます。 この機能があれば、上記のような制限はほとんど気にならなくなります。 例えば、以下のようになります。


ルートのパスには、以下のような括弧で囲まれたパスパラメータを含めることができます。

/finance/{country}


/{service}


バックエンドの定義では、コンテキスト変数を使用して、それらの値を取得することができます。

http://api.finance.com/${request.path[country]} or


http://apis.com/${request.path[service]}


パラメータとコンテキスト変数の詳細については、「ポリシーと HTTP バックエンド定義へのコンテキスト変数の追加」を参照してください。


次の図は、API デプロイメントのパスのプレフィックス、ルート、バックエンド API の関係をまとめたものです。



さて、ドキュメント「API Gateway Internal Limits」によると、APIデプロイメントごとに定義できるルートの最大数は50です。 これはバックエンドのエンドポイントの数と同じに対応しています。 これでは少なすぎますね。 では、最大20個のAPIデプロイメントを作成すれば、バックエンド・エンドポイントの数は1000に増えます。 これでもまだ少ないし、もし2つか3つのAPIデプロイメントしか定義したくないとしたら？


この図を見てください。



この例では、複数のプライベートバックエンドアプリケーションがあり、それぞれが複数のエンドポイント（API）を提供しています。 APIクライアントは、1つのエントリーポイント（https://myapps.ateam.com）を介して、これらすべてのサービスにアクセスします。 ゲートウェイの「APIデプロイメント」と「ルート」をバックエンドのエンドポイントにマッピングするには、さまざまな方法があります。 3つの基本的な例があります。


1.    アプリケーションごとに1つのAPIデプロイメント・プレフィックスを使用し、アプリのエンドポイントごとに1つのルートを使用する（上の図のように）。 



この場合、バックエンドのエンドポイントごとに1つのルートが存在することになります。 そのため、このオプションは、特に上述の制限を考慮すると、おそらく良いアイデアではありません。 また、バックエンドエンドポイントの追加、削除、変更には、API Gatewayの設定を変更する必要があるため、メンテナンス性の高いオプションとなります。


2.   アプリケーションごとに1つのAPI Deployment prefixを使用し、すべてのアプリケーションのエンドポイントに対して1つのルートを使用します。




このオプションでは、複数のデプロイメントが定義され、デプロイメントごとに 1 つのルートのみが定義されます。 バックエンドのURL(host.domain)が異なる場合、複数のデプロイメントが必要になります。 ルートのパスには{endpoints}のようなパス変数を、バックエンドのURLには${request.path[endpoints]}のようなコンテキスト変数を使用します。



このオプションでは、APIデプロイメントごとに1つのルートのみが必要になる場合があります。 APIクライアントの呼び出しとマッピングの例をいくつかご紹介します。

API Client Call

Backend Mapping

https://myapps.ateam.com/app1/finance/us

http://app1.d1.com/finance/us

https://myapps.ateam.com/app2/hr/Users

http://app2.d2.com/hr/Users



3.  1つのAPI Deploymentプレフィックスと、すべてのアプリのエンドポイント用の1つのルート。



このオプションは、ロードバランサーを使用している場合など、バックエンドのURL（host.domain）がすべてのエンドポイントで同じである場合に使用できます。 そのため、API デプロイメントは 1 つしか必要ありません。


このオプションでは、1 つのデプロイメントと 1 つのルートのデプロイメントのみが必要になる場合があります。 API クライアントの呼び出しとマッピングの例をいくつか紹介します。

API Client Call

Backend Mapping

https://myapps.ateam.com/apps/finance/us

http://app.d.com/finance/us

https://myapps.ateam.com/apps/hr/Users

http://app.d.com/hr/Users


 


上記は、デプロイメントとルートをバックエンドのURLにマッピングする方法の3つの例に過ぎません。  その他の設定として、ヘッダ（request.headers）、クエリパラメータ（request.query）、認証パラメータ（request.auth）にコンテキスト変数を使用することができます。 これらのオプションを使用すれば、多くのAPIエンドポイントをデプロイする際に、APIのデプロイメントとルートのリソース制限が問題になることはありません。


 


参考文献

コメント

コメントを投稿

このブログの人気の投稿

Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01)

イメージ
Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01) https://database-heartbeat.com/2023/11/01/draining-ac-rac/ はじめに Oracle RACは、Oracle Databaseのスケーラビリティと高可用性を提供します。1つのサーバー(RACノード)に障害が発生した場合、またはメンテナンスのためにオフラインになった場合でも、追加のノードを介してデータベースにアクセスできます。ただし、メンテナンスの開始時に、データの読取りまたは変更に関係なく、一部の作業を実行しているクライアント・セッションはどうなりますか。この作業は中断され、ドレインを実装してアプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを有効にしないかぎり、エンドユーザーまたはアプリケーションによって再度実行する必要があります。 環境 2ノードのOracle RACを例に挙げて、高速アプリケーション通知(FAN)、ドレインおよびアプリケーション・コンティニュイティによってメンテナンス・イベントがエンドユーザーに透過的になる方法を理解しましょう。アプリケーションは、30個のセッションを保持するように構成された接続プールを使用しています。 通常の操作 通常の操作中は、両方のRACノードが起動し、アプリケーションを実行しています。ロード・バランシング戦略によっては、セッションの数が両方のノード間で異なるか、均等に分散される場合があります。次の図をよりよく視覚化するために、ノード2のノード1および20のセッションに10のセッションがあるとします。 セッションは、アイドル状態(接続されているが何もしていない)またはアクティブ状態(リクエストの途中)にできます。リクエストは、データの読取り(SELECT)または操作(INSERT、DELETE、UPDATE)が可能です。 ドレインによるサービスの停止 ある時点で、システムのメンテナンスが必要になります。2ノードRACがあるため、メンテナンスはローリング方式で、1つのノードを順番に(ほとんどの場合)実行できます。メンテナンスは、たとえば、オペレーティング・システム、Grid Infrastructureまたはデ
続きを読む

Oracle Cloud Infrastructure Secure Desktopsを発表: デスクトップ仮想化のためのOracleのクラウドネイティブ・サービス (2023/06/28)

イメージ
Oracle Cloud Infrastructure Secure Desktopsを発表: デスクトップ仮想化のためのOracleのクラウドネイティブ・サービス (2023/06/28) https://blogs.oracle.com/cloud-infrastructure/post/secure-desktops-cloud-native-virtualization 投稿者： Joost Pronk Van Hoogeveen Jan Hendrik Mangold | Principal Product Manager Oracleは、Oracle Cloud Infrastructure(OCI)Secure Desktopsという新しいクラウド・ネイティブ・サービスをリリースしています。このエキサイティングな開発により、顧客はOCIテナンシから簡単にすばやく仮想デスクトップ・インフラストラクチャ(VDI)をデプロイできます。 OCIの使用状況は大幅に拡大しています。組織は、OCI内でデータを安全に保つことの価値を実現しています。ゼロトラストなセキュリティ優先アーキテクチャを実装することで、OCI Compute、Storage、およびNetworkingサービスは、グローバル・アクセスのためのエンタープライズ・アプリケーションを導入するための信頼できるプラットフォームを提供します。 データ・セキュリティとVDIがどのように役立つか 業界のアナリストによると 、ラップトップは53秒ごとに盗まれています。その事実と現実を結び付けると、会社のデータは、公共の場所を経由したり、従業員の自宅に座ったりするラップトップやデスクトップへと移行します。ローカル・ディスクの暗号化、データ・アクセス権限の強制、VPNアクセスの保護によってデータを保護するためにテクノロジが使用されていますが、いずれも許容可能なセキュリティ・レベルが適用されるため、リスクは依然として高くなる可能性があります。盗難または準拠していないいくつかのマシンでは、企業データ、さらには顧客データのデータ侵害が発生する可能性があります。 VDIテクノロジは長年にわたって存在してきましたが、従業員はローカル・マシンを使用して、会社のデータ・センター内の仮想マシンで実行されているデスクトップ・アプリケー
続きを読む

新しいOracle Container Engine for Kubernetesの機能強化により、大規模なKubernetesがさらに簡単になりました (2023/03/20)

イメージ
新しいOracle Container Engine for Kubernetesの機能強化により、大規模なKubernetesがさらに簡単になりました (2023/03/20) https://blogs.oracle.com/cloud-infrastructure/post/oracle-container-engine-kubernetes-enhancements 投稿者： Mickey Boxell | Product Management Linux以降、 Kubernetes はオープンソースソフトウェアの歴史上最も急速に成長しているプロジェクトです。10年も経たないうちに、 Kubernetesは主流 になり、特に過去2年間で導入がかつてないほど大きくなりました。 Oracle Cloud Infrastructure(OCI) は、この勢いも見ています。あらゆる業界の何千ものエンタープライズ顧客が、クラウドネイティブアプリケーション開発のメリットを経験しており、その導入を迅速化し、Kubernetesの使用を拡大しています。 Oracle Container Engine for Kubernetes (OKE)で実行されている抽出、変換、ロード(ETL)ジョブ、パイプライン、ハイパフォーマンスコンピューティング(HPC)ワークロード、さらにはデータベースなどにKubernetesを使用するために、顧客はKubernetesで標準化されており、コンテナ化されたアプリケーションを実行するのみでなく拡張されています。  「私たちは、Kubernetes インフラストラクチャと OKE、GPU、HPC、およびストリーミング、OpenSearch などの最新の開発者サービスを組み合わせて使用​​して、OCI で数十億の音声 AI クエリを実行しています。私たちは、次世代のトレーニングと配信に最適なクラウドとして OCI を選択しました。 AI アプリケーション – Mercedes Benz、Toast、VIZIO、Hyundai などのグローバル ブランドに最速かつ最も正確な音声エクスペリエンスを提供するのに役立ちます.OCI を使用することで、以前のクラウドと比較してパフォーマンスが 50 ～ 60% 向上しました。 2 倍のコスト削減 – 使用量
続きを読む