Aeron：HFT業界の半分を支えるメッセージングシステムの仕組み

Aeron：Media Driver、共有メモリ、トリプルバッファログ——低遅延メッセージングの標準を打ち立てたアーキテクチャ。

高頻度取引のメッセージングシステムについて語るとき、必ず話題に上がる名前がある——Aeron。Martin ThompsonとReal Logicチーム（後にAdaptive Financial Consulting）によって開発されたAeronは、マイクロ秒が全てを決する世界におけるデータ転送のデファクトスタンダードとなった。

本記事では、Aeronの各コンポーネントを分解して解説する：Transport、Archive、Cluster、Sequencer。内部構造、強み、そして問題が生じ始める箇所を明らかにする。

概要

• Aeron——低遅延アプリケーション向けオープンソース（Apache 2.0）メッセージングシステム
• IPCレイテンシ：共有メモリ経由で約250ナノ秒（往復）
• スループット：毎秒2,000万メッセージ以上
• 4つの製品：Transport（コア）、Archive（記録/リプレイ）、Cluster（Raft）、Sequencer（全順序）
• 言語：Java（メイン）+ Cクライアント（機能限定）
• 利用者：数十のHFT企業、マーケットメイカー、取引所

第1部：Aeron Transport——全ての基盤

アーキテクチャ：Media Driver

Aeronの中核コンポーネントはMedia Driverである。独立プロセス（またはembeddedライブラリ）として動作し、全てのデータ転送を管理する。アプリケーションは共有メモリ（/dev/shmのmmapファイル）を通じてMedia Driverと通信する。

┌──────────┐                    ┌──────────────┐                    ┌──────────┐
│ Publisher │ ── shm commands ─→│ Media Driver  │←─ shm commands ── │Subscriber│
│   (App)   │ ←─ shm responses─│  (process)    │─→ shm responses  │  (App)   │
└──────────┘                    │              │                    └──────────┘
                                │ Log Buffers  │
                                │ (data path)  │
                                └──────┬───────┘
                                       │
                                    Network
                                  (UDP/IPC)

主要データ構造：

• ManyToOneRingBuffer（MPSC）——クライアントからMedia Driverへのコマンド
• BroadcastTransmitter/Receiver——Media Driverからクライアントへのレスポンス
• Log Buffers——データ用のトリプルバッファ追記型ログ
• Position Counters——位置調整用のアトミックカウンタ

Log Buffers：トリプルバッファリング

Aeronのデータ転送はLog Buffersを通じて行われる——3つのterm bufferが交互に使用される。1つのバッファが満杯になると次のバッファに切り替わる（term rotation）。これにより、publisherが1つのバッファに書き込みながら、subscriberが別のバッファから読み取ることが可能になる。

各term bufferのサイズは64 KBから1 GBの範囲で、Publication作成時に固定される。

プロトコル

AeronはUDP上に独自のwire protocolを使用する：

• Data frames——ヘッダ付きの実データ（stream ID、session ID、term ID、offset）
• Status Messages——フロー制御（receiverが自身の位置を報告）
• NAK——再送要求（receiver駆動）
• Setup——接続確立
• Heartbeat——活性確認

パフォーマンス

公表されている性能指標：

これらの数値は印象的だ。ただし注意点がある——Java上で計測されたものであり、JVMの影響を受ける。

第2部：Aeron Archive——記録と再生

Archiveは、メッセージをディスクに保存し、任意の位置からリプレイする機能を提供する。

動作原理

1. ArchiveプロセスがAeron Transportを通じてストリームをサブスクライブ
2. 全メッセージがセグメント化されたファイルとしてディスクに記録
3. 必要に応じてリプレイ：Archiveが記録データから新しいPublicationを作成
4. クライアントがリプレイストリームをサブスクライブして過去のメッセージを受信

用途

• 監査——規制当局が全メッセージの保存を要求
• 障害復旧——新ノードがリプレイでリーダーに「追いつく」
• 分析——戦略バックテスト用にストリームをリプレイ
• デバッグ——正確なイベントシーケンスを再現

第3部：Aeron Cluster——Raftコンセンサス

Clusterは、Raftコンセンサスに基づくフォールトトレラントなレプリケーテッドステートマシンである。メッセージの欠落が許されないミッションクリティカルなシステム（マッチングエンジン、注文管理）で使用される。

動作原理

