【Aiming】共通基盤なのに「共通化しない」課金・認証基盤「LINK」が選び取ったシングルテナント戦略と運用の秘訣

by sikeda

Embed

Start on current slide

Slide 1

Slide 1 text

共通基盤なのに「共通化しない」課⾦‧認証基盤「LINK」が選び取ったシングルテナント戦略と運⽤の秘訣

Slide 2

Slide 2 text

⽬次 ● ● ● ● ● ● ● 登壇者紹介‧会社紹介課⾦‧認証基盤「LINK」の紹介誕⽣と共通基盤への成⻑運⽤と苦難の歴史シングルテナントで得た価値今取り組んでいる課題まとめ

Slide 3

Slide 3 text

登壇者紹介講演者プロフィール 2004年よりゲーム業界にて主にモバイル向けタイトルの開発‧運営に従事。バンダイナムコスタジオではサーバーアーキテクト、テクニカルディレクターとして技術的品質を担う業務を経て、エンジニアリングマネージャーとして組織開発 ‧⼈材育成へと活動の幅を広げる。 2021年9⽉弁護⼠ドットコム株式会社に⼊社後は、電⼦契約サービス「クラウドサイン」の開発部⻑を務める傍ら、政府情報システムのためのセキュリティ評価制度（ISMAP）取得‧維持のための活動に従事。事業⽀援部シニアマネージャー井⽥浩義 2025年10⽉より株式会社Aimingに⼊社。特技は打ち上げ花⽕。

Slide 4

Slide 4 text

登壇者紹介講演者プロフィール 2011年株式会社Aiming⼊社。開発基盤、認証基盤、コミュニティサイト開発、ゲーム開発、マネージャーなど様々なプロジェクトを担当し、現在はエキスパート職として認証‧決済基盤の開発を担当。事業⽀援部シニアスペシャリスト堀井啓真

Slide 5

Slide 5 text

会社紹介

Slide 6

Slide 6 text

株式会社Aimingについて面白いをカタチに変える。社名：株式会社 Aiming 設立：2011年5月12日所在地：〒 151-0051 東京都渋谷区千駄ヶ谷五丁目 31-11住友不動産新宿南口ビル 5F 事業内容：オンラインゲーム開発・企画プロデュース・運営

Slide 7

Slide 7 text

株式会社Aimingについて Aimingの強み‧特徴従業員数：約700名市場：グロース市場上場ゲーム事業に特化した「開発⼒」ベンチャー気質の「挑戦‧スピード感」

Slide 8

Slide 8 text

開発実績剣と魔法のログレスいにしえの⼥神陰の実⼒者になりたくて！マスターオブガーデンドラゴンクエストタクト（スクウェア‧エニックス）

Slide 9

Slide 9 text

開発体制

Slide 10

Slide 10 text

使⽤している技術の紹介開発ツールゲームエンジン⾔語/フレームワーククラウドサービスデータベースコンテナ技術ネットワーク通信

Slide 11

Slide 11 text

イントロ

Slide 12

Slide 12 text

「共通基盤」といえば、ふつうは相乗り

Slide 13

Slide 13 text

相乗りモデルのメリットとデメリット ● メリット ○ ⼀つに集約するほど、コスト効率と⼀括運⽤が効く ○ ミドルウェア対応もセキュリティ対応も⼀度で全体反映できる ● デメリット ○ 全員が同じルール‧同じ更新‧同じ制約に従う ○ タイトルごとの個別の事情には応えにくい

Slide 14

Slide 14 text

しかし、Aimingの現実はバラバラだった ● タイトルごとに利⽤するクラウドが異なる ● 運⽤の途中で決済事業者の追加が起きる ● 運営移管（他社への委託‧受け⼊れ）の検討が⼊るステークホルダーの要望は、多岐にわたった…

Slide 15

Slide 15 text

単⼀の基盤では、価値を届けきれない

Slide 16

Slide 16 text

課⾦‧認証基盤「LINK」紹介

Slide 17

Slide 17 text

「LINK」とは定義した共通のルール‧フローで決済が⾏えるシステム

