データの二分法: データとサービスの関係を再考する

こんにちは、みんな！ 素晴らしいニュースです。OTUS は XNUMX 月にコースを再開します 「ソフトウェアアーキテクト」これに関連して、私たちは伝統的に役立つ資料を皆さんと共有しています。

何の脈絡もなくこのマイクロサービス全体に出会ったとしても、少し奇妙だと思うのも無理はありません。 アプリケーションをネットワークで接続されたフラグメントに分割するということは、必然的に、結果として得られる分散システムに複雑なフォールト トレランス モードを追加することを意味します。

このアプローチには、サービスを多数の独立したサービスに分割することが含まれますが、最終的な目標は、単にそれらのサービスを異なるマシン上で実行するだけではありません。 ここで私たちは外の世界との相互作用について話していますが、それも本質的には分散しています。 技術的な意味ではなく、多くの人々、チーム、プログラムで構成され、これらの各部分が何らかの形でその役割を果たす必要があるエコシステムという意味です。

たとえば、企業は、集合的に何らかの目標の達成に貢献する分散システムの集合体です。 私たちは何十年にもわたってこの事実を無視し、独自の個別の目標に焦点を当てながら、ファイルを FTP 送信したり、エンタープライズ統合ツールを使用したりして統合を達成しようとしました。 しかし、サービスの登場によりすべてが変わりました。 サービスは、私たちが地平線の向こう側に目を向け、相互に依存し、連携して動作するプログラムの世界を見るのに役立ちました。 しかし、うまく仕事を進めるためには、XNUMX つの根本的に異なる世界を認識し、設計する必要があります。XNUMX つは、私たちが他の多くのサービスのエコシステムの中で暮らす外部の世界、もう XNUMX つは私たちが単独で統治する個人的な内部の世界です。

この配布ワールドは、私たちが育って慣れ親しんだ世界とは異なります。 伝統的なモノリシックアーキテクチャを構築する原則は批判に耐えられません。 したがって、これらのシステムを正しく構築することは、優れたホワイトボード図や優れた概念実証を作成するだけでは不十分です。 重要なのは、このようなシステムが長期間にわたって正常に動作することを保証することです。 幸いなことに、このサービスはかなり前から存在していますが、見た目は異なります。 SOA レッスン Docker、Kubernetes、そして少しみすぼらしい流行に敏感なひげで味付けされていても、依然として関連性があります。

そこで今日は、ルールがどのように変わったのか、サービスとサービス間で受け渡しされるデータへのアプローチ方法を再考する必要がある理由、そのためにまったく異なるツールが必要になる理由を見ていきます。

カプセル化が常に味方になるわけではない

マイクロサービスは互いに独立して動作できます。 この特性こそがそれらに最大の価値をもたらします。 これと同じ特性により、サービスの拡張と成長が可能になります。 それは、数千のユーザーやペタバイトのデータに拡張するという意味ではなく (ただし、それらも役立ちます)、チームや組織が継続的に成長するにつれて人員という観点から拡張するという意味です。

しかし、独立は諸刃の剣でもあります。 つまり、サービス自体が簡単かつ自然に実行できるのです。 しかし、ある機能が別のサービスの使用を必要とするサービス内に実装されている場合、最終的には両方のサービスをほぼ同時に変更する必要があります。 モノリスではこれは簡単で、変更を加えてリリースに送信するだけですが、独立したサービスを同期する場合にはさらに問題が発生します。 チームとリリース サイクル間の調整は俊敏性を破壊します。

標準的なアプローチの一環として、煩わしいエンドツーエンドの変更を回避し、サービス間で機能を明確に分割するだけです。 ここではシングル サインオン サービスが良い例となります。 他のサービスと区別する明確に定義された役割があります。 この明確な分離は、周囲のサービスに対する需要が急速に変化する世界において、シングル サインオン サービスが変わる可能性は低いことを意味します。 それは厳密に限定されたコンテキスト内に存在します。

問題は、現実の世界では、ビジネス サービスが常に同じ純粋な役割の分離を維持できないことです。 たとえば、同じビジネス サービスは、他の同様のサービスからのデータとより広範囲に連携します。 オンライン小売業に携わっている場合、注文フロー、製品カタログ、ユーザー情報の処理が多くのサービスの要件になります。 各サービスが動作するには、このデータにアクセスする必要があります。

ほとんどのビジネス サービスは同じデータ ストリームを共有するため、それらの作業は常に絡み合っています。

したがって、話すべき重要な点に到達します。 サービスは、主に分離して動作するインフラストラクチャ コンポーネントではうまく機能しますが、ほとんどのビジネス サービスは最終的にはより密接に絡み合います。

データの二分法

サービス指向のアプローチはすでに存在しているかもしれませんが、サービス間で大量のデータを共有する方法についての洞察がまだ不足しています。

