5 月 15 日より、 AWS CodeBuild の Docker サーバー機能を使用して、CodeBuild プロジェクト内で直接、永続的な専用 Docker サーバーをプロビジョニングできるようになりました。Docker サーバー機能を使用すると、イメージのビルドをリモートホストに集中化することで Docker イメージのビルドを高速化でき、待機時間を短縮して、全体的な効率を高めることができます。 私のベンチマークでは、この Docker サーバー機能を使用することで、ビルドの合計時間が 24 分 54 秒から 16 秒へと 98% 短縮されました。ここでは、私の AWS CodeBuild プロジェクトを用いて、この機能について簡単に見ていきます。 AWS CodeBuild は、ソースコードをコンパイルし、テストを実行して、デプロイ可能なソフトウェアパッケージを生成する、フルマネージド継続的インテグレーションサービスです。Docker イメージのビルドは、CodeBuild のお客様にとって最も一般的なユースケースの 1 つです。このサービスでは、時間が経過する中で、Docker ビルドのパフォーマンスを改善するために、 Docker レイヤーのキャッシュ や リザーブドキャパシティ機能 などの機能をリリースすることで、このエクスペリエンスを徐々に改善してきました。 新しい Docker サーバー機能で、一貫性のあるキャッシュを提供する永続的な Docker サーバーを提供することで、アプリケーションのビルド時間を短縮できます。CodeBuild プロジェクトで有効にすると、専用 Docker サーバーがプロビジョニングされ、Docker レイヤーのキャッシュを維持する永続的なストレージが提供されます。このサーバーは複数の同時 Docker ビルドオペレーションを処理でき、すべてのビルドで同じ集中キャッシュを利用できます。 AWS CodeBuild の Docker サーバーの使用 新しい Docker サーバー機能の利点を示すデモをご紹介します。 このデモでは、公式の AWS CodeBuild 厳選 Docker イメージリポジトリ 、具体的には 標準 Ubuntu イメージ をビルドするための Dockerfile に基づいて、複雑かつ多層的な Docker イメージを構築します。このイメージには、最新の継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに必要な多数の依存関係とツールが含まれており、開発チームが定期的に実行する大規模な Docker ビルドの好例となります。 # Copyright 2020-2024 Amazon.com, Inc. or its affiliates.All Rights Reserved. # # Amazon ソフトウェアライセンス (以下「ライセンス」という) に基づいてライセンスされています。ライセンスに従わない限り、このファイルを使用してはなりません。 # ライセンスのコピーは、 # # http://aws.amazon.com/asl/ # # またはこのファイルに付属の「license」ファイルにあります。 # このファイルは「現状有姿」で配布されるものであり、明示または黙示を問わず、いかなる種類の保証または条件もありません。 # ライセンスに基づく権限および制限を規定する具体的な文言については、ライセンスを参照してください。 FROM public.ecr.aws/ubuntu/ubuntu:20.04 AS core ARG DEBIAN_FRONTEND="noninteractive" # git、SSH、Git、Firefox、GeckoDriver、Chrome、ChromeDriver、stunnel、AWS Tools をインストールし、SSM を設定して、AWS CLI v2、ランタイム用の環境ツール: Dotnet、NodeJS、Ruby、Python、PHP、Java、Go、.NET、Powershell Core、Docker、Composer、および他のユーティリティをインストールします COMMAND REDACTED FOR BREVITY # イメージバージョンに固有のランタイムバージョンをアクティブ化します。 RUN n $NODE_14_VERSION RUN pyenv global $PYTHON_39_VERSION RUN phpenv global $PHP_80_VERSION RUN rbenv global $RUBY_27_VERSION RUN goenv global $GOLANG_15_VERSION # SSH を設定します COPY ssh_config /root/.ssh/config COPY runtimes.yml /codebuild/image/config/runtimes.yml COPY dockerd-entrypoint.sh /usr/local/bin/dockerd-entrypoint.sh COPY legal/bill_of_material.txt /usr/share/doc/bill_of_material.txt COPY amazon-ssm-agent.json /etc/amazon/ssm/amazon-ssm-agent.json ENTRYPOINT ["/usr/local/bin/dockerd-entrypoint.sh"] この Dockerfile は、複数のプログラミング言語、ビルドツール、依存関係を備えた包括的なビルド環境を作成します。これはまさに、永続的なキャッシュの利点を享受できるタイプのイメージです。 ビルド仕様 (buildspec) では、 docker buildx build . コマンドを使用します: version: 0.2 phases: build: commands: - cd ubuntu/standard/5.0 - docker buildx build -t codebuild-ubuntu:latest . Docker サーバー機能を有効にするには、AWS CodeBuild コンソールに移動し、 [プロジェクトを作成] を選択します。既存の CodeBuild プロジェクトを編集する際にも、この機能を有効にできます。 すべての詳細と設定を入力します。 [環境] セクションで、 [追加設定] を選択します。 その後、下方向にスクロールして [Docker サーバー設定] を見つけ、 [このプロジェクトのために Docker サーバーを有効にする] を選択します。このオプションを選択すると、Docker サーバーのコンピューティングタイプの設定を選択できます。設定が完了したら、このプロジェクトを作成します。 ここからは、Docker サーバー機能が実際にどのように機能するのかを見てみましょう。 最初のビルドは、すべての依存関係を最初からダウンロードしてコンパイルする必要があるため、完了までに約 24 分 54 秒かかります。このような複雑なイメージの最初のビルドでは、通常この程度の時間がかかります。 コード変更のない後続のビルドでは、ビルド時間はわずか 16 秒です。これは、98% のビルド時間の短縮となります。 ログを見ると、Docker サーバーではほとんどのレイヤーが永続キャッシュからプルされていることがわかります。 Docker サーバーが提供する永続キャッシュは、ビルド間ですべてのレイヤーを維持します。これは、多くのレイヤーを持つ大規模かつ複雑な Docker イメージで特に役立ちます。このことは、CI/CD パイプラインで多数の Docker ビルドを実行するチームのスループットを Docker サーバーが劇的に増大できることを意味しています。 その他の知っておくべきこと いくつかの留意点を次に示します: アーキテクチャサポート – この機能は、x86 (Linux) ビルドと ARM ビルドの両方でご利用いただけます。 料金 – Docker サーバー機能の料金の詳細については、「 AWS CodeBuild の料金 」ページをご覧ください。 利用できるリージョン – この機能は、AWS CodeBuild が提供されているすべての AWS リージョンでご利用いただけます。CodeBuild が利用可能な AWS リージョンの詳細については、 AWS リージョンのページ をご覧ください。 Docker サーバー機能の詳細については、 AWS CodeBuild のドキュメント をご覧ください。 構築がうまくいきますように! – Donnie Prakoso 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 15 日、NVIDIA B200 を搭載した Amazon Elastic Compute Cloud (Amazon EC2) P6-B200 インスタンス の一般公開を開始しました。この新しいインスタンスは、 人工知能 (AI) 、 機械学習 (ML) 、 ハイパフォーマンスコンピューティング (HPC) アプリケーションにおける高いパフォーマンスとスケーラビリティへのニーズに応えます。 Amazon EC2 P6-B200 インスタンスは GPU 対応の幅広いワークロードを高速化しますが、中でも、強化学習 (RL) と蒸留を用いた 基盤モデル (FM) の大規模な分散 AI トレーニングおよび推論、マルチモーダルトレーニングおよび推論のほか、気候モデリング、創薬、地震分析、保険リスクモデリングなどの HPC アプリケーションにも適しています。 Elastic Fabric Adapter (EFAv4) ネットワーキング、 EC2 UltraClusters を用いたハイパースケールクラスターリング、 AWS Nitro System を用いた高度な仮想化およびセキュリティ機能と組み合わせることで、速度、スケール、セキュリティを強化しつつ、FM のトレーニングとサービス提供を実現しています。さらに、これらのインスタンスは、 EC2 P5en インスタンス と比較して、AI トレーニング (トレーニング時間) と推論 (トークン/秒) のパフォーマンスが最大 2 倍向上しています。 FM トレーニングの市場投入までの時間を短縮しながら、推論スループットを高速化できます。これにより、推論コストを削減し、生成 AI アプリケーションの採用を促進できるだけでなく、HPC アプリケーションの処理性能も向上します。 EC2 P6-B200 インスタンスの仕様 新しい EC2 P6-B200 インスタンスには、1440 GB の高帯域幅 GPU メモリを搭載した 8 機の NVIDIA B200 GPU、第 5 世代インテル Xeon スケーラブルプロセッサ (Emerald Rapids)、2 TiB のシステムメモリ、30 TB のローカル NVMe ストレージが搭載されています。 EC2 P6-B200 インスタンスの仕様は次のとおりです。 インスタンスサイズ GPU (NVIDIA B200) GPU メモリ (GB) vCPU GPU ピアツーピア (GB/秒) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) P6-b200.48xlarge 8 1440 HBM3e 192 1800 8 x 3.84 NVMe SSD 8 x 400 100 これらのインスタンスは、P5en インスタンスと比較して GPU TFLOP が最大 125% 向上、GPU メモリサイズが 27% 増加、GPU メモリ帯域幅が 60% 増加しています。 稼働中の P6-B200 インスタンス 米国西部 (オレゴン) AWS リージョン では、 ML 用 EC2 キャパシティブロック を介して、P6-B200 インスタンスを利用できます。EC2 キャパシティブロックを予約するには、 Amazon EC2 コンソール で、 [キャパシティ予約] を選択します。 [ML 用キャパシティブロックを購入] を選択してから合計容量を選択し、 p6-b200.48xlarge インスタンス用の EC2 キャパシティブロックが必要な期間を指定します。EC2 キャパシティブロックを予約できる合計日数は、1 ～ 14 日間、21 日間、28 日間、または 7 日単位で、最長 182 日までです。利用開始日は、最大で 8 週間先まで選択可能です。 これで、EC2 キャパシティブロックが正常にスケジュールされます。EC2 キャパシティブロックの合計料金は前払いで請求され、購入後に料金が変更されることはありません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。詳細については、Amazon EC2 ユーザーガイドの「 Capacity Blocks for ML 」を参照してください。 P6-B200 インスタンスの起動時には、 AWS Deep Learning AMI (DLAMI) を使用して EC2 P6-B200 インスタンスをサポートできます。DLAMI は、事前設定された環境でスケーラブルで安全な分散型 ML アプリケーションをすばやく構築するためのインフラストラクチャとツールを ML の専門家や研究者に提供します。 インスタンスの起動には、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用できます。 EC2 P6-B200 インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon FSx for Lustre などの各種 AWS マネージドサービスとシームレスに統合できます。 Amazon SageMaker HyperPod にも間もなく対応予定です。 今すぐご利用いただけます Amazon EC2 P6-B200 インスタンスは、現在、米国西部 (オレゴン) リージョンで利用可能で、 ML 用 EC2 キャパシティブロックとして購入できます 。 Amazon EC2 コンソール で Amazon EC2 P6-B200 インスタンスをお試しください。詳細については、 Amazon EC2 P6 インスタンスのページ をご確認ください。ご意見やご要望がありましたら、 EC2 の AWS re:Post 、または通常の AWS サポート窓口までお寄せください。 – Channy 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

2025 年 4 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Managed Workflows for Apache Airflow (MWAA) Amazon Managed Workflows for Apache Airflow (MWAA) は、オープンソースの Apache Airflow のマネージドサービスで、ワークフローと呼ばれる一連のタスクを Python で作成し、実行、監視、スケジュールできます。本セミナーでは、MWAA の概要や他のサービスとの使い分けについて、デモを交えながらご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 MWAA に関心がある、またはご利用予定の方 AWS でワークフローを作成したいが、どのサービスを使うか検討中の方 既存の Airflow を利用していて、MWAA に移行予定の方 本 BlackBelt で学習できること Airflow, MWAA のサービス概要と機能を学習できます。 MWAA を使ってワークフローを実行するまでに実施する内容が分かります。 MWAA と 他のサービス (Step Functions など) の特徴が分かります。 スピーカー 佐藤 悠 プロフェッショナルサービス Savings Plans Savings Plans は、1 年または 3 年の期間で特定の使用量を契約するかわりに、オンデマンド料金と比較して低料金を実現する柔軟な料金モデルです。本セッションでは、Savings Plans の概要、購入方法および購入計画などについて説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Savings Plans の概要や購入方法を知りたい方 Savings Plans のコミットメントに迷っている方 コンピューティングワークロードのコスト最適化を促進したい方 本 BlackBelt で学習できること Savings Plans の概要・購入方法について学んでいただけます コミットメントを決める購入計画や購入後のモニタリングについても紹介します スピーカー 加須屋 悠己 テクニカルアカウントマネージャー AWS Database Migration Service ベストプラクティス – 計画編 AWS Database Migration Service は、オンプレミスから AWS へのデータベース移行や異なるエンジン間でのデータ連携など、データベース間でのデータ移行に役立つデータベースサービスです。難易度の高いデータ移行が容易に移行できるようになることから、多くのお客様のデータ移行で採用頂いています。本セミナーでは、データベース移行を計画する上で知っておきたいノウハウやベストプラクティスについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これからデータベースの移行を予定されている方 データベース間のデータ連携を検討している方 AWS Database Migration Service を用いた DB 移行やレプリケーションについてさらに深く学びたい方 本 BlackBelt で学習できること 移行計画を立てる際に事前に確認しておくべきポイント テスト移行の重要性と進め方 DMS の各機能の活用と使い分け DMS における移行完了判定の手法 スピーカー 菅原 照太 クラウドサポートエンジニア AWS Backup で考える DR 戦略 #1 基本編 AWS Backup は、AWS サービス全体のデータのバックアップを一元的にオーケストレーションし、自動化できるフルマネージドサービスです。Disaster Recovery (DR) というユースケースに対して AWS Backup がどのように活用できるかという点を機能とともにご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 DR 戦略において AWS Backup がどのように活用できるか知りたい方 AWS Backup の概要を知りたい方 AWS Backup を用いたバックアップ方法を学びたい方 本 BlackBelt で学習できること AWS 上での DR 戦略の概要 AWS Backup の概要 AWS Backup でのバックアップ取得方法 スピーカー 小島 七海 クラウドサポートエンジニア Amazon Connect 最新・重要アップデート ( 2024 年 1 月 〜 2025 年 3 月 ) Amazon Connect が東京リージョンでローンチされてから 6 年が経ちたくさんの新機能が追加されてきました。この動画では 2024 年 1 月から 2025 年 3 月までに発表された、Amazon Connect のアップデートの中から、特に重要なアップデートについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect ご利用中のお客様、パートナーの方 Amazon Connect のご利用をご検討中の方 Amazon Connect のアップデートを知りたい方 本 BlackBelt で学習できること 2024 年 1 月から 2025 年 3 月までに発表された、Amazon Connect のアップデートの中から、特に重要なアップデートについてキャッチアップすることができます。 スピーカー 濱上 和也 ソリューションアーキテクト Amazon Chime SDK WebRTC Media 編 音声や動画によるリアルタイムコミュニケーション機能を組み込んだアプリケーションの開発を検討されている方や、既存のアプリケーションの拡張や運用などで課題感をお持ちの方に対して、Amazon Chime SDK を使用して、リアルタイムコミュニケーション機能をアプリケーションに実装する方法について、特に WebRTC Media 機能を中心にご説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS についての深い知識や経験はなくても Amazon Chime SDK は利用可能ですが、一方で、クライアントサイドおよびサーバーサイドのアプリケーション開発に関する広範な知識は前提知識として必要になります。 本 BlackBelt で学習できること インテリジェントなリアルタイム通信機能をアプリケーションに組み込むためのソリューションである Amazon Chime SDK について、WebRTC Media 機能を中心にご紹介します。WebRTC Media 機能を利用することで高品質な音声・映像通話、画面共有機能などの機能を簡単にアプリケーションに組み込むことが可能になります。 スピーカー 石井　悠太 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-06 Amazon Timestream 基本編 ソリューションアーキテクト 小林 新一

はじめに 2024/12/13 に待望の Direct Connect 大阪第2ロケーション 「KDDI TELEHOUSE OSAKA2(以下:OSAKA2)」の開設を 発表 しました。日本全体では 5番目、大阪では Equinix OS1(以下:OS1) に続き２番目のロケーションです。これまでは関西以西の国内 DX ロケーション は OS1 しかなく、ロケーション 冗長を取るには、東京にあるロケーション をバックアップルートに選択する必要があり大阪リージョンにワークロードをデプロイしようとしても 東阪間の往復を許容する必要がありました。今回のアップデートにより関西地域に閉じたロケーション冗長を行うことが可能になり、AWS クラウドの大阪リージョンをメインリージョンとしたワークロードおよびハイブリッドネットワークをより最適化することができます。 本イベントでは、この２つのロケーションを用いた冗長アーキテクチャについてご説明をしました。また、ロケーションを提供いただいた KDDI株式会社 様に加え、OSAKA2 へのコネクティビティを提供いただいている 株式会社TOKAI コミュニケーションズ様、株式会社JPIX様にもご登壇いただき、すぐに OSAKA2 を利用したいお客様のニーズに応える内容となっています。 電力、鉄道など関西を事業基盤とされているお客様や、数多くのお客様のシステムを AWS 上に構築いただいている AWS パートナー 様が中心となり、49名の方に参加いただきました。CSAT は 4.67/5(39名からの回答) と非常に満足度が高いイベントとなりました。 アジェンダ 本イベントでは、AWS セッション、パートナー様セッション、デモとバライティに富んだ内容となっております。 タイトル スピーカー 資料 1 Opening & Keynote AWS Shakeel Ahmad Download 2 AWS Direct Connect 大阪第2ロケーション Launch Overview AWS 櫻井俊和 Download 3 Service Introduction by Direct Connect Partners 3.1 AWS Direct Connect サービス KDDI Telehouse 大阪2 開設について KDDI株式会社 森島隆政様、菅原凛太様 (非公開) 3.2 AWS Direct Connect ⼤阪第２ロケーション開設におけるTOKAICOMのご紹介 株式会社TOKAI コミュニケーションズ 鈴木賢様、斎藤貴様 Download 3.3 AWS Direct Connect Telehouse OSAKA2への接続について 株式会社 JPIX 飯塚友久様 Download 4 Routing Topology デモ AWS 丁亜峰、奥村洋介 (非公開) 5 Networking ( 懇親会 ) Opening & Keynote オープニングスピーカーは APJ のスペシャリストチームをリードしている Shakeel から AWS のグローバルインフラストラクチャとダイレクトコネクトについてお話ししました。会場では逐次通訳にて日本語でもお届けしています。 ( Download ) Shakeel Ahmad – Specialist SA Leader, APJ AWS Direct Connect 大阪第2ロケーション Launch Overview 本セッションでは、 AWS Direct Connect の回復性に関する推奨事項 で本番環境のワークロードにはマルチサイト(ロケーション)でのデプロイを推奨していること、OS1/OSAKA2 の冗長構成を組むことで推奨構成を満たしつつ大阪リージョンへ低レイテンシーの接続が期待できることをご説明しました。注意事項として、OS1/OSAKA2 ロケーションは Associated AWS Region が OS1 は東京リージョンに、OSAKA2 は大阪リージョンに設定されています。異なるリージョンに関連付けられていることで、ルーティングを制御するための設定には注意が必要です。ネットワークスペシャリスト SA の奥村さんが投稿されたテックブログ「 AWS Direct Connect のトラフィックコントロールと大阪リージョンとの接続 」にて詳しく説明されています。ご確認ください。 ( Download ) 櫻井 俊和 – Sr. Solutions Architect Service Introduction by Direct Connect Partners ここからはイベントのメインセッションとなります。パートナー様よりOSAKA2 コネクティビティサービスの提供情報についてお話いただきました。 AWS Direct Connect サービス KDDI Telehouse 大阪2 開設について パートナー様セッションのオープニングは ロケーションを提供いただている 株式会社 KDDI 様にご登壇いただきました。はじめにグループ戦略本部 テレハウス企画部 森島様よりKDDI のデータセンターの取り組み、AWSとKDDI の連携について、Telehouse 大阪2について、AWS Direct Connect 接続パターンについてお話しいただきました。具体的な契約手続きについてもふれていただきました。Part 2 として プロダクト本部 ネットワークサービス企画部 菅原様より WVS2 マルチクラウドゲートウェイ の概要と、Telehouse 大阪2開設にむけた将来像についてお話しいただきました。 KDDI株式会社　森島 隆政 様 AWS Direct Connect ⼤阪第２ロケーション開設におけるTOKAICOMのご紹介 続いて、株式会社TOKAI コミュニケーションズ 法人営業部 ⻄⽇本事業部 鈴木様にご登壇いただきました。TOKAI コミュニケーションズ様は国内 14番目のプレミアパートナー (2025/04現在、国内15社)として企業様の AWS 導入をご支援いただいています。すでに閉域網サービス「 BroadLine 」からの AWS 接続サービスを展開されています。2025/04 には 「BroadLine」を九州エリアまで延伸され、多くの西日本エリアのお客様へ提供が可能となりました。後半には 法人営業部 技術開発事業部 齋藤 様にご登壇いただき、 BroadLine と AWS 接続サービスを使用して、OS1、OSAKA2、AT Tokyo CC1 とのレイテンシー比較のテスト結果を発表いただきました。OSAKA2 を経由したの大阪リージョン、東京リージョンとのレイテンシーは、OS1 と同等で安定しており、OS1をご利用のお客様がOSAKA2へ拡張した場合でもこれまでと同等のネットワーク品質が期待されます(計測データは当日のみ、資料非公開)。 ( Download ) 株式会社 TOKAIコミュニケーションズ　鈴木 賢 様 株式会社 TOKAIコミュニケーションズ　齋藤 貴 様 AWS Direct Connect Telehouse OSAKA2への接続について パートナー様セッションの最後として 株式会社JPIX コネクティビティ部 飯塚様にご登壇いただきました。Telehouse OSAKA2 は大阪ビジネスパーク(OBP) に立地しています。 OBP コネクトサービス を利用することで、OSAKA2 に芯線接続が可能となります。利用者は JPIX 様が提供するファイバー網を利用するか、OBPコネクトサービスと連携している 大阪なにわリング に接続することで、OSAKA2 へ接続することが可能です。大阪なにわリングは JR 西日本光ネットワーク様及びBBバックボーン様が光ファイバーを提供しており、提供エリアは大阪市内の主要データセンターから JR 西日本営業管轄エリアに広がります。JPIX様は インターネットエクスチェンジを提供する事業者様ですが、IX ポートサービスで提供される L2 ポートから Telehouse OSAKA2 まで延伸し、構内配線にて AWS Direct Connect への接続が可能な付加サービスとして提供されています。 ( Download ) 株式会社JPIX　飯塚 友久 様 Routing Topology デモ 最後に AWS SAs(丁/奥村) から OS1/OSAKA2 を冗長構成とした経路制御のデモを実施しました。オンプレミス模擬のルータに BGP commuity を設定して、AWS → オンプレミス向きの経路を OS1 を優先するよう変更し、Traceroute コマンドにて確認しました。検証用の回線は TOKAI コミュニケーションズ様より提供いただきました。ありがとうございました。 (左)　丁亜峰 – Solutions Architect　　　　　　　　　　 (右)　奥村洋介 – Network Specialist Solutions Architect おわりに Direct Connect 大阪第2ロケーション(OSAKA2)の登場により、関西以西の国内拠点からは、OS1/OSAKA2 に接続することで関西地域に閉じたロケーション冗長を行うことが可能になりました。２つのロケーションと大阪リージョンを活用することで、ミッションクリティカルなワークロード、低レイテンシーが求められるワークロードに対して要求を満たすことができます。また、これまでOS1 単独ロケーションで回線を冗長されていたお客様は OSAKA2 を利用することで可用性の向上が期待できます。ダイレクトコネクトロケーションまでのコネクティビティはご登壇いただいた皆様をはじめとしたパートナー様によるサービス提供によって成り立っています。本イベントにてOSAKA2 がパートナー様接続サービス含め利用可能な状態であることをお伝えいただきました。ご登壇いただきました KDDI株式会社様、株式会社TOKAI コミュニケーションズ様、株式会社JPIX様に重ねてお礼申し上げます。OSAKA2 のご利用にご興味がある方は、AWS担当営業へご相談ください。 著者: Sr. Solutions Architect　 櫻井 俊和

このブログは 2025 年 4 月 23 日に Margaret O’Toole、Alexis Bateman、Marta Fraga、Paula Csatlos によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 お客様の持続可能性への取り組みを支援するため、2022 年に AWS の請求とコスト管理コンソールに 顧客の二酸化炭素排出量ツール (CCFT) を導入しました。CCFT は、お客様の AWS 利用による炭素排出量を追跡、測定、確認できるツールです。CCFT は、温室効果ガスプロトコルで定義されているスコープ 1 とスコープ 2 の排出量を対象とし、Amazon EC2、Amazon S3、AWS Lambda など、AWS の製品全範囲をカバーしています。排出量はメトリックトン二酸化炭素換算 (MTCO2e) で提供されます。 本日、CCFT の継続的な改善プロセスの一環として、3 つの更新内容を公開します。 データアクセスの簡易化 ：請求とコスト管理 データエクスポートサービス を通じて、お客様の炭素排出量データへのアクセスを容易にします。 より詳細な炭素データ ：CCFT の粒度を高め、AWS リージョンを表示するようになります。 更新された独立検証済みの方法論 ：APEX 社による 検証 済みの更新された配分方法論 (v2.0) と付随する 方法論に関する文書 を公開しています。 これらの変更の結果、お客様は 2025 年 1 月以降の AWS 利用に関して、更新された方法論を反映した炭素排出量を確認できるようになり、一部のお客様は推定排出量の数値に変更が見られる可能性があります。業界の慣行に従い、2024 年 12 月以前の CCFT データは、従来の方法論 v1.0 を引き続き使用します。 CCFT 更新の詳細 1. データへのアクセスを容易に CCFT からのデータをより使いやすくするため、お客様は現在、AWS の請求とコスト管理データエクスポートサービスを通じて 2025 年 1 月のデータをエクスポートできるようになりました。お客様が AWS Organizations を使用している場合、炭素排出量データのエクスポートは、管理アカウントにリンクされているすべてのメンバーアカウントの炭素排出量推定値を提供します。データエクスポートサービスは、CSV または Parquet 形式で月次更新を自動的に Amazon S3 に配信し、お客様は AWS 組織全体で炭素データの処理を自動化できます。最初のエクスポートでは履歴分析を可能にするため、S3 バケットに最大 38 ヶ月分の履歴データが提供されます。2024 年 12 月以前のデータはバージョン 1.0 の方法論を使用して計算され、2025 年 1 月以降はバージョン 2.0 を使用します。データエクスポートの設定方法の詳細については、 データエクスポートユーザーガイド をご参照ください。 2. AWS リージョン別の詳細度 お客様は現在、AWS リージョン（例：米国東部（オハイオ））ごとに炭素排出量の内訳を確認でき、Amazon CloudFront CDN の使用量も別途表示されます（単一のグローバルサービスカテゴリとして表示）。これにより、お客様は AWS 上のワークロードのリージョン分布を再評価する際に、カーボンフットプリントに最も寄与しているリージョンを特定できます。 3. 更新された v2.0 の方法論 お客様は多くの場合、複数のリージョンにまたがって幅広い AWS サービスを使用しており、その結果、ワークロードに基づく炭素排出量の追跡と配分が課題となっています。クラウド使用に関するお客様への炭素排出量の配分について業界標準は存在しませんが、v2.0 の方法論の更新では、CCFT をサポートするために既存の基準を活用しました。これには以下が含まれます： GHG プロトコルコーポレートスタンダード 、 GHG プロトコルプロダクトスタンダード 、 ISO 14040 / 44 (LCA) 、 ISO 14067 （製品のカーボンフットプリント）、 ICT セクターガイダンス 。 お客様は 方法論に関する文書 で詳細を確認できますが、以下にアプローチの概要を示します： スコープ 1 排出量 (直接) の概要 v2.0 版 スコープ 1 には、AWS が所有または管理する発生源からの直接排出が含まれます。例えば、データセンターのバックアップ発電機での燃料燃焼などです。AWS は、Amazon の年次保証プロセスの結果として、前年のスコープ 1 活動データを翌暦年の第 1 四半期に受け取ります。その後、サイトレベルの粒度で推定炭素データを計算し、クラスターレベルに集計します。AWS クラスターは、AWS リージョン（例：us-east-1、eu-central-1）または AWS CloudFront Edge Cluster（例：北米の CloudFront、南米の CloudFront）となります。 スコープ 2 排出量 (間接) の概要 v2.0 版 スコープ 2 には、購入電力からの間接排出が含まれ、CCFT ではマーケットベース方式を採用しています。例えば、グリッドミックス（グリッドからのカーボンフリーエネルギーの割合）や排出係数 (kgCO2e/kWh) は毎年更新され、Amazon のカーボンフットプリント保証の一環として検証されます。スコープ 2 について、CCFT はロケーションに基づく排出係数を使用し、温室効果ガスプロトコルが推奨する排出係数の階層に従っています。 v2.0 の配分概要 このモデルでは、まず AWS クラスターレベルでサーバーラックに排出量を配分し、次にリソース消費量に基づいて特定の AWS サービスにそれらの排出量をマッピングします。このモデルは、専用ハードウェアを持つ基盤サービス（例：Amazon EC2）とその基盤の上に構築された非基盤サービス（例：AWS Lambda）間の依存関係を考慮します。最後に、これらのサービスを利用する各お客様アカウントに排出量が割り当てられます。 モデルは以下のように機能します。 クラスターレベルの推定排出量をクラスター内のサーバーラックに配分します。 サーバーラックのリソース使用率に基づき、相互依存関係を考慮しながら、サーバーラックに関連する推定炭素排出量を AWS クラウドサービスに配分します。 各クラウドサービスに関連する推定炭素排出量を個々のお客様アカウントに配分します。 CCFT の方法論が更新されたことにより、一部のお客様は推定排出量が変更される場合があります。これは、バージョン 2.0 がカーボン排出量をより正確にお客様ごとに割り当てられるようになり、実際の AWS サービス利用状況をより的確に反映できるようになったためです。 方法論 v2.0 における 3 つの主要な更新内容： 現在、未使用のキャパシティをすべての AWS カスタマーに配分しています。AWS は、すべてのお客様のニーズに効果的に対応できるよう、十分なサーバーラックを提供しています。これにより、時として未使用のキャパシティが発生します。この未使用のキャパシティに関連する推定炭素排出量は、現在 AWS サービスを利用するすべてのお客様に比例配分されています。これは、GHG プロトコル、プロダクトレベルの炭素報告に関連する ISO 規格 (ISO 14040/14044)、およびクラウドとデータセンターサービス業界のセクターガイダンスにおいて、お客様に製品 / サービスを提供するために必要なすべての余剰リソースと非効率性を含めることが要求されているためです。 AWS Lambda や Amazon Redshift など、専用ハードウェアを持たない AWS サービスからの推定排出量を AWS のお客様と Amazon チーム間で配分するロジックを改善しています。 ネットワークラックや AWS カスタマー向けの新規リージョン立ち上げに関連する推定炭素排出量など、データセンター運営に関連するオーバーヘッドの配分を更新しています。 お客様のニーズを起点に、私たちは引き続きツールの改善を進めてまいります。お客様は、 方法論に関する文書 、 CCFT ユーザーガイド 、および データエクスポートユーザーガイド をご覧いただくことで、これらの更新について詳しく知ることができます。 今後も、進化するデータや気候科学などに基づいて方法論の更新情報を発信し続けるとともに、お客様の持続可能性への取り組みを支援する機能の開発に継続的に投資していきます。 The Climate Pledge への誓約 The Climate Pledge (2040 年までにカーボンニュートラルを達成するという Amazon のコミットメント) や、AWS を含む事業全体における持続可能性への投資についての詳細は、 ここ の当社のサステナビリティサイトをご覧ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 Margaret O’Toole Margaret O’Toole は、AWS のワールドワイド・テックリーダー (サステナビリティ担当) です。彼女の役割は、お客様が自社の持続可能性目標を達成するために AWS を活用できるよう支援することです。2017年 から AWS に在籍しており、それ以前はバージニア大学でコンピュータサイエンスと生物学を学びました。 Alexis Bateman Alexis Bateman は、Amazon Web Services (AWS) のサステナビリティ・テック部門の責任者です。この役職で、AWS とそのお客様、そしてパートナーがより持続可能な未来に向けて前進できるようにするためのデータ製品、ツール、意思決定支援機能の開発を担当するチームを率いています。Bateman は 2021年 にアマゾンに入社し、サステナビリティ研究とテクノロジー開発において 10 年以上の経験を持っています。AWS 入社以前は、MIT の輸送・物流センターで 10 年間、研究員およびサステナブルサプライチェーンラボのディレクターを務めました。Bateman は、カリフォルニア大学アーバイン校で環境計画・政策・デザインの博士号を取得し、また環境計画の修士号も保持しています。 Marta Fraga Marta Fraga は、AWS サステナビリティにおけるカスタマーカーボンフットプリントツール（CCFT）のプロダクトリーダーです。この役割において、彼女は AWS のお客様がサステナビリティ目標を達成するために必要なサステナビリティ製品とツールのビジョンを設定しています。Marta は 2011 年からアマゾンに在籍しており、ウェールズ大学で経営学の学士号を取得しています。 Paula Csatlos Paula Csatlos は、AWS サステナビリティ部門のシニアプロダクトマネージャー (テクニカル) として、お客様の気候目標達成を可能にする技術製品の開発を主導しています。B2B および B2C 製品の構築とスケーリングにおいて 10 年の経験を持ち、機械学習、生成 AI、カスタマーエクスペリエンスデザイン、プロセス自動化に関する深い専門知識を有しています。

AWS での新しい リージョンとアベイラビリティーゾーン の立ち上げの迅速さには、いつも感動しています。現在、36 のリージョンと 114 のアベイラビリティーゾーンがリリースされています。これは素晴らしいことです! 5 月 5 日週の AWS でのニュースは、グローバルインフラストラクチャの大幅な拡張です。南米向けの新しいリージョンの発表により、お客様にとって、低レイテンシーとデータレジデンシーの要件を満たすための選択肢が増えます。拡張と並行して、AWS はより多くのリージョンで多数のインスタンスタイプを利用できるようになったことを発表しました。 インフラストラクチャの拡張に加えて、AWS は Amazon Q Developer の対象範囲を Amazon OpenSearch Service にも拡大しています。 5 月 5 日週のリリース Amazon OpenSearch Service での Amazon Q Developer の使用 – Amazon Q Developer が Amazon OpenSearch Service と統合されました。これにより、開発者は関連するコードの提案やトラブルシューティングガイダンスを使用して検索アプリケーションを迅速に構築するのに役立つ、AI を活用した支援を受けることができます。 構築中 – AWS 南米 (チリ) リージョン – AWS は、南米 (チリ) リージョンの新設計画を発表しました。この計画では、グローバルインフラストラクチャを拡張して、地域のお客様に低レイテンシーおよび強化されたデータレジデンシーの選択肢を提供できるようになります。 AWS Zero Trust Accelerator for Government のご紹介 – 新しい AWS Zero Trust Accelerator for Government は、公共部門の組織がコンプライアンス要件に特化したツールとガイダンスを使用して、ゼロトラストセキュリティアーキテクチャをより効率的に実装するのに役立ちます。 Amazon EBS スナップショットから新しい EBS ボリュームへのデータ転送の高速化 – AWS は、Amazon EBS Provisioned Rate for Volume Initialization の一般提供を発表しました。これは、ユーザーが EBS スナップショットから新しい EBS ボリュームへのデータ転送を 100 MiB/秒〜300 MiB/秒の範囲の指定されたレートで高速化できる新機能です。 インスタンスに関する発表 AWS は、さまざまなインスタンスタイプのインスタンス可用性を、さらに多くのリージョンに拡大しました。 Amazon EC2 C8gd、M8gd、R8gd インスタンスが AWS リージョン欧州 (フランクフルト) で利用可能に – Amazon EC2 C8gd、M8gd、R8gd インスタンスが AWS 欧州 (フランクフルト) リージョンで利用できるようになりました。これにより、ローカル NVMe ベースの SSD ストレージを使用した Graviton 搭載のコンピューティングインスタンスが、より多くのお客様に提供されるようになりました。 Amazon EC2 R7g インスタンスがさらに多くの AWS リージョンで利用可能に – AWS Graviton3 プロセッサを搭載した Amazon EC2 R7g メモリ最適化インスタンスが、さらに多くの AWS リージョンで利用できるようになり、メモリを大量に消費するワークロードのデプロイオプションが広がりました。 Amazon EC2 R7g インスタンスが AWS GovCloud (米国東部) で利用可能に – Amazon EC2 R7g インスタンスは AWS GovCloud (米国東部) で利用できるようになりました。これにより、政府や規制対象のワークロードに、高性能のメモリ最適化コンピューティングの選択肢がもたらされます。 Amazon EC2 X2idn インスタンスが AWS イスラエル (テルアビブ) リージョンで利用可能に – Intel Xeon Scalable プロセッサを搭載した Amazon EC2 X2idn メモリ最適化インスタンスが、AWS イスラエル (テルアビブ) リージョンで利用できるようになりました。これにより、インメモリデータベースとハイパフォーマンスコンピューティングのワークロードがサポートされます。 Amazon EC2 P5en インスタンスが AWS 米国西部 (北カリフォルニア) リージョンで利用可能に – 高性能機械学習トレーニングと生成 AI 推論用に設計された Amazon EC2 P5en インスタンスが、AWS 米国西部 (北カリフォルニア) リージョンで利用できるようになりました。 その他のアップデート AWS Systems Manager にオンボーディング設定のカスタマイズオプションを追加 – AWS Systems Manager では、オンボーディング設定のカスタマイズオプションが拡張され、管理者がより柔軟にリソースを設定および管理できるようになりました。 Amazon MSK により MSK プロビジョニングクラスターでのシームレスな証明書更新が可能に – Amazon MSK では、MSK プロビジョニングクラスターでのシームレスな証明書更新が可能になり、Apache Kafka 環境のセキュリティ管理が簡素化されます。 AWS Resource Explorer が 41 種類の新しいリソースタイプをサポート – AWS Resource Explorer は 41 種類の新しいリソースタイプをサポートするように拡張され、アカウント全体でより多くの AWS リソースを簡単に見つけて視覚化できるようになりました。 Amazon Managed Service for Prometheus が AWS カナダ (中部) リージョンで利用可能に – Amazon Managed Service for Prometheus が AWS カナダ (中部) リージョンで利用できるようになり、北米のより多くのお客様にコンテナモニタリング機能を提供できるようになりました。 AWS End User Messaging がメキシコ (中部) で利用可能に – AWS End User Messaging がメキシコ (中部) で利用できるようになりました。これにより、企業は地理的地域の顧客に SMS、音声、E メールメッセージを送信できます。 Amazon WorkSpaces が AWS 欧州 (パリ) リージョンで利用可能に – AWS のマネージドデスクトップ仮想化サービスである Amazon WorkSpaces が AWS 欧州 (パリ) リージョンで利用できるようになり、欧州のお客様における仮想デスクトップインフラストラクチャの選択肢が広がりました。 今後のイベント AWS Summit シーズン の真っ只中です! AWS Summit は夏の間、世界中の都市で開催されます。カレンダーをチェックして、お近くで AWS Summit が開催される日をご確認ください。2025 年 5 月の残りの Summit は次のとおりです。 韓国、ソウル – 5 月 14 日〜15 日 アラブ首長国連邦、ドバイ – 2025 年 5 月 21 日 イスラエル、テルアビブ – 2025 年 5 月 28 日 シンガポール – 2025 年 5 月 29 日 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

このブログは、テクニカルアカウントマネージャーの Zakiya Randall が執筆し、シニアスペシャリストソリューションアーキテクトの Muru Bhaskaran と共同で書かれました。 はじめに コンピューティング環境が進化するにつれ、さまざまなコンピューティングアーキテクチャをサポートすることが求められるようになっています。 こうした動きは、多様なハードウェアプラットフォームにおける柔軟性、効率性、パフォーマンス最適化のニーズから生まれています。 その結果、開発者や組織にとって、複数のアーキテクチャ (マルチアーキテクチャ) に対応したコンテナイメージを構築することが、ますます重要になっています。 AWS CodeBuild は、フルマネージド型の継続的インテグレーションサービスで、現在マネージド GitHub Actions ランナーを サポートしています 。これは、GitHub Actions ワークフローのジョブイベントを受信するように CodeBuild プロジェクトを設定できる、GitHub Actions の セルフホステッドランナー です。この記事では、 GitHub 、GitHub Actions ワークフロー、および CodeBuild を使用して、AWS 上で x86 用と AWS Graviton ベースのコンピューティング環境用の両方のネイティブコンテナイメージをビルドするソリューションをご紹介します。GitHub Actions ワークフローが完了すると、マルチアーキテクチャイメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュします。 ソリューションの概要 構成図は、GitHub リポジトリへ変更をコミットした際のワークフローを示しており、その後コンテナイメージを Amazon ECR にプッシュするまでの手順を詳しく説明しています。 図 1: ソリューションの構成図 GitHub リポジトリへ変更をコミットすると、ワークフローがトリガーされます 両方のアーキテクチャ用の CodeBuild ランナーが起動され、コンテナイメージのビルドを開始します コードが GitHub リポジトリからチェックアウトされます AWS アカウントへのアクセスに必要な認証情報が設定されます Amazon ECR にログインするためにロールが使用されます 両方のアーキテクチャのイメージリストを使って、マルチアーキテクチャイメージがビルドされます 前提条件 このソリューションを実施するには、以下の前提条件が必要です: AWS アカウント Amazon Command Line Interface (AWS CLI) GitHub リポジトリ 手順解説 以降の手順で、このソリューションの概要を説明します。 GitHub リポジトリファイルの作成 ソリューションを開始するには、Dockerfile、index.html ファイル、GitHub Actions ワークフロー YAML ファイルを格納する GitHub リポジトリが必要です。手順については、GitHub の 新しいリポジトリの作成 を参照してください。この例では、次の 2 つのファイルを GitHub リポジトリのルートにコミットします。 index.html ファイル <!DOCTYPE html> <html> <body> <h1>Containers</h1> <p>You can run containers!</p> </body> </html> コンテナイメージをビルドするための Dockerfile FROM public.ecr.aws/nginx/nginx COPY index.html /usr/share/nginx/html/index.html EXPOSE 8080 CMD ["nginx", "-g", "daemon off;"] x86 および arm64 アーキテクチャ用の 2 つの CodeBuild プロジェクトの作成 GitHub Actions ジョブを実行するには、2 つの CodeBuild プロジェクトを作成する必要があります。CodeBuild プロジェクトは、 <project-name> -x86 と <project-name> -arm64 という命名規則に従ってください。 x86 と arm64 の環境用に 2 つの CodeBuild プロジェクトを設定する方法については、 このチュートリアル を参照してください。 GitHub リポジトリに接続するには、OAuth アプリ認証方式を使用する必要があります。 x86 と arm64 の CodeBuild プロジェクトでは、それぞれのアーキテクチャに対応した環境イメージを選択してください。また、 Buildspec のビルド仕様は無視されます。 代わりに、コンピューティングランナーをセットアップするコマンドに CodeBuild が上書きします。 図 2: x86 と arm64 用の CodeBuild プロジェクト Amazon ECR リポジトリの作成 x86 と arm64 のコンテナイメージを格納するために、Amazon ECR リポジトリを作成する必要もあります。次の AWS CLI コマンドを実行して、Amazon ECR リポジトリを作成してください。 aws ecr create-repository \     --repository-name <repository-name> Amazon ECR リポジトリを作成した後、CodeBuild の実行環境が Amazon ECR リポジトリにアクセスしてイメージをプッシュできるように、IAM ロールを作成する必要があります。 次のロールにより、Amazon ECR リポジトリに対してコンテナイメージをプッシュできるようになります。 1. IAM コンソール に移動し、以下の権限を持つポリシーを作成します。ポリシー内の AllowPushPull ステートメントの Resource セクションでは、利用する AWS リージョン 、アカウント番号、リポジトリ名を含む Amazon ECR プライベートリポジトリの Amazon リソースネーム (ARN) に置き換えてください。このポリシーに名前を付け、 ポリシーの作成 を選択します。 {     "Version": "2012-10-17",     "Statement": [         {             "Sid": "AllowPushPull",             "Effect": "Allow",             "Action": [                 "ecr:BatchGetImage",                 "ecr:BatchCheckLayerAvailability",                 "ecr:CompleteLayerUpload",                 "ecr:GetDownloadUrlForLayer",                 "ecr:InitiateLayerUpload",                 "ecr:PutImage",                 "ecr:UploadLayerPart"             ],             "Resource": [                 "arn:aws:ecr:<aws-region>:<account-id>:repository/<repository-name>"             ]         },         {             "Sid": "AllowLogin",             "Effect": "Allow",             "Action": [                 "ecr:GetAuthorizationToken"             ],             "Resource": [                 "*"             ]         }     ] } ポリシーを作成した後、 AWS Identity and Access Management (IAM)  コンソールに移動して、Identity Provider を作成し、 OpenID Connect を選択します。プロバイダーの URL は https://token.actions.githubusercontent.com を選択します。対象者は sts.amazonaws.com を選択します。 2. プロバイダーを作成した後、ロールを作成し、 Web Identity を選択します。ドロップダウンボックスには、 https://token.actions.githubusercontent.com の プロバイダー URL が表示されるはずです。このオプションを選び、 対象者  に sts.amazonaws.com を指定します。 GitHub organization  では、あなたの GitHub Organization を指定し、上記で作成したリポジトリを追加します。 次へ を選択します。 図 3: ロール作成の例 3. 許可を追加 の項目で、ステップ 1 で作成したポリシーを選択し、Amazon ECR にイメージをプッシュできるようにします。 次へ を選択します。次の画面でロールに名前を付けて、 ロールを作成 を選択します。 図 4: ポリシーの許可を追加する例 4. GitHub リポジトリの Settings に移動し、左側ペインの Security の下にある Secrets and variables を選択します。Secrets and variables 内の Actions タブを選択します。 New repository secret を選択します。名前に AWS_ROLE_ARN と入力し、ステップ 3 で作成した AWS ロールの ARN を入力して、 Add secret を選択します。 図 5: AWS ロールの GitHub Actions シークレットを作成する例 5. AWS_REGION 用に別の 新しいリポジトリシークレット を作成します。リソースを作成したリージョンを指定し、 シークレットを追加 を選択します。 図 6: AWS リージョンの GitHub Actions シークレットの例 GitHub Actions ワークフローの準備 GitHub Actions ワークフローは、1 つ以上のジョブで構成された自動化プロセスであり、YAML ファイルでこれらのジョブを定義できます。GitHub リポジトリ内の .github/workflows ディレクトリに YAML ファイルを作成し、そこでソリューションのワークフローを定義します。今回、GitHub Actions ワークフローの YAML ファイルには、CodeBuild ランナー用のビルドジョブを指定します。ランナー環境は YAML ファイルの runs-on セクションで指定され、マルチアーキテクチャソリューション用に作成する各 CodeBuild プロジェクトを参照します。 container-image.yaml name: Docker on:   workflow_dispatch: {}   push:     branches: [ "main" ]     # Publish semver tags as releases.     tags: [ 'v*.*.*' ] env:   REGISTRY: xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com   IMAGE_NAME: myapp jobs:   build:     strategy:       matrix:         arch: [arm64, x86]     runs-on: codebuild-myapp-${{ matrix.arch }}-${{ github.run_id }}-${{ github.run_attempt }}     permissions:       contents: read       id-token: write     steps:       - name: Checkout repository         uses: actions/checkout@v4              - name: Configure AWS credentials         uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2         with:           role-to-assume: ${{ secrets.AWS_ROLE_ARN }}           aws-region: ${{ secrets.AWS_REGION }}                  - name: Login to Amazon ECR Private         if: github.event_name != 'pull_request'         id: login-to-ecr         uses: aws-actions/amazon-ecr-login@062b18b96a7aff071d4dc91bc00c4c1a7945b076 # v2.0.1         with:           registry-type: private       # Extract metadata (tags, labels) for Docker       # https://github.com/docker/metadata-action       - name: Extract Docker metadata         id: meta         uses: docker/metadata-action@8e5442c4ef9f78752691e2d8f8d19755c6f78e81 # v5.5.0         with:           images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}       # Build (and optionally) push Docker image (don't push on PR)       # https://github.com/docker/build-push-action       - name: Build and push Docker image         id: build-and-push         uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0 # v5.3.0         with:           context: .           push: ${{ github.event_name != 'pull_request' }}           tags: ${{ steps.meta.outputs.tags }}-${{ matrix.arch }}           labels: ${{ steps.meta.outputs.labels }}      manifest:     needs: build     runs-on: codebuild-myapp-x86-${{ github.run_id }}-${{ github.run_attempt }}     permissions:       contents: read       id-token: write     steps:       - name: Configure AWS credentials         uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2         with:           role-to-assume: ${{ secrets.AWS_ROLE_ARN }}           aws-region: ${{ secrets.AWS_REGION }}                  - name: Login to Amazon ECR Private         if: github.event_name != 'pull_request'         id: login-ecr         uses: aws-actions/amazon-ecr-login@062b18b96a7aff071d4dc91bc00c4c1a7945b076 # v2.0.1         with:           registry-type: private       # Extract metadata (tags, labels) for Docker       # https://github.com/docker/metadata-action       - name: Extract Docker metadata         id: meta         uses: docker/metadata-action@8e5442c4ef9f78752691e2d8f8d19755c6f78e81 # v5.5.0         with:           images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}       # Build and push image manifest (don't push on PR)       # https://github.com/Noelware/docker-manifest-action       - name: Build and push Docker manifest         id: build-and-push         uses: Noelware/docker-manifest-action@master # v0.3.0         with:           images: ${{ steps.meta.outputs.tags }}-arm64,${{ steps.meta.outputs.tags }}-x86           inputs: ${{ steps.meta.outputs.tags }}           push: ${{ github.event_name != 'pull_request' }} GitHub Actions ワークフロー構成ファイル内の env variables セクションでは、GitHub Actions ジョブがコンテナマニフェストとコンテナイメージをプッシュする先の Amazon ECR リポジトリを定義する必要があります。作成したリポジトリの名前を IMAGE_NAME という環境変数に設定します。 env:   REGISTRY: xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com   IMAGE_NAME: <repository-name> GitHub Actions ワークフローの YAML ファイルでは、ホストランナーがジョブを実行するために使用するアーキテクチャを決定するために、runs-on 値の両方の CodeBuild プロジェクトを定義する必要があります。ここでは、 matrix フィールドで arm64 と x86 の変数を定義しています。マトリックス内の arch  フィールドで定義された変数の組み合わせごとにジョブが実行されます。CodeBuild ランナーにジョブを選択してもらうには、ジョブ名に CodeBuild プロジェクト名を接頭辞として指定する必要があります。 構成ファイルの runs-on 値は次のように設定します。 runs-on: codebuild-<project-name>-${{ matrix.arch }}-${{ github.run_id }}-${{ github.run_attempt }} jobs:   build:     strategy:       matrix:         arch: [arm64, x86]     runs-on: codebuild-myapp-${{ matrix.arch }}-${{ github.run_id }}-${{ github.run_attempt }} GitHub Actions ワークフローの構成ファイルには、 AWS_ROLE_ARN と AWS_REGION の GitHub シークレット変数が定義されています。 AWS にアクセスするための資格情報として、GitHub はこれらのシークレット変数の値を使用します。 - name: Configure AWS credentials         uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2         with:           role-to-assume: ${{ secrets.AWS_ROLE_ARN }}           aws-region: ${{ secrets.AWS_REGION }} すべてのファイルを GitHub リポジトリにアップロードした後、リポジトリは次の画像のようになります。 Dockerfile と index.html ファイルはリポジトリのルートに配置され、container-image.yaml ファイルは GitHub Actions ワークフローを定義するために .github/workflows ディレクトリに配置されています。 図 7: GitHub リポジトリ内のファイル構造の例 .github/workflows フォルダ内に container-image.yaml ファイルが格納されています。 図 8: GitHub Actions ワークフロー YAML ファイルの例 ソリューションのテスト GitHub と AWS 内のすべてのリソースが作成されたので、ソリューションをテストしてみましょう。 GitHub リポジトリ内の index.html ファイルのメッセージを変更し、変更をメインブランチにコミットしてください。これにより、GitHub Actions ワークフローが起動します。 GitHub Actions ワークフローが起動すると、CodeBuild ランナーが構成ファイルで指定したジョブを実行し始めるはずです。 1. index.html ファイル内の、body のメッセージを変更してください。変更をコミットし、main ブランチにプッシュします。 2. リポジトリの上部パネルの Actions を選択してください。 Actions  を選択すると、次の図に示すように、両方のアーキテクチャのビルドプロセスで実行されているジョブの詳細ページが表示されます。 図 9: 両方のアーキテクチャでビルドジョブが開始されています 3. 各ビルドジョブ内で、両方のアーキテクチャに対してビルドプロセスが完了するまでのステップを見ることができます。ランナーがこのジョブを受け取るのを待っている旨が表示されています。 図 10: x86 環境のランナー 図 11: arm64 環境のランナー 4. AWS コンソールの CodeBuild に移動すると、各アーキテクチャ用の 2 つのビルドプロジェクトが進行中になっているはずです。 ビルドが完了するまでに数分かかる場合があります。 図 12: 両方のアーキテクチャ用の CodeBuild プロジェクト 5. GitHub repository の Actions ページに戻ると、x86 と arm64 の両方のアーキテクチャに対してビルドジョブが完了したことがわかります。 マニフェストジョブは、x86 と arm64 のコンテナイメージを含むマニフェストリストを作成しています。 図 13: GitHib Actions ページ内のビルド完了画面 6. Amazon ECR リポジトリにアクセスすると、マニフェストおよび x86 と arm64 向けのコンテナイメージが更新されていることがわかります。 図 14: ECR での完了したイメージビルド クリーンアップ この記事で説明したインフラストラクチャをすべて破棄することで、追加の費用は発生いたしません。GitHub のリソースをクリーンアップするには、この例で作成したリポジトリを削除してください。AWS のリソースをクリーンアップするには、次のコマンドで 2 つの CodeBuild プロジェクトを削除することができます。 aws codebuild delete-project –-name <project-name>-x86 aws codebuild delete-project –-name <project-name>-arm64 また、次のコマンドを使用して Amazon ECR リポジトリを削除できます。 aws ecr delete-repository \     --repository-name <repository-name> \          --force 結論 この投稿では、GitHub Actions と AWS CodeBuild を統合して、マルチアーキテクチャイメージをビルドする方法を紹介しました。また、これらのマルチアーキテクチャイメージを Amazon ECR に格納し、x86 または Amazon Elastic Compute Cloud (Amazon EC2) の AWS Graviton コンピューティングから取得できるようにする手順を説明しました。CodeBuild には専用の ウェブサイト があり、ランナーをデプロイする際に役立つ情報、チュートリアル、リソースが用意されています。Graviton コンピューティングの詳細を知りたい場合は、こちらの ウェブサイト を参照してください。 本記事は、 Building multi-arch containers with GitHub Actions in AWS (2025 年 3 月 14 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

