【レポート】AWS サポートの現場からお送りする、AWS 環境運用のベストプラクティス #AWSSummit

こんにちは！オンジーどすぅ

いつも大変お世話になっているAWSサポートのセッションは絶対に聞いとかないと！ということでレポートします。

AWS Summit Online やってまっせ！(〜2020/9/30)

セッションの概要

タイトル：AWS サポートの現場からお送りする、AWS 環境運用のベストプラクティス

スピーカー：AWSJ テクニカルアカウントマネージャー 鈴木優さん

• 対象者
  • AWS上で本稼働システムを運用しているエンジニアの方
• 目的
  • 運用に関するベストプラクティスを紹介しお客様の明日からの運用をより良くするための気づきを一つでも持ち帰っていただくこと
• 話さないこと
  • 各種サービスの基本的な仕様の説明、詳細な設定方法の解説

動画と資料

前提

エンタープライズサポートでAWSサポートの実際の現場で得た運用のベストプラクティスを紹介するセッションになります。

AWSの本稼働時に必要な対応

• 稼働してからがシステムの本当の始まり

• • システムは稼働してからが価値を発揮するフェーズとなっており一般的には保守運用フェーズにおいては開発期間よりも使われるものとなる
  • 保守運用フェーズには
    • システムに障害が発生した場合の障害対応
    • システムを正常に維持するためのメンテナンスや維持活動など
• 運用フェーズにおける重要な観点

• トラブルサポート
  • AWSを運用フェーズで利用するにあたり発生するさまざまなトラブルにわたってAWSサポートを通して問題解決を支援するという活動
  • AWS基盤の問題においては場合によってはプロダクトチームとも連携しながら対応を実施する
• プロアクティブサポート
  • トラブルを起こさないために事前にどのような観点が必要なのかを支援する
    • 例)AWS から連絡される各種メンテナンス変更点についてユーザーのシステム運用への影響を最小化して採用するにはどのような対応ができるのか
    • 例)起票したサポートケースの傾向からどのようなイシューが潜んでいるのか、また次回同じようなトラブルが起こった際にはどのように対応するとより迅速に解決できるか
• アドバイザリーサポート
  • ユーザーの個別のシステムだけではなく運用としてよりよく実施いただくためのOperation Excellenceを支援するためオべレーションレビューやユーザーのコストを最適化するための提案
  • ユーザーのビジネスを AWS のサービスを利用してどのように実現していくかの支援

本セッションはプロアクティブサポートの次の3つの観点でAWS運用のベストプラクティスを紹介します。

1. 効率的なメンテナンス対応
2. 運用のナレッジマネジメント
3. 本稼働に向けたイベント管理

メンテナンス・維持対応

本項では画像右側のAWS責任範囲におけるメンテナンス維持活動を対象に話します。

• AWS Personal Health Dashboard(PHD)
  • AWS責任範囲における各種メンテナンスについて確認することができる
  • ユーザーのアカウントにおいて影響する可能性があるイベントについて一覧で表示できるダッシュボードとなっており、対象リソースが対応方法のガイダンスなどが記載されている
  • よくあるお悩みポイント
    • 「複数のAWSアカウントでメンテナンスが発⽣するため、それぞれ確認するのが⼤変」
    • 「業務インパクトを最⼩限にするために、各アカウントの対象をまとめて把握し⼀気に対応したい」
    • 「⽬検でのPHD確認によるイベント把握は漏れが怖い。機械的に集計したい」
    • 「セキュリティ系など緊急のイベント通知(AbuseEvent)に対しては、迅速に対応したい」
    • そんなときはAWS Health integrationとOrganizational View
• AWS Health Integration

• • AWSの様々なサービスとイベント通知するために統合されている
  • プログラム可能な方法でイベント情報にアクセスすることが可能
  • Amazon CloudWatch Events でイベント発生時にプッシュ通知を行いアクションを自動化するといった対応も実施することが可能
  • ユーザーの社内またはサードパーティの監視およびイベント管理システムと統合するために使用することも可能
• Organizational View
  • AWS Organizationsに紐づく全てのアカウントのイベント情報を収集可能し、必要に応じてフィルタリングして情報を検索することも可能
  • 組織全体のリソースのメンテナンスイベントを事前に把握管理することがより容易に
  • またAWS Health APIを利用した各種ツールを公開しているAWS Health toolsではこちらの Organizational View を利用してSlackなどに通知を行うツールも公開中！
  • ユーザー自身で Health API を元に実装することも可能
• AWS Health APIの活用例
  • AWS Health DoS abuse report automation

