データ移行フレームワークとは何ですか?
データ移行フレームワークとは何ですか?
データ移行とは、あるストレージシステムまたはコンピューティング環境から別のストレージシステムまたはコンピューティング環境にデータを移動することです。どのデータ移行イニシアチブも、ネットワークリソース、データセキュリティ、時間、転送方法などの要素を考慮しながら、データを効率的に移動することを目的にしています。クラウドデータ移行は、クラウドへのデータ移行に明確に焦点をあてます。
このプロセスでは、単にデータを再配置するだけではなく、異なるストレージ環境間でデータを正確にマッピングする必要があります。いくつかの形をとることができます。たとえば、定期的にデータファイルをバッチでアップロードしたり、センサーからデータをストリーミングしたり、オンプレミスのデータストレージシステムから既存のアーカイブを一度だけ移行したりすることが必要な場合があります。
目標
各クラウドデータ移行プロジェクトには、最良の結果を決定するための明確なビジネスケースが必要です。ただし、ほとんどのデータ移行に共通する目標がいくつかあります。
- 例えば、アップタイムの増加、リモートファーストのインフラストラクチャ、またはシステム統合を求めるときの効率性の向上。
- ハードウェアのメンテナンス、サーバールームの運用、24 時間 365 日のオンサイトシステム管理者にかかるリソース支出の削減。
- 分析、人工知能の実施、エンタープライズアプリケーションの構築のための基盤データプラットフォーム。
その他の目標には、システムが本来の寿命を迎えても利用可能な状態を維持すること、すべてのインフラストラクチャを仮想化すること、既存のクラウドシステムとのデータ統合などがあげられます。
課題
クラウド移行を成功させるには、ファイルを転送するだけでは不十分です。次のことが必要です。
- 権限、アクセス制御、およびその他のメタデータが機能するように残ること。
- アップロード中も重要なデータに中断なくユーザーがアクセスできること。
- ネットワークが停止しても、データ整合性が維持されること
大量のデータを転送するには時間がかかり、多くの場合、かなりの手動操作が必要になります。移行に特化したツールに投資すると、移行が完了したときに埋没費用が発生する可能性があります。
したがって、クラウド移行には、運用上のオーバーヘッドを制限してコストを削減するための計画、スケジューリング、および適切なツールが必要です。そうしないと、データ移行プロセスが遅れたり、最初からやり直す必要が生じたりする可能性さえあります。
データ移行計画の主な考慮事項は何ですか?
データ移行に関与する経営陣とチームは、次の点を考慮する必要があります。
- データ移行にかかる時間
- 移行元と移行先の既存の非互換性
- 移行中のセキュリティ上の考慮事項
- 移行ツールまたはプロセスのコスト
- スケジュールに関する考慮事項
- 移行タイプ — バッチ、ストリーミング、一括
- ネットワークリソースへの影響。
計画のステップには次の項目が含まれます。
データソースを評価
データを移動する前に、現在のデータ構成を評価する必要があります。現在のデータ、ストレージ、アクセス方法のタイプが移行オプションの指針になります。
例えば、オンサイトの MySQL サーバーに保存されているリレーショナルデータベースは、比較的簡単なプロセスと 1 対 1 のデータベース管理システムで Amazon Relational Database Service (RDS) に移行できます。ただし、特にデジタルトランスフォーメーションの必須事項にソフトウェアの変更が含まれる場合は、ERP 用のオンプレミスのレガシーシステムの方が難しい場合があります。
クラウド移行に必要なすべてのデータソースの詳細を特定して書き留めます。例えば、次の項目です。
- データベース
- アプリケーションデータ
- ストレージ
- データモデル
- クラウド間
移行を設計
これには、既存のセキュリティ標準を満たす移行ツールの整理と構成が含まれます。データ移行操作の順序を決定し、事前にスケジュールすることも必要です。例えば、次の中から選択できます。
- 両方のシステム間でデータが同期されるまで、オブジェクトを自動的に非同期でコピーするためのライブレプリケーション。
- システム全体の状態を一括配信し、次に、現在の状態に追いついて適合するように小規模の転送で更新するスナップショット移行。
- 小規模なデータセットを 1 つずつ移行する段階的移行。
最後に移行の精度と品質を評価する方法も計画します。
主要な利害関係者に簡単に説明
移行は、ビジネス従業員、クライアント、パートナーの混乱を招く可能性があります。主要な利害関係者が、移行期間中のデータ移行プロセス、計画、タイムライン、およびアクセシビリティの中断について認識するようにします。移行後に管理者が構成方法を理解し、ユーザーがデータやクラウドサービスへのアクセス方法を理解できるようにするためのトレーニングも必要になる場合があります。
移行プロセス全体を通して頻繁な更新を計画し、スケジュールを設定して、ポジティブな印象を維持してください。
ソリューションを構築してテスト
データ移行にはそれぞれ異なる戦略が必要です。データ移行の種類によっては、少量のデータを一括で高速に転送する必要があるものもあれば、時間の経過とともに大量のデータが流れ込むものもあります。移行をどのように構築してテストするかは、関連する戦略とツールによって異なります。通常、移行プロセスが完全かつ正確であることを確認するために、新しいシステムの完全なテストが完了するまで、古いシステムを使い続けます。
データ移行戦略はどのようなものですか?
AWS クラウドデータ移行サービスを使用して AWS クラウドにデータをアップロードするには、さまざまな戦略と方法があります。
直接ネットワーク接続
直接ネットワーク接続は、ご使用のルーターとクラウドベースのルーター間のプライベートケーブル接続です。クラウドベースのルーターはクラウドプロバイダーのプライベートネットワークのエッジにあるため、さまざまなサービスに直接アクセスできます。
AWS Direct Connect では、組織と AWS 間のレイヤー 3 ネットワーク接続にイーサネット光ファイバーケーブルを使用して、ネットワークから AWS サービスにデータを安全に移動できます。AWS Direct Connect には、データ移行用の機器をセットアップできる拠点が世界中にあります。
使用開始のための手順
ステップ 1 — Direct Connect の拠点を選択する
AWS Direct Connect の拠点を選択し、必要な接続を決定し、ポートサイズを選択します。帯域幅や冗長性を上げるために、複数のポートを使用できます。
ステップ 2 — 接続タイプを選択する
専用接続かホスト接続かを決定します。専用接続は複数の仮想インターフェースによる排他的アクセスを提供し、ホスト接続はクロスコネクトを共有して単一の仮想インターフェースを提供します。
ステップ 3 — 仮想インターフェースのセットアップ
接続を介して 1 つ以上の論理仮想インターフェイス (VIF) を構成します。トランジット VIF は AWS Transit Gateway に接続し、パブリック VIF はパブリック IP を介して AWS パブリックサービスにアクセスし、プライベート VIF はプライベート IP を使用して Amazon VPC に接続します。
デバイスベースのデータ転送
大規模なデータ移行では、データをデバイスに移動し、それをデータセンターに物理的に転送する方が効率的です。AWS Snowball は、データをクラウドに安全にアップロードするために使用できる安全で頑丈なデバイスを提供するサービスです。手順は次のとおりです。
1. AWS がリクエストに応じて Snowball デバイスをお客様の場所に配送します。
2. デバイスをネットワークに接続し、AWS Snowball クライアントまたは AWS OpsHub を使用してデバイスのロックを解除して構成します。
3. データをデバイスにコピーします。組み込みの暗号化機能により、転送中のセキュリティが確保されます。
4. 前払いの配送ラベルを使用してデバイスを AWS に返送します。
5. 到着すると、AWS は指定の S3 バケットにデータを自動的に転送し、Snowball デバイスを安全に消去します。
6. 処理が完了すると、通知が届きます。
センサーデータストリームのアップロード
IoT、産業用デバイス、センサーネットワークから収集されたストリーミングデータは、オンサイトでキャプチャしてバッチ処理する代わりに、リアルタイムでクラウドに転送できます。Amazon Data Firehose では、データソースを使用してストリームを設定し、必要に応じてデータを変換し、AWS のさまざまな宛先ストレージサービスに格納できます。
手順は次のとおりです。
ステップ 1 — Firehose ストリームを作成する
Firehose ストリームは Amazon Data Firehose のコアエンティティです。AWS コンソールから作成し、データを直接受信するか、既存の Amazon Kinesis データストリームからデータを受信するように構成できます。
ステップ 2 — Firehose ストリームにデータを送信する
最大 1,000 KB のレコードが、データストリームプロデューサーから Firehose ストリームに送信されます。データプロデューサーには、アプリケーション、サーバー、またはその他の AWS サービスを使用できます。
ステップ 3 — バッファリングとデータ処理を構成する
Amazon Data Firehose では、宛先にデータを配信する前に受信データがバッファされます。バッファサイズ (MB 単位) とバッファ間隔 (秒単位) を構成できます。
ステップ4 — 宛先を選択し、データフローを把握する
Amazon Data Firehose はストリーミングデータをさまざまな宛先に配信します
- Amazon S3 ではデータは S3 バケットに格納され、変換されたデータがオプションでバックアップされます。
- Amazon Redshift ではまず S3 バケットに配信され、次に COPY コマンドを使用して Redshift に読み込まれます。
- Amazon OpenSearch Service では、オプションで S3 へのバックアップが行われます。
データベースの移行
データベースの移行とは、リレーショナルデータベース、データウェアハウス、NoSQL データベース、およびデータベース形式のその他のタイプのデータストアを移行することを指します。移行サービスはデータベースタイプとスキーマを検出し、同じインフラストラクチャに直接コピーするか、新しいターゲットエンジンに変換します。
AWS Database Migration Service は、自動化されたデータ移行プロセスを使用して、データベースと分析のワークロードを検出、評価し、AWS に変換して移行します。可用性が高く、ダウンタイムも最小限に抑えられます。
データ移行のケースが上記のリストにない場合は、次の方法も試してみてください。
- AWS Transfer Family は SFTP のような安全な一連のファイル転送サービスです
- AWS Storage Gateway は一連のオンサイトとクラウドのハイブリッドストレージソリューションです
- AWS Glue はさまざまなソースのデータを検出、準備、移動、統合するための一連のサービスです
データ移行のベストプラクティスはどのようなものですか?
クラウドデータ移行のベストプラクティスをいくつか以下に示します。
常にデータをバックアップしておく
データを移動する場合でも、単に日常業務を行う場合でも、常にデータのバックアップを用意してください。クラウド構成が完全にテストされ、独自のバックアップを使用して期待どおりに動作することを確認するまでは、元のデータを削除しないでください。
すべての依存関係がマッピングされ、移行されていることを確認する
多くの場合、データは他のさまざまな依存関係と結合されていて、それらがないと正しく動作しません。移行をスムーズに行うには、すべての依存関係が元のデータとともにマッピングおよび移行されていることを確認してください。ユーザー権限とアクセス制御は移行前と同じレベルに設定し、可能であればセキュリティを強化するために再評価する必要があります。
セキュリティとコンプライアンスの義務と構成を再確認してください
移行前、移行中、移行後に、セキュリティとコンプライアンスのポリシーと手順を調べて、移行作業に使用する適切なプロセスと統制を決定する必要があります。
古い機器の廃止計画を含める
古いハードウェアには、ファイルやディスクスペースが削除されても、回復可能なデータが残っている場合があります。すべてのデータを確実に削除するには、例えば NIST 800-88 の媒体のデータ抹消処理に関するガイドラインに従うなどして、古いデバイスを安全に廃棄してください。
AWS はデータ移行のニーズをどのようにサポートできますか?
AWS では、データのインポートとエクスポートを簡単、安全、かつ費用対効果の高い方法で行うことができるように、データ移行ツールとサービスの一式を開発しました。データ移行プロセス全体の各段階でヘルプを利用できます。AWS クラウド移行にアクセスして AWS で移行とモダナイズを実行するか、無料の AWS Optimization and Licensing Assessment を今すぐリクエストしてください。