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
79
ミクシィの技術選定
北大のプログラミングサークル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
200
モンスターストライクのリアルタイム通信を支える技術
genkami
8
12k
運用未経験の新卒がモンストのメンテに入るまでにやったこと
genkami
0
2k
Other Decks in Programming
See All in Programming
💎 My RubyKaigi Effect in 2025: Top Ruby Companies 🌐
yasulab
PRO
1
130
漸進。
ssssota
0
1.2k
技術的負債と戦略的に戦わざるを得ない場合のオブザーバビリティ活用術 / Leveraging Observability When Strategically Dealing with Technical Debt
yoshiyoshifujii
0
160
Efficiency and Rock 'n’ Roll (Really!)
hollycummins
0
600
Devinで実践する!AIエージェントと協働する開発組織の作り方
masahiro_nishimi
6
2.6k
Javaに鉄道指向プログラミング (Railway Oriented Pro gramming) のエッセンスを取り入れる/Bringing the Essence of Railway-Oriented Programming to Java
cocet33000
1
130
Passkeys for Java Developers
ynojima
1
210
What Spring Developers Should Know About Jakarta EE
ivargrimstad
1
620
インターフェース設計のコツとツボ
togishima
2
490
複雑なフォームを継続的に開発していくための技術選定・設計・実装 #tskaigi / #tskaigi2025
izumin5210
12
6.4k
Language Server と喋ろう – TSKaigi 2025
pizzacat83
2
670
イベントストーミングから始めるドメイン駆動設計
jgeem
3
430
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
The Cult of Friendly URLs
andyhume
78
6.4k
GraphQLとの向き合い方2022年版
quramy
46
14k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Being A Developer After 40
akosma
91
590k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
For a Future-Friendly Web
brad_frost
178
9.7k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Site-Speed That Sticks
csswizardry
7
590
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
6
660
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
25
2.8k
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