Amazon Web Services ブログ

機械学習は多くのスタートアップやエンタープライズにとって重要な技術です。数十年に渡る投資と改善にも関わらず、機械学習モデルの開発、学習、そして、メンテナンスはいまだに扱いにくく、アドホックなままになっています。機械学習をアプリケーションに組み込むプロセスはしばしば一貫しない仕組みで数ヶ月間に及ぶエキスパートチームによるチューニングと修正を伴います。企業と開発者は機械学習に対する生産パイプラインに対するのエンド・エンドな製品を望んでいます。   Amazon SageMaker の紹介   Amazon SageMaker はフルマネージドなエンド・エンド機械学習サービスで、データサイエンティストや開発者、機械学習のエキスパートがクイックに機械学習モデルをスケーラブルにビルド・学習・ホストすることを可能とします。このサービスが機械学習に関する全ての試みを急激に加速し、プロダクションアプリケーションに素早く機械学習を追加可能とします。 Amazon SageMaker には３つの主要なコンポーネントが存在します： オーサリング：データに関する調査・クレンジング・前処理に対してセットアップ無しで利用可能な Jupyter notebook IDE をCPUベースのインスタンスやGPUを利用可能なインスタンスで実行することが可能です。 モデルトレーニング：モデルトレーニングは分散モデル構築／学習／評価サービスです。ビルトインされた共通の教師あり／教師なし学習アルゴリズムやフレームワークの利用や Docker コンテナによる独自の学習環境を作ることも可能です。学習では、より高速なモデル構築を可能とするため、数十のインスタンスにスケールすることが可能です。学習データは S3 から読み出され、モデルアーティファクト が S3 に保存されます。モデルアーティファクトはデータと分離されたモデルのパラメータであり、モデルを使って推論を可能とするような実行コードではありません。この分離により、IoT デバイスのような他のプラットフォームに SageMaker で学習したモデルをデプロイすることが容易になります。 モデルホスティング：モデルをホストするサービスで、リアルタイムに推論結果を取得するためにモデルを呼び出す HTTPS エンドポイントを提供します。エンドポイントはトラフィックに対処するためにスケールすることができ、同時に複数モデルで A/B テストすることを可能とします。加えて, ビルトインの SDK を利用してエンドポイントを構築できるだけでなく、カスタム設定で Docker イメージを利用することができます。 これらコンポーネントはそれぞれ分離して利用することができ、分離されていることが、存在するパイプラインのギャップを埋めるために Amazon SageMaker を採用することを本当に簡単にしています。故、エンド・エンドにサービスを使用するときに有効になる、本当に強力な事象がいくつも存在します。

  Amazon Rekognitionを発表したのは昨年のre:Invent 2016期間中でした。手を汚してコードを書き、サービスを活用して画像認識ソリューションを構築するのにとても興奮しました。ご存知かもしれませんが、Amazon Rekognition Imageは、ディープラーニングを利用してスケーラブルな画像認識と分析を提供するクラウドサービスです。Rekognitionを利用して、オブジェクトとシーンの検出、リアルタイム顔認識、セレブリティ認識、節度の認識だけではなく、テキスト認識をアプリケーションやシステム統合して構築することができます。 Amazon Rekognition Imageサービスは、深層ニューラルネットワークモデルを利用して作成されており、Prime Photosで毎日数億の画像分析を可能にしているのと同じテクノロジーに基づいています。これまで、Rekognitionはスケーラビリティ、自動的な分析、サーチ、画像の分類を提供することに重点的にフォーカスしてリリースされてきました。今その全てが変わっています。今回、このサービスの幾つかの追加機能についてお伝えできることを嬉しく思います。

Amazon Simple Storage Service (S3) は、各業界のマーケットリーダーが使用する数百万のアプリケーションのデータを保存しています。セキュアで耐久性のある非常に低コストのアーカイブストレージとして、これらの多くのお客様は Amazon Glacier も使用しています。S3 では、望むだけの数のオブジェクトを格納することができますし、個々のオブジェクトは最大5テラバイトとすることができます。オブジェクトストレージのデータは、通常１エンティティ全体としてアクセスされます。そのことは、例えば 5GB のオブジェクトに対してなんらかの要求をすれば、5GB 全てのデータ取得を行うことを意味します。これはオブジェクトストレージとしては自然なことです。 2017年11月29日、このパラダイムに挑戦すべく、S3とGlacierに2つの新機能を発表します。シンプルなSQL文を利用して、それらのオブジェクトから必要なバイトだけを引き出すことを可能としました。この機能により、S3やGlacierのオブジェクトにアクセスするすべてのアプリケーションが強化されます。 S3 Select プレビューとして発表された S3 Select により、アプリケーションはシンプルなSQL文を用いて、オブジェクトからデータの一部分のみを取り出すことができます。アプリケーションが必要とするデータのみを取得するので、大幅なパフォーマンス向上が達成でき、400%ほどの改善が見込めることもあります。

