Amazon Web Services ブログ

6 月の AWS Black Belt オンラインセミナーのご案内 [GreenGrass緊急開催決定!]

こんにちは。プロフェッショナルサービスの宮本です。AWS Greengrassが一般利用可能となったため、AWS GreengrassのAWS Black Belt オンラインセミナーの緊急開催が決定しました!IoTデバイスからのデータ送信量が増加傾向にある昨今、GreenGrassのようにIoTデバイスのローカル環境上で実行できるアプリケーションの管理が必須な技術要素となってきています。この機会をお見逃しなく!

※サービスカットですが、火曜日のお昼開催となりますのでご注意ください。

6 月は、AWSの新サービス、機能追加のご紹介や、5月30日から6月2日まで4日間に渡って開催されたAWS Summit Tokyo 2017の振り返りなど幅広いラインナップでお送りいたします。また今年から開始したオンラインハンズオンの開催もありますので、ふるってご参加いただければと思います。

※ 2017/6/6追記: 6/20に予定していたAWS Lambda回は都合により7月に延期になりました。

6 月の開催予定

サービスカット

6/7(水) 18:00-19:00 Amazon Redshift Update – 最近追加された新機能とRedshift Spectrumの解説
6/14(水) 18:00-19:00 AWS Snowball
6/21(水) 18:00-19:00 Server Migration Service Application Discovery Service
6/27(火) 12:00-13:00 AWS Greengrass
6/28(水) 18:00-19:00 AWS Code Services Part 2

ソリューションカット

6/13(火) 12:00-13:00 AWS Summit Tokyo 2017 まとめ

ハンズオン

6/28(水) 14:00-16:30 AWS 体験オンラインハンズオン~セキュア&スケーラブルウェブサービス構築編~

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

Amazon Rekognition の更新 – 有名人の認識

re:Invent で Amazon Rekognition をリリースし (「Amazon Rekognition – ディープラーニングがサポートする画像の検出と認識 (Amazon Rekognition – Image Detection and Recognition Powered by Deep Learning))、本年初頭にイメージモデレーションを追加しました。本日は、有名人の認識を追加します。Rekognition のトレーニングにより、政治、スポーツ、芸能、ビジネス、メディアなどの分野の有名人や著名人を多数識別できるようになりました。このリストはグローバルで、頻繁に更新されます。この機能にアクセスするには、新しい RecognizeCelebrities関数を呼び出します。既存の DetectFaces 関数によって返される境界ボックスおよび顔ランドマーク機能に加えて、新しい関数では認識される有名人に関する情報が返されます。

"Id": "3Ir0du6", 
"MatchConfidence": 97, 
"Name": "Jeff Bezos", 
"Urls": [ "www.imdb.com/name/nm1757263" ]

Urls は、有名人に関する追加情報を提供します。現在、この API は IMDB コンテンツへのリンクを返します。今後は他のソースを追加する可能性があります。この機能をお試しになるには、AWS Management Console有名人の認識デモをお使いください。

イメージアーカイブを持っている場合は、有名人別にインデックスを作成できます。有名人の認識とオブジェクトの検出を組み合わせて使用して、あらゆる種類の検索ツールを構築することもできます。イメージが S3 にすでに保存されている場合は、そこで処理できます。この新機能には、いろいろな面白い使い方があるかと思います。ご意見ご感想をお寄せいただき、皆様がどのようなものをビルドしたかお知らせください。

Jeff;

AWS Greengrass – AWS Lambdaをネットワーク接続性のあるデバイス上で動かす

私が最初に AWS Greengrassについて投稿したのは、re:Invent期間中でした。(AWS Greengrass -ユビキタス, 現実世界におけるコンピューティング)
我々は、ご興味をお持ちいただいたお客様を招待制という限定プレビューのかたちでローンチさせていただきました。
そのときに私がお知らせしたように、多くのAWSの顧客は、接続が遅く、時には断続的、信頼できない場合がある、現場でデータを収集して処理したいと考えています。Greengrassでは、AWSプログラミングモデルを小型で簡単なフィールドベースのデバイスに拡張することができます。 AWS IoTAWS Lambdaをベースに構築されており、AWS Cloudで利用可能な多様なサービスへのアクセスをサポートしています。

一般利用可能

今日、Greengrassは米国東部(バージニア)と米国西部(オレゴン)のリージョンで一般利用可能になっています。プレビュー中、AWSのお客様はGreengrassでの実践的な体験を得て、その周辺のアプリケーションやビジネスの構築を開始できました。これらの初期の成功のいくつかをこの記事の後半で共有します。

(more…)

Amazon EMRでS3DistCpを使用してHDFSとAmazon S3間で効率的にデータを移動するための7つのヒント

Amazon S3とHadoop Distributed File System(HDFS)の間で大量のデータを移動する必要があったものの、データセットが単純なコピー操作には大きすぎるということはありませんでしたか? EMRはこれを救うことができます。ペタバイト級のデータの処理と分析に加えて、EMRは大量のデータの移動もできます。

