한 줄 요약: Vitess는 MySQL/Percona Server 인스턴스 여러 대 앞에 VTGate(프록시) 와 VTTablet(에이전트) 을 끼워, 애플리케이션이 단일 MySQL 처럼 보는 사이 클러스터가 샤딩·재샤딩·failover·온라인 스키마 변경·CDC 스트리밍 을 알아서 처리하도록 만든 오픈소스 시스템임. YouTube에서 출발해 2019-11 CNCF Graduated 프로젝트가 됐고, PlanetScale 등 상용 서비스의 백엔드로 쓰임.
개요
MySQL 단일 인스턴스의 한계가 보일 때 흔히 부딪히는 두 갈래는 (a) 샤딩 로직을 애플리케이션에 박는다, (b) NoSQL 로 옮긴다 임. Vitess 는 그 사이를 메우는 세 번째 길로 설계됨 — MySQL 그대로 두고 앞단에 게이트웨이·토폴로지 계층 을 얹어서 애플리케이션은 단일 DB 처럼 보면서도 뒤에서는 수십~수백 샤드가 돌아가게 함.
| 항목 | 내용 |
|---|---|
| 라이선스 | Apache 2.0 |
| 출처 | YouTube 에서 2010년부터 사용, 2018-02 CNCF 인큐베이션, 2019-11 Graduated |
| 지원 백엔드 | MySQL 8.0/8.4, Percona Server for MySQL 8.0/8.4 (이전 버전은 import 만) |
| 프로토콜 호환 | MySQL wire protocol — 클라이언트는 일반 MySQL 드라이버로 VTGate 에 붙음 |
| 토폴로지 저장소 | etcd (기본) 또는 ZooKeeper |
| VTGate 가 광고하는 버전 | 기본 8.4.<patch>-Vitess (@@version), --mysql-server-version 으로 변경 가능 |
결론
어떤 문제를 해결하나
| 문제 | Vitess 의 답 |
|---|---|
| 단일 MySQL 용량/IOPS 한계 | 수평 샤딩 — 키스페이스를 N개 샤드로 쪼개고, 샤드 추가·삭제는 라이브 클러스터에서 진행 가능 |
| 애플리케이션 코드에 박힌 샤딩 라우팅 | VTGate 프록시 가 SQL 파싱 후 키 컬럼(vindex) 으로 대상 샤드 결정 — 앱은 단일 DB 처럼 질의 |
| 수천 커넥션이 만드는 MySQL 메모리·CPU 비용 | 커넥션 풀링 — VTTablet 이 사용자 세션을 mysqld 커넥션 풀에 멀티플렉싱 |
| primary 장애 → 수동 failover 절차 | 토폴로지 + 리플리케이션 그래프 로 장애 감지·승격을 자동화 |
무중단 스키마 변경 (ALTER) 운영 부담 | Online DDL — ddl_strategy=vitess 등 빌트인 전략으로 백그라운드 마이그레이션 |
| MySQL → MySQL 또는 외부 시스템으로의 데이터 이동 | VReplication / MoveTables / Reshard — binlog 구독 기반 실시간 복사 + Switch |
운영자 관점에서 기억할 함정
- 샤딩 키 결정이 가장 비쌈. Vindex 와 VSchema 가 잘못 설계되면 cross-shard 쿼리가 폭증해 VTGate 가 N개 샤드 fan-out 결과를 머지하는 비용이 모든 쿼리에 깔림. 도입 검토는 데이터 모델·접근 패턴 분석부터 들어감.
- Vitess 는 active-active(다중 라이터) 를 지원하지 않음. 같은 샤드의 primary 는 한 대. 지리적 분산은 “샤드별로 primary 셀을 다르게 두는” 모델로 풂.
- 샤드 간 트랜잭션은 기본 best-effort. 분산 ACID 가 필요하면
transaction_mode=TWOPC로 올려야 하고, 이때 쓰기 비용이 약 50% 증가함. “한 트랜잭션 = 한 샤드” 가 되게 모델링하는 것이 원칙. - MySQL 변수 일부는 VTGate 가 가로챔.
binlog_row_image,binlog_format,auto_increment_increment등은 거절·무시됨. CDC 도구는 VTGate 가 아니라 mysqld 또는 VStream API 를 직접 구독해야 함. - 단일 노드를 작게 운영함. 공식 권장값은 mysqld 인스턴스당 약 250GB. 한 호스트에 여러 mysqld 를 띄우는 패턴이 일반적이며, 이 전제가 백업·복구·장애 격리 시간을 짧게 만드는 핵심임.
컴포넌트 한 페이지 그림
공식 다이어그램은 Architecture — Vitess docs 참조. 실서비스에서는 Application·VTGate·Shard 가 모두 N 인스턴스로 스택됨.
- VTGate — MySQL 호환 무상태 프록시. SQL 을 파싱·계획해 적절한 샤드의 tablet 으로 라우팅함.
- VTTablet — 각 mysqld 옆에 1:1 로 붙는 사이드카. 커넥션 풀링·쿼리 보호·백업/복구·VReplication 의 source/target 역할을 맡음.
- vtctld — 키스페이스 생성·리샤딩·Online DDL 등 모든 관리 작업이 통과하는 평면. CLI 진입점은
vtctldclient. - VTAdmin — vtctld 위에 얹히는 웹 GUI. 키스페이스·샤드·tablet 상태 조회와 일부 관리 작업을 브라우저에서 처리.
- vtorc — Vitess 전용 orchestrator. tablet 헬스체크·primary 장애 감지 후 자동 failover 를 수행. Topology server 의 상태와 실제 mysqld 토폴로지를 비교해 정정함.
- Topology server — etcd/ZooKeeper 위에 “어느 샤드에 누가 살아 있고 누가 primary 인가” 를 보관. failover 는 이 포인터 한 번 바꾸는 것으로 끝남.
- Cell — 같은 가용 영역 단위 묶음. 셀 단위로 장애 격리됨. 다이어그램에는 생략됨.
참고
- What Is Vitess — Vitess 가 해결하는 문제와 vanilla MySQL/NoSQL 비교
- Architecture — 컴포넌트 구성도
- Scalability Philosophy — 250GB/인스턴스 권장, 일관성 모델, multi-cell 설계 원칙
- History — YouTube 발 출생 배경과 CNCF Graduation 시점
- Supported Databases — MySQL 8.0/8.4·Percona 호환 범위
- CNCF — Vitess Graduation Announcement (2019-11-05) — 8번째 graduated 프로젝트로 승격 발표