BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル マイクロサービスの内と外を裏返しにする

マイクロサービスの内と外を裏返しにする

キーポイント

  • The idea of "unbundling" the database and replacing it with an event log such as Apache Kafka is appealing, but in practice fails to realize its goals. Rather than replacing a fundamental component such as the database, a better approach is to complement the database with Apache Kafka through a connecting tissue such as Debezium.
  • To future-proof your microservices, you have to design them with inbound and outbound APIs where the data flows through and a meta API that describes these APIs.
  • Outbound events are turning into the preferred integration method for modern platforms such as cloud services, data sources, and even file systems. Custom-built microservices are not an exception, and emitting state change or domain events is the most natural way for modern microservices to fit uniformly among other event-driven systems. 
  • The responsibilities and the importance of meta APIs are growing as their scope changes from describing synchronous APIs to also including asynchronous APIs. The meta APIs are expanding toward enabling faster development cycles by ensuring safe schema evolution through compatibility checks, notifications for updates, code generation for bindings, test simulations, and so forth.
  • Recent drivers such as cloud adoption and microservices architecture have accelerated the consolidation and community-driven standardization of open-source projects around Apache Kafka.
     

原文(投稿日:2021/08/03)へのリンク

リレーショナルデータベースからイミュータブル (不変) なイベントとマテリアライズドビューのログに移行することで、多大なメリットが得られます。

この急進的なアイデアは、Martin Kleppmann氏が「Turning the database inside-out. (データベースを内と外を裏返しにする)」という講演で非常によく表現されています。リレーショナルデータベースの内部動作に関する彼の説明、およびそのようなデータベースアーキテクチャで作成されたアプリケーションの制限により、データベースとイベントログに対する見方が不可逆的に変わることでしょう。

データベースの制限とイベントログの利点について概説したことに同意しますが、データベースをイベントログに置き換えることの実用性については確信していません。データベースを裏返しにするために使用されるのと同じ設計原則を、代わりに、マイクロサービスが変更を裏返しにストリーミングすることを保証するためにサービス設計レベルをより高く適用する必要があると思います。

そのひねりを加えて、サービス内で、従来のデータベースを最適なものとして使用し続けることができます。つまり、ミュータブル (可変) な状態を効率的に処理し、イベントログを使用してサービス間で確実に変更を伝播することもできます。

データベースとイベントログ間を結合剤 (connecting tissue) として機能できるDebeziumなどのフレームワークの助けを借りて、実績のある使い慣れたデータベーステクノロジーと、Red HatのマネージドApache Kafkaサービスなどの最新のイベントログを同時に利用することで利点が得られます。

この裏返しの考え方には、マイクロサービスでアウトバウンドAPIを提供して、関連するすべての状態変化とドメインイベントをサービス内から外の世界にストリーミングすることに慎重に焦点を当てることが求められます。

マイクロサービスの動きとイベント駆動型を融合する新たなトレンドを、私はマイクロサービスデータを裏返し (inside-out) にすることと呼んでいます。

マイクロサービスAPIの種類

このアイデアに基づいて、マイクロサービスがプロバイド (生成) およびコンシューム (消費) するさまざまなAPIの種類の観点からそれらを調べます。

マイクロサービスを説明する一般的な方法は、独立してデプロイされたコンポーネントを、ビジネスドメインを中心に構築し、データを所有し、APIを介して公開することです。これは、上記のビデオでデータベースの使用方法が説明されることと非常によく似ています。つまり、出入りする単一のAPIを備えたブラックボックスです。

マイクロサービスのインバウンドからアウトバウンドAPIに流れるデータ

マイクロサービスについて考えるより良い方法は、すべてのマイクロサービスが、データフローを介し、メタAPIがインバウンドAPIとアウトバウンドAPIで定義されたAPIで構成されていることだと思います。インバウンドAPIは今日よく知られていますが、アウトバウンドAPIはあまり使用されておらず、メタAPIの責務はさまざまなツールや急増しているマイクロサービステクノロジーに分散しています。裏返しアプローチを機能させるには、アウトバウンドとメタAPIを第一級のマイクロサービスで構成し、これらの領域のツールとプラクティスを改善する必要があります。