主な問題は、データとサービスが切り離せないことです。 一方で、カプセル化はデータを隠すことを奨励し、サービスを相互に分離し、サービスの成長とさらなる変更を促進します。 一方で、共有データも他のデータと同様に、自由に分割して征服できる必要があります。 他の情報システムと同様に、すぐに自由に作業を開始できることがポイントです。

ただし、情報システムはカプセル化とはほとんど関係がありません。 実際には全く逆です。 データベースは、保存されているデータへのアクセスを提供するためにあらゆる手段を講じます。 これらには、必要に応じてデータを変更できる強力な宣言型インターフェイスが付属しています。 このような機能は予備調査段階では重要ですが、絶えず進化するサービスの増大する複雑性を管理するためには重要ではありません。

そしてここでジレンマが生じます。 矛盾。 二項対立。 結局のところ、情報システムはデータを提供するものであり、サービスはデータを隠すものです。

この XNUMX つの力が基本です。 彼らは私たちの仕事の多くを支えており、私たちが構築するシステムの卓越性を求めて常に戦っています。

サービス システムが成長し、進化するにつれて、データの二分法がさまざまな形でもたらす結果が目に見えてきます。 サービス インターフェイスが成長して、ますます幅広い機能を提供し、非常に豪華な自社製データベースのように見えるようになるか、それとも不満を感じて、データのセット全体をサービス間で一括して取得または移動する何らかの方法を実装するかのどちらかです。

逆に、派手な自社製データベースのようなものを作成すると、さまざまな問題が発生することになります。 なぜ危険なのかについては詳しく説明しません 共有データベースかなりのコストのかかるエンジニアリングと運用を表しているとだけ言っておきましょう。 困難 それを使おうとしている企業にとって。

さらに悪いことに、データ量によってサービス境界の問題が拡大することです。 サービス内に共有データが多くなるほど、インターフェイスはより複雑になり、異なるサービスからのデータセットを組み合わせることがより困難になります。

データセット全体を抽出して移動するという代替アプローチにも問題があります。 この質問に対する一般的なアプローチは、単純にデータセット全体を取得して保存し、それを使用する各サービスにローカルに保存することのように見えます。

問題は、サービスが異なれば、消費するデータの解釈が異なることです。 このデータは常に手元にあります。 これらはローカルで変更および処理されます。 すぐに、ソース内のデータとの共通点がなくなります。

コピーの変更可能性が高くなるほど、時間の経過とともにデータの変化も大きくなります。

