Well Architected Frameworkを意識して自分なりにアーキテクチャ設計・構築をしてみた。＜アーキテクチャ設計編＞

はじめに

この記事は、実務未経験の大学生がロールプレイング形式でアーキテクチャの設計、構築を行うといった記事です。
よろしければ＜準備編＞もご覧くださいませ。

前提条件の確認（ロールプレイング中）

• インフラエンジニアは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のマッピング

• スナップショット、AMIの管理

  • AWS Backup
    • RDSのスナップショット
    • EBSのスナップショット
    • ゴールデンイメージの管理
    • バックアップイベントをSlackに通知

運用の優秀性

リソースの監視体制が不十分

• 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時間はかかっております