Next Gen Db2 Warehouse on Cloud Beta(*)版を使ってみた(*：2023年7月7日に正式版リリース済)

概要

皆さん、こんにちは。
この度グローバルでも正式に発表されたばかりのNext generation Db2 Warehouse on Cloud(以後Db2WoCと記述)ですが、日本IBM様のご厚意により、こちらのBeta版を事前に検証する機会をいただきました。

Db2WoCでは様々な新機能が提供されますが、特に目を引くのが、今回の目玉機能として表明されているAmazon Web Services(AWS)のオブジェクトストレージ環境の標準サポートです。従来型ブロックストレージと比較して、パフォーマンスを維持しながらより安価に提供されるとのことです。やはりこちらのパフォーマンスが気になることから、本記事では新しいDb2WoC Beta版での検証結果報告を行っていきます。

なお、こちらはリリース前2023年5月時点のBeta(*)版での検証となりますので、リリース版とは画面や機能が異なる可能性があります。

*：2023年7月7日に正式版リリース済

主な新機能は以下です。

主な新機能	解説
Amazon S3標準サポート	パフォーマンスを犠牲にせず、かつ安価にGen2までのブロックストレージと同様の感覚でS3オブジェクトストレージをDb2用のストレージとして使用可能
オープンデータレイクフォーマットのサポート	Iceberg, Parquet, ORC, CSV他様々なオープンな標準フォーマットをサポート
watsonx.dataとの統合(*)	同じくグローバルで発表されたばかりのwatsonx.dataのデータカタログ、S3バケットの共有やDBエンジンの統合が可能。

*：watsonx.dataについては私どもも別途ブログを公開しております。こちらも併せてご参照ください。

Db2WoC は、現時点ではAWSにてご使用いただけます(数か月以内にIBM Cloudでも利用可能予定とのことです)。以下はAWSの場合のご契約プランとなります。

　

基本サービス(詳細はIBM Cloudカタログをご確認ください)

構成	コンピュート・リソース	ブロックストレージ	オブジェクトストレージ	バックアップ	月額(最小構成)
Small	最小32 vCPUでの構成で256 vCPUまで選択可能	40TBまで拡張可能 ($1.58/1TB/1時間)	・使用料に応じて課金 ($0.05/1TB/1時間)	・使用料に応じて課金 ($0.09/1TB/1時間)	$6,301.36
Medium	最小128　vCPUでの構成で1536 vCPUまで選択可能	120TBまで拡張可能 ($1.58/1TB/1時間)	同上	同上	$24,744.08
Large	最小576　vCPUでの構成で5760 vCPUまで選択可能	600TBまで拡張可能 ($1.58/1TB/1時間)	同上	同上	$112,040.40

追加サービス

名称	概要	月額
AWS Private Link	AWS PrivateLinkテクノロジーを使用して、Db2 Warehouseインスタンスへのプライベート接続を作成します。	$300
Dedicated Private Cloud(*)	IBMが管理する専用の仮想ネットワークにデータベース・インスタンスを作成します。	$3,000
Oracle Compatibility	Oracle 互換で構成することで、Oracle データベース用に記述されたアプリケーションを Db2 Warehouse上でシームレスに実行できます。	無料

*：2023年7月時点では選択不可

ぜひともお気軽にお問合せくださいませ。上記は2023年7月7日時点費用となります。最新の情報はIBM Cloudのカタログも併せてご参照ください。また、すでにDb2をお使いのお客様向けの価格オファリングも先日発表されたようですので遊休ライセンスの有効活用もできそうです。

使用環境のスペック

以下の環境を使用します。

1. Db2 Warehouse on Cloud
   • CPU：128vCPU
   • メモリー：864GB
   • ストレージ：内蔵ブロックストレージ(従来型)、Amazon S3オブジェクトストレージ(新規サポート)
   • 環境：Publicネットワーク(インターネット経由。米国東部リージョン)

検証環境の前提条件

ここまで記述したようにDb2WoC の環境を使用しますが、この中でさらにブロックストレージとオブジェクトストレージの計2環境を使用します。この2環境に対して、一般に公開されているテスト用サンプルデータを用いてそれをあらかじめ各環境にロードし、それぞれに同一のデータが含まれるようにします。

この2環境に対して以下のテストを実行し処理時間を測定するものとします。

