[Cloud, Integration] Registries: Use Cases for API Management and Microservices

原文はこちら。
http://www.oracle.com/technetwork/articles/soa/wilkins-api-mgmt-3796702.html
マイクロサービスと新しい第3世代API Managementのケイパビリティは、技術者にとって非常に自然なものです。（マイクロ）サービスが1つの機能のための実行ロジックを提供し、第3世代API Managementは、各サービス、潜在的に（マイクロ）サービス間での外部への公開を制御する手段を提供します。Luis Weirの3rd-Generation API Managementの記事では、API Management機能の進化と、第3世代API ManagementがどのようにAPI Managementを（マイクロ）サービスとうまくかみ合うのかを説明しています。
3rd-Generation API Management: From Proxies to Micro-Gateways
http://www.oracle.com/technetwork/articles/soa/weir-3rd-gen-api-mgmt-3787102.html
https://orablogs-jp.blogspot.jp/2017/07/3rd-generation-api-management-from.html
この記事では、（マイクロ）サービス環境におけるレジストリの役割、そして最終的にはAPI Managementとの関係について見ていきます。具体的なソリューションについて深く掘り下げることはしませんが、よく知られているレジストリのいくつかを参照し、さらに深く掘り下げていくためのリンクを提供します。
マイクロサービスを（マイクロ）サービスと呼んでいることにお気づきかと思います。これは非常に熟考した結果で、論争が起こる可能性があります。マイクロサービスは通常、DockerやTomcatなどの軽量アプリケーションコンテナなどの特定のテクノロジーに関連付けられていますが、マイクロサービスの純粋主義者であれば、（SOAの場合と同様に）テクノロジーではなく、設計のパラダイムと原則について考える必要があります。幸運にも非常に見識があるサービス組織や、ただ幸運なサービス組織で働いていない場合、必要な意思決定と制約はすなわち実用的な決定をする必要があるため、こうした観点を持ちながら取り組まなければならないことが多々あります。WebLogicのライセンスに多額の投資をした組織にとって、その投資をあきらめるというのは穏やかな話ではありませんが、このことがすなわちマイクロサービスアプローチを採用できないことを意味してるわけではありません。とはいえ、（マイクロ）サービスアーキテクチャを採用する場合に、WebLogicを利用することで発生しうるリスクを軽減する必要があります。第2に、レジストリの概念はマイクロサービスに固有のものではありません。実際、これらのソリューションの中には、例えばBig Data/Hadoopなどのソリューションに由来するものがあります。
Gartnerはマイクロサービスの観点でミニアプリまたはマイクロアプリについて話を始めており、これは私の伝えたい点を強調するものです。この本質はマイクロサービスの原則のより実用的な適用方法です。すべての組織が（NetflixやUberといった）マイクロサービスのポスターチャイルドたちのように、ハイパースケールやsuper elasticityを必要としているわけではありませんが、サービスのアドレス指定を容易に管理できる手段が必要です。
レジストリの役割を理解するためには、一歩戻ってマイクロサービスを支える思想を理解する必要があります。 そんなわけで、まとめてみましょう。
  • スケールとElasticity。つまり、マイクロサービスは機能の小さなピースであるため、そのサービスだけのための環境で要求を満たすためのサービスインスタンスの追加が簡単である必要があります。スケールには、インスタンス数の削減が含まれる場合があります。
  • ソリューションは多くのデプロイ済みマイクロサービスから構成されるため、どのピースもサービスコントラクトを超えて別のサービスの存在を想定するべきではありません。ピースが離散的にデプロイされているため、別のサービスの物理的な存在場所はわかりません。この分離があることで、ソリューション全体をモノリスにデプロイするのではなく、サービスの変更や追加、デプロイを独立して実施することができます。
まず第一に、この2点からだけでも、暗黙的であれ明示的であれ、サービス・インスタンスの場所を知る必要があることがわかりますし、利用可能なキャパシティを把握するためにも、インスタンスの個数を知る必要があります。さらに、ロードバランサが必要です。マイクロサービスは独立してデプロイされるため、ロードバランサが確認可能な全てのサーバの同じポートでマイクロサービスが実行されていない可能性をあることを心に留めておくことが重要です。（もちろん）全てのサーバでマイクロサービスが同じポートで動作するようにデプロイできますが、その場合、実質的にすべてのサービスをモノリスとして扱うことになります。それではロードバランサとルーティングの問題に戻りましょう。
レジストリの役割は、名前が示すように、どのサービスがどこに存在するかといった登録情報を保持することです。新しいマイクロサービスが起動すると、最初のアクションの1つは、レジストリにその存在を宣言することです。この後、各サービスはレジストリと連携して、シャットダウン時または予期せず終了した時に、確実にレジストリが検出するようにする必要があります。
wilkins-api-mgmt-fig001
この図から、次の2個の疑問が湧いてきます。
  1. レジストリはSPOF（単一障害点）にならないのか？
  2. レジストリの場所を知る方法は？
