Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

柔軟性の高いディープラーニングのために簡単に使用できるプログラミングインターフェイス Gluon のご紹介

本日は、AWS と Microsoft が、どのディープラーニングフレームワークを選択するかにかかわらず、すべての開発者向けに機械学習テクノロジーの速度、柔軟性、アクセス性を向上させることを主眼とした新しい仕様を発表しました。この連携による最初の結果が、新しい Gluon インターフェイスです。これはあらゆるスキルレベルの開発者がディープラーニングモデルのプロトタイプ作成、構築、トレーニングを行えるようにする、Apache MXNet のオープンソースライブラリです。このインターフェイスにより、トレーニング速度を犠牲にすることなく、ディープラーニングモデルの作成プロセスを大幅に簡略化できます。 Gluon の 4 つの重要な利点と、それを示すサンプルコードを示します。 (1) シンプルで理解しやすいコード Gluon では、シンプル、明瞭、簡潔なコードを使ってニュートラルネットワークを定義できます。事前定義されたレイヤー、オプティマイザ、イニシャライザを含む、プラグアンドプレイのニュートラルネットワーク構築要素のフルセットを入手できます。これにより、基盤となる複雑な実装詳細の多くが排除されます。次の例では、わずか数行のコードでシンプルなニュートラルネットワークを定義する方法を示しています。 # 最初のステップはモデルの初期化です net = gluon.nn.Sequential() # Then, define your model architecture with net.name_scope(): net.add(gluon.nn.Dense(128, activation=”relu”)) # 最初のレイヤー – 128 ノード net.add(gluon.nn.Dense(64, activation=”relu”)) # 2 番目のレイヤー – 64 ノード net.add(gluon.nn.Dense(num_outputs)) # Output layer 次の図に、ニュートラルネットワークの構造を示します。 詳細については、こちらのウォークスルーに移動して、Gluon ニュートラルネットワーク構成要素を使って multilayer perceptron (MLP) と呼ばれるシンプルなニュートラルネットワークを作成する方法を参照してください。より高度なユースケース向けに、ニュートラルネットワークのパーツをゼロから作成することも簡単です。Gluon […]

Read More

AWS支払の円払いへの切り替え方法について

先日のCloud Roadshow 2017 広島、名古屋、大阪では、KeyNoteの中でAWSの円払い対応および日本準拠法対応についてみなさんにご案内いたしました。本ブログの中で2回連載という形でそれぞれ、支払方法の円対応、日本準拠法切り替えについてご案内をいたします。 実は、AWSの支払い通貨変更機能は、2015年2月にお客様からのご要望受けて実現してる機能ですが、新しくAWSのご利用をご検討いただいている皆様に改めてお伝えしたいこと、また管理者画面のデザイン変更などで過去ブログで記載された手順と少し変更が入っているため、改めてみなさんにその特徴・注意点と手順を共有させていただきます。 [特徴] 管理者画面での変更だけで切り替え作業が完了します 対応しているクレジットカードはVISAとMasterカードです MarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます AWS内部ではドルで計算され、月末の利用料集計時に、その時点でのAWSが定めるレートをもとに円に自動計算されます 月額のAWSご利用額がドル換算で過去3か月平均が2000ドル以上ある場合は、請求書切り替えも可能となります。 請求書払いもクレジットカードと同様にMarketplaceでAMI形式で有償EC2インスタンスを設定している場合、その部分だけ引き続きドルで請求されます [手順] それでは手順についてみていきましょう。まず管理者画面にログインしてください。トップページがでてきます。 右上のアカント名が、みなさんが設定を行おうとしているアカウント名が正しく表示されていることを確認してください。なお、AWSマネージメントコンソールはアカウント開設時期や設定状態などで異なるデザインが表示される方もいらっしゃいますが、エラーではありませんので安心してください。 右上のアカウント名を選択してください。 アカウントを選ぶと以下の画面が出てきます。 オレンジ色の箇所にはみなさんのアカントに登録された情報が出てきます。左側の「お支払方法」を選択してください。 お支払いに使用されているクレジットカード情報が表示されます。その右上にUSDとなっている箇所がありますのでそちらをクリックしてください。 「お支払通貨の設定」の右側にある「編集」を選んで通貨を選んでください。 全部で13種類の通貨が選べるようになっています。日本円の場合はJPYを選んでください。以上で切り替えは終わりです。作業を行った月のAWS利用分から支払通貨変更が反映されます。 [請求書払いへの切り替えについて] 請求書払いへの切り替えの場合、AWSの月額ご利用額がドル換算で過去三か月の平均が2000ドル以上であれば、サポートセンターで「新規ケースの作成」をクリックし、「アカウントおよび請求サポート」まで変更をご依頼ください。 2000ドルに満たないが、今後ご利用予定がある場合は、担当アカウントマネージャへのご連絡、もしくはこちらからご連絡ください。 -プロダクトマーケティング エバンジェリスト 亀田  

