分散リアクティブアプリケーションを構築し、一貫性の問題を解決します

今日、多くの企業は、新しいプロジェクトを開始したり、既存のシステムを改善したりして、どの開発オプションがより正当化されるのか疑問に思っています。「クラシック」3層アプローチを使用するか、疎結合コンポーネントのセットとしてシステムを設計しますか？

最初のケースでは、蓄積されたすべての経験と既存のインフラストラクチャを最適に使用できますが、計画とリリースの長いサイクル、テストの困難性、中断のない運用の確保に耐える必要があります。 2番目のケースでは、インフラストラクチャと分散アプリケーション自体の管理にリスクが生じます。

この記事では、2GISで新しいシステムを構築するための2番目のオプションを選択した方法と理由、発生する問題を解決する方法、およびそれから得られるメリットを説明します。 Amazon S3、Apache Kafka、Reactive Extensions（Rx）、最終的な整合性とGitHub、厳しい納期、1つの技術スタックを使用するエンジニアから必要な規模のチームを編成できないことについて。

広告管理システムとは何ですか、なぜ広告が必要なのですか？

2GISは、2GIS製品のユーザーにより見やすくしたい企業に広告機会を販売することで利益を上げます。 広告販売には2つの要素があります。これは販売プロセスそのものと広告コンテンツ管理です。 この記事では、2番目のコンポーネントに焦点を当て、Advertising Management System（AMS）と呼ばれるシステムの詳細の一部を検討します。これは、2GISで広告資料を管理するためのアプリケーションです。

2011年に2GISで販売システムが開始され、広告販売の量と効果を高めるための新しい機会が開かれました。 当時、広告コンテンツの種類はそれほど多くなかったため、広告資料管理モジュールは販売システムの一部でした。 時間が経つにつれて、モジュールの要件が増加しました。新しいタイプのコンテンツが登場し、モデレーションプロセスが開始され、変更のより透明な監査が必要になりました。

これにより、2016年末に、広告コンテンツ管理モジュールを個別のシステムであるAMSに分離するための新しいプロジェクトが開始されました。AMSでは、現在のすべてのニーズを最初に解決し、開発に必要な基盤を構築できます。

AMSの主な目的は、2GIS製品で広告を作成、モデレート、およびリリースするプロセスの自動化を提供することです。 システムのユーザーは、2GISセールスマネージャー、広告主自身、および2GISモデレーターです。 AMSは、2GISが存在するすべての国で機能し、いくつかの言語にローカライズされています。主な言語はロシア語と英語です。 AMSがどのように機能するかを理解するために、販促資料を扱う際の主な手順を見てみましょう。

ある会社が注文数を増やすことにしたと想像してください。 たとえば、検索結果に会社のロゴと短いコメントを配置し、会社の背景色を選択して、カードに行動を促すボタンを追加することにより、ユーザーの注意を引くことができます。 これはすべて、広告主または彼に割​​り当てられたセールスマネージャーによって行われます。 さらに、広告資料はモデレートのために送信され、モデレーターが確認した後、すべての2GIS製品に配信されます。

システムの主な特徴は、システム内のすべてのデータがバージョン管理されていることです。 これは、テキストまたはバイナリデータに関係なく、広告コンテンツの変更は、広告素材の新しいバージョンが以前のバージョンの「隣に」作成されるという事実につながることを意味します。 これにより、誰が、いつ、どのような変更を加えたかなど、常に完全な情報を得ることができます。 これは法律の観点から非常に重要です。 この問題を解決するために、広告素材を構成するデータを、すぐにバージョン管理できるAmazon S3互換ストレージに保存することにしました。

それでも、システムを効果的に設計するためには、特定のサブジェクト領域の観点から機能する、データストレージレイヤーの明確で理解可能なAPIが必要です。 これは、ストレージAPIのCRUD S3ストレージAPIを広告素材、つまり厳密に定義された構造のオブジェクトに適合させる、内部ストレージAPIの登場です。 このストレージAPIには独自の名前-VStore（Versioned Storage）があり、その開発はGitHubで公然と行われています 。

