クラウド

“クラウド”と聞くとどんなイメージですか？
私はクラウドとは、単語の意味からして「雲」或いは「実際に存在するけれど触ることができない物」のような感じがします。だからこそ、クラウド環境が国内で本格的に普及できるか疑問に思っていました。

Kubernetesが登場する前

ユーザのクリティカルな情報を外部に保存するパブリッククラウドの場合、国内の金融機関での導入は非常に難しいと思います。

ハイブリッドクラウドの概念の登場

しかし、Kubernetesの登場で企業が構築したプライベートクラウドとパブリッククラウドの両方を使用するハイブリッドクラウドの概念が登場すると、選択的なデータ隔離が可能になりました。これにより大半の企業はKubernetesを利用したクラウド環境への移転を少しずつ進めています。
個別インスタンスのリアルタイムモニタリングに強みがあるJENNIFERもこのような変化に対応するため、新しい観点のモニタリング方法を検討しています。

既存のモニタリング方法の限界

クラウド環境でもモニタリングの核心は、個別インスタンスとトランザクションのリアルタイムモニタリングであることは変わりがありません。JENNIFERはクラウド環境でも簡単にインストールできる方法を提供し、既存のものと同じモニタリング経験を提供します。

新しいモニタリング方法が何故必要か？

私は偶にユーザを訪問することがあり、ユーザ毎に異なる多様な使用パターンと悩みを見聞きすることがあります。
ある時、ユーザのダッシュボードで異常な状況を確認しました。

この数字で表現された形態のチャートはアクティブサービスチャートです。

ユーザのアプリケーションは大量のインスタンスで構成され、業務を表す多数のドメインをドメイングループに設定して運用しています。ドメイングループを選択してモニタリングする過程で、一つのチャートに多数のインスタンスがモニタリング対象になり、表したいデータを適切に表現できていません。

JENNIFERはリアルタイム情報を円滑に把握するために、ドメイン毎にインスタンスの数を100以下に維持することを推奨しています。しかし、複数のドメインを束ねたドメイングループの観点でモニタリングする場合、この例のように大量のインスタンスが一つのチャートに現れる可能性があります。

Kubernetesの導入でアプリケーションのオートスケールが行われることで、このような状況が頻繁に発生することがあります。

改善方法はないか?

前述の例のように一つのダッシュボードで多数のインスタンスを個別モニタリングすることは現実では不可能です。

勿論、特定条件を満足する特定インスタンスのみを選択し、表示するフィルタリングでモニタリングを提供できます。

しかし、このような方法も次の様な限界があります。

• ダッシュボードに表示される対象が頻繁に変更されることで、ユーザが混乱する。
• 問題があるインスタンスは、他の問題があるインスタンスに比べ優先順位が低くなることで、認知できなくなる可能性がある。

JENNIFERは限界がある方法を提供する代わりに、モニタリングの観点を変えることにしました。

基本に立ち返る

JENNIFERの全てのダッシュボードと分析機能は最小モニタリング単位がインスタンスになっています。

決まった数のインスタンスで業務が運用される場合、問題の原因となるインスタンスを素早く識別して、問題を解決することが重要であるため、JENNIFERの強みが現れる部分です。

個別インスタンス単位の問題の把握が必須

このような個別インスタンスのモニタリングの重要性は、水平展開が簡単であり現時点でも有効です。インスタンスが多くなったとしても、問題解決のためには個別インスタンス単位の問題把握が必須です。

クラウド環境でモニタリングする時に、難しい部分は問題認識で、その原因は既存とは異なるモニタリング対象の数です。

制限されたインスタンス数から可変的で制限がないインスタンス数

無理して大量のインスタンスを既存の方法でモニタリングできるようにダッシュボードの性能を改善できても、その結果はユーザが期待したものではない可能性があります。(前述の[図1]参照)

問題があるインスタンスを確認して、そのインスタンスが実行したアプリケーションで遅いトランザクションを確認します。つまり、問題把握の最終対象は“アプリケーション”です。

であれば、個別インスタンスの状態を表示する方法ではなく、問題把握の対象のアプリケーションを中心にモニタリングをすることはどうですか?