• • セキュリティイベントに関してはイベント発生時に迅速に対応する必要があることからイベント通知をもとに自動的に対応する仕組みを構築した例
  • ユーザーのEC2においてDoSインシデントが発生した際の通知とその対応を自動で行うためのワークフロー
  • AbuseEventが発生した際その内容のPHDへの通知から紐づいたCloudWatch events発生→ AWS Lambdaのfunctionを利用してタグを確認し本番環境ではないインスタンスは自動的に停止する対応を取り、Amazon SNSを利用して通知する仕組みを実装
• まとめ
  • AWS Health APIを活用することでよくあるお悩みを解決できるかもしれない！
  • ユーザーの運用システムと連携させたりメンテナンスイベントを機械的に収集したり、また発展的には緊急性の高いイベントに対しては自動的なアクションを実行させるといったことも可能

運用ナレッジマネジメント

• 日々の障害対応におけるナレッジは宝物
  • 設計・開発フェーズでは⾒えなかった課題や改善点が運⽤フェーズで発⾒
  • 社内へ横展開することで、同様の事象においては迅速な解決が可能に
  • AWSサポートとのやり取りから得た知⾒も重要な情報
• よくあるお悩みポイント
  • 「AWSサポートはアカウント単位での契約となるため、他アカウントのサポートの情報を活⽤しにくい」
  • 「過去の問合せ内容について、効率的に検索したい」
  • 「問合せデータを1年以上保持したい」
  • そんなときにAWS Support API
• AWS Support API
  • サポートケース管理及びAWS Trusted Advisorに対してのインターフェイスとして提供されている
  • サポートケースに関するサポートセンターから実施する全オペレーションをAPI を通して実施が可能
  • サポートケースのやり取り情報についても API から取得が可能

※AWS Support API のご利⽤は、AWS サポートのビジネスサポートプランまたはエンタープライズサポートプラン が必要です。

• AWS Support APIの活用例
  • AWS support tickets aggregation service

• • AWS Support APIを利用しOrganizationsに紐づく複数アカウントのサポートケース情報をまとめて取得する実装例
    • Organizationsに紐づいた各アカウントのサポートイベント情報をOrganizationsのマスターアカウントなど集約用のアカウントのAWS CloudTrailに集約
    • この情報をもとにLambdaからAWS Support APIを実行し各メンバーアカウント側のサポート情報収集
    • 最終的にAmazon DynamoDBに格納する
  • フロントとして表示するダッシュボード作成することで複数のアカウントで使用されているサポートケースの単一なダッシュボードを実測いただくことも可能
  • データの格納先としてDynamoDBではなくS3などにファイル出力しそれに対してSQLでクエリを発行するサービスであるAmazon Athenaからクエリすることで簡易的に確認することも可能
  • 運用しているチケット管理システムに情報を送るといった実装も考えられる

(参考)How to Create an AWS Cross-Account Support Case Dashboard

• まとめ
  • AWS Support APIを活用することで過去のサポートケース情報の取得や複数のアカウントのサポート技術情報を一元管理し社内横断でのナレッジ共有が可能となる

本稼働に向けたイベント管理

• ローンチイベントは最も重要なイベント
  • 充分に事前に様々なテストを行ったとしても想定外の事象は起こりうるものであり、新サービスの提供にあたって何かトラブルが発生した際にはシステムを利用するエンドユーザーの方々にも影響を与え、ビジネスへの影響も大きいものとなる
• インフラストラクチャイベントの準備
  • AWSではこういった重要なイベントに向けたガイドラインとしてInfrastructure Event Readinessというホワイトペーパーを公開している

• イベントマネージメントの全体構成

• • 計画・準備フェーズ
    • 最も重要なフェーズ
    • サービス規模やサイクルにもよりますがイベントの2ヶ月前から開始する
    • 適切な準備はイベントの成功率を上げる
  • 実行フェーズ
    • サービスのローンチやプロモーションイベントなどの当日に行う対応についてまとめられている
  • イベント後フェーズ
    • イベントの振り返りを行い今後に向けた対応について確認を行う

各フェーズで重要なタスク(画像のオレンジ文字)について説明していきます。

• アーキテクチャの確認
  • 「事前にWell-Architected Reviewなどをやっているのに何故必要か︖」
  • →「設計時と稼働前では見るべき観点が違うため」
    • 設計フェーズは机上の設計であり、稼働時は実リソースがある
    • 実リソースから各種メトリクスなども確認可能
    • 負荷テストが終わっており、その結果もインプットとして使える
    • 構築していく中で、当初設計から乖離している可能性
• アーキテクチャレビューの観点
  • AWS サービス固有の観点
    • 各サービスの利用/設定が稼働時におけるベストプラクティスに沿っているか
    • 例)開発期間が数年にわたっている場合、または過去に作ったシステムと同様にサービスを利用して過去のベストプラクティスのまま新しいシステムを構築するというパターンには新しいアップデートを用いることでより良い設定が可能になっている場合がある
    • 想定される負荷に備えた準備が⾏われているか（暖機申請、IPアドレスレンジ、各サービスの上限値）
  • システムアーキテクチャの観点
    • 全てのコンポーネントにおいて高い可用性やパフォーマンスを求めることはコストとのトレードオフになるため現実的には難しい場合がある、リスクを認識しておくことが重要
    • パフォーマンス上のボトルネックとなりうるところはどこか
    • 必要なキャパシティが⽤意されている/その⼿段を⽤意しているか
    • スロットリングが発⽣しないか負荷テストで確認しているか
    • 可⽤性の観点よりSPOF(Single Point of Failure)となる箇所はないか
    • 想定されるリスクに対して適切な対応を検討しているか
    • イベントに関連するアカウントに漏れはないか

• サービス上限の確認
  • 利⽤している各種AWSサービスの上限について改めて確認
  • AWS Trusted Advisor や AWS Service Quotasなどを上⼿く活⽤し、⾃動的に通知することも可能
  • 負荷テストの結果も踏まえて、想定するピークワークロードを定義し事前に上限の緩和を⾏っているか
    • 複数アカウントを利用している際はどのアカウントで上限緩和が必要かを注意して確認しておく
    • 上限緩和の対応には時間がかかるものもあるので予め充分に確認することが大事
  • コンテンジェンシープランも想定した代替リージョン/代替サービス/代替インスタンスタイプなどについても必要な上限緩和が⾏われているか

• モニタリングメトリクスの設定
  • イベント中に向けて、重要な各コンポーネントをインシデントが起きたときにモニタリングするための、ライブメトリクスダッシュボードを作成
  • 各種メトリクスについて、通常時のベースラインの値を理解する
  • また、各メトリクスに対してアラートの設定、及びアラート発⽣時の対応⽅法についてあらかじめ検討しておくことが重要
  • CloudWatch のカスタムダッシュボードを⽤いて、AWS のリソースから⼤半のメトリクスを収集するなど対応を実施

• 当日の話
  • 計画準備フェーズにて充分な準備を行うことが重要なポイントなので当日にやることは多くない
  • War roomの構築 – 迅速な情報共有のチャネルを構築
  • モニタリングメトリクスのモニターを実施
  • トラブル発⽣時には、AWS サポートを有効的に活⽤する
• (参考)トラブルサポート
  • 技術的なお問い合わせに関するガイドライン
  • よくある事例として緊急時に情報が不充分なサポートケースが起票され必要な情報や問題点など改めてヒアリングし逆に時間がかかってしまう
  • 緊急時においてもガイドに沿って必要なリソース情報やログなどを提供しつつ特に急ぎの状況ではサポートケースにて三つの点を留意する
    • 「いつまで」に「どういう状態」にする必要があるかを共有する
    • ビジネスインパクトを共有する
    • ユーザー側での切り分け状況、または切り分けていないならそのステータスでも問題ないので可能な限り状況を共有する

• イベント後の話
  • イベント実施後に、イベントの振り返り（レトロスペクティブ）を⾏うことは⾮常に重要
  • 発⽣したインシデントのRoot causeを分析し次回に活かす
  • イベントに向けてスケールアップしていたリソースのスケールダウンを忘れずに
  • 取得したピークワークロードにおけるメトリクスは次回の類似イベントの負荷テストの⽬安として活⽤

• (参考)アドバイザリーサポート
  • 単⼀のシステム/サービスについてではなく、Operation Excellence を⽬指すための組織としての取り組みを⽀援
  • コスト最適化・運用自動化・運用メンバーの育成など様々なトピックに対してディスカッションを元に支援
  • Well-Architected Framework の活⽤
  • エンタープライズサポートのお客様に向けては、Operations Reviewサービスの活⽤

まとめ

システムやサービスは稼働してからが価値を発揮するフェーズになっています。

そこで実施する保守運用フェーズの各業務は長い間対応していくものとなります。

本セッションの情報を参考に各タスクを実施していきましょう！

所感

AWSサポートの実際の現場で得た運用のベストプラクティス、とても貴重な情報でした。。。

運用のタスクって漠然としていたのですが本セッションで整理された気がします。

ブレークダウンされると心にも余裕ができて事前に検討・準備しておこうという気になりますよね！

そういった意味でも日頃から運用フェーズを意識したキャッチアップは重要だと感じました。

運用のことを意識すると要件定義・設計・構築・開発も良い方に変わっていきますしね！！