AWS Well-Architected フレームワーク

概要

• AWS Well-Architected フレームワークに記載されているAWSが推奨するアーキテクチャフレームワークについてまとめました
• 対象読者はアーキテクチャ設計に興味のある方です
• 一読してなんとなく雰囲気を掴み、必要に応じて参照するのが良いかと考えています

はじめに

• フレームワークによって、現代のクラウドベースのシステムに期待する品質を評価するための一貫したアプローチと、その品質を達成するために必要な対応を提供することが目的
• AWS Well-Architected(WA) Toolは、AWS Well-Architectedフレームワークを使ってアーキテクチャをレビューし、測定するための一貫したプロセスを提供する
• AWS WA Tool は、ワークロードを信頼性が高く、よりセキュアかつ効率的で、コスト効率性に優れたものにするためのレコメンデーションを提供します
• ベストプラクティスの適用をサポートするためにAWS Well-Architected Labsが作成された
• このラボでは、コードとドキュメントのリポジトリを使用してベストプラクティスの実装を実践的に体験できる

用語解説

• コンポーネント
  • 用件に対して提供されるコード、設定、AWSリソース
• ワークロード
  • ビジネス価値を提供する一連のコンポーネントを識別するために使用
• マイルストーン
  • アーキテクチャが設計、テスト、ゴーライブ、及び本番という製品ライフサイクル全体を通じて進化するにあたり、アーキテクチャにおける重要な変更を記録
• アーキテクチャ
  • コンポーネントがワークロードで連携する方法。コンポーネントが通信や対話を行う方法は、アーキテクチャ図の中心となることがよくある
• テクノロジーポートフォリオ
  • ビジネスの運営に必要なワークロードの集合体

AWS Well-Architected フレームワークの5本柱

ワークロードを設計するときには、ビジネスの状況に応じて5本の柱の間でトレードオフを行う

• 開発環境では新rな異性を犠牲にすることでコストを削減する
• ミッションクリティカルなソリューションでは、信頼性を最適化するためにコストをかける
• eコマースソリューションでは、パフォーマンスが収益と顧客の購買傾向に影響する
  など
  セキュリティと運用性は、通常、他の柱とトレードオフされることはない

運用上の優秀性

ビジネス価値を提供し、サポートのプロセスと手順を継続的に向上させるためにシステムを稼働及びモニタリングする能力

セキュリティ

リスク評価とリスク軽減の戦略を通してビジネスに価値をもたらす、情報、システム、アセットのセキュリティ保護機能

信頼性

インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、語設定や一時的なネットワークの問題といった中断の影響を緩和する能力

パフォーマンス効率

システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力

コスト最適化

最も低い価格でシステムを運用してビジネス価値を実現する能力

一般的な設計の原則

クラウド上における適切な設計を可能にする一般的な設計の原則

• 必要キャパシティーの推測が不要になる
  • クラウドコンピューティングでは、必要な分のみキャパシティーを使用し、自動的にスケールアップまたはスケールダウンできる
• 本稼働スケールでシステムをテストする
  • クラウド上では、本稼働スケールのテスト環境をオンデマンドで作成し、テスト完了後にリソースを解放できる
• 自動化によってアーキテクチャでの実験を容易にする
  • 自動化によって低コストでシステムを作成及びレプリケートして、手動作業の支出を回避できる
• 発展するアーキテクチャが可能になる
  • クラウド上では、自動化し、オンデマンドでテストできるので、設計変更によって生じる影響のリスクを軽減できる
  • その他め、イノベーションを標準プラクティスとしてビジネスで活用できるように、システムを時間と共に進化させることができる
• データに基づいてアーキテクチャを進化させる
  • クラウドのインフラストラクチャはコードなので、そのデータに基づいてアーキテクチャに関する選択と改善を徐々に進めることができる
• ゲームでーを利用して改善する
  • ゲームでーを定期的にスケジュールして、本稼働環境のイベントをシミュレートすることで、アーキテクチャとプロセスのパフォーマンスをテストする

運用上の優秀性