Amazon Redshift Serverless は、ワークロードの需要に合わせて自動的に計算能力をスケーリングし、この能力を Redshift Processing Units (RPU) で測定します。従来のスケーリングはクエリキューの待ち時間に応じて行われていましたが、新しい AI 主導のスケーリングと最適化機能 は、クエリの複雑さやデータ量など複数の要因を考慮することで、より洗練されたアプローチを提供します。インテリジェントなスケーリングにより、パフォーマンスとコストのバランスを取ることができ、主要なデータウェアハウスの課題を解決できます。特に、日次パターンや月次サイクルに基づいてワークロードが変動する場合に有効です。 Amazon Redshift サーバーレスでは、ワークグループの構成をより柔軟に設定できるようになりました。ユーザーは、クエリ実行のベース RPU を指定してベース容量を設定するか、価格対パフォーマンスのターゲットを選択できます。RPU の範囲は 8 から 1024 で、各 RPU は 16GB のメモリを提供します。Amazon Redshift Serverless の AI 主導のスケーリングと最適化により、さまざまなワークロードの要件により適切に対応でき、インテリジェントにリソース管理を行い、クエリ実行中にリソースを自動的に調整し、最適なパフォーマンスを実現します。現在のワークロードが 32 から 512 ベース RPU を必要とする場合は、AI 主導のスケーリングと最適化を使用することをお勧めします。32 ベース RPU 未満または 512 ベース RPU を超えるワークロードでは、この機能の使用をお勧めしません。 この記事では、Amazon Redshift Serverless の AI 主導のスケーリングと最適化が、さまざまな最適化プロファイルにおいてパフォーマンスとコストにどのような影響を与えるかを示します。 AI 主導のスケーリングと最適化の選択肢 Amazon Redshift Serverless の AI による自動最適化では、直感的なスライダーインターフェースを提供し、価格とパフォーマンスのゴールをバランスさせることができます。次の図に示されるように、「コスト最適化」から「パフォーマンス最適化」までの 5 つの最適化プロファイルから選択できます 。スライダーの位置に合わせて、Amazon Redshift がリソース割り当てと AI による自動最適化の調整を行い、価格とパフォーマンスを望ましいバランスに保ちます。 スライダーには以下のオプションがあります: コスト最適化 (1) パフォーマンスよりもコスト削減を優先します コスト削減のため、最小限のリソースを割り当てます パフォーマンスが時間的に重要でないワークロードに最適です コストバランス (25) 適度なパフォーマンスを維持しつつ、コスト削減に重点を置きます 中程度のリソースを割り当てます クエリ時間に柔軟性がある混合ワークロードに適しています バランス (50) コスト効率とパフォーマンスに同等の重点を置きます ほとんどのユースケースに最適なリソースを割り当てます 汎用ワークロードに理想的です パフォーマンスバランス (75) ある程度のコスト管理を維持しつつ、パフォーマンスを優先します 必要に応じて追加のリソースを割り当てます 一貫して高速なクエリ経過時間を必要とするワークロードに適しています パフォーマンス最適化 (100) コストに関係なく、パフォーマンスを最大化します 利用可能な最大のリソースを提供します 最速のクエリ配信を必要とする時間的に重要なワークロードに最適です AI 主導のスケーリングと最適化を検討すべきワークロード Amazon Redshift Serverless の AI によるスケーリングと最適化機能は、ほとんどすべての分析ワークロードに適用できます。Amazon Redshift は、コスト、バランス、パフォーマンスのいずれかの価格と性能の目標に応じて、最適化を評価して適用します。 ほとんどの分析ワークロードは、数百万または数十億行のデータを処理し、集計や複雑な計算を行います。これらのワークロードはクエリパターンとクエリ数の変動が大きくなります。Amazon Redshift Serverless の AI 主導のスケーリングと最適化により、ワークロードのパターンを学習し、パフォーマンス重視の場合はパフォーマンス向上のためにリソースを多く割り当て、コスト重視の場合はリソースを少なく割り当てるため、価格、パフォーマンス、またはその両方が改善されます。 AI ドリブンのスケーリングと最適化のコスト効率性 Amazon Redshift Serverless の AI 主導のスケーリングと最適化の効果を適切に判断するためには、現在のコストパフォーマンスを測定できる必要があります。現在のコストパフォーマンスを測定するために、 sys_query_history を使用してワークロードの合計経過時間を計算し、開始時刻と終了時刻を確認することをお勧めします。次に、 sys_serverless_usage を使用してコストを計算します。 Amazon Redshift ドキュメント のクエリを使用し、同じ開始時刻と終了時刻を追加できます。これにより、現在のコストパフォーマンスが確立され、比較のための基準ができます。 ワークロードが継続的に実行されており、固定された開始時刻と終了時刻を決めるのが現実的でない場合、別の方法として、全体的に比較することもできます。前月比のコストをチェックしたり、パフォーマンス、システムの安定性、データ配信の改善、または前月比の全体的な処理時間の短縮に対するユーザーの評価をチェックすることができます。 ベンチマークの実施と結果 TPC-DS 3TB データセットを AWS Labs GitHub リポジトリ ( amazon-redshift-utils ) から評価し、最適化オプションを検証しました。このデータセットを、コスト最適化、バランス、パフォーマンス最適化に設定された 3 つの Amazon Redshift Serverless ワークグループに分けてデプロイしました。本格的なレポーティング環境を作成するため、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス 3 台に JMeter (エンドポイントごとに 1 台) を設定し、次のスクリーンショットに示すように、選択した 15 の TPC-DS クエリを約 1 時間同時に実行しました。 結果キャッシュを無効化 して、Amazon Redshift Serverless がすべてのクエリを直接実行し、正確な測定値を提供するようにしました。この設定により、各最適化プロファイルにおける本物のパフォーマンス特性を把握できました。また、Amazon Redshift Serverless ワークグループの 最大容量 パラメータを設定しない環境でテストを行いました。このパラメータは、データウェアハウスで利用可能な最大 RPU を制御する重要な設定です。この制限を外すことで、さまざまな設定がテストエンドポイントのスケーリング動作にどのように影響するかを明確に示すことができました。 包括的なテスト計画では、15 個の各クエリを 355 回実行し、テストサイクルごと 5,325 クエリを生成しました。AI 主導のスケーリングと最適化を行うには複数の反復が必要であり、パターンを特定し RPU を最適化するため、このワークロードを 10 回実行しました。これらの繰り返しを通して、AI は学習し、動作を適応させ、テスト期間中に合計 53,250 クエリを処理しました。 テストでは、AI 主導のスケーリングと最適化システムが、コスト最適化、バランス、パフォーマンス最適化の 3 つの異なる構成プロファイルに対してパフォーマンスを適応させ、最適化する様子が明らかになりました。 クエリと経過時間 同じコアのワークロードを繰り返し実行しましたが、JMeter で変数パラメータを使用して WHERE 句の条件に異なる値を生成しました。このアプローチにより、類似ではあるが異なるワークロードが作成され、システムが実際のシナリオでさまざまなクエリパターンを処理する方法を示す自然な変動が導入されました。 経過時間の分析により、パフォーマンス目標を達成するためにどのような設定にしたのかが示されています。 次のスクリーンショットで、各エンドポイントの平均消費メトリックスが示されています。 結果は期待通りで、パフォーマンス最適化の構成は大幅な高速化を実現し、バランス構成の約 2 倍、コスト最適化の構成の約 4 倍のクエリ実行速度でした。 次のスクリーンショットは、各テストの経過時間の内訳を示しています。 次のスクリーンショットは、10 回目の最終テスト反復で、構成間の明確なパフォーマンスの違いを示しています。 より詳しく説明すると、クエリの経過時間を 3 つのグループに分類しました。 短いクエリー: 10 秒未満 中程度のクエリー: 10 秒以上 10 分未満 長いクエリー: 10 分以上 最後のテストを考慮すると、分析は以下に示す通りです： 構成ごとの期間 コスト最適化 バランス パフォーマンス最適化 短いクエリ (<10 秒) 1488 1743 3290 中程度のクエリ (10 秒 – 10 分) 3633 3579 2035 長いクエリ (>10 分) 204 3 0 合計 5325 5325 5325 構成の容量は、クエリの経過時間に直接影響します。コスト最適化構成では、リソースを制限してコストを節約しますが、その結果クエリ時間が長くなるため、時間的な制約がなく、コスト削減が優先される作業に最適です。バランス構成では、中程度のリソースを割り当てることで、中程度の時間のクエリを効果的に処理し、短いクエリに対しては合理的なパフォーマンスを維持しつつ、長時間実行されるクエリをほぼ排除する中間的な性能を示します。一方、パフォーマンス最適化構成では、多くのリソースを割り当てることで、コストは増加しますが、クエリ結果が高速になるため、クエリの速度が重要な待ち時間に敏感な作業に最適です。 テスト中の使用容量 3 つの構成を比較した結果、Amazon Redshift Serverless の AI 主導のスケーリングと最適化テクノロジーが、ユーザーの期待に応じてリソース割り当てを調整することがわかりました。監視では、ベース RPU の変動はあるものの、構成間で異なるスケーリングパターンが確認されました。パフォーマンスを優先してスケールアップするか、コスト最適化のために RPU を抑えるかが、構成によって異なっていました。 コスト最適化構成は 128 RPU から開始し、3 回のテスト後に 256 RPU に増加します。コスト効率を重視するため、このセットアップではクエリが一時的に溜まった場合でも、スケーリング時の最大 RPU 割り当てを制限します。 次の表では、コスト最適化構成のコストを確認できます。 テスト # 起動時の RPU 数 拡張後の RPU 数 発生コスト 1 128 1408 $254.17 2 128 1408 $258.39 3 128 1408 $261.92 4 256 1408 $245.57 5 256 1408 $247.11 6 256 1408 $257.25 7 256 1408 $254.27 8 256 1408 $254.27 9 256 1408 $254.11 10 256 1408 $256.15 Amazon Redshift Serverless による戦略的な Redshift Processing Unit (RPU) の割り当てが、コストの最適化に役立つことが、テスト 3 と 4 で観測された大幅なコスト削減から示されています。これは次の図に示されています。 コスト最適化がベース RPU を変更しましたが、バランス構成ではベース RPU は変更されず、2176 RPU にスケールアップしました。これは、コスト最適化設定によって使用された最大値が 1408 RPU を上回っています。次の表は、バランス構成の数値を示しています。 テスト No. 開始 RPU 数 スケールアップ先 発生コスト 1 192 2176 $261.48 2 192 2112 $270.90 3 192 2112 $265.26 4 192 2112 $260.20 5 192 2112 $262.12 6 192 2112 $253.18 7 192 2112 $272.80 8 192 2112 $272.80 9 192 2112 $263.72 10 192 2112 $243.28 バランス構成は、テストあたり平均 $262.57 かかりましたが、パフォーマンスが大幅に向上し、コスト最適化構成 (テストあたり平均 $254.32) に比べてわずか 3% 高いコストでした。前のセクションで示したように、このパフォーマンス上の利点は経過時間の比較からも明らかです。次のグラフは、バランス構成のコストを示しています。 パフォーマンス最適化の構成から予想されるように、リソースの使用量が高くなり、高パフォーマンスを実現しました。この構成では、2 回のテスト後にエンジンが適応し、より多くの RPU から開始してクエリをより速く処理するようになったことも確認できます。 試行番号 開始時の RPU スケールアップ後の RPU 数 発生コスト 1 512 2753 $295.07 2 512 2327 $280.29 3 768 2560 $333.52 4 768 2991 $295.36 5 768 2479 $308.72 6 768 2816 $324.08 7 768 2413 $300.45 8 768 2413 $300.45 9 768 2107 $321.07 10 768 2304 $284.93 3 回目のテストで 19% のコストアップがあったものの、その後の大半のテストでは平均コストを下回りました。 パフォーマンス最適化構成は、クエリ時間を短縮することを優先し、コスト効率よりも速度を重視してリソース使用量を最大化します。 費用対効果の最終分析では、説得力のある結果が明らかになりました: バランス構成は、コスト最適化構成に比べてわずか 3.25% のコスト増でパフォーマンスが 2 倍向上しました パフォーマンス最適化構成は、コスト最適化オプションと比較して 19.39% のコスト増で経過時間が 4 分の 1 の時間で実行できました。 次の図は、コストパフォーマンスの調査結果を示しています。 これらの結果は特定のテストシナリオを反映していることに注意が必要です。各ワークロードには固有の特性があり、構成間のパフォーマンスとコストの違いは、他のユースケースでは大きく異なる可能性があります。 当社の調査結果は一般的な基準というよりは参考値として提示するものです。また、Amazon Redshift Serverless で利用可能な中間の 2 構成(コスト最適化とバランスの間、バランスとパフォーマンス最適化の間)はテストしていません。 結論 テスト結果は、さまざまなワークロード要件に対する Amazon Redshift Serverless の AI 駆動型スケーリングと最適化の有効性を示しています。この結果は、Amazon Redshift Serverless の AI 駆動型スケーリングと最適化が、組織がコストとパフォーマンスの理想的なバランスを見つけるのに役立つことを示唆しています。ただし、テスト結果は参考程度にすぎません。各組織は特定のワークロード要件とコストパフォーマンス目標を評価する必要があります。5 つの異なる最適化プロファイルの柔軟性と、インテリジェントなリソース割り当てを組み合わせることで、チームはデータウェアハウス運用を最適な効率で細かく調整できます。 Amazon Redshift Serverless の AI によって自動的に行われるスケーリングと最適化を開始するには、次のことをお勧めします。 現在の価格とパフォーマンスのベースラインを確立する ワークロードのパターンと要件を特定する 特定のワークロードでさまざまな最適化方法をテストする 結果に基づいて監視と調整を行う これらの機能を活用することで、組織は特定のパフォーマンスとコスト目標を達成しながら、リソースをより効率的に活用できます。 AWS マネジメントコンソールにアクセスして、今すぐ Amazon Redshift Serverless の AI 主導のスケーリングと最適化機能を作成し、さまざまな最適化プロファイルを探索してみてください。詳細については、Amazon Redshift Serverless の AI 主導のスケーリングと最適化に関するドキュメントをご覧いただくか、AWS アカウントチームにお問い合わせいただき、ご利用のユースケースについてご相談ください。 著者について Ricardo Serafim は、AWS のシニアアナリティクス専門ソリューションアーキテクトです。2007 年からデータウェアハウスソリューションの支援を行っています。 Milind Oke は、ニューヨークを拠点とするデータウェアハウス専門のソリューションアーキテクトです。15 年以上にわたってデータウェアハウスソリューションを構築しており、Amazon Redshift に特化しています。 Andre Hass は、AWS の Senior Technical Account Manager で、AWS のデータ分析ワークロードに特化しています。20 年以上のデータベースとデータ分析の経験を持ち、お客様のデータソリューションの最適化と複雑な技術的課題の解決を支援しています。データの世界に没頭していないときは、アウトドアアドベンチャーに情熱を注いでいます。週末や機会があれば、家族とキャンプ、ハイキング、新しい目的地を探索することを楽しんでいます。 翻訳は、ソリューションアーキテクトの平井が担当しました。原文は こちら です。

この記事は Under the hood: Amazon EKS Auto Mode (記事公開日: 2025 年 3 月 31 日) を翻訳したものです。 この記事は、EKS シニアプロダクトマネージャーの Alex Kestner、EKS シニアソフトウェアエンジニアの Todd Neal、EKS シニアソフトウェア開発マネージャーの Neelendra Bhandari、プリンシパルスペシャリストソリューションアーキテクトの Sai Vennam が共同執筆しました。 re:Invent 2024 で、Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode を発表しました。EKS Auto Mode は、すぐにワークロードをホストできる、Kubernetes 準拠の本番環境対応のクラスターを提供する新機能です。この記事では、EKS Auto Mode が Kubernetes ワークロードにとってどのような意味を持つのか、そして EKS Auto Mode クラスターの内部構造について詳しく説明します。 EKS Auto Mode の概要 EKS Auto Mode を利用するとアプリケーションをより効率的に運用できるようになります。Kubernetes コントロールプレーンとワーカーノードのセットアップ、スケーリング、メンテナンスを自動的に管理するため、基盤となるインフラストラクチャを気にする必要がありません。アプリケーションのデプロイに集中すれば、EKS Auto Mode が残りの部分を処理します。これは、複雑さを管理することなく Kubernetes を使用したいユーザーに最適です。 2017 年の re:Invent で、Kubernetes の運用を効率化する Amazon EKS をローンチしました。ローンチ時の Amazon EKS は、 AWS Identity and Access Management (IAM) などの既存のサービスと統合された、マネージド Kubernetes コントロールプレーンを提供しました。私たちはそのコントロールプレーンの健全性とパッチ適用に責任を持ち、現在ユーザーは毎年数千万の EKS クラスターを実行しています。しかし、ワークロードが実行される Kubernetes クラスターのデータプレーンである Amazon Elastic Compute Cloud (Amazon EC2) ノードの運用はユーザーが責任を負っていました。 マネージドノードグループ や Karpenter などの機能を年々導入し、データプレーンの運用負荷を軽減してきましたが、ユーザーは依然として、適切な OS の選択、基盤となるノードのスケーリング、CNI や kube-proxy などのコアアドオンやコンポーネントの管理に責任を負っていました。 図 1: Amazon EKS (Auto Mode を含まない) の責任共有モデル EKS Auto Mode は、2017 年に導入した運用モデルの進化版で、Kubernetes クラスターのデータプレーン部分の責任を AWS がより多く引き受け、マネージド型のコンピューティング、ネットワーキング、ストレージ機能を提供します。EKS Auto Mode を使用すると、ユーザーはクラスターを作成し、すぐに本番環境対応のワークロードをデプロイできます。EC2 インスタンスの設定、パッチ適用、健全性の管理は AWS が担当するため、ユーザーは VPC とクラスターの設定、および実行するアプリケーションコンテナにのみ注力できます。 図 2: Amazon EKS (Auto Mode を含む) の責任共有モデル EKS Auto Mode におけるデータプレーン EKS Auto Mode クラスターのデータプレーンを構成する重要なコンポーネントがいくつかあります。 EC2 マネージドインスタンス は、AWS に運用管理が委任された標準的な EC2 インスタンスです。 Bottlerocket は、AWS がコンテナの実行を目的に構築したオープンソースのオペレーティングシステムです。 コア機能とアドオン は EKS Auto Mode が管理するノードに組み込まれており、ユーザーがこれらのコンポーネントを管理・維持する必要がありません。 ワーカーノード管理 (Karpenter) は、ワーカーノードの健全性を自動的に処理し、コスト効率を最適化するための理想的なインスタンスタイプでノードを削除および置き換えることができます。 EC2 マネージドインスタンス 最も基本的なレベルでは、EKS Auto Mode は re:Invent 2024 で発表された新機能である EC2 マネージドインスタンス を使用します。マネージドインスタンスは標準的な EC2 インスタンスですが、Amazon EKS のような AWS サービスに運用管理を委任している点が異なります。基本的に、EKS Auto Mode は運用のオーバーヘッドと一部の制御を手放すことで、セキュリティの向上を得ることができます。例えば、マネージドストレージ機能がワークロードに必要な EBS ボリュームのアタッチとデタッチを担当するため、EKS Auto Mode が管理するノードから Amazon Elastic Block Store (Amazon EBS) ボリュームを手動でデタッチする必要がなくなります。同様に、ノードに直接 SSH 接続することはできませんが、Amazon EKS サービスを通じてインスタンスの情報取得や トラブルシューティング を行う機能は常に維持されています。EKS クラスターの削除時にクラスターに関連付けられた EC2 マネージドインスタンスが強制的に終了されるため、EKS クラスターのクリーンアップがより直接的になります。 EC2 マネージドインスタンスにより、EKS Auto Mode は Kubernetes ワークロードのコンピューティングキャパシティをシームレスに管理できます。そのため、ノードの管理ではなく、アプリケーションのデプロイと実行に集中できます。ワークロードは、 AWS Lambda や AWS Fargate のように、AWS がお客様に代わってワークロードを実行する場合と同じ基準で維持されます。既存ノードのキャパシティをワークロードが超過した場合、EKS Auto Mode は Karpenter (後述のワーカーノード管理セクションで詳しく説明) を使用して、高可用性とパフォーマンスを確保するために EC2 マネージドインスタンスを動的にプロビジョニングし、手動でのスケーリング調整の必要性を排除します。 EC2 マネージドインスタンスは、インフラストラクチャ管理の合理化だけでなく、コストの最適化にも役立ちます。 リザーブドインスタンスや Savings Plans などの既存の AWS のコスト削減メカニズムを利用でき、予測可能な支出を維持しながら柔軟性を提供します。 EKS Auto Mode を通じて EC2 マネージドインスタンスを使用することで、AWS がインフラストラクチャを管理する完全マネージド型の Kubernetes をユーザーは利用でき、アプリケーションの開発とスケーリングに集中できます。 オペレーティングシステムとしての Bottlerocket の選択肢 EC2 マネージドインスタンスは、他の EC2 インスタンスと同様にオペレーティングシステムが必要です。EKS Auto Mode は、 Bottlerocket を使用します。これは AWS がコンテナ実行を目的として開発したオープンソースのオペレーティングシステムです。Bottlerocket は、Kubernetes ワークロードを効率的かつ安全に実行するように設計されているため、EKS Auto Mode の理想的なベースオペレーティングシステムです。Bottlerocket には、コンテナの実行に必要なソフトウェアのみが含まれています。大規模な汎用オペレーティングシステムが約 50,000 のパッケージ定義を持つのに対し、Bottolerocket のオープンソースプロジェクトは約 100 のパッケージ定義を維持しています。これにより、不要な機能と依存関係がビルド時に無効化されます。さらに、コンテナのユースケースに不要なサービスを排除することで、潜在的な CVE の対象領域を減らすとともに、ワークロードにより多くのリソースを提供します。Bottlerocket は、ルートファイルシステムの暗号化整合性チェックと、SELinux などの強制アクセス制御を実施し、コンテナエスケープが発生した場合の攻撃対象領域を削減します。 EKS Auto Mode で利用する Amazon Machine Image (AMIs) は、Bottlerocket の新しい Out of Tree Build (OOTB) システムを使用するカスタム Bottlerocket バリアントです。OOTB は、カスタム Bottlerocket バリアントを作成するための合理化されたメカニズムです。OOTB はバリアントと Bottlerocketのコア部分との依存関係を疎結合に定義します。これにより、カスタムバリアントは独自の進化を遂げながらも、Bottlerocketのコアアップデートを安全に取り入れることができます。 kernel kit と core kit は Bottlerocket のコアを形成し、EKS Auto Mode で利用する AMI はこれらを Bottlerocket プロジェクトから取り込むことで、セキュリティと慎重に選定された依存関係に焦点を当てた恩恵を受けています。 EKS Auto Mode 固有の新しい ノード機能を提供するだけでなく、Auto Mode AMI は Bottlerocket の基本的な設定にもいくつかの変更を加えています。たとえば、標準の Bottlerocket は SSH やコンソールを介したインタラクティブなログインをサポートしていません。代わりに、アクセスを提供するためのホストコンテナと呼ばれる特別なタイプのコンテナを利用することができます。EKS Auto Mode は Bottlerocket ホストコンテナを完全に無効化し、代わりに ノードログの取得 や、ノードとの 直接的なやり取り のための Kubernetes ネイティブなメカニズムを提供します。これには、ネットワーク接続がない場合の ノードのトラブルシューティング情報 の取得などが含まれます。また、EKS Auto Mode は、ブートストラップコマンドのような新しい Bottlerocket の機能を利用して、ローカルインスタンスストレージ (インスタンスタイプが対応している場合) を設定します。これにより、対応するインスタンスタイプに含まれる高速なエフェメラルローカルストレージが、コンテナイメージ、Pod のエフェメラルデータ、およびログに自動的に使用されます。 コアノードの機能 Kubernetes ノードには通常、ノードレベルの重要な機能を提供するための Pod を作成する DaemonSet が必要です。ユーザーからは、これらのコンポーネントの管理、パッチ適用、互換性の確保が困難で時間がかかるという声が多く寄せられていました。EKS Auto Mode の一環として、最も一般的に使用されるコンポーネントについて、この煩雑な作業を解消しました。まず、EKS クラスターの大多数で使用されているコアとなるノード機能を特定し、それらの機能を EKS Auto Mode ノードに直接組み込むように取り組みました。 ネットワーク:ノードのローカルネットワーク設定、DNS、および Network Policy の適用 ストレージ: Amazon EBS にバックアップされた Persistent Volume と、一時データ用の ローカルインスタンスストレージ の、オペレーティングシステムレベルの設定 アイデンティティ: Pod に IAM アイデンティティを設定できるようにします 専門ハードウェアのサポート AWS Neuron : Inferentia アクセラレータと Trainium アクセラレータを Pod で利用できるようにするドライバとデバイスプラグイン NVIDIA: NVIDIA GPU を Pod で使用できるようにするためのドライバーとデバイスプラグイン Elastic Fabric Adapter (EFA) : EFA デバイスを Pod で使用できるようにするドライバーとデバイスプラグイン ヘルス: ノードヘルスモニタリング 。特定の障害モードのレポート作成と自動修復が可能 上記から、EKS Auto Mode を利用するクラスターでは Network Policy での適切なネットワーク設定、 Pod Identity を使用した AWS サービスへのリクエスト、Persistent Volume を使用した EBS へのデータ保存を行う Pod を作成できます。NodePool がアクセラレーテッドインスタンスタイプをサポートしている場合、ノード上の Pod はリソースリクエストを通じて Neuron アクセラレータや NVIDIA GPU を使用することもできます。さらにユーザーの負担を軽減するため、組み込みのヘルスモニタリングは、Amazon EKS の運用を通じて特定してきた一連の問題や障害モードを定期的にチェックし、Kubernetes のイベントやコンディションを通じて報告します。応答しない kubelet やプロセス ID の枯渇などのエラーケースでは、EKS Auto Mode はノードを自動的に修復し、置き換えることでアプリケーションへの影響を最小限に抑えることができます。 ワーカーノードの管理 Karpenter を活用した EKS Auto Mode のコンピュート機能は、EC2 マネージドインスタンスと Bottlerocket ベースの EKS Auto Mode AMI を組み合わせて、EKS Auto Mode ノードを作成します。このコンピュート機能は、ワークロードの実行に必要なコンピュート容量を提供するために、必要に応じてノードを自動的に起動および終了します。これらのノードは、設定された NodePool とクラスター内のワークロード要件に基づいて、コスト効率を継続的に最適化します。 このプロセスは、ワークロード要件 (CPU、メモリ、または特殊なハードウェアのニーズなど) と Kubernetes のスケジューリング制約を満たす、最もコスト効率の高いインスタンスタイプを特定することから始まります。ワークロードや NodePool の要件を通じてインスタンスタイプの選択を正確に制御するか、より広範なインスタンスタイプを許可することで柔軟性を維持しコストを削減することができます。適切なインスタンスが特定されると、EKS Auto Mode は、それらの特定のインスタンスタイプに対応する Auto Mode AMI を使用して、必要な EC2 マネージドインスタンスを起動します。 時間の経過とともに、需要に合わせてスケールアップ / スケールダウンしたり、ワークロードがクラスターに追加 / 削除されたりすると、ワークロード要件が変化する可能性があります。EKS Auto Modeは、統合プロセスの一環としてクラスター全体を継続的に評価し、ワークロードをより費用対効果の高い方法で実行できるかどうかを判断します。大まかに言うと、次の 2 つの方法でこれを実現しています。 ノードの削除: クラスター内の他のノードの利用可能なキャパシティで、そのノードのすべての Pod が実行できる場合、そのノードは削除の対象となります。 ノードの置き換え: 既存のノードの利用可能なキャパシティと、より低コストの代替ノード 1 つの組み合わせで、そのノードのすべての Pod を再分配できる場合、そのノードは置き換えの対象となります。 迅速なノードプロビジョニングと継続的なコスト最適化のシームレスな統合により、EKS Auto Mode がノード管理タスクを処理する間、ユーザーはクラスター内のワークロードに集中できます。 ノードのライフサイクルとメンテナンス EKS Auto Mode が登場する以前は、ノードレベルのコンポーネントと EKS クラスターコントロールプレーンの互換性の検証、それらのコンポーネントのデプロイ、パッチ適用と更新管理はユーザーの責任でした。 Cluster Insights のような機能により、非互換性を表示することで負担は軽減されましたが、デプロイとパッチ適用はユーザーの責任のままでした。EKS Auto Mode では、すべてのコアノード機能を含むテスト済みの最新 AMI を、すべての EKS Auto Mode ノードで継続的に利用できるようにすることで、AWS がその責任を引き受けます。Auto Mode AMI のビルドとリリースプロセスは、以下を担当する継続的デプロイメントパイプラインによって駆動されます。 CVE スキャン AMI のビルド AMI の検証 Kubernetes コンフォーマンス テスト コンポーネントの機能テスト (例: Pod が EKS Pod Identity を通じて IAM 認証情報を取得できることの検証) セキュリティテスト AMI のデプロイ このパイプラインは、 安全なハンズオフデプロイメントの自動化 の標準的なベストプラクティスに従っています。このプロセスは、新しくテストされた AMI を単一のリージョン内の少数の EKS Auto Mode クラスターにデプロイすることから始まり、潜在的な問題を検出するための時間を設けています。AMI の安定性に対する信頼性が高まるにつれて、より多くのクラスターに段階的にロールアウトされ、より大規模な展開とより多くの AWS リージョンへの展開が行われ、デプロイメント間の時間も短縮されていきます。 EKS Auto Mode では、ユーザーがすべてのコントロールプレーンのアップグレードを制御およびトリガーすることができます。データプレーンの更新については、 Pod Disruption Budget と Node Disruption Budget を使用して更新プロセスを管理できます。これらのツールは、 Pod とノードの両方のレベルで詳細な制御を提供します。 Pod Disruption Budgets は、特定のワークロード更新時に許可される中断の最大数を定義します。 Node Disruption Budgets は、メンテナンスウィンドウを指定し、同時に更新できるノード数を制御することができます。 AWS が新しいセキュリティパッチを適用した EKS Auto Mode AMI をリリースすると、EKS Auto Mode は Kubernetes のスケジューリング制約と設定された Disruption Budgets を考慮しながら、ワーカーノードを自動的にアップグレードできます。 EKS のベストプラクティスドキュメント では、アップデート中のアプリケーションの信頼性を維持するための具体的な推奨事項など、これらの制御を効果的に実装するための詳細なガイダンスを提供しています。 まとめ Amazon EKS Auto Mode は、ユーザーが AWS 上で Kubernetes を実行する方法を大きく進化させたものです。セキュアなコンピュート管理のための Amazon EC2 マネージドインスタンス、コンテナ最適化オペレーティングシステムとしての Bottlerocket、そして重要な機能が組み込まれたノードを組み合わせることで、EKS Auto Mode はユーザーがインフラストラクチャ管理からアプリケーション開発へと注力できるようにします。ノードコンポーネントの設定、セキュリティパッチの管理、運用ツールのメンテナンスに時間を費やす代わりに、チームはビジネスにとって重要なアプリケーションのデプロイとスケーリングに集中できます。 EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する 準備はできましたか？ eksctl、AWS CLI、AWS マネジメントコンソール、EKS API、またはお好みの Infrastructure as Code ツールを使用して、新しい EKS Auto Mode クラスターをデプロイしたり、既存のクラスターで EKS Auto Mode を有効にしたりできます。ワークロードのデプロイと Auto Mode の機能を探索するハンズオンワークショップをお試しください。 お客様自身の AWS アカウント で実行するか、 AWS 主催のイベント に登録して参加できます。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

