こんにちは！vivitの技術開発部マネジャーの井島です。 開発部ではマイクロサービスアーキテクチャを採用しており、そのアーキテクチャの考え方について話したいと思います。
この分野は個人的に好きで、一生話してられます笑
はじめに
一般的な「マイクロサービス」の知識は知っている前提で、それをどれだけ自分たちの組織向けにアレンジできるかが、肝になると私は考えています。
マイクロサービスは会社の組織構造に密接に関係します。 ビジネス側の組織構造、開発側の組織構造、プロダクト、事業方針、技術方針、採用方針、（経営方針）など。 会社として最終的にアウトプットを最大化していかなければならない状況下で、どれだけ開発効率を出せる、会社の成長に追従できるシステムアーキテクチャにできるかどうか、という視点からの話になります。
技術的な観点や教科書通りのみで導入してしまうと、事業規模に対してコスト面や事業成長にネガティブに働いてしまうことも考えられ、全体的に考えることが必要です。 マイクロサービスも導入して終わりではなく、状況に応じて戦略的に成長させていくものだと考えます。
あなただったら、どのようにシステムのアーキテクチャをデザインしていきますか？
vivitの組織について
色々部署はありますが、エンジニアは技術開発部に所属しているかたちになります。
もう少し細分化して、技術開発部とビジネス側との関係性は以下になります。
ビジネス側は事業（プロダクト）毎に部署が別れています。 それに紐づくかたちで開発部内でもチーム分割され、ビジネス側とそれぞれが密に連携しています。
使用言語, フレームワーク
- TypeScript
- React
- Next.js
- Ruby on Rails
- Go
エンジニア構成
- フロントエンドエンジニア
- バックエンドエンジニア
開発部内各チームにはフロントとバックのエンジニアが所属します。
ほか全体的な状況
- 開発部内各チームは、基本2人で構成される。 1チームのエンジニア人数が少ない。※開発計画によって人数は増減する。
- 事業計画によって、プロダクトにかける開発工数が上下し、兼任もあり得る。
- 開発内容は、ビジネス側の事業部毎に管理され開発に降りてくる流れ
- 基本的にフロントエンド、バックエンドとで職務が別れている
マイクロサービスの群雄割拠
実は、vivitにマイクロサービスが導入されたときは、2019年あたりのレンタル事業、スポット事業が立ち上がったころでした。 この頃はvivitが新規事業を立ち上げていったころで、0→1の開発で開発部も1チームでした。 この頃のシステム構成は1チームが10前後マイクロサービスを開発するかたちでBazelも使って同時ビルドしていました。
マイクロサービス分割設計が境界付けられたコンテキストになっておらず、要件を満たすために結局複数マイクロサービスを開発することになり、開発は非効率なままでした。 その問題から、マイクロサービスの統一化が進みました。
たしかに、0→1 の段階でプロダクトの業務や機能も変化が激しい時期に業務単位でマイクロサービス分割するのはかなり難しいことだということが得られました。
マイクロサービスの考え方の1つに「作りやすい壊しやすい」がありますが、新規マイクロサービス作成にコストがかかる状況も、統一化の方向性に向けていたと思います。
マイクロサービス所有者
教科書的には1チーム1マイクロサービスを聞いたことがあると思いますが、vivit開発部の場合はどうでしょう。
1チームにフロントエンドエンジニアが開発するサーバ(Next.js)、バックエンドエンジニアが開発するサーバ(Go) がすくなくとも存在します。
野良マイクロサービス（明確な所有者不在）
プロダクト共通で使っているシステムも存在しています。「会員管理システム」と読んでいるもので、顧客情報/アカウントを管理し各プロダクトからログイン廻り共通で使われる部分です。 明確にビジネス側と紐づくチームは現在ありません。
放置されたマイクロサービス
マイクロサービス群雄割拠時代に取り残され、メンテナンスがほぼ入っていないマイクロサービスも存在しています。 プロダクト共通で使われている機能となっており、プロダクト都合の変更を入れづらい状況となっています。
一般的に1マイクロサービス内に複数ドメインの都合が染み出していくことはアンチパターンで、vivitでもこの考え方に従っています。 障害ドメイン分割、リリースの独立性の面もありますが、何より所有者不在かつ継続的に開発が入らないマイクロサービスに対してこのようなことを行うことは、 各プロダクトの開発要件を常に共通システムとして設計する必要があり、現状のvivit開発部でもアンチパターンとしています。
まとめ
設計する上での前提条件や、運用経験を並べてみましたが、マイクロサービスをどう適用しようか少しでもイメージ付きましたか？
vivit でのマイクロサービス構成は、基本的なマイクロサービスの考え方にプラスし、特徴は以下になっています。
- 1チーム複数マイクロサービスを所有
- ソースのレポジトリはチーム毎にモノレポ
- マイクロサービス間でも技術的統一性を保つ
- 新規マイクロサービス作成は慎重傾向
- 基本はプロダクト毎、フロントエンド/バックエンド毎（開発が企画される部署単位）
- 常にメンテナンス（開発）されるマイクロサービスとしていく
- 放置マイクロサービスは引き続き放置
- 機能追加などしたい場合はその機能をプロダクト所有マイクロサービスに移行することを検討
- 会員管理のマイクロサービスのように所有者不在も一部許容
- 必要に応じて各プロダクトチームの担当者が開発を行う
- プロダクト毎のBFF
- Kubernetes (GKE)
- gRPC による同期的通信
- バッチ処理 (CronJob)
- [構想段階] ログ出力などマイクロサービス共通で使うもののライブラリ化
- マイクロサービス毎の品質均一化
- 開発効率アップ
- 放置マイクロサービスを否とし、常にメンテナンスされる状況を是としており、共用だがエンジニアの目につくところ配置でき、この方式はvivitとしてアリ
コンウェイか逆コンウェイかと言われたら、コンウェイの法則に従っていると思います。 vivit の場合、複数事業があり1チームのエンジニアが最小限なことや、継続的なプロダクト開発をしつつ、開発リソースを集中させたプロジェクト的な開発も行われるところも、システムアーキテクチャ設計を難しくしています。しかし、それが面白いところでもあります。暇しないですね笑
少しでも気になったら、話を聞きに来てください！
いつでも歓迎します！
新卒採用
キャリア採用
