ミクシィの技術選定

北大のプログラミングサークルHUITの新歓で発表したものです

Transcript

1. ミクシィの技術選定 神⾕ 元太 開発本部 CTO室 SREG
2. ⾃⼰紹介 • 神⾕ 元太 • やってること ◦ 〜2021 モンスターストライク ◦ 2021〜 新規事業 • 紋別出⾝
3. 技術選定
4. ⼤前提 他⼈の技術選定の話は ⼤してあてにならない
5. ⼤前提 その会社独⾃の(明⽰的 or 暗黙 的)前提に⼤きく依存するため
6. 今⽇話すこと • 技術選定とは何か • 技術選定をする上で、何を考えればよいのか • ミクシィの技術選定と、選定における前提 • もし前提が違えばどういう技術選定になっていたか
7. 技術選定とは
8. 技術選定とは 特定の制約条件下で、ある問題に対する解決策の⽅針を提供すること 「制約条件」 「問題」 「解決策」
9. 問題とは 今直⾯している、解決しないといけない課題のこと 「どんなサービスを作りたいか」とは必ずしも⼀致しない場合もある 技術選定を⾏うためには、まずは問題の性質を熟知しないといけない
10. 制約条件とは 問題の解決策に制限を与える様々な条件 例: • コスト • ⻑期運⽤できるか • 既存サービスとの相性 • うちのチームが適切に使えるか • etc.
11. 解決策とは • プログラミング⾔語 • ソフトウェア • クラウドサービス • 物理的な機械 • ワークフロー • ⼈⼿ • etc. 必ずしも技術によって解決することが最適解でない場合も無いとは⾔えない
12. 技術選定をする上で 考えること
13. 技術選定の流れ 1. 問題と制約条件を知る 2. 解決策の候補を探す 3. 候補の中から最適なものを決める 2以下はかなり具体的な問題に依存するので、今回は 問題と制約条件を知る上で重要な部分のみを説明。
14. 問題と制約条件を知る ここでやるべきことも、本当はかなり具体的な問題の内容による ここでは、そもそもWebサービス的なものを作ることが解決策になりそうな タイプの問題を前提とし、その場合共通して考えなければならないことを説明
15. データアクセスのパターン 多くのウェブサービスの場合、実現可能かどうかを判断するために最初に考え ないといけないのがここ 問題の性質として、具体的なサービスに限らず共通して⾔える限られたものの うちの⼀つ
16. 少数が書いて多数が読むパターン 8SJUF 3FBE
17. 多数が書いて少数が読むパターン 8SJUF 3FBE
18. 多数が読み書きするパターン 8SJUF 3FBE
19. サービスの地理的なスケール
20. サービスの地理的なスケール
21. 許される反映遅延の限界 ਺ेඵʙ਺෼ ਺ेNT
22. 解決策について 問題を分析し終わる頃には⾃ずと解決策はある程度候補が絞られれているはず。 個別の解決策を挙げるのは単純に固有名詞を列挙するだけになってしまう(し、 あんまり役に⽴たない)ので割愛。 以降では、解決策を選ぶ上で⼀般的に気をつけないといけない部分について説 明。
23. ⼤前提: ⽬の前にあるツールは本当に その問題を解くために作られている︖ ハンマーを持つとなんでも釘に⾒える問題 「⽬の前に慣れたツールがある」×「そのツールで問題が解決できそうであ る」という場合特に注意 ⽬の前の問題をよりシンプルに解決できるツールはないか常に考えていく必要 がある
24. 将来性はある︖ 今後も活発な開発が⾏われうるツールかどうか ただし、これを正しく判断するのは難しい(or不可能) ⼤まかには以下のようなものに気をつけるとよい • 現時点で開発が活発か • 現時点でより筋の良い代替案は出ていないか
25. 使おうとしている他のツールとの相性は︖ ツール単体で⾒てみるとよくても、他のツールと組み合わせたときに無理が⽣ じる可能性がある 弊社で実際におこった例: Elixir + GCP で開発していたところ Elixir に GCP まわりのライブラリが充 実しておらず、最初に Spanner クライアントを作り始めるところから始まっ た。 (※ 相性が悪い例として出しているが、これが必ずしも悪いことであるわけで はない)
26. チームとの相性は︖ 全く同じことができるツールが複数あれば慣れ親しんだやつのほうがベター ただし、慣れ親しんだツールを選んだが故に元々の問題をシンプルに解けなく なってしまっては本末転倒
27. コストパフォーマンスは︖ 会社としてWebサービスを提供する以上、⼤前提として⿊字を⾒込めないと いけない あるツールを導⼊して問題を解決できるようになったが、かわりに利益も出せ なくなってしまっては本末転倒 場合によっては多少不便だがかわりにコストの安いサービスを解決策として使 うという⼿段もありえる
28. 運⽤コストは︖ 特に何らかの作業の⾃動化、負荷軽減に関連するツールの選定で重要 (あるツールが軽減する負荷) < (そのツールをメンテするために発⽣する負 荷) になっていないか
29. 技術選定をする上での注意点 とはいえ、適当に選択肢を枝刈りしていかないと永遠に終わらない作業になっ てしまう
30. ミクシィの技術選定
31. 具体的な「ミクシィの技術選定」 例として、『モンスターストライク(以下モンスト)』の抱える問題と、その解 決策として⽣まれたアーキテクチャの変遷について解説する ※ 完璧にモンストの技術選定の変遷を表しているものではなく、説明しやす いように詳細は編集もしくは省略している
32. モンストの「問題」 ⼤前提: だいたい以下のような機能がほしい • ユーザー資産の取得、編集 ◦ ステータス、モンスター、アイテム等 • フレンドのステータスやプロフィール等の閲覧 • 位置情報によるマッチング おそらく開発初期にあったでろう暗黙の前提 • 超⼤ヒットすることは想定していない • 今ほどクラウドサービスは充実していない
33. 初期のアーキテクチャ -# "1* NFN DBDIFE .BSJB%#
34. 前提の変化 ⼈気爆発してユーザーが増えた︕︕ この時点での前提 • 超⼤ヒットすることは想定していない • ⼤量のユーザーを捌かないといけない • 今ほどクラウドサービスは充実していない • ⽔平スケール⾃体の⽅法論がそこまで成熟していない ◦ さらに、水平スケールするのは超大変 • クラスタリングなんてものも普及していない
35. 垂直分散 -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    #
36. リードレプリカ -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    # 38 .BSJB%#
    # 3
