Bristol Myers Squibb が AWS Storage Gateway を使用してパフォーマンスの向上とコスト削減を実現

AWS ストレージブログの以前の投稿で説明したように、Bristol Myers Squibb は、多くの AWS ストレージサービスを利用して、さまざまなライフサイエンスのワークフローでペタバイト規模のデータを管理しています。ゲノミクスと臨床データは指数関数的に増加しており、データの処理における信頼性が高く、スケーラブルで安全なサービスを利用することが重要となっています。そのため、当社の組織では、Amazon Simple Storage Service (Amazon S3)、Amazon Elastic Block Store (Amazon EBS)、AWS Storage Gateway などの AWS ストレージサービスが中心的な役割を果たします。

以前言及したように、Amazon S3 が非常に成功し、Bristol Myers Squibb で広く採用された主な理由の 1 つに、AWS がアクセス管理とセキュリティに注力していることが挙げられます。この結果、組織がアクセス許可のないユーザーから何百万ものファイルを保護することが可能となりましたが、それだけでなく、複数の適正なアプリケーションやチームとの共有も行うこともできます。途中で権限を与えられた関係者に対し、データ暗号化を透過的に維持できます。

このブログの目標は、AWS ストレージサービスのアーキテクチャと技術の側面を共有することです。これらのサービスに関する私たちの知識は、Amazon S3 と AWS Storage Gateway の多くの実装の使用、コスト削減の機会の調査、さまざまな機能とアーキテクチャの調査から得た学びに基づいています。当社は、オンプレミスアプリケーションのストレージへの低レイテンシーでのアクセスが必要となった際に、EC2 インスタンスとして、および環境内のハードウェアアプライアンスとして、Storage Gateway を導入しました。このブログ投稿では、さまざまな EC2 設定における Storage Gateway のパフォーマンスに焦点を当て、この素晴らしい AWS のサービスに適用できるいくつかの潜在的なコスト最適化を提案します。クラウド内アプリケーションを Storage Gateway とインタラクションさせる予定で、データへのアクセスに関するオンプレミスの要件がわかっている場合、当社は EC2 に Storage Gateway をデプロイします。

Storage Gateway のテスト環境

Bristol Myers Squibb の多くのユースケースでは、科学機器から S3 クラウドストレージへの生データ転送のためのメインエンジンとして、AWS Storage Gateway の File Gateway を使用しています。データは Amazon S3 に存在し、ここで処理されます。AWS の他のアプリケーションには、複数のリージョンからアクセスできます。テスト環境で AWS Storage Gateway をテストしたところ、コスト効率が高く、高いパフォーマンスを発揮する方法を見つけました。

特定のユースケースにおいて、AWS は、IOPS が高い、仮想の Storage Gateway のためのプロビジョニングされた Amazon EBS ボリューム (io1 タイプ) を推奨しますが、当社は、汎用 gp2 ベースのストレージを使用したところ、ファイルが小さいデータセットで大幅に節約できました。中規模および大規模ファイルのデータストリームの場合、io1 は優れた結果を示します。

これを説明する前に、テスト環境について簡単に説明します。これは、sgw-Alpha および sgw-Beta という 2 つの同一の Storage Gateway で構成されています。AWS のレコメンデーションで提案されるように、それぞれが c5.4xlarge Amazon EC2 インスタンス上で編成されています。ファイルゲートウェイをデプロイして、オンプレミスアプリケーションに、最近使用したデータについて、S3 ストレージへのファイルベースの低レイテンシーキャッシュアクセスを提供します。これら 2 つのゲートウェイの唯一の違いはストレージです。sgw-Alpha には、80 GB の EBS ルートディスク (io1、4,000 プロビジョンド IOPS) と 512 GiB の EBS キャッシュディスク (io1、1,500 IOPS) が装備されていますが、sgw-Beta は、それに代えて、同じサイズの汎用 SSD ディスク (gp2) を備えています。

両方の Storage Gateway が完全に設定されて起動したら、次のステップで、NFS ファイル共有を作成します。ゲートウェイ sgw-Alpha および sgw-Beta の 2 つの Amazon S3 バケットの名前を指定して、ファイルを保存し、ファイルを取得します。それぞれを s3-Alpha および s3-Beta と呼びます。組織の要件を反映する必要がある場合は、NFS ファイル共有の構成設定を変更できます。両方のファイル共有が同一であることを確認してください。

そして、テストの準備の最終ステップとして、これらのファイル共有をクライアントにマウントします。当社の場合、これは通常の (専用ではない) c5.large Amazon EC2 インスタンスであり、次のコマンド (Linux の場合) または AWS ドキュメントである NFS ファイル共有をクライアントにマウントするに記載されている他のコマンドのようなコマンドを使用しました。

sudo mount -t nfs -o nolock,hard [ゲートウェイ VM IP アドレス]:/[S3 バケット名] [ 
クライアントのマウントパス]

上記の命名ルールに従って、テスト用の c5.large EC2 インスタンスに sgw-alpha-io1 および sgw-beta-gp2 としてこれらのファイル共有をマウントします。これにより、それらの間の主な違いがすぐにわかります。これまでのところは次のとおりです。