この記事は 「 Mastering Direct-to-Consumer Marketing with First-Party Data: Delivering Personalized Experiences Using Generative AI 」（記事公開日： 2025 年 3 月 11 日）の翻訳記事です。 消費財 (Consumer Packaged Goods) 企業が長期的な成功を収めるためには、考慮すべき点がたくさんあります。とりわけ、ブランドイメージを維持し、利益率を改善し、顧客との良い関係を築く新しい方法を見つける必要があります。幸いなことに、生成 AI の出現により、消費財企業がこれらすべての課題に対処できるようになりました。ただし、これは万能のアプローチではありません。AI を組織に導入するだけでは、最大のメリットは得られません。ビジネス目標に沿った戦略的アプリケーションを採用する必要があります。 このため、消費財ブランドは、そうした消費者への D2C 戦略を実施するために、高度な分析と生成 AI のサービスとソリューションを豊富に用意しているアマゾンウェブサービス（AWS）に目を向けています。専用の基盤モデル、豊富なツール、AWS の堅牢なインフラストラクチャを活用することで、企業はファーストパーティデータを実用的なインサイトに変えることができます。サードパーティーデータへの依存を減らし、AWS のソリューションとサービスを使用してパーソナライズされた体験を向上させた Tapestry、Adidas、DoorDash、FrontDoor Inc. の事例を参照してみてください。彼らの投資は事業の将来を見据えたものであり、持続可能な成長を促進し続けています。さらに、今日の競争の激しいビジネス環境においても、プライバシーコンプライアンスを遵守しながら、インサイトを収集し、パーソナライズされた体験を実現しています。このブログではそうした方法についても説明しますが、その前に、こうした変革をもたらした背景について説明します。 ファーストパーティデータによる消費者行動の予測 ファーストパーティデータは、消費財企業が高度な分析機能を通じて顧客のニーズを予測する上で重要な役割を果たします。過去の購入パターンを分析することで、企業は将来のキャンペーン戦略のベースとなる有意義な傾向を明らかにすることができます。高度な機械学習 (ML) モデルは、購入意向や潜在的な解約リスクなどの特定の行動を予測することで、この機能を強化します。消費財企業は、これらのインサイトを活用して、さまざまな顧客セグメントの共感を呼び起こす、セグメント別のターゲットごとに最適化されたメッセージングキャンペーンを推進することもできます。 消費財企業によるファーストパーティデータ戦略への適応 消費財企業は、ロイヤルティプログラムと改善された CRM（顧客管理）システムを通じて収集されたファーストパーティデータを活用することで、Cookie が使えなくなる未来に適応しようとしています。そこで AWS では、パーソナライズされたマーケティング、データ駆動の商品開発、および効果的なターゲット広告のためのリテールメディアネットワークの連携を可能にする 5 つの主要な戦略に焦点を当てることを提案しています。 ロイヤルティプログラムの構築：ロイヤルティプログラムは、報酬と引き換えにデータを共有してもらうよう消費者にインセンティブの形でアプローチします。たとえば、割引や限定商品を提供することで、購入パターンに関する貴重なインサイトを収集し、リピート購入を促すことができます。 Starbucks はその好例です。 CRM システムの強化：ファーストパーティデータを CRM プラットフォームに統合することで、消費財企業は詳細な顧客プロファイルを作成できます。こうしたプロファイルを活用して、パーソナライズされたマーケティングキャンペーンや顧客とのより強固な関係構築が可能になります。 パーソナライズされたマーケティングキャンペーン：ファーストパーティデータを分析することで、ブランドは消費者の好みや行動に基づいてオーディエンスをセグメント化できます。たとえば、オーガニック製品（商品）に関心のあるセグメントを特定した企業は、こうした商品を強調してセグメント別のターゲットごとに最適化されたキャンペーンを作成し、コンバージョン率を高めることができます。 商品開発の最適化：ファーストパーティのデータは、商品イノベーションに役立つ消費者からの直接的なインサイトを提供します。したがって、企業が消費者の間でグルテンフリーのスナックへの関心が高まっていることに気付いた場合、需要に合わせてそうした種類の商品の開発を優先することができます。 リテールメディアネットワーク： iHerb や Oriental Trading などの企業は、Amazon Ads テクノロジーと連携して、パーソナライズされた広告を配信し、広告主とのつながりを最適化し、プラットフォーム全体で買い物客の体験を向上させています。これにより、企業は Amazon Ads をすでに利用しているブランドに広告を簡単に提供できるようになり、広告主とのつながりがスムーズになります。 AWS ベースのファーストパーティデータソリューションの主要インフラストラクチャコンポーネント 消費財企業が長期的な価値を追求したいのであれば、ファーストパーティのデータ戦略に投資すべきです。データの収集と利用に不可欠な AWS ソリューションとサービスを活用することで、企業は長期的な価値をいくつかの方法で実現できます。 テクノロジーインフラストラクチャ：顧客データプラットフォーム（Customer Data Platform; 以後 CDP）などのツールを導入することで、企業は複数のソースからの消費者データを統一されたプロファイルに一元化し、パーソナライズされたマーケティング活動を行うことができます。これには、クラウドストレージソリューションと分析ソフトウェアへの投資が不可欠です。 データ管理：企業には、クリーンで正確かつ安全なデータを維持するためのプラットフォームが必要です。データレイクには Amazon Simple Storage Service (Amazon S3) 、データウェアハウスには Amazon Redshift というのは素晴らしい選択肢です。というのも、分析を可能にしながら大規模なデータセットを安全に保存できるからです。 AWS Glue などのツールは、生データを自動的に取り込んで実用的なインサイトに変換し、データ準備の簡素化をサポートします。 データ分析とインサイト： Amazon SageMaker 、 Amazon QuickSight 、 Amazon Bedrock などの AWS 分析ツールは、CDP からのファーストパーティデータを分析してパターンを特定し、消費者の行動を予測することができます。 Amazon Q Business の生成 AI 機能は、自然言語によるインサイトを提供し、トレンド分析を自動化し、履歴データとリアルタイムの行動シグナルに基づいて顧客セグメントに関する予測を行います。 コンプライアンスへの取り組みとプライバシー遵守： AWS Artifact は、企業が監査レポートにアクセスできるようにし、規制コンプライアンスを維持できるようにする包括的なコンプライアンスツールと認証を提供しています。このソリューションには、きめ細かなアクセス制御、暗号化機能、および地域別のデータ保存オプションが付属しているため、組織は詳細な監査証跡を維持しながら特定のプライバシー要件を満たすことができます。 組織的な連携：Amazon S3 と Amazon Redshift によってデータの保管場所を集約することができますが、消費財企業はこれらを利用して部門間のコラボレーションを促進することもできます。さらに、 AWS Lake Formation と AWS Glue を使用して、抽出、変換、およびロード機能とともに安全なデータ共有をサポートできます。最後に、Amazon QuickSight と Amazon OpenSearch Service は、チームが共有データを分析して視覚化するのをサポートします。これらのサービスには、さまざまな部門に適切なアクセスレベルを割り当てて管理するアイデンティティアクセス管理コントロールが含まれます。 こうしたシステム導入には初期投資が必要な場合がありますが、ROI は確実に得られます。 IDC と Forrester の調査によると、ファーストパーティのデータを広告ターゲティング戦略に統合することで、ビジネスに大きなメリットがもたらされることがわかっています。これを実施した企業は、AI 駆動のインサイトを利用してメディア支出を再配分することで、購入数を 500% 向上させ、広告のクリックスルー率（CTR）を 300% 向上させ、顧客満足度を 78% 向上させ、コンバージョン率を 73% 向上させました。 AWS の包括的なツールキットで生成 AI の力を引き出す AWS のエンタープライズソリューションは、 Claude や Llama 2 などの大規模言語モデル (LLM) へのアクセスを提供する Amazon Bedrock を中核としています。 また、コンテキストに応じたリアルタイムの応答のための検索拡張生成機能が備わっている Amazon Titan にもアクセスできます。Amazon Q for Business では自然言語でデータのやりとりが可能で、Amazon SageMaker はモデル開発およびデプロイツールを提供します。企業はまた、自然言語処理のための Amazon Comprehend 、インテリジェントなエンタープライズ検索のための Amazon Kendra 、そして Amazon Q Developer を実装することもできます。これらのツールを組み合わせることで、組織は安全でスケーラブルな AI ソリューションを導入し、さまざまなユースケースを通じてビジネスを変革できます。以下は、AWS のソリューションとサービスを使用して顧客体験とエンゲージメントを強化した方法のほんの一部です。 1. インテリジェントなカスタマーサポート：パーソナライズされたインタラクションをリアルタイムで提供し、日常業務を自動化することで、顧客体験を向上させます。消費財ブランドは以下を使用してこれを実現できます。 a. Amazon Connect ： AI 搭載のチャットボットと音声アシスタントにより、24 時間 365 日の顧客セルフサービスを実現 し、待ち時間を短縮し、初回問い合わせの解決率を向上させます。 b. Amazon Lex V2：音声とテキストを使用するアプリケーション用の会話型インターフェイスを構築します。Amazon Bedrock の生成 AI 機能を使用して、Amazon Lex V2 ボットのボット作成を自動化し、スピードアップさせます。 c. Amazon Q in Connect ：動的で状況に応じた応答を生成し、エージェントと顧客への正確で、共感をもたらすコミュニケーションを実現します。 2. パーソナライズされた顧客エンゲージメント：生成 AI と顧客データ分析を組み合わせることで、高度にパーソナライズされた体験を実現します。これにより、ブランドはマーケティングメッセージ、レコメンデーション、オファーを顧客にあわせて簡単に調整できます。 a. Amazon Personalize ：AI により高度にパーソナライズされたユーザー体験をリアルタイムで大規模に提供することで、顧客体験を向上させます。 b. Amazon Bedrock：複数の大規模言語モデル (LLMs) から選択可能で、パーソナライズされた E メール、商品説明、プロモーションコンテンツを生成します。 c. Amazon SageMaker：ML モデルを構築し、ターゲットを絞ったキャンペーンを作成するために顧客行動を分析します。 3. プロアクティブな顧客への働きかけ：生成 AI を使用して顧客のニーズを予測し、タイムリーな対応を開始することで、プロアクティブなエンゲージメントを容易にします。 a. Amazon Connect のセグメンテーション機能：リアルタイムデータと履歴データに基づいて顧客を自動的にセグメント化し、ML と生成 AI の両方を使用してパーソナライズされたアウトリーチキャンペーンを生成します。 b. Amazon Comprehend：顧客からのフィードバックのセンチメントを分析して、積極的にエンゲージすべき機会を特定します。 4. エージェント支援の強化：顧客とのやり取り中に、生成 AI を活用したリアルタイムのインサイト、要約、レコメンデーションをブランド担当者に提供してサポートします。 a. Amazon Q in Connect ：通話中やチャット中に関連情報にすぐにアクセスできるため、エージェントの作業体験が向上し、生産性が向上します。 b. Amazon Kendra：インテリジェントなエンタープライズ検索をサポートして、ナレッジベースから正確な回答を取得します。これにより、担当者の調査時間が節約され、提供する情報の正確性が向上します。 5. セルフサービスの強化：生成 AI により、企業は直感的で効果的、かつ高度なセルフサービスオプションを提供して顧客が自分で実行できることを増やします。 a. Amazon Transcribe ：自動で音声入力をテキストに変換して、シームレスなやり取りを実現します b. Amazon Translate ：多言語に対応できるため、世界中の顧客にアプローチできます。 生成 AI は、業務のビジネス面だけでなく、顧客にもメリットをもたらします。例としては次のような機能があります。 パーソナライズされた自動応答により、問題をより迅速に解決できます。AI を搭載したシステムは、顧客からの問い合わせを即座に分析して応答できるため、応答時間を短縮できます。自動応答は顧客の履歴とコンテキストに基づいてパーソナライズされるため、数時間ではなく数分で正確なソリューションを提供できます。 シームレスなやり取りを通じて顧客満足度を高めます。一貫性のある正確な回答は、顧客満足度スコアを向上させることができます。AI システムは、24 時間 365 日、遅延なくサポートを提供し、ピーク時でも高品質を維持したサービスを提供できます。 正確なターゲティングによりコンバージョン率を高めます。AI は顧客の行動パターンと購入履歴を分析して的を絞ったレコメンデーションを提供します。その結果、従来の方法と比較して、クエリの解決が速くなり、コンバージョン率が高くなります。 実際に発生する前に顧客のニーズを予測します。予測分析を使うと、行動パターンと履歴データに基づいて潜在的な顧客ニーズを特定します。これにより、積極的なサポート介入が可能になり、顧客がサポートに問い合わせる回数が減ります。 不満に早期に対処することで解約率を減らします。リアルタイムの感情分析により、解約リスクのある顧客を特定し、即時対応を可能にします。問題の早期発見と解決は、顧客離れを減らし、顧客維持率を高めます。 多様なデータを最大限に活用 ファーストパーティのデータは、第三者による Cookie の利用が制限されつつある状況をうまく乗り切っていかなければならない消費財企業にとって重要な資産として浮上しています。AWS を使用することで、企業は社内と社外の両方でデータをさらに活用できるようになりました。生の顧客データを実用的なインサイトに簡単に変換し、よりパーソナライズされた経験を提供できるので、消費財企業にはこれまで以上に多くの選択肢を持つことができます。 データのニーズについて相談したい場合や、小売店向けに 生成 AI ソリューションを導入する準備ができている場合は、AWS がお手伝いします。 今すぐアカウントチームに連絡して始めましょう。 その他の参考資料 Tapestry は、何千人もの店舗スタッフから顧客の需要に関するリアルタイムのフィードバックを収集し、在庫管理と店舗の品揃えを最適化しました。 Adidas は AWS の生成 AI を使用して、受信者ごとにカスタマイズされたマーケティングキャンペーンを提供し、エンゲージメント率を向上させています。 DoorDash は Amazon Connect と Amazon Lex を使用してインタラクティブな音声応答システムを作成し、エージェントの移動距離を 49% 削減し、ファーストコンタクトの解決率を 12% 向上させ、年間 300 万ドルの経費節減を実現しました。 Frontdoor, Inc. の経験から、AI を活用したワークスペースがいかにエージェントの能力を強化し、顧客からの複雑な問い合わせに初日からより効果的に対処できるようになるかが明らかになっています。 著者について Udit Jhalani Udit は、バージニア州アーリントンを拠点とする AWS の 消費財シニアソリューションアーキテクトです。彼はクラウドベースのアプリケーションの設計に豊富な経験があります。彼は現在、大企業と協力して、そうした企業が拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャを構築することを支援し、クラウドに関するあらゆることを指導しています。彼はニューヨーク州立大学でコンピューターサイエンスの理学修士号を取得しており、「ソフトウェアは進化させなければ意味がない」という Dr. Werner Vogels の格言を信奉しています。 Krishnan Harihanan Krishnan はシカゴを拠点とする AWS のソリューションアーキテクチャ兼シニアマネージャーです。現在の役職では、顧客、商品、テクノロジーに関する広範な知識、運用に関する多様なスキルを活用して、小売/消費財企業の顧客が AWS を使用して最適なソリューションを構築できるよう支援しています。AWS に入社する前は Kespry 社の社長兼 CEO、LightGuide 社の COO を務めていました。デューク大学 Fuqua School of Business で経営学修士号を、デリー大学で電子工学の理学士号を取得しています。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

本記事は 2025 年 4 月 17 日に公開された “ Announcing General Availability of GitLab Duo with Amazon Q ” を翻訳したものです。 本日（原文公開日 : 2025/4/17）、 GitLab Duo with Amazon Q の一般提供開始を発表できることを嬉しく思います。この新しいサービスは、 GitLab の DevSecOps プラットフォームと Amazon Q の生成 AI 機能を組み合わせた製品です。GitLab Duo with Amazon Q は、GitLab の DevSecOps プラットフォームに Amazon Q エージェント機能を直接組み込み、ソフトウェア開発ライフサイクル全体にわたる複雑で多段階のタスクを加速します。 現在の急速に変化するソフトウェア開発環境では、開発者はコード品質やセキュリティ、デプロイメントのベストプラクティスを維持しながら、いかに生産性を高められるかを日々模索しています。GitLab Duo と Amazon Q の統合により、GitLab の包括的な DevSecOps プラットフォームと Amazon Q のインテリジェントなコーディング支援が組み合わさり、こうしたニーズに応えます。 この統合により、開発者は普段使い慣れた GitLab 環境の中で、アイデアの構想からデプロイメントまで、開発プロセス全体を通して AI を活用できます。新規ユーザーも既存ユーザーも、IDEで利用しているのと同じ Amazon Q Developer エージェントをそのまま GitLab でも使えるため、ツールが変わっても操作感は変わりません。 主な利点と機能 GitLab Duo と Amazon Q の統合が、より効率的で安全、かつ協調的なワークフローを作り出し、開発チームに大きな価値をもたらします。 この統合により、開発者は強力な AI 支援機能に GitLab から直接アクセスできるため、ツールや環境を切り替る必要がなくなります。GitLab は安全なコードのビルド、テスト、パッケージング、デプロイメントを自動化し、開発ライフサイクル全体を効率化します。とくに優れているのは、AI エージェントが GitLab プロジェクト全体のコンテキストを活用し、 ソフトウェア開発ライフサイクルの「ループ」を継続できることです。失敗したパイプラインのトラブルシューティング、脆弱性の調査、新機能の作成など、ありとあらゆる場面で、Amazon Q エージェントは適切なコンテキストを活用して適切なサポートを提供します。 セキュリティとコンプライアンスは、この統合の基本要素です。エンドツーエンドのセキュリティ制御がプラットフォームに直接組み込まれています。Amazon Q エージェントには適切なガードレールが備わっており、開発速度に影響を与えることなくコンプライアンスを満たすのに役立ちます。また、AWS のクラウドインフラストラクチャを活用することで、AI を取り入れた開発プロセスを安心して拡張できます。さらに、プロジェクトの脆弱性レポートの修正や、失敗したパイプラインのトラブルシューティングも Amazon Q エージェントに依頼できます。 開発プロセス全体にわたり、さまざまなタスクを支援する協調的な AI エージェントが用意されています。たとえば、Java コードをバージョン 8 または 11 から 17 にアップグレードする必要がある場合や、AI を活用したコードレビューの提案がほしい場合、包括的なテストケースを自動生成したい場合、または、アイデアをそのままマージリクエストに変換したい場合など、あらゆる場面で Amazon Q がサポートします。これらのインテリジェントなエージェントはチームと連携して作業し、生産性を向上させます。 ユースケースと例 GitLab と Amazon Q がどのように連携して開発生産性を加速し、組織のアプリケーションセキュリティを支援するかをお見せするために、ここではパズル愛好家に人気のある Java アプリケーションを使用してご紹介します。 アイデアからマージリクエストへ 開発者チームを拡大したい場合でも、機能リクエストから本番環境へのプロセスを効率化したい場合でも、GitLab Duo with Amazon Q は GitLab のプラットフォームに統合されており、GitLab の Issue を Amazon Q Developer エージェントに割り当てるだけで開発を始められます。 まず、GitLab プロジェクトでタスクを作成します。Q words ゲームに複数の言語をサポートする新機能を追加したいと思います。 ここから、Issueのコメントセクションで GitLab の クイックアクション の「 /q dev 」を使用して、タスクを直接 Amazon Q エージェントに割り当てます。 エージェントは、提案されたコード変更を確認するためのマージリクエストを自動的に作成します。ここでは、エージェントがフロントエンド、API、スタイル変更を含む 11 のファイルにわたる修正を行ったことが確認できます。以前であれば、IDE を立ち上げ、プロジェクトをクローンし、自分でこれらの変更をコーディングしていたでしょう。GitLab Duo with Amazon Q を使えば、新しいコードを確認してテストするだけで、すぐにデプロイの準備が整います。 コードレビュー コードレビューは開発ライフサイクルにおいて重要な機能を果たします。セキュリティやコーディング標準の高い品質を維持するための品質ゲートとして機能します。しかしその一方で、レビュアーが不在だったり、変更が複雑だったりすると、コードレビューはソフトウェアのリリースを遅らせる要因にもなります。 GitLab で利用できる Amazon Q エージェントによるコードレビュー機能は、チームがコードレビューをより迅速に進めるのに役立ちます。マージリクエストのコメント欄でクイックアクション「 /q review 」を実行すると、そのマージリクエストが Amazon Q に送信され、コード変更に関連するセキュリティや品質のリスクを自動的に検出します。 まず、マージリクエストを作成します。この例では、別の開発者が Q words アプリケーションに認証を追加するタスクを担当していました。 次に、クイックアクション「 /q review 」でエージェントを呼び出します。 レビューはマージリクエストにインラインのコード提案として返されます。ここでは、レビューエージェントによる指摘の一例を確認できます。コメントには発見された問題の説明と、コードを改善するためのガイダンスと関連リンクが含まれています。 次に、ウェブインターフェイスで GitLab Duo with Amazon Q のチャットエージェントを使い、変更内容の要約を依頼し、重要な問題を強調するようリクエストします。GitLab Duo チャットでは、現在の URL で表示されているリソースについて質問できます。この例ではマージリクエストについて質問していますが、他にも GitLab の Issue やリポジトリ内のコードファイルの概要についても質問できます。 テスト生成 次に、クイックアクション「 /q test 」を使用して、GitLab Duo with Amazon Q にテストの生成を依頼します。このアクションをコメントフィールドに追加すると、マージリクエストに十分なテストが含まれてない場合に、推奨されるテストコードが自動で生成されます。 GitLab Duo with Amazon Q から受け取る概要は、変更の範囲を把握するのに役立ち、重要なポイントに注意を集中させてくれます。さらに、Q Developer エージェントが提案したテストを活用することで、マージリクエストをより短時間で承認できます。 Java 変換 古いバージョンの Java アプリケーションを Java 17 にアップグレードすることは、時間がかかり、エラーが発生しやすい作業です。GitLab Duo と Amazon Q を使用すると、変換エージェントを活用して Java 8 コードから Java 17 へのコード移行を自動化し、プロジェクトの依存関係もアップグレードできます。まずは、GitLab プロジェクトで Java アップグレードに関する新しい Issue を作成します。 アップグレードを開始するには、GitLab Q のクイックアクション「 /q transform 」を使用します。Amazon Q 変換エージェントは、プロセスを続行するために gitlab-ci.yaml ファイルの更新を求めてきます。 エージェントの進行状況は、Issue の詳細画面で更新内容を確認することで把握できます。また、GitLab Duo with Amazon Q は、アップグレードに必要な変更内容を把握できるよう、Issue に変換計画も追加します。 変換が完了すると、確認のための新しいマージリクエストが自動的に作成されます。ご覧のとおり、pom.xml ファイルが Java 17 にてコンパイルできるように更新され、さらにプロジェクトが正しくコンパイルされるように追加の変更も行われています。さらに、更新された Java コードをマージしてデプロイする前に検討すべき次のステップを詳しくまとめたレポートも含まれています。 まとめ この記事では、GitLab Duo with Amazon Q がアプリケーション開発のスケールと改善にどのように役立つかをご紹介しました。GitLab Duo with Amazon Q を活用することで、GitLab の統合されたインターフェイス内で、追加機能の迅速な実装、コード変更のレビュー、アプリケーションの Java 17 へのアップグレードまで、すべてをスムーズに実施できました。これで、スペイン語の練習にも使える、安全でモダンな Java アプリが完成しました。 GitLab Duo with Amazon Q の一般提供は、AI を活用したソフトウェア開発における重要なマイルストーンとなります。GitLab の包括的な DevSecOps プラットフォームと Amazon Q の生成 AI 機能を組み合わせることで、この統合は開発チームがセキュリティとコンプライアンスの高い基準を維持しながら、より効率的に作業できるよう支援します。 組織はこの強力な統合を活用してソフトウェア開発ライフサイクルを加速し、手作業を減らし、より安全なコードをより迅速に提供できるようになります。シームレスな開発者体験、エンタープライズグレードのセキュリティ、開発プロセス全体にわたる協調的な AI エージェントにより、この統合はあらゆる開発チームのツールキットにとって価値ある追加となるでしょう。私たちは、お客様がこの統合を活用して開発プロセスを変革し、生産性とイノベーションの新たなレベルを達成されることを楽しみにしています。 さらに学びたい方はこちら GitLab Duo ドキュメント Amazon Q ドキュメント GitLab Duo with Amazon Q へのアクセスを取得 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Ryan Bachman Ryan Bachman は、Amazon Web Services（AWS）Next Generation Developer Experience チームのシニアスペシャリストソリューションアーキテクトです。Ryan は、クラウド向けアプリケーション開発の効率を高めるプロセスとサービスの採用をお客様が支援することに情熱を持っています。彼は開発、ネットワークアーキテクチャ、テクニカルプロダクトマネジメントなどの役割を含む 20 年以上の専門的な技術者としての経験を持っています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。 GWはリフレッシュできましたでしょうか？　休み明けの今週は火、水、木と生成AI関連のイベントが続きます！ 5 月 13 日 (火)：Coding Agent Workshop ~ 開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock活用のコツ 5 月 14 日 (水)：JAWS-UG Expert Online: Amazon Q Developer 特集 5 月 15 日 (木)：GenAIOps – 生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現 イベントの申し込み方法などのリンクはこちらのブログ「 生成 AI 最前線！5月開催の AWS 生成 AI イベントガイド 」にまとめていますので是非参照してみてください。 また、6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 の事前登録 が始まっていますのでこちらも登録をお忘れなく！ それでは、5 月 5 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Amazon Nova Premier: 複雑なタスクを実行したり、モデル蒸留の教師として機能させたりするための、当社の最も有能なモデル」を公開 ついに Amazon Nova Premier の一般提供を開始しました。これは複雑なタスクの実行や100万トークンの長文処理が可能な高性能モデルで、テキスト、画像、動画を処理できます。特筆すべき点は、モデル蒸留の教師モデルとしても機能し、Nova Pro、Lite、Microなどの小規模モデルに高度な機能を効率的に移行できることです。17のベンチマークで最高性能を示し、業界最高クラスの非推論モデルと同等以上のパフォーマンスを発揮します。Amazon Bedrock で利用可能で、マルチエージェントコラボレーションなど複雑なワークフローにも対応し、コスト効率の高いソリューションを提供します。 ブログ記事「Amazon Q Developer が新しいエージェントコーディングエクスペリエンスで IDE エクスペリエンスを改善」を公開 Amazon Q Developer に新しいエージェントコーディング機能が追加され、Visual Studio Code 上でより直感的な開発体験が可能になりました。素晴らしいのはこの機能により、自然な対話を通じてコードの作成、ドキュメント作成、テスト実行などがリアルタイムで行えるようになります。英語を含む10言語に対応していることや、コードベースのコンテキストを理解した的確な提案が可能なこと、そして Amazon Q Developer Pro と Amazon Q Developer 無料利用枠の両方で追加コストなく利用できることです。是非一度お試しください。 ブログ記事「Amazon Q Developer in GitHub (プレビュー) がコード生成を加速」を公開 GitHub環境で直接利用できるAmazon Q Developer for GitHub（プレビュー）の提供を開始しました。このツールを使用することで、GitHubのIssueに「Amazon Q Developer agent」ラベルを付けるだけで、新機能の開発から自動コードレビューまでをAIが支援してくれます。特筆すべき点は、セキュリティリスクの自動検出機能や、Java 8/11からJava 17への自動コード移行機能を備えていることです。AWS アカウント不要で無料で利用できるため、GitHubを日常的に使用する開発者の生産性向上に大きく貢献します。まさにAIを活用したフルスタック開発支援ツールとして、コード品質の向上とプロジェクトの効率化を実現します。 ブログ記事「Amazon Q Developer for GitHub (プレビュー) を活用して開発ワークフローを加速し、リリースサイクルを短縮する」を公開 開発 サイクルを短縮するためタスクを自動実行できる Amazon Q Developer for GitHub（プレビュー）は、AWS アカウントが不要で無料利用できます。Amazon Q Developer は GitHub.com と GitHub Enterprise Cloud での機能開発を加速します。。追加コストなしで Q Developer を支える高性能モデルを活用し、新機能の自動実装、バグの修正、テストカバレッジの向上、ドキュメント作成、すべての新しい Pull Request に対するコードレビューの実行、レガシー Java アプリケーションのモダナイズを行うことができます これらは GitHub 上にある Issue と Pull Request を使用しながら実現できます。 builders.flash 「天気のことならなんでも聞いて !」Amazon Bedrock で作るお天気エージェント ~ 株式会社ウェザーニューズによる実装解説」を公開 株式会社ウェザーニューズは、Amazon Bedrock を活用して気象情報のアシスタント機能「お天気エージェント」を開発しました。このシステムは、LangChain Agentsを利用し、Claude 3.5 Sonnet v2 モデルを採用することで、ユーザーからの多様な天気関連の質問に柔軟に対応できます。独自の気象データと組み合わせることで高い信頼性を確保し、ユーザーは「車で2時間の週末晴れる観光スポット」といった従来のアプリでは得られなかった情報まで取得できるようになりました。builders.flashでは「お天気エージェント」開発の背景や実装について解説しています。 「3 分でプロレベルの記事が完成 ! Amazon Bedrock を活用した AI コンテンツ作成支援機能の実装」を公開 株式会社いえらぶGROUPは、不動産業界向けSaaS「いえらぶCLOUD」に、Amazon Bedrock を活用したAIコンテンツ作成支援機能を実装しました。この機能は、Claude 3.5 Sonnet v2 を利用し、不動産業者が対象読者とSEOキーワードを入力するだけで、わずか3分程度でプロレベルのブログ記事を自動生成できます。従来3〜4時間かかっていた記事作成が大幅に効率化され、「書く時間が取れない」という課題を解決しています。builders.flashではAI コンテンツ作成までの流れやプロンプトエンジニアリングの工夫などを解説しています。 サービスアップデート GitHub向けのAmazon Q Developer 統合機能（プレビュー版）が利用可能に GitHub環境で直接利用できる Amazon Q Developer for GitHub（プレビュー）を発表しました。開発者はGitHub.comとGitHub Enterprise Cloudプロジェクトにおいて、機能開発、コードレビュー、Javaコード変換などをAmazon Q Developerエージェントを通じて実行できます。詳細はこのブログの前半で紹介した ブログ記事「Amazon Q Developer for GitHub (プレビュー) を活用して開発ワークフローを加速し、リリースサイクルを短縮する」を公開 を参照ください。 Amazon Bedrock Data Automationが音声からのカスタムインサイト抽出に対応 Amazon Bedrock Data Automation（BDA）が、ブループリントを通じて音声データからのカスタムインサイト抽出機能を追加しました。ブループリントをニーズに合わせてカスタマイズすることで、顧客との通話や臨床討論、会議など様々な音声会話から要約、重要トピック、意図、感情などの洞察を抽出できます。この機能は米国西部（オレゴン）および米国東部（バージニア北部）のAWSリージョンで利用可能です。 Amazon SageMaker AIがカスタムコード提案とワークスペースコンテキストでAmazon Q Developerを強化 Amazon SageMaker AI Jupyter LabにおけるAmazon Q Developerの機能強化を発表しました。プライベートコードリポジトリに基づくコード提案のカスタマイズ機能では企業や組織が持つ独自のプログラムを学習させることで、その組織に最適なコード提案ができるようになります。ワークスペース全体のコンテキストを含めた支援機能では、開発中のプロジェクト全体を理解した上でアドバイスができるようになります。これにより、例えば「このプロジェクトではこういう書き方が推奨されています」といった、より実践的なサポートが可能になります。開発者は通常のチャット感覚でAIに質問でき、プロジェクトの規模や複雑さに関係なく、一貫性のある高品質なコード作成支援を受けられます。 今週は以上でした。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近は自宅焼き鳥で串打ちにハマっています。

