Category: General


Apache MXNetとApple Core MLを使った機械学習をiOSアプリケーションに組み込む

AppleのWWDC2017で発表されたCore MLを使えば、iOSやmacOS、watchOS、tvOSの開発者は、 自分のアプリケーションに機械学習モデルを簡単に統合することができるようになります。Core MLによって、開発者はほんの数行のコードを追加するだけで、インテリジェントな新しい機能をユーザに提供できるようになります。Core MLを使えば、モバイルアプリケーションの開発者が機械学習を簡単に利用出来るようになり、プロトタイプを素早く構築することが出来ますし、これまでのアプリよりもパワフルなアプリを開発するために、カメラやGPSなどの様々なセンサーを使用できるようにもなります。

MXNetコミュニティーのメンバー達(AppleやAWSの社員もcontributorとして活動しています)は、MXNetを使って作られた機械学習モデルをCore MLのフォーマットに変換するためのツールを作りました。このツールを使えば、 Appleのデバイス向けのアプリに機械学習を簡単に組み込むことが 出来ますし 、Deep Learningを組み込んだアプリケーションのための高速なパイプラインを手にすることになります。つまり、AWSクラウド上で スケーラブルかつ効率的に、MXNetを使用した分散モデルトレーニングを行なった結果を用いて,Apple デバイス上で高速な推論処理を行うことが可能となります。

この変換ツールのリリースをサポートするために、我々はcoolなiOSアプリケーションを構築することにしました。本アプリは、以前のAWS AI Blogの「AWS EC2上でのMXNetと Multimedia Commonsデータセットを用いた 画像の場所の推測」という投稿を参考にしています。この投稿では、LocationNetモデルを使って写真がどこで撮影されたのかを予測しています。

本記事では、MXNetのモデルからCore MLに変換するための環境の構築方法および、既存のモデルの変換方法 、変換したモデルをSwiftで開発したiOSアプリケーションにimportする方法について説明します。このアプリケーションは、写真の撮影場所を予測するモデルに写真を入力し、撮影場所をマップ上に表示します。実行環境としては、iOS 11 betaがインストールされたiPhoneなどの物理iOSデバイスをおすすめします。シミュレータを使う場合にはXCode 9.0 beta付属のシミュレータで試してみてください。

本記事の執筆時点では、Xcode9、iOS11、Core MLはまだbeta版のため、XcodeやiOSのダウンロードのためにはApple Developer Programアカウントが必要となります。2017年中にはすべてリリースされる予定なので、リリース後であれば、MacのApp StoreやiOSデバイスのSoftware UpdateからXcode9やiOS11を入手できるようになります。

MXNetと変換ツールのインストール

変換ツールはmacOS High Sierra 10.13 beta 8にインストールして動かしてみました。Core ML Modelを使った推論をせずに、変換ツールを動かすだけならmacOS El Capitan (10.11)以上であれば大丈夫です。

変換ツールを利用するにはPython2.7のインストールが必要です。

MXNet frameworkおよびmxnet-to-coreml toolをインストールするためには下記のコマンドを実行します。

pip install mxnet-to-coreml

MXNetモデルの変換

LocationNetモデルはp2.16xlargeのAmazon EC2インスタンス1台と、AWS Multimedia Commonsのデータセットの中のgeoタグの付いた画像を使ってトレーニングしています。これはMXNet Model Zooで一般に公開されています。

他のMXNetモデルと同様に、LocationNetも2個の要素を持っています。

  • モデル定義を含んだJSONファイル
  • パラメータを含んだバイナリファイル

まず、Amazon S3に格納されている .json model definition.params model parametersファイルをダウンロードしましょう。

加えて、GitHubリポジトリから、モデルのトレーニングに利用する位置情報を含んでいるgrids.txtファイルもダウンロードしましょう。このファイルはGoogleのS2 Geometry Libraryを用いたトレーニングデータから作られています。このテキストファイルの各行は、S2 Cell Token、緯度、軽度(例えば、8644b594 30.2835162512 -97.7271641272)の形式になっています。今回Swiftを使って作るiOSアプリケーションでは、S2 Cell Tokenの情報は利用せず、座標情報のみを利用します。

変換ツールのGitHubリポジトリで説明してあるように、モデルを変換してみましょう。

同じディレクトリにすべてのファイルをダウンロードした後、次のコマンドを実行します。

mxnet_coreml_converter.py --model-prefix='RN101-5k500' --epoch=12 --input-shape='{"data":"3,224,224"}' --mode=classifier --pre-processing-arguments='{"image_input_names":"data"}' --class-labels grids.txt --output-file="RN1015k500.mlmodel"

内部では、MXNetによってモデルが最初にロードされて、メモリ上に全体のsymbolic graphとして再形成されます。変換ツールはこのsymbolic graphの各オペレーターを、Core ML における等価な表現へと変換していきます.。変換ツールに与えたいくつかの引数はMXNetによってグラフを生成するために使われますが、その他の引数は特定の方法にて、Core MLの(ニューラルネットワークを通す前の)入力の前処理か、ニューラルネットワークの出力の処理かのどちらかに使われます。

変換ツールがモデルの多数のレイヤーを処理していることを確認できるでしょう。そして、SUCCESSという結果とともに、生成されたファイル名(この例ではRN1015k500.mlmodel)が確認できます。後の段階で、Xcodeプロジェクトにこのファイルをimportして利用します。

Xcodeがインストール済みであれば、このモデルファイルをダブルクリックすれば、このモデルファイルについての、サイズや名前、Swiftコード内で通常使用されるパラメータなどの情報を確認できます。

iOSアプリケーションのコードのダウンロードおよび設定

このサンプルiOSアプリケーションはmacOS Sierra 10.12.6のMac上でXcode 9 beta 6を使ってSwiftで開発されており、iOS 11 beta 8がインストールされたiPhone7にてテストされています。

