本日 (2023 年 10 月 4 日) 、Amplify の GraphQL API 機能のための AWS Cloud Development Kit (CDK) コンストラクト を発表できることを嬉しく思います。Amplify の GraphQL API CDK コンストラクトを使用すると、単一の GraphQL スキーマ定義を使用して、 Amazon DynamoDB テーブルや AWS Lambda 関数などのデータソースをバックエンドとするリアルタイム GraphQL API を作成できます。( Construct Hub で見る) フロントエンド用の API を立ち上げるためには、開発者は API エンドポイント、カスタムビジネスロジック、データソースを構築して繋げ合わせるために、何千行もの反復的で差別化されないコードを書く必要があります。 AWS Amplify は、開発者が単一の定義ファイルでデータモデルを定義し、データソースの create, update, list, read, subscribe, delete のような一般的な API 操作をサポートするために必要な AWS リソースを自動的に生成できるようにすることで、この重労働を取り除きます。これまでは Amplify CLI でのみ利用可能でしたが、今回のアップデートでこの機能を AWS CDK に拡張します。 CDK Day 2023 の Amplify のセッションで、新しい Amplify GraphQL API コンストラクトのプレビューを皆さんにお見せしました。 新しい GraphQL API コンストラクトの詳細なツアーに参加しましょう！本記事では、フロントエンドのためのバックエンドを必要とし、AWS CDK を使っているお客様が利用できる 6 つの新機能にフォーカスします。 既存 CDK アプリやリソースとのシームレスな統合 リアルタイム API とデータスタックのための信頼できる唯一の情報源 簡単に始められ、拡張できる認可ルール 拡張可能なカスタム Query, Mutation, Subscription API 生成されたリソースを完全に制御する L2 および L1 コンストラクトへのエスケープハッチ リアルタイム機能のためのファーストクラスのクライアントライブラリサポート 1. 既存 CDK アプリやリソースとのシームレスな統合 新しい Amplify GraphQL API CDK コンストラクトは、既存 CDK アプリ内のドロップインコンポーネントとして使用できます。Lambda 関数のような既存のリソースとシームレスに統合できます。CDK のコンポーザブルアーキテクチャをベースに、手作りのリソースやインポートしたリソースを GraphQL API のデータソースとして使用しながら、Amplify の自動化された CRUD 操作、認可ルール、AWS AppSync によるリアルタイムのサブスクリプションの恩恵を受けることができます。新しい Amplify GraphQL API コンストラクトでは、CDK で開始し、CDK で反復し、CDK でデプロイします。 開始するには、既存 CDK アプリを使用するか、新しいアプリを作成します。 mkdir amplify-cdk-demo cd amplify-cdk-demo mkdir backend cd backend cdk init app --language=typescript 次に、以下のコマンドで新しい Amplify GraphQL API CDK コンストラクトと依存関係をインストールします。 npm install @aws-amplify/graphql-api-construct CDK アプリの lib/backend-stack.ts ファイルで、新しい Amplify GraphQL API コンストラクトをインポートして初期化します。 import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; import * as path from 'path' export class BackendStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const amplifyApi = new AmplifyGraphqlApi(this, "MyNewApi", { definition: AmplifyGraphqlDefinition.fromFiles(path.join(__dirname, "schema.graphql")), authorizationModes: { defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 上記のコードは、 schema.graphql に格納されたスキーマ定義に基づいて新しい API をインスタンス化し、API キーを API のデフォルト認証モードとして使用します。API キーの有効期限はデプロイ時から 30 日間です。 次に、 schema.graphql を新規作成し、データモデルと API の単一のソースとして使用します。 2. リアルタイム API とデータスタックのための信頼できる唯一の情報源 新しい Amplify GraphQL API コンストラクトでは、開発者はデータモデルを GraphQL スキーマ定義言語で定義し、DynamoDB テーブル ( @model ) 、Lambda 関数 ( @function ) 、OpenSearch クラスタ ( @searchable ) などの付随するデータソースを生成するためのディレクティブを使って拡張します。CDK コンストラクトは、Amplify CLI の既存の GraphQL Transformer 機能と完全に同等の機能を備えています。開発者は @auth ディレクティブを使用して API とデータをセキュアにすることができます。 @auth ディレクティブは、グローバル、モデルレベル、フィールドレベルの認可ルールを構成する機能だけでなく、デフォルトで拒否する認可を提供します。新しい CDK コンストラクトは、CDK コード内から Amplify によって生成されたすべてのリソースにアクセスし、カスタマイズする機能を備えており、拡張可能です。 以下のスキーマは Blog アプリケーションを記述しています。以下の GraphQL スキーマをアプリケーションにコピー & ペーストしてください。 type Blog @model @auth(rules: [{ allow: public }]) { title: String content: String authors: [String] } 次に、CDK を使ってアプリケーションをデプロイし、プロンプトが表示されたら “y” と答えます。 cdk deploy デプロイが完了したら、AWS AppSync コンソールにアクセスして API を選択し、いくつかのテストクエリを実行します。作成クエリとリストクエリを実行して結果を確認してみましょう。 3. 簡単に始められ、拡張できる認可ルール 新しい Amplify GraphQL API CDK コンストラクトは、デフォルトの拒否ルールをすぐに提供することで、認可を簡単に始めることができます。API レベル、データモデルごと、あるいは個々のフィールドごとにきめ細かい認証ルールを追加することで、アクセス制御をさらにカスタマイズすることができます。Amplify は、ユーザー単位、複数ユーザー、グループ単位、複数グループによる特定のレコードへのアクセスなど、一般的な認証ルールを提供します。これらのルールは、Amazon Cognito または任意の OpenID Connect (OIDC) プロバイダで動作します。カスタムの認可パターンを実現するために、Lambda 関数を活用することもできます。この宣言的な認証モデルを使えば、アプリケーションの成長に合わせて拡張できる、堅牢なアクセス制御を得ることができます。 API をロックダウンして、一般ユーザーは全てのブログを読むことができるが、サインインしたユーザーはブログの作成、閲覧、更新、削除ができるようにしてみよう。まず、GraphQL スキーマを更新して、”public ” アクセスルールをスコープダウンし、新しい “owner” 認可ルールを追加しましょう。”owner” 認可ルールでは、ユーザーごとの認可を指定することができる。サインインしたユーザーが新しいレコードを作成すると、そのレコードは自動的にサインインしたユーザーをオーナーとして指定します。 type Blog @model @auth(rules: [ { allow: public, operations: [ read ] }, { allow: owner } ]) { title: String content: String authors: [String] } 認可ルールは以下のように定義されています。 Public (API キーを使用するユーザー ) はどのブログでも読むことができます。 Owner (Cognito 経由でサインインしたユーザー) は自分のブログを作成、閲覧、更新、削除できます。 注意 ：グループベースの認可やフィールドレベルの認可など、さらに高度な認可を追加できます。これによって、「Admins グループのメンバーにのみブログの削除を許可する」、「サインインした作者にのみ表示される新しい privateNotes フィールドを追加する」などのユースケースに拡張することが出来ます。認可機能の全範囲については、 ドキュメント を参照してください。 lib/backend-stack.ts の CDK コンストラクトプロパティを更新し、ユーザーのサインインとサインアップ管理に新しいユーザープールまたは既存のユーザープールを使用するようにしました。 import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; import * as path from 'path' import { UserPool, UserPoolClient } from 'aws-cdk-lib/aws-cognito'; export class BackendStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const userPool = new UserPool(this, "MyNewUserPool") new UserPoolClient(this, "MyNewUserPoolClient", { userPool: userPool }) const amplifyApi = new AmplifyGraphqlApi(this, "MyNewApi", { definition: AmplifyGraphqlDefinition.fromFiles(path.join(__dirname, "schema.graphql")), authorizationModes: { defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) }, userPoolConfig: { userPool: userPool } } }) } } 以下のコマンドで最新のものを再度デプロイします。 cdk deploy デプロイ後、 Amazon Cognito ユーザプールコンソール でテストユーザーを作成します。 AppSync コンソール では API キーを使う、もしくはサインインしたユーザーとして、GraphQL クエリを実行してテストすることができます。 4. 拡張可能なカスタム Query, Mutation, Subscription API 基本的な CRUD 操作以外のカスタムビジネスロジックを実装する必要がありますか？Amplify GraphQL API CDK コンストラクトを使用することで、独自の Lambda 関数をトリガーするカスタム GraphQL リゾルバを簡単に定義できます。カスタム Query, Mutation, Subscription を追加して、検索、分析、メッセージングなどの特殊な API を実装します。カスタムデータタイプを定義して、レスポンスフォーマットを構造化します。RDS や 3rd Party のAPI など、あらゆるソースからデータにアクセスします。Amplify が GraphQL スキーマの生成、クライアントSDK の構築、およびそれらの繋込みを行うことで、お客様はカスタムロジックの作成に専念することが出来ます。GraphQL と AWS Lambda の柔軟性で API 機能を拡張しましょう。 例えば、ブログアプリケーションにシンプルな PubSub API 機能を構築するとします。読者はブログサイトに表示され、お互いにメッセージをライブ配信することができます。 まず、GraphQL スキーマを編集して、サインインしたユーザがメッセージを送信し、Subscription がメッセージを受信できるような Mutation を追加する必要があります。 type Blog @model @auth(rules: [ { allow: public, operations: [ read ] }, { allow: owner } ]) { title: String content: String authors: [String] } type Mutation { broadcastLiveMessage(message: String): String } type Subscription { subscribeToLiveMessages: String @aws_subscribe(mutations: ["broadcastLiveMessage"]) } @aws_subscribe ディレクティブは、 mutations 引数で指定されたすべての Mutations に対してリアルタイムの Subscription をセットアップします。 次に、 lib/backend-stack.ts の CDK コードに戻って、 broadcastLiveMessage Mutation からのメッセージを subscribeToLiveMessages Subscription に渡す JavaScript リゾルバを追加します。Amplify GraphQL API をインスタンス化した後、以下のコードを追加します。 const broadcastDataSource = amplifyApi.addNoneDataSource("BroadcastNone") amplifyApi.addResolver("BroadcastResolver", { dataSource: broadcastDataSource, typeName: 'Mutation', fieldName: 'broadcastLiveMessage', code: Code.fromAsset(path.join(__dirname, 'resolvers', 'broadcastLiveMessage.js')), runtime: FunctionRuntime.JS_1_0_0 }) 上記のコードでは、まず NONE データソースを作成し、API に新しいリゾルバを追加して broadcastLiveMessage Mutation を処理します。このタイプのデータソースは、アクションを他の AWSリソースと連携することなく、AppSync 内でローカルに解決したい場合に使用します。 broadcastLiveMessage Mutations を処理するために、新しい resolvers フォルダに broadcastLiveMessage.js を作成します。 resolvers/broadcastLiveMessage.js は、Mutation からのメッセージ引数を使用し、Subscription に結果としてそれを渡します。 export function request(ctx) { return { payload: { message: ctx.arguments.message } } } export function response(ctx) { return ctx.result.message } もう一度変更をデプロイしてみます。 cdk deploy それでは、2 つの AppSync コンソールウィンドウを開いて、変更を検証してみましょう。1 つは一般向けの Subscription で、もう 1 つは Mutations を送信するために使用します。 5. 生成されたリソースを完全に制御する L2 および L1 コンストラクトへのエスケープハッチ Amplify は、DynamoDB テーブルや Lambda 関数のような基本リソースのプロビジョニングをしますが、アプリケーションが成熟するにつれて、開発者はより深いアクセスが必要になってきます。CDK コンストラクトは、L2 および L1 CDK コンストラクトを通じて基礎となるリソースに直接アクセスするためのエスケープハッチを提供します。DynamoDB の課金モードを微調整したり、Lambda に VPC インタフェースを追加したり、OpenSearch インデックスを CDK でカスタマイズできます。 AppSync API や DynamoDB テーブルなど、生成されたすべてのリソースは、L2 コンストラクトとして .resources パラメータの下で利用可能です。 .resources.cfnResources 経由でアクセスすることで、生成されたリソースの L1 コンストラクトにさらにドロップダウンできます。例えば、基礎となる AppSync API で X-Ray トレースを有効にするには、L1 レベルにドロップダウンして必要な X-Ray トレースを設定します。 >amplifyApi.resources.cfnResources.cfnGraphqlApi.xrayEnabled = true 一度設定すれば、変更を再度デプロイすることができます。 cdk deploy 6. リアルタイム機能のためのファーストクラスのクライアントライブラリサポート バックエンドの実装を合理化すると同時に、Amplify はお客様の GraphQL API に強く型付けされたクライアント SDK の自動生成を提供します。クライアントアプリでリアルタイムデータのサポートと強力な GraphQL クエリをすぐに利用できます。Web アプリの場合は、React ベースの JavaScript クライアントを生成します。クロスプラットフォームまたはモバイルアプリについては、Android、iOS、および React Native をサポートしています。これらのプラットフォームに対応するクライアントコードを生成する方法については、 ドキュメント を参照してください。Amplify クライアントライブラリを使えば、複雑なロジックを 1 からコーディングすることなく、魅力的なユーザー体験を構築することができます。 この例では、React アプリケーションを使ってこのライブブログを紹介します。まず、ターミナルから以下のコマンドを実行して、新しい React アプリケーションを作成します。 cd .. npx create-react-app frontendcd frontend 全体的なフォルダー構造は以下のようになります。 >amplify-cdk-demo |-backend |-frontend 次に、アプリケーションをバックエンド API に接続するための Amplify Libraries をインストールします。 npm install aws-amplify 次に、バックエンド API を認識するように Amplify Libraries を設定する必要があります。アプリのエントリーポイント (すなわち index.js ) に行き、 cdk deploy を実行したときにターミナルに出力された API エンドポイントの情報を使って、Amplify Libraries を設定します。先程の cdk deploy で以下のように出力されているはずです。 ✨ Deployment time: 62.86s Outputs: BackendStack.amplifyApiModelSchemaS3Uri = s3://backendstack-mynewapiamplifycodegenassetsamplifyc-1u3xykyhe309m/model-schema.graphql BackendStack.awsAppsyncApiEndpoint = https://wy5mtp7jzfctxc5w5pzkcoktbi.appsync-api.us-east-1.amazonaws.com/graphql BackendStack.awsAppsyncApiId = eci46vifpvbvhno55uo2ovtoqm BackendStack.awsAppsyncApiKey = da2-XXXX BackendStack.awsAppsyncAuthenticationType = API_KEY BackendStack.awsAppsyncRegion = us-east-1 フロントエンドの index.js に、Amplify Libraries をインポートし、対応する情報を設定します。 import { Amplify } from 'aws-amplify' Amplify.configure({ aws_appsync_graphqlEndpoint: 'https://wy5mtp7jzfctxc5w5pzkcoktbi.appsync-api.us-east-1.amazonaws.com/graphql', aws_appsync_region: 'us-east-1', aws_appsync_authenticationType: 'API_KEY', aws_appsync_apiKey: 'da2-XXXX' }) Amplify Libraries の API カテゴリを使って生の GraphQL リクエストを書くこともできるます、以下の npx スクリプトを使うことで、一般的なリクエストの大部分を Amplify に生成させることもできます。 npx @aws-amplify/cli codegen add --apiId eci46vifpvbvhno55uo2ovtoqm --region us-east-1 npx @aws-amplify/cli codegen 注意 ：バックエンドにスキーマ変更をデプロイする度に、対応するクライアントヘルパーコードを再生成するために、 npx @aws-amplify/cli codegen を再実行する必要があります。 src/graphql/ フォルダに新しいファイル群があるはずです。これらは GraphQL Query、Mutation、Subscription のクライアントコードヘルパーです。 src/graphql/ ├── mutations.js ├── queries.js └── subscriptions.js ブログとメッセージ機能を表示するためにフロントエンドの UI を変更します。 App.js にアクセスし、以下の内容に置き換えます。 import "./App.css"; import { useEffect, useState } from "react"; import { API } from "aws-amplify"; import { listBlogs } from "./graphql/queries"; import { subscribeToLiveMessages } from "./graphql/subscriptions"; import { broadcastLiveMessage } from "./graphql/mutations"; function App() { const [blogs, setBlogs] = useState([]); const [messages, setMessages] = useState([]); useEffect(() => { // fetches all blog posts async function fetchBlogs() { const response = await API.graphql({ query: listBlogs, }); setBlogs(response.data.listBlogs.items); } fetchBlogs(); // setup subscriptions for live chat messages const subscription = API.graphql({ query: subscribeToLiveMessages }).subscribe(next => { setMessages(messages => [...messages, next.value.data.subscribeToLiveMessages]) }) return () => subscription.unsubscribe() }, []); // sends the live chat message to users function handleMessageSend(event) { if (event.key === 'Enter') { API.graphql({ query: broadcastLiveMessage, variables: { message: event.target.value } }) } } return ( <div style={{ display: "flex", gap: 20 }}> <div> <h1>Articles</h1> {blogs.map((blog) => ( <div style={{ border: '1px solid black', padding: 10, borderRadius: 10}}> <h2>{blog.title}</h2> <p>{blog.content}</p> </div> ))} </div> <div> <h1>Live chat</h1> <input type="text" placeholder="Hit enter to send message" onKeyDown={handleMessageSend} /> <hr></hr> <ul> {messages.map(message => <li>{message}</li>)} </ul> </div> </div> ); } export default App; 70 行以下のコードで、ライブチャット機能を持つブログ記事フロントエンドを構築しました。アプリをローカルで実行するには、ターミナルで以下のコマンドを実行してます。 npm run start あなたのアプリはこのように見えるはずです。ライブチャット機能をテストするために、別のウィンドウで開いてみてください。 成功の秘訣 CDK を使用してデプロイされたリアルタイム API とデータスタックが React アプリに統合されました！これは、Amplify GraphQL CDK コンストラクトのほんの一部の機能です。より深く掘り下げるために、以下のリソースもぜひご覧ください。 Construct Hub の Amplify GraphQL API コンストラクト Amplify GraphQL API 機能の認可ルール カスタムビジネスロジック (Lambda 関数、HTTP、JS/VTL リゾルバ ) JavaScript、Android、Swift、Flutter 用の GraphQL クライアントヘルパーコードの生成 他に質問がある場合は、 Discord に参加するか、問題や機能要求を提出したい場合は、 GitHub にアクセスしてください。 本記事は、「 Connect a React app to GraphQL and DynamoDB with AWS CDK and Amplify 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS Amplify UI チームは、エンドユーザーのための機能豊富なアプリを構築するのに役立つ、8 つの新しい React ユーザーインターフェイスコンポーネントと 2 つの改良されたコンポーネントを紹介します。本記事では、新しいコンポーネントと、それらをプロジェクトにどのように使用できるかを紹介します。Amplify UI は、クラウドに接続されたクロスプラットフォームと、パフォーマンス、テーマ性、応答性、アクセシビリティに優れた React コンポーネントの両方を備えたコンポーネントライブラリです。 1. Fieldset <Fieldset legend="Favorite fruits" variation="outlined" direction="column"> <CheckboxField label="Apple" name="apple" /> <CheckboxField label="Pear" name="pear" /> </Fieldset> Fieldset は、アクセス可能な <legend> を伴う <fieldset> 要素をレンダリングする新しいコンポーネントです。Fieldset は、フォーム内の関連する要素をグループ化するために使用される HTML 要素です。例えば、チェックボックスのグループや、より大きなフォーム内に関連するフィールドを作成するために使用されます。以前は、独自のフィールドセットを作成し、スタイルを設定する必要がありましたが、Fieldset コンポーネントの導入により、このプロセスはより簡単になりました。 Fieldset はコンテキストプロバイダなので、Fieldset の無効状態は、Amplify UI のフォームコントロールとネストされた Fieldset に正しく受け継がれます。 isDisabled プロパティを true に設定すると、Fieldset の子要素であるすべてのフォームフィールドが無効になります。 2. Input <Input placeholder="placeholder" /> Input は <input> 要素が受け入れる標準的な HTML 属性のどれでも受け入れます。標準的な <input> 属性は MDN Documentation で確認することができます。Input プリミティブはテキスト入力専用にスタイルされています (テキスト、日付、数字など)。 3. Label <Flex direction="column" gap="small"> <Label htmlFor="first_name">First Name:</Label> <Input id="first_name" name="first_name" /> </Flex> Label は UI 要素のキャプションを表します。Label コンポーネントは Input コンポーネントと一緒に使うことで、独自のフォームフィールドを構成することができます。Label は、 <label> 要素が受け入れる標準的な HTML 属性を受け入れます。標準的な <label> 属性は MDN Documentation で確認することができます。 4. SelectField (更新) <SelectField label="Fruit" descriptiveText="What's your favorite fruit?" isMultiple={true} > <option value="apple">Apple</option> <option value="banana">Banana</option> <option value="orange" disabled>Orange</option> <option value="pineapple">Pineapple</option> <option value="kiwi">Kiwi</option> <option value="tangerine">Tangerine</option> </SelectField> SelectField に isMultiple と selectSize プロパティが追加され、ユーザの選択を処理するための設定オプションが増えました。 5. Button (更新) <Button variation="primary" colorTheme="success" > Click me! </Button> 更新された Button コンポーネントでは、 colorTheme プロパティがサポートされ、より多くのカラーバリエーションを柔軟に組み込むことができるようになりました。 variation 、 size 、 colorTheme プロパティにより、54 種類のスタイルのボタンが用意されました！ 6. Message <Message variation="plain" colorTheme="neutral" heading="A message heading"> Basic message content </Message> Message コンポーネントは Alert コンポーネントの後継です。Message はよりカスタマイズ可能で柔軟性があるため、アプリケーションのより多くの状況で使用することができます。Message にはデフォルトで ARIA ロールが設定されていません。使用するケースに応じて、 role 属性を渡したり、必要に応じて独自の ARIA 属性を追加したりすることができます。Message コンポーネントには、メッセージのカラーバリエーションを増やす colorTheme プロパティがあります。colorTheme プロパティは、同名の buttonプロパティに似ています。 7. Breadcrumbs (パンくずリスト) import { Breadcrumbs } from '@aws-amplify/ui-react'; export default function DefaultBreadcrumbsExample() { return ( <Breadcrumbs items={[ { href: '/', label: 'Home', }, { href: '/react/components', label: 'Components', }, { label: 'Breadcrumbs', }, ]} /> ); } Breadcrumbs コンポーネントは柔軟性があるので、レンダリングされるものを完全にコントロールすることができ、より高度なユースケースをアンロックすることができます。 <Breadcrumbs.Container> <Breadcrumbs.Item> <Breadcrumbs.Link> <Breadcrumbs.Separator> Breacrumbs コンポーネントを NextJS の Link コンポーネントと useRouter コンポーネントと一緒に使うことで、現在のパスに基づいて Breadcrumbs を自動的に生成することができます。 import Link from 'next/link'; import { Breadcrumbs } from '@aws-amplify/ui-react'; import { useRouter } from 'next/router'; export default function NextBreadcrumbsExample() { const { asPath } = useRouter(); const nestedRoutes = asPath .split('#')[0] .split('?')[0] .split('/') .filter((subpath) => subpath.length > 0); const breadcrumbs = [ { href: '/', text: 'Home' }, ...nestedRoutes.map((subpath, i) => { const href = '/' + nestedRoutes.slice(0, i + 1).join('/'); const text = subpath; return { href, text }; }), ]; return ( <Breadcrumbs.Container> {breadcrumbs.map(({ href, text }, i) => { const isCurrent = i === breadcrumbs.length - 1; return ( <Breadcrumbs.Item key={href}> <Link href={href} passHref> <Breadcrumbs.Link isCurrent={isCurrent}>{text}</Breadcrumbs.Link> </Link> {isCurrent ? null : <Breadcrumbs.Separator />} </Breadcrumbs.Item> ); })} </Breadcrumbs.Container> ); } 8. Dropzone export default function DefaultDropZoneExample() { const [files, setFiles] = React.useState([]); return ( <> <DropZone onDropComplete={({ files }) => { setFiles(files); }} > Drag images here </DropZone> {files.map((file) => ( <Text key={file.name}>{file.name}</Text> ))} </> ); } DropZone コンポーネントは、要素に必要なイベントハンドラを追加し、ファイルタイプによってドロップされたファイルをフィルタリングします。ドロップされた後のファイルを取得するには、 files と rejectedFiles 配列を持つ関数である onDropComplete プロパティを使用できます。 9. IconsProvider Amplify UI コンポーネントで使用するアイコンをカスタマイズするには、アプリケーションを IconProvider コンポーネントでラップし、変更したいアイコンを渡します。 icons プロパティは、アイコンの名前を React コンポーネントにマッピングするオブジェクトでなければなりません。例えば、以下のように実装することが出来ます。 import { IconsProvider, Rating } from '@aws-amplify/ui-react'; import { FiStar } from 'react-icons/fi'; export default function IconProviderExample() { return ( <IconsProvider icons={{ rating: { filled: <FiStar />, empty: <FiStar />, }, }} > <Rating value={3.5} /> </IconsProvider> ); } IconProvider コンポーネントは、React コンテキストを使用して、子コンポーネントがカスタムアイコンセットを利用できるようにします。IconProvider 内部のどのコンポーネントも、内部フックを介してカスタムアイコンにアクセスできます。アプリケーションの特定の部分でアイコンを変更したい場合は、他の React コンテキストと同じように、アプリケーションのさまざまな部分で IconsProvider をネストできます。 10. StorageImage <StorageImage alt="cat" imgKey="cat.jpg" accessLevel="public" /> StorageImage コンポーネントは @aws-amplify/ui-react-storage パッケージの新しい Storage 接続コンポーネントで、Storage に保存された画像を簡単に表示するために使用できます。 まとめ これら 10 個の新しいコンポーネントと更新されたコンポーネントにより、Amplify UI は React アプリケーションの構築と拡張においてより柔軟性と効率性を提供します。私たちは、アクセスしやすく、カスタマイズ可能で、ユーザーフレンドリーなアプリケーションを簡単に作成するために必要なツールを提供するために努力を続けています。他にもご希望のコンポーネントがありましたら、 GitHub でお知らせください 。 これらのコンポーネントやその他の Amplify UI の詳細については、 ドキュメントをご覧ください 。 本記事は、「 AWS Amplify UI: 10 new and updated components 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