運用上の優秀性
運用上の優秀性の柱には、ビジネス価値を提供し、サポートのプロセスと手順を継続的に向上させるためにシステムを稼働及びモニタリングする能力が含まれる

設計原則

• 運用をコードとして実行する
• ドキュメントに注釈をつける
• 定期的に、小規模な、元に戻すことができる変更を適用する
• 運用手順を定期的に改善する
• 障害を予想する
• 運用上の全ての障害から学ぶ

3つのベストプラクティス

準備

• アプリケーション、プラットフォーム、インフラストラクチャのコンポーネント、およびカスタマーエクスペリエンスと顧客の行動をモニタリングし、インサイトを取得するメカニズムを使用してワークロードを設計する
• ワークロードまたは変更が本番環境に移行できる状態であり、運用上、サポートされていることを検証するためのメカニズムを作成する
• 運用準備状態はチェックリストを使用して検証し、ワークロードが規定の標準を満たしていることと、必要な手順がランブックとプレイブックに適切に記載されていることを確認する
• ワークロードを効果的にサポートするために、十分にトレーニングを受けた担当者がいることを確認する
• 移行前に、運用上のイベントと障害への応答をテストする
• 障害の投入やゲームデーイベントによって、サポートされる環境で応答を練習する
• 運用アクティビティをコードとして実装することに投資することにより、運用担当者の生産性を最大に引き上げ、エラーの発生を最小限に抑え、自動応答を可能にする
• クラウドの伸縮性を活用したデプロイ方法を導入し、システムの事前デプロイを促進して実装を高速化する

運用

• 予想される成果を定義し、成功を評価する方法を決定する
• また、運用が成功したかどうかを判断するための計算で使用するワークロードと運用のメトリクスを特定する
• ワークロードの状態と、そのワークロードで実行する運用の状態と成功 (デプロイとインシデント対応など) の両方を含めて、運用の状態を検討する
• 運用の向上または低下を特定するための基準を確立し、メトリクスを収集および分析する
• 次に、運用の成功に関する理解と、時間の経過とともにどのように変化するかについて検証する
• 収集したメトリクスを使用して、顧客とビジネスのニーズを満たしているかどうかを確認し、改善の余地がある分野を特定する
• 運用上の優秀性を実現するには、運用上のイベントを効率的かつ効果的に管理する必要がある
• これには、計画した運用上のイベントと計画外の運用上のイベントの両方が含まれる
• 十分に把握しているイベントには既定のランブックを使用し、その他のイベントの解決にはプレイブックを使用する
• ビジネスと顧客への影響に基づいてイベントへの応答に優先順位を付ける
• イベントへの応答でアラートが発生する場合、実行する関連プロセスがあり、所有者が具体的に指名されていることを確認する
• イベントを解決する担当者を事前に決めておき、影響 (期間、規模、範囲) に基づいて、必要に応じて他の担当者を関与させるためにエスカレーションするトリガーを含める
• 以前に処理したことがないイベント応答によってビジネスに影響が及ぶ場合は、アクションの方針を決定する権限を持つ担当者を特定し、関与させる
• 日常的な運用や計画外のイベントへの応答は自動化する必要がある
• デプロイ、リリース管理、変更、ロールバックについて、手作業のプロセスは避ける必要がある
• リリースは、低頻度で行われる大規模なバッチ処理にしないようにする

進化

• 継続的かつ段階的な改善を行うために専用の作業サイクルを作成する
• ワークロードと運用手順の両方について、改善の機会 (機能のリクエスト、問題の修正、コンプライアンス要件など) を定期的に評価し、優先順位を付ける
• 手順にフィードバックループを取り入れ、改善が必要な分野をすばやく特定し、実際に運用して教訓を学ぶ
• チーム間で学んだ教訓を共有し、その教訓の利点を活用する
• 学んだ教訓に見られる傾向を分析し、運用のメトリクスに関してチーム間で遡及的分析を行い、改善の機会とその方法を特定する
• 改善をもたらす変更を実施し、結果を評価して成功の判断を行う
• 運用の進化を成功させるためには、頻繁な小規模の改善、実験と開発およびテストの改善のための安全な環境と時間、失敗から学ぶことを推奨する環境が重要

