4편 · 약 24분

Azure Database 서비스: MySQL/PostgreSQL Flexible Server 운영

Azure 관리형 DB 서비스 현황

Azure에서 MySQL과 PostgreSQL을 관리형으로 운영한다면 Flexible Server가 현재의 주력 선택지다. 이전 세대인 Single Server는 2024년 9월 퇴역(retirement)했다. 마이그레이션 대상이 남아있다면 Flexible Server로 전환이 필요하다.

Flexible Server는 Single Server 대비 세 가지 측면에서 향상됐다.

HA 옵션 다양화: Zone-Redundant HA와 Same-Zone HA 선택 가능.
더 많은 파라미터 제어: OS와 DB 엔진 설정에 더 넓은 접근 권한.
연결 관리 개선: PostgreSQL 기준 PgBouncer 내장.

Flexible Server 스토리지 아키텍처

Flexible Server는 AWS RDS/Aurora나 Cloud SQL과 달리 Azure Files Premium을 스토리지 백엔드로 사용한다. 컴퓨트 노드(MySQL 또는 PostgreSQL 엔진이 실행되는 VM)와 스토리지(데이터 파일, redo 로그, 바이너리 로그)가 분리되어 있다.

Zone-Redundant HA 구성: ZRS(Zone-Redundant Storage) Premium 파일 공유 사용. 동일 리전 내 3개 AZ에 걸쳐 동기적으로 복제.
Same-Zone HA 또는 비HA 구성: LRS(Locally Redundant Storage) Premium 파일 공유 사용. 단일 데이터센터 내 복제.

이 구조 덕분에 HA Standby 노드는 Primary와 동일한 파일 공유에 접근할 수 있다. 페일오버 시 Standby는 남은 바이너리 로그를 적용한 뒤 Primary 역할을 맡는다.

Azure Flexible Server HA 구성 비교

HA 옵션 선택 기준

Azure Flexible Server는 세 가지 HA 옵션을 제공한다.

항목	Zone-Redundant HA	Same-Zone HA	HA 없음
RPO	0 (무손실)	0 (무손실)	백업 기준
RTO	60~120초	~60초 이내	N/A
존 장애 보호	✓	✗	✗
스토리지	ZRS Premium	LRS Premium	LRS Premium
Standby 읽기	불가	불가	N/A
비용	가장 높음	중간	가장 낮음
사용처	프로덕션, 규정 준수	비용 절감 + HA	개발/테스트

주의사항:

Zone-Redundant HA는 서버 생성 시에만 활성화 가능. 사후 전환 불가.
Burstable 티어는 HA를 지원하지 않는다.
Zone-Redundant HA의 ZRS 쓰기는 3개 AZ에 동기 복제되므로 쓰기 지연이 5~10% 증가한다.
HA Standby는 읽기 트래픽을 처리할 수 없다. 읽기 분산은 Read Replica를 별도로 사용해야 한다.

읽기 복제본

항목	MySQL Flexible Server	PostgreSQL Flexible Server
복제 방식	비동기 (binlog 기반)	비동기 (WAL 기반)
최대 복제본 수	10개	5개
교차 리전	✓	✓
승격 가능	✓ (독립 인스턴스로)	✓ (독립 인스턴스로)
복제본 읽기 가능	✓	✓
복제본의 HA	✓ (별도 HA 설정 가능)	✓

복제본은 HA Standby와 완전히 별개다. Standby는 페일오버용이고, 복제본은 읽기 분산용이다.

복제 lag 모니터링: Azure Monitor의 Replication lag in seconds 지표로 확인. 쓰기 부하에 따라 수초~수분 가변.

MySQL Flexible Server: 연결 관리

MySQL Flexible Server는 내장 커넥션 풀러가 없다. 고연결 환경에서는 외부 커넥션 풀러를 사용해야 한다.

max_connections 계산 공식

연결 한도는 인스턴스 메모리에 비례한다.

max_connections ≈ RAM(GB) × 85

예:
- Standard_D4ads_v5 (4 vCore, 16 GB RAM) → 약 1,365 연결
- Standard_E8ds_v4 (8 vCore, 64 GB RAM) → 약 5,461 연결
- Standard_B1s (1 vCore, 1 GB RAM) → 약 85 연결

연결 한도를 초과하면 ERROR 1040 (08004): Too many connections 오류가 발생한다.

고연결 환경 권장 패턴

애플리케이션 → [ProxySQL / HAProxy] → MySQL Flexible Server

또는:

애플리케이션 → Azure App Service 연결 풀링 → Flexible Server

Microsoft는 고연결 환경에 ProxySQL 사용을 권장한다. ProxySQL은 쿼리 라우팅, 읽기/쓰기 분리, 연결 멀티플렉싱을 지원한다.

PostgreSQL Flexible Server: 내장 PgBouncer

PostgreSQL Flexible Server의 핵심 차별점은 PgBouncer 내장이다. 별도 VM에 PgBouncer를 설치·운영할 필요 없이 서버 자체에서 커넥션 풀링을 제공한다.

연결 방식:
port 5432 → PostgreSQL 직접 연결 (max_connections 적용)
port 6432 → 내장 PgBouncer 경유 (풀링 후 DB 연결)