インバウンドAPI

インバウンドAPIは、今日すべてのマイクロサービスがサービスエンドポイントの形で持っているものです。これらのAPIはアウトサイドイン (outside-in) であり、外部システムがコマンドやクエリを介して直接またはイベントを介して間接的にサービスと対話できるようにします。

今日のマイクロサービスの標準であるInbound APIs

実装に関しては、これらは通常、ロードバランサ (負荷分散) ゲートウェイが前面にある同期操作の変更または読み取り専用操作を提供するRESTベースのAPIです。これらは、非同期コマンドベースの相互作用としてキューまたはイベントベースの相互作用のトピックとして実装することもできます。これらのAPIの責務とガバナンスは十分に理解されており、今日のマイクロサービスAPIのランドスケープの大部分を形成しています。

アウトバウンドAPI

私がアウトバウンドAPIと呼んでいるのは、サービス内から発生し、外部のサービスやシステムに到達する相互作用です。これらの大部分は、サービスによって開始され、他の誰かが所有する依存サービスをターゲットとしたクエリやコマンドです。私がさらにこのカテゴリに分類しているのはサービス内から発生するアウトバウンドイベントです。アウトバウンドイベントは、既存および将来の受信者に関して具体的な知識なしでサービスによって定義され、特定のエンドポイントをターゲットとするクエリやコマンドとは異なります。APIの間接的な性質に関係なく、これらのイベントはサービス内 (通常はインバウンドの相互作用によって引き起こされる) で発生する重要な変更に対して予測可能かつ確実に生成されることが期待されます。

今日、アウトバウンドイベントはしばしば後付けです。それらは、それらに依存する特定のコンシューマ (消費者) のニーズに合わせて作成されるか、サービスの所有者ではなくデータ複製を担当する他のチームによって、サービスライフサイクルの後半で追加されます。どちらの場合も、アウトバウンドイベントのユースケースで可能なことは低いままであり、その潜在力を弱めています。

アウトバウンドイベントの課題は、サービス内で発生する変更に対して、統一された信頼性の高い通知メカニズムを実装することです。このアプローチをすべてのマイクロサービスおよびあらゆる種類のデータベースに均一に適用するには、ここでのツールは、邪魔にならず、開発者にとって使いやすいものでなければなりません。このパターンをサポートする優れたフレームワークがなく、実証済みのパターン、プラクティス、および標準がないことは、一般的なトップレベルのマイクロサービスの構造としてのアウトバウンドイベントの採用を妨げる障害です。

変更データキャプチャ (change data capture) を通じて実装されたアウトバウンドイベント

アウトバウンドイベントを実装するには、データベースを更新するロジックにイベントをメッセージングシステムにパブリッシュするロジックをアプリケーションコードに含めることができますが、これはよく知られているdual-write problem (デュアルライト問題) につながります。あるいは、従来のデータベースをイベントログに置き換えるか、専用のイベントソーシングプラットフォームを使用することもできます。しかし、プロジェクトで最も価値のあるリソースが人と実績のあるツールと実践であると考えた場合、データベースなどの基本的なコンポーネントを別のものに置き換えることは大きな影響を及ぼします。より良いアプローチは、リレーショナルデータベースと何十年にもわたってうまく機能してきたすべての周辺ツールとプラクティスを使い続け、データベースをDebezium (免責事項: 私はRed HatのDebeziumのプロダクトマネージャであるため、私はこれについては偏っています) などの結合剤で補完することです。

