AWSの運用ベストプラクティス 「運用上の優秀性」についての解釈

以前行われたWell-Architected Frameworkのオンラインセミナーに関するブログで、チェックシート(Excel, 2018年11月版)が公開されています。 チェックシートにはWell-Architected Frameworkの質問とチェック項目が記載されています。 チェック項目について、どのように考えたらいいのか悩むケースが多いのでは？と感じました。 運用上の優秀性(Operational Excellence)のチェック項目について、私の解釈を考えたので共有します。

W-Aではワークロードという言葉が頻出します。 AWSリソースやプログラムなどを含むITシステムのことだと考えてください。

[質問]優先順位はどのように決定されていますか？

優先順位というとわかりづらいですが、チェック項目を見ていくとわかるかと思います。 優先順位に関する共通認識を関係者で持つことが重要です。

チェック項目

顧客のニーズをビジネス、開発、運用の各チームが理解している

ITシステムがECサイトの場合、顧客がスムーズに画面を閲覧し購入できることが重要です。 セール時期は特にアクセスが増えるでしょう。 こういったニーズを各チームで共有できていると、様々ないいことがあります。 インフラ運用を行うチームではセール時期を見据えて、スケーリングをスケジュールしたり、開発チームでは、Auto Scalingを前提にした設計ができます。

キックオフで関係者にシステムの概要を共有したり、ドキュメントを整備して新しいメンバーに共有するといった運用が必要です。 運用チームがキックオフに参加すれば、スムーズな受け入れが可能かもしれません。

社内のニーズをビジネス、開発、運用の各チームが理解している

ECサイトで業務運用するチームのニーズを抑えておけば、開発する機能の選定に役立てられます。 業務運用チームがコンテンツを反映する管理画面が必要かもしれません。 もしくは、業務運用チームがAWSのCodeシリーズやGitを扱えるのであれば、不要かもしれません。

必要なコンプライアンス要件(法令遵守・業界ガイドラインなど)を評価している

PCDISSや安全なウェブサイトの作り方、AWSが提供しているIAMベストプラクティスなどを評価しているか確認します。

クラスメソッドはinsightwatchをどなたでも無償で提供し、CISベンチマーク、AWS Security Checklist、IAM Best Practiceでのチェックが可能です。

どのようなビジネス脅威やシステム脅威があるかを把握し、運用に与える影響を評価している

ECサイトの場合ユーザーが増えたり取り扱いする商品が増えると、画面表示が遅くなる恐れがあります。 RDSのスケールアップで対応できるかもしれませんし、アプリケーションの改修が必要なケースもあります。

提供スピードやコストなど様々なトレードオフが、運用に与える影響を評価している

AWSの監視はCloudWatchだけでも可能です。 しかし、一般的な監視ツールにあるような、監視テンプレートがなかったり、ping監視、ポート監視などができません。 他のサービスと組み合わせることで要件を満たせることもありますが、DataDogやMackerelなどの製品を使った方が運用は楽になるでしょう。 コストと運用性を考えて、選択します。

コストを下げるためにOSSを選ぶには一定のリスクがあります。OSSに知見がないと不具合などがあった時に痛い目に合います。 商用製品を利用したり、サポートが提供されているOSSを利用します。

得られると利益とリスク(未解決の問題があるが、新機能をリリースを優先するなど)を判断する際に、運用に与える影響を評価している

Infrastructure as Codeのようなインフラのコード化を行う場合、一度コード化すれば、環境を複数すぐに作成できるなどの利益があります。 一方でCloudFormationやAnsibleなどを扱えるエンジニアが複数いないと、コードのメンテナンスが苦しくなってしまう恐れがあります。 また、コードと環境の差異が生まれないように作業はコードで行うといったルールが必要です。 何かの変更を行う場合は、運用にどんな影響を与えるの検討します。

[質問]ワークロードの状況が把握できるように、設計はどのように行っていますか？