我々はCore MLで画像を扱いやすくするために、Appleの新しいVision frameworkを利用することにしました。Vision frameworkは、 Core MLのモデルが要求するフォーマットおよびサイズに画像を自動で変換してくれます。このフレームワークはコンピュータ上で画像や映像を扱う際の課題に対して、一貫性のあるインターフェースおよび、各種機能(顔追跡や顔検出、ランドマークや文字検出、矩形検出、バーコード検出、オブジェクト追跡、画像登録)を提供します。

開始するために、次のリソースを使用しました。

では、アプリケーションをビルドしてみましょう。

GitHubリポジトリ(MXNet2CoreML_iOS_sample_app)からiOSのサンプルアプリケーションのソースコード をダウンロードします。

MXNet2CoreML.xcodeprojをXcodeで開きます。

下図のように、変換ツールで生成したファイル(RN1015k500.mlmodel)をXcodeプロジェクトのnavigatorにドラッグ&ドロップし、画面右下のTarget Membershipでチェックを入れます。

変換ツールをインストールせずに、iOSアプリケーションを試してみたい場合には、RN1015k500.mlmodelをアップロードしていますので、ダウンロードすれば、Xcodeプロジェクトのnavigatorにドラッグ&ドロップして利用可能です。

アプリケーションを実行してみましょう

前述したとおり、アプリケーションを実行する際には、iOS11(本記事の執筆時点ではβ版)をインストールした実機で実行することをおすすめしています。

Xcodeのシミュレータでも実行することが出来ますが、アプリケーションの実行速度やMAPの移動や拡大の際のアニメーションがイマイチな可能性があります。

次のスクリーンショットで示すように、iOSの実機でアプリケーションを実行するのであれば、Teamの設定をあなたのものに変更するのを忘れないでください。

前述したとおり、こちらの実行をするためにはApple Developer accountが必要となります。

iPhone上でアプリケーションをビルドして実行するためにplayを押下します。

アプリケーションがiPhoneにインストールされて、次の画面が確認できるはずです。

画面には3個のセクションがあります。

上部のセクションには世界のどこかで撮影された写真が表示されます。左右にスワイプすることでアプリケーションに組み込んである3枚の画像のうちの1枚が表示されます。これらの画像は人間が見れば比較的容易に場所を識別できます。しかし、 素晴らしいことに、このモデルはGPS情報が一切含まれていない画像データから非常に正確な位置情報を予測します!

中央のセクションでは、リアルタイムの推論結果を上位3位まで表示しています。実際には、モデルは何百という予測を出しますが、その中で上位3件のみを表示しています。

下部のセクションでは、モデルで予測した上位3位までの位置情報をインタラクティブなMAP上にPinで表示しています。拡大や移動などの操作も自由にできます。

スクリーンショット1:

スクリーンショット2:

まとめ

本記事では、AWS上でMXNetを使って洗練された機械学習モデルの構築とトレーンングが可能なこと、MXNetでトレーニングしたモデルをCore MLのフォーマットに変換ツールを使って変換可能なこと、そして、変換したモデルをXcodeに素早くimport可能なことを紹介しました。iOSやその他のAppleデバイス用のアプリで、新しく素晴らしい機能を試してみましょう。

次のステップ

自分のコンピュータに保存されている写真をこのアプリケーションで試してみたいのであれば、Xcodeプロジェクトのnavigatorから1.jpgを削除して、1.jpgにリネームした、あなたの写真をドラッグ&ドロップするだけで試すことができます。どうやってこの写真の予測をするのかはCore MLモデルについての部分で説明しました。

このサンプルアプリケーションに手を入れて、カメラ機能を実装することも出来ます。写真を撮影する機能を追加するか、カメラロールから読み出せる機能を追加することで、これから撮影する写真もしくは過去に撮影した写真に対してリアルタイムで位置の予測をすることが出来ます。

この記事からインスパイヤされて様々な活用方法を発見してもらえれば大変嬉しいです。 ご質問、ご意見、ご提案がありましたら、下記のコメント欄に投稿してください。

Have fun!

原文: Bring Machine Learning to iOS apps using Apache MXNet and Apple Core ML (翻訳: SA石井・志村)

Windows 向けの新しい Amazon EC2 Elastic GPU

本日、Windows 向け Amazon EC2 Elastic GPU の一般提供を発表しました。Elastic GPU はアプリケーションのグラフィックパフォーマンスを高速化するために Amazon Elastic Compute Cloud (EC2) インスタンスにアタッチできる GPU リソースです。Elastic GPU は Medium (1GB)、Large (2GB)、XLarge (4GB)、2xlarge (8GB) のサイズで提供されています。G3 または G2 (OpenGL 3.3 アプリケーション向け) といった GPU インスタンスタイプを使用する代わりとして、低コストで利用できるサービスです。Elastic GPU は様々なインスタンスタイプと使用することができ、アプリケーションに適切なコンピューティング、メモリ、ストレージバランスを選べるように柔軟性を提供しています。そして今日から Elastic GPU を us-east-1 と us-east-2 でプロビジョンできるようになりました。

Elastic GPU は eg1.medium で 0.05 USD/時間からご提供しています。1 時間 5 セントです。Elastic GPU を t2.medium (0.065 USD/時間) にアタッチすると、GPU を使用したインスタンスに毎時間支払う金額は 12 セント以下となります。これまでは、もっとも低価格なグラフィカルワークステーション (G2/3 クラス) のコストは 0.76 USD/時間でした。つまり、特定のグラフィカルワークロードを実行するための価格を 80% 以上削減できることになります。

Elastic GPU はいつ使うのか?

Elastic GPU はグラフィックの高速化に必要な少量または断続的な GPU のパワーを必要とするアプリケーションや、OpenGL のサポートに最適です。Elastic GPU は OpenGL 3.3 API スタンダードもサポートし、展開済み API サポートも近日中にリリースする予定です。

Elastic GPU はインスタンスのハードウェアの一部ではありません。代わりに、Elastic GPU でインスタンスを起動した時に作成したサブネットにある Elastic GPU ネットワークインターフェイスを介してアタッチされます。次のイメージは Elastic GPU がどのようにアタッチされるか示しています。

