AWS Well-Architectedフレームワーク 6つの柱と設計原則

単語カード

設定全面表示

• ビジネス成果を中心にチームを編成する

  オペレーショナルエクセレンス(運用上の優秀性) チームがビジネス成果を達成する能力は、リーダーシップのビジョン、効果的な運用、ビジネスに沿った運用モデルから得られます。リーダーシップは、チームが最も効率的な方法で業務を行い、ビジネス成果を達成するようチームにインセンティブを与える適切なクラウド運用モデルを用いて、CloudOps の変革に全力で取り組む必要があります。適切な運用モデルでは、人材、プロセス、テクノロジーの能力を活用してスケールと生産性の最適化を実現し、俊敏性、即応性、適応性を通して差別化を図ります。組織の長期的なビジョンは、エンタープライズ全体にわたってステークホルダーおよびクラウドサービスや消費者に伝える目標に変換されます。目標と運用上の KPI はすべてのレベルで一致します。このプラクティスは、以下の設計原則の実装から得られる長期的な価値を維持します。
• オブザーバビリティを実装して実用的なインサイトを得る

  オペレーショナルエクセレンス(運用上の優秀性) ワークロードの動作、パフォーマンス、信頼性、コスト、健全性などを包括的に理解します。主要業績評価指標 (KPI) を設定し、オブザーバビリティのテレメトリを活用して、ビジネス成果の達成が脅かされている場合に情報に基づいた意思決定を行い、迅速に対処します。実用的なオブザーバビリティデータに基づいて、パフォーマンス、信頼性、コストを積極的に改善します。
• 可能な場合は安全に自動化する

  オペレーショナルエクセレンス(運用上の優秀性) クラウドでは、アプリケーションコードに使用するものと同じエンジニアリング原理を、環境全体に適用できます。ワークロード全体とその運用 (アプリケーション、インフラストラクチャ、設定、手順) をコードとして定義し、更新できます。その後、イベントに応じてワークロードの操作を開始することで、ワークロードの操作を自動化できます。クラウドでは、レート制御、エラーしきい値、承認などのガードレールを設定することで、自動化における安全性を実現できます。効果的な自動化により、イベントへの一貫した対応を実現し、人為的ミスを最小限に抑え、オペレーターの労力を軽減できます。
• 小規模かつ可逆的な変更を頻繁に行う

  オペレーショナルエクセレンス(運用上の優秀性) コンポーネントを定期的に更新できるように、スケーラブルで疎結合のワークロードを設計します。デプロイの自動化の手法と併せて、小さく段階的に変更していくことで、障害が発生した場合でも影響範囲を小さく抑え、迅速に復旧することができます。そのため、自信を持ってワークロードに有益な変化を加えられるようになり、一方で品質も維持し、市場の変化にも迅速に適応できます。
• オペレーション手順を頻繁に改善する

  オペレーショナルエクセレンス(運用上の優秀性) ワークロードを進化させるときは、オペレーションを適切に進化させます。運用手順を実施するときに、改善の機会を探します。定期的にレビューを実施し、すべての手順が効果的であり、チームに周知されていることを検証します。ギャップが見つかった場合は、手順を適宜更新してください。手順の更新について、すべてのステークホルダーとチームに伝えます。運用のゲーミフィケーションを行ってベストプラクティスを共有し、チームを教育します。
• 障害を予測する

  オペレーショナルエクセレンス(運用上の優秀性) 障害シナリオを進め、ワークロードのリスクプロファイルとビジネス成果への影響を把握することで、運用の成功を最大化します。こうしてシミュレートした障害に対する手順とチームの対応の有効性をテストします。テストで特定された未解決のリスクを管理するために、情報に基づいた意思決定を行います。
• 運用上のイベントとメトリクスから学ぶ

  オペレーショナルエクセレンス(運用上の優秀性) すべてのオペレーションのイベントや障害から学んだ教訓を通して、改善を推進します。チーム間と組織全体で教訓を共有します。教訓は、運用がビジネス成果にどのように貢献するかについてのデータやエピソードに焦点を当てたものである必要があります。
• マネージドサービスを使用する

  オペレーショナルエクセレンス(運用上の優秀性) 可能な限り AWS のマネージドサービスを利用して、運用上の負担を軽減します。それらのサービスの操作に関する運用手順を作成します。※持続可能性の柱にも同名の項目あり。
