TiDB クラスタ統合の取り組み メルカリでは、CoreDB と呼ばれる中核データベースを、オンプレミス環境のMySQL から TiDB Cloud へと移行しました。MySQL から TiDB への移行に至った背景や移行全体の概要については、 メルカリのCoreDBをMySQLからTiDBへ移行した振り返り で詳しく紹介しています。 本エントリーでは、TiDB Cloud 移行後に実施した、TiDB クラスタの統合について、その背景や進め方、得られた知見について共有します。 クラスタ統合の背景 メルカリのCoreDBをMySQLからTiDBへ移行した振り返り でも説明されているように、CoreDB はサービスの成長に合わせて、垂直シャーディングを繰り返してきました。 柔軟性に乏しいオンプレミス環境では、データ量やトラフィックの増加に対応するため、シャーディングによってデータベースを分割し、十分なキャパシティを常に確保しておくことが重要でした。 一方で、シャーディングには以下のようなデメリットがあります。 開発の複雑性の増加 クラスタをまたいだトランザクションが行えない データ不整合の検出・解消をアプリケーション側で実装する必要がある、など 運用コストの増加 クラスタごとに監視や設定、メンテナンス作業が発生 障害対応時の確認対象の増加 小規模クラスタの最低維持コスト 最小構成でも余剰リソースが発生 TiDB Cloud へ移行したことで、書き込み性能を含めたスケーラビリティが向上し、シャーディングによるキャパシティ確保を行う必要性が低下しました。移行後の TiDB 環境ではクラスタ（シャード）を統合できる可能性が出てきました。 統合対象クラスタの選定 今回の環境では「テーブル間の依存関係により分割が難しい」「機能・サービスの廃止によって利用が減った」etc… というような背景でクラスタごとの規模には大きな差がありました。以下のようなイメージです。 小規模クラスタは、TiDB Cloud の最小構成でもリソースに余剰がありました。そのため、統合によるコスト削減が見込めました。一方、検討時点では、超大規模クラスタはまだ移行途中だったこと、初めての統合作業となることを考慮し、今回は3つの「小規模クラスタ」を１つの「中規模クラスタ」へ統合することにしました。 統合方法の検討 まず、２つのクラスタを１つのクラスタへ統合し、これを繰り返すことで、最終的に、３つの小規模クラスタを中規模クラスタへと統合することとしました。２つのクラスタを統合する方法は大きくわけて２つのアプローチが考えられました。それぞれの方式の大まかな作業の流れは以下になります。 方式１：新規統合クラスタ方式 ①新しいTiDB クラスタをつくり、そこに統合する２つのクラスタのデータをインポートします ②それぞれの統合元クラスタから、新規統合クラスタへとレプリケーションを設定し、データを同期するようにします ③それぞれのクラスタへ接続しているアプリケーションの接続先を順次切り替えます メリット データのインポート作業において、サービスへ影響を与えるリスクがほとんどない デメリット 統合作業中はクラスタ数が増えるため、コストが一時的に増加する 統合元と統合先の双方で、アプリケーションの接続先変更が必要 方式２：既存クラスタ追記方式 ①既存の統合先クラスタ（中規模クラスタ）へ、統合元のデータをインポートします ②統合元クラスタから、統合先クラスタへとレプリケーションを設定し、データを同期するようにします ③最後に統合元クラスタへ接続しているアプリケーションの接続先を切り替えます メリット 新規のクラスタが不要なため、コストの増加が抑えられる 統合元のアプリケーションのみ接続先を変更すれば良い デメリット 稼働中のクラスタへデータのインポートを行う必要がある。インポート作業において、サービスへ影響を与えないよう考慮が必要 私たちは、「方式２：既存クラスタ追記方式」を採用することにしました（このことが、後ほどトラブルを引き起こす要因の１つになります・・・）。中規模クラスタを利用しているサービスの停止は影響範囲は比較的大きく、ダウンタイムを伴うメンテナンスの調整に手間がかかることが主な選択理由です。 発生した課題 TiCDC によるインポート制限の回避 統合先クラスタでは、TiDB Change Data Capture (TiCDC) を利用して、他システムへリアルタイムデータ連携を行っていました。TiCDC 動作中の物理インポートはサポートされていません（物理インポートは TiKV に直接データを書き込み、TiCDC が利用する変更ログを生成しないため、インポートしたデータが連携先に反映されない。詳細は 公式ドキュメント を参照）。TiDB Cloud では TiCDC が設定してあると、インポートが使えないように制限されています。 PingCAP のサポートへ依頼し、この制限を解除してもらいました。 その上で、念のため、インポートが TiCDC に予期しない影響を与えないよう、 TiCDC の対象外のテンポラリのスキーマに対してインポートすることとしました。 エクスポートには dumpling （詳細は 公式ドキュメント を参照）を利用しました。dumpling はファイル名にスキーマ名を記載するフォーマットになっています。ファイル名を変更するだけでインポート先のスキーマ名を変更できました。 出力ファイル名 内容 {schema}.{table}-schema.sql CREATE TABLE 文（テーブル名にスキーマは付かない） {schema}.{table}.{連番}.csv データ本体 {schema}.{view}-schema-view.sql ビューの定義 インポート後に、ALTER TABLE で各テーブルを元のスキーマに移動します。 ALTER TABLE temporary.table_name RENAME TO original.table_name なお、データ連携先へは、統合元クラスタからデータが既に連携されているため、インポートで統合先クラスタへ追加したデータを改めて、連携しなおす必要はありませんでした。 AUTO_INCREMENT の重複エラー問題 接続を統合先クラスタに切り替えたところ、AUTO_INCREMENT を利用しているテーブルでプライマリキーの重複エラーが発生してしまいました。 調査の結果、原因はTiDB の バグ#64561 によるものでした（このバグは TiDB v8.5.5 で修正 されています）。このバグでは、テーブルを別のスキーマへ RENAME した際、AUTO_INCREMENT (Auto ID allocator) がRENAME 前の スキーマ (database ID) を参照し続けます。一方、TiDB ノードを追加したり、再起動したりすると、そのノードの Auto ID allocator はRENAME後のスキーマを参照します。結果、ノード間で異なるAuto ID allocator から重複したIDが払い出されてしまいました。 障害発生時は、手動で AUTO_INCREMENT の値 をリセットすることで復旧しました。 ALTER TABLE テーブル名 AUTO_INCREMENT = 最大値+1 その後の統合作業では、事前に以下を行うことで再発防止としました。 TiDB ノード をローリングリスタートし、AUTO_INCREMENT が正しくRENAME後のスキーマに紐づいた状態にする 全ての TiDB ノード で AUTO_INCREMENT の進み具合 が一致（SHOW CREATE TABLE の AUTO_INCREMENT の値に差分がないこと）していることを確認する インポートによる影響 「統合方法の検討」で説明したように、今回の手順では、稼働中のサービスに利用されているクラスタに対して、インポートを行います。そのため、インポートの負荷によってサービスに影響が出ないよう、対策をした上でインポートを行いました。具体的には以下の対応を行いました。 TiKV を事前に十分にスケールアップする インポート速度の調整 (import.num-threads を下げる) しかし、このような対策をしても、あるクラスタの統合作業時に、影響が出てしまいました。インポートによって多くのデータファイル（SSTファイル）が TiKV に作成された結果、コンパクション処理が遅延し、TiKVサーバが「Server is busy」エラー状態になってしまいました。 再発防止として TiKV へデータを取り込む速度を直接制限するパラメータを設定し、インポートを行うこととしました。 [tikv-importer] range-concurrency = 1 store-write-bwlimit = "20MiB" また、ANALYZE についても、インポート時には行わず、念の為、負荷の低い時間帯に手動で実行するように手順を見直しました。 [post-restore] analyze = "off" まとめ TiDB Cloud への移行によってスケーラビリティが向上したことで、従来はキャパシティ確保のために分割していたクラスタを統合できるようになりました。今回、3つの小規模クラスタを既存の中規模クラスタへ段階的に統合し、運用コストとインフラコストの削減を進めました。完全に１つに統合されたわけではありませんが、それでも、管理対象が減り、管理の手間が大きく減ったと実感しています。 今回は、コストとメンテナンス調整の負担を抑えるために「方式2：既存クラスタ追記方式」を選びました。しかし、その選択が、複雑なインポート手順やそれに起因する AUTO_INCREMENT の問題、さらには稼働中のクラスタへのインポートによる影響といった問題につながりました。今振り返ると、「方式1：新規統合クラスタ方式」にしておけば避けられた問題もあったかもしれません。ただ、方式1 には別のコストや切り替えの大変さがあります。どちらを選んでも悩ましいところがあり、こうした方式選びの難しさをあらためて感じました。 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM（Engineering Manager）および IC（individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは以下をご覧ください。 EM: https://apply.workable.com/mercari/j/7AD4EF9218/ IC: https://apply.workable.com/mercari/j/ACD2689E9E/