この記事は Amazon Redshift: Lower price, higher performance の翻訳記事です。 ほぼすべてのお客様と同様に、あなたも可能な限り最高のパフォーマンスを実現しながら、コストを最小限に抑えたいと考えることでしょう。つまり、コストパフォーマンスに注意を払う必要があるということです。 Amazon Redshift を使用すると、コストを最小限に抑えながら最高のパフォーマンスを実現することができます。 Amazon Redshift は、数百人の同時ユーザーをサポートするための同時実行スケーリングや、クエリパフォーマンスを高速化するための強化された文字列エンコーディング、Amazon Redshift Serverless のパフォーマンス強化といった先進的な技術を使用することで、実際のワークロードにおいて他のクラウドデータウェアハウスと比較して、ユーザーあたりのコストを最大 4.9 倍削減し、最大 7.9 倍優れたコストパフォーマンスを実現します。コストパフォーマンスが重要な理由と、Amazon Redshift では、特定のレベルのワークロードパフォーマンスを得るためにどの程度のコストが必要になるかという尺度、つまりパフォーマンス ROI (投資収益率) を理解するためにぜひ読んでください。 コストとパフォーマンスの両方がコストパフォーマンスの計算に含まれるため、コストパフォーマンスについては 2 つの考え方があります。 1 つ目の考え方は、コストを一定に保つことです。1 ドルを使えるとしたら、データウェアハウスからどの程度のパフォーマンスが得られるでしょうか？ コストパフォーマンスの優れたデータベースは、支出した 1 ドルごとに優れたパフォーマンスを提供します。したがって、同じ一定のコストの 2 つのデータウェアハウスを比較する場合、コストパフォーマンスの高いデータベースの方がクエリの実行が速いです。 2 つ目の考え方は、パフォーマンスを一定に保つことです。ワークロードを 10 分以内で完了する必要がある場合、それにかかるコストはいくらでしょうか？ コストパフォーマンスに優れたデータベースでは、ワークロードを10 分以内でより低コストで実行できます。したがって、パフォーマンスを一定に保ち、同じパフォーマンスを実現するサイズの 2 つのデータウェアハウスを比較する場合、コストパフォーマンスの高いデータベースの方がコストが低くなり、コストを節約することができます。 最後に、コストパフォーマンスのもう 1 つの重要な観点は、予測可能性です。データウェアハウスのユーザー数が増加するにつれて、データウェアハウスのコストがどれくらいかかるかを把握することは、計画を立てる上で非常に重要です。今日最高のコストパフォーマンスを提供するだけでなく、ユーザーやワークロードが追加されたときに予測どおりに拡張し、最高のコストパフォーマンスを提供する必要があります。理想的なデータウェアハウスは線形にスケールする必要があります。つまり、クエリスループットを 2 倍にするためにデータウェアハウスをスケーリングすることは、理想的にはコストが 2 倍 (またはそれ以下) になるということです。 この投稿では、Amazon Redshift がその他の主要なクラウドデータウェアハウスと比較して、コストパフォーマンスが非常に優れているということを説明するために、パフォーマンスの計測結果を共有します。これは、他のデータウェアハウスに費やすのと同じ金額を Amazon Redshift に費やした場合、Amazon Redshift を使用した方がパフォーマンスが向上することを示しています。あるいは、同じパフォーマンスを実現するように Redshift クラスターのサイズを調整すると、他のデータウェアハウスと比較してコストが低くなるということです。 実ワークロードにおけるコストパフォーマンス Amazon Redshift を使用すると非常に多様なワークロードを強化できます。複雑な抽出、変換、ロード (ETL) ベースのレポートのバッチ処理やリアルタイムのストリーミング分析から、数百、さらには数千の同時ユーザーに1 秒未満の応答時間でサービスを提供する必要がある低レイテンシーのビジネスインテリジェンス (BI) ダッシュボードまでのありとあらゆるワークロードです。AWS は、お客様のコストパフォーマンスを継続的に向上させる方法の 1 つとして、Amazon Redshift のパフォーマンスをさらに向上できる機会とお客様のユースケースを見つけるために、Redshift フリートからのソフトウェアおよびハードウェアのパフォーマンステレメトリーを常にレビューしています。 フリート テレメトリによるパフォーマンス最適化の最近の例としては、次のようなものがあります。 文字列型に対するクエリの最適化 – Amazon Redshift が Redshift フリート内のさまざまなデータ型をどのように処理するかを分析した結果、文字列を多く含むクエリを最適化すると、お客様のワークロードに大きなメリットがあることがわかりました。 (これについては、この投稿の後半で詳しく説明します。) 自動化されたマテリアライズド ビュー – Amazon Redshift のお客様は、サブクエリパターンを持つ多くのクエリを実行することが多いことがわかりました。たとえば、いくつかの異なるクエリが同じ結合条件を使用して同じ 3 つのテーブルを結合する場合があります。 Amazon Redshift は、マテリアライズドビューを自動的に作成および維持し、機械学習による 自動マテリアライズドビュー の自律的な機能を使用して、マテリアライズドビューを使用するようにクエリを透過的に書き換えられるようになりました。自動マテリアライズドビューを有効にすると、ユーザーの介入なしに、反復的なクエリのパフォーマンスを透過的に向上させることができます。 (ただし、自動マテリアライズドビューは、この投稿で説明したどのベンチマーク結果にも使用されていません) 同時実行性の高いワークロード – Amazon Redshift を使用してダッシュボードのようなワークロードを提供するユースケースが増加しています。これらのワークロードの特徴は、要求されるクエリ応答時間が 1 桁秒以下であり、使用パターンが突発的でしばしば予測不可能で、数十から数百のユーザーが同時にクエリを実行します。この典型的な例は、Amazon Redshift を利用した BI ダッシュボードで、多くのユーザーが週初めの月曜の朝にトラフィックが急増します。 特に同時実行性の高いワークロードは非常に幅広い適用範囲を持っています。ほとんどのデータウェアハウスのワークロードでは同時実行で動作し、Amazon Redshift では、数百、さらには数千のユーザーが同時にクエリを実行することも珍しくありません。 Amazon Redshift は、クエリの応答時間を予測可能かつ高速に保つように設計されています。 Redshift Serverless は、必要に応じて自動的に処理能力を追加および削除することで、クエリの応答時間を高速かつ予測可能に保ちます。つまり、1 人または 2 人のユーザーがアクセスしているときに迅速に読み込まれる Redshift Serverless のダッシュボードは、多くのユーザーが同時にアクセスしている場合でも引き続き迅速に読み込まれることを意味します。 このタイプのワークロードをシミュレートするために、100 GB データセットを使用した TPC-DS から派生したベンチマークを使用しました。 TPC-DS は、さまざまな典型的なデータウェアハウスクエリを含む業界標準のベンチマークです。 100 GB という比較的小規模なスケールでは、このベンチマークのクエリは Redshift Serverless 上で平均数秒で実行されます。これは、インタラクティブな BI ダッシュボードを読み込むユーザーが期待する典型的な速度であることを表しています。このベンチマークでは 1 ～ 200 の同時テストを実行し、同時にダッシュボードを読み込もうとする 1 ～ 200 人のユーザーをシミュレートしました。また、自動スケールアウトをサポートするいくつかの一般的なクラウドデータウェアハウスに対してテストを繰り返しました (自動スケールアップをサポートしていないため、私たちはブログ「 Amazon Redshift の継続的なコストパフォーマンス最適化 」の競合他社 A を含めませんでした)。私たちは、平均クエリ応答時間を測定しました。これは、ユーザーがクエリの完了 (またはダッシュボードの読み込み) を待つ時間を意味します。結果を次のグラフに示します。 競合他社 B は、同時クエリ数が約 64 個になるまではうまく拡張できていますが、その時点で追加のコンピューティングを提供できなくなり、クエリがキューに入り始め、クエリの応答時間の増加につながっています。競合他社 C も自動的にスケーリングできていますが、Amazon Redshift や競合他社 B よりもクエリのスループットが低くなり、クエリのランタイムを低く保つことができません。さらに、コンピューティングが不足した場合のクエリのキューイングはサポートしていないため、同時ユーザー数が約 128 人を超えて拡張することができません。これを超えて追加のクエリを送信すると、システムによって拒否されます。 ここで、Redshift Serverless は、数百のユーザーが同時にクエリを実行している場合でも、クエリ応答時間を約 5 秒と比較的一定に保つことができます。競合他社 B と競合他社 C の平均クエリ応答時間は、データウェアハウスの負荷が増加するにつれて着実に増加しています。その結果、データウェアハウスがビジー状態になると、ユーザーはクエリが返るまでより長く (最大 16 秒) 待たなければならなくなります。これは、ユーザーがダッシュボードを更新しようとしている場合 (リロード時に複数の同時クエリを送信することもあります)、Amazon Redshift は、たとえダッシュボードが他の数十、数百ものユーザーによって同時に読み込まれている場合でも、ダッシュボードの読み込み時間を一貫した状態に保つことができることを意味します。 Amazon Redshift は実行時間の短いクエリに対して非常に高いクエリスループットを提供できるため (「 Amazon Redshift の継続的なコストパフォーマンス最適化 」で説明したように)、スケールアウト時にこれらの高い同時実行性をより効率的に処理できるため、大幅に低いコストで処理することもできます。 これを定量化するために、次のグラフに示すように、前のテストで各データウェアハウスの公開されている オンデマンド価格 を使用してコストパフォーマンスを調べます。なお、 リザーブドインスタンス (RI) 、特に全額前払いオプションで購入した 3 年間の RI を使用すると、プロビジョニングされたクラスター上で Amazon Redshift を実行するコストが最も低くなり、オンデマンドまたは他の RI オプションと比較して、最高の相対的な価格パフォーマンスが得られることには注目すべきでしょう。 したがって、Amazon Redshift は、より高い同時実行でより優れたパフォーマンスを提供できるだけでなく、大幅に低いコストでそれを実現できます。コストパフォーマンスの図の各データポイントは、指定された同時実行数でベンチマークを実行するコストに相当します。コストパフォーマンスは線形であるため、任意の同時実行数でベンチマークを実行したコストを同時実行数 (このグラフの同時ユーザー数) で割ることで、この特定のベンチマークで新しいユーザーを追加するたびにどれくらいのコストがかかるかを知ることができます。 ここまでの結果は簡単に再現できます。ベンチマークで使用されるすべてのクエリは GitHub リポジトリ で利用でき、パフォーマンスはデータウェアハウスを起動し、Amazon Redshift で同時実行スケーリング (または他のウェアハウスで対応する自動スケーリング機能) を有効にし、データをロードすることによってカスタマイズなしの状態で測定します (手動でのチューニングやデータベース固有のセットアップはありません）。そして、各データウェアハウスで 同時実行数を1-200の間で32刻みで変化させ、同時実行テストを行いました。上述の GitHub リポジトリは、公式 TPC-DS データ生成キットを使用して事前生成された (かつ変更されていない)、 Amazon Simple Storage Service (Amazon S3) 内にある様々なスケールのTPC-DSデータを参照しています。。 文字列を多く含むクエリの最適化 前述したように、Amazon Redshift チームは、お客様にさらに優れたコストパフォーマンスを提供するための新しい機会を継続的に探しています。パフォーマンスを大幅に向上させるために最近開始した改善の 1 つは、文字列データに対するクエリのパフォーマンスを高速化する最適化です。たとえば、 SELECT sum(price) FROM sales WHERE city = ‘New York’ のようなクエリを使用して、ニューヨーク市にある小売店から得られた総収益を確認するとします。このクエリは文字列データ ( city = ‘New York’ ) を述語に適用しています。ご想像のとおり、文字列データ処理はデータウェアハウスアプリケーションで広く使用されています。 お客様のワークロードが文字列にアクセスする頻度を定量化するために、Amazon Redshift が管理する数万のお客様のクラスターのフリートテレメトリを使用して、文字列データ型の使用状況の詳細な分析を実施しました。分析の結果、クラスターの 90% では文字列カラムが全カラムの少なくとも 30% を構成し、クラスターの 50% では文字列カラムが全カラムの少なくとも 50% を構成していることがわかりました。さらに、Amazon Redshift クラウドデータウェアハウスプラットフォームで実行されるクエリの大部分は、少なくとも 1 つの文字列カラムにアクセスしています。もう 1 つの重要な要素は、文字列データはカーディナリティが低いことが非常に多く、列に含まれる一意の値のセットが比較的少ないことを意味します。たとえば、販売データを表す orders テーブルには数十億の行が含まれている場合がありますが、そのテーブル内の order_status 列には、 pending 、 in process 、 completed などの数十億の行にわたって一意の値がわずかしか含まれていない可能性があります。 この記事の執筆時点では、Amazon Redshift のほとんどの文字列カラムは LZO または ZSTD アルゴリズムで圧縮されています。これらは優れた汎用圧縮アルゴリズムですが、カーディナリティの低い文字列データを活用するように設計されていません。特に、データを操作する前に解凍する必要があり、ハードウェアメモリ帯域幅の使用効率が低くなります。カーディナリティの低いデータの場合、より最適な別のタイプのエンコーディングである BYTEDICT があります。このエンコードでは、ディクショナリエンコードスキームが使用されており、データベースエンジンは圧縮データを最初に解凍する必要がなく、圧縮データに対して直接操作できます。 文字列の多いワークロードのコストパフォーマンスをさらに向上させるために、Amazon Redshift は現在、BYTEDICT としてエンコードされたカーディナリティの低い文字列カラムのスキャンと述語評価を、LZO や ZSTD などの圧縮エンコーディングと比較して 5 ～ 63 倍高速化する追加のパフォーマンス強化を導入しています (次のセクションの結果を参照)。 Amazon Redshift は、CPU 効率が高い軽量なBYTEDICT でエンコードされたカーディナリティの低い文字列カラムをベクトル化スキャンすることで、このパフォーマンスの向上を実現します。これらの文字列処理の最適化により、最新のハードウェアが提供するメモリ帯域幅が効果的に利用され、文字列データのリアルタイム分析が可能になります。これらの新しく導入されたパフォーマンス機能は、カーディナリティの低い文字列カラム (最大数百の一意の文字列値) に最適です。 Amazon Redshift データウェアハウスで 自動テーブル最適化 を有効にすることで、この新しい高パフォーマンス文字列の機能強化の恩恵を自動的に受けられます。テーブルで自動テーブル最適化が有効になっていない場合は、Amazon Redshift コンソールの Amazon Redshift Advisor から、文字列絡むの BYTEDICT エンコードへの適合性に関する推奨事項を受け取ることができます。 BYTEDICT エンコードを使用したカーディナリティの低い文字列列を持つ新しいテーブルを定義することもできます。 Amazon Redshift の文字列の拡張機能は、 Amazon Redshift が利用可能 なすべての AWS リージョンで利用できるようになりました。 パフォーマンス測定結果 文字列処理の強化によるパフォーマンスへの影響を測定するために、カーディナリティの低い文字列データで構成される 10 TB (テラバイト) データセットを生成しました。 Amazon Redshift フリートテレメトリからの文字列の長さの 25、50、および 75 パーセンタイルに対応する、短、中、長の文字列を使用して 3 つのバージョンのデータを生成しました。このデータを Amazon Redshift に 2 回ロードし、1 つは LZO 圧縮を使用し、もう 1 つは BYTEDICT 圧縮を使用してエンコードしました。最後に、多くの行 (テーブルの 90%)、中程度の行 (テーブルの 50%)、および少数の行 (テーブルの 1%) を返すスキャンを多用するクエリのパフォーマンスを、これらのカーディナリティの低いデータセットに対して測定しました。パフォーマンス結果を次のグラフにまとめます。 この内部ベンチマークでは、多くの行に一致する述語を含むクエリでは、LZO と比較して新しいベクトル化 BYTEDICT エンコーディングで 5 ～ 30 倍の改善が見られました。一方で、少ない行に一致する述語によるクエリでは 10 ～ 63 倍の改善が見られました。 Redshift Serverless コストパフォーマンス この投稿で示した高い同時実行パフォーマンスの結果に加えて、より大きな 3 TB データセットでTPC-DS 派生のクラウドデータウェアハウスのベンチマークも使用して、Redshift Serverless のコストパフォーマンスを、他のデータウェアハウスと比較しました。私たちは同様の価格のデータウェアハウスを選択しました。今回のケースでは、公開されているオンデマンド価格を使用すると、1 時間あたり 32 ドルの 10% 以内に収まっています。結果は、Amazon Redshift RA3 インスタンスと同様に、Redshift Serverless が他の主要なクラウドデータウェアハウスと比較して優れたコストパフォーマンスを実現していることを示しています。いつものように、これらの結果は、 GitHub リポジトリ の SQL スクリプトを使用して再現できます。 Amazon Redshift がデータ分析のニーズをどのように満たすかを確認する最良の方法として、自身の PoC ワークロードを使用して Amazon Redshift を試してみることをお勧めします。 あなたのワークロードにおける最高のコストパフォーマンスを見つける この投稿で使用されているベンチマークは、業界標準の TPC-DS ベンチマークから派生したもので、次の特徴があります。 スキーマとデータは TPC-DS から変更せずに使用しています。 クエリは、TPC-DS キットのデフォルトのランダムシードを使用して生成されたクエリパラメーターを持つ公式 TPC-DS キットを使用して生成しています。データウェアハウスがデフォルトの TPC-DS クエリの SQL 言語をサポートしていない場合は、TPC で承認された変更を加えたクエリを使用しています。 テストには 99 個の TPC-DS の SELECT クエリを含みます。これには、メンテナンスとスループットの手順は含んでいません。 単発の 3TB 同時実行テストでは、3 回の POWER RUN が実行され、データウェアハウスごとに最良の実行結果を採用しました。 TPC-DS クエリのコストパフォーマンスは、時間あたりのコスト (USD) にベンチマークの実行時間 (時間単位) を掛けたものとして計算しています。これは、ベンチマークの実行コストに相当します。前述したようにリザーブド インスタンスの価格ではなく、すべてのデータウェアハウスで最新の公開されたオンデマンド価格を使用しています。 これをクラウドデータウェアハウスベンチマークと呼びます。 GitHub リポジトリ で利用可能なスクリプト、クエリ、データを使用して、前述のベンチマーク結果を簡単に再現できます。この投稿で説明されているように、これは TPC-DS ベンチマークから派生したものであり、テストの結果は公式仕様に準拠していないため、公開されている TPC-DS の結果と比較することはできません。 結論 Amazon Redshift は、さまざまなワークロードに対して業界最高のコストパフォーマンスを提供することに尽力しています。 Redshift Serverless は、最良の (最も低い) コストパフォーマンスでリニアにスケールし、一貫したクエリ応答時間を維持しながら数百人の同時ユーザーをサポートします。この投稿で説明したテスト結果に基づくと、Amazon Redshift は、最も近い競合他社 (競合 B) と比較して、同じレベルの同時実行数で最大 2.6 倍優れたコストパフォーマンスを示しました。前述したように、3 年間全額前払いオプションでリザーブドインスタンスを使用すると、Amazon Redshift の実行コストが最も低くなり、この投稿で使用したオンデマンドインスタンスの価格と比較して、相対的なコストパフォーマンスがさらに向上します。継続的なパフォーマンス向上に対する当社のアプローチには、顧客のユースケースとそれに関連するスケーラビリティのボトルネックを理解するというお客様を中心とした考え方と、パフォーマンスを大幅に最適化する機会を特定するための継続的なフリートデータ分析を組み合わせた独自の組み合わせが含まれます。 各ワークロードには独自の特性があるため、まだ始めたばかりの場合は、Amazon Redshift がどのようにコストを削減しながらパフォーマンスを向上させるかを理解するための最良の方法は PoC です。独自の PoC を実行する場合は、クエリスループット (1 時間あたりのクエリ数)、応答時間、コストパフォーマンスなどの適切な指標に焦点を当てることが重要です。 PoC を自分で実行するか、AWS または システムインテグレーターおよびコンサルティングパートナー の 支援 を受けて、データ主導の意思決定を行うことができます。 Amazon Redshift の最新の開発状況を常に把握するには、 Amazon Redshift の最新情報 フィードをフォローしてください。 翻訳はソリューションアーキテクトの池田 敬之が担当しました。

この投稿は、プリンシパルソリューションアーキテクトの Anton Aleksandrov とシニアプロダクトマネージャーの Tarun Rai Madan の投稿を翻訳したものです。 本日、 AWS Lambda は、 Amazon Simple Queue Service（Amazon SQS） をイベントソースとして構成したスパイクのある Lambda ワークロードのポーリングスケールアップ率を最大 5 倍高速化したことを発表しました。 この機能により、Lambda と SQS を使用してイベント駆動型アプリケーションを構築し、SQS キュー内のメッセージのバースト時に応答性の高いスケーリングを実現します。また、より高速なメッセージ処理を実現するために Lambda 関数または SQS キューを複製する必要性を減らします。 概要 AWS Lambda で最新のイベント駆動型およびメッセージングアプリケーションを構築するお客様は、分離されたアーキテクチャを作成するための基本的なビルディングブロックとして Amazon SQS を使用します。 Amazon SQS は、マイクロサービス、分散システム、サーバーレスアプリケーション向けのフルマネージドなメッセージキューイングサービスです。Lambda 関数がイベントソースとして SQS キューをサブスクライブすると、Lambda はキューをポーリングし、メッセージを取得し、取得したメッセージをバッチで関数ハンドラに送信して処理します。メッセージを効率的に消費するために、Lambda はキューの深さの増加を検出し、キューに入れられたメッセージを処理するためのポーラープロセスの数を増やします。 今日まで、Lambda は SQS キューを購読した Lambda 関数に対して 1 分間に最大 60 回の同時実行を追加し、約 20 分で最大 1,250 の同時実行にスケールアップしていました。しかし、お客様の声では、Lambda と SQS を使用して構築する最新のイベント駆動型アプリケーションのいくつかは、メッセージの突然の急増に敏感であり、エンドユーザーのメッセージの処理に顕著な遅延を引き起こす可能性があるとのことでした。SQS キューでメッセージのバーストがあるアプリケーションに Lambda のパワーを活用するために、これらのお客様はより速くスケールアップするための Lambda メッセージポーリングが必要でした。 今日の発表により、SQS キューを購読する Lambda の機能は、メッセージバックログが急増するキューに対して最大 5 倍速くスケールし、1 分間に最大 300 の同時実行を追加し、最大 1,250 の同時実行数にスケールアップできます。このスケーリングの改善は、Lambda と SQS の統合のシンプルさを使用して、特にリアルタイムシステム向けに、受信メッセージの急増時により高速に拡張できるイベント駆動型アプリケーションを構築するのに役立ちます。また、SQS キューでのメッセージの急増時に処理を高速化する利点を提供する一方で、SQS イベントソースごとに最大同時 Lambda 呼び出しを制限する柔軟性を提供し続けます。 SQS による最大同時 Lambda 呼び出しの制御 新しく改善されたスケーリングレートは、イベントソースとして Lambda と SQS を使用するすべての AWS アカウントに自動的に適用されます。取らなければならない明示的なアクションはなく、追加費用もありません。このスケーリングの改善は、お客様がより高速な SQS ポーリングスケールアップを必要とする、より高性能な Lambda アプリケーションを構築するのに役立ちます。関連するダウンストリームが高負荷になる可能性を低減するために、Lambda は関数レベルで予約済み同時実行数（Reserved concurrency）、イベントソースレベルで最大同時実行数（Maximum concurrency）を設定できます。 次の図は、SQS イベントソースの流量を制御するために使用できる設定を示しています。予約済み同時実行数（Reserved concurrency）を使用して関数レベルのスケーリングを制御し、最大同時実行数（Maximum concurrency）を使用してイベントソースのスケーリングを制御します。 予約済み同時実行数（Reserved concurrency） は、関数に割り当てる最大同時実行数です。関数に割り当てられた予約済み同時実行数がある場合、他の関数はその同時実行数を使用できません。 関数にスケールアップするのに十分な同時実行数を確保したい場合は、予約済み同時実行数を使用することを推奨します。SQS イベントソースが Lambda の同時実行をスケールアップしようとしているが、関数がすでに予約済み同時実行数によって定義されたしきい値に達している場合、Lambda サービスはさらなる関数呼び出しを制限します。 これにより、SQS イベントソースがスケールダウンを試み、同時に処理されるメッセージの数が減少する可能性があります。キューの設定に応じて、制限されたメッセージは再試行のためにキューに返されるか、保持ポリシーに基づいて期限切れになるか、 デッドレターキュー (DLQ) または 失敗の宛先 (on-failure destination) に送信されます。 最大同時実行数（Maximum concurrency） 設定を使用すると、イベントソースレベルで同時実行数を制御できます。これにより、イベントソースが Lambda 関数に送信しようとする同時呼び出しの最大数を定義できます。1つの関数に複数の SQS イベントソースが構成されているシナリオでは、各イベントソースの最大同時実行数を個別に定義することで、よりきめ細やかな制御が可能です。SQS イベントソースにレート制御を追加しようとする場合は、より高い柔軟性を提供するために、まず初めに最大同時実行数の設定を評価することを推奨します。 予約同時実行と最大同時実行は補完的な機能であり、併用することができます。最大同時実行数は、ダウンストリームシステムが高負荷になるのを防ぐために呼び出しをスロットルするのに役立ちます。予約同時実行数は、関数が利用可能な同時実行数を確保するのに役立ちます。 シナリオ例 あなたのビジネスはストレージから大量の文書を処理する必要があると考えてください。数時間ごとに、ビジネスパートナーは大量のドキュメントをアカウントの S3 バケットにアップロードします。 回復力（レジリエンシー）のために、アップロードされた各ドキュメントの SQS キューにメッセージを送信するようにアプリケーションを設計したので、誤ってスキップすることなく効率的に処理できます。ドキュメントは、単一のドキュメントを処理するのに約 2 秒かかる Lambda 関数を使用して処理されます。 これらのドキュメントの処理は CPU 使用率の高い操作であるため、1 つの呼び出しごとに 1 つのドキュメントを処理することにしました。Lambda のパワーを使用して、できるだけ多くの同時実行環境に並列処理をファンアウトしたいと考えています。Lambda 関数は、これらのドキュメントを可能な限り迅速にスケールアップし、コストを節約するためにすべてのドキュメントが処理されたらゼロにスケールダウンします。 ビジネスパートナーが 20万件の文書をアップロードすると、20万件のメッセージが SQS キューに送信されます。Lambda 関数は SQS イベントソースで構成され、キューからのメッセージを消費し始めます。 この図は、SQS イベントソースのスケーリング改善の前にテストシナリオを実行した結果を示しています。予想通り、同時実行数は 1 分間に 60 増加することがわかります。900 の同時実行数に徐々にスケールアップし、キュー内のすべてのメッセージを処理するには、約 16 分かかります。 次の図は、SQS イベントソースのスケーリングの改善後に同じテストシナリオを実行した結果を示しています。両方のチャートに使用される時間枠は同じですが、2 番目のチャートのパフォーマンスは優れています。同時実行数は毎分 300 増加します。1,250 の同時実行数にスケールアップするのに 4 分しかかからず、キュー内のすべてのメッセージは約 8 分で処理されます。 この例をデプロイする サンプルプロジェクト を使用して、自分の AWS アカウントでこのパフォーマンステストを複製します。 AWS Cloud Development Kit (CDK) を使用して AWS アカウントのサンプルプロジェクトをプロビジョニングするには、README.md の指示に従ってください。 このサンプルプロジェクトは、20万件のメッセージを処理する大規模なワークロードを実証するように構成されています。アカウントでこのサンプルプロジェクトを実行すると、料金が発生する場合があります。 AWS Lambda の料金 と Amazon SQS の料金 を参照してください。 デプロイしたら、“sqs-cannon” ディレクトリの下にあるアプリケーションを使用して、20万件のメッセージを SQS キューに送信します(もしくは他の数値を設定します)。SQS キューにメッセージを入力するのには数分かかります。すべてのメッセージが送信されたら、README.md で説明されているように SQS イベントソースを有効にし、プロビジョニングされた CloudWatch ダッシュボードのチャートをモニタリングします。 新しい AWS アカウントのデフォルトの同時実行数クォータは 1000 です。このクォータの増加をリクエストしていない場合、同時実行数はこの数に制限されます。 サービスクォータ を使用するか、アカウントチームに連絡して同時実行数の増加をリクエストしてください。 セキュリティのベストプラクティス Lambda 関数に SQS キューへのアクセスを許可するときは、常に最も特権の低い権限を使用してください。これは、特定の機能のみが特定のキューに対して特定のアクションを実行する権限を持つようにすることで、潜在的な攻撃面を減らします。たとえば、関数がキューからのみポーリングする場合は、メッセージを読む権限を付与しますが、新しいメッセージを送信する権限は付与しません。 関数実行ロール は、関数が他のリソースで実行できるアクションを定義します。 キューアクセスポリシー は、このキューにアクセスできるプリンシパルと、許可されるアクションを定義します。 サーバーサイド暗号化(SSE) を使用して、暗号化された SQS キューに機密データを保存します。SSE では、メッセージは常に暗号化された形式で保存され、SQS は許可された消費者に送信するためにのみ復号化します。SSE は、SQS が管理する暗号化キー (SSE-SQS) または AWS Key Management Service で管理されるキー (SSE-KMS) を使用して、キュー内のメッセージの内容を保護します。 まとめ 改善された Lambda の SQS イベントソースポーリングスケールアップ機能は、SQS キューを使用したスパイクのあるイベント駆動型ワークロードのスケールアップパフォーマンスを追加料金なしで最大 5 倍高速化できます。この改善は、SQS キューのメッセージの急増時に処理を高速化するメリットを顧客に提供しますが、イベントソースとして SQS による最大同時実行数を制限する柔軟性を提供し続けます。 より多くのサーバーレス学習リソースについては、 Serverless Land をご覧ください。 翻訳はソリューションアーキテクトの淡路が担当しました。原文は こちら です。

はじめに 2023年10月12日にAWS Support の事例Webinar  を実施しました。AWS サポートは障害対応だけでなく、開発時から運用まで、AWS をより良くご利用いただくための支援をします。例えば、コスト削減、セキュリティ強化、重要なシステムのマイグレーションなどのクラウドの活用に関するお客様の課題をサポートします。最上位プランである「エンタープライズ」に加えて、2023年１月から新たに「エンタープライズ On-Ramp」が登場し、よりリーズナブルな価格で上位サポートがご利用できるようになりました。本セミナーでは「エンタープライズ」と「エンタープライズ On-Ramp」をご利用のお客様にご登壇いただき、導入の背景や効果をご紹介いただきました。 セッション１：RevComm の急速な事業成長を支えるエンタープライズサポート 株式会社RevComm は 2017 年の創業以来、AI 搭載型のクラウド IP 電話 「MiiTel （ミーテル）」を中心に急速な事業成長を遂げ、累計のユーザー数は5万人を超えました。CTO の平村様とLead Infrastructure Engineerの工藤様のお二人から、経営とエンジニアリングの現場という２つの視点で事例をご紹介いただきます。 RevComm は急速な事業拡大を背景に2022年7月にエンタープライズサポートに加入しました。導入の狙いとしては、①開発の円滑化による更なる事業拡大、②新たな顧客層（金融機関や自治体等）からのセキュリティや高可用性へのニーズの対応、③従業員のスキルアップ（導入した頃は150人程度で40% がエンジニア）、④AWS の有効活用による技術競争力の強化、の４点です。 導入効果の1つとして、エンジニア一人ひとりがAWS サポートを使いこなし、技術的課題を早く解決できるようになったことが挙げられます。RevComm はマイクロサービスチーム（ソフトウエアエンジニア）がインフラ構築・運用を担当し、インフラエンジニアは横断的な部分を担当しています。つまり、ソフトウエアエンジニアもAWS に触れる機会があるのですが、エンタープライズサポート導入前は開発段階ではAWS サポートを活用していませんでした。しかし、導入後は開発に関するAWS サポートへの質問が42件まで増加し、その約7割がソフトウエアエンジニアからでした。各エンジニアが技術的課題を自ら解決できるようになり、インフラエンジニアがボトルネック化しないスケーラブルな開発体制に変わったとも言えます。 また、担当テクニカルアカウントマネージャ（TAM ）からの情報提供も効率的な事業運営に役立っています。例えば、新機能やサービスの情報やメンテナンスの情報をRevComm の状況に即してTAM から解説やフォローをしてもらえます。インフラ側から各エンジニアに最新の情報を展開することでAWS をうまく使いこなすために一役買っています。 ［ プレゼン資料のダウンロードはこちら ］ セッション2：開発チームの自走を支える為の AWS エンタープライズサポート 株式会社リクルートは、2021年4月に複数の事業会社・機能会社を統合する形で誕生しました。多くの開発チームを横断的に支援するCCOE としてご活躍の宮地様からお話いただきます。 エンタープライズサポートへの加入はある障害がきっかけでした。オペレーションミスが障害のトリガーでしたが、そのアカウントがサポート未加入のためAWS サポートに技術的な問い合わせができず、再発防止のための根本原因の特定には至りませんでした。当時は開発チーム毎にサポート加入を決めていました。しかし、責任あるプロダクト提供のためには全アカウントでエンタープライズサポートに入るべきだと考え、CCOE から意見を上げ全社的な意思決定につなげました。これは、リクルートが「ボトムアップ組織」であることをよく表していると思います。 仕様や設計の質問もできるAWS サポートは、開発チームの自走に役立っています。TAM と協力し、AWS サポートの使い方勉強会を社内向けに行った結果、問い合わせ件数が２倍以上に増加しました。TAM との定例会では、実際の問い合わせをレビューし、正確な回答を早く引き出すアドバイスをTAM からもらうことで、問合せの質の向上にも取り組んでいます。また、ナレッジの蓄積も重要です。様々な知見やノウハウが含まれているためAWS サポートからの回答が自動的に社内wiki に蓄積される仕組みをつくり他のエンジニアも参照できるようにすることで、組織的な技術力強化に利用しています。 複雑な課題が発生したときのTAM からの支援もメリットの１つです。以前、複数アカウント間でのデータ連携の問題が発生し、問題個所の特定に時間がかかったことがありました。リクルートの開発チーム、AWS のSA ・TAM が協力し事象を整理したことで、適切なアカウントからAWS サポートに適切な問い合わせができました。結果的にAmazon Aurora の仕様によるものと分かりましたが、インタラクティブな初期対応は、エンタープライズサポートならではだと思います。 ［ プレゼン資料のダウンロードはこちら ］ セッション3：カオナビにおける AWS サポートアップグレード 株式会社カオナビ プラットフォーム本部長の髙橋様から「プロダクトの成長を維持する開発組織であり続けるために、柔軟な権限分離と委譲を実現する手法としてマルチアカウント化を進め、エンタープライズ On-Ramp プランを導入するまでのお話」というテーマでお話をしていただきます。 タレントマネジメントシステム「カオナビ」は2012年の事業開始から成長を続け3,000を超える企業に採用されています。事業成長にともなってエンジニア数も増加すると、生産性・開発効率の向上や、品質（セキュリティ・統制）の維持が課題となります。この課題に対応するために、開発チーム体制を「単一チーム」→「チーム開発」→「ハイブリッド」と変化させてきました。また、体制に合わせてシステムを分割するために、権限の分離や移譲、統制の強化も必要ですし、変化に対応するための柔軟性の維持も大切です。そこで1つのAWS アカウントを分割し複数のアカウントで運用する、マルチアカウント運用の整備も進めています。 AWS アカウントの増加に伴いAWS サポートのアップグレードの検討を行いました。ポイントはサポート利用料と管理コストの2つです。AWS アカウント単位での加入となる開発者プラン・ビジネスプランでは、どのアカウントがどのサポートプランなのか管理が必要です。サポートプランが混在した状況でアカウントが増加していくと、認知コスト、コミュニケーションコスト、プラン変更運用など様々な内部的コストが増大します。一方で、エンタープライズOn-Ramp は全アカウント一括で加入できるため、将来的にも管理コストを抑えることができます。サポート利用料もアカウントが多い場合はビジネスプランと大差がないため、エンタープライズOn-Ramp の採用を決めました。今後はビジネスプランでは利用できなかったプールTAMも活用していきたいと思います。 ［ プレゼン資料のダウンロードはこちら ］ セッション4：エンタープライズ On-Ramp で AWS の利用体験を高める スタートアップ企業である株式会社スタディストでは、創業からAWS を使い「Teachme Biz」、「ハンクラ」というサービスを提供してきました。若松様からSRE の視点でエンタープライズOn-Ramp の活用事例をお話しいただきます。 エンタープライズOn-Ramp に加入した理由は3つです。1つ目は、AWSサポートのリードタイムの改善です。ビジネス的には急いでいてもAWS は正常に使えている場合、AWS サポートへの問い合わせでは高い緊急度を選択できません。しかし、エンタープライズOn-Ramp ではプールTAM にサポートケースをエスカレするとTAM がAWS サポートとのコミュニケーションを支援してくれます。請求に関する急ぎの問い合わせをしたときには期待以上に迅速に対応してもらえ助かりました。 2つ目はサポート未加入のAWS アカウントの解消です。エンタープライズOn-Ramp ではすべてのAWS アカウントからSlack を使って問合せAWS サポートに問い合わせできます。問い合わせ毎にスレッドが作成され履歴が残るため、Slack チャネルに参加しているメンバーへの共有も簡単です。マネジメントコンソールからの問い合わせの場合、必要なIAM 権限が必要で、問合せ内容は個々のエンジニアに閉じていましたが、Slack の活用でナレッジの展開にもつながっています。 3つ目はサポート料金です。最上位のエンタープライズプランは予算オーバーでしたが、エンタープライズOn-Ramp ならスタートアップの当社でも手の届く範囲だったため採用を決めました。エンタープライズ On-Ramp に加⼊したことで、AWS サポートの利⽤体験が大幅に向上しました。もう、ビジネスプランには戻りたくないと思っています。 ［ プレゼン資料のダウンロードはこちら ］ さいごに 本Webinar ではゲストスピーカーの皆様から具体的なエピソードを交えてエンタープライズサポートとエンタープライズOn-Ramp の活用方法を共有いただきました。ご利用を検討中のお客様が「自社にとっての活用方法」をイメージしていただく一助になると幸いです。ミッションクリティカルなシステムの運用にエンタープライズサポートやエンタープライズOn-Ramp の活用をご検討のお客様はAWS の営業担当までお問い合わせください。 本ブログは、技術支援本部　シニア事業開発マネージャー　庄司が担当しました。

この記事は、 AWS App Runner adds support for monorepos を翻訳したものです。 はじめに AWS App Runner は、インフラストラクチャやコンテナに関する経験がなくても、コンテナ化されたウェブアプリケーションや API サービスを構築、デプロイ、実行できる、フルマネージド型のコンテナアプリケーションサービスです。本日より、AWS App Runner はモノレポ構造を取っているソースコードリポジトリからのサービスのデプロイをサポートします。これにより、複数のサービスのソースコードをホストするモノレポにおいて、デプロイするソースディレクトリを AWS App Runner に伝えることができます。 モノレポは、複数の異なるプロジェクトのコードを、明確に定義された関係を持つ単一のリポジトリに保存するソフトウェア開発戦略です。クラウドコンピューティングを利用するお客様は、コラボレーションを強化し、コードの重複を避け、可視性を向上させるために、モノレポ開発戦略を採用している場合があります。これは、マイクロサービスベースのアーキテクチャに従った最新のアプリケーションを開発する場合に特に有益です。 お客様は、AWS App Runner の「ソースからのビルド」機能を使用してソースコードから直接サービスをデプロイすることで、ビルドとデプロイのワークフロー管理を AWS App Runner に任せることができます。以前は、AWS App Runner は、ビルドコマンドと起動コマンドを実行する際にリポジトリのルートディレクトリのみをサポートしていました。本日より、アプリケーションのビルドパイプラインとデプロイパイプラインを個別に管理する必要がなくなります。アプリケーションのビルドとデプロイに使用する AWS App Runner サービス設定でソースディレクトリを定義できます。 サービスの自動デプロイを有効にすることもできます。自動デプロイを有効にすると、AWS App Runner はソースディレクトリまたはサービスの依存関係に更新があったときにサービスを再ビルドしてデプロイします。ソースディレクトリ以外の他のアプリケーションやフォルダが更新されても、AWS App Runner はサービスを不必要に再構築してデプロイしません。 つまり、お客様は AWS App Runner のソースからのビルド機能を利用して、モノレポ構造に従うソースコードリポジトリから直接サービスをデプロイできます。お客様は、ソースコードベースのサービスの標準ビルド料金を支払います。お客様は、モノレポアプリケーションの柔軟性と、AWS App Runner でのシンプルな実行のメリットを享受できます。 ソリューション概要 AWS App Runner でモノレポをサポートする機能を紹介するために、ウォークスルーを行います。1 つのソースコードリポジトリから 2 つのサービス (1 つはフロントエンド、もう 1 つはバックエンド) を含むサンプルアプリケーションをデプロイします。 サンプルアプリケーションは、架空のホテルのウェブサイトを運営する 2 つのマイクロサービスのモノレポによって支えられています。フロントエンドとバックエンドはどちらも、 Express ウェブフレームワークが提供する Node.js アプリケーションです。AWS App Runner を使用して、アプリケーションをホストする 2 つのサービスを作成します。 アプリケーションをサポートするインフラストラクチャの一部として、Amazon Relational Database Service ( Amazon RDS ) データベースと、2 つのサービスとデータベース間の通信に必要な Amazon Virtual Private Cloud ( Amazon VPC ) ネットワークコンポーネントを作成します。パブリックのインターネットトラフィックがフロントエンドサービスに到達し、ホテルの部屋の管理をリクエストできるようになります。 これらのリクエストは、 VPC Connector と VPCIngressConnection を経由して、Amazon RDS データベースにクエリを実行してリクエストを処理するバックエンドサービスに安全に送信されます。最後に、リクエストが処理され、リクエスタがレスポンスを受け取ります。AWS App Runner によるプライベートネットワーキングの詳細については、 VPC ネットワーキング と プライベートサービス に関する詳細な投稿を参照してください。 AWS App Runner サービスを作成する際には、各ソースディレクトリに対して行われたコミットがそれぞれのサービスにのみデプロイされるように、自動デプロイを有効にしてそれぞれのソースディレクトリを設定します。 図 1: AWS クラウド内で接続された 2 つの モノレポ AWS App Runner サービスを示すアーキテクチャ図 前提条件 ウォークスルーを完了するには、次のツールのセットアップが必要です。 AWS Command Line Interface (AWS CLI) version 2 Git jq GitHub アカウント ウォークスルー AWS App Runner の Connection コードベースのサービスの場合、AWS App Runner はリポジトリからコードをデプロイするための Connection を必要とします。このチュートリアルでは、フォークできるホテルアプリケーションのモノレポを GitHub 上に作成しました。 まず、この GitHub リポジトリ にアクセスし、個人の GitHub アカウントにモノレポブランチをフォークします。フォークする際には、Copy the main branch only のチェックを外し、main　以外のブランチもコピーするようにしてください。フォークしたのち、リポジトリの URL を環境変数として保存します。 REPOSITORY_URL=https://<<YOUR_FORKED_REPOSITORY_URL>> 次に、us-east-2 の AWS App Runner コンソール にアクセスして、個人用 GitHub アプリケーションに接続する GitHubConnection という名前の AWS App Runner の Connection を作成します。認証されると、GitHub リポジトリから AWS App Runner サービスを作成できるようになります。この認証ハンドシェイクの仕組みの詳細については、 開発者ガイド をご覧ください。 ConnectionArn をこの後使用できるようにローカルに保存します。 export MRO_AWS_REGION=us-east-2 LIST_CONNECTIONS_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ list-connections \ --connection-name "GitHubConnection") APP_RUNNER_CONNECTION_ARN=$(echo ${LIST_CONNECTIONS_RESPONSE} | jq -r '.ConnectionSummaryList[0].ConnectionArn') ネットワーク及びデータベースインフラストラクチャの構築 サンプルのリポジトリ (もしくは、新しくフォークしたレポジトリ) をクローンします。 export MRO_STACK_NAME=apprunner-monorepo git clone --branch monorepo https://github.com/aws-samples/apprunner-hotel-app.git cd ./apprunner-hotel-app/ それでは以下のコマンドを実行し、AWS CloudFormation のテンプレートである infrastructure/base-infra.yaml を利用して、VPC、VPC エンドポイント、VPC Connector、Amazon RDS インスタンス、データベースの認証情報のための AWS Secrets Manager の Secret をデプロイしましょう。 aws cloudformation deploy \ --region ${MRO_AWS_REGION} \ --template-file ./infrastructure/base-infra.yaml \ --stack-name ${MRO_STACK_NAME} \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM 上記の AWS CloudFormation スタックの実行が完了するまで待ちます。この際、スタック作成に時間がかかる場合はコマンドから抜けてプロンプトに戻る場合があります。必要に応じてスタックの実行状況を確認し、スタックの実行が継続していれば問題ありません。スタックの実行が完了したら、以下のコマンドを実行してスタックから出力値を取得します。 #Hotel Name HOTEL_NAME=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`HotelName`].OutputValue' \ --output text) #RDS Secret SECRET_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`DBSecret`].OutputValue' \ --output text) #VPC ID VPC_ID=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`VPCID`].OutputValue' \ --output text) #App Runner VPC Endpoint VPC_ENDPOINT=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerVPCEndpoint`].OutputValue' \ --output text) #Backend App Runner VPC Connector VPC_BE_CONNECTOR_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerBEVPCConnector`].OutputValue' \ --output text) #Frontend App Runner VPC Connector VPC_FE_CONNECTOR_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerFEVPCConnector`].OutputValue' \ --output text) #App Runner IAM Instance Role INSTANCE_ROLE_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerInstanceRole`].OutputValue' \ --output text) モノレポサービスの作成 これで、バックエンドとフロントエンドの AWS App Runner サービスをサポートするために必要なすべてのインフラストラクチャが揃いました。 バックエンドサービスの作成 それでは、バックエンドサービスを作成しましょう。まず、以下のコマンドを実行して、サービスの構成を表すローカルファイル create_backend_service.json を作成します。SourceDirectory は Git リポジトリ内の backend ディレクトリ が指定されていることに注意してください。 cat > create_backend_service.json << EOF { "ServiceName": "hotel-backend", "SourceConfiguration": { "CodeRepository": { "RepositoryUrl": "${REPOSITORY_URL}", "SourceCodeVersion": { "Type": "BRANCH", "Value": "monorepo" }, "CodeConfiguration": { "ConfigurationSource": "API", "CodeConfigurationValues": { "BuildCommand": "npm install", "Port": "8080", "Runtime": "NODEJS_16", "RuntimeEnvironmentSecrets": { "HOTEL_NAME" : "${HOTEL_NAME}", "MYSQL_SECRET": "${SECRET_ARN}" }, "StartCommand": "npm start" } }, "SourceDirectory": "backend" }, "AutoDeploymentsEnabled": true, "AuthenticationConfiguration": { "ConnectionArn": "${APP_RUNNER_CONNECTION_ARN}" } }, "InstanceConfiguration": { "Cpu": "1 vCPU", "Memory": "3 GB", "InstanceRoleArn": "${INSTANCE_ROLE_ARN}" }, "NetworkConfiguration": { "EgressConfiguration": { "EgressType": "VPC", "VpcConnectorArn": "${VPC_BE_CONNECTOR_ARN}" }, "IngressConfiguration": { "IsPubliclyAccessible": false } } } EOF バックエンドサービスを作成します。 BACKEND_CREATE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ create-service \ --cli-input-json file://create_backend_service.json) バックエンドサービスの ServiceArn を保存します。 BACKEND_SERVICE_ARN=$(echo ${BACKEND_CREATE_SERVICE_RESPONSE} | jq -r '.Service.ServiceArn') VpcIngressConnection の作成 デフォルトでは、AWS App Runner サービスはインターネット経由でパブリックにアクセスできます。ただし、バックエンドサービスは公開されることを意図したものではありません。VPC 内でのみアクセスできるようにする必要があります。 バックエンドサービスへのネットワークアクセスを制限するために、AWS App Runner VPC Ingress Connection リソースを作成します。VPC Ingress Connection は VPC インターフェイスエンドポイントと AWS App Runner サービス間の接続を確立し、Amazon VPC 内からのみ App Runner サービスにアクセスできるようにします バックエンドサービスへのプライベートアクセスを許可する VpcIngressConnection を作成します。 INGRESS_CREATE_RESPONSE=$(aws apprunner --region ${MRO_AWS_REGION} \ create-vpc-ingress-connection \ --service-arn ${BACKEND_SERVICE_ARN} \ --vpc-ingress-connection-name "Private-Connection-To-Backend" \ --ingress-vpc-configuration VpcId=${VPC_ID},VpcEndpointId=${VPC_ENDPOINT}) VpcIngressConnectionArn と、バックエンドサービスURL の出力値を保存します。 INGRESS_ARN=$(echo ${INGRESS_CREATE_RESPONSE} | jq -r '.VpcIngressConnection.VpcIngressConnectionArn') BACKEND_URL="https://$(echo ${INGRESS_CREATE_RESPONSE} | jq -r '.VpcIngressConnection.DomainName')/" フロントエンドサービスの作成 いよいよフロントエンドサービスをデプロイします。以下のコマンドを実行して、サービスの構成を表すローカルファイル create_frontend_service.json を作成します。SourceDirectory は Git リポジトリ内の frontend ディレクトリ が指定されていることに注意してください。 cat > create_frontend_service.json << EOF { "ServiceName": "hotel-frontend", "SourceConfiguration": { "CodeRepository": { "RepositoryUrl": "${REPOSITORY_URL}", "SourceCodeVersion": { "Type": "BRANCH", "Value": "monorepo" }, "CodeConfiguration": { "ConfigurationSource": "API", "CodeConfigurationValues": { "BuildCommand": "npm install", "Port": "8080", "Runtime": "NODEJS_16", "RuntimeEnvironmentSecrets": { "HOTEL_NAME" : "${HOTEL_NAME}" }, "RuntimeEnvironmentVariables": { "BACKEND_URL": "${BACKEND_URL}" }, "StartCommand": "npm start" } }, "SourceDirectory": "frontend" }, "AutoDeploymentsEnabled": true, "AuthenticationConfiguration": { "ConnectionArn": "${APP_RUNNER_CONNECTION_ARN}" } }, "InstanceConfiguration": { "Cpu": "1 vCPU", "Memory": "3 GB", "InstanceRoleArn": "${INSTANCE_ROLE_ARN}" }, "NetworkConfiguration": { "EgressConfiguration": { "EgressType": "VPC", "VpcConnectorArn": "${VPC_FE_CONNECTOR_ARN}" }, "IngressConfiguration": { "IsPubliclyAccessible": true } } } EOF フロントエンドサービスを作成します。 FRONTEND_CREATE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ create-service \ --cli-input-json file://create_frontend_service.json) フロントエンドサービスの ServiceArn と、ServiceUrl の出力値を保存します。 FRONTEND_SERVICE_ARN=$(echo ${FRONTEND_CREATE_SERVICE_RESPONSE} | jq -r '.Service.ServiceArn') FRONTEND_URL="https://$(echo ${FRONTEND_CREATE_SERVICE_RESPONSE} | jq -r '.Service.ServiceUrl')" 作成が完了するまでの間、適宜ステータスを確認します。 aws apprunner --region $MRO_AWS_REGION \ describe-service \ --service-arn ${FRONTEND_SERVICE_ARN} サービスが利用可能になったら、FRONTEND_URL を介してアプリケーションにアクセスします。 echo ${FRONTEND_URL} 図2: モノレポのフロントエンドとバックエンドサービスで構築された実行中のホテルアプリケーション このアプリケーションは、Create ボタンを押下してデータベーススキーマを作成し、ホテルの部屋を追加して表示することができます。自動デプロイを有効にしている場合、GitHub リポジトリの frontend ディレクトリに変更がコミットされると、フロントエンドサービスへのデプロイが開始されますが、バックエンドサービスへのデプロイは行われません。本記事では、自動デプロイを有効にしてサービスを作成しています。ぜひ試してみてください！ 後片付け このウォークスルー中に作成された AWS リソースにはコストがかかります。ウォークスルーが終了したら、作成したインフラストラクチャを必ず削除してください。 まず、AWS App Runner VpcIngressConnection を削除します。 INGRESS_DELETE_RESPONSE=$(aws apprunner --region ${MRO_AWS_REGION} \ delete-vpc-ingress-connection \ --vpc-ingress-connection-arn ${INGRESS_ARN}) 次に、フロントエンド、バックエンドサービスを削除します。 FRONTEND_DELETE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ delete-service \ --service-arn ${FRONTEND_SERVICE_ARN}) BACKEND_DELETE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ delete-service \ --service-arn ${BACKEND_SERVICE_ARN}) 最後に、AWS CloudFormation スタックを削除します。 DELETE_STACK_RESPONSE=$(aws cloudformation --region $MRO_AWS_REGION \ delete-stack \ --stack-name ${MRO_STACK_NAME}) まとめ 本記事では、AWS App Runner を使用してモノレポ構成のリポジトリからサービスをデプロイする方法を紹介しました。App Runner のモノレポをサポートする機能を使用して、単一のソースコードリポジトリにフロントエンド層とバックエンド層の両方を持つサンプルアプリケーションをデプロイしました。AWS App Runner を使用して、本番環境のウェブアプリケーションでこの新機能を試すことをお勧めします。AWS App Runner の詳細については、 ドキュメント と 開発者ガイド をご覧ください。 翻訳はパートナーソリューションアーキテクトの髙橋達矢が担当しました。原文は こちら です。

この記事は Announcing Container Insights with Enhanced Observability for Amazon EKS on EC2 (記事公開日: 2023 年 11 月 7 日) を翻訳したものです。 Container Insights は、Amazon のフルマネージドなモニタリングおよびオブザーバビリティサービスであり、DevOps エンジニア、開発者、SRE、IT マネージャーに、コンテナ化されたアプリケーションとマイクロサービス環境に対するすぐに使える可視性を提供します。Container Insights を使用すると、Kubernetes クラスターの問題の監視、切り分け、診断を最小限の労力で実施できます。これは、クラスター、サービス、Pod の CPU、メモリ、ネットワーク、ディスク使用量などのインフラストラクチャテレメトリを、CloudWatch コンソールで簡単に視覚化できるメトリクスとログの形で提供します。また、お客様は CloudWatch アラームを追加して、プロアクティブなアクションのために異常を通知させることができます。本日、これをさらに一歩進める「Amazon EKS のオブザーバビリティが拡張された Container Insights」を発表できることを嬉しく思います。これは、API サーバーや etcd のような Kubernetes コントロールプレーンコンポーネントからの追加テレメトリを提供します。また、より迅速な問題の切り分けとトラブルシューティングのために、Pod ごと、コンテナごと、そして Kube State メトリクス (訳注: kube-state-merics に相当するメトリクスの一部) を含む、コンテナレベルまでの詳細な健全性とパフォーマンスメトリクスも含まれています。 Kube State メトリクスを使用すると、Kubernetes クラスターのコアコンポーネントと全体的な健全性を包括的に可視化できるため、ユーザーはリアルタイムの状態をモニタリングし、問題やボトルネックを迅速に検出できます。詳細なコンテナレベルのメトリクスを使用することで、さまざまなクラスターレイヤーにわたって視覚的にドリルダウンおよびドリルアップして、個々のコンテナのメモリリークなどの問題を簡単に特定し、解決までの平均時間を短縮できます。もう 1 つの重要な利点は、アラームがまだ設定されていない場合でも、リスクを特定しプロアクティブなアクションを取ることができることです。モニタリングされていないコンポーネントにアラームを設定したり、より多くのリソースを割り当てたりして、先手を打ってリスクを軽減し、エンドユーザーエクスペリエンスの低下を回避することができます。最終的には、拡張されたオブザーバビリティ機能により、お客様のアクションに依存することなく、早期のリスク特定とプロアクティブな緩和が容易になり、エンドユーザーエクスペリエンスに悪影響を及ぼす可能性のある問題の予防に役立ちます。 Amazon EKS の拡張されたオブザーバビリティを有効にするにはどうすればよいですか? Amazon CloudWatch Observability EKS アドオン を使用することで、Amazon EKS クラスターで拡張されたオブザーバビリティを得ることができます。Amazon EKS アドオンは、Amazon EKS クラスターで拡張されたオブザーバビリティを有効にする簡単な方法を提供します。このアドオンは CloudWatch エージェントと Fluent Bit をインストールし、インフラストラクチャとコンテナのログに関するインサイトを提供します。CloudWatch エージェントは、クラスターノードから CloudWatch に主要なインフラストラクチャメトリクスを送信します。これにより、CPU、ネットワーク、ディスク、およびその他の低レベルのノードメトリクスをモニタリングできます。Fluent Bit はコンテナログをクラスターから CloudWatch Logs に送信します。これにより、コンテナからのアプリケーションログとシステムログについてのインサイトが得られます。Amazon EKS アドオンを使用するには、クラスター内のワーカーノードが使用する IAM ロールに必要な IAM アクセス許可を設定します。 aws iam attach-role-policy --role-name my-worker-node-role \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy 次に、以下のようにアドオンをインストールします。「my-cluster-name」はクラスターの名前に置き換えてください。 aws eks create-addon --cluster-name my-cluster-name \ --addon-name amazon-cloudwatch-observability 以上です！これで EKS クラスターで Container Insights が有効になります。簡単なオンボーディングを可能にするために、EKS コンソールのクラスター情報ビューからアクセスできるアドオンタブからも同じアドオンを利用可能です。 これにより、CloudWatch コンソールで拡張されたメトリクスとログが表示されるようになります。EKS アドオンは、EKS クラスターにオブザーバビリティを導入する簡単な方法を提供します。いくつかのコマンドを実行するだけで、AWS 上の Kubernetes ワークロードの豊富なモニタリングとトラブルシューティングを有効にすることができます。完了すると、以下のように Amazon EKS の拡張されたオブザーバビリティ機能が有効になります。 kubeclt の出力 有効にすると、AWS マネジメントコンソールでは以下のような拡張された Container Insights のページが表示できます。クラスター、Kube State、コントロールプレーンメトリクスのハイレベルな概要が表示されます。Container Insights ダッシュボードには、クラスターのステータスとアラームが表示されます。CPU とメモリの事前定義されたしきい値を使用して、消費量が多いリソースを迅速に特定し、パフォーマンスへの影響を回避するためのプロアクティブなアクションを可能にします。 Container Insights ダッシュボード また、以下のようにクラスター、ノード、Pod、ワークロード、コンテナのレベル別にトップ 10 リストを表示するオプションもあります。これらは、リソースの消費量に基づいて、使用量が 100% に達する前に、アラームがなくてもリスクのあるコンポーネントを特定するために使用できる重要なチャートです。 トップ 10 リスト 以下に示すクラスターの概要セクションでは、重要性に基づいてクラスターを一覧表示します。アラーム状態にあるクラスターは最初に表示されます。次にリソース消費量の多いクラスターが表示されます。ユーザーはこのリスト表示を使用して、必要に応じてクラスターをフィルタリングすることもできます。 クラスターの概要 上記のビューによると、「prodcatalog」クラスターの使用率が 50% を超えているようです。クラスター名をクリックすると「パフォーマンスのモニタリング」ダッシュボードが開き、さらに詳細を確認できます。このモニタリングダッシュボードには、パフォーマンスを分析するための以下のようなさまざまなビューが用意されています。 クラスター全体のパフォーマンスダッシュボードビュー – クラスター全体のリソース使用率の概要を提供します。 ノードパフォーマンスビュー – 個々のノードレベルのメトリクスを可視化します。 Pod パフォーマンスビュー – CPU、メモリ、ネットワークなどの Pod レベルのメトリクスに焦点を当てます。 コンテナパフォーマンスビュー – 個々のコンテナの使用率メトリクスにドリルダウンします。 例えば、クラスター全体のパフォーマンスダッシュボードビューから始めて、ハイレベルな概要を把握することができます。さまざまなビューを使用することで、クラスターからノード、Pod、コンテナまで、系統的に絞り込んで根本原因を見つけることができます。 クラスターのパフォーマンスモニタリング 以下にチャートによると、ノードレベルの CPU とメモリの使用率が最大で 60% 近くまで急上昇しているようです。 ノードレベルの CPU とメモリの使用率 Container Insights ダッシュボードでは、より詳細なビューにドリルダウンして、さらなるインサイトを得ることができます。例えば、コンテナビューには、Pod の制限に対する CPU とメモリの使用率が表示されます。このビューから、fluent-bit コンテナの使用率が 77% でピークに達していることがわかりました。これらのさまざまなビューを詳しく調べることで、問題の根本原因をより簡単に特定できます。ダッシュボードは、テレメトリデータをさまざまな角度から分析するためのさまざまなビューを提供します。コンテナレベルの詳細にドリルダウンすると、そのコンテナの関連コンポーネントがフィルターに自動的に入力されます。これにより、ユーザーは、障害の発生したコンテナがどのノード上にあるのかを迅速に特定し、そのノード上の他の隣接するコンポーネントに対する潜在的なリスクを調査することができます。ネストされたビューと自動フィルタリングを活用することで、根本原因の分析が非常に効率的になります。これにより、ハイレベルのモニタリングから Pod やコンテナのメトリクスに至るまで、コンテナ化されたワークロードを可視化できます。この可視性は、トラブルシューティングとコンテナのパフォーマンスの最適化に役立ちます。 コンテナのパフォーマンスモニタリング ノードのパフォーマンスダッシュボードビューには、ノードごとに実行中の Pod、CPU とメモリの使用率などが含まれます。特定のインスタンスの詳細を知りたい場合は、フィルターを使用して同じことを実現できます。 ノードのパフォーマンスモニタリング Container Insights のサービスダッシュボードビューは、Kubernetes Service の Pod の CPU、メモリ、ネットワークパフォーマンスのメトリクスを提供します。これらのインサイトにより、リソースの利用をより最適化し、コンテナ化されたサービスの問題をトラブルシューティングできます。 サービスのパフォーマンスモニタリング 加えて、以下に示すように、Java、HAproxy などの一般的なワークロードのためのダッシュボードビューもあります。 一般的なワークロードのためのダッシュボードビュー また、Container Insights でシステムやアプリケーションのログを分析することもできます。メトリクスの横にある 3 つの点をクリックして「View logs」を選択するだけで、関連するログにアクセスできます。Logs Insights には、事前に入力されたクエリが付属しているため、簡単にログデータを分析し、インサイトを得ることができます。 便利なグラフを、Container Insights から直接ダッシュボードに追加することもできます。価値のあるデータを含むグラフを見つけたら、その横にある 3 つの点をクリックして「Add to dashboard」を選択すると、ダッシュボードに自動的に追加され、簡単にモニタリングできるようになります。これらのビューからアラームを作成するのも簡単です。例えば、「CPU Utilization Over Pod Limit」のアラームを作成するには、3 つの点をクリックして「View in metrics」を選択します。これにより、そのメトリックのしきい値に基づいてアラームを設定することができます。Container Insights のこれらのビルトインオプションを活用すると、コンテナ化されたアプリケーションの監視、分析、アラートの作成が簡単になります。 アラーム作成 – View in metrics これにより、以下のようなメトリクスビューが表示されます。ここで「ベル」のアイコンをクリックすることで、このメトリクスのアラームを作成できます。 アラーム作成 – メトリクスビュー これにより、「Create Alarm」ウィザードが開き、ステップバイステップガイドで値をカスタマイズしてアラームを作成できます。アラームを作成すると、アラームダッシュボードにもアラームが表示されます。 アラーム作成ウィザード すべての新しいメトリクスは、CloudWatch メトリクスセクションの「ContainerInsights」メトリクス名前空間の下に整理されます。 ContainerInsights メトリクス名前空間 「ContainerInsights」にアクセスすると、以下のようなさまざまなメトリクスが表示されるはずです。 拡張された Container Insights のさまざまなメトリクス AWS は Amazon EKS の Container Insights に新しい統一された料金モデルを導入し、メトリクス数とログの取り込みにかかるコストを単一の Observation (観測数) 単位の低コストな料金にバンドルします。この競争力のある価格設定により、クラスターを完全にモニタリングする追加メトリクスを収集するための追加コストなしで、デフォルトで拡張されたオブザーバビリティを提供することができます。 このブログ記事では、Amazon EKS のオブザーバビリティが拡張された Container Insights の一部として導入されたさまざまな機能を紹介しました。Container Insights は、AWS 上のコンテナワークロードのオブザーバビリティを得るための簡単な方法を提供し、組織がコンテナ化されたアプリケーションやマイクロサービスをモニタリング、トラブルシューティング、最適化するのに役立ちます。Amazon EKS のオブザーバビリティが拡張された Container Insights の提供開始により、AWS はテレメトリ収集を拡張し、包括的なステータスダッシュボードを提供することで、このサービスを強化しました。AWS 上でコンテナを実行している組織は、オブザーバビリティが拡張された Container Insights を有効にして、Amazon EKS 上の Kubernetes 環境の可視性の向上と迅速なトラブルシューティングを実現することができます。これにより、コンテナの健全性とパフォーマンスをモニタリングする際に推測に頼る必要がなくなります。 Amazon EKS の新しい改善されたオブザーバビリティの詳細については、 こちらのドキュメント をご参照ください。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

この投稿は、プリンシパル・ソリューション・アーキテクトのHeeki Park氏、シニア・アプリケーション・アーキテクトのSachin Doshi氏、シニア・ソリューション・アーキテクトのJason Enderle氏 の投稿を翻訳したものです。 Amazon API Gateway は、開発者が Virtual Private Cloud (VPC) 内からのみアクセス可能なプライベート REST API を作成することが可能です。プライベート API へのトラフィックはセキュアな接続を介して送信され、AWS ネットワーク内、特にお客様が管理している VPC 内に留まり、パブリックインターネットから保護されます。このアプローチは、送信されたトラフィックの機密性を確保することで、お客様の規制要件やセキュリティ要件に対応するために使用できます。このため、プライベート API Gateway エンドポイントは、マイクロサービスやデータ API で使用されるような内部 API の公開に適しています。 マイクロサービス・アーキテクチャでは、チームはしばしば個別の AWS アカウントでコンポーネントを構築・管理し、企業固有のカスタムドメイン名を使用してこれらのプライベート API エンドポイントにアクセスすることを好みます。カスタムドメイン名は、ホスト名と API へのパスのエイリアスとして機能します。これにより、クライアントは覚えやすい URL を使用して接続しやすくなり、また基礎となる API エンドポイントの URL が変更された場合でも同じ URL を維持できます。カスタムドメイン名は、企業内の機能に従って API の構成を改善することもできます。例えば、標準的な API Gateway の URL フォーマット: “https://api-id.execute-api.region.amazonaws.com/stage” を “https://api.private.example.com/myservice”に変換できます。 概要 このブログポストは、 プライベートエンドポイントのフロントエンド呼び出し と バックエンド統合パターン に関するドキュメントと、以前に公開された以下で紹介する2つのブログに基づいています。 最初のブログでは、VPC 対応の Lambda 関数と mTLS を使用したコンテナベースのアプリケーションを使用して、 API Gateway からプライベート API エンドポイントを利用する方法 を説明しています。2つ目のブログは、 AWS Fargate や Amazon EC2 を使用してデプロイされた マイクロサービス API へのプライベートバックエンドインテグレーションの実装 を解説するものです。このブログではこれらを拡張し、NGINX リバースプロキシを使ってプライベートエンドポイントにカスタムドメイン名を実装することで、API エンドポイントへのアクセスを簡素化できるようにします。 このソリューションでは NGINX を使用します。NGINX は高性能な仲介役として機能し、プライベートネットワーク内のトラフィックを効率的に転送することができます。構成マッピングファイルは、カスタムドメインとAWSアカウント間の対応するプライベートエンドポイントを関連付けます。この設定マッピングファイルはコードとして管理され、下流の環境と本番環境への統制されたデプロイに使用することができます。 次の図は、コンポーネント間の相互作用と API リクエストのパスを示しています。このユースケースでは、共有サービスアカウント（アカウントA）がカスタムドメイ ンのマッピングを一元管理し、プロバイダーアカウント（アカウントBとアカウントC）のプライベート API エンドポイントへの AWS PrivateLink 接続を作成する役割を担っています。 API へのリクエストは、VPC または VPC にルーティング可能な別のデバイス内から、プライベートカスタムドメインを使用して行われます。例えば、リクエストはドメイン https://api.private.example.com を利用するかもしれません。 Amazon Route 53 の プライベートホストゾーン のエイリアスレコードは、プライベートの Elastic Load Balancing (ELB) の FQDN に解決します。ELB は、ネットワークロードバランサー (NLB)またはアプリケーションロードバランサー (ALB) のいずれかに構成することができます。 ELB は AWS Certificate Manager (ACM) 証明書を使用して、対応するカスタムプライベートドメインのTLS (Transport Layer Security) を終了します。 ELB リスナーはリクエストを関連する ELB ターゲットグループ にリダイレクトし、そのターゲットグループはリクエストを AWS Fargate 上で動作する Amazon Elastic Container Service タスクに転送します。 Fargate サービスは、NGINX ベースのコンテナをホストし、1つ以上のプロバイダーアカウントのプライベート API エンドポイントへのリバースプロキシとして動作します。Fargate サービスは、CPU 使用率を自動的に追跡するメトリックを使用してスケールするように構成されています。 Fargate タスクは、PrivateLink VPC エンドポイントを介して、プロバイダアカウント B またはアカウント C の適切なプライベートエンドポイントにトラフィックを転送します。 API Gateway の リソースポリシー は、API を要求するために使用される特定の VPC エンドポイント、HTTP メソッド、およびソースドメインに基づいて、プライベートエンドポイントへのアクセスを制限します。 このソリューションでは、認証ヘッダ、Content-type ヘッダ、カスタムヘッダなど、上流の呼び出しのヘッダで見つかった追加情報を、プロバイダアカウント（アカウント B およびアカウント C）のプライベートエンドポイントに変更せずに渡します。 前提条件 カスタムドメイン名を使用するには、TLS 証明書と DNS エイリアスの2つのコンポーネントが必要です。この例では、TLS 証明書の管理に ACM を使用し、DNS エイリアスの作成に Route 53 を使用しています。 ACM は、TLS 証明書を統合するためのさまざまなオプションを提供しています： 既存の TLS 証明書を ACM に インポート します。 ACM で 電子メールベース の検証を使用して TLS 証明書を要求します。 DNS ベース の検証を使用して ACM に TLS 証明書を要求します。 プライベート CA を使用して ACM に TLS 証明書を要求します。 次の図は、各オプションに関連する利点と欠点を示しています。 このソリューションでは、DNS ベースの検証 (オプション3) を使用して ACM に TLS 証明書を 要求します。ルートドメイン( example.com など)が登録された パブリックホストゾーン が、 ターゲットアカウントに既にデプロイされているものと仮定します。その後、このソリューションは ACM を使用して、デプロイ時に設定マッピングファイルに指定された ドメイン名の所有権 を検証します。 デプロイされたパブリックホストゾーンでは、 DNS 検証 を使用してプライベートの子ドメイン（api.private.example.comなど）をデプロイできるため、ソリューションのデプロイ時に証明書の検証を自動化するIaC（Infrastructure as Code）デプロイが可能になります。さらに、DNS ベースの検証では、ACM 証明書の有効期限が切れる前に自動的に更新されます。 このソリューションでは、特定の VPC エンドポイント、すなわち共有サービスアカウント（アカウント A）内の execute-api、logs、ecr.dkr、ecr.api、 Amazon S3 ゲートウェイが必要です。execute-api の VPC エンドポイントでプライベート DNS を有効にすることはオプションであり、ソリューションの要件ではありません。これにより、VPC 内のアプリケーションは NGINX リバースプロキシを通じてプライベート API エンドポイントに到達できますが、パブリック API ゲートウェイのエンドポイントも解決できます。 サンプルのデプロイ このパターンを自分のアカウントにデプロイするには、サンプルの AWS Cloud Development Kit (CDK) または GitHub で利用可能な Terraform コードを使うことができます。 このソリューションでは、YAML ベースの設定マッピングファイルを使用して、カスタムドメインとプライベート API エンドポイント間のマッピングを追加、更新、または削除します。デプロイ中に、自動化されたInfrastructure as Code（IaC）スクリプトは提供された YAML ファイルを解析し、以下を実行します： NGINX 設定ファイルを作成します。 NGINX 設定ファイルを標準 NGINX コンテナイメージに適用します。 マッピングファイルを解析し、アカウント A に必要な Route 53 プライベートホストゾーンを作成します。 アカウント A にワイルドカードベースの SSL 証明書（*.example.comなど）を作成します。ACM は、それぞれのパブリックホストゾーン（example.comなど）を使用してこれらの証明書を検証し、ELB リスナーにアタッチします。デフォルトでは、ELB リスナーは最大 25 の SSL 証明書をサポートします。ワイルドカードは、無制限の数のサブドメインを保護するために使用され、複数のサブドメインの管理と拡張を容易にします。 マッピングファイルのフィールドの説明 Property Required Example Values Description CUSTOM_DOMAIN_URL TRUE api.private.example.com プライベート API に必要なカスタム URL PRIVATE_API_URL TRUE https://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com/dev/path1/path2 対象となるプライベート・エンドポイントの実行 URL VERBS FALSE [“GET”,” POST”, “PUT”, “PATCH”, “DELETE”, “HEAD”, “OPTIONS”] このプロパティは、API Gateway リソースポリシーを作成するために使用されます。1つまたは複数のメソッドをカンマ区切りのリストとして指定できます。このプロパティを指定しない場合は、すべての動詞が許可されます。 プライベートエンドポイントに API Gateway リソースポリシーを使用する 自分の VPC または別のアカウントの VPC からプライベートエンドポイントへのアクセスを許可するには、 リソースポリシー を実装する必要があります。リソースポリシーは、VPC エンドポイント、API パス、API メソッドなどの特定の条件に基づいてアクセスを制限するために使用できます。この機能を有効にするには、以下の手順に従います： IaC（Infrastructure as Code）の導入を完了します。 プロバイダーアカウント（ アカウント B やアカウント C など ）に API Gateway リソースポリシーを作成または更新します。このポリシーには、共有サービスアカウント（ アカウント A ）の VPC エンドポイント ID を含めます。 API をデプロイして、プロバイダーアカウント（ アカウント B やアカウント C など ）に変更を適用します。 API Gateway のリソースポリシーをコードで更新するには、 GitHub リポジトリ のドキュメントとコード例を参照してください。 マッピングファイルのアップデートのデプロイ カスタムドメインとプライベートエンドポイント間のマッピングを追加、更新、または削除するには、マッピングファイルを更新してから、以前と同じ手順でデプロイを再実行します。 既存の Infrastructure as Code パイプラインを使用してマッピングファイルの更新をデプロイすることで、人的ミスのリスクを低減し、トレーサビリティを追加し、構成のドリフトを防止し、デプロイプロセスを既存の DevOps プロセスとガバナンスプロセスに従わせることができます。 例えば、設定マッピングファイルを別のソース管理リポジトリに保存し、各変更をそのリポジトリにコミットすることができます。各変更がデプロイメントプロセスのトリガーとなり、デプロイメントプロセスは設定変更をチェックし、適切なデプロイメントを実施します。必要であれば、変更管理プロセスが確実に実施されるように、手動チェックまたはチケットプロセスのいずれかを強制するゲートを導入できます。 ソリューションのコストを理解する このソリューションで言及されているサービスのほとんどは、リクエストの数によって決定される使用量に応じて課金されます。 ただし、時間単位または月単位の費用が発生するサービスもいくつかあります。これには、 Route 53 ホストゾーンの月額料金、 VPC エンドポイント の時間課金、 Elastic Load Balancing 、 Fargate で NGINX リバースプロキシを実行する時間課金などがあります。特定のワークロードに基づいてこれらのオプションのコストを見積もるには、 AWS Pricing Calculator を利用することができます。ここでは、このソリューションで実装されたアーキテクチャに関連するおおよその コストの例 を示します。 結論 このブログポストでは、カスタムドメイン名のリバースプロキシを使って、AWS アカウント間や VPC ネットワーク内で API Gateway を安全にプライベートエンドポイントを利用できるソリューションを紹介しました。このソリューションは、API Gateway とカスタムドメイン名を持つプライベートエンドポイント間のマッピングを管理する簡素化されたアプローチを提供し、シームレスな接続性とセキュリティを確保します。 サーバーレスの学習リソースについては、 Serverless Land をご覧ください。 この投稿は、Heeki Park氏、Sachin Doshi氏、Jason Enderle氏 によって書かれた Implementing custom domain names for Amazon API Gateway private endpoints using a reverse proxy の日本語訳です。この記事はソリューションアーキテクトの松本侑也が翻訳しました。

こんにちは、アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクトの中川です。 2023 年 10 月 26 日に AWS for Games Live を開催いたしました。 AWS for Games Live とは？ AWS for Games Live は、AWS 公式ウェブマガジン builders.flash の記事と連動したイベントで、AWS for Games の 3 つの柱「Build」「Run」「Grow」の柱のうち 1 つにフォーカスを当てて、その内容を掘り下げるものです。参加者の方々には、ゲーム業界のトレンドを知ったりネットワーキングを楽しんだりする時間として活用していただいています。今回は、「大阪で学ぶゲーム開発最新動向と生成系 AI」と題して、4 つのセッションを設け、AWS のゲーム業界の最新事例、先日リリースした「Amazon Bedrock」についてのご紹介、AWS をご利用のお客様による事例登壇をいただきました。また、イベントの最後には懇親会も開催され、ゲーム開発者の方々とのネットワーキングもお楽しみいただきました。 AWS for Games と最新ゲーム事例のご紹介 ver. Osaka はじめに、ソリューションアーキテクト 鷲見 啓志 から、現在までの 4 年間の AWS の変遷と、AWS for Games、大阪リージョンについてご紹介しました。資料は こちらのリンク からご覧いただけます。 本セッションではまず、大阪で前回イベントが開催された４年前から現在までを振り返り、AWS と大阪の変遷を紹介しました。AWS の主要なアップデートを振り返ると、2020 年には、Amazon EC2 Mac インスタンスが発表され、クラウド上でモバイルゲームのビルドができるようになりました。2021 年には、AWS App Runner, Amazon ECS Anywhere が GA するなど、コンテナ系サービスのアップデートが多くありました。2022 年には、Amazon Aurora Serverless v2 や Amazon Redshift Serverless が GA するなどサーバレスサービスの拡充が多く行われました。2023 年には、Amazon Bedrock という生成系 AI をアプリに簡単に組み込めるサービスが GA しました。 次に、2022 年に生まれた AWS for Games について紹介しました。AWS for Games とは AWS 及び AWS パートナーによるゲーム業界向けの開発( BUILD )、運営( RUN )、成長( GROW )のそれぞれのフェーズをサポートする 6 つのエリアに特化したソリューションとサービスの集まりです。 BUILD では、ゲーム開発者向け仮想ワークステーションによりリモートワークやコラボレーションを支援でき、Perforce Helix Core on AWSで高い可用性/拡張性を、Incredibuild on AWS でビルドの並列化/高速化/コスト最適化を実現できます（お客様 BUILD 事例：ゲームフリーク様、カプコン様、ガンホー・オンライン・エンターテイメント様）。RUN では、高速で安価なネットワークを提供する AWS のグローバルインフラストラクチャを活用でき、AWS Global Accelerator によりネットワークの可用性とパフォーマンスを向上できます。また、ゲームバックエンドシステムの各コンポーネントには、ユースケースに応じて適したコンピューティング環境・データベースを選択でき、例えばマネージドなゲームサーバーの構築には Amazon GameLift、DDoS/Bot 攻撃の緩和には AWS Shield / AWS WAFのようなセキュリティサービスも活用できます（お客様 RUN 事例：VALORANT、ELDEN RING、Dead by Daylight）。GROW では、ゲームの収益拡大に重要なゲームデータ分析パイプラインの構築支援や、チート予測やオペレーション効率化のような AI/ML 活用へ向けた支援が可能です（お客様 GROW 事例：ソーシャルゲームデータ分析基盤、モンスターハンターライダーズにおけるユーザー離脱予測）。 最後に、2021 年に日本で 2 つ目のリージョンとして生まれた、大阪リージョンについて紹介しました。大阪リージョンは、3 つの AZ をもち、他リージョンと同様に単体利用可能な AWS リージョンです。お客様の声を反映し、サービスおよび機能拡充を続けており、多くのパターン様々な業種業態のお客様にご利用頂いています。ぜひ、大阪リージョンの活用もご検討ください。 Generative AI はゲーム開発 運用の夢をみるか？ 次に、同じくソリューションアーキテクトの中村 一樹から、「ゲーム開発運用は生成系 AI の恩恵を受けられるか？」というテーマで生成系 AI でできること、AWS サービスとの関わり、活用例についてご紹介しました。 生成系 AI は、新しいコンテンツやアイデアを想像する AI であり、一般に基盤モデル（FM : ファウンデーションモデル）と呼ばれる膨大なデータに基づいて事前にトレーニングされた大規模モデルを搭載しています。特定のタスクを実行する従来の機械学習モデルとは異なり、学習なしで様々な異なるタスクを高い精度で実行できる適応性が基盤モデルの特長です。 生成系 AI は、ビデオ、オーディオ、テキスト、画像などを生成できます。Txt2Txt （テキストからテキストを生成する）モデルは、シナリオなどの文章作成、文章チェックなどの Quality Assuarance、チーム内・社内ナレッジボットなどの開発運用支援に活用できます。Txt2Img（テキストから画像を生成する）モデルや Img2Img（画像から画像を生成する）モデルは、カラーバリエーション検証、ラフ画やテキストからの画像生成などのコミュニケーションサポート等で活用できます。Img2Txt（画像からテキストを生成する）モデルは、表示不具合検知などの Quality Assurance、不適切な User Generated Content の検知などのコンテンツモデレーションで活用できます。 AWS での生成系 AI サービスとしては、AI によるコード生成やセキュリティスキャンができる Amazon CodeWhisperer や、生成系 AI アプリケーションを簡単に構築できる Amazon Bedrock などがあり、その活用例としては、RAG : Retrieval Augmented Generation（検索拡張生成）を使用した社内ナレッジ検索ツールや、Img2Txt を使用した多言語対応による文字のはみ出し・装備の組み合わせにより見た目がおかしくなるチェック、といった画像確認チェックなどが考えられます。 著作権など色々考えないといけないことはありますが、生成系AIを使える範囲で正しく使うと、ゲーム開発運用においても多くの恩恵を受けられます。   社内システムから大ヒットタイトルまで – Happy Elements の鉄板 AWS 設計 続いて、Happy Elements 株式会社 インフラグループ グループリーダーの長谷川 一輝様から、少人数でも高い安定性を維持できるインフラの標準構成についてご紹介をいただきました。資料は こちらのリンク からご覧いただけます。 まず技術構成として、ゲームエンジンは Unity、アプリケーションフレームワークは Ruby on Rails、リアルタイム通信時はnode.js, gRPC, magiconion、監視ツールは Datadog, New Relic、IaC ツールには Terraform を利用しています。 基本的なインフラの設計方針としては、アプリケーションは Amazon ECS、ワーカーは Amazon EC2、データベースは Amazon Aurora、静的コンテンツ配信は Amazon CloudFront・Amazon S3、ロードバランサーは Application Load Balancer、ログは Amazon CloudWatch Logs から Amazon Kinesis Data Firehose を通して Amazon S3 へ配信する構成です。特別なことはせず、シンプルな構成を意識しています。 アプリケーションの ECS は、Kubernetes ほどの学習コストがなく、バージョンアップの負担も軽減されるため、WebAPI のようなシンプル運用に非常にマッチします。ワーカーの EC2 は、リザーブドインスタンスやスポットインスタンスを活用して大規模利用時のコストメリットを活かす為 Fargate ではなく EC2 を採用していますが、運用コストもそこまで大きくありません。静的アセット配信は必ず CloudFront + S3 を使い高スループットのメリットを活かしつつ、API 通信を含む全てのリクエストを CloudFront に通すことでボリュームディスカウントを効かせています。 Http ロードバランサーには ALB を活用することで他AWS サービスとの連携が容易となり運用負荷が減ります。ログ配信は運用負荷の低い ECS awslogs ドライバを利用して CloudWatch Logs に配信し、そこから Kinesis Data Firehose を使い S3 のデータレイクに集約することでログ処理に繋げています。中でも AWS Enterprise Support が一番オススメしたいサービスで、TAM による助言や IEM など多岐に渡るサポートを受けられるため、少人数で AWS 利用する時の非常に心強い味方だと述べました。 サイバーコネクトツーのゲーム開発効率化と AI のこれから 最後に、株式会社サイバーコネクトツー 代表取締役の松山 洋様から、サイバーコネクトツーの AWS 利用と AI 研究とその活用状況についてご紹介をいただきました。 まずはじめに AWS の利用状況について 2 つご紹介頂きました。1 つ目に オンラインストレージとして Amazon S3 を使用しています。サイバーコネクトツーでは、福岡・東京・大阪の３拠点で連携しながら同じプロジェクトを担当します。その為、ピーク時には各拠点同士で 200 人以上が情報共有をする必要がありますが、そのデータ連携基盤として Amazon S3 を利用しています。2 つ目に、Incredibuild Cloud のクラウドプラットフォームとして AWS を使用しています。これによりビルドの速度が向上し、エンジニアの作業効率の向上に繋がりました。「これを使う前にはもう戻れない」とのエンジニアの声もあったそうです。また、AWS を選んで良かったこととして、オンライン会議等で丁寧にフォローをしてくれる点と、AWS のエンジニアが直接サポートに入ってくれる点を挙げました。分からないことをとにかく手厚くサポートしてくれる、気配り、真心、おもてなしが素晴らしいと述べ、開発効率化について今後も AWS からの最適な提案を期待していると述べました。 次にサイバーコネクトツーの AI 研究とその活用状況についてご紹介頂きました。サイバーコネクトツーでは AI 研究会を発足し、AI の積極運用を目指し活用方法や可能性を模索しています。実際に、漫画作品内の架空ビジュアルの作成や、AI によるラフの作成、ラフからのレタッチ、静止画から短尺の動画の自動生成などで活用を始めています。今後 AI でゲーム開発がどう変わるか？という問いに対しては、現状開発が大きく変わることはないとの見解を示しましたが、開発の初動でスピードは向上し、将来的なゲーム開発には不可欠な技術となり得ると述べました。ただし、人材として AI を活用するスキルが求められること、AI 導入の為の初期設備投資が必要となる点にも触れました。 懇親会 セッション終了後には、懇親会が開催されました。多くの参加者が、会社の壁を超えてセッションの内容についてディスカッションしたり、ネットワーキングを楽しまれたご様子でした。 最後に 前回の Game Tech Night の大阪開催から 4 年を経て、コンピュート、コンテナ、サーバレス、生成系 AI と様々な技術領域でアップデートを迎えた AWS ですが、その多くがゲームの開発運用にも役立っています。実際、Happy Elements 様、サイバーコネクトツー様をはじめ多くのゲーム業界のお客様が AWS を活用することでシステムを改善されました。生成系 AI の活用については、人材、設備投資、著作権など意識すべき点はありますが、現時点でもゲーム開発運用において多くの恩恵をもたらしてくれそうであり、将来的なゲーム開発には不可欠な要素となるでしょう。ゲーム開発運用の効率化・モダン化をお考えのお客様、生成系 AI の導入をお考えのお客様は、ぜひ一度お気軽に AWS までご相談下さい。

この記事は Persistent storage for Kubernetes (記事公開日: 2022 年 11 月 22 日) を翻訳したものです。 ステートフルアプリケーションを適切に実行するためには、データが永続化され取得できることが必要です。Kubernetes を使用してステートフルアプリケーションを実行する場合、コンテナ、Pod、ノードのクラッシュや終了に関係なく、状態を永続化する必要があります。これには、永続ストレージ、すなわち、コンテナ、Pod、またはノードの生存期間を超えて存続するストレージが必要です。 このブログ記事では、Kubernetes 環境における永続ストレージのコンセプトと、Kubernetes の世界におけるストレージオプションについて取り上げます。そして、ホスト、Pod、コンテナレベルで障害や終了が発生した場合のデータ損失の懸念を軽減する、Kubernetes 上でのステートフルアプリケーションの設計と構築について説明します。 Kubernetes の永続ストレージは、特にストレージの初心者や、Kubernetes を使い始めようとしている人にとっては複雑なトピックです。そのため、私たちはこの 2 つのブログ記事シリーズを作成しました。最初に概念と用語について説明し、次に実用的なユースケースに踏み込みます。 Part 1 [このブログ記事]: この最初のパートでは、Kubernetes の永続ストレージの概念を説明し、 Amazon Elastic Kubernetes Service (Amazon EKS) と永続ストレージとして Amazon Elastic File System (Amazon EFS) を使用して、基本的なワークロードにこれらの概念を適用する方法について解説します。 Part 2 : Amazon EKS 上で Kubeflow を使用して実行される、永続ストレージを必要とする機械学習ワークロードの例を詳しく掘り下げます。 Kubernetes におけるデータの永続化 ステートフルアプリケーションを実行し、永続ストレージがない場合、データは Pod やコンテナのライフサイクルにに関連付けられます。Pod がクラッシュしたり終了したりすると、データは失われます。 このデータ損失を防ぎ、Kubernetes 上でステートフルなアプリケーションを実行するには、以下の 3 つのシンプルな要件に従うストレージが必要です。 ストレージは、Pod のライフサイクルに依存しないようにする必要があります。 ストレージは、Kubernetes クラスター内のすべての Pod とノードから利用可能である必要があります。 ストレージは、クラッシュやアプリケーションの障害に関係なく、高い可用性を持つ必要があります。 Kubernetes ボリューム Kubernetes にはいくつかの種類のストレージオプションが用意されていますが、そのすべてが永続的であるわけではありません。 エフェメラルストレージ コンテナは一時的なファイルシステムを使用してファイルの読み取りと書き込みを行うことができます。しかし、このエフェメラルストレージはストレージに必要な 3 つの要件を満たしていません。コンテナがクラッシュした場合、一時的なファイルシステムは失われ、コンテナは再びまっさらな状態から開始されます。また、複数のコンテナで一時的なファイルシステムを共有することはできません。 エフェメラルボリューム Kubernetes のエフェメラルボリュームは、一時的なファイルシステムが直面する両方の課題を解決します。エフェメラルボリュームの生存期間は Pod に連動します。これにより、コンテナの安全な再起動と、Pod 内のコンテナ間でのデータの共有が可能になります。しかし、Pod が削除されるとすぐにエフェメラルボリュームも削除されるため、依然として 3 つの要件を満たしていません。 一時的なファイルシステムはコンテナのライフサイクルに連動し、エフェメラルボリュームは Pod のライフサイクルに連動します。 ストレージから Pod を切り離す: 永続ボリューム Kubernetes は永続ボリューム (Persistent Volume) もサポートしています。Persistent Volume を使用すると、アプリケーション、コンテナ、Pod、ノード、あるいはクラスター自体のライフサイクルに関係なく、データが永続化されます。Persistent Volume は、先に説明した 3 つの要件を満たします。 Persistent Volume (PV) オブジェクトは、アプリケーションデータを永続化するために使用されるストレージボリュームを表します。PV には、Kubernetes Pod のライフサイクルとは異なる、独自のライフサイクルがあります。 PV は基本的に 2 つの異なるもので構成されいます。 PersistentVolume と呼ばれるバックエンドストレージ技術 ボリュームのマウント方法を Kubernetes に指示するアクセスモード バックエンドストレージ技術 PV は抽象的なコンポーネントであり、実際の物理的なストレージはどこかから提供される必要があります。以下はいくつかの例です。 csi : Container Storage Interface (CSI) → (例: Amazon EFS 、 Amazon EBS 、 Amazon FSx など) iscsi : iSCSI (SCSI over IP) ストレージ local : ノードにマウントされたローカルストレージデバイス nfs : Network File System (NFS) ストレージ Kubernetes は汎用性が高く、 さまざまなタイプの PV をサポート しています。Kubernetes は基盤となるストレージの内部構造を気にしません。実際のストレージへのインターフェースとして PV コンポーネントを提供するだけです。 PV には 3 つの大きなメリットがあります。 PV は Pod のライフサイクルにバインドされていません。PV オブジェクトにアタッチされた Pod を削除しても、PV は存続します。 Pod がクラッシュした場合にも前述の記述は有効です。すなわち、PV オブジェクトは Pod がクラッシュしても PV は存続し、クラスターから削除されません。 PV はクラスター全体で利用可能です。クラスター内の任意のノードで動作している任意の Pod にアタッチできます。 さまざまなバックエンドストレージ技術には、それぞれ独自のパフォーマンス特性とトレードオフがあります。このため、本番環境の Kubernetes では、アプリケーションに応じてさまざなタイプの PV が使用されます。 アクセスモード アクセスモードは PV 作成時に設定され、ボリュームのマウント方法を Kubernetes に伝えます。Persistent Volume は以下の 3 つのアクセスモードをサポートします。 ReadWriteOnce : ボリュームは、同時に 1 つのノードのみによる読み取り/書き込みが可能です。 ReadOnlyMany : ボリュームは、多くのノードによる読み取り専用モードを同時に許可します。 ReadWriteMany : ボリュームは、同時に複数のノードによる読み取り/書き込みが可能です。 訳注: 他に ReadWriteOncePod というアクセスモードがあり、Kubernetes 1.27 からベータ版となっています。 すべての PersistentVolume タイプが すべてのアクセスモード をサポートしているわけではありません。 永続ボリューム要求 (Persistent Volume Claim) PersistentVolume (PV) は、実際のストレージボリュームを表します。Kubernetes には、PV を Pod にアタッチするために必要な追加の抽象化レイヤーである PersistentVolumeClaim (PVC) があります。 PV は実際のストレージボリュームを表し、PVC は実際のストレージを取得するために Pod が行うストレージのリクエストを表します。 PV と PVC の分離は、Kubernetes 環境においては 2 つの異なる役割が存在するという考えに関連しています。 Kubernetes 管理者 : クラスターの保守および運用し、永続ストレージなどの計算リソースの追加を行います。 Kubernetes アプリケーション開発者 : アプリケーションの開発とデプロイを行います。 簡単に言えば、アプリケーション開発者は管理者が提供する計算リソースを消費します。Kubernetes は、PV オブジェクトはクラスター管理者のスコープに属し、PVC オブジェクトはアプリケーション開発者のスコープに属するという考えに基づいて構築されています。 基本的に、Pod は PV オブジェクトを直接マウントできません。明示的に要求する必要があります。そしてその要求動作は、PVC オブジェクトを作成して Pod にアタッチすることで実現します。これが、この抽象化レイヤーが存在する唯一の理由です。PVC と PV は 1 対 1 の対応関係にあります (PV は 1 つの PVC にしか関連付けることができません) 。 このブログ記事では、Pod に永続ストレージをアタッチするこのプロセスをデモします。しかし、その前に、CSI ドライバーに関する背景を説明する必要があります。 Container Storage Interface (CSI) ドライバー Container Storage Interface (CSI) は、さまざまなストレージソリューションを Kubernetes において使いやすくするために設計された抽象化です。さまざまなストレージベンダーは、CSI 標準を実装する独自のドライバーを開発し、ストレージソリューションが (基盤となるストレージソリューションの内部構造に関係なく) Kubernetes と連携できるするようにすることができます。AWS には、 Amazon EBS 、 Amazon EFS 、 Amazon FSx for Lustre などのための CSI プラグインがあります。 静的プロビジョニング 「永続ボリューム要求 (Persistent Volume Claim)」セクションで説明した内容では、まず管理者が 1 つまたは複数の PV を作成し、次にアプリケーション開発者が PVC を作成します。これは静的プロビジョニングと呼ばれます。Kubernetes で PV と PVC を手動で作成する必要があるため、静的です。規模が大きくなると、特に数百の PV や PVC を管理する場合、この方法では管理が困難になる可能性があります。 例えば、Amazon EFS ファイルシステムを作成して PV オブジェクトとしてマウントしたいとします。静的プロビジョニングを使用する場合、次のようにする必要があります。 Kubernetes 管理者のタスク Amazon EFS ファイルシステムを作成します。 ファイルシステム ID をコピーして PV の YAML 定義ファイルに貼り付けます。 YAML ファイルを使用して PV を作成します。 Kubernetes アプリケーション開発者のタスク この PV を要求する PVC を作成します。 Pod の YAML 定義ファイルにの Pod オブジェクトに PVC をマウントします。 この方法は機能しますが、規模が大きくなると時間がかかります。 動的プロビジョニング 動的プロビジョニングでは、PV オブジェクトを作成する必要はありません。その代わり、PVC を作成すると自動的に PV が作成されます。Kubernetes はストレージクラス (Storage Class) と呼ばれる別のオブジェクトを使ってこれを行います。 Storage Class は、コンテナアプリケーションに使用されるバックエンドの永続ストレージ (Amazon EFS ファイルストレージ、Amazon EBS ブロックストレージなど) のクラスを定義する抽象化です。 Storage Class には基本的に次の 2 つのものが含まれます。 Name : これは、Storage Class オブジェクトを一意に識別する名前です。 Provisioner : 基盤となるストレージ技術を定義します。例えば、Amazon EFS の場合は efs.csi.aws.com 、Amazon EBS の場合は ebs.csi.aws.com となります。 Kubernetes が非常に多くの異なるストレージ技術を扱うことができるのは、Storage Class オブジェクトのおかげです。Pod の観点からは、それが EFS ファイルシステムであろうと、EBS ボリュームであろうと、NFS ドライブであろうと、その他何であろうと、Pod には PVC オブジェクトしか見えません。実際のストレージ技術を扱うすべての基盤となるロジックは、Storage Class オブジェクトが使用する Provisioner によって実装されます。 Amazon EKS と Amazon EFS を使用した静的プロビジョニングと動的プロビジョニングのデモ では、学んだことをすべて実践してみましょう。 GitHub のこのページ を参考に、このデモセクションのための作業環境をセットアップしてください。 訳注: 日本語翻訳にあたり、EKS 1.28 においてデモが動作することを検証しています。バージョンを適宜置き換えて実施してください。 次のコードスニペットでは、5 つのノードを持つ Amazon EKS クラスターを確認できます。 $ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-12-218.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-24-116.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-46-22.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-63-240.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-7-195.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 Kubernetes クラスターの永続ストレージとして Amazon EFS ファイルシステムを使用します。そのためには、まず Amazon EFS CSI ドライバーをインストールする必要があります。 訳注: こちらのドキュメント に従い、EFS CSI ドライバーをインストールしてください。 2023 年 8 月のアップデート で、Amazon EFS CSI ドライバーは EKS アドオンとしてインストールすることができるようになりました。 Amazon EFS を使用した静的プロビジョニング 訳注: マネジメントコンソールから EFS ファイルシステムを作成する場合、事前にセキュリティグループを作成し、EFS ファイルシステムのマウントターゲットと関連付ける必要があります。eksctl によって作成された VPC ( eksctl-efsworkshop-eksctl-cluster/VPC ) に、セキュリティグループを作成し、クラスターセキュリティグループ ( eks-cluster-sg-efsworkshop-eksctl-XXXXXXXX ) から TCP 2049 ポートへのアクセスを許可するインバウンドルールを作成してください。 まず AWS マネジメントコンソールで Amazon EFS ファイルシステム ( myEFS1 ) を作成しましょう。次のステップで PV を作成する際に必要になるので、 FileSystemId を控えておきましょう。 すべてをデフォルトのままにして、ファイルシステムを作成します。 訳注: 「カスタマイズ」を選択し、VPC は eksctl-efsworkshop-eksctl-cluster/VPC を選択し、マウントターゲットのセキュリティグループは事前に作成したセキュリティグループを選択してください。 次に、PV のマニフェストファイルを作成し、新しく作成したファイルシステムの FileSystemId を指定します。 #pv.yaml --- apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce storageClassName: "" persistentVolumeReclaimPolicy: Retain csi: driver: efs.csi.aws.com volumeHandle: fs-073d77123471b2917 この pv.yaml ファイルにあるように、 spec.capacity.storage のサイズを 5 ギビバイト (GiB) としました。これは、PV を作成する際に必須であり、Kubernetes を満足させるための単なるプレースホルダー値です。バックエンドには Amazon EFS ファイルシステムを使用しています。これは完全に伸縮性があり、スケーラブルなファイルシステムです。使用量に応じて自動的にスケールアップまたはスケールダウンされるため、容量を心配する必要はありません。 $ kubectl apply -f pv.yaml persistentvolume/efs-pv created $ kubectl get pv efs-pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE efs-pv 5Gi RWO Retain Available 45s PV の ステータスは Available ですが、まだどの Persistent Volume Claim (PVC) ともバインドされていません。次に、PVC を作成します。 #pvc.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: efs-claim spec: accessModes: - ReadWriteOnce storageClassName: "" resources: requests: storage: 5Gi $ kubectl apply -f pvc.yaml persistentvolumeclaim/efs-claim created では、PV と PVC のステータスを確認してみましょう。 $ kubectl get pv efs-pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE efs-pv 5Gi RWO Retain Bound default/efs-claim 15m $ kubectl get pvc efs-claim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE efs-claim Bound efs-pv 5Gi RWO 103s PV のステータスが Available から Bound に変わりました。これは、Kubernetes が PVC にマッチするボリュームを見つけることができ、ボリュームがバインドされたことを意味します。 ここで別の PVC を作成しようとすると、PV がもう残っていないため失敗します (PV は 1 つの PVC にのみバインドできます) 。そこで、動的プロビジョニングが役に立ちます。動的プロビジョニングに移る前に、この PVC を使ってサンプルアプリケーション ( efs-app ) を作成し、データがどのように永続化されるかを確認しましょう。 #pod.yaml --- apiVersion: v1 kind: Pod metadata: name: efs-app spec: containers: - name: app image: centos command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 2; done"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: efs-claim $ kubectl apply -f pod.yaml pod/efs-app created kubectl を使用して、データが Amazon EFS ファイルシステムに書き込まれたことが確認できます。 $ kubectl exec -ti efs-app -- tail -f /data/out.txt Mon Mar 21 23:33:05 UTC 2022 Mon Mar 21 23:33:07 UTC 2022 Mon Mar 21 23:33:09 UTC 2022 以下は静的プロビジョニングのまとめです。 Amazon EFS を使用した動的プロビジョニング Amazon EFS CSI ドライバーは、動的プロビジョニングと静的プロビジョニングの両方をサポートしています。EFS の場合、動的プロビジョニングでは各 PV の アクセスポイント が作成されます。つまり、手動で Amazon EFS ファイルシステムを作成し、それを Storage Class パラメータの入力として提供する必要があります。 デフォルトでは、動的プロビジョニングによって作成された各アクセスポイントは、EFS 上の異なるディレクトリにファイルを書き込み、各アクセスポイントは異なる POSIX uid/gid を使用して EFS にファイルを書き込みます。これにより、複数のアプリケーションが同じ EFS ファイルシステムを永続ストレージとして使用しながら、アプリケーション間の分離が実現します。 それでは、動的プロビジョニングに使用する新しい Amazon EFS ファイルシステム ( myEFS2 ) を作成しましょう。 訳注: 静的プロビジョニングで実施した手順と同様に、「カスタマイズ」を選択し、VPC は eksctl-efsworkshop-eksctl-cluster/VPC を選択し、マウントターゲットのセキュリティグループは事前に作成したセキュリティグループを選択してください。 次に、Storage Class を作成し、新しく作成されたファイルシステムの FileSystemId を指定します。 #sc.yaml ---- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: efs-sc provisioner: efs.csi.aws.com parameters: provisioningMode: efs-ap fileSystemId: fs-026bb4e33bea77857 directoryPerms: "700" Storage Class を作成して確認します。 $ kubectl apply -f sc.yaml storageclass.storage.k8s.io/efs-sc created $ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE efs-sc efs.csi.aws.com Delete Immediate false 4s gp2 (default) kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 2d5h 「動的プロビジョニング」セクションで述べたように、アプリケーションをデプロイする前に PV を作成する必要はありません。したがって、先に進んで PVC と Pod を作成できます。 #pvc_pod_1.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: efs-claim-1 spec: accessModes: - ReadWriteMany storageClassName: efs-sc resources: requests: storage: 5Gi --- apiVersion: v1 kind: Pod metadata: name: efs-app-1 spec: containers: - name: app image: centos command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /data/out; sleep 5; done"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: efs-claim-1 PVC と Pod をデプロイしましょう。 $ kubectl apply -f pvc_pod_1.yaml persistentvolumeclaim/efs-claim-1 created pod/efs-app-1 created $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE efs-claim-1 Bound pvc-82da05b5-ff85-40a5-8135-50428480fd22 5Gi RWX efs-sc 89s $ kubectl get pv | grep efs-sc pvc-7994fdce-5711-4346-aefb-85e10155ec7c 5Gi RWX Delete $ kubectl get pods NAME READY STATUS RESTARTS AGE efs-app-1 1/1 Running 0 95s $ kubectl exec -ti efs-app-1 -- tail -f /data/out Tue Mar 22 00:38:08 UTC 2022 Tue Mar 22 00:38:13 UTC 2022 Tue Mar 22 00:38:18 UTC 2022 efs-app-1 が正常に実行され、EFS CSI ドライバーによって PV が自動的に作成されたことが確認できました。AWS マネジメントコンソールでは、それぞれのアクセスポイントが確認できます。 このプロセスを繰り返して別のアプリケーション ( efs-app-2 ) を作成すると、自動的に別のアクセスポイントが作成されます。PV について心配する必要はありません。 以下は、動的プロビジョニングのまとめです。 クリーンアップ すべてのエクササイズが終わったら、すべてのリソースを削除しましょう。 すべての Kubernetes リソース (PV、PVC、Pod、Storage Class など) を削除します。 $ kubectl delete -f pod.yaml $ kubectl delete -f pvc.yaml $ kubectl delete -f pv.yaml $ kubectl delete -f pvc_pod_1.yaml $ kubectl delete -f sc.yaml AWS マネジメントコンソールまたは AWS CLI で EFS ファイルシステム ( myEFS1 と myEFS2 ) を削除します。 EKS クラスターを削除 ( eksctl delete cluster efsworkshop-eksctl ) します。 訳注: KMS キー ( efsworkshop ) 、Cloud9 環境 ( efsworkshop ) 、IAM ロール ( efsworkshop-admin ) も削除してください。 まとめ このブログ記事では、Kubernetes の永続ストレージの基本原則について説明しました。Persistent Volume を使用することで、Pod のクラッシュや終了に関係なくデータが永続化されるステートフルなアプリケーションを Kubernetes 上に作成できます。Persistent Volume は、静的プロビジョニングまたは動的プロビジョニングのいずれかを使用してプロビジョニングできます。基盤となるストレージとして Amazon EFS を使用して、EKS クラスター上で両方のデモを行いました。 基本的なことはすべて学んだので、次はより実用的なユースケースに移ります。このブログ記事シリーズの Part 2 では、Kubeflow を使って機械学習ワークロードを実行するために永続ストレージを利用します。 このブログ記事をお読みいただきありがとうございます。コンテナでの EFS の使用に関するその他のチュートリアルについては、 amazon-efs-developer-zone GitHub リポジトリにアクセスしてください。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

ある企業は、未来に向けて変革したいと考えています。トランスフォーメーションがなければ、破壊的な競合他社に脅かされるか、顧客にサービスを提供できなくなります。しかし、従業員が日々の仕事に忙殺されているため、トランスフォーメーションに着手できません。変革には努力が必要です。また、プロセスを変更すると同時に、そのプロセスを使ってビジネスを運営しなければなりません （「自転車に乗りながらタイヤを交換する」という問題）。新しいスキルの習得、新しいクラウド環境の準備、ビジネスプロセスの変更、企業の再編成など、トランスフォーメーションに必要な作業を、同じプロセスで忙しくしている間に誰が行うのでしょうか？ 事実：従業員はすでに忙しいのです。彼らはフルタイムの仕事をしています。彼らは新しい仕事を待っているわけでもありません。もしそうであれば、あなたはそれを容認しないでしょうし、従業員が十分に活用されていなければ、多くの給料を支払うこともないでしょう。また、トランスフォーメーションの仕事をするために新しい従業員を増やすだけでは変革はできません。それではトランスフォーメーションとは言えず、新しい会社や事業部を作るようなものです。トランスフォーメーションは、すでに存在しているものを変えることなのです。 つまり、トランスフォーメーションを会社の日常業務の一部にする方法を見つけなければなりません。というのも、私たちはトランスフォーメーションを、開始点、終着点、一連のステップが明確に定義されたプロジェクトであるかのように言い続けているからです。 以前のブログ記事 で指摘したように、デジタルトランスフォーメーションは解釈がぶれる言葉です。デジタルトランスフォーメーションとは、 企業の働き方を変えること だと理解するのに役立ちます。それは日常の活動や考え方を変えることです。 もちろん、大規模な技術的取り組み （例えばクラウドへの移行） も含まれますが、そうした取り組みは会社の働き方を変えるためのものです。これらは日常業務の変更によって推進されるのが最適なのです。この2つは一体となります。私が役に立つと思ったフレームワークは、 ゴイコ・アジッチのインパクト・マッピング です。彼のフレームワークでは、ビジネスの目的から出発し、どのような行動の変化がその目的を達成するのに役立つかをマッピングします。次に、どのような技術的変化がその行動変容をサポートするかを考えます。 日々の活動とは別に、5年間の詳細なトランスフォーメーションロードマップをプロジェクト計画として作成すれば、問題はさらに悪化します。全員の承認を得るのに何年も費やすことになり、その結果、それを実行する自由な時間を持つ者がいなくなってしまうでしょう。 確かに、この質問の出し方には少し突飛なところがあります。私は冒頭で、あなたが会社の将来にとってトランスフォーメーションが不可欠だと判断し、会社が顧客のニーズに応えられなかったり、新たな競合他社 （おそらくは動きの速い新興企業） によって破壊されたりするリスクがあると仮定しました。会社の従業員には、会社の存続に必要なことをするための十分な時間がないようです。ここには明らかに優先順位の問題があります。会社の存続は最優先事項なので、リストの一番上になければなりません （優先順位設定の問題については、 以前のブログ記事 を参照）。何か他のことをしなければならないのです。 とはいえ、これは私が企業のリーダーたちから聞く話であり、企業のリーダーだった私には彼らがどこから来るのか理解できます。 変革するための時間を見つける 問題に対する考え方を逆転させてみてはどうでしょうか。新しいテクノロジーを構築し、それを使って従業員の働き方を変えるのではなく、従業員が望む働き方を変え、それをテクノロジーの変革の原動力にするのです。そのためのアイデアをいくつか紹介します。 まず、トランスフォーメーションへのコミットメントを示す必要があります。社員に変革を指示したり、計画を書いたり、スライドデッキを作ったりするだけでは不十分です。トランスフォーメーションは、時間に余裕があるときに取り組む余分なものではないというメッセージを伝えなければなりません。それは最優先事項 （冗長な表現？） であり、会社が計画していることではなく、 行っている ことなのです。リーダーはそれを実現するためならトレードオフもいといません。 ある AWS のお客様の幹部は最近、ベストプラクティスや新しい知識を共有するための週1回のセッションなど、自社のトランスフォーメーションを進めるために彼が作った知識共有コミュニティについて話してくれました。彼は金曜日の午後にミーティングを行っていましたが、私にはそれが間違っているように思えました。小さなことかもしれませんが、リーダーシップがそれを重要だと考えていないことを示していました。月曜日のゴールデンタイムに、新しい知識が次の週にどのように使われるかを説明するミーティングを行えば、知識共有セッションが役に立つかどうかは別として、その重要性をより強く示すことができます。トランスフォーメーションを強力に推進するには、知識の共有よりもはるかに多くの 「実行」 が必要なのです。 次に、インセンティブと役割の定義を変える必要があります。トランスフォーメーションのゴールは行動変容 （新しい仕事の仕方や考え方） であるため、新しい行動にインセンティブを与え、それをテクノロジー変革の要件推進に利用することで、トランスフォーメーションを最も効果的に進めることができます。インセンティブを変えなければ、従業員はこれまでと同じことを続けることになります。私は、必ずしも金銭的なインセンティブについて話しているのではなく、従業員の仕事の目的や、自分の役割にとっての成功がどのようなものかを変えただけです。新しいインセンティブの下では、「ただ仕事をする」だけでは失敗につながります。成功するためには、トランスフォーメーションのビジョンに沿って動く必要があるのです。 従業員は、トランスフォーメーションがどこに向かっているのかを明確に認識しなければなりません。詳細なロードマップではなく、変革後の企業の新しい状態と、それがどのように変わるのかというビジョンが重要です。ビジョンは、将来の状態がどのようにビジネス目標や組織の使命をよりよく達成するかを明確にする必要があります。漠然としたものや一般的なものであってはなりません。なぜなら、従業員の頭の中に、何を目指しているのか、なぜそれが重要なのかを明確に描かなければならないからです。忘れてはならないのは、副次的なプロジェクトとしてではなく、全員が日々の活動の中でトランスフォーメーションのビジョンに向かって取り組むことが目標だということです。 考えてみれば、「トランスフォーメーション」と呼ぶだけでも、まるで別個の、しかも非常に大規模なプロジェクトのように聞こえます。そして、誰がそんなことをする時間があるのでしょうか？　詳細なロードマップなしに、大きなコミットメントを進めるのは無責任に感じられます。しかし、コミットメントすべきはビジョンであって、実行の詳細ではありません。 長期的なロードマップの代わりに、大きなトランスフォーメーションの取り組みを一連のビジネス目標に変換し、その総和をトランスフォーメーションのビジョンとすることを試してみてはどうでしょうか。最初の目標は、会社の運営コストの構造を 20％ 削減することかもしれません。第二の目標は、特定のビジネスラインを拡大することかもしれません。第三の目標は、パンデミックやランサムウェア攻撃に対処できるよう、業務に回復力を持たせることかもしれません。これらの目標は具体的であり、日常的な企業活動に一体化しやすいのです。 物事を個々の目標に分解すると、トランスフォーメーションが断片化され、考え抜かれた技術的アーキテクチャーが稚拙なものになるのではないかと心配するかもしれません。高レベルのビジョンがそれを導き、アーキテクチャは反復的に形成され、洗練されていきます。 私が USCIS (訳者注：米国市民権・移民業務局) で担当したのは、巨大なトランスフォーメーションプロジェクトでした。私たちの最初の間違いは、このプロジェクトを一枚岩の取り組みと考えたことでした。つまり、 USCIS の紙プロセスをすべてデジタルプロセスにするつもりだったのです。達成可能なビジネス成果を明確にしたほうがよかったのです。オフィス間で移動する紙の量を減らしたいことは分かっていました。そのため、最も紙の移動が多い業務に優先的に取り組むことができました。また、不正申請の検出を強化したいこともわかっていたので、不正の可能性が最も高い移民給付金の種類に焦点を絞ることができました。他の目標についても同様です。このように目標を明確にしたことで、副業として技術インフラを構築するのではなく、日常業務と結びつけてトランスフォーメーションを進めることができました。 CIO はよく私に、ビジネス機能への要求事項ですでに手一杯なのに、どうやってレガシーな技術的負債を是正する時間を確保できるのかと尋ねてきます。うまくいかないのは、新規開発をすべて中止し、システムのモダナイズだけに何年も費やすことです。企業は何年もじっとしているわけにはいきません。その代わりに私は、新規開発作業は継続するが、納品される作業の品質については、安全性、回復力、保守性、自動的にデプロイ可能でテスト可能であることなど、非常に高い基準を採用することをよく勧めます。この標準を達成するためには、レガシーシステムに対する作業においても、レガシーの技術的負債を解決する必要がありますが、それは新機能の開発をサポートする範囲に限られます。こうして、変革的作業は日常業務の一部となっていくのです。 その他の留意点 従業員のトレーニングに時間を割くことは重要ですが、それが新しいスキルを開発するための戦略のすべてというわけにはいきません。技術者は、実践的な作業を行い、他の技術者とペアを組んで仕事を提供することによって、最もよく学ぶことができます。新しいスキルは、前提条件ではなく、トランスフォーメーションのアウトプットとして考えるのです。 組織は、トランスフォーメーションの責任者、 AWS ではシングルスレッドリーダーと呼んでいる者を任命することがあります。トランスフォーメーションに完全に専念する人をリーダーの役割に据えることは、強力なものになり得えます。しかし、この人物がトランスフォーメーションを実施する従業員に対する直接的な管理権限を持っていない場合、まだ問題があります。従業員はどうやって変革活動のための時間を作るのでしょうか？　また、トランスフォーメーションには従業員の仕事を変える必要があるため、トランスフォーメーションの責任者はどのようにその変化を引き起こすのでしょうか？ シングルスレッドリーダーを置くことは決して悪い考えではないですが、多忙な従業員がその努力の一部となれるよう、組織のリーダー全体のコミットメントと組み合わせる必要がります。トランスフォーメーションが重要だと言うだけでは十分ではありませんし、肩書きに「トランスフォーメーション」とあるシニアリーダーを任命してその重要性を伝えるだけでも十分ではありません。コミットメントとは、トランスフォーメーションを全員の日々の活動やインセンティブの一部にすることを意味するのです。 新しい行動にインセンティブを与えて変革するのは時間がかかるように聞こえるかもしれませんが、決意をもってやればそんなことはありません。社員が暇になるまで待つよりも、確実に速くなるのです。 逆算と前進 変革を日常的な活動から遠ざけすぎると、トランスフォーメーションのための時間を確保できません。変革を日常業務の一部にするためには、テクノロジーを進化させると同時に行動を変える必要があります。従業員は、与えられた目標を達成するために時間を費やします。彼らのインセンティブが変わらなければ、トランスフォーメーションは起こりません。一方、あなたが望む新しい行動に対して従業員にインセンティブを与えることで、従業員はトランスフォーメーションの 推進 に参加するようになります。私たちは時々、物事を逆から考えることがあるのです！ Mark Schwartz マーク・シュワルツは、アマゾンウェブサービスのエンタープライズストラテジストであり、『 The Art of Business Value and A Seat at the Table：IT Leadership in the Age of Agility 』の著者です。 AWS に入社する前は、米国市民権・移民業務局 (国土安全保障省の一部) の CIO、Intrax の CIO、および Auctiva の CEO を務めていました。 彼はウォートン大学で MBA を取得し、イェール大学でコンピューターサイエンスの理学士号を取得し、イェール大学で哲学の修士号を取得しています。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文は こちら です。

皆様、こんにちは！PSA (Partner Solutions Architect) の Yukki です。 本記事では直近新規公開された、AWS 初学者向けのコンテンツをご紹介いたします。 皆様や皆様の周りでこのようなお悩みを持っている方はいませんか？ 「クラウドという言葉はよく聞くけど、実はどういうものか説明できない」 「あまりにも学習リソースが多すぎて、何から始めればいいかわからない」 「AWS って結局何ができるの？」 このような方をこの記事の対象として、 2023 年 9 ～ 11 月に公開された初学者向けの動画コンテンツ をご紹介します。   1. QuizKnock 鶴崎 氏が語る AWS の魅力 (提供：アマゾン ウェブ サービス ジャパン合同会社) QuizKnock【クイズノック】はクイズ王・伊沢 拓司 氏率いる東大発の知識集団です。 QuizKnock の YouTube チャンネル 登録者は 212 万人を突破。(2023 年 10 月時点) そのメンバーである鶴崎 修功 氏はなんと AWS ユーザー。「AWS でどんなツールを作ったの？」「ユーザーの視点から見てどんな点がいいの？」といった内容を、実際の AWS ユーザーならではの実感を持って語っていただきます。 AWS の推しサービスの話もあり、熱量を感じ取ることができる動画です。 言わずと知れたクイズ王・伊沢 拓司 氏が初学者の目線から質問をしてくれるので、初めて AWS に触れるという方も楽しさが伝わる内容になっています。まずは気軽に開発の世界に触れてみたいという皆様、ぜひご覧ください。 また動画で紹介されたコンテンツは、以下のページにまとめられていますので合わせてチェックしてみてください。 https://aws.amazon.com/jp/local/quizknock-tie-up/   2. Cloud for Beginners on-demand training こちらの動画は IT 初学者の方を対象に、基礎的な IT 用語の説明と AWS クラウドを学習する上で必要となる IT 知識について解説する合計約 3 時間のオンデマンドコンテンツです。ウェブサービスや、サーバーはどのように構成されているのか、CPU やメモリはどのような働きをしているのか、 AWS クラウドがどういうものなのかといった、AWS の学習をはじめる際に前提となる知識を効率よく学ぶことができます。IT に関する専門用語について適宜解説しながら進行しているので、AWS に関心がある非 IT 領域の方々や学生の皆様にお勧めです。登録不要ですぐにご覧いただけます。 ご視聴はこちらから： ご視聴ページ        3. AWSome Day Online Conference AWS クラウド初学者向け大規模オンラインイベント AWSome Day Online Conference が 2023 年 11 月 16 日（木）に開催 されます！今回で年内最後の開催となります。上記の 1, 2 で概要についての予備知識を手に入れたあなたなら、きっとより楽しめるのがこのイベントです。実は私がこのイベントの講師をしています。私 Yukki と、トレーニングチームでプログラムマネージャーをしている平賀の 2 名による台本無しの掛け合い形式で進行していきます。平賀さんは皆様の立場になって質問をしたりコメントをしますので、聞きやすくなっています。 さらにそれぞれのトピックでは、AWS を実際に操作するデモを取り入れました。デモも掛け合いを行っていますので、ぜひ皆様は平賀さんの立場になって聞いていただけると、より操作するイメージが湧きやすくなると思います！もし聞いている中で疑問に思うことがあったら、すぐにプライベートチャットで AWS エキスパートに質問することができます。その場で疑問を解消していくことがスムーズな学習のコツ！ということで、ぜひこの機会をご活用ください。資料のダウンロードもできるので、復習にも役立ちます。 こちらのオンラインイベントは参加登録が必要です。お忘れなく！また AWSome Day の画面でお会いしましょう！！ ご登録はこちらから： 登録ページ        まとめ 本記事では、AWS 初学者向けに最近公開されたコンテンツをご紹介しました。このほかにも、2023 年 10 月にはロールプレイング形式で AWS クラウドについて学べる AWS Cloud Quest の日本語版 の公開もされるなど、数多くの入り口が用意されています。 これらのリソースを活用して、今日から AWS の学習を早速始めてみましょう！最後まで読んでいただき、本当にありがとうございました！！

イントロダクション Amazon VPC Lattice は、AWS ネットワークインフラストラクチャに直接組み込まれた、フルマネージドなアプリケーションネットワーキングサービスです。複数のアカウント、複数の仮想プライベートクラウド (VPC) にまたがる全てのサービスの接続、セキュア化、監視に使用できます。 Amazon Elastic Kubernetes Service ( Amazon EKS ) では、 Kubernetes Gateway API の実装である AWS Gateway API コントローラー を通じて、Amazon VPC Lattice を使用できます。Amazon EKS のお客様は、Amazon VPC Lattice を用いることで、シンプルかつ一貫性のある方法で、標準的な Kubernetes のセマンティクスによりクラスターをまたいだ接続を設定できます。 一方で、特定のお客様ではアプリケーションレイヤーのセキュリティを強化したいという要望がありました。Amazon VPC Lattice のデザインはセキュアバイデフォルトです。これは、どのサービスを共有したいのか、どの VPC にアクセスを提供したいのかを、明確にする必要があるためです。 Amazon VPC Lattice は 3 レイヤーのフレームワーク を提供しており、ネットワークの複数のレイヤーで多層防御戦略を実装できます。これらのレイヤーには、サービスネットワークと VPC の関連付け、セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、AWS Identity and Access Management ( AWS IAM ) 認証ポリシーが含まれ、Amazon VPC Lattice を構成することでセキュリティとコンプライアンスの目標を達成することができます。 VPC 内のセキュリティグループのサービスネットワークへの関連付けと認証ポリシーは、どちらもオプションです。セキュリティグループを設定せずに、サービスネットワークを VPC に関連付けることができます。また、認証タイプを NONE に設定して、認証ポリシーを使用しないこともできます。 本記事では、3 つ目のレイヤー、すなわちサービスネットワークと各々のサービスに適用できる、VPC Lattice の認証ポリシーに焦点を当てます。通常、サービスネットワークの認証ポリシーはネットワーク管理者あるいはクラウド管理者によって運用され、粗い粒度での認証を実装します。例えば、AWS Organizations の指定した組織からの認証済みリクエストのみ許可します。一方、サービスの認証ポリシーでは、サービスのオーナーはネットワーク管理者やクラウド管理者がサービスネットワークのレベルで適用した粗い粒度での認証ルールよりも制限の厳しい、きめ細やかな制御を設定できます。認証ポリシーを使用することで、お客様はアプリケーションのコードを変更することなく、 誰が、どのサービスに対して、どのアクションを実行できるか を定義することができます。 我々の実装では、以下の方法を示します。 Amazon VPC Lattice サービスネットワークと Amazon EKS を構築し、Amazon VPC Lattice サービスの認証ポリシーを有効にします。 Amazon EKS と Amazon VPC Lattice でのサイドカーパターンと Init コンテナパターンを用いて、サービスの呼び出し元が AWS IAM 認証で Amazon VPC Lattice サービスに対しての HTTP リクエストの生成を自動的におこなえるようにするソリューションを構築します。呼び出し元のアプリケーションのソースコードの変更は必要ありません。 サービスの呼び出し元が Amazon VPC Lattice サービスネットワーク内の複数のサービスに接続できることを確認します。 ソリューション概要 Amazon VPC Lattice は AWS IAM と統合され、お客様独自のサービス間通信のために、現在 AWS サービスとやり取りする時に慣れ親しんでいるのと同様の認証・認可の機能を提供します。 サービスのアクセス制御を設定するために、アクセスポリシーを使用できます。アクセスポリシーは、サービスネットワークと個々のサービスに関連付けることができる AWS IAM リソースポリシーです。アクセスポリシーでは、PARC (Principal、Action、Resource、Condition) モデルを使用して、サービスのコンテキスト固有のアクセス制御を適用できます。例えば、所有するサービスに対してアクセス可能なサービスを定義するために、アクセスポリシーを使用できます。 Amazon VPC Lattice はクライアント認証に AWS Signature Version 4 (SigV4) を使用します。Amazon VPC Lattice のサービスで認証ポリシーを有効化した後に、署名付き Authorization ヘッダー、 x-amz-content-sha256 、 x-amz-date 、 x-amz-security-token が HTTP リクエストに含まれるよう、サービスを呼び出す側を変更する必要があります。AWS SigV4 の詳細は こちら を参照してください。 Amazon VPC Lattice サービスへのリクエストに署名するために、お客様には以下の選択肢があります。 AWS SDK を用いて、対応するプログラミング言語でリクエストに署名します。このソリューションはパフォーマンスが最適化されますが、アプリケーション開発者によるコードの変更を必要とします。実装については Amazon VPC Lattice のドキュメント を参照してください。 AWS SIGv4 プロキシアドミッションコントローラーを活用し、 AWS SIGv4 プロキシ を用いて HTTP リクエストをフォワードし、AWS Sigv4 ヘッダーを追加します。詳細については、こちらの 記 事 を参照してください。しかし、上記のソリューションには 1 つの制限があります。AWS SIGv4 プロキシアドミッションコントローラーを使用する場合、単一のホストしかサポートされません。 サンプルのマニフェスト では、フロントエンドのコンテナは localhost:8005 にリクエストをしていて、Host ヘッダーは sidecar.aws.signing-proxy/host Annotations で静的に定義された datastore-lambda.sarathy.io に置き換えられていることがわかります。言い換えると、呼び出し元のサービスは単一の Amazon VPC Lattice サービスにのみ接続できます。クライアントが複数の Amazon VPC Lattice サービスに接続する場合に、課題となります。 この記事では、完全に透過的に複数の Amazon VPC Lattice サービスに対する接続をサポートする、最適化されたソリューションを紹介します。 はじめに、Kubernetes の Pod に Init コンテナとサイドカーコンテナを導入します。 Init コンテナ： iptables を実行し、ポート 8080 をリッスンする AWS SigV4 プロキシから Amazon VPC Lattice サービスへのトラフィックをインターセプトします。 SigV4 プロキシ： --name vpc-lattice-svcs, --unsigned-payload フラグとロギングのオプションを含む args を指定して実行します。プロキシコンテナは AWS IAM roles for service accounts (IRSA) によって取得された認証情報を使用して、自動的にリクエストに署名します。 次に、Init コンテナとサイドカーコンテナを自動的に注入します。開発チームが既存の Kubernetes マニフェストに変更を加えないようにするためです。ポリシーエンジンとして Kyverno を使用します。Kyverno は Kubernetes のために設計されており、Kubernetes クラスター内で Dynamic Admission Controller として動作します。この場合、Kyverno は Kubernetes API サーバーから Mutating Admission Webhook の HTTP コールバックを受け取り、マッチするポリシーを適用して、Admission Policy を強制する結果を返します。言い換えると、Kyverno は Init コンテナとサイドカーコンテナをコーディングを必須とせずに自動的に注入することができます。 ウォークスルー Amazon EKS における Amazon VPC Lattice と認証ポリシー 前提条件 管理者権限を持つ AWS アカウント AWS Command Line Interface ( AWS CLI )、 kubectl 、 eksctl 、 Git のインストール Amazon EKS クラスターと Amazon VPC Lattice サービスの準備 ソリューションをテストするための環境を準備する必要があります。 Amazon EKS クラスターの作成と、Amazon VPC Lattice のための Gateway API コントローラーのインストール Kyverno のインストール サンプル httpbin アプリケーションを Amazon VPC Lattice サービスとしてデプロイする 以下のコマンドを使用して、httpbin を Amazon VPC Lattice サービスとしてデプロイします。 git clone https://github.com/aws/aws-application-networking-k8s.git cd aws-application-networking-k8s/examples ## Create the GatewayClass, Gateway, HTTPRoute, Service and Deployment objects kubectl apply -f gatewayclass.yaml kubectl apply -f my-hotel-gateway.yaml kubectl apply -f httpbin.yaml kubectl apply -f httpbin-route.yaml ## Create another VPC Lattice Service (HTTPRoute), Service and Deployment object cat << EOF > another-httpbin.yaml apiVersion: apps/v1 kind: Deployment metadata: name: another-httpbin labels: app: another-httpbin spec: replicas: 1 selector: matchLabels: app: another-httpbin template: metadata: labels: app: another-httpbin spec: containers: - name: httpbin image: mccutchen/go-httpbin --- apiVersion: v1 kind: Service metadata: name: another-httpbin spec: selector: app: another-httpbin ports: - protocol: TCP port: 80 targetPort: 8080 EOF cat << EOF > another-httpbin-route.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: another-httpbin spec: parentRefs: - name: my-hotel sectionName: http rules: - backendRefs: - name: another-httpbin kind: Service port: 80 EOF ## Another VPC Lattice Service kubectl apply -f another-httpbin.yaml kubectl apply -f another-httpbin-route.yaml Bash サービスネットワークの保護 この機能を実証するために、 httpbin サービスに認証ポリシーを適用し、認証されたアクセスのみを許可します。 ドキュメント を参照することで、粒度の細かいポリシーを定義できます。 AWS コンソールの VPC セクションに移動し、 VPC Lattice の下の Services 、右ペインの httpbin-default サービスを選択します。 次のページで Access タブの Edit access settings を選択します。 表示される Service access 画面で、 AWS IAM から Apply policy template > Allow only authenticated access を選択します。次に Save changes を選択します。 ここで、サービスが AWS IAM 認証を必要とし、そうでなければ HTTP 403 Forbidden エラーを返すかを示すテストを実施します。 kubectl run curl --image alpine/curl -ti -- /bin/sh curl -v http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws * Trying 169.254 .171.32:80 .. . * Connected to httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws ( 169.254 .171.32 ) port 80 ( #0) > GET / HTTP/1.1 > Host: httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws > User-Agent: curl/8.0.1 > Accept: / < HTTP/1.1 403 Forbidden < content-length: 253 < content-type: text/plain < date: Mon, 31 Jul 2023 07:24:10 GMT < * Connection #0 to host httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws left intact AccessDeniedException: User: anonymous is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:us-west-2:091550601287:service/svc-09ff9bb5d43b72048/ because no service-based policy allows the vpc-lattice-svcs:Invoke action # Bash 呼び出し元のアプリケーションのデプロイ ここで、AWS IAM roles for service accounts (IRSA) を使用するようプロキシを構成し、プロキシがリクエストに署名するために AWS IAM ロールの認証情報を使用できるようにします。アイデンティティベースのポリシーである VPCLatticeServicesInvokeAccess を AWS IAM ロールにアタッチすることで、Amazon VPC Lattice サービスを呼び出す権限をロールに付与できます。 Service Account 用の IAM ロールの作成 export CLUSTER_NAME = my-cluster export NAMESPACE = default export SERVICE_ACCOUNT = default eksctl create iamserviceaccount \ --cluster = $CLUSTER_NAME \ --namespace = $NAMESPACE \ --name = $SERVICE_ACCOUNT \ --attach-policy-arn = arn:aws:iam::aws:policy/VPCLatticeServicesInvokeAccess \ --override-existing-serviceaccounts \ --approve Bash 準備が完了したら、プロキシコンテナと一緒にサービスを呼び出すアプリケーションを準備します。プロキシコンテナはポート 8080 をリッスンし、ユーザー ID 101 として実行します。YAML スニペットは以下のとおりです。 - name : sigv4proxy image : public.ecr.aws/aws - observability/aws - sigv4 - proxy : latest args : [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , "us-west-2" , "--upstream-url-scheme" , "http" ] ports : - containerPort : 8080 name : proxy protocol : TCP securityContext : runAsUser : 101 YAML ここでは、メインのアプリケーションからのトラフィックをインターセプトし、 iptables ユーテリティを使って Amazon VPC Lattice CIDR 169.254.171.0/24 に接続するトラフィックを EGRESS_PROXY チェーンにルーティングし、ローカルのポート 8080 にリダイレクトしています。プロキシコンテナによってトラフィックが送信される際の無限ループを避けるため、UID が 101 かどうかをチェックすることで識別し、再度リダイレクトされないようにしています。 initContainers : # IPTables rules are updated in init container - image : public.ecr.aws/d2c6w7a3/iptables name : iptables - init securityContext : capabilities : add : - NET_ADMIN command : # Adding --uid-owner 101 here to prevent traffic from envoy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - - c - > iptables -t nat -N EGRESS_PROXY; iptables -t nat -A OUTPUT -p tcp -d 169.254.171.0/24 -j EGRESS_PROXY; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080; YAML コンテナイメージ public.ecr.aws/d2c6w7a3/iptables は、シンプルに iptables がインストールされた Ubuntu Linux ディストリビューションのベースイメージです。 FROM ubuntu:focal RUN apt update && apt install -y iptables Bash 完全な YAML マニフェストは以下のようになります。 apiVersion: apps/v1 kind: Deployment metadata: name: client-app labels: app: client-app spec: replicas: 1 selector: matchLabels: app: client-app template: metadata: labels: app: client-app spec: serviceAccountName: default initContainers: # IPTables rules are updated in init container - image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN command: # Adding --uid-owner 101 here to prevent traffic from aws-sigv4-proxy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - -c - > iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; containers: - name: app image: alpine/curl command: [ "/bin/sh" , "-c" , "sleep infinity" ] - name: sigv4proxy image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest args: [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , "us-west-2" , "--upstream-url-scheme" , "http" ] ports: - containerPort: 8080 name: proxy protocol: TCP securityContext: runAsUser: 101 Bash curl を実行することで、/get のレスポンスが表示されます。レスポンスは HTTP 200 OK です。 ➜ kubectl get gateway -o yaml | yq '.items[0].status.addresses[].value' another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws ➜ VPC_LATTICE_SERVICE_ENDPOINT = http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get ➜ kubectl exec -c app -ti deploy/client-app -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.46.245" , "url" : "http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash プロキシコンテナのログを確認することで、ヘッダーがプロキシによって追加されたことを確認できます。 Authorization ヘッダーと、 x-amz-content-sha256 、 x-amz-date 、 x-amz-security-token といったヘッダーがリクエストに追加されています。 ➜ kubectl logs deploy/vpc-lattice-client -c sigv4proxy time = "2023-08-07T10:14:59Z" level = debug msg = "signed request" region = us-west-2 service = vpc-lattice-svcs time = "2023-08-07T10:14:59Z" level = debug msg = "proxying request" request = "GET /get HTTP/1.1 \r \n Host: httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws \r \n Accept: */* \r \n Authorization: AWS4-HMAC-SHA256 Credential=ASIARKUGXKBDQVWU6BFX/20230807/us-west-2/vpc-lattice-svcs/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=<redacted> \r \n User-Agent: curl/8.0.1 \r \n X-Amz-Content-Sha256: UNSIGNED-PAYLOAD \r \n X-Amz-Date: 20230807T101459Z \r \n X-Amz-Security-Token: IQoJb3JpZ2luX2VjEMr//////////<redacted>== \r \n \r \n " Bash ここでは、 VPC_LATTICE_SERVICE_ENDPOINT を 2 つ目のホスト名に置き換えることができます。アプリケーションコードの変更は必要としないので、複数の Amazon VPC Lattice サービスに接続することができます。 ➜ VPC_LATTICE_SERVICE_ENDPOINT = http://another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get ➜ kubectl exec -c app -ti deploy/client-app -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.32.152" , "url" : "http://another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash Kyverno を使って、Init コンテナとサイドカーコンテナを自動で注入する ここで、Kyverno を活用して、Init コンテナとサイドカーコンテナを自動で注入するようにします。Kyverno がインストールされたクラスターでは、注入するための ClusterPolicy を書くことができます。Deployment オブジェクトに vpc-lattices-svcs.amazonaws.com/agent-inject が true であるアノテーションが設定されると、Deployment に Init コンテナとサイドカーコンテナが注入されます。 環境変数 AWS_REGION を指定する必要もあります。 apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: inject-sidecar annotations: policies.kyverno.io/title: Inject Sidecar Container spec: rules: - name: inject-sidecar match: any: - resources: kinds: - Deployment mutate: patchStrategicMerge: spec: template: metadata: annotations: ( vpc-lattices-svcs.amazonaws.com/agent-inject ) : "true" spec: initContainers: # IPTables rules are updated in init container - image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN command: # Adding --uid-owner 101 here to prevent traffic from envoy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - -c - > iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; containers: - name: sigv4proxy env: - name: AWS_REGION value: "us-west-2" image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest args: [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , \ $( AWS_REGION ) , "--upstream-url-scheme" , "http" ] ports: - containerPort: 8080 name: proxy protocol: TCP securityContext: runAsUser: 101 Bash このアプローチでは、Kubernetes Deployment の YAML に vpc-lattices-svcs.amazonaws.com/agent-inject: "true" を指定すると、Deployment に Init コンテナとサイドカーコンテナが注入されます。 クライアントの YAML は以下です。 apiVersion: apps/v1 kind: Deployment metadata: name: vpc-lattice-client labels: app: vpc-lattice-client spec: replicas: 1 selector: matchLabels: app: vpc-lattice-client template: metadata: labels: app: vpc-lattice-client annotations: vpc-lattices-svcs.amazonaws.com/agent-inject: "true" spec: serviceAccountName: default containers: - name: app image: alpine:curl command: [ "/bin/sh" , "-c" , "sleep infinity" ] Bash サイドカーは自動的に注入されます。 ➜ kubectl describe deploy vpc-lattice-client Name: vpc-lattice-client Namespace: default CreationTimestamp: Thu, 20 Jul 2023 11 :01:32 +0800 Labels: app = vpc-lattice-client Annotations: deployment.kubernetes.io/revision: 1 policies.kyverno.io/last-applied-patches: inject-sidecar.inject-sidecar.kyverno.io: added /spec/template/spec/containers/0 .. . Bash パッチが当たった YAML マニフェストは以下のようになります。 ➜ kubectl get deploy vpc-lattice-client -o yaml apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" kubectl.kubernetes.io/last-applied-configuration: | { "apiVersion" : "apps/v1" , "kind" : "Deployment" , "metadata" : { "annotations" : { } , "labels" : { "app" : "vpc-lattice-client" } , "name" : "vpc-lattice-client" , "namespace" : "default" } , "spec" : { "replicas" :1, "selector" : { "matchLabels" : { "app" : "vpc-lattice-client" } } , "template" : { "metadata" : { "annotations" : { "vpc-lattices-svcs.amazonaws.com/agent-inject" : "true" } , "labels" : { "app" : "vpc-lattice-client" } } , "spec" : { "containers" : [ { "command" : [ "/bin/sh" , "-c" , "sleep infinity" ] , "env" : [ { "name" : "HTTP_PROXY" , "value" : "localhost:8080" } ] , "image" : "nicolaka/netshoot" , "name" : "app" } ] , "serviceAccountName" : "default" } } } } policies.kyverno.io/last-applied-patches: | inject-sidecar.inject-sidecar.kyverno.io: added /spec/template/spec/containers/0 creationTimestamp: "2023-07-20T03:01: labels: app: vpc-lattice-client name: vpc-lattice-client namespace: default spec: selector: matchLabels: app: vpc-lattice-client template: metadata: annotations: vpc-lattices-svcs.amazonaws.com/agent-inject: " true" creationTimestamp: null labels: app: vpc-lattice-client spec: containers: - args: - --unsigned-payload - --log-failed-requests - -v - --log-signing-process - --name - vpc-lattice-svcs - --region - $( AWS_REGION ) - --upstream-url-scheme - http env: - name: AWS_REGION value: us-west-2 image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest imagePullPolicy: Always name: sigv4proxy ports: - containerPort: 8080 name: proxy protocol: TCP resources: { } securityContext: runAsUser: 101 terminationMessagePath: /dev/termination-log terminationMessagePolicy: File - command: - /bin/sh - -c - sleep infinity image: alpine:curl imagePullPolicy: Always name: app initContainers: - command: - /bin/sh - -c - | iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN .. . Bash また、クライアントが Amazon VPC Lattice サービスに正常にアクセスできることも確認できます。 ❯ VPC_LATTICE_SERVICE_ENDPOINT = http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get kubectl exec -c app -ti deploy/vpc-lattice-client -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.32.152" , "url" : "http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash クリーンアップ 将来的な課金を避けるため、以下のコマンドを使用して Amazon VPC Lattice リソースと Amazon EKS クラスターを含む、全てのリソースを削除します。 kubectl delete -f httpbin.yaml kubectl delete -f httpbin-route.yaml kubectl delete -f another-httpbin.yaml kubectl delete -f another-httpbin-route.yaml kubectl delete -f my-hotel-gateway.yaml kubectl delete -f gatewayclass.yaml eksctl delete cluster -f $CLUSTER_CONFIG Bash まとめ この記事では、Amazon VPC Lattice に AWS IAM 認証を実装する方法を、以下のようなソリューションを用いて紹介しました。 Init コンテナを使って iptables コマンドを実行し、VPC Lattice へのトラフィックをインターセプトする。 Kyverno を用いて Init コンテナとサイドカーコンテナを自動的に注入する。 呼び出し元のサービスは、VPC Lattice サービスネットワーク内の IAM 認証で複数のサービスに接続できるようになる。 VPC Lattice をベースにソリューションを構築し、VPC Lattice の IAM 認証を活用してセキュリティ体制を強化したい場合に、本ブログで共有した内容がお役に立てば嬉しいです。Amazon VPC Lattice の詳細については、 ドキュメント やその他の ブログ を参照してください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

みなさんこんにちは。ソリューションアーキテクトの林です。2023 年 10 月12 日に AWS が主催するエネルギー業界向けイベント「AWS Energy Tech Forum 2023」を開催しました。今年で 2 回目となる本イベントも 前回 同様のオンライン開催となりましたが、 1000 名近く の方にご登録いただきました。今年の本イベントでは、エネルギー業界で先進的に AWS をご活用いただいている、送配電網協議会様、関電システムズ様、JERA 様、北海道ガス様、関西電力送配電様にご登壇いただきました。 オープニング – 川島 浩史 アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ事業統括本部 ストラテジックカスタマー営業本部 第三営業部 部長 オープニングでは、エネルギー業界におけるクラウド活用のバリューチェーンや日本のエネルギー企業さまのクラウド活用の拡大についてご紹介しました。また、グローバルでの参考取組みとして、ENGIE 社におけるゼロカーボンエネルギーのためのデジタルプラットフォーム、Duke Energy 社と AWS の戦略的提携とグリッドソリューションの共同開発、NERC CIP 標準の対応をサポートするための AWS ユーザーガイド公開について紹介しました。 電力データで何ができるか 社会課題解決に向けた電力データ集約システムの取り組み –  田村 豪一朗 様 送配電網協議会 ネットワーク企画部 部長（電力データ活用担当） セッションでは、送配電網協議会様より、全国のスマートメーターデータを扱う電力データ集約システム構築に至る背景やAWS 選定の理由、実装アーキテクチャなどについてご説明頂きました。ペタバイトクラスの大量データを扱うシステムとして、AWS クラウドの柔軟性と高可用性のメリットを最大限活用した事例となっております。 2020 年 6 月の改正電気事業法により、スマートメーターから得られる電力使用量データを、有事の際に災害復旧などへの活用、平時においても (利用者本人が同意した場合に限り) 社会課題解決などを目的とする活用が可能となりました。スマートメーターデータを活用することで、防災計画の高度化などの災害発生時のレジリエンス強化だけでなく、平時においてもみまもりサービスなどの新たなイノベーションを実現できます。しかし、法改正当時は手作業でデータを抽出しており、データ取得のための作業コストに課題がありました。電力データ集約システムはそのような課題に端を発し、2021 年に検討が開始され、18 カ月の構築フェーズを経て 2023 年 9 月末に運用を開始されております。各エリアで段階的に運用を開始される予定です。全国 10 社の一般送配電事業者から連携されるスマートメーターデータは約 8,000 万件となり、3 年間保持した場合は電力データ量だけで数ペタバイトに及ぶため、システム基盤は大量データを扱うことができ、拡張性がある必要がありました。AWS の拡張性や東京・大阪リージョンの冗長構成での高可用性をご評価頂き、AWS 上での基盤構築の運びとなりました。電力データ集約システムでは全国のスマートメーターデータを収集・加工・蓄積し、Web、API 経由で自治体などの許可された利用者への提供を実現する必要があります。大量データの加工には Amazon EMR   を利用した並列加工処理を、増加するデータの蓄積には Amazon Simple Storage Service (S3) を利用して実質無制限でのデータ保存とデータ量に応じた従量課金を実現しております。 関西電力のデジタルトランスフォーメーションを支えるクラウド基盤のアジリティ向上への取り組み –  金子 恭史 様 株式会社関電システムズ テクニカルラボ クラウド＆アーキテクチャグループ アシスタントマネジャー セッションでは、関西電力様にて組成した CCoE (Cloud Center of Excellence) 組織や活動内容と更なるアジリティ向上のためのクラウド活用方針についてお話いだたきました。クラウド活用推進のための組織づくりや目標設定を検討されている参加者に参考になる具体的な取組みであったと推察します。 関西電力様は 2025 年までに新たな価値創造を目標とした “Kanden Transformation” を進めており、その加速に向けて IT インフラの「迅速さ・柔軟さ」「IT コスト削減」を実現するクラウドの活用を促進されており、2020 年にクラウドファースト宣言と CCoE を発足されました。クラウド活用推進の体制としては、本社組織が技術的な戦略を担いつつ、情報子会社である関電システムズに実動部隊としての CCoE を設置、基盤運用をオプテージ社が担うという体制を取られております。さらには AWS Professional Services をご活用いただくことで、AWS 利用ガイドライン作成などを効率的に実施されております。 直近では更にクラウドのメリットを活かした迅速でアジリティのある運用を実現するために、セキュリティルールの再定義を進められています。具体的には、発見的統制(権限はシステム開発箇所に付与しつつ、リスクのある設定・操作を検知して通知する統制)を導入することで、セキュリティを担保した形でのシステム開発者への権限付与を実現されています。セキュリティリスクに至る可能性のある設定・操作を AWS Config   で検知し、 AWS Security Hub   と 連携することで担当者への通知を実現し、セキュリティリスクを即座に発見・対処する仕組みを構築しました。そのほかにも AWS Service Catalog   を利用して事前に定義した環境を払い出すことでセキュリティリスクを低減しながらアジリティの向上を実現しています。このような運用変更により、従来であれば 10 営業日以上の申請待ち時間が生じていた作業について、システム開発箇所で完結可能となり、アジリティ向上を実現されています。 IoT/AIを活用した O&M 業務改善の取り組み -Global Data Analyzing Center – –  島添 道裕 様 株式会社JERA O&M・エンジニアリング戦略統括部 G-DAC モニタリングユニット シニアマネージャー –  佐藤 正芳 様 株式会社JERA 情報セキュリティ室 マネージャー –  大澤 正紹 様 株式会社JERA デジタルクリエーション部デジタルトランスフォーメーションユニット マネージャー セッションでは、JERA 様の発電所データの連係の仕組みから Global Data Analyzing Center (以下、G-DAC) でのデータ高度活用についてお話いただきました。発電所という OT 領域のクラウド連係や高度なデータ活用はセキュリティの懸念から進みにくい分野ですが、積極的に推進されている状況は、同領域を検討する参加者にとって参考になったのではないでしょうか。 JERA 様は発電設備の運転実績/設備データを収集・分析する基盤である IoT Platform を構築し、システム・部門を超えたデータ統合と高度分析による意思決定のスピード化・事業全体の最適化を実現されています。しかし、発電所とのデータ連係において、制御システムを納入する OT ベンダーにクラウドへの連係部分のシステムも依存していたため、データとシステム設計を自社で完全にコントロールできていないことに課題がありました。そこで、 AWS Direct Connect による専用接続と AWS Site-to-Site VPN  による暗号化の併用に加えて、 AWS Gateway Load Balancer   の採用により 、国内電力会社向けセキュリティガイドラインに準拠しつつ、システム更新やデータマネジメントを自社でコントロール可能な構成を構築されました。これにより、自社主導の統一的なデータ収集・活用を実現されています。収集したデータは G-DAC により高度に活用されております。2023 年 9 月時点で、G-DAC は国内外 62 の発電ユニットと連携しており、「予兆管理」「性能管理/診断」「運転最適化」を 3 つの柱としてサービス提供されています。JERA 様が独自ノウハウを活用した予測モデルを構築するために、 Amazon SageMaker   を利用した AI/ML の内製化を実現されております。G-DAC により計画外設備停止時間の 10~20% 削減や年間 1 億円超の燃料費削減を実現しております。 AWS IoT を活用した業務用分野におけるエネルギーマネジメントシステムの開発 –  國奥 広伸 様 北海道ガス株式会社 エネルギーシステム部 エネルギーシステムグループ 係長 セッションでは、北海道ガス様の事業部メンバーが主体となって構築したエネルギーマネジメントシステム (以下、EMS) について、PoC 検討からサービスリリースに至るまでの課題や内製化の取組みについてお話いただきました。AWS やIoT に知見のなかった事業部メンバーが、事業構想からサービスリリースまでを主体的に進めた貴重な事例です。 北海道ガス様は、分散型エネルギー社会の実現に向けて、分散型 EMS の導入促進に取組まれています。2023 年 6 月には、お客さまの設備変更や高額な投資を必要とせず導入できる省エネソリューション「 Mys³ (ミース)」をリリースされました。 Mys³  の事業検討は 2018 年からスタートしており、レガシー設備の IoT 化による季節や負荷に合わせた柔軟な運用にニーズがあるとの構想がありました。しかし、事業立ち上げ時から大きな初期投資ができず、AWS やIoT に知見がない事業部の 3 名が中心となり、PoC を開始されました。プロトタイプ構築に必要な知見を補うために、部署や部門を超えたコミュニティ活動を通じてボトムアップ的に知識を習得されました。コスト削減のため、AWS のサーバレス/マネージドサービスを活用する方針で検討を進め、 AWS IoT Core 、 AWS Lambda 、 Amazon QuickSight   を利用した IoT データ可視化のプロトタイプを 5ヶ月、30 万円で構築されました。PoC 後は、コストダウンに加え、セキュリティとアジリティの改善に取組まれました。セキュリティについては AWS の Well-Architected Framework IoT Lens Checklist を利用して改善し、アジリティについては Amazon CodeCatalyst による CI/CD パイプラインの構築により、環境構築やテストの工数の削減を実現されました。このような取組みにより、当初の事業部メンバー中心のまま Mys³ リリースを実現されました。 メンバー熱意と積極的に社員に任せる組織文化がサービスリリースにつながった好例だと感じました。 関西電力送配電の次世代スマートメーターシステムにおけるAWSクラウド活用 –  児山 一郎 様 関西電力送配電株式会社 情報技術部 設備業務システムグループ マネジャー セッションでは、関西電力送配電様にて推進されている AWS クラウドを活用したスマートメーターシステム開発の取組みについてご紹介いただきました。より詳細な内容を公開しておりますので、下記ブログをご確認ください。 ・関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半)   ・関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (後半)   クロージングセッション ～ AWSからのご支援 ～ –  丹羽 勝久 アマゾン ウェブ サービス ジャパン合同会社 エンタープライズソリューション本部 ユーティリティソリューション部 ソリューションアーキテクト クロージングセッションでは、AWS の提供するご支援プログラムについてご説明しました。AWS はお客様の企画・構想段階から検証、実現までの全てのフローにおいてご支援可能なメニューを用意しております。セッションでは、複数のプログラムセットの中から DIP (Digital Innovation Program) によるイノベーション創出支援、プロトタイピングによるお客様と共同した AWS 環境の構築支援のプログラムについてご説明しました。また、クラウド標準環境構築・ガイドライン作成などをご支援可能な有償コンサルティングサービスである AWS Professional Services  についてもご紹介しました。ご興味あれば担当営業までご連絡ください。 おわりに 日本のエネルギー産業は 5D (Digitalization、De-carbonization、De-centralization、De-population、Deregulation) と呼ばれる大きな変化の波にさらされています。今回の Forum を通じて、その多くの変化が「デジタル」に関係してきている事を実感しました。ご登壇いただいたお客様は、エネルギー業界で先進的に AWS を活されております。セッションでは、検討の背景から実現までのプロセスをお話をいただいたことで、参加者の方々がクラウド活用を進める上で必要な具体的な方針をイメージできたのではないでしょうか。今後も、先進的な取組みを発信されたいお客様にイベント登壇いただき、これから取組みを進める皆様への参考としていただけるように活動を続けて参ります。 著者プロフィール 林 隆太郎  (Ryutaro Hayashi) 大手ガス会社にてガススマートメーター、電力トレーディングのシステム開発を経験した後、総合商社にて全社の IT/DX 推進と国内外のエネルギー領域での事業投資、新規事業開発を担当。現在は AWS 電力・ガス業界のソリューションアーキテクトとして業界知識を活かした AWS 活用に携わる。

