Category: Advanced (300)

Application Auto Scaling は、Amazon Elastic Container Service (Amazon ECS) サービス、Amazon DynamoDB テーブル、AWS Lambda のプロビジョニングされた同時実行などのスケーラブルな AWS サービスに向けた、リソースを自動的にスケーリングするソリューションを必要とする開発者やシステム管理者向けのウェブサービスです。Application Auto Scaling では、Amazon CloudWatch のカスタムメトリクスに基づくスケーリングポリシーを使用して、このようなリソースをスケーリングできるようになりました。これらのメトリクスは、メトリクスの数学式に照らして評価されます。この記事では、この機能がどのように機能するかを、サンプルシナリオを使ってデモします。このシナリオでは、サービスが処理する HTTP リクエストの平均レートに基づいて、Amazon ECS サービスをスケーリングします。

AppSync の Private API の一般提供を発表します。Private API を使用すると、VPC やオンプレミスのデータセンターなどのプライベートネットワーク内のクライアントのみに、お客様の GraphQL API へのアクセスを制限できます。Private API へのリクエストは、インターネットを介さずに AWS のプライベートネットワークを経由して行われます。開始するには、AppSync で GraphQL API を作成する際に API を Private に設定し、API を呼び出す同じ AWS アカウント内の各 VPC にインターフェース VPC エンドポイントを作成します。また、AWS Direct Connect または AWS Site to Site VPN を使用して、オンプレミスネットワークからインターフェイスエンドポイントをホストする VPC へのプライベート接続を確立することができます。この接続により、オンプレミスデータセンターのクライアントは Private API を呼び出すことができます。

アプリケーションや IT インフラストラクチャを AWS に移行する際は、既存のデータも移行する必要があります。移行するデータは移行元の環境に応じて変化し、ファイルサイズも多岐に渡ります。移行するデータの内、1 MB 未満のファイルが全体の 1 桁のパーセンテージ以上含まれていた場合、移行のパフォーマンスは低下する可能性があります。

2023年5月4日、Amazon SageMaker が AWS Inferentia2 (ml.inf2) と AWS Trainium (ml.trn1) ベースの SageMaker インスタンスをサポートして、リアルタイムおよび非同期推論のための生成系 AI モデルをホストすることを発表しました。この記事では、大規模モデル推論 (LMI) コンテナを活用して、SageMaker を使用して AWS Inferentia2 に大規模な言語モデルをデプロイするプロセスを示します。

AWS Backup と VMware Cloud on AWS が、オンプレミスで VMware ワークロードを実行しているお客様にバックアップ、マイグレーション、およびディザスタリカバリのためのシンプルなソリューションを提供できるということを紹介します。お客様は、オンプレミスの VMware ワークロードを AWS クラウドに移行し、データ保護ソリューションをコスト効率よく拡張でき、運用の複雑さも最小限に抑えることができます。

多くのお客様は、AWS Application Migration Service (MGN)を使用してAWS […]

本稿では、AWS Inferentia2 上で大規模言語モデルをデプロイする方法を解説します。ここでは、AWS Neuron ソフトウェア開発キット (SDK) を使って Inferentia デバイスにアクセスし、その高いパフォーマンスの恩恵を受けます。そして、モデルサービングのソリューションとして、Deep Java Library (DJLServing) を搭載した大規模モデル推論コンテナを使用します。Amazon Elastic Compute Cloud (Amazon EC2) の inf2.48xlarge インスタンスに OPT-13B モデルをデプロイし、これら3つのレイヤーがどのように連携しているかをデモンストレーションします。

このブログは、Everton Fraga によって書かれた Introducing token-based a […]

データをクラウドに移行するには、さまざまなタイプのデータ移行経験や、ソースデータ構造やメタデータを保持する仕組みが必要です。お客様はオンプレミスのファイルデータを従来のファイルサーバーに格納する際、データライフサイクル管理等の理由でデータ作成時のタイムスタンプを併せて保持することが多くあります。一方でお客様は、データ構造やメタデータを保持しハイブリッドクラウド構成をサポートするような、クラウドへの移行方法を悩まれているのではないでしょうか。その結果として、お客様はコストやパフォーマンス、スケールなど、クラウドストレージのメリットを最大限享受できなくなります。

Amazon OpenSearch Service を運用していく中で、クラスター構成やインデックス設定がワークロードに適していないことでパフォーマンスの問題が生じることがあります。短期的にはクラスタのスケールといった対処も必要ですが、原因を精査することがその後の運用において重要です。本記事では、パフォーマンストラブルが起きた際に確認すべきポイントを、順を追って紹介していきます。各ポイントは質問の形式で記載されているので、質問への回答を作成しながら根本原因の調査や、対処を検討するための参考情報を整理することができます。