Category: Migration and Transfer

この記事は、AWSでパートナーソリューションアーキテクトを務めるKenney Antoney Rajanによるものです。 SAPのようなエンタープライズリソースプランニング (ERP)ソフトウェアを使用する多くの組織は、セキュアファイル転送プロトコル (SFTP)サーバーを稼働および保守して、ビジネス上の重要なデータをSAPから外部のパートナーシステムに安全に転送しています。この一連のブログ記事では、SAP Process Integration (SAP PI)とSAP Process Orchestration (SAP PO)、およびSAP Cloud Platform IntegrationとAWS Transfer for SFTP (AWS SFTP)を統合するための手順を紹介します。また、AWS SFTPがAmazon Simple Storage Service (Amazon S3)に格納するデータを後処理分析に使用する方法も紹介します。

AWS は最新の AWS Database Migration Service (AWS DMS) バージョン 3.1.3 の新しいデータ変換機能をサポートするようになりました。スキーマ、テーブル、および列の名前を変更し、Oracle ターゲットの個々の表領域名を指定し、そして任意のターゲット上のテーブルの主キーと一意キーを更新することができます。DMS バージョン 3.1.3 は、以下の新しいデータ変換機能をサポートしています。 明示的なテーブルマッピング Oracle のソースおよびターゲットの表領域の変換規則 Oracle のソースおよびターゲットの索引表領域の変換規則 主キーまたは一意キーのインデックスの定義 対象列のデータ型の変更 明示的なテーブルマッピング 以前の DMS バージョンでは、AWS マネジメントコンソールを使用してテーブルマッピングを実行したり、テーブル選択を指定したり、スキーマやテーブルのルールアクションを変換したりしていました。 バージョン 3.1.3 では、AWS DMS により明示的なテーブルの選択を行えます。明示的なテーブルマッピングルールを使用すると、サポートされている DMS ターゲットへの移行用に特定のソーステーブルを選択できます。また、より良い粒度のためにソースからテーブルのサブセットを除外します。明示的な選択規則を使用するときは、テーブルマッピングのスキーマ名とテーブル名にワイルドカード (％) を使用することはできません。 次の例では、ソースに 7 つのテーブルがあります。明示的な変換規則を使用すると、残りのテーブルを移行から除外する一方、DEPT テーブルのみを移行することを選択できます。 SQL> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_CATALOG LIKE %DEPT%’ TABLE_NAME —————————— HRDEPT DEVDEPT SUPPORTDEPT PMDEPT […]

ウェブアプリケーションアーキテクチャの一般的なパターンには、アプリケーションデータを検索するための検索エンジンと対になったアプリケーションデータ用データベースが含まれます。多くのリレーショナルデータベース、さらには非リレーショナルデータベースにも、基本的な検索機能が提供されています。しかし、検索エンジンには、他のデータベースに対し、関連性とブール式による、真の、複雑な、自然言語による検索機能が搭載されています。Werner Vogels が最近指摘したように、万能のデータベースは存在しないのです。ユーザーは信頼できるデータの情報源としてリレーショナルデータベースまたは NoSQL データベースを使用し、そのデータを検索するために検索エンジン (データベース) を使用します。 お使いのデータベースからどのようにデータを Amazon Elasticsearch Service (Amazon ES) へ移し、2 つのシステム間でそれらをどのように同期しますか? ごく最近まで、スクリプトを書くか、Amazon ES を使用してデータベースをブートストラップし、同期をとるために、パイプラインを増やす必要がありました。2018 年 11 月、AWS Database Migration Service (AWS DMS) で、Amazon ES をデータベースマイグレーションのターゲットとするサポートが追加されました。AWS DMS を使用することで、データを Amazon ES へブートストラップし、DMS の変更データキャプチャ (CDC) 機能で両システムを同期できます。 本記事では、DMS タスクの処理に Amazon ES ドメインで十分なリソースを確保するためにおすすめの基準をご紹介します。しかし、あらゆるおすすめの基準と同じで、ここで触れる内容も一般論に過ぎません。データの使用量はユーザーごとに異なるためです。 AWS DMS のタスク設定パラメータ AWS DMS で Elasticsearch のターゲットを使用する場合、サポートされている任意のソースから Amazon ES へデータを移動するのはシンプルな処理です。必要なデータをすばやく安全に移行できます。Amazon ES ドメインにデータベースのテーブルまたはビューをレプリケートできます。全ロードフェーズで、ソースデータベースにある既存データのすべてがレプリケートされます。データベースの継続的な変更は、CDC […]