この記事は、Adrian Hornsby (プリンシパル システム デベロッパー エンジニア) と Marcia Villalba (プリンシパル デベロッパー アドボケイト) が執筆しています。 AWS Lambda は 80 を超えるサービスで構成され、連携し、お客様へサーバーレスコンピューティングサービスを提供しています。 内部的には 、これらのサービスの多くは、アベイラビリティーゾーン内でプロビジョニングされた Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上に構築されています。ただし、 AWS Lambda はリージョンサービスです。つまり、顧客はリージョンレベルで Lambda を使用でき、その基盤であるアベイラビリティーゾーンで起きる可能性のある障害に対してレジリエントであるように設計されていることを意味します。 このブログ記事では、Lambda などのリージョンサービスがアベイラビリティーゾーンと静的安定性を活用して  高可用性の目標 を達成する方法について説明し、Lambda チームが AWS Fault Injection Simulator (AWS FIS) を使用してサービスの静的安定性を検証する方法についても説明します。また、FIS、 Amazon CloudWatch 、 Amazon Route 53 Application Recovery Controller (Route 53 ARC) のような AWS のサービスとツールを使用して、Lambda のレジリエンス戦略を実現するソリューションも提供しています。 アベイラビリティーゾーンの役割 アベイラビリティーゾーンは AWS リージョンの物理的に分離された区画で、動作においても障害の発生においても互いに独立するように設計されています。相互に関連する障害を防ぐため、相互に最大 100 km (60マイル) 程度の十分な距離を置いて離れていますが、1 桁ミリ秒の遅延で同期レプリケーションを使用できるほど近い距離にあります。 お客様と AWS サービスは長年にわたりアベイラビリティーゾーンを使用して、可用性が高く、耐障害性があり、スケーラブルなアプリケーションを構築してきました。特に、AWS Lambda、 Amazon DynamoDB 、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon Simple Storage Service (Amazon S3) などの AWS リージョンサービスは、サービスの複数の独立したレプリカを複数のアベイラビリティーゾーンに分散させることで、高い可用性を実現しています。アベイラビリティーゾーンの独立性と冗長性の原則を使用して、そのサービスの全体的な可用性を最大化します。 各レプリカはゾーンレプリカと呼ばれます。この仕組みは、どのレプリカでもいつでも障害が発生する可能性を考慮して設計されています。レプリカに障害が発生した場合は、すべてが再び期待どおりに動作するまで、そのレプリカをシステムから一時的に削除できます。その場合、負荷は残りのゾーンレプリカ間で分散されます。 障害を想定した設計 AWS でサービスを構築する際に学んだ教訓の 1 つ  は、アベイラビリティーゾーンに障害が発生した場合、 コントロールプレーンの操作  による復旧に頼らない方が良いということです。例えば、コントロールプレーンの操作とは、障害の影響を受けないアベイラビリティーゾーンでより多くの容量をプロビジョニングすることです。 この原則は静的安定性と呼ばれ、システムが破壊的なイベントにさらされた場合でも、何も変更せずに元の定常状態 (または動作) を維持できることを表しています。静的に安定したサービスは、復旧プロセスにおける依存関係が少なくなります。 これは、AWS Lambda のようなリージョンサービスの場合、正常なアベイラビリティーゾーンの残りの容量が、障害の可能性があるアベイラビリティーゾーンからのトラフィックをスケールアップすることなく吸収できることを意味します。これは、すべてのアベイラビリティーゾーンでリソースを過剰にプロビジョニングすることを意味します。その余分な容量を事前にプロビジョニングしておくと、Lambda は静的安定性を実現できます。これは、リソースを過剰にプロビジョニングするコストと、サービスの可用性の間のトレードオフです。AWS Lambda はお客様に高い可用性を約束し、 月間稼働率  を 99.95% とすることを約束しているため、そのトレードオフではサービスの可用性を優先しています。 障害に備える方法 アベイラビリティーゾーンの障害に備えることは困難です。なぜなら、問題の事象や規模は大きく変わる可能性があるからです。アベイラビリティーゾーンには、部分的にアクセス可能な場合もあれば、まったくアクセスできない場合もあります。障害の原因には、ファイバー切断、電源の問題、過熱、ハードウェアの誤動作、ネットワークの問題、容量の問題、およびその他の予期しない状況などがあります。そのような状況は起こりますが、めったに起こりません。障害の最も一般的な種類は、不適切なデプロイや不適切な設定です。 これらの障害の中には、推測や再現が難しいものもありますが、一般的な症状としては、接続の中断、遅延の増加、急増するリトライによるトラフィックの増加、CPU とメモリの使用量の増加、I/O の低下などがあります。 AWS では、予期せぬ事態を想定し、障害に備えることを学びました。つまり、システムに障害を注入してアベイラビリティーゾーンの障害の一般的な症状を再現し、システムがどのように反応するかを観察し、改善を実施することになります。さらに、システムに障害を注入することで、モニタリングやアラートにおける潜在的な盲点を明らかにすることができ、チームが復旧までの時間を短縮することに重点を置いて、イベントへの対応を練習して改善する機会にもなります。 Lambda がアベイラビリティーゾーンの障害への対応をテストする方法 アベイラビリティーゾーンの障害に対するレジリエンスを高めるための Lambda のアプローチは、静的安定性と自動化されたシステムに頼ることです。人間は機械よりも問題の検出と軽減に時間がかかります。そのため、Lambda では、サービスがゾーンレプリカ内の問題を検出し、オペレーターの介入なしに数分以内に自動的に修正できるようにする必要があります。この自動修復は、顧客のトラフィックを、影響を受けるアベイラビリティーゾーンから正常なアベイラビリティーゾーンに移すことで行われ、アベイラビリティーゾーン退避と呼ばれます。 そのために、Lambda は障害を検出し、必要に応じてアベイラビリティーゾーンの退避を実行するツールを構築しました。このツールは、さまざまなアベイラビリティーゾーンと EC2 インスタンス間のメトリクスを統計的に比較して、異常のあるアベイラビリティーゾーンを特定します。アベイラビリティーゾーンに問題があることが判明した場合、ツールは異常のあるアベイラビリティーゾーンからの退避を自動的に開始します。この自動化により、最初のアクションまでの時間が 30 分から 3 分未満に短縮されます。 AWS Lambda が AWS FIS を使用する方法 自動化が期待通りに継続的に機能することを確認するために、Lambda では実稼働前の環境でのアベイラビリティーゾーンの障害テストなど、さまざまなテストを実施しています。これらのテストの主な目的は、アベイラビリティーゾーンに障害が発生してもサービスが静的に安定していることを確認し、アベイラビリティーゾーンからの退避を正常に開始できることを確認することです。自動テストの利点は、チームが定期的にテストを繰り返すことができるため、特別なスキルがなくても済むことです。ワンクリックでテストを開始できます。 これらのテストでは、Lambda は AWS FIS を使用して大規模な EC2 インスタンス群に障害を発生させます。AWS FIS を使用して、 AWS System Manager (SSM) エージェントとリソースフィルターとの連携により、特定のアベイラビリティーゾーンにある EC2 インスタンス群をターゲットにします。これは、CPU やメモリの枯渇などのリソース障害や、パケット遅延、損失、ドロップなどのネットワーク障害を挿入できる汎用性の高いアプローチです。 これらの症状はアプリケーションやネットワークのパフォーマンスに重大な影響を与える可能性があるため、パケット損失や遅延を発生させることは非常に重要です。実際、レイテンシーと損失は、たとえ少量であっても非効率性を生み出し、アプリケーションを最高のパフォーマンスで実行できなくなる可能性があります。Lambda にとって、レイテンシーの増加や損失が顧客に影響を与える前に検出できることは非常に重要です。 アベイラビリティーゾーンの障害からアプリケーションを迅速に復旧する方法 Lambda と同様のソリューションを構築して、ゾーン障害からアプリケーションを迅速に回復できます。ソリューションには、障害が発生したアベイラビリティーゾーンから退避させるメカニズム、ゾーンレプリカに障害が発生したことを検出できる監視システム、およびシステムの静的安定性をテストする方法が必要です。AWS は、このソリューションを構築して Lambda のレジリエンス戦略を実現するのに役立つ多くのツールとサービスを提供しています。 アベイラビリティーゾーン退避には、Route 53 ARC の新しい ゾーンシフト機能 を使用できます。ゾーンシフトにより、 Elastic Load Balancing を使用するアプリケーションをアベイラビリティーゾーンから退避させることができます。ゾーンレプリカに障害があるか、異常があることが分かった場合は、問題が修正されるまでの間、ゾーンシフトを使用してアベイラビリティーゾーンから一定期間退避できます。 ゾーンシフトを実行するには、ゾーンレプリカが正常でないことを検出する必要があります。アプリケーションは、アベイラビリティーゾーンごとにヘルスシグナルを提供する必要があります。この信号をキャプチャする一般的な方法は 2 つあります。まず、レスポンスタイムや HTTP ステータスコードなど、アプリケーションの致命的なエラーの追跡に役立つメトリクスを受信してチェックできます。または、能動的にシンセティックモニタリングを使用することもできます。これにより、本番アプリケーションに対して合成リクエストを作成し、顧客体験をより包括的に把握できます。 Amazon CloudWatch Synthetics  にはカナリアが用意されています。カナリアはスケジュールに従って実行され、アプリケーションのエンドポイントと API に対して合成リクエストを実行するスクリプトです。カナリアは顧客と同じ行動をとり、顧客体験を継続的に検証します。アプリケーションのゾーンレプリカごとにカナリアを作成し、結果を個別に監視できます。 この情報があれば、いずれかのレプリカで顧客体験が低下した場合でも、ゾーンシフトを使用してアベイラビリティーゾーン退避を開始し、障害の原因を見つけて修正する間、ユーザーへの悪影響を最小限に抑えることができます。 障害から正常に回復できるようにするには、事前にソリューションをテストする必要があります。テストなしでは、これは単なる仮説に過ぎません。アベイラビリティーゾーン内の問題などの破壊的イベントを処理するシステムの能力に関する仮説を証明または反証するには、FIS を使用できます。 FIS を使用すると、アベイラビリティーゾーンなど、同じ障害ドメイン内の複数のリソースに同時に障害を注入できます。FISは現在、EC2、 Amazon Elastic Kubernetes Service (Amazon EKS) 、  Amazon Elastic Container Service (Amazon ECS )、  Amazon Relational Database Service (Amazon RDS) 、AWSネットワーク、CloudWatchなど、いくつかのAWSサービスと統合されています。 アベイラビリティーゾーンの障害に対するワークロードの耐障害性をテストする一般的な使用例としては、特定のアベイラビリティーゾーン内のすべてのコンピューティングリソースとデータベースを停止する、レイテンシーまたはパケットロスを発生させる、特定のアベイラビリティーゾーンのコンピュートリソースのリソース消費量 (CPU、メモリ、I/O) を増やす、アベイラビリティーゾーン内またはアベイラビリティーゾーン間のネットワーク通信に影響を与えるなどがあります。 単一のアベイラビリティーゾーンでアプリケーション障害から迅速に復旧し、AWS FIS でテストする方法の詳細とステップバイステップの例については、 このブログ記事 をお読みください。 結論 本記事では、静的安定性について解説しました。静的安定性は、Lambda などの AWS サービスがレジリエントなリージョンサービスを構築するために使用するメカニズムです。また、AWS が顧客と同じサービスとインフラストラクチャをどのように活用しているかについても解説しました。Lambda が複数のアベイラビリティーゾーンと AWS FIS などのサービスを使用して可用性の高いサービスを構築し、予期しない障害からの復旧時間を人間の介入なしにわずか数分に短縮する方法を示しました。最後に、お客様のアプリケーションで、Lambda のレジリエンス戦略と同等の内容を実現するためのアプリケーション例も示しました。 AWS FIS の詳細については、 多数のチュートリアル と ワークショップ  をご覧ください。 その他のサーバーレス学習リソースについては、  Serverless Land をご覧ください。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