当初、VStoreは非常にシンプルなRESTサービスとして考えられていましたが、開発プロセス中に、このレベルで他のタスクも解決する必要があることが明らかになりました。 たとえば、バイナリコンテンツのトランスコーディングと配布、または未使用データの削除（「ゴミ処理」）。 しかし、それについては後で。

S3ではデータを完全に保存できますが、効果的な検索クエリを実行することはできません。 そのため、このプロジェクトでは、検索スクリプトの広告資料に関するメタデータと、本格的なビジネスケースの実装に必要なデータを含む、使い慣れたSQLデータベースも導入しました。

プロジェクトの開始時には、別の問題を解決する必要がありました。その時点では、1つの技術スタックを使用してエンジニアから必要な規模のチームを編成する機会がありませんでした。 そして、締め切りはいつものように非常に厳しかった。

したがって、チームをさまざまな「世界」から集め、システムはさまざまなプログラミング言語を使用して記述でき、Dockerコンテナで実行できる分離モジュールのセットとして設計されました。 Kubernetesが2GISで積極的に運用され始めたのは非常に幸運でした。 そこで、マイクロサービスの道に着手しました。

AMSインフラストラクチャ

現在、AMSは4つの大きなモジュールで構成されています。

• VStoreは、厳密に定義された構造のオブジェクトのバージョン付きストレージの問題を解決し、S3ストレージを完全に抽象化して、可能な限り効率的に相互作用します。 このレベルでは、構成されたルール（テキスト内の文字数、ビットマップ画像のサイズと形式、ベクターグラフィックスの検証など）の遵守について、広告素材のコンテンツが監視されます。 コンテンツの配信はすべてVStoreの責任です。
• AMS APIは基本的にシステム全体のバックエンドです。 AMS APIは、VStoreを使用して、プロモーションデータの作成または編集を必要とするケースを実行します（バイナリデータの操作を含む）。 AMS APIは、広告資料に関するすべてのメタ情報をリレーショナルデータベースに保存します。 フロントエンドAMSは、会社の他のシステムと同様に、AMS APIと対話します。
• フロントエンドAMSは、プロモーション資料を使用してすべてのユーザーケースを実行するためのUIアプリケーションです。 2GISセールスマネージャーと広告主が仕事で使用するのはこのアプリケーションです。
• AMS管理パネルは、出版物の種類と言語に応じて、広告資料のコンテンツに関するルールと制限を設定するために必要です。 これらのルールは、広告が表示される2GIS製品によって決まります。

これらのモジュールは、独立したリポジトリの異なる言語で独立して実装されます。 すべての対話契約は慎重に合意されているため、開発は並行して効率的に行われます。 これらの各モジュールは、Kubernetesによって生成される1つ以上のDockerコンテナーとして実行されます。

一般に、Kubernetesは一般的な2GISプラットフォームの一部の1つであり、同社のサービスの多くが運用されています。 このプラットフォームには、ELKで構築された統合ログインフラストラクチャと、Prometheusを使用した監視サービスのすべての機能も含まれています。 シンプルで便利なアプリケーションの構築と展開のために、会社は特別に構成された内部GitLabを使用しています。 このすべてが作成された理由と方法については、 この記事をお読みください 。

すべてのAMSコンポーネントのアセンブリプロセスと、すべての2GISデータセンターへの展開も自動化されています。 モジュールには、他のコンポーネントのバージョンと一貫性のある独自のリリースサイクルとバージョンがあります。 これにより、数分で隔離されたテストベンチを上げて、システムの任意の部分の変更を確認したり、ステージングや実稼働でアプリケーションを展開したりできます。 DevDayのレポート記録を見ると、これがどのように配置されているかについて詳しく知ることができます。

要点をつかむ

もちろん、マイクロサービスと接続性の低さは優れています。分離、複数の言語での並行開発、変更管理の容易さです。 ただし、このアプリケーションの構成方法では、多くのアーキテクチャ上の問題を解決する必要があります。 そして、最初のものはコンポーネント間の通信です。

