みなさんこんにちは。 ご存知かもしれませんが、私は以前、ストレージ、Vertica、ビッグデータストレージ、およびその他の分析について書いて話していました。 現在、分析データベースだけでなく、OLTP（PostgreSQL）、NOSQL（MongoDB、Redis、Tarantool）など、他のすべてのデータベースも私の責任範囲に含まれています。

この状況により、複数のデータベースを持つ組織を、1つの分散した異種（異種）データベースを持つ組織として見ることができました。 多数のPostgreSQL、Redis、およびMongで構成される単一の分散異種データベース。また、場合によっては、1つまたは2つのVerticaデータベース。

この単一の分散ベースの作業により、多数の興味深いタスクが生成されます。 まず、ビジネスの観点から、すべてが正常であり、データがそのようなベースに沿って移動していることが重要です。 整合性、一貫性という用語は特に使用しません。 この用語は複雑で、DBMS（A C IDとC APの定理）を考慮する際のニュアンスが異なるため、意味が異なります。

企業がマイクロサービスアーキテクチャに切り替えようとすると、分散ベースの状況は悪化します。 ネコの下で、分散トランザクションや緊密な接続性を持たないマイクロサービスアーキテクチャでデータの整合性を確保する方法について説明します。 （そして最後に、なぜこのイラストを記事に選んだのかを説明します）。

Chris Richardson（マイクロサービスアーキテクチャの最も有名な伝道者の1人）によると、このアーキテクチャには、データベースを操作するための2つのアプローチがあります：共有データベースとサービスごとのデータベースです。

共有データベースは良い第一歩であり、野心的な成長計画のない中小企業にとっては素晴らしいソリューションです。 さらに、このパターン自体は、マイクロサービスアーキテクチャの観点からはアンチパターンです。 共通のベースを共有する2つのサービスを個別にテストおよびスケーリングすることはできません。 つまり むしろ、これらのサービスはモノリスになる傾向がある1つのサービスです。

データベースごとのサービスパターンは、各サービスに独自のデータベースがあることを前提としています。 サービスは、そのデータベースに直接接続することなく、APIを介して（広い意味で）別のサービスのデータにアクセスできます。

データベースごとのパターンを使用すると、対応するサービスのチームが好きなようにデータベースを選択できます。 誰かがMongoDBを使用できる、誰かがPostgreSQLを信じる、誰かがRedisを必要とする（このサービスではシャットダウン時のデータ損失のリスクは許容できる）、そして誰かは通常ディスク上のCSVファイルにデータを保存する（そして実際、なぜ、いいえ？）。

このようなデータベースの「動物園」で作業すると、データの順序をまったく新しいレベルの複雑さに復元するタスクが発生します。

ACIDおよびマイクロサービスアーキテクチャ

DBMSベースの古典的なACID要件セットのプリズムを通して物事を整理するタスクを見てみましょう。略語の各文字の本質を拡大し、マイクロサービスアーキテクチャにおけるこの文字の難しさを説明します。

（A）CID-原子性。 原子性-すべてまたは何もない。

アトミック性の要件に従って、すべてのステップを（可能な繰り返しで）完了することが不可欠です。重要なステップが失敗した場合、完了したステップをキャンセルします。

上記の図は、VIPサービスを購入するテストプロセスを示しています：お金は請求（1）で予約され、ボーナスサービス（2）はユーザーに対して有効化され、ユーザーの種類はPro（3）に変更され、請求で予約されたお金は引き落とされます（4）。 4つのステップはすべて完了する必要があります。

同時に、プロセスの途中でハングすることはできません。したがって、非同期が望ましいです。極端な場合は、組み込みのタイムアウトとの同期が必要です。

A（C）ID-一貫性。 一貫性-各ステップは境界条件と矛盾するべきではありません。

たとえば、サービス1のクライアントAからサービス2のクライアントBに送金するための条件の古典的な例：このような送金の結果として、以下（送金中にお金を失ってはいけません）以上（2人のユーザーに同じお金を送ってはいけません）同時に）。 この要件に準拠するには、条件をどこかにコーディングし、条件のデータを確認する必要があります（理想的には、追加の呼び出しなしで）。

ACI（D）-耐久性。 耐久性の要件は、操作の影響が消えないことを意味します。

Polyglotの永続性の条件下では、サービスはデータベースで動作し、データベースに記録されたデータを定期的に「失う」ことがあります。 非同期レプリケーションが有効になっている場合、PostgreSQLなどの堅牢なデータベースからも同様のトリックを取得できます。 この図は、マスターに記録されたが、非同期レプリケーションを介してスレーブに到達しなかった変更を、マスターサーバーを焼き付けることによって破棄する方法を示しています。 耐久性の要件を確保するには、このような損失を適切に診断して回復できる必要があります。

そして、私はどこにいますか？

そしてどこにもありません。 いくつかの独立した非同期サービスの環境での分離は技術的な要件です。 現代の研究は、実際のビジネスプロセスを分離せずに実装できることを示しています。 分離は同時実行性を最小限に抑えることで思考を簡素化します（プログラマーにとって並列コンピューティングの開発はより困難です）が、マイクロサービスアーキテクチャは本質的に大規模な並列であり、そのような環境での分離は冗長です。

