はじめに アマゾン ウェブ サービス (以下、AWS) は、 2023年9月28日に 基盤モデルを API 経由で利用できるようにするフルマネージド型のサービスである Amazon Bedrock を一般公開しました 。本記事では Amazon Bedrock で提供されるモデルのうち、日本語にも対応した Anthropic 社の Claude を利用し、コンタクトセンター業務を支援するサンプルソリューションである Live Call Analytics with Agent Assist（以下、LCA）を日本語化し、お客様とエージェントの通話に合わせた回答生成、通話内容の自動要約等に活用するための手順をご紹介します。なお、LCA の詳細については、 Amazon言語系AIサービスによるコンタクトセンターのライブ通話分析とエージェントアシスト をご参照ください。 Amazon Connect 環境の概要 LCA ではコールセンターのソリューションとして、Asterisk、Genesys Cloud、Amazon Chime SDK 等、複数の音声源をサポートしています。今回は Amazon Connect の利用を前提とし、環境の構築を進めます。 アーキテクチャやコードは GitHub で公開 されています。 Amazon Connect 環境の構築 LCA ではコールセンターのソリューションとして、Asterisk、Genesys Cloud、Amazon Chime SDK 等、複数の音声源をサポートしています。今回は Amazon Connect の利用を前提とし、環境の構築を進めます。 Amazon Connect で日本の電話番号を使用するためにはAWS サポートへの問い合わせの上、手続きが必要です。以下の手順では日本の電話番号を使用していますが、US 等の電話番号等でも実施可能です。 1. Amazon Connect のコンソールで「インスタンスを追加する」をクリックします。 2. アクセス URL を設定して、「次へ」をクリックします。 3. 管理者を指定して、「次へ」をクリックします。 4. 残りの項目はデフォルトのまま変更せず進み、「インスタンスの作成」をクリックします。 5. 作成した環境の Instance ARN をメモします。 6. 「Log in for emergency access」を選択して、Amazon Connectの管理コンソールにログインします。 7. 上部の地球儀アイコンから、言語設定を変更します。 8. 電話番号を取得するために、「開始」をクリックします。 9. 電話番号を選択して、「次へ」をクリックします。 10. 「Continue」をクリックします。 11. 「ルーティング」メニューの「フロー」を選択します。 12. 「フローを作成」をクリックします。 13. サンプルのフローを こちら からダウンロードします。右上のドロップダウンから「インポート（ベータ）」をクリックします。 14. 前の手順でダウンロードしたファイルを選択して、「インポート」をクリックします。 15. 「記録と分析の動作を設定」ブロックを選択し、言語設定で「日本語（日本）」を選択して「保存」をクリックします。 16. 右上の「保存」をクリックします。「公開」をクリックし、表示されるダイアログで「公開」をクリックします。 17. 「チャンネル」メニューの「電話番号」をクリックします。 18. 電話番号をクリックします。 19. 「問い合わせフロー/IVR」で「LCA-EXAMPLE」を選択して、「保存」をクリックします。 AWS Cloud9 環境の作成 LCA をデプロイするために必要な構成ファイル等を生成するために、AWS Cloud9（以下、Cloud9） の環境を作成します。 1. Cloud9のコンソールから「環境を作成」をクリックします。 2. 「名前」を入力し、インスタンスタイプで「m5.xlarge」を選択して「作成」をクリックします。 3. 「開く」をクリックします。 4. 環境で使用されている Amazon EBS ボリュームのサイズ変更 の手順にしたがってボリュームサイズを 20GB に変更します。 LCA のデプロイ AWS CloudFormation（以下、CloudFormation）で LCA をデプロイします。ブログ執筆時点の最新である LCA v0.8.8 の使用を前提とします。 1. Github から LCA のコードを Cloneします。 git clone https://github.com/aws-samples/amazon-transcribe-live-call-analytics.git cd amazon-transcribe-live-call-analytics/ 2. publish.sh を以下のように実行します。（S3バケット名は日付を入れる等、一意になるように変更する必要があります。） ./publish.sh lca-demo-env-bucket lca-artifacts ap-northeast-1 各引数の意味は以下のとおりです。 ./publish.sh <cfn_bucket_basename> <cfn_prefix> <region> [public] - <cfn_bucket_basename>: CloudFormation テンプレートやコードを保存する S3バケットを指定します。 - <cfn_prefix>:作成されるコードはこの prefix 下に置かれます。 - <region>: 使用するAWSリージョンをしています。 - public: (optional) "public" を指定するとコード類がパブリックに公開され、他のアカウントでも使用可能となります。 3. 正常に実行が完了すると以下のように結果が出力されるので、Template URLをコピーします。 OUTPUTS Template URL: https://s3.ap-northeast-1.amazonaws.com/lca-demo-env-bucket-ap-northeast-1/lca-artifacts/lca-main.yaml CF Launch URL: https://ap-northeast-1.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/create/review?templateURL=https://s3.ap-northeast-1.amazonaws.com/lca-demo-env-bucket-ap-northeast-1/lca-artifacts/lca-main.yaml&stackName=LCA CLI Deploy: aws cloudformation deploy --region ap-northeast-1 --template-file /tmp/lca/lca-main.yaml --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND --stack-name LCA --parameter-overrides AdminEmail=jdoe@example.com CallAudioSource=Demo Asterisk PBX Server demoSoftphoneAllowedCidr=CIDRBLOCK siprecAllowedCidrList="" S3BucketName="" Done 4. CloudFormationのコンソールを開き、「スタックの作成」をクリックします。 5. テンプレートの「Amazon S3 URL」に先ほどコピーしたTemplate URLを入力し、「次へ」をクリックします。 6. スタック名、パラメーターを以下のように入力します。（以下に記載以外のパラメーターはデフォルトの値を使用します） 項目 設定値 スタック名 lca-demo-env パラメーター Web UI Authentication Admin Email Address 自分の E メールアドレス Telephony Ingestion Options Call Audio Source Amazon Connect Contact Lens Call Audio Processor Call Transcriber Lambda Amazon Connect instance ARN (existing) 前の手順で確認した Amazon Connect環境のARN Agent Assist Options Agent Assist QnABot Bedrock ModelId anthropic.claude-instant-v1（デフォルト） Amazon Transcribe Configuration Transcribe API mode standard Language for Transcription ja-JP Transcript Event Processing Configuration BedrockModelId anthropic.claude-instant-v1（デフォルト） 7. 以降の設定はデフォルトのまま「次へ」をクリックして進みます。 8. 以下のようにチェックボックスを有効にして、「送信」をクリックします。 9. 45分程でデプロイが完了します。 Claude のアクセス申請 Amazon Bedrock が提供する Claude を利用するためにアクセス申請を行います。 ブログ執筆時点、Amazon Bedrock は東京リージョン（ap-northeast-1）で一部のモデルがリリースされていないため、実際の画面とは異なります。本記事では東京リージョンでリリース済みの Claude Instant を使用します。 1. Amazon Bedrock のコンソールに移動します。 2. 左側のメニューの「Model access」を選択し、「Edit」をクリックします。 3. Anthropic の横にある「Request」をクリックします。 4. 必要事項を入力して、「Request」をクリックします。 5. しばらくすると Claude の「Access status」が「Available」になるので、チェックボックスにチェックを入れて、「Save changes」をクリックします。 6. 「Access status」が「Access granted」になります。 LCA のWeb コンソールにログイン LCA の Web コンソールにログインします。コンソールはコールセンターのエージェントがお客様との通話中に使用します。 1. スタックの作成が完了すると「Welcome to Live Call Analytics with Agent Assist!」というメールが届くので、メールに記載のURLを開き、メールアドレス、メールに記載のパスワードでログインします。 2. パスワードの変更を求められるので、パスワードを変更します。 3. 「Email」にチェックを入れて、「VERITY」をクリックします。 4. 受信したEメールに記載の Confirmation Code を入力して「SUBMIT」をクリックします。 5. LCAのWebコンソールが開きます。 QnABot Content Designer にログイン QnABot Content Designer は LCA に含まれる Agent Assist Bot の各種動作を設定することができます。ここでは必要最低限の修正を行います。各項目の説明は QnABot on AWS のドキュメント を参照してください。 1. 「QnABot Signup Verification Code」というメールが届くので、メールに記載のURLを開き、ユーザー名（Admin）、メールに記載のパスワードでログインします。 2. 新しいパスワードを入力して「Send」をクリックします。 3. QnABot Content Desigerが開きます。 4. 左上のメニューを開き、「Settings」を選択します。 5. 以下の項目を変更します。 項目 値 備考 ALT_SEARCH_KENDRA_FALLBACK＿CONFIDENCE_SCORE LOW Kendra の 検索結果でSCOREが低いものも対象にする LLM_GENERATE_QUERY_PROMPT_TEMPLATE Human: <chatHistory> タグの中にチャット履歴の記載があります:<br><chatHistory><br>{history}<br></chatHistory><br>Human: <followUpMessage> タグの中に Human からの質問があります:<br><followUpMessage><br>{input}<br></followUpMessage><br>Human: 質問の内容を、チャット履歴を読まなくても理解できるような独立した質問として言い換えてください<br><br>Assistant: 6. 「SAVE」をクリックします。 日本語対応 LCA を日本語対応するための設定変更を行います。 Kendra LCA のデフォルトの構成では Kendra に英語のドキュメントが投入されています。ここでは検索対象を日本語のドキュメントに変更します。 1. Kendraのコンソールで、作成されたインデックスを選択します。 2. データソースを選択し、Action メニューの「Edit」を選択します。 3. Default Languageで「Japanese (ja)」を選択して「Next」をクリックします。 4. 設定済みの Source URL を削除して、以下のURLを追加します。 https://ja.wikipedia.org/wiki/損害保険 https://ja.wikipedia.org/wiki/自動車損害賠償責任保険 5. 最後まで進み、「Update」をクリックします。 6. データソースを選択して、「Sync now」をクリックします。 Lambda 1. Lambda のコンソールを開きます。 2. 関数名に「FulfillmentLambda」を含む Lambda 関数を開きます。 3. lib/middleware/3_query.js に以下の行を追加して、「Deploy」をクリックします。 req['kendraQueryArgs'] = ['"AttributeFilter" : {"EqualsTo":{"Key":"_language_code","Value":{"StringValue": "ja"}}}'] 4. 「エイリアス」タブで「live」をチェックして、「編集」をクリックします。「バージョン」で $LATEST を選択して「保存」をクリックします。 5. AWS Systems Manager のパラメータストアの値を修正します。Systems Manager のコンソールで「パラメータストア」を選択し、「LLMPromptSummaryTemplate」を含むパラメータを開きます。 6. 「編集」をクリックします。 7. 「値」を以下のように設定し、「変更を保存」をクリックします。 { "Summary":"<br><br>Human: <transcript></transcript>タグに記載された内容に基づいて、<question></question>タグに記載された質問に答えてください。質問に答えられない場合は、「n/a」と答えてください。性別に関係ない代名詞を使用してください。回答する場合は、答えのみを回答してください。<br><br><question>記載された内容の要約は？</question><br><br><transcript><br>{transcript}<br></transcript><br><br>Assistant:", "Topic":"<br><br>Human: <transcript></transcript>タグに記載された内容に基づいて、<question></question>タグに記載された質問に答えてください。質問に答えられない場合は、「n/a」と答えてください。性別に関係ない代名詞を使用してください。回答する場合は、答えのみを回答してください。<br><br><question>通話のトピックは何ですか？例えば、iphoneの問題、請求の問題、キャンセルなど。トピックだけを答えてください。</question><br><br><transcript><br>{transcript}<br></transcript><br><br>Assistant:", "Follow-Up Actions":"<br><br>Human: <transcript></transcript>タグに記載された内容に基づいて、<question></question>タグに記載された質問に答えてください。質問に答えられない場合は、「n/a」と答えてください。性別に関係ない代名詞を使用してください。回答する場合は、答えのみを回答してください。<br><br><question>AGENTはこれからどのようなアクションが必要ですか？</question><br><br><transcript><br>{transcript}<br></transcript><br><br>Assistant:" } 動作確認 ここまでの設定で LCA を日本語対応するための最低限の設定ができましたので、実際に電話をかけて動作を確認します。 1. エージェント(Agent)側で「問い合わせコントロールパネル」を開きます。 2. ステータスを「Available」にします。 3. お客様側(Caller)から電話をかけます（通話料が発生しますのでご注意ください）。 4. Webコンソールにレコードが作成されるので、Call IDをクリックします。 5. 以下のようにLCAの詳細ページが開きます。 「Call Transcript」には通話の文字起こしの結果が表示されます。エージェントとお客様の会話内容に基づき、リアルタイムに関連ドキュメントが提示され、エージェントは適切な回答を即座に行うことができます。「Agent Assist Bot」の画面ではエージェントが質問内容を入力し、関連ドキュメントを検索することが可能です。「Call Summary」には通話終了後に、会話内容の要約、トピック、フォローアップ内容が表示されます。 まとめ 本記事ではコンタクトセンター業務を支援する LCA を Amazon Connect と共に構築し、 Amazon Bedrock の Claude 2 を利用して日本語化する手順をご紹介しました。ご自身のアカウントでも構築可能ですので、ぜひトライしていただき、Amazon Bedrock が提供する生成系 AI の可能性を体感してください。本ソリューションは 生成系 AI を利用したユースケースの一例に過ぎませんので、ご自身の業務での適用できそうなアイディアをふくらませていただき、ビジネスの革新に Amazon Bedrock を活用いただければと思います。 著者について 千代田 真吾は、アマゾンウェブサービスのソリューションアーキテクトです。現在は、エンタープライズの小売・消費財業界のお客様が AWS を用いてビジネスを拡大するのを支援しています。