さらに悪いことに、そのようなデータは後になって修正することが困難です (MDM ここが本当に助けになるところです）。 実際、企業が直面する解決できないテクノロジーの問題の一部は、アプリケーションごとに増加する異種データから発生します。

この問題の解決策を見つけるには、共有データについて異なる考え方をする必要があります。 それらは、私たちが構築するアーキテクチャの中で第一級のオブジェクトになる必要があります。 パット・ヘランド はそのようなデータを「外部」と呼びます。これは非常に重要な機能です。 サービスの内部動作を公開しないようにカプセル化が必要ですが、サービスが正しくジョブを実行できるように、サービスが共有データに簡単にアクセスできるようにする必要があります。

問題は、サービス インターフェイス、メッセージング、共有データベースのいずれも外部データを操作するための適切なソリューションを提供していないため、どちらのアプローチも今日では適切ではないことです。 サービス インターフェイスは、どのような規模であってもデータ交換にはあまり適していません。 メッセージングは​​データを移動しますが、その履歴は保存しないため、データは時間の経過とともに破損します。 共有データベースは XNUMX つの点に集中しすぎるため、進歩が妨げられます。 私たちは必然的にデータ障害のサイクルにはまってしまいます。

データ障害のサイクル

ストリーム: データとサービスへの分散型アプローチ

理想的には、サービスが共有データを処理する方法を変更する必要があります。 現時点では、どちらのアプローチも、それを消すために振りかけることができる魔法の粉がないため、前述の二分法に直面しています。 しかし、問題を再考して妥協点に達することはできます。

この妥協には、ある程度の集中化が伴います。 分散ログ メカニズムは、信頼性が高くスケーラブルなストリームを提供するため、使用できます。 現在、サービスがこれらの共有スレッドに参加して操作できるようにしたいと考えていますが、この処理を行う複雑な集中型のゴッド サービスは避けたいと考えています。 したがって、最良のオプションは、各コンシューマ サービスにストリーム処理を組み込むことです。 このようにして、サービスはさまざまなソースからのデータセットを組み合わせて、必要な方法でそれらを操作できるようになります。

このアプローチを実現する XNUMX つの方法は、ストリーミング プラットフォームを使用することです。 多くのオプションがありますが、今日は Kafka について見ていきます。Kafka のステートフル ストリーム処理を使用すると、提示された問題を効果的に解決できるからです。

分散ログ メカニズムを使用すると、よく踏まれた道をたどり、メッセージングを使用して作業できるようになります。 イベント駆動型アーキテクチャ。 このアプローチは、フローの制御を送信者ではなく受信者に与えるため、要求/応答メカニズムよりも優れたスケーリングと分割を提供すると考えられています。 しかし、この人生のすべてに対してあなたは支払わなければなりません、そしてここでは仲介者が必要です。 しかし、大規模なシステムの場合、トレードオフにはそれだけの価値があります (平均的な Web アプリケーションには当てはまらない可能性があります)。

ブローカーが従来のメッセージング システムではなく分散ログを担当する場合は、追加機能を利用できます。 トランスポートは、分散ファイル システムとほぼ同じように線形に拡張できます。 データはログに長期間保存できるため、メッセージ交換だけでなく情報も保存できます。 共有状態の変更を心配する必要のない、スケーラブルなストレージ。

その後、ステートフル ストリーム処理を使用して、使用するサービスに宣言型データベース ツールを追加できます。 これは非常に重要な考え方です。 データはすべてのサービスがアクセスできる共有ストリームに保存されますが、サービスが行う集約と処理はプライベートです。 彼らは、厳しく制限された状況の中で孤立していることに気づきます。

不変の状態ストリームを分離することで、データの二分法を排除します。 次に、ステートフル ストリーム処理を使用してこの機能をすべてのサービスに追加します。

したがって、サービスが注文、製品カタログ、倉庫を操作する必要がある場合、そのサービスには完全なアクセス権が与えられます。どのデータを結合するか、どこで処理するか、時間の経過とともにどのように変化するかを決めるのはあなただけです。 データが共有されているにもかかわらず、その作業は完全に分散化されています。 各サービス内で制作されており、すべてが自分のルールに従って進む世界です。

整合性を損なうことなくデータを共有します。 ソースではなく関数を、それを必要とするすべてのサービスでカプセル化します。

データをまとめて移動する必要がある場合があります。 サービスには、選択したデータベース エンジン内のローカル履歴データセットが必要な場合があります。 重要なのは、分散ログ メカニズムにアクセスすることで、必要に応じてコピーをソースから復元できることを保証できることです。 Kafka のコネクタはこれに優れた役割を果たします。

したがって、今日説明したアプローチにはいくつかの利点があります。

• データは、ログに長期間保存できる共通ストリームの形式で使用され、共通データを操作するメカニズムが個別のコンテキストに組み込まれているため、サービスが簡単かつ迅速に動作することができます。 このようにして、データの二項対立のバランスをとることができます。
• さまざまなサービスからのデータを簡単に組み合わせてセットにすることができます。 これにより、共有データとのやり取りが簡素化され、データベース内にローカル データセットを維持する必要がなくなります。
• ステートフル ストリーム処理はデータをキャッシュするだけであり、信頼できる情報源は一般的なログのままであるため、時間の経過によるデータ破損の問題はそれほど深刻ではありません。
• サービスの中核はデータ駆動型です。つまり、データ量が増え続けているにもかかわらず、サービスは依然としてビジネス イベントに迅速に対応できます。
• スケーラビリティの問題はサービスではなくブローカーにあります。 これにより、スケーラビリティについて考える必要がなくなるため、サービス作成の複雑さが大幅に軽減されます。
• 新しいサービスを追加するときに古いサービスを変更する必要がないため、新しいサービスの接続が容易になります。

ご覧のとおり、これは単なる REST ではありません。 分散型の方法で共有データを操作できるツールのセットを受け取りました。

今日の記事ではすべての側面がカバーされているわけではありません。 リクエスト/レスポンスのパラダイムとイベント駆動型のパラダイムの間でバランスをとる方法を見つける必要があります。 しかし、これについては次回に扱います。 たとえば、ステートフル ストリーム処理が優れている理由など、もっと深く知る必要があるトピックがあります。 これについては第 XNUMX 回の記事で説明します。 また、他にも、次のような強力な構造があり、それらを利用すれば利用できます。 XNUMX 回だけの処理。 これは、トランザクション保証を提供するため、分散ビジネス システムにとって大きな変革をもたらします。 XA スケーラブルな形式で。 これについては第 XNUMX 回の記事で説明します。 最後に、これらの原則の実装の詳細を検討する必要があります。

ただし、ここでは、データの二分法がビジネス サービスを構築する際に直面する力であることを覚えておいてください。 そして私たちはこれを覚えておかなければなりません。 秘訣は、すべてをひっくり返して、共有データを最上級のオブジェクトとして扱い始めることです。 ステートフル ストリーム処理は、これに対する独自の妥協策を提供します。 これにより、進歩を妨げる集中化された「神のコンポーネント」が回避されます。 さらに、データ ストリーミング パイプラインの俊敏性、拡張性、復元力を確保し、それらをすべてのサービスに追加します。 したがって、あらゆるサービスがデータに接続して操作できる一般的な意識の流れに焦点を当てることができます。 これにより、サービスの拡張性、交換性、自律性が向上します。 そのため、ホワイトボードや仮説テストで見栄えがするだけでなく、何十年にもわたって機能し、進化し続けるでしょう。

コースについて詳しくはこちらをご覧ください。

出所： habr.com