教育業界は、ここ数年で革新的な技術変化を遂げました。まず、パンデミックにより e ラーニングソリューションが増加しました。教師と生徒がコミュニケーション、教育、学習、および学術情報の管理にデジタルプラットフォームを採用したためです。これらのソリューションは、世界中の生徒たちがインターネットを通じて質の高い教育を受けることができることを表しています。デジタルプラットフォームの使いやすさとアクセスの容易さにより、教師と生徒の考え方が変化し、オフラインの授業とともにオンライン学習を引き続き活用するようになりました。 さらに最近では、人工知能（AI）の分野におけるイノベーション、つまり生成系 AI が、教育者や教育技術企業（EdTech）に対し、このテクノロジーがどのように生徒の成功を促進し、教職員の生産性を向上させるかといったことを再考する新たな機会をもたらしています。 このブログ記事では、自動化・個別最適化された教育用ツールを用いて生徒の体験を支援する目的で、 Amazon Web Services (AWS) で録画済みの授業動画を使った複数の生成系 AI ソリューションの作り方を学べます。例としては、動画からテキストへの文字起こし、授業の要約や宿題・問題の生成、教材の地域ごとの言語への翻訳、問題解決のために個別最適化された授業用チャットボットの作成などがあります。 ソリューションの概要: 授業コンテンツを用いた教育向け生成系 AI ソリューションの構築 Amazon Interactive Video Service ( Amazon IVS ) などのライブストリーミングビデオサービスを使用すると、教師はリモートの生徒と教室での授業をリアルタイムで共有できます。ライブストリーミングを使えば、遠隔地の生徒は、対面での環境と同じように質問をしたり、教師とやり取りしたりできます。その後、教育者はストリーミングされた授業内容 を録画してテキストに変換することができ、こうした文字起こしは、生成系 AI ソリューションにおいてさまざまな用途で利用可能です。 このブログ記事では、 AWS 上の AI サービス を使ったハイレベルのソリューションアーキテクチャと、事前トレーニング済みの大規模言語モデル (LLM) について説明します。こうしたモデルは、Amazon や主要な AI スタートアップが開発した基盤モデル (FM) を API 経由で利用できるフルマネージドサービスの Amazon Bedrock や、機械学習 (ML) への取り組みを加速させるのに役立つ ML ハブである Amazon SageMaker JumpStart から利用可能です。 ソリューションの基礎: 授業のストリーミング、録画、文字起こし 教師や生徒を支援する上で AI ソリューションが授業内容を扱えるようにするために、その内容を録画し文字起こしをする必要があります。Amazon IVS を使用すると、教師は実際の教室から授業を行い、その授業をリモートで同時に視聴可能にできます。 Amazon IVS はフルマネージドのライブストリーミングソリューションです。コンテンツを Amazon IVS にストリーミングするだけで、世界中のあらゆる視聴者が低遅延のライブ動画を閲覧できるようになります。Amazon IVS は、 Twitch と同じテクノロジーを使用して、ライブコンテンツの取り込み、トランスコーディング、パッケージ化、配信を行います。 ライブビデオを Amazon Simple Storage Service ( Amazon S3 ) バケットに保存するように Amazon IVS を設定できます。ビデオストリームはビデオファイルとして保存され、Amazon Transcribe に送信することで音声をテキストに変換できます。 Amazon Transcribe では授業の音声や動画を、授業中リアルタイムにあるいは授業後にまとめて、テキストに変換できます。 その後、授業の文字起こしも Amazon S3 に保存でき、それを Amazon Bedrock や Amazon SageMaker JumpStart を使用するさまざまな生成系 AI のユースケースに利用できます。 さらに、生徒の宿題のような他のテキストベースのコンテンツも Amazon S3 に保存し、授業の文字起こしと一緒に使用することで、より生徒にとってパーソナライズされた体験を構築できます。 図 1.このブログ記事の基礎となるソリューションのアーキテクチャ図。まず、教育者は Amazon IVS を使用してコンテンツをストリーミングおよび録画し、生徒がリモートで視聴できるようにします。その後、録画した授業ビデオが Amazon Transcribe で処理され、ビデオ内の音声が自動的にテキストに変換されます。次に、Amazon Transcribe は 文字起こしを Amazon S3 バケットにアップロードします。Amazon Bedrock や Amazon SageMaker などの AI サービスでは、文字起こしを様々な目的で活用できます。例えば、SMS、電子メール、ソーシャルメディアを通じて学習者にメッセージを送信するコンテンツの生成、授業の概要の生成、授業教材に基づいて生徒の質問に回答できるパーソナライズされたチャットボットの作成、関連画像の生成、生徒の評価などが可能です。Amazon Translate では、Amazon S3 から取得した文字起こしを地域ごとの言語に翻訳できます。また Amazon Kendra を使えば、生徒が授業コンテンツを効果的に検索して利用する検索ソリューションを作成できます。 授業の要約と検索可能な授業内容インデックスの生成 一度授業の文字起こしを行えば、教育者は授業の要約生成ソリューションを構築できます。生徒は授業の要約を短時間で読むことができ、授業を通して教わる重要な概念を学べます。 図 2 は、AWS におけるこのモデルのハイレベルなアーキテクチャの構築方法を示しています。AI ソリューションでは、 Amazon Bedrock や Amazon SageMaker JumpStart で利用可能なテキスト要約ができるさまざまなモデルを使用して、授業内容全体をほんの数段落に要約します。要約されたテキストは、深層学習により人間の自然な音声を合成できるサービスである Amazon Polly を使用して音声に変換され、生徒は授業の要約を聞くこともできます。コンテンツをさまざまな地域の生徒にローカライズするために、元の文字起こしと要約のテキストを Amazon Translate で サポートしている言語 に翻訳できます。 教育者は、生徒が特定の授業コンテンツにすばやくアクセスできるように、録画した授業や文字起こし、要約を章立ててまとめることもできます。その後、教育者は ML を活用したインテリジェントな検索サービスである Amazon Kendra を使用して、授業内容の 検索可能なインデックスを作成 でき、生徒は自分が必要とする内容を検索できるようになります。Amazon Kendra で構築されたアプリケーションでは、生徒は自然言語で質問し、教材から非常に正確な回答を得ることができます。たとえば、化学の授業を受講している生徒が、Amazon Kendra に保存されている授業内容を検索して、「酸とは何か？」といった質問をすることができます。Amazon Kendra は授業の文字起こしから利用可能なコンテンツを取得します。統合された大規模言語モデル (LLM) は内容を要約し、自然言語として回答を示します。 図 2. 授業の文字起こしから授業の要約を生成するアーキテクチャ図。文字起こしが Amazon S3 バケットにアップロードされると、Amazon Bedrock または Amazon SageMaker JumpStart が事前に訓練されたモデルを使用して、文字起こしされたコンテンツを要約します。この要約されたコンテンツを、Amazon Translate に送信すれば複数の言語に翻訳できたり、Amazon Polly に送信すれば要約を音声に変換できたりします。 また Amazon Kendra に送信すれば、すべての授業内容をインテリジェントに検索できるインデックスを作成できます。 問題や学習資料の作成 教師は、文字起こしした授業内容に生成系 AI を用いることで、特定の授業や授業に基づいた問題と解答の組み合わせを素早く生成できます。教育者はこれらの問題を使って、宿題やフラッシュカード、小テスト、試験問題の準備を行えます。 Amazon Bedrock と Amazon SageMaker JumpStart で利用できるテキスト生成モデルでは、文字起こしした授業内容からこのタイプの教材を生成できます。その後、Amazon Kendra を使って、こうした評価や学習のための教材をインデックス化し検索できるようにできます。 図 3. 問題生成のアーキテクチャ図。主要なコンポーネントは Amazon Bedrock や Amazon SageMaker JumpStart です。 パーソナライズされた授業用チャットボットを作成して、教材に関する質問に回答する 授業の文脈における生徒からの質問に自動的に回答できるチャットボットを作成できれば、生徒の体験向上につながります。図 4 は、このソリューションを AWS で設計する方法を表したハイレベルなアーキテクチャを示しています。 Amazon Lex は、高度な自然言語モデルを備えたフルマネージド AI サービスで、アプリケーション (チャットボットなど) の会話型インターフェイスを設計、構築、テスト、デプロイできます。その後、生徒は音声またはテキストでこのチャットボットとやり取りできます。 生徒が授業用チャットボットに授業に関する質問をすると、Amazon Lex は Amazon Kendra から回答を取得します。Amazon Kendra はテキスト生成 LLM にコンテキストを与え、自然言語でレスポンスが返されます。その後、Amazon Lex はこのレスポンスをユーザーに返します。外部のデータベースからコンテキスト情報を取得して LLM の知識を拡張するこのプロセスは、検索拡張生成（RAG）と呼ばれます。Amazon Lex が、 Amazon Kendra インデックス用の LangChain リトリーバー を用いるような AWS Lambda 関数を呼び出すことで、RAG ワークフローを実装してます。ここで LangChain は、LLM を外部の情報源と統合できるようにするフレームワークです。 さらに、授業の音声やビデオの中で特定の概念が説明されている正確な時間を提供することでも生徒の学習体験はより良くなります。GitHub で利用可能な MediaSearch ソリューション を使用すると、Amazon Kendra 内でオーディオコンテンツとビデオコンテンツを検索できるようになります。 図 4. Amazon Kendra でインデックス化された質問および回答を使用した、自動で疑問を解決するソリューションのアーキテクチャ図。主なコンポーネントは、Amazon Bedrock あるいは Amazon SageMaker JumpStart、また、Amazon Kendra と Amazon Lexです。 生徒の試験などの自動採点 AI ソリューションは生徒の試験を採点するのにも役立ちます。これにより、教師は日々の採点に費やす時間を減らし、複雑なトピックや生徒への個人的な指導に専念できます。さらに、生徒は自分の解答に対して即座にフィードバックを得ることができるため、授業の理解と進度が早まります。 図 5 は、このソリューションのハイレベルなアーキテクチャの例を示しています。試験の解答を確認するために、生徒の解答と、 Amazon DynamoDB などのデータベースから取得した正解として期待される解答がテキストプロンプトとしてテキスト生成の LLM に送信されます。 Amazon Bedrock や Amazon SageMaker JumpStart で利用できる LLM に、生徒の解答と期待される解答を照らし合わせてチェックするよう依頼します。このアーキテクチャを基礎とすることで、生徒が自身の解答が正しいのか、部分的に正しいのか、あるいは間違えているのかを説明付きですばやく判断できるようなシステムを設計できます。また、このアーキテクチャは、教師が生徒たちの解答を最初にまとめて自動採点できるようにも拡張可能です。 図 5. 生徒の解答採点のアーキテクチャ図。主なコンポーネントは Amazon Bedrock や Amazon SageMaker JumpStart 、Amazon Lex です。 画像を生成して情報をより明確で説得力のあるものにする 画像生成モデルを使用すると、教師は自分の持つイメージを魅力的な絵に変え、ストーリーを語るように概念を説明できます。たとえば、拡散モデルを使用して授業の文字起こしからイラストを生成し、概念を明確にする、あるいは単にコンテンツをより楽しく魅力的なものにすることができます。元となるテキストに加えて、サンプルイメージも組み合わせることで stability.ai の Stable Diffusion モデルを使い目的通りの画像を生成できます。これらのモデルは Amazon Bedrock や Amazon SageMaker JumpStart ですぐに利用可能です。 図 6. 画像生成のアーキテクチャ図。主なコンポーネントは Amazon Bedrock や Amazon SageMaker JumpStart です。 まとめ 授業の要約、採点、生徒の質疑への回答（Q&A）、テキストや画像の生成は、教育者にとって時間を要する作業です。AWS で利用できる AI ソリューションでは、新しい生成系 AI の機能を使ってこれらのタスクをシンプルに実行できます。そして教育者は面倒な作業に割く時間を減らし、生徒の体験を豊かにすることにもっと集中できます。 AWS における生成系 AI 使用に関する詳細については、「 AWS で生成系 AI を使用した構築のための新ツールを発表 」を参照してください。 Sarat Guttikonda Sarat Guttikonda は、Amazon Web Services (AWS) のグローバルな公共部門のプリンシパルソリューションアーキテクトです。Sarat は人工知能 (AI) と機械学習 (ML) の愛好家であり、ビジネスの俊敏性を犠牲にすることなく、お客様のイノベーションと変革を推進したいと考えています。余暇には、息子と一緒にレゴを作ったり、卓球をしたりするのが大好きです。 Paul Saxman Paul Saxman は、クラウドでの次世代の計算とストレージの運用において、世界中の教育機関や学術研究機関を支援するグローバルな技術プログラムを率先して主導しています。生物医学と臨床情報学の研究とシステム開発における以前のキャリアを経て、クラウドと AI/ML テクノロジーの運用を通じて科学と教育を発展させることを目標に、Amazon Web Services (AWS) に入社しました。 本ブログはソリューションアーキテクトの田村健祐が翻訳しました。原文は こちら です。