Elastic GPU はアタッチしているネットワークなので、アプリケーションをサポートできる適切なネットワークの帯域幅でインスタンスをプロビジョンすることが大切です。また、インスタンスセキュリティグループがポート 2007 でトラフィックを許可していることを確認することも重要です。

OpenGL API を使用できるアプリケーションであれば、Elastic GPU を利用することができます。Blender、Google Earth、SIEMENS SolidEdge などはすべて Elastic GPU で実行できます。Kerbal Space Program も実行できます。

いつ、そしてどのように Elastic GPU を使用できるのか分かったところで、インスタンスを起動して 1 つ使ってみましょう。

Elastic GPU の使用

まず、EC2 コンソールにアクセスし [Launch Instance] をクリックします。次に [Microsoft Windows Server 2016 Base] といった Windows AMI を選択します。次にインスタンスタイプを選択します。次に [Elastic GPU] セクションを選択したことを確認し、eg1.medium (1GB) Elastic GPU を割り当てます。

[Advanced Details] セクションでユーザーデータもいくつか入れます。Elastic GPU ソフトウェアをダウンロードしインストールするために、PowerShell の簡単なスクリプトを書きます。


<powershell>
Start-Transcript -Path "C:\egpu_install.log" -Append
(new-object net.webclient).DownloadFile('http://ec2-elasticgpus.s3-website-us-east-1.amazonaws.com/latest', 'C:\egpu.msi')
Start-Process "msiexec.exe" -Wait -ArgumentList "/i C:\egpu.msi /qn /L*v C:\egpu_msi_install.log"
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Program Files\Amazon\EC2ElasticGPUs\manager\", [EnvironmentVariableTarget]::Machine)
Restart-Computer -Force
</powershell>

このソフトウェアはすべての OpenGL API コールをアタッチした Elastic GPU に送ります。

次に、セキュリティグループで TCP ポート 2007 が VPC に公開されているか確認し、Elastic GPU がインスタンスに接続できるようにします。最後に [Launch] をクリックしてインスタンスと Elastic GPU がプロビジョンされるのを待ちます。インスタンスにアタッチできる別の SG を作成することが、これを実行する上で最適な方法です。

起動手順のアニメーションは下記をご覧ください。

また、次のような簡単なコールを使用して AWS CLI で起動することもできます。

$aws ec2 run-instances --elastic-gpu-specification Type=eg1.2xlarge \
--image-id ami-1a2b3c4d \
--subnet subnet-11223344 \
--instance-type r4.large \
--security-groups "default" "elasticgpu-sg"

そうすると、こちらの Elastic GPU のソフトウェアインストール手順を実行できます。

タスクバーで Elastic GPU のステータスをチェックすると、Elastic GPU が問題なく動作しアタッチされていることが分かります。

サービスに関するフィードバックがあれば、ぜひお知らせください。Elastic GPU でのエクスペリエンスをお知らせいただくには、GPU Status Box の左下端にある Feedback リンクをクリックしてください。

Elastic GPU の実演

これでインスタンスのプロビジョンと Elastic GPU のアタッチが完了しました。AWS の私のチームメイトが、素晴らしい 3D アプリケーションについて紹介するようにリクエストしていたのですが、Elastic GPU のことを最初に聞いた時に考えたのは Kerbal Space Program (KSP) のことだったので、ここで簡単にテストしてみようと思います。結局のところ、Jebediah Kerman をスペースで起動できないのなら、こうしたソフトウェアの意味は何なのでしょう?KSP をダウンロードし、 -force-opengl を起動パラメーターとして追加して、レンダリングに OpenGL を使用していることを確認します。下記で、私の中途半端なスペースシップの構築案を見ることができます。昔はもっと良いのを作れたのですが。劣化を伴うリモートデスクトッププロトコルを使用したネットワークにしては悪くないでしょう。

ロケット発射の写真をお見せしてもいいのですが、スケジュール外で起きた分解により地上から離陸しなかったのです。そういうことで、またいちからやり直しです。

当面は Amazon CloudWatch メトリクスをチェックし、その間にどれだけの GPU メモリを使用したか見ることができます。

パートナー、料金、ドキュメント

利用者の皆さんに優れたエクスペリエンスを提供していくため、ANSYS や Siemens といった 3D ソフトウェアパートナーは、Elastic GPU で OpenGL API を活用しようと、自社ソフトウェアの Elastic GPU の認定に現在取り組んでいます。パートナーシップの詳細についてはこちらをご覧ください。

Elastic GPU の料金についてはこちらをご覧ください。その他のドキュメントに関してはこちらをご覧ください。

さて、仮想ロケットを構築する用事がありますので今回はこの辺で失礼します。

Randall

Amazon Aurora の Fast Database Cloning

今回は、私が実に便利だと思う Amazon Aurora の機能、Fast Database Cloning について簡単にご紹介します。Aurora の基盤となる分散ストレージエンジンを利用して、データベースのコピーオンライトで素早く経済的にクローンを作成することができます。

私のこれまでのキャリアの中で、開発、実験、分析に使用するための代表的なデータサンプルを待つことに多くの時間を費やしてきました。たとえば 2 TB のデータベースがあった場合、タスクを行う前にデータのコピーの準備を待つのに何時間も掛かることがあります。RDS MySQL でさえ、スキーマの移行テストやいくつかの分析を行う前に、スナップショットコピーが完了するのを何時間も待つ必要があります。Aurora はこの問題を実に興味深い方法で解決しています。

Aurora の分散ストレージエンジンは、通常であれば実現が不可能なことをできるようにしたり、従来のデータベースエンジンでは経済的に難しいことを可能にします。各ページにポインタを作成することで、ストレージエンジンが Fast Database Cloning を有効にします。そして、ソース内のデータやクローンで変更を行うと、コピーオンライトプロトコルがそのページのコピーを新たに作成し、ポインタを更新します。つまり、これまで 1 時間を要した 2 TB スナップショットの復元タスクを約 5 分で完了することができるのです。そして、その時間の大半は新しい RDS インスタンスのプロビジョニングに費やされます。

