#はじめに
この記事は、実務未経験の大学生がロールプレイング形式でアーキテクチャの設計、構築を行うといった記事です。
よろしければ＜準備編＞もご覧くださいませ。
#前提条件の確認（ロールプレイング中）
- インフラエンジニアは4人
- 4人でインフラの構築、運用を行なっていかなければならない
- 自動化が重要
- 構築までの期間は1ヶ月
#問題点
現環境の構築に携わったエンジニアにヒアリングを行い、現環境の問題点を整理しました。
Well-Architected フレームワークを元にアーキテクチャを考えた時に、現時点でのアーキテクチャでは以下の様な問題点が挙げられます。
###セキュリティ
- 通信にSSLが適用されていない
- セキュリティグループが適切に設定されていない（全てがフルオープンになっている）
- DDos等の一般的なセキュリティ対策を行なっていない
- データの暗号化が行われていない
- リソースに対する権限管理が曖昧である
- DBの接続情報など、設定ファイルにハードコーディングされている
###信頼性
- 静的ファイルの保存先がEBSになっている
- 各リソースのスケーリングが行われていない
- 障害復旧の手順が決まっていない
###運用の優秀性
- リソースの監視が行われていない
- ログの収集、分析を行なっていない
- デプロイが手動で行われている
- パッチ適用、メンテナンスが手動で行われている
###コスト最適化
- リソースのコストを把握出来ない
###パフォーマンス
- DBのキャパシティ、パフォーマンスに対する懸念がある
#改善案
以上の問題点より、具体的な改善案を提案しました。
以下具体的な改善案です。
##セキュリティ
#####通信にSSLが適用されていない
- ACM
- CloudFront、ALBに証明書の関連付けを行いHTTPS化を行う
#####セキュリティグループが適切に設定されていない（全てがフルオープンになっている）
-
VPC
- 通信の範囲に応じてSubnetを作成
- NAT Gatewayの作成、Route Tableを定義する
- セキュリティグループを用いて必要最小限のアクセスのみを許可する
-
Systems Manager
- Session Managerを用いてSSHログインを行う
-
Config
- セキュリティグループのSSH全開放をAWS Configによる自動修復によって修正する
#####DDos等の一般的なセキュリティ対策を行なっていない
-
CloudFront
- ディストリビューションの作成
- 特定地域からのアクセスをブロックする
- CloudFrontからのアクセスのみを許可（オリジンへの直接アクセスを禁止）
-
Inspector
- 脆弱性を評価
- Slackに通知を行う
-
AWS WAF
- WebACLの作成
#####データの暗号化が行われていない
-
RDS
- 通信の暗号化
-
KMS
- RDSのデータを暗号化
- EBSのボリュームを暗号化
#####リソースに対する権限管理が曖昧である
- IAM
- IAMロールの管理、リソースへの適用
#####DBの接続情報など、設定ファイルにハードコーディングされている
- Systems Manager
- Parameter Storeを用いてデータベースへの接続情報を保存、管理
###信頼性
#####静的ファイルの保存先がEBSになっている
- S3
- サーバー間でのファイルの共有が可能、コスト、可用性、耐障害性の観点から静的ファイルの保管をS3で行う
#####各リソースのスケーリングが行われていない
-
ALB
- ターゲットグループの作成
- ALBの作成
- AutoScalingの有効化（検討）
- AutoHealingの有効化（検討）
-
Cloudwatch
- AutoRecoveryの有効化(検討)
#####障害復旧の手順が決まっていない
-
フェイルオーバー
-
Route53
- ヘルスチェックの有効化
- フェイルオーバールーティングの実装
-
CloudFront
- カスタムエラーレスポンスとしてSorry Pageを実装
-
-
DRとしてパイロットライト
- VPC
- インターリージョンvpcピアリングの実装
- RDS
- クロスリージョンレプリカの配置
- Lambdaを用いてマスターDBへの昇格を制御
- Cloudformation
- 別リージョンにスタックをコピー
- AMIのマッピング
- VPC
-
スナップショット、AMIの管理
- AWS Backup
- RDSのスナップショット
- EBSのスナップショット
- ゴールデンイメージの管理
- バックアップイベントをSlackに通知
- AWS Backup
##運用の優秀性
#####リソースの監視体制が不十分
-
Cloudwatch
- RDSのメトリクスを監視
- EC2インスタンスのメトリクスを監視
- CloudWatch Agentのインストール
- ELBのメトリクスを監視
- Cloudfrontのメトリクスを監視
- Cloudwatch Syntheticsを用いてサービス状況を監視
-
Personal Health Dashboard
- AWSの障害をSlackに通知
-
RDS
- イベントサブスクリプションによるRDSのイベントを通知
-
Trusted Advisor
- セキュリティの現状、不要なリソースの確認を行う
-
Security Hub /
- Security Standardの有効化
- Slackに通知を行う
-
GuardDuty /
- Slackに通知を行う
#####ログの収集、分析を行なっていない
-
S3
- VPC FlowLogの作成、S3にログの収集
- CloudFrontのアクセスログをS3に収集
- ELBのアクセスログをS3に収集
-
Athena/QuickSight
- アクセスログをAthena+QuickSightで分析&可視化
-
Systems Manager
- Session Managerの操作ログの収集
-
EC2
- ログの正当性を担保する為にTime Sync Serviceで時刻同期を行う
-
CloudWatch Logs
- ログの収集、ロググループの作成
- メトリクスフィルタによるログの監視
- CloudWatch Logs Insightsによるログの分析
-
Kinesis Firehose
- AWS WAFのログの収集
#####デプロイが手動で行われている
- Code3兄弟
- Code3兄弟を用いたCI/CDパイプラインの構築
#####パッチ適用が手動
- Systems Manager
- SSM Agentのインストール
- Patch Managerを用いたパッチの自動化
- RunCommand、State Managerを用いた再起動、メンテナンスの自動化
###コスト最適化
#####リソースのコストを把握出来ない
-
Cost Explorer
- コスト分配タグの設定
- CostExplorerを用いて、コストを確認
-
IAM（Organization）
- リソースに対して、コスト管理の為のタグ付けの強制
-
Budgets
- 予算を設定し、コストの管理を行う
- Slackへの通知
###パフォーマンス
#####DBのキャパシティ、パフォーマンスに対する懸念がある
-
RDS
- リードレプリカの配置
- MySQLをAuroraMySQLに移行
- クラスターエンドポイント、リーダーエンドポイントの実装(検討)
- 容量のスケーリングの有効化
-
ElastiCache
- Auroraと併用し、クエリ結果をキャッシング
#感想
アーキテクチャの設計が完了しました！
あとはこれを構築するだけです （...だけ？）
アーキテクチャ図に3時間はかかっております