LMAXアーキテクチャ

全体構造

図1：3つのブロックによるLMAXのアーキテクチャ

トップレベルでは、アーキテクチャは3つの部分から構成されています。

• ビジネスロジックプロセッサ[5]
• 入力ディスラプター
• 出力ディスラプター

名前が示すように、ビジネスロジックプロセッサはアプリケーション内のすべてのビジネスロジックを処理します。前述のように、これはメソッド呼び出しに応答し、出力イベントを生成する単一スレッドのJavaプログラムとして実行されます。その結果、JVM自体以外のプラットフォームフレームワークを必要としない単純なJavaプログラムであるため、テスト環境で簡単に実行できます。

ビジネスロジックプロセッサはテストのために単純な環境で実行できますが、本番環境で実行するためのより多くの複雑な調整が必要です。入力メッセージはネットワークゲートウェイから取得され、アンマーシャリング、複製、ジャーナリングする必要があります。出力メッセージはネットワーク用にマーシャリングする必要があります。これらのタスクは、入力および出力ディスラプターによって処理されます。ビジネスロジックプロセッサとは異なり、これらはIO操作が遅く独立しているため、並列コンポーネントです。これらはLMAX向けに特別に設計および構築されましたが、（全体的なアーキテクチャと同様に）他の場所でも適用できます。

ビジネスロジックプロセッサ

入出力ディスラプター

ビジネスロジックは単一のスレッドで発生しますが、ビジネスオブジェクトメソッドを呼び出す前に実行する必要があるタスクがいくつかあります。処理のための元の入力はメッセージの形でワイヤから取得されます。このメッセージは、ビジネスロジックプロセッサが使用しやすい形式にアンマーシャリングする必要があります。イベントソーシングは、すべての入力イベントの永続的なジャーナルを保持することに依存しているため、各入力メッセージを永続的なストアにジャーナリングする必要があります。最後に、アーキテクチャはビジネスロジックプロセッサのクラスタに依存しているため、このクラスタ全体で入力メッセージを複製する必要があります。同様に、出力側では、ネットワークを介して送信するために出力イベントをマーシャリングする必要があります。

図2：入力ディスラプターによって実行されるアクティビティ（UMLアクティビティ図表記を使用）

レプリケーターとジャーナラーはIOを含み、したがって比較的遅いです。結局のところ、ビジネスロジックプロセッサの中心的なアイデアは、IOを実行しないことです。また、これらの3つのタスクは比較的独立しており、ビジネスロジックプロセッサがメッセージを処理する前にすべて実行する必要がありますが、任意の順序で実行できます。したがって、後続の取引の市場を変化させる各取引が行われるビジネスロジックプロセッサとは異なり、並行処理に自然に適合します。

この並行処理を処理するために、LMAXチームは、**ディスラプター**[11] と呼ばれる特別な並行処理コンポーネントを開発しました。

大雑把に言うと、ディスラプターは、プロデューサーがオブジェクトを配置し、すべてのコンシューマーに送信されて、個別のダウンストリームキューを介して並列に消費されるキューのマルチキャストグラフと考えることができます。内部を見ると、このキューネットワークは実際には単一のデータ構造であるリングバッファーであることがわかります。各プロデューサーとコンシューマーには、現在作業中のバッファーのスロットを示すシーケンスカウンターがあります。各プロデューサー/コンシューマーは独自のシーケンスカウンターを書き込みますが、他のシーケンスカウンターを読み取ることができます。このように、プロデューサーはコンシューマーのカウンターを読み取って、書き込みたいスロットが利用可能であることを確認できます。同様に、コンシューマーは、カウンターを監視することで、別のコンシューマーが処理を完了するまでメッセージを処理しないようにすることができます。

図3：入力ディスラプターは1つのプロデューサーと4つのコンシューマーを調整します

出力ディスラプターは似ていますが、マーシャリングと出力のために2つのシーケンシャルコンシューマーしかありません[12]。出力イベントは複数のトピックに整理されているため、メッセージは関心のある受信者だけに送信できます。各トピックには独自のディスラプターがあります。

