AWS Well-Architected Framework を深掘りしてみる①

〜運用上の優秀性 (Operational excellence) 〜
2023年10月13日- By Hiromasa Chigusa

はじめに

以前、こちらのブログで、AWS Well-Architected Frameworkの概要について触れました。

ここからは、AWS Well-Architected Frameworkで定義されている「6つの柱」について少し掘り下げて見ていきたいと思います。

AWSをこれから学ぶ方はもちろん、日々扱っているというエンジニアの方々にも、あらためて「運用上の優秀性 (Operational excellence)」の柱について考える機会となれば幸いです。

「運用上の優秀性」とは

「運用上の優秀性」の目的は以下のように定義されています。

『運用上の優秀性の目的は、新機能とバグ修正を迅速かつ確実にお客様に提供することです。運用上の優秀性に投資している組織は、新しい機能を構築し、変更を加え、障害に対処しながら、着実に顧客満足を実現しています。その過程で、運用上の優秀性は、開発者が高品質の結果を常に達成するために役立ち、継続的インテグレーションと継続的デリバリー (CI/CD) を促進します。』（参考資料[1]）

変化に強い組織と仕組み、という風にも言えるかと思います。

AWS Well-Architected Frameworkには、「6つの柱」それぞれに「設計原則」と「ベストプラクティス領域」が含まれています。

・「設計原則」には、クラウド上における適切な設計を可能にするためのガイド

・「ベストプラクティス領域」には、ベストプラクティスを実現するための施策

が各々まとめられています。

「運用上の優秀性」の「設計原則」「ベストプラクティス領域」について、順に見ていきましょう。

設計原則

「運用上の優秀性」には、5つの設計原則があります。

  1. 運用をコードとして実行する (Perform operations as code)                                               　　　　　　　　→ ワークロード全体のコード化や運用手順のスクリプト化を通じて、ヒューマンエラーの抑制と一貫性のある対応を実現する。
  1. 小規模かつ可逆的な変更を頻繁に行う (Make frequent, small, reversible changes) 　　　　　　　       → ワークロードはそのコンポーネントが変更可能なように設計し、元に戻すことができるように変更は小規模に行う。
  1. 運用手順を頻繁に改善する (Refine operations procedures frequently)                　　　　　　　               → 運用を実施する際は改善の機会を探し、ワークロードの変更時には手順も改善する。また、ゲームデー(*1)を設けて、手順が効果的でチームに熟知されていることを確認する。
  1. 障害を予想する (Anticipate failure)                                                                               　　　　　　　　　　　→ 「プレモータム(pre-mortem)」(*2)演習の推奨。潜在的な原因を特定し障害を排除または軽減する。障害を想定したシナリオでテストを行い、手順の有効性やチームの反応をテストする。
  1. 運用上のあらゆる障害から学ぶ (Learn from all operational failures)                      　　　　　　　            → 運用で遭遇したあらゆる事象や障害から教訓を得、チームに共有し、改善を繰り返す。

(*1)ゲームデー：シミュレーションや演習により、手順や体制を検証するための内部イベント。

(*2)プレモータム：起こり得る失敗を予測し、その原因を事前に検証すること

ベストプラクティス領域

「運用上の優秀性」のベストプラクティスは、次の4つの領域として分類されています。

  • 組織 (Organization)
  • 準備 (Prepare)
  • 運用 (Operate)
  • 進化 (Evolve)

これだけ見るとちょっとよくわかりませんが、それぞれ熟読していくと、フォーカスしている部分が見えてきます。一段階ブレークダウンして見てみましょう。

  • 組織 (Organization)
    • 組織の優先順位 (Organization priorities)
    • 運用モデル (Operating model) – 関係性と所有権 (Relationships and ownership)
    • 組織カルチャー (Organizational culture)
  • 準備 (Prepare)
    • テレメトリを設計する (Design telemetry)
    • 運用のための設計 (Design for operations)
    • デプロイのリスクを緩和する (Mitigate deployment risks)
    • 運用準備状況と変更管理 (Operational readiness and change management)
  • 運用 (Operate)
    • ワークロードの状態と把握 (Understanding workload health)
    • 運用状態の把握 (Understanding operational health)
    • イベントへの対応 (Responding to events)
  • 進化 (Evolve)
    • 学習・共有・改善 (Learn, share, and improve)