主なAWSのサービス

運用上の優秀性に不可欠なAWS のサービスは AWS CloudFormation であり、ベストプラクティスに基づいたテンプレートを作成できる
これにより、開発環境から本番環境まで規則的で一貫した方法でリソースをプロビジョンできる

• 準備
  • AWS Config と AWS Config のルールを使用して、ワークロードの標準を作成し、本番稼働の前に環境がその標準に準拠しているかどうかを確認できる
• 運用
  • Amazon CloudWatch では、ワークロードの運用状態をモニタリングできる
• 進化
  • Amazon Elasticsearch Service (Amazon ES) を使用すると、ログデータを分析し、実用的なインサイトをすばやく確実に取得できる

リソース

Operational Excellence Pillar
DevOps - ユースケース別クラウドソリューション
AWS re:Invent 2015: DevOps at Amazon: A Look at Our Tools and Processes (DVO202) - YouTube

セキュリティ

セキュリティ
セキュリティの柱には、リスク評価とリスク軽減の戦略を通してビジネスに価値をもたらす、情報、システム、アセットのセキュリティ保護機能が含まれる

設計原則

• 強力なアイデンティティ基盤の実装
• トレーサビリティの実現
• 全レイヤーへのセキュリティの適用
• セキュリティのベストプラクティスの自動化
• 伝送中および保管中のデータの保護
• データに人の手を入れない
• セキュリティイベントへの備え

5つのベストプラクティス

アイデンティティ管理とアクセス管理

• アイデンティティ管理とアクセス管理は情報セキュリティプログラムの重要な要素であり、これにより顧客が意図した仕方で、承認され認証されたユーザーのみがリソースにアクセスできる
• 例えば、プリンシパル (顧客のアカウントに対してアクションをとるユーザー、グループ、サービス、ロール) を定義し、これらのプリンシパルに合わせたポリシーを構築し、強力な認証情報管理を実装できる
• これらの権限管理機能は認証と承認の中枢となっている
• すべてのユーザーやシステムが認証情報を共有してはいけない
• ユーザーアクセス権は、パスワード要件や MFA の強制などのベストプラクティスを実践した上で、最小権限で与えられるべき

発見的統制

• 発見的統制により、セキュリティの潜在的な脅威やインシデントを特定できる
• これはガバナンスフレームワークの最重要機能であり、品質管理プロセス、法的義務またはコンプライアンス義務、脅威の特定とその対応のサポートのために、この機能を使用できる
• ログ管理は、セキュリティやフォレンジックから規制要件や法的要件まで十分に対応できる、優れたアーキテクチャを設計するために重要
• 潜在的なセキュリティインシデントを特定するために、ログの分析とそれに対する対応は特に重要

インフラストラクチャ保護

• インフラストラクチャ保護には、ベストプラクティスと組織の義務または規制上の義務に準拠するために必要な、深層防御などの制御手段が含まれている
• すべての環境で複数レイヤーを防御するのが賢明
• 境界保護の強制、イングレスおよびエグレスのモニタリングポイント、包括的なログ記録、モニタリング、アラートはすべて、効果的な情報セキュリティ計画には必須

データ保護

• システムを設計する前に、セキュリティに影響を与える基本的なプラクティスを実施する必要がある
• 例えば、データ分類は組織のデータを機密性レベルに基づいてカテゴリーに分類し、暗号化は認証されていないアクセスに対してデータが開示されてしまうことを防ぐ
• これらのツールやテクニックは、金銭的な損失の予防や規制遵守という目的を達成するためにも重要

インシデント対応

• 非常に優れた予防的、発見的統制が実装されていてもなお、組織はセキュリティインシデントの潜在的な影響に対応し、影響を緩和する手段を講じる必要がある
• ワークロードのアーキテクチャは、インシデントの際にチームが効果的に対応できるかどうか、システムを隔離するかどうか、運用を既知の正常な状態に復元できるかどうかに大きく影響する
• セキュリティインシデントが起きる前にツールとアクセスを実践し、本番を想定したインシデント対応を定期的に実施することで、タイムリーな調査と復旧を可能にするアーキテクチャを構築できる

