チームを編成して優れたソフトウェア製品を提供するには、さまざまな方法があります。 Amazon の Two-Pizza チーム のように、製品に関するエンドツーエンドの責任を単一のチームに割り当てている企業もあれば、複数のチームがインフラストラクチャ (またはプラットフォーム) チームとアプリケーション開発チームの間で責任を分担している企業もあります。この記事では、 AWS Cloud Development Kit (CDK) を活用して Split-Team アプローチの場合に、コラボレーションの効率をどのように改善できるかについてのガイダンスを提供します。 AWS CDK は、クラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。そのためには、TypeScript、Python、Java、C#、Go などの使い慣れたプログラミング言語を使用します。これにより、従来のインフラストラクチャでは AWS CloudFormation や HashiCorp Terraform などの IaC ツールで表現されてきたインフラストラクチャを定義するコードと、アプリケーションをバンドル、コンパイル、パッケージングするコードを組み合わせることができます。 これは、製品に関連するすべてのコードを 1 か所と 1 つのプログラミング言語にまとめることができるため、エンドツーエンドの責任を持つ自律的なチームに最適です。1 つのチームでインフラストラクチャコードとアプリケーションコードを別のリポジトリに分ける必要はありませんが、チームが分割されるモデルについてはどうでしょうか。 大企業は通常、インフラストラクチャ (またはプラットフォーム) チームとアプリケーション開発チームの間で責任を分担します。この記事では複数のチームが関与している場合でも、AWS CDK を使用してチームの独立性と俊敏性を確保する方法を見ていきます。チームごとに異なる責任と各チームが作成した成果物を見ていきます。また、チームがスムーズに連携する方法についても説明します。 このブログ記事は、AWS CDK とその概念に関する基本的な知識があることを前提としています。さらに、イベント駆動型アーキテクチャに関する非常に高いレベルの理解も必要です。 チームトポロジ まず、さまざまなチームトポロジと各チームの責任について簡単に見てみましょう。 One-Team アプローチ このブログ記事では、以降で説明する Split-Team アプローチに焦点を当てます。ただし、「1 つのチームがアプリケーションをエンドツーエンドで所有する」という “One-Team” アプローチが何を意味するのかを理解しておくと役に立ちます。この部門の枠を超えたチームは、次に実装する機能、使用するテクノロジー、そしてその結果得られるインフラストラクチャとアプリケーションコードの構築方法とデプロイ方法を独自に決定します。チームの責任は、インフラストラクチャ、アプリケーションコード、デプロイメント、開発したサービスの運用です。 このような環境で AWS CDK アプリケーションを構築する方法に興味がある場合は、Alex Pulver のブログ記事 “ Recommended AWS CDK project structure for Python applications ” を参照してください。 Split-Teamアプローチ 実際には、アプリケーション開発とインフラストラクチャの開発と展開を別々のチームに分けるお客様が多く居ます。 インフラストラクチャチーム ここで言及するインフラストラクチャチームは、プラットフォームチームまたは運用チームとも呼ばれます。インフラストラクチャチームは、他のチームがアプリケーションを実行するために使用する共有のインフラストラクチャを設定、デプロイ、運用します。これには、 Amazon SQS キュー、 Amazon Elastic Container Service (Amazon ECS) クラスター、新しいバージョンのアプリケーションを本番環境に導入するために使用される CI/CD パイプラインなどがあります。 アプリケーションチームが開発したアプリケーションパッケージを AWS にデプロイして実行させること、およびアプリケーションの運用サポートを提供する事がインフラストラクチャチームの責任です。 アプリケーションチーム 従来、アプリケーションチームはアプリケーションのパッケージ (JAR ファイルや npm パッケージなど) を提供するだけで、AWS でのデプロイ、設定、実行の方法を考えるのはインフラストラクチャチームの責任でした。しかしながら、インフラストラクチャチームは複数のチームが開発したさまざまなアプリケーションをサポートしなければならないため、このような従来の手法ではボトルネックになることがよくあります。さらに、インフラストラクチャチームは多くの場合、それらのアプリケーションの内部構造についてほとんど知識がありません。これはしばしば、サービスのために最適化された選択肢を提供できないことにつながります。インフラストラクチャチームが提供するサービス実行のための選択肢が十分でない場合、アプリケーションチームはワークロードに最適化されたオプションを使用できません。 そのため、このブログ記事では、アプリケーションチームの従来の責任を拡張しています。チームはアプリケーションを提供し、さらにアプリケーションの実行に必要なインフラストラクチャの説明も提供します。「必要なインフラストラクチャ」とは、アプリケーションの実行に使用される AWS サービスのことです。このインフラストラクチャの説明は、インフラストラクチャチームが理解できる形式で記述する必要があります。 このような責任範囲の変化によってアプリケーションチームに追加のタスクが追加されることは理解していますが、長期的には努力する価値があると考えています。これが DevOps の概念を組織に導入する出発点になり得ます。ただし、このブログ記事で説明されている概念は、アプリケーションチームにこの責任を課したくない場合にも、まだ有効です。誰が何を提供するのかという境界線が、インフラストラクチャチームの方へ更に移るだけです。 このアプローチを成功させるには、アプリケーションの引き渡し方、インフラストラクチャの定義、本番環境への導入方法について、2 つのチームが共通の形式について合意する必要があります。Construct というコンセプトを備えた AWS CDK は、そのための役立つ手段を提供します。 入門: AWS CDK Construct このセクションでは、コードを構築するために AWS CDK が提供する概念と、これらの概念を使用して CDK プロジェクトをチームトポロジにフィットさせる方法を見ていきます。 Constructs Construct は AWS CDK アプリケーションの基本的な構成要素です。AWS CDK アプリケーションは複数の Construct で構成されており、最終的には AWS CloudFormation によってデプロイされる方法と内容が定義されます。 AWS CDK には、AWS サービスをデプロイするための Construct が付属しています。ただし、使用できるのは AWS CDK によって提供される Construct だけに限定されないことを理解しておくことが重要です。AWS CDK の真の利点は、デフォルトの Construct の上に独自の抽象化を作成して、特定の要件を満たすソリューションを作成できることです。これを実現するには、独自のカスタム Construct を作成、公開、使用する必要があります。特定の要件をコード化し、抽象化レベルを高め、他のチームがその Construct を利用したり使用したりできるようにします。 以降ではカスタム Construct を使用して、アプリケーションとインフラストラクチャチームの責任を分担します。アプリケーションチームは、アプリケーションコードの実行に必要なインフラストラクチャとその 設定を記述した Construct をリリースします。インフラストラクチャチームはこの Construct を使用して AWS にワークロードをデプロイして運用します。 Split-Team で AWS CDK を使用する方法 次は、AWS CDK を使用してアプリケーションチームとインフラストラクチャチームの間で責任を分担する方法を見てみましょう。サンプルシナリオを紹介し、このシナリオにおける各チームの責任を説明します。 シナリオ 架空のアプリケーション開発チームが AWS Lambda 関数を作成し、AWS にデプロイします。 Amazon SQS キュー内のメッセージがこの関数を呼び出します。関数が注文を処理し (この例では詳細な意味は関係ありません)、各注文はキュー内のメッセージによって表されるとします。 アプリケーション開発チームは AWS Lambda 関数を柔軟に作成できます。どのランタイムを使用するか、どのくらいのメモリを設定するかを決定できます。関数が処理する SQS キューは、インフラストラクチャチームによって作成されます。アプリケーションチームは、メッセージがどのようにキューに入るのかを知る必要はありません。 これで、チームごとに実装例を見ていきましょう。 アプリケーションチーム アプリケーションチームは、アプリケーションコード (JAR ファイルや npm モジュールなど) と、アプリケーションの実行に必要なインフラストラクチャ (AWS Lambda 関数とその設定) を AWS にデプロイするための AWS CDK Construct という 2 つの異なる成果物を担当します。 これらの成果物のライフサイクルは異なります。アプリケーションコードは、実行されるインフラストラクチャよりも頻繁に変更されます。だからこそ、成果物は別々にしておきたいのです。これにより、それぞれの成果物は、変更された場合のみ独自のペースでリリースできます。 このような個別のライフサイクルを実現するためには、アプリケーションのリリースは CDK Construct のリリースから完全に独立している必要があることに注意することが重要です。これは、CDK Construct 内でアプリケーションコードをビルドしてパッケージ化する標準的な CDK の方法と比較して、チームを分けるという私たちのアプローチに合っています。 しかし、このサンプルソリューションではどのように実現するのでしょうか？チームは CDK に関係のないアプリケーションを構築して公開します。 この Construct を含む CDK スタックを合成すると、指定されたバージョン番号のビルド済みアーティファクトを AWS CodeArtifact からダウンロードし、それを使用して Lambda 関数のための zip ファイルを作成します。CDK の合成の間は、アプリケーションパッケージのビルドは行われません。 Constructとアプリケーションコードを分離したので、CodeArtifact から取得するアプリケーションコードの特定のバージョンを CDK Construct に伝える方法を見つける必要があります。この情報をコンストラクターのプロパティを介してConstructに渡します。 アプリケーションチームの責任範囲外のインフラストラクチャへの依存関係については、依存性注入のパターンに従います。共有 VPC や Amazon SQS キューなどの依存関係は、インフラストラクチャチームから Construct に渡されます。 例を見てみましょう。SQS キューへの外部依存関係を、目的の appPackageVersion とその CodeArtifact の詳細とともに渡します。 export interface OrderProcessingAppConstructProps { queue: aws_sqs.Queue, appPackageVersion: string, codeArtifactDetails: { account: string, repository: string, domain: string } } export class OrderProcessingAppConstruct extends Construct { constructor(scope: Construct, id: string, props: OrderProcessingAppConstructProps) { super(scope, id); const lambdaFunction = new lambda.Function(this, 'OrderProcessingLambda', { code: lambda.Code.fromDockerBuild(path.join(__dirname, '..', 'bundling'), { buildArgs: { 'PACKAGE_VERSION' : props.appPackageVersion, 'CODE_ARTIFACT_ACCOUNT' : props.codeArtifactDetails.account, 'CODE_ARTIFACT_REPOSITORY' : props.codeArtifactDetails.repository, 'CODE_ARTIFACT_DOMAIN' : props.codeArtifactDetails.domain } }), runtime: lambda.Runtime.NODEJS_16_X, handler: 'node_modules/order-processing-app/dist/index.lambdaHandler' }); const eventSource = new SqsEventSource(props.queue); lambdaFunction.addEventSource(eventSource); } } lambda.Code.fromDockerBuild(...) というコードに注意してください。ここでは AWS CDK の機能を使用して、Docker ビルドを介して Lambda 関数のコードをバンドルしています。提供された Dockerfile 内で発生する処理は以下のものだけです。 事前ビルド済みのアプリケーションコードのパッケージが格納されている AWS CodeArtifact リポジトリへのログイン アプリケーションコードのアーティファクトを AWS CodeArtifact (この場合は npm 経由) からダウンロードしてインストールすること AWS CDK アセットをビルド、バンドル、デプロイする方法について詳しく知りたい場合は、 Cory Hall による記事 “ Building, bundling, and deploying applications with the AWS CDK ” を強くお勧めします。ここで説明している内容よりもずっと詳細に説明されています。 Dockerfile の例を見ると、上記の 2 つのステップが分かります。 FROM public.ecr.aws/sam/build-nodejs16.x:latest ARG PACKAGE_VERSION ARG CODE_ARTIFACT_AWS_REGION ARG CODE_ARTIFACT_ACCOUNT ARG CODE_ARTIFACT_REPOSITORY RUN aws codeartifact login --tool npm --repository $CODE_ARTIFACT_REPOSITORY --domain $CODE_ARTIFACT_DOMAIN --domain-owner $CODE_ARTIFACT_ACCOUNT --region $CODE_ARTIFACT_AWS_REGION RUN npm install order-processing-app@$PACKAGE_VERSION --prefix /asset 以下の点にご注意ください。 npm のインストールコマンドで --prefix /asset を使用します。これにより、CDK がコンテナーにマウントするフォルダーに依存関係をインストールするよう npm に指示します。Docker build の出力に含まれるはずのすべてのファイルをここに配置する必要があります。 aws codeartifact login を続行するには、適切な権限を持つ認証情報が必要です。これを AWS CodeBuild や CDK Pipelines 内で実行する場合は、使用するロールに適切なポリシーがアタッチされていることを確認する必要があります。 インフラストラクチャチーム インフラストラクチャチームは、アプリケーションチームが公開した AWS CDK Constructを使用します。彼らはアプリケーション全体を構成する AWS CDK スタックを所有しています。おそらく、これはインフラストラクチャチームが所有する複数のスタックのうちの 1 つに過ぎないでしょう。他のスタックは、共有インフラストラクチャ (VPC、ネットワークなど) や他のアプリケーションを作成する可能性があります。 アプリケーションのスタック内では、インフラストラクチャチームがアプリケーションチームの Construct を利用してインスタンス化し、依存関係を解決してから、適切と思われる手段 (AWS CodePipelines、GitHub Actions、またはその他の CI/CD ツール) でスタックをデプロイします。 アプリケーションチームの Construct への依存関係は、インフラストラクチャチームの CDK アプリの package.json に表れています。 { "name": "order-processing-infra-app", ... "dependencies": { ... "order-app-construct" : "1.1.0", ... } ... } 作成された CDK スタックには、アプリケーションパッケージの依存バージョンと、インフラストラクチャチームが追加情報（使用するキューなど）を渡す方法が表示されます。 export class OrderProcessingInfraStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const orderProcessingQueue = new Queue(this, 'order-processing-queue'); new OrderProcessingAppConstruct(this, 'order-processing-app', { appPackageVersion: "2.0.36", queue: orderProcessingQueue, codeArtifactDetails: { ... } }); } } 新しいリリースの普及 これで、各チームが所有するアーティファクトとともに、各チームの責任を整理できるようになりました。しかし、アプリケーションチームが行った変更を本番環境に反映するにはどうすればよいでしょうか。あるいは、アプリケーションチームの最新バージョンのアーティファクトを使用して、インフラストラクチャチームの CI/CD パイプラインを呼び出すにはどうすればよいでしょうか。 アプリケーションまたは AWS CDK Construct のいずれかの新しいバージョンが公開されるたびに、インフラストラクチャチームのアプリケーションチームのアーティファクトへの依存関係を更新する必要があります。依存関係が更新されたら、リリースパイプラインを開始できます。 1 つのアプローチは、 Amazon EventBridge 経由で AWS CodeArtifact によって発行されたイベントを受け取ることです。リリースごとに、AWS CodeArtifact は Amazon EventBridge にイベントを発行します。そのイベントのペイロードから新しいリリースのバージョン番号を抽出し、CDK Construct への依存関係 (例えば CDK アプリケーションの package.json) を更新するワークフローを開始するか、インフラストラクチャチームが利用する Construct に渡す appPackageVersion を更新するワークフローを開始できます。 新しいアプリケーションのリリースがシステム内を流れる仕組みは次のとおりです。 図 1 — アプリケーションパッケージがリリースされると、インフラストラクチャチームの CDK スタックが変更され、デプロイされる アプリケーションチームは新しいアプリケーションバージョンを AWS CodeArtifact に公開します。 CodeArtifact は Amazon EventBridge でイベントをトリガーします。 インフラストラクチャチームが発行されたイベントを受け取ります。 インフラストラクチャチームは、最新の appPackageVersion が含まれるように CDK スタックを更新します。 インフラストラクチャチームの CDK スタックがデプロイされます。 図 2 – アプリケーションチームのCDK Constructの変更をトリガーにインフラストラクチャチームのCDK スタックが変更され、デプロイされる。 そして、CDK Constructの新しいバージョンのリリースも非常によく似ています。 アプリケーションチームは新しい CDK Construct を AWS CodeArtifact に公開します。 CodeArtifact は Amazon EventBridge でイベントをトリガーします。 インフラストラクチャチームが発行されたイベントを受け取ります。 インフラストラクチャチームは依存関係を最新の CDK Construct に更新します。 インフラストラクチャチームの CDK スタックがデプロイされます。 このようなワークフローがどのようになるかについては詳しく説明しません。なぜなら、各チーム向けに高度にカスタマイズされている可能性が高いからです (コードリポジトリや CI/CD に使用されるさまざまなツールを考えてみてください)。ただし、これをどのように実現できるかについてのアイデアをいくつか紹介します。 CDK Construct 依存関係の更新 CDK Construct の依存関係バージョンを更新するには、インフラストラクチャチームの package.json (または pom.xml のような依存関係の追跡に使用される他のファイル) を更新する必要があります。ソースコードをチェックアウトして npm install sample-app-construct@NEW_VERSION (NEW_VERSION は EventBridge イベントペイロードから読み取られた値) のようなコマンドを発行するオートメーションを構築できます。次に、この変更をメインブランチに組み込むためのプルリクエストを自動的に作成します。これがどのようなものかについてのサンプルは、ブログ記事 “ Keeping up with your dependencies: building a feedback loop for shared librares ” を参照してください。 appPackageVersion の更新 インフラストラクチャチームの CDK スタック内で使用されている appPackageVersion を更新するには、上記と同じ方法に従うか、CDK の機能を使用して AWS Systems Manager (SSM) Parameter Store から読み取ることができます。そうすれば、 appPackageVersion の値をソース管理に入力するのではなく、SSM パラメータストアから値を読み取ることになります。その方法については、AWS CDK のドキュメントに Systems Manager Parameter Store から値を取得する というものがあります。次に、 パラメータが変更されたイベント に基づいてインフラストラクチャチームのパイプラインを開始します。 常に何がデプロイされているかを明確に把握し、CloudFormation で使用されているパラメーター値を確認するために、 合成時の Systems Manager の値を読み取り で説明されているオプションを使用することをおすすめします。 結論 複数のチーム (この場合はアプリケーション開発チームとインフラストラクチャチーム) が協力してアプリケーションの新しいバージョンを本番環境に導入する場合でも、AWS Cloud Development Kit とその Construct のコンセプトがチームの独立性と俊敏性を確保するのにどのように役立つかを見てきました。そのために、アプリケーションチームにアプリケーションコードだけでなく、アプリケーションを実行するために使用するインフラストラクチャの部分の管理も任せました。すべての共有インフラストラクチャと最終的なデプロイメントはインフラストラクチャチームが管理し、アプリケーションチームの Construct はこの中で利用されるため、ここまで見てきた Split-Team アプローチと合致しています。 著者 ソリューションアーキテクトとして、Jörg はドイツの製造業のお客様と協力しています。2019 年に AWS に加入する前は、開発者、DevOps エンジニア、SRE など、さまざまな役割を担当していました。そのため、Jörg はビルドと自動化のことが大好きです。AWS Cloud Development Kit に恋をしたのです。 Mo は2020年にテクニカルアカウントマネージャーとして AWS に加入し、7年間の AWS DevOps の実践経験と6年間のシステム運用管理者としての経験を持っています。 AWS 内の2つのコミュニティ(クラウド運用とビルダーエクスペリエンス)のメンバーであり、CI/CD パイプラインと AI for DevOps を使って、ビジネスニーズに合った適切なソリューションを持っていることを確認するために、お客様をサポートすることに焦点を当てています。 本記事は、 Joerg Woehrle と Mohamed Othman による “Improve collaboration between teams by using AWS CDK constructs” を翻訳したものです。翻訳はソリューションアーキテクトの平川 大樹が担当しました。

11月26日、 Amazon Detective は、時間の節約とセキュリティ運用の強化に役立つ 4 つの新機能を追加しました。 1 つ目は、 IAM の Detective 調査 です。これは、セキュリティアナリストが、ユーザーやロールなどの AWS Identity and Access Management (IAM) オブジェクトを調査して 侵害の痕跡 (IOC) がないかを確認し、 MITRE ATT&CK フレームワーク に含まれる既知の戦術に関係している可能性があるかどうかを判断するのに役立ちます。これらの自動調査は、 AWS マネジメントコンソール の [Detective] セクションで利用でき、新しい API を通じて分析やインシデント対応を自動化したり、 AWS Security Hub や SIEM などの他のシステムに検出結果を送信できます。 2 つ目は、 Detective 検出結果グループの要約 です。これは、生成系人工知能 (AI) を使用して調査をエンリッチ化します。検出結果グループを自動的に分析し、自然言語でインサイトを提供することで、セキュリティ調査を加速します。イベントを開始したアクティビティとその影響 (存在する場合) の説明など、関連する要約されたインサイトを含む検出結果グループの分析に基づいて、平易な言葉でタイトルを提供します。検出結果グループの要約は、複数の AWS データソースにわたって構築された検出結果グループの分析という面倒な作業を処理するため、異常なアクティビティや疑わしいアクティビティをより簡単かつ迅速に調査できます。 この記事で説明するこれらの 2 つの新機能に加えて、Detective は、ここでは取り上げていない別の 2 つの機能を追加しています。 Detective は、 Amazon GuardDuty ECS Runtime Monitoring によって検出される脅威についてのセキュリティ調査をサポートするようになりました。 Detective は Amazon Security Lake と統合し、セキュリティアナリストは Security Lake に保存されているログをクエリおよび取得できるようになりました。 Amazon Detective を利用すると、セキュリティに関する検出結果や疑わしいアクティビティの根本原因の分析、調査、および迅速な特定がより容易になります。Detective は、機械学習 (ML)、統計分析、グラフ理論を活用して、セキュリティ調査を視覚化し、より迅速かつ効率的に実施できるようサポートします。Detective は、 AWS CloudTrail ログ、 Amazon Virtual Private Cloud (Amazon VPC) フローログ 、 Amazon GuardDuty 検出結果、 Amazon Elastic Kubernetes Service (Amazon EKS) 監査ログ、AWS セキュリティ検出結果などのソースからログデータとイベントを自動的に収集します。Detective は、分析と調査のために最大 1 年分の集計データを保持します。 クラウドセキュリティの専門家は、脅威ハンティングとインシデント調査に、大量のリソースと長い時間を要すると感じることがよくあります。さまざまなソースからデータを手動で収集して分析し、潜在的な IAM 関連の脅威を特定する必要があります。IAM の調査は、クラウド許可と認証情報が動的であることにより、特に困難です。アナリストは、分散している可能性のある監査ログ、エンタイトルメントレポート、CloudTrail イベントなど、さまざまなシステムから得られたデータをまとめる必要があります。クラウドの許可は、多くの場合、オンデマンドで、またはオートメーションスクリプトを通じて付与されるため、認可の変更を追跡するのが困難です。アクティビティのタイムラインを再構築し、不規則なエンタイトルメントを特定するには、その複雑さに応じて、数時間から数日かかる場合があります。レガシーシステムについての可視性が限られ、ログが不完全である場合には、IAM の調査がさらに複雑になり、不正アクセスを明確に把握することが困難になります。 IAM の Detective 調査は検出結果に優先順位を付けて、極めて重大で疑わしい問題のみを明らかにするため、セキュリティアナリストは高度な調査に集中できます。機械学習と脅威インテリジェンスを使用して、AWS 環境内のリソースを自動的に分析し、潜在的な侵害の痕跡や疑わしいアクティビティを特定します。これにより、アナリストはパターンを特定し、どのリソースがセキュリティイベントの影響を受けるかを把握できるため、脅威の特定と緩和に対するプロアクティブなアプローチを採ることができます。 調査はコンソールで利用できるだけではありません。新しい StartInvestigation API を使用して、修復ワークフローを自動化したり、関係するすべての IP や侵害された AWS リソースに関する情報を収集したりできます。また、API を使用してデータを他のシステムにフィードし、セキュリティ体制の統合ビューを構築することもできます。 検出結果グループの要約は、環境全体のセキュリティイベント間の関係を評価し、関連する脅威、侵害されたリソース、悪意のある攻撃者の行動を結びつけるインサイトを自然言語で提供します。この説明は、個々のサービスレポートにとどまらないセキュリティインシデントの包括的な概要をセキュリティアナリストに提供します。複数のソースから得られたデータをグループ化およびコンテキスト化することにより、検出結果グループの要約は、インサイトが分離されている場合には気付かれない可能性のある脅威を特定します。このアプローチにより、調査と対応の速度と効率が向上します。セキュリティアナリストは、検出結果グループの要約を利用して、セキュリティイベントとその相互関係を総合的に理解できます。これは、封じ込めと修復に関して、十分な情報に基づいた意思決定を下すのに役立ちます。 これらの 2 つの機能がどのように動作するのかを見てみましょう このデモでは、 コンソールの [Detective] セクション にある IAM の Detective 調査から始めます。Detective ダッシュボードには、実行された調査の数と、疑わしいアクティビティに関与した IAM ロールおよびユーザーの数が表示されます。 そこから、調査のリストを詳しく確認します。 そして、特定の調査を 1 つ選択して詳細を把握します。最初に要約があります。 ページを下方向にスクロールして、どの IP アドレスが関与しているか、およびどのような種類のアクティビティに関与しているかを確認します。この例は、物理的な不可能性を示しています。短時間で、オーストラリアと日本という 2 つの異なる場所から同じ IP が使用されました。 私の意見では、このページで最も興味深いのは、 戦術、技術、手順 (TTP) に対するマッピングです。すべての TTP は重大度に従って分類されます。コンソールには、使用された技術とアクションが表示されます。特定の TTP を選択すると、右側のペインに詳細が表示されます。この例では、IAM ロールの信頼できるポリシーを変更しようとして失敗した 2,000 回を超える試行に、疑わしい IP アドレスが関与しています。 最後に、 [指標] タブに移動して指標のリストを確認します。 また、検出結果グループの要約は、 [検出結果グループ] で確認できます。検出結果グループを選択して、検出結果と関連するリスクについての自然言語での説明を確認します。 料金と利用可能なリージョン これらの 2 つの新機能は現在、すべての AWS のお客様にご利用いただけます。 IAM の Detective 調査は、 Detective が利用可能な すべての AWS リージョンでご利用いただけます。検出結果グループの要約は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール、東京)、欧州 (フランクフルト) の 5 つの AWS リージョンでご利用いただけます。 Amazon Detective に関するすべての詳細を確認し、今すぐ使用を開始しましょう 。 — seb 原文は こちら です。

