毎月40万部を超えるアンケートデータを収集しているopensurveyは、データベースサーバーの移行により発生した問題の解決に>WhaTap Monitoringを活用しました。

Q）まず、opensurveyについて紹介してください。

A）opensurveyはモバイル向けのリサーチを中心に、多彩な消費者データを収集・分析している会社です。ビジネス意思決定に悩まされる企業側へ有意義なインサイトを提供しています。他のリサーチ企業との差別化ポイントは「技術」にあります。opensurveyは時間や空間上の制限なく、いつ、どこからでもアンケートへ参加できるモバイルパネルを20万人確保しています。それに、パネルを絞ってアンケートが実施できる技術を持っています。性別、年齢、地域人口分布に比例したパネルをランダムに抽出してアンケートを実施することができます。または、最近3か月以内に割引チェーン店で5千円以上の買い物をした消費者だけを選別してアンケートを送ることも可能です。

このようなデータ収集に加え、opensurveyは莫大なデータから意思決定のためのインサイトデータを導き出すデータ分析・運用へも力を入れています。

Q）opensurveyでどのような業務に就いていますか？

A）opensurveyは蓄積したアンケート結果データを活かして、データ提供プラットフォームを開発・運用しています。例えば、消費者の消費パターンを分析した献立データの定期配信サービスがあります。また、企業側が自社顧客を対象にCXデータを収集・分析できるSaaS型サービス等を運用しています。ここでプラットフォームの開発と運用といったDevOps業務を任されています。

opensurveyでバックエンド開発を担当するPark Hyunminさん（左）と、データサービス開発を担当するLee Donghoonさん（右）

Q）WhaTap Monitoringを選択したきっかけは何でしょうか？

A）opensurveyの製品開発グループには、スキルの高いメンバーが多くいます。会社ではこのようなメンバーが自らの業務により集中できるよう、システム運用、トラブルシューティング等はできる限りツールやサービスに任せたいと思っています。DevOpsのためのモニタリングサービスを選定する際にはWhaTapの他にも韓国内のAPM業界で長くやっているJ社と、グローバルサービスのD社も一緒に検討しました。 まず、J社の製品はオンプレミス型だったのでやめました。D社の場合はマイクロサービスアーキテクチャ（MSA）のトポロジーに優れていましたが、opensurveyにとっては2％程足りなかったような気がします。障害発生時にはどんな状況なのかをより早く、的確に把握しなければなりません。しかし、そのために色々な機能をすべてを確認する必要はありません。機能が多すぎて逆に使いづらかったです。それに比べて、WhaTapはリアルタイムで障害状況がすぐ把握できたので導入しました。

Q）最近クラウド転換作業があったそうですが、移行作業の過程でWhaTap Monitoringは活用できましたか？

A）2021年の下半期、クラウド移行作業の過程でWASとDBのゾーンが別になった時期がありました。従来はKTクラウドに一部のWASとDBが置いてあったのですが、DBだけをAWSへ先にマイグレーションしてから障害が発生してしまいました。

原因を調べたところ、DBのクエリ件数が多すぎたため発生した問題でした。問題をトレースする過程でWhaTap Monitoringが役に立ちました。ログ分析時にクエリ件数で並べ替える機能がありますが、同じゾーンならレスポンスタイムが短くて引っかからないのが、ゾーンが違うとクエリ件数が増加することが確認できました。WhaTap Monitoringではクエリ件数が見えるため、どこのエンドポイントが問題なのかが分かります。

DBクエリは、アプリケーションサーバーと同じゾーンにあったらRTT（ラウンドトリップタイム）が短いわけです。DBゾーンを移転してからアプリケーションサーバーとのゾーンが別になったせいで、レイテンシが1msから6msに伸びました。1クエリ当たりのレスポンスタイムとしては1msと6msは大した差ではありませんが、クエリが数百万件を超えたら相当な問題を引き起こす原因になったのです。1クエリ当たりのレスポンスタイムが短く、リソース使用も少ないためにDB slow queryとリソース使用量などの指標には引っかからない状況でした。WhaTap Monitoringでなかったら、原因究明に相当な苦労をしたのではと、ホッとしています。