2020.12.17

【中編】モニタリングはもう古い?-Tanzu Observabilityのご紹介-

星野真知
ヴイエムウェア株式会社
このエントリーをはてなブックマークに追加

【前編】モニタリングはもう古い?-Tanzu Observabilityのご紹介-
【中編】モニタリングはもう古い?-Tanzu Observabilityのご紹介-
←本記事です
【後編】モニタリングはもう古い?-Tanzu Observabilityのご紹介-

はじめに

前回の記事でTanzu Observabilityの概要を紹介させていただきました。
今回は一歩踏み込んで昨今話題のKubernetes観測について取り上げます。

※なお、本記事では「監視」ではなく「観測」(Observe)という表現を使います。

2020-12-14T07-54-00.png

Prometheusから脱却?
SaaS型のKubernetes観測のメリットとは

Kubernetesの登場により、より柔軟なインフラストラクチャ、そしてアプリケーションをオンデマンドに展開やスケールアップが可能になりました。しかし、それと同時に課題になるのが観測の手法です。

Kubernetesの観測と聞き、多くの方が最初に思い浮かべるソリューションがPrometheusだと思います。Prometheusは、Cloud Native Computing Foundation(CNCF)のプロジェクトの一つであり、Kubernetes観測の代表格です。特徴としてエージェントに依存せず、サービスディスカバリによって観測対象を自動的に見つけ出し収集できる点、PromQLという高速に必要なデータを取り出すクエリ言語をサポートしている点があげられます。きっと皆様も、PoCや本番環境で利用されたことがあるかと思います。

しかし、Prometheusの導入によって新たな問題が発生します。最初の問題がスケーラビリティです。これは、Prometheusが高可用性(HA)の構成が取りにくいために生じます。結果として、複数のPrometheusをKuberntesごとに作るなどの構成になってしまいます。当然Prometheusの数に伴い運用の難易度が高くなります。さらに頭を悩ませるのがストレージの容量です。Prometheusのデータ量はKubernetesの規模によって大きくなり、数テラバイト〜数ペタバイドの容量になりうります。

もう一つの問題がセキュリティです。Prometheusは、 ユーザー認証やアクセス制御の仕組みは機能が充実していません
そのため、Prometheusを複数チームで共有することや、オペレーター以外のユーザーに公開することは難しくなります。

2020-12-14T07-47-48.png

(KubernetesのPrometheus連携とその課題)

こういった点に疑問を感じ始めたときこそが、SaaS型のKubernetes観測を検討するべきタイミングです。SaaSにすることによって、オンプレミス側の運用を簡素化していきます。さらには、データ容量もSaaSのサービスによって保証されるだけでなく、アップタイムもService Level Agreement(SLA)で保証されます。ユーザー認証もプラットフォームが提供する機能を利用することができます。

Tanzu ObservabilityはSaaS型プラットフォームであり、Kubernetes環境の観測を次のステップへと昇格させることができます。

Tanzu ObservabilityとPrometheusの連携

冒頭で取り上げたように既にPrometheusをお使いのお客様も多いと思います。
Tanzu ObservabilityはPrometheusの運用で培った経験や資産を活かしつつ連携することができます。

2020-12-14T07-52-23.png

(PrometheusとTanzu Observabilityの連携)

連携を実現する一つ目の機能がPrometheus Storage Adapterです。この機能を使うことにより、PrometheusのデータをTanzu Observabilityに転送することができます。この構成のメリットは、オンプレミス側のPrometheusを小さくできることです。あくまで、オンプレミスのPrometheusをキャッシュストレージとして使い、データの長期保管をTanzu Observability側に任せることができます。(Tanzu Observabilityはデータを18ヶ月保管することができます。)

もう一つの機能がTanzu Observability上でのPromQLのサポートです。今まで使ってきたPromQLをベースとしTanzu Observabilityのダッシュボードやアラートの作成に使うことができます。なお、PromQL自体の知名度が高く、使っている方も多いでしょうが、最終的にはTanzu Observabilityが提供するクエリ言語であるWavefront Query Languageに移行することがお勧めです。この言語を使うことによって100を超える分析手法を中心にTanzu Observabilityの機能を全て使えるようになるためです。

さて、複数のPrometheusを一つのSaaSプラットフォームでまとめあげたとき、チームごとのアクセス管理が気になるかもしれません。もしかしたら、チーム間では見られて困るデータがあるかもしれません。この時に役に立つのがMetrics Security機能です。この機能によってPrometheusから転送されるデータそのものにユーザーアクセス制御ができます。こうして複数のPrometheusを1つのプラットフォームにまとめても、マルチテナントやユーザーアクセスを制御が可能です。

