クラウド活用する企業は年々広がるが同時に発生するバージョンアップ対応問題 / その解決に特化した「InsightSQLTesting」がアップデートへ
10月17日、株式会社インサイトテクノロジーがSQLテストツール「InsightSQLTesting」のver.4.2をリリースしたことを発表した。これによりAmazon Bedrockに対応する。
クラウドサービスを利用する企業は年々増加
直近5年間において企業のクラウドの利用は年々広がりをみせており、2019年には64.7％だった利用率は2023年には77.7％に増加した。今後も、クラウド利用する企業は増えていく見通しだ。
さらに、クラウドサービスを利用した実に9割の企業がプラス効果を実感している。理由として、「場所、機器を選ばずに利用できるから」「資産、保守体制を社内に持つ必要がないから」「安定運用、可用性が高くなるから」などが挙げられた。
一方で、中小企業では利用していない割合は多い。課題として、ITに関わる人材不足や予算問題が挙げられている。
オンプレミスDBを利用する企業とクラウドDBを活用する企業の実態の違い
オンプレミスDBを利用する企業と、クラウドDBを活用する企業の二極化がみられた。しかし、オンプレミスのバージョンアップの頻度は3年に1回未満が最多であり塩漬け状態も多い。
オンプレミスとは自社でサーバーやネットワーク機器、ソフトウェアなど設備やシステムを用意して運用する利用形態だ。
一方、クラウドのマネージドDBのバージョンアップは一年に一回の頻度が最多である。つまり、クラウドのマネージドDBはバージョンアップごとに効率化はされるが、その定期的なバージョンアップに対応する必要がある。
オンプレミスDBを利用する企業の94％は、バージョンアップ対応の必要性を認識してはいる。ただし、実施しているとは限らない。一方、クラウドDBを活用する企業の29％はバージョンアップ対応の必要性を認識していなかった。それどころか、強制バージョンアップされることも知らなかった。
オンプレミスDBのバージョンアップ対応には、3人から5人体制で2週間未満の期間が必要との回答が多く、クラウドDBのバージョンアップ対応には同じく3人から5人体制だが1か月以上2か月未満が必要との回答が多い。
クラウドDBのバージョンアップをする際に、テストをスキップしているケースが40％に達していた。その上で、SQLの修正が必要なのかどうかもわからない、影響範囲もわからないとの回答が46％。つまり、バージョンアップによって、SQLの互換性の不具合が発生する課題が存在する実態が判明した。
「InsightSQLTesting」は生体AIを駆使して問題を解決
「Insight SQL Testing」Ver.4.2は、生体AIを強化した特徴がある。本番環境でアプリケーションが発行するSQLを自動収集し、収集したSQLを自動でテストする。Amazon Bedrock対応がより強化され、複数の推論モデルを利用できるので、SQLの修正工数を簡略化することが可能だ。
また、命令文であるプロンプトを製品側が用意したもの以外に、カスタムして使用することもできる。
クラウドDBのバージョンアップは、パフォーマンス向上や新テクノロジーの活用など多くのメリットが得られる。その上、脆弱性の対策もされるためにセキュリティ面も向上する。つまり、必要不可欠なのである。
DBバージョンアップによる非互換SQLの存在チェックを、「InsightSQLTesting」はしてくれる。性能への影響調査もするので、どんなエラーが発生するのか、挙動の非互換はあるかどうかも人力を注力せずとも生体AIがしてくれるのだ。
株式会社ココナラの川崎氏による活用所感
3年で3倍の組織規模に成長した株式会社ココナラ。データベースクラウドのサポート終了のタイミングで、「InsightSQLTesting」を導入した。そもそも、どのような課題解決のために導入したのか。川崎氏が語った。
川崎氏：
「KPIとして設定している目標のリクエスト成功率99.96％以上に対して、Amazon RDSのSLAは99.95％で達していなかった。さらに、1秒あたりのアクセス数がさばききれなくなる限界が見えてきていた。ストレージ拡張で上限を上げたが、一時しのぎでしかない。
これに加えて、MySQL 5.7 EOL対応も迫る。解決しなければ自壊することが明白であり、2022年春に本腰を上げることになった。
470万名を超えるユーザーに対応するメインDBには膨大なSQLが流れており、雑にアップデートができない。内製でするには年単位の作業になるのがみえており、外注する必要があった。
さまざまなサービスのなかから、実際のSQLを利用でき、新旧バージョンの違いを一目で比較できる「InsightSQLTesting」を選んだ。
運用してみて見えた課題はふたつ。ひとつは性能テストの実施オプションの入力が毎回必要で手間だった。もうひとつはココナラの膨大なSQLを並列実行してみたところメモリがオーバーフローして作業停止になってしまった。
これらの課題は、ひとつ目の課題はREST APIが提供されていたのでスクリプトの作成で効率化した。ふたつ目の課題は、クエリログ時間を一時間から一分にする一手間で解消した。
運用したおかげで、性能テストで事前に問題点を洗い出せたのでメインDBのAuroraMySQL3化が無事故で終えられた。こうした移行をしやすくしてくれるサービスは新技術への対応も手助けしてくれることが期待できる」