• 強力なアイデンティティ基盤を実装する

  セキュリティ 最小特権の原則を実装し、お客様の AWS リソースのやり取りごとに適切な承認を得て、職務の分離を強制します。アイデンティティ管理を一元化し、長期的な静的認証情報への依存を排除することを目指します。
• トレーサビリティの維持

  セキュリティ 環境に対して、リアルタイムでモニタリング、アラート、監査のアクションと変更を行います。ログとメトリクスの収集をシステムと統合して、自動的に調査してアクションを実行します。
• すべての層にセキュリティを適用する

  セキュリティ 複数のセキュリティコントロールを使用して、詳細な防御アプローチを適用します。すべての層に適用します (ネットワークのエッジ、VPC、ロードバランシング、すべてのインスタンスとコンピューティングサービス、オペレーティングシステム、アプリケーション、コードなど)。
• セキュリティのベストプラクティスの自動化

  セキュリティ 自動化されたソフトウェアベースのセキュリティメカニズムにより、迅速かつコスト効果に優れた方法で安全にスケールできます。バージョン管理されたテンプレートのコードとして定義および管理されるコントロールの実装を含む、安全なアーキテクチャを作成します。
• 転送中のデータおよび保管中のデータの保護

  セキュリティ データを機密レベルに分類し、必要に応じて暗号化、トークン化、アクセス制御などのメカニズムを使用します。
• 人をデータから遠ざける

  セキュリティ メカニズムとツールを使用して、データに直接アクセスしたり、手動でデータを処理したりする必要性を軽減または排除します。これにより、機密データを扱う際の誤処理や変更、人的ミスのリスクが軽減されます。
• セキュリティイベントの準備

  セキュリティ 組織の要件に合わせたインシデント管理および調査のポリシーとプロセスを導入し、インシデントに備えます。インシデント対応シミュレーションを実行し、ツールと自動化により、検出、調査、復旧のスピードを上げます。
• 障害から自動的に復旧する

  信頼性 ワークロードの主要業績評価指標 (KPI) をモニタリングすることで、しきい値を超えた場合に自動化を開始できます。この場合の KPI は、サービス運用の技術的側面ではなく、ビジネス価値に関する指標である必要があります。これにより、障害発生時の自動通知と追跡が可能になり、障害に対処する、または障害を修正するための復旧プロセスを自動化できます。より高度な自動化を使用すると、障害が発生する前に予測して、修復できます。
• リカバリ手順をテストする

  信頼性 オンプレミス環境では、ワークロードが特定のシナリオで動作することを実証するためのテストを行うことがよくあります。復旧戦略を検証するためにテストを実施することはあまりありません。クラウドでは、どのようにワークロードに障害が発生するかをテストし、復旧の手順を検証できます。オートメーションを使用してさまざまな障害をシミュレートすることも、以前に障害が発生したシナリオを再現することもできます。このアプローチでは、実際の障害シナリオが発生する前にテストを行い、修正できる障害経路が公開されるため、リスクが軽減されます。
• 水平方向にスケールして総合的なワークロードの可用性を高める

  信頼性 1 つの大規模なリソースを複数の小規模なリソースに置き換えることで、1 つの障害がワークロード全体に及ぼす影響を軽減します。リクエストを複数の小規模なリソースに分散することで、一般的な障害点を共有しないようにします。
• 容量を推測しない

  信頼性 オンプレミスのワークロードにおける障害の一般的な原因はリソースの飽和状態で、ワークロードに対する需要がそのワークロードの容量を超えたときに発生します (サービス妨害攻撃の目標となることがよくあります)。クラウドでは、需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化することで、プロビジョ二ングが過剰にも過小にもならない、需要を満たす最適なレベルを維持できます。制限はまだありますが、いくつかのクォータは制御でき、そのほかのクォータも管理できます (「Service Quotas と制約の管理」を参照してください)。
• 自動化で変更を管理する

  信頼性 インフラストラクチャに対する変更は、自動化を使用して実行する必要があります。管理する必要がある変更には、自動化に対する変更が含まれており、それを追跡して確認することができます。