アウトバウンドイベントの最適な実装アプローチは、単一のトランザクションを使用して、サービスロジックによって指定された通常のデータベース更新を実行し、同じデータベース内の特定のアウトボックス (送信トレイ) テーブルにメッセージを挿入するアウトボックスパターンであると思います。トランザクションがデータベースのトランザクションログに書き込まれると、Debeziumはログから送信トレイメッセージを取得し、Apache Kafkaに送信します。これには「独自の書き込みを読み取る」セマンティクスなどの優れたプロパティがあります。このセマンティクスでは、サービスへの後続のクエリが新しく永続化されたレコードを返すと同時に、Apache Kafkaを介して信頼性の高い非同期の変更の伝播を取得します。Debeziumは、データベースのトランザクションログから変更を選択的にキャプチャし、変換し、サービスのアウトバウンドイベントインターフェイスとして機能する統一された方法でKafkaにパブリッシュできます。Debeziumは、ライブラリとしてJavaアプリケーションランタイムに組み込むことも、サイドカーとして分離することもできます。これは、レガシーサービスであるかゼロ (scratch) から作成されたものであるかに関係なく、サービスに追加するプラグアンドプレイコンポーネントです。これは、どのサービスにも不足している構成ベースのアウトバウンドイベントAPIです。

メタAPI

今日、メタAPIはインバウンドAPIとアウトバウンドAPIを記述し、それらのガバナンス、検出、および消費を可能にします。これらは、特定のテクノロジーに関連するサイロ化されたツールに実装されています。私の定義では、APIポータルに公開されたRESTエンドポイントのOpenAPI定義はメタAPIの例です。スキーマレジストリに公開されるメッセージングトピックのAsyncAPI定義も、メタAPIの例です。Debeziumがデータベーススキーマ変更イベント (データ変更イベントとは異なります) をパブリッシュするスキーマ変更トピックは、メタAPIの例です。他のツールには、データ構造やすべてメタAPIに分類できる提供しているAPIを記述するさまざまな機能があります。したがって、私の定義では、メタAPIとは、さまざまな利害関係者 (ステークホルダ) がサービスを操作し、他のシステムがインバウンドとアウトバウンドAPIを使用できるようにするすべてのアーティファクトです。

進化するメタAPIの責務

マイクロサービスの基本的な設計原則の1つは、それらを個別に更新およびデプロイできるようにすることです。しかし、今日でも、APIの変更を伴うアップグレードについては、サービス所有者間でかなりの量の調整が必要です。サービス所有者は、依存サービスからの更新をサブスクライブし、タイムリーな変更を可能にするために、より優れたメタAPIツールを必要としています。敏捷性 (agility) を高めるためには、メタAPIツールを開発および運用アクティビティにさらに深く統合される必要があります。今日のメタAPIツールは、サイロ化され、受動的であり、テクノロジースタック全体で異なっています。代わりに、メタツールは、イベント駆動アプローチに向けたサービスの相互作用が変化する性質を反映し、開発チームと運用チームの日常的なタスクの一部を自動化する上でより積極的な役割を果たす必要があります。

新たなトレンド

アウトバウンドイベントの台頭

アウトバウンドイベントは、ほとんどの最新プラットフォームで推奨される統合方法としてすでに存在しています。ほとんどのクラウドサービスはイベントを発行します。多くのデータソース (Cockroachチェンジフィード、MongoDBチェンジストリームなど) やファイルシステム (Ceph通知など) でさえ、状態変更イベントを発行できます。ここでは、カスタムビルドのマイクロサービスも例外ではありません。状態変化またはドメインイベントを発行することは、同じツールと実践の恩恵を受けるために、接続されているイベント駆動システム間で最新のマイクロサービスを均一に適合させるための最も自然な方法です。

アウトバウンドイベントは、多くの理由でトップレベルのマイクロサービス設計構造になるはずです。アウトバウンドイベントを使用してサービスを設計すると、アプリケーションのモダナイゼーションプロセス中にデータを複製するのに役立ちます。アウトバウンドイベントは、アウトボックスパターンと、非ブロッキングなSaga実装を使用して複数のサービスにまたがる複雑なビジネストランザクションを通じて、エレガントなサービス間相互作用を実装するためのイネーブラでもあります。

