PhoenixAI Anywhere Sub Second Analytics on Live Data, Inside Your Own Network

PhoenixAI Anywhere는 어떤 제품인가요? 실시간 분석 엔진인 PhoenixAI를 프라이빗 클라우드 환경에서 자체 관리할 수 있도록 지원하는 제품으로, AI 에이전트와 고객 대면 분석 시스템의 복잡한 쿼리 요구사항을 충족시킵니다.

1. PhoenixAI Anywhere 소개 및 등장 배경

PhoenixAI Anywhere는 AI 에이전트와 고객 대면 분석 시스템의 복잡한 쿼리 요구사항을 충족시키기 위해 실시간 분석 엔진인 PhoenixAI를 프라이빗 클라우드 환경에서 자체 관리할 수 있도록 지원하는 제품이다.

1.1. 분석 쿼리의 변화와 새로운 도전

1. 분석 쿼리 유형의 변화
1. 과거에는 내부 대시보드를 통해 미리 설정된 쿼리를 사람이 확인하는 방식이었다 .
2. 현재는 고객 대면 시스템을 넘어 AI 에이전트가 분석을 수행하는 방식으로 변화하고 있다 .
2. AI 에이전트의 쿼리 특성
1. AI 에이전트는 훨씬 더 즉흥적인(ad hoc) 쿼리를 사용하며, 더 많은 조인(join)을 필요로 한다 .
2. 따라서 미리 데이터를 계산해두는 사전 계산(precomputation) 방식은 더 이상 효과적이지 않다 .
3. 높아진 성능 요구사항
1. AI 에이전트는 훨씬 더 높은 동시성(concurrency)과 낮은 지연 시간(latency)을 요구한다 .

1.2. 프라이빗 클라우드 환경의 중요성

1. 데이터 주권 및 규제 준수
1. 고객들은 데이터를 자체 프라이빗 환경에 보관하려는 경향이 증가하고 있다 .
2. 이는 제로 이그레스(zero egress) 네트워크를 통해 외부로 데이터가 나가지 않도록 하며, 특정 관할권 내에 데이터를 유지해야 하는 규제 준수(compliance) 문제와 관련이 있다 .
2. 제어권 소유의 필요성
1. 고객은 데이터베이스뿐만 아니라 제어 플레인(control plane), 모든 로그, SQL 편집기 등 모든 것을 직접 소유하고 제어하기를 원한다 .

1.3. 기존 온프레미스 OLAP 솔루션의 한계

1. MPP 데이터 웨어하우스의 한계
1. 온프레미스 MPP(Massively Parallel Processing) 데이터 웨어하우스는 조인을 지원하지만, 초고속(sub-second) 지연 시간에는 적합하지 않다 .
2. 데이터 신선도(data freshness)는 일반적으로 몇 시간에서 밤샘 배치 작업 수준이며, 수십 개의 동시 쿼리까지만 처리할 수 있다 .
2. 데이터 레이크 쿼리 엔진의 한계
1. 하둡(Hadoop) 생태계의 하이브(Hive) 테이블과 트라이노(Trino) 또는 스파크(Spark) 같은 쿼리 엔진은 조인 처리와 수평 확장은 가능하지만, 낮은 지연 시간과 고성능 쿼리에는 최적화되어 있지 않다 .
2. 데이터 신선도는 데이터 레이크의 성능에 따라 달라지며, 대부분의 프라이빗 환경 사용자는 여전히 하이브 테이블이나 하둡 환경에 머물러 있다 .
3. 실시간 OLAP 데이터베이스의 한계
1. 클릭하우스(ClickHouse)나 아파치 드루이드(Apache Druid)와 같은 오픈소스 실시간 OLAP 솔루션은 단일 테이블 설계가 많아 조인을 의미론적으로 지원하지 않거나, 여러 머신에서 조인을 병렬로 실행할 수 없다 .
2. 이는 확장성이 부족하여 사용자들이 데이터를 비정규화(denormalize)하도록 강요한다 .

1.4. 비정규화의 문제점

