[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article:dena-mobile-game-observability":3},{"meta":4,"markdown":66,"quiz":67},{"type":5,"articleId":6,"slug":7,"title":8,"titleEn":9,"category":10,"summary":11,"publishedAt":12,"image":13,"vocabulary":14,"quizId":65},"article","tech-dena-observability","dena-mobile-game-observability","DeNAのモバイルゲーム監視基盤","DeNA's Mobile Game Observability Platform","tech","An overview of how DeNA operates large-scale mobile games with a unified observability stack — combining real-time KPI dashboards, crash analytics, distributed tracing across game\u002Fmatchmaking\u002Fpayment services, anomaly detection for cheating, and capacity planning for event spikes.\n","2026-04-27T00:00:00Z","https:\u002F\u002Fimages.yamiyomi.com\u002Ftech-dena-observability.png",[15,20,24,29,33,37,41,45,49,53,57,61],{"word":16,"reading":17,"meaning":18,"level":19},"監視","かんし","monitoring","N2",{"word":21,"reading":22,"meaning":23,"level":19},"基盤","きばん","platform",{"word":25,"reading":26,"meaning":27,"level":28},"指標","しひょう","metric","N1",{"word":30,"reading":31,"meaning":32,"level":28},"解析","かいせき","analysis",{"word":34,"reading":35,"meaning":36,"level":19},"分散","ぶんさん","distributed",{"word":38,"reading":39,"meaning":40,"level":28},"追跡","ついせき","tracing",{"word":42,"reading":43,"meaning":44,"level":28},"検知","けんち","detection",{"word":46,"reading":47,"meaning":48,"level":19},"不正","ふせい","cheating",{"word":50,"reading":51,"meaning":52,"level":19},"予測","よそく","prediction",{"word":54,"reading":55,"meaning":56,"level":19},"負荷","ふか","load",{"word":58,"reading":59,"meaning":60,"level":28},"突発","とっぱつ","sudden",{"word":62,"reading":63,"meaning":64,"level":28},"兆候","ちょうこう","sign","tech-observability-quiz","\n::para\n[株式会社]{かぶしきがいしゃ:corporation:N1}DeNAは[多数]{たすう:numerous:N3}の[大規模]{だいきぼ:large-scale:N1}モバイルゲームを[運営]{うんえい:operating:N2}しており、[同時]{どうじ:simultaneous:N4}[接続]{せつぞく:connection:N2}[数]{すう:number:N3}が[数百万]{すうひゃくまん:millions:N3}に[達する]{たっする:reaching:N3}タイトルも[珍しく]{めずらしく:rare:N2}ありません。こうしたサービスを[安定]{あんてい:stably:N3}して[提供]{ていきょう:provide:N1}するため、[同社]{どうしゃ:the company:N4}は[統一]{とういつ:unified:N1}された[監視]{かんし:monitoring:N1}[基盤]{きばん:platform:N1}を[構築]{こうちく:build:N2}しています。\n\n#en\nDeNA operates a large number of large-scale mobile games, and it is not unusual for a single title to reach millions of concurrent users. To deliver these services stably, the company has built a unified observability platform.\n::\n\n::heading\n[全体]{ぜんたい:overall:N3}アーキテクチャ\n\n#en\nOverall Architecture\n::\n\n::para\n[監視]{かんし:monitoring:N1}[基盤]{きばん:platform:N1}は[大きく]{おおきく:broadly:N5}[四つ]{よっつ:four:N5}のレイヤーで[構成]{こうせい:composed:N3}されています。[第一]{だいいち:first:N1}にメトリクス[収集]{しゅうしゅう:collection:N3}、[第二]{だいに:second:N1}にログ[集約]{しゅうやく:aggregation:N3}、[第三]{だいさん:third:N1}に[分散]{ぶんさん:distributed:N3}[追跡]{ついせき:tracing:N2}、そして[第四]{だいよん:fourth:N1}にクラッシュ[解析]{かいせき:analysis:N1}です。これらを[横断]{おうだん:traverse:N3}して[検索]{けんさく:search:N1}できるように、[共通]{きょうつう:common:N3}の[相関]{そうかん:correlation:N3}IDが[全]{ぜん:all:N3}リクエストに[付与]{ふよ:attached:N3}されます。\n\n#en\nThe observability platform is broadly composed of four layers: first, metrics collection; second, log aggregation; third, distributed tracing; and fourth, crash analytics. To enable cross-cutting search, a common correlation ID is attached to every request.\n::\n\n::heading\nリアルタイムKPIダッシュボード\n\n#en\nReal-Time KPI Dashboards\n::\n\n::para\n[経営]{けいえい:management:N2}・[企画]{きかく:planning:N1}[陣]{じん:team:N1}が[毎日]{まいにち:every day:N5}[確認]{かくにん:check:N3}するKPIには、DAU（[日間]{にっかん:daily:N5}アクティブユーザー）、MAU（[月間]{げっかん:monthly:N5}アクティブユーザー）、ARPU（ユーザー[一人]{ひとり:one person:N5}[当たり]{あたり:per:N3}[平均]{へいきん:average:N2}[売上]{うりあげ:revenue:N4}）、そしてチャーンレート（[離脱]{りだつ:churn:N1}[率]{りつ:rate:N1}）が[含まれ]{ふくまれ:included:N2}ます。これらは[従来]{じゅうらい:traditionally:N1}[翌日]{よくじつ:next day:N2}のバッチ[処理]{しょり:processing:N3}で[算出]{さんしゅつ:calculated:N2}されていましたが、[現在]{げんざい:now:N3}はストリーム[処理]{しょり:processing:N3}[基盤]{きばん:platform:N1}により[数秒]{すうびょう:a few seconds:N2}[以内]{いない:within:N3}に[更新]{こうしん:updated:N3}されます。\n\n#en\nKPIs that management and planning teams check daily include DAU (Daily Active Users), MAU (Monthly Active Users), ARPU (Average Revenue Per User), and churn rate. These were traditionally calculated by next-day batch processing, but are now updated within a few seconds via the stream-processing platform.\n::\n\n::callout\n[要点]{ようてん:key point:N3}：[意思]{いし:intention:N4}[決定]{けってい:decision:N3}の[速度]{そくど:speed:N3}を[上げる]{あげる:to raise:N5}には、[指標]{しひょう:metrics:N1}の[算出]{さんしゅつ:calculation:N2}[頻度]{ひんど:frequency:N1}そのものを[上げる]{あげる:to raise:N5}[必要]{ひつよう:necessary:N3}があります。\n\n#en\nKey point: To raise the speed of decision-making, the calculation frequency of the metrics themselves must be raised.\n::\n\n::heading\nクラッシュ[解析]{かいせき:analysis:N1}との[統合]{とうごう:integration:N1}\n\n#en\nIntegration with Crash Analytics\n::\n\n::para\nモバイル[端末]{たんまつ:device:N1}で[発生]{はっせい:occurring:N4}したクラッシュは、Firebase Crashlyticsに[送信]{そうしん:sent:N3}され、そこから[内部]{ないぶ:internal:N3}の[監視]{かんし:monitoring:N1}[基盤]{きばん:platform:N1}へ[転送]{てんそう:forwarded:N4}されます。[端末]{たんまつ:device:N1}[側]{がわ:side:N3}のスタックトレースと、サーバー[側]{がわ:side:N3}のログを[同じ]{おなじ:same:N4}リクエストIDで[結び付ける]{むすびつける:link together:N1}ことにより、「クライアントの[特定]{とくてい:specific:N3}APIコールがサーバー[側]{がわ:side:N3}のどの[応答]{おうとう:response:N1}に[起因]{きいん:caused by:N3}してクラッシュしたか」を[追跡]{ついせき:trace:N2}できるようになります。\n\n#en\nCrashes that occur on mobile devices are sent to Firebase Crashlytics, and from there forwarded to the internal observability platform. By linking device-side stack traces with server-side logs via the same request ID, engineers can trace \"which server response caused which client API call to crash.\"\n::\n\n::heading\n[分散]{ぶんさん:distributed:N3}[追跡]{ついせき:tracing:N2}の[役割]{やくわり:role:N3}\n\n#en\nThe Role of Distributed Tracing\n::\n\n::para\n[現代]{げんだい:modern:N3}のモバイルゲームは、ゲームサーバー、マッチメイキングサービス、[決済]{けっさい:payment:N3}サービス、[通知]{つうち:notification:N4}サービスなど[多数]{たすう:many:N3}のマイクロサービスで[構成]{こうせい:composed:N3}されます。プレイヤーが「[対戦]{たいせん:match:N3}を[開始]{かいし:start:N4}」ボタンを[押す]{おす:to press:N3}と、[十数]{じゅうすう:more than ten:N3}のサービスを[経由]{けいゆ:via:N3}するリクエストが[飛び交い]{とびかい:fly around:N3}ます。OpenTelemetryと[互換]{ごかん:compatible:N2}のトレーシングにより、[各]{かく:each:N2}サービスの[処理]{しょり:processing:N3}[時間]{じかん:time:N5}を[可視化]{かしか:visualize:N1}し、ボトルネックを[特定]{とくてい:identify:N3}しています。\n\n#en\nModern mobile games are composed of many microservices — game servers, matchmaking, payment, notifications, and more. When a player presses \"Start Match,\" a request flies through more than ten services. OpenTelemetry-compatible tracing visualizes the processing time of each service and identifies bottlenecks.\n::\n\n::heading\n[不正]{ふせい:cheating:N4}[行為]{こうい:behavior:N1}の[異常]{いじょう:anomaly:N1}[検知]{けんち:detection:N1}\n\n#en\nAnomaly Detection for Cheating\n::\n\n::para\n[自動]{じどう:automated:N4}[操作]{そうさ:operation:N1}ツールやチートツールを[使う]{つかう:use:N4}プレイヤーは、[正規]{せいき:legitimate:N3}のプレイヤーと[異なる]{ことなる:differ:N1}[行動]{こうどう:behavior:N4}パターンを[示す]{しめす:show:N3}ことが[多い]{おおい:often:N4}です。たとえば、リクエスト[頻度]{ひんど:frequency:N1}が[人間]{にんげん:human:N5}にはありえない[速度]{そくど:speed:N3}であったり、[特定]{とくてい:specific:N3}のAPIだけを[繰り返し]{くりかえし:repeatedly:N1}[呼ぶ]{よぶ:call:N3}といった[兆候]{ちょうこう:signs:N2}が[見られます]{みられます:are seen:N5}。[機械]{きかい:machine:N2}[学習]{がくしゅう:learning:N4}モデルがこれらを[継続的]{けいぞくてき:continuously:N1}に[学習]{がくしゅう:learn:N4}し、[疑わしい]{うたがわしい:suspicious:N3}アカウントを[自動]{じどう:automatically:N4}で[検知]{けんち:detect:N1}します。\n\n#en\nPlayers who use automation tools or cheats often exhibit behavioral patterns different from legitimate players — for example, request frequencies impossible for a human, or repeatedly calling only specific APIs. A machine-learning model continuously learns from these and automatically detects suspicious accounts.\n::\n\n::callout\n[注意]{ちゅうい:caution:N4}：[誤]{ご:false:N3}[検知]{けんち:detection:N1}は[正規]{せいき:legitimate:N3}ユーザーの[体験]{たいけん:experience:N4}を[損なう]{そこなう:harm:N2}ため、[自動]{じどう:automatic:N4}BANではなく、まず[人]{ひと:human:N5}による[確認]{かくにん:review:N3}キューへ[送る]{おくる:send to:N4}[運用]{うんよう:operational:N4}が[一般的]{いっぱんてき:general:N2}です。\n\n#en\nCaution: False detections harm legitimate users' experience, so it is common practice to send accounts to a human review queue first, rather than auto-banning.\n::\n\n::heading\nイベントスパイクへの[備え]{そなえ:preparation:N3}\n\n#en\nPreparing for Event Spikes\n::\n\n::para\n[期間]{きかん:limited-time:N3}[限定]{げんてい:limited:N3}イベントやガチャの[更新]{こうしん:update:N3}は、[通常]{つうじょう:normal:N3}[時]{じ:time:N5}の[数十]{すうじゅう:dozens:N3}[倍]{ばい:times:N2}の[負荷]{ふか:load:N2}を[生み出し]{うみだし:generate:N5}ます。[過去]{かこ:past:N3}のイベントの[負荷]{ふか:load:N2}データを[元]{もと:basis:N4}に、[将来]{しょうらい:future:N2}の[突発]{とっぱつ:sudden:N3}スパイクを[予測]{よそく:predict:N2}し、Kubernetesの[自動]{じどう:automatic:N4}スケーラーを[事前]{じぜん:in advance:N4}に[起動]{きどう:trigger:N4}します。これにより[ピーク]{ぴーく:peak}[直前]{ちょくぜん:just before:N3}にウォームアップ[済み]{ずみ:already done:N3}のPodが[十分]{じゅうぶん:sufficient:N5}に[揃う]{そろう:be in place:N1}[仕組み]{しくみ:mechanism:N3}になっています。\n\n#en\nLimited-time events and gacha updates generate loads dozens of times higher than normal. Based on historical event load data, the platform predicts future sudden spikes and proactively triggers Kubernetes autoscalers in advance. This ensures that warmed-up pods are sufficiently in place just before peak.\n::\n\n::heading\n[今後]{こんご:going forward:N5}の[展望]{てんぼう:outlook:N1}\n\n#en\nFuture Outlook\n::\n\n::para\nDeNAは[今後]{こんご:going forward:N5}、eBPFベースのオーバーヘッドの[低い]{ひくい:low:N2}トレース[収集]{しゅうしゅう:collection:N3}や、LLMによるアラート[要約]{ようやく:summarization:N3}にも[取り組む]{とりくむ:work on:N3}と[公表]{こうひょう:announced:N3}しています。[人手]{ひとで:human labor:N4}を[介さず]{かいさず:without intermediation:N2}、[症状]{しょうじょう:symptom:N1}から[根本]{こんぽん:root:N2}[原因]{げんいん:cause:N3}まで[一気に]{いっきに:in one stroke:N5}[到達]{とうたつ:reach:N3}できる[基盤]{きばん:platform:N1}が[目標]{もくひょう:goal:N1}です。\n\n#en\nDeNA has announced that it will work on lower-overhead trace collection based on eBPF, as well as LLM-based alert summarization. The goal is a platform that can reach root causes from symptoms in one stroke, without human intervention.\n::\n",{"id":65,"title":68,"titleEn":69,"topicPath":10,"questions":70},"テック確認テスト — オブザーバビリティ","Tech Check — Observability",[71,99,122,146,171],{"id":72,"articleId":6,"question":73,"options":76,"correctLabel":82,"explanation":93,"tags":96},"tech-observability-quiz-q01",{"en":74,"jp":75},"In DeNA's observability platform, what is the main reason real-time KPI dashboards are superior to conventional batch processing?","DeNAの監視基盤において、リアルタイムKPIダッシュボードが従来のバッチ処理よりも優れている主な理由は何ですか。",[77,81,85,89],{"label":78,"jp":79,"en":80},"ア","ストレージコストが安く済むから","Storage cost is cheaper",{"label":82,"jp":83,"en":84},"イ","意思決定の速度を上げられるから","Decision-making speed can be raised",{"label":86,"jp":87,"en":88},"ウ","プログラミング言語を統一できるから","Programming languages can be unified",{"label":90,"jp":91,"en":92},"エ","クラッシュ件数が減るから","The number of crashes decreases",{"en":94,"jp":95},"The article explicitly states as a key point that 'to raise the speed of decision-making, the calculation frequency of the metrics themselves must be raised.'","本文では「意思決定の速度を上げるには、指標の算出頻度そのものを上げる必要がある」と要点として明示されています。",[97,98],"observability","kpi",{"id":100,"articleId":6,"question":101,"options":104,"correctLabel":86,"explanation":117,"tags":120},"tech-observability-quiz-q02",{"en":102,"jp":103},"How does DeNA correlate crashes on client devices with server-side logs?","DeNAでは、クライアント端末のクラッシュとサーバー側ログをどのように関連付けていますか。",[105,108,111,114],{"label":78,"jp":106,"en":107},"プレイヤーのIPアドレスで関連付ける","By the player's IP address",{"label":82,"jp":109,"en":110},"端末モデル名で関連付ける","By device model name",{"label":86,"jp":112,"en":113},"共通のリクエストID(相関ID)で関連付ける","By a common request ID (correlation ID)",{"label":90,"jp":115,"en":116},"ゲームのバージョン番号で関連付ける","By the game's version number",{"en":118,"jp":119},"The article explains that linking via 'the same request ID' allows tracing the relationship between client API calls and server responses.","本文では「同じリクエストIDで結び付ける」ことでクライアントAPIコールとサーバー応答の関係を追跡できると説明されています。",[97,121],"correlation-id",{"id":123,"articleId":6,"question":124,"options":127,"correctLabel":82,"explanation":140,"tags":143},"tech-observability-quiz-q03",{"en":125,"jp":126},"In anomaly detection for cheating, which operational practice is generally recommended for handling false detections?","不正行為の異常検知において、誤検知への対応として一般的に推奨される運用はどれですか。",[128,131,134,137],{"label":78,"jp":129,"en":130},"検知時に即座に自動BANする","Automatically ban immediately upon detection",{"label":82,"jp":132,"en":133},"まず人による確認キューへ送る","First send to a human review queue",{"label":86,"jp":135,"en":136},"アカウントを無視する","Ignore the account",{"label":90,"jp":138,"en":139},"全プレイヤーに警告メールを送る","Send warning emails to all players",{"en":141,"jp":142},"The caution note states that since false detections harm legitimate users' experience, it is common to send to a human review queue rather than auto-banning.","誤検知は正規ユーザーの体験を損なうため、自動BANではなく人による確認キューへ送るのが一般的だと注意書きで明示されています。",[144,145],"anomaly-detection","operations",{"id":147,"articleId":148,"question":149,"options":152,"correctLabel":82,"explanation":165,"tags":168},"tech-observability-quiz-q04","tech-hatena-mackerel",{"en":150,"jp":151},"In Mackerel's alert design philosophy, what kind of alert is recommended?","MackerelのAlert設計思想では、どのようなアラートが推奨されていますか。",[153,156,159,162],{"label":78,"jp":154,"en":155},"原因に基づくアラート(例: CPUが高い)","Cause-based alerts (e.g., high CPU)",{"label":82,"jp":157,"en":158},"症状に基づくアラート(例: API応答時間超過)","Symptom-based alerts (e.g., API response time exceeded)",{"label":86,"jp":160,"en":161},"毎時定期的に送信されるアラート","Alerts sent on a regular hourly schedule",{"label":90,"jp":163,"en":164},"全メトリクスに対する固定閾値アラート","Fixed-threshold alerts on all metrics",{"en":166,"jp":167},"The article recommends symptom-side metrics (e.g., API response time) because they tie directly to user experience, while cause-side alerts lead to frequent false detections.","本文では症状側の指標(例: API応答時間)はユーザー体験に直結するため推奨されており、原因側のアラートは誤検知が多発するとされています。",[169,170],"alerting","philosophy",{"id":172,"articleId":148,"question":173,"options":176,"correctLabel":82,"explanation":189,"tags":192},"tech-observability-quiz-q05",{"en":174,"jp":175},"Which is the most appropriate reason Mackerel adopts a design that delegates on-call management (rotation, escalation) to specialized services?","Mackerelがオンコール管理(輪番、エスカレーション)を専用サービスに任せる設計を採用している理由として最も適切なものはどれですか。",[177,180,183,186],{"label":78,"jp":178,"en":179},"オンコール機能の開発が技術的に不可能だから","Developing on-call features is technically impossible",{"label":82,"jp":181,"en":182},"PagerDutyやOpsgenieなど専門サービスに役割を分担させるため","To divide roles by entrusting specialized services like PagerDuty and Opsgenie",{"label":86,"jp":184,"en":185},"通知を行いたくないから","They do not want to send notifications",{"label":90,"jp":187,"en":188},"メトリクス収集に集中するため、アラートを廃止しているから","They have abolished alerts to focus on metrics collection",{"en":190,"jp":191},"The article explicitly states that rotation, escalation, and notification suppression are entrusted to specialized services such as PagerDuty\u002FOpsgenie as a role division.","本文では、輪番・エスカレーション・通知抑止などはPagerDuty\u002FOpsgenieといった専用サービスに任せるという役割分担の設計と明示されています。",[193,194],"oncall","integration"]