Slide 18

Slide 18 text

「LINK」導⼊⾃体のメリット ● ストア決済のトランザクションを LINK で管理できる ○ ○ 商品管理対応、決済のみなど、ストア特性に依存しないストアごとに異なるタイミングを⼀意に制御できる ● ストア決済のトランザクションの状況を LINK で確認できる ● ゲーム側でストア決済処理をコーディングする必要がなくなる

Slide 19

Slide 19 text

対応決済ストア etc...

Slide 20

Slide 20 text

「LINK」の技術スタック言語/フレームワークデータベースクラウドサービスコンテナ技術

Slide 21

Slide 21 text

「LINK」 SDK ゲームクライアントと LINK及び決済プラットフォームとの連携ツール各タイトルごとに課⾦決済処理を作ったり、決済事業者特有の処理を作ったりしなくて済むようになっている

Slide 22

Slide 22 text

「LINK」 SDK実態 Unity Package エディタ上でのimport

Slide 23

Slide 23 text

「LINK」 SDK実態

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

「LINK」サーバー構成図

Slide 26

Slide 26 text

「LINK」の歴史〜誕⽣と共通基盤への成⻑〜 ❏ ❏ ❏ ❏ 開発のきっかけ共通基盤化の壁運⽤の壁インフラ⾯の困難

Slide 27

Slide 27 text

開発のきっかけ

Slide 28

Slide 28 text

LINK誕⽣前は全て⾃前で実装していたタイトル内で個別に課⾦、認証を制作していた切り出して共通化する考えもなかった。

Slide 29

Slide 29 text

某タイトル開発がLINK誕⽣のきっかけ海外タイトルの国内運営のために、認証と課⾦処理のシステムとして実装課⾦と認証だけが作られており、切り出しやすい構造だった開発後、他タイトルチームから需要があり、だんだんと活⽤されるように。

Slide 30

Slide 30 text

評判の⼀⽅で…… なし崩し的なシステムの広まりに、現場では不安と危機感が⾼まる。

Slide 31

Slide 31 text

トップメッセージによる後押し

Slide 32

Slide 32 text

企業資産としてのシステムへエンジニアリーダーのメッセージから本格的に共通基盤化することに！

Slide 33

Slide 33 text

共通基盤化への壁

Slide 34

Slide 34 text

「共通化」を前にした現実新規機能が互換性に影響コスト問題運営中タイトルへの導⼊は困難縮退運営中のタイトルはアップデートコストがかけられないことも……。

Slide 35

Slide 35 text

「共通化しない」― これが私たちの開き直りシングルテナントで運⽤！

Slide 36

Slide 36 text

共通化への⽅針は定まったものの‥‥‥

Slide 37

Slide 37 text

「運⽤」の課題 ● 汎⽤機能にパブリッシャー側の制約が混⼊ ● 他タイトルの固有機能が混⼊

Slide 38

Slide 38 text

状況を打破するために

Slide 39

Slide 39 text

必要機能を選択可能にする、３つの戦略コードベースの統合フィーチャーフラグで必要機能を選択互換性のバージョン管理

Slide 40

Slide 40 text

コードベースの統合 ● まずは⼀つに統合する ● パブリッシャー制約は抽象度を⾼めて⼀般化して統合した ● タイトル固有機能も⼀定の汎⽤化を⾏った上で統合した

Slide 41

Slide 41 text

フィーチャーフラグの導⼊ ● 各タイトルで必要な機能をフィーチャーフラグで選択させるように ● 環境変数やビルドパラメータ、管理ツールでの切り替えなど、⽤途に応じて必要なパラメータを操作できるように

Slide 42

Slide 42 text

互換性のバージョン管理 ● セマンティックバージョニングを⽤いアップデートコストを可視化 ● タイトルがアップデートを⾏うかどうかを判断できるように

Slide 43

Slide 43 text

インフラ⾯の困難

Slide 44

Slide 44 text

従来の課題オンプレミス環境での不安定なインフラ構築

Slide 45

Slide 45 text