同じストレージにポイントしているため、クローン作成の所要時間はデータベースのサイズによります。また、コピー全体ではなく変更を行ったページのストレージ分だけを支払うため、経済的にクローンを作成できます。データベースクローンは耐久性保証を含む通常の Aurora データベースクラスターです。

では、データベースのクローンを作成してみましょう。まず、Aurora (MySQL) インスタンスを選び [Instance Actions] で [create-clone] を選択します。

次にクローン名を 「dolly-the-sheep」 にし、プロビジョンします。

約 5 分半でクローンが利用可能になり、大規模なスキーマ変更をいくつか行ってもパフォーマンスへの影響は見られませんでした。Aurora チームが高速化した DDL オペレーションを有効にしているため、スキーマ変更自体は従来の MySQL で行うよりも早く完了することができました。自分で変更を追加していく間に他のチームメンバーにスキーマ変更をテストさせる場合は、これに続いてクローンのクローンを作成したり、クローンのクローンのクローン (など) を作成することもできます。RDS の視点から見ると、クローンがファーストクラスデータベースであるということは重要なポイントです。スナップショット、バックアップ、モニタリングなど、他の Aurora データベースがサポートする機能すべてを利用できます。

この機能を活用することで、あなたとチームが Amazon Aurora をベースにした実験やアプリケーション開発において大幅に時間とコストを節約できるようになると幸いです。この機能の詳細は「Amazon Aurora ユーザーガイド (Amazon Aurora User Guide)」をご覧ください。また「AWS データベースブログ (AWS Database Blog)」をフォローすることも強くお勧めします。Anurag Gupta 氏によるクォーラムと Amazon Aurora ストレージに関するブログ記事は特に興味深い情報です。

フォローアップの質問またはフィードバックがあれば、aurora-pm@amazon.com に連絡するか、こちらにコメントを残してください。皆さんからのご意見やご感想をお待ちしています。

Randall

IP アドレスから AWS とオンプレミスリソースを介したアプリケーションの新しい負荷分散

去年、新しい AWS Application Load Balancer について紹介した時に、それを使用して Layer 7 (アプリケーション) ルーティングを EC2 インスタンス、そしてコンテナで実行しているマイクロサービスに実装する方法も説明しました。

長期に渡る AWS への移行の一部として、ハイブリッドアプリケーションを構築しているお客様もいらっしゃいます。こうしたお客様からは、単一の Application Load Balancer を使用して既存のオンプレミスリソースと AWS クラウドで実行している新しいリソースの両方でトラフィックを分散させたいという声が寄せられています。また、別のお客様からは、2 つ以上の Virtual Private Clouds (VPC) に渡るウェブやデータベースサーバーにトラフィックを分散させたり、特定のポート番号を使用しながら特定の IP アドレスと同じインスタンスで複数のサービスをホストしたり、Server Name Indication (SNI) をサポートしないクライアントに IP ベースの仮想ホスティングを提供したいという声も寄せられています。さらに別のお客様からは、きめ細かなアクセス制御を実装するために複数のインターフェイスとセキュリティグループを使用しながら、同じインスタンス (場合によってはコンテナ内) でサービスの複数のインスタンスをホストしたいというリクエストも頂いています。

これらはハイブリッド、移行、災害復旧、オンプレミスのユースケースやシナリオといった幅広い状況で発生します。

IP アドレスへのルート
こうしたユースケースに対処するため、Application Load Balancer が直接 IP アドレスにトラフィックをルートできるようになりました。こうしたアドレスは ALB と同じ VPC、同じリージョンにあるピア VPC、ClassicLink を経由した VPC とリンクしている EC2 インスタンス、VPN 接続の反対側にあるオンプレミスリソース、または AWS Direct Connect 接続にある場合があります。

Application Load Balancer はすでにターゲットグループにターゲットをグループ化しています。今回のリリースの一部として、各ターゲットグループにターゲットタイプの属性が追加されました。

インスタンス – 以前と同様にターゲットは EC2 インスタンス ID を経由して登録されています。

ip – ターゲットは IP アドレスとして登録されています。ロードバランサーの VPC 内にあるターゲットのロードバランサーの VPC CIDR からの IPv4 アドレス、RFC 1918 範囲 (10.0.0.0/8, 172.16.0.0/12 と 192.168.0.0/16) からの IPv4 アドレス、ロードバランサーの VPC 外 (ピア VPC、EC2-Classic、Direct Connect または VPN で到達できるオンプレミスターゲットを含む) にあるターゲットの RFC 6598 範囲 (100.64.0.0/10) を使用できます。

各ターゲットグループにはロードバランサーとヘルスチェックの設定があり、従来と同様に CloudWatch にメトリクスを発行します。

AWS にアプリケーションを移行中の場合や AWS を使用して EC2 インスタンスでオンプレミスリソースを拡張したい場合、AWS とオンプレミスリソースの両方に渡りアプリケーショントラフィックを分散させる必要があります。そうするには、すべてのリソース (AWS とオンプレミス) を同じターゲットグループで登録し、ターゲットグループをロードバランサーと関連付けます。また、DNS ベースの加重ロードバランスを AWS とオンプレミスリソースで使用することもできます。この場合、AWS とオンプレミスリソースにそれぞれロードバランサーを 1 つずつあてがうといったように、2 つのロードバランサーを使います。アプリケーション A のバックエンドが VPC にあり、アプリケーション B のバックエンドがオンプレミスにある場合、別のターゲットグループで各アプリケーションにバックエンドを配置し、コンテンツベースのルーティングを使用して各ターゲットグループにトラフィックをルートすることができます。

ターゲットグループを作成する
Application Load Balancer を作成する時のプロセスの一部として、いくつかの IP アドレスへのトラフィックを送信するターゲットグループを作成する方法は次の通りです。名前を入力 (ip-target-1) しターゲットタイプに [ip] を選択します。

