사진·글을 공유하는 가상 SNS를 성장시키며, NHN Cloud RDS for MySQL과 EasyCache로 database의 backup·read scaling·cache·failover·sharding을 단계적으로 설계해 나가는 실전 시나리오다. 각 단계에서 운영 중 놓치기 쉬운 세부 조건과 trade-off를 함께 짚는다.
핵심 포인트- XtraBackup이 일관성을 위해 table lock을 기다리다 긴 query로 실패하는 조건과, lock을 끄면 point-in-time recovery가 제한되는 trade-off, backup window·binary log 보존·타 region Object Storage 복제 설정
- read 부하를 read-only replica로 분산하되 semi-synchronous replication의 relay log 적용 지연(replication lag)을 고려하고, HAProxy를 TCP→MySQL handshake·auth→실제 SELECT 순으로 health check 강화해 장애 node 자동 제외
- 동일 인기 게시물 반복 조회는 EasyCache Redis replication group으로 흡수하되 OS용 memory를 남기도록 maxmemory 신중 설정, Redis 우선 조회 후 cache miss만 HAProxy 경유 replica 조회·갱신
- master/cache 장애 격리를 위해 다른 AZ standby 승격·DNS 전환, 3개 이상 Sentinel 합의 승격, HAProxy 2대+LB 이중화로 단일 장애점 제거하고, 단일 writer 한계는 table·user ID·hash 등 shard key와 분산 transaction·rebalancing 설계로 대응
왜 읽나단일 DB에서 시작해 대용량으로 키우며 backup·replica·cache·HA·sharding을 순서대로 붙여야 하는 백엔드 엔지니어에게, managed DB 운영의 함정과 최종 아키텍처를 짚어주는 실전 가이드.