非エンジニアがAWS Summit Tokyo 2017へ参加してみた セッション参加編~Part3-1~

こんにちは。

今回も前回に引き続きセッション内容について紹介していきたいと思います。

今回もセッションは内容がボリューミーなので2部作でお送りしたいと思います。

前回同様、自分のメモを参考としたので、細かな内容やニュアンスが異なる部分もあるかもしれませんが、ご了承下さい。

セッション紹介

セッション名
「AWSサポートと各種運用支援ツールを利用した、システム運用・管理コストの最適化」

AWSサポートラインナップ

  •  Basic
    • フォーラム
    • 課金Q&A
  • Developer(開発環境)
    • フォーラム
    • 課金Q&A
    • 技術Q&A
      • 営業時間対応
      • webフォーム
  • Business(プロダクション環境)
    • フォーラム
    • 課金Q&A
    • 技術Q&A
      • webフォーム
      • 電話
      • チャット
      • 24/365対応
    • Trusted Advisor
  • Enterprise(プロダクション環境)
    • フォーラム
    • 課金Q&A(コンンシュルジュ対応)
    • 技術Q&A(認定エンジニア対応)
      • webフォーム
      • 電話
      • チャット
      • 24/365対応
    • Trusted Advisor
    • 最優先対応
    • TAM

・24/365(ビジネスプラン以上)の日本語サポート
・AWSサービスのフルランナップをサポート
・長期のコミットメントは不要
・お問い合わせ回数は無制限

セッション3つのポイント

・迅速な対応によるシステムの安定運用
・ベストプラクティスを活用したシステム品質向上
・コスト可視化、AWS利用の最適化

 

迅速な対応によるシステムの安定運用

システム安定運用の為の2つの視点

・メンテナンス影響の最小化
・障害時の迅速な対応

Personal Health Dasyubordでメンテナンスを知る

Personal Health Dasyubordとは…
AWSのサービス稼動状況を確認出来るダッシュボード。
2016年のre:Inventで個人使用向けとして発表された。
自分が使っているサービスの可用性、メンテナンス状況等を一覧で確認可能。
CloudWatch Eventsと組み合わせることのより、イベントをトリガーとして自動的に何らかの処理を行うことも可能。

 

AWS Health APIでプログラムからアクセスする

Personal Health Dashboardに表示される通知を機械的に取得するためのAPI。

AWS Health APIの活用-AWS Health Tools リポジトリ

・AWS Health(personal Health Dashboard)を活用して通知対応など自動化するためにコミュニティベースのツールレポジトリ。

  • ・利用可能なサンプル(2017/5)
    • SMS Notifier
    • SNS Topic Publisher
    • Slack Notifilre
    • Instance Store Degraded Drive
    • Disable AWS CodePipeline Stage
    • Transtion

 

例:slack Notifier
AWS Healthが生成するCloudWatch Eventを利用してLambdaを実行し、SlackのWebHookに情報をパブリッシュ。
サンプルのLambda FunctionやCloudFormation Templateを提供。
メンテナンスイベントの取りこぼし防止に役立つ。

お客様が障害を検知した時の問題解決フロー
→障害を時のフロー

AWSのステータスService Health Dashboard

  • 提供機能
    • サービス(Region)単位でステータス表示
    • RSSを利用して更新をチェックすることも可能
    • 過去の稼動情報も提供
  • 注意点
    • 必ずしも更新はリアルタイムではない
    • 発生した障害の影響範囲によって必ずしもステータスが更新されない

 

サポートお問い合わせのベストプラクティス

・一つのお問い合わせで関連性のない複数の質問をしない。
・問い合わせ対象リソースの所有者が起票していることを確認する。
・適切な緊急度を設定いただく。
・お問い合わせの際に可能な限り以下の内容を添付する。

・事象の発生時間(タイムゾーン):
・事象が発生したリソースの詳細(リージョン/リソースID・名前):
・発生した事象の詳細:
→SDKやCLIのエラーであればそのエラー出力
可能であれば、AWS CLIの場合は”–debug”オプションの指定。
ネットワーク疎通の問題であれば通知元と通信先のリソース情報

 

プログラムからサポートへアクセス(AWS Support API)

・AWS Support APIはサポートのお問い合わせに関する操作やAWSサポートが提供するツール(AWS Trusted Advisor)に対してAPIアクセスを提供
・AWS CLIや各種SDKから利用可能
・IAMによるアクセス制御もサポート

 AWS Trusted Advisorとは…
”コスト最適化””セキュリィ”パフォーマンス”耐障害性”の4つの観点から利用者のAWS環境をAWSが自動で精査。推奨情報をお知らせしてくれる機能のこと。
推奨情報はベストプラクティスに基づくもの。

AWS Support APIの活用例
→APIでもサポート可能

・サポート問い合わせの自動化や問題管理ツールとの連携
・サポート問い合わせのエクスポート
→サポートの内容をエクスポートして、社内のナレッジをためる
・Trusted Advisorとの自動連携(後述)

AWSサポートはこんなことも確認できる

・ドキュメントを見ながらいろいろためしてみたけど、詳しい仕様がどうなっているのか確認したい。

・このサービスを使って実現したいことがあるのだけど、どう使うのがベストプラクティス?


ここで前半部分終了です。

前半部分だけでも思った以上にボリューミーになってしまいました。

後半の部はこちらをご覧下さい。

非エンジニアがAWS Summit Tokyo 2017へ参加してみた セッション参加編~Part3-2~

最後に技術的な事で悩んだら、ぜひサバカンblogへ! 新しい発見があると思います

最後までお読みいただきましてありがとうございました。
それでは後半スタート!

投稿者プロフィール

akiyama
2014年7月から在職。
エンジニアの近くで一緒に仕事をしております。
独自の目線で情報をどんどん配信していきたいと思います!!!!

コメントを残す

メールアドレスが公開されることはありません。

Time limit is exhausted. Please reload CAPTCHA.

ABOUTこの記事をかいた人

2014年7月から在職。 エンジニアの近くで一緒に仕事をしております。 独自の目線で情報をどんどん配信していきたいと思います!!!!