【DeNA TechCon 2021 Autumn】デジタルコレクティブ、世界展開、データベース運用、QCDコントロール。企業成長でつけられた課題にDeNAはどう挑んだのか【イベントレポート】

最新のテックカンファレンス現場をレポートする本シリーズ。2021年9月29日、DeNAはオンラインで「DeNA TechCon」を開催した。ビジネスが多方面に展開し、急成長を続けていくなか、同社はどのようなテクノロジーに着目し、どう使いこなしているか。第1部では全体概要と4つのテーマ、NFTデジタルコレクティブ市場、ゲームの海外展開を支える共通機能、数百Shardにもなる大規模なデータベースのマネジメント、サービスの成長におけるQCDコントロールを解説する。

• keyboard_arrow_down オープニングキーノート【小林 篤氏登壇】
• keyboard_arrow_down NFTデジタル・コレクティブル市場におけるDeNAの新たなる挑戦【緒方 文俊氏登壇】
• keyboard_arrow_down 中国も含め全世界で共通のゲーム課金基盤を提供するための挑戦【橋本 侑樹氏登壇】
• keyboard_arrow_down 数百shardのデータベース運用を最適化する手法【天野 知樹氏登壇】
• keyboard_arrow_down インフラの究極の選択？QCDのどれを優先すべきか？【李 堯桓氏登壇】

最初に登場したのは「ネコカク（Twitter：@nekokak）」として知られている小林篤氏。2019年4月からDeNAのCTOを務め、同社の直近の取り組みについて紹介した。

クラウドシフト

DeNAは現在、オンプレからクラウドへの移行を完遂し、クラウド化したサービス群をより安定して稼働させ、より柔軟で生産性高い環境にするための段階へと突入した。ユーザーに安心感のあるサービスを持続的に提供するには、DR（ディザスタリカバリ）が重要となる。システムのクラウドシフトによりオンプレ時代より低コストで効率的DR構成を実現できるようになっている。小林氏は「これからはオンプレで経験したことをクラウドに生かしていきます。IaaSだけではなくSaaSやPaaSも含め、最適解を出せるように徹底的に使いこなしていきます」と話す。

データ活用の最大化

DeNAは2021年4月、エンゲージメントサイエンスやAIの効果を最大化するためにデータ統括部を創設した。ここでデータ設計、収集、分析、モデル開発、活用までを一気通貫で行い、AIを事業に活用するなど経営の高度化に役立てる。さらにデータ活用の効果を最大化するために、利用しているBIツール「Looker」に組み込むWebアプリケーションの開発にも取り組んでいる。

データヘルス

DeNAと住友商事の合弁会社であるDeSCヘルスケア株式会社では、ユーザーのヘルスデータをもとに健康管理を支援するアプリ「kencom」を展開している。

「kencom」で収集したデータは、ユーザー個人の健康増進に還元するだけではなく、官学と連携し、医療費の適正化、疾病予防など社会全体への還元にも活かしている。実世界のデータを分析に利用するためには複雑なデータ処理を行う必要がある。「データ利活用においては、ナレッジの集約、品質の標準化、継続的な改善が極めて重要です。DeNAはこれらをオペ―レーションではなく、システムで問題解決する組織を目指しています」（小林氏）

IRIAM

2021年8月にDeNAグループに仲間入りした、イラストをアップロードするだけで、キャラクターを使ったバーチャルライブ配信を楽しめるアプリ「IRIAM」。『IRIAM』はDeNAが推進するライブストリーミング事業で事業成長をリードする重要な存在として期待されている。

「IRIAM」には、AIによる自動キャラモデリング技術やリアルタイムのコミュニケーションを実現するために、音声・フェイストラッキングデータを直接送るモーションライブ技術など、最先端の取り組みが行われている。研究開発はまだ始まったばかりの段階にいる。今後はキャラクター認識精度や表現力のさらなる向上だけではなく、海外展開も視野に入れてサービスを躍進させていく。

セッション動画

