はじめに
こんにちは、ユニファ株式会社取締役 CTO の赤沼 寛明です。
2015年に一人目の正社員エンジニアとしてユニファに入社し、当初は開発に注力しながら採用なども進めてきました。気持ちとしてはずっと技術的なところをやっていたいのですが、今では開発メンバーが50名ぐらいになり、会社全体としても組織が大きくなってきたこともあり、直接的な開発業務はメンバーに任せて私は採用や組織面に主に注力しています。
今回は「あえてこの選択しています」ということで、弊社が2021年7月に発表した新「ルクミー」シリーズのうち5サービスについて、バックエンドをどう分割・共有したか、その判断の過程をお話します。少しでも複数サービスの持ち方、考え方の参考になれば幸いです。
新規サービスの設計に向けた検討材料
ユニファは「スマート保育園・スマート幼稚園・スマートこども園」構想を掲げて、保育施設向け総合ICTサービス「ルクミー」を提供しています。現在の日本において、保育士不足や保育現場の長時間労働や高負荷業務は深刻な社会課題です。ルクミーは、ICTを活用して保育施設の保育現場業務の負担削減と、保育の質の向上を目指しています。
今回のリニューアルで新たに設計したサービスとして、「ルクミークラスボード」「ルクミー連絡帳」「ルクミーおたより」「ルクミー帳票管理」「ルクミー登降園」があります。これらのアーキテクチャを考えるにあたって、主に以下のような検討材料がありました。
- クライアントは保育者向け、保護者向けなど複数のモバイルアプリからアクセスしてくる
- ユーザー・クライアント認証は全サービスで共通のロジックが必要
- ビジネスロジックはサービスごとに全く異なる
- サービスは今後も増えていく見込みがある
- データはサービス間で共通に使うものが多いが、登降園サービスは比較的データの独立性が高い（完全に独立ではない）
- 各サービスでアクセス特性が異なるが、特に登降園サービスは朝と夕方の登降園時間帯に激しいスパイクがある（日本全国、一斉に園児が登園・降園する時間帯がある）
- 特にそのスパイクは導入先の保育施設数に応じて大きくなっていく
- 既存プロダクトの延べ導入数は1万以上であり、これらのユーザーが順次流入してくる
- 上記の業界固有のアクセス特性やユーザー数増加に対しても高い安定性が求められる
また、開発開始当時、以下のようなチーム体制でこのサービスのサーバーサイドのアーキテクチャ設計を進めました。
- エンジニアリングマネージャー２人
- サーバーサイドエンジニア4人
- インフラエンジニア２人
- プロダクトマネージャー1人
- CTO（私）
今後の事業展開も考えた、バランスの良いアーキテクチャを探る
クライアントサイドはスーパーアプリとして一つのUXを提供しつつ、バックエンドのサービスをどう分けるべきか（あるいは分けないか）が正解のない論点でした。今後のサービス・事業展開を考えたスケーラビリティ、保守性、設計のシンプルさ、そして開発のスピードのバランスを取るために最適なアーキテクチャは何かを検討しました。
まず、「クライアントは保育者向け、保護者向けなど複数のモバイルアプリからアクセスしてくる」「ユーザー・クライアント認証は全サービスで共通のロジックが必要」という点は、全てのサービスにおいて共通の要件となるため、ICTフロントエンドサービスとしてゲートウェイ的に前面に立てることにしました。そもそも切り出す必要があるのか、そのバックエンドと分ける必要があるのかなどの議論もありましたが、モバイルアプリの開発を考えてもアクセス先は統一されていたほうが良い、認証は一手に受けておいてバックエンドの各サービスには意識させないほうが良いなどの理由から切り出すことにしました。
ここでは、スケーラブルでありながら運用負荷の少ないサーバーレスなサービスとして Amazon API GatewayとAWS Lambdaを使いました。
より検討が必要だったのはそのバックエンドです。最初にインフラエンジニア主導でいくつかの案を出してもらい、他のメンバーを交えて議論しました。
- 案1：各サービスを個別に分けて作る。データベースもサービスごとに持つ
- 案2：全部をひとまとめにする。データベースは一つだけ
- 案3：園児の活動系、保護者連絡系、その他で分ける
- 案4：登降園、保護者連絡系、その他で分ける
- 案5：登降園、その他で分ける
このとき「マイクロサービスとして正しく作る」ことを意識したわけではなく、あくまでもプロダクトの特性と自チームの体制、開発期間的な制約などから考えて、ビジネス上の成果を上げるための合理的な判断をすることに徹しました。
