はじめに
アーキテクチャの勉強するために、こんな記事を書きました。
基本的にスマホで書いていますので、PCで見ると表示崩れが起きているかもしれません。
要件
- 営業活動をするための基幹システムを構築する。
- 営業活動はほとんど関東圏内で完結している。
- システムが完全に止まっても、事業会社が完全停止するわけでもない。しかしできれば止めたくない。またシステムを復旧するためのバックアップデータは必要。
- できる限り安くしたい。
- 通常営業時間は9:00-18:00であり、1日の平均残業は1時間以下である。また土日祝の完全週休二日制ではあるが、まれに休日出勤をすることもある。
- できる限り運用分担を減らしたい。
アプリ構成
- フロントエンドはCSRで、Reactを採用したい。
- バックエンドはステートレスRest APIで、Spring Bootを採用したい。
- データ管理はRDBで行う。
- 認証や認可、セッション管理は、バックエンド側で行う
AWS構成図
以下構成図を東京リージョンのみで動かします。
EC2やLambdaではなく、ECSを採用した理由
EC2を不採用にした理由は、OSやミドルウェアレイヤーの管理をなくすためです。
それにより運用負担を減らすことが出来ます。
またLambdaを不採用にした理由は、Javaによるコールドスタートをなくするためです。
Lambdaでもコールドスタート対策は出来ますが、チューニングによる運用負担が増加するため不採用にしました。
マルチリージョンでシステムを動かさない理由
営業活動はほとんど関東圏内で完結していることやできる限り安くしたいため、マルチリージョンを採用しませんでした。
もし東京リージョン全体が止まった場合、関東に大災害が起きたことになります。
その場合営業活動自体が難しいため、別リージョンにDRしても意味がないです。
しかしシングルAZだけでは心もとないため、マルチAZを採用しました。
またDBなどのバックアップは大阪リージョンで行います。
理由は東京リージョンが止まっても、データを復旧できるようにするためです。
ECSのスケーリングについて
構成図に記載していませんが、スケーリングの最大値は営業活動をしている人数に合わせて時間帯ごとに設定します。
【設定する時間帯】
通常営業時間 + 1 > 平日19:00以降 > 土日祝
その設定により、可用性とコストを両立します。
さいごに
SAPを取得して3ヶ月経ちますが、忘れていることが多かったです。
そのためサービスについて調べ直すことが多かったです。