2024.05.14

#20　Dynatraceを用いたKubernetes分析（3/3）

Dynatrace

Kubernetes

アラート機能の活用方法

はじめに

本テーマの構成

本テーマは、3本の記事で構成しています。

1本目の記事では、コンテナ技術の普及に至った背景から、Kubernetesを構成するレイヤーの説明、オートスケーリング機能によるリソースの自動調整の機能を紹介しました。

以降の記事で、「Dynatrace」を用いて、Kubernetesを対象に分析する手法について説明しています。

2本目の記事では、パフォーマンス分析の観点から、各画面や手法を紹介しました。

本記事にて、アラート機能に焦点を当てて、各種設定やIT運用にどのように役立てられるのかを説明します。（下記目次の3、4に該当します。）

本テーマ全体の目次

全体を通しての目次は、下記の通りです。

[目次] ――――――――――――――――――――――――

1.　 Kubernetesとは、Kubernetesの各レイヤーについて

1-1. Kubernetesとは何か

1-2. コンテナ技術とDocker

1-3. Kubernetesの登場

1-4. Kubernetesの構成

1-5. Kubernetesのオートスケーリング機能について

2.         Dynatraceでできること（パフォーマンス分析）

2-1.     Dynatraceを用いたKubernetesの性能管理

2-2.     DynatraceでのKubernetesの稼働分析

2-2-1. Cluster単位の分析

2-2-2. Namespace単位の分析

2-2-3. Workload単位の分析

2-2-4. Node単位の分析

2-2-5. Pod単位の分析

2-2-6. Container単位の分析

3.     Dynatraceでできること（アラート機能）

3-1. Cluster単位の検知

3-2. Namespace単位の検知

3-3. Node単位の検知

3-4. Workload単位の検知

4. まとめ

――――――――――――――――――――――――

3．Dynatraceでできること（アラート機能）

Dynatraceには、普段と異なる動きを計測した場合に、"Problem"として判断しアラート通知・分析を容易にする機能があります。

また、アラート通知について、メール等による発報も可能となっており、問題発生時に早急に気付く仕組みも備わっています。

＜Problem検知について設定の容易性＞

Dynatraceでは、各レイヤー単位で、一括でアラート通知の監視対象とすることができます。

KubernetesにおけるNamespaceとは、任意で作成が可能であり、随時追加されることがあります。

Dynatraceでは、Namespaceに対してのアラート通知設定を一度行えば、後に追加されたNamespaceについてもそのアラート通知設定の対象となり、手動での追加設定は必要ありません。

その他、Cluster単位や、オートスケーリングにつき増減するNode、Podについても同様です。

一度アラート通知設定を行えば、その後で生成されたものについて自動的にその通知設定の対象となります。

＜Problem検知について設定の実例＞

弊社のお客様では、下記のようなケースに対して、Problem検知を設定された実績があります。

・ClusterやNode単位で、リソースが高騰したとき

・Podがkillされたとき

・Podのデプロイメントがスタックしたとき

上記のケースでは、リソース不足が発生した際などに、担当者にメールを送信する仕組みを構築されました。

下記、Dynatraceが検知可能なProblemの例を掲載します。

なお、各設定は、閾値や発生継続時間等による設定を対象に、デフォルト値からの変更も可能です。

3-1. Cluster単位の検知

・Clusterを対象に、CPU Requestsの飽和が発生しているか

・Clusterを対象に、メモリ Requestsの飽和が発生しているか

3-2. Namespace単位の検知

・Namespaceを対象に、CPU Requestsがrequest quotaで定めた値を超過した際の検知

・Namespaceを対象に、メモリ Requestsがrequest quotaで定めた値を超過した際の検知

　※Resource Quotasは管理者が、Namespaceを対象に、総リソース消費を制限するための上限を設定する値です。

　　これは複数のユーザーやチームが共有するCluster内で、1つのチームが使えるリソース量を超えないために使用されます。

3-3. Node単位の検知

・Nodeが準備できていないことの検知

・Nodeを対象に、CPU Requestsの飽和が発生した際の検知

・Nodeを対象に、メモリ Requestsの飽和が発生した際の検知

・Podを対象に、飽和が発生した際の検知

3-4. Workload単位の検知

・Workloadを対象に、CPU使用率が高騰した際の検知

・Workloadを対象に、メモリ使用率が高騰した際の検知

・Podを対象に、保留中、終了中、準備中の状態の検知

・Podを対象に、メモリ不足によるkillが発生した際の検知

・CPUスロットリングが閾値を超えて発生しているかの検知

・Containerのリスタート回数が指定の閾値を超えた際の検知

・デプロイのスタックが発生した際の検知

４．まとめ

Kubernetesの持つ高度なオートスケーリング機能により、システム運用者がこれまで抱えていたリソース過不足による性能問題の多くが解決できるようになりましたが、同時に設定の最適化という新たな問題が出てきました。

リソースの割り当てについて動的に設定を変更できる反面、サービスレベルを維持しつつ、変化する業務量に対してKubernetesが使用するリソースの無駄をできるだけ少なくするという、より高度な運用が求められます。

DynatraceはOneAgentの自動インストール機能により、PodのスケーリングからNodeの追加までClusterの変化に即座に適応しながら、リアルタイムで性能状況を可視化できます。

また、Kubernetes自身の稼働状況だけでなく、Kubernetesの上で稼働するアプリケーションについても詳細なレベルで情報を取得・可視化できます。

さらに、アラート機能を活用することで、各レイヤーのリソース管理や、アプリケーションの監視にあたって、問題があれば通知する仕組みをレイヤー単位で容易に設計することができます。

能動的に監視をする手間を省き、問題が起きた際には、一元的に全体を俯瞰ができるダッシュボードから、最小単位であるContainerまで繋げて辿ることが可能であり、復旧に当たっても役立ちます。

インフラ面、アプリケーション面の双方からシステムの稼働状態を把握することで、適切なサービスレベルを維持しつつ、リソース使用の無駄を排除していくという高度な運用の手助けになるかと思っております。

この記事がお客様のシステム運用における一助になれば幸いです。

以上

執筆者

R.Y.　

営業技術本部 技術サービス統括部 技術サービス１部　

お客様担当SEとして、製品の構築から活用方法までの一連のサポートを担当
また、お客様環境にて性能問題が発生した際には、製品のアウトプットを利用し、問題解決に向けた調査／提案業務を実施

■経歴
2021年　　入社
2022年　　東京でのお客さまサポートを担当

主にシステムリソース情報からの性能管理サポート、APM製品を利用したユーザー体感レスポンスやアプリケーション視点での性能管理サポートに従事。現在に至る。