クラウドデータ移行における6つの隠れたボトルネック

ペタバイト単位のデータをクラウドに移動するのは困難な作業です。クラウドでアクセスするとアプリケーションの動作が異なり、コスト構造も異なり、すべてのデータを移動するのに時間がかかることはおそらくご存知でしょう。

企業ユーザーは、ネットワーク速度が頭痛の種であると考え、支援を求めています。しかし、企業がこの問題を克服するのを支援する過程で、専門家は、他の多くの要因が見落とされ、企業のクラウド移行に影響を及ぼす可能性があることを発見しました。

[[227000]]

データの収集、整理、フォーマット、検証は、移行よりも企業にとって大きな課題となる可能性があります。時間とコストのかかる問題を回避するために、クラウド移行計画フェーズで考慮すべき一般的な要素をいくつか示します。

クラウド移行のボトルネックその1: データストレージ

クラウド移行で最もよく見られる間違いは、データの使用方法を考慮せずにデータをクラウド ストレージに移動することです。典型的な考え方は、「オブジェクト ストレージは安価なので、ドキュメントとデータベースをクラウドに保存したい」というものです。しかし、ファイル、オブジェクト、データベースの動作はそれぞれ大きく異なるため、データを間違った場所に置くと、企業のクラウド計画に支障をきたす可能性があります。

ファイルはパスの階層、つまりディレクトリ ツリーで構成されます。各ファイルは、最小限の遅延で高速（データの流れが始まるときの 1 秒あたりのビット数）ですぐにアクセスできます。個々のファイルを簡単に移動、名前変更、変更できます。企業には、多数の小さなファイル、少数の大きなファイル、またはさまざまなサイズとデータ タイプの組み合わせが存在する場合があります。従来のアプリケーションは、特別なクラウド認識を必要とせずに、ローカルと同じようにクラウド内のファイルにアクセスできます。

これらすべての特性により、ファイルベースのストレージは最も高価なオプションになりますが、クラウドにファイルを保存することには他にも欠点があります。より高いパフォーマンスを実現するために、Amazon EBS などのほとんどのクラウドベースのファイルシステムには、一度に 1 つのクラウドベースの VM からしかアクセスできません。つまり、そのデータを必要とするすべてのアプリケーションを 1 つのクラウド VM で実行する必要があります。 Azure Files などの複数の仮想マシンを提供するには、ストレージに SMB などの NAS (ネットワーク接続ストレージ) プロトコルを使用する必要がありますが、これによりパフォーマンスが大幅に制限される可能性があります。ファイル システムは高速で柔軟性があり、互換性がありますが、高価で、クラウドで実行されるアプリケーションにのみ適しており、拡張性も高くありません。

オブジェクトはファイルではありません。忘れやすいので覚えておいてください。オブジェクトは、巨大なディレクトリのようなフラットな名前空間に存在します。レイテンシは高く、時には数百または数千ミリ秒に達します。また、スループットは低く、巧妙なトリックを使用しない限り、通常は 150 メガビット/秒程度です。オブジェクトへのアクセスに関するほとんどの作業には、マルチパートアップロード、バイト範囲アクセス、キー名の最適化などの巧妙なトリックが含まれます。オブジェクトはクラウドの内外から読み取ることができますが、従来のアプリケーションではパフォーマンスの遅い回避策が必要になります。オブジェクト ストレージにアクセスするためのほとんどのインターフェイスでは、オブジェクトがファイルのように見えます。キー名はプレフィックスによってフィルター処理されてフォルダーのように見え、カスタム メタデータがオブジェクトに添付されてファイル メタデータとして表示されます。また、一部のシステム (仮想マシン ファイル システム上の FUSE キャッシュ オブジェクトなど) では、従来のアプリケーションを介したアクセスが可能になります。しかし、このような回避策は脆弱であり、パフォーマンスも低くなります。クラウド ストレージは安価で、スケーラブルで、クラウド ネイティブですが、速度が遅く、アクセスが困難です。

データベースは独自の複雑な構造を持ち、SQL などのクエリ言語を通じてアクセスされます。従来のデータベースはファイル ストレージによってサポートされますが、クエリを処理するにはリアルタイムのデータベース プロセスが必要です。データベース ファイルとアプリケーションを仮想マシンにコピーするか、データをクラウド ホスト データベース サービスに移行することで、クラウドに移行できます。ただし、データベース ファイルをオブジェクト ストレージにコピーするのは、オフライン バックアップとしてのみ行うと便利です。データベースはクラウドホスト型サービスの一部として拡張できますが、データベースに依存するアプリケーションとプロセスが完全に互換性があり、クラウドネイティブであることを確認することが重要です。データベース ストレージは高度に専門化され、専用化されています。

オブジェクト ストレージの明らかなコスト削減とファイルおよびデータベースの機能のバランスをとるには、必要な機能を慎重に検討する必要があります。たとえば、何千もの小さなファイルを保存して配布する場合は、各ファイルを個別のオブジェクトとして保存するのではなく、ZIP ファイルとして保存し、それを単一のオブジェクトとして保存します。ストレージの選択を誤ると、依存関係が複雑になり、後で変更するのが困難でコストがかかる可能性があります。