Hadoopエコシステムでは、DistCpがデータを移動するためによく使用されます。 DistCpは、MapReduceフレームワークの上に構築された分散コピー機能を提供します。 S3DistCpは、S3で動作するように最適化されたDistCpの拡張機能であり、いくつかの便利な機能が追加されています。 S3DistCpは、HDFSとS3の間でデータを移動するだけでなく、ファイル操作のスイスアーミーナイフです。この記事では、S3DistCpを使用するための基本的なユースケースから始めて、さらに高度なシナリオまでのヒントについて説明します。

  1. 変換なしにファイルをコピーまたは移動する
  2. ファイル圧縮を変更しつつコピーする
  3. ファイルを段階的にコピーする
  4. 1つのジョブで複数のフォルダをコピーする
  5. パターンに基づいてファイルを集約する
  6. サイズが1TBを超えるファイルをアップロードする
  7. S3DistCpステップをEMRクラスターにサブミットする

(more…)

AWS Greengrass – 接続されたデバイスでの AWS Lambda 関数の実行

私が re:Invent 中に公開した投稿 (「AWS Greengrass – ユビキタスなリアルワールドコンピューティング」) で、初めて AWS Greengrass についてご紹介しました。その時点で限定プレビューの Greengrass の提供を開始し、関心をお持ちの場合はぜひサインアップしていただくよう皆様にお願いしました。そのときに説明したように、AWS の多くのお客様はフィールドでのデータの収集と処理を希望していますが、フィールドでの接続は低速で、中断したり信頼性が低くなったりすることが少なくありません。Greengrass では、AWS のプログラミングモデルを小型でシンプルなフィールドベースのデバイスに拡張することができます。これは AWS IoTAWS Lambda 上に構築されていて、AWS Cloud で利用できる、増え続けるさまざまなサービスへのアクセスがサポートされます。Greengrass では、フィールドで実行され、AWS リージョンへ継続的な高帯域幅接続に依存しないコンピューティング、メッセージング、データキャッシュ、および同期の各サービスにアクセスできます。Python 2.7 で Lambda 関数を記述し、デバイスシャドウを使用して状態を維持しながら、クラウドから Greengrass デバイスにデプロイできます。デバイスと周辺機器は、クラウドを経由しないローカルメッセージングを使用して相互に通信できます。

一般提供を開始
本日、AWS は US East (Northern Virginia) および US West (Oregon) リージョンで Greengrass の一般提供を開始しました。プレビュー中に AWS のお客様は Greengrass を実際に体験し、アプリケーションやビジネスの構築を開始できました。これらの初期的な成功のいくつかは、この投稿の後半でお知らせします。Greengrass Core コードは各デバイスで実行されます。デバイスに Lambda アプリケーションをデプロイして実行し、セキュアなネットワークでローカル MQTT メッセージングをサポートして、デバイスとクラウド間の対話がセキュアな接続で行われるようにします。Greengrass Core は、Lambda 関数を含む、セキュアな無線によるソフトウェア更新もサポートします。これには、メッセージブローカー、Lambda ランタイム、Thing Shadows の実装、およびデプロイエージェントが含まれます。Greengrass Core および (オプションで) その他のデバイスにより、Greengrass グループが構成されます。グループには設定データ、Greengrass Core のデバイスと ID のリスト、Lambda 関数のリスト、およびメッセージの送信先を定義するサブスクリプションのセットが含まれます。このすべての情報は、デプロイプロセス中に Greengrass コアデバイスにコピーされます。Lambda 関数は 3 つの個別の SDK で API を使用できます。

AWS SDK for Python – この SDK では、コードは Amazon Simple Storage Service (S3)Amazon DynamoDBAmazon Simple Queue Service (SQS)、およびその他の AWS のサービスと連携できます。

AWS IoT Device SDK – この SDK (Node.js、Python、Java、および C++ 用に利用可能) は、ハードウェアデバイスを AWS IoT に接続するうえで役立ちます。C++ SDK には、Greengrass 検出サービスやルート CA のダウンロードのサポートなど、いくつか追加の機能があります。

AWS Greengrass Core SDK – この SDK は、他の Lambda 関数のローカル呼び出し、メッセージの発行、Thing Shadows との連携が可能な API を提供します。Greengrass Core は、OverlayFS およびユーザー名前空間の機能を有効にしたバージョン 4.4.11 (またはそれ以降) の Linux カーネルを持つ x86 および ARM デバイスで実行できます。Greengrass のほとんどのデプロイは専門的な工業用ハードウェアを対象としていますが、デプロイおよびテスト目的で Raspberry Pi または EC2 インスタンスで Greengrass Core を実行することもできます。この投稿では、WiFi 経由で私の自宅のホームネットワークに接続された BrickPi に Raspberry Pi をアタッチして使用しました。