説明したディスラプターは、1つのプロデューサーと複数のコンシューマーというスタイルで使用されていますが、これはディスラプターの設計の制限ではありません。ディスラプターは複数のプロデューサーでも動作し、この場合でもロックは必要ありません[13]。

ディスラプター設計の利点は、問題が発生して遅れが生じた場合でも、コンシューマーが迅速に追いつくことが容易になることです。アンマーシャラーがスロット15の処理中に問題が発生し、受信者がスロット31にいるときに戻った場合、スロット16〜30のデータを一括で読み取って追いつくことができます。ディスラプターからのデータの一括読み取りにより、遅れているコンシューマーが迅速に追いつくことが容易になり、全体的なレイテンシが減少します。

ここでは、ジャーナラー、レプリケーター、アンマーシャラーをそれぞれ1つずつ説明しましたが、これはLMAXが行っていることです。しかし、この設計では、これらのコンポーネントを複数実行できます。2つのジャーナラーを実行した場合、1つは偶数スロットを処理し、もう1つは奇数スロットを処理します。これにより、必要に応じてこれらのIO操作の並行処理がさらに可能になります。

リングバッファーは大きいです。入力バッファーには2000万スロット、各出力バッファーには400万スロットあります。シーケンスカウンターは、リングスロットがラップされても単調増加する64ビット長の整数です[14]。バッファーは2の累乗のサイズに設定されているため、コンパイラーはシーケンスカウンター番号からスロット番号へのマッピングに効率的なモジュラス演算を実行できます。システムの他の部分と同様に、ディスラプターは一晩でリスタートされます。このリスタートは主にメモリをクリアするために実行され、取引中の高価なガベージコレクションイベントの可能性が低くなります。（緊急時にも実行方法を練習するために、定期的に再起動することも良い習慣だと思います。）

ジャーナラーの役割は、すべてのイベントを永続的な形式で保存し、何か問題が発生した場合に再生できるようにすることです。LMAXはこれにはデータベースを使用せず、ファイルシステムのみを使用します。彼らはイベントをディスクにストリーミングします。現代的な観点から見ると、機械式ディスクはランダムアクセスには非常に遅いが、ストリーミングには非常に高速です。そのため、「ディスクは新しいテープ」というキャッチフレーズが付けられています[15]。

前に述べたように、LMAXは迅速なフェイルオーバーをサポートするために、システムの複数のコピーをクラスタで実行しています。レプリケーターはこれらのノードを同期状態に保ちます。LMAXのすべての通信はIPマルチキャストを使用するため、クライアントはリーダーノードがどのIPアドレスであるかを認識する必要はありません。リーダーノードだけが直接入力イベントをリッスンし、レプリケーターを実行します。レプリケーターは入力イベントをフォロワーノードにブロードキャストします。リーダーノードがダウンした場合、ハートビートの欠如が認識され、別のノードがリーダーになり、入力イベントの処理を開始し、レプリケーターを開始します。各ノードには独自の入力ディスラプターがあり、したがって独自のジャーナルを持ち、独自のアンマーシャリングを実行します。

IPマルチキャストを使用しても、IPメッセージは異なるノードで異なる順序で到着する可能性があるため、レプリケーションは依然として必要です。リーダーノードは、残りの処理のための決定論的なシーケンスを提供します。

アンマーシャラーは、ワイヤからのイベントデータを、ビジネスロジックプロセッサで動作を呼び出すために使用できるJavaオブジェクトに変換します。したがって、他のコンシューマーとは異なり、アンマーシャリングされたオブジェクトを格納できるように、リングバッファー内のデータを変更する必要があります。ここでのルールは、コンシューマーはリングバッファーに書き込むことが許可されますが、各書き込み可能なフィールドには、それに書き込むことが許可されている並列コンシューマーが1つだけ存在できます。これにより、単一のライターのみを持つという原則が維持されます。[16]

図4：ディスラプターを展開したLMAXアーキテクチャ

