【IT Daily】「DB 性能障害の 60％ 以上が SQL から始まります。ハードウェアを増設する前に SQL から最適化する必要があります。それが最高情報責任者 (CIO) が今すぐできる最も現実的なコスト削減戦略です。これを『まずチューニングし、その次に増設せよ (Tune First, Expand Later)』と呼んでいます。」

Openmade Consulting の Jang Cheol-woong 常務は最近、本紙（IT Daily/Computer World）とのインタビューで、AI 時代のインフラコスト問題の解決策をこのように提示した。Jang 常務は、IT 業界でハードウェアからシステムインテグレーション (SI)、ビッグデータ、DB まで多岐にわたる現場経験を活かし、現在 Openmade Consulting で AI ベースの SQL 自動最適化ソリューション「Query Medic」の営業を統括している。

「インフラ・インフレ時代… SQL 最適化なしには財務統制は不可能」

今年の企業 IT 環境は複合的な状況にある。DB 性能最適化専門企業の Openmade Consulting が最近発表した報告書によると、グローバル AI サーバー市場が約 2,200 億ドル規模に成長し、GPU やメモリ半導体の価格が高騰、DRAM 価格は前年比 50％ 以上上昇すると予測されている。

これにより、サーバーを増設したくても物量の確保が難しく、確保できたとしても費用が指数関数的に増加する、いわゆる「インフラ・インフレ」の局面が続いている。

コスト削減のために Cloud への移行を選択した企業も事情は大きく変わらない。Cloud 環境はリソースの使用量に応じて費用が請求される構造だ。最適化されていない SQL をそのまま移行すれば、不必要な I/O と CPU 消費が直ちにコスト上昇につながる。業界の調査によると、Cloud 支出の 10〜30％ が非効率なクエリによって浪費されている。

Jang 常務は「インフラをいくら増やしても、その上で動く SQL が非効率であれば、コストは際限なく漏れる構造だ。CIO の立場では、サーバーを購入するにせよ Cloud を利用するにせよ、SQL 最適化なしには財務的な統制が不可能な状況に直面している」と診断した。

「SQL チューニングは 1 日 3〜4 件が限界…管理の死角が発生」

問題は、このような SQL 最適化を誰が行うかだ。Jang 常務によると、現場の DB 管理担当者はシステムの可用性維持や障害対応などの運用業務に追われ、性能改善まで手が回らない。外部の専門家を投入してチューニングを依頼する場合もあるが、熟練した DBA 一人が 1 日に処理できる SQL チューニング件数は 3〜4 件が限界だ。難易度が高い場合は 1 件に 1 週間かかることもある。

ang 常務は「問題となるクエリのリストは担当者またはチーム別に管理されており、担当者の経験を合わせて管理するレベルだ」とし、「把握しているものは管理できるが、気づいていない伏兵が積み重なり、ある日突然障害として爆発するのが非常に危険だ」と述べた。

このような問題は開発現場でもボトルネックとなっている。例えば、ある IT 組織に 300 人の開発者がいる場合、各自が SQL を作成するが、作成したクエリの性能を検証してくれるチューニング専門家が不足している状況だ。開発者はチューニングを依頼したくても受け入れ先がなく、DBA は自身の運用業務に追われ、他人のクエリまで見る時間がない。

Jang 常務は「開発部署も DB 運用部署もチューニングの必要性は切実に感じているが、お互いに解決できない状況だ。それが現在の国内 IT 組織が抱えている最大の構造的問題だ」と指摘した。

「検知からチューニング・検証まで全過程を AI で自動化」

Query Medic はこのような問題を解決するために誕生した。Openmade Consulting は 21 年間にわたり金融圏を中心に DBA、チューナー、モデラーを顧客企業に派遣し、DB 性能管理の現場経験を積んできた。そのノウハウを集約して「OpenPOP」を開発・運営してきた。OpenPOP は SQL の開発段階から運用までの全過程にわたり性能を点検・検証・統制し、運用環境では 24 時間 365 日の障害予防プロセスを適用して先制的に障害を防ぐソリューションだ。

Jang 常務によると、顧客企業から「ガイドだけでなく、チューニング自体を自動化できないか」という要求が絶えず寄せられていたという。問題を見つけ出すことまでは OpenPOP で可能だった가、実際に SQL を修正する作業は依然として人間の役割だったからだ。

これを受け、AI 技術が急激に発展した 2 年前、本格的な Query Medic R&D に着手し、OpenPOP の検知・検証エンジンに LLM の推論能力を結合させた。性能の低い SQL の自動抽出から最適なチューニング結果の生成、検証まで全過程を自動化したのが核心だ。昨年 10 月に正式リリースされた。

ここには現場経験に基づいた詳細なチューニングロジック도反映されている。実際の DB 運用環境では、同じ SQL であっても、いつ、どのような目的で実行されるかによって最適なチューニング方法が異なる場合が多い。

例えば、日中のユーザーリクエストに即座に応答する必要がある OLTP クエリは、0.1 秒でも早く結果を返すことが重要だが、早朝に数時間かけて大量のデータを処理する Batch クエリは、個別の応答速度よりも全体の処理量を抑え、決められた時間内に作業を終えることが重要だ。Query Medic は対象となる SQL のタイプと実行パターンを自動的に判別し、各状況に合った最適化ロジックを適用する。

