k8sでJavaを見守る新常識

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

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

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

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

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

Transcript

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

   View Slide

2. 名前　　：　伊藤　ちひろ
   Twitter ：　@chiroito
   会社　　：　Red Hat
   仕事　　：　Java Platform Advocate
   活動　　：　OpenJDK Committer
   Japan OpenJDK Developer’s Group
   Japan Java User Group
   自己紹介
   2
   

   View Slide

3. 本資料の対象者
   ● Java アプリケーションを開発している人
   ● コンテナを使ってる人
   ● Java アプリケーションの監視でなにをすれば良いか悩んでいる人
   ● Javaアプリケーションの監視をもっと楽にしたい人
   ● 監視システムを楽に運用したい人
   3
   

   View Slide

4. みなさんはシステムを
   監視してますか？
   4
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. 監視についてよくある問題
   ● 監視なんて不要だと思って監視の仕組みを作成するコストはない
   ● 監視が必要だと思っているが、監視についての知識がない
   ● 監視環境の管理なんてしたくない
   ● 監視をしても問題の分析に必要な情報が取れていない
   ● 監視しても問題の予兆を検知できず、問題が顕在化する
   ● 問題を製品のせいにし、別の製品へ移行して再発する
   8
   今日の
   本題
   

   View Slide

9. どうすれば良いの？
   ● Red Hat OpenShift Container Platformを使ってください
   ○ 監視に必要な基盤はOpenShiftに無料で含まれています
   ○ 必要十分な監視の基盤が標準で入っています
   ○ 監視の基盤が簡単にインストール、自動で運用されます
   ○ 標準的な機能を使って必要十分な情報を取得します
   9
   

   View Slide

10. OpenShiftとは？
    10
    

    View Slide

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
    

    View Slide

12. システムの自律運用化
    Operatorによる、システム全体の自律運用
    正常稼働
    障害検知
    状態確認
    復旧作業
    正常確認
    正常稼働
    障害検知
    動的復旧
    不具合修正
    or 再構築
    正常確認
    自己修復
    (Self-Healing)
    個別対応
    (Customize)
    いままで人が対応してきた障害対応を自律的に回復する
    『Operator』
    Automated operations
    Manage with simplicity.
    

    View Slide

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.
    

    View Slide

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の製品価値
    

    View Slide

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プロジェクト)に還元されてい
    る。
    

    View Slide

16. 監視とは
    16
    

    View Slide

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

    View Slide

18. どんな情報を監視するべきか
    ● よく取られている情報
    ○ ハードウェアリソースの使用量
    ● 取られていないことが多い情報
    ○ そもそもシステムが動いているかどうか
    ○ OSの各種リソース
    ○ アプリケーションの情報
    ○ フレームワークやミドルウェアの情報
    18
    OS
    HW
    スタック
    アプリ
    App
    

    View Slide

19. Javaの監視
    .
    19
    

    View Slide

20. Javaアプリで監視すべき情報
    ● アプリケーション
    ● ミドルウェア（APサーバ、フレームワーク含む）
    ● Java 仮想マシン(Virtual Machine)
    ● オペレーティングシステム
    20
    MW
    JVM
    OS
    スタック
    アプリ
    App
    

    View Slide

21. Javaが標準で提供する情報の取り方
    ● ログ（java.util.logging、Unified Logging、他JVMログ）
    ● MBean / MXBean / Java Management Extensions (JMX)
    ● JDKツール群 (jcmd, jstatなど)
    ● JDK Flight Recorder
    ● MicroProfile Health/Metrics
    21
    

    View Slide

22. 近年Javaの監視で良くとられる手段
    ● Application Perfomance Management (APM)を使用
    ● クラウドベンダーの監視サービスを使用
    ● 手動で監視環境を構築
    ○ Elasticsearch + Kibana
    ○ Prometheus + Grafana
    ● ログ出力
    22
    

    View Slide

23. 従来のシステム監視方法
    23
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. ログを分析するときの良くある問題
    ● 手動で情報を集めてくるため情報の取得に時間が掛かる
    ● 記録している情報が不足して原因を絞り込めない（勘で対象を決定
    ● 再起動時にログを上書きして消失
    27
    アプリケーション Database
    Web
    多分これが原因なので、
    ベンダーに問い合せよう
    （根拠なし）
    

    View Slide

28. 現在求められる監視
    28
    

    View Slide

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

    View Slide

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

    View Slide

31. 新しい監視に望まれる要件
    ● 簡単に情報を集められる
    ● どの構成要素が問題かすぐ分かる
    ● 必要十分な情報が取れる
    ● 追加コストがあまり掛らない
    31
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

37. OpenShiftでの監視
    37
    

    View Slide

