AKIBA.AWS #13 ガチ編〜監視(モニタリング)のメモ
AKIBA.AWS #13 ガチ編〜監視(モニタリング) - https://classmethod.connpass.com/event/130740/
AWSと監視SaaSの動向から探る監視(モニタリング)の「現在」
資料:https://dev.classmethod.jp/cloud/aws/201905-akiba-aws-13-monitoring-s01/
ペットと家畜モデル
- ペットは丁寧に色々なメトリクスを収集
- 家畜は10ノードの全体のパフォーマンスに注目し、ノードごとの細かなメトリクスはあまり気にしない
Design for failuer: 1つ2つサーバが落ちてもサービス継続可能な設計
昔はマシン再起動に時間がかかったので、プロセスだけを再起動していたが、 今は再起動にかかる時間が少ない。コンテナなら破棄して再作成するだけ。
Apdex(アプリケーション性能指標)
- アプリケーションの応答時間やサービスの応答時間を基に ユーザー満足度を測定するための業界標準の指標
- 簡潔なサービス品質保証契約 (SLA:Service Level Agreement) ソリューション
IoT Botの監視(re:Invent 2018 DEV311)
資料紹介:運用自動化、不都合な真実(波多野)
監視 SaaS(網羅的で汎用的)
- Datadog, Mackerel, Stackdriver
Stackdriver
New Relic
- https://newrelic.co.jp/
- APMに強い
- アプリ寄りの出自。ログはこれから
sumoLogic
- https://www.sumologic.jp/
- ログ解析重点
- リアルタイムよりは分析で威力を発揮
Pingdom
- 外形監視特化
- 複数拠点からの死活監視
これまでの監視を振り返って、最近の監視で変わったことを考える
監視環境はいつでも構成変更できるようにすべき
Grafanaが可視化レイヤーを担うことで、内部のコンポーネントを変更可能になった。
- (これにより、アップグレードの単位が小さくなり、特に可視化レイヤーのアップグレードしやすくなったと思われる)
最近のトレンド
Googleトレンド検索によると、Zabbixの一強
- (これは監視SaaSは検索しなくても使えるからと思われる。Zabbixはノウハウを検索しないと使いこなせない)
最近の監視(モニタリング)は非技術者も見るようになってきている。
- (これはビジネスのKPIをダッシュボード化しているためと思われる)
「監視」でつくる「安全な自動デプロイ環境」
資料:https://www.slideshare.net/ssusere269e9/cicd-148257692
デプロイにはリスクがつきものなので監視が必要。
自動デプロイ失敗時は必ずアラートを通知すること
- CircleCIにはSlack通知機能がある
- CodePipelineでは、Lambdaなどを使って作る必要がある
デプロイするモジュールなどは事前にビルドしておきデプロイする時にしない方がエラー発生のリスクを減らせる。
Blue/Green deploymentによるデプロイリスク低減
- Blueを本番とした場合、Greenにデプロイしてリリースは切り替えるだけにする
REDメソッド
- Rate, Error, Durationに着目したアラート通知条件の設定
- レート(Rate) - 秒あたりのリクエスト数
- エラー(Errors) - リクエストの失敗数
- 時間(Duration) - リクエストの処理にかかる時間
勉強会で説明はなかったが、USEメソッドというのもある
- すべてのリソースについて、使用率(Utilization)、飽和状態(Saturation)、エラー(Errors)を確認する
- リソース(Resources):すべての物理サーバーの機能コンポーネント(CPU、ディスク、バスなど)
- 使用率(Utilization):リソースが処理中でbusyだった時間の平均
- 飽和状態(Saturation):リソースにサービスできない余分な作業がある度合い。(処理できてないものは大抵キューに入れられいる)
- エラー(Errors):エラーイベントの数
- 参考: http://febc-yamamoto.hatenablog.jp/entry/2019/02/17/152014
REDメソッドとUSEメソッドは両方一緒に使うべきらしい
複数ノードで構成されるクラスタをローリングアップグレードする際にあるノードがデプロイが失敗しても、通常の監視では気づきにくいので、デプロイの失敗は明示的にアラート通知すべき。
いまふたたびの CloudWatch Dashboards へ
2018年からCloudWatch Dashboardsのアップデートが多く発表された
- AWSのすべてのリソースがAutomatic Dashboardsで見れるようになった
- Metric Math により複数の CloudWatch メトリクスをクエリし、数式を使用して、これらのメトリクスに基づく新しい時系列を作成できるようになった
- 検索条件式が使えるようになった
Four of the Observability
- Monitoring
- Alerting/Visualization
- Distributed systems tracing infrastructure
- Log aggregation/analytics
Observabilityとは
- 複雑化するシステムの動作を追跡、把握できること
CloudWatchではグラフに注釈を追加でき、グラフ上に表示可能
- 未来の注釈も事前に追加可能
- (分析する時に便利そう)
その他
AWS Systems Manager
- 以下、引用
- AWS リソースの運用実態を把握して迅速に対応
- AWS でご利用のインフラストラクチャを可視化し、制御するためのサービスです。 Systems Manager を使用すると、統合ユーザーインターフェイスで AWS のさまざまなサービスの運用データを確認でき、AWS リソース全体に関わる運用タスクを自動化できます
- https://aws.amazon.com/jp/systems-manager/