アウトバウンドイベントは、データコンシューマ (消費者) を念頭に置いてサービスが設計されている Distributed Data Mesh (分散データメッシュ) アーキテクチャにうまく適合します。データメッシュは、データがイノベーションを促進するためには、データをプロダクトとして提供する責任があるドメインデータ所有者間でその所有権を統合する必要があると主張しています。つまり、ETLプロセスを通じてすべてのマイクロサービスからデータを複製する一元化されたデータエンジニアリングチームを持つよりも、マイクロサービスを開発者やデータエンジニアと共同で所有し、最初にデータを利用できるようにサービス設計する方がよいでしょう。Debezium、Apache Kafka、およびSchema Registryを介したリアルタイムデータストリーミングを使用したアウトバウンドイベントよりも、これを行うためのより良い方法があるでしょうか?

要約すると、アウトバウンドイベントは、マイクロサービスを「すべてのプログラムの出力がまだ未知のプログラムの入力になる」というUnix哲学と整合させます。サービスの将来性を保証するには、データがインバウンドからアウトバウンドAPIに流れるようにサービスを設計する必要があります。これにより、最新のイベント指向ツールとパターンを使用してすべてのサービスを均一に開発および運用でき、イベントを通じて公開されるデータの未知の将来の使用に解き放ちます。

メタAPIツールの収束

イベント駆動アーキテクチャの採用が増え、サービスの進化のペースが速くなるにつれて、メタAPIの責務と重要性も高まっています。メタAPIツールの範囲は、いまや同期APIに限定されなくなり非同期APIも含まれています。メタAPIは、互換性チェック、更新の通知、バインディングコードの生成、テストシミュレーションなどを通じて安全なスキーマの進化を保証することにより、より高速な開発サイクルを可能にする方向へと拡大しています。

サービスのコンシューマ (消費者) として、既存のエンドポイントとデータ形式、API互換性ルール、制限、およびサービスが1か所で準拠するSLAを見つけたいと思います。同時に、今後の変更、非推奨、APIの更新、またはサービスが提供する予定の新しいAPIについて、私が興味を持つ可能性のある通知を受け取りたいと思います。それだけでなく、開発者はコードをますます速く出荷することが求められており、最新のAPIツールはスキーマとイベント構造の発見のプロセスを自動化できます。スキーマが検出されレジストリに追加されると、開発者は自分の言語のコードバインディングをすばやく生成し、IDEでの開発を開始できます。次に、他のツールがメタAPI定義を使用してテストとモックを生成し、MicrocksPostmanなどのダミーイベントを発行して負荷をシミュレートできます。実行時に、メタAPIで利用可能なコンテキスト情報により、アプリケーションを実行しているプラ​​ットフォームで接続資格情報 (クレデンシャル) を挿入したり、監視ツールに登録したりすることができます。

全体として、メタAPIの役割は、サービスオーナ間の調整アクティビティの一部を自動化し、開発者の生産性を高め、運用チームのタスクを自動化することで、非同期相互作用エコシステムでより積極的な役割を果たすように進化しています。そしてそれを実現するには、APIメタデータ、コード生成、テストスティミュレーション、環境管理を含むさまざまなツールを統合、標準化、統合する必要があります。

イベント駆動分野の標準化

イベント駆動アーキテクチャ (EDA) には長い歴史がありますが、クラウドの採用、マイクロサービスアーキテクチャ、変化のペースの速さなどの最近の推進要因により、EDAの関連性と採用が増幅されています。プラットフォーム分野のKubernetesとそのエコシステムで発生する統合と標準化と同様に、Apache Kafka周辺のイベント駆動分野で発生する統合とコミュニティ主導の標準化があります。いくつかの具体的な例を見てみましょう。