この記事は、 Patterns for updating Amazon OpenSearch Service index settings and mappings を翻訳したものです。 Amazon OpenSearch Service は、リアルタイムのアプリケーションモニタリング、ログ分析、大規模なウェブサイト検索など、幅広いユースケースで利用されています。ドメインが古くなり、コンシューマが追加されると、追加のストレージとコンピュートニーズを処理するためにドメインの構成を再評価し、変更する必要があります。このような変更を行う際には、ダウンタイムとパフォーマンスへの影響を最小限に抑えたいものです。 インデックスのメンテナンスを行うためのウィンドウを設けずにインデックス設定を変更したり、OpenSearch Service ドメインの全体的なパフォーマンスに影響を与えることなくインデックス設定を変更するためのベスト・プラクティスとパターンに関するガイダンスをお客様から求められます。これは 2 部構成の第 1 部で、データのプロデューサおよびコンシューマがアクティブなまま、ダウンタイムをほとんど発生させずに OpenSearch Service のインデックスに設定変更を行う方法を紹介します。 OpenSearch Service におけるインデックス OpenSearch Service では、データを検索する前に インデックスを作成 する必要があります。インデックスとは、検索エンジンが高速に検索できるようにデータを整理する方法です。こうしてできた構造をインデックスと呼びます。インデックスに対して行われるすべての操作は、 インデックス APIs を介して行われます。また、各インデックスには インデックスマッピング が含まれており、インデックス内のフィールド名とデータ型を定義している。データ作成者はインデックスに新しいフィールドとデータ型を追加することができます。インデックスのマッピングは、インデックスのライフサイクルを通して変更することはできません。 OpenSearch Service のインデックスには 2 種類の設定があり、ワークロードの状態が変化すると定期的に調整が必要になります: 動的 – インデックス上でいつでも変更可能な設定 静的 – インデックスの作成時にのみ定義でき、インデックスのライフサイクルを通じて変更できない設定 動的インデックスの設定は、 設定更新 API を使用していつでも変更することができます。OpenSearch Service ドメインが動的インデックス設定に対して指示された操作を実行している間、インデックスはダウンタイムを必要としません。ほとんどの動的インデックス設定を変更しても、ドメインリソースの全体的な利用に影響を与えるバックグラウンドタスクは発生しません。しかし、 index.number_of_replicas や index.auto_expand_replicas によるレプリカ数の増加など、ドメインの設定によっては、ドメインがレプリカを追加している間、一時的にリソースの使用率が増加することがあります。冗長性のために少なくとも1つのレプリカを維持し、高いクエリスループットを使用する場合は複数のレプリカを維持することを推奨します。 マッピングやシャード数などの静的インデックス設定は、インデックス作成時に定義され、インデックスのライフサイクルを通じて変更することはできません。この投稿では、シャード数の変更やインデックスマッピングの更新パターンなど、静的インデックス設定を扱うためのパターンとベストプラクティスに焦点を当てます。 この投稿で取り上げるすべての操作と手順は、 OpenSearch REST API に直接、または OpenSearch Dashboards の Dev Tools を介して発行されます。 どのようなユースケースでもそうですが、考慮すべき解決策と制約のスペクトルがあります。私たちは、いくつかのシンプルな基本パターンから始めて、より多くの運用上の制約を持つユースケースや大規模なデータセットを扱うことを考慮しながら、それらを構築していきます。 ソリューション概要 OpenSearch Service のデフォルトのシャーディング戦略は 5:1 で、各インデックスは 5 つのプライマリシャードに分割されます。各インデックス内では、各プライマリシャードに対するレプリカも保持します。OpenSearch Service は自動的にプライマリシャードとレプリカシャードを別々のデータノードに割り当てます。 既存インデックスのプライマリシャード数を増やすことはできません。つまり、プライマリシャード数を増やしたい場合はインデックスを再作成する必要があります。 _reindex 操作は、シャードと マッピング設定 を更新して目的とするインデックスを作成するのに適しています。 _reindex 操作はリソースを消費します。 number_of_replicas を 0 に設定してインデックスのレプリカを無効にし、再インデックス処理が完了したらレプリカを再度有効にすることをお勧めします。もし S3 など他のデータストアにデータがある場合、更新を一時停止し、ソースからインデックスを再作成するのが最もシンプルな方法です。しかし、それは常に可能というわけではありません。この投稿では、シャード数のような静的なインデックス設定も更新できるようにするいくつかの方法を紹介します。 _reindex 操作を使用する主な利点の1つは、ソースインデックスを読み取り専用モードにする必要がないことです。（データプロデューサは、再インデックス中もデータを書き込みを続けることができます）また、 _reindex 操作は、部分的なドキュメントの再処理、 変換 、再インデックス、さらには複数のインデックスからのドキュメントの選択的な結合を可能にします。 _reindex 操作では、クエリで選択したドキュメントのすべてまたは一部を別のインデックスにコピーすることができます。 最も基本的な形式では、 _reindex 操作は、コピー元とコピー先のインデックス、および設定パラメータを指定する必要があります。 以下は、reindex API がサポートするユースケースの一部です: すべてのドキュメントの再インデックス クラスタ間でデータを転送する際にリモートクラスタからの再インデックス 検索クエリにマッチする一部のドキュメントの再インデックス 1つ以上のインデックスを結合 再インデックス作成中の文書の変換 シャード数を増やすには、新しいインデックスを作成し、 number_of_shards を希望のプライマリシャード数に設定し、 number_of_replicas を0に設定し、要件に基づいて新しいインデックス・マッピングを更新し、reindex API 操作を実行します。 _reindex 操作が完了したら、作成したインデックスの設定の number_of_replicas を必要なレプリカシャード数に更新することをお勧めします。 下のセクションでは、reindex API 操作のウォークスルーを提供する。この投稿で紹介するパターンと手順は Amazon OpenSearch Service バージョン 1.3 で検証されていることに注意してください。 前提条件 _reindex 操作はソースドキュメントなしでは使用できないため、インデックス作成時に渡されたドキュメントがインデックスに格納されている必要があります。（マッピングの "_source" 設定が "enabled":true （デフォルト）に設定されている必要があります。） 目的のマッピング（フィールドやデータ型）で出力先インデックスを作成します。デモンストレーションのために、ソースインデックスには ratings という long として定義されたフィールドがあり、同じフィールドがディスティネーションインデックスでは float データ型を使用するようにします : GET /source_index_name/mappings { "source_index_name": { "mappings" : { "properties" : { "ratings " : { "type" : "long" }, … } } } } PUT /destination_index_name { "settings": { "index": { "number_of_shards": <DESIRED_NUMBER_OF_PRIMARY_SHARDS>, "number_of_replicas": 0 } }, "mappings": { "properties" : { "ratings" : { "type" : "float" }, … } } } 各 Hot 層のデータノードに、新しいインデックスのプライマリシャードと、構成によってはレプリカシャードを格納するのに十分なディスク容量があることを確認します。ディスク容量が不足している場合は、OpenSearch Service ドメインで 更新操作 を行い、必要なストレージ容量を追加します。 ストレージ要件 によっては、OpenSearch Service ドメインを別のインスタンスタイプに移行する必要があるかもしれません。ノードには、各インスタンスタイプにマウントできる EBS ボリュームサイズ に制約があるからです。次の操作を実行して、使用可能なディスク容量を確認します : GET _cat/allocation?v 次のスクリーンショットは出力を示しています。 ホットストレージ層のノードの disk.avail メトリクスをチェックし、使用可能なディスク容量を確認します。 reindex API 操作の利用 _reindex オペレーションは、実行開始時にインデックスをスナップショットし、スナップショットに対して処理を実行することで、ソースインデックスへの影響を最小限に抑えます。ソースインデックスは引き続きデータの問い合わせや処理に使用できます。_reindex 処理は同期でも非同期でも実行できますが、非同期での実行を推奨します。 _task 、 _cancel 、 _rethrottle 操作をそれぞれ使用することで、 _reindex 操作の進捗を監視したり、実行をキャンセルしたり、実行を絞ったりすることができます。 _reindex 操作は、読み取り専用モードのソースインデックスを必要としないので、クエリとインデックス更新操作は自由に続けることができます。 以下のコマンドで reindex API を使用してください： POST _reindex?wait_for_completion=false { "source": { "index": "source_index_name" }, "dest": { "index": "destination_index_name", "op_type" : "index" } } _reindex API 操作の一部であるソースインデックスは、 ドキュメントの一部を再インデックス してインデックス先に格納するためのクエリで補足することができます。インデックス再作成処理の進行状況は、 tasks API 操作で確認することが監視することができます : GET _tasks _reindex 操作は、 _rethrottle APIまたはパラメータとして渡される設定によってスロットルできます。また、 _cancel 操作でタスクをキャンセルできます : POST _tasks/TASK_ID/_cancel 次のスクリーンショットは、 source_index_name から destination_index_name への再インデックスのための _reindex 操作の出力を示しています。 操作が完了すると、コンシューマとプロデューサが接続しているソースインデックス、もしくはエイリアスの向き先をディスティネーションインデックスに切り替える必要があり、最初の _reindex 操作が実行されている間にインデックス元で実行された作成、更新、または削除操作に追いつくために、同じ _reindex 操作を再度実行する必要があります。 _reindex 操作はインデックスのスナップショット上で実行されているため、このステップが必要です。この時点で、欠落しているドキュメントやバージョン外のドキュメントを再調整ために、 “op_type”:”create” で _reindex 操作を実行する必要があります。以下のAPIコマンドを参照してください : POST _reindex?wait_for_completion=false { "conflicts":"proceed", "source": { "index": "source_index_name" }, "dest": { "index": "destination_index_name", "op_type" : "create" } } 操作が完了し、インデックス先のデータ整合性が確認されたら、ソースインデックスを削除してディスク領域を取り戻すことができます。 Split index APIを使用してインデックスシャード数を増やす split index APIとshrink index APIは多くのユースケースをカバーし、ドメイン内のリソース使用率を低く抑えられます。しかし、これらのAPIは書き込み操作に対するインデックスを停止する必要があり、マッピング設定の変更を必要とするユースケースには対応していません。 OpenSearch Serviceでは、 number_of_shards インデックス設定は変更不可であり、インデックス作成時に定義されます。しかし、この設定は変更不可ですが、明示的にインデックスを作成し直さなくても、インデックスのシャード数を増減できるパターンがいくつかあります。書き込み操作を中断できる環境では、 split index API を使用してインデックスシャード数を増やすこともできます。split index API は、再インデックスをすることなく、異なるシャード設定で新しいインデックスを作成する簡便な方法を提供します。split index API は、読み込み専用インデックスをもとに新しいインデックスを作成します。 OpenSearch Service では、 index alias は1つ以上のインデックスを指す仮想的なインデックス名です。アプリケーションでエイリアスを使用してインデックスを参照すると、 インデックス名の変更を避けることができます。インデックスエイリアスは、インデックス API の分割操作が完了した後に、 コンシューマやプロデューサに新しいインデックスを指し示すために使用されます。 ユースケースの大半は、データの増加により既存のインデックスのシャード数を増やすことですが、 既存のインデックスのシャード数を減らす必要がある場合もあります。このようなケースは、実際のインデックスサイズがインデックス作成時に想定していたサイズよりも小さく、 OpenSearch Service の運用上のベストプラクティス における シャード戦略 に合わせたい場合に発生することがあります。インデックスのシャード数を減らす必要がある場合、 shrink index API を使用してこのタスクを達成することができます。 結論 この投稿では、OpenSearch Service の 静的インデックス設定 やマッピングを変更する際に、インデックスのダウンタイムをほとんど、あるいはまったく必要としないデータの 再インデックス のベストプラクティスについて検討しました。また、インデックスを読み取り専用状態にすることができるユースケースのために、プライマリインデックスのシャード数を変更するための split index および shrink index API の使用についても説明しました。 次回の投稿では、OpenSearch Service ドメインに対する負荷とリソースの使用を軽減するリモートインデックスのパターンを探ります。 翻訳は Solutions Architect 川岸が担当しました。