イントロダクション Karpenter は AWS によって開発された Kubernetes のノードライフサイクルマネージャーで、クラスターのノードの設定を最小化することを目的として、2021 年にリリースされました。この 1 年で、GitHub の Star 数は 4900 を超え、200 人以上のコントリビューターによるコードがマージされるなど、素晴らしい成長を遂げています。現在、Kubernetes Autoscaling Special Interest Group の一部として、Cloud Native Computing Foundation (CNCF) に寄贈されるプロセスにあります。 このような成長の一貫として、alpha 版で行われた数々の破壊的な変更に対処したくないというユーザーに対して、より厳格な安定性を保証する Kubernetes API の成熟の需要が高まっています。これは、プロジェクトの進化において重要なマイルストーンになります。この移行によって顧客は、beta 版が提供する API の安定性と成熟度の向上による恩恵を受けます。またこれは、後方互換性を優先するという我々からのコミットメントを示しています。顧客は将来的な破壊的な変更に悩まされる必要なく、新しい機能や機能の拡張を自信を持って採用できます。このリリースは、以前のリリースと同様に、オープンソースコミュニティからのフィードバックを取り入れています。 API の変更は、Karpenter のバージョン 0.32.0 リリースの一部として展開されます。既存の Deployment をこのバージョンにアップグレードする必要があります。この記事で移行パスの概略について説明しており、Karpenter アップグレードガイド でさらに詳しく説明されています。 既存の alpha API は非推奨となり、この単一のバージョンでのみ利用可能です。 v0.33.0 のリリースから、Karpenter は v1beta1 API のみをサポートします。 Karpenter の API は alpha → beta → stable という成熟の過程をたどります。 alpha 版から beta 版への昇格には、この記事で強調している API の重大な変更を必要としました。beta 版から stable 版への昇格には、同じレベルの変更は必要ないと予測しています。 Kubernetes API の昇格プロセスについて興味がある方は、 こちらの記事 をご覧ください。 変更点について stable v1 に到達するまでの過程において、alpha 版から beta 版への移行に際して API に重要な変更を加えました。ユーザーにとってよく問題となる API の領域を削除することによって、使いやすさを向上させるためです。これらの領域のひとつがネーミングでした。provisioner という言葉の使用に際して混乱が生じていて (ストレージの領域では、多重定義された用語)、ユーザーが考える必要がある概念の数を減らしたいと考えていました。 今回のリリースで、Karpenter は Provisioner・AWSNodeTemplate・Machine API を廃止し、NodePool・EC2NodeClass・NodeClaim を導入しました。全体的な視点を捉え、Node という単一の概念を中心に API を合理化しました。 ウォークスルー API グループ と kind のネーミング v1beta1 バージョンでは、以下の新しい API が導入されている一方で、既存の API は廃止されています。 karpenter.sh/Provisioner は karpenter.sh/NodePool になる karpenter.sh/Machine は karpenter.sh/NodeClaim になる karpenter.k8s.aws/AWSNodeTemplate は karpenter.k8s.aws/EC2NodeClass になる これらのネーミングの変更にはそれぞれ、Karpenter の最新バージョンに更新する際に考慮する必要があるスキーマの変更が含まれます。各々の変更点と、新しい API 定義がどのようなものかを見てみましょう。 v1alpha5/Provisioner → v1beta1/NodePool NodePool は Provisioner の後継として機能し、スケジューリング中に Node と Pod 間の互換性に影響を与える、設定ベースのパラメータ (要件、Taint、Label など)を公開します。また Karpenter のスケジューリングやデプロビジョニングの意思決定を微調整するための、振る舞いベースの設定も含まれています。 NodePool はインスタンスタイプとサイズの組み合わせを解決する一方で、ワークロードがリソースをリクエストする方法には制限を課します。これは、プロビジョニングとデプロビジョニングの動作のグルーピングを促進します。重要なのは、ポータブルな設定を維持するためには、プールにクラウド固有の設定を持つべきではないということです。 Karpenter の v1beta1 では、全ての振る舞いに関わらないフィールドは NodePool テンプレートのフィールド内部でカプセル化されます。Karpenter の場合、NodePool が NodeClaims をテンプレート化し、それらは Karpenter コントローラーによってオーケストレートされます。これは Deployment コントローラーによって Pod がテンプレート化されオーケストレーションされる、Deployment のコンセプトを反映しています。 NodePool の詳細については、ドキュメントをご覧ください。 NodePool の例は以下のとおりです。 apiVersion: karpenter.sh/v1beta1 kind: NodePool ... spec: template: metadata: annotations: custom-annotation: custom-value labels: team: team-a custom-label: custom-value spec: nodeClassRef: name: default requirements: - key: karpenter.k8s.aws/instance-category operator: In values: [ "c", "m", "r" ] ... kubelet: systemReserved: cpu: 100m memory: 100Mi ephemeral-storage: 1Gi maxPods: 20 disruption: expireAfter: 360h consolidationPolicy: WhenUnderutilized Apache Configuration spec の例を見ると、disruption という新しいセクションがあることに気がつくでしょう。これにより、Consolidation、Expiration、空のノードに関する以前の設定 ( ttlSecondsAfterEmpty 、 ttlSecondsUntilExipred 、 consolidation.enabled ) がグループ化されます。 NodePool マニフェストが適用される時に明示的に指定されていない場合、Karpenter は disruption をデフォルトで設定します。デフォルト値は以下で強調されています。こららのフィールドの振る舞いの詳細については、 ドキュメント をご覧ください。 Field Default spec.disruption.consolidationPolicy WhenUnderutilized spec.disruption.expireAfter 720h v1alpha1/AWSNodeTemplate → v1beta1/EC2NodeClass EC2NodeClass は AWSNodeTemplate の後継として機能し、Node の起動やブートストラッププロセスに影響するクラウドプロバイダー固有のフィールドを公開します。これには、使用したい Amazon Machine Image (AMI)、セキュリティグループ、サブネットの設定、更にはブロックストレージ、ユーザーデータ、インタンスメタデータの設定に関する詳細が含まれます。 Karpenter の spec.instanceProfile フィールドは EC2NodeClass から削除され、 spec.role フィールドが選択されました。(訳注： spec.instanceProfile フィールドは v0.32.2 で追加されています。現在指定可能なフィールドについては、公式ドキュメントを参照してください。) Karpenter は、ユーザーが指定したロールが定義された EC2NodeClass に基づいて、インスタンスプロファイルを自動生成するようになりました。 既に非推奨となっていた管理対象外の起動テンプレートを参照するための spec.launchTemplateName フィールドが削除されました。そのため、このフィールドを使用している場合は、EC2NodeClass に移行する際に、管理対象外の起動テンプレートから、Karpenter が管理する起動テンプレートに移行する必要があります。 NodeClass の詳細については、 ドキュメント をご覧ください。EC2NodeClass の例は以下のとおりです。 apiVersion: karpenter.k8s.aws/v1beta1 kind: EC2NodeClass metadata: name: default spec: amiFamily: Bottlerocket role: KarpenterNodeRole-karpenter-demo subnetSelectorTerms: - tags: karpenter.sh/discovery: karpenter-demo securityGroupSelectorTerms: - tags: karpenter.sh/discovery: karpenter-demo tags: test-tag: test-value Apache Configuration v1alpha5/Machine→ v1beta1/NodeClaim Karpenter v0.28.0 では、Machine と呼ばれる新しいリソースタイプが追加されました。これにより、複数のノードのプロビジョニングが改善され、ネイティブの Kubernetes コントローラーがノードをクラスターに参加させながら、Karpenter がノードを管理および追跡できるようになりました。v0.28.0 以前の Karpenter のバージョンを使用している場合、このリソースタイプを使用することはできません。 v0.32.0 のリリースで、NodeClaim に変更されました。NodeClaim はクラスター管理者によって作成されることを意図したものではなく、かわりに Karpenter によって作成および削除されます。NodeClaim が機能するために何も変更する必要はないはずです。クラスター内のノードをトラブルシューティングする際に、Karpenter が管理しているノードのライフサイクルと状態を確認できます。 ラベルの変更 Karpenter の v1beta1 では、 karpenter.sh/do-not-evict と karpenter.sh/do-not-consolidate の共通ラベルに変更が加えられました。これらは廃止され、 karpenter.sh/do-not-disrupt という単一のラベルに統一されました。これらは Pod と Node の両方に適用でき、Karpenter がノードの中断や Pod の退避を実行することを防ぎます。 NodeClass の AMI、サブネット、セキュリティグループのためのより柔軟なセレクター 現在のセレクターの設定では、プロビジョニングされるノードに対して異なる設定を識別し使用する能力が、いくらか制限されていました。既存の動作では AND ロジックが適用されるため、様々なクラスターやリージョンで設定を一致させることが困難でした。これに対処するためにセレクターを拡張し、複数の条件を指定できるようにしました。これらの条件は OR ロジックを使って組み合わさるようになり、一致するものが特定されるまで、まとめて評価されることを意味します。 名前が my-name1 あるいは my-name-2 で、所有者が 123456789 または amazon の AMI を照合する場合の例は、以下のとおりです。 amiSelectorTerms: - name: my-name1 owner: 123456789 - name: my-name2 owner: 123456789 - name: my-name1 owner: amazon - name: my-name2 owner: amazon Apache Configuration subnetSelectorTerms と securityGroupSelectorTerms についても同様の設定を行うことができます。詳細については Karpenter の ドキュメント をご覧ください。 securityGroupSelectorTerms: - id: abc-123 name: default-security-group # Not the same as the name tag tags: key: value # Selector Terms are ORed - id: abc-123 name: custom-security-group # Not the same as the name tag tags: key: value Apache Configuration Drift がデフォルトで有効に 次のリリース (v0.33.0) から、Drift 機能はデフォルトで有効になります。Drift のフィーチャーゲートを指定しなかったら、この機能は有効であるとみなされます。Karpenter のコマンドライン引数で --feature-gates DriftEnabled=false を指定することで、Drift 機能を無効化できます。このフィーチャーゲートは core API (NodePool、NodeClaim) が v1 にバージョンアップされた時に、完全に削除される予定です。 移行パス Karpenter コントローラーの AWS IAM ロールを更新する Karpenter コントローラーは、AWS Identity and Access Management ( AWS IAM ) を使用して、AWS アカウント内で Amazon Elastic Compute Cloud ( Amazon EC2 ) インスタンスを起動および操作する権限を付与します。アップグレードの一貫として、以下のとおり新しいアクセス権限ポリシーを作成します。 ec2:RunInstances 、 ec2:CreateFleet 、 ec2:CreateLaunchTemplate に、以前のタグキー karpenter.sh/provisioner-name の代わりに、タグベースの制約 karpenter.sh/nodepool を追加しました。 iam:CreateInstanceProfile 、 iam:AddRoleToInstanceProfile 、 iam:RemoveRoleFromInstanceProfile 、 iam:DeleteInstanceProfile 、 iam:GetInstanceProfile といったアクションの許可を与えました。これらのアクセス権限は全てタグベースのポリシーによって制約され、コントローラーが作成に責務を持つインスタンスプロファイルのみを操作する権限を持っていることを保証します。これらは Karpenter が管理するインスタンスプロファイルをサポートするために必要です。 移行が完了し、以下の詳細の説明に従って新しいノードをロールアウトしたら、以前のアクセス権限ポリシーを安全に削除できます。 アクセス権限ポリシーの例は Karpenter の GitHub リポジトリ にあります。またプロジェクトを開始する AWS CloudFormation テンプレートの一部として配布されています。 API の移行 alpha 版から新しい v1beta1 版の API に移行するには、まず新しい v1beta1 の Custom Resource Definitions (CRD) をインストールする必要があります。その後、Provisioner と AWSNodeTemplates の両方について、alpha 版 API に相当する beta 版 のリソースを作成する必要があります。Machine から NodeClaim への移行は、カスタムリソースを Provisioner から NodePool に移行する際に Karpenter によって管理され、ユーザーにとってはシームレスである点に注目してください。 NodePool と EC2NodeClass オブジェクトの作成を効率化するために設計されたコマンドラインユーティリティツールである karpenter-convert を紹介できることを嬉しく思います。以下に、このツールを効果的に利用するための手順を示します。 コマンドラインユーティリティをインストールします。： go install github.com/aws/karpenter/tools/karpenter-convert/cmd/karpenter-convert@latest 各 Provisioner を NodePool に移行します。： karpenter-convert -f provisioner.yaml > nodepool.yaml 各 AWSNodeTemplate を EC2NodeClass に移行します。： karpenter-convert -f nodetemplate.yaml > nodeclass.yaml ツールによって生成された各 EC2NodeClass に対して、AWS IAM ロールを手動で指定する必要があります。ツールはプレースホルダー $KARPENTER_NODE_ROLE を残すので、実際のロール名に置き換える必要があります。 各 Provisioner のリソースについて、ノードを 1 つずつ入れ替えるか、全ての Provisioner ノードを一気に入れ替えるかを決定する必要があります。詳細な手順のガイドについては、以下のセクションに記載されています。 Drift による段階的なノードの入れ替え Drift を有効にした状態で、クラスター内の各 Provisioner に対して次のアクションを実行します。 alpha 版の CRD を v1beta1 に移行します。 karpenter.sh/legacy=true:NoSchedule のような Taint を古い Provisioner に追加します。 Karpenter の Drift は、その Provisioner によって所有される全てのマシン・ノードをドリフト済としてマークします。 Karpenter の Drift は、新しい NodePool リソースのノードを代替ノードとして起動します。 現在、Karpenter は一度に 1 つのノードの入れ替えのみサポートしています。すなわち、Karpenter が 1 つの Provisioner 配下の全てのノードを入れ替えるには、時間がかかる場合があります。 強制的な削除 クラスター内の各 Provisioner について、以下のアクションを実行します。 クラスター内に、v1alpha5 Provisioner・AWSNodeTemplate に対応する NodePool・EC2NodeClass を作成します kubectl delete provisioner <provisioner-name> --cascade=foreground で古い Provisioner を削除します Karpenter は、Provisioner によって所有される各々の Node を削除し、全ての Node に対して同時に排出を行い、Node が排出中の状態になったら新しく Pending 状態になった Pod 用の Node を起動します 手動での入れ替え クラスター内の各 Provisioner について、次の操作を実行します。 v1alpha5 のProvisioner・AWSNodeTemplate に対応する v1/beta1 NodePool・EC2NodeClass をクラスター内に作成します。 古い Provisioner に karpenter.sh/legacy=true:NoSchedule のような Taint を追加します。 kubectl delete node <node-name> を実行して、Provisioner によって所有される各ノードを 1 つずつ削除します。 まとめ この記事では、新しい API によって導入された変更を紹介し、コミュニティからのフィードバックによって形作られたこれらの変更の背景にある理由についての洞察を提供しました。Karpenter プロジェクトの成熟度の高まりを目の当たりにできてとれも嬉しいです。これらの変更の大部分は、最終的には stable v1 API に移行すると予想しています。これにより、幅広いユーザーベースが、ワークロードネイティブなノードのプロビジョニングにおける Karpenter の能力を最大限に活用できるようになります。 この記事では取り上げなかった廃止や変更が他にもいくつかあります。包括的な移行ガイドラインについては、Karpenter アップグレードガイド をご覧ください。 Karpenter を v0.32.0 にアップグレードする前に、 リリースノート を全て読むことを推奨します。質問があれば、Kubernetes slack #karpenter チャンネル または GitHub までお気軽にご連絡ください。新機能の優先順位付けと開発に役立つフィードバックをお待ちしています。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

生成系 AIの急速な成長は、有望な新しいイノベーションをもたらすともに、新たな課題も提起しています。お客様がお客様の環境のセキュリティに関する保証を規制当局や監査人に提供できるよう、AWS では責任を持って AI を開発することに全力を注いでいます。 AWS Audit Manager は、 Amazon Bedrock におけるエビデンス収集を自動化する生成系 AI の AWS ベストプラクティスフレームワークの最初のバージョンを発表しました。このフレームワークにより、お客様は生成系 AI の可能性を最大限に活用すると同時に倫理的で責任ある使用に関する懸念に対処できるようになります。 2020 年 12 月に提供が開始された AWS Audit Manager は、事前定義されたコントロールに対して、リソース構成と使用アクティビティなどの証拠収集を自動化し、お客様の AWS 利用状況が意図したポリシーや規制要件に合致するかどうかを監視するサービスです。2023年9月に一般提供が開始された Amazon Bedrock は、Amazon やその他の大手 AI 企業の基盤モデル (FM) を API を通じて利用できるフルマネージド型サービスで、既存の大規模言語モデル (LLM) を組織のデータでプライベートにチューニングすることも可能です。Amazon Bedrock のお客様は、生成系 AI モデルとアプリケーションを実行しているアカウントに、この新しいベストプラクティスフレームワークを AWS Audit Manager 経由でデプロイし、意図したポリシーへのコンプライアンスを監視するのに役立つ証拠を収集できます。 AWS の AI、コンプライアンス、セキュリティ保証に関する専門家が、AWS パートナーでグローバルな監査・保証会社であるデロイトによる追加レビューを受けながらこのフレームワークを開発しました。典型的なセキュリティまたはコンプライアンスのフレームワークは、特定のミッションや業界の目標に基づいて既知のリスクやエンティティを中心に境界線を構築します。このことを念頭に置き、規制やコンプライアンスが成熟するまでの間にお客様が革新的なテクノロジーを適切に活用するための心構えを形作ることを目指しています。 “生成 AI の標準的な使用例が広がるにつれて、毒性 (toxicity) や幻覚 (hallucination) などの生成 AI 固有のリスクに対処するための標準的な統制、生成系 AI のためのガードレール実装は今後ますます重要になります。AWS Audit Manager の提供する生成系 AI 向けフレームワークにより、組織は進化する AI リスクの監視を開始し、より多くの生成系 AI 活用の機会を模索できるようになります。” &nbsp; &nbsp;— Christina DeJong 公認会計士 — デロイト パートナー この新しいフレームワークは、正確性、公平性、プライバシー、レジリエンス、責任、安全性、セキュリティ、持続可能性の8つの重要なドメインにわたる32の目標のもと、110の統制項目をグループ化しています。これにより、生成系 AI システム、基盤となるモデル、お客様が入力するデータ、最終的に生成されるデータなど、各テクノロジー層におけるリスクに対処できます。例えば、モデルにデータを入力する前に既知のバイアスを軽減したいお客様は、このフレームワークの「Pre-processing Techniques（前処理に関する技術）」コントロールを用いて、データ拡張、再重み付け、リサンプリングなどに関する文書が、検証のための基準を満たしているかのエビデンスを要求することができます。 AWS Audit Manager での評価の設定方法 Audit Manager の生成系 AI フレームワーク v1のベストプラクティスを使うのは簡単です。Audit Manager 評価の作成を進める前に、以下の前提条件が整っていることを確認してください。 前提条件 Audit Manager が評価を作成するアカウントで Amazon Bedrock を実際に利用していること。Amazon Bedrockをまだセットアップしていない場合は、 以下の手順 に従って利用を開始してください。 Audit Manager が評価を作成するアカウントで有効化されていること。以前にアカウントで Audit Manager を有効にしたことがない場合は、 以下の手順 に従って利用を開始してください。 まず、AWS コンソールに移動し、Audit Manager を選択または検索します。 Audit Manager コンソールから、右上の [ 評価の作成 ] を選択します: 図 1. AWS Audit Manager で評価を作成 次に、2 つの必須情報を入力する必要があります。1 つは 300 文字以下の評価名、もう 1 つは評価レポートの出力先である S3 バケットです。オプションで、評価の説明を 1000 語まで入力できます: 図 2. 評価の詳細を指定 次に、標準フレームワークのリストから [AWS Generative AI Best Practices Framework v1] フレームワークを選択します: 図 3. 生成 AI ベストプラクティスフレームワークを選択 [新しいタグを追加] を選択して、タグを評価に関連付けます。各タグにキーと値を指定できます。タグキーは必須で、このアセスメントを検索する際の検索条件として使用できます。Audit Manager のタグの詳細については、「 AWS Audit Manager リソースのタグ付け 」を参照してください。オプションとして、評価に最大 50 個のタグを追加することが可能です: 図 4. 自動化を容易にするために、フレームワークにタグを追加 次に、評価の対象となる AWS アカウントを指定します。このデモ環境では、開発、ロギング、および単一の本番アプリケーションアカウントを選択しています。ユースケースによっては異なるかもしれませんが、ロギングアカウントを使用している場合は、そのアカウントを含めてそこにルーティングされる可能性のある関連イベントをキャプチャする必要があります。アカウントを指定したら、[次へ] を選択して続行します: 図 5. 評価対象のアカウントを選択 これは標準フレームワークでカスタムフレームワークではないため、Audit Manager はエビデンスの収集に必要なサービスを選択します (つまり、ここで選択されているサービスはこの評価でテスト可能なサービスの一覧ではなく、評価に必要なデータを収集するサービスの一覧となっているということです)。この画面では、あとは [次へ] を選択するだけです: 図 6. 対象となる AWS サービス ユーザー名またはロールで 1 人以上の [監査所有者 (audit owners)] を選択する必要があります。ここで選択されたエンティティは、この評価に変更を加えることが可能です。一般的には、組織内でそのような職務を担う人だけを選択します。監査所有者が決まったら、 [次へ] を選択して次に進みます: 図 7. この評価の監査所有者を選択 最後に、設定した内容がすべて表示されます。必要に応じて内容を変更し、設定内容に問題がなければ [ 評価を作成 ] を選択します: 図 8. 評価を作成 上のバナーにあるように、評価対象のアカウントで Amazon Bedrock が実際に使用されている場合は24 時間以内にエビデンスを確認できるようになるはずです。 さらに深く掘り下げたい場合は、より具体的なニーズに合わせてフレームワークをカスタマイズできます。AWS Audit Manager の標準フレームワークのカスタマイズに関する詳細については、 こちら をご覧ください。 このブログはソリューションアーキテクトの三厨が翻訳を担当しました。原文は こちら 。 著者について John Fischer John は AWS セキュリティ保証サービスチームのシニアアシュアランスコンサルタントであり、AWS Audit Manager のスペシャリストでもあります。余暇には演奏したり、妻や子供たちと過ごす時間を楽しんでいます。 Alexis Robinson Alexis は AWS のシニアマネージャーで業界スペシャリストです。15 年以上にわたり、セキュリティのベストプラクティスに関するアドバイスや、サイバー評価や財務評価を実施するお客様にサービスを提供してきました。現在は、re:inforce のオピニオンリーダー、講演者、トラックリーダーを務めており、AWS のクラウドセキュリティをサポートするインパクトのあるソリューションを推進するチームを率いています。 Neha Singh Rajpurohit Neha は AWS のシニアプロダクトマネージャー (テクニカル) です。製品管理と戦略に関する 10 年以上の経験を活かしています。Neha は、顧客のニーズを理解し、共感できるインサイトとデータを組み合わせて最も複雑なプロセスでも簡素化することに情熱を注いでいます。 参考文献: What’s New Post – Best Practices framework for GenAI AWS Audit Manager ドキュメント Transform responsible AI from theory into practice Amazon Bedrock ユーザーガイド Transform responsible AI from theory into practice AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI <!-- '"` -->

新しい U7i インスタンスは、SAP HANA、Oracle、SQL Server などの大規模なインメモリデータベースをサポートするように設計されています。カスタムの第 4 世代インテル Xeon スケーラブルプロセッサ (Sapphire Rapids) を搭載したインスタンスは、次に示すように、米国西部 (オレゴン)、アジアパシフィック (ソウル)、欧州 (フランクフルト) の複数の AWS リージョンにおいて、プレビューでご利用いただけるようになりました。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 u7in-16tb.224xlarge 896 16,384 GiB 100 Gbps 100 Gbps u7in-24tb.224xlarge 896 24,576 GiB 100 Gbps 100 Gbps u7in-32tb.224xlarge 896 32,768 GiB 100 Gbps 100 Gbps また、より小さなインスタンスにも取り組んでいます。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 u7i-12tb.224xlarge 896 12,288 GiB 60 Gbps 100 Gbps 32 TiB のメモリは次のようになります。 そして、896 vCPU (および他の多くの情報) は次のとおりです。 第 1 世代 のハイメモリインスタンスと比較すると、U7i インスタンスは、最大 125% 高いコンピューティングパフォーマンスと、最大 120% 高いメモリパフォーマンスを提供します。また、2.5 倍の EBS 帯域幅を提供するため、1 時間あたり最大 44 テラバイトのレートでインメモリデータベースをハイドレートできます。 各 U7i インスタンスは、最大 128 の汎用 (gp2 および gp3) またはプロビジョンド IOPS (io1 および io2 Block Express ) EBS ボリュームのアタッチをサポートします。各 io2 Block Express ボリュームは、最大 64 TiB まで拡張でき、最大 32 Gbps で最大 256K IOPS を提供できるため、U7i インスタンスに最適です。 ネットワーク側では、インスタンスは ENA Express をサポートし、ネットワークフローあたり最大 25 Gbps の帯域幅を提供します。 サポートされているオペレーティングシステムには、Red Hat Enterprise Linux および SUSE Enterprise Linux Server が含まれます。 プレビューをお試しください ご使用の環境で U7i インスタンスをテストする準備ができたら、 プレビューにぜひご参加ください 。 – Jeff ; 原文は こちら です。

最近では、特にテキストや画像形式のデータについて、機械学習 (ML) を使用して予測を行う際、ディープラーニングモデルの作成とチューニングに関する広範な機械学習の知識が必要でした。今日では、ML モデルを使用してビジネス価値を生み出したいと考えているすべてのユーザーが、ML にアクセスしやすくなっています。 Amazon SageMaker Canvas を使用すると、コードを 1 行も記述せずに、表形式データや時系列データだけでなく、さまざまなデータタイプの予測を作成できます。これらの機能には、画像、テキスト、およびドキュメントデータタイプの事前トレーニング済みモデルが含まれます。 この記事では、事前トレーニング済みのモデルを使用して、表形式データ以外にもサポートされているデータタイプの予測を取得する方法について説明します。 テキストデータ SageMaker Canvas は、ML モデルの構築、トレーニング、デプロイを行うためのノーコードのビジュアルインターフェースを提供します。自然言語処理 (NLP) タスクの場合、SageMaker Canvas は Amazon Comprehend とシームレスに統合されているため、言語検出、エンティティ認識、感情分析、トピックモデリングなどの主要な NLP 機能を実行できます。この統合により、Amazon Comprehend の堅牢な NLP モデルを使用するためのコーディングやデータエンジニアリングが不要になります。テキストデータを提供し、一般的に使用される4つの機能（感情分析、言語検出、エンティティ抽出、個人情報検出）から選択するだけです。シナリオごとに、UI を使用してテストし、バッチ予測を使用して Amazon Simple Storage Service (Amazon S3) に保存されているデータを選択できます。 感情分析 感情分析を使用すると、SageMaker Canvas では入力テキストの感情を分析できます。次のスクリーンショットに示すように、全体的な感情がポジティブ (Positive)、ネガティブ (Negative)、混合 (Mixed)、ニュートラル (Neutral) のいずれであるかを判断できます。これは、商品レビューの分析などの場合に便利です。たとえば、「この製品が大好きです、すごいです！」というテキストがあるとします。SageMaker Canvas ではポジティブな感情を持つものとして分類され、「この製品はひどい、買ったことを後悔している」はネガティブな感情として分類されます。 エンティティ抽出 SageMaker Canvas はテキストを分析し、その中に記載されているエンティティを自動的に検出できます。文書が分析のためにSageMaker Canvas に送信されると、テキスト内の人、組織、場所、日付、数量、およびその他のエンティティが識別されます。このエンティティ抽出機能により、文書で議論されている主要な人物、場所、詳細についての洞察をすばやく得ることができます。サポートされているエンティティのリストについては、「 エンティティ 」を参照してください。 言語検出 SageMaker Canvas では、Amazon Comprehend を使用してテキストの主要言語を判断することもできます。テキストを分析して主要言語を特定し、検出された主要言語の信頼度スコアを提供しますが、多言語文書の割合の内訳は示しません。複数言語の長い文書で最良の結果を得るには、テキストを小さな部分に分割し、結果を集計して言語の割合を推定します。20 文字以上のテキストで最適に動作します。 個人情報検出 SageMaker Canvas による個人情報検出を使用して機密データを保護することもできます。テキスト文書を分析して個人を特定できる情報 (PII) エンティティを自動的に検出できるため、名前、住所、生年月日、電話番号、電子メールアドレスなどの機密データを特定できます。最大 100 KBのドキュメントを分析し、検出された各エンティティの信頼度スコアを提供するため、最も機微な情報を確認して選択的に削除できます。検出されたエンティティのリストについては、「 PII エンティティの検出 」を参照してください。（訳者注: 対応言語は開発者ガイドを参照してください） 画像データ SageMaker Canvas は、 Amazon Rekognition と統合することで、コンピュータビジョン機能を簡単に使用できるノーコードの視覚的なインターフェイスを画像分析のために提供します。たとえば、画像のデータセットをアップロードしたり、Amazon Rekognition を使用してオブジェクトやシーンを検出したり、テキスト検出を実行してさまざまなユースケースに対応できます。視覚的なインターフェイスと Amazon Rekognition の統合により、開発者以外のユーザーでも高度なコンピュータービジョン技術を活用できます。 画像内のオブジェクト検出 SageMaker Canvas は Amazon Rekognition を使用して画像内のラベル (オブジェクト) を検出します。SageMaker Canvas UI から画像をアップロードするか、 Batch prediction タブを使用して S3 バケットに保存されている画像を選択できます。次の例に示すように、時計塔、バス、建物などの画像内のオブジェクトを抽出できます。インターフェイスを使用して予測結果を検索し、並べ替えることができます。 画像内のテキスト検出 画像からテキストを抽出することは非常に一般的なユースケースです。このタスクを SageMaker Canvas 上ノーコードで簡単に実行できるようになりました。次のスクリーンショットに示すように、テキストは行項目として抽出されます。画像内の短いフレーズはまとめて分類され、1 つのフレーズとして識別されます。（訳者注: 対応言語は開発者ガイドを参照してください） 一連の画像をアップロードしてバッチ予測を実行し、1 つのバッチジョブですべての画像を抽出し、結果を CSV ファイルとしてダウンロードできます。このソリューションは、画像内のテキストを抽出して検出する場合に便利です。 文書データ SageMaker Canvas には、日々の文書理解のニーズを解決する、すぐに使えるさまざまなソリューションが用意されています。これらのソリューションは Amazon Textract によって提供されています。ドキュメントで使用できるすべてのオプションを表示するには、次のスクリーンショットに示すように、ナビゲーションペインで Ready-to-use models を選択し、 Document でフィルタリングします。（訳者注: 対応言語は開発者ガイドを参照してください） 文書分析 文書分析では、検出されたテキスト間の関係について文書とフォームを分析します。このオペレーションでは、未加工テキスト (Raw text)、フォーム&nbsp;(Forms)、テーブル (Tables)、署名 (Signatures) の 4 つのカテゴリの文書抽出が返されます。このソリューションは文書構造を理解できるため、文書から抽出するデータの種類をさらに柔軟に設定できます。次のスクリーンショットは、テーブル検出がどのように見えるかの例です。 このソリューションは複雑な文書のレイアウトを理解できるため、文書内の特定の情報を抽出する必要がある場合に役立ちます。 身分証明書分析 このソリューションは、個人識別カード、運転免許証、またはその他の類似の身分証明書などの文書を分析するように設計されています。ミドルネーム、郡、出生地などの情報は、次のスクリーンショットに示すように、正確性に関する個人の信頼スコアとともに、IDドキュメントごとに返されます。 バッチ予測を行うオプションもあります。これにより、識別書類のセットを一括アップロードし、バッチジョブとして処理できます。これにより、身分証明書の詳細を、データ分析などの下流プロセスに使用できるキーと値のペアに迅速かつシームレスに変換できます。 経費分析 経費分析は、請求書や領収書などの経費文書を分析するように設計されています。次のスクリーンショットは、抽出された情報がどのように見えるかの例です。 結果は集計フィールドと行項目フィールドとして返されます。Summary fields はドキュメントから抽出されたキーと値のペアで、 Grand Total 、 Due Date 、 Tax などのキーが含まれます。Line item fields とは、ドキュメント内のテーブルとして構造化されたデータを指します。これは、レイアウトを維持したままドキュメントから情報を抽出する場合に便利です。 ドキュメントクエリ ドキュメントクエリは、ドキュメントについて質問できるように設計されています。これは、複数ページのドキュメントがあり、ドキュメントから非常に具体的な回答を抽出したい場合に使用するのに最適なソリューションです。以下は、質問できる質問の種類と、抽出された回答の例です。 このソリューションは、ドキュメントを操作するためのわかりやすいインターフェイスを提供します。これは、大きな文書の中で特定の詳細情報を取得したい場合に役立ちます。 まとめ SageMaker Canvas は、テキスト、画像、文書などのさまざまなデータタイプで ML を簡単に使用できるノーコードの環境を提供します。視覚的なインターフェイスと、Amazon Comprehend、Amazon Rekognition、Amazon Textract などの AWS サービスとの統合により、コーディングやデータエンジニアリングの必要がなくなります。テキストの場合、感情、エンティティ、言語、PIIに関して分析できます。画像の場合、オブジェクトとテキストの検出により、コンピュータービジョンのユースケースが可能になります。最後に、ドキュメント分析では、下流プロセスのためにドキュメントのレイアウトを維持しながらテキストを抽出できます。SageMaker Canvas のすぐに使用できるソリューションにより、高度な ML 技術を活用して、構造化データと非構造化データの両方から洞察を得ることができます。すぐに使える ML モデルでコード不要のツールを使用することに興味があるなら、今すぐ SageMaker Canvas を試してみてください。詳細については、「 Amazon SageMaker Canvas の使用を開始する 」を参照してください。 翻訳はソリューションアーキテクト菊地が担当しました。原文は こちら です。 著者について Julia Ang は、シンガポールを拠点とするソリューションアーキテクトです。彼女は、医療や公共部門からデジタルネイティブビジネスまで、さまざまな分野の顧客と協力して、ビジネスニーズに応じたソリューションを採用してきました。また、東南アジアをはじめとする地域のお客様のビジネスにおける AI と ML の活用を支援してきました。仕事以外では、旅行やクリエイティブな活動を通じて世界について学ぶことを楽しんでいます。 Loke Jun Kai は、シンガポールを拠点とする AI/ML のスペシャリストソリューションアーキテクトです。彼は ASEAN 全域の顧客と協力して、AWS で大規模な機械学習ソリューションを構築しています。Jun Kai は、ローコード・ノーコード・機械学習ツールの提唱者です。余暇には、自然とのふれあいを楽しんでいます。

モノのインターネット (IoT) は、様々な業界でますます普及しています。また、接続されるデバイスの増加や送信される機密情報の量に伴い、IoT セキュリティは最重要課題となっています。世界人口の増加が続く中、エネルギー需要はかつてない水準に急増しています。この差し迫った課題に対応するため、再生可能エネルギー源は、IoT 技術の力を活用し、この変革的な移行を推進することで、非常に大きな意味を持つようになりました。風力、水力発電設備、太陽光発電 (PV) システムは、クリーンで持続可能なエネルギーの効率的な生成と利用を可能にする重要な触媒として登場しました。AWS IoT は、デバイスとシステムを接続する安全で暗号化された手段を提供し、送信データの完全性と安全性を保証します。AWS IoT は、再生可能エネルギーシステムの効果的な運用と管理をサポートし、効率的なエネルギー生成と分配を促進する上で重要な役割を果たします。 ソリューション概要 提案するアーキテクチャでは、再生可能エネルギーシステムは、Modbus インターフェースを利用する AWS IoT 認定デバイス と統合されます。このデバイスは AWS IoT Greengrass を実行し、シームレスな接続を実現します。デバイスは、 MQTT と HTTPS プロトコルを介して AWS IoT Core と通信します。データは、効率的な配信のために Amazon Kinesis Data Firehose を通じてストリーミングされ、 Amazon Simple Storage Service に保存されます。データを可視化し、洞察を得るために、 Amazon QuickSight が活用され、インタラクティブで視覚的に魅力的なダッシュボードが作成されます。そして、 AWS IoT Device Management 、 Amazon CloudWatch 、 Amazon Simple Notification Service を使用して、リアルタイムのモニタリングとアラートを実装することができます。さらに、データを AI/ML アプリケーションに活用することで、高度な分析と予測機能を実現することができます。 図1：再生可能エネルギー-電力 AWS IoT 認定ソリューション AWS IoT によるクラウドのセキュリティ 再生可能エネルギー部門は、IoT セキュリティに関していくつかの課題に直面しています。主な課題とそれに対応するAWS IoT ソリューションは以下の通りです： デバイスのセキュリティ: 再生可能エネルギーシステムで使用される IoT デバイスには、悪意のある行為者に悪用される可能性のある脆弱性があります。これらの脆弱性は、安全でないファームウェア、セキュリティパッチの欠如、または脆弱な認証メカニズムに起因する可能性があります。これらのデバイスのセキュリティを向上させることは、不正アクセスや改ざんを防ぐために非常に重要です。AWS IoT は、セキュアな デバイスのオンボーディング 、 証明書管理 、 ポリシーベースのアクセス制御 を可能にするデバイス・セキュリティ・サービスを提供します。デバイスの脆弱性に対処するために、堅牢な 認証メカニズム 、セキュアな Over-the-Air(OTA) アップデート、 AWS IoT Device Defender などの脆弱性管理サービスを提供します。 相互運用性: 再生可能エネルギーシステムは、多くの場合、異なるメーカーのレガシーデバイスと最新デバイスが混在しています。セキュリティを維持しながら、これらの機器間のシームレスな統合と相互運用性を実現することは、難しいことです。レガシーデバイスには強固なセキュリティ機能がない場合があり、システムの潜在的な弱点となります。AWS IoT は、標準化されたプロトコルと API を通じて、異なるメーカーのデバイス間のシームレスな統合と相互運用性を促進します。AWS IoT Core と AWS IoT Greengrass は、安全な通信のための MQTT 、 HTTPs 、 Modbus プロトコルを提供し、セキュリティを維持しながらレガシーデバイスと最新デバイスの互換性を確保します。 データ・セキュリティ: IoT システムは、エネルギー生産、消費、ユーザー行動に関する機密情報を含む膨大な量のデータを生成します。このデータのプライバシーと機密性を保護することは非常に重要です。組織は、不正アクセスやデータ漏洩から保護するために、セキュアなデータ送信、保存、アクセス制御メカニズムを実装する必要があります。AWS IoT は、暗号化、セキュアなデータ伝送プロトコル（TLS など）、アクセス制御メカニズムを通じて、 エンドツーエンド のデータセキュリティを提供します。 リモートアクセスのセキュリティ: 再生可能エネルギーシステムの多くは遠隔地から監視・管理されるため、さらなるセキュリティリスクが生じます。制御システムや監視プラットフォームへのリモートアクセスは、不正アクセスや改ざんを防ぐために適切に保護されなければなりません。セキュアなリモートアクセスプロトコルと多要素認証を実装することで、これらのリスクを軽減することができます。AWS IoT は、 AWS Identity and Access Management (IAM) 、 AWS IoT Core 、 AWS IoT セキュアトンネリング を使用することで、IoT システムへのセキュアなリモートアクセスを提供します。 標準化されたセキュリティのベストプラクティス: IoT 技術は急速に進化しているため、標準化されたセキュリティプラクティスや規制がありません。これは、再生可能エネルギーシステム全体で一貫性のある強固なセキュリティ対策を実施するための課題となっています。業界全体のセキュリティ標準を策定し、関連規制に準拠することは、IoT セキュリティを向上させるために不可欠です。AWS IoT は、業界の セキュリティにおけるベストプラクティス と コンプライアンス に従っています。AWS IoT はガイドライン、フレームワーク、ドキュメントを提供し、組織が IoT の導入全体で堅牢なセキュリティ対策を実施できるよう支援します。 デバイス管理: 再生可能エネルギーシステムの IoT デバイスは、そのライフサイクルを通じて頻繁なメンテナンス更新が必要です。デバイスをセキュリティパッチやアップデートで常に最新の状態に保つことは、大規模な導入では難しい場合があります。組織は、脆弱性を減らすために、デバイスの更新とセキュリティパッチを管理する効率的なプロセスを確立する必要があります。AWS IoT は、大規模なデバイスの更新と管理のプロセスを簡素化するデバイス管理サービスを提供します。AWS IoT Device Management は AWS IoT Jobs を提供し、企業が IoT デバイスにセキュリティパッチやファームウェアアップデートを効率的に導入できるようにします。 AWS IoT が提供する包括的なセキュリティ機能とサービスを活用することで、企業はセキュリティ体制を強化し、ファームウェアや OS の脆弱性、相互運用性、データプライバシー、リモートアクセス、デバイス管理に関連するリスクを軽減することができます。 AWS IoT Greengrassによるエッジでのセキュリティ AWS IoT Greengrass は、Amazon Web Services(AWS) が提供するオープンソースのエッジランタイムソフトウェアサービスで、産業用デバイスなどのエッジデバイスにクラウド機能を拡張し、産業用デバイスのセキュリティを支援します。 AWS IoT Greengrass は、デバイスがエッジでローカルにデータを処理・分析することを可能にし、システムのレイテンシを削減し、オフラインモードでオペレーションを継続する機能を提供することで、低レイテンシとオフライン機能が要求される産業環境でのエッジコンピューティングとデータ処理を可能にします。これにより、機密データをローカライズし、伝送中のデータ漏洩の可能性を低減することで、機密データの安全性を保つことができます。 さらに、 AWS IoT ポリシー 、 クライアントデバイス認証コンポーネント 、AWS IAM ポリシーを使用して、ローカルとクラウドで AWS IoT Greengrass への認証と認可を制御できます。その結果、許可されたユーザーとデバイスのみが産業用デバイスにアクセスし、必要に応じてアクションを実行できます。 AWS Systems Manager &nbsp;は、エッジデバイスのリモートソフトウェアアップデートや構成管理を含むデバイス管理機能を提供します。また、 Systems Manger エージェント を通じて AWS IoT Greengrass と統合することで、産業用デバイスのセキュリティ体制を維持し、最新の OS パッチやアップデートを適用することができます。 AWS IoT Greengrass は、Edge Framework ESF (Everyware Software Framework) のサポートも認定されています。このフレームワークは、 IEC 62443-4-2 &nbsp;と&nbsp; IEC 62443-4-1 &nbsp;の両方のサイバーセキュリティ認証を世界で初めて取得したフレームワークです。この実績は、AWS IoT Greengrass が採用している強固なセキュリティ対策と業界をリードするサイバーセキュリティ標準への準拠を強調しています。その結果、ユーザーはエッジコンピューティングシステムの完全性と回復力に自信を持つことができ、サイバーセキュリティ保護を強化した IoT ソリューションの導入が可能になります。 これらの製品関連認証は、より高いレベルのソリューション認証に継承することができ、エンドツーエンドソリューションのセキュリティ標準やベストプラクティスへの準拠を求めるシステムインテグレーターやソリューションオーナーにとって有益です。つまり、AWS IoT Greengrass と Edge Framework ESF を大規模なソリューションの一部として使用する場合、この製品によって取得された認定は、ソリューション全体のコンプライアンスとセキュリティ態勢に貢献することができ、導入においてサイバーセキュリティを優先する人々に付加価値を提供することができます。 まとめ AWS IoT は、IoT セキュリティの課題を支援するために設計された包括的なサービススイートを提供します。統合作業を合理化し、コストを削減し、リスクを軽減することで、AWS IoT は組織に安全で効率的なソリューションを実装する力を与えます。AWS IoT が提供する edge-to-cloud のセキュリティアプローチは、厳格なサイバーセキュリティ標準に準拠した設計を保証し、堅牢で信頼性の高いセキュリティ対策を求める組織にとって信頼できる選択肢となります。AWS IoT の堅牢なセキュリティ機能を活用することで、再生可能エネルギー業界の組織は貴重なデータとデバイスを保護し、ソリューションの潜在能力を最大限に引き出すことに集中することができます。 著者について Muhammad Qazafi は、アメリカ合衆国を拠点とするソリューションアーキテクトです。ソリューションアーキテクトとして、AWS 上でのセキュアでスケーラブルかつ革新的なソリューションの設計、開発、実装において顧客を支援します。彼の主な目的は、AWS サービスの効果的な活用を通じて、顧客が測定可能なビジネス成果を達成するのを支援することです。Muhammad は15年以上の経験を持ち、多様な業界にわたる豊富な知識と専門知識を持っています。この豊富な経験により、彼はさまざまなビジネスが直面する独自の課題を理解し、顧客が AWS 上でソリューションを作成するのを支援することができます。 この記事は Muhammad Qazafi によって書かれた Protecting renewable energy systems using AWS IoT の日本語訳です。この記事は ソリューションアーキテクトの安田が翻訳しました。

このブログは Kunal Vasavada（Akridata）と Eric Yuen（Senior Partner Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 深層学習プロセスではデータ処理を行う前に、数百 GB に及ぶデータセット全体を読み込むことがよくあります。このようなパフォーマンスが重要なワークロードを実行している企業にとっては、ストレージからの高速なデータ取得と低レイテンシーが非常に重要です。 AWS 独立系ソフトウェアベンダー（ISV）パートナーである Akridata は、ラベルのない動画や画像のデータセットに対して人工知能（AI）を利用した大規模なデータ整理、調査、分析機能を提供することにより、非構造化データの探索を支援しています。 このブログでは、 Akridata Data Explorer がどのように機能するかを、自動運転の開発者がビジュアルデータセットの可能性を引き出した例を交えながら説明します。次に、Akridata Data Explorer を使用する際に、Amazon S3 標準と比較してデータアクセス速度が 10 倍向上しリクエストコストを 50 % 削減できる Amazon S3 Express One Zone ストレージクラスにデータを保存することで、3.5 倍処理を高速化できることについて説明します。 Akridata Data Explorer : ラベル付けされていないビジュアルデータの自動処理 Akridata Data Explorer は software as a service（SaaS）ソリューションで、確かな運用実績、膨大なサービスが利用可能、世界中の潜在的なお客さまにリーチ可能という理由から、すべて AWS 上で構築されています。Akridata Data Explorer は、Amazon Elastic Kubernetes Service（Amazon EKS）上で動作する柔軟なソリューションです。これにより、 Amazon S3 の様々なストレージクラスに格納された大量の動画や画像のデータを手動でラベル付けすることなく、エンドユーザーが分析可能なノーコード環境を提供します。 以下の画像は、Akridata Data Explorer のワークフローを示します。 ビジュアルデータセットを Amazon S3 にアップロードします。（今回の場合、Amazon S3 Express One Zone ストレージクラスを使用） Akridata Data Explorer SaaS サービスにサインインします。 Amazon Elastic Container Registry（Amazon ECR）から目的のモデルを選択し、データ処理パイプラインを作成します。 Akridata Data Explorer は Amazon S3 Express One Zone からデータを読み取り、深層学習処理を開始します。 作成されたデータカタログは、Amazon Aurora に保存されます。 最終的に、ビジュアルデータセットに対して検索やデータ分析等の視覚化操作を実行できます。 Akridata Data Explorer を自動運転のデータで使用する Akridata Data Explorer を説明するため、自動運転データの収集を例に挙げます。自動運転のデータ収集では、日々さまざまな国を走行する各テスト車両は何時間分もの動画や画像を撮影し、大量の非構造化データが収集されます。これらのデータセットはすべて、サニタイズ、クリーニング、タグ付けする必要があります。 Akridata Data Explorer は、すぐに利用できるさまざまなパイプラインを通じて、データセットに対して任意の基盤モデルや一般的な機械学習モデルを使用したタグ付けやラベル付けを自動的に実施できます。以下の画像は、Akridata Data Explorer おいて Recognize Anything Model（RAM）を使用した自動タグ付けの結果です。建物や駐車場といったインフラ関連のタグ、自動車、ジープ、SUV、バンといった自動車関連タグや道路タグがすべて自動的に付与されています。 次の画像は、Akridata Data Explorer がデータセット全体をクラスターに変換し、類似度に基づいてデータをグループ化しているものです。この視覚的なアプローチにより、大規模なデータセットの全体像を迅速かつ直感的に把握でき、外れ値を見つけることができます。 次の画像は、ユーザーが視覚的に類似した画像を検索できることを示しています。画像の場合、Akridata Data Explorer は 1 回のクエリで最大 2,500 万枚の画像を検索できます。一方でこのプロセスでは重い読み取り操作が求められ、最短時間でワークフローを完了するにはストレージサブシステムの高いパフォーマンスが必要です。Amazon S3 のスケーラビリティとパフォーマンスは、ユーザーエクスペリエンスにおいて重要な役割を果たします。 画像の左には、緑の境界枠で囲まれた 3 つの画像例があります。これらの例は、横断歩道と傘を持った人が写っています。対照的に赤い境界枠で囲まれた画像では、これらの特徴はありません。 似たような画像の例を見つけるには、横断歩道や傘を持った人が写っている画像の「いいね」アイコンを選択し、 Quick Search を選択します。画像の右に示す結果には、さまざまなシナリオにおいて類似した画像が示されます。この機能により、興味深いパターンやシナリオの発見が容易になります。 Akridata Data Explorer は自然言語クエリを使用して、ラベルのない動画や画像データセットを検索することもできます。次の画像は、Akridata Data Explorer において「傘を持っている人と横断歩道」と検索した結果を示しています。テキストベースの検索により、データからの洞察がより簡単に得られます。 Amazon S3 Express One Zone による非構造化データ探索の加速 Akridata Data Explorer を使用する場合、ストレージサブシステムは、深層学習、検出、タグ付け、検索にかかる時間に直接影響します。Amazon S3 Express One Zone は、スケーラブルであるだけでなく、データ分析のユースケースで一桁ミリ秒という優れたレイテンシーを実現する最速のクラウドオブジェクトストレージであり、お客様はこれまでで最高のパフォーマンスを体験することができます。 Amazon S3 Express One Zone にデータを保存すると、Akridata Data Explorer パイプラインの実行時間と処理時間は、Amazon S3 標準を使用する場合と比較して平均 3.5 倍も改善されます。結果として、データの取り込みや視覚的データ探索の準備、検索が格段に早くなります。お客さまがオリジナルの高画質な動画や画像を閲覧しようとした場合、Amazon S3 Express One Zone の低レイテンシーと高スループットはデータの準備時間を大幅に短縮し、ユーザーエクスペリエンスを大幅に向上させます。そしてお客さまは運用コストを削減しながら、より多くのデータを短時間で分析できるようになり、生産性が向上します。 まとめ このブログでは、Akridata Data Explorer にて自動運転のデータセットにタグ付けを自動的に行い、画像から特定のコンテンツを検索、データ分類における課題を解決している様子を紹介しました。加えて、Amazon S3 Express One Zone にデータを保存することで、Akridata Data Explorer のお客さまは、データの準備にかかる時間を平均で 3.5 倍高速化することができます。 詳細については、 Akridata や Amazon S3 Express One Zone にアクセスするか、担当の AWS 営業にご連絡ください。Akridata Data Explorer は AWS Marketplace より入手可能です。 Kunal Vasavada Kunal は、Akridata のソリューション開発とプラットフォームエンジニアリングの責任者です。彼の経験は、ハイブリッドデータインフラストラクチャ、ストレージ、システムエンジニアリング、フルスタックML、大規模かつ高速なデータプラットフォームにまで及びます。彼は現在、Akridata でプラットフォームエンジニアリングとカスタマーソリューションを率いており、大規模で分散型なデータ中心の AI アプリケーション向けに、インテリジェントでオープンアーキテクチャの Edge-to-Cloud DataOps プラットフォームを提供しています。 Eric Yuen Eric Yuen は AWS の Senior Partner Solutions Architect です。彼は AWS のストレージパートナーと密に連携してソリューションを構築し、お客さまが AWS 上でストレージ環境を設計するのを支援しています。Eric は、さまざまなストレージおよびデータ保護テクノロジーに取り組んだ 20 年の業界経験を持っています。

はじめに IoT (モノのインターネット)では、接続されたデバイスのパフォーマンスを監視して、異常動作を検出し、デバイスが侵害された時には迅速に対応することが重要です。 AWS IoT Device Defender は、接続されたデバイスとクラウドインフラストラクチャからメトリクスを収集し、デバイスの異常動作の検出機能を提供します。以前は、分析するためにデバイスメトリクスをデータレイクへ追加する場合は、ファームウェアの変更して追加の MQTT トピックへメトリクスをパブリッシュする必要がありました。これは、開発時間とコストに影響を与える可能性があり、特に大量のデバイスを管理する場合は問題になります。AWS IoT Device Defender の新しいメトリクスエクスポート機能は、デバイスメトリクスを AWS IoT Device Defender からデータレイクへ出力するための利便性とコスト効率に優れた方法を提供します。メトリクスエクスポート機能を使えば、ファームウェの変更は不要かつ、簡単な設定のみでメトリクスをエクスポートできます。この新機能は、既存のワークロードも含めて提供されます。 インド最大級の決済業者の 1 社である Paytm は、何百万もの消費者や小売り業者向けの金融取引決済を運用管理しています。最も人気のある IoT ソリューションの 1 つが soundbox デバイスで、Paytm の QR コード決済を行った際に音声で決済内容を伝える、小売業者向けサービスです。Paytm の QR コードサービスにより、企業は Paytm アプリを通じて店頭でのコンタクトレス決済を可能にしました。soundbox には、4G 通信の SIM カードと 50-60 時間のバッテリーが内臓されているため、露店といった小規模店のユーザーはインターネット回線の用意を心配する必要がありません。Paytm のデバイスからメトリクスを AWS IoT Device Defender へ送信することで、Paytm は soundbox の稼働状態を監視することができます。 AWS IoT Device Defender からのメトリクスエクスポート AWS IoT Device Defender は、コネクテッドデバイスに利用される主要なサービスです。AWS IoT Device Defender は、クラウド側やデバイス側から収集したメトリクスと、設定された期待値とを比較することにより、デバイスの異常動作をほぼリアルタイムで検出します。メトリクスは 2 つのソースから収集されます。一つは クラウド側メトリクス として、認証失敗の回数や、AWS IoT Core を介してデバイスが送受信するメッセージ数やサイズなどがあります。もう一つは デバイス側メトリクス として、デバイスが待受しているポート、送信したバイト数またはパケット数、TCP のコネクション数などがあります。フリート固有の カスタムメトリクス を利用することも出来ます。たとえば Wi-Fi ゲートウェイに接続しているデバイスの数や、バッテリーの充電レベル、スマートプラグの電源サイクルの数などを定義することが出来ます。メトリクスエクスポート機能を使用して、クラウド側やデバイス側のメトリクスや、カスタムメトリクスをエクスポートできます。 セキュリティプロファイル の設定で、エクスポートするメトリクスと送信先の MQTT トピックを指定できます。AWS IoT Device Defender はデータをバッチで処理し、セキュリティプロファイルで設定された MQTT トピックへパブリッシュすることで、エクスポートのコストを最適化します。メトリクスをエクスポートする方法としては 2 つのオプションがあります。 IoT Core ルールエンジンを使ったエクスポート AWS IoT Core のルールエンジン の機能を利用して、エクスポートされたメトリクスを任意の宛先にルーティングできます。このオプションを使用すると、AWS IoT Core の Basic Ingest を活用して、データのエクスポートコストを削減できます。次の図は、このオプションのリファレンスアーキテクチャを示しています。このオプションでは、AWS IoT Device Defender からメトリクスを Basic Ingest のトピックに送信し、AWS IoT Core の ルールエンジン でデータを任意の宛先にルーティングする様にルールを作成します。（例えば、 Amazon Kinesis Data Firehose を介して Amazon Simple Storage Service (Amazon S3) バケットにルーティングします） 図1: AWS IoT Core Rules Engine を使用した AWS IoT Device Defender メトリックエクスポートのアーキテクチャ MQTT サブスクリプションを使ったエクスポート このオプションでは AWS IoT Core を使って、AWS IoT Device Defender からデータを MQTT トピックへを送信し、MQTT トピックをサブスクライブすることでデータを利用します。次の図は、AWS IoT Device Defender からメトリクスを MQTT トピックに送信するリファレンスアーキテクチャを表しています。同じ MQTT トピックをサブスクライブする MQTT クライアント（例えば、 Amazon Elastic Container Service のコンテナ内）を実行します。AWS IoT Device Defender がデータをパブリッシュする毎に、MQTT クライアントはデータを受信して処理します。 図 2: AWS IoT Core MQTT Broker を使用した AWS IoT Device Defender メトリックエクスポートのアーキテクチャ ここからは、図 1 で確認した AWS IoT Device Defender からメトリクスをエクスポートするソリューションを構築していきます。 前提条件 AWS IoT Core、AWS IoT Device Defender、Amazon Kinesis Data Firehose、および Amazon S3 上での実行権限がある AWS アカウント AWS Identity and Access management (IAM) で AWS IoT Core に割り当てるロールの作成権限 AWS CloudShell へのアクセスと、Linux と AWS Command Line Interface (AWS CLI) の基本的な知識 手順 以下のステップでは、メトリクスエクスポート機能を使って、いくつかのクラウド側メトリクスと AWS IoT Device Defender のカスタムメトリクスを Amazon S3 にエクスポートするパイプラインを構築します。Basic Ingest のメカニズムを使用して、AWS IoT Device Defender のメトリクスを Kinesis Data Firehose 経由で Amazon S3 にエクスポートします。 初期設定 このステップでは IoT Core でモノを作成し、シミュレーターを使って、このモノのカスタムメトリクスを 5 分毎にパブリッシュします。初期設定と MQTT クライアントの実行には AWS CloudShell を使用します。 AWS コンソールにログインし、 CloudShell を開く 設定で利用するスクリプトとコードをダウンロードするために git リポジトリをクローンする $ git clone https://github.com/aws-samples/aws-iot-device-defender-metric-export.git ‘createThing.sh’ を実行して、AWS IoT Core に名前が ‘dd-export-test’ のモノを作成し、Amazon S3 に保存先バケットを作成します。 $ cd aws-iot-device-defender-metric-export $ bash ./createResources.sh dd-export-test AWS IoT Device Defender カスタムメトリクスの作成 次に、デバイスが観測したモバイルネットワークの電波強度 (RSSI) を収集および評価するためのカスタムメトリクスを作成します。 AWS IoT Core に移動し、左側のメニューから セキュリティ → 検出 → メトリクス を選択し、 作成 をクリックします。 カスタムメトリクスの作成 画面で、以下の値を入力し、 カスタムメトリクスの作成 (Create custom metric) をクリックします。 名前 (Name) – mobilerssi 表示名 (Display name) – Cellular Network Strength タイプ (Type) – number AWS IoT Device Defender セキュリティプロファイルの作成 次に、異常動作を定義する セキュリティプロファイル を作成します。AWS IoT Device Defender メトリクス、 カスタムメトリクス 、 ディメンション を組み合わせることで、ユースケースに応じた適切な検出モデルを作成出来ます。以下の例では、クラウド側メトリクス(受信したメッセージとサイズ)とモバイルネットワークの電波強度カスタムメトリクスを利用します。メトリクスを効果的に組み合わせる方法の詳細については、ドキュメントの セキュリティのユースケース をご確認ください。 AWS IoT Core で、左側のメニューをクリックし、 セキュリティ → 検出 → セキュリティプロファイル に移動します。 セキュリティプロファイルを作成 をクリックし、 ルールに基づいた異常検出プロファイルを作成 を選択します。 セキュリティプロファイルのプロパティを指定する のステップで、以下の値を入力し、 次へ をクリックします。 セキュリティプロファイル名 (Profile name) – Monitor_RSSI ターゲット (Target) – ターゲットグループ、1 つまたは複数のグループを選択できます。この例では、 dd-metric-export-group をターゲットにします。 メトリクス動作の設定 のステップで、次の操作を行います。 クラウド側のメトリクス下にある メッセージサイズ を探して選択し、 アラートを送信しない(リテンションメトリクス) オプションを選択します。 メトリクスの追加 をクリックし、先ほどと同じ様に 受信したメッセージ と Cellular Network Strength メトリクスを繰り返し選択します。 次へ をクリックします。 メトリクスをエクスポートする のステップで、 メトリクスのエクスポート設定 を以下のように設定し、 次へ をクリックします。 メトリクスをエクスポートする (Export Metrics): メトリクスのエクスポートを有効にする を選択します。 トピック (Topic): $aws/rules/dd_export_firehose/ddmetric/cellular IAM ロール (IAM Role): 新しいロールの作成 をクリックし、表示された手順に従います。 メトリクスの選択: 提供されたリストから メッセージサイズ 、 受信したメッセージ 、 Cellular Network Strength を選択します。 通知の設定 のステップでは SNS の構成は空白のまま 次へ をクリックします。 確認と作成 のステップで構成を確認して 作成 をクリックします。 メトリクス動作の設定した内容は以下の様な画面になります。 AWS IoT Core ルールの作成 このセクションでは、AWS IoT Core ルールエンジンでルールを定義して、Basic Ingest のトピック $aws/rules/dd_export_firehose/ddmetric/cellular で受信したデータを、Kinesis Data Firehose のデータストリームに転送します。 AWS IoT Core に移動し、左側のメニューで メッセージのルーティング → ルール を選択して、 ルールの作成 をクリックします。 ルールのプロパティ で、ルール名を dd_export_firehose と入力し、 次へ をクリックします。 SQL ステートメントを設定 のステップで、次の SQL ステートメントを指定し、 次へ をクリックします。 SELECT * FROM 'ddmetric/#' ルールアクションをアタッチ のステップの、 ルールアクション パネルで、 アクション 1 に Kinesis Firehose stream を選択します。 Firehose ストリームを作成 をクリックします。すると、新しいウィンドウで 配信ストリームを作成 ページが開きます。 ソースと送信先を選択 パネルで ソース として Direct Put を選択します。 送信先 として、 Amazon S3 を選択します。 配信ストリーム名 パネルで 配信ストリーム名 フィールドに dd-metric-export-stream と入力します。 送信先の設定 パネルで S3 バケットとして、 &lt;Account_id&gt;.dd.metric.export S3 バケットを参照ボタンから探し選択します。 その他はすべてデフォルトのままにします。 配信ストリームを作成 をクリックし、配信ストリームの作成完了を待ちます。ステータスフィールドが 作成中 から アクティブ に変わったことを確認します。 前のウィンドウ ( ルールアクションをアタッチ ) に戻ります。 Kinesis Firehose ストリーム のドロップダウンから、 dd-metric-export-stream を選択します。ドロップダウンに新しく作成したストリームが表示されない場合は、ドロップダウンの横にある更新ボタンをクリックしてエントリを更新してください。 区切り文字 と バッチモード はそのままにします。 IAM ロール : 新しいロールを作成 をクリックし、表示された手順に従います。 次へ をクリックします。 構成を確認し、 作成 をクリックします。 カスタムメトリクスをパブリッシュし、データ出力を確認する 次に、作成したパイプラインをテストするためにデバイスシミュレータを実行します。 AWS CloudShell プロンプトに移動し、次のスクリプトを実行します。スクリプト内で MQTT クライアントが実行され、5 分ごとに AWS IoT Device Defender の カスタムメトリクスレポート として、モバイルネットワーク RSSI がパブリッシュされます。 $ bash ./publishMetric.sh スクリプトを 15 分以上実行させてください。(Kinesis Firehose はデータを 15 分間バッファリングします) Amazon S3 の &lt;Account_id&gt;.dd.metric.export バケットに移動し、エクスポートされたデータを確認してください。 クリーンアップ 実験後のコスト発生を避けるために、下記手順を実行: スクリプトを実行しているターミナルで Ctrl + C を押して、MQTT クライアントを停止します。 次のスクリプトを実行して、作成した AWS IoT Core のモノを削除します。 $ bash ./cleanupResources.sh 作成した AWS IoT Device Defender セキュリティプロファイルを削除します。 作成した AWS IoT Device Defender カスタマーメトリクスを削除します。 作成した AWS IoT Core ルールを削除します。 作成した Kinesis Data Firehose 配信ストリームを削除します。 作成した Amazon S3 バケットを削除します。 まとめ この投稿では、新しい AWS IoT Device Defender メトリクスエクスポート機能の使用方法を学びました。AWS IoT Device Defender からサービスまたは希望のストレージへメトリクスをエクスポートする方法を学び、エクスポートのコスト最適化に関する方法を学びました。メトリクスを複数の宛先にエクスポートする場合は、AWS IoT Core ルールエンジンのファンアウト機能も検討出来ます。 詳細については、 AWS IoT Core サイトをご覧いただくか、 コンソールにログイン して利用を開始してみてください。ご意見やご質問をお待ちしています。 著者について Reetesh Varshney Reetesh は Amazon Web Services の IoT スペシャリストです。彼は業種を問わずお客様と協力し、IoT が可能にするビジネスチャンスと技術について支援しています。また、スマートコネクテッドプロダクト、コネクテッドビークル、スマートファクトリーの IoT プラットフォーム開発でもお客様を支援してきました。 Andre Sacaguti Andre Sacaguti は、AWS IoT のシニアプロダクトマネージャーです。デバイスメーカー、自動車メーカー、そしてさまざまな業界のお客様が、IoT デバイスを監視および保護できるような製品やサービスの構築をエッジからクラウドに渡って注力しています。AWS 入社以前は、T-Mobile や Qualcomm で IoT 製品の構築やローンチを行っていました。 この記事は “How to use the new metric export capability of AWS IoT Device Defender” の日本語訳です。この記事はソリューションアーキテクトの 山岡 卓紀夫 が翻訳しました。