IP アドレスのターゲットを入力します。ロードバランサーをホストする VPC からのものを使用できます。

またロードバランサーをホストする VPC 外のターゲットには、上記のプライベート範囲の 1 つにあるプライベート IP アドレスを使うこともできます。

設定を確認しロードバランサーを作成するとヘルスチェックが終了次第、指定された IP アドレスにトラフィックが送信されます。各ロードバランサーは 1000 件までのターゲットに対応できます。

自分のターゲットグループを調べ、いつでも一連のターゲットを編集することができます。

ご覧のように、このスクリーンショットを撮った時はターゲットの 1 つのヘルス状態が悪かったことが分かります (意図的です)。各ターゲットグループのメトリクスが CloudWatch に発行されます。これがコンソールで表示され、CloudWatch アラームを作成することができます。

提供開始
この機能はすべての AWS リージョンで今すぐご利用いただけます。

Jeff;

Cloud Road Show(CRS)がはじまります

いよいよ、AWS Cloud Roadshow 2017 powered by Intel®が始まります。

AWS Cloud Roadshow 2017 powered by Intel® は、広島、大阪、名古屋、福岡の 4 都市を巡る無料クラウドカンファレンスです。

本イベントでは、各地域で活躍を拡げる著名企業様によるクラウド導入事例セッションや AWS クラウドの最新テクノロジートレンドをご紹介するテクニカルセッションなどを通して、AWS が提供する様々なサービスのベストプラクティスを知ることができます。

また最終セッションでは、JAWS-UG Nightとして、AWSユーザーグループ主催のイベントがあります。私も各会場のUG Nightで過去3か月のAWSのアップデート纏めをお話させていただく予定です。

会場では、弊社アーキテクトや営業による案件相談やアーキテクチャ相談も可能です。

またお申込み可能ですので、是非以下よりお申し込みください。

広島(9/8)

大阪(9/21)

名古屋(9/27)

福岡(10/31)

それではみなさんにお会いできることをAWSチーム一同おまちしております。

– プロダクトマーケティングエバンジェリスト 亀田 治伸

VMware Cloud on AWS – 利用可能になりました

昨年、VMware Cloud on AWS を構築するために VMware と一緒に行っている作業についてお話ししました。そこでご報告したように、これはお客様待望の、伸縮性とセキュリティを維持しながら VMware SDDC スタックをベアメタル AWS インフラストラクチャ上で直接実行する、ネイティブな完全マネージド型製品です。これにより、当社のセキュリティを最重視したアーキテクチャの基盤部分であるネットワーキングとシステムレベルのハードウェア機能はもとより、AWS のスケーラビリティと弾力性の利点を活かすことができます。

VMware Cloud on AWS では、お客様が習得済みの知識とすでにお持ちのものを活用できます。お客様の既存のスキル、トレーニングへの投資、運用経験、ソフトウェアライセンスへの投資は、パブリッククラウドに移行しても応用して適用できます。この移行の中で、データセンターの構築や運用、ハードウェアの近代化、一時的または短期の需要に合わせたスケーリングは忘れて構いません。また、AWS の膨大なコンピューティング、データベース、分析、IoT、AI、セキュリティ、モバイル、デプロイメントおよびアプリケーションの各サービスを利用できます。

初期提供
Early Access ベータプログラムで多くのお客様やパートナーからいただいたフィードバックを反映させて、本日、VMworld において、VMware および Amazon は VMware Cloud on AWS の初期提供を発表しました。最初は米国西部 (オレゴン) リージョンで VMware および VMware Partner Network のメンバーを通して提供されます。これは、データセンター拡張、アプリケーションのデプロイおよびテスト、アプリケーションの移行などの一般的なユースケースをサポートするようにデザインされています。

この製品の販売、配信、サポート、請求は VMware が担当します。この製品はカスタムサイズの VM をサポートし、VMware でサポートされている任意の OS を実行します。シングルテナントのベアメタル AWS インフラストラクチャを活用してお持ちの Windows Server ライセンスをクラウドに持ってくることができます。各 SDDC (Software-Defined Data Center) は 4 個から 16 個のインスタンスで構成され、各インスタンスは 36 個のコア、512 GB のメモリー、15.2 TB の NVMe ストレージを備えています。現行、クラスターは単一の AWS アベイラビリティーゾーン (AZ) で実行され、作業が複数の AZ に渡るクラスター内の作業がサポートされています。VMware SDDC 全体を 2 時間のうちに立ち上げることができ、ホスト容量を数分でスケールアップまたはスケールダウンできます。

NSX ネットワーキング・プラットフォーム (最大 25 Gbps で動作する AWS Elastic Networking Adapter 搭載) では、マルチキャストトラフィック、管理用とコンピューティング用の個別ネットワーク、およびオンプレミスファイアウォール、ルーターなどへの IPSec VPN トンネルがサポートされています。

次の図は、各部分がどのように連携するかの概要です。

現在ご使用の VMware およびサードパーティー製管理ツール (vCenter ServerPowerCLIvRealize SuitevSphere API と呼ばれるコード) は、既存のオンプレミスリソースと AWS で立ち上げるリソースを組み合わせたハイブリッド VMware 環境を構築するときも問題なく動作します。このハイブリッド環境では、新しい VMware Hybrid Linked Mode を使用して、オンプレミスとクラウドのリソースを統合した単一ビューが作成されます。お客様は使い慣れた VMware ツールを使用してアプリケーションを管理できます。新規またはカスタムのハードウェアを購入したり、アプリケーションを書き換えたり、運用モデルを変更する必要はありません。

お客様のアプリケーションやコードは、AWS のサービスすべてにアクセスできます (データベースサービス、分析サービス、AI サービスなどから始めるといいでしょう)。これらのサービスの使用は別途請求されるため、AWS アカウントを作成する必要があります。

詳細は VMworld で
ラスベガスで開催中の VMworld に参加している方は、90 以上の AWS のセッションをいくつかチェックしてみてください。

また、ブース #300 にぜひお立ち寄りください。AWS チーム一同がお待ちしています。

