Upgrade to Pro — share decks privately, control downloads, hide ads and more …

運用まで考慮したクラウドアーキテクチャ設計できてますか?

mars_eu
April 26, 2021

 運用まで考慮したクラウドアーキテクチャ設計できてますか?

mars_eu

April 26, 2021
Tweet

Other Decks in Technology

Transcript

  1. 自己紹介 • 名前 村瀬 善則 • 前職 独立系SIer • 一言で言うと

    アプリもわかるインフラアーキテクト • LIKE リファクタリング、トラブルシューティング、性能改善
  2. AWS Organizations & SCP おすすめの設定 • 本番用のOUを作成し、初期構築後のクリティカルな変更を禁止する。 ◦ KMSの削除禁止 ◦

    CloudTrailの変更禁止 ◦ S3バケットの削除禁止 ◦ RDSの削除禁止 • サンドボックス用のOUを作成し、利用させたくないAWSサービス、高額なインスタン スタイプを禁止する。
  3. システム・環境ごとにアカウントを用意 jump SystemA develop SystemA staging SystemA production Develop Role

    Staging IAM Production Role IAM User login(ID/PW) SystemB develop SystemB staging SystemB production Develop Role Staging IAM Production Role Switch Role
  4. IaCの分離 システムの規模・特性にもよるが、適切な分離をする。 • サービス提供 • CI/CDパイプライン • 監視 メリット •

    IaCのプラン、デプロイ時間の短縮 • サービス提供に直接関係ない部分の更新が気楽
  5. 監視対象 LB DB compute USERS POINT1 エラーレスポンス、応答時間を監視するのはクライアントに一番近い個所。 なぜなら後方のエラーレスポンス、応答時間よりも確実に大きいため 例 Aurora

    50msec < EC2 80msec < ALB 100msec サービス特性によるが単位時間あたりにアクセスが一度も来ないのも異常。 POINT4 空きストレージ容量が枯渇しないよう早期に予兆監視する。 POINT2 computeに関してはメトリクスではなくエラーログを監視する。 対応不要なものは通知しない。 POINT3 CPU、memoryが高くてもパフォーマンスが良好であれば問題ない。
  6. インシデント発生時に備え用意しよう 復旧 不具合解消 原因特定 インシデント検知 インシデント発生 アプリエラー メトリクス異常 アプリログ監視 メトリクス監視

    アプリログ確認 X-Rayで特定 アプリ修正 データ修正 アプリ修正 データ修正 チューニング セキュリティ 本日は話しません。機会があればいつかどこかで