はじめに コンタクトセンターではエージェントのパフォーマンスを把握するために労力をかけています。これは、大量のインタラクションと、顧客とのコミュニケーションに使用されるさまざまなチャネルに起因しています。更に、パフォーマンス分析のために関連するデータポイントを抽出・収集する事は難しい作業です。幸い、 Amazon Connect Contact Lens には、評価フォームを使用したエージェントのパフォーマンス評価機能があります。コンタクトセンターのマネージャーは、トークスクリプトの遵守や機密データ収集の遵守などの特定の基準に基づき、評価フォームを作成します。Contact Lens の機械学習を活用した会話分析により、これらの評価フォームにスコアを付けて、エージェントのパフォーマンスを包括的に把握する事ができます。 更に、Contact Lens を使用すると、組織は 評価フォームの出力 データと コンタクトレコード （以前のコンタクト追跡レコード）をデータレイクにストリーミングできるため、高度な分析が可能になります。この分析手法により、マネージャーはエージェントのパフォーマンス傾向に関するインサイトを確認し、データドリブンな意思決定を行い、カスタマーサービスを向上させる事ができます。FrontDoor や Ameriflex のような当社のお客様では、品質保証の業務効率を向上させることで評価機能のメリットを享受しています。パートナーの Cognizant は、エージェントのパフォーマンスについてより多くのインサイトを取得し、トレーニングの機会を特定し、彼らのユーザー企業がコンタクトセンターの運用を強化できるように支援します。 このブログでは、Amazon Connect からコンタクトレコードをストリーミングする方法、評価フォームデータを処理する方法、それらのデータを関連付ける方法、そして、 Amazon QuickSight を使用して分析結果を視覚化する方法を学習します。これらの強力な機能を使用することで、カスタマーサービス業務を最適化し、カスタマーエクスペリエンスを向上させることができます。 概要 図1：ハイレベルなアーキテクチャー図 上記のアーキテクチャーにより、Amazon Kinesis Streams と Kinesis Data Firehose を使用した Amazon Connect Contact Center からのデータのリアルタイム処理が可能になり、AWS Glue Data Catalog、Amazon Athena、Amazon QuickSight を使用したデータのクエリと視覚化が可能になります。 Amazon Kinesis Streams は、Amazon Connect コンタクトレコード (CTR) を Amazon Simple Storage Service (S3) バケットに送信するために使用します。 コンタクトレコードからコンタクトセンターで発生するコンタクトのイベント情報を取得する事ができます。 Amazon Connect は、CTR を少なくとも 1 回配信する事を保証しています。また、最初に CTR が配信されてから新しいイベント情報が発生する場合は、同じコンタクトに対して追加の CTR を配信する場合があります。 Amazon Connect のパフォーマンス評価機能が有効になっている場合、評価が完了すると、評価フォームの出力ファイルが同じ S3 バケットに直接配信されます。 この出力ファイルの配信により Amazon EventBridge イベントがトリガーされ、Amazon Kinesis Data Firehose にイベント情報が送信されます。 Kinesis Data Firehose は、指定した間隔でこれらのイベントを収集し、 AWS Lambda を使用して S3 バケットから各ファイルのコンテンツを取得します。 Kinesis Data Firehose は、AWS Glue カタログで定義されたスキーマを使用して、これらのファイルから取得したレコードを Parquet ファイル に圧縮し、S3 バケットに保存します。 AWS Glue Data Catalog には、CTR と評価フォーム出力ファイルのテーブル定義があります。 Contact Id フィールドを使用してこれらを関連付けることができ、Amazon Athena を使用してクエリーを実行する事ができます。 Amazon QuickSight は視覚化の目的で使用されます。 前提条件 このブログ投稿で紹介されているソリューションを進めるには、次の AWS のサービスと機能について理解しておく必要があります。 Amazon Connect Amazon EventBridge AWS Lambda Amazon Simple Storage Service (S3) AWS CloudFormation Amazon Kinesis Amazon Athena AWS Glue AWS Identity and Access Management (IAM) Amazon Connect コンソールにて、 セキュリティプロファイル の[ 分析および最適化 ]セクションにある以下のアクセス権限を割り当てる事で、Amazon Connect のユーザーが評価フォームを作成、定義し、アクセスできるようになります。 評価フォーム – 評価の実行 評価フォーム – フォーム定義の管理 更に、 AWS Cloud Development Kit (CDK) データパイプラインをデプロイするには、以下の前提条件を満たす必要があります。 AWS アカウント Administrator 権限が割り当てられた AWS IAM ユーザー Contact Lens および 評価機能 が有効化された Amazon Connect インスタンス Node (v16) と NPM (v8.5) がインストール、設定された端末 AWS Command-Line Interface (CLI) (v2) がインストール、設定された端末 AWS CDK (v2) がインストール、設定された端末 本ブログシナリオのデプロイメントでは、6 つの S3 バケットが作成されます。 全てのスタータープロジェクトをデプロイするには 12 個の S3 バケットが必要となります。 ウォークスルー このウォークスルーは 2 つのパートから構成されています。 まず、CDK データパイプラインをデプロイします。 次に、CloudFormation Template(CFT) を使用してデプロイする事で、 Amazon QuickSight でダッシュボードを作成します。 データパイプラインをデプロイする データ分析のサンプルプロジェクトは、GitHub https://github.com/aws-samples/amazon-connect-data-analytics-sample から入手できます。 以下の手順は、AWS CDK CLI を使用してソリューションをデプロイする方法です。 Windows デバイスを使用している場合は、 Git Bash ターミナルを使用し、強調表示されている代替のコマンドを使用して下さい。 端末上にソリューションのクローンを作成します。: git clone https://github.com/aws-samples/amazon-connect-data-analytics-sample AWS CLI 設定を確認します。: AWS CDK は AWS CLI のローカル認証情報とリージョンを使用します。 aws configure で意図したリージョンで作業していることを確認してください。 NPM パッケージをインストールします。: ターミナル (Windows では Git Bash) を開き、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 npm run install:all を実行します。 CDK スタックを構成します。 ターミナル (Windows では Git Bash) で、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 このガイドでは、対話モード npm run configure で構成スクリプトを開始します。 このブログに必要な機能を有効にするには、 ctr-stack-enabled、ctr-partitioning-schedule-enabled、ef-stack-enabled、ef-partitioning-schedule-enabled、 および ef-reporting-stack-enabled を true に設定する必要があります。 プロンプトが表示されたら、次のパラメータを入力します。 aws-glue-database-name : Amazon Connect データ分析用のテーブルを保持する AWS Glue データベースの名称を入力します (デフォルトは AmazonConnectDataAnalyticsDB ) ctr-stack-enabled : コンタクト追跡レコード (CTR) スタックを展開するには true に設定します。 ctr-partitioning-schedule-enabled : Amazon EventBridge で CTR パーティショニング ジョブをスケジュールする場合は true に設定します。 ae-stack-enabled : エージェントイベント (AE) スタックをデプロイするには true に設定します。 ae-partitioning-schedule-enabled : Amazon EventBridge で AE パーティショニング ジョブをスケジュールする場合は true に設定します。 cfl-stack-enabled : コンタクトフローログ (CFL) スタックを展開するには true に設定します。 cfl-partitioning-schedule-enabled : Amazon EventBridge で CFL パーティショニング ジョブをスケジュールする場合は true に設定します。 connect-contact-flow-logs-cloudwatch-log-group : Amazon Connect のコンタクトフロー ログが保存される Amazon CloudWatch ロググループを設定します (例: /aws/connect/<your-instance-alias> ) cl-stack-enabled : コンタクト レンズ (CL) スタックを展開するには true に設定します。 connect-contact-lens-s3-bucket-name : Amazon Connect が Contact Lens の出力ファイル (および Amazon Connect 通話録音) を保存する S3 バケットの名称を設定します。 cl-partitioning-schedule-enabled : Amazon EventBridge で CL パーティショニング ジョブをスケジュールする場合は true に設定します。 ef-stack-enabled : true に設定すると、評価フォーム (EF)スタックがデプロイされます。 connect-evaluation-forms-s3-bucket-path : Amazon Connect が評価フォームの出力ファイルを保存する S3 バケット名とプレフィックス ( <your-bucket-name>/connect/<your-instance-alias>/ContactEvaluations )を設定します。 ※末尾のスラッシュは含めません。 ef-partitioning-schedule-enabled : Amazon EventBridge で EF パーティショニング ジョブをスケジュールする場合は、 true に設定します。 ef-reporting-stack-enabled : ビジュアライズを実施する場合は、 true に設定します。 これにより、Amazon 　QuickSight ダッシュボードがデータ ソースとして使用する Amazon Athena ビューがデプロイされます。 CDK スタックをデプロイします。 ターミナル (Windows 上の Git Bash) で、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 新しい環境で開始した場合は、 cdk bootstrap コマンドを使用して CDK をブートストラップします。 npm run cdk:deploy スクリプトを実行します。 Windows デバイスでは、 npm run cdk:deploy:gitbash を使用します。 コンソールコンフィグレーション: 希望するリージョンで   AWS マネジメント コンソール にサインインします。 Amazon Connect インスタンス の S3 バケット (Amazon Connect が Contact Lens 出力ファイルと通話録音を保存するバケット) に移動し、[ プロパティ ] タブを選択します。 [ Amazon EventBridge ] セクションで、[ 編集 ] ボタンを選択し、通知を オン に切り替えます。 Amazon Connect インスタンス にて、[ データ ストリーミング ] の設定を表示し、[ データ ストリーミングを有効化 ] にチェックを入れます。 コンタクトレコード(コンタクト追跡レコード)を取得するために、Kinesis ストリームのリストから CDK スタックによって作成された CTRKinesisStream を選択します。 Amazon Connect インスタンス にて、[ データ ストレージ ] 設定を表示し、[ Contact evaluation s] が有効になっている事を確認します。設定がSDKスタックで指定した[ connect-evaluation-forms-s3-bucket-path ]と一致している事を確認します。 サービスから Amazon Athena にて、メニューから クエリエディター を表示し、[ 設定 ] タブに移動し、[ クエリの結果と暗号化 ] で[ 管理 ]ボタンを押下し、[ クエリ結果の場所 -オプション ]に、バケット名 amazonconnectdataanalyticssample-ar-<account-id>-<region> を設定します。 注: バケット名の「al」は「アクセス ログ」を示すため[ amazonconnectdataanalyticssample-ar-al-<account-id>-<region> ]を選択しないでください。 Athena コンソールの クエリエディター に戻ります。 データベースを[ amazonconnectdataanalyticsdb ]に切り替え、[ ビュー ]セクションにて、各ビュー名の横に表示される3 つのドットをクリックします。 [ クエリを表示/編集 ] を選択し、[ 実行 ] ボタンを選択します。 次の順序でビューを実行します。 connect_ctr_denormalized connect_ef_evaluationquestionanswers_view connect_ef_evaluationsscores_view connect_ef_evaluationsall_view final_connect_ef_evaluationsall_view final_connect_evaluation_ctr_view 評価フォームダッシュボードをデプロイ 希望するリージョンで AWS マネジメント コンソールにサインインします。 Amazon QuickSight のアカウントを作成します (すでに QuickSight アカウントをお持ちの場合は、この手順をスキップしてください) コンソールから Amazon QuickSight サービスに移動します。 [ Sign up for QuickSight ] ボタンを選択します。 エディションを選択し、「 続行 」を選択します。 データパイプラインがデプロイされているのと 同じリージョン を選択します。 アカウント名 と 通知メールアドレス を入力します。 続いて、以下の手順の通り、 Amazon Athena Workgroup の書き込みアクセス許可を有効 にした形で、 Amazon Athena および Amazon S3 出力バケット (特に amazonconnectdataanalyticssample の一部としてデプロイされたすべてのバケット) への access and autodiscovery を許可し、[ 完了 ] を選択します。 注: すでに Amazon QuickSight アカウントをお持ちの場合は、以下の手順に従ってください。 Amazon QuickSight に移動し、右上隅のアイコンをクリックして、[ QuickSight を管理 ]を選択します。 [ セキュリティとアクセス権限 ]をクリックします。 [ QuickSight の AWS のサービスへの アクセス ] で、[ 管理 ]ボタン を選択します。 この CDK データレイク ソリューションによって作成された Amazon Athena と Amazon S3 バケットを選択し、各 S3 バケットおよび Amazon Athena Workgroup の書き込みアクセス許可にチェックを入れて [保存]します。 以下 [ スタックの起動 ] ボタンを押下して、評価フォーム分析ソリューションを希望のリージョンにデプロイします。: 一意の[ スタック名 ]を入力します。 パラメータ AwsGlueDatabaseName にはデフォルト値( AmazonConnectDataAnalyticsDB )を使用するか、データパイプラインのセットアップ中に別の Glue データベース名を選択した場合は一致するように更新して下さい。[ スタックの作成 ]を選択します。 CloudFormation スタックの作成が完了したら、QuickSight コンソールで ユーザーアイコン (右上) を選択してメニューを開き、[ QuickSight を管理 ] を選択します。 管理ページのメニューから、[ アセットの管理 ] > [ ダッシュボード ] の順に選択します。 <stack-name>-EvaluationFormAnalytics_v1 にチェックを入れて、[ 共有 ] を選択します。 必要に応じて、ダッシュボードをさらにカスタマイズするには、[ アセットの管理 ] > [ 分析 ]で <stack-name>-EvaluationFormAnalytics_v1 を共有し、[ アセットの管理 ] > [ データセット ]で <stack-name>-EvaluationFormAnalytics_v1 を共有します。 アセットを共有画面が表示されたら、 ユーザーまたはグループ を入力し、再度 [ 共有 ] を選択します。 テスト手順 リポジトリ から「 contact-flows/SimpleInboundFlow 」コンタクト フローをダウンロードします。 Amazon Connect のコンソールにログインし、「 ルーティング 」>「 フロー 」の順に移動します。 [ フローを作成 ] ボタンを選択します。 フロー デザイナーが表示されたら、画面右上にある下矢印▼を選択し、[ インポート ] を選択します。 SimpleInboundFlow を選択し、Amazon Connect インスタンスにインポートし、[ 公開 ] をします。 Amazon Connect コンソールにて、[ チャネル ] > [ 電話番号 ] の順に移動します。 テストで使用する電話番号に SimpleInboundFlow フローを関連付けます。 Amazon Connect コンソールにて、[ 分析と最適化 ] > [ Contact Lens ] > [ 評価フォー ム] の順に移動し、 評価フォーム を作成します。 詳細については、ドキュメント「 評価フォームの作成 」を参照してください。 Amazon Connect インスタンスにエージェントとしてサインインし、 コンタクトコントロール パネル (CCP) を開きます。 顧客として 電話番号 に電話します。 IVR の分岐メニューでいずれかを選択すると、エージェントにルーティングされます。 CCP で電話に応答し、コンタクトセンターにおける顧客とエージェントのやりとりを真似した短い会話を行ってください。 通話が終了したら、Amazon Connect のナビゲーション ウィンドウで、[ 分析と最適化 ] > [ コンタクトの検索 ] を選択し、先の手順で通話した評価対象のコンタクトを検索します。 [ コンタクト ID ] をクリックして、[ 評価 ] または [ < ] アイコンを選択します。 評価を開始するには、ドロップダウン メニューから評価を選択し、[ 評価の開始 ] を選択します。 評価フォームに記入し、「 送信 」をクリックします。 CTR と EF の両方の S3 の宛先バケットに Kinesis Data Firehose ファイルが作成されたことを確認します。 評価フォームのデータが宛先バケットに表示されるまでに最大 3 分かかる場合があります。 処理されたレコードは、宛先バケット amazonconnectdataanalyticssample-ef-<account-id>-<region> に書き込まれます。 amazonconnectdataanalyticssample-ef-al-<account-id>-<region> に追加の「al」が付いたものは、アクセス ログ バケットを示すことに注意してください。 Amazon Athena クエリエディター に移動します。 「 テーブル 」セクションで、 connect_ef の横にある 3 つのドットを選択し、「 パーティションのロード 」をクリックします。 Amazon Athena は MSCK REPAIR TABLE `connect_ef` を実行して新しいパーティションをロードします。 connect_ctr テーブルに対しても同じ手順を繰り返します。connect_ctr テーブルの横にある 3 つのドットを選択し、[ パーティションのロード ] をクリックします。 注: 通常、パーティショニング プロセスは毎日午前 0 時に実行され、前日のデータが取り込まれます。 結果をすぐに確認するために、データを手動でインポートしています。 Amazon QuickSight のダッシュボードでは、数分で評価フォーム データが表示されます。 QuickSight、ダッシュボード に移動し、 <stack-name>-EvaluationFormAnalytics_v1 を選択します。 サンプルダッシュボードの概要 [ Team ] ビューには、評価フォームの概要が表示されます。 総合評価スコアと平均評価スコアが表示され、ワードクラウドも含まれています。 評価フォームの詳細かつ包括的な分析が必要な場合は、表形式のビューが最適なオプションになります。 このビューには、評価フォームの質問、結果の値、件数の内訳が表示されます。 カスタムフィルターを適用する事で独自のビューを作成できます。 [ Agent ] ビューは、コンタクト センター エージェントに対するハイレベルな分析を提供します。 このビューには、評価フォームのスコアの内訳が含まれており、これによって最もパフォーマンスの高いエージェントや、コーチングが必要な領域を特定する事ができます。 エージェント、キュー、ルーティングプロファイルなどの条件に基づいてフィルターを適用できるため、絞り込んだ検索や、容易に必要な関連データを見つける事が可能です。 [ Evaluator ]ビューには、コンタクト センターの評価者に対するハイレベルな概要が包括的に表示されます。 実行された評価の合計数と各フォームの平均スコアを視覚化した内容が表示されます。 さらに、サンキー図では、どの評価者が各評価フォームを入力したかを強調表示にて視覚的に確認する事ができます。 クリーンアップ このブログによって作成されたリソースを削除するには: CloudFormation テンプレートを削除します。 CloudFormation テンプレートから作成された S3 バケットを空にして削除します。 CloudFormation テンプレートから作成された Glue データベースを削除します。 CDK データ パイプライン ソリューションをアカウントから削除するには、次の手順に従います。 CDK スタックを削除します。 ターミナルで、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 cdk destroy --all を実行します。 AWS System Manager パラメータ ストアからデプロイメント パラメータを削除します。 ターミナルで、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 node configure.js -d を実行します。 まとめ このブログでは、Amazon Kinesis と Amazon EventBridge を使用してコンタクトレコードと評価フォームのデータをストリーミングする方法を学びました。 また、QuickSight ダッシュボードを使用してこのデータを視覚化する方法も示しました。 Amazon Connect のデータソースに関するさらなるインサイトと分析機能については、Amazon Connect Reporting ブログシリーズをご覧ください。 Analyze Amazon Connect Contact Trace Record (CTR) Analyze Amazon Connect Contact Lens Analyze Amazon Connect Chat sentiments Analyze Amazon Connect Chatbot performance Analyze Amazon Connect Agent Event Stream (AES) Automating Amazon QuickSight dashboard creation for analyzing Amazon Connect data Analyze data for Amazon Connect Outbound Campaigns (Contact event Streams) Create Custom Reports for Amazon Connect Cases この記事は Ankur Taunk、 Angela Yu、 Mehmet Demir、 Karletha Paxton によって書かれた Managing Agent Quality using Amazon Connect Contact Lens and Evaluation Capabilities の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。

