本記事は、2025 年 6 月 11 日に Networking & Content Delivery で公開された VPC resource gateways: Implementation patterns and use cases を翻訳したものです。 Amazon Virtual Private Cloud (Amazon VPC) 間でアプリケーションを接続する際、従来の AWS PrivateLink のプロバイダー・コンシューマーモデルに適合しないサービスへの接続が必要になると、VPC ピアリングや AWS Transit Gateway だけでは簡単に解決できない複雑なネットワーク課題に直面します。これは特に、IP アドレス空間が重複している場合に顕著です。 従来の PrivateLink の Provider-Consumer Model に適合しないサービスへの接続を、VPC リソースゲートウェイを使用することで実現でき、ネットワークアーキテクチャを簡素化できます。プロバイダーがサービスの前段に Network Load Balancer を配置することを求める VPC エンドポイントサービスとは異なり、リソースゲートウェイはロードバランサーインフラストラクチャの追加オーバーヘッドなしに、より幅広いターゲットを公開できます。 これまで複雑な追加設定が必要だったシナリオでも、追加インフラストラクチャの管理オーバーヘッドなしにサービスにアクセスできるようになりました。リソースゲートウェイは、ARN、DNS、または IP ベースのサービスへの接続を可能にしながら、セキュリティの維持、複雑さの軽減、コストの最適化を実現します。 リソースゲートウェイには複数のアクセス方法があります。 リソースエンドポイント 、 Amazon VPC Lattice サービスネットワークアソシエーション、および VPC Lattice サービスネットワークに接続された サービスネットワークエンドポイント です。本記事では、リソースへのアクセスを提供するために、リソースゲートウェイとリソースエンドポイントを使用したアーキテクチャパターンに焦点を当てます。Amazon VPC Lattice のサービスネットワークエンドポイントのユースケースと使用方法の詳細については、 こちらのブログ を参照してください。 以下のユースケースとトラフィックフローパターンを通じて、リソースゲートウェイの機能を理解していきましょう。 ユースケース 1：RDS リソースへのプライベートかつセキュアなアクセス 異なるビジネスユニットやアプリケーションコンポーネント間で厳密な分離を維持するために、マルチ VPC またはマルチアカウント戦略を採用している場合、アプリケーションサーバーとデータベースが異なる VPC や AWS アカウントに配置されます。また、このアーキテクチャパターンの要件は、合併・買収（M&A）の際にも発生します。 Amazon Relational Database Service (Amazon RDS) は、管理タスクを自動化することで従来型データベースの管理を簡素化します。 Amazon Aurora は、MySQL および PostgreSQL との完全な互換性を持つグローバルスケールのリレーショナルデータベースです。 Web/アプリケーションサーバーと RDS/Aurora データベースが異なる VPC に存在する場合、VPC ピアリングによる直接的な VPC 間通信や、AWS Transit Gateway / AWS Cloud WAN を使用したネットワーク接続のセットアップにより接続を確立できます。しかし、コンシューマーの数が急速に増加すると、これらの VPC ピアリング接続や AWS Transit Gateway / AWS Cloud WAN を経由するネットワークフローの管理オーバーヘッドが増大します。 リソースゲートウェイとリソース VPC エンドポイントを使用して、アプリケーションから Amazon RDS リソースへの接続を可能にできます。図1は、このユースケースのハイレベルアーキテクチャ図を示しています： 図1：RDS リソースへのプライベートかつセキュアなアクセス RDS リソースへのプライベートかつセキュアなアクセスを実現するために、以下の手順でリソースエンドポイントとリソースゲートウェイを構成できます： RDS リソースが存在する VPC にリソースゲートウェイを作成する。 アクセスしたい各 RDS クラスターまたはインスタンスに対して「ARN」タイプの リソース設定 を作成し、リソースゲートウェイに関連付ける。   注意 ：ARN ベースのリソースは現在、パブリックでない Amazon RDS リソースでサポートされています。ARN ベースのリソース設定の 子リソース設定 は、AWS によって自動的に管理されます。 （オプション） コンシューマー VPC と RDS VPC が異なる AWS アカウントにある場合、RDS VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に 「Resource」タイプの VPC エンドポイント を作成し、ARN タイプのリソース設定に関連付ける。VPC エンドポイントの作成時に、オプションで「Private DNS」を有効化する。Private DNS を有効にすると、リソース VPC エンドポイントを通じたプライベート接続を活用しながら、AWS サービスがリソースに対してプロビジョニングした DNS 名を使用してリクエストを続けることができます。   注意 ：Private DNS を使用するには、コンシューマー VPC の DNS ホスト名および DNS 解決が「有効」 （enableDnsHostnames, enableDnsSupport）に設定されていることを確認してください。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 VPC エンドポイントの Private DNS が有効時と無効時での動作を示す：   有効（推奨） ：RDS リソースの DNS 名（ライターエンドポイント、リーダーエンドポイント、またはインスタンスエンドポイント）を使用してリソースにアクセスできます。   無効 ：リソース VPC エンドポイントの DNS 名を使用して RDS リソースにアクセスします。ただし、これはデータベース証明書のコモンネーム（CN）を検証 していない 場合にのみ機能します。これは、リソース VPC エンドポイントの DNS 名が RDS/Aurora DB インスタンスの証明書のサブジェクト代替名（SAN）に含まれていないためです。 ユースケース 2：VPC IP CIDR が重複する環境での接続 CIDR が重複する VPC にコンシューマーとリソースが 存在する場合、それら間の直接通信が困難になります。このシナリオは、合併・買収時、パートナーネットワークへの接続時、または CIDR の計画が調整されていないマルチアカウント環境で一般的に発生します。この問題に対処する従来のソリューションには、NAT（ネットワークアドレス変換）を実行するアプライアンスの設定、NAT ゲートウェイの使用、または Network Load Balancer の作成と VPC エンドポイントサービスを使用したサービスの公開が含まれます。これらの解決策は有効ですが、追加リソースの作成が必要なため、複雑さとコストが増加します。 VPC リソースエンドポイントとリソースゲートウェイは、このような状況でコンシューマーがリソースにアクセスできるようにする、よりシンプルな代替手段を提供します。図2は、このユースケースのハイレベルアーキテクチャ図を示しています。 図2：重複 CIDR ユースケースにおけるリソースエンドポイントとリソースゲートウェイの使用 このケースでコンシューマーがリソースにアクセスできるようにするには、以下を実行します。 アクセス対象のリソースが存在する VPC にリソースゲートウェイを作成する。 リソースまたはリソースグループを表すリソース設定を作成し、リソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に、各リソース設定に対応する「Resource」タイプの VPC エンドポイントを作成する。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 リソース VPC エンドポイントの DNS 名を使用して、リソース VPC 内のリソースにアクセスする。フレンドリーな名前を使用してリソースにアクセスしたい場合は、「コンシューマー VPC」に関連付けられたプライベートホストゾーンを作成し、フレンドリー DNS 名をリソース VPC エンドポイントの DNS 名にポイントする CNAME レコードを追加できます。リソース VPC エンドポイントの DNS 名は、関連するリソース VPC エンドポイントを選択した際の「Associations」の下で確認できます。 図3：リソース VPC エンドポイントの DNS 名 ユースケース 3：パブリックドメインへの接続プロキシ パブリックエンドポイント宛ての通信であっても、一元化されたVPCを経由させるか、あるいはプライベートかつ制御されたネットワーク経路を使用することを義務付けるような厳格なポリシーを採用する場合を想定します。こうしたパブリックエンドポイントは、多くの場合 AWS 外の SaaS サービスか、AWS 上にありながら PrivateLink 経由ではプライベートに公開されていないサービスです。 リソースゲートウェイを使用して、集約 VPC 経由で、または AWS VPN 、 AWS Direct Connect 、VPC ピアリングなどのプライベート接続オプションを介したインクラウド接続ユースケースとして、パブリックエンドポイント（AWS またはサードパーティ）にアクセスできます。図4は、VPC 内のクライアントが集約 VPC とリソースゲートウェイを通じてパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 図4：集約 VPC とリソースゲートウェイによるパブリックエンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC 経由でパブリックエンドポイントへの接続を確立するには、以下のアプローチに従います： パブリックサブネットとプライベートサブネットを持つ VPC（「リソース VPC」）を作成する。VPC ルーティングを設定し、プライベートサブネットからインターネットへのトラフィックがパブリックサブネット内の NAT ゲートウェイを経由してルーティングされることを確認する。 リソース VPC のプライベートサブネットにリソースゲートウェイを作成する。 コンシューマーにアクセスさせたい各ドメイン名に対して、「DNS」タイプのリソース設定を作成する。各 DNS リソース設定は、コンシューマーにアクセスさせたい単一のドメイン名にマッピングされます。複数のドメイン名にアクセスさせたい場合は、複数のリソース設定を単一の「リソースグループ」にグループ化し、単一のリソース VPC エンドポイントで複数ドメインにアクセスできるようにできます。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS Resource Access Manager(RAM) を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 プライベートホストゾーン（コンシューマー VPC に関連付け）を作成し、アクセスするパブリック FQDN をリソースエンドポイントの対応する DNS 名にマッピングする CNAME タイプのレコードを追加する。リソースエンドポイントの DNS 名の確認方法については、図2を参照。 プライベートホストゾーンで作成したレコードを使用して、アプリケーションからパブリックエンドポイントにアクセスする。 同様に、オンプレミスと AWS 間の確立済みプライベート接続を通じて、パブリックエンドポイントへのトラフィックをルーティングすることもできます。これにより、アウトバウンドインターネット接続を信頼できるエンドポイントに制限し、オンプレミスのクライアントがネットワーク分離を維持しコンプライアンス要件を満たしながら、パブリック FQDN とセキュアに通信できるようになります。図5は、オンプレミスのクライアントが AWS Site-to-Site VPN / AWS Direct Connect を介してリソースゲートウェイ経由でパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 ※訳者注：集約 VPC の IGW からのアウトバウンド通信は TGW での接続が分かりやすく一般的ですが、TGW のデータ処理料金は $0.02/GB、リソースエンドポイントのデータ処理料金は $0.01/GB であり、本方式は特にデータ量が圧倒的である場合、コスト削減に大きく寄与します。 図5：集約 VPC とリソースゲートウェイによるオンプレミスからのパブリックエンドポイントへのアクセス ユースケース 4：Transit Gateway や VPC ピアリングを経由せずに AWS サービスのインターフェースエンドポイントを集約する インターネットを経由せずに AWS サービスへのプライベート接続を実現するには、インターフェース VPC エンドポイントを使用できます。しかし、各 VPC でサービスごとに個別のインターフェース VPC エンドポイントを作成すると、大きなコストと管理の複雑さにつながる可能性があります。そのため、より効率的なアプローチは、必要な すべてのインターフェースエンドポイントをホストする集約 VPC を用意し、AWS Transit Gateway または AWS VPC ピアリング接続を使用してコンシューマー VPC とリソース VPC 間の接続を確立し、集約 VPC エンドポイントへの接続を実現することです。 リソースゲートウェイとリソースエンドポイントは、このユースケース（特に大規模ネットワーク）に対処するための、よりシンプルでコスト効率の高いオプションを提供します。Transit Gateway アタッチメントよりも低い全体コスト（時間あたりおよびデータ処理）で、単一のリソースエンドポイントを作成して複数の AWS サービスエンドポイントにアクセスできます（集約 VPC エンドポイントが主なユースケースであることを前提）。図6は、このユースケースのハイレベルアーキテクチャ図を示しています。 図6：リソースゲートウェイを使用した集約 VPC エンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC エンドポイントへのプライベート接続を確立する方法は以下のとおりです。 リソース VPC に、要件に応じた AWS サービスの集約インターフェース VPC エンドポイントを作成する。 リソース VPC にリソースゲートウェイを作成する。 各 AWS サービス VPC エンドポイントに対して、「DNS」のリソース定義を持つリソース設定を作成する。ドメイン名には、インターフェース VPC エンドポイントのリージョナル DNS 名を追加する（例： vpce-xxxx.ec2.<region>.vpce.amazonaws.com ）。   注意 ：リソースゲートウェイでは、リソース設定の DNS 名がパブリックに解決可能である必要があるため、インターフェース VPC エンドポイントのプライベート DNS 名は機能しません。 子 DNS リソース設定を持つリソースグループを作成し、リソースグループをリソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 （オプション）異なるドメイン名を使用してサービスエンドポイントにアクセスしたい場合は、ドメイン名 <region>.amazonaws.com のプライベートホストゾーンを作成し、コンシューマー VPC に関連付ける。アクセスする各サービスに対してプレフィックス付きの CNAME タイプのレコードを追加し（例： <prefix>.ec2.<region>.vpce.amazonaws.com ）、リソースエンドポイントの対応する DNS 名にポイントする。TLS 検証が正常に行われるようにするため、プライベートホストゾーンとレコードは上記の形式である必要がある。 プライベートホストゾーンで作成したレコード（例： <prefix>.<region>.vpce.amazonaws.com ）、またはリソースエンドポイントの DNS 名を使用して、アプリケーションからインターフェースエンドポイントにアクセスする。 まとめ 本記事では、VPC リソースゲートウェイを使用して AWS 環境における複雑なネットワーク課題を簡素化する方法を説明しました。プライベートなデータベース接続の確立、IP アドレスが競合するネットワーク間の通信の実現、セキュアなインターネットアクセスの作成、AWS サービスアクセスの合理化について解説しました。これらのソリューションは、VPC リソースゲートウェイが強固なセキュリティを維持しながら一般的なネットワーク課題に対処する方法を示しており、成長に合わせたクラウドアーキテクチャの構築に有用なツールとなります。 AWS ネットワーク構成を簡素化する準備はできましたか？ VPC リソースゲートウェイ のドキュメントを参照して、今すぐリソースゲートウェイの実装を開始し、ご自身の AWS 環境でこれらのパターンを試してみてください。 翻訳はソリューションアーキテクトの長屋が担当しました。