Jang 常務は「一般的な AI にクエリを入力すれば教科書的な回答が得られるが、現場ではそれが通用しないことが多い。長年金融業界の現場で培った経験、例えば『このような状況ではこのようにチューニングするのが実際に良い』という判断基準がエンジンに反映されているため、結果の質が異なる」と説明した。

「AI が修正した SQL、信頼できるかどうかが鍵」

特に Jang 常務が Query Medic の核心的な差別化ポイントとして挙げたのは「AI ベースの検証」機能だ。汎用 AI ツールでも SQL チューニングの結果を得ることはできるが、その結果を実務にすぐに適用できるかどうかは全く別の問題だという説明だ。

Jang 常務は「ChatGPT や Gemini に SQL を入力すれば、それらしい案は出てくる。しかし、結果の一貫性が保証されないため、運用環境には適用できない。実際、多くの企業が独自に LLM モデルを導入して SQL チューニングを試みたが、結果を信頼できず実務への適用を断念したケースがほとんどだ」と語った。

Query Medic は、AI が生成したチューニング案を実際の運用データが含まれる DB 環境で直接実行し、チューニング前後の結果値とデータ件数が正確に一致するかまで自動的に照合・検証する。

Jang 常務は「チューニングから検証までの全ステップを自動化したソリューションは、国内はもちろん世界的にもまだ存在しない。この検証機能こそが特別なのだ」と強調した。

「DBA 一人は月 60 件、Query Medic は 1 日 1,000 件以上」

Jang 常務によると、熟練した DBA 一人が 1 日に処理できる SQL チューニング件数は約 3 件だ。単純計算で月 20 日勤務基準で 60 件、年間約 720 件を処理することになる。Query Medic は 24 時間 365 日自動で稼働し、1 日に 1,000 件以上の SQL をチューニングできる。さらに、人が気づかない潜在的な障害 SQL まで全数検査して先制的に排除するため、障害予防効果も期待できる。

Jang 常務は「人間が管理しているのは、記録に残っているものや担当者が経験的に把握している一部に過ぎない。Query Medic は全 SQL を全数検査するため、それまで誰も気づかずにある日突然障害となるような伏兵まで事前に捉えることができる」と説明した。

Query Medic への現場の期待も高いという。Jang 常務は「Query Medic を紹介すると、開発者、DB 担当者、CIO の反応が最も熱い。開発者の立場では、自分が作成した SQL の品質を即座に検証してもらえる手段ができたことになり、CIO の立場では、サーバー増設や人員補充なしに運用効率を向上させ、コストを制御できるツールが確保されたことになる」と語った。

さらに「ある金融業界の顧客企業では、5〜6 年にわたり多様な AI モデルを導入してビジネス成果を出そうとしたが、満足のいく結果が得られなかった。Query Medic のデモと POC を経て、該当の IT 部署から『AI で実際に実績を出せるソリューションは Query Medic しかない』という評価をいただいた」と付け加えた。

現在、Query Medic は公共機関や金融業界を中心に導入が拡大している。公共機関のシステム再構築事業に Query Medic を供給した事例も出ており、多数の金融機関や公共機関で POC を実施、または導入を検討中だ。

最近では製造業分野でも関心が高まっている。Jang 常務は「韓国の大手製造企業が海外の生産ラインを運営する際、現地の開発者が作成した SQL の品質問題により性能障害が頻発している。生産ラインが止まれば原価損失が莫大だが、その原因の大部分が DB 上で動く SQL にあるという認識が広まり、製造分野からの問い合わせが大幅に増えた」と述べた。

「『チューニングが先』という原則を現場に定着させる」

Query Medic は現在 Oracle 環境をサポートしており、サポート対象の DB を急速に拡大している。PostgreSQL は既に開発がほぼ完了しており、国産 DB の Tibero は第 2 四半期内にサポート予定だ。MySQL は下半期を目標に開発が進行中だ。2027 年からは SaaS 版も提供する計画だ。

Jang 常務は「DB チューニングという専門領域で 21 年間築き上げてきた技術的信頼があるからこそ可能なことだ。Query Medic が導入されたシステムは安全だという確信を市場に広めたい」と語った。

続けて「もはや DBA が徹夜でクエリを一つひとつ分析する時代は終わらせるべきだ。『まずチューニングし、その次に増設せよ』という原則が CIO たちの常識になる日まで、現場で走り続ける」と付け加えた。

製品導入およびコンサルティングなどの営業のお問い合わせ

02-6310-6167 / qm@openmade.co.kr

出典：IT Daily (http://www.itdaily.kr/news/articleView.html?idxno=238877)

キム・ホ記者 seungyang@itdaily.kr

＃SQLチューニング ＃AIチューニング ＃データベースパフォーマンス ＃クエリメディック ＃QueryMedic ＃オープンメイドコンサルティング ＃DB最適化 ＃自動化ソリューション ＃2025新製品 ＃DBA＃開発者 ＃IT運営 ＃コスト削減 ＃パフォーマンス改善 #AI自動化 #DB性能管理 #インフラコスト削減 #CIO