PrometheusとAWSのサービスを組み合わせてオブザーバビリティを実現
株式会社ココナラ / k
テックリード / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
ツールの利用規模 | ツールの利用開始時期 |
---|---|
11名〜50名 | 2018年 |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBRUT09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--4011c04ff3eb5be88d992a70717768d8398f78f1/prometheus_100.png?disposition=inline)
アーキテクチャの意図・工夫
以下の3点を考慮しました。
詳細は、こちらのブログの「考慮事項」に記載しています。
- どこで計測するか?
アクセスログはALBだけではなく、Nginxでも出力されています。データソースとして、どちらを使用するか検討しました。 - どうやって計測するか?
Prometheusでは、ラベルにURLのような種類の多い値を使うことはあまり推奨されていません。ラベルのカーディナリティが高いと動作が遅くなってしまうためです。そのため、 Promethuesで本当に実現できるのか? という懸念がありました。 - 大量のログをどう処理するか?
アクセスログは大量に出力されます。大量のログを一定時間以内に高速に処理する必要があります。
導入の背景・解決したかった問題
導入背景
導入前の状況・課題
異常発生時に、事象や影響範囲の把握、原因の調査に時間がかかっていました。各種ログやAmazon CloudWatchなどのメトリクスを1つずつ確認する必要があり、迅速に解決することが難しい状況でした。
また、以下のような課題がありました。
- URL単位でモニタリングできない
CloudWatchで確認できるのは、ALBまたはターゲットグループ単位のメトリクスまでで、URL単位では確認できなかったです。 - URL単位に確認したい場合、NginxのアクセスログをCloudWatch LogsやBigQueryで検索する必要がありました。
- 検知できないエラーがあった サイト全体に影響を与えるようなエラーであれば、CloudWatchだけで十分検知できていましたが、特定のURLだけで少量発生したエラーやログも出力されていないようなエラーは検知できないことがありました。
目指していた状態
プロダクトのオブザーバビリティが確立されている状態。
異常発生時にどこで何が起きているかが手に取るように分かる状態。
比較検討したサービス
- Amazon CloudWatch
- Datadog
- New Relic
比較した軸
導入の背景で書かせていただいた課題を迅速に解決できる点です。
選定理由
- オブザーバビリティを実現するツールのデファクトスタンダードであること。
- GitHubで公開されている各種Exporterを使用することで、様々なメトリクスを簡単に収集できること。
- Exporterが公開されていない場合も、クライアントライブラリを使って簡単に自作できること。
導入の成果
導入によって上記の課題を解決することができました。
加えて、Prometheusを使用してURL毎にエラーやレイテンシを可視化することで、それまで見えていなかった問題が見えるようになり、UXの改善にも繋がりました。
また、前述のように、レイテンシが遅いURLトップ10を可視化することでエンジニア内で競うように改善が進んでいくという文化面での変化もありました。
導入時の苦労・悩み
やりたいことを実現するために独自のExporterを作成し、Prometheusにデータを流し込む必要がありました。
ただ、2週間ほどで後述のアーキテクチャ図の仕組みを構築することができたので、それほど大きな苦労ではありませんでした。
導入に向けた社内への説明
上長・チームへの説明
現在の課題と解決するためのアーキテクチャを整理し、説明しました。PrometheusはOSSで、SaaSのように高額な費用はかからなかったので、ライトに導入することができました。
社内への展開・導入推進
Grafanaで即利用可能な様々なダッシュボードを整備して展開しました。また、レイテンシが遅いURLトップ10を可視化し、エンジニア内で競うように改善を行っていました。
活用方法
SLOを設定し、全社的にモニタリングを行っています。
また、URL毎のCore Web Vitalsの数値も可視化するなどの機能追加も随時行っています。
よく使う機能
- Grafanaによるメトリクスの可視化
- Exporterやクライアントライブラリによるメトリクスのインストルメント
ツールの良い点
- 様々なExporterがGitHubで公開されており、それらを使うことで簡単に各種メトリクスが収集できること
- 最近では、Amazon Managed Service for Prometheusのようなマネージドサービスがあり、以前に比べて楽に運用が可能であること
ツールの課題点
- カーディナリティが高いデータの取り扱いが苦手なこと
カーディナリティが高いデータをPromQLでクエリすると時間がかかります。ただし、レコーディングルールで事前に集計しておくことである程度対応できることと、カーディナリティが高いデータを扱いたいケースがそれほど多くないことから大きな課題ではありません。 - クエリ言語PromQLに癖があること
PromQLは慣れれば使いやすいのですが、独自の構文なので最初は慣れが必要です。
その他
Prometheusを実行しているサーバーのディスクの使用率が100%になり、アラートが上がったことがあります。 マネージドサービスを使えば、そのような運用面もあまり気にしなくてよくなるので、今から使うならマネージドサービスを使うのがおすすめです。
ツールを検討されている方へ
Promethesから生まれたメトリクス形式は、現在ではOpenMetricsとして標準化され、その収集と可視化がオブザーバビリティ実現の必要条件になってきています。例えば、OpenMetricsは今ではDatadog、New Relic、Azmon CloudWatchなどの様々なサービスで扱うことができます。
また、各種メトリクスをOpenMetricsとして公開するフレームワークやライブラリも増えてきました。
興味のある方は活用を検討してみてください。
株式会社ココナラ / k
テックリード / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
大学卒業後、SIerに入社。 2019年にココナラにSREとしてジョイン、現在は技術戦略室を担当。
株式会社ココナラ / k
テックリード / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
大学卒業後、SIerに入社。 2019年...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法