はじめに こんにちは、カート決済部カート決済基盤ブロックの多田とSRE部カート決済SREブロックの伊藤（ @_itito_ ）です。普段はZOZOTOWN内のカート機能や決済機能の開発、保守運用、リプレイスを担当しています。 以前の記事で、クレジットカード決済処理をSQSで非同期化し、キャパシティコントロールを実現した取り組みをご紹介しました。 techblog.zozo.com 非同期化によって決済処理の安定性は大幅に向上しました。しかし、セールの終了時刻となる日曜から月曜にかけての日跨ぎ時に注文のピークを迎える時間帯では、依然としてユーザーの待ち時間が課題として残っていました。本記事では、SQSメッセージ処理を高速化することで待ち時間を改善した取り組みについてご紹介します。 目次 .entry .entry-content .table-of-contents > li > ul { display: none; } はじめに 目次 クレジットカード決済の非同期処理の仕組み 課題：ピーク時のSQS滞留による注文完了までの待ち時間 問題の本質：エンキュー速度 > デキュー速度 メッセージ処理をどれぐらい短縮すれば解消できるか 改善箇所の特定 改善1：仮注文から本注文作成のストアドプロシージャ改善 仮注文から本注文の作成処理とは ボトルネック：リンクサーバー経由の参照コスト 改善アプローチ：OPENJSONでリンクサーバー経由の参照を不要にする Java側の事前取得とクエリ最適化 改善結果 改善2：本注文の作成後の後処理の並列化 既存の課題：直列実行される後処理 後処理の分類：待つべきか、投げっぱなしでよいか CompletableFutureとは 改善アプローチ：@AsyncとCompletableFutureによる並列化 改善の全体像と効果 改善サマリー 実測値による効果確認 今後の展望 まとめ クレジットカード決済の非同期処理の仕組み 前回の記事でご紹介した非同期処理の仕組みを簡単に振り返ります。 ZOZOTOWNのクレジットカード決済では、注文確定ボタンの押下後、仮注文の作成まで同期処理で行います。クレジットカードの与信確保から本注文作成までは非同期処理で行われます。与信の確保が成功するとCartDBにある仮注文をFrontDBの本注文に変換し、注文を確定させます。フロントエンドはポーリングで本注文の完了を監視し、完了次第ユーザーに結果を表示します。 この非同期化により、注文数のスパイクをキューで吸収し、与信処理のキャパシティコントロールを実現できました。ただし、注文の完了画面が表示されるまでのユーザーの待ち時間は非同期化により短縮されたわけではありません。 課題：ピーク時のSQS滞留による注文完了までの待ち時間 ZOZOTOWNでは、セールの終了時刻となる日曜から月曜にかけての日跨ぎ時に注文のピークを迎えます。このピーク時に、注文確定のリクエスト受信から注文が確定するまでのP99レイテンシを分析しました。その結果、ピーク時間帯では注文確定までのP99レイテンシが大幅に増加し、最大で約26秒まで悪化していました。 問題の本質：エンキュー速度 > デキュー速度 ピーク時の待ち時間が増加する原因を深掘りしたところ、個々の処理速度ではなくエンキューとデキューの速度差に問題がありました。 指標 値 エンキューのスループット 109 req/s ワーカーの並列数 186 メッセージ処理時間（平均） 2.1s デキューのスループット 186 ÷ 2.1s ≒ 89 req/s エンキューのreq/sは注文確定のリクエスト数に相当します。デキューのスループットはワーカーの並列数 ÷ メッセージ処理時間から算出しています。 上記グラフの通り、 エンキュー速度がデキュー速度を上回っている ため、SQSにメッセージが滞留し、待ち時間が増加していました。つまり、メッセージ処理は2.1秒で終わっているが、キューが詰まり26秒も待たされている状態です。 メッセージ処理をどれぐらい短縮すれば解消できるか メッセージ処理時間を改善することで、単位時間あたりの処理数を増やし、エンキュー速度に追いつくことができます。現在の並列数からメッセージ処理時間を改善することでの、デキューのスループットと待ち時間の見込みは以下の通りです。 デキュー (req/s) メッセージ処理時間 (平均) 短縮量 不足分（エンキュー - デキュー） 89（現状） 2.1s 0s +20 req/s 93 2.0s 0.1s +16 req/s 98 1.9s 0.2s +11 req/s 103 1.8s 0.3s +6 req/s 109 1.7s 0.4s 0 平均メッセージ処理時間を2.1秒から1.7秒程度まで0.4秒短縮できれば、エンキューとデキューのスループットが均衡し、キュー滞留による待ち時間を大幅に改善できる ことが分かりました。 改善箇所の特定 目標が定まったところで、与信処理後に実行される注文の作成処理フローを整理し、改善できそうな箇所を探しました。大きく2つの改善ポイントを見つけました。 仮注文から本注文作成のストアドプロシージャ改善：リンクサーバー経由のアクセスが多く、ネットワークオーバーヘッドが大きい。アクセスを削減すれば大幅な改善が見込める。 本注文の作成以降の後処理の並列化：メール送信やクレジットカード登録などが直列実行されており、並列化すれば合計時間を圧縮できる。 以降、それぞれの改善内容を詳しくご紹介します。 改善1：仮注文から本注文作成のストアドプロシージャ改善 仮注文から本注文の作成処理とは 仮注文から本注文を作成するストアドプロシージャでは、CartDB上の仮注文テーブル群に保存されたデータをFrontDBの本注文テーブル群にINSERTします。与信の確保が成功した後に実行され、この処理が完了することで注文データが作成されます。 参照する仮注文側のテーブルは10種類以上に分かれており、ストアド内ではCartDBに対するSELECT・INSERT・UPDATEが合計で約20回実行されます。 ボトルネック：リンクサーバー経由の参照コスト ストアドプロシージャはFrontDB側で動作しますが、参照する仮注文テーブルはCartDB側にあります。FrontDBからCartDBへの参照にはSQL Serverの機能である リンクサーバー が使われており、クエリ実行のたびにDBサーバー間で通信が発生します。 learn.microsoft.com ネットワーク往復のオーバーヘッドにより、本来1ms未満で完了する軽量なクエリでも数msのコストがかかります。 実測では、 IF EXISTS 程度の軽量クエリ1回でも約3.5msかかっていました。同様のリンクサーバー経由クエリがストアド内で約20回繰り返されることで、ストアド全体で大きなオーバーヘッドになっていました。 改善アプローチ：OPENJSONでリンクサーバー経由の参照を不要にする 改善後のストアドプロシージャでは、リンクサーバー経由のクエリを排除するために以下のアプローチを取りました。 CartDBから仮注文データをJava側で事前に取得する 取得したデータをJSON形式に変換し、ストアドプロシージャのパラメーターとして渡す ストアド内では OPENJSON を使ってJSONをテーブルのように扱い、リンクサーバー経由の参照を置き換える OPENJSON はSQL Serverの組み込み関数で、JSON文字列をテーブル形式に変換できます。リンクサーバー経由のクエリを、メモリ上のJSONに対するクエリに置き換えることで、サーバー間通信を不要にしました。 以下は代表的な変換パターンです。仮注文関連テーブルへの存在チェックを例にすると、改修前後で次のように書き換わります。 -- 改修前: リンクサーバー経由でCartDBの仮注文関連テーブルを参照 IF EXISTS ( SELECT * FROM [接続先].[DB名].[スキーマ名].[テーブル名] WHERE ID = @ID ) -- 改修後: パラメーターで受け取ったJSONをOPENJSONで参照 IF EXISTS ( SELECT * FROM OPENJSON(@Json, ' $.table_foo_bar ' ) WITH ( ID INT ' $.table_foo_bar_id ' ) WHERE ID = @ID ) 同じパターンで、リンクサーバー経由で実行していたCartDBへのアクセスのうち、参照系の処理を中心に約20か所を置き換えました。 Java側の事前取得とクエリ最適化 ストアドへ渡すJSONを生成するためには、改修前はストアド内からリンクサーバーを介して取得していた仮注文データを、Java側で事前に取得する必要があります。事前取得は直列でも実行できますが、少しでも処理時間を短縮するため、 CompletableFuture を使って並列実行しました。（ CompletableFuture の詳細は改善2で後述します） さらに、改修前は仮注文テーブルごとに個別のSELECTを発行していましたが、関連テーブルをJOINで集約し、実行するクエリ数を削減しました。事前取得そのものを軽量化することで、JSONパラメーター化のオーバーヘッドを最小限に抑えています。 修正後の処理フローは以下のとおりです。 改善結果 STG環境で負荷試験シナリオを実行し、改善効果を ミクロ（個別クエリ）→ミドル（ストアド全体）→マクロ（エンドポイント全体） の3つの粒度で計測しました。クエリはストアドに含まれ、ストアドはエンドポイント処理の一部であるという包含関係になっています。 計測には、ミクロ・ミドルの粒度ではSQL ServerのDMV（ dm_exec_query_stats ・ dm_exec_procedure_stats ）を用いています。マクロの粒度ではエンドポイント全体のレイテンシ計測を用いています。 クエリ個別での計測（代表例） リンクサーバー経由のクエリは、置き換えにより1クエリあたりの平均実行時間が1〜2桁減少しました。 クエリ種別 改修前 改修後 改善率 仮注文関連テーブルへの存在チェック（ IF EXISTS ） 3.764ms 0.049ms 98.7% 仮注文テーブルからの INSERT 6.424ms 0.984ms 84.7% 仮注文テーブルからの SELECT 2.655ms 0.210ms 92.1% ストアド単体での計測 ストアド内で繰り返されていたリンクサーバー経由クエリの実行時間の短縮が積み重なり、ストアド全体としても75％超の改善につながりました。 改修前 改修後 改善率 平均CPU時間 81.7ms 15.6ms 80.9% 平均実行時間 146.3ms 36.1ms 75.3% 本注文作成の処理全体での計測 エンドポイント全体のレイテンシを計測した結果、 平均で約100msの改善 を確認できました。内訳としては、ストアド単体で約110msの短縮が得られた一方、JSON生成のためにJava側で事前取得する処理が追加された分（約10ms）があり、合計で約100msの改善となっています。 改善2：本注文の作成後の後処理の並列化 既存の課題：直列実行される後処理 本注文の作成後には、以下のような後処理が必要です。 注文完了メール送信 クレジットカード登録 お気に入りブランド登録 メールマガジン登録 買い替え割（割引サービス）の適用 不正検知 在庫の更新 従来の実装では、これらの処理が直列に実行されていたため、個々の処理は数十〜数百ミリ秒程度であっても、全体の実行時間が膨らんでいました。 後処理の分類：待つべきか、投げっぱなしでよいか 並列化を進めるにあたり、まず各処理を一覧化し、 完了を待つ必要があるか（join）、投げっぱなしでよいか（fire-and-forget） を判断しました。 判断基準は、 注文の完了画面の表示に直接影響する処理か という点です。失敗時にエラーメッセージを表示する必要がある処理は完了を待ち、画面表示に影響しない処理は投げっぱなしにします。 なお、ここでのfire-and-forgetは、注文の完了画面の表示を待たないという意味です。処理に失敗した場合は、ログやメトリクスで検知できるようにし、必要に応じてリトライや補完処理を行えるようにしています。 この基準で各処理を分類した結果は以下の通りです。 処理 分類 理由 注文完了メール送信 join（待つ） 失敗時に注文の完了画面でエラーメッセージを表示するため クレジットカードの登録 join（待つ） 失敗時に注文の完了画面でエラーメッセージを表示するため お気に入りブランドの登録 join（待つ） 失敗時に注文の完了画面でエラーメッセージを表示するため メールマガジンの登録 join（待つ） 失敗時に注文の完了画面でエラーメッセージを表示するため 買い替え割の適用 fire-and-forget 画面表示に影響しない非同期処理 不正検知 fire-and-forget 画面表示に影響しない非同期処理 在庫の更新 fire-and-forget 画面表示に影響しない非同期処理 この整理により、 joinで待つ処理同士はCompletableFutureで並列実行し、fire-and-forgetの処理は完了を待たず投げっぱなしにする という方針が定まりました。 CompletableFutureとは CompletableFuture は、非同期処理の結果を表すJavaのクラスです。Springの@AsyncやExecutorと組み合わせることで、複数の処理を並列に実行し、すべての完了を待ち合わせることができます。 例えば、メール送信（200ms）とクレジットカード登録（500ms）を直列実行すると合計700msかかりますが、 CompletableFuture で並列実行すれば最も遅い処理の500msで完了します。 // joinパターン：@Asyncメソッドが返すCompletableFutureをallOfで待ち合わせ CompletableFuture<ResultA> futureA = task.processA(); CompletableFuture<ResultB> futureB = task.processB(); CompletableFuture<ResultC> futureC = task.processC(); CompletableFuture<ResultD> futureD = task.processD(); CompletableFuture.allOf(futureA, futureB, futureC, futureD).join(); // fire-and-forgetパターン：@Asyncメソッドの戻り値を受け取らず呼び出すだけ task.processE(); task.processF(); 改善アプローチ： @Async と CompletableFuture による並列化 リプレイス後のJava実装では、Springの @Async アノテーションと CompletableFuture を活用して後処理を並列化しました。 処理の流れは以下の通りです。 仮注文から本注文作成 ：仮注文データを取得し、JSON形式に変換しストアドプロシージャを呼び出し本注文を作成 後処理を順次発火 ：join対象・fire-and-forget問わず、すべての後処理を @Async メソッドとして順次発火する。各処理は非同期で並列に実行される join対象のみ待ち合わせ ： CompletableFuture を返す4つの処理だけを allOf().join() で待ち合わせ、結果を取得する 改善の全体像と効果 これらの改善は、ASPからJavaへのリプレイスに合わせて実施しました。現時点ではPCサイトのリプレイスのみ完了しており、SPサイト（スマートフォンサイト）は今後リプレイスを実施する予定です。 改善サマリー 改善内容 短縮効果 改善1 本注文の作成処理のJSONパラメーター化 （リンクサーバー削減・クエリ最適化・並列データ取得） 約0.1s 改善2 後処理の並列化・fire-and-forget化 （CompletableFutureによる並列実行と不要な待機の排除） 約0.3〜0.4s 合計 約0.4〜0.5s PCリプレイス済み範囲では、目標としていた0.4秒の短縮を確認できました。 実測値による効果確認 PCのリプレイスが完了した時点で、リプレイス済みのPCとリプレイス未完了のSPのレイテンシを比較しました。 対象 ASP（SP） Java（PC） 改善幅 メッセージの処理時間（平均） 1.74s 1.34s 約0.4s改善 なお、前述の2.1秒はピーク時分析に用いた期間の平均値であり、上表の1.74秒はPCリプレイス後の効果確認の時点におけるSP側の実測値です。目標の0.4秒と実測の改善幅0.4秒は、計測期間・比較対象が異なるため直接比較できるものではありませんが、目標と同等の短縮効果が得られていることを確認できました。 グラフからも、リプレイス後はピーク時に限らず全体的にメッセージ処理時間が改善していることが確認できます。当初の分析で目標としていた0.4秒の短縮が、実測値でも確認できました。過去に計測したピーク時のリクエスト量であれば、SQSの滞留が解消される見込みです。なお、現時点ではPCのリクエスト数はSPと比較して大幅に少なく、同等のリクエスト数での比較はできていません。あくまで現時点で確認できた速報値としてご理解ください。 今後の展望 注文数は年々増加しており、現在の改善だけでは将来的に再びSQSの滞留が起こりえます。 また、今回の効果測定はPCとSPのリクエスト数が大きく異なる状況での比較でした。SPのN％リリース中に同等のリクエスト数で比較し、正式な効果測定を実施する予定です。 今後は以下の取り組みを検討しています。 SPリリース時の同等リクエスト数での正式な効果測定 さらなるストアドプロシージャの最適化 注文フロー全体のリプレイス完遂 まとめ 本記事では、クレジットカード決済の非同期処理におけるSQSメッセージ処理の高速化についてご紹介しました。 注文リクエストのピーク時のデータ分析 で、ボトルネックがエンキュー速度とデキュー速度の差にあることを特定 本注文の作成処理のストアドプロシージャのJSONパラメーター化 でリンクサーバー経由アクセスを削減し、CPU時間を80.9％改善 後処理の並列化 でCompletableFutureを活用し、メール送信・クレジットカード登録などの処理を並列実行 これらの組み合わせで 約0.4秒の短縮 を達成し、ピーク時の待ち時間を大幅に改善 ストアドプロシージャのリンクサーバー削減と、Javaの CompletableFuture による並列化を組み合わせることで、0.4秒という目標を達成できました。決済処理のような高信頼性が求められるシステムでも、ms単位の地道な改善の積み重ねが大きな効果を生むことを実感しました。同様の課題を抱えている方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いよいよ AWS Summit Japan 2026 が 6月25日(木)・26日(金) の 2 日間、幕張メッセで開催されます。260 を超えるセッションと 300 以上の展示が集まる、日本最大の “AWS を学ぶイベント” です。 今回はその中から、開発者の方にぜひ立ち寄っていただきたい「Developer Community Zone」をご紹介します。ここは、開発者同士がディスカッションを楽しみ、コミュニティとのつながりを育むインタラクティブなラウンジです。サーバーレスアーキテクチャでコーヒーを淹れる名物アクティベーション 「Serverlesspresso」 を体験できるほか、コミュニティのメンバーと交流できる、Summit ならではの場になっています。 セッションや EXPO の合間に、ぜひ Developer Community Zone に足を運んで、ビルダー同士の”つながり”を体験してみてください。詳細は AWS Summit Japan 2026 公式サイト をご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月8日週の主要なアップデート 6/8(月) Amazon OpenSearch Serverless が Agentic Search に対応 Amazon OpenSearch Serverless に Agentic Search 機能が追加されました。自然言語でクエリを記述すると、LLM を活用した QueryPlanningTool が意図を解釈し、適切な DSL クエリを自動生成して検索を実行します。「東京行きの $800 以下の航空券を探して」のような問い合わせに対して、システムが検索戦略を計画し、推論内容のわかりやすい説明とともに結果を返します。Amazon Bedrock の Claude Haiku などの LLM を使用し、OpenSearch Dashboards または API 経由で設定できます。全ての OpenSearch Serverless 対応リージョンで利用可能です。 AWS Transform における Amazon RDS for SQL Server マイグレーションコスト評価機能の提供開始 AWS Transform で Amazon RDS for SQL Server の TCO 評価機能が利用可能になりました。AI エージェントを活用して、オンプレミス SQL Server 環境を分析し、ワークロード要件を満たす最適なデータベースインスタンスを推奨します。What-if 分析により複数のマイグレーションオプションを評価でき、BYOM (Bring Your Own Media) と License Included の両方のライセンスモデルに対応しています。Database Savings Plans を活用することでオンデマンド価格と比較して最大 20% のコスト削減が可能です。 Amazon Redshift Serverless および RG インスタンスのマニュアルスナップショットコストを削減 Amazon Redshift は、Serverless および RG (AWS Graviton ベース) インスタンスにおけるマニュアルスナップショットの課金モデルを変更しました。従来は各スナップショットの合計サイズで課金されていましたが、新モデルでは複数スナップショット間で固有のデータブロックのみを課金対象とします。これにより、複数のスナップショットを保持する顧客は大幅なコスト削減を実現できます。10TB のデータウェアハウスで 3 つのスナップショットを保持する場合、従来の 30TB 課金が 11TB に削減される計算となり、約 63% のコスト削減効果があります。この変更は 2026年6月8日 から自動的に適用されます。 AWS Application Migration Service が AWS Transform MGN に名称変更 AWS Application Migration Service (MGN) が AWS Transform MGN に名称変更されました。これは MGN が AWS Transform という agentic migration service（AI エージェント型移行サービス）の基盤となるレプリケーションエンジンとして位置付けられたことを反映しています。ユーザーは従来通り MGN コンソールで直接制御する方法と、AWS Transform のエージェンティックワークフローでディスカバリーからランディングゾーン構築、ネットワーク作成、リホストやコンテナ化までを自動化する方法の 2 つから選択できます。既存のコンプライアンス認証（FedRAMP High、HIPAA、PCI DSS、ISO、SOC 1/2/3）はすべて維持され、全商用リージョンおよび AWS GovCloud (US) で利用できます。 6/9(火) AWS Cost Explorer が Amazon Q による AI コスト分析機能を提供開始 AWS Cost Explorer に「Analyze with Amazon Q」機能が追加されました。ワンクリックで、現在表示しているコストレポートについて、コストトレンド、主要なコストドライバー、異常検知の包括的な分析を Amazon Q Developer から受け取ることができます。従来は複数のフィルターやデータポイントをまたいで手動で調査する必要がありましたが、この機能により、設定済みのフィルターや期間に基づいた詳細な説明が自動生成されます。過去データには実績分析を、未来データには予測分析を、混在期間には両方の分析を提供します。すべての商用 AWS リージョンで追加料金なしで利用できます。 AWS FinOps Agent がプレビュー提供開始 AWS FinOps Agent は、FinOps 実務者とエンジニアリングチーム向けの AI エージェントで、コストに関する質問への回答、最適化機会の提示、コスト異常の自動調査、定期的な FinOps ワークフローの実行を行います。Amazon Bedrock 上に構築され、Cost Optimization Hub、Compute Optimizer、Jira、Slack に直接統合することで、エンジニアが普段使うツール内でコスト分析を完結できます。プレビュー版は 米国東部 (バージニア北部)リージョンで提供され、プレビュー期間中は追加料金なしで利用できます（ただし、エージェントが呼び出す AWS API の標準料金は発生します）。 6/10(水) AWS Cost and Usage Report 2.0 でテーブル設定の更新をサポート AWS は AWS Cost and Usage Report 2.0 (CUR 2.0) において、AWS Management Console および SDK/CLI を通じてデータテーブル設定を更新できる機能を追加しました。これにより、既存のエクスポートを削除して再作成することなく、新しい CUR 2.0 機能（追加カラムや詳細な行レベル粒度など）を採用できるようになります。更新された設定は、次回のスケジュール配信から適用されます。 Amazon EC2 M9g および M9gd 汎用インスタンスが利用可能に AWS は AWS Graviton5 プロセッサを搭載した Amazon EC2 M9g および M9gd インスタンスの一般提供を開始しました。M9g インスタンスは前世代の M8g 比で最大 25% の性能向上を実現し、データベースで最大 30%、Web アプリケーションと機械学習で最大 35% の高速化を達成しています。M9gd インスタンスはローカル NVMe SSD ストレージを搭載し、メディア処理やバッチ処理などの高速ストレージを必要とするワークロードに対応します。第 6 世代 AWS Nitro System を採用し、形式検証により数学的に証明されたワークロード分離を提供する Nitro Isolation Engine を初めて搭載しています。現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州(フランクフルト)の 4 リージョンで利用できます。 6/11(木) OpenAI GPT-5.4 および GPT-5.5 モデルが Amazon Bedrock の米国東部 (バージニア北部) リージョンで利用可能に AWS は OpenAI の GPT-5.4 および GPT-5.5 モデルを Amazon Bedrock の米国東部 (バージニア北部)リージョンで提供開始しました。両モデルは 272K トークンのコンテキストウィンドウを持ち、テキストと画像の入力に対応します。GPT-5.5 は OpenAI の最も高性能なモデルで、高度なコーディング、調査分析、ソフトウェア操作、長時間実行されるエージェントタスクに特化しています。GPT-5.4 はフロンティア推論、コーディング、コンピュータ使用、長文コンテキストワークフロー、ツール使用を本番環境にもたらします。両モデルは Responses API 経由で利用でき、サーバーサイドおよびクライアントサイドのツール呼び出し、プロジェクト、レスポンスストリーミングに対応しています。 AWS Workload Credentials Provider を発表 AWS は AWS Workload Credentials Provider を発表しました。このプロバイダーは、AWS Certificate Manager (ACM) からエクスポートした証明書の自動デプロイと、AWS Secrets Manager のシークレットをローカルキャッシュする軽量なクライアント側プロバイダーです。従来は ACM から証明書をエクスポートする際、Amazon EventBridge を使ってカスタム自動化を構築する必要がありましたが、CA/B Forum の規定により公開証明書の有効期限が短縮される中、このカスタム自動化は大規模環境でのメンテナンスが困難になっていました。AWS Workload Credentials Provider は、証明書とシークレットの両方を単一のプロバイダーで配布・自動化できる統合ソリューションを提供します。Windows と Linux で動作し、Apache と NGINX ウェブサーバーに対応しています。 Amazon Aurora が PostgreSQL メジャーバージョン 18 をサポート Amazon Aurora PostgreSQL-Compatible Edition が PostgreSQL メジャーバージョン 18 (18.3) をサポート開始しました。このリリースでは、B-tree skip scans によるクエリパフォーマンス改善、pg_roaringbitmap 拡張機能の追加、オプティマイザ統計の保持によるアップグレード後の性能維持、論理レプリケーションの並列ストリーミングによるレプリケーションラグ削減が実現されます。すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用可能です。 Amazon Quick と Snowflake Cortex AI の統合 Amazon Quick が Snowflake Cortex AI との統合を発表しました。Model Context Protocol (MCP) を介した接続により、自然言語で Snowflake の構造化データと非構造化ドキュメントをクエリできます。OAuth 認証による Snowflake 管理型 MCP サーバーを設定することで、Cortex Analyst（構造化データ分析）と Cortex Search（非構造化ドキュメント検索）へアクセス可能になります。Amazon Quick の Flows 機能を使用して、Snowflake Cortex Agents を組み合わせた反復可能なワークフローを構築でき、構造化された一貫性のある出力を得られます。この統合は Amazon Quick が利用可能な全 AWS リージョンで提供されます。 6/12(金) Amazon SageMaker AI が Nvidia Nemotron モデルのサーバーレスファインチューニングに対応 Amazon SageMaker AI は Nvidia Nemotron 3 Nano モデル (30B パラメータ) のサーバーレスモデルカスタマイゼーションに対応しました。Supervised Fine-Tuning (SFT) と Reinforcement Fine-Tuning (RFT) の両方に対応し、インフラ管理を完全に自動化することで、開発者はデータ準備とモデル評価に集中できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド)の 4 リージョンで利用できます。 Claude Fable および Mythos に関する発表 もありましたが、米国政府から指示があり、現在アクセス停止となっておりますのでご注意ください。Opus 4.8 等の他のモデルに関しては影響ありません。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

