猛暑/残暑に負けるな！OpenShift.Run Summer #10 SUDA Kazuki (@superbrothers), Preferred Networks, Inc. Kubernetes で実践する クラウドネイティブ DevOps “監視とオブザーバビリティ” 編

@superbrothers 前回のお話（DevOps / GitOps） 2 スライド: https://speakerdeck.com/superbrothers/cloud-native-devops-with-kubernetes-devops-cloudnative-and-gitops YouTube: https://youtu.be/3_x1CO7XsaE?t=1216

@superbrothers SUDA Kazuki / @superbrothers ▶ Preferred Networks, Inc. (PFN) エンジニア ▶ Kubernetes Meetup Tokyo, Prometheus Meetup Tokyo ほか、共同主催者 ▶ CNCF Ambassador ▶ 「Kubernetes実践⼊⾨」、「みんなのDocker/Kubernetes」共著書 ▶ 「⼊⾨ Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書 3

https://www.oreilly.co.jp/books/9784873119014/ “ Kubernetesが標準プラットフォームである クラウドネイティブの世界でアプリケーションを開発 し運⽤する⽅法を解説する書籍です。Kubernetesの 基本から、継続的デプロイ、機密情報管理、 オブザーバビリティなどの⾼度なトピックを扱う本書 は、サーバ、アプリケーション、サービスを管理する IT運⽤者、クラウドネイティブサービスの構築や 移⾏を⾏う開発者必携の⼀冊です。

@superbrothers PFN における Kubernetes の利⽤ 5 多種多様な研究 多種多様なデータ ⼤勢の研究者 ⾃社開発の技術 オンプレの GPU クラスタ ⼤量の機械学習ジョブ Icon pack by Icons8 - https://icons8.com

@superbrothers PFN の Kubernetes クラスタ 6 Tesla P100 PCIe x 8 10GbE x 2 InfiniBand FDR x 2 MN-1a サーバ トータル 1024 GPUs 19.1 PFLOPS 2017年 Tesla V100 PCIe x 8 10GbE x 2 InfiniBand EDR x 2 MN-1b サーバ トータル 1536 GPUs 53.3 PFLOPS 2018年 Tesla P100 SXM2 x 8 100GbE x 2 RoCEv2 with SR-IOV MN-2a サーバ トータル 1024 GPUs 128 PFLOPS 2019年 MN-Core x 4 100GbE x 2 MN-3a サーバ MN-Core DirectConnect トータル 192 MN-Cores 4.7 PFLOPS (21.11 GFLOPS/W) 2020年 Icon pack by Icons8 - https://icons8.com MN-1 Series MN-2 Series MN-3 Series NVIDIA GPUなどの最新技術を採⽤した プライベート・スーパーコンピュータ MN-2 を⾃社構築し、7⽉に稼働 Preferred Networksの深層学習⽤スーパーコンピュータMN-3がスーパーコンピュータ省電⼒性能ランキングGreen500で世界1位を獲得 世界⼀位!!

@superbrothers アジェンダ 1. 監視とオブザーバビリティ 2. Kubernetes におけるメトリクス 3. そのほか、PFN での取り組み 4. まとめ 7

@superbrothers 監視とオブザーバビリティ

@superbrothers 監視（モニタリング）とは何か アプリケーションやツール、データベース、ネットワーク等の問題を知り、 それに対処するための情報を得て、問題に対処すること。 ▶ アラートと問題の特定 + システムの状態が悪くなっていることを知り、問題への対処を始める ▶ デバッグ情報の提供 + 問題に対処するために必要な情報の提供 ▶ トレンド調査 + 現時点では問題ではないが時間の経過とともにどのように変化していくかを知る ▶ 他のシステムへの情報提供 + オートスケーリングなど、⾃動化のために必要な情報を提供する 9

@superbrothers ブラックボックス監視の限界 外部からの「アップ（up）かどうか」という問いかけに対してイエス∕ノーで答えるだけ。 ▶ 予測可能な障害しか検出できない（例えばウェブサイトが応答しないなど ▶ システムの外部に露出する部分の挙動しかチェックできない ▶ 受動的かつ事後対応で、問題が発⽣した後でしか通知できない ▶ 「何が壊れているか」という疑問には答えられるが、 もっと重要な「なぜ壊れているのか」という疑問には答えられない 「なぜか」に答えるためには、ブラックボックス監視を超えた⼿法へ移⾏する必要。 10

@superbrothers クラウドネイティブアプリケーションは常にどこかが壊れている 分散システムは、完全な意味で「アップ（up）」になることはない。* ▶ サービスが部分的に劣化しているのが定常的な状態であり、それを前提に稼働する + ブラックボックス監視のような単⼀の視点や観測からでは検出が難しい ▶ そもそも「アップ」を厳密に定義することは難しい + 名⽬上はアップの状態にあったとしても、 提供するサービスがユーザにとって機能していなければ、サービスはダウンしている ブラックボックス監視は出発点としては意義があるが、そこでよしとすべきではないと認識する。 11 * Ops: It's everyone's job now | Opensource.com

@superbrothers ロギング、トレーシング、メトリクス 12 ロギング Events トレーシング Request scoped メトリクス Aggregatable Low volume High volume http://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