まず、レコード数とそのサイズ(非圧縮)について記載いたします。

テーブル	レコード数	データサイズ(非圧縮)	使用する処理
テーブルA	209レコード	約15.6KB	大きなテーブルからのSQL結果抽出
テーブルB	10,287,841,280レコード	約1612.5GB	大きなテーブルからのSQL結果抽出
テーブルC	9レコード	約93Bytes	複数のテーブルを結合したSQL結果抽出
テーブルD	47レコード	約705Bytes	複数のテーブルを結合したSQL結果抽出
テーブルE	606,758,672レコード	約35.5GB	複数のテーブルを結合したSQL結果抽出
テーブルF	3,640,552,032レコード	約214GB	複数のテーブルを結合したSQL結果抽出
テーブルG	5,460,828,048レコード	約327.3GB	複数のテーブルを結合したSQL結果抽出
テーブルH	2,427,034,688レコード	約144.6GB	複数のテーブルを結合したSQL結果抽出
テーブルI	2,427,034,688レコード	約145.2GB	複数のテーブルを結合したSQL結果抽出
テーブルJ	3,640,552,032レコード	約218GB	複数のテーブルを結合したSQL結果抽出
テーブルK	3,033,793,360レコード	約180.9GB	複数のテーブルを結合したSQL結果抽出
テーブルL	2,427,034,688レコード	約144.4GB	複数のテーブルを結合したSQL結果抽出
テーブルM	4,854,069,376レコード	約290.5GB	複数のテーブルを結合したSQL結果抽出

　

まず、テーブルAおよびBを用いて、単純に大きなテーブルと簡単な結合を行う処理を確認し、続けてテーブルC～Lを用いた複数テーブルの結合についての動作確認を行います。

また、テストの実行方法について概要を記載いたします。

1. Cognosのレポートを実行
   DWHに溜め込んだテーブルデータを、Cognosレポートとして参照します。実運用に近い使用感を確認することが狙いとなります。参照先テーブルだけが異なる3種類のレポートを用意します。また、この時にレポートで使用するSQLを取得しておきます。
   
   両環境に接続するCognosサーバーのスペック情報についても以下に記載します。
   
   　CPU：3.59GHz 4コア
   　メモリー：10GB
   　OS：Windows Server 2016
   　Cognos：IBM Cognos Analytics 11.1.7
   　環境：NI+C社内ネットワーク
   
   社内検証用のため決して高スペックのものではありませんが、レポートを実行することは充分に可能です。Db2WoC に対しては、インターネット経由かつ米国東部リージョンへのアクセスということで、どうしてもオーバーヘッドが発生することになります。通信における不利を考慮に入れた確認を行います(なお、今回お借りした環境は上記の通り国外リージョンに存在するためこのようなオーバーヘッドを考慮する必要がありますが、GA版では東京AZでDb2WoCを利用可能です。そのため、日本の環境から東京AZにあるDb2WoCへのクエリ実行を考えた際にはあまり考慮しなくてもよいオーバーヘッドとも考えられるかと思います)。
   
2. Cognosのレポートで発行されたSQLをWebConsoleで実行
   1.で確認したSQLを単体で実行します。実行環境は、Db2WoC のWebConsoleです。データベースから近い環境からSQLを発行することで、Cognosのキャッシュやネットワーク差による影響を小さくすることが狙いとなります。
   
3. Cognosのレポートで発行されたSQLをdb2batchコマンドで実行
   同じく1.で確認したSQLをData Server Client経由で実行します。db2コマンドではなく db2batchコマンドを使用することによりネットワーク等の影響を排除し、Db2内での処理時間を把握することが狙いとなります。
   
4. データパターンを考慮
   レコード数のところでも記載しました通り、データの種類やSQLの処理パターンによる違いも確認できればと考え、SQLは2種類を用意しています。
   ・大きなテーブルからのSQL結果抽出
   ・複数のテーブルを結合したSQL結果抽出

2環境に対して3種類の方法で、2種類のSQLを実行することになりますので、2×3×2=12パターンの検証となります。これらを3回ずつ実行します。

なお、今回はBeta版ということで上記の通りSELECTのパフォーマンスを意識した検証となります。以下のような検証は行っておりません。

