Slide 1

Slide 1 text

Amazon Managed Service for Prometheus へ移行した話 2023-05-24 Qiita Night~AWS vol.2~

Slide 2

Slide 2 text

Cluster, Inc. 2 自己紹介 Tomohiro Urakawa / @corn3rl0ve https://cluster.mu クラスター株式会社でサーバーサイドの開発/運用を担当しています 最近なんかインタビューがでてました https://aws.amazon.com/jp/blogs/startup/tech-interview-cluster- 2023/ 好きなAWSサービスは

Slide 3

Slide 3 text

Cluster, Inc. 3 clusterについて 詳しくは AWS Summit Tokyoでえらいひとがしゃべったやつ をどうぞ

Slide 4

Slide 4 text

Cluster, Inc. 4 はなすこと Amazon Managed Service for Prometheusの 導入で、clusterのサーバーサイドの監視まわりがど うなったか を、ご紹介します。 ※今日の話に出てくる cluster という単語は、クラスター株式会社が提供するサービスの名称であることにご注意ください

Slide 5

Slide 5 text

Cluster, Inc. 5 clusterのサービス構成と監視(古代) いろいろ いっぱい ユーザーやイベントが 増えてきたな.. ECS EC2 Prometheus Grafana EC2インスタンス数 めっちゃ増えそうだな ... もっとmetricsを追加 したいな...

Slide 6

Slide 6 text

Cluster, Inc. 6 clusterのサービス構成と監視(旧) いろいろ めちゃめちゃいっぱい CloudWatch Prometheus Prometheus Prometheus Thanos Grafana Trickster X-Ray ECS EC2

Slide 7

Slide 7 text

Cluster, Inc. 7 clusterのサービス構成と監視(旧) それなりにスケールしたし、そこそこほっといても大丈夫ではあった (実際2年ほど運用した) ... が

Slide 8

Slide 8 text

Cluster, Inc. 8 起きてた問題 運用するものが多すぎる

Slide 9

Slide 9 text

Cluster, Inc. 9 シンプルに大変 ● 必要な知識、設定が多い ○ 単体ソフトウェアの設定だけでも大変なのに、バージョンアップなどで壊れな いよう維持するのは難しい ○ トラブルシューティングが大変 ● 監視系の可用性 ○ 本体サービス以上を求められる ○ 本体サービスを開発しながらこちらの運用をやるのは大変 ● コスト ○ 適切なスペックの判断が難しいため盛られがち

Slide 10

Slide 10 text

Cluster, Inc. 10 Amazon Managed Service for Prometheus https://aws.amazon.com/prometheus/ 長くて面倒なので AMP と略します

Slide 11

Slide 11 text

Cluster, Inc. 11 clusterのサービス構成と監視(旧) いろいろ めちゃめちゃいっぱい CloudWatch Prometheus Prometheus Prometheus Thanos Grafana Trickster X-Ray ECS EC2

Slide 12

Slide 12 text

Cluster, Inc. 12 clusterのサービス構成と監視(今) いろいろ CloudWatch Grafana Prometheus Prometheus Prometheus Thanos Trickster AMP めちゃめちゃいっぱい X-Ray ECS EC2

Slide 13

Slide 13 text

Cluster, Inc. 13 旧構成からの変化 めっちゃスッキリ

Slide 14

Slide 14 text

Cluster, Inc. 14 導入にあたっての注意 (1/3) AMPへpushしなければならない AMP側からscrapeしにくるものでは無いため、対象システム側からingestする 必要がある (場合によってはシステム改修を伴う) ● Prometheus remote_write ● AWS Distro for OpenTelemetry Collector 古いデータはingestできない 1hより前のmetric sampleは受け取ってくれない

Slide 15

Slide 15 text

Cluster, Inc. 15 導入にあたっての注意 (2/3) 上限緩和できないハードリミットが存在する。代表的なものは下記 詳細 Resource Default quota Possible error message Query bytes for range queries 5GB that can be scanned per 24-hour interval in a single range query. This quota can't be changed. the query hit the aggregated data size limit Query samples 50,000,000 samples that can be scanned during a single query. This quota can't be changed. query processing would load too many samples into memory in query execution Query time range 32 days between the start time and the end time of a PromQL query. This quota cannot be changed. the query time range exceeds the limit (query length: xxx, limit: yyy) 1回のクエリでスキャン可能なデータ量やサンプル数、指定可能な期間に制限がある

Slide 16

Slide 16 text

Cluster, Inc. 16 導入にあたっての注意 (3/3) 制限を確認して試算、必要であれば上限緩和申請する。代表的なものは下記。詳細 Resource Default quota Possible error message Active series (metrics that have reported data in the past 2 hours) per workspace 2,000,000. You can request a quota increase. per-user series limit of 2000000 exceeded, please contact administrator to raise it Active series per metric name 2,000,000. You can request a quota increase. per-metric series limit of 2000000 exceeded, please contact administrator to raise it Ingestion rate 140,000 samples per second. You can request a quota increase. ingestion rate limit (...) exceeded Retention time for ingested data 150 days. Data older than this is deleted from the workspace. You can request a quota increase or decrease. ※seriesの考え方は最後のおまけを参照

Slide 17

Slide 17 text

Cluster, Inc. 17 移行プロセス 1. AMPの準備 ○ ワークスペース ○ 権限 (IAM Role) 2. データ量を試算しQuotaを確認 ○ 必要なら上限緩和申請をおこなう ○ metricsの棚卸しをおこない、不要なものは消すなどの対応 3. AMPへingestできるようシステム構成や実装の変更 ○ remote_writeできるようにしたり、adot-collectorを導入したり 4. 自前Prometheusと一定期間併用 5. 新旧Prometheusでグラフを比較し確認 ○ AMPでは最大1ヶ月しか期間指定できないためdashboardの修正 6. 自前Prometheus廃止

Slide 18

Slide 18 text

Cluster, Inc. 18 運用してみて (まとめ) 圧倒的に楽 Active series系Quotaに余裕があるかは継続的なモニタリングが必要。あわ せて定期的にmetricsの棚卸しをやれると良い。 ハードリミットに注意 3ヶ月でどうだったっけ?みたいなのは無理。 クエリの期間指定が最大1ヶ月というだけなので、offset等を用いて1ヶ月より長 い期間のデータを集計対象にするのはOK timeoutがけっこう短い(気がする) ちょっと重めのクエリだとtimeoutになることが多い。recording ruleを作ると か、Tricksterなどのキャッシュを挟むのが良いかも?? (模索中...)

Slide 19

Slide 19 text

Cluster, Inc. 19 We are hiring! https://recruit.cluster.mu/engineer/

Slide 20

Slide 20 text

Cluster, Inc. 20 おまけ: seriesの考え方 https://prometheus.io/docs/concepts/data_model/

Slide 21

Slide 21 text

Cluster, Inc. 21 リンク集 cluster の紹介など ● サービスサイト https://cluster.mu ● インタビュー https://aws.amazon.com/jp/blogs/startup/tech-interview-cluster-2023/ ● AWS Summit Tokyo https://aws.amazon.com/jp/blogs/startup/event-report-aws-summit-cluster-2023/ AMP導入にあたって見ておくと良いもの ● AMPにmetricsを送り込む方法 https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-met rics.html ● AMPのクォータ https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html ● データ量の試算方法 https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-troubleshooting.htm l#AMP-understand-output ● product roadmap https://github.com/aws/amazon-managed-service-for-prometheus-roadmap/issues