Raspberry Pi、BrickPi、ケース、およびその他すべてのパーツは、BrickPi 3 Starter Kit に用意されています。これらをすべて組み合わせて使用するには、Linux コマンドラインの関するいくらかの専門知識と、手動の巧みな操作がほどほど必要になりますが、私ができるのであれば、お客様も確実にできるでしょう。

Greengrass の実行
Greengrass はコンソール、API、または CLI からアクセスできます。私はコンソールを使用します。Greengrass コンソールの [Intro] ページでは、グループの定義、Greengrass Core の追加、およびグループへのデバイスの追加ができます。

[Get Started] をクリックし、[Use easy creation] をクリックします。

次に、グループに名前を付けます。

最初の Greengrass Core に名前を付けます。

準備ができたので、[Create Group and Core] をクリックします。

これは数秒間実行されてから、Greengrass Core とともに、ダウンロードできるセキュリティリソース (2 つのキーと証明書) が表示されます。

セキュリティリソースをダウンロードし、安全な場所に配置します。次に、目的のバージョンの Greengrass Core ソフトウェア (私の Raspberry Pi の場合は ARMv7l) を選択してダウンロードし、[Finish] をクリックします。次に、Pi を起動し、セキュリティリソースとソフトウェアを Pi にコピーします (S3 バケットに配置し、 wget でダウンロードしました)。この時点でのシェル履歴は次のとおりです。

 

重要な更新: AWS セキュリティチームの鋭い同僚の 1 人が指摘したように、これはシークレットをデバイスに配布するための良い方法ではありません。AWS CLI を使用して、暗号化されたバケットからこれらをダウンロードするか、カットアンドペーストでコピーするか、USB キーを使用することができました。ユーザーガイドの指示に従って、新しいユーザーとグループを作成し、 rpi-update スクリプトを実行して、 sqlite3opensslを含むいくつかのパッケージをインストールします。数回の再起動後に、続行する準備ができました。次に、引き続き指示に従って Greengrass Core ソフトウェアを展開し、セキュリティリソースを最終的な場所 (/greengrass/configuration/certs) に移動して、その過程で一般的な名前を付けます。ディレクトリは次のようになります。

次のステップは、AWS IoT Thing とコアの関連付けです。コンソールに戻り、クリックしてグループと Greengrass Core に移動して、Thing ARN を見つけます。

証明書と Thing ARN の名前を config.json ファイルに挿入し、 iotHostggHostの不足しているセクションを入力します。

Greengrass デーモンを開始します (これは 2 回目の試行です。1 回目はパス名の 1 つで入力ミスがありました)。

コマンドラインでの時間を楽しんだ後 (Unix v7 や BSD 4.2 を使用していたころを思い出しました)、再びビジュアルに戻ります。AWS IoT ダッシュボードに移動すると、Greengrass Core が IoT への接続を実行していることがわかります。

Lambda コンソールに移動し、Python 2.7 ランタイムを使用して Lambda 関数を作成します (ここでは IAM ロールは関係ありません)。

通常の方法で関数を発行し、Greengrass コンソールに移動してグループをクリックし、Lambda 関数の追加を選択します。

次に、デプロイするバージョンを選択します。

また、関数をオンデマンドではなく長期間使用するよう設定します。

コードにより AWS IoT にメッセージが発行されるため、ソースとターゲットを指定してサブスクリプションを作成します。

サブスクリプションでトピックのフィルター (hello/world) も設定します。

設定を確認し、サブスクリプションを保存します。これで、コードをデプロイする準備ができました。再びグループにアクセスし、[Deployments] をクリックして、[Actions] メニューから [Deploy] を選択します。

[Automatic detection] を選択して続行します。

これが最初のデプロイである場合は、他の AWS のサービスにアクセスする権限を Greengrass に与えるサービスレベルロールを作成する必要があります。[Grant permission] をクリックします。

各デプロイの状態を確認できます。

コードは現在、Pi で実行されています。コードはトピック hello/world にメッセージを発行します。これは IoT コンソールに移動し、[Test] をクリックして、トピックにサブスクライブすることで表示されます。

メッセージは次のとおりです。

すべての設定作業を行ったら、新しいバージョンのコードをアップロード、発行、デプロイして反復性のある開発を行うことができます。私は BrickPi を使用して LEGO Technic モーターを制御し、一部のセンサーから収集したデータを公開する計画です。この投稿をお楽しみに。Greengrass の料金表 Greengrass Core は、AWS 無料利用枠の一部として、1 年間 3 つのデバイスで無料で実行できます。次のレベル (3~10,000 デバイス) では、2 つのオプションを利用できます。

  • 従量制 – 1 か月、1 デバイスあたり 0.16 USD。
  • 年間契約 – 1 年、1 デバイスあたり 1.49 USD (17.5% の節約)。

10,000 以上のデバイスで Greengrass Core を実行するか、より長期的を希望される場合は、当社までお問い合わせください。

すべての料金モデルの詳細は、Greengrass 料金表ページでご覧いただけます。

Jeff;

最大 2 か月まで無料で Amazon WorkSpaces をお試しください

