みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 さて、みなさんはゴールデンウィークのご予定はお決まりでしょうか。今年は長期休暇にされる方も多いようですね。私はというと、6月24日・25日に幕張メッセで開催される AWS Summit の準備があり、飛び石連休をつなげての長期休暇は取れそうにありません。その代わり、趣味のパデルの大会にいくつかエントリーしているので、そこでリフレッシュしようと思っています。 AWS Summit では、パデルのフォームを VR で計測できる展示を予定しており、現在鋭意開発中です。VR の世界観も AI を活用して実現しており、日々多くの学びがあります。また、スマートグラスや音声を活用した業務効率化アプリも開発中で、そちらもご体験いただけます。ぜひご来場ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年4月20日週の主要なアップデート 4/20(月) Amazon CloudWatch Logs Insights が JOIN およびサブクエリコマンドを導入 Amazon CloudWatch Logs Insights で JOIN とサブクエリコマンドが利用可能になりました。これまで複数のロググループをまたいだ分析では、複数のクエリを実行して手動で結果を組み合わせる必要がありましたが、今回のアップデートで 1 つのクエリで完結できるようになりました。例えば、エラーが多いサービスを特定するサブクエリと、パフォーマンスデータを持つ別のロググループを JOIN することで、エラー頻度と応答時間を同時に分析し、優先対応すべきサービスを効率的に特定できます。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB (MongoDB 互換) がバージョン 5.0 から 8.0 へのインプレースアップグレードをサポート Amazon DocumentDB で、バージョン 5.0 から 8.0 へのインプレースアップグレードが可能になりました。従来はクラスタを新規作成する必要がありましたが、今回のアップデートでクリック数回の操作だけでアップグレードできます。バージョン 8.0 ではクエリ処理が最大 7 倍高速化され、ストレージ圧縮も最大 5 倍向上するため、アプリケーションの応答速度改善とコスト削減を同時に実現できます。詳細は こちらのドキュメントをご参照ください。 4/21(火) AWS Lambda Durable Execution SDK for Java 一般提供開始 AWS Lambda Durable Execution SDK for Java が一般提供開始されました。Java 開発者が Lambda で長時間実行されるワークフローを構築できるようになります。注文処理パイプラインや AI エージェント連携、承認フローなどを外部サービスなしで作成可能です。実行を最大 1 年間一時停止でき、進捗も自動で保存されます。詳細は こちらの Document をご参照ください。 Amazon Aurora serverless: 最大 30% のパフォーマンス向上、よりスマートなスケーリング、そしてゼロまでのスケールダウンを継続 Amazon Aurora serverless がプラットフォームバージョン 4 で大幅にアップデートされ、最大 30% のパフォーマンス向上と賢いスケーリング機能を実現しました。従来は複数のタスクが同時実行される際にリソース競合が発生しやすかったビジネス用 Web アプリケーションや API サービスでも、効率的に動作するようになりました。特にエージェント型 AI アプリケーションのように、活動が集中する時間と長時間のアイドル状態が不規則に発生するワークロードに最適で、使用量に応じた自動スケーリングにより無駄なコストを削減できます。詳細は こちらの Blog 記事をご参照ください。 AWS Lambda 関数で Amazon S3 バケットを S3 Files によりファイルシステムとしてマウント可能に AWS Lambda で Amazon S3 バケットをファイルシステムとして直接マウントできる S3 Files 機能が提供開始されました。従来はデータ処理のためにオブジェクトをダウンロードする必要がありましたが、今回のアップデートによりファイル操作が直接可能になります。複数の Lambda 関数が同じファイルシステムに同時接続でき、AI や機械学習のワークフローでデータ共有が簡単になります。詳細は こちらの Blog 記事をご参照ください。 ハイブリッド Kubernetes ネットワーキング向け Amazon EKS Hybrid Nodes ゲートウェイの紹介 Amazon EKS で Hybrid Nodes gateway が提供開始されました。この機能により、クラウドとオンプレミス環境を跨ぐハイブリッド Kubernetes ネットワークが自動化されます。従来は複雑なルーティング設定やネットワークチームとの調整が必要でしたが、これらが不要になります。pod 間通信や AWS サービスとの接続も自動で処理され、EC2 インスタンスに Helm でデプロイするだけで利用できます。中国リージョン以外で追加料金なしで利用可能です。詳細は こちらのドキュメントをご参照ください。 4/22(水) Amazon Bedrock AgentCore が開発者のエージェント構築を高速化する新機能を追加 Amazon Bedrock AgentCore に新機能が追加され、AI エージェント開発が大幅に簡単になりました。新しい managed harness (プレビュー) により、従来必要だったオーケストレーションコードを書かずに、モデルとプロンプト、ツールを指定するだけでエージェントを即座に実行できます。セッション途中でのモデル変更や、タスクの中断・再開も可能で、プロトタイプから本格運用まで一貫してサポートします。追加料金は発生せず、オレゴン、バージニア北部、フランクフルト、シドニーの 4 リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 AWS Secrets Manager が MongoDB Atlas と Confluent Cloud への管理対象外部シークレット機能を拡張 AWS Secrets Manager が MongoDB Atlas と Confluent Cloud の外部シークレット管理に対応しました。従来は各サービスの認証情報を自動ローテーションするために Lambda 関数を自作する必要がありましたが、今回のアップデートで AWS が提供する機能だけで実現できるようになりました。データベースと Kafka を組み合わせたデータパイプラインなどで、複数のサービスのシークレットを一元管理し、運用負荷を大幅に削減できます。詳細は こちらのドキュメントをご参照ください。 Amazon ECS マネージドインスタンス向け GPU ヘルスモニタリングと自動修復機能の導入 Amazon ECS Managed Instances で NVIDIA GPU の健康監視と自動修復機能が提供開始されました。GenAI 推論などの GPU ワークロードでハードウェア故障が発生した際、自動的に故障を検知して問題のあるインスタンスを交換します。これまで GPU 故障時は手動での対応が必要でしたが、この機能により可用性が大幅に向上します。NVIDIA DCGM を使用して継続的に監視し、EventBridge 経由で通知も可能です。対応する NVIDIA GPU インスタンスタイプで追加料金なしで利用できます。詳細は こちらのドキュメントをご参照ください。 4/23(木) Amazon Redshift が Apache Iceberg テーブルに対する UPDATE、DELETE、MERGE をサポート Amazon Redshift で Apache Iceberg テーブルに対する UPDATE、DELETE、MERGE 操作がサポートされました。これまで Iceberg テーブルの個別行を修正するには外部エンジンが必要でしたが、今回のアップデートにより Redshift から直接データ操作が可能になります。データパイプラインの複雑さや遅延を削減でき、変更データキャプチャや緩やかに変化するディメンションなどの一般的なデータ統合パターンで活用できます。詳細は こちらのドキュメントをご参照ください。 AWS Client VPN が AWS Transit Gateway とのネイティブ統合をサポート AWS Client VPN が AWS Transit Gateway とのネイティブ統合をサポートしました。これまで複数の VPC にリモートアクセスするには中間 VPC の管理が必要でしたが、今回のアップデートで不要になり運用が大幅に簡素化されます。さらにエンドユーザーの IP アドレスが保持されるため、セキュリティ監査やトラブルシューティングが容易になります。詳細は こちらのドキュメントをご参照ください。 Amazon Athena がマネージドコネクタでフェデレーテッドクエリを簡素化 Amazon Athena で DynamoDB や PostgreSQL、MySQL、Snowflake など 12 のデータソースに対するマネージド コネクタが提供開始されました。従来は S3 以外のデータをクエリするためにコネクタリソースのデプロイや管理が必要でしたが、マネージド コネクタにより Athena が自動でセットアップと管理を行うため、この手間が不要になりました。データを移動することなく、複数のデータソースを横断してクエリできるため、分析作業が大幅に効率化されます。詳細は こちらのドキュメントをご参照ください。 4/24(金) Amazon Connect が AI エージェントのパフォーマンスを測定・改善するための 8 つの新しいメトリクスを提供開始 Amazon Connect で AI エージェントの性能を測定する 8 つの新しいメトリクスが利用可能になりました。ゴール成功率や忠実度スコア、ツール選択精度などを通じて、AI が顧客の問い合わせを正しく解決できているかを詳細に分析できます。従来は AI エージェントの品質評価が困難でしたが、今回のアップデートで定量的な改善が可能になります。専用ダッシュボードや API を通じてデータにアクセスでき、カスタマーサポートの質向上に活用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Gateway と Identity が VPC egress をサポート Amazon Bedrock AgentCore Gateway と Identity が VPC egress をサポートし、プライベートネットワーク内のリソースと安全に通信できるようになりました。従来は外部からアクセスできないプライベート環境のリソース呼び出しが困難でしたが、今回のアップデートにより EKS 上の MCP サーバーなどを直接利用可能になります。マネージド設定で簡単に開始でき、複雑な要件には自己管理も選択できます。東京リージョンを含む 14 リージョンで利用可能です。 詳細はこちらのドキュメントをご参照ください。 Amazon Q がワークフォースインテリジェンスのための Visier の Vee エージェントと統合 Amazon Quick が Visier の AI アシスタント Vee と統合されました。これにより HR や財務担当者が Amazon Quick 内で直接人事データにアクセスできるようになります。従来はツールを切り替える必要がありましたが、今回のアップデートで自然言語による質問で人員数や離職率などの情報を瞬時に取得可能です。詳細は こちらの Blog 記事をご参照ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

