デルタ: データの同期と強化のプラットフォーム

このレートで新たな流れが始まることを期待して データエンジニア 興味深い資料の翻訳を用意しました。

Обзор

アプリケーションが複数のデータ ストアを使用する、かなり一般的なパターンについて説明します。各ストアは、たとえば、正規形式のデータ (MySQL など) を保存したり、高度な検索機能 (ElasticSearch、など) .)、キャッシュ (Memcached など) など。 通常、複数のデータ ストアを使用する場合、そのうちの XNUMX つはプライマリ ストアとして機能し、他のデータ ストアは派生ストアとして機能します。 唯一の問題は、これらのデータ ストアを同期する方法です。

私たちは、二重書き込み、分散トランザクションなど、複数ストアの同期の問題を解決しようとするさまざまなパターンを検討しました。 ただし、これらのアプローチには、実際の使用、信頼性、メンテナンスの点で大きな制限があります。 データの同期に加えて、一部のアプリケーションでは、外部サービスを呼び出してデータを強化する必要もあります。

デルタはこれらの問題を解決するために開発されました。 デルタは最終的に、データの同期と強化のための一貫したイベント駆動型のプラットフォームを提供します。

既存のソリューション

ダブルエントリー

XNUMX つのデータ ストアの同期を保つには、一方のストアに書き込み、その直後にもう一方のストアに書き込むデュアル書き込みを使用できます。 最初の記録は再試行でき、試行回数を使い果たした後に最初の記録が失敗した場合は XNUMX 番目の記録を中止できます。 ただし、XNUMX 番目のストアへの書き込みが失敗すると、XNUMX つのデータ ストアが同期しなくなる可能性があります。 この問題は通常、第 XNUMX のストレージから第 XNUMX のストレージにデータを定期的に再転送するか、データに差異が検出された場合にのみ再転送するリカバリ手順を作成することで解決します。

問題点

回復手順の実行は、再利用できない特定のジョブです。 さらに、復元手順が実行されるまで、保管場所間のデータは同期されないままになります。 XNUMX つ以上のデータ ストアが使用される場合、ソリューションはより複雑になります。 最後に、復元手順により、元のデータ ソースに負荷がかかる可能性があります。

変更ログテーブル

一連のテーブルに変更が発生すると (レコードの挿入、更新、削除など)、変更レコードは同じトランザクションの一部としてログ テーブルに追加されます。 別のスレッドまたはプロセスは常にログ テーブルにイベントを要求し、必要に応じて XNUMX つ以上のデータ ストアにイベントを書き込み、レコードがすべてのストアによって確認された後にログ テーブルからイベントを削除します。

問題点

このパターンはライブラリとして実装する必要があり、理想的にはそれを使用するアプリケーションのコードを変更せずに実装する必要があります。 多言語環境では、このようなライブラリの実装は必要な言語で存在する必要がありますが、言語間で機能と動作の一貫性を確保することは非常に困難です。

もう 1 つの問題は、MySQL などのトランザクション スキーマ変更をサポートしていないシステムでスキーマ変更を取得する際にあります [2][XNUMX]。 したがって、変更 (スキーマ変更など) を行って、それを変更ログ テーブルにトランザクション的に記録するというパターンは、常に機能するとは限りません。

分散トランザクション

分散トランザクションを使用すると、トランザクションを複数の異種データ ストアに分割して、使用されるすべてのデータ ストアに操作をコミットするか、どのデータ ストアにもコミットしないようにすることができます。

問題点

分散トランザクションは、異種データ ストアにとって非常に大きな問題です。 その性質上、関連するシステムの最小公倍数にのみ依存できます。 たとえば、準備段階でアプリケーション プロセスが失敗した場合、XA トランザクションは実行をブロックします。 さらに、XA はデッドロック検出を提供せず、オプティミスティック同時実行制御スキームもサポートしません。 さらに、ElasticSearch などの一部のシステムは、XA またはその他の異種トランザクション モデルをサポートしていません。 したがって、さまざまなデータ ストレージ テクノロジで書き込みアトミック性を確保することは、アプリケーションにとって依然として非常に困難な課題です [3]。

デルタ

Delta は、既存のデータ同期ソリューションの制限に対処するように設計されており、オンザフライのデータ強化も可能にします。 私たちの目標は、アプリケーション開発者がこれらすべての複雑さを抽象化して、ビジネス機能の実装に完全に集中できるようにすることでした。 次に、NetflixのDeltaの実際の使用例である「映画検索」について説明します。

