Amazon FSx for NetApp ONTAP を使ったデータキャッシング

このブログは 2022 年 2 月 15 日に Eran Brown (Semiconductor specialist solutions architect) と Jens Dickmeis (Cloud Architect Manager) によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。

ネットワーク・アタッチド・ストレージ（NAS）に長距離でアクセスすると、待ち時間が発生し、ビジネス・プロセスへの影響、エンジニアの仕事の遅延、コスト増の原因となる可能性があります。多くの場合、データセットのごく一部にしかアクセスする必要がないため、データをローカルにキャッシュすることで、データセット全体を複製する必要が無くなるので、こうした課題を解決することができます。これは、オンプレミスとクラウド（クラウドバーストなど）を含む複数の場所にコンピュートリソースが配置されている場合や、追加のコンピュートリソースにアクセスするために複数の AWS Availability Zone（AZ）または複数のリージョンにまたがる場合に特に有用となります。

Amazon FSx for NetApp ONTAP は、ONTAP のデータアクセスおよびエンタープライズデータ管理機能をフルパワーで提供し、そのパフォーマンスをお客様に提供します。これには、FlexCache ボリュームが含まれます。FlexCache ボリュームは 1 つの場所にある ONTAP ボリュームで、リモート ONTAP ボリューム（つまりオリジンボリューム）からのデータをキャッシュし、ローカル読み取りのレイテンシを低減します。オリジンボリュームは、別の FSx for ONTAP ファイルシステム、NetApp Cloud Volumes ONTAP（CVO）インスタンス、あるいはオンプレミスで稼働する物理 NetApp システムでもかまいません。読み取りは FlexCache ボリュームにローカルにキャッシュされますが、書き込みはキャッシュを経由してオリジンボリュームに送信されるため、データのシングルソースオブトゥルース（信頼できる唯一の情報源）を維持することができます。これにより、あるエンジニアがプロジェクトファイルを変更しても、別の場所にいる別のエンジニアが同じファイルの旧バージョンを読み込むという不整合を防ぐことができます。

NetApp は、ソフトウェア開発、メディア・エンターテイメント、半導体など、グローバルに複数の業界で利用されています。これらの業界のワークロードは、現在利用しているすべてのエンタープライズ機能を備えた、フルマネージド ONTAP サービスのシンプルさの恩恵を受けることができます。AWS にデータがあれば、エンジニアは数分で数万の計算コアに拡張し、AI/ML パイプラインを構築し、分析など他の AWS サービスと統合することができます。

この記事では、FSx for ONTAP FlexCache を活用して、共有ファイルシステムのパフォーマンスを向上させ、データ転送コストを削減するためのいくつかのパターンを紹介します。以下の構成はすべて、FSx for ONTAP とソース ONTAP システム間のネットワーク通信を必要とします。ピアリングを設定する方法の詳細については、FSx for ONTAP getting started guide を参照してください。

未知のワーキングデータセットのキャッシング

既存のオンプレミス型 NetApp ファイルシステムは、複数のプロジェクトのデータを共有していることが多く、あるプロジェクトがバーストする必要があったり、完全にクラウドへ移行したりしなければならないときに問題が発生します。お客様は、ビジネスの中断を犠牲にしてでもデータ移行を最小化するためにファイルシステムを分割すべきか、必要以上に多くのデータを移行すべきか、ジレンマに直面することになります。FlexCache でデータをキャッシュすることで、AWS で使用されているデータブロックのみがキャッシュにコピーされ、キャッシュは時間と共に蓄積していきます（レイジーローディング）。この結果、AWS へのバーストが高速化され、帯域幅とコストが削減されます。

Figure1 FlexCache only caches the blocks within files that users read locally

図 1 : FlexCache は、ユーザーがローカルで読み取るファイル内のブロックのみをキャッシュする

クラウドバースティング

FlexCache ボリュームのシンプルな使用例としては、データのシングルソースオブトゥルース（信頼できる唯一の情報源）はオンプレミスのままでの、クラウドへのバースト、Amazon EC2 インスタンスへの低レイテンシーデータアクセスなどがあります。

