みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 はじめに、7月28日に熊本県で発生した地震(令和8年熊本地震)により被害に遭われた皆様に、心よりお見舞い申し上げます。被災された皆様の安全と、一日も早い復旧を心よりお祈りしております。 話題は変わりますが、AWS 認定をこれから取得したい方、あるいはスキルアップを考えている方に向けたキャンペーンのご案内です。現在、 AWS 認定 AI スキルアップキャンペーン が実施されており、AWS Certified AI Practitioner (AIF-C01) を 2026 年 9 月 30 日までに受験すると試験料が 50% 割引になります。さらに合格すると、AWS Certified Cloud Practitioner (CLF-C02) を無料で受験できます。この夏、AI 分野の認定取得にチャレンジしてみるのはいかがでしょうか。 それでは、先週の主なアップデートについて振り返っていきましょう！ 2026年7月27日週の主要なアップデート 7/27(月) Amazon RDS for SQL Server が Multi-AZ インスタンスでの TDE データベース復元に対応 Amazon RDS for SQL Server で、TDE (Transparent Data Encryption) を有効にした SQL Server データベースを Multi-AZ インスタンスおよび同一リージョン内のリードレプリカを構成したインスタンスに復元できるようになりました。ネイティブバックアップ・リストア機能を使用します。従来は Single-AZ インスタンスでのみ TDE 有効データベースの復元が可能で、暗号化データを復元するには TDE を無効化するか Single-AZ 構成への移行が必要でした。今回の対応により、保存時暗号化 (TDE) と Multi-AZ の高可用性の両方を必要とする移行・復旧のワークフローを簡素化できます。この機能は Amazon RDS for SQL Server が提供されるすべての AWS リージョンで利用できます。 AWS Security Hub MCP App で、エクスポージャー検出結果を自然言語で調査可能に (プレビュー) AWS Security Hub MCP App のパブリックプレビューが開始されました。これは Claude Desktop 内で動作するローカルの Model Context Protocol (MCP) サーバーで、Security Hub のエクスポージャー検出結果について、攻撃パスの深掘りや修復方法の提案などを自然言語で調査できます。すべてのツールは読み取り専用 (read-only) で、環境に変更を加えずに利用できます。Security Hub の利用者は追加費用なしで使うことができます。 Amazon EKS がクラスター OIDC エンドポイント向けの AWS PrivateLink に対応 Amazon EKS が、クラスターの OIDC ディスカバリおよび JWKS エンドポイント向けの AWS PrivateLink に対応しました。インターフェイス型 VPC エンドポイント (サービス名 `com.amazonaws.[リージョン名].oidc-eks`) を作成することで、VPC 内の eksctl や Terraform、独自のトークン検証ツールが、IAM roles for service accounts (IRSA) のセットアップやトークン検証を、インターネットに出ることなく閉域 VPC 内で実行できるようになりました。追加料金はなく、標準の AWS PrivateLink 料金のみが適用されます。 7/28(火) Amazon S3 Tables が Apache Iceberg V3 の Variant データ型に対応 Amazon S3 Tables が Apache Iceberg V3 仕様の Variant データ型に対応しました。JSON などの半構造化データを事前にスキーマを固定せずに直接書き込めます。書き込み時に Iceberg V3 対応エンジンが Variant データを隠しカラムに分解 (shredding) し、Parquet のカラム統計を生成します。クエリエンジンはこの統計を使ってファイルプルーニングを行い、分析クエリがスキャンするデータ量を減らします。S3 Tables は Variant カラムに対してもコンパクションを含むテーブルメンテナンスを継続実行します。東京を含む、15 の AWS リージョンで利用できます。 AWS DataSync Enhanced mode が HDFS、Azure Blob、オブジェクトストレージのロケーションと Hyper-V エージェントに対応 AWS DataSync の Enhanced mode が、エージェント経由での HDFS (Hadoop Distributed File System)、Microsoft Azure Blob Storage、および自己管理型オブジェクトストレージへの転送に対応しました。あわせて Enhanced mode のエージェントを Microsoft Hyper-V 上に展開できるようになりました。HDFS 転送では複数 NameNode 構成 (High Availability) と Kerberos 認証を用いた TDE (Transparent Data Encryption) に対応します。これにより規制業界の組織が、可用性を維持したままペタバイト級の暗号化 Hadoop データを移行できます。この機能は DataSync が提供されているすべての AWS リージョンで利用できます。 AWS DataSync Enhanced mode が Amazon EFS および Amazon FSx for Lustre をサポート AWS DataSync の Enhanced mode が、転送元・転送先として Amazon EFS と Amazon FSx for Lustre に対応しました。従来これらのストレージへの転送は Basic mode に限定されていましたが、今回のアップデートで Enhanced mode を選択できるようになりました。Enhanced mode はデータを並列に処理し、ファイル数の上限がなく、詳細な転送メトリクスを提供します。大規模なデータ移行や AI/ML の学習データ準備、HPC、ゲノム解析、メディアレンダリングといったワークロードで利用できます。AWS DataSync が提供されているすべての AWS リージョンで利用可能です。 7/29(水) IAM Identity Center が Identity Center ディレクトリのマルチリージョン対応を拡張 AWS IAM Identity Center が、ID ソースとして Identity Center ディレクトリを使用する組織インスタンスでもマルチリージョンレプリケーションに対応しました。これまで外部 IdP 接続のインスタンスに限られていた機能が拡張されています。プライマリリージョンで有効化したインスタンスを、デフォルトで有効化されている 17 の商用リージョンから選んだリージョンへ複製できます。ユーザー ID、権限セット、割り当て、セッションなどが自動でレプリケートされ、プライマリリージョンで障害が発生してもプロビジョニング済みのアクセスを維持できます。利用にはマルチリージョン対応の customer managed KMS key (CMK) が必要です。 AWS Interconnect – multicloud (Oracle Cloud Infrastructure 対応) が一般提供を開始 AWS は AWS Interconnect – multicloud の Oracle Cloud Infrastructure (OCI) 対応を一般提供 (GA) しました。この機能を使うと、AWS の VPC と OCI の VCN (Virtual Cloud Network) の間に、専用帯域を持つプライベート接続を短時間で作成できます。従来は複数クラウド間の相互接続を自前で構築する必要がありましたが、その運用負荷を AWS と接続先プロバイダーが肩代わりします。GA 時点では OCI と Google Cloud に対応し、米国東部 (バージニア北部) リージョンで利用できます。Microsoft Azure は 2026 年後半に対応予定です。 AWS Glue の REST API コネクタが VPC 接続、フィルタプッシュダウン、パーティションに対応 AWS Glue の REST API コネクタに 3 つの機能が追加されました。プライベートサブネットや VPN、AWS PrivateLink 経由の非公開 REST API に接続できる VPC 対応、クエリ条件を API ネイティブのパラメータに変換して転送量を減らすフィルタプッシュダウン、大規模データを複数の Spark ワーカーに分割して並列読み取りするパーティション対応です。これにより REST API を持つ任意のデータソースから、カスタムコードを書かずに ETL パイプラインを構築できます。 7/30(木) AWS Managed Microsoft AD が Standard から Enterprise Edition へのアップグレードに対応 AWS Directory Service は、AWS Managed Microsoft AD の Standard Edition ディレクトリを Enterprise Edition へ直接アップグレードする機能に対応しました。AWS Management Console、AWS CLI、API、AWS Tools for PowerShell から実行でき、新しいディレクトリへの移行や既存ワークロードのドメイン再参加は不要です。信頼関係、アプリケーション統合、グループポリシー、DNS 設定はそのまま維持されます。所要時間は 4 時間から 5 時間で、ドメインコントローラー (DC) を 1 台ずつ入れ替えるため、その間は性能低下とダウンタイムが発生する可能性があります。アップグレードは不可逆であり、以前のスナップショットはアップグレード後のディレクトリには使用できません。アップグレードには追加料金が発生するため、詳細は Directory Service の料金ページをご確認ください。 AWS Transit Gateway のポリシーベースルーティングが一般提供開始 AWS Transit Gateway (TGW) でポリシーベースルーティング (PBR) の一般提供が開始されました。従来の宛先 IP アドレスのみによる転送判断に加えて、送信元 IP、宛先 IP、送信元ポート、宛先ポート、プロトコルの組み合わせでトラフィックを分類し、転送先の TGW ルートテーブルを選択できます。設定はポリシーテーブルという新しいリソースで行い、アタッチメントに関連付けます。ルールは番号の昇順に評価され、最初に一致したルールが適用されます (first-match-wins)。TGW が提供されているすべての商用リージョンで利用でき、標準の TGW 料金を超える追加課金はありません。ただしポリシーテーブルを関連付けたアタッチメントでは Site-to-Site VPN と Connect への BGP 経路広報が停止するため、導入前に影響確認が必要です。 Amazon SageMaker Unified Studio が全プロジェクトツールで Git バージョン管理を拡充 Amazon SageMaker Unified Studio のリポジトリ機能が更新され、Query Editor、Visual ETL、Workflows、Notebooks の 4 ツールでファイル単位の Git バージョン管理に対応しました。従来の自動同期 (保存ごとにリモートへ force push する方式) を置き換え、コミットメッセージ付きの push とブランチ操作ができるようになりました。これまで Git 非対応だった Notebooks も対象に含まれます。リポジトリはプロジェクト作成時ではなく任意のタイミングで追加でき、1 つのプロジェクトから複数のリポジトリとブランチへ同時に接続できます。既存プロジェクトへの適用はオプトインで、プロジェクトの更新を実行して切り替えます。 7/31(金) Amazon CloudWatch がマネージド Prometheus コレクターを発表 Amazon CloudWatch が、エージェントを配置せずに Prometheus 互換メトリクスを収集するマネージドコレクターに対応しました。従来は自己管理の OpenTelemetry Collector を配置、スケール、保守する必要がありましたが、スクレイプ設定とサブネット、セキュリティグループを指定すれば AWS 側がプロビジョニングとスケーリングを行います。対応対象は Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Service です。収集したメトリクスは OpenTelemetry 形式で CloudWatch のデータセットに配信され、PromQL でクエリできます。AWS ベンダーメトリクスと同じ画面でアラームとダッシュボードを構成できます。 Amazon RDS for Oracle が R8i および M8i インスタンスのリザーブドインスタンスを提供開始 Amazon RDS for Oracle で、R8i および M8i インスタンスに対する 1 年および 3 年のリザーブドインスタンス (RI) を購入できるようになりました。オンデマンド価格と比較して最大 53% のコスト削減となります。RI の割引は Multi-AZ 構成と Single-AZ 構成の双方に適用され、同一インスタンスクラスタイプ内であれば構成を変更できます。BYOL ライセンスモデルではサイズ柔軟性が働き、同一インスタンスファミリー内のどのサイズの使用量にも割引レートが自動適用されます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 みなさんは AWS Builder Center を活用されていますか? AWS Builder Center は、世界中のビルダーが書いた記事や動画などのコンテンツ、コミュニティ、学習リソースがひとつに集まったプラットフォームです。トピックごとにコンテンツがまとまっているのが便利で、例えば agent-to-agent のトピックページ では、AI エージェント同士を連携させる A2A に関する記事を一覧で読むことができます。気になる技術分野のトピックをフォローしておくと、最新のノウハウを効率よくキャッチアップできるので、ぜひ覗いてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月20日週の主要なアップデート 7/20(月) KNFSD File Cache のプレビュー提供を開始 AWS は NFS キャッシュソリューション KNFSD File Cache のプレビュー提供を開始しました。Apache-2.0 ライセンスのオープンソースで、オンプレミスや別リージョン、他クラウドの NFS サーバーをマウントし、AWS 内の NFS クライアントに再エクスポートします。頻繁に読み取られるデータをメモリとローカル NVMe にキャッシュし、高レイテンシー回線を越えるアクセスを 1 回に抑えて VPC 内速度で配信します。Linux カーネル標準の nfs-kernel-server と FS-Cache を利用し、Packer で AMI を構築後 Terraform でクラスターをデプロイします。全 AWS リージョンで利用でき、ライセンス費用はかからず消費した AWS リソースにのみ課金されます。 Amazon CloudWatch が Coding Agent Insights を発表 Amazon CloudWatch は、AI コーディングエージェントの利用状況を可視化する Coding Agent Insights を発表しました。Claude Code、OpenAI Codex、GitHub Copilot の OpenTelemetry (OTel) メトリクスを CloudWatch に取り込み、組織/部門/チーム/ユーザー単位で利用状況やコストを確認できます。Claude apps gateway for AWS と連携すると、追加の計装なしで Claude Code のテレメトリを収集できます。ダッシュボードは CloudWatch コンソールの GenAI Observability 配下に自動で表示され、料金は標準の CloudWatch OTel メトリクス取り込み料金が適用されます。 Amazon WorkSpaces Applications がマルチセッションフリートで Microsoft OneDrive と Google Drive に対応 Amazon WorkSpaces Applications のマルチセッションフリートで、永続ストレージオプションとして Microsoft OneDrive for Business と Google Drive が利用できるようになりました。従来はマルチセッションフリートで Amazon S3 バックエンドの home folder のみが選択肢でしたが、今回のアップデートでユーザーは自身の OneDrive / Google Drive アカウントを接続し、ストリーミングセッション内でクラウドファイルを直接参照・保存・同期できます。マルチセッションフリートは 1 つのフリートインスタンスを複数ユーザーで共有してセッション密度を高める構成で、コストを抑えながらクラウドストレージ体験を提供できます。機能の追加料金はなく、標準の WorkSpaces Applications 利用料金のみが適用されます。有効化には 2026 年 6 月 29 日以降にリリースされたエージェントを含むイメージが必要です。 Amazon Connect のエージェント型音声機能を対応言語と発話制御の拡張により強化 Amazon Connect は、agentic voice (エージェント型音声) 機能で 50 以上のロケール (言語) と 100 を超える音声オプションに対応しました。Spanish、French、Italian、Japanese、Korean、Portuguese、Thai などが含まれます。発話のペーシング、話者交替 (turn-taking) の精度向上に加え、速度/音量/感情を調整できる発話制御 (speech controls) を利用できます。この機能は Amazon Connect Customer のデフォルト音声プロバイダーとして提供され、米国/欧州/アジアパシフィックの 9 リージョンで利用できます。 AWS CloudTrail で ID 別にネットワークアクティビティイベントを選択的にログ記録 AWS は CloudTrail のネットワークアクティビティイベント (VPC エンドポイント向け) に対して、IAM ユーザー ID に基づくイベントフィルタリングを追加しました。API を呼び出した ID を条件にして、ログを記録するイベントを絞り込めます。例えば信頼済み IAM ロール以外からの VpceAccessDenied イベントだけを記録する、といった設定ができます。これにより、承認済みプリンシパルからの正常なトラフィックを除外し、ログ量とコストを抑えられます。この機能は AWS Management Console、AWS CLI、AWS SDK から利用でき、CloudTrail ネットワークアクティビティイベントが対応する全リージョンで使えます。 7/21(火) Amazon RDS for SQL Server が Microsoft SQL Server 2025 に対応 Amazon RDS for SQL Server が Microsoft SQL Server 2025 (Enterprise、Standard、Developer の各エディション) に対応しました。RDS で提供される最新マイナーバージョンは 17.0.4045.5 (CU5) です。SQL Server 2025 は T-SQL から外部 REST エンドポイントを呼び出す機能をデータベースエンジンに組み込んでおり、Amazon Bedrock や Amazon SageMaker、Amazon S3、AWS Lambda といった AWS サービスとアプリケーションを再設計せずに連携できます。また native vector データ型による埋め込みベクトルの格納/検索に対応し、Standard Edition は最大 32 コア/256 GB バッファプールへ拡張され Resource Governor も利用できるようになりました。既存の RDS インスタンスは DB エンジンバージョンの変更でアップグレードでき、オンプレミスからの移行も可能です。 Amazon ECS が Action Logs を提供開始 (デプロイとオーケストレーションの可視化) Amazon ECS は、サービスデプロイと ECS Managed Daemon 更新の際に ECS がユーザーに代わって実行する操作を、タイムスタンプ付きで記録する Action Logs を提供開始しました。従来は開始状態と終了状態しか観測できなかった中間操作 (コンテナイメージのダウンロード、ロードバランサー登録、セキュリティグループ設定など) を確認できるようになりました。ログはクラスターレベルで opt-in し、CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれかへ配信できます。Amazon Q が Action Logs と連携し、circuit breaker によるロールバックなどの原因分析をコンソール内で提供します。AWS GovCloud (US) を含む全 AWS リージョンで利用できます。 Amazon SES が料金プランを導入 Amazon SES は、個別のアドオンとして販売されていたメール到達性関連の機能を 3 段階の料金プラン (Essentials、Pro、Enterprise) にまとめて提供する仕組みを導入しました。各プランは下位プランの機能をすべて含み、上位ほど機能が増えます。従来の従量課金と比べて割引が適用されます。プランはアカウント単位かつ AWS リージョン単位で選択し、中東 (UAE) および中東 (バーレーン) を除く Amazon SES 提供リージョンで利用できます。新規アカウントは 2026 年 7 月 21 日以降 Essentials から開始します。 7/22(水) Amazon EKS の EKS Auto Mode と Karpenter で EFA と Placement Group をサポート Amazon EKS の EKS Auto Mode とオープンソースの Karpenter で、ノードプールの EC2 Placement Group (配置グループ) と Elastic Fabric Adapter (EFA) のネットワークインターフェース設定に対応しました。NodeClass または EC2NodeClass の定義から、EFA-only インターフェースの構成と、cluster / spread / partition の 3 種類の配置戦略を指定できます。EFA-only インターフェースは IP アドレスを消費しないため、VPC 内の IP 使用量を抑えながら EFA の帯域を利用できます。分散学習や分散推論のスループット最適化と、本番サービスの障害範囲 (blast radius) 縮小の両方に対応します。この機能は Amazon EKS が利用可能なすべての AWS リージョンで使えます。 Network Load Balancer がカスタムトラフィックルーティング向けのリスナールールに対応 Network Load Balancer (NLB) が、送信元 IP アドレスタイプ (IPv4 / IPv6) に基づいて接続を別々のターゲットグループへ振り分けるリスナールールに対応しました。1 台のデュアルスタック NLB で IPv6 クライアントの通信を IPv6 ターゲットへ、IPv4 クライアントの通信を IPv4 ターゲットへ送り、両方のアドレスファミリでクライアント元 IP をエンドツーエンドで保持できます。従来はロードバランサーを 2 台に分ける方法か、プロトコル変換で元 IP を失う方法のいずれかを選ぶ必要がありましたが、この機能でその制約がなくなりました。既存のデュアルスタック NLB に作り直しなしでルールを追加できます。全 AWS 商用リージョンと AWS GovCloud (US) リージョンで追加料金なしで利用できます。 7/23(木) Amazon CloudWatch Logs が Application Load Balancer ログに対応 Amazon CloudWatch Logs が Application Load Balancer (ALB) のログを vended logs として受け取れるようになりました。ALB のアクセスログ、接続 (connection) ログ、ヘルスチェックログの 3 種類を CloudWatch に直接配信し、Logs Insights クエリ、メトリクスフィルタ、Live Tail で分析できます。配信先は CloudWatch Logs のほか Amazon Data Firehose と Amazon S3 (Apache Parquet 形式対応) を選択できます。CloudWatch telemetry enablement rules を使うと、既存および新規の ALB に対してログ設定を自動適用できます。ALB と CloudWatch が利用可能なすべての AWS 商用および GovCloud リージョンで利用できます。 7/24(金) aws-bench (AWS 上の AI エージェント向けオープンソースベンチマーク) を発表 AWS は 2026 年、AI エージェントが実際の AWS タスクをどれだけ正確かつ効率的に完了できるかを測定するオープンソースベンチマーク aws-bench をリサーチプレビューとして公開しました。実際の AWS 環境を都度払い出し、エージェントに調査・トラブルシューティング・インフラ作成のタスクを実行させて採点します。テストケースは自然言語クエリ、クラウドリソースの状態、正解データの 3 点で構成され、任意のエージェントやモデルを一貫した基準で比較できます。テスト環境の構築・実行・採点・リセットを行う CLI が同梱され、GitHub (Apache License 2.0) で入手できます。 AWS で Claude Opus 5 が利用可能に AWS は 2026 年 7 月 23 日に Anthropic の最新モデル Claude Opus 5 の提供を開始しました。コーディング、長時間稼働エージェント、文書量の多い業務での推論精度が向上しています。提供経路は Amazon Bedrock と Claude Platform on AWS の 2 つで、Bedrock 版はゼロデータ保持 (ZDR) がデフォルトで有効です。コンテキストウィンドウは 1M トークン、最大出力は 128K トークンで、東京リージョン (ap-northeast-1) からは Global クロスリージョン推論経由で利用できます。入力 $5 / 出力 $25 (100 万トークンあたり) の価格で、前世代 Opus 4.8 と同水準の単価に据え置かれています。 Amazon EC2 Dedicated Hosts がセルフマネージドライセンスなしでホストリソースグループに対応 EC2 Dedicated Hosts のホストリソースグループ (Host Resource Groups, HRG) を、これまで必須だったセルフマネージドライセンス (Self-Managed Licenses, SML) の作成と AMI 関連付けなしで作成できるようになりました。ハードウェアレベルの分離だけを目的とする顧客や EC2 Mac インスタンスの顧客は、AWS License Manager でのライセンス設定手順を省略できます。BYOL (Bring Your Own License) ワークロードでは従来どおり SML 付きの HRG も作成でき、起動できる AMI の制限とホスト単位のライセンス消費追跡を継続できます。HRG がサポートされる全ての AWS リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

はじめに こんにちは、カート決済部カート決済基盤ブロックの多田と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