Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

DeNA_Tech
March 02, 2023

サーバーサイドの開発言語を 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/

DeNA_Tech

March 02, 2023
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. アジェンダ 本日お話しすること • 前編 (飯塚) ◦ Go ポーティングを行おうとした経緯 ◦ Go

    を採用した経緯 ◦ Go 未経験者が Go を使用してみた感想 ◦ ポーティングしたことのメリット • 後編 (江口) ◦ C# から Go へコードのポーティングの進め方 ◦ 本番環境での C# から Goへの切り替え方 ◦ Go を採用したことによるメリット 2
  2. 自己紹介 飯塚 直亮 (Naoaki Iizuka) IRIAM事業部 エンジニアリング部 エンジニアリング第一グループ • 2016

    年ソーシャルゲーム会社に新卒入社 ◦ ブラウザゲームのサーバーサイド担当 • 2019 年に IRIAM に入社 ◦ アプリのサーバーサイド担当 ◦ 2022 年から GL に就任 ◦ 現在はアプリや管理画面開発、マネジメント業務関連に従事 経歴 その他 3 • 一番好きなしらすは「ゆきんこしらす」(写真のやつ)
  3. アプリケーションコードを網羅的に理解できるメンバーが不在 • コードの属人化 ◦ 現存メンバーが触ったことないコードが存在 ◦ 設計思想が闇の底 • その結果、気軽にコード変更ができない ◦

    コードの関連性を理解できていないのでコア実装を変えられない ◦ 機能追加などに多大なコストがかかる ◦ 設計レベルから改修を行えない 7
  4. • 設計ベースからサービスを作れる ◦ 0 からの作り直しが発生するので必要不可欠 • キャッチアップのアンテナ ◦ 言語のバージョンアップに対してアンテナを張れた •

    ティーチングの体制 ◦ プルリクエストでコードレベルを上げられる ◦ 未経験者が多い中で、みんなで学習していくという体制が作れた ◦ 技術選定に対して適切な議論が行える 社内に有識者が居た 13
  5. Go を採用した経緯 16 「社内に有識者が居た」 • GCP のサービスとの相性が良かった • 後述するポーティング後を考えた時に Go

    を採用した方がメリットがあった • 設計から実装まで整理し直せるメンバーが居た • Go 未経験のメンバーに対してティーチングできる体制できた 「ポーティング後の未来との相性がよかった」 • Go を勉強するというモチベーションと環境があった • なんだかんだポーティングする上でここが重要だったかも 「メンバーのモチベーションが高かった」
  6. ポーティング前のメンバーのステータス 18 iizuka • C#, PHP でゲームのバックエンド開発を行なっていた • Go 触ってみたいけど機会がなかった

    • C# でゲームのバックエンド開発を行なってた • Go…?あぁ、マスコットが可愛い言語だね! サーバーエンジニア A • C# でゲームのバックエンド開発を行なってた • Go という名前は知ってたぐらい サーバーエンジニア B
  7. 実際に Go を触ってみての所感 22 • 言語仕様がシンプル ◦ A Tour of

    Go やれば大まかコードが読める ◦ 一つの実装の仕方に複数パターン記法が存在しない ◦ 誰が書いても同じコードになる • 動かしやすい ◦ 環境構築がラクラク ◦ サクッと試せるのがコスト安くて good • 便利標準ライブラリが少ない印象 ◦ LINQ みたいな便利標準ライブラリがない
  8. 自己紹介 江口 達郎 (Tatsuro Eguchi) IRIAM事業部 エンジニアリング部 エンジニアリング第一グループ • 大手SI会社を経てスマートフォン向けゲーム業界に転職

    • 新しい分野に挑戦したいと考え2020年よりライブ配信プラット フォームのIRIAMに入社 • 現在はIRIAMでサーバーサイドの負債返済や配信周りのシステム 設計・実装に従事 経歴 26
  9. APIサーバー Google Kubernetes Engine Go ポーティングプロジェクトについて IRIAM のインフラ構成 27 配信サーバー

    Compute Engine バッチサーバー Compute Engine Cloud DNS Cloud Load Balancing Cloud SQL Memorystore
  10. APIサーバー Google Kubernetes Engine Go ポーティングプロジェクトについて C# から Go への置き換え対象

    28 配信サーバー Compute Engine バッチサーバー Compute Engine Cloud DNS Cloud Load Balancing Cloud SQL Memorystore Goへの置き換え対象
  11. 大まかなスケジュール 29 Go ポーティングプロジェクトについて 2020年10月 2022年7月 Web API Go化に着手 Web

    API置き換え完了 2023年1月 バッチ置き換え完了 2022年3月 Web API ポーティング完了 バッチ Go化に着手 2022年10月 バッチ ポーティング完了 12月 Web API Go側へ置き換え開始 明確な完了期限は切らずにとにかくポーティングを終わらせる
  12. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • サーバーメンバー数人で頑張る • APIサーバーを作る足がかりから着手 ◦

    C#固有の機能 (DateTime.Ticksなど) のGo化 ◦ ユーザー認証機能などのミドルウェア層のGo化 37 まずはポーティングのための足固めを行った
  13. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • ポーティング専属のメンバーを配置 ◦ ポーティングを行うAPIが150近くありバッチも数十件あり膨大 ◦

    ポーティング関連の作業だけを行う • メンバーが増えてポーティングのプルリクが大量に積まれる ◦ レビューがたまる ◦ レビューだけを行うメンバーを配置 38 ポーティングのためのリソースを大幅に割いた
  14. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • ポーティングを進める管理者をおいた ◦ ポーティングするAPIの割り当て管理 ◦

    レビューまで完了したAPIのデバッグ依頼 ◦ 開発デプロイ、本番デプロイなどのポーティング状態管理 39 ポーティング専属人数が最大で5人くらいいたのでしっかり管理
  15. C# から Go へのポーティングの進め方 最初期〜初期〜中期〜後期 • ポーティングするものの割り当て方を工夫 ◦ なるべく機能的に遠いものを順次割り当てるようにした ▪

    DBアクセスのコードを重複してポーティングしてしまわないように ◦ 開発中の機能に関わりそうなAPIのポーティングは避ける ▪ 開発は継続して行われている ▪ ポーティング+機能追加の形にした 41 なるべく無駄な割り当てが出ないように細かく管理
  16. 本番環境での 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
  17. Go 版のバッチサーバー C# 版のバッチサーバー 本番環境での Go への切り替え (バッチ編) バッチに関してはC#からGoに置き換えるタイミングで実装方法を見直した 47

    バッチサーバー Compute Engine dll バッチサーバー Cloud Run HTTPサーバー Cloud Scheduler cron • バッチサーバーが固定インスタンスだったので増強が難しい • 定期実行の失敗・成功などがGCP管理画面上でわかるようになった
  18. 本番環境での Go への切り替え (バッチ編) 1. Goのコードをデプロイ 2. バッチサーバーのcronを停止(C#) 3. Cloud

    Scheduler を設定(Go) 48 ◦ 毎分動作するバッチ: メンテナンス中に切り替え ◦ 上記以外: バッチが動作する間の時間に切り替え 置き換えルール C#→ Goへの切り替え方
  19. 切り替え完了、その先へ 53 • 将来的には HTTP/1.1 でのリクエストから gRPC へ • ①

    の対応はこの前哨戦的な位置付け pb化 gRPC化 • APIを改修するタイミングでリクエスト、レスポンスの形式を変更 • JSONでのデータのやり取りから pb でデータをやりとりするように ① HTTP/1.1 + JSON → HTTP/1.1+ Protocol Buffers へ ② HTTP/1.1 + pb → gRPC へ
  20. まとめ 55 「C#からGoへ開発言語を置き換えたメリットは大きかった」 • 専用の工数を割り当てても長期プロジェクトになることは覚悟する必要がある • 長期プロジェクトになるので最後は「気合い」 • 単体テストとデバッグをしっかり行ったので障害はほとんどなかった •

    問題があった際もすぐに切り戻せるようにしておいた • シンプルな言語なのでC#からの移行は難しくなかった • エンジニア採用面でのメリットも大きかった 「IRIAMの全API、バッチをGoに置き換えるには2年以上かかった」 「少しずつ切り替えていく」
  21. 56