クラウドObjectストレージとの連携機能「FabricPool」の謎を解け!
第2回:FabricPoolのパフォーマンスと「読者への挑戦状」

 2020.01.23  ストレージチャンネル編集部

みなさま、こんにちは。株式会社ネットワールドの福住です。年末にAWSのre:Invent 2019に参加してきました。多数のスポンサーの中、NetAppさんかなり目立ってましたよ。NetAppのAWS連携への力の入れようを感じました。こちらについてはまた別途紹介したいと思います。

前回の投稿では、FabricPoolの基本的な動作について解説しました。今回はFabricPoolを使った場合のパフォーマンスを分析することによって、より詳細にFabricPoolへの理解を深めたいと思います。

さらに今回は推理小説よろしく、「読者への挑戦状」を出します。この投稿ではこのあとFabricPool利用時のストレージパフォーマンスを解説していきますが、意図的にある情報を操作しています。そうすることで、FabricPool機能を都合よく説明できるのですが、実態とは少し違う内容となっています。どんなトリックを使ったのか?考えながら読んでみてください。

fabricpool-networld-01

FabricPoolを使うとどれだけパフォーマンスが悪くなるのか?

FabricPoolのパフォーマンスを検証するということは、FabricPoolを使うとどの程度パフォーマンスが劣化するのか?を調べるということです。FabricPoolを使う以上パフォーマンス劣化は避けられないですよね。問題はその劣化具合が許容範囲かどうか、だと思います。もっとも、クラウドとの接続回線の種類/状態によりパフォーマンスは大きく異なりますので、これから紹介するデータはあくまでも参考値としてお考えください。弊社の検証機AFF A220とS3は一般的なインターネット回線で接続しました。Direct Connect等は利用していません。そのため、今回の検証はパフォーマンス検証という形をとっていますが、FabricPoolの動作をより深く理解するためにパフォーマンスを計測した、とご理解ください。

nw2-FabricPool-01

それでは実際にパフォーマンスを比較してみましょう。まずは単純にファイルコピー速度を「FabricPool有り」と「FabricPoolなし」の環境でくらべます。10GBのファイル一つをrobocopyでAFF A220からA200に転送します。このとき「FabricPool有り」の環境では、データの99%がS3にアップロードされています。10GBのファイルコピーにはS3から9.9GBのデータをダウンロードしてくる必要があります。さて結果はどうだったのでしょうか。

nw2-FabricPool-02

「FabricPoolなし」は約17秒、「FabricPoolあり」は約8分でファイルコピーできました。FabricPoolを利用するとパフォーマンスは20分の1以下になってしまう、という一見残念な結果となってしまいました。でもこれは仕方がないですよね。同じネットワークにいるAll Flash FAS間のデータコピーと、ほとんどのデータをインターネット経由でS3からダウンロードしてからコピーするのでは差がつくのは当然です。パフォーマンスが悪いと言っても、影響を受けるのはめったに利用しないデータを読み出すときだけです。

たまたま使われなかったデータがS3にアップロードされてしまったが、急にアクセス頻度が高くなってしまうケースでも問題ありません。FabricPoolでは一度オブジェクトストレージ(Capacity Tier)から読み出されたデータはSSD領域(Performance Tier)に書き戻す、という動作をします。次回以降同じデータにアクセスした場合、SSDから高速に読み出しできます。次はこの動作を実際に確認してみます。

オブジェクトストレージにあったデータでもSSDに書き戻す

まず、1GBのダミーファイルを用意し、その99%がS3にアップロードされている環境を作ります。次に、ダミーファイルに対して負荷ツールから32Kのランダムリードを30秒間連続でかけます。同じく30秒のアイドルタイムを置いてから再度30秒の負荷をかけます。これを都合5回実施します。

nw2-FabricPool-03

仕様通りの動作であれば、オブジェクトストレージからランダムに読み出されたデータは徐々にローカル環境のSSDに書き戻されていきます。そうすると、リードパフォーマンスも徐々に良くなっていくはずです。