2021年、ブロックチェーンで大きな話題になったのがNFT（Non-Fungible Token：非代替性トークン）。NFTはブロックチェーンの利用用途の1つで、デジタルデータのコピーや偽造ができないようにする技術として、デジタルアートの価値を証明する手段にもなりうる。実際にアート作品、トレーディングカードの新形態といえるような短い動画、有名人のツイートなどがNFT（ERC721）を用いることで高額で売買されることも実現するようになってきた。DeNAもNFTを用いたデジタルコレクティブ市場での取り組み（デジタルコンテンツを所有・収集する市場）に乗り出している。

その1つに、まだ検討中ではあるものの「NFTコレクション」がある。NFTを使えば、ビットコインを管理・保管するウォレットにてデジタルアイテムの収集（所有）、さらにウォレットを使ってのトレーディングが可能になり、将来的にはアプリケーション間の相互運用（オリジナルのキャラクターを他アプリ上で使用すること）も実現できる。

緒方氏は「事業会社としてはサービス終了の判断が必要なこともあるが、せっかくユーザーさんが作ってくれたキャラクターやアイテムを、終了後も手元に残しておく方法がないかと、ゲーム開発に関わっていた頃から長年考えていた」と話す。NFTコレクションで提供するキャラクターの第一弾は、過去Mobageで高い人気を誇った「住み着き妖精 セトルリン」を予定している。

NFT技術を活用したもう一つの事例は、スポーツ分野におけるスタッツ(STATS)を用いた取り組みだ。ここでは川崎ブレイブサンダースの「PICKFIVE」が事例となっており、IOT機器などから正確にスタッツ(STATS)のデータを吸い上げ、それをブロックチェーン上で管理、そしてスマートコントラクトを用いて、人の手を介することなく、ランキングの生成やリワードの付与などにつなげるといった、将来的な試みが紹介されていた。

ブロックチェーン市場は現在「チェーン戦国時代」と言われており、様々な機能を持ったチェーンが存在している。さらにチェーンと接続するためのSDKもチェーンごとに異なり、技術選定の難易度が高い。そんな中、緒方氏は基盤技術を選定するポイントについて、DeNAが大切にしている「User Delight（ユーザーデライト）」という言葉で表現している。ブロックチェーンにおけるユーザーデライトを届ける要素として、使いやすいUX、購入しやすい価格帯、相互運用性の3つのアプローチから説明を行った。

使いやすいUXについて、緒方氏はDeNAがクローズドβテストから参加した「LINE Blockchain」を例に挙げた。LINEのIDがあればNFTを簡単に扱うことができ、利便性が高いという。将来的には、LINE Blockchainだけではなく、EthereumやFlowなど、状況に応じて他のチェーンでの展開も視野に入れている。

ユーザーにとって手の届きやすい価格帯にすることも重要だ。昨今Ethereumのガス代（取引手数料）高騰が問題となっている。高止まりしている取引コストの低減を実現するために、「Layer 2 Solution」、「Gas-Less Transaction」、「Flow」など最新の技術に関する調査を進めている。

そして3者の中で最も難易度が高いのはアプリケーション間の相互運用性を実現すること。実際の開発現場では、オフチェーンのデータをどのようにオンチェーンにのせるか検討したり、ほかのアプリからトークンを移管する際のパラメーターの設定が難しかったりするなど、複数の課題に取り組んでいる。今後は、OracleNetworkといった、チェーン外の様々なデータを扱う仕組みの構築や、Statndardといった規格をつくることによって、色々な場面でデータの相互利用しやすい環境を作っていく予定だ。また、DAO（自立分散型組織）的なアプローチで、トークン所有する価格情報や発行枚数などの情報を正規化してパラメーターの自動生成につなげていく試みを続けるという。

緒方氏は「こういった試みはDeNAだけでは成し遂げられないと思っていますので、興味があればお気軽にお声かけください。ぜひ一緒に。新しい挑戦につなげられたらと思います」と語った。

セッション動画

橋本氏はこのセッションで、海外にむけて、とくに中国でスマホゲームを展開する上での課題と、認証や課金などの共通機能を担う「LCX」について解説した。

