스탠바이 DB를 AI 조회에 활용할 수 있을까

#AI 조회는 스탠바이로, 업무 트랜잭션은 운영 노드로

누군가 "지난달 지역별 매출"을 물어도 AI는 곧바로 답을 뽑지 않습니다. 테이블 구조를 살피고, 값 몇 개를 확인하고, 실행 계획을 본 뒤에야 본 조회를 보냅니다. 질문 하나에 조회가 여러 번 나가니 AI는 사람보다 DB를 자주 봅니다. 처음 DB를 연결할 때는 테이블마다 통계와 표본 값을 읽으며 DB를 미리 공부하기도 합니다(「AI가 짠 SQL은 돌아가는데, 매출 숫자는 왜 틀릴까」). 이 조회가 모두 주문과 결제를 처리하는 운영 노드로 가면, 사람이 쓰는 업무 화면이 그 부담을 함께 집니다.

OwlDB와 함께 쓰면 AI 조회를 어느 노드에서 실행할지 OwlDB가 고릅니다. 이중화로 둔 스탠바이 노드(대기 서버)가 있으면 데이터를 읽는 조회를 그쪽으로 보내고, 운영 노드는 사람의 트랜잭션에 집중합니다.

#OwlAI만으로도 복제본에서 읽을 수 있다

OwlAI만 써도 운영 DB의 부담을 덜 수 있습니다. 관리자가 연결을 등록할 때 운영 DB 대신 조회 전용 복제본의 주소를 넣으면 됩니다(「운영 DB에 AI를 붙이자는 말에 보안팀이 묻는 세 가지」). 다만 이 선택은 등록한 시점의 구성에 묶입니다. 이중화가 전환돼 복제본이 운영 노드가 되거나, 복제본이 멈추거나 크게 뒤처지면 누군가 연결 정보를 고쳐야 합니다. 연결 하나로는 그 노드가 지금 운영 노드인지, 복제가 얼마나 늦었는지 알 수 없기 때문입니다.

#OwlDB는 조회하는 순간의 노드를 고른다

OwlDB는 노드마다 역할과 복제 지연을 이미 알고 있습니다. 그래서 OwlAI는 조회를 보낼 때 노드를 정하지 않고, 어느 DB에서 실행할지만 말합니다. OwlDB가 조회의 성격과 그 순간의 노드 상태를 보고 알맞은 노드를 골라 실행하고, 결과와 함께 어느 노드에서 왜 실행했는지를 돌려줍니다. 이중화가 전환돼도 OwlAI 쪽에서 고칠 것이 없습니다.

읽을 수 있는 스탠바이가 잠시 없거나 복제 지연이 기준을 넘으면, OwlDB는 실행하지 않고 그 사유를 알려 줍니다. OwlAI는 잠시 뒤 다시 시도합니다.

#어느 노드에서 읽었는지 기록에 남는다

OwlDB가 노드를 고른다고 해서 어디서 읽었는지 모르게 되지는 않습니다. OwlAI는 SQL을 실행할 때마다 남기는 기록에 실행한 노드와 그 노드를 고른 이유를 함께 적습니다. 나중에 "그날 그 답은 어느 서버의 데이터였나"를 물으면 기록에서 바로 찾을 수 있습니다. 스탠바이가 있는데도 운영 노드로 간 조회가 잦다면, 그 이유도 같은 기록에서 읽힙니다.

#스키마 분석도 업무 시간에 맡길 수 있다

DB를 연결하고 처음 돌리는 스키마 분석은 테이블 수만큼 조회가 이어지는 작업입니다. 테이블이 수백 개면 카탈로그·통계·표본 조회가 수천 번 나갑니다. OwlDB로 연결한 DB에서는 이 조회도 OwlDB를 거칩니다. 표본 값처럼 데이터를 읽는 조회는 대기 서버에서 읽고, 고객이 실제로 실행한 SQL 기록처럼 서버마다 따로 쌓이는 정보는 운영 서버에서 읽습니다. 그런 정보는 서버마다 자기 활동만 기록해서, 대기 서버에서 읽으면 운영 서버에서 실제로 돈 내용이 보이지 않을 수 있기 때문입니다. 데이터를 읽는 조회가 운영 서버를 비켜 가니 업무 시간에도 분석을 맡길 수 있습니다.

#도입 전에 확인할 것

• 운영 DB에 스탠바이 노드가 있는지
• AI가 답하는 업무가 스탠바이에서 읽어도 되는지(복제 지연만큼 지난 데이터를 받아들일 수 있는지)
• 스키마 분석을 돌릴 시간대