#目次

この記事のサマリー
環境
構成上の留意点
テスト結果 - 構成別の性能差 (CVOのsysstat結果を記載)
テストする際の考慮点
まとめと雑談
関連情報

#1. この記事のサマリー

いくつか条件を変えてクラウドへのデータ移行性能をテストした結果を一覧表にしています。
移行先はクラウドインスタンス上で動作するNetApp CVO(Cloud Volumes ONTAP)です。
移行にONTAPのSnapMirrorを使わず、ツールで上抜きコピーしています。
既存で存在する技術レポート(TR-4383)にはCVOの単体性能が書かれていますので、参考にしてください。
TR-4383 Performance Characterization of NetApp Cloud Volumes ONTAP for Amazon Web Services
https://www.netapp.com/pdf.html?item=/media/9088-tr4383pdf.pdf
このQiita記事ではTR-4383に記載されていないDirect Connect経由の性能測定をしており、また、CVOに割り当てるEBSストレージの容量・数・タイプを変えて計測しています。
NFS to NFSを前提に計測しましたが、CIFS to CIFSでもそれほど大きな違いはありませんでした。
環境の詳細を以下に記載しますが、まず最初に1GのDirect Connectを使った際にはネットワーク回線ネックがあらわれて、10Gに切り替えた後は移行先のEBSストレージの性能ネックが見えてきました。そして最後にCVOが動作するインスタンスタイプ起因のボトルネックがありました。
回線はDirect Connectを使ったためストレージ間の遅延は2ms程度でした。
10GのAWS Direct Connect回線は非常に高速で、受け側のストレージが十分に高性能であれば24時間で50TB以上のデータをクラウドに移行することも可能です。AWSへのアップロードの回線コストは固定費として1時間で約$2.361/時間(東京リージョン、2021年4月時点)となり、24時間使っても7000円未満です。(Equinixデータセンターの利用料は別。)
価格表：https://aws.amazon.com/jp/directconnect/pricing/
インターネットVPN(Nuro Biz回線, インターネットVPN1Gbps)を使ったパターンも~~今後テスト予定です。~~テストしました。
■AWSと1GbpsでインターネットVPN接続してデータ移行性能を計測してみた (NetApp FAS -> CVO)
https://qiita.com/kan_itani/items/8dc4f0995833df54ab59

#2. 環境

移行元ストレージ（設置先：Equinixデータセンター、大手町TY4）
- NetApp FAS8040 (ONTAP9.1) / DS2246 (SSD x24本)
移行先ストレージ（AWS東京リージョン）
- NetApp CVO (Cloud Volumes ONTAP, ONTAP 9.9.0)
- CVOのHA構成: 無し(=Single Node)
- CVOのインスタンスタイプ：m5.xlarge / r5.2xlarge / r5.12xlarge
- CVOにアタッチするEBS：gp2(SSD) / st1(HDD)
  ※ CVOにアタッチしたEBSボリュームはRAID-0でストライプされて利用されます。
  ※ 同じタイプの同じサイズのEBSをそのRAID内に入れることができます。
  ※ 既存のRAID-0内に後からEBSを追加することもできますが、すでにDISK使用率が高い場合は後から追加したEBSにWriteが偏るため、性能面でのメリットはあまりありません。
ネットワーク回線
- Equinixデータセンター経由のAWS Direct Connect接続 (1Gbps/10Gbps)
  ※ Direct ConnectのMTUは1500
データ移行ツール
　(1) NetApp XCP　(ホストインストール型ソフトウェア)
　(2) NetApp Cloud Sync　(SaaSサービス)
　※ ラージファイルをテストデータに使ったため性能差があまりなく、以下はXCPでの結果を記載しています。
　※ XCPをインストールしたサーバは4コア32GBで、このサーバネックにならないようにサイジングしています。

#3. 構成上の留意点

回線速度を使いきれるように移行元データはSSD上に配置しました。
事前にオンプレ to オンプレでデータ移行を試し、移行元で1000MBytes/s以上の読み出し性能が出せることを確認しています。
ボトルネックはDirect Connect回線、もしくはクラウド上のインスタンスとなる構成としました。
MTUを9000にするともう少し性能が出るかもしれませんが、デフォルトのまま試しています。

#4. テスト結果 - 構成別の性能差 (CVOのsysstat結果を記載)

No.	インスタンス	回線速度	EBS構成(gp2 or st1)	転送レート(bytes/s)	CPU使用率(CVO)	備考
(1)	m5.xlarge	1Gbps	gp2 500GB x1	120 MB/s	50-70%	1Gbps回線ネック。gp2のバーストクレジットが無くなるとさらに半分程度まで性能が落ちる
(2)	m5.xlarge	10Gbps	st1 1TB x2	250-300 MB/s	60-70%	EBSネック。st1のバーストクレジットが無くなるとそのボリュームサイズ本来の速度になる
(3)	m5.xlarge	10Gbps	gp2 1TB x4	未テスト	未テスト	CVOのCPUネックになる可能性大
(4)	r5.2xlarge	10Gbps	gp2 8TB x1	260 MB/s	30-45%	EBSネック
(5)	r5.2xlarge	10Gbps	gp2 1TB x4	580 MB/S	65-75%	r5.2xlargeインスタンスのEBS 帯域幅ネック。AWSのマニュアルでは最大4,750Mbps(≒593MB/s)と記載有
(6)	r5.2xlarge	10Gbps	st1 1TB x4	250-300 MB/s	30-45%	st1を4つ束ねても性能向上しない。平均250 MB/s程度。
(7)	r5.12xlarge	10Gbps	gp2 2TB x2	530 MB/s	10-14%	CPU負荷は低く、EBSネック
(8)	r5.12xlarge	10Gbps	gp2 1TB x4	680-720 MB/s	16-17%	EBSネック。r5.12xlargeのEBS帯域幅は9,500Mbpsのため、gp2 1TB x8にすれば1187MB/s(≒9500Mbps)まで出る可能性有り、10Gbpsを使い切れると想定

