Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Yusuke Mito
September 15, 2021

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

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

Yusuke Mito

September 15, 2021
Tweet

More Decks by Yusuke Mito

Other Decks in Programming

Transcript

  1. Mobility Technologies Co., Ltd. 2 水戸 祐介 Twitter: @y_310 株式会社Mobility

    Technologies (通称MoT) SREグループ タクシーアプリ「GO」を作っている会社です。 自己紹介
  2. Mobility Technologies Co., Ltd. 3 ▪ AWSを中心にGCPも使用 ▪ Kubernetesベースの共通基盤をEKS、GKEの上で動かし社内に提供 ▪

    ネームスペース20以上、デプロイメント80以上、Pod数600以上 ▪ マイクロサービスアーキテクチャを取っていることで比較的小規模なサービスが大量 にあり、毎月のように新たなサービスが増えている状況 以上の環境をSREグループ4名で運用 MoTのインフラ環境
  3. Mobility Technologies Co., Ltd. 4 ▪ 毎月のように増えるサービスに対して個別対応していると早々にコントロール不能に なる ▪ 不十分な監視体制のままリリースされる

    ▪ 同じような構成のサービスなのに監視項目に差異が生じる ▪ 他サービスの知見が生かされない マイクロサービスにおける監視の課題 効率化しなければ破綻する 一貫した監視のポリシーを設 計し自動化する
  4. Mobility Technologies Co., Ltd. 5 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪

    メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
  5. Mobility Technologies Co., Ltd. 6 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪

    メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
  6. 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
  7. Mobility Technologies Co., Ltd. 8 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪

    メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
  8. Mobility Technologies Co., Ltd. 9 メトリクスの収集 Latency レスポンスタイム Traffic RPS

    Errors エラー数 アプリケーションのメトリクス MoT環境ではService MeshとしてIstioを導入しておりIstio経 由でサービス間通信のメトリクスを取得できる newrelic-istio-adapterでNew Relicに送信
  9. Mobility Technologies Co., Ltd. 10 メトリクスの収集 Saturation CPU/Memory/etc インフラのメトリクス KubernetesのワーカーノードやAWS

    RDS、SQS などのクラウドリソースのメトリクス New Relic Infrastructure Agent New Relic Infrastructure Integration でNew Relicに送信
  10. Mobility Technologies Co., Ltd. 11 これらはKubernetesクラスタやクラウド側で予めセット アップしておくもの メトリクスの収集 newrelic-istio-adapter New

    Relic Infrastructure Agent New Relic Infrastructure Integration つまりマイクロサービス単位での個別設定なしで必要なメト リクスを自動的に収集できる
  11. Mobility Technologies Co., Ltd. 12 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪

    メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
  12. Mobility Technologies Co., Ltd. 13 ▪ 必要なメトリクスが集まったため後はNRQLで好きなようにダッシュボード化、アラート 設定ができる メトリクスの利用 Traffic,

    Errors, Latency アプリケーションのメトリクス Saturation Podのメトリクス Saturation クラウドリソースのメトリクス
  13. Mobility Technologies Co., Ltd. 15 ▪ ダッシュボードはmodule化し、クラウドリソースのパネル のみオプションで表示を制御 ▪ アラートは以下の単位でmoduleを作成

    ▪ アプリケーションアラート ▪ クラウドリソースアラート ▪ RDS ▪ SQS ▪ DynamoDB ▪ etc ▪ マイクロサービス毎に必要なアラートを組み合わせて設 定 Terraformによる自動化 固定 オプションで必要 なリソースのみ表 示 固定
  14. 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のインフラリソース