내장 PgBouncer는 트랜잭션 풀링(transaction pooling) 모드로 동작한다. 수천 개의 애플리케이션 연결을 소수의 실제 DB 연결로 멀티플렉싱할 수 있다.

PgBouncer 주요 서버 파라미터:
- pgbouncer_max_client_conn: 최대 클라이언트 연결 수
- pgbouncer_pool_mode: transaction (기본), session, statement
- pgbouncer_min_pool_size: 풀 최소 유지 연결 수
- pgbouncer_server_idle_timeout: 유휴 서버 연결 timeout

트랜잭션 풀링 모드의 주의점: 트랜잭션 풀링 모드에서는 SET 명령, 임시 테이블, Prepared Statement를 세션 간에 공유할 수 없다. 드라이버나 ORM에 따라 호환성 확인이 필요하다.

PostgreSQL Flexible Server: Citus 확장

PostgreSQL Flexible Server에서 Citus 확장을 활성화하면 단일 노드 PostgreSQL을 분산 데이터베이스로 변환할 수 있다.

Citus 활성화 시:
- 코디네이터 노드: 쿼리 파싱·분산·집계
- 워커 노드: 실제 데이터 샤드 저장 및 처리
- 애플리케이션: 코디네이터 하나에만 연결

Citus는 대규모 멀티테넌트 SaaS 또는 수십~수백 TiB 규모의 분석 워크로드에 적합하다. 단일 Flexible Server 인스턴스의 처리 한계를 넘어야 할 때 선택한다.

PostgreSQL Flexible Server에서 활용 가능한 주요 확장:

pgvector: AI 벡터 유사도 검색
TimescaleDB: 시계열 데이터 최적화
PostGIS: 지리 공간 데이터
pg_stat_statements: 쿼리 성능 분석
Citus: 분산 PostgreSQL

Azure Monitor: 핵심 모니터링 지표

지표	의미	알림 기준
`cpu_percent`	CPU 사용률	80% 초과 지속
`memory_percent`	메모리 사용률	90% 초과
`io_consumption_percent`	IOPS 사용률	80% 초과
`active_connections`	현재 연결 수	max_connections의 80%
`connections_failed`	연결 실패 수	급격한 증가 시
`storage_percent`	스토리지 사용률	80% 초과
`Replication lag in seconds`	읽기 복제본 지연	30초 초과
`network_bytes_egress`	아웃바운드 트래픽	급격한 증가 감시

페일오버 대응 체크리스트

페일오버 준비:
1. 연결 재시도 로직 구현 (최대 3회, 지수 백오프)
2. 연결 timeout을 충분히 설정 (RTO 기준: 120~180초)
3. HA Standby는 읽기 불가 — Read Replica 별도 구성
4. 계획된 페일오버(Planned Failover) 기능으로 정기 드릴
5. Azure Monitor 알림으로 페일오버 이벤트 탐지
6. 읽기 복제본: 페일오버 후 자동 재연결 확인 필요

AWS vs GCP vs Azure 비교 요약

기준	AWS	GCP	Azure
MySQL 주력 서비스	RDS for MySQL / Aurora MySQL	Cloud SQL for MySQL	MySQL Flexible Server
PostgreSQL 주력	RDS for PostgreSQL / Aurora PG	Cloud SQL for PG / AlloyDB	PostgreSQL Flexible Server
HA 스토리지	EBS Multi-AZ 동기복제	Regional Persistent Disk	ZRS Azure Files Premium
HA Standby 읽기	불가 (Multi-AZ Instance)	불가	불가
읽기 복제 lag	수초~수십초	수초~수십초	수초~수분
클라우드 네이티브 DB	Aurora (MySQL/PostgreSQL)	AlloyDB (PostgreSQL)	— (SQL Server Hyperscale)
연결 풀러 내장	RDS Proxy (별도 유료)	없음 (Proxy 등 외부)	PostgreSQL: PgBouncer 내장
분산 PostgreSQL	Aurora Limitless, Citus on RDS	AlloyDB + Citus	Citus on Flexible Server
최대 스토리지	64TB (RDS), 128TiB (Aurora)	64TB (Cloud SQL), 자동확장 (AlloyDB)	32TiB (Flexible Server)

선택 가이드:

이미 AWS 생태계에 있고 MySQL이 주력이면 → RDS/Aurora
PostgreSQL + HTAP 혼합 워크로드, GCP 환경이면 → AlloyDB
Azure 환경 + PostgreSQL + 연결 폭발 우려 → PostgreSQL Flexible Server (PgBouncer 내장)
어느 클라우드든 분산 PostgreSQL이 필요하면 → Citus 확장 (공통)

References

https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-high-availability
https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-read-replicas
https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage
https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-server-parameters
https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-supported-versions
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-high-availability
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions
https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-read-replicas
https://techcommunity.microsoft.com/blog/adformysql/announcing-extended-support-for-azure-database-for-mysql/4442924
https://techcommunity.microsoft.com/blog/adformysql/azure-database-for-mysql-8-4-now-generally-available/4448971