原文はこちら。
https://blogs.oracle.com/developers/an-api-first-approach-to-microservices-development
開発者は、多くの可動パーツを備えた分散システムの観点から、そのアプリケーションについて考える必要があります。その結果、ちょっと例示すると、resiliency（復元性、回復力）、idempotency（冪等性）、eventual consistency（結果整合性）などの課題は、今や考慮すべき重要な側面です。
さらに、マイクロサービスの設計とベストプラクティスの最新動向を踏まえて、アプリケーションやサービスを動作させるためにコンテナやオーケストレーターについて学ぶ必要もあります。Kubernetes、Mesos/Marathon、Docker Swarmなどの最新のクラスター管理とコンテナオーケストレーションソリューションは、ネットワーク化やサービス発見などを単純化します。これらは時間をかけて改良されているとはいえ、これらはいまだインフラストラクチャーの活動です。これらのツールとテクノロジは、サービスのデプロイと接続のプロセスを処理し、障害発生時にサービスの継続実行を保証することを主目的としています。これらの側面は、実際のサービスそのものよりもサービスをホストするために使われるインフラストラクチャとより関連しています。開発者は、オーケストレータの仕組みをしっかりと理解している必要があります。また、サービスを構築する際には、そのことを考慮する必要があります。プログラミングモデルとインフラストラクチャは絡み合っており、明確に分かれていませんので、開発者はサービスを機能させるために基礎となるインフラストラクチャを理解する必要があります。
開発者は実際にサービスをデプロイする実行環境を処理するために必要なコードではなく、ロジックの開発に集中したいと考えている、とお客様やオープンソースコミュニティか何度も伺いましたが、それはどういうことでしょうか。
より複雑なサービスのデプロイや管理で非常にオーバーヘッドがかかりすぎる場合、とりわけ、開発者は（別のサービスに接続するために必要な唯一のもの）APIに注力し、リアクティブなスタイルでサービスを開発し、場合によってはfunction（関数）を使ってシンプルな操作を実行したいのです。
また、OSSスタック上にプラットフォームを構築して、ベンダーのロックインを回避し、パブリッククラウドをオンプレミスインフラストラクチャと組み合わせて使用するハイブリッドシナリオを可能にすることも、開発者の間で強く求められています。
API-firstなマイクロサービスプラットフォームの開発の主な動機となったのは、顧客および開発者からの沢山のご意見であり、以下の主要な要求事項に基づきます。
![]()
![]()
プラットフォームのすべての主要コンポーネントを見てみましょう。APIレジストリは、開発者がマイクロサービスをどのように考え、構築し、使用するかを変えるものです。
このように、クラウドベンダーが提供するような外部サービスは、クラスタ内の他のサービスと同様に、同じワークフローを使用する開発者と共に使用できます。利用したいAPIを特定し、クライアントライブラリを生成し、サービスとの実際の通信を処理します。
Service Brokerは、既存のインフラストラクチャの最新化に携わる開発者をサポートします。例えば、既存のコードをクラスタに展開できるコンテナにパッケージングできます。モダナイズできない既存アプリケーションが存在する場合のソリューションも検討しています。この場合、Service Brokerを使用してAPIレジストリ内の一連のAPIを公開するプロキシサービスを「公開」することで、クラスタ内の他のマイクロサービスを利用するのと同様に外部/レガシーシステムを利用できます。
先に述べたように、主たる目標の1つは開発者にとっての複雑性を軽減することです。複数のマイクロサービス間の通信の管理は困難な作業です。 このため、Istioをサービスメッシュとしてプラットフォームに追加する必要があると判断しました。Istioを使えば、監視、診断、複雑なルーティング、復元力、ポリシーを無料で享受できます。Istioのおかげで、これらの機能を実装する開発者の大きな負担がなくなります。 Istioを使えば、こうした機能をプラットフォームレベルで利用可能です。
API-firstアプローチを監視にも推し進めるべく、我々の監視ソリューションでは、マイクロサービスが（Vizsceralを使って）互いにどのように接続されているか、それらをまたがって流れるデータを開発者が確認できます。将来的には、どのAPIが利用されてきたかを示すことも考えています。これにより、開発者は、Zipkin/Jaegerの分散トラッキング情報を使って、潜在的なレイテンシの問題を調査したり、サービスの効率を向上したりできます。将来、他のサービスとの統合を追加する予定です。例えば、マイクロサービス間のリクエストをJVM内のデータ構造と相関させる機能を追加することで、開発者は各リクエストに対してデータがどのように処理されているかを追うことで、複数のマイクロサービス全体（の性能）を最適化できます。
を示したものです。私たちは、2018年初頭の初期OSSリリースに近づくにつれて、プラットフォームのさまざまな側面をより深く理解してもらうためのブログを投稿する予定です。それまでの間、以下のJavaOneセッションをご覧ください。
このトピックの背景については、Getting Started with Microservicesシリーズの他のブログ記事を参照してください。Part 1では、マイクロサービスの主な利点のいくつかについて説明すると共に、マイクロサービスを扱う際に考慮すべきいくつかの領域に触れています。
https://blogs.oracle.com/developers/an-api-first-approach-to-microservices-development
Introduction
ここ数年、クラウドでのさまざまなマイクロサービスプラットフォームに対する私たちの取り組みにより、多くのお客様と緊密な協力関係ができあがりました。その結果、開発者が分散システムの深い知識に加え、マイクロサービスアーキテクチャを採用する際の苦労を深く理解しました 。 Oracleに入社した大きな動機は、スタートアップ、Amazon、マイクロソフト出身の非常に優れた人材と協力して、開発者を真に対象とする、オープンソースコンポーネントに基づくプラットフォームをゼロから構築する機会があることでした。私たちの新しいプラットフォームのこの最初のブログエントリで、このプラットフォームの設計を推し進めるものと、アーキテクチャの概要を紹介します。What developers are looking for
マイクロサービスへの移行は、これまでの伝統的な方法を使用してアプリケーションを構築している開発者にとっては容易な移行ではありません。分散アプリケーション（つまりこれこそがマイクロサービスアプリケーション）を設計する際に開発者が熟知し、考慮する必要がある新しい概念や詳細がたくさんあります。コンテナやオーケストレータが加われば、多くの開発者がこの新しい世界に対応するために苦労している理由が明確になります。開発者は、多くの可動パーツを備えた分散システムの観点から、そのアプリケーションについて考える必要があります。その結果、ちょっと例示すると、resiliency（復元性、回復力）、idempotency（冪等性）、eventual consistency（結果整合性）などの課題は、今や考慮すべき重要な側面です。
さらに、マイクロサービスの設計とベストプラクティスの最新動向を踏まえて、アプリケーションやサービスを動作させるためにコンテナやオーケストレーターについて学ぶ必要もあります。Kubernetes、Mesos/Marathon、Docker Swarmなどの最新のクラスター管理とコンテナオーケストレーションソリューションは、ネットワーク化やサービス発見などを単純化します。これらは時間をかけて改良されているとはいえ、これらはいまだインフラストラクチャーの活動です。これらのツールとテクノロジは、サービスのデプロイと接続のプロセスを処理し、障害発生時にサービスの継続実行を保証することを主目的としています。これらの側面は、実際のサービスそのものよりもサービスをホストするために使われるインフラストラクチャとより関連しています。開発者は、オーケストレータの仕組みをしっかりと理解している必要があります。また、サービスを構築する際には、そのことを考慮する必要があります。プログラミングモデルとインフラストラクチャは絡み合っており、明確に分かれていませんので、開発者はサービスを機能させるために基礎となるインフラストラクチャを理解する必要があります。
開発者は実際にサービスをデプロイする実行環境を処理するために必要なコードではなく、ロジックの開発に集中したいと考えている、とお客様やオープンソースコミュニティか何度も伺いましたが、それはどういうことでしょうか。
より複雑なサービスのデプロイや管理で非常にオーバーヘッドがかかりすぎる場合、とりわけ、開発者は（別のサービスに接続するために必要な唯一のもの）APIに注力し、リアクティブなスタイルでサービスを開発し、場合によってはfunction（関数）を使ってシンプルな操作を実行したいのです。
また、OSSスタック上にプラットフォームを構築して、ベンダーのロックインを回避し、パブリッククラウドをオンプレミスインフラストラクチャと組み合わせて使用するハイブリッドシナリオを可能にすることも、開発者の間で強く求められています。
API-firstなマイクロサービスプラットフォームの開発の主な動機となったのは、顧客および開発者からの沢山のご意見であり、以下の主要な要求事項に基づきます。
- 開発者はコードを書くことだけに注力できる（API-firstアプローチ）
- これは、伝統的なRESTベースのプログラミングモデルと最新のリアクティブイベント駆動モデルを組み合わせである
- 従来のコンテナベースのマイクロサービスをサーバレス/FaaSインフラストラクチャと統合し、柔軟性を高め、開発者が適切なツールを選択できるようにする
- 「外部」サービスを簡単に利用することで、開発者がクラウドサービスなどを活用して、レガシーまたはサードパーティのサービスに簡単に接続できる
The Platform Approach
そんなわけで、プラットフォームがどのようなもので、どのコンポーネントを使っているのか、その詳細に入る前に、このプラットフォームを構築するための基本原則を見てみましょう。- Opinionated and open: 開発者が簡単かつ速やかに生産性を上げるだけでなく、スタックの深耕や、モジュール交換のオプションも提供
- クラウドベンダー非依存：新しいアプリケーション開発スタックでプラットフォームが最適に機能するにもかかわらず、任意のクラウドインフラストラクチャ上でインストールできる必要がある
Meet the New Application Development Stack - Managed Kubernetes, Serverless, Registry, CI/CD, Java
https://blogs.oracle.com/developers/meet-the-new-application-development-stack-kubernetes-serverless-registry-cicd-java - オープンソースベースのスタック：私たちはOSSを強く信じている、我々のスタックは、人気のあるOSSコンポーネント上で構築されており、OSSとして利用可能。
The Platform Architecture
Figure 1は我々のプラットフォームのハイレベル・アーキテクチャと各コンポーネントの機能を示したものです。
API Registry:
APIレジストリは、クラスタ内で利用可能なAPIに関するすべての情報を格納します。公開したサービスを他の開発者にとって使いやすくするために、開発者はAPIを公開できます。開発者は、特定のサービスまたは（Fn Projectのようなserverlessフレームワークがクラスタにインストールされている場合）Functionを検索できます。Fn Project実際のサービスがまだ準備されていない、、またはデプロイされていない場合でも、開発者はモックサービスに対してAPIをテストできます。クラスタ内のマイクロサービスまたはFunctionに接続するために、開発者はさまざまな言語でクライアントライブラリを生成できます。クライアントライブラリはソースコードに統合され、サービスの呼び出しに使用されます。実行時にクラスタ内のエンドポイントを常に自動的に検出するので、サービスのライフサイクルで変化の可能性のあるIPアドレスやポート番号などのインフラストラクチャの詳細に対処する必要はありません。将来のバージョンでは、開発者がAPIレジストリにセキュリティとルーティングのポリシーを直接設定する機能を追加する予定です。
http://fnproject.io/
Event Manager:
Event Manager（イベントマネージャー）により、サービスおよびFunctionが、他のサービスおよびFunctionがサブスクライブ可能なイベントを公開できます。これは、EventProviderがイベントを発行し、コンシューマ（Functionまたはマイクロサービスのいずれか）がそれらを消費するという、イベント駆動型プログラミングモデルを可能にする主要コンポーネントです。EventManagerを使えば、開発者は、従来のRESTベースのプログラミングモデルと、リアクティブ/イベント駆動モデルの両方を、統合されたプラットフォームで組み合わせることができ、ワークフローやツールに関して一貫したエクスペリエンスを提供します。Service Broker:
主要なクラウドベンダーに移行する過程で、Kubernetesクラスタ上でサービスを実行、運用するのではなく、マネージド・クラウドサービスを使用することを多くのお客様が選択していることがわかりました。これの一般的な例はRedisキャッシュであり、ほぼすべての主要なクラウドプロバイダーがマネージド・サービスとして提供しています。その結果、マイクロサービスベースのアプリケーションは、開発チームによって開発されたサービスだけでなく、マネージド・クラウドサービスから構成されることが非常に一般的です。Kubernetesは、Kubernetesクラスター内で外部サービスを利用できるようにする、service catalog（サービスカタログ）という素晴らしい新機能を導入しました。そのため、初期設計を拡張し、外部サービスへのアクセスを構成するだけでなく、ユーザーサービスをAPIレジストリに登録することで、開発者がマネージド・サービスと一緒にそれらを簡単に使用できるようにしました。このように、クラウドベンダーが提供するような外部サービスは、クラスタ内の他のサービスと同様に、同じワークフローを使用する開発者と共に使用できます。利用したいAPIを特定し、クライアントライブラリを生成し、サービスとの実際の通信を処理します。
Service Brokerは、既存のインフラストラクチャの最新化に携わる開発者をサポートします。例えば、既存のコードをクラスタに展開できるコンテナにパッケージングできます。モダナイズできない既存アプリケーションが存在する場合のソリューションも検討しています。この場合、Service Brokerを使用してAPIレジストリ内の一連のAPIを公開するプロキシサービスを「公開」することで、クラスタ内の他のマイクロサービスを利用するのと同様に外部/レガシーシステムを利用できます。
Kubernetes and Istio:
我々のプラットフォームの基礎としてKubernetesを選択したのは、マイクロサービスを実行するための最も一般的なコンテナ管理プラットフォームとしてKubernetesが台頭しているためです。さらに、Kubernetes周辺のコミュニティが急速に成長しており、すべての主要クラウドベンダーでKubernetesがサポートされていることももう一つの重要な要素です。先に述べたように、主たる目標の1つは開発者にとっての複雑性を軽減することです。複数のマイクロサービス間の通信の管理は困難な作業です。 このため、Istioをサービスメッシュとしてプラットフォームに追加する必要があると判断しました。Istioを使えば、監視、診断、複雑なルーティング、復元力、ポリシーを無料で享受できます。Istioのおかげで、これらの機能を実装する開発者の大きな負担がなくなります。 Istioを使えば、こうした機能をプラットフォームレベルで利用可能です。
Monitoring
監視は、マイクロサービスプラットフォームの重要なコンポーネントです。潜在的に多くの可動部分があるならば、システムは実行時にその動作を監視する方法が必要です。当社のマイクロサービスプラットフォームでは、我々のプラットフォームの他のコンポーネントと同様、Prometheus、Zipkin/Jaeger、Grafana、Vizsceralなど、統合されかつ実戦で叩かれた技術をベースにした、すぐに使える監視ソリューションを提供することを選択しました。API-firstアプローチを監視にも推し進めるべく、我々の監視ソリューションでは、マイクロサービスが（Vizsceralを使って）互いにどのように接続されているか、それらをまたがって流れるデータを開発者が確認できます。将来的には、どのAPIが利用されてきたかを示すことも考えています。これにより、開発者は、Zipkin/Jaegerの分散トラッキング情報を使って、潜在的なレイテンシの問題を調査したり、サービスの効率を向上したりできます。将来、他のサービスとの統合を追加する予定です。例えば、マイクロサービス間のリクエストをJVM内のデータ構造と相関させる機能を追加することで、開発者は各リクエストに対してデータがどのように処理されているかを追うことで、複数のマイクロサービス全体（の性能）を最適化できます。
What’s Next?
このエントリは、- 新しいプラットフォームの初期の概要
- 私たちのモチベーションに対する洞察
- 使用した設計ガイドライン
を示したものです。私たちは、2018年初頭の初期OSSリリースに近づくにつれて、プラットフォームのさまざまな側面をより深く理解してもらうためのブログを投稿する予定です。それまでの間、以下のJavaOneセッションをご覧ください。
このトピックの背景については、Getting Started with Microservicesシリーズの他のブログ記事を参照してください。Part 1では、マイクロサービスの主な利点のいくつかについて説明すると共に、マイクロサービスを扱う際に考慮すべきいくつかの領域に触れています。
Getting Started with Microservices, Part 1: Advantages and ConsiderationsPart 2では、コンテナがマイクロサービスの話にどのように適合しているかを検討します。
https://blogs.oracle.com/developers/getting-started-with-microservices-part-one
Getting Started with Microservices, Part 2: Containers and MicroservicesPart 3では、マイクロサービスを実装するための基本的なパターンとベストプラクティスについて説明します。
https://blogs.oracle.com/developers/getting-started-with-microservices-part-two
Getting Started with Microservices, Part 3: Basic Patterns and Best PracticesPart 4では、コンテナ化されたマイクロサービスでDevOpsの原則とプラクティスを使用する際の重要な側面について検討します。
https://blogs.oracle.com/developers/getting-started-with-microservices-part-three
Getting Started with Microservices, Part 4: Fundamentals of DevOps with Containerized Microservices
https://blogs.oracle.com/developers/getting-started-with-microservices-part-four
Related content
- Meet the New Application Development Stack - Managed Kubernetes, Serverless, Registry, CI/CD, Java
https://blogs.oracle.com/developers/meet-the-new-application-development-stack-kubernetes-serverless-registry-cicd-java - Getting Started with Microservices, Part 1: Advantages and Considerations
https://blogs.oracle.com/developers/getting-started-with-microservices-part-one - Get a highly available Kubernetes Cluster on Oracle Cloud Infrastructure in minutes
https://blogs.oracle.com/developers/get-a-highly-available-kubernetes-cluster-on-oracle-cloud-infrastructure-in-minutes
https://orablogs-jp.blogspot.com/2017/09/get-highly-available-kubernetes-cluster.html