• Db2オブジェクト移行/データ移行
  社内のオンプレミス環境において、検証という観点ではなく手順確認まで行ったということになります。
• バックアップ・リストア
  こちらは今回のパフォーマンス検証とは意味合いが異なりますが、Db2WoC としてのバックアップリストア機能およびパフォーマンスの確認となります。Beta版でのみ機能提供が無く実施しておりません。スナップショットの開始時刻と保管世代数を指定します。

テスト項目

上記を踏まえ、テストケースは以下となります。

Db2WoCブロックストレージのテストケース

項番	テスト項目
1-1-1	Db2WoCブロックストレージに対して Cognos を用いて レポートパターン1を実行し結果を測定
1-1-2	Db2WoCブロックストレージに対して Cognos を用いて レポートパターン2を実行し結果を測定
1-2-1	Db2WoCブロックストレージに対して WebConsole を用いて SQLパターン2を実行し結果を測定
1-2-2	Db2WoCブロックストレージに対して WebConsole を用いて SQLパターン2を実行し結果を測定
1-3-1	Db2WoCブロックストレージに対して db2batch を用いて SQLパターン1を実行し結果を測定
1-3-2	Db2WoCブロックストレージに対して db2batch を用いて SQLパターン2を実行し結果を測定

Db2WoCオブジェクトストレージのテストケース

項番	テスト項目
2-1-1	Db2WoCオブジェクトストレージに対して Cognos を用いて レポートパターン1を実行し結果を測定
2-1-2	Db2WoCオブジェクトストレージに対して Cognos を用いて レポートパターン2を実行し結果を測定
2-2-1	Db2WoCオブジェクトストレージに対して WebConsole を用いて SQLパターン2を実行し結果を測定
2-2-2	Db2WoCオブジェクトストレージに対して WebConsole を用いて SQLパターン2を実行し結果を測定
2-3-1	Db2WoCオブジェクトストレージに対して db2batch を用いて SQLパターン1を実行し結果を測定
3-3-2	Db2WoCオブジェクトストレージに対して db2batch を用いて SQLパターン2を実行し結果を測定

確認方法

1. Cognosのレポートを実行

まず、Cognosからのレポート実行となります。
以下のように実行を行いました。

同一データがロード済みの2環境に対して、参照先テーブルのみを変更した3レポート×2を実行し、処理時間を取得しました。

GUI操作からの時間計測のため、SQLやデータベースにおける実行時間という厳密な意味での正確な時間が取れているわけではありませんが、レポートの実行から、レポートの結果が戻るまでの時間を確認しています。

2. Cognosのレポートで発行されたSQLをWebConsoleで実行

続けて、WebConsoleからのSQL実行となります。
以下のように実行を行いました。

同一データがロード済みの2環境に対して、参照先テーブルのみを変更した3レポート用SQL×2をDb2WoC のWebConsoleより実行し、処理時間を取得しました。

こちらもGUI操作からの時間計測のため、同様に厳密な意味でのSQLやデータベースでの実行時間という正確な値が取れているわけではありませんが、SQLの実行から、SQLの結果が戻るまでの時間を確認しています。

3. Cognosのレポートで発行されたSQLをdb2batchコマンドで実行

続けて、WebConsoleからのSQL実行となります。
以下のように実行を行いました。

同一データがロード済みの2環境に対して、参照先テーブルのみを変更した3レポート用SQL×2をdb2batchコマンドを用いて実行し、処理時間を取得しました。db2batchコマンドを用いてSQLを実行することで、合計処理時間だけでなくFetchの時間、Db2内の実際の処理時間なども個別に取得することができます。これにより、Db2内のみの処理時間の確認を行います。

db2batchコマンドについての詳細は以下となります。
https://www.ibm.com/docs/ja/db2/11.5?topic=commands-db2batch-benchmark-tool
今回の検証では、db2batch -i complete オプションを使用することで、各処理の実行時間内訳を取得しています。

