リアーキテクチャに伴うサービスの無停止切り替え事例の紹介

リアーキテクチャに伴うサービスの無停止切り替え事例の紹介株式会社ジーニー小河原優貴

小河原優貴 Webチャットサービスの開発チームマネージャー経歴：ジーニー→メルカリ→フリーランス→ジーニー自己紹介こ　がわら　　　ゆうき @warawara28 kgwryk28

• 事例1: 管理画面のリプレース • 事例2: メッセージ配信基盤のリアーキテクチャ目次

事例1: 管理画面のリプレース

管理画面のリプレース：構成変更前の構成 SPA + REST API 構成 Routing SPA (React)
REST API (Python/Django)

管理画面のリプレース：課題 1. ライブラリの全面刷新が必要 2. 技術負債が多く、機能開発の工数が増大例・UIで使用しているテンプレート、シナリオ画面のライブラリを変更したい・新機能開発をする際に既存機能、ライブラリが流用できない・脆弱性対応のため、問題のあるライブラリのバージョンアップが必要・開発環境で使用するパッケージを変更して開発効率を上げたい
個別で対応した結果をまとめると、最終的には実質ほぼ作り直しリファクタで対応するか、全てを捨ててリプレースするのか半年悩んだ

管理画面のリプレース：方針 1. 開発スコープを絞る a. REST APIは変更せず、SPAのみリプレースする。 b. 技術スタックはTypeScript/Reactをそのまま使用。 c. 移行中はUIのレイアウトを変更しない
2. 半年以上かけた段階的な移行 a. 既存ユーザーに配慮して周知・共有を行いながら、トラブル防止のため段階的な移行を行う 3. 移行中も機能開発は継続 a. 新機能は新管理画面に実装。旧管理画面の追加の機能開発は行わずコードフリーズした旧管理画面を稼働しながら、新管理画面にリプレースする決定方針