最も好ましくないのは、我々が達成しようとしている目標を損なう可能性のある、レジストリが単一障害点になることですが、幸運なことに、利用可能なすべてのレジストリには、情報を共同して共有する手段が組み込まれています。さまざまなレジストリ実装で採用されているいくつかの共通戦略があります。
マイクロサービスが事前定義済みアドレス（理想的にはDNSベースまたは仮想IP）のリストを持つ場合、2点目は対処できます。つまり、マイクロサービスはそのリストを使って動作し、応答するまでレジストリへの接続を試行します。この連携ノード探索モデルはかなり一般的で、例えばActiveMQメッセージブローカでは、クラスタ内で動作する場合にこのようにしています。最後の方法は、通信を開始するという点で、ネットワークブロードキャストを使用することです。多くのサービスが開始されると、多くのネットワークトラフィックが発生する可能性があるため、この方法はイケていませんが、CORBAブローカの中にはこのアプローチを採用していたものがあります。
ここまでで、自身をレジストリに登録し、存在を維持する方法がわかりましたが、これでは問題の半分が解決したに過ぎません。実際には、この情報の利用方法を理解し、全てのワークロードがすべてのインスタンスに分散され、マイクロサービスがワークロードを実際にマイクロサービスが存在する場所にネットワークインフラストラクチャがルーティングする必要があります。レジストリの使用にあたり2つのコアモデルがあります。
  1. クライアントサイド・レジストリの場合、マイクロサービスがレジストリのことを知っていて、インスタンスを見つけて呼び出し、必要なサービスのアドレスを取得します。
    クライアントはしばらくの間、参照をキャッシュできます。これはもちろん、インスタンス間のロードバランシングが問題になる可能性があり、新しいサービスインスタンスを起動するだけですぐに負荷が分散されるわけではありません。この方法のよい点は、グローバルな分散シナリオでは、DNSの操作をせずに、最も近い場所でマイクロサービスをすぐにインスタンス化する方法を見つける可能性が高いということです。このモデルは、EurekaフレームワークでNetflixがサポートしています。
wilkins-api-mgmt-fig003
  1. 続いて、サーバサイド・レジストリの場合、これらのレジストリは通常ロードバランサやその他のネットワーク基盤の背後に隠れています。このレジストリはロードバランサと関係があります。
    1. レジストリがロードバランサにマイクロサービスの場所を伝え、最善の方法で負荷分散するようロードバランサを構成します。
    2. ロードバランサは黙ってレジストリを呼び出し、特定のサービスで使用するアドレスを要求します。
      このサーバーサイド・アプローチは多くの点でマイクロサービスの道理を反映しています。つまり、1つだけをうまくやる、というものです。ロードバランサはロードバランシングを行い、レジストリは単に登録情報を管理し、マイクロサービスは要求がどのように処理されるかはまったく気にしません。それは別のマイクロサービスがやるのか、モノリスがやるのかも気にしません。
      この方法はパフォーマンスの低下を犠牲にしており、その実現は特定の製品（NetScalerやF5 BigIPなど）に依存しています。
wilkins-api-mgmt-fig005
全くの新規構築で、レガシーなモノリスを取り扱う必要がない場合や、ネットワークインフラストラクチャではなくアプリケーションドメイン内でルーティング管理を維持したい場合は、クライアントサイド・モデルが理想的です。マイクロサービスがモノリスとなる可能性のある他の要素と混在する場合や、最適なルーティングを実現するためにDNSなどのネットワークインフラストラクチャ要素を活用したい場合は、サーバ・サイド・モデルのほうがよいかもしれません。DNSとネットワークルーティングによって違いを隠蔽することができます。しかし、代替オプションがあります。それは、モノリスのエンドポイントを登録し、モノリスのハートビートを偽装するプロキシコンポーネントを立てるというものです（下図）。
wilkins-api-mgmt-fig007
クライアントサイド・モデルの場合、ロードバランシングをゲートウェイと組み合わせる必要があるため、SkyDNSやEurekaなどのソリューションが実質的にAPIロードバランサになりました（以後の進化と区別するため、このモデルを第1世代と呼んでいます）。
これまでは、厳密に管理された、あるいは閉鎖されたマイクロサービスのエコシステム、つまりアクセス管理、スロットリング、セキュリティ、収益化などに焦点を当てる必要のない環境だけを考慮してきましたが、こうした点が課題になると、すぐにファイアウォールまたはそれ以上のAPIゲートウェイを導入する必要があります。
APIゲートウェイでクライアントサイド・レジストリ・モデルを採用する場合、ゲートウェイの配置方法を非常に慎重に検討する必要があります。さもないと、サービスが簡単にゲートウェイの無視や、ゲートウェイのバイパスが簡単にできてしまうからです。これは、次の図に示すように、実行状況の把握および管理の観点でゲートウェイが提供するメリットが失われる可能性があることを意味します。
wilkins-api-mgmt-fig009
サーバーサイド・レジストリの場合、よりシンプルになります。下図のように、ゲートウェイはロードバランサのそばにあればいいのです。
wilkins-api-mgmt-fig011
これにより、第2世代のAPIロードバランサと言えるものに到達しました。このアプローチでは、ロード・バランシングとレジストリを単一のコンポーネントだけでなく、ゲートウェイの特性もマージするという考え方が採用されています。これは、ネットワークインフラストラクチャソリューションの進化と似ています。これはかつてはファイアウォールまたはロードバランサのいずれかでしたが、現在は複合ソリューション（Composite Solution）です。
レジストリやロードバランサとゲートウェイ間の通信にかかるパフォーマンスコストのオーバーヘッドがなくなり、環境はマイクロサービスの観点で非常に簡単になります。
実際のところ、第2世代のAPIロードバランサとして説明したものは、この記事の冒頭で触れたLuis Weirの記事にあるように、実は第3世代のAPI管理ソリューションの一部です。
wilkins-api-mgmt-fig013
いくつかの議論でこのアプローチに楯突いてくることがあります。
  • 「ハイブリッドソリューションは、（サービスは一つだけを実施し、それをうまくやるべき、という点に反する、という意味で）最高のレジストリソリューションや最高のロードバランサを得る可能性が低い」と、マイクロサービス純真主義者たちは異議を唱える可能性があります。ハイブリッド・ソリューションには、よいロードバランサ（F5 BigIPやNetScalerのことを思い出してください）の洗練性や、レジストリのシンプルさ、議論の余地はあるかもしれませんがレジストリの信頼性がほぼないためです。
  • レジストリは、純粋なロードバランサよりもかなり重い（したがってスループットが低い）と主張してくる可能性もあります。