Wavefront Collector for Kubernetesによるデータ収集

Prometheusをまだ使っていない、もしくはTanzu Observabilityの使い方に慣れたら次に検討していただきたいのが、Wavefront Collector for Kubernetes を使って直接Kubernetesのデータを転送することです。

2020-12-14T07-58-54.png

(Wavefront Collectorを使ったTanzu Observabilityの直接連携)

この機能をお勧めする理由の一つが、Tanzu Observabilityのデフォルトのダッシュボードを使うことができる点にあります。このデフォルトのダッシュボードはクラスタ、ノード、ポッドなど階層化されたものになっています。それぞれのダッシュボードから気になる箇所をクリックしていき、ドリルダウンしていくことができます。
こうして、自分自身のKubernetesの環境を様々な断面で見ることができます。

2020-12-14T08-08-27.png

(Cluster, Nodes, Podのダッシュボードの遷移)

さらにはTroubleShootダッシュボードとよばれる問題解決に特化したダッシュボードを提供しており、Kubernetesの問題解決に役立てることができます。

2020-12-14T08-02-30.png

(TroubleShootダッシュボード)

また、お勧めする理由のもう一つが、Kubernetes以外のミドルウェアを観測するためのダッシュボードを提供している点にあります。多くのお客様ではKubernetesの上でApache, MySQL, Memcachedなどのミドルウェアを稼働させていると思います。前回の記事でも紹介したようにTanzu Observabilityは250近いインテグレーションを持っています。そしてWavefront Collectorはそれら対応したミドルウェアを自動的にディスカバー、つまり見つけ出し、メトリクスを収集することができます。そして、それらもまたデフォルトのダッシュボードを提供しています。こうすることで、Kubernetesだけでなく、ミドルウェアのレイヤーまで観測を広げることができます。

2020-12-14T08-00-53.png


(MySQLダッシュボード)

Wavefront Collectorのインストールですが、Kubernetesの標準的なデプロイツールであるHelmの他に、Tanzu Mission Control経由でインストールできます。Tanzu Mission Controlは(本記事では詳細に取り上げませんが)Kubernetesのライフサイクル管理を行うことができるSaaSプラットフォームであり、Wavefront Collectorを簡単にインストールするためのインテグレーション機能を提供します。以下の画面ショットにあるように、Tanzu Observabilityの認証情報(APIキー)を登録するだけで利用できます。こうすることでKubernetesのライフサイクル管理と、観測を同時に行うことができます。

2020-12-14T03-16-52.png

(Tanzu Mission ControlとTanzu Observabilityの連携)

さらにアドバンスに、Horizontal Pod Autoscalerとの連携


既に盛り沢山の内容ですが、最後にもう一つだけ機能を紹介します。それはHorizotal Pod Autoscaler (HPA)との連携です。

HPAとは、Kubernetesにおける自動スケリーング機能です。従来の自動スケーリングはCPUとメモリの消費量にしか対応していない、そして観測プラットフォームとは別のメトリクスをトリガーとする課題がありました。

2020-12-14T08-17-55.png

(Tanzu ObservabilityとHPAの連携)

Tanzu ObservabilityのHPA Adapterを使うと、CPUやメモリだけでなくTanzu Observabilityからの値で自由にスケーリングのトリガーを定義できます。さらには、WavefrontはAPI稼働率99.95%のSLAを保証しています。よって信頼できる観測基盤として安心してアプリケーションで利用することができます。

まとめ

以上、Kubernetesの観測基盤としてTanzu Observabilityを使うメリットを紹介させていただきました。
ぜひ、Tanzu Observabilityを使い、よりアドバンスなKubernetes観測に役立ててください!

関連リンク

【後編】モニタリングはもう古い?-Tanzu Observabilityのご紹介-

「モダンアプリケーションプラットフォームの可観測性」資料

「Tanzu Obseravability」の紹介資料

この記事の著者:星野 真知

ヴイエムウェア株式会社

10年以上のオープンソースを中心としたITソリューションにかかわる。
現在はVMwareでソリューションエンジニアとして、
Tanzuを中心とするモダンアプリケーション開発の支援をおこなっている。


DevOps Hubのアカウントをフォローして
更新情報を受け取る

  • Like on Feedly
    follow us in feedly

関連記事

このエントリーをはてなブックマークに追加

お問い合わせ

DevOpsに関することなら
お気軽にご相談ください。

Facebook、TwitterでDevOpsに関する
情報配信を行っています。