システム監視やアプリケーションログについて、検討します。

チェック項目

アクションが必要な状況が把握できるように、アプリケーションの測定を実装している

ワークロードが異常を示した際に気がつけるようにします。 Webサイトの場合、HTTPで接続してステータス200が返ってくるか監視したり、応答速度を取得します。 ジョブ実行するシステムでは、キューの数を測定したり、ジョブのリターンコードを確認できるようにします。

アクションが必要な際に調査が出来るように、システム内部の状況を把握できるような情報(API Call Volume, http status codeなど)を出力している

Webサイトの場合、Apacheのログを収集してhttpステータスコードを確認できるようにします。 一定規模のサイトの場合はCloudWatch LogsやFluentdでログを集約し、まとめて確認できるようにします。 S3にログを出力する場合、Athenaでの解析手順を用意しておくといいでしょう。

ユーザアクセスパターンの分析が出来るように、ユーザアクティビティに関する測定を実装している

Webサイトでは、Googleアナリティクスのようなツールを使ってユーザアクティビティを測定します。

外部依存のリソース(外部のDB, DNS, ネットワーク接続)についても、アクションが必要な状況が把握できるように測定を実装している

外部DBを参照する場合、DBとの疎通を監視しておけば、障害の切り分けに役立てられます。

トランザクションフローが把握できるように、トランザクションのトレーサビリティを実装している

RDSのログやパフォーマンスインサイトを利用します。 アプリケーションの機能で、トレーサビリティを実装しても良いでしょう。 ユーザーから特定の操作が遅いと言ったクレームがあった場合に、原因特定に役立ちます。

[質問]プロダクトの欠陥を減らし、修復を容易にし、本番環境への移行フローを改善するためにどのような作業を行っていますか？

主にアプリケーション開発に関する内容です。 パッケージソフトを使っている場合も、検証環境を用意しバージョンアップや変更などの検証ができるようにします。

チェック項目

バージョンコントロールにより変更とリリースを管理している

自社でアプリケーション開発を行なっている場合、CICD環境の構築でバージョンやリリース管理ができるかもしれません。 パッケージソフトを使っている場合は、SSM AgentとAWS Configを組み合わせれば、インストールされたソフトとそのバージョンの履歴を残せます。

変更に関するテストと検証を実施している(手作業による作業エラーを軽減するため、自動化している)

検証環境は用意されているでしょうか？ インスタンスサイズの変更はAWS CLIでスクリプト化すれば、コンソールで行うよりもエラーを軽減できるかもしれません。

構成管理システムを使用している

CloudFormation、Ansible、Terraformなどが人気があります。

ビルドおよびデプロイ管理システムを使用している

AWSでは、Codeシリーズが該当します。

パッチ管理機能を使用している

AWSでは、Systems Managerが該当します。 OSのバージョンやミドルウェアのバージョンなどを管理します。

設計のベストプラクティスを各チーム間でも共有している

本番システムでは、ログ出力を行う、IAMキーではなくIAMロールを使うなど、幅広く適用できるベストプラクティスがあります。

コード品質を向上させるために、TDD(テスト駆動開発)、コードレビュー、コード規約などを行っている

Code Buildを利用すれば、ユニットテストが可能です。

動作確認や負荷テストのために複数の環境を(本番環境だけでなく)使用している

パッチ適用時の検証などを行う為に、検証環境を用意します。

トラブル発生に備えて、変更は「頻繁に」「小さく」「可逆」に実施している

変更の頻度が少なく、変更が大きい場合、トラブルの影響が大きくなります。 運用を塩漬けしないようにします。 普段から、セキュリティパッチを定期的に適用したり、バックアップ/リストアの訓練をしておけば、緊急の脆弱性が見つかった時にも対応できます。

ビルド、デプロイ、テストを自動化している

AWSのCodeシリーズなどを使って実装します。