Figure 2 Caching data from an on-premises NetApp system

図 2 ：オンプレミスの NetApp システムからのデータキャッシュ

スケールアップではなくスケールアウト

アプリケーションが成長して追加の読み取り容量が必要になると、ストレージを拡張する代わりに、FlexCache を活用してクライアントを異なる Amazon FSx for NetApp ONTAP ファイルシステム間に分散し、単一のファイルシステムの能力を超えてパフォーマンスを向上させるという選択肢もあります。新しいクライアントが追加された場合、新しいFlexCache ボリュームにマウントすることで、ソースボリュームにさらなるパフォーマンスを提供することができます。

Figure 3 Achieving higher read performance with multiple FSx for ONTAP file systems

図 3 ：複数の FSx for ONTAP ファイルシステムによる高い読み取り性能の実現

単一のアベイラビリティーゾーンを超えたスケーリング

例えば、ハイパフォーマンスコンピューティング（HPC）、特定のインスタンスタイプ（例えば、GPU 搭載のもの）を大量に必要とするワークロード、大規模なスポットフリートに依存するワークロードなど、多くのワークロードは単一の AWS アベイラビリティーゾーンを超えて拡張することでメリットを得ることができます。これらのワークロードの多くは、共有ストレージへの高速アクセスを必要とし、レイテンシーが増加すると、データ処理が遅くなったり、高価なソフトウェアライセンスの使用期間を延長しなければならない可能性があります。また、単一の Amazon FSx for NetApp ONTAP ファイルシステムの最大スループットを超えるスケーリングも可能になります。

これらのワークロードは、1つのアベイラビリティーゾーンで FSx for ONTAP を利用し、同じ AWS リージョン内の他のアベイラビリティーゾーンで1つ（または複数）の FlexCache ボリュームを利用することで、メリットを得ることができます。AZ 間のレイテンシーが低いため、オリジンキャッシュからデータを迅速に取得でき、キャッシュに書き込む際にもレイテンシーがわずかに増加するだけです。

Figure 4 FSx for ONTAP in two Availability Zone, caching data for local access within each Availability Zone

図 4 ： 2 つの AZ における FSx for ONTAP、各 AZ 内のローカルアクセス用にデータをキャッシュ

グローバルなスケールでのコラボレーションを実現

企業によっては、グローバルに分散した開発チームが共同でプロジェクトを進めていることがあります。例えば、複数の国で同じ集積回路（IC）を開発している半導体企業では、各リージョンの NAS に高速にアクセスする必要があります。従来は、このような場合、データへの読み取り専用アクセスを提供するデータセット全体の複製を使用していましたが、追加の管理オーバーヘッドを必要としました。また、これらの複製は非同期であったため、一部のサイトでは古いバージョンのファイルを長期間にわたって使用する結果となっていました。

Amazon FSx for NetApp ONTAP を利用することで、エンジニアは複数の AWS リージョンで、ローカルキャッシュと選択したリージョンにあるシングルソースオブトゥルース（信頼できる唯一の情報源）を使って、同じ IC 設計ファイルを操作することができます。最近変更されたファイルにアクセスするエンジニアは、手作業や次のレプリケーションサイクルを待つことなく、常に最新バージョンを取得することができます。

Figure 5 FSx for ONTAP in one Region caching data from a remote Region

図 5 ：あるリージョンの FSx for ONTAP が、リモートリージョンのデータをキャッシュ

類似クライアントをグループ化し、キャッシュヒット率を高める

レイテンシーを最小化するために、キャッシュソリューションを設計する際の目標は、キャッシュヒット率を高めることです。これは、同じ FSx for ONTAP FlexCache ボリュームをマウントするクライアントが類似のデータセットで作業している場合に達成され、オリジンボリュームからのデータフェッチ要求を最小限に抑えることができます。たとえば、HPC クラスタでは、同じデータセットを処理するすべてのクライアントを同じ FlexCache ボリュームにマウントすると、クライアントをランダムにマウントする場合と比較してパフォーマンスが向上します。

Figure 6 Grouping similar clients on different FlexCache volumes to increase cache hit ratio

