Save 37% off PRO during our Black Friday Sale! »

k8sでJavaを見守る新常識

484571ccba0db66b69dc11761afdd0c4?s=47 Chihiro Ito
November 21, 2021

 k8sでJavaを見守る新常識

JJUG CCC 2021 Fallの講演資料です。

Kubernetesが発表されて長い時間が経ち、さまざまなシステムで導入されていきました。そのような中で、Java言語で書かれたアプリケーションをKubernetes上で動かす機会が増えています。

本セッションでは、まず、監視とはそもそも何か、また、Javaの監視について簡単に振り返ります。次に、昔の監視方法はどの様なもので、どの様な課題があったかを整理し、今のシステムではどの様な監視が求められているのかを紹介します。

最後に、Red Hatが提供しているエンタープライズグレードのKubernetesであるOpenShift Container Platformを使用することで、今求められている監視の要件をどの様に実現できるのかを紹介します。

注意:
本セッションではJavaを具体的にどの様に監視するのかという話はしません。Javaの監視の知識がなくても、簡単に詳細な情報を取得する機能について紹介します。

484571ccba0db66b69dc11761afdd0c4?s=128

Chihiro Ito

November 21, 2021
Tweet

Transcript

  1. 伊藤ちひろ Chihiro Ito k8sでJavaを見守る新常識 1

  2. 名前  : 伊藤 ちひろ Twitter : @chiroito 会社  : Red Hat 仕事  : Java Platform Advocate 活動  : OpenJDK Committer

    Japan OpenJDK Developer’s Group Japan Java User Group 自己紹介 2
  3. 本資料の対象者 • Java アプリケーションを開発している人 • コンテナを使ってる人 • Java アプリケーションの監視でなにをすれば良いか悩んでいる人 •

    Javaアプリケーションの監視をもっと楽にしたい人 • 監視システムを楽に運用したい人 3
  4. みなさんはシステムを 監視してますか? 4

  5. よくある監視の回答 監視?そんなの必要なの? 担当が良い感じにしてるはずだよ 監視とか不要な物に余計なお金を 使う余裕は無いんですよ。 5 ビジネス所有者

  6. よくある監視の回答 うちはHWのリソース使用量を 取ってるからバッチリです! うちのシステムは問題なんて 出ないから監視しなくて大丈夫。 6 システム担当

  7. 障害に直面すると・・・ HWのリソースは余裕があるのに性能が 出ないからこのMWが悪い 情報?何も取ってないけど早く 解決してよ 7 ビジネス所有者/システム担当

  8. 監視についてよくある問題 • 監視なんて不要だと思って監視の仕組みを作成するコストはない • 監視が必要だと思っているが、監視についての知識がない • 監視環境の管理なんてしたくない • 監視をしても問題の分析に必要な情報が取れていない •

    監視しても問題の予兆を検知できず、問題が顕在化する • 問題を製品のせいにし、別の製品へ移行して再発する 8 今日の 本題
  9. どうすれば良いの? • Red Hat OpenShift Container Platformを使ってください ◦ 監視に必要な基盤はOpenShiftに無料で含まれています ◦

    必要十分な監視の基盤が標準で入っています ◦ 監視の基盤が簡単にインストール、自動で運用されます ◦ 標準的な機能を使って必要十分な情報を取得します 9
  10. OpenShiftとは? 10

  11. OpenShiftはKubernetesを補完する付加価値機能を提供 運用プロセスを含めたポータビリティの実現 AUTOMATED OPERATIONS CLUSTER SERVICES APPLICATION SERVICES DEVELOPER SERVICES

    Middleware, Service Mesh Functions, ISV Monitoring, Chargeback Registry, Logging Automated Builds, CI/CD, IDE 11 Any Infrastructure どの環境でも、迅速かつ 信頼性の高いOS どの環境でも、同様の手 順でアプリケーションを稼 働 どの環境でも、自動化さ れた運用プロセスを実現 Virtual Private cloud Bare metal Public cloud Edge
  12. システムの自律運用化 Operatorによる、システム全体の自律運用 正常稼働 障害検知 状態確認 復旧作業 正常確認 正常稼働 障害検知 動的復旧

    不具合修正 or 再構築 正常確認 自己修復 (Self-Healing) 個別対応 (Customize) いままで人が対応してきた障害対応を自律的に回復する 『Operator』 Automated operations Manage with simplicity.
  13. Automated operations Enterprise Linux CoreOS 13 コンテナアプリの本番適用 OpenShift involve Kubernetes

    ecosystem with partner & community Cluster Services クラスタ管理を容易にし、運用業務を自動化するサービス Physical Virtual Private Public Any infrastructure Developer Services 開発者がコンテナアプリケーション開発に集中できる環境を 整えるサービス Cluster services monitoring, showback, registry, logging Application services middleware, functions, ISV Service mesh Developer services dev tools, automated builds, CI/CD, IDE certified Application Services マイクロサービス間の連携やファンクションサービスを実現 を支援するサービス Logging Registry Monitoring ISV Middleware Function Service ServiceMesh IDE CI/CD Developer Tools チームがスピード、アジリティに自信を持ってビルド できる環境を提供。クラウドネイティブな開発を本番 へのコード作成を支援。 Build fast. Ship first.
  14. OpenShift Core Value Container Value Kubernetes Value OpenShift Value 開発スピードと安定性の両立

    Agility & Reliability リソースの抽象化 Declarative Configuration 堅牢化されたコンテナ実行環境 Trust with Red Hat どこでも実行出来るアプリ Application Portability 自己回復性 Self-healing システムの自律運用化 Manage with Simplicity 一貫した環境の維持 Consistent Environment 自動オートスケール Auto-Scaling コンテナアプリの本番適用 Build fast. Ship first コンテナやk8sで得られる共通の価値 OpenShiftの製品価値
  15. https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1 オープンソースリード <2 years v1.0 v1.1 v1.2 v1.3 v1.4 v1.5

    v1.6 v1.7 v1.8 v1.9 v1.10 v1.11 v1.12 v1.13 v1.14 4 years+ 2016 2017 2018 2019 2 years+ ~2 years ~2 years <2 years <2 years 4 years+ ~2 years Kubernetes versions GoogleがKubernetesを オープンソース化した当初から、 Red Hatも開発に大きく貢献 エンタープライズの機能は先に OpenShift に取り込まれ、オープンソース (Kubernetesプロジェクト)に還元されてい る。
  16. 監視とは 16

  17. そもそもなぜシステムの監視が必要? • システムが稼働していることを確認 • システムがどの様に動いているのかを確認 • 問題の予兆を検知して、問題が発生しないように対処 • 何か起きたときに分析の参考にする 17

    アプリケーション 君、動いてる? ・・・
  18. どんな情報を監視するべきか • よく取られている情報 ◦ ハードウェアリソースの使用量 • 取られていないことが多い情報 ◦ そもそもシステムが動いているかどうか ◦

    OSの各種リソース ◦ アプリケーションの情報 ◦ フレームワークやミドルウェアの情報 18 OS HW スタック アプリ App
  19. Javaの監視 . 19

  20. Javaアプリで監視すべき情報 • アプリケーション • ミドルウェア(APサーバ、フレームワーク含む) • Java 仮想マシン(Virtual Machine) •

    オペレーティングシステム 20 MW JVM OS スタック アプリ App
  21. Javaが標準で提供する情報の取り方 • ログ(java.util.logging、Unified Logging、他JVMログ) • MBean / MXBean / Java

    Management Extensions (JMX) • JDKツール群 (jcmd, jstatなど) • JDK Flight Recorder • MicroProfile Health/Metrics 21
  22. 近年Javaの監視で良くとられる手段 • Application Perfomance Management (APM)を使用 • クラウドベンダーの監視サービスを使用 • 手動で監視環境を構築

    ◦ Elasticsearch + Kibana ◦ Prometheus + Grafana • ログ出力 22
  23. 従来のシステム監視方法 23

  24. 従来のシステムの特徴 • 3層アーキテクチャ(Web、AP、DB) • 台数は完全に固定 24 アプリケーション Database Web

  25. 従来のシステムでの監視の特徴 • 対象が不変なのでシステム構築時に設計すれば十分 • アプリケーションの監視項目が更新されないので監視項目は不変 25

  26. 従来の監視方法の例 • 監視システムを構築し、監視対象を登録(超レア) • 情報をログファイルへ保存(レア) • 監視しない(多い) 26 アプリケーション レア

    超レア 監視システム ログ
  27. ログを分析するときの良くある問題 • 手動で情報を集めてくるため情報の取得に時間が掛かる • 記録している情報が不足して原因を絞り込めない(勘で対象を決定 • 再起動時にログを上書きして消失 27 アプリケーション Database

    Web 多分これが原因なので、 ベンダーに問い合せよう (根拠なし)
  28. 現在求められる監視 28

  29. 従来と現在のシステムの違い • システムの構成はかなり複雑 • システムの構成は日々変化 • 各構成要素のサーバ数は刻々と変化 29 0~100で増減します

  30. 現在のシステムを監視する新たな問題 • 監視サービスは便利だが高すぎて導入できない • 構成が複雑すぎて従来以上に情報を取りきれない • 製品やサービスの進化が早すぎて情報の変化についていけない • 対象が動的に変化するので監視できない •

    障害に気付いたときには監視対象がすでに存在しないことがある 30
  31. 新しい監視に望まれる要件 • 簡単に情報を集められる • どの構成要素が問題かすぐ分かる • 必要十分な情報が取れる • 追加コストがあまり掛らない 31

  32. ”簡単に集められる”とは • 監視システムの運用が要らない • 監視対象の追加は設定するだけor設定すら不要 • 監視対象が増えたら勝手に監視開始 32

  33. ”どの構成要素が問題かすぐ分かる”とは • 処理の中の登場人物を網羅 • 処理のどの部分で問題が起きているのかが明白 • 処理の中で何が起こっているかが明白 . 33 私のXXXが問題です

  34. ”必要十分な情報が取れる”とは • HWリソースだけでなくアプリの情報までも幅広く取れる • 新しい情報にも自動で追従する 34 アプリケーション MWのバージョン更新で 新しい情報を提供します

  35. ”追加コストがあまり掛らない”とは • 監視システムの構築/運用コストが低い • アプリケーションを監視システムに対応するコストが低い • 可視化に必要な開発コストが低い 35

  36. こんな監視システムを 実現するの大変ですよね? 36

  37. OpenShiftでの監視 37

  38. OpenShiftができること • 監視を簡単に始められる • 監視環境は高い可用性を持つ構成で構築される • 監視環境は自動で運用される • Javaの標準機能とデファクトのOSSを使用する •

    初期設定だけ、または設定もなしに監視できる • 各環境へのアクセスはOpenShiftの認証でSSOされる 38
  39. OpenShiftで監視の例1 39

  40. OpenShiftで監視の例2 40

  41. OpenShiftで監視の例3 41

  42. OpenShiftが使用するJavaの標準機能 • 標準出力・標準エラー出力 • Unified Logging (Java 9以降) / JVMログ(Java

    8以前) • MBean / MXBean / JMX • JDK Flight Recorder (Java 8 u262以降, Java 11以降) • MicroProfile Metrics/Health 42
  43. OpenShiftが統合するツール群 • どこで問題が起こっているかを確認 ◦ Service Mesh (Istio, Jaeger, Kiali, Grafana)

    • 各コンテナの問題を確認 ◦ Liveness / Rediness / Startup Probe (Kubernetes) ◦ OpenShift Logging (Elasticsearch + Fluentd + Kibana) ◦ Cluster Monitoring (Prometheus) ◦ Cryostat(Grafana) 43
  44. Javaの機能とOpenShiftのツールの対応 44 Service Mesh (OpenTracing、OpenTelemetry) Liveness / Readiness / Startup

    Probe MicroProfile Health OpenShift Logging 標準出力・標準エラー出力 java.util.logging Unified Logging JVMログ Cluster Monitoring MBean / MXBean / JMX MicroProfile Metrics Cryostat JDK Flight Recorder
  45. OpenShiftが統合するツール群 45 インストールされているOperator

  46. Service Mesh • メリット ◦ システムのどこに問題が起きているかを確認 ◦ どこの処理に時間が掛かったかを確認 • 監視環境構築

    ◦ オペレータでインスタンスを作るだけ • アプリケーション ◦ OpenTracingを使うように設定 46
  47. Service Meshの画面 (Kiali) 47 リクエストがどの様に処理されているか、どこに問題が起きているか確認可能

  48. Service Meshの画面 (Kiali) 48 システム全体の各種性能情報が確認可能

  49. Service Meshの画面 (Kiali) 49 各リクエストの処理時間が視覚的に確認可能

  50. Service Meshの画面 (Jaeger) 50 リクエスト内で処理に掛かった時間が視覚的に確認可能 Quarkusの場合はHTTP/RDBMS/Kafka/MongoDBなどがトレース可能

  51. Service Meshの画面 (Grafana) 51 負荷情報など様々な情報が視覚的に確認できる 事前定義済の様々な ダッシュボード

  52. Service Mesh の環境 52 さまざまな要素によって運用され、これらは自律的に運用 構成要素 Istio Grafana Prometheus Kiali

    Jaeger
  53. Service Mesh の構築方法1 53 基本的な構築はボタンを押すだけ

  54. Service Mesh の構築方法2 54 基本的な構築はボタンを押すだけ

  55. Liveness / Readiness / Startup Probe . • メリット ◦

    コンテナの状態を確認 • 監視環境構築 ◦ Kubernetesの標準機能なのでインストール不要 • アプリケーション ◦ コンテナの設定で監視先URLを指定 55
  56. Probeの構築方法 56 GUIによってURLを指定、またはデプロイ時に指定

  57. OpenShift Logging . • メリット ◦ 各種ログを可視化 • 監視環境構築 ◦

    Operator をインストール ◦ カスタムリソース定義でインスタンスを作成 • アプリケーション ◦ 標準出力かファイルへログを出力 57
  58. OpenShift Loggingの画面 . 58 GUIでログを分析可能

  59. OpenShift Loggingの構成 . 59 さまざまな要素によって運用され、これらは自律的に運用 構成要素 Elasticsearch Fluentd Kibana

  60. OpenShift Loggingの構築方法1 . 60 GUIでボタンを押すだけで インストール完了

  61. OpenShift Loggingの構築方法2 61 監視基盤のカスタムリソース定義を作成 (複雑なカスタマイズも可能) apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata:

    name: "instance" namespace: "openshift-logging" spec: managementState : "Managed" logStore: type: "elasticsearch" retentionPolicy : application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch : nodeCount: 3 storage: size: 200G resources: requests: memory: "8Gi" proxy: resources: limits: memory: 256Mi requests: memory: 256Mi redundancyPolicy : "SingleRedundancy" visualization : type: "kibana" kibana: replicas: 1 curation: type: "curator" curator: schedule: "30 3 * * *" collection: logs: type: "fluentd" fluentd: {}
  62. Cluster Monitoring • メリット ◦ 各種メトリクスをグラフ化 • 監視環境構築 ◦ 管理者がユーザ領域での監視を有効化

    ◦ ユーザに権限付与 • アプリケーション ◦ カスタムリソース定義でアプリケーションを監視対象に追加 62
  63. Cluster Monitoringの画面1 63 デフォルトで各コンテナのリソース情報を取得 図は縦の画面を横に並べています

  64. Cluster Monitoringの画面2 64 アプリケーション独自のメトリクスも表示可能

  65. Cluster Monitoringのアーキテクチャ 65 さまざまな要素によって運用され、これらは自律的に運用 構成要素 Prometheus Thanos

  66. Cluster Monitoringの構築方法 管理者側1 66 apiVersion: v1 kind: ConfigMap metadata: name:

    cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | enableUserWorkload: true 機能をユーザ領域にも拡張(1度のみ) ユーザ領域用の 監視環境を 自動作成 @openshift-user-workload-monitoring名前空間
  67. Cluster Monitoringの構築方法 管理者側2 67 oc policy add-role-to-user <role> <user> -n

    <monitored_namespace> 名前空間を監視する権限(ロール)を付与 oc -n openshift-user-workload-monitoring adm policy add-role-to-user \ user-workload-monitoring-config-edit <user> \ --role-namespace openshift-user-workload-monitoring ユーザが監視対象を追加できる権限(ロール)を付与
  68. Cluster Monitoringの構築方法 アプリ側 68 apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels:

    k8s-app: prometheus-example-monitor name: prometheus-example-monitor namespace: ns1 spec: endpoints: - interval: 30s port: web scheme: http selector: matchLabels: app: prometheus-example-app 監視したい対象を追加
  69. Cryostat . • メリット ◦ JVM内部の情報を取得・可視化 ◦ カスタムイベントを作るとアプリケーションの情報も対応可能 • 監視環境構築

    ◦ Operatorでインストール&自動運用 • アプリケーション ◦ カスタムリソース定義でJFRを起動 69 開発中、製品非サポート
  70. Cryostatの画面 70 JVMやアプリケーションのさまざまな情報を確認できる

  71. Cryostatの構築方法1 71 GUIでボタンを押すだけの簡単なインストール

  72. Cryostatの構築方法2 72 GUIでボタンを押すだけの簡単なインストール

  73. Cryostatの構成 73 Grafanaも内包された環境を構成

  74. まとめ:こういう構成が簡単に組めます 74 アプリケーション ログ OpenTracing MBean JFR MicroProfile Metrics MicroProfile

    Health
  75. まとめ 簡単 • 設定だけで監視 • 自動構成 • 自律運用 75 安い

    • 無料で使用可能 • 構築コスト低 便利 • 標準仕様 • 必要十分な情報
  76. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you 76