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/

はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富( @yannKazu1 )です。 VPC Flow Logs に、 VPC 内のサーバーがインターネット上の IP の 6379 番ポートと通信している 行が記録されているのを見つけました。6379 は Redis のポートなので、字面だけ読むと「インターネット側に Redis がいて、そこに繋ぎに行っているのか？」と読めてしまいます。 この記事では、このログをパケットのヘッダーとしてどう読むか、そしてそこから立てた仮説を Flow Logs だけでどう裏付けたかを書いていきます。 きっかけ VPC Flow Logs を眺めていたときのことです。 Redis のポートである 6379 に絞ってフィルタをかけたら、見慣れないパブリック IP が出てきました。 本記事の IP アドレスについて 実際の値は伏せ、すべてダミーに差し替えています。グローバル IP はドキュメント用に予約されている RFC 5737 のレンジ（ 192.0.2.0/24 、 198.51.100.0/24 、 203.0.113.0/24 ）、CGNAT 内部のアドレスは RFC 6598 の 100.64.0.0/10 、VPC 内と宅内のアドレスは RFC 1918 のプライベートレンジから適当な値を置いています。ENI ID と ISP 名も伏せました。 srcaddr dstaddr dstport action 10.0.1.100 203.0.113.45 6379 ACCEPT 10.0.1.100 は VPC 内のプライベート IP、 203.0.113.45 はインターネット上のパブリック IP です。つまりこの行をそのまま読むと、 VPC 内から外部の IP の 6379 番ポートへ通信している ことになります。 6379 は Redis のポートです。となると「知らないうちに外部の Redis に繋ぎに行っているのか？」「何かに乗っ取られて外のキャッシュにデータを投げているのか？」という絵が浮かんでくるログです。少なくとも、VPC 内で使っている Redis は VPC に閉じているはずなので、この行の存在自体が説明できない。思わず手が止まる 1 行だと思います。 パケットレベルで考えれば、当たり前だった ここで思い出すべきは、 Flow Logs がどのレイヤーの記録なのか です。 Flow Logs に残るのは L3/L4、つまり IP ヘッダーと TCP ヘッダーの中身だけです。入っているのは「送信元 IP / 送信元ポート / 宛先 IP / 宛先ポート」の 4 つ組といったメタ情報だけです。 この目で読み直すと、結論は簡単です。 この ENI が ALB のものだと仮定すると、クライアントの送信元ポートが 6379 なら、戻りのパケットはその 6379 宛になります （ALB であることは後述のログで確認しています）。改めて送信元・宛先のポートを両方一緒に出力してみると、内部側は 443 番でした。TCP は行きと戻りで送信元と宛先が入れ替わるだけなので、この行は 203.0.113.45:6379 → 10.0.1.100:443 の戻りと考えれば一目瞭然です。6379 を名乗っているのはクライアント側で、 6379 は宛先ポートでなく送信元ポート 。接続ごとに振られる使い捨ての番号で、Redis とは関係ありません。 しかもクライアントの送信元ポートは、端末から ALB に届くまでに何度も NAT で付け替えられます。そのどこかで 6379 が選ばれるのは、 十分にあり得るし、何も不思議ではないシナリオ です。 この流れを整理しておきます。 端末から ALB の ENI までに起きていること 一般ユーザーがブラウザでサイトを開いてから、そのパケットが ALB の ENI に届くまで、いくつもの機器を経由します。そしてそのたびにヘッダーが書き換えられます。 flowchart TD A["端末（スマホ・PC）<br/>src 192.168.1.5:51000<br/>dst 192.0.2.10:443"] B["宅内ルーター（NAT）<br/>src 100.64.12.7:40277<br/>dst 192.0.2.10:443"] C["ISP の CGNAT<br/>src 203.0.113.45:6379<br/>dst 192.0.2.10:443"] D["Internet Gateway<br/>src 203.0.113.45:6379<br/>dst 10.0.1.100:443"] E["ALB の ENI<br/>ここで Flow Logs に記録される"] A -->|"送信元を書き換え"| B B -->|"送信元を書き換え → 6379 が誕生"| C C -->|"宛先を書き換え"| D D --> E 各段階を順に見ていきます。 1. 端末 ブラウザが接続を開くとき、OS が送信元ポートを 1 つ払い出します。これは「この通信を識別するための整理番号」であって、サービスの種類とは無関係です。Linux なら 32768〜60999、Windows なら 49152〜65535 から選ばれます（設定で変更可能）。 宛先は DNS で引いた ALB のパブリック IP と 443 番です。 2. 宅内ルーター 家庭内のプライベート IP のままでは外に出られないので、ルーターが NAT で送信元を書き換えます。このとき送信元ポートも付け替えられます。 3. ISP の CGNAT ← ここで 6379 が生まれる IPv4 アドレスが枯渇しているため、ISP は複数の利用者で 1 つのグローバル IP を共有する構成を取ります。CGNAT と呼ばれる仕組みです。 同じグローバル IP を共有するので、「誰の通信か」はグローバル IP とポート番号の組み合わせで見分けることになり、ここでもう一度ポートが付け替えられます。しかも多数の利用者分をさばくため、 well-known ポート以外の広い範囲を、ポートのプールとして使う実装があります 。OS がエフェメラルポートとして使う 49152〜65535 の範囲に収まらず、登録済みポート帯の番号が払い出されることもあります。 そして今回、たまたま 6379 が払い出されました。この瞬間から、この通信はずっと「6379 番」を名乗って進むことになります。 4. Internet Gateway VPC の入口です。ここでは宛先側が書き換えられます。端末は ALB のパブリック IP 宛に送っていますが、VPC 内部ではプライベート IP に変換されます。 5. ALB の ENI 到着。この時点のヘッダーがそのまま Flow Logs の 1 行になります。そして ALB が返事を返すと、送信元と宛先が反転したもう 1 行が記録されます。 sequenceDiagram participant C as クライアント（CGNAT 通過後）<br/>203.0.113.45 participant E as ALB の ENI<br/>10.0.1.100 C->>E: 203.0.113.45:6379 → 10.0.1.100:443 Note over E: Flow Logs 1 行目（インバウンド） E->>C: 10.0.1.100:443 → 203.0.113.45:6379 Note over E: Flow Logs 2 行目（アウトバウンド） 最初に目に入ったのは、この 2 行目でした。 行きのパケットの送信元ポートが、そのまま戻りのパケットの宛先ポートになる。TCP としてはごく当たり前の挙動ですが、これをポート番号だけで「6379 宛の通信」と読んでしまうと、一気に怪しい通信に見えてきます。 ログで裏付ける とはいえ、ヘッダーの読み方だけでは「そう解釈できる」までです。ログで裏付けを取りました。確認したのは 2 点です。 対向のインバウンドフロー（ 外部:6379 → 内部:443 ）が同じ ENI・同じ時間帯に存在するか その ENI が ALB のものかどうか 対向フローは全件見つかった 該当した 3 件すべてに、ペアとなるインバウンドが存在しました。 方向 送信元 宛先 パケット バイト → リクエスト 203.0.113.45:6379 10.0.1.100:443 31 10,164 ← レスポンス 10.0.1.100:443 203.0.113.45:6379 39 18,401 → リクエスト 198.51.100.72:6379 10.0.3.200:443 4 285 ← レスポンス 10.0.3.200:443 198.51.100.72:6379 7 405 → リクエスト 198.51.100.72:6379 10.0.3.200:443 14 4,027 ← レスポンス 10.0.3.200:443 198.51.100.72:6379 16 7,670 4 つ組がきれいに反転していて、1 対 1 で対応しています。完全な TCP セッションのペアです。 通信は外から始まっている 。VPC 内部から外の 6379 に繋ぎに行ったわけではない、という有力な裏付けになりました。 ENI は ALB のものだった 該当した 2 つの ENI に流れている他のトラフィックを見てみると、すべてが 外部IP:エフェメラルポート → 10.0.x.x:443 の形でした。送信元は国内の大手 ISP ばかり。 要するに、これは ALB の ENI です。一般ユーザーが HTTPS でサイトを見に来ている入口そのものでした。 送信元 IP を引いてみる 念のため GeoIP で送信元を確認しました。 IP 種別 203.0.113.45 国内コンシューマー ISP（モバイル回線） 198.51.100.72 国内コンシューマー ISP（固定回線） どちらも一般家庭・モバイル向けの ISP です。攻撃の出所になりやすいデータセンターや VPS 事業者の IP ではありません。 ただし、WHOIS や GeoIP で分かるのは「どの ISP の、コンシューマー向けらしいレンジか」までです。 その IP が CGNAT の出口かどうかは、外から見て断定できません 。ここで言えるのは「一般利用者の回線から来ていると考えて矛盾がない」という裏付けです。 バイト数の傾向も HTTPS らしく、レスポンスのほうがリクエストより大きい（10,164 → 18,401）。Web ページを返しているなら自然な形です。 結論 何も起きていませんでした。 ISP の CGNAT が送信元ポートを付け替える際に、たまたま 6379 を割り当てただけ。それ以降その通信はずっと「6379 番」を名乗って進み、ALB がそこへ返事を返した、というだけの話でした。 そしてこれは「たまたま今日起きた珍事」ではなく、 仕組み上、アクセスがある限り起こり続ける現象 です。6379 に限った話でもなく、3306（MySQL）でも 5432（PostgreSQL）でも同じことが起きます。 この仕組みを知らないとハマる落とし穴 今回は調査で済みましたが、理解していないと実害が出るケースもあります。 NACL の outbound DENY で本番障害になる これが一番怖いパターンです。セキュリティ強化のつもりで NACL に outbound: 6379 DENY を入れていると、 たまたま送信元ポート 6379 を引いたユーザーだけサイトが見られない という障害になります。 しかも症状が最悪です。再現しない。特定の人だけ。時間が経つと（NAT のポートが変わると）直る。問い合わせを受けても「こちらでは再現しません」という回答になりやすい類の事象です。 セキュリティグループはステートフルなので戻りが自動で通り、この問題は起きません。ハマるのはステートレスな NACL のほうです。同じ理由で、ステートレスなファイアウォールや、ポートベースの ACL も同様に要注意です。 Flow Logs の限界を知らないと結論を出しすぎる Flow Logs は ENI 単位の記録なので、見えるのは「ENI に届いた時点のヘッダー」だけです。 flowchart LR A[端末] --> B[宅内ルーター] --> C[ISP の CGNAT] --> D[Internet Gateway] D --> E subgraph OBS["VPC Flow Logs が観測できる範囲"] E["ALB の ENI"] end 見える — 送信元/宛先の IP とポート、プロトコル、パケット数、バイト数、ACCEPT/REJECT、TCP フラグ（ tcp-flags 。SYN / SYN-ACK から接続を開始した向きも分かる） 見えない — 端末や宅内ルーターの実 IP（NAT で消えている）、ALB のパブリック IP（IGW が書き換えた後しか届かない）、通信の中身、パケット 1 つごとの TCP フラグ（ tcp-flags は集約単位のビットマスクなので、ACK や PSH は含まれない） 先ほど 5 段階で経路を追いましたが、Flow Logs に残るのは最後の 1 段階だけです。手前で何度 NAT されたかは記録に一切現れません。 なので今回証明できたのは「この通信は ALB 宛の正常な HTTPS である」ところまでです。その中身が正当かを問うなら、 見に行くべきログのレイヤーが変わります 。どのパスにリクエストが来て何を返したのかならアクセスログ、そのリクエストがシステムの中で何をしたのかならアプリケーションのログ。知りたいことがどのレイヤーの話なのかで、見るログを選ぶ必要があります。今回の論点は L3/L4 の話だったので、Flow Logs だけで決着がつきました。 おわりに 結果は空振りでしたが、ヘッダーの向きでついた見当を、対向フロー・ENI・送信元 IP で裏付けて「正常です」と言い切れたのは良かったと思います。 そしてその見当がついたのは、端末 → 宅内ルーター → CGNAT → Internet Gateway → ENI という流れと、各段で何が書き換わるのかが頭に入っていたからです。 どのレイヤーのログを見れば決着がつくのかを選べるかどうかは、経路の全体像を持っているかで決まる と実感しました。

