Google Managed Prometheus が GA したので乗り換えていく
Google Managed Prometheus が GA したので Ubie では本格的に移行を進めています。
Google Managed Prometheus とは
その名の通りGoogle CloudのPrometheus互換のプロダクトです。正式名称は Google Cloud Managed Service for Prometheus ですが、各種リソース名が GMP (Google Managed Prometheus)と略されてるのでここではGMPと呼びます。
そして2/28 (日本時間3/1)にGAしました。
GA したばかりですが Preview の段階でほぼ検証を済ませていたので絶賛移行を進めています。今回は GMP の概要と Ubie での GMP 移行計画について簡単にまとめました。
※ Google Cloud の GA/Preview についてはこちら
Monarch
先程 Prometheus 互換とか書きましたが、GMPはGCE上に Prometheus がホスティングされているわけではなく、 もともと Cloud Monitoring で使用しているMonachというストレージをバックエンドに構築されています。
Monach 自体についてはこちらの論文でまとめられています。(Google’s Planet-Scale In-Memory Time Series Database タイトルだけですごい) Googleの内部で長年利用されてきたインメモリのTSDBです。これがどのくらいスケールするかについては Product Manager の方が Cloud Next21 のセッションの中で楽しそうに解説しています。
もともと専用の sidecar を利用し Cloud Monitoring API に書き込むオプション(Prometheus server with Stackdriver collector) が公式から出ていましたが、ラベル数の上限などいくつか制限があり弊社では利用するのが厳しい面が有りました。GMPではこのあたりが解消しています。
GMPの使い方
簡単に使い方を紹介します。詳しくはドキュメント参照ください。また3分ほどで解説している動画もあります。
セットアップ
GMP をセットアップする方法は2種類あります。一つは Managed Collection を利用する方法です。Managed Collection を利用するとメトリクスを収集する Prometheus を自前で運用する必要がなくなります。もう一つは Prometheus Operator などを使った自前での Self-deployed collection を利用する方法です。
新規で利用する場合は Managed Collection で気軽に始められますし、すでに Prometheus を運用している場合は Self-deployed collectionで既存の Prometheus の資産を活かしつつ移行することができるでしょう。
また、GA に伴い Managed Collection は GKE のオプションとして gcloud で有効化できるようになりました。
gcloud beta container clusters update CLUSTER_NAME --enable-managed-prometheusメトリクスの収集
Prometheus Operator の場合 PodMonitor や ServiceMonitor を利用しますが、GMP では PodMonitoring/ClusterPodMonitoring というリソースが登場します。名前の通り PodMonitoring は特定の namespace の Pod を、ClusterPodMonitoring は namespace をまたいだPodを対象にしています。
基本的には selector/endpoints を指定するだけです。
apiVersion: monitoring.googleapis.com/v1alpha1
kind: PodMonitoring
metadata:
name: sakajun-app
namespace: sakajun-public
spec:
selector:
matchLabels:
app: sakajun-app
endpoints:
- port: http-web
path: /prometheus/stats
interval: 30s詳しいAPI spec については GitHub まとめられているのでそちらをご覧ください。Convert existing prometheus-operator resourcesのセクションにServiceMonitorからの移行についても記述があります。
(Preview の途中まで ClusterPodMonitoring がなかったため、フィードバックをして待ってました。)
メトリクスの利用
Cloud Monitoringのコンソール中から Managed Service for Prometheus を選択でき、簡単にクエリを試すことが可能です。
またMetrics Exploreで通常のCloud Monitoringのメトリクスと同じように確認することができます。
Grafana からも利用できますが、Googe API(OAuth2)とGrafanaが直接通信することが現状できないので専用のfrontendをデプロイする必要があります。
GMPの制約
ドキュメントにもありますがすべてのPromQLがサポートされてるわけではないので注意が必要です。 PromQL support にまとめられています。
また Managed Collection の場合 Prometheus 自体と比べるといくつかスクレイピングのオプションが少ないので注意が必要です。
Ubie でのモニタリング
少々 GMP の話が長くなってしまったので、 Ubie でのモニタリングとPrometheus の話に移りたいと思います。Ubie のサービスは分散システムで複数のアプリケーションで構築されています。それらは GKE 上に構築した Istio のサービスメッシュ上にデプロイされています。Prometheus を利用することで Istio のメトリクスや GKE のメトリクス、アプリケーションごとのメトリクスを取得、Grafanaで可視化しています。
また、データベースなどマネージドサービスを多く利用しているのでそれらのリソースについては Cloud Monitoring を利用しています。
それぞれどのように利用しているか簡単にまとめてみます。
Prometheus
既存の Prometheus は Grafana Cloud のPrometheus を利用しています。これは限られた人的なリソースの中で運用コストを少しでも減らすということで選定しました。今回はこれをGMPに移行していきます。
メトリクス
具体的には下記のようなメトリクスを可視化しています。
- Istio
- Kubernetes
- アプリケーション固有のメトリクス(Micrometerなど)
- Argo stack
- etc…
メトリクスの活用
- Grafanaでの可視化
- Alertmanager でのアラート
- HPAでの利用 (Prometheus Adapter)
Cloud Monitoring
次に Cloud Monitoring について紹介します。利用の最大の理由はマネージドサービスを多く利用しており、それらのメトリクスは Cloud Monitoring に統合されているためです。
また、 Prometheus や他の SaaS でこれらのメトリクスを収集すると費用面でも気になります。
Cloud Monitoring メトリクスの活用
- Grafanaでの活用
- トラブルシューティング時のMetrics Explore
- Cloud Monitoring Alert
特に SLO Monitoring は便利です。
ダッシュボードを Grafana に統一しているため、 Cloud Monitoring のメトリクスも Grafana で見れるようにしています。
Cloud Logging
今回のテーマとは関係ないですが、ログについては Cloud Loggingを使用しています。検索の柔軟性、Log Routerの活用、コストなどが理由です。
既存の Prometheus の構成と乗り換えの背景について
Prometheusの構成
ということでGrafana/Prometheus/Cloud Monitoringを利用していますが、それらはこういう構成になっています。
- GKE 上に Prometheus Operator を利用し kube-prometheus を構築
- GKE 上のPrometheusから Grafana Cloud のマネージド Prometheus に対して remote_write で書き込み
- Grafanaで可視化
細かいですが Prometheus Operator の方も Persistent Disk で永続化しています。(Cloud Filestore を使うなどの議論もありました)
既存のPrometheusでの課題
乗り換えの話に移る前に、既存の構成の問題点など乗り換えの背景をまとめます。既存のPrometheusには、費用の問題とスケーラビリティという問題が大きく２つありました。
費用
もともと利用している Prometheus は、交渉やコミットにより下げる余地はあるものの、インフラコストをかなり圧迫していました。 GMP の課金体系が少し複雑ではあるものの、概算で今よりはコストが下げられる見込みがあります。また全体としてはそこまで大きくないものの Google Cloud の外にあることにより Egress のトラフィック課金が発生します。
GMP では Non-chargeable metrics で Anthos や Istio (w/ GKE Addon) に対して無料枠があるのも魅力です。(話は脱線しますが、Open-source の Istio からマネージドに切り替えることも将来的な選択肢として考えています)
スケーラビリティ
サービスの成長やマイクロサービス化などでマネージド Prometheus の制限を緩和をするなどしのいできましたが、自分たちで運用している Prometheus を含め水平にスケールするよう構成を変えていく必要が出てきました。
GMP の場合 Monarch をバックエンドにしているので、Cloud Monitoiringと同等に（しらないところでスケールしてくれる）利用できることが期待できます。複雑な構成を取らずにスケールするのであればそれが嬉しいです。
これら以外にも細かな課題がありました。
Prometheus の運用
そこまで負担になっているわけでもないですが、PrometheusOperator 自体やkube-prometheus のバージョンアップなどの負担を減らしたいというのがあります。
セキュリティ上 Google Cloudの外に出したくない
Generalなメトリクスのみなので当然 PII 等取り扱いに気をつける必要があるものは有りませんが、万が一を考慮しクラウド内に収めたい、remote_write などの API Key の管理をしたくないというのがあります。(GMPの場合基本的にはIAMで完結)
Grafana Cloud にもいいところがある
移行の背景ばかり説明してきましたが、 Grafana Cloud にもメリットがあります。マネージドでアップデートも自動で行われるため運用コストがかからないだけでなく、Grafana Machine Learningなど最新の機能がすぐに使えます。また CVE が見つかった際にもマネージド側で対応されています。
乗り換えの計画
最後に移行計画について紹介します。
GAのタイミングで移行完了できたら良かったのですが、他の施策との兼ね合いもありできませんでした。この執筆時点では、「あとはやるだけになった」というような感じです。
３月中には移行完了の予定なのでまたブログでまとめたいと思います。
Prometheus
冒頭で解説した Managed collection を利用して既存の Prometheus と同じメトリクスを GMP に飛ばし、並行稼動期間を設けた上で既存の Prometheus を廃止していきます。また cAdvisor など一部のメトリクスについてはスクレイプせず、Cloud Monitoringのメトリクスで代用することでコストを削減していきます。
Prometheus Adaptor
各種 HPA から直接 GMP にを参照するようにし Prometheus Adaptor は廃止します。Workload Metrics と同じ要領でmetric nameを修正すれば動きます。管理するコンポーネントを少しでも減らしたいところ。
Alertmanager
そこまで複雑なアラートはないので Cloud Monitoring の Alert に移動しterraformで管理していきます。SLO Monitoringも活用していきます。
Grafana
運用がそこまで負担にならないこと、GMPのfrontendをホスティングする必要する必要があることから、IAPをセットしたGrafanaを自前で構築する予定です。
まとめと今後の展望
簡単に Google Managed Prometheus の概要と Ubie における利用計画をまとめてみました。AWS には Managed Prometheus があっていいなーと思っていたところ Google Cloud にも来てくれたので嬉しいです。GKEで簡単に有効化することができるようになったので、今までPrometheusを使ったことがなかった方も気軽に試せるのではないかと思います。
個人的にはCloud Monitoring のMQL と Prometheus の PromQL の棲み分けがどうなるか気になります。現状 GMP Metrics に対してのみ PromQL が投げられる状況ですが Cloud Monitoring のMetrics に対しても PromQL が使えるとシステムの連携やユーザーの学習コストの観点で良さそうかと思っています。
GMP の今後のアップデートに期待してます！
