Well-Architected Frameworkの柱「信頼性」を読み解いてみた

豊崎隆

2019.05.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ご機嫌いかがでしょうか、豊崎です。

最近Well-Architectedにご縁があり、連続して記事を書いています。今回はWell-Architectedの信頼性の柱についてご紹介をしたいと思います。

何度か書いていますが、Well-Architectedとは何か？どういうシステムに使ってもらいたいか？については以下をご覧いただければと思います。

無料のAWS Well-Architected Toolでクラウド最適化への一歩を踏み出そう

さて、改めての記載となるのですが、Well-Architected Framework には５つの観点があります。

5 つの柱などと表現されたりします。

それぞれの柱に対話形式の質問が用意されています。

ここでは実際にどのような質問があるのか、またそれに対してどのような観点を持ってアプローチを行うことが望ましいかを確認していきたいと思います。

そのために各柱の設計原則、定義、ベストプラクティス、キーとなるAWSサービスについて確認していきたいと思います。内容がたっぷりあるので、柱ごとに確認をしていきます。

今回は信頼性の柱について確認していきたいと思います。

信頼性の柱

信頼性の柱にはインフラや、サービスの中断から回復して需要に対するコンピューティングリソースを動的に取得すること。また、設定ミスや一時的なネットワークの問題を軽減する機能が含まれています。

自動化を利用して障害シナリオの再現や、シミュレートが行い、実際の障害発生前にテストを行い修正が必要な経路やコンポーネントの確認が障害のリスクが軽減されます。

KPI（重要業績評価指標）についてシステムの監視を行うことで、閾値に従った自動化アクションをトリガーすることができます。これにより障害の通知と追跡、および障害回避または復旧のための自動回復プロセスの導入が可能になります。より高度な自動化においては発生前に障害を予測し、修正することなども可能です。

１つの大きなリソースを複数のリソースに置き換えて、システム全体に対するSPOF（単一障害点）を減らします。

需要と、システムの使用率を監視しリソースの追加や削除を自動化して、過不足なく適切なプロビジョニングを行います。

まず、インフラストラクチャに対する変更は自動化するべきという前提のもと、変更の自動化に対する管理が必要です。

信頼性の柱には以下の3つのベストプラクティス分野があります。これらは以下にあるBest Practicesの項目にある質問およびKey AWS Services とマッピングされた形で確認されます。

ベストプラクティスを確認するために以下のような質問が用意されています。

基盤（Foundations）
- REL1：サービス上限をどのように管理していますか？
- REL2：ネットワーク構成をどのように管理していますか？
変更管理（Change Management）
- REL3：システムは需要の変化にどのように適応しますか？
- REL4：リソース監視をどのように行いますか？
- REL5：どのように変更を実施しますか？
障害管理（Failure Management）
- REL6：どのようにデータのバックアップを行いますか？
- REL7：どのようにシステムはコンポーネント障害に耐えますか？
- REL8：どのように復旧のテストしますか？
- REL9：どのようにDR（disaster recovery）のための計画を行いますか？

信頼性に必要不可欠なサービスは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