1. 인프라 비용 증가
1. 비정규화는 테이블을 평탄화(flatten)하거나 사전 집계(pre-aggregate)하여 저장 비용을 약 10배 증가시킨다 .
2. 스키마 변경의 어려움
1. 차원 테이블(dimension table)이나 팩트 테이블(fact table)의 스키마를 변경할 때, 비정규화된 테이블 전체를 업데이트해야 하므로 스키마 변경이 훨씬 어려워진다 .
2. 데이터 백필(data backfill) 비용이 매우 비싸고, 비정규화 파이프라인 구축에 많은 노력이 필요하다 .
3. AI 에이전트의 기능 제한
1. AI 에이전트가 생성하는 쿼리는 즉흥적(ad hoc)이므로, 비정규화나 사전 계산은 AI 에이전트의 미래 기능을 제한하게 된다 .
2. 쿼리를 템플릿으로 제한하는 것 또한 AI의 기능을 제한하는 결과를 초래한다 .
4. 지연 시간 수용의 한계
1. MPP 데이터 웨어하우스나 쿼리 엔진에서 지연 시간을 수용하는 것은 수십 분까지 걸릴 수 있어 고객 대면 또는 대화형 분석에는 적합하지 않다 .
2. 이는 즉흥적인 워크로드에는 좋지 않으며, 야간 배치 보고서에나 적합하다 .

1.5. PhoenixAI의 핵심 기능

1. 즉흥적인 다중 테이블 조인 지원
1. PhoenixAI는 즉흥적인 다중 테이블 조인을 지원하며, 최첨단 비용 기반 최적화(cost-based optimizer) 덕분에 빠르게 실행된다 .
2. 분산 환경에서 효율적으로 작동하도록 설계되었으며, 메모리 간 셔플(shuffle)을 통해 조인을 분산 처리한다 .
2. 초고속(Sub-second) 지연 시간
1. C++ uVector를 기반으로 한 완전 벡터화된(fully vectorized) 연산자를 사용한다 .
2. 모든 연산자는 CPU에 최적화되어 있으며, 컬럼 형식으로 데이터를 저장하고 배치로 처리하여 최고의 OLAP 성능을 제공한다 .
3. 초 단위 데이터 신선도
1. 업데이트 프로세스를 돕기 위해 행 기반 인덱스(row-based index)를 가진 전용 기본 키 테이블을 갖추고 있다 .
2. 카프카(Kafka)나 플링크(Flink)에서 데이터를 가져와 5초 미만의 데이터 신선도를 달성하며, 삽입(upsert) 및 삭제(delete)도 지원한다 .
4. 높은 동시성 지원
1. 매우 높은 동시성과 이기종(heterogeneous) 워크로드를 지원하도록 최적화되어 있다 .
2. 리소스와 워크플로우를 격리하는 다양한 방법을 통해 하나의 Phoenix 클러스터가 여러 워크로드를 동시에 처리할 수 있다 .
5. StarRocks 기반 아키텍처
1. PhoenixAI는 StarRocks를 기반으로 하며, FE와 CN두 가지 프로세스만으로 구성되어 객체 스토리지에 연결된다 .
2. 이는 프라이빗 배포 환경에 적합하며, 확장성, 비용 효율성, 배포 유연성을 제공한다 .
3. PhoenixAI 아키텍처는 상단에 AI 에이전트, 고객 대면 앱, BI 도구와 같은 애플리케이션이 있고, 컴퓨트 계층은 멀티 웨어하우스(multi-warehouse)로 구성되어 컴퓨트 노드 클러스터를 물리적으로 격리하여 독립적으로 확장할 수 있다 .
4. 내부 스토리지 외에도 아파치 아이스버그(Apache Iceberg) 또는 델타 레이크(Delta Lake) 테이블에 대한 읽기 전용(read-in-place) 지원을 통해 데이터 레이크하우스에서 직접 초고속 쿼리 성능을 제공한다 .

1.6. PhoenixAI Anywhere 출시

1. PhoenixAI Cloud와 Anywhere의 차이점
1. 기존에는 3대 주요 퍼블릭 클라우드에서 실행되는 서비스형 제품(BOC service)인 PhoenixAI Cloud가 있었다 .
2. 이번에 소개하는 PhoenixAI Anywhere는 쿠버네티스(Kubernetes), 온프레미스(on-premises) 또는 VPC(Virtual Private Cloud) 환경에서 자체 관리형(self-managed) PhoenixAI 경험을 제공한다 .

2. PhoenixAI Anywhere의 기능 및 활용

PhoenixAI Anywhere는 강력한 PhoenixAI 엔진을 기업 환경에서 안정적으로 배포, 운영 및 확장할 수 있도록 지원하는 자체 관리형 솔루션이다.

2.1. PhoenixAI Anywhere의 역할

1. 운영의 복잡성 해결
1. 강력한 엔진을 프로덕션 환경에 배포한 후에는 시스템을 24시간 내내 가동하고, 문제 발생 시 신속하게 진단 및 해결하여 비즈니스 영향을 최소화하는 것이 중요하다 .
2. 운영 계층의 제어 플레인
1. PhoenixAI Anywhere는 이러한 자체 관리 환경을 위해 구축된 운영 계층의 제어 플레인으로, PhoenixAI 데이터베이스 엔진과 함께 제공된다 .