「LCX」はmBaaS（mobile Backend as a Service）とも呼ばれる、複数のゲームタイトルに対して認証、アプリ内課金、プッシュ通知などストア固有の処理を呼び出す機能群を抽象化するサービスである。ゲームタイトルに共通する機能を一箇所に集約することで開発・運用の効率化につなげている。

日本では、iOSならAppleのストア（App Store）、AndroidならGoogleのストア（Google Play）で寡占状態である。しかし海外、特に中国では、Androidストアが50を超えるほど群雄割拠でGoogle Playも使用不可。またクラウド環境も日本ではGCP、中国ではAlibaba Cloudと異なる。さらに運用サイクルに関しても、中国では実名認証や、未成年に対するアプリ使用時間のトラッキングなど、中国の法令に迅速に対応したパッチ開発、パッチリリースが求められる。

DeNAでは中国展開のために、早くから中国企業と提携し、中国で展開するゲームにも使うことができる「LCX」を共同開発している。上述の課題を解決するために、開発は日中両国の2チーム共同で行い、運用はチームごとに各自のノウハウが溜まっているクラウド上で行う「マルチクラウド運用」という形態を選択した。具体的には、認証や課金など同じふるまいをする部分はコアとしてビジネスロジックを共通化し、ここから別々のクラウドインフラのインターフェースを呼び出せるようにしている。クラウドインフラのインターフェースは日本側ではGCP用、中国側ではAlibaba Cloud用の実装を行うことで、急な中国政府の要求に対しても、限定された影響範囲内で独自のロジックが入れられるようになっている。

「LCX」では、ほとんどのクラウド呼び出しはこのような実装されている。ただし現場では、国を跨いだ開発ならではの課題に直面している。両国のチームは共通の振る舞いをするようにインターフェースを定義し実装することが求められるが、日本のエンジニアはAlibaba Cloudを、中国のエンジニアはGCPでの開発経験がない。お互いが未知のクラウド環境で開発・実装できるように、LCXでは、一般的に好ましいとされるクラウドプロダクトの使い分けをあえて最小限に抑えるようにしている。というのも、片方のクラウドでプロダクトの使い分けによって運用を最適化できても、もう一方では適用できない可能性が高いからだ。両チーム間でよりスムーズに開発を進めるために、極力単純なロジックで動く実装を心がけている。

さらに、データベースはGCPではSpanner、Alibaba CloudではPolarDBを用いているため、細かなところで文法や構文が違ったり、どちらかがスキーマ変更すると不整合が生じたりすることもある。こういった不整合を解決するために、永続化層に関しては実装をクラウド間で分けず、JPA（Java Persistence API）で抽象化し、JPAを実装するクラスがクラウドサービスを呼び出すようにしている。そうすることで、複数のクラウド間でインターフェースを切りづらい、ふるまいを共通化しづらいといった課題を解決することができる。また、データベースのDDLもJPAの機能を使って生成することができ、日本と中国のエンジニアがお互いのクラウドを気にせずデータベーススキーマを変更できる。

セッションの最後に橋本氏はLCXにおけるサーバーリリースの考え方を紹介した。「マルチクラウド運用の目的は、基本的なビジネスロジックやゲーム開発者に提供するAPIは共通とし、運用面ではそれぞれのノウハウを活かして、それぞれが必要なときにリリースができるようにすることです。これを実現するために、リリースは各チームが同一のコードベースから独自にバージョニング、デプロイを行う運用としています」（橋本氏）

セッション動画

DeNAではゲームをはじめとして、様々なサービスをグローバルに展開しており、その多様な特性に対応できるように柔軟性を意識して運用設計を行なっている。天野氏はこのセッションで、IT基盤部がデータベースの運用を最適化するために行ってきた取り組みを紹介した。

これまでDeNAでは、IT基盤部共通のツールセットのグローバルインフラやアプリ別のcookbookのchef、オーケストレーションツールを用いてインフラ運用の最適化を進めてきたが、いまだに工数がかかるのがデータベースだという。

大規模ゲームではMySQL互換のデータベースを採用しており、リリース直後は膨大なリクエストをさばくために数百shardもの水平分割を行い、負荷が落ち着くとshard統合を行うようにしている。また、モバイルゲームでは常にユーザーとサーバーが通信するため、高いIOPSの性能が求められ、イベント時にはユーザーが急増するので、常にクエリ最適化やスペック調整を行う必要がある。