主要なAWSのサービス

セキュリティに不可欠なAWS のサービスは AWS Identity and Access Management (IAM) であり、これにより、AWS のサービスとリソースへのユーザーアクセスを保護して管理できる

• アイデンティティ管理とアクセス管理
  • IAM により、AWS のサービスとリソースへのアクセスを保護して管理できる
  • MFA は、ユーザーアクセスに保護レイヤーを追加する
  • AWS Organizations により、複数の AWS アカウントのポリシーを一元的に管理・強制できる
• 発見的統制
  • AWS CloudTrail は AWS API コールを記録し、AWS Config は AWS のリソースと設定の詳細なインベントリを提供する
  • Amazon GuardDuty は、悪意のある動作や不正な動作を継続的にモニタリングする、マネージド型の脅威検出サービス
  • Amazon CloudWatch は、CloudWatch Events をトリガーしてセキュリティ対応を自動化できる、AWS リソースのモニタリングサービス
• インフラストラクチャ保護
  • Amazon Virtual Private Cloud (Amazon VPC) を使用して、顧客が定義した仮想ネットワーク内で AWS リソースを起動できる
  • Amazon CloudFront は、DDoS を緩和する AWS Shield に統合されたビューワーに対して、データ、動画、アプリケーション、API を安全に提供する、グローバルコンテンツ配信ネットワーク
  • AWS WAF は、ウェブの一般的な脆弱性からウェブアプリケーションを保護するために役立つ、Amazon CloudFront または Application Load Balancer にデプロイされたウェブアプリケーションファイアウォール
• データ保護
  • ELB、Amazon Elastic Block Store (Amazon EBS)、Amazon S3、Amazon Relational Database Service (Amazon RDS) などのサービスには、伝送中および保管中のデータを保護する暗号化機能が含まれている
  • Amazon Macie は、機密性の高いデータを自動で発見し、分類し、保護する
  • AWS Key Management Service (AWS KMS) は、暗号化に使用するキーの作成と管理を容易にする
• インシデント対応
  • IAM は、インシデント対応チームと対応ツールに適切な承認を与えるために使用する
  • AWS CloudFormation は、調査を実施する際の信頼できる環境やクリーンルームを作成するために使用できる
  • Amazon CloudWatch Events を使用すれば、AWS Lambda などの自動化されたレスポンスをトリガーするルールを作成できる

リソース

Security Pillar
クラウドセキュリティ
AWS クラウドコンプライアンス
AWS Security Blog
Overview of Security Processes
AWS Security Best Practices
Risk and Compliance
AWS re:Invent 2017: AWS Security State of the Union (SID326) - YouTube
AWS Compliance - The Shared Responsibility Model - YouTube

信頼性

信頼性
信頼性の柱には、インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や一時的なネットワークの問題といった中断の影響を緩和する能力が含まれる

設計原則

• 復旧手順をテストする
• 障害から自動的に復旧する
• 水平方向にスケールしてシステム全体の可溶性を高める
• キャパシティーを推測しない
• オートメーションで変更を管理する

3つのベストプラクティス

基盤

• システムを設計する前に、信頼性に影響を与える基本的な要件を満たしておく必要がある
• 例えば、データセンターへの十分なネットワーク帯域幅が必要
• このような要件は、単一のプロジェクトの範囲を超えているため、無視される場合がある
• この点を無視すると、システムの信頼性の達成に多大な影響が及ぶ

変更管理

• 変更がシステムに及ぼす影響に注意していれば、事前に計画できるようになる
• モニタリングによってキャパシティーの問題や SLA 違反につながりかねない傾向をすばやく識別できる
• 従来の環境では、変更管理プロセスはしばしば手動で行われ、誰がいつ変更するかを効果的に制御するには、監査との注意深い連携が必要
• 需要の変動に対応してリソースの追加や削除を自動で行うシステムを設計しておけば、信頼性が高まることに加え、ビジネスの成功が負担に変わってしまうことを避けられる
• モニタリングを実行しておけば、KPI が予測された基準から逸脱すると、アラートが自動的にチームに送られる
• 環境の変更は自動的にログに記録されるため、アクションを監査して、信頼性に影響を与える可能性のあるアクションを特定できる
• 変更管理をコントロールすることで、必要な信頼性を実現するためのルールに効力を持たせることができる

