Category: Migration & Transfer Services

このブログはVaibhav Singh (Cloud Infrastructure Architect with AWS ProServe India)によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。   オンプレミスからクラウドへの移行では、さまざまなお客様がそれぞれに異なった環境を持っていて実現方法も異なります。あるお客様はオンプレミスで稼働しているワークロードの規模が小さかったり、あるお客様は複数のデータセンターに複数のストレージアレイを設置していたり、さらに複雑で膨大なセットアップを行っているお客様もいるかと思います。クラウドに移行する場合、現在のデータストレージ環境を調査することの難しさや、どのように始めればよいか戸惑うのは当然のことでしょう。 AWSプロフェッショナルサービスは、ダウンタイムを最小限に抑えながら、お客様のクラウドへの移行をサポートし、最も効率的で効果のある方法でクラウドソリューションを最大限に活用できるようにします。AWSは、アプリケーションやデータベース、バックアップやディザスタリカバリ（DR）のスタックを再設計することなく、ビジネスに最適な方法でデータをクラウドに移行することを支援します。 この記事では、10,000人以上の従業員を抱えるグローバル金融サービス企業のお客様が、AWSプロフェッショナルサービスによる迅速かつ安全なオンライン移行によって、どのようにしてクラウドへの移行を加速させたかを紹介します。このケースでは、お客様はAWS DataSyncとAmazon FSx for Windows File Server（Amazon FSx）を使用して、100TB以上のファイルストレージを迅速かつシームレスに移行することができました。

VMware Cloud on AWSはVMwareのSoftware-Defined Data Center (SDDC)技術をAWSのグローバルインフラストラクチャ上で提供するためVMwareとAWSが共同開発したソリューションです。 様々なストレージ要件のワークロードが存在する場合、利用可能なストレージオプションの種類を把握し、異なる条件下でそれらをどう使っていくことが最適であるかを理解することが重要です。 VMware Cloud on AWSは複数のストレージサービスと統合されており、VMware vSphereワークロードに対して選択肢と柔軟性を提供しています。しかしながら各サービスは特定のシナリオに最適化されており、ワークロード全体に対して最適な単一のアプローチというものはありません。正しいサービスを選択するには、まずVMware vSphereワークロードのストレージ要件やパフォーマンスの統計データを理解しなければいけません。それを踏まえた上で、お客様のワークロードに適したコスト、可用性、パフォーマンス要件を満たすストレージを計画、実装することができます。

先日 (2021/03/16) 開催しました AWS Black Belt Online Seminar「AWS DataSync」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20210316 AWS Black Belt Online Seminar AWS DataSync AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. DataSync を使って AWS 間でデータ転送する場合、そのデータは AWS の専用ネットワークのみを通るのでしょうか? A. はい、AWS バックボーンネットワークを使用して転送されます。 Q. クロスアカウントで S3 から S3 には転送できないのでしょうか？(クロスアカウントの表になかったので気になりました) A. はい、現在 S3 から S3 へのクロスアカウント転送は対応しておりません。 Q. ファイル連携タスクはスケジュールベースのようですが、ファイルが新規に置かれたら、のようなイベントベースの連携設定は可能ですか？ A. 御指摘有難う御座います。有ると便利な機能ですが現在対応しておりません。貴重なフィードバック有難う御座います。 Q. EFS と S3 間での同期を想定していますが、ファイルの整合性チェックに失敗した場合、リトライは可能でしょうか？ A. タスクを再実行する事により、再度整合性を保つ事は可能です。 Q. […]

アメリカ海軍（U.S. Navy）が、”最大”の基幹システム(“U.S. Navy’s largest SAP ERP system”)をAWSへ移行した事例が公開されました。今回のブログでは、AWSジャパン・パブリックセクターより、この事例から読み取られるべきインパクトについて、ご紹介します。

「Amazon FSx」は、他サードパーティ製ファイルシステムのような互換性と同時に多様な用途に堪える様々な機能を提供します。Amazon FSxを活用することによって、ハードウェアの調達・ソフトウェアの設定・パッチ適用・バックアップ等、時間と労力のかかる従来の運用作業を自動化することができます。この記事ではActive Directoryドメイン移行のシナリオにおいて、オンプレミスのファイル共有をAWS DataSyncを用いてどのようにAmazon FSxに移行できるかを説明していきたいと思います。多くのお客様がオンプレミスのADからAWS Managed Microsoft Active Directoryへの移行と同時に、ファイルサーバーもAmazon FSxに移行しています。

