이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Managed Service는 어떤 운영 책임을 줄이고 어떤 책임을 남기는가?
- 백엔드 서비스에서 Managed DB, cache, queue를 선택할 때 무엇을 비교해야 하는가?
- Managed Service 장애에서 공급자 문제와 애플리케이션 문제를 어떻게 나눠 보는가?
개요
Managed Service는 클라우드 사업자가 운영의 일부를 대신 맡아 주는 서비스다.
예를 들어 managed DB, managed cache, message queue, object storage, log service가 있다.
직접 VM에 설치해 운영하는 것보다 patch, 장애 조치, 백업, 확장, 모니터링 일부를 덜 신경 쓸 수 있다.
하지만 운영 책임이 사라지는 것은 아니다.
연결 제한, 스키마 설계, 비용, 권한, 장애 시 우회 방식, 서비스 한계는 여전히 애플리케이션 팀이 이해해야 한다.
줄어드는 책임
Managed Service를 쓰면 보통 다음 책임이 줄어든다.
- OS와 engine patch 적용
- 단일 장비 장애 처리
- 기본 백업과 복원 기능
- storage 확장
- 기본 metric 제공
- TLS endpoint와 인증 통합
- 일부 장애 조치 자동화
이 장점 때문에 작은 팀은 직접 운영보다 Managed Service를 우선 검토하는 편이 안전하다.
운영 역량이 부족한 상태에서 DB나 queue를 직접 설치하면 장애 복구와 보안 패치가 큰 부담이 된다.
남는 책임
Managed Service에서도 다음 책임은 남는다.
- schema, index, query 성능
- connection pool 크기와 timeout
- 백업 보관 기간과 복구 테스트
- 장애 조치 시 애플리케이션 retry 동작
- 비용 증가와 quota 초과
- 계정 권한과 secret rotation
- region 선택과 데이터 위치
- 유지보수 창과 배포 일정 조율
- 서비스 한계와 vendor lock-in
“managed”라는 이름은 운영 책임의 일부를 이전한다는 뜻이지 판단을 없앤다는 뜻이 아니다.
선택 기준
Managed Service 선택 전에는 기능 목록보다 운영 질문을 먼저 던진다.
- 우리 팀이 직접 patch와 복구를 할 수 있는가?
- 장애 조치가 자동인지 수동인지 알고 있는가?
- RTO/RPO가 서비스 요구와 맞는가?
- peak traffic에서 connection과 throughput 제한이 충분한가?
- 비용이 traffic, storage, request 수에 따라 어떻게 증가하는가?
- local 개발과 staging 환경에서 같은 방식으로 검증할 수 있는가?
- 장애 시 다른 서비스로 우회할 수 있는가?
- 데이터 이동이 필요한 경우 export가 가능한가?
답하지 못하는 질문은 선택 후 장애 때 비용으로 돌아온다.
Spring 백엔드 관점
Managed DB나 cache는 Spring 설정과 직접 연결된다.
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.connection-timeout=3000
spring.data.redis.timeout=2s이 설정은 서비스 quota와 맞아야 한다.
애플리케이션 instance가 5개이고 pool size가 20이면 DB에는 최대 100개 연결이 열릴 수 있다.
Managed DB의 connection limit이 90이면 평소에는 괜찮아도 배포나 장애 조치 중 연결 실패가 발생한다.
백엔드 개발자는 instance 수, pool size, retry, timeout을 managed service 제한과 함께 설명해야 한다.
장애 분석
Managed Service 장애는 공급자 상태만 보면 부족하다.
다음 축으로 나눠 본다.
- 공급자 service status에 장애가 있는가?
- 우리 계정의 quota나 limit에 닿았는가?
- 특정 region 또는 zone에서만 발생하는가?
- 애플리케이션 connection pool이 과하게 열렸는가?
- retry가 실패를 증폭시키는가?
- 최근 schema, index, 설정 변경이 있었는가?
- 유지보수 창과 배포 시간이 겹쳤는가?
공급자 장애라고 단정하기 전에 우리 설정과 사용량도 함께 확인해야 한다.
장애 신호
- DB CPU는 낮지만 connection limit에 도달한다.
- cache memory eviction이 증가해 응답 시간이 흔들린다.
- queue가 적체되지만 consumer 수를 늘려도 처리량이 증가하지 않는다.
- object storage request 비용이 예상보다 급증한다.
- 유지보수 창 직후 TLS나 endpoint 연결 오류가 발생한다.
- 장애 조치 후 DNS cache 때문에 일부 instance만 이전 endpoint를 본다.
- quota 초과로 새 resource 생성이나 write 요청이 거부된다.
이 신호는 managed service의 한계와 애플리케이션 설정을 함께 봐야 한다.
안전한 완화 조치
- connection limit에 닿으면 pool size와 instance 수를 함께 조정한다.
- retry 폭주가 있으면 retry 횟수와 backoff를 줄인다.
- queue 적체는 producer 중단, consumer 조정, dead letter 확인 순서로 본다.
- cache 장애는 핵심 기능이 DB fallback으로 버틸 수 있는지 확인한다.
- 공급자 장애가 확인되면 status page, support ticket, 내부 영향 범위를 같이 기록한다.
- 비용 폭증은 관련 endpoint, object prefix, query pattern을 먼저 찾는다.
완화는 managed service 설정만 바꾸는 것이 아니라 애플리케이션 사용 패턴도 함께 바꾸는 일이다.
하지 말아야 할 대응
- Managed Service라서 백업과 복원 테스트를 생략하지 않는다.
- connection limit을 확인하지 않고 instance 수만 늘리지 않는다.
- 공급자 장애라고 단정하고 애플리케이션 로그를 보지 않는 상태로 두지 않는다.
- 비용 알림 없이 request 기반 서비스를 공개 endpoint 뒤에 두지 않는다.
- 권한 문제를 해결하려고 admin key를 애플리케이션에 넣지 않는다.
인프라 담당자와 공유할 자료
- 서비스 종류, 이름, region, endpoint
- plan, quota, connection limit, storage limit
- 애플리케이션 instance 수와 pool 설정
- timeout, retry, circuit breaker 설정
- 최근 배포, schema, index, 설정 변경
- 공급자 status와 support ticket 여부
- 비용 또는 사용량이 급증한 시간대
공유 자료는 “managed DB가 느리다”가 아니라 “이 제한과 이 사용량이 충돌한다”로 정리해야 한다.
운영 체크리스트
- 직접 운영과 Managed Service의 책임 분리가 문서화되어 있는가?
- RTO/RPO와 백업 보관 기간이 서비스 요구와 맞는가?
- connection pool 합계가 서비스 limit보다 낮은가?
- 유지보수 창과 배포 시간이 충돌하지 않는가?
- quota와 비용 알림이 설정되어 있는가?
- 장애 조치 후 애플리케이션이 재연결할 수 있는가?
- export와 migration 가능성이 검토되어 있는가?
확인 질문
확인 질문
- Managed Service가 줄이는 책임과 남기는 책임은 어떻게 다른가?
- patch와 기본 장애 조치는 줄지만 설정, 사용량, 비용, 권한, 데이터 모델 책임은 남는다.
- Spring datasource pool을 Managed DB limit과 함께 봐야 하는 이유는 무엇인가?
- instance 수와 pool 크기의 합이 connection limit을 넘으면 장애가 나기 때문이다.
- 공급자 장애와 애플리케이션 문제를 나눌 때 확인할 축은 무엇인가?
- service status, quota, region, connection, retry, 최근 변경, 유지보수 창이다.
리뷰 체크포인트
- Managed Service 선택 기준이 비용과 운영 책임까지 포함하는가?
- 애플리케이션 설정과 서비스 limit이 연결되어 있는가?
- 백업/복구와 장애 조치 방식을 확인했는가?
- quota와 비용 알림이 있는가?
- vendor lock-in과 export 가능성을 검토했는가?