Amazon プライムデー 2026 はプライム会員限定で、2026 年 6 月 23 日から 26 日まで開催され、35 を超えるカテゴリーで数百万件のお得な情報が提供されました。 AWS がどのようにプライムデー ( 2016年 、 2017年 、 2019年 、 2020年 、 2021年 、 2022年 、 2023年 、 2024年 、 2025年 ) を支えてきたかをご紹介する毎年恒例の取り組みの一環として、お客様の素晴らしいショッピング体験を実現した AWS のサービスと、トップクラスの実績を記録したメトリクスをご紹介します。 数値で見るプライムデー 2026 例年通り、プライムデーは AWS によって支えられています。最も興味深いメトリクスと、驚異的なメトリクスをいくつか紹介します。 Amazon Elastic Compute Cloud (Amazon EC2) と AWS Graviton – Amazon プライムデー 2026 の開催中、AWS Graviton は Amazon.com が使用する Amazon EC2 コンピューティングの最大 49% を担いました。 Amazon Elastic Block Store (Amazon EBS) – プライムデー 2026 の開催中、当社の高性能ブロックストレージサービスである Amazon EBS の I/O オペレーションはピーク時に 24.8 兆回に達し、1 日あたりのデータ量は 1 エクサバイトを超えました。 AWS Lambda – AWS Lambda は、プライムデー 2026 の開催中、1 日あたり 2.3 兆件を超える呼び出しを処理しました。 Amazon Elastic Container Service (ECS) および Fargate – プライムデー 2026 の開催中、Amazon ECS は AWS Fargate 上で 1 日平均 1 億 5,830 万件のタスクを起動しました。これは、前年のプライムデーにおける平均から 47.7% 増加した数値です。 Amazon CloudFront – Amazon CloudFront は、プライムデー 2026 のグローバル開催中 2.1 兆件を超える HTTP リクエストを処理しました。これは、リクエスト総数が 2025 年のプライムデーと比較して 5% 増加した数です。 Amazon DynamoDB – フルマネージドのサーバーレス分散型 NoSQL データベースである Amazon DynamoDB は、Alexa、Amazon.com のサイト、すべての Amazon フルフィルメントセンターなど、トラフィック量の多い複数の Amazon のプロパティとシステムを支えています。2026 年 6 月 23 日から 6 月 26 日まで開催されたプライムデー 2026 の期間中、DynamoDB は 59 兆件を超えるリクエストを処理しました。DynamoDB は、1 桁ミリ秒のレスポンスを提供し、ピーク時には 1 秒あたり 1 億 9,200 万件のリクエストを処理しながら、高可用性を維持しました。 Amazon Aurora – プライムデーでは、PostgreSQL、MySQL、DSQL 向けにグローバル規模で高いパフォーマンスと可用性を実現するために構築されたリレーショナルデータベース管理システム (RDBMS) である Amazon Aurora が、数千億件のトランザクションを処理し、5,491 テラバイトのデータを格納し、1,194 テラバイトのデータを転送しました。 Amazon ElastiCache – プライムデーの開催中、Amazon ElastiCache が、ピーク時には 1 日あたり 2,300 兆件を超えるリクエスト、1 分間に 2.1 兆件を超えるリクエストを処理しました。 Amazon Kinesis Data Streams – フルマネージドサーバーレスデータストリーミングサービスである Amazon Kinesis Data Streams は、プライムデー 2026 の開催中に、ピーク時には 1 秒あたり 9 億 8,800 万件のレコードを処理しました。 Amazon Simple Notification Service (SNS) – アプリケーション間およびアプリケーション対人通信用のフルマネージドパブ/サブメッセージングサービスである Amazon SNS は、プライムデー 2026 の開催中、1 日あたり 5 兆通のメッセージを配信しました。 Amazon Simple Queue Service (Amazon SQS) – マイクロサービス、分散システム、サーバーレスアプリケーション向けのフルマネージドメッセージキューイングサービスのである Amazon SQS は、プライムデー 2026 の開催中、ピーク時に 1 秒あたり 2 億 1,300 万件のメッセージを受信しました。 AWS CloudTrail – AWS CloudTrail は、ガバナンス、コンプライアンス、およびオペレーション監査のために、1 日あたり数十億件の API アクティビティイベントを処理しています。プライムデー 2026 の開催中、その件数はわずか 4 日間で 3.6 兆件に急増し、プライムデー 2025 と比較して 44% 増加しました。 AWS CloudWatch – Amazon CloudWatch は、プライムデー 2026 の開催中、1 日あたり 2.15 千兆件を超えるメトリクス観測データを処理しました。 Amazon GuardDuty – プライムデー 2026 の開催中に、Amazon GuardDuty は、1 時間あたり平均 14.08 兆件のログイベントをモニタリングしました。これは、昨年のプライムデーと比較すると 59% の増加です。 AWS Fault Injection Service (FIS) – 当社は、プライムデーにおいて Amazon.com が高可用性を維持できるようにするため、44,000 件を超える AWS FIS 実験を実施しました。これは、2025 年に実施した数の 6 倍超です。 スケールするための準備 同様のビジネスクリティカルなイベント、製品のリリース、移行の準備をしている場合は、 AWS Countdown Premium を活用することをお勧めします。小売業界の繁忙期から主要なスポーツイベント、選挙、医療保険の加入期間に至るまで、最も重要な時期に完璧な体験を提供できるよう支援します。当社のエキスパートが、セキュリティとパフォーマンスを維持しながら大量のトラフィックの急増に対処できるよう、インフラストラクチャの管理を支援します。お客様のチームと連携し、インフラストラクチャの拡張、需要の急増時のコストの最適化、セキュリティ対策の強化、リアルタイムの需要の監視を行います。詳細については、 ビジネスクリティカルイベントに関する AWS Countdown Premium をご覧ください。 2027 年も、どのような記録が破られるか本当に楽しみです! — Channy 原文は こちら です。