HULFT10 新圧縮方式Zstandard は性能が良いのか、と考える（測定比較する）要素

こんにちは、こんばんは。
HULFT10 の開発プロジェクトを頑張っていた、、セゾンテクノロジーの加藤と申します。
数年ぶりのバージョンアップ開発ということで、
苦労がゼロとは言えない、なかなか大変な開発プロジェクトでありました。

しかししかし！ そんな苦労話はしかし！
1ミリも見せるつもりはございません！！
（いや数ミリ…いや数センチは見せるかもしれませんが…）

そんな苦労話はおいておいて、
HULFTご利用いただいている皆さまへは、
爽やかな顔してこの新バージョン、2024/12/10 リリースの新作、
HULFT10
を全力でオススメしたいと思います。
ぜひ。ご利用ください。ご利用中のありがたいお客様は、ぜひ、バージョンアップしてください。

何が「HULFT10 オススメ」なの？

それは、我々PJ メンバの血と汗と涙が製品を輝かせて…
などという感傷的な裏話はさておき、

HULFT10 は以下のテーマを打ち立てて開発を行っておりました。

• インターネット時代のHULFT
• プロフェッショナルな機能の強化
• Z世代への訴求

これらテーマをもって製品企画に取り組み、
機能的な回答として以下のように新たな製品価値を作り上げました。

• インターネット時代のHULFT
  HULFT 転送を中継し、WSS 技術にてインターネット内の安全転送を実現する「Smart Proxy（別製品）」

• Z世代への訴求
  「HULFT って、古い古い遺跡のようなアプリでしょ？」と言われたことがショックだった、といつ開発コンセプト（モチベーション？）のもと、
  HULFT 操作を可能とするAPI 展開を目的とした「API Gateway（別製品）」を作り上げ、モダンなUI を開発。今後はこれを拡張していけるように考えてます。

• プロフェッショナルな機能の強化

では「プロフェッショナルな機能の強化」とは何か、がこのブログのテーマと繋がるのですが、
「なんといってもファイル転送ツールなんだから、転送速度向上させることこそ、「プロ」だろう！」
というストレートな考え方のもと、

（もちろん他にも色々機能改修しているのですが）

HULFTとしてあらたな圧縮ライブラリである「Zstandard」を取り込んだことこそが、
「プロフェッショナル機能強化」であり、
オススメしたい機能であるのです。
やはり、ファイルを転送するので、圧縮率を強化は狙っていきたい要素でしたので！
しかしそこに注意を促したい要素もあります。

私は当初、プロジェクトの全体リーダを担当していたのですが、
プロジェクトが広がってく中で、テストチームを組織し、性能測定に集中していた時期がありました。
その際の思い出を語らせていただければと思います。

Zstandard、とはそもそも何か。

アルゴリズムです。ライブラリです。
詳しくはWiki を参照…なんて書くと、私のこのブログの価値がなくなりますので、
Wiki を案内しつつ（https://ja.wikipedia.org/wiki/Zstandard）
どのようにHULFT に取り込まれたのかに触れていきたいと思います。

まず、HULFT はHULFT8 にて「Deflate 圧縮」に対応しました。
いわゆるZIP 圧縮でして、インターネット上のサーバ上に配置したりやり取りするための圧縮方式として広く普及したアルゴリズムとなります。
Deflate は一般利用もされ、普及し、非常に有用な圧縮アルゴリズムでありました。

しかし技術は日進月歩。
世界の技術者はこだわり続け、
ある人が（Yann Collet氏）が新たなアルゴリズムとして2016年に発表したのが「Zstandard」です。
Deflate 方式の圧縮と比較した時に、圧縮率はほぼ同等であるものの、処理が高速、という特徴があると言えます。
Deflate アルゴリズムは、復元処理（伸長処理）は非常に高速であるものの、
圧縮処理は、そこそこの速度、
かつ、計算処理が多い、
といえる特徴を持ってました。

このDeflate 方式よりも「もっと凄いのが作れるぞ」とYann Collet 氏が作り上げたのがZstandard であり、
「メモリテーブルを大きめにすることで、CPU 処理負担を軽減しての高速化を狙った」、
という点がDeflate の特徴的な差異と言えるでしょう。