Read More

Amazon Redshiftに新世代のDC2ノードが追加 – 価格はそのままで最大2倍の性能向上

Amazon Redshiftは高速で完全マネージド型のデータウェアハウス(DWH)です。ペタバイト級までスケールアウトが可能であり、Amazon Redshift Spectrumを利用することでAmazon S3上に保存されたエクサバイト級のデータにロード無しでクエリを実行することも可能です。 Amazon Redshiftがリリースされた当初からご利用いただいている方であれば、当初はHDD搭載のDW1と呼ばれるノード1種類しか無かったことをご記憶かと思います。続いてSSDを搭載した新しいノード追加され、DW1(HDDベース)とDW2(SSDベース)の2タイプから選択可能になりました。 その後、DW1の後継がリリースされる際にHDDベースはDense Storage (DS) に、SSDベースはDense Compute (DC)とそれぞれの特性を表した名前に整理され、DS1(旧DW1)の後継としてDS2がリリースされました。DS2リリース時のブログエントリはこちらにありますが、その登場はDS1ユーザから驚きをもって迎えられました。DWHとしての性能が大きく向上しつつ、ノードの価格は据え置きだったからです。 次はDense Compute (DC)の番です。DC2が本日より利用可能になりました! 第二世代のDense Computeノード DC2はDC1の後継となるノードであり、高いスループットと低いレイテンシを必要とするDWHワークロードのために設計されています。CPUはIntel E5-2686 v4(Broadwell)になり、高速なDDR4メモリを搭載。ストレージはNVMe接続のSSDです。 私達はAmazon Redshiftがこのより高速なCPU、ネットワーク、ストレージの性能をDC2で十分に発揮できるようチューニングを行い、結果としてDC1との同一価格構成での比較で最大2倍のパフォーマンスを発揮しています。DC2.8xlargeノードではスライスあたりで2倍のメモリを搭載しており、ストレージレイアウトの改善によって30%多いデータが保管できるようになりました。これらの改善がされた新世代のノードを旧世代と同じ価格で提供します。 DC2.8xlargeではパフォーマンスを最大化するためにスライス数が変更されています。旧世代のDC1.8xlargeでは1ノードあたり32スライスでしたが、DC2.8xlargeでは16スライスに変更されています。DC2.largeはDC1.largeと変わらず1ノード2スライスのままです。 このため、DC1.8xlarge (もしくはDS)からDC2.8xlargeへ移行するためにはクラスターのリサイズが必要になります。DC1.largeからDC2.largeへの移行については、リサイズもしくはDC1で取得したスナップショットからの作成が可能です。 本日より利用可能です DC2ノードはUS East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific […]

Read More

Build an Autonomous Vehicle on AWS and Race It at the re:Invent Robocar Rally

自動運転車は近い将来に車道を埋め尽くすことが見込まれています。ディープラーニングと自動運転のアプリケーションの進歩がこの自動運転車を実現しました。このポストでは、Amazon AI サービスを活用したリモートコントロール (RC) 自動車を製作する方法のチュートリアルを紹介していきます。 通常、各自動運転車には高度なテレメトリを提供する多くのセンサーが搭載されています。このテレメトリは、個々の自動車の運転と共に、ユーザーエクスペリエンスを向上するために使用できます。こういった向上の例には、スマートドライブルーチングによる時間の短縮、車両航続可能距離と効率の向上や安全性とクラッシュリポートの増大などがあります。AWS では、TuSimple などのカスタマーが Apache MXNet を使用した繊細な自動化プラットフォームを構築しました。最近では、TuSimple が 200 マイルドライバーレス運転を成功しました。 ディープラーニング、AWS IoT と人工知能 (AI) の技術による運転の認知を目的として、AWS はワークショップ形式のハッカソンである Robocar Rally を re:Invent 2017 で開催します。このポストは、開発者を対象に自動化 AI 技術を学習し、ハッカソンに備えるためのブログポストと Twitch ビデオシリーズの第 1 弾となります。ハッカソンについての詳細は、Robocar Rally 2017 をご覧ください。 このチュートリアルでは、Donkey という名称のオープンソースプラットフォームを活用します。希望する場合には、お手持ちの 10 分の 1 スケールの電気自動車で体験することもできます。ただし、Donkey プロジェクトで使用される 16 分の 1 スケールの RC カーの使用がより推奨されます。 次の 2 本のビデオでは、これから説明するチュートリアルを使用して AWS で製作した 2 台の自動車を紹介しています。 […]