本日（US時間 11 月 30 日）、私たちは AWS Supply Chain について、サプライチェーンの上流のプロセスをサポートするために4つの新機能を発表しました。 コンポーネントと製品在庫を計画、配置、補充するのに役立ち、在庫コストを削減し、需要の変動とサプライチェーンの混乱により迅速に対応できる AWS Supply Chain Supply Planning 。 貴社とサプライヤー間のコミュニケーションを効率化し、供給計画への対応と実行段階における需要またはサプライの変更の管理を改善する AWS Supply Chain N-tier Visibility （複数段のサプライチェーンに対する可視化） 。この機能により、わずか数クリックで複数階層の取引先と安全に連携できます。 サステナビリティデータの要求、収集、監査を可能にする格納場所を提供する AWS Supply Chain Sustainability 。 生成系 AI を利用して、分析と意思決定を支援する会話型エクスペリエンスをサプライチェーンのプロフェッショナルに提供する AWS Supply Chain の Amazon Q 。 これらの新しい機能は、2024年に利用可能になり、既存のデータレイク、需要予測、機械学習 (ML) によるインサイトを拡張します。 今日、お客様は在庫の可視性を高め、品切れを防ぎ、過剰在庫による在庫保有コストの増加を減らすために AWS Supply Chain を利用しています。 AWS Supply Chain は、個別のERPに格納された、互いに関係した顧客データを 統一された正規データモデルに基づいて集約し、サプライチェーンデータレイク (SCDL) を作成することが出来るためです。 この統一された SCDL により、在庫の可視性を高める Insights という AWS Supply Chain 機能が可能になり、機械学習を活用し、在庫とリードタイムのリスクを軽減するための在庫配置や補充に対する推奨が提供されます。Demand Planning 機能は Amazon の深いサプライチェーンの専門知識と機械学習を組み合わせ、正確性を向上させるためにモデルを継続的に調整しながら、販売履歴データとリアルタイムデータを分析して予測を作成しています。 サプライチェーン上流の課題 サプライチェーンの上流部分には、サプライヤーや取引先パートナーからの原材料とコンポーネントの調達と移動が含まれます。 サプライチェーンのリーダーは、サプライヤー、メーカー、ディストリビューター、小売業者など、多くの異なるレイヤーの取引先との調整が絶えず課題であると伝えてきました。 各取引先には、独自のデータ管理システムがあり、高価なカスタマイズや長い開発サイクル、または手作業による回避策を必要とすることが多いです。 その結果、供給計画担当者は、予測、注文確認、出荷数量など整合するのに多くの時間を費やしています。 データがサイロ化していることが、需要の変動、サプライの中断、ベンダーのリードタイムの不確実性と相まって、企業が正確に在庫を把握し、顧客需要を満たすのを困難にしています。 製造業のお客様は、原材料とコンポーネントの価格・入手が変動することにより一層の複雑さに直面しています。さらに、取引先の顧客からのデータ要求への対応は、品質、頻度、適時性、構造の点で顧客毎に異なっており、必ずしも体系的に追跡または監査されているわけではありません。 大量の規制対応情報(炭素排出量や有害物質開示など)を管理することは、同様に困難であり、これまでは正式な追跡や監査メカニズムではなく、電子メール、ファックス、メッセージアプリを介して行われてきました。その結果、多くの組織では、需要を効率的に満たしたり、厳しくなる規制要件を満たしたりするために、適切な数量の商品を適切な時間に適切な場所に確実に配置することに苦慮しています。 本日発表された新しい AWS Supply Chain 機能を使用することで、上流のサプライチェーン・プロセスを改善し、材料の在庫率や入荷率を向上させ、サプライヤーとコミュニケーションを取りながら供給計画を確認し合意を得ることができます。また、重要な環境要因に関する正確なデータを取得することもできます。これらの機能についてもっと詳しく見ていきましょう AWS Supply Chain Supply Planning Supply Planning の機能は、Amazon が自社の運用のために高度なサプライプランニングモデルを開発してきた専門知識に基づいています。Supply Planning は、施設全体で必要な在庫水準を正確に判断できる高度なサプライプランニングモデルを作成します。サプライプランは、AWS Supply Chain デマンドプランニングによって作成された需要予測と、SCDL からの製品、施設、部品表 (BOM)、在庫、その他の顧客情報を組み合わせて生成されます。このデータの自動統合により、情報の品質が向上し、予測、注文確認、仕入先リードタイムなどを含むさまざまなレポートを手動で統合する作業によるリスクが軽減されます。 Supply Planning は需要の変動、仕入先のリードタイム、発注頻度を考慮して在庫目標を動的に計算し、在庫発注や在庫移動を推奨します。これにより、発注または移動する単位数、発注または移動のタイミング、在庫の配置場所を最適に決定することができます。 次のスクリーンショットは、在庫状況、発注状況、運用指標などをまとめた Supply Planning ダッシュボードを示しています。各カテゴリの詳細を確認し、適切な対応を取ることができます。 AWS Supply Chain N-Tier Visibility N-Tier Visibility（複数段のサプライチェーンに対する可視化） は、組織外の複数の外部取引先の可視性と、そこから洞察を得る能力を向上させます。 わずか数クリックで取引先を招待し、利用を開始してもらうことができ、ネットワーク全体のすべてのパートナーを次のスクリーンショットのように表示できます。 この接続性により、取引先はコミュニケーションを自動化し、自社の予測を改善することもできます。 例えば、AWS Supply Chain の N-Tier Visibility から、取引先と購入注文や供給予測を共有し、それらの購入注文や在庫レベルの変化を追跡することができます。 更新された供給計画と購入注文は Amazon Simple Storage Service (S3) にエクスポートされるので、エンタープライズリソースプランニング (ERP) システムと統合できます。 内蔵されたチャットとメッセージング機能により、サプライチェーン全体でのコラボレーションがさらに容易になります。 例えば、コンポーネントの出荷が遅れた場合、在庫管理者は AWS Supply Chain アプリケーション内で回避策を特定するためにサプライヤーに連絡できます。 サプライヤーや製造業者との内部コラボレーションと情報共有の改善により、調達リスクとコンポーネント不足を検出する能力が向上し、迅速に混乱を軽減できるようになります。 AWS Supply Chain Sustainability Sustainability の機能では、サプライヤーネットワークから必須のドキュメントやデータセットをより安全で効率的な方法で入手することができます。製品のライフサイクルアセスメント、製品安全性に関する証明書、サプライチェーンの有害物質に関する報告書など、どの時点でも使用される成果物を要求、収集、エクスポートすることができます。 また、サプライヤーにサステナビリティの課題を文書化してもらうための独自のデータ収集フォームをアップロードし、複数の改装にまたがって取引相手にデータ要求を送信し、回答を追跡し、不在者にリマインダーを送信し、回答を保存・閲覧するための格納場所を提供することもできます。これは、次のスクリーンショットに示されています。 また、サプライヤーにサステナビリティの課題を文書化してもらうための独自のデータ収集フォームをアップロードし、複数の改装にまたがって取引相手にデータ要求を送信し、回答を追跡し、不在者にリマインダーを送信し、回答を保存・閲覧するための格納場所を提供することもできます。これは、次のスクリーンショットに示されています。 Amazon Q in AWS Supply Chain 最後に、Amazon Bedrock を用いた自然言語インターフェースを備えた生成 AI アシスタントにより、AWS Supply Chain は SCDL 内のデータを問い合わせでき、「何を?」「なぜ?」「もし~だったら?」といった質問に対してインテリジェントな回答を提供します。質問はアプリケーション内の文章による対話を通じて行うことができます。Amazon Q は、複雑なシナリオの結果と、さまざまなサプライチェーンの意思決定のトレードオフを可視化することもできます。 質問と回答の例は次のようになります。 Q 1 : ブレーキパッドは何個注文していますか? A 1 : ブレーキパッドカテゴリーでは、5 つの製品にわたって 1500 個を注文しています。 Q 2 : ブレーキパッドの注文数量は先月と比べてなぜ増加したのですか? A 2 : サプライヤー AA のリードタイムが先月の 28 日から今月は 56 日に延びたため、注文数量は 50% 増加しました。 Q 3 : サプライヤーがリードタイムを 2 週間短縮した場合、注文はどう変わりますか? A 3 : サプライヤー AA からのブレーキパッドのリードタイムが2週間短縮して 42 日になった場合、注文数量は 20% 減少します。 応答は次のスクリーンショットに示します。 これは、Amazon Q in AWS Supply Chain が幅の能力の広さと深さを示す例です。Amazon Q in AWS Supply Chain は応答が速く正確で、すばやく洞察を得たり、因果関係を理解したり、サプライチェーンのパフォーマンスを改善する可能性がある選択肢を特定するのに役立ちます。 まとめ AWS re:Invent は、お客様、パートナー、AWS にとってエキサイティングなイベントです。互いに出会い、学び合い、最新のイノベーションを共有できるからです。今年、サプライチェーンの計画を改善し、複数のティアのサプライチェーン全体での可視性を高め、重要な課題に対応する 4つの新機能を発表しました。Supply Planning、N-Tier Visivility、Sustainability、Amazon Q in AWS Supply Chain は、2024 年第 1 四半期初頭に利用可能になります。 AWS Supply Chain &nbsp;をご覧いただき、詳細をご確認ください。セルフペースの技術概要については、 AWS Workshops をご覧ください。re:Invent セッションの録画やその他の役立つリソースにアクセスするには、 re:Invent ページもご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Diego Pantoja-Navajas は AWS Supply Chain の VP で、ビジネスアプリケーションのビジョンと実行を担当しています。彼と彼のチームは、サプライチェーンがどのように機能できるかを根本的に考え直し、世界で初めての連続的に改善するサプライチェーンシステムオブレコードを市場に投入することに注力しています。彼は顧客の成功に情熱を注ぎ、SaaS、クラウド、AI/ML テクノロジーを活用して、サプライチェーン、e コマース、フルフィルメントに関連するビジネスの問題を解決するための高度に使いやすく知的な B2B エンタープライズソフトウェアソリューションを構築しています。Diego はジョージア工科大学の優等生で、MIT の人工知能・機械学習のエグゼクティブエデュケーションコースなど、トレーニングを続けています。また、IESE ビジネススクール、ミシガン大学ロス・ビジネススクールとのパートナーシップのもと、リーダーシップコースにも参加しています。彼は南フロリダに家族と暮らしており、顧客のビジネスの成功をさらに推進する革新的な製品やソリューションを学ぶことを常に喜んでいます。 <!-- '"` -->