2.2. PhoenixAI Anywhere의 주요 기능

1. 배포 및 관리
1. 쿠버네티스 네이티브(Kubernetes native) 방식으로 배포되며, 포드(pod) 재시작과 같은 쿠버네티스의 이점을 활용한다 .
2. 운영자(operator)를 통해 재구성, 스케일링 등 전체 라이프사이클 관리를 지원한다 .
2. 콘솔 기능
1. 콘솔은 쿼리 인사이트, 모니터링, 사용량 측정, 진단 및 지원 기능을 제공한다 .
3. 배포 환경 지원
1. EKS, AKS, GKE와 같은 모든 관리형 쿠버네티스 플랫폼에 배포할 수 있으며, 자체 VPC 또는 데이터 센터 환경에서도 작동한다 .
2. Anywhere 콘솔과 운영자를 함께 배포하여 데이터베이스의 전체 라이프사이클을 관리하며, 오픈소스 StarRocks 또는 이전 엔터프라이즈 버전에서 마이그레이션도 지원한다 .
4. 운영 기능
1. 구성, 로드 밸런싱, 크기 조정, 스케일링, 백업 및 복원 등 다양한 운영 기능을 포함한다 .

2.3. Anywhere 콘솔 라이브 데모: 관리자 기능

1. 클러스터 개요
1. 콘솔은 관리자와 데이터베이스 사용자 두 가지 페르소나를 지원한다 .
2. 네트워크 플랫폼 내의 클러스터 목록을 카드 또는 리스트 형태로 볼 수 있으며, 라이선스 만료 시 경고를 표시한다 .
3. 클러스터를 클릭하면 클러스터 이름, 생성일, CPU 리소스 기반 사용량, 가동 중인 노드 수, 데이터 볼륨 변화, CPU 사용량 등 빠른 개요를 확인할 수 있다 .
2. 리소스 관리
1. 쿠버네티스 정의(manifest)를 통해 클러스터의 모든 정의를 확인할 수 있으며, kubectl get pods와 같은 명령줄 작업 없이도 쉽게 볼 수 있다 .
2. 코디네이터(coordinator)의 포드, CPU, 메모리 사용량 등 리소스 정보를 확인할 수 있다 .
3. 웨어하우스(warehouse)는 컴퓨트 노드의 리소스를 격리하여 독립적으로 스케일링할 수 있도록 정의된 개념이며, 각 웨어하우스의 CPU 및 메모리 사용량도 확인할 수 있다 .
3. 모니터링 및 진단
1. 모니터링 탭에서는 클러스터의 주요 지표를 제공하며, 개별 포드에 대한 상세 지표도 확인할 수 있다 .
2. 사전 정의된 규칙에 따라 시스템의 상태를 점검하는 헬스 체크(health check) 기능을 제공하여, 시스템을 안정적으로 유지하는 데 중요한 규칙들을 콘솔 내에서 확인할 수 있다 .
3. 문제 진단을 돕기 위해 사전 정의된 SQL 명령을 제공하여, 사용자가 직접 명령을 기억하거나 입력할 필요 없이 쉽게 실행하고 결과를 확인할 수 있다 .
4. 특정 포트에 접속하여 상태를 확인할 수 있는 셸 명령(shell command)도 제공하며, JStack과 같은 명령을 콘솔에서 바로 실행할 수 있다 .
4. 라이선스 관리
1. 각 클러스터의 라이선스를 적용하고, 사용 중인 용량과 만료일을 확인할 수 있으며, 주의가 필요할 때 알림을 받는다 .
5. 지원 번들 생성
1. 고객 지원이 필요할 경우, 지원 번들(support bundle)을 생성하여 PhoenixAI 팀에 보낼 수 있다 .
2. 번들 생성 시, 미리 정의된 시나리오(예: 느린 쿼리, 컴퓨트 노드 충돌)를 선택하면 필요한 로그 파일, 쿼리 아티팩트 등이 자동으로 포함된다 .
3. 특정 컴퓨트 노드를 선택하여 번들을 생성할 수 있으며, 사용자가 시스템 전문가가 아니더라도 쉽게 진단 정보를 수집할 수 있도록 돕는다 .
6. 번들 전송 및 전체 플릿 헬스 체크
1. 생성된 번들은 로컬로 다운로드하거나, 온디맨드 연결을 통해 PhoenixAI 팀에 직접 전송할 수 있다 .
2. 에어갭(air-gapped) 환경에서는 다운로드 후 슬랙(Slack)이나 젠데스크(Zendesk)를 통해 수동으로 전송할 수 있다 .
3. 전체 플릿(fleet) 헬스 체크 기능을 통해 모든 클러스터의 상태를 한눈에 파악하고, 가장 높은 우선순위의 문제를 확인할 수 있다 .
7. 사용량 및 측정(Usage and Metering)
1. 월별 CCU(Compute Consumption Unit) 사용량을 추적하고, 두 클러스터의 사용량 추세를 확인할 수 있다 .
2. 일별 상세 사용량 데이터를 제공하며, 전체 사용량 기록을 JSON 파일로 다운로드하여 사용량 보고서로 활용할 수 있다 .