38. OpenShiftができること
    ● 監視を簡単に始められる
    ● 監視環境は高い可用性を持つ構成で構築される
    ● 監視環境は自動で運用される
    ● Javaの標準機能とデファクトのOSSを使用する
    ● 初期設定だけ、または設定もなしに監視できる
    ● 各環境へのアクセスはOpenShiftの認証でSSOされる
    38
    

    View Slide

39. OpenShiftで監視の例１
    39
    

    View Slide

40. OpenShiftで監視の例２
    40
    

    View Slide

41. OpenShiftで監視の例３
    41
    

    View Slide

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
    

    View Slide

43. OpenShiftが統合するツール群
    ● どこで問題が起こっているかを確認
    ○ Service Mesh (Istio, Jaeger, Kiali, Grafana)
    ● 各コンテナの問題を確認
    ○ Liveness / Rediness / Startup Probe (Kubernetes)
    ○ OpenShift Logging (Elasticsearch + Fluentd + Kibana)
    ○ Cluster Monitoring (Prometheus)
    ○ Cryostat（Grafana）
    43
    

    View Slide

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
    

    View Slide

45. OpenShiftが統合するツール群
    45
    インストールされているOperator
    

    View Slide

46. Service Mesh
    ● メリット
    ○ システムのどこに問題が起きているかを確認
    ○ どこの処理に時間が掛かったかを確認
    ● 監視環境構築
    ○ オペレータでインスタンスを作るだけ
    ● アプリケーション
    ○ OpenTracingを使うように設定
    46
    

    View Slide

47. Service Meshの画面 (Kiali)
    47
    リクエストがどの様に処理されているか、どこに問題が起きているか確認可能
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

55. Liveness / Readiness / Startup Probe
    .
    ● メリット
    ○ コンテナの状態を確認
    ● 監視環境構築
    ○ Kubernetesの標準機能なのでインストール不要
    ● アプリケーション
    ○ コンテナの設定で監視先URLを指定
    55
    

    View Slide

56. Probeの構築方法
    56
    GUIによってURLを指定、またはデプロイ時に指定
    

    View Slide

57. OpenShift Logging
    .
    ● メリット
    ○ 各種ログを可視化
    ● 監視環境構築
    ○ Operator をインストール
    ○ カスタムリソース定義でインスタンスを作成
    ● アプリケーション
    ○ 標準出力かファイルへログを出力
    57
    

    View Slide

58. OpenShift Loggingの画面
    .
    58
    GUIでログを分析可能
    

    View Slide

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

    View Slide

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

    View Slide

61. OpenShift Loggingの構築方法２
    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: {}
    

    View Slide

62. Cluster Monitoring
    ● メリット
    ○ 各種メトリクスをグラフ化
    ● 監視環境構築
    ○ 管理者がユーザ領域での監視を有効化
    ○ ユーザに権限付与
    ● アプリケーション
    ○ カスタムリソース定義でアプリケーションを監視対象に追加
    62
    

    View Slide

63. Cluster Monitoringの画面１
    63
    デフォルトで各コンテナのリソース情報を取得
    図は縦の画面を横に並べています
    

    View Slide

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

    View Slide

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

    View Slide

66. Cluster Monitoringの構築方法 管理者側１
    66
    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: cluster-monitoring-config
    namespace: openshift-monitoring
    data:
    config.yaml: |
    enableUserWorkload: true
    機能をユーザ領域にも拡張（1度のみ）
    ユーザ領域用の
    監視環境を
    自動作成
    @openshift-user-workload-monitoring名前空間
    

    View Slide

67. Cluster Monitoringの構築方法 管理者側２
    67
    oc policy add-role-to-user -n
    名前空間を監視する権限（ロール）を付与
    oc -n openshift-user-workload-monitoring adm policy add-role-to-user \
    user-workload-monitoring-config-edit \
    --role-namespace openshift-user-workload-monitoring
    ユーザが監視対象を追加できる権限（ロール）を付与
    

    View Slide

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
    監視したい対象を追加
    

    View Slide

69. Cryostat
    .
    ● メリット
    ○ JVM内部の情報を取得・可視化
    ○ カスタムイベントを作るとアプリケーションの情報も対応可能
    ● 監視環境構築
    ○ Operatorでインストール＆自動運用
    ● アプリケーション
    ○ カスタムリソース定義でJFRを起動
    69
    開発中、製品非サポート
    

    View Slide

70. Cryostatの画面
    70
    JVMやアプリケーションのさまざまな情報を確認できる
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

75. まとめ
    簡単
    ● 設定だけで監視
    ● 自動構成
    ● 自律運用
    75
    安い
    ● 無料で使用可能
    ● 構築コスト低
    便利
    ● 標準仕様
    ● 必要十分な情報
    

    View Slide

76. linkedin.com/company/red-hat
    youtube.com/user/RedHatVideos
    facebook.com/redhatinc
    twitter.com/RedHat
    Thank you
    76
    

    View Slide