パッケージソフトをマルチテナント型Saasにした話

方向性

・なるべく既存のアーキテクチャを変更せずに拡張する

・新しく作り直さない

背景

・仕様作成からリリースまでスケジュールが6ヶ月間

・すべて作り直しをした場合、コストがとてもかかる。また本当に開発完了できるか不安があった

DB関連

ElasticsearchがベストプラクティスかもしれないがMySQLを選択した

MySQLを選択した意図

・開発陣がElasticsearchに慣れていない

・経験上、パフォーマンスは十分に出せる感覚はあった

・カラム追加の柔軟さは減るがMySQLの方がデータの堅牢性は上がる。

各テーブルにcompany_idを持たないでテナントごとにデータベースを分ける

データベースごとにRDSインスタンスを分けた

意図

Aurora serverlessがMySQL8.0に対応してない。

スキーマ管理のマイグレーション

意図：並列で処理実行。エンタープライズ企業が多くテナントの数がとても多いわけではない。

SmartHRさんの記事を呼んだが、並列マイグレーションでも行けると判断した。

参考：https://speakerdeck.com/purintai/builderscon-2018

利用技術：https://phinx.org/

項目の追加は単純にadd columnするようにした

意図：json型の採用やElasticsearchの利用は、学習コストや移行コストが発生すると判断した

index設計

トランザクション系データ

各テナントの運用開始時点で手動でインデックスショットガンにする。管理画面での項目追加・変更時にはindexに関する操作はしない

マスタ系データ

（あえて）インデックスショットガンを選択

インデックスショットガンを選んだ理由

・いろいろな項目で自由に検索が可能な画面設計になっている

AP関連

特に変更せずApacheを採用した

意図：経験上、パフォーマンスは十分に出せる感覚はあった。

現在特段大きな問題は発生していない

AWS ELBを利用して冗長化した

セッションデータはMySQLに保存するアーキテクチャだったので問題なかった

APサーバをまたがるようなファイルについてはEFSに保存するようにした

設定ファイル設計

サブドメインに応じて設定ファイルを分けるようにした

具体例：$tennant_name.config

意図：

ファイル保存

AWS EFSを選択

意図：

APサーバが複数台ある場合にNAS的に利用したかった。

監視

ZabbixとCloudwatch

意図：以前からの変更をしない