2.4. Anywhere 콘솔 라이브 데모: 사용자 기능

1. SQL 편집기 및 데이터 카탈로그
1. 데이터베이스 사용자는 SQL 편집기에서 쿼리를 작성하고 실행할 수 있다 .
2. 데이터 카탈로그를 통해 데이터베이스 스키마를 쉽게 탐색하고, 웨어하우스를 전환하는 등 편리한 기능을 제공한다 .
2. 쿼리 인사이트 및 프로파일링
1. 실행된 모든 쿼리 목록을 볼 수 있는 쿼리 인사이트(query insights) 기능을 제공한다 .
2. 복잡하거나 느린 쿼리의 경우, 그래픽 쿼리 프로파일(graphical query profile)을 통해 쿼리의 각 단계에서 시간이 가장 많이 소요되는 부분을 시각적으로 확인할 수 있다 .
3. 이 정보를 통해 사용자는 SQL 쿼리를 최적화하고, 자체적으로 문제 해결을 할 수 있다 .
3. 시스템 모니터링
1. 최종 사용자는 시스템 모니터링을 통해 쿼리가 느린 이유가 SQL 비효율성 때문인지, 아니면 리소스가 부족하기 때문인지 빠르게 파악할 수 있다 .

2.5. PhoenixAI Anywhere 로드맵 및 향후 계획

1. 운영자(Operator) 개선
1. 업그레이드 및 롤백 시 더 원활한 작동을 보장하고, 오토스케일링(autoscaling)을 최적화할 예정이다 .
2. 데이터 웨어하우스 내에 더 많은 컴퓨트 노드 그룹을 추가하여, 개별 노드 단위가 아닌 그룹 단위 스케일링을 통해 워크로드에 더 잘 대응할 계획이다 .
2. 쿼리 정보 추가
1. CPU 및 메모리 외에 큐에 있는 쿼리 수와 같은 쿼리 정보를 포함하여, 오토스케일링을 미리 예측하고 대응할 수 있도록 돕는다 .
3. 문제 해결 도구 강화
1. 추가적인 검사, 더 풍부한 진단 기능, 셀프 서비스 알림 등 문제 해결 도구를 더욱 강화할 예정이다 .
4. AI 어시스턴트 운영 추가
1. AI를 활용하여 쿼리 작성 단계에서 자연어 처리나 가이드 SQL 컨텍스트를 통해 AI 어시스턴트가 직접 쿼리를 생성할 수 있도록 지원할 계획이다 .

2.6. 재해 복구 및 거버넌스 Q&A

1. 재해 복구(Disaster Recovery) 및 클러스터 간 마이그레이션
1. StarRocks의 공유 없음(shared-nothing) 아키텍처에서는 데이터만 복제되므로, 접근 제어 및 권한과 같은 메타데이터는 사용자가 직접 관리해야 한다 .
2. 두 개의 클러스터를 항상 대기 상태로 유지해야 하는 어려움이 있다 .
3. PhoenixAI의 공유 데이터(shared-data) 아키텍처에서는 클러스터 스냅샷(snapshot) 기능을 통해 메타데이터와 공유 스토리지(예: AWS S3)의 데이터를 사용하여 전체 클러스터를 복구할 수 있으며, 두 개의 클러스터를 동시에 유지할 필요가 없다 .
4. PhoenixAI Anywhere는 공유 데이터 아키텍처만 지원한다 .
2. 거버넌스, RBAC(Role-Based Access Control), 마스킹
1. 현재 관리자 콘솔은 Kubernetes 시크릿(secret)에 저장된 기본 사용자 이름과 비밀번호로만 접근할 수 있다 .
2. 사용자 콘솔은 주로 모니터링 기능만 제공하며 CRD(Custom Resource Definitions)에 쓰기 작업을 하지 않으므로, 현재는 복잡한 RBAC를 적용하지 않았다 .
3. 향후 더 많은 기능이 추가되면 사용자 측에 RBAC를 추가하여 사용자 접근을 완벽하게 제어할 계획이다 .
4. PhoenixAI 데이터베이스 자체에서는 SQL 쿼리를 통해 RBAC를 구성할 수 있다 .