株式会社kubell｜日本最大級のビジネスチャット「Chatwork」の大規模データベース移行において、網羅的なSQLテストにより短期間での安全かつ確実なバージョンアップに成功

95.3万社以上が導入する日本最大級のビジネスチャット「Chatwork」はkubellの主力事業であり、多くの企業の業務に不可欠なコミュニケーション基盤となっている。「Chatwork」のバックエンドデータベースはAWS上で構築・運用され、日々膨大な量のデータを処理する。今回、旧バージョンのサポート終了を迎え、データベースのAmazon Aurora MySQL バージョン3への移行が喫緊の課題となっていた。長年にわたり機能追加や修正がなされてきた巨大なデータベースを、ユーザーに影響を与えずに、安全かつ確実に移行するためには、網羅的なテストの実施が不可欠であると判断。そこで、人海戦術で半年かけて対応する場合の人件費と比較して安価であることも考慮され、Insight SQL Testingが導入された。

導入社数95.3万社以上、登録ID数が792.7万以上の日本最大級のビジネスチャット「Chatwork」

株式会社kubellの主力事業は、日本最大級のビジネスチャット「Chatwork」だ。導入社数は95.3万社を超え*、登録ID数は792.7万以上*。また同社は、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる「タクシタ」などのBPaaS(Business Process as a Service:業務プロセスそのものを提供するクラウドサービス)を幅広く展開。ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業拡張している。

「Chatwork」は、日々の業務の中でユーザー間の重要なデータを扱うため、高い可用性と信頼性が求められる。コミュニケーションプラットフォームディビジョン プロダクトユニット サーバーサイド開発Bグループ 松田和樹氏は、「そのうえで、FAXや電話、メールなどと同様、情報の秘匿性や堅牢性も必要です」と述べる。

ビジネスチャットはユーザー企業が始業する9時頃から10時台にトラフィックが一気に増加し、終業の19時くらいまでほぼ一定のトラフィックが続く。このような変化のあるトラフィックに対し、高い安定性が求められる。さらに「Chatwork」が止まれば業務にも大きな支障をきたすなど、ユーザー企業にとって極めて重要なツールとなっている。

大規模データベースを確実に移行するためにInsight SQL Testingを採用

高い信頼性、可用性が求められる「Chatwork」のシステムは、AWS上で構築、運用されている。バックエンドのデータベースには、Amazon Aurora MySQLが利用されている。「Chatwork」への1日のアクセスユーザー数は約123.5万人*で、「Chatwork」の大半 のデータが集約されている。*2025年9月末時点

開発グループ内には、「さまざまな会社のデータベースの中でも『Chatwork』のインスタンスサイズは極めて大きい」と見ているメンバーもいる。

利用していたMySQL 5.7ベースのAuroraバージョン2はサポート終了が迫っていたため、8.0ベースのバージョン3への移行が必須だった。提供されているドキュメントなどで移行の影響範囲は把握できたものの、安全、確実な移行には網羅的で漏れのないテストが不可欠だと考えた。

移行時に活用できるテストツールの存在は知っていたが、具体的にどのようなものがあるかは知らなかった。そこで、「データベース」「更新」「SQLテスト」「マイグレーション」などのキーワードで調査を行い、Insight SQL Testingを見つけた。

オープンソースのテストツールなども検討候補となったが、自分たちでツールを持ってきて使えるように準備し、テストを行い確認して結果を評価するとなれば、かなりの手間がかかる。SQLを取得するための環境の構築も必要であり、データを扱う際のセキュリティの問題なども自ら解決しなければならない。

一方Insight SQL Testingは、AWSのエンジニアからも推奨され、Amazon Auroraの移行で豊富な実績があることも分かった。インサイトテクノロジーからも説明を受け、事例などの情報も得て、やりたいことが一通りできることも確認できた。サポート終了までの半年という短期間で、手作業で網羅的なテストを実施する場合の工数と人件費を考慮した結果、コスト面でも十分に見合うと判断。kubellはInsight SQL Testingの採用に至った。

