みなさま、こんにちは。石原です。先日AWS Partner向けのトレーニングコース:Well-Architected Best Practicesに参加したので学習メモとして投稿します。
本コースは、各柱の設計原則について、1つ1つ具体的に説明する形式でした。ドキュメントを読むだけでは「…?」な部分も頭の中にスッと入ってきた気がします。
Well-Architected Framework とは？
クラウド最適化のための設計・運用ノウハウを提供するフレームワーク
「システム設計・構築・運用の”大局的な”考え方とベストプラクティス集」→AWS公式ドキュメント
6つの柱
- 運用上の優秀性
- 信頼性
- セキュリティ
- パフォーマンス効率
- コスト最適化
- 持続可能性 ＊コースでは時間の関係上6つの内5つ(持続可能性以外)についてのみ
設計原則と適用
一般的な設計原則
- 必要な容量の判断を勘に頼らない。
- 本番規模でシステムをテストする。
- 自動化によってアーキテクチャの実験を簡単にする。
- 発展的なアーキテクチャを受け入れる。
- データを使用してアーキテクチャを決定する。
- ゲームデーを通して向上を図る。 ＊ゲームデー：避難訓練のようなもの
↓
各柱固有の設計原則に落とし込まれる。
適用(Well-Architected レビュー)
レビューの目的
-
連携して改善する。
→監査ではない。
必ずしもすべてを満たすことが目的ではなく、
レビューを通して、ここに改善点があるな、ここに問題があるなと気づいてビジネス的な決断をするためのもの -
実用的で実証されたアドバイス
→アーキテクチャを過度に議論する場ではない。 -
初めから終わりまでのライフサイクル
→1回限りのチェックではない。
定期的にチェックするのが推奨される。サービスが日々進化するのに合わせてWell-Architected Frameworkも進化しているから。
Toolの紹介 「AWS Well-Architected Tool」
コンソール上から無料で利用できる。手軽にレビューすることができる。
AWS公式ドキュメント
→Well-Architected Framework Review の実施方法 – パート 1
→Well-Architected Framework Review の実施方法 – パート 2
→Well-Architected Framework Review の実施方法 – パート 3
各柱の主要な設計原則
①運用上の優秀性の設計原則
-
運用をコード化する。
オペレーションにおける手作業を自動化しましょうということ
手動(ミスが多い、スケールしない、変更管理できない)から自動へ
例：CloudFormationのTemplateでリソースを起動
Systems Manager – Run Command
-
頻繁に、小さく、可逆的な変更を行う。
細かくデプロイしていくことによって、不具合があった場合に問題の切り分けがしやすくなる。
例：AWS CodePipeline、 AWS CodeCommit、 AWS CodeBuild、 AWS CodeDeploy
CI/CDパイプラインを作成する。
- 運用手順を頻繁に改良する。
- 障害を予想する。( ← ゲームデーを通して向上を図るが落とし込まれている)
- 運用上の失敗を改善に役立てる。
②信頼性の設計原則
-
障害から自動的に復旧する。 例：EC2 Auto Scaling
-
復旧手順をテストする。 例：AWS Fault Injection Simulator
-
水平方向にスケールして総合的なワークロードの可用性を向上させる。 例：AZレベルでの水平方向の冗長化
-
容量の予測が不要になる。 例：EC2 Auto Scaling
-
オートメーションで変更を管理する。 例：AWS Systems Manager – Change Manager
信頼性の柱には
「可用性や復旧可能性。いかにサービスを中断させないか。いかに障害の影響を小さくするか。
いかに信頼のおけるシステムにするか」が含まれる。
③セキュリティの設計原則
-
強力な認証基盤を整備する。 例：MFAの設定
-
トレーサビリティを整備する。
何か問題が起きた時に原因が後追いできるようにしておく。
例：AWS CloudTrail、AWS Config、VPCフローログ -
すべてのレイヤーにセキュリティを適用する。
-
セキュリティのベストプラクティスを自動化する。
問題の検出を自動化
例：CloudWatch Logsとアラーム、S3へのAmazon Macie
-
転送中および保管中のデータを保護する。
データを保護＝暗号化のこと
例：ACM、AWS KMS -
データに⼈の手を入れない。
データを人から遠ざけていく。
例： ×人 → DynamoDB 〇 人 → アプリケーション → Lambda → DynamoDB -
セキュリティイベントに備える
インシデントに対して自動で対応できるようにしておく。
例：AWS Config ルール、AWS Lambda
④パフォーマンス効率の設計原則
-
最新のテクノロジーを誰もが利用できるようにする。
-
グローバル化を即座に実現する。
-
サーバーレスアーキテクチャを使用する。
例：S3(コンテンツ配信)、Lambda(アプリケーション)、SQS(メッセージング) -
実験の頻度を増やす。
新しいサービスがリリースされたら積極的にテストする。 -
メカニカルシンパシーを考慮する。
テクノロジーの適材適所を考える。
例：すべての要求についてリレーショナルデータベース(RDS)で対応
→ 目的別に用意されたデータサービス(DynamoDB、ElastiCache)を活用する。
⑤コスト最適化の設計原則
-
クラウドの財務管理 (CFM) を実践する。
クラウドの料金体制を意識したコスト管理をする。
例：ビジネスチーム、開発チーム、財務チーム、全体がクラウドのコストを理解しておく。 -
消費モデルを導入する。
使用量とコストの動きが合っている状態が望ましい。
例：必要ないときはリソースを停止削除する。 -
全体的な効率を測定する。
コスト 対 収益 ／より大きな全体像を確認する。
例：毎月の使用料金が15%増えているが、注文数が増えて収益が35%増加 -
画一的で面倒な作業にかかる費用を排除する。
ビジネス価値をより生み出す作業に人的リソースを割く。 -
費用を分析し帰属関係明らかにする。
どこにどれだけお金がかかっているのかわかるようにする。
感想
入社してから毎日、聞かない日はない「AWSのベストプラクティスとしては…」、正直ピンと来ない部分もあったのですが、本コースを通じて少し理解が深まったかと思います。