検索
連載

死活監視、ロギング、メトリクス――Kubernetesと監視の話：マネージドサービスで始めるKubernetes入門（5）（2/2 ページ）

AWSが提供するマネージドKubernetesサービスの「EKS」を用いてアプリケーションを公開する方法を紹介する本連載。最終回は、Kubernetesでアプリケーションを公開後に必要となる「監視」について。

[上野一義，株式会社PIVOT] PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

メトリクスを活用して知りたいことが分かる設計をする

　知りたいことは、任意の瞬間において「システムで何が起きているのか？」であり、それらの「知りたい項目」がユーザーにとってハッピーかどうか？の指標になっているのかです。

　では「知りたい項目」とは、どのように決定すればよいのでしょうか。今回は、「REDメソッド」というものを紹介します。

　REDメソッドは、「Google Analytics」のSREであったTom Wilkie氏が提唱しているもので、以下の3つのメトリクスを指します。ちなみにREDは「Request」「Errors」「Duration」の頭文字を取ったものです。

（1）リクエスト率（％）：1秒当たりのリクエスト数
（2）エラー率（％）：エラーを返したリクエスト数
（3）レイテンシ：リクエストの持続時間

　例えば（1）のリクエスト率を監視することでトラフィック量を把握できます。この値が上昇している時は「アクセスしているユーザー数が増えている」とポジティブに捉えることも可能ですし、「データベース障害によるリトライが多数発生している」という予想も立てられます。

【ミニコラム】ユーザー視点のカスタム監視も大切

　「アプリケーションの応答」「ログ」「メトリクス」の組み合わせだけで安心してはいけません。ユーザーがサービスを通じてハッピーな状態に持っていけるようにするためには、ユーザーと同じ環境で監視をする必要があります。

　障害は必ずしもシステム内部で起きるとは限りません。ユーザーがサービスに到達するまでには、そのシステムの手前にルーターやファイアウォールなどのネットワークが存在します。システム内部の状態を監視していてOKであったとしても、システム外部障害が原因でサービス障害と見なされることもあります。ユーザー視点での監視を実施するには、システム外部からの監視も必要です。

　またユーザー視点での不具合を検出するためにアプリケーション自体に監視のための機能を追加する必要がある可能性もあります。例えば「会員ログイン機能が正しく動いているか？」を検出するためにHTTPステータスコードとは別に、テストユーザーなどによるログインとログイン後のページに任意の文字が存在しているか？　をチェックできる機能などです。


Kubernetesのメトリクス項目

　ではKubernetesのメトリクスとしては、どんなものがあるのかを確認してみましょう。

　Kubernetesのメトリクスは大きく分けて3つの観点があります。これらを参考に不足があれば、必要なメトリクスを追加し組み合わせて設計にトライしてみてください。

1.クラスタの健康状態の指標

  • ノード数
  • 各ノードのステータス
  • 各ノードのPod数
  • 各ノードのリソース使用率

　本連載で紹介したAWS EKSの場合、ノード自体に障害が起きてダウンした場合は、EKSが自動的に復旧します。そのため、AWS EKSを利用する場合、ノード数はあまり有用ではないかもしれません。

2.Deploymentの指標

  • Deployment数
  • Deploymentごとのレプリカ数。または利用できないレプリカ数

　Deploymentレプリカ数の監視でクラスタのキャパシティーが不足しそうになったり、既に不足したりしている可能性を知ることができます。

3.コンテナ単位の指標

  • ノード当たりのコンテナ数またはPod数
  • 各コンテナまたはPodの再起動回数
  • コンテナのLivenessまたはReadiness状態
  • 各コンテナのリソース使用率
  • 各コンテナのネットワーク入出力トラフィックおよびエラー

　コンテナの指標は、1.と2.よりも細かい観点になります。コンテナ内は、ほぼサービスに直結したアプリケーションになるため、これまでKubernetesクラスタ以外でコンテナを利用した方にとってはイメージしやすいのではないでしょうか。

　なお、こうしたメトリクスを収集する方法としては、以下のようなサービスが知られています。

  • 「Amazon CloudWatch」（AWS EKSを利用している場合）
  • 「Prometheus」
  • 「Datadog」
  • 「New Relic」

留意点と、この先について

　かなりざっくりと監視についてまとめてみました。監視は非常に領域が広く、今回述べたことは入り口に過ぎません。例えば、アラートの方針（いつ、誰に、どの監視をどのようなアラートで？）やアラートの閾値を決めるためのメトリクスの分析など、考えなければならないことはまだまだあります。

　また「システム内で何が起きているか？」を得られるという点でメトリクスの有用性を紹介しましたが、むやみに取得するところから始めてしまうと情報が多すぎてしまい逆効果になってしまう可能性もあります。

　「何が適切なメトリクスなのか？」をチーム全員で考えることも大切です。監視の仕組みを構築するのはエンジニア側であるがゆえに、エンジニアだけに監視を任せる傾向が多いかもしれませんが、「ユーザーがハッピーか？」という観点は、ITサービスを通じて価値を提供する企業に勤める誰もが持つべきだと考えています。

まとめ

　全5回にわたってAWSが提供するマネージドKubernetesサービスの「AWS EKS」を用いてKubernetes環境の構築からアプリケーションの公開までを紹介しました。最終回は、Kubernetesを通じてアプリケーションを公開した次に必要な監視の話がメインだったので、不明点もあったかもしれません。しかし、これらはアプリケーションをKubernetesで運用していく上で必要な知識の一つです。本連載を通じて少しでもKubernetesに対するイメージや、Kubernetesの活用に向けて必要な知識の明確化につながれば幸いです。

筆者紹介

上野一義

株式会社PIVOT R&D Div. テクニカル・アーキテクト

株式会社PIVOTは、企画、Webサイト構築〜運営支援、アプリ開発、システム開発まで、UIを中心にしたモノづくりでユーザー体験を追求しているデザイン会社。自身のIターンに伴い、福岡オフィス立ち上げメンバーとしても従事。

得意な言語

Elixir, Swift

活動来歴

  • 元GraphicDesigner
  • openFrameworks.jp 翻訳メンバー ※現在は休止
  • ElixirConfJP 2019 LT登壇

インタビュー

SNSなど


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る