みなさま、こんにちは。株式会社ネットワールドの福住です。年末にAWSのre:Invent 2019に参加してきました。多数のスポンサーの中、NetAppさんかなり目立ってましたよ。NetAppのAWS連携への力の入れようを感じました。こちらについてはまた別途紹介したいと思います。
前回の投稿では、FabricPoolの基本的な動作について解説しました。今回はFabricPoolを使った場合のパフォーマンスを分析することによって、より詳細にFabricPoolへの理解を深めたいと思います。
さらに今回は推理小説よろしく、「読者への挑戦状」を出します。この投稿ではこのあとFabricPool利用時のストレージパフォーマンスを解説していきますが、意図的にある情報を操作しています。そうすることで、FabricPool機能を都合よく説明できるのですが、実態とは少し違う内容となっています。どんなトリックを使ったのか？考えながら読んでみてください。
FabricPoolを使うとどれだけパフォーマンスが悪くなるのか？
FabricPoolのパフォーマンスを検証するということは、FabricPoolを使うとどの程度パフォーマンスが劣化するのか？を調べるということです。FabricPoolを使う以上パフォーマンス劣化は避けられないですよね。問題はその劣化具合が許容範囲かどうか、だと思います。もっとも、クラウドとの接続回線の種類/状態によりパフォーマンスは大きく異なりますので、これから紹介するデータはあくまでも参考値としてお考えください。弊社の検証機AFF A220とS3は一般的なインターネット回線で接続しました。Direct Connect等は利用していません。そのため、今回の検証はパフォーマンス検証という形をとっていますが、FabricPoolの動作をより深く理解するためにパフォーマンスを計測した、とご理解ください。
それでは実際にパフォーマンスを比較してみましょう。まずは単純にファイルコピー速度を「FabricPool有り」と「FabricPoolなし」の環境でくらべます。10GBのファイル一つをrobocopyでAFF A220からA200に転送します。このとき「FabricPool有り」の環境では、データの99%がS3にアップロードされています。10GBのファイルコピーに
「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回実施します。
仕様通りの動作であれば、オブジェクトストレージからランダムに読み出されたデータは徐々にローカル環境のSSDに書き戻されていきます。そうすると、リードパフォーマンスも徐々に良くなっていくはずです。
NetAppのコマンドでクラウドからのリード（オブジェクトストレージからのダウンロード）とストレージ全体としてスループットを計測し、グラフにしました。結果は一目瞭然。一回目、二回目のテストではオブジェクトストレージからデータが読み込まれますが、スループットはグラフ上わずかです。3回目の途中からオブジェクトストレージからの読み込みがなくなり、4回目以降はほぼゼロとなりました。一方、スループットは3回目の途中から急激に向上し、以後は安定して高い値となっています。この結果から「1回目の段階では99%のデータがオブジェクトストレージに保存されているためパフォーマンスは低い。負荷をかけていくうちに徐々にオンプレのSSD領域（Performance Tier）にデータが書き戻され、4回目以降はほぼすべてのデータをSSDから読み出すため、高いパフォーマンスとなった」ということが推察できます。
ただし、この検証結果からほんとうにそう言えるでしょうか。利用したダミーファイルは1GBと比較的小さなサイズです。ひょっとするとコントローラーメモリでキャッシュヒットしただけかもしれません。検証に利用したA220はコントローラーあたり32GBのメモリを搭載しています。すべてをリードキャッシュとして利用するわけではないのですが、たまたま
今度は100GBという大きめのダミーファイルを用意し、そのファイルに対して連続して50分間アクセスします。その際のストレージパフォーマンスを先程と同じコマンドで取得してグラフにしました。
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の特性を理解、納得いただけたでしょうか？
納得したというそこのあなた！
冒頭で予告したとおり、あるトリックを使って実態とはすこし異なる説明をしています。なぜそんなことをしたかというと、その方がわかりやすいからです。では、どんなトリックをつかって読者をだまそうとしたか、わかりましたか？
トリックを使ったのはこちらの資料です。よーく考えればこちらが世に跋扈する「インチキグラフ」であることがわかるはずです。
こちらのグラフ、縦軸の単位を記載していないんですね。単位（と目盛）をきちんと記載すると上記のグラフになります。ご覧のとおり、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の仕様を正確に理解していれば、このトリックに気づけたのではないでしょうか。
目盛を調整しないグラフでは、スループットが向上していくのはわかるのですが、Cloud readが3回目の途中からなくなったことはまったくわかりません。そこでグラフの見せ方を少しだけ工夫した、というのが今回のトリックのタネ明かしです。「ありの~ままの~♪」がもてはやされていますが、常に良いとは限らないのです。「一回目、二回目のテストではオブジェクトストレージからデータが読み込まれますが、スループットはグラフ上わずかです」という記述、ギリギリセーフですよね。ありのままのグラフを見せず、姑息なトリックを使った背景には、SSDのReadパフォーマンスとインターネット回線経由でオブジェクトストレージをダウンロードするパフォーマンスでは、一つのグラフに収めることができないほど異なる、という事象があります。このギャップを埋める技術が重要になってきます。
無事に「読者への挑戦状」も解決できましたが、次回はFabricPool最大の謎「クラウドアップロードデータ、実は生きていた事件」に挑みます。お楽しみに。
株式会社ネットワールド
お問合せ窓口：netapp-info@networld.co.jp
執筆者：
株式会社ネットワールド 
ストラテジック・プロダクツ営業部
福住 遊
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）
- Networld Twitterアカウント（@nw_netapp）