[質問]デプロイのリスクをどのように軽減していますか？

主にアプリケーション開発に関する内容です。 パッケージソフトを使っている場合も、検証環境を用意しバージョンアップや変更などの検証ができるようにします。

チェック項目

デプロイ失敗時のシナリオを計画している(切り戻しなど)

作業前にAMIを取得の上、Launch Templates for Amazon EC2 instancesを使えば、EC2の再作成が楽になります。

変更内容を事前にテストし、その結果を確認している

検証環境はありますか？ セキュリティパッチの適用などを検証できる環境を作りましょう。

デプロイ管理システムを使用している

AWSでは、Code Deployが用意されています。

限定的なデプロイでのテストを実施している(カナリアテストやワンボックスデプロイなど)

カナリアテストは一部のユーザーに新機能をリリースし、反応をみながら段階的にリリースする方法です。

ロールバック出来るように、(既存環境とは異なる)並行環境にデプロイしている

BlueGrennデプロイを行えば、デプロイの失敗時の切り戻しが簡単です。

トラブル発生に備えて、デプロイは「頻繁に」「小さく」「可逆」に実施している

塩漬けしたシステムを大きく変更することはトラブルに繋がります。

CI(継続的インテグレーション)ツールなどを用いて、ビルド、デプロイ、テストを自動化している

AWSのCodeシリーズを利用します。

テストとロールバックを自動化している

AWSのCodeシリーズを利用します。

[質問]運用へのサポート準備をどのように把握していますか？

運用チームに運用を押し付ける形にならないように気をつけます。 手順書を作成するのはもちろん、ビジネス上の背景なども共有します。

チェック項目

適切なスキルを持ったメンバを配置している(必要であればトレーニングを実施)

AWSの経験が浅い場合、AWSのトレーニングに参加したり、コンサルティングパートナーにトレーニングを依頼します。

一貫性のある運用準備レビューを実施し、運用準備が整っていることを確認している(特にセキュリティ観点と運用観点)

開発チームは、顧客のニーズを過不足なく運用チームに伝えましょう。 運用手順を整備する必要があるかもしれません。

通常運用のため、運用手順書(Runbook)を使用している

利用するAWSリソースによって、必要な運用手順書は異なります。 EC2ならリタイアメントの対応手順書が必要です。

ニーズによっても必要な手順書が異なります。 ビジネスサイドからアクセス数の集計を求められる場合は、Athenaでログ解析する手順が必要かもしれません。※リンクはVPCフローログの解析例

障害時運用のため、障害対応手順書(Playbook)を使用している

リソースの再起動やソーリーページへの誘導手順、エスカレーションパスなどを手順化します。

デプロイと変更は、メリットとリスクの双方を踏まえ、情報に基づいた判断により行われている

デプロイに失敗した場合、サービス断が発生するなどの恐れがあります。 リスクを踏まえた上でリスクを軽減するための前述の施作を実行し、デプロイや変更を行います。

EC2インスタンスのインスタンスタイプ変更ではトラブルが起きることがあります。 世代が異なるタイプ変更では、ドライバーなどのアップグレードが必要だからです。 アップグレードの検証にかかるコスト、変更によるAWS利用費削減、リプレース時期などを踏まえ、変更するか考えます。 苦労してインスタンスタイプをアップデートしても、OSのサポート期限などがすぐにくるかもしれません。

[質問]ワークロードの状態をどのような方法で理解していますか？

全体像が見えないまま監視運用に入ると、目先のアラートに追われがちではないでしょうか。 KPIを定義し定期的なメトリック分析を行えば、全体を俯瞰した運用に役立つと思います。

チェック項目

ビジネスKPIによって評価している

Webサイトの場合、Webサイトの稼働時間が候補になります。

KPIの達成度を判断するためのワークロードのメトリックが定義されている

Webサイトの稼働時間は、DatadogやMackerelなどで監視できます。