みなさん、こんにちは。ソリューションアーキテクトの松本です。本記事では、2025/04/15 に開催された、 流通小売・消費財のお客様向けの基幹システム移行イベント の内容をお伝えいたします。 イベントの目的 市場の拡大や頻繁に変化する顧客のニーズに対応するために、流通小売・消費財業界ではテクノロジーを活用して組織やシステムの柔軟性を保つことが求められます。AWS クラウドへの移行はシステム基盤のコスト削減だけでなく、ビジネス側からの要求に短期間で応えられるようになることも含みます。コアビジネスこそ AWS に移行することでビジネスの俊敏性を実現し、企業の経営戦略に貢献できます。しかし、そのための障壁、変化へのリスクやレガシーシステムであること、クラウド人材の不足といったものからクラウド移行を躊躇される企業様を見受けるケースがあります。このイベントではそれらを乗り越えられた顧客事例をご紹介し、ビジネス変革へのチャレンジの参考にしていただくことを目的としました。 当日にご参加のお客様はクラウドへの リフト & シフト をご検討中である傾向がありました。 当日のアジェンダ このイベントでは、ユーザー企業様に事例登壇をしていただき、パネルディスカッションでさらに取り組みを伺う構成にしました。 コーナン商事株式会社 佐々木 史人氏 コーナン商事株式会社 佐々木 史人氏からは、「事業の成長を支える基幹システムを中心としたオンプレミスから AWS へのシステム移行」と題してお話いただきました。 登壇内容のポイント オンプレミス環境でのデータ保持制限や高コスト、拡張性の問題が移行の契機となった。 コストや基盤停止リスクの声 に対し丁寧な説明を行い、専任部署を設置して円滑な移行を実現した。 AWS移行後、データの長期保管や分析が可能となり、店舗情報の共有も効率化された。 コーナン商事株式会社様が AWS に移行する前のシステム課題として、既存のオンプレミスシステムが Solaris 上で構築されており、POS をはじめとする業務データを 1 年ごとに捨てざるを得ず、OS の将来性やディスク装置の拡張性に懸念がありました。また、開発コストが高いファイルベースの他システム連携や、Oracle や VMware を使い続ける場合の高いコストも課題でした。そこで、今後の事業拡大を見据えて、これらの課題を解決するために AWS への移行を検討しました。 移行にあたっての課題は、主に社内の抵抗感でした。特に、既存のオンプレミスのみを経験していたベンダーやシステム部門のメンバーからの疑念が強かったとのことです。これに対して、例えば従量課金でのコストの懸念に対しては、クラウドでは必要最低限のスペックで運用でき、コストを抑えられるという説明をされました。また、クラウドの突然の停止や遅延に対する懸念に対しては、オンプレミスでは全て自分たちで対処する必要があるのに対して、AWS なら基盤が自動復旧するので運用負荷を下げられることを説明されました。他にもセキュリティの確保や運用体制の構築といった対処によって社内の理解を得ました。 移行スケジュールは、2019 年から検討を開始し、移行は 2020 年 1 月から着手、2021 年 6 月には オンプレミスから AWS に切り替えました。移行後は、発注量の多い年末年始に OS レイヤーの設定起因で障害が起きたものの、その後は安定稼働を続けています。そして、AWS 移行ができたことでさらなる事業の成長に向けた、拡張性のある基盤を獲得できました。 Amazon S3 を使ったデータレイクを導入し、データの無期限保管が可能になったことで、BI で長期間のデータを分析できるようになりました。また、データレイクから API 基盤を通じたデータ連携により、EC サイトやコールセンターでも 1 時間ごとの店舗在庫情報が参照可能になりました。 コーナン商事株式会社 佐々木 史人氏 クラウド化にあたっての振り返りとしては、システム部門と異なる専任部署を独立させて、これを主導したことで、大きなスケジュール遅延を回避し、システム部門の通常業務も維持しながら移行を進めることができたとのことです。また、移行準備期間中に有償の AWS セミナーに参加し、クラウドに関する知識を深めたことで、ベンダーとの円滑なコミュニケーションが可能になりました。一方で、社内でのクラウド人財をもう少し確保していれば知見がたまりやすかったことや、移行中の想定外のコスト増加に注意しておくと良かったことも述べられていました。 青山商事株式会社 石塚 正明氏 青山商事株式会社 石塚 正明氏からは、「基幹システムの AWS 移行から始まる DX への挑戦 〜決断から実践、そして未来への展望」と題してお話いただきました。 登壇内容のポイント 高額な保守費用と非効率な運用体制の改善のため、AWS への移行によるシステム刷新を決断した。 複雑な多層構造のシステムがネックだった ため、ゼロベースの要件定義からの再構築を選択した。 AWS 移行後、自社でのシステム理解が進み、データ活用や新技術導入への基盤が整備された。 青山商事株式会社 石塚 正明氏 青山商事株式会社様では、システム保守費用が小売業平均の 3 倍以上かかっていました。これは、複数システムに存在した類似機能、不明瞭なシステム構造、情報システムにかかわる償却や維持費用を積み上げてきたためでした。また、基幹システムがバッチ処理中心である一方、EC システムはリアルタイム処理が必要なため、在庫データを二重に持つなどの非効率な運用を強いられていました。こうした状況から、デジタル化を加速するには、最新のテクノロジーを拡充できる柔軟性と拡張性のあるインフラ環境を獲得した上で、シンプルかつリアルタイムに連携出来るシステムにマイグレーションすべきとの仮説を立て、クラウド環境への移行を前提に、システムのマイグレーションを進める決断をしました。他社クラウドと比較検討した上で保守性・柔軟性・技術者の多さ、そして 小売業からの発祥である点を踏まえて AWS を選定されました。 基幹システムは、メインフレームの COBOL で書かれたシステムを最下層として、その上に Solaris、Red Hat など異なる OS で作られたシステムが重なる多層構造であり、さらに EC システムは 古い OSS パッケージに機能拡張をしていました。しかし、前述した状況を打開し、時々刻々と変化する事業状態を営業、損益、顧客、そして商品視点で見える化するためには、根幹となる基幹システムと機能冗長が著しかった EC システムをシンプルなシステムにする必要がありました。そこで、既存システムベースでの置き換えは断念し、ゼロリセットで要件定義から開発を進める決断をされました。 青山商事株式会社様はオンプレミスの経験しかなく、はたして AWS で構築が出来るのかと不安がありましたが、AWS アカウントチームおよびパートナー会社からのサポートを受けながら社員のリスキリングを行いました。テスト工程時の環境設定等で様々なトラブルはありましたが、2024 年末に移行させることができました。 移行を完了した後に不具合が発生しており完全な安定稼働とは言えない状況ではあるものの、これまでシステムベンダーに丸投げしていた開発について、自社で中身を理解し、開発ベンダーと直接対話できるようになったことは大きな進歩であり、経営層にも世に言われる 2025 年の崖を乗り越えられたと理解を得られています。また、業務フローやデータの使われ方についての理解が深まり、社内にナレッジが蓄積されるようになったとのことです。 AWS に移行したことでデジタル化推進の基盤を整備できた青山商事株式会社様は、 GenU という AWS の生成 AI アプリケーションの利用や Amazon Connect を活用したクラウドベースのコンタクトセンターの運用も行っています。また、アプリケーションのデータを Amazon S3 に蓄積できているため、今後はデータドリブンな経営ができるためのダッシュボードの作成や、OMO 戦略の加速によるシームレスな顧客体験の提供といった新しい取り組みに、AWS とのパートナーシップを活かして挑むとのことです。 株式会社ポーラ・オルビスホールディングス 佐々木 哲哉氏 株式会社ポーラ・オルビスホールディングス 佐々木 哲哉氏からは、「クラウドで拓く基幹システム革新と持続的変革への挑戦」と題してお話いただきました。 登壇内容のポイント モノリシックな基幹システムの技術負債と外部依存が経営リスクとなり、クラウド移行を決断した。 一挙に移行したときの失敗 を踏まえて段階的に移行してコストを削減し、経営層への可視化と理解促進に成功した。 現在は経営戦略と連動したIT戦略として、クラウドネイティブな組織・システム変革を推進している。 株式会社ポーラ・オルビスホールディングス 佐々木 哲哉氏 株式会社ポーラ・オルビスホールディングス様の基幹システムは、EC とリアルな顧客接点を統合し、商品企画から出荷、会計まで一気通貫で支える集中型のモノリシックな構成となっていました。そのため、システムの変化への対応力が著しく低く、アーキテクチャの進化に追従することが困難でした。また、外部ベンダーへの依存度が高く、エンジニアの外注単価の高騰やシステムのブラックボックス化もあり、基幹システムが大きな技術負債となり経営リスクとなっていました。このような課題を放置していると、顧客体験の質も向上せず、外部サービスとの連携も遅れ、企業の競争力を損なう恐れがあると判断し、クラウド移行を決断されました。 株式会社ポーラ・オルビスホールディングス様の AWS 移行は 3 つのフェーズに分けられます。第 1 フェーズでは、2018 年から2019年にかけて、業務とシステムを同時にシンプル化する次世代システムの再構築に挑戦しましたが、この取り組みは頓挫しました。失敗の主な要因は、業務のシンプル化が実現できなかったことによる膨大なコストと長期の開発期間のために事業の戦略案件との同時並行が実現できなかったことでした。また、関係者の意識改革や組織文化の変革が不十分だったこと、経営者の意思決定に必要な具体的な成果や実現可能性を十分に示せなかったことも大きな要因であったと述べられていました。 第 2 フェーズでは、2022 年までにクラウドリフトとリファクタリングによる段階的なクラウド移行を実施しました。このフェーズでは、システム環境の変化による成果を数値で可視化することに重点を置きました。例えば、EC サイトでは受注数が 5 分間で 5 倍以上に跳ね上がるような急激な負荷変動が発生しますが、オンプレミス環境では常時 2 倍の余剰リソースを確保する必要があった一方、クラウドでは必要な時だけリソースを確保できる柔軟性を経営者にも分かりやすく説明されました。クラウドの柔軟性を利用して、オンプレミスよりも少ない費用と短い時間でシステム復旧できることも説明されました。また、一部のシステムではサーバーレスアーキテクチャを採用して機能のリファクタリングを行い、事業戦略案件も実現しました。結果として、移行前と比べて 30% のインフラコスト削減、18% の開発コスト削減、リファクタリングしたシステムは 50% のインフラコスト削減を実現できました。 現在の第 3 フェーズでは、クラウドに移行したシステムのアーキテクチャ刷新に取り組まれています。これは単なる IT システムの変革ではなく、経営戦略と連動した IT 戦略として位置づけられています。具体的には、クラウドネイティブに特化した内製開発組織の構築、システム全体のアーキテクチャ刷新、IT ガバナンスの確立など、「ヒト・モノ・カネ」の各側面から変革を進めています。特に為替変動の影響でクラウドコストが上昇する中、単純なリフトにとどまらず、クラウドネイティブなアーキテクチャーへの移行を通じて、より本質的な変革を目指しています。具体的には開発スピードを 1/2 に、システムコストを 1/3 に抑えることを現実的な目標として進めています。 成果を可視化して経営層をはじめとする組織を味方につけ、組織の成長に合わせた段階的な移行を行い、経営戦略と IT 戦略を連動させるまでに至るステップを踏めているとまとめられました。 パネルディスカッション 各社様の登壇の後、パネルディスカッションを行い、システム移行の実態と今後の展望についてご紹介いただきました。 発言内容のポイント 移行前は基幹システムの再構築範囲や方法の判断に苦心した。 移行中は各社で人材育成とシステム理解に重点的に取り組んだ。 移行後はコスト最適化とデータ活用による価値創造を進めている。 移行前の段階では、各社とも経営層の理解を得ることに大きな苦労はなかったものの、具体的な移行方法の検討で課題に直面しました。特にコーナン商事株式会社様では、COBOL、Oracle、Solarisを使用したバッチ処理主体の基幹システムの機能群をどこまで移行するか、また作り直すかの判断に苦心されました。しかし、最終的には、将来の人材確保のしやすさを新しい技術での再構築を決断しました。 移行作業では、各社それぞれに特徴的な課題がありました。青山商事株式会社様では、現行システムにこだわらずゼロベースでの見直しを実施されました。その中で、古いシステムの多重構造テーブルの解析やシステム間インターフェースの理解に時間をかけられました。また、自社のプロジェクトメンバーの皆さんは AWS から提案を受けたトレーニングの受講や、プロジェクトマネジメントの方法を学び、移行プロジェクトの中で実践されました。学びに時間をかけることそのものが投資であったと述べられました。株式会社ポーラ・オルビスホールディングス様では性能テストでの課題をエンジニアの迅速な対応で克服し、マネージドサービスの活用で開発コストの削減に成功されました。また、コーナン商事様では Oracleから PostgreSQL への移行作業において、SQL の変更や新しいエンジンの学習に取り組まれました。 移行後は、各社ともコスト最適化に取り組んでいます。例えばコーナン商事株式会社様では、 AWS Cost Explorer や AWS 請求コンソール での料金の定期チェック、 Amazon EC2 リザーブドインスタンス の活用、不要リソースの削除など、きめ細かな対策を実施されました。また、青山商事株式会社様ではシステムの内部構造を自社で理解・管理する体制が確立し、株式会社ポーラ・オルビスホールディングス様はクラウドネイティブなアーキテクチャにすることでビジネス側の要求に応えられやすくなり、IT メンバーが成功体験を得られたことなど、組織のレベルアップにも取り組まれました。 今後の展望として、各社ともクラウドを活用した新たな価値創造を目指しています。青山商事株式会社様はシステム間連携の API 化を進め、データドリブンなビジネスモデルへの転換を図り、株式会社ポーラ・オルビスホールディングス様は例えば顧客の声の分析のように、消費者の多様なニーズへの迅速な対応を目指しています。コーナン商事株式会社様は、データレイクを活用した他システムとの連携強化や、店内での顧客向け商品探索サービスの提供を計画されているとのことです。 クラウド移行を単なるシステム基盤の刷新にとどめずに、ビジネス変革の重要な契機とされていることがわかりました。 お客様の声 本セミナー全体の CSAT（お客様満足度）は、4.66 / 5.0 となり、参加されたみなさまにご満足いただけるものであったと考えております。参加者からは、「各社の苦労話が聞けてよかった」「どの企業様も人材の育成に力を入れていることが印象に残った」といった感想をいただきました。 最後に 今回、ご登壇くださった、コーナン商事株式会社 佐々木 史人様、青山商事株式会社 石塚 正明様、株式会社ポーラ・オルビスホールディングス 佐々木 哲哉様 には心から感謝を申し上げます。各社のチャレンジや苦労を乗り越えた先に、ビジネスへの貢献ができていることは、参加された多くの企業様にとって参考になり、クラウド移行の動機を強めることになったと思います。また、本イベントの内容がみなさまのシステム移行の取り組みの一助となれば幸いです。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 5月15日 (木) に「 GenAIOps – 生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現 」というイベントが開催されます。このイベントでは、GenAIOps を実現するための重要な要素である生成 AI オブザーバビリティについて、評価 (evaluation) が中心となるという Eval-Centric AI の考え方の解説とともに、Langfuse と Amazon Bedrock を題材にしたハンズオンワークショップを提供します。昨今の生成 AI 切っても切り離せない GenAIOps に取り組まれる方、興味ある方はぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年5月5日週の主要なアップデート 5/5(月) Amazon ECS introduces 1-click rollbacks for service deployments Amazon Elastic Container Service（Amazon ECS）が、失敗したデプロイメントを簡単に元の安全な状態に戻せる新機能を発表しました。この機能では、 デプロイメントサーキットブレーカー と CloudWatch アラームを使用して、ECSサービスのローリングアップデートに対する自動障害検出と修復を構成できます。これまでは、特定の障害検出メカニズムで検出されないデプロイメント失敗の場合、手動でロールバックトリガーの操作が必要でした。新しい stopDeployment APIを使用することで、ECS が自動的に最後の安定状態にサービスをロールバックします。この機能はすべての AWS リージョンでAWS Management Console、API、SDK、CLIから利用可能です。 Amazon SES now supports IPv6 when calling SES outbound endpoints Amazon Simple Email Service（SES）が送信エンドポイントへの IPv6 接続をサポートし、AWS SDK や CLI を使用する際に IPv4 または IPv6 を選択できるようになりました。これまでは SES の送信エンドポイントへの接続は IPv4 アドレスのみでしたが、環境変数やコマンドライン引数を使ってデュアルスタック接続の設定が可能になり、IPv6 通信への移行が容易になります。 5/6(火) Amazon EBS announces Provisioned Rate for Volume Initialization Amazon Elastic Block Store（Amazon EBS）が、スナップショットからボリュームを作成する際の初期化速度を指定できる「プロビジョンドレート」機能の一般提供を開始しました。この機能により、多数の EC2 インスタンスを同時に起動する場合でも、ボリュームが予測可能な時間内に十分なパフォーマンスを発揮できるようになります。スナップショットからの新規ボリューム作成、AMI からのインスタンス起動、ルートボリューム交換などのシナリオで利用可能で、すべての商用 AWS リージョンで提供されています。なお、プロビジョンドレートを指定する場合は追加料金が発生します。詳細は こちら をご確認ください。 Amazon SageMaker adds support for three new data sources Amazon SageMaker は、Oracle、Amazon DocumentDB、および Microsoft SQL Server データベースへの直接接続をサポートするようになり、Amazon SageMaker Lakehouse で利用可能なデータ統合機能が拡張されました。この機能強化により、お客様はこれらのデータベースからシームレスにデータにアクセスして、ETL フローを構築することができます。 Amazon CloudWatch Network Monitoring adds multi-account support for flow monitors Amazon CloudWatch Network Monitoring で、Flow Monitor を使用して、複数のアカウントにまたがる AWS ワークロードのネットワークパフォーマンスを監視できるようになりました。マルチアカウントサポートにより、ネットワーク管理者は監視が必要なリソースを所有するすべてのアカウントで Flow Monitor を有効にすることができます。そうすることで、複数のアカウントにまたがるワークロードのネットワークパスの可視性が得られます。また、複数のアカウントにまたがる Flow のネットワークパフォーマンスメトリクスを統合的に表示することもできます。 5/7(水) Amazon EC2 R7g instances are now available in additional AWS regions Amazon Elastic Compute Cloud（Amazon EC2）R7g インスタンスが大阪リージョンを含む、６リージョンで新たに利用可能となりました。R7gインスタンス は AWS Graviton2 プロセッサと比較して最大 25% 優れたコンピューティング性能を提供する AWS Graviton3 プロセッサを搭載しています。同等のEC2インスタンスと比較して、同じ性能で最大 60% 少ないエネルギーを使用し、クラウド利用時の環境負荷をより抑えることができます。 Amazon MSK enables seamless certificate renewals on MSK Provisioned clusters Amazon Managed Streaming for Apache Kafka（Amazon MSK）は、MSK プロビジョンドクラスターのすべてにおいて、中断のない証明書の更新を提供するようになりました。Amazon MSK で使用される暗号化証明書は 13ヶ月ごとに更新が必要です。この機能のリリースにより、Amazon MSK プロビジョンドクラスターでの証明書更新は、クライアント接続を中断することなくシームレスに行われるようになりました。 5/8(木) Amazon SQS now supports FIPS 140-3 enabled interface VPC endpoint Amazon SQS は、連邦情報処理標準（FIPS）140-3 プログラムの下で検証された VPC エンドポイントをサポートするようになりました。FIPS 140-3 検証済みの暗号化モジュールを使用した安全な接続を必要とする規制対象のワークロードに対して、AWS PrivateLink と Amazon SQS を簡単に使用できるようになりました。 Amazon RDS for PostgreSQL supports minor versions 17.5, 16.9, 15.13, 14.18, and 13.21 Amazon Relational Database Service (RDS) for PostgreSQL で、最新のマイナーバージョン 17.5、16.9、15.13、14.18、13.21 がサポートされるようになりました。このリリースには、pg_repack 1.5.1、pg_logical 2.4.5などの PostgreSQL 拡張機能の更新も含まれています。 Amazon SageMaker AI enhances Amazon Q Developer with custom code suggestions and workspace context Amazon SageMaker AI Jupyter Lab における Amazon Q Developer の重要な機能強化を発表しました。この強化には、プライベートコードリポジトリに基づくコード提案のカスタマイズと、改善されたコード支援のためにワークスペース全体のコンテキストを含める機能が含まれています。これらの新機能により、組織は独自のコードを活用し、コード提案の関連性を向上させ、最終的に Jupyter Lab 環境内での開発者の生産性とコード品質を向上させることが可能になります。 Amazon Aurora PostgreSQL Limitless Database now supports PostgreSQL 16.8 Amazon Aurora PostgreSQL Limitless Database が PostgreSQL 互換性 バージョン 16.8 が利用可能になりました。このリリースには、 PostgreSQLコミュニティによる製品の改善とバグ修正 に加え、ltree 拡張機能、btree_gist 拡張機能のサポート、クエリパフォーマンスの向上などの Aurora Limitless 固有の追加機能が含まれています。 5/9(金) Amazon SageMaker HyperPod now integrates with Amazon EventBridge to deliver status change events Amazon SageMaker HyperPodがAmazon EventBridgeと統合され、クラスターのステータス変更についてほぼリアルタイムの通知を受け取ることが可能になりました。SageMaker HyperPodは、EventBridge を通じて2種類の通知を提供します。1つ目は、HyperPod クラスターが InService や Failed などの状態間で遷移する際に通知するクラスターステータス変更イベント、2つ目は、ノードの健全性ステータス（健全/不健全など）が変更された場合や、障害からの回復中に自動的に置き換えられた場合に通知するノード健全性イベントです。これらのイベントが発生した際に自動アクションをトリガーする簡単な EventBridge ルールを作成することもできます。 Amazon VPC Reachability Analyzer now supports resource exclusion Amazon VPC Reachability Analyzer が、送信元とあて先間の到達性分析時にネットワークリソースを除外する機能をサポートするようになり、到達性分析をより柔軟に実行できるようになりました。例えば、インターネットゲートウェイからElastic Network Interface（ENI）への、ネットワークファイアウォールによる検査を通過しないパスを特定したい場合、リソース除外でNetwork Firewallを指定して到達性分析を実行できます。分析の結果、到達可能なパスが見つかった場合、ネットワーク内に代替パスが存在することがわかり、必要な対策を講じることができます。 暑くなったり、寒くなったりと不安定な気候が続いていますので、体調管理に気をつけてお過ごしください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は、2025/5/9 に公開された Accelerate lightweight analytics using PyIceberg with AWS Lambda and an AWS Glue Iceberg REST endpoint を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 データインサイトに基づき決定を行う現代の組織にとって、効果的なデータ管理は、高度な分析と効率的な機械学習の利用を実現するための重要な要素です。データ利用のユースケースがより複雑になるにつれ、データエンジニアリングチームには、複数のデータソースやアプリケーション全体でのバージョン管理、増加するデータ量、スキーマ変更に対処するための高度なツールが必要になります。 Apache Iceberg は、データレイクで人気の選択肢となっています。ACID (原子性、一貫性、独立性、永続性) トランザクション、スキーマ進化、タイムトラベル機能を提供します。Iceberg テーブルは、Apache Spark や Trino などの様々な分散データ処理フレームワークからアクセスできるため、多様なデータ処理のニーズに対して柔軟なソリューションとなります。そのような Iceberg を扱うためのツールの中で、 PyIceberg は分散コンピューティングリソースを必要とせずに、Python スクリプト上でテーブルのアクセスと管理を可能にします。 この投稿では、 AWS Glue Data Catalog と AWS Lambda と統合された PyIceberg が、直感的な Python インターフェースを通じて Iceberg の強力な機能を活用するための軽量なアプローチを提供する方法を示します。この統合により、チームはほとんどセットアップやインフラストラクチャの依存関係の設定を行わずとも Iceberg テーブルの操作や利用を開始できることを説明します。 PyIceberg の主要機能と利点 PyIceberg の主な利点の 1 つは、軽量であることです。分散コンピューティングフレームワークを必要とせず、チームは Python アプリケーションから直接テーブル操作を実行できるため、学習曲線が小さく、小規模から中規模のデータ探索と分析に適しています。さらに、PyIceberg は Pandas や Polars などの Python データ分析ライブラリと統合されているため、データユーザーは既存のスキルとワークフローを活用できます。 PyIceberg を Data Catalog と Amazon Simple Storage Service (Amazon S3) で使用すると、データチームはテーブルを完全にサーバーレスな環境で利用および管理できます。つまり、データチームはインフラストラクチャの管理ではなく、分析と洞察に集中することができます。 さらに、PyIceberg を通じて管理される Iceberg テーブルは、AWS のデータ分析サービスと互換性があります。PyIceberg は単⼀ノードで動作するため、⼤量のデータを扱う場合は性能に制限がありますが、 Amazon Athena や AWS Glue などのサービスを使えば、同じテーブルをより大規模に効率的に処理できます。これにより、チームは PyIceberg を使って迅速な開発とテストを行い、その後、データ管理アプローチの一貫性を維持しながら、より大規模な処理エンジンを使った本番ワークロードにシームレスに移行できます。 代表的なユースケース 次のようなシナリオでは、PyIceberg が特に役立ちます: データサイエンスの実験と特徴量エンジニアリング – データサイエンスでは、信頼できる効率的な分析とモデルを維持するために、実験の再現性が重要です。しかし、組織のデータが継続的に更新されるため、重要なビジネスイベント、モデル学習、一貫した参照のためのデータスナップショットを管理することが難しくなります。データサイエンティストは、タイムトラベル機能を使ってデータの過去のスナップショットを照会し、 タグ付け機能 を使って重要なバージョンを記録できます。PyIceberg を使えば、Pandas などの馴染みのあるツールを使って Python 環境でこれらの利点を得られます。Iceberg の ACID 特性のおかげで、テーブルが積極的に更新されている場合でも整合性を担保したデータアクセスが可能になります。 AWS Lambda によるサーバーレスデータ処理 – 組織は多くの場合、複雑なインフラストラクチャを管理せずに、データを効率的に処理し、分析テーブルを維持する必要があります。PyIceberg と Lambda を使えば、チームはサーバーレスな Lamnba 関数を使ってイベント駆動のデータ処理やスケジュールされたテーブル更新を構築できます。PyIceberg の軽量な性質は、サーバーレス環境に適しており、データ検証、変換、取り込みなどのシンプルなデータ処理タスクを可能にします。これらのテーブルは、さまざまな AWS サービスを通じて更新と分析の両方にアクセスできるため、チームはサーバーやクラスターを管理せずに効率的なデータパイプラインを構築できます。 PyIceberg を使用したイベント駆動のデータ取り込みと分析 このセクションでは、 NYC yellow taxi trip data を使用して、PyIceberg によるデータ処理と分析の実践的な例を探ります。リアルタイムのタクシー走行記録の処理をシミュレートするために、Lambda を使用してサンプルデータを Iceberg テーブルに挿入します。この例では、効率的なデータ取り込みと柔軟な分析機能を組み合わせることで、ワークフローをより合理的なものにする方法を示します。 チームが次のような複数の要件対応する必要がある場面を想像してください: データ処理ソリューションは、中規模のデータセットを処理するケースで分散コンピューティングクラスターの管理の複雑さを避けるため、コストパフォーマンスが良く、メンテナンス性が高い必要があります。 アナリストは、Python のツールを使って柔軟なクエリと探索を行えるようにする必要があります。例えば、過去のスナップショットと現在のデータを比較して、時間の経過に伴うトレンドを分析する必要があるかもしれません。 ソリューションは、将来的により拡張性の高いものにする能力を持つ必要があります。 これらの要件に対処するため、PyIceberg で動作する Lambda によるデータ処理と Jupyter ノートブックによる分析を組み合わせたソリューションを実装します。このアプローチにより、データの整合性を維持しながら柔軟な分析ワークフローを可能にする、軽量でありながら堅牢なアーキテクチャが実現されます。ウォークスルーの最後では、Athena を使用してこのデータを照会し、複数の Iceberg 対応ツールとの互換性を示すとともに、このアーキテクチャのスケール性を示します。 大まかな手順は以下の通りです: Lambda を使用して、 AWS Glue Iceberg REST エンドポイント 経由で PyIceberg を利用し、サンプルの NYC yellow taxi trip data を Amazon S3 上の Iceberg テーブルに書き込みます。実際のシナリオでは、この Lambda 関数は Amazon Simple Queue Service (Amazon SQS) などのキューイングコンポーネントからのイベントによってトリガーされます。詳細は、 Lambda と Amazon SQS の併用 を参照してください。 Jupyter ノートブックで AWS Glue Iceberg REST エンドポイントを経由して PyIceberg を使用し、テーブルデータを分析します。 Athena を使用してデータをクエリし、Iceberg の柔軟性を実証します。 次の図はアーキテクチャを示しています。 このアーキテクチャを実装する際に重要になる点は、Lambda 関数がイベントによってトリガーされると、複数の同時実行が発生する可能性があることです。この同時実行により、Iceberg テーブルへの書き込み時にトランザクション競合が発生する可能性があります。これを処理するには、適切な再試行メカニズムを実装し、トランザクション分離レベルを慎重に管理する必要があります。Amazon SQS をイベントソースとして使用する場合は、 SQS イベントソースの最大同時実行設定 を使って同時実行を制御できます。 前提条件 このユースケースには、次の前提条件が必要です。 Lambda、AWS Glue、Amazon S3、Athena、および AWS CloudFormation へのアクセスを提供するアクティブな AWS アカウント。 CloudFormation スタックを作成およびデプロイする権限。詳細については、 自己管理権限を使用した CloudFormation StackSets の作成 を参照してください。 AWS CloudShell とその機能に対する完全なアクセス権を持つユーザー。詳細については、 AWS CloudShell の概要 を参照してください。 AWS CloudFormation によるリソースのセットアップ 次の CloudFormation テンプレートを使用して、以下のリソースをセットアップできます: Iceberg テーブルのメタデータとデータファイルを格納する S3 バケット Amazon Elastic Container Registry (Amazon ECR) のリポジトリ (Lambda 関数のコンテナイメージを格納) テーブルを格納するデータカタログデータベース Amazon SageMaker AI の ノートブックインスタンス (Jupyter ノートブック環境用) Lambda 関数と SageMaker AI ノートブックインスタンス用の AWS Identity and Access Management (IAM) ロール 次の手順に従ってリソースをデプロイしてください。 Launch stack を選択します。 スタックの パラメータ では、データベース名として　 pyiceberg_lambda_blog_database がデフォルトで設定されています。デフォルト値を変更することもできます。データベース名を変更した場合は、以降のすべてのステップで pyiceberg_lambda_blog_database を選択した名前に置き換えることを忘れないでください。次に、 次へ を選択します。 次へ を選択します。 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します を選択します。 送信 を選択します。 Lambda 関数の構築と実行 PyIceberg を使って着信レコードを処理する Lambda 関数を構築しましょう。この関数は、Data Catalog の pyiceberg_lambda_blog_database データベース内に nyc_yellow_table という Iceberg テーブルが存在しない場合に新規でテーブルを作成します。次に、サンプルの NYC yellow taxi trip data を生成して、レコードをシミュレートし、 nyc_yellow_table に挿入します。 この例では、この関数を手動で呼び出していますが、実際のシナリオでは、この Lambda 関数は Amazon SQS からのメッセージなどの実際のイベントによってトリガーされます。実際のユースケースを実装する際は、関数コードをイベントデータを受け取り、要件に基づいて処理するように変更する必要があります。 コンテナイメージをデプロイパッケージとして使用して、この関数をデプロイします。ここではコンテナイメージから Lambda 関数を作成するために、CloudShell でイメージをビルドし、ECR リポジトリにプッシュします。以下の手順を実行してください。 AWS マネジメントコンソール にサインインし、 CloudShell を起動 します。 作業ディレクトリを作成します。 mkdir pyiceberg_blog cd pyiceberg_blog Lambda スクリプト lambda_function.py をダウンロードします。 aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-5013/lambda_function.py . このスクリプトは以下のタスクを実行します: Data Catalog に NYC yellow taxi trip data のスキーマを持つ Iceberg テーブルを作成します ランダムな NYC yellow taxi trip data にもとづくデータセットを生成します このデータをテーブルに挿入します この Lambda 関数の重要な部分を掘り下げてみましょう: Iceberg カタログの構成 – 次のコードは、AWS Glue Iceberg REST エンドポイントに接続する Iceberg カタログを定義しています: # Configure the catalog catalog_properties = { "type": "rest", "uri": f"https://glue.{region}.amazonaws.com/iceberg", "s3.region": region, "rest.sigv4-enabled": "true", "rest.signing-name": "glue", "rest.signing-region": region } catalog = load_catalog(**catalog_properties) テーブルスキーマ定義 – 次のコードは、NYC taxi データセットの Iceberg テーブルスキーマを定義しています。このテーブルには以下が含まれています。 Schema で定義されたスキーマのカラム vendorid と tpep_pickup_datetime による パーティショニング (PartitionSpec を使用) tpep_pickup_datetime に適用された day 変換 tpep_pickup_datetime と tpep_dropoff_datetime による ソートオーダー タイムスタンプ列に day 変換を適用する際、Iceberg は階層的に日付ベースのパーティション分割を自動的に処理します。つまり、単一の day 変換で、年、月、日のレベルでパーティションプルーニングを可能にするため、各レベルに明示的な変換を必要としません。Iceberg のパーティション分割の詳細については、 パーティション分割 を参照してください。 # Table Definition schema = Schema( NestedField(field_id=1, name="vendorid", field_type=LongType(), required=False), NestedField(field_id=2, name="tpep_pickup_datetime", field_type=TimestampType(), required=False), NestedField(field_id=3, name="tpep_dropoff_datetime", field_type=TimestampType(), required=False), NestedField(field_id=4, name="passenger_count", field_type=LongType(), required=False), NestedField(field_id=5, name="trip_distance", field_type=DoubleType(), required=False), NestedField(field_id=6, name="ratecodeid", field_type=LongType(), required=False), NestedField(field_id=7, name="store_and_fwd_flag", field_type=StringType(), required=False), NestedField(field_id=8, name="pulocationid", field_type=LongType(), required=False), NestedField(field_id=9, name="dolocationid", field_type=LongType(), required=False), NestedField(field_id=10, name="payment_type", field_type=LongType(), required=False), NestedField(field_id=11, name="fare_amount", field_type=DoubleType(), required=False), NestedField(field_id=12, name="extra", field_type=DoubleType(), required=False), NestedField(field_id=13, name="mta_tax", field_type=DoubleType(), required=False), NestedField(field_id=14, name="tip_amount", field_type=DoubleType(), required=False), NestedField(field_id=15, name="tolls_amount", field_type=DoubleType(), required=False), NestedField(field_id=16, name="improvement_surcharge", field_type=DoubleType(), required=False), NestedField(field_id=17, name="total_amount", field_type=DoubleType(), required=False), NestedField(field_id=18, name="congestion_surcharge", field_type=DoubleType(), required=False), NestedField(field_id=19, name="airport_fee", field_type=DoubleType(), required=False), ) # Define partition spec partition_spec = PartitionSpec( PartitionField(source_id=1, field_id=1001, transform=IdentityTransform(), name="vendorid_idenitty"), PartitionField(source_id=2, field_id=1002, transform=DayTransform(), name="tpep_pickup_day"), ) # Define sort order sort_order = SortOrder( SortField(source_id=2, transform=DayTransform()), SortField(source_id=3, transform=DayTransform()) ) database_name = os.environ.get('GLUE_DATABASE_NAME') table_name = os.environ.get('ICEBERG_TABLE_NAME') identifier = f"{database_name}.{table_name}" # Create the table if it doesn't exist location = f"s3://pyiceberg-lambda-blog-{account_id}-{region}/{database_name}/{table_name}" if not catalog.table_exists(identifier): table = catalog.create_table( identifier=identifier, schema=schema, location=location, partition_spec=partition_spec, sort_order=sort_order ) else: table = catalog.load_table(identifier=identifier) データの生成と挿入 – 次のコードはランダムなデータを生成し、テーブルに挿入します。この例では、ビジネスイベントやトランザクションを追跡するために、新しいレコードが継続的に追加される append-only のパターンを想定しています。 # Generate random data records = generate_random_data() # Convert to Arrow Table df = pa.Table.from_pylist(records) # Write data using PyIceberg table.append(df) Dockerfile をダウンロードします。これは、Lambda 関数のコンテナイメージを定義します。 aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-5013/Dockerfile . requirements.txt をダウンロードします。これは、Lmbmda 関数に必要な Python パッケージを定義しています。 aws s3 cp s3://aws-blogs-artifacts-public/artifacts/BDB-5013/requirements.txt . この時点で、作業ディレクトリには次の 3 つのファイルが含まれているはずです。 Dockerfile lambda_function.py requirements.txt 環境変数を設定します。 を自分の AWS アカウント ID に置き換えてください: export AWS_ACCOUNT_ID= <account_id> Docker イメージをビルドします: docker build --provenance=false -t localhost/pyiceberg-lambda . # Confirm built image docker images | grep pyiceberg-lambda イメージにタグを設定します: docker tag localhost/pyiceberg-lambda:latest ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/pyiceberg-lambda-repository:latest AWS CloudFormation によって作成された ECR リポジトリにログインします: aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com イメージを ECR リポジトリにプッシュします: docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/pyiceberg-lambda-repository:latest Amazon ECR にプッシュしたコンテナイメージを使用して、Lambda 関数を作成します: aws lambda create-function \ --function-name pyiceberg-lambda-function \ --package-type Image \ --code ImageUri=${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/pyiceberg-lambda-repository:latest \ --role arn:aws:iam::${AWS_ACCOUNT_ID}:role/pyiceberg-lambda-function-role-${AWS_REGION} \ --environment "Variables={ICEBERG_TABLE_NAME=nyc_yellow_table, GLUE_DATABASE_NAME=pyiceberg_lambda_blog_database}" \ --region ${AWS_REGION} \ --timeout 60 \ --memory-size 1024 次のセクションで確認するため、少なくとも 5 回関数を呼び出して複数のスナップショットを作成してください。今回は手動で関数を呼び出してイベント駆動型のデータ取り込みをシミュレートしていますが、実際のシナリオでは Lambda 関数がイベント駆動型で自動的に呼び出されます。 aws lambda invoke \ --function-name arn:aws:lambda:${AWS_REGION}:${AWS_ACCOUNT_ID}:function:pyiceberg-lambda-function \ --log-type Tail \ outputfile.txt \ --query 'LogResult' | tr -d '"' | base64 -d ここまでで、Lambda 関数をデプロイして実行しました。この関数は、 pyiceberg_lambda_blog_database データベース内に nyc_yellow_table Iceberg テーブルを作成します。また、このテーブルにサンプルデータを生成して挿入します。後の手順で、このテーブルのレコードを確認します。 コンテナを使用した Lambda 関数の構築に関する詳細情報は、 コンテナイメージを使用した Lambda 関数の作成 をご覧ください。 Jupyter を使った PyIceberg によるデータ探索 このセクションでは、Data Catalog に登録された Iceberg テーブルのデータにアクセスし、分析する方法を示します。PyIceberg を使用した Jupyter ノートブックから、Lambda 関数によって作成されたタクシー運行データにアクセスし、新しいレコードが到着するたびに作成される異なるスナップショットを検査します。また、重要なスナップショットにタグを付けて保持し、さらなる分析のために新しいテーブルを作成します。 SageMaker AI ノートブックインスタンスで Jupyter を使ってノートブックを開くには、次の手順を実行してください。 SageMaker AI コンソールで、ナビゲーションペインから Notebooks を選択します。 CloudFormation テンプレートを使用して作成したノートブックインスタンスの横にある Open JupyterLab を選択します。 ノートブック をダウンロードし、SageMaker AI ノートブックの Jupyter 環境で開いてください。 アップロードした pyiceberg_notebook.ipynb を開きます。 カーネル選択のダイアログでは、デフォルトのオプションのままにして Select を選択します。 ここからは、セルを順番に実行してノートブックを進めていきます。 カタログへの接続とテーブルのスキャン PyIceberg を使用して Iceberg テーブルにアクセスできます。次のコードは、AWS Glue Iceberg REST エンドポイントに接続し、 pyiceberg_lambda_blog_database データベース上の nyc_yellow_table テーブルを読み込みます。 import pyarrow as pa from pyiceberg.catalog import load_catalog import boto3 # Set AWS region sts = boto3.client('sts') region = sts._client_config.region_name # Configure catalog connection properties catalog_properties = { "type": "rest", "uri": f"https://glue.{region}.amazonaws.com/iceberg", "s3.region": region, "rest.sigv4-enabled": "true", "rest.signing-name": "glue", "rest.signing-region": region } # Specify database and table names database_name = "pyiceberg_lambda_blog_database" table_name = "nyc_yellow_table" # Load catalog and get table catalog = load_catalog(**catalog_properties) table = catalog.load_table(f"{database_name}.{table_name}") Iceberg テーブルからフルデータを Apache Arrow テーブルとしてクエリし、 Pandas の DataFrame に変換できます。 スナップショットの操作 Iceberg の重要な機能の 1 つがスナップショットベースのバージョン管理です。スナップショットは、テーブルのデータに変更があるたびに自動的に作成されます。次の例のように、特定のスナップショットからデータを取得できます。 # Get data from a specific snapshot ID snapshot_id = snapshots.to_pandas()["snapshot_id"][3] snapshot_pa_table = table.scan(snapshot_id=snapshot_id).to_arrow() snapshot_df = snapshot_pa_table.to_pandas() スナップショットに基づいて、任意の時点の過去のデータと現在のデータを比較できます。この場合、最新のテーブルとスナップショットテーブルの間のデータ分布の違いを比較しています。 # Compare the distribution of total_amount in the specified snapshot and the latest data. import matplotlib.pyplot as plt plt.figure(figsize=(4, 3)) df['total_amount'].hist(bins=30, density=True, label="latest", alpha=0.5) snapshot_df['total_amount'].hist(bins=30, density=True, label="snapshot", alpha=0.5) plt.title('Distribution of total_amount') plt.xlabel('total_amount') plt.ylabel('relative Frequency') plt.legend() plt.show() スナップショットのタグ付け 特定のスナップショットに任意の名前を付けてタグ付けし、後でその名前で特定のスナップショットを取得できます。これは、重要なイベントのスナップショットを管理する際に便利です。 この例では、checkpointTag タグを指定してスナップショットへクエリをしています。ここでは polars を使用して、既存のカラム tpep_dropoff_datetime と tpep_pickup_datetime に基づいて trip_duration という新しいカラムを追加することで、新しい DataFrame を作成しています。 # retrive tagged snapshot table as polars data frame import polars as pl # Get snapshot id from tag name df = table.inspect.refs().to_pandas() filtered_df = df[df["name"] == tag_name] tag_snapshot_id = filtered_df["snapshot_id"].iloc[0] # Scan Table based on the snapshot id tag_pa_table = table.scan(snapshot_id=tag_snapshot_id).to_arrow() tag_df = pl.from_arrow(tag_pa_table) # Process the data adding a new column "trip_duration" from check point snapshot. def preprocess_data(df): df = df.select(["vendorid", "tpep_pickup_datetime", "tpep_dropoff_datetime", "passenger_count", "trip_distance", "fare_amount"]) df = df.with_columns( ((pl.col("tpep_dropoff_datetime") - pl.col("tpep_pickup_datetime")) .dt.total_seconds() // 60).alias("trip_duration")) return df processed_df = preprocess_data(tag_df) display(processed_df) print(processed_df["trip_duration"].describe()) 処理済みの DataFrame から trip_duration 列を使って新しいテーブルを作成します。このステップは、将来の分析のためにデータを準備する方法を示しています。基になるテーブルが変更されていても、タグを使うことで、処理済みデータが参照しているデータのスナップショットを明示的に指定できます。 # write processed data to new iceberg table account_id = sts.get_caller_identity()["Account"] new_table_name = "processed_" + table_name location = f"s3://pyiceberg-lambda-blog-{account_id}-{region}/{database_name}/{new_table_name}" pa_new_table = processed_df.to_arrow() schema = pa_new_table.schema identifier = f"{database_name}.{new_table_name}" new_table = catalog.create_table( identifier=identifier, schema=schema, location=location ) # show new table's schema print(new_table.schema()) # insert processed data to new table new_table.append(pa_new_table) 処理済みデータから作成した新しいテーブルを Athena でクエリし、Iceberg テーブルの相互運用性を実証しましょう。 Amazon Athena からのデータクエリ 前のセクションのノートブックから作成された pyiceberg_lambda_blog_database.processed_nyc_yellow_table テーブルを、 Athena クエリエディタ でクエリできます: SELECT * FROM "pyiceberg_lambda_blog_database"."processed_nyc_yellow_table" limit 10 ; これらのステップを通して、Lambda と AWS Glue Iceberg REST エンドポイントを使用したサーバーレスのデータ処理ソリューションを構築し実際に利用する流れを体験しました。また、PyIceberg を使用してスナップショット管理やテーブル操作を含む Python によるデータ管理と分析を行いました。さらに、別のエンジンである Athena を使用してクエリを実行し、Iceberg テーブルの互換性を示しました。 クリーンアップ この記事で使用したリソースをクリーンアップするには、次の手順を実行してください。 Amazon ECR コンソールで、リポジトリ pyiceberg-lambda-repository に移動し、リポジトリ内のすべてのイメージを削除します。 CloudShell で、作業ディレクトリ pyiceberg_blog を削除します。 Amazon S3 コンソールで、CloudFormation テンプレートを使用して作成した S3 バケット pyiceberg-lambda-blog- - に移動し、バケットを空にします。 リポジトリとバケットが空になったことを確認したら、CloudFormation スタック pyiceberg-lambda-blog-stack を削除します。 Docker イメージを使用して作成した Lambda 関数 pyiceberg-lambda-function を削除します。 結論 この記事では、AWS Glue Data Catalog と PyIceberg を使用することで、堅牢なデータ管理機能を維持しながら、効率的で軽量なデータワークフローを実現できることを示しました。チームがインフラストラクチャの依存関係を最小限に抑えながら、Iceberg の強力な機能を活用できることを紹介しました。このアプローチにより、組織は分散コンピューティングリソースのセットアップや管理の複雑さなしに、すぐに Iceberg テーブルの利用を開始できます。 Iceberg の機能を低いハードルで導入しようとしている組織にとって、これは特に価値があります。PyIceberg の軽量な性質により、チームはすぐに Iceberg テーブルを使い始めることができ、慣れ親しんだツールを使用し、追加の学習を最小限に抑えることができます。データニーズが高まれば、同じ Iceberg テーブルを Athena や AWS Glue などの AWS 分析サービスからシームレスにアクセスでき、将来的なスケーラビリティへの明確なパスが提供されます。 PyIceberg と AWS の分析サービスの詳細については、 PyIceberg のドキュメント と Apache Iceberg とは? を参照することをお勧めします。 著者について Sotaro Hikita は、AWS でアナリティクスに特化したスペシャリストソリューションアーキテクトで、ビッグデータ技術とオープンソースソフトウェアを扱っています。仕事以外では、いつも美味しい食べ物を探し求め、最近はピザに夢中になっています。 Shuhei Fukami は、AWS におけるアナリティクスに特化したスペシャリストソリューションアーキテクトです。趣味で料理をするのが好きで、最近はピザ作りにはまっています。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2025 年 3 月のアップデートまとめ はお読みいただけましたでしょうか。今月も アップデート 情報を中心に以下の内容をお届けします。皆さまのお役に立つ内容がございましたら幸いです！ 注目のアップデートについて 2025 年 4 月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートについて #1: ダッシュボードがエージェント階層を使用したアクセス制御をサポート Amazon Connect Contact Lens ダッシュボードが、特定のエージェント階層に基づいてきめ細かなアクセス制御を実施するコンタクトセンター管理者向けの機能をサポートするようになりました。ユーザーに階層を割り当てると、ユーザーが所属する組織グループを定義でき、きめ細かなアクセス制御を有効にすると、自身の階層内または特定の割り当てられた階層内のエージェントのメトリクスのみを表示できるようにすることができます。たとえば、チームの階層グループとレベルを設定すると、そのチーム内の階層グループに割り当てられたユーザーのみが、そのエージェントのメトリクスを表示できるようになるため、スーパーバイザーは、自チームのエージェントのメトリクスだけを表示できます。 セキュリティプロファイルのアクセスコントロールで“階層ベースのアクセスコントロール”を選択し、リソースに“ユーザー”、ターゲティングに“割り当てられたユーザー階層”(階層内のユーザーを表示) または “カスタムのユーザー階層”(特定の階層内のユーザーを表示)を指定することで、エージェント階層に基づいた、ダッシュボード、リアルタイムメトリクス、履歴メトリクスの表示を制御することが可能です。制御可能なリソースはユーザーのみサポートされています。詳細は管理者ガイドを参照してください。 関連リンク 管理者ガイド リリースノート 2. 2025年4月のアップデート一覧 Amazon Connect がエージェントスケジュールの管理者アクセスを開始 – 2025/04/30 Amazon Connect では、管理者にエージェントスケジュールへのアクセス権を付与できるようになりました。今回のローンチにより、スケジュール管理者をすべてのスタッフグループにスーパーバイザーとして追加することなく、特定のユーザーに対して公開済みのエージェントスケジュールへのアクセス権を付与できるようになりました。たとえば、一元管理されたスケジューラーや監査担当者など、組織全体のエージェントスケジュールを幅広く把握する必要があるユーザーに、数回クリックするだけでこのアクセス権を付与できるようになりました。これにより、アクセス管理に費やす時間が短縮され、業務効率が向上します。  関連リンク 管理者ガイド Amazon Connect でエージェントスケジュールを一括削除できるようになりました  – 2025/04/30 Amazon Connect では、エージェントスケジュールを一括削除できるようになり、エージェントスケジュールの日々の管理がより効率的になりました。今回のアップデートにより、1 日単位で最大 400 人のエージェント、1 人の場合は最大 30 日間のスケジュールを削除できるようになりました。たとえば、コンタクトセンターのクローズにあわせて翌週の月曜日のスケジュールをすべて削除したり、組織に所属しなくなったエージェントの今後のシフトを一括して削除することが可能になります。一括削除により、マネージャーはエージェントのシフトスケジュールを 1 日ずつ削除する必要がなくなり、エージェントスケジュールの管理に費やす時間が短縮されるため、マネージャーの生産性が向上します。  関連リンク 管理者ガイド お客様の AI 導入を加速するための MAP の強化  – 2025/04/30 モダナイゼーションの取り組みを加速し、お客様の AI の採用を促進するために、以下の2 つの主要機能によりAWS 移行アクセラレーションプログラム (MAP) が強化されました。 1つ目は、Amazon Bedrock と Amazon SageMaker を特徴とする新しい「AI への移行」モダナイゼーションパスウェイです。このパスウェイにより、測定可能なビジネス価値をもたらす実証済みの AI パターンを使用して、お客様が既存のアプリケーションやビジネスプロセスを変革できるよう支援できます。 2つ目として、Amazon Connect は MAP モダナイゼーション戦略的パートナーインセンティブ (SPI) の対象サービスになりました。これにより、エージェントの生産性を高め、カスタマーエクスペリエンスを向上させる AI を活用した機能により、顧客がコンタクトセンターを変革できるよう支援できます。 これらにより、顧客の AI 変革を主導し、コンタクトセンターの近代化を推進する能力が強化されます。 関連リンク AWS Partner Funding Benefits Program Guide MAP Modernization SPI Eligible Services Amazon Connect エージェントワークスペースが、問い合わせ関連のアクションを含むサードパーティアプリケーション向けの機能を拡張 – 2025/04/25 Amazon Connect エージェントワークスペースは、アウトバウンドコールの発信、コンタクトの応答、転送、クリア、エージェントステータスの更新など、サードパーティアプリケーションの追加機能をサポートするようになりました。これらの機能強化により、エージェントがより直感的なワークフローを実現するアプリケーションを統合できるようになりました。例えば、 createOutboundCall API を使用して、最新のコンタクト一覧を表示するカスタムメイドの通話履歴インターフェイスから、エージェントがワンクリックでアウトバウンドコールを行う Click to Call 機能を実装できるようになります。今回新たにサポートされた API の詳細情報は以下を参照してください。 関連リンク 管理者ガイド API リファレンス Amazon Connect Cases にケースに関するサービスレベル契約を管理するためのサポートが追加 – 2025/04/18 Amazon Connect Cases に、コンタクトセンターがケースのサービスレベル契約 (SLA) を追跡、管理する機能が追加されました。管理者は、Amazon Connect の管理コンソール上で、ケース属性に基づいて SLA ルールを設定し、目標とするケースの解決までの時間を設定できるようになりました。エージェントとマネージャーはケース一覧で各ケースの SLA 状況をリアルタイムで確認できるため、緊急性の高い作業から優先的に対応することができます。また、管理者は SLA が守られない場合にケースを自動的にエスカレーションしたり、別のチームにケースを転送するルールを作成できます。たとえば、「重要度の高いケースは4時間以内に確認し、24時間以内に解決する」といった目標を設定し、その達成状況を管理することができます。これにより、企業はサービス品質の維持・向上に取り組みやすくなりました。 ルール設定画面で、 ① ケース作成時にサービスレベルを割り当てるルールを作成 し、作成したルールをもとに ② サービルレベルに抵触した場合の検知、通知、エスカレーションを行うルールを作成 することが可能です。サービスレベルが割り当てられたケースは ③エージェントワークスペースの“Next SLA Branch”カラムで SLA の状況を確認することが可能 です。  関連リンク 管理者ガイド Amazon Connect Contact Lens ダッシュボードがエージェント階層を使用したアクセス制御をサポート開始 – 2025/04/18 注目アップデート #1 をご覧ください！ Amazon Connect がコンタクトフローで音声や言語を動的に設定する機能を提供開始 – 2025/04/10 Amazon Connect では、音声ボットと自動音声応答 (IVR) で使用されるテキスト読み上げ (TTS) の音声、言語、話し方を動的に設定できるようになりました。これらの新機能を利用することで、よりパーソナライズされたエクスペリエンスをエンドカスタマーごとに提供することが可能になります。例えば、 顧客プロファイル で設定した主な使用言語に基づいて、希望する音声を動的に設定できます。これらの新機能は、 Amazon Connect フロー の [ 音声の設定 ] ブロックで設定が可能であり、ドラッグアンドドロップのフローデザイナーまたはパブリック API で設定できます。 関連リンク 管理者ガイド Amazon Connect でスーパーバイザーが進行中のチャットで追加のアクションを実行可能に – 2025/04/03 Amazon Connect では、スーパーバイザーが進行中のチャットで Amazon Connect UI から直接追加のアクションを実行できるようになりました。これにより、問題解決が加速され、顧客満足度が向上します。例えば、スーパーバイザーは、非アクティブな顧客とのチャットを終了したり、特定のエージェントやキューにチャットを再割り当てしたりできるようになりました。  関連リンク 管理者ガイド Amazon Connect が追加の Dual-Tone Multi-Frequency (DTMF) 構成設定のサポートを開始 – 2025/04/02 Amazon Connect では、発信者がキーパッドボタンを押す間にシステムが待機する秒数をカスタマイズできるようになりました。これにより、自動音声応答 (IVR) システムでのユーザー入力を最適化できます。管理者は以前は5秒に固定されていたこの待機時間を 1 秒から 20 秒の間で調整できるようになりました。たとえば、銀行の IVR フローでは、口座番号入力の桁間タイムアウトを長く設定できます。これは、数字を押す間隔が長くなる場合がある顧客に役立ちます。さらに、既存の 2 つの設定である [最大桁数] と [最初の入力までのタイムアウト] を変数を使用して動的に設定できるようになったため、管理者は IVR フローをより柔軟に設計できます。この柔軟性の向上により、特定のユースケースに合わせて IVR システムを最適化し、ユーザーエクスペリエンスとシステム効率を向上させることができます。  関連リンク 管理者ガイド Amazon Connect でエージェントの作業スケジュールへの遵守状況がカレンダービューに表示されるように – 2025/04/02 Amazon Connect では、スーパーバイザーがエージェントのスケジュール遵守状況をカレンダービューで簡単に監視できるようになりました。今回のリリースにより、スーパーバイザーは、過去 90 日間までの遵守違反をエージェント別、日別にシフトと一緒に視覚化できるようになりました。これには、最小限の遵守違反を除外する機能も含まれます。この視覚化により、スーパーバイザーはチーム全体の遵守違反を即座に発見し、最も重要なインシデントに優先順位を付け、過去のエージェントの行動と比較し、該当エージェントの懸念に対処するための措置を講じることができます。たとえば、スーパーバイザーは、エージェントが休憩や昼食後に常に遅刻するパターンに気づいた場合、さらに調査して、ネットワークの問題、機器の問題、適時性への期待など、対処する必要のある根本的な問題があるかどうかを判断できます。  関連リンク 管理者ガイド Amazon Connect Contact Lens で感情分析の有効化および無効化をサポート – 2025/04/01 Amazon Connect Contact Lens で感情分析の有効・無効化を制御できるようになりました。これにより、コンプライアンス義務を果たす必要がある組織は、トランスクリプト、生成 AI の要約、その他の会話インサイトなど、Contact Lens の他の会話分析機能を引き続き利用しながら、感情分析を制御することができます。例えば、ブランドに対する顧客の認識の追跡では感情分析を有効にし、社内の苦情対応窓口では利用者の感情分析を無効にすることができます。  関連リンク 管理者ガイド Amazon Connect Contact Lens、新たに 34 言語で会話型分析のサポートを開始 – 2025/04/01 Amazon Connect Contact Lens では、新たに 34 言語で会話分析がサポートされるようになりました。 関連リンク 管理者ガイド(言語サポート) Amazon Connect Contact Lens が新たに 2 つのリージョンで AI を活用したセマンティックコンタクト分類の機能の提供を開始 – 2025/04/01 Amazon Connect Contact Lens では、新たに 2 つのリージョン (欧州 – フランクフルトとアジアパシフィック – ソウル) で生成 AI を活用したコンタクト分類の機能が提供されました。 関連リンク 管理者ガイド(言語サポート) Amazon Connect Contact Lens で新たに 2 つのリージョンで AI を活用したコンタクトの要約機能の提供を開始 – 2025/04/01 Amazon Connect Contact Lens では、新たに欧州 (フランクフルト) とアジアパシフィック (ソウル) の 2 つのリージョンで、コンタクト終了後に生成 AI を活用した概要が提供されるようになりました。 関連リンク 管理者ガイド(言語サポート) 3. AWS Contact Center Blog のご紹介 Salesforce Contact Center with Amazon Connect: オムニチャネルのカスタマーエンゲージメントを効率化 (日本語翻訳) Salesforce Contact Center with Amazon Connect (SCC-AC) は、Amazon Connect のデジタルチャネルおよび音声機能を Salesforce に統合した画期的なソリューションとして、一般提供されています。音声チャネル専用の Service Cloud Voice (SCV) を基盤として、SCC-AC は、Amazon Connect と Salesforce 間で音声チャネルとデジタルチャネルを統合することで、カスタマーエクスペリエンス、エージェントエクスペリエンス、および業務効率を向上させることを可能にします。 AWS recognized as a leader in 2025 Forrester Wave for Contact Center as a Service with Amazon Connect (英語記事) Amazon Connect は、AIアーキテクチャ、生成 AI と LLM のサポート、エージェントデスクトップとワークフローの自動化、イノベーション、ロードマップ、価格の柔軟性と透明性といった評価基準で最高スコアを獲得しました。本ブログ記事は、AWS 社のクラウドベースのコンタクトセンターソリューションである Amazon Connect が、Forrester 社による2025年第2四半期のコンタクトセンター・アズ・ア・サービス(CCaaS)プラットフォーム評価でリーダーとして認定されたことを説明しています。 Insights and learnings from Amazon Q in Connect at NatWest (英語記事) 大手金融機関のNatWestグループによる、コンタクトセンターでのAmazon Q in Connect導入事例を紹介する記事です。ユーザー受け入れテスト(UAT)での課題、知識管理システムの統合方法、パイロット評価の手法など、具体的な取り組みが紹介されています。特に、テスト用の適切なインテント選定、レガシーな知識システムとの統合、パイロットの成功評価という3つの主要な課題に焦点を当てています。 今月のお知らせは以上です。皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は、2025/4/8 に公開された Manage concurrent write conflicts in Apache Iceberg on the AWS Glue Data Catalog を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 現代的なデータアーキテクチャにおいて、Apache Iceberg はデータレイクの人気のあるテーブルフォーマットとして台頭しており、ACID トランザクションと同時書き込みサポートなどの重要な機能を備えています。これらの機能は強力ですが、本番環境で効果的に実装するには、慎重な検討を要する独自の課題があります。 一般的なシナリオを考えてみましょう。ストリーミングパイプラインが継続的に Iceberg テーブルにデータを書き込み、スケジュールされたメンテナンスジョブがコンパクション操作を実行しています。Iceberg には同時書き込みを処理するための組み込みメカニズムがありますが、ストリーミング更新とコンパクション操作の間のような特定の競合シナリオでは、トランザクションが失敗し、特別な処理パターンが必要になる可能性があります。 この記事では、Iceberg テーブルで信頼性の高い同時書き込み処理メカニズムを実装する方法を示します。Iceberg の同時実行モデルを探り、一般的な競合シナリオを検討し、自動再試行メカニズムと、独自の競合解決ロジックが必要な状況の実用的な実装パターンを提供して、耐障害性の高いデータパイプラインを構築します。また、 AWS Glue Data Catalog テーブル最適化による自動コンパクションと併用した設計パターンについても説明します。 一般的な競合シナリオ 多くの組織がデータパイプラインで直面する、データ競合が最も頻繁に発生する具体的な運用シナリオについて、この節で説明します。 重複したパーティションへの UPDATE/DELETE の同時実行 複数のプロセスが同時に同じパーティションを変更しようとすると、データの競合が発生する可能性があります。例えば、ここで両方の操作が同じパーティションのcustomer_id を対象にした場合、重複するデータセットを変更することで競合が発生する可能性があります。両方の操作は customer_id に基づいて同じパーティションを対象としているため、重複するデータセットを変更しているので競合が発生する可能性があります。このような競合は、大規模なデータクリーンアップ操作で特に一般的です。 コンパクション vs ストリーミング書き込み テーブルのメンテナンス操作中に、典型的な競合シナリオが発生する可能性があります。リアルタイムのイベントデータを取り込むストリーミングパイプラインと、ファイルサイズを最適化するためにスケジュールされたコンパクションジョブが同時に実行されている場合を考えてみましょう。ストリーミングプロセスが新しいレコードをパーティションに書き込んでいる間に、コンパクションジョブが同じパーティション内の既存ファイルを結合しようとしているかもしれません。このシナリオは、特に Glue Data Catalog の自動最適化機能を利用している際に一般的に起こりうるシナリオです。自動コンパクションが継続的なデータ取り込みと同時に実行される可能性があるためです。 MERGE の同時実行操作 MERGE 操作は、データの読み取りと書き込みの両方を含むため、特に競合が発生しやすくなります。例えば、ある時間単位のジョブがソースシステムからの顧客プロファイル更新をマージしている一方で、別のジョブが別のシステムからの設定更新をマージしている場合、両方のジョブが同じ顧客レコードを変更しようとすると、それぞれの操作が異なる現在のデータ状態に基づいて変更を行うため、競合が発生する可能性があります。 一般的なテーブルの同時更新 複数のトランザクションが同時に発生すると、他のトランザクションの干渉により、一部のトランザクションがカタログにコミットできない可能性があります。Iceberg にはこのシナリオを処理するメカニズムがあり、多くの場合、同時トランザクションに対応できます。ただし、更新の基準となるメタデータバージョンが確立された後にメタデータが最新化されると、コミットが失敗する可能性があります。このシナリオは、Iceberg テーブルのあらゆる種類の更新に適用されます。 Iceberg の同時実行モデルと競合の種類 特定の実装パターンに入る前に、Iceberg がテーブルアーキテクチャとトランザクションモデルを通じて同時書き込みをどのように管理するかを理解することが不可欠です。Iceberg は、テーブルの状態とデータを管理するために階層アーキテクチャを使用しています。 カタログレイヤー – 現在のテーブルメタデータファイルへのポインターを維持し、テーブル状態の単一の情報源として機能します。Glue Data Catalog は Iceberg カタログと同様の機能を提供します。 メタデータレイヤー – テーブルの履歴、スキーマの進化、スナップショット情報を追跡するメタデータファイルが含まれています。これらのファイルは Amazon Simple Storage Service (Amazon S3) に格納されています。 データレイヤー – 実際のデータファイルと削除ファイル (Merge-on-Read 操作用) が格納されています。これらのファイルも Amazon S3 に格納されています。 次の図はこのアーキテクチャを示しています。 このアーキテクチャは Iceberg の楽観的同時実行制御の基本であり、複数のライターが同時に操作を進めることができ、競合はコミット時に検出されます。 書き込みトランザクションの流れ Iceberg での典型的な書き込みトランザクションは、次のキーステップに従います。 現在の状態を読み取ります。OVERWRITE、MERGE、DELETE などの多くの操作では、クエリエンジンがどのファイルまたは行が関連するかを知る必要があるため、現在のテーブルスナップショットを読み取ります。INSERT などの操作ではこの手順はオプションです。 トランザクションが行う変更を確定し、新しいデータファイルを書き込みます。 テーブルの最新のメタデータを読み込み、更新の基準となるメタデータバージョンを判断します。 ステップ 2 で準備した変更が、ステップ 3 の最新のテーブルデータと互換性があるかどうかを確認します。互換性がないことが検出された場合、トランザクションは停止する必要があります。 新しいメタデータファイルを生成します。 メタデータファイルをカタログにコミットします。コミットに失敗した場合は、ステップ 3 から再試行します。再試行回数は設定によって異なります。 次の図はこのワークフローを示しています。 競合が発生する可能性がある重要な 2 つのポイントは次のとおりです。 データ更新の競合 – データの競合をチェックする際の検証時 (ステップ 4) カタログコミットの競合 – カタログポインタを更新しようとするコミット時 (ステップ 6) Iceberg テーブルを扱う際、発生しうる競合の種類とその処理方法を理解することは、信頼性の高いデータパイプラインを構築する上で非常に重要です。主な 2 種類の競合とその特徴について説明しましょう。 カタログコミットの競合 カタログコミット競合は、複数のライターが同時にテーブルメタデータを更新しようとしたときに発生します。コミット競合が発生すると、Iceberg はテーブルの書き込みプロパティに基づいて自動的に操作を再試行します。再試行プロセスはメタデータのコミットのみを繰り返すため、安全で効率的です。再試行に失敗すると、トランザクションは CommitFailedException で失敗します。 次の図では、2 つのトランザクションが同時に実行されています。トランザクション 1 は、Iceberg カタログ内のテーブルの最新のスナップショットを 0 から 1 に正常に更新しました。一方、トランザクション 2 はスナップショット 0 から 1 への更新を試みましたが、カタログへの変更をコミットしようとしたときに、最新のスナップショットがすでにトランザクション 1 によって 1 に変更されていたことがわかりました。その結果、トランザクション 2 はステップ 3 から再試行する必要がありました。 これらの競合は一時的なものであり、再試行によって自動的に解決できます。オプションで、コミットの再試行動作を制御する書き込みプロパティを構成できます。より詳細な構成については、Iceberg ドキュメントの 書き込みプロパティ を参照してください。 現在の状態を読み取るときに使用されるメタデータ (ステップ 1) と、更新のベースメタデータとして使用されるスナップショット (ステップ 3) は異なる可能性があります。ステップ 1 とステップ 3 の間に別のトランザクションが最新のスナップショットを更新しても、現在のトランザクションはデータ競合チェック (ステップ 4) に合格すれば、カタログに変更をコミットできます。つまり、変更の計算とデータファイルの書き込み (ステップ 1 から 2) に長い時間がかかり、その間に他のトランザクションが変更を加えた場合でも、トランザクションはカタログへのコミットを試行できます。これは、Iceberg の賢明な同時実行制御メカニズムを示しています。 次の図はこのワークフローを示しています。 データ更新の競合 データ更新の競合は、より複雑で、同時実行されるトランザクションが重複するデータを変更しようとしたときに発生します。書き込みトランザクション中、クエリエンジンはトランザクション分離ルールに従って、書き込まれるスナップショットと最新のスナップショットの整合性をチェックします。不整合が検出された場合、トランザクションは ValidationException で失敗します。 次の図では、2 つのトランザクションが id 、 name 、 salary 列を含む従業員テーブルで同時に実行されています。トランザクション 1 は、スナップショット 0 に基づいてレコードを更新しようとし、この変更を正常にコミットしてスナップショットのバージョンを 1 に更新しました。一方、トランザクション 2 も同じレコードをスナップショット 0 に基づいて更新しようとしました。トランザクション 2 が最初にデータをスキャンした時点では、最新のスナップショットは 0 でしたが、その後トランザクション 1 によって 1 に更新されていました。データ競合チェック中に、トランザクション 2 はその変更がスナップショット 1 と競合していることを検出し、トランザクションが失敗しました。 この競合シナリオでは、更新の元となるテーブルの状態が変更されているため、トランザクションを再施行した場合に全体のデータ整合性が維持されるかどうかが不確かになるため、Iceberg のライブラリでは自動的に再試行できません。この種の競合は、個別のユースケースと要件に基づいて対処する必要があります。 次の表は、各書き込みパターン別に競合が発生する可能性の有無をまとめたものです。 書き込みパターン カタログコミット競合 (自動再試行可能) データ競合 (再試行なし) INSERT ( AppendFiles ) Yes Never UPDATE/DELETE with Copy-on-Write または Merge-on-Read ( OverwriteFiles ) Yes Yes Compaction ( RewriteFiles ) Yes Yes Iceberg テーブルの分離レベル Iceberg テーブルは、 Serializable 分離 と Snapshot 分離 の 2 つの分離レベルをサポートしています。どちらも、テーブルの一貫したビューを読み取り、リーダーがコミットされたデータのみを参照することを保証します。Serializable 分離は、同時実行操作が逐次的に実行されたかのように処理されることを保証します。Snapshot 分離は保証が弱くなりますが、同時に多数の書き込みクライアントが存在する環境でのパフォーマンスが向上します。Snapshot 分離では、同時実行トランザクションが条件に一致する可能性のあるレコードを含む新しいファイルを追加した場合でも、データ競合チェックが合格する可能性があります。 デフォルトでは、Iceberg テーブルはSerializable 分離を使用します。テーブルプロパティを使用して、特定の操作の分離レベルを構成できます。 tbl_properties = { 'write.delete.isolation-level' = 'serializable', 'write.update.isolation-level' = 'serializable', 'write.merge.isolation-level' = 'serializable' } ユースケースに基づいて適切な分離レベルを選択する必要があります。最も一般的な競合シナリオの一つであるストリーミングでの書き込みとコンパクション操作の同時実行では、スナップショット分離を選んだとしても、競合を緩和する観点でシリアライザブル分離に対する追加のメリットはない点に留意してください。より詳細な設定については、 IsolationLevel を参照してください。 実装パターン Iceberg で堅牢な同時書き込み処理を実装するには、競合の種類とユースケースに応じて異なる戦略が必要です。このセクションでは、一般的なシナリオを処理するための実証済みのパターンを共有します。 カタログコミット競合の管理 カタログコミットの競合は、テーブルプロパティを通じて比較的簡単に処理できます。以下の構成は、ワークロードのパターンと要件に応じて調整できる、初期のベースライン設定として機能します。 頻繁な同時書き込み (ストリーミングによる書き込みなど) の場合: tbl_properties = { 'commit.retry.num-retries': '10', 'commit.retry.min-wait-ms': '100', 'commit.retry.max-wait-ms': '10000', 'commit.retry.total-timeout-ms': '1800000' } メンテナンス操作 (コンパクション等) の場合: tbl_properties = { 'commit.retry.num-retries': '4', 'commit.retry.min-wait-ms': '1000', 'commit.retry.max-wait-ms': '60000', 'commit.retry.total-timeout-ms': '1800000' } データ更新の競合管理 データ更新の競合は自動的に再試行できないため、適切なエラー処理を伴うカスタムの再試行メカニズムを実装する必要があります。一般的なシナリオは、ストリームでの UPSERT 取り込みと同時実行のコンパクション操作が競合する場合です。このような場合、ストリーム取り込みジョブは通常、データを処理するために再試行を実装する必要があります。適切なエラー処理がないと、ジョブは ValidationException で失敗します。 Iceberg ストリーミングジョブでのデータ競合に対するエラー処理の実用的な実装を示す 2 つのサンプルスクリプトを紹介します。このコードは、適切な Java と Python を相互に利用する際に不可欠な Py4JJavaError 処理を通じて、 ValidationException を捕捉しています。また、 エクスポネンシャルバックオフとジッター戦略 を実装し、各再試行間隔に 0 〜 25% のランダムな遅延を追加しています。たとえば、指数関数的バックオフ時間の基準が 4 秒の場合、実際の再試行の遅延は 4 〜 5 秒の間になり、即座の再試行の嵐を防ぎながら、合理的な待ち時間を維持できます。 このサンプルでは、一意の識別子として 'value' を使用し、その範囲を人為的に制限することで、同じレコードに対する頻繁な MERGE 操作のシナリオを作成しています。モジュロ演算 ( value % 20 ) を適用することで、すべての値を 0 〜 19 の範囲に制限しています。これにより、複数の更新が同じレコードを対象とすることになります。たとえば、元のストリームに値 0、20、40、60 が含まれている場合、すべて 0 にマッピングされるため、同じレコードに対して複数の MERGE 操作が行われます。次に、 groupBy と max 集約を使用して、一般的な UPSERT パターンをシミュレートします。ここでは、各値の最新のレコードを保持します。変換されたデータは一時ビューに格納され、MERGE ステートメントのソーステーブルとして機能します。これにより、 'value' を一致条件として使用して UPDATE 操作を実行できます。このセットアップにより、同時実行トランザクションが同じレコードを変更しようとしたときに発生する ValidationExceptions に対するリトライメカニズムの動作を確認できます。 最初のサンプルでは、20 秒のトリガー間隔でデータを生成する レートソース を使用する Spark Structured Streaming を使用して、同時操作によるデータ競合が発生したときの再試行メカニズムの動作を示します。 <database_name> は実際のデータベース名、 <table_name> は実際のテーブル名、 amzn-s3-demo-bucket は 実際の S3 バケット名にそれぞれ置き換えてください。 import time import random from pyspark.sql import SparkSession from py4j.protocol import Py4JJavaError from pyspark.sql.functions import max as max_ CATALOG = "glue_catalog" DATABASE = "" TABLE = "<table>" BUCKET = "amzn-s3-demo-bucket" spark = SparkSession.builder \ .appName("IcebergUpsertExample") \ .config(f"spark.sql.catalog.{CATALOG}", "org.apache.iceberg.spark.SparkCatalog") \ .config("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \ .config(f"spark.sql.catalog.{CATALOG}.io-impl","org.apache.iceberg.aws.s3.S3FileIO") \ .config("spark.sql.defaultCatalog", CATALOG) \ .config(f"spark.sql.catalog.{CATALOG}.type", "glue") \ .getOrCreate() spark.sql(f""" CREATE TABLE IF NOT EXISTS {DATABASE}.{TABLE} ( timestamp TIMESTAMP, value LONG ) USING iceberg LOCATION 's3://{BUCKET}/warehouse' """) def backoff(attempt): """Exponential backoff with jitter""" exp_backoff = min(2 ** attempt, 60) jitter = random.uniform(0, 0.25 * exp_backoff) return exp_backoff + jitter def is_validation_exception(java_exception): """Check if exception is ValidationException""" cause = java_exception while cause is not None: if "org.apache.iceberg.exceptions.ValidationException" in str(cause.getClass().getName()): return True cause = cause.getCause() return False def upsert_with_retry(microBatchDF, batchId): max_retries = 5 attempt = 0 # Use a narrower key range to intentionally increase updates for the same value in MERGE transformedDF = microBatchDF \ .selectExpr("timestamp", "value % 20 AS value") \ .groupBy("value") \ .agg(max_("timestamp").alias("timestamp")) view_name = f"incoming_data_{batchId}" transformedDF.createOrReplaceGlobalTempView(view_name) while attempt < max_retries: try: spark.sql(f""" MERGE INTO {DATABASE}.{TABLE} AS t USING global_temp.{view_name} AS i ON t.value = i.value WHEN MATCHED THEN UPDATE SET t.timestamp = i.timestamp, t.value = i.value WHEN NOT MATCHED THEN INSERT (timestamp, value) VALUES (i.timestamp, i.value) """) print(f"[SUCCESS] Batch {batchId} processed successfully") return except Py4JJavaError as e: if is_validation_exception(e.java_exception): attempt += 1 if attempt < max_retries: delay = backoff(attempt) print(f"[RETRY] Batch {batchId} failed with ValidationException. " f"Retrying in {delay} seconds. Attempt {attempt}/{max_retries}") time.sleep(delay) else: print(f"[FAILED] Batch {batchId} failed after {max_retries} attempts") raise # Sample streaming query setup df = spark.readStream \ .format("rate") \ .option("rowsPerSecond", 10) \ .load() # Start streaming query query = df.writeStream \ .trigger(processingTime="20 seconds") \ .option("checkpointLocation", f"s3://{BUCKET}/checkpointLocation") \ .foreachBatch(upsert_with_retry) \ .start() query.awaitTermination() 2 つ目のサンプルは、AWS Glue Streaming ジョブで利用可能な GlueContext.forEachBatch を使用しています。リトライメカニズムの実装パターンは同じですが、主な違いは GlueContext を使った初期設定と、ストリーミング DataFrame を作成する方法です。このサンプルでは spark.readStream をレートソースと共に使用していますが、実際の AWS Glue Streaming ジョブでは、通常 glueContext.create_data_frame.from_catalog を使用して、 Amazon Kinesis や Kafka などのソースからストリーミング DataFrame を作成します。詳細については、 AWS Glue ストリーミング 接続 を参照してください。 <database_name> は実際のデータベース名、 <table_name> は実際のテーブル名、 amzn-s3-demo-bucket は 実際の S3 バケット名にそれぞれ置き換えてください。 import time import random from py4j.protocol import Py4JJavaError from pyspark.context import SparkContext from awsglue.context import GlueContext from pyspark.sql import SparkSession from pyspark.sql.functions import max as max_ CATALOG = "glue_catalog" DATABASE = "<database_name>" TABLE = "<table_name>" BUCKET = "amzn-s3-demo-bucket" spark = SparkSession.builder \ .appName("IcebergUpsertExample") \ .config(f"spark.sql.catalog.{CATALOG}", "org.apache.iceberg.spark.SparkCatalog") \ .config("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \ .config(f"spark.sql.catalog.{CATALOG}.io-impl","org.apache.iceberg.aws.s3.S3FileIO") \ .config("spark.sql.defaultCatalog", CATALOG) \ .config(f"spark.sql.catalog.{CATALOG}.type", "glue") \ .getOrCreate() sc = spark.sparkContext glueContext = GlueContext(sc) spark.sql(f""" CREATE TABLE IF NOT EXISTS {DATABASE}.{TABLE} ( timestamp TIMESTAMP, value LONG ) USING iceberg LOCATION 's3://{BUCKET}/warehouse' """) def backoff(attempt): exp_backoff = min(2 ** attempt, 60) jitter = random.uniform(0, 0.25 * exp_backoff) return exp_backoff + jitter def is_validation_exception(java_exception): cause = java_exception while cause is not None: if "org.apache.iceberg.exceptions.ValidationException" in str(cause.getClass().getName()): return True cause = cause.getCause() return False def upsert_with_retry(batch_df, batchId): max_retries = 5 attempt = 0 transformedDF = batch_df.selectExpr("timestamp", "value % 20 AS value") \ .groupBy("value") \ .agg(max_("timestamp").alias("timestamp")) view_name = f"incoming_data_{batchId}" transformedDF.createOrReplaceGlobalTempView(view_name) while attempt < max_retries: try: spark.sql(f""" MERGE INTO {DATABASE}.{TABLE} AS t USING global_temp.{view_name} AS i ON t.value = i.value WHEN MATCHED THEN UPDATE SET t.timestamp = i.timestamp, t.value = i.value WHEN NOT MATCHED THEN INSERT (timestamp, value) VALUES (i.timestamp, i.value) """) print(f"[SUCCESS] Batch {batchId} processed successfully") return except Py4JJavaError as e: if is_validation_exception(e.java_exception): attempt += 1 if attempt < max_retries: delay = backoff(attempt) print(f"[RETRY] Batch {batchId} failed with ValidationException. " f"Retrying in {delay} seconds. Attempt {attempt}/{max_retries}") time.sleep(delay) else: print(f"[FAILED] Batch {batchId} failed after {max_retries} attempts") raise # Sample streaming query setup streaming_df = spark.readStream \ .format("rate") \ .option("rowsPerSecond", 10) \ .load() # In actual Glue Streaming jobs, you would typically create a streaming DataFrame like this: """ streaming_df = glueContext.create_data_frame.from_catalog( database = "database", table_name = "table_name", transformation_ctx = "streaming_df", additional_options = { "startingPosition": "TRIM_HORIZON", "inferSchema": "false" } ) """ glueContext.forEachBatch( frame=streaming_df, batch_function=upsert_with_retry, options={ "windowSize": "20 seconds", "checkpointLocation": f"s3://{BUCKET}/checkpointLocation" } ) 操作のスコープを絞り、競合の可能性を最小化する メンテナンス操作 (コンパクションや更新など) を実行する際は、他の操作との重複を最小限に抑えるため、スコープを絞ることをお勧めします。たとえば、日付でパーティション分割されたテーブルで、ストリーミングジョブが最新の日付のデータを継続的に上書きする場合を考えてみましょう。以下は、テーブル全体をコンパクションするために rewrite_data_files プロシージャを実行するサンプルスクリプトです。 # Example of broad scope compaction spark.sql(""" CALL catalog_name.system.rewrite_data_files( table => 'db.table_name' ) """) where 句でデータ分割フィルターを使用してコンパクション範囲を狭めることで、ストリーミングデータ取り込みとコンパクション操作の競合を回避できます。ストリーミングジョブは最新のパーティションで動作を続けられる一方で、コンパクションは過去のデータを処理できます。 # Narrow down the scope by partition spark.sql(""" CALL catalog_name.system.rewrite_data_files( table => 'db.table_name', where => 'date_partition < current_date' ) """) 結論 Iceberg での同時書き込みを適切に管理するには、テーブルのアーキテクチャと様々な競合シナリオを理解する必要があります。この投稿では、本番環境で信頼できる競合処理メカニズムを実装する方法を探りました。 最も重要な概念は、カタログコミット競合とデータ競合の違いを覚えておくことです。カタログコミット競合は自動再試行とテーブルプロパティの設定で対処できますが、データ競合には独自の処理ロジックを慎重に実装する必要があります。これは、 rewrite_data_files で where 句を使用してスコープを絞ることで競合の可能性を大幅に低減できるため、コンパクション (compaction) などのメンテナンス操作を実装する際に特に重要になります。 ストリーミングパイプラインでの成功の鍵は、競合の種類を区別し、適切に対応するためのエラー処理を実装することにあります。これには、テーブルプロパティを通じて適切な再試行設定を構成し、ワークロードの特性に合わせたバックオフ戦略を実装することが含まれます。適切なタイミングでメンテナンス操作を組み合わせることで、同時書き込みを確実に処理できる、耐障害性の高いデータパイプラインを構築できます。 これらのパターンを適用し、Iceberg の同時実行モデルの基本的なメカニズムを理解することで、データの整合性と信頼性を維持しながら、同時書き込みシナリオを効果的に処理できるロバストなデータパイプラインを構築できます。 著者について 疋田 宗太郎 : アナリティクスソリューションアーキテクトです。幅広い業界の顧客に対し、アナリティクスプラットフォームの構築と運用をより効果的に行えるようサポートしています。特に、ビッグデータ技術とオープンソースソフトウェアに情熱を持っています。 関山 宜孝 : AWS Glue チームのプリンシパル ビッグデータ アーキテクトです。東京を拠点に活動しています。顧客を支援するためのソフトウェアアーティファクトの構築を担当しています。余暇時間には、ロードバイクで走ることを楽しんでいます。