• 高度なテクノロジーを誰でも使えるようにする

  パフォーマンス効率 複雑なタスクをクラウドベンダーに委託することによって、チームがより円滑に高度なテクノロジーを実装できるようにします。IT チームに新しいテクノロジーのホストと実行について学んでもらうのではなく、テクノロジーをサービスとして消費することを検討します。例えば、NoSQL データベース、メディアトランスコーディング、および機械学習などは、いずれも特化された専門知識を必要とするテクノロジーです。クラウドでは、これらのテクノロジーがチームが消費できるサービスとなり、チームはリソースのプロビジョニングと管理ではなく、製品の開発に集中できるようになります。
• わずか数分でグローバル展開する

  パフォーマンス効率 世界各地にある複数の AWS リージョンでのワークロードのデプロイメントは、最小限のコストで、お客様により低いレイテンシーとより良いエクスペリエンスを提供することを可能にします。
• サーバーレスアーキテクチャを使用する

  パフォーマンス効率 サーバーレスアーキテクチャにより、従来のコンピューティングアクティビティのために物理的なサーバーを実行および維持する必要がなくなります。例えば、サーバーレスストレージサービスは静的ウェブサイトとして機能させることができ (ウェブサイトサーバーが不要になる)、イベントサービスはコードをホストできます。これによって物理サーバーを管理する運用上の負担が取り除かれます。また、マネージドサービスはクラウド規模で運用されることから、トランザクションコストも削減することができます。
• より頻繁に実験する

  パフォーマンス効率 仮想および自動化可能なリソースを使用して、異なるタイプのインスタンス、ストレージ、および設定による比較テストを迅速に実行できます。
• メカニカルシンパシーを重視する

  パフォーマンス効率 クラウドサービスの使用方法を理解し、常にワークロードの目標に最適なテクノロジーアプローチを使用します。例えば、データベースやストレージのアプローチを選択するときには、データアクセスパターンを考慮します。
• クラウド財務管理の実装

  コスト最適化 クラウドで財務上の成功を達成し、ビジネス価値の実現を加速するには、クラウド財務管理およびコスト最適化に投資します。組織は、テクノロジーと使用状態の管理というこの新しい領域における能力を獲得するために、時間とリソースを投入する必要があります。コスト効率の高い組織にするには、セキュリティや優れた運用力と同様、知識の積み上げ、プログラム、リソース、プロセスを通じて能力を構築する必要があります。
• 消費モデルを導入する

  コスト最適化 必要なコンピューティングリソースの使用分のみを支払い、ビジネス要件に応じて使用量を増減します。複雑なコストの予測は必要ありません。例えば、通常、1 週間の稼働日に開発環境とテスト環境を使用するのは、1 日あたり 8 時間程度です。未使用時にこのようなリソースを停止することで、コストを 75% 削減できる可能性があります (168 時間ではなく 40 時間になる)。
• 全体的な効率を測定する

  コスト最適化 ワークロードのビジネス成果とその実現に関連するコストを測定します。この測定値を使って、成果向上とコスト削減から得られる利点を把握します。
• 差別化につながらない手間のかかる作業にコストをかけるのをやめる

  コスト最適化 サーバーのラッキング、積み上げ、電力供給などのデータセンターの手間のかかる運用作業は AWS が行います。また、マネージドサービスを使用することで、オペレーティングシステムやアプリケーションの管理に伴う運用上の負担も解消されます。この結果、IT インフラストラクチャよりも顧客やビジネスプロジェクトに集中できるようになります。
• コストを分析し帰属関係を明らかにする

  コスト最適化 クラウドでは、システムの使用状況とコストを正確に確認しやすくなり、IT コストを個々のワークロード所有者に透過的に結び付けることができます。これによって投資収益率 (ROI) を把握できるため、ワークロードの所有者はリソースを最適化してコストを削減する機会が得られます。
• 影響を理解する

  持続可能性 クラウドワークロードの影響を計測し、ワークロードの将来の影響をモデル化します。顧客がお客様の製品を使用することによる影響、および最終的に製品を廃止および使用停止する際の影響などを含む、すべての影響源を含めます。作業単位ごとに必要なリソースと排出量を確認し、生産量と、クラウドワークロードの全影響を比較します。このデータを利用して重要業績評価指標 (KPI) を作成し、影響を抑えながら生産性を向上させる方法を評価して、提案された変更による影響を経時的に見積もります。
