TECH PLAY

AWS

AWS の技術ブログ

3159

12月20日、 AWS Cloud Development Kit (AWS CDK) のサポートを備えた、既存の MySQL および PostgreSQL データベースに接続してクエリする機能の一般提供を開始しました。これは、Amazon Web Services (AWS) 内外のリレーショナルデータベースのために、リアルタイムで安全な GraphQL API を作成するための新しい機能です。データベースエンドポイントと認証情報のみを使用して、すべてのリレーショナルデータベースオペレーション用の API 全体を生成できるようになりました。データベーススキーマが変更された場合、コマンドを実行して最新のテーブルスキーマの変更を適用できます。 2021 年に、 AWS Amplify GraphQL Transformer バージョン 2 を発表しました。これにより、デベロッパーは、クラウドに関する専門知識が極めて少ない場合でも、より機能が豊富で、柔軟かつ拡張可能な GraphQL ベースのアプリケーションバックエンドを開発できるようになりました。この新しい GraphQL Transformer は、GraphQL API リクエストをルーティングし、認可などのビジネスロジックを適用するとともに、 Amazon DynamoDB などの基盤となるデータソースと通信するために、拡張可能なパイプラインリゾルバーを生成することを目的として、一から再設計されました。 しかし、お客様は、Amazon DynamoDB に加えて、 Amazon RDS データベースや Amazon Aurora データベースなどの GraphQL API 用のリレーショナルデータベースソース を使用したいと考えていました。今後、リレーショナルデータベースと DynamoDB データソースの両方のために、 @model タイプの Amplify GraphQL API を使用できるようになりました。リレーショナルデータベースの情報は、別の schema.sql.graphql ファイルに生成されます。通常の schema.graphql ファイルを引き続き使用して、DynamoDB ベースのタイプを作成および管理できます。 MySQL または PostgreSQL データベースの情報を提供するだけで、仮想プライベートクラウド (VPC) の背後にある場合でも、インターネット上でパブリックにアクセスできる場合でも、 AWS Amplify は、データベーステーブルに安全に接続して、 作成、読み取り、更新、または削除 (CRUD) クエリおよびミューテーションを公開する、変更可能な GraphQL API を自動的に生成します。フロントエンドのために、データモデルの名前をより慣用的な名前に変更することもできます。一例として、データベーステーブルは「todos」(複数形、小文字) と呼ばれるが、クライアントには「ToDo」(単数形、パスカルケース) として公開される場合を挙げることができます。 1 行のコードで、既存の Amplify GraphQL 認可ルール を API に追加でき、所有者ベースの認可やパブリック読み取り専用パターンなどのユースケースをシームレスに構築できます。生成された API は AWS AppSync の GraphQL 機能に基づいて構築されているため、安全なリアルタイムサブスクリプションをすぐに利用できます。数行のコードで、任意のデータモデルから任意の CRUD イベントをサブスクライブできます。 AWS CDK で MySQL データベースの使用を開始する AWS CDK を使用すると、プログラミング言語の優れた表現力を活用して、信頼性とコスト効率が高く、スケーラブルなアプリケーションをクラウド上に構築できます。使用を開始するには、ローカルマシンに AWS CDK をインストール します。 $ npm install -g aws-cdk 次のコマンドを実行して、インストールが正しいことを検証し、AWS CDK のバージョン番号を出力します。 $ cdk –version 次に、アプリケーション用の新しいディレクトリを作成します。 $ mkdir amplify-api-cdk $ cd amplify-api-cdk cdk init コマンドを使用して CDK アプリケーションを初期化します。 $ cdk init app --language typescript Amplify の GraphQL API コンストラクトを新しい CDK プロジェクトにインストールします。 $ npm install @aws-amplify/graphql-api-construct CDK プロジェクトのメインスタックファイルを開きます (通常は lib/<your-project-name>-stack.ts にあります)。ファイルの先頭に必要なコンストラクトをインポートします。 import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; MySQL データベースで次の SQL ステートメントを実行して、新しいリレーショナルデータベース API の GraphQL スキーマを生成します。列ヘッダーを含む結果を .csv ファイルに出力し、 <database-name> を、データベース名、スキーマ名、またはその両方に置き換えてください。 SELECT INFORMATION_SCHEMA.COLUMNS.TABLE_NAME, INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT, INFORMATION_SCHEMA.COLUMNS.ORDINAL_POSITION, INFORMATION_SCHEMA.COLUMNS.DATA_TYPE, INFORMATION_SCHEMA.COLUMNS.COLUMN_TYPE, INFORMATION_SCHEMA.COLUMNS.IS_NULLABLE, INFORMATION_SCHEMA.COLUMNS.CHARACTER_MAXIMUM_LENGTH, INFORMATION_SCHEMA.STATISTICS.INDEX_NAME, INFORMATION_SCHEMA.STATISTICS.NON_UNIQUE, INFORMATION_SCHEMA.STATISTICS.SEQ_IN_INDEX, INFORMATION_SCHEMA.STATISTICS.NULLABLE FROM INFORMATION_SCHEMA.COLUMNS LEFT JOIN INFORMATION_SCHEMA.STATISTICS ON INFORMATION_SCHEMA.COLUMNS.TABLE_NAME=INFORMATION_SCHEMA.STATISTICS.TABLE_NAME AND INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME=INFORMATION_SCHEMA.STATISTICS.COLUMN_NAME WHERE INFORMATION_SCHEMA.COLUMNS.TABLE_SCHEMA = '<database-name>'; 次のコマンドを実行します。その際、 <path-schema.csv> を、前のステップで作成した .csv ファイルへのパスに置き換えます。 $ npx @aws-amplify/cli api generate-schema \ --sql-schema <path-to-schema.csv> \ --engine-type mysql –out lib/schema.sql.graphql schema.sql.graphql ファイルを開いて、MySQL データベーススキーマからインポートされたデータモデルを確認できます。 input AMPLIFY {      engine: String = "mysql"      globalAuthRule: AuthRule = {allow: public} } type Meals @model {      id: Int! @primaryKey      name: String! } type Restaurants @model {      restaurant_id: Int! @primaryKey      address: String!      city: String!      name: String!      phone_number: String!      postal_code: String!      ... } まだ作成していない場合は、 AWS Systems Manager コンソール の [パラメータストア] に移動し、データベースの接続の詳細のパラメータ ( hostname/url 、 database name 、 port 、 username 、 password など) を作成します。これらは、Amplify がデータベースに正常に接続し、そのデータベースに対して GraphQL クエリまたはミューテーションを実行するために次のステップで必要になります。 メインスタッククラスで、次のコードを追加して、新しい GraphQL API を定義します。 dbConnectionConfg オプションを、前のステップで作成したパラメータパスに置き換えます。 new AmplifyGraphqlApi(this, "MyAmplifyGraphQLApi", { apiName: "MySQLApi", definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( [path.join(__dirname, "schema.sql.graphql")], { name: "MyAmplifyGraphQLSchema", dbType: "MYSQL", dbConnectionConfig: { hostnameSsmPath: "/amplify-cdk-app/hostname", portSsmPath: "/amplify-cdk-app/port", databaseNameSsmPath: "/amplify-cdk-app/database", usernameSsmPath: "/amplify-cdk-app/username", passwordSsmPath: "/amplify-cdk-app/password", }, } ), authorizationModes: { apiKeyConfig: { expires: cdk.Duration.days(7) } }, translationBehavior: { sandboxModeEnabled: true }, }); この設定は、データベースがインターネットからアクセスできることを前提としています。また、デフォルトの認可モードは AWS AppSync の API キーに設定されており、すべてのモデルでパブリックアクセスを許可するためにサンドボックスモードが有効になっています。これは、より詳細な認可ルールを追加する前に API をテストする場合に役立ちます。 最後に、GraphQL API を AWS クラウドにデプロイします。 $ cdk deploy これで、 AWS AppSync コンソール に移動し、作成した GraphQL API を見つけることができます。 プロジェクトを選択し、 [クエリ] メニューを選択します。MySQL データベースのテーブルと互換性のある、新しく作成された GraphQL API (1 つの項目を取得するための getMeals や、すべての項目を一覧表示するための listRestaurants など) を確認できます。 例えば、フィールドが address 、 city 、 name 、 phone_number などの項目を選択すると、新しい GraphQL クエリを確認できます。 [実行] ボタンを選択すると、MySQL データベースからのクエリ結果が表示されます。 MySQL データベースをクエリすると、同じ結果が表示されます。 データベースに合わせて GraphQL スキーマをカスタマイズする方法 SQL でカスタムクエリまたはミューテーションを追加するには、生成された schema.sql.graphql ファイルを開き、 the :<variable> 表記を使用してパラメータで @sql(statement: "") パスを使用します。 type Query {     listRestaurantsInState(state: String): Restaurants @sql("SELECT * FROM Restaurants WHERE state = :state;”) } より長くて複雑な SQL クエリの場合は、 customSqlStatements 設定オプションで SQL ステートメントを参照できます。参照値は、SQL ステートメントにマッピングされたプロパティの名前と一致する必要があります。次の例では、 customSqlStatements の searchPosts プロパティが参照されています。 type Query { searchPosts(searchTerm: String): [Post] @sql(reference: "searchPosts") } SQL ステートメントが API 定義でどのようにマッピングされるかを次に示します。 new AmplifyGraphqlApi(this, "MyAmplifyGraphQLApi", { apiName: "MySQLApi", definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( [path.join(__dirname, "schema.sql.graphql")], { name: "MyAmplifyGraphQLSchema", dbType: "MYSQL", dbConnectionConfig: { // ...ssmPaths, }, customSqlStatements: { searchPosts: // property name matches the reference value in schema.sql.graphql "SELECT * FROM posts WHERE content LIKE CONCAT('%', :searchTerm, '%');", }, } ), //... }); SQL ステートメントは、スキーマ内でインラインで定義されているかのように実行されます。パラメータの使用や戻り値のタイプの一致、および有効な SQL 構文が確実に使用されるようにすることに関しても、同じルールが適用されます。参照ファイルを使用すると、スキーマがクリーンな状態に保たれ、フィールド間で SQL ステートメントを再利用できるようになります。これは、より長くて複雑な SQL クエリ向けのベストプラクティスです。 または、 @refersTo ディレクティブを使用してフィールドとモデル名を変更することもできます。 @refersTo ディレクティブを指定しない場合、AWS Amplify は、モデル名とフィールド名がデータベースのテーブル名と列名に正確に一致すると想定します。 type Todo @model @refersTo(name: "todos") {      content: String      done: Boolean } 2 つのデータベーステーブル間の関係を作成する場合は、 @hasOne ディレクティブと @hasMany ディレクティブを使用して 1:1 または 1:M の関係を確立します。関係の親に戻る双方向の関係を作成するには、 @belongsTo ディレクティブを使用します。例えば、レストランとその食事メニューの間に 1:M の関係を作成できます。 type Meals @model {      id: Int! @primaryKey      name: String!      menus: [Restaurants] @hasMany(references: ["restaurant_id"]) } type Restaurants @model {      restaurant_id: Int! @primaryKey      address: String!      city: String!      name: String!      phone_number: String!      postal_code: String!      meals: Meals @belongsTo(references: ["restaurant_id"])      ... } DB インスタンスの GraphQL スキーマまたはデータベーススキーマに変更を加えるたびに、変更をクラウドにデプロイする必要があります。 DB インスタンスの GraphQL スキーマまたはデータベーススキーマに変更を加えるたびに、このガイドで前述した SQL スクリプトと .csv へのエクスポートのステップを再実行して、 schema.sql.graphql ファイルを再生成し、変更をクラウドにデプロイする必要があります。 $ cdk deploy 詳細については、AWS Amplify ドキュメントの「 Connect API to existing MySQL or PostgreSQL database 」をご覧ください。 今すぐご利用いただけます AWS Amplify のリレーショナルデータベースサポートは、Amazon VPC 内または AWS クラウド外の任意の場所でホストされている MySQL および PostgreSQL データベースで動作するようになりました。 ぜひお試しいただき、 AWS Amplify の AWS re:Post 、Amplify GraphQL API の GitHub リポジトリ 、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy P.S.サンプルコードの作成に貢献してくれた AWS の Principal Product Manager である René Huangtian Brandel に特に感謝します。 原文は こちら です。
Amazon Verified Permissions は、アプリケーション内の承認管理のプロセスを簡素化するために設計されています。本ブログでは、このサービスが様々なビジネスケースにどのように適用できるか理解いただくことを目的としています。 通常、企業はビジネスアプリケーション内に埋め込まれたカスタム権限ロジックを使用しています。これは最も一般的なアプローチで、ユーザのアクセス承認を管理するためのカスタムコードを記述する必要があります。これから、アプリケーション開発者とアクセス管理者がアプリケーション内でユーザのアクセス承認を取り扱う際に直面する一般的な課題と、Amazon Verified Permissionsがこれらの課題を解決する方法について説明します。そして、支払管理などのユースケースにVerified Permissions を組み込むための統合ガイドを提供します。最後に、きめ細かく、様々なケースに適応でき、アプリケーションの外部から管理されるアクセス制御システムの利点について議論します。 このブログ記事は、アクセスポリシーの管理を包括的かつ集約的なアプローチで行い、管理上のオーバーヘッドを軽減し、LoB (Line of Business) のユーザーがアプリケーション権限ポリシーを定義、管理、適用できるようにすることを目的としています。 エンタイトルメントシステムの構築に伴う課題 エンタイトルメントとは、アプリケーション内で各ユーザが何ができて何ができないかを決定するルールのことです。図1は、アプリケーションに組み込まれたコンポーネントと複数のデータストアに格納された、一般的なエンタイトルメントシステムのアーキテクチャを示しています。 図1: 典型的なエンタイトルメントシステム 独自の承認管理システムを作成することは、その有用性を確認するにあたって時間や専門知識が必要な、多くのリソースがかかる作業となります。企業は独自のエンタイトルメント管理システムを構築する際に、複雑性、セキュリティリスク、パフォーマンス、スケーラビリティ不足など多くの課題に直面します。これらの課題について詳しく見ていきましょう。 データの複雑性  – エンタイトルメントの決定は、ユーザーのロール、グループとの紐付き、プロダクトをどのように操作できるかなど、複雑なデータ関係に基づいて行われます。この複雑性の管理は困難で、特に多くのユーザー、グループ、プロダクトを持つ大規模な組織ではその管理はさらに難しくなります。 コンプライアンスとセキュリティ – エンタイトルメントシステムの構築には、コンプライアンス規制とセキュリティベストプラクティスの両方を慎重に考慮する必要があります。お客様のデータを保護し、セキュアな通信プロトコルを実装し、潜在的なセキュリティ上の脆弱性に対処する必要があります。 スケーラビリティ – 権限管理システムは、多数のユーザーとトランザクションを処理できるようスケールする必要があります。特に、サービスが重要なリソースへのアクセスを制御するために使用される場合は、この点が課題となります。 パフォーマンスと可用性 – エンタイトルメントサービスは、リアルタイムな判断を下すために頻繁に使用されるため、高性能である必要があります。加えて、お客様が自組織のエンタイトルメントが正しいと自信を持てるよう、信頼性や一貫性を備える必要があります。 Amazon Verified Permissionsを使用したエンタイトルメントサービスのアーキテクチャ設計 Amazon Verified Permissionsは、スケーラブルな権限管理ときめ細かな認可を提供するサービスであり、アプリケーションのコードに埋め込まれた認可の実装に大きく依存することなく、アプリケーションの構築とモダナイゼーションを支援します。Verified Permissionsを使用して、エンタイトルメントの管理方法について言及します。 ポリシーの作成と運用 Verified Permissionsは、ユーザーが特定のタスクを承認されるか禁止される権限をポリシーとして開発者が表現できるポリシー言語である Cedar を使用しています。一元的なポリシーベースの認証システムにより、開発者はアプリケーション間で一貫した方法できめ細かな認証を定義および管理でき、コードを変更する必要なく権限ルールを変更でき、権限をコードから外に移動することで可視性が向上します。 Verified Permissionsを使用することで、ロールベースアクセスコントロール(RBAC)と属性ベースアクセスコントロール(ABAC)の特徴を取り入れた特定の権限ポリシーを作成できます。このアプローチにより、 最小権限 の原則を優先しながらきめ細かなコントロールを実装できます。 ユースケース1 :メアリーは事務員として働いており、支払いの提出と閲覧ができます。彼女の支払い管理システム内のロールは複数のアクションを許可しており、この役割のポリシーは以下の通り定義できます。 permit ( principal, action in [ PaymentManager::Action::"SubmitPayment", PaymentManager::Action::"UpdatePayment", PaymentManager::Action::"ListPayment" ], resource ) when { principal.role == "clerk" }; 反対に、シャーリーは監査役で、支払いのリストアップのみが許可されています。この役割のポリシーは以下の通りです。 permit ( principal, action in [PaymentManager::Action::"ListPayment"], resource ) when { principal.role == "auditor" }; 支払いシステムは、主体、アクション、リソース、およびエンティティデータをVerified Permissionsに渡します。ユーザ情報がアプリケーション内で明示的に定義されていない場合は、支払いシステムはアイデンティティプロバイダやデータベースなどのデータストアからそれを取得する必要があります。 次に、Verified Permissionsは呼び出し元と対象となるリソースに影響するポリシーを組み立て、アクションを承認するか拒否するかの決定を下します。決定が下されると、それはアプリケーションに伝えられ、アプリケーションはその決定を強制できるようになります。 図2から分かるように、メアリーは「事務員」の役割を持ち、前述のポリシーがこのアクションを承認しているため、支払いの提出にアクセスできます。 図 2: テストベンチを使用した、メアリーが支払いを提出できるかどうかのテスト シャーリーは「監査人」という役割で支払いを提出できず、図3で示されるようにアクションが拒否されました。 図3:テストベンチを使用した、シャーリーが支払いを提出できるかのテスト ただし、図4に示すように、前述のポリシーではこのアクションが承認されているため、支払いを一覧表示することはできます。 図 4: テストベンチを使用した、シャーリーが支払いを一覧表示できるかどうかのテスト ユースケース2 :財務部長のジェーンが休暇中、支払システムアプリケーションを使用して、111222333という高額利用のアカウントにおけるアクセス権限を、財務部長代理のジョンに委任します。テンプレートからポリシーを作成することで、ジェーンの直接的な立会いなしにも関わらず、ジョンに支払いの承認権限を付与します。 支払いの承認ポリシーテンプレート :図5は、支払いを承認するためのサンプルポリシーテンプレートを示しています。このテンプレートを使用して作成されたポリシーを用い、以下のとおり、リソースの支払い承認権限をプリンシパルに提供します。 permit ( principal == ?principal, action in [PaymentManager::Action::"ApprovePayment"], resource == ?resource ); 図 5: ポリシーテンプレートの作成 テンプレートからポリシーを作成:図6は、前述のテンプレートを使用して作成されたポリシーを示しています。渡す必要があるパラメータは、プリンシパルとリソース情報です。このユースケースの場合、プリンシパルは「ジョン」で、リソースはアカウント「111222333」となっており、ジョンがそのアカウントの支払い承認を可能にしています。(AWSでは、プリンシパルとして統合的で一意な識別子(Universally Unique Identifier, UUID)の使用を推奨していますが、このブログ記事では読みやすさのため「ジョン」が使用されています。) 図 6: テンプレートからのポリシーの作成 ポリシーを評価:想定どおり、ジョンにはアカウント 111222333 の支払いを承認するためのアクセス権限が付与されます (図 7 を参照)。 図 7: テストベンチを使用した、ジョンが支払いを承認できるかどうかのテスト Verified Permissions を用いたエンタイトルメントサービスの構築 Verified Permissions では、認可機能を外部化し、ポリシーの管理と運用を中央集権化したエンタイトルメントサービスを構築できます。これにより、Verified Permissionsが提供する基盤となる権限管理を活用しながら、特定のアプリケーション要件に合わせてアクセス制御を調整することができます。 既存のエンタイトルメントサービスをVerified Permissionsと統合する 既存のエンタイトルメントサービスをVerified Permissionsと統合する方法が図8に示されています。エンタイトルメントサービスの基盤の実装においては、標準的なエンタープライズテクノロジースタックが使用されています。ユーザーとロール情報を格納するために Amazon DynamoDB が使用されています。 図 8: エンタイトルメントサービスとVerified Permissionsの統合 既存のエンタイトルメントサービスをVerfied Permissionsとスムーズに統合するためのアプローチがこちらです: 承認の識別 : まずは既存のエンタイトルメントサービスを評価し、現在使用している権限、様々な役割、アクション、リソースを特定することから始めます。権限の詳細なリストと、それぞれの目的をまとめてください。 ポリシーの構築 : 前のステップで各ユースケースに対して特定した承認ルールをポリシーにマッピングします。インラインポリシーとポリシーテンプレートの両方を使用できます。AWS マネジメントコンソールのVerified Permissionsテストベンチを使用して作成したポリシーを評価します。 ポリシーの作成 : ビジネスニーズに応じて、Verified Permissions内に1つまたは複数のポリシーストアを作成します。これらのポリシーストア内にポリシーを作成します。これは1回限りのタスクで、自動化を使用することをお勧めします。 エンタイトルメントサービスの更新 : 既存のインターフェイスを使用して、現在のリクエストペイロードをVerified Permissionsの認可リクエストが期待する形式に変換するロジックを作成します。必要なパラメータを既存のインターフェイスに追加する必要があるかもしれません。この同じ変換ロジックをレスポンスペイロードにも適用します。Verified Permissionsの認可リクエストとレスポンス形式についてはこちらの ドキュメント を参照してください。 Verified Permissionsとの統合 : Verified Permissions APIまたはAWS SDKを使用して、エンタイトルメントサービスをVerified Permissionsと統合します。 Amazon DynamoDB からユーザーロールを取得する、Verified Permissionsへの認可リクエストを行う、レスポンスを処理する、などのタスクが含まれます。 テスト : 権限変更後にサービス全体を徹底的にテストします。すべての機能が予期どおり動作し、Verified Permissionsのポリシーが正しく利用されていることを確認します。 デプロイ : サービスがレビュープロセスを通過したら、更新されたエンタイトルメントサービスと統合されたVerified Permissionsをロールアウトします。 モニタリングとメンテナンス : デプロイ後は、継続的にパフォーマンスをモニタリングし、フィードバックを収集します。状況に応じて、エンタイトルメントサービスのさらなる調整を実施します。 ドキュメントとサポート : エンタイトルメントサービスを使用する開発者向けに包括的なドキュメントを提供します。利用可能なエンドポイント、リクエストとレスポンスの形式、認可の要件について明確に説明します。 既存の権限サービスをサードパーティのエンタイトルメント管理システムと統合する場合においても、同様のアプローチをとることができます。 Amazon Verified Permissions を使用した AWS 上での新しいエンタイトルメントサービスの構築 図9の参考アーキテクチャは、Verified Permissionsを使用して新しいエンタイトルメントサービスを構築する方法を示しています。AWSのお客様はすでに Amazon Cognito を簡易で高速な認証のために使用しています。Amazon Verified Permissionsにより、お客様はAmazon Cognitoが生成したID Tokenにユーザープロファイル属性を追加することで、既存のアプリケーションに簡易で高速な認可を追加できるようになります。 図9:Verified Permissionsを使用したエンタイトルメントサービス 図に示されているワークフローは以下の通りです: お客様はAmazon Cognitoを使用してアプリケーションにサインインします。 認証が成功した場合、トークン生成前のLambda関数が起動します。 トークン生成前のLambda関数を使用して、Amazon Cognitoが生成するアイデンティティトークンをカスタマイズする前に、アイデンティティトークンに新しいクレームとしてユーザープロファイル属性を追加できます。この場合、トリガーはユーザープロファイル属性をアイデンティティトークンに新しいクレームとして追加するために使用されます。 ユーザープロファイル属性はAmazon DynamoDBから取得されます。 属性はその後アイデンティティトークンに新しい主張として追加されます。 ユーザーはサインインした後、 Amazon API Gateway を介してアプリケーション内の保護されたリソースへのアクセスをリクエストします。 Amazon API Gatewayは、Lambdaオーソライザーを使用して認可チェックを開始します。Lambdaオーソライザーは、Amazon Cognitoによって生成されたアイデンティティトークンを使用してカスタム認可スキームを実装できるAPI Gatewayの機能です。 Lambdaオーソライザーは、アイデンティティトークンから検証、デコード、ユーザープロファイル属性の取得を行います。 Lambda認可機能は、プリンシパル、アクション、リソース、ユーザープロファイル属性をエンティティとしてVerified Permissionsの認可APIに渡します。 Verified Permissionsによって返された判断に基づいて、リソースへのアクセスが承認または拒否されます。 エンタイトルメントサービスの一般的な落とし穴 エンタイトルメントサービスは複雑な場合がありますが、いくつかの共通のミスを避ければ、よりセキュアで使いやすいようにすることができます。 エンタイトルメントサービスの設定ミスはセキュリティ上の脆弱性を生み、データ漏洩を引き起こす可能性があります。エンタイトルメントサービスを慎重に設定し、ポリシーを定期的に見直して正しく最新の情報に更新されているか確認することが重要です。 ビジネスアプリケーションを初めて使用する時、ユーザーに過剰な承認を与えがちです。これはアプリケーションのセキュリティを低下させ管理を難しくします。ユーザーに必要最小限の承認のみを与えることが重要です。 特に承認の申請と管理に関わる場合には、ユーザーはエンタイトルメントサービスの正しい利用方法についてトレーニングを受ける必要があります。もしユーザーがこれらの作業を適切に行えない場合、システムの脆弱性の原因になる可能性があります。 結論 Amazon Verified Permissions は、きめ細かなアクセス制御、柔軟な認可、アプリケーション外部で一元化されたアクセス制御を管理したい企業向けの包括的なソリューションです。このサービスにより、組織は新しいポリシーを環境全体に迅速かつ便利に適用できるため、ユーザー管理プロセスが合理化され、全体的なセキュリティが向上します。この記事では、アプリケーション内の権限管理に Verified Permissions を使用することの多くの利点が強調されています。このサービスをビジネスユースケースにどのように適用できるかを理解するうえで参考になれば幸いです。 AWS セキュリティに関するニュースをもっと知りたいですか? X でフォローしてください。 翻訳はソリューションアーキテクトの高野が担当しました。原文は こちら です。
このブログ記事では、 AWS IAM Identity Center(AWS Single Sign-On の後継) を使用して、許可セットとアカウント割り当ての管理を委任する方法をご紹介します。日々のユーザーと権限の管理を委任することで、チームはより速く動き、中央集権的なアイデンティティ管理者の負担を軽減できます。 IAM Identity Centerは、安全にWorkforce Identityを作成または接続し、AWSアカウントとアプリケーションに渡るアクセスを一元的に管理することに役立ちます。Identity Centerでは、 AWS Organizationsによってマルチアカウントが管理されている 必要があります。Identity Centerの管理は、 メンバーアカウント(管理アカウント以外のアカウント)に委任 できます。 管理アカウントにアクセスできる人を制限 し、 管理アカウントの利用は管理アカウントが必要なタスクに限って使用する ことをおすすめします。 委任された管理は、このブログで取り上げている許可セットとアカウント割り当ての委任とは異なります。AWS IAM Identity Centerの委任管理についての詳細は、「 AWS IAM Identity Center委任管理の導入 」をご覧ください。このブログポストで説明する手法は、Identity Centerがメンバーアカウントに委任されているか、または管理アカウントに残っているかに関係なく機能します。 許可セット は、AWSアカウントに対するユーザーまたはグループのアクセスレベルを定義するために使用されます。許可セットには、 AWS管理ポリシー 、 カスタマー管理ポリシー 、 インラインポリシー 、および アクセス許可境界 が含まれる可能性があります。 ソリューションの概要 組織が成長するにつれて、許可管理とアカウント割り当ての権限をチームに委任して、チームの自律性を高め負担を減らすことを検討したいと考えるかもしれません。または、自分たちの 組織単位(OU) で運用している様々な社内ビジネスユニットや社外のユーザーが、自分たちのアイデンティティ管理をよりコントロールしたいと考えるかもしれません。 このシナリオでは、例として3つの開発チーム(レッド、ブルー、イエロー)を持つある組織を仮定します。各チームはそれぞれ自分たちのOUを運用しています。IAM Identity Centerは管理アカウントから管理用メンバーアカウントに委任されています。図1はこの例の組織構成を示しています。 図1:本ブログで仮定するシナリオの組織構造 このシナリオの組織には既にある許可セットのコレクションがあります。中央集権的なアイデンティティ管理チームから許可セットとアカウント割り当ての管理を委任したいと考えています。 レッドチームは、自分たちのOU内のアカウントに既存の許可セットを割り当てることができるようにしたいと考えています。これはアカウントベースのモデルです。 ブルーチームは、単一の許可セットを編集・使用し、その許可セットをチームの単一アカウントに割り当てたいと考えています。これは許可ベースのモデルです。 イエローチームは、「Team: Yellow」とタグ付けされた許可セットを作成、編集、使用し、その許可セットを自分たちの組織単位内の全アカウントに割り当てたいと考えています。これはタグベースのモデルです。 これら3つのユースケースの必要な許可セットを見ていきます。 注意 : AWS Management Console を使用している場合は、 追加の許可が必要 です。 ユースケース 1: アカウントベースのモデル このユースケースでは、レッドチームに対してOU内の3つのアカウントに既存の許可セットを割り当てる許可が与えられます。これにはアカウント割り当ての削除許可も含まれます。 このモデルを使用すると、組織は一般的な許可セットを作成し、AWSアカウントに割り当てることができます。これにより、管理者の複雑性が軽減され、組織のベストプラクティスに従う許可セットの使用状況が確認しやすくなります。これらの許可セットは、特定のリソースではなく、サービスと機能をベースにアクセスを制限します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:ProvisionPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>", "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/*", "arn:aws:sso:::account/112233445566", "arn:aws:sso:::account/223344556677", "arn:aws:sso:::account/334455667788" ] } ] } 上記のポリシーでは、プリンシパルはAWSアカウントIDが112233445566、223344556677、334455667788の3つのAWSアカウントに既存の許可セットを割り当てることができます。このポリシーには管理者向けの許可セットが含まれるため、どのアカウントに許可セットの割り当てるか十分に検討してください。 arn:aws:sso:::instance/ssoins-<sso-ins-id> はIAM Identity Center におけるインスタンスID の ARNです。 AWSコマンドラインインターフェイス(AWS CLI) v2  の  list-instances APIまたは AWS管理コンソール を使用して以下のように確認できます。 AWS CLI の使用 AWS コマンドラインインターフェイス (AWS CLI) を使用して以下のコマンドを実行してください: aws sso-admin list-instances AWS CloudShell を使用してコマンドを実行することもできます。 AWS マネジメントコンソールの使用 ご利用の AWS リージョンの管理コンソールを使用して、IAM Identity Center に移動し、ダッシュボード上の アイデンティティソースの確認 を選択してください。 図2: コンソール上のIAM Identity Center インスタンス ID ARN ユースケース 2: 権限ベースのモデル この例では、ブルーチームは1つまたは複数の特定の許可セットを編集する許可を与えられ、それらの許可セットを1つのアカウントに割り当てることができます。以下の許可は、チームがAWS管理ポリシー、カスタマー管理ポリシー、インラインポリシーを使用できるようにします。 このモデルでは、委任管理者が特定のAWSアカウント上のきめ細かなアクセス許可を使用できます。チームがAWSアカウント内へのアクセス許可を完全に管理したい場合、および管理ロールを作成する能力を持ちたい場合に有用です。このような場合、アカウントを操作するチームの方がサービスとワークロードの理解が深いため、アクセス許可は通常管理者よりもチームの方が実施しやすくなります。 アクセス許可の完全なコントロール権限を与えることは、意図しないまたは望ましくない結果につながる可能性があります。許可セットは IAMの評価と認証 の対象であるため、 サービスコントロールポリシー(SCP) により特定のアクションを拒否することができます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sso:AttachCustomerManagedPolicyReferenceToPermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:DeleteInlinePolicyFromPermissionSet", "sso:DetachCustomerManagedPolicyReferenceFromPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:ProvisionPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:UpdatePermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>", "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/ps-1122334455667788", "arn:aws:sso:::account/445566778899" ] } ] } ここでは、プリンシパルは許可セット arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/ps-1122334455667788 を編集し、AWS アカウント 445566778899 に割り当てることができます。編集権限には、お客様管理ポリシー、AWS 管理ポリシー、インラインポリシーが含まれます。 前述のポリシーを使用する際には、ご自身の IAM Identity Center インスタンス ID とアカウント番号で値を書き換えてください。 前述のポリシーでは、 arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/ps-1122334455667788 が許可セットの ARN です。この ARN はコンソールから、または以下の AWS CLI コマンドを使用してすべての許可セットをリストすることで見つけることができます。 aws sso-admin list-permission-sets —instance-arn <上記のインスタンス ARN> この許可セットも、最初のユースケースと同様に、アカウント ID のリストに追加のアカウント ID を追加することで、複数のアカウントに適用できます。同様に、許可セットを追加して、ユーザーが複数の許可セットを編集し、セットのアカウントに割り当てることができます。 ユースケース 3: タグベースのモデル この例では、イエローチームには「Team: Yellow」とタグ付けされた許可セットを作成、編集、使用する許可が与えられます。その後、それらのタグ付けされた許可セットをすべてのアカウントに割り当てることができます。 この例は、組織がチームに対して自由に許可セットを作成および編集し、チーム自身のアカウントに割り当てることを可能にします。タグは、どの許可セットを作成および編集できるかを制御するために使用されます。正しいタグが付いていない許可セットは変更できません。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sso:CreatePermissionSet", "sso:DescribePermissionSet", "sso:UpdatePermissionSet", "sso:DeletePermissionSet", "sso:DescribePermissionSetProvisioningStatus", "sso:DescribeAccountAssignmentCreationStatus", "sso:DescribeAccountAssignmentDeletionStatus", "sso:TagResource" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>" ] }, { "Effect": "Allow", "Action": [ "sso:DescribePermissionSet", "sso:UpdatePermissionSet", "sso:DeletePermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow" } } }, { "Effect": "Allow", "Action": [ "sso:CreatePermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:RequestTag/Team": "Yellow" } } }, { "Effect": "Allow", "Action": "sso:TagResource", "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow", "aws:RequestTag/Team": "Yellow" } } }, { "Effect": "Allow", "Action": [ "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:ProvisionPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>", "arn:aws:sso:::account/556677889900", "arn:aws:sso:::account/667788990011", "arn:aws:sso:::account/778899001122" ] }, { "Sid": "InlinePolicy", "Effect": "Allow", "Action": [ "sso:GetInlinePolicyForPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>" ] }, { "Sid": "InlinePolicyABAC", "Effect": "Allow", "Action": [ "sso:GetInlinePolicyForPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow" } } } ] } このポリシーでは、プリンシパルは Team: Yellow というタグがついた許可セットのみを作成することができ、Account ID 556677889900、667788990011、778899001122のAWSアカウントに対してそれらの  Team: Yellow でタグ付けされた許可セットを割り当てることができます。 プリンシパルは Team: Yellow でタグ付けされた許可セットのインラインポリシーのみを編集できます。他のチームのために既にタグ付けされた許可セットのタグを変更することはできません。 上記のポリシーを使用する際には、ご自身のIAM Identity CenterインスタンスID、タグ、アカウント番号に置き換えてください。 注意 :このポリシーは、プリンシパルに適用されるその他のステートメントがないことを前提としています。追加の許可ステートメントが必要な場合は、結果としてポリシーが権限昇格のリスクを生み出さないか確認してください。 タグを使用したAWSリソースへのアクセスの管理 についての追加情報を参照できます。 このポリシーでは、インラインポリシーを使用した許可設定の委任のみが許可されています。カスタマー管理ポリシーとは、各AWSアカウントに対して固有に払い出されたIAMポリシーのことです。許可セットでカスタマー管理ポリシーを使用する場合は、各AWSアカウントにおいて同じ名前およびパスのIAMポリシーを作成する必要があります。IAMポリシーが存在しない場合は、Identity Centerはアカウントへの割り当てを行いません。カスタマー管理ポリシーをIdentity Centerでどのように使用するかについては、 高度な AWS IAM Identity Center のユースケースに向けたカスタマー管理ポリシーの使用方法 を参照してください。 以下の2つのステートメントにより、上記のポリシーに対し、 カスタマー管理ポリシー の委任も許可するように拡張することもできます。 { "Sid": "CustomerManagedPolicy", "Effect": "Allow", "Action": [ "sso:ListCustomerManagedPolicyReferencesInPermissionSet", "sso:AttachCustomerManagedPolicyReferenceToPermissionSet", "sso:DetachCustomerManagedPolicyReferenceFromPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>" ] }, { "Sid": "CustomerManagedABAC", "Effect": "Allow", "Action": [ "sso:ListCustomerManagedPolicyReferencesInPermissionSet", "sso:AttachCustomerManagedPolicyReferenceToPermissionSet", "sso:DetachCustomerManagedPolicyReferenceFromPermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/*", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow" } } } 注意 : 上記ステートメントは両方の記載が必要です。なぜなら、タグによる条件キー aws:ResourceTag/${TagKey} には PermissionSet リソースタイプのみが対応しており、リストされているアクションは、インスタンスと PermissionSet リソースタイプの両方に対するアクセス権限が必要であるためです。詳細は  AWS IAM Identity Center のアクション、リソース、条件キー を参照してください。 ベストプラクティス 許可セットおよびアカウント割り当ての管理を委任する場合に考慮すべきベストプラクティスは以下の通りです。 特定の許可セットの編集権限のみを付与してください。すべての許可セットの編集権限を付与すると、そのロールは彼ら自身の許可セットも編集できてしまいます。 管理者のみがグループ管理を行えるようにしてください。グループ内ユーザーの編集権限を持つユーザーは、Organizations 管理者グループを含め自分を任意のグループに追加できてしまいます。 IAM Identity Center を委任アカウントで使用する場合は、 委任された管理のベストプラクティス も考慮してください。 まとめ 組織はIAM Identity Centerでの許可セットとアカウント割り当ての管理をチームに委任することで、チームに権限を与えることができます。これらのアクションの委任は、チームがより迅速に動くことに寄与し、また中央集権的なアイデンティティ管理チームの負担を軽減できます。このシナリオと例は、組織内で組み合わせて拡張できる委任概念を共有しています。 AWS セキュリティに関するニュースをもっと知りたいですか? X でフォローしてください。 翻訳はソリューションアーキテクトの高野が担当しました。原文は こちら です。
AWS Fault Injection Service (FIS) は 、Chaos Engineering を大規模に実践するのに役立ちます。11月30日、AWS アベイラビリティーゾーンで停電が発生したり、ある AWS リージョンから別の AWS リージョンへの接続が失われたりした場合に、アプリケーションが意図したとおりに動作することを実証できる新しい シナリオ を発表しました。 シナリオを使用して実験を行うことで、何か問題が発生したときにアプリケーション (単一リージョンかマルチリージョンかを問わず) が期待どおりに動作するという確信を築き、直接的および間接的な依存関係をよりより深く理解し、復旧時間をテストできます。アプリケーションを一定のペースでテストし、期待どおりに機能することを確認したら、実験の結果をコンプライアンスの目的で使用できます。 AWS Resilience Hub 、 の他の部分と組み合わせて使用すると、アプリケーションの全体的な 耐障害性体制 を完全に理解するのに役立ちます。 シナリオ入門 AWS アプリケーションで管理された実験を実施できるように、2021 年に FIS を立ち上げました。今回のリリースを発表するために 書いた私の投稿 では、実験テンプレートの作成方法と、それを使った実験方法を紹介しました。これらの実験は強力で低レベルのアクションを使用して構築されており、特定タイプの AWS リソースの指定されたグループに影響を与えます。例えば、次のアクションは EC2 インスタンスと Auto Scaling グループで動作します。 これらのアクションを構成要素として、私たちは最近 AWS FIS シナリオ ライブラリ を立ち上げました。ライブラリ内の各シナリオでは、アプリケーションの耐障害性をテストするために使用できるイベントまたは条件が定義されています。 各シナリオを使用して実験テンプレートを作成します。シナリオをそのまま使用することも、任意のテンプレートをベースに必要に応じてカスタマイズまたは拡張することもできます。 シナリオは、同じ AWS アカウントまたは他の AWS アカウントのリソースを対象にすることができます。 新しいシナリオ これらすべてを背景として、新しいシナリオを見てみましょう。 AZ 可用性: 停電 — このシナリオでは、EC2 インスタンス (EKS および ECS クラスター内のインスタンスを含む)、EBS ボリューム、Auto Scaling グループ、VPC サブネット、 Amazon ElastiCache for Redis クラスター、 Amazon Relational Database Service (RDS) クラスターなどを含む 1 つのアベイラビリティーゾーン内の対象となるリソースすべてで一時的に「プラグを抜く」ことになります。ほとんどの場合、複数のアベイラビリティーゾーンにリソースを持つアプリケーションで実行しますが、予想される結果として停電が発生するシングル AZ アプリケーションで実行することもできます。1 つの AZ を対象とし、実験中に指定した一連の IAM ロールまたは Auto Scaling グループが新しいインスタンスを起動したり、停止したインスタンスを起動したりできないようにすることもできます。 新しいアクションとターゲットエクスペリエンス により、シナリオ内のアクションとそれらが影響する AWS リソースの種類など、すべてを一目で簡単に確認できるようになります。 シナリオには、実験テンプレートのカスタマイズに使用されるパラメーターが含まれます。 詳細パラメータ — ターゲットタグ を使用すると、実験の対象となるリソースを見つけるために使用されるタグキーと値を制御できます。 クロスリージョン: 接続 — このシナリオでは、テストリージョンのアプリケーションがターゲットリージョンのリソースにアクセスできなくなります。これには、VPC にアタッチされた EC2 インスタンス、ECS タスク、EKS ポッド、および Lambda 関数からのトラフィックが含まれます。また、 Transit Gateway と VPC ピアリング 接続を経由するトラフィック、およびクロスリージョンの S3 と DynamoDB のレプリケーションも含まれます。このシナリオは、初期の状態で次のとおりです。 このシナリオは 3 時間実行され ( disruptionDuration パラメーターを変更しない限り)、指定された方法でテストリージョンをターゲットリージョンから分離します。詳細なパラメータを使用して、分離されたリージョン内の影響を受ける AWS リソースを選択するために使用されるタグを制御します。 また、このシナリオで使用されている 中断 アクションや 一時停止 アクションは、それだけでも役立つ場合があります。 例えば、 aws:s3:bucket-pause-replication アクションを使用して、リージョン内のレプリケーションを一時停止できます。 留意点 新しいシナリオについて知っておくべきことがいくつかあります。 リージョン — 新しいシナリオは、FIS が利用できるすべての商用 AWS リージョンで、追加費用なしで利用できます。 料金 — 実験の実行で消費されたアクション分に対してお支払いいただきます。詳細については、 AWS Fault Injection Service (FIS) の料金表ページをご覧ください。 サービス名 — このサービスは、以前は AWS Fault Injection Simulator と呼ばれていました。 – Jeff ; 原文は こちら です。
11月30日、 Amazon Route 53 Application Recovery Controller の新機能であるゾーン自動シフトを公開しました。これにより、AWS がそのアベイラビリティーゾーンに影響する潜在的な障害を特定したときに、ワークロードのトラフィックを アベイラビリティーゾーン から 自動的に かつ 安全に 移動し、障害が解決したら元のアベイラビリティーゾーンに復元できます。 耐障害性の高いアプリケーションのデプロイでは、通常、リソースをリージョンの複数のアベイラビリティーゾーンにデプロイします。アベイラビリティーゾーンとは、さまざまな電力、接続、ネットワークデバイス、および氾濫原管理を確保するために、通常数マイル離れた物理データセンターの個別のグループのことです。 デプロイの失敗、構成の誤り、オペレーターのミスなど、アプリケーションのエラーからユーザーを保護するために、当社では昨年、 手動またはプログラムでゾーンシフトをトリガーする機能 を導入しました。 これにより、あるアベイラビリティーゾーンでメトリクス値の低下が検出したときに、トラフィックをそのアベイラビリティーゾーンから遠ざけることができます。そのためには、すべての新しい接続を正常なアベイラビリティーゾーンのインフラストラクチャのみに転送するようにロードバランサーを設定します。これにより、障害の根本原因を調査する間、顧客はアプリケーションの利用を継続できます。障害が解消されたら、ゾーンシフトを停止して、トラフィックが再びすべてのゾーンに分散されるようにします。 ゾーンシフトは、NLB のデフォルトである クロスゾーン負荷分散 が無効になっている場合にのみ、 Application Load Balancer (ALB) または Network Load Balancer (NLB) レベルで機能します。簡単に言うと、ロードバランサーには 2 つのレベルの負荷分散があります。最初のレベルは DNS で設定されます。ロードバランサーはアベイラビリティーゾーンごとに 1 つ以上の IP アドレスを公開し、ゾーン間のクライアント側の負荷分散を実現します。トラフィックがアベイラビリティーゾーンに到達すると、ロードバランサーは登録された正常なターゲット (通常は Amazon Elastic Compute Cloud (Amazon EC2) インスタンス) にトラフィックを送信します。デフォルトでは、ALB はすべてのアベイラビリティーゾーンのターゲットにトラフィックを送信します。ゾーンシフトを正しく機能させるには、クロスゾーン負荷分散を無効にするようにロードバランサーを設定する必要があります。 ゾーンシフトが始まると、次の図に示すように、DNS はすべてのトラフィックをあるアベイラビリティーゾーンから遠ざけます。 手動によるゾーンシフトは、ユーザー側で発生したエラーからワークロードを保護するのに役立ちます。しかし、アベイラビリティーゾーンで障害が発生した可能性がある場合、障害の特定や検出が困難な場合があります。ほとんどの場合、アベイラビリティーゾーンごとにメトリクスを追跡することはないため、アプリケーションメトリックスを使用してアベイラビリティーゾーンの問題を検出することは困難です。さらに、サービスがアベイラビリティーゾーンの境界を越えて依存関係を呼び出すことが多く、その結果、すべてのアベイラビリティーゾーンでエラーが発生してしまいます。最新のマイクロサービスアーキテクチャでは、これらの検出と復旧の手順を数十または数百の個別のマイクロサービスで実行しなければならないことが多く、復旧に数時間かかってしまいます。 お客様から、アベイラビリティーゾーンで発生した可能性のある障害を特定する負担を軽減できないかと問い合わせがありました。結局のところ、当社が内部のモニタリングツールを使用すれば、潜在的な問題についてお客様より先に検出できる可能性があります。 今回のリリースにより、アベイラビリティーゾーンで発生する可能性のある障害からワークロードを保護する ゾーン自動シフト を設定できるようになりました。当社では、ネットワークトラフィックのシフトをいつトリガーするかを決定するために、独自の AWS 内部モニタリングツールとメトリクスを利用します。シフトは自動的に開始され、API を呼び出す必要はありません。ゾーンに電源障害やネットワーク障害などの潜在的な障害が発生していることが検出されると、インフラストラクチャの NLB または ALB トラフィックの自動シフトが自動的にトリガーされ、障害が解決された時点でトラフィックを元に戻します。 言うまでもなく、トラフィックをアベイラビリティーゾーンから遠ざけることはデリケートなオペレーションであり、慎重に準備する必要があります。アプリケーションの可用性を誤って低下させないように、一連の保護手段を構築しました。 まず、トラフィックを一度に複数のアベイラビリティーゾーンから移動させないようにするための内部制御が必要です。次に、毎週 30 分間、インフラストラクチャの移行を演習します。例えば、月曜日から金曜日の 08:00~18:00 など、演習をブロックする時間帯を定義できます。3 つ目は、演習実行中の サーキットブレーカー として機能する 2 つの Amazon CloudWatch アラームを定義することです。一方は演習の実行をまったく開始しないようにするアラーム、他方は演習実行中のアプリケーションの状態をモニタリングするアラームです。演習中にどちらかのアラームがトリガーされると、停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。演習実行終了時のアプリケーションヘルスアラームの状態は、実行の結果 (成功または失敗) を示します。 責任共有の原則 によれば、2 つの責任があります。 まず、すべてのアベイラビリティーゾーンに十分な容量がデプロイされていることを確認して、トラフィックが移動した後に残りのアベイラビリティーゾーンのトラフィックが増加しても対応できるようにする必要があります。残りのアベイラビリティーゾーンには常に十分な容量を確保し、アプリケーションの復旧を遅らせたり可用性に影響を与えたりする可能性のあるスケーリングメカニズムに依存しないことを強くお勧めします。ゾーン自動シフトがトリガーされると、 AWS Auto Scaling はリソースをスケーリングするのに通常よりも時間がかかる場合があります。リソースを事前にスケーリングすることで、最も要求の厳しいアプリケーションの復旧時間を予測できます。 通常のユーザートラフィックを吸収するために、アプリケーションが 3 つのアベイラビリティーゾーンに 6 つの EC2 インスタンス (2×3 インスタンス) を必要とするとします。ゾーン自動シフトを設定する前に、1 つのアベイラビリティーゾーンが利用できない場合にトラフィックを吸収するのに十分な容量が残りのアベイラビリティーゾーンにあることを確認する必要があります。この例では、1 つのアベイラビリティーゾーンにつき 3 つのインスタンス (トラフィックが 2 つのアベイラビリティーゾーンに移動されたときに 2×3 = 6 つのインスタンスを維持して負荷分散する必要があるため、3 つのアベイラビリティーゾーンに 3×3 = 9 つのインスタンスが必要) という意味です。 実際には、高い信頼性が求められるサービスを運用する場合、顧客による負荷の急上昇や時折のホスト障害などの不測の事態に備えて、ある程度の冗長容量をオンラインで運用するのが一般的です。この方法で既存の冗長性を満たすことで、アベイラビリティーゾーンの問題が発生したときに迅速に復旧できるだけでなく、他のイベントに対する堅牢性も高まります。 次に、選択したリソースのゾーン自動シフトを明示的に有効にする必要があります。AWS は、選択したリソースにのみゾーン自動シフトを適用します。ゾーン自動シフトを適用すると、アプリケーションに割り当てられる合計容量に影響します。先ほど説明したように、残りのアベイラビリティーゾーンに十分な容量をデプロイして、アプリケーションを準備する必要があります。 もちろん、この追加容量をすべてのアベイラビリティーゾーンにデプロイすることにはコストがかかります。耐障害性について話すとき、アプリケーションの可用性とコストのどちらを決めるかというビジネス上のトレードオフがあることを説明します。これが、選択したリソースにのみゾーン自動シフトを適用するもう 1 つの理由です。 ゾーン自動シフトの設定方法を見てみましょう ゾーン自動シフトの設定方法を示すために、今や有名になった TicTacToe ウェブアプリケーションを CDK スクリプトを使ってデプロイします。 AWS マネジメントコンソール の [Route 53 Application Recovery Controller] ページを開きます。左側のペインで、 [ゾーン自動シフト] を選択します。次に、ウェルカムページで、 [リソースのゾーン自動シフトを設定] を選択します。 デモアプリケーションのロードバランサーを選択します。現在のところクロスゾーン負荷分散が無効になっているロードバランサーのみがゾーン自動シフトの対象であるということに注意してください。コンソールの警告からもわかるように、アベイラビリティーゾーンが 1 つ失われても動作を継続するのに十分な容量がアプリケーションにあることも確認しています。 ページを下にスクロールして、AWS に 30 分間の演習を実行させたくない時間と曜日を設定します。最初は、自動シフトに慣れるまで、月曜日から金曜日の 08:00〜18:00 は演習をブロックします。時刻は UTC で表示され、 夏時間 は適用されないことに注意してください。 UTC 時間変換アプリケーション を使用すると便利です。最初は営業時間を外して問題ありませんが、アプリケーションのトラフィックが少ないときやまったくない場合には表示されない可能性がある問題を確実にキャプチャできるように、営業時間中にも演習を実行するように設定することをお勧めします。ピーク時に衝撃を与えずに機能させるには、おそらくゾーン自動シフトが最も必要ですが、テストしたことがない場合は、どの程度自信がありますか? 常時ブロックしないのが理想ですが、それが常に現実的であるとは限らないことを私たちは認識しています。 同じページのさらに下にある 2 つのサーキットブレーカーアラームを入力します。最初のものは演習の開始を妨げます。このアラームを使って、今は演習を始めるのに良いタイミングではないと示します。例えば、アプリケーションで現在問題が発生している場合や、アプリケーションの新しいバージョンを本番環境にデプロイする場合などです。2 番目の CloudWatch アラームは、演習実行の結果を示します。これにより、ゾーン自動シフトにより、アプリケーションが演習実行にどのように反応しているかを判断できます。アラームが緑色のままであれば、すべてがうまくいったことがわかります。 演習中にこれら 2 つのアラームのいずれかがトリガーされると、ゾーン自動シフトは演習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。 最後に、30 分間の演習実行が毎週実行され、アプリケーションの可用性が低下する場合があることを認めます。 その後、 [Create] を選択します。 それだけです。 数日後、コンソールの [リソースのゾーンシフト履歴] タブに演習実行の履歴が表示されます。2 つのサーキットブレーカーアラームの履歴をモニタリングして、すべてが正しくモニタリングされ、設定されていることを確認しています。 自動シフト自体をテストすることはできません。アベイラビリティーゾーンで潜在的な問題を検出すると、自動的にトリガーされます。この記事で共有した手順をテストするためにアベイラビリティーゾーンをシャットダウンできるかどうかサービスチームに尋ねたところ、丁寧に断られました。 自動シフトと同じように動作する手動シフトをトリガーすれば、設定のテストができます。 さらに押さえておくべきこと ゾーン自動シフトは、中国と GovCloud を除くすべての AWS リージョンで追加料金なしで利用できるようになりました。 クロール、ウォーク、ラン方式の適用をお勧めします。まず、手動のゾーンシフトから始め、アプリケーションに対する信頼性を確立します。次に、営業時間外に演習実行を設定したゾーン自動シフトを有効にします。最後に、営業時間中のゾーンシフトの演習を含めるようにスケジュールを変更します。イベントが発生したくないときに、イベントに対するアプリケーションの応答をテストしたいと考えています。 また、トラフィックを 1 つのアベイラビリティーゾーンから別のアベイラビリティーゾーンに戻したときに、アプリケーションのすべての部分がどのように復旧するかを総合的に考えることをお勧めします。私が思いつくリスト (完全なものではありませんが) は次のようなものです。 まず、すでに説明したように、容量増加の計画を立てます。次に、各アベイラビリティーゾーンで発生する可能性のある単一障害点について考えてみましょう。例えば、単一の EC2 インスタンスで実行される自己管理型データベースや、1 つのアベイラビリティーゾーンに存在するマイクロサービスなどです。ゾーンシフトを必要とするアプリケーションには、 Amazon DynamoDB や Amazon Aurora などのマネージドデータベースを使用することを強くお勧めします。これらには、レプリケーションとフェイルオーバーのメカニズムが組み込まれています。3 番目に、アベイラビリティーゾーンが再び利用可能になったときに切り替える計画を立ててください。リソースのスケーリングにはどの程度の時間が必要ですか? キャッシュをリハイドレートする必要がありますか? 耐障害性の高いアーキテクチャと方法論について詳しくは、 同僚の Adrian が執筆したこの素晴らしい記事シリーズ をご覧ください。 最後に、現在ゾーン自動シフトの対象となるのは、クロスゾーン負荷分散が無効になっているロードバランサーのみであることに注意してください。CDK スクリプトからクロスゾーン負荷分散を無効にするには、 stickinessCookieDuration を削除し、ターゲットグループに load_balancing.cross_zone.enabled=false を追加する必要があります。CDK とタイプスクリプトを使った例を以下に示します。 // 負荷分散として Auto Scaling グループを追加します // リスナーをターゲットにします。 const targetGroup = listener.addTargets('MyApplicationFleet', { port: 8080, // ゾーンシフトでは、維持設定とクロスゾーンの負荷分散を無効にする必要があります // stickinessCookieDuration: Duration.hours(1), targets: [asg] }); // クロスゾーン負荷分散を無効にする targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false"); 次は、ゾーン自動シフトのメリットが得られるアプリケーションを選択します。まず、各アベイラビリティーゾーンのインフラストラクチャ容量を確認してから、サーキットブレーカーアラームを定義します。モニタリングが正しく設定されていることを確認したら、 ゾーン自動シフトを有効にしてください 。 — seb 原文は こちら です。
11月30日は、 AWS Application Composer の統合開発環境 (IDE) 拡張機能についてお話しできることを嬉しく思います。AWS Application Composer を IDE で直接使用して、最新のアプリケーションを視覚的に構築したり、 Amazon CodeWhisperer を使用してインフラストラクチャをコードテンプレートとして反復的に開発したりすることができます。 AWS re:Invent 2022 でプレビュー版として発表され、 2023 年 3 月 に一般公開される Application Composer は、ビジュアルキャンバス上で AWS サービスをドラッグ、グループ化、接続することで、デベロッパーがアプリケーションアーキテクチャを簡単に視覚化、設計、反復できるようにするビジュアルビルダーです。Application Composer は、使いやすい視覚的なドラッグアンドドロップインターフェイスを提供し、IaC テンプレートをリアルタイムで生成することで、最新のアプリケーションの構築を簡素化します。 AWS Application Composer では、AWS CloudFormation リソースを使用することもできます。9 月、 AWS Application Composer が 1000 以上の AWS CloudFormation リソースのサポートを開始しました 。これにより、AWS リソースの設定をきめ細かなレベルで柔軟に定義できます。 最新のツールを利用したモダンアプリケーションの構築 AWS Application Composer の IDE 拡張により、コンソールで提供されているのと同様の視覚的なドラッグアンドドロップ操作と機能性が提供されます。IDE のビジュアルキャンバスを利用することで、プロトタイプでアイデアをすばやく試作し、アプリケーションコードに注力できます。 また、IDE で Application Composer を実行すると、IDE のさまざまなツールを利用できるようになります。例えば、Application Composer によってリアルタイムで生成された IaC テンプレートを  AWS Serverless Application Model (AWS SAM) とシームレスに統合して、サーバーレスアプリケーションを管理およびデプロイできます。 Application Composer を IDE で使用できるようにするだけでなく、アプリケーションアーキテクチャを分割ビューで視覚化しながら、CloudFormation テンプレートで生成系 AI を活用したコード提案をリアルタイムで生成できるようになります。Application Composer の視覚化と CloudFormation テンプレートの編集を IDE で組み合わせて同期させることで、コンソール間でコンテキストを切り替えて設計を繰り返す必要がありません。これにより、手動コーディングは最小限になり、生産性は向上します。 Visual Studio コードで AWS Application Composer を使用する まず、最新の AWS Toolkit for Visual Studio Code プラグインをインストールする必要があります。AWS Toolkit プラグインが既にインストールされている場合は、プラグインを更新するだけで Application Composer の使用を開始できます。 Application Composer を使い始めるのに、自分の AWS アカウントで認証を受ける必要はありません。 IDE で Application Composer を利用できるようになったので、既存の AWS CloudFormation テンプレートや AWS SAM テンプレートを開くことができます。 もう 1 つの方法は、新しい空白のファイルを作成し、そのファイルを右クリックして [Application Composer で開く] を選択して、アプリケーションの視覚的な設計を開始することです。 これで空のキャンバスができあがります。ここでは、 Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB を使用してシンプルなサーバーレス API を構築するためのコードとビジュアルエディターの両方を同時に使用しています。キャンバスで行った変更は、IaC テンプレートにもリアルタイムで反映されます。 Application Composer コンソールを使用するときなど、一貫したエクスペリエンスが得られます。例えば、AWS Lambda 関数に何らかの変更を加えると、ローカルフォルダに関連ファイルも作成されます。 ローカルフォルダに IaC テンプレートがあるので、AWS SAM CLI でアプリケーションを管理するのが簡単になりました。 sam パイプライン で継続的インテグレーションと継続的デリバリー (CI/CD) を作成することも、 sam デプロイ でスタックをデプロイすることもできます。 私の開発ワークフローを加速する機能の 1 つは、AWS SAM コマンド sam sync とシームレスに統合する組み込みの Sync 機能です。この機能は、ローカルアプリケーションの変更を私の AWS アカウントに同期します。これは、アプリケーションを本番環境にデプロイする前にテストと検証を行うのに役立ちます。 生成系 AI による IaC テンプレートの開発 この新機能では、生成系 AI コードの提案を利用すれば、CloudFormation の 1000 以上のリソースのいずれかをすばやく使い始めることができます。 つまり、標準の IaC リソースを組み込んでアーキテクチャを拡張するのがさらに簡単になりました。 例えば、標準の IaC リソースである Amazon MQ を使用する必要があり、アプリケーションコンポーザーを使用して AWS CloudFormation リソースの一部の設定を変更する必要があります。 [リソース設定] セクションで、必要に応じていくつかの値を変更し、 [生成] を選択します。Application Composer によるコードの提案を受け入れて IaC テンプレートに組み込むことができます。 この機能は、コンテキストの切り替えをなくしたことで開発のスピードアップを促進さます。AWS Application Composer キャンバスを使用して最新のアプリケーションを設計し、Amazon CodeWhisperer や AWS SAM などのさまざまなツールを使用して開発ワークフローを加速できます。 留意点 ここで、留意すべきことがいくつかあります。 IDE のサポート — このリリースで、この新機能を Visual Studio Code で利用できるようになりました。 価格 — AWS Application Composer の IDE 拡張は無償でご利用いただけます。 最新の AWS Toolkit for Visual Studio Code をインストールして、AWS Application Composer の IDE 拡張機能を使い始めましょう。 コーディングをお楽しみください! –  Donnie 原文は こちら です。
11月30日、 Amazon SageMaker Studio のエクスペリエンスが改善されたことをお知らせします。 新しい SageMaker Studio の Web ベースのインターフェイスは読み込みが速くなり、IDE の種類に関係なく、お好みの統合開発環境 (IDE) や SageMaker リソースやツールに一貫してアクセスできます。JupyterLab と RStudio に加えて、SageMaker Studio には Code-OSS (Visual Studio コードオープンソース) をベースにしたフルマネージド型のコードエディターが含まれるようになりました。 コードエディターと JupyterLab はどちらも、柔軟なワークスペースを使用して起動できます。スペースを使用すると、IDE のコンピューティングとストレージを必要に応じてスケールアップまたはスケールダウンしたり、ランタイム環境をカスタマイズしたり、いつでもどこからでもコーディングを一時停止して再開したりできます。このようなスペースを複数スピンアップし、それぞれがコンピューティング、ストレージ、ランタイムの異なる組み合わせで構成できます。 また、SageMaker Studio には、個人ユーザーと企業管理者の両方が数分で使い始めることができるように、オンボーディングと管理機能が合理化されています。これらのハイライトのいくつかを簡単に紹介しましょう。 SageMaker Studio の新しいウェブベースのインターフェイス 新しい SageMaker Studio の Web ベースのインターフェイスは、お好みの IDE を起動したり、SageMaker ツールにアクセスしてモデルを構築、トレーニング、チューニング、デプロイしたりするためのコマンドセンターとして機能します。SageMaker Studio で SageMaker のトレーニングジョブとエンドポイントを表示したり、 SageMaker JumpStart を介して基盤モデル (FM) にアクセスしたりできるようになりました。また、SageMaker Studio を手動でアップグレードする必要もなくなりました。 Code-OSS (Visual Studio コードオープンソース) に基づく新しいコードエディター データサイエンティストまたは機械学習 (ML) の実践者は、SageMaker Studio にサインインして、ブラウザから直接コードエディターを起動できるようになりました。コードエディターを使用すると、 Open VSX レジストリから何千もの VS Code 互換の拡張機能にアクセスでき、AWS でアプリケーションを開発およびデプロイするための事前設定された AWS toolkit for Visual Studio Code にもアクセスできます。また、 Amazon CodeWhisperer と Amazon CodeGuru が提供する人工知能 (AI) 搭載のコーディングコンパニオンおよびセキュリティスキャンツールを使用することもできます。 コードエディターと JupyterLab を柔軟なワークスペースで起動 スペースを作成するユーザーのみがアクセスできるプライベートスペースを使用して、コードエディターと JupyterLab の両方を起動できます。この柔軟なワークスペースは、より高速で効率的なコーディング環境を提供するように設計されています。 スペースには、一般的な ML フレームワークと Python パッケージを含む SageMaker ディストリビューションがあらかじめ設定されています。AI 搭載のコーディングコンパニオンとセキュリティツールを使用すると、コードの生成、デバッグ、説明、リファクタリングをすばやく行うことができます。 さらに、SageMaker Studio ではコラボレーションエクスペリエンスが向上しています。ビルトインの Git 統合を使用してコードの共有とバージョン管理を行ったり、 Amazon EFS を使用して独自の共有ファイルストレージを持ち込んだりして、さまざまなユーザーやチーム間で共同ファイルシステムにアクセスできます。 ユーザーのオンボーディングと管理の効率化 再設計されたセットアップとオンボーディングのワークフローにより、SageMaker Studio ドメインを数分でセットアップできるようになりました。 個人ユーザーは、ドメインや AWS IAM ロールについて学ぶことなく、ワンクリックでデフォルトのプリセットを使用して SageMaker Studio を起動できるようになりました。 企業管理者は、手順を追って説明することで、適切な認証方法の選択、サードパーティの ID プロバイダーへの接続、ネットワークとセキュリティ構成の統合、きめ細かなアクセスポリシーの設定、SageMaker Studio で有効にする適切なアプリケーションの選択などに役立ちます。また、設定はいつでも更新できます。 はじめに、 SageMaker コンソールに移動し 、[ 単一ユーザー向けにセットアップ] または [ 組織向けにセットアップ ] を選択します。 シングルユーザーセットアップでは、デフォルトのプリセットを使用して SageMaker Studio ドメインのデプロイが開始され、数分以内に準備が整います。組織向けのセットアップでは、構成を段階的に説明します。ただし、従来の SageMaker Studio エクスペリエンスで作業を続けるか、新しいエクスペリエンスの探索を開始するかを選択できることに注意してください。 今すぐご利用いただけます Amazon SageMaker Studio の新しいエクスペリエンスは、SageMaker Studio が利用可能なすべての AWS リージョンで本日ご利用いただけます。本日より、新しい SageMaker Studio ドメインはデフォルトで新しい Web ベースのインターフェースになります。既存のセットアップがあり、新しいエクスペリエンスを使い始めたい場合は、SageMaker デベロッパーガイドで既存のドメインを移行する方法を確認してください。 ぜひお試しいただき、ご意見をお聞かせください。 フィードバックは、 AWS re:Post for Amazon SageMaker Studio にご送信いただくか、または通常の AWS の担当者を通じてお寄せください。 Amazon SageMaker Studio で、ML プロジェクトの構築を今すぐ始めましょう! –  Antje 原文は こちら です。
はじめに AWS IoT SiteWise アプリケーションをスケーリングして本番環境に移行する際には、開発環境と QA 環境を本番環境から分離する一般的な CI/CD を採用することを検討します。この分離により、デプロイパイプラインを通じてこれらのアプリケーションのデプロイを自動化できます。また、共通のアセットモデルや階層を持つ複数の事業部門や産業拠点があり、それらを組織全体で共有して再利用したい場合もあります。このような場合、顧客は通常、開発環境と本番環境間あるいは異なる事業部門間において、別々の環境に異なる AWS アカウントを持っています。次の図は、開発環境が QA 環境や本番環境から切り離されている例を示しています。 AWS IoT SiteWise のリソースを環境間で複製できるようにするために、 AWS IoT SiteWise ツール を作成しました。これは AWS IoT SiteWise のアセットモデル、アセット 、 AWS IoT SiteWise モニターダッシュボード を AWS CloudFormation テンプレート にエクスポートできるユーティリティセットです。エクスポートされたテンプレートを使用して、リソースを別の AWS 環境に再作成できます。このブログでは、AWS IoT SiteWise ツールを使用してモデルをエクスポートするサンプルの手順と、CI/CD パイプラインでエクスポートと複製のプロセスを自動化するためのサンプルアーキテクチャを紹介します。 アセットモデルエクスポートの概要 AWS IoT SiteWise ツールリポジトリのユーティリティは、特定のユースケースに必要なリソースのみを複製する柔軟性を提供します。 AWS IoT SiteWise アセットモデルのみをエクスポートするか、対応するアセットと AWS IoT SiteWise モニターダッシュボードもエクスポートするかを選択できます。 エクスポートツールは、コマンドラインから手動で使用できます (例: アセットモデルを別の環境に 1 回限りエクスポートする場合など) 。また、CI/CD デプロイシナリオの自動化パイプラインに統合することもできます。 このユーティリティは、同じアカウント内のマルチリージョンデプロイの AWS IoT SiteWise リソースをコピーするためにも使用できます。 AWS IoT SiteWise ツールリポジトリには、各ユーティリティの使用方法が詳細にドキュメント化されていますが、ツールの基本的なデモンストレーションとして、以下のように CNC マシン と 生産ライン の 2 つのアセットモデルを作成しました。 各モデルには、プロパティと 2 つのモデル間の階層関係が含まれています。 簡単にするために、モデルのみをエクスポートします。AWS IoT SiteWise エクスポートツールを使用して、オプションでエクスポートするリージョンを指定し、他のフラグを付けずにコマンドを実行します (アセットもモデルとともにエクスポートする場合は、単純に -a、—assets フラグを追加します)。 コマンドの出力は次のようになります。 コマンドが成功すると、CloudFormation テンプレートがローカルディレクトリ内の cfnexport というフォルダに保存されます。 例の場合、CloudFormation は次のようになります: { "AWSTemplateFormatVersion": "2010-09-09", "Description": "SiteWise Export", "Resources": { "CNCMachineResource": { "Type": "AWS::IoTSiteWise::AssetModel", "Properties": { "AssetModelName": "CNC Machine", "AssetModelProperties": [ { "Name": "SpindleSpeed", "DataType": "DOUBLE", "Unit": "RPM", "Type": { "TypeName": "Measurement" }, "LogicalId": "SpindleSpeed9f2e03dd" } ], "AssetModelHierarchies": [] } }, "ProductionLineResource": { "Type": "AWS::IoTSiteWise::AssetModel", "Properties": { "AssetModelName": "Production Line", "AssetModelProperties": [ { "Name": "Location", "DataType": "STRING", "Type": { "TypeName": "Attribute", "Attribute": {} }, "LogicalId": "Locationafc85231" } ], "AssetModelHierarchies": [ { "Name": "CNC Machines", "ChildAssetModelId": { "Ref": "CNCMachineResource" }, "LogicalId": "CNCMachines" } ] } } } } JSON この CloudFormation テンプレートを別のリージョンまたは別の AWS アカウントで展開して、上記で定義したのと同じアセットモデルを作成できます。 以上で、エクスポートユーティリティの仕組みを理解できました。次のセクションでは、ユーティリティを CI/CD パイプラインに統合するアーキテクチャの例を紹介します。 CI/CD アーキテクチャ例 このサンプルアーキテクチャでは、CloudFormation と AWS SDK を使用して AWS サービスをデプロイできる既存の CI/CD パイプラインがあることを前提としています。 ビルド アーキテクチャの構築段階では、CI/CD パイプラインがソース環境で Step Functions ワークフローを開始します。このワークフローでは、アセットモデル、アセット、ダッシュボードなどのリソースタイプごとに 1 つずつ、合計 3 つの Lambda 関数が実行されます。Lambda 関数を並行して実行し、エクスポートユーティリティを使用して AWS IoT SiteWise サービス API にクエリを実行し、複製するリソースに対応する CloudFormation テンプレートを生成できます。その後、Lambda 関数は生成されたファイルを Amazon S3 バケットに保存し、パイプラインのデプロイ段階で使用できるようにします。S3 バケットでは、すべての AWS 環境で共通の 共有バケット を使用するか、S3 レプリケーションを使用して 各環境ごとのバケット間 でファイルを自動的にコピーできます。 デプロイ デプロイ段階では、AWS IoT SiteWise リソースをターゲット環境で特定の順序 (アセットモデル、アセット、ダッシュボードの順) で作成または変更する必要があります。そのためには、 AWS Step Functions ワークフロー の状態をリソースタイプごとに定義し、適切な順序で実行するようにワークフローを設定します。各ワークフローのステートは、S3 内の対応する CloudFormation テンプレートを参照する Lambda 関数タスクを呼び出します。リソースはまず CI/CD パイプラインで作成する必要があるため、最初のワークフローデプロイタスクで CloudFormation スタックが作成されます。 スタックが作成されると、それ以降の CI/CD パイプラインからの更新では、ワークフローと AWS Step Functions を使用してそれらのスタックが更新され、AWS IoT SiteWise リソースが変更および更新されます。アセットとダッシュボードの状態は、前の状態が CloudFormation へのデプロイを完了するまで待ってから開始します。これは、リソースを作成する前にリソースが存在する必要があるためです。アーキテクチャ図は以下のようになります。 本番環境のワークロードでは、お客様はデプロイパイプラインで CloudFormation の 変更セット を使用し、CloudFormation の更新が行われる前に手動の承認ゲートをセットして確認ができます。ダッシュボードがプラインでのデプロイ対象である場合は、ターゲット環境内に AWS IoT SiteWise Monitor ポータルをあらかじめ作成しておく必要があります。 まとめ このブログ記事では、AWS IoT SiteWise リソースを AWS 環境間で複製するための AWS IoT SiteWise ツール を紹介し、それらをデプロイパイプラインに統合するアーキテクチャ例を示しました。IT インフラストラクチャとアプリケーションのデプロイに関しては、組織ごとに要件、手順、ツールが異なります。そのため、お客様の要件に合わせてアーキテクチャを柔軟に調整し、特定の自動化パイプラインに統合できるようにツールを設計しました。こちらのツールの改善や追加のために、お気軽に リポジトリ にプルリクエストを送信してください。 About the Authors Sebastian Salomon は、AWS のシニア IoT データアーキテクトです。IIoT、自動車、O&G、スマートホーム、スマートシティ、マイニング、データウェアハウス、ビッグデータプラットフォームなど、さまざまな分野の IoT アーキテクチャで 7 年以上の経験があります。最近では、スケーラブルな MLOps プラットフォームを通じて AI を IoT に取り込む活動に注力しています。AWS プロフェッショナルサービスのメンバーとして、さまざまな規模や業界のお客様と協力して、さまざまなエンドツーエンドの IoT ソリューションを設計および実装しています。 Ashok Padmanabhan は、製造分野におけるビッグデータ分析とインダストリー 4.0 ソリューションに焦点を当てた AWS プロフェッショナルサービスのシニア IoT データアーキテクトです。 Mihai Lucaciu は、16 年以上の経験を持つ AWS プロフェッショナルサービスのシニア IoT データアーキテクトとして、産業データ、エッジ分析、クラウドサービスに関するさまざまなプロジェクトのソリューションアーキテクチャ、設計、実装でお客様を支援しています。 Tim Wilson は、AWS の公共部門パートナー組織の IoT 支援スペシャリストです。AWS 公共部門のパートナーと協力して、彼らの AWS IoT サービスとソリューションの運用と活用をサポートしています。AWS の公共部門事業が比較的小規模だった 2012 年に、ソリューションアーキテクトとして AWS に入社しました。また、AWS で IoT プロトタイピングラボを管理したり、AWS エグゼクティブブリーフィングセンターでテクニカルプレゼンターを務めたこともあります。 この記事は Sebastian Salomon, Ashok Padmanabhan, Mihai Lucaciu, Tim Wilson によって書かれた How to replicate AWS IoT SiteWise resources across environments の日本語訳です。この記事は Solutions Architect の 西亀真之 が翻訳しました。
クリックストリームデータとは、ユーザーと Web サイトまたはモバイルアプリケーションとの間で発生するデジタルインタラクションを収集したものです。リアルタイムにユーザーデータを収集し有用なインサイトを作成することは困難な場合があります。アマゾン ウェブ サービス(AWS)のサーバーレスサービスは、クリックストリームデータをシームレスにキャプチャ、処理、視覚化し、分析基盤に取り込むためのスケーラブルなアーキテクチャを提供するために役立ちます。 ユーザーインタラクションには、リンクやボタンのクリック、さまざまなページの表示、特定のページの閲覧時間、フォームの送信、ファイルのダウンロード、その他デジタル環境で行われるさまざまなアクティビティなど、さまざまなアクションが含まれます。クリックストリームデータが組織にとって重要である理由については、「 クリックストリームデータによるビジネス成果の促進 」を参照してください。 本ブログでは、AWS のサービスによって、サーバーのプロビジョニングや管理を必要とせずにクリックストリームデータを簡単に収集して処理する方法について詳しく見ていきます。 アーキテクチャ このソリューションでは、 Amazon API Gateway 、 AWS Lambda 、 Amazon Kinesis データストリームを使用してクリックストリームデータを取り込んで処理し、Amazon Kinesis Data Firehose を使用して未加工データをアマゾンシンプルストレージサービス (Amazon S3) に保存し、次に Amazon Athena と Amazon QuickSight を使用してユーザーフレンドリーな方法でデータを分析および視覚化します。 サービス選定理由 クリックストリームデータは、ユーザーのトラフィックと行動に応じて非常に変動しやすく、大量のメッセージとして継続的にストリーミングされます。新しいアプリケーション機能、 Web サイトのレイアウト、またはマーケティングキャンペーンのパフォーマンスを評価する場合、迅速なアクションを可能にするためにそれらをリアルタイムで分析することが重要です。 このアーキテクチャ用に選択された AWS サービスは、クリックストリームデータを処理するための自動スケーリング機能と費用対効果の高いソリューションを提供します。これらのサービスは、入ってくるワークロードの変動に対応するようにリソースを動的にスケーリングし、ほぼリアルタイムの処理と分析を保証します。従量課金制の価格モデルでは、使用したリソースに対してのみ支払いが発生するため、過剰なインフラを用意しておく必要がなくなり、コストを最小限に抑えることができます。 Amazon API Gateway は、開発者があらゆる規模の API を簡単に作成、公開、保守、監視、保護できるようにする完全マネージド型サービスです。 AWS Lambda はサーバーレスのイベント駆動型コンピューティングサービスで、サーバーのプロビジョニングや管理を行わずに、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。Lambda は 200 以上の AWS サービスと Software-as-a-Service (SaaS) アプリケーションからトリガーできます。支払いは使用した分だけです。 Amazon Kinesis Data Streams は、あらゆる規模のデータストリームの収集、処理、保存を容易にするサーバーレスのストリーミングデータサービスです。 Amazon Kinesis Data Firehose は、ストリーミングデータを確実に収集、変換し、データレイク、データストア、分析サービスに配信する抽出、変換、ロード (ETL) サービスです。 Amazon S3 は、業界トップクラスのスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。あらゆる規模と業種のお客様が、データレイク、クラウドネイティブアプリケーション、モバイルアプリなど、ほぼすべてのユースケースで任意の量のデータを保存および保護できます。 Amazon Athena では、場所を問わずペタバイト単位のデータを簡単に柔軟に分析できます。Athena を使用すると、Amazon S3 データレイクとオンプレミスのデータソースや SQL や Python を使用する他のクラウドシステムを含む 30 のデータソース からデータを分析したり、アプリケーションを構築したりできます。 Amazon QuickSight は、ハイパースケールの統合ビジネスインテリジェンス (BI) により、データ駆動型の組織を強化します。QuickSight を使用すると、すべてのユーザーが、最新のインタラクティブなダッシュボード、ページ分割レポート、埋め込み分析、自然言語クエリを通じて、同じ情報源からさまざまな分析ニーズを満たすことができます。 アーキテクチャ図 図 1 はクリックストリームのデータフローアーキテクチャを示し、クリックストリームのレコードが一連のステップを経てどのように処理されるかを示しています。図中のカスタマー Web ポータルは、Web サイトやモバイルアプリケーションなどのデジタルプラットフォームとして機能し、ユーザーがシステムを操作できるようにします。ユーザーが Web ポータルを操作してさまざまなリンクをクリックすると、クリックストリームデータは次のように処理されます。 図 1 — アーキテクチャ クライアント (カスタマー Web ポータル) は、クリックストリームペイロード (レコード) を API Gateway に送信します。 API Gateway はレコードを Lambda に送信し、そこでデータが標準化されます。 Lambda はレコードを Kinesis Data Streams に送信して非同期処理を行います。 Kinesis Data Streams はリクエストを Kinesis Data Firehose に転送します。 Kinesis Data Firehose は、1 分ごとにレコードをバッファリングし、S3 バケットにアップロードします。 Athena は S3 バケットに保存されているデータのクエリと分析に使用されます。 QuickSight を使用してダッシュボードを作成し、データを視覚的に表示します。 前提条件 このソリューションを導入するには、次が必要です。 AWS アカウント AWS CloudFormation テンプレートを実行するための AWS Identity and Access Management (IAM) 権限 ステップ 1: ソリューションの実装 次のステップを実行して AWS リソースを作成し、アーキテクチャに記載したクリックストリームパイプラインを構築します。本ブログでは、AWS リージョン us-east-1 を使用します。 CloudFormation スタックを起動します。 「 Create stack 」ページで、「 Next 」 を選択します。 図 2 — CloudFormation を使用してスタックを作成する 「 Specify stack details 」ページで、「 Next 」をクリックします。 図 3 — スタックの詳細 「 Configure stack options 」ページで、デフォルトの選択のままにして「 Next 」をクリックします。 レビューページで、AWS CloudFormation が IAM リソースを作成する可能性があることを確認します。IAM の詳細については、 IAM の詳細 を確認してください。 「 Submit 」をクリックします。 図 4 — IAM リソースの確認 スタックが完全にデプロイされると、スタックのステータスが CREATE_COMPLETE に変わります。CloudFormation スタックによって作成されたリソースは 「 Resources 」 タブを確認できます。 図 5 — スタックの状態 図 6 — 作成されたリソース Athena でクエリを実行する前に、クエリ結果を保存する S3 バケットを選択する必要があります。ステップ 9 ~ 15 に従って S3 バケットパスを設定します。 Amazon Athena コンソールに移動し、「 Query your data 」 を選択します。 「 Launch query editor 」をクリックします。 図 7 — Amazon Athena コンソール Query editor ページで、「 Settings 」タブを選択します。 「 Query result and encryption settings 」セクションで、「 Manage 」をクリックします。 図 8 — クエリエディタの設定 「 Manage settings 」 ページで、「 Browse S3 」をクリックします。 「 Choose S3 data set 」ページで、clickstream-で始まる S3 バケットを選択し、「 Choose 」をクリックします。 図 9 — クエリ結果の場所 「 Manage settings 」ページで、「 Save 」をクリックします。 図 10 — 設定の確認 次に、ステップ 17 ~ 20 に従って、クリックストリームデータを保存するテーブルを Athena に作成します。 クエリーエディタで、「 Saved queries 」タブを選択します。 図 11 — Athena の保存したクエリ 名前フィールドで、「 ClickStreamAthenaNamedQuery- 」 で始まる名前を探し、その名前に関連付けられている ID リンクをクリックします。 図 12 のように、「 Editor 」タブにクエリが入力されていることを確認します。「 Run 」をクリックします。 図 12 — クエリの実行 クエリが実行されると、図 13 に示す必要な列を含む clickstream_data テーブルが作成されます。 図 13 — テーブル作成 ステップ 2: ソリューションのテスト 後続のデータポイントを出力する Lambda 関数を使用して、クリックストリームデータをシミュレートします。 customerid deviceid productid productcategory productsubcategory activitytype ステップ 2a: データを取り込む AWS Lambda コンソールに移動します。 「 ClickStream-IngestDataLambda 」で始まる Lambda 関数をクリックします。 図 14 — Lambdaを選択 「 Test 」タブを選択します。任意のイベント名を入力します (たとえば、「 ClickStreamTest 」)。「 Save 」 をクリックし、「 Test 」をクリックします。 図 15 — Lambda テスト設定 Lambda 関数は、図 1 のアーキテクチャ図のステップ 1 に示すように、ランダムなクリックストリームデータの生成を開始し、それらを API Gateway に渡します。 関数が実行されるまで 1 分ほどかかることがあります。Lambda 関数によって生成されたクリックストリームのデータを確認するには、「 Log Output 」セクションを確認してください。 図 16 — Lambda ログ ステップ 2b: データを検証する Lambda 関数が実行されてから、データが Amazon S3 に表示されるまでに数分かかる場合があります。Kinesis Data Firehose は、受信レコードを S3 バケットに配信する前にバッファリングします。クリックストリームデータを Amazon S3 にすばやくアップロードするために、バッファ間隔を Kinesis Data Firehose の最小許容値である 60 秒に設定しました。 Amazon S3 コンソールに移動します。 「 ClickStream-ClickStreams3Buket- 」で始まる S3 バケットをクリックし、下にあるフォルダ構造をナビゲートしてクリックストリームデータファイルを見つけます。Amazon Kinesis Data Firehose は、オブジェクトを Amazon S3 に配置する前に、 UTC 時間で YYYY/MM/DD/HH の形式でプレフィックスを追加します。プレフィックスは Amazon S3 フォルダ構造に変換され、スラッシュ (/) で区切られた各ラベルがサブフォルダになります。 図 17 — Amazon S3 パス オブジェクトリンクをクリックし、「 Open 」 をクリックして CSV ファイルを開きます。 図 18 — ファイルを開く データを確認してください。図19 に示すような表示になっているはずです。 図 19 — データを確認する ステップ 2c: データの分析 Amazon Athena コンソールのクエリエディタに移動します。 「 Data source 」 フィールドで 「 AWSDataCatalog 」 が選択されていることを確認します。 「 Database 」フィールドから「 clickstreamDb 」を選択します。 「 Tables 」の左側にある方向三角形をクリックして テーブル を展開します。 clickstream_data テーブルを見つけて、clickstream_data テーブル名の右端にある 縦の 3 つの点 をクリックします。ドロップダウンメニューから 「 Preview Table 」 を選択します。 図 20 — テーブルをプレビュー 図 21 に示すように、 ingestClickStream Lambda 関数を介して取り込まれたデータが表示されるはずです。 図 21 — データを確認する ステップ 3: Amazon QuickSight を使用してダッシュボードを作成する Amazon QuickSight コンソールに移動します。 a. 以前に QuickSight アカウントを作成したことがない場合は、手順 2 ~ 6 に従ってアカウントを作成します。QuickSight アカウントをすでにお持ちの場合は、ステップ 7 に進んでください。 「 Sign up for QuickSight 」 ボタンをクリックします。 「 Create your QuickSight account 」 ページで、既定の選択のままにして 「 Continue 」 をクリックします。 「 Get Paginated Report add-on 」で、「 No, Maybe Later 」をクリックします。 「 Create your QuickSight account 」ページで、 a. 「 Authentication method 」セクションで、「 IAM federated identities & QuickSight-managed users 」を選択します。 b. 米国東部 (バージニア北部) リージョンを選択します。 c.一意の QuickSight アカウント名を入力します。 d. 通知を受け取るメールアドレスを入力します。 e. IAM ロール で、「 QuickSight-managed role (default) 」 を選択します。 f. 「 Allow access and autodiscovery for these resources 」 で、 IAM 、 Amazon S3 、 Amazon Athena の各チェックボックスをオンにします。図 22 に示すように、他のすべてのボックスのチェックを外します。 g. チェックマークが付いたAmazon S3リソースの下で、「 Select S3 bucket 」リンクをクリックします。新しいポップアップウィンドウから、「 clickstream-clickstreams3bucket- 」で始まる S3 バケットを選択し、「 Finish 」 をクリックしてポップアップウィンドウを閉じます (図 23 を参照)。 「 Finish 」 をクリックして Amazon QuickSight アカウントの作成を完了します。 図 22 — QuickSight アカウントの作成 図 23 — S3 バケットの選択 「 Go to Amazon QuickSight 」をクリックします。これにより、QuickSightが開きます。 図 24 — アカウントが作成されました 左側のナビゲーションメニューで「 Analyses 」が選択されていることを確認します。 右上隅の 「 New analysi s 」 ボタンをクリックします。次のページで 「 New dataset 」 ボタンをクリックします。 図 25 — 新しい分析 「 Create a Dataset 」ページで、「 Athena 」を選択します。 「 New Athena data source 」ページで、お好みの データソース名 を入力し、「 Create data source 」 をクリックします。 図 26 — データソースの作成 「 Choose your table 」ページで、以下を選択します。 a. 「 Catalog: contain sets of databases 」の下の awsDataCatalog b. 「 Database: contain sets of tables 」の下の clickstream_db c. 「 Tables: contain the data you can visualize 」の下の clickstream_data 完了したら、「 Select 」 をクリックします。 図 27 — テーブルを選択 「 Finish dataset creation 」 ページで、デフォルトの選択のままにして 「 Visualize 」 をクリックします。 図 28 — データセット作成の完了 次のページで、「 Interactive Sheet 」が選択されていることを確認します。デフォルトの選択をそのまま使用して、「 Create 」をクリックします。 図 29 — データセット作成の完了 (続き) クリックされた製品カテゴリの数を分析するビジュアルを作成します。 左上隅の 「 Add 」 をクリックし、「 Add Visual 」 をクリックします。 「 Visual Types 」から円グラフアイコンを選択します。 図 30 に示すように、「 productcategory 」を「 Group/Color 」フィールドにドラッグアンドドロップします。これにより、「 productcategory 」別のレコード数を示す円グラフが生成されます。 図 30 — 製品カテゴリ もう 1 つのビジュアルを追加して、各カテゴリの下でクリックされたサブカテゴリの数を分析してみましょう。 左上隅の 「 Add 」 をクリックし、「 Add Visual 」 をクリックします。 「 Visual Types 」から 垂直積み上げ棒グラフ アイコンを選択します。 図31に示すように、 X 軸 フィールドに「 productcategory 」をドラッグし、「 Group/Colo r 」フィールドに「 productsubcategory 」をドラッグアンドドロップします。 図 31 — 製品カテゴリ/サブカテゴリ ステップ 4: クリーンアップ 今後課金されないようにするには、次の手順に従ってリソースを削除してください。 QuickSight アカウントを削除する。 a. 右上の「 プロファイルアイコン 」をクリックします。 b. 「 Account Settings 」 をクリックします。 c. 「 Manage 」ボタンをクリックします。 図 32 — QuickSight アカウント設定 d. アカウント終了保護機能をオフにするには、「 Account Termination toggle 」を左にスライドします。 e. このアカウントを削除するには、「 Type “confirm” to delete this account box 」に「 confirm 」と入力します。 f. 「 Delete Account 」をクリックします。 図 33 — QuickSight アカウントの解約 S3 バケットを空にします。 a.  Amazon S3 コンソールに移動します。 b.  clickstream-clickstreams3bucket で始まるバケットを選択し、「 Empty 」をクリックします。 c. 「 Empty bucket 」ページで、「削除の確認」フィールドに「 permanently delete 」と入力し、「 Empty 」をクリックします。 図 34 — S3 バケットの選択 図 35 — S3 バケットを空にする ソリューションを削除します。 a.  CloudFormation コンソールに移動し、このプロジェクトの一環として作成した clickstream スタックを選択します。スタックをクリックし、「 Delete 」 をクリックします。 図 36 — CloudFormation スタックの削除 まとめ AWS サーバーレスサービスを活用することで、クリックストリームデータを扱うための強力でスケーラブルなソリューションが得られます。 Amazon API Gateway 、AWS Lambda 、 Amazon Kinesis Data Streams 、 Amazon Kinesis Data Firehose 、 Amazon S3 、 Amazon Athena 、 Amazon QuickSight などのサービスを利用することで、組織はクリックストリームデータを切れ目なく収集し、処理、視覚化し、分析基盤に取り込むことができます。Kinesis Data Firehose は受信データを自動的にスケーリングしてバッファリングすることで取り込みプロセスを促進し、Lambda はデータ変換と加工のためのカスタムコードの実行を可能にします。 サーバーレスアーキテクチャにより、企業はさまざまなデータ量を効率的に処理し、オペレーションコストを削減し、迅速に反復処理を行い、デジタルコンテンツにおける顧客の行動の変化から学ぶことができます。また、クリックストリームデータから迅速にインサイトを抽出できるため、データ主導の意思決定と顧客体験の向上が可能になります。 AWS の担当者 にお問い合わせいただき、当社がお客様のビジネスをどのように促進できるかをご確認ください。 参考文献 Real-time Clickstream Anomaly Detection with Amazon Kinesis Analytics Amazon Personalize customer outreach on your ecommerce platform 著者について Pritam Bedse Pritam Bedse は、アマゾン ウェブ サービスのシニアソリューションアーキテクトで、エンタープライズ企業のお客様を支援しています。彼の関心と経験には、AI/ML 、分析、サーバーレステクノロジー、カスタマーエンゲージメントプラットフォームなどがあります。仕事以外にも、Pritam は屋外でのガーデニングやグリルを楽しみます。 Christin Carter Christin Carter は、アマゾン ウェブ サービスのプリンシパルアカウントマネージャーで、エンタープライズ企業のお客様を支援しています。彼女の関心と経験には、デジタルトランスフォーメーション、AI/ML 、分析、サーバーレステクノロジー、カスタマーエクスペリエンスソリューションなどがあります。仕事以外では、Christin が世界中を旅し、大小さまざまな新しい冒険を求めています。 Jared Warren Jared Warren は、アマゾン ウェブ サービスのプリンシパルソリューションアーキテクトであり、エンタープライズ企業のお客様と協力しています。仕事以外では、ボードゲームをしたり、裏庭でバーベキューをしたりしています。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。
今日の競争の激しい市場では、顧客を中心に考えることは不可欠です。顧客を中心に考えるためには、まず性別や年代といったユーザー属性(デモグラフィック)、嗜好やライフスタイルといったユーザーの心理的属性(サイコグラフィック)、取引、購入記録、サポートケース、製品の使用状況、買い物習慣、コンテンツの好みなどのデータが必要です。 ガートナーのレポート によると、消費者を 360 度把握している企業は 10% 未満です。彼らが努力しないからではなく、全体像を把握することはとても難しいのです。この課題は、データ収集と統合のプロセスに内在する複雑さに起因し、消費者の全体像を把握するうえで根強いハードルとなっています。 今日のビジネス環境は変化が速いため、タイムリーなビジネス意思決定では、新しいデータに何時間も何日もアクセスするのではなく、リアルタイムでアクセスする必要があります。競争力を維持し、現在の市場の状況に合わせて十分な情報に基づいた意思決定を行うためには、組織はリアルタイムの情報を自由に利用できなければなりません。 市場が急速に変動し、顧客の好みが変化すると、古くなったデータによって機会を逃したり、インサイトが古くなったりして、顧客体験が最適ではなくなる可能性があります。 企業は、自社のデータ(ファーストパーティデータ)の所有権を取り戻し、顧客や見込み客の情報の力を活用して競争力を高め、より顧客体験をもたらすべく取り組む必要があることを認識しています。ファーストパーティデータの例としては、企業が顧客の行動や好みについての理解を深めるための大きな可能性を秘めたクリックストリームデータがあります。 クリックストリームデータとは、ユーザーと Web サイトまたはモバイルアプリケーションとの間で発生するデジタルインタラクションを収集したものです。リアルタイムにユーザーデータを収集し有用なインサイトを作成することは困難な場合があります。アマゾン ウェブ サービス(AWS)のサーバーレスサービスは、クリックストリームデータをシームレスにキャプチャ、処理、視覚化し、分析基盤に取り込むためのスケーラブルなアーキテクチャを提供するために役立ちます。 ユーザーインタラクションには、リンクやボタンのクリック、さまざまなページの表示、特定のページの閲覧時間、フォームの送信、ファイルのダウンロード、その他デジタル環境で行われるさまざまなアクティビティなど、さまざまなアクションが含まれます。クリックストリームデータは、ユーザーの行動、好み、パターンに関する貴重なインサイトを提供します。これにより、組織は Web サイトやアプリを最適化し、顧客体験を向上させ、データ駆動型の意思決定を行って全体的なパフォーマンスを向上させることができます。 クリックストリームデータを活用することで企業が得ることができる利点をいくつか紹介します。 顧客インサイト: クリックストリームデータは、顧客の行動、好み、関心に関する貴重なインサイトを提供することができます。クリックストリームデータを分析することで、企業はユーザーが Web サイトやモバイルアプリをどのように操作しているか、どのページや機能が最も人気があるか、コンバージョン前にユーザーが取るアクションをよりよく理解できます。 パーソナライゼーション: クリックストリームデータを使用して、ユーザー体験をパーソナライズできます。ユーザーのクリックストリームデータを分析することで、企業はパーソナライズされたレコメンデーションを行い、ターゲットを絞ったコンテンツを表示し、関連性の高い広告を配信できます。 最適化: クリックストリームデータは、Web サイトやモバイルアプリの最適化に使用できます。クリックストリームデータを分析することで、企業は Web サイトやモバイルアプリの中で、ユーザー体験を損なっている領域やコンバージョンを妨げている領域を特定できます。その後、変更を加えてユーザー体験を向上させ、コンバージョンを増やすことができます。 マーケティング: クリックストリームデータは、マーケティングキャンペーンを最適化するために使用できます。クリックストリームデータを分析することで、企業はカスタマージャーニーをよりよく理解し、ターゲティング、メッセージング、チャネルセレクションについてより多くの情報に基づいた意思決定を行うことができます。 本ブログでは、サーバーのプロビジョニングや管理を必要とせずに、AWS サーバーレスサービスを使用してクリックストリームデータをほぼリアルタイムで収集するための高レベルのアーキテクチャについて説明します。 アーキテクチャ このソリューションでは、 Amazon API Gateway 、 AWS Lambda 、 Amazon Kinesis データストリームを使用してクリックストリームデータを取り込んで処理し、Amazon Kinesis Data Firehose を使用して未加工データをアマゾンシンプルストレージサービス (Amazon S3) に保存し、次に Amazon Athena と Amazon QuickSight を使用してユーザーフレンドリーな方法でデータを分析および視覚化します。 サービス選定理由 クリックストリームデータは、ユーザーのトラフィックと行動に応じて非常に変動しやすく、大量のメッセージとして継続的にストリーミングされます。新しいアプリケーション機能、 Web サイトのレイアウト、またはマーケティングキャンペーンのパフォーマンスを評価する場合、迅速なアクションを可能にするためにそれらをリアルタイムで分析することが重要です。 このアーキテクチャ用に選択された AWS サービスは、クリックストリームデータを処理するための自動スケーリング機能と費用対効果の高いソリューションを提供します。これらのサービスは、入ってくるワークロードの変動に対応するようにリソースを動的にスケーリングし、ほぼリアルタイムの処理と分析を保証します。従量課金制の価格モデルでは、使用したリソースに対してのみ支払いが発生するため、過剰なインフラを用意しておく必要がなくなり、コストを最小限に抑えることができます。 Amazon API Gateway は、開発者があらゆる規模の API を簡単に作成、公開、保守、監視、保護できるようにする完全マネージド型サービスです。 AWS Lambda はサーバーレスのイベント駆動型コンピューティングサービスで、サーバーのプロビジョニングや管理を行わずに、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行できます。Lambda は 200 以上の AWS サービスと Software-as-a-Service (SaaS) アプリケーションからトリガーできます。支払いは使用した分だけです。 Amazon Kinesis Data Streams は、あらゆる規模のデータストリームの収集、処理、保存を容易にするサーバーレスのストリーミングデータサービスです。 Amazon Kinesis Data Firehose は、ストリーミングデータを確実に収集、変換し、データレイク、データストア、分析サービスに配信する抽出、変換、ロード (ETL) サービスです。 Amazon S3 は、業界トップクラスのスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。あらゆる規模と業種のお客様が、データレイク、クラウドネイティブアプリケーション、モバイルアプリなど、ほぼすべてのユースケースで任意の量のデータを保存および保護できます。 Amazon Athena では、場所を問わずペタバイト単位のデータを簡単に柔軟に分析できます。Athena を使用すると、Amazon S3 データレイクとオンプレミスのデータソースや SQL や Python を使用する他のクラウドシステムを含む 30 のデータソース からデータを分析したり、アプリケーションを構築したりできます。 Amazon QuickSight は、ハイパースケールの統合ビジネスインテリジェンス (BI) により、データ駆動型の組織を強化します。QuickSight を使用すると、すべてのユーザーが、最新のインタラクティブなダッシュボード、ページ分割レポート、埋め込み分析、自然言語クエリを通じて、同じ情報源からさまざまな分析ニーズを満たすことができます。 ニーマン・マーカスは、このソリューションを自社の e コマース Web サイトである BergdorfGoodman.com とNeimanMarcus.com に実装しました。オムニチャネルパーソナライゼーション担当ディレクターの Sravan Erukulla 氏は次のように語っています。「AWS は ニーマン・マーカス グループ と協力して、毎日数百万件のレコードを処理できるクリックストリームリポジトリを作成しました。わずか 3 週間で、2 つのチームが協力してソリューションを構築し、本番環境にデプロイしました。このクリックストリームデータにより、ニーマン・マーカスは、ユーザーの閲覧行動や放棄されたカートなどについて、ほぼリアルタイムでモデルのトレーニングと調整を行うことができます。」 アーキテクチャ図 図 1 はクリックストリームのデータフローアーキテクチャを示し、クリックストリームのレコードが一連のステップを経てどのように処理されるかを示しています。図中のカスタマー Web ポータルは、Web サイトやモバイルアプリケーションなどのデジタルプラットフォームとして機能し、ユーザーがシステムを操作できるようにします。ユーザーが Web ポータルを操作してさまざまなリンクをクリックすると、クリックストリームデータは次のように処理されます。 図 1 — アーキテクチャ クライアント (カスタマー Web ポータル) は、クリックストリームペイロード (レコード) を API Gateway に送信します。 API Gateway はレコードを Lambda に送信し、そこでデータが標準化されます。 Lambda はレコードを Kinesis Data Streams に送信して非同期処理を行います。 Kinesis Data Streams はリクエストを Kinesis Data Firehose に転送します。 Kinesis Data Firehose は、1 分ごとにレコードをバッファリングし、S3 バケットにアップロードします。 Athena は S3 バケットに保存されているデータのクエリと分析に使用されます。 QuickSight を使用してダッシュボードを作成し、データを視覚的に表示します。 クリックストリームのユースケースの例 クリックストリームデータは、 Amazon Personalize を使用してパーソナライズされたおすすめ商品を提供するための貴重な情報源となります。Amazon Personalize は、開発者がアプリケーション向けにパーソナライズされたレコメンデーションを作成できるようにする機械学習サービスです。Amazon Personalize はクリックストリームデータを使用してレコメンデーション機能を強化し、より適切でパーソナライズされた体験を顧客に提供できます。このブログで説明されているクリックストリームソリューションは、図 2 に示すように、クリックストリームデータを Amazon Personalize にフィードするように拡張できます。 図 2 — クリックストリームのユースケース Kinesis Data Streams はクリックストリームのレコードを Lambda に渡します。 Lambda はレコードをフォーマットして Amazon Personalize に送信します。 まとめ AWS サーバーレスサービスを活用することで、クリックストリームデータを扱うための強力でスケーラブルなソリューションが得られます。 Amazon API Gateway 、AWS Lambda 、 Amazon Kinesis Data Streams 、 Amazon Kinesis Data Firehose 、 Amazon S3 、 Amazon Athena 、 Amazon QuickSight などのサービスを利用することで、組織はクリックストリームデータを切れ目なく収集し、処理、視覚化し、分析基盤に取り込むことができます。Kinesis Data Firehose は受信データを自動的にスケーリングしてバッファリングすることで取り込みプロセスを促進し、Lambda はデータ変換と加工のためのカスタムコードの実行を可能にします。 サーバーレスアーキテクチャにより、企業はさまざまなデータ量を効率的に処理し、オペレーションコストを削減し、迅速に反復処理を行い、デジタルコンテンツにおける顧客の行動の変化から学ぶことができます。また、クリックストリームデータから迅速にインサイトを抽出できるため、データ主導の意思決定と顧客体験の向上が可能になります。 技術に焦点を当てたブログ「 AWS サーバーレスサービスを使用してクリックストリームデータをキャプチャする 」では、クリックストリームデータのキャプチャを開始する際に役立つように、このソリューションを導入する手順を段階的に説明します。 AWS の担当者 にお問い合わせいただき、当社がお客様のビジネスをどのように促進できるかをご確認ください。 参考文献 Real-time Clickstream Anomaly Detection with Amazon Kinesis Analytics Amazon Personalize customer outreach on your ecommerce platform 著者について Pritam Bedse Pritam Bedse は、アマゾン ウェブ サービスのシニアソリューションアーキテクトで、エンタープライズ企業のお客様を支援しています。彼の関心と経験には、AI/ML 、分析、サーバーレステクノロジー、カスタマーエンゲージメントプラットフォームなどがあります。仕事以外にも、Pritam は屋外でのガーデニングやグリルを楽しみます。 Christin Carter Christin Carter は、アマゾン ウェブ サービスのプリンシパルアカウントマネージャーで、エンタープライズ企業のお客様を支援しています。彼女の関心と経験には、デジタルトランスフォーメーション、AI/ML 、分析、サーバーレステクノロジー、カスタマーエクスペリエンスソリューションなどがあります。仕事以外では、Christin が世界中を旅し、大小さまざまな新しい冒険を求めています。 Jared Warren Jared Warren は、アマゾン ウェブ サービスのプリンシパルソリューションアーキテクトであり、エンタープライズ企業のお客様と協力しています。仕事以外では、ボードゲームをしたり、裏庭でバーベキューをしたりしています。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。
11月29日は、 Amazon DocumentDB (MongoDB 互換) のベクトル検索 の一般提供についてお知らせします。この製品は、ドキュメントデータベース内でミリ秒の応答時間で何百万ものベクトルを保存、索引付け、検索できる新しい組み込み機能です。 ベクトル検索は、 機械学習 (ML) で使用される新しい手法で、距離または類似度メトリックを使用してベクトル表現を比較することにより、特定のデータに類似したデータポイントを検索します。ベクトルは、Amazon Bedrock、Amazon SageMaker、およびその他のオープンソースまたは独自の ML サービスでホストされている大規模言語モデル (LLM) から作成された非構造化データを数値で表したものです。このアプローチは、 検索拡張生成 (RAG) モデルアプローチを使用して、直感的な検索、製品推奨、パーソナライゼーション、チャットボットなどの 生成型人工知能 (AI) アプリケーションを作成するのに役立ちます。たとえば、データセットに映画の個別のドキュメントが含まれている場合、単にキーワードを照合するのではなく、「ボート」、「悲劇」、「実話に基づいた映画」などの共有コンテキストに基づいて、 タイタニック に似た映画をセマンティックに検索できます。 Amazon DocumentDB のベクトル検索を使用すると、個別のベクトルデータベースインフラストラクチャを管理する時間とコストをかけることなく、微妙な意味とコンテキストに基づいてデータベースを効果的に検索できます。また、Amazon DocumentDB が提供する、完全に管理された、スケーラブルで、安全で、可用性が高い JSON ベースのドキュメントデータベースも利用できます。 Amazon DocumentDB でベクトル検索を開始する ベクトル検索機能は、Amazon DocumentDB 5.0 インスタンスベースのクラスターで利用できます。ベクトル検索アプリケーションを実装するには、ドキュメント内のフィールドに埋め込みモデルを使用してベクトルを生成し、ソースデータを Amazon DocumentDB 内に並べて保存します。 次に、ベクトルフィールドにベクトルインデックスを作成します。これにより、類似のベクトルを取得しやすくなり、セマンティック検索を使用して Amazon DocumentDB データベースを検索できます。最後に、ユーザーが送信したクエリは、同じ埋め込みモデルを使用してベクトルに変換され、意味的に類似したドキュメントを取得してクライアントに返します。 Amazon DocumentDB でベクトル検索を使用して簡単なセマンティック検索アプリケーションを実装する方法を見てみましょう。 ステップ 1.Amazon Titan 埋め込みモデルを使用してベクトル埋め込みを作成する Amazon Titan 埋め込みモデルを使用して埋め込みベクトルを作成してみましょう 。Amazon Titan Embeddings モデルは、サーバーレスの生成系 AI サービスである Amazon Bedrock で利用できます。インフラストラクチャを管理することなく、単一の API を使用して簡単にアクセスできます。 prompt = "I love dog and cat." response = bedrock_runtime.invoke_model( body= json.dumps({"inputText": prompt}), modelId='amazon.titan-embed-text-v1', accept='application/json', contentType='application/json' ) response_body = json.loads(response['body'].read()) embedding = response_body.get('embedding') 返されるベクトル埋め込みは次のようになります。 [0.82421875, -0.6953125, -0.115722656, 0.87890625, 0.05883789, -0.020385742, 0.32421875, -0.00078201294, -0.40234375, 0.44140625, ...] ステップ 2.ベクトル埋め込みを挿入してベクトルインデックスを作成する insertMany( [{},...,{}] ) オペレーションを使用して、Amazon DocumentDB のコレクションに追加したいドキュメントのリストを使用して、生成されたベクトル埋め込みを追加できます。 db.collection.insertMany([ {sentence: "I love a dog and cat.", vectorField: [0.82421875, -0.6953125,...]}, {sentence: "My dog is very cute.", vectorField: [0.05883789, -0.020385742,...]}, {sentence: "I write with a pen.", vectorField: [-0.020385742, 0.32421875,...]}, ... ]); createIndex コマンドを使用してベクトルインデックスを作成できます。Amazon DocumentDB は、フラット圧縮 (IVFFLAT) ベクトルインデックスを使用した転置ファイルを使用して、近似最近傍検索 (ANN) を実行します。この機能は、ユークリッド、コサイン、内積の 3 つの距離計量をサポートします。ここでは、空間の 2 点間の直線距離の尺度であるユークリッド距離を使用します。ユークリッド距離が小さいほど、ベクトルは互いに近づきます。 db.collection.createIndex ( { vectorField: "vector" }, { "name": "index name", "vectorOptions": { "dimensions": 100, // the number of vector data dimensions "similarity": "euclidean", // Or cosine and dotProduct "lists": 100 } } ); ステップ 3. Amazon DocumentDB からベクトル埋め込みを検索する $search 内の新しい集計パイプライン演算子を使用して、ドキュメント内の類似のベクトルを検索できるようになりました。「 ペットが好き 」を検索するサンプルコードは次のとおりです。 db.collection.aggregate ({ $search: { "vectorSearch": { "vector": [0.82421875, -0.6953125,...], // Search for ‘I like pets’ "path": vectorField, "k": 5, "similarity": "euclidean", // Or cosine and dotProduct "probes": 1 // the number of clusters for vector search } } }); これにより、「 犬と猫が大好き 」などの検索結果が返されます。意味的には似ています。 詳細については、Amazon DocumentDB のドキュメントを参照してください。Amazon DocumentDB によるセマンティックムービー検索など、より実用的な例については、 GitHub リポジトリ にある Python のソースコードとデータセットをご覧ください。 今すぐご利用いただけます Amazon DocumentDB のベクトル検索は、 Amazon DocumentDB が利用可能な すべての AWS リージョンで Amazon DocumentDB 5.0 インスタンスベースのクラスターを使用しているすべてのお客様に追加費用なしで利用できるようになりました。Amazon DocumentDB への埋め込みの保存、インデックス作成、および検索ベクトルには、標準のコンピューティング、I/O、ストレージ、およびバックアップ料金が適用されます。 詳細については、 Amazon DocumentDB のドキュメント を参照してください。フィードバックは、 AWS re:Post for Amazon DocumentDB または通常の AWS サポート連絡先から送信してください。 – Channy 原文は こちら です。
アマゾン ウェブ サービス (AWS) の スマートストアソリューション の出現は、小売業者に新たな可能性を示しました。これらのソリューションを最大限に活用するには、小売業者はネットワークインフラストラクチャを最適化する必要があります。小売業者が業務のデジタル化を進め、より多くのサービスをクラウドに移行するにつれて、セキュリティとネットワークインフラストラクチャが主要な論点となっています。何千ものエンドポイントの管理、セキュリティコンプライアンスの確保、すべての店舗からの迅速かつ安全なクラウドアクセスの提供は、小売業者が直面する課題のほんの一部にすぎません。これらの課題は、世界中に大規模な店舗ネットワークを持つ小売業者にとって特に困難な場合があります。 幸いなことに、これらの課題に対する解決策があります。それは、AWS を使用してネットワークとセキュリティインフラストラクチャを統合し、一元管理することです。グローバルまたは全国規模のネットワークバックボーンを構築し、店舗やビジネスセンターにリーフノードを接続し、すべて AWS が管理することで、小売業者は AWS Cloud WAN を使用して世界中の何千もの店舗を AWS に接続できます。このアプローチは、低レイテンシーで安全な接続を提供するだけでなく、セキュリティの管理と監視を一元化し、すべての店舗で一貫したセキュリティポリシーを実現します。一元管理システムを導入することで、小売業者は各店舗に常駐する IT スタッフを必要とせずに、ネットワークインフラストラクチャを一元的に管理することで、セキュリティ規制の遵守、業務の合理化、コストの削減を実現できます。 ネットワークインフラストラクチャを最適化し、AWS スマートストアソリューションを活用することで、小売業者は収益を向上させながら顧客の店内体験を向上させることができます。たとえば、リアルタイムのデータ分析を使用してショッピング体験をパーソナライズしたり、オンラインとオフラインのチャネルを統合して新しい収益源を創出したり、サプライチェーン業務を最適化したりすることができます。さらに、小売業者は AWS の機械学習機能を活用して、在庫管理を自動化し、店舗のレイアウトと人員配置を最適化し、さらには盗難の検出と防止を行うことができます。 可能性は無限ですが、すべては強固なネットワークインフラストラクチャと信頼できるクラウドプロバイダーがあることが前提です。 店舗側に必要な要件 ほとんどの小売店には、IT チームがリモートから管理する IT 環境があります。これには以下が含まれます。 小売店向け IT ハードウェア: このカテゴリには、サーバー、従業員用 PC 、 Point-of-Sale (POS) コンポーネント、デジタルサイネージ、カメラなどのセキュリティデバイスなど、店舗でよく見かけるデバイスが含まれます。 小売店向け IT ソフトウェア: このカテゴリには、サーバーと PC のオペレーティングシステム、プロダクティビティソフトウェア、ERP ソフトウェア、コミュニケーションアプリケーション、ロイヤルティアプリケーション、e コマース、ビジネスアプリケーション、注文管理ソフトウェアが含まれます。 小売店向け IT サービス: このカテゴリには、サポートサービス、ハードウェアおよびソフトウェア管理、インストール/変更管理、ディザスタリカバリ、カスタムソフトウェア統合/開発が含まれます。 米国全土の 500 を超える店舗の平均を調べたところと、上記のすべてに店舗ごとの費用がかかります。世界中に数千の店舗を展開するような一部の小売業者では、IT 支出は大幅に増加します。 IT コンポーネント 500 を超える店舗の平均 PC 5% ファイアウォール/ルーター/スイッチ 2% 電話システム 6% 社内電話回線 7% サーバー (Windows DC 、SQL) 4% アプリケーションメンテナンス /POS 、スケジューリング、在庫管理、電子メール、その他アプリケーションのアップグレード 20% ブロードバンド接続 3% IT メンテナンスサポート (40 時間/月) 52% データストレージ / バックアップ 1% 合計 一部の小売業者では約 8,000 万ドルになります 表 1 — 小売店舗の IT コスト (ハードウェア、ソフトウェア、サービス) ほとんどの小売業者の IT 支出は年々増加し続けているため、これらのサービスの多くを AWS に統合してコストを削減し、顧客体験への投資を増やすことができます。このようなインフラストラクチャの管理は、特にさまざまな地域にまたがる多数の店舗を扱う場合には困難な場合があります。すべてのハードウェアとソフトウェアが最新で、安全で、正しく機能していることを確認することは、IT チームにとって大変な作業です。 小売業者は、IT インフラストラクチャの管理という課題に加えて、店舗ネットワークの信頼性と安全性を確保し、クラウドベースのサービスに対する需要の高まりに対応できるようにする必要もあります。e コマースの台頭により、顧客はすべてのチャネルでシームレスな体験を期待しており、小売業者はこの体験を実店舗でも提供できなければなりません。そのためには、リアルタイムの在庫管理、顧客分析、パーソナライズされたマーケティングなど、複数のアプリケーションとサービスを支えることのできる堅牢でスケーラブルなネットワークインフラストラクチャが必要です。AWS を使用して ネットワークとセキュリティインフラストラクチャ を統合して一元管理することで、小売業者はこれらの課題を克服し、シームレスでパーソナライズされたショッピング体験を顧客に提供できます。 実店舗のサービスを AWS に移行すると、コスト削減とともに以下のメリットが得られます。 一元化されたセキュリティ 侵入ポイントを減らす一元化されたインターネットアクセス 電話システム/電話回線などの資産を減価償却するための共有リソース 仮想デスクトップインフラストラクチャ (VDI) ソリューションによる安全なデスクトップアプライアンス (最小限の店舗の端末) すべての店舗にまたがるディザスターリカバリソリューション 店舗を横断した在庫管理 IT 人件費の削減 店舗ソリューションの導入 ソリューション概要 スマートストアネットワーキングおよびインフラストラクチャソリューションは、パートナーとの Direct Connect または SD-WAN (Software Defined-Wide Area Network)を使用して、すべての店舗を AWS に接続します。冗長性を確保するため、各店舗には AWS への接続が少なくとも 2 つ必要です。商品のスキャン、支払い処理、領収書の印刷、および店舗の端末用のハードウェアコンポーネントは、プライベート接続を介して AWS サービスに接続できます。 すべての店舗ソフトウェアは、オペレーションサポートのために最も近い AWS リージョンにデプロイする必要があります。これにより、サーバーや店舗ごとのメンテナンスが不要になります。支払い機能のためには、 AWS 仮想デスクトップインフラストラクチャソリューション に接続するゼロクライアントモニターが設置され、店舗アプリケーションがクラウド ERP および POS システムと通信できるようになり、より高い回復力とディザスターリカバリ機能が提供されます。電話交換機 (PBX) サービスは、Asterisk や Sipxcom などのオープンソースソリューションを使用して米国の 2 つのリージョンに統合し、 Amazon Connect と統合することでシームレスな顧客体験を実現できます。 AWS ネットワークインフラストラクチャ AWS ネットワークインフラストラクチャは AWS Cloud WAN を使用して構築され、クラウドネットワークエンジン (CNE) が米国の 4 つのリージョン (us-east-1、us-east2、us-west1、us-west2) のそれぞれにデプロイされます。これにより、4 つのリージョンに関連付けられた Direct Connect ロケーションが、AWS リージョン全体の Amazon Virtual Private Clouds (Amazon VPC) にトラフィックをルーティングできるようになります。 AWS Cloud WAN 内では、セグメントを作成して、各地域の店舗とそれに関連付けられた Amazon VPC ワークロードのトラフィックルールをグループ化できます。これにより、インターネットトラフィックと冗長ワークロードの管理が簡素化され、通信トラフィック用の VOIP セグメント、アプリケーションの開発とテスト用の開発セグメント、ビジネスアプリケーションの本番セグメントなど、アプリケーションとビジネス要件に基づいてネットワークトラフィックをセグメント化できます。このように店舗を地理的セグメントにグループ化することで、地域固有のニーズに基づいてさまざまなサービスを提供することもできます。 セキュリティアーキテクチャについては、すべての店舗のインターネット入出力トラフィックを処理するために、出口用のAmazon VPC が各リージョンに設定されます。出口用の Amazon VPC では、冗長構成でデプロイされたファイアウォールを使用してトラフィックを検査し、ネットワークインフラストラクチャの高度なセキュリティを確保します。 図 1: リファレンスネットワークアーキテクチャ 店舗から AWS への接続 小売業者のネットワーク上の各店舗には、近接性とネットワークプロバイダーのサービスに基づいて選択された 2 つの異なる AWS Direct Connect (Direct Connect) ロケーションへのファイバー接続が 2 つ以上必要です。仮想プライベートネットワーク (VPN) を使用した AWS Cloud WAN への 3 次バックアップ接続は、5G または BB を使用して設定できます。0.0.0.0/0 のルートが Direct Connect または VPN 経由で AWS を指定しているため、店舗からインターネットに直接アクセスすることはできません。AWS Direct Connect サービスプロバイダーに接続するには、各店舗にローカルルーターまたはスイッチが必要です。2 つの Direct Connect 接続は、異なるポイントオブプレゼンス (POP) で接続することをお勧めします。 複数の Direct Connect 接続と VPN バックアップのルート優先順位を管理するには、AWS のベストプラクティスに従って、ローカルルーターでボーダーゲートウェイプロトコル (BGP) を使用する必要があります。各 Direct Connect 接続は、店舗から Direct Connect ロケーションまで 1G で、AWS への Direct Connect ロケーションの帯域幅は、必要な店舗数と帯域幅に応じて 10G です。パケットのスループットを確保するには、帯域幅をオーバープロビジョニングすることをお勧めします。AWS Direct Connect はパケットの優先順位とサービス品質 (QoS) を管理しないため、すべてのパケットには差分サービスコードポイント (DSCP) のマークを付け、送信元で優先順位を付ける必要があります。DSCP マーキングは宛先に渡されます。帯域幅とクラスレスドメイン間ルーティング(CIDR)の計画が実施されている場合、店舗は Direct Connect 接続を追加する前に、まず SD-WAN を使用して AWS に接続できます。 ハイブリッド接続モデル すべての店舗が同じ接続モデルを必要とするわけではありません。店舗は大都市圏、郊外、地方に分類できます。これらのカテゴリではそれぞれ、接続オプションと帯域幅のニーズが異なる場合があります。 店舗から AWS に接続するには、SD-WAN を使用して店舗のローカル Direct Connect ロケーションにある顧客管理のスイッチ/ルーターへのラストマイルを行うハイブリッドアプローチがあります。この方法では、短距離でのパフォーマンスが向上し、レイテンシーが減少します。Direct Connect ロケーションでは、SD-WAN 接続を集約して AWS Cloud WAN に直接接続できます。 ブロードバンド回線を使用する郊外地域の店舗では、店舗接続の集約をローカルゾーンで行うこともできます。仮想 SD-WAN アプライアンスをローカルゾーンにデプロイして、SD-WAN ネットワークをローカル AWS ロケーションに拡張して AWS Cloud WAN に接続できます。全体として、このハイブリッドアプローチにより、店舗から AWS への効率的な接続が可能になります。 各接続モデルは、パフォーマンスと遅延の要件に基づいて最適かどうかをテストする必要があります。 図 2: ハイブリッド接続 店舗のインターネットアクセス 一部の店舗では、インターネットに直接アクセスできない場合があります。インターネット宛のトラフィックはすべて、Direct Connect 経由でインターネット出口用の Amazon VPC に送信されます。ファイアウォールポリシーは、設定されたルールに基づいて、下りの Amazon VPC のインターネットトラフィックに適用されます。インターネット出口用の Amazon VPC は各 AWS リージョンで設定され、トラフィックは各セグメントのルートテーブルを使用してインターネット出口用の Amazon VPC に送られます。 このモデルを利用すると、管理が必要なファイアウォールの数を合計 4 セットに減らすことができます。インターネット出口用の Amazon VPC は AWS Cloud WAN 内の共有サービスセグメントに接続されます。 図 3: ストア接続 マルチクラウド相互接続 Azure 、 GCP 、 SAP などの他のクラウドプロバイダーにデプロイされているワークロードの場合、小売業者はそのクラウドプロバイダーが存在するトランジットポイントへの Direct Connect 接続が必要になります。マルチクラウド接続をサポートする Direct Connect ロケーションを使用することをお勧めします。 これを設定するには、小売業者には次の 2 つの選択肢があります。 AWS Direct Connect 接続と他のクラウド接続を相互接続し、ルーティングを管理するルーターを備えたコロケーションラックを Direct Connect ロケーションにセットアップします。 マルチクラウドをサポートする Direct Connect パートナー と連携します。 どちらのオプションでも、IPv4 CIDR ブロック範囲が重複しないようにする必要があります。また、AWS Cloud WAN のルーティングルールは、トラフィックをマルチクラウドの Direct Connect ロケーションに転送するように適切に設定する必要があります。 マルチクラウドの Direct Connect 接続が設定されている各リージョンでは、マルチクラウド接続との間のすべての経路について、ファイアウォール検査付きのトランジット Amazon VPC を作成することをお勧めします。このファイアウォールはインターネット出口用のファイアウォールとは別のものです。 注:他のクラウドプロバイダーのパートナーサポートによっては、必要に応じて複数の Direct Connect ロケーションを使用して他のクラウドプロバイダーに接続できます。 エッジファイアウォールの設計 このアーキテクチャには以下のファイアウォールが推奨されます。 AWS Network Firewall – AWS Network Firewallは、AWS 内で開始されるすべてのアウトバウンドトラフィックに対して、出口用の Amazon VPC にデプロイされます。アウトバウンドトラフィックとレスポンストラフィックは、設定されたポリシーに基づいて検査されます。AWS Cloud WAN は、すべての Amazon VPC トラフィックを出口用の Amazon VPC 経由で転送するように設定できます。 Multi-Cloud Amazon VPC firewall – このファイアウォールは、AWS を経由して他のクラウドプロバイダー接続に向かうすべてのトラフィックに使用されます。各リージョンでアクティブ/スタンバイの 1 組が設定されます。 AWS WAF with AWS Shield – このファイアウォールは、Web アプリケーションの小売用 Web サーバーに送信されるすべての Web トラフィックに使用されます。これには、外部サポートを必要とするサードパーティーの Software-as-a-Service (SaaS) アプリケーションも含まれます。 一元管理されたファイアウォールマネージャーを使用することをおすすめします。高可用性と障害復旧のためには、複数のリージョンに展開する必要があります。 ローカルゾーン接続 ローカルゾーンは、必要に応じてワークロード用のミリ秒未満のレイテンシーをサポートできます。ローカルゾーンを使用すると、その店舗のリージョンの Amazon VPC は、コンピューティングリソースとストレージリソースをローカルゾーンに拡張できます。今後、サポートされるサービスが増えるにつれて、それらのサービスをローカルゾーンで利用できるようになります。Direct Connect を使用すると、リージョンへルーティングを戻さなくても、店舗のネットワークルーティングをローカルゾーンに直接拡張できます。 各ワークロードを分析して、ローカルゾーンが最適な選択肢かどうかを確認する必要があります。 スマートストアアプリケーション スマートストアアプリケーションには、相互に連携する必要のある店舗内コンポーネントとクラウドベースのコンポーネントの両方があります。たとえば、インタラクティブな統計情報を生成するためのカメラビジョンと人工知能と機械学習(AI/ML)処理の場合、ハードウェアを備えた AI コンポーネントは店舗にあり、データ分析とプレゼンテーションはクラウドで行われる場合があります。そうは言っても、店舗はかさばるハードウェアやサーバーを店舗内に置かず、商品を販売するためのスペースを空けたいと考えています。このような低レイテンシーの重要なソフトウェアの多くは、店舗がある場所の近くのローカルゾーンに導入できます。本ブログで説明されているネットワークアーキテクチャを利用することで、店舗はこの作業の負担を軽減できます。ローカルゾーンからは、店舗の貴重な帯域幅を使用することなく、AWS リージョンでデータを処理できます。 店舗とローカルゾーン間の通信のセキュリティは、プライベートネットワークを使用してローカルゾーンに直接接続するか、ローカルゾーンの仮想アプライアンスへの安全なトンネルを作成する店舗内の SD-WAN ベースのアプライアンスを使用してトラフィックを暗号化することで実現できます。もう 1 つの考慮は、トラフィックの優先順位です。コンピュータビジョン、RFID、スマートキオスク、ロボティクス、VOIP などの複数のスマートストアソリューションをサポートする場合、サービス品質が重要なニーズになります。店舗の帯域幅のニーズがブロードバンドアップリンク容量を超える時が来るでしょう。SD-WAN とDirect Connect のオーバーレイを使用すると、ネットワークエンジニアはビジネスニーズに基づいてトラフィックに優先順位を付けるポリシーを追加できます。このアーキテクチャは、スマートストア機能の有効化をサポートします。 まとめ 結論として、小売店向けの AWS ネットワークインフラストラクチャと接続オプションは、クラウドへの高性能で信頼性の高い接続を提供するように綿密に設計されています。 AWS Direct Connect 、SD-WAN 、ハイブリッドアプローチなど、さまざまな接続オプションがあるため、小売店は自分に最適なオプションを選択できます。さらに、AWS のサービスとベストプラクティスを活用することで、店舗はセキュリティと回復力を向上させながら、オンプレミスのハードウェアとメンテナンスの必要性を減らすことができます。 全体として、このネットワークインフラストラクチャと接続ソリューションは、小売店がクラウドに接続して事業運営をサポートするためのスケーラブルで柔軟かつ効率的な方法を提供します。 AWS の担当者 にお問い合わせいただき、当社がお客様のビジネスをどのように促進できるかをご確認ください。 参考文献 AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns Extending your VPC to Local Zones Smart Stores 著者について Ameel Kamboh Ameel Kamboh は AWS のシニアソリューションアーキテクトで、緊急通報ネットワークをグローバルに構築した経歴があります。ネットワークと複雑なアプリケーションの構築で 28 年以上の経験を持つ Ameel は、高可用性とスケーラビリティに重点を置いて設計してきました。AWS では、Ameel は小売企業部門での活動範囲を広げ、可能性を秘めた芸術をもたらす革新的なソリューションを顧客に提供してきました。 Chris Sereno Chris は AWS のソリューションアーキテクトで、ネットワーク分析のバックグラウンドを持っています。彼は、お客様がパフォーマンスと信頼性の高いアプリケーションを提供できるよう支援することに情熱を注いでいます。予定がないときには、キーボードを使って音楽を作るのを楽しんでいます。 Justin Swagler Justin Swagler は、AWS のフィジカル Retail のワールドワイド・ヘッドであり、フィジカル・リテールのグローバル戦略とソートリーダーシップを率いています。Justin は、イノベーション戦略、小売事業、製品開発、経営幹部など、消費者向けパッケージ商品、小売、戦略において 15 年以上にわたる経験があります。彼は、消費者体験を戦略的に革新し、再発明するよう組織を導くことに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号を、ケロッグ・スクール・オブ・マネジメントで経営学修士号を取得しています。 Rahul Nammireddy Rahul は AWS のシニアソリューションアーキテクトであり、デジタルネイティブのお客様をクラウドネイティブの変革に導くことに重点を置いています。彼は AI/ML テクノロジーに情熱を傾け、小売や通信などの業界の顧客と協力して、お客様の急速なイノベーションを支援しています。Rahul は 23 年以上にわたるキャリアを通じて、スタートアップ企業から上場企業まで、さまざまな企業で主要な技術指導的役割を果たしてきました。ビルダーとしての専門知識を披露し、イノベーションを推進してきました。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。
11月29日は、新機能を備えた Amazon OpenSearch Serverless 用ベクトルエンジン が一般公開されたことをお知らせします。2023 年 7 月に、Amazon OpenSearch Serverless 用ベクトルエンジンの プレビューリリースを発表 しました。これは、シンプルでスケーラブルで高性能な類似検索機能です。ベクトルエンジンを使用すると、基盤となるベクトルデータベースインフラストラクチャを管理することなく、最新の機械学習 (ML) 拡張検索エクスペリエンスや生成型人工知能 (生成系 AI) アプリケーションを簡単に構築できます。 数千次元の何十億ものベクトル埋め込みをミリ秒単位で保存、更新、検索できるようになりました。ベクトルエンジンの高性能な類似検索機能により、AI を活用した生成型アプリケーションでは、ミリ秒単位の応答時間で、正確で信頼性の高い結果を得ることができます。 また、ベクトルエンジンでは、ベクトル検索と全文検索を同じクエリで組み合わせることで、ハイブリッド検索で結果を最適化および調整できるため、個別のデータストアや複雑なアプリケーションスタックを管理および保守する必要がなくなります。ベクトルエンジンは、安全で信頼性が高く、スケーラブルでエンタープライズ対応のプラットフォームを提供し、プロトタイピングアプリケーションをコスト効率よく構築し、本番環境にシームレスに拡張できます。 専用のベクトルエンジンベースのコレクションを作成することで、ベクトルエンジンをすぐに使い始めることができます。コレクションとは、埋め込みを論理的にグループ化したもので、連携してワークロードをサポートします。 ベクトルエンジンは、 OpenSearch Compute Units (OCU)、つまりコンピュートキャパシティユニットを使用して、類似検索クエリを取り込んで実行します。1 つの OCU は、99 パーセントのリコール率で、128 次元の最大 200 万のベクトル、768 次元の 500,000 のベクトルを処理できます。 OpenSearch サーバーレス上に構築されたベクトルエンジンは、デフォルトでは可用性の高いサービスです。アカウントの最初の収集には、少なくとも 4 つの OCU (プライマリとスタンバイを含む取り込み用に 2 つの OCU、アベイラビリティーゾーン全体に 2 つのアクティブなレプリカがある検索用に 2 つの OCU) が必要です。同じ AWS Key Management Service (AWS KMS) キーを使用する以降のすべてのコレクションは、それらの OCU を共有できます。 GA での新機能とは? プレビュー以降、Amazon OpenSearch Serverless 用ベクトルエンジンは、検索拡張生成 (RAG) コンセプトを使用して生成系 AI アプリケーションを構築するための Amazon Bedrock のナレッジベース のベクトルデータベースオプションの 1 つになりました。 今回の GA リリースの新機能または改善された機能は次のとおりです。 冗長レプリカ (開発とテストに重点を置く) オプションを無効にする プレビューブログ記事 でお知らせしたように、この機能により、可用性のためだけに別のアベイラビリティーゾーンに冗長な OCU を用意する必要がなくなります。コレクションには 2 つの OCU (1 つはインデックス用、もう 1 つは検索用) を使用してデプロイできます。これにより、冗長レプリカを使用するデフォルトのデプロイと比較して、コストが半分に削減されます。コスト削減のため、この構成は開発およびテストワークロードに適しており、経済的です。 このオプションでも、ベクトルエンジンが Amazon S3 のすべてのデータを保持するため、耐久性は保証されますが、シングル AZ に障害が発生すると、可用性に影響が及びます。 冗長レプリカを無効にする場合は、新しいベクトル検索コレクションを作成するときに [冗長性を有効にする] のチェックを外してください。 開発とテストに重点を置いたオプション用のフラクショナルOCU 開発とテストに重点を置いたワークロードに対して OCU の部分課金をサポートする (つまり、冗長レプリカオプションがない) ため、ベクトル検索コレクションの最低価格が下がります。ベクトルエンジンは、最初は小さい 0.5 OCU を導入しながら、同じ機能を低スケールで提供し、ワークロードの需要に合わせてフル OCU 以上までスケールアップします。このオプションを使用すると、ベクトルエンジンを試す際の月額コストをさらに削減できます。 10 億スケールの自動スケーリング ベクトルエンジンのシームレスな自動スケーリングにより、スケーリングのためにインデックスを再作成する必要がなくなります。プレビューでは、約 2,000 万のベクトル埋め込みをサポートしていました。ベクトルエンジンが一般公開されたことで、10 億のベクトルスケールをサポートできるよう制限を引き上げました。 今すぐご利用いただけます Amazon OpenSearch Serverless 用ベクトルエンジン は、Amazon OpenSearch Serverless が利用可能なすべての AWS リージョンで利用できるようになりました。 はじめに、次のリソースを参照してください。 Amazon OpenSearch Serverless 用ベクトルエンジンのご紹介 (現在プレビュー中) Amazon OpenSearch Service のベクトルエンジンでセマンティック検索を試してみる Amazon OpenSearch Service のベクトルデータベース機能の説明 OpenSearch をベクトルデータベースとして使う Amazon OpenSearch Serverless 入門ドキュメント デモビデオ: ベクトル検索用の Amazon OpenSearch Service デモビデオ: 検索機能の強化: OpenSearch と一括ベクトル検索 お試しいただき、 AWS re:Post for Amazon OpenSearch Service 、または通常の AWS サポート窓口までフィードバックをお送りください。 – Channy 原文は こちら です。
11月29日は、 Amazon SageMaker HyperPod を紹介します。この製品は、大規模な分散トレーニング専用のインフラストラクチャを提供することで、基盤モデル (FM) のトレーニング時間を短縮するのに役立ちます。SageMaker がクラスターの状態をアクティブに監視し、障害のあるノードを交換してチェックポイントからモデルトレーニングを再開することで、ノードとジョブの回復を自動化しながら、SageMaker HyperPod を使用して FM を数週間から数か月間トレーニングできるようになりました。 クラスターには、SageMaker の分散トレーニングライブラリがあらかじめ設定されています。これにより、トレーニングデータとモデルをすべてのノードに分割して並列処理し、クラスタのコンピューティングとネットワークインフラストラクチャを最大限に活用できます。追加のフレームワーク、デバッグツール、最適化ライブラリをインストールすることで、トレーニング環境をさらにカスタマイズできます。 SageMaker HyperPod を使い始める方法を紹介します。次のデモでは、SageMaker HyperPod を作成し、 AWS ML トレーニングリファレンスアーキテクチャ GitHub リポジトリで共有されている例を使用して Llama 2 7B モデルをトレーニングする方法を示します。 クラスターの作成と管理 SageMaker HyperPod 管理者は、 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用してクラスターを作成および管理できます。  コンソールで 、 Amazon SageMaker に移動し、左側のメニューの [HyperPod クラスター] で [クラスター管理] を選択し、その後 [クラスターの作成] を選択します。 以下のセットアップでは、クラスター名を指定し、選択したインスタンスタイプと各インスタンスグループに割り当てるインスタンスの数でインスタンスグループを設定します。 また、クラスターの作成時に各インスタンスグループで実行するライフサイクルスクリプトを 1 つ以上準備して Amazon Simple Storage Service (Amazon S3) バケットにアップロードする必要があります。ライフサイクルスクリプトを使用すると、クラスター環境をカスタマイズし、必要なライブラリとパッケージをインストールできます。SageMaker HyperPod のライフサイクルスクリプトの例は、GitHub リポジトリにあります。 AWS CLI を使用する AWS CLI を使用してクラスターを作成および管理することもできます。このデモでは、JSON ファイルでクラスター構成を指定します。2 つのインスタンスグループを作成することにしました。1 つは「controller-group」と呼ばれるクラスターコントローラーノード用で、もう 1 つは「worker-group」と呼ばれるクラスターワーカーノード用です。 モデルトレーニングを行うワーカーノードには、 AWS Trainium チップを搭載した Amazon EC2 Trn1 インスタンスを指定します。 // demo-cluster.json { "InstanceGroups":[ { "InstanceGroupName": "controller-group", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "lifecycleConfig": { "SourceS3Uri": "s3://<your-s3-bucket>/<lifecycle-script-directory>/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/my-role-for-cluster", "ThreadsPerCore": 1 }, { "InstanceGroupName": "worker-group", "InstanceType": "trn1.32xlarge", "InstanceCount": 4, "lifecycleConfig": { "SourceS3Uri": "s3://<your-s3-bucket>/<lifecycle-script-directory>/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/my-role-for-cluster", "ThreadsPerCore": 1 } ] } クラスターを作成するには、次の AWS CLI コマンドを実行します。 aws sagemaker create-cluster \ --cluster-name antje-demo-cluster \ --instance-groups file://demo-cluster.json 作成時に、 aws sagemaker 記述クラスター と aws sagemaker リストクラスターノード を使用して、クラスターとノードの詳細を表示できます。コントローラーノードのクラスター ID とインスタンス ID を書き留めます。クラスターに接続するには、その情報が必要です。 また、 Amazon FSx for Lustre などの共有ファイルシステムをアタッチすることもできます。FSx for Lustre を使用するには、 Amazon Virtual Private Cloud (Amazon VPC) 設定を使用してクラスターをセットアップする必要があります。これは SageMaker VPC を作成する方法と Lustre に FSx をデプロイ する方法を示す AWS CloudFormation テンプレートです。 クラスターに接続するには、 クラスターユーザーは、クラスター管理者によってプロビジョニングされたクラスターにアクセスできる必要があります。アクセス権限を設定したら、SSH を使用してクラスターに接続し、ジョブをスケジュールして実行できます。プリインストールされている AWS Systems Manager 用の AWS CLI プラグイン を使用して、クラスターのコントローラノードに接続できます。 デモでは、コントロールノードのクラスター ID とインスタンス ID をターゲットとして指定して、次のコマンドを実行します。 aws ssm start-session \ --target sagemaker-cluster:ntg44z9os8pn_i-05a854e0d4358b59c \ --region us-west-2 Slurm を使用してクラスターでジョブをスケジュールして実行する 発売時には、SageMaker HyperPod は Slurm によるワークロードオーケストレーションをサポートしています。Slurm は人気のあるオープンソースのクラスター管理およびジョブスケジューリングシステムです。クラスター作成の一環として、ライフサイクルスクリプトを使用して Slurm をインストールして設定できます。ライフサイクルスクリプトの例はその方法を示しています。次に、標準の Slurm コマンドを使用してジョブをスケジュールし、起動できます。アーキテクチャの詳細と役立つコマンドについては、 Slurm クイックスタートユーザーガイド をご覧ください。 このデモでは、 AWS ML トレーニングリファレンスアーキテクチャ GitHub リポジトリにあるこの例 を使用して、Trn1 インスタンスを使用して Slurm で Llama 2 7B をトレーニングする方法を示しています。私のクラスターはすでに Slurm でセットアップされており、Lustre ファイルシステムの FSx がマウントされています。 注意 Llama 2 モデルは Meta によって管理されています。 Meta リクエストアクセスページ からアクセスをリクエストできます。 クラスター環境のセットアップ SageMaker HyperPod は、 Conda 、 venv 、 Docker 、 enroot など、さまざまな環境でのトレーニングをサポートしています。 README の指示に従って、仮想環境 aws_neuron_venv_pytorch を構築し、Trn1 インスタンスでモデルをトレーニングするための torch_neuronx と neuronx-nemo-megatron ライブラリをセットアップしました。 モデル、トークナイザー、データセットの準備 指示に従って Llama 2 モデルとトークナイザーをダウンロードし、モデルを Hugging Face 形式に変換します。次に、 RedPajama データセット をダウンロードしてトークン化します。最後の準備ステップとして、モデルトレーニングをスピードアップするために、事前 (AOT) コンパイルを使用して Llama 2 モデルをプリコンパイルします。 クラスターでジョブを起動する これで、 sbatch コマンドを使用してモデルトレーニングジョブを開始する準備ができました。 sbatch --nodes 4 --auto-resume=1 run.slurm ./llama_7b.sh squeue コマンドを使用してジョブキューを表示できます。トレーニングジョブが実行されると、SageMaker HyperPod の復元機能が自動的に有効になります。SageMaker HyperPod は、前述のコマンドに示すように、ハードウェア障害を自動的に検出し、必要に応じてノードを交換し、 自動再開 パラメーターが設定されている場合はチェックポイントからトレーニングを再開します。 モデルトレーニングジョブの出力は、次のファイルで確認できます。 tail -f slurm-run.slurm-<JOB_ID>.out モデルトレーニングが開始されたことを示すサンプル出力は、次のようになります。 Epoch 0: 22%|██▏ | 4499/20101 [22:26:14<77:48:37, 17.95s/it, loss=2.43, v_num=5563, reduced_train_loss=2.470, gradient_norm=0.121, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.40] Epoch 0: 22%|██▏ | 4500/20101 [22:26:32<77:48:18, 17.95s/it, loss=2.43, v_num=5563, reduced_train_loss=2.470, gradient_norm=0.121, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.40] Epoch 0: 22%|██▏ | 4500/20101 [22:26:32<77:48:18, 17.95s/it, loss=2.44, v_num=5563, reduced_train_loss=2.450, gradient_norm=0.120, parameter_norm=1864.0, global_step=4512.0, consumed_samples=1.16e+6, iteration_time=16.50] モデルトレーニングジョブをさらに監視してプロファイリングするには、 SageMaker がホストする TensorBoard やその他の任意のツールを使用できます。 今すぐご利用いただけます SageMaker HyperPod は、本日より AWS リージョンの米国東部 (オハイオ州)、米国東部 (バージニア州北部)、米国西部 (オレゴン州)、アジアパシフィック地域 (シンガポール)、アジア太平洋地域 (シドニー)、アジアパシフィック地域 (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) でご利用いただけます。 詳細はこちら。 価格情報とサポートされているクラスターインスタンスタイプのリストについては、 Amazon SageMaker HyperPod を参照してください デベロッパーガイド をご覧ください AWS マネジメントコンソールにアクセスして、SageMaker HyperPod で FM のトレーニングを開始してください –  Antje PS: AWS でブログ記事を書くのは、投稿タイトルの下に名前が 1 つしかない場合でも、常にチームの努力が必要です。今回は、 Brad Doran 、 Justin Pirtle 、 Ben Snyder 、 Pierre-Yves Aquilanti 、 Keita Watanabe 、 Verdi March の各氏に、サンプルコードの提供や、大規模モデル学習インフラ、Slurm、SageMaker HyperPod の管理に関する専門知識の共有など、惜しみない協力をいただきました。 原文は こちら です。
11月29日、 アンソロピックのクロード2.1 ファンデーションモデル (FM) が Amazon Bedrock で発売されたことをお知らせします。先週、Anthropic は最新モデルである クロード 2.1 を発表しました。これは、業界をリードする200,000トークンのコンテキストウィンドウ (クロード 2.0の2倍)、幻覚発生率の低減、長い文書の精度の向上、システムプロンプト、関数呼び出しとワークフローオーケストレーションのためのベータツール使用機能など、企業向けの主要な機能を提供します。 Amazon Bedrock でクロード 2.1が利用可能になったことで、Anthropic のより正直で信頼性の高い AI システムを使用して、 エンタープライズ対応のジェネレーティブ人工知能 (AI) アプリケーションを構築できます。Anthropic が提供する クロード 2.1 モデルを Amazon Bedrock コンソール で使用できるようになりました。 Amazon Bedrock の新しいクロード2.1モデルに関する主なハイライトは次のとおりです。 200,000トークンのコンテキストウィンドウ — エンタープライズアプリケーションでは、製品ガイド、技術文書、財務諸表、法的声明などの長い文書を扱う場合、より大きなコンテキストウィンドウとより正確な出力が必要になります。クロード 2.1は20万トークンをサポートしています。これは約15万語、つまり500ページを超える文書に相当します。豊富な情報をクロードにアップロードすると、要約、質疑応答、傾向の予測、複数の文書の比較対照が可能になり、事業計画の立案や複雑な契約の分析が可能になります。 精度の大幅な向上 — クロード 2.1 では、クロード 2.0 と比較して、幻覚発生率が2倍低下し、自由形式の会話やドキュメント Q&A での幻覚が 50% 減少し、不正回答が 30% 減少し、文書が特定の主張を裏付けていると誤って結論付ける割合が 3〜4 倍減少するなど、誠実さも大幅に向上しました。クロードは自分が知らないことを知るようになり、幻覚を起こすよりも反論する可能性が高くなります。この精度の向上により、顧客や従業員向けに、より信頼性の高いミッションクリティカルなアプリケーションを構築できます。 システムプロンプト — クロード 2.1では、システムプロンプトがサポートされるようになりました。これは、ロールプレイングシナリオ、特に長時間の会話でのキャラクターの深みと役割の順守の向上、ガイドライン、ルール、指示の厳守など、さまざまな方法で Claude のパフォーマンスを向上させる新機能です。これは構造的な変化を表していますが、クロードの以前の促し方からの内容の変化ではありません。 関数呼び出しとワークフローオーケストレーションのためのツールの使用 — ベータ機能として提供される クロード 2.1 は、既存の社内プロセス、製品、API と統合して、生成的な AI アプリケーションを構築できるようになりました。クロード 2.1は、追加のナレッジソースからデータを正確に取得して処理するだけでなく、特定のタスクの関数を呼び出します。 クロード 2.1 では、プライベート API や ウェブ 検索 API を使用してデータベースを検索して質問に答えたり、自然言語のリクエストを構造化された API 呼び出しに変換したり、製品データセットに接続してレコメンデーションを行ったり、顧客の購入を支援したりすることができます。この機能へのアクセスは現在、一部の早期アクセスパートナーに限定されており、近い将来にオープンアクセスが予定されています。早期アクセスに興味がある場合は、AWS アカウントチームにお問い合わせください。 クロード2.1の特徴と機能の詳細については、 Amazon Bedrock の Anthropic クロードと Amazon Bedrock のドキュメント をご覧ください。 クロード2.1のアクション Amazon Bedrock で クロード 2.1 を使い始めるには、 Amazon Bedrock コンソールにアクセスしてください 。左下のペインで モデルアクセス を選択し、右上の モデルアクセスの管理 を選択し、ユースケースを送信して、Anthropic クロード モデルへのモデルアクセスをリクエストします。モデルにアクセスするには数分かかる場合があります。既にクロード モデルにアクセスできる場合は、クロード 2.1 へのアクセスを別途リクエストする必要はありません。 チャットモードで クロード 2.1 をテストするには、左側のメニューペインの プレイグラウンド で テキスト または チャット を選択します。次に Anthropic を選択し、次に クロード v2.1を選択します 。 API リクエストを表示 を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK のコード例を使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルは次のとおりです。 $ aws 岩盤ランタイム呼び出しモデル\       --model-id anthropic.claude-v2:1 \       --body "{\"prompt\":\"Human: \\n\\nHuman: Tell me funny joke about outer space!\n\nAssistant:", "max_tokens_to_sample": 50}' \       --cli-binary-format raw-in-base64-out \       invoke-model-output.txt Claude 2.1 モデルで提供されるシステムプロンプトエンジニアリング手法を使用できます。この手法では、その内容を参照または利用する質問の前に、入力やドキュメントを配置します。入力には、自然言語テキスト、構造化文書、 <document> 、 <papers> 、 <books> 、または タグを使用したコードスニペットなどがあります。チャット履歴などの会話テキストや、チャンク化されたドキュメントなどの検索拡張生成 (RAG) 結果を使用することもできます。 これは、サポートエージェントが企業文書に基づいて顧客の質問に回答するためのシステムプロンプトの例です。 タスクで参照できるドキュメントは次のとおりです。 <documents>  <document index="1">   <document_content>   (文書のテキストコンテンツ-一節、ウェブページ、記事などが考えられます)    </document_content> <document index="2">   <source>https://mycompany.repository/userguide/what-is-it.html</source> </document> <document index="3">   <source>https://mycompany.repository/docs/techspec.pdf</source>  </document> ... </documents> あなたはラリーで、会社の製品について深い知識を持つカスタマーアドバイザーです。ラリーは、顧客がナンセンスなことを言ったり、皮肉っぽいことを言ったりしても、顧客に対して非常に忍耐強いです。ラリーの答えは丁寧ですが、時には面白いこともあります。しかし、彼は会社の製品に関する質問に答えるだけで、他の質問についてはあまり知りません。提供されているドキュメントを使用して、ユーザーの質問に答えてください。 人間: 私が操作すると、あなたの製品は奇妙なスタッター音を出しています。何が問題なの? Amazon Bedrock のプロンプトエンジニアリングの詳細については、Amazon Bedrock のドキュメントに含まれている プロンプトエンジニアリングガイドライン を参照してください。クロードを含む Amazon Bedrock テキストモデルの一般的なプロンプトテクニック、テンプレート、例を学ぶことができます。 今すぐご利用いただけます クロード 2.1 は現在、米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけます。 支払いは実際に使用した分のみで、オンデマンドモードでは時間ベースの契約は不要です。テキスト生成モデルでは、処理された入力トークンと生成されたすべての出力トークンに対して課金されます。または、時間ベースの契約と引き換えに、アプリケーションのパフォーマンス要件を満たすのに 十分なスループット をプロビジョニングすることもできます。詳細については、「 Amazon Bedrock 価格設定 」を参照してください。 Anthropic Claude 2.1 を今すぐ Amazon Bedrock コンソールで試して、Amazon Bedrock の AWS re にフィードバックを投稿するか、通常の AWS サポートの連絡先を通じて投稿してください。 — チャニー 原文は こちら です。
本稿では  カヤバ株式会社 (以下、カヤバ)において、データとデジタル技術を活用できるデジタル人財の育成を目指し、AI ハッカソンなどを活用して教育の体系化・内製化を推し進めた取り組みについてご紹介します。 この取り組みについてより詳しくご覧になりたい方は カヤバ技報 第66号 デジタル人財育成の取組み  もご覧ください。(カヤバでは社員は会社の「財産」との認識があり、「人材」を「人財」と称しています) また本活動と並行して実施した、内製化によるシステムモダナイゼーションの取り組みについては こちら でご紹介しています。 デジタル人財育成の必要性 カヤバは、四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。これまでに予知保全システムでのクラウド利用をきっかけとして 2017 年より AWS 上で クラウドネイティブな IoT プラットフォーム を構築し、社員が場所や時間の制約を受けることなく柔軟にデータを活用できる、コスト効率に優れた基盤を提供してきました。 カヤバでは 2019 年に設立された DX 推進部(現、デジタル変革推進本部)が旗振り役となり、ロードマップとして独自に6段階からなるデータ活用のステップを定義し、デジタルトランスフォーメーションを加速を目指しています。 図: データ活用ステップ 個人に依存したデータ活用から、あらゆる社員がデータを利用できる民主化、データ主導の意思決定を経て、ビジネスモデルの変革に至るこのステップを滞りなく進めるためには、システムの整備だけではなく、それを活用できる人財の育成が必要不可欠です。カヤバでは目指すべきデジタル人財を「デジタル技術を扱うテクノロジースキルとビジネス変革スキルを兼ね備えた人財」と定義し、特に重点的な育成が必要な分野と位置付けた AI (Artificial Intelligence) および BI (Business Intelligence) について、社員一人一人が次に目指すべきレベルを明確化するためにスキル別の階級策定表を策定し、また成長を支援するための教育計画を策定し、年間を通じて教育プログラムを提供しています。   図: デジタル人財 スキル別の階級策定表 図: デジタル人財育成の教育計画 AI 人財育成の取組み カヤバでは上記教育計画に基づいて、AI および BI の人財育成に重点的に取り組んでいますが、ここではそのうち AI に関する取り組みについてご紹介します。 AI人財育成では「AI教育カリキュラム」および「AIコミュニティ」の 2 つが活動の主たる柱となっています。 AI教育カリキュラム AI教育カリキュラムは知識や技術の習得を目的として、基礎理論からサービス化を視野に入れた実践的な内容までを網羅的にカバーしています。データサイエンティストやデータエンジニア、機械学習エンジニアが相互に円滑なコミュニケーションをとりながら技術的に連携できるよう、すべての受講生に対して MLOps を考慮した教育カリキュラムの提供を目指しており、2022年はAI基礎、プログラミング基礎、AWS基礎、AI実践の4種類の講座と、AIハッカソンプログラムを展開しました。AIハッカソンについては後述します。 AIコミュニティ AIコミュニティは、製品開発や生産技術など様々な領域から集まった人財がAI/MLに関する知識や技術について意見を交換しています。チャットツール上で社員がオープンに交流する場を提供し、またグループワークとして日頃の開発業務で抱えている具体的な課題を募集し、メンバが協力して解決を試みるなどの試みを行なっています。 AI ハッカソン 通年の教育カリキュラムで習得した知識や技術をチーム単位でアウトプットするイベントとして、2022 年より AWS の支援を得て AI ハッカソンを開催しています。 ハッカソンでは DX 推進部が運営主体となり、参加者は4人毎のチームを組んで運営から提供された仮想の課題に対して協力して機械学習によるソリューションの開発を行います。この活動では、単に機械学習モデルを実装するだけでなく、機械学習モデルの運用の仕組みや、AWS が提唱する Well-Architectedフレームワークへの適合なども課題として採用しました。2022年度は DX 推進部を含む 5 部署から計 16 名の社員が AI ハッカソンに参加し、3 ヶ月の活動期間中は週次のオフィスアワーとして AWS のソリューションアーキテクトへ自由に相談できる場を用意することで、チームが検討している設計や機械学習に関する実装上の不明点の解決をサポートしました。 ハッカソンの最後に実施した成果発表会では、カヤバの経営層や AWS 社が参加し、チーム毎に機械学習モデルの実装結果や機械学習システムの設計に関する工夫点を発表しました。 図: 成果発表会資料 2023年には、2022年のAIハッカソン受講生が担当する開発テーマの中から 2 つがプロジェクト化され、実証実験 (PoC: Proof of Concept) が開始されました。生産領域から製造ラインの外観検査におけるMLOps基盤の開発を、製品領域からCAEとAIを融合させたサロゲートモデルの活用基盤の開発に着手し、2024年から順次、運用を見込んでいます。 図:製造ラインの外観検査におけるMLOps基盤 図:サロゲートモデルの活用基盤 まとめ・今後について 本稿では,カヤバにおけるデジタル人財育成の取組みをご紹介しました。カヤバでは教育の目的は、社員が習得した知識や技術を日頃の開発業務に応用し、ビジネスに貢献することで初めて達成されると考えています。カヤバは今後も社内のデータ活用事例を増やし、DXの実現に向けて世の中のトレンドを意識しながら,必要な教育カリキュラムを展開・拡大していく予定です。   本稿はソリューションアーキテクト 内田、石井が担当し、カヤバ株式会社 デジタル変革推進本部 宮内 悠樹との共同執筆です。デジタル人材育成に取り組む方の参考となれば幸いです。 カスタマープロフィール: カヤバ株式会社 (KYB Corporation) 1919 年創業、設立1948 年。従業員数: 13,920名(2023年度・連結)四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。
本稿では  カヤバ株式会社 (以下、カヤバ)のデジタル変革推進本部が中心となり、オンプレミスに存在したシステム群を内製化によってクラウドネイティブなアーキテクチャへと移行した、モダナイゼーションの取り組みについてご紹介します。 また本活動と並行して教育の体系化・内製化を推し進めた取り組みについては こちら でご紹介しています。 移行の背景と課題 カヤバは、四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。これまでに予知保全システムでのクラウド利用をきっかけとして 2017 年より AWS 上で クラウドネイティブな IoT プラットフォーム を構築し、社員が場所や時間の制約を受けることなく柔軟にデータを活用できる、コスト効率に優れた基盤を提供してきました。 カヤバでは社内のデジタルトランスフォーメーションを加速することを目的として 2019 年に DX推進部(現在のデジタル変革推進本部)を設立し、その活動の一環として古くから長期稼働しているシステムの次世代化を推進してきました。この活動の一環として、2021 年下期に品質データ管理システムが内製化の対象に選ばれ、検討が始まりました。品質データ管理システムは、製品のトレーサビリティを実現するものであり、工場設備や試験機から収集された製品の加工条件や試験計測値などの品質情報を保存しています。旧来のシステムはオンプレミスで運用されており、主に3つの課題に直面していました。 課題1. メンテナンスコスト 20年以上稼働する当該システムは必ずしも正しく文書化されておらず、機能の修正や追加をする際にソースコードを直接確認しなければならないケースが頻発していました。また、Oracle Database をはじめとする商用ソフトウェアのサポートサービス費用がメンテナンスコスト最適化の足枷せとなっていました。 課題2. 可用性とセキュリティ 旧来のシステムは冗長化されていないサーバーコンポーネントが存在したことでシステムダウンを招くことがあり、また DR (Disaster Recovery: 災害復旧 ) 対策の不完全さによって広域災害時に業務が停止するリスクを抱えていました。また 2018 年には従業員によるコンプライアンス上の問題が露見し、改ざんをはじめとするデータベースの不正操作を検知する仕組みの導入も急務となっていました。 課題3. パフォーマンス 品質データ管理システムで使用しているデータベースは 20 年前の設計時と比較して取り扱うデータ量が拡大しており、最低限の正規化しか行われていない大福帳型のスキーマ構造では周辺システムとのデータ連携を行う際に十分なパフォーマンスを提供することができませんでした。 以下のアーキテクチャ図は、旧来のオンプレミスシステムの主要なコンポーネントを表したものです。 図: オンプレミスシステムのアーキテクチャ 前述の課題を解決するため、次のようなソリューションを検討し、適用しました。 1. サーバーレスサービスの活用 メンテナンスコストの課題への対策として、AWS の各種サーバーレスサービスの活用を推進しました。従来、ファイルサーバー上から別のサーバーへファイルを転送して処理していたアーキテクチャを、Amazon S3 や AWS Lambda を活用するアーキテクチャに変更することで、個々のサーバーに対するパッチ適用など運用工数を削減することができました。またサービスが提供するAWSリージョン内での冗長性やリージョン間のデータ連携機能等を活用することで広域災害への対応を強化することができました。リアーキテクチャにあたっては改修工数が発生しましたが、改修に要した期間はオンプレミスを前提とした予測よりも短期で完了することができました。 2. Amazon Quantum Ledger Database (Amazon QLDB) の導入 データの改ざん防止に適したフルマネージド型の台帳データベースである Amazon QLDB を導入しました。Amazon QLDB に品質データを保存することによって、完全かつ検証可能な変更履歴を長期に渡って保持し、管理者を含むあらゆる権限でのデータの変更を確実に追跡することが可能となりました。Amazon QLDB  に品質データのマスタを格納することに加え、社内ユーザーのニーズに応えるために複数の AWS サービスとの組み合わせでソリューションを提供しました。例えば、オンプレミス環境での SQL 検索の需要に応えるために、Amazon QLDB から Amazon Aurora PostgreSQL へデータを同期し、SQL 検索が可能になるようにしました。さらに、可視化の要望に応えて Tableau でダッシュボードを構築しました。SQL 検索機能に関しては、Amazon QLDB とのデータ連携に Amazon Kinesis Data Streams を使用し、データの順序保証には AWS Step Functions と AWS Lambda を利用した実装を行いました。 3. Amazon Aurora PostgreSQL の導入 周辺システムとの連携でパフォーマンスの課題が発生していたデータベースを、Amazon Aurora PostgreSQL に移行されました。また Amazon Aurora Global Database によってデータベースをリージョン間にレプリケーションすることで、今後の予定されている世界中の拠点からの利用拡大に際しても、アプリケーションからネットワーク上の距離が近い場所からデータを提供することが可能になりました。移行に際してはスキーマの正規化やコード体系の見直しも合わせて実施したことで、複数のシステム間でのデータ連携もスムーズに行うことができるようになりました。 これらの対策を取り入れ、新たに構築したシステムのアーキテクチャは以下の通りです。 図: クラウド上に新たに構築したアーキテクチャ 導入効果と今後の展望 前述の三つの課題(メンテナンスコストの増加、可用性とセキュリティ、パフォーマンス)を解決し、コストの最適化、システムの信頼性の向上、パフォーマンスの向上を実現しました。2023 年 9 月からは一部の工場での本格稼働を開始し、国内外での展開を計画中です。導入効果として、コスト面では従来のオンプレミス環境と比較して 5 年間で約 80% の削減が見込まれており、この削減には Oracle Database から Amazon Aurora PostgreSQL への変更、そしてアーキテクチャのサーバーレス化が寄与しています。 次の図はオンプレミスからクラウドへの移行パターンを示しています。今回の移行では、紫色の線で表されたリファクタの戦略を採用しました。単なるリホスト(Lift and Shift、オレンジ色の線)と比べると、リファクタには多くの工程を要することに気づかれるかもしれません。特に再設計が必要な箇所は高度な知識を要し、既存の設計と実装に加えて AWS の仕様に精通していることも求められました。このプロジェクトを実質約 1 年で内製化し成功させた実績は、品質データ管理システムに留まらず、他のシステムへも応用可能であると信じており、将来的にはサーバーコストを大きく削減できると考えています。 図: AWS への移行戦略 本稿はソリューションアーキテクト 内田、石井が担当し、カヤバ株式会社 デジタル変革推進本部 古川 輝との共同執筆です。Amazon QLDB をはじめとするAWSのマネージドサービスを活用したモダナイゼーションに取り組む方の参考となれば幸いです。 カスタマープロフィール: カヤバ株式会社 (KYB Corporation) 1919 年創業、設立1948 年。従業員数: 13,920名(2023年度・連結)四輪車や二輪車のショックアブソーバー、建設機械用油圧シリンダー、コンクリートミキサー車などの技術や製品を提供しています。
コンビニエンスストアという名前からもわかるように、コンビニエンスストアは速く便利なことを目的としています。 平均的な消費者が店内で過ごす時間は 3~4 分です 。ほとんどの消費者が店に入るときには、すでに何を買うか決めてます。 しかし、その利便性は、消費者が長いレジの行列を見たときに台無しになることがあります。残念ながら、消費者の「長い」という認識は必ずしも寛容ではありません。ある 調査 では、消費者の 15% が 1 分以上待たされると、必需品でないものの購入を諦めることがわかりました。彼らの半数は、わずか 30 秒待っただけで店を出て行くと言いました。 しかし、テクノロジーによって 30 秒の待ち時間を解消することができます。Amazon の Just Walk Out テクノロジー は、この便利さを実現した例です。 Just Walk Out テクノロジーが実装された店舗では、消費者は必要なものを手に取り、ただ出ていくだけでいいのです – レジに並ぶ必要は全くありません。Amazon は、自社のコンビニエンスストアである Amazon Go だけでなく、旅行小売、スポーツスタジアム、ライブイベント会場などのサードパーティーが運営するコンビニエンスストアおよび、コンビニ企業向けにこのテクノロジーを実装しました。 Amazon の Just Walk Out テクノロジー担当バイスプレジデントである Jon Jenkins は、「 Just Walk Out テクノロジーは、コンビニエンスストア運営者がコンシューマージャーニーのビジョンを設定できるようにすると同時に、迅速で便利なショッピング体験という目的を達成するのに役立つ」と説明しました。「コンビニエンスストアには、エンドツーエンドの店舗ジャーニーを柔軟に設計してもらいたいと考えています。コンビニエンスストアは、入退店体験、購入後の消費者体験、商品価格設定、支払い方法など、取り入れたい機能を定義できます」と彼は言います。 テクノロジーを活用したアクション Just Walk Out テクノロジーを採用した店舗に入るには、消費者はクレジットカードを挿入またはタップしたり、アプリやデジタルウォレットを使用したり、 Amazon One デバイスの上に手のひらをかざしたりすることで入店できます。 Amazon One は、消費者が支払いから入店まで、さまざまな体験を簡単にする手のひらを使った ID ソリューションです。Amazon One を初めて利用する消費者は、数秒で登録できます。一度登録すれば、Amazon One を導入している場所ならどこでも、手のひらを使って入店し支払いができます。 「いったん店に入ると、消費者はいつものように買い物をすればよいだけです。」と Jenkins は言います。「消費者が棚から取り出したものはすべて自動的に仮想ショッピングカートに追加され、棚に戻したものはすべて仮想ショッピングカートから削除されます。たとえば、棚からソーダを取り出すと、そのソーダは仮想ショッピングカートに入れられ、買い物が終わって店を出たときに請求されます。」 チェックアウトの手間を省く 店舗での買い物をより速くするため、多くのコンビニエンスストアはセルフレジを導入しています。セルフレジを導入することでレジ担当者の数を減らし、消費者に支払いオプションを増やすことができますが、その反面、消費者の利便性を低下させる結果となります。 セルフレジでは、消費者は商品のバーコードを見つけて、スキャンするか手動で入力しなければなりません。そして POS 機器から支払いデバイスに切り替えて購入しなければなりません。セルフレジのプロセスには多くの間違いが起こりやすく、実際に頻繁に起こっています。消費者が速やかな買い物を期待している時に、レジのプロセスに問題が発生したり、前の人が問題に直面していて列が停滞すると、イライラと苛立ちを感じることになります。 これとは対照的に、Just Walk Out テクノロジーはチェックアウトの手間を省き、コンビニエンスストアのオペレーションとスタッフの効率化を支援します。Jenkins は次のように語っています。「レジなしの店舗では、消費者は自分のペースで入店し、買い物を楽しみ、帰宅できるため、消費者の不満は最小限に抑えられます。」 運用の最適化とパフォーマンスの向上 Just Walk Out テクノロジーは、コンビニエンスストア事業者に複数のメリットをもたらします。レジの行列をなくすことで、スタッフはより良い体験を提供することに注力できます。「スタッフは、消費者への対応、質問への回答、商品の探し方の手伝い、必要に応じての陳列棚の補充などに、より多くの時間を費やすことができ、レジ操作や支払い処理などに時間を取られなくて済みます。この技術は、コンビニエンスストアが従業員を支払い処理のような反復的な機能から、よりエンゲージメントの高い消費者中心の機能へとシフトするのに役立ちます。」 Just Walk Out テクノロジーは、コンビニエンスストアがスペースの生産性を最大化するのにも役立ちます。コンビニエンスストアは伝統的に小規模な店舗です。従来の POS システム専用のスペース(通常は視認性の高いエリア)をなくすことで、コンビニエンスストアはそのスペースを再割り当てして、より多くのより良い製品配置やプロモーションを行うことができます。 さらに、コンビニエンスストア事業者はは、Just Walk Out アナリティクスを利用することで、自社の Just Walk Out テクノロジー対応店舗における商品の検討、受け取り、棚への返品、購入方法に関するインサイトを得ることができます。 e コマースサイトについて考えてみてください。小売業者は、最初にクリックされた商品、よく一緒に閲覧された商品、最終的に購入された商品を確認できます。Just Walk Out アナリティクスは、コンビニエンスストアのリーダーに実店舗についてもこれと同レベルの洞察を提供します。Just Walk Out アナリティクスを使うと、コンビニエンスストアのリーダーは、店舗全体および棚別、備品別、製品カテゴリ別の商品インタラクションをスケーラブルでデータ主導型のビューで把握できます。この洞察は、コンビニエンスストアのリーダーが商品の品揃えや配置を改善し、オペレーション効率を高め、消費者の店舗体験を向上させるのに役立ちます。 消費者とコンビニエンスストア事業者は同じような目標を共有しています。どちらも、買い物を簡単にする店舗体験を求めています。「 Just Walk Out テクノロジーは双方にメリットをもたらします」と Jenkins は言います。「レジの列に並ぶ必要がなくなるため、消費者は忙しい生活の中でも簡単に店舗に入って必要なものを購入することができます。それがこのテクノロジーによって可能になることであり、この体験をより多くのお客様に提供できることを楽しみにしています。」 Amazon の Just Walk Out テクノロジーとコンビニエンスストア向け Amazon One の 詳細 をご覧ください。 翻訳はソリューションアーキテクトの小西が担当しました。原文は こちら です。
本記事は How to: Create a VR application with user insights using AWS Amplify and WebXR を翻訳したものです。 このブログでは、 AWS Amplify と Babylon.js の WebXR 実装 を使用して、ユーザーのインサイトを活用したバーチャルリアリティ体験を作成する方法について学びます。この組み合わせによって、最初のバーチャルリアリティ(VR)アプリケーションを立ち上げる際のハードルを下げることができるでしょう。 このハウツーでは、AWS Amplify を使用してフルスタックアプリケーションをホストし、Babylon.js の WebXR 実装で VR シーンと機能を提供し、 Amazon DynamoDB を使用してユーザーイベントを保存し報告する、シンプルな VR 対応アプリケーションを作成する手順をカバーします。アプリケーションは Amplify と Babylon.js を使用して設定され、デプロイされます。コントローラーの入力データは WebXR を使用して有効にされ、ユーザーの入力イベントは DynamoDB、 Amazon Athena 、および Amazon Quicksight を使用して保存および報告されます。アプリケーションで使用される 3D モデルは、 Amazon Simple Storage Service(Amazon S3) を使用して保存されます。Amplify は AWS CodeCommit を使用して継続的なデプロイメントを行います。 最終的には 3D モデルを使用した VR アプリケーションが作成され、ユーザーの入力が記録・可視化されるため、お客様はユーザーエクスペリエンスの改善方法についてのインサイトをダッシュボードで確認できます。 この Amplify アプリケーションでは、たとえばプレイヤーは VR コントローラーで Color GUI から青色を選択します。色の変更イベントは、データベースに色の値を送信します。 DynamoDB テーブルには、各イベントの色の値が記録されます。 Quicksight ダッシュボードは DynamoDB からのデータを表示するために使用されます。 アーキテクチャ ユーザーは、VR 対応デバイスを使用して AWS Amplify のウェブサイトに接続します。テクスチャやオブジェクトは Amazon S3 からアプリケーションに読み込まれます。オブジェクトは AWS Amplify の外で Amazon S3 において管理します。ユーザーは XR シーンで利用可能なオブジェクトやコントロールと対話し、クリック、色の選択、テクスチャの選択などの各ユーザーイベントは DynamoDB に送信されます。Amazon Athena は Quicksight がユーザーのインサイトを提供するためのデータを利用可能にします。AWS Amplify の管理者は、ホストされたサイトにユーザーのインサイトに基づいた変更をデプロイすることができます。 前提条件 AWS Amplify 、 Amazon DynamoDB 、 Amazon S3 、 Amazon Athena 、および Amazon Quicksight への完全な権限を持つ既存の Amazon Web Services (AWS) アカウント JavaScript と Linux コマンドラインに慣れている Node.js v14.x 以降 npm v6.14.4 以降 git v2.14.1 以降 最新の Amplify CLI ;バージョン 10.6.2 以上 手順の概要 サンプルアプリケーションをデプロイして実行するには、次の手順を実行します。 ステップ 1: React アプリケーションのセットアップ Getting started – React – AWS Amplify Docs を使用して React アプリケーションを作成し、create-react-app を使用してディレクトリ構造を作成し、ローカルシステムで開始できることを確認します。 ステップ 2: AWS Amplify と Babylon.js のインストール Getting Set Up | Babylon.js Documentation を使用して AWS Amplify CLI 、Babylon.js、および Babylon.js モジュールをインストールします。AWS Amplify は、フロントエンドの Web およびモバイル開発者が AWS 上でフルスタックアプリケーションを迅速かつ容易に構築できるようにするための目的に特化したツールおよび機能のセットです。 ステップ 3: Amplify でバックエンドを初期化 このプロジェクトでは、Amplify の AWS AppSync 、Amazon S3、 Amazon Cognito との統合を活用します。アプリケーションの構築とデプロイ、必要な AWS リソースのプロビジョニングについては Complete guide to full-stack CI/CD workflows with AWS Amplify も参照してください。まずは Amplify CLI を使用して Amplify 環境を初期化し、編集します。 ステップ 4: Amplify でバックエンドリソースを作成 Storage – Overview – AWS Amplify Docs を使用して Amplify バックエンドリソースを作成しプッシュし、 Tutorial – Add authentication – React – AWS Amplify Docs を使用して認証を行い、 Tutorial – Connect API and database to the app – React – AWS Amplify Docs を使用してデータを同期および DynamoDB に保存します。 ステップ 5: Amazon S3 にテクスチャをアップロード AWS 管理コンソール に移動し、作成されたリソースを表示します。Amazon S3 コンソールに移動し、ステップ 4 で作成したバケットを探します。トップディレクトリで「public」というフォルダを作成し、そのフォルダに入ります。このフォルダ内で「アップロード」をクリックし、バケットにテクスチャをアップロードします。これでコードからアクセス可能になります。 ステップ 6: アプリケーションシーンの作成 Babylon.js は JavaScript ベースの人気のある 3D エンジンで、Web 用の 3D アプリケーションやゲームを開発するためのオープンソースフレームワークです。これは、リアルな動きやオブジェクト間の相互作用を容易に作成できる高度な機能を提供し、VR アプリケーションの作成に不可欠です。Babylon.js のドキュメントから Starter HTML Template を使用して index.html ファイルを作成します。ローカルシステムでコードをコピーし、 README.md の src/index.js、src/App.js、および src/Scene.js に貼り付けます。 ステップ 7: git ベースの CI/CD デプロイメント用の CodeCommit を作成 アプリケーションをホストするために、AWS Amplify Hosting サービスと AWS CodeCommit を使用します。Amplify Hosting は完全に管理された CI/CD およびホスティングサービスであり、AWS CodeCommit は完全に管理されたソースコントロールサービスであり、 Setting up Amplify access to GitHub repositories のドキュメントを使用して git ベースの CI/CD デプロイメントを可能にします。 ステップ 8: 継続的なデプロイメントのために Amplify を CodeCommit に接続 AWS 管理コンソールから Amplify コンソールを開き、継続的なデプロイメントを有効にするために CodeCommit リポジトリに接続します。 ステップ 9: Amazon Athena と DynamoDB コネクタを作成 Amazon Athena DynamoDB コネクタ により、Amazon Athena は DynamoDB と通信できるようになり、SQL を使用してテーブルをクエリできます。これにより、シーン内のユーザーアクションから取り込まれたイベントデータを視覚化するために QuickSight を使用できます。 ステップ 10: QuickSight ダッシュボードを作成 DynamoDB に保存されたイベントデータから洞察を得るために QuickSight ダッシュボード を作成します。Amazon QuickSight は、簡単に理解できる洞察を提供するために使用できるクラウドスケールのビジネスインテリジェンス(BI)サービスです。 ステップ 11: VR アプリケーションの表示と使用 新しい CodeCommit プッシュコマンドが実行されるたびに、Amplify は新しいビルドとデプロイプロセスを実行します。デプロイプロセスが完了すると、最新バージョンはアプリホスティング環境にある同じプロダクションブランチの URL に残ります。 ステップ 12: QuickSight ダッシュボードの表示 QuickSight は、172 回の VR コントローラーのクリックと、各クリックの色の RGB 値を示しています。 ステップ 13: 公開アクセスの制限またはクリーンアップ 意図しないアクセスによるコスト上昇を防ぐためには、 Restricting access to branches の指示に従って Amplify URL をパスワード保護するか、作成されたすべてのリソースを削除します。 終わりに Amplify、Babylon.js、および Babylon.js の WebXR スタックを使用する方法を示すこのブログは、WebXR を始めるための多くの方法のうちの一つにすぎません。Amplify を使用すると、XR のアイデアを反復するための継続的なデプロイメント環境が提供されます。Bablyon.js で次に試すべきことのインスピレーションを得るためには、 The Playground を訪れてください。このブログの例は、追加のオブジェクト、テクスチャ、およびコントロールでより多くのイベントデータを収集すること、より包括的なダッシュボードを作成すること、または AI/ML を追加してユーザーの洞察を拡大することでさらに拡張することができます。 次のステップ このブログで概説されているセットアップを再現するために使用された具体的な技術コマンドを含む完全なステップバイステップの解説は、 Create a VR application with user insights using aws amplify and the webxr stack で見つけることができます。 著者について Brian M. Slater Brian M. Slater は、Amazon Web Services の Independent Software Vendors (ISV) の Principal Solutions Architect です。Brian は、政府、スタートアップ、および金融サービスにおいて多年の経験を持っています。現在は、IoT および空間コンピューティングソリューションの構築において顧客を支援しています。 Sam Burton Sam Burton は Amazon Web Services のエンタープライズソリューションアーキテクトであり、業界のベストプラクティスに従って AWS 上でソリューションを構築、反復、およびスケールするお客様を支援しています。エンタープライズ顧客との作業以外に、Sam は AWS Amplify などのフロントエンドの Web およびモバイルサービスでの構築を行っています。 Sneha Panchadhara Sneha Panchadhara は Amazon Web Services のソリューションアーキテクトで、お客様がビジネス目標を達成し、AWS サービスの採用を加速するのを支援することを楽しんでいます。仕事以外の時間は、家族や友人と過ごすのが好きです。 翻訳はソリューションアーキテクトの阿南が担当しました。原文は こちら です
本記事は Exploring the Spatial Computing Spectrum: The Next Frontier of Immersive Technologies を翻訳したものです。 新しい技術進歩の時代に入るにつれ、次なるイノベーションのフロンティアは空間コンピューティングによって動かされることが明らかになってきました。ゲーム、映画とメディア、シミュレーション、あるいはメタバースなどの分野において、さまざまな業界の企業が空間コンピューティングの能力開発を競っています。特に、3D コンテンツ作成、ゲーム、シミュレーション、地理空間の4つの空間コンピューティングセグメントがイノベーションを推進する立場にあります。これらの各領域のためのより良いツールとクラウドサービスを開発することで、空間コンピューティングは人々の働き方、遊び方、生活の仕方を革新する新しい可能性の扉を開くでしょう。 Amazon Web Services(AWS) のチームは、すでに空間コンピューティングの基盤を構築するために懸命に取り組んでいます。このブログ記事では、空間コンピューティングとは何かを探り、3D コンテンツ作成、ゲーム、シミュレーション、地理空間を通じて、AWS がこの革新的なテクノロジーの未来を形作る支援をしていることを紹介します。 空間コンピューティングとは 空間コンピューティングは、仮想世界と物理世界の組み合わせです。物理世界を仮想化し、仮想情報を物理世界に重ね合わせることで、ユーザーがデジタルコンテンツと自然かつ直感的に対話できるようになります。この組み合わせにより、物理的あるいは仮想的な場所におけるデータの可視化、シミュレーション、操作が強化されます。ブログ “The Best way to Predict the Future is to Simulate it”  で、Amazon のテクノロジー担当 VP Bill Vass は、「空間コンピューティングは、協調型エクスペリエンスを実現する原動力です」と述べています。 空間コンピューティングは、業種や業界の垣根を越えています。ユースケースは、リアルタイムメトリクスを表示するデジタルツインから、大規模多人数同時オンライン (MMO) ビデオゲーム、都市全体のレーザースキャンで訓練された AI/ML モデルなど、幅広い範囲に及びます。これらのユースケースは業界の垣根を越えていますが、同様のコアテクノロジー、仕様、ワークフロー、課題を共有しています。 アート作品の制作 3D デジタルコンテンツ制作は、空間コンピューティングのバックボーンです。AWS を利用することで、顧客は画期的なアート作品の創作により多くの時間を費やし、ハードウェアやレンダーファームの管理に費やす時間を短縮できます。ブログ “Avatar: The Way of Water” のような最新のコンピュータグラフィックス (CG) ショットをレンダリングする場合でも、プロダクションをクラウドに移行することで世界中から最高の人材を集める場合でも、AWSのソリューションとサービスはクリエイターが観客を楽しませる力を発揮してきました。 AWS のメディアサービス は、顧客がハリウッドの大作映画のデジタルコンテンツを作成し、ライブおよびオンデマンドのビデオワークフローを構築するのに利用されてきました。 AWS Thinkbox Deadline は、スケーラブルかつ柔軟なコンピュートレンダリング管理の業界標準です。Deadline により、顧客はオンプレミスのレンダーファームからクラウドに移行でき、アーティストはより迅速に反復処理を行い、ショットの納期を従来の日数から時間単位に短縮することが可能になりました。 ここ数年で、顧客は中央集中型のチームから世界中に分散したチームへと移行してきました。これにより、スタジオはタイムゾーンを越えて世界中から最高のクリエイターを集めることができるようになりました。 AWS Studio in the Cloud ソリューションは、スタジオの分散型グローバルチームへの移行を支える基盤として機能してきました。こうした移行からの学びを踏まえ、AWS のツールとサービスは 3D コンテンツ制作のためのクラウド利用をより簡単にするよう進化を遂げています。AWS は、顧客がワークフローを加速し、次世代の 3D コンテンツをより効率的に制作できるよう、コアとなるクラウドインフラとリソースの提供に注力しています。 AWSは次なる一手を予測するため、先を見据えています。世界中のスタジオがクラウドを利用して、日数ではなく時間単位で映像作品を制作してきました。顧客とのこうした取り組みから得た教訓をさらに推し進めることで、新しい形の映画製作、インタラクティブ体験、ビデオゲームのためのより大規模なスケーラビリティ、可用性、クラウドコンピューティングパワーを実現していきます。 あらゆる規模でのゲーム この 5 年間でビデオゲームは驚異的な成長を遂げており、AWS は規模の大小を問わずゲーム開発者をサポートしてきました。インディーゲームスタジオの Blinkmoon Games から、 Epic Games のような業界最大手スタジオまで、AWS に全面的にコミットしている開発者に対し、AWS はグローバルな規模でゲームを提供するために必要なツールとリソースを提供しています。 今日、Epic Games が開発した Fortnite は、ほぼ完全に AWS 上で動作しています。 AWS Graviton processors を搭載した Amazon EC2 インスタンスを何万台も使用し、Epic Games は毎日世界中の何百万人ものプレイヤーをサポートしています。今年、Epic Games は AWS と協力し、 AWS Local Zones を通じてより多くの Fortnite プレイヤーをサポートしました (英語)。現在 AWS Local Zones 上で動作しているため、中部アメリカとメキシコのプレイヤーは、新しい北米中央 Fortnite リージョンで低レイテンシーのゲームプレイを体験できます。AWS では、ゲームプレイの機能とクラウドサービスが拡張していくにつれ、Fortnite のプレイヤーがどのようなことを実現するのか楽しみにしています。 チームの規模に関わらず、 Amazon GameLift を利用することで、セッションベースのマルチプレイヤーゲームのための専用のリアルタイムサーバーを提供できます。 開発者がサーバーの完全な制御とカスタマイズを必要とする場合でも、面倒なカスタムゲームサーバーのデプロイプロセスを省くことができる使いやすいゲームサーバーを必要とする場合でも、どちらでもAmazon GameLift はゲームのマーケットへのリリースを支援することができます。 リアルタイム 3D エクスペリエンスのユースケースがゲームから他のビジネス分野に広がるにつれ、 AWS for Games のソリューションを求める顧客が増えています。 当社のパートナーである Surreal Events は、AWS を利用してメタバースソリューションを拡張・スケーリングし、世界中の顧客に提供しています。 AWS を利用することで、あらゆる種類のリアルタイム 3D エクスペリエンスを構築する開発者は、仮想世界を拡大していくにつれて、エンドユーザーに大規模なコラボレーションをもたらすことができます。 未来のシミュレーション 近年、ほぼすべてのビジネス分野で、何らかの形でのシミュレーションが採用されるようになりました。ライフサイエンス、金融サービス、石油・ガス、設計、エンジニアリング、気候科学、自動運転などです。 システムがますます複雑になるにつれ、空間シミュレーションは、物理世界への洞察を提供する鍵となります。 過去には、空間シミュレーションは1つのハードウェアに制約されており、開発者にとってはほぼ不可能な課題でした。 このため、AWS は昨年、新しいシミュレーション専用サービスである AWS SimSpace Weaver を発表しました。 この新サービスにより、AWSの開発者は都市規模の 3D シミュレーションから洞察を得ることができます。 SimSpace Weaver は、コンピューティングインフラストラクチャー全体でシミュレーションを管理することで、クラウドで大規模な空間シミュレーションを簡単に実行できるようにします。 これにより、開発者はクラウドインフラストラクチャーのプロビジョニングとメンテナンスではなく、シミュレーションとアプリケーションの構築に集中できます。 さらに、SimSpace Weaver は、人気のあるリアルタイム 3D エンジンとの統合を提供するため、開発者は没入型でインタラクティブな体験を作り出すことができ、チームは実世界のシナリオをより良く理解することができます。 大規模な群衆シミュレーションのエキスパートである uCrowds 社との提携により、私たちは何百万ものシミュレートされた人間がネバダ州ラスベガスの通りを歩く実世界のシミュレーションの拡大、実行、可視化の可能性を示しました。この規模でシミュレーションを行うことで、私たちのチームは人口の急増が物理的な都市インフラに与える影響についてより良い理解を得ることができました。 AWS re:Invent 2022でのAmazonのCTO、Werner Vogelsの言葉 を言い換えると、私たちは物理的なものと仮想的なものとの境界線が曖昧になる中で、シミュレーションが重要であると考えており、開発者たちがあらゆるもののシミュレーションを始めることを願っています。 地理空間データを至る所で活用する 歴史を通じて、地図は新しいフロンティアを定義する上で重要な役割を果たしてきましたが、空間コンピューティングの強化により、これからもその役割を続けるでしょう。相互接続された私たちの世界では、地図は商品やサービスのルート、場所、フェンスを定義します。ビジネスが都市をナビゲートし、荷物を追跡し、車両やラストワンマイルを配送する自動運転ロボットのルートを設定する際、地図が提供する地理空間データはますます重要になっています。 2021 年、AWS は Amazon Location Service を発表しました。これは、地図、興味のあるポイント、ジオコーディング、ルーティング、トラッキング、ジオフェンシングをアプリケーションに簡単かつ安全に追加できる完全に管理されたサービスで、データのセキュリティ、ユーザーのプライバシー、またはコストを妥協することなく提供します。Amazon Location には、地図ベースの可視化、リソースの追跡、配送、ジオマーケティングによる場所を意識したユーザーのエンゲージメントなど、様々なユースケースのための位置機能が追加されました。 AWSは地図にとどまりません。アプリケーションに高い理解、洞察、および文脈に応じた情報をもたらすために、AWSは Amazon SageMaker も拡張し、開発者が地理空間データを使用して、機械学習モデルをより速く構築、トレーニング、デプロイできるようにしました。 AWS の Open Data Program と組み合わせることで、テラバイト単位のオープンソースの LiDAR ポイントクラウドデータを使用して、新しい地理空間ワークロードのための AI/ML モデルをトレーニングすることができます。自動運転車のフリート、配送ロボットのトレーニング、または物理世界からの洞察を得たい場合であっても、 Amazon SageMaker での地理空間ML は、開発チームが地理空間データを分析し、インタラクティブな地図を使用して 3D で強化されたグラフィックでモデル予測を探索することを可能にします。 空間コンピューティングにより、次世代のアプリケーションは私たちの周囲の物理的世界に対して、より深い洞察と文脈データをもたらすでしょう。Amazon Location や SageMaker などの AWS サービスは、すでに開発者によって使用されており、私たちの仮想世界を物理的な世界にオーバーレイしています。 更なるイノベーションへ 空間の革命はすでに進行中で、AWS のお客様によって、あらゆる規模やビジネスラインで主導されています。3D の文脈データと AWS クラウドのパワーとスケールにより、私たちの仮想世界と物理世界はシームレスに組み合わされ、働き方、生活、遊び方の変革を促進しています。AI/ML がよりアクセスしやすくなるにつれて、 AWS 上の生成 AI サービス を使えば、誰もがクリエイターになり、3D 仮想コンテンツで物理世界を拡張することができるでしょう。 3D コンテンツ作成、ゲーム、シミュレーション、地理空間という 4 つのテクノロジーセグメントを通じて、AWS は開発者と協力して未来を形作っています。AWS チームが未来を見据える中で、私たちは新しいツールやクラウドサービスを開拓し、技術革新の次のフロンティアに挑戦し、世界中の開発者が未来を構築することを支援することを目指しています。 著者について Chris Lee Chris Lee は AWS の没入型テクノロジー部門のディレクターでありGMです。彼は、AWS 上で大規模な空間コンピューティング体験を構築するために、レンダリング、VFX、ゲーム、シミュレーション、地理空間サービスの構築に注力しています。この役割に就く前、Chris は 20 年以上にわたりゲーム業界で複数の AAA ゲームを構築してきました。 翻訳はソリューションアーキテクトの阿南が担当しました。原文は こちら です。