トレンドを把握するために、ワークロードのメトリックの分析が定期的に実施されている

継続的にメトリックを評価しておけば、昼間はアクセスが多く、ページの表示に時間がかかっているといった傾向を確認できます。 昼前にEC2 Auto Scalingでインスタンス台数を増やすといった対応を取れます。

メトリックの基準値が定められており、ギャップ分析の基準として使用できる

レスポンスは1秒未満という基準値を設けておけば、1秒を超えた際に対策が必要という認識ができます。

ワークロードの活用パターンを予測し、想定外の活用時に適切に対処出来るように備える

TVに取り上げられることでWebサイトのアクセスが増えることがあります。 通常とは異なる利用をされる場合に対応できるように、スケーリング手順を整備します。

ワークロードにリスクがある場合、アラートを発するようにしている

DatadogやMackerelなどで監視したり、セキュリティサービスを利用します。 セキュリティ面ではGuardDutyの有効化をお勧めします。

ワークロードの異常が検出された場合、アラートを発するようにしている

前述と同様ですが、アラートには重要度をつけます。 重要度によって、エスカレーションパスを設定します。

運用のビジネスビューを作成し成果の実証を行う。またKPIやメトリックが有効であることも検証し、必要であれば修正する

運用レポートを作成し、KPIに対するメトリックの状態を確認します。 アプリケーションの応答が遅くなっていることに気付けるかもしれません。

[質問]運用の状態をどのような方法で理解していますか？

運用の働きや価値が見えづらいと言われてしまうケースがあるかと思います。 KPIやメトリックを定義すれば、関係者に理解してもらいやすいかと思います。 自チームの自信にも繋がるはずです。

チェック項目

ビジネスKPIによって評価している

社内で使うファイルサーバーの場合、ユーザーの発行にかかる時間や、作業リクエストを受けてから完了するまでの時間が候補です。

KPIの達成度を判断するための運用についてのメトリックが定義されている

社内で使うファイルサーバー場合、ユーザーの発行にかかる日数。 セキュリティアップデートが公開されてから、適用できるまでの日数などです。

トレンドを把握するために、運用についてのメトリックの分析が定期的に実施されている

特定の時期にオペレーションに時間がかかるようなケースでは、作業が属人化している可能性があります。 特定のメンバーが不在の時期にオペレーションが滞るようなケースです。

メトリックの基準値が定められており、ギャップ分析の基準として使用できる

社内で使うファイルサーバーのユーザーの発行に3日以上かかる場合は、発行フローが整備できていないのかもしれません。 すぐに発行できている場合は、運用の価値を自チームの自信になりますし、他の組織へのアピールもしやすくなります。 セキュリティアップデートの適用に時間がかかる場合は、検証環境を用意したり、手順やツールを整備しても良いでしょう。

運用の活用パターンを予測し、想定外の活用時に適切に対処出来るように備える

セキュリティアップデートを整備しておけば、重要な脆弱性が見つかった時も適切に対応できます。

運用にリスクがある場合、アラートを発するようにしている

重要な脆弱性などが見つかった場合、ビジネス、開発と連携し対応します。 

運用の異常が検出された場合、アラートを発するようにしている

システムに重大な異常が異常が検出された場合、アラートをあげます。

運用のビジネスビューを作成し成果の実証を行う。またKPIやメトリックが有効であることも検証し、必要であれば修正する

ビジネスビューというのはレポートと解釈しました。 KPIに対して目標値で対応できているかを確認します。

[質問]ワークロードおよび運用のイベントをどのように管理していますか?

アラートメールの受信とその対応で一杯一杯になっていませんか。 チェック項目を確認すれば、俯瞰した運用への第一歩になります。

チェック項目

観察されたイベント、対処が必要なインシデント、すぐに解決出来ない問題に対応するためのプロセスがある

backlogのような課題管理システムを利用し、問題を管理します。 関係者による定例会を実施し、問題を棚卸しします。

