Cloud Nativeなテクノロジーに おけるObservability(可観測性)とは？ 0 2019/11/26 プラットフォームサービス本部 クラウド基盤ソリューション部 ソリューションアーキテクトチーム 秋葉

もくじ 1 • Observability(可観測性)の概要 • Observability(可観測性)の3本柱  Metrics  Logs  Traces • さいごに

2 • Observability(可観測性)の概要 • Observability(可観測性)の3本柱  Metrics  Logs  Traces • さいごに

Observabilityとは？ 3 参考) https://www.elastic.co/jp/blog/observability-with-the-elastic-stack https://vm-event.jp/cnday/program/CD171/  起源 • 1960年位から機械制御理論の中で使われていた用語 • シリコンバレーの巨大企業からSRE界隈で流行(諸説あり) • Google SRE Bookで「Observability」に関連する原理の多くを提示 SRE・・「Site Reliability Engineer」。信頼性こそがあらゆるプロダクトの基本的な機能として位置づけ、SREはシステムのスケーラビリティ、信頼性 、効率性を向上させるために、その設計と運用の改善方法を見つけることに集中し、 システムが「十分な信頼性を持った」ら、機能の追加や 新プロダクトの構築のために力を注ぐ役割を担う  目標 • システムを運用する上で、未知の動作を含め、不具合の根本原因を特定・判断する 為に必要な情報(イベントログ、リソース使用状況、アプリケーションのトレースなど)が取 得出来ている状態 Cloud Nativeなアプリケーションへの変化 (アーキテクチャが複雑化、パブリッククラウド サービスの普及、リリースサイクルの加速な ど)によりObservabilityが一層注目

Observabilityで目指すロードマップ 4 参考) https://vm-event.jp/cnday/program/CD171/ 用語の補足)  サービス稼働の保障 • SLI (Service Level Indicator) ・・ システムの安定稼働を示す指標 • SLO(Service Level Objective) ・・ 安定稼働を示す目標値(SLI + 目標値) ※各サービスの正常な状態を各サービス毎で定義。**m/secの目標値など • SLA(Service Level Agreement)・・ 安定稼働の為の規約(SLO + 規約)  データ分析 • MTTD(Mean Time To Diagnosis)・・平均診断時間 • MTTR(Mean Time To Recovery)・・平均復旧時間 今回は、このデータ収集部分について注目

Observabilityの3本柱 5 1. Metrics • CPU/MEM/Diskなどのリソース使用率 • APIリクエスト数、NWトラフィック、キャッシュヒット率、ページロードタイムなど 2. Logs • Syslog(サーバ、コンテナOSなど)、ミドルウェアやアプリケーションのログ • NWパケット、DBクエリ、構成変更、API操作、クラウド監査ログなど 3. Traces • アプリケーション、データベース、外部API、マイクロサービス間の処理や呼び 出しタイムの計測と追跡 参考) https://www.elastic.co/jp/blog/observability-with-the-elastic-stack 参考) https://github.com/warmchang/KubeCon-CloudNativeCon-Europe- 2019/blob/master/keynote-metrics-logs-traces-what-does-the-future-hold-for- observability-tom-wilkie-vp-product-grafana-labs-frederic-branczyk-software- engineer-red-hat.pdf

6 • Observability(可観測性)の概要 • Observability(可観測性)の3本柱  Metrics  Logs  Traces • さいごに

CNCF Landscape ＞ Monitoring( ≒ Metrics) 7  備考 • Prometheus + Grafanaは、CNCF界隈では有名 • Kialiは、サービスメッシュ(Istio/Envoy)の可視化で利用 • sysdigは、セキュリティチェック機能もあるので、セキュリティ領域でも注目 • WAVEFRONTは、VMware Tanzu & Project PacificのUIで利用 • CloudHealthは、AWS WA管理ツールとして検証(検討)中 • INSTANAは、既存顧客で検証(検討)中 • Amazon CloudWatchは、AWS ECS/EKS触っていると、まずは有力候補 ※Amazon CloudWatch Container Insights(2019年9月 GA) この本でNagiosは 否定的(レガシー)な 文脈で書かれている (2019年11月19日時点) (2019年1月発売)

AWS EKSをAmazon CloudWatch Container Insightsでメトリクス取得する際の構成例 8 Namespace:CwAgent Kubernetesクラスタ DaemonSet CloudWatch Agent メトリクス送信 CloudWatch Role IAM Role IAM Role IAM 参考) https://eksworkshop.com/ekscloudwatchcontainerinsights/cwcinstallprep/ • 各ワーカーノードにCloudWatchログへの書き込みIAMロールを付与 • CloudWatchAgentコンテナをdeamonSetで配置 • CloudWatchAgentコンテナがメトリクス収集しCloudWatch Insightへ転送 CloudWatch Agent CloudWatch Agent

AWS EKSをAmazon CloudWatch Container Insightsでメトリクス表示した一例 9 k8sクラスタ単位 ワーカーノード単位 pod単位

Prometheusの特徴を理解する 10  Prometheusについて • メトリックスをKVSで時系列データベースに保存 • NodeExporter(deamonSet)や自らのスクレイピング経由でメトリックス取得 • AlertManagerでアラートを判断/送信。可視化はGrafanaが鉄板  PrometheusのOperatorについて • シングル構成以外にもHA構成を組む事が出来るOperatorの利用を要検討 • Operatorは数種類あるがCoreOSのstar数が多いものが有力か • PrometheusとAlertManagerがCRDとして実装  AlertManager HA構成 • ゴシッププロトコルでat least oneアラート送信実現 • ランダムな相手と情報をやり取りして新しければ自データを更新  Prometheus HA構成 • 同じ対象を二重監視してDBを二重に持つ。可用性の確保の仕方 • それぞれでタイムスタンプが異なるので、クライアントからクエリが来た場合 の為にsession affinity(ClientIP)でスティッキーセッションを実現  長期間のメトリクス保存にはthanosを利用 • 高い可用性で無期限のPrometeusメトリクス保存が出来るCNCF Sandboxプロジェクト • S3やGCSなどにメトリクスを保存し、GrafanaやAlertManagerからのクエリをthanosが 仲介する役割を持つ • 既存Prometheusに対してシームレスに展開可、HA構成のPrometheusデータもマージ、 重複排除おこなう機能あり 例)All Nodes 例)Namespace 例)Pods 買ったこの本をこれから読む (2019年5月発売) +

Prometheus in k8sの構成例 11 Monitoring NodeExporter App Prometheus AlertManager Operator Grafana 可視化クエリ kubestatemetrics コンテナ メトリクス取得 サービスディスカバリ、 クラスタ メトリクス取得 ノード メトリクス取得 K8s クラスタ AWS Cloud 可視化 メトリクス収集・転送 メトリクス管理 アラート判定、通知 監視、管理 サービスディスカバリ

何をMonitoring(≒Metrics)すべきか？ 12  何を監視すべきか？ • システムが正常に働いているかどうか？ • 正常/異常の原因調査の一つとしてリソース使用状況は？ • リソース使用状況以外にイベントは？  何をアラートすべきか？  調査・分析方法や見方は？  k8sならではの監視項目は？ Monitoring Kubernetes with Datadog (https://www.datadoghq.com/ja/blog/monitoring-kubernetes-datadog/) Google SRE Book (https://landing.google.com/sre/sre-book/chapters/monitoring- distributed-systems/#xref_monitoring_golden-signals) この辺をインプットにマイクロサービス(k8s)環境 で何を監視・アラートすべきかを現在整理中 The RED Method: key metrics for microservices architecture (https://www.weave.works/blog/the-red-method-key-metrics-for- microservices-architecture/)

13 • Observability(可観測性)の概要 • Observability(可観測性)の3本柱  Metrics  Logs  Traces • さいごに

マイクロサービス(k8s)におけるロギングアーキテクチャパターンを紹介 14  アーキテクチャパターン 1. ワーカーノードでログローテート 2. 「1」+ ワーカノードのロギングエージェン(deamonSet)でログ収集・転送 3. 「2」+ アプリPodにストリーミングコンテナ(sidecar) 4. アプリPodのロギングエージェント(sidecar)でログ収集・転送 5. アプリコンテナ内のロギングエージェントでログ収集・転送 引用) https://kubernetes.io/docs/concepts/cluster-administration/logging/

1. ワーカーノードでログローテート 15 AWS Cloud アプリコンテナ stdout / stderr hostPathのvlumeMount 経由でログ出力 例：/var/log/app-file.log • ワーカーノード上でログローテートのみ • ワーカーノード障害などによりログローテートデータが消失する可能性あり /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log stdout/stderrで出力していない場合、kubectl logsコマンドで該当ログを確認する事は出来ない。

2. 「1」 + ワーカノードのロギングエージェン(deamonSet)でログ収集・転送 16 AWS Cloud Cloudwatch(ロググループ) ロギングエージェント (deamonSet) アプリコンテナ /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log stdout / stderr hostPathのvlumeMount 経由でログ出力 hostPathのvlumeMount経由でログをキャッチ Fluentd + CloudWatchプラグインで CloudWatchロググループへログ転送 • ワーカーノードにアプリコンテナの複数ログファイルや標準/エラー出力を記録 • ロギングエージェン(deamonSet)でログをキャッチし転送 stdout/stderrで出力していない場合、kubectl logsコマンドで該当ログを確認する事は出来ない 例：/var/log/app-file.log stdout/stderrは、docker runtimeのauto parse jsonされるので後続処理で扱いやすい 例えば、AWS CloudWatchに集約

3. 「2」 + アプリPodにストリーミングコンテナ(sidecar) 17 AWS Cloud Cloudwatch(ロググループ) アプリコンテナ ストリーミングコンテ ナ(sidecar) emtpyDirのvlumeMount 経由でログ出力 ロギングエージェント (deamonSet) ストリーミングコンテナ (sidecar) emptyDirのvlumeMount 経由でログをキャッチ stdout / stderr stdout / stderr hostPathの vlumeMount経由で ログをキャッチ Fluentd + CloudWatchプラグインで CloudWatchロググループへログ転送 • アプリコンテナの複数ログファイルを各ストリーミングコンテナ(sidecar)でキャッチ し標準(エラー)出力 • ロギングエージェン(deamonSet)で各ストリーミングコンテナログをキャッチし転送 /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log emptyDir{} 例えば、AWS CloudWatchに集約 stdout/stderrは、docker runtimeのauto parse jsonされるので後続処理で扱いやすい

4. アプリPodのロギングエージェント(sidecar)でログ収集・転送 18 AWS Cloud Cloudwatch(ロググループ) アプリコンテナ ロギングエージェント(sidecar) emtpyDirのvlumeMount 経由でログ出力 emptyDirのvlumeMount 経由でログをキャッチ Fluentd + CloudWatchプラグインで CloudWatchロググループへログ転送 • アプリコンテナのログファイルをロギングエージェント(sidecar)でキャッチし転送 stdout/stderrで出力していない場合、kubectl logsコマンドで該当ログを確認する事は出来ない emptyDir{} 例えば、AWS CloudWatchに集約

5. アプリコンテナ内のロギングエージェントでログ収集・転送 19 AWS Cloud Cloudwatch(ロググループ) アプリコンテナ + ロギングエージェント Fluentd + CloudWatchプラグインで CloudWatchロググループへログ転送 • アプリコンテナのログファイルを、アプリコンテナ内部に設定したロギングエージェ ントでキャッチし転送 stdout/stderrで出力していない場合、kubectl logsコマンドで該当ログを確認する事は出来ない 例えば、AWS CloudWatchに集約

CNCF Landscape > Logging 20  メモ • 「splunk」、「sumologc」、「fluentd」、「logstash」あたりのメジャーどころは割愛 • 「Elasticsearch ELK Stack」という形でElasticsearch社の有償サポートあり • 「logz.io」は、「ELK + Grafana」構成をフリーとエンプラ版でサービス提供 • 「graylog」は、ダッシュボード機能(フリーとエンプラ有償版あり)を提供。AWSマネージドサービスからログ連携も出来る • 「loom」は、ブロックチェーンに最適化されたプロダクトを提供。ログ収集・転送はfluentd(loomプラグイン入り)を採用している模様 https://support.loomsystems.com/en/articles/2510334-ship-logs-to-sophie-from-kubernetes • 「HUMIO」は、ダッシュボード機能(オンプレとSaaS版あり)を提供 。ログ収集・転送は、ogstash、filebeat、fluentd、netflow、metricbeatなど • 「SCALYR」は、Googleに買収されGoogle Docsの技術に採用。ログ保管期間と容量課金のSaaSを提供。SCALYRエージェントでログ収集・転送 • 「logdna」は、フリーと有償版あり。ログ収集・転送はlogdnaエージェント • 「sematext」は、ELK stackをSaaSで提供。influxDBやelasticsearch API連携可。ログ収集・転送は、logstash、logagent、fluentd、beats、syslog-ngなど • 「LOGGLY」は、ダッシュボードをSaaSで提供。AWSサービスなど複数ログソース連携可。フリー&有償版 CNCF Landscape > Loggingではカテゴライズされていないが、 Monitoringで整理されている製品でもLogging機能あり (2019年11月19日時点)

いくつかのロギングツールを並べて整理 ※AWS EKS脳 21 # 比較項目 ① AWSマネージドサービス (CloudWatchLogs Insights / Elasticsearch) ② Elastic stack(EC2) ③ Elastic Cloud on Kubernetes ④ Grafana/loki on kubernetes ⑤ sumologic 1 ログストリーム (バッファ、再送) AWSサービス仕様に準拠。 Fluentdなどバッファリングも 有効。 Logstash(キュー永続化機能) AWS MSKの選択肢もあり logstash Promtail側でretry処 理(buffeは見つから ない) fluentdなどの バッファ機能。 S3経由。 2 ログデータ保護 (バックアップ) EC2(EBS)の定期バックアップ。Or AWS EFSにデータ保管(バックアップ機能含 む) k8sステートフルセット。PVC Backupは AppsCodeのStashなど(未検証)。 SaaS仕様に準 拠 3 スケーリング (パフォーマンス) Elasticsearch Cluster Podスケールアップ 位？(情報見つから ず) 4 ログサーバ可用性 (耐障害性) マルチAZで冗長化 シングル構成時はオートリカバリなど k8sオートヒーリングレベル 5 ログデータ暗号化 (セキュリティ) AWS EBS or EFS暗号化オプション。 Elasticsearch 暗号化/認証機能 Elasticsearch 暗号化/ 認証機能 secureJsonData(v6.2 +) 6 提供元コスト (k8s VMは除く) AWSマネージドサービス利用 料 EC2利用料、elastic stackツール(filebeat、 logstash、kibanaなど)はOSS Elasticツール自体は OSS Grafanaツール自体は OSS SaaS利用料 7 オンプレ/マルチ クラウドの考慮 別サービスを要検討 仮想サーバで汎用性あり k8sレイヤで汎用性あり SaaS継続利用 8 アラート、通知 CloudWatchlogMetricfilter + SNS X-Pack > Watcher(OSS after v6.3+) ElastAlert(OSS) Grafana > Alert Sumologic > alert 9 検索、可視性 CloudWatchInsight独自クエリ、 画面。or Elasticsearch + kibana(Query DSL) Elasticsearch + kibana(Query DSL) Elasticsearch + kibana(Query DSL) Prometheus queryと 同様(独自Query) 独自Query+画 面 10 その他 EKSとの親和性 弊社内で事例あり。Elastic Stackサポー トサブスクモデルあり。 Alpha Beta 有償SaaS • ログアーキテクチャ(sidecar or deamonSet)、ログエージェント(収集/転送ツール)は、どの製品でもや り口はほぼ同じ。ログ集約・分析側に着目し非機能項目を中心に比較項目を抽出 (2019年9月時点)

①AWSマネージドサービスの利用例 22 AWS Cloud fluentdコンテナ(daemonSet) アプリコンテナ /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log • 収集/転送 ：fuluentd ※fluent-bitでも可 • 集計/保存 : AWS CloudWatchロググループ ※Lambda経由でElasticsearch連携 • 検索/可視化：AWS CloudWatch Logs Insights、または、AWS Elasticsearch(kibana) k8sクラスタ + ワーカー ノード関連ログ emptyDir{} fluentdコンテナ(sidecar) アプリログ (/var/log/msgpub/*log) CloudWatch(ロググループ) or CloudWatch Logs Insights Stream to AWS ES(lambda) Elasticsearch (kibana) 参考) AWSマネージドサービス利用例だと、Kinesis Data Firehose + S3 + Athena 構成案もある(https://aws.amazon.com/jp/blogs/news/centralized- container-logging-fluent-bit/) この連携はeksworkshopが参考になる (https://eksworkshop.com/logging/) 今後の機能強化に期待 (2018年11月末リリース)

②Elastic Stack(EC2)の利用例 23 AWS Cloud filebeatコンテナ(daemonSet) アプリコンテナ /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log • 収集/転送 ：filebeat(beatsファミリー) • 集計/加工 ：logstash • 保存/検索 ：Elasticsearch • 可視化 ：Kibana k8sクラスタ + ワーカー ノード関連ログ emptyDir{} filebeatコンテナ(sidecar) アプリログ (/var/log/msgpub/*log) EC2(logstash + elasticsearch + kibana) Beatsファミリー(auditbeat、metricbeatなど)、APMとセット利用 すると、 observability(metrics/logs/tracies)の統合が期待 参考) elastic-stack (https://www.elastic.co/guide/en/elastic-stack/current/index.html)

③Elastic Cloud on Kubernetesの利用例 24 AWS Cloud filebeatコンテナ(daemonSet) アプリコンテナ /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log • 収集/転送：filebeat(beatsファミリー) • 保存/検索：elasticsearch • 可視化 ：kibana k8sクラスタ + ワーカー ノード関連ログ emptyDir{} filebeatコンテナ(sidecar) アプリログ(/var/log/msgpub/*log) https://**:9200 CLB (追加) elastic-operator kinaba elasticsearch • elastic-operatorやhelm chartで導入可能 • Beatsファミリー(auditbeat、metricbeatなど)、APMとセット利用す ると、observability(metrics/logs/tracies)の統合が期待 参考) elastic-operator/elasticsearch cluster/ kibana (https://www.elastic.co/guide/en/cloud-on-k8s/0.9/k8s-quickstart.html) ※alpha filebeat (https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html) Elastic Stack Kubernetes Helm Charts もある (https://github.com/elastic/helm-charts) ※beta。metricbeatも試したがkibanaでリソース値が全て0%で正しく表示出来なかった

④grafana/loki on kubernetesの利用例 25 AWS Cloud promtailコンテナ(daemonSet) アプリコンテナ /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log • 収集/転送：Promtail ※lokiへ転送 • 保管/検索：Loki • 可視化 ：Grafana loki ClusterIP CLB k8sクラスタ + ワーカー ノード関連ログ emptyDir{} promtailコンテナ(sidecar) アプリログ(/var/log/msgpub/*log) • grafana/Loki Helm Chartで作成可能 • Tanka(k8sの構成管理ツール)でインストールするのが推奨ならしい • Prometheus + grafanaとの一元管理 参考) grafana/loki (https://github.com/grafana/loki/tree/master/docs) promtail (https://github.com/grafana/loki/blob/master/docs/clients/promtail/installation.md) コミュニティ資料で参考になったLoki仕様 (https://speakerdeck.com/uesyn/lokiru-men?slide=3) + grafana

⑤sumologicの利用例 26 AWS Cloud fluentdコンテナ(daemonSet) アプリコンテナ /var/lib/docker/containers/<コンテ ナID>/<コンテナID>-json.log • 収集/転送 ：fuluentd • 集計/保存/検索/可視化 : sumologic k8sクラスタ + ワーカー ノード関連ログ emptyDir{} fluentdコンテナ(sidecar) アプリログ (/var/log/msgpub/*log) 参考) github (https://github.com/SumoLogic/fluentd-kubernetes-sumologic) / (https://github.com/SumoLogic/sumologic-kubernetes-collection) sumologic setup (https://help.sumologic.jp/07Sumo-Logic-Apps/01Amazon_and_AWS/Amazon_EKS/Collect_Logs_for_Amazon_EKS) ※プレビュー中で一部実機にない helm (https://github.com/SumoLogic/sumologic-kubernetes-collection/tree/master/deploy#installation-with-helm) (https://github.com/SumoLogic/sumologic-kubernetes-collection/blob/master/deploy/docs/Installation_with_Helm.md) ※AWS EKS1.13で試したが、fluent-bitからfluent-collectionへの接続がうまくいかなかった k8s log and metric (https://help.sumologic.com/07Sumo-Logic-Apps/10Containers_and_Orchestration/Kubernetes) • ログ以外にもPrometheus/node_exporterと 利用しメトリクス収集・可視化も可能 • k8s用のSumologic AppCatalogも提供

Pros/Cons ※AWS EKS脳 27 # 利用例 Pros Cons ① AWSマネージド (CloudWatch Logs Insights) • AWS ECS/EKSとの親和性 • AWS管理コンソールで直接クエリ抽出 • ログのフィールド自動検出 • マネージドサービス • 複数ロググループのクロス分析 • 可視化 • AWS環境にロックイン • 今後機能追加に期待 AWSマネージド (Elasticsearch) • AWS CloudWatchと連携(Lambda) ※AWS ECS/EKSとの親和性 • Elasticsearch、Kibanaをマネージドサービスで利用 • AWS環境にロックイン • インデックス、タイプ管理 ② Elastic stack(EC2) • AWS Marketplace(Elasticsearch Service on Elastic CLoud) • Elastic stackはOSS or 有償版を選択可 • Beatsファミリーでobservability統合 • OpenShiftはEFKがベース • Elastic stack環境の運用 • ステートフルなデータ管理 • インデックス、タイプ、シャード管理 ③ Elastic Cloud on Kubernetes • Github(K8s yaml、operator)で公開 • OSS or 有償版を選択可 • OpenShiftはEFKがベース • Beatsファミリーでobservability統合 • Elastic Cloud環境の運用 • ステートフルなデータ管理 • インデックス、タイプ、シャード管理 • Visualization/dashboardテンプレート(良いサ ンプルが見つからない) ④ Grafana/loki on kubernetes • Github(k8s yaml、Helm Chart)で公開 • Prometheus/Grafanaとのobservability統合 • インデックス不要。ラベル管理(inspire by Prometheus) • Grafana Labでダッシュボードテンプレートが提供 • Grafana/loki環境の運用 • ステートフルなデータ管理 • Grafanaのメトリクス画面からログ画面への 遷移が現時点で出来ない(beta版) ⑤ sumologic • Github(k8s yaml、Helm Chart)で公開 • アプリカタログが提供 • SaaS • AWS EKSでHelm Chart v0.9 fluentbitで一部エ ラー(やり方が悪い？) • SaaSインターネット利用前提、SaaS利用料

28 • Observability(可観測性)の概要 • Observability(可観測性)の3本柱  Metrics  Logs  Traces • さいごに

(分散)トレーシングの用途とは？ 29 参考) https://istio.io/docs/tasks/observability/distributed-tracing/ • 複雑なマイクロサービス「小さなサービス(コンテナ)の集まり」間のリクエスト詳細(リクエストパス、ホップ、レ イテンシー、エラー、データフローなど)を記録・可視化する事で、どのサービス間で不具合や性能ボトル ネックが起きているか原因調査・分析 例) Jaeger UIのWeb画面 例) Kiali UIのWeb画面 • マイクロサービス間のリクエスト詳細を可視化 • サービスメッシュ(Istio/Envoy)とセットでマイクロサービ ス間のトラフィックを可視化  Span 各APIリクエストの処理/レスポンスタイム  Trace 該当APIリクエストの伝搬(関係性) ※Aサービス⇒Bサービス⇒Cサービス の呼び出しなど + +

CNCF Landscape ＞ Tracing 30  以下2つ(2019年11月6日 正式終了)がOpenTelemetryプロジェクトに統合 • OPEN TRACING(分散トレーシング仕様をベンダー非依存で標準化) ※ZIPKIN、JAEGERなど • OpenCensus(メトリックス収集、分散トレーシングライブラリ) ※google社内で利用  OpenTelemetryプロジェクトとは？ • メトリクス、トレーシング、コンテキストAPI仕様などの標準化 • Current SIG Progress(https://opentelemetry.io/project-status/) • Loadmap/Milestones(https://medium.com/opentracing/a-roadmap-to-convergence-b074e5815289)  OPEN TRACING互換のTracingツールたち • Tracer ・・ designed after Dapper, not production ready. • LightStep ・・ cloud-based commercial tracing instrumentation platform. • AppDash ・・ based on Zipkin and Dapper. Limited clients availability (Go, Python and Ruby). • Instana ・・ commercial product. Focused on APM and distributed tracing. CNCF Landscape > Tracingではカテゴライズされていないが、 Monitaringで整理されている製品でもトレーシング機能あり ※) Instanaなどと検証した参考資料 ¥¥ogis-ri¥file¥組織横断¥ＰＳ本部公開文書¥ＰＳ本部公開文書¥50.PS本部内報告会（PS計画部主催¥2019年度 ¥20190523¥①Instana技術検証報告 (2019年11月19日時点)

いくつかのTracingツールを並べて整理 # Jaeger OpenZipKin AWS X-Ray (EKS 検証している都合) Datadog 1 起源 Uber(2017年～) Twitter(2012年～) AWS(2017年～) Datadog(2017年～ ※dd- trace-**) 2 トレーシング 方式 クライアントライブラリ クライアントライブラリ X-Ray SDKをimportしコー ディング DataDogのtracing library をimportしコーディング。 Datadog APM Agentで収 集。 3 稼働概要 Single process、 Scalable system Single process(collector、 storage、API、UI) AWSマネージド SaaS 4 クライアントライブラリ 公式サポート言語 C++、C#、Go、Java、Python、Node.js C#、Go、Java、Ruby、 Scala、Node.js C#、Go、Java、Node.js、 Python、Ruby Java、Go、Python、Ruby、 Node.js、.NET、php 5 コレクタ転送方式 UDP、HTTP HTTP、Kafka、Scribe、コミュ ニティサポート(Jaeger、 Skywalkingなど) AWS X-Ray Endpointへ HTTPSで連携 SaaS環境へDataDog Agent経由(https/http)で連 携 6 Spanフォーマット OpenTracing仕様 OpenTracing仕様 Java clientのみ OpenTracingサポート OpenTracing仕様 7 ストレージ、ストア In-memory、Cassandra、Elasticsearch、 コミュニティ開発実績(ScyllaDB、 DynamoDB、InfluxDB In-memory、MySQL、 Cassandra、Elasticsearch AWSマネージド SaaS 8 UI、可視化 有：Jaeger UI(React) 有：UI(NGINX) 有：AWS管理コンソール 有：Datadog管理コンソール 9 デプロイ、クイックスター ト operator、 Helm chart、 k8s template docker run、 docker-compose、 Java program AWS管理コンソール、AWS CLI k8s template(daemonSet)、 Helm、Host、clusterインス トール 10 サービスメッシュ(Istio) のバックエンドサポート 有。追伸：OpenShift Service Mesh(Istio)内でバックエンドコンポーネントで 使用 有 無。追伸：AWS App Mesh はenvoy proxyのみ使用 有。追伸：AWS App Mesh も対応 11 その他 ZIPKINと後方互換あり。 OpenShift Service Meshのバックエンドで使 用。 拡張サポート(Collector： aws sqs、kinesis、 Storage：aws Elasticsearch、X-Rayなど) サポートAWS(Lambda、 APIGW、EB、SNS、SQS) ZIPKIN + Datadog APM 31 • 表には載せていないがElastic APMも分散トレーシングをサポート。ストレージにElasticsearch対応のJaegerやZipKinがAgent/Collectorとして機能 (https://www.elastic.co/jp/blog/distributed-tracing-opentracing-and-elastic-apm)

Jaeger in k8sを利用した構成例 32 AWS Cloud アプリコンテナ (jaeger client library実装含む) jaeger-operator simplest 参考) https://github.com/jaegertracing/jaeger-kubernetes https://github.com/jaegertracing/jaeger-operator agent collector query Collector-headless NodePort (外部アクセス用 に個別に作成) Jaeger agent (daemonSet) Jaeger agent (sidecar) • jaeger client libraryを含むアプリコードは、jaeger agent(sidecar or daemonSet)経由で、Jaeger collectorへTraceIDなどを転送 • Jaeger Operatorのデフォルトはsidecar方式 • JAEGER公式サイト > Deployment > Kubernetesを見ると、セットアップはOperator前提 • github(jaegertracing/jaeger-kubernetes)でもOperatorでインストール・管理が推奨 • Operatorでデフォルト作成(strategy：AllInOne、テスト用途)すると一つのpodに全機能[agent、collector、query、in-memory(storage)]が作成 Strategy：AllInOne or

Istio/Envoy in k8sを利用した分散トレーシングの構成例 33 AWS Cloud broker Istio-proxy (sidecar) • Istio/Envoyは、分散トレーシング(Zipkin、LighStep)をサポート(https://istio.io/docs/tasks/telemetry/distributed-tracing/) ※現在はJaegerもサポートしている様に見える • Githubにhelm形式「stio/grafana/prometheus/tracing(jaeger)/kiali」で提供※https://github.com/istio/istio/tree/master/install/kubernetes/helm/istio ※Helm Hub(https://hub.helm.sh/)に居ないが、github>helm>incubatorにいた(https://github.com/helm/charts/tree/master/incubator/istio) redis Istio-proxy (sidecar) mysql Istio-proxy (sidecar) agent collector query(UI) istio-tracing (Jaeger all-in-one) (memory storage) Istio- tracing zipkin • istio-citadel • istio-egressgateway • istio-galley • istio-ingressgateway • istio-pilot • istio-policy • istio-sidecar-ingector • istio-telemetry • Grafana • Prometheus • kiali ※下記の deployment/replic aset/podが稼働 ※下記の deployment/replic aset/podが稼働 NodePort (jaeger UIへアクセス) NodePort (grafana UIへアクセス) NodePort (kiali UIへアクセス) 各Podにトレーサ用sidecar(例：Istio-Proxy) or アプリコードにトレーサクライア ントライブラリを実装し、TraceIDなどを収集 ※試したMessagePub+では、brokerがredisやmysqlへアクセス この辺りもセットで作れる ※ 分散トレーシング話についてRedhatの以下コミュニティ資料が結構参考になります (https://speakerdeck.com/16yuki0702/distributed-tracing-at-openshift-meetup-tokyo20191018) サービスメッシュ(Istio)関連 のサービス達

34 • Observability(可観測性)の概要 • Observability(可観測性)の3本柱  Metrics  Logs  Traces • さいごに

さいごに 35 • Observabilityは従来からの概念。マイクロサービス化による複雑・俊敏性から一層注目 • 過渡期なマイクロサービスのObservabilityを自分で整備するのは大変。利用中のパブリ ッククラウドのマネージドサービス(例：Stackdriver)やSaaS(例：Datadog)も要検討 • Observabilityはロードマップ(最終目的はビジネスKPIの改善)の出発点 • k8s社内勉強会では、こういった話をしています(宣伝)  社内説明会・研修受付システムで申込可能  http://trs.icc.ogis-ri.co.jp/kenshu/app.html#/courses/search/q=K19052802

ご清聴ありがとうございました 36