現状・課題
- ZOZOでは5年以上前からリプレイスプロジェクトが進行中で2017年から作成された参照系をあつめたマイクロサービスが存在する
- このマイクロサービスは過去の弊社社員のプレゼン資料にも書かれている通り、肥大化しておりモノリス化してしまっている
- 現状でも参照系のエンドポイントを増やすときはこのマイクロサービスに追加するかたちになっておリ、肥大化していた。
- 参照系マイクロサービスを作成したあとに作られた他のマイクロサービスへ移行が済んでいるのも関わらずエンドポイントが残ってしまっている。
- リクエストされていないエンドポイントが存在する
そもそものハナシ
マイクロサービスとは
協調して動作する小規模で自律的なサービス。
- 小さくかつ1つの役割に専念したもの
サービスの境界をビジネスの境界と合わせて特定の機能のコードがある場所を明確にする。
サービスの境界を明示化しておくことによって大規模になるのを防ぐようにする - 自律性
それぞれが独立して変更でき、コンシューマを変更する必要なく単独でデプロイできなくてはならない。
「他のなにも変更せずに単独でサービスの変更やデプロイを行えるか」
マイクロサービス化する主な利点
- 技術変異性
サービスごとに異なる技術やジョブごとに最適なツールを選択することができる - 回復性
サービス境界は明確な障壁となって障害の連鎖を防ぐ - スケーリング
必要なサービスに絞ってスケーリングすることができる - デプロイの容易性
独立したサービスのみを迅速にデプロイできるため顧客に新機能を提供することも迅速に可能
問題が起こった場合でも原因の特定もモノリシックシステムに比べて容易で、ロールバックも迅速に行うことができる - 交換可能にするための最適化
必要に応じてサービスを完全に書き直したりサービス自体の削除も容易になる
コードベースを数百行程度にすると開発者はサービスに対して愛着を持ちにくくなるので置き換えコストも低くなる。
モノリシックシステムとは
システムやソフトウェアが1つのモジュールでできており、分割されていない設計のこと
モノリシックシステムのメリット
- デプロイが簡単
- 1つのコードベースで構築すると開発が容易
- 外部モジュールを必要としない構造のためプロセス間での通信が発生しない。
モノリシックシステムのデメリット
- 大規模なモノリシックシステムは開発が複雑になり速度が低下する
- スケーリングが困難
- いずれかのモジュールにエラーが発生するとすべての可用性に影響する可能性がある
- テクノロジー導入の障壁が高い
- 微小な変更でもモノリシックシステム全体のデプロイが必要になる
洗い出し・調査
- 肥大化した参照系マイクロサービスのopenAPIからエンドポイントをスプレッドシートなどに洗い出し。
- 洗い出したエンドポイントの中で既存で同等の機能を持つマイクロサービスがあるか/すでに移行済みか洗い出し。
移行できると判断した場合はそのエンドポイントがサービスのどのページで呼ばれているのか・どんな用途でリクエストされているかなども合わせて記載しておく。 - エンドポイントを1つ1つ過去に呼び出された形跡があるかDatadogのデータを確認
- 過去に呼び出されていないエンドポイントをリクエストするASPなどのクライアント側のロジックが存在するか確認
存在する場合、なんの機能に使われているものかを記載しておく - リクエストされていない削除候補のエンドポイントを別シートなどにまとめてクライアント側のソースを管理するチームに確認してもらい、削除可能か判断してもらう。（全体の3割ほどが削除候補になった）
- 一部、まだ使われていないが今後使われる想定のものに関しては、使われるまではOpenAPIでdeprecatedを指定して非推奨としておきます。
- 今後使用する可能性もないものに関しては参照系マイクロサービス及びクライアント側からのソースコードの削除をすすめる。
削除
- 洗い出し・調査の結果、削除可と判断されたエンドポイントについては随時ソースコード自体の削除をすすめる
- 削除の際にも開発環境やステージング環境などでエラーが発生しないか監視を行う
- 削除をした際には関連チームに報告を行い、エラー監視をしばらく行う
- 削除を随時行うことでスリム化が進みビルド時間なども短縮されていき、よりマイクロサービスの恩恵を受けられるようになる
今後の進め方
- まずは削除できるソースコードについてすべて削除を完了する。（数万行のソースコードを削除できる見込み）
- 削除しないエンドポイントに関してはマイクロサービスを細分化した際にどのマイクロサービスに該当するかを分類分けする
- 各マイクロサービスが作成される時に同時で参照系マイクロサービスからの移行もすすめる
- クライアント側についても移行後のエンドポイントをリクエストするように修正を行っていく
振り返り
- 参照系マイクロサービスの中でもさらに細分化してマイクロサービスを定義するべきだったかもしれないが、マイクロサービス化の第一歩を踏み出しただけでも大きな価値があったと思う。
- マイクロサービス化したあとからも肥大化させてしまっていたことも問題で、ストアドを参照しているロジックを前もってエンドポイント化して実装を進めたものの数年間使われていないものも多かったので進め方についても途中で見直す必要があったと思う。
- 数カ月間かけて洗い出し調査を行ったが最終的には数万行は削除できそうなのでこの作業はやる価値が大きいと思う。
- もうちょっとスリム化すれば新しい技術を導入したりすることも容易になると思うのでよりよいマイクロサービスになると思う。