私は実際の経験を非常に重視しています。ごくまれな状況を除いて、私のブログの投稿は、該当のサービスを使用してから書いています。「私は Amazon WorkSpace がお気に入りです」という投稿をお読みになっていれば、Amazon WorkSpaces が私にとって最も重要な生産性ツールの 1 つであることをご存知かと思います。お客様ご自身で、WorkSpaces を無料でお試しいただく機会についてお話したいと思います。

新しい Amazon WorkSpaces の無料利用枠では、2 つの標準バンドル WorkSpaces を起動し、最大 2 か月まで 1 か月あたり合計 40 時間ご使用になれます。Windows Server を利用した Windows 7 または Windows Server 10 のデスクトップ体験を選択できます。どちらのオプションにも、Internet Explorer 11、Mozilla Firefox、7-Zip、および Amazon WorkDocs と 50 GB のストレージが含まれています。無料利用枠を利用するには、AutoStop モードで WorkSpaces を実行する必要があります。これはデフォルトで選択されます。未使用の時間は最初の月の末日に期限切れになり、無料利用枠は 2 か月目の末日に期限切れになります。

その後は、Amazon WorkSpaces 料金表ページに記載されている時間レートで課金されます。使用を開始するには、クイックステップの手順に従って、無料利用枠の対象となるバンドルを選択してください。

本特典は、現在 WorkSpaces が利用可能なすべての AWS リージョンでご利用いただけます。

Jeff;

6 月の AWS Black Belt オンラインセミナーのご案内 [確定版]

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー 6 月の配信に関しまして、テーマが確定しましたので改めてご案内させて頂きます。6 月は、AWSの新サービス、機能追加のご紹介や、5月30日から6月2日まで4日間に渡って開催されたAWS Summit Tokyo 2017の振り返りなど幅広いラインナップでお送りいたします。また今年から開始したオンラインハンズオンの開催もありますので、ふるってご参加いただければと思います。

※ 2017/6/6追記: 6/20に予定していたAWS Lambda回は都合により7月に延期になりました。

6 月の開催予定

サービスカット

6/7(水) 18:00-19:00 Amazon Redshift Update – 最近追加された新機能とRedshift Spectrumの解説
6/14(水) 18:00-19:00 AWS Snowball
6/21(水) 18:00-19:00 Server Migration Service Application Discovery Service
6/28(水) 18:00-19:00 AWS Code Services Part 2

ソリューションカット

6/13(火) 12:00-13:00 AWS Summit Tokyo 2017 まとめ

ハンズオン

6/28(水) 14:00-16:30 AWS 体験オンラインハンズオン~セキュア&スケーラブルウェブサービス構築編~

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

SAP on AWSにおけるVPCサブネットのゾーニングパターン 第2回:ネットワークのゾーニング

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。

VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。この第2回となる記事では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明します。

従来のオンプレミス環境の実装モデルでは、アプリケーションは様々なネットワークゾーンに分離されています:

  • 制限付きゾーン: これは最も安全なゾーンで、機密データを管理します。例えば、会計や人事ソリューション、コンテンツリポジトリやファイルサーバー用のデータベースをここに配置します。
  • イントラネットゾーン: このゾーンは、制限付きゾーン内のデータベースにアクセスするアプリケーションサーバーを対象としています。例えば、SAP Advanced Business Application Programming(ABAP)、Java Central ServicesといったSAPアプリケーションサーバーをここに配置します。企業ネットワークに接続されるエンドユーザーのデバイスもこのゾーンにも配置されます。
  • エクストラネットゾーン: このゾーンには、SAP Process Orchestration(PO)やSAP Process Integration(PI)、SSH File Transfer Protocol(SFTP)サーバー、SAP TREXなどのミドルウェアを配置します。このゾーンは、外部ゾーンと内部ゾーンの間の中間ゾーンとして機能します。
  • 外部ゾーン: このゾーンでは、インターネットに直面しているアプリケーションとアプライアンスを管理し、内部ゾーンのアプリケーションの入口または出口のポイントとして機能します。このゾーンに配置されるソリューションの例としては、Network Access Translation(NAT)インスタンス、リバースプロキシ、およびSAProuterです。
  • 管理/共有サービスゾーン: 上記のすべてのゾーンで必要とされるMicrosoft Active Directory、管理サーバー、SAP Solution Manager、あるいはDNSサーバーなどのアプリケーションをこのゾーンに配置します。
  • インターネットゾーン: このゾーンは管理しませんが、ビジネスパートナーやSaaSプロバイダなどが管理するアプリケーションに接続するときは、このゾーンと連携します。

図 1:様々なネットワークゾーン

従来の環境では、ファイアウォールのルールを定義することによってゾーン間のトラフィックの流れを制御しています。AWSでは、サブネットレベルのステートレスなファイアウォールであるネットワークアクセスコントロールリスト(ネットワークACL)、インスタンスまたはElastic Network Interfaceレベルのステートフルなファイアウォールであるセキュリティグループ、そしてトラフィックがどこに向けられるかを決定する一連のルールとなるルートテーブルを使用してトラフィックの流れを制御します。