ディスラプターは、LMAXシステム以外でも使用できる汎用コンポーネントです。通常、金融会社はシステムについて非常に秘密主義であり、ビジネスに関係のない項目についても黙っています。LMAXは全体的なアーキテクチャについてオープンなだけでなく、ディスラプターコードをオープンソース化しました。これは私を非常に幸せにする行為です。これにより、他の組織がディスラプターを使用できるようになるだけでなく、その並行処理特性のテストも可能になります。

キューと機械的共感の欠如

LMAXアーキテクチャは、多くの人が考えているものとは非常に異なる方法で高性能システムにアプローチするため、人々の注目を集めました。これまで、その仕組みについて説明してきましたが、なぜこのように開発されたのかについてはあまり詳しく説明していません。この物語自体も興味深いものです。なぜなら、このアーキテクチャは突然現れたわけではないからです。より従来の代替案を試してみて、その欠陥を認識するのに長い時間がかかり、チームがこのアーキテクチャに落ち着くまで時間がかかりました。

現代の多くのビジネスシステムは、トランザクションデータベースによって調整された複数のアクティブセッションに依存するコアアーキテクチャを持っています。LMAXチームはこのアプローチに精通していましたが、LMAXには適していないと確信していました。この評価は、LMAXを設立した親会社であるBetfairの経験に基づいています。Betfairは、スポーツイベントへの賭けを可能にするベッティングサイトです。非常に大量のトラフィックと多くの競合を処理します - スポーツベッティングは特定のイベントを中心にバーストする傾向があります。これを機能させるために、彼らは最高のデータベースインストールの1つを持っており、機能させるために多くの非自然な行為をしなければなりませんでした。この経験に基づいて、彼らはBetfairのパフォーマンスを維持することがいかに困難であるかを知っており、この種のアーキテクチャは、取引サイトに必要な非常に低いレイテンシには適していないと確信していました。その結果、彼らは異なるアプローチを見つけなければなりませんでした。

彼らの最初の取り組みは、今日多くの人が言っていること、つまり高性能を得るには明示的な並行処理を使用する必要があるということでした。このシナリオでは、これは注文を複数のスレッドで並列に処理することを意味します。しかし、並行処理の場合によくあることですが、困難はこれらのスレッドがお互いに通信しなければならないことです。注文を処理すると市場状況が変化し、これらの状況を伝える必要があります。

彼らが初期に検討したアプローチは、アクタモデルとその近縁であるSEDAでした。アクタモデルは、独自のThreadを持ち、キューを介してお互いに通信する独立したアクティブオブジェクトに依存しています。多くの人は、この種の並行処理モデルの方が、ロックプリミティブに基づいた何かを行うよりもはるかに扱いやすいと感じています。

チームはアクタモデルを使用してプロトタイプ交換機を構築し、そのパフォーマンステストを行いました。彼らが発見したのは、プロセッサがアプリケーションの実際のロジックを実行するよりもキューの管理に多くの時間を費やしていたことです。キューへのアクセスがボトルネックでした。

このようなパフォーマンスを追求すると、最新のハードウェアの構成方法を考慮することが重要になります。マーティン・トンプソンが好んで使用するフレーズは「メカニカルシンパシー」です。この用語はレーシングカーの運転から来ており、ドライバーが車に対する生まれつきの感覚を持っていることを反映しており、最高の性能を引き出す方法を感じることができます。多くのプログラマー、そして私もこの陣営に属していると告白しますが、プログラミングがハードウェアとどのように相互作用するかについて、それほどメカニカルシンパシーを持っていません。さらに悪いことに、多くのプログラマーはメカニカルシンパシーを持っていると考えていますが、それは数年前に時代遅れになったハードウェアの動作に関する概念に基づいています。

レイテンシに影響を与える最新のCPUの支配的な要因の1つは、CPUがメモリとどのように相互作用するかです。今日では、CPUの観点から見ると、メインメモリにアクセスするのは非常に遅い操作です。CPUには複数のレベルのキャッシュがあり、それぞれがはるかに高速です。そのため、速度を上げるには、コードとデータをこれらのキャッシュに取得する必要があります。