私の同僚 Deepak Singh が、コンテナに関してたくさんお伝えしたいことがあります！ – Jeff; AWS 上で Kubernetes を利用している多くのお客様がいます。実際、Cloud Native Computing Foundationによると、Kubernetes のワークロードの63％が AWS 上で動作しています。AWS は Kubernetes を実行するうえで人気の場所ですが、お客様が Kubernetes クラスターを管理するためには、依然として多くの手動設定が必要となります。Kubernetes のマスターをインストールして運用し、Kubernetes のワーカーのクラスターを構成する必要があります。Kubernetes クラスターで高可用性を実現するには、異なる AZ 間で少なくとも三つの Kubernetes マスターを実行する必要があります。各マスターは、それぞれで対話し、障害が発生した場合に備え情報を共有し、負荷分散、フェールオーバーを他のマスターに確実に実行するように構成する必要があります。そして、すべての設定と実行が完了しても、マスターとワーカーのソフトウェアのアップグレードとパッチ適用を行う必要があります。これらは運用の専門家とその努力必要としており、我々はお客様からもっと簡単にしてほしいと言われてきました。 Amazon EKS の紹介 Amazon Elastic Container Service for Kubernetes (Amazon EKS) は、Kubernetes クラスターの専門家でなくてもKubernetesを AWS 上で簡単に使用することができるフルマネージドサービスです。開発者の皆様にこのサービスを気に入ってもらえるいくつかの点があります。まず、Amazon EKS は オープンソースの Kubernetes を基に実行されますので、Kubernetes コミュニティの全ての既存のプラグインとツールを使用できます。Amazon EKS 上で動作するアプリケーションは、オンプレミスのデータセンターやパブリッククラウドで動作しているかにかかわらず、標準の Kubernetes 環境で動作するアプリケーションと完全に互換性があります。つまり、コード変更なしで簡単にあなたの Kubernetes アプリケーションを […]

AWS上でコンテナを運用管理するお客様の手助けになるようAmazon Elastic Container Service(Amazon ECS)をアナウンスしたのは約3年前でした。Amazon ECSを利用することで、クラスター管理やオーケストレーション用ソフトウェアを運用することについて心配する必要がなくなり、大規模に高い可用性を持ってワークロードを稼働させることが可能になりました。 2017/11/29、AWSは AWS Fargateをアナウンスしました。下回りとなるインスタンス群の管理をせずとも、コンテナを基本的な計算単位として利用することができる技術です。Fargateをご利用いただくことで、コンテナを動かすためにクラスター内の仮想マシンのプロビジョニング、設定やスケールを行う必要はもうありません。Fargateは現在Amazon ECSから利用可能ですが、将来的にはAmazon Elastic Container Service for Kubernetes (Amazon EKS)もサポートする予定です。 Fargateでは、アプリケーションの要件に対して最も近い設定を柔軟に行うことができ、請求は秒単位となります。 Amazon ECSとFargate Amazon ECSは、コンテナを大規模に稼働させることを可能にします。また、このサービスは、VPC networking、load balancing、IAM、Amazon CloudWatch LogsやCloudWatch metricsといったAWSプラットフォームとネイティブに連携しています。これらの連携により、ECSタスクはAWSプラットフォームの中でファーストクラスオブジェクトとして扱うことができます。 タスクを起動するためには、適切なインスタンスタイプと数を選び、Auto Scalingを設定し、パフォーマンス向上のためにクラスターのサイジングを管理するといったクラスターの立ち上げが必要ですが、Fargateでは、それらを全て忘れることができ、アプリケーションの定義、権限やスケーリングについてのポリシー設定に専念することができます。