では、これらのゾーンをどのようにAWSに合わせて展開するのでしょうか?

前回の記事で紹介したアーキテクチャでは、私たちは暗黙的にゾーンを定義し、サブネットレベルでアプリケーションを分離しています。エクストラネットゾーンを除くすべてのゾーンについて説明しました。

図 2:サブネットレベルの分離によるネットワークゾーンの配置

もちろん、サブネットはAWS上のアプリケーションを分離する唯一の方法ではありません。ゾーンごとに異なるVPCを使用してアプリケーションを限定することもできます。例えば、管理ゾーンに専用のVPCを作成し、VPCピア接続を使用して、(他のVPC内にある)他のゾーンと接続することができます。ただし、SAPアプリケーションサーバーやデータベースなど、密接に関連するコンポーネントを別々のVPCに分けることはお勧めしません。

1つのVPCで複数のサブネットにするか、複数のVPCを使用して分離するか、判断するために役立つ基準は何でしょうか?

経験則はなく、一般的に、管理のし易さと組織における職務の分離によって選択されます。例えば、組織内では、Microsoft Active Directory(SAPユーザーの管理とシングルサインオン用)、電子メール、マルウェア対策など、管理ゾーンのサービスとして使用するSAP以外のアプリケーションがあるとします。これらの共有サービスは、別々のチームによって管理される場合があり、そしてその影響範囲が大きく違うため、まったく異なる変更管理プロセスが必要になる場合があります。したがって、これらの共有サービス用に個別のVPCを作成することもできます。また、AWS Organizationsを使った複数のAWSアカウント戦略を取ることにより、この共有接続を管理することもできます。

異なるVPCに外部ゾーンと管理ゾーンを配置し、イントラネットゾーンと制限付きゾーンは1つのVPCにまとめたままにすると、前回の記事のアーキテクチャがどのように見えるかを確認してみましょう。

図 3:複数のVPCにまたがったネットワークゾーンの配置

この設計に合わせていくつかの設定を変更する必要があります:

  • VPCごとに別々のVPC CIDRを使用してください。例えば、VPC CIDRとしては10.0.0.0/16しかありませんでしたが、今では次のものが必要になります。
    • 10.0.0.0/16 – イントラネットゾーン(サブネット 10.0.1.0/24)と制限付きゾーン(サブネット 10.0.2.0/24)のための一つのVPC CIDR
    • 10.2.0.0/16 – 外部ゾーンのためのVPC CIDR(サブネット 10.2.1.0/24)
    • 10.3.0.0/16 – 管理ゾーンのためのVPC CIDR(サブネット 10.3.1.0/24)
  • VPCピア接続を使用して、それぞれのVPC間の接続を確立します。
  • 必要に応じて、あるVPCから別のVPCへのトラフィックをルーティングするために、ネットワークACL、ルートテーブル、およびセキュリティグループを調整します。

ここまでの概要と今後の予定

この記事では、従来のネットワークゾーンをAWSクラウドで同等の構造に置き換えました。次回の記事では、内部および管理された、または管理されていない外部接続を必要とするSAPアプリケーションのサブネットのゾーニングパターンについて紹介して、このシリーズを締める予定です。

私たちは、SAPアプリケーションにおけるVPC設定について皆様の経験をお聞きしたいと思っています。このシリーズ記事に関するご質問やご意見がございましたら、お気軽にお問い合わせください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。

オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。

AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。

この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。

以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。

お客様のフィードバックに基づいたアップデートの後、AWS SCT と AWS DMS を使用して Oracle Database のビューとファンクションを Amazon Redshift に移行できるようになりました。

次の図は移行手順を示しています。

準備

この移行を開始するには次の手順を実行します。

  • AWS SCT をダウンロード
  • AWS SCT グローバル設定 からデータベースドライバーをダウンロードし、そのパスを設定。
  • 米国西部(オレゴン)リージョンで使用できる Amazon EC2 キーペアを用意。持っていない場合は新しい Amazon EC2 キーペアを作成。

スタックの作成

この投稿では、AWS CloudFormation スタックを起動するために、以下の Launch Stack を使います。起動プロセス中に前述のアーキテクチャも作成されます。結果は AWS DMS コンソールで確認できます。移行が終わると、CloudFormationスタックは破棄できます。

このリンクは米国西部(オレゴン)リージョン (us-west-2) でスタックを開始します。

一部のリソースを使用されている間は料金が発生します。

Launch Stack

