Well Architected Frameworkとは何か。
その名の通り
Well ・・・上手に、満足に、よく
Architected ・・・設計された
Framework ・・・枠組み、骨組み
直訳すると、「上手に設計された枠組み」となる。
なんとなく、意味わかるような分からないような感じですが。。
例えば、パフォーマンス効率を上がるにはどうしたらいいか？
色々なやり方があり、キリがないと思います。
そこでWell Architected Framewrokで挙げている事を基準に設計してくださいね。そうすると、
- 信頼性があり
- パフォーマンス効率の良い
- 安全性に富んだ
- コスト最適化された
- 運用のやりやすい
AWSが作れますよっと
思ってもらうとわかりやすいかなと思う。
結論から言うと以下の５つの設計原則と１１のベストプラクティスで構成されています。
それぞれ、詳しく解説していきます。
信頼性（Reliablility）
障害による中断・停止と障害復旧による影響を軽減するインフラストラクチャーを構成する
【設計事項】
- インフラストラクチャサービスの障害復旧の自動化など軽減設計
- 復旧手順のテストによる検証
- 需要変化に応じた水平方向へのスケーラビリティによる高可用性の確保
- キャパシティの推測を止める
- モニタリングと自動化を進める
【主なAWSサービス】
信頼性の基本対応領域は基盤、変更管理、障害管理の３つ
基盤
- IAM
- VPC
- AutoScaling
- ELB
- CloudFormation
変更管理
- CloudTrail
- AWS Config
障害管理
- Cloud Watch
パフォーマンス効率（Performance Efficiency）
システム要件のリソース最適化によるインフラの効率化
設計事項
- システム要件を満たすためのコンピューティングリソースを効率化する
- システム要件やAWSサービスの進化に応じてAWSインフラの効率化を推進する
パフォーマンス効率の基本対応領域はコンピューティング、ストレージ、データベース、容量と時間のトレードオフの４つ
主要サービス
- コンピューティング
- Auto Scaling
- Lambda
- ストレージ
- EBS
- S3
- Glacier
- EFS
- データベース
- RDS
- DynamoDB
- Elastic search
- Aurora
- Redshift
- 容量と時間のトレードオフ
- CloudFront
- Elastic Cashe
安全性（Security）
AWS内のデータ／システム／アセットの保護とモニタリングによりセキュリティを高める
設計事項
- 全てのレイヤーでのセキュリティを適用
- アクセス追跡・モニタリングを確実な実施
- 条件ドリブンのアラートをトリガーとしてセキュリティイベントへの応答を自動化
- AWS責任共有モデルに基づく対象範囲の保護に集中する
- セキュリティのベストプラクティスの自動化
主要サービス
- データ保護
- ELB
- EBS
- S3
- RDS
- KMS
- 権限管理
- IAM
- MFA
- インフラ保護
- VPC
- 検出制御
- CloudTrail
- CloudWatch
- AWSGuardDuty
- AmazonInspector
コスト最適化（Cost Optimaization）
不必要なリソースの削減や最適な料金選択によりコストを削減
設計事項
- 不必要なリソース削減
- 透明性のある費用賦課
- マネージド型サービスの利用によるコスト削減
- 固定の償却コストを変動コストへと転換
- スケールによるコストメリット
- データセンターへの投資不要化
コスト最適化の基本対応領域は需要と供給の一致、コスト効率 の高いリソース、支出の認識、継続した最適化の4つ
主要サービス
- 需要と供給 の一致
- AutoScaling
- コスト効率 の高いリソース
- EC2購入方式
- TrustedAdvisor
- 支出の認識
- CloudWatch
- 見積もりツール
- 継続した 最適化
- AWS最新情報
- TrustedAdvisor
運用の優秀性（Operational Excellence）
運用上の優秀性とは計画変更が起こった場合や予期せぬイベン トの発生時において、自動化された運用実務及び文書化されテストされレビューされた手順があること
設計事項
- コードに基づく運用実施
- ビジネス目的に沿った運用手順
- 定期的かつ小規模で増加的な変更実施
- 予期せぬイベントへの応答テスト
- 運用イベントと障害からの学習
- 運用手順を最新のものに保持すること
主要サービス
- 準備
- CloudFormation
- Codeシリーズ
- RunbookPlaybook
- 運用
- SystemManager
- ServiceCatalog
- CloudTrail
- AWSArtifact
- AWSGuardDuty
- CloudWatch
- AWSConfig
- APIGateway
- 進化
- 継続的かつ段階的な改善のために時間とリソースを割り当て、運用
の有効性と効率性を向上させる
- 継続的かつ段階的な改善のために時間とリソースを割り当て、運用
11のベストプラクティス
これまで解説した５つの設計原則と１１のベストプラクティスの関係はこんな感じです。
- スケーラビリティの確保
- 需要の変化に対応できるアーキテクチャを設計する
- 環境の自動化
- システムの安定性・整合性及び組織の効率性を改善するため主要プロセスを自動化する
- 使い捨てリソースの使用
- サーバーなどのコンポーネントを一時的なリソースとして利用・設計する
- コンポーネントの疎結合
- コンポーネント間の相互依存を減らした構成とすることで、1つのコンポーネント変更や障害の影響を削減する
- サーバーではなくサービス （サーバレス）
- マネージド型サービスとサーバレスアーキテクチャにより効率的な設計と運用を実現
- 最適なデータベース選択
- ワークロードに応じた最適なデータベース技術を利用する
- 増大するデータ量対応
- IoT／ビッグデータなどで絶えず増加するデータの保持を効率的に実施する
- 単一障害点の排除
- AWSのサービスの多くは高可用が保証されているものが多いものの、EC2などはELBなどによる高可用設計が必要
- コスト最適化
- リソースが適切なサイズから必要に応じたスケールアウト・スケールインの実施と最適な料金プランの選択
- キャッシュの利用
- 繰り返し取り出すデータやコンテンツについてはキャッシュを利用する構成とする
- セキュリティの確保
- 全てのレイヤー・境界・リソース内／外においてセキュリティを実装する
まとめ
AWSを構築していく上での設計チェックリスト的な位置付けと思う。
この５つの設計原則とベストプラクティスを利用することで最適解や改善点を把握できるように
なると思うが、あくまで参考であり、絶対というものではない。
基本を忠実に、かつ自分のオリジナリティを出したAWSライフを送ってください。
ちなみに他の主要クラウドであるAzureやGCPなども同じ考えがあります。
次は【信頼性の設計】についてです。
前回の、【S3】についてはこちら
コメント