アプリケーション層は多くのクラウドアーキテクチャで世界中がアクセスする部分ですが、使用しているデータベースに合わせてアプリケーションを最適化する方法を検討することはほとんどないようです。リレーショナルデータベースエンジンを使用するときは、スキーマの設計だけでなく、アプリケーションが管理可能で、スケーラブルで、パフォーマンスが高いことを保証するために、データベースがストレージシステムに対してデータを読み書きする方法を理解することが重要です。シリーズのパート 1 となるこの投稿では、PostgreSQL の主要な用語について説明し、次に、 Amazon Aurora PostgreSQL 互換エディション または Amazon Relational Database Service (Amazon RDS) for PostgreSQL を使用する場合の自動コミット処理、自動バキューム処理、およびトランザクション中のアイドル状態についてもう少し詳しく説明します。 PostgreSQL パラメータの変更: どこで、いつ、なぜ パラメータは、データベースと PostgreSQL でその要素プロパティを定義するために使用されます。PostgreSQL では、新しいデータベースを作成するときにデフォルトのパラメータが設定されており、多くのシステムでは、通常はデフォルトパラメータのパフォーマンスが良く、チューニングは必要ありません。システムが成長し、規模が拡大し、負荷が高まるにつれて、最適なパフォーマンスを得るために一部のパラメータを調整する必要があります。 セルフマネージドデータベースと AWS マネージドデータベースのどちらを使用しているかによって、異なるパラメータ値を変更する必要があります。セルフマネージドデータベースの場合、パラメータの変更は postgresql.conf ファイルで行われます。AWS マネージドデータベースでは、postgresql.conf ファイルへのアクセスは制限されているため、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、SDK、または AWS CloudFormation を介してのみ、基礎となるデータベースまたはクラスターパラメータグループに対して変更を行うことができます。 postgresql.conf (セルフマネージド) セルフマネージドデータベースでは、PostgreSQL クラスター全体にパラメータを設定する場合、このファイル (PostgreSQL データディレクトリ内) に変更を加えます。詳細については、PostgreSQL コミュニティドキュメントの パラメータ設定 を参照してください。 RDS DB パラメータグループ (AWS マネージド) Amazon RDS のクラスターレベルとデータベースレベルのパラメータグループには、インスタンスクラスとサイズに応じたデフォルト設定があります。パフォーマンスを向上させるために他の値に変更が必要な場合は、 コンソール 、 AWS CLI 、SDK、または AWS CloudFormation を使用して新しいパラメータグループを作成できます。詳細については、 DB パラメータグループの作成 を参照してください。 セッションレベル (セルフマネージドまたは AWS マネージド) PostgreSQL のパラメータの多くは、セッションレベル (1つ以上のトランザクションで構成される) で変更できます。これらのパラメータは、そのワークロードの中で実行されたクエリにのみ適用され、データベース全体には適用されません。これらのパラメータは、 SET コマンドを使用して変更できます。詳細については、PostgreSQL コミュニティドキュメントの SET を参照してください。 PostgreSQL のコンセプト このセクションでは、PostgreSQL データベースの運用に不可欠な PostgreSQL のコアコンセプトについて説明します。 トランザクション PostgreSQL では、トランザクションは単一の操作として実行される一連の SQL ステートメントです。このトランザクションモデルは、トランザクション内の全てのステートメントがデータベースに正常にコミットされるか、ステートメントが失敗した (もしくはエラーが発生した) 場合にロールバックされることを保証します。 PostgreSQL は ACID に準拠しています。ACID とは、データベース操作において原子性、一貫性、独立性、永続性が常に維持されることを保証する一連のデータベース特性です。 Atomicity (原子性) – データベースの原子性により、トランザクションが完了するまでオープントランザクションは他のトランザクションから見えなくなり、その後、すべての変更が単一のユニットとして同時に表示されます。 Consistency (一貫性) – 一貫性により、データにコミットされた変更があった場合、その変更が数日前、数時間前、または数秒前にコミットされたかどうかにかかわらず、新しいトランザクションでその変更を確認できます。また、サーバーがクラッシュした後でも、データをエラーなく回復できます。 Isolation (独立性) – PostgreSQL は、他の同時実行中のトランザクションへのデータ変更の可視性を制御するためのさまざまな分離レベルを提供します。デフォルトでは、read commited の分離レベルが使用されます。これにより、トランザクションは、他のトランザクションによってコミットされた後にのみ変更を確認できます。 Durability (永続性) – 永続性は、コミットされたすべての変更をデータベースが追跡することを保証します。そのため、異常なキャンセルが発生した場合、データベースは元の状態にロールバックするか、トランザクションログを再生して中断したところから続行できます。 トランザクションの詳細については、 トランザクション を参照してください。ACID コンプライアンスの詳細については、PostgreSQL コミュニティドキュメントの 用語集 を参照してください。 ロッキング PostgreSQLは、複数のトランザクション間の競合を防ぐために、ロッキングメカニズムを使用してデータへの同時アクセスを管理します。PostgreSQL には次の 2 種類のロックがあります。 共有ロック – これにより、複数のトランザクションが特定のデータオブジェクトを同時に読み取ることができます。 排他ロック – ロックが解除されるまで、他のトランザクションがデータオブジェクトにアクセスできないようにします。 PostgreSQLはロックプロトコルを利用しており、ロックは特定の順序で取得および解除されます。これにより、データベースをデッドロックから保護できます。デッドロックとは、2 つ以上のトランザクションが互いにリソースアクセスのロックの解放を待っている間にブロックされる状況です。 PostgreSQL は行レベルのロックもサポートしています。これにより、テーブル全体ではなく個々の行をロックできるため、同時アクセスをきめ細かく制御できます。最後に、 PostgreSQL はロックエスカレーションを実装しています。これにより、 1 つのオブジェクトに対する多数のロックを、 1 つの高レベルのロックに置き換えて、全体的なロックオーバーヘッドを削減できます。 ロックの詳細については、 明示的ロック を参照してください。 VACUUM PostgreSQL は、データの行をタプルと呼ばれる構造に格納します。タプルが論理的に更新または削除されても、データベースには目に見えないバージョンが残っています。削除または更新コマンドと同時に実行されているトランザクションが、トランザクションが開始された時点からのデータベースのスナップショットで終了できるように、タプルが保持されます。 PostgreSQL は VACUUM プロセスを使用して、古い不可視タプルのバージョンで使用されていたスペースを解放し、ストレージを再利用します。更新および削除された行はデッドタプルとしてマークされ、後で VACUUM プロセスによってクリーンアップされます。異なるトランザクションが同じタプルで同時に処理される可能性があるため、これらはすぐにはクリーンアップされません。マルチバージョン同時実行制御 (MVCC) によって精度が保証されます。たとえば、元のバージョンをすぐに削除すると、同時に実行されているトランザクションは正確にロールバックされません。VACUUM を実行するだけでもデッドタプルは削除されますが、VACUUM コマンドには他にも理解しておかなければならないバリエーションがあります。これについてはこのセクションで説明します。 VACUUM ANALYZE このコマンドは、デッドタプルを削除し、そのテーブルの内容に関するデータベース統計を収集します (これらの統計は pg_statistic システムカタログに保存されます) 。このデータは PostgreSQL クエリオプティマイザによって使用され、クエリ実行時に最も効率的なクエリ実行プランを決定するのに役立ちます。 VACUUM FREEZE このオプションは、デッドタプルをクリーンアップするだけでなく、VACUUM が古い行をフリーズしてすべてのユーザーに表示するか、削除するかを決定するために使用するカットオフ期間 (トランザクション XID 単位) を指定して、タプルを積極的にフリーズします。これにより、VACUUM プロセス中に古いアクティブなタプルのデータが失われたり、トランザクションのラップアラウンドによる破壊を防ぐことができます。トランザクションは固有の XID で追跡され、固定番号であるため使い果たされる可能性があります。適切に監視しないと、運用データベースの XID 番号が登録可能な上限に達し、過去の XID 番号が現在になって再利用できるというラップアラウンドが発生する可能性があります。このラップアラウンド破損により、データの整合性を保護するためにデータベースがシャットダウンする可能性があります。 VACUUM FULL このオプションは、内容を完全に書き換えることにより、テーブル (またはデータベース) からデッドタプルを削除します。データを物理的に再配置してより徹底的なクリーンアップを行うことで、削除および更新されたタプルからディスク容量を再利用します。その結果、ストレージがより圧縮され、クエリパフォーマンスが向上します。このオプションは、テーブルに対して排他ロックを作成し、操作が完了するまで他のすべてのアクセスを防止するため、通常の運用環境では使用しないでください。 PostgreSQL のタイムアウト関連のパラメータ ベンチマーク中にワークロードがどのように動作するかを見積もることはできますが、本番環境のワークロードが予期しない動作をすることがあるため、タイムアウト設定は必要です。タイムアウト設定を適切に設定することは、ワークロードの実行中の異常からクラスターを保護するためのセーフガードとして機能します。これらの設定は、データベースのライフサイクルを通じて調整可能であり、また、調整する必要があります。グッドプラクティスはコネクションとリクエストのタイムアウトを設定することです。RDS for PostgreSQL データベースには便利なデフォルト設定がありますが、異なる設定でパフォーマンスが向上すると判断した場合は、本番環境に適用する前に、設定を 1 つずつ変更してテストしてください。 PostgreSQL データベースタイムアウト設定は、ステートメント、ユーザ、またはデータベースレベルで設定できます。アプリケーション開発者は、これらのタイムアウトパラメータと、それらがタイムアウトエラーを防ぐためにどのように機能するかを理解しておくと役に立ちます。アプリケーションのパフォーマンスとユーザーエクスペリエンスがタイムアウトエラーによって悪影響を受けないように調整できるタイムアウトに関するパラメーターは次のとおりです。 statement_timeout – クエリ内のステートメントがタイムアウトするまでのミリ秒数。デフォルトはタイムアウトなしです。 idle_in_transaction_session_timeout – このパラメータは、指定された期間を超えてアイドル状態が続いているオープントランザクションのあるセッションをすべて閉じます。これにより、そのセッションで保持されていたロックがすべて解放され、コネクションスロットを再利用できます。また、このトランザクションでのみ表示されるタプルをバキュームされ、肥大化を抑えることができます。デフォルト値は (0) で無効です。 idle_session_timeout – PostgreSQL バージョン 14 以降では、 idle_session_timeout パラメーターを使用できます。アイドル状態であるが、指定された時間を超えてオープントランザクションの外にあったセッションはすべて閉じられます。デフォルト値は (0ms) で無効です。バージョン 13 以前では、 idle_in_transaction_session_timeout パラメーターが使用されていましたが、開いているセッションのすべてのトランザクションが停止させるものでした。 client_connection_check_interval – PostgreSQL バージョン 14 以降では、 client_connection_check_interval パラメーターを使用できます。このパラメータを使用すると、クエリ実行時にクライアントコネクションをオプションでチェックする間隔を設定できます。このチェックにより、カーネルからコネクションが閉じられたと報告された場合に、長時間実行されるクエリをより早く終了させることができます。デフォルト値は (0ms) で無効です。バージョン 13 以前では、サーバーはクエリが完了するまでコネクションの切断を検出しなかったため、コネクションが予期せず終了した場合、結果をクライアントに送り返すことができませんでした。 データベースの動作に関するPostgreSQLの機能とそのベストプラクティス PostgreSQL は、実証済みのデータ整合性、信頼性、拡張性を備えた強力なオブジェクトリレーショナルデータベースシステムです。高性能で革新的なデータベースソリューションを提供できる強力なアーキテクチャを備えています。 PostgreSQL には、アプリケーション開発者がフリーのオープンソースの拡張可能な環境で運用可能なフォールトトレラントアプリケーションを構築するのに役立つ多くの機能があります。開発者は、データベースを再コンパイルしなくても、カスタム関数を構築し、さまざまなプログラミング言語のコードを使用できます。このセクションでは、データベースの動作に関するいくつかの機能とベストプラクティスについて説明します。 AUTOCOMMIT PostgreSQLはACIDに準拠しているため、トランザクションを明示的にコミットする必要があります。これに役立つ機能の 1 つが、トランザクションをデータベースに自動的に保存する AUTOCOMMIT です。 AUTOCOMMIT では、各ステートメントがトランザクション内で実行され、各ステートメントが自動的にコミットされます。デフォルト値は ON です。つまり、実行するために BEGIN または COMMIT コマンドを特別に発行する必要はありません。トランザクションは BEGIN で始まり、 COMMIT コマンドで終わります。コミットはユーザーの変更を保存します。 AUTOCOMMIT が OFF に設定されている場合、 BEGIN コマンドは不要ですが、変更がデータベースに反映されるようにするには、ステートメントの最後に明示的に COMMIT コマンドを記述する必要があります。 AUTOCOMMIT のデフォルト設定はほとんどの環境で役に立ち、変更する必要はありません。たとえば、 \COPY コマンドを使用して行を一括ロードする場合、 AUTOCOMMIT を無効にする必要はありません。100 行の AUTOCOMMIT の一括挿入 (たとえば、 INSERT … VALUES (...), (...), (...), (...) のほうが、100 行の INSERT ステートメント ( BEGIN; INSERT … INSERT … INSERT … ) からなる単一の COMMIT よりもパフォーマンスが向上します。これは、個々の BEGIN コマンドと COMMIT コマンドが大量のディスクアクティビティと CPU を消費するためです。ただし、特定の状況下では、設定をオフにした方が作業しやすい場合があります。1 回の挿入に失敗すると、すべての行がロールバックされます。これは、ビジネスニーズによっては問題となる可能性のある不要な部分的データロードを回避するためです。 この機能は、 WHERE 句なしで DELETE ステートメントを誤って実行してしまったなどの間違いからすばやく回復できるため、アプリケーション開発者にとって有益な場合があります。 AUTOCOMMIT をオフのままにしておきたい場合は、ワークロードの特定の側面に合わせてセッションレベルでこの設定を変更するのが最善です。 AUTOCOMMIT をオフにしてステートメントを発行し、 COMMIT コマンドを指定しなかった場合、PostgreSQL はこの投稿で前述したように COMMIT が指定されるまでロックを保持するため、次のステートメントはロック状態になります。 AUTOCOMMIT を使用する際のベストプラクティスを次に示します。 AUTOCOMMIT はグローバルにオンのままにしておき、ビジネス上の理由がある場合にのみ無効にします。次の点に注意してください。 AUTOCOMMIT をオンにすると、クエリはグループ化されません。 AUTOCOMMIT は暗黙的に発行されるため、どのクエリがコミットまたはロールバックされるかが不確実になることはありません。 PostgreSQL のオートコミットには暗黙的な BEGIN と COMMIT があり、しばしば トランザクションブロック と呼ばれ、 COMMIT コマンドは不要です。 AUTOCOMMIT をオンにすると、すべての SQL ステートメントが自動的にコミットされることが保証され、 AUTOCOMMIT が off でない限りロールバックはできません。 AUTOCOMMIT を無効にする場合は、セッションレベルでのみ無効にしてください。次の点に注意してください。 無効にすると、データベースは常にトランザクションモードになり、 COMMIT または ROLLBACK コマンドで明示的に終了する必要があります。 AUTOCOMMIT がオフの場合、間違いがあった時に、ロールバックを実行するのは簡単で、すべてが元に戻されます。これにより、変更がデータベースに保持されていないため、間違いから迅速かつ簡単に回復できます。 AUTOVACUUM VACUUM はデッドタプルをクリーンアップする手動プロセスですが、 AUTOVACUUM は削除されたタプルや更新された古いタプルの削除を自動化する定期的なバックグラウンドユーティリティデーモンです。AUTOVACUUM はデフォルトで有効になっており、データベースに多数の UPDATE コマンドと DELETE コマンドが発行されている場合は、そのパラメータをテストして調整する必要があります。PostgreSQL は MVCC モデルを使用しており、同時読み取り要求を完了できるように古い行バージョンを保持します。これらのステートメントの間、行は削除されず、古いバージョンはトランザクションが完了するまで保持されます。COMMIT コマンドが指定されていない場合、トランザクションは技術的にはまだ実行中であり、その行がまだ必要である可能性があるため、AUTOVACUUM はこれらの行を削除できません。オートコミットを無効にすることで発生する問題の例としては、データベースのロックや AUTOVACUUM メンテナンスの障害があります。 AUTOVACUUM を無効にすると、デッドタプルが削除されず、テーブルが肥大化します。データベースの肥大化はテーブルとインデックスの全体的なディスク使用量の増加につながり、クエリの実行時間が増加し、クエリを実行するためにテーブルやインデックスからデッドタプルやアクティブな可視行が読み取られることになるため、これは望ましくありません。AUTOVACUUM が自動的にデッドタプルを削除する代わりに、 VACUUM FULL コマンドを明示的に呼び出して物理的に削除しなければならない場合があります。 AUTOVACUUM のベストプラクティスは次のとおりです。 タプルレベルの統計用の pgstattuple 拡張機能で、肥大化を評価できる情報を定期的に取得して、AUTOVACUUM が実行されていることを確認します。次の点に注意してください。 肥大化によってディスク消費量が増加し、パフォーマンスが低下します。その結果、管理されず、定期的に削除されていないと、関連するデータを取得するクエリは、 2 倍 (またはそれ以上) かかります。AUTOVACUUM は、適切に設定されていれば、時間の経過に伴うデータベースの肥大化を最小限に抑えるのに役立ちます。 autovacuum_naptime パラメーターを適切に調整して、AUTOVACUUUM が十分な頻度で実行されるようにします。これにより、データベースの肥大化を防ぐことができます。 書き込みの多いワークロードの裏で実行される、長時間実行されるクエリは避けてください。AUTOVACUUM はテーブルに弱いロックをかけるため、サーバーで実行されているワークロードを完全に把握するようにしてください。 INSERT 、 UPDATE 、 DELETE などの通常のデータベース操作は続行できますが、インデックスやテーブルの切り詰めには影響します。 テーブルの使用状況とアクセスパターンに基づいて AUTOVACUUM 設定を調整します。次の点に注意してください。 DELETE ステートメントや INSERT ステートメントが多いテーブルで、前述の VACUUM パラメータに基づいてテーブル の AUTOVACUUM のしきい値をテストして設定します。 データベースへの影響を小さくするために、ビジーでない時間帯に AUTOVACUUUM をいつどのように実行するかについての最善の戦略を計画してテストしてください。また、ロックによって本番システムのワークロードが中断されないように、ビジー時に実行する方法も決定してください。 AUTOVACUUM を頻繁に使われないように注意してください。バキューム処理の間、ビジー状態になって回復するのを待つか、 VACUUM FULL を使わなければならないようなリスクがシステムに発生するかもしれません。 トランザクション中のアイドル状態 コネクション状態の変化はエラーのトラブルシューティングの出発点になる可能性があるため、 PostgreSQL コネクションの監視は重要なタスクです。 PostgreSQL には、トランザクションまたはステートメントの4つの主な状態があります。 active – オープンでクエリを実行しているコネクション idle – アイドル状態でクエリを実行していないが、メモリや CPU などのサーバーリソースを消費し、パフォーマンスの低下の一般的な原因となっているコネクション idle_in_transaction – バックエンドがトランザクション中であるが、アイドル状態で現在入力を待っているコネクション idle_in_transaction (aborted) – idle_in_transaction に似ていますが、トランザクション内のステートメントが原因でエラーが起こった状態 トランザクション処理中は、ロックを保持したり、他のクエリをブロックしたり、AUTOVACUUM や VACUUM のパフォーマンスを妨げてテーブルが肥大化したりする可能性があります。特定が難しい場合が多く、パフォーマンスの問題の原因となっている重要な状態が idle_in_transaction です。データベースが BEGIN コマンドを発行し、1 つまたは複数のテーブルをロックし、ユーザー入力を待っているが、何らかの理由で COMMIT または ROLLBACK コマンドを発行していない場合、クエリは idle_in_transaction になります。トランザクション中のアイドル状態のコネクションはハングアップし、この状態がずっと続く可能性があります。PostgreSQL はなぜ待っているのかわからず、トランザクションスレッドを消費している間はトランザクションを自動的に停止しないからです。プロセスが待機しているのはビジネス上の理由がある可能性があるため、この状態は自動的には解決されません。たとえば、ドキュメントが読まれるまでに時間がかかったり、電子メールの送受信に何営業日も待たされたりします。 idle_in_transaction をなくすには、データベースロックを理解してそのロックが発行された理由を判断する必要があります。また、アプリケーションがロックに遭遇したときの処理方法を知っておく必要があります。 idle_in_transaction は簡単に再現できます。まず、テーブルを作成してデータを追加します。次に、 BEGIN と入力してステートメントを開始します。ステートメントの開始後、コミットやロールバックで終了せずに別の列を追加してテーブルを変更します。このアクションにより、2 番目のステートメントが最初のステートメントを終了せずに開始されたため、トランザクションロックでアイドル状態になります。 psql セッションで idle_in_transaction を再現するには、次のコードを実行します。 CREATE TABLE mydbtable ( id int GENERATED BY DEFAULT AS IDENTITY, username varchar (50), password varchar (50)); BEGIN; alter table mytable add column last_update timestamp; 別の psql タブを開き、次のコードを実行します。 SELECT `*` `FROM` mydbtable`;` テーブルにロックがかかっているので何も起こりません。ロックを解除するには、最初のセッションに戻り、コミットまたはロールバックを実行します。 COMMIT`;` コマンドが実行されると、2 番目のセッションはただちに終了します。ロックは、コミットまたはロールバックが行われるまで常に保持されます。 idle_in_transaction セッションを管理するためのベストプラクティスを次に示します。 pg_stat_activity テーブルにクエリを実行して、現在 idle_in_transaction になっているクエリを見つけます。このテーブルとその使用方法の詳細については、 pg_stat_activity を参照してください。 idle_in_transaction を回避するために、トランザクションをより小さくて扱いやすい部分に分割してください。次の点に注意してください。 セッションごとまたはデータベースごとの設定で、指定した時間より長く実行されないようにクエリを準備します。 タイムアウトログを定期的にチェックして、実行時間の長いトランザクションを検出します。 長時間実行されているトランザクションをキャンセルできるように、 idle_in_transaction_session_timeout パラメータを設定することを検討してください。デフォルトは 0 で、タイムアウトがないことを意味します。 pg_stat_activity を使用して、実行時間の長いクエリと、クエリがその状態であった時間をチェックします。 長時間実行されるストアドプロシージャまたは関数をデータベース層からアプリケーション層に移動します。次の点に注意してください。 エラーは、アプリケーションにコーディングされたエラー処理ロジックによって処理できます。 クエリ結果を処理する前にトランザクションを終了するようにアプリケーションをコーディングします。 不要なエラーを避けるため、アプリケーション層とデータベース層で AUTOCOMMIT がオンになっていることを確認してください。 idle_in_transaction トランザクションの pg_stat_activity パラメータを使用してテーブルを監視し、 idle_in_transaction セッションが VACUUM やその他のクエリによるテーブルへのアクセスを妨げていないことを確認してください。これにより、すべてのオープントランザクションとその状態が一覧表示されます。 まとめ この投稿では、PostgreSQL の主要な機能と、 PostgreSQL エンジンの具体的な機能と、アプリケーションアーキテクチャの指針となるベストプラクティスを詳しく説明しました。Amazon RDS for PostgreSQL と Aurora PostgreSQL を使ったアプリケーションを設計する時にデータベース設計とパラメータ設定を検討することは、ダウンタイムを削減できると同時に、データベースパフォーマンスのコストと不便な中断を回避できます。この投稿はこれらのトピックに関する網羅的なリソースではありませんが、アプリケーション開発者向けの追加の PostgreSQL アーキテクチャとチューニングの考慮事項について説明するフォローアップ投稿の入門書となることを意図しています。 コメント欄でコメントやフィードバックをお待ちしています。 この記事のトルコ語翻訳版は こちら からご覧ください。 この記事の翻訳はソリューションアーキテクトの鈴木 大樹が担当しました。原文は こちら です。 著者について Peter Celentano は、アマゾン ウェブ サービスのスペシャリストソリューションアーキテクトで、マネージド PostgreSQL を専門としています。彼は AWS のお客様と協力して、スケーラブルで、安全で、パフォーマンスが高く、堅牢なデータベースアーキテクチャをクラウド上で設計しています。 Tracy Jenkins は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼女はデータベースを扱い、信頼性、コスト、セキュリティに関する推奨事項を提示しながら、パフォーマンスが高く、可用性が高く、スケーラブルなソリューションを顧客が設計できるよう支援することを楽しんでいます。

Amazon SageMaker Canvas でより高速でより直感的に、時系列予測の機械学習モデルを作成できるようになりました。SageMaker Canvas は、ビジネスアナリストが機械学習の経験やコードを記述することなくマウス操作だけで、高精度な機械学習 (ML) モデルを生成できるサービスです。 SageMaker Canvasは、小売業における在庫管理のための時系列予測、製造業における需要計画、旅行やホスピタリティにおける人員計画および顧客計画、財務における収益予測、その他、正確な予測が必要となる多くのビジネス・クリティカルなユースケースをサポートしています。例えば、小売業者は需要予測によって保持する在庫量、物流、マーケティングキャンペーンの計画を立てています。SageMaker Canvas の時系列予測モデルは、高度な技術を使用して統計アルゴリズムと機械学習アルゴリズムを組み合わせ、非常に高精度な時系列予測を作成します。 本記事では、SageMaker Canvas の予測機能の強化について説明し、ユーザーインターフェイス (UI) と AutoML API を使用して時系列予測を行う方法を説明します。SageMaker Canvas UI にはコーディング不要のビジュアルインターフェイスがありますが、API を使用すると開発者はこれらの機能をプログラムから操作できます。どちらも SageMaker コンソール からアクセスできます。 時系列予測の改善 今回のリリースにより、SageMaker CanvasはAutoMLを使用して予測機能をアップグレードし、以前のバージョンと比較して、モデルの構築が最大50％、予測が最大45％高速になりました。これにより、データサイズが最大 100 MB の 750 時系列の一般的なバッチでは、モデルトレーニングの平均時間が 186 分から 73 分に、平均予測時間が 33 分から 18 分に短縮されます。また、ユーザーは Amazon SageMaker Autopilot API を通じてモデル構築関数と予測関数にプログラムでアクセスできるようになりました。同時に構築されたモデルの説明とパフォーマンス・レポートも取得できます。 以前は増分データを導入するにはモデル全体を再トレーニングする必要がありました。これは時間がかかり、オペレーション遅延の原因となっていました。SageMaker Canvas ではモデル全体を再トレーニングしなくても、最新のデータを追加して将来の予測を生成できるようになりました。モデルに増分データを入力するだけで、最新の洞察を今後の予測に使用できます。再トレーニングをなくすことで予測プロセスが加速し、その結果をビジネスプロセスにすばやく適用できるようになります。 SageMaker Canvas が予測に AutoML を使用するようになったことで、SageMaker Autopilot API を通じたモデル構築および予測が可能になり、UI と API の一貫性が確保されるようになりました。例えば、UI でモデルを構築し、次に API を使用して予測を生成するように切り替えることができます。この最新のモデリング手法により、モデルの透明性もいくつかの点で向上しています。 ユーザーは、予測に影響を与える要因について説明可能性レポートで明確に知ることができます。これは、リスク/コンプライアンスチーム、外部規制当局にとって有益です。このレポートは、データセットのどの属性が時系列予測にどのように影響するかを解明します。インパクトスコアを使用して各属性の相対的な効果を測定し、それらが予測値を増幅するか減少させるかを示します。 トレーニング済みのモデルにアクセスし、SageMaker エンドポイントまたは任意のインフラストラクチャにデプロイできます。 AutoMLが選択した予測モデルや、トレーニングで使用されるハイパーパラメータについて、パフォーマンスレポートから確認できるようになります。 SageMaker Canvas UIを使った時系列予測の生成 SageMaker Canvas UI を使えば、クラウドやオンプレミスのデータソースをシームレスに統合、これらを簡単にデータセットにマージ、高精度なモデルのトレーニング、追加データを使った予測、これらをコーディングすることなく実行できます。この UI を使用して時系列予測を生成する方法を見てみましょう。 まず、SageMaker Canvas にデータを取り込みましょう。データは、PC上のファイルや、 Amazon Simple Storage Servide (Amazon S3) のバケット、 Amazon Athena 、 Snowflake など 40以上のソース から取り込み可能です。データを取り込んだら、散布図や棒グラフを使って、それらを探索的に確認することができます。そして、予測対象となる目的変数や予測期間などの必須項目を設定し、すぐにモデルを作ることができます。以下は、複数店舗における売上実績データに基づいた需要予測のビジュアライゼーションの例です。 以下は特定の商品の需要予測の結果です。 SageMaker Canvas UI での時系列予測の包括的なガイドについては、こちらの ブログ記事 をご覧ください。 ワークフローの自動化や アプリケーションへの直接統合が必要な場合は、 API を通じて予測機能にアクセスできます。次のセクションでは、API 使用して予測を自動化する方法を説明したサンプルソリューションを紹介します。 APIを使った時系列予測の作成 API を使用してモデルをトレーニングし、予測を生成する方法について詳しく見ていきましょう。このデモンストレーションでは、企業が顧客の需要を満たすために各店舗の商品在庫量を予測する状況を考えてみましょう。API による時系列予測は、大まかに言うと以下のステップに分かれます。 データセットを準備します。 SageMaker Autopilot ジョブを作成します。 Autopilot ジョブを評価します。 モデルの精度メトリクスとバックテストの結果を確認します。 モデルの説明レポートを確認します。 モデルから予測を生成します。 Autopilotジョブで生成された real-time inference エンドポイントを利用する、または batch transform ジョブを使用します。 Amazon SageMaker Studio ノートブックでの API による予測のサンプル ビジネスでAPIを使ったプログラムで予測システムを手早く本番利用したいという皆さんのために、 GitHub で SageMaker Studio ノートブックのサンプルを提供しています。このノートブックは、パブリックな S3 バケットでサンプルデータを提供し、上記で説明した一連の予測の流れを実行します。ノートブックでは基本的な予測APIの使い方を学習できますが、ご自身のユースケースに合わせてカスタマイズすることもできます。例えば、データスキーマや予測単位（日ごと・週ごとなど）、予測期間など、その他必要なパラメータを必要に応じて変更してください。 まとめ SageMaker Canvasは、ユーザーフレンドリーでコーディング不要のインターフェースを提供することで、時系列予測を民主化します。これにより、ビジネスアナリストでも精度の高い機械学習モデルを作成できます。AutoMLのアップグレードにより、モデル構築が最大50パーセント、予測が最大45パーセント速くなり、モデル構築と予測機能の両方にAPIアクセスが導入され、透明性と一貫性が向上しました。再トレーニングなしで増分データをシームレスに処理できる SageMaker Canvas 独自の機能により、絶え間なく変化するビジネス要求に迅速に適応できます。 SageMaker Canvasは、直感的なUI・汎用性の高いAPIのいずれにおいても、データ統合、モデルトレーニング、予測を簡素化し、データ主導の意思決定と業界全体のイノベーションにとって極めて重要なツールとなっています。 詳細については、 ドキュメント を確認するか GitHub リポジトリにある ノートブック をご覧ください。SageMaker Canvas を使用した時系列予測の利用料金は、 SageMaker Canvas 料金ページ でご覧いただけます。SageMaker Autopilot API を使用する場合の SageMaker トレーニングおよび推論の料金については、 SageMaker 料金ページ を参照してください。 これらの機能は、SageMaker Canvas と SageMaker Autopilot が一般公開されているすべての AWS リージョンで利用できます。リージョンの可用性の詳細については、「 リージョン別の AWS サービス 」を参照してください。 著者について Nirmal Kumar は Amazon SageMaker サービスのシニアプロダクトマネージャーです。AI/MLへのアクセスを拡大することに尽力し、ノーコードおよびローコードのMLソリューションの開発を主導しています。仕事以外では、旅行やノンフィクションの読書を楽しんでいます。 Charles Laughlin は、AWS の Amazon SageMaker サービスチームで働くプリンシパル AI/ML スペシャリストソリューションアーキテクトです。サービスロードマップの策定を支援し、さまざまな AWS のお客様と日々協力して、最先端の AWS テクノロジーとソートリーダーシップを発揮してビジネスの変革を支援しています。チャールズはサプライチェーン管理の修士号とデータサイエンスの博士号を取得しています。 Ridhim Rastogi は、AWS の Amazon SageMaker サービスチームで働くソフトウェア開発エンジニアです。彼は、AI/ML を通じて現実世界の問題を解決することに重点を置いた、スケーラブルな分散システムの構築に情熱を注いでいます。余暇には、パズルを解いたり、フィクションを読んだり、周囲を探索したりするのが好きです。 Ahmed Raafat は AWS のプリンシパルソリューションアーキテクトで、20 年のフィールド経験を持ち、5 年間は AWS エコシステムに携わってきました。彼はAI/MLソリューションを専門としています。彼はさまざまな業界で豊富な経験を持っており、多くの企業顧客の信頼できるアドバイザーとなって、クラウドへの移行のシームレスなナビゲーションと加速を促進しています。 John Oshodi は、英国ロンドンを拠点とするアマゾンウェブサービスのシニアソリューションアーキテクトです。彼はデータと分析を専門としており、多数の AWS 企業顧客のテクニカルアドバイザーを務め、クラウドへの移行をサポートし、加速させています。仕事以外では、新しい場所に旅行したり、家族と一緒に新しい文化を体験したりすることを楽しんでいます。     この記事の翻訳はソリューションアーキテクトの横山誠が担当しました。原文は こちら です。

バーチャルリアリティ (VR) ストーリーテリングの技術を進歩させることは、「Population One」、「Onward VR」、「Beat Saber」などの人気のマルチプレイヤーゲームを提供する Meta の Oculus Studios の主な目的の 1 つです。 Meta の Oculus Studios が進化し続ける中、信頼性が高くスケーラブルなゲーム開発と、VR ストーリーテラーが利用できるホスティングバックエンドを確立することが重要です。Meta の Oculus Studios コアエンジニアリングチームは、マルチプレイヤー VR ゲームのホスティングとマッチメイキングサービスを Amazon GameLift で標準化することにしました。 課題に正面から向き合う Meta の Oculus Studios 部門は複数の VR スタジオで構成されており、それぞれが独自の作業方法を持っています。これによりユニークなプレイヤー体験の提供が保証できる一方で、ゲーム開発やホスティングが複雑になる可能性もあります。エンジニアリングチームは、Unity から Unreal Engine まで、さらにはカスタマイズされたゲームエンジンやプラットフォームまで、幅広いゲームエンジンをサポートする必要があります。各スタジオでカスタマイズされたマルチプレイヤーシステムを理解して使いこなせるようにするには、十分な準備期間も必要です。その他にも、ライブサービスの構築、クロスプラットフォームのサポート、チャットなどの機能開発、各スタジオのリリースプロセスの統合などの考慮事項があります。 エンジニアリングチームは、品質保証、テストとリリースの手法、オフィスのセットアップといった事項の調査と統合も担当しています。サイロ化された進め方を維持するのは不可能であると認識したエンジニアリングチームは、ゲームホスティングとマッチメイキングのソリューション検討に取り組み始めました。 共通の目標を持つように調整する エンジニアリングチームは、将来のスタジオも一貫してサポートできるよう、シンプルで再現性のある戦略を実現したいと考えていました。目標は、開発者の作業速度を高め、新しいマルチプレイヤー体験の作成や機能の追加を効率化することでした。各スタジオがタイトル間のサポート、拡張、メンテナンスを管理する方法を進化させることも、このビジョンの一部でした。チームは、新しいゲームや機能の開発を加速させるなど、共通の目標を設定しました。 しかし、このビジョンを現実に変えるには、すべてのスタジオの信頼が必要です。チームは、開発中のソリューションがオーバーヘッドの削減にどのように役立つかを実証し、すべてのスタジオが連携できるようにする方法を見つける必要がありました。そして彼らは共通の目標を持つことができました。短期的には、チームは将来のスタジオ向けに Meta のOculus Studiosエコシステムへの統合を加速し、すべてのスタジオでのサポートを増やし、よりスケーラブルなソリューションを提供し、すべてのゲームタイトルの回復力と信頼性を向上させることを目指しました。将来を見据えて、チームは一般的なインテグレーション、共有パターン、コードをより簡単に再利用できるようにすることで、新しいゲームや機能の開発を加速させています。 最適なテクノロジーを見つける Meta の Oculus Studios は、明確な目標、それに伴う課題の理解、VR スタジオとの連携を踏まえて、利用可能なマルチプレイヤーゲームホスティングとマッチメイキングソリューションの検討を開始しました。計画としては、「Beat Saber」でエンドツーエンドのハイブリッドソリューションを試験運用し、そのマルチプレイヤーゲームをピアツーピア (P2P) ホスティングモデルではなく専用ゲームサーバーに標準化することでした。サービスレベルアグリーメント (SLA)、マッチメイキングの柔軟性、グローバルリージョンでの可用性、機能、サポートはすべて、技術要素の意思決定プロセスにおいて重要な役割を果たしました。 その後、研究開発 (R&D) が行われ、チームは最終的に Amazon GameLift の導入を決定しました。Amazon GameLift は完全マネージド型のサービスで、マルチプレイヤーゲーム専用のゲームサーバーを簡単にホストおよびスケーリングできます。Meta の Oculus Studios Core Engineering である Mick Afaneh 氏は、この戦略について次のように語っています。「私たちは、大規模サービスに付随する固有の課題を理解しているだけでなく、場所に関係なく最適なプレイヤー体験を確保し、世界規模での規模拡大とスタジオ間の開発コストの削減に役立つテクノロジーを提供してくれるサービスプロバイダーと提携したいと考えていました。 Amazon Web Services for Games と Amazon GameLift は理想的にフィットしました。」 舞台裏のテクノロジー Amazon GameLift により、Meta の Oculus Studios はゲームサーバーのビルドをサービスにアップロードし、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのサイズを選択できるようになりました。その後、このテクノロジーはゲームセッションを作成し、複数の AWS リージョンにまたがる EC2 インスタンスのフリートを構築します。オートスケーリングなどの統合機能により、Meta の Oculus Studios はアクティブなゲームセッションの数に基づいて EC2 フリートを簡単にスケールアップおよびスケールダウンできるため、コスト削減に役立ちます。Meta の Oculus Studios の基盤となるゲームホスティングとマッチメイキングのインフラストラクチャを Amazon GameLift が管理するため、VR スタジオは魅力的な VR コンテンツを作成するために使える時間を増やすことができています。AWS のインフラストラクチャはグローバルで、かつレイテンシーの影響を受けやすいアプリケーションをエンドユーザーの近くで実行できる AWS Local Zones もあるため、Meta の Oculus Studios は地理的に離れたプレーヤーにもレイテンシーを最小限に抑えた VR ゲーム体験を提供できます。 1 年以上前に AWS とのコラボレーションを開始して以来、Meta の Oculus Studios はゲームホスティングとマッチメイキングの標準化された手法を開発し、すべてのマルチプレイヤータイトルを Amazon GameLift に移行してきました。Afaneh 氏は次のように締めくくりました。「AWS とのコラボレーションと Amazon GameLift の活用により、当社のスタジオが体験を提供する方法が合理化され、常に進化し続けている信頼性が高くスケーラブルなソリューションのメリットが得られました。同時に、スタジオが素晴らしいゲームの制作に集中するための時間を増やすことができました。今では、スタジオの内外でいくつものサポートを受けていますが、それはかけがえのないものです。」 Amazon GameLift サービスとスタンドアロンのマルチプレイヤー機能の詳細については、 Amazon GameLift のページ をご覧ください。 この記事の翻訳はソリューションアーキテクトの西坂 信哉が担当しました。原文は こちら です。

はじめに 本日、Amazon Elastic Kubernetes Service (EKS) の Kubernetes バージョンに対する延長サポートのプレビューを発表します。これにより、特定の Kubernetes バージョンが Amazon EKS で一般提供されてから最大 26 か月間、Amazon EKS クラスターでご利用頂けるようになります。延長サポートは、本日から Kubernetes 1.23 バージョンを対象に、すべての Amazon EKS ユーザーに対して無料でプレビューされます。 Kubernetes のようなオープンソースソフトウェアにおいて、コラボレーションを可能にし、エコシステムを横断して互換性を確保するために、バージョンは重要な構成要素です。Amazon EKS の責任共有モデルの一環として、ユーザーはクラスターを最新の状態に保つ必要がありますが、Kubernetes の新規バージョンのリリースペースや複雑さは、 企業にとって追従が難しい場合があります。我々は、Kubernetes のバージョンアップグレードをより簡単にするためのサポートを提供したいと考えています。 Amazon EKS の延長サポートは、クラスターのセキュリティ体制を損なうことなく、Kubernetes のバージョンアップグレードを計画する柔軟性をユーザーに提供します。延長サポートが役立つと思われる一般的なシナリオは次のとおりです。 コードフリーズへの対応 : 商業上重要なイベント(年末商戦、会計年度末の財務報告、新製品発売など)に備えて、環境を凍結する必要がある場合があります。Kubernetes バージョンの廃止に向けて急いで計画を立てるのではなく、延長サポートによりビジネスを優先させ、アップグレードを自分にとって最も都合のよいタイミングで実施できます。 サードパーティの依存関係の管理 : クラスター内で、セキュリティコントロールやインフラ管理機能などを実現するために、カスタムまたはサードパーティ製のソフトウェアを利用している場合があるでしょう。ベンダーが、Kubernetes の特定バージョン用のコントローラやその他のソフトウェアのリリースと認定に遅れることがあります。この場合、延長サポートにより、ユーザーとベンダーは、ソフトウェアの認定バージョンをテストしてリリースするための時間を確保できます。 延長サポートの機能 Kubernetes プロジェクトは、最新の 3 つのマイナーバージョンに対してリリースブランチを 維持 しています。各バージョンは、安定版のリリース (dot 0) から 14 か月の間、Kubernetes コミュニティからサポートを受けます。このサポートが終了すると、アップストリームのプロジェクトはそのバージョンに対するバグ報告やパッチのリリースを受け付けなくなります。Amazon EKS の標準的なバージョンサポート期間は、このアップストリームのサポート期間に合わせています。延長サポートにより、Amazon EKS のクラスターは、当初の 14 か月のサポート期間後、最大 12 か月間そのバージョンで稼働し続けることができます。Kubernetes のバージョンに対する 14 か月の標準サポートが終了すると、そのバージョンで稼働しているクラスターは自動的に延長サポートに入ります。アクションや設定変更は必要ありません。延長サポート期間の終了時に、非推奨バージョンを使用しているすべてのクラスターは、自動的に次に古いバージョンにアップグレードされます。クラスターで Kuberentes バージョンの延長サポートを利用しない場合は、標準サポートの期間内にアップグレードが可能です。 延長サポートの対象 延長サポート期間中の Amazon EKS クラスターは、 Kubernetes のコントロールプレーンに対する継続的なセキュリティパッチを受け取ります。加えて、Amazon VPC CNI、kube-proxy、CoreDNS アドオン、AWS が公開した Amazon Linux と Bottlerocket 向けの EKS Optimized Amazon Michine Images(AMI)、EKS Fargate ノードに対して重要なパッチが提供されます。また、延長サポート期間中のすべてのクラスターは、AWS からテクニカルサポートを受けることができます。 延長サポートは、AWS から提供される Kubernetes 固有のコンポーネントをすべてカバーしますが、AWS が公開した Amazon Linux および Bottlerocket 向けの EKS Optimized AMI に対してのみサポートを提供します。つまり、延長サポートを利用している間、AWS が公開した EKS Optimized AMI 上にオペレーティングシステム (OS)、カーネルなど、新しいコンポーネントが含まれる可能性を意味しています。例えば、 Amazon Linux 2 は 2025 年に EoL を迎えますが、AWS が公開する EKS Optimized Amazon Linux AMI は、新しい Amazon Linux OS を使用してビルドされるでしょう。Amazon EKS は、Kubernetes バージョンごとに重要なサポートライフサイクルとの不一致を発表し、ドキュメント化します。 本日時点では、Amazon EBS CSI ドライバーや Amazon EFS CSI ドライバー、 AWS Distro for OpenTelemetry (ADOT), Amazon GuardDuty エージェント、AWS Marketplace add-ons for EKS、Windows AMI、Amazon EKS Distro など、その他の Amazon EKS アドオン は延長サポートの対象外です。 プレビューで利用可能 Kubernetes バージョンの延長サポートは、Kubernetes バージョン 1.23 以上で動作する Amazon EKS クラスターを対象にプレビューとして提供されます。追加のアクションや設定の変更は必要ありません。バージョン 1.23 で動作するクラスターは、2024 年 10 月にバージョン 1.23 の延長サポート期間が終了した時点で、自動的にバージョン 1.24 にアップグレードされます。 プレビュー期間中は、延長サポートに対して追加コストはかかりません。延長サポートは 2024 年初旬の利用可能を予定しており、延長サポートを利用するクラスターごとに追加料金が発生する予定です。もちろん、ユーザーは標準サポート期間内にアップグレードできます。この場合、既存の Amazon EKS の利用料金 が適用されます。 Kubernetes バージョンの延長サポートは、Amazon EKS のユーザーがクラスターをアップグレードする際の選択肢を提供します。 Amazon EKS バージョン 1.28 で発表されたコントロールプレーン/ノードのスキューポリシーの変更 に加えて、AWS からの完全なセキュリティパッチ、バグ修正、サポートを受けながら、クラスターのアップグレード頻度を減らすことができます。サポートされている Amazon EKS のバージョンと重要なリリース日を確認するには、 リリースカレンダー をブックマークすることをお勧めします。 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

この記事では、 Lambda@Edge , Amazon DynamoDB , AWS Lambda , および AWS StepFunctoins を使用して Amazon CloudFront のタグベースでのキャッシュ削除を実装する方法について説明します。また、タグベースのキャッシュ削除をデプロイしてテストするのに役立つリファレンスアーキテクチャとサンプルコードを提供します。 まず、ページをまとめてタグ付けすると便利なユースケースをいくつか紹介します。 ブランドページ – 直販企業(D2C)は、お客様や検索エンジンのボットが発見し易いように、ブランドや製品に関する情報をウェブサイトやモバイルアプリケーションにまとめています。一般的に、ブランドページ、製品リストページ、製品仕様ページと階層的にまとめています。これらは、カテゴリーページやあらかじめ用意された検索語ページなどの補助的なページに結び付けられることもあります。これらはすべてつながっており、ブランドや製品仕様の更新に影響されます。例えば、自動車メーカーが、ブランド、モデルリスト、詳細仕様のページを、ブランドと製品コードを使ってグループ化したい場合があります。 ニュースポータル – ニュース速報やスポーツイベント、記者発表などのイベントをライブ中継する Web サイトでは、写真、ビデオ、スコアティッカー、スコアボード、統計情報などの豊富なマルチメディアコンテンツを含むページを頻繁に更新する必要があります。イベントに関連するすべてのアセットを無効にすることで、視聴者は新しいコンテンツにいち早くアクセスすることができます。 複数のレンディションを持つ画像サイト – 画像などのリッチメディアコンテンツは、デバイスの特性に基づいて最適化されるため、同じコンテンツが複数表示されることになります。例えば、レスポンシブデザインでは、画像はサムネイルと異なるサイズで表示されることがあります。元の画像を更新するとそのすべての表示が更新されるはずですが、それらがグループ化されていれば、より簡単になります。 これらすべてのシナリオで、1 つ以上のタグに基づいてコンテンツをグループ化し、個々のファイルではなくタグに基づいてキャッシュを削除することができます。キャッシュ削除ワークフローにインテリジェンスを追加することで、コンテンツの更新時に複数のファイルを更新する必要がある際のオペレーション効率を向上させることができます。 CloudFront には、ビューワーがアプリケーションのバックエンドを操作するときに (リクエストまたはレスポンスの) 情報を処理する 4 つのイベントトリガーが用意されています。この機能といくつかの AWS サービスを利用して、タグベースのキャッシュ削除ワークフローを実装します。CloudFront イベントトリガーの詳細については ここ を参照してください。 ソリューションの概要 このソリューションは、2 つのコンポーネントで構成されています： タグの取り込みワークフロー ：タグとコンテンツのマッピングの取り込みと、永続化を担当します。各コンテンツURLは、あらかじめ定義されたレスポンスヘッダーに1つ以上のタグを指定することができます。 タグベースのキャッシュ削除ワークフロー ：1 つまたは複数のタグに基づくキャッシュ削除を担当します。このシステムは、タグとコンテンツのマッピングを読み取り、重複を排除し、CloudFront の 無効化のクォータ 内に収まるように制御された方法でキャッシュ削除を実行する役割を担っています。 それでは、各コンポーネントの実装の詳細を見ていきましょう。 タグの取り込みワークフロー 図1: タグの取り込みワークフロー タグの取り込みワークフローの一環として、アプリケーションのバックエンドから来るレスポンスヘッダーを捕まえるためのリスナーを設定します。アプリケーションは、事前に定義されたレスポンスヘッダーに 1 つ以上のタグを送信します。この追加メタデータは、URL と 1 つ以上のタグ間のマッピングを維持するために使用されます。 Chrome デベロッパーツールから見たレスポンスヘッダーの例を以下に示します。’Edge-Cache-Tag ’ は、3 つのタグレベルの情報を保持し、カンマで区切られていることに注意してください。検索する特定のレスポンスヘッダーをカスタマイズしたり、タグをカンマまたはスペースで区切ったりできます。これらはオリジンレスポンスのヘッダーであるため、Lambda@Edge 関数は処理後にこれらのヘッダーを削除することに注意してください。 図2: キャッシュタグを含むオリジンレスポンスヘッダーの例 タグ取り込みワークフロー : Lambda@Edge 関数を、ビヘイビアの ’Origin-Response (オリジンレスポンス)’ に関連付けます。この関数は、キャッシュミス時と、CloudFront がオリジンからレスポンスを受信する直前にのみ実行されます。そのため、冗長な情報でダウンストリームのタグ取り込みシステムに負荷をかけすぎることなく、タグとコンテンツ間のマッピングをキャプチャできる理想的なイベントトリガーになります。 Amazon Simple Notification Service ( Amazon SNS ) トピックは、Lambda@Edge が実行される Regional Edge Cache ( REC ) 毎に作成されます。これは、タグと関連する URL を取得し、永続化するための情報を中継する際の待ち時間を最小化するために行われます。 選択した AWS リージョンにデプロイされた Amazon Simple Queue Service ( Amazon SQS ) は、前述の各リージョンにある Amazon SNS トピックをサブスクライブしています。これにより、異なるリージョンからタグ情報を中央のロケーションに集めることができます。 スケジュールで起動するリージョンのLambda関数：Amazon SQSキューからメッセージを取得し、 DynamoDB テーブルに保存します。 なお、Lambda@Edge 関数は、リクエストされた URL に対してオリジンからエラーが返された場合でも実行されることに注意してください。HTTP 200 OK のみをフィルタリングして動作させたい場合は、HTTP ステータスコードのソースコードに追加のチェックを組み込むことができます。 タグベースのキャッシュ削除ワークフロー 図 3: タグベースのキャッシュ削除ワークフロー タグベースのキャッシュ削除ワークフローを起動するために特権ユーザが下記のアクションを行います。 CloudFront ディストリビューション ID からキャッシュ削除する 1 つ以上のタグを含むJSONペイロードを送信します。 Step Functionsワークフローは、最初に DynamoDBテーブルからマッピングされたURLを取得し、パージキューにポストします。 スケジュールベースの Purge Lambda 関数は、CloudFront に送信されたアクティブなキャッシュ削除の数を監視し、パージキューにメッセージを送ります。この Lambda 関数は、キャッシュ削除 API で許可された制限内に収まるように、CloudFront のキャッシュ削除 API に新しい URL を送ります。 リファレンスソリューション リファレンスソリューションの GitHubリポジトリ はこちらです。 前提条件 リファレンス・ソリューションを展開するために下記が必要です。 あらかじめ定義されたレスポンスヘッダー (デフォルトは ‘Edge-Cache-Tag’) でタグを送信するバックエンドアプリケーション(オリジン) AWS Cloud Development Kit (AWS CDK) を使用してリソースを作成する権限のある AWS クレデンシャル テストするための CloudFrontディストリビューション ソリューションのテスト リファレンスソリューションの導入とテストには、主に次の 5 つのステップが必要です。 GitHubリポジトリ の指示に従いソリューションをデプロイします。 Lambda@Edge のオリジンレスポンス関数を CloudFront のディストリビューションに関連付けてテストします。 新しく作成された DynamoDB テーブルにアクセスし、タグが取り込まれていることを確認します。 Step Functions ワークフローを使用して、タグを指定したキャッシュ削除リクエストを送信します。 CloudFront コンソールからタグ付き URL のキャッシュが削除されたことを確認します。 ステップ 1 : GitHub リポジトリに従ってソリューションをデプロイする プロジェクトのビルド方法に関する説明とともに、GitHub リポジトリ からリファレンスソリューションを見つけることができます。ソリューションをデプロイするために設定できるパラメータについては、’Steps to build’ セクションを参照してください。このソリューションでは、オリジンレスポンスからタグを受信するための Lambda@Edge 関数をデプロイします。ソリューションは一度デプロイするだけでよく、オリジンレスポンストリガーを使用して Lambda@Edge 関数をさまざまな CloudFront のビヘイビアに関連付けることができます。 env.sh ファイルのキャッシュタグヘッダーやタグ区切り文字など、ソリューションのパラメーターを指定できます。デフォルトでは、ソリューションでは “Edge-Cache-Tag” レスポンスヘッダーを使用してオリジンからキャッシュタグを受け取ります。複数のタグをカンマで区切って指定することが出来ます。 オプションとして、前述のパラメーターに加えて、DynamoDB のテーブルに古いレコードが蓄積されるのを防ぐために、各タグに Time-To-Live (TTL) を指定することができます。“TAG_TTL_NAME” は、TTL を含むオリジンレスポンスヘッダーを秒単位で指定します。デフォルトのヘッダー名は “tag-ttl “で、オリジンがレスポンスを返す際にヘッダー値を指定する必要があります。env.sh ファイルの “TAG_TTL_DEFINED_BY ” は、TTL 計算においてどのレスポンスヘッダーを優先するかを指定します。例えば、”TAG_TTL_DEFINED_BY=tag-ttl” を指定した場合、”tag-ttl” ヘッダーに設定された値が最初に優先され、次に ‘Cache-Control’ ヘッダーに設定されている値が優先され、逆も同様です。TTLを完全に無効にしたい場合は、”TAG_TTL_DEFINED_BY” に空の値を指定してください。 Lambda@Edge 関数は us-east-1 リージョンにデプロイされ、他のアーティファクトは複数のリージョンにデプロイされることに注意してください。DynamoDB テーブル と Step Functions ワークフロー は、設定ファイルのプライマリーリージョンとして指定されたリージョンにデプロイされます。リージョナルスタックがデプロイされる他のリージョンは us-east-2 , us-west-2, ap-south-1, ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, eu-central-1, eu-west-1, eu-west-2, sa-east-1 になります。 Amazon CloudFront のリージョン別エッジキャッシュの詳細については、 こちら を参照してください。 ステップ 2 : Lambda@Edge オリジンレスポンス関数を CloudFront ディストリビューションに関連付けてテストする デプロイが完了すると、AWS CDK はタグを取り込むための Lambda@Edge 関数の ARN を出力します。ARN をコピーして、関数を CloudFront のビヘイビアに関連付けます。 図 4: タグ埋め込み用 Lambda@Edge 関数のARNの出力 Amazon CloudFront コンソールに移動し、オリジンレスポンスでタグを返すオリジンを含む CloudFront ディストリビューションを選択または作成します。“Behaviors (ビヘイビア)” タブで、タグ取り込み Lambda@Edge 関数に関連付けるキャッシュビヘイビアを選択し、“Edit (編集)” を選択します。 図 5: タグベースのキャッシュ削除のためのビヘイビアを選択 ビヘイビア設定で、“Function associations (関数の関連付け)” セクションまでスクロールします。オリジンレスポンストリガーにLambda@Edge を選択し、AWS CDK の出力にある Function ARN を貼り付け、Save changes (変更を保存)します。 図6: タグ取り込み Lambda@Edge 関数の関連付け テストする前にキャッシュを削除します。ディストリビューションドメイン名を確認し、CloudFront からコンテンツをダウンロードして、キャッシュにデータを入力し、オリジンからタグを取り込みます。“x-cache” レスポンスヘッダーの値は、最初のリクエストでは “Miss from cloudfront”、それ以降のリクエストでは “Hit from cloudfront” でなければなりません。 図 7: CloudFront レスポンスヘッダーのキャッシュ(x-cache)を確認する ステップ 3 : 新しく作成した DynamoDB テーブルに移動して、タグの取り込みを確認する ソリューションをデプロイするために選択したリージョンの DynamoDB コンソールに移動します。“ Table (テーブル)” から ” Explore items (項目を探索)“ に移動すると、” TagPrimaryStack-{distributionID} “ という名前で作成された新しいテーブルが見つかります。 {DistributionId} は、前のステップで使用した CloudFront ディストリビューションのディストリビューション ID です。 CloudFront 継続的デプロイ機能 を使用してステージングディストリビューションでテストする場合は、ステップ 2 で説明されているようにステージングディストリビューションも設定する必要があることに注意してください。これにより、ステージング CloudFront ディストリビューション ID を使用して別の DynamoDB テーブルが作成されます。 CloudFront にキャッシュされたコンテンツのキャッシュタグとタグ付き URI を含むエントリがテーブルに入力されていることを確認できます。次の図の例は、さまざまな車の年式、モデル、色をタグ付けした例を示しています。 図 8: DynamoDBに登録された tag/URL を確認 テーブルエントリから、次のステップでキャッシュ削除に使用するタグを選択し、そのタグに関連付けられた URI を書き留めます。 ステップ 4 : Step Functions ワークフローを使用してタグによるキャッシュ削除リクエストを送信する ソリューションをデプロイするために選択したリージョンの Step Functions コンソールに移動して、ステートマシンのリストからステートマシン “ TagPrimarystackPurgeWorkflow ” を探します。ステートマシンを選択し、“View details (詳細を表示)” を選択します。 詳細画面の “ Executions (実行) “ タブで ” Start execution (実行を開始) “ を 選択 し、タグによるキャッシュ削除を作成します。 ”Start execution (実行を開始)“ 画面で、CloudFront ディストリビューション ID とキャッシュ削除に使用したいタグを指定した後、”Input (入力)“ セクションに次の文字列を入力します。次に、”Start execution (実行を開始)“ を選択します。複数のタグは OR ステートメントのように個別に評価されることに注意してください。 { "distributionId": "CLOUDFRONT_DISTRIBUTION_ID", "tags": ["TAG1","TAG2"] } この例では “ year-2021 ” と “ model-suv ” というタグを使用してキャッシュを削除をします。 図 9: タグベースによるキャッシュ削除の実行例 実行の詳細タブで、“Execution Status (実行ステータス)” が “Succeeded (成功)” になっていることを確認します。 図 10: 実行ステータスを確認 ステップ 5 : CloudFront コンソールからタグ付き URL のキャッシュ削除を確認する CloudFront コンソール に移動し、使用している CloudFront ディストリビューションを選択します。次に、“Invalidations (キャッシュ削除)” タブに移動して、キャッシュ削除のリストを表示します。 キャッシュ削除 ID のリストから、送信されたキャッシュ削除リクエストを見つけて選択し、“View details (詳細を表示)” を選択します。 “Invalidation details (キャッシュ削除の詳細)” 画面で、ステータスが “Completed (完了済み)” であることと、“Object paths (オブジェクトパス)” に、キャッシュ削除リクエストで送信したタグ値でタグ付けされたURIが含まれていることを確認します。 図11: タグ付き URI のキャッシュ削除を確認 ソリューションの実行にかかる見積もり費用と、異なるAWSサービスコンポーネントによる内訳は、リポジトリの ’ Pricing Calculation ’ セクションで確認できます。 トラブルシューティングについては、リポジトリの ‘ Troubleshooting ’ セクションを参照してください。 クリーンアップ テストが完了したら、“cdk” ディレクトリで destroy.sh スクリプトを実行することで、ソリューションを削除し AWS CDK プロジェクトによって作成されたリソースに関連するコストを回避できます。スクリプトを実行する前に、Lambda@Edge 関数がすべての CloudFront ビヘイビアと関連付けられていないこと、および AWS CDK によって作成された CloudFormation スタックの削除保護が 無効 になっていることを確認してください。AWS CDK プロジェクトが破棄されたら、DynamoDB テーブルも手動で削除する必要があります。このスクリプトでは、他の AWS CDK プロジェクトに使用できる AWS CDK ブートストラップ CloudFormation スタックと Amazon Simple Storage Service (Amazon S3) バケットは削除されません。スタックとバケットを使用する予定がない場合は、手動で削除することが出来ます。 まとめ 今回のまとめとして、タグベースのキャッシュ削除を使用できるシナリオを学んだ後、 AWS Lambda , Lambda@Edge , Amazon DynamoDB , AWS Step Functions , Amazon Simple Notification Service(SNS) , Amazon Simple Queue Service(SQS) などのサービスを使用して Amazon CloudFront のタグベースのキャッシュ削除ソリューションを実装する方法を説明しました。このソリューションでは、1つまたは複数のタグに基づいてキャッシュされたコンテンツをグループ化し、パスやファイルではなくタグに基づいてキャッシュを削除することができます。キャッシュ削除ワークフローにさらなるインテリジェンスを加えることで、コンテンツの更新時に複数のキャッシュファイルをリフレッシュする必要があるユースケースにおいて、運用効率を向上させることができます。 この記事は、 Tag-based invalidation in Amazon CloudFront を翻訳したものです。 このブログの翻訳は Solutions Architect の深井 宣之が担当しました。

調査に参加した通信事業者の半数が今後2年以内の生成系AIの活用を計画し、生成系AIへの支出が現在の最大6倍に拡大すると予測 AWS通信およびエッジクラウド担当 チーフテクノロジストIshwar Parulkar（イシュワール・パルルカー） 生成系AIは、あらゆる場で活用され、すべての産業に大きなインパクトをもたらすとAWSは考えています。生成系AIは機械学習の普及に続く新たな波であり、通信業界を含む業界で、お客様体験や多様なビジネスアプリケーションを革新する可能性を秘めています。 AWSは、通信業界における生成系AIへの展望や論調、活用状況に対する理解を深めるため、戦略コンサルティング企業であるAltman Solonと協力し、北米、西欧、アジア太平洋地域の通信事業者の幹部100名以上を対象とした調査を実施しました。主な調査結果は以下のとおりです。 1.  生成系AIの活用は今後2年間で大きく拡大 通信事業者の4つの業務領域（製品・マーケティング、カスタマーサービス、ネットワーク、社内IT）をまたぐ17のユースケースについて調べたところ、生成系AIを既に活用しているか、活用に向けて取り組んでいるとした回答者は全体の19%でした。この数値は今後、さらに拡大する見込みで、調査結果によると1年以内に34%、2年以内に半数近く（48%）に達する見込みです。これに伴い、生成系AIへの支出も現在の最大6倍に急拡大する可能性があります。この急拡大を牽引するユースケースはチャットボットですが（詳細は後述）、通信事業者の64%は、検討している生成系AIのユースケースの多くが、既存のアプリケーションやプロセスではまだ実現されていない新たなアプリケーションだと述べています。 2. 北米の通信事業者が生成系AIの活用で他地域をわずかにリード 生成系AIの活用では、北米の通信事業者がわずかに先行しています（22%が活用、または活用に向けて既に取り組む）。欧州の通信事業者（同19%）は、EUの一般データ保護規則（GDPR）などのデータレジデンシーに関する域内規制のため、生成系AIの活用には、より慎重な姿勢を見せています。特に北米以外の通信事業者にとっては、AI活用やデータ規制、データレジデンシーに関する現行および今後の規制が重要な考慮点となります。中国やEUの多くでAI規制やAIへの監視が強化されているのに対し、米国やインドでは、規制や監視に関して、より消極的です。 アジア太平洋地域の通信事業者（同16%）は、他地域と比べ緩やかなデータ規制の環境にいますが、言語などのローカライゼーションの課題に面しています。生成系AIの多くは大規模言語モデル（LLM）をベースとしており、特定言語のデータコーパスによるトレーニングが必要です。現在の主要なLLMの多くは英語で構築・提供されており、AWSはこの溝を埋めるべく取り組んでいます。例えば、2023年7月に日本で発表した「 AWS LLM開発支援プログラム 」は、日本におけるLLM開発の加速を支援するもので、総額600万米ドル規模のAWSクレジットを提供するなど、LLMの多様性を推進する取組を進めています。 3.  顧客対応チャットボットが生成系AIのユースケースとして、いち早く普及 生成系AIがまずは顧客対応チャットボットに取り入れられていることは自然な流れであり、本調査でも広く活用される見込みであることが分かりました。回答者の92%が、導入の可能性の高いものとしてカスタマーサービスとチャットボットを挙げています。そのうち63%が、すでに開発を進めていると回答しました。 これは既存の基盤モデルを活用するものであり、最初の段階としては正しい方向である一方、将来的には生成系AIがネットワーク運用を支援すると、AWSは考えています。例えば、生成系AIは、通信事業者がネットワーク要素をインストールする際に参考とするマニュアルからデータを取り込むことができます。このデータをチャットボットと組み合わせることで、プロンプトに基づくインタラクティブなガイダンスを提供できるようになり、インストール作業のスピードアップや簡素化につながります。 他の主要なユースケースは、カスタマーサービス、ITにおけるガイド付き支援や文書作成など、社員の生産性向上を支援するものです。 活用ステージ別生成系AIユースケース （全回答者に占める割合。回答者数はユースケースごとに異なる） ※現在、取り組んでいる、または、高い可能性のもとで検証しているとした回答者の割合 4.   データセキュリティとガバナンスが生成系AI活用における最大のチャレンジであり、実現に向けた重要なイネーブラー 生成系AIの活用には、一方で課題があります。本調査に協力した通信事業者の約3分の2（61%）が、データセキュリティ、プライバシー、ガバナンスに関する懸念を表明しました。通信事業者が自社の業務に生成系AIを活用するには、各社が保有する膨大な量のデータが必要となります。広く利用可能なLLMはありますが、自社保有のデータがこうしたモデルそのものに組み込まれることには、知的財産権上の懸念があります。 ある通信事業者のIT部門責任者は、次のように話しています。「当社データのセキュリティを確保し、第3者に使用されないよう徹底する必要があります」 AWSはこうしたお客様の懸念を踏まえ、Amazon Bedrockではお客様のデータが利用する基盤モデルの学習に使用されないようにする機能が組み込まれています。お客様のデータはプライベートかつセキュアに保護されます。 この調査ではまた、アーリーアダプターのうち、データ習熟度上位30%の組織においては、生産性向上以外のユースケースでの生成系AIの活用が進んでいることが明らかになりました。例えば、製品・マーケティングなど、収益創出を目指したユースケースです。データ活用が進むこうした組織では、AIを専門とするセンターオブエクセレンスが設置されていること、高度なデータアナリティクスの活用が進んでいること、最新のデータ基盤（クラウドなど）が整備されていることなど、共通の特徴があります。 5.  通信事業者は、自社開発よりも、既存モデルの活用を想定 生成系AI活用における課題として技術的リソースの不足を挙げる通信事業者もありました。このような背景を考えると、社内で基盤モデルを構築したいと回答した通信事業者は15%にとどまり、その他は既存の基盤モデルの活用を想定していることも驚きではありません。回答者の約4分の3（65%）は既存の基盤モデルを社内の専有データで追加学習し、各社それぞれのニーズに対応させたいと考えています。私たちは、データ基盤のモダナイゼーションにおいて強固な基礎を保有するアーリーアダプターが独自の基盤モデルを構築する15%の層となり、マネタイゼーションに向けて新たな道を切り拓くものと考えています。 通信事業者はファインチューニングされた基盤モデルとともに、AWSのような大規模言語モデルへのアクセスを提供するベンダーに開発環境や専門的なサービスを提供してほしいと考えています。あるワイヤレス通信事業者の高度アナリティクス担当ゼネラルマネージャーが、「個人的には、これが通信業界における生成系AI活用において重要な促進剤になると思います」と述べているように、回答した通信事業者の44%は、フルマネージドサービス基盤を活用し、その基盤上で提供される基盤モデルを利用してアプリケーションを構築したいと考えています。 生成系AIはお客様のビジネスや顧客価値の提供を変革する大きな可能性を秘めています。私たちは、企業のニーズに合った柔軟なアプローチを提供することに注力しており、AWS InferentiaやAWS Traniumなど機械学習に最適化したAWS独自設計のクラウドインフラを活用して自社で基盤モデルを構築する、あるいは、Amazonの基盤モデル（Amazon Titan、Alexa）やサードパーティーの基盤モデルを活用してアプリケーションを開発する、Amazon BedrockやAmazon SageMaker Jumpstartといったサービスを活用して、基盤モデルにデータを追加してファインチューニングするの複数の選択肢をご用意しています。加えて、基盤モデルやAI、機械学習テクノロジーに関する専門知識なしにご利用いただける、Amazon CodeWhisperer、Amazon Quicksightなどの生成系AIアプリケーションもあります。 どのように生成系AIへの取り組みに着手するにせよ、通信事業者にとって最も重要なのは、今すぐ試行錯誤を開始することです。 生成系AIの現在、そして将来的な活用を展望した調査結果の詳細は、 調査レポート（英語） よりご覧ください。 このブログは、英文での 原文ブログ を参照し、アマゾン ウェブ サービス ジャパン合同会社　広報チームが翻訳・執筆しました。

みなさん、こんにちは、カスタマーソリューションマネージャー (CSM) の西口です。このブログ記事では、CSM としてお客様のクラウド活用やクラウド移行の加速をご支援している経験を踏まえ、クラウドの体験型ワークショップ (Experience-Based Acceleration(EBA)) の Party の一つである EBA FinOps Party をご紹介します。 FinOps という用語を皆さまご存じでしょうか。もしかするとあまり馴染みのない用語かもしれません。同じような用語でより耳にすることの多い DevOps が Development (開発) と Operations (運用) が密に連携して、高い品質を確保しつつ開発速度の向上と運用の効率化を目的とした取り組みを指しますが、それと同じように、FinOps は Financial (財務) と DevOps (開発および運用) が密に連携して、クラウドの費用予測や計画をより精微化しコストを最適化することで、財務の面でもクラウドリソースの効率的な利用を進めることを意味しています。 お客様はこの FinOps の一部の取り組みを EBA による実践的なアプローチで体験することが可能です。 EBA ではクラウド利用や移行におけるお客様課題に対して 5 つの Party と呼ばれるワークショップを提供しています。EBA FinOps Party はそのうちの一つです。この EBA FinOps Party を通じて、お客様ご自身で自らの部門やシステムを対象に FinOps を実践します。 EBA の詳細は こちら の記事をご確認ください。 EBA FinOps Party は、移行を行った後などでクラウドの支出が増えており組織として最適化したい、オンプレミスとクラウドの財務の考え方の違いが整理できておらず適切にクラウドを活用できているか自信がない、クラウドの費用計画では財務部門と IT 部門の連携が必要であることは理解しているが連携の一歩が踏み出せない、といったお客様に特におすすめします。 EBA FinOps Partyを実践する効果 EBA FinOps Party を実践する効果として、お客様内のコスト管理を担当する組織 (財務部門、業務部門、IT 部門) が「コストを最適化し続ける」意識を持つための契機を作ることができます。 昨今、IT システムのクラウド化をお客様クラウド推進組織 (Cloud Center of Excellence) が推進していただいている成果として、大変多くのお客様に AWS をご利用いただいています。しかし、それと並行して、景気の低迷や急激な円安によりクラウドの利用料が想定していたよりも高騰し、ビジネス課題として「コスト『削減』」が挙げられることも多くなってきました。これらに対し、AWS では単純な「削減」作業を実施するのではなく、定常的に無駄なコストを減らし適切なコスト状態とするための「最適化」活動として FinOps の実施および活動の定着を推奨をしています。この活動を実践するためのフレームワークが Cloud Financial Management  (CFM) です。 EBA FinOps Party は、このフレームワークと最適化手法をお客様が理解し、定常的な活動計画の立案までを体験するプログラムです。 EBA FinOps Partyでのアジェンダ例 今回のブログでは、日本のお客様向けアジェンダ例をご紹介します。日本では、お客様環境を変更するためのプロセスとして変更作業前に財務部門やアプリケーションチームとの協議、承諾といったプロセスが存在していたり、事前に手順検証を実施しリスクを軽減しておくといったプロセスが存在していることが多く、ワークショップ中に環境を変更するにはとてもハードルが高いと推測します。 そのため、日本のお客様向け EBA FinOps Party ではまず FinOps を始める契機を作ることを目的とし、以下 3 つに焦点を当てています。 CFM フレームワークを理解、認識する コスト最適化が可能な箇所の確認および最適化の手法を理解する エグゼクティブスポンサーからコスト最適化活動に対する支援を獲得する 標準的なアジェンダ例として、Day1 : 基礎編、Day2 : 実践編、Day3 : 報告会の 3 日間です。特に Day2 ではハンズオンやデモを取り入れ、活動施策を Day3 に向けた宿題として検討します。そして Day3 で施策を発表することで定量的な最適化成果を明示的に意識する内容となっています。これにより参加者に「コスト最適化活動し続ける」意識を高める体験を得ることができます。 Day1 (基礎編) ： CFM フレームワーク (座学) AWS の提唱する CFM フレームワークに関して、コストを最適化し続ける重要性と4つの柱「可視化」、「最適化」、「計画・予測」、「 FinOps の実践」を実現するための取組をセミナー形式で実施します。 Day2 (実践編) ：コスト最適化⼿法についての AWS サービスのハンズオンやデモ Day2 では、お客様課題に合ったコスト最適化手法について AWS サービスのハンズオンやデモをご提供します。 ※一例　 AWS Cost Explorer を用いたお客様のご利用状況確認手順ハンズオン、 AWS Budgets や AWS Instance Scheduler 、 Amazon QuickSight のデモまた、このハンズオンやデモの内容を踏まえ、参加メンバーには Day3 へ向けてご自身が関係するシステムやプロジェクトにおける最適化活動施策をご検討いただくことを宿題としてお渡しします。 Day3 (報告会) ：施策報告 Day2 で宿題として検討した最適化活動施策を、エグゼクティブに向けに発表します。エグゼクティブ向けに発表を行うことで、エクゼクティブには今後この施策を後押ししていただけるスポンサーになっていただくことを目的としています。 FinOps ベストプラクティス CFM フレームワークにもあるとおり、 4 つの柱のうち「可視化」、「最適化」、「計画・予測」の 3 つアクションを定常的に「 FinOps の実践」として実施することが非常に重要です。  可視化 AWS コスト配分タグ や AWS Cost Categories を用いたタグ付け戦略の策定、 AWS Cost Explorer や Amazon QuickSight を利用しお客様のクラウド利用料をグラフ化することで、「最適化」を行う対象リソースの可視化を行います。 最適化 「可視化」により確認した対象に対し、AWS の提唱する最適化手法である「クイックウィン最適化」あるいは「アーキテクチャ最適化」を計画、実施します。 クイックウィン最適化 適切なインスタンスサイズの選定、未使用リソースの停止等ご利用環境にて、オペレーションすることで最適化を実践できる手法です。 アーキテクチャ最適化 IaC による運用の自動化やサーバレス、マネージメントサービスの利用といったクラウドネイティブ化することで最適化を実践できる手法です。 計画・予測 新しいシステムの導入やサービスへの機能追加などによりクラウド環境が拡大する等、ビジネス状況を鑑みたクラウド利用料の計画、予測を行い、 AWS Budgets や Amazon Forecast 、 AWS Cost Anomaly Detection を利用しモニタリングします。 AWS Budgets 設定した予算に対し、閾値を設定することでその閾値を超過した場合、E メールまたは SNS 通知によるアラート通知が可能です。 Amazon Forecast AWS Cost Explorer では過去 12 か月分のデータを基にした予測となりますが、Amazon Forecast は AWS Cost and Usage Reports の請求情報データから機械学習を用いて、クラウド利用料の予測を行います。 AWS Cost Anomaly Detection AWS サービスの利用状況を機械学習モデルにより学習し、ベースラインを設け、このベースラインから大きく逸脱した値を「異常」として検知し、E メールまたは SNS 通知によるアラート通知が可能です。 コスト最適化を実践しているお客様事例 FinOps として CFM フレームワークの可視化、最適化、計画・予測を実践することで、コストの最適化がより身近になり、定常的なコスト最適化活動に一歩近づくでしょう。ここではコスト最適化活動を実践しているお客様の例を紹介します。 ナビタイムジャパン様 では、CFM による包括的なコスト最適化の診断の結果、ストレージコストを約 10% 削減しました。また EC2 のダウンサイジングなど 段階的なアプローチを行い、インフラコストはオンプレミス比で 30% の削減を達成できています。加えて、次世代プロセッサーを具備した最新世代のインスタンスへ変更したことにより、さらなるコスト削減とパフォーマンス向上を見込んでいます。 また、 NTT ドコモ様 では、IT 部門と利用部門に対して意識改革を促すため、CFM ワークショップを実施し、コストの最適化を進めた結果、過去の最大利用料より 30% のコストを削減しました。他のお客様においても、EBA FinOps Party を実施した結果、金融業界のお客様で約 120,000 USD、通信業界のお客様で約 500,000 USD、製造業のお客様で約 190,000 USD のコスト最適化を見込んでいます。 EBA FinOps Partyの始め方 EBA FinOps Party は、AWS のクラウド移行トータル支援プログラムである「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー 」の準備・移行フェーズにおける継続的なコスト最適化支援の無償プログラムの一つです。 EBA FinOps Party または AWS IT トランスフォーメーションパッケージにご興味ある方のご利用に向けた入り口は 2 つあり、 1) Web フォーム からお問い合わせ、 2) 担当営業までご連絡、どちらからでも可能です。 AWS へのコンタクトをお待ちしております。 参考情報 AWS によるクラウド財務管理 コスト最適化のためのアーキテクチャベストプラクティス コスト最適化の柱 – AWS Well-Architected フレームワーク AWS コスト最適化フレームワーク– AWS へ移行前後のコスト最適化を通してイノベーションを加速させる クラウド財務管理はコスト削減以上のメリットをもたらす アプリケーションのモダナイゼーションを加速する EBA Level up your Cloud Transformation with Experience-Based Acceleration (EBA) AWS ITトランスフォーメーションパッケージ 2023 ファミリー(ITX 2023) Vega Cloud brings FinOps solutions to their customers faster by embedding Amazon QuickSight AWS 導入事例：株式会社ナビタイムジャパン | AWS AWS 導入事例: NTTドコモ | AWS

