この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ご機嫌いかがでしょうか、豊崎です。
最近Well-Architectedにご縁があり、連続して記事を書いています。今回はWell-Architectedの信頼性の柱についてご紹介をしたいと思います。
何度か書いていますが、Well-Architectedとは何か？どういうシステムに使ってもらいたいか？については以下をご覧いただければと思います。
さて、改めての記載となるのですが、Well-Architected Framework には５つの観点があります。
- 運用の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
5 つの柱などと表現されたりします。
それぞれの柱に対話形式の質問が用意されています。
ここでは実際にどのような質問があるのか、またそれに対してどのような観点を持ってアプローチを行うことが望ましいかを確認していきたいと思います。
そのために各柱の設計原則、定義、ベストプラクティス、キーとなるAWSサービスについて確認していきたいと思います。内容がたっぷりあるので、柱ごとに確認をしていきます。
今回は信頼性の柱 について確認していきたいと思います。
信頼性の柱
信頼性の柱について
信頼性の柱にはインフラや、サービスの中断から回復して需要に対するコンピューティングリソースを動的に取得すること。また、設定ミスや一時的なネットワークの問題を軽減する機能が含まれています。
設計原則（Design Principles）
復旧手順のテスト
自動化を利用して障害シナリオの再現や、シミュレートが行い、実際の障害発生前にテストを行い修正が必要な経路やコンポーネントの確認が障害のリスクが軽減されます。
障害からの自動回復
KPI（重要業績評価指標）についてシステムの監視を行うことで、閾値に従った自動化アクションをトリガーすることができます。これにより障害の通知と追跡、および障害回避または復旧のための自動回復プロセスの導入が可能になります。より高度な自動化においては発生前に障害を予測し、修正することなども可能です。
システム全体の可用性向上のため、水平方向へのスケールアウト
１つの大きなリソースを複数のリソースに置き換えて、システム全体に対するSPOF（単一障害点）を減らします。
キャパシティに対する推測をやめる
需要と、システムの使用率を監視しリソースの追加や削除を自動化して、過不足なく適切なプロビジョニングを行います。
自動化による変更の管理
まず、インフラストラクチャに対する変更は自動化するべきという前提のもと、変更の自動化に対する管理が必要です。
定義（Definition）
信頼性の柱には以下の3つのベストプラクティス分野があります。これらは以下にあるBest Practicesの項目にある質問およびKey AWS Services とマッピングされた形で確認されます。
- 基盤（Foundations）
- 変更管理（Change Management）
- 障害管理（Failure Management）
ベストプラクティス（Best Practices）
ベストプラクティスを確認するために以下のような質問が用意されています。
- 基盤（Foundations）
- REL1： サービス上限をどのように管理していますか？
- REL2： ネットワーク構成をどのように管理していますか？
- 変更管理（Change Management）
- REL3： システムは需要の変化にどのように適応しますか？
- REL4： リソース監視をどのように行いますか？
- REL5： どのように変更を実施しますか？
- 障害管理（Failure Management）
- REL6： どのようにデータのバックアップを行いますか？
- REL7： どのようにシステムはコンポーネント障害に耐えますか？
- REL8： どのように復旧のテストしますか？
- REL9： どのようにDR（disaster recovery）のための計画を行いますか？
Key AWS Service
信頼性に必要不可欠なサービスはAmazon CloudWatchでメトリクスを監視します。
- 基盤（Foundations）
- AWS IAM
- Amazon VPC
- AWS Trusted Advisor
- AWS Shield
- 変更管理（Change Management）
- AWS CloudTrail
- AWS Config
- Amazon Auto Scaling
- Amazon CloudWatch
- 障害管理（Failure Management）
- AWS CloudFormation
- Amazon S3
- Amazon Glacier
- AWS KMS
まとめ
信頼性の柱ではシステムの単一障害点を無くし、KPIに基づいたシステム監視のもと、需要に対して自動的な変更が行えるようにすること。また、データバックアップとリストアのテストを行い、障害に備えることなどについて言及されていました。
基盤（Foundations）
- システム設計を行う前に信頼性に影響を与える要件を設定する
- オンプレミス環境がある場合はAWSとオンプレミスのネットワークトポロジーを把握し、設計を行う
変更管理（Change Management）
- 変更がシステムに与える影響を把握する
- KPIを元に監視を行い、閾値に応じて自動的な変更が行う
- 手作業での変更プロセスを自動化する
- 環境への変更を自動的に記録しておく
障害管理（Failure Management）
- 障害が発生することを前提に検討
- 監視の閾値をトリガーに自動的なアクション実施
- データの定期的なバックアップをする
- バックアップファイルのテスト
- RTO、RPOに基づく定期的なシステムリストアのテスト
さいごに
今回は信頼性の柱についてまとめました。KPIを意識した監視や、変更の自動化、システム復旧について書かれていました。他の柱にも言えることですが、システムに対しての”基準や指標”が定義されていることが判断を行う上で重要であると改めて感じました。
この記事が誰かのお役に立てば幸いです。
18