移行は複数のフェーズがあるプロセスで、実行する移行のタイプに応じて異なるステップが関わってきます。AWS Schema Conversion Tool (AWS SCT) レポートの活用とパートナーとの協力によって、その作業の 50 パーセント以上を自動化することができますが、それでもまだ残っている多くの作業を行う必要があります。そこで役立つのが Workload Qualification Framework (WQF) です。 この記事では、お客様のエンタープライズインフラストラクチャを移行するプロセス全体の分析に役立つ、AWS SCT のための WQF モジュールをご紹介します。WQF は、移行戦略がある場合はそれを推奨し、適切な移行ツールを提示します。また、これらの情報を明確に伝達します。 WQF は、OLTP と OLAP の各ワークロードを評価して分類する援助を行うソリューションアーキテクト、パートナー、およびコンサルタントのために設計されています。WQF は、移行の容易さ、スタッフの時間消費、および AWS のサービスにおける適切な対象サービスを判断する助けになります。 以下の図は、AWS SCT と併せて WQF を使用する場合のプロセスの概要を示したものです。 WQF は移行プロセスの計画フェーズ中に、データとそのデータを使うアプリケーションの移行に何が必要になるかを判断するために使用できます。WQF レポートは、以下を実行することによってユーザーを助けます。 以下によるワークロードの評価と各ワークロードのスコア付け。 専有機能の評価 複雑性 サイズ 使用されるテクノロジー 移行戦略の推奨 移行ツールの推奨 移行エンジニアが活用するための明瞭なフィードバックの提供 これらに加えて、WQF は AWS Data Migration Service (AWS DMS) とも統合されています。 WQF は […]

企業は年々データが急激に増加するのを目の当たりにしています。データベースとハードウェアインフラストラクチャをスケーリングし続けることは、ますます困難になっています。ワークロードが非リレーショナルデータストアに適していない場合に、基盤となるインフラストラクチャの管理に膨大な費用を費やすことなく、スケーリングの課題をどのように克服したらいいでしょうか? Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL により、コスト効率の高い方法で PostgreSQL クラウドのデプロイを簡単にセットアップ、運用、拡張することができます。昨年、私たちは (数百 GB から数 TB に及ぶ) 100 を超える Oracle データベースを Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL に移行しました。 この記事では、移行中に持ち上がった最も一般的な問題のいくつかについて説明します。皆さんは AWS Database Migration Service (AWS DMS) を使用して、あるデータベースから別のデータベースにデータを移動させた経験があることでしょう。私も AWS Schema Conversion Tool (AWS SCT) をかなり使い込みました。手始めに、データ抽出プロセスで直面する可能性のある問題を取り上げます。次に、データの移行中に起こる問題について取り上げます。最後に、移行後に PostgreSQL で観察するパフォーマンスの問題について説明します。 抽出フェーズの問題 このフェーズで一般的に直面する問題は、大きなテーブルのデータ抽出が遅くなり、ソース DB で ORA-01555 エラー (スナップショットが古すぎます) […]