図 6 ：類似のクライアントを異なる FlexCache ボリュームにグループ化し、キャッシュヒット率を向上

双方向キャッシュによる出力アクセスの高速化

一般的なバーストシナリオは、ソースデータが AWS 上またはオンプレミスにある状態で AWS 上でジョブを大規模に実行し、ジョブ実行中に出力ファイルや詳細ログファイルを生成し、これらのファイルを様々な場所から利用することです。

FlexCache は、クラウドバーストジョブの出力へのアクセスを高速化するために双方向にセットアップすることができます。双方向の設定では、入力ファイルはオンプレミスに存在し、クラウドにキャッシュされ、出力ファイルはクラウドに存在し、オンプレミスにキャッシュされます。

Figure 7 Bidirectional caching input files cached in AWS and output files cached on premises

図 7 ： AWS にキャッシュされた入力ファイルとオンプレミスにキャッシュされた出力ファイルの双方向キャッシュ

測定とモニタリング

FlexCache の実装を成功させるには、計画とモニタリングが必要です。いくつかのベストプラクティスを紹介します。

ネットワーク： キャッシュミスはオリジンボリュームからデータブロックを取得する必要があり、書き込みはオリジンから承認される必要があります。どちらの操作も利用可能な帯域幅によって制限され、リンクによって大幅な遅延が発生すると、速度が低下します。利用可能な帯域幅を測定し、アクセスする必要があるデータのサイズ（ワーキングセットサイズ）を推定して、キャッシュのウォームアップ（ハイドレーション）時間を推定します。帯域幅が限られている場合は、新しいインスタンスを起動する前にキャッシュをハイドレートすることを決定することができます。

スケーラビリティ（拡張性）： ファイルシステムは、時間とともに容量や性能が大きくなる傾向があります。FlexCache ボリュームはオリジンボリュームより小さい場合があるため、FlexCache ボリュームのサイズをいつ大きくしなければならないかを特定することが重要です。これは、FlexCache ボリュームのキャッシュヒット率を監視し、時間をかけて異なるサイズを試し、特定のワークロードが異なるサイズのキャッシュにどのように反応するかを確認するのが最も良い方法です。キャッシュヒット率が低下し始めたら、キャッシュのサイズを大きくしてください。

モニタリング： ネットワークとスケーラビリティの両方が長期に渡って機能するためには、モニタリングが必要です。モニタリングには、少なくとも 3 つの主要な分野を含める必要があります。

FlexCache のキャッシュヒット率：オープンソースのツール Harvest を使って監視し、Grafana にフィードすることができます。
FlexCache ボリュームとオリジンボリューム間のネットワーク接続：書き込みとオリジンフェッチのレイテンシーが高くなる可能性があるので、パケットロスと利用可能な帯域幅を監視します。これは、標準的なネットワーク監視ツールによって実現できます。
オリジンボリュームの応答時間：オリジンボリュームにボトルネックがあると、オリジンフェッチと、オリジンに戻る FlexCache ボリュームの書き込みのレイテンシーが増加します。これも Harvest を使用して監視することができます。

まとめ

Amazon FSx for NetApp ONTAP を使用すると、データセット全体を複製することなく、リモートで NAS ファイルシステムへのアクセスを高速化できますが、特定のユースケースのニーズを満たすための計画が必要です。適切な導入パターン（たとえば、同じアベイラビリティーゾーン内でのキャッシュ、アベイラビリティーゾーンをまたがるキャッシュ、リージョンをまたがるキャッシュ）を選択すれば、必要なリソースに適切にアクセスできます。一方、双方向キャッシュを活用すれば、クラウドで生成したデータへのオンプレミスからのアクセスを加速し、さらに成果を上げることができます。これらはすべて、データセット全体をクラウドにレプリケートすることなく実現でき、時間、帯域、容量を削減できます。

FSx for ONTAP を使用したキャッシュのベストプラクティスに関するこのブログ記事をお読みいただき、ありがとうございました。コメントや質問がある場合は、遠慮なくコメント欄にご記入ください。

翻訳は Storage SA 竹内が担当しました。

Amazon Web Services ブログ