5年目の常連客であるBalanceHeroのWhaTapの使い方

ITインフラ状況について教えてください。

チャン・ギルスさん（以下、ギルス）： AWSでインフラ全体を構築しています。インドでサービスをしている会社なので、韓国地域にはサーバーがなく、インド地域に主要サービスが集中しています。DRを除いてAWSを利用しています。

WhaTap導入の背景について教えてください。

ギルス： 弊社がWhaTapを導入したのは5年前です。その当時、WhaTapサービスも始まったばかりのサービスだったと思います。弊社も他のAPMを使った経験がなく、少しは簡単で軽く始めるAPMが必要でした。ちょうど当時、WhaTapは初期だったからかもしれませんが、インストールが簡単で必須機能だけ特別な設定なしに見ることができた簡単な製品でした。私たちの目線に合った製品で、初期に積極的にサポートしてくれました。

他の製品と比べて、メリットについて教えてください。

ギルス： DBの場合、基本的なセットアップが全部されているので、インストールさえすれば設定しなくてもモニタリングできるのが一番便利です。その次に、エージェント方式はユーザーによって異なると感じることもありますが、特に技術を使わなくても単純にエージェントをインストールしてDBを接続するだけでほとんどのモニタリング収集ができ、その次にWEBページを通じて必要なグラフが一度に出てくるということ。簡単に言うと、インストールが簡単で容易に使用できるんです。他のAPMの場合は、インストールからセットアップまで方法が難しく、特にインストールは簡単ですが、セットアップが難しいです。自分がしたいことをするにはメニューも多すぎるのですが、WhaTapの場合はインストールから構成、つまりモニタリングのインストール過程を私が何も知らない状態でしても、全部終わるまで約30分〜1時間以内だったと思います。

ハン・ダウィさん（以下、ダウィ）： 私はAPMを使う時にデモ (Demo) は使ったことがありますが、実際に他のAPMは使ったことがありません。ですが、他の製品のデモで困難に直面することが多かったです。なぜなら、設定したら膨大すぎて、詳細に何かをしなければ望む結果を得ることができないからです。ですが、WhaTapを私も3〜4年ほど使ったのですが、初期にはほとんど設定がなく、変更できる設定があまりありませんでした。最近はWhaTapも機能が多くなって、少し難しくなりました。それでも相対的に楽じゃないかなと……D社やE社のAPMなどに比べて簡単にアプローチできると思います。

WhaTapのサービスの画面の中で一番よく見る画面はありますか？

ギルス： DBではインスタンスモニタリングページとフレックスボード、ほとんどグラフ中心のサービスをよく見ています。その次に、インスタモニタリングにアクティブセッションが表示されますよね。リアルタイムでクエリが処理されているのが出てくるのを一番よく確認します。

ダウィ： Application Monitoringでは、ヒットマップをよく見ています。ヒットマップのパターンについて慣れてくると、これがどんな問題なのか少し把握しやすく見えるんですよ。例えば、3秒台の赤い線がずらりとかかっているとします。それに対するthreadがどこにかかっているのか把握しやすいので見ています。その上にいろんなキューが、以前の私たちだと見落としてしまったものがキューブに保存されているものがあるので、そのキューブを開いて内容をもう一度見て、合うパターンをもう一度把握し、パターンによって引き起こされる問題にトラッキングしやすいので、そういうものを見ています。

Server Monitoringは最近になって使い始めました。私たちはServer MonitoringとしてZabbixを使っていましたが、Zabbixは特定の時点を決めてどのプロセスがどのようにCPUを使用したのか、あるいはメモリをどのように使用しているのかを確認するのが容易ではありませんでした。ZabbixやRedisなどのモニタリングは確認が難しいです。しかし、WhaTap　Server Monitoringは、サーバーリソースの使用量をhistoricalに残してくれます。また、それぞれのプロセスで使用中のCPUやメモリを確認することができるので、よく見ています。例えば、WhaTapでは、Javaで運用中のアプリケーションが全体のCPUやメモリのうち、どれだけのリソースを使用しているか把握できます。

WhaTapを利用しながら問題を解決した経験はありますか？