AWS Glue Studio は AWS Glue DataBrew と統合されました。 AWS Glue Studio は、 AWS Glue で抽出、変換、ロード (ETL) ジョブを簡単に作成、実行、監視できるようにするグラフィカルインターフェイスです。 DataBrew は、コードを書かずにデータをクレンジングおよび正規化できる可視的なデータプレパレーションツールです。DataBrewで提供されている 200 を超える変換ステップを、AWS Glue Studio ビジュアルジョブで使用できるようになりました。 DataBrew において、レシピは、直感的なビジュアルインターフェイスで対話的に作成できる一連のデータ変換ステップです。このブログでは、DataBrew でレシピを作成し、それを AWS Glue Studio ビジュアル ETL ジョブの一部として適用する方法を説明します。 既存の DataBrew ユーザーもこの統合の恩恵を受けることができます。高度なジョブ設定と最新の AWS Glue エンジンバージョンを使用できることに加えて、AWS Glue Studio が提供している他のすべてのコンポーネントを使用して、より大規模なビジュアルワークフローの一部としてレシピを実行できるようになります。 この統合により、両方のツールの既存ユーザーに明確なメリットがもたらされます。 AWS Glue Studio では、全体的な ETL ダイアグラムをエンドツーエンドで一元的に表示できます。 DataBrew コンソール上で、値・統計・分布を確認しながらレシピをインタラクティブに定義し、テストおよびバージョン管理された処理ロジックを AWS Glue Studio ビジュアル ジョブで再利用できます。 AWS Glue ETL ジョブで複数の DataBrew レシピを統合でき、AWS Glue ワークフローを使用して複数のジョブを統合できます。 DataBrew レシピでは、増分データ処理のためのブックマーク、自動再試行、自動スケール、小さなファイルのグループ化などの AWS Glue ジョブ機能を使用して効率化を図ることができるようになります。 ソリューション概要 今回のユースケース例では、このブログ用に作成された医療請求データセットをクレンジングすることが要件となります。サンプルデータには、データプレパレーションにおける DataBrew の機能を実践するために意図的にいくつかのデータ品質の問題を組み込んでいます。次に、別のデータソースから取得した医療事業者に関する関連情報を追加して、請求データをデータカタログに取り込みます。 (そうすることでアナリストが可視化できるようになります)。 このソリューションは、請求データと医療事業者データの 2 つの CSV ファイルを読み取る AWS Glue Studio ビジュアルジョブで構成されます。このジョブは、データの品質問題に対処するために、請求データにレシピを適用させて、医療事業者データから必要な列を選択した上で、両方のデータセットを結合して、最後に結果を Amazon Simple Storage Service (Amazon S3) に保存して、データカタログ上にテーブルを作成します。出力データは、 Amazon Athena などの他のツールで使用できます。 DataBrew レシピの作成 まず、サンプルデータとして、請求データをデータストアに登録します。そうすることで、実際のデータを使用してインタラクティブエディターでレシピを作成できるようになり、変換を定義する際にその結果をレビューできるようになります。 次のリンクから請求データの CSV ファイルをダウンロードします: alabama_claims_data_Jun2023.csv 。 DataBrew コンソールのナビゲーション ペインで [データセット] を選択し、[新しいデータセットの接続] を選択します。 [ファイルをアップロード] オプションを選択します。 [データセット名] に Alabama Claims と入力します。 [アップロードするファイルを選択します] で、ローカル PC にダウンロードしたファイルを選択します。 [S3 送信先を入力] で、使用しているAWSアカウントとリージョンにあるバケット名を入力または参照します。 残りのオプションはデフォルトのままにし (CSV はカンマとヘッダーで区切られます)、データセットの作成を完了します。 ナビゲーションペインで [プロジェクト] を選択し、[プロジェクトの作成] を選択します。 プロジェクト名として、 ClaimsCleanup と入力します。 [レシピの詳細] の [アタッチされたレシピ] で、[新しいレシピを作成] を選択し、名前を ClaimsCleanup-recipe とし、 Alabama Claims データセットを選択します。 DataBrew に 適切な既存の IAM ロール を選択するか、新しい IAM ロールを作成します。これで、プロジェクトの作成は完了です。 以上で、構成可能なデータのサブセットを使用してセッションが作成されます。セッションの初期化が完了すると、一部のセルに無効な値または欠落した値が含まれていることがわかります。 Diagnosis Code 、 Claim Amount 、および Claim Date の列の値が欠落しており、データの一部の値には余分な文字が含まれています。 Diagnosis Code の値には「code 」(スペースが含まれる) という接頭辞が付く場合があり、 Procedure Code の値には、末尾に一重引用符が付いています。 Claim Amount の値は一部の計算に使用される可能性があるため、数値型に変換し、 Claim Date は Data 型に変換する必要があります。 対処すべきデータ品質の問題を特定したので、各問題をどのように対処するかを決定する必要があります。 レシピステップを追加するには、列のコンテキストメニュー、上部のツールバー、またはレシピの概要からなど、複数の方法があります。最後の方法を使用すると、指定されたステップタイプを検索して、このブログで作成したレシピを複製できます。 今回のユースケースでは Claim Amount は不可欠な値であるため、欠損のある行を削除することにします。 [欠損した値を削除] のステップを追加します。 ソース列で、[Claim Amount] を選択します。 デフォルトのアクション [欠落した値がある行を削除する]のままにし、[適用] を選択して保存します。 ステップの適用を反映してビューが更新され、 Claim Amount が欠損している行はなくなりました。 Diagnosis Code は空でもよいですが、 Claim Date には合理的に推測された値が必要です。データ内の行は時系列で並べ替えられるため、プレビューの前の行の有効な値を使用して、欠落している日付を代入できます。毎日請求が発生していると仮定すると、最大の問題は、その日の最初の請求データの日付が欠落している場合に、プレビューの日付が割り当てられてしまうことです。今回は説明のために、潜在的なエラーは許容できると考えてみましょう。 まず、列を string 型から date 型に変換します。 [型の変更] のステップを追加します。 ソース列として [Claim Date] を選択し、型として[date] を選択し、[適用] を選択します。 次に、欠落した日付を代入するために、[欠落した値を埋める/帰属] ステップを追加します。 ソース列に [Claim Date]、アクションとして [最後の有効な値で埋める] を選択します。 [変更のプレビュー] を選択して検証し、[適用] を選択してステップを保存します。 下記の画像のように、ここまででレシピには 3 つのステップが存在しているはずです。 次に、[引用符の削除] ステップを追加します。 ソース列に [Procedure Code]、削除する値に [先頭と末尾の引用符] を選択します。 プレビューにてステップが反映されていることを確認し、新しいステップとして適用します。 [特殊文字を削除] のステップを追加します。 ソース列に [Claim Amount] 選択し、[カスタム特殊文字] の [カスタム特殊文字を入力] に $ を入力します。 [型を変更] ステップを追加し、ソース列 [Claim Amount] 、タイプを [double] とします。 最後のステップとして、余分な “code ” プレフィックスを削除するために、[値またはパターンの置き換え] ステップを追加します。 ソース列で [Diagnosis Code] を選択し、[カスタム値を入力] に code と入力します (末尾にスペースを入れます)。 サンプルで特定したすべてのデータ品質の問題に対処したので、プロジェクトをレシピとして公開します。 レシピペインで [発行] を選択し、オプションでバージョンの説明を入力してレシピの発行を完了します。 発行するたびに、異なるバージョンのレシピが作成され、使用するレシピのバージョンを選択できるようになります。 AWS Glue Studio でビジュアル ETL ジョブを作成 次に、レシピを使用するジョブを作成します。次の手順を実行します。 AWS Glue Studio コンソールのナビゲーションペインで [Visual ETL] を選択します。 [Visual with a blank canvas] を選択し、ビジュアル ジョブを作成します。 ジョブの上部の “Untitled job” を任意の名前に置き換えます。 [Job Details] タブで、ジョブが使用するロールを指定します。 これは、Amazon S3 および AWS Glue データカタログへのアクセス許可を持つ、 AWS Glue に適した AWS Identity and Access Management (IAM) ロールである必要があります。先ほど DataBrew で使用したロールはジョブの実行には使用できないため、ここでは [IAM ロール] ドロップダウン メニューにはリストされないことに注意してください。 DataBrew ジョブとは違い、AWS Glue Studio では、ワーカー サイズ、自動スケーリング、 柔軟な実行 などのパフォーマンスとコストの設定を選択できるほか、最新の AWS Glue 4.0 ランタイムを使用することで大幅なパフォーマンスの改善を受けることができることに注目してください。このジョブでは、デフォルトの設定を使用できますが、節約のためにワーカーの数を減らします。この例では、2 Wokers で十分です。 [Visual] タブで、S3 ソースを追加し、 Providers という名前を付けます。 S3 URL には、 s3://awsglue-datasets/examples/medicare/Medicare_Hospital_Provider.csv と入力します。 データフォーマットとして [CSV] を選択し、[Infer schema] を選択します。 これで、ファイルヘッダーを使用してスキーマが [Output schema] タブにリストされます。 このユースケースでは、providers データセット内のすべての列を必要としないため、残りは削除できます。 Providers ノードを選択した状態で、Transforms で [Drop Fields] を追加します (Node parents を選択しなかった場合は、Node parents を手動で割り当てます)。 Provider Zip Code 以降のフィールドをすべて選択します。 その後、この Providers データを、Alabama 州の 請求データと結合します。ただし、2 番目のデータセットには州の情報がありません。Providers データから、必要なデータをフィルタリングすることで結合を最適化できます。 [Drop Fields] の子としてTransforms から[Filter] 追加します。 Alabama providers と名前を付け、Provider State が AL と一致するという条件を追加します。 2番目のソース (新しい S3 ソース) を追加し、 Alabama claims という名前を付けます。 S3 URL を入力するには、別のブラウザ タブで DataBrew を開き、ナビゲーションペインで [データセット] を選択し、表に表示されている Alabama claims の場所をコピーします (http リンクではなく、s3:// で始まるテキストをコピーします)。次に、ビジュアルジョブに戻り、S3 URL 欄に貼り付けます。正しい場合は、[Output schema] タブにデータフィールドがリストされていることがわかります。 CSV 形式を選択し、他のソースの場合と同様に [infer schema] します。 このソースの子として、ノードの追加メニューで recipe と検索し、[Data Preparation Recipe] を選択します。 新しいノードのプロパティで、 Claim cleanup Recipe という名前を付け、先ほど発行したレシピとバージョンを選択します。 ここでレシピの手順を確認し、必要に応じて DataBrew へのリンクを使用して変更を加えることができます。 結合ノードを追加し、 Alabama providers と Claim cleanup recipes の両方を親として選択します。 両方のソースの provider ID を結合条件として追加します。 最後のステップとして、S3 ノードをターゲットとして追加します (検索時に表示される最初のノードはソースであることに注意してください。ターゲットとして表示されるものを必ず選択してください)。 ノード設定では、デフォルト形式の JSON のままにし、ジョブの IAM ロールが書き込み権限を持つ S3 URL を入力します。 さらに、データ出力をカタログ内のテーブルとして利用できるようにします。 [データ カタログの更新オプション] セクションで、上から 2 番目のオプション [データ カタログにテーブルを作成し、その後の実行でスキーマを更新し、新しいパーティションを追加する] を選択し、テーブルを作成する権限があるデータベースを選択します。 名前を alabama_claims とし、partition key として Claim Date を選択します (これは説明のためであり、今回のような小さなテーブルでは、後でデータを追加しない場合、実際にはパーティションを必要としません)。 ジョブを保存してジョブを実行します。 [Run] タブでは、ジョブ ID リンクを使用してプロセスを追跡し、詳細なジョブメトリクスを確認できます。 ジョブが完了するまでに数分かかります。 ジョブが完了したら、Athena コンソールに移動します。 選択したデータベースでテーブル alabama_claims を検索し、コンテキスト メニューを使用して [テーブルのプレビュー] を選択します。これにより、テーブルに対して単純な SELECT * SQL ステートメントが実行されます。 ジョブの結果から、データが DataBrew レシピによってクレンジングされ、AWS Glue Studio の結合処理によって強化されたことがわかります。 Apache Spark は、AWS Glue Studio で作成されたジョブを実行するエンジンです。生成されるイベント ログ上で Spark UI を使用すると、ジョブの計画と実行に関するインサイトを表示でき、ジョブのパフォーマンスと潜在的なパフォーマンスのボトルネックを理解するのに役立ちます。たとえば、大規模なデータセットに対するこのジョブの場合、これを使用して、結合処理を実行する前にプロバイダーの状態を明示的にフィルタリングすることの影響を比較したり、自動バランス変換を追加して並列処理を改善することでメリットが得られるかどうかを確認できます。 デフォルトでは、ジョブは Apache Spark イベント ログを s3://aws-glue-assets-<アカウント ID>-<リージョン名>/sparkHistoryLogs/ のパスに保存します。ジョブを表示するには、 いずれかの方法 を使用して History server をインストールする必要があります。 後片付け このソリューションが不要になった際は、Amazon S3 に格納された生成ファイル、ジョブによって作成されたテーブル、DataBrew レシピ、および AWS Glue ジョブを削除してください。 まとめ このブログでは、AWS DataBrew のインタラクティブエディターを使用してレシピを作成し、発行されたレシピを AWS Glue Studio ビジュアル ETL ジョブの一部として使用する方法を説明しました。データプレパテレーションを実施して、AWS Glue Catalog のテーブルにデータを取り込む際に必要な一般的なタスクの例をいくつか含めました。 この例ではビジュアルジョブで 1 つのレシピを使用しましたが、ETL プロセス内で複数のレシピを使用したり、複数のジョブで同じレシピを再利用することも可能です。 これらの AWS Glue ソリューションを使用すると、コードを記述することなく、構築と運用が簡単な高度な ETL パイプラインを効果的に作成できます。両方のツールを組み合わせたソリューションをすぐに開始できます。 この記事は、Sr. Software Dev Engineer の Mikhail Smirnov とSr. Big Data Architect の Gonzalo Herreros が執筆しています。日本語訳はソリューションアーキテクトの三宅が翻訳しました。原文は こちら です。 執筆者について Mikhail Smirnov is a Sr. Software Dev Engineer on the AWS Glue team and part of the AWS Glue DataBrew development team. Outside of work, his interests include learning to play guitar and traveling with his family.   Gonzalo Herreros  is a Sr. Big Data Architect on the AWS Glue team. Based on Dublin, Ireland, he helps customers succeed with big data solutions based on AWS Glue. On his spare time, he enjoys board games and cycling.

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週、東京リージョンで利用開始になったことが話題になった Amazon Bedrock をはじめとして、AWSでは多様な生成系AI（Generative AI）サービスが用意されていますが、その生成系AIに関するイベントが今週17日（火）から3日間の日程で開催されます。生成系AIやLLMの基本が学べる初日、ユーザー事例多数の2日目、BedrockをはじめとするAWSサービスの高度な使い方を解説する3日目と充実した内容になっています。オンライン開催でどこからでも参加できますので、ご興味がある方はぜひ以下より登録してご参加ください。 – 生成系 AI を中心とした AI 最前線がここに AWS AI Week For Developers それでは、先週の主なアップデートについて振り返っていきましょう。 2023年10月9日週の主要なアップデート 10/9(月) AWS Glue now supports GitLab, BitBucket in its Git integration feature AWS Glue はETL処理のためのソースコードをGitサービスで管理することが可能です。これまではAWS CodeCommitおよびGitHubに対応していましたが、今回の発表でGitLabとBitBucketに対応し、より多様なコード管理環境に対応可能になりました。 AWS Verified Access is now available in two additional AWS regions AWS Verified Access が利用可能なリージョンとして、東京リージョンおよびシンガポールリージョンが追加されました。Verified Access はゼロトラストの基本原則に基づいて社内リソースにアクセス可能にするための環境を提供するサービスです。 10/10(火) Amazon Linux announces support for Ansible and Corretto 21 with AL2023.2 Amazon Linux 2023 の四半期アップデートの2回目、AL2023.2がリリースされました。これには無料のOpenJDKディストリビューションである Amazon Corretto 21 とAnsibleが含まれています。Amazon Linux 2023のリリースの考え方は こちらのブログ をご覧ください。 Announcing pgactive: Active-active Replication Extension for PostgreSQL on Amazon RDS pgactive が Amazon RDS for PostgreSQL で利用可能になりました。PostgreSQL 15.4-R2以降で利用可能です。pgactiveは複数のPostgreSQLデータベース間でactive-activeのレプリケーションを実現するextensionです。詳細は こちらのブログ をご覧ください。 10/11(水) Amazon FSx for NetApp ONTAP is now available in the AWS Asia Pacific (Osaka) Region Amazon FSx for NetApp ONTAP が大阪リージョンで利用可能になりました。Amazon FSx for NetApp ONTAP はフルマネージドの共有ストレージであり、 ONTAP のデータアクセスおよび管理機能が利用可能なサービスです。東京リージョンのFSx for Netapp ONTAPと SnapMirror によるレプリケーションを利用することも可能です。 New Amazon CloudWatch metric monitors EC2 instance reachability to EBS volumes Amazon CloudWatch にAttached EBS Status Check (StatusCheckFailed_AttachedEBSメトリクス)が追加されました。EBSボリュームとEC2間で通信が可能か、IO操作が可能かをチェックするメトリクスで、これを監視することでEBSボリュームで異常が発生した際に素早く問題に気づくことができます。 10/12(木) Amazon SageMaker Canvas expands content summarization and information extraction capabilities コードの記述なしで、機械学習モデルの学習や利用ができる Amazon SageMaker Canvas では、すぐに利用できる(ready-to-use)モデルとして、生成系AIのFM（Anthropic Claude 2 や Amazon Titan など）を利用した、コンテンツの要約と情報抽出(content summarization and information extraction)が用意されています。今回追加機能として、ユーザーが提供するドキュメント（インデックス）を指定可能になりました。現時点ではAmazon Kendraがドキュメントソースとして利用可能です。これによりKendraに格納した情報を知識源としたチャットベースの分析環境をコーディング不要で実現可能です。 AWS Step Functions launches Optimized Integration for Amazon EMR Serverless AWS Step Functions が Amazon EMR Serverless をネイティブにサポートし、EMR Serverless の API Actionとして CreateApplication, StartApplication, StopApplication, DeleteApplication, StartJobRun, CancelJobRun が呼び出せるようになりました。 Announcing new AWS Network Load Balancer (NLB) availability and performance capabilities AWS Network Load Balancer (NLB)で新たに3つの機能が追加されました。1つ目は Availability Zone DNS affinity で、DNSで同一AZ内でのターゲットを返す機能、2つ目は disable connection termination for unhealthy targets　でヘルスチェックに失敗した接続の切断をしないようにする機能、3つ目は UDP connection termination by default で、UDP接続にデフォルトでタイムアウトが設定されるようになったというものです。 Announcing AWS Lambda’s support for Internet Protocol Version 6 (IPv6) for outbound connections in VPC AWS Lambda で dual-stack構成のVPC内のリソースにIPv6でアクセスすることが可能になりました。これにより、VPC内のIPv4アドレスの残量を気にすることなくLambda関数を並列実行できるようになり、より大規模な利用がしやすくなりました。 10/13(金) Amazon EC2 C7gd, M7gd, and R7gd instances now available in additional regions Amazon EC2 の C7gd, M7gd, R7gd インスタンスが新たに東京リージョンとシンガポールリージョンで利用可能になりました。AWS Graviton3プロセッサに加え、ローカルストレージを搭載したインスタンスです。また、合わせて C7gd がシドニーリージョンで利用可能になったことがアナウンスされています。 Deploy ML models built in SageMaker Canvas to SageMaker real-time endpoints Amazon SageMaker Canvas では作成したMLモデルにデータを与えることでバルクで予想を出力させることが可能ですが、今回、これに加えてリアルタイム予測エンドポイントをデプロイすることが可能になりました。アプリケーションからAPIで呼び出すことで、リアルタイムに予測値を得ることが可能です。 Amazon EC2 now supports setting AMIs to a disabled state EC2のAmazon Machine Images (AMIs) でAMIをdisable（無効）に設定可能になりました。以前にパブリックに公開したAMIであっても、disableするとそこからEC2を起動することはできなくなります。 余談ですが、最後に紹介したAMIのアップデートの文中で、”Amazon Machine Images (AMIs; pronounced ah-mee)”という珍しい注記が含まれていました。AMI＝アーミィと発音しますということなのですが、良く質問があったのでしょうか？ちなみに筆者（下佐粉）は、エーエムアイ派です：） それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

