はじめに
AWS Startup Loftにて、Observabilityに着目した「AWS 秋の Observability 祭り」というイベントが開催されました
Observabilityがキーワードになっているため、CloudWatchに関連する話が多かったです
ただ、Observabilityについて改めて考えるという意味でも、とても勉強になるイベントでした
後ほどAWSさんから公式にブログが公表されるとのことですが、最速版として参加レポートを残しておきます
10/10追記
AWSさん公式のブログが公開されていました
発表資料の閲覧もできるので、ぜひ合わせてご覧ください
※以下、「Observability」を適宜「O11y」と略して記載します
[AWSセッション] Amazon CloudWatchはじめとしたObservabilityの最近のアップデート紹介
- O11yはなぜ必要か？
- システムの構造が複雑になってきている
- 「理由が未知、原因も未知」の問題が発生する
- メトリクス、トレース、ログを取得することが重要
- 3つの使い分けはA needle in a haystackの例えで話される
- 干し草の山（一つ一つのシステムを例えている）の中から一本の針を見つけるような場合を想定
- まずはアラートを発生させて針が混入したことを検知
- トレースしてどの干し草の山が怪しいかあたりをつける
- メトリクスを見て山の中のどの辺に問題があるかを考える
- 実施にどこに針があるのかは、ログを見て特定していく
- 3つの使い分けはA needle in a haystackの例えで話される
- O11yに正解はない、ビジネス要件に合わせて考えていく
- システムの構造が複雑になってきている
- CloudWatch 最近のアップデート
- Internet Monitor
- インターネットの問題がパフォーマンスにどう影響しているかを可視化する
- どれくらいのプロバイダーからデータを引っ張ってくるかどうかによって料金が異なる
- 最近（7月）にNLBもモニタリング対象になった
- CW AgentがOTelとX-Rayをサポート
- OTel, X-RayのエージェントやSDKが不要、CW Agentだけで対応可能になった
- ダッシュボード変数のサポートを開始
- メトリクスの中の任意の値を変数にして、ダッシュボードをカスタマイズ可能になった
- ドロップダウン、ラジオボタン、テキスト入力に対応
- CW LogsにLive Tailが追加された
- リアルタイムログの調査が可能
- Linuxのtailコマンドのようなことができる
- CW Logsに正規表現が使用可能になった
- フィルタパターン、メトリクスパターンで正規表現が使用可能に
- Internet Monitor
[AWSセッション] Observability と Dashboard Best Practice
- O11yベストプラクティス
- Amazonが掲げる重要な要素5つ
- 重要なものを監視する
- まず最初に成功基準を明確にすると進めやすいと思う
- システム全体の健全性の把握とツールの選定
- メトリクス、ログ、トレースを収集して分析するツールが必要になってくる
- このツールは共通のものを使用することで、管理や新人トレーニングの負荷が減る
- 既存のツールがある場合は完全に消すのではなく、活かして連携することも考える
- 全てのレイヤーからテレメトリーデータを収集する
- インテグレーション、システム間の連携を把握することが重要になってくる
- エンドユーザーの体験を念頭におく
- 細部に囚われすぎない
- 重要なシステムから始めて、重要なシステムと連携するコンポーネントにどんどん広げていく
- 最初からO11yを組み込む
- 最初から組み込むことで開発速度の向上にも繋がる
- 重要なものを監視する
- O11yのサイクル
- 運用のカイゼンのためにまわすO11yのサイクル
- 質問を受けてインストルメンテーション（計測）をする
- インストルメンテーション（計測）の結果としてログ、メトリクス、トレースを出力
- ログ、メトリクス、トレースを受けてアラート発砲やダッシュボードを実装
- アラート発砲してみた結果やダッシュボードを使ってみた結果、質問が来る
- 質問を受けて、さらにインストルメンテーション。。。というサイクルを回す
- （おそらく）元ネタになっているセッションに関する記事はこちら
- 運用のカイゼンのためにまわすO11yのサイクル
- Amazonが掲げる重要な要素5つ
- ダッシュボードベストプラクティス
- （おそらく）元ネタになっている記事はこちら
- 目的別ダッシュボードの構築
- ダッシュボードを見る人、チーム、使用用途によってダッシュボードを変える
- 「そのダッシュボードを誰が見るか」が重要
- ビジネス視点でダッシュボードを見る人に向けては、抽象度の高い（高レベル）ダッシュボード
- 伝えたいメッセージを絞る
- 情報過多にならないように注意する
- システム視点でダッシュボードを見る人に向けては、抽象度の低い（低レベル）ダッシュボード
- 目的に特化したダッシュボードを作成する
- ダッシュボードを見る人、チーム、使用用途によってダッシュボードを変える
- ダッシュボードの設計
- 「見るひとがすぐに理解して使える」ことが重要
- AmazonのTips
- 最重要なメトリクスは最上位に大きく表示
- ディスプレイサイズを適切にする
- スクロールしないと見れない、などはだめ
- タイムゾーンを一つに絞る、などなど
- ダッシュボードのメンテナンス
- お客様の影響を明確にしたのか、障害対応に役立ったのか、定期的にレビューを行う
- CW Dashbord
- 好みのダッシュボードを異なるアカウント、異なるリージョンのリソースでダッシュボードを準備することが可能
[NTTドコモ様 事例] マイクロサービスのためのシステム運用を一瞬でラクにするオブザーバビリティ事例
- サービス紹介
- スーパー販促プログラム
- 他システムとの連携が複雑に絡み合ってきているため、O11yがないとやっていけない状態になっている
- システム運用をラクにする取り組み
- DataDogを使用
- ダッシュボードのテンプレが提供されているので、1時間ほどでダッシュボードが作成できた
- slackと連携して通知をさせている
- ユーザーに提供しているAPIや外形監視にはすぐ気づけるように通知
- 実例
- 外形監視でAPIのレイテンシーが悪化しているというアラート
- ダッシュボードからでは原因がわからなかった
- 原因はDynamoDBのキャパシティユニット枯渇が原因
- CWのContributor Insightsで確認ができた
- 外形監視でAPIのレイテンシーが悪化しているというアラート
- カスタムメトリクスの活用
- GoogleCloudのAPIをLambdaで定期的に叩き、カスタムメトリクスを使用して可視化
- ElasticashやDynamoのメトリクスから待機人数を出してカスタムメトリクスとして通知
- DataDogを使用
- まとめ
- SaaSは便利だが、全てのメトリクスがリアルタイムには反映されない
- 各サービスのコンソールでメトリクスがすぐにモニタリングできるので、有効活用すべき
- 作らなくてもすでに用意されているものもあるので、それだけでも十分O11yになる！
[AWSセッション] Observability Code の必要性
- O11yの実装における課題
- 変化への対応
- システムの変化にO11yも対応していかないといけない
- 煩雑な管理・設定漏れ
- システムが複雑になると発生しがち
- 開発スピード
- 実装する時の手順が面倒になるなど
- 変化への対応
- Observability Codeとは
- IaCをO11yの領域に適用した考え方を指す
- IaCによってO11y関連のリソースを構築する
- 使うIaCツール
- CloudFormation
- CDK
- Terraform
- Pulumi、などなど
- CDKを使ったObservability Code
- CDKは使い慣れたプログラミング言語を使って、クラウドのリソースを管理できる
- 大きなメリット3つ
- 開発者体験を改善
- アプリケーション全体をコードで管理
- 高レベルの抽象化でインフラ構築
- Terraform
- 独自言語HCLを使用
- 使用するメリット
- プロバイダを使うことでAWS以外のサービスも管理することが可能
- ナレッジが豊富
- Observability Codeが与える変化
- インフラとO11yを一緒に管理することで、リソースの変化に追随することが可能
- リソース作り直しによるIDの変更などにも追随可能
- 設定漏れ、確認漏れのリスク低減
- コードと設計書を照らし合わせるだけで漏れを検知できる
- Policy as Codeを使用することでガバナンスを効かせることも可能
- 開発効率向上
- 人手の介在を減らすのでスピードアップ、ミスを減らすことが可能
- バージョニングして管理することも可能
- インフラとO11yを一緒に管理することで、リソースの変化に追随することが可能
- Observability Codeの活用
- O11yライフサイクル
- 実装、可視化、通知の領域（分析以外）にObservability Codeが活用できる
- O11yライフサイクル
[株式会社デイトナ・インターナショナル様 事例] ECサイトのサーバ監視: コード化の取り組みとメリット
- 現状の監視設定フロー
- CDKでリソースをデプロイ
- デプロイしたリソースの情報をコンソールで確認
- Zabbixにリソース情報を設定
- 課題
- リソース再作成をするたびにZabbixの設定をし直す必要あり
- 手間がかかる＆ミスも発生しやすい
- コード化による改善
- リソース再作成での設定変更を自動化
- 一回設定すればコードをコピペして対応可能
- レビューもコードを見れば良いのでやりやすい
- ZabbixからDataDogへの移行
- 移行の理由
- 機能が豊富、O11yの実装もしやすそうだから
- 実装手順
- まずはCDKでAWSリソースをデプロイ
- CfnOutputを使用して値をJSONにアウトプット
- DataDogはCDK for Terraformを使用してデプロイ
- CfnOutputで出力された値を参照する
- まずはCDKでAWSリソースをデプロイ
- 移行の理由
参考
AWsさんのセッションの内容ですが、おそらく去年のre:Inventのセッション「Observability best practices at Amazon」が元になっていると思われます
非常に興味深い内容なので、後ほどじっくり読んでみようと思います
また、このイベントの前に、JAWSーUGでもCloudWatchに関する勉強会が開催されました
超多機能なCloudWatchについて、改めて勉強するのにうってつけの内容になっています
アーカイブ動画、登壇資料、いずれも公開されているのでぜひ一緒にご覧ください！