G-gen の佐々木です。当記事では、Google Cloud Next '26 で発表された Google Cloud のデータベースに関する新機能について、公式の投稿記事「 What’s new with Databases: Powering the agentic future 」の内容をもとに紹介します。 はじめに Embed AI into every layer of the data stack AI Studio とのバイブコーディング連携（GA） データエージェント向けツール（Preview） Database Onboarding Agent / Database Observability Agent（Preview） AlloyDB AI-Powered Search at Scale（Preview） AlloyDB の AI 関数の追加と最適化（Preview） データベース向けマネージドリモート MCP サーバー（GA / Preview） MCP Toolbox for Databases 1.0（GA） Break down walled gardens with lakehouse integrations AlloyDB の Lakehouse Federation（Preview） BigQuery から AlloyDB への Reverse ETL（Preview） Datastream による継続レプリケーション（GA） Knowledge Catalog（旧称 : Dataplex Universal Catalog）（Preview） Spanner Columnar Engine（GA） Database Center の BigQuery サポート（Preview） Commitment to open data and multi-cloud flexibility Spanner Omni（Preview） Bigtable In-Memory（Preview） Memorystore for Valkey 9.0（GA） Oracle AI Database@Google Cloud の拡張 Compute Engine からマネージドサービスへの移行機能（Preview） Firestore の全文検索 / 地理空間検索（Preview） はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された Google Cloud のデータベース製品に関する新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Coming Soon）は 2026年4月23日現在の情報です。 Google Cloud Next '26 では、AI モデル、データ分析、運用データベースを単一の AI ネイティブ基盤に統合するアーキテクチャとして Agentic Data Cloud が提唱されました。当記事では以下の公式投稿の内容に沿って、データベースに関する新機能を紹介します。 参考 : What’s new with Databases: Powering the agentic future 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp Embed AI into every layer of the data stack AI Studio とのバイブコーディング連携（GA） Google AI Studio とデータベースの統合が GA となり、自然言語プロンプトから、データベースと接続済みで即座に動作するアプリケーションを数秒で生成できるようになりました。現時点では Firestore との接続が GA で提供されており、Cloud SQL for PostgreSQL のサポートも近日提供予定とされています。 プロトタイピングから本番運用まで、エージェント主導の自動化ワークフローとデータベースをシームレスに接続できる点が特徴です。 参考 : From prompt to production: Build full-stack apps faster with Google AI Studio and Firebase データエージェント向けツール（Preview） AlloyDB、Cloud SQL、Spanner で、データエージェントから使えるツール群が Preview 提供となりました。その中核となる QueryData ツールは、自然言語から SQL を生成する text-to-SQL を扱う機能で、公式ブログでは「ほぼ100%の精度」と説明されています。 QueryData は、 コンテキストセット と呼ばれる JSON 形式のナレッジベースを利用する点が、従来の汎用的な text-to-SQL との違いです。開発者があらかじめ監査・整備したコンテキストセットを参照してクエリを組み立てるため、LLM に自由生成させる方式と比べて、実データや業務要件に即したクエリを安定して生成できます。 また QueryData からデータへのアクセスは、 パラメータ化セキュアビュー （Parameterized Secure Views）を介して行われます。パラメータ化セキュアビューは、 PostgreSQL のセキュアビューの拡張機能であり、行レベルセキュリティやフィルタ条件をビュー側にあらかじめ組み込んでおける機能です。エージェントが自然言語から組み立てたクエリであっても、ログインユーザーに許可された範囲のデータだけが参照される状態を保つことができます。 カスタマーサポートの自動化、e コマースのショッピングアシスタントなど、定型的な問い合わせが大量に発生するユースケースでの利用が想定されています。 参考 : QueryData helps agents turn natural language into queries for AlloyDB, Cloud SQL and Spanner 参考 : QueryData の概要 参考 : パラメータ化されたセキュアなビューの概要 Database Onboarding Agent / Database Observability Agent（Preview） データベースの導入と運用を支援する2つのエージェントが Preview 提供となりました。 Database Onboarding Agent は、小規模システムからエンタープライズ要件まで、要件に応じた最適なデータベースを選択し、プロビジョニング作業をガイドするエージェントです。 Database Observability Agent は、AlloyDB、Bigtable、Cloud SQL、Spanner のパフォーマンスを監視し、潜在的な問題の根本原因の特定や、改善策の提示を行うエージェントです。運用中のデータベース群の観測と改善を自動化する機能となっています。 AlloyDB AI-Powered Search at Scale（Preview） AlloyDB のベクトル検索基盤に、Google が開発した ScaNN インデックスを活用した大規模ベクトル検索機能が Preview 提供となりました。最大100億ベクトルまでスケールし、標準 PostgreSQL の HNSW インデックスとの互換性を実現しながら6倍高速なベクトルクエリを実現します。また、カラム型エンジンによる高速化により、HNSW を使用する場合でも標準 PostgreSQL の4倍高速になります。 加えて、キーワード検索とベクトル検索を組み合わせたハイブリッド検索を可能にする BM25 のネイティブサポートも近日追加予定です。BM25 は Elasticsearch をはじめとする主要な検索エンジンで広く採用されている、単語の一致を基準に関連度を算出するキーワード検索のランキングアルゴリズムです。固有名詞や厳密な語句一致が得意な BM25 と、意味の近さを捉えるベクトル検索を1つのデータベース上で組み合わせられる点が特徴です。 参考 : ベクトルインデックスの概要 参考 : Okapi BM25 - Wikipedia AlloyDB の AI 関数の追加と最適化（Preview） AlloyDB に、SQL から直接 LLM を呼び出せる新しい AI 関数が Preview 提供となりました。 新規に ai.analyze_sentiment （感情分析）、 ai.summarize （要約）が追加され、既存の ai.if 、 ai.rank 、 ai.generate 、 ai.forecast についても最適化が施されています。各関数の用途とユースケースを以下にまとめました。 AI 関数 用途 ユースケース例 ai.if 自然言語による条件判定（インテリジェントフィルタリング） 振る舞いパターンから不正の疑いがある取引を検出 ai.rank ベクトル検索結果の再ランク付け 文脈に即して検索結果を並べ替え ai.generate コンテンツ生成、データフォーマット変換 生のサーバーログを解析しやすい JSON へ変換 ai.analyze_sentiment テキストの感情（ポジティブ / ネガティブ / ニュートラル）を分類 商品レビューから顧客満足度を評価 ai.summarize 長文テキストの要約 議事録から決定事項やアクションアイテムを抽出 ai.forecast TimesFM による時系列予測 過去の売上データから将来の在庫需要を予測 参考 : AI 関数の概要 参考 : AI 関数を使用してインテリジェントな SQL クエリを実行する データベース向けマネージドリモート MCP サーバー（GA / Preview） Google Cloud の各データベースで、 Model Context Protocol （MCP）に対応したフルマネージドのリモート MCP サーバーが提供開始となりました。Gemini をはじめとする MCP 準拠のクライアントが、データやインフラストラクチャと安全にやり取りするためのインターフェースを提供します。 参考 : Powering the next generation of agents with Google Cloud databases MCP サーバーの提供ステータスはサービスにより異なるため、最新のステータスは以下の公式ドキュメントの原文（英語）をご確認ください。 参考 : Supported products Google Cloud が提供している MCP サーバーの詳細については、以下の記事を参照してください。 blog.g-gen.co.jp MCP Toolbox for Databases 1.0（GA） MCP Toolbox for Databases は、AI エージェント、IDE、アプリケーションといった MCP クライアントからデータベースに直接接続するための、オープンソースの MCP サーバーです。Gemini CLI や Claude Code などの MCP 準拠クライアントから、Google Cloud のマネージドデータベースに加え、PostgreSQL、MySQL、Oracle、MongoDB、Redis、Snowflake など、合計40以上のデータベースを扱えるようにします。 テーブル一覧の取得（ list_tables ）や SQL 実行（ execute_sql ）といった汎用ツールがデフォルトで利用できるほか、独自のロジックをカスタムツールとして定義することで、エージェントが実行可能な操作をあらかじめ限定できます。 参考 : googleapis/mcp-toolbox（GitHub） Break down walled gardens with lakehouse integrations AlloyDB の Lakehouse Federation（Preview） AlloyDB から BigQuery や Apache Iceberg のライブデータを、PostgreSQL のインターフェースで直接照会できる Lakehouse Federation が Preview 提供となりました。 AlloyDB Studio の UI から BigQuery や Iceberg のテーブルを探索でき、フィルタや集計は BigQuery 側にプッシュダウンされます。データを移動せずに、オペレーショナルデータと分析データのライブ結合が可能です。 BigQuery から AlloyDB への Reverse ETL（Preview） BigQuery で算出したインサイト（顧客セグメント、レコメンドスコア、需要予測など）を、AlloyDB にワンクリックで同期できる Reverse ETL 機能が Preview 提供となりました。 アプリケーションから BigQuery を直接参照するのは、レイテンシや同時実行数、コストの観点で現実的でないケースが少なくありません。あらかじめ BigQuery で計算しておいたインサイトを AlloyDB に戻しておけば、アプリは普段通り AlloyDB を参照するだけで、分析結果を画面表示やレコメンドなどのリアルタイム機能に組み込めます。 同期先の AlloyDB は、読み取りを高速化するカラム型エンジンと高速キャッシュによって、多数の同時リクエストに低レイテンシで応答できるアプリケーションバックエンドとして機能します。 参考 : AlloyDB にデータをエクスポートする（リバース ETL） Datastream による継続レプリケーション（GA） Datastream を介して、AlloyDB から BigQuery や Apache Iceberg テーブルへ 継続的レプリケーション を行える機能が GA となりました。 Datastream はサーバーレスで動作し、特に AlloyDB から BigQuery へのストリームには無料枠が提供されます。リアルタイムの ML 特徴量生成など、分析側との連携を前提としたユースケースに適しています。 参考 : ストリームの作成 Knowledge Catalog（旧称 : Dataplex Universal Catalog）（Preview） データガバナンス サービスである Dataplex Universal Catalog が、 Knowledge Catalog へ名称変更されました。Dataplex Universal Catalog は、BigQuery のテーブルや Cloud Storage 上のファイルなど Google Cloud 上のデータ資産に対して、メタデータ、データ品質、リネージ、アクセス制御を一元的に扱えるサービスです。 名称変更に合わせ、AI エージェントがデータの業務的な意味を踏まえて動けるようにするための「コンテキストエンジン」としての機能が Preview 提供となりました。Google Cloud の製品だけでなく、パートナーのデータプラットフォームやサードパーティカタログからも情報を取り込み、組織横断のデータガバナンスの起点として機能します。 Knowledge Catalog の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Spanner Columnar Engine（GA） Spanner Columnar Engine が GA となりました。行ベースのストレージと並行して列指向フォーマットでデータを保持し、複数行をまとめて処理するベクトル化実行を組み合わせることで、稼働中のトランザクションデータに対する集計・分析クエリのスキャンを最大200倍高速化するとされています。 また、Iceberg テーブルのサポートや、BigQuery からの継続的な Reverse ETL、フェデレーションクエリの高速化にも対応したことで、Spanner を単独で HTAP （Hybrid Transactional/Analytical Processing）的に使える範囲が広がりました。HTAP は、トランザクション処理（OLTP）と分析処理（OLAP）を、ETL を介さずに1つのデータベースで兼ねるアーキテクチャを指す用語です。 参考 : Spanner カラム型エンジンの概要 Database Center の BigQuery サポート（Preview） Database Center は、Google Cloud のデータベースサービスを横断して、フリート全体の健全性、パフォーマンス、セキュリティ、コンプライアンスを一元的に可視化・管理する管理コンソールです。 この Database Center での BigQuery サポートが Preview 提供となりました。これにより、Google Cloud のマネージドデータベースや Compute Engine 上で運用しているデータベースに加えて、BigQuery も一元的に扱えるようになります。 Gemini によるフリートアナリティクスによってパフォーマンス改善の余地を検出できるほか、メトリクスをサードパーティツールへ連携するための API とマネージド MCP サポートも提供されます。 参考 : Database Center の概要 Commitment to open data and multi-cloud flexibility Spanner Omni（Preview） Spanner Omni が Preview 提供となりました。Spanner Omni は、従来 Google Cloud 上でのみ提供されていた Spanner を、自社データセンター、他クラウド、エッジなど任意の場所で稼働できるダウンロード可能なエディションです。 Spanner のスケーラビリティ、高可用性、強整合性、エンタープライズセキュリティ、マルチモデル機能を、自社データセンターや他クラウドなどの環境でも利用できるようになります。 参考 : Spanner Omni を発表：あらゆるインフラで Google のイノベーションを活用 参考 : Spanner Omni の概要 Bigtable In-Memory（Preview） Bigtable に、1ミリ秒未満の読み取りレイテンシを実現する新しい インメモリ階層 が Preview 提供となりました。Bigtable は2026年4月から Enterprise と Enterprise Plus の2つのエディションを提供しており、このインメモリ階層は Enterprise Plus エディションの一部として提供されます。 インメモリ階層は Bigtable ノードの一部として統合されており、RAM / SSD / HDD のハイブリッド ストレージアーキテクチャによって、頻繁にアクセスされるホットデータをメモリに、長期保管データを低コストストレージに置く、といった使い分けが透過的に行えます。 参考 : エディションの概要 参考 : インメモリ階層の概要 Memorystore for Valkey 9.0（GA） Memorystore for Valkey が Valkey バージョン 9.0 に対応しました。Memorystore 以外で独自に運用している Redis や Valkey を Memorystore へ移行するためのパスも提供されます。 また、選べるノードサイズに小型と大型が加わり、ワークロードの規模に応じて性能とコストのバランスを取りやすくなりました。ブルームフィルタを提供する valkey-bloom 、JSON ドキュメントをネイティブに扱える valkey-json といったモジュールへの対応や、ACL、トークンベース認証、柔軟な認証局設定などのエンタープライズレベルのセキュリティ機能も整備されています。 参考 : Memorystore for Valkey の概要 Oracle AI Database@Google Cloud の拡張 Oracle AI Database@Google Cloud の提供が20リージョンまで拡大しました。なお、東京リージョンは2025年6月に対応済みです。 加えて、 Oracle GoldenGate Service のサポートが追加され、Oracle DB から BigQuery へのニアリアルタイムなデータレプリケーションが可能になります。さらに、前述の Knowledge Catalog（旧称 : Dataplex Universal Catalog）および Database Center との統合も発表されました。 参考 : Oracle Database@Google Cloud overview Compute Engine からマネージドサービスへの移行機能（Preview） Compute Engine 上で自前運用している PostgreSQL などのデータベースを、Cloud SQL や AlloyDB といったマネージドサービスへ移行できる機能が Preview 提供となりました。移行フローは Database Center にネイティブに統合されており、Database Center の画面からそのまま移行を開始できます。 PostgreSQL 向けにはネットワーキングとレプリケーションが自動化されており、最小限の作業とダウンタイムで移行できる点が特徴です。 Firestore の全文検索 / 地理空間検索（Preview） Firestore で 全文検索 および 地理空間検索 機能が Preview 提供となりました。これまで別サービスと組み合わせる必要があった検索機能が、Firestore 単体でサーバーレスに提供され、キーワード / フレーズ / 地理空間クエリに対して高い関連度で応答できます。 参考 : Use text searches 参考 : Use geo queries 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