これで、Storage Gateway の新しいプレイグラウンドのストレステストを行う準備ができました。いつもどおり、最初に重要な免責事項を述べなければなりません。すなわち、これは科学的なテストではないということです。これは主に、専用ではない共有のクラウドホスト環境とシミュレートされたデータセットを使用していることによります。さらに、当社が制御できない他のいくつかの要因がこれらの結果に寄与するかもしれません。

Storage Gateway を使用したコスト削減に関する仮説

当社は、主に小さなサイズのファイルで構成されるデータセットについて、通常の gp2 ベースの EBS ストレージで構築することにより、Storage Gateway の大幅な節約が達成できるという仮説を立てました。当社は、AWS 簡易見積りツールを使用して、Bristol Myers Squibb の環境に基づき、節約額を計算しました。他の組織では、特定の環境とデプロイするサービスによって、節約額が異なる場合があります。見積りツールに基づいて、約 40% のコスト削減があることがわかりました (S3 のコスト、Storage Gateway のコスト、データ転送速度が同じであると仮定した場合):

ご覧のとおり、c5.4xlarge io1-storage ベースの AWS Storage Gateway インスタンスのみ (EC2 インスタンスのみ) の月額費用は約 930 USD です。しかし、gp2 ベースのストレージを使用する同じ EC2 インスタンスのコストは、わずか 557 USD であり、これは 40% 近くの節約となります。

これらの節約は、特にこれらの節約を年間で考えると、大きなものです。しかし、Storage Gateway のパフォーマンスが低下しないということを同時に保証できるでしょうか? 当社の測定によれば、小さなファイルでパフォーマンスが大幅に低下することはなく、実際にはほとんど同じであることが示されています。

Storage Gateway のシーケンシャル I/O パフォーマンス

次のLinuxコマンドを使用して、Storage Gateway ファイル共有のシンプルなシーケンシャル I/O パフォーマンスを確認し、サーバーのレイテンシーを測定しました。

dd if=/dev/zero of=/sgw-beta-gp2/test bs=1048576 count=1000 oflag=dsync
dd if=/dev/zero of=/sgw-apha-io1/test bs=1048576 count=1000 oflag=dsync

この例では、1 MB のファイルが gp2 ベースおよび io1 ベースのファイル共有にそれぞれ 1000 回書き込まれました。同期 I/O を強制し、OS キャッシュを削除して、信頼性の高い結果を受け取るために、[oflag=dsync] キーを使用していることに留意してください。全体として、AWS クラウド環境による逸脱のおそれを克服するために、ファイル共有ごとに 12 のテストが行​​われました (表 1 および図 1)。

表 1: 1 MB ファイルでシーケンシャル I/O を使用した AWS Storage Gateway レイテンシーテストの結果 (dd Linux ツール)

図 1: 1 MB ファイルテストでのシーケンシャル I/O の AWS Storage Gateway のレイテンシーチャート (dd Linux ツール)

前の図に示されているとおり、両方の Storage Gateway の io1 ベースおよび gp2 ベースのスループットはほとんど同じままです。これは、小さなファイルの場合、IOPS がプロビジョニングされたストレージがそれほど重要ではないことを示唆しています。ただし、1 つの Storage Gateway は、最大 10 の異なるファイル共有を維持できることに留意してください。これらは、並行して作業しているときに、キャッシュの関与により、io1 ベースと gp2 ベースの Storage Gateway ファイル共有でパフォーマンスに大きな違いをもたらす可能性があります。

中規模のファイル (1 GB) を使用した同じテストの結果、io1 ベースの Storage Gateway ファイル共有の余剰が大きくなりました (表 2 および図 2)。この傾向はより大きなサイズのファイル (3〜5 GB) でも続いています。このことは、主に大きなファイルで構成されるデータストリームについて、io1 ベースの Storage Gateway が勝者であることを明らかにしています。これは、次の図で明確に示唆されています。

表 2: 1 GB ファイルのシーケンシャル I/O を使用した AWS Storage Gateway レイテンシーテストの結果 (dd Linux ツール)

図 2: 1 GB ファイルテストでのシーケンシャル I/O の AWS Storage Gateway のレイテンシーチャート (dd Linux ツール)

もう 1 つの留意すべき点は、io2 のパフォーマンスが一定に保たれ、時間の経過とともに低下しないことです。

Storage Gateway の非同期 I/O パフォーマンス

多くの科学機器は、複数のスレッドを介してデータを非同期に読み取り/書き込みします。そのような条件下における Storage Gateway の動作態様のデモンストレーションを行うことは、当社にとって不可欠な場合があります。このアクティビティをシミュレートする前に、テスト用の EC2 インスタンスに Flexible I/O Tester (Fio) ツールがインストールされている必要があります。Fio は、ユーザーが指定した特定のタイプの I/O アクションを実行する多数のスレッドを生成します。多くの興味深いパラメータが付属しており、複雑なテストシナリオをさまざまな I/O パターンに実装することもできます。Linux Fio のインストールプロセスは簡単で、次の 1 つのコマンドで実行できます。

sudo yum install fio -y

これで、4 つのアクティブスレッドを作成して、科学機器の動作を模倣できます。各スレッドは、Storage Gateway ファイル共有内に配置された 2 つの専用 4 GB ファイルに対して非同期に書き込みまたは読み取りを行います。次の Linux コマンドを使用して、テスト EC2 インスタンスでこれらのジョブを送信してみましょう。

gp2 ベースの Storage Gateway ファイル共有に対して実行されたジョブ:

fio --ioengine=libaio --name=sgw-test-gp2 --directory=/sgw-beta-gp2/ --bs=4k --iodepth=4
--numjobs=4 --size=8G --readwrite=randrw --rwmixread=25 --nrfiles=2

iop1 ベースの Storage Gateway ファイル共有に対して実行されたジョブ:

fio --ioengine=libaio --name=sgw-test-io1 --directory=/sgw-alpha-io1/ --bs=4k --iodepth=4 
--numjobs=4 --size=8G --readwrite=randrw --rwmixread=25 --nrfiles=2

ここでは、さまざまなコマンドラインオプションで以下を定義します。

• --ioengine – ジョブの I/O エンジン (その特定のケースでは Linux ネイティブ非同期 I/O)。
• --directory – ターゲットファイルデバイス/ディレクトリ
• --bs – I/O ユニットに使用されるバイト単位のブロックサイズ (この場合は 4 KB)
• --iodepth – ファイルに対する実行中に維持する I/O ユニットの数 (4)
• --numjobs – 並列ジョブの数 (4)
• --size – ジョブあたりのテストファイルの合計サイズ (8 GB をジョブあたりのファイル数で除した値 –nrfiles=2 で 4 GB のファイルが得られます)
• --readwrite – ランダム書き込みを定義します
• --rwmixread – 読み取りである必要がある混合ワークロードのパーセンテージを提供します (この場合、読み取りの場合は 25%、書き込みの場合は 75%)

c5.large テスト用 Amazon EC2 インスタンスで各ジョブを完了するのに約 3 時間かかります。このツールは大量の出力を生成するため、Fio 出力の解釈は簡単な作業ではありません。説明を簡単にするために、グループ統計のみに着目し、主に [aggrb] の結果図に焦点を当てます。これは、ジョブグループ全体のスレッドの総帯域幅を表します。それでも念のため、Fio の結果グループの統計を簡単に説明させてください。

• io – 実行された I/O のメガバイト数
• aggrb – グループ内のスレッドの総帯域幅
• minb – スレッドが確認した最小平均帯域幅
• maxb – スレッドが確認した最大平均帯域幅
• mint – グループ内のスレッドの最短実行時間
• maxt – グループ内のスレッドの最長実行時間

これは、テスト環境での各ジョブの完了時に Fio が報告するものです。繰り返しになりますが、ネットワーク、インフラストラクチャ構成、およびクラウドテスト環境専用ではないホスティングの違いにより、数値が異なる場合があります。

ジョブ sgw-test-gp2 (gp2 ベースの Storage Gateway に対して実行されます):

ジョブ sgw-test-io1 (io1 ベースの Storage Gateway に対して実行されます):

表 3 および図 3 は、これらの結果を読みやすい形式で示しています。

表 3: 4 GB ファイルの非同期ランダム I/O を使用した AWS Storage Gateway の I/O テストの結果 (Fio Linux ツール)

図 3: 4 GB ファイルの非同期ランダム I/O テストの AWS Storage Gateway の図 (Fio Linux ツール)

この最後の図で示唆されているように、io1 ベースの Storage Gateway ファイル共有は、大きなファイルを使用する非同期 I/O での gp2 ベースのゲートウェイよりもおよそ 36% 優れています。これはかなりの増加ですが、コストがかかり、ファイルサイズとビジネスロジックに依存します。

まとめ

Bristol Myers Squibb は、長年 Storage Gateway を使用し、テラバイト単位の科学データをローカルの施設から AWS クラウドに毎日移動しています。汎用 SSD ブロックストレージ (gp2 EBS ボリューム) が Storage Gateway の優れたオプションになり得ることを実証しました。これは、パフォーマンスへの影響を最小限に抑えて、中小規模のファイルサイズ (1 MB〜1 GB) のデータセットに特に当てはまります。EBS プロビジョンド IOPS SSD (io1) は、通常の gp2 ボリュームと交換されるため、節約できる可能性は最大で 40% に達する可能性があり、多くのライフサイエンスのアプリケーションではかなりの量になることがあります。

言うまでもなく、Bristol Myers Squibb は、Storage Gateway を使用してクラウドへのデータ転送を最適化しました。AWS は、信頼性の高いサービスポートフォリオを提供しており、当社は、これらを採用して、大規模データインフラストラクチャを安全に管理しています。AWS ストレージブログで、Bristol Myers Squibb の旅を AWS とさらに共有できることを楽しみにしています。Bristol Myers Squibb の AWS のサービスの使用に関するこの 2 部構成のシリーズをお読みいただきありがとうございます。また、ご不明な点がありましたら、コメントをお寄せください。

この記事の内容および意見は第三者の作者によるものであり、AWS はこの記事の内容または正確性について責任を負いません。