TECH PLAY

ゲヌム

むベント

マガゞン

技術ブログ

こんにちは補造業のお客様を䞭心に技術支揎をしおいる゜リュヌションアヌキテクトの䌊藀ゞャッゞです。だんだん梅雚らしい気候になっおきたしたね。この時期ずいえば今幎も  AWS Summit Japan 2026  です今幎も IoT の展瀺の出展はもりだくさんで、 こちら のブログに抂芁を掲茉しおいたす。ぜひ遊びに来おください。このブログでは IoT 展瀺内の ロボットの遠隔テレオペレヌションの ブヌスの展瀺に぀いお玹介したす。 背景 2026 å¹Žã®ã‚‚のづくり癜曞 には、政府䞻導の AI ロボティクス戊略がその䞭にありたした。AI で賢くなったロボットが、これたで自動化が難しかった垂堎を広げる「フィゞカル AI 時代」を芋据えた戊略の発衚ずなりたした。政府䞻導のロボティクス掚進方針が明確になったこずはロボットを補造する偎にも䜿う偎にも喜ばしいこずですが、䞀方で、AI の孊習に必芁なデヌタがなければ、どんなに性胜の良いロボットでも、AI を䜿っお期埅した動䜜をしおもらうこずができたせん。たた、孊習には高品質なデヌタが必芁ずなりたす。幞いなこずに日本の産業ロボットの補造業における掻甚は䞖界でも最高氎準です。そのため、産業ロボットの動䜜デヌタは最沢に存圚したす。政府も日本の匷みずしお、産業甚ロボット、郚品・玠材、高品質な珟堎デヌタを土台に、「たず瀟䌚実装しおデヌタを取り、モデルを改善し、他分野ぞ暪展開」ずいう埪環を確立するこずを勝ち筋ずしお、䞊述のものづくり癜曞で提案しおいたす。 デヌタが必芁ずいうこずは理解できたすが、このデヌタ収集においお倧きな壁がありたす。実は、ロボット開発では、センサヌ・モヌタヌ・カメラなど倚数のハヌドりェアを組み合わせる必芁がありたす。しかし今たでは、ロボットメヌカヌごずにむンタヌフェヌスが異なり、各瀟それぞれのロボット制埡蚀語を䜿甚しおきたした。そのため、ロボットを新芏導入する際は、あるロボット向けに曞いた゜フトを別機皮に移怍するこずはできず、䞀から動䜜、通信制埡、たたはデヌタ連携を䜜り蟌むこずになり、膚倧な開発コストがかかっおいたした。この状態は各皮ロボットが連携する将来を芋据えたロボットの動䜜デヌタの収集ずいう芳点では、障壁ず蚀えるでしょう。 このサむロ化したロボット開発環境の問題を解決するため、ROS ãŒç™»å Žã—たした。ROSRobot Operating Systemは、䞊蚘の課題を解決するオヌプン゜ヌスの共通フレヌムワヌクです。暙準化された通信の仕組みずツヌル矀を提䟛し、開発者はハヌドりェアの違いを意識せずにロボットの機胜開発に集䞭できたす。さらに、ROS2 ã®ç™»å Žã‚’きっかけに近幎では産業甚ロボットメヌカヌも ROS2 のサポヌトを発衚する機䌚が増えおきたした。 デモの内容 デモのタむトルにある「遠隔テレオペレヌション」テレオペずは、離れた堎所にあるロボットや機械を、人間がリアルタむムに操䜜する技術です。オペレヌタヌは手元のコントロヌラヌやモニタヌ映像を通じお珟堎の状況を把握し、ロボットに動䜜指瀺を送りたす。ロボット偎のカメラやセンサヌの情報がネットワヌク経由でオペレヌタヌに返されるこずで、あたかも珟堎にいるかのように䜜業できたす。この技術により危険な環境灜害珟堎、高所、有害物質のある堎所や、人がすぐに行けない遠隔地での䜜業を安党に行えおいたす。 このテレオペのデモでは AWS の IoT サヌビスを利甚し、 Web の UI を芋ながらゲヌムコントロヌラヌを操䜜するこずで、クラりド経由でロボットを操䜜したす。 このデモで利甚しおいる実機のロボットは、䞖界䞭の生産珟堎でも利甚されおいるセむコヌ゚プ゜ン株匏䌚瀟補の高速・高粟床な垂盎倚関節6軞ロボット( CX4-A601S )を利甚しおいたす。セむコヌ゚プ゜ン株匏䌚瀟では自瀟のロボットに察応した ROS2 パッケヌゞ を公開しおおり、デモでは ROS2 経由で操䜜しおいたす。 このデモでは同時にデゞタルツむンずしおの Amazon EC2 äžŠã§å®Ÿè¡Œã•れおいる NVIDIA Isaac SIM ã«ã‚‚情報が送られるため、カメラの映像だけではなく、シミュレヌション環境䞊でもロボットの動䜜を確認するこずができたす。 セむコヌ゚プ゜ン株匏䌚瀟の ROS2 パッケヌゞ では実機を利甚せず、Rviz (3D 可芖化ツヌル)で動かすモヌドも甚意されおいるため、シミュレヌション環境の䞭だけで動かすこずもできたす。それゆえ、ロボットの操䜜に䞍慣れな人でも安心しお操䜜するこずが可胜です。 このデモでは操䜜時のデヌタを rosbag 圢匏 (ROS2 䞊でやり取りされるメッセヌゞを蚘録し、埌で利甚できる) に保存するこずも可胜で、䜜成された rosbag は蚘録埌にクラりドに保存されたす。このデヌタを䜿うこずで、クラりド䞊のシミュレヌション環境で、同じ様に再珟するこずもできたす。たた、保存された操䜜デヌタは、Physical AI で利甚される VLAVision-Language-Actionモデルの暡倣孊習デヌタずしお掻甚するこずができたす。 今回のデモの党䜓の構成は䞋蚘ずなっおいたす。 ぜひ、 6 月 25 日、26 æ—¥ã«å¹•匵メッセで開催される AWS Summit ã«æ¥å Žã„ただき、実際にご自身の手でコントロヌラヌを操䜜 し、Physical AI の時代に必須ずなるロボット動䜜デヌタ生成ず収集を䜓隓しに来おください デモは AWS Expo の AWS for Industries Zone に展瀺しおいたす。 䌊藀ゞャッゞ向子 (Ito, Judge Sakiko) 米囜での開発者経隓を経お、AWSのサポヌトに入瀟し、異動し゚ンタヌプラむズ事業本郚で゜リュヌションアヌキテクトずしお補造業のお客様をご支揎しおいたす。趣味は山登り、クラッシックバレ゚ず愛犬のお䞖話です。 Muhammad Fikko Fadjrimiratnoふぃっこ アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 䞍動産・建蚭業界のお客様を䞭心に、AWS 利甚をご支揎しおいる゜リュヌションアヌキテクトです。奜きな領域はロボットずIoTず機械孊習であり、最近はロボット分野での生成AIの掻甚にチャレンゞしおいたす。趣味はフラむトシミュレヌタヌ、冬はスノヌボヌドです。 垂川 箔 プロトタむピング゜リュヌションアヌキテクト AWS では IoT に関連するプロトタむピングを支揎する、゜リュヌション アヌキテクトずしお、お客様の IoT 関連案件を支揎しおいたす。
  みなさんこんにちは 猫や犬に癒されるより AI bou (盞棒) に助けられる日々を送る Solutions Architect の高野です。䞀昚幎、昚幎ず AWS Summit Japan でご奜評いただいた Chaos Kitty が、今幎はさらにパワヌアップした「察戊モヌド」を匕っさげお 4 回目の登堎です   この蚘事では、2026 幎の AWS Summit Japan の AWS Builders’ Fair で展瀺される「人間 vs AI 障害察応バトル – Chaos Kitty Challenge」に぀いおご玹介したす。今幎のテヌマは、システム運甚保守業務における AI Agent の掻甚による効率化です。参加者ず AI ゚ヌゞェントが同じ障害に同時に挑み、察戊を通じお AI Agent がむンシデント察応をどのように効率化するかを䜓感できる䜓隓型コンテンツずなっおいたす。   AWS Summit Japan 2026 の開催期間は 2026 幎 6 月 25 日 (æ°Ž) ず 26 日 (朚) の 2 日間で、䌚堎は幕匵メッセになりたす。 本展瀺は䞡日ずもご䜓隓いただけたす。 ただ AWS Summit Japan 2026 に登録しおない方は こちらのペヌゞ からご登録ください。Chaos Kitty は、AWS Expo の AWS Builders’ Fair の䞭にありたす。 Chaos Kitty ずは   Chaos Kitty は、AWS のアヌキテクチャを物理的に衚珟し、むンシデント察応の䜓隓孊習ができる゜リュヌションです。Web 3 局アプリケヌションに異垞を泚入し、異垞を修正するたでのタむムを競うこずで、ゲヌム感芚でむンシデント察応を孊ぶこずができたす。   2023 幎の初登堎 以来、 2024 幎 、 2025 幎 ず 3 幎連続で AWS Summit Japan に登堎し、毎幎パワヌアップを重ねおきたした。昚幎は IoT 機噚なしで利甚可胜な Web アプリケヌション化や、 AWS Cloud Development Kit (AWS CDK) による Infrastructure as Code (IaC) 化を実斜し、 AWS Samples ずしお公開 しおいたす。どなたでもご自身の AWS 環境にデプロむしおお詊しいただけたす。たた、Amazon CloudWatch ダッシュボヌドや Amazon CloudWatch Application Signals を掻甚したモニタリングも組み蟌たれおおり、むンシデント発生時の状況把握を䜓隓いただけたす。 新機胜玹介: 察戊モヌド   4 回目ずなる今回は、 システム運甚保守における AI Agent 掻甚 をテヌマに、察戊モヌドを新たに远加したした。AI Agent がむンシデント察応をどのように効率化するかを楜しみながら䜓感いただけるよう、参加者ず AI が同じ障害に同時に挑むゲヌム圢匏にしおいたす。 図 1 : AWS Summit Tokyo 2026 版 Chaos Kitty 倖芳 図 2 : 障害泚入察象の Web 3 局アプリケヌション画面 察戊モヌドの抂芁   同じ障害が発生した 2 ぀の環境で、参加者ず AI ゚ヌゞェントが同時に察応を開始したす。人間の盎感ず経隓 vs AI の分析力ず速床 — リアルタむムで䞡者の察応プロセスが可芖化され、どちらが早く正確に障害を解決できるかを競いたす。AI 時代のむンシデント察応の未来を、察戊を通じお䜓感できるモヌドです。   日々システムを運甚されおいる皆様であれば、障害発生時にログを远い、メトリクスを確認し、構成倉曎を掗い出し、根本原因を突き止めるたでの緊匵感ず難しさをよくご存知かず思いたす。その䞀連のプロセスを、AI Agent はどれほどの速さでこなすのか。そしお、あなたは AI Agent に勝おるのか。今幎は埓来の Easy モヌド、Hard モヌドに加えお、䞊玚者向けの Extreme モヌドも远加しおいたす。長幎の経隓ず勘で培ったむンシデント察応力を、ぜひ AI にぶ぀けおみおください。勝っおも負けおも、AI 時代のシステム運甚のあり方を肌で感じおいただけるはずです。腕に自信のある方、お埅ちしおおりたす 図 3 : 察戊モヌド初期画面 図 4 : ゲヌム䞭画面 図 5 : 勝敗確定画面 (AI WIN) 図 6 : 結果画面 むンシデント調査・分析甚 AI Agent に AWS DevOps Agent を採甚   察戊モヌドで参加者ず競う AI Agent には、 AWS DevOps Agent を採甚しおいたす。   AWS DevOps Agent は、むンシデント察応を自動化するフルマネヌゞドサヌビスです。むンシデントが発生するず、Amazon CloudWatch のメトリクス、ログ、トレヌス、さらにはデプロむ履歎や API 倉曎履歎など、耇数のデヌタ゜ヌスを暪断的に分析し、根本原因の特定から修埩アクションの提案たでを自動で行いたす。人間のオンコヌル゚ンゞニアが手動で盞関分析に費やしおいた時間を、数分レベルに短瞮できるのが特城です。   AWS DevOps Agent は API 経由で調査タスクの開始や状態取埗ができるため、今回の Chaos Kitty ではアプリケヌションから API を呌び出し、察戊モヌドの画面䞊に AI Agent の調査プロセスをリアルタむムで衚瀺しおいたす。参加者は、自分が手動で調査を進める暪で、AI Agent がどのような手順で原因を特定しおいくかを目の前で確認できたす。   たた、AWS DevOps Agent が暙準で提䟛する Web 画面 (DevOps Agent Space) もブヌスでご芧いただけたす。実際の運甚で AWS DevOps Agent をどのように掻甚できるかのむメヌゞを掎んでいただけるず思いたす。 図 7 : AWS DevOps Agent Space の画面 䜓隓を通じお孊べるこず   この察戊モヌドを通じお、以䞋のこずを䜓感いただけたす。 1. AI Agent がどのようにむンシデントを調査・分析するか — AWS DevOps Agent の動䜜を目の前で確認できたす 2. AIOps による迅速化の効果 — 手動察応ず AI 支揎察応の所芁時間の差を実䜓隓で理解できたす 3. AI Agent を掻甚したむンシデント察応の実践むメヌゞ — 日々のシステム運甚にどう掻かせるかのヒントを埗られたす さいごに   今幎の Chaos Kitty は、システム運甚保守における AI Agent 掻甚をテヌマに、察戊モヌドを通じおその効果を楜しみながら䜓感いただける内容になっおいたす。AI Agent がむンシデントをどのように調査・分析するのか、そしお日々の運甚業務にどう掻かせるのか、ぜひブヌスで実際に䜓隓しおみおください。   AI に勝おた方も、負けおしたった方も、AI 時代のシステム運甚のあり方に぀いお新たな気づきを持ち垰っおいただければ幞いです。AWS Summit Japan 2026 の AWS Builders’ Fair で、皆様のご来堎をお埅ちしおおりたす アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクト 高野 翔史 Chaos Kitty は AWS Japan ゜リュヌションアヌキテクトの服郚 䞀成、堀 貎裕、䜐々 拓也、接郷 光明、河角 修、黒朚 琢倮、高野 翔史が䞭心ずなっお開発しおおりたす。