AWSの多くのお客様にDynamoDBは広く、ミッションクリティカルな用途に使われています。金融、E-コマース、広告、IoT、そしてゲームなど様々な用途で使われており、数百万リクエスト/秒のスループットとテラバイトのデータと数兆のアイテムを格納しています。 本日、我々は２つの強力な新機能を皆様に紹介出来る事に喜びを感じています。 Global Tables – 今から新しくテーブルを作る時に全自動で２つのリージョン間、若しくはそれ以上のリージョン間で同期されるマルチマスタのテーブルを数回のクリックで簡単に作成する事が出来ます。簡単かつ素早く構築が出来る事と、大規模なスケールをアプリケーションに提供出来るためグローバルスケールのユーザーに対応することがレプリケーションの管理無しに可能になります。 On-Demand Backup – 一回のクリックで、今利用しているDynamoDBのテーブルのフルバックアップを取得する事が今から可能です。これはパフォーマンスや可用性などに影響がありません。バックアップ取得中もアプリケーションはオンラインのまま実行され、設定したプロビジョンドキャパシティ応じて読み書きが可能です。バックアップは長期間の保持、アーカイブを行い、監査要件などで必要な場合にも役立ちます。 Global Tables DynamoDBでは既にデータは3つのAZにレプリケーションされ耐久性と高い可用性のストレージを提供しています。今日からGlobal Tablesを使うことによって、あなたのテーブルのデータは複数のリージョンへのレプリケーションを数クリックで実現出来ます。多くのグローバルで提供しているアプリケーションに必要な素早い書き込み、読み込み性能をこのスケールによって実現が可能です。 アプリケーションのコードは変更する必要がありません。書き込みリクエストと結果整合性の読み込みリクエストであればそれぞれのリージョンで作成されるendpointにリクエストを送れば大丈夫です（もし強い一貫性の読み込みが必要であれば一つのendpointに書き込みと読み込みリクエストを一つのendpointに集約する必要があります）。裏側では、DynamoDBはマルチマスター書き込みを実装し、特定のアイテムへの最後の書き込みが確実に行われるようにします。あなたがGlobal Tablesを使う時、全てのアイテムは最新の書き込み時刻を表すタイムスタンプ属性を含む様になります。アイテムへのアップデートがあった場合他のリージョンへ非同期で伝播し、DynamoDB Streams経由で完了までに1秒程度で終わります（あなたがこの状況を追跡するために新しくTimeToReplicateとReplicationQueueBacklogメトリクスが追加されます。）。

現代の生活を可能にするために必要な全てのデータ構造やアルゴリズムの中でも、グラフは日々世界を変えています。ビジネスからは、複雑な関係性を持つリッチなデータが生まれ続け、また取り込まれ続けています。しかし開発者は未だにトラディショナルなデータベースの中でグラフのような複雑な関係性を扱うことを強要されています。必然的に、そのような関係性-リレーションシップが追加されるにつれ、パフォーマンスは劣化し、いらいらするくらい高コストで複雑なクエリとなっていきます。我々はそのようなモダンで複雑性が日々高まるようなデータセットやリレーションシップ、パターンを簡単に扱えるようにしたいと考えました。 Hello, Amazon Neptune 2017年11月29日、我々は限定プレビュー版のAmazon Neptuneを発表します。Amazon Neptuneにより、高度に接続されたデータセット間のリレーションシップから簡単に洞察を得ることができます。Neptuneのコア部分は、数十億ものリレーションシップが格納可能で、グラフに対してミリ秒レベルの遅延となるよう最適化された、専用の、高性能なグラフデータベースエンジンです。フルマネージドなデータベースとして提供されることで、Neptuneはお客様をメンテナンスやパッチ適用、バックアップ/リストアなどの退屈なオペレーションから解放し、アプリケーションに集中できるようにします。高速なフェイルオーバー、Point-in-Timeリカバリ、そしてマルチAZでの実装など高可用性のための各種機能も備えるサービスです。最大15個のリードレプリカによりクエリのスループットを秒間10万件レベルまでスケールさせることも可能です。Amazon NeptuneはAmazon VPC内で動作し、データを暗号化して保管でき、保管時や転送時にデータの整合性について完全に制御することができます。