本記事は 2025 年 4 月 10 日に公開された “ Announcing inline chat in Eclipse with Amazon Q Developer ” を翻訳したものです。 本日 (原文公開日 : 2025/4/10)、 Amazon Q Developer は Eclipse IDE でのインラインチャット機能（プレビュー版）をリリースしました。この記事では、既存コードのリファクタリングからパフォーマンスが重要なメソッドの最適化まで、この強力な新機能を使って Java 開発作業を効率化する方法をご紹介します。Eclipse のベテランユーザーでも、これから始める方でも、 Amazon Q Developer の高度な AI を活用したツールがソフトウェア開発ライフサイクル全体を通じて生産性を向上させる方法をご覧いただけます。 背景 長年の Java 開発者として、昨年 Amazon Q Developer が Eclipse に統合された ときにとても興奮しました。私は Amazon Q Developer をしばらく使用していますが、これによって開発方法が完全に変わりました。 Amazon Q Developer が 2022 年にインライン提案機能を最初にリリースした とき、コーディング作業がどれだけ加速できるかに驚きました。しかし、 2023 年に完全なチャットインターフェイスが追加された ことで、さらに次のレベルへと進化しました。そして 2024 年には、 新しいインラインチャット機能によってコードをその場で編集・リファクタリングできるようになりました。 しかし、今日(原文公開日 : 2025/4/10)までインラインチャットは Eclipse では利用できませんでした！ Amazon Q Developer の チャットインターフェイス は、特定のタスクをどう進めればいいのかわからないときに頼りになります。解決しようとしている問題や理解しようとしている概念を説明すると、正しい方向へ導くための、詳細なコンテキストに基づいた回答が得られることが、とても気に入っています。AI が生成するコードスニペットと説明は、新しいことを学んだり複雑な課題に取り組んだりするときに、とても価値があります。しかし、タスクの実行方法がわかっているときは、説明は要らず、コードだけが欲しいのです。 一方で、よく理解しているタスクに取り組んでいるときは、 Amazon Q Developer の インライン提案 を使いたいと感じます。既存のコードやコメントを分析して関連性の高いカスタマイズされた補完を提供してくれるので、本当に素晴らしいです。コンテキストを切り替えたり、正しい構文を探したりすることなく、新しい機能をより速く開発できます。ただし、インライン提案は新しいコードの生成には優れていますが、既存のコードの編集には使用できません。 今回、 Eclipse での新しい インラインチャット 機能（プレビュー版）により、 Amazon Q Developer を使用してコードをその場で簡単に編集できるようになりました。別のチャットウィンドウからコードをコピー＆ペーストする必要はありません。エディター内で直接変更したい内容を説明するだけで、 Amazon Q Developer が Amazon Q Developer によって提案された更新がコードベースに差分としてシームレスに統合されます。この機能はリファクタリング、バグ修正、ドキュメントの整備、そしてコードの可読性の維持にといった作業にとても役立ちます。それでは、Eclipse でインラインチャットがどのように機能するか、いくつかの例を見てみましょう。 リファクタリング 開発チームの新メンバーとして、 OrderProcessor クラスにユニットテストを追加するタスクを任されたと想像してみましょう。しかし、コードベースを調べていくと、 OrderProcessor が OrderRepository の実装に密結合していることに気づきました。以下の画像の 2 行目で OrderRepository を直接インスタンス化しているのが確認できます。これにより、モックリポジトリを簡単に差し替えることができず、ユニットテストの作成が困難でした。依存性注入を使用するようにコードをリファクタリングする必要があることはわかっていましたが、その変更をすべて手動で行うことはとても大変でした。 幸いなことに、 Eclipse IDE の Amazon Q Developer のインラインチャットのおかげで、このリファクタリングに一人で立ち向かう必要はありませんでした。 OrderProcessor クラスを選択し、キーボードショートカット（macOS では CMD + SHIFT + I、Windows では CTRL + SHIFT + I）を使用してインラインチャットを呼び出しました。そして、「このクラスに依存性注入（Dependency Injection : DI）を使うようリファクタリングして。 OrderRepository をモック化してユニットテストしたい。」と変更内容を説明しました。特定の DI フレームワーク（Hibernate など）を活用するよう Amazon Q Developer に指示することもできましたが、このブログ記事ではシンプルに進めることにします。 Amazon Q Developer はコードをすばやく分析し、以下の画像のように変更を提案しました。変更は差分として表示され、 Amazon Q Developer が削除する部分（赤色）と追加する部分（緑色）を一目で確認できます。変更をレビューすると、 Amazon Q Developer が IOrderRepository インターフェイスを受け取るコンストラクタを導入し、具体的な実装またはテストダブルのいずれかを渡せるようにしていることがわかりました。これにより、 OrderProcessor の包括的なユニットテストを簡単に作成できるようになります。「Accept」をクリックするだけで、 Amazon Q Developer がコードを更新し、時間を大幅に節約し、かつ堅牢でテスト可能な設計の上に新しい機能が構築できるのです。。 今回の例では、クラス全体を選択しました。しかし、コードの特定の部分に対して Q Developer に作業を依頼することもできます。 最適化 Order クラスに取り組んでいるとき、 containsItem メソッドの実行が遅いことに気づきました。とくに多数の明細項目を持つ注文に対してその事象が発生していました。コードをプロファイリングしたところ、そのメソッドがホットスポットとなり、過剰な量の CPU サイクルを消費していることがわかりました。そこで、 containsItem メソッドを選択し、インラインチャットを表示して、 Amazon Q Developer に「このコードの実行が遅いので、最適化してください」と依頼しました。 Amazon Q Developer は、すぐに既存のコードを分析しました。このコードはリスト内の項目を反復処理するために、単純な for ループを使用しており、そこ対して改良された実装を提供しました。差分に示されているように、 Amazon Q Developer は for ループをより効率的なストリームベースのアプローチに置き換え、 anyMatch メソッドを使用して注文内に項目が存在するかどうかを判断する実装を提案しました。この変更により、とくに多数の明細項目を持つ注文のパフォーマンスが向上しました。私は変更を確認し、 Amazon Q Developer の提案を受け入れました。（※訳者注 : あくまで分かりやすい例としての記載であり、実際にパフォーマンスが上がるかどうかはデータの量などによって変わります。） Amazon Q Developer の最適化により、 containsItem メソッドのパフォーマンスが向上しただけでなく、コードの可読性と保守性も向上しました。 まとめ Amazon Q Developer の Eclipse IDE への統合（プレビュー版）により、私の Java 開発の作業が効率化し、改善されました。新しい概念の学習、ボイラープレートコードの生成、パフォーマンスのボトルネックの最適化など、 Amazon Q Developer の AI を活用したツール群は、私の開発プロセスに欠かせない存在となっています。とくにインラインチャットの追加により、アシスタントと直接やりとりし、集中力を途切れさせることなくコードベースを直接更新できるようになったのは大きな変化です。もし、あなたが Eclipse ユーザーで、生産性をさらに向上させたいと考えているなら、 Amazon Q Developer プラグインを今すぐインストール することを強くオススメします。 翻訳はApp Dev Consultantの宇賀神が担当しました。