はじめに JADOGは、データセンター事業者をはじめ、ユーザー、メーカー、SIer、ネットワーク事業者など、多様な業界のプレーヤーが業界の枠を超えて集まり、建設的な情報共有と活発な議論を行うコミュニティーです。これにより […]

本ブログは 2026 年 5 月 12 日に公開された AWS Blog “ Enabling AI sovereignty on AWS ” を翻訳したものです。 クラウドと AI は、研究の加速や顧客体験の向上から、ビジネスプロセスの最適化や公共サービスの充実に至るまで、かつてないスピードで産業や社会を変革しています。 Amazon Web Services (AWS) は、クラウドと AI がその可能性を最大限に発揮するには、お客様がデータをコントロールでき、ワークロードをどのように、どこで実行するかを選択できる必要があると考えています。2022 年には、 AWS Digital Sovereignty Pledge によってコントロールと選択肢へのコミットメントを正式に表明しました。これにより、クラウドで利用できる最も高度な主権コントロールと機能を、すべての AWS のお客様に提供しています。AI の導入が加速する中、AWS はお客様と協力し、 主権要件を満たしながら AI イノベーションを取り入れられるよう 支援してきました。AWS は、お客様が AWS クラウドの機能、パフォーマンス、イノベーション、セキュリティ、スケールを犠牲にすることなく、AI 主権を含む主権のニーズを満たしながら、AI の変革力を引き続き活用できるよう取り組んでいます。AI 主権に対する AWS のアプローチは、こうしたニーズと、それに伴う実際の導入上の課題に対する深い理解に基づいています。 お客様、パートナー、アナリスト、規制当局との議論を通じて、デジタル主権、そして AI 主権の意味はステークホルダーによって異なることがわかりました。国や地域ごとに独自の主権要件があり、その要件も変化し続けています。また、どのワークロードやセクターが準拠すべきかについて、統一的なガイダンスはありません。このように違いがある一方で、共通するテーマも見えてきました。それは、データ主権 (データレジデンシーとオペレーターによるアクセスの制限を含む) と運用主権 (レジリエンス、存続性、独立性を含む) です。AI 主権はこれらを基盤とし、さらに AI の出力において文化的規範、価値観、現地の言語を守るといった新たな考慮事項が加わります。つまり、デジタル主権と AI 主権の要件を満たすことは、最終的にはお客様により多くのコントロールと選択肢を提供することにほかなりません。 AI スタック全体でのお客様によるコントロールと選択肢の実現 AI 主権には、AI スタック全体にわたるコントロールと選択肢が必要です。AI スタックとは、コンピューティング、ネットワーキング、データ管理、セキュリティコントロール、専門的なアプリケーションサービス、そして人材を組み合わせた包括的なクラウドインフラストラクチャを指します。お客様独自のニーズ、規制要件、イノベーションの目標に沿って、ロケーション、依存関係、サービス、パートナーなどをスタック全体で意図的に選択できることも、これに含まれます。AWS を利用することで、お客様はデータを安全かつ自らのコントロール下に置いたまま、信頼できる基盤の上で AI を開発できます。また、 専用設計の AWS シリコン や、NVIDIA、AMD、Intel のチップなど、AI に最適化された幅広いチップから自由に選択できるため、ワークロードに最適なチップを選べます。AWS は 20 年にわたって培ってきた専門知識を包括的な AI スタックに活かしており、組織はデータと運用を完全にコントロールしながら、最先端の機能を活用して地域の課題を解決できます。 AWS は、AI を個別のユースケースにとどめず、バリューチェーン全体に組み込むためのインフラストラクチャとツールをお客様に提供しています。これにより AI は、モデルのトレーニングとデプロイ、そして卓越したパフォーマンスを備えた高度な AI アプリケーションや生成 AI アプリケーションの構築を可能にする基盤的な能力となります。その結果、お客様はインフラストラクチャではなくイノベーションに集中できます。さらに、 AWS AI Factories 、 AWS Outposts 、 AWS Local Zones 、 AWS Dedicated Local Zones 、 AWS リージョン ( AWS European Sovereign Cloud を含む) など、さまざまな選択肢の中から、最も必要とされる場所でクラウドを利用できます。例えば、ミッションクリティカルな AI ワークロードの主権要件を満たすために専用のデプロイを必要とするお客様は、AWS AI Factories を利用できます。お客様専用に構築され、物理的に分離されたこのデプロイ環境は、 AWS Trainium アクセラレーター、NVIDIA GPU、専用のネットワーキング、ストレージといった最新の AI インフラストラクチャを組み合わせています。AWS AI Factories は、トレーニング、ファインチューニング、リアルタイム推論を安全に実行できるオンプレミスの AI 機能を提供し、AI 主権のニーズに対応します。 AWS の AI ポートフォリオは、 基盤モデル (FM) を提供する Amazon Bedrock から、 Amazon SageMaker AI などの機械学習サービス、 Amazon Q などのアプリケーションサービス、 Kiro などの開発者ツールまで、幅広いサービスで構成されています。これらはいずれも、お客様がデータをコントロールし、AI のデプロイ方法を選択できるように設計されています。Amazon Bedrock では、AI21 Labs、Anthropic、Amazon、Cohere、Mistral AI、OpenAI などの主要プロバイダーが提供する数百のモデルから選択できます。お客様は、特定のニーズに最適な FM を評価して選択し、デプロイ先を決められるほか、独自のデータを使用してモデルをプライベートにファインチューニングすることもできます。データは常にお客様のコントロール下にあります。特に重要な点として、お客様の Amazon Bedrock への入力や Amazon Bedrock からの出力が、 Amazon Nova やサードパーティーのモデルのトレーニングに使用されることは一切ありません。 国家 AI 戦略の支援 AI 戦略を成功させるには、地域の人材を育成し、スタートアップを支援し、業界固有のアプリケーションを開発し、官民パートナーシップを促進する包括的な環境を構築する必要があります。クラウドによって、AI は巨額の投資を必要とする一部の組織だけの技術から、あらゆるセクターや規模の組織がイノベーションに活用できる身近なツールへと変わりました。AI 主権を考える際には技術インフラストラクチャに注目が集まりがちですが、各国の FM が持つ文化的・戦略的な側面も同様に重要です。こうした FM は単なる計算ツールではありません。文化的な知識、言語のニュアンス、社会的な文脈といった要素を取り込めるため、地域との関連性は後から付け加えるものではなく、設計段階から考慮すべき事項となります。また、こうした FM は技術的な能力にとどまらない役割を果たします。地域でトレーニングされた FM は、その地域の法制度、商慣行、規制の枠組みを理解しながら、国の教育カリキュラムや文化的価値観を反映できます。現地の言語、方言、文化的文脈でトレーニングされたモデルは、言語の多様性を支え、これまで十分に扱われてこなかった言語が AI 製品やサービスに反映されるよう後押しします。 AWS は、文化的規範、価値観、現地の言語の保護や、地域や現地の言語に対応した言語モデルの能力開発など、国家にとって重要な優先事項やお客様のミッションを支援しています。 モデルをカスタマイズする 際には、 Amazon SageMaker AI を使用して、音声への対応やドメインへの特化を行ったり、モデルの精度を評価したりできます。例えば、2024 年 3 月に初のギリシャ語の大規模言語モデル (LLM) として公開された Meltemi は、Mistral-7B をベースに構築され、AWS のインフラストラクチャ上で稼働しています。さらに、285 億のギリシャ語トークンからなるデータセットで継続的な事前トレーニングを行うことで、ギリシャ語の能力を高めています。Meltemi は HuggingFace で利用できます。 SEA-LION は東南アジア向けのオープンソースの多言語 LLM ファミリーで、マネージド GPU クラスターを使用し、すべて AWS 上でトレーニングされました。開発チームは 30 億パラメータのモデルをわずか 3 か月で完成させており、これは同等のオンプレミスプロジェクトと比べて 60% 速いペースです。 データアクセスに対する検証可能なコントロール 主権は、データがどこに保存されているかだけの問題ではありません。誰が、どのような条件でデータにアクセスできるかという問題でもあります。AI の文脈では、アクセス制限の対象はインフラストラクチャにとどまらず、モデルの入力と出力、トレーニングプロセス、さらに AI が実行される運用環境にまで及びます。従来のインフラストラクチャとは異なり、AI ワークロードには新たなアクセス対象が存在します。具体的には、モデルそのもの、モデルのトレーニングに使用されるデータ、そして機密性の高い入力が流れる推論パイプラインです。そのため、IT システムにおける検証可能なガバナンスとアイデンティティの伝播の必要性がさらに高まっています。 お客様データの機密性と完全性を確保するため、最新のすべての Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、 AWS Inferentia や AWS Trainium などの AI アクセラレーターを搭載したインスタンスも含め、 AWS Nitro System の業界をリードするセキュリティ機能によって保護されています。お客様がワークロードの実行に使用する Nitro EC2 インスタンス上のお客様データに、AWS の誰であってもアクセスできる仕組みは、設計上存在しません。Amazon EC2 上に構築された AI 機能を持つサービスを含め、AWS のサービスはこれと同じ保護を継承しています。これらの保護は AWS Nitro System 上で処理される AI データに適用されるため、モデルトレーニングから推論まで、あらゆる段階でデータが保護されます。独立したサイバーセキュリティ企業である NCC Group は、 Nitro System の設計を検証 しました。AWS は、このレベルの透明性を提供することが、信頼の構築と維持に不可欠であると考えています。 AI エージェントがユーザーに代わって複数のシステムにまたがるアクションを実行することが増える中、誰が、また何がリソースにアクセスできるかを制御し、人間による適切な監督を確保することが重要になっています。 AWS Identity and Access Management (IAM) は、きめ細かなアクセス許可と包括的な監査証跡によって、認可されたユーザーとアプリケーションだけが AI リソースにアクセスできるようにします。AI エージェントや自動化されたワークロードについては、 Amazon Bedrock AgentCore Identity がアイデンティティと認証情報の管理機能を提供するため、エージェントは必要最小限のアクセス許可だけで動作します。 透明性と保証 透明性は、AWS のデジタル主権へのコミットメントの中核です。AWS は、データをどこに保存し、誰がアクセスでき、どのように使用されるかをお客様がコントロールできるよう、業界をリードする包括的な技術的対策、運用上のコントロール、契約上の保護を提供しています。また、AWS のサービスの設計と運用についてより高い保証を提供するため、お客様のコンプライアンスニーズへの対応に役立つ第三者による証明、認定、認証の取得に引き続き取り組んでいます。 AWS は、お客様への保証と透明性を引き続き強化しています。例えば、 AWS サービス条件を更新 して技術的保護に関するコミットメント (AWS Nitro System など) を反映したほか、お客様データの開示を求める第三者からの要請の取り扱いについて、契約で詳細なコミットメントを示しています。さらに、お客様が主権に関する事項について十分な情報に基づいて判断できるよう、補足的な説明やリソース ( CLOUD Act に関するブログ など) も提供しています。こうした取り組みは 責任ある AI へのコミットメントにも及んでおり、お客様が AWS のサービスを使用して、安心して AI アプリケーションを責任ある形で構築、運用できるよう支援しています。ISO/IEC 42001 は、組織が AI システムの責任ある開発と使用を推進するための要件と管理策を定めた国際的なマネジメントシステム規格です。AWS は、 主要クラウドサービスプロバイダーとして初めて、認定を受けた認証機関から AI サービスを対象とした ISO/IEC 42001 認証を取得 しました。対象には Amazon Bedrock、 Amazon Q Business 、 Amazon Textract 、 Amazon Transcribe が含まれます。2025 年 11 月には、ISO 42001:2023 の初回サーベイランス審査を 指摘事項なし で完了し、責任ある AI の実践に対する AWS の継続的なコミットメントを改めて示しました。 革新的なテクノロジーには、安全で信頼できる基盤が欠かせません。AWS は 140 を超えるセキュリティ標準とコンプライアンス認証をサポートしており、お客様やパートナーはこれらを継承することで、各地域の法律や規制への準拠に役立てることができます。AWS は 20 年にわたり、規制当局やサイバーセキュリティ当局と緊密に連携し、提供するサービスを国家の優先事項に合わせるとともに、ソリューションがイノベーションとコントロールの両方を支えられるよう取り組んできました。また、進歩を妨げることなく新たな動向に対応できるフレームワークづくりにも積極的に貢献しています。 お客様の主権目標の達成に向けた継続的なコミットメント AWS は、お客様がデータに対して持っているのと同じコントロールと選択肢を、AI システムに対しても提供することに取り組んでいます。AWS クラウドの機能、パフォーマンス、イノベーション、セキュリティ、スケールを維持しながら、お客様が AI の変革力を活用できるよう支援します。クラウドと AI の進化に合わせて、AWS は今後も、利用可能な最も高度な主権コントロールと機能を提供し続けます。 Stéphane Israël Stéphane は、AWS European Sovereign Cloud のリーダー兼 Managing Director です。AWS European Sovereign Cloud のインフラストラクチャ、テクノロジー、サービスを含む管理と運用に加え、AWS におけるより広範なデジタル主権の取り組みを担当しています。AWS に入社する前は Arianespace の CEO を務め、ジェイムズ・ウェッブ宇宙望遠鏡の打ち上げをはじめ、成功を収めた数多くの宇宙ミッションを統括しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。