Read More

Using Amazon Polly to Provide Real-Time Home Monitoring Alerts

このブログは、Y-cam Solutions のシニア開発者である Siva K. Syamala によるゲストブログポストです。Syamala 女史の言葉によると、「Y-cam は高性能なセキュリティビデオソリューションのプロバイダとして、すべての人々に簡単で扱いやすいスマートホームセキュリティを提供してくことをビジョンに掲げています」。 ホームセキュリティは、ホームオートメーションと IoT の活用においてとても重要な要素です。Y-cam Solutions Limited は Amazon をその基盤援助として、世界各地からスマートフォンによるモニタリングと制御ができるスマートセキュリティシステムを提供してきました。アラート、通知、そしてシステムをコントロールする方法を改善するために、Y-cam は Amazon Polly を使用して、ユーザーが会話によってセキュリティシステムと交信できる最新型の AI サービスを提供します。 当社サービスの作動方法 アラームが発生すると、Twilio を通じて音声によるカスタマーへの通知が行われます。呼び出しが確立されたら、Twilio は TwiML の指示に従って手順を実行し、Amazon Polly から取得する音声構成を使用してカスタマーにストリーミングを開始します。呼び出しの受信者は、携帯電話のキーパッド (DTMF コード) のボタンを押して回答します。DTMF コードによって、当社のサービスは指定されたアクションを実行し、Amazon Polly から取得する音声合成への TwiML 指示を返します。実際により近い会話を実現するには、Amazon Polly が素早く返答することがとても重要となります。遅延と待機時間は不満を引き起こし、受信者が電話を終了してしまう可能性を増大させます。 以下は、アラームが発生した場合のカスタマーへの通話を示すオーディオクリップのサンプルです。 アーキテクチャ   Amazon Polly の呼び出し 次の Java コードは、Amazon Polly から音声合成がリクエストされ、S3 バケットに保存されることを示しています。

Read More

利用可能になりました – Amazon Linux AMI 2017.09

Amazon Linux AMI の最新バージョン (2017.09) が、すべての AWS リージョンの現行世代の EC2 インスタンスで利用可能になったことをお知らせします。AMI には、EC2 上で実行するアプリケーションのために安定した安全で高性能な環境を提供するように設計された Linux イメージのサポートと保持が含まれています。 簡単なアップグレード 次の 2 つのコマンドを実行して既存のインスタンスをアップグレードし、再起動します。 $ sudo yum clean all $ sudo yum update 盛りだくさん AMI には多くの新機能が含まれており、そのうち多くはお客様のリクエストに応えて追加されたものです。概要は次をご覧ください。 Kernel 4.9.51 – Based on the 4.9 の安定したカーネルシリーズをベースにしたこのカーネルには、ENA 1.3.0 ドライバーと TCP Bottleneck Bandwidth and RTT (BBR) のサポートが含まれています。私の投稿 Elastic Network Adapter – High-Performance Network Interface for […]

Read More

Step Functions を使用するともっとうまくできます

私はよく Amazon のイノベーション文化についてプレゼンテーションを行いますが、Amazon の創設者 Jeff Bezos の意義深い引用を取り上げたスライドから始めることが多くあります。 お客様にお会いして、私たちがお客様の創造性や夢の追及をどのように支援できているかについて知るのは楽しいものです。今年に入って、Coca-Cola Company の Patrick と歓談し、AWS Step Functions や他の AWS のサービスを使用して Coke.com の Vending Pass プログラムをサポートした方法を教えてもらいました。このプログラムでは、Coca-Cola Vending Pass を使用したモバイル支払いをサポートしている自動販売機で製品を購入することで、ドリンクがプレゼントされます。参加者が NFC 対応電話をスワイプすると Apple Pay または Android Pay で購入が完了し、自動販売機で個人が識別されてクレジットを獲得できます。このクレジットを貯めることで、将来自販機で無料で購入できます。 スワイプ後、SNS トピックと AWS Lambda 関数の組み合わせにより既存のバックエンドコードに対する 1 組の呼び出しが開始され、販売ポイントがカウントされて参加者の記録が更新されます。残念ながらバックエンドコードは反応が鈍く多少のタイミング依存性があり、更新が行われず Vending Pass 利用者が混乱する可能性がありました。この問題に対する初期のソリューションは非常にシンプルでした。Lambda コードを変更して 2 つの呼び出しの間に 90 秒間のディレイを含めたのです。これにより問題は解決しましたが、処理時間がかかるのはいいことではありませんでした (Lambda 関数の使用料金は 100 ms 間隔のリクエスト所要時間に基づいています)。 ソリューションの費用対効果を向上させるため、チームは AWS […]

Read More

Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ

本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。 Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見することがあります。これは問題になっているコードの変更を探すことを困難にし、不必要なストレージ料金も引き起こします。以前は、レポジトリをクリーンアップするには、手動で古いイメージを削除するのに時間を費やしたり、スクリプトを書いて実行する必要がありました。 今日からライフサイクルポリシーを使うことで、古いコンテナイメージを自動的に削除するためのいくつかのルールを定義することが可能になりました。ルールが実行された時に影響を受けるコンテナイメージを実際にプレビューで確認することも可能です。これによって、レポジトリはより組織化され問題になっているコードのリビジョンを簡単に見つけられ、そしてストレージコストも抑えられます。 それでは、ライフサイクルポリシーがどのように動くかを見てみましょう。 基本的なルール コンテナを使ってコードをデプロイすることの最も大きい利点の1つは、素早く簡単に過去のバージョンにロールバックできるということです。これにより、リスクを抑えてデプロイすることが可能になります。なぜならば、もし何かおかしかったら、過去のコンテナのバージョンに戻して、失敗したデプロイ以前の状態でアプリケーションを動作させることが簡単にできるからです。多くの人は、数個前のバージョンにロールバックするということはおそらくしないでしょう。もしこういった状況であれば、1つのシンプルなライフサイクルルールとしては、最新の30イメージを保持するというものが考えられます。 最新の30イメージ ECRレジストリの中から、Dry-Run Lifecycle Rules, Addを選択します。 Image Statusには、Untaggedを選択します。 Match criteriaでは、Count TypeにImage Count More Thanを入力します。 Count Numberには30を入力します。 Rule actionにはexpireを選択します。 Saveを選択します。どのイメージがクリーンアップされるかを見るには、Save and dry-run rulesを選択します。 もちろん、数による保持ではなく、コンプライアンスの理由で期限によっていくつかのイメージを保持したいチームも存在します。そういった場合には、90日以前のイメージをクリーンアップするという選択もできます。 最新90日分 先程作成したルールを選択し、Editを選びます。パラメータを変更して、タグがついていないイメージを90日だけ保持する様に変更します: Match criteriaでは、Count TypeにSince Image Pushedを入力します。 Count Numberには90を入力します。 Count Unitにはdaysを選択します。 タグ もちろん90日というのは任意の時間に設定できますが、ある特定の種類のイメージだけもっと長い期間保持するようなポリシーが必要なこともあります。そういった場合で、でも大掃除は続けたいというときには、タグがつけられたイメージだけ削除するというのを検討することも可能です。 こちらのルールのリストは、タグが無いもの、development、staging、そしてproductionなイメージへのルールの例をまとめてみたものです: タグのないイメージは90日以前を削除 developmentタグのついたイメージは90日以前を削除 stagingタグのついたイメージは180日以前を削除 productionタグのついたイメージは1年以前を削除 ご覧頂いた通り、新しいAmazon ECRのライフサイクルポリシーは強力で、必要なイメージだけを保持するのが簡単になり、もう必要のないイメージをクリーンアップしてくれます。この機能は本日よりAmazon […]

Read More

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。 もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。 TLS? SSL? SNI? SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。 TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。 SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。 フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。 ALBの証明書スマートセレクション ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択し、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。 ALBでSNIを利用する ここではウェブサイトの例として、VimIsBetterThanEmacs.comとVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。 最初に、コンソールから私のロードバランサを選択し、listenerタブに行き、”view/edit cerfiticates”を選択します。 次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。 これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。 aws elbv2 add-listener-certificates –listener-arn <listener-arn> –certificates CertificateArn=<cert-arn> 知っておくべきこと ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。 […]

Read More

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

こんにちは。ソリューションアーキテクトの岡本です。AWS Black Belt オンラインセミナー11月の配信についてご案内させて頂きます。初めてご紹介するNLB (Network Load Balancer) を中心としたELBのセッションをはじめ、今月も様々なテーマを取り扱います。 また今年もAWS re:Inventの開催期間中に現地からの生中継で最新アップデートをお伝えする回を予定しておりますので、こちらもぜひご登録いただければと思います。                   11月の開催予定 サービスカット 11/1(水) 18:00-19:00 Amazon EMR 11/15(水) 18:00-19:00 ELB Update – Network Load Balancer(NLB)と関連サービス 11/22(水) 18:00-19:00 AWS WAF – OWASP Top10脆弱性緩和策 – ソリューションカット 11/9(木) 12:00-13:00 Amazon Pinpoint で始めるモバイルアプリのグロースハック  ※ 通常の開催曜日と異なりますのでご注意ください 11/21(火) 12:00-13:00 AWS上の位置情報 12/1(金) 12:00-13:00 AWS […]

Read More