@superbrothers 198.186.192.44 - - [27/May/2010:01:56:54 +0100] "GET / HTTP/1.1" 403 327 "-" "-" 208.80.193.29 - - [27/May/2010:03:08:17 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts; SIMBAR=0; .NET 66.249.68.210 - - [27/May/2010:03:46:25 +0100] "GET /robots.txt HTTP/1.1" 403 269 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html 66.249.68.210 - - [27/May/2010:03:46:25 +0100] "GET / HTTP/1.1" 403 263 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 198.186.192.44 - - [28/May/2010:02:04:30 +0100] "GET / HTTP/1.1" 403 327 "-" "-" 184.73.2.36 - - [28/May/2010:05:14:00 +0100] "GET /robots.txt HTTP/1.0" 403 272 "-" "SheenBot/SheenBot-1.0.4 (Sheen web crawler)" 184.73.2.36 - - [28/May/2010:05:14:00 +0100] "GET / HTTP/1.0" 403 267 "-" "SheenBot/SheenBot-1.0.4 (Sheen web crawler)" 208.80.193.42 - - [28/May/2010:12:56:12 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 7.0; AOL 9.0; Windows NT 5.1; FunWebProducts; InfoP 208.80.193.43 - - [29/May/2010:21:54:59 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; SIMBAR={ED852896-9625-4d9 188.140.124.209 - - [29/May/2010:23:04:22 +0100] "GET / HTTP/1.1" 403 263 "http://www.google.pt/url? sa=t&source=web&ct=res&cd=2&ved=0CBkQFjAB&url=http%3A%2F%2Ftransmsilverio.com%2F&rct=j&q=transportes+manuel+silverio&ei=YY8BTNzMMZKL4AbUpNTLDg&usg=AFQjCNGYg9T SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; InfoPath.2)" 188.140.124.209 - - [29/May/2010:23:04:36 +0100] "GET / HTTP/1.1" 403 263 "http://www.google.pt/url? sa=t&source=web&ct=res&cd=2&ved=0CBkQFjAB&url=http%3A%2F%2Ftransmsilverio.com%2F&rct=j&q=transportes+manuel+silverio&ei=YY8BTNzMMZKL4AbUpNTLDg&usg=AFQjCNGYg9T SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; InfoPath.2)" 188.140.124.209 - - [29/May/2010:23:05:56 +0100] "GET / HTTP/1.1" 403 263 "http://www.google.pt/url? sa=t&source=web&ct=res&cd=1&ved=0CBUQFjAA&url=http%3A%2F%2Ftransmsilverio.com%2F&rct=j&q=www.transmsilverio.com&ei=vI8BTKe6M4SV4gbjruzLDg&usg=AFQjCNGYg9TdafIh CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; InfoPath.2)" 208.80.193.30 - - [31/May/2010:05:56:02 +0100] "GET / HTTP/1.0" 403 323 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; YPC 3.2.0; FunWebProducts 207.44.204.87 - - [31/May/2010:14:35:45 +0100] "GET /wp-login.php HTTP/1.1" 403 274 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.ht 207.44.204.87 - - [31/May/2010:14:35:46 +0100] "GET /old/wp-login.php HTTP/1.1" 403 276 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bo 207.44.204.87 - - [31/May/2010:14:35:46 +0100] "GET /cms/wp-login.php HTTP/1.1" 403 276 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bo 207.44.204.87 - - [31/May/2010:14:35:47 +0100] "GET /blog/wp-login.php HTTP/1.1" 403 278 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/b 207.44.204.87 - - [31/May/2010:14:35:47 +0100] "GET /blog_old/wp-login.php HTTP/1.1" 403 282 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.c 207.44.204.87 - - [31/May/2010:14:35:48 +0100] "GET /blog-old/wp-login.php HTTP/1.1" 403 281 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.c https://gist.github.com/pmcconnell-tc/9c3d57818d55ba7203d4e56f7142a43f ロギング（Logging） ▶ イベントを対象として、イベント1つひとつのコンテキストの⼀部を記録する ▶ 例えば、HTTP リクエストをイベントとして、リクエスト時間、HTTP メソッド、パス、 リクエスト元 IP などのコンテキストをエントリとして記録する（アクセスログ + そのほかに、トランザクションログやデバッグログなど ▶ サンプリングしないので、記録できるコンテキストに⼤きな制限がなく、特定のイベントに どのような問題があるのかを正確に特定できる ⼀⽅で、何を記録し、何を記録しないかは開発者が判断するため、ブラックボックス監視と同じく 検出できる問題は事前に予測しうるものに限定される。さらに、⼤量のストレージと帯域が必要で スケールが困難。 13

@superbrothers ▶ ログフォワーダのツール + fluentd, fluent-bit + Logstash ▶ ログデータの管理、分析 + ツール + Elastic + Grafana Loki + サービス + Google Cloud Logging + Amazon CloudWatch Logs + Azure Monitor ロギングのツールとサービス 14 Observability and Analysis - Logging / CNCF Cloud Native Interactive Landscape

@superbrothers PFN でのロギング ▶ 転送しているログ + Kubernetes システムコンポーネント + Kubernetes Events + github.com/opsgenie/kubernetes-event-exporter 15 Google Cloud Logging イベントをログに落とす以外に、特定のイベントを
 Slack で通知といったこともできてべんりなんだけど、 イベントログが作成されなくなるバグがあるようなので注意 (v0.9)

@superbrothers トレーシング（Tracing） ▶ 1つのリクエストといった区切られたスコープのなかで関数呼び出しなどの 複数のイベントを記録し、ボトルネックがどこにあるのかを明らかにする + スタックトレース + プロセスをまたぐと分散トレーシングと呼ばれる ▶ サンプリングによってデータ量を⼀定に保ちつつ、 パフォーマンスに及ぼす影響を合理的な範囲に留める 16 12.94ms 11.95ms 6.91ms 6.71ms 1.27ms 0.04ms

@superbrothers ▶ ツール + Elastic APM + Jaeger + Zipkin + Lightstep ▶ サービス + Google Cloud Trace + AWS X-Ray + Azure Application Insights トレーシングのツールとサービス 17 Observability and Analysis - Tracing / CNCF Cloud Native Interactive Landscape

@superbrothers メトリクス（Metrics） ▶ 何かの状態を測定した数値で、集計した結果から経時的にどのように変化しているかを明らかにする + アプリケーション: HTTP リクエスト数やリクエストの処理にかかった時間 + インフラ: プロセスやコンテナの CPU 使⽤率、ディスク I/O、ネットワークトラフィック ▶ できる限りのコンテキストを無視することで、データ量と処理を合理的な範囲に維持する 18

@superbrothers メトリクスは「動作している/していない」という単純な判断を超えて 監視の新たな次元を切り開く ▶ メトリクスは「なぜか」をあきらかにする + ⾃動⾞のスピードメータや⽬盛りが刻まれた温度計と同様に、メトリクスは現在の状況に 関する数値情報を与えてくれる + グラフの作成、統計処理、閾値に基づくアラートなどが簡単に処理できる ▶ メトリクスは「問題の予測」に役⽴つ + 運⽤者やユーザが問題に気付く前に、何らかのメトリック値が上昇してトラブルが 近づいている状況を⽰唆することがある ▶ メトリクスはアプリケーションを「内部から」監視する + 運⽤者がアプリケーションやサービスの内部実装を推測するのではなく、 システムの実際の動作（および障害）に関する情報に基づいて問題に取り組める 19

@superbrothers ▶ ツール + Prometheus ▶ サービス + Google Cloud Monitoring + Amazon Cloud Monitoring + Azure Monitor + Datadog + New Relic + Sysdig Monitor メトリクスのツールとサービス 20 Observability and Analysis - Monitoring / CNCF Cloud Native Interactive Landscape どのサービスも Prometheus との連携機能がある！

@superbrothers ▶ https://github.com/prometheus/prometheus (Apache 2.0) ▶ クラウドネイティブの世界で事実上の標準となっているメトリクス管理ソリューション ▶ オープンソースのメトリクスベースモニタリングシステム + プル型で単純なテキストのメトリクス形式 + 柔軟なクエリ⾔語 + サービスディスカバリ機構との連携で動的な環境のモニタリングが得意 + ダッシュボードとアラート通知 ▶ 2016年に Cloud Native Computing Foundation の2番⽬のプロジェクトのメンバになる + 2018年8⽉に “卒業” (Graduated) プロジェクトとなる Prometheus（プロメテウス） 21

@superbrothers PFN でのメトリクス 22 ▶ Prometheus Operator と⻑期記憶ストレージとして VictoriaMetrics を利⽤ Prometheus とその関連コンポーネントの管理を Kubernetes でいい感じにやってくれるべんりなヤツです！

@superbrothers 23 3ZPUB"SBJ 1SFGFSSFE/FUXPSLT 1SPNFUIFVT5PLZP.FFUVQ 1SPNFUIFVTBU1'/ スライド: https://speakerdeck.com/superbrothers/introduction-to-prometheus YouTube: https://youtu.be/avj1QbWpf6M?t=1291 スライド: https://www.slideshare.net/pfi/prometheus-at-preferred-networks YouTube: https://youtu.be/avj1QbWpf6M?t=4829 2019年6月時点の情報で
 現在と異なっている部分があることに注意！

@superbrothers https://www.oreilly.co.jp/books/9784873118772/ Prometheus ユーザ必読！

@superbrothers オブザーバビリティとは何か 可観測性、システムを運⽤する上で必要な内部状態の情報を取得できる状態にあること。 ▶ システムのオブザーバビリティといえば、「測定のしやすさがどれほど担保されているか」 および「内部で何が起こっているかをどれほど容易に判断できるか」を⽰す尺 ▶ オブザーバビリティは、システムの理解を促進する + システムの改善が意図したとおりに機能するかどうかの判断材料を提⽰できる + 「推測するな計測しろ」 これまでの監視が「システムが正しく機能しているかどうか」を⽰すのに対して、 オブザーバビリティが確保された監視は「システムがどうして正しく機能しないのか」を⽰す。 25 オブザーバビリティはまだ新しい概念で、監視の上位集合だという人もいれば、
 従来の監視とは全く異なる考え方を反映しているという人もいます。

@superbrothers オブザーバビリティを重視する⽂化の醸成 開発（Dev）と運⽤（Ops）の連携を通じて、サービスを測定できるようにしてオブザーバビリティ を実現し、事実とフィードバックに基づくエンジニアリングのチーム⽂化へと移⾏。 26 開発（Dev） 運⽤（Ops）

@superbrothers Kubernetes で活⽤すべきブラックボックス監視 Liveness（ライブネス）と Readiness（レディネス）の2つのプローブ。 ▶ Liveness プローブ: ⾃分が健全（healthy）であるかどうか + 失敗するとコンテナが再起動される ▶ Readiness プローブ: ⾃分は問題ないが機能を提供できるかどうか + 失敗すると Service から切り離される、サーキットブレーカ 「クラウドネイティブアプリケーションは常にどこかが壊れている」 ▶ サービスの優雅な劣化 + ⼀部のコンポーネントで障害になった場合にもシステム全体の障害になることを回避する 27

@superbrothers Kubernetes におけるメトリクス

@superbrothers Kubernetes におけるメトリクス ▶ クラスタの健全性に関するメトリクス + ノードの健全性ステータスやノードあたり、および全体のリソース使⽤率∕割り当てなど ▶ Deployment などのオブジェクトに関するメトリクス + Deployment ごとのレプリカの設定数、利⽤できないレプリカの数など ▶ コンテナに関するメトリクス + ノードあたり、および全体のコンテナ/Podの数、リソース要求/制限に対する各コンテナの リソース使⽤、コンテナのLiveness/Readinessの状況など ▶ アプリケーションに関するメトリクス + 受信したリクエストの数、返されたエラーの数、持続期間など ▶ ランタイムに関するメトリクス + プロセス、スレッドの数、ヒープとスタックの使⽤率、ガベージコレクション機能の 実⾏時間と待機時間など 29

@superbrothers Kubernetes のメトリクスを取得する ▶ Kubelet （cAdvisor） + コンテナのリソース使⽤率と性能に関する情報 ▶ github.com/kubernetes/kube-state-metrics + Kubernetes API にクエリして、ノード、Pod、Deployment などのオブジェクトに関する情報 ▶ github.com/prometheus/node_exporter + OS カーネルが開⽰する CPU、メモリ、ディスクスペース、ディスク I/O、ネットワーク帯域 幅、マザーボードの温度などのマシンレベルの情報 30

@superbrothers 優れたメトリクスを選択する ▶ サービス: 「RED」パターン + Requests（リクエスト数）、 Errors（エラー）、Duration（持続期間） + 総数は増え続けるだけなので、例えば1秒当たりのリクエスト数（rate）に注⽬する ▶ リソース: 「USE」パターン + Utlisation（利⽤状況/使⽤率）、Saturation（飽和）、Errors（エラー） + Utilization はサービスがどの程度稼働しているか、Saturation はキューで処理待ちに なっている仕事の量 ▶ ビジネスメトリクス + サインアップしたもののキャンセルした割合（解約率）など 31 Prometheus は完全なデータ提供よりも 99.9% 正しいデータ提供と 機能継続を選択している。現⾦や請求書の処理などの完全なデータが 必要な場合は、ロギングなどの他の⽅法を選択しなければならない。 Google SRE handbook では、Saturation（飽和）を 追加した4つのメトリクスをゴールデンシグナルと呼んでいます

@superbrothers 単純な平均の問題点 単純平均（mean）は、外れ値の影響を受けやすく、1つか2つの極端な値があるだけで 平均値が⼤きく違ってしまう。 32 アンスコムの例 - Wikipedia 4つのデータセットは全く異なるグラフですが、
 単純平均の値はすべて同じになるのです

@superbrothers 最悪を知る あるサーバのレイテンシの中央値が1秒であることが分かったとしても、10秒以上のレイテンシを 経験しているユーザにとっては何の意味もない。 ▶ パーセンタイル（百分位数） + 99パーセンタイル（P99）は、ユーザの 99% が経験しているより⼤きな値であることを⽰す + P99 の値より⾼いレイテンシを経験しているのはユーザの 1% とも⾔える 33 ⽣データ 10秒間隔での単純平均 99パーセンタイル https://igor.io/latency/ P50 は中央値です！

@superbrothers メトリクスのダッシュボードによるグラフ化 メトリクスを⽤いて実際には何をするのかといえば、メトリクスをグラフ化し、それらを ダッシュボードにグループ化して、場合によってはメトリクスに基づいてアラートを通知する。 ▶ サービスには「RED パターン」、リソースには「USE パターン」をしっかり活⽤する ▶ クラスタからノード、Pod、コンテナというように、より広い範囲から狭い範囲に 絞り込んで調査できるようにする 34 The RED Method: key metrics for microservices architecture すべてのサービスに標準のレイアウトを
 用意するのがオススメ！

@superbrothers メトリクスに基づくアラート ⼤規模な分散システムはほとんど常にサービスが部分的に劣化した状態にある。そのため、あるメ トリクスが通常の制限範囲から外れるたびにアラートを出していたのでは、1⽇に何百回も オンコールされることになってしまう。 ▶ オンコールを地獄にしない + 緊急かつ重要で「対処可能な」アラートのみに限定する + オンコール対象とならない他のすべてのアラートは、⾮同期の通知を送信すれば⼗分 + メール、Slack メッセージ、GitHub イシューほか ▶ 間違ったアラートの排除 + システムに対する信頼性を低下させて、無視しても問題ないと⼈間を油断させてしまう 35 SN 比（信号対雑音比）が高い状態を維持しよう！

@superbrothers そのほか、PFN での取り組み

@superbrothers アラートから GitHub イシューを作成 https://github.com/pfnet-research/alertmanager-to-github ▶ Alertmanager からの Webhook を受け取って GitHub イシューを作成する + 新しいアラートから GitHub イシューを作成 + アラートが resolved ステータスになるとイシューをクローズ + アラートが再度 firing ステータスになるとイシューをリオープン 37

@superbrothers ノードの Conditions の変化によりオペレーションを実⾏ https://github.com/pfnet-research/node-operation-controller ▶ ノードのConditionsを監視し、条件を満たすとそのノードのメンテナンス処理を 実⾏するPodを作成するコントローラ ▶ Conditions の変更には、 node-problem-detector やそれと連携する内製のツールを使⽤ 38 アラート/サポートイシューのアサインをバランスよく⾏う ▶ 内製の task-assigner ツールを開発（クローズド） ▶ /assign コメントによるアサインもサポート オンプレでべんりです！

@superbrothers まとめ

@superbrothers まとめ ▶ これまでのブラックボックス監視が「システムが正しく機能しているかどうか」を⽰すのに対し、 オブザーバビリティが確保された監視は「システムがどうして正しく機能しないのか」を⽰す ▶ クラウドネイティブな世界で重要な役割を果たすのが「メトリクス」 ▶ メトリクス監視では、「Prometheus」がクラウドネイティブの世界で事実上の標準となっている ▶ オブザーバビリティに取り組むことは、事実とフィードバックに基づくチーム⽂化へと移⾏ ▶ 重要なメトリクスに集中する。サービスの場合はリクエスト、エラー、持続期間（RED）、 リソースの場合は利⽤状況、飽和、エラー（USE） ▶ 単純な平均よりも最悪に注⽬する。それにはパーセンタイル（百分位数）を使⽤する。 ▶ オンコールを地獄にしない、緊急かつ重要で「対処可能な」アラートのみに限定する 40

@superbrothers Thanks / Question? ▶ SUDA Kazuki, @superbrothers ▶ Slide: https://speakerdeck.com/superbrothers/ 41