上記の要件へのコンプライアンスを達成するための多くのアプローチがあります。 いわゆる2フェーズコミット（2PC）によって提供される分散トランザクションの最も広く知られているアルゴリズム。 残念ながら、2フェーズコミットを実装するには、関連するすべてのサービスを書き換える必要があります。 そして最も深刻なのは、このアルゴリズムの生産性があまり高くないことです。 最近の研究の上記の図は、このアルゴリズムが2台のサーバーの分散ベースで特定のパフォーマンスを示していることを示していますが、サーバーの数が増えると、生産性は直線的に増加しません...より正確には、まったく増加しません。

マイクロサービスアーキテクチャの主な利点の1つは、サーバーを追加するだけでパフォーマンスを直線的に向上できることです。 分散整合性を確保するために2フェーズコミットを使用すると、サーバーの数が増えても、このプロセスがボトルネックになり、生産性の向上を制限することになります。

2段階のコミットなしで、パフォーマンスを直線的に拡張する機能を備えた分散整合性（ACiD要件）をどのように確保できますか？

現代の研究（たとえば、 分散同時実行制御の評価。VLDB2017 ）は、いわゆる「楽観的アプローチ」が役立つと主張しています。 2フェーズコミットと一般化された「楽観的アプローチ」の違いは、旧ソビエト店（カウンター付き）とAuchanのような現代のスーパーマーケットの違いによって説明できます。 カウンターのある店舗では、すべての顧客が疑わしいと見なされ、最大限のコントロールが提供されます。 したがって、線と競合。 そして、スーパーマーケットでは、買い手はデフォルトで正直であると見なされ、棚に近づいてカートを埋める機会を与えます。 もちろん、詐欺師（カメラ、セキュリティ）を捕まえるための監視ツールがありますが、ほとんどの買い手はそれらに対処する必要はありません。

したがって、より多くのキャッシュデスクを配置するだけで、スーパーマーケットを拡大、拡張できます。 マイクロサービスアーキテクチャでも同じことが言えます。分散型の整合性が「楽観的なアプローチ」によって保証されている場合、何か問題が発生したプロセスだけにチェックが追加でロードされます。 また、通常のプロセスでは追加のチェックは行われません。

重要です。 「楽観的アプローチ」には、いくつかのアルゴリズムが含まれます。 クリス・リチャードソンが推奨する、分散完全性を維持するためのアルゴリズムであるサガについてお話ししたいと思います。

Sagas-アルゴリズムの要素

sagアルゴリズムには2つのオプションがあります。 したがって、最初に、アルゴリズムの必要な要素を普遍的に説明して、両方のオプションに適したものにするようにします。

要素1.サービス間の信頼性の高い永続的なイベント配信チャネル。「少なくとも1回の配信」を保証します。 つまり プロセスのステップ2が正常に完了した場合、これに関する通知（イベント）が少なくとも1回ステップ3に到達し、配信の繰り返しは許容されますが、何も失われるべきではありません。 「永続的」とは、データベースが失われたために最新の変更を失ったサービス（図のステップ2である耐久性の例を参照）が復元できるように、チャネルが通知を一定期間（週に2〜3日）保存する必要があることを意味しますこれらの変更は、チャネルからイベントを再生することによって行われます。

要素2.一意のi等性キーを使用したサービス呼び出しのdem等性。 私（ユーザー）がVIPパッケージの購入プロセスを開始すると想像してください（アトミック性の例を参照）。 プロセスの開始時に、一意のキー、たとえば42のi等性キーが与えられます。次に、各ステップ（1→2→3→4）への呼び出しを、i等性キーを指定して実行する必要があります。 上記の段落では、同じメッセージがサービスに（ステップで）繰り返し到着する可能性が言及されています。 サービス（ステップ）は、処理されたイベントの繰り返し到着を自動的に無視し、べき等キーによる繰り返しをチェックできる必要があります。 つまり、すべてのサービス（プロセスステップ）がべき等である場合、AtomicityおよびDurabilityの要件を満たすためには、チャネルからのイベントに対応するステップにリダイレクトするだけで十分です。 イベントをスキップしたステップはそれらを完了し、既にイベントを完了したステップは、べき等性のためにそれらを無視します。

要素3.べき等キーによるサービス呼び出し（ステップ）のキャンセル。

アトミック性（例を参照）を確保するために、たとえば、dem等性キー42のプロセスがステップ3で停止/低下した場合、キー42のステップ1および2の正常な実行をキャンセルする必要があります。このため、必須の各プロセスステップには「補償」ステップが必要です、指定されたべき等キー（42）に必要なステップの実行をキャンセルするAPIメソッド。 代償呼び出しの実装は、サグアルゴリズムの実装の一部としてのサービスの洗練において困難ですが必要な要素です。

上記の3つの要素は、「サグ」の実装の両方のバージョンに関連しています：オーケストラとコレオグラフィック。

オーケストラサガ

