クラウド移行への道: Storage Transfer Service を使用してオンプレミスから Google Cloud に移行するためのベスト プラクティス

※この投稿は米国時間 2021 年 8 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

過去数年にわたり、組織において、オンプレミスからクラウドへのデータとアプリケーションの移行が進められています。その理由は、アプリケーションのモダナイゼーションやコンテンツ配信、アーカイブなど、さまざまです。特に、メディアやエンターテイメントなどの分野で移行の機運が高まっています。これらの分野のお客様は、過去に作成した価値あるコンテンツの収益化と保存の方法を再検討しており、Google Cloud のさまざまな分析ソリューションや AI ソリューションに着目していることも多くあります。

こうしたお客様の多くは、非構造化データをオンプレミスのアプライアンスから Google の Cloud Storage に移行することに関心を持っています。この 1 年間にわたって、数十ペタバイト以上のオンプレミスのファイルデータを Google の柔軟で安全なオブジェクト ストレージに移行する、大規模な移行の増加が確認されています。

Telecom Italia / TIM Brasil のようなお客様の場合、こうしたトランスフォーメーションを実現するためにオンプレミスのファイル システムから拡張可能な低コストの Cloud Storage にネットワーク経由でデータを移行する際に、Google のフルマネージド Storage Transfer Service が重要な役割を果たしました。

Telecom Italia / TIM Brasil の CIO である Auana Mattar 氏は次のように述べています。「Storage Transfer Service のおかげで、ペタバイト規模のデータをオンプレミスのファイル システムから Google Cloud に高パフォーマンスかつフルマネージドの方法で移行できました転送パイプラインを設定するには、いくつかのテストを実行して、自社のオンプレミス環境における理想的なエージェント数やネットワーク設定を割り出す必要がありましたが、初期設定の完了後はシームレスにデータが転送されました。サービスのパフォーマンスは 20 Gbps の Partner Interconnect リンクの上限一杯に達しました。」

大規模なクラウド移行によって問題が生じる可能性がありますが、数ペタバイトのデータ転送をできる限り円滑に行えるようにお客様が取れる措置はいくつかあります。これまで、Google では、クラウド移行を初めて行う方向けの一般的なアーキテクチャ ガイダンスを紹介してきました。また、移行における選択肢をお探しのお客様には、完全にオフラインの Transfer Appliance をはじめ、オンプレミスのファイルデータをクラウドに移行するパスをいくつか用意しています。

このブログ投稿では、Storage Transfer Service を使用してデータをオンプレミスからクラウドに移行する方法に焦点を当てた最新の見解を紹介します。具体的には、Storage Transfer Service を使用してオンプレミスのファイル システムから Cloud Storage に大量のデータを移行する際に考慮すべき 3 つの要素について見ていきます。

ソースファイルおよびファイル システムの把握

オンプレミスのファイル システムからデータを移行する場合は、ソースファイルと移行元のファイル システムが転送のパフォーマンスに与え得る影響を認識しておく必要があります。

Cloud Storage へのコピーを作成すると、メタデータ転送、チェックサム作成、暗号化などの関連操作に伴って、ある程度のオーバーヘッドが都度発生します。つまり、一定の容量のストレージでは、非常に小さいファイルを大量に転送する方が時間がかかります。経験則では、Storage Transfer Service は、16 MB 以上のファイルを移行する際に最もパフォーマンスが高くなります。

小さいファイルが大量にある場合は、tar などのツールで 1 つにまとめて単一のオブジェクトとしてアップロードすることもできます。これによって転送のパフォーマンスは向上しますが、Cloud Storage でのそうしたファイルの使用が制限されます。これは、Google Cloud に転送されたデータの管理やアクセスが日常的に行われることがないアーカイブ ストレージなどのユースケースに最適なオプションと考えられます。Google の Nearline、Coldline、Archive の各アーカイブ層は、アーカイブされたデータを検索する必要がある場合に優れたパフォーマンスを提供します。

特に、移行元のファイル システムで読み取りスループットが制限されている場合は、転送のパフォーマンスが低下する可能性があります。読み取りスループットは、Fio のようなツールを使用してテストできます。Fio で一連の 1 MB の順次読み取り操作を実行して、レポートを生成するコマンドを以下に示します。

その後、Fio はレポートを生成します。「bw」というラベルが付いた最後の行は、すべてのスレッドの集約帯域幅の合計を表し、読み取りスループットのプロキシとして使用できます。一般的に、必要なアップロード スループットまたは速度の 1.5 倍の読み取りスループット（「bw」）を確保する必要があります（読み取りスループットを簡単に向上させる方法の一つは、ファイル システム自体で最大スループットに制限を設けないようにすることです）。

Storage Transfer Service リソースの最適化

Storage Transfer Service 内には、大規模なワークロードに最適なパフォーマンスを確保するために事前に調整できる設定がいくつかあります。

まず、ソースデータの転送エージェントの数が適切かどうか確認する必要があります。1 GB を超える転送ジョブの場合は、別々の VM で、それぞれ少なくとも 4 vCPU と 8 GB の RAM が割り当てられたエージェントを 3 つ以上使用して開始することをおすすめします。このアーキテクチャによって、パフォーマンスの高いデータ転送の基盤が提供されるだけでなく、1 台のエージェント マシンが使用できなくなった場合でも、転送がフォールト トレラントであることが保証されます。

Google Cloud は、特定の Google Cloud プロジェクトに対して最大 100 個の同時エージェントをサポートします。ワークロードをサポートするエージェントの適切な数を特定するには、まず大規模な転送を開始して各エージェントを追加し、3 分間待ってからスループットが安定していることを確認します。