スタックを起動して名前を付けるには、次のようにします。

  1. AWSアカウントにまだログインしていない場合はログイン。
  2. Launch Stack を選んで、あらかじめ用意されたCloudFormationテンプレートでCloudFormationコンソールを起動。「次へ」を選択。
  3. スタック名には入力済みのorclrsmigrationを使用するかカスタム名を入力。KeyNameを選択し、Redshiftクラスター用のMasterUserPasswordを入力し、「次へ」を選択。
    Specify Details
  4. 確認ページにて、スタックの起動結果としてCloudFormationが AWS Identity and Access Management (IAM) ロールを作成することを確認。「作成」を選択。
    I acknowledge that AWS CloudFormation might create IAM resources with custom names.
  5. スタック作成の進行状況を確認するには更新ボタンを押し、起動イベントを表示するスタックを選択。
    Eventsタブ
  6. スタックが正常に起動すると、状況はCREATE_IN_PROGRESSからCREATE_COMPLETEに変わります。次のセクションで使用する値を表示するには「出力」を選択。
    Outputsタブ

このCloudFormationテンプレートによって作成されたインフラは、次のセクションで使用されます。以下のテーブルでリストされている値が表示されています。

Schema Conversion Tool での設定

Schema Conversion Tool での設定のために、以下を実行します。

  1. AWS Schema Conversion Tool を開始。
  2. Fileから New Project を選択。New Project ダイアログが表示される。
    New Project dialog
    次のプロジェクト情報を追加。

    Project Name プロジェクト名を入力。コンピュータにローカル保存される
    Location ローカルプロジェクトファイルの保存先を入力
    Data Warehouse (OLAP)
    Source DB Engine Oracle DW
    Target DB Engine Amazon Redshift
  3. AWS Schema Conversion Tool プロジェクトを作成するためOKを選択。
  4. Oracle Database に接続するため、Connect to Oracle DW を選択。

    Connect to Oracle DW ダイアログが表示される。移行元の Oracle Database 接続情報を入力。

    以下の値をフォームに入力。

    Server name <移行元EC2エンドポイントのDNS名>
    Server port 1521
    Oracle SID XE
    User name dms_sample
    Password dms_sample
    Use SSL チェックしない
  5. 移行元のデータベースに正しく接続できるかを確認するため、Test Connection を選択。
  6. 移行元データベースに接続するため、OKを選択。
  7. DMS_SAMPLEデータベースを選び、Nextを選択。
  8. Database Migration Assessment Report を読み、Nextを選択。

  9. Amazon Redshift に接続するため、Connect to Amazon Redshift を選択。

    Connect to Amazon Redshift ダイアログが表示される。移行先のデータベース接続情報を入力。

    以下の値をフォームに入力。

    Server name 移行先RedshiftエンドポイントのDNS名
    Server port 5439
    Database dev
    User name admin
    Password CloudFormationで選ばれたパスワード
    Use SSL チェックしない
  10. 移行先のデータベースにただしく接続できるかを確認するため、Test Connection を選択。
  11. 移行先データベースに接続するため、OKを選択。

スキーマを変換

次にスキーマを変換します。

  1. Viewを選び、Main View を選択。
  2. 移行元のデータベースのスキーマを表示している左側のパネルから変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Convert schema を選択。
  3. AWS Schema Conversion Tool でのスキーマ変換が完了すると、選択されたスキーマがビューやファンクションを含めて移行先の Amazon Redshift クラスター上で表示されます。この時点では、移行先の Amazon Redshift クラスターにスキーマは適用されていません。このウィンドウでスキーマを編集できます。編集したスキーマはプロジェクトの一部として保存されます。変換されたスキーマをデータベースに適用することを選択すると、編集されたスキーマが移行先DBインスタンスに書き込まれます。
  4. 移行先データベースのスキーマを表示する右側のパネルで、変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Applyを選択。

この時点で、データが空の状態のデータベーススキーマが Amazon Redshift クラスター上にできあがります。

データベース移行のために AWS DMS を構成

次にDMSに移ります。

  1. AWSマネジメントコンソールでDMSを選び、「移行の作成」を選択。
  2. 「AWS Database Migration Service へようこそ」ページで「次へ」を選択。
  3. 「レプリケーションインスタンスの作成」ページが表示される。

    このページで以下の値を入力し、「次へ」を選択。

    名前 8から16文字のASCII文字によるレプリケーションインスタンスの名前(/、”、@を除く)
    説明 レプリケーションインスタンスの説明を入力
    インスタンスクラス dms.t2.medium
    VPC 使いたい Amazon Virtual Private Cloud (Amazon VPC) を選択。移行元または移行先または両方があるVPCを使う
    Multi-AZ いいえ
    パブリックアクセス可能 チェック
  4. 「アドバンスト」タブはデフォルトのままで、「次へ」を選択。

データベースエンドポイントの設定

  1. ソースエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン oracle
    サーバー名 <移行元EC2エンドポイントのDNS名>
    ポート 1521
    SSLモード none
    ユーザー名 dms_sample
    パスワード dms_sample
  2. ターゲットエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン redshift
    サーバー名 <RedshiftエンドポイントのDNS名>
    ポート 5439
    SSLモード none
    ユーザー名 admin
    パスワード CloudFormationで選ばれたパスワード

レプリケーションインスタンスが正しく作成された後に「テストの実行」を選ぶことで、エンドポイントへの接続をテストできます。

タスクの作成

「タスクの作成」ページでタスクのオプションを設定します。

以下のテーブルはタスクの設定について説明しています。

タスク名 タスク名を入力
ソースエンドポイント 使用する移行元エンドポイントを選択
ターゲットエンドポイント 使用する移行先エンドポイントを選択
レプリケーションインスタンス 使用するレプリケーションインスタンスを選択
移行タイプ Migrate existing data
作成時にタスクを開始 チェックする

「ターゲットテーブル作成モード」は「何もしない」を選択。

「テーブルマッピング」ではdms_sampleを選び、Add selection rule を押して、「タスクの作成」を選択。

タスクの監視

タスクの作成で「作成時にタスクを開始」を選んだ場合、「タスクの作成」を選択するとすぐにデータ移行が開始されます。AWSマネジメントコンソールから実行中のタスクを選ぶことで、タスクの統計と監視の情報を表示できます。次のスクリーンショットはデータベース移行のテーブル統計を表しています。

まとめ

この投稿では Oracle Database の商用環境をビューやファンクションとともに Amazon Redshift に移行することがいかに簡単であるかをご紹介しました。


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は Migrating Oracle Database from On-Premises or Amazon EC2 Instances to Amazon Redshift です。

Oracle Database を Amazon Aurora に移行する方法

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。

データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。

AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。

すばらしい! では、どこから始まれば良いのでしょう?

AWS SCT での移行手順

通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool とは からご覧ください。

この投稿ではSCTのイストールや構成については触れませんが、注意点は移行元と移行先のデータベースにSCTを接続するために、OracleとMySQLのドライバーをインストールする必要があることです。移行元のOracleに接続した後、スキーマのいずれかを右クリックしてアセスメントレポートを作成できます。アセスメントレポートはこのスキーマがどれくらいOracleからAuroraに自動変換されるのかと、自動変換後に残された作業量がどれくらいなのかの概要を教えてくれます。以下がレポートの例です。

Database Objects with Conversion Actions for Amazon Aurora

アセスメントレポートに加えて、SCTは各オブジェクトがどれくらい正確に変換されるかも教えてくれます。もしあるオブジェクトが変換できない場合、SCTはその理由と、状況を改善するためのヒントを教えてくれます。

Database Objects with Conversion Actions for Amazon Aurora

スキーマの100%がOracleからAuroraに変換されない場合、いくつかの方法で状況を改善できます。

  • 移行元のOracleのデータベース上のオブジェクトを変更して、SCTでAuroraに変換できるようにする
  • スキーマをひとまず変換し、SCTによって生成されたスクリプトを変更してからAuroraデータベースに適用する
  • 変換できないオブジェクトを無視し、移行先でそれらを置き換えるか無視する。たとえば、Oracleのsys.dbms_randomパッケージを呼び出すファンクションがあるとします。このパッケージはAuroraには存在しません。この問題を解決するには以下のことができます。
    • ランダム値の生成をアプリケーションコードに移し、それをパラメーターとしてファンクションに渡します。この変更は、変換前の移行元データベースまたは変換後の移行先データベースで行うことができます。
    • SCTで生成されたコードを、MySQLに存在するRAND()ファンクションを使うように変更し、新しいコードをAuroraデータベースに適用します。

その他の例として、一意の識別子を生成するためにOracleのシーケンスを使っているとします。Auroraはシーケンスをサポートしていないので、修正するために以下を実行してください。

  • 自動的に一意の識別子を生成するAuroraのauto-increment機能を使う。この方法で行く場合は、Auroraデータベースにスキーマを作成した後で、移行先のテーブルを変更するためのスクリプトを作成することをお勧めします。
  • 一意の識別を生成する何か別の方法(ファンクションや類似のもの)を作成し、シーケンスを参照している部分を新しいファンクションで置き換える。これは変換前に移行元のOracle上で実施することも、移行先のAuroraで実施することもできます。
  • 両方の手法を使う必要があるかもしれません。

一般的に、移行の一環としてSCTを使うための良い取り組み方には以下を含みます。

  • SCTアセスメントレポートを作成し、移行のギャップを埋める計画を立てる。もし移行候補となる複数のシステムがある場合は、どのシステムから最初に取り組むべきかの決定に役立ちます。
  • Action Items を確認し、変換に失敗した各項目の適切な処理を決定する。
  • 新しいAuroraデータベースに対してアプリケーションをテストしながら、AWS Database Migration Service と連携して新しいスキーマにデータをロードし、この処理を繰り返す

AWS DMS での移行手順

AWS DMS は移行元のOracleデータベースから移行先の新しいAuroraデータベースにデータをロードするときに使えます。DMSの素晴らしい点は、データを丸ごとロードすることに加えて、実行中のトランザクションをキャプチャして適用することです。カットオーバーの準備が整うまで、Oracleの移行元データベースとAuroraの移行先データベースを同期させつづけます。このアプローチによって、移行を完了させるために必要な停止時間を大幅に短縮することができます。DMSマイグレーションには、移行元エンドポイントであるOracle、移行先エンドポイントであるAurora、レプリケーションサーバー、タスクを含みます。

OracleからAuroraに移行するとき、既存データを移行し、進行中の更新をレプリケーションするタスクを構成したいでしょう。これにより、データ全体の移行中に実行されたトランザクションをキャプチャするようにDMSに指示します。データ全体がロードされると、DMSはキャプチャされたトランザクションの適用を開始し、OracleとAuroraのデーベースの同期を開始します。Auroraをカットオーバーする準備ができたら、アプリケーションを停止し、残ったトランザクションをDMSに適用させ、新しいAuroraデータベースに接続するアプリケーションを開始するだけです。

DMSを使用してOracleからAuroraに移行する場合、考慮すべき点がいくつかあります。

サプリメンタルロギング。 DMSが移行元のOracleから更新をキャプチャするにはサプリメンタルロギングを有効にする必要があります。詳細な手順については、DMSのマニュアルを参照してください。

DMSの3つのフェーズ。 データを移行し、進行中の更新をキャプチャするとき、DMSは3つのフェーズを経ています。

  • バルクロード: バルクロードフェーズで、DMSはn個のテーブルを一度にまとめてロードします。デフォルトでは n = 8 です。この値はDMSマネジメントコンソールまたは AWS CLI を利用して変更できます。
  • キャッシュされたトランザクションの適用: バルクロードフェーズにDMSは移行元データベースへの更新をキャプチャします。あるテーブルのバルクロードが完了すると、DMSはバルクロードの一部であるかのようにキャッシュされた更新をできるだけ速くそのテーブルに適用します。
  • トランザクションとしての適用: すべてのテーブルのバルクロードが完了すると、DMSはキャプチャされた更新を単一のテーブルの更新ではなく、トランザクションとして適用し始めます。

セカンダリインデックス。 状況によっては、性能上の理由からDMSのバルクロードフェーズにセカンダリインデックスを削除したくなるかもしれません。バルクフェーズ中にセカンダリインデックスの一部またはすべてを削除することを選ぶ場合は、移行を一時停止して、トランザクションとしての適用フェーズでそれらを追加しなおす必要があります。すべてのテーブルのフルロードが完了した後であれば、移行を安全に一時停止することができます。

外部キー、トリガーなど。 バルクロードはテーブル単位で行われるため、バルクロードやキャッシュされたトランザクションの適用フェーズでは移行先のAurora内の外部キーに違反する可能性があります。initstmt=SET FOREIGN_KEY_CHECKS=0 をAuroraエンドポイントの追加接続属性として加えることで、外部キー検査を無効にすることができます。一般的に、データのバルクロードを中断したり悪影響を与える可能性のあるものにどう対処するかの戦略を策定する必要があります。たとえば、問題を回避するために、移行のカットオーバーフェーズになるまでトリガーの実装を延期することができます。

データ型。 新しいデータベースエンジンに移行するときには、どのようなデータ型がサポートされているかと、移行元のデータ型を移行先の新しいデータ型にどう変更するかを理解することが重要です。これについては、移行元のOracleのデータ型移行先のAuroraのデータ型をマニュアルで確認すべきです。

性能。 移行の全体的な性能は、移行元のOracle内のデータ量、種類、分散に依存しています。 AWS Database Migration Service Best Practices ホワイトペーパーに移行性能を最適化するためのいくつかの推奨事項が載っています。

手順をおさらいすると、

  1. SCTアセスメントレポートを使用して課題の概要を知ることができます。Auroraへの移行候補が複数ある場合は、どれから最初に取り組むべきかの決定に役立ちます。
  2. 処理の前後に必要となるかもしれない移行手順を洗い出すために、DMSを使用して移行先スキーマの作成とロードを実践します。
  3. 移行先のシステムでアプリケーションをテストして、新しい環境で期待通りに動作することを確認します。負荷やネットワーク環境を含む本番環境と同等の構成でテストしてみてください。
  4. スキーマの生成、データのロード、後処理の手順の適用、移行元と移行先システムの同期、カットオーバーに必要な手順などの実際の移行を実践します。
  5. SCTもDMSをシステム全体を一度に移行することを求めません。システムを短期間で効率的に移行するため、また必要であれば再構築するために、これらのツールを使用することができます。

実際の移行を開始する前に、SCTとDMSの両方のドキュメントを通して読むことをお勧めします。また、Step-by-Step ウォークスルーAWS Database Migration Service Best Practices ホワイトペーパー を読むこともお勧めします。

ツールの使い方を知るためにサンプルデータベースを使用したいのであれば、AWS GitHub リポジトリ で見つけることができます。

この投稿は特定の状況に必要な可能性のあるすべての手順や考慮事項を解説するものではありませんが、SCTとDMSを使用してプロプライエタリなOracleデータベースの足かせをどう緩められるかについての良いアイデアを提供しました。それでは幸せな移行を!


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は How to Migrate Your Oracle Database to Amazon Aurora です。