Apache BookKeeperの紹介-複製された雑誌サービス

私の活動の性質上、広告、フィンテック、SaaS、PaaSクラスのサービスなど、さまざまな市場向けのアクセスしやすく高性能なシステムが作成されるプロジェクトに頻繁に参加する必要があります。 このようなシステムは、たとえばストリーミングデータ処理用のラムダアーキテクチャ、水平スケーリングに特化したスケーラブルなマイクロサービスソフトウェア設計、noSQL DBMS（Redis、Aerospike、Cassandra、MongoDBなど） ）、メッセージブローカー（Kafka、RabbitMQ）、分散調整および検出サーバー（Apache Zookeeper、Consul）。 このような基本的なインフラストラクチャブロックにより、ほとんどのタスクを正常に解決できます。開発チームは、開発中のシステムのビジネス指向の部分で使用される中間レベルのコンポーネントを開発するタスクに直面しません。

場合によっては、標準の既存のソリューションを使用してプロジェクトチームを実装できないという問題が発生し、特定の問題を解決するために設計された高度に専門化された製品の検索または開発が必要になります。

挑戦する

プロジェクトの1つでは、チームにかなり具体的なタスクがあり、そのフレームワーク内で、データを「再生」し、複製、水平スケーリングをサポートし、フォールトトレラントになる厳密に順序付けられたデータキューを整理する必要がありました。 これはコミットログと呼ばれる古典的なデータ構造であり、ほぼすべての複雑なDBMSで使用されます。

トランザクションログの主な要件は、変更を厳密な順序で記録することです。そのため、この構造により、レコードが他のクライアントよりも長くかかった場合でも、最初にレコードを開始したクライアントがより低いシーケンス番号のジャーナルエントリを受け取ることが保証されます。 操作ログは、注文する必要のあるオブジェクトへの競合アクセスがあるシステムで広く使用されています。 通常の同時アクセスキューは、このようなログの例です（JavaのLinkedBlockingQueueなど）。

このような構造の価値は、繰り返しパス中に最終状態の不変性を保証し、多くの場合、複数の変更中にオブジェクトの最終状態を正しく反映するために正確に使用されることです。

複数のエージェントが複数のオブジェクトの複数のノードにわたって状態の順序付けられた変更を伝播する必要がある場合、問題が始まります。 明らかで最も低パフォーマンスのアプローチは、Apache Zookeeperなどの分散ロックサービスの使用に基づいており、その助けを借りて、ストレージへの順序付けられたアクセスが実行されます。 このオプションは機能していますが、オブジェクトの変更がめったに起こらない場合、オブジェクトの状態が頻繁に変更される高性能システムを実装するために、このオプションは適切ではありません。 2つのエージェントと2つのノードがある特殊なケースを図に示します。

リック、モーティ、サマーの紹介画像を注意深く見ると、これに気付くことができます...すべては似ているように見えますが、すでに若干の矛盾があります。

RocksDBの各ノードがオブジェクトの現在の状態を維持するリーダー/フォロワータイプの複製システムを開発する必要がありました。ノードが失われた場合、別のノードと既存の操作ログから簡単に復元でき、抽象ビューが図に表示されます：

このタスク内に存在する主なエンジニアリング上の問題は、 分散複製操作ログの開発です。

分散複製アクティビティログ

最初に、いつものように、考えは道を進んだ- 独自のバーが必要です... 私たちはクールな開発者です-自分ですべてをやろう！「ローカルマガジンの実装があり、おそらくネットワークに展開して実装を複製できると考えました。正直なところ、作業量が鈍い歯痛を引き起こしましたが、主要製品ではなく、下層のコンポーネントでした。

待ってください、しかしApache Kafkaがあります、驚いた読者は言うでしょう！ そして、それはほぼ正しいでしょう。 Apache Kafkaは素晴らしいことですが、このタスクの一部として、次の機能が欠けています。

1. 動作完了の確認
2. 保証されたデータ順序と一意性

ほとんどの場合、Apache Kafkaは正常に機能しますが、TCPパケットを失ったり、ウィザードをクラッシュした場合、メッセージが複製されないという保証はありません。 これは、Kafkaのメッセージが完全に送信され、Apache Kafkaが帯域幅に対して最適化されているため、クライアントがサーバー上のエントリの順序を制御しないという事実によるものです。

しかし、ソリューションの詳細を分析し、考え始めたとき、すでにソリューションが存在することがわかりましたが、それについては知りませんでした。 そして、これはApache BookKeeperです。 さらに、Apache Zookeeper、Java、Netty（私たちのプロジェクトはScalaにありましたが、Javaスタックは非常に満足していました）で、イデオロギー的にも技術的にも実装されています。 その結果、ニーズを満たすためにApache BookKeeperをテストする新しいフェーズが開始されました。

Apacheブックキーパー

次に、Apache BookKeeperが複製されたスケーラブルな操作ログの問題を解決するために使用する原則とアプローチについてお話します。

そのため、この製品はあまり知られていませんが、ユーザーはいます。 例：

• Twitter DistributedLog
• Twitterマンハッタン
• より有名なユーザー

おそらく最初の記事を翻訳するだけでいいのかもしれませんが、チュクチの魂の中で-作家。

最初に、次の図に表示されているApache BookKeeperの概念アーキテクチャを見てみましょう。

スキームの主要な要素：

• Bookie-ログデータが保存されているサーバー。
• 元帳-「元帳」。特定の数のレコードを単一のボリュームに編成し、データの複製先のBookieサーバーを定義します。
• 元帳入力-元帳への入力、有用な情報。
• BKクライアント-APIを実装するJavaクライアントコード。
• Zookeeper-元帳に関するレコードを保存するApache Zookeeperサーバー（番号、レプリカが保存されるBookieサーバー）。