一般的に、各エージェントは最大 10 個のエージェントに対して約 1 Gbps のスループットを実現でき、その時点で非常に大きいネットワーク帯域幅に対してエージェントの追加が必要になる場合があります。たとえば、20 Gbps の専用ネットワークを持つあるお客様は、1 回の大規模な移行で一度に最大 30 個のエージェントを実行しました。こうした数字から 1 つのエンタープライズ データセンターで何が必要とされたかが読み取れます。すべての環境で、Cloud Monitoring を使用してスループットをテスト、モニタリングし、転送の目的に適った構成を確保することが重要です。

エージェントのインストール場所とインストール方法も最適化対象です。前述のとおり、エージェントは別々の VM にインストールされ、各ホストマシンはエージェントごとに少なくとも 4 つの vCPU と 8 GB のメモリを使用する必要があります。これは出発点で、長時間かつ大規模な転送を行う場合は、追加の CPU とメモリが必要になる可能性があります。こうした長時間ジョブについては、最適なパフォーマンスを確保するために、CPU 使用率と未使用メモリを注意深くモニタリングすることをおすすめします。CPU の使用率が 70% を超える場合は、さらに CPU を追加してプロビジョニングを行う必要があります。同様に、エージェントの未使用メモリが 1 GB 未満の場合は、追加のメモリのプロビジョニングを準備する必要があります。

大規模なデータ転送のためのネットワークの準備

3 番目にして最後の検討要素はネットワーク接続です。ネットワーク接続を、移行元のファイル システムと Google Cloud バケット間の帯域幅に限定するのは簡単ですが、ネットワークにはさらに容易に構成できるコンポーネントが他に 2 つあります。1 つ目はオンプレミス エージェントから WAN へのネットワーク インターフェースで、2 つ目はオンプレミスのファイル システムへのエージェントの接続です。

最初のコンポーネント（オンプレミス エージェントから WAN へのネットワーク インターフェース）の場合、一般的には、これがボトルネックにならないようにすることが推奨されます。具体的には、このインターフェースが、ファイル システムから読み取るために必要な帯域幅に、Google Cloud に書き込むためのアップロード帯域幅を加えたもの以上であることを確認する必要があります。つまり、オンプレミスから Google Cloud に 10 Gbps のデータを移行する場合、オンプレミス エージェントと WAN の間で 20 Gbps の帯域幅が必要になります。10 Gbps はネットワークに接続されたファイル システムから読み取るためで、残りの 10 Gbps は Google Cloud に転送して書き込むためです。

オンプレミスのファイル システムとネットワークには、さまざまな種類があります。2 つ目のコンポーネント（エージェントがオンプレミスのファイル システムに接続する方法）の場合、レイテンシを念頭に置いて定期的にテストすることが一般的なルールです。レイテンシが非常に低いネットワークに接続されたファイル システムにアクセスできるマシンで、エージェントが実行されるようにするのが不可欠です。

最後に、転送のパフォーマンスを最大化しようとしている場合は、転送速度に影響を与える可能性がある、オンプレミスのファイル システムと Google Cloud 間の帯域幅制限が回避されるようにネットワークを構成していることを確認します。Storage Transfer Service を使用すると、転送で使用される帯域幅を制限し、他の本番環境アプリケーションへの影響を簡単に最小化できます。Cloud Storage へのアップロードに利用できるネットワーク帯域幅を測定する場合は、lperf3、tcpdump、gsutil などのツールを使用することを検討してください。

特に gsutil は有用であると思われるため、少し詳しく紹介しておきます。gsutil は Python ツールで、エージェントと Cloud Storage API の接続確認といった、さまざまなオブジェクト ストレージ管理タスクを Google Cloud で実行する際に役に立ちます。Google Cloud SDK 経由でインストールすることも、個別にインストールすることもできます。この場合、gsutil が Storage Transfer Service エージェントと同じオンプレミス VM で使用できることも確認する必要があります。

gsutil を使用して Google Cloud への接続をテストする場合は、次のコマンドを使用します。

CP は、オンプレミスからクラウドにデータをコピーできるコピーコマンドです。この場合、gsutil はテスト ドキュメント test.txt をコピーして、Google Cloud APIs と接続していることを確認します。このコマンドを実行する前に、テスト ドキュメントを作成する必要があります。

テストを 2 回、転送を 1 回

すべての要素について等しく言えることは、テストはパフォーマンスを把握するのに役立つということです。オンプレミスのファイル システムから Google Cloud に大規模なデータ転送を行うというのは、多くのお客様にとって例外的な出来事です。エンタープライズ IT における他の例外的な取り組みと同様に、各関係者（ネットワーク管理者からファイル システムやストレージの専門家、クラウド アーキテクトに至るまで）がそれぞれの専門分野に関連するテストを複数回行えるようにし、作業をスムーズに行えることを確認しておくのが賢明です。

データ転送の前にテストを微調整する際には、ネットワーク帯域幅を増やすためのオプション、SMB ファイル システムからの転送をオーケストレーションするためのオプション、あるいはオブジェクト ストレージのコストを節約するための適切な選択方法を、詳しく確認することをおすすめします。また、今後数か月間にわたって、Google の転送サービスを利用したお客様の事例をブログで詳しくご紹介する予定です。エージェントの高度な設定 | Cloud Storage Transfer Service のドキュメント

Storage Transfer Service の詳細と開始方法については、Google のドキュメントをご覧ください。または、Google Cloud Console から開始してください。

-プロダクト マネージャー Ajitesh Abhishek

-ストレージ担当アウトバウンド プロダクト マネージャー Chris Schilling