Amazon Web Services ブログ

Tag: reinvent2019update

Amazon DocumentDB (MongoDB 互換) re:Invent 2019 まとめ

Amazon DocumentDB チームは、AWS re:Invent 2019 で皆様と直接お会いしてフィードバックやユースケース、次に構築してほしいサービスなどのご希望を伺い、楽しい時間を過ごすことができました。私にとっての re:Invent の見どころは、FINRA と フルフィルメント by Amazon (FBA) による、2 つのお客様導入事例のプレゼンテーションでした。どちらにも、Amazon DocumentDB への移行に至るまでのそれぞれの遍歴や、開発者の効率性を向上しながらアプリケーションのスケーリングを高速化した方法についてお話しいただきました。 このブログ記事では、re:Invent 2019 からの Amazon DocumentDB 録画セッションについてまとめていきます。 DAT372 – データベースを Amazon DocumentDB へ移行する Amazon DocumentDB のシニアスペシャリストソリューションアーキテクトである Jeff Duffy が、顧客戦略および Amazon DocumentDB への移行の際の検討事項の概要についてお話しします。セッションには、リレーショナルおよび非リレーショナルソース、移行のフェーズ (検出/計画/テスト/実行)、クラスターサイジング、および移行ツーリングについてのディスカッションが含まれます。セッションの目玉となったのは、FINRA が XML を利用して、どのようにしてリレーショナルデータベースから Amazon DocumentDB へ移行したかについての講話でした。アプリケーションから必要とされる変換レイヤーがないため、FINRA は Amazon DocumentDB によって JSON をデータベースでネイティブに使用し、よりスピーディーな移行を行えています。また、FINRA は Amazon DocumentDB がどのように SLA とセキュリティ要件の高い基準を満たしたかについても説明しています。 […]

Read More

AWS Local Zones がロサンゼルスで利用可能に

AWS のお客様は、より多くの機能、より多くの帯域幅、より高いの計算能力、より多くのメモリを常に求める一方で、レイテンシと価格の低下も求めています。これらの競合する要求を満たすために最善を尽くします。新しいEC2 インスタンスタイプ、EBS ボリュームタイプ、およびS3 ストレージクラスを迅速にローンチし、定期的に価格を下げていきます。 ロサンゼルスでの AWS 本日、カリフォルニア州ロサンゼルスで Local Zone を開始します。Local Zone は、特定の地理的エリアに非常に近い AWS のサービスを選択する新しいタイプの AWS インフラストラクチャのデプロイメントです。この Local Zone は、ロサンゼルスや南カリフォルニアの他の場所からアクセスされるアプリケーションに非常に低いレイテンシ (ミリ秒 1 桁) を提供するように設計されています。レイテンシに特に敏感な非常に要求の厳しいアプリケーションからは特に関心が得られるでしょう。本サポートに含まれるものは次のとおりです。 メディア&エンターテインメント – ゲーム、3D モデリングとレンダリング、ビデオ処理 (リアルタイムの色補正を含む)、ビデオストリーミング、メディア制作パイプライン。 電子設計自動化 – インタラクティブな設計とレイアウト、シミュレーション、検証。 Ad-Tech – 迅速な意思決定と広告配信。 機械学習 – 高速で継続的なモデルトレーニング。高性能で低遅延の推論。 Local Zone の詳細 ロサンゼルスの新しい Local Zone は、米国西部 (オレゴン)リージョン (これを親リージョンと呼びます) の論理的な部分であり、いくつかのユニークで興味深い特性があります。 : ネーミング – Local Zone には、プログラムで us-west-2-lax-1a […]

Read More

Amazon S3 Access Points で共有データセットの管理が簡単に

