停止が許されないDX時代のITシステムを監視・運用するKubernetes

「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」というDXの定義のとおり、これから提供されるITサービスは利用者に必要とされ、生活に深く溶け込むものであることでしょう。しかしその反面、ひとたび停止すれば影響は大きなものとなります。よって、これまで以上に停止を回避する策が必要です。

システムの停止は、ビジネスへの多大なマイナス影響を及ぼします

  • ユーザーがサービスを利用できなければ機会損失、場合によっては補償の発生
  • 開発中に環境が停止すれば開発者待機の人件費、サービスインの遅れによる損失

DX時代のサービスは以前の考え方からするととてつもなく複雑で監視など成り立つのかと不安に思われるのではないでしょうか。

意外なことに「自律的なしくみ」の取り入れなどにより、これまでのような力を割かなくてもよい部分がでてきたりもします。

今回は理にかなった仕組みと新しい監視戦略をご案内いたします。

マイクロサービスの増加で監視は複雑化　より重要視されるObservability

Observabilityとは

Observabilityとは「システムを運用する上で、未知の動作を含め不具合の根本原因を特定、判断するために必要な情報（イベントログ、リソース使用状況、アプリトレース）が取得出来ている状態」

のことをいいます。

なぜ、Observabilityが必要か

まず、システムに対してObservabilityが必要であるもっとも重要な理由は、システムの停止が、ビジネスへの多大なマイナス影響を及ぼすためです。

システムがダウンするとユーザーがサービスを利用できないため、通常通り利用できる状態かどうかを監視する必要があります。

次に、システムに未知の動作や不具合が発生した際に、根本原因を特定し改善を行う必要がありますが、そのために必要なデータも取得、監視する必要があります。

また、マイクロサービスやクラウドネイティブなアプリケーションの台頭により、監視における複雑さが増したため、それに追従できるようObservabilityという概念はより一層注目されています。

Observabilityを実現するには、まず必要なデータを収集し、サービス提供のための目標値を設定します。次にユーザ体験を分析し、ビジネスへフィードバックするという流れで進めていきますが、今回は、このうち最初の「データ収集」部分について注目します。

Observabilityの３つの要素

Observabilityにおけるデータ収集では、下記の3つの要素があります。

  • Monitoring　CPU、メモリ、ディスク、ネットワークのリソース使用率等
  • Logging　OS、ミドルウェア、アプリケーションのログ
  • Tracing　アプリケーションのトレース情報（処理時間）

今回はこのうち主に、MonitoringやLoggingにフォーカスしたお話をします。

Kubernetesでのモニタリング これまでとの違い

コンテナを扱わずに従来のアプリケーションを普通に動かす場合は、物理ホストやVM、OS、ミドルウェア、アプリケーションといったレイヤーで構成されますが、Kubernetesの世界では、それ自身とコンテナという二つのレイヤーが単純に増えています。

そのためその二つ、コンテナレイヤーとkubernetesクラスタレイヤーについて監視を再考する必要があります。

「自由に激しく動き回る」コンテナのモニタリングについて

Kubernetesをはじめとしたコンテナで構成されたシステムにおいては、従来のシステムと違い、コンテナはイミュータブル(作成後にその状態を変えることができない)でありスケーリングも頻繁に行われます。

そのため、コンテナの削除や生成、増減が激しく行われる、という特性を持っています。

また可用性をもたせるために複数ホストで構成されるのが一般的ですが、スケーリング等のイベントが発生した際に、コンテナはそのホストの上を自由に動き回ります。

そのため、従来の監視戦略だと、移動するコンテナに追従してモニタリングが出来なかったり、全体で何が起きているかを把握することが困難です。

そのためコンテナに対してラベル付けを行い、激しく移動するコンテナに追従して監視し、アプリケーションに何が起こっているのかをモニタリングできるようにする、といったことが必要です。コンテナにつけるラベルは例えば、環境、アプリ、チーム、バージョンなどが一般的です。

また、コンテナ自体のCPUやメモリのモニタリングはそこまで重要ではありません。なぜならば、リソースが枯渇した場合はスケールするよう設定するのが一般的のため、CPUやメモリの使用率が高い事が、必ずしもサービスへの影響を引き起こすとは限らないためです。より重要なのは、ユーザー影響に直結するような、サービスのヘルスチェックや、レイテンシーを監視することです。

その他には、コンテナのファイルシステムの使用率については、枯渇するとEvict(退避)といってコンテナがダウンした状態になってしまうので、モニタリングを行うと良いでしょう。

「自律的な」仕組みを持つKubernetes自身のモニタリングについて

Kubernetesは大きく分けて二種類のノードで構成されており、一つはコンテナ同士の連携情報やコンテナの起動台数などを定義した設定情報を常時維持するようにコンテナの制御を行うMasterで、二つ目は実際のコンテナが動作するWorkerです。