この投稿は、プリンシパルスペシャリストソリューションアーキテクトの Dan Fox とシニアソリューションアーキテクトの Brian Krygsman によって執筆されました。 本日、AWS は AWS 統合アプリケーションテストキット(IATK) のパブリックプレビューを発表しました。AWS IATK は、クラウドベースのアプリケーションの自動テストを書くのに役立つソフトウェアライブラリです。このブログ記事では、AWS IATKのいくつかの初期機能を紹介し、ビデオ処理アプリケーションの例を使用して、これがどのように動作するのかを解説します。サーバーレスのテストをはじめるには、 serverlessland.com/testing で詳細をご覧ください。 概要 AWS Lambda 、 Amazon EventBridge 、 AWS Step Functions などのサーバーレスサービスで構成されるアプリケーションを作成すると、アーキテクチャコンポーネントの多くはデスクトップにデプロイできず、AWS クラウドにのみ存在します。ローカルに展開されたアプリケーションでの作業とは対照的に、これらのタイプのアプリケーションは、自動テストを実行するためのクラウドベースの戦略の恩恵を受けます。今回のパブリックプレビューのリリースでは AWS IATK は Python アプリケーションにおける実装を支援します。AWS IATK は、今後のリリースで他の言語をサポートします。 テスト用のリソースを見つける クラウドリソースの自動テストを作成するには、リソースの物理IDが必要となります。物理IDは、作成後にAWSがリソースに割り当てる名前です。たとえば、 Amazon API Gateway にリクエストを送信するには、API エンドポイントを形成する物理IDが必要です。 別々の Infrastructure as Code スタックにクラウドリソースをデプロイすると、物理IDを見つけるのが難しい場合があります。CloudFormation の場合、テンプレート内のリソースの論理IDとスタック名を作成します。IATKを使用することで、論理IDとスタック名を入力すると、リソースの物理IDが取得できます。スタック名を入力することで、スタックの出力を取得することもできます。これらの便利な方法により、記述したテストのためにリソースを見つけやすくなります。 イベント駆動型アーキテクチャのテストハーネスの作成 イベント駆動型アーキテクチャの統合テストを書くには、アプリケーションをサブシステムに分割して論理的な境界を確立します。サブシステムは、判断するのに十分シンプルで、理解可能な入力と出力が含まれている必要があります。サブシステムをテストするための有用なテクニックの 1 つは、テストハーネスを作成することです。テストハーネスは、サブシステムをテストするために特別に作成するリソースです。 たとえば、統合テストは、入力テストイベントを渡すことでサブシステムプロセスを開始できます。IATK は、出力されるイベントのために Amazon EventBridge をリッスンするテストハーネスを作成します。（内部では、ハーネスは出力イベントを Amazon Simple Queue Service に転送する EventBridge ルールで構成されています。）その後、統合テストはテストハーネスにクエリして出力を調べ、テストが成功または失敗するかどうかを判断します。これらのハーネスは、クラウドにおけるイベント駆動型アーキテクチャの統合テストを作成するのに役立ちます。 非同期機能をテストするためのサービスレベルアグリーメントを確立する 同期的なサービスを作成すると、自動テストがリクエストを行い、即時にレスポンスされることを期待します。アーキテクチャが非同期の場合、サービスはリクエストを受け取り、その後で一連のアクションを実行します。決められた期間がない場合、アクティビティの成功をどのようにテストしたら良いでしょうか？ 非同期システムのための合理的なタイムアウトを作成することを検討してください。サービスレベルアグリーメント (SLA) としてタイムアウトをドキュメント化します。SLA は外部に公開するか、内部標準としてドキュメント化するかを決定できます。IATK には、タイムアウトを確立できるポーリング機能が含まれています。この機能は、非同期システムがタイムリーにタスクを完了するかどうかをテストするのに役立ちます。 詳細なテストに AWS X-Ray を使用する アプリケーションの内部の詳細をより可視化したい場合は、 AWS X-Ray で計測します。AWS X-Rayを使用すると、複数のサービスを通じてイベントのパスを追跡できます。IATKは、AWS X-Ray のサンプリングレートを設定し、トレースツリーを取得し、トレース期間をアサートするのに役立つ便利な機能を提供します。これらの機能は、分散システムをより詳細に観察し、テストするのに役立ちます。 より詳しくは、 aws-samples/serverless-test-samples で非同期アーキテクチャのテストをご覧ください。 サンプルアプリケーションの概要 IATKの機能を示すために、この投稿ではプラグインアーキテクチャで設計されたサーバーレスビデオアプリケーションの一部を使用します。コア開発チームが主要なアプリケーションを作成します。組織全体の分散された開発チームはプラグインを作成します。1つの AWS CloudFormation スタックがプライマリアプリケーションをデプロイします。別々のスタックは各プラグインをデプロイします。 プライマリアプリケーションとプラグイン間の通信は、EventBridge バスによって管理されます。プラグインは、アプリケーションのライフサイクルイベントをバスからプルし、20秒以内に完了通知イベントをバスに戻す必要があります。テストのために、コアチームは、適切にフォーマットされたサンプルライフサイクルイベントを発行することで、実稼働プロセスを模倣する AWS Step Functions ワークフローを作成しました。開発者は、開発およびテスト環境でこのテストワークフローを実行し、プラグインがイベントバスと適切に通信していることを確認します。 次のデモンストレーションは、プラグインの動作を検証するサンプルアプリケーションの統合テストを示しています。統合テストでは、IATK は Step Functions のワークフローを特定し、プラグインから送信されるイベント完了通知をリッスンするためのテストハーネスを作成します。その後、テストはワークフローを実行してライフサイクルプロセスを開始し、プラグインアクションを開始します。その後、IATK はタイムアウト付きのポーリングメカニズムを使用して、プラグインが 20 秒のサービスレベルアグリーメントに準拠していることを確認します。以下は処理のシーケンスです。 統合テストは、テストワークフローの実行を開始します。 ワークフローは、ライフサイクルイベントをバスに PUT します。 プラグインは、バスからライフサイクルイベントを PULL します。 プラグインが完了すると、バスに完了イベントが PUT されます。 統合テストは、完了イベントをポーリングして、テストが SLA 内で合格するかどうかを判断します。 サンプルアプリケーションのデプロイとテスト 以下の手順に従って、このアプリケーションを確認し、ローカルに構築し、AWSアカウントにデプロイし、テストしてください。 サンプルアプリケーションのダウンロード ターミナルを開き、次のコマンドで GitHub から サンプルアプリケーション をクローンするか、コードを ダウンロード します。このリポジトリには、サーバーレスアプリケーションをテストするための他のサンプルパターンも含まれています。 git clone https://github.com/aws-samples/serverless-test-samples IATKサンプルアプリケーションのルートは python-test-samples/integrated-application-test-kit にあります。このディレクトリに移動します。 cd serverless-test-samples/python-test-samples/integrated-application-test-kit 統合テストのレビュー アプリケーションをデプロイする前に、テキストエディタで plugins/2-postvalidate-plugins/python-minimal-plugin/tests/integration/test_by_polling.py を開いて、統合テストが IATK をどのように使用するかを確認してください。テストクラスは、ファイルの上部にある IATK をインスタンス化します。 iatk_client = aws_iatk.AwsIatk(region=aws_region) setUp() メソッドでは、テストクラスは IATK を使用して CloudFormation スタック出力を取得します。これらの出力は、プラグインテスター AWS Step Functions ワークフローのようなデプロイされたクラウドコンポーネントの参照です。 stack_outputs = self.iatk_client.get_stack_outputs( stack_name=self.plugin_tester_stack_name, output_names=[ "PluginLifecycleWorkflow", "PluginSuccessEventRuleName" ], ) テストクラスは、スタック出力で提供されるイベントルールを使用して、リスナーをデフォルトのイベントバスにアタッチします。このテストでは、後でこのリスナーを使用してイベントをポーリングします。 add_listener_output = self.iatk_client.add_listener( event_bus_name="default", rule_name=self.existing_rule_name ) テストクラスは、 tearDown() メソッドでリスナーをクリーンアップします。 self.iatk_client.remove_listeners( ids=[self.listener_id] ) 設定が完了すると、 test_minimal_plugin_event_published_polling() メソッドによって実際のテストが実装されます。 テストは最初にトリガーイベントを初期化します。 trigger_event = { "eventHook": "postValidate", "pluginTitle": "PythonMinimalPlugin" } 次に、テストはプラグインテスター Step Functions ワークフローの実行を開始します。 setUp の実行中にフェッチされた plugin_tester_arn が使用されます。 self.step_functions_client.start_execution( stateMachineArn=self.plugin_tester_arn, input=json.dumps(trigger_event) ) テストはリスナーをポーリングし、プラグインがイベントを発火するのを待ちます。SLA で決められたタイムアウトに達するか、最大数のメッセージを受信すると、ポーリングを停止します。 poll_output = self.iatk_client.poll_events( listener_id=self.listener_id, wait_time_seconds=self.SLA_TIMEOUT_SECONDS, max_number_of_messages=1, ) 最後に、テストは適切な数のイベントを受け取り、それらが適切にフォーマットされているか検証します。 self.assertEqual(len(poll_output.events), 1) self.assertEqual(received_event["source"], "video.plugin.PythonMinimalPlugin") self.assertEqual(received_event["detail-type"], "plugin-complete") 前提条件のインストール このサンプルをビルドするには、次の前提条件が必要です。 AWSアカウント AWSリソースを管理できる資格情報がある AWS Serverless Application Model（AWS SAM）CLI Python 3.11 Node.js 18.x Docker （オプションですが、AWS SAM で Python アプリケーションを構築するのに推奨されます） サンプルアプリケーションコンポーネントのビルドとデプロイ AWS SAMを使用して、プラグインテスターを構築し、AWSアカウントにデプロイします。プラグインテスターは、前の図に示されている Step Functions ワークフローです。ビルドプロセス中に、ビルドコマンドに --use-container フラグを追加して、AWS SAM に渡されたコンテナでアプリケーションを作成するように指示できます。デプロイプロセス中にデフォルト値を受け入れるか、上書きすることができます。後で「スタック名」と「AWSリージョン」を使用して統合テストを実行します。 cd plugins/plugin_tester # plugin tester のディレクトリに移動します sam build --use-container # plugin tester をビルドします テスターをデプロイする: sam deploy --guided # plugin tester をデプロイします プラグインテスターがデプロイされたら、AWS SAMを使用してプラグインをデプロイします。 cd ../2-postvalidate-plugins/python-minimal-plugin # plugin directory に移動します sam build --use-container # plugin をビルドします プラグインをデプロイする: sam deploy --guided # plugin をデプロイします テストを実行する unittest や pytest などの標準的な Python テストランナーを使用して、IATK で書かれたテストを実行できます。サンプルアプリケーションのテストでは、ユニットテストを使用します。 仮想環境 を使用して依存関係を整理します。サンプルアプリケーションのルートから、実行します。 python3 -m venv .venv # virtual environment を作成する source .venv/bin/activate # virtual environment を activate する IATK を含む依存関係をインストールします。 cd tests pip3 install -r requirements.txt テストを実行し、以前のデプロイから必要な環境変数を提供します。 plugin_tester ディレクトリの samconfig.toml ファイルでその値を見つけることができます。 cd integration PLUGIN_TESTER_STACK_NAME=video-plugin-tester AWS_REGION=us-west-2 python3 -m unittest ./test_by_polling.py ユニットテストがテストを実行すると、出力が表示されるはずです。 AWS アカウントで Step Functions コンソールを開き、 PluginLifecycleWorkflow-&lt;random value&gt; ワークフローを選択して、プラグインテスターが正常に実行されたことを確認します。最近の実行は、成功したステータスを示しています。 他のIATK機能を確認する サンプルアプリケーションには、モックイベントの生成やAWS X-Rayトレースの取得など、他のIATK機能の例が含まれています。 クリーンアップ AWS SAM を使用して、AWS アカウントからプラグインとプラグインテスターの両方のリソースをクリーンアップします。 プラグインのリソースを削除する: cd ../.. # plugin directory に移動する sam delete # plugin を削除する プラグインテスターのリソースを削除します。 cd ../../plugin_tester # plugin tester directory に移動する sam delete # plugin tester を削除する IATK がテスト中に作成した一時的なテストハーネスリソースは、 tearDown メソッドが実行されるとクリーンアップされます。実行中に問題が発生した場合、一部のリソースは削除されない可能性があります。IATK は、作成したすべてのリソースにタグを追加します。 これらのタグ を使用してリソースを見つけ、手動で削除できます。また、 独自のタグを追加 することもできます。 まとめ AWS 統合アプリケーションテストキット（IATK）は、クラウドアプリケーションの自動テストを書くのに役立つ便利なソフトウェアライブラリです。このブログ記事は、IATK の初期Python バージョンの機能のいくつかを示しています。 サーバーレスアプリケーションの自動テストの詳細については、 serverlessland.com/testing をご覧ください。また、 serverlessland.com/testing/patterns または GitHub の AWS serverless-test-samples リポジトリでコード例を表示することもできます。 より多くのサーバーレス学習リソースについては、 Serverless Land をご覧ください。 翻訳はソリューションアーキテクトの淡路が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 この記事は AWS re:Invent 2023 特別号の後半にあたる Part 2 です。 今週は AWS re:Invent 2023 特別号のため週刊AWSは二本立てになっています。 Part 1 をまだお読みでない方はこちら からお読みいただけます。また、 Part 1 にも記載していますが、発表内容をほぼ網羅したセミナー「 AWS Black Belt Online Seminar AWS re:Invent 2023 速報 」の資料と動画が公開されていますので、こちららも合わせてご覧ください。 それでは、AWS re:Invent 2023 でのアップデート、後半をみていきましょう。Part 2 では、以下のカテゴリについてまとめました。Generative AI / Machine Learning のカテゴリでは、アップデート内容が多くなっております。 カテゴリリンク : Generative AI / Machine Learning | Management &amp; Governance | Networking &amp; Content Delivery | Security, Identity, &amp; Compliance | Serverless | Storage AWS re:Invent 2023 期間に発表された主要なアップデート Part 2 (2023/11/27週) Generative AI / Machine Learning Introducing Amazon Q, a new generative AI-powered assistant (preview) Amazon Q のプレビューを開始しました。Amazon Q は、お客様のビジネスに合わせて作業できるように設計されている、生成系 AI を活用したアシスタントです。組織内のデータソースと連携しながら、会話、問題の解決、アイデアの生成、アクション実行などができます。Amazon Q は特定のサービスということではなく、AWS をご利用いただくお客様を様々なシチュエーションでご支援するアシスタントです。複数の利用方法があり、マネジメントコンソールで「Amazon Q」と検索すると出てくるアシスタント機能、マネジメントコンソール右側の Q アイコンからアクセスする会話型の Q&amp;A 機能、AWS ドキュメント、各種 AWS サービス、IDE (統合開発環境) などでご支援するものです。各種アップデートで「Amazon Q」という用語が出てきますが、混乱しないようにしましょう。様々な状況で横に寄り添って支援してくれる、そんな感覚で良いと思います。 このアップデートは AWS マネジメントコンソール上で「Amazon Q」で検索して開くことのできるアシスタント機能についてです。組織内のデータと連携するためのコネクターや、会話型の Web インターフェースなどが提供されており、アシスタントを組織用にカスタイマイズできます。汎用的にアシスタントを構成でき、ビジネス用途向けにも活用いただけます。プレビュー時にサポートされているデータソースの連携先は、 こちらのドキュメント に記載があります。また、Web エクスペリエンスでは、任意の IdP と連携した Web 画面を利用できます。AWS マネジメントコンソールを省略して直接の Web アクセスを提供できるため、組織内の展開がやりやすくなります。プレビュー中は、Amazon Q の機能の多くを無料でご利用頂けるため、ぜひお試しください (一部有料のものがあります)。バージニア北部とオレゴンでプレビューが提供されています。詳細は こちらの Blog をご覧ください。 Amazon Q brings generative AI-powered assistance to IT pros and developers (preview) Amazon Q は、開発者や IT プロフェッショナルをサポートするいくつかの機能があります。一つ利用例を挙げると、マネジメントコンソールの右側の Q アイコンからアクセスする「会話型の Q&amp;A 機能」は、アプリケーションを構築する方法やベストプラクティスなどをチャット形式で調査できます。たとえば、「サーバーレス API を構築するための AWS サーバーレスサービスとは何ですか?」と英語で質問すると、回答と参考資料を提示してくれます。疑問が残っている場合は追加で質問を投げることも可能です。現時点では日本語は利用できない点にご留意ください。他には、最適な EC2 インスタンスのアドバイス、Lambda 関数のエラートラブルシュート、ネットワーク接続性のトラブルシュート、IDE 上からアクセスなどがあります。詳細は こちらの Blog をご覧ください。 Amazon Bedrock now provides access to Anthropic’s latest model, Claude 2.1 Amazon Bedrock で Claude 2.1 の提供が開始されました。11/21 に Anthropic 社が最新基盤モデルの Claude 2.1 を発表し、それに Bedrock が対応した形です。エンタープライズに必要な機能を提供しており、Claude 2.0 と比較してトークン数が 2 倍の 20万に拡張、ハルシネーション率の低減、長い文書における精度の向上、システムプロンプト、ベータ版のツール機能などがあります。ハルシネーションの改善について取り上げると、自由形式の会話や文書 Q&amp;A でのハルシネーションが 50% 減少し、誤った回答が 30% 減少しました。これらの精度向上により、お客様や従業員向けに、より信頼性の高く重要なアプリケーションを構築しやすくなりました。Claude 2.1 を利用する際に、モデルアクセスの有効化が必要です。Claude 2.1 は現在、バージニア北部とオレゴンで利用可能です。 詳細は こちらの Blog をご覧ください。 Evaluate, compare, and select the best foundation models for your use case in Amazon Bedrock (preview) Amazon Bedrock で基盤モデルを評価する機能がプレビュー提供され、ユースケースに最適なモデルを選択しやすくなりました。モデルによって特徴の違いがあり、洗練された対話や創造性の高い生成が得意なパワフルなモデルや、回答スピードが速く低コストで軽量な生成が得意なモデルなどがあります。これを一つずつ試していくのは大変なので、評価を行う支援機能が提供されました。評価のタイプは「自動評価」と「人手評価」の 2 種類があります。「自動評価」は、事前に「プロンプト」と「あるべき答え」を定義した JSON ファイルを用意することで、基盤モデルを自動的に評価しスコアを表示してくれる機能です。「人手評価」では、自動で行う代わりに組織内の特定の方をアサインして、手動による評価を進める機能があります。サポートされるリージョンは、若干の機能の違いはありますが、バージニア北部とオレゴンでプレビュー利用が可能です (人手評価に、AWS 管理チームに評価を依頼する機能がありますが、これはバージニア北部のみ可能です)。詳細は こちらの Blog をご覧ください。 Amazon Titan Image Generator, Multimodal Embeddings, and Text models are now available in Amazon Bedrock Amazon Bedrock で、いくつかの新しいモデルが提供されました。画像生成をおこなう Amazon Titan Image Generator のプレビュー提供、テキストと画像を組み合わせてベクトル埋め込みを生成し検索に活かす Amazon Titan Multimodal Embeddings のリリース、テキスト生成を行う Amazon Titan Text Lite と Amazon Titan Text Express のリリースがされました。Amazon Titan モデルは、Amazon の 25 年間にわたる人工知能と機械学習のイノベーションが組み込まれており、フルマネージド API を通じてさまざまな高性能の画像、マルチモーダル、テキストモデルへのアクセスを提供します。 AWS はこれらのモデルを大規模なデータセットで事前トレーニングし、AI の責任ある使用もサポートしながら、さまざまなユースケースを対応できるように構築しています。Amazon Titan Text は、東京を含めた 5 リージョンで利用可能です。Amazon Titan Multimodal Embeddings は、バージニア北部とオレゴンで利用可能です。 Amazon Titan Image Generator は、バージニア北部とオレゴンでパブリックプレビューとして利用できます。詳細は こちらの Blog をご覧ください。 Guardrails for Amazon Bedrock helps implement safeguards customized to your use cases and responsible AI policies (preview) Guardrails for Amazon Bedrock の限定プレビューを開始しました。これは、責任ある AI 提供を支援する機能となっており、組織内のポリシーに合わせて基盤モデルの出力結果をコントロールしやすくするものです。いくつかの機能があり、「トピックの拒否」は、短い自然言語で拒否すべきトピックを定義しておくことで、不適切なリクエストを対応しないようにする機能です。たとえば、Bedrock を活用して銀行の AI アシスタントを提供するときに、銀行からの公式ガイドとして受け取ってほしくないため、投資アドバイスの話題に対応したくない場合があります。この機能で事前に「投資アドバイス」と定義しておくことで、不適切な話題を拒否できます。「コンテンツフィルター」は、憎悪、侮辱、性的、暴力の 4 カテゴリについて、しきい値を設定し、有害なコンテンツをフィルターできます。 多くの基盤モデルは、望ましくない有害な生成を防ぐための保護機能が組み込まれていますが、この機能によって組織内のポリシーに基づき、責任のある AI の提供をやりやすくします。利用したい場合は AWS サポートの連絡先にお問い合わせください。詳細は こちらの Blog をご覧ください。 Knowledge Bases now delivers fully managed RAG experience in Amazon Bedrock Amazon Bedrock で Knowledge Bases の一般提供を開始しました。Knowledge Bases を使うと、Bedrock の基盤モデルに組織内のデータを安全に接続し、そのデータを使ってより適切で正確な応答を生成する Retrieval Augmented Generation(RAG) ができるようになります。Knowledge Bases で取得したデータに基づいて回答をしてくれるため、ハルシネーションを最小限に抑えられます。Knowledge Bases の裏側にある、ベクトルストアの構築、ベクトル埋め込み、クエリーなどを自動的に行ってくれるため、簡単に RAG を実装できます。留意点は、ベクトルストアの部分は Knowledge Bases に加えて追加の料金が掛かります。ベクトルストアは、Amazon OpenSearch Serverless (自動構成機能あり)、Pinecone、Redis Enterprise Cloud が利用可能です。Amazon Aurora と MongoDB も近々サポートされる予定です。バージニア北部とオレゴンで利用可能です。詳細は こちらの Blog をご覧ください。 Agents for Amazon Bedrock is now available with improved control of orchestration and visibility into reasoning Amazon Bedrock で Agents for Amazon Bedrock の一般提供を開始しました。この機能は、ユーザーの要求したタスクを基盤モデルの推論機能を利用して、複数のステップに分割し、その後のアクションを実行します。推論したステップによっては、Knowledge Bases に格納されている組織内データにアクセスを行うことや、事前に定義した API にアクセスして情報の更新などを行います。ユースケースを挙げると、小売注文の管理や保険請求の処理などが考えられます。注意点は、行動するアクションは基盤モデルが推論する内容に基づくため、場合によってはハルシネーションが含まれる可能性があります。本番環境に利用する前に、しっかりとした検証を行うのが特に重要です。バージニア北部とオレゴンで利用可能です。詳細は こちらの Blog をご覧ください。 Amazon CodeWhisperer offers new AI-powered code remediation, IaC support, and integration with Visual Studio Amazon CodeWhisperer で、 「IaC サポート」、「AI を活用したコード修復 」、「Visual Studio のプレビューサポート」の 3 つのアップデートがありました。「IaC サポート」は、AWS CloudFormation (YAML、JSON)、AWS CDK (Typescript、Python)、および HashiCorp Terraform (HCL) のコードを生成できるようになりました。例えば、Visual Studio Code のエディタ上で 「# S3 バケットを作成」とコメントを入力すると、Amazon CodeWhisperer がコメントを読み取りソースコードの候補を生成します。候補を確認し、良さそうな場合は Tab キーを押すことでエディタ上にコードが反映されます。「AI を活用したコード修復」についてですが、アップデート前は CodeWhisperer が持つセキュリティスキャン機能でコード上の脆弱性を指摘してくれました。今回のアップデートで、指摘するのに加えて修正後のコードを提案してくれるようになり、迅速な修正が容易になりました。「Visual Studio のプレビューサポート」は、Visual Studio 2022 のサポートを提供するものです。C# のリアルタイムなコード提案を利用して、アプリケーションを素早く開発できます。詳細は こちらの Blog をご覧ください。 Use natural language to explore and prepare data with a new capability of Amazon SageMaker Canvas Amazon SageMaker Canvas で、データ調査、分析、可視化、変換といったデータの前準備を、自然言語で指示できるようになりました。Amazon Bedrock で提供される基盤モデルに基づき、自然言語であたえられた指示を解釈します。一つ例を挙げると、住宅価格の予測モデルを作るときに、部屋の大きさと収入の分布を可視化したいとします。SageMaker Canvas のチャットインターフェースに「plot room_size vs median_income」と入力すると、部屋の大きさ (room_size) と収入 (median_income) の散布図を可視化してくれます。次に、人口が 1000 人以下の町をフィルターしたいときには、さきほどと同様に「remove rows where population is less than 1000」と入力することで、該当の行を削除してくれます。また、裏側で生成された PySpark などのソースコードを確認でき、内容の微調整を行いたい場合はソースコードの手動編集も可能です。なお、私が試した範囲では、日本語の自然言語でも理解してくれました。Amazon SageMaker Canvas と Amazon Bedrock がサポートされているすべての AWS リージョンで利用できますが、東京リージョンはまだ利用できませんでした。詳細は こちらの Blog をご覧ください。 Amazon SageMaker Studio adds web-based interface, Code Editor, flexible workspaces, and streamlines user onboarding Amazon SageMaker Studio で Web インターフェースの新しい体験を提供開始しました。新しい Web インターフェースは、読み込みが速くなり、好みの IDE を選択できる特徴を持ちます。IDE は、JupyterLab と RStudio に加えて、Code-OSS (Visual Studio Code Open Source) に基づくフルマネージドコードエディターが含まれるようになりました。Visual Studio Code に慣れている方は、手に馴染みやすいと思います。Visual Studio Code 互換の何千もの拡張機能をインストールすることができ、好みの環境を作り上げることが出来ます。Visual Studio Code 用の AWS Toolkit、コード生成の CodeWisperer、セキュリティスキャンの CodeGuru もご利用頂けます。元々の SageMaker Studio Classic を利用したことが有り、新しい Web インターフェースを利用したい場合は、AWS CLI を使った切り替え作業が必要です。詳細は AWS Blog や マイグレート用のドキュメント をご覧ください。SageMaker Studio が利用可能なすべてのリージョンで利用可能です。 Management &amp; Governance Amazon CloudWatch Application Signals for automatic instrumentation of your applications (preview) Amazon CloudWatch Application Signals のプレビュー提供が開始されました。Amazon で何千ものアプリケーション運用から得られたベストプラクティスに基づいて構築されており、AWS 上でアプリケーションを自動的に計測して運用を楽にする新機能です。手作業による設定を軽減し、重要なビジネス目標に照らしてアプリケーションのパフォーマンスを追跡できます。事前に構築されたダッシュボードを使用して、各アプリケーションのボリューム、レイテンシ、エラーなどの標準化されたメトリクスを確認できます。 東京を含む 5 リージョンでプレビュー提供されています。詳細は こちらの Blog をご覧ください。 Use natural language to query Amazon CloudWatch logs and metrics (preview) Amazon CloudWatch logs と metrics で自然言語を使ったクエリー生成のプレビュー提供を開始しました。logs や metrics をクエリーで検索する際に、自然言語を入力することでクエリーを生成できます。検索を行う際に、手動でクエリーを組み立てる負担を軽減でき、自動生成したクエリーを基に使い始められます。例えば metrics の例を挙げると「CPU 使用率の高い EC2 インスタンスを表示」と入力したあとにクエリー生成ボタンを押すことで、その入力に基づいたクエリーが生成されます。生成結果を確認しながら、より詳細な説明を与えて再度生成ができ、また、生成されたクエリーを手動で微調整することも可能です。バージニア北部とオレゴンでプレビューが開始されています。詳細は こちらの Blog をご覧ください。 New Amazon CloudWatch log class for infrequent access logs at a reduced price CloudWatch Logs で新しいログクラスの Infrequent Access を提供開始しました。通常のログクラスと比較して、1 GB あたりのログ取り込みの料金が 1/2 で提供されており、コスト効率のよい利用ができるようになりました。反面、通常のログクラスで利用できる Live Tail、サブスクリプションフィルター、S3 へのエクスポートなどの機能が制限されています。なお、Logs Insight を利用した検索は Infrequent Access でも利用可能です。全てのリージョンで利用可能です。詳細は こちらの Blog をご確認ください。 Networking &amp; Content Delivery Mutual authentication for Application Load Balancer reliably verifies certificate-based client identities Application Load Balancer で mTLS (Mutual authentication) のサポートを開始しました。クライアント証明書を使った認証に利用できる機能で、アクセスを許可したい端末にクライアント証明書を配置することで、その端末に限定したアクセスを提供できます。ALB の mTLS では、「パススルー」と「トラストストアで検証」の 2 つの方式があります。「パススルー」では、クライアントから受信したすべてのクライアント証明書チェーンをバックエンドアプリケーションに送信します。ALB のバックエンドにあるアプリケーション側でクライアントを認証するためにクライアント証明書チェーンを検証する必要があります。「トラストストアで検証」では、ACM の Private 認証局、もしくはサードパーティの CA と連携してクライアント認証を行います。全てのリージョンで利用可能です。詳細は こちらの Blog をご覧ください。 Zonal autoshift – Automatically shift your traffic away from Availability Zones when we detect potential issues Amazon Route 53 Application Recovery Controller で Zonal autoshift を提供しました。アベイラビリティーゾーン (AZ) に影響を与える潜在的な障害を AWS が特定した場合に、障害を検知した AZ にトラフィックを送信せず、 代わりに正常に稼働している AZ に送信する機能です。その後、検知した AZ 障害が回復した場合、元の構成に戻ります。手動で AZ を切り離す機能を提供してきましたが、AWS が検知するものについて自動で行うアップデートとなります。なお、AZ の切り離しは慎重に行うべき操作なので、Zonal autoshift を有効化した場合は、毎週 30 分間、実際に切り離すテストを行います。切り離すテストのタイミングは、任意の時間帯に指定が可能です。本番環境に影響を与えないように複数の AZ で事前にリソース配置することや、切り替えが問題ないようにアプリケーションの構成が必要です。全てのリージョンで利用可能です。詳細は こちらの Blog をご覧ください。 Security, Identity, &amp; Compliance IAM Access Analyzer updates: Find unused access, check policies before deployment AWS IAM Access Analyzer に 2 つの新機能が追加されました。1 つ目は Unused Access Analyzer です。これは、付与されたが実際には使用されていない権限を持つロールやユーザーを継続的にモニタリングする新しいアナライザーです。組織のセキュリティチームは、不要な権限、ロール、IAM ユーザーの見直しが必要なアカウントを特定するのに役立つダッシュボードを活用できます。2 つ目は、Custom Policy Checks です。これは、新しく作成されたポリシーが意図しない権限を付与していないことを検証するものです。例えば、CI/CD パイプラインにこのチェック機能を追加することで、継続・自動的なチェックが可能になります。全ての AWS リージョンで利用可能です。詳細は こちらの Blog をご覧ください。 Detect runtime security threats in Amazon ECS and AWS Fargate, new in Amazon GuardDuty Amazon GuardDuty で ECS ランタイムモニタリングの一般提供を開始しました。これは、Amazon ECS on Fargate で稼働するコンテナワークロードで、ランタイムの脅威検知を提供する拡張機能です。2023 年の初めに、Amazon EKS でランタイムモニタリングを提供してきました。これが、Amazon ECS on Fargate に拡張して提供された形です。ランタイムの脅威を示す可能性のあるファイルアクセス、プロセスの実行、ネットワーク接続などのランタイムイベントを検出するのに役立ちます。たとえば、権限昇格の試み、仮想通貨マイニングやマルウェアによって生成されたアクティビティ、攻撃者による偵察を示唆するアクティビティなどを検出できます。東京を含めた 9 個のリージョンで利用可能です。詳細は こちらの Blog をご覧ください。 Serverless AWS Lambda functions now scale 12 times faster when handling high-volume requests AWS Lambda 関数のスケーリング速度が最大 12 倍速くなりました。アップデート以前は、Lambda 関数は最初の 1 分間で 500 ~ 3,000 並列実行までスケールアップし、その後 1 分間に 500 並列実行ずつアカウントの制限に達するまでスケールアップしていました。このスケーリング制限は、同じアカウントとリージョンの全関数で共有されていたため、ある関数でトラフィックが急増した場合、同じアカウントの他の関数のスループットに影響を与える可能性がありました。今回の改善により、各 Lambda 関数はアカウント内の他の関数とは独立してスケーリングできるようになりました。また、アカウントの並列実行制限に達するまで 10 秒ごとに 1,000 の並列実行数をスケールアップできるようになりました。この改善により、トラフィックの変動が大きい顧客は、以前よりも速く並列実行目標に到達できるようになります。全てのリージョンで利用可能です。詳細は こちらの Blog をご覧ください。 Storage Announcing the new Amazon S3 Express One Zone high performance storage class Amazon S3 で新しいストレージクラスとして Express One Zone の一般提供を開始しました。一貫して 1 桁ミリ秒のレイテンシーを要求する性能重視なアプリケーション向けに設計されています。S3 Standard と比較してデータアクセス速度が 10 倍向上し、リクエストコストが 1/2 となり、1 分あたり数百万件のリクエストを処理できるように拡張できます。保存されるオブジェクトは、1 個の AZ 内にある専用ハードウェアに保存、レプリケートされます。あらゆるサイズのオブジェクトを処理できますが、特に小さいオブジェクトに最適です。レイテンシーが短くなっており、多数の小さいファイルにアクセスするときに恩恵が得られやすいです。デメリットとしては、単一の AZ で火災や水害などの障害が発生した場合、データが失われる可能性があります。このような障害を除けば、Express One Zone はディスク障害、ホスト障害、ラック障害からオブジェクトを保護できる仕組みがあり、99.999999999 % のデータ耐久性を実現するように設計されています。東京リージョンを含む 4 リージョンで利用可能です。詳細は こちらの Blog をご覧ください。 Amazon EBS Snapshots Archive is now available with AWS Backup Amazon EBS のスナップショットを、低コストのアーカイブストレージに移行できる機能が、AWS Backup でも利用可能になりました。これまで、この機能は Amazon EC2 コンソールや Amazon Data Lifecycle Manager で利用できましたが、今回のアップデートにより、AWS Backup からも利用できるようになりました。EBS スナップショットアーカイブは、頻繁または高速な取得を必要とせず、めったにアクセスされないスナップショット向けの低コストの長期ストレージ層で、ストレージコストを最大 75% 節約できます。すべてのリージョンでご利用頂けます。詳細は こちらの Blog をご覧ください。 Automatic restore testing and validation now available in AWS Backup AWS Backup は、リソースの復元テストを実行できる restore testing を提供開始しました。この機能により、ストレージ、コンピューティング、データベース全般の AWS リソースに対して復元テストを自動化できます。ランサムウェアなどのデータ損失が発生した場合に、バックアップを使用して正常に復旧できるかどうかを事前に判断することで、安全なバックアップリストア戦略を実現できます。東京や大阪を含めた 27 リージョンでご利用頂けます。詳細は こちらの Blog をご覧ください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 先週は AWS re:Invent 2023 が開催されました。週刊AWSは、毎週の新発表を発表日ごとに纏めるというのがコンセプトなのですが、今回は昨年に引き続きサービスのカテゴリごとにまとめる形にしました。非常に多くのアップデートがあったので、できる限りお届けしたく今回は Part 1 （本稿）と、 Part 2 の二本立てになります。 re:Inventのアップデートに関しては12/1(金)に発表内容をほぼ全て網羅したセミナー「 AWS Black Belt Online Seminar AWS re:Invent 2023速報 」も開催されています。こちらの資料と動画もすでにアップロードされていますのでぜひご確認ください。 また、年明けの2024年2月にre:Inventで発表された多くのアップデートを振り返るRecapイベントも開催いたします。以下のリンクからすでにお申し込みいただけますので是非ご参加ください！ AWS re:Invent Recap – ソリューション編 AWS re:Invent Recap – インダストリー編 それでは まずは Part 1 を見ていきましょう。こちらでは以下のカテゴリについて取り扱います。 カテゴリリンク : Analytics | Application Integration | Business Applications | Cloud Financial Management | Compute | Contact Center | Container | Customer Enablement | Database | Developer Tools | End User Computing AWS re:Invent 2023期間に発表された主要なアップデート Part 1 (2023/11/27週) Analytics Amazon Redshift announces Multidimensional Data Layouts to optimize your query performance (preview) Amazon Redshiftの多次元データレイアウトソートキーサポートのプレビューが発表されました。多次元データレイアウトソートキーとは列に保存されているデータの順番でソートするのではなくフィルター述語でテーブルのデータをソートする新しいタイプのソートキーで、特にクエリワークロードに反復スキャンフィルターが含まれている場合に、テーブルスキャンのパフォーマンスを大幅に向上させます。この機能は東京を含む6つのリージョンでプレビューを利用可能です。詳細については ドキュメント や ブログ をご確認ください。また、この機能に限らず、re:Invent中に発表されたRedshiftの機能をまとめた 日本語ブログ も発信されています。合わせてご確認ください。 Amazon Q generative SQL is now available in Amazon Redshift Query Editor (preview) Amazon Redshift クエリエディタでAmazon Q Generative SQLのプレビューが発表されました。通常、Redshiftで分析のSQLを作成するには組織が持つデータの知識が必要になるかと思います。一方、Amazon Q Generative SQLを利用するとデータ構造やテーブル名を理解した上でSQLの生成を支援してくれる他、自然言語で調べたい内容を記入することでSQLを生成してくれるので、SQL作成の生産性が向上します。Amazon Q Generative SQLはバージニア北部、オレゴンでパブリックプレビューが可能です。詳細については ドキュメント もご確認ください。 Amazon Q in QuickSight simplifies data exploration with Generative BI capabilities (Preview) Amazon Q in QuickSightのプレビューが発表されました。この機能は自然言語によるダッシュボードの要約、データの説明のサマリー、データに関するミニダッシュボードの生成等を支援してくれるため、特にビジネスユーザのようにシステムに精通しないユーザーの生産性を高めることが可能です。Amazon Q in QuickSightはバージニア北部、オレゴンでパブリックプレビューが可能です。詳細については ブログ もご確認ください。 Amazon OpenSearch Service zero-ETL integration with Amazon S3 preview now available Amazon OpenSearch Service zero-ETL integration with Amazon S3のプレビューが発表されました。これまで、OpenSearchで検索したいデータはS3などの保管場所からOpenSearchにコピーする必要がありデータの複製の手間やコストがかかっていました。今回の機能追加により、S3に保存したデータに対してOpenSearchから直接アクセスすることが可能になったので、例えば運用ログのようなアクセス頻度の低いデータに関してはよりコスト効率よく、手間なく利用することが可能になります。この機能は東京を含む6つのリージョンでプレビューを利用可能です。詳細については ブログ や ドキュメント をご確認ください。 Accelerate data processing and analysis with Amazon EMR and Amazon S3 Express One Zone Accelerate data lake queries with Amazon Athena and Amazon S3 Express One Zone Amazon AthenaとAmazon EMRがAmazon S3 Express One Zoneに対応しました。(Amazon S3 Express One Zoneに関しては Part2 で扱っているのでそちらもご確認ください。) S3 Express One ZoneはS3 Standard と比較してデータアクセス速度が10倍向上し、リクエストコストが1/2のため、AthenaやEMRのようにS3のデータを直接参照するサービスにおいて性能向上と処理のコスト最適化が見込めます。Athenaでは最大2.1倍、EMRでは最大4.0倍高速化されます。詳細については Athena 、 EMR 各々のドキュメントをご確認ください。 AWS announces Amazon ElastiCache Serverless Amazon OpenSearch Serverless でベクトルエンジンの一般提供が開始されました。OpenSearch Serverless のベクトルエンジンは、シンプルでスケーラブルな高性能のベクトルデータベースであり、サーバーを管理することなく、機械学習や人工知能の機能を持つアプリケーションと簡単に連携ができるようになります。生成系 AI でベクトル埋め込みを生成し、文脈を意識したセマンティック検索などを実現する際に、検索エンジンとしてベクトルエンジンを利用できます。数千次元をもつ数十億のベクトル埋め込みをミリ秒以内に保存、更新、検索が実現できます。東京を含めた8つのリージョンで利用できます。詳細はこちらの ブログ をご確認ください。 Application Integration Amazon SQS announces increased throughput quota for FIFO High Throughput mode Amazon SQS announces support for FIFO dead-letter queue redrive Amazon SQSのデッドレターキューの再配信機能強化と、FIFO キューの高スループットモードの上限引き上げが発表されました。これまでもデットレターキューからの標準ソースキューや標準カスタム宛先キューへのメッセージの再配信をサポートしていました、今回のアップデートでFIFOソースキューやFIFOカスタム宛先キューへの再配信もサポートした形です。これによりリトライやデバッグの為の再配信が柔軟になります。この機能追加はSQSが利用可能なすべてのリージョンで利用できます。また、高スループットモードに関してはバージニア北部、オレゴン、アイルランドで最大70,000件/秒まで強化されています。詳細については こちらのブログ もご確認ください。 Business Applications Introducing Amazon One Enterprise (Preview) 組織のアクセスコントロールのための手のひら認証デバイス、Amazon One Enterpriseのプレビューが発表されました。Amazon One Enterpriseの精度は99.9999％を誇り、データの転送や保存に渡り多層のセキュリティ対策がされています。エンタープライズ企業の厳格なアクセスコントロールの方法をバッチやPIN、パスワードなどから置き換えることで管理者の手間を削減できます。Amazon One Enterpriseは米国内のみでのプレビューとなります。詳細に関しては Contact us からご確認ください。 Cloud Financial Management AWS Free Tier usage is now available through the GetFreeTierUsage API AWS 無料利用枠の使用状況にGetFreeTierUsage API経由でアクセスできるようになりました。これによりAWS SDKやCLI、そしてサードパーティのツールを介してプログラム的に把握することが可能になります。詳細については ブログ も出ているので是非ご確認ください。 Introducing Cost Optimization Hub AWS Billing and Cost ManagementにCost Optimization Hubという機能が追加されました。Cost Optimization HubはOrganizationのメンバーアカウントやリージョン全体でコスト最適化の推奨事項に関して可視化や検討をサポートする機能です。コスト最適化の推奨事項は、EC2インスタンスの適正サイズ、起動されて未使用のリソース、Gravitonの移行推奨、Savings Plan等15以上準備されています。詳細についてはこちらの ブログ や ユーザーガイド もご確認ください。 Compute Announcing Amazon EC2 High Memory U7i instances (Preview) 最大32TiBのDDR5メモリを備えたAmazon EC2 U7iインスタンスのプレビューが発表されました。U7iインスタンスはXeon Scalable Processors (Sapphire Rapids)を採用しておりU-1インスタンスと比較し最大125%高い処理性能を発揮と最大100Gbpsのネットワーク帯域を持ちます。主にはSAP HANAやその他インメモリのデータベース等に最適なインスタンスです。このプレビューでは、U7i インスタンスは u7in-16tb.224xlarge、u7in-24tb.224xlarge、u7in-32tb.224xlarge の 3 つのサイズでご利用いただけます。詳細については ブログ や、U7iインスタンスのプレビューへのアクセスをリクエストするには High Memory インスタンスのページ をご覧ください。 Announcing new Amazon EC2 R8g instances powered by AWS Graviton4 processors (Preview) Amazon EC2 R8gインスタンスのプレビューが発表されました。AWS Graviton4 プロセッサを搭載しており、AWS Graviton3とくらべ30%高速かつ、広いメモリ帯域を持つので、データベースやインメモリストア、リアルタイムのビックデータ分析などに最適です。R8gインスタンスのプレビューへのアクセスをリクエストするには Amazon R8g インスタンスのページ をご覧ください。また、詳細については ブログ もご確認ください。 Contact Center Amazon Q in Connect offers generative AI powered agent assistance in real-time Generative AIを活用したアシスタントサービスであるAmazon QをConnectでも利用できるようになりました。Amazon Q in Connectにより、通話やチャットの中で顧客の意図をリアルタイムに検出し、推奨アクションや対応するエージェントに関連文献をサジェスチョンすることが可能になります。東京リージョンを含む6つのリージョンでご利用可能です。詳細に関しては ブログ や ドキュメント もご確認ください。 Amazon Connect provides Zero-ETL analytics data lake to access contact center data (preview) Amazon Connect analytics data lakeのプレビューが発表されました。analytics data lakeを使うと、複雑なワークフローを作らずともコンタクトセンターのパフォーマンス指標の可視化や詳細な分析が可能になります。また、Amazon Athena、Amazon QuickSight、3rd-Partyツールとも連携してカスタムレポートやダッシュボード作成も可能です。Amazon Connect analytics data lakeは東京を含む10リージョンでプレビュー利用が可能です。詳細については ドキュメント もご確認ください。 Container Amazon EKS introduces EKS Pod Identity Amazon EKSで、PodにIAM Roleを割り当てる新機能としてEKS Pod Identityがリリースされました。これまで同じことをするにはIAM roles for service accounts(IRSA)をする必要がありましたが、今回の機能を使うとより簡単に設定することが可能です。例えば、新しいクラスターを作成した際にロール信頼性ポリシーの更新が不要になるほか、クラスター名、名前空間、サービスアカウント名などの属性とAWSリソースのアクセス権限の紐付け等ができるようになります。EKS Pod IdentityはAWS GovCloud, 北京、寧夏を除くAmazon EKSが利用可能なすべてのAWSリージョンでご利用可能です。詳細については ドキュメント や ブログ もご確認ください。 Amazon Managed Service for Prometheus launches an agentless collector for Prometheus metrics from Amazon EKS Amazon Managed Service for Prometheus collectorが発表されました。これまで、PrometheusでEKSのメトリクスを収集するためにはエージェントの導入と、管理が必要でした。今回のアップデートにより、Amazon EKSコンソール、もしくはAPI経由でエージェント不要でKubernetes APIサーバからのメトリクスを検出、収集できるようになりました。このアップデートはAmazon Managed Service for Prometheusが利用可能なすべてのリージョンで利用可能です。詳細については ブログ もご確認ください。 Customer Enablement Announcing the general availability of AWS re:Post Private AWS re:Post Privateの一般提供が開始されました。AWS re:Post は、AWSが管理するQ&amp;Aサービスで、AWSに関する技術的な質問に対して、専門家やコミュニティメンバーがやりとりできるものです。今回、このPrivate版として企業・組織内で利用いただける他、AWSサポートセンターとの統合によりディスカッションスレッドをサポートケースに変換することも可能です。Enterprise SupportおよびEnterprise On-Ramp Supportをご利用の方向けのサービスで、オレゴンとフランクフルトの２つのリージョンで提供開始されています。詳細については re:Post Rivate のページや ブログ もご確認ください。 Database Announcing Amazon Aurora Limitless Database Amazon Aurora クラスターを秒間数百万の書き込みでも対応できるよう自動スケールするAmazon Aurora Limitless Databaseのプレビューが発表されました。トランザクションへの一貫性を維持しながらデータやクエリを自動的に分散してくれるサーバレスエンドポイントや、分散型のクエリプランニング、トランザクション管理の機能により、シャーディングのように複数のデータベースを管理する必要なく拡張性を得ることが可能です。Aurora Limitless Databaseは、東京を含む４つのリージョンで、Amazon Aurora PostgreSQL 互換エディションの限定プレビューを行なっています。プレビューへの参加リクエストは こちら から行うことができます、 Announcing the general availability of Amazon RDS for Db2 Amazon RDSのラインナップにDb2が追加されました。Db2 バージョン11.5をサポートしており、ライセンスはBYOLが必要になります。マネージドサービスとして利用することで、プロビジョニング、パッチ適用、バックアップ、障害検出、リカバリ等、管理タスクをRDSに任せることができ、よりアプリケーションやビジネスに集中いただけます。その他詳細に関しては ドキュメント や ブログ をご確認ください。 AWS announces Amazon DynamoDB zero-ETL integration with Amazon OpenSearch Service Amazon DynamoDBとAmazon OpenSearch ServiceがZero-ETLに統合されました。この統合により、DynamoDBのデータを逐一抽出、変換、コピーするプログラムや仕組みを構築することなく、シームレスにOpenSearchで全文検索やベクトル検索などの高度な検索をすることが可能になります。この統合機能は東京を含む１3のリージョンで利用可能です。詳細については ブログ をご確認ください。 AWS announces Amazon Aurora PostgreSQL zero-ETL integration with Amazon Redshift (Public Preview) AWS announces Amazon RDS for MySQL zero-ETL integration with Amazon Redshift (Public Preview) Amazon Aurora PostgreSQL互換とAmazon RDS for MySQLでAmazon RedshiftへのZero-ETL機能のプレビューが発表されました。複雑なデータ処理を作成・管理せずとも、AuroraやRDSに書き込まれたトランザクションデータが数秒内にRedshiftでも利用可能になります。Aurora PostgreSQLに関してはオハイオリージョンのAurora PostgreSQL 15.4で、RDS for MySQLは東京を含む5つのリージョンのMySQL バージョン 8.0.28以上でパブリックプレビューが可能です。詳細については Aurora 、 RDS 、 Redshift 各々のドキュメントをご確認ください。 Developer Tools Introducing an Integrated Development Environment (IDE) extension for AWS Application Composer AWS Toolkitの機能強化により、Application ComposerをVS Code経由で使えるようになりました。AWS Application ComposerのビジュアルキャンバスによるGUI経由での操作のほか、生成系AIによるコード提案も利用して効率的にAWSリソースの設計、開発を進めることができるようになります。あくまでもAWS Toolkitの機能なので こちら から入手可能です。詳細については ドキュメント と ブログ もご確認ください。 AWS AppConfig Agent launches write to disk, backups, and permission mapping AppConfig エージェントに新たな機能が追加がされました。AppConfigはアプリケーションの設定をAWS上で管理するサービスです。使い方の例を挙げると、新旧両方のプログラムを含むアプリケーションを事前にデプロイしておき、AppConfigの機能フラグで新旧どちらを使うか切り替える仕組みにしておくことで、資源のデプロイとアプリケーションのロールアウトのタイミングを安全に分けることを可能にする他、様々な使い方があるサービスです。AppConfigを使う際、ローカルでのキャッシュやポーリングの仕組みなど、面倒な実装をせずに使えるようにするのがAppConfig エージェントです。今回、AppConfig エージェントがローカルディスクへの機能フラグや構成データの書き込みに対応した他、最新バージョンの機能フラグをローカルバックアップし耐障害性を高める機能、ローカル環境でのテスト機能、IAMとの連携によるきめ細やかな権限管理の４つの機能が追加されました。詳細については App Config エージェント のドキュメントもご確認ください。 End User Computing Amazon WorkSpaces Multi-Region Resilience launches one-way data replication Amazon WorkSpaces Multi-Region Resilienceにリージョン間の一方向レプリケーション機能が追加されました。これまで、リージョン障害時にはstandby configuration機能によって迅速にセカンダリリージョンを利用できる仕組みがありましたが、今回の強化によって12時間毎のルート及びユーザボリュームを取得、使用できるようになります。今回の機能追加は、バージニア北部、オレゴン、フランクフルト、アイルランドなど、Multi-Region Resilienceが利用できるAWSリージョンで利用できます。詳細については ブログ や ドキュメント をご確認ください。 それでは、 Part 2 もお楽しみください。 ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

