[論文レビュー] Blade: A Data Center Garbage Collector

David Terei, Amit Levy|arXiv (Cornell University)|Apr 10, 2015

Advanced Data Storage Technologies参考文献 6被引用数 6

ひとこと要約

Bladeは、ガベージコレクション（GC）の待機時間を予測可能な障害とみなすことで、ガベージコレクションの同期を失敗回復メカニズムを用いて行う分散システム向けのGC協調APIである。これにより、HTTPロードバランサーやRaftコンセンサスなど、GCによる尾遅延を排除し、1回のネットワークラウンドトリップ（48 μs）に制限する。その結果、GCなしと同等のパフォーマンスを達成する。

ABSTRACT

An increasing number of high-performance distributed systems are written in garbage collected languages. This removes a large class of harmful bugs from these systems. However, it also introduces high tail-latency do to garbage collection pause times. We address this problem through a new technique of garbage collection avoidance which we call Blade. Blade is an API between the collector and application developer that allows developers to leverage existing failure recovery mechanisms in distributed systems to coordinate collection and bound the latency impact. We describe Blade and implement it for the Go programming language. We also investigate two different systems that utilize Blade, a HTTP load-balancer and the Raft consensus algorithm. For the load-balancer, we eliminate any latency introduced by the garbage collector, for Raft, we bound the latency impact to a single network round-trip, (48 μs in our setup). In both cases, latency at the tail using Blade is up to three orders of magnitude better.

研究の動機と目的

• 多くの現代の分散システムは、メモリバグの防止を可能にするが、GCの待機時間に起因する予測不能で高い尾遅延を引き起こすGo やJava といったガベージコレクション言語で構築されている。
• 既存のGC最適化は平均性能に焦点を当てており、マイクロ秒レベルの保証を必要とする現代のデータセンタワークロードにとって重要な尾遅延には対処できない。
• アプリケーションレベルでのGCチューニングは困難で、ワークロード依存的であり、GCを無効化するか、手動メモリ管理に移行すると、安全性と生産性が損なわれる。
• 本論文の目的は、GCタイミングをアプリケーション開発者が制御できるようにし、システムレベルの失敗回復メカニズムと統合することで、GC待機時間を隠蔽することにある。
• 目的は、下位のGCランタイムを変更することなく、生産環境システムにおけるGC関連の尾遅延を排除または制限することである。

提案手法

• Bladeは、ガベージコレクションの開始前にコールバックを登録できるシンプルなAPIを提供し、失敗回復メカニズムとの同期を可能にする。
• APIにより、アプリケーションはネットワークラウンドトリップ後や、既知のアイドル期間中にGCを遅延させることができる。
• GC待機時間を制御された障害の一種とみなすことで、リクエストレプリケーションやリーダ選挙といった既存のシステムレジリエンスパターンを活用し、影響を隠蔽する。
• このアプローチはGoランタイムに統合されており、言語やGC実装を変更せずにGC協調をオプトインできる。
• アプリケーションレベルの協調により、ノード間でのGCの重複を回避し、エンドツーエンドの遅延影響を低減する。
• HTTPロードバランサとRaftコンセンサスの2つの事例研究により、Bladeの実世界システムにおける有効性が示された。

実験結果

リサーチクエスチョン

• RQ1 GC最適化ではなく、アプリケーションレベルの協調によって分散システムにおけるGC待機時間を排除または制限できるか？
• RQ2 分散システムに既存の失敗回復メカニズムを再利用することで、GCランタイムを変更せずにGC待機時間の影響を隠蔽できるか？
• RQ3 Bladeは、デフォルトのGCとGCを完全に無効化した場合に比べて、エンドツーエンドの尾遅延においてどのように異なるか？
• RQ4 Bladeは、ガベージコレクションのないシステムと同等のパフォーマンスを実現できるか？
• RQ5 複数ノードにわたるGCの協調にBladeを用いる際のパフォーマンスオーバーヘッドや遅延影響は何か？

主な発見

• HTTPロードバランサのユースケースでは、BladeがGC関連の尾遅延を完全に排除し、GCのないシステムと区別できないパフォーマンスを達成した。
• Raftコンセンサスアルゴリズムでは、BladeがGCの影響を1回のネットワークラウンドトリップに制限し、実験環境で48 μsの測定値を得た。
• Bladeを用いたエンドツーエンド遅延は、GCのないシステムの最適パフォーマンスと一致しており、GCの影響を完全に隠蔽できることを示した。
• デフォルトのGoガベージコレクタと比較して、尾遅延が最大3桁改善された。
• Bladeは、低遅延コレクタを必要とせず、アプリケーションレベルの協調によって遅延低減を担うことで、高スループットでシンプルなGC設計を可能にする。
• この手法は一般化可能であり、GCランタイムの変更を必要とせず、同様のAPIを持つ他のガベージコレクション言語にも適用可能である。