あるレベルでは、アクタモデルはここで役立ちます。アクタを、コードとデータをクラスタ化する独自のオブジェクトと考えることができます。これはキャッシングのための自然な単位です。しかし、アクタは通信する必要があり、それはキューを介して行われます。そしてLMAXチームは、キューがキャッシングを妨げていることを観察しました。

説明は次のようになります。キューにデータを入れるには、そのキューに書き込む必要があります。同様に、キューからデータを取り出すには、削除を実行するためにキューに書き込む必要があります。これは書き込み競合です。複数のクライアントが同じデータ構造に書き込む必要がある可能性があります。書き込み競合に対処するために、キューは多くの場合ロックを使用します。しかし、ロックを使用すると、カーネルへのコンテキストスイッチが発生する可能性があります。これが発生すると、関連するプロセッサはキャッシュ内のデータを失う可能性が高くなります。

彼らが到達した結論は、最高のキャッシング動作を得るには、任意のメモリ位置に書き込むコアが1つしかない設計が必要である[17]ということです。複数の読み取りは問題ありません。プロセッサは、多くの場合、キャッシュ間に特別な高速リンクを使用します。しかし、キューは1つの書き込み元という原則に適合しません。

この分析により、LMAXチームは2つの結論に至りました。まず、単一書き込み元制約を断固として守るディスラプターの設計につながりました。次に、単一スレッドビジネスロジックアプローチを探求するというアイデアにつながり、並行処理管理から解放された単一スレッドがどれだけの速度を出せるかを問いました。

単一スレッドで作業することの本質は、1つのコアで実行される1つのスレッドを持ち、キャッシュをウォームアップし、可能な限り多くのメモリアクセスをメインメモリではなくキャッシュに移動することです。これは、コードとデータのワーキングセットの両方を可能な限り一貫してアクセスする必要があることを意味します。また、コードとデータをまとめて小さなオブジェクトを保持することで、それらを単位としてキャッシュ間でスワップすることができ、キャッシュ管理を簡素化し、パフォーマンスをさらに向上させることができます。

LMAXアーキテクチャへの道のりの重要な部分には、パフォーマンステストの使用がありました。アクタベースのアプローチの検討と放棄は、プロトタイプの構築とパフォーマンステストから生まれました。同様に、さまざまなコンポーネントのパフォーマンス向上における多くのステップは、パフォーマンステストによって可能になりました。メカニカルシンパシーは非常に価値があります。それは、どのような改善ができるかについての仮説を立てるのに役立ち、後退ではなく前進へと導きます。しかし、最終的にはテストによって説得力のある証拠が得られます。

ただし、このスタイルのパフォーマンステストは、十分に理解されていないトピックです。LMAXチームは定期的に、意味のあるパフォーマンステストを考案することは、本番コードを開発するよりも難しいことが多いと強調しています。適切なテストを開発するには、メカニカルシンパシーも重要です。CPUのキャッシング動作を考慮せずに低レベルの並行コンポーネントをテストしても意味がありません。

特に重要な教訓の1つは、パフォーマンステストが実際に実際のコンポーネントが行っていることを測定するのに十分な速度であることを確認するために、nullコンポーネントに対してテストを作成することの重要性です。高速なテストコードを書くことは、高速な本番コードを書くことと同じくらい容易ではなく、テストが測定しようとしているコンポーネントほど高速ではないため、誤った結果を得やすくなります。

このアーキテクチャを使用すべきか？

一見、このアーキテクチャは非常に小さなニッチなもののように見えます。結局のところ、それを導いたドライバーは、非常に低いレイテンシで多くの複雑なトランザクションを実行することでした。ほとんどのアプリケーションは、600万TPSで実行する必要はありません。