DeNAのデータベース運用システムには第一世代と第二世代があり、機能が補い合えるように両者並行して運用している。

第一世代システムではIaaSを使ってMySQLを運用し、故障時には自動で処理を進めるようにしている。故障したslaveは自動的にDNSから切り離す。master故障時はMySQLの可用性を高めるMHAで対応する。

具体的には、slaveの中で最もポジションが進んでいるものをmasterに昇格させレプリケーションを張りなおすなど、自動フェイルオーバーが働くようにしている。故障対応やスペック変更を手軽に行うために、コマンド一つでslaveを自動複製できるような仕組みもつくっている。第一世代システムは、このようなslave複製とMHAに加え、マルチインスタンスという1つのインスタンス内で複数のプロセスを動かすDeNA独自の運用手法を組み合わせることで、ほぼ無停止でshard統合を実現している。またAWSではSSDを用いたi3/i3enインスタンスを使用し、高いIOPS性能も確保している。

ただし第一世代システムの課題として、イベントの際に毎回データベースインスタンスのサイズを変更する工数がかかることや、運悪く同じホストで同時多発的に故障が発生するリスクがあること、故障の際は手動で対応する必要があることが挙げられる。

第二世代システムは第一世代システムで解決できなかったインスタンス管理や故障時の課題を解決するためにAWSのAurora MySQL 5.7を採用している。Aurora MySQL 5.7は、マネージドデータベースであるため数百あるshardの運用コストを下げることができる。また、DeNAでは自前のDNSサーバーを用いてDNSの更新遅延を改善することで、独自のAurora高速フェイルオーバーを実装した。その結果、もともと20秒程度だったダウンタイムを5秒に短縮している。

ただ、第二世代システムにも課題がある。現段階では性能に対するコストが高い、イベントの際に毎回データベースインスタンスのサイズを変更する必要がある、shard統合には停止メンテが必要、AWSにベンダーロックインされる、といった課題は依然として存在する。

これらの課題を解決するために、現在は次世代システムの技術候補としてAurora Serverless v2とTiDBを検討しているという。Aurora Serverless v2はインスタンスとCPU、メモリのスケールアップ・ダウンが自動かつ一瞬で行われるため、ゲームの急激なリクエストの変化にも対応できる。ただ、既存のAuroraよりコストが高いといった問題がある。

TiDBについて。TiDBはMySQLと互換性のあるクラウドネイティブなデータベースだ。データはキーバリューで保存されるためshard統合が不要で、クラスターの台数を自由に入れ替えられるため、故障対応の自動化もできる見込みだ。

セッション動画

QCD（クオリティ、コスト、デリバリー）のどれを優先すべきか？どれも重要なのだが、現状は様々理由から並行してどれも取ることはそれほど容易ではない。IT基盤部の李氏はこのセッションで、DeNAのQCDコントロールの考え方とライブコミュニケーションアプリ「Pococha」におけるQCDコントロールの実践例を解説した。

インフラ観点のQCDコントロールとは、合意した品質（Q）、予算（C）、納期（D）を守り、インフラ環境を構築/運用し安定した環境を提供することを意味する。Q&Dを追求する場合は安全性の高い環境の上に早くユーザーへのサービス提供が可能となるが、コストが高まるデメリットがある。当然そのコストに対して投資するべきかどうか判断する必要はあるが、必ずしもネガティブな要素ではない。一方、Q&Cは一見良さそうに見えるが、クオリティの高い環境を安く提供するのに年単位の時間を要するとなると、許容されない可能性も高いだろう。 最後のD&Cでは、クオリティは保証されていない。それではいくら納期を早め、コストを安く維持できたとしても意味がない。李氏は「事業状況に応じてQCDの優先順位は変化するが、スモールスタートのサービスやスタートアップベンチャーにとっては、Q&Dを優先しつつ、適宜コスト削減に取り組むのが理想の進め方だ」と言う。