(例) [db2inst1@test01 db2batch]$ date; LANG=C db2batch -d bludb -f woctest.sql -a bluadmin/ -o r 0 -i complete; date 2023年 6月 13日 火曜日 11:10:31 JST * Timestamp: Tue Jun 13 2023 11:10:32 JST SQL Statement Number 1: ： (略) ： 149460 row(s) fetched, 0 row(s) output. Prepare Time is: 0.010684 seconds Execute Time is: 59.690412 seconds Fetch Time is: 0.292703 seconds Elapsed Time is: 59.993799 seconds (complete) Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output Statement 1 1 59.993799 59.993799 59.993799 59.993799 59.993799 149460 0 Total Entries: 1 Total Time: 59.993799 seconds Minimum Time: 59.993799 seconds Maximum Time: 59.993799 seconds Arithmetic Mean Time: 59.993799 seconds * Geometric Mean Time: 59.993799 seconds Timestamp: Tue Jun 13 2023 11:11:32 JST 2023年 6月 13日 火曜日 11:11:32 JST [db2inst1@test01 db2batch]$

結果についての所感

今回のテストケースに関しまして、実行したレポート/SQLの環境ごとの結果についての所感を記載していきます。

[1. 大きなテーブルからのSQL結果抽出]では、Db2WoCにおいてブロックストレージを使用した場合でもオブジェクトストレージを使用した場合でも同等もしくはオブジェクトストレージ側のほうが高速であるという結果を得られました。この違いは、オブジェクトストレージ側にのみ搭載されている、NVMeキャッシュの存在が大きいものと考えられます。

NVMeキャッシュについては以下をご確認ください。ストレージへの書き込み前にキャッシュに溜め込まれ、一括でストレージに書き込むことで処理を高速化しています。

CPUやメモリーの制約を受けない極端に複雑な処理ではないような場合には、オブジェクトストレージを使用したDb2WoCのパフォーマンスは、ブロックストレージと同等かそれ以上であることがわかりました。オブジェクトストレージはブロックストレージよりも安価であり、Db2WoC の目玉のひとつであるAmazon S3オブジェクトストレージは非常によいソリューションになりますね。

ただし、今回の検証では充分な結果が得られなかったケースもありました。[2. 複数のテーブルを結合したSQL結果抽出]です。

[2. 複数のテーブルを結合したSQL結果抽出]のように、非常に複雑なSQLかつそれがCPUやメモリーの制約を受けるようなレベルである場合には、いかに最新のDb2WoC であってもパフォーマンス低下が発生しました。今回は検証ということでかなり意地悪なレポートおよびSQLの作りだったというのはあるとは思いますが、パフォーマンスへの影響が発生しました。

それでもブロックストレージと比較するとオブジェクトストレージ側のほうが劣化が少ないというのは、こちらもオブジェクトストレージソリューションにのみ存在するNVMeキャッシュが効果的に働いていると考えられます。

今回の処理を高速に動作させるには、検証で用いた環境はスペック的にやや不足していたということになりますが、Db2WoC ではオンデマンドでリソースを増やすことも可能です。例えば、このような重い処理のときは一時的にリソース増強することで解消できる可能性があります。オンデマンドのリソース追加はオンプレミスでのDWH構築やアプライアンス製品では行えない、クラウドならではの利点となります。

各テスト結果考察

各所感について、実際の結果サマリも交えて考察を行います。

　

1. 大きなテーブルからのSQL結果抽出 

( 1 ) Cognosからの実行

グラフの伸びが短いほど高速です。今回の結果を見ると、複数回実行することで処理が改善しています。これは、いずれもメモリーキャッシュを活用できているためと考えられます。ブロックストレージ側、オブジェクトストレージ側いずれもメモリー、キャッシュを効率的に使用し、大きな劣化無く結果を得られています。これにはCognosのキャッシュも大きく寄与している可能性が高いです。

　

( 2 ) WebConsole/db2batch からの実行

WebConsoleの実行が70秒前後で終了しているのに対して、db2batchの実行ではElapsed Time(合計の処理時間)が短くても120秒から240秒弱ほどと大きな開きが出ています。どちらも参照先テーブルがブロックストレージ側かオブジェクトストレージ側かというだけで、内容的には同じSQLを用いています。しかし、Db2WoC へのdb2batchでは社内のオンプレミス環境のサーバーからSQLを実行することになるため、ネットワーク的な条件は、例えばオンプレミス環境に存在するDBサーバーに対してのアクセスと比較すると圧倒的に不利になります。

一方で、WebConsoleからの実行ではSQLはウェブ・ブラウザ経由で実行され、データとクエリの通信距離が長くなることはありません。つまり、パフォーマンスの違いはネットワークの違いに起因することになります。

