方向性
・なるべく既存のアーキテクチャを変更せずに拡張する
・新しく作り直さない
背景
・仕様作成からリリースまでスケジュールが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
意図：以前からの変更をしない