データ量の増大と保管・復元の長時間化
数十年前に生成され、その後は実質的に参照されることのないデータやレコードであっても、それが企業の基幹業務に関わるのであれば、容易に削除できないものである。
誤解のないように付け加えておくと、システム部門の担当者にとってレコードを削除することは技術的に難しくはない。しかしユーザー部門・業務部門から削除許可を得られないため、削除できないのが実情である。
こうしてシステムが抱えるデータ量はリニア式に増える一方であり、それに準じて日次・週次・月次といった通常運用でのデータバックアップ処理、有事の際のリストア処理に時間を要することになる。
IBM i ユーザーのSAV/RSTの利用状況
HDDと比較して性能面で利点のあるSSDやフラッシュ・ストレージといったストレージ技術製品、および最新のLTO製品や仮想テープ技術製品を利用することで、保管・復元に要する時間の短縮化を試みるのはもちろん有効である。
ただし、IBM i ユーザーの定常的なバックアップ処理の実態としては、ディスク上にあるライブラリーやオブジェクトを、テープ装置を代表とする外部装置に直接保管するより、WindowsシステムのzipファイルやUNIXシステムのtarファイルに例えられるSAVF（保管ファイル）にいったん保管する運用が一般的ではないだろうか。
ディスク・プールをSSDやフラッシュ・ストレージで構成することで、そのディスク・プール上に配置するSAVFにオブジェクトを保管すれば、高速かつ効率的なバックアップ運用を実現できるからである。
SAVFを利用した保管では、ユーザー環境のディスク・プール資源容量とバックアップ・ウィンドウ双方での制約を鑑みた圧縮オプション（DTACPR＝Data Compression）が従来から実装されており、*NO、LOW（*YES）、*MEDIUM、*HIGHといったキーワードを指定することで、バックアップ完了時の保管ファイルのサイズを制御できる。もちろん圧縮率が高ければ高いほど、その処理に関する所要時間が伸長するのはご想像のとおりである。
ZLIB登場の背景とその特徴
こうしたビジネスやITを取り巻く状況を背景に、IBM i は多くの企業で使用されている重要システムである事実も加わり、ユーザーからはデータをより効率的にバックアップする圧縮アルゴリズムの実装が求められてきた。
その要求に応える形で、IBM i 7.5、IBM i 7.4 TR7で追加された保管・復元用の圧縮アルゴリズムがZLIBである。これは、ほかの多くのプログラムやシステムでサポートされている標準的な圧縮形式でもあり、昨今ユーザーが抱えてきた課題を解決に導く技術と言える。
ZLIBは、WindowsやUNIX環境でデータの圧縮・伸張を実行するzipやgzipをライブラリー化したものであり、可逆圧縮アルゴリズムのDeflate （RFC 1951） を実装している。
IBM iにとっては新しいこの圧縮アルゴリズムは、Power10プロセッサ上で、かつPower10互換モードで実行されることにより、オンチップのNest Accelerator（NX） GZIP を自動的に使用する。そのため、従来から利用可能だった圧縮オプションよりも高速で処理され、CPUへの負荷も低くなることが実証されている。
パラメータ*ZLIBは、圧縮オプションのキーワードとして新たに追加されている（図表1）。
これを指定できるシステム提供保管コマンドには、以下がある。
SAV、SAVCFG、SAVCHGOBJ、SAVDLO、SAVLIB、SAVLICPGM、SAVOBJ、SAVSECDTA、SAVSYS、SAVSYSINF
また、以下のシステム提供APIについても、*ZLIBパラメータの指定が可能である。
Save Object List （QSRSAVO）
Save Object （QsrSave）
Save to Application （QaneSava）
なおリストア処理に変更はなく、復元プロセスでは保管時に使用された圧縮アルゴリズムが自動的に決定される仕様となっている。
各種保管コマンドで圧縮アルゴリズム*ZLIBを使用するには、IBM i 7.5、7.4で、それぞれ以下のPTFを適用する必要がある。
◎IBM i 7.5：PTF MF70497、PTF SI81754、
◎IBM i 7.4：PTF MF70498、PTF SI81755、PTF SI81756
IBM i 7.4 の場合はTR7を適用せずとも、上記3つのPTFを適用することで利用可能になるので、TR更新をためらうユーザーは、個別PTFのみの適用を検討することも一案である。
ZLIBの検証・実装
以下に、Power10とIBM i 7.4の環境で、単一のライブラリーをSAVFに保管する際にデータ圧縮（DTACPR）キーワードに指定するパラメータごとの違いを検証した結果を記載する。
ライブラリー内の条件は、次のとおりである。
ライブラリー内の合計オブジェクト・サイズ：約90 GB
ライブラリー内のオブジェクト種別：物理ファイル、論理ファイル、ジャーナル、ジャーナル・レシーバー
図表2に示すとおり、*ZLIBを指定することで、既存の圧縮アルゴリズムの中で最も圧縮率の高い*HIGHよりも保管ファイルのサイズが小さくなり、最も高速な圧縮処理である*LOW（=*YES）よりも処理時間が短縮される（*NOは圧縮しない指定なので比較対象から除外してもよいのだが、参考値として掲載する）。
なお、*ZLIBを指定した保管処理を100回近く並列に実行した場合は、各ジョブでのI/O待ちが極端に少なくなるため、Power10互換モードのプロセッサであっても、CPUバウンダリーな処理に偏り過ぎる結果となった。
この理由により、*ZLIBを指定した多重保管処理の並列度合いについては、システムに搭載しているコア数や論理区画に割り振っているコア数を考慮しながら、ユーザー側で適度な調整が必要となることに注意したい。
次に、Power10とIBM i 7.4の環境は同一であるものの、プロセッサをPower9互換モードにして、同様の検証を実施した結果を記載する。
図表3が示すとおり、Power9モードの処理でも、保管ファイルのサイズは*ZLIBを指定した時が最小となることに変わりはないが、処理時間は*LOW（=*YES）が最も短い結果となった。これは、Power9モードではPower10アーキテクチャのハードウェア・アクセラレータを使用できないことに起因すると思われる。
ZLIBによる新しい運用方法と
アプリケーションへの期待
夜間処理や日次処理の前後でいくつかのライブラリーを保管ファイルに一次的にバックアップし、複数の保管ファイルが格納されたライブラリーを物理テープ媒体や仮想テープ・ソリューションを用いて2段階でバックアップする運用を実装しているIBM i ユーザーは多いだろう。
その場合、既存の運用アプリケーションを流用しながら、新しい圧縮アルゴリズムZLIBを指定することで、ストレージ使用量の削減を比較的容易に実現できると考えられる。
とくに機器の老朽化や定期更新等に伴って、これからPower10ベースの筐体に移るユーザーは、IBM i 7.4や7.5へのマイグレーションを行うと同時に、新しい圧縮アルゴリズムZLIBの効能をぜひ試してほしい。
最新のハードウェア自体の能力向上に加えて、ZLIB指定による夜間処理自体（一次バックアップ）の短縮化、および保管ファイルのサイズが縮小することによる二次バックアップの短縮化を実現し、その結果として、メンテナンス・ウィンドウ（もしくはサービス提供時間）の拡張が可能になるだろう。
なおZLIBについては、IBM i 7.5 とIBM i 7.4 TR 6から、二筐体間での地理的ミラーリングでも内部的に採用されており、ソースシステムからターゲットシステムに送信するデータ量を効率的に圧縮して減らすことで、これまでより高速な地理的ミラーリングの同期を実現している。
ZLIBは現在進行系で開発が進んでいる技術であるため、今後も新たな機能拡張やオプションの追加を期待できる。
IBM iの世界でも、各種ファイル転送やデータベースのエクスポート／インポートなど、OSの保有する機能に対するZLIBの内部的な実装や横展開に期待したい。
著者
小林 直樹 氏
キンドリル・ジャパン株式会社
西日本デリバリー・中部第一サービス
インフラストラクチャー・アーキテクト
IBM Power、IBM iを主要エリアとするシステムエンジニア。2001年、日本IBM入社。主に中部地区ユーザーの各種プロジェクトに従事。データベース基盤としてのIBM iの設計、構築、運用、インフラアーキテクチャの作成を担当。2021年、IBM社の分社化に伴いキンドリル・ジャパンに転籍、現在に至る。
［i Magazine 2023 Spring（2023年5月）掲載］
