re:Invent 2025: SamsungがDynamoDBで1.2PBを最適化しゼロダウンタイムで100TBに削減した事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - How Samsung optimized 1.2 PB on Amazon DynamoDB with zero downtime (DAT323)
この動画では、Samsung CloudのPrincipal Software EngineerであるManseok Kimが、1.2ペタバイトのDynamoDBテーブルを最適化した事例を紹介しています。月間10億台以上のデバイスから毎日500億件のリクエストを処理するSamsung Cloudでは、Samsung Internetのタブデータが急増し、ストレージコストが月間数十万ドルに達していました。データ分析の結果、テーブルの90%がtombstoneレコードで、その60%が6ヶ月以上経過していることが判明しました。削除履歴の伝播時間を調査したところ、99.9%のデバイスが1週間以内に完了していたため、保持期間を6ヶ月から1週間に短縮することを決定しました。ユーザー単位の移行戦略とMigration Status Table、flow regulatorを用いた制御された実行により、わずか1週間で移行を完了し、テーブルサイズを100テラバイトに削減、顧客からの苦情ゼロを達成しました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
1.2ペタバイトの課題：Samsung Cloudが直面したストレージコスト問題の発見
皆さん、こんにちは。AWS re:Inventにお越しいただきありがとうございます。私はSamsung CloudのPrincipal Software Engineer、Manseok Kimと申します。本日は、私たちのチームがプラットフォーム上で直面した大規模な技術的課題をどのように解決したかについて、素晴らしいストーリーをお話しさせていただきます。
まず、Samsung Cloudについて簡単にご紹介させてください。私たちのプラットフォームは、世界中の数十億人のGalaxyユーザーにとって重要な存在です。 私たちは、Samsung Notes、Samsung Health、Samsung Internetといった人気のSamsungアプリに対して、Sync、Backup、Restoreなどのコアクラウドサービスを提供しています。私たちのミッションはシンプルです。すべてのデータがすべてのデバイス間で一貫性を保ち、利用可能であることを保証し、スムーズな体験を提供することです。
Samsung Cloudは非常に大規模に運用されています。月間10億台以上のアクティブデバイスを処理しています。 これにより、毎日500億件のリクエストが発生しています。この膨大なトラフィックに対応するため、私たちはAmazon DynamoDBをプライマリデータベースとして選択しました。
私たちはAmazon DynamoDBを使用して、Samsung Internetなどのアプリケーションのコア同期データを保存しています。この特定のデータセットにズームインしてみましょう。 開いているタブのデータがあります。タブ情報は、ユーザーがタブを開いたり、閉じたり、タブ間を移動したりするたびに、常に生成され更新されます。サービスが成長するにつれて、タブデータの継続的な作成と更新により、データ量が急速に増加していきました。
テーブルサイズはどんどん大きくなり続けました。 そして2025年初頭までに、1.2ペタバイトに達していました。この巨大なテーブルは、毎月数十万ドルのAWSストレージコストを消費していました。 私たちのミッションは2つありました。ストレージコストを50%削減すること。そして2つ目は、最適化への投資全体を3ヶ月以内に回収することでした。これが私たちの重要なROI目標でした。1.2ペタバイトのテーブルでこれを達成することは、非常に大きな課題でした。
何兆ものレコードがある中で、データを分析するだけでも途方もない作業でした。すべてのデータを分析することはできなかったので、レコードのサンプルを取って、その特性を理解することにしました。 結果は驚くべきものでした。データテーブルの90%が、タブの削除レコード、つまりtombstoneで構成されていたのです。ユーザーがタブを閉じると、システムはそのデータをすぐには削除しません。代わりに、ステータスを削除済みに変更して、6ヶ月間テーブルに保持します。このメカニズムは、非アクティブなデバイスが再接続したときに、すべての同期履歴を受信できるようにするために重要なんです。
tombstoneメカニズム自体が問題だったわけではありません。そこで、さらに深く掘り下げてみたところ、tombstoneの60%が6ヶ月以上経過していることがわかりました。 初期の頃は、迅速な開発と安定性に注力していたため、ライフサイクル管理のような長期的なタスクは後回しにされていました。これが私たちの技術的負債だったんです。この分析に基づいて、6ヶ月以上経過したすべてのデータを削除することで、テーブルを最適化することにしました。
私たちは2つの主要な戦略を検討しました。 戦略Aは、既存のテーブルをクリーンアップして、データを直接見つけて削除する方法です。戦略Bは、新しいテーブルを作成して、保持したいデータのみを移行する方法です。直接スキャンして削除するアプローチでは、何兆ものレコードをスキャンする必要があり、膨大なRCUとWCUを消費します。このプロセスは6ヶ月以上かかると予測されました。総費用は数ヶ月分のストレージ料金に相当するものでした。 この膨大な支出では、3ヶ月という目標を達成することは不可能だったので、すぐに戦略Aは除外しました。
必要なデータのみを移行することで、処理するデータセットがはるかに小さくなります。処理するデータ量を元の40%に削減しました。 総データ量の40%を移行するのは改善ではありましたが、RCUとWCUは依然として数十万ドルに達していました。もっと良い方法があるはずだとわかっていました。そこで、技術的な詳細から一歩引いて、サービスの本質的な目的に再び焦点を当てました。
データ伝播分析から生まれた解決策：履歴ウィンドウ短縮とユーザー単位移行アーキテクチャの設計
先ほど述べたように、私たちのシステムは、削除レコードが送信された後、6ヶ月間保存しています。 しかし、この基本的な前提に疑問を持ち始めました。自分たちに問いかけたんです。この6ヶ月の保持期間は本当に必要なのか、と。 削除レコードの目的は、シグナルがユーザーのすべてのデバイスに伝播されれば達成されます。合理的な基準を見つけるために、 削除レコードがユーザーのすべてのデバイスに完全に伝播されるまでにかかる時間を測定しました。調査の結果は予想外でした。 タブの削除履歴の伝播に1週間以上必要とするデバイスは0.1%未満でした。 残りの99.9%は1週間以内に伝播が完了し、99%のデバイスは3 日以内に削除履歴を受信していました。
先ほど確認したデータに基づいて、私たちは重要な決断を迫られました。従来の履歴ウィンドウを6ヶ月から1週間に短縮すべきでしょうか?メリットは大きなものでした。1週間に移行することで、移行すべきデータ量は96%削減され、24週間分からわずか1週間分になります。これはストレージと処理コストの大幅な削減を意味していました。しかし、トレードオフとして、特定の技術的制約が伴いました。約0.1%のデバイスが差分同期のみを実行する機能を失うことになります。これらのユーザーは増分変更だけでなく、完全なデータセットを取得せざるを得なくなります。
長期間非アクティブなデバイスによって引き起こされる問題は、システムレベルのリスクを生み出します。Samsung Cloudの規模では、0.1%でも数百万台のデバイスになります。これらのデバイスが同時にフル同期を行わなければならない場合、大量のトラフィック急増がシステムに過負荷をかけ、スロットリングやダウンタイムを引き起こす可能性があります。この技術的な障壁に直面したとき、私たちは解決策が単に技術的なものではないことを理解しました。そこで、私たちのコアサービスドメインを深く掘り下げる必要がありました。Samsung Internetチームと協力することで、重要な運用上の動作を学びました。それが99タブ制限です。このポリシーは、どのデバイスも99個を超えるタブを開くことができないことを意味します。これが私たちのブレークスルーでした。トラフィックストームが危険なのは、負荷が無制限で予測不可能な場合のみです。99タブ制限はリスクを定量化しました。これは、フル同期のための最大データ量が小さく予測可能なサイズに保たれることを意味し、私たちの最大の懸念を無効化しました。
データ伝播のインサイトと99タブポリシーを手に入れて、私たちの進むべき道は明確になりました。私たちは正式に、従来の履歴ウィンドウを1週間に変更することを決定しました。この決定により、移行すべき総データ量は以前の計画の40%から、わずか10%にまで減少しました。数兆件のレコードから数千億件への大幅な削減です。最終的なデータ戦略が決まり、私たちのミッションは明確でした。1.2ペタバイトのテーブルから基準を満たす10%のデータを見つけ、新しいテーブルに移行し、コスト効率を最大化するために迅速に完了させることです。しかし、Samsung Cloudチームにとって、ミッション自体よりもさらに重要なものがあります。それは私たちのユーザーです。
そこで、何かを構築する前に、移行プロセスにおけるすべての決定を導く2つの原則を確立しました。第一の原則はシンプルです。ユーザー体験を最優先にすること。私たちのプロジェクトは、ユーザーにとってネガティブな体験を引き起こしてはなりません。第二の原則は制御された実行です。すべてのステップは予測可能で、観察可能で、完全に制御可能でなければなりません。これらは単なるスローガンではありませんでした。移行アーキテクチャのすべての要素における絶対的な基準でした。
私たちの目標は、システムレベルのゼロダウンタイムではなく、ユーザーが体験するゼロダウンタイムでした。これを達成するために、私たちはユーザー単位の移行戦略を採用しました。移行されていないユーザーは古いテーブルを使い続けます。ユーザーデータの移行が完了すると、そのユーザーのすべてのリクエストは新しいテーブルにリダイレクトされます。デバイスのデータが転送されている間、デバイスはロック状態に置かれます。このロック中に到着したリクエストは、移行が完了してデバイスが切り替わるまで一時的に拒否されます。ユーザーがこの一時的なエラーを受け取った場合、クライアントは数秒以内に自動的にリトライし、真にシームレスな体験を保証します。
デバイスがリクエストを送信すると、 sync serviceはどのテーブルを使用すべきかを知る必要があります。このルーティングの問題を解決するために、私たちはcontrol tower、つまりMigration Status Table（MST）を導入しました。 Migration Status Tableは各ユーザーのマイグレーションステータスを記録します。すべてのsyncリクエストに対して、sync serviceはまずMSTにクエリを実行し、ユーザーのマイグレーションステータスを判断して、適切なテーブルにアクセスします。
このアーキテクチャを見ていただくと、 皆さんは重要な問題を正しく特定されたと思います。次に説明するflow regulatorは、新しいテーブルを保護します。これは書き込み負荷を着実かつスムーズに増加させますが、Migration Status Tableを保護するものは何もありませんでした。これが私たちの単一障害点だったのです。この単一障害点の問題を解決するために、私たちはAWSのconstant work principleを適用しました。MSTの前にAmazon ElastiCacheインスタンスを配置し、 sync serviceがまずキャッシュを呼び出すようにしました。Migration Status Tableは pre-warmされているため、基盤となるDynamoDBテーブルがトラフィックを即座に処理できる状態になっています。また、provisioned capacityの最小値をチューニングして、 キャッシュの障害時でもテーブルが常に完全なリクエストを受け入れることを保証しました。これがAWSの言うconstant work principleです。
どのようなマイグレーションでも目標はスピードですが、スピードだけに焦点を当てると安定性とコントロールが損なわれます。これが私たちがcontrolled execution principleを採用した理由です。私たちは水門を開け放つことはしませんでした。フローを管理したのです。同時にマイグレーションするユーザーの最大数を制限しました。これは下流の洪水を防ぐためにダムを制御するのと同じようなものです。このアプローチにより、4つの重要な利点が得られました。古いテーブルをI/Oの問題から保護し、新しいテーブルが予測可能にスケールすることを保証します。 インフラストラクチャの安定性を確保し、データフローを細く一定に保つことで可観測性を確保します。
この制御されたスピードを実装するために、私たちはflow regulatorを作成しました。 これはjob feederとworking queueの組み合わせです。job feederはユーザーIDをworking queueに供給します。migration workerは working queueからジョブを取り出し、データマイグレーションを実行します。キューはマイグレーション中のユーザーの最大数を厳密に制限します。キューが満杯になると、 バックプレッシャーメカニズムが自動的にjob feederを一時停止します。この自己調整システムにより、スループットが計画されたレベルで正確に維持されます。
私たちの最後の技術的なハードルは、1.2ペタバイトのテーブルの中から必要な10%のデータをどのように見つけるかということでした。 もし必要かどうかを判断するためだけにすべてのアイテムを読み取らなければならなかったら、膨大なRCUコストが発生し、プロジェクトのタイムラインが即座に伸びてしまいます。ブレークスルーは新しい技術からではなく、既存のsync serviceの基本的なメカニズム、つまりタイムスタンプベースの同期を見ることから生まれました。私たちのsyncメカニズムは、タイムスタンプ、つまり各変更の正確な時刻を追跡することで機能します。これにより、デバイスは見逃した変更のみをダウンロードできます。 私たちのテーブルには、これをサポートするためにタイムスタンプをキーとするLocal Secondary Indexが含まれています。重要なのは、このLSIにはstatusがprojection attributeとして含まれているということです。これがキーなのです。
これにより、メインテーブルに触れることなく、適切なweight indexを読み取ることで、古いデータの90%をフィルタリングすることができます。つまり、重いテーブルスキャンの代わりに、フィルタリングされたクエリを実行し、マイグレーションワーカーを初回同期をリクエストする新しいデバイスとして扱うわけです。
データ抽出を2つのステップで行う方法をご紹介します。まず、LSIを使用して移行対象のデータを見つけます。単一のLSIクエリを実行して、2つのターゲットグループを取得します。1つ目はアクティブなタブ、2つ目は先週のtombstoneレコードです。次に、tab IDを使って、最初のステップから実際のデータを取得します。各アイテムを1つずつフェッチする代わりに、DynamoDBのbatch get item APIを使用します。LSIクエリはコスト効率が良く高速で、フルテーブルスキャンを回避できます。batch APIはすべてのデータを効率的に収集します。この組み合わせにより、Read Capacity Unitsを劇的に削減できました。
顧客苦情ゼロで達成した1週間の移行：データドリブンとユーザー中心主義がもたらした成功
マイグレーションは単なるデータ移行以上のものでした。これは私たちの哲学の究極のテストだったのです。誇りを持って言えるのは、私たちの原則が機能したということです。成功を3つの主要な指標で分析していきます。技術的指標、財務的指標、そして最も重要な顧客指標です。マイグレーション全体がわずか1週間で完了しました。制御された実行の原則のおかげで、同時にマイグレーションを行うユーザー数は数万人で安定していました。古いテーブルのWCUは着実に減少し、トラフィックの段階的な減少を示しています。このグラフは、新しいテーブルのRCUとWCUがスムーズかつ着実に増加し、目立ったスパイクがないことを示しています。これにより、制御された実行アプローチが負荷を適切に管理できたことが確認できます。
財務面では、インパクトは即座かつ巨大でした。テーブルサイズを1.2ペタバイトからわずか100テラバイトに削減し、ストレージコストを大幅に削減しました。私たちの戦略のおかげで、マイグレーションコストは最小限に抑えられました。総費用は1ヶ月分の節約額未満でした。次のAWSの請求書が届く前に、投資全額を回収できました。当初の目標の150%を達成しました。
しかし、技術的および財務的な指標を超えて、私たちにとって最も重要な指標があります。それは顧客指標です。マイグレーション全体を通じて、マイグレーションに関連する顧客からの問い合わせやバグレポートはゼロでした。これが私たちのチームが最も誇りに思っている数字です。これこそが、ユーザーエクスペリエンスの原則がスローガンではなかったことの究極の証明なのです。
私たちはこれらの結果を誇りに思っており、それを可能にした3つの鍵をお話ししたいと思います。最初の教訓は、データドリブンな意思決定の力です。最初に問題を明らかにしたのはデータサンプリングでした。テーブルの60%が古いTombstoneだったのです。そして、ソリューションに対する確信を与えてくれたのもデータ分析でした。ログを分析した結果、99.9%のシグナルが1週間以内に伝播していることがわかり、保持履歴ウィンドウを6ヶ月から1週間に変更するという最も重要な決定を下しました。データが当て推量を排除してくれたのです。私たちはこのデータファーストのアプローチをすべての重要な局面で適用しました。
しかし、私たちのチームはデータだけでは十分ではないことも学びました。データは数字を与えてくれますが、意味を与えてくれるのはドメイン分析だけです。これがなければ、同じデータを見ていても間違った選択をしてしまう可能性があります。
そこで、2つ目の教訓は深いドメイン理解です。最初の洞察は、Tombstone Recordsの真の目的について根本的なサブクエスチョンを問いかけることから生まれました。これが、そもそも6ヶ月ルールに疑問を投げかけることを可能にした鍵でした。2つ目の洞察は、99 tab limitと呼ばれるドメインポリシーを発見しただけではありませんでした。そのポリシーが何を意味し、どのようにデータを自然に制約し続けているかを理解したことでした。これにより、最大の技術的リスクが即座に無効化されました。真のブレークスルーは、どのように最適化するかからは生まれません。なぜかを問うことから生まれるのです。
最後の、そして最も重要な教訓は、ユーザー中心のマインドセットです。これは私たちが下したすべての決定を導いた原則です。ユーザーエクスペリエンスを損なうのであれば、技術的・財務的な成功は何の意味も持ちません。このマインドセットがあったからこそ、私たちは簡単な道ではなく、最も安全な道を選んだのです。そうすることで、私たちのチームは真の成功の尺度とは何かを学びました。それは、移行したペタバイト数でも節約したドル数でもありません。ユーザーとの信頼を守ったことです。
1.2ペタバイトの移行を顧客からの苦情ゼロで実現しました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion