Amazon Web Services ブログ

Apache MXNet バージョン 0.12 で Extends Gluon 機能を拡大、最先端の研究をサポート

先週、Apache MXNet コミュニティが MXNet バージョン 0.12 をリリースしました。このバージョンの主な機能は NVIDIA Volta GPU と Sparse Tensor のサポートです。同リリースには Gluon プログラミングインターフェイスの新機能がいくつも含まれています。こうした機能は特にディープラーニングモデルにおける最先端のリサーチを実装しやすくします。 変分ドロップアウトは、オーバーフィッティングをリカレントニューラルネットワーク (RNN) に移行するために使うドロップアウト技術を効率的に適用できるようにします。 畳み込み RNN、Long short-term memory (LSTM)、Gated Recurrent Unit (GRU) セルは、時間ベースのシーケンスと空間ディメンションの両方を示すデータセットのモデリングを可能にします。 7 つの新しい損失関数、エクスポート機能、トレーナー機能の強化 変分ドロップアウト (VariationalDropoutCell) は最近のリサーチを足掛かりにして、RNN のオーバーフィッティングを移行させる新たなツールを提供しています。これは「リカレントニューラルネットワークのグランデッドアプリケーションの推論 (“A Theoretically Grounded Application of Recurrent Neural Networks”)」と「RNNDrop: ASR における RNN の新しいアプローチ (“RNNDrop: A Novel Approach for RNNs in ASR”)」を基盤にしています。オーバーフィッティングは、モデルがトレーニングデータセットに近すぎた状態でフィットしていることで発生するモデリングエラーです。そのため、新しいデータまたはテストデータセットが表れた場合に予測精度が低下してしまいます。ドロップアウトはランダムにモデルパラメータをゼロにするモデリング技術です。そのため、トレーニング中にモデルが必要以上に 1 […]

Read More

Apache MXNet リリースに追加された新しい NVIDIA Volta GPU と Sparse Tensor のサポート

Apache MXNet バージョン 0.12 が利用可能になりました。MXNet コミュニティに参加している貢献者の方々との協力により、強化点を追加する新機能の提供を実現することができました。今回のリリースでは、MXNet に 2 つの重要な機能が追加されています。 NVIDIA Volta GPU のサポートにより、ユーザーはトレーニングやニューラルネットワークモデルの推論に掛かる時間を大幅に削減することができます。 Sparse Tensor のサポートにより、ユーザーは保存とコンピューティングを効率的にした方法で Sparse マトリックスを使用しモデルをトレーニングすることができます。 NVIDIA Volta GPU サポートのアーキテクチャ MXNet v0.12 リリースには NVIDIA Volta V100 GPU サポートが追加されています。これにより、ユーザーは畳み込みニューラルネットワークのトレーニングを Pascal GPU に比べて 3.5 倍も速くすることができます。ニューラルネットワークのトレーニングには、数兆にもなる浮動小数点 (FP) 倍数や追加が関係しています。通常、こうした計算には高精度にするため単精度浮動小数点 (FP32) が使われます。けれども、最近の研究結果によると、ユーザーがトレーニングで浮動小数点を半精度 (FP16) にしたデータタイプを使用しても、FP32 データタイプを使用したトレーニングと同じ精度を実現できることが分かっています。 Volta GPU アーキテクチャが Tensor Core を導入しました。各 Tensor Core は 1 時間ごとに 64 fuse-multiply-add […]

Read More

新しい – AWS Direct Connect Gateway – リージョン間の VPC アクセス