QCDコントロールの実践例として、李氏はライブコミュニケーションアプリ「Pococha」における取り組みを紹介した。「Pococha」は2017年にスタートし、開発当初は予算1000万円、開発エンジニア2名、リリースまで3ヶ月という迫った状況だった。リリース初期に取ったのは、基盤はAWSで担保しつつ、運用は人力で賄い、とにかく機能開発に注力するというデリバリー優先の方針だった。その結果サービス全体で急成長を成し遂げ、2021年6月末時点ですでに290万ダウンロードを突破するほど人気のサービスとなった。

しかし一方で、急速な成長に伴い、インフラ環境ではアーキテクチャ、性能管理、定常運用の方面で構築・運用の限界を迎えていた。アーキテクチャではVPC/SubnetのCIDR不足、データベース接続が永続できない、スケールアウトが遅い、障害発生後のフローが整備できていないといった問題が発生していた。性能管理においてはメトリクスや監視が不十分、全テーブルが単一のクラスターに載ってしまい、スケールしにくくピーク時は障害が起きやすい。定常運用においては非効率な手動オペレーション、障害対応時のフロー未整備など様々なインフラ課題を抱えていた。

現状を改善し開発チームに開発に集中してもらえるように、インフラをDeNA社内のインフラ専門部署に委任するなど、ロール変更による改善を図った。李氏はこのインフラ専門部署の所属している。

インフラ専門部署の介入による改善は2つのフェーズにわたって進められた。最初のフェーズではハイクオリティとファーストデリバリーを追求し、インフラの安定化とスケーラビリティーの向上を図った。まず単一だったAurora Cluster構成を改善して、データベースの垂直分割と水平分割を行った。垂直分割ではテーブル単位、水平分割ではレコード単位の分割を実施し、データベースの負荷軽減に成功した。

また、EC2で構成されたAPIサーバーでは、Autoscalingによるスケールの際にプロビジョニングの成功有無が追えない、スケールが遅いという2つの課題に対して改善に取り組んだ。具体的には、従来ローカルでユーザーデータを使ってプロビジョニングを行っていたところから、ライフサイクルフックを用いてプロビジョニング管理部を外部に切り出すことで、プロビジョニングの安定化を図った。

さらに、スケールアウトのリードタイムを短縮するために、インスタンスを作成するためのテンプレートを常に最新化し、更新がある場合のみデプロイを実行させることで、プロビジョニングプロセスの効率化に成功した。重たい処理が行われるサーバーをグループ化しまとめて実行することで、デプロイロックによって生じたタイムロスを削減した。こういった施策によって、トータルで80％のスピードアップを実現した。

なおこの段階では、インフラのプロビジョニングにTerraformを用いることで、複数のリソースに対して1つのtfファイルを使いまわすことができ、素早いデリバリーやセットアップの一貫性を保つことにも寄与した。GitHubコード管理で履歴が残るため、信頼性向上もつながった。さらに、「Pococha」のグローバル展開を見据えて配信基盤の移行も行った。スケーラビリティーの確保の運用工数の削減をより効率的に図るために、これまでのIDCF/AWSクラウド基盤（wowza）からAmazon IVSにマネージド移行した。スケラビリティーコストは倍増したがクオリティとデリバリーを優先して投資判断となったという。

次のフェーズでは徹底的にコスト削減に取り組んだ。ステートレス系統においてスポット率100％を目指して、スポットインスタンスを活用した。EC2 Autoscaling Groupを使用しているため、スポット比率を変更し利用することは簡単だ。しかし、スポット利用によって起こってしまうサービスの不安定、障害対応などオペレーションコストの増大は抑えなければならない。スポットインスタンスに関しては、安定的な運用を図るため、Autoscaling Group のRebalance機能を用いたスポットキャパシティ管理、スポット起動失敗時はOndemandBaseCapacityを増加し台数維持、スポット中断通知による撤退はEventBridgeを活用することで実現した。

李氏は「事業の状況に応じてQCDの優先順位やバランスを決めることが重要です。今後はグローバル展開を支えるアーキテクチャの模索や新規サービスのリリースを支援しながら、QCDコントロールの継続を進めていきます」と話す。

セッション動画

関連リンク
DeNA Engineering

文：加山恵美