マイクロサービス環境における監視の効率化

2021/09/15 NRUG : New Relic User Group
Nerd Life Talk

Transcript

1. Mobility Technologies Co., Ltd. マイクロサービス環境における監視の効率化 株式会社Mobility Technologies 技術戦略部SREグループ 水戸祐介
2. Mobility Technologies Co., Ltd. 2 水戸 祐介 Twitter: @y_310 株式会社Mobility Technologies (通称MoT) SREグループ タクシーアプリ「GO」を作っている会社です。 自己紹介
3. Mobility Technologies Co., Ltd. 3 ▪ AWSを中心にGCPも使用 ▪ Kubernetesベースの共通基盤をEKS、GKEの上で動かし社内に提供 ▪ ネームスペース20以上、デプロイメント80以上、Pod数600以上 ▪ マイクロサービスアーキテクチャを取っていることで比較的小規模なサービスが大量 にあり、毎月のように新たなサービスが増えている状況 以上の環境をSREグループ4名で運用 MoTのインフラ環境
4. Mobility Technologies Co., Ltd. 4 ▪ 毎月のように増えるサービスに対して個別対応していると早々にコントロール不能に なる ▪ 不十分な監視体制のままリリースされる ▪ 同じような構成のサービスなのに監視項目に差異が生じる ▪ 他サービスの知見が生かされない マイクロサービスにおける監視の課題 効率化しなければ破綻する 一貫した監視のポリシーを設 計し自動化する
5. Mobility Technologies Co., Ltd. 5 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪ メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
6. Mobility Technologies Co., Ltd. 6 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪ メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
7. Mobility Technologies Co., Ltd. 7 The Four Golden Signals (*)をベースに監視すべきメトリクスを設計 ▪ Latency ▪ アプリケーションのレスポンスタイム ▪ Traffic ▪ アプリケーションのRPS ▪ Errors ▪ アプリケーションのエラー数 ▪ Saturation ▪ アプリケーションやミドルウェアのリソース使用率(CPU、メモリ等) メトリクスの設計 - 監視ポイント * Site Reliability Engineering - Chapter 6 https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_g olden-signals
8. Mobility Technologies Co., Ltd. 8 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪ メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
9. Mobility Technologies Co., Ltd. 9 メトリクスの収集 Latency レスポンスタイム Traffic RPS Errors エラー数 アプリケーションのメトリクス MoT環境ではService MeshとしてIstioを導入しておりIstio経 由でサービス間通信のメトリクスを取得できる newrelic-istio-adapterでNew Relicに送信
10. Mobility Technologies Co., Ltd. 10 メトリクスの収集 Saturation CPU/Memory/etc インフラのメトリクス KubernetesのワーカーノードやAWS RDS、SQS などのクラウドリソースのメトリクス New Relic Infrastructure Agent New Relic Infrastructure Integration でNew Relicに送信
11. Mobility Technologies Co., Ltd. 11 これらはKubernetesクラスタやクラウド側で予めセット アップしておくもの メトリクスの収集 newrelic-istio-adapter New Relic Infrastructure Agent New Relic Infrastructure Integration つまりマイクロサービス単位での個別設定なしで必要なメト リクスを自動的に収集できる
12. Mobility Technologies Co., Ltd. 12 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪ メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
13. Mobility Technologies Co., Ltd. 13 ▪ 必要なメトリクスが集まったため後はNRQLで好きなようにダッシュボード化、アラート 設定ができる メトリクスの利用 Traffic, Errors, Latency アプリケーションのメトリクス Saturation Podのメトリクス Saturation クラウドリソースのメトリクス
14. Mobility Technologies Co., Ltd. 14 ▪ マイクロサービスを作る度にこれらのダッシュボードやアラートを作成するのは手間 が大きすぎるためTerraformで自動化する メトリクスの利用
15. Mobility Technologies Co., Ltd. 15 ▪ ダッシュボードはmodule化し、クラウドリソースのパネル のみオプションで表示を制御 ▪ アラートは以下の単位でmoduleを作成 ▪ アプリケーションアラート ▪ クラウドリソースアラート ▪ RDS ▪ SQS ▪ DynamoDB ▪ etc ▪ マイクロサービス毎に必要なアラートを組み合わせて設 定 Terraformによる自動化 固定 オプションで必要 なリソースのみ表 示 固定
16. Mobility Technologies Co., Ltd. 16 Terraformのディレクトリ構成 ▪ terraform ▪ modules ▪ newrelic-dashboard/main.tf ▪ newrelic-application-alerts/main.tf ▪ newrelic-rds-alerts/main.tf ▪ newrelic-...-alerts/main.tf ▪ service1 ▪ development/main.tf ▪ production/main.tf ▪ service2 ▪ service3 Terraformによる自動化 ダッシュボードモジュール アプリケーションアラートモジュール - エラー数、レスポンスタイムなど RDSアラートモジュール - コネクション数、CPU使用率など service1で使用するモジュールを定義するテンプレート service1のインフラリソース service2のインフラリソース
17. Mobility Technologies Co., Ltd. 17 Terraformによる自動化 モジュールを読み込んでサービスに合った閾値を設定するだけ で必要なダッシュボードとアラートが作成される 共通ダッシュボードモジュール 共通アプリケーションアラートモジュール 共通クラウドリソースアラートモジュール
18. Mobility Technologies Co., Ltd. 18 ▪ マイクロサービス環境では新規サービスの立ち上げが頻繁に発生するため自動化 が不可避 ▪ 汎用的なメトリクス設計を元にメトリクスの収集から利用まで自動化することで効率 的な運用が可能になる ▪ New RelicはNRQLの柔軟性と性能によってマイクロサービスの監視を楽にしてくれる まとめ
19. 文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Mobility Technologies Co., Ltd. 19