そのため、db2batchの結果の中でもElapsed Timeだけでの比較はフェアではありません。Elapsed TimeだけではなくExecute Timeを併せて確認、比較することでDb2内の処理についての時間を確認することができます。今回の検証ではブロックストレージ、オブジェクトストレージのいずれも、処理自体の合計時間Elapsed Timeに対して、実際の処理時間を表すExecute Timeは約半分の60秒から90秒ほどになっています。残り半分はほぼFetch Timeです。

単純にExecute Timeだけで比較しますと、Db2WoC オブジェクトストレージ、少し差が空いて同ブロックストレージと続きました。Db2WoC オブジェクトストレージには、先述の通り同ブロックストレージには存在しないNVMeキャッシュが別に存在します。db2batchにより純粋にDb2内処理を確認してみますと、こちらの存在が大いにパフォーマンスに寄与していると考えられます。

　

2. 複数のテーブルを結合したSQL結果抽出

( 1 ) Cognosからの実行

グラフの伸びが短いほど高速です。ブロックストレージの結果と比較すると、オブジェクトストレージがより速いという結果になりました。ただし、ブロックストレージ側で900秒程度、オブジェクトストレージ側でも300秒程度の時間を要しており、必ずしも高速な結果が得られたわけではありませんでした。ブロックストレージを使う場合でもオブジェクトストレージを使う場合でもDb2のエンジン自体は同一です。こちらは、単純にレポートのSQLを処理するためのメモリーが不足しており、Db2の一時表領域を使用してSQLが処理された可能性がありそうです。

ただし、オブジェクトストレージ側の場合にはNVMeキャッシュが使用されたため、パフォーマンス低下を最小限に抑えられたと考えられます。

　

( 2 ) WebConsole/db2batch からの実行

こちらも概ねCognosからの実行時と同傾向です。オブジェクトストレージがより速いという結果となりました。WebConsoleの実行と比べて、db2batchの実行ではElapsed TimeとExecute Timeが異なるのはこれまでと同様ですが、今回の場合その差は多くありません。Db2の処理自体により長い時間を要したことが見て取れます。

今回のテストで実行されたレポート/SQLは複数の結合を含む複雑なものであるため、最初のテストとは異なり、CPUないしメモリー、あるいはその両方で負荷が高まり、ボトルネックが発生した可能性があります。内部処理としては、SQLを処理するためのメモリーが不足したため、一時表領域を使用してSQLを処理していた可能性が考えられます。そして、Db2WoC側でもオブジェクトストレージの場合にはNVMeキャッシュが使用されたため、ブロックストレージよりもパフォーマンス低下を抑えられた可能性があります。

この辺りの厳密なところは、従来からのDb2と同じようにアクセスプランを確認するなどし詳細を比較し検討を行う必要がありますが、一般的にこのような場合には、CPUとメモリーがボトルネックになっていることが多いです。より潤沢なリソースを使用すれば解決する可能性が高いため、処理の特性によって一時的なリソース増強によりメモリーの量を増やすことが対策として考えられます。

ここまでのまとめ

• Db2WoC 内ブロックストレージとオブジェクトストレージの比較において、概してオブジェクトストレージ側のほうが良好な結果が得られています。Db2WoC においてオブジェクトストレージの使用料金は従来と比べて安価となります。IBM社より公開されているブログによると34倍の価格差だそうで、性能が同等以上で安価であるというのは、製品の競争力を高める理由の1つになるのではないでしょうか。
• 従来のブロックストレージと新しいオブジェクトストレージのどちらもユーザーが自由に使用を選択することができます(*)が、どのテーブル、テーブルスペースがどちらのストレージに存在するのか、何らかの手段により視覚的にわかりやすくなるとユーザーにはもっと使いやすいのではと考えます。今後のさらなる改善に期待します。
  *：オブジェクトストレージは列指向テーブルのデータの格納のみサポートされており、行指向テーブルのデータや索引は対象外となります。
  
• 今回貸与いただいた環境では、リソース割り当てを増やした環境でのテストを行うことはできませんでした。[2. 複数のテーブルを結合したSQL結果抽出]についても、リソース強化で対応できるかの検証もできればと考えています。

　　

　

しかし、ここまで検討を行い、あらためて考えてみました…

