準備 - AWS Well-Architected フレームワーク

準備

OPS 4 ワークロードの状態を理解するために、ワークロードをどのように設計すればよいですか?

ワークロードを設計する際には、すべてのコンポーネント (メトリクス、ログ、トレースなど) にわたって内部状態を理解するために必要な情報が送出されるようにします。そうすることによって、適時に有用な返答を提供できるようになります。

ベストプラクティス:

  • アプリケーションテレメトリーを実装する: 内部状態、ステータス、ビジネス成果の達成に関する情報が送出されるように、アプリケーションコードをインストルメント化します。例えば、キューの長さ、エラーメッセージ、応答時間などの情報です。この情報を使用して、応答が必要とされるタイミングを特定します。

  • ワークロードテレメトリーを実装して設定する: 内部状態や現在のステータスに関する情報が送出されるように、ワークロードを設計および設定します。例えば、API 呼び出しボリューム、HTTP ステータスコード、スケーリングイベントなどの情報です。この情報を使用して、応答が必要とされるタイミングを特定します。

  • ユーザーアクティビティテレメトリーを実装する: ユーザーアクティビティに関する情報 (クリックストリームのほか、開始、放棄、完了済みトランザクションなど) が送出されるように、アプリケーションコードをインストルメント化します。この情報を使用して、アプリケーションの使用方法や使用パターンを理解したり、応答が必要とされるタイミングを特定したりできます。

  • 依存関係のテレメトリーを実装する: 依存するリソースの状態 (到達可能性や応答時間など) に関する情報を出力するように、ワークロードを設計および設定します。外部依存関係の例としては、外部データベース、DNS、ネットワーク接続などがあります。この情報を使用して、応答が必要とされるタイミングを特定します。

  • トランザクショントレーサビリティを実装する: ワークロード全体のトランザクションフローに関する情報が送出されるように、アプリケーションコードを実装し、ワークロードコンポーネントを設定します。この情報を使用して、応答が必要とされるタイミングを特定し、問題につながる要素の特定に役立てます。

OPS 5 欠陥を減らし、修正を簡単にし、本番環境へのフローを改善するにはどうすればよいですか?

リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。

ベストプラクティス:

  • バージョン管理を使用する: バージョン管理を使用して、変更とリリースの追跡を有効にします。

  • 変更をテストし、検証する: 変更をテストして検証し、エラーの制限と検出に役立てます。手動プロセスによって発生するエラーと、テストにかかる労力を減らすためにテストを自動化します。

  • 設定管理システムを使用する: 設定を変更し、変更を追跡記録するには、構成管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。

  • 構築およびデプロイ管理システムを使用する: 構築およびデプロイ管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。

  • パッチ管理を実行する: パッチ管理を実行し、問題を解決して、ガバナンスに準拠するようにします。パッチ管理の自動化により、手動プロセスによって発生するエラーと、パッチにかかる労力を減らすことができます。

  • 設計標準を共有する: チーム全体でベストプラクティスを共有し、デプロイ作業の認識を高めて利点を最大化します。

  • コード品質の向上のためにプラクティスを実装する: コード品質の向上のためにプラクティスを実装し、不具合を最小限に抑えます。たとえば、テスト駆動型デプロイ、コードレビュー、標準の導入などがあります。

  • 複数の環境を使用する: 複数の環境を使用して、ワークロードの実験、開発、テストを行います。環境が本稼働環境に近づくにつれて増加するコントロールレベルを使用して、デプロイ時にワークロードが意図したとおりに運用するように確信を強化します。

  • 小規模かつ可逆的な変更を頻繁に行う: 頻繁に小規模で可逆的な変更を行うことで、変更の範囲と影響を縮小します。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また変更を元に戻すこともできます。

  • 統合とデプロイを完全自動化する: ワークロードのビルド、デプロイ、テストを自動化します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。

OPS 6 デプロイのリスクを軽減するにはどうすればよいですか?