AWS Database Migration Service (AWS DMS)の新しいターゲットをさらに—Amazon Elasticsearch Serviceへの新しいターゲットの追加を発表しました。これで、AWS DMSでサポートされているすべてのソースからAmazon Elasticsearch Service にデータを移行できます。この新しいターゲットのサポートで、データ統合パイプラインで DMSを使用し、ほぼリアルタイムで Amazon Elasticsearch Serviceにデータを複製できます。 Amazon Elasticsearch Serviceは、大規模かつ簡単にElasticsearchの展開、保護、操作が可能な完全に管理されたサービスです。本サービスは、オープンソースのElasticsearch API操作、管理されたKibana、およびLogstashと他のAWS serviceとの統合を提供します。これらの機能を使用すると、ログ分析、全文検索、アプリケーション監視、およびセキュリティ解析のユースケースをリアルタイムで検索、分析、視覚化することができます。 Amazon Elasticsearch Serviceを使用した検索は強力ですが、複数のデータストアからAmazon Elasticsearch Serviceへのデータの簡単な取得が可能にすることを考えていました。当社はある時点からのバルクデータのロードの可能性の確認を願っていました。また、必要に応じて転送中のデータの結合とマッピングを完全にサポートし、変更データがほぼリアルタイムで複製されるようにしたいと思っていました。AWS DMS は、現在 サポートされているソース からどのデータの移行にも役立ちます。DMSを使用すれば、必要なデータをより迅速かつ安全に移行できます。 データの分析と処理を実行したり、または電子商取引や検索サービスのビジネスに携わっている多くの大企業や技術ベンチャーは、すべてデータに関連しています。巨大なデータベースで直面する最も一般的な問題は、製品情報を検索する際の待ち時間に関連したものです。この遅延は、ユーザーエクスペリエンスの低下につながり、見込み客にそっぽを向かれることになります。データ量が増えるにつれて、大きなウェブページの応答時間の提供はさらに困難になっています。ユースケースはますます複雑になり、組織は数百万件、時には数十億件のデータベース記録を管理しているにもかかわらずつ、わずかなページの読み込み時間しか提供していません。この問題は、大きなデータセットの検索とフィルタリングによって悪化します。複雑で動的なフィルタを使用しても、数十億の記録をめくるために関連データベース（Oracle、SQL Serverなど）を拡張するには、多くの専門知識を必要とします。 今日のビジネスには、迅速に検索を促進するためにデータが格納される場所の代替案を探しています。これは、データの格納に関連データベースではなく、NoSQLを採用することで実現できます。Amazon Elasticsearchは、フルテキストの分散型NoSQLデータベースです。つまり、スキーマや表ではなく文書を使用するので、データのリアルタイム検索と分析が可能となります。人がこのシステムを高く評価しているのは、データに基づいた測定基準が即座に実行可能であるため、継続的に即座に理解できるためです。 以下は、Elasticsearchが性能に適している使用例です。 すべての行を索引付けし、これらのフィールドのブール値の組み合わせでフィールド検索を提供する 関連するフリーテキスト検索を提供する自然言語テキストによるネイティブ処理 関連した結果の提供 オートコンプリートと検索候補の提供 ファセット加工とファセットドリルダウンをサポート 地元検索のためのサポート日とGEOの場所 Amazon Elasticsearch Serviceは、検索エンジンの最良の情報に基づいて記録とソートされた結果を提供し、一般には素晴らしいです。おおよその回答を見つけることは、より伝統的なデータベースからAmazon ESを差別化するプロパティです。 要約すると、AWSは皆様のユースケースと要件に合わせたアプリケーションとデータベースの再構築の支援を目的としています。AWS DMSを使用してAmazon ESにデータの移行と複製のためのサポートの追加により、柔軟性は向上します。また、RDBMSからAmazon ESへのデータの移行の際に提供するアプローチは、あまり複雑ではありません。 Amazon Elasticsearch Serviceをターゲットとしてサポートする機能の一部は、以下のとおりです。 Amazon Elasticsearch Serviceの全バージョンがサポートされています。この文書に詳細があります。 […]

 今回は、AWS Schema Conversion Tool (AWS SCT) 新バージョンをご紹介します。このバージョンには、テーブル値関数の変換のサポート、サーバーレベルの評価レポートへの追加情報などが含まれます。 AWS SCT とは、あるデータベースエンジン上の既存のデータベーススキーマを別のデータベースエンジン用に変換するためのツールです。リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon RDS に変換することができます。たとえば、MySQL や PostgreSQL などと互換性があるため、Amazon Aurora に変換できます。また、リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon Redshift に変換することも可能です。サポートされているすべてのソースおよびターゲットは、AWS SCT ドキュメントで確認できます。 以下に、この記事で説明するトピックの概要を示します。 Microsoft SQL Server から PostgreSQL へ – テーブル値関数の変換 SQL Server から PostgreSQL/MySQL へ – テーブル型変数の変換 SQL Server から PostgreSQL へ – MERGE ステートメントの実装 Oracle から […]

AWS Database Migration Service (AWS DMS) バージョン 2.4.3 についてご紹介します。これには、PostgreSQL 10 のネイティブパーティション表へデータを移行するサポートが含まれています。 この記事では、AWS DMS バージョン 2.4.3 を使用して Oracle パーティション表から PostgreSQL 10 のネイティブパーティション表へデータを移行する方法について説明します。これは特殊な設定をせずに行えます。AWS DMS と並行してパーティション表のスキーマ変換を実行するには、この変換をサポートするようになった AWS Schema Conversion Tool (AWS SCT) を使用できます。 PostgreSQL のパーティショニング パーティショニングは、論理的に 1 つの大きな表をより小さな物理的なピースに分割することを指します。パーティショニングにはいくつかの利点があります。 AWS DMS を使用してこの記事の説明に従ってパーティション表に移行する前に、PostgreSQL のパーティション表に精通している必要があります。PostgreSQL はバージョン 10 でネイティブパーティショニングサポートを導入しました。 以下は、Oracle パーティション表から PostgreSQL 10 ネイティブパーティション表にデータを移行する例です。ソースの Oracle パーティション表は、作成日の列に 3 つのパーティションが作成されます。すべてのパーティションは、それぞれの日付範囲の値に基づいてデータを保持します。 ステップ 1: レンジパーティション基準を使用して Oracle […]