北半球は美しい初秋の季節です。米国では地元のファーマーズマーケットやコーヒーショップがパンプキンに占領されています。re: Invent 2023まで後 50 日です。 Pre:Invent の公式シーズンの前に、10月2日週のエキサイティングなニュースや発表をいくつか見てみましょう。 10月2日週のリリース 私が注目したリリースを以下に記載しました。 AWS Control Tower – AWS Control Tower は、お客様の規制要件を満たし、転送中のデータの暗号化、保管中のデータの暗号化、強力な認証の使用などの統制目標を満たすために役立つ 22 のプロアクティブコントロールと 10 の AWS Security Hub 発見的コントロールをリリースしました。コントロールの詳細とリストについては、 AWS Control Tower ユーザーガイド を参照してください。 Amazon Bedrock – 米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンで Amazon Bedrock の提供 が開始されてからわずか 1 週間後、Amazon Bedrock は アジアパシフィック (東京) の AWS リージョンで利用可能 になりました。基盤モデルで生成系 AI アプリケーションの構築とスケーリングを開始するには、 Amazon Bedrock ドキュメント を参照して、 community.aws の生成系 AI スペース を探索し、 Amazon Bedrock ワークショップ の演習を利用してください。 Amazon OpenSearch Service – 検索、オブザーバビリティ、セキュリティ分析、機械学習 (ML) 機能が強化された OpenSearch バージョン 2.9 を Amazon OpenSearch Service で実行できるようになりました。OpenSearch Service は、バージョン 2.9 で 地理空間集約サポートを拡張 し、傾向とパターンの高レベルの概要のインサイトを収集してデータ内の相関関係を確立できるようになりました。OpenSearch Service 2.9 には、OpenTelemetry などの新しいスキーマ標準を活用するための OpenSearch Service Integrations も付属 するようになりました。また、ダッシュボードでの アラートと異常の管理、および視覚化折れ線グラフへのオーバーレイ が可能になりました。 Amazon SageMaker – SageMaker 特徴量ストアが、完全マネージド型のインメモリオンラインストアをサポート するようになり、高スループットの ML アプリケーション用のモデル提供に必要な特徴量をリアルタイムで取得できます。新しいオンラインストアは、オープンソースの Redis 上に構築されたインメモリデータストアである ElastiCache for Redis を利用しています。詳細については、 SageMaker デベロッパーガイド を参照してください。 また、 SageMaker Model Registry はプライベートモデルリポジトリのサポートを追加 しました。プライベート Docker リポジトリに保存されているモデルを登録し、複数のプライベート AWS モデル リポジトリと AWS 以外のモデルリポジトリにわたるすべてのモデルを 1 つの中央のサービスで追跡できるようになったので、スケールでの ML 運用 (MLOps) と ML ガバナンスを簡素化できます。使用を開始する方法については、 SageMaker デベロッパーガイド を参照してください。 Amazon SageMaker Canvas – SageMaker Canvas のサポートが拡張され、すぐに使えるモデルに基盤モデル (FM) が含まれるようになりました 。ノーコードのチャットインターフェースから、Claude 2、Amazon Titan、Jurassic-2 (Amazon Bedrock 搭載) などの FM だけでなく、Falcon や MPT (SageMaker JumpStart 搭載) などの公開されているモデルにもアクセスできるようになりました。詳細については、 SageMaker デベロッパーガイド を参照してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS のニュース 興味深いと思われるその他のブログ投稿とニュース項目をいくつかご紹介いたします。 オープンソースデータベースへの AWS の貢献の舞台裏 – この投稿では、過去 2 年間に AWS がアップストリームのデータベースに対して行ってきた重要なオープンソースの貢献をいくつか紹介するとともに主要な貢献者を紹介し、AWS がデータベースサービスのアップストリーム作業にどのように取り組んでいるかを紹介します。 AWS Trainium による迅速で費用対効果の高い Llama 2 の微調整 – この記事では、LLM トレーニング専用のアクセラレータである AWS Trainium で Meta の Llama 2 モデルを微調整してトレーニング時間とコストを削減する方法を紹介します。 Meta の Code Llama コード生成モデルが Amazon SageMaker JumpStart で利用可能に – Meta が開発した Code Llama FM を ワンクリックで SageMaker JumpStart にデプロイできるようになりました。この投稿では、詳細が手順ごとに説明されています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 Build On Generative AI – 生成系 AI のすべてを網羅した 週刊 Twitch ショー のシーズン 2 が盛り上がりを見せています。 毎週月曜日 9:00 (米国太平洋標準時) に同僚の Emily と Darko が AWS の新しい技術的および科学的パターンについて考察し、ゲストスピーカーを招いてその作業のデモを行い、生成系 AI の状態を改善するために構築されたものを紹介します。 今日のエピソード では、Emily と Darko が非構造化ドキュメントを構造化データに変換する方法について解説しました。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 AWS Community Days – お住まいの地域の AWS ユーザーグループリーダーたちが主催するコミュニティ主導のカンファレンスにご参加ください: DMV (DC、メリーランド、バージニア) (10 月 13 日)、 イタリア (10 月 18 日)、 UAE  (10 月 21 日)、 ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、 ブラジル (11 月 4 日)。 AWS Innovate: Every Application Edition  – 無料のオンラインカンファレンスに参加して、セキュリティと信頼性の強化、予算内でのパフォーマンスの最適化、アプリケーション開発のスピードアップ、生成系 AI でのアプリケーションの革新を実現する最先端の方法を探索してください。10 月 19 日の AWS Innovate Online アメリカ地区 と EMEA 、および 10 月 26 日の AWS Innovate Online アジアパシフィックと日本 に登録してください。 AWS re:Invent (11 月 27 日～12 月 1 日) – ぜひご参加ください 。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 セッションカタログ と 参加者ガイド を参照して、 生成系 AI の re:Invent のハイライト をチェックしてください。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 10月9日週はここまでです。10月16日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

