Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

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 […]

Read More

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 […]

Read More

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 […]

Read More

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 の視点から見ると、クローンがファーストクラスデータベースであるということは重要なポイントです。スナップショット、バックアップ、モニタリングなど、他の […]

Read More

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 […]

Read More

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

Elastic Load Balancing(ELB)は、Auto ScalingとAmazon 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 […]

Read More

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チーム一同おまちしております。 – プロダクトマーケティングエバンジェリスト 亀田 治伸

Read More

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 […]

Read More

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 Beanstalk、AWS 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 […]

Read More

AWS OpsWorks Chef 12 stackでのApplication Load Balancerの利用

Elastic Load BalancingのApplication Load Balancer機能の利点を活かして、スケーラブルなアプリケーションを構築してみたいですか? Application Load Balancerを使えば、コンテンツベースのルーティングやHTTP/2、WebSocketプロトコルの機能を追加したり、コンテナや拡張メトリクスなどを追加することができます。 AWS OpsWorks Stackのユーザーから、レイヤーに新しいApplication Load Balancerをどのようにしたら追加できるかをAWSにご質問されていました。そこでAWSは、簡単にこれらを統合するためのChef 12のレシピのセットを開発し、オープンソースにすることを決めました。本記事ではOpsWorks StackにおけるChef 12 LinuxレイヤーでApplication Load Balancerと連携させるための手順を紹介します。 手順 特に記載がない限り、すべてのステップはOpsWorksコンソール内で完結されるものとします。 alb_supportレシピの概要 alb_support::attach_to_alb: こちらのレシピはApplication Load Balancerのターゲットグループにインスタンスをアタッチする実際の作業を行います。Setupライフサイクルイベントにより既存のが実行され、追加される必要があり、インスタンスがApplication Load Balancerにアタッチされる前にレシピが実行される必要があります。 alb_support::detach_from_alb: こちらのレシピはロードバランサーからインスタンスをデタッチします。Shutdownライフサイクルイベントにこちらのレシピを追加するようにしてください。Shutdownライフサイクルイベントにより実行される一連のレシピを実行後にこちらのレシピが実行され、こちらによりインスタンスはApplication Load Balancerからデタッチされ、コネクションはdrainされます。 alb_support:install および alb_support::uninstall_http_server: デフォルトのApplication Load Balancerのヘルスチェックをパスする簡単な方法、およびそのロードバランサーが想定した通りに動作していることを視覚的に示す方法として、AWSは80番ポートを使用するNGINXサーバをインストールおよびアンインストールして、デフォルトのテストページを提供するサンプルレシピも提供しています。 ステップ1:Application Load Balancerを作成する 80番ポートを使ってデフォルトのTCPリスナーとHTTPヘルスチェックをシンプルなALBを作成します。ターゲットグループにインスタンスを追加しないようにしてください。こちらはオープンソースのChefレシピによって処理されるためです。 ステップ2:Chef 12 stackを作成する 新しいChef 12 stackを作成します。必ずカスタムChef cookbooksの利用を有効にして、次の設定を行ってください。 Repository typeでは、Gitを選択します。 Repository URLでは、https://github.com/awslabs/opsworks-example-cookbooks を使用します。もし既に動作中のスタックがあれば、そのリポジトリからalb_cookbookをダウンロードして、ご自身のChefリポジトリにマージして、次のセクションを継続することができます。 ステップ3:stack内のインスタンスにElastic […]

Read More