Amazon Web Services ブログ

Amazon Lex ボットのスキーマを Alexa Skills Kit にエクスポート

Alexa スキルの作成プロセスをシンプルにするため、Amazon Lex チャットボットのスキーマを Alexa Skills Kit にエクスポートできるようになりました。

Amazon Lex が Amazon Lex チャットボットの定義を Alexa Skills Kit (ASK) に追加できる JSON ファイルとしてエクスポートできるようになりました。ASK にボットのスキーマファイルを追加すると、Amazon Echo、Amazon Dot、Amazon Look、Amazon Tap、Amazon Echo Show、Alexa を有効にしたサードパーティ製のデバイスで使用する Alexa スキルを構築できます。JSON 設定ファイルには発話、スロット、プロンプト、スロットタイプを含む Amazon Lex チャットボットの構造が含まれています。エクスポート機能は Amazon Lex チャットボットで Alexa スキルの作成プロセスをシンプルにすることができます。

Alexa スキルを作成するには、次のステップを実行して ASK ポータルにある Amazon Lex ボットの定義ファイルを使用できます。手順については次をご覧ください。

Amazon Lex コンソールから

  1. ボットの作成、構築、発行が完了したら開発したボットリストを含むページに戻ります。
  2. ラジオボタンを使ってエクスポートしたいボットを選択します。ボットを選択するとページ上部の [Actions] タブが有効になります。
  3. [Actions] タブのドロップダウンメニューの項目から [Export] を選択し、モーダルダイアログに従い [Alexa Skills Kit] をプラットフォームとして選択しバージョンを選びます。
  4. [Create] をクリックします。ボットスキーマの JSON ファイルを含む Zip ファイルが生成されます。

これで、Amazon Alexa スキルで Amazon Lex ボットスキーマを使う準備ができました。

(more…)

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石井・志村)

Deadline 10 – AWSでレンダリングファーム起動

Deadline Version10の発表に合わせて、セミナーを9/27に目黒にて開催いたします。奮ってご参加ください!
Thinkbox Deadline Version 10 発表セミナー (2017 年 9 月 27 日開催)

グラフィカルレンダリング処理は、embarrassingly parallel(驚異的並列)ともいわれる計算能力集約型のタスクです。 言い換えると、タスクを処理しているプロセッサの数とタスクを完了するのに必要な処理時間との間に、直線的な関係があることを意味します。 映画製作などのクリエイティブな取り組みでは、結果をより速くすることで創造性が高まり、フィードバックループが改善され、試行錯誤を繰り返す時間が得られ、より良い結果が得られます。 社内レンダリングファームを所有している場合でも、ピーク時にはより多くのコンピューティングパワーを確保するためにクラウドを活用することができます。 一度このような環境に慣れてしまうと、社内リソース、クラウドリソース、およびデジタルアセットをどのように統一的に管理していくかが次の課題になります。

Deadline 10

8/29、強力なレンダリング管理システムであるDeadline 10を発表しました。Deadline10では、買収したThinkbox Software社の技術をベースとし、シンプルな使いやすさはそのままに、既存のオンプレミスレンダリングをAWS クラウドへ拡張可能に設計されており、レンダリングファームに弾力性と柔軟性を提供します。これにより複数のAWSリージョンにまたがる大規模な分散ジョブを設定および管理することが可能になり、一般によく使われるDeadline for Autodesk 3ds Max, Maya, Arnold等のアプリケーションも弾力性に富んだusage-based(従量課金)で利用可能になり、Thinkboxマーケットプレイスから入手可能です。(訳注:現時点で3ds Maxは近日提供予定となっております)皆様はマーケットプレイスからソフトウェアライセンスを購入したり、既存のライセンスを使用したり、それらを一緒に使用することもできます。

Deadline 10は、EC2 スポットインスタンスへ入札を行うことでクラウドベースのコンピューティングリソースを取得可能です。これにより、あなたの想像力をそのまま形にするために、低コストでコンピューティング能力を提供します!
またDeadline 10は既存AWSアカウントを利用し、トラッキング用にEC2インスタンスにタグを付け、レンダリングを開始する前にローカルアセットをクラウドに同期させる機能をもちます。