安全で、スケーラブルで、耐久性があり、可用性の高いストレージは、クラウドコンピューティングの基本的なコンポーネントです。それが、AWS が 2006 年に Amazon Simple Storage Service (S3) を開始したそもそもの理由です。これは、AWS が現在提供している 175 を超えるサービスの多くの構成要素になっています。2020 年代が間近に迫る中、Amazon Redshift、Amazon Athena、Amazon EMR および AWS Lake Formation により、S3 は、オブジェクトだけでなくエンジンも格納する方法にもなり、データを洞察に変えていきます。これらの機能は、バケットに保存されたデータのアクセスパターンと要件が進化したことを意味します。 本日、S3 で共有データセットの大規模なデータアクセスを管理する新しい方法、Amazon S3 Access Points をローンチします。S3 Access Points は、そのエンドポイントを使用してデータにアクセスする方法を記述する専用のアクセスポリシーを持つ一意のホスト名です。S3 Access Points 以前は、データへの共有アクセスは、バケット上の単一のポリシード2020キュメントを管理することを意味していました。これらのポリシーは、多くの異なる権限を持つ数百のアプリケーションを表し、監査と更新が多くのシステムに影響を及ぼす潜在的なボトルネックになる可能性がありました。 S3 Access Points を使用すると、アプリケーションやチームを追加するときにアクセスポイントを追加でき、ポリシーを具体的かつ管理しやすくします。バケットには複数のアクセスポイントを含めることができ、各アクセスポイントには独自の AWS Identity and Access Management (IAM) ポリシーがあります。アクセスポイントポリシーはバケットポリシーに似ていますが、アクセスポイントに関連付けられています。S3 Access Points は、Amazon Virtual Private Cloud 内からのアクセスのみを許可するように制限することもできます。また、各アクセスポイントには一意の DNS 名があるため、AWS […]

Read More

Amazon SageMaker Processing – 完全マネージド型のデータ処理とモデル評価

本日、フルマネージドインフラストラクチャで前処理、後処理、およびモデル評価のワークロードを簡単に実行できる、Amazon SageMaker の新機能、Amazon SageMaker Processing をリリースいたしました。 高精度な機械学習 (ML) モデルをトレーニングするにはさまざまな手順を踏む必要がありますが、中でもデータセットの前処理が最も重要となるでしょう。たとえば: 使用中の ML アルゴリズムに合う入力形式にデータセットを変換する、 既存の特徴をより表現力のある表現 (one-hot エンコーディングカテゴリ別特徴など) に変換する、 数値特徴を再スケーリングまたは正規化する、 高レベル特徴量エンジニアリングを行う (例: 住所を GPS 座標に置き換える)、 自然言語処理アプリケーションのテキストをクリーニングし、トークン分割する、 などなど! これらのタスクは、(とても大変な) データセットに対する特注スクリプトの実行と、後でトレーニングジョブで使用する処理済みバージョンの保存を伴います。ご想像のとおり、それらを手動で実行したり、オートメーションツールを構築およびスケールしたりする必要があることを考えると、ML チームは気が重くなります。後処理ジョブ (フィルタリングや照合など) やモデル評価ジョブ (さまざまなテストセットに対するモデルのスコアリング) についても同じことが言えます。 この問題を解決するために、私たちは Amazon SageMaker Processing を構築しました。それでは、詳細を説明しましょう。 Amazon SageMaker Processing のご紹介 Amazon SageMaker Processing には、データサイエンティストと ML エンジニアが Amazon SageMaker で前処理、後処理、およびモデル評価ワークロードを簡単に実行できる新式の Python SDK が導入されています。 この SDK では […]

Read More