ギルス： 最近大きな障害はないので、障害対応をしたというよりは、普段問題が発生した時、問題をトラッキングした時にインスタンスモニタリングをよく確認します。P社もD社も、どのAPIを見てもインスタンスモニタリングをする際は、グラフ中心が多いです。

もちろんクエリを見ることもできますが、WhaTapの場合はインスタンスモニタリングのTotal runtimeを押すと、グラフと一緒に実行されたクエリが表示されます。クエリと関連のない数値が上がると、クエリの問題ではなく、他の問題が発生したと一度に把握できます。なので一度に一緒に見られるのがメリットだと思います。XOSをインストールするとプロセス情報も表示され、ロック情報とDBに関する情報を1ページで見ることができます。スロークエリが大量に入ってきたり、あるクエリに変更によるロックがかかっている場合、そういうことをいろんな関係で把握しなければならないので。大量の大きな障害になる前にマイナーな状態で見て、素早く判断して処置できるように確認し続けています。事実上、DBは一度障害が出ると大きな障害じゃないですか。だから、その前に事前に把握して措置を取らなければならないので、リアルタイムでずっとモニタリングしています。

使用しながらどのような機能が一番役に立ち、WhaTapを使って障害や問題を解決したことはありますか？

サービスの中心でgatewayの役割を果たしているプロセスのアクティブトランザクションとヒットマップが非常に役立ちました。大規模な障害（全体サービス停止）に真っ先に気づくことができたからです。どのトランザクションで遅れているかを把握し、原因を追跡して問題を解決することができて役立ちました。そして、それぞれのClassに対してトランザクションエラーに対するStatisticsを提供していますが、一部障害（一部サービス停止）が発生した場合、開発者がError Logを残さないため、症状を把握することができませんでした。WhaTapのメニューを通じて症状がわかるようになり、問題の原因を見つけて解決することができました。

サーバー配布時に発生した問題は警告通知で確認します。

ギルス： DBの場合、WhaTapの警告通知をSlackで受信しています。問題が発生した時はSlackで確認するので、モニタリング画面を注視しているわけではありませんが、24時間モニタリングしているのと同じです。

ダウィ： Application Monitoringの場合、結構よく見ています。システムの性能も見ていますが、APIの指標やエラーを収集するためにも見ているんです。どんなパターンでどのように起こっているのか、弊社のサービス自体がインドのサードパーティーなので、連携すると何時間もインドで障害が発生した場合、タイムアウトがかかることがよくあるんですよ。弊社は配布がほぼ毎日あるので、その時間帯は絶対に見ています。私以外の他のエンジニアが配布しても私はずっとモニタリングしているので、一日平均3〜4時間は見ていると思います。私も通知はSlackで受け取っているので、警告通知が届いたらすぐに確認しています。

BalanceHeroがお勧めする3つの機能

DPMでよく見る機能

- フレックスボードとヒットマップトランザクションを最もよく活用します。

- エージェント方式はユーザーによって異なりますが、エージェントインストールからDBを接続するだけでほとんどのモニタリングが収集され、関連するグラフが出てきます。簡単に言うと、インストールが簡単で容易に使用できます。

- DBに異常なクエリや流入量が発生した場合、大量の外部流入によって発生するのか、内部配置なのか、特定のAPIで発生させたのかを確認するために、複数の指標を一緒に見ながら把握します。

APMでよく見る機能

- ヒットマップを一番よく見ています。直観的に現在の状態を見ることができて良く、障害パターンを通じて原因の把握と類推に役立ちます。

- キューブ分析を通じてCPUとメモリを基準に数値を把握して見落としたパターンを再び把握し、発生する問題をトラッキングしやすかったです。

気になることはリアルタイムで解決！

ギルス： チャンネルトークの場合、リアルタイムで詳細な返事が届きました。そして、解決されていない部分はメールでエンジニアとすぐに繋げてくださって、返事も詳細でした。テクニカルサポートサービスの場合も、サポートもとてもよくしていただいて満足しています。

シリーズB投資を誘致したスタートアップなら？

ギルス： スタートアップ企業の場合、十分に試してみる価値があると思います。モニタリングは何を使えばいいか悩むと思いますが、複雑に大規模なAPMよりは、気軽に始めやすいWhaTapをお勧めします。複雑ではなくシンプルでサポートサービスもとても幅広く、親身になって対応してくれます