• 持続可能性の目標を設定する

  持続可能性 クラウドワークロードごとに、持続可能性の長期目標を立てます。トランザクションごとのコンピューティングリソースやストレージリソースの削減などです。既存のワークロードに対する持続可能性向上のための投資のリターンをモデル化し、持続可能性目標に必要な投資のリソースを所有者に与えます。成長計画を立て、その成長により、ユーザー単位やトランザクション単位など適した単位に対して計測される影響の大きさが結果的に削減できるようにワークロードを構築します。目標により、ビジネスや組織のより大きな持続可能性目標の支援、回帰の特定、改善できる可能性のある分野の優先順位付けが可能になります。
• 使用率を最大化する

  持続可能性 ワークロードのサイズを適正化し効率的な設計を実装して、使用率を高く保ち、基盤となるハードウェアのエネルギー効率を最大化します。ホスト単位のベースライン電力消費量があるため、使用率 30% のホスト 2 つは、使用率 60% のホスト 1 つよりも効率が悪くなります。同時に、アイドル状態のリソース、処理、ストレージを減らすか、最小化して、ワークロードに必要な合計エネルギー量を削減します。
• より効率的なハードウェアやソフトウェアの新製品を予測して採用する

  持続可能性 パートナーやサプライヤーが行っているアップストリームの改善をサポートし、お客様のクラウドワークロードへの影響の軽減に役立てます。より効率的なハードウェアやソフトウェアの新製品を継続的にモニタリングし評価します。新しい効率的なテクノロジーを迅速に採用できるように、設計に柔軟性を持たせます。
• マネージドサービスを使用する

  持続可能性 広範な顧客ベースでサービスを共有することで、リソースの使用率を最大化できます。こうすることで、クラウドワークロードをサポートするために必要なインフラストラクチャ数を削減できます。例えば、ワークロードを AWS クラウドに移行し、サーバーレスコンテナに AWS Fargate などのマネージドサービスを採用することで、電力やネットワークなど、データセンターに共通するコンポーネントの影響を顧客間で共有できます。マネージドサービスは、AWS が大規模に運用し、効率的なオペレーションについて責任を持ちます。お客様の影響を最小化できるマネージドサービスを使用します。例えば、Simple Storage Service (Amazon S3) ライフサイクル設定を使用して、あまり頻繁にアクセスされていないデータを自動的にコールドストレージに移動したり、Amazon EC2 Auto Scaling を使用して容量を需要に合わせたりできます。※オペレーショナルエクセレンスの柱にも同名の項目あり。
• クラウドワークロードのダウンストリームの影響を軽減する

  持続可能性 お客様のサービスを使用するために必要なエネルギーやリソースの量を削減します。お客様のサービスを使用するために顧客がデバイスをアップグレードしなければならない必要性を削減します。Device Farm を使用したテストで予想される影響を理解し、顧客とともにテストしてお客様のサービスを使用することによる実際の影響を理解します。
• 〇〇の柱では、システムの実行とモニタリング、およびプロセスと手順の継続的な改善に焦点を当てています。主なトピックには、変更の自動化、イベントへの対応、日常業務を管理するための標準化などが含まれます。

  オペレーショナルエクセレンス(運用上の優秀性)
• 〇〇の柱では、情報とシステムの保護に焦点を当てています。主なトピックには、データの機密性と完全性、ユーザー許可の管理、セキュリティイベントを検出するためのコントロールが含まれます。

  セキュリティ
• 〇〇の柱は、期待通りの機能を実行するワークロードと、要求に応えられなかった場合に迅速に回復する方法に焦点を当てています。主なトピックには、分散システムの設計、復旧計画、および変化する要件への処理方法が含まれます。

  信頼性
• 〇〇の柱は、IT およびコンピューティングリソースの構造化および合理化された割り当てに重点を置いています。主なトピックには、ワークロードの要件に応じて最適化されたリソースタイプやサイズの選択、パフォーマンスのモニタリング、ビジネスニーズの増大に応じて効率を維持することが含まれます。

  パフォーマンス効率
• 〇〇の柱は、不要なコストの回避に重点を置いています。主なトピックには、時間の経過による支出の把握と資金配分の管理、適切なリソースの種類と量の選択、および過剰な支出をせずにビジネスのニーズを満たすためのスケーリングが含まれます。

  コスト最適化
• 〇〇の柱は、実行中のクラウドワークロードによる環境への影響を最小限に抑えることに重点を置いています。主なトピックには、持続可能性の責任共有モデル、影響についての把握、および必要なリソースを最小化してダウンストリームの影響を減らすための使用率の最大化が含まれます。

  持続可能性

広告

コメント