1. Leaderが全ての受信コマンドを処理
2. Aeron Transportを通じて各レコードをfollowersにレプリケート
3. 過半数が確認後——レコードがcommittedとなる
4. committedされたレコードがステートマシンに適用

特性

• 自動リーダー選出とフェイルオーバー（1秒未満）
• 強整合性（リーダー経由の線形化可能読み取り）
• ホットシステムアップグレード
• スループット：Raftコンセンサスで毎秒数百万メッセージ

第4部：Aeron Sequencer——統一されたイベント順序

Sequencerは資本市場向けに最適化された新製品（2025年）。

課題

マーケットメイキングや取引所では、全参加者が同一のイベント順序を確認できることが極めて重要である。Sequencerは全順序（total ordering）——全メッセージに対する統一されたグローバル順序を保証する。

アーキテクチャ

• Aeron Cluster上に構築
• 複数マシンにレプリケートされた分散ログ
• マルチリーダー——複数アプリケーションが同一ログを読み取り
• チーム分離——チームが統一された順序付けの枠組み内で独立して作業

制約

Sequencerは Adaptive Financial Consultingの商用製品。クローズドソース。Clusterの全ての弱点を継承。

Aeronの弱点

多くの利点がある一方で、Aeronには根本的な制約がある：

1. JVM依存

off-heapメモリを使用していても、JVMのsafepointは全スレッドを停止させる。GuaranteedSafepointInterval=300000はワークアラウンドに過ぎず、根本的な解決策ではない。JITウォームアップにより起動後の数分間は予測不能な挙動が生じる。

Cクライアントは存在するが、機能が不完全——ArchiveもClusterもない。

2. Media Driverのオーバーヘッド

別プロセスということは、共有メモリを経由する追加のホップを意味する。Embeddedモードを使えばJVMに縛られる。どちらの場合も余分な不確実性が生じる。

3. 固定サイズのLog Buffers

3つのterm bufferがあり、サイズは作成時に固定。アダプティブなメモリ管理がない。大きすぎればRAMの無駄、小さすぎれば頻繁なterm rotationが発生。

4. ネイティブカーネルバイパスの不在

ネットワークはUDPのみ。io_uring、DPDK、AF_XDPには非対応。Aeron Premiumがカーネルバイパスを追加するが、クローズドソースの有料製品である。

5. SBE——別途の依存

XMLスキーマ、Javaコードジェネレータ、独立したビルドステップ。言語への統合がない。

6. ゼロコピーネットワーキングの不在

データはソケットからlog bufferにコピーされる。Linux 6.0以降ではio_uringがゼロコピー送受信を可能にするが、Aeronはこの機能を活用していない。

代替手段

私たちMarketmaker.ccはZigBoltを開発した——Zig言語によるオープンソースのAeron代替。JVMなし、GCなし、comptimeコーデックと20ナノ秒のSPSCレイテンシ。詳しくはZigBoltに関する記事をご覧ください。

まとめ

Aeronは低遅延メッセージングの標準を確立した卓越したエンジニアリングプロジェクトである。そのアーキテクチャ上の設計判断（トリプルバッファログ、NAKベースの信頼性、Raftクラスタ）は模範となっている。

しかし、世界は進化し続けている。ZigやRustのような言語は、JVMオーバーヘッドなしで同等（またはそれ以上）の成果を達成できる。io_uringやDPDKによるカーネルバイパスは、純粋なUDPでは不可能な可能性を切り開く。comptimeコード生成は、独立したXMLスキーマやJavaコードジェネレータを過去の遺物にしつつある。

Aeronは今後も数十の企業の本番環境で何年も稼働し続けるだろう。しかし新規プロジェクトには、代替手段を検討する価値がある——ZigBoltを含めて。

参考リンク：

• Aeron GitHub: github.com/real-logic/aeron
• Aeron Wiki: github.com/real-logic/aeron/wiki
• Martin Thompson（開発者）: mechanical-sympathy.blogspot.com
• ZigBolt（私たちの代替手段）: 記事 | サイト
• Marketmaker.cc: marketmaker.cc

引用

@article{soloviov2026aeron,
  author = {Soloviov, Eugen},
  title = {Aeron: HFT業界の半分を支えるメッセージングシステムの仕組み},
  year = {2026},
  url = {https://marketmaker.cc/ja/blog/post/aeron-messaging-overview},
  description = {Aeronアーキテクチャの解説——Transport、Archive、Cluster、Sequencer。強みと弱み。}
}