本記事は 2025 年 5 月 6 日に公開された “ Accelerate development workflows to reduce release cycles using the Amazon Q Developer integration for GitHub (Preview) ” を翻訳したものです。 開発サイクルを短縮するためタスクを自動実行できる Amazon Q Developer for GitHub （プレビュー）は、AWS アカウントが不要で無料利用できます。 Amazon Q Developer は GitHub.com と GitHub Enterprise Cloud での機能開発を加速します。追加コストなしで Q Developer を支える高性能モデルを活用し、新機能の自動実装、バグの修正、テストカバレッジの向上、ドキュメント作成、すべての新しい Pull Request に対するコードレビューの実行、レガシー Java アプリケーションのモダナイズを行うことができます。これらは GitHub 上にある Issue と Pull Request を使用しながら実現できます。 背景 開発チームは、要件定義、開発、デプロイを協力して行う際に、複数のツールやコンテキストを行き来しながら、増え続ける課題に直面しています。バグ修正、コードレビュー、単体テストの作成、アップグレード管理といった定型作業に貴重な時間が費やされています。アプリケーションの規模が拡大するにつれ、これらの活動は開発者の生産性やセキュリティのベストプラクティスの維持にますます影響を与えています。 多くの開発者と同様に、皆様も DevOps ワークフローに GitHub を使用されていることでしょう。そのため、Amazon Q Developer の GitHub への統合を発表できることを大変嬉しく思います。AI 駆動の支援を、使い慣れた GitHub 環境に直接組み込むことで、コンテキスト切り替えを排除し、より迅速に作業を進め、セキュリティと運用の卓越性を維持しながらイノベーションに集中することができます。そのような開発の未来がここに到来しました！ はじめに Amazon Q Developer for GitHub の開始は簡単です。Organization の管理者は GitHub Marketplace を通じて Amazon Q Developer アプリケーションを迅速にデプロイし、リポジトリアクセスと AI エージェント設定を管理できます。個々の開発者は Organization のセットアップ後すぐにサービスの使用を開始できます。AWS アカウントの設定は必要ありません。 設定が完了すると、開発者は GitHub の Issue に “Amazon Q development agent” または “Amazon Q transform agent” ラベルを追加するだけで Amazon Q Developer のサポートを受けることができます。Pull Request が作成された後、開発者は Amazon Q Developer の Pull Request に自然言語でコメントすることで、生成されたコードを Amazon Q Developer と共に改善することができます。 Amazon Q Developer for GitHub の仕組み 1. 機能開発エージェント Amazon Q Developer は自然言語による説明から本番環境対応のコードを生成することで機能開発やバグ修正を簡素化します。開始するには GitHub の Issue に “Amazon Q development agent” ラベルを追加するだけです。ラベル付けされると Amazon Q Developer は要件と既存のコードベースを分析してコンテキストを理解します。その後新しいブランチを作成し、プロジェクトの確立されたパターンとベストプラクティスに従ったコードを生成します。 図 1 – “Amazon Q development agent“ ラベルを追加した Issue の作成 図 2 – Amazon Q Developer によって作成された Pull Request と変更内容の説明 図 1 に示すように、”Add an option to delete a task on the screen (画面上にタスクを削除するオプションを追加する)” というタイトルで Issue を作成し、”Amazon Q development agent” ラベルを適用すると、エージェントは処理を開始します。エージェントはリクエストを分析し、図 2 に示すように詳細な変更内容とセキュリティレビューを含む提案されたコード変更を含む Pull Request を作成します。 2. Transformation エージェント Amazon Q Developer は開発チームがアプリケーションをモダナイズし、自動化されたコードのアップグレードを通じて技術的負債を削減するのを支援します。このエージェントは現在、Java アプリケーションをバージョン 8 または 11 から Java 17 へアップグレードすることをサポートしており、API の変更や非推奨化を自動的に処理します。新しい言語機能を活用するためにコードを自動的に更新しながら、アプリケーションの既存機能を維持し、メジャーバージョンアップグレードに通常伴う時間とリスクの両方を削減します。 コード変換を開始する前に、 ドキュメント に記載されている前提条件とセットアップ手順を確認してください。 図 3 – “Amazon Q development agent” ラベルで作成された Issue 図 4 – コード変換のサマリが記載された Pull Request の作成 図 5 – Pull Request のファイル変更点 図 3 に示すように、“Migrate project from Java 8 to Java 17 (プロジェクトを Java 8 から Java 17 に移行する)” というタイトルの課題を作成し、”Amazon Q development agent” ラベルを適用すると、Amazon Q Developer はアップグレードプロセスを開始します。エージェントは図 4 と図 5 に示すように、すべての変更と実装手順を詳細に記録した Pull Request を作成します。 3. コードレビュー エージェント Amazon Q Developer は Pull Request レビューのプロセスを効率化し、自動コード分析を提供します。これによりチームはレビューサイクルを削減し、開発の早い段階で潜在的な問題を発見できます。Pull Request が作成されると、エージェントは自動的に以下の点についてコードを分析します: 品質の問題と潜在的なバグ セキュリティの脆弱性 公開された機密情報や重要情報 図 6 – Pull Request の自動コードレビュー 図 6 に示すように、エージェントは包括的なセキュリティレビューを実施し、詳細かつ実行可能なフィードバックを提供します。この例では、ハードコードされた SECRET_KEY を特定し、改善計画を提案しました。エージェントの推奨事項には以下が含まれています： 明確さのためのキーの名前変更 機密データを環境変数に移動 将来の改善のためのドキュメント追加 安全なキー管理のためのベストプラクティスの提案 エージェントは、ソースコードから機密情報を削除し、キーのローテーションを容易にし、コードの保守性を向上させることで、これらの変更がセキュリティをどのように改善するかを説明しました。また、安全な設定ファイルの使用や適切なエラー処理の実装など、本番環境のセキュリティを強化するための追加ステップも推奨しています。 このレベルの詳細なガイダンスを提供することで、コードレビューエージェントはチームがすばやくセキュリティ問題に対処し、開発者が AWS セキュリティのベストプラクティスを実装するのを支援するように設計されています。この自動化された詳細なレビュープロセスは、手動コードレビューに費やす時間を削減しながら、全体的なコード品質とセキュリティを向上させるのに役立ちます。 アンイストール GitHub Organization から Amazon Q Developer をアンインストールするには、 アプリのインストールページ に移動して “Configure“ を選択します。“Uninstall Amazon Q Developer” を選択すると、以前に選択したすべてのリポジトリから連携が完全に削除されます。 次のステップ この Amazon Q Developer for GitHub (プレビュー) は企業のソフトウェア開発を強化することを目的としています。Amazon Q Developer は AI を活用したエージェント機能を GitHub にもたらし、チームが高品質基準を維持しながら技術的負債を減らしつつ、より良いコードをより速く提供できるよう支援します。 この統合は GitHub の Issue、Pull Request、Commentなどの標準ワークフローを使用します。チームは確立された開発プラクティスを妨げることなく Amazon Q Developer のメリットを享受できます。 開発ワークフローを強化する準備はできていますか？ GitHub Marketplace にアクセスして、今すぐ GitHub での Amazon Q Developer の利用を開始しましょう。 翻訳はソリューションアーキテクトの小森谷が担当しました。 著者について Madhu Balaji Madhu is a Senior Specialist Solutions Architect at AWS who helps customers design and implement innovative cloud solutions. With 20+ years of experience in development and application architecture, he focuses on enabling customers to accelerate their time-to-market and solve complex business challenges using AWS services.