オーケストレーションされたサガのより単純で明白なアルゴリズムは、理解と実装が簡単です。 優れた記事で、 KevteevはAvitoで編成されたサガのメカニズムのアルゴリズムと実装プロセスについて説明しました。 彼らのアルゴリズムは、サービス対象ビジネスプロセスの一部としてサービス呼び出しを「調整」する制御サービスの存在を前提としています。 同じ監視サービスに独自のデータベース（たとえば、PostgreSQL）があり、信頼できる永続的なイベント配信チャネル（要素1）として機能します。

振り付けサガ

振り付けの物語はもっとトリッキーです。 ここで、次の要件を実装するデータバスは、信頼できる永続的なチャネルとして機能する必要があります。fire-and-forgetpublishing、publish-subscribeイベント配信、少なくとも1回の配信。 つまり 各プロセスの各ステップは、バスから操作するコマンドを受け取り、成功した実行、次のステップの開始に関するメッセージをそこに投げて、バスからそれを読み取ってプロセスを続行する必要があります。 さらに、各メッセージには複数のサブスクライバーが存在する場合があります。

振り付けの物語には、制御サービス、サガのサービスも必要ですが、かなり「軽量」です。 サービスは、システムに登録されているビジネスプロセス、各プロセスに含まれるステップの構成について知っている必要があります。 また、バスに耳を傾け、各プロセス（各べき等性キー）の実行を監視し、何か問題が発生した場合にのみ、特定のステップの「繰り返し」を行うか、実行したステップの「キャンセル」、「補償」を行います。

ニュアンス

古典的な取引と区別するサガの最も重要なニュアンスの1つは、各ステップの線形性、順序、および義務からの逸脱です。 サガは必ずしもイベントの線形チェーンではなく、有向グラフでもかまいません：新しいユーザー登録イベントは、いくつかのステップを並行して生成できます（SMSの送信、ログインの登録、パスワードの生成、電子メールの送信）。その一部はオプションです。 最初の近似では、オプションのステップを備えたこのような「分岐」サガでは、サガ（プロセス）の完了を判断することは困難であるように見えますが、実際にはすべてが単純です：サガ（プロセス）はすべての必要なステップが任意の順序で完了すると完了します。

振り付けサガではより典型的ですが、オーケストラのサガでは可能性のある2番目のニュアンスは、ビジネスプロセス、サガサービスでのサガのタイプを登録する方法を選択することです。 Atomicityの例では、4つの連続した必須ステップのプロセスを説明しています。

誰がこのプロセスを登録し、すべてのステップを示し、依存関係と必須ステップを配置しましたか？ 明らかですが、昔ながらの答えは、プロセス登録はsagサービスの中央で行う必要があるということです。 しかし、この答えはマイクロサービスアーキテクチャとあまり整合性がありません。 マイクロサービスアーキテクチャでは、ボトムアッププロセスの登録がより有望で、生産性が高く、高速です。 つまり サグサービスのプロセスのすべてのニュアンスを書き留めるのではなく、個々のサービスが既存のプロセスに独自に「適合する」ようにし、それらのバインディング/オプションの性質と必須の先行を示します。

つまり ユーザーをサグサービスに登録するプロセスは、最初は3つのステップで構成できます。その後、システムの開発中に、さらに7つのステップが収まり、1つのステップが書き​​出され、9つあります。 このような「アナーキー」および「分散」スキームは、厳密な調整プロセスを実装するためにテストするのが困難ですが、アジャイルチームにとっては、継続的な多方向の製品進化にとってはるかに便利です。

実はここ。 真剣なプレゼンテーションで、私はそれを終了する価値があると思います。

---

この資料のプレゼンテーションへのリンクは次のとおりです。HighloadSiberia 2018でこのトピックに関するレポートを作成しました。

UPD-および会議のビデオ：

---

エピローグ

最後に、上記のすべてをより比language的な言語で説明したいと思います。

結局のところ、サガとは元々何ですか？ このプロット、この中世からの冒険...またはゲーム・オブ・スローンズから。 イベントが発生し（戦闘、結婚式、誰かが死亡）、このニュースはメッセンジャー、伝書鳩、商人を通して世界中に飛びます。 （1週間、1か月、1年で）興味のある人にニュースが届くと、彼らは反応します。軍隊を送り、戦争を宣言し、誰かを処刑し、新しいメッセージが飛びます。

アクションのシーケンスを監視する規制機関はありません。 アクションを取り消すという意味でのトランザクション、ロールバックはありません。 すべて大人の方法で、すべてのアクションは永遠に行われます。 それは補償することができますが、それは正確に行動（殺人）と補償（頭の支払い、ビラ）であり、死の廃止ではありません。

イベントは長い時間がかかり、さまざまなソースから発生し、アクションは厳密に連続してではなく、並行して発生します。 そして、かなり頻繁に、新しい参加者が突然プロットに現れ、参加することを決定します（ドラゴンが到着します;））...そして、古い参加者のいくつかは突然死にます。

そのようなこと。 混乱と混乱のように見えますが、すべてが機能し、世界の内部の一貫性が壊れておらず、プロットが発展しており、一貫しています...時には予測不可能です。