障害の管理

• どのようなシステムでも、ある程度複雑になると障害が発生することが予想される
• そのため、それらの障害をどのように検出して対応し、再発を防止するかが問題
• 定期的にデータをバックアップして、バックアップファイルをテストすることで、論理的および物理的なエラーから確実に復旧できるようになる
• 障害の管理で重要なのは、システムに対し自動化されたテストを頻繁に実施して障害を発生させ、どのように復旧するかを確認すること
• このようなテストは定期的なスケジュールでも大きなシステム変更後にトリガーされる
• KPI を積極的に追跡し、目標復旧時間 (RTO)、目標復旧時点 (RPO)、システムの回復力を評価する
• KPI の追跡は、単一障害点を特定して排除するのに役立る
• 目的は、システム復旧プロセスを徹底的にテストして、問題が持続する場合でも、すべてのデータを復旧し、サービスを顧客に提供し続けられることを確認すること
• 復旧プロセスも、通常の本番プロセスと同じように実施する必要がある

主要なAWSのサービス

信頼性に不可欠なAWS のサービスは Amazon CloudWatch であり、はランタイムメトリクスをモニタリングする

• 基盤
  • AWS IAM により、AWS のサービスとリソースへのアクセスを保護して管理できる
  • Amazon VPC では、AWS クラウドのプライベートで孤立したセクションをプロビジョニングできる
  • ここでは、顧客が定義する仮想ネットワークで AWS リソースを起動できる
  • サービスの制限は AWS Trusted Advisor で可視化できる
  • AWS Shield はマネージド型分散サービス妨害攻撃 (DDoS) 防止サービスで、AWS で実行されるウェブアプリケーションを保護する
• 変更管理
  • AWS CloudTrail ではアカウントの AWS API コールが記録され、監査のためにログファイルが送られる
  • AWS Config は AWS のリソースと設定の詳細なインベントリを提供し、設定内容の変更を継続的に記録する
  • Amazon Auto Scaling はデプロイされたワークロードに対して需要管理の自動化を実現する
  • Amazon CloudWatch には、カスタムメトリクスなどのメトリクスに基づいてアラートを送る機能がある
  • Amazon CloudWatch にはロギング機能があり、複数のリソースのログファイルを集約することができる
• 障害の管理
  • AWS CloudFormation には、AWS リソースを作成し、予測可能な方法で順番にプロビジョニングするためのテンプレートが用意されている
  • Amazon S3 はバックアップの保存先として耐久性の高いサービス
  • Amazon Glacier には耐久性の高いアーカイブを保存できる
  • AWS KMS は信頼性の高いキー管理システムで、AWS のサービスの多くと統合されている

リソース

Reliability Pillar
AWS のサービスの制限を管理する
AWS re:Invent 2014 | (PFC305) Embracing Failure: Fault-Injection and Service Reliability - YouTube
AWS Limit Monitor
AWS Service Quotas
Amazon EC2 Service Limits Report Now Available
What Is Amazon VPC?
AWS Shield
What Is Amazon CloudWatch?
What is Amazon S3?
What is AWS Key Management Service?
Backup, Archive, and Restore Approaches Using AWS
Managing Your AWS Infrastructure at Scale
Amazon Virtual Private Cloud Connectivity Options
AWS サポート
Trusted Advisor

パフォーマンス効率

パフォーマンス効率
パフォーマンス効率の柱には、システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力が含まれる

設計原則

• 最新テクノロジーの標準化
• 数分でグローバルに展開
• サーバーレスアーキテクチャを使用
• より頻繁に実験可能
• システムを深く理解

4つのベストプラクティス

選択