コンピューティング最適化 Amazon EC2 C6a インスタンス は 2022 年 2 月にリリースされました。これは、第 3 世代 AMD EPYC (Milan) プロセッサを搭載しており、最大 3.6 GHz の周波数で動作します。 10月4日、最大周波数 3.7 GHz の第 4 世代 AMD EPYC (Genoa) プロセッサを搭載した新しいコンピューティング最適化 Amazon EC2 C7a インスタンスの一般提供の開始をお知らせします。このインスタンスでは、C6a インスタンスと比べてパフォーマンスが最大 50% 向上しています。このパフォーマンスの向上により、データ処理の高速化、ワークロードの統合、保有コストの削減を実現できます。 C7a インスタンスは、C6a インスタンスと比較して最大 50% 高いパフォーマンスを実現します。これらのインスタンスは、高性能ウェブサーバー、 バッチ処理 、 広告配信 、 機械学習 、 マルチプレイヤーゲーム 、 動画エンコーディング 、科学モデリングなどの ハイパフォーマンスコンピューティング (HPC) 、 機械学習 などのコンピューティングを多用するワークロードの実行に最適です。 C7a インスタンスは、 AVX-512、Vector Neural Network Instructions (VNNI) 、および bfloat16 (brain floating point) をサポートします。これらのインスタンスは、メモリ内のデータへの高速アクセスを可能にする Double Data Rate 5 (DDR5) メモリを備えており、前世代のインスタンスと比較して 2.25 倍のメモリ帯域幅を提供してレイテンシーを低減します。 C7a インスタンスは、最大 192 個の vCPU と 384 GiB の RAM を備えています。これにより、新しい中サイズのインスタンスが利用して、ワークロードのサイズをより正確に調整できるようになりました (1 個の vCPU、2 GiB を提供します)。詳細な仕様は次のとおりです。 名前 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c7a.medium 1 2 最大 12.5 最大 10 c7a.large 2 4 最大 12.5 最大 10 c7a.xlarge 4 8 最大 12.5 最大 10 c7a.2xlarge 8 16 最大 12.5 最大 10 c7a.4xlarge 16 32 最大 12.5 最大 10 c7a.8xlarge 32 64 12.5 10 c7a.12xlarge 48 96 18.75 15 c7a.16xlarge 64 128 25 20 c7a.24xlarge 96 192 37.5 30 c7a.32xlarge 128 256 50 40 c7a.48xlarge 192 384 50 40 c7a.metal-48xl 192 384 50 40 C7a インスタンスは最大 50 Gbps の拡張ネットワーキングと 40 Gbps の EBS 帯域幅を備えており、最大 128 個の EBS ボリュームをインスタンスにアタッチできます (前世代のインスタンスの EBS ボリュームアタッチメントは最大 28 個)。 C7a インスタンスは、AMD セキュアメモリ暗号化 (SME) を使用した常時オンのメモリ暗号化と、暗号化および復号アルゴリズム、畳み込みニューラルネットワーク (CNN) ベースのアルゴリズム、財務分析、および動画エンコーディングワークロードを高速化するための新しい AVX-512 命令 をサポートします。また、C7a インスタンスは、セキュリティを強化するために AES-256 をサポートします (C6a インスタンスでは AES-128)。 これらのインスタンスは AWS Nitro System 上に構築されており、ハイパフォーマンスコンピューティングや動画処理など、ネットワークレイテンシーの低減や、高度にスケーラブルなノード間通信の恩恵を受けるワークロード向けに Elastic Fabric Adaptor (EFA) をサポートしています。 今すぐご利用いただけます Amazon EC2 C7a インスタンスは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の AWS リージョンで利用できるようになりました。Amazon EC2 でのお支払いと同じように、使用した分の料金のみをお支払いいただきます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 EC2 C7a インスタンスページ と AWS/AMD パートナーページ を参照してください。 ec2-amd-customer-feedback@amazon.com 、 AWS re:Post for EC2 、または通常の AWS サポートの担当者を通じて、ぜひフィードバックをお寄せください。 — Channy 原文は こちら です。

