created at 2023-01-08
서론
단방향까지는 구현이 가능했었는데, 양방향(BDR)은 아래의 이유로 굉장히 까다로웠다.
- 컨셉만 존재할 뿐, 코드 레퍼런스가 없다.
현업자분들께 방향성을 여쭙고싶다.
- 두 개의 마스터 노드일 때는 그래도 할 순 있겠지만, 그 이상일 때는 각각을 전부다 설정해줘야하기때문에 상당히 까다롭다.
즉, 클러스터 구현을 직접 해야한다.
- 동시성 문제가 대두된다.
예로 만약 master-db-1과 master-db-2에서 동시에 같은 키의 데이터가 삽입되었을 때 crash error가 발생한다.
일차적 방어방법으로 같은 key가 각각의 DB에 동시적으로 들어오지 못하게 ip 해시값 기반 라우팅 로드 밸런싱을 적용했지만, 누군가 악의적으로 동시에 다른 ip로 같은 key를 삽입요청할 수도 있다.
- 네트워크 장애로 replication data 유실 시, 장애대응이 미비하다.
예로 데이터 유실 시, 다시 replication 데이터를 보내줘야되는데 이런 설정또한 까다롭다.
위의 4가지 이유 이외 진짜 여러가지 문제점이 발생가능하다. 그래서 DBA가 아닌 취준 개발자 입장에서는, 이미 안정적이며 체계적인 cloud의 솔루션을 사용할 수 밖에 없는것 같다.
그런데 너무 비싸다!!!! 필자는 현재 포트폴리오 프로젝트(EC2, route-53), 뱅킹 백엔드 프로젝트(secret, ECR, EKS, etc.)을 사용하고 있는데 한달에 12만원 가량 고정 지출이 발생한다. 여기에 예상되는 postgres DB 비용을 계산해보자면, 다음과 같다.
제일 싼 db.t4g.micro의 시간당 요금 = 0.032 USD * 24시간 * 30일 * 2대 = 46 USD = 57,258 WON. 약 고정지출로 20만원이 사라지게 될것이다. 취준생에게는 매우 큰 돈이다
정말 분산 DB는 MSA에서 빠질 수 없는 주제이며 정말 중요한 기능이다. 하지만 지금은 잠시 위의 이유로 양방향 DB sync는 미뤄두도록 하겠다. 그리고 이제는 Front에 집중을 해볼것이다.