準備中
当チームは昨年から長い道のりをたどってきましたが、これからますますエンジンの回転を上げていきます。

VMware と AWS は今後も、アプリケーション移行、データセンター拡張、アプリケーションのテストとデプロイなど、新しい機能やユースケースのサポートを実現するために力を入れていきます。現在進行中の作業は、他の AWS リージョンの追加、災害対策やデータセンター統合などより多くのユースケースのサポート、認定の追加、AWS のサービスへのより深い統合の実現です。

Jeff;

【確定版】9 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー9月の配信について,ご案内させて頂きます。AWSのコスト最適化とリザーブドインスタンスについてのセミナーが追加になりましたので、改めて最新版の配信予定についてお知らせいたします。

 

9月の開催予定

サービスカット

9/6(水) 18:00-19:00 Amazon AppStream 2.0
9/13(水) 18:00-19:00 Amazon Aurora
9/19(火) 18:00-19:00 AWS DMS
※通常とは異なり、火曜日開催となりますのでご注意ください。
9/27(水) 18:00-19:00 Amazon CloudFront + AWS Lambda@Edge

ソリューションカット

9/5(火) 12:00-13:00 AWSでのDDoS対策
9/12(火) 12:00-13:00 AWSのコスト最適化/リザーブドインスタンス

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

AWSと.NET Core 2.0

昨日、.NET Core 2.0がリリースされ(訳注:このブログ記事の原文は2017/8/15に発行されています)、AWSでは .NET Coreプラットフォームに追加された新機能と完成度にとても興奮しています。今後数か月以内に、AWSサービスをアップデートして、.NET Core 2.0のファーストクラスのサポートを提供します。 2つの簡単な方法ですぐにAWS上で.NET Core 2.0を使い始めることができます。

 

AWS Elastic Beanstalkの利用

Elastic Beanstalkを使用すると、Webアプリケーションを簡単に展開できます。現在、.NET Frameworkおよび.NET Core 1.1がサポートされています。 Elastic Beanstalkプラットフォームは、すぐに.NET Core 2.0をサポートするように更新されるでしょう。 それまではデプロイメントパッケージをカスタマイズして、デプロイ中のインスタンスに.NET Core 2.0をインストールするようにBeanstalkに指示することができます。

ASP.NET CoreアプリケーションがBeanstalkにデプロイされると、AWS-windows-deployment-manifest.jsonというJSONマニフェストがツールキットによって作成され、Beanstalkにアプリケーションのデプロイ方法を指示します。 以前のブログ記事では、このマニフェストのカスタマイズ方法について説明しました。 この機能を使用して、デプロイ前にPowerShellスクリプトを実行して.NET Core 2.0をインストールすることができます。

最初のステップとして、ASP.NET Core 2.0プロジェクトにaws-windows-deployment-manifest.jsonというファイルを追加します。 aws-windows-deployment-manifest.jsonのプロパティウィンドウで、[Copy to Output Directory]フィールドを必ず[Copy Always]に設定してください。 このファイルは、通常、ツールキットによって生成されますが、ツールキットがファイルがすでに存在することが判明した場合は、代わりにデプロイメントウィザードで指定された設定で既存のファイルを変更します。

 

次に、下の内容をコピーしてaws-windows-deployment-manifest.jsonに貼り付けます。 これはASP.NET Coreアプリケーションをデプロイし、デプロイの前に./Scripts/installnetcore20.ps1 PowerShellスクリプトを実行することを示しています。

 

{
  "manifestVersion": 1,
  "deployments": {

    "aspNetCoreWeb": [
      {
        "name": "app",
        "parameters": {
          "appBundle": ".",
          "iisPath": "/",
          "iisWebSite": "Default Web Site"
        },
        "scripts": {
          "preInstall": {
            "file": "./Scripts/installnetcore20.ps1"
          }
        }
      }
    ]
  }
}

PowerShellスクリプトを追加するためのマニフェストを追加しました。 ASP.NET Coreプロジェクトに./Scripts/installnetcore20.ps1ファイルを追加します。 再度、[Copy to Output Directory]フィールドを[Copy Always]に設定して、デプロイメントパッケージに追加されていることを確認してください。 以下のスクリプトは、.NET Core 2.0インストーラをダウンロードし、インストーラを実行します。

 

$localPath = 'C:\dotnet-sdk-2.0.0-win-x64.exe'

if(!(Test-Path $localPath))
{
    Invoke-WebRequest -Uri 'https://download.microsoft.com/download/0/F/D/0FD852A4-7EA1-4E2A-983A-0484AC19B92C/dotnet-sdk-2.0.0-win-x64.exe' -OutFile $localPath
    & $localPath /quiet /log c:\InstallNetCore20.log
}

 

このスクリプトでは、Microsoftの公式リンクから.NET Core 2.0をダウンロードしています。 デプロイ中のダウンロードを高速化し、リンクの変更の影響を受けないようにするために、.NET Core 2.0インストレーションをElastic Beanstalk環境と同じリージョンにあるAmazon S3バケットにコピーすることをお勧めします。

デプロイメントマニフェストのカスタマイズにより、ASP .NET Core 2.0アプリケーションをElastic Beanstalkに簡単にデプロイできます。

 

Dockerベース サービスの利用

Amazon EC2 Container ServiceやAWS CodeBuildなどのDockerコンテナを実行するDockerベースのサービスについては、Docker Hubに発行されたDockerイメージを使用してすぐに開始できます。 たとえばコンソールでAWS CodeBuildプロジェクトを設定するときに、Docker HubからカスタムのDockerイメージを指定することができます。

 


.NET Core Dockerイメージの詳細については、GitHubリポジトリを参照してください。 AWSでDockerコンテナを実行する方法の詳細については、「Amazon ECS入門」を参照してください。

 

AWS SDK for .NET