倧芏暡なデヌタ量を運甚するうえで、運甚面での重芁な課題に盎面したす。Similarweb では Apache HBase でこれらの課題に盎面し、 Amazon DynamoDB で解決策を芋出したした。 Similarweb は、 Web サむトのトラフィック、アプリの利甚状況、垂堎トレンドに関する AI 駆動のむンサむト を提䟛するデゞタルむンテリゞェンスプラットフォヌムであり、䌁業が競合をベンチマヌクし、成長戊略を最適化するのに圹立ちたす。 私たちは既存の Apache HBase むンフラストラクチャでスケヌラビリティず運甚䞊の耇雑さの問題が増倧しおおり、より柔軟で効率的な代替案を暡玢するこずになりたした。本蚘事では、デヌタストレヌゞを Apache HBase から DynamoDB ぞ移行した過皋を玹介したす。技術的な課題、移行アプロヌチ、デヌタモデリング戊略、コスト最適化テクニック、そしお埗られた䞻なメリットに぀いお議論したす。DynamoDB ぞ移行するこずで、パフォヌマンスずスケヌラビリティが向䞊し、メンテナンス負荷が軜枛され、チヌムはむンフラ管理よりもむノベヌションに泚力できるようになりたした。孊んだ教蚓ず、この移行が業務オペレヌションに䞎えた圱響に぀いおも探っおいきたす。 背景 私たちの Web アプリケヌションでは、ナヌザヌに倧量のデヌタを提䟛するために堅牢なデヌタベヌス゜リュヌションが必芁です。その゜リュヌションは、デヌタを効果的に保存し、迅速に取埗し、ナヌザヌむンタヌフェむスに結果を返す前に集蚈、グルヌピング、゜ヌトなどの操䜜を実行する必芁がありたす。これを実珟するため、デヌタの性質ずク゚リパタヌンに基づいた 2 ぀のアプロヌチを採甚し、Web アプリケヌションを応答性が高くむンタラクティブに保぀よう蚭蚈しおいたす。 最初のアプロヌチは、ナヌザヌ入力に䟝存する動的ク゚リや、サむトグルヌプのべき集合のデヌタを蚈算するような耇雑な蚈算に関するものです。これは膚倧な数の組み合わせずなり、事前蚈算は珟実的ではありたせん。そのため、これらのク゚リには Firebolt のようなクラりド分析デヌタベヌス (OLAP システム) を䜿甚しおいたす。Firebolt は、JOIN、GROUP BY、その他の SQL ラむクなク゚リ操䜜を含む耇雑なク゚リパタヌンにも䜿甚しおいたす。これらのデヌタベヌスは、ETL ベヌスの事前集蚈に適さない倧芏暡デヌタセットのオンザフラむ凊理に優れおいたす。 䞀方、2 ぀目のアプロヌチでは、予枬可胜で事前蚈算可胜なアクセスパタヌンを持぀機胜に぀いお、DynamoDB のようなキヌバリュヌ (KV) ストアを䜿甚しおいたす。定期的な ETL プロセスでデヌタを事前蚈算するこずにより、DynamoDB は集蚈情報ぞの高速で簡玠なアクセスを提䟛し、パフォヌマンスずスケヌラビリティのバランスを取りながらナヌザヌに応答性の高い䜓隓を提䟛したす。 トラフィックず゚ンゲヌゞメントデヌタを取埗するための芁件 事前蚈算デヌタの利甚方法を瀺すために、プラットフォヌムの UI で衚瀺しおいる、Web サむトのトラフィックず゚ンゲヌゞメントの経時的な掚移ずいう兞型的なナヌスケヌスを芋おみたしょう。 図 1: Similarweb の Traffic and Engagement レポヌトでは、ナヌザヌは分析するサむト (1) を遞択し、日付範囲 (2) を遞び、䞖界党䜓たたは特定の囜などの地理的範囲 (3) を蚭定できたす。これらの遞択を行うず、グラフには遞択した期間における蚪問数やナニヌクナヌザヌずいった䞻芁メトリクスが衚瀺されたす。 䟋えば example.com などの Web サむトの蚪問統蚈を、サむト名、日付、囜 (ISO コヌド)、蚪問数ずいった詳现ずずもに保存しおいたす。   Site Country (ISO) Date Visits TimeOnSite BounceRate 
 example.com 840 2026-01-22 7 15.2 7 example.com 840 2026-01-23 11 11.7 1 example.com 840 2026-01-24 3 20.3 4 example.com 840 2026-01-25 12 13.2 5 example.com 840 2026-01-26 9 19.1 7 アクセスパタヌンずしおは、example.com の特定の日付範囲における党囜の蚪問デヌタを取埗したり、米囜 (840) のような特定の囜の蚪問デヌタをク゚リしたりするこずが考えられたす。このシナリオでは、ETL プロセス䞭に日付、囜、サむトの各組み合わせに察する蚪問数を事前に蚈算しお保存するこずで、これらの䞀般的なアクセスパタヌンに察しお迅速な応答時間を実珟し぀぀、ク゚リ時の蚈算オヌバヌヘッドを最小限に抑えるこずができたす。 これらの事前蚈算されたメトリクスは単玔に芋えたすが、Similarweb の芏暡では、その背埌にある曞き蟌み負荷ずク゚リの倚様性が既存の HBase クラスタを限界たで抌し䞊げたした。私たちのケヌスでは、デヌタは継続的に曞き蟌たれるのではなく、Spark ゞョブを䜿甚しお日次、週次、月次ずいったスケゞュヌルされた間隔で倧芏暡なバッチで取り蟌たれたす。 倧芏暡スケヌルず柔軟なアクセス Similarweb のトラフィックず゚ンゲヌゞメントデヌタセットは膚倧で、合蚈 255 テラバむト (TB) を超えたす。デヌタを継続的に取り蟌むトランザクションアプリケヌションずは異なり、私たちの分析パむプラむンは倧きなバヌストで呌吞したす。デヌタを新鮮に保぀ため、 1 テヌブルあたり玄 70 億レコヌド を、数時間で完了させる必芁があるタむトなスケゞュヌルのバッチで取り蟌んでいたす。 しかし、デヌタを曞き蟌むこずは戊いの半分にすぎたせん。保存埌、このデヌタは倚様で耇雑な読み取りパタヌンに察しお即座に利甚可胜でなければなりたせん。ナヌザヌは単玔なキヌ怜玢以䞊のこずを行いたす。圌らは耇数の次元でデヌタを切り分けお、競合をベンチマヌクし、トレンドを分析したす。 次の図は、移行前のハむレベルなデヌタフロヌを瀺しおいたす。 図 2 (移行前): 生のむベントはデヌタレむクに到達し、Spark ETL が日次集蚈を蚈算し、バルク曞き蟌みで結果を HBase に保存したす。.NET バック゚ンドはサむトず囜のメトリクスをキヌ (および日付) で読み取り、Traffic and Engagement UI に提䟛したす。すべおの矢印はデヌタフロヌを衚しおいたす。 単玔なキヌバリュヌ怜玢を超えお 特定のフィルタリングパタヌンに察しお 1 桁ミリ秒の読み取りを提䟛しながら、倧芏暡な曞き蟌みスパむクに察応できるデヌタベヌス゜リュヌションが必芁でした。具䜓的には、任意のサむトに察しお以䞋の 4 ぀のアクセスパタヌンをサポヌトする必芁がありたした。 サむトレベルの集蚈: サむトの党トラフィックを取埗。 SELECT * WHERE Site = {site} 特定の囜の内蚳: 特定の囜にドリルダりン。 SELECT * WHERE Site = {site} AND Country = {country} 時系列トレンド: 特定の期間の履歎を取埗。 SELECT * WHERE Site = {site} AND Date BETWEEN {start} AND {end} 耇雑な組み合わせ: 囜ず日付範囲の䞡方でフィルタリング。 SELECT * WHERE Site = {site} AND Country = {country} AND Date BETWEEN {start} AND {end} これを達成するために、理想的なデヌタベヌスは以䞋の 4 ぀の厳栌な基準を満たす必芁がありたした。 高い曞き蟌みスルヌプット: 数時間で数十億レコヌドを取り蟌む。 倚甚途なク゚リサポヌト: テヌブル党䜓をスキャンせずに、前述の次元ベヌスのク゚リを凊理。 パフォヌマンスを保ったスケヌラビリティ: ピヌク曞き蟌み時でも高い読み取りパフォヌマンスを維持。 コストの透明性: 請求曞で驚くのではなく、実行 前に コストを芋積もれる予枬可胜な料金モデルを提䟛。 HBase が壁にぶ぀かった理由 HBase は長幎にわたっお私たちに圹立っおきたしたが、Similarweb の芏暡では、埐々に「䜿甚するデヌタベヌス」から「運甚するシステム」ぞず倉化しおいきたした。䞭栞的な制限は生の胜力ではありたせんでした。それは、非垞に倧芏暡なバッチ曞き蟌みず垞時皌働の読み取りに察する厳しい期埅を組み合わせた埌に珟れた運甚リスクず䞍安定さでした。 1. RegionServer の䞍安定性がオンコヌル察応の原因に 繰り返し発生するむンシデントの原因は、HBase の RegionServer がクラスタの他の郚分ず同期しなくなったり、ダりンしたりするこずでした。RegionServer がドリフトしたり誀動䜜したりするず、ホストするリヌゞョンの可甚性ずレむテンシに圱響を䞎える可胜性がありたす。回埩が可胜な堎合でも、それは䞍安で時間がかかるものであり、頻繁に発生したため、実質的な運甚負担ずなっおいたした。 2. ストレヌゞずディスクのアップグレヌドが悪倢 倧芏暡な HBase 環境におけるディスク管理ずアップグレヌドは、垞に非垞に摩擊の倧きいものでした。分散システムにおけるディスク倉曎は単独のむベントではありたせん。それはパフォヌマンス、安定性、運甚手順に波及したす。ルヌチンずなるべきむンフラ䜜業がしばしば実質的なリスクを䌎う耇数ステップのメンテナンスに倉わり、特に取り蟌みりィンドりや読み取り SLA を保護しようずしおいるずきには厳しいものでした。 3. アヌキテクチャの利点が私たちのアクセスパタヌンず䞀臎しなかった HBase のワむドカラムモデルは、倧きな行から列のサブセットを読み取るずきに真䟡を発揮したす。私たちの堎合、アクセスパタヌンはしばしばキヌに察するメトリクスの完党なセットを読み取るこずを必芁ずしおいたため、システムの最も匷力な蚭蚈䞊の利点を䞀貫しお享受するこずなく、システムの運甚コストを支払っおいるこずになっおいたした。 4. デヌタベヌスがピヌク向けにサむゞングされおいたため高コスト テラバむト芏暡のバッチロヌドは短く激しい曞き蟌みピヌクを生み出す䞀方で、補品は䟝然ずしお高速で予枬可胜な読み取りを必芁ずしおいたした。ピヌク向けにサむゞングされた垞時皌働クラスタを維持するこずは、1 日のほずんどで実際に䜿甚しおいないキャパシティに察しお支払うこずを意味しおいたした。 これらの課題は単䞀の壊滅的な障害ずしお珟れたわけではありたせん。それらは环積する運甚負荷ずしお珟れたした。深倜の呌び出しが増え、クラスタの健党性に費やす時間が増え、ルヌチンメンテナンスのリスクが増加したした。その耇合化するオヌバヌヘッドが、フルマネヌゞドな代替案を探すこずを促したした。 DynamoDB がこれらの課題にどう察凊するか DynamoDB により、以䞋が可胜になりたした。 クリティカルパスからクラスタ運甚を排陀。 DynamoDB では、リヌゞョンサヌバヌをプロビゞョニングする必芁がなく、リバランスもなく、むンフラ局でのキャパシティプランニングも手動で行う必芁がありたせん。それにより、デヌタベヌスの健党性に関連する日垞的な運甚䜜業ず障害モヌドの数が盎接削枛されたした。 氞続的なオヌバヌプロビゞョニングなしでバッチ取り蟌み向けにスケヌル。 私たちの曞き蟌みパタヌンは予枬可胜です。曞き蟌むレコヌド数ず完了たでの時間りィンドりがわかっおいたす。DynamoDB ではキャパシティをダむダルずしお扱うこずができたす。取り蟌み実行の盎前に プロビゞョンド曞き蟌みキャパシティナニット (WCU) を即座にスケヌルアップし、完了次第すぐにスケヌルダりンしたす。これにより、24 時間 365 日倧芏暡なクラスタを皌働させ続けるのではなく、コストをバッチりィンドりに合わせるこずができたした。 曞き蟌みスパむク䞭も読み取りパフォヌマンスを安定的に維持。 UI の背埌にあるアクセスパタヌンは、䞻にキヌベヌスの怜玢ず日付範囲ク゚リです。DynamoDB のパヌティション化されたアヌキテクチャず、 パヌティションキヌず゜ヌトキヌ に察する Query 操䜜 により、テヌブルが非垞に倧きく成長し、取り蟌みゞョブが䞊列実行されおいる堎合でも、これらの読み取りを䞀貫しお䜎レむテンシで提䟛できたす。 コスト動䜜を明瀺的か぀予枬可胜に。 DynamoDB のキャパシティずリク゚ストパタヌンが私たちのワヌクロヌドにきれいにマップされるため、レコヌド数、アむテムサむズ、予想されるク゚リの圢状から曞き蟌みず読み取りのコストを芋積もるこずができたす。これにより、コストモデリングは事埌的な驚きではなく、蚭蚈の䞀郚ずなりたした。 耐障害性ずディザスタリカバリオプションの改善。 DynamoDB は、すぐに䜿えるマネヌゞドバックアップずリカバリプリミティブを提䟛したす。マルチリヌゞョンのニヌズに察しおは、 DynamoDB Global Tables でリヌゞョン間でデヌタをレプリケヌトできるため、読み取りをロヌカルで提䟛でき、リカバリは倧芏暡クラスタを圧力䞋で再構築するこずに䟝存したせん。 この基盀が敎ったこずで、私たちのワヌクロヌド固有の郚分、぀たり高スルヌプットで効率的に取り蟌む方法ず、䜎コストでアクセスパタヌンを満たすためのキヌモデリングに集䞭できるようになりたした。次の図は、移行埌のデヌタフロヌを瀺しおいたす。 図 3 (移行埌) : 事前蚈算されたトラフィックず゚ンゲヌゞメントメトリクスは、2 ぀のパスを通じお提䟛されたす。予枬可胜で䜎レむテンシのアクセスのための DynamoDB に支えられたキヌバリュヌレヌンず、動的でアドホックなク゚リのための Firebolt を䜿甚する分析レヌンです。.NET バック゚ンドはそれに応じおリク゚ストをルヌティングしたす。歎史的に、レヌン A は HBase を䜿甚しおいたした。それを DynamoDB に眮き換えたした。 デヌタモデリング DynamoDB のパフォヌマンスずコストのメリットを最倧限に匕き出すためには、実際のク゚リパタヌンに基づいおデヌタモデルを蚭蚈するこずが重芁でした。私たちの目暙は、応答時間ず読み取り/曞き蟌みキャパシティ䜿甚量の䞡方を最小化する効率的なアクセスパスを䜜成するこずでした。 Traffic and Engagement の䟋を再床芋おみたしょう。コアアクセスパタヌンには、日付範囲党䜓にわたるサむトの蚪問デヌタの取埗ず、オプションで囜によるフィルタリングが含たれたす。 単玔なアプロヌチ: パヌティションキヌ 最初のアプロヌチは、次のようなフラットでナニヌクなパヌティションキヌを䜜成するこずかもしれたせん。 PK = {site}_{country}_{date} Primary key Visits TimeOnSite BounceRate PK example.com_840_2026-01-21 4 24 12.31 1 か月分のデヌタ、䟋えば 2026 幎 1 月の米囜 (囜コヌド 840) における example.com ぞの蚪問を取埗するには、31 個の個別のキヌを生成し、BatchGetItem リク゚ストを発行したす。 example.com_840_2026-01-01 example.com_840_2026-01-02 ... example.com_840_2026-01-31 この蚭蚈は機胜したすが、スケヌルでは非効率でコストがかかりたす。単䞀の BatchGetItem リク゚スト内では、各アむテムの取埗が個別の読み取り操䜜ずしおカりントされ、ペむロヌドサむズが小さくおもアむテムごずに 1 ぀の読み取りキャパシティナニットを消費したす。 最適な蚭蚈: パヌティションキヌず゜ヌトキヌを持぀コンポゞットキヌ よりスケヌラブルなモデルでは、パヌティションキヌず゜ヌトキヌを持぀ コンポゞットプラむマリキヌ を䜿甚したす。 パヌティションキヌ (PK): {site}_{country} ゜ヌトキヌ (SK): {date} Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 このセットアップでは、DynamoDB の効率的な Query API を䜿甚しお、日付範囲にわたるサむトず囜のペアのすべおのレコヌドをク゚リできたす。 Query(PK="example.com_840", SK BETWEEN "2026-01-01" AND "2026-01-31") これにより API コヌルの数が枛り、゜ヌトキヌに察する範囲ク゚リを䜿甚するこずで読み取りコストが倧幅に削枛されたす。 コスト比范: Query 察 BatchGetItem サむトず囜の組み合わせごずに 500 日分のデヌタを取埗し、各゚ントリが玄 200 バむトであるナヌスケヌスを考えおみたしょう。 泚: RCU はアむテムサむズに応じお 4 KB チャンクでスケヌルしたす。結果敎合性のある読み取りでは RCU が半分になりたす。 アプロヌチ 読み取り API RCU 蚈算 掚定コスト フラット PK BatchGetItem 500 アむテム × 1 RCU = 500 RCU $0.065 コンポゞット PK + SK Query 100 KB / 4 KB = 25 RCU $0.00325 節玄: コンポゞットキヌ蚭蚈を䜿甚するこずで 20 倍以䞊安䟡 。 党䞖界のナヌスケヌス コンポゞットキヌモデル ( PK = {site}_{country} 、 SK = {date} ) は、サむト、囜、日付範囲でフィルタリングされた䞀般的なク゚リを効率的にサポヌトしたすが、 党囜にわたる蚪問デヌタをク゚リ する必芁がある堎合に課題が生じたす。䟋えば、example.com の党䞖界の蚪問を、党期間たたは特定の日付範囲で取埗する堎合です。 SELECT * WHERE Site = 'example.com' SELECT * WHERE Site = 'example.com' AND Date BETWEEN '2026-01-01' AND '2026-01-31' 既存のスキヌマでは、 囜コヌドがパヌティションキヌに埋め蟌たれお おり、これはパヌティション間で曞き蟌みず読み取りの負荷を均等に分散するために䞍可欠です。しかしこれは、 デヌタをク゚リするには囜を知る必芁がある こずも意味し、グロヌバル集蚈のナヌスケヌスには望たしくありたせん。 シンプルですが非効率な解決策は、すべおの囜別パヌティションにわたっお Query API コヌルをファンアりト するこずです。 # ファンアりト Query: すべおの囜にわたるサむトの蚪問を取埗 results = [] for country in country_codes: # ~200 ISO 3166 コヌド pk = f"example.com_{country}" response = query( TableName='TrafficTable', KeyConditionExpression="PK = :pk AND SK BETWEEN :start AND :end", ExpressionAttributeValues={ ":pk": pk, ":start": "2026-01-01", ":end": "2026-01-31" } ) results.extend(response['Items']) # 囜レベルのレコヌドを集蚈しお単䞀の䞖界芏暡ビュヌにする worldwide = {} for item in results: date = item['SK'] visits = item['visits'] worldwide[date] = worldwide.get(date, 0) + visits # worldwide = {"2026-01-01": 148200, "2026-01-02": 136400, ...} 機胜的には正しいものの、このアプロヌチにはいく぀かの欠点がありたす。 高コスト : サむト/日付ク゚リごずに 200 以䞊の Query リク゚スト。 増加したレむテンシ : 200 のク゚リにわたっお結果をク゚リし集蚈するこずで、応答時間が倧幅に増加する可胜性がありたす。 BatchQueryItem なし : BatchGetItem ずは異なり、耇数の Query リク゚ストを単䞀の API コヌルにバッチ凊理するネむティブな方法はありたせん。 運甚オヌバヌヘッド : 200 以䞊の䞊列ク゚リの管理は、アプリケヌションに負荷をかけ、スロットリングのリスクを増加させる可胜性がありたす。 ファンアりトのコストず耇雑さを発生させずに効率的なグロヌバルク゚リをサポヌトするため、ETL プロセス䞭に特別な合成囜コヌド (䟋: 999) を導入したした。実際には、ETL パむプラむンの䞀環ずしお集蚈された䞖界芏暡メトリクスを事前蚈算しお保存し、専甚の「グロヌバル」パヌティションに曞き蟌みたす。これは、䞖界芏暡デヌタに指定されたパヌティションキヌ PK = {site}_999 を䜿甚するこずで実珟したす。 Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 example.com_999 2026-01-23 33 17 16.5 これにより、 単䞀の Query リク゚スト で䞖界芏暡デヌタをク゚リできたす。 Query(PK="example.com_999", SK BETWEEN "2026-01-01" AND "2026-01-31") このようにしお、読み取り時のパフォヌマンスオヌバヌヘッドがなく、耇数ではなく 1 ぀の Query リク゚ストを䜿甚するためコストも削枛されたす。 もちろん、「999」アプロヌチにもコストがかかりたす。サむトず日付ごずに远加の䞖界芏暡ロヌルアップを蚈算する必芁があるため ETL の耇雑さが増し、サむト囜レコヌドごずに远加のアむテムを氞続化するためストレヌゞも増えたす。それでも、システムを゚ンドツヌ゚ンドで芋るず、明らかな勝利です。読み取り時から曞き蟌み時に䜜業をシフトし、200 以䞊のファンアりトク゚リの必芁性を排陀し、アプリケヌション偎のオヌケストレヌションを枛らし、䞀貫しおより高速な䞖界芏暡読み取りを実珟したす。実際には、远加の ETL ずストレヌゞコストはク゚リコストずレむテンシの節玄によっお䞊回られるため、゜リュヌション党䜓ずしおはより安䟡で高速になりたす。 次のセクションでは、初期デヌタ移行ず毎月のデヌタ取り蟌み䞭に時間ずコストを節玄するために、DynamoDB の機胜をさらにどのように利甚しおいるかを探りたす。 DynamoDB ぞの曞き蟌み バッチ取り蟌みは私たちの分析パむプラむンの心拍です。継続的なストリヌムではなく、Databricks 䞊で日次、週次、月次のスケゞュヌルで ETL Spark ゞョブをトリガヌするスケゞュヌルされた Apache Airflow Directed Acyclic Graphs (DAGs) に䟝存しおおり、それぞれが䞋流機胜の鮮床芁件に合わせお調敎されおいたす。すべおの実行で、テヌブルが読み取りトラフィックに察しおできるだけ早く準備できるように、短い時間りィンドり内に DynamoDB に数十億のアむテム、しばしば数テラバむトをプッシュしたす。 DynamoDB は、異なるワヌクロヌドパタヌンに察応する 2 ぀の異なる キャパシティモヌド を提䟛しおいたす。オンデマンドモヌドはサヌバヌレスで埓量課金型のモデルで、トラフィック需芁に合わせお自動的にスケヌルし、キャパシティプランニングは䞍芁で、䜿甚した分のみ支払いたす。䞀方、プロビゞョンドモヌドでは、垌望する読み取りず曞き蟌みのスルヌプットを事前に指定する必芁があり、課金はこのプロビゞョンされたキャパシティに基づいお行われたす (完党に䜿甚されたかどうかにかかわらず)。私たちのケヌスでは、曞き蟌むレコヌドの総数ず取り蟌みの時間りィンドりが既にわかっおいるため、必芁な曞き蟌みキャパシティナニットを正確に蚈算しお蚭定できたす。これにより、スケゞュヌルされたバッチロヌドに察しおは、プロビゞョンドモヌドのほうがオンデマンドよりも倧幅にコスト効率が良くなりたす。 ゚ンドツヌ゚ンドのバッチワヌクフロヌ Airflow がロヌドをスケゞュヌル DAG パラメヌタには、テヌブル名ず゜ヌスから読み取る日付範囲が含たれたす。 ゞョブはピヌクの重耇を避けるためにずらされたす。 Databricks Spark が ETL を実行 Spark のパヌティションは、䞊列凊理を最倧化するために DynamoDB のパヌティションキヌず敎合したす。 DynamoDB Connector for Apache Spark を䜿甚しおおり、これは曞き蟌みをバッチ化し、指数バックオフによるリトラむロゞックを凊理したす。 キャパシティはゞャストむンタむムでスケヌルアップ タヌゲット DynamoDB テヌブルぞの最初の曞き蟌みの前に、むンフラスクリプトが UpdateTable を呌び出しおテヌブルのプロビゞョンド曞き蟌みキャパシティ、぀たり曞き蟌みキャパシティナニット (WCU) を蚈算されたピヌクたで匕き䞊げたす。スクリプトは、目暙期間ずレコヌド数に基づいおこのレベルを自動的に蚭定したす。 デヌタを䞊列に曞き蟌み DynamoDB Connector for Apache Spark を䜿甚し、プロビゞョンドキャパシティに密接に敎合したスルヌプットでデヌタを曞き蟌みたす。通垞、プロビゞョンド曞き蟌みキャパシティの玄 1.1 倍を目暙ずし、リ゜ヌスを十分に掻甚し぀぀最適な利甚率を達成するため、制埡されたレベルのスロットリングを受け入れたす。 キャパシティは自動的にスケヌルバックダりン ETL がすべおのレコヌドの曞き蟌みを終えるず、UpdateTable を再床呌び出しおプロビゞョンドキャパシティ曞き蟌みレベルを䞋げる埌続タスクをスケゞュヌルしたす。 def run_etl(table_name, records_count, target_duration_hours=1): # ステップ 3 -- キャパシティをゞャストむンタむムで蚈算しおスケヌルアップ desired_wcu = ceil(records_count / (target_duration_hours * 3600)) desired_wcu = clamp(desired_wcu, MIN_WCU, MAX_WCU) wait_until_table_is_active(table_name) current_wcu = describe_table(table_name).provisioned_write_capacity update_table(table_name, wcu=current_wcu + desired_wcu) # UpdateTable API wait_until_table_is_active(table_name) try: # ステップ 4 -- Spark DynamoDB Connector を介しおデヌタを䞊列に曞き蟌み spark.write(target_table=table_name, write_throughput_ratio=1.1) # プロビゞョンド WCU の玄 110% finally: # ステップ 5 -- キャパシティを自動的にスケヌルバックダりン update_table(table_name, wcu=current_wcu) # UpdateTable API wait_until_table_is_active(table_name) DynamoDB テヌブルのプロビゞョンドキャパシティを蚈算しおスケヌルアップする Python 疑䌌コヌド Amazon Simple Storage Service (Amazon S3) からの Import Table を䜿甚する DynamoDB ぞの曞き蟌みの時間ずコストをさらに削枛するため、HBase からの移行時および䞀郚の定期的な曞き蟌みに、 DynamoDB Import from S3 機胜を䜿甚しお、Amazon Simple Storage Service (Amazon S3) から盎接デヌタをむンポヌトしたした。これにより、レコヌドごずの曞き蟌みが䞍芁になり、取り蟌み時に曞き蟌みキャパシティナニットを消費するこずがなくなりたす。 メリット バルク取り蟌みで 最倧 90% のコスト削枛 。 ETL 取り蟌みのための Databricks コンピュヌティング䜿甚が䞍芁 。 ネむティブむンポヌトによっおリトラむロゞックが隠蔜され、運甚オヌバヌヘッドが取り陀かれた 簡玠化された運甚 。 埓来の Spark ゞョブず比范しお より高速な取り蟌み 。 Import Table 機胜は、アむテムごずの曞き蟌み操䜜ではなく、取り蟌たれたデヌタの総量に基づいお課金されるため、特に私たちのケヌスのように小さなアむテムを持぀倧きなテヌブルを移行する堎合、倧幅なコスト削枛を実珟したす。 S3 からのむンポヌトワヌクフロヌ ETL 前の自動化の䞀環ずしお、デヌタは指定された S3 パスから読み取られ、Import from S3 機胜でサポヌトされおいる DYNAMODB_JSON 圢匏に倉換されたす。 敎圢されたデヌタの S3 パスずテヌブル定矩を指定しお ImportTable API を呌び出したす。 モニタリングタスクがむンポヌト完了たで進捗を远跡したす。 期間ごずに別々のテヌブルにデヌタを保存するタむミング DynamoDB の Import from S3 機胜は、倧芏暡なバックフィルにずっおゲヌムチェンゞャヌですが、重芁な制玄がありたす。新しいテヌブルにのみむンポヌトできるずいう点です。その制限は、デヌタセットが自然に時間でパヌティション化されおおり、䞻に最近の期間でアクセスされる堎合には機䌚ずなりたす。 月次のデヌタセットでは、意図的な蚭蚈を採甚したした。月ごずに 1 ぀のテヌブルを䜜成し、Import from S3 を䜿甚しおその月のデヌタをむンポヌトし、デヌタが叀くなるに぀れおそれらのテヌブルのラむフサむクルを管理したす。 月次デヌタに適しおいる理由 このアプロヌチが特に月次ワヌクロヌドに適しおいる理由は以䞋のずおりです。 バルクロヌドが離散的 : 各月のデヌタセットは通垞完党なバッチずしお生成されるため、むンポヌトのクリヌンな単䜍になりたす。 ク゚リ時の運甚の簡玠さ : アプリケヌションは、コヌルドデヌタずホットデヌタを 1 ぀の倧きなテヌブルで混圚させる代わりに、関連する期間テヌブルにク゚リをルヌティングできたす。 保存期間管理が簡単に : 叀いアむテムを削陀する代わりに、期限切れになったテヌブル党䜓を削陀できたす。 コスト最適化が容易 : 叀い月次テヌブルは、アプリケヌションロゞックを倉曎するこずなく、幎霢を重ねるに぀れお Standard-IA テヌブルクラス に移行でき、ストレヌゞコストを削枛できたす。 実甚的な呜名芏則によっお自動化が容易になりたす。䟋: {table_name}_2026-01 。 ゚ンドツヌ゚ンドの実行方法 各月に぀いお、デヌタセットを生成し、サポヌトされおいるむンポヌト圢匏の 1 ぀である DynamoDB JSON に倉換し、新しい月次テヌブルに ImportTable を実行したす。 むンポヌト埌、䞍芁になったテヌブルを削陀する保存期間ポリシヌを適甚したす。 叀くなった月次テヌブルを Table Class Standard-IA に移行しおストレヌゞコストを節玄したす。 芁求された日付範囲が耇数の月にたたがる堎合、API は関連する月次テヌブルにわたっおク゚リをファンアりトし、結果をマヌゞしたす。 期間ベヌスのテヌブルを䜿甚すべきでない堎合 このパタヌンは匷力ですが、䞇胜ではありたせん。 日次のデヌタセット の堎合、1 日ごずにテヌブルを䜜成するずテヌブル数が爆発し、䞍必芁な運甚オヌバヌヘッドが発生したす。そのような堎合は、単䞀の長期間有効なテヌブルを維持し、暙準的な取り蟌みパス (Spark 曞き蟌み + プロビゞョンドキャパシティスケヌリング) を続けるほうが良いです。 経隓則 期間が粗い (月次以䞊) で、デヌタがバルクでロヌドされ、保存期間がテヌブルレベルで匷制できる堎合は、 期間ごずに別々のテヌブルを優先 しおください。 期間が现かすぎる (日次) 堎合、たたは同じ物理テヌブルぞの継続的な増分曞き蟌みが必芁な堎合は、 単䞀のテヌブルを優先 しおください。 結論 本蚘事では、Similarweb が Apache HBase から DynamoDB に移行した経緯を玹介したした。この移行は、運甚を簡玠化し、効率的にスケヌルし、むンフラオヌバヌヘッドを削枛しながら、倧芏暡に高速で信頌性の高いむンサむトを提䟛し続ける必芁性によっお掚進されたした。 レガシヌの HBase セットアップは匷力ではありたしたが、増倧するバッチ取り蟌みワヌクフロヌず動的ク゚リ芁件のニヌズに応えるのに苊劎しおいたした。安定性、運甚メンテナンス、スケヌリングの限界などの課題が、よりモダンなサヌバヌレスの代替案を求めるきっかけになりたした。 DynamoDB を採甚するこずで、以䞋を達成したした。 むンテリゞェントな曞き蟌みプロビゞョニングを䌎う ETL ゞョブを䜿甚した 高パフォヌマンスなバッチ取り蟌み 。 倧芏暡で倚様なク゚リパタヌンをサポヌトする 柔軟でコスト効率の高いデヌタモデリング 。 フルマネヌゞドでサヌバヌレスな DynamoDB アヌキテクチャによる 運甚負担の削枛 。 Amazon S3 から盎接むンポヌトするこずによる 䜎い運甚負担ず高速な履歎デヌタ移行 。 手動のクラスタ管理なしでの システム信頌性ずスケヌラビリティの向䞊 。 この移行は、デヌタむンフラのパフォヌマンスず安定性を向䞊させ、゚ンゞニアリングチヌムが機胜の構築ずむノベヌションの掚進に集䞭できるようにしたした。DynamoDB は、私たちの分析パむプラむンの匷靭でコスト効率の高い基盀であるこずが蚌明されおおり、Similarweb がお客様にタむムリヌで実行可胜なデゞタルむンサむトを提䟛するずいうミッションを支えおいたす。 本蚘事は 2026 幎 06 月 16 日 に公開された “Similarweb’s migration from HBase to Amazon DynamoDB” を翻蚳したものです。 原文: https://aws.amazon.com/blogs/database/similarwebs-migration-from-hbase-to-amazon-dynamodb/ 著者に぀いお Idan Lahav Idan はテルアビブを拠点ずする Similarweb の R&D ディレクタヌです。バック゚ンドむンフラ、プラットフォヌム基盀、デヌタ゚ンゞニアリングに深い専門知識を持ち、スケヌラブルなデヌタパむプラむンアヌキテクチャの蚭蚈ず、高スルヌプットプラットフォヌムの耇雑な課題の解決に泚力しおいたす。最近の HBase から DynamoDB ぞの移行においお、Idan は移行を可胜にした基盀ずなるむンフラ基盀の蚭蚈ず管理を担圓したした。 Leonid Koren Leonid は AWS のプリンシパル NoSQL ゜リュヌションアヌキテクトで、お客様が NoSQL デヌタベヌスを䜿甚しお既存のアプリケヌションをモダナむズし、新しいアプリケヌションを蚭蚈するのを支揎しおいたす。AWS に入瀟する前は、2000 幎代初頭からバック゚ンドシステムの蚭蚈ず開発を行っおきたした。

動画

曞籍