[レポート]無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜 #devsumi #devsumiB

こんにちは、坂巻です。

翔泳社主催のイベントDevelopers Summit 2019にて、セッション「無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜」を聴講してきましたのでレポートします。

登壇者

Datadog Sales Engineer 池山 邦彦 さん

概要

DevOpsにおいてモニタリングは重要なパートを占めています。リリースしたアプリケーションが正常に稼働しているか、パフォーマンス劣化していないか、過負荷になっていないか、リクエストに応じて適切にスケールアウトされているか、といった観点でサービスをモニタリングする必要があります。 インフラメトリクスからアプリケーションパフォーマンスまで多種多様のモニタリングを始めた結果、複数のモニタリングツールを使って運用の負担が増えたり、アラートの嵐に悩まされて重要な通知を見落としてしまう、というようでは適切なモニタリングとは言えません。 このセッションでは、運用負荷を下げつつ素早いリリースに繋げてユーザーに更なる価値を届けるために、Datadogを使って何をどうモニターすれば良いのかデモを交えてお伝えします。

レポート

Datadogってなに？

クラウド時代の開発者&運用担当者のためのモニタリング＆分析SaaS。

• リアルタイムのパフォーマンス可視化
• 強力なアラート
• 履歴の分析
• 根本原因の相関と分析
• ダッシュボードの公開やチーム間のコラボレーション

レガシーなモニタリングツールではクラウド時代のスピードとペースについていけない。

なぜモニタリング？

サービスダウンに伴う機会損失。

• サービスのSLOは？
• 99.9% → 年間8.76時間のダウンまで許容
• 99.99% → 年間0.876時間のダウンまで許容
• 1時間のサービスダウンで発生する機会損失は？
• 100万ドル（約1億円）/時間の場合...
• 3時間のダウンでサラリーマンの生涯所得を上回る
• 3分間のダウンで5万ドルの損失＝社員1人の年収
• Amazonは1時間のダウンで14億円の損失があるとか
• 失われるのはお金だけ？
• 社会的信用
• 顧客満足度
• リピート率

サービス稼働を可視化してコントロールすること、普及を早めてリスクを最小化することが重要。

システムの可能性における三本柱

• Traces
• サービス間の原因特定
• アプリケーションのスループット、レイテンシー、エラー
• リクエストベース
• Metrics
• トレンドやパターンを把握
• システムやミドルウェアのパフォーマンス
• 組み合わせや集計による分析
• Logs
• インシデントの調査
• デバッグやトラブルシューティング
• イベントベース

Why Datadog

• 250以上のインテグレーション
• AWS、GCP、nginx..
• チームを跨いだコラボレーション
• セルフサービス、OOTB（そのままつかえる）、Fast time to Value
• メトリクス、イベント、APM（Application Performance Monitoring）、ログの相関
• 機械学習を含むスケーラブルなプラットフォーム

クラウド時代のモニタリング そのポイントは？

Cattle, not pets(ペットではなく家畜)

• サーバ1台1台を細かく監視するのではなく、サービス（サーバー群）として捉える
• その実現方法がタグ（DataDogを使用する上で非常に重要）

Tag（タグ）

• メトリクスに付帯
• Key:Value形式で1個のメトリックに複数のタグを付与することが可能
• フィルタリング／グルーピング
• サーバやVM、コンテナ、データセンター、ゾーンごとに分析可能
• カスタマイズ可能
• エージェント設定ファイル、UI、インテグレーション..自身でタグの付与が可能

モニタリングのポイント

ワークメトリクス

• スループット
• 単位時間あたりの処理量（通常は絶対値で表現）
• 例：秒間HTTPリクエスト数／秒間DBクエリー数
• 成功
• 成功した処理のパーセンテージ
• 例：秒間HTTPステータス2XXの割合／成功したDBクエリーの割合
• 失敗
• 失敗した処理のパーセンテージ
• 例：秒間HTTPステータス5XXの割合／例外処理が発生したDBクエリーの割合
• パフォーマンス
• 成功が完了するまでに要する時間といった効率
• 例：99%のリクエストが0.1秒以内にレスポンスされる／クエリー時間の90パーセンタイル値

リソースメトリクス

• 使用率（utilization）
• リソースがビジー状態になる時間の割合、リソースが使用されているキャパシティの割合
• 例：ビジー状態のディスクI/Oの時間%／合計メモリに対する使用%
• 飽和度（saturation）
• 処理しきれないリクエスト量
• 例：メモリのスワップ量／キューに溜まっているDBクエリー数
• 失敗（error）
• 処理そのものからは見えない内部エラー
• 例：ディスクデバイスエラー数／DBレプリケーションエラー数
• 可用性（availability）
• リソースがリクエストに応答可能な状態となっている時間の割合
• 定期的にチェックされている場合のみ観測可能
• 例：ディスク読み書き可能な時間%／DBにアクセス可能な時間％

イベント

• メトリクスとは別にシステムの変更といった重要な通知をイベントとして記録
• 頻度としてはメトリクスほどではないが原因究明につながる情報を含むことがある
• 変更（changes）
• コード変更のリリースやビルド、パッチ適用..
• アラート（alerts）
• 生成されたアラートや3rd Party製品の通知
• スケーリング（scaling ecents）
• サーバやコンテナの追加／停止

APM

• アプリケーション開発とインフラ運用の統合
• DevOpsのチーム体制やインフラの変化（オートスケール、マイクロサービス、コンテナ化）に伴いフルスタックでのモニタリングが必要となった
• アプリケーションのスループット、エラー、レイテンシ
• トランザクションのトレーサビリティ
• サービスマップ

ログ

• 詳細な原因や傾向を分析
• アプリケーショントレースとの相関
• ログパターン分析

Datadog APMの特徴

• 関数やメソッドごとのパフォーマンスやエラーのトレースを簡単な設定で取得可能
• メトリクスやログとのシームレスな相関をGUIで実現
• マイクロサービスの分散トレーシングも可能
• OpenTracingにも対応
• 対応言語：python、Ruby、Go、Java、Node.js、.NET、PHP

サービスマップ

• サービスの依存関係が見えるサービスマップがオススメ機能
• 何がどういうAPIコールをしているか、マイクロサービスを可視化できる

依存関係の可視化等、サービスマップの画面の案内がありました。

Datadogでモニタリングしよう

アラートの種類

緊急性に応じて3段階のレベルでアラートを使い分ける。

• 記録する（Record） 緊急度：低
• 誰かに知らせる必要がなく、モニタリングシステムに記録するだけ
• 例：データベースのクエリーレスポンスが遅くなってきているが、サービス全体のレスポンスに影響する程ではない
• 通知する（Notification） 緊急度：中
• すぐに対応が必要ではないが、誰かが対応できるようにメールやチャットで知らせる
• 例：ディスクスペースが逼迫してきているので数日以内での対応が必要
• 呼び出す（Page） 緊急度：高
• 他の仕事や私用を中断してでも対応が必要なものを担当者に直接連絡して呼び出す
• 例：レスポンス時間がSLAに抵触するほど遅延している

モニタリングの種類

• 閾値
• 異常検知（Anomaly）
• 外れ値(Outlier)
• 予測(Forecast)
• ログ
• APM
• 複合条件

アラートワークフローで約に立つ豊富なインテグレーション

• UIから簡単にセルフインストール可能
• さまざまな3rd Partyツールとの連携
• Slack、PagerDuty、JIRA..
• モニターごとに個別に連絡先を指定可能

Synthetics ／ 外形監視

• サービスを外側から監視
• 複数の拠点から任意のサイトやAPIエンドポイントにHTTP(S)リクエストを送信して監視
• クライテリアとしてステータスコード、レスポンス時間、ヘッダ等の指定が可能
• モニター対象として通知、稼働状況をダッシュボードで可視化することが可能
• 2019年２月現在プライベートβ

Demo

会場ではAgentのインストール（1分かからず完）、設定ファイルからのタグ付け、インテグレーション（Nginx）画面等のデモがありました。

さいごに

デモを交えてのセッションで、Datadogの使い所がわかりました。今Datadogをトライアルすると、Nintendo Switchの抽選プレゼントがあるようです。当たるといいなー

余談ですが、DataDogさんは猫派が多いそうです。