既にご存知の通り、Amazon AuroraはMySQL互換とPostgreSQL互換があり、マネージドサービスで自動的に64TBまでスケールアップするデータベースストレージ’を備えています。Auroraデータベースインスタンスを作成する際に必要なインスタンスサイズの選択や、リードスループットを向上させるためにリードレプリカを作成するかどうかのオプションを選択します。処理の需要やクエリ数の増減に応じて、インスタンスサイズやリードレプリカの数を必要に応じて変更可能です。このモデルはリクエスト数や負荷などのワークロードが予測し易い場合はうまくいきます。 しかし、場合によっては1日や1週間の間に数時間、もしくは数分間だけリクエストがスパイクするようなワークロードの割り込みがあったり予測が難しいケースがあります。セールや1回だけもしくは不定期イベント、オンラインゲームや日時・週次のレポーティング、dev/test、新規アプリケーションなどが当てはまります。適切なキャパシティに調整し続けるためには多くの作業が必要です、そのため安定している状態を基準として支払いを行うほうが懸命です。

コンテナは、開発者がアプリケーションを開発・パッケージ・デプロイするのに強力な手法の１つです。AWSでは、十万以上のアクティブなECSクラスタが稼働しており、毎週数億の新しいコンテナが起動しています。これは、2016年からすると400%を超えるお客様成長率です。Amazon ECSやKubernetesといったコンテナのオーケストレーションソリューションは、コンテナワークロードのデプロイ・管理・スケールをより容易にし、敏捷性を増します。しかし、それらのどのソリューションも下回りとなるインフラストラクチャの可用性、キャパシティやメンテナンスを行う必要が依然としてあります。AWSにおいて、私たちはこれを差別化とならない重労働を取り除く機会と考えました。私たちは、コンテナがもたらすスピード、敏捷性や不変性のメリットを十分にお客様にご利用いただき、インフラストラクチャの管理ではなくアプリケーションの構築に注力いただきたいと思っています。 AWS Fargate AWS Fargateは、コンテナをデプロイする最も簡単な方法です。端的に言うと、FargateはEC2に似ていますが、仮想マシンを提供する代わりに、コンテナを提供します。これにより、下回りとなるインスタンス群の管理をせずとも、コンテナを基本的な計算単位として利用することができる技術です。やるべきことは、コンテナイメージ構築し、CPUやメモリの要件を指定し、ネットワークやIAMポリシーを定義し、そしてコンテナを起動することです。Fargateでは、アプリケーションの要件に対して最も近い設定を柔軟に行うことができ、請求は秒単位となります。

このブログでは、Amazon EMR で Apache MXNet (incubating) および Apache Spark を使用して大規模なデータセットで分散オフライン推論を実行する方法を説明します。オフライン推論がどのように役立つのか、課題となる理由、および、Amazon EMR で MXNet と Spark を活用して課題を解決する方法を説明します。 大規模データセットでの分散推論 – ニーズと課題 ディープラーニングモデルのトレーニングの後、新しいデータ上で推論を実行して活用します。推論は、不正検出など、その場でのフィードバックが必要なタスクでリアルタイムに実行できます。これは通常オンライン推論と呼ばれています。または、事前計算が役立つ場合は、推論をオフラインで実行できます。オフライン推論のよくあるユースケースは、ユーザーの製品スコアのソートやランク付けを必要とする推奨システムなど、レイテンシー要件が低いサービスです。これらのケースでは、推奨はオフライン推論を使用して事前計算されます。結果は低レイテンシーストレージに保存され、必要に応じて、推奨がストレージから引き出されます。オフライン推論の別のユースケースは、最新モデルから生成された予測による履歴データのバックフィリングです。仮の例として、新聞でこの設定を使用して、人物識別モデルから予測された人物の名前でアーカイブされた写真をバックフィルできます。また、分散推論を使用して、歴史的なデータで新しいモデルをテストし、本番稼働用にデプロイする前により良い結果を生み出すかどうかを確認できます。 通常、分散推論は数百万以上のレコードがあるような大規模なデータセットで実行されます。妥当な時間内にそのような巨大なデータセットを処理するには、ディープラーニングの機能をセットアップされたマシンクラスターが必要です。分散クラスターでは、データ分割、バッチ処理、タスクの並列化を使用した高いスループット処理ができます。ただし、ディープラーニングデータ処理クラスターをセットアップするには課題もあります。 クラスターのセットアップと管理: ノードのセットアップとモニタリング、高い可用性の維持、ソフトウェアパッケージのデプロイと設定など。 リソースとジョブの管理: ジョブのスケジューリングと追跡、データ分割とジョブの障害への対処。 ディープラーニングのセットアップ: ディープラーニングタスクのデプロイ、設定、および実行。 次に、このブログの投稿では、Amazon EMR で MXNet および Spark を使用してこれらの課題に対処する方法を示します。