• システムにとって最適なソリューションは、顧客のワークロードの種類に応じて異なる
• 多くの場合、複数のアプローチを組み合わせて使用する
• 優れた設計のシステムでは複数のソリューションが使用され、さまざまな機能によってパフォーマンスが改善される
• アーキテクチャでは通常、アーキテクチャに関するさまざまなアプローチが組み合わされて使用される (イベント駆動型、ETL、パイプラインなど)
• アーキテクチャを実装する場合は、アーキテクチャのパフォーマンスを最適化するための AWS のサービスが使用される
  顧客が検討すべき4つの主なリソースタイプ (コンピューティング、ストレージ、データベース、ネットワーク) は以下になる

コンピューティング

システムにとって最適なコンピューティングソリューションは、アプリケーションの設計、使用パターン、設定に応じて異なる
各アーキテクチャでは、コンポーネントごとに異なるコンピューティングソリューションが使用されることもあり、パフォーマンスを向上させるための機能も異なる
アーキテクチャに対して適切でないコンピューティングソリューションを選択すると、パフォーマンス効率が低下する場合がある

ストレージ

システムにとって最適なストレージソリューションは、アクセス方法 (ブロック、ファイル、オブジェクト)、アクセスパターン (ランダムまたはシーケンシャル)、必要なスループット、アクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度 (WORM、動的)、および可用性と耐久性に関する制約に応じて異なる
優れた設計のシステムでは複数のストレージソリューションが使用され、さまざまな機能によってパフォーマンスが改善される

データベース

システムにとって最適なデータベースソリューションは、可用性、整合性、パーティション対応性、レイテンシー、耐久性、スケーラビリティ、クエリ機能などの要件に応じて異なる
多くのシステムでは、各種サブシステムに異なるデータベースソリューションを使用しているため、パフォーマンスを向上させるために活用する機能も異なる
システムに対して適切でないデータベースソリューションや機能を選択すると、パフォーマンス効率が低下する場合がある

ネットワーク

システムにとって最適なネットワークソリューションは、レイテンシーやスループットなどの要件によって異なる
場所のオプションはユーザーリソースやオンプレミスリソースなどの物理的制約の影響を受けるが、最新技術を使用することやリソースを置き換えることで、こうした影響を軽減できる

レビュー

• ソリューションを設計するときは、選択できるオプションが限られていても、時間が経つにつれ、アーキテクチャのパフォーマンスを向上させることができる新しいテクノロジーやアプローチが利用できるようになる
• アーキテクチャのどの部分でパフォーマンスが制約されているかを把握することで、そうした制約を緩和できるリリースを見つけることができる

モニタリング

• アーキテクチャの実装後は、顧客が発見する前に問題を修正できるよう、アーキテクチャのパフォーマンスをモニタリングする必要がある
• モニタリングメトリクスを使用して、メトリクスがしきい値を超えたときにアラームを発生させるようにする
• アラームを使用すれば、正しく動作していないコンポーネントが見つかったときに、そのコンポーネントを回避するための自動アクションをトリガーできる
• 効果的にモニタリングするには、大量の誤検出を発生させたり、大量のデータに振り回されたりしないことが重要
• 自動化されたトリガーを使用すれば、ヒューマンエラーを防ぐことができ、問題解決までの時間を短縮できる
• アラームソリューションをテストするシミュレーションを本番環境で実行するゲームデーを計画し、そのソリューションが問題を正しく認識するか確認する

トレードオフ

• ソリューションのアーキテクチャを設計する場合は、トレードオフを考慮して最適なアプローチを選択する
• より高いパフォーマンスを実現できるように、整合性、耐久性、容量を重視するのか、時間またはレイテンシーを重視するのかを、顧客の状況に応じてトレードオフしなければならない
• トレードオフを行うことで、アーキテクチャが複雑になる可能性がある
• トレードオフを行った場合は、ロードテストを実施して、トレードオフによって目に見える効果が得られたか確認する必要がある

主要なAWSのサービス

パフォーマンス効率に不可欠なAWS のサービスは Amazon CloudWatch であり、リソースとシステムをモニタリングし、全体的なパフォーマンスと動作状況を可視化する

