자체 호스팅한 서비스가 늘면서 문제가 하나 생겼습니다. 하나 늘 때마다 데이터베이스도 하나씩 늘어나는 구조였습니다.
전자서명, 기기 관리, 자동화 도구 — 각자 저장소가 필요합니다. 서비스마다 인스턴스를 세우면 백업도 따로, 모니터링도 따로, 버전 업그레이드도 따로가 됩니다. 서비스 다섯 개면 데이터베이스 다섯 개를 운영하는 일이 됩니다.
하나로 모았다
이미 자체 호스팅하고 있던 PostgreSQL 에 클러스터 내부 로드밸런서를 붙이고, 사내 서비스들이 그것을 바라보게 했습니다. 서비스마다 데이터베이스와 계정을 나누되, 운영해야 할 인스턴스는 하나입니다.
백업 한 번으로 전부 덮이고, 버전을 올릴 때 한 곳만 보면 됩니다. 새 서비스를 붙일 때 데이터베이스는 이미 있는 것을 쓰므로, 도입 비용이 급격히 낮아집니다. 실제로 그 뒤에 올린 서비스들은 저장소 준비 없이 바로 붙었습니다.
대신 격리를 신경 써야 한다
같이 쓰면 편한 만큼, 하나가 다른 것을 볼 수 있게 되면 곤란합니다.
계정을 서비스별로 나누고 권한을 필요한 범위로만 줬습니다. 큐를 쓰는 쪽은 환경별 롤까지 따로 만들어서, 개발용 계정이 스테이징 큐를 아예 볼 수 없게 했습니다. 이름 규칙으로 나누는 것은 관례일 뿐이라 지켜지지 않습니다.
트레이드오프는 분명하다
단일 장애점이 생깁니다. 이 데이터베이스가 죽으면 사내 서비스 여럿이 같이 멈춥니다.
받아들일 수 있었던 이유는 이것들이 전부 사내 도구이기 때문입니다. 고객이 쓰는 서비스라면 다른 판단을 했을 겁니다. 몇 분 멈춰도 되는 것과 안 되는 것을 섞지 않는 게 이 구조의 전제입니다.