Amazon Web Services ブログ

Amazon EC2アップデート – 高性能で費用対効果の高い推論のための AWS Inferentia チップを搭載した Inf1 インスタンス

お客様は機械学習を大いに活用しています。オブジェクト検出、音声認識、自然言語処理、パーソナライズ、不正検出など、さまざまな種類のワークロードを実行しています。大規模な本番ワークロードで実行する場合、可能な限り迅速かつ費用対効果の高い方法で推論を実行できることが不可欠です。お客様の話では、推論は機械学習作業のコストの最大 90% を占めます。 新しい Inf1 インスタンス 本日、4 つのサイズの Inf1 インスタンスを起動します。これらのインスタンスは AWS Inferentia チップを搭載しており、高速で低レイテンシーの推論を提供するように設計されています。 AWS Inferentia チップは、推論プロセスを加速するように設計されています。各チップは次のパフォーマンスを提供できます。 16 ビット浮動小数点 (FP16 および BF16) と混合精度データの 64 teraOPS。 8 ビット整数 (INT8) データの 128 teraOPS。 チップには、高速インターコネクトと大量のメモリも含まれています。最大のインスタンスに 16 個のチップが搭載されているため、新規および既存の TensorFlow、PyTorch、および MxNet 推論ワークロードは、2 petaOPS を超える推論能力の恩恵を受けることができます。G4 インスタンスと比較した場合、Inf1 インスタンスは推論スループットを最大 3 倍にし、推論あたりのコストを最大 40% 削減します。 サイズと仕様は次のとおりです。 インスタンス名 Inferentia チップ vCPUs RAM EBS 帯域幅 ネットワーク帯域幅 inf1.xlarge 1 […]

Read More

新機能 – VPC Ingress Routing – サードパーティアプライアンスの統合を簡素化

Architecting on AWS クラスを担当していたとき、お客様から、Amazon Virtual Private Cloud を設定して、オンプレミスと同じネットワークセキュリティポリシーをクラウドで実施する方法をよく尋ねられました。たとえば、侵入検知システム (IDS) アプライアンスを使用してすべての入力トラフィックをスキャンしたり、クラウドでオンプレミスと同じファイアウォールを使用したりするために。今日まで、私が提供できる唯一の答えは、すべてのトラフィックを VPC からオンプレミスのアプライアンスまたはファイアウォールにルーティングして、クラウドにルーティングする前に通常のネットワーク機器でトラフィックを検査することでした。これは明らかに理想的な設定ではなく、レイテンシーと複雑さが増します。 今日、新しい VPC ネットワーキングルーティングプリミティブを発表します。これにより、インターネットゲートウェイ (IGW) または仮想プライベートゲートウェイ (VGW) との間の送受信、または Amazon Elastic Compute Cloud (EC2) インスタンスの Elastic Network Interface へ送信されるすべてのトラフィックをルーティングできます。つまり、トラフィックがビジネスワークロードに到達する前にすべてのトラフィックを EC2 インスタンスに送信するように仮想プライベートクラウドを設定できるようになりました。通常、インスタンスはネットワークセキュリティツール (IDS/IPS または Firewall など) を実行して、疑わしいネットワークトラフィックを検査またはブロックするか、他の EC2 インスタンスにトラフィックを中継する前に他のネットワークトラフィック検査を実行します。 仕組み その仕組みを学ぶために、この CDK スクリプトを作成して、アプライアンス用のサブネットとビジネスアプリケーション用のサブネットの 2 つのパブリックサブネットを持つ VPC を作成しました。このスクリプトは、パブリック IP アドレスを持つ 2 つの EC2 インスタンス (各サブネットに 1 つずつ) […]

Read More

AWS Compute Optimizer – カスタマイズされたリソース最適化サービス

