クラウドで回す監視と運用PDCA
注意
・この記事はメモ+ちょいちょい追加纏め となります
・元のメモはツイートにあります(基本そのまま載せてます)
・きっちりまとめられている記事を見たい方には向いておりません
(m´・ω・｀)m ｺﾞﾒﾝ…
スピーカー
テクニカルアカウントマネージャー 石川 公基さん
12時 A1-01
かつて論文も出されている方ですね。
（拝見しました）
以下、メモ
テクニカルアカウントマネージャー
テクニカルアカウントマネージャー（通称:TAM）は、
エンタープライズサポートの方に向けた
「かかりつけ」「顔の見える担当エンジニア」
のようです。
AWS サポートの特徴
https://aws.amazon.com/jp/premiumsupport/features/#TAM
下記公式リンク内の「AWSサポートの紹介」にある図が解り易かったですが、
エンタープライズのプランだと、
"テクニカルアカウントマネージャー (TAM) へ直接アクセス" というサービスが〇になっています。
AWS サポートのプラン比較
https://aws.amazon.com/jp/premiumsupport/compare-plans/
継続的なサポートニーズに関するお問い合わせの主点として機能
というのが手厚いですね。
私はまだAWSサポートを利用したことはリソースのリミット緩和や調査時の質問しかしたことがないですが
その時はとても丁寧に回答いただけました。。
内容
サーバーと通信出来なくてアラートが…
DBフェイルオーバーが…
などの事態。
インフラエンジニアのつらいところですね。
しかし、システムとしては何かあっても
動き続ける作りにクラウドではできるものもある。
そのアプローチを紹介するセッション。
参考(Design For Failure)
クラウドアーキテクティング原則 - clouddesignpatternより
http://aws.clouddesignpattern.org/index.php?title=%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E5%8E%9F%E5%89%87&oldid=3837
クラウドをなぜ使うのか？
ビジネスにおけるガバナンス
設定、モニタリング、管理、レポート
アジリティ
実験挑戦、生産性など
→これらは基本、トレードオフ？？
AWSなら片方を選択しなくても良い
・実現するためにカテゴライズされたサービス群がたくさんある(運用だけでも)
継続的に、更新、改善をすればよい
Operational Excellence
AWS Well-Architected
https://aws.amazon.com/jp/architecture/well-architected/
和訳で「運用上の優秀性」という5本柱の1つのことでしょう。
中身は、
変更の管理と自動化、イベントへの対応、標準の定義
などのトピックがあります。
システムの準備とは別に改善サイクルを用意
優先事項の定義やイベント対応、知見共有など
新しい知見を反映させていかないといけない。
システムのクラウドネイティブ化
→耐障害性やトラフィックの変化に対応する弾力性を備えたシステム
マネージドサービスなど、クラウド特有のものを取り入れる。
AWSは特に、サービスの改善や新しいサービスのリリース等
更新の頻度が並大抵のレベルじゃない（笑）
だから、少なくとも半年に1回等、定期的にSaaSや効率化を図れるサービスが出ていないか、
見直す機会を作る必要があるということでしょうか。
「システムが健全である」事はどうやって知っているか？
・インスタンスの生死確認
・リソース使用率、レスポンス数を見る
・トレンド時間を見る
クラウドでのキーポイントを考える
クラウドでの俊敏性を向上させる
→障害時の自動修復機能など
特定リソースに依存しない指標へシフトする
・ビジネスファンクションに対する指標を決めることで、共通言語となる
・将来的に、システム全体のパフォーマンス(スループットやレスポンスなど)へシフトするべき！
例：Amazon CloudWatchで標準提供しているCPU使用率から、LBがどう捌いているかなどへシフト
ビジネスと、連動した基準値を設定
cloudwatch → elasticsearch service
のように、[集積してあとから分析]
と言った形だと動いていてどう対処すれば良いかが考えられるように。
必要なものに絞った監視へ
可視化は、指標定義の時の交渉材料や、「このシステムはこんな傾向もあるよ」という取り組みへ繋げられる
- CloudWatchのdashboard
- elasticsearchのkibanaを使って可視化させる
ログをelasticsearchに貯める時、CloudWatch Logsでワンクリックで可能
アクセスログなどを送ることや、LB内の平均値を見たり、
既存のサービス群を組み合わせて行うなど活用次第。
システムデプロイの手順化してるか？
・運用手順書？
・パッケージ配布用自動化ツール？
・バージョンを容易にロールバックできるようにしてる？
・すべて自動化？
変化の繰り返しに対応させる
自動化により俊敏に対応、ヒューマンエラー低減
アプリレイヤに対しても。
実験的な操作を可能にさせる
小さい単位でデプロイ可能へ
活用できるAWSサービス
CloudFormation
Elastic Beanstalk
CodePipeline
Codedeploy
切り戻し機能も可能へ
AWS DeveloperToolsのサービスを活用
新しいもの
AWS Codestar
発表時のサービス説明 2017/04
https://aws.amazon.com/jp/blogs/news/new-aws-codestar/
はじめからすべてできる必要はなく、
部分的にみつけて広げていくのがベスト。
規模が小さくても
運用部分＋ユーザ、企画部門などと行うと取り組みやすい。
取り組む順番(例)は
①標準メトリクスを眺める
ダッシュボードなどで。
②有用そうなメトリクスを集めてみる
スループットレスポンスを示すもの、関連するリソースを比較用に。
③複数リソースに跨ったり、組み合わせてカスタムメトリクスで平均値つくったり、などでアラート設定
③まで行うことで、結果的に
そのサービスに本当に必要かつ効率化されたメトリクスが並ぶ
⇒新しい指標をつけることができる
例
運用チームだけでやる場合は、
・運用ツールやスクリプト、Toolsを管理してみる
・コード管理を自動化してみる、なども。
CloudWatch・・・初めて使った時の使いやすさ半端じゃなかった。(多分2年前?)
ダッシュボードをブラウザ(マネジメントコンソール)で自作出来て、
好きなものをカスタマイズして、適宜置き換えたりしてすぐ反映される。
ブランクありましたが、また色々作ってみようと思います。
まとめ
まずは現状を把握するところから始めましょう。
・性能の基準や目標
・チーム体制
・健全性のためのコストチェック
AWS Well-Architected Tools
運用に関するセルフチェックができる
コンプライアンス要件評価
運用メトリックレビュー
応答自動化
Trusted Adviserで、推奨のプラクティスなど定期的にチェック。
⇒ビジネスプランならTrustedAdviser全機能使える！
(再貼)AWS サポートのプラン比較
https://aws.amazon.com/jp/premiumsupport/compare-plans/
そういえば最近よくAWS Loftで
ビジネスサポートプランのお試しキャンペーンのチラシがあったのを思い出しました
※ホワイトボードのとこで2回見かけた