この記事は、AMD 社のウェブサイトで公開されている「Accelerating Applications with AOCL Cryptography」の日本語参考訳です。原文は更新される可能性があります。原文と翻訳文の内容が異なる場合は原文を優先してください。
2026 年 6 月 2 日
AOCL Cryptography チーム
Advanced Micro Devices, Inc.
暗号ライブラリ単体の性能向上と、実際のアプリケーションでの性能向上は必ずしも同じではありません。実運用環境では、クエリ エンジンやプロトコル処理、ストレージ I/O など、さまざまな要素が性能に影響します。そのため、暗号ライブラリの本当の価値は、ユーザーが日常的に利用するワークロード全体をどれだけ高速化できるかにあります。
AMD Zen™ に最適化された暗号ライブラリである AOCL-Cryptography を、広く利用されている ClickHouse、strongSwan、RocksDB に組み込み、その効果を検証しました。これらのアプリケーションでは、暗号処理が使われる場面が大きく異なります。ClickHouse では SQL クエリの処理中に数百万回もの AES 暗号化・復号処理が実行されます。strongSwan では、IKE セッションのネゴシエーションや IPsec ESP パケットの暗号化をライン レートで処理します。RocksDB では、永続ストレージに書き込まれるすべての SST ブロックが暗号化されます。
本ブログでは、これらのアプリケーションへの統合方法や性能評価の結果に加え、検証を進める中で得られた興味深い知見について紹介します。
ClickHouse: 大規模な分析ワークロードにおけるカラム単位の暗号化
ClickHouse は、カラム指向の OLAP データベースとして広く利用されており、OpenSSL をバックエンドとする encrypt() と decrypt() を組み込み SQL 関数として提供しています。例えば以下のようなクエリでは、クエリ処理の中で 100 万回の AES キー スケジュールと暗号化処理が実行されます。
SELECT encrypt(‘aes-256-ctr’, payload, key, iv) FROM events LIMIT 1000000
この規模になると、暗号処理がクエリ全体の実行時間を左右する主要な要因になります。
AOCL-Cryptography は、内部インターフェイスを実装した ClickHouse の contrib ライブラリとして統合しました。ビルド時に 1 つのフラグを有効にするだけで、この統合機能を利用できます。有効化すると、ClickHouse はサポート対象の AES モード (GCM、CBC、CTR、CFB、OFB) を AOCL で最適化されたコード パスへ自動的に振り分けます。一方、サポート対象外のモードについては、自動的に OpenSSL にフォール バックします。そのため、SQL 構文や動作を変更する必要はありません。また、この統合により、ハードウェアによる高速化に対応したハッシュ関数として、AOCL_SHA256()、AOCL_SHA512()、AOCL_SHA3_256() の 3 つの SQL 関数が新たに利用できるようになります。
ベンチマークでは、clickhouse local –time を使用し、100 万行のデータを対象に性能を測定しました。各行では、SHA256 から生成したキーと初期化ベクトル (IV) を使用し、実際の利用環境に近い暗号ワークロードとなるようにしました。ベンチマークでは、暗号化から復号までの一連の処理を実行しました。また、結果のばらつきを抑えるため、各構成を 3 回実行し、その中央値を採用しました。比較対象には OpenSSL 3.5.0 を使用し、AOCL-Cryptography を無効化した同一の ClickHouse ビルドで評価を行いました。
AOCL-Crypto の OpenSSL 比性能向上i
評価環境
- AMD: EPYC™ 9755、128 コア (Zen 5、Turin)、Ubuntu 24.04.1、Linux 6.8.0-94-generic、Clang 19
- インテル: Xeon® 6980P、128 コア/ソケット × 2、3.9 GHz、RHEL 9、Clang 19
- ClickHouse バージョン: v25.11.8.25
| モード | データ サイズ | AMD EPYC™ Turin | インテル® Xeon® 6980P |
| AES-256-CTR | 小容量 (64 B ～ 2 KB) | 2.77 倍 | 1.78 倍 |
| AES-256-CTR | 16 KB | 1.57 倍 | 1.40 倍 |
| AES-256-CFB | 小容量 (64 B ～ 2 KB) | 1.84 倍 | 2.25 倍 |
| AES-256-CFB | 16 KB | 2.47 倍 | 2.15 倍 |
| AES-256-GCM | 小容量 (64 B ～ 2 KB) | 1.83 倍 | 1.54 倍 |
| AES-256-GCM | 16 KB | 1.26 倍 | 1.00 倍 |
| AES-256-CBC | 小容量 (64 B ～ 2 KB) | 1.33 倍 | 1.25 倍 |
| AES-256-CBC | 16 KB | 0.96 倍 | 0.92 倍 |
| AES-256-OFB | 小容量 (64 B ～ 2 KB) | 1.37 倍 | 1.29 倍 |
| AES-256-OFB | 16 KB | 1.12 倍 | 1.12 倍 |
図 1: AOCL 使用時の ClickHouse の性能向上
AOCL-Crypto は、並列化可能なすべての AES モードにおいて、AMD と インテルの両プラットフォームで性能向上を実現しました。特に AMD EPYC Turin では、Zen 5 の強化された VAES パイプラインにより、その効果がさらに高まっています。CTR モードでは、小容量のデータで AMD EPYC Turin が 2.77 倍、インテルが 1.78 倍の性能向上を示しました。CFB モードでは、データ サイズが大きくなるほど性能向上が大きくなり、16 KB のデータでは AMD EPYC Turin で 2.47 倍に達しました。これは、OpenSSL の EVP オーバーヘッドが目立つ条件ほど、AOCL のパイプライン処理による効果が発揮されるためです。GCM モードでは、小容量のデータで AMD EPYC Turin が 1.83 倍、インテルが 1.54 倍の性能向上を示しました。一方、16 KB では両プラットフォームとも AES-NI の処理能力がほぼ上限に達するため、両者の差は小さくなります。CBC モードでは、16 KB のデータにおいて AMD EPYC Turin が 0.96 倍、インテルが 0.92 倍と、両プラットフォームともほぼ性能向上は見られませんでした。これは、ブロックごとの処理が前のブロックに依存する CBC 固有の性質により、並列化による性能向上が難しいためです。
strongSwan: AMD およびインテル環境における IPsec の高速化
strongSwan は、VPN 接続やサイト間接続、企業ネットワークにおけるポリシー制御などで広く利用されているオープンソースの IPsec ソフトウェアです。IKE セッションのネゴシエーションや ESP パケットの暗号化処理はすべて暗号ライブラリに依存しているため、最適化による効果が得られやすい領域です。
strongSwan 向けに AOCL-Crypto プラグインを開発し、AES-GCM、AES-CBC、SHA-2、SHA-3、HMAC、SHAKE (XOF)、および X25519 キー交換のハードウェア高速化を実現しました。このプラグインは、strongSwan の標準 OpenSSL プラグインと並行して利用されます。strongSwan は起動時に、登録されているすべてのプラグインを内部テスト ベクトルを用いて評価し、アルゴリズムごとに最も高速な実装を自動的に選択します。以下に示すスループット性能は、この組み込みベンチマークの結果です (値が大きいほど性能が高く、固定データに対する 1 秒あたりの処理回数で測定しています)。
AOCL-Crypto の効果が異なるプラットフォームでも得られることを確認するため、AOCL を有効化した同一の strongSwan 6.0.2 を、特性の異なる 2 つのサーバー プラットフォームで評価しました。
AOCL-Crypto の OpenSSL 比性能向上ii
評価環境
- AMD EPYC (Turin): EPYC 9755、128 コア、4.06 GHz (Zen 5)、Ubuntu 6.8.0-94-generic
- インテル: Xeon 6980P、128 コア/ソケット × 2、3.9 GHz、RHEL 9
- strongSwan バージョン: 6.0.2
- コンパイラ: GCC 14.2
| アルゴリズム | AMD EPYC Turin | インテル Xeon 6980P |
| AES-GCM-16 (128-bit) | 1.89 倍 | 1.48 倍 |
| AES-GCM-16 (256-bit) | 1.72 倍 | 1.43 倍 |
| AES-CBC (128-bit) | 1.24 倍 | 1.19 倍 |
| AES-CBC (256-bit) | 1.23 倍 | 1.16 倍 |
| SHA2-256 | 1.23 倍 | 1.22 倍 |
| SHA2-512 | 0.96 倍 | 1.07 倍 |
| SHA3-256 | 1.14 倍 | 1.22 倍 |
| Curve25519 | 1.33 倍 | 1.73 倍 |
図 2: AOCL 使用時の strongSwan の性能向上
最も高い性能向上を示したのは AES-GCM の 1.89 倍で、これは Zen 5 の広い VAES パイプラインと、VPCLMULQDQ 命令による高い処理性能を直接反映した結果です。HMAC-SHA2-256 は 1.34 倍の性能向上を示しました。HMAC は IKE 認証時のすべてのメッセージ交換で計算されるため、この性能向上は実運用においても重要な意味を持ちます。一方、このプラットフォームでは AOCL を使用した SHA2-512 の性能はわずかに低く (0.96 倍)、プラットフォームごとに、さらなる最適化の余地があることを示しています。
AOCL-Cryptography は AMD ハードウェア専用ではありません。インテル環境でも、AES-GCM は 128-bit キーで 1.43 倍、256-bit キーで 1.48 倍の性能向上を示しました。また、SHA-2 と SHA-3 はいずれも約 1.22 倍、Curve25519 は 1.73 倍の性能向上を示しています。GCM の性能向上は Turin と比べるとやや小さくなっています (インテルの 1.48 倍に対し、Turin は 1.89 倍)。これは、AOCL の GCM 実装が Zen アーキテクチャ向けの命令スケジューリング最適化の恩恵を受けるためです。一方で、AES-NI および AVX を活用した最適化により、AMD とインテルの両プラットフォームで OpenSSL の標準実装を上回る性能を実現しています。
注記: ここで示している結果は暗号処理そのもののスループットであり、 IPsec トンネルのエンド ツー エンド性能を評価したものではありません。実際の IPsec のパケット処理性能は、パケット サイズや有効なセキュリティ アソシエーションの数、カーネル ネットワーク スタックのオーバーヘッドなど、さまざまな要因の影響を受けます。
RocksDB: 性能への影響を抑えた保存データの暗号化
RocksDB は、Meta や CockroachDB、TiKV をはじめとする多くのシステムで利用されている組み込み型のキー バリュー データベース エンジンで、プラグイン方式の保存データ暗号化機能をサポートしています。私たちは RocksDB 向けに AOCL-Crypto 暗号化プラグインを開発し、RocksDB の標準暗号化インターフェイスを通じて、AES-CTR と AES-XTS の両モードを利用できるようにしました。
AES-CTR は、RocksDB 本体に変更を加えることなく、RocksDB の標準暗号化フレームワーク上で利用できます。一方、AES-XTS では、ブロック境界に合わせた I/O 読み取りが必要になりますが、RocksDB はこの機能を標準ではサポートしていません。そのため、必要なブロック境界読み取り機能を追加するパッチを RocksDB 向けに作成しました。
暗号化実装を公平な条件で比較するため、RocksDB の db_bench をベースにしたベンチマーク ツール bench-rocksdb を作成しました。このツールでは、AOCL-Crypto、インテル IPP-Crypto (ippcp)、OpenSSL をバックエンドとする EncFS AES-256-CTR 構成、および暗号化を使用しない構成に対して、同じワークロードを実行します (fillrandom、fillseq、readrandom、readseq をそれぞれ 100 万回実行)。すべての構成が同じ RocksDB の暗号化インターフェイスを経由するため、暗号化ライブラリ自体の性能差を比較できます。
AOCL AES-CTR の他実装との性能比較iii
評価環境
- AMD: EPYC Turin 9755、128 コア、4.06 GHz (Zen 5)、Ubuntu 6.8.0-94-generic
- インテル: Xeon 6980P、128 コア/ソケット × 2、3.9 GHz、RHEL 9
| 比較内容 | AMD EPYC Turin | インテル Xeon 6980P |
| AOCL vs 非暗号化 (fillseq) | 1.02 倍 | 1.00 倍 |
| AOCL vs EncFS/OpenSSL (fillseq) | 1.68 倍 | 1.63 倍 |
| AOCL vs IPP-Crypto (fillseq) | 1.19 倍 | 1.21 倍 |
| AOCL vs EncFS/OpenSSL (fillrandom) | 1.41 倍 | 1.31 倍 |
| AOCL vs IPP-Crypto (fillrandom) | 1.12 倍 | 1.09 倍 |
| AOCL vs EncFS/OpenSSL (readseq) | 1.10 倍 | 1.25 倍 |
| AOCL vs IPP-Crypto (readseq) | 0.97 倍 | 1.29 倍 |
図 3: AOCL 使用時の RocksDB の性能向上
AOCL AES-CTR による暗号化は、書き込み性能への影響がほとんどありません。順次書き込みのスループットは、両プラットフォームとも非暗号化構成と比べて 2% 以内の差に収まっています。OpenSSL をバックエンドとする EncFS と比較すると、AOCL-CTR は AMD EPYC Turin で 1.68 倍、インテルで 1.63 倍の順次書き込み性能を実現しました。また、インテル IPP-Crypto と比較した場合、順次書き込みでは AMD EPYC Turin で 1.19 倍、インテルで 1.21 倍の性能向上を示しました。インテル環境では、読み取り性能における AOCL の性能差はさらに大きくなり、順次読み取りでは 1.29 倍、ランダム読み取りでは 1.36 倍の性能向上を示しました。
注記: インテル環境における AOCL の readseq の値は、非暗号化構成を上回っています。これは db_bench に起因する測定上の特性によるものです。暗号化レイヤーが RocksDB の I/O パスに組み込まれることで、先読みの動作が変化するためであり、「暗号化によって読み取り性能が向上した」ことを意味するものではありません。
まとめ
AOCL-Cryptography は、性質の異なる 3 つのアプリケーション分野において、一貫して測定可能な性能向上を実現しました。
- AMD EPYC Turin 上の ClickHouse
– AES-256-CTR: 最大 2.77 倍
– AES-256-CFB: 最大 2.47 倍
– AES-256-GCM: 最大 1.83 倍 - インテル Xeon 6980P 上の ClickHouse
– AES-256-CFB: 最大 2.25 倍
– AES-256-CTR: 最大 1.78 倍
– AES-256-GCM: 最大 1.54 倍 - AMD EPYC Turin 上の strongSwan
– AES-GCM: 最大 1.89 倍
– Curve25519: 最大 1.33 倍 - インテル Xeon 6980P 上の strongSwan
– AES-GCM: 最大 1.48 倍
– Curve25519: 最大 1.73 倍 - AMD EPYC Turin 上の RocksDB
AOCL AES-CTR の書き込み性能は非暗号化構成と比べて 1% 以内の差に収まりました。順次書き込みでは、IPP-Crypto と比べて 19% 高い性能を示しました。 - インテル Xeon 6980P 上の RocksDB
AOCL AES-CTR はインテル IPP-Crypto と比べて最大 36% 高い性能を示しました。書き込み性能は非暗号化構成と同等でした。
これらの性能向上は、VAES、VPCLMULQDQ、SHA 拡張命令といったハードウェアによる暗号化支援機能に加え、アーキテクチャに応じた命令スケジューリング最適化によって実現されています。
注記: 本ブログで紹介した ClickHouse、strongSwan、RocksDB 向けの統合機能は、AMD が独自に開発したパッチによるものであり、現時点では各プロジェクト本体には取り込まれていません。今後は、長期的な保守性の向上とコミュニティでの利用拡大に向けて、これらの変更を各プロジェクトへ取り込んでもらう予定です。AOCL-Cryptography を利用するには、アプリケーションの暗号化フックから AOCL API を直接利用する方法のほか、OpenSSL プロバイダーを利用して、EVP インターフェイス経由で利用する方法があります。
今後の展開
ClickHouse では、対応するハッシュ関数や暗号アルゴリズムの拡充を進めています。strongSwan 向けには、IPsec トンネルのベンチマークも準備中です。また、アプリケーション向けに開発した統合パッチやインターフェイスについても、各プロジェクト本体への取り込みを目指しています。これらの改善を各プロジェクトへ提供することで、より多くのユーザーが利用しやすくなるとともに、長期的な保守性の向上にもつながると考えています。
AOCL-Cryptography や AOCL スイートの詳細については、AMD AOCL Developer Portal を参照してください。AOCL-Cryptography のソース コードは GitHub で公開されており、コミュニティからのフィードバックを歓迎しています。
AOCL-Cryptography の導入によって得られた性能向上についても、ぜひ GitHub の Issue や Discussion で共有してください。
脚注
巻末注
i. ClickHouse ベンチマーク
AMD 社内評価 (2026 年 4 月 15 日)
- システム構成
– 2 ソケット AMD EPYC™ 9755 (Zen 5 “Turin”、128 コア/ソケット)、1536 GB DDR5-6400、Ubuntu 24.04.1 LTS、カーネル 6.8.0-94-generic、SMT 有効、Mitigations 無効、Power Determinism、AMI BIOS
– 2 ソケット インテル® Xeon® 6980P (128 コア/ソケット、3.9 GHz)、RHEL 9 - ソフトウェア
– ClickHouse v25.11.8.25-stable
– OpenSSL 3.5.0 (比較対象)
– AOCL-Cryptography 5.x (ENABLE_AOCL_CRYPTO=ON でビルド)
– Clang 19 - ワークロード
– clickhouse local –time
– クエリあたり 100 万行
– 各行で SHA-256 から生成したキーおよび IV を使用
– 暗号化から復号までの一連の処理を実行、AES-256 CTR/CFB/GCM/CBC/OFB、データ サイズ: 64 B ～ 2 KB・4 KB・16 KB、各構成を 3 回実行し中央値を採用
ii. strongSwan ベンチマーク
AMD 社内評価 (2026 年 4 月 18 日)
- システム構成
– 2 ソケット AMD EPYC™ 9755 (Zen 5 “Turin”、4.06 GHz)、1536 GB DDR5-6400、Ubuntu 24.04.1 LTS、カーネル 6.8.0-94-generic、SMT 有効、Mitigations 無効、Power Determinism
– 2 ソケット インテル® Xeon® 6980P (128 コア/ソケット、3.9 GHz)、RHEL 9、カーネル 5.14.0 - ソフトウェア
– strongSwan 6.0.2 (6.0.4 でも検証)
– OpenSSL 3.5.0 プラグイン (比較対象)
– AOCL-Cryptography 5.2、OpenSSL プラグインと併用する AMD 独自プラグインとして組み込み
– GCC 14.2 - ワークロード
– strongSwan 組み込み暗号ベンチマーク、内部テスト ベクトルを使用
– スループット値で (“points”) で評価
– 対象アルゴリズム: AES-GCM-16/12/8 (128/192/256-bit)、AES-CBC (128/192/256-bit)、SHA2-224/256/384/512、SHA3-224/256/384/512、HMAC-SHA2、PRF_HMAC_SHA2、SHAKE128/256、Curve25519 (X25519)
※ 測定対象は暗号処理そのもののスループットであり、IPsec トンネル全体の性能ではありません。
iii. RocksDB ベンチマーク
AMD 社内評価 (2026 年 4 月 20 日)
- システム構成
– 2 ソケット AMD EPYC™ 9755 (Zen 5 “Turin”、4.06 GHz)、1536 GB DDR5-6400、Ubuntu 24.04.1 LTS、カーネル 6.8.0-94-generic、SMT 有効、Mitigations 無効、Power Determinism
– 2 ソケット インテル® Xeon® 6980P (128 コア/ソケット、3.9 GHz)、RHEL 9 - ソフトウェア
– AMD 独自の AOCL-Cryptography 暗号化プロバイダーを組み込んだ RocksDB (AES-XTS にはブロック境界読み取りに対応する独自パッチが必要)
– AOCL-Cryptography 5.2
– インテル IPP-Crypto (評価時点での最新版)
– OpenSSL 3.5.0 を利用した EncFS
– db_bench ベースのベンチマーク ツール bench-rocksdb - ワークロード
– fillseq、fillrandom、readseq、readrandom をそれぞれ 100 万回実行
– RocksDB のプラグイン方式の暗号化インターフェイスを利用した 5 つの構成で評価: base (非暗号化)、alcp-ctr (AOCL AES-256-CTR)、alcp-xts (AOCL AES-256-XTS)、ippcp (Intel IPP AES-256-CTR)、encfs-aes256ctr (EncFS/OpenSSL AES-256-CTR)
結果は、システム構成、ワークロードの特性、データセットのサイズ、ソフトウェア バージョンによって異なる場合があります。
著作権および商標について
©2026 Advanced Micro Devices, Inc. All Rights Reserved.
AMD、AMD Arrow ロゴ、EPYC、AOCL、およびこれらの組み合わせは、Advanced Micro Devices, Inc. の商標です。
Picard および GATK は Broad Institute によって開発されており、それぞれのライセンスが適用されます。
OpenJDK および Java は、Oracle Corporation およびその関連会社の商標または登録商標です。
Ubuntu は Canonical Ltd. の登録商標です。
本記事に記載されているその他の製品名は識別のみを目的としており、それぞれの企業の商標である場合があります。
一部の AMD テクノロジーでは、第三者による有効が必要になる場合があります。サポートされる機能はオペレーティング システムによって異なる場合があります。具体的な機能については、ご利用のシステムの製造元にご確認ください。
免責事項
本ブログに掲載されている性能評価は AMD Performance Labs による検証結果です。性能データは、上記の構成を使用した AMD 社内評価に基づくものであり、参考情報として提供されています。本ブログで紹介した ClickHouse、strongSwan、RocksDB 向けの統合機能は、各プロジェクトのアップストリーム リポジトリをベースに AMD が独自に開発したインターフェイスであり、現時点では各プロジェクト本体には取り込まれていません。同等の効果は、AOCL-Cryptography API への軽量なインターフェイスを独自に実装する方法や、OpenSSL プロバイダー経由で利用する方法でも得られます。実際の性能は、システム構成、ソフトウェア バージョン、ワークロード、BIOS 設定、カーネル バージョン、コンパイラ バージョン、その他の要因によって異なる場合があります。AMD、AMD Arrow ロゴ、EPYC、およびこれらの組み合わせは、Advanced Micro Devices, Inc. の商標です。本ブログに記載されているその他の製品名は識別のみを目的としており、それぞれの企業の商標である場合があります。インテル および Xeon は、Intel Corporation またはその子会社の商標です。ClickHouse は ClickHouse, Inc. の商標です。RocksDB は Meta Platforms, Inc. の商標です。strongSwan は strongSwan Project の商標です。
© 2026 Advanced Micro Devices, Inc. All rights reserved.
AMD Zen Software Studio サポート サービス
エクセルソフトは AMD と提携し、HPC クラスター システムやデータ センター向けに AMD EPYC™ CPU ベースのサーバー上で動作するアプリケーションのパフォーマンスを最適化するためのソフトウェア開発ツール スイート 「AMD Zen Software Studio」 のサポート サービスを提供しています。サポート サービス導入前のご質問やご購入前の見積依頼などございましたら、エクセルソフトまでお気軽にお問合せください。