クラウド移行のボトルネック #2: データ準備

データをクラウドに移動することは、指定されたストレージ タイプにコピーするほど簡単ではありません。企業は何かを複製する前に多くの準備を行う必要があり、予算を慎重に計画する必要があります。このステップは概念実証プロジェクトでは見落とされることが多く、後でコストの超過につながる可能性があります。

不要なデータを除外することで、多くの時間とストレージコストを節約できます。たとえば、データセットには、クラウド コンピューティング ワークフローに含める必要のないバックアップ ファイル、以前のバージョン、または一時ファイルが含まれている場合があります。おそらく、フィルタリングの最も重要な部分は、どのデータを最初に移動する必要があるかを優先順位付けすることです。アクティブに使用されているデータは、移行プロセス全体が完了するまでに数週間、数か月、または数年かかる間、同期されていない状態を許容しません。ここで重要なのは、どのデータをいつ送信するかを自動的に選択する方法を考え出し、実行されていないすべてのことを注意深く記録することです。

クラウド コンピューティング ワークフローによっては、オンプレミス アプリケーションとは異なる方法でデータをフォーマットしたり整理したりする必要がある場合があります。たとえば、ワークフローでは何千もの小さな Word または PDF ドキュメントをコンパイルして ZIP ファイルにパッケージ化する必要がある場合があり、メディア ワークフローではトランスコードとメタデータのパッケージ化が必要な場合があり、バイオインフォマティクス ワークフローではテラバイト単位のゲノム データを選択してセグメント化する必要がある場合があります。この再フォーマットは非常に時間がかかり、面倒なプロセスになる可能性があります。多くの実験、多くの一時ストレージ、および多くの例外処理が必要になる可能性があります。クラウド環境への再フォーマットを先延ばしにするのは簡単な場合もありますが、これでは問題が解決するわけではなく、ビジネスで使用するすべてのリソースの環境に問題が移動するだけであることに注意してください。

ストレージとフォーマットの問題の一部には、圧縮とアーカイブに関する決定が含まれる場合があります。たとえば、何百万もの小さなテキスト ファイルをクラウドに送信する前に圧縮するのは理にかなっています。しかし、数ギガバイトのマルチメディア ファイルは圧縮しません。データをアーカイブして圧縮すると、データの転送と保存が容易になりますが、これらのアーカイブをパックおよび解凍するために必要な時間とストレージ スペースを考慮してください。

クラウド移行のボトルネック #3: 情報検証

整合性チェックは最も重要なステップですが、最もエラーが発生しやすいステップでもあります。一般的に、物理メディア経由かネットワーク経由かを問わず、データ転送中に破損が発生すると想定されており、転送前後にチェックサムを実行することで破損を検出できます。チェックサムはプロセスの重要な部分ですが、実際には、失われたり破損したりする可能性が最も高いデータを準備してインポートしています。

データがフォーマットやアプリケーション間で移行する場合、バイトが同一であっても、意味や機能が失われる可能性があります。ソフトウェア バージョン間の単純な非互換性により、ペタバイト単位の「正しい」データが役に立たなくなる可能性があります。データが正しく利用可能であることを検証することは、スケーラブルなプロセスでは困難な作業になる可能性があります。最悪の場合、「問題なさそう」という労働集約的で不正確な手作業のプロセスに陥る可能性があります。しかし、たとえ検証できたとしても、検証しないよりはましです。最も重要なことは、レガシー システムが廃止される前に、企業がその問題を特定できるようにすることです。

クラウド移行のボトルネック #4: 転送マーシャリング

単一のシステムをクラウドに移行する場合、準備したデータを物理メディアにコピーしたり、グローバル インターネット経由でプッシュしたりするのは比較的簡単です。しかし、このプロセスは、特に物理メディアの場合、拡張が困難な場合があります。概念実証では「簡単」に思えることも、さまざまなシステムが関与すると「悪夢」に変わる可能性があります。

各マシンにメディアデバイス (AWS Snowball など) を接続する必要があります。これには、1 つ以上のデータ センター間で機器を移動し、接続を行い、ドライバーを更新してソフトウェアをインストールすることが含まれる場合があります。ローカル ネットワーク経由で接続すると物理的な移動が不要になりますが、ソフトウェアのセットアップは依然として難しく、コピー速度はグローバル インターネット経由で直接アップロードする場合よりも大幅に低下する可能性があります。各コンピュータからインターネット経由でデータを直接転送すると、特にデータがすでに準備されている場合は、多くの手順が節約されます。

データの準備にコピー、エクスポート、再フォーマット、アーカイブが含まれる場合、ローカル ストレージがボトルネックになる可能性があります。準備されたデータをステージングするために専用のストレージを設定する必要がある場合があります。これには、多くのシステムを並行して準備できるという利点があり、出荷可能なメディアとデータ転送ソフトウェアの接点が 1 つのシステムに削減されます。