インフラのモダナイゼーションで解決！ IaC（Infrastructure as Code）やコンテナ化の普及により、安全かつ低コストな運⽤体制を実現

Slide 46

Slide 46 text

「LINK」をシングルテナントで運⽤するメリット ❏ ❏ ❏ ❏ ❏ 運⽤負荷分散ミドルウェア対応コスト減⾃社環境への円滑な合流セキュリティ診断も1度でOK 運⽤の柔軟性

Slide 47

Slide 47 text

シングルテナントモデルの採⽤で負荷分散

Slide 48

Slide 48 text

スパイクが発⽣しても、他のタイトルへ影響しない１つのシステムだと… シグナルテナント（LINK）スパイクが他タイトルへ及ぶ影響が隔離され、運⽤負荷も低い

Slide 49

Slide 49 text

ミドルウェアへの対応コスト減

Slide 50

Slide 50 text

ミドルウェアへの対応は⼀度で完了！各タイトルへの個別対応が不要に！

Slide 51

Slide 51 text

⾃社環境への円滑な合流

Slide 52

Slide 52 text

委託時は権限渡すのみでOK 委託時は権限を渡すだけ他タイトル情報へアクセスされる恐れがない

Slide 53

Slide 53 text

堅牢で安価なセキュリティ

Slide 54

Slide 54 text

無駄のないセキュリティ診断⼀度の診断で監査済みシステムを各タイトルへ適⽤できる！

Slide 55

Slide 55 text

タイトルの状況に合わせた、柔軟な対応

Slide 56

Slide 56 text

好調タイトルへの対応 ● 課⾦誘因施策の実装 ● 決済⼿段追加による利便性の向上 ● タイトル固有の要望対応アクティブな施策を積極的に導⼊！

Slide 57

Slide 57 text

縮退運営タイトルへの対応 ● コストをかけない運⽤ ● バージョンを積極的には上げない ● セキュリティリスクなど最⼩限の対応コストの最適化を図る

Slide 58

Slide 58 text

現在の取り組み更なる成⻑と進化のために ❏ 課⾦状態の⼀元管理化 ❏ 認証と課⾦の分離 ❏ チームの成⻑

Slide 59

Slide 59 text

「LINK」の、その先へ ― これからの全体像課⾦状態の⼀元管理で、サ認証と課⾦の分離で、複雑開発者体験そのものを担うポートコストを下げる性‧認知負荷を下げるプラットフォームエンジニアリングチームへ

Slide 60

Slide 60 text

課⾦状態の⼀元管理決済業者ごとに異なる状態管理を⼀元化し、サポートコストを軽減

Slide 61

Slide 61 text

認証と課⾦の分離それぞれの特性に合わせた最適化を可能にし、認知負荷を軽減

Slide 62

Slide 62 text

チームの成⻑ LINK以外にもCI/CDや分析基盤など、開発者体験向上を担うチームへ！

Slide 63

Slide 63 text

それでも、まだ道半ば ― 残る宿題 ● リアーキテクチャや分離は進⾏中― ⼀度に終わるものではない ● 取り組みの最中にも新たな要望や経営判断が⼊り、計画通りには進まない ● だからこそ、呼吸を乱さず進められる個別配布の構成が効いてくる

Slide 64

Slide 64 text

まとめ

Slide 65

Slide 65 text

共通化しない共通基盤の正体と価値要望の集約と個別配布選択的バージョンアップリスクまで共有しない各タイトルの要望を集約して作ることで分散を防ぎつつ、配布は個別にすることで⾃由度を上げている共通基盤の運⽤が各タイトルの運営の呼吸を乱さない共通基盤のメリットを資産として共有しながらも、各種リスクは分散している

Slide 66

Slide 66 text

もう⼀度設計しても、同じ構成を選ぶ ● 要望は集約しつつ、配布は個別に。この分離が効いた ● タイトルの状況に合わせ、運営の呼吸を乱さず運⽤できた ● メリットは資産として共有し、リスクは分散できた「共通化しない」という開き直りは、結果として正しかった