データを転送するには、同期的と非同期的の2つの方法があります。 最初のケースでは、特定のエンドポイントにリクエストを送信します。 要求は、応答が到着するか、待機時間が経過するまでブロックされます。 このメソッドを使用すると、アクションの確認と操作の結果が必要なケースを実装できます。 2番目の方法は、メッセージの送受信、つまりプロデューサー/コンシューマーパターンの実装です。

実際には、これらの方法の両方を一緒に使用する必要があります。 そのため、同期の場合にはHTTPプロトコルとRESTサービスを使用し、メッセージング全体がApache Kafkaで構築されます。

AMSの基本的なケース-プロモーション資料の作成を検討してください。 広告素材は一連の異なる要素で構成され、その内容はテキストまたはバイナリのいずれかであることに注意してください。 したがって、販促資料を作成するには、次のものが必要です。

• 要素のタイプと数を決定します。
• バイナリコンテンツを持つ要素がある場合は、バイナリファイルをダウンロードするための時間制限のあるセッションを作成する必要があります。
• 広告素材のプロトタイプをクライアント側に転送して、UIを描画します。
• バイナリコンテンツをダウンロードするときは、それを確認して（画像のタイプとサイズ、アルファチャネルの存在）、クライアントにリンクを返す必要があります。 検証が失敗した場合、ダウンロードしたファイルを削除します。
• 必要なすべての値が入力され、新しい広告素材がサーバーに送信される場合、すべてのテキスト値（ハイパーテキスト、すべての単語および各単語の文字数、単語数など）を確認する必要があります。
• すべてのチェックに合格したら、VStoreを使用してバージョン管理されたリポジトリに広告資料を作成し、リレーショナルデータベースにメタ情報（名前、会社へのリンク、モデレーションステータス）を保存する必要があります。

ここで何がうまくいかないのでしょうか？ 分散アプリケーションの場合-たくさん。

ケース自体の同期が原因でRESTサービスのいずれかが使用できない場合、広告資料は作成されません。 しかし、まだ微妙な違いがあります。

AMS APIがPOSTリクエストを送信してVStoreを介してオブジェクトを作成する状況を想像してください。 VStoreは、応答を送信することで正常に処理します。 すべての成功にもかかわらず、たとえばネットワークの「点滅」が原因で、この回答がAMS APIに届かない可能性があります。 それで何？ 次に、AMS APIはオブジェクトが作成されていないことを考慮し、ユーザーにそのことを通知します（簡単にするために、再試行サイクルはないと仮定します）。 ただし、このオブジェクトを再度作成しようとすると、ダブルを作成するか（新しい識別子を生成する場合）、オブジェクトが既に存在するため、作成を完了できません。 どちらの場合も、リポジトリの不一致が発生します。

別のトリッキーなケース

ソリューションの説明に進む前に、別のポイントを見てください。

プロモーション資料を作成するとしましょう。 バイナリコンテンツをダウンロードするためのセッションを準備し、ユーザーが写真をアップロードできるようにしました。 事前にすべてを確認した後、リポジトリにロードし、特定のキー（リンク）を返します。

しかし、ユーザーがダウンロードした画像がどのように見えるか気に入らず、別の（または3番目、4番目）をアップロードした場合はどうなりますか？ 実際、最後にアップロードされた画像のみが広告素材の一部になり、残りはすべて使用されません。

しかし、ユーザーがすべての操作を行った後、広告素材をまったく作成しないことを決めて、それを去った場合はどうでしょうか？ ダウンロードしたすべてのバイナリコンテンツは、削除するゴミになりました。

保証された効率的な方法

銀の弾丸

この記事では、「マイクロサービス」という用語を数回使用しました。これにより、アマチュアの間で用語について議論する合理的なdigりが生じる可能性があります。 実際、マイクロサービスは多くの場合、完全に独立した小さなアプリケーションのセットと呼ばれ、それぞれが相互作用のための独自の契約、サブジェクト領域のモデル、および独自のデータウェアハウスを持っています。 この場合、すべてのバックエンドサービスは共有リポジトリを使用します。