Amazon Finance Technologies（FinTech）の payment transmission（支払い送信）チームは、請求書の作成から支払が行われるまでのプロセスにおける、Accounts Payable（AP）チームの製品を管理しています。彼らの一連のサービスは、請求書の作成から決済が終わるまで、受け取り側が確実に支払いを受け取れるよう、支払いプロセスの処理を行います。 Amazon Business は、デジタル作家、アプリケーション開発者、小売業者、電力会社、税理士法人など、非常に多様な支払先に送金を行っています。2022年、FinTech の payment transmission チームは、アメリカで使用されている送金ネットワークの一つである ACH や電信送金などの様々な送金オプションを通じて、150カ国、60通貨以上で4,200万件以上の送金をサポートしました。 このブログでは、 Amazon DynamoDB をあらゆるスケールでミリ秒のレイテンシを提供するキーバリュー及びドキュメントデータベースとして使用して、拡張可能で復元力が高いイベント駆動型の送金通知サービスを構築した方法を紹介します。 要件 Amazon での送金の過程にはいくつかのステップがあります。送金先名や金額などの詳細が記載された請求書の作成から始まり、送金先の銀行パートナーを特定し、最終的に金額、国、ビジネスタイプに応じて最適な送金方法を選択します。必要な情報が集まると、送金の指示が銀行パートナーに送信されます。送金が行われたことを銀行パートナーが確認した後、Amazon は送金完了の通知を顧客に送ります。送金完了時にタイムリーに顧客に通知することで、顧客は支払い状況を把握し、カスタマーサービスへの問い合わせを最小限に抑えることができます。決済される量は日によって、また地域によって異なるため、送金完了の通知を正確に行うためには、必要に応じてサービスの拡張ができることが重要でした。 私たちは以下の項目を主要要件をして設定しました。 シームレスなスケーラビリティ 確実な処理と送金通知 効率的なエラー処理 メンテナンスの容易さ スケーリング問題の解決策 堅牢な送金サービスを構築するために、私たちは AWS のコンピューティングとデータベースのテクノロジーを使用しました。 AWS Lambda はサーバーレスでイベント駆動型のコンピューティングサービスで、DynamoDB とネイティブに統合されています。この記事では、データベースを選択する基準と、その機能をどのように使ってシステムを設計したかに焦点を当てて紹介します。 使用するデータベースサービスを決定するために、私たちは2つの主要な要件を特定しました。まず一つ目は、大量の支払いを処理し、お客様へのタイムリーな通知を維持するために、シームレスにスケールできるデータベースであることです。そして二つ目は、送金先のタイプ、トランザクションのタイプ、国など、支払いに影響を与えるさまざまな要因を考慮したスキーマの柔軟性があることです。急速に変化する財務状況の中で、決められたスキーマを維持することは難しいため、すべてのデータ要素を前もって定義しなければならないような、厳格なスキーマでのシステム構築はしたくありませんでした。こうした点を考慮し、私たちは DynamoDB を選択しました。 DynamoDB は、ハイパフォーマンスなアプリケーションを大規模に実行するために設計された、フルマネージド、サーバーレスの key-value NoSQL データベースです。 DynamoDB は、ビルトインのセキュリティ、継続的なバックアップ、自動化されたマルチリージョンでのレプリケーション、インメモリキャッシング、データのインポートとエクスポートツールを提供します。これらの機能により、ビジネスの差別化には繋がらないデータベースの管理や拡張といった作業は無くなり、私たちは顧客向けの送金アプリケーションの構築に集中することができました。 DynamoDB の オンデマンドキャパシティモード は、キャパシティ予測無しで毎秒何千ものリクエストに対応します。また、使用量に応じた従量課金により、最適なパフォーマンスを維持しながらコストを低く抑えることも可能です。 お客様の支払いを可能にするための処理に必要な情報は、銀行パートナーに送信されます。銀行パートナーが送金処理に成功すると、確認メッセージが送信されます。これらのメッセージには、請求書や支払明細などの追加情報が含まれます。これら2つの処理は異なるシステムで動作するため、2つの異なるサービスに分離し、それぞれが同じ再利用可能なパターン（後ほど説明）に従いながら独自のタスクを実行できるようにしました。処理を分離することで、 FinTech はソリューションをシンプルに保つことができ、また、サービスごとに拡張することができます。 私たちのアプリケーションでは、以下の2つのサービスを使用しています： エンリッチメント・サービス – このサービスは、送金成功時に銀行パートナーからの通知を受信し、詳細情報を追加する役割を果たします。 通知サービス – このサービスは、詳細情報が追加されたメッセージを受信し、通知を顧客に送信します。 エンリッチメント・サービス 次の図は、エンリッチメント・サービスの流れです。 銀行パートナーからの通知は、 Amazon Simple Queue Service （Amazon SQS）の送金イベントキューで受信されます。これらのメッセージは Lambda 関数によって処理され、 DynamoDB のテーブルに格納されます。 DynamoDB の挿入または更新操作は、 Amazon DynamoDB Streams （テーブルアイテムの変更に関する情報の順序付けられたフロー）を介して変更データキャプチャ（ CDC ）イベントのトリガーとなります。 Lambda を使用して特定の CDC イベントを処理し、 AWS Step Functions のワークフローをトリガーします。このワークフローは必要な検証、エンリッチメント、変換を実行します。加工されたメッセージは最終的に Amazon Simple Notification Service ( Amazon SNS ) のトピックにパブリッシュされ、また、DynamoDB テーブルを更新します。この SNS トピックは、通知サービスから、顧客に通知を行うために使用されます。 次の図は、テーブルの設計を示しています。 新しいレコードは、イベントのアトミック性と高いカーディナリティのため、 request ID を主キー、ソートキーは無しで DynamoDB に挿入されます。また、メッセージごとに Step Functions 固有の実行 ARN 名を生成して保存します。事前に ARN を生成することには、主に2つの利点があります。1つ目は、Strep Fcuntions イベントのアップデートを取得する際、ステータスを更新する DynamoDB のレコードを正しく識別するために ARN を参照します。2つ目は、 Step Functions は同じ ARN での実行を許可しないため、偶発的な再実行や重複処理を最小限に抑えることができます。これは arn:aws:states:<region>:<account>:execution:<state machine name>:<Execution Name> という形式です。各メッセージに対してこの一意な実行名を生成するために、request ID と他の値にほとんど静的な値を使用します。Sweeper や通知ワークフローなどの複数のプロセスが、ステータスを更新するために同じレコードにアクセスする可能性があります。 楽観的ロック を有効にするために versionId 属性を使用し、バージョン番号を効果的に管理するために DynamoDBVersionAttribute 注釈で便利なソリューションを提供する AWS SDK for DynamoDB for Java を使用しています。 FinTech の要件の1つはエラー処理能力の向上であったため、Step Functions のワークフローによってトリガーされる依存サービスの停止など、いくつかの理由によって引き起こされるワークフローの失敗を処理することを目指しました。これを実現するために、テーブル上のグローバルセカンダリインデックス ( GSI ) に依存する、sweeper パターンと呼ばれる、FinTech の内部設計パターンを導入しました。 送金テーブルについては、対応するステータスにあるジョブを識別するために、3つの GSI キー（ Retry Job GSI、 Failed Job GSI、Running Job GSI ）を作成しました。ワークフローが失敗するたびに、エンリッチメント・サービスは対応するテーブル・ アイテムを更新し、request ID と同じ値で Retry Job 属性を修正します。Sweeper という名前の Lambda 関数は、失敗したメッセージを再実行するために呼び出され、再実行のしきい値に達していない失敗したアイテムを見つけるために、 GSI キーの Retry Job 属性をスキャンします。GSI は スパース なので、それらの属性に値を持つアイテムだけを抽出します。失敗した項目だけが GSI キーの Retry Job 属性に request ID を持ち、正常に処理されたレコードは表示されません。アイテムを特定した後、Lambda 関数は Step Functions の実行 ARN を生成し、ジョブを再度トリガーします。このアプローチは失敗を最小化します。また、この関数は失敗したワークフローを特定するために数時間ごとに実行されるようにスケジュールされているため、GSI をスキャンすることはこのケースでは実現可能です。 通知サービス 通知サービスは、エンリッチメント・サービスと同様の設計とテーブルスキーマを使用し、出力されたメッセージは同様のパターンに従って消費・処理され、送金通知を顧客に送信します。このサービスには、ユーザー特性、目的、または地域に基づいて、正しい通知テンプレートが使用されることを確認するための追加ルールがあります。 次の図は、通知サービスの流れです。 まとめ Amazon FinTech チームは、DynamoDB データベースを利用して、スケーラブルで信頼性が高く、イベント駆動型の送金サービスを構築しました。彼らは、DynamoDB Streams とスパースな GSI を使ってソリューションをシンプルにし、Sweeper パターン設計を実装しました。さらに、DynamoDB Streams、GSI、スキーマの柔軟性など、DynamoDB ですぐに利用できる機能を使うことで、FinTech チームは、検討した他の選択肢と比較して開発工数を40%削減し、送金および通知サービスを早期に開始することができました。 DynamoDB を使い始めるための詳細については、 ドキュメント を参照してください。DynamoDB を使ったイベントドリブンパターンをより深く知りたい方は、 Serverless Land をご覧ください。 作者情報 Balajikumar Gopalakrishnan は Amazon Finance Technology のプリンシパルエンジニア。2013年から Amazon に勤務し、Amazon の顧客の生活に直接影響を与えるテクノロジーを通じて現実世界の課題を解決している。仕事以外の趣味は、ハイキング、絵画、家族と過ごすこと。映画好きでもある！ Pradeep Misra は AWS のスペシャリスト・ソリューション・アーキテクト。最新の分散アナリティクスと AI/ML ソリューションのアーキテクトと設計に Amazon 全体で取り組んでいる。データ、アナリティクス、AI/ML を用いて顧客の課題を解決することに情熱を注いでいる。仕事以外では、新しい場所を探検したり、新しい料理に挑戦したり、家族とボードゲームをしたりするのが好き。また、娘たちと科学実験をするのも大好きだ。   （本記事は 2023/08/22に投稿された How Amazon Finance Technologies built an event-driven and scalable remittance service using Amazon DynamoDB を翻訳したものです。翻訳は Solutions Architect の嶋田朱里が担当しました。）