Apache Kafka は、AWS S3がオブジェクトストアであり、Kubernetesがコンテナオーケストレーションであるのと同じように、イベントストリーミングのデファクトスタンダードプラットフォームになる段階に達しました。Kafkaには、その背後にある巨大なコミュニティ、ツールとサービスの大規模なオープンソースエコシステム、そしておそらく現代のデジタル組織によるイベントインフラストラクチャとしての最大の採用があります。あらゆる種類のセルフホストのKafka環境、ブティック企業、クラウドプロバイダ、そして最近ではRed Hatによるマネージドサービスもあります。(Apache Kafkaの Red Hat OpenShift Streams は、私が関わっているマネージドKafkaサービスであり、フィードバックをお待ちしています。)

ログベースのメッセージングのAPIとしてのKafkaは非常に普及しているため、Pulsar、Red Panda、Azure Event HubsなどのKafka以外のプロジェクトでも互換性があります。今日のKafkaは、サードパーティのアーキテクチャに依存しているだけではありません。Kafkaは、サービスの設計と実装の方法に影響を与え、システムのスケーリングと高可用性の実現方法を決定し、ユーザがデータをリアルタイムでコンシューム (消費) する方法を推進します。しかし、Kafkaだけでは、podのない裸のKubernetesプラットフォームのようなものです。Kafkaエコシステムの他に何が必須の補完であり、デファクトスタンダードにもなりつつあるかを見てみましょう。

Schema Registry は、同期APIのためのAPIマネージャと同様、非同期APIの場合も重要です。多くのストリーミングシナリオでは、イベントペイロードには、プロデューサとコンシューマの両方が検証して理解する必要のある構造化データが含まれています。スキーマレジストリは、スキーマドキュメントの中央リポジトリと共通のガバナンスフレームワークを提供して、アプリケーションがこれらの契約に準拠できるようにします。現在、Red HatのApicurio、AivenのKarapace、Cloudera、Lenses、Confluent、Azure、AWSなどのレジストリがあります。スキーマリポジトリの人気が高まり、スキーマ管理に関する機能とプラクティスが統合されている一方で、同時にライセンス制限も異なります。それだけでなく、スキーマレジストリは、Kafkaシリアライザ/デシリアライザ (SerDes)、コンバータ、およびその他のクライアント依存の形でクライアントアプリケーションにリークする傾向があります。したがって、実装を交換できるオープンでベンダー中立な標準の必要性は、ここしばらくで明らかになりました。そして、良いニュースは、Schema Registry API標準の提案がCNCFに存在し、ApicurioAzure Schema Registryなどのいくつかのレジストリがすでにそれに準拠し始めていることです。オープンソースのKafka APIをオープンソースのサービスレジストリAPIと一般的なガバナンス手法で補完することは正しいと感じており、この分野での採用と統合が拡大し、メタAPIの概念全体がイベント駆動アーキテクチャの基礎になることを期待しています。

EDAと同様に、Change Data Capture (CDC) の概念は新しいものではありません。しかし、イベント駆動システムを取り巻く最近の推進力と、リアルタイムデータへのアクセスに対する需要の高まりにより、トランザクションログ駆動のイベントストリーミングツールの勢いが増しています。今日、データをポイントツーポイントで複製するために同じトランザクションログの概念に依存する多くのクローズドソースのポイントアンドクリックツール (Striim、HVR、Qlikなど) があります。AWS DMS、Oracle GoldenGate Cloud Service、Google Datastreamなどのクラウドサービスがあり、データをサービスにストリーミングします (ただし、反対方向にはストリーミングしません)。変更をストリーミングするデータベースやKey-Valueストアも多数あります。さまざまなベンダーが従うことができ、ダウンストリームの変更イベントのコンシューマ (消費者) が信頼できる、オープンソースでベンダー中立なCDC標準の必要性が高まっています。

成功には、そのような標準はベンダー中立な基盤で管理され、より大きな関連エコシステムの一部である必要があります。今日存在する最も近いものはCNCFであり、これにはすでにAsyncAPI、CloudEvents、Schema Registry、および Serverless Workflow 仕様が含まれています。今日、CDC分野の主要なオープンソースプロジェクトはDebeziumです。Debeziumは主要企業で使用されており、Google、Heroku、Confluent、Aiven、Red Hatのクラウドサービスに組み込まれ、複数のオープンソースプロジェクトに組み込まれ、これまで知らなかった多くの独自のソリューションでも使用されています。このドメインで標準を探している場合、最も近いデファクトスタンダードはDebeziumです。

