Well-Architected Frameworkの柱「運用の優位性」を読み解いてみた

2019.05.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ご機嫌いかがでしょうか、豊崎です。

最近Well-Architectedにご縁があり、いくつかの記事を書いています。今回もWell-Architectedについてご紹介をしたいと思います。

Well-Architectedとは何か?どういうシステムに使ってもらいたいか?については以下をご覧いただければと思います。

無料のAWS Well-Architected Toolでクラウド最適化への一歩を踏み出そう

そんなWell-Architected Framework には5つの観点があります。

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

5 つの柱などと表現されたりします。

それぞれの柱に対話形式の質問が用意されています。

ここでは実際にどのような質問があるのか、またそれに対してどのような観点を持ってアプローチを行うことが望ましいかを確認していきたいと思います。

そのために各柱の設計原則、定義、ベストプラクティス、キーとなるAWSサービスについて確認していきたいと思います。内容がたっぷりあるので、柱ごとに確認をしていきます。

まずは運用の優秀性から確認していきたいと思います。

運用の優秀性

運用の優秀性の柱について(Operational Excellence)

運用の優秀性の柱にはビジネスの価値を提供するための監視の機能と、継続的なサポートプロセスの改善の機能が含まれています。

設計原則(Design Principles)

オペレーションをコードで実行する

クラウドにおいては、アプリケーションに使用しているのと同じ技術を環境全体に適用することができます。システム全体(アプリケーション、インフラストラクチャ)をコードとして定義して、コードで更新を行うことができます。オペレーションの手順をコード化して実装することでイベントをトリガーにオペレーションを実行することができます。

ドキュメントに注釈をつける

オンプレミス環境ではドキュメントは手作業で作成されて、人が使用します。そしてシステムの変更に応じてドキュメントを整備するのは大変ですが、クラウドではビルドごとにドキュメントへの注釈を自動的に行うことができます。注釈付きのドキュメントは人やシステムによって利用されます。そして注釈はオペレーションのコードへの入力として使用されます。

小さく、頻度高く、可逆的な変更を行う

コンポーネントを定期的に更新できるようにシステムを設計します。失敗した場合に元に戻すことができるように少しずつ変更を行います。また、可能であればロールバックについてはユーザに影響を与えないことが望ましいです。

作業手順を頻繁に変更する

運用手順を行う場合には手順の改善を行えるチャンスを探します。システムを進化させながら手順を適切に進化させます。ゲームデイ(意図的な障害発生日)を設定して全ての手順について効果的な手順であることを検証しましょう。

失敗を予測する

潜在的な失敗の原因を特定し、それらを取り除いたり、軽減したりできるようになるためには障害シナリオをテストします。テストによって、それぞれの障害について影響を理解できているかを検証します。また、対応手順をテストしてそれらが効果的であることと、チームが手順を正しく実行できるかを確認します。定期的なゲームデイ(意図的な障害発生日)を設定して障害に対するチームの対応をテストしましょう。

全ての運用上の障害から学ぶ

全ての運用上のイベントや障害から改善を行いましょう。チーム間や組織全体で学んだことを共有しましょう。

定義(Definition)

運用の優位性には以下の3つのベストプラクティス分野があります。これらは以下にあるBest Practicesの項目にある質問およびKey AWS Services とマッピングされた形で確認されます。

  • 準備
  • オペレーション
  • 進化

Best Practices

  • 準備
    • OPS1:どのように優先順位を定めていますか?
    • OPS2:どのようにシステムの状態を判断できるように設計していますか?
    • OPS3:どのようにバグを減らしつつ修正を容易にし、本番環境のフローを改善しますか?
    • OPS4:デプロイのリスクをどのように軽減しますか?
    • OPS5:システムに対するサポート(運用業務)が準備できていることをどのように判断しますか?
  • オペレーション
    • OPS6:どのようにシステムの健全性を判断しますか?
    • OPS7:どのようにオペレーションの健全性を判断しますか?
    • OPS8:どのようにシステムとオペレーションのイベントを管理しますか?
  • 進化
    • OPS9:どのように運用を進化させますか?

Key AWS Services

  • 準備
    • AWS Config
    • AWS Config Rules
      • システムに関する標準ルールを作成し準拠されているかの確認が可能に
  • オペレーション
    • Amazon CloudWatch
      • システムの健全性を監視
  • 進化
    • Amazon Elasticsearch Service
      • ログデータの分析

まとめ

まとめる(まとめにしては量が多いですが)と、運用の優位性では、実際のオペレーションに対して準備を十分に行い、常に進化させましょうと書いてありました。

準備について

  • 監視を行いシステムの状況を把握する
  • また手順をコード化やドキュメント化する
  • 手順のテストを行う
  • オペレーションが失敗した時に元の状態に戻せるようにする
  • ログの収集を行なっておく

実際のオペレーションについて

  • システムが期待される成果を定義する
  • オペレーションの作業量と運用について定量化し、運用が成功しているか判断を行えるようにする
  • 運用の成功の観点として以下の視点を持つ
    • システムの健全性
    • オペレーションの健全性
      • デプロイやインシデント対応
  • 運用イベントの管理を行う
    • 予定された運用イベント
    • 予定外の運用イベント
  • エスカレーションフローの整備
  • 監視に対する閾値およびアラート通知の設定
  • 根本原因解決フローの整備
  • ログの収集および可視化
  • 日常的な運用の自動化

進化について

  • 手順については小さく頻繁に改善できるチャンスを増やす
  • 障害からの教訓を共有し、改善を行ことが推奨される環境を作る

さいごに

元々のボリュームが多いので、結構まとめたつもりでもそこそこの分量になってしまいました。サマリーではありますが、重要な点をまとめられたと思っています。

もしこの記事が誰かのお役に立てば幸いです。

参考

https://wa.aws.amazon.com/wat.pillar.operationalexcellence.en.html