PeopleWorkのインフラ構成をモジュラモノリス化しコスト削減を行った話

PeopleWorkについて

PeopleXが運用するPeopleWorkはエンプロイーサクセス (社員の活躍支援) のためのプラットフォームです。PeopleWorkは2024年8月のリリースから1年強の間さまざまな状況の変化を経てインフラのアーキテクチャもそれに合わせて変化していきました。

この1年における環境の変化

開発初期の段階でPeopleWorkは コンパウンドSaaS として複数サービスをそれぞれ独立した開発組織でプラットフォーム上に展開していくことを想定していました。そのためインフラ構成もサービスごとに独立した環境を構築し展開するアーキテクチャ (いわゆる マイクロサービス) を採用していました。

しかし2025年に入りプロダクト戦略、組織戦略が変わり、コンパウンドとしてすべてのサービスを1つのチームで同質的に展開し、より開発速度を上げていく方針となりました。

この変化に伴い当時のPeopleWorkのマイクロサービスアーキテクチャは、かなりオーバーヘッドの大きなものになってしまっていました。具体的にはサービスごとに立ち上げているインフラリソース^[1]のコスト負荷、1チームで複数サービスを担当するという、組織構造とマッチしないアーキテクチャになることによるメンテナンスや運用負荷の増大などです。

このような状況を踏まえ、先日PeopleWorkのインフラをモジュラモノリスの形式に整理 (以下 モノリス化 と呼びます) し、1チームでメンテナンス可能な状態に更新しました。

どのようにモノリス化したか

アプリケーション

もともとPeopleWorkのアプリケーションコードはモノレポ形式を取っており、モノリス化するのに大きな変更は不要でした。^[2]

インフラ (AWS)

インフラに関して、もともとサービスごとに独立したVPCを利用し、そこにアプリケーションサーバやDB,キャッシュ,ストレージなどを立ち上げてていた状態でしたが、これらをすべて 1つのVPCにまとめる形に変更しました。

また、個別に立ち上げていたデータベース, キャッシュ, LoadBalancerのリソースを 1つのインスタンスに統合しました。データベースに関してはメンテナンス時間を取り、すべてのデータを1つのDBインスタンスへ統合しました。利用するDBはアプリケーションごとに論理的に分割されているため、再びマイクロサービスにしたい場合や負荷分散のため独立したインスタンスに分割する場合も実施可能な状態にしています。

BEFORE

AFTER

運用面

開発者の運用に関して、もともとAWSへの開発者のアクセス権限はIAM Identity Centerで管理しており、

「サービス」×「役割(管理者,運用者など)」

のマトリクスで権限管理していました。これをサービスの分類を廃止し、役割で全てのサービスを見れるように変更しました。

またエラー通知先のSlackチャンネルも一つに集約し、確認の負荷を減らしました。

モノリス化の効果

コスト面

モノリス化によってインフラコストを半分以下に削減できました。
※2025年6月と8月比較。7月は新旧両インフラを立ち上げていたため一時的に増えています

運用面

エラー発生時の調査が簡易化したのはもちろん、リソースを減らすことによって全体のデプロイ時間が 約半分(20分から10分) に削減され、開発サイクルをより速く回すことが出来るようになりました。

最後に

PeopleWorkを始めとするPeopleXが提供するサービスは日々様々な変化が発生しています。こういった変化にPeopleXの行動規範の一つである 異常速度 で対応できるようにメンバー一同活動を行っています。

脚注

1. DB, Cache, LoadBalancer, 監視設定など

2. このような構成にしてくれていた先人に感謝