何らかの形で、この場合にも「マイクロサービス」という用語を使用でき、1つのドメインモデルが存在すると論理的に共有リポジトリが使用されると考えています。 そのため、1つのコアドメインモデルがあれば、それをさまざまなコンポーネントで再利用できるため、データの保存と読み取りのロジックを再利用できます。 基本ドメインモデルの変更は、アプリケーションのすべての部分のビジネスロジックに必然的に影響するため、これは非常に合理的です。 ここでの主なことは、アプリケーションの境界と責任を正しく決定し、コアドメインモデルを正しく選択することです。

しかし、バージョン管理されたストレージ（S3）とメッセージングインフラストラクチャ（Apache Kafka）の2つのツールに基づいて、データの調和の問題のほとんどを解決する方法を見てみましょう。

少し広く見ると、データのバージョン管理が不変プロパティの実装の1つであることがわかります。 このプロパティを持ち、バージョン/メッセージの順序を保証することで、いつでもデータが最終的に合意されるシステムを構築できます（ 結果整合性 ）。

広告素材を作成するケースの実装を少し変更して、いくつかの副作用を追加します（変更は太字で強調表示されています）。

• 要素のタイプと数を決定します。
• バイナリコンテンツを持つ要素がある場合は、セッションを作成し、バイナリファイルをダウンロードするための時間制限のあるセッションを作成しようとする試みについてメッセージを送信する必要があります。
• 広告素材のプロトタイプをクライアント側に転送して、UIを描画します。
• バイナリコンテンツをダウンロードするときは、それを確認し（画像のタイプとサイズ、アルファチャネルの存在など）、 特定のキーを持つファイルがダウンロードされたというメッセージを送信し、クライアントにリンクを返す必要があります。 チェックに合格した場合は、ダウンロードしたファイルを削除し、メッセージを送信しないでください 。
• 必要なすべての値が入力され、新しい広告素材がサーバーに送信される場合、すべてのテキスト値（ハイパーテキスト、すべての単語および各単語の文字数、単語数など）を確認する必要があります。
• すべてのチェックに合格したら、特定のキーを使用してオブジェクトを作成する試みに関するメッセージを送信し、 VStoreを使用してバージョン管理されたリポジトリに広告素材を作成し、メタ情報（名前、会社へのリンク、モデレーションステータス）をリレーショナルデータベースに保存する必要があります。

したがって、データの変更とともに、イベントが発生した順序でイベントを送信します。 これで、膨大な数のシナリオを実装することができます。 さらに、個別のバックグラウンドプロセスとして実行される同じマイクロサービスの助けを借りて、それらの実装を互いに完全に独立させることができます。

これで、リポジトリ内のデータの一貫性の問題は比較的簡単に解決されます。バックグラウンドプロセスは、オブジェクトを作成しようとするイベントを受け取り、オブジェクトが作成されたかどうかを確認し、SQLリポジトリに存在するかどうかを確認します。 上記の同期のケースが依然として失敗する場合、非同期に修正されます。 システムの一貫性が失われる時間間隔は短いほど、Apache Kafkaで効率的に作業できます。 そして、ここで事後対応的なアプローチが役立ちます。

Kafkaで同じメッセージを使用して、未使用のバイナリファイルを効果的にクリーンアップする方法を見てみましょう。 すべてがシンプルです。

別のバックグラウンドマイクロサービスを作成したら、セッション作成の事実に関するメッセージを順番に移動できます。 セッションが終了するとすぐに新しいファイルをアップロードできないため、このセッションのファイルを参照するオブジェクトがセッションアクティビティ中に作成または変更されたかどうかを確認する必要があります。 Kafkaは時間間隔を操作するためのAPIを提供します（Kafkaのすべてのメッセージにはタイムスタンプがあるため）。これは簡単です。 どのファイルも参照されていないことがわかった場合、すべてのファイルを含むセッション全体を削除できます。 それ以外の場合は、未使用のファイルのみを削除します。

