Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
マイクロサービス環境における監視の効率化
Yusuke Mito
September 15, 2021
Programming
0
490
マイクロサービス環境における監視の効率化
2021/09/15 NRUG : New Relic User Group
Nerd Life Talk
Yusuke Mito
September 15, 2021
Tweet
Share
More Decks by Yusuke Mito
See All by Yusuke Mito
GraphQL Q&A
y310
7
2.9k
Ruby on Rails Introduction
y310
0
170
WWDC2014 これだけ押さえておけば間違いなし! おすすめセッションTOP10
y310
11
5.2k
NSUserDefaultsの中身を見る
y310
0
2k
xctoolで爆速テスト
y310
2
1.5k
Kibana入門
y310
63
49k
Other Decks in Programming
See All in Programming
LINE Messaging APIの概要 - LINE API総復習シリーズ
uezo
1
160
io22 extended What's new in app performance
veronikapj
0
340
設計ナイト2022 トランザクションスクリプト
shinpeim
11
2k
エンジニアによる事業指標計測のススメ
doyaaaaaken
1
180
The strategies behind ddd – AdeoDevSummit 2022
lilobase
PRO
4
240
ISUCON12 事前講習
rosylilly
3
4.3k
NEWT.net: Frontend Technology Selection
xpromx
0
230
Jetpack Compose best practices 動画紹介 @GoogleI/O LT会
takakitojo
0
300
Beyond Micro Frontends: Frontend Moduliths for the Enterprise @enterjs2022
manfredsteyer
PRO
0
140
Maintaining Software Correctness
dlew
PRO
3
250
Chart実装が楽になりました。
keisukeyamagishi
0
110
ES2022の新機能
smt7174
0
230
Featured
See All Featured
WebSockets: Embracing the real-time Web
robhawkes
57
5.2k
Designing the Hi-DPI Web
ddemaree
272
32k
Done Done
chrislema
174
14k
Why You Should Never Use an ORM
jnunemaker
PRO
47
7.6k
Code Reviewing Like a Champion
maltzj
506
37k
Product Roadmaps are Hard
iamctodd
34
6.5k
Designing for humans not robots
tammielis
241
23k
Principles of Awesome APIs and How to Build Them.
keavy
113
15k
Reflections from 52 weeks, 52 projects
jeffersonlam
337
17k
Git: the NoSQL Database
bkeepers
PRO
415
59k
Fashionably flexible responsive web design (full day workshop)
malarkey
396
62k
Side Projects
sachag
450
37k
Transcript
Mobility Technologies Co., Ltd. マイクロサービス環境における監視の効率化 株式会社Mobility Technologies 技術戦略部SREグループ 水戸祐介
Mobility Technologies Co., Ltd. 2 水戸 祐介 Twitter: @y_310 株式会社Mobility
Technologies (通称MoT) SREグループ タクシーアプリ「GO」を作っている会社です。 自己紹介
Mobility Technologies Co., Ltd. 3 ▪ AWSを中心にGCPも使用 ▪ Kubernetesベースの共通基盤をEKS、GKEの上で動かし社内に提供 ▪
ネームスペース20以上、デプロイメント80以上、Pod数600以上 ▪ マイクロサービスアーキテクチャを取っていることで比較的小規模なサービスが大量 にあり、毎月のように新たなサービスが増えている状況 以上の環境をSREグループ4名で運用 MoTのインフラ環境
Mobility Technologies Co., Ltd. 4 ▪ 毎月のように増えるサービスに対して個別対応していると早々にコントロール不能に なる ▪ 不十分な監視体制のままリリースされる
▪ 同じような構成のサービスなのに監視項目に差異が生じる ▪ 他サービスの知見が生かされない マイクロサービスにおける監視の課題 効率化しなければ破綻する 一貫した監視のポリシーを設 計し自動化する
Mobility Technologies Co., Ltd. 5 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪
メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
Mobility Technologies Co., Ltd. 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
Mobility Technologies Co., Ltd. 8 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪
メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
Mobility Technologies Co., Ltd. 9 メトリクスの収集 Latency レスポンスタイム Traffic RPS
Errors エラー数 アプリケーションのメトリクス MoT環境ではService MeshとしてIstioを導入しておりIstio経 由でサービス間通信のメトリクスを取得できる newrelic-istio-adapterでNew Relicに送信
Mobility Technologies Co., Ltd. 10 メトリクスの収集 Saturation CPU/Memory/etc インフラのメトリクス KubernetesのワーカーノードやAWS
RDS、SQS などのクラウドリソースのメトリクス New Relic Infrastructure Agent New Relic Infrastructure Integration でNew Relicに送信
Mobility Technologies Co., Ltd. 11 これらはKubernetesクラスタやクラウド側で予めセット アップしておくもの メトリクスの収集 newrelic-istio-adapter New
Relic Infrastructure Agent New Relic Infrastructure Integration つまりマイクロサービス単位での個別設定なしで必要なメト リクスを自動的に収集できる
Mobility Technologies Co., Ltd. 12 ▪ メトリクスの設計 ▪ メトリクスの収集 ▪
メトリクスの利用 ▪ 可視化 ▪ アラート設定 監視のタスク分解
Mobility Technologies Co., Ltd. 13 ▪ 必要なメトリクスが集まったため後はNRQLで好きなようにダッシュボード化、アラート 設定ができる メトリクスの利用 Traffic,
Errors, Latency アプリケーションのメトリクス Saturation Podのメトリクス Saturation クラウドリソースのメトリクス
Mobility Technologies Co., Ltd. 14 ▪ マイクロサービスを作る度にこれらのダッシュボードやアラートを作成するのは手間 が大きすぎるためTerraformで自動化する メトリクスの利用
Mobility Technologies Co., Ltd. 15 ▪ ダッシュボードはmodule化し、クラウドリソースのパネル のみオプションで表示を制御 ▪ アラートは以下の単位でmoduleを作成
▪ アプリケーションアラート ▪ クラウドリソースアラート ▪ RDS ▪ SQS ▪ DynamoDB ▪ etc ▪ マイクロサービス毎に必要なアラートを組み合わせて設 定 Terraformによる自動化 固定 オプションで必要 なリソースのみ表 示 固定
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のインフラリソース
Mobility Technologies Co., Ltd. 17 Terraformによる自動化 モジュールを読み込んでサービスに合った閾値を設定するだけ で必要なダッシュボードとアラートが作成される 共通ダッシュボードモジュール 共通アプリケーションアラートモジュール
共通クラウドリソースアラートモジュール
Mobility Technologies Co., Ltd. 18 ▪ マイクロサービス環境では新規サービスの立ち上げが頻繁に発生するため自動化 が不可避 ▪ 汎用的なメトリクス設計を元にメトリクスの収集から利用まで自動化することで効率
的な運用が可能になる ▪ New RelicはNRQLの柔軟性と性能によってマイクロサービスの監視を楽にしてくれる まとめ
文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Mobility Technologies Co., Ltd. 19