DB에서 Application의 Read(읽기)와 Write(쓰기)를 분리하는 이유 241231

q1: DB에서 Application의 Read(읽기)와 Write(쓰기)를 분리하는 이유

a1:

DB에서 Application의 Read(읽기)와 Write(쓰기)를 분리하는 이유는 성능 최적화와 확장성을 위해서입니다. 데이터베이스의 읽기와 쓰기 작업은 성격이 다르고, 이를 분리하면 시스템 리소스를 효율적으로 사용하면서 더 높은 성능과 안정성을 제공할 수 있습니다.

1. 주요 이유

1) 읽기 요청과 쓰기 요청의 특성 차이
• 읽기(Read):
• 데이터베이스에서 정보를 조회하는 작업으로, 일반적으로 트래픽이 많고 반복적인 요청이 발생.
• 캐싱과 읽기 전용 복제본(Read Replica) 활용이 가능.
• 쓰기(Write):
• 데이터를 삽입, 수정, 삭제하는 작업으로, 데이터 무결성과 일관성을 보장하기 위해 추가적인 처리(트랜잭션, 잠금 등)가 필요.
• 성능 상 상대적으로 더 많은 리소스를 소모.

2) 성능 향상
• 읽기 작업이 많은 경우 쓰기 작업과 함께 처리하면 성능 병목이 발생할 가능성이 높음.
• 읽기 요청을 읽기 전용 DB(Read Replica)로 분산시키면 **주 데이터베이스(Primary DB)**의 부하가 줄어듦.

3) 확장성
• 읽기와 쓰기를 분리하면 읽기 작업을 처리하는 **복제본(Replica)**을 추가하여 트래픽 증가에 대응 가능.
• 쓰기는 주 데이터베이스에서만 처리하여 데이터 일관성을 유지.

4) 장애 복구와 안정성
• 주 데이터베이스에 문제가 생기더라도 읽기 복제본(Read Replica)은 별도로 동작하므로 읽기 작업은 지속 가능.
• 장애 시, 읽기 전용 복제본을 활용해 신속히 복구할 수 있음.

2. 구현 방법

1) 데이터베이스 복제 (Replication)
• 데이터를 주 데이터베이스(Primary DB)에서 읽기 복제본(Read Replica)으로 복사.
• 쓰기 요청은 Primary DB로 보내고, 읽기 요청은 Read Replica에서 처리.

2) 애플리케이션 계층에서의 분리
• 애플리케이션에서 읽기 요청과 쓰기 요청을 구분하여 각각 다른 DB로 라우팅.
• 예: ORM(Object-Relational Mapping) 툴에서 read와 write 연결을 따로 설정.

3) 로드 밸런싱
• 읽기 요청이 여러 복제본에 균등하게 분산되도록 로드 밸런서를 사용.

3. 사용 사례

1) 전자상거래 플랫폼
• 제품 정보 조회(읽기)가 대량으로 발생.
• 주문 생성, 결제 정보 기록(쓰기)은 상대적으로 적음.

2) 소셜 네트워크 서비스
• 사용자 피드 조회(읽기)가 빈번.
• 게시물 작성, 댓글 달기(쓰기)는 비교적 적음.

3) 로그 시스템
• 대량의 데이터가 쓰기 작업으로 기록됨.
• 하지만 분석이나 모니터링을 위해 읽기 작업은 실시간으로 많이 발생.

4. 장점과 단점

장점
• 성능 최적화: 읽기와 쓰기의 리소스 경쟁을 줄임.
• 확장성: 읽기 작업에 대한 수평 확장 가능.
• 안정성: 읽기 복제본을 활용해 장애 복구 속도를 높임.

단점
• 복잡성 증가: 읽기와 쓰기를 분리하면서 애플리케이션 및 DB 설정이 복잡해짐.
• 일관성 문제: 복제본 간 동기화 지연으로 인해 읽기 작업에서 최신 데이터가 보이지 않을 수 있음(최종적 일관성).

결론

읽기와 쓰기를 분리하면 성능과 확장성을 크게 개선할 수 있지만, 데이터 일관성을 관리하기 위해 신중한 설계와 구현이 필요합니다. 특히 대규모 트래픽을 처리해야 하는 애플리케이션에서 필수적인 아키텍처입니다.