ここで、Apache BookKeeperインタラクションモデルとそのデータ管理アーキテクチャがどのように機能するかを理解するために、主要な要素を詳しく見ていきます。

ブッキー

ストレージサーバー。 BookKeeperの一部として、フィールドに複製されたストレージ環境を備えた多くのBookieサーバーを展開して実行します。 データは元帳内で配信され、配信方法はフラットです。システムではトポロジラベルを設定できません（これは残念です）。 Bookieサーバーを追加すると、システムを水平方向に拡張できます。

元帳/元帳

同じサーバーに複製される厳密に順序付けられたレコードのセットを編成します。 元帳は、識別子の増加順に並べられます。 レプリカサーバーデータは、Zookeeperの元帳レコードに保存されます。

重要な制限1 。 元帳に書き込むことができるのは1人の作家のみです。 したがって、元帳はスケーリングの単位です。 一連の操作で異なる元帳に分離できない場合、パフォーマンス制限は元帳への書き込み速度になります。これはレプリケーション係数に依存します（BK Clientは並行して書き込むため、直線的ではありません）。

各レコードの元帳に書き込むとき、一意の増加するシリアル整数番号がクライアントによって発行されます。これにより、記録への非同期アプローチを編成できます。 同時に、BookKeeperは、番号（n + 1）の書き込み操作が、より小さい番号のすべての書き込み操作が完了した場合にのみ完了することを保証します。 これは非常に便利な機能であり、操作の完了に関するクライアントへの規則的な通知が必要な場合でも、場合によっては書き込み操作のパフォーマンスを大幅に向上させることができます。

重要な制限2 。 無制限の数のリーダーが台帳から並行して読み取ることができますが、台帳が閉じているとき、つまり現在誰も書いていないときに読み取りが許可されます。

一般に、元帳に対する上記の制限は重要な制限であり、場合によっては範囲を大幅に狭める可能性があります。

たとえば、毎秒新しい元帳を開き、書き込み、閉じます。 これは、読み取り処理が1秒遅れることを意味します。 元帳は識別子タイプLongであるため、1msごとに問題なく開くことができますが、Zookeeperの負荷が増加する状況が発生しますが、これはすでに大きな負荷になります。 私たちが解決しようとしている問題では、この制限は受け入れられました。

別の例として、記録の強度は、1つの台帳内のサーバーのパフォーマンスが十分でないことであり、アプリケーションロジックは、複数の元帳間で記録を分割できないことです。 彼らが言うように、すべてが到着しました。 この制限もタスクのフレームワーク内でバイパスされました。この方法ですべてのオブジェクトをパーティション分割でき、この制限を回避できないデータストリームが1つしかありませんでした。

元帳識別子ストレージ

元帳識別子はZookeeperに保存されているため、繰り返し使用できますが、すべてが単純ではありません。 複数のパラレル元帳チェーンが必要な場合、特定のチェーンに属する元帳識別子を別々にどこかに保存する必要があります。BookKeeperはこれを支援しません。 別のオプションは、Zookeeperで個別のパスを持つように、タスクごとに分離されたBookieサーバーを個別に展開することです（これは私たちには不適当でした）。

Apache Zookeeper自体が追加の制限を課していることにも注意する必要がありますが、これも考慮する必要があります。

1. データベース全体をサーバーのメモリに配置する必要があります（多くの元帳を開いて削除しない場合）、いつかサーバーに十分なRAMがなくなる可能性があります（もちろん、この事実は割引されません）。
2. 親Zookeeperディレクトリに多くの要素がある場合、1MBの最大Zookeeperパッケージサイズに収まらない場合、ディレクトリリストを受信するときにエラーが発生する可能性があります。

Apache BookKeeperの作成者は、 Hierarchical Ledger Managerを導入することで問題2の解決策を提供します。これは、Longをレベルに分割することにより、階層ツリー内のフラットな識別子スペースを編成します。 デフォルトはFlat Ledger Managerです 。これは、新しいレジャーを頻繁に生成する場合には明らかに適用されません。

元帳入力/記録

レコードは元帳の要素です。 元帳の各レコードには、0から連続する増加する識別子があります。レコードには、バイト配列の形式で任意のデータが含まれます。 レコードの追加は、同期モードと非同期モードで実行できます。 非同期モードでは、通常どおり、マルチユーザーアプリケーションのパフォーマンスを向上させることができます。 すでに述べたように、非同期部分は、レコードが元帳に追加されたときに、つまり規則正しい方法で呼び出されます。

おそらく、これら3つの概念-Bookie、Ledger（元帳）、およびLedger Entry（レコード）は、Apache BookKeeperの作業を理解するための最も重要な要素です。

結論の代わりに

Apache BookKeeperは銀の弾丸や魔法の丸薬のようには見えませんが、これはCAP定理に決して矛盾しない非常に特殊な解決策であり、解決される問題にかなりの数の制限を課します。 幸いなことに、このコンポーネントを使用してシステムの水平スケーリングを提供できましたが、要件をサポートするために、途中でいくつかのエンジニアリングの問題を解決する必要がありました。

この記事は入門的な事実調査です。 Apache BookKeeperでHello Worldを簡単にすることは非常に簡単です。著者は詳細なスタートアップガイドを提供しますが、 Scalaでの実装を書き直しました。

RocksDBについて

RocksDBが選ばれた理由は、高性能であり、アトミックパケット書き込み（すべてまたは何もしない）をサポートしているためです。これにより、緊急事態の場合に正しい動作を保証できます。 タスクの一部として、前の状態をRocksDBから読み込み、元帳からすべてのアクションを減算し、RAMに最終状態を形成してRocksDBにアトミックに書き込みましたが、処理した元帳番号もレコードに移動しました。