DBRE (DataBase Reliability Engineering)チームの taka-h です。 2025年10月のTiDB User Dayにおいて、 オートスケールについて取組み中(P. 81)であることをご紹介 しました。この記事では、その後のオートスケールの取り組み状況についてお伝えします。 結論としては、2025年11月時点で、DBREが管理するTiDB移行済みの全クラスタでTiDBの水平方向オートスケール導入が完了し、その後も安定稼働しています。 次の画像は、メルカリ内のとあるCluster(l1-2)で、オートスケールがCPU利用率の平均値を60パーセント前後に保つように動作している様子を示したものです。 なお、TiDB Cloudにはいくつかの製品ラインアップがありますが、本記事での以後のTiDB Cloudという言葉は、いわゆるサーバーレスではない「TiDB Cloud Dedicated」を指すものとします。 背景：なぜTiDB Cloudでオートスケールが必要だったか メルカリでは、最初にTiDBのオートスケールの実装をすることを決め、初期の実装ターゲットをTiDBに絞ってオートスケールの導入を進めました。 まずはこの経緯を簡単に説明します。 実装決定に至った経緯 最初に既存のライブラリの実装状況を調査しました。 TiDBをKubernetes上でホスティングするためのライブラリとしては、 tidb-operator があります。このライブラリでオートスケールが実装されていれば、我々が利用しているTiDBのマネージドサービスであるTiDB Cloudでもオートスケールが近々実現されることが想定されます。 オートスケール導入を検討した当時は、次の状況でした。 当初実装されていたオートスケールの機能が削除されていた TiDB Cloudの開発ロードマップにオートスケールの機能が入っていない （最新の tidb-operator v2ではCRDのsub resourcesに対応 しています） また、TiDB Cloudは自動での水平/垂直のオートスケールの機能が提供されていない一方で、スケール変更についてAPIが提供されています。 https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster/operation/UpdateCluster APIがあれば、オートスケールは実現のための必要条件を満たすので、まずはオートスケールの実現のため実装を進めることとしました。 実装対象の選定 オートスケールの実装を決めた後、最初にオートスケール化の対象を決める必要があります。 メルカリにおけるTiDB Cloudのコストの構成としては、オートスケール導入前の時点で、大雑把にTiKVが6割程度、TiDBが2割程度でありました。TiKVが実データを持つのに対し、TiDBはステートレスでオートスケールに対する考慮事項が少なく、比較的容易に実現できますので、まずは実装対象をTiDBとし、要件を定義の上実装することにしました。 https://docs.pingcap.com/tidb/stable/tidb-architecture/ 方針1：Kubernetes HPA活用, しかしマネージドサービス特有の壁があった (オートスケール v1) 実装範囲を決めた後、最初はKubernetes HPA(Horizontal Pod Autoscaler)を活用して実装する方針としました。ここではその最初の方針決定の経緯、そして方針変更に至った経緯を順に説明します。 要件を定義の上LLMで実装する予定でしたので、フルカスタム実装でもよかったのですが、主に、社内で Elasticsearchのオートスケールが実現されていた ため、これと同様にKubernetesのNativeのオートスケールの機能の活用して実現することに決定しました。 具体的には、実績があり安心できるという理由の他には、Kubernetes Nativeのオートスケールを利用すると、次の利点がありました。 考慮すべき様々な一般的な考慮事項が既に満たされており、これを活用することでその実装が不要になり、開発すべき機能のスコープが絞られる 例) スラッシング回避、一度に増減できるノード数上限、など datadog経由のメトリクス連携を既存のオートスケールの機能でできる クレデンシャルのセットアップなども追加で不要 運用が他のKubenetesのものとそろう 既存のパターンとの違い: Podが管理するClusterに存在しない 既存のElasticsearchのオートスケールと今回のTiDB Cloudでは、前提条件が大きく異なります。既存のパターンは「自分たちが運用するKubernetesクラスタ上でPodが動いている」ことを前提に、HPAがPodのスケールを制御していました。 一方で、TiDB Cloudを利用する場合、実際のPodはTiDB Cloud上で動作しており、メルカリが管理するKubernetesクラスタ上には存在しません。このため、既存パターンと同様にHPAを適用しようとすると「スケール対象として参照できるPodがない」という問題に直面します。 そこで、TiDB Clusterを表すCustom Resourceを定義し、これをHPAのスケール対象として扱う方針で検討を進めました（次節で説明します）。 実際のPodがない対象へのHPA ここでやりたかったのは、TiDB CloudのTiDBノード数変更を、KubernetesのHPAの仕組みに乗せて自動化することです。そのために、TiDB Clusterを表すCustom Resourceを定義し、HPAがその replicas を増減できる構成を検討しました。 しかし、HPAがCustom Resourceをスケール対象として扱うには、 scale subresource （ /scale ）を提供する必要があり、あわせて labelSelectorPath の定義が求められます。 labelSelectorPath は、本来スケール対象に紐づくPod群を特定するための情報です。 https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource TiDB Cloudでは該当Podが自クラスタに存在しないため、この前提を満たせず、通常の形ではHPAが成立しませんでした。一方で、 External Metricsで AverageValue を使う場合に限り、結果的にselectorが評価に使われない挙動 があり、 labelSelectorPath をダミーにしても動作しました（ただし仕様保証がなく、運用上のリスクが残ります）。 https://docs.cloud.google.com/kubernetes-engine/docs/tutorials/autoscaling-metrics : autoscaling/v1beta1（旧形式） metrics: - type: External external: metricName: pubsub.googleapis.com|subscription|num_undelivered_messages metricSelector: matchLabels: resource.labels.subscription_id: my-subscription targetAverageValue: "2" : autoscaling/v2 (現行推奨) metrics: - type: External external: metric: name: pubsub.googleapis.com|subscription|num_undelivered_messages selector: matchLabels: resource.labels.subscription_id: my-subscription target: type: AverageValue averageValue: "2" 方針2: フルカスタムへ切り替え、運用可能な形へ収束 (オートスケール v2) ステージング環境までは、何とかこの実装で動作はしたのですが、External Metrics連携が想定通りに動作せず、次の理由からCustom Resourceを定義し、reconcileのループを回すところだけ残し、その他をフルカスタム実装に切り替えることにしました。 Native HPAの機能を活用している既存の実装は、現状利用している特定のパターンが将来的に利用できなくなる可能性が払拭できない デバッグが困難を極めた LLMでオートスケールのような「よくある」実装が非常に容易になっている フルカスタム実装に切替えてから、オートスケールで考慮すべき一般的な考慮事項についての学びを1つ1つ獲得しながら、下記の方針で、迅速にそして大きな問題なくオートスケールを導入完了できました。 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること 想定外であった場合に、それを検知する実装/設計になっていること つまり、当初は実装精度が十分ではなく、オートスケールの制御精度もやや低い状態でした。そこで初期は目標値を保守的に設定し、まずは一定のコスト削減を達成しました。あわせて、目標値との差分（猶予）を確保しつつ、想定外を検知できる仕組みを用意しました。そのうえで、運用しながら段階的に精度を高めていきました。精度が低い状態を許容するには、想定外の事態や異常の検知が十分に検討され、適切に実装されていることが前提になります。 最低限担保すべき範囲 オートスケールでは、ある指定されたメトリックが目標値になるようリソースを増減させます。 運用開始時に、この目標値に余裕を持たせる前提であれば、 最小ノード数を一定以下にしないこと 一度に可能な増減ノード数を制御できていること ノード増減操作の連続操作に制約を与えること が期待通りに動作していれば、提供するサービス品質に影響が発生するということはないと考えました。 想定外を検知する実装/設計 最低限担保する範囲を厳密に守りながら、実装速度を優先し、運用中に改善を重ねていく前提で開発を進める方針でしたので、運用中の改善を許容するためには「異常な状態」をうまく検知できる必要があり、そのために必要なメトリクス/アラートについて、事前に多くの検討を行いました。 ここでの検討事項には、次の3つのポイントがありました。 1. 制御するパラメータに対する適切なアラート設計/設定 現時点ではCPU利用率を一定範囲にコントロールすることを目標にオートスケールを運用しています。当たり前ですが、利用率が低すぎれば、それはリソースが有効に活用できておらず、利用率が高すぎれば、サービスの提供品質に問題がでる、こういったことが起きない範囲にコントロールすることを目指します。 オートスケールでの制御目標値 実際のアラートの閾値(Cluster/Node) 上記のような値を適切な上下関係に設定し、運用を行うこととしました。 2. 依存関係のモニタリング オートスケールが依存しているAPIの品質/問題に対して異常検知を行うことが重要であると考えました。今回は現状のメトリクスを把握するためのdatadogのAPI、そしてTiDB CloudのAPIが該当します。 例えば、APIレスポンスが遅くなったり、特定のエラーコードが一定以上発生したり、データ点が欠損したり、あるいは、変更操作を起こった際の所要時間をモニタリングし、これが期待値通りかを観測する、といったことです。 3. オートスケールの想定内・想定外の規定 オートスケールでは、ノードを追加したり、削除したり、変更操作を随時行っています。 一方で、あるノードの予期せぬ再起動、といったことも発生します。 外部から観測できるメトリクス(Clusterの状態や、NodeのUptimeなど)から、どのような状態/変化が想定通りか、あるいは想定外かを考え、規定しています。 これらを可能にした周辺改善 オートスケールは、当たり前のように実施しなければならない項目ではありますが、それを実現するために、メルカリ社そしてTiDB Cloudの提供元であるPingCAP社の様々な改善がありました。 一番大きなものは、TiDB CloudのTiDBのスケール操作(スケールアップ/スケールダウン/スケールイン)がgracefulではなかった点を、メルカリ/PingCAP社で改善したことです( TiDB User Day 2025 P.36~ )。 そして、TiDB CloudのdatadogのCPUメトリクスの値の信頼性が十分でなく、オートスケールなどに利用するのが難しい、といった問題への対処、また、オートスケールをAPIで実施する際の 権限制御の改善 、などがありました。 度重なる要望に対して、改善を積み重ねていただいたPingCAP社には改めて感謝します。 今後: TiKVへの展開の難しさと次の一手 現在、より大きなコスト割合を占めるTiKVのスケーリングに取り組んでいます。 TiKVはデータを保持するため、これを水平スケールする際には、データの偏りをなくすためのリバランス、が必要です。水平スケールの戦略を取るためには、スケールインの際には削除対象のノードのすべてのデータを他のノードに移動してからではないと、ノードを削除できません。 現在、「1日の中で負荷が上下し、TiKVで必要なリソースが変化するので、これに最適なリソースにし、コストを抑制しながら必要なリソースを必要なだけ確保したい」という要望があります。データのリバランスは、既存のノードの性能にも影響を与える可能性があり、そのため一般的にはその速度がある程度抑制されています。水平スケールに求めるスケール速度が、このような1日の中でノードを増減する必要がある、という場合においてスケールインは不向きであるといえるでしょう。また、逆にもう少し長いスパンでのスケールの自動追従であれば、コストに対するインパクトがそこまでないため実現の重要性は下がるでしょう。 これに対して、リバランスの速度を調整する、という選択肢も考えられます。しかし、現状ではTiDBではこのリバランスの設定を含む、TiKVの設定変更に対してAPIが提供されておらず、現状取りうる手段は、サポートチケット経由での設定の変更依頼が必要です。 そこで、まずは垂直スケールの機能の導入を目指しています。 TiKVの垂直スケールにおけるメモリ有効活用 今後も追加で様々な課題が見つかるかとは思いますが、現状、大きなインスタンスクラスでTiKVを運用した場合、メモリを有効活用できない課題がありましたので、それを解決しています。 MySQLやその他のデータストアや、システムでもよくある問題ですが、データベースをホストしているノードの安定稼働のために、データベース以外、あるいは主に利用するリソース以外で利用するリソースを一定割合確保するため、主に利用するメモリの利用率を保守的に設定することがあります。 TiDBにおいては、TiKVの block_cache.capacity , memory_usage_limit といった設定が主に積極的に活用したいリソースでありますが、現状のTiKVの実装状況で発生している拘束条件として、これらのパラメータについては、初期値は固定の割合で指定されるものの、初期値ではない値に変更する場合に、利用するメモリ利用量を数値で指定する必要がありました。 https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#memory-usage-limit https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#capacity 先述の通り、TiDB Cloudではこれらの設定を変更するAPIもありませんので、メモリを有効活用するためにメモリ利用量を、値を指定して変更する場合、現状サポートチケット経由で変更依頼が必要です。この状況では、負荷に合わせて自動で垂直スケールしたい、といった場合に、サポートチケット経由での変更が必要になり、結果として適切にメモリ利用量を追従させられません。 すなわち、TiKVを大きなインスタンスクラスで運用した場合、メモリが余剰しリソースを有効活用できない、という問題がありました。具体的にはblock-cache.capacityのデフォルト値の45%に近い、50%前後までしか、メモリを活用できませんでした。 そこで、TiKVのメモリを割合で指定し、大きなインスタンスタンスクラスで運用する場合に、これを大きな値に設定することができるように修正しました。この修正はmasterブランチにマージ済みで、次のマイナーバージョンである8.5.7で利用可能になる見込みです。 https://github.com/tikv/tikv/pull/19419 まとめ メルカリではTiDB Cloudを運用しており、負荷に合わせTiDBの水平方向のオートスケールを安定的に運用しています。これにより、TiDBの50%前後のコストが削減されました（トータルでは、全体の2割の約半分、の削減効果）。 既存のKubernetesのNativeの機能を活用する方針で初期の検討を始め、ステージング環境までも動作させたものの、LLMにて再実装を行ったこと、また、LLMでの実装については、 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること 想定外であった場合に、それを検知する実装/設計になっていること を基本方針として迅速に実装を完了させたこと、 一見当たり前のようにみえる、オートスケールの実現自体には、実はとても大変な基礎的な改善の数々があること、また、最後にTiKVの垂直スケールでメモリを有効活用するため、修正をコントリビュートしていること、をお伝えしました。 最後に、現在メルカリでは、この記事の発行者の所属する DBREチーム の EM(Engineering Manager) を募集しています。詳しくは こちら をご覧ください。