みなさま、こんにちは。株式会社ネットワールドのペレキアン、福住です。前回の投稿では、FabricPoolのパフォーマンス検証結果を分析して、FabricPoolの動作を細かく見ていきました。実はその検証中、ある不可解な事象が発生していました。その事象こそ、FabricPool最大の謎として知られる「クラウドアップロードデータ、実は生きていた」事件なのです！
今回はこの事件の謎に迫ります。
事件の発端：不可解な事象
前回はFabricPool利用有無によるrobocopyパフォーマンスの比較検証結果をお伝えしました。
「FabricPool有り」の環境ではS3からのデータダウンロードが必要なため、「FabricPoolなし」に比べて大幅なパフォーマンスダウンが見られた、という検証結果でした。FabricPoolの仕様上、仕方がない結果ですよね。性能劣化は残念ですが、まあ納得できる結果だと思います。ところが、実はこの検証を実施した際になんとも不可解な結果が出ていたのです。
なんと、「FabricPool有り」「FabricPoolなし」でほとんど同じパフォーマンス結果が出ていたのです。「FabricPool有り」ではデータの99%がS3に保存されています。インターネット経由で9.9GBのデータをダウンロードしてからファイルコピーしますので、コピー時間は絶対に「FabricPoolなし」よりも大幅に遅くなるはずです。
理由がよくわからないので、もう一度別の検証をしてみました。
今度は100GBのダミーファイルに対して、負荷サーバーから4K～64KのランダムReadを順次30秒ずつかけていきます。その際のパフォーマンス結果をFabricPool利用有無で比較します。100GBあればコントローラーのメモリ上に全データが乗ることも有りませんし、なによりAggregateには27GBのデータしか残っていません。この環境であれば、「FabricPoolなし」が圧倒的に高いパフォーマンスを発揮するはずです。さて結果はどうだったのでしょうか？
なんと、またしても不可思議な結果が出てしまいました。事前の予想に反して、FabricPool有無でほぼ同じパフォーマンスとなってしまいました。64K時のパフォーマンスこそ悪いものの、16K/32KのReadパフォーマンスに至っては「FabricPoolなし」よりも「FabricPool有り」のほうが高い結果となってしまいました。良いパフォーマンスが出ていぶかるのもへんな話ですが、このような「直感に反する結果」に直面するとひとは狼狽してしまいます。明らかに不自然な結果です。
「クラウドObjectストレージとの連携機能「FabricPool」の謎を解け！第2回：FabricPoolのパフォーマンスと「読者への挑戦状」」についてもっと詳しくご覧ください。
いったいどういうことなのでしょうか？あれこれ考えても仕方がありませんので、推理に入る前にもう少し調査してみましょう。
先ほどと同じ検証を実施して、コマンドでAFFへのデータの出入りを一秒ごとに出力させました。するとなんとびっくり、Cloud（S3）からは一切データをダウンロードせずに、SSDからデータを読み込んでいたことがわかりました。でも、対象のデータはオンプレのAFFにはほとんど残っておらず、99%のデータはS3にあるはずです。それなのになぜ、SSDからデータを読み出すことができたのでしょうか？もしかして不可能犯罪？
犯人はあの人だった！ストレージ探偵の名推理
ここからは推理するしかありません。もう一度整理してみましょう。FabricPoolのティアリングでオンプレのSSDにはメタデータしか残っていません。負荷ツールからRead要求をかけると、S3からデータをダウンロードするはずです。ところが、実際にはS3からデータをダウンロードせずにSSDからデータを読み出していました。この状況はなにを意味しているのでしょうか。まるで推理小説の密室のようですね。ストレージ探偵の腕の見せ所です。こういうときはシンプルに考えましょう。この状況から導き出せる事実は「データはオンプレのSSDに残っていた」ということです。
ここからはあくまでもストレージ探偵の推理（推測）です。メーカー公式の見解ではありませんのでご注意ください。消えたはずのデータが残っていた！ということであれば、その謎にはファイルシステムの仕様に関係がありそうです。NetAppのファイルシステムといえばWAFL（Write Anywhere File Layout）ですよね。WAFLはNetAppが特許を取得している独自のファイルシステムで、1992年の製品リリースから採用されています。WAFLの特徴としては1）効率的なデータの書き込み、2）データ更新は上書きではなく追記、があります。ここでポイントになるのは2）データ更新は上書きではなく追記、という特徴です。
NetAppさんの資料を元に解説してみます。例えば、A,B,Cというブロックがあるとします。このうちB,Cを編集する場合、WAFLではB,Cのあった場所にD,Eを上書きするのではなく、空いているブロックにD,Eを追記します。B,Cのブロックは論理的には「削除された」ことになっています。でも実はまだデータとしては残っています。空のブロックがなくなるまではB,Cにデータが上書きされることはありません。まさに消えたデータは「実は生きていた」のです。
そうです。すべてはWAFLのせい（おかげ）、というのがストレージ探偵の推理です。犯人として告発されていますがWAFLはなにも悪くなく、むしろWAFLはFabricPoolを使う上で大きなメリットを提供しています。
※事件の犯人?「わっふるん」の正体をしりたい方はこちらを見るべし。
FabricPoolの機能を使ってColdデータ（全データの99%）をS3にアップロードします。ポリシー「all」を使った場合、オンプレSSDにはごくわずかなメタデータだけが残ります。ところが、S3にアップロードされたデータは上書きされるまではオンプレには残っています。それであれば、読み出し要求があった場合に、S3にあるデータをダウンロードするのではなく、手元にソンビのように残っているデータを使ってしまえ！というのが事の真相と推測しています。S3からデータをダウンロードすると、確実にパフォーマンスは低下します。しかも、クラウドからオンプレにデータをダウンロードすると、データ量に応じた料金がAWSから請求されてしまいます。これらの課題を見事に解決するためWAFLが「良かれと思ってやった」のが事件の真相ということではないでしょうか。ちなみにこの推理、メーカーさんにぶつけてみたところ「非開示のアーキテクチャのためノーコメント」とのことでした。
それでも残る謎：ネットワールドの検証結果はウソだったのか⁉
ストレージ探偵によって無事に「クラウドアップロードデータ、実は生きていた」事件は解決？されました。でもちょっと待ってください。「クラウドアップロードデータ、実は生きていた」事件があったとするならば、この連載第二回で紹介した検証データ（FabricPoolを利用すると当然のごとくパフォーマンスが低下する）はなんだったのでしょうか。
この検証データはウソだったのでしょうか。いえ、もちろん違います。でもこの検証データを出すためにちょっとした工夫をしています。
FabricPoolのポリシー「all」を適用してColdデータをS3にアップロードすると、Aggregateの利用率は激減します。この状態でパフォーマンステストを実施しても、S3からデータをダウンロードしないため、良いパフォーマンスが出てしまいます。実際にS3からダウンロードした場合のパフォーマンスを調べるために、新たなデータをAggregateの利用率が70%程度になるまで上書きしてからテストを実施しました。ゾンビデータは新たなデータに上書きされてしまいますので、テスト時にはS3からデータがダウンロードされることになります。結果、「悪いパフォーマンス値」が得られます。
さらにもう一つポイントがあります。新たなデータを上書きしてAggregateの利用率を70%程度にして負荷テストを実施しました。これが利用率80%、90%ではなく70%であることにも注目してください。Aggregateの利用率が70%を越えると、今後は下記の検証データが取れなくなります。
連載第二回で説明したこちらのグラフからは、S3からデータをダウンロードすると、そのデータがオンプレのSSDに書き戻され、徐々にクラウドからの読み出しは減り、SSDからの読み出しが増えていることがわかります。ところが、Aggregate利用率が70%を越えているとこの結果は得られません。S3からデータを読みだした後、SSDにデータを書き戻すことはないのです。再度同じデータの読み出し要求があったとしても、改めてS3からダウンロードしてくるだけです。なぜかというと、しきい値70%を越えてもデータをSSDに書き戻していると、どんどんAggregateの利用率はあがってしまい、新規データを書き込む場所がなくなってしまうからです。
FabricPoolの動作を細かくみていくと、かなりよく作り込まれていることがわかります。「クラウドアップロードデータ、実は生きていた」事件の真相も、ストレージ探偵の推理が正しければ、WAFLの特徴と組み合わせたすばらしい技術です。でも、実際にS3からダウンロードしたときのパフォーマンスインパクトを知りたい、というときにはゾンビデータを使ってしまう動作は実は困りものです。この動作を知っていないと、パフォーマンスを勘違いしてしまう可能性もありますのでご注意ください。
次回は「FabricPool+FlexGroupで実現するなんちゃってマルチクラウド」の予定です。お楽しみに。
株式会社ネットワールド
お問合せ窓口：netapp-info@networld.co.jp
執筆者：
株式会社ネットワールド 
ストラテジック・プロダクツ営業部
福住 遊
NetApp専門の営業だったのに、最近部門ごとマーケティングに引っ越してしまったので今はマーケティング部門に所属。エンジニア経験は一切ないが、CVOとクラウドとジョルジュ・ペレックが大好き。2020年のテーマは「オンプレに未練いっさいなし」。好きなペレック論文はAnne Roche, «Le REVENANT», Cahiers Perec N 2, P.O.L, 1988。ペレック『Wあるいは子供の頃の思い出』では、父の写真の裏に『ハムレット』の一節を書き込もうとしたという逸話が唐突に紹介されるのだが…
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）