再発防止のため根本的な原因を特定・分析し対応するRCA(Root Cause Analysis, 根本原因解析)プロセスがある

問題が発生したら、事象、原因、時系列などをまとめます。 関係者でレビューし、チームで共有します。

発生するアラートに対して対応者と対応手順が定められている

代表的なアラートに対して、EC2の再起動などの対応手順を定めます。

ビジネスへの影響に基づき運用イベントを優先度付けしている(同時に複数のインシデント対応が必要な場合など)

背景を踏まえ、優先づけを行います。 インフラ運用チームに、システムの背景やニーズを共有しておく必要があります。

エスカレーションのプロセスが定義されている

問題が発生した際のエスカレーションプロセスを定義します。 特に重要なメトリクスはビジネス責任者に報告します。

サービスに影響がある際には、顧客に知らせる仕組みがある（電子メール、SMS、Push通知など）

利用者が多いサービスの場合は、サービス影響を伝える手段を用意します。 多数のお客にメールで伝えるには、手順や専用のシステムが必要です。 アプリケーションの機能で、メンテナンスを通知する機能を実装しても良いでしょう。

ダッシュボードによる状態確認が可能である(社内チーム、責任者、顧客などに対して)

サービスの状態を示すダッシュボードを作成します。 Datadog、Mackerel、CloudWatchではダッシュボードを作成できます。

イベントに対する応答が自動化されている

障害を検知したら、自動復旧させるスクリプトを自動実行します。 Auto Scalingを使っても良いでしょう。

[質問]運用をどのように進化させていますか？

システム運用をしていると課題が顕在化したり、ニーズや技術が変化します。 AWSでは日々新しい技術がローンチされるので、運用に取り入れていきます。

チェック項目

継続的な運用改善のプロセスがある

定例会を行い、運用における課題を棚卸しします。

フィードバック・ループがある（フィードバックをあげたり、吟味する仕組みがある）

新しいツールを導入した場合、実運用してみないとわからないことがあります。 通知が多すぎて困るとか、ツールの手順や説明が不足しているために活用されないといったケースです。 導入しっぱなしにするのではなく、フィードバックできる場を作ります。

改善のための推進役を決定している

日々の運用業務に追われがちになってしまいます。 推進役を決定し、行います。

組織横断チームとビジネスオーナーによるレビュー実施し、分析を実施している

運用の価値はビジネスオーナーに見えづらいことがあります。 前述のKPIを作成しビューにすることで、システムや運用への投資が判断しやすいです。

様々なチームと定期的にメトリックを用いた運用レビューを行い、学びを共有している

メトリックに理想とのギャップがある場合、チームを横断した改善が必要かもしれません。 特定のオペレーションが増えている場合は、開発チームに自動化を依頼するといった形です。

運用上で得た教訓をドキュメント化し、共有する仕組みがある

ドキュメント化することで情報は正しく伝わります。 BacklogのWikiやConfluenceなどを利用し、共有します。

継続的な改善のため、時間とリソースを設定している

AWSでは新しいサービスが日々リリースされています。 新しいサービスを検討する時間を設定します。

終わりに

Well-Architected Frameworkの運用性について、私の解釈を紹介しました。 W-Aはシステム構築時に行い、運用が開始した後も継続的に実施すると良いとされてています。 システム構築時に行えば、ステークホルダーで共通認識を持った上で、必要なアクションを洗い出せます。 運用が開始した後も、技術的な内容の振り返りや運用フローなどについて不足していないか確認できます。

W-Aの質問に答えられなかったり、チェック項目を満たせなくてもがっかりしないでください。 ITシステムや環境によって、方針は変わってきます。利用者が少なかったり、優先度が低いシステムには人的コストをかけない形も取れます。 W-Aはポジティブに課題を発見するためのツールです。 うまく使って、改善に繋げていきましょう。