11月26日、IDE とコマンドライン用の AI 搭載生産性向上ツールである、 Amazon CodeWhisperer の人工知能 (AI) を活用したコード修復と Infrastructure as Code (IaC) サポートの一般提供開始が発表されました。また、Amazon CodeWhisperer が Visual Studio でもプレビュー版として利用できるようになりました。Amazon CodeWhisperer に対するこれらの新しい機能強化により、提携型の作業から解放され、顧客向けの自動化、セキュリティ、効率化、コード配信のスピードアップを実現することで、ソフトウェア開発をより迅速かつ効率的に行えるようになります。また、こうしたサポートがデベロッパーの望む環境で提供できるようになります。 AI を活用したコード修復 – Amazon CodeWhisperer は、発売以来、組み込みのセキュリティスキャンにより、見つけにくいセキュリティの脆弱性を特定してきました。現在では、特定されたセキュリティやコード品質の問題の修正に役立つ、生成系 AI を活用したコード提案が提供されています。組み込みのセキュリティスキャンは、漏えいした認証情報やログインジェクションなどの問題を検出するよう設計されています。生成系 AI を活用したコード提案は、特定された脆弱性を修正するよう設計されているほか、アプリケーションコードに合わせて調整されるため、ユーザーは自信を持って、迅速に修正を利用することができます。CodeWhisperer でセキュリティスキャンが完了すると、コード提案が表示されます。ユーザーはこれを使用するだけで、特定された脆弱性を迅速に修正できます。生成系 AI を活用したコード提案は、セキュリティ問題の対処プロセスをスピードアップします。それによって、ユーザーは正しいソリューションを見つけるために手動で 1 行ずつコードを確認する必要がなくなり、より価値の高い作業に集中できます。この機能を利用するために、Amazon CodeWhisperer で追加的なセットアップを行う必要はありません。 セキュリティスキャンはこれまでも Java、Python、および JavaScript で利用できましたが、今後は TypeScript、C#、AWS CloudFormation (YAML、JSON)、AWS CDK (TypeScript、Python)、および HashiCorp Terraform (HCL) でも利用できます。脆弱性を修復するためのコード提案は、現在 Java、Python、JavaScript で記述されたコードに対し提供されています。 Infrastructure as Code (IaC) – Amazon CodeWhisperer での IaC サポート開始が発表されました。今後、AWS CloudFormation (YAML、JSON)、AWS CDK (Typescript、Python)、および HashiCorp Terraform (HCL) がご利用いただけるようになります。この更新により、IaC スクリプト開発の効率が向上し、デベロッパーと DevOps チームがインフラストラクチャコードをシームレスに記述できるようになります。複数の IaC 言語をサポートすることで、CodeWhisperer は、多様なチーム間のコラボレーションと一貫性を促進します。これにより、クラウドインフラストラクチャの開発が大幅に進歩し、ユーザーはより合理的で生産的なコーディングエクスペリエンスを得られるようになります。 Visual Studio – Amazon CodeWhisperer が Visual Studio 2022 (プレビュー) で利用できるようになりました。デベロッパーは、C# のリアルタイムコード提案により、アプリケーションをより迅速に構築できます。AWS Toolkit 拡張機能をインストールし、 AWS ビルダー ID でサインインすることで、無料で個人利用枠の利用を開始できます。 また、CodeWhisperer は、公開されているコードに似ている可能性のあるコード提案にフラグを付けることで、デベロッパーが責任を持ってコーディングを行えるよう支援します。CodeWhisperer は、公開コードに似たコードの場合、リポジトリの URL とライセンスを提供します。 最後に、Amazon CodeWhisperer は最近 (11 月 20 日)、コマンドラインインターフェイス用の新たな時短機能のプレビューを開始しました。Amazon CodeWhisperer にて、Git、npm、AWS CLI、Docker など、多数の一般的な CLI 向けに先行入力コード補完とインラインドキュメント機能が追加されました。また、自然言語をシェルコードに変換する機能も追加されています。詳細については、「 Introducing Amazon CodeWhisperer for command line 」をご覧ください。 詳細はこちら Amazon CodeWhisperer 構築しましょう! – Irshad 原文は こちら です。

11月13日週は、なんと 160 を超える新サービスがリリースされました。たくさんの更新情報であふれかえっていたため、私たちは Weekly Roundup をもう一度投稿することにしました。 AWS re:Invent 2023 の開催が近づく中、11月13日週と同じペースでイノベーションが継続されています。 AWS のニュースブログチームでも、皆さんに記事を楽しんでもらうために、サービスチームによる素晴らしいリリースを紹介する re:Invent 関連の新しいブログ記事の仕上げに取りかかっています。Jeff Barr が、ブログ作成のジャーニーとプロセスを説明する The Road to AWS re:Invent 2023 を共有しています。11月20日週もどうぞお楽しみに! 11月13日週のリリース 11月13日週のリリースのうち、私の目に留まったものをいくつかご紹介します。 Amazon EC2 DL2q インスタンス – 新しい DL2q インスタンス には Qualcomm AI 100 Standard アクセラレータが搭載されており、パブリッククラウドで 最初に Qualcomm の AI テクノロジーを採用 したインスタンスです。8 台の Qualcomm AI 100 Standard アクセラレータと合計 128 GiB のアクセラレータメモリを備えた DL2q インスタンスでは、一般的な生成系人工知能 (AI) アプリケーションを実行して、スマートフォン、自動運転、パーソナルコンピューティング、そしてエクステンデッドリアリティヘッドセットにおよぶエッジデバイスに拡張し、これらの AI ワークロードを開発および検証してからデプロイすることが可能です。 Amazon Bedrock の PartyRock – AWS は、生成系 AI アプリを構築するための、Amazon Bedrock 駆動の直感的で実践的な楽しいプレイグラウンド環境、 PartyRock を導入しました。実験したり、プロンプトエンジニアリングについて学んだり、ミニアプリを構築したり、アプリを友達と共有したりすることができますが、コードを書いたり、AWS アカウントを作成したりする必要はありません。 また、Amazon Bedrock では Meta Llama 2 Chat 13B 基盤モデル に加えて、 Cohere Command Light、および Cohere Embed の English と Multilingual モデル へのアクセスも可能になりました。 6 周年を迎えた AWS Amplify – 新しい Amplify Documentation サイト、ホスティングおよび JavaScript ライブラリでの Next.js 14 のサポート、Amplify Auth へのカスタムトークンプロバイダーと自動 React Native ソーシャルサインイン更新の追加、新しい ChangePassword および DeleteUser アカウント設定コンポーネント、そして 新しい Amplify JavaScript v6 を使用するためのすべての Amplify UI パッケージの更新を含めた、 6 つの新しいリリース が発表されました。AWS Amplify ホスティングにデプロイされた Amplify アプリケーションでカスタムドメインを使用するときは、 ワイルドカードサブドメイン を使用することもできます。 この 1 週間で公開された主要リリースに関するその他のニュースブログ記事も、ぜひチェックしてください。 AWS Glue データカタログが Apache Iceberg テーブルの自動コンパクションをサポートするように 新着 – AWS Audit Manager が初のサードパーティー GRC 統合のサポートを開始 AWS Resource Explorer がマルチアカウント検索をサポート Amazon EBS スナップショットが、より優れたコンプライアンスのために個々のスナップショットのロックをサポート Amazon Polly が新しい長文読み上げエンジンによる 3 つの新しいボイスをサポート その他の AWS サービスのリリース 以下に、その他のバンドル機能のリリースを AWS サービス別にいくつかリストしました。 Amazon Athena – 新しいコストベースオプティマイザ (CBO) を使用して、AWS Glue データカタログと、ほぼすべての認証プラグインをサポートする新しい代替ドライバーである Athena JDBC 3.x ドライバー を用いて収集された 表統計と列統計 に基づくクエリパフォーマンスを強化することができます。また、 Amazon EMR Studio を使用 して、Amazon Athena でインタラクティブなクエリを開発し、実行することもできます。 Amazon CloudWatch – EBS Stalled I/O Check と呼ばれる新しい CloudWatch メトリクスを使用して、Amazon EBS ボリュームの正常性、関連するログイベントを検索して一致させるための Amazon CloudWatch Logs Live Tail フィルターパターン構文の 正規表現 、CloudWatch Application Insights での SAP Sybase ASE データベースのオブザーバビリティ 、および結果で集約を実行するための Log Insights クエリ内の 最大 2 つの stats コマンド を監視することができます。 Amazon CodeCatalyst – CodeCatalyst ワークフローからの Amazon Virtual Private Cloud (Amazon VPC) への接続、 CodeCatalyst ワークフロー内で Terraform を使用することによるインフラストラクチャのプロビジョニング、 IAM アイデンティティセンターで設定された Workforce アイデンティティ を使用した CodeCatalyst へのアクセス、および CodeCatalyst スペースのメンバーで構成された チームの作成 を実行することができます。 Amazon Connect – 事前構築されたキューパフォーマンスダッシュボード と、 Contact Lens 会話型分析ダッシュボード を使用して、リアルタイムの集約キューパフォーマンスと履歴的な集約キューパフォーマンスを表示し、比較することができます。「 /#greet 」を入力してパーソナライズされた応答を挿入するなどの事前に記述されたフォーマットによる チャットのクイックレスポンス や、マルウェアやその他の望ましくないコンテンツを検出するための 添付ファイルのスキャン を使用することも可能です。 AWS Glue – AWS Glue for Apache Spark が、Teradata、SAP HANA、Azure SQL、Azure Cosmos DB、Vertica、および MongoDB の 6 つの新しいデータベースコネクタ と、 Amazon OpenSearch Service へのネイティブ接続 を追加しました。 AWS Lambda – AWS Lambda コンソールで メトリクス、ログ、およびトレースのシングルペインビュー を表示するとともに、 高度なロギング設定制御 を使用して、ログを JSON 構造形式でネイティブにキャプチャすることができます。 Lambda コンソールで SAM テンプレートを表示 して、関数の設定を AWS Application Composer にエクスポートできます。AWS Lambda は、新しい Amazon Linux 2023 ランタイム上に構築された Java 21 バージョンと NodeJS 20 バージョンもサポートします。 米国テキサス州ダラスの AWS Local Zones – Amazon EC2 C6i、M6i、R6i、C6gn、M6g の各インスタンス、および gp2、gp3、io1、sc1、st1 の Amazon EBS ボリュームタイプで、 米国テキサス州ダラスの新しいローカルゾーン 、 us-east-1-dfw-2a を有効にすることができます。この新しいローカルゾーン内の Amazon ECS、Amazon EKS、Application Load Balancer、および AWS Direct Connect にアクセスして、エッジで幅広いワークロードをサポートすることもできます。 Amazon Managed Streaming for Apache Kafka (Amazon MSK) – AWS Identity and Access Management (IAM) を使用して Kafka リソースに対するアクセスコントロール を標準化し、あらゆるプログラミング言語で記述された Amazon MSK Serverless 向けの Kafka クライアント を構築することができます。これらは、 Java 、 Python 、 Go 、 JavaScript を含めた一般的な言語のための、オープンソースのクライアントヘルパーライブラリおよびコードサンプルです。また、Amazon MSK は Apache Kafka 3.6.0 の拡張バージョン のサポートも開始しました。このバージョンは、一般提供されている階層型ストレージを提供し、ストレージを使い果たしてしまうリスクが生じた場合には、 ストレージ容量アラート を自動的に送信します。 Amazon OpenSearch Service Ingestion – 最新バージョンの Amazon OpenSearch Service に Elasticsearch バージョン 7.x クラスターからのデータを移行 するとともに、受信データの耐久性を保護するための 永続的なバッファリング を使用することができます。 Amazon RDS – Amazon RDS for MySQL が、 Group Replication プラグイン を使用したアクティブ/アクティブ構成のクラスターの作成、 MySQL 5.7 スナップショットから MySQL 8.0 へのアップグレード、および MySQL 8.1 の Innovation Release バージョン をサポートするようになりました。 Amazon RDS Custom for SQL Server は、最大 1,000 台のデータベースに ポイントインタイムリカバリのサポート を拡張し、透過的データ暗号化 (TDE)、表および列レベルでの暗号化、DBMail およびリンクされたサーバーを使用するための サービスマスターキーの保持 をサポートするとともに、Bring Your Own Media (BYOM) 機能を用いて SQL Server Developer Edition を使用します。 さらに、2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ 配置は、Amazon RDS Proxy の使用時に、通常 1 秒未満のダウンタイムでの マイナーバージョンアップグレードとシステムメンテナンス更新 をサポートするようになりました。 AWS パートナーセントラル – AWS パートナーセントラルの 改善されたユーザーエクスペリエンス を使用して製品の構築と宣伝を行い、Partner Analytics Dashboard にある 新しい投資タブ で実用的なインサイトを入手することができます。パートナーセントラルと AWS Marketplace 間で アカウントと関連するユーザーをリンク し、APN カスタマーエンゲージメント (ACE) マネージャーとの 強化された共同販売エクスペリエンス を利用できるようになりました。 Amazon QuickSight – ユーザーアクセスのプログラム的な管理 と、 ロールに対するカスタム許可のサポート により、API を使用して IAM アイデンティティセンターと Active Directory の QuickSight アカウントに QuickSight 機能を制限できるようになりました。また、 共有された制限付きフォルダ 、コントリビューターロール、フォルダ内でのデータソースアセットタイプのサポート、および多種多様な業界と社会的コンテキスト全体のお客様のデータ分析エクスペリエンスを向上させるために設計された追加機能である、 週のカスタム開始日 機能も使用できます。 AWS Trusted Advisor – 新しい API を使用して Trusted Advisor のベストプラクティスチェック、推奨事項、および優先順位付けされた推奨事項にプログラム的にアクセスするとともに、DB インスタンスの設定、使用状況、およびパフォーマンスデータを分析することによってベストプラクティスガイダンスを提供する 37 の新しい Amazon RDS チェック を使用することができます。 このブログで取り上げなかったリリースニュースもたくさんあります。詳細については、「 AWS の最新情報 」を参照してください。 AWS re:Invent でバーチャルにお会いしましょう 来週、私たちは米国ラスベガスで AWS の最新情報を聞き、エキスパートから学び、グローバルクラウドコミュニティとつながります。re:Invent に参加する場合は、出発前に アジェンダ 、 セッションカタログ 、および 参加者ガイド を確認してください。 今年の re: Invent に直接参加できない場合のために、AWS では 基調講演とイノベーショントークをライブストリーミングする オプションもご用意しています。 オンラインパスに登録 することで、イベント後にオンデマンドの基調講演、イノベーショントーク、および厳選されたブレイクアウトセッションにアクセスできます。 – Channy 原文は こちら です。

データサイエンティストやアプリケーション開発者が大量のグラフデータを迅速に分析できるようにする新しい分析データベースエンジン、 Amazon Neptune Analytics の一般提供を開始しました。Amazon Neptune Analyticsを使えば、 Amazon Neptune または Amazon Simple Storage Service (Amazon S3) 上のデータレイクからデータセットを素早くロードし、ほぼリアルタイムで分析タスクを実行することができます。 グラフデータは、多様なデータ領域内の複雑な関係やつながりを表現し、分析することを可能にします。一般的なアプリケーションとしては、ソーシャルネットワークがあり、コミュニティの特定、つながりの推奨、情報拡散の分析に役立ちます。サプライチェーン管理では、グラフは効率的なルート最適化やボトルネックの特定を容易にします。サイバーセキュリティでは、ネットワークの脆弱性を明らかにし、悪意のある活動のパターンを特定します。グラフデータはナレッジマネジメント、金融サービス、デジタル広告、ネットワークセキュリティに応用され、銀行取引におけるマネーロンダリングネットワークの特定やネットワークの脆弱性の予測などのタスクを実行します。 2018年5月にAmazon Neptuneのサービスが開始 してから、何千ものお客様が、グラフデータを保存し、グラフの特定のサブセットを更新および削除するサービスを採用しています。しかし、洞察を得るためにデータを分析するには、多くの場合、グラフ全体をメモリに読み込む必要があります。たとえば、不正行為の検出を目的とする金融サービス会社では、過去の口座取引をすべて読み込んで関連付ける必要がある場合があります。 一般的なグラフアルゴリズムの実行など、広範なグラフデータセットの分析を行うには、専用のツールが必要です。個別の分析ソリューションを利用するには、処理対象のデータを転送するための複雑なパイプラインを構築する必要がありますが、これは操作が難しく、時間がかかり、エラーも発生しやすくなります。さらに、既存のデータベースやデータレイクからグラフ分析ソリューションに大規模なデータセットを読み込むには、数時間から数日かかることもあります。 Amazon Neptune Analytics は、フルマネージド型のグラフ分析エクスペリエンスを提供します。インフラストラクチャの面倒な作業を処理してくれるため、お客様はクエリやワークフローなどの課題の解決に集中できます。Amazon Neptune Analytics は、グラフのサイズに応じてコンピューティングリソースを自動的に割り当て、すべてのデータをメモリにすばやく読み込んで、クエリを数秒で実行します。最初のベンチマークでは、Neptune Analytics が既存のAWSソリューションよりも最大80倍高速にAmazon S3 からデータをロードできていることがわかりました。 Neptune Analytics は、15種類のアルゴリズムに対応する5種類のアルゴリズムファミリーをサポートしています。 それぞれに複数のバリエーションがあります。たとえば、Pathfinding(経路探索)、クラスタリング、重要なデータの特定 (中心性)、類似性の定量化のためのアルゴリズムを提供しています。 Pathfinding(経路探索)アルゴリズム は、サプライチェーン最適化のためのルートプランニングなどのユースケースに使用されます。 ページランク などの 中心性アルゴリズム は、最も影響力のある売り手をグラフで特定します。 連結成分 , クラスタリング 、類似性アルゴリズムなどのアルゴリズムを不正検出のユースケースに使用して、接続されたネットワークが友人のグループなのか、あるいは連携した詐欺師の集まりによって形成された詐欺の輪（Fraud Ring）なのかを判断できます。 Amazon Neptune Analytics は、以下を使用してグラフアプリケーションの作成を容易にします。 openCypher は現在広く採用されているグラフクエリ言語の1つです。開発者、ビジネスアナリスト、データサイエンティストは、openCypherのSQLに着想を得た構文を高く評価しています。グラフクエリを作成するのに馴染みがあり構造化されているからです。 Amazon Neptune Analyticsの利用開始手順 AWS News Blogでいつも行っているように、その手順をお見せしましょう。このデモでは、 AWS Management Console から、まず Neptune に移動します。 左側のナビゲーションペインの「 Analytics 」セクションから「 Graph 」を選択します。 それから 「 Create graph 」を選択します。 グラフの作成ページで、グラフ解析データベースエンジンの詳細情報を入力します。 各パラメータの詳細はここでは割愛します。 ほとんどの場合、セキュリティの観点から、グラフはVPCの境界からのみ利用できるようにすることがほとんどです。パブリックアクセスを許可しないようにしてください。また、アカウントVPCネットワーク内のマシンやサービスからのプライベートアクセスを許可するために、Privateエンドポイントも作成します。 ネットワーク・アクセス・コントロールに加え、ユーザーがグラフにアクセスするには適切なIAMパーミッションが必要です。 最後に、ベクトル検索を有効にして、データセット内の埋め込みを使った類似性検索を実行します。ベクトルの次元は、埋め込みを生成するために使用する大規模言語モデル（LLM）などに依存します。 準備ができたら、グラフの作成を選択します。数分後、グラフが表示されるはずです。 その後「 Connectivity &amp; security 」の「 Endpoint 」を確認してください。これは後でアプリケーションからグラフにアクセスするときに使う時のDNS名となります。 補足ですが、レプリカを作成することもできます。レプリカは、別のアベイラビリティ・ゾーンにあるグラフのウォーム・スタンバイ・コピーです。高可用性を実現するために、1つまたは複数のレプリカを作成することもできます。デフォルトではレプリカを1つ作成しますが、可用性の要件によってはレプリカを作成しないこともできます。 グラフデータに対するビジネスクエリ Amazon Neptune Analytics グラフが利用できるようになったので、データをロードして分析してみよう。このデモでは、あなたが金融業界で働いていると想像してください。 米国証券取引委員会（SEC） から入手したデータセットがあります。このデータセットには、資産1億ドル以上の投資家が保有するポジションのリストが含まれています。以下は、このデモで使用するデータセットの構造を説明するための図です。 ある投資会社（仮に “Seb’s Investments LLC “とします）の保有ポジションをもっとよく理解したいとします。上位5社の保有銘柄は何か、同じ会社で10億ドル以上を保有している会社は他にあるか。また、Seb’s Investments LLCと同じようなポートフォリオを持つ投資会社が他にあるのか知る必要があるとします。 分析を始めるために、 AWS Management Console の NeptuneセクションでJupyterノートブックを作成 します。ノートブックでは、まず分析エンドポイントを定義し、S3バケットからデータセットをロードします。1,700万レコードをロードするのに18秒しかかかりません。 それから、openCypherのクエリを使ってデータセットを探索します。まずはパラメータを定義します。 params = {'name': "Seb's Investments LLC", 'quarter': '2023Q4'} まず、Seb’s Investments LLCの今四半期の持ち株上位5銘柄と、同じ会社で10億ドル以上を保有している他に彼かを知る必要があります。openCypherでは、以下のクエリで記述します。 $name パラメータの値は “Seb’s Investment LLC”、 $quarter パラメータの値は “2023Q4 “です。 MATCH p=(h:Holder)--&gt;(hq1)-[o:owns]-&gt;(holding) WHERE h.name = $name AND hq1.name = $quarter WITH DISTINCT holding as holding, o ORDER BY o.value DESC LIMIT 5 MATCH (holding)&lt;-[o2:owns]-(hq2)&lt;--(coholder:Holder) WHERE hq2.name = '2023Q4' WITH sum(o2.value) AS totalValue, coholder, holding WHERE totalValue &gt; 1000000000 RETURN coholder.name, collect(holding.name) 次に、”Seb’s Investments LLC “と同じような持ち株を持つ他の上位5社を知りたいです。 topKByNode() 関数を使用してベクトル検索を実行します。 MATCH (n:Holder) WHERE n.name = $name CALL neptune.algo.vectors.topKByNode(n) YIELD node, score WHERE score &gt;0 RETURN node.name LIMIT 5 このクエリは、”Seb’s Investments LLC “という名前の特定のHolderノードを識別します。次に、Amazon Neptune Analytics のカスタムしたベクトル類似性検索アルゴリズムを、Holderノードの埋め込みプロパティに利用し、グラフ内の類似する他のノードを検索します。結果は、正の類似性スコアを持つものだけを含むようにフィルタリングされ、クエリは最終的に最大5つの関連するノードの名前を返します。 利用リージョンと価格 Amazon Neptune Analyticsは、2023年11月30日より、米国東部（オハイオ州、バージニア州）、米国西部（オレゴン州）、アジア太平洋地域（シンガポール、東京）、欧州（フランクフルト、アイルランド）の7つのAWSリージョンでご利用いただけます。 利用料金は従量制で、定期的なサブスクリプションや1回限りのセットアップ料金は発生しません。 Amazon Neptune Analyticsの価格は、メモリに最適化されたNeptuneキャパシティ・ユニット（m-NCU）の構成に基づきます。各m-NCUは、1時間の計算およびネットワーク容量と1GiBのメモリに相当します。128m-NCUから始まり、最大4096m-NCUまでの構成を選択できます。m-NCUに加えて、グラフ・スナップショットにはストレージ料金がかかります。 詳しくは、 Amazon Neptune の価格ページ をご覧ください。 Amazon Neptune Analyticsは、大規模なグラフデータセットを分析するための新しい分析データベースエンジンです。不正検知・防止、デジタル広告、サイバーセキュリティ、輸送ロジスティクス、バイオインフォマティクスなどのユースケースにおいて、深い洞察をより迅速に発見することができます。 Amazon Neptune Analyticsを今すぐ使ってみよう AWS Management Console にログインして、Amazon Neptune Analyticsを是非試してみてください。 著者について Sébastien Stormacq Sebは、80年代半ばに初めてCommodore 64に触れて以来、コードを書き続けています。彼は、情熱、熱意、顧客志向、好奇心、創造性を駆使して、AWSクラウドの価値を引き出すためにビルダーを鼓舞します。ソフトウェア・アーキテクチャ、開発者ツール、モバイル・コンピューティングに興味があります。 本記事は 2023/11/30に投稿された Analyze large amounts of graph data to get insights and find trends with Amazon Neptune Analytics を翻訳した記事です。翻訳はソリューションアーキテクトの木村 達也が行いました。