nw2-FabricPool-04

NetAppのコマンドでクラウドからのリード(オブジェクトストレージからのダウンロード)とストレージ全体としてスループットを計測し、グラフにしました。結果は一目瞭然。一回目、二回目のテストではオブジェクトストレージからデータが読み込まれますが、スループットはグラフ上わずかです。3回目の途中からオブジェクトストレージからの読み込みがなくなり、4回目以降はほぼゼロとなりました。一方、スループットは3回目の途中から急激に向上し、以後は安定して高い値となっています。この結果から「1回目の段階では99%のデータがオブジェクトストレージに保存されているためパフォーマンスは低い。負荷をかけていくうちに徐々にオンプレのSSD領域(Performance Tier)にデータが書き戻され、4回目以降はほぼすべてのデータをSSDから読み出すため、高いパフォーマンスとなった」ということが推察できます。

ストレージに関するお役立ち資料

ただし、この検証結果からほんとうにそう言えるでしょうか。利用したダミーファイルは1GBと比較的小さなサイズです。ひょっとするとコントローラーメモリでキャッシュヒットしただけかもしれません。検証に利用したA220はコントローラーあたり32GBのメモリを搭載しています。すべてをリードキャッシュとして利用するわけではないのですが、たまたまランダムにアクセスしたデータが3回目以降キャッシュ上に残っていた、という可能性も捨てきれません。そこでもう一度別の検証をしてみました。

今度は100GBという大きめのダミーファイルを用意し、そのファイルに対して連続して50分間アクセスします。その際のストレージパフォーマンスを先程と同じコマンドで取得してグラフにしました。

nw2-FabricPool-05

Cloud readがオブジェクトストレージからのダウンロード量ですが、途中からほぼゼロになっています。SSD readは逆にある段階から急激に増えています。最終的なスループットであるNet outは、テスト開始当初はCloud readとほぼイコールですが、途中から大きく乖離します。SSD readと同じ曲線を描き、最終的には800MB/sという高い値で安定しました。つまり、当初はクラウドからデータを読み込んでいたが、一度読み込んだデータはSSDに書き戻すため、スループットパフォーマンスが向上した、ということです。この検証結果を持って、一度アクセスしたデータをSSDに書き戻してパフォーマンスを向上させる、というFabricPoolの仕様を確認できたと思います。

ストレージの自動階層化にはリアルタイム性が必要

これらの検証からFabricPoolの以下の特徴を確認できました。

  • FabricPoolを利用時、オブジェクトストレージに保存されたデータにアクセスする場合はパフォーマンスが大幅に低下する
  • ただし、オブジェクトストレージに保存されていたデータでも、一度アクセスされると再びホットデータとしてSSD領域(Performance Tier)に書き戻す

これらの特徴により、FabricPoolはアクセスパターンの急激な変更にもリアルタイムに対応できます。

ここで思い出していただきたいのが、第一回目で説明した「NetAppがストレージ自動階層化に消極的だった理由」です。NetAppはこれまで頑なにストレージ自動階層化(ティアリング)を導入してきませんでした。自動階層化よりもSSDキャシュによる仮想的なティアリングのほうが、アクセスパターンの急激な変更にもリアルタイムに対応できるため優れている、という考え方がその理由でした。そのような考え方のNetAppが初めて導入した(実データを移動させる)自動階層化機能がFabricPoolです。これまでの検証結果から、このFabricPoolがリアルタイム性を重視するNetAppの考え方をちゃんと継承していることがわかりますよね。

「読者への挑戦状」の解答

ここまで読んで頂いて、検証結果からFabricPoolの特性を理解、納得いただけたでしょうか?

納得したというそこのあなた!あなたはだまされていますよ‼

冒頭で予告したとおり、あるトリックを使って実態とはすこし異なる説明をしています。なぜそんなことをしたかというと、その方がわかりやすいからです。では、どんなトリックをつかって読者をだまそうとしたか、わかりましたか?