管理画面のリプレース：移行の流れ移行の流れ 1. 新管理画面をリリースバージョニング+パスルーティングで振分 Routing 旧SPA REST API 新SPA
/v2/* /v1/* /v1/api/*

管理画面のリプレース：移行の流れ移行の流れ 2. 新旧管理画面の遷移リンクを追加（両方の画面を使えるようにする）その後デフォルトの画面を新SPAに変更（ログイン後は新SPAが表示される） Routing 旧SPA REST
API 新SPA /v2/* /v1/* /v1/api/* 旧SPAへのリンク新SPAへのリンク

管理画面のリプレース：移行の流れ移行の流れ 3. 遷移リンクを削除後、旧管理画面へのルーティングを削除（サービスアウト） Routing REST API 新SPA
/v2/* /v1/api/* 旧SPAを削除リンクを削除

事例紹介(管理画面) AFTER BEFORE

管理画面のリプレース：成果 AFTER BEFORE 開発環境パッケージ数：2366 モジュールハンドラ：webpack ローカル起動時間：30s ホットリロード：20s ビルド時間：53s 開発環境
パッケージ数：518 -78%! モジュールハンドラ：vite ローカル起動時間：~1s 30倍~! ホットリロード：~1s 20倍~! ビルド時間：17s 3.1倍!

管理画面のリプレース：成果 AFTER BEFORE 機能開発リードタイム（平均）：0.7ヶ月 -46%! チケット消化数（平均）：16個 1.6倍! 機能開発リードタイム（平均）：1.3ヶ月
チケット消化数（平均）：10個

事例2: メッセージ配信基盤のリアーキテクチャ

変更前のアーキテクチャ

変更後のアーキテクチャ

管理画面のリプレース：構成バックエンドで処理されたメッセージが配信キューに送信配信キューから配信サーバーがメッセージを取得してクライアントに配信 (WebSocketによる双方向通信で実現) 処理ワーカー配信サーバークライアント roomid: aaa クライアント
roomid: bbb 配信サーバー処理ワーカー roomid: aaaに送信するメッセージ roomid: bbbに送信するメッセージ roomid: bbbのメッセージは捨てる roomid: aaaのメッセージは捨てる配信キュー

メッセージ配信基盤：課題 1. 配信サーバーのスケーラビリティが低い問題 a. 全体のメッセージ処理負荷をサーバー毎に分散できないメッセージ処理負荷が増えても、スケーリングしやすい設計にしたい

管理画面のリプレース：方針配信サーバーがルーム単位でメッセージ取得できるようにする決定方針 1. 配信キューを Valkey(Redis)を利用した Pub/Subに置き換える a. 配信サーバーはクライアントの接続ルーム単位でチャネルをSubscribeする他のルームのメッセージを受信しなくて良くなる
2. 送信側でDouble Writeを利用、受信側は両方受信しながら切り替える a. デプロイ後のロールバックを考慮 3. 段階的なリリース

管理画面のリプレース：移行の流れ(1/6) 配信サーバーは配信キュー内の全てのメッセージを受信する。（クライアントに配信しないメッセージは無視） roomid: aaaに送信するメッセージ roomid: bbbに送信するメッセージ処理ワーカー配信サーバークライアント
roomid: aaa クライアント roomid: bbb 配信サーバー処理ワーカー roomid: bbbのメッセージは捨てる roomid: aaaのメッセージは捨てる配信キュー

管理画面のリプレース：移行の流れ(2/6) Valkey(Redis)を用意して、ワーカーはキューとValkey(Redis)に同一メッセージをDouble Write roomid: aaaに送信するメッセージ roomid: bbbに送信するメッセージ処理ワーカークライアント roomid:
aaa クライアント roomid: bbb 処理ワーカー roomid: bbbのメッセージは捨てる roomid: aaaのメッセージは捨てる配信サーバー配信サーバー Valkey(Redis) subscriberがいない場合捨てられる配信キュー

管理画面のリプレース：移行の流れ(3/6) 配信サーバーでValkey(Redis)に対してSubscribeを行い、メッセージを両方受信するようにする・Valkey(Redis)のメッセージ：受け取って捨てる・SQSのメッセージ：受け取って利用する or 別のルームのメッセージは捨てる roomid: aaaに送信するメッセージ
roomid: bbbに送信するメッセージ処理ワーカー配信サーバークライアント roomid: aaa クライアント roomid: bbb 配信キュー配信サーバー処理ワーカー roomid: bbbのメッセージは捨てる roomid: aaaのメッセージは捨てる Valkey(Redis) Valkey経由のメッセージも捨てる Valkey経由のメッセージも捨てる

管理画面のリプレース：移行の流れ(4/6) 配信サーバーでメッセージの受信元をキューからValkey(Redis) に切り替える・Valkey(Redis)のメッセージ：捨てる・SQSのメッセージ：利用する or 捨てる
roomid: aaaに送信するメッセージ roomid: bbbに送信するメッセージ処理ワーカー配信サーバークライアント roomid: aaa クライアント roomid: bbb 配信キュー配信サーバー処理ワーカー Valkey(Redis) SQS経由のメッセージは捨てる SQS経由のメッセージは捨てる

管理画面のリプレース：移行の流れ(5/6) 送信側でSNS/SQSに送信するのを停止する (SQSにメッセージが流れなくなる) roomid: aaaに送信するメッセージ roomid: bbbに送信するメッセージ処理ワーカー配信サーバークライアント
roomid: aaa クライアント roomid: bbb 配信キュー配信サーバー処理ワーカー Valkey(Redis)

管理画面のリプレース：移行の流れ(6/6) 配信キューを削除して切り替え完了 roomid: aaaに送信するメッセージ roomid: bbbに送信するメッセージ処理ワーカー配信サーバークライアント roomid:
aaa クライアント roomid: bbb 配信サーバー処理ワーカー Valkey(Redis)

事例紹介(メッセージ配信サーバーのCPU負荷) AFTER BEFORE

まとめ・既存仕様を把握、課題を明確化しておく・対処の選択肢を複数リストアップしてから判断するリファクタリングやコードの修正などで解決できないか？他の選択肢と投資対効果をしっかり比較する議論内容、比較軸の検討などはADRとして残しています・実施する場合、やらないことを決めておく社内過去事例として、リプレースが全ての問題を解決する魔法のプロジェクトになってしまい失敗したことがあります

ご清聴ありがとうございました

リアーキテクチャに伴うサービスの無停止切り替え事例の紹介

リアーキテクチャに伴うサービスの無停止切り替え事例の紹介

warawara28

Transcript