しかし、このアプリケーションで私を魅了するものは、多くのソフトウェアプロジェクトを悩ませるプログラミングの複雑さの大部分を排除する設計にたどり着いたことです。トランザクションデータベースを取り巻く従来の同時セッションモデルは、問題がないわけではありません。データベースとの関係には通常、取るに足りない努力が必要です。オブジェクト/リレーショナルマッピングツールは、データベースの処理に伴う多くの痛みを軽減するのに役立ちますが、すべてを解決するわけではありません。エンタープライズアプリケーションのパフォーマンスチューニングのほとんどは、SQLの微調整に関係しています。

今日では、私たち古い世代がディスク容量として入手できたよりも多くのメインメモリをサーバーに搭載できます。ますます多くのアプリケーションが、すべてのワーキングセットをメインメモリに配置できるようになり、複雑さと遅滞の両方の原因を排除しています。イベントソーシングは、インメモリシステムの耐久性問題を解決する方法を提供し、単一スレッドですべてを実行することで、並行処理の問題を解決します。LMAXの経験は、数百万TPS未満であれば、十分なパフォーマンスヘッドルームがあることを示唆しています。

CQRSへの関心の高まりと、ここではかなりの重複があります。イベントソーシングされたインメモリプロセッサは、CQRSシステムのコマンド側の自然な選択肢です。（ただし、LMAXチームは現在CQRSを使用していません。）

では、この道に進まないことを示すものは何でしょうか？これは、このあまり知られていないテクニックの場合、常に難しい質問です。なぜなら、この専門分野は境界を探求するのにさらに時間が必要だからです。しかし、出発点は、アーキテクチャを促進する特性を考えることです。

1つの特性は、これは接続されたドメインであり、1つのトランザクションを処理すると、それに続くトランザクションの処理方法が常に変更される可能性があることです。互いに独立したトランザクションが多いほど、調整の必要性が少なくなり、並列で実行される個別のプロセッサを使用することがより魅力的になります。

LMAXは、イベントが世界をどのように変えるかの結果を理解することに集中しています。多くのサイトは、既存の情報ストアを取り、その情報のさまざまな組み合わせをできるだけ多くの目に届けることに関心があります。たとえば、メディアサイトを考えてみてください。ここでは、アーキテクチャ上の課題は多くの場合、キャッシュを正しく設定することにあります。

LMAXのもう1つの特性は、バックエンドシステムであるため、対話モードで動作するものにどの程度適用できるかを検討するのは妥当です。Webアプリケーションは、このアーキテクチャにうまく適合する側面である、要求に反応するサーバーシステムに慣れさせてくれます。このアーキテクチャがほとんどのそのようなシステムよりもさらに進んでいるのは、非同期通信の絶対的な使用であり、前に概説したプログラミングモデルの変更につながります。

これらの変更には、ほとんどのチームが慣れるのに時間がかかります。ほとんどの人は同期的な観点からプログラミングすることを好み、非同期性の処理には慣れていません。しかし、非同期通信は応答性にとって不可欠なツールであることは長い間真実です。AJAXやnode.jsによるJavaScriptの世界での非同期通信のより広範な使用が、より多くの人々がこのスタイルを調査することを促すかどうかは興味深いでしょう。LMAXチームは、非同期スタイルに適応するのに少し時間がかかったものの、すぐに自然になり、多くの場合より簡単になったとわかりました。特に、このアプローチではエラー処理がはるかに簡単になりました。

LMAXチームは確かに、調整されたトランザクションデータベースの時代は数少ないと感じています。この種のアーキテクチャを使用してソフトウェアをより簡単に記述でき、より高速に実行できるという事実は、従来の中央データベースの正当性の多くを取り除きます。

私自身は、これは非常にエキサイティングなストーリーだと考えています。私の目標の多くは、複雑なドメインをモデル化するソフトウェアに集中することです。このようなアーキテクチャは懸念事項の優れた分離を提供し、ドメイン駆動設計に集中し、プラットフォームの複雑さの大部分を適切に分離することができます。ドメインオブジェクトとデータベース間の密結合は常に問題でした。このようなアプローチは、解決策を示唆しています。