操作
設計 #39
未完了開始日:
2024-02-12
期日:
2024-02-12 (約7ヶ月 遅れ)
進捗率:
0%
予定工数:
説明
概要¶
- AWSサービス上にアプリケーションを構築し、運用できるまでのインフラを構築する。
- インフラ構成図を作成する。
本番環境での運用はどうする?¶
- AWSサービスを利用する。
- AWS Cognitoを使用しているので、DBやRedisもAWSのサービスで統一してしまった方がまとまりがあって良い。
- Terraformで管理を可能にする。(すでにCognitoはTerraform管理している)
設計してみた¶
- AWS初心者すぎるので、以下のように設計してみた。
ただし、これは本来は良くない設計であることは承知している。
- 理由:本当は以下のような設計であるべき。
- ユーザー認証周りはALBとCognitoで連携できるため。
- ただし当初の設計ミスが響き、
- Cognitoとの連携をRailsのコードで実装したためECSとCognito間を接続してユーザー認証を実現してやる必要がある。(正直ここは反省点である。)
NginxコンテナとAppコンテナは分割させる。
- 開発したアプリではNginx用とApp用でコンテナを分けている。
- 1コンテナ=1インスタンスとした方がコンテナ間の関係が疎となり、問題が生じた時の切り分けや影響範囲が小さくなる。
ALBを活用するのにNginxコンテナが必要かの検討。
Zenn¶
Lunatic1998 さんが7ヶ月前に更新
- 説明 を更新 (差分)
考慮したいこと¶
アプリケーションサーバー¶
- アプリケーションはコンテナ上にて構築されている。
- プロキシとしてWebサーバー(Nginx)を前段に置き、処理は後段のアプリサーバーという二段構えである。
- 現時点では、アプリケーションの全体像が掴めない状態である。
- 可変的にスペックを変動できる、もしくは拡張可能なインフラ構成であることが望ましい。
DB¶
- MySQL形式のデータベースを使用している。
- データのバックアップはどうするか。
Redis¶
- 永続的にデータを保持する想定のRedisを使用している。
- リリースはリードタイムが短いアジャイル開発に近い頻度で予定している。
認可サーバー¶
- AWS Cognitoを使用しており、本番環境でも継続使用する予定。
DNS¶
メールサーバー¶
- 現状でメール機能が存在しないので、不要である。
- 認証機能にメールを追加したい場合は、必要となる可能性。
監視¶
- 死活監視
- アプリケーションやRedis、DBのログ監視
- メトリクス監視
- 現状ではほとんどユーザーが来ない想定であるため、無効化でも良い。
ロギング¶
- Nginx,production.log,redis.logなど、Logrotateが必須である。
バックアップ対象¶
- 定期的にバッチでバックアップを取得し、S3などのストレージへ格納できるように実装する。
- バックアップ対象は、RedisとDB、アプリサーバー。
リリース¶
- リリース頻度はアジャイル開発に近いリードタイムが短めとする。
備考¶
- 初期段階では、ユーザー数が見込めないため、単一障害点を考慮しない。
Lunatic1998 さんが7ヶ月前に更新
- 期日 を 2023-09-12 から 2024-03-31 に変更
- 開始日 を 2023-09-12 から 2024-03-31 に変更
操作