Amazon Simple Storage Service (Amazon S3) は、様々な作業を可能にする強力なプラットフォームです。特筆すべき機能として、FQDN でバケットを作成し、 バケットのWebサイトのエンドポイントにエイリアスレコードを指定する ことで、HTTP の静的ウェブサイトをすぐに立ち上げることができます。静的ウェブサイトの HTTPS トラフィックを提供したい場合は、 Amazon CloudF ront を使用して、キャッシュと HTTPS 証明書の両方を公開ユーザーに提供することができます。 ユーザがイントラネットやプライベートネットワーク内にいる場合は、 AWS PrivateLink for S3 のインターフェイスエンドポイントを使用して S3 バケットへのアクセスを提供します。また、ユーザーは portal.example.com のようなフレンドリーなドメイン名を使って静的ウェブサイトにアクセスしたいでしょう。HTTPS は共通の s3-website.<region>.amazonaws.com といったドメイン名で利用可能です。しかし、カスタムドメインでは、TLS証明書を提供するために追加の内部プロキシが必要になります。これは、内部の アプリケーションロードバランサー (ALB) で実現できます。 ソリューション概要 このソリューションは、VPC への既存のプライベート接続と内部 ALB を活用して、カスタム S3 バケットドメインの TLS 証明書をエンドユーザーに提示します。 ALB は AWS Certificate Manager (ACM) を活用し、信頼できる Amazon S3 VPC Endpoint への安全な TLS 接続を維持しながら、エンドユーザーに有効な証明書を提示します。これにより、静的ウェブサイトのカスタムドメイン名の使用が可能になります。 ウォークスルー このチュートリアルでは、Amazon S3 VPC Endpoint と、既存の AWS 接続で利用できる Internal ALB を作成します。 前提条件 このチュートリアルでは、以下の前提条件が必要です： AWSアカウント ACMでインポートしたドメインの プライベート証明書 または インポートした証明書 （任意のリージョン） ACM証明書と一致するドメイン名の Amazon S3 バケット（” portal.example.com “など）。 Amazon S3を使い始める には、こちらをお読みください。また、 Amazon S3バケットでの作業 については、こちらをお読みください。 バケット上で静的ウェブサイトホスティングを有効にする必要はありません。バケットへのリクエストはプライベート REST API を経由します。 少なくとも2つのプライベートサブネットを持つ VPC 既存の Direct Connect、Site-to-Site VPN、またはクライアント VPN 接続で、VPC に正しくルーティングされていること。これはプライベートインバウンド接続と呼ばれます。 カスタムドメイン名の プライベートホストゾーン VPC 内で稼働する Amazon Elastic Compute Cloud（Amazon EC2）インスタンスなど、VPC ネットワークにアクセスできるリソース S3バケットに入力された index.html エントリページを含む静的ウェブサイト Step 1: Amazon S3 のVPC Endpoint を作成する ALB を安全かつプライベートにS3バケットに接続するには、まず Amazon S3 VPC Endpointを作成する 必要があります。 VPC ダッシュボードにログインします。 左側のメニューから「エンドポイント」ページに移動します。 「Create Endpoint」を選択します。 サービスリストで “s3″を検索し、Amazon S3 Interface Endpoint サービスを選択します。 プライベートインバウンド接続を含む VPC と、エンドポイントが属するサブネットを少なくとも 2 つ選択します。インターフェイスエンドポイントの フォールト・アイソレーションを活用する ため、2つ以上の異なるアベイラビリティゾーン（AZ）に属するサブネットを選択することをお勧めします。 VPC エンドポイントを保護するセキュリティグループを選択します。このセキュリティグループは、最低でも ALB のセキュリティグループからのポート 80 と 443 でのアクセスを許可する必要があります。 セキュリティグループの詳細 については、こちらを参照してください。 VPC Endpointのポリシー は “Full Access” を選択します。このポリシーは、VPC で作業している全ての AWS プリンシパルが、どの S3 バケットでも VPC Endpoint にアクセスできるようにします。これは S3 バケットに定義するセキュリティポリシーをバイパスするものではないです。ただし、ALB を作成した後で、このポリシーを制限して ALB へのアクセスのみを許可することもできます。 「Create endpoint」を選択します。 新しい VPC Endpoint ID を選択して、新しい VPC Endpoint を作成する画面に移動します。 下のタブで「Subnets」に移動します。 VPC Endpoint の IPv4 アドレスは後で必要になるのでメモしておきます。 Step 2: VPCエンドポイントから S3 へのアクセスを許可する VPC EndpointsのS3バケットポリシーについて は、こちらをご覧ください。 S3バケットに移動し、「Permissions」タブに移動します。 「Bucket policy」までスクロールダウンし、「Edit」を選択します。 提供されているドキュメントに基づいてポリシーを追加します。参考までに、この提供されたポリシーを使用して、VPC Endpoint のみが明示的に許可されるようにすることもできます。 { "Version": "2012-10-17", "Id": "Policy1415115909152", "Statement": [ { "Sid": "Access-to-specific-VPCE-only", "Principal": "*", "Action": "s3:GetObject", "Effect": "Allow", "Resource": ["arn:aws:s3:::yourbucketname", "arn:aws:s3:::yourbucketname/*"], "Condition": { "StringEquals": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] } Step 3: Internal ALB を設定する 内部 ALBは、クライアント向けの TLS 接続を終了します。 AWS ConsoleのEC2ダッシュボードに移動します。 左側のメニューで、「Load Balancers」を選択します。 「ロードバランサーの作成」を選択します。 「Application Load Balancer」ボックスで「Create」を選択する。 ALB に名前を付け、「internal」スキームを選択する。 リスナープロトコルを「HTTPS」に切り替えます。 ALB がサービスを提供するプライベートサブネットを選択します。「Next」を選択します。 クライアントに提供する ACM 証明書を選択します。静的S3バケットのドメイン/名前と一致する必要があることに注意してください。「Next」を選択します。 既存のプライベート接続がロードバランサーのポート 443 に接続できるようにするセキュリティグループを選択または作成します。「Next」を選択します。 まだ設定していない場合は、ここで定義したALBセキュリティグループへのアクセスを許可するように、VPCエンドポイントのセキュリティグループを更新してください。 HTTPS プロトコルを使用する IP をターゲットとする新しいターゲットグループを作成します。ヘルスチェックでHTTPプロトコルを使用します。「ヘルスチェックの詳細設定」で、「ポートオーバーライド」がHTTPプロトコルと一致するように80に設定されていることを確認します。 ALB の ヘルスチェックホストヘッダーにはドメイン名が含まれない ため、S3 は200以外の HTTP レスポンスコードを返します。ヘルスチェックの成功コードに 「307,405」を追加します。「Next」を選択します。 ステップ1で確認した VPC エンドポイントの IP アドレスをターゲットグループに登録します。「Next」を選択します。 ステップ 4: リスナー・ルールの追加設定 Amazon S3 PrivateLink EndpointはREST API Endpoint であるため、末尾のスラッシュを含むリクエストはデフォルトで XML ディレクトリリストを返します。これを回避するには、リダイレクトルールを作成して、末尾にスラッシュを含むすべてのリクエストを index.html に向けるようにします。 内部 ALB に移動します。それを選択し、「Listeners」タブを開きます。 HTTPS リスナーのテーブルの右側で、「View/edit rules」を選択します。 上部近くの「+」アイコンを選択し、新しいルールを挿入できるようにします。 「IF」の下で 「Add Condition」を選択し、「Path…」を選択します。 パスの値の下に 「 */ 」を入力します。 「THEN」で 「Add Action」を選択し、「Redirect to…」を選択します。 「Enter port」の下に 「 #{port} 」と入力します。 ドロップダウンから「Custom host, path, query」を選びます。 「パス」を「 /#{path}index.html 」に修正します。 右上の「保存」を選択します。 Step 5: DNS を設定し、ALB をテストする オンプレミスまたはプライベートの DNS エントリを設定し、Internal ALB を指すようにします。 Route53 プライベートホストゾーン （PHZs）を使用してプライベートエイリアスレコードを設定し、PHZをVPCに関連付けることができます。また、 オンプレミスからのインバウンドDNSクエリをVPCに転送する こともできます。 Step 6: ALB をテストする 内部 ALBにアクセスするには、VPC へのプライベートアクセスを持つリソースを使用する必要があります。リソースに接続し、新しいプライベート DNS エントリにナビゲートしてみてください。リソースへのコンソールアクセスしかない場合は、cURL コマンドを使用してプライベート静的ウェブサイトを検証することもできます。 クリーンアップ クリーンアップのために、このガイドで作成したリソースを以下の順序で削除または元に戻すことができます： Route53 PHZ DNS entries ALB Load Balancer ターゲットグループ Amazon S3 VPCエンドポイント 作成したリソースに関連するセキュリティグループ S3 バケットポリシー まとめ この投稿では、Amazon EC2でプロキシをプロビジョニングすることなく、カスタムドメインでプライベートな静的 Amazon S3 ウェブサイトを作成する方法を学びました。これは、大規模な内部ユーザ・ベースに対して静的ウェブサイトをスケーリングする際に便利です。また、 Amazon EC2 プロキシインスタンスのアップグレード、セキュア化、スケーリングと行ったの差別化につながらない重労働を管理する必要がなくなるというメリットもあります。 静的ウェブサイトに認証メカニズムを追加したい場合は、ドキュメントで提供されている使用例の1つを使用してALB を使用して認証を活用するか、 AWS Verified Access を使用することができます。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。