nw2-FabricPool-06

トリックを使ったのはこちらの資料です。よーく考えればこちらが世に跋扈する「インチキグラフ」であることがわかるはずです。

nw2-FabricPool-07

こちらのグラフ、縦軸の単位を記載していないんですね。単位(と目盛)をきちんと記載すると上記のグラフになります。ご覧のとおり、Net outとCloud readで単位は同じMB/sですが、目盛間隔が大きく異なります。左軸の最大700(MB/s)がNet out、右軸の最大16(MB/s)がCloud read用となります。今回の環境では、データの99%がオブジェクトストレージにアップロードされている環境で検証を実施しています。オンプレのSSD領域にはメタデータしか残っていません(メタデータはオブジェクトストレージにはアップロードしない仕様となっています)。一回目の負荷をかけた段階ではほぼすべてのデータをいったんS3からダウンロードしてから、負荷ツール側に渡します。そうすると、Cloud readとNet out(スループット)はほぼイコールになるはずです。手元にデータがないのですから、ダウンロードしたデータがそのままストレージから負荷ツールに渡されるデータとなる、ということです。実際、50分間連続して負荷をかける検証では、テスト開始直後はCloud readとNet outがほぼイコールになっていました。FabricPoolの仕様を正確に理解していれば、このトリックに気づけたのではないでしょうか。

nw2-FabricPool-08-2

nw2-FabricPool-09-2

目盛を調整しないグラフでは、スループットが向上していくのはわかるのですが、Cloud readが3回目の途中からなくなったことはまったくわかりません。そこでグラフの見せ方を少しだけ工夫した、というのが今回のトリックのタネ明かしです。「ありの~ままの~♪」がもてはやされていますが、常に良いとは限らないのです。「一回目、二回目のテストではオブジェクトストレージからデータが読み込まれますが、スループットはグラフ上わずかです」という記述、ギリギリセーフですよね。ありのままのグラフを見せず、姑息なトリックを使った背景には、SSDのReadパフォーマンスとインターネット回線経由でオブジェクトストレージをダウンロードするパフォーマンスでは、一つのグラフに収めることができないほど異なる、という事象があります。このギャップを埋める技術が重要になってきます。

無事に「読者への挑戦状」も解決できましたが、次回はFabricPool最大の謎「クラウドアップロードデータ、実は生きていた事件」に挑みます。お楽しみに。


株式会社ネットワールド

お問合せ窓口:netapp-info@networld.co.jp

執筆者:

株式会社ネットワールド fukusumi-sama
ストラテジック・プロダクツ営業部
福住 遊

NetAppの営業10年目。エンジニア経験は一切ない純粋な営業だが、CVOとクラウドが大好き。2020年のテーマは「オンプレに未練いっさいなし」。好きなペレックの作品は『さまざまな空間』。

NetApp Hybrid Cloud Architect & Administrator, AWS Solution Architect Associate, Perecien

福住が講師の資格取得プログラムやコミュニティイベント実施中!

NetAppくらうどコミュニティ「くらこみゅ」~クラウドSEに、俺はなる!~

https://www.networld.co.jp/product/netapp/kurakomyu/


最新情報お届け!Twitter / Facebook のフォローもお願いします!

  • ネットワールドFacebook (@Networld.TeamNetApp)

photo2

  • Networld Twitterアカウント(@nw_netapp)
図12-1

RELATED POST関連記事


RECENT POST「ネットワールド」の最新記事


クラウドObjectストレージとの連携機能「FabricPool」の謎を解け! 第2回:FabricPoolのパフォーマンスと「読者への挑戦状」
ネットアップクラウドデータサービス
ハイパーコンバージドインフラも新たな世代へ NetApp HCI
NetApp All Flash FAS

RANKING人気資料ランキング

FlexPodクラウドアプライアンス
{% if not contact.email %} {% include 'ClassicV1/controls/Blog/CT_BlogSidebar_CTA5.html' %} {% endif %}