.NET Core 2.0は.NET Standard 2.0をサポートしています。つまり、.NET Standard 2.0とそれ以下を対象とするNuGetパッケージは.NET Core 2.0でサポートされています。 AWS SDK for .NETは.NET Standard 1.3をターゲットとしています。このことはつまり、.NET Core 1.xまたは.NET Core 2.0の両方で利用できることを意味しています。

 

結論

.NET Core 2.0とAWSについて最新の情報を入手するには、AWS .NET開発ブログをフォローし、Twitterで私たちのツイートを見つけてください

 
(日本語翻訳はSA 福井が担当しました。原文はこちらです。)

オートメーションを活用したCloudEndureによるAWSへの容易な移行

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。

オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。

オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。

ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式(リフト&シフト)に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。

ソリューションの概要

このブログ記事で説明するソリューションでは、CloudEndureAWS Database Migration Service(AWS DMS)を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス(Gogs)の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。

CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。

CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。

移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。

次の図は、この記事で取り上げる移行プロセスを示しています。

プロセスの仕組みは次のとおりです。

  1. Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。
  2. AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。
  3. CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。
  4. CloudEndureが初期同期を完了すると、Continuous Data Protection(CDP)エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 (この変数は、CloudEndureダッシュボードにインスタンス名として表示されます)。
  5. CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。
  6. CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。
    1. DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。
    2. Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。

      "Message": "{"instanceId": " i-0bb669daff4b1eea1","Pass": "True"}"

    3. CloudEndure Lambda関数は、CloudEndure Pass / Fail SNSトピックに登録されています。ラムダ関数は成功メッセージを探します。成功メッセージを受信すると、着信インスタンスIDに基づいてAmazon Machine Image(AMI)を作成し、AMI情報をAmazon SQSに送信します。 CloudWatchでLambda関数のステータスを追跡できます:
  7. CloudEndure.pyスクリプトは、移行されたインスタンスに関するメッセージをSQSキューに常にポーリングします。メッセージを受信すると、AMIが準備完了であるかどうかを確認します。準備ができたら、スクリプトはGogs CloudFormationテンプレートを起動し、AMI IDをパラメータとして渡します。 CloudFormationテンプレートは、次のような高可用性環境を展開します;

始めましょう

移行プロセスの仕組みが分かりましたので始めてみましょう。まず、CloudEndureでアカウントを設定する必要があります。アカウントをお持ちでない場合は、AWS SaaSサブスクリプションマーケットプレイスのCloudEndure Migration製品ページで登録できます。[1]

アカウントを設定し、CloudEndureのウェブサイトのスタートガイドに従ったら、以下のファイルに慣れておく必要があります。完全な解決策はGitHub上でより詳細に説明されています。

Ansibleプレイブック、変数、ファイル:

  • playbooks/files/CloudEndure.sh  – このファイルはCloudEndureが移行後のスクリプトを実行する/ boot/ce_conversionにデプロイされます。 GogがRDSを指すように再構成し、サービスをテストするために使用されます。
    • reinvent-ent312-source-instances.yml CloudFormationテンプレートは、このファイルのすべてのent312.five0.ninja
      を、Auto Scalingを使用して高可用性のGogs環境用のELBロードバランサを指し示すAmazon Route 53ドメインエイリアスに置き換えます。この値は、CloudFormationテンプレートのGogsDNSパラメータを介してテンプレートに渡されます。
  • playbooks/cloudendure_agent_install.yml
    • einvent-ent312-source-instances.yml CloudFormationテンプレートは、CloudEndure UserNameとパスワードをCloudEndureUserとCloudEndurePasswordのCloudFormationテンプレートのパラメータに基づいて、この「AnEure Playbook」の「Install CloudEndure」セクションに設定します。

CloudEndure.pyスクリプトで使用される移行スクリプトconfig.yml:

ファイルを編集して、次の情報を入力します。

  • username – CloudEndureのユーザー名
  • password – CloudEndureのパスワード
  • hosttomigrate – CloudEndureダッシュボードで移行するホストの名前。 CloudEndureが最初のレプリケーションプロセスを開始するまで、この値はダッシュボードで使用できません。
  • stackname –CloudFormationスタックの名前。 CloudFormationスタックに名前を付けるときに、CloudEndureBlogDemoのデフォルト値を変更することを選択した場合にのみ、これを変更してください。
  • keypairname – Gogs自動スケーリングスタックを起動するためのキーペア
  • gogsdns – Gogs自動スケーリング用にELBロードバランサにマップするRoute 53ドメインエイリアス

CloudFormation テンプレート:

  • reinvent-ent312-migrated-gogs.template
    • この値は、Gogs自動スケーリングのELBロードバランサにマップするRoute 53ドメインエイリアスです。パラメータGogsDNSNameは、CloudEndure.pyスクリプトの実行時にconfig.ymlのgogsdns値に基づいて渡されます。

AWS CloudFormationを使用してソリューションをデプロイする

次に、移行を詳しく見て、各ステップを実行してみましょう。このデモンストレーションでは、CloudFormationテンプレートは、AWSアカウントの別個の仮想プライベートクラウド(VPC)でソース環境を紡ぎ出し、同じアカウント内の宛先VPCに移行します。

まず、AWS CloudFormationテンプレートをAWSアカウントに展開する必要があります。
テンプレートをダウンロードして、独自の実装の出発点として使用することもできます。

テンプレートの選択」ページで、テンプレートURLのデフォルト設定を維持し、「次へ」を選択します。

デフォルトのスタック名のままにするか、スタックの名前を入力し、下のスクリーンショットごとに値を入力します。

Gogsを構成する際に必要なため、ソースデータベースのユーザー名とパスワードに設定した値に注意してください。次の2つの画面で「次へ」および「次へ」を選択し、「AWS CloudFormationがカスタム名でIAMリソースを作成する可能性があることを確認します」というチェックボックスをオンにして、「作成」を選択します。

CloudFormationがアカウント内のリソースを作成するまでには数分かかります。 {YourStackName} -SourceInstanceResourcesがCREATE_COMPLETEとマークされたスタックが表示されたら、ログインしてGogsを設定できます。