品質に関する迅速なフィードバックを提供し、望ましい結果をもたらさない変更から迅速に復旧できるようにするアプローチを採用します。このような手法を使用すると、変更のデプロイによって生じる問題の影響を軽減できます。

ベストプラクティス:

  • 変更の失敗に備える: 変更によって望ましい結果が得られない場合に、既知の良好な状態に戻すか、本番環境で修正を行うことを計画します。この準備を行うことで、迅速な対応によって復旧時間を短縮できます。

  • 変更をテストし、検証する: ライフサイクルのすべての段階で変更をテストし、結果を検証して新しい機能を確認するとともに、デプロイの失敗によるリスクと影響を最小限に抑えます。

  • デプロイ管理システムを使用する: デプロイ管理システムを使用して変更を追跡および実装します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。

  • 限定的なデプロイを使用してテストする: 完全なデプロイを行う前に、既存のシステムと並行して限定的なデプロイを実施してテストを行い、望ましい結果が得られるかどうか確認します。例えば、デプロイ Canary テストまたはワンボックスデプロイを使用します。

  • 並列環境でデプロイする: 並列環境に変更を実装し、その後、新しい環境に移行します。デプロイの成功を確認するまで、以前の環境を維持します。こうすることで、以前の環境へのロールバックが可能になり、復旧時間を最小限に抑えることができます。

  • 小規模で可逆的な変更を頻繁にデプロイする: 小規模で可逆的な変更を頻繁に行うことで、変更の範囲を縮小します。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また、変更をロールバックすることもできます。

  • 統合とデプロイを完全自動化する: ワークロードのビルド、デプロイ、テストを自動化します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。

  • テストとロールバックを自動化する: デプロイした環境のテストを自動化し、望ましい結果が得られることを確認します。結果が達成されない場合に以前の正常な既知の状態に自動的にロールバックすることで、復旧時間を最小限に抑えるとともに、手動プロセスによるエラーを減らします。

OPS 7 ワークロードをサポートする準備が整っていることを確認するにはどうすればよいですか?

ワークロード、プロセス、手順、従業員の運用準備状況を評価し、ワークロードに関連する運用上のリスクを理解するようにします。

ベストプラクティス:

  • 従業員の対応力を確保する: 運用上のニーズに対応できるようにトレーニングを受けた、適切な人数の従業員が配置されていることを検証するメカニズムを導入します。効果的なサポートを継続できるように必要に応じて従業員のトレーニングを実施し、従業員の対応力を調整します。

  • 運用準備状況の継続的な確認を実現する: ワークロードの運用に関する準備状況を継続的に確認するようにしてください。確認には、チームとワークロードに関する運用準備状況、またセキュリティ上の要件を必ず含める必要があります。必要に応じて確認アクティビティをコードで実装し、イベントへの応答として自動確認をトリガーし、一貫性、実行スピードを確認して、手動プロセスによって発生するエラーを減らします。

  • ランブックを使用して手順を実行する: ランブックは、具体的な成果を達成するための文書化された手順です。ランブックに手順を文書化することにより、一貫性を保ち、汎用イベントにすみやかに対応できるようになります。必要に応じてランブックをコードとして実装し、イベントへの応答としてランブックの実行をトリガーし、一貫性、対応スピードを確認して、手動プロセスによって発生するエラーを減らします。

  • プレイブックを使用して問題を調査する: 調査プロセスをプレイブックに文書化することで、十分に理解されていない問題に対する一貫性のある迅速な対応が可能になります。プレイブックは、障害シナリオの原因となる要因を特定するために実行される事前定義されたステップです。プロセスステップの結果は、問題が特定されるか、エスカレーションされるまで、次のステップを決定するために使用されます。

  • システムや変更をデプロイするために十分な情報に基づいて決定を下す: ワークロードと、ワークロードのガバナンスとのコンプライアンスをサポートするためにチームの能力を評価します。システムを移行するか、本番環境に変更するかどうかを判断する際に、これらをデプロイの利点に対して評価します。メリットとリスクを理解し、十分な情報に基づく決定を下します。