クラウド設計・運用のベストプラクティス集「AWS Well-Architectedフレームワーク」をグラレコで解説

AWSクラウドでサービスのアーキテクチャを設計する際、

• 適切に設計するための指針となる「設計原則」を知りたい
• 設計後、アーキテクチャが適切に設計されているか、第三者の視点から客観的にチェックしたい (問題点を特定したい)

と思われたことはありませんか ?

AWS では、こういったご要望にお応えするため、「AWS Well-Architected フレームワーク」というクラウドアーキテクチャ設計のベストプラクティスに関する資料を無料で提供しています。

具体的には、「AWS Well-Architected フレームワーク」では、

• 運用上の優秀性
• セキュリティ
• 信頼性
• パフォーマンス効率
• コスト最適化

の 5 つの観点（以降、「柱」と呼びます）から、以下の資料を提供しています。

1. クラウドにおいて適切にアーキテクチャを設計するための「設計原則」に関するホワイトペーパー
2. 設計したアーキテクチャが設計原則に則っているかを確認するための質問チェックリスト

新たにアーキテクチャを設計する場合は1. の設計原則に関するホワイトペーパーを参考にアーキテクチャを設計することで、ベストプラクティスに則ったアーキテクチャを設計することができます。

また、設計済みのアーキテクチャに関しては、2. の質問チェックリストに回答することで、アーキテクチャが設計原則に則って設計されているか確認することができます。この質問チェックリストを使った確認作業を「Well-Architected レビュー」と呼びます。「Well-Architected レビュー」は、AWS が無料で提供している AWS Well-Architected Tool をお使い頂くことによりセルフサービスで実施可能ですが、支援が必要な場合は AWS Well-Architected パートナープログラムに参加している AWS パートナー、またはAWSのソリューションアーキテクトに依頼頂くことで、支援を受けながらレビューを実施して頂くことも可能です。

注意点として、「Well-Architected レビュー」はあくまでも、アーキテクチャ上の重大な問題点や改善すべき点を特定することを目的に実施します。そして、監査ではなく話し合いを目的としています。そのため誰かを非難することは NG、というルールを設けた上で、何日もかけずに数時間で手早くレビューを実施します。また、設計を細部まで作り込んでからレビューを実施すると、たとえ問題点や改善すべき点が見つかったとしても、変更が困難になる場合があります。そのため AWS では、設計の初期段階で最初のレビューを実施し、その後、本番運用開始前にもう一度レビューを実施することを推奨しています。

また、本番運用開始後も、システムに変更が行われることにより、気付かないうちに新たな問題が生じている場合があります。そのため、本番運用開始後も、定期的に「Well-Architected レビュー」を実施することをお奨めしています。

「Well-Architected レビュー」では、ビジネスに重大な悪影響を及ぼす可能性のある高リスクの問題 (High Risk Issue、略してHRI) やビジネスに悪影響を及ぼす可能性がある中リスクの問題 (Medium Risk Issue、略してMRI) を顕在化させることができます。AWS では、HRI が見つかった場合、お客様のビジネスへの重大な悪影響を防ぐためベストプラクティスに則って修正いただくよう推奨しておりますが、修正を強制することはありません。各々のお客様のビジネス上の判断により、現状維持を優先せざるを得ない場合もあるためです。そのような場合は、お客様の社内のナレッジとして蓄積していただき、次回のワークロードの設計の際に活用していただくことも可能です。「Well-Architected レビュー」では、あくまでもアーキテクチャ上の問題点を含め、現状認識をしていただき、その上でお客様のビジネス上の判断に役立てて頂くことを目的としています。

さて、冒頭で「AWS Well-Architected フレームワーク」は 5 つの柱で構成されると申し上げました。

• 運用上の優秀性
• セキュリティ
• 信頼性
• パフォーマンス効率
• コスト最適化

です。それぞれの柱に関し、見ていきましょう。