Amazon Elasticsearch Service 向け UltraWarm (プレビュー版) 発表

  本日、Amazon Elasticsearch Service 向けの低コストの完全マネージド型ウォームストレージ層である UltraWarm を発表します。UltraWarm はプレビューでご利用いただけます。UltraWarm はAmazon Elasticsearch Service でホットウォームティアリングを提供する新しいアプローチを採用し、最大 900TB のストレージを提供。既存のオプションに比べて、ほぼ 90% のコスト削減を実現しています。UltraWarm は、Amazon Elasticsearch Service エクスペリエンスのシームレスな拡張機能であり、使い慣れた Kibana インターフェイスから、ホットデータと UltraWarm データの両方をクエリおよび視覚化できます。UltraWarm データは、現在使用しているのと同じ API とツールを使用してクエリできます。また、保管中および転送中の暗号化、統合アラート、SQL クエリなどの一般的な Amazon Elasticsearch Service 機能もサポートしています。 Amazon Elasticsearch Service のお客様に人気のユースケースは、大量の (そしてますます増加している) マシン生成ログデータを取り込んで分析することです。ただし、これらのお客様からは、より多くのこのデータに対してリアルタイム分析を実行したいので、それを使用して運用とセキュリティの問題を迅速に解決するのに役立てたいとの声が寄せられています。数か月、さらには数年分のデータの保存と分析は費用がかかりすぎてしまうため、複数の分析ツールを使用する人もいれば、貴重なデータをただ削除して洞察を逃してしまう人もいます。UltraWarm は、Amazon Simple Storage Service (S3) に裏打ちされた費用対効果の高いストレージで、この問題の解決に役立ち、お客様は長年蓄積してきたデータを保持して分析できます。 UltraWarm のリリースにより、Amazon Elasticsearch Service は、ホットウォームと UltraWarm の 2 つのストレージ層をサポートできるようになります。ホットティアは、インデックス作成、更新、およびデータへの最速アクセスの実現に使用します。UltraWarm は、ホットティアを補完して、アクセス頻度の低い古い大量のデータのサポートを強化し、ストレージコストを削減できる利点があります。前述したように、UltraWarm はデータを […]

Read More

Deep Graph Library が Amazon SageMaker で利用可能に

本日ここに、グラフニューラルネットワークを簡単に実装できるよう構築されたオープンソースライブラリ、Deep Graph Library が、Amazon SageMaker で利用可能になったことをお知らせします。 近年、自由形式のテキスト、画像、動画など、複雑なデータから詳細なパターンを抜き出すことができる、驚異的な性能の深層学習が世界に旋風を巻き起こしています。しかし、多くのデータセットはこれらのカテゴリーに当てはまらないため、グラフの方がわかりやすく表すことができます。 畳み込みニューラルネットワークや再帰型ニューラルネットワークのような、従来のニューラルネットワークのアーキテクチャは、そのようなデータセットに適していないことは直感的にも感じられ、新しいアプローチが必要となります。 グラフニューラルネットワークの初歩 グラフニューラルネットワーク (GNN) は、今日の機械学習におけるもっとも画期的な発展事項です。手始めに、これらの参考資料をご覧になるとよいでしょう。 GNN は、以下のような予測モデルのトレーニングに使用されています。 ソーシャルネットワーク。関連する利用者同士のつながりをグラフ化 推奨システム。顧客とアイテムの間のやり取りをグラフ化 化学分析。原子や結合をグラフ化して化合物のモデルを作成 サイバーセキュリティ。発信元と発信先の IP アドレスの接続状況をグラフ化で説明 その他多数のモデル ほとんどの場合、これらのデータセットは非常に大きく、部分的なラベル付けしかできません。ある個人から既知の不正を行う者への接続状況を分析することで、その個人が不正を行っている可能性を予測する、不正行為検出シナリオを考えてみましょう。この問題は、グラフノードの一部のみがラベル付けされる (「不正」か「正当」)、半教師あり学習タスクとして定義できます。これは大きなデータセットを手作業のラベル付けにより構築し、「線形化」して従来の機械学習アルゴリズムに適用するよりも良いソリューションになるはずです。 これらの問題に対処するためには、分野の専門知識 (小売、財務、化学など)、コンピューターサイエンスの知識 (Python、深層学習、オープンソースツール)、インフラストラクチャの知識 (トレーニング、デプロイ、モデルのスケーリング) が必要です。これらのスキルをすべてマスターしている人はごくわずかです。それが Deep Graph Library や Amazon SageMaker のようなツールが必要とされる理由です。 Deep Graph Library の紹介 2018 年 12 月に Github で初めてリリースされた Deep Graph Library (DGL) は Python のオープンソースライブラリーで、研究者や科学者がデータセットの GNN を迅速に構築、トレーニング、評価するのに役立ちます。 DGL は、PyTorch […]

Read More

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

新機能 – 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