FXトレードのために2010年10月にロンドンに設立されたthe LMAX Exchangeの開発者がAzulのZing JVMを使って、すでに高速なレスポンス時間とスループットをさらに改善しようとしている。
LMAX Exchangeは技術的選択を公表しようとする姿勢によって、金融業界の外でも名前が知られている。同社は自身のソフトウエアの中核のコンポーネントであるthe Disruptor frameworkを2011年3月に公開し、QConや他のカンファレンスでプレゼンを行っている。
昨年末、LMAX Exchangeはデータセンターの再構築を完了させ、IntelのHexaCore Dunningtonプロセッサを搭載したHewlett-Packardのサーバからデュアルソケット8コアのIntel Sandy Bridge CPUを搭載したDell 520と720へ移行した。Dellのサーバはそれぞれ64GBと128GBのメモリを搭載している。"これらのサーバは普通のサーバで、特にチューニングはしていません"とLMAX Exchangeのソフトウエア部門のヘッドであるMichael Barker氏は言う。
性能が重要なジャーナルベースのストレージとして、私たちはバッテリバックアップ式ライトキャッシュを利用した15k SASのRAIDを使用しています。テストしてみると、私たちのワークロードではひとつのRAIDアレイは複数のSSDと同等かそれ以上の性能を発揮しました。これはジャーナルを書き込むコードの品質の高さを示しています。
サーバ移行と同時に、同社はOSをCentOS 5からCentOS 6に変えた。"(Fedora Coreのようなディストリビューションではなく)CentOSのままにした理由のひとつは、Azul Zingをサポートしているからです"と氏は言う。しかし、現時点では、LMAX ExchangeはOracleのHotSpot JVMを利用している。
サーバはEquinixのデータセンターにある。多くの金融サービス事業者がここにサーバやアプリケーションを配置している。それゆえ、システム間のレイテンシは比較的小さい。同社はロンドンにDRデータセンターを持っている。また、テストと開発用の環境としてロンドン北部にもホスティングセンターを持っている。この環境ではOpenStackを利用したJenkinsベースの継続的統合システムを利用している。"AmazonやRackspaceのクラウドの利用も拡大しています。顧客のデータを持たないシステムやレイテンシを気にする必要がないシステムで利用しています"
同社は平均で秒間1,000から2,000の注文を処理している。ピーク時は秒間5,000を超える場合もある。まれに秒間20,000を超える場合もあるそうだ。"ピーク時の負荷をベースラインとしてテストしてます。テストを定期的に実行し、どの時点でシステムが処理しきれなくなるかを特定しています(‘レッドライン’テストと呼んでいます)"
LMAX Exchangeは性能についてのデータを公表している。それによれば、注文のレイテンシは平均で1.5ミリ秒、取引のレイテンシは、リアルタイムの取引前リスクコントロールの処理を含んで、エンドツーエンドで3ミリ秒以下だ。
素晴らしい性能だが、HotSpotの一部であるCMSコレクタのStop-the-World停止が引き起こす性能の変動が大きな問題になりつつある。同社はJDK 7でCMSのバージョンをあげようとしたが、GCによる停止の長さが20%程度上昇してしまった。原因は不明だが、Barker氏はコレクタを再びチューニングするしかないと考えた。そのような状況だったので、同社にとって、ほとんどチューニングが必要ないZingのコレクタ(C4)は魅力的に思えた。
私は、GCの設定をもう一度チューニングし、-XX:+UseCondCardMarkや-XX:+UseNUMAのようなJDK 7固有の設定を利用すべきか動作調査する必要があると考えていました。JDKの新しいバージョンはスクラッチでチューニングするというのが一般的な推奨事項で、理論的にはそのとおりなのですが、現実的ではありません。Oracle JDKでコレクタをチューニングするには幅広く調査して自分のニーズにあう方法を見つけなければなりません。経験と知識があり、推測しながら作業を進めれば、調査範囲を劇的に狭められるかもしれませんが、それでもチューニングには数週間はかかるでしょう。たとえば、私たちのエンドツーエンドの性能テストは全体で1時間かかります(10ぷんのビルドとデプロイ、10分のワームアップ、40分のテスト)ので、1日に8回テストが行えます。異なるコレクタ(CMS, Parallel, Serial,...)とそれぞれに関連するオプション(新しいオブジェクト領域のサイズと古いオブジェクト領域のサイズ、生存領域、生存率...)を考慮した場合、いったいどれくらいのテストを実行すれば、効果のある調査ができたといえるのでしょうか。Zingは初期状態で、しっかりチューニングしたOracle JDKよりも優れた性能を発揮します。Zing VMをチューニングすることでより性能を上げられるかどうかはまだ調査中ですが、Zingをチューニングするのは、すでに十分な性能のシステムを最高の状態にしようとすることと同じです。Oracle JDKの場合は、デフォルトからチューニングするかしないかがそのまま使い物になるかならないかの違いになる可能性があります。そしてこのようなチューニングは機会コストとなります。GCのチューニングに携わる開発者(ソフトウエアの性能について最高の実践的知見を持っているはずの)にはシステムのほかの領域の性能改善に注力してもらいたいのです。
ふたつの新しいコレクタも選択肢にあがった。IBMのBalanced GCとOracleのG1だ。このふたつは互いに無関係に開発されていたが驚くほどよく似ており、定期的な低停止時間を提供することを目的にしている。あるメモリ領域が他のメモリ領域よりも頻繁にアクセスされているという前提で動作する増分圧縮法は、一度にひとつの領域を圧縮し、すべての潜在的な参照を再マップするときにだけその領域を参照している領域をスキャンする。しかし、大多数のアプリケーションの場合、この前提は妥当だが、すべてのアプリケーションに当てはまるわけではない。さらに、Balanced GCもG1も並列マーカーと古い世代のオブジェクトに対する増分圧縮を実行するが、Stop-the-Worldコレクタを実行して性能を落としてしまう。そして、AzulのC4以外の他の有償コレクタと同様、新しい世代のオブジェクトに対しては、並列ではないStop-the-Worldコレクタを実施する。AzulのC4は新しい世代にも古い世代にも完全に並列な圧縮アルゴリズムを適用するので性能が劣化しない。InfoQでは以前、このアルゴリズムの詳細を報じている。
このような状況から、LMAX ExchangeはG1もBalanced GCも試さなかった。Barker氏曰く、"両方ともCMSが原理的に抱える問題と同じ問題を持っています。潜在的な停止を遅らせることはできますが、完全に排除できません"
...市場で調達できるGCの実装の中で、ほかの[うまくいきそうな]選択肢はIBMのMetronomeコレクタとJRockitのReal Timeコレクタです。Metronomeは非常に興味深く、時間を使って詳しく調べてみたいと思ったほどです。しかし、いくつかの懸案事項が見つかり、テストする時間が取れませんでした。IBMの名誉のために言えば、私たちはほとんどのアプリケーションが利用していないJDKの重箱の隅に進出していたのです。私が見つけた懸念点をしかるべき人に報告したところ、すぐさま修正してくれました。JRockit Real Timeは残念ながらOracleが開発を停止してしまいました。JDK 1.6より新しいバージョンには対応しないでしょう。もう技術的選択肢にはならなそうです。
Azul Zingはうまく動作し成果を上げました。また、Azulのチームは私たちのユースケースで成果が出るようにZingの改善を行ってくれました。それで、Zingに決めたのです。
結果、目覚しい成果を上げることができた。レイテンシは平均で10-20%改善し、99パーセンタイルでは、50%も改善した。さらに、
HotSpotの最大パーセンタイルや99.99パーセンタイルの値はばらつきが大きく、Zingと比較できません。はっきりしているのは、Zingの値は安定しているということです。HotSpotは悪い場合は劇的に悪化します。
スループットについては、
Zingは"レッドライン"を持ち上げてくれました。レッドラインというのはレイテンシが一気に悪化するスループット値のことです。この悪化はGCによる停止の副次的効果の表れです。私たちは長い時間速度低下が発生した場合は、パケットのドロップし始めます。パケットの再送はシステムの残りの部分に負荷をかけしてしまい、クライアント側のレイテンシは急上昇します。停止時間が短いより効率的なコレクタを使うことで"レッドライン"を押し上げることができたのです。
Barker氏は、性能のばらつきを生み出す問題は他にもたくさんあると指摘する。悪いコード、OSの動作不安定、ロックコンテンション、LMAX Exchangeと顧客の間の帯域幅などだ。"しかし、もっとも性能を劣化させているのはGCだったのです。ほとんどの性能チューニング作業と同様、最大の問題から片付けるのが得策です"
AzulはZingのおかげで金融サービス事業者の中で良い評判を得ている。AzulのCTOであるGil Tene氏によれば、Azulの金融サービス業の顧客の中で、LMAX Exchangeは優れた技術と素晴らしい性能で知られているが、もっともレイテンシを追求している企業ではない。"もっとレイテンシを追求している顧客もいます"
金融サービス事業者にとってZingが魅力的なのは、古い世代と新しい世代のオブジェクト両方に対してStop-the-World停止を行わない唯一のコレクタだからだ。新しい世代のオブジェクトに対する処理に伴う停止が短いとしても、性能が重要なアプリケーションにとっては問題だ。Tene氏によれば、
...さらにZingは秒間数GBのアロケーションをレイテンシや停止なしで処理します。これは、"苦痛"を理由にこのようなアロケーションをしないように注力してきた開発者にとって魅力的です。Zingを使えば、豊富なメモリを利用できます。問題が起きないように大量のメモリを使うのを避ける必要はありません。
運用環境でZingを使うにはサーバごとに年間の料金が発生する。Azulは金額を公表していないが、OracleやIBMのサポート付きのJVMと同等の価格だ。
Zingはオープンソースではないが、オープンソース開発者は無償で利用できる。