(1) m5.xlarge(1G, gp1 500GB x1の性能)
- CVOのsysstat
- XCPデータ移行ツールの結果
(2) m5.xlarge(10G, st1 1TB x2の性能)
- CVOのsysstat結果
- XCPデータ移行ツールの表示
(3) m5.xlarge(10G, gp2 1TB x4の性能)
- CVOのsysstat結果
  - 未テスト
- XCPデータ移行ツールの表示
  - 未テスト
(4) r5.2xlarge(10G, gp2 8TB x1の性能)
- CVOのsysstat結果
- XCPデータ移行ツールの表示
(5) r5.2xlarge(10G, gp2 1TB x4の性能)
- CVOのsysstat結果
- XCPデータ移行ツールの表示
(6) r5.2xlarge(10G, st1 1TB x4の性能)
- CVOのsysstat結果
- XCPデータ移行ツールの表示
(7) r5.12xlarge(10G, gp2 2TB x2の性能)
- CVOのsysstat結果
- XCPデータ移行ツールの表示
(8) r5.12xlarge(10G, gp2 1TB x4の性能)
- CVOのsysstat結果
- XCPデータ移行ツールの表示

#5. テストする際の考慮点

EBSのサイズとバーストクレジットに注意
EBSはディスクタイプとそのサイズによってベースの性能とバースト性能が異なるため、最初は高速に転送できても1時間後には低速になることもあります。
以下の**「I/O クレジットおよびバーストパフォーマンス」**が参考になりますが、
【Amazon EBS ボリュームの種類】
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html#EBSVolumeTypes_considerations
- 汎用SSDボリューム(gp2)の場合の性能
  
  とても長いので、クラスメソッドさんのブログをおすすめします。（シンプルでわかりやすい）
  https://dev.classmethod.jp/articles/ebs-gp2-burstbalance/
CVOは割り当てられたEBSをRAID-0でストライプしますが、8TBのgp2ボリューム1つの構成と、1TBのgp2ボリュームを4つストライプする構成では後者の方が性能が出ました。サイジングする際には容量だけでなくEBSの本数も考慮して構築してみてください。
EBS単体の性能だけでなく、インスタンスタイプ毎に制限があるため、以下の**「ネットワーク帯域幅」と「EBS帯域幅」**を確認の上、自分で利用するEC2インスタンスを選択することをお勧めします。
【Amazon EC2インスタンスタイプ】
https://aws.amazon.com/jp/ec2/instance-types/

インスタンスの最大性能を超えるEBSを割り当てても性能が出ないので、容量と性能のバランスを考えてEBSのタイプ(gp2/io2/st1/sc1)を選択することでコストを下げることができます。
st1のEBSは2個、4個と本数を増やしても、性能はリニアに向上しませんでした。AWSのマニュアルには、
「1 TiB の st1 ボリュームの場合、バーストスループットは 250 MiB/秒に制限され、バケットのクレジットは 40 MiB/秒で最大 1 TiB 分まで累積されます。」と記載されており、また、「バーストスループットの範囲は、31 MiB/秒～500 MiB/秒 (上限) です。次に示すように、この上限には 2 TiB で到達します。」と記載されています。そのためst1 1TB x4で性能がリニアに上がらないのは、CVO側の何らかの内部の動作に起因している可能性を疑っていますが、新しいことがわかったら追記します。(CVOが4つのEBSを同時にストライプせずに1つずつ利用しているような挙動をしている場合、st1を2TBで割り当てることで500MiB/sの性能が出る可能性があります。)

#6. まとめと雑談

今回はあまり細かいチューニングを行わず、簡単なGUI操作で出来る範囲の設定変更でデータ移行性能を計測してみました。
移行元の単一ボリュームを1つだけ転送して測定しましたが、複数のボリュームを同時並列で移行すればさらに性能が期待できます。
今回はAWSにデータ移行しましたが、GCPのCVOへの移行はとても魅力的な選択肢となります。オンプレミスのデータストアをGCPのCVOに移行すれば、そのデータはGCVE(Google Cloud VMware Engine)からデータストアとして利用することができます。GCVEの内蔵のvSAN領域を使わなくても良くなり、オンプレミスの仮想基盤の引っ越し先としてGoogle Cloudは有力な選択肢となります。
移行ツールのXCPは汎用的に使えるツールで、移行元のストレージのメーカーやタイプも選びません。
この検証は以下の環境を利用しました。NetAppソリューションを検討されているお客様はどなたでもご利用できますので、ご興味のある方はNetApp担当営業、もしくはNetAppパートナーまでお問い合わせください。

#7. 関連情報

NetApp Cloud Volumes ONTAP紹介・設定動画
https://www.youtube.com/playlist?list=PL2CVZPvKXD1_eOPuQmZzspNG2tmuswrYd
NetApp XCPの紹介
https://www.slideshare.net/kanitani35/netapp-xcp
XCPを使ったオンプレ to オンプレデータ移行性能(rsyncとの比較)
https://www.storage-channel.jp/blog/nfs-small-file.html
AWS Direct Connectユーザーガイド
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/dc-ug.pdf
Direct Connect価格表
https://aws.amazon.com/jp/directconnect/pricing/
AWSと1GbpsでインターネットVPN接続してデータ移行性能を計測してみた (NetApp FAS -> CVO)
https://qiita.com/kan_itani/items/8dc4f0995833df54ab59