今回のブログの準備をしている時に、2012 年に公開した懐かしいブログ記事を読み返してみました。これは AWS Direct Connect のリリースについて紹介したものです。エンタープライズをご利用されているお客様達から、プライバシーの強化やデータ転送の帯域幅の追加、より予測可能性に優れたデータ転送パフォーマンスを実現するため、AWS リージョンに専用接続を確立できるようにしたいというリクエストを受け、Direct Connect を提供するに至りました。当初は AWS リージョン 1 か所と 1 つのコロケーションから始まりましたが、現在ではすべてのパブリック AWS リージョンでその利用が可能となり、世界中に散在する多数のコロケーションからアクセスできるようになりました (合計 60 か所のロケーション)。当社のお客様には Direct Connect を全面的にご活用いただいており、その後も Link Aggregation、Amazon EFS サポート、CloudWatch モニタリング、HIPAA の適格性といった機能を追加しました。過去 5 週間だけでも、Direct Connect ロケーションをヒューストン (テキサス)、バンクーバー (カナダ)、マンチェスター (英国)、キャンベラ (オーストラリア)、パース (オーストラリア) に追加しました。 そして現在は、Direct Connect Gateway を追加することで Direct Connect をよりシンプルに、そしてさらにパワフルにするよう努めています。また、すべてのリージョンにおいて Direct Connect をご利用のお客様が、当社のグローバル IP ルートを受信するパブリック仮想インターフェイスを作成したり、当社サービスのパブリックエンドポイントへのアクセスの有効化、Direct Connect の価格モデルの更新などを行えるようにしています。 では詳しく見てみましょう。 新しい […]

Read More

98、99、100 か所の CloudFront 接続ポイントを提供

9 年前のことになりますが「Amazon CloudFront でコンテンツを分散させるには (Distribute Your Content with Amazon CloudFront)」というブログを書いたことがあります。2008 年のリリース以来、14 の接続ポイントで始まった CloudFront は急速な拡大を遂げてきました。そして本日、100番目の接続ポイントを東京で 5 番目の、そして日本で 6 番目の接続ポイントとして提供を始めました。89 か所のエッジロケーションと 11 か所のリージョン別エッジキャッシュを備えた CloudFront は、世界中の何百万ものユーザーが生成するトラフィックをサポートするようになりました。 23 か国、50 都市、今後もさらに増加 100 か所の接続ポイントは世界中の 23 か国 50 都市で展開されています。過去 12 か月間に渡りネットワークサイズを 58% 拡大、次の 9 都市を含む 37 か所の接続ポイントを追加しました。 ベルリン (ドイツ) ミネアポリス (米国ミネソタ) プラハ (チェコ共和国) ボストン (米国マサチューセッツ) ミュンヘン (ドイツ) ウィーン (オーストリア) クアラルンプール (マレーシア) フィラデルフィア […]

Read More

AWS HIPAA 利用資格の更新 (2017 年 10 月) – 16 の追加サービス