• 選択
  • コンピューティング
    • 需要に対応し、応答性を維持するための十分なインスタンスを確保するには、Auto Scaling が重要
  • ストレージ
    • Amazon EBS では、ユースケースを最適化できる幅広いストレージオプション (SSD、プロビジョニングされた 1 秒あたりの入力/出力オペレーション数 (PIOPS) など) 利用できる
    • Amazon S3 では、サーバーレスのコンテンツ配信機能が用意されている
    • Amazon S3 Transfer Acceleration を使用すれば、すばやく簡単かつセキュアにファイルを長距離転送できる
  • データベース
    • Amazon RDS では、ユースケースを最適化できる幅広いデータベース機能が用意されている (PIOPS やリードレプリカなど)
    • Amazon DynamoDB は、あらゆる規模で 10 ミリ秒未満のレイテンシーを実現する
  • ネットワーク
    • Amazon Route 53 では、レイテンシーベースのルーティングが用意されている
    • Amazon VPC エンドポイントおよび AWS Direct Connect を使用すれば、ネットワークの距離を縮めたり、ジッターを減らしたりできる
• レビュー
  • AWS ブログと AWS ウェブサイトの「最新情報」セクションで、新たに利用できるようになった機能とサービスを確認できる
• モニタリング
  • Amazon CloudWatch で提供されているメトリクスやアラーム、通知を顧客の既存のモニタリングソリューションに組み込んだり、AWS Lambda と組み合わせてアクションをトリガーしたりできる
• トレードオフ
  • Amazon ElastiCache、Amazon CloudFront、AWS Snowball は、パフォーマンスの向上を可能にするサービス
  • Amazon RDS でレプリカを読み込めば、読み込み負荷が高いワークロードをスケーリングできる

リソース

Performance Efficiency Pillar
Best Practices Design Patterns
Amazon EBS Volume Performance on Linux Instances
AWS re:Invent 2016: Scaling Up to Your First 10 Million Users (ARC201) - YouTube
AWS re:Invent 2017: Deep Dive on Amazon EC2 Instances, Featuring Performance Optimiz (CMP301) - YouTube

コスト最適化

コスト最適化
コスト最適化の柱には、最も低い価格でシステムを運用してビジネス価値を実現する能力が含まれる

設計原則

• 消費モデルを導入する
• 全体的な効率を測定する
• データセンター運用のための費用を排除する
• 費用を分析し、帰結させる
• アプリケーションレベルのマネージドサービスを使用して所有コストを削減する

4つのベストプラクティス

費用認識

• 多くのビジネスは、さまざまなチームが運用する複数のシステムによって構成されている
• リソースのコストをそれぞれの組織や製品オーナーに帰属させることができると、リソースを効率的に使用し、無駄を削減できる
• コストの帰属を明確にすることで、実際に利益率の高い製品を把握し、予算の配分先についてより多くの情報に基づいた決定ができるようになる

費用対効果の高いリソース

• ワークロードにとって適切なインスタンスとリソースを使用することが、コスト削減の鍵になる
• たとえば、レポート処理を小規模なサーバーで実行すると 5 時間かかるものの、費用が 2 倍の大規模なサーバーでは 1 時間で実行できるとすると、どちらのサーバーでも同じ結果が得らるが、長期的に見れば小規模なサーバーで発生するコストの方が大きくなる
• 優れた設計のワークロードでは最もコスト効率の良いリソースが使用されるため、大幅にプラスの経済的影響が生じる
• マネージドサービスを使用することで、コストを削減できる場合もある
• 例えば、E メールを配信するためにサーバーを保守することなく、メッセージ単位で料金が発生するサービスを使用できる

需要と供給を一致させる

• 需要と供給を最適に一致させることでワークロードのコストを最低限に抑えることができるが、プロビジョニングの時間と個々のリソースの障害に備えて十分に余裕を持った供給も必要
• 需要が一定の場合も変動する場合もあり、管理に多大なコストがかからないようにメトリクスと自動化が必要

長期的な最適化

• AWS では新しいサービスと機能がリリースされるため、既存のアーキテクチャの決定をレビューし、現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティス
• 要件の変化に応じて、不要になったリソース、サービス全体、システムを積極的に廃止しなければならない