Netflix はマイクロサービス アーキテクチャを広く使用しており、各マイクロサービスは通常 XNUMX 種類のデータを提供します。 映画に関する基本情報は Movie Service と呼ばれるマイクロサービスに含まれており、プロデューサー、俳優、ベンダーなどに関する情報などの関連データは、他のいくつかのマイクロサービス (つまり、Deal Service、Talent Service、Vendor Service) によって管理されます。
Netflix スタジオのビジネス ユーザーは、多くの場合、さまざまな映画基準を対象に検索する必要があるため、すべての映画関連データを検索できることが非常に重要です。

Delta が導入される前は、映画検索チームは映画データにインデックスを付ける前に、複数のマイクロサービスからデータを取得する必要がありました。 さらに、チームは、まったく変更がない場合でも、他のマイクロサービスに変更をリクエストすることで検索インデックスを定期的に更新するシステムを開発する必要がありました。 このシステムはすぐに複雑になり、保守が困難になりました。

図 1. デルタへのポーリング システム
デルタの使用後、システムは次の図に示すようにイベント駆動型システムに簡素化されました。 CDC (Change-Data-Capture) イベントは、Delta-Connector を使用して Keystone Kafka トピックに送信されます。 Delta Stream Processing Framework (Flink ベース) を使用して構築された Delta アプリケーションは、トピックから CDC イベントを受信し、他のマイクロサービスを呼び出してイベントを強化し、最後に強化されたデータを Elasticsearch の検索インデックスに渡します。 プロセス全体はほぼリアルタイムで行われます。つまり、変更がデータ ウェアハウスにコミットされるとすぐに、検索インデックスが更新されます。

図 2. Delta を使用したデータ パイプライン
次のセクションでは、ストレージに接続し、CDC イベントを Kafka トピックにルーティングするリアルタイム データ送信インフラストラクチャであるトランスポート層に CDC イベントを発行するデルタコネクタの動作について説明します。 そして最後に、アプリケーション開発者がデータ処理とエンリッチメント ロジックに使用できるデルタ ストリーム処理フレームワークについて説明します。

CDC (変更データキャプチャ)

私たちは、コミットされた変更をデータ ストアからリアルタイムでキャプチャし、ストリームに書き込むことができる Delta-Connector と呼ばれる CDC サービスを開発しました。 リアルタイムの変更は、トランザクション ログとストレージ ダンプから取得されます。 通常、トランザクション ログには変更履歴全体が保存されないため、ダンプが使用されます。 通常、変更はデルタ イベントとしてシリアル化されるため、受信者は変更がどこから来たのかを心配する必要はありません。

デルタコネクタは、次のようないくつかの追加機能をサポートしています。

• Kafka を超えたカスタム出力データを書き込む機能。
• すべてのテーブル、特定のテーブル、または特定の主キーに対していつでも手動ダンプをアクティブ化する機能。
• ダンプは分割して取得できるため、失敗しても最初からやり直す必要はありません。
• テーブルにロックを設定する必要はありません。これは、データベースの書き込みトラフィックがサービスによってブロックされないようにするために非常に重要です。
• AWS アベイラビリティーゾーンの冗長インスタンスによる高可用性。

現在、AWS RDS と Aurora でのデプロイメントを含む、MySQL と Postgres をサポートしています。 Cassandra (マルチマスター) もサポートしています。 Delta-Connector の詳細については、こちらをご覧ください。 ブログ記事.

Kafka とトランスポート層

デルタ航空のイベント トランスポート層は、プラットフォームのメッセージング サービス上に構築されています キーストーン.

歴史的に、Netflix への投稿は、存続期間ではなくアクセシビリティを重視して最適化されてきました (下記を参照)。 前の記事）。 その代償として、さまざまなエッジ シナリオにおけるブローカー データの不整合が生じる可能性がありました。 例えば、 汚れたリーダー選挙 受信者には、イベントが重複または失われた可能性があることに責任があります。

デルタでは、派生ストアへの CDC イベントの配信を確実にするために、より強力な耐久性保証を求めていました。 この目的のために、私たちは特別に設計された Kafka クラスターをファーストクラスのオブジェクトとして提案しました。 以下の表でいくつかのブローカー設定を確認できます。

Keystone Kafka クラスターでは、 汚れたリーダー選挙 通常、発行者のアクセシビリティを確保するために含まれています。 同期されていないレプリカがリーダーとして選択されると、メッセージが失われる可能性があります。 新しい高可用性 Kafka クラスターの場合、オプション 汚れたリーダー選挙 メッセージの損失を防ぐためにオフになっています。

うちも増えました 複製係数 2から3まで、そして 最小の同期レプリカ 1 から 2。このクラスターに書き込むパブリッシャーは、他のすべてのレプリカからの確認応答を必要とし、2 つのレプリカのうち 3 つがパブリッシャーから送信された最新のメッセージを持つようにします。