ですので、HULFT10 への取り込んだ特徴としては、
・CPU 使用時間よりもメモリ使用量が増える
・特に圧縮処理が高速化（復元＝伸長も、高速化）
が上げられるもの、となります。

さて、では転送速度は速くなるのか

当然ながら、「新しいアルゴリズム、ライブラリを取り込みました！」
だけでは
「だからなに？」
なわけで、
「何が良いの？」
という価値が大事なわけです。

「Zstandard 使えば、速くなるのね？」
と、そう聞きたくなりますよね？
…
…ケース・バイ・ケースです。

転送速度とは、つまり、何なのか（要素分解）

性能測定を行うにあたり、要素分解を行いました。
「ファイルを、2拠点間にて、圧縮、暗号、コード変換しつつ転送する」、
これがHULFT の機能概要です。
HULFT がファイルを転送開始し、転送を完了するまでの処理は以下のような流れとなります。

• 転送先との通信確立
• 配信元ファイルをOPENし、データをRead（集信側は集信ファイルをOPEN）
• HULFT電文のコード変換、圧縮、暗号化
• HULFT電文をTCPIPパケットとして配信側が送出
• 電文がネットワークを流れていく
• 集信側がパケットを受信
• HULFT電文を解析（暗号の複合、圧縮の伸長）
• 集信ファイルへデータをWrite
• （モードにより、集信ファイルへの電文内容のWirte 完了を待たずに配信側はRead して電文送出）
• （モードにより、集信ファイルへの電文内容のWrite が終わるまで待機し、配信側が続くデータ電文を生成して送出）

このように並べた時に、転送速度に影響する要素を詳述していくと以下のようになります。

• 転送先との通信確立
  配信側の環境（OS、と言って良いでしょう）から、相手を探す手間にかかる速度
• 配信元ファイルをOPENし、データをRead（集信側は集信ファイルをOPEN）
  配信元ファイルのディスクI/O 速度（OS の処理性能とHW のディスクアクセス速度）
• HULFT電文のコード変換、圧縮、暗号化
  コード変換アルゴリズムの速度
  圧縮アルゴリズムの速度
  暗号化アルゴリズムの速度
• HULFT電文をTCPIPパケットとして配信側が送出
  OS のTCPIP 処理速度
• 電文がネットワークを流れていく
  ネットワーク速度。中継点になるルータ、拠点などの全てが影響
• 集信側がパケットを受信
  OS のTCPIP 処理速度
• HULFT電文を解析（暗号の複合、圧縮の伸長）
  暗号を複合するアルゴリズムの速度
  圧縮データを伸長するアルゴリズムの速度
  コード変換アルゴリズムの速度（集信側変換の場合はこのタイミングで処理）
• 集信ファイルへデータをWrite
  集信ファイルのディスクI/O 速度（OS の処理性能とHW のディスクアクセス速度）
• （モードにより、集信ファイルへの電文内容のWirte 完了を待たずに配信側はRead して電文送出）
• （モードにより、集信ファイルへの電文内容のWrite が終わるまで待機し、配信側が続くデータ電文を生成して送出）

…こうして書き出してみると、「速度＝転送時間」に関わる要素の多さに、ちょっと戸惑います。
実のところ…Zstandard が影響するのは、上述の中にある、
配信側の「圧縮アルゴリズムの速度」
集信側の「圧縮データを伸長するアルゴリズムの速度」
この2点への影響（効果）であり、
…実際はなんとも、転送速度に関わる要素が「他に」多いのです。
…うーん、こう書き並べてみると「対して効果がない」という説明になってしまいそう…

どういうことかと言うと、いくつか例え話をしてみますと、
「配信側のHULFT 環境が、OS、HW を含めて高性能であっても、集信側のディスクI/O（Write 性能が悪い）場合、各要素が高速でも転送時間自体は長くなる」
「配信側、集信側に高速なOS、HW を配備していても、「ネットワーク速度」がボトルネックとなり転送時間自体は長くなる」

そうなのです。
今回、HULFT10 においては「Zstandard という非常に優秀はアルゴリズムを取り込み、選択できるようにしました！！」と、
声を大にしてお伝えしたいのですが、
どこかにボトルネックがあれば、Zstandard を選択しても「あれ？ HULFT8 と変わらない？」という測定結果がありうるのです。

圧縮アルゴリズムにはそれぞれの得意分野がある