運用データの操作を容易にするために、 Amazon CloudWatch は11月26日、Logs および Metrics Insights 用の自然言語クエリ生成を導入します。 生成系人工知能 (AI) を活用したこの機能を使用すると、求めているインサイトの説明を英語で記述でき、Logs または Metrics Insights のクエリが自動的に生成されます。 この機能は、CloudWatch Logs と Metrics Insights 用に 3 つの主要な機能を提供します。 簡単に開始するのに役立つよう、説明または質問から新しいクエリを生成します。 より高度な機能を含む言語の学習に役立つクエリの説明。 ガイド付きのイテレーションを使用して既存のクエリを改良します。 いくつかの例を使用して、これらが実際にどのように機能するかを見てみましょう。最初にログについて説明し、その後にメトリクスについて説明します。 自然言語を使用して CloudWatch Logs Insights クエリを生成する CloudWatch コンソール の [ログ] セクションで、 [Log Insights] を選択します。その後、調査する AWS Lambda 関数のロググループを選択します。 [クエリジェネレーター] ボタンを選択して、新しい [プロンプト] フィールドを開き、自然言語を使用して必要な情報を入力します。 Tell me the duration of the 10 slowest invocations その後、 [新しいクエリを生成] を選択します。次の Log Insights クエリが自動的に生成されます。 fields @timestamp, @requestId, @message, @logStream, @duration | filter @type = "REPORT" and @duration &gt; 1000 | sort @duration desc | limit 10 [クエリを実行] を選択して結果を確認します。 出力に含まれる情報が多すぎることがわかりました。必要なデータのみを表示したいので、 [プロンプト] に次の文を入力し、 [クエリを更新] を選択します。 Show only timestamps and latency クエリは入力に基づいて更新され、タイムスタンプと期間のみが返されます。 fields @timestamp, @duration | filter @type = "REPORT" and @duration &gt; 1000 | sort @duration desc | limit 10 更新されたクエリを実行すると、読みやすい結果を得ることができました。 次に、ログにエラーが含まれているかどうかを確認したいと思います。次の文を [プロンプト] に入力し、新しいクエリを生成します。 Count the number of ERROR messages リクエストに応じて、生成されたクエリは、 ERROR 文字列を含むメッセージをカウントします。 fields @message | filter @message like /ERROR/ | stats count() クエリを実行すると、想定よりも多くのエラーがあることがわかりました。さらに詳しい情報が必要です。 このプロンプトを使用してクエリを更新し、エラーをより適切に分散させます。 Show the errors per hour 更新されたクエリは、 bin() 関数を使用して、結果を 1 時間ごとの間隔でグループ化します。 fields @timestamp, @message | filter @message like /ERROR/ | stats count(*) by bin(1h) メモリの使用状況に関するより高度なクエリを見てみましょう。いくつかの Lambda 関数のロググループを選択し、次のように入力します。 Show invocations with the most over-provisioned memory grouped by log stream クエリを生成する前に、歯車アイコンを選択して、プロンプトと説明をコメントとして含めるオプションを切り替えてオンにします。結果は次のとおりです (読みやすくするために説明を複数行に分割しています)。 # 最も過剰にプロビジョニングされたメモリを持つ呼び出しを、ログストリームごとにグループ化して表示します fields @logStream, @memorySize/1000/1000 as memoryMB, @maxMemoryUsed/1000/1000 as maxMemoryUsedMB, (@memorySize/1000/1000 - @maxMemoryUsed/1000/1000) as overProvisionedMB | stats max(overProvisionedMB) as maxOverProvisionedMB by @logStream | sort maxOverProvisionedMB desc # このクエリは、プロビジョニングされたメモリと使用された最大メモリの差を計算することにより、 # 各ログストリームについて、過剰にプロビジョニングされたメモリの量を検索します。 # その後、結果をログストリームごとにグループ化し、各ログストリームについて、 # 過剰にプロビジョニングされた最大メモリを計算します。最後に、 # 過剰にプロビジョニングされた最大メモリで降順に結果を並べ替えて、 # 最も過剰にプロビジョニングされたメモリを含むログストリームを表示します。 これで、これらのエラーを理解するために必要な情報が得られました。一方で、EC2 ワークロードもあります。それらのインスタンスはどのように実行されているのでしょうか? いくつかのメトリクスを見てみましょう。 自然言語を使用して CloudWatch Metrics Insights クエリを生成する CloudWatch コンソール の [メトリクス] セクションで、 [すべてのメトリクス] を選択します。その後、 [クエリ] タブで、 [エディタ] を使用します。必要に応じて、 [クエリジェネレーター] を [ビルダー] でも使用できます。 先ほどと同様に、 [クエリジェネレーター] を選択します。その後、平易な英語を使用して必要な情報を入力します。 Which 10 EC2 instances have the highest CPU utilization? [新しいクエリを生成] を選択し、Metrics Insights 構文を使用して結果を取得します。 SELECT AVG("CPUUtilization") FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY InstanceId ORDER BY AVG() DESC LIMIT 10 グラフを表示するには、 [実行] を選択します。 私の EC2 インスタンスはあまり稼働していないようですね。この結果は、それらのインスタンスが CPU をどのように使用しているかを示していますが、ストレージはどうでしょうか? プロンプトに次の文を入力し、 [クエリを更新] を選択します。 How about the most EBS writes? 更新されたクエリは、平均 CPU 使用率を、インスタンスにアタッチされているすべての EBS ボリュームに書き込まれたバイトの合計に置き換えます。上位 10 件の結果のみを表示するという制限は維持されます。 SELECT SUM("EBSWriteBytes") FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY InstanceId ORDER BY SUM() DESC LIMIT 10 クエリを実行し、その結果を確認することで、EC2 インスタンスによってストレージがどのように使用されているかをより良く理解できます。 いくつかのリクエストを入力し、生成されたクエリをログとメトリクスに対して実行して、これがお客様のデータでどのように機能するかをぜひご確認ください。 留意点 Amazon CloudWatch のログとメトリクス用の自然言語クエリ生成は、米国東部 (バージニア北部) と米国西部 (オレゴン) AWS リージョン でプレビューでご利用いただけます。 プレビュー中における自然言語クエリ生成の利用に追加料金はかかりません。お支払いいただくのは、 CloudWatch の料金 に従って、クエリの実行コストのみです。 生成されるクエリは生成系 AI によって生成され、アカウントで選択される利用可能なデータなどの要因に依拠します。これらの理由により、結果は異なる場合があります。 クエリを生成する際、元のリクエストとクエリの説明をコメントとして含めることができます。これを実行するには、クエリ編集ウィンドウの右下にある歯車アイコンを選択し、それらのオプションを切り替えてオンにします。 この新しい機能は、ログとメトリクス用のクエリの生成と更新に役立ち、時間と労力を節約できます。このアプローチにより、エンジニアリングチームは、特定のデータに関する知識やクエリに関する専門知識について心配することなく、業務を拡張できます。 自然言語を使用して、Amazon CloudWatch でログとメトリクスを分析しましょう。 – Danilo 原文は こちら です。

テキスト検索と セマンティック検索 エンジンの台頭により、eコマースや小売業は消費者にとってより簡単に検索できるようになりました。検索する際にテキストと画像の両方をクエリに含むことができる検索エンジンは、検索ソリューションの柔軟性を非常に高めることができます。たとえば、ラップトップに何百もの家族の写真が入ったフォルダがあり、あなたとあなたの親友が古い家のプールの前にいたときに撮った写真をすぐに見つけたいという場合を仮定します。この場合、「プールの前に二人が立っている」のような会話形式の文章をクエリとして入力することで、テキストと画像の統合検索エンジンからお目当ての画像を検索することができます。画像タイトルに適切なキーワードを入力しなくても、クエリを実行できます。 現在、 Amazon OpenSearch Service は k-NN インデックスの コサイン類似度 メトリクスをサポートしています。コサイン類似度は、2 つのベクトル間の角度のコサインを測定します。コサイン角度が小さいほど、ベクトル間の類似性が高くなります。コサイン類似度を使用すると、2 つのベクトル間の向きを測定できるため、特定のセマンティック検索アプリケーションに適しています。 Contrastive Language-Image Pre-Training (CLIP) は、さまざまな画像とテキストのペアでトレーニングされたニューラルネットワークです。CLIP ニューラルネットワークは、画像とテキストの両方を同じ 潜在空間 に投影できるため、コサイン類似度などの類似度尺度を使用して画像とテキストを比較することができます。CLIP を使用して製品の画像や説明を Embedding に エンコード し、OpenSearch Service k-NN インデックスに保存することができます。そうすれば、顧客はインデックスをクエリして、関心のある商品を検索できます。 Amazon SageMaker を用いることで、上記の CLIP をエンコーディングさせるために利用することができます。 Amazon SageMaker Serverless Inference は、機械学習 (ML) モデルのデプロイとスケーリングを容易にする専用の推論サービスです。SageMaker を使用すると、開発とテスト用にサーバーレスをデプロイし、本番環境では リアルタイム推論 に移行することも可能です。Amazon SageMaker Serveless Inference では、アイドル時にインフラストラクチャを 0 にスケールダウンすることでコストを節約できます。これは、開発サイクル間のアイドル時間が長い POC を構築する場合に最適です。この他、 Amazon SageMaker Batch transform を使用して、大規模なデータセットから推論を取得することもできます。 この記事では、SageMakerとOpenSearch ServiceでCLIPを使用して検索アプリケーションを構築する方法を示します。コードはオープンソースで、 こちらのGitHub でホストされています。 ソリューション概要 Amazon OpenSearch Service は、テキストマッチングとEmbedding k-NN 検索を提供します。このソリューションでは Embedding k-NN 検索を利用します。画像とテキストの両方をクエリとして使用して、インベントリからアイテムを検索できます。この統合画像およびテキスト検索アプリケーションの実装は、次の 2 つのフェーズで構成されます。 k-NN 参照インデックス — このフェーズでは、一連のコーパスドキュメントまたは製品画像をCLIPモデルに渡して、それらを Embedding にエンコードします。テキストと画像の Embedding は、それぞれコーパスまたは画像の数値表現を表します。これらの Embedding を OpenSearch Service の k-NN インデックスに保存します。k-NNを支える概念は、Embedding 空間に類似したデータポイントが近接して存在するというものです。たとえば、「赤い花」、「バラ」といったテキストと赤いバラの画像は似ているため、これらのテキストと画像の Embedding は Embedding 空間内で互いに近接しています。 k-NN インデックスクエリ — これはアプリケーションの推論フェーズです。このフェーズでは、ディープラーニングモデル (CLIP) を介してテキスト検索クエリまたは画像検索クエリを送信し、Embedding にエンコードします。次に、それらの Embedding を使用して、OpenSearch Service に保存されている参照 k-NN インデックスをクエリします。k-NN インデックスは、emnbedding 空間から同様の Embedding を返します。たとえば、「赤い花」のテキストを渡すと、赤いバラの画像の Embedding が類似のアイテムとして返されます。 以下の画像はソリューションのアーキテクチャ図です。 以下がワークフローとなります。 事前学習済みの CLIP モデルからバッチ推論とリアルタイム推論用の SageMaker モデル をデプロイします。 SageMaker batch transform ジョブを使用して製品画像の Embedding を生成します。 SageMaker Serverless Inference を使用して、クエリ画像とテキストを Embedding へリアルタイムにエンコードします。 Amazon Simple Storage Service (Amazon S3) を使用して、未加工のテキスト (製品説明) と画像 (製品画像)、および SageMaker batch transform ジョブによって生成された画像の Embedding を保存します。 OpenSearch Service を検索エンジンとして使用して、Embeddingを保存し、類似のEmbeddingを検索します。 クエリ関数を使用してクエリのエンコーディングを調整し、k-NN 検索を実行します。 このソリューションを開発するための統合開発環境 (IDE) として、Amazon SageMaker Studio Notebooks を使用しています（アーキテクチャ図には示されていません） 。 ソリューションのセットアップ ソリューションをセットアップするには、次の手順を実行します。 SageMaker ドメインとユーザープロファイルを作成します。手順については、「 クイックセットアップを使用して Amazon SageMaker ドメインにオンボーディングする 」を参照してください。 OpenSearch Service ドメインを作成します。手順については、「 Amazon OpenSearch サービスドメインの作成と管理 」を参照してください。 上記の手順以外にも、 GitHub の記載内容 に従い AWS CloudFormation テンプレートを使用してドメインを作成することも可能です。現状このテンプレートではインターネット経由で接続する形になっていますが、VPC のインターフェイスエンドポイントを使用して、Amazon 仮想プライベートクラウド (Amazon VPC) から SageMaker Studio を Amazon S3 に接続することが可能です。VPC エンドポイント (インターフェイスエンドポイント) を使用することで、VPC と SageMaker Studio 間の通信は AWS ネットワーク内で完全かつ安全に行われます。SageMaker Studio Notebookは、プライベート VPC 経由で OpenSearch Serviceに接続できるため、通信のセキュリティが確保されます。OpenSearch Service ドメインは、保存中のデータを暗号化します。これは、データへの不正アクセスを防ぐのに役立つセキュリティ機能です。ノード間暗号化は、OpenSearch Service のデフォルト機能に加えてセキュリティをさらに強化します。Amazon S3 は、別の暗号化オプションを指定しない限り、新しいオブジェクトごとにサーバー側の暗号化 (SSE-S3) を自動的に適用します。 OpenSearch Service ドメインでは、アイデンティティベースのポリシーをアタッチして、サービスにアクセスできるユーザー、実行できるアクション、および該当する場合はそれらのアクションを実行できるリソースを定義できます。 イメージとテキストのペアを Embedding にエンコードする このセクションでは、画像とテキストを埋め込みにエンコードする方法について説明します。ここでは、データの準備、SageMaker でのモデルの作成、およびモデルを使用した Batch Transformの実行が含まれます。 （訳者追記：本記事にかかれているコードの内容はすべてこちらの GitHub リポジトリ の blog_clip.ipynb に記載されています。SageMaker Studio にGit リポジトリをクローンする方法については こちらのドキュメント を参照してください。 ） データの概要と準備方法 Python 3 (データサイエンス) カーネルを搭載した SageMaker Studio ノートブックを使用してサンプルコードを実行できます。 この記事では、 Amazon Berkeley Object Dataset を使用します。このデータセットは、多言語メタデータと 398,212 枚のユニークなカタログ画像を含む 147,702 個の製品リストのコレクションです。商品の画像と商品名は US 英語でのみ使用しています。デモ用には、約 1,600 個の製品を使用しています。このデータセットの詳細については、 README を参照してください。データセットは外部公開されているパブリックな S3 バケットでホストされています。Amazon商品の商品説明とメタデータを含む16個のファイルのフォーマットは listings/metadata/listings_&lt;i&gt;.json.gz となっています。 このデモでは、最初のメタデータファイルを使用します。 Pandas を使用してメタデータを読み込み、データフレームから US 英語のタイトルを含む製品を選択します。Pandasは、Pythonプログラミング言語上に構築されたオープンソースのデータ分析および操作ツールです。 main_image_id という属性を使用してイメージを識別します。次のコードを参照してください。 meta = pd.read_json("s3://amazon-berkeley-objects/listings/metadata/listings_0.json.gz", lines=True) def func_(x): us_texts = [item["value"] for item in x if item["language_tag"] == "en_US"] return us_texts[0] if us_texts else None meta = meta.assign(item_name_in_en_us=meta.item_name.apply(func_)) meta = meta[~meta.item_name_in_en_us.isna()][["item_id", "item_name_in_en_us", "main_image_id"]] print(f"#products with US English title: {len(meta)}") meta.head() データフレームには 1,639 個の製品があります。次に、アイテム名と画像を結合させます。 images/metadata/images.csv.gz には画像のメタデータが含まれています。このファイルは gzip で圧縮された CSV ファイルで、 image_id , height , width , path 列があります。メタデータファイルを読み込んで、それをアイテムメタデータと結合してみましょう。次のコードを参照してください。 image_meta = pd.read_csv("s3://amazon-berkeley-objects/images/metadata/images.csv.gz") dataset = meta.merge(image_meta, left_on="main_image_id", right_on="image_id") dataset.head() SageMaker Studio Notebook の Python 3 カーネルに組み込まれている PIL library を使用して、データセットのサンプル画像を表示してみましょう。 from sagemaker.s3 import S3Downloader as s3down from pathlib import Path from PIL import Image def get_image_from_item_id(item_id = "B0896LJNLH", return_image=True): s3_data_root = "s3://amazon-berkeley-objects/images/small/" item_idx = dataset.query(f"item_id == '{item_id}'").index[0] s3_path = dataset.iloc[item_idx].path local_data_root = f'./data/images' local_file_name = Path(s3_path).name s3down.download(f'{s3_data_root}{s3_path}', local_data_root) local_image_path = f"{local_data_root}/{local_file_name}" if return_image: img = Image.open(local_image_path) return img, dataset.iloc[item_idx].item_name_in_en_us else: return local_image_path, dataset.iloc[item_idx].item_name_in_en_us image, item_name = get_image_from_item_id() print(item_name) image モデルの準備 次に、事前学習済みの CLIP モデルから SageMaker で推論用にモデルをデプロイ します。最初のステップは、事前学習済みのモデルの重みファイルをダウンロードして model.tar.gz ファイルに入れ、S3 バケットにアップロードすることです。事前学習済みモデルのパスは CLIP リポジトリ にあります。このデモでは、事前学習済みの ResNet-50 (RN50) モデルを使用します。次のコードを参照してください。 %%writefile build_model_tar.sh #!/bin/bash MODEL_NAME=RN50.pt MODEL_NAME_URL=https://openaipublic.azureedge.net/clip/models/afeb0e10f9e5a86da6080e35cf09123aca3b358a0c3e3b6c78a7b63bc04b6762/RN50.pt BUILD_ROOT=/tmp/model_path S3_PATH=s3:////model.tar.gz rm -rf $BUILD_ROOT mkdir $BUILD_ROOT cd $BUILD_ROOT &amp;&amp; curl -o $BUILD_ROOT/$MODEL_NAME $MODEL_NAME_URL cd $BUILD_ROOT &amp;&amp; tar -czvf model.tar.gz . aws s3 cp $BUILD_ROOT/model.tar.gz $S3_PATH !bash build_model_tar.sh その後、推論の entry point として指定する CLIP モデルのスクリプトを提供する必要があります。 CLIP は PyTorch を使って実装されているため、 SageMaker PyTorch Framework を使用します。 PyTorch はオープンソースの ML フレームワークで、研究プロトタイピングから本番デプロイまでのパスを加速させます。 SageMaker で PyTorch モデルをデプロイする方法については、 Deploy PyTorch Models を参照してください。 推論コードは、 MODEL_NAME と ENCODE_TYPE の2つの環境変数を受け入れます。 これにより、異なる CLIP モデルを簡単に切り替えることができます。 ENCODE_TYPE を使用して、イメージまたはテキストのどちらをエンコードするかを指定します。ここでは、 デフォルトの PyTorch 推論ハンドラ をオーバーライドするために、 model_fn 、 input_fn 、 predict_fn 、 output_fn 関数を実装します。 次のコードを参照してください: !mkdir -p code %%writefile code/clip_inference.py import io import torch import clip from PIL import Image import json import logging import sys import os import torch import torch.nn as nn import torch.nn.functional as F from torchvision.transforms import ToTensor logger = logging.getLogger(__name__) logger.setLevel(logging.DEBUG) logger.addHandler(logging.StreamHandler(sys.stdout)) MODEL_NAME = os.environ.get("MODEL_NAME", "RN50.pt") # ENCODE_TYPE could be IMAGE or TEXT ENCODE_TYPE = os.environ.get("ENCODE_TYPE", "TEXT") device = torch.device("cuda" if torch.cuda.is_available() else "cpu") # defining model and loading weights to it. def model_fn(model_dir): model, preprocess = clip.load(os.path.join(model_dir, MODEL_NAME), device=device) return {"model_obj": model, "preprocess_fn": preprocess} def load_from_bytearray(request_body): return image # data loading def input_fn(request_body, request_content_type): assert request_content_type in ( "application/json", "application/x-image", ), f"{request_content_type} is an unknown type." if request_content_type == "application/json": data = json.loads(request_body)["inputs"] elif request_content_type == "application/x-image": image_as_bytes = io.BytesIO(request_body) data = Image.open(image_as_bytes) return data # inference def predict_fn(input_object, model): model_obj = model["model_obj"] # for image preprocessing preprocess_fn = model["preprocess_fn"] assert ENCODE_TYPE in ("TEXT", "IMAGE"), f"{ENCODE_TYPE} is an unknown encode type." # preprocessing if ENCODE_TYPE == "TEXT": input_ = clip.tokenize(input_object).to(device) elif ENCODE_TYPE == "IMAGE": input_ = preprocess_fn(input_object).unsqueeze(0).to(device) # inference with torch.no_grad(): if ENCODE_TYPE == "TEXT": prediction = model_obj.encode_text(input_) elif ENCODE_TYPE == "IMAGE": prediction = model_obj.encode_image(input_) return prediction # Serialize the prediction result into the desired response content type def output_fn(predictions, content_type): assert content_type == "application/json" res = predictions.cpu().numpy().tolist() return json.dumps(res) このソリューションでは、モデルの推論時に追加の Python パッケージが必要です。そのため、SageMaker がモデルをホスティングする際に追加のパッケージをインストールできるように、 requirements.txt ファイルを提供することができます。 %%writefile code/requirements.txt ftfy regex tqdm git+https://github.com/openai/CLIP.git PyTorchModel クラス を使用すると、モデル成果物のAmazon S3 の場所と推論エントリポイントの詳細を含むオブジェクトを作成できます。このオブジェクトを使用して、Batch Transform ジョブを作成したり、エンドポイントにデプロイしてオンライン推論を行うことができます。以下のコードを参照してください: from sagemaker.pytorch import PyTorchModel from sagemaker import get_execution_role, Session role = get_execution_role() shared_params = dict( entry_point="clip_inference.py", source_dir="code", role=role, model_data="s3://&lt;your-bucket&gt;/&lt;your-prefix-for-model&gt;/model.tar.gz", framework_version="1.9.0", py_version="py38", ) clip_image_model = PyTorchModel( env={'MODEL_NAME': 'RN50.pt', "ENCODE_TYPE": "IMAGE"}, name="clip-image-model", **shared_params ) clip_text_model = PyTorchModel( env={'MODEL_NAME': 'RN50.pt', "ENCODE_TYPE": "TEXT"}, name="clip-text-model", **shared_params ) アイテム画像を Embeding にエンコードするための Batch Transform を実行する 次に、CLIP モデルを使用して、アイテム画像を Embedding にエンコードし、SageMaker Batch Transformを使用してバッチ推論を実行します。 ジョブを作成する前に、以下のコードスニペットを使用して、Amazon Berkeley Objects Dataset のパブリック S3 バケットからアイテム画像を自分のバケットにコピーします。この操作は10分未満で終了します。 from multiprocessing.pool import ThreadPool import boto3 from tqdm import tqdm from urllib.parse import urlparse s3_sample_image_root = "s3://&lt;your-bucket&gt;/&lt;your-prefix-for-sample-images&gt;" s3_data_root = "s3://amazon-berkeley-objects/images/small/" client = boto3.client('s3') def upload_(args): client.copy_object(CopySource=args["source"], Bucket=args["target_bucket"], Key=args["target_key"]) arugments = [] for idx, record in dataset.iterrows(): argument = {} argument["source"] = (s3_data_root + record.path)[5:] argument["target_bucket"] = urlparse(s3_sample_image_root).netloc argument["target_key"] = urlparse(s3_sample_image_root).path[1:] + record.path arugments.append(argument) with ThreadPool(4) as p: r = list(tqdm(p.imap(upload_, arugments), total=len(dataset))) 次に、バッチ処理でアイテム画像の推論を行います。SageMakerの Batch Transform ジョブは、Amazon S3 の入力用ディレクトリに格納されているすべての画像をエンコードするためにCLIPモデルを使用し、出力された Embedding を出力S3フォルダにアップロードします。 このジョブには約10分かかります。 batch_input = s3_sample_image_root + "/" output_path = f"s3://&lt;your-bucket&gt;/inference/output" clip_image_transformer = clip_image_model.transformer( instance_count=1, instance_type="ml.c5.xlarge", strategy="SingleRecord", output_path=output_path, ) clip_image_transformer.transform( batch_input, data_type="S3Prefix", content_type="application/x-image", wait=True, ) Amazon S3 から Embeddings を変数に読み込み、後ほどOpenSearch Service にデータを格納できるようにします。 embedding_root_path = "./data/embedding" s3down.download(output_path, embedding_root_path) embeddings = [] for idx, record in dataset.iterrows(): embedding_file = f"{embedding_root_path}/{record.path}.out" embeddings.append(json.load(open(embedding_file))[0]) 機械学習を活用した統合検索エンジンを作成する このセクションでは、Embeddings を使用した k-NN 検索を実行する検索エンジンの作成方法について説明します。これには、OpenSearch Serviceクラスターの構成、Embeddings の取り込み、フリーテキストおよび画像検索クエリの実行が含まれます。 k-NN を使って OpenSeach Service ドメインを設定する 以前に、OpenSearch クラスターを作成しました。ここでは、カタログデータと埋め込みを格納するためのインデックスを作成します。インデックス設定を次の構成で構成して、k-NN機能を有効にできます。 index_settings = { "settings": { "index.knn": True, "index.knn.space_type": "cosinesimil" }, "mappings": { "properties": { "embeddings": { "type": "knn_vector", "dimension": 1024 #Make sure this is the size of the embeddings you generated, for RN50, it is 1024 } } } } この例では、 Python Elasticsearch Client を使用してOpenSearch クラスターと通信し、データをホストするインデックスを作成します。 ノートブックで %pip install elasticsearch を実行してライブラリをインストールできます。 次のコードを参照してください: import boto3 import json from requests_aws4auth import AWS4Auth from elasticsearch import Elasticsearch, RequestsHttpConnection def get_es_client(host = "&lt;your-opensearch-service-domain-url&gt;", port = 443, region = "&lt;your-region&gt;", index_name = "clip-index"): credentials = boto3.Session().get_credentials() awsauth = AWS4Auth(credentials.access_key, credentials.secret_key, region, 'es', session_token=credentials.token) headers = {"Content-Type": "application/json"} es = Elasticsearch(hosts=[{'host': host, 'port': port}], http_auth=awsauth, use_ssl=True, verify_certs=True, connection_class=RequestsHttpConnection, timeout=60 # for connection timeout errors ) return es es = get_es_client() es.indices.create(index=index_name, body=json.dumps(index_settings)) 画像の Embedding データを OpenSearch Service へ投入する ここで、データセットをループ処理して、クラスターにアイテムデータを取り込みます。 この練習のためのデータ取り込みは60秒以内に完了するはずです。 また、データがインデックスに正常に取り込まれたことを確認するためのシンプルなクエリを実行します。 次のコードを参照してください: # ingest_data_into_es for idx, record in tqdm(dataset.iterrows(), total=len(dataset)): body = record[['item_name_in_en_us']].to_dict() body['embeddings'] = embeddings[idx] es.index(index=index_name, id=record.item_id, doc_type='_doc', body=body) # Check that data is indeed in ES res = es.search( index=index_name, body={ "query": { "match_all": {} }}, size=2) assert len(res["hits"]["hits"]) &gt; 0 リアルタイムでクエリを実行する これで在庫の画像アイテムの Embeddings が含まれたOpenSearch Service Index を用意できたので、次はクエリの Embeddings を生成する方法を見ていきましょう。テキストと画像の Embeddings をそれぞれ処理するために、2 つのSageMaker 推論エンドポイントを作成する必要があります。 また、エンドポイントを使用して画像とテキストをエンコードする 2 つの関数を作成します。 encode_text 関数の場合、 this is をアイテム名の前に追加して、アイテム名をアイテムの説明文として翻訳します。 Transformer と ResNet モデルをサポートするために、 memory_size_in_mb は 6 GB に設定されています。以下のコードを参照してください: text_predictor = clip_text_model.deploy( instance_type='ml.c5.xlarge', initial_instance_count=1, serverless_inference_config=ServerlessInferenceConfig(memory_size_in_mb=6144), serializer=JSONSerializer(), deserializer=JSONDeserializer(), wait=True ) image_predictor = clip_image_model.deploy( instance_type='ml.c5.xlarge', initial_instance_count=1, serverless_inference_config=ServerlessInferenceConfig(memory_size_in_mb=6144), serializer=IdentitySerializer(content_type="application/x-image"), deserializer=JSONDeserializer(), wait=True ) def encode_image(file_name="./data/images/0e9420c6.jpg"): with open(file_name, "rb") as f: payload = f.read() payload = bytearray(payload) res = image_predictor.predict(payload) return res[0] def encode_name(item_name): res = text_predictor.predict({"inputs": [f"this is a {item_name}"]}) return res[0] まず使用する画像をプロットします。 item_image_path, item_name = get_image_from_item_id(item_id = "B0896LJNLH", return_image=False) feature_vector = encode_image(file_name=item_image_path) print(feature_vector.shape) Image.open(item_image_path) 簡単なクエリの結果を見てみましょう。OpenSearch Serviceから結果を取得した後、 dataset からアイテム名と画像のリストを取得します。 def search_products(embedding, k = 3): body = { "size": k, "_source": { "exclude": ["embeddings"], }, "query": { "knn": { "embeddings": { "vector": embedding, "k": k, } } }, } res = es.search(index=index_name, body=body) images = [] for hit in res["hits"]["hits"]: id_ = hit["_id"] image, item_name = get_image_from_item_id(id_) image.name_and_score = f'{hit["_score"]}:{item_name}' images.append(image) return images def display_images( images: [PilImage], columns=2, width=20, height=8, max_images=15, label_wrap_length=50, label_font_size=8): if not images: print("No images to display.") return if len(images) &gt; max_images: print(f"Showing {max_images} images of {len(images)}:") images=images[0:max_images] height = max(height, int(len(images)/columns) * height) plt.figure(figsize=(width, height)) for i, image in enumerate(images): plt.subplot(int(len(images) / columns + 1), columns, i + 1) plt.imshow(image) if hasattr(image, 'name_and_score'): plt.title(image.name_and_score, fontsize=label_font_size); images = search_products(feature_vector) 2 つの画像が同じであるため、最初の項目のスコアは 1.0 です。その他の項目は、OpenSearch Service Index にあるさまざまな種類のウォーターグラスになります。 テキストを使用してインデックスをクエリすることもできます。 feature_vector = encode_name("drinkware glass") images = search_products(feature_vector) display_images(images) これで、インデックスからウォーターグラスの写真を 3 枚取得できるようになりました。CLIP エンコーダーを使用すると、同じ潜在空間内の画像とテキストを検索できます。これのもう 1 つの例は、索引で「ピザ」という単語を検索することです。 feature_vector = encode_name("pizza") images = search_products(feature_vector) display_images(images) Clean up 従量課金制モデルの Serverless Inference は、頻度の低いトラフィックパターンや予測不可能なトラフィックパターンに対して費用対効果の高いオプションです。厳格な サービスレベル契約 (SLA) を締結している場合や、コールドスタートに耐えられない場合は、リアルタイムエンドポイントの方が適しています。 マルチモデル または マルチコンテナ のエンドポイントを使用すると、多数のモデルをデプロイするためのスケーラブルで費用対効果の高いソリューションが得られます。詳細については、 Amazon SageMaker の料金ページ を参照してください。 サーバーレスエンドポイントは、不要になったら削除することをお勧めします。この演習を終了したら、次の手順でリソースを削除できます (これらのリソースは、 AWS マネジメントコンソール から、または AWS SDK または SageMaker SDK を使用して削除できます)。 作成したエンドポイントを削除します。 (オプション) 登録されたモデルを削除します。 (オプション) SageMaker 実行ロールを削除します。 (オプション) S3 バケットを空にして削除します。 Summary この記事では、SageMaker と OpenSearch Service の k-NN インデックス機能を使用して k-NN 検索アプリケーションを作成する方法を示しました。OpenAI 実装の事前トレーニング済みの CLIP モデルを使用しました。 投稿の OpenSearch サービスのインジェスト実装は、プロトタイピングにのみ使用されます。Amazon S3 から OpenSearch サービスに大規模にデータを取り込みたい場合は、適切なインスタンスタイプとインスタンス数で Amazon SageMaker 処理ジョブを起動できます。別のスケーラブルな埋め込み取り込みソリューションについては、「 Novartis AG uses Amazon OpenSearch Service K-Nearest Neighbor (KNN) and Amazon SageMaker to power search and recommendation (Part 3/4) 」を参照してください。 CLIPは ゼロショット 機能を備えているため、 転移学習 を使用してモデルを微調整しなくても、事前にトレーニングされたモデルを直接採用できます。これにより、CLIPモデルの適用が簡単になります。製品画像と説明文の両方がある場合は、転移学習を使用して独自のデータでモデルを微調整し、モデルのパフォーマンスをさらに向上させることができます。詳細については、「 Learning Transferable Visual Models From Natural Language Supervision 」と「 CLIP GitHub リポジトリ 」を参照してください。 著者について Kevin Du は AWS のシニアデータラボアーキテクトで、お客様の機械学習 (ML) 製品と MLOps プラットフォームの開発を促進できるよう支援することに専念しています。スタートアップと企業の両方を対象に ML 対応製品を開発してきた 10 年以上の経験を持つ彼は、お客様が ML ソリューションの本番化を合理化できるよう支援することに重点を置いています。自由時間には、ケビンは料理やバスケットボール観戦を楽しんでいます。 Ananya Royは、オーストラリアのシドニーを拠点とするAIと機械学習を専門とするシニアデータラボアーキテクトです。彼女はさまざまな顧客と協力してアーキテクチャのガイダンスを提供し、データラボとの連携を通じて効果的なAI/MLソリューションを提供できるよう支援してきました。AWS に入社する前は、シニアデータサイエンティストとして働き、通信会社、銀行、フィンテックなどのさまざまな業界の大規模な ML モデルを扱っていました。AI/ML の経験により、複雑なビジネス上の問題に対して効果的なソリューションを提供でき、最先端のテクノロジーを活用してチームが目標を達成できるよう支援することに情熱を注いでいます。 翻訳はソリューションアーキテクトの辻 浩季が担当しました。原文は こちら です。 &nbsp;