明確にすると、CDC標準は、データソースが変更を発行するためのAPIを意味するものではありません。私としては、データベーストランザクションログをイベントに変換するときに従うべきデータソースとDebeziumなどの結合剤の標準的な規則を意味します。これには、データマッピング (データベースフィールドタイプからJSON/Avroタイプへ)、データ構造 (DebeziumのBefore/Afterメッセージ構造など)、スナップショット、テーブルのパーティションをトピックに、プライマリキーをトピックにパーティション化、トランザクション境界インジケーターなどを含みます。CDCに集中している場合は、Debeziumを使用すると、データベーストランザクションログエントリからデータソース間で均一なApache Kafkaイベントにマッピングする一貫したセマンティクスが保証されます。

Apache Kafkaエコシステムを取り巻く仕様と実装

CNCFのイベント駆動分野から、勢いを増している既存の仕様がすでにいくつかあります。

  • AsyncAPIは、最近CNCFに参加したOpenAPIのイベント駆動アプリケーションに相当します。さまざまなチームやツール間で一貫性とガバナンスを維持するために、イベント駆動システムを文書化するための仕様を提供します。
  • CloudEvents (CNCFの一部でもあります) は、必須のメタデータ情報を標準エンベロープと呼ばれるものに指定することにより、メタデータの課題を取り除くことを目的としています。また、相互運用性を簡素化し、複数のプロトコルのための複数のプログラミング言語のライブラリも提供します。
  • OpenTelemetry (別のCNCFサンドボックスプロジェクト) は、複数のアプリケーションを介したイベントのエンドツーエンドパスを明らかにするトレース情報の生成と管理を標準化します。
  • CNCF Serverless Workflowは、非同期のステートレスおよびステートフル相互作用を調整するためのベンダー中立の仕様です。
  • 上で説明したCNCFでのサービスレジストリの提案。

私達が、これを標準化、コミュニティの採用、または他の何と呼んでも、イベント駆動構造に関する統合プロセスと、デファクトスタンダードとしてのいくつかのオープンソースプロジェクトの台頭を否定することはできません。

要約

マイクロサービスは、ビジネスドメインに属するデータのカプセル化と、可能な限り少数のAPIの公開に重点を置いています。しかしそれは変化しています。サービスから出て行くデータは、サービスに入るデータと同じくらい重要です。マイクロサービスでデータを公開することは、もはや後から考えることはできません。高度に疎結合されたマイクロサービスにラップされた、サイロ化されたアクセスできないデータの価値は限られています。データの新しいユーザや発見可能で理解可能なリアルタイムデータへのアクセスを要求する可能性のある未知のユーザがいます。これらのユーザのニーズを満たすために、マイクロサービスはデータを裏返しにし、データを出力できるアウトバウンドAPIと、データのコンシューム (消費) をセルフサービスアクティビティにするメタAPIを使用して設計する必要があります。Apache Kafka、Debezium、Apicurioなどのプロジェクトは、このアーキテクチャを自然に実現するものであり、さまざまなオープンソースの非同期仕様の助けを借りて、将来を見据えたイベント駆動マイクロサービスを実装するための事実上の選択肢になりつつあります。

著者について

Bilgin Ibryam氏 は、Red Hatのプロダクトマネージャであり、元アーキテクトであり、Apache Software Foundationのコミッタであり、メンバーです。彼はオープンソースのエバンジェリストであり、定期的なブロガであり、スピーカであり、書籍 Kubernetes Patterns と Camel Design Patterns の著者です。Bilginの現在の仕事は、分散システム、イベント駆動アーキテクチャ、および反復可能なクラウドネイティブアプリケーション開発パターンと実践に焦点を当てています。同トピックに関する今後の更新については、@bibryam をフォローしてください。

この記事に星をつける

おすすめ度
スタイル

BT