[1단계 - DB 복제와 캐시] 테드(김규태) 미션 제출합니다.

[Kimprodp]

안녕하세요 뽀로로~

오랜만입니다. 잘 지내시죠? 😁

복제와 캐시 미션 1단계 완료하여 PR 요청 드립니다.
DB 설정과 복제가 제대로 되지 않아서 삽질 좀 하다가 늦어졌네요..

복제 지연에 대한 해결책으로 저는 단순하게 reader 에서 조회할 경우 writer를 확인하여 가져오는 방법을 선택했습니다.

어떤 방법으로 할까 고민하면서 여러 방법들을 생각했는데, 이 방식을 선택한 이유를 같이 남겨요.

• 도커에 있던 redis를 사용할까 했으나, 현재 구조나 단계에서 너무 과한 방법이 아닌가 생각했어요.
• 그렇다고 인메모리 캐시를 고려하면 스케일 아웃 상황이 걸렸습니다.
• write 한 트랜잭션은 조회할 때 writer DB를 사용하는 방식은 다른 트랜잭션에서 조회할 때 역시 지연이 발생하면 찾지 못하게 될 수 있다고 생각해요. 사실 이런 케이스(누군가 생성한 쿠폰을 다른 누군가 조회)는 거의 없을 것 같지만, 또 다른 이유로 write 후에는 무조건 writer DB를 사용하니, write 작업이 많다면 writer DB에게 부담이 될 수 있다고 생각합니다.
• 읽기 자체를 지연하는 것은 지연 시간을 알지 못하기도 하고, 지연이 아니라 복제가 안된 경우는 아예 찾지 못하게 되니 제외했습니다.

제가 선택한 방식(reader 에서 조회할 경우 writer를 확인하여 가져오는 방법)은 조회 때 마다 데이터가 없다면 writer DB를 확인한다는 로직이 있으나, 사실 지연되는 특수한 경우 외에는 reader DB 선에서 가져오고 끝나기 때문에 writer DB까지 확인하는 다음 로직을 가는 일이 별로 없을 거라 생각했어요. 진짜 지연이 발생한 경우만 writer DB를 확인하니까요. 또한 지연이 아니라 복제가 되지 않은 경우에도 문제 없이 조회할 수 있게 됩니다. 현재 단계에서 단순하면서도 지연에 대한 해결책으로 적합하다 생각해서 적용해봤습니다.

생각나는 방법 중에는 이게 제일 나은 것 같아요.. 혹시 더 좋은 방법이 있을까요?

그럼 리뷰 잘 부탁드려요~ 😊

---

DB는 도커 빌드할 때 데이터베이스 생성되게 하려 했는데, 방법이 이상한지 실패했습니다..
직접 접속해서 CREATE DATABASE coupon; 해야 합니다 😢