AWSの運用ベストプラクティス 「運用上の優秀性(Operational Excellence)」についてがっつり説明しているスライドがあったのでレポートします

インサイトウォッチ

AWS が公開している「アーキテクチャに関するベストプラクティス」、Well-Architected (W-A) フレームワークには、運用（オペレーション）に関する記述も当然あります。

「運用上の優秀性（Operational Excellence）」と銘打たれているそれば、フレームワークを支える5つの柱のうちのひとつであり、「ビジネス価値を提供するためのシステムの実行とモニタリング、および継続的にプロセスと手順を改善することに焦点を当て」たものと説明されています。AWS にて動作している組織の運用担当者であれば、いちどは目を通しておきたいものです。

・・・なのですが、

少々残念なことに、この「運用上の優秀性についてのホワイトペーパー」は、'18/07時点で英語版しかありません。A4 25ページにわたってぎっしり書かれているので、訳して紹介するにしても分量があります。

なにか代替となる資料がないか。。と探していたところ、下記のスライドを見つけました。スライドであれば紹介もしやすいと考えたのでお届けします。

かなり超訳しているところがあるので、もとのスライドと見比べながら見て頂けますと幸いです。

スライド

  • Jonathan LaCour
    • CTO of Reliam
    • テクノロジスト
    • プログラマ
    • クラウドストラテジスト
    • バーボン好き
  • Reliam社の紹介
  • Q : あなたの会社はいまAWSを使っていますか？

Agenda

  • W-Aの紹介
  • Operational Excellenceのデザイン原則
  • Operational Excellenceの領域
    • Preparation
    • Operation
    • Evolution
  • Q&A

The Well-Architected Framework

  • W-Aの5つの柱
  • W-Aの価値
    • 素早い構築とデプロイ
    • 低い、または緩和されたリスク
    • 情報に基づく決定
    • AWSベストプラクティスからの学び
  • Reliam's Insights from W-A Reviews
  • ReliamはW-A Reviewパッケージを加速する
    • Review - Free

「オペレーショナルエクセレンス」

  • デザイン原則
    • コード化されたオペレーション実行
    • 注釈の付いたドキュメント
    • 繰り返される、小さな、可逆的な変更
    • オペレーション手順を繰り返しリファインする
    • 障害を予測する
    • 全ての「運用上の失敗」から学ぶ

コード化されたオペレーション実行

  • "Perform operations as code"
  • 「ソフトウェアエンジニアの経験」と「コード化されたオペレーション」
    • ソフトウェアエンジニアの経験
      • 自動化されたテスト
      • CI/CDパイプライン
      • バージョンコントロール
      • コードレビューとコーディング標準
    • コード化されたオペレーション
      • 全て はソフトウェアである
      • ソフトウェアの知見をオペレーションとインフラへ
      • リスク回避、確実な一貫性
  • Q : あなたの組織は Infrastructure as Code に適合していますか？

注釈の付いたドキュメント

  • "Annotated documentation"
  • 「オンプレミス環境」から「クラウド環境」へ
    • オンプレミス環境
      • 人の手によるドキュメント作成
      • エラーを起こしがち
      • ドキュメントと実装の乖離
      • 運用の迅速性に悩む
    • クラウド環境
      • 自動化されたドキュメント生成
      • 人間 と システム の両方に使いやすい
      • ドキュメントは実装を反映している
      • 運用の迅速性を拡大する

繰り返される、小さな、可逆的な変更

  • "Frequent, small, reversible changes"
  • 「従来型のアプローチ」から「継続的アプローチ」へ
    • 従来型のアプローチ
      • 大きな、リスクの高い変更の束を抱えたソフトウェアリリース
      • アジャイル経験者は多くの「スプリント」をひとつのリリースに詰め込む
      • システムは単一的（モノリシック）
    • 継続的アプローチ
      • 変更することは普通のことになる
      • 小さく特化されたコンポーネントの集合体であるシステム
      • 全ての変更は素早く切り戻すことが可能にデザインされている
  • Q : 一般的なリリースの頻度は？

オペレーション手順を繰り返しリファインする

  • 「ソフトウェアエンジニアリングのやり方」と「運用のやり方」
    • ソフトウェアエンジニアリングのやり方
      • 規則正しく実施される「振り返り」ミーティング
      • 拡張は連続的に組み込まれていく
    • 運用のやり方
      • 規則正しく実施される「Game Day」とその振り返り
      • 拡張は連続的に組み込まれていく
  • Q : あなたの組織は継続的に「Game Day」を設けていますか？

※ Game Day = 実際に障害を発生させてその対策を行う、一種の訓練。システムの可用性機構が正常に動作すること（なのでサービスに影響は及ばない）の確認や、そういった事象が発生した時のオペレーションに担当者が習熟することが目的。

