TITLE

DuckDBの非同期I/OでS3分析が最大20倍速くなった理由 ― 見えていなかったボトルネックの正体

投稿日:2026.08.17

CATEGORY

  • Web開発
DuckDBの非同期I/OでS3分析が最大20倍速くなった理由 ― 見えていなかったボトルネックの正体

EC2インスタンスからS3上のファイルへクエリを投げると、体感で遅くなることがあります。原因をインスタンスの性能不足と見なせば、次の一手は多くの場合、より高性能な(そしてより高額な)インスタンスへの切り替えです。しかし分析データベースのDuckDBは2026年7月31日、公式ブログで「遅さ」の一因が計算資源の不足ではなく、ネットワークI/Oの使い方そのものにあったと明らかにしました。同期I/O(Synchronous I/O)から非同期I/O(Asynchronous I/O)へアーキテクチャを切り替えるだけで、S3上のクエリ実行時間が最大約20倍短縮しています。

同期I/Oが招く「1本の管」― ボトルネックの正体

DuckDBが問題視したのは、EC2インスタンスからS3のようなリモートストレージへクエリを投げる場面です。この構成で同期I/Oを使うと、ワーカースレッドはネットワークからの応答を待つ間、他の処理を進められずに止まります。たとえるなら、1本の水道管のようなものです。蛇口をいくつ増やしても、水を運ぶ管が1本しかなければ流量は増えません。CPUには余力があり、ネットワーク帯域にも余裕があるのに、両者をつなぐ経路がボトルネックになって性能が頭打ちになる構造です。

二層のワーカープールと先読みで帯域を使い切る

DuckDBが実装した非同期I/Oは、ワーカーを役割ごとに2種類のスレッドプールへ分けるアプローチです。1つは計算を担う「REGULARワーカー」で、数はCPUスレッド数と同数に抑えられています。もう1つはブロッキングI/Oを担う「ASYNCワーカー」で、システムスレッド数の4倍(上限256)まで確保されます。ASYNCワーカーは「read-ahead(先読み)」戦略でS3へのフェッチタスクを継続的に発行し続け、その間REGULARワーカーはネットワーク応答を待たずにデコード処理を進められます。フェッチを先取りしすぎるとメモリを圧迫するため、非同期のメモリガバナンス機構がOOM(メモリ不足によるクラッシュ)を防ぐ仕組みも組み込まれています。

同期I/Oと非同期I/Oの構造比較図。上段は1本の管を1ワーカーが独占して応答待ちで止まる同期I/O、下段はREGULARワーカーとASYNCワーカー(最大256)の二層プールがqueueを介して連携し、ASYNCが先読みで継続的にS3へフェッチを発行する非同期I/Oの構造を示す。

計算を担当する側と通信を担当する側を分離し、通信側の数を大きく増やしたことで、ネットワーク帯域を使い切れる構造に変わりました。非同期I/Oはプレビュービルドのv2.0.0-devで先行提供されており、正式版のDuckDB v2.0は2026年秋にリリース予定です(現行安定版はv1.5.5)。

実測で3倍から20倍 ― TPC-Hベンチマークの結果

DuckDBは公式ブログでTPC-H Query 6(スケールファクタ100)を使ったベンチマーク結果を公開しています。S3上のParquetファイル(22GB)へのクエリは平均実行時間が8.230秒から2.844秒へ、約3倍高速化しました。S3上のCSVファイル(80.89GB)では878秒から45秒へ、約20倍という差が出ています。同時に4つのクエリを実行した場合も、35.8秒から15.6秒へ短縮されました(デフォルトのメモリ設定時)。ネットワーク利用率の実測では、v1.5.5の約5Gbit/sからv2.0.0-devでは25Gbit/s近くまで帯域を使い切るようになっています。

コールドなローカルディスクからの読み込みでも1.321秒から0.883秒へと約1.5倍改善しており、今回のベンチマークでは、S3のようなリモートストレージに限らずローカルディスクの読み込みでも効果が確認されています。

クラウド費用を疑う前に、I/Oの実装を疑う

DuckDBの非同期I/O実装が示しているのは、性能改善が必ずしもハードウェアの増強を意味しないという点です。REGULARワーカーとASYNCワーカーを役割ごとに分離するという、インスタンスを増強しないソフトウェア側の設計変更だけで、実行時間が数倍から20倍変わっています。クラウドのデータ分析基盤のコストや性能に課題を感じている場合、まず疑う価値があるのは、使っているクエリエンジンがネットワークI/Oをどう扱っているかという実装の側面です。

まとめ

DuckDBを使っている場合、次の一歩は現行安定版のv1.5.5から、非同期I/Oを実装したプレビュービルドv2.0.0-dev(正式版のv2.0は2026年秋リリース予定)へ切り替え、自社のワークロードで実際の実行時間を計測してみることです。DuckDB以外のエンジンを使っている場合も、S3のようなリモートストレージへのアクセスで非同期I/Oに対応しているか、ネットワーク帯域を実際に使い切れているかを、ベンダーのドキュメントやサポート窓口に確認する余地があります。インスタンスを増強せず、ソフトウェアの実装だけで実行時間が数倍から20倍変わり得ることを、今回のDuckDBのベンチマーク(TPC-H Query 6、スケールファクタ100)は示しています。

出典:

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)

AI

AI導入やシステム開発の ご相談を承っています。

お気軽にお問い合わせください