コストを約2万倍以上削減したTESTWORKSのAPM活用法

TESTWORKSとTESTWORKSが運営しているサービスについて紹介してください。

TESTWORKSは、技術基盤の成長とともに社会に貢献できる業務を遂行している業界唯一の人工知能データおよびソフトウェアテスト専門スタートアップです。弊社は、第4次産業の中核となる人工知能データセットの構築と自動化プラットフォームの技術力に多様な階層の強みを生かし、インクルーシブ雇用の機会を提供しています。

現在、弊社では5つのサービスを開発および運営しています。クラウドソーシング方式の人工知能学習用データ収集加工専門プラットフォームaiworks、データの効率的な自動化－加工－管理のためのblackolive、エッジコンピューティング技術を基盤により早く必要な画像と映像データを収集できるEdge AI、弊社だけの技術でデータの品質検証に最適化されたサービスADQ、遠隔で半導体開発に必要なCI/CT/CD体系を構築できるTedworksを開発および提供しています。

TESTWORKSの開発環境はどのように構成されていますか？

運用環境と類似した環境をクラウドに搭載し、構成管理とピアレビューを通じたブランチ戦略ベースの配布環境と通常2週間単位のスプリント開発目標の日程と品質管理を行い、すべての段階別進行状況をリアルタイムでコミュニケーションを取り問題発生と解消のための協業環境に重点を置きました。開発環境もAPMを適用し、単位テスト中に先に識別可能な危険要素を除去するために努力しました。

モニタリングの導入前に、どのような課題があったのか教えてください。

第一に、サービス開発にもっと集中しなければならない時だったので、サービスのアーキテクチャまで考えにくい構造です。また、SQLを使ったとしてもサービスを早く開発して配布しなければならないため、性能まで考慮しにくいということでした。

第二に、性能改善をするためにモニタリングサービスを利用しなければならないということ自体に対する認識が不足していました。「彼を知り己を知れば勝乃殆うからず」という言葉があります。すべてのサービスは週末もサービスが続いていますが、障害が発生すれば障害箇所を素早く見つけて解決しなければなりません。モニタリングがこのような役割をしますが、もしモニタリング自体を知らなければ、障害箇所を探すのに時間を浪費してユーザーが離脱してしまう可能性があるという問題に直面しました。

最後に、モニタリングで問題を解決する前に、スムーズなサービスのためのチェックポイントを確認しました。コストと増設で比較的早く解決できるサーバー、ネットワークとユーザーのPC、ユーザーの使用レベルなど、開発ではできない部分を除外しました。モニタリングでサービスのどの箇所に問題があるかを識別できる領域は、サービスアーキテクチャ、サービスプログラミング言語の活用、データベースSQLの活用、アプリケーションでした。

＜接続時間短縮＞

接続するのに3秒以上かかる場合は改善対象だと考え、WhaTap Application Monitoringが提供するヒットマップダッシュボードを確認しました。3秒と指定した理由は、ユーザーが離脱を決心するのが通常3秒以上のため、基準を定めました。その結果、3秒から80秒まで大多数が存在したことを確認でき、この程度では実際のサービスが難しい状態だと判断しました。

次に、サービスへの接続を阻害する要素を調べるために、TXプロファイルチャートを確認しました。正常なサービスにおけるサーバーの負荷を誘導する内容を識別することができ、50秒以上だったFront Read I/OとSlow SQLが問題でした。

識別した後にSQLを調べたところ、使わない7百万件のSQLを照会してサーバーが死ぬ現象が発生していました。これを改善するために、SQL実行時に正確に必要な母集合に範囲を制限しました。変更前は7百万件だったSQLを、たった280件に減らしました。これは1/25,000レベルです。

これらの要因により、サービスの読み込みが遅くなるだけでなく、JVMの使用可能なメモリを過度に使用し、サーバーが動作しない問題まで同時に発生しました。モニタリングで発生した問題を解決することで、従来は10秒から80秒までかかったSQLのロード時間が150msに減りました。50秒以上だったFront Read I/Oを、サーバーリソースを使用しないようにGoogleのCDN I/Oを利用するように変更し、サーバーの負荷を根本的に取り除きました。

＜サービス遅延パターン＞

3秒以内で反応する正常なサービスなら、ヒットマップは下に点があるパターンのようにならなければなりません。しかし、ある瞬間から横、縦のラインなどの異常なパターンが見えてきました。このようなパターンがなぜ急にできたのかヒットマップを見て、3秒以上応答するトランザクションはサービス不能なので処理し、そのトランザクションに対処しました。

＜サービス不能の改善＞

サービス不能を改善したケースです。サービス不能とは「サービスができるわけでも、できないわけでもない」状態を意味します。スケールが80秒まであり、最大300秒まで読み込まれる状況で、ユーザーの立場ではサービスに全くアクセスできない状態でした。モニタリングを通じて、5段階に分けて問題を解決しました。

• まず、どのような要因が私たちのシステムに影響を及ぼすのか、1、2位の要因から取り除いてみようと優先順位を決めました。
• 必要なデータのみ必要時に照会しなければなりませんが、このシステムは使用していないデータによるシステム不能を示す現象を発見しました。不要なデータまで照会される部分を改善しました。
• 一つのアプリケーションを呼び出す時、最大1万5千SQLが呼び出され、Round Tripが発生したりもしました。アプリケーションを呼び出す際に一度に照会できるように、Round Tripを削除することも一つの目標になりました。
• 徐々に増えるデータを必要なだけ照会できるようにAJAXフィルタリングを設定しました。
• あるアプリケーションは、サーバーに接続する前にあらかじめ確認し、SQL実行前に権限をチェックできるようにアーキテクチャを改善することにしました。

＜ソースコードの改善＞

ソースコードから不要なSQLを削除しました。また、全体の照会を防止するようにSQL文を改善しました。以下の結果のように、インスタンス応答時間、SQL、トランザクションSQL応答時間など、改善前と比べると、各領域別のチャートを見ても明らかに違いがあることが確認できます。

このようにモニタリングを通じて同時接続ユーザー数が5人であるにもかかわらずシステムが不能状態だったとすれば、今の場合は同時接続ユーザー数が140倍以上増え、世界中から接続してもトランザクションの99.9%が3秒以内に正常に応答することをWhaTapのヒットマップで確認することができました。

WhaTapのモニタリングを一文でどのように表現できますか？

昨日より良い今日、今日より良い明日を作ると思います。特に、スタートアップが危険にさらされないためには、モニタリングは選択ではなく必須だと判断されます。

個人的に、情報システムを一度に良くするのは難しいことだと思います。特にスタートアップでは事業や機能開発もしなければならず、サービス運用も同時に行っており、アーキテクチャの改善まで始めれば、一度にシステムを改善することはさらに難しいと思います。

しかし、モニタリングを使用していなかったら、情報システムを改善することはこれよりさらに長い時間がかかったと思います。今後もサービス機能を開発し、ビジネス成長のために今のようにモニタリングを十分に活用する予定です。