| Project/Area Number |
22K12048
|
|---|
| Research Category |
Grant-in-Aid for Scientific Research (C)
|
| Allocation Type | Multi-year Fund |
|---|
| Section | 一般 |
|---|
| Review Section |
Basic Section 60090:High performance computing-related
|
|---|
| Research Institution | Nagoya Institute of Technology |
|---|
Principal Investigator |
松尾 啓志 名古屋工業大学, 工学(系)研究科(研究院), 教授 (00219396)
|
|---|
| Project Period (FY) |
2022-04-01 – 2025-03-31
|
| Project Status |
Granted (Fiscal Year 2023)
|
| Budget Amount *help |
¥4,160,000 (Direct Cost: ¥3,200,000、Indirect Cost: ¥960,000)
Fiscal Year 2024: ¥1,040,000 (Direct Cost: ¥800,000、Indirect Cost: ¥240,000)
Fiscal Year 2023: ¥1,040,000 (Direct Cost: ¥800,000、Indirect Cost: ¥240,000)
Fiscal Year 2022: ¥2,080,000 (Direct Cost: ¥1,600,000、Indirect Cost: ¥480,000)
|
|---|
| Keywords | DPDK / プロトコルスタック / L2通信 / プロキシ / データ交換モデル / RPC / クロスレイヤー最適化 |
|---|
| Outline of Research at the Start |
第一番目の学術的な問いは、耐故障性・相互運用性の排除を前提とした新しいデータ交換モデルを再設計することにより、分散計算性能がどこまで向上できるか？である。
第二番目の学術的な問いは、CPUリソースを演算リソースとしてのみ利用してきた従来の分散計算フレームワークの実装に対して、ネットワーク・二次記憶へのアクセススタックとして用いた時の性能向上の可能性である。当然CPU Coreリソーススケジューリングや、ユーザレベル（プログラム）からの、例えばスピンロック頻度など、クロスレイヤー最適化も必要となる。
|
| Outline of Annual Research Achievements |
申請者は、Sparkに於ける通信時のキャッシュメカニズムのオーバヘッド低減について複数の検討を行ってきたが、その性能向上は十数パーセントであった。大規模なバッチ処理では、かなりの効果があると考えられるが、例えばDeep Learning処理系の代表例であるTensor Flow(GPU非使用時)に比べると数十分の一の性能しか得られなかった。この原因を解析する上で、2つの問題点に着想した。(1)RDDやその発展系であるDataFrame, Datasetは、耐故障性と相互運用性の実現から、処理オーバヘッドが高く、これ以上の劇的な性能向上は不可能であること。(2)複数サーバー間での高い通信レイテンシが、Sparkの処理単位であるタスクとスケジューラ通信で大きなコストとなっていることである。
例えば、Sparkで分散Deep Learningを実現するためのプロジェクトとして、Project Hydrogenがある。Project Hydrogenの目指すゴールは、本研究が目指すゴールと同様である。しかしアプローチが全く異なる。一つは、本研究がSparkの基本的な特徴である耐故障性と、相互運用性を捨てるところから始まっていることである。つまりDL処理の大部分の実行時間を、数時間から十数時間と想定した場合の故障率と、耐故障性を実現するオーバヘッドを考慮した場合の耐故障性の実装は、性能低下に見合わないと判断したところが、全く異なる。
さらに本研究ではProject Hydrogen が対象としていないクロスレイヤー間での通信スタックも最適化の対象としている。つまりDPDK,SPDKを用いて通信速度・レイテンシを最適化するとともに、Project HydrogenがGPUをスケジューリング対象にしたのと同様に、CPU Coreを動的スケジューリングの対象とするところに新規性を有する。
|
| Current Status of Research Progress |
Current Status of Research Progress
2: Research has progressed on the whole more than it was originally planned.
Reason
本年度は主に２つのテーマについて進捗があった。
まずDPDKを用いた透過型L2プロキシでKVSのキャッシュを行う手法を提案した．DPDKによりコンテキスト切り替えのオーバーヘッドを解消し，OSI参照モデルのデータリンク層でキャッシュ制御を行い，キャッシュヒット時にプロキシがレスポンスを送信してスループットを向上させた．インメモリDBであるRedisに適用して提案手法の性能を評価した結果，キャッシュヒット時においてレイテンシを36%削減した．また，READリクエスト割合の増加に伴いスループット性能が向上し，公式のRedisと比較して最大13.6倍向上した．
次に、RDBMSと同様の一貫性を保証しつつ，NoSQLと同様なスケーラビリティを実現するNewSQLが利用されている．NewSQLはタイムスタンプを使用することで分散環境下でもRDBMSと同様のトランザクション処理機能を提供する．NewSQLのトランザクション処理性能は取得するタイムスタンプの精度に依存する．Google Spanner のクローンであるYugabyteDB はタイムスタンプの取得にNTPを用いるが，NTPによって得られるタイムスタンプの精度はSpannerが用いる原子時計・GPSと比較して低いため，トランザクション処理性能は劣る．そこでNewSQLノードに対し，集中型のプロキシを用いてクライアントに対し透過的なトランザクション処理を行うことで，NewSQLにおけるトランザクション処理性能の高速化を実現する手法について提案した．提案手法とYugabyteDBとのsysbenchを用いたトランザクション処理性能の比較において，YuagbyteDBノードを10台用いた場合，読み込み処理のみのワークロードでは1.28 倍，書き込み処理のみのワークロードでは4.46倍，書き込み処理と読み込み処理を含むワークロードでは最大で8.25倍の性能向上を確認した
|
| Strategy for Future Research Activity |
今年度は、分散メモリ環境下におけるプロキシを用いたキャッシュシステムについて検討を行う。これは昨年度の研究成果の拡張であり、分散トランザクショナルメモリにおけるキャッシュをプロキシ上に実装することを検討する。そのプロキシとサーバーとの通信はL2/UDPを用いることにより、TCP実装に比べて高速な実装を行う。
|
