【Tips】劔"Tsurugi"の性能比較検証：WSL vs Linux、ホスト vs Dockerの比較

概要

劔"Tsurugi"（以下、Tsurugi）を推奨環境以外で実行して、どの程度性能が変化するか検証しました。

背景

Tsurugiは、NEDOとNEC、ノーチラス・テクノロジーズが開発した次世代RDBです。2024年9月にGA版がリリースされ、2025年4月現在1.3.0までバージョンアップを重ねています。

Tsurugiの実行環境としてはUbuntu 22.04が推奨されていますが、開発用途などでWindowsのWSL環境やDockerにおける実行ニーズは少なくないと思われます。そこで今回は、Tsurugiを異なる実行環境（WSLとLinux）および異なるデプロイ方法（ホスト直接実行とDockerコンテナ）、クライアントからTsurugiへの接続方法（IPCとTCP）による性能の違いに焦点を当てて分析しました。

検証には、Project-tsurugiで公開されているTPC-Cベンチマーク（https://github.com/project-tsurugi/tsubakuro-examples）を使用します。

検証環境

今回の検証は、AWSの高性能CPU搭載でベアメタルEC2インスタンス c7i.metal-24xl を使用して実施しました：

• vCPU: 96コア

• メモリ: 192 GiB

• プロセッサ: 第4世代インテル Xeon スケーラブルプロセッサ

• ネットワーク: 37.5 Gigabit

Windows ServerでWSL2を動かすために、仮想化されていないベアメタルのインスタンスを選択しています。

検証バージョン

• OS: Windows Server 2022 Base, Ubuntu 24.04

• Docker: Docker CE version 28.0.2

• Tsurugi: 1.3.0

比較対象の環境

以下の6つの環境、8通りの構成で性能を比較しました：

• P-1. WSL (IPC)
  Windows Server上のWSL内にTsurugiを配置し、TPC-C AppからIPCで接続する構成。

• P-2. WSL上のDockerコンテナ (IPC)
  Windows Server上のWSL内にdockerコンテナとしてTsurugiを配置し、TPC-C AppもコンテナとしてIPCで接続する構成。

• P-3a. WSL上のDockerコンテナ (TCP)
  Windows Server上のWSL内にdockerコンテナとしてTsurugiを配置し、TPC-C Appはdockerの外からTCPで接続する構成。

• P-3b. WSL上のDockerコンテナ (TCP/host)
  Windows Server上のWSL内にnet_mode: hostにしたdockerコンテナとしてTsurugiを配置し、TPC-C Appはdockerの外からTCPで接続する構成。

• P-3c. WSL上のDockerコンテナ (TCP/direct)
  Windows Server上のWSL内にdockerコンテナとしてTsurugiを配置し、TPC-C AppはWSLの外からTCPで接続する構成。

• P-4. Linux (IPC)
  LinuxにTsurugiを配置し、TPC-C AppからIPCで接続する構成。（推奨構成）

• P-5. Linux上のDockerコンテナ (IPC)
  LinuxにdockerコンテナとしてTsurugiを配置し、TPC-C AppもコンテナとしてIPCで接続する構成。

• P-6. Linux上のDockerコンテナ (TCP)
  LinuxにdockerコンテナとしてTsurugiを配置し、TPC-C Appはdockerの外からTCPで接続する構成。

検証結果の概要

TPC-C Appから各環境でのトランザクション処理性能（TPM）を測定しました。結果は以下の通りです：

主要な発見

1. Linux環境の優位性

   • Linuxホスト環境が最も高い性能を発揮

   • 最大TPMは71,903.27（96W/96T）

2. Dockerの影響

   • Linux環境ではDockerによる性能低下は最小限

   • WSL環境ではDockerによる性能低下が顕著

3. 接続方式の違い

   • IPC接続がTCP接続よりも高い性能を発揮

   • 特にWSL環境での差が顕著

詳細な分析

$$\begin{array}{|l|c|r|r|r|r|r|} \hline 比較対象の環境 & P−4比 & 16W/16T&32W/32T&48W/48T&64W/64T&80W/80T&96W/96T\\ \hline P−1.WSL(IPC)&93％&17,277&32,041&44,451&55,357&66,088&67,068\\ \hline P−2.WSL上のDockerコンテナ(IPC)&83％&17,394 &31,537&36,502&43,122&51,266&59,464\\ \hline P−3a.WSL上のDockerコンテナ(TCP)&29％&14,274&23,733&26,301&22,691&20,692&20,630\\ \hline P−3b.WSL上のDockerコンテナ(TCP/host)&78％&14,344&28,501&34,976&43,272&48,880&56,231\\ \hline P−3c.WSL上のDockerコンテナ(TCP/direct)&5％&608&1,220&1,770&2,338&2,966&3,550\\ \hline P−4.Linux(IPC)&100％&23,061&41,438&57,054&69,636&71,078&71,903\\ \hline P−5.Linux上のDockerコンテナ(IPC)&98％&29,273&41,956&58,534&69,550&69,812&70,592\\ \hline P−6.Linux上のDockerコンテナ(TCP)&55％&21,302&23,617&28,357&32,569&37,312&39,332\\ \hline \end{array}$$

W/T列の数値は、TPC-CのWarehouseパラメータ(W)とスレッド数(T)です。

P-4比列は、96W/96TにおけるP-4. Linux (IPC)環境のTPMに対する各環境の測定値の比率です。

TsurugiをWSL上のDockerコンテナ（TCP）にした場合は、docker-proxyの負荷が高くスレッド数を増やしても性能が上がらなくなります（P-3a）。コンテナに`net_mode: host`を指定してdocker-proxyを使わない設定に変更するとIPCに近い性能（P-3b）になりました。

WSL外にTPC-C Appを配置してTsurugiをWSL上のDockerコンテナ（TCP）にした場合（P-3c）は、大きな性能劣化が見られました。

Linux環境が70,000程度で頭打ちになっているのは、測定環境のDisk I/O性能が原因と考えられます。CPUには余裕があるため、I/O性能の高い環境にすることでさらなる性能向上が見込めます。

結論と推奨事項

1. 本番環境での推奨構成

   • Linuxホスト環境での直接実行が最適

   • Dockerを使用する場合はLinux環境を推奨

2. WSL環境の使用について

   • 開発環境としては適している

   • 本番環境での使用は性能面で注意が必要

3. 接続方式の選択

   • 可能な限りIPC接続を使用

   • TCP接続は必要な場合のみ使用を検討

   • DockerのTCP接続は要件が許せばhostネットワークを利用

今後の展望

今回の検証結果を踏まえ、以下のような点についてさらなる調査を検討します：

• 異なるハードウェア構成での性能比較

• より大規模なワークロードでの検証

• 他の仮想化技術との比較

• I/O性能の高い環境での検証