2023 年 10 月 5 日木曜日に開催される参加無料のオンラインイベントである Data and Generative AI Day にぜひご参加ください。AWS は、 LinkedIn Live や YouTube などの複数のプラットフォームでイベントを同時にストリーミングします。 生成系 AI の領域では、組織のデータに秘められた力と可能性がこれまで以上に大きくなっています。生成系 AI には、顧客とのやり取りを再構築し、従業員の生産性を向上させ、創造的なアイデア出しを刺激し、画期的なイノベーションを推進する力があります。しかし、先進的なリーダーとして、このデータ駆動型の可能性を最大限に活用し、それを目に見える成果に変えるには、どのようなステップが必要となるのでしょうか? この半日間のイベントでは、AWS のエキスパート、パートナー、お客様、主要なスタートアップが、今日の進化し続ける環境の中で、データと生成系 AI を使用してイノベーションを推進する取り組みについてのインサイトを提供します。この革新的なテクノロジーがもたらすさまざまな機会や課題にどのように対応すべきかについて、業界リーダーからの実践的なガイダンスを得ながら、同時に将来に何が待ち受けているかを感じ取ることができます。 このイベントで予定されているハイライトをいくつかご紹介します。 AWS の Database, Analytics, and ML 担当 VP である Swami Sivasubramanian がイベントの開始に際して基調講演を行い、ビジネスリーダー向けにデータと AI を民主化するための青写真を共有します。Swami は、リーダーが生成系 AI の可能性を実際のビジネス価値に変えるための正しい考え方、戦略、ツールをどのように採り入れることができるのかについて語ります。 AWS の Enterprise Strategy 担当 Director である Tom Godden は、生成系 AI を活用してビジネスの成果を推進するための実践的な戦略について詳しく説明します。Tom は、組織全体で生成系 AI を試験運用する機会を特定するためのフレームワークを共有するとともに、これらの強力な新機能の活用方法について、ビジネスリーダーが時宜にかなったかたちで理解できるように説明します。 Informatica の Strategic Cloud Ecosystems 担当 Vice President である Gopinath Sankaran 氏は、生成系 AI がデータ管理に及ぼす影響に関するインサイトを共有するとともに、Informatica の AI を活用した Intelligent Data Management Cloud と AWS の AI および分析サービスが、インサイトとエクスペリエンスの新しい波をどのように強化できるかを探ります。 Deloitte の Data & AI 担当 Managing Director である Diego Saenz 氏と、Deloitte の Global Financial Services Industry (GFSI) Data, Analytics, & AI 担当 Principal の Jojy Matthew 氏は、綿密に練られたデータ戦略が、生成系 AI の成功にとって何を意味するかを共有します。Diego は、生成系 AI を活用してビジネス成果を推進するためにデータ資産の準備が整っているかどうかを評価するための実践的なアドバイスを共有します。 AWS のリーダー、ならびに AWS のお客様である FOX、Salesforce、および Booking.com は、データと生成系 AI に関する取り組みを共有し、この革新的なテクノロジーを活用して顧客と従業員のエクスペリエンスを再考する方法について説明します。 イベントページ でご登録いただくと、カレンダーにイベントリマインダーを追加できます。 当日お会いできるのを楽しみにしています。 – Irshad 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、列レベルのデータ暗号化をサポートしています。列レベルの暗号化では、すべての列または選択した列に適用できるより詳細なレベルのデータを暗号化できます。列レベルの暗号化では、列ごとに異なる暗号化キーを定義できます。 SQL Server では、接続、データ、ストアドプロシージャに暗号化を使用できます。暗号化の詳細については、「 SQL Server 暗号化 」を参照してください。 この投稿では、Amazon RDS for SQL Server に列レベルの暗号化を実装する方法を紹介します。 SQL Server の暗号化 Amazon RDS は、 データベースインスタンス 、 自動バックアップ 、 リードレプリカ 、 スナップショット の基盤となるストレージを保護するために、 AWS Key Management Service (AWS KMS) を使用して 保存時の暗号化 をネイティブに提供します。 Amazon RDS for SQL Server は、Microsoft SQL Server Enterprise Edition と Standard Edition でサポートされている透過的データ暗号化 (TDE) をサポートしています。 TDE はデータベース内の機密データを暗号化し、証明書を使用してデータを暗号化するキーを保護します。このソリューションでは、キーを持っていない人がデータを使用できないようにします。この種の保護は事前に計画しておく必要があります。TDE は、データおよびログファイルの I/O 暗号化と復号化をリアルタイムで行います。暗号化にはデータベース暗号化キー (DEK) を使用します。データベースブートレコードには、復旧時に使用できるようにキーが保存されます。DEK は対称キーです。サーバーのプライマリデータベースに保存される証明書または EKM モジュールが保護する非対称キーによって保護されます。 TDE は保存中のデータ、つまりデータファイルとログファイルを保護します。これにより、さまざまな業界で確立されている多くの法律、規制、ガイドラインに従うことができます。この機能により、ソフトウェア開発者は既存のアプリケーションを変更せずに AES および 3DES 暗号化アルゴリズムを使用してデータを暗号化し、データがストレージから読み取られるとデータを自動的に復号化できます。不正な復号化を防ぐために、TDE は暗号化キーをデータベース外部のセキュリティモジュールに保存します。データベースレベルの完全な暗号化を実装したいと考えているなら、TDE は良い選択肢です。 TDE はデータベース全体を暗号化しますが、列レベルの暗号化ではデータベース内の個々の列を暗号化できます。暗号化を行うと、対応する復号化キーやパスワードがないとデータが役に立たなくなります。暗号化を行ってもアクセス制御の問題は解決されません。ただし、一部のユースケースでは、アクセス制御がバイパスされてもデータ損失が制限され、セキュリティが強化されます。たとえば、データベースホストコンピューターの設定に誤りがあってハッカーが機密データを入手した場合、盗んだ情報が暗号化されていれば役に立ちません。 ソリューション概要 SQL Server の列レベルのデータ暗号化は、暗号化階層に基づいています。暗号化階層は、データと暗号化キーを保護するために使用されます。階層レベルは以下のとおりです。 Windows レベル – このレベルは、Windows データ保護 (DP) API を使用して次のレベルを暗号化して保護します。 SQL Server レベル – このレベルには Windows レベルで保護されているサービスマスターキー (SMK) が含まれています。SMK は次のレベルを保護するために使用されます。 データベースレベル – このレベルには、データベースマスターキー (DMK) と残りのキーと証明書が含まれます。DMK はデータベース内の証明書、対称キー、非対称キーを暗号化して保護します。 次の図は、完全な暗号化階層 ( Microsoft ドキュメント にあるアーキテクチャリファレンス) を示しています。 列レベルの暗号化は、対称キーまたは非対称キーをそれぞれ証明書またはパスワードと組み合わせて使用することで実現できます。次の図は、列レベルの対称暗号化と非対称暗号化の概要を示しています。 以下のセクションでは、両方の実装方法を示します。 方法 1: 対称キーによる列暗号化 対称キーによる列レベルの暗号化の実装手順は次のとおりです。 RDS インスタンスで、次のコマンドを使用して SMK が存在することを確認します。 Use Master go select * from sys.symmetric_keys go データベースの対称キーを作成するには、まず、対称キーストアの保護機能として機能するマスターキーと証明書を使用してユーザーデータベースを設定する必要があります。 データベースレベルのプライマリキーを作成します。 use <dbname> CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<password>’ 証明書を作成します。 use <dbname> CREATE CERTIFICATE <certificate-name> WITH SUBJECT = 'A label for this certificate' 対称キーを作成します。 use <dbname> CREATE SYMMETRIC KEY <key-name> WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE <certificate-name>; GO 列を暗号化します。 use <dbname> OPEN SYMMETRIC KEY <key-name> DECRYPTION BY CERTIFICATE <certificate-name>; UPDATE <table-name> SET <encrypted-column-name> = EncryptByKey(Key_GUID('<key-name>’), <column-name>); 列を復号化します。 use <dbname> OPEN SYMMETRIC KEY <key-name> DECRYPTION BY CERTIFICATE < certificate-name>; GO SELECT CONVERT(varchar, DecryptByKey(<encrypted-column-name>)) AS 'Decrypted-column’ FROM <table-name>; GO 方法 2: 非対称キーによる列暗号化 非対称キーによる列レベルの暗号化の実装手順は次のとおりです。 RDS インスタンスで、インスタンスの起動時に Amazon RDS ですでに作成されている SMK を確認します。 Use Master go select * from sys.symmetric_keys go ユーザーデータベースの非対称キーを作成するには、まずプライマリキーを使用してデータベースを設定し、次にパスワードで暗号化して非対称キーを作成する必要があります。 データベースレベルのプライマリキーを作成します。 use <dbname> CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<key-password>’ 非対称キーの作成します。 use <dbname> IF NOT EXISTS (SELECT * FROM sys.asymmetric_keys WHERE name = '<Asym-key-name>') BEGIN CREATE ASYMMETRIC KEY <Asym-key-name> WITH ALGORITHM = RSA_2048 ENCRYPTION BY PASSWORD = '<Asym-key-password>' ; END GO 列を暗号化します。 use <dbname> UPDATE <table-name> SET <encrypted-column-name> = ENCRYPTBYASYMKEY(ASYMKEY_ID('<Asym-key-name>'), <column-name>) GO 列を復号化します。 use <dbname> SELECT *, <Decrypted-column-name> = CONVERT(CHAR(11),DECRYPTBYASYMKEY(ASYMKEY_ID ('<Asym-key-name>'), <encrypted-column-name>, N'<Asym-key-password>’)) FROM <table-name>; GO まとめ この投稿では、Amazon RDS for SQL Server に列レベルの暗号化を実装する方法を学びました。暗号化はセキュリティの確保に役立つ貴重な技術ですが、すべてのデータや接続に暗号化を考慮すべきではありません。暗号化を実装するかどうかを決めるときは、ユーザーがどのようにデータにアクセスするかを検討してください。ユーザーがパブリックネットワーク経由でデータにアクセスする場合は、セキュリティを強化するためにデータを暗号化することを強くお勧めします。ただし、すべてのアクセスがセキュアに設定されたイントラネットの中にある場合は、暗号化は必要ない場合があります。暗号化を使用する際には、パスワード、キー、証明書のメンテナンス方法も含める必要があります。 著者について Kiran Mulupuru は、アマゾンウェブサービスのデータベーススペシャリストテクニカルアカウントマネージャーです。Amazon RDS と Amazon Aurora データベースを専門としています。彼女はお客様と協力して、データベースの運用パフォーマンスに関する技術支援を提供し、データベースのベストプラクティスを共有しています。 Lakshman Thatisetty は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼は AWS のお客様と協力してデータベースプロジェクトに関するソリューションを設計し、既存のデータベースを AWS クラウドに移行してモダナイズする支援や、AWS での大規模な移行のオーケストレーションを支援しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、Microsoft SQL Server を実行している DB インスタンスに保存されているデータを暗号化するための 透過的データ暗号化 (TDE) をサポートしています。 TDE は、データをストレージに書き込む前に自動的に暗号化し、ストレージからデータを読み取るときにデータを復号化します。 TDE 証明書の有効期限は、証明書がいつ作成されて有効期限と関連付けられるかによって異なります。Amazon RDS for SQL Server の場合、TDE 証明書は、 オプショングループ を使用してインスタンスで TDE を有効にした日から1 年後に有効期限が切れます。この TDE 証明書の有効期限が切れると、監査の観点から RDS for SQL Server インスタンスがコンプライアンス違反になります。ただし、証明書の有効期限が切れても TDE の動作は停止しません。 TDE が有効になっている Amazon RDS for SQL Server で適切な監査とコンプライアンスを確保するためのベストプラクティスとして、TDE 証明書を RDS for SQL Server インスタンスで毎年ローテーションする必要があります。これには、新しい証明書を作成し、既存の証明書の有効期限が切れる前に新しい証明書を使用することが含まれます。 ソリューション概要 TDE 暗号化階層には、サービスマスターキー (SMK) を暗号化する Windows オペレーティングシステムレベルのデータ保護 API (DPAPI) をはじめとする複数の保護レベルが含まれます。この SMK はプライマリデータベースのデータベースマスターキー (DMK) を暗号化し、TDE 用に作成された証明書の秘密キーを保護します。この証明書はデータベース暗号化キー (DEK) を保護し、それによってデータが暗号化および復号化されます。 次の図は、完全な暗号化階層 ( Microsoft からのアーキテクチャリファレンス) を示しています。 DEK は対称キーであり、SMK や DMK のように変化しません。ただし、証明書は作成プロセスの一環として有効期限付きで生成されるため、ローテーションが必要になります。次の図は、Amazon RDS for SQL server に TDE をハイレベルに実装するためのリファレンスアーキテクチャを示しています。 実装 TDE 対応の Amazon RDS for SQL Server で TDE 証明書を定期的にローテーションするには、次のステップを実行します。このプロセスにはダウンタイムは発生しないことに注意してください。ただし、大規模なデータベースを使用する場合はインスタンスのパフォーマンスを監視する必要があります。 RDS for SQL Server インスタンスがマルチ AZ モードの場合は、シングル AZ モードに変更します。   TDE オプションは永続的なオプション であり、すべての DB インスタンスとバックアップがオプション グループから関連付け解除されない限り、オプション グループから削除できないからです。 TDE 証明書の詳細を確認します。 USE [master] GO SELECT name FROM sys.certificates WHERE name LIKE 'RDSTDECertificate%' GO 暗号化されたデータベースを確認します。 USE [master] GO SELECT name FROM sys.databases WHERE is_encrypted = 1 GO SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys GO TDE を無効化します。 USE [DBNAME] ALTER DATABASE [DBNAME] SET ENCRYPTION OFF GO USE [DBNAME] DROP DATABASE ENCRYPTION KEY GO TDE を検証します。 USE [master] GO SELECT name FROM sys.databases WHERE is_encrypted = 1 GO SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys GO 復旧モデルを SIMPLE に変更します。これにより、ログファイル内の暗号化された値をすべて消去できます。 注意 : 復旧モデルを変更すると、 DMS のような復旧モデルに依存しているサービス に影響がある可能性があります。Amazon RDS for SQL Server の復旧モデル変更に関しては こちら をご参照ください。 ALTER DATABASE [DBNAME] SET RECOVERY SIMPLE GO 復旧モデルを FULL に変更します。 ALTER DATABASE [DBNAME] SET RECOVERY FULL GO TDE が有効になっていないオプショングループに切り替えるようにインスタンスを変更します。   この結果、古い TDE 証明書は RDS for SQL Server インスタンスから完全に削除されます。オプショングループの詳細については、「 オプショングループを使用する 」と「 オプショングループにオプションを追加する 」を参照してください。 RDS インスタンスが使用可能になったら、オプショングループに TDE オプションを追加すると、新しい証明書が生成されます。   データベース復旧モデルが FULL – SIMPLE – FULL と変更すると、新しいスナップショットが作成されます。 スナップショットが完成したら、Amazon RDS コンソールを使用してインスタンスをマルチ AZ に戻します。 オプショングループをアタッチし、シングル AZ に変更してからマルチ AZ に変更し直しても、ダウンタイムは発生しません。ただし、データベース復旧モードとマルチ AZ が変更されるため、このプロセス中は高可用性とポイントインタイムリカバリ (PITR) に影響があります。 Amazon RDS for SQL Server での TDE の制限事項 このソリューションには以下の制限があります。 このソリューションは、SQL Server 2019 Standard Edition と Enterprise Edition、および SQL Server 2012-2017 Enterprise Edition でのみサポートされています。 Amazon RDS は TDE 証明書のインポートまたはエクスポートをサポートしていません。 TDE 対応データベースのネイティブバックアップは作成できますが、そのバックアップをオンプレミスデータベースに復元することはできません。TDE 対応のオンプレミスデータベースのネイティブバックアップは復元できません。 まとめ この投稿では、RDS for SQL Server インスタンスで TDE 証明書をローテーションする方法を学びました。この方法を使うと、証明書の有効期限が切れる前に TDE 証明書を適時にローテーションし、インスタンスが適切にコンプライアンスを守れるようにすることができます。 著者について Lakshman Thatisetty は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。彼は AWS のお客様と協力してデータベースプロジェクトに関するソリューションを設計し、既存のデータベースを AWS クラウドに移行してモダナイズする支援や、AWS での大規模な移行のオーケストレーションを支援しています。 Saroj Kumar Das は、アマゾンウェブサービスのクラウドサポートエンジニアです。彼は AWS のお客様と仕事をしており、SQL Server に特化した Amazon RDS データベースプラットフォームに関する深い技術的専門知識を提供しています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

生成系 AI (Generative AI) への関心が広まったことで、ビジネス上の課題、特に顧客サービスの課題を解決するために AI の利用に再び注目が集まっています。生成系 AI は、会話、ストーリー、画像、動画、音楽など、新しいコンテンツやアイデアを生み出すことができる AI の一種です。 マッキンゼー によると、カスタマーエクスペリエンス (CX) は生成系 AI のトップユースケースの 1 つです。同社は生成系 AI をカスタマーケア領域に適用することで、生産性コストが 30 ～ 45% 改善すると予測しています。 3 部構成のブログ投稿シリーズの第 1 部では、生成系 AI とは何か、生成系 AI が CX 環境をどのように変えているか、そして生成系 AI がもたらすビジネス成果について見ていきます。第 2 回と第 3 回では、生成系 AI を成功させるための重要な考慮事項と、CX 環境で大規模言語モデル (LLM) を使用する際のベストプラクティスについて詳しく説明します。 生成系 AI によるカスタマーエクスペリエンスの革新 生成系 AI は、大量のデータに対して事前にトレーニングされた非常に大規模な 機械学習 モデルによって実現されています。たとえば、 Amazon Bedrock で公開されている Anthropic の Claude 2 は、1370 億個のパラメータを使用してトレーニングされました。これらの事前トレーニング済みモデルは、一般に基盤モデル (FM) と呼ばれます。大規模言語モデル (LLM) は、人間のようなテキストの理解と生成に重点を置いた FM の一種です。 LLM は、コンタクトセンターが大量のデータを管理および処理する方法を改善し、リアルタイムで CX を強化できるため、CX のユースケースで素晴らしい可能性をもたらします。たとえば、LLM の備える人間並みのテキスト生成機能は、CX にとってすぐに活用できる分野です。テキスト生成により、会話の要約のようなテキストを生成したり、エージェントをリアルタイムで支援することに利用できます。 LLM はコンタクトセンターでの自動化を成功させるための基礎となる、音声やチャットボットの会話の自然言語処理も改善します。 LLM が会話のコンテキスト（通話履歴、以前の会話の記録、以前の取引など）として膨大な量のメタデータを活用できるためです。さらに、 LLM は複雑で非線形の文章構造をより簡単に理解できるため、連絡の意図を正確に判断できます。 発信者が自然言語理解 (NLU) 旅行ボットと対話する例を考えてみましょう。旅行者がこのボットに「ノルウェーの首都」へ旅行する意図を伝えたとします。従来の NLU ボットには、その意図を適切に解決するためのコンテキストがありません。 NLU ボットは、結果を得るためのデータセットがはるかに限られているため、通常、LLM ほどパラメータートレーニングの深さはありません。しかし、 LLM を統合すれば、ボットは顧客がオスロへの旅行を希望していることを「理解」するでしょう。これは、 LLM が膨大なパラメータ知識を使って顧客の意図を解決するという、非常に単純な例です。 LLM が生成する応答よりも予測性の高い結果を得るために、回答を特定の小さなデータセットに限定したいというユースケースがあるかもしれません。これらのユースケースとトレードオフについては、このシリーズの今後のブログ記事で詳しく説明します。 生成系AIでコンタクトセンタービジネスはどう改善できるか 私たちはカスタマーエクスペリエンスの向上は、生成系 AI のトップユースケースの1つだと考えています。それは、生成系 AI によって、エージェントへの支援、マネージャー向けの洞察、顧客向けのセルフサービス体験をさらに改善する機会があるからです。 生成系 AI がコンタクトセンターでどれほど役立つかを検討する際には、達成しようとしているビジネス成果から始めることが重要です。これにより、コンタクトセンターにおける生成系 AI の具体的なユースケースを絞り込むことができます。生成系 AI の次の 3 つのユースケースは、エージェントの効率を高め、データをより正確に処理し、顧客がより複雑なクエリへの回答を得られるようにすることで、すぐにビジネス価値をもたらします。 生成系 AI は、エージェントが顧客の問題に対応する際の効率性と正確性を向上させることで、 処理時間をさらに短縮し、初回解決率を高める ことに役立つ可能性があります。生成系 AI で企業のナレッジコンテンツから要約された回答やアクションをリアルタイムに生成することで、エージェントの能力を助け、エージェントが顧客の問題を迅速かつ正確に解決できるようにします。たとえば、顧客が自動車保険の請求について問い合わせるために電話をかけてきた場合、 LLM は顧客の請求と保険契約に関する情報、保険会社の Web サイトにある修理店の詳細、内部リポジトリの保険契約書を活用して、エージェントに包括的な対応と顧客の問題解決に役立つ次のアクションを提供できます。 また生成系 AI により、少量のサンプルではなくすべてのコンタクトを分析することで、 対応中のリアルタイムおよび対応後の分析と品質保証の取り組みを強化 することもできます。これにより、マネージャーは洞察をより迅速に特定し、エージェントがポリシーを順守していることを確認できます。生成系 AI を使用して会話を簡潔にまとめることができるため、エージェントやマネージャーが会話を引き継ぐ際にメモを取ったり確認したり、経緯を共有したりする時間を短縮できます。たとえば、生成系 AI は、回線契約の問い合わせに関する長い会話を「顧客がエージェントから提示された 10 ドルのリベートを拒否した後、回線契約をキャンセルした」と要約できます。また、 LLM は、エージェントの能力がビジネス成果をどのように左右するか、さらなる洞察をマネージャーに提供します。その後、コーチングポイントやエージェントトレーニングなどの推奨アクションを提供して、パフォーマンスをさらに向上させることができます。 さらに、セルフサービスエクスペリエンスを最適化して、 様々なチャネルを活用し、自動セルフサービスエクスペリエンスの開発コストを削減 したいと考えているかもしれません。生成系 AI はここでも、企業が顧客の意図の複雑なニュアンスを理解しやすくすることで役に立ちます。また、セルフサービス体験の設計、構築、更新を容易にするコンタクトセンターの構成を改善するための、 LLM を活用した推奨事項も提供できます。 Amazon Connect と生成系 AI の組み合わせによる可能性 2017 年に Amazon Connect の提供を開始したとき、統合された AI 機能をゼロから構築しました。これにより National Australia Bank 、 Traeger 、 Accor 、 Just Energy などのお客様が、処理時間の短縮や顧客満足度の向上などの成果を実現しています。私たちは Amazon Connect の既存の組み込み AI 機能を生成系 AI を使って強化することで、さらなるビジネス価値をもたらす機会があると考えています。 以下のデモでは、生成系 AI をコンタクトセンターの 3 つのユースケース (エージェントアシスタンス、マネージャーアシスタンス、カスタマーセルフサービス) にどのように使用できるかを紹介します。 効率的で効果的なサービスを顧客に提供しながら、コンタクトセンターの実際のビジネス成果を促進する生成系 AI のアプリケーションについて、皆様と協力できることを嬉しく思います。 より深く生成系 AI を理解するための関連記事 生成系 AI のビジネス価値を組織で実現 How Technology Leaders Can Prepare for Generative AI (英文) How Your Organization Can Prepare for Generative AI (英文) An introduction to generative AI with Swami Sivasubramanian (英文) 上のデモビデオで紹介されている生成系 AI を活用したカスタマーセルフサービスソリューションを試す方法の詳細については、以下をご覧ください Deploy self-service question answering with the QnABot on AWS solution powered by Amazon Lex with Amazon Kendra and large language models (英文) 著者について  Mike Wallace は AWS でアメリカのカスタマーエクスペリエンス分野のソリューションアーキテクトをリードしています。 Andrea Caldwell は AWS の Amazon Connect のプロダクトマーケティングマネージャーです。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

Amazon QuickSight は、クラウド向けに構築されたビジネスインテリジェンス (BI) サービスです。機械学習 (ML) を活用しており、スケーラブル、サーバーレス、埋め込み可能です。QuickSight により、Web ブラウザーやモバイルデバイスを介してアクセス可能な、インタラクティブなダッシュボードや高度な形式のレポートを作成および公開できます。2023 年 11 月 7 日から、QuickSight に新しい分析体験が導入されます。新しい体験では、QuickSight でダッシュボードをより直感的かつ効率的に作成できるようになります。本ブログでは、この再設計の主な体験を紹介し、作成者が美しいダッシュボードやレポートを作成するためにより改良されたワークフローについて説明します。 主要な体験 今回の再設計により、QuickSight は次のような重要な体験を実現しました。 3 ペインレイアウト – 新しく合理化されたレイアウトでは、データ、ビジュアライゼーション構築、オブジェクトプロパティの間を簡単に移動することが可能な、明確で整理されたワークスペースを提供します。3 ペインの分析体験には、ペインコンポーネントの更新、縦型に整理された新しいフィールドウェル、フィールドのドラッグアンドドロップ、追加/編集ワークフロー、ビジュアルタイプセレクターの再設計、プロパティペインが含まれます。 分析ツールバー – 作成、編集、ペイン管理といった重要な機能にたった 1 クリックでアクセスでき、分析体験全体を通してより効率的に作業することが可能になります。 以下は、作成プロセスを効率化するために、コアとなるオーサリングワークフローがどのように再設計されたかを示しています。 ビジュアルの追加 – 作成者は、キャンバスにビジュアルをシームレスに追加する作業をよりスムーズに、複数の方法で行うことができます。ビジュアルの追加と、テキストやカスタムコンテンツなどのその他のオブジェクトの追加を簡単に区別できるようにしました。これにより、作成者はより柔軟な制御を行えるようになります。 ビジュアルの変更 – 再設計された UI により、ビジュアルの変更がより意図的に行えるようになりました。作成者がビジュアルを選択しているか否かに基づいて、UI にてその状況を確認できます。これにより、意図しない変更を防ぎ、シームレスな変更を行うことが可能になりました。 ビジュアルへのデータの追加 – フィールドリストの横にある縦型のフィールドウェルを使用すると、データフィールドを簡単にドラッグアンドドロップできます。これにより作成者のワークフローが改善されます。 プロパティの編集 – Properties は画面の右側に設置された専用のペインとなり、1 つ以上のビジュアルのプロパティを簡単に編集できるようになりました。プロパティペインには、条件付き書式設定やアクションなど、オブジェクトに関連するすべてのプロパティが統合されるようになりました。 新しい体験へのナビゲーション – 導入された変更のほとんどは直感的に操作できるように設計されていますが、作成者が機能やワークフローを発見することができるように、様々な分析アクションを検索する機能も導入しました。分析メニューに統合されたクイック検索により、分析体験内の機能の発見がより簡単になります。クイック検索ではキー操作のたびに検索結果が絞り込まれるため、特定の機能を簡単に見つけることができます。ダッシュボード作成タスクの効率を向上させながら、目的の機能に移動することができます。 ベータ体験のオプトアウト – 以前の体験に戻したい場合は、2023 年 11 月 21 日まで可能です。オプトアウトするには、ツールバーの右上にある [New Look] をクリックし、 [Switch back] を選択します。新しい体験に変更する準備が完了次第、いつでもこのオプションから新しい UI に切り替えることができます。 まとめ 本ブログでは、再設計された分析体験によって、どのように QuickSight が多様なデータ分析要件に適した、強固、柔軟、安全な BI プラットフォームとしてより良く機能するのかについて説明しました。主要なオーサリングワークフローの再設計は、2023 年 11 月 7 日から利用可能です。 詳細については、 Amazon QuickSight や AWS の最新情報の Quicksight フィード を参照してください。 ご質問やご意見がございましたら、コメントを残してください。 追加のディスカッションや、質問への回答を得られるヘルプについては、 QuickSight コミュニティ をチェックしてください。 翻訳はソリューションアーキテクトの守田が担当しました。原文は こちら です。 著者について Rushabh Vora は、Amazon Web Services のクラウドネイティブなフルマネージド BI サービスである Amazon QuickSight のシニアテクニカルプロダクトマネージャーです。彼はデータ可視化に情熱を注いでいます。以前は、Amazon Business でプロダクトマネージャーとして働いていました。

本ブログ記事は、NASCAR の Event & Media Technology 担当 Managing Director である Chris Wolford と共同執筆しました。 はじめに National Association for Stock Car Auto Racing（NASCAR）は、1940 年代後半まで遡る、豊かな歴史を有します。時を経て、NASCAR は世界で最も人気のあるモータースポーツ組織の1つとなり、スーパースピードウェイ、オーバルトラック、ロードコース、ストリートサーキットを巡る、ホイールツーホイールレースの接戦をファンに届けています。何百万人もの視聴者が観戦する NASCAR 最高峰の NASCAR カップシリーズでは、40 台のレースカーが、時速 200 マイルを超える最高速度で競い合います。 レースの最中、クルーチーフ、スポッター、ピットクルー、エンジニア、その他のチームメンバーから成る各チームは、それぞれの協力のもと、さまざまなデータポイントを分析してリアルタイムの意思決定を行います。しかし、データはラップごとに絶えず変化していきます。たとえば、タイヤの摩耗状況は戦略を組み立てるうえで、チームにとって重要な要素となる場合があります。チームは、いつピットストップを行うか、またレース中に何回行うべきか決めなければなりません。ところが、タイヤの摩耗に関するデータはラップごとに異なる可能性があるため、データ分析を行い、全体的なレース戦略を実行に移すうえで、ドライバーやエンジニアと連携を図り、クルーの専門知識を活かすことは極めて重要となります。そこで、データ分析やその適用を効率化するクラウドベースのサービスとソリューションを提供しているのが Amazon Web Services（AWS）です。 NASCAR のデータパイプラインは、チーム内にとどまるものではありません。NASCAR はリアルタイムのレーシングデータを放送局やファンと共有し、比類なきファン体験を提供しています。「NASCAR は、単一のレースから他のどこよりも圧倒的に多くのコンテンツ、データ、ビデオを生み出しています。」と NASCAR の Operations and Technical Production 担当 VP である Steve Stum は述べています。「トラック上でより多くのコンテンツをクラウドへと移行を進めるに伴い、私たちは AWS の限界を押し広げてきました。そして、AWS のエンジニアは、そのデータをファンやレーシングチームのデバイスに取り込めるよう、優れたソリューションをいくつも提案してくれました。」 それでは、NASCAR が AWS を活用して、レーシングチーム、放送局、そしてファンにリアルタイムのデータをどのように提供しているかを探っていきましょう。 レースの未来：NASCAR の NextGen car (次世代車両) 2022年にデビューした NextGen car は、チームの競争力を高め、安全性を向上させ、コスト削減を図るために開発されました。新しい設計には、独立したリアサスペンションや、シングルラグナットを使用する新しい 18 インチホイールなど、前世代から多くの空気力学的および機械的な変更が加えられました。これらの機械的な設計変更以外にも、NextGen car にはテクノロジーの変更やアップグレードが施されました。この NextGen car により、競技中のパフォーマンスに関するインサイトがより多く提供されるようになり、NASCAR は、以前までは不可能だった、データポイントの追加を将来的には実現できるようになりました。 レース中、40 台の NextGen car に装備された多数のセンサーが、エンジン回転数からブレーキ圧に至るまで、合計 60 を超えるデータポイントであらゆるデータをキャプチャします。これらのデータポイントはすべて、各車両で毎秒数百回サンプリングされ、その結果、レース中には毎秒 612,000 件を超えるメッセージが送られます。メッセージあたりのサイズが 0.15 KB であることを踏まえると、NASCAR は、レース中に（時には最大 4 時間にわたって）約 92 MB/秒のデータ取り込みに対応できるシステムを必要としていました。いったん取り込んだデータは、競技チームや他の NASCAR パートナーにリアルタイムでストリーミングする必要がありました。さらに複雑なことに、この種のデータ収集は、レースシーズン中、全米の複数のレーストラックで利用可能でなければなりませんでした。 これを実現するために、NASCAR は AWS プロフェッショナルサービスと協業し、Event Racing Data Platform（ERDP）と呼ばれる、車両のテレメトリーデータを取り込み、ストリーミングするプラットフォームを構築しました。 図 1：Event Racing Data Platform のアーキテクチャ NextGen car からデータをキャプチャする NextGen car- のテレメトリーデータが辿るジャーニーの第一歩は、車両そのものから始まります。レースカーには 60 種類以上のセンサーが装備されており、エンジン、タイヤ、エクステリアなどからデータが収集されています。これらのデータはいずれも、各車両に搭載された電子制御ユニット（ECU）によって収集、集約されます。この集約されたデータパケットは、40 台の車両のそれぞれから極超短波（UHF）の電波を介して、各トラックの中継局に 10 ミリ秒ごとに送信されます。次にこの中継局は、このデータパケットを、トラックの内部ネットワーク上の UDP 経由で、NASCAR のモバイルデータセンター（MDC）に転送し、各レーストラックへとジャーニーは進みます。 超低レイテンシーでエッジからクラウドへと境界を押し広げる ジャーニーにおける現段階では、集約されたデータはトラック上の MDC に到達し、取り込みサーバーによってデコードおよびデアグリゲートされます。ここで、データメッセージはトレーラー車内のデータパブリッシュ用クラスターで利用できるようになります。その後、これらのデータメッセージは、MDC 内の Kubernetes クラスター上で稼働している NATS と呼ばれるオープンソースの pub/sub メッセージングシステムによって処理されます。このクラスターは、受信データのコピーをローカルに保持することに加え、クラウドで稼働している受信側の NATS クラスターにメッセージを伝播することを目的としています。車両を離れてからメッセージが利用可能になるまでの総経過時間は、ローカルのトラックでは 40 ミリ秒未満、クラウドでは 200 ミリ秒未満です。 トラック上の MDC と AWS 間の超低レイテンシー通信を実現するために、NASCAR は AWS Direct Connect （DX）接続を利用しています。Direct Connect を利用することは、このソリューションを全国のすべてのトラックで再現可能とするための非常に重要な要素となっています。各トラックには Direct Connect へのルーティングを備えたプライベートネットワークがあるため、トラックからクラウドへのデータ転送には常に AWS バックボーンネットワークが使用されています。これにより、パブリックインターネットをバイパスし、ソリューションに必要な超低レイテンシーを実現することができます。また、クラウドインフラストラクチャを単一の AWS リージョンに配置し、レースが物理的にどこで行われていても、同じパフォーマンスを提供することができます。 テレメトリーデータは、NATS クラスターから DX  接続を介して、NASCAR の AWS アカウントに配置されている、 Amazon Elastic Load Balancing のNetwork Load Balancer (NLB)に送信されます。NLB は、受信トラフィックのレイヤー 4 ロードバランサーとして機能するため、NLB を使用することで非常に高いスループットを得ることができます。送信先は受信側の NATS クラスターです。このクラスターは、同様に Kubernetes 上で稼働しており、 Amazon Elastic Kubernetes Service (EKS) で管理されています。これで、テレメトリーデータの準備が整い、ダウンストリームで消費可能となります。 データが車両を離れてからトラック上のサブスクライバーに届くまでの総経過時間は 40 ミリ秒弱であり、これがクラウド経由でアクセスできるサブスクライバーの場合、インターネットレイテンシーにもよりますが、200 ミリ秒弱となります。 NASCAR、レースチーム、自動車メーカーがどのようにデータを活用しているか NASCAR の AWS アカウントで利用可能なレーシングテレメトリーデータは、ダウンストリームでの活用方法や消費方法に従って、3 つの異なる送信先があります。 図 2：テレメトリーデータストレージ 何よりもまず、NASCAR はこのレーシングテレメトリーデータを信頼できる唯一の情報源として、安全かつ永続的に保存する必要があります。これを実現するために、テレメトリーデータは Amazon Kinesis Data Firehose  ストリームにストリーミングされます。Firehose は、AWS や他の HTTP のエンドポイントにあるダウンストリームの送信先にデータをリアルタイムでストリーミングするためのツールです。ここでは、 Amazon S3 バケットはレーシングテレメトリーデータの送信先として使用されています。業界をリードする耐久性、データの可用性、セキュリティ、パフォーマンスを備えた Amazon S3 は、NASCAR によって公式のレーシングデータのストレージサービスとして選定されました。 NASCAR が公式利用するためにこのテレメトリーをキャプチャする以外に、レーシングテレメトリーは、サブスクライバーが独自に利用できるようになっています。このサブスクライバーには、レースチーム、自動車メーカー、およびレースに関わるその他の第三者が含まれています。可能な限りリアルタイムに近いデータへのアクセスは、これら多くのサブスクライバーにとって必要不可欠です。どのレーシングチームもトラックでこのデータに直接アクセスできますが、現在では多くのチームに、リモートエンジニアやアナリティクスチームが組み入れられ、彼らが提供し得るインサイトや戦略の決定事項がレースの流れを変え、ドライバーにアドバンテージをもたらします。 図 3：リアルタイムのテレメトリーデータフロー レーシングテレメトリーデータをリアルタイムで取り込むために、サブスクライバーはパブリック向け NLB 経由で EKS クラスターに接続することができます。クラウドへのデータ取り込みと同様に、NLB は低レイテンシーのレイヤー 4 ルーティングを提供しているため、EKS 内のデータへの高速アクセスが可能です。実際にはこれにインターネットレイテンシーが加わり、車両外に配信されてから合計約 200 ミリ秒で、レーシングチームはレーシングテレメトリーデータにリモートアクセスすることができます。 この設計に組み込まれた NATS の重要な特徴の 1 つは、異なるサブスクライバー間でデータを分離している点が挙げられます。特定のレーシングチームが、そのチーム車両のテレメトリーデータを受け取る唯一の受信者であることを保証することは、競技の健全性を確保するうえで必要不可欠です。したがって、ERDP に接続してライブテレメトリーデータを受信するチームは、そのチームに適切なデータセットにのみ、リアルタイムでアクセスすることができます。 図 4：履歴データフロー リアルタイムでの消費に加えて、多くのサブスクライバー向けに、レース後の分析や車両のテレメトリーデータの利用に関するユースケースもあります。これをサポートするために、NASCAR の S3 バケットの公式レーシングデータを、お客様向けの他の S3 バケットにコピーする、データ同期サービスが提供されています。このデータ同期は、 AWS Lambda 関数を使用して実行されます。どのデータをどのチームと共有すべきかについての情報は、設定ファイルとして、これも S3 に保存されています。Lambda はこれらの設定を読み取り、未加工データを変換せずにお客様向けバケットにレーシングデータをコピーします。 データ用に個別の Amazon S3 バケットを用意することや、データ変換を行わないことなどの設計上の決定は、意図的に行われています。第一に、変更されていないデータを提供することで、サブスクライバーは提供されたテレメトリーやレーシングデータが、NASCAR 自身が管理する公式のレーシングデータ（信頼できる情報源）と一致していることを確認できます。第二に、メインとなる NASCAR のバケットをお客様向けバケットから切り離すことで、データセキュリティおよび耐障害性が向上します。レーシングテレメトリーデータとのやり取りを行うダウンストリームサービスは、公式の NASCAR のバケットと直接やり取りすることはありません。さらに、データの取り込みで問題が発生した場合、提供準備が整っていないデータ、または破損している可能性のあるデータはダウンストリームのサブスクライバーには提供されません。 まとめ NASCAR のテクノロジーへの投資は、より公平な競技の場、より接戦となる競争、そしてより魅力的なファン体験をもたらしています。AWS Direct Connect、ELB、EKS、および Kinesis Firehose は、NASCAR に超低レイテンシーのデータストリーミング機能を提供し、スポーツをモダナイズしています。Amazon S3 の業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスにより、NASCAR は有用なデータをダウンストリームに提供することができます。NASCAR のデータジャーニーストーリーから得た教訓は、たとえ時速 200 マイルで走行する必要のないビジネスであったとしても、より良いビジネス成果を上げるために、データ活用を推進しているあらゆるビジネスに応用できます。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口が担当しました。原文は こちら をご覧ください。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、ソリューションアーキテクトの山中です。 今年4回目の AWS Innovate を 10 月 26 日に開催します！ 今回はモダンアプリケーション開発にフォーカスした AWS Innovate – Modern Applications Edition です。お客様のビジネス成功に欠かせないアプリケーションをモダナイゼーションすることで得られるメリットやアプローチ方法について集中的に学んでいただくことができます。午前の部と午後の部の 2 回、同じ内容で開催しますので、ご都合に合わせてご参加ください。 Modern Application Edition では、テーマ別に「サーバーレス」、「コンテナ」、「デベロッパーエクスペリエンス」、「お客様事例」の計 4 トラック、16 セッションをご用意しています。 当日のアジェンダはこちらです。 セッションの見どころについて まず、オープニングセッションでは、モダンアプリケーションが提供する価値として「開発のアジリティ」「パフォーマンスやスケーラビリティの柔軟な調達」「セキュリティやレジリエンシーのクラウドインフラストラクチャへのオフロード」「実行環境の選択や開発効率向上によるコスト最適化」の全体像についてお話しをします。また、これまでの Amazon のイノベーションの歴史を振り返りながら、技術的なアプローチだけでなく、「人」や「プロセス」も含めたモダナイゼーション成功のポイントについてご紹介します。 続いて、各トラックです。 「サーバーレス」トラックでは、アプリケーションをサーバーレスで開発する際に、運用やセキュリティ、スケーラビリティなどの観点で押さえておくべきポイントを幅広くお伝えします。サーバーレスなアプリケーションを実際に運用される方は是非ご覧ください。また、サーバーレスなアプリケーションから生成系 AI を活用するためのアプローチについてのセッションも用意しています。 「コンテナ」トラックでは、コンテナ入門者向けに、既存のアプリケーションをコンテナで動かすにあたっての基本的な考え方や、素早くコンテナ上にアプリケーションをデプロイするためのサービスについて紹介します。また、本格的にコンテナを利用される方に向けて、コンテナを使ったプラットフォームエンジニアリングやコンテナのネットワーキングについても解説します。 「デベロッパーエクスペリエンス」トラックでは、開発者体験向上にフォーカスし IaC やオブザーバビリティの話題を扱います。また、統合 DevOps プラットフォームや生成系 AI によるコーディング支援など新しいサービスについてのセッションも用意しています。チーム開発やコーディングの効率化に対するアプローチをご紹介しますので、アプリケーション開発者の方は是非ご覧ください。 「お客様事例」トラックでは、AWS 上でモダンアプリケーションを効率的に開発・運用されている事例や、自社アプリケーションのモダナイゼーションに挑戦されている事例について、お客様からご紹介を頂きます。 AWS Innovate – Modern Applications Edition をより楽しむために イベントの申し込みは こちら になります。AWS が提供するセッションは Level 100、Level 200、Level 300 でセッションレベルを分類しています。トピックに関する前提知識に応じて、セッション選びの参考にしてみてください。 また、当日はライブ Q&A も実施します。セッションで気になったことや疑問点など、お気軽にご相談ください。 みなさまのご参加をお待ちしております。 – ソリューションアーキテクト 山中

コラボスタイルは、クラウド型ワークフロー製品の開発・販売と、ワークスタイル自体のデザインやワークプレイスを構築する事業を展開しています。2022年12月に、自社で開発しているクラウドワークフローシステム「コラボフロー」を Aurora PostgreSQL Serverless v2 化することでスケールアップ時のダウンタイムをゼロに、負荷の高かったスケールアップ作業時の運用負荷を大幅に削減することに成功しました。本ブログは、2023年8月9日に実施した、 2時間で学ぶ！Amazon Aurora オススメ機能 ～Aurora Serverless v2 ～ のイベント内で、コラボスタイルの成島様にご登壇いただいた発表内容を元に、Aurora Serverless v2化の導入検討から導入効果についてまとめたものになります。Aurora Serverless v2の導入を検討している方の参考になればと思います。 アーキテクチャ 以下は、Aurora Serverless v2採用前のコラボフローのアーキテクチャになります。インターネットからWAFを経由するリクエストがCloudFrontからALBを経てアプリケーションサーバーに振り分けられます。アプリケーションサーバーからのリクエストは、Aurora クラスターのWriterインスタンスにアクセスして実行されていました。 大規模な障害の発生 2022年の前半、コラボフローでユーザーの業務に影響するような障害が発生しました。障害の原因を分析した結果、大きく2点が原因であることがわかりました。１つはコラボフロー自体のサービス面の問題で、1. ユーザー数の急激な増加、2. 利用状況の変化、3. アクセス数の増加により、データベースへの負荷が急増したことが原因でした。そしてもう１つはエンジニアのマインド面で、データベース運用が特定のエンジニアに属人化していたことでそのエンジニアを頼りすぎてしまい、多角的な視点が欠如していたことに気づきました。この障害がきっかけで、コラボスタイルでは特定の個人ではなくチームとして対応できるようSREチームを立ち上げ、障害を起こさないインフラ作りをチームで推進することになりました。 スケールアップによる新たな課題 SREチームでは、データベースの負荷を分析して、必要であればAuroraのスケールアップを実施するような運用にしました。これによって、障害を未然に防ぐことができるようになりました。一方で、スケールアップにともなう新たな課題に直面することになりました。 スケールアップにともなう新たな問題 リザーブドインスタンス（RI）のサイジング １つ目はRIのサイジングです。RIは最低1年単位での契約になるため、見積もりも１年間の予測を立てる必要があります。ですが、この障害以降の半年間で２回のスケールアップを実施しており、１年間の予測を立てることが難しい状況になっていました。 検証負荷 コラボスタイルでは、インスタンスサイズの変更に多くの時間を使って検証作業を実施していました。アプリケーションサーバーも含めた検証環境の構築や負荷テスト、負荷テスト結果の分析など、多くの作業が発生するため、スケールアップ毎に多くの時間を割く必要がありました。 停止メンテナンスの増加 スケールアップによるメンテナンスが増えることは、コラボフローのサービスへの影響はもちろん、ユーザーへのメンテナンスの案内や、メンテナンスの夜間作業などのエンジニアへの負担など、間接的な運用負荷も増えることになります。また、このような状況だと年間でのメンテナンス計画も立てづらい状況でした。 監視時間の増加 RIのサイジングやメンテナンスが必要なタイミングを適切に把握するためには、分析作業の頻度も多くする必要があります。その結果、監視時間や分析作業、判定会議などの運用負荷が増加し、本来SREとして取り組むべき作業時間が削られる、という問題も発生していました。 Aurora Serverless v2の導入 このような課題を解消するために、Aurora Serverless v2を導入することを決めました。Aurora Serverless v2は負荷に応じてシームレスにスケーリングすることができるため、コラボフローでのスケーリング時の運用課題を解決できる機能でした。 また、Aurora Serverless v2への変更も、通常のプロビジョンドインスタンスと同じように変更することができます。今回の移行では、ReaderをServerless v2に変更して１ヶ月程度検証したあと、フェイルオーバーで WriterをServerless v2に変更する、といった手順で、徐々にServerless v2に変更しました。この手順であれば、万が一Serverless v2に問題があった場合でも、再度フェイルオーバーすることで簡単にプロビジョンドインスタンスに戻すことも可能でした。 Aurora Serverless v2の導入による効果 Aurora Serverless v2導入して半年以上経過しましたが、パフォーマンス等の問題は発生しておらず、課題だったスケーリングに伴う運用負荷も大幅に改善することができました。 Aurora Serverless v2の性能 Aurora Serverless v2の導入後、通常時はもちろん、サービスによる急激な負荷増大でスケーリングした時でも、4.5ms以下のレイテンシーでパフォーマンスを維持することができており、プロビジョンドと比較しても遜色ないパフォーマンスを実現できています。 運用負荷の改善、RIのサイジングの改善 Aurora Serverless v2はRIがないため、難しい見積もり作業自体が不要になりました。 検証負荷の改善 インスタンスサイズの変更に伴う検証作業は無くなりました。これにより、検証作業に関わるエンジニアの作業工数を削減することができ、本来SREが対応すべき作業にリソースを集中させることができるようになりました。さらに、以前は検証に伴う環境作成で発生するインスタンスコストも削減することができています。 停止メンテナンスの改善 スケールアップ作業自体が不要になり、エンジニアによる深夜対応なども改善されました。また、年間でのメンテナンス計画も立てやすくなりました。 監視時間の改善 RIのサイジングやメンテナンスが必要なタイミングを把握するためのモニタリングは不要になり、それに伴う打ち合わせなども無くなりました。一方で、Aurora Serverless v2のリソースを監視、分析して、最適化できるよう取り組んでいます。 Aurora Serverless v2の最適化 ここでは、SREチームで実施したAurora Serverless v2の最適化の取り組みの１つをご紹介します。SREチームがAurora Serverless v2のリソースを分析したところ、サービスの負荷が低い夜間の時間帯で思うようにスケールダウンがされず、日中のACU（Aurora Capacity Unit）のままのリソースが割り当てられていることがわかりました。ACUは、Aurora Serverless v2のデータベース容量で、1ACUあたり約 2 GiB のメモリとそれに対応する CPU、ネットワークが割り当てられます。 上記のグラフは、オレンジがACUのUtilizationで青がServerless Capacity、赤背景が負荷の低い夜間の時間帯です。ACUのUtilizationを見ると、負荷の低い赤背景の時間帯でも60ACUが割り当てられています。このため、負荷が低い時間帯に対してスケジュールで最小と最大のACUの設定を変更することにしました。このACUの最小値と最大値は再起動が不要で動的に変更可能であるため、Amazon EventBridgeのスケジュールでAWS Lambdaを呼び出し、値を変更することにしました。 この結果、負荷の低い時間帯にスケールダウンされるようになりました。これにより応答性能を維持しつつ、インスタンスのコストを12%削減することができています。 まとめ コラボスタイルでは、今回のAurora Serverless v2の導入を成功させたことで、運用時の課題を改善し、SREチームとして本来の業務に専念することができるようになりました。そして、SREチームが「サービスを守る最強の盾」と代表から評価されるほど、社内でサービスを安定させるためのキーファクターになったことや、開発部の中にSREチームの考え方を強く浸透させることができたこともAurora Serverless v2採用の効果だったと言えそうです。コラボスタイルのSREチームでは、引き続きAWSサービスを利用しつつシステムの安定化やコスト最適化などに取り組んでいく予定です。