5 月 7 日、 Amazon Web Services (AWS) は、2026 年末までにチリに新しい AWS リージョン を開設する計画を発表しました。AWS 南米 (チリ) リージョンは、開設時に 3 つの アベイラビリティーゾーン で構成される予定です。これにより、チリのお客様には、 AWS インフラストラクチャ とサービスを、より近い場所でご利用いただけるようになります。この新しいリージョンは、 AWS 南米 (サンパウロ) リージョンと AWS メキシコ (中部) リージョン に続き、ラテンアメリカにおける 3 つ目の AWS リージョンとなります。各アベイラビリティーゾーンは、低レイテンシーを必要とするアプリケーションをサポートするために十分な距離を保って相互に離れており、単一のイベントが可用性に影響を及ぼすリスクを大幅に軽減します。 ラスコンデスの金融街にある近代的なオフィスビルが立ち並ぶ、チリのサンティアゴのスカイライン 新しい AWS リージョンにより、ラテンアメリカのお客様には、 AI や 機械学習 (ML) などの高度なクラウドテクノロジーを、より近い場所でご利用いただけるようになります。このリージョンは、完全に冗長化された専用ファイバー経由の高帯域幅かつ低レイテンシーのネットワーク接続を通じて、同期レプリケーションを必要とするアプリケーションをサポートすると同時に、データレジデンシー要件を満たせるよう、ワークロードの実行とデータのローカル保存における柔軟性を提供します。 チリにおける AWS 2017 年、AWS はチリのサンティアゴにオフィスを設立し、現地のお客様とパートナーをサポートしています。現在、サンティアゴのオフィスでは、ビジネス開発チーム、ソリューションアーキテクト、パートナーマネージャー、プロフェッショナルサービスコンサルタント、サポートスタッフ、および他のさまざまな役割を担うスタッフが勤務しています。 チリに対する継続的なコミットメントの一環として、AWS は、チリ全土で複数のインフラストラクチャオファリングに投資してきました。2019 年、AWS は チリに Amazon CloudFront エッジロケーション を開設しました。これにより、非常に安全でプログラム可能なコンテンツ配信ネットワークが提供され、低レイテンシーと高速転送により、世界中のユーザーに対する、データ、動画、アプリケーション、API の配信が高速化されます。 AWS は 2021 年に 2 つの重要な追加により、その存在感を強化しました。1 つ目は、 プンタアレーナスの AWS Ground Station アンテナ拠点 です。これは、衛星通信、データ処理、グローバルな衛星運用のスケーリングのためのフルマネージドサービスを提供します。2 つ目は、 チリの AWS Outposts です。これは、一貫したハイブリッドエクスペリエンスを実現するために、フルマネージド AWS インフラストラクチャおよびサービスを、事実上あらゆるオンプレミスまたはエッジロケーションで利用できるようにします。 2023 年、AWS は 2 つの重要な開発により、インフラストラクチャをさらに強化しました。1 つは、AWS と、お客様のデータセンター、オフィス、またはコロケーション環境の間でプライベート接続を確立できるようにする チリの AWS Direct Connect ロケーション であり、もう 1 つは、コンピューティング、ストレージ、データベース、および他の厳選されたサービスを、人口密集地や IT ハブの近くで利用できるようにする、 サンティアゴの AWS Local Zones です。サンティアゴの AWS Local Zone は、お客様が 1 桁ミリ秒のレイテンシーを必要とするアプリケーションをエンドユーザーに提供するのに役立ちます。 今後開設予定の AWS 南米 (チリ) リージョンは、チリにおけるイノベーションの推進に対する当社の継続的なコミットメントを表すものです。AWS は、インフラストラクチャの構築を超えて、包括的なクラウド教育イニシアティブを通じて、チリのデジタルワークフォースの育成においても重要な役割を果たしています。 AWS Academy 、 AWS Educate 、 AWS Skill Builder を通じて、AWS は、学生やデベロッパーから、ビジネスプロフェッショナルや新進の IT リーダーまで、必要不可欠なクラウドコンピューティングスキルを多様なグループに提供しています。2017 年以降、AWS は、ラテンアメリカ全域で 200 万を超える人々にクラウドスキルのトレーニングを提供してきました。これには、チリの 10 万人超も含まれています。 チリの AWS のお客様 チリの AWS のお客様はますます、アプリケーションを AWS に移行し、世界中の AWS リージョンでテクノロジーインフラストラクチャを運用するようになっています。この新しい AWS リージョンの追加により、お客様は、さらに低いレイテンシーをエンドユーザーに提供し、生成 AI、モノのインターネット (IoT)、モバイルサービス、銀行業界などの高度なテクノロジーを利用してイノベーションを推進できるようになります。このリージョンを利用することで、AWS のお客様は、チリでワークロードを実行したり、コンテンツを保存したりできます。 AWS を利用してイノベーションを推進しているチリのお客様の例をいくつかご紹介します: Digital Government Secretariat (SGD) は、デジタル政府戦略の提案と実施の調整を担当し、統合的な政府アプローチを提供するチリの政府機関です。SGD は、行政やサービスの提供を改善するために、デジタルテクノロジー、データ、公共情報の戦略的な利用において、調整および助言したり、セクター横断的なサポートを提供したりしています。このミッションを果たすため、SGD は AWS を利用して、 Clave Única (シングルサインオン) 、 FirmaGob (デジタル署名) 、 State Electronic Services Integration Platform (PISEE) 、 DocDigital 、 SIMPLE 、 Administrative Procedures and Services Catalog (CPAT) など、重要なデジタルプラットフォームを運用しています。 チリ最大の決済ソリューションエコシステムであり、国内取引の最も大きな割合を管理している Transbank は、AWS を利用して、新製品の市場投入までの時間を大幅に短縮しました。さらに、Transbank は AWS を利用した複数のソリューションを実装して、チームの生産性を高め、イノベーションを加速しました。これらの取り組みは、金融テクノロジー企業が AWS を利用してイノベーションと運用効率の向上を推進する方法を示しています。「チリの新しい AWS リージョンは、当社にとって非常に重要なものとなるでしょう」と Transbank の Chief Architecture and Technology Officer (CA&TO) である Jorge Rodríguez M. 氏は述べています。「このリージョンは、レイテンシーをさらに低減し、セキュリティを強化するとともに、イノベーションの可能性を拡大してくれるでしょう。これにより、当社は、より優れた新しいサービスと製品をお客様に提供できるようになります」。 チリの AWS のお客様の詳細については、 AWS のお客様の成功事例 にアクセスしてください。 チリにおける AWS のサステナビリティへの取り組み AWS は、革新的な保全プロジェクトを通じて、チリにおける水資源管理に取り組んでいます。サンティアゴ首都圏やバルパライソ地域に不可欠な水を供給するマイポ川流域において、AWS は、現地の農家や 気候テック企業である Kilimo と連携し、節水の取り組みを実施しています。このプロジェクトでは、67 ヘクタールの農地を湛水灌漑から点滴灌漑に転換します。これにより、年間約 2 億リットルの水が節約される予定です。 この節水活動は、2030 年までにウォーターポジティブとなることを目指す AWS のコミットメントを支えるものであり、AWS が事業を展開するコミュニティにおける環境の持続可能性への当社の取り組みを示すものです。このプロジェクトでは、専用の配管網を通して植物の根系に直接水を供給する効率的な点滴灌漑システムを採用し、農業用水効率を最大化しています。この取り組みの詳細については、ブログ記事「 AWS expands its water replenishment program to China and Chile—and adds projects in the US and Brazil 」をお読みください。 チリの AWS コミュニティ チリの AWS コミュニティは、この地域で最もアクティブなコミュニティの 1 つであり、 AWS Community Builders 、2 つの AWS User Group ( AWS User Group Chile と AWS Girls Chile )、 AWS Cloud Club で構成されています。これらのグループは毎月イベントを開催し、2 回の AWS Community Day を企画しました。2023 年に開催された最初の Community Day では、 Jeff Barr を基調講演のスピーカーとして迎えました。 Chile AWS Community Day 2023 引き続きご期待ください このリージョンや他のリージョンの開設については、今後のブログ記事でお知らせします。ご期待ください! 詳細については、 チリの AWS リージョンのページ にアクセスしてください。 – Eli Chile AWS Community Day 2023 の写真を提供してくださった Leonardo Vilacha 氏に感謝いたします。 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)