障害を予測する

  • 「よくあるオペレーションチーム」から「優秀性を持ったオペレーションチーム」へ
    • よくあるオペレーションチーム
      • 受動的な障害へのアプローチ
      • 全てが終わった後の「死体解剖(Post-mortem)」訓練
      • 問題はいつも 本番環境から発見される
    • 優秀性を持ったオペレーションチーム
      • 能動的な障害へのアプローチ
      • 「死体になる前の(Pre-mortem)」訓練
      • Game Dayのシナリオを試験紙、正常確認し、測定する
      • 問題はいつも 予見される
  • Q : 「死体になる前の」打合せを定期的に行っていますか？

全ての「運用上の失敗」から学ぶ

  • 進化(Evolution)は共有(Sharing)を要求する
    • 共有による変化の推進
    • 製品もマーケティングも財務も発展に巻き込む
    • 継続的な進化という文化の確立

オペレーショナルエクセレンスの注力する領域(Area)

  • Preparation - 準備
  • Operation - 操作(オペレーション)
  • Evolution - 進化

準備

オペレーション上の優先順位
  • 成功しているオペレーションチームは精鋭である
    • 彼らのワークロードのエキスパート
    • ビジネス目標を把握している
    • 自分の役割を明確に認識
    • 規制およびコンプライアンス上の制約をしっかりと把握する
  • コンテキストのない専門性の優先順位付けは不可能
  • Q : あなたのオペレーションチームは「精鋭だ」と感じますか？
オペレーションのためのデザイン
  • あえて、「開発」「更新」そして「運用」をデザイン側から熟考する
    • コード化された「全て」
    • スケジュールされたCI/CDパイプライン
    • 標準的なツールとテンプレートの共有ライブラリ
    • 偏執的に観測する - データだ、データをもっとよこせ！
  • インシデント発生時に素早く動くための、あなた自身の能力
オペレーションの準備はできていますか？
  • 技術は重要です、しかしそれは手順と手続きでしかありません
    • 正確なドキュメンテーション
      • チェックリスト、操作指示書(RUnbook)、定石集(Playbook)
    • よく訓練された「正しい」チーム
      • 近道はない！
    • 準備状態をコントロールする統治状態
  • 手順と手続きを AWS でコード化する
    • リソースタグ、イベントトリガ、SSM Run Command、AWS Lambda、CloudWatch Events 等
  • Q : あなたのオペレーションチームは文書化された手順を持っていますか？

オペレーション

オペレーション上のシステムヘルスについて
  • 「運用上の優秀性」は、即時に利用でき、正確な、ビジネス要件上の鍵となるメトリクスの分析を要求する
    • 性能、コスト、可用性、遅延　等
    • データの収集・集積
    • ダッシュボードや通知の作り込み
  • AWSのこれらのツールを使う：
    • CloudWatch、Amazon Elasticsearch Service / Kibana　その他
事象発生への対応
  • キーメトリクス、通知、そしてダッシュボード、これらで「武装」したあなたのチームは自信を持ってそれらの事象に対処できる
    • 優先順位を付ける際に、ビジネスインパクトを考慮する
    • スクリプトは、データによっててこ入れされた「コード化されたオペレーション」を通して反応する
    • 問題ないと判断されているバージョンへの自動ロールバック機能を作り込む
    • Auto-Scalingと共にあれ (Embrace AWS auto-scaling)
  • インシデントへの対処が全て終わった後、根本原因を分析するための「死体解剖」が行われる

進化

経験から学ぶ
  • オペレーションチームの成功に関する最も優れた指標は何か？　学習への情熱だ。
    • 全てのインシデントはチャンス(Opportunity)である
    • オペレーションチームに、分析し、実験し、そして拡張することを奨励する
    • AWSはそれらを可能にする大規模なプラットフォームを提供している
  • ビジネスにおいて、あらゆる点で違う視点を持つことは、成長への新しい機会であると知っておくべきだ
  • Q : あなたの組織は運用上のイベントをちゃんと見ていますか？
学びを共有する
  • 多くの会社は多くの製品とオペレーションチームを持っている。成長文化を進めるために、広く学習成果をシェアしよう
    • ベストプラクティスを共有するために、AWSプラットフォームを活用する
      • CloudFormationテンプレート、Chefクックブック、Lambda function
    • AWS IAMを使用し、権限とアクセスコントロールを行う
  • 進化は、局所的な動きではない

まとめ

  • AWS W-A は、ベストプラクティスの強力な資料集である
  • W-A プログラムのパートナー（Reliamのような！）はあなたのビジネスの加速をお手伝いする
  • Q&A

最後に

Well-Architected フレームワークは、クラウドアーキテクトがアプリケーション向けに実装可能な、最も安全かつ高パフォーマンス、障害耐性を備え、効率的なインフラストラクチャを構築するのをサポートする目的で開発されました。

AWS Well-Architected のLPにそう謳われているように、AWS、というよりクラウドインフラは、もちろんオンプレミスの延長として考えることもできますが、「クラウドインフラ」の特性を生かすことで、より良く (Well) 利用することが可能です。設計も開発もそうですし、セキュリティも、もちろん運用もそうです。せっかく AWS がベストプラクティスを公開しているのですから、皆さんも是非ご活用ください。

新メンバーズ