G-gen の今村です。当記事では、Cloud SQL で提供されているパフォーマンス最適化機能の1つである インデックスアドバイザー について解説します。 概要 インデックスアドバイザーとは 仕組み 料金と要件 料金 対象エディションと要件 有効化の手順 推奨事項の確認 推薦インデックスの確認方法 画面に表示される評価データの内容 Gemini による支援 推奨事項の適用 概要 インデックスアドバイザーとは Cloud SQL の インデックスアドバイザー 機能は、Cloud SQL で実行されたクエリを自動的に分析し、パフォーマンス向上につながる最適なインデックスを提案する機能です。当機能は Cloud SQL の Enterprise Plus エディションでのみ使用できます。 2026年6月現在、Cloud SQL の主要な3つのデータベースエンジン（MySQL、PostgreSQL、SQL Server）のすべてでサポートされています。各データベースエンジンにおける基本的な機能の目的や仕組みに大きな違いはありません。 リレーショナルデータベースの運用において、クエリの実行速度低下を解決するためのインデックス追加は非常に有効な手段です。しかし、どのカラムにどのようなインデックスを定義すべきかの判断には、高度な知識と経験が必要です。インデックスアドバイザーを使用することで、システムが実際のクエリ負荷に基づいて具体的な推奨インデックスを提示するため、データベース管理者の運用負荷を大幅に削減できます。 参考 : インデックス アドバイザーを使用する | Cloud SQL for PostgreSQL Cloud SQL の機能の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 仕組み インデックスアドバイザーがクエリを分析する際は、具体的な数値や文字列などのリテラルを除外した「正規化クエリ」と呼ばれる共通のパターンで追跡されます。例えば、検索する数値が異なっていても、同じ型のクエリとしてまとめて統計が取られる仕組みです。 このデータを基に、パフォーマンス向上につながる新しいインデックスが自動で識別され、具体的な CREATE INDEX 文として推奨事項に保存されます。生成された推奨事項は、Google Cloud コンソールの Query Insights ダッシュボードや推奨事項画面からいつでも確認できます。 なお当機能が提案するのは、データの検索速度を高めるためのインデックスであり、主キーや外部キーなどのテーブル構成の推奨事項などは生成されません。またリレーショナルデータベースの一般的な仕様として、テーブルにインデックスを追加すると、データ更新時にインデックス更新も同時に行われることで書き込み処理の負荷が増加する点にも留意が必要です。 よって、インデックスアドバイザーによる推奨事項を無条件に採用するのではなく、パフォーマンス影響等を考慮して、適用の可否を判断してください。 料金と要件 料金 インデックスアドバイザー機能自体の使用に追加料金はかかりません。Cloud SQL の Enterprise Plus エディションを利用していれば、無料で使用できます。 対象エディションと要件 インデックスアドバイザーを使用するには、Cloud SQL の Enterprise Plus エディション を使用している必要があります。また、インスタンスで Query Insights 機能が有効化されていることが要件となります。 Query Insights が収集する指標データは、原則として Cloud SQL インスタンスのストレージ領域を占有しません。指標は Cloud Monitoring に保存されるため、インスタンス自体のディスク容量を圧迫しない設計になっています。ただし、収集された指標の転送や API リクエストに伴い、Cloud Monitoring 側の料金が適用される場合がある点に留意してください。 参考 : Cloud SQL のエディションの選択 | Cloud SQL for PostgreSQL Cloud Monitoring の機能の詳細は以下の記事を参照してください。 blog.g-gen.co.jp 有効化の手順 インデックスアドバイザーを有効化する手順は以下の通りです。 Cloud SQL の「インスタンス」ページに移動し、対象のインスタンス名をクリック 概要ページから「編集」をクリック 「構成の編集」をクリック 「インスタンスのカスタマイズ」セクションで「Query Insights」を展開 「Query Insights を有効にする」チェックボックスをオンにする 「インデックスアドバイザーを有効にする」チェックボックスをオンにする 「保存」をクリックして設定を反映 インデックスアドバイザーを有効にするには、インスタンスの再起動が必要です。本番環境で実施する際は、必ずメンテナンス可能な時間帯を計画してください。 参考 : Query Insights を使用してクエリのパフォーマンスを向上させる | Cloud SQL for SQL Server 推奨事項の確認 推薦インデックスの確認方法 推奨インデックスを確認する手順は以下の通りです。 Cloud SQL の「インスタンス」ページに移動 対象のインスタンス名をクリックし、「Query Insights」をクリック 「上位のクエリとタグ」セクションで目的のクエリをクリック 画面に表示される評価データの内容 クエリの詳細画面では、推奨されたインデックスを適用すべきかを総合的に判断するための情報がまとまっています。 まず確認したいのがパフォーマンスへの影響です。推定クエリ速度が「高」「中」「低」の3段階で示されるため、導入によってどれほどの速度向上が見込めるかが一目でわかります。次に、その効果に対してどれほどのリソースが必要になるかを、影響を受けるテーブルと必要な追加ストレージサイズの推定値から見積もります。さらに、そのインデックスがシステム全体のどれほど多くの処理に貢献するかを、影響を受けるクエリの数で評価します。 このように、見込める効果とリソースへの影響を天秤にかけて適用の可否を判断した上で、画面上の「インデックスの作成」をクリックすると、実行すべき具体的な DDL が表示されます。 推奨事項は、自動的にデータベースへ適用されるわけではありません。そのため、ユーザー自身がコンソール画面から CREATE INDEX 文をコピーし、手動で適用作業を行う必要があります。 Gemini による支援 2026年6月現在、Cloud SQL ではインデックスアドバイザーによる自動分析だけでなく、生成 AI モデル Gemini を使用したクエリ作成のアシスタンス機能も提供されています。 Google Cloud コンソールの Cloud SQL Studio などの画面において、自然言語のプロンプトから SQL の生成や、クエリ構造の説明を取得できます。これにより、インデックスアドバイザーが提案した CREATE INDEX などの DDL の意図を深く理解したり、最適化されたクエリの記述を効率化できます。機能の具体的な使用方法や最新の要件については、公式ドキュメントを参照してください。 参考 : Gemini を使用して SQL クエリを作成する | Cloud SQL for PostgreSQL 推奨事項の適用 推奨事項を適用するには、コピーした CREATE INDEX 文を、Cloud SQL インスタンス内のデータベースに対して手動で実行します。実行にあたり、普段運用で使用しているデータベース管理ツール経由で DDL を実行することも、Google Cloud コンソール上で直接 SQL を実行できる Cloud SQL Studio を使用することもできます。 一般的に、インデックスの作成処理は、既存のテーブル内にあるレコードを読み込んだうえで新しくインデックスを構築してディスクに書き込むため、データベースの CPU やディスク I/O などのリソースを大きく消費します。対象テーブルのデータ量によっては処理に長い時間がかかり、本番環境のパフォーマンスに影響を与える可能性がある点に留意してください。 そのため、本番環境へ適用する際は、事前に検証環境で処理時間や影響度を確認し、システムへの負荷を最小限に抑えられるよう、利用者の少ない時間帯に実行を計画してください。 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow