ども、マーケティングチームのいきをです。夏休みの宿題であったクラウドプラクティショナー取得を無事に終わらせることができました。

今回は、AWS Summit Onlineのセッション「AWS-32：AWS サポートの現場からお送りする、AWS 環境運用のベストプラクティス」についてレポートします。
本セッションでは、エンタープライズサポートのお客様を支援するテクニカルアカウントマネージャー（TAM）の立場から得た知見としてのAWS運用のベストプラクティスを紹介しています。

セッション概要

タイトル

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

スピーカー

アマゾン ウェブ サービス ジャパン株式会社
技術支援本部 テクニカルアカウントマネージャー 鈴木 優さん

概要

本セッションでは、AWS を運用する上で必要となる、トラブルサポートといった「リアクティブな対応」、トラブルを起こさない / 大きくしない運用を行う「プロアクティブな対応」、そして長期的に効率的な運用を検討する「アドバイザリーサポート」の 3 つの観点を定義し、特に「プロアクティブな対応」にフォーカスをあてご説明します。AWS Health API を活用したメンテナンスイベントの対応方法、Support API を利用したナレッジマネジメント、お客様のローンチをサポートするイベント管理の手法について、AWS サポートの現場の経験を交えてご紹介します。
出典：AWS-32：AWS サポートの現場からお送りする、AWS 環境運用のベストプラクティス

レポート

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

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

TAMとしてサポートするときの重要な3つの観点

お客様がどのような支援が必要か

• 大分類：プロアクティブ、リアクティブ
• タイムライン：長期、中期、短期
• 観点：アドバイザリーサポート、プロアクティブサポート、トラブルサポート

プロアクティブサポート

トラブルを起こさないために日々どういった対応が必要か今回はプロアクティブサポートの以下の内容について説明

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

メンテナンス・維持対応

責任共有モデルに基づき、お客様の責任範囲とAWSの責任範囲それぞれでメンテナンス・維持をする必要がある
AWSの責任範囲のメンテナンス対応について紹介

AWS Personal Health Dashboard(PHD)

PHDのダッシュボードにお客様環境に影響のあるイベントがある場合にアラートと修復ガイダンスを提供

よくある悩み

• 複数のAWSアカウントでメンテナンスがあるのでそれぞれを確認するのが大変
• 業務インパクトを最小限にするために各アカウントの対象をまとめて把握して一気にしたい
• 大量のPHDからの通知を目視ではなく機械的に集計したい
• 緊急性の高いセキュリティのPersonal Health Dashboardについては即対応したい

↓
AWS Health APIを利用することで解決する
※ビジネス・エンタープライズサポートで利用可能
実行例はAWS Health Toolsで公開されているので利用できる

AWS Health Integration

• AWS Health APIを利用することでプログラム可能な方法でイベント情報にアクセスできる
• CloudWatch Eventで通知を管理することもできる
• サードパーティーのツールと統合して利用できる

Organization Veiwの活用

• Organizationsに紐づく全てのアカウントへのイベント情報を取得できる
• フィルタリングで検索することも可能
• 組織全体のメンテナンスイベントを把握できる

AWS Health DoS abuse report automation

セキュリティイベントについては迅速に把握する必要があるためイベント通知を設定

例：DoSインシデントが発生した場合のワークフロー

1. Abuse eventが発生した場合にPHDに紐付いた通知をCloudWatch eventsを発生される
2. Lambda functionでタグを確認し、本番環境ではないインスタンスを自動的に停止させる
3. SNSでメール通知がされるように設定

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

運用上のナレッジを社内で共有することで迅速に解決できるようにする
本番環境でのサポートはAWSサポートを利用した知見も重要になる

よくある悩み

• AWSサポートはアカウントごとにサポート情報が紐付いているので、他のアカウントのサポート情報を活用しにくい
• 問い合わせ内容について効率的に検索したい
• サポート内容のデータは1年で消えてしまうので保持したい

↓
AWS Support API で解決
※ビジネス・エンタープライズサポートで利用可能
参考：AWS サポート ケースのプログラミング、Using Trusted Advisor as a web service

AWS Support API

• サポートケースの管理、Trusted AdvisorのUIに関する操作ができる
• サポートケースの全やり取りをAPIから取得できる

AWS Support tickets aggregation service

例：Organizationsに紐づくサポートケースの情報を集約する

1. Organizationsに紐づくアカウントをCloudTrailに集約
2. LambdaからSupport APIを実行しメンバーアカウントの情報を収集
3. DynamoDBに格納

独自のダッシュボード作成、DynamoDB以外のストレージサービスの利用、サードパーティーのサポートシステムへの取り組みなども実装次第で可能

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

ローンチはテストを行っていてもトラブルが発生することがある
AWSではInfrastructure Event Readiness というホワイトペーパー（英語）を提供

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

• 計画・準備：もっとも重要
• 実行（ローンチ）：当日の対応
• イベント後：振返りを行い、今後の対応を決める

下図のオレンジ文字の部分は特に重要

アーキテクチャの確認

事前にWell-Architectedのレビューを行っているのに事前に確認がさらに必要な理由

• 設計と稼働ではみるべきポイントが違う
  実リソース、メトリクスなどの確認が必要
• 当初設計から乖離がある場合もあるので、その場合の潜在的なリスクを考える

アーキテクチャレビューのポイント

• AWSサービス固有の観点
  各サービスが稼働時に最新のベストプラクティスに沿っているか
  開発期間が数年に渡っている場合や過去に作ったシステムの場合はベストプラクティスが古くなっている可能性がある
  最新のものを適用する必要がある

• システムアーキテクチャの観点
  ボトルネック、単一障害点、条件緩和されているかなど
  リスクを認識することが大切
  問題が発生する可能性のある箇所、その対応について事前に認識しておく

サービス上限の確認

• 負荷テストの結果を踏まえ想定するピークにあわせて上限の緩和をしているか
  複数アカウントを利用している場合、開発・本番で分かれているようなケースだと本番での上限緩和をしておかないといけない
  上限緩和は時間がかかる場合もあるので事前にしておく
  Trusted Advisor、Service Quitasなどを活用して自動通知をだすこともできる

モニタリングメトリクスの設定

• ローンチ中にモニタリングをするためのライブメトリクスダッシュボードの作成を推奨
• 通常時のベースラインを理解し、アラートを設定
• アラート発生時にどう対応するかを決めておく（自動スケール、手動で対応など）
• CloudWatchのカスタムダッシュボードを利用して、クロスアカウント・リージョンに対応したダッシュボードを作成することができる

実行フェーズ

• 準備を十分に行うことが大切
• 連絡手段をオンラインで用意しておく
• メトリクスを設定してモニタリングする
• 万が一の場合にAWSサポートを活用する

AWSサポートの活用
技術的なサポートのガイドラインに沿って依頼をあげる
最初に情報が不足していると確認対応に時間がかかることも

• いつまで、どういう状態にする必要があるのか
• ビジネスインパクト
• 切り分け状況(調べる内容が重複しないように！)

イベント後の振返り

• スケールアップしていたリソースのスケールダウンがされているか
• ローンチ時のメトリクスデータを類似イベントで活用する

アドバイザリーサポートについて

• エンタープライズサポートを利用しているお客様にはOperation Excellenceを目指すための取り組みを支援
• コスト最適化、運用メンバーの育成など

まとめ・感想

AWSの運用についてサポートされているTAMの方からの実践的なセッションでとてもためになりました。私自身はエンジニアではないのですが、AWS初心者でもわかり易い内容と使えるサービス＆参考サイトを豊富に紹介いただいているためすぐに実践できる内容となっていますので、運用でお悩みの方のヒントになるセッションです。