大規模プラットフォームにおけるGoの利用例 DMM.go#4

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 15

Slide 15 text

© 2020 EXNOA LLC トップページ負荷試験のPod数 ● トップページのリプレイスをするにあたって負荷試験を行った ○ 1000rps耐えるPod数を明らかにする試験 ← 今回お話します ○ 平常時の推測である300rps〜600rpsの試験 ● 負荷のシナリオ（1000rps） ○ ウォームアップ：4分 ○ 最大負荷：14分 ○ クールダウン：2分 ● 1000rpsの定義 ○ 画面へのリクエストです 15

Slide 16

Slide 16 text

© 2020 EXNOA LLC 1Podのリソース Go製API 16 • requests: • cpu: 500m • memory: 512Mi • limits: • cpu: 1000m • memory: 1024Mi Next.js製Webサーバ • requests: • cpu: 1000m • memory: 512Mi • limits: • cpu: 2000m • memory: 1024Mi

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2020 EXNOA LLC 1000rpsの負荷試験をやってみて ● Go製APIは非常に安定していた ○ パフォーマンスチューニングは一切せずに済んだ ○ バイナリファイルを置くだけなので、スケールアウトも早い ● 最初にリクエストを受けるWebサーバはかなりPodが必要 ○ 性質上、スケールアウトに時間がかかってしまうのがネック ● BFFも複数のバックエンドに通信をする必要があるのでPodが必要 ○ キャッシュが非常に有効だった Podを並べておけばかなりの負荷に耐えられることがわかった 19

Slide 20

Slide 20 text

© 2020 EXNOA LLC 実際の運用時のPod数は？ ● 実際に1000rpsにいくことは非常に稀 ○ 社会現象レベルの大ヒットタイトルが出た瞬間くらい ○ それでも平常時に数百rpsは出る ● 日中→ピークタイム→深夜0時を上手く乗り越えられるか ○ 実際に運用して調整していく予定 ○ オートスケーリングで安定したままPodを増減させられる範囲を探っていく ● Podの起動スピードはかなり重要 ○ 早く起動ができるほど、急なスパイクに耐えることができる ○ Goはやはり相性が良さそうで、特に手間がかからなかった ○ Next.js製Webサーバの方はチューニングが必要そうである 20

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 2020 EXNOA LLC 前回お話したGoを使った開発（1/2） ● 言語として提供されるフォーマット ○ 複数人開発で、書き方での差分が出ないのでとても良い ● 言語として提供されるパッケージ管理 ○ Go Modules 便利 ● 後方互換性の高さ ○ ちゃんと互換性を持ったマイナーバージョンアップ ● 学習コストの低さ ○ Go自体を覚えるのはそう難しくない（と思う） ○ 難しいのは設計やアーキテクチャ、ドメイン分析… 23

Slide 24

Slide 24 text

© 2020 EXNOA LLC 実際に運用してどうだったか（1/2） ● 言語として提供されるフォーマット ○ SREとしてみるとすごい助かる ● 言語として提供されるパッケージ管理 ○ Go Modules 便利。パッケージの更新もしやすい ● 後方互換性の高さ ○ 非常に更新しやすい！ ○ 本番もちゃんと1.18になっています ● 学習コストの低さ ○ Goの書き方がわからないという質問を受けたことはなかった ○ 難しいのは設計やアーキテクチャ、ドメイン分析なのはやはりそうだった 24

Slide 25

Slide 25 text

© 2020 EXNOA LLC 前回お話したGoを使った開発（2/2） ○ 多種多様なアーキテクチャから選定しないといけない場合が増えた ■ メリットを享受できないのにフルスタックなフレームワークを使うと困る ○ RDB以外にもいろんなDBが使える時代 ■ Amazon DynamoDB, Cloud Spanner, etc. ○ 分散システムが（つらいけど）手軽に利用できる時代 ■ Amazon Kinesis, Apache Kafka, etc. ○ フロントエンドとバックエンドの分離 ■ バックエンドは単に永続層からデータを取ってフロントにデータを渡すだけにしたい 25

Slide 26

Slide 26 text

© 2020 EXNOA LLC 実際に運用してどうだったか（2/2） ○ 多種多様なアーキテクチャから選定しないといけない場合が増えた ■ フルスタックのフレームワークではなく、必要なGoパッケージをクリーンアーキテクチャでシンプルに使っていくことで、開発者の学習コストを下げられた ● SREをやってわかったが、他人のコーディング力を上げるのは難しすぎる ■ プロジェクトテンプレートが使いまわせ、様々なアーキテクチャに対応できた ■ BatchをGoで書いてKubernetesのCronJobで動かしたりもできた ○ RDB以外にもいろんなDBが使える時代 ○ 分散システムが（つらいけど）手軽に利用できる時代 ■ 実際に全文検索が強いものが欲しくなったりした ■ Redis Streamを使う検討を始めた ■ これもクリーンアーキテクチャで差し替えられる構造が役に立った ○ フロントエンドとバックエンドの分離 ■ バックエンドの言語としてGoを採用してメリットが多かった 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2020 EXNOA LLC まとめ（1/2） ● プラットフォームの特徴と負荷傾向 ○ ゲームという性質上、平常時の負荷とピーク時の差が激しい ○ スパイクもかなり激しい ○ ヒットタイトルが生まれることはチャンスだが同時にピンチでもある ● 最大1000rpsのトップページを捌くアーキテクチャ ○ バックエンドAPIの言語としてGoが存在 ○ オートスケーリングと相性の良いGoの特性 ○ その他、Kubernetes等のGoで作られたエコシステムに支えられている 28

Slide 29

Slide 29 text

© 2020 EXNOA LLC まとめ（2/2） ● バックエンドAPIの言語にGoを選択して良かったと思えた ○ それなりの開発規模で組織としてビジネスに対応していく必要がある現場でメリットがあると思う ■ シンプルなことを積み上げていくことで着実に成果を出す ○ 開発のレベルに差があるのは常なので、それをサポートできるかが肝 ■ CIでgolagci-lintを利用することで、品質を保つこともしている ● WebサービスはAPIだけでは成り立たない ○ フロントエンドが必要 ■ 画面を担うため、どうしても重くなりがち ○ だからこそ、安定かつ高速なバックエンドAPIが必要ともいえる 29

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 2020 EXNOA LLC 質問への回答（1/2） ● 標準パッケージしか使っていない？ ○ 3rd製パッケージも普通に使っています ○ 例：WebフレームワークとしてEchoを採用 ● Echoの採用理由ってある？（Ginとの比較とか） ○ 決定メンバーが詳しくて他と比べても内容に遜色はないので採用 ■ はっきり技術的な理由があるわけではない ○ Ginとは性能で比較したわけではない ■ Echoだとこんな感じで捌けたという一例だと思っていただければ ○ 非常にシンプルな使い方をしているので、困っていないという側面 ■ どういう構成なのかで選択するフレームワークも変わってくると思います 32

Slide 33

Slide 33 text

Slide 34

Slide 34 text