Amazon EC2 インスタンスタイプについて公に話すと、よく受ける質問の 1 つに「アプリケーションに適したインスタンスタイプを間違いなく選択するにはどうすればよいですか?」というものがあります。 正しいインスタンスタイプの選択は、芸術と科学の中間にあります。通常は、通常の環境 (ベースライン) でのアプリケーションのパフォーマンス特性と予想される日ごとの変動を把握して、これらの特性に一致するインスタンスタイプを選択します。その後、主要なメトリクスをモニタリングして選択を検証し、時間をかけてプロセスを繰り返して調整し、アプリケーションのコストとパフォーマンスの割合に最適なインスタンスタイプになるようにします。リソースを過剰にプロビジョニングするとインフラストラクチャへの支払いが過剰になり、リソースを過少にプロビジョニングするとアプリケーションのパフォーマンスが低下し、顧客体験に影響を与える可能性があります。 今年の初めに Cost Explorer Rightsizing Recommendations を開始しました。これは、使用率が低い Amazon Elastic Compute Cloud (EC2) インスタンスを特定するのに役立ちます。このインスタンスを同じファミリー内でダウンサイジングして、お金を節約します。受け取ったフィードバックは素晴らしく、お客様からは同じインスタンスファミリー内の単なるダウンサイジング以上の推奨事項を求める声が上がりました。 本日、ワークロード向けのコンピューティングリソースの最適化に役立つ新しいサービスを発表します。AWS Compute Optimizer です。AWS Compute Optimizer は、機械学習技術を使用してアカウントのリソース消費の履歴を分析し、リソースの使用状況に合わせて明確で実用的な推奨事項を作成します。AWS Compute Optimizer は AWS Organizations に統合されており、マスター titletitleAWS Organizations アカウントから複数のアカウントの推奨事項を確認できます。 AWS Compute Optimizer を開始するには、AWS マネジメントコンソールに移動し、[AWS Compute Optimizer] を選択してサービスをアクティブ化します。Amazon CloudWatch メトリクスを使用してリソースの使用状況と履歴の分析をすぐに開始し、数時間後に最初の推奨事項を提示します。 次のように、AWS Compute Optimizer ダッシュボードで最初の推奨事項を確認できます。 次のように、[オーバープロビジョニング: 8 インスタンス] をクリックして詳細を取得します。 8 […]

Read More

【開催報告】第10回Amazon SageMaker 事例祭り