アプリケーションアーキテクチャが記述されているため、ユーザーへの通知の送信からシステム内のイベントに基づく複雑な分析モデルの構築まで、まったく異なるシナリオを実装するのは非常に簡単です。 必要なのは、別のバックグラウンドプロセスを開始することだけです。 または、不要な場合は無効にします。

対処的アプローチ

それは何であり、このパラダイムは、Apache Kafkaと効果的に連携するのにどのように役立ちますか？ 正しくしましょう。 主なアイデアを理解するために、 リアクティブマニフェスト （ 翻訳 ）から引用します。

「リアクティブシステムとして構築されたシステムは、より柔軟で疎結合でスケーラブルです。 これにより、開発が容易になり、変更を受け入れやすくなります。 それらは障害に対して非常に寛容であり、 障害が発生しても、災害ではなく優雅に対応します。 リアクティブシステムは応答性が高く、 ユーザーに効果的なインタラクティブフィードバックを提供します。

私たちの前の課題の文脈では、「高応答性」および「効果的なインタラクティブフィードバック」という言葉に特に重点を置く必要があります。 主なポイントは、事後対応アプローチを使用すると、即座に応答し、メッセージの受信と処理の遅延を最小限に抑えるような方法でシステムを構築できることです。

反応主義を使用したシステムの実装を支援するツールがいくつかあります。 .NETの実装では、 Reactive Extensionsを使用しました。 このライブラリの中心にあるのは、観察可能なシーケンスの概念、つまり、サブスクライバーに新しい要素の出現を通知するコレクションです。 このようなコレクションを持つRx.NETを使用すると、あらゆる種類の操作を使用してメッセージ処理パイプラインを構築できます。最も単純な操作は、フィルタリング、投影、グループ化、バッファリングなどです。

カフカとRxを友達にする方法は？ とても簡単です。 Kafkaを使用するためのクライアントライブラリAPIでは、新しいメッセージが表示されたときに呼び出される関数（.NETではこれがイベントのサブスクリプションです）と、 Poll



メソッドの周期的な呼び出しをクライアントが指定する必要があります。 Rx.NETには、このタイプのAPIからObservable



移行するための特別Observable.FromEventPattern



メソッドがあります。 ここでは、実際の製品コードを見ることができます。

したがって、Rx.NETを使用すると、Apache Kafkaとアプリケーションを非常にシームレスに統合しながら、高性能、低レイテンシ、 非常にシンプルで読みやすいコードを取得できます 。

おわりに

分散アプリケーションは簡単ではありません。 AMSをマルチコンポーネントにする理由がなければ、おそらく「古典的な」アーキテクチャの道をたどるでしょう。

必要なソリューションを構築するには、次のことを思い出させてください。

1. データの効率的なバージョン管理をサポートします。
2. さまざまな技術スタックで開発をリードすると同時に、チーム内で相互理解を深める。
3. リリースサイクルが非常に短く、1日数回、運用環境で変更を展開します。
4. 個々のサービスが比較的単純で分離されているため、テストの単純さを保証します。
5. フォールトトレランスとスケーリングの容易さを提供するようにアプリケーションを設計します。

さらに、プロジェクトの開始時に、次のことを行いました。

1. Kubernetesに基づいた作業アプリケーション用のプラットフォーム。
2. 適切に構成され、サポートされているApache Kafkaクラスター。
3. バックエンドの開発における豊富な経験により、技術的リスクの管理が可能になりました。

現在、1秒あたり50〜70のhttp要求（RPS）があり、1秒あたりのKafkaを介して送信されるメッセージの数は数百単位です。 この負荷は、主に内部ユーザー（2GIS従業員）によって提供されます。 しかし、このように設計されたアプリケーションは、広告主の個人アカウントを通じて売り上げを増やし、2GISが存在するすべての国で売り上げを伸ばす準備をする機会を与えてくれます。 マイクロサービスアプローチのおかげで、新しい機能を比較的簡単に実装し、アプリケーションの安定性を管理できます。

VStoreの技術的な詳細は、techno.2gis.ruのレポートのビデオ録画にあります。

VStoreコードはオープンで、 GitHubで積極的に開発されています 。 視聴、コメント、質問。