クイック・ツアー

Deadline 10の画面にて、どのようにAWSを活用するのかを見てみましょう。AWSリソースを利用する機能であるAWSポータルは、 Viewメニューから利用できます。

最初のステップは皆様のAWSアカウントでログインすることです。

その後、AWS環境との接続に利用するコネクションサーバ、ライセンスサーバ、レンダリングセットを保管するためのS3バケットを設定します。

次に、Spot Fleetをセットアップし、各EC2インスタンスの1時間あたりの最大入札価格を設定し、ターゲット容量を設定し、目的のレンダリングアプリケーションを選択します。

もちろん、ご希望のEC2インスタンスタイプを選択いただくことも可能です。

レンダリング準備ができたら、「Start Spot Fleet」をクリックします。

これにより、スポットインスタンスの入札と管理のプロセスが開始されます。 実行中のインスタンスはポータルへ表示されます。

レンダリングパイプラインの進行状況を監視できます。

不要になれば停止することもできます。

Deadline 10は、Usage based license(従量課金ライセンス)で利用できるようになりました。従来のフローティングライセンスユーザーは新しいライセンスが必要です。年間デッドラインライセンスの価格は年間48ドルに引き下げられております。すでに以前のバージョンを使用している場合やライセンスオプション詳細については、お気軽にお問い合わせください。

Jeff
原文:Deadline 10 – Launch a Rendering Fleet in AWS(翻訳: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;

新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング

Elastic Load Balancing(ELB)は、Auto ScalingAmazon CloudWatchを含む3つの組みの一部としてローンチした2009年以来、AWSの重要な要素になっています。それから、私たちは多数の機能を追加し、そしてApplication Load Balancerをリリースしました。コンテナで稼働するアプリケーションに対するアプリケーションレベルでのコンテンツベースルーティングをサポートする様に設計されており、Application Load Balancer はマイクロサービス、ストリーミング、リアルタイムワークロードと相性が良いです。

長年にわたって、私達のお客様はあらゆる規模のwebサイトや、アプリケーションをサポートする為にELBを利用しています。1, 2台のT2インスタンス上で動くシンプルなサイトや、ハイエンドインスタンスで構成される大きなフリート上で動き大量のトラフィックを捌く複雑なアプリケーションにまで利用されています。ELBはバックグラウンドでトラフィックを監視し、需要に応じる様に自動的にスケールしています。このプロセスには、余裕をもったバッファが含まれていて、長年にわたってより迅速になりより反応性があがってきたことで、生放送やフラッシュセール、ホリデーシーズンををサポートするためにELBを利用しているお客様にとっても、よく動作します。しかしながら、リージョン間の瞬時のフェイルオーバーや急激なワークロードの変動(スパイク)などの状況では予想されるトラフィックの急増に対してELBをプリプロビジョニングをするようお客様と協力して対応してきました。

新しい Network Load Balancer

今日、新しいNetwork Load Balancer(NLB)を発表します。NLBは超低遅延で高いスループットを維持しながら利用者の努力なしに、秒間何百万リクエストを捌く様に設計されています。Network Load Balancerはターゲットグループやターゲットの完全なプログラム制御を含めて、Application Load BalancerとAPI互換性があります。最も重要な機能のいくつかは以下の通りです。

固定IPアドレス – 各Network Load Balancerは 各VPCサブネットの範囲に対して1つの固定IPアドレスを提供します。us-west-2aにあるサブネットにターゲットがあり、他のターゲットがus-west-2cのサブネットにあった場合、NLBは2つのIPアドレス(サブネットあたり1つ)を作成し管理します。そのIPアドレスに対する接続は そのサブネット内のインスタンス全体に分散します。さらに制御をするために、各サブネットに対して既存のElasticIPを割り当てることも可能です。IPアドレスを完全に制御することで、Network Load BalancerはIPアドレスを、DNSレコードやファイアウォールルールなどにハードコードされる必要がある場合でも利用可能です。

ゾーナリティ(Zonality) – サブネット単位のIP機能はパフォーマンスの向上により遅延を減少させ、アイソレーションとフォールトトレランスを通じて可用性を向上させ、Network Load Balancerの利用をクライアントアプリケーションから透過的にします。Network Load Balancerは、自動フェイルオーバーを可能にしながら、特定の送信元からの一連のリクエストを1つのサブネットのターゲットにルーティングします。

送信元アドレスの保持 – Network Load Balancerでは、到達コネクションのオリジナルの送信元IPアドレスと送信元ポートを維持するので、アプリケーションソフトウェアはX-Forwarded-Forやプロキシプロトコルや他のワークアラウンドをサポートする必要がありません。これは、VPC Security Groupsを含む一般的なファイアウォールルールをターゲット上で利用可能であることを意味しています。

長時間の接続 – NLBは組み込まれたフォールトトレランスによりコネクションを扱うため、NLBは何ヶ月も何年にもわたってオープンなコネクションを処理できるため、IoTやゲーム、メッセージングアプリケーションに最適です。

フェイルオーバーRoute53による ヘルスチェックによって、NLBはリージョン内およびリージョン間のIPアドレス間のフェイルオーバーをサポートします。(訳注: NLB単体では複数AZをサポートします)

Network Load Balancerの作成

EC2コンソールの画面を開き、Network Load Balancerを作成することができます。Load Balancers を選択し、Create Load Balancerをクリックします。

Network Load Balancerを選び、Createをクリックし、詳細を入力します。ターゲットVPCの各サブネットに対してElasticIPを選択することがで、Network Load Balancerにタグづけができます。

次にConfigure Routingをクリックし、新しいターゲットグループを作成します。名前を入力し、プロトコルとポートを選択します。トラフィックポートまたは代替に選んだポートに対するヘルスチェックも設定することができます。

Register Targetsとトラフィックを受けるEC2インスタンスをクリックし、 Add to registeredをクリックします。

全ての項目が問題無い事を確認し、Createをクリックします。

新しいLoad Balancerの状態はprovisioningで、1分程度の間にactiveに代わります。

テスト目的のために、コンソールからLoad BalancerのDNS名前を確認します。(通常はAmazon Route 53を使い、もっとわかりやすい名前を使用します。)

それから大量のトラフィックを送りました。(1秒か、2秒の間実行する事を意図していましたが、気をとられ、膨大な数のプロセスを生成してしまいました。これはうれしいアクシデントでした。)

$ while true;
> do
>   wget http://nlb-1-6386cc6bf24701af.elb.us-west-2.amazonaws.com/phpinfo2.php &
> done

もちろん、より規律あるテストではBees with Machine Gunsの様なツールを使用します!

トラフィックを流す様にするため少し休憩したのち、私のLoad BalancerのCloudWatchメトリックスを確認し、簡単に、突然のトラフィックの猛攻撃を処理することができたことを確認しました。

どの様な負荷をかけているか確認するために、EC2インスタンスをみました。(本当にうまくいったことがわかりました)

私の同僚達が私が実施したよりもより規律的なテストを実施しています。彼らはNetwork Load Blancerをセットアップし、それにはEC2インスタンスのオートスケールフリートを利用しました。彼らは数百台のEC2インスタンスにより構成される2番目のfleetをセットアップし、それぞれBees with Machine Gunsを実行し、非常に多数のリクエストとレスポンスサイズを生成する様に設定しました。秒間150万リクエストからはじめ、素早くダイアルを全部あげ、テストリソースの最大に達する前に、秒間300万以上のリクエスト、総帯域幅が30Gbpsに達しました。

Load Balancerの選択

いつものように、Load Balanerを選ぶ場合、アプリケーションの要求を考える必要があります。以下はいくつかのガイドラインです。

Network Load Balancer(NLB) – TCPトラフィックの負荷分散に理想的で、NLBは超低遅延を維持しながら秒間数百万のリクエストを取り扱う能力があります。NLBはAvailability Zone毎に1つの固定IPを使いながら、突発的で変動しやすいトラフィックパターンを取り扱う事に最適化されています。

Application Load Balancer(ALB) – HTTPおよびHTTPSトラフィックの高度なロードバランシングに理想的で、ALBはマイクロサービスやコンテナベースのアプリケーションを含むモダンなアプリケーションアーキテクチャをサポートする高度なリクエストルーティングを提供します。

Classic Load Balancer(CLB) – EC2 Classicネットワーク上に作成されたアプリケーションに最適です。

横並びでの比較には、Elastic Load Balancing Details の表を確認してください。

現在Classic Load Balancer を利用していて、Network Load Balancerに移行しようとしている場合には新しい Load Balancer Copy Utilityを確認してください。このPythonツールは既存のClassic Load Balancerと同じ設定でNetwork Load Balancerを作成する手伝いをします。また既存のEC2インスタンスを新しいload balancerに登録することもできます。

価格と利用状況

Application Load Balancerと同様に、価格はLoad Balancer Capacity Units、LCUに基づきます。費用はLCUあたり$0.006で、以下のディメンジョンの内、最も高い値に基づきます。

  • Bandwidth -LCUあたり1 GB
  • New Connections – LCUあたり800
  • Active Connections – LCUあたり100,000

ほとんどのアプリケーションは帯域幅バウンドで、Application またはClassic Load Balancerと比較すると
約25%のコスト削減(負荷分散について)になります。

Network Load BalancerはChina(Beijing)以外の商用リージョンの全てで利用可能で、AWS CloudFormation, Auto Scaling, Amazon ECSでもサポートされています。

Jeff;

原文: New Network Load Balancer – Effortless Scaling to Millions of Requests per Second (翻訳: SA浅野・岩永)

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;

AWS Tools for Visual Studio Team Servicesのご紹介

本日、Amazon Web Servicesは、AWS Tools for Microsoft Visual Studio Team Services(VSTS)を発表しました(訳注:原文のBlog記事は2017/8/15にポストされました)。 ツールは無料で使用することができ、Visual Studio Marketplaceで配布されます。 VSTS内とTeam Foundation Serverでホストされたビルドとリリースのパイプラインで、AWSサービスと対話するためにこれらのタスクを使用することができます。 例えばタスクを利用してAmazon S3バケットとの間でコンテンツをコピーしたり、パイプラインにタスクを追加してAWS Elastic BeanstalkAWS CodeDeploy、またはAWS Lambdaにビルド出力をデプロイしたりすることができます。 ツールはオープンソースとして提供されGitHubで公開されています。

この記事では、ツールのインストール方法、中に含まれるタスクの概要、セットアップを検証するための簡単なシナリオを実行し、いかに簡単に使使えるかを見ていきます。 後続の記事では、タスクの詳細とVSTSパイプラインでの使用方法について詳しく説明する予定です。

 

インストール

AWS Tools for Microsoft Visual Studio Team Servicesのインストールは素早くて簡単です! 最初にVisual Studio Marketplaceにアクセスしてください。 以下に示すように、ツールをインストールするには2つのオプションがあります。 オンラインのVSTSアカウントにインストールするか、ツールをダウンロードしてオンプレミスのTeam Foundation Serverインスタンスにインストールすることができます。

やることはこれだけです! これでこの拡張機能のタスクは、アカウントまたはオンプレミスのインスタンスで使用できるようになりました。この最初のリリースで提供されているタスクを簡単に確認してみましょう。 先に述べたように、続く記事ではこれらのタスクのいくつかをより深く見ていくことになります。

  • AWS CloudFormation Create/Update Stack: このタスクでは、テンプレートファイルとオプションのパラメータファイルを使用して、AWS CloudFormationでスタックを作成または更新できます。 タスクはスタックがすでに存在するかどうかによって、既存のスタックを更新するか、新しいスタックを作成するかを自動的に切り替えます。 どちらの「モード」かを選択する必要はないため、パイプラインでの使用が便利です。 テンプレートとパラメータファイルを選択するだけでなく、変更セットを使用してスタックを作成または更新することも、変更セットを自動的に実行するオプションを追加することもできます(正常に検証された場合)。 また「Execute Change Set」タスクを使用して、後から有効な変更セットを実行することもできます。
  • AWS CloudFormation Delete Stack: このタスクは名前またはIDで識別されるスタックを削除します。 新規のデプロイメントに伴う破壊と再構築のシナリオで、開発環境やテスト環境のスタックをクリーンアップするのに使用することができます。
  • AWS CloudFormation Execute Change Set:前述のように、「Create/Update Stack」タスクでは、変更セットを使用して変更を実行するオプションが提供され、セットが有効であればすぐに実行するか、またはこのタスクを後で使用して変更を実行できます。 変更セットと関連するスタックの名前を提供するとタスクが残りの処理を行いスタックが作成または更新の完了ステータスに達するのを待ちます。
  • AWS Elastic Beanstalk Deployment:このタスクを使用してWebDeployアーカイブを使用して従来のASP.NETアプリケーションをデプロイしたり、ASP.NET Coreアプリケーションをデプロイしたりすることができます。
  • AWS Lambda .NET Core Deployment:このタスクでは、スタンドアロンの関数またはサーバレスアプリケーションをAWS Lambdaにデプロイすることができます。 このタスクはAWS Visual Studio Toolkitと同じdotnet CLI拡張を使用するため、タスク内で使用可能なコマンドラインツールスイッチの完全なカスタマイズ機能が利用できます。
  • AWS Lambda Invoke Function:AWS Lambdaにデプロイすることに加えて、このタスクを使用してパイプライン内からLambda関数を実行するようにします。 関数の結果はパイプライン内の次のタスクが利用する変数に出力することができます。
  • AWS S3 Download:バケット名とオプションのキープレフィックスの組み合わせを使用して、このタスクは1つ以上のglobパターンのセットを使用して、Amazon S3バケットからパイプラインの作業フォルダにコンテンツをダウンロードできるようにします。 たとえばこれを使用してカスタムな静的コン テンツをビルドに挿入することができます。
  • AWS S3 Upload:AWS S3 Downloadタスクと同様に、このタスクではパイプラインの作業フォルダからバケットにコンテンツをアップロードするために、ソースフォルダ内で実行されるバケット名とglobパターンの組み合わせを取ります。
  • AWS Tools for Windows PowerShell Script:このタスクでは、Tools for Windows PowerShell(AWSPowerShell)モジュールのコマンドレットを使用するスクリプトを実行し、必要に応じてスクリプトを実行する前にモジュールをインストールします。
  • AWS CLI:このタスクでは、個々のAWS CLIコマンドを実行できます。 ただし、ビルドホストにAWS CLIをすでにインストールしている必要があります。

 

タスクの設定と利用

リリースに含まれるタスクについて少し理解できたので、パイプラインでAWS S3 Uploadタスクを使用する方法を簡単に見ていきましょう。 これはまたツールの設定の検証と、タスクに対する資格情報がどのように扱われるかを理解することにも繋がります。

このチュートリアルでは、ビルドおよび/またはデプロイするアーティファクトをフェッチする既存のビルドまたはリリース定義があると仮定しています。 ここでは単純に新しいタスクをパイプラインの最後に追加し、S3バケットにビルド済みまたはデプロイ可能な成果物をアップロードするように設定します。 先に進み使用するビルド定義を選択するか新しいビルド定義を作成します。 定義を選択したり作成したりしたら定義を編集するオプションを選択します。

次のスクリーンショットの例では、ASP.NET Coreプロジェクトの新しいビルド定義を作成することを選択しました。 リストされているタスクにはデフォルト値が割り当てられています。

1.  パイプラインにS3 Uploadタスクを追加
このチュートリアルでは、Publishタスクによって生成されたビルド出力を取得し、Amazon S3にアップロードします。 したがって既存のPublishとPublich Artifactsタスクの間に新しいタスクを挿入します。 これを行うには、[Add Task]を選択します。 右側のパネルで使用可能なタスクを利用可能なAWSタスクが現れるまでスクロールし、AWS S3 Uploadを指定します。そして「Add」を選択してビルド定義に追加します。

Publishタスクの直後に新しいタスクが追加されていない場合はそのタスクを所定の位置にドラッグします。 それから設定を開始します。

 

2. タスクの資格情報を設定

Amazon S3などのAWSサービスのリクエストを行うタスクでは認証情報を設定する必要があります。 Team Systemsの用語では、これらをサービスエンドポイントと呼びます。 AWSタスクは資格情報を提供できるようにAWSという名前のサービスエンドポイントタイプを提供します。 このタスクの資格情報をすばやく追加するには、AWS Credential ボックスの右側にある[+]アイコンをクリックします。

歯車のアイコンをクリックすると新しいブラウザページが開き、すべてのサービスエンドポイント(新しいAWSタイプを含む)を管理できます。 タスクで使用するために複数のAWS資格情報セットを設定する場合はこれを行います。

「+」アイコンをクリックすると、AWSキーを入力できるポップアップウィンドウが表示されます。

AWS CLIやAWS modules for PowerShellのようなAWS SDKやツールを使用するのに慣れているなら、ここでのオプションに慣れているかもしれません。それらのSDKやツールと同じように基本的にはAWSの認証情報を構築します。プロファイルには名前(この場合はConnection nameに入力された値)があり、これをタスク設定でこの資格情報のセットを参照するために使用します。 次に使用する認証情報のアクセスキーとシークレットキーを入力し後で利用するための名前を割り当て[OK]をクリックして保存します。 ポップアップが閉じ新しい資格情報が事前に選択されたS3 Uploadタスク設定に戻ります。

他のタスクで入力した資格情報を再利用することができます。 設定しているタスクの[AWS Credentials]リストで、資格情報を識別するために使用した名前を選択するだけです。

 

注意:

アカウントのルート資格情報を使用することはお勧めしません。 代わりに、1つ以上のIAMユーザーを作成し、それらの資格情報を使用します。 詳細については、「AWSアクセスキーを管理するためのベストプラクティス」を参照してください。

 

3. タスクオプションの設定

資格情報を設定して選択することで、タスク設定を完了できます。

  • us-east-1、us-west-2などバケットが存在する(または作成する)リージョンを設定します。
  • バケットの名前を入力します(バケット名はグローバルに一意でなければなりません)。
  • Source Folderは、アップロードするコンテンツを含むビルドエリア内のフォルダを指します。 Team Servicesにはハードコードされたパスを避けるために使用できるいくつかの変数が用意されています。このチュートリアルでは、Build.ArtifactStagingDirectoryという変数を使用することを選択します。これは、デプロイ先にプッシュされる前にアーティファクトがコピーされるエージェント上のローカルパスです。 完璧ですね!
  • Filename Patternsには、アップロードのためにソースフォルダの下のファイルを選択するために使用される1つ以上のglobパターンを含めることができます。 ここに示すデフォルトの値は、すべてのファイルを再帰的に選択します。複数のパターンを1行ごとに指定できます。 このチュートリアルでは、前のタスク(パブリッシュ)がビルドした結果を含むzipファイルを出力します。 これがアップロードされるファイルになります。
  • Target Folderは、アップロードされたすべてのファイルに適用されるバケットのキープレフィックスです。 これはフォルダパスのように考えることができます。 値を指定しないと、ファイルはバケットのルートにアップロードされます。 デフォルトでは、相対的なフォルダ階層は保持されます。
  • 最後に、設定できる追加オプションがあります:
    • Create S3 Bucket if it does not exist:バケットを作成できない場合、タスクは失敗します。
    • Overwirte(アドバンスドセクション内): これはデフォルトで選択されています。
    • Flatten folders(アドバンスドセクション内):これにより、ソースフォルダを基準にした各ファイルのパスが削除され、すべてのファイルがターゲットフォルダに直接配置されます。

 

4. ビルドの実行

設定された新しいタスクで、ビルドを実行する準備が整いました。 Save & Queueを選択します。

ビルド中、タスクはメッセージをログに出力します。

まとめ

ご覧のとおり、新しいタスクの使用は簡単です。 今後の記事では、いくつかのデプロイメントタスクとその使用方法の詳細について説明します。 私たちは、新しいツールの登場によってあなたが私たちと同じようにワクワクしていることを願っています。そして、VSTS環境でツールが役立つことがわかるでしょう。 GitHubリポジトリにフィードバックを提供して、今後の開発を支援してください!

 

謝辞

これらの新しいツールをVisual Studio Marketplaceに導入する際に、Visual Studio ALM Rangersの支援を頂きました。Visual Studio ALM Rangersのサポートに感謝します。

 

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