ベストプラクティス領域の「組織」「運用」「進化」は組織体制や文化面に、「準備」はワークロードの具体的な設計面にフォーカスしていそうです。さらにブレークダウンしてみます。

さらに下の階層では、個々の「ベストプラクティス」の定義にまで至ります。ここでの「ベストプラクティス」は合計で80個以上にものぼります。ここでは要点のみをお伝えしますので、詳しくはAWSの公式サイトをご確認ください。

  • 組織 (Organization)
    • 組織の優先順位 (Organization priorities)
      • OPS01-BP01 外部顧客のニーズを評価する、等（他6項目）。
        •  外部・内部問わず顧客のニーズを理解する
        • ガバナンスやコンプライアンスの要件を把握する
        • ビジネス上の脅威を特定し理解する
        • 競合する利益やアプローチのトレードオフを理解し意思決定を下せる
        • アクションのメリットとリスクを理解し意思決定を下せる
  • 運用モデル (Operating model) – 関係性と所有権 (Relationships and ownership)
  • 組織カルチャー (Organizational culture)
    • OPS03-BP01 エグゼクティブスポンサーシップ、等（他7項目）
      • 組織に対する期待値が明確であり評価可能である
      • 必要なスキルを訓練する機会がある
      • 実験が推奨されている
      • エスカレーションが推奨されている
      • コミュニケーションが洗練されている
      • チームのパフォーマンスを理解し必要なリソースが提供され
      • 多様な意見や視点が求められている
  • 準備 (Prepare)
    • テレメトリを設計する (Design telemetry)
      • OPS04-BP01 アプリケーションテレメトリーを実装する、等（他4項目）
        • アプリケーション、ワークロード、ユーザーアクティビティ、外部システムとの関連について、テレメトリーを実装する
        • ワークロード全体のトランザクショントレーサビリティを実装する
  • 運用のための設計 (Design for operations)
    • OPS05-BP01 バージョン管理を使用する、等（他9項目）
      • コードのバージョン管理を使用する
      • 本番リリース前に検証する
      • 構成管理システムを利用する
      • 構築・デプロイを自動化する
      • パッチと脆弱性を管理し、検証と自動化の仕組みを採り入れる
      • チーム全体でベストプラクティスを共有する
      • コードレビューやテスト駆動型デプロイなどのような仕組みを入れる
      • 目的別に複数の環境を使用する
      • 小さな変更を頻繁に行うことで、変更の範囲と影響を減らす
      • ワークロードのビルド、デプロイ、テストを自動化する
  • デプロイのリスクを緩和する (Mitigate deployment risks)
    • OPS06-BP01 変更の失敗に備える、等（他7項目）
      • 変更を失敗した場合の計画を立てる
      • 本番リリース前に検証する
      • 構築、デプロイを自動化する
      • 限定的にデプロイし検証する
      • 並列環境でデプロイし成功の確認まで維持する
      • 小さな変更を頻繁に行うことで、変更の範囲と影響を減らす
      • ワークロードのビルド、デプロイ、テストを自動化する
      • デプロイ後のテストとロールバックを自動化する
  • 運用準備状況と変更管理 (Operational readiness and change management)
    • OPS07-BP01 人材能力の確保、等（他5項目）
      • ワークロードをサポートする人材を確保し、トレーニングを提供する
      • 運用準備状況レビュー（ORR）(*3)の仕組みを整える
      • ランブックを作成・維持し、自動化する
      • プレイブックを作成・維持し、自動化する
      • ワークロードの変更は成功・失敗を想定した十分な情報に基づいて決定する
      • ワークロードが依存するソフトウェアやサービスのサポートを有効にする