ブローカー インスタンスが終了すると、古いインスタンスが新しいインスタンスに置き換えられます。 ただし、新しいブローカーは非同期レプリカに追いつく必要があり、これには数時間かかる場合があります。 このシナリオの復旧時間を短縮するために、ローカル ブローカー ディスクの代わりにブロック データ ストレージ (Amazon Elastic Block Store) の使用を開始しました。 新しいインスタンスが終了したブローカー インスタンスを置き換えると、終了したインスタンスが持っていた EBS ボリュームを接続し、新しいメッセージの受信を開始します。 このプロセスにより、新しいインスタンスを空の状態からレプリケートする必要がなくなるため、バックログのクリア時間が数時間から数分に短縮されます。 全体として、ストレージとブローカーのライフサイクルを分けることで、ブローカーの切り替えによる影響が大幅に軽減されます。

データ配信の保証をさらに高めるために、次を使用しました。 メッセージ追跡システム 極端な条件下でのメッセージ損失を検出します (たとえば、パーティション リーダーでのクロックの非同期)。

ストリーム処理フレームワーク

デルタの処理レイヤーは、Netflix SPaaS プラットフォーム上に構築されており、Apache Flink と Netflix エコシステムとの統合を提供します。 このプラットフォームは、Titus コンテナ管理プラットフォーム上で Flink ジョブの展開と Flink クラスターのオーケストレーションを管理するユーザー インターフェイスを提供します。 このインターフェイスはジョブ構成も管理し、ユーザーが Flink ジョブを再コンパイルすることなく構成を動的に変更できるようにします。

デルタは、Flink および SPaaS に基づいたストリーム処理フレームワークを提供します。 注釈ベースの 技術的な詳細を抽象化する DSL (Domain Specific Language)。 たとえば、外部サービスを呼び出してイベントを強化するステップを定義するには、ユーザーは次の DSL を記述する必要があります。フレームワークはそれに基づいてモデルを作成し、Flink によって実行されます。

図 3. デルタにおける DSL のエンリッチメントの例

この処理フレームワークは、学習曲線を短縮するだけでなく、一般的な運用上の問題を解決するための重複排除、図式化、柔軟性と復元力などの一般的なストリーム処理機能も提供します。

デルタ ストリーム処理フレームワークは、DSL & API モジュールとランタイム モジュールという XNUMX つの主要なモジュールで構成されています。 DSL & API モジュールは、ユーザーが独自の処理ロジック (フィルタリングや変換など) を作成できるように、DSL および UDF (ユーザー定義関数) API を提供します。 ランタイム モジュールは、DAG モデルの処理ステップの内部表現を構築する DSL パーサーの実装を提供します。 実行コンポーネントは、DAG モデルを解釈して実際の Flink ステートメントを初期化し、最終的に Flink アプリケーションを実行します。 フレームワークのアーキテクチャを次の図に示します。

図 4. デルタ ストリーム処理フレームワークのアーキテクチャ

このアプローチにはいくつかの利点があります。

• ユーザーは、Flink や SPaaS 構造の詳細を深く掘り下げることなく、ビジネス ロジックに集中できます。
• 最適化はユーザーに対して透過的な方法で実行でき、ユーザー コード (UDF) を変更することなくエラーを修正できます。
• デルタ アプリケーションのエクスペリエンスは、このプラットフォームがすぐに使える柔軟性と復元力を提供し、アラートに使用できるさまざまな詳細なメトリクスを収集するため、ユーザーにとって簡素化されています。

生産用途

Delta は XNUMX 年以上にわたって運用を開始しており、多くの Netflix Studio アプリケーションで重要な役割を果たしています。 彼女は、チームが検索インデックス作成、データ ストレージ、イベント駆動型ワークフローなどのユースケースを実装するのを支援しました。 以下は、Delta プラットフォームの高レベルのアーキテクチャの概要です。

図 5. Delta の高レベルのアーキテクチャ。

感謝

Netflix でデルタの作成と開発に携わった次の方々に感謝します: Allen Wang、Charles Zhao、Jaebin Yoon、Josh Snyder、Kasturi Chatterjee、Mark Cho、Olof Johansson、Piyush Goyal、Prashanth Ramdas、Raghuram Onti Srinivasan、Sandeep Gupta、Steven Wu、Tharanga Gamaethige、Yun Wang、Zhenzhong Xu。

ソース

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann、Alastair R. Beresford、Boerge Svingen: オンライン イベント処理。 共通。 ACM 62(5): 43–49 (2019)。 土井： doi.org/10.1145/3312527

無料のウェビナーに登録する: 「Amazon Redshift ストレージ用のデータ構築ツール」。

出所： habr.com