Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ミクシィの技術選定
Search
Genta Kamitani
April 30, 2021
Programming
0
83
ミクシィの技術選定
北大のプログラミングサークルHUITの新歓で発表したものです
Genta Kamitani
April 30, 2021
Tweet
Share
More Decks by Genta Kamitani
See All by Genta Kamitani
ガチャを1から作り直した話 ─規模の拡大につれて開発速度を落とさないための取り組みについて─
genkami
7
4.6k
pt-query-digestをリアルタイムに取りたい!
genkami
0
210
モンスターストライクのリアルタイム通信を支える技術
genkami
8
12k
運用未経験の新卒がモンストのメンテに入るまでにやったこと
genkami
0
2k
Other Decks in Programming
See All in Programming
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
240
つよそうにふるまい、つよい成果を出すのなら、つよいのかもしれない
irof
1
300
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
200
統一感のある Go コードを生成 AI の力で手にいれる
otakakot
0
3k
Select API from Kotlin Coroutine
jmatsu
1
180
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
560
GoのGenericsによるslice操作との付き合い方
syumai
2
680
Go Modules: From Basics to Beyond / Go Modulesの基本とその先へ
kuro_kurorrr
0
120
複数アプリケーションを育てていくための共通化戦略
irof
10
4k
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
390
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
130
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
1
310
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
PRO
53
11k
Scaling GitHub
holman
459
140k
Balancing Empowerment & Direction
lara
1
340
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Being A Developer After 40
akosma
90
590k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
790
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Agile that works and the tools we love
rasmusluckow
329
21k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.9k
Thoughts on Productivity
jonyablonski
69
4.7k
Building an army of robots
kneath
306
45k
Building a Modern Day E-commerce SEO Strategy
aleyda
41
7.3k
Transcript
ミクシィの技術選定 神⾕ 元太 開発本部 CTO室 SREG
⾃⼰紹介 • 神⾕ 元太 • やってること ◦ 〜2021 モンスターストライク ◦
2021〜 新規事業 • 紋別出⾝
技術選定
⼤前提 他⼈の技術選定の話は ⼤してあてにならない
⼤前提 その会社独⾃の(明⽰的 or 暗黙 的)前提に⼤きく依存するため
今⽇話すこと • 技術選定とは何か • 技術選定をする上で、何を考えればよいのか • ミクシィの技術選定と、選定における前提 • もし前提が違えばどういう技術選定になっていたか
技術選定とは
技術選定とは 特定の制約条件下で、ある問題に対する解決策の⽅針を提供すること 「制約条件」 「問題」 「解決策」
問題とは 今直⾯している、解決しないといけない課題のこと 「どんなサービスを作りたいか」とは必ずしも⼀致しない場合もある 技術選定を⾏うためには、まずは問題の性質を熟知しないといけない
制約条件とは 問題の解決策に制限を与える様々な条件 例: • コスト • ⻑期運⽤できるか • 既存サービスとの相性 •
うちのチームが適切に使えるか • etc.
解決策とは • プログラミング⾔語 • ソフトウェア • クラウドサービス • 物理的な機械 •
ワークフロー • ⼈⼿ • etc. 必ずしも技術によって解決することが最適解でない場合も無いとは⾔えない
技術選定をする上で 考えること
技術選定の流れ 1. 問題と制約条件を知る 2. 解決策の候補を探す 3. 候補の中から最適なものを決める 2以下はかなり具体的な問題に依存するので、今回は 問題と制約条件を知る上で重要な部分のみを説明。
問題と制約条件を知る ここでやるべきことも、本当はかなり具体的な問題の内容による ここでは、そもそもWebサービス的なものを作ることが解決策になりそうな タイプの問題を前提とし、その場合共通して考えなければならないことを説明
データアクセスのパターン 多くのウェブサービスの場合、実現可能かどうかを判断するために最初に考え ないといけないのがここ 問題の性質として、具体的なサービスに限らず共通して⾔える限られたものの うちの⼀つ
少数が書いて多数が読むパターン 8SJUF 3FBE
多数が書いて少数が読むパターン 8SJUF 3FBE
多数が読み書きするパターン 8SJUF 3FBE
サービスの地理的なスケール
サービスの地理的なスケール
許される反映遅延の限界 ेඵʙ ेNT
解決策について 問題を分析し終わる頃には⾃ずと解決策はある程度候補が絞られれているはず。 個別の解決策を挙げるのは単純に固有名詞を列挙するだけになってしまう(し、 あんまり役に⽴たない)ので割愛。 以降では、解決策を選ぶ上で⼀般的に気をつけないといけない部分について説 明。
⼤前提: ⽬の前にあるツールは本当に その問題を解くために作られている︖ ハンマーを持つとなんでも釘に⾒える問題 「⽬の前に慣れたツールがある」×「そのツールで問題が解決できそうであ る」という場合特に注意 ⽬の前の問題をよりシンプルに解決できるツールはないか常に考えていく必要 がある
将来性はある︖ 今後も活発な開発が⾏われうるツールかどうか ただし、これを正しく判断するのは難しい(or不可能) ⼤まかには以下のようなものに気をつけるとよい • 現時点で開発が活発か • 現時点でより筋の良い代替案は出ていないか
使おうとしている他のツールとの相性は︖ ツール単体で⾒てみるとよくても、他のツールと組み合わせたときに無理が⽣ じる可能性がある 弊社で実際におこった例: Elixir + GCP で開発していたところ Elixir に
GCP まわりのライブラリが充 実しておらず、最初に Spanner クライアントを作り始めるところから始まっ た。 (※ 相性が悪い例として出しているが、これが必ずしも悪いことであるわけで はない)
チームとの相性は︖ 全く同じことができるツールが複数あれば慣れ親しんだやつのほうがベター ただし、慣れ親しんだツールを選んだが故に元々の問題をシンプルに解けなく なってしまっては本末転倒
コストパフォーマンスは︖ 会社としてWebサービスを提供する以上、⼤前提として⿊字を⾒込めないと いけない あるツールを導⼊して問題を解決できるようになったが、かわりに利益も出せ なくなってしまっては本末転倒 場合によっては多少不便だがかわりにコストの安いサービスを解決策として使 うという⼿段もありえる
運⽤コストは︖ 特に何らかの作業の⾃動化、負荷軽減に関連するツールの選定で重要 (あるツールが軽減する負荷) < (そのツールをメンテするために発⽣する負 荷) になっていないか
技術選定をする上での注意点 とはいえ、適当に選択肢を枝刈りしていかないと永遠に終わらない作業になっ てしまう
ミクシィの技術選定
具体的な「ミクシィの技術選定」 例として、『モンスターストライク(以下モンスト)』の抱える問題と、その解 決策として⽣まれたアーキテクチャの変遷について解説する ※ 完璧にモンストの技術選定の変遷を表しているものではなく、説明しやす いように詳細は編集もしくは省略している
モンストの「問題」 ⼤前提: だいたい以下のような機能がほしい • ユーザー資産の取得、編集 ◦ ステータス、モンスター、アイテム等 • フレンドのステータスやプロフィール等の閲覧 •
位置情報によるマッチング おそらく開発初期にあったでろう暗黙の前提 • 超⼤ヒットすることは想定していない • 今ほどクラウドサービスは充実していない
初期のアーキテクチャ -# "1* NFN DBDIFE .BSJB%#
前提の変化 ⼈気爆発してユーザーが増えた︕︕ この時点での前提 • 超⼤ヒットすることは想定していない • ⼤量のユーザーを捌かないといけない • 今ほどクラウドサービスは充実していない •
⽔平スケール⾃体の⽅法論がそこまで成熟していない ◦ さらに、水平スケールするのは超大変 • クラスタリングなんてものも普及していない
垂直分散 -# "1* NFN DBDIFE .BSJB%#" .BSJB%##
リードレプリカ -# "1* NFN DBDIFE .BSJB%#" .BSJB%## 38 .BSJB%## 3
⼀部処理を⾮同期実⾏ -# "1* NFN DBDIFE .BSJB%#" .BSJB%## 38 .BSJB%## 3
+PC2VFVF 3FEJT "TZOD 8PSLFS
ジョブキューの分散 -# "1* NFN DBDIFE .BSJB%#" .BSJB%## 38 .BSJB%## 3
+PC2VFVF 3FEJT "TZOD 8PSLFS +PC2VFVF 3FEJT ʜ
なんやかんやで⽔平分散 -# "1* NFN DBDIFE .BSJB%#" .BSJB%## 38 .BSJB%## 3
+PC2VFVF 3FEJT "TZOD 8PSLFS +PC2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
なんやかんやで⽔平分散 -# "1* NFN DBDIFE .BSJB%#" .BSJB%## 38 .BSJB%## 3
+PC2VFVF 3FEJT "TZOD 8PSLFS +PC2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
モンストのアーキテクチャの変遷 そうしてだいたい今の形にいたる
モンストの「問題」(初期) ⼤前提: だいたい以下のような機能がほしい • ユーザー資産の取得、編集 ◦ ステータス、モンスター、アイテム等 • フレンドのステータスやプロフィール等の閲覧 •
位置情報によるマッチング おそらく開発初期にあったでろう暗黙の前提 • 超⼤ヒットすることは想定していない • 今ほどクラウドサービスは充実していない
モンストの「問題」(中期〜) この時点での前提 • 超⼤ヒットすることは想定していない • ⼤量のユーザーを捌かないといけない • 今ほどクラウドサービスは充実していない • ⽔平スケール⾃体の⽅法論がそこまで成熟していない
◦ さらに、水平スケールするのは超大変 • クラスタリングなんてものも普及していない
仮に前提が違ったら どうなっていたか
仮定1: ⽔平スケールの⽅法論が確⽴していたら 仮定: もしこの時代に⽔平スケールが容易なDBがあったら 問題の性質への追記: • あるユーザーが他のユーザーのリソースにアクセスすることはまれ ◦ ↑水平スケールにより問題が解決しやすい •
Writeが多く、書き込み前の古いデータを掴むことがクリティカルなバグ につながる ◦ ↑キャッシュによる負荷軽減により問題が解決しにくい
現実のモンストの構成 -# "1* NFN DBDIFE .BSJB%#" .BSJB%## 38 .BSJB%## 3
+PC2VFVF 3FEJT "TZOD 8PSLFS +PC2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
IFの仮定でのモンストの構成 -# "1* %# %# %# ɾɾɾ %# $MPVE 4QBOOFS
:VHBCZUF%# $PDLSPBDI% # 5J%# FUD
仮定2: 最⼩限のコストで運営 仮定: 最⼩限の初期コストで運営できるようにしつつ、万が⼀ヒットしたとき も耐えられるようにしたい リリースしたゲームがヒットするかどうかは博打的要素が⼤きい 以下のような場⾯でより重要度が⾼まる: • 多くのゲームを⾼頻度でリリースしている(ため、個々の費⽤はなるべく抑 えたい)
• スタートアップ等で予算が限られている
現実のモンストの構成 -# "1* NFN DBDIFE .BSJB%#" .BSJB%## 38 .BSJB%## 3
+PC2VFVF 3FEJT "TZOD 8PSLFS +PC2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
IFの仮定でのモンストの構成 "1* 'BB4 εέʔϥϒϧͳ /P42- 'BB4 "84-BNCEB $MPVE'VODUJPOT FUD %#
"NB[PO %ZOBNP%# $MPVE'JSFTUPSF FUD
おわりに
おわりに 技術選定はその会社の前提に強く依存 前提が少し変われば選定結果も変わる 問題と制約条件を詳しく知ることが、適切な技術選定への近道
None