アマゾン ウェブ サービス ジャパン株式会社 パートナーソリューションアーキテクトの小田桐です。 AWS Japan 目黒オフィスでは「Amazon SageMaker 事例祭り」(Twitter: #sagemaker_fes) を定期的に開催しています。2019年11月28日に開催された 第10回 Aazon SageMaker 事例祭り では、AWS Japan のソリューションアーキテクトによるサービスの最新情報や技術情報と、Amazon SageMaker をご利用いただいているお客様をゲストスピーカーにお招きし、実際に導入頂いたお客様による「体験談」をお話し頂きました。

Read More

新機能 – EBS Direct API – EBS スナップショットコンテンツへのプログラムによるアクセス

EBS スナップショットは実に有能です。 これは、AWS マネジメントコンソール を通じて双方向的に作成できます。 作成するには、コマンドライン (create-snapshot) を使うか、CreateSnapshot 関数を呼び出します。また、Data Lifecycle Manager (DLM) により、スナップショット自動管理の設定が行えます。 スナップショットについて スナップショットは Amazon Simple Storage Service (S3) に保存され、これにより、必要に応じて新しい EBS ボリュームを素早く作成できます。ボリュームの最初のスナップショットには、ボリューム上にある 512K サイズのブロックすべてのコピーが含まれます。その後のスナップショットには、前のスナップショット以降に変更されたブロックのみがふくまれます。スナップショットが増分を扱うこの性質により、コスト効率が非常に高くなります。(統計的にいって) EBS ボリューム上にあるブロックの多くは、ほとんど変更されることがないからです。 その手短な例をご覧いただきましょう。今、8 個のブロックがある EBS ボリュームを作成およびフォーマットしたと考えます (これは許可された最小サイズより小さいですが、例としてお許しください) 。これにいくつかファイルをコピーした後、最初のスナップショット (Snap1) を作成します。このスナップショットには、次に示すようにすべてのブロックが含まれます。 次に、いくつかのファイルをさらに追加し、1 つのファイルを削除してから、2 つめのスナップショット (Snap2) を作成します。このスナップショットには、1 つめを作成した後に修正されたブロックのみが含まれ、それは次のようになります。 さらに、いつくかの変更を加えた後、3 つめのスナップショット (Snap3) を作成します。 現実には、ディレクトリー、ファイル、そして下層ブロックの間の関係性はファイルシステムで制御されており、一般的にかなり複雑なものになることは、心に留めておいてください。 さて、3 つのスナップショットができましたので、これらを使って新しくボリュームを作成したいと思います。EBS ボリュームのスナップショットを作成するたび、前のスナップショットへの内部参照も作成されます。これにより、CreateVolume が各ブロックについて最新のコピーを見つけられるようになっています。次に示すような関係です。 詳細な管理は、この背景にある EBS が受け持ってくれます。たとえば、Snap2 を削除するとそれに含まれる Block […]

Read More

Amplify DataStore – GraphQL でオフラインアプリの開発を簡素化

オープンソースの Amplify Framework は、ウェブおよびモバイル開発者がクラウドベースのサービスを簡単にプロビジョニングおよびアクセスできるようにするコマンドラインツールおよびライブラリです。たとえば、モバイルアプリケーション用に GraphQL API を作成したければ、開発マシンで amplify add api を使用してバックエンド API を設定します。いくつかの質問に答えた後、amplify push と入力して、クラウドで AWS AppSync API バックエンドを作成します。Amplify はコードを生成し、アプリが新しく作成された API に簡単にアクセスできるようにします。Amplify は Angular、React、Vue などの一般的なウェブフレームワークをサポートしています。また、React Native、iOS 用の Swift、Android 用の Java で開発されたモバイルアプリケーションもサポートしています。モバイルアプリケーションで Amplify を使用する方法について詳しく知りたい場合は、re:Invent 2019 カンファレンス向けに準備したワークショップ (iOS または React Native) にお気軽にご参加ください。 AWS のお客様は、ウェブおよびモバイルアプリケーションを開発する際に最も難しいタスクは、デバイス間でデータを同期し、オフライン操作を処理することだと語っています。理想的には、デバイスがオフラインのときも、お客様はデータにアクセスするだけでなく、データを作成および変更するためにアプリケーションを引き続き使用できる必要があります。デバイスがオンラインに戻ると、アプリケーションはバックエンドに再接続し、データを同期して、競合がある場合は解決する必要があります。AWS AppSync SDK のオンデバイスキャッシュをオフラインミューテーションとデルタ同期で使用している場合でも、すべてのエッジケースを正しく処理するには、多くの未分化コードが必要です。 本日、Amplify DataStore を導入いたします。これは、開発者がデータへの変更を書き込み、読み取り、監視するための永続的なオンデバイスストレージリポジトリです。Amplify DataStore を使用すると、開発者は、オフラインまたはオンラインシナリオ用の追加コードを作成することなく、分散データを活用するアプリを作成できます。Amplify DataStore は、クラウドへの接続や AWS アカウントを必要とせずに、ウェブおよびモバイルアプリケーションでスタンドアロンのローカルデータストアとして使用できます。ただし、クラウドバックエンドで使用する場合、Amplify DataStore は、ネットワーク接続が利用可能であれば、データを AWS […]

Read More

re:Invent 2019 12月5日のまとめ

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。re:Invent 2019 4日目(12月5日)が終了しました。今日はWerner Vogelsによるre:Invent 2019 最後の基調講演がありました。 Deep Racer リーグ決勝戦では、日本からの参加者がワンツーフィニッシュとなりました。   そしてこの後は最後の Have Fun Event、re:Playがあります。 12月5日ですが、アップデートは1つでした。 Amazon Builders’ Libraryがリリースされました Amazon Builders ‘Libraryは、AmazonがAmazon.comとAWSを支えるソフトウェアをどのように設計、リリース、運用するかを読者に紹介する生きた記事のコレクションです。ビルダーズライブラリの記事は、Amazonのシニアテクニカルリーダーとエンジニアによって書かれており、アーキテクチャ、ソフトウェア配信、運用に関するトピックをカバーしています。たとえば、読者はAmazonがソフトウェア配信を自動化して年間1億5千万件以上の展開を達成する方法や、Amazonのエンジニアがシャッフルシャーディングなどの原則を実装して、可用性とフォールトトレラントな復元力のあるシステムを構築する方法を見ることができます。 – シニアエバンジェリスト 亀田

Read More

UltraWarm for Amazon Elasticsearch Service を使用して少ないコストでより多くのデータを維持する

機械によって生成されたデータは、ソリューションを強化すると共に問題も引き起こします。これは今日の最新ソフトウェアアプリケーションで運用上の問題を特定するために必要不可欠ですが、それをリアルタイムで分析するには Amazon Elasticsearch Service のような柔軟でスケーラブルなツールが必要です。このログデータは極めて貴重であるため、ホットストレージから削除したくはないのですが、大量にありすぎるので削除するしかありません。ログ分析には、潜在的な価値と実費をてんびんにかけるという本質的な葛藤があります。 過去数日間からのログに価値があることは分かっています。最高のインデックスおよび検索パフォーマンスを提供するホットストレージに料金を支払うことは道理にかないます。6 週間前、または数か月前からのログには価値が出る可能性もありますが、これからどのくらいで価値が出るのでしょうか? その一方で、それらをホットストレージに維持するコストは正当化できるのでしょうか? Amazon Elasticsearch Service の新しいストレージ階層である UltraWarm は、この葛藤を取り除き、ホットストレージと比較してデータ保持期間を劇的に延長し、コストを最大 90% 削減することを可能にします。何よりも素晴らしいのは、インタラクティブな分析経験はそのまま変わらないところです。ウォームインデックスは、他のインデックスと同様にクエリしたり、それらを使用して Kibana ダッシュボードを構築したりします。 仕組み 従来のウォームストレージソリューションには制限がありました。オープンソースの Elasticsearch クラスターは高密度ストレージの D2 インスタンスを使用することができますが、これらのノードを追加しても同じ基本的な Elasticsearch アーキテクチャが維持されます。引き続きオペレーティングシステムオーバーヘッド、ディスクウォーターマーク、およびインデックスレプリカを考慮しなくてはなりません。使用分だけを支払うのではなく、プロビジョニングした分の料金を支払い続けます。 UltraWarm は違います。これは、Amazon S3 と AWS Nitro System 駆動のノードの組み合わせを使用して、集約と可視化にホットストレージのような経験を提供します。S3 は耐久性に優れた低コストのストレージを提供し、レプリカの必要性を排除します。S3 はまた、オーバーヘッドという概念を取り去るので、各 UltraWarm ノードは利用可能なストレージを 100% 使用することができます。これらのノードには、クエリ処理最適化、およびデータをプリフェッチする高度なキャッシングソリューションが含まれています。従来のウォームストレージソリューションと比較して、UltraWarm のパフォーマンスは通常それらと同様、またはそれらより優れています。 具体的な料金例について、3 つのultrawarm1.large ノードを検討しましょう。すべてのノードと同様に、各ノードには時間レートの料金を支払います。今回の場合のレートは 2.680 USD です。これらのノードを合わせると、毎月 GiB あたり 0.024 USD で最大 60 TiB の […]

Read More

新機能 – Lambda 関数のプロビジョニングされた同時実行性

特にサーバーについて考える必要がない場合は、時間はあっと言う間に過ぎていきます。AWS Lambda は 5 年目を迎えました。チームは常に、顧客がより簡単な方法で、アプリケーションを構築して実行できるようにする新しい方法を探しています。 ミッションクリティカルなアプリケーションがサーバーレスに移行するにつれて、顧客はアプリケーションのパフォーマンスをさらに制御する必要があります。 本日、プロビジョニングされた同時実行数を開始します。これは、関数を初期化し、2 桁のミリ秒以内に応答するためのハイパーレディを維持する機能です。 ウェブおよびモバイルバックエンド、レイテンシーの影響を受けやすいマイクロサービス、同期 API などの対話型サービスの実装に最適です。 Lambda 関数を呼び出すと、呼び出しは実行環境にルーティングされ、リクエストが処理されます。関数がしばらく使用されていない場合、より多くの同時呼び出しを処理する必要がある場合、または関数を更新する場合、新しい実行環境が作成されます。実行環境の作成は、関数コードのインストールとランタイムの開始を処理します。デプロイパッケージのサイズやランタイムとコードの初期化時間に応じて、新しい実行環境にルーティングされる呼び出しのレイテンシーーが発生する可能性があります。このレイテンシーは通常、「コールドスタート」と呼ばれます。 ほとんどのアプリケーションでは、この追加のレイテンシーは問題になりません。ただし、一部のアプリケーションでは、このレイテンシーは許容されない場合があります。 関数のプロビジョニングされた同時実行を有効にすると、Lambda サービスは実行環境のリクエスト数を初期化して、呼び出しに応答する準備ができるようにします。 プロビジョニングされた同時実行の設定 同じ Java コードを使用し、Amazon API Gateway によってトリガーできる 2 つの Lambda 関数を作成します。本番稼働ワークロードをシミュレートするために、これらの関数は、初期化段階で 1,000 万回、呼び出しごとに 20 万回の数学的計算を繰り返しています。計算は java.Math.Random と条件 (if …) を使用して、コンパイラの最適化 (反復の「ループ解除」など) を回避します。各関数には 1 GB のメモリがあり、コードのサイズは 1.7 MB です。 2 つの関数のいずれかでのみプロビジョニングされた同時実行を有効にして、同様のワークロードに対する反応を比較できるようにします。Lambda コンソールで、いずれかの機能を選択します。構成タブに、新しいプロビジョニングされた同時実行設定が表示されます。 設定を追加を選択します。プロビジョニングされた同時実行は、特定の Lambda 関数バージョンやエイリアスに対して有効にできます ($LATEST は使用できません)。関数のバージョンごとに異なる設定を指定できます。エイリアスを使用すると、これらの設定を適切な関数バージョンに簡単に有効化できます。私の場合、AWS SAM AutoPublishAlias 関数設定を使用して、最新バージョンに更新し続けるエイリアスライブを選択します。プロビジョニングされた同時実行の場合、500 と保存を入力します。 現在、プロビジョニングされた同時実行の構成は進行中です。実行環境は、私の入力に基づいて同時に着信するリクエストを処理する準備ができています。 この間、関数は利用可能なままで、トラフィックを処理し続けます。 数分後、同時実行が準備状態になります。これらの設定により、最大 500 件の同時実行リクエストで、それらを処理するための準備が整った実行環境が見つかります。それを超えても、Lambda […]

Read More

新機能 – AWS Step Functions 高速ワークフロー: 高パフォーマンスと低コスト

re:Invent 2016 では AWS Step Functions を開始しました。お客様はすぐにサービスを利用して、多段階ワークフローのコア要素として使用しました。現在、機械学習トレーニング、レポート生成、注文処理、IT オートメーション、およびその他の多くの多段階プロセスを調整するサーバーレスワークフローを構築しているお客様もいらっしゃいます。これらのワークフローは最大 1 年間実行でき、チェックポイント、一時的な障害の再試行、監査目的での詳細状態の追跡を含むワークフローモデルを中心に構築されます。 使用状況とフィードバックから、お客様方がコアな Step Functions モデルを非常に好んでいることがわかります。お客様は、宣言仕様と、ワークフローを簡単に構築、テスト、スケーリングできることを気に入っています。実際、お客様は Step Functions が非常にお気に入りのため、IoT データの取り込み、ストリーミングデータ処理、モバイルアプリケーションバックエンドなどの大容量で短期間のユースケースに使用したいと考えています。 新しい高速ワークフロー 本日、既存の標準ワークフローのオプションとして高速ワークフローを開始しました。高速ワークフローは同じ宣言仕様モデル (Amazon States Language) を使用しますが、これらの大容量で短期間のユースケース向けに設計されています。知っておくべきことは、次のとおりです。 トリガー – AWS サービスの長いリストに関連付けられたイベントと読み取り/書き込み API 呼び出しを使用して、高速ワークフローの実行をトリガーできます。 実行モデル – 高速ワークフローは 1 回以上実行モデルを使用し、失敗したステップを自動的に再試行することはありませんが、エラー処理で説明されているように、再試行とキャッチを使用できます。ステップはチェックポイントとして表示されないため、ステップごとのステータス情報は利用できません。成功と失敗は CloudWatch Logs に記録され、ログ記録レベルを完全に制御できます。 ワークフロー段階 – 高速ワークフローは、アクティビティタスクを除き、標準ワークフローと同じサービス統合の多くをサポートします。AWS Batch、AWS Glue、Amazon SageMaker などの長期実行サービスを開始できます。とても待ち遠しいことでしょう。 期間 – 高速ワークフローは、実際の経過時間で最大 5 分間実行できます。他の高速ワークフローまたは標準ワークフローを呼び出すことはできますが、とても待ちきれないでしょう。また、標準ワークフローから高速ワークフローを呼び出して、アプリケーションのニーズを満たすために両方のタイプを構成することもできます。 イベント料金 – 高速ワークフローは、1 秒あたり 100,000 […]

Read More