このソリューションが組織の主要なIP（知的財産）になるか、またはジャイアントキラー製品やオープンソースフレームワークを使用して市場に参入しない限り、NetScalerとF5キットの最適化を上回ることはうまくいかないでしょう。しかし、いくつかの領域でオーバーヘッドを取り除くことで、うまくいく可能性があります。以下の点を検討してください。
  • マイクロサービスはレジストリとの通信のオーバーヘッドがない
  • サービスからサービスへのコールがAPIロードバランサ（API Manager）を経由するため、ハートビートのオーバーヘッドを削減する。サービスからの応答を受信するたびにハートビートのクロックをリセットできる。
  • ロードバランサとレジストリ間の調整はインメモリでのアクティビティで、負荷分散が回復するにつれて、レジストリは本質的に復元する。
  • ロードバランサの高性能メカニズムは、レジストリロジックによって悪用される可能性がある。さらに、起動時、終了時にAPIロードバランサに信号を送るだけで済む（別のAPIを呼び出すことはWebのアドレスを呼び出すようなものである）ため、サービスは（特にクライアントサイドでの）フレームワークをあまり必要としない。
スループットについて言えば、潜在的なコストはありますが、ゲートウェイ機能がポリシー駆動型で、コストがポリシーの複雑さと同じくらい高く、APIへの外部呼び出しのポリシーと内部APIのポリシーを分離できる場合、一方ではセキュリティにより敏感に、他方はそうでないように負荷を調整することができます。
では、第2世代のAPIロードバランサが良いアイデアなら、なぜそれはまだ存在しないのでしょうか？私たちの答えは、ゲートウェイがまだ成熟の途上であるという事実に行き着きます。ゲートウェイソリューションの中には軽量ESBに移行しているものがあります（私は以前に概説された議論に同意します）し、これはThoughtWorks Tech Radarのポジションに反映されています。
Overambitious API gateways (ThoughtWorks TECHNOLOGY RADER)
https://www.thoughtworks.com/radar/platforms/overambitious-api-gateways
しかし、このようなニーズの方向に向かう構想が確認されています。レジストリから見えるAPIの作成を簡単にするためのFeignのメカニズムを考えてください。APIの第4世代（全てがAPI）に向かうにつれ、その時点ではAPIが普及しているため、第2世代のAPIロードバランサの必要性が高まるでしょう。別の見方をすれば、第3世代のAPI Managementはその中に負荷分散機能を取り込んでいます。

Conclusion

Oracle PaaSの中でもAPI Platform Cloud Serviceはまだ若いサービスゆえに、主要な要求を反映する機能の提供が継続中です。しかし、API Platform Cloud ServiceにはSDKを使って機能を提供する手段がありますし、API Platformのゲートウェイエンジン部分は非常にスケーラブルであるとともに、通信業界由来の基礎部分を有しているため、本質的に高パフォーマンスです。OracleのApplication Container Cloudは現時点で、第1世代のAPIロードバランサ機能をそのプラットフォーム内に有していますが、将来主要な差別化要因として第2世代モデルを採用する可能性があるでしょう。別の可能性として、お客様が両サービスを採用する場合には、ACCSは負荷分散機能を持つAPI Platform Cloud Serviceを利用するように切り替えることができるようになるかもしれません。

References:

About the Author

Oracle ACE AssociateのPhil WilkinsはiPaaS、ミドルウェアやOracleテクノロジーを専門とするCapgeminiのSenior Consultantで、Implementing Oracle Integration Cloud Service (2017, Packt) の共著者であり、OTNやUKOUG Oracle Scene、その他の出版物に対して多数寄稿している。
-
カテゴリ ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)