セーフィーで取り組むマイクロサービス化について

はじめに

セーフィー株式会社でバックエンド開発のテックリードをしております鈴木敦志と申します。セーフィー株式会社は創業から9年経過し、サービスの拡大と開発者の増加に伴う開発生産性の問題に直面しています。この問題の解消のため、職能横断型チームの再編成とコードベースの分割によるマイクロサービス化を進めています。

セーフィーのサービス・チーム構成

セーフィーのクラウドサービスはカメラ管理および映像閲覧のほか、業務システム、AI応用サービス、開発者向け機能および入退館管理システムなどで構成されており、サーバー/Webの開発者のほかモバイル/組み込み/QAエンジニアなど様々な職種が関わっています。チームは職能別に分かれており、チームごとに複数のプロジェクト (開発案件) に参加します。

開発組織の規模が増えるにつれ、様々な問題が明らかになってきました。

機能追加・改修にはたいていWeb・サーバーなど複数職種が関わってくるため、開発に伴い複数チーム間の調整が頻繁に発生します。各チームは複数プロジェクトを並列で掛け持ちすることになり、開発リードタイムの増加と認知的負荷の増加に繋がっていました。
特にバックエンド開発において、モノリシックなサーバーコンポーネントを複数チームで共有しているためコード変更やデプロイ作業の競合が頻繁に発生していました。こういった状況に対処するためにコードベースの分割が進められていましたが、各コンポーネントのオーナーシップが不明確であるためにいわゆる分散モノリスの状態になり改善には繋がりませんでした。

これらの問題を抜本的に解消するため、職能横断型チームの再編成とマイクロサービス化に取り組んでいます。

マイクロサービス

マイクロサービスとは、個別にデプロイ可能なサービスの集合体としてシステムを構成することで多人数による並列開発を効率化する手法です。今回は下記方針でマイクロサービス化およびチーム再編成を進めていきます。

マイクロサービス境界を決定: マイクロサービスの導入にはどのようにサービス境界を定めるかが重要になりますが、今回はビジネス機能により分割し、必要以上に細かく分割しないようにしています

チームの再編成: 各チーム内で開発業務が遂行できるよう企画・QA含め機能を集約し機能横断チームを編成します
コンポーネントの分割と内部APIの整備: ソフトウェアコンポーネントの機能がマイクロサービス境界をまたいでいる場合、コードベース・デプロイ単位・DBを分割します。境界をまたいで機能提供を行う場合、gRPC等で内部APIを整備します。

モジュラーモノリスの検討

マイクロサービスに関連する手法としてコードベースおよびデプロイ単位は単一のままモジュールのオーナーシップを明確化するモジュラーモノリスも知られており、マイクロサービス移行の前段階として、あるいはマイクロサービスの複雑さを回避しつつ大規模開発を行うために用いられます。弊社においてはモジュール間参照の規律を保つのが難しいと判断したため、マイクロサービスを選択しました。

既存コードベースのマイクロサービス化

既存コードベースのうち特にバックエンドのソフトウェアはAPIサーバー、デバイス接続サーバー、タスクキュー、バッチサーバー等多数のサーバーで構成され、いわゆるモノリスあるいは分散モノリスとなっています。これらのソフトウェアの機能を保ったままマイクロサービス化を進めるため、以下の手順を取ります。

既存コードベースのうちマイクロサービス境界をまたぐものをチームごとにフォーク
自チームの担当範囲外の実装範囲外を削除またはプロキシに置き換え
DBへの接続権限を変更し担当範囲外のテーブルへの書き込みを禁止
マイクロサービス境界をまたぐ機能提供をAPIプロキシまたはDBの参照からgRPC等の内部APIに置き換える
DBサーバーを分割

例: カメラ管理と契約・決済情報の分離

場合によっては単純なAPI分割だけではサービスの分割ができず、再設計が必要な箇所があります。

例として、セーフィーではカメラごとに顧客とSaaS契約が締結され、契約プランにより使用できる機能が異なります。契約プランはフロントエンドチームの内製する管理ツールにより操作され、また社内の業務システム (Salesforce, Zuora等) と同期されています。チームをまたいだ複雑なデータの同期が行われ、またどこの情報が元データなのかがわかりづらくなっていました。

現在サーバー内では契約情報とそれにより有効化される機能が単一のRDBテーブルで表現されていますがこれを分離し、カメラの機能有効化API/ライフサイクル管理APIを業務システムチームに提供する形で連携することで、契約情報の一元管理を実現します。