弊社には、もう1つのDb2 Warehouse環境が存在するのです。それはIIASです。このIIASを用いることで、リソース強化環境(仮)を想定した検証を行えるのではないでしょうか？

　

　

　　

IIASとは、IBM Integrated Analytics Systemの略称です。このIIASは、オンプレミス環境にて圧倒的なパフォーマンスを誇り、Db2WoC と共通のデータベースであるDb2 Warehouseを搭載したDWHアプライアンスとなります。共通のDBエンジンを使用しているIIASであれば、Db2WoCのリソース強化を想定した検証を行えるのではないでしょうか？

(参考)検証に用いるIIASのスペック

1. IBM Integrated Analytics System M4001-003
   • CPU：PowerPC 72cores
     (概ねDb2WoC の144vCPU相当。一般的に、Powerチップとx86ですと概ね2倍計算になります)
   • メモリー：1.5 TB
   • ストレージ：内蔵FlashStorage
   • 環境：NI+C社内ネットワーク
2. Db2 Warehouse on Cloud (再掲)
   • CPU：128vCPU
   • メモリー：864GB
   • ストレージ：内蔵ブロックストレージ(従来型)、Amazon S3オブジェクトストレージ(新規サポート)
   • 環境：Publicネットワーク(インターネット経由。米国東部リージョン)

vCPU換算ではIIASとDb2WoC は比較的近いもののIIASが勝り、物理メモリー搭載量においてはIIASが大きく勝っております。そのため、特にメモリー搭載量においては約1.7倍強の増強という観点で参考程度に比較を行うことができそうです。
そこで、IIASに対してもDb2WoC と同様のデータをロードし、テスト環境を整えました。Cognosからの接続設定も同様に行っております。WebConsoleはIIASにも存在しますのでそちらを用いました。db2batchの実行も同様に行いました。

(参考)IIASにおける検証

1. (参考)大きなテーブルからのSQL結果抽出 

2. (参考)複数のテーブルを結合したSQL結果抽出

いずれもグラフの伸びが短いほど高速です。[1. (参考)大きなテーブルからのSQL結果抽出]ではDb2WoC よりやや速くなり、[2. (参考)複数のテーブルを結合したSQL結果抽出]においては大きくパフォーマンスが改善しました。前者においてはもともとメモリーが足りていることもあり、vCPU換算でのスペック差通りの差が現れました。また、後者については、やはり搭載メモリーの差が大きく表れた結果と考えられます。また、db2batchを用いることで環境によりネットワークにおける不利が発生しないよう確認を行っておりますが、こちらの結果を見てもわかるように、処理そのものが改善しています。

仮にDb2WoC で実施した、[2. 複数のテーブルを結合したSQL結果抽出]におけるパフォーマンス劣化がもしIIASで発生していたとしたらどうなったでしょうか？今回はたまたまオンプレミス環境のIIASのほうが基本スペックにおいて上回っているため、こうした参考結果を得ることができましたが、IIASでリソース起因の問題が発生した場合、簡単には対処を行うことはできません。一方で、Db2WoC にて仮に同様の問題が発生してしまった場合においてのリソース増強の平易さは、クラウド環境であるDb2WoC の大きな強みとなります。

また、このような検証を踏まえまして、弊社には豊富な設計・構築ノウハウがございます。そもそもこういった問題が発生しないための事前の設計、サイジング、あるいは今回のように実際に動かしてみて、お客様にとって最適なリソースを把握するといったような、PoCによるご支援により最適なリソース活用のご提案を行うことも可能です。

記事のまとめ

• Db2WoC 導入にあたってどういったサイジングを行うか、NI+Cとしてご支援できますのでお気軽にご相談ください。
• PoCを行い、最適なリソース活用のご提案を行うことも可能です。
• 今回試せなかった機能についても、今後機会があればぜひ検証していければと思います。
• 今回の検証の機会をいただいた日本IBM様にはあらためて感謝を申し上げます。IBM社からも以下ブログにてDb2 WoCの新たなアーキテクチャや性能に関する情報が公開されておりますので合わせて御覧いただけますと幸いです。
  https://www.ibm.com/blog/db2-warehouse-delivers-4x-faster-query-performance-than-previously-while-cutting-storage-costs-by-34x/

以上、最後までお読みくださり、大変ありがとうございました。