こんにちは、タイミーでバックエンドエンジニアをしている 福井 (bary822) です。 タイミーのバックエンドは巨大な Rails のモノリスアプリケーションです。以前から「アクセスが集中する特定のテーブル（以下、人気テーブル）への DB マイグレーションが日中に通らない」という問題を抱えており、看過できないレベルになってきたため、本格的に対処に乗り出しました。 この記事では、原因となっていたロングトランザクションに対し、Datadog と Devin を組み合わせた自動修正フローで対処した話と、その設計の裏側を紹介します。 DBマイグレーション失敗のメカニズム 日常的に発生していたのは、人気テーブルへの ALTER TABLE が日中はほぼ通らない、という状況でした。原因は メタデータロック (MDL) です。 Aurora MySQL(8.0) では、SELECT / INSERT / UPDATE / DELETE などの DML が対象テーブルの MDL（共有ロック）を取得する MDL はテーブルなどのメタデータに対して取得されるロックであり、共有 MDL が保持されている間は ALTER TABLE に必要な排他 MDL を取得できずロック待ちになる MDL が解放されるまで ALTER TABLE はブロックされるため、1 本でも長い時間走るトランザクション（以下、ロングトランザクション）があると、その裏で ALTER TABLE がタイムアウトしてしまう つまり、クエリ実行頻度の高い人気テーブルほど日中は触れなくなり、「カラムを別テーブルに切り出す」「カラム、インデックスの削除を諦める」といった、技術的制約が設計を歪める方向に力学が働き始めていました。 このマイグレーション失敗そのものに対しては、これまで strong_migrations gem のロック取得リトライ機能（ lock_timeout_retries など）で何とか対策してきました。しかし、これらはあくまで成功確率を上げる ための投機的なアプローチにとどまり、根本原因であるロングトランザクションそのものには手を入れられていませんでした。 ロングトランザクション修正の方針 これまで見てきた通り、根本原因はロングトランザクションそのものです。そこで、リトライで凌ぐ運用から一歩踏み込んで、いよいよロングトランザクション自体を減らしていく方向に舵を切ることにしました。 とはいえ、現時点において目立ったロングトランザクションを頑張って解消したとしても、今後開発者が意図せず新たなロングトランザクションを生み出してしまう可能性は大いにあります。 かといってマージ前にロングトランザクションを検出するのも現実的ではありませんでした。トランザクションの長さは、多くの場合そのレコード（スキャン）量に依存しており、本番で実行してみるまで検知しにくいからです。 そこで本番リリース前の検知は諦めて、リリース後にできるだけ早く検知する方針にしました。また、検知から修正、レビューまでをできるだけ自動化し、人間は最終判断要員として介入するだけで済む状態にすることで持続可能な運用を目指すことにしました。 仕組みの全体像 上記方針をもとにいくつかのプランを検討した結果、タイミーで既に導入されていた Datadog、Devin などを組み合わせ、以下の 5 フェーズからなる自動化フローを構築しました。 準備: ActiveRecord Query Logs を有効化し、クエリの発行元がSQLコメントとして埋め込まれるようにしておく 観測: Datadog Agent から本番 DB に対して定期クエリを実行し、 performance_schema と information_schema の情報をもとに、テーブルごとにMDLを取得するロングトランザクション時間をカスタムメトリクスとして Datadog に送信する テーブルごとにMDLを保持しているトランザクションのうち、計測時点で最も時間が長い秒数を記録する 検知: Datadog Monitor にてテーブルごとに一定のしきい値を超えるロングトランザクションを検知する 修正 : Datadog Monitor で発火されたアラートをトリガーとして、Datadog Workflow Automation を起動。コンテキストを整理して GitHub Actions 経由で Devin Session を起動し、修正 PR を作成 レビュー : 「修正対象のコードに詳しい人」を自動的に判定してアサイン + AI による事前レビュー ロングトランザクション修正フローの構成図 以下、それぞれのフェーズで工夫したポイントを紹介します。 準備: クエリの発行元を明らかにする Rails 7 から標準提供されている ActiveRecord Query Logs には豊富なオプションが用意されており、クエリの発行元をコメントとして付与する対象を限定することができます。 https://railsguides.jp/v8.1/configuring.html#config-active-record-query-log-tags タイミーでは次の設定を入れています。 config.active_record.query_log_tags_enabled = true config.active_record.query_log_tags = %i[namespaced_controller action sidekiq_worker rake_task] 観測: ロングトランザクション発生状況を可視化する MySQL では performance_schema と information_schema の情報を組み合わせることで「テーブルごとのその時点で実行されている最も長いMDLを取得するトランザクション」を特定することができます。 さらにクエリコメントとして付与された発行元の情報を組み合わせることで「どこから実行されたトランザクションが何秒実行されているか」が特定可能になります。 次の例では、テーブル名を table_name 、クエリの発行元を query_source として取得しています（ query_source は、実際の出力を見ながら扱いやすいように加工している）。 計測クエリ例 SELECT table_name, CASE WHEN raw_sql LIKE '%namespaced_controller:%' THEN CONCAT( TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'namespaced_controller:', -1), '*/', 1), ',', 1)), '#', TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'action:', -1), '*/', 1), ',', 1)) ) WHEN raw_sql LIKE '%sidekiq_worker:%' THEN TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'sidekiq_worker:', -1), '*/', 1), ',', 1)) WHEN raw_sql LIKE '%rake_task:%' THEN CONCAT('rake:', TRIM(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(raw_sql, 'rake_task:', -1), '*/', 1), ',', 1))) ELSE 'unknown' END AS query_source, tx_duration_seconds AS max_tx_duration_seconds FROM ( SELECT CASE WHEN ml.OBJECT_NAME LIKE '#sql-%' THEN 'DDL_IN_PROGRESS' ELSE ml.OBJECT_NAME END AS table_name, COALESCE(esc.SQL_TEXT, it.trx_query, '') AS raw_sql, TIMESTAMPDIFF(SECOND, it.trx_started, NOW()) AS tx_duration_seconds, ROW_NUMBER() OVER ( PARTITION BY CASE WHEN ml.OBJECT_NAME LIKE '#sql-%' THEN 'DDL_IN_PROGRESS' ELSE ml.OBJECT_NAME END ORDER BY TIMESTAMPDIFF(SECOND, it.trx_started, NOW()) DESC ) AS rn FROM performance_schema.metadata_locks ml JOIN performance_schema.threads th ON ml.OWNER_THREAD_ID = th.THREAD_ID JOIN information_schema.innodb_trx it ON th.PROCESSLIST_ID = it.trx_mysql_thread_id LEFT JOIN performance_schema.events_statements_current esc ON th.THREAD_ID = esc.THREAD_ID WHERE ml.OBJECT_TYPE = 'TABLE' AND ml.OBJECT_SCHEMA NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys') AND TIMESTAMPDIFF(SECOND, it.trx_started, NOW()) >= 5 ) ranked WHERE rn = 1 このクエリを何かしらの方法で本番DBに対して定期的に実行し、その結果をどこかに貯めておけばロングトランザクション発生状況を可視化できます。 Datadog ではこれを簡単に行うことができました。アプリケーションが実行されているものとは別のサービスとして ECS 上で常時稼働している Datadog Agent にて定期的にクエリを実行し、その結果をカスタムメトリクスとして Datadog に送信しています。 Aurora MySQL での設定方法: https://docs.datadoghq.com/ja/database_monitoring/setup_mysql/aurora 検知: 修正対象のロングトランザクションを絞り込む カスタムメトリクスとして1度 Datadog に取り込んでしまえば、それを使ってアラート(Datadog Monitor)を仕込むことは簡単です。 メトリクスはクエリ発行元( query_source )でグルーピングして監視するようにしました。こうすることで後続のフローに「どのクラス(ファイル)でロングトランザクションが発生したか」を渡せるようになります。 また、発行元が特定できなかったものや定期実行しないバッチなどは対象外としました。 以下が Datadog Monitor のクエリです。( !query_source:rake:tmp:* は定期実行しないバッチを取り除くためのものです) default_zero(avg:custom.mysql.mdl_holder.max_tx_duration_by_table{account:timee-jp-prod,replication_role:writer, !query_source:unknown, !query_source:rake:tmp:*} by {query_source}) しきい値はまずはアラートがノイズにならない程度(後続の修正フローによって作成されるPRのレビューが負担にならない程度)から始めることをおすすめします。 タイミーの場合は当初数百 sec を超えるロングトランザクションが発生していたため、まずは 100 秒をしきい値として設定しました。 この時点でロングトランザクションの発生元が限られている場合は、後続の自動修正フローを構築する前に、まずはそれらだけを対象にいったん修正してみるのも効果的かもしれません。 修正: パターン集で修正アプローチを制御する Datadog Monitor のしきい値超過をトリガーに、Datadog Workflow Automation を起動します。ここでは、Monitor から渡されたロングトランザクションに関する情報（クエリ実行元、発生時間など）を取りまとめ、GitHub Action 経由で Devin Session を起動して、詳細な原因調査と修正PRの作成を行います。 また、数百秒にわたるロングトランザクションでは、Monitor が重複してトリガーされる可能性があります。そのため、同一クエリ発行元に対して Devin Session が重複実行されないようにする必要がありました。具体的には、Session 起動時のタグに query_source を設定し、新しい Session を起動する前に既存の起動有無をチェックして、利用料金の無駄を防いでいます（初期段階ではこのチェックがなく、一夜にして数百ドルかかったことがありました）。 Devin による修正では Datadog MCP 経由で APM などの情報を分析させることで詳細な原因調査を行っていますが、しばらく運用しているうちにロングトランザクションの発生とその修正方法には一定のパターンがあることを発見しました。そこであらかじめ修正パターンをドキュメント化してレポジトリに置いておき、それを Devin に参照させるようにしました。こうすることで調査のアタリをつけやすくなりコンテキストの節約に寄与したり、実行時間を短縮することができました。 修正パターンドキュメント例 # トランザクション内の外部APIコールを排除する ## 概要 トランザクション（`with_lock` / `transaction do`）の内側で外部APIコール（HTTP リクエスト、LLM API、外部 SDK 呼び出しなど）を実行している場合、通信時間の間ずっとMDL（Metadata Lock）が保持され続けます。外部呼び出しの所要時間は秒〜分単位に及ぶことがあり、これがロングトランザクションの**最も典型的な原因**です。 改善の基本方針は、外部呼び出しをトランザクション外に出して **MDL保持時間を最小化** することです。完全な除去ではなく **トランザクションスコープの最小化** を第一選択とし、ロックが守ろうとしていたデータ整合性は別の手段（ステータス管理・楽観的整合性チェックなど）で維持します。 ## 問題のシグネチャ - **コード上の特徴**: - `with_lock do ... end` または `transaction do ... end` の内部に、HTTP クライアント呼び出し（Net::HTTP, Faraday, RestClient など）、AWS SDK 呼び出し、LLM API 呼び出し、メール送信、Slack 通知などが含まれている - 外部呼び出しが完了してから `save!` / `update!` が呼ばれる流れになっている - **APMトレース上の特徴**: - トランザクション開始から終了までのスパン内に、`http.client` / `aws.s3` / `openai.api` 等の子スパンがある - DB クエリの所要時間より外部呼び出しスパンの所要時間のほうが長い - 「DB時間 << 全体時間」のトレースが頻発している ## Before / After ```ruby # Before（外部APIコールがトランザクション内 → MDLを長時間保持） def process with_lock do reload return false unless entered? result = call_external_api! # 外部APIコール → 最大120秒のMDL保持 save_result!(result) end end # After（トランザクションを分離してMDL保持時間を最小化） def process # 短いトランザクション: ステータス確認のみ with_lock do reload return false unless entered? end # 外部APIコールはトランザクション外で実行（MDLを保持しない） result = call_external_api! save_result!(result) end ``` ### 楽観的整合性チェックの追加（再enqueueパターンがある場合） 対象の処理が「データ変更時に再enqueueされる」設計の場合、以下のリスクが生まれます： - Worker A がデータ読み込み後にトランザクションを終了 - レコードが更新され Worker B が enqueue - Worker A が古いデータで重い処理を続行 - Worker B が新しいデータで上書き（結果整合性は保たれるが Worker A の処理は無駄になる） このリスクを緩和するため、トランザクション終了後に再enqueueトリガーと同じ変化検知ロジックでデータの鮮度を確認し、変化があれば中断する楽観的チェックを追加します。 ```ruby # トランザクション内でスナップショット取得 before_checker = SomeChecker.new(record) data = load_data_in_transaction # トランザクション外で鮮度確認(重い処理の前) current_record = Record.includes(...).find(id) return if before_checker.changed?(current_record) # Worker Bに任せる # 重い処理を実行 process(data) ``` ## 効果 - MDL保持時間が **秒〜分単位** で短縮される（外部呼び出しの所要時間ぶん） - ロングトランザクション（長時間 MDL 保持）アラートの発火回数が大幅に減少することが期待される - 同テーブルへの他アクセス（マイグレーション・更新クエリ）の待ち時間も短縮される ## 注意点・トレードオフ - **排他制御が弱まる可能性**: トランザクション外に出すことで排他制御が弱まる場合があります。 ` retry: false ` の Sidekiq Worker など、同一レコードが同時処理されるリスクが低い場合は許容できます - **堅牢化の選択肢**: より堅牢にするには、トランザクション内でステータスを ` processing ` に変更してから外部呼び出しを行うパターンが有効です（スキーマ変更が必要な場合は別PRで対応） - **楽観的整合性チェックの適用条件**: 対象レコードの更新が同一Workerの再enqueueをトリガーする設計になっている場合のみ必要。再enqueueしない設計では不要です - **完全除去は最終手段**: ロックの完全除去は、保護が不要であることを論理的に説明できる場合にのみ行ってください。経緯（ ` git log ` / ` git blame ` ）を確認せずに削除すると、過去に修正済みのバグを再発させるリスクがあります ``` # Before（外部APIコールがトランザクション内 → MDLを長時間保持） def process with_lock do reload return false unless entered? result = call_external_api! # 外部APIコール → 最大120秒のMDL保持 save_result!(result) end end # After（トランザクションを分離してMDL保持時間を最小化） def process # 短いトランザクション: ステータス確認のみ with_lock do reload return false unless entered? end # 外部APIコールはトランザクション外で実行（MDLを保持しない） result = call_external_api! save_result!(result) end ``` ### 楽観的整合性チェックの追加（再enqueueパターンがある場合） 対象の処理が「データ変更時に再enqueueされる」設計の場合、以下のリスクが生まれます： - Worker A がデータ読み込み後にトランザクションを終了 - レコードが更新され Worker B が enqueue - Worker A が古いデータで重い処理を続行 - Worker B が新しいデータで上書き（結果整合性は保たれるが Worker A の処理は無駄になる） このリスクを緩和するため、トランザクション終了後に再enqueueトリガーと同じ変化検知ロジックでデータの鮮度を確認し、変化があれば中断する楽観的チェックを追加します。 ``` # トランザクション内でスナップショット取得 before_checker = SomeChecker.new(record) data = load_data_in_transaction # トランザクション外で鮮度確認(重い処理の前) current_record = Record.includes(...).find(id) return if before_checker.changed?(current_record) # Worker Bに任せる # 重い処理を実行 process(data) ``` ## 効果 - MDL保持時間が **秒〜分単位** で短縮される（外部呼び出しの所要時間ぶん） - ロングトランザクション（長時間 MDL 保持）アラートの発火回数が大幅に減少することが期待される - 同テーブルへの他アクセス（マイグレーション・更新クエリ）の待ち時間も短縮される ## 注意点・トレードオフ - **排他制御が弱まる可能性**: トランザクション外に出すことで排他制御が弱まる場合があります。 ` retry: false ` の Sidekiq Worker など、同一レコードが同時処理されるリスクが低い場合は許容できます - **堅牢化の選択肢**: より堅牢にするには、トランザクション内でステータスを ` processing ` に変更してから外部呼び出しを行うパターンが有効です（スキーマ変更が必要な場合は別PRで対応） - **楽観的整合性チェックの適用条件**: 対象レコードの更新が同一Workerの再enqueueをトリガーする設計になっている場合のみ必要。再enqueueしない設計では不要です - **完全除去は最終手段**: ロックの完全除去は、保護が不要であることを論理的に説明できる場合にのみ行ってください。経緯（ ` git log ` / ` git blame ` ）を確認せずに削除すると、過去に修正済みのバグを再発させるリスクがあります Devin は与えられたコンテキストとパターン集を照らし合わせ、当てはまるパターンがあればこれを参考に修正。なければ新規パターンとしてドキュメントを追加します。 つまり、Devin が直せば直すほど、次の Devin が使えるドキュメントが増えていくループを、リポジトリ内で完結する形で作っています。プロンプトの調整も普通の PR ベースで行えるので、レビュアーからのフィードバックが自然と AI 側の挙動改善に還元されていきます。 レビュー: 「そのコードに詳しい人」を特定する ロングトランザクション修正は、コードの表面的な変更だけでは判断できないケースが多く、実装の意図やドメイン背景を知っている人のレビューが不可欠です。 そこで、次の手順でレビュアーを決めています。 コードオーナーが設定されていれば、その人(チーム)をレビュアーとする なければ、直近 1 年間で最も多くそのファイルに commit したユーザーとその時点での所属チーム 1 年以内に commit がなければ、特定チーム(私が所属するチーム) これはプロンプトベースだと間違ったアサインを行うことがあったため、スクリプト化しました。 さらに、作成された PR に対して AI レビューを実行しています。Devin はレビューに対して自動で対応を行うため、人間レビュアーの目に届く時点で、AI 同士の一次すり合わせは終わっている状態になっています。 運用上のポイント 昨今、コーディングエージェントの性能向上やその周辺ツールの充実により、このような自動修正フローを簡単に構築することができるようになりました。 一方で「作った仕組みを普段の開発フローの中で無理なく運用する方法」をセットで実装することは以前に増して重要になってきたように思います。 今回のケースでは下記3点を特に意識して実装に落とし込みました。 人間の目に触れる前までに無駄を削ること 人間が対応する場合の工数を可能な限り小さくすること 無理なく運用できるペースで継続できること AI による相互レビューで無駄を削る 前述の AI 相互レビューでは次の観点でPRの妥当性を判断しています。 この変更は本当に長時間MDLを生み出すボトルネックにアプローチしているか? この変更が長時間MDLを解消するための必要最小限の変更か? 長時間MDLを解消しつつ、元の振る舞いを極力維持できているか？ たとえ修正によってあるトランザクションがMDLを取得する時間が短くなったとしても、それが検出されたロングトランザクションを十分に解消する(アラートが鳴らなくなるレベル)でなければ修正する価値はありません。 また、修正できたとしてもその変更範囲が膨大になってしまえばレビュアーの負荷が高くなり、いつまでもマージできないことで運用が回らなくなってしまいます。 AI レビューでこれらの観点を満たさない場合は PR を クローズする運用を行っています。 「対応しない」ことも選択肢におく 継続的な運用で意外と重要なのが、「対応しない」判断を尊重することです。 Devin が作った PR が、レビュアーの目から見て対応しないと判断されることは普通にあります。多くの場合トランザクションの範囲を小さくしたりトランザクション自体を無くすことはデータの整合性とトレードオフの関係にあるからです。 このとき単にクローズして終わりだと、次に同じクエリ発行元( query_source )でトリガーされたときにまた同じ PR が生成されてしまいます。 これを避けるために、「対応しない」ことがあるという前提で運用を考えました。また、対応しない場合の工数もできる限り小さくなるようにしています。 対応しないものは query_source 単位で Ignore List として管理し、リポジトリに含めておく Ignore List の実体はただの query_source のリスト(フォーマットは JSON、YAML など何でもいい) レビュアーが PR に long-transaction-wontfix ラベルを付けるとGitHub Actions が起動し、それまでの commit を破棄して Ignore List に追加する ⚠️ Ignore List は query_source 単位なので、同じ query_source の別箇所で新たにロングトランザクションが発生しても検知されなくなります。厳密な検知性より運用のシンプルさを優先した割り切りで、必要があれば粒度を後から変えられるようにしています。 しきい値を下げて対象を広げていく ここまでの仕組みは、Datadog Monitor のしきい値(初期構築時は 100 s)を超えたロングトランザクションを対象にしています。運用初期はやや保守的な値に置き、専用のダッシュボードにまとめたロングトランザクション発生状況や作成された修正 PR 数やマージ数、レビュアーの偏りを見ながら、段階的に下げていく運用を行っています。 現在では無理なく運用しながらしきい値を 50s まで引き下げられており、人気テーブルによっては MDL 保持時間が以前の半分以下になりました。 定期観測しているダッシュボード。画面上部のメトリクス(MDL保持時間)が時間が進むにつれて改善されている(短くなっている)ことがわかる おわりに 以前投稿した Flaky Test 自動修正の取り組みとテーマは違いますが、同じようなパターンでロングトランザクションを改善する仕組みの実装と運用ノウハウを紹介しました。 tech.timee.co.jp 今回のケースでは変更によるトレードオフが発生する特性があるため、「対応しない」という選択も同じように尊重する必要がありました。そこでロングトランザクションを駆逐するのではなく、あくまでも現状を緩和することをターゲットに置いたことで現実的に持続可能な運用に落とし込むことができました。 問題の発生を検知し、自動で原因分析から修正 PR の作成まで行うパターンは、他の問題にも適用できる汎用性があります。そのため、ついつい多用したくなってしまいます。しかし、開発サイクルのどこかに人間が介在する限り持続可能な運用に落とし込むことが重要になっていることをあらためて実感しています。 最後までお読みいただき、ありがとうございました！

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 2026 年も折り返し地点を過ぎ、いよいよ下半期に入りました！上半期は生成 AI とエージェントに関するアップデートが目立ちましたが、その勢いは下半期も止まる気配がありません。今週も Claude Sonnet 5 の登場や Amazon WorkSpaces for AI agents の一般提供開始など、エージェント活用を後押しするアップデートが多数ありました。 一方で 6/30 には AWS のサービス提供状況が更新され、いくつかのサービスがメンテナンスモードやサンセット (提供終了予定) へ移行しています。本記事にて主張なアップデートとして取り上げておりますのでご確認の上、該当サービスをご利用中の方は、代替サービスへの移行計画をお早めにご検討ください。 それでは、先週の主なアップデートについて振り返っていきましょう！ 2026年6月29日週の主要なアップデート 6/29(月) Amazon S3 サーバーアクセスログが Amazon CloudWatch Logs と Amazon S3 Tables への配信に対応 Amazon S3 のサーバーアクセスログを Amazon CloudWatch Logs へ直接配信できるようになりました。これにより、アクセスログデータに対する即時クエリ、アラーム、クロスアカウント/クロスリージョンの集約、AWS Key Management Service (KMS) 暗号化が利用可能になります。また、追加のストレージコストなしで Apache Iceberg 形式の Amazon S3 Tables にミラーリングすることも可能です。CloudWatch Logs への配信ではエラー率のアラーム設定やアクセスインシデントの調査などに活用できます。S3 Tables にミラーリングされたログは Amazon Athena や Amazon Redshift など Iceberg 互換のクエリエンジンから標準 SQL で即座にクエリでき、アクセスパターンの監査やコスト要因の分析に役立ちます。AWS 中国リージョンおよび AWS GovCloud (米国) を除くすべての AWS リージョンで利用可能です。 AWS WAF が Amazon Bedrock AgentCore Gateway のサポートを追加 Amazon Bedrock AgentCore Gateway 向けの AWS ウェブアプリケーションファイアウォール (AWS WAF) 保護の一般提供が発表されました。エージェンティック AI ワークロードを一般的なウェブ脆弱性や悪用から保護できるようになります。AWS WAF 保護パックを AgentCore Gateway に関連付けることで、IP ベースのアクセスコントロール、レートベースのルール、一般的なルールセット・既知の不正入力・Bot Control を含む AWS マネージドルールグループを適用できます。Gateway レベルで一度設定するだけで、その背後にあるすべてのターゲットに一貫して適用されるため、単一の設定でダウンストリームのツールやエージェント、統合をまとめて保護できるのがポイントです。AWS WAF と Amazon Bedrock AgentCore Gateway の両方が利用可能なすべての AWS リージョンで提供されます。 6/30(火) AWS のサービスおよび機能の提供状況変更のお知らせ 複数の AWS サービスおよび機能について、提供状況が更新されました。メンテナンスに移行するサービスは 2026 年 7 月 30 日以降、新規のお客様はご利用いただけません (既存のお客様は継続利用可、AWS の運用・サポートも継続)。対象は、Amazon Bedrock Agents (2023 年 11 月リリース版、Amazon Bedrock Agents Classic に名称変更)、Amazon Cognito Sync、Amazon Kendra、Amazon Q Business、AWS Directory Service – Simple AD、AWS IoT Device Defender – Detect (2026 年 8 月 31 日以降)、AWS Mainframe Modernization – Self-Managed Experience、AWS Management Console – myApplications、AWS Resource Groups – Group Lifecycle Events、AWS Service Catalog – Application Registry、AWS Systems Manager – Application Manager、Amazon SageMaker AI の A2I / Clarify / Debugger / GeoSpatial / Ground Truth / Mechanical Turk / Model Monitor / Role Manager / Studio Lab です。サンセット (提供終了予定) に移行するサービスは、Amazon WorkSpaces – PCoIP / Pool、AWS Managed Services (AMS) Advanced、AWS re:Post Private、Amazon SageMaker AI – Profiler です。2026 年 6 月 30 日をもってサポート終了となったのは、Amazon Chime SDK – Carrier Voice Focus、Amazon SageMaker AI – Ground Truth Plus です。詳細は AWS 製品ライフサイクルページをご覧ください。 Amazon SageMaker AI が Gemma 4 モデルのサーバーレスモデルカスタマイズをサポート Amazon SageMaker AI が、教師ありファインチューニング (SFT)、直接選好最適化 (DPO)、強化ファインチューニング (RFT) を用いた Gemma 4 E4B および 31B モデルのサーバーレスカスタマイズをサポートするようになりました。Gemma は Google DeepMind が構築したオープンモデルのファミリーです。今回のリリースにより、Gemma 4 を含む Nova、Nemotron 3、Qwen、Llama、gpt-oss、DeepSeek などのモデルファミリーが SageMaker AI でサーバーレスカスタマイズに利用できるラインナップに揃いました。サーバーレスカスタマイズではインフラのプロビジョニングとトレーニングのオーケストレーションを SageMaker AI が引き受けてくれるため、クラスター管理ではなくデータと評価に集中できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用可能です。 Claude Sonnet 5 が利用可能に AWS で Claude Sonnet 5 の提供が開始されました。Anthropic の最新世代における最初の Sonnet モデルで、Sonnet の価格帯を維持しつつコーディング・エージェント・専門業務でトップクラスのインテリジェンスを提供します。コーディングでは大規模なコードベースの複数ファイルにまたがる変更やデバッグ・リファクタリングを、エージェント用途ではツール呼び出しや多ステップの状態保持・エラー回復を、ナレッジワークではドキュメント起草や非構造化データの構造化変換をこなします。アクセス方法はAmazon Bedrock 経由での利用と Claude Platform on AWS での利用の2 種類あります。Amazon Bedrock 経由ではデータを AWS インフラストラクチャ内に保持したまま、Guardrails や Knowledge Bases、リージョンデータレジデンシーなどのマネージド機能と組み合わせて利用できます。Claude Platform on AWS では、AWS コンソールから Anthropic のネイティブプラットフォーム体験に直接アクセスでき、Anthropic と直接やり取りする場合と同じ API・機能・コンソールを AWS の請求と認証に統合された形で利用できます。 Amazon WorkSpaces for AI agents の一般提供を発表 AI エージェントがマネージド WorkSpaces 環境を通じてデスクトップアプリケーションに安全にアクセス・操作できる Amazon WorkSpaces for AI agents が、一般提供開始となりました。ERP、CRM、メインフレーム、独自ツールなど、モダナイズが難しいデスクトップアプリケーションを、アプリの改修なしにエージェントから操作できるのが特徴です。エージェントは人間のユーザーと同じ ID 制御、ネットワーク分離、コンプライアンス境界を継承するため、ガバナンスを損なわずに保険金請求処理や取引決済などのバックオフィス業務を自動化できます。Model Context Protocol (MCP) を使うあらゆるエージェントフレームワークと連携します。プレビュー期間中のフィードバックを反映し、MCP 呼び出しで直接アプリケーションや OS を操作する MCP ツールフォワーディング、オペレーターがエージェント活動をライブで可視化しセッション中のアクセスを取り消せるリアルタイムセッション制御、既存の Active Directory ID の下で動作させられるドメイン参加フリートサポートといった機能も追加されています。 7/1(水) Amazon OpenSearch Service にログ分析向けに最適化された新エンジンが登場 Amazon OpenSearch Service に、ログ分析ワークロード向けに専用設計された新エンジンが導入されました。集計ワークロード向けのカラムナーストレージにより最大 70% のストレージ削減を実現し、同じコストで最大 3 倍のデータを保持できます。加えて、同じハードウェアで最大 2 倍の取り込みスループットと 2 倍高速な分析クエリを提供します。ポイントは、OpenSearch が得意とするフルテキスト検索と、新エンジンによる高速な集計・分析クエリを同一クエリ内で組み合わせられる点で、集計とインシデント調査を 1 つのドメインで両立できます。開始するには OpenSearch 3.5 以上でドメインを作成し、オブザーバビリティのユースケースを選択、エンジンモードを optimized に設定してください。米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、カナダ (中部)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、欧州 (フランクフルト、アイルランド、ロンドン、スペイン) のグローバル 12 リージョンで利用可能で、新エンジンの利用に追加料金はかかりません。 AWS AppConfig が A/B テスト向けのマネージド実験ツールを提供開始 AWS AppConfig で、A/B テストや機能実験を実行できる実験ツールの一般提供が開始されました。個別の実験インフラストラクチャを構築・管理する必要なく、25 年以上にわたる Amazon の実験ベストプラクティスをベースに、AI 駆動のガイダンスで堅牢な実験の構築を支援します。UI 変更やレコメンデーションアルゴリズム、AI モデルの選択やプロンプト実験まで、アプリケーションスタック全体で A/B テストや多変量実験を実行可能で、機能バリエーションの定義やトラフィック割り当て率の設定を、AWS Management Console、CLI、API、AWS CDK から行えます。結果は Amazon CloudWatch や既存の分析ツールで分析でき、勝ちパターンは AppConfig の安全なロールアウトで本番環境へ適用できます。この機能は Amazon EC2、AWS Lambda、Amazon ECS、Amazon EKS、AWS AppConfig Agent 経由のオンプレミスサーバー上で動作します。AWS GovCloud (米国) を含むすべての AWS リージョンで利用可能です。 Amazon RDS のクロスリージョン自動バックアップが 4 つの追加 AWS リージョンで利用可能に Amazon RDS のクロスリージョン自動バックアップレプリケーションが、4 つの AWS リージョンで追加提供されました。今回のリリースで、メキシコ (中部) と欧州 (アイルランド) または米国西部 (北カリフォルニア) の間、アジアパシフィック (台北) とアジアパシフィック (シンガポール) または アジアパシフィック (東京) の間、アジアパシフィック (ニュージーランド) とアジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (メルボルン) の間、アジアパシフィック (タイ) とアジアパシフィック (シンガポール) または アジアパシフィック (ジャカルタ) の間で、自動バックアップレプリケーションを設定できるようになりました。クロスリージョン自動バックアップレプリケーションでは、RDS がスナップショットとトランザクションログを選択した送信先リージョンへレプリケートしてくれるので、プライマリリージョンが利用できなくなった場合でも、セカンダリリージョンで任意の時点に復元して迅速にオペレーションを再開できます。Amazon RDS for PostgreSQL、MariaDB、MySQL、Db2、Oracle、Microsoft SQL Server で利用できます。 7/2(木) AWS Config が 8 つの新しいリソースタイプに対応 AWS Config が、Amazon API Gateway、Amazon EC2、Amazon S3 Vectors を含む主要サービスにわたる 8 つの追加リソースタイプに対応しました。追加されたリソースタイプは、AWS::ApiGateway::DomainNameV2、AWS::ApiGatewayV2::VpcLink、AWS::EC2::VPCEncryptionControl、AWS::NetworkFirewall::ContainerAssociation、AWS::OpenSearchServerless::SecurityPolicy、AWS::OSIS::Pipeline、AWS::S3Vectors::VectorBucket、AWS::S3Vectors::VectorBucketPolicy の 8 種類です。すべてのリソースタイプの記録を有効にしている場合、これらの新規リソースは自動的に追跡されます。新しくサポートされたリソースタイプは Config ルールと Config アグリゲーターでも利用可能で、リソースが利用可能なすべての AWS リージョンで対応します。 Amazon EC2 X8i インスタンスが追加リージョンで利用可能に Amazon EC2 X8i インスタンスが、アジアパシフィック (ソウル)、アジアパシフィック (マレーシア)、アジアパシフィック (東京) の各リージョンで利用可能になりました。AWS でのみ提供されるカスタム Intel Xeon 6 プロセッサを搭載しており、クラウド上の同等 Intel プロセッサの中で最高のパフォーマンスと最速のメモリ帯域幅を提供します。前世代の X2i と比較して、最大 43% 高いパフォーマンス、1.5 倍のメモリ容量 (最大 6TB)、3.3 倍のメモリ帯域幅を実現し、SAP HANA、大規模データベース、データ分析、電子設計自動化 (EDA) などのメモリ集約型ワークロードに適しています。X2i との比較で SAPS 性能は最大 50%、PostgreSQL 性能は最大 47%、Memcached 性能は 最大 88%、AI 推論性能は 最大 46% の高速化が期待できます。large から 96xlarge まで、2 つのベアメタルオプションを含む 14 サイズで提供され、Savings Plans、オンデマンド、スポットで購入可能です。 Amazon SageMaker Unified Studio が Terraform によるプロビジョニングをサポート Amazon SageMaker Unified Studio が Terraform に対応しました。オープンソースの terraform-aws-sagemaker-unified-studio モジュールを使用して、バージョン管理されたテンプレートから SageMaker Unified Studio ドメインをデプロイできます。プラットフォームチームは、既存の Infrastructure-as-Code パイプラインに SageMaker Unified Studio を組み込むことで、開発・ステージング・本番アカウント間の一貫性を維持できます。サブモジュールにより、ブループリントの有効化、プロジェクトプロファイルへの構成、プロジェクトの独立作成が可能で、既存の IAM ロールを流用したプロジェクト作成もできます。SageMaker Unified Studio が利用可能なすべての AWS リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。