Amazon RDS for MySQLでdelayed replicationをサポートしました。これにより、レプリカデータベースがソースデータベースより遅延する期間を設定できます。標準のMySQLレプリケーション設定では、ソースとレプリカの間の遅延が最小限に抑えられています。今回のアップデートで意図的な遅延を導入するオプションを選べるようになりました。 遅延は、人為的なエラーから復旧させる必要がある場合に非常に役立ちます。たとえば、誤ってプライマリデータベースからテーブルを削除した場合、レプリカで同じクエリを実行する必要はありません。テーブルが削除される直前でレプリケーションを停止し、レプリカをスタンドアロンインスタンスに昇格させることができます。このブログ記事では、delayed replicationを使用して、このようなシナリオから復旧させる方法をご紹介します。 次の図は、遅延が3600秒(1時間)に設定されたレプリカを人為的エラーから回復する方法を示しています。まず、レプリケーションを停止します。次に、ログの問題の箇所を見つけ、問題のクエリが実行される直前までトランザクションを実行し。最後に、レプリカをマスターに昇格させます。   前提条件 delayed replicationをチェックする前に、Amazon RDS for MySQLソースデータベースインスタンスでMySQL 5.6.40または5.7.22以降が必要です。また、インスタンスに接続するためのMySQLクライアントと、データベースにアクセスできる適切なセキュリティグループが必要です。 バイナリログを十分な時間保持していることを確認してください。バイナリログの詳細については、 MySQL Binary Logsを参照してください。次のコマンド例は、保持期限を24時間に設定する方法を示しています。 call mysql.rds_set_configuration(‘binlog retention hours’, 24);   シナリオの設定 既存のAmazon RDS for MySQLデータベースを既存のリードレプリカで使用するか、新しいデータベースを作成します。このブログ記事では、既存のRDS MySQLデータベースを利用し、新しい読み取りレプリカを作成します。 データベースの作成 MySQLインスタンス用のAmazon RDSをまだお持ちでない場合は、作成をしてください。クライアントマシンからのアクセスを許可するセキュリティグループを使用してデータベースを構成してください。作業したいMySQLデータベースがすでにある場合は、この手順をスキップしてください。 AWSマネージメントコンソール、AWS CLI、AWS SDK、またはAWS CloudFormationテンプレートを使用して、MySQLデータベース用のRDSを作成します。MySQLインスタンスの作成を支援する必要がある場合は、Create and Connect to a MySQL Database with Amazon RDSの手順に従ってください。次のスクリーンショットは、すでに設定されて使用可能な1つのデータベースインスタンスを示しています。 データベースに接続する マスターデータベース・インスタンスが作成されて使用可能になったら、そのデータベースインスタンスに接続します。Amazon EC2 Linuxマシンを使用している場合は、次のコマンドに示すように、いくつかの環境変数を設定して余分なタイピングを省くことができます。 export REGION=”us-west-2″ export […]

AWS は、AWS Identity and Access Management (IAM) や AWS Key Management Service (AWS KMS)　などのインフラストラクチャおよびサービスを保護する、セキュリティ機能を豊富に提供しています。AWS Data Migration Service (AWS DMS) を使うと、既存のデータベースから Amazon RDS にデータを簡単に自動移行することができます。その一環として、AWS DMS はいくつかの AWS セキュリティ機能を使用し、お客様にサービスを提供しています。例えば、DMS は他のセキュリティ機能の中でも、AWS KMS キーを使用した、静止状態でのデータベース接続およびデータ暗号化のための Secure Socket Layer (SSL) 暗号化を、すでにサポートしています。 それでも、クラウド内のデータベースに移行する際に、付加的な法令遵守の義務や特定のセキュリティポリシーに遭遇する企業もあります。こうした企業は、クラウド責任共有モデルの中でも、適切なデータ保護手段を利用する必要があります。このようなユーザーに、Baffle は最も重要なデータを保護する、列レベルの暗号化メカニズムを提供しています。企業は、DMS の使用中でもアプリケーションの変更を行わず、このメカニズムを実装できます。 アプリケーションを変更せずに暗号化できるこの機能により、既存のアプリケーションや新しいアプリケーションにデータのプライバシーを追加することが可能となります。バックエンド管理者またはサードパーティがアプリケーションデータにアクセスできないようにするのです。このアプリケーションの透過性とプライバシー保護は、DMS がデータベース間でデータを移行するのに使用するツールにまで及びます。これらのツールを使用すると、データを Amazon RDS に移行する際にデータを暗号化することができます。DMS とのカスタム統合なしでデータを暗号化でき、AWS への移行中および移行後にデータが公開されるリスクはほとんどありません。 このブログ記事では、Baffle の Advanced Data Protection ソリューションを使用して、RDS に移行するデータベースを暗号化する方法について解説します。Baffle のアプローチだと、データがクラウド上にある間に、メモリ内であろうと静止状態であろうと、確実にデータが保護されるようにします。以下に示すように、実際上、標準の DMS 移行ワークフローにはほとんど変更がありません。 […]