37. ⼀部処理を⾮同期実⾏ -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    # 38 .BSJB%#
    # 3 +PC
    2VFVF 3FEJT "TZOD 8PSLFS
38. ジョブキューの分散 -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    # 38 .BSJB%#
    # 3 +PC
    2VFVF 3FEJT "TZOD 8PSLFS +PC
    2VFVF 3FEJT ʜ
39. なんやかんやで⽔平分散 -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    # 38 .BSJB%#
    # 3 +PC
    2VFVF 3FEJT "TZOD 8PSLFS +PC
    2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
40. なんやかんやで⽔平分散 -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    # 38 .BSJB%#
    # 3 +PC
    2VFVF 3FEJT "TZOD 8PSLFS +PC
    2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
41. モンストのアーキテクチャの変遷 そうしてだいたい今の形にいたる
42. モンストの「問題」(初期) ⼤前提: だいたい以下のような機能がほしい • ユーザー資産の取得、編集 ◦ ステータス、モンスター、アイテム等 • フレンドのステータスやプロフィール等の閲覧 • 位置情報によるマッチング おそらく開発初期にあったでろう暗黙の前提 • 超⼤ヒットすることは想定していない • 今ほどクラウドサービスは充実していない
43. モンストの「問題」(中期〜) この時点での前提 • 超⼤ヒットすることは想定していない • ⼤量のユーザーを捌かないといけない • 今ほどクラウドサービスは充実していない • ⽔平スケール⾃体の⽅法論がそこまで成熟していない ◦ さらに、水平スケールするのは超大変 • クラスタリングなんてものも普及していない
44. 仮に前提が違ったら どうなっていたか
45. 仮定1: ⽔平スケールの⽅法論が確⽴していたら 仮定: もしこの時代に⽔平スケールが容易なDBがあったら 問題の性質への追記: • あるユーザーが他のユーザーのリソースにアクセスすることはまれ ◦ ↑水平スケールにより問題が解決しやすい • Writeが多く、書き込み前の古いデータを掴むことがクリティカルなバグ につながる ◦ ↑キャッシュによる負荷軽減により問題が解決しにくい
46. 現実のモンストの構成 -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    # 38 .BSJB%#
    # 3 +PC
    2VFVF 3FEJT "TZOD 8PSLFS +PC
    2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
47. IFの仮定でのモンストの構成 -# "1* %# %# %# ɾɾɾ %# $MPVE
    4QBOOFS :VHBCZUF%# $PDLSPBDI% # 5J%# FUD
48. 仮定2: 最⼩限のコストで運営 仮定: 最⼩限の初期コストで運営できるようにしつつ、万が⼀ヒットしたとき も耐えられるようにしたい リリースしたゲームがヒットするかどうかは博打的要素が⼤きい 以下のような場⾯でより重要度が⾼まる: • 多くのゲームを⾼頻度でリリースしている(ため、個々の費⽤はなるべく抑 えたい) • スタートアップ等で予算が限られている
49. 現実のモンストの構成 -# "1* NFN DBDIFE .BSJB%#
    " .BSJB%#
    # 38 .BSJB%#
    # 3 +PC
    2VFVF 3FEJT "TZOD 8PSLFS +PC
    2VFVF 3FEJT ʜ .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 6TFS .BSJB%# 4FRVFODFS
50. IFの仮定でのモンストの構成 "1* 'BB4 εέʔϥϒϧͳ /P42-౳ 'BB4 "84
    -BNCEB $MPVE
    'VODUJPOT FUD %# "NB[PO
    %ZOBNP%# $MPVE
    'JSFTUPSF FUD
51. おわりに
52. おわりに 技術選定はその会社の前提に強く依存 前提が少し変われば選定結果も変わる 問題と制約条件を詳しく知ることが、適切な技術選定への近道