圧縮処理そのものも、「必ずZstandard が有利、有効」ということとはなりません。
まず、Deflate もZstandard も、アルゴリズム的に、得意なデータ配列とそうでない配列があります。
アルゴリズムの詳しい説明は私にはできないですが、端的に言いますと、
「複雑度の高いデータの圧縮において有効」と言えます。
逆に「複雑度の低いデータ」については、実は単純圧縮の、弊社が開発して実装した、HULFT の圧縮方式である「横圧縮」「縦横圧縮」の方が有効である可能性が高いのです。

複雑度の高い、低いって、なに？
という疑問になるのは当然かと思います。
ファイル形式的には、
「テキストファイル、CSV ファイル、それに準ずる単純なデータの配列」が複雑度低、
「PDF、エクセル、画像データなどなと、アプリ独自圧縮」のようなデータが複雑度が高いと言えます。

入力データによって向き、不向きがある、と。
で、あるからこそ、HULFT は選択肢を増やす形で実装をし、
「このアルゴリズムがいつでも最適・最高！」
とは言い切れない点が、重要な点です。

どの圧縮形式を選択すればいいの？

そこです。
そこなのです。
…お試しください！

開発におけるテストチームでは、色々、いくつかのシーン、パターンを想定して性能測定を行いました。
配信元となるデータの内容（複雑度）によっても随分結果、効果が変わりますし、
転送の相手先、つまりOS によっても変わります。
印象としましては、Windows OS はディスクI/O、特に書き込みが「遅い」印象があり、
せっかく配信側がファイルのデータを読み込んで、高速に圧縮していても、
それを受け取った集信が（圧縮からの伸長は速いのに）、書き込みにもたついて、転送時間自体が、Deflate 圧縮とZstandard 圧縮で全然変わらない、ということもありました。

先の「単純データ」と呼ぶようなデータにおいては、HULFT が旧来から提供しているアルゴリズムの方が速い！ ということも確認できております（横圧縮、縦横圧縮）。

つまり…
「これを選択すれば完璧！ どんな場合でも一番最適！」
というものは無い、ということです。銀の弾丸は無い、と。

HULFT は、様々な業務、様々な利用シーンでご利用いただくことを想定しており、
設定値を非常に多く持つことで、その「様々な、多様さ」に対して最適となりうる設定を調査・検討可能としています。
それが、ミドルウェアとしての「ケース・バイ・ケースに対応できます」という矜持です。

テストチームとしましては、設定値が増えることでべき乗計算的にテスト項目が増えていくので、
設定値は少ないほうが断然！ 工数的には助かるのですが、
お客様が様々なHW、様々なOS、様々なネットワーク環境にて、多様なデータを送受信されている以上、
メーカーからの押しつけの「最適設定」を示すことは出来ませんので、
利用者様に是非、探し出していただきたいのです。

その際の選択肢に、新たに「Zstandard」が増えることになりますので、
ぜひ設定の検討をいただければと思います。

設定値が多いと検討が大変なんだけれど

おっしゃる通り！！
テストチームを大いに悩ませるのは、とにもかくにも設定値、パターンの多様さです。
しかし実際、お客様の環境・構成をお聞きする度に、「違う」と。
様々な利用シーンがあることを、つくづく、痛感しております。

であるので、HULFT10 をご利用いただくお客様におかれましては、
ぜひ、
・転送するデータパターン毎、
・転送の相手先OS、HW 毎、
・お取引される相手企業とのネットワーク速度毎、

設定値の検討と、お試し評価をしていただければと思います。
「これが最適設定です！」
とメーカである我社から、明確に示すことができないのは、
お客様にそれぞれにデータと環境が異なるためであり、
視点を変えますと、
「非常に様々な状況・シーンにおいても、多くのカスタマイズ要素、設定項目で、HULFT と環境の力を最大限引き出していただくことが可能なのです！」
ということが、
HULFT の基本コンセプトになります。
…ですので設定項目が多いのです。

おわりに

「HULFT10 の新機能が、全てのシーンに最適です！！」
と大きく大きく、わかりやすく言えなくて申し訳ありませんが、

HULFT の以前のバージョンでは解決できなかった課題、
諦めていた「転送時間の長さ」に、効果がある可能性があります。

ぜひ！
新たな選択肢を検証していただき、採用検討をお願いいたします！