また、Kubernetesでは、一つもしくはそれ以上のコンテナをPodという単位にまとめて扱います。


また、Kubernetesの特徴的な仕組みの一つとして、自律的な仕組みが挙げられます。

例えばPodが停止した場合、それをMasterの中のControllerが検知し設定情報の通りに修復が行われるように、自律的な仕組みで動いています。

そのため、今までのオンプレミスのような考え方で、Kubernetesやコンテナの全コンポーネントを全て監視する必要は必ずしもなく、Kubernetesの自律的な仕組みを担っているMasterの各コンポーネントが正しく動いているかどうか、を監視することが重要です。

たとえば、Masterが正しく動いているかについては下記が挙げられます。

  • Masterのコンポーネントプロセスは起動しているか
  • Masterのコンポーネントの動作ログでエラーが発生していないか
  • Masterのコンポーネントの処理レスポンスは遅延していないか

今回は簡略化した図でご説明しましたが実際のMasterノードにおいては、たくさんのコンポーネントが動いています。例えば、

  • Kubernetesを操作する際に使われるAPI Server
  • 設定情報を蓄積する複数台のetcd
  • Pod等をコントロールするControllerManager
  • WorkerへPodを配置指示するScheduler

等です。これら全てについてのプロセス監視はもちろんのこと、どのようなエラーログが出れば異常なのか、どの程度の処理レスポンスを異常とみなすのか、それぞれ正常に動いているかどうかを定義し運用していく必要があるため、自らMasterを運用していくには多くのノウハウが必要となります。

幸い世の中のパブリッククラウドにおいては、マネージドのKubernetesサービスが提供されているため、それを利用する場合は、このようなMasterの運用は必要ないため、Worker側つまりコンテナやアプリケーションに専念することが出来ます。

モニタリングのヒント：ラベルの付与　おすすめのツールやサービスは？

先に説明した通り、コンテナは激しく増減、移動するためラベルを付与することと、そのラベルベースでのモニタリングできる仕組みが必要となります。

具体的なツールやサービスは、CNCFのLandscapeの中にラインアップされています。

OSSであればPrometheusとGrafanaを組み合わせて実現したり、SaaSであればDatadogやSumologic等でKubernetesの監視を行うことが出来ます。

*弊社は企業向けに導入コンサルティングもさせていただいています。詳細はこちら

運用部隊を疲弊させず重点的に監視すべき大事な指標とは？

モニタリングする対象や、モニタリングの方法が決まった後に、次にその運用を考える必要があります。

一般的にモニタリングするメトリクス(定量化した数値)は、3種類に整理ができます。

  • Work Metrics　正常動作しているかの指標
  • Resource Metrics　リソース使用率等
  • Event　スケーリングイベント、動作ログなど

全てを監視、通知するのでは、運用部隊が疲弊してしまうため、Work Metricsをきちんと定義してそれに対して適切に通知、対応を行う運用を考える必要があります。

具体的なWork Metricsは、例えばKubernetes自身のモニタリングでいうと、自律的な仕組みを支えるコンポーネントの異常として、etcdクラスタ内のコンポーネントが正/副で構成されているべきところを、etcdの正コンポーネントが選出されていない状態であったり、API Serverのリクエストキューが溜まっている状態などです。

またコンテナのモニタリングにおいては、例えばファイルシステムが枯渇している状態であったり、ヘルスチェックが異常な状態などを指します。

また、他のメトリクスについては、モニタリングしなくていいということではなく、運用部隊への通知は必要なくとも、定期的にリソースの見直しを行うためにも、ResourceMetricsやEventはモニタリングしておく必要があります。

一般的には、各メトリクスに対して、重要度ごとに３つに分けて運用すると良いでしょう。

  • None 監視設定はするが、通知はしない
  • Info　監視設定を行い通知をするが、急ぎではない
  • Alert　監視設定および通知を行う。即対応が必要なもの

まとめ

  • Kubernetesは監視するレイヤーが増えるため、監視戦略を再考しましょう
  • コンテナに対しては適切なラベルを付与すること、そしてそのラベルを追従できるモニタリングツールの選定が必要です
  • マネージドのKubernetesサービスを利用しない場合、Masterの運用は注意が必要です
  • Kubernetesにおけるメトリクスはレイヤーが増えた分、数が多いですが自律的な仕組みで動作するという特徴もあるため、それらを意識して監視設計を行いましょう
  • 各メトリクスに対しては、正常に動いているかどうかの定義や、対応の優先度付けを行い、どのような状態になれば通知あるいは対応が必要なのかを、きちんと設計して運用することが重要です

※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。

関連サービス

関連記事一覧