(*3) Operational Readiness Review。ワークロードのローンチ前に使用されるチェックプロセスで、ベストプラクティスに則ることのほか、組織内の過去のイベントの再発防止の役割がある。

  • 運用 (Operate)
    • ワークロードの状態と把握 (Understanding workload health)
      • OPS08-BP01 主要業績評価指標 (KPI) を特定する、等（他7項目）
        • ワークロードが持つべきKPIを特定する
        • ワークロードのメトリクスを定義し、収集と分析をする
        • メトリクスのベースラインを定義し、正常時の基準を設ける
        • 「繁忙期に使用率が増加する」などの予想されるアクティビティのパターンを知る
        • ワークロードの結果にリスクがある場合に警告する仕組みを設ける
        • ワークロードに異常が検出された場合に警告する仕組みを設ける
        • KPIの達成状況と有効性を検証し、修正する仕組みを設ける
  • 運用状態の把握 (Understanding operational health)
    • OPS09-BP01 主要業績評価指標 (KPI) を特定する、等（他7項目)
      • 運用が持つべきKPIを特定する
      • 運用のメトリクスを定義し、収集と分析をする
      • メトリクスのベースラインを定義し、正常時の基準を設ける
      • 「新人のオペレーションは失敗しがちである」などの予想されるアクティビティのパターンを知る
      • オペレーション結果にリスクがある場合に警告する仕組みを設ける
      • オペレーションに異常が検出された場合に警告する仕組みを設ける
      • KPIの達成状況と有効性を検証し、修正する仕組みを設ける
  • イベントへの対応 (Responding to events)
    • OPS10-BP01 イベント、インシデント、問題管理のプロセスを使用する、等（他6項目）
      • インシデント等、介入が必要なプロセスを文書化・維持し、改善する
      • アラートに対しては全て具体的な対応策を定め、所有者を明確にする
      • 介入が必要なイベントに対して、ビジネス上の影響度から優先度を決定する
      • エスカレーション経路を定める
      • システム停止時における顧客とのコミュニケーション計画を定める
      • ダッシュボードでステータスを知らせる仕組みを設ける
      • イベントへの対応を自動化する
  • 進化 (Evolve)
    • 学習・共有・改善 (Learn, share, and improve)
      • OPS11-BP01 継続的改善のプロセスを用意する、等（他8項目）
        • 1年に1回以上ワークロードのレビューを行い、改善の機会を優先する
        • インシデントを分析し、再発回避の緩和に向けたプロセスを設ける
        • 顧客やチームのフィードバックを収集し、改善を継続的に行う
        • ナレッジ管理を行い、必要な情報へのアクセスを与える
        • 改善を推進する基準を定める
        • 関連チームやビジネスオーナー間で、収集されたデータの意味について共通理解を持つ
        • チームで運用メトリクスを定期的に確認し、共通理解を持つ
        • 運用から学んだ教訓を文書化して共有する
        • 改善のプロセスに、時間とリソースを設ける

まとめ

如何でしたでしょうか。ツールを使った自動化もさることながら、組織構造や文化といった非テクニカルな面が重視されていることがわかります。

「運用上の優秀性」を高めるには、組織として、繰り返し継続改善していく仕組みを設けて維持していくことが必要となるのです。

参考資料

[1] https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/operational-excellence.html

Rackspaceについて

Rackspace Technologyの日本国内サービスは、アイレット株式会社Global Solutions事業部より提供させていただきます。

Amazon AWSとMicrosoft Azureの導入検討のコンサルティング（勉強会）から構築、運用・保守までワンストップのクラウド支援サービスです。

お客様のご要望に柔軟に対応いたしますので、まずはお気軽にご相談ください。

お問合せ
資料請求