新しいダッシュボードの必要性

アプリケーションが中心のモニタリングのためには、既存のJENNIFERダッシュボードの再構成だけでは不十分な部分があります。

例えば、インスタンス単位のモニタリング要素を除去すると、リアルタイムモニタリングで重要なアクティブサービス情報を表示できない問題が発生することがあります。また、問題があるトランザクションを認知して処置を行うため、設定管理画面でそのインスタンスを探す手間がかかります。

このような問題を解決するには、問題の認知と分析だけでなく、解決のための処置までできるダッシュボードがあるべきだという考えに至りました。

それがリアルタイムでアプリケーションの問題を認知して処置できるアプリケーションインサイトです。

詳細内容は JENNIFER AI、アプリケーションインサイトでリアルタイム問題分析 ドキュメントを参照してください。

多数のインスタンスで構成された業務をアプリケーション中心のチャートで構成後、アプリケーションインサイトと統合すると、次のような効果が期待できます。

• オートスケールによるインスタンス数の変化に制約なく問題を認知できる。
• 問題の現象を認知後、分析画面を移動なく問題の原因を把握できる。
• 原因を把握した後、素早く処置できる。

上記のようにモニタリングの全般的な過程を実行できるオールインワンのダッシュボードを考えました。

アプリケーションインサイトダッシュボード

新しいダッシュボード名はアプリケーションインサイト

前述のJENNIFERの機能ですが、問題の認知、原因把握に特化した機能であるため、クラウド環境のモニタリングを提供するダッシュボードの名称として適切だと思います。
既存のJENNIFERダッシュボードは、個別インスタンス単位のアプリケーション性能モニタリングをメインとしていて、一方、アプリケーションインサイトダッシュボードはインスタンス数の制約なく、選択したドメイン(業務)単位でアプリケーションの性能をモニタリングするダッシュボードです。

アプリケーションインサイトダッシュボードでは、JENNIFERで初めて導入した幾つかのチャートが含まれています。ダッシュボードは包括的な問題の認知から始まり、詳細の分析へ続くようにチャートが配置されています。

問題の認知

上記にあるように、急激な負荷の増加でオートスケールによりインスタンス数が増加する場合、既存のアクティブサービスチャートでは個別インスタンスの状態を把握することが難しい場合があります。

下記の例ではインスタンスの数を何とか認知することが可能な程度ですが、複数のインスタンスで同時に遅延が発生する場合、インスタンス別にアクティブサービスの詳細情報を確認するには、非常に手間と時間が掛かります。

個別インスタンスの状態を把握することより、サービスの全体の観点で問題を認知することが重要であれば、全体的なアクティブサービスを要約して視覚化することが効率的だと思います。

JENNIFERで新しい方法のアクティブサービスモニタリングのために開発した“アクティブアプリケーション”チャートを確認します。

JENNIFERダッシュボードの全てのチャートで赤は、障害または性能低下の危険性をアラートすることに使用します。このチャートでも同じく赤を中心にモニタリングすることになります。もう少し詳細に説明します。

上記のチャートはアクティブサービス要約情報の平均応答時間をX軸で、リクエスト数の合計をY軸で設定後、アプリケーションを円で表現します。

アプリケーションを表す円の色とサイズは次のことを表しています。

ここで遅いリクエスト数とは、アプリケーションの平均応答時間がアクティブサービスの全部で4つの区間の中で、最後の区間に該当するリクエスト数の合計を意味します。

• 色
  • 🔵青
    • ・正常状態
  • 🔴赤
    • ・アプリケーションの平均応答時間がアクティブサービスの最後の区間に該当する場合(ここでは8秒以上)
    • ・アプリケーション別要約情報を構成するアクティブサービスの中の一つでもアクティブサービスの最後の区間に該当する場合
• サイズ
  • 遅いリクエストの数に比例して大きい

このように色とサイズの条件を利用して平均することで、表すことができない遅いアクティブサービスを確認できるようにします。また、ユーザはアクティブアプリケーションチャートに確認できる赤い円をクリックするか、ドラッグするだけで、遅延中のアプリケーションを素早く確認できます。

以降は、第2回に続きます。