主要なAWSのサービス

コスト最適化に不可欠なツールは Cost Explorer であり、ワークロードと組織の全体にわたり、使用量を可視化して深く理解するのに役立つ

• 費用認識
  • AWS Cost Explorer を使用すると、詳細な使用状況の確認と追跡が行える
  • AWS Budgets では、使用量や費用が実際の、または事前の予算範囲を超えたときに通知が送付される
• 費用対効果の高いリソース
  • リザーブドインスタンスのレコメンデーションに Cost Explorer を利用すると、これまでの AWS リソースに対する支払いパターンを確認できる
  • Amazon CloudWatch と Trusted Advisor を使用して、リソースを適切にサイジングする
  • RDS で Amazon Aurora を使用すると、データベースのライセンスコストを排除できる
  • AWS Direct Connect と Amazon CloudFront を、データ転送の最適化に使用できる
• 需要と供給を一致させる
  • Auto Scaling を使用すると、浪費することなく、需要に対応するようにリソースの追加や削除を行うことができる
• 長期的な最適化
  • AWS ニュースブログと AWS ウェブサイトの最新情報セクションには、新しくリリースされた機能やサービスについて案内するリソースがある
  • AWS Trusted Advisor で AWS 環境を検査すると、未使用のリソースやアイドル状態のリソースを削除することや、リザーブドインスタンスのキャパシティーを活用することで費用を節約する方法を見つけることができる

リソース

Cost Optimization Pillar
Analyzing Your Costs with Cost Explorer
エコノミクスセンター
What Are AWS Cost and Usage Reports?
AWS 総所有コスト（TCO）計算ツール
AWS Simple Monthly Calculator
AWS re:Invent 2017: Running Lean Architectures: How to Optimize for Cost Efficiency (ARC303) - YouTube

レビュープロセス

• アーキテクチャの評価は非難せずに掘り下げることができる一貫した方法で実施される必要がある
• これは何日もかけずに数時間で終わる軽いプロセスである必要がある
• 話し合いであり、監査ではない
• アーキテクチャレビューの目的は、対策を必要とする重大な問題や改善可能な領域を特定すること
• レビュー結果は、ワークロードの扱いやすさを改善する対策
• 各チームメンバーがアーキテクチャの品質に責任を持つ必要がある
• レビューを継続することで、チームメンバーはアーキテクチャの変化に応じて回答を更新したり、機能を提供しながらアーキテクチャを改善したりすることができる
• 設計の初期段階におけるレビューを実施する
• 本番運用前にもレビューを行う
• 本稼働開始後に新しい機能を追加したり、テクノロジーの実装を変更したりするにつれて、ワークロードは変化し続け、ワークロードのアーキテクチャは時間とともに変わるので、その変化にともなってアーキテクチャの特性が劣化しないように適切な予防策を取る必要がある
• アーキテクチャを大幅に変更するときには、Well-Architected レビューを含めて、予防プロセスに従う必要がある
• 1 回限りのレビューまたは単独の測定として評価を活用するには、すべての適切な関係者をその話し合いに含める必要がある
• 別のチームのワークロードをレビューするときに有効な方法は、そのアーキテクチャについて何度か気軽に話し合うこと
• 会議を進行するために推奨されるアイテム
  • ホワイトボードのある会議室
  • 印刷した構成図や設計ノート
  • 回答に別途調査が必要な質問のアクションリスト（例えば「暗号化を有効にしましたか？」など）
• レビューを完了すると、問題のリストが出来上がる
• ビジネスの状況に応じてその優先順位を決める
• 課題がチームの日常業務に及ぼす影響を考慮する必要もある
• 課題に早く対処することで、ビジネス価値の想像に費やす時間ができる
• 課題に対処しながらレビューを更新することで、アーキテクチャがどのように改善しているのかを知ることができる
• 組織内の他のチームと何度かレビューを実施すると、主題となる課題が見つかるかもしれない
• すべてのレビューを総合的に検討し、それらの主題に関する課題に対処するのに役立つメカニズム、トレーニング、またはプリンシパルエンジニアリングの説明を見つける必要がある