CloudFormationで作成したカスタムDMSタスクは、Gogs DBが存在するかどうかによって異なりますので、CloudFormationスタックが完了する前にGogsをインストールして設定する必要があります。 (この執筆時点では、CloudFormationはDMSリソースをサポートしていませんが、移行の特定の側面について自動化を構築するための具体的な方法の1つを示したいと思います。)

スタックの[出力]タブで、AnatileSourceInstanceを見つけます。 SSHを次のコマンドで値を使用してインスタンスに追加します。

ssh -i {KeyPairYouAssociatedWithTheStack}centos@{ValueFromAnsibleSourceInstance}

インスタンスにSSHしたら、次のコマンドを実行して、更新とCloudFormationのユーザーデータステップが完了していることを確認します。

sudo tail -f /var/log/cloud-init.log

クラウド・イニシエータがインスタンスのブートストラップを終了すると、以下のようなメッセージが表示されます。

Mar 7 18:30:29 ip-10-10-138-101 cloud-init: Cloud-init v. 0.7.5 finished at Tue, 07 Mar 2017 18:30:29 +0000. Datasource DataSourceEc2. Up 369.01 seconds

これでインスタンスへのキーペアを追加する必要があります。そのため、SSHを使用してソースインスタンスに使用したり、Gogを構成したりすることができます。ローカルマシン上で、鍵ペアを保存したディレクトリから、次のコマンドを使用して秘密鍵をクリップボードにコピーします。

cat {KeyPairYouAssociatedWithTheStack}.pem | pbcopy

Ansibleソースインスタンスで、次のコマンドを実行します。

vi key.pem

プライベートキーをviウィンドウに貼り付け、ファイルを保存します。次に、次のコマンドを実行してアクセス許可を変更します。

chmod 400 key.pem

次のコマンドを実行して、ssh-agentが有効になっていることを確認します。エージェントpidを受け取る必要があります(たとえば、Agent pid 417)。

eval `ssh-agent`

ssh-agentにSSH鍵を追加し、空のパスフレーズを入力するためにEnterキーを押します。

ssh-add key.pem 
今度は、あなたのソースGogs DBをAnsible経由でプロビジョニングできます:

ansible-playbook -i playbooks/hosts playbooks/database_provision.yml

ソースのGogsインスタンスをプロビジョニングします。

ansible-playbook -i playbooks/hosts playbooks/gogs_provision.yml

GogsがAnsible経由で設定されると、ログイン環境でGogsをログインして設定することができます。 CloudFormationのSourceInstanceResourcesスタックのOutputsタブにGogsSourceInstanceの値が必要です。

http://{ValueFromGogsSourceInstance}:3000

「Gogsのユーザーパスワード」フィールドに、CloudFormationのソースデータベースのユーザー名とパスワードから前述した値を入力します。

Gogsであなたの選択したユーザーとパスワードを登録することができます。このデモンストレーションの後半に注意してください。

CloudFormationのDMSスタックが完了したら、セットアップを調べることができます。レプリケーションインスタンスが表示されます。

送信元と宛先の両方のエンドポイントも表示されます。

データベース同期を実行するタスクも表示されます。

DMSの検証が終了したら、AnatileSourceInstance SSHウィンドウに戻り、次のコマンドを実行してApplication Discovery ServiceとCloudEndureをインストールします。

ansible-playbook -i playbooks/hosts playbooks/aws_cli_ads_agent_install.yml

ansible-playbook -i playbooks/hosts playbooks/cloudendure_agent_install.yml

CloudEndureダッシュボードにログインすると、サーバーが表示されます。 CloudEndureはAWSへの最初のブロックレベル同期を完了する過程にあるため、テストの準備が整っている、と表示されるまでに時間がかかることがあります。

CloudEndure DashboardのINSTANCE NAMEの値は、config.ymlファイルのhosttomigrate変数に設定する必要がある値です。
CloudEndure.pyスクリプトを実行して、移行を初期化します。

python scripts/CloudEndure.py

スクリプトの出力例を見るには、READMEを見てください。

スクリプトが終了すると、Lambda関数から作成されたAMIを使用して、AutoScalingと共に高可用性Gogs環境が表示されます。

高可用性のGogs環境がヘルスチェックに合格し、ELBロードバランサの背後でサービスを受けるには数分かかりますが、最終的には、ソース環境で作成したユーザー名を使ってサインインし、RDSを使用するように設定された移行済みGogs環境にアクセス可能です。これは、DMSタスクが移行元GogsデータベースをRDSに移行するのに成功したことを証明します。

サマリー

この記事では、オンプレミス環境からAWSへの移行をスピードアップするために、自動化とテストをツールキットに組み込む方法を示しました。慎重な計画と構成では、移行シナリオ全体で再利用できる一連のツールが用意されています。これにより、ワークロードをより迅速に移行できるようになり、移行後に期待どおりアプリケーションが動作しているという確信が得られます。

 

このブログの内容は、第三者の製品を推奨するものではありません。このブログは情報提供を目的としています。

[1]このブログ記事の手順に従う際に発生した費用については、あなたが責任を負います。

(翻訳は諸岡が担当しました。原文はこちら)

 

9 月の AWS Black Belt オンラインセミナーのご案内

【注意】セミナーの実施日程について更新がありました.最新の実施日程は,こちらをご覧ください.

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー9月の配信についてご案内させて頂きます。ソリューションカットでは、AWSにおけるDDoS対策について、サービスカットでは、BlackBelt初開催となる、AppStream2.0や、多くの機能アップデートが行われたサービスを中心にお送りいたします。

 

9月の開催予定

サービスカット

9/6(水) 18:00-19:00 Amazon AppStream 2.0
9/13(水) 18:00-19:00 Amazon Aurora
9/19(火) 18:00-19:00 AWS DMS

※通常とは異なり、火曜日開催となりますのでご注意ください。
9/27(水) 18:00-19:00 Amazon CloudFront + AWS Lambda@Edge

ソリューションカット

9/5(火) 12:00-13:00 AWSでのDDoS対策

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