話題の記事

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

2018.06.20

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

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

・・・なのですが、

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

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

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

スライド

  • Jonathan LaCour
  • CTO of Reliam
  • テクノロジスト
  • プログラマ
  • クラウドストラテジスト
  • バーボン好き
  • Reliam社の紹介
  • Managed Cloud Services - AWS - Microsoft Azure | Reliam
  • "Reliam is an AWS certified consulting and managed services provider based in Southern California."
  • AWS コンサルティングパートナー
  • Q : あなたの会社はいまAWSを使っていますか?

Agenda

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

The Well-Architected Framework

  • W-Aの5つの柱
  • Operational Excellence (運用上の優秀性)
  • オペレーショナル・エクセレンス - Wikipedia
  • Security (セキュリティ)
  • Reliability (信頼性)
  • Perfoemance Efficiency (パフォーマンス効率)
  • Cost Optimization (コストの最適化)
  • W-Aの価値
  • 素早い構築とデプロイ
  • 低い、または緩和されたリスク
  • 情報に基づく決定
  • AWSベストプラクティスからの学び
  • Reliam's Insights from W-A Reviews
  • Promotion - AWS Well-Architected Review - Archive | Reliam
  • Reliamの提供するW-A Reviewパッケージの実績
  • クリティカルな事象の92%がセキュリティ
  • 69%が可用性および運用(オペレーション)
  • 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 でコード化する
  • リソースタグ、イベントトリガ、AWS Systems Manager 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 がベストプラクティスを公開しているのですから、皆さんも是非ご活用ください。