この記事は Alex Zarenin（プリンシパルソリューションアーキテクト）、Sudhir Amin（シニアソリューションアーキテクト）と Vikas Babu Gali（シニアスペシャリストソリューションアーキテクト）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 このブログ記事では Amazon Web Services（AWS）上の Microsoft SQL Server デプロイメントをスケーリングするための戦略について紹介します。この戦略ではクラウド上でフルマネージドの高性能なファイルシステムを提供する Amazon FSx を使用します。この戦略により、AWS 上での SQL Server のパフォーマンスが大幅に改善され、1 分あたりのトランザクション数（TPM）は従来比で 2～3 倍になります。また、トランザクションあたりのコストが低減されるため、コスト効率も向上します。 全体としてこの戦略は、最高性能の SQL Server データベースをクラウドで実行するコスト効率の高い方法をお探しのお客様にご利用いただけます。 1. はじめに 2021 年、私たちのチームは、AWS 上の SQL Server のパフォーマンスについて新たなベンチマークを記録し、 ブログ記事 としてリリースしました。著者は、メモリ最適化された Amazon Elastic Compute Cloud (Amazon EC2) r5b.24xlarge インスタンスを使用し、最大 60,000 Mbps の Amazon Elastic Block Store (EBS) 帯域幅と、毎秒 26 万回の Input/Output Operations（IOPS）を実現しました。このインスタンスの IO 機能を最大限に活用するため、3.5 TB の HammerDB TPCC テストデータベースを 2 つの io2 Block Express (io2-BE) ボリュームに格納し、 RAID-0 構成で実装しました。この構成で HammerDB を使用したパフォーマンステストでは、約 83 万 TPM を達成しました。 同じブログ記事で、著者は Amazon EC2 のインスタンスストア ボリュームにデータベースをホスティングすることで、パフォーマンスが約 20 ％ 向上することを示しました。しかしながら、インスタンスストアボリュームは 一時的な ブロックストレージであり、インスタンスを停止すると失われます。そのため、インスタンスストアボリュームは tempdb のストレージに適しています。一方で EBS ボリュームと Amazon FSx ファイルシステムは、データベースをホスティングするための耐久性と拡張性のあるストレージソリューションを提供します。 x2iedn や r6idn といった新しいインスタンスファミリーは、ブログ記事で使用した r5b.24xlarge よりも大幅にパフォーマンスが向上しています。これにより、パフォーマンスが約 30 ％ 向上し、100 万 TPM に近い結果が得られました。ただし、こうしたパフォーマンスの向上にはコストを伴います。仮想 CPU（vCPU）数の増加により、SQL Server の追加ライセンスが必要となります。また、インスタンスのスループットを使い切るには、3 つの io2-BE ボリュームにわたって RAID-0 を構成して使用する必要があるため、EBS ストレージのコストも増加します。 このブログ記事では、SQL Server について、EBS またはインスタンスストアボリュームだけでは不可能な高いパフォーマンスを実現するための Amazon FSx の革新的な使用方法をご紹介します。 2.&nbsp;テスト構成 Windows 上での SQL Server のパフォーマンステストでは、Windows と互換性のある Amazon FSx ファイルシステム、つまり Amazon FSx for NetApp ONTAP (FSx for ONTAP) と Amazon FSx for Windows File Server (FSx for Windows File Server) を使用しました。それぞれの Amazon FSx ファイルシステムを、26 TB の SSD ストレージ、80,000 IOPS、2 GBps のスループットで構成しました。 FSx for ONTAP は、最大 4 GBps、160,000 IOPS のスループットを提供 し、 FSx for Windows File Server は、最大 12 GBps、350,000 IOPS のスループットを提供 しますが、本ブログ記事の執筆時点では特定の AWS リージョンでのみ利用可能であるため、これらの構成は今回のテストから除外しました（これらのパフォーマンステストは、より高いスループットキャパシティレベルを使用してフォローアップする予定です）。 パフォーマンステストでは、 AWS バージニア北部リージョン（us-east-1） で、Amazon のライセンス付き Microsoft Windows Server 2019 with SQL Server 2019 Enterprise edition を使用しました。EC2 インスタンスには、768 GB の RAM、96 個の vCPU、100 Gbps のネットワーク帯域幅、4 個の 900 GB NVMe SSD インスタンスストアボリュームを備えた r5dn.24xlarge EC2 インスタンスを使用しました。このインスタンスを選択した理由は、 元のブログ記事 で使用した r5b.24xlarge EC2 インスタンスと同等の vCPU と RAM を備えながら、より高いネットワークスループットを提供するためです。データベースの格納場所としてネットワーク接続ストレージを使用しているため、ネットワークスループットはパフォーマンスを大きく左右します。 tempdb を格納する場所として、 r5dn.24xlarge EC2 インスタンスで利用可能な 4 つのインスタンスストアボリュームにわたって、RAID-0 ボリュームを作成しました。また、SQL Server データベースのログファイルを保管する場所として、64,000 IOPS でプロビジョニングされた io2-BE EBS ボリュームを使用しました。データベースのデータファイルは Amazon FSx ファイルシステムに格納しました。 今回、データベースのワークロードをシミュレートするために、幅広く使用されているベンチマークツール HammerDB を使用しました。HammerDB の OLTP ワークロード は、SQL Server の AWS への移行において一般的であるため、私たちのパフォーマンステストのベースとしました。約 3 TB で 30,000 の データウェアハウス を含むテストデータベースを作成しました。 HammerDB の 仮想ユーザー は、パフォーマンステストのためにデータベースに負荷をかけるシミュレートされたユーザーです。システムのピークパフォーマンスを測定するには、少数の仮想ユーザーから始め、データベースの TPM が臨界点に達するまで徐々にこの数を増やすことをお勧めします。仮想ユーザーの数を増やすと、パフォーマンスメトリクスは 臨界点に達するまで増加 し、その後は増加が止まるか、あるいは減少に転じます。 各テストの構成では、仮想ユーザー数として 256 、 362 、 512 、 724 、 1,024 を選択しました。結果の信頼性と一貫性を確保するため、仮想ユーザー数で定義されたそれぞれの負荷について、3 回のテストを実施しました。そして、これらのテストの平均を算出しました。 3.&nbsp;FSx for ONTAP を使用したパフォーマンステスト FSx for ONTAP は、 iSCSI と SMB の 2 つのプロトコルを提供しています。パフォーマンステストでは、両方のプロトコルを使用しました。 3.1.&nbsp;FSx for ONTAP を iSCSI プロトコルで使用 4 つの FSx for ONTAP インスタンスが提供する iSCSI 接続のドライブを EC2 インスタンスにアタッチしました。これらのドライブは、 Windows Storage Spaces 機能を使用して、RAID-0 構成でストライピングしました。iSCSI ドライブのパフォーマンスを引き出すため、 MPIO を有効にして、各ドライブに 4 つのパスを割り当てました。このシナリオの構成を図 1 に示します。 図 1. FSx for ONTAP iSCSI プロトコルのパフォーマンステスト構成 この構成での HammerDB パフォーマンステストの結果を表 1 と図 2 に記載します。結果が示すように、この構成では、元のブログ記事で説明したパフォーマンスの 2 倍のパフォーマンスを達成することができました。この構成では、 724 の仮想ユーザーで臨界点に達し、それ以上負荷が増加するとパフォーマンスが低下しました。 表 1. FSx for ONTAP iSCSI プロトコルのパフォーマンステスト結果 図 2. FSx for ONTAP iSCSI プロトコルのパフォーマンステスト結果 3.2.&nbsp;FSx for ONTAP を SMB プロトコルで使用 FSx for ONTAP は SMB プロトコル もサポートしています。SMB プロトコルは、ネットワーク上でファイルへのアクセスを共有するために使用されるクライアントサーバ通信プロトコルです。iSCSI プロトコルとは異なり、SMB は仮想ドライブを提供しませんが、代わりにファイル共有を提供します。このため、前のシナリオのように RAID-0 ストライピングを使用してパフォーマンスを向上させることはできません。 ボリュームをストライピングする代わりに、ファイルグループ内のデータベースファイルを複数のボリュームまたはファイル共有に分散する SQL Server の機能を使用しました。プライマリファイルグループを、4 つの FSx for ONTAP ファイルシステムが提供する 4 つのファイル共有に分散しました。 RAID-0 シナリオでは、テーブルの各レコードは複数のドライブに分割されます。しかし、プライマリファイルグループを複数の共有に分散させると、このファイルグループに割り当てられた各テーブルレコードは、それぞれ単一の SMB 共有に保存されます。テーブルのすべてのレコードは、複数の共有に均等に分散されます。この構成は RAID-0 の場合と類似しています。この構成を図 3 に示します。 図 3. FSx for ONTAP SMB プロトコルのパフォーマンステスト構成 この構成での HammerDB パフォーマンステストの結果を表 2 と図 4 に記載します。結果から明らかなように、この構成は、前述のセクション 3.1 で説明した構成よりも優れた値を記録しました。負荷が増加するに従ってパフォーマンスは徐々に向上し、1,024 仮想ユーザーで臨界点に達しました。 表 2. FSx for ONTAP SMB プロトコルのパフォーマンステスト結果 図 4. FSx for ONTAP SMB プロトコルのパフォーマンステスト結果 4.&nbsp;FSx for Windows File Server を使用したパフォーマンステスト FSx for Windows File Server は SMB プロトコル のみをサポートしています。そのため、テストでは FSx for ONTAP の代わりに FSx for Windows File Server を使用している点を除き、図 3 で示したものと同様の構成を使用しました。この構成を図 5 に示します。 図 5. FSx for Windows File Server のパフォーマンステスト構成 ストレージにこの構成を使用して SQL Server を実行し、表 3 と図 6 に示すパフォーマンステスト結果を得ました。 表 3. FSx for Windows File Server のパフォーマンステスト結果 図 6. FSx for Windows File Server のパフォーマンステスト結果 パフォーマンステストでは、200 万 TPM を上回る結果を達成しました。これは、 元のブログ記事 で紹介した io2-BE EBS ボリュームで達成した最高記録の約 3 倍です。 5.&nbsp;コストとパフォーマンス観点の比較 表 4 は、先に説明した 3 つの構成と、io2-BE EBS ボリュームを使用した元の構成（元のブログ記事に記載）に対するパフォーマンステストの結果をまとめたものです。また、各構成の試算コストも記載しています。Amazon FSx のコスト試算においては、バックアップのコストや重複の削減はデータベースワークロードには当てはまらないため、考慮していません。 FSx for ONTAP を使用した構成のパフォーマンスとしては、安定状態のパフォーマンス値を使用しました。SQL Server などの動的なワークロードでは、通常、表 1 と表 2 の結果よりも 10～15 % 低くなります。コンピュートのコストは、AWS リージョン us-east-1 （バージニア北部）の EC2 インスタンス r5dn.24xlarge （ライセンス付き Microsoft Windows Server 2019 with SQL Server 2019 Enterprise edition）に基づいており、原文が執筆された 2023 年 8 月 28 日時点のものです。 表 4. コストとパフォーマンスの比較データ Amazon FSx ファイルシステムを 4 つ追加したことで、システムのトータルコストは増加しました。しかし、パフォーマンスも向上したため、トランザクションあたりの総コストは減少しました。 FSx for ONTAP を SMB 接続で使用した場合、コストパフォーマンスが最も優れていました。FSx for Windows File Server は、全体的なパフォーマンスは最も高いですが、トータルコストも最も高くなりました。ただし、この構成で達成した SQL Server の優れたパフォーマンスを考慮すると、1,000 TPM あたりのコストは、SMB 接続を使用した FSx for ONTAP とほぼ同等です。 6.&nbsp;パフォーマンステストのスコープを拡大 AWS の新しいインスタンスタイプ、特にメモリを大量に消費する大規模アプリケーションに幅広く使用されている x2iedn メモリ最適化 EC2 インスタンスファミリーを考慮しなければ、分析は不完全なものになります。このファミリーではすべてのサイズで、メモリと vCPU が 32:1 の比率で提供され、RAM を最大 4 TB までスケールアップできるため、SQL Server のワークロードに適しています。これまでのテストで使用した r5dn.24xlarge インスタンスと比較するため、それぞれ 2 TB と 4 TB の RAM を搭載した x2iedn.24xlarge と x2iedn.32xlarge を選択しました。 3.5 TB のデータベースを、データベースのサイズに近いかそれを超える RAM を搭載した EC2 インスタンスで使用した場合、IO サブシステムをテストするための十分な負荷を与えられない可能性があります。そのため、8.5 TB で 75,000 のデータウェアハウスを含む HammerDB データベースを作成しました。8.5 TB では IO サブシステムに負荷をかけることができます。また、仮想ユーザー数を 2,048 に増やすことで、SQL Server の負荷をさらに高めることを目指しました。 ストレージサブシステムについては、FSx for Windows File Server を 4 つ使用し、図 5 と同じ構成で、最もパフォーマンスの良い構成を選択しました。テストの結果を表 5 と図 7 に記載します。 表 5. パフォーマンステスト結果 – 8.5 TB データベース 図 7. パフォーマンステスト結果 – 8.5 TB データベース r5dn.24xlarge インスタンス上の SQL Server は、8.5 TB のデータベースでは約 150 万 TPM でピークに達しました。 x2iedn ファミリーの RAM の増加は、SQL Server が 200 万 TPM を超えることを可能にした決定的な要因でした。8.5 TB のデータベースでは、 r5dn.24xlarge で利用可能な 768 GB と比較して、 x2iedn ファミリーはメモリ容量が増えているため、大きな違いが生じました。 この一連のテストのコストパフォーマンス分析を表 6 に記載します。 x2iedn.24xlarge EC2 インスタンスは、1,000 TPM あたりのコストという点では明らかに優れていました。ただし、より大きな x2iedn.32xlarge EC2 インスタンスと比べ、性能はわずかに低くなっています。 x2iedn.32xlarge の EC2 インスタンスで利用可能な 4 TB の RAM を最大限に活用するには、さらに大きなデータベースを検討する必要があるかもしれません。 表 6. 大規模データベーステストのコスト/パフォーマンス比較 図 8 に示したもう 1 つの興味深い点は、RAM の大きいインスタンスほど、基盤となる FSx for Windows File Server で消費される IOPS とスループットが減少したことです。これは、SQL Server がキャッシュ内でより多くのオペレーションを完了し、ファイルシステムに対する負荷が減少したためです。 図 8. RAM の増加による IOPS とスループットの変化 7.&nbsp;まとめ 複数の Amazon FSx ファイルシステムを革新的に使用することで、単一のファイルシステムよりもはるかに高いストレージパフォーマンスを達成することができました。これにより、SQL Server のパフォーマンスが大幅に向上しました。複数の Amazon FSx ファイルシステムを使用することで、実行するリソースのコストは増加しますが、結果として SQL Server のパフォーマンスが向上します。そのため、トランザクションあたりのコストは、他の構成と同等か、それ以下の水準まで減少します。 FSx for ONTAP を iSCSI で使用した場合、SQL Server のテストではやや低いパフォーマンスを示しましたが、RAID-0 を構成することで、プライマリファイルグループを 4 つのボリュームに分散する必要がないため、よりシンプルな導入方法を提供します。 4 つの Amazon FSx ファイルシステムを使用してテストを実施しましたが、「4」は「マジックナンバー」ではありません。SQL Server をホストする EC2 インスタンスと、お客様固有のパフォーマンスおよびコスト要件によっては、2 つまたは 3 つの Amazon FSx ファイルシステムを使用するだけでも、SQL Server のパフォーマンスを大幅に向上させることができます。 この方法は、お客様が高性能な SQL Server ワークロードを管理するための新たな選択肢を提供します。特に今回ご紹介した戦略は、最高性能の SQL Server データベースをクラウドで実行するコスト効率の高い方法をお探しのお客様にご利用いただけます。 AWS は、どのクラウドプロバイダーよりも多くのサービスと機能を備えています。そのため、既存のアプリケーションをより速く、より簡単に、よりコスト効率の高い方法でクラウドに移行でき、想像できるほとんどすべてのものを構築することができます。Microsoft アプリケーションに必要なインフラストラクチャを提供し、お客様が望むビジネス成果を実現することができます。Microsoft ワークロードに関する詳しいガイダンスとオプションについては、 .NET on AWS と AWS データベース のブログをご覧ください。移行とモダナイゼーションの検討を今すぐ開始するには、 こちらへお問い合わせ ください。 <!-- '"` --> 翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの宮城が担当しました。 著者紹介 Alex Zarenin Alex Zarenin は Amazon Web Services のプリンシパルソリューションアーキテクトです。金融サービス企業と協力して、幅広い技術ソリューションの設計と実装に従事しています。Microsoft テクノロジーに関する専門知識を持ち、商業部門と公共部門の両方で 30 年以上の技術経験を積み重ねてきました。ニューヨーク大学でコンピューターサイエンスの博士号を取得しています。 Sudhir Amin Sudhir Amin は Amazon Web Services のシニアソリューションアーキテクトです。ニューヨークを拠点として、さまざまな業種の企業顧客にアーキテクチャのガイダンスと技術支援を提供し、クラウドの導入を加速しています。スヌーカー、ボクシングや UFC などの格闘技の大ファンで、野生動物保護区が豊富な国を旅して、世界で最も雄大な動物を間近で見るのが好きです。 Vikas Babu Gali Vikas Babu Gali は、Amazon Web Services の Microsoft ワークロードを専門としたシニアスペシャリストソリューションアーキテクトです。さまざまな業種のお客様に対して、クラウド導入を加速するためのアーキテクチャに関するガイダンスと技術支援を提供しています。

(出展: 株式会社MIXI) MIXI は、認証から決済までをワンストップで提供する、基盤システム &amp; WALLET サービスである MIXI M を消費者向けに展開しています。このたび、お客様は MIXI M に 3D セキュアを実装しました。3D セキュアは、追加の認証によってユーザーの購買意思を確認する仕組みで、より安心・安全なオンライン決済体験を実現します。 以下はユーザーから見た 3D セキュアを含む決済体験のイメージです。 3D セキュアの提供にあたってはセキュリティ基準 PCI 3DS への準拠が不可欠です。お客様は、PCI 3DS が求める厳密な鍵管理を、AWS Key Management Service (AWS KMS) を用いて実装し、同基準に準拠しました。 PCI 3DS では、一部の鍵管理に FIPS140-2 Level3 以上もしくは PCI PTS 認定の HSM の利用を規定しています。このため、以前は AWS KMS は利用できませんでしたが、 2023 年 5 月に AWS KMS 内部の HSM が FIPS140-2 Level3 にアップグレード したことにより、要件を満たすようになりました。お客様の検討段階では AWS KMS を用いた PCI 3DS 準拠の先行事例はありませんでしたが、AWS からの支援を通じて、AWS KMS を利用するメリット、PCI 3DS QSA (認定審査人) との会話のポイントがクリアになったことから、 AWS KMS を第一選択肢として設計が進みました。 コンプライアンス対応の削減 AWS におけるコンプライアンス対応は、責任共有モデルに基づいて利用者と AWS が分担します。マネージド型サービスなど抽象度の高いサービスを使えば使うほど、利用者の責任範囲が減少し、コンプライアンス対応のより多くを AWS にオフロードできます。当初予定していた AWS CloudHSM を利用する場合に比べて、AWS KMS の利用によりコンプライアンス対応が削減されることは明らかでした。PCI 3DS では準拠後にコンプライアンス維持のための運用が必要となるため、これを削減できることはメリットでした。 運用の削減 AWS CloudHSM では、HSM のバックアップやクラスターの管理の一部を利用者自身で行う必要があります。一方、AWS KMS はマネージド型サービスのため、全て AWS に任せることができます。お客様は少人数でも運用が可能なマネージド型サービスを積極的に採用しているため、AWS CloudHSM よりマネージドな AWS KMS が利用できることに大きなメリットがありました。 AWS SDK の活用 AWS CloudHSM では、鍵へのアクセスに PKCS #11 や OpenSSL Dynamic Engine といった HSM 標準の SDK の利用が必要でした。一方、AWS KMS が管理する鍵へのアクセスはお客様が慣れ親しんだ AWS SDK を利用することができるため、開発やテストが容易である点がメリットでした。 アクセス保護 PCI 3DS では鍵への物理的、論理的アクセスからの保護要件が存在します。物理的アクセスは両サービスともに AWS の責任範囲である一方、論理的アクセスからの保護は利用者の対応も必要です。AWS CloudHSM では HSM の仕様に沿った保護が必要な一方で、 AWS KMS ではキーポリシーの利用によりこれまで活用してきた AWS Identity and Access Management (AWS IAM) の仕組みで実現できることにメリットがありました。 ランニングコスト AWS CloudHSM は時間課金制で HSM の料金が発生するため、最小構成(2台)でも月額 $3,400 程度となり、スケールアウトする際には1台ずつ追加が必要です。一方、AWS KMS はリクエスト単位で費用が発生するため、リクエスト数に応じて無駄なくコストを支払うことができます。そのため、想定していた費用を大きく削減することができました。 アーキテクチャ MIXI M における 3D セキュアの実装に関わるアーキテクチャの一部を紹介します。 お客様は以前より MIXI M で Amazon API Gateway などマネージド型サービスを積極的に活用しており、また PCI DSS に準拠しています。 AWS KMS で管理する鍵を使用する操作は REST API を介して実行します。 AWS KMS で定義されたリクエストクォータの範囲内であればアクセスの増減に対して追加の作業は発生しません。VPC Endpoint を活用することでプライベートな経路で API を呼び出します。AWS KMS で管理する鍵に対する変更や鍵の使用は AWS CloudTrail に記録され確認が可能です。AWS KMS への論理アクセスはキーポリシーで管理しており、鍵へのアクセスが可能な IAM ユーザーや IAM ロールを鍵側から限定することができます。 お客様からの声 田岡 文利様 (株式会社 MIXI 開発本部 MIXI M 事業部) PCI 3DS 準拠は弊社にとって前例がなく、非常にチャレンジングな課題でした。弊社担当の AWS アカウントチームに問い合わせたところ、ニーズを瞬時に理解いただき、迅速にセキュリティスペシャリストとのミーティングを設定していただけました。ミーティングでは数々の有益な情報をご提供いただき、結果として安全性と信頼性を担保しながら迅速に PCI 3DS 準拠への対応を行うことができました。 浅見 公輔様 (株式会社 MIXI 開発本部 MIXI M 事業部) MIXI M では小規模チームでフルスタックに開発と運用を行っており、運用と開発のコスト削減は常に最優先事項です。AWS KMS を利用することで PCI 3DS で必要となる運用コストを大幅に削減でき、3D セキュアのシステム開発に集中できました。私達は AWS のフルマネージド型サービスをフルに活用していますが、フルマネージド型サービスの活用による開発・運用コストの削減は大きなベネフィットがあると改めて確認しました。 まとめ お客様は AWS KMS を利用することで運用コストを低く抑えつつ 3D セキュアの実装と PCI 3DS 準拠を達成しました。今後も マネージド型サービスのメリットを活かしてアーキテクチャを最適化し、サービス向上につながる様々な機能の実装を進めていきたいとのことです。 著者 秋山 周平（ゲームソリューションアーキテクト） 中島 智広（シニアセキュリティソリューションアーキテクト）