少ない人数でも短期間で網羅的なSQLテストを実現

2024年1月にプロジェクトがスタートし、まず少人数で何をするべきかを洗い出していった。その過程でテストツールの必要性を認識し、4月頃にはInsight SQL Testingの存在にたどり着いた。6月からツールの具体的な評価を実施し、並行して手作業で行うテスト作成なども進めた。

続いてピーク時、定常時、バッチ処理の時間帯など、複数のタイミングで必要なSQLをアプリケーションログから取得。これらは「とても手作業で取得できるような量ではありませんでした」と、松田氏は振り返る。テスト項目の洗い出しや手動テストの実行については、約4名で行ったと言う。取得したSQLでテストを実施し、結果の評価、確認、必要な修正を行い、最終的に9月末に 期限内に「問題なくリリースできる」という判断をすることができたと言う。

移行対象となるシステムは、既に15年ほど機能追加や修正を重ねながら使い続けられている。その間には担当者の入れ替わりもあったために中身を熟知しているエンジニアがいない機能もあり、確認すべき事項は多岐にわたる。「膨大な量の本番ログを目で追いながら、手動でテスト項目を洗い出すのは無理だと感じるほど大変です。それをInsight SQL Testingで自動化できたので大変助かりました。」と松田氏。

また、kubellではセキュリティ担保などを目的に、役割分担が明確化されている。たとえばアプリケーション開発エンジニアは、データベースの中身の一部参照権限を持たない、といった具合だ。

移行を担当した松田氏らはアプリケーション開発担当で、そのような権限が限定された体制でも、Insight SQL Testingを活用することによって、実際に動いているSQLを網羅的に取得できた点は大きなメリットだった。

また、移行前後での差分がUIで見やすく表示され、問題がありそうなクエリもUIからすぐに実行・結果確認できるのが便利だったと、松田氏はInsight SQL Testingの使い勝手の良さを評価する。テストの結果、大きな修正を伴うSQLの変更はなく、見つかった差異はドキュメントなどで明らかにされていたものがほとんどだった。

「Insight SQL Testingで、エンジニアが安心して本番リリースに臨むための材料を見つけることができました」と松田氏。レイテンシの劣化が予測されるクエリもあったが、Insight SQL Testingの結果から許容範囲に収まることも事前に分かった。また、本番環境から取得できたクエリはバージョンアップ後もエラーが出たり大きく性能が変わったりすることがないことも確認できた。これらの結果が、本番リリースをして問題なしとする判断につながった。

また、特定の利用パターンでパフォーマンスに懸念があるクエリや、バリデーションチェックが不十分だった箇所など、効率化できそうなクエリも見つかっている。これはInsight SQL Testingの副次的な効果とも言える。

ツールの活用がエンジニアの「安心」につながる

kubellでは、今回のバージョンアップの対応とリリースにあたり、Insight SQL Testingによる効果を検証することができた。この結果をうけ、今後大規模なバージョンアップでは再びInsight SQLTestingの活用を検討する。グループ内では「スモークテストのためにInsight SQL Testingを起動し続け、何か問題があればアラートを受け取れるような使い方もあるのでは」という意見が出ている。それが可能であれば、エンジニアはさらに安心して開発ができるようになると指摘もある。松田氏は、本番のワークロードを使った負荷テストもSQLテストと一緒にできると「より魅力的です」と言う。

今回kubellでは、アプリケーションエンジニア中心に移行プロジェクトが進められた。そのため、Insight SQL Testingのようなツールの存在を知らないところからスタートした。アプリケーションでは重要な情報を扱うので、データを守ることの優先順位はかなり高い。データを扱う際にSQL Testingのような便利なツールがあるとの情報を、今後はアプリケーションエンジニアにも積極的に届けて欲しいと言うのだった。