「医療顧客の事例 (Health Customer Stories)」 ページでは、AWS で実行するヘルスケアやライフサイエンスのアプリケーションを構築し実行している数多くのお客様の中から数件をご紹介しています。Verge Health や Care Cloud、Orion Health といったお客様は、HIPAA や HITECH の規制に準拠する取り組みの一環として、保護されるべき医療情報 (PHI) や個人識別情報 (PII) において AWS に信頼を寄せています。 その他 16 のサービス 前回の「HIPAA 利用資格の更新 (HIPAA Eligibility Update)」と題したブログでは、HIPAA 利用資格サービスのリストに 8 つのサービスを追加したことについてお知らせしました。そして本日、それに加え 16 のサービスをリストに追加し、ご利用可能なサービスの合計数はこれで 46 件になりました。次に、今回追加したサービスの簡単な概要と過去のブログ記事へのリンクをご紹介します。 PostgreSQL と互換性を持つ Amazon Aurora – Amazon Aurora に追加したこのサービスは、AWS Key Management Service (KMS) で作成し管理するキーを使用してリレーショナルデータベースを暗号化できるようにします。Amazon Aurora データベースで暗号化を有効にすると、基盤となるストレージが暗号化されます。また、自動バックアップやリードレプリカ、スナップショットにおいても同様です。詳しくは「Amazon Aurora の保管時の暗号化 (Read New […]

Read More

Amazon CloudWatch で GPU 使用率をモニタリング

GPU には何千ものコアがあるため、ディープラーニングには大量のマトリックス乗算と GPU (グラフィックス処理ユニット) により並列化できるベクトルオペレーションが必要です。アマゾン ウェブ サービスでは P2 または P3 インスタンスにサインアップすることが可能です。このようなインスタンスは、大規模なディープニューラルネットワークのデプロイの加速化を強調する MXNet のようなディープラーニングフレームワークの実行に優れています。 データサイエンティストや開発者はネットワークを微調整する場合、適切なバッチサイズを使用できるように GPU 使用率を最適化したいと考えています。今回のブログでは、Amazon CloudWatch メトリクスを使用して GPU とメモリ使用量をモニタリングする方法をご説明します。Amazon マシンイメージ (AMI) では、インスタンスが Amazon Deep Learning AMI を使用することを勧めています。 GPU を有効にしたインスタンスのモニタリングや管理をサポートするために使用されている現在の一般的な方法は、コマンドラインユーティリティの NVIDIA システム管理インターフェイスを利用することです (nvidia-smi)。nvidia-smi の使用により、ユーザーは GPU 使用率、メモリ消費量、ファンの使用量、電力消費量、そして NVIDIA GPU デバイスの温度などの情報をクエリすることができます。 nvidia-smi は NVIDIA 管理ライブラリをベースにしているので (NVML)、C ベースの API ライブラリを使用し、カスタムメトリクスとして Amazon CloudWatch に送信するのと同じデータポイントをキャプチャできます。このライブラリに関する詳細については「リファレンスマニュアル (reference manual)」をご覧ください。このブログではライブラリに Python ラッパーの pyvnml を使用します。 […]

Read More

AWS がエモリー大学とのコラボレーションを通じ、Apache MXNet を活用したクラウドベースの NLP 研究プラットフォームを開発

自然言語処理 (NLP) は、コンピュータプログラムに人間の言語 (自然言語) を理解させるという、人工知能の研究分野のひとつです。NLP についてあまりご存じない方でも、日々の生活の中でこれを使っている可能性は高いでしょう。携帯電話の仮想キーボードで文字入力を行う際、入力内容の分析結果に基づき、次に打ち込むべきであると予測される単語がリスト表示されます。これは言語モデリングと呼ばれ、入力された単語にどの単語が続くかの確率をその内容に基づいて測定する技術であり、NLP の中核的タスクのひとつです。NLP はすでに多くのアプリケーションに採用されており、世の中を大きく変えつつあります。 エモリー大学の NLP 研究グループである Evolution of Language and Information Technology (ELIT) チームは、研究者たちに最先端の NLP と機械学習テクノロジーをもたらす取り組みを行っています。ELIT プロジェクトは、AWS クラウドの豊富なリソースを活用し、ビッグデータ解析に向けたスケーラブルなエンドツーエンドの NLP パイプラインを提供することに主眼を置いています。他の多くの NLP フレームワークとは異なり、ELIT はウェブ API をサポートすることで、プラットフォームに依存しない体制を実現しています。そのお陰で、研究者たちはいつでもどこでも大規模なコンピューティングを利用できます。また、ELIT プロジェクトは、GitHub にも参加しています。これは、エモリー大学の NLP 研究グループが AWS の MXNet チームとの緊密なコラボレーションの下で立ち上げたサービスです。今回のブログ投稿では、ELIT のプラットフォームをご紹介するとともに、そこで活用されているウェブ API や、NLP の可視化についてもご説明します。 ELIT の研究用プラットフォーム 近年、NLP においてディープラーニングが盛んに活用され始めた結果、機械学習に基づく NLP モデルには多大な計算処理能力が要求されるようになり、研究者たちは強力なマシンなしには NLP の最新技術をフル活用できなくなっています。AWS のようなクラウドコンピューティングプラットフォームは、研究者たちがこれらのモデルを実行できるよう、無制限のコンピューティングリソースを提供します。しかしこれは、クラウドにさほど通じていない方々にとっては面倒でもあるでしょう。そこで ELIT プロジェクトが目指すのは、NLP のためのウェブサービスを提供し、インターネット接続さえあれば誰でもリクエストを行えるようにすることです。つまり、ローカルインストールは不要ですし、クラウドコンピューティングに関する予備知識も必要ありません。では、感情分析などの一般的な NLP […]

Read More

Amazon Rekognition とグラフデータベースを使って映画スターのソーシャルネットワークを理解する

Amazon Rekognition は、イメージの分析をアプリケーションに簡単に追加できるようにする AWS サービスです。ディープラーニングを活用したこのコンピュータビジョン向け API に追加された最新機能が、有名人の認識です。この使いやすい機能は、各分野の有名人や著名人を多数検出、認識します。このツールにより、ユーザーは自身の関心に基づいて有名人のデジタルイメージライブラリのインデックスを作成し、検索することができます。 当社のお客様が個人に関するデータの保存に用いる一般的な方法の 1 つが、グラフデータベースです。過去のブログ投稿で詳しく説明したとおり、Facebook や LinkedIn、Twitter といった企業は巨大な関係性ネットワークの管理能力を通じ、社会が相互に関わり合う方法を革新してきました。このブログ投稿の目的は、Rekognition の有名人の認識および顔認識機能をグラフデータベースに保存された関係情報に組み合わせるのがいかに簡単かをご紹介することです。 これらのテクノロジーを組み合わせることで、お客様は 1 枚の写真を通じて、その写真に含まれる人物が他の関心対象である人物とどのように関連しているかを把握できます。さらに、2 枚の写真を送信し、それぞれの写真に含まれる人々の間にどのような相互関係があるかを素早く見極めることも可能です。この関係マッピングを活かしたコミカルな例が、有名な Six Degrees of Kevin Bacon (ケヴィン・ベーコンとの六次の隔たり) ゲームです。しかし、このようなアプリケーションのビジネス価値は実に大きなものです。法執行機関は 2 枚の写真を基に Rekognition を活用して各人物の身元を特定し、グラフデータベースを参照して関心対象である 2 名の人物が知り合いかどうかを突き止めることができます。同様に、ホスピタリティ企業は Rekognition とグラフデータベースを使って敷地内にいる有名人を素早く特定し、その人物の知り合いである他の有名人のうち、近隣に宿泊している人物を把握できます。 このブログ投稿では、グラフデータベース (ここでは Neo4j Community Edition を使用) を採用した Rekognition と、D3.js ライブラリを使用した Jupyter Notebook の併用方法のデモンストレーションをご紹介します。 設定 このテクノロジーの組み合わせの使用を開始するには、まず AWS ラボの Github リポジトリからプロジェクトのコピーを取得します。  プロジェクト構成には 2 つの主なエリアが含まれます。 <project […]

Read More

見逃していませんか? 最近公開された AWS サービスの概要

目を疑うほどの数のリリースやクラウドの最新技術が開発されています。今回のブログでは、この夏から秋の終わりまでにリリースされた優れたサービスや機能の近況報告の概要を紹介します。 今回ご紹介するサービスと機能: RDS MySQL と Amazon Aurora で行うデータベースユーザー認証の AWS IAM Amazon SES 評価ダッシュボード Amazon SES オープンおよびクリックのトラッキングメトリクス ソリューションビルダーチームによるサーバーレスイメージハンドラ ソリューションビルダーチームによる AWS Ops Automator では、詳しい内容を見てみましょう。 RDS MySQL と Amazon Aurora で行うデータベースユーザー認証の AWS IAM AWS IAM を使用して、Amazon RDS データベースインスタンスやクラスターへのアクセスを管理したいと思ったことはありませんか?なんと、それを実現できるようになりました。Amazon RDS はユーザーが IAM を使用して MySQL や Amazon Aurora DB の Amazon RDS へのデータベースアクセスを管理できるようにする機能をリリースしました。 このサービス機能の良い所は、使用開始が実に簡単なことです。IAM を使用してデータベースユーザー認証を有効にするには、DB インスタンスまたはクラスターの作成、変更、復元を行う際に [Enable IAM DB Authentication] […]

Read More

Amazon Aurora Under the Hood: クオーラムメンバーシップ

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。 この記事は、Amazon Auroraがどのようにクオーラムを使用するのかをお話する4回シリーズの最後です。最初の記事では、障害が発生した場合に必要なクォーラムのメリットとメンバの最小数について説明しました。2回目の記事では、読み書きを行う際に利用するネットワーク帯域の増加を避けるために、ロギング、キャッシュの状態、および非破壊的な書き込みを使用する方法について説明しました。3回目の記事では、より高度なクォーラムモデルを使用して複製コストを削減する方法について説明しました。クォーラムに関するこの最後の記事では、クォーラムメンバーシップの変更を管理する際にAmazon Auroraが問題を回避する方法について説明します。 クオーラムメンバーシップの変更を管理するテクニック マシンは故障します。クオーラムメンバの1つが破損すると、ノードを交換することによってクオーラムを修復する必要があります。これは複雑な決定になります。 クォーラムの他のメンバーは、障害のあるメンバに一時的なレイテンシーの増加が発生したか、再起動のための短期間の可用性低下が発生したか、または永久にダウンしたかどうかを判断できません。 ネットワークパーティションにより、複数のメンバーグループが同時にお互いに隔離を実行出来ます。 ノードごとに大量の永続状態を管理している場合、クォーラムを修復するための状態の再複製には長い時間がかかります。 そのような場合、障害のあるメンバーが復帰できる場合に備えて修復を開始することについて慎重に行う必要があります。 多くのノードで状態をセグメント化することで、修復時間を最適化することができます。 しかし、これは失敗の可能性を高めます。 Auroraでは、データベースボリュームを10GBのチャンクに分割し、3つのアベイラビリティゾーン(AZ)に分散した6つのコピーを使用します。 現在の最大データベースサイズが64TBなので、プロテクショングループは6,400個、セグメント数は38,400個です。 このスケールでは破損は一般的に発生する可能性があります。 メンバーシップの変更を管理する一般的な方法は、一定期間リースを使用し、各リースでメンバーシップを確保するためにPaxosなどのコンセンサスプロトコルを使用することです。 しかし、Paxosは処理負荷のかかるプロトコルであり、最適化されたバージョンでは多数の障害が発生します。 障害を管理するためにクオーラムセットを利用する Auroraはメンバーシップの変更を管理するために、ロギング、ロールバック、コミットなどのクォーラムセットとデータベース技術を使用します。 A、B、C、D、E、Fの6つのセグメントを持つプロテクショングループを考えてみましょう。この場合、書き込みクォーラムはこの6組のうち4つのメンバーであり、読み取りクォーラムは3つのメンバーです。 前回の記事でご紹介したように、Auroraのクオーラムはこれよりも複雑ですが、今は単純に考えてみることにします。 Auroraの読み書きはそれぞれ、メンバーシップエポックを使用します。これは、メンバーシップの変更ごとに単調に増加する値です。 現在のメンバーシップエポックよりも古いエポックにある読み取りと書き込みは拒否されます。そのような場合、クオーラムメンバーシップの状態をリフレッシュする必要があります。 これは、概念的には、REDOログ内のlog sequence numbers(LSN)の概念に似ています。 エポックナンバーおよび関連する変更記録は、メンバーシップに順序付けられたシーケンスを提供します。 メンバーシップエポックを変更するには、データ書き込みと同様に書き込みクォーラムを満たす必要があります。 現在のメンバーシップの読み込みには、データの読み込みと同様のリードクオーラムが必要です。 ABCDEFのプロテクショングループの話を続けましょう。セグメントFが破損した可能性があるとし、新しいセグメントGを導入する必要があると考えてください。一時的な障害に遭遇する可能性があり、迅速に復帰する可能性があります。またはリクエストを処理しているかもしれませんが、なんらかの理由で検出出来ない可能性があります。また、Fが復活したかどうかを確認するのを待ちたくはありません。クオーラムが損なわれて2回目の障害が発生する可能性が増加だけです。 これを解決するためにクォーラムセットを使用します。 私たちはABCDEFからABCDEGに直接メンバーシップの変更をすることはありません。代わりに、メンバーシップのエポックを増やし、クォーラムセットをABCDEFとABCDEGに移動します。書き込みはABCDEFの6つのコピーのうち4つから正常に行われなければならず、またABCDEGの6つのコピーのうち4つからackが返る必要があります。 ABCDEのどの4つのメンバーは両方とも書き込みクォーラムを満たしています。 読み取り/修復クォーラムは同じように動作し、ABCDEFからの3つのackとABCDEGから3つのackが必要です。ABCDEからの3つのいずれかが両方を満たします。 データがノードG上に完全に移動され、Fを取り除くと決定した場合、メンバーシップエポックの変更を行い、クォーラムセットをABCDEGに変更します。エポックの使用は、コミットLSNがREDO処理のために行うのと同様に、これをアトミックに行います。このエポックの変更は、現在の書き込みクォーラムが満たされている必要があり、他のアップデートと同様に、ABCDEFの6つのうち4つと、ABCDEGの6つのうちの4つからのackが必要です。Gが利用可能になり前に再びノードFが利用可能になると、変更を元に戻しメンバーシップエポックの変更をABCDEFに戻します。完全に健全なクオーラムに戻るまで、いかなる状態やセグメントも破棄しません。 このクォーラムへの読み書きは、メンバーシップの変更中に、変更前または変更後と同じように行われることに注意してください。 クォーラムメンバーシップへの変更は、読み取りまたは書き込みをブロックしません。失効したメンバーシップ情報を持つ呼び出し元は、状態をリフレッシュして正しいクォーラムセットに要求を再発行します。また、クオーラムメンバーシップの変更は、読み取り操作と書き込み操作の両方に対して非ブロッキングです。 もちろん、Fの代わりにGへデータを移動しクオーラムを修復している間にABCDEGのいずれかが破損する可能性もあります。多くのメンバーシップ変更プロトコルはメンバーシップの変更中に障害を柔軟に処理しません。クォーラムセットとエポックでは、簡単です。Eも破損してHに置き換えられる場合を考えてみましょう。ABCDEFとABCDEGとABCDFHとABCDGHのクオーラムに移動するだけです。単一障害と同様に、ABCDへの書き込みはこれらのすべてを満たします。メンバーシップの変更は、読み取りと書き込みの失敗と同じ範囲になります。 まとめ クォーラムセットをメンバーシップの変更に使用することにより、Auroraは小さなセグメントを使用することができます。これにより、Mean Time To Repair(MTTR)および複数の障害に対する可能性を削減することで、耐久性が向上します。また、お客様のコストを削減します。Auroraのボリュームは必要に応じて自動的に増加し、小さなセグメントでは少しずつ増加します。クォーラムセットを使用することで、メンバーシップの変更が行われている間も読み取りと書き込みが継続できるようになります。 メンバーシップの決定を元に戻すことができれば、積極的にクオーラムを変更することができます。障害のあったメンバーが返ってくると、いつでも変更を元に戻すことができます。いくつかの他のシステムでは、リースが期限切れとなり、クオーラムメンバシップを再確立する必要があるため、定期的な停止が発生します。Auroraは、リースが期限切れになるまでメンバーシップの変更操作を延期するという耐久性の犠牲を払わず、クオーラムメンバシップが確立されている間に読み込み、書き込み、またはコミットを遅らせるというパフォーマンス上のペナルティも発生しません。 Auroraは、さまざまな分野で進歩を遂げています。データベースと分散システムを統合するアプローチは、これらの多くの中核を成しています。クォーラムをどのように使用するかについてのこの連載をご覧いただき、ご自身のアプリケーションやシステムを設計する方法について考えるときに役立てて頂けると思います。今回使用した手法は広く適用可能ですが、スタックの多くの要素にに対して適用する必要があります。 もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。 翻訳は星野が担当しました (原文はこちら)

Read More