AWS Transfer Family は、完全マネージド型の SFTP (Secure File Transfer Protocol)、TLS 経由のファイル転送プロトコル (FTP)、および Amazon Simple Storage Service (S3) の FTP サポートを提供し、ファイル転送ワークフローをシームレスに AWS に移行します。 AWS Transfer Family は Amazon S3 に加えて、Amazon Elastic File System (EFS) ファイルシステムへのファイル転送もサポートするようになりました。この機能により、ビジネスパートナーは Amazon EFS ファイルシステムに格納されているファイルへのアクセスを簡単かつ安全に提供できます。SFTP、FTPS、または FTP プロトコルを使用する既存のワークフローを維持しながら、転送されたファイルを完全に管理されたファイルシステムに格納し、運用上の負担を軽減できます。

先日 (2020/08/11) 開催しました AWS Black Belt Online Seminar「CloudEndure」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200811 AWS Black Belt Online Seminar CloudEndure AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. クラッシュコンシステントの観点によってデータベースは DB ネイティブ（例えば Oracle DataGuard など）でレプリケーションをしたほうが良いかどうかの判断ということでしょうか？https://aws.amazon.com/jp/cloudendure-disaster-recovery/features/ A. CloudEndure は、ストレージの変更ブロックをレプリケーションして、データとしての一貫性を保持している動作になるので、crash consistent です。 Q. Disaster Recovery に関して、東京リージョンと大阪ローカルリージョンとの間でも実施可能でしょうか？ A. 可能です。大阪ローカルリージョンを利用する際は、利用申請が必要です。また、リザーブドインスタンスでの利用となります。 Q. TestMode と CutoverMode でターゲットサーバに差異はあるのでしょうか？ A. 差異はありません。2 つの Mode を用意している理由は、本番移行前に確実にテストを実施頂き、CloudEndure のコンソール上で Tested となっている対象サーバを本番移行頂きたいためです。 — 今後の AWS Webinar | […]

  AWS DataSync は、セルフマネージドのオブジェクトストレージとの間の転送をサポートするようになりました! 🎉 この新機能により、オンプレミスのオブジェクトストレージと AWS Cloud Storage との間で大量のデータを簡単に自動コピーできるようになります。 AWS DataSync について AWS DataSync を使用したことがない方は、このサービスをどのように活用するかについてご関心があることでしょう。 AWS DataSync を使用すると、オンプレミスストレージと AWS Cloud Storage との間で大量のデータを簡単かつ迅速に移動できます。AWS DataSync は、データ転送プロセスの管理と、高性能で安全なデータ転送に必要なインフラストラクチャの両方を自動化することで、データの移動を容易にします。以下の画像は、AWS DataSync を使用して、オンプレミスストレージシステムと Amazon S3、Amazon EFS、Amazon FSx for Windows ファイルサーバーとの間でデータを迅速かつ効率的に移動する方法を示しています。     デモを見てみましょう… デモの準備はよろしいでしょうか? 私は準備万端です! 😁 AWS コンソールにアクセスして、AWS DataSync を検索してみましょう。   [Get Started] (今すぐ始める) をクリックします。 このブログ投稿においては、すでにエージェントを作成したと仮定します。エージェントを作成し、送信元と送信先を設定したら、次のステップではタスクを作成します。 オンプレミスのオブジェクトストレージシステムから AWS にファイルを転送するタスクを設定したいと考えています。これを行うには、[Create Task] (タスクの作成) […]