クラウド移行のボトルネック#5: データ転送

ネットワーク伝送とメディア伝送を比較する場合、送信時間のみに注目しがちです。たとえば、80TB の AWS Snowball デバイスは宅配便で送られる可能性があり、その結果、見かけ上のデータ レートが非常に速くなります。しかし、これは、デバイスを取得し、構成してロードし、返却の準備をして、クラウド プロバイダーがバックエンドでデータを複製できるようにするために必要な時間を無視しています。そして、定期的にそうする顧客は、このような処理時間（デバイスの注文からクラウドでデータが利用可能になるまで）は一般的であると報告しています。これにより、デバイスが運ぶ実際のデータ転送速度は 300 メガビット/秒に低下しますが、デバイスが完全に装着されていない場合は、この速度が大幅に低下する可能性があります。

ネットワークの伝送速度も多くの要因に依存しますが、最も重要なのはローカル アップリンクです。適切なデータ準備により企業が送信する必要のあるデータの量を削減できますが、物理ビット レートよりも高速にデータを送信することはできません。クラウド ベンダーがオブジェクト ストレージにデフォルトで使用するプロトコルを含む従来のプロトコルでは、長距離のグローバル インターネット パスでの速度と信頼性に問題があり、そのビット レートの達成が困難になる可能性があります。 CloudDat などの高速化ソフトウェアを使用したギガビット インターネット接続では、最大 900 メガビット/秒を生成でき、これは AWS Snowball のネット スループットの 3 倍です。

物理トランスポートとネットワーク トランスポートの最大の違いは、概念実証中に最も見落とされがちな問題の 1 つでもあります。物理的な出荷の場合、デバイスにロードされた最初のバイトは、最後のバイトが完全にコピーされるまで待機してから出荷する必要があります。つまり、デバイスへの読み込みに数週間かかる場合、一部のデータはクラウドに到達するまでに数週間古くなることになります。データ セットがペタバイト レベルに達し、全体的な実際の転送速度が速くなる場合でも、移行プロセス中に優先データの流れを維持できれば、重要な資産のネットワーク転送にメリットがもたらされる可能性があります。データ準備のフィルタリングと最適化のフェーズでの慎重な計画が不可欠であり、ハイブリッド アプローチが可能になる場合があります。

クラウド コンピューティング プロバイダーにデータをインポートするだけでは、データ転送手順は終了しない場合があります。複数のリージョンまたはプロバイダーに複製する必要がある場合は、そこに到達する方法を慎重に計画してください。インターネット経由でのアップロードは無料ですが、たとえば AWS では地域間のデータ転送に 1 ギガバイトあたり最大 2 セント、その他のクラウド コンピューティング プロバイダーでは 1 ギガバイトあたり 9 セントかかります。どちらのアプローチも帯域幅の制限に直面しますが、CloudDat などの転送高速化ソフトウェアの恩恵を受ける可能性があります。

クラウド移行のボトルネック #6: クラウドの拡張

データがクラウド内の宛先に到達しても、移行プロセスはまだ半分しか完了していません。まずチェックサムがチェックされ、到着したバイトが送信されたバイトと一致することが確認されます。これはおそらく人々が考えるよりも複雑です。ファイル ストレージでは、アップロードされたばかりのデータの破損を隠すことができるキャッシュ レイヤーが使用されます。この破損は非常にまれですが、すべてのキャッシュをクリアしてファイルを再度読み取るまで、チェックサムを確実に確認することはできません。インスタンスを再起動したり、ストレージをアンマウントしたりしても、キャッシュはクリアされます。

オブジェクト ストレージ チェックサムを検証するには、計算のために各オブジェクトをインスタンスに読み出す必要があります。一般に信じられていることとは反対に、オブジェクトの「電子タグ」はチェックサムとしては役に立ちません。マルチパート技術を使用してアップロードされたオブジェクトは、読み取ることによってのみ検証できます。

送信されたデータが検証されたら、企業のクラウドベースのアプリケーションやサービスで使用できるようになる前に、さらにデータを抽出して再フォーマットし、配布する必要がある場合があります。これは、敷地内で行われる準備と発送とはほぼ逆のことです。

データを拡張する最後のステップは、データが正しくて有用であることを確認することです。これは、上で説明した情報検証プログラムの別の側面であり、それが実際に完了したかどうかを知る唯一の方法です。

クラウド移行はデータよりもプロセスが重要です。一見単純なファイル配布タスクであっても、結果として得られるクラウド コンピューティング インフラストラクチャが目的のワークフローと一致するようにするには、複雑な移行手順が必要です。コスト削減からスケーラビリティまで、クラウド コンピューティング テクノロジーを取り巻く大規模な宣伝は理にかなっています。しかし、それらの利益を達成するために必要なツールと方法を決定するには、慎重な計画と困難の予測が不可欠です。