날짜
April 25, 2025 2:00 AM (GMT+9)
선택
태그
- Eightfold의 고객 대면 분석과 AI 에이전트
- 소개
- Eightfold.ai 소개
- 제품 영역
- 규모와 인프라
- 분석 시스템 아키텍처
- 데이터 구조
- OLTP vs OLAP 데이터베이스
- ETL Evolution
- 1세대 아키텍처
- 2세대 아키텍처
- 3세대 아키텍처 (Lake House)
- Eightfold의 도전과 StarRocks 선택
- In-product Analytics 필요성
- Redshift의 한계
- StarRocks의 장점
- Agentic Analytics와 미래
- AI 에이전트와 분석의 결합
- Conversational Analytics
- 보안 및 액세스 제어
- 미래 비전
- 시작하는 팀을 위한 조언
- ❓ Q&A 하이라이트
- 성능과 비용
- 데이터 저장 전략
- 파티셔닝과 확장성
- Materialized Views 활용
- 데이터 신선도
Eightfold의 고객 대면 분석과 AI 에이전트
소개
오늘 특별 게스트인 Suresh(Director of Engineering from eightfold)의 발표와 대화를 정리한 내용입니다. 주요 주제는 customer-facing analytics와 AI agents입니다.
Eightfold.ai 소개
- Eightfold는 talent space에 특화된 AI 회사
- 마지막으로 알려진 인재 관련 스타트업은 약 20년 전의 Workday
- Eightfold는 AI 시대에 시작됨 (LLM 이전부터)
- AI 기반 접근 방식으로 talent 문제를 해결
제품 영역
- Talent acquisition management
- Workforce planning
- 기타 인재 관련 제품들
규모와 인프라
- Fortune 500 기업 중 200개 이상이 Eightfold 사용
- careers.microsoft.com, careers.morganstanley.com 등 대기업 채용 사이트 트래픽 처리
- 높은 인프라 안정성과 데이터 분석 능력 필요
분석 시스템 아키텍처
데이터 구조
- Fact tables: clickstream events (대규모)
- Dimension tables: 직원 프로필, 다중 테넌트 데이터 (대규모)
- Star schema 모델 사용 (팩트 테이블과 차원 테이블 결합)
OLTP vs OLAP 데이터베이스
- OLTP (MySQL, Postgres)
- 웹 애플리케이션 백엔드
- point queries에 최적화 (예:
SELECT * FROM employee WHERE name = 'Suresh') - 높은 QPS 지원
- OLAP (Redshift, Teradata, Snowflake, BigQuery)
- 주로 back-office 용도
- 집계 쿼리에 최적화
- 전통적으로 동시성/확장성보다는 분석 능력 중시
ETL Evolution
1세대 아키텍처
- 구조화된 데이터(OLTP) → ETL → Data Warehouse → BI 보고서
- 문제점: Data warehouse도 고정 스키마, 비정형 데이터 처리 어려움
2세대 아키텍처
- 모든 데이터를 Data Lake(HDFS/S3)에 저장 → ETL → Data Warehouse
- Data Science 팀은 Data Lake 직접 사용, BI 팀은 Data Warehouse 사용
- 문제점: 일관성 관리 문제 증가 (2개의 ETL 프로세스)
3세대 아키텍처 (Lake House)
- Data Lake + Data Warehouse 통합
- 구조화/비구조화 쿼리 모두 지원
- 메타데이터/인덱싱 레이어로 구조화 기능 제공
- Databricks, Snowflake 등이 이 방식 채택
Eightfold의 도전과 StarRocks 선택
In-product Analytics 필요성
- LinkedIn 같은 실시간 분석 대시보드 제공 필요
- 기존 Redshift로는 한계
- 서브초 단위 응답 시간 필요
Redshift의 한계
- 단일 Leader Node 병목
- 모든 쿼리가 Leader Node를 통과
- Compute Node를 추가해도 QPS 제한 존재
- 파티셔닝 개념 부족
- 다중 테넌트 환경에서 noisy neighbor 문제
- 비용 효율성 문제
- Concurrency Scaling이 비싸고 시간 소모적
- 최대 10-11 concurrency clusters 제한
- 서버리스 한계
- EBS 캐시 이점 부족
- I/O 병목현상
StarRocks의 장점
- 확장성 있는 Front-End Nodes
- 단일 리더 병목 없음
- 무제한 FE 노드 및 백엔드 노드 확장 가능
- 효과적인 파티셔닝
- 테넌트별 가상 파티셔닝 지원
- 태블릿이 여러 백엔드 노드에 분산
- 더 나은 성능
- 대략 2배 성능 향상
- 비용도 약 2배 절감
- 단순한 아키텍처
- 유지보수 용이
- 적은 구성 요소
Agentic Analytics와 미래
AI 에이전트와 분석의 결합
- 에이전트가 사용자 대신 쿼리 수행
- 기존 인간보다 더 많은 쿼리 생성 가능
- 높은 QPS 필요성 증가
Conversational Analytics
- 고정된 보고서/대시보드가 아닌 자유로운 질문-답변
- "이번 분기 총 채용 수는?", "이 후보자의 상태는?" 등 자연어 질문
- StarRocks의 높은 QPS로 이러한 혁신 가능
보안 및 액세스 제어
- 자유 형식의 분석 쿼리에 가드레일 필요
- 권한 경계 위치:
- DB 내부보다 애플리케이션 레이어에 두는 것 권장
- 중앙 집중식 권한 프레임워크 사용
- 모든 시스템에 동일한 액세스 제어 적용
미래 비전
- GPT 플랫폼으로 자연어 질문에 답변
- 보고서, CSV, 템플릿 PPT 등 다양한 형식으로 결과 제공
- 미리 정의된 보고서 없이 대화형 분석 지원
시작하는 팀을 위한 조언
- QPS 요구사항 파악부터
- 데이터베이스 인프라부터 설계
- 좋은 OLAP 데이터베이스에 먼저 투자
- 기본 데이터 레이어 견고하게
- 마이그레이션은 수개월 소요 가능
- 새로운 ETL, 유스케이스 고려 필요
- 데이터 구조와 아키텍처 설계 중요
- 테이블 생성, 비동기 MV 활용
- 사용 패턴에 맞는 최적화
❓ Q&A 하이라이트
성능과 비용
- Redshift 대비 약 2배 성능 향상
- 비용도 약 2배 절감 (특히 스케일링 시)
데이터 저장 전략
- S3에 기본 데이터 저장 (shared data 아키텍처)
- EBS 볼륨에 약 10-20% 데이터 캐싱
- 작은 테이블은 전체, 큰 테이블은 일부 캐싱
파티셔닝과 확장성
- S3에 태블릿 단위로 데이터 저장
- 테넌트 ID 기반 가상 파티셔닝
- 쿼리 시 일부 백엔드 노드만 참여 (전체 클러스터 부하 감소)
Materialized Views 활용
- 파티션별 점진적 새로고침 지원
- 클러스터 성능에 영향 최소화
- 최신성과 성능 사이 트레이드오프 관리
데이터 신선도
- Fact 테이블은 near real-time 유스케이스에 활용
- 높은 조인이 필요한 경우 MV 사용 (신선도 희생)