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
51
ミクシィの技術選定
北大のプログラミングサークルHUITの新歓で発表したものです
Genta Kamitani
April 30, 2021
Tweet
Share
More Decks by Genta Kamitani
See All by Genta Kamitani
ガチャを1から作り直した話 ─規模の拡大につれて開発速度を落とさないための取り組みについて─
genkami
7
4.4k
pt-query-digestをリアルタイムに取りたい!
genkami
0
180
モンスターストライクのリアルタイム通信を支える技術
genkami
8
11k
運用未経験の新卒がモンストのメンテに入るまでにやったこと
genkami
0
1.8k
Other Decks in Programming
See All in Programming
Modern Angular with Lightweight Stores: New Rules and Options
manfredsteyer
PRO
0
110
Unlocking Python's Core Magic
leew
0
130
Cloud Adoption Frameworkにみる組織とクラウド導入戦略(縮小版)
tomokusaba
1
230
もう実家に手頃な情シス娘は不要!Bedrockでもう一人の娘を作る
komakichi
0
120
2024-10-02 dev2next - Application Observability like you've never heard before
jonatan_ivanov
0
180
モジュラモノリス、その前に / Modular monolith, before that
euglena1215
8
720
perl for shell, awk and sed programmers
mackee
2
790
게임 개발하던 학생이이 세계에선 안드로이드 개발자?
pangmoo
0
110
[KR] Server Driven Compose With Firebase
skydoves
2
210
(Deep|Web) Link support with expo-router
mrtry
0
180
tsconfig.jsonの最近の新機能 ファイルパス編
uhyo
7
1.8k
The Efficiency Paradox and How to Save Yourself and the World
hollycummins
0
190
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
105
48k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
From Idea to $5000 a Month in 5 Months
shpigford
381
46k
What's in a price? How to price your products and services
michaelherold
243
11k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
4
120
Testing 201, or: Great Expectations
jmmastey
38
7k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
The Cult of Friendly URLs
andyhume
77
6k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
130k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.5k
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