サーバーサイドの開発言語を C# から Go へ置き換えた道のり【DeNA TechCon 2023】

youtube：https://youtu.be/9HxfyGPcwGU

概要：
キャラライブアプリ IRIAM では、サービス開発当初 API サーバーとバッチ処理の実装にサーバーサイド C# を採用していました。現在サービスリリースから4年が経過しており、その間常に新しい機能を開発し続けてきました。そのためバックエンドで動作している API 数は100を軽く超える規模に成長しています。

日々新たな機能を開発する中で、今後の機能拡張やメンテナンス性を考慮して全ての API を Go に置き換える計画が社内で進行し、2年近くの歳月をかけて全ての API とバッチ処理の Go への置き換えに成功しました。

置き換え作業はほぼノーメンテナンスでサービスを止めることなく行われ、現在では全ての API とバッチ処理が Go 言語で実装されたものに置き換わっており、言語置き換えによる大きな障害も起きていません。

本セッションでは C# から Go へのポーティングの進め方や本番へのノーメンテナンスでのデプロイ方法、 Go 言語未経験者が Go 言語を使用してみた感想や言語置き換え時に苦労したこと、Go 言語を採用したことによるメリットなどを紹介します。

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

Transcript

1. サーバーサイドの開発言語を C# から Go へ置き換えた道のり 株式会社IRIAM 江口 達郎　飯塚 直亮
2. アジェンダ 本日お話しすること • 前編 (飯塚) ◦ Go ポーティングを行おうとした経緯 ◦ Go を採用した経緯 ◦ Go 未経験者が Go を使用してみた感想 ◦ ポーティングしたことのメリット • 後編 (江口) ◦ C# から Go へコードのポーティングの進め方 ◦ 本番環境での C# から Goへの切り替え方 ◦ Go を採用したことによるメリット 2
3. 自己紹介 飯塚 直亮 (Naoaki Iizuka) IRIAM事業部 エンジニアリング部 エンジニアリング第一グループ • 2016 年ソーシャルゲーム会社に新卒入社 ◦ ブラウザゲームのサーバーサイド担当 • 2019 年に IRIAM に入社 ◦ アプリのサーバーサイド担当 ◦ 2022 年から GL に就任 ◦ 現在はアプリや管理画面開発、マネジメント業務関連に従事 経歴 その他 3 • 一番好きなしらすは「ゆきんこしらす」(写真のやつ)
4. IRIAMについて IRIAM（イリアム）は、スマホひとつで いつでも・どこでも「キャラクターのライブ配 信」を楽しめるアプリです。
5. 5 Go ポーティングを行おうとした経緯
6. Go ポーティングを行おうとした経緯 6 アプリケーションコードを網羅的に理解できるメンバーが不在 C# でサービスを成長させるためのメンバーが不在
7. アプリケーションコードを網羅的に理解できるメンバーが不在 • コードの属人化 ◦ 現存メンバーが触ったことないコードが存在 ◦ 設計思想が闇の底 • その結果、気軽にコード変更ができない ◦ コードの関連性を理解できていないのでコア実装を変えられない ◦ 機能追加などに多大なコストがかかる ◦ 設計レベルから改修を行えない 7
8. • 知見不足 ◦ 社内でなかなか知見が湧いてこない状況になってしまった ◦ ライブラリや言語バージョンのキャッチアップに疎くなってしまった ◦ コードの保守性を高められない • サービス規模を拡大できない ◦ サービスのフェーズに応じて臨機応変に対応できない C# でサービスを成長させるためのメンバーが不在 8
9. Go ポーティングを行おうとした経緯 9 「アプリケーションコードを網羅的に理解できるメンバーが不在」 • 知見不足 • サービス規模を拡大できない • コードの属人化 • 気軽にコード変更ができない 「C# でサービスを成長させるために必要なメンバーが不在」
10. ポーティングを行うことで…！！！ 10 アプリケーションコードを網羅的に理解できるメンバーが不在 • ポーティング先の言語の有識者が居るので知見共有が行われるはず！ • コードを再生成しているので将来リファクタリングしたい放題なはず！ • 全コードを読む必要があるのでどのコードでも少なくとも一人は理解者が生まれるはず！ • コード変更時に聞ける人が生まれるはず！ C# でサービスを成長させるために必要なメンバーが不在
11. 11 Go を採用した経緯
12. Go を採用した経緯 12 「社内に有識者が居た」 「ポーティング後の未来との相性がよかった」 「メンバーのモチベーションが高かった」
13. • 設計ベースからサービスを作れる ◦ 0 からの作り直しが発生するので必要不可欠 • キャッチアップのアンテナ ◦ 言語のバージョンアップに対してアンテナを張れた • ティーチングの体制 ◦ プルリクエストでコードレベルを上げられる ◦ 未経験者が多い中で、みんなで学習していくという体制が作れた ◦ 技術選定に対して適切な議論が行える 社内に有識者が居た 13
14. • GCP との相性 ◦ google 系のサービスを入れる時にハードルが低い ◦ 公式ライブラリが充実している • 今後採用していく技術との相性 ◦ 後述にあるので割愛 ポーティング後の未来との相性がよかった 14
15. • みんなで学習する ◦ わからないをしっかり共有して教え合う ◦ とにかくわからないことを恥じることはない • チーム文化が良かった ◦ 議論をして色々決めていく文化が ◦ 知見を一人のものにしないでみんなのものにする メンバーのモチベーションが高かった 15
16. Go を採用した経緯 16 「社内に有識者が居た」 • GCP のサービスとの相性が良かった • 後述するポーティング後を考えた時に Go を採用した方がメリットがあった • 設計から実装まで整理し直せるメンバーが居た • Go 未経験のメンバーに対してティーチングできる体制できた 「ポーティング後の未来との相性がよかった」 • Go を勉強するというモチベーションと環境があった • なんだかんだポーティングする上でここが重要だったかも 「メンバーのモチベーションが高かった」
17. 17 Go 未経験者が Go を触ってみて
18. ポーティング前のメンバーのステータス 18 iizuka • C#, PHP でゲームのバックエンド開発を行なっていた • Go 触ってみたいけど機会がなかった • C# でゲームのバックエンド開発を行なってた • Go…?あぁ、マスコットが可愛い言語だね！ サーバーエンジニア A • C# でゲームのバックエンド開発を行なってた • Go という名前は知ってたぐらい サーバーエンジニア B
19. みんながまずやったこと… 19
20. A Tour of Go 20
21. • 自分で書いたツールを Go で書き直してみる ◦ 身近なところで手を動かす • 他人のコードをレビューする ◦ 人のコードを読んで自分の意見を述べる ◦ 生まれた議論から学習する • とにかく有識者に聞く ◦ これはとても大事！ その他には 21
22. 実際に Go を触ってみての所感 22 • 言語仕様がシンプル ◦ A Tour of Go やれば大まかコードが読める ◦ 一つの実装の仕方に複数パターン記法が存在しない ◦ 誰が書いても同じコードになる • 動かしやすい ◦ 環境構築がラクラク ◦ サクッと試せるのがコスト安くて good • 便利標準ライブラリが少ない印象 ◦ LINQ みたいな便利標準ライブラリがない
23. 23 ポーティングを行ったメリット
24. ポーティングを行ったメリット 24 「コード文化を再制定できた」 • 言語のこだわりが減って幅が広がる • ただ熱量にはこだわって組織文化は崩さなかった • チーム内でポリシーを再制定 • linter と formatter の力を借りてさらに強化！ 「エンジニア採用の幅が広がった」
25. 25 Go ポーティングプロジェクトについて
26. 自己紹介 江口 達郎 (Tatsuro Eguchi) IRIAM事業部 エンジニアリング部 エンジニアリング第一グループ • 大手SI会社を経てスマートフォン向けゲーム業界に転職 • 新しい分野に挑戦したいと考え2020年よりライブ配信プラット フォームのIRIAMに入社 • 現在はIRIAMでサーバーサイドの負債返済や配信周りのシステム 設計・実装に従事 経歴 26
27. APIサーバー Google Kubernetes Engine Go ポーティングプロジェクトについて IRIAM のインフラ構成 27 配信サーバー Compute Engine バッチサーバー Compute Engine Cloud DNS Cloud Load Balancing Cloud SQL Memorystore
28. APIサーバー Google Kubernetes Engine Go ポーティングプロジェクトについて C# から Go への置き換え対象 28 配信サーバー Compute Engine バッチサーバー Compute Engine Cloud DNS Cloud Load Balancing Cloud SQL Memorystore Goへの置き換え対象
29. 大まかなスケジュール 29 Go ポーティングプロジェクトについて 2020年10月 2022年7月 Web API Go化に着手 Web API置き換え完了 2023年1月 バッチ置き換え完了 2022年3月 Web API ポーティング完了 バッチ Go化に着手 2022年10月 バッチ ポーティング完了 12月 Web API Go側へ置き換え開始 明確な完了期限は切らずにとにかくポーティングを終わらせる
30. 30 C# から Go への置き換えにあたってのルール
31. C# から Go への置き換えにあたってのルール 31 • リファクタは極力しない 忠実に挙動をGoに置き換えるためにリファクタせずにポーティングす る。レビューする際にも比較しやすく • クライアントに迷惑をかけない リクエストやレスポンスの内容、APIで処理する内容を一切変えない
32. C# から Go への置き換えにあたってのルール 32 • 機能開発は継続して行う IRIAMの新機能や既存機能の改修は止めずに継続して行う • テストをしっかり書く ポーティングが正しくできていることを確認するためにもテストを しっかり書くことをルールづけた
33. 33 C# から Go への置き換えの準備
34. C# から Go への置き換えの準備 34 本番環境で呼ばれているAPIを列挙 ⇦ DBに入っているアクセスログから列挙 調査の結果 150 APIほどあった
35. C# から Go への置き換えの準備 35 クライアントチームで各APIを調査して追記 呼んでいるAPIパス 呼んでいる画面や タイミング 呼んでいる目的
36. 36 C# から Go へのポーティングの進め方
37. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • サーバーメンバー数人で頑張る • APIサーバーを作る足がかりから着手 ◦ C#固有の機能 (DateTime.Ticksなど) のGo化 ◦ ユーザー認証機能などのミドルウェア層のGo化 37 まずはポーティングのための足固めを行った
38. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • ポーティング専属のメンバーを配置 ◦ ポーティングを行うAPIが150近くありバッチも数十件あり膨大 ◦ ポーティング関連の作業だけを行う • メンバーが増えてポーティングのプルリクが大量に積まれる ◦ レビューがたまる ◦ レビューだけを行うメンバーを配置 38 ポーティングのためのリソースを大幅に割いた
39. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • ポーティングを進める管理者をおいた ◦ ポーティングするAPIの割り当て管理 ◦ レビューまで完了したAPIのデバッグ依頼 ◦ 開発デプロイ、本番デプロイなどのポーティング状態管理 39 ポーティング専属人数が最大で5人くらいいたのでしっかり管理
40. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 割り当て管理はNotionで実施 40 進行状況一覧
41. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • ポーティングするものの割り当て方を工夫 ◦ なるべく機能的に遠いものを順次割り当てるようにした ▪ DBアクセスのコードを重複してポーティングしてしまわないように ◦ 開発中の機能に関わりそうなAPIのポーティングは避ける ▪ 開発は継続して行われている ▪ ポーティング+機能追加の形にした 41 なるべく無駄な割り当てが出ないように細かく管理
42. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • ポーティングが終わるのか不安になる 42 最後は 気合い と 根性
43. 43 本番環境での Go への切り替え
44. 本番環境での Go への切り替え (API編) C# と Go のどちらにルーティングするかを決める NGINX を中間に置いた 44 C# APIサーバー Google Kubernetes Engine 配信サーバー Compute Engine Cloud DNS Cloud Load Balancing Cloud SQL Memorystore Go APIサーバー Google Kubernetes Engine ルーティング用に新設 NGINX
45. 45 • サービスは止めず、運用したままで切り替わる 利用者が少ない昼間の時間帯に切り替える • ルーティングを切り替えるだけで Go 側にリクエストが行く 挙動がおかしいなどを観測したら、ルーティングを戻すだけで切り戻し完了 本番環境での Go への切り替え (API編) • APIの切り替えは少しずつ行う 一気に切り替えると影響範囲が読めなくなる。ゆっくり確実に切り替える。
46. • 本番APIの切り替え時にアナウンス Slackの全体チャンネルで報告。おかしな挙動がないかチェックしてもらう意味も • 大きいAPIはメンテナンス中に切り替える ギフト送信APIなどは問題が発生した際の影響が大きい。メンテ中に最終チェックを行った 46 本番環境での Go への切り替え (API編) ↑ このような感じで全体に周知
47. Go 版のバッチサーバー C# 版のバッチサーバー 本番環境での Go への切り替え (バッチ編) バッチに関してはC#からGoに置き換えるタイミングで実装方法を見直した 47 バッチサーバー Compute Engine dll バッチサーバー Cloud Run HTTPサーバー Cloud Scheduler cron • バッチサーバーが固定インスタンスだったので増強が難しい • 定期実行の失敗・成功などがGCP管理画面上でわかるようになった
48. 本番環境での Go への切り替え (バッチ編) 1. Goのコードをデプロイ 2. バッチサーバーのcronを停止(C#) 3. Cloud Scheduler を設定(Go) 48 ◦ 毎分動作するバッチ: メンテナンス中に切り替え ◦ 上記以外: バッチが動作する間の時間に切り替え 置き換えルール C#→ Goへの切り替え方
49. 49 切り替えにより生まれたメリット
50. 切り替えにより生まれたメリット 50 • Web APIの応答速度はそこまで変わらなかった Goになったからと言って早くはならなかった • C#からGoに切り替えたことによる性能劣化はなかった 切り替え前に負荷試験を実施。負荷試験は Locust + boomer で実施 • CI/CD の導入が進んだ GitHub Actionsでの自動テスト、自動ビルド、自動デプロイ化が進み楽に
51. 切り替えにより生まれたメリット 51 • テストを書く文化が定着した 全体のカバレッジは55%程度だが、C#時代のほぼ0%からは大幅なカバレッジ向上 • 未使用のコード・APIが無くなった ポーティング時点で使われているコードのみをGoに置き換えたのでスリムになった 開発者体験は大幅に向上した
52. 52 切り替え完了、その先へ
53. 切り替え完了、その先へ 53 • 将来的には HTTP/1.1 でのリクエストから gRPC へ • ① の対応はこの前哨戦的な位置付け pb化 gRPC化 • APIを改修するタイミングでリクエスト、レスポンスの形式を変更 • JSONでのデータのやり取りから pb でデータをやりとりするように ① HTTP/1.1 + JSON → HTTP/1.1+ Protocol Buffers へ ② HTTP/1.1 + pb → gRPC へ
54. 54 まとめ
55. まとめ 55 「C#からGoへ開発言語を置き換えたメリットは大きかった」 • 専用の工数を割り当てても長期プロジェクトになることは覚悟する必要がある • 長期プロジェクトになるので最後は「気合い」 • 単体テストとデバッグをしっかり行ったので障害はほとんどなかった • 問題があった際もすぐに切り戻せるようにしておいた • シンプルな言語なのでC#からの移行は難しくなかった • エンジニア採用面でのメリットも大きかった 「IRIAMの全API、バッチをGoに置き換えるには2年以上かかった」 「少しずつ切り替えていく」