本日、Amazon Database Migration Accelerator (DMA) をローンチしたことを発表します。Amazon DMA では、AWS Database Migration Service (DMS)、AWS Schema Conversion Tool (SCT)、AWS データベース移行エキスパートを活用することで、従来の商用データベースから固定料金で移行することができます。ローンチ時点の Amazon DMA では、Oracle や SQL Server から Amazon Aurora または Amazon Relational Database Service (RDS) for PostgreSQL/MySQL への移行が可能です。ソースおよびターゲットとして対応するデータベース、データウェアハウス、分析システムは、Amazon DMA の今後の拡張に伴い、順次追加されていく予定です。詳細については、Amazon Database Migration Accelerator のページをご覧ください。 Amazon DMA を選ぶ理由 多くのお客様から、従来のデータベースの移行はとてつもなく労力がかかるうえ、しばしば予算超過や遅延が発生してしまうというフィードバックが寄せられています。そうした問題は、データベースエンジン間でのアプリケーションのリファクタリングが時間がかかり、技術的に困難であることが原因です。データベース移行に取り組むエンジニアには、ソースおよびターゲット両方のデータベースを深く知っていることに加え、さまざまなプログラミングフレームワークにも精通していることが求められます。しかし、多くの組織が、収益を生み出す、顧客に向けたプロジェクトにこそ、こうしたエキスパートエンジニアを充てたいと考えています。 Amazon DMA が従来の移行プロジェクトと異なる点 Amazon DMA では固定料金での移行が可能です。移行の完了後に支払いができるため、予算超過のリスクが軽減されます。また、AWS DMS、AWS SCT、移行エキスパートに加え、Amazon のエンジニアが社内システムの AWS […]

AWS Database Migration Service (DMS) を使用してデータベースを新しいシステムに移行する場合、新しいシステムが想定どおりに機能しない場合に備えてフォールバック戦略を立てることが賢明です。概要として、移行からロールバックするためには、4 つの基本的な戦略があります。すなわち、基本的なフォールバック、フォールフォワード、デュアル書き込み、双方向レプリケーションです。特定の状況に応じて、これらの戦略の 1 つまたは複数を用いることができる場合があります。 この投稿では、各戦略を定義し、その戦略が適切であると思われる状況の概要を説明します。一般的には、データベースシステムの整合性を維持しながら、最小限の労力とコストを必要とする戦略または戦略の組み合わせをデプロイすべきです。 基本的なフォールバック ソース A からターゲット B に移行する場合の最も簡単なフォールバック戦略は、アプリケーションを元のソース A に戻すことです。この戦略は、あまり生じないかもしれませんが、以下の状況では合理的です。 読み取り専用システムを移行していて、新しいターゲットが新しいトランザクションを取得していない。 システムは「バッチ」タイプのシステムであり、新しいターゲットにまだトランザクションを適用していない。 古いシステムにロールバックした後は、新しいシステムでトランザクションを使用する必要がいない。(一部のロギングシステムはこのパターンである場合があります。) ロールバックの前または後に、新しいシステムで使用されたトランザクションを元のシステムに再生成またはコピーすることができる。(ロギングシステムまたは挿入のみのシステムは、このパターンである場合があります。) 元のシステムにロールバックした後、新しいシステムにトランザクションを適用する必要はない。 カットオーバーの前に、DMS タスクはデータを A から B にレプリケートします。B に「フリップ」されるアプリケーションは、引き続き A とインタラクションします。次の図は、このアーキテクチャを示しています。 カットオーバー時にレプリケーションタスクが停止し、アプリケーションがフリップされて B とインタラクションします。次の図は、この変更を示しています。 ロールバックが必要な場合、アプリケーションはフリップされて A に戻ります。B のカットオーバー後に発生した変更は、無視され、または失われます。下図を参照してください。 デュアル書き込み 場合によっては、移行の一環として、デュアル書き込み戦略が使用されます。たとえば、データベース A をデータベース B に移行する場合の状況を考えてみます。デュアル書き込み戦略では、両方のデータベースにトランザクションを同時に書き込むことができるようにアプリケーションコードを変更します。デュアル書き込み戦略の採用は、アプリケーションへの (通常は重要な) 変更を伴うため、より複雑で時間のかかるフォールバックアプローチの 1 つです。ただし、ターゲットデータベース B への書き込みを停止するだけなので、デュアル書き込み構成からのフォールバックは簡単です。次の状況では、デュアル書き込み戦略が適切な場合があります。 データが (おそらく顧客ごとに) 分割されており、アプリケーションの移行に段階的なアプローチを採用している。このシナリオでは、DMS を使用して新しいターゲットをハイドレートし、ソースと同期させます。カットオーバーでは通常、デュアル書き込み機能を有効にし、DMS […]