[1권 - 1장] 사용자 수에 따른 규모 확장성

[KimH4nKyul]

보충 세션간 진행한 1장 사용자 수에 따른 규모 확장성을 읽고 궁금했던 점이나 자신이 겪었던 이슈에 대해 공유하는 시간을 갖습니다.

[yw7148]

1. NoSQL은 언제 사용하는 게 유리할까? 어떤 장점으로 사용하는 걸까?
2. RDBMS는 어떤 장점이 있어서 사용하는 걸까?

[yw7148]

NoSQL: 유연한 스키마, 고성능, 수평 확장성
RDB: 정규화, 트랜잭션, 관계형 쿼리 (Join)

[KimH4nKyul]

왜 RDB 보다 NoSQL 이 더 고성능일까요?
NoSQL로 일관성을 보장하는 방법은 없을까요?

[KimH4nKyul]

NoSQL의 인덱싱 방식은 RDB의 것과 어떻게 다를까?
MSA에서는 왜 NoSQL일까? -> Join 이점을 가져갈 이유가 없어서?
코치님들 -> "꼭 Join 해야 되나? 애플리케이션 조인 하면 되잖아"

[KimH4nKyul]

용한(@yonghanyoon) -> 그러면 MSA가 아닌 환경에서도 NoSQL이 훨씬 좋은거 아닐까?

[KimH4nKyul]

RDB -> 트랜잭션을 통한 일관성 보장과 스키마가 정해져있어 유지보수하기 쉬움?

[KimH4nKyul]

샤딩과 파티셔닝의 차이는 뭐고, 어떤 때 사용해야 효과적일까?

[KimH4nKyul]

[자료 공유]

• 1장 총정리
• 샤딩과 파티셔닝

[KimH4nKyul]

• 효진(@hyojin202406) SPOF가 되진 않을까? -> M-S 구조로 확장한다.
• 각 데이터베이스 마다 샤딩을 설정하는 방법과 샤드로 데이터를 분산 저장하는 방법은 무엇일까?

[hyojin202406]

https://techblog.yogiyo.co.kr/%EC%A3%BC%EB%AC%B8%EC%84%9C%EB%B9%84%EC%8A%A4-shardingsphere-proxy-%EB%8F%84%EC%9E%85%EA%B8%B0-46d83084586b

[KimH4nKyul]

• 데이터베이스가 샤딩한다면 M-S 레이어가 먼저일까 나중일까?

[KimH4nKyul]

[hyojin202406]

1. 메시지 큐의 소비자 작업 성능이 낮아 큐가 가득 차는 문제를 방지하기 위해, 소비자의 처리 능력을 어떻게 확장하거나 최적화할 수 있을까요?
2. 메시지 큐가 가득 차 메시지가 유실될 위험이 있을 때, 메시지를 안전하게 관리하고 손실을 방지하기 위해 사용할 수 있는 전략은 무엇인가요?

[hyojin202406]

• 소비자 작업 성능 확장 및 최적화 방안
  • 스케일 아웃
• 메시지 유실 방지 전략
  • DLQ

@Component
public class MessageListener {

    @RabbitListener(queues = RabbitMQConfig.MAIN_QUEUE)
    public void handleMessage(String message) throws Exception {
        System.out.println("Processing message: " + message);
        
        // 처리 실패 시 Exception 발생
        if (message.contains("error")) {
            throw new Exception("Message processing failed");
        }
    }

    @RabbitListener(queues = RabbitMQConfig.DLQ)
    public void handleDlqMessage(String message) {
        System.out.println("DLQ message received: " + message);
    }
}

@Component
public class KafkaMessageListener {

    @KafkaListener(topics = "main-topic", groupId = "group-id")
    public void listen(ConsumerRecord<String, String> record) throws Exception {
        System.out.println("Processing message: " + record.value());
        
        // 처리 실패 시 Exception 발생
        if (record.value().contains("error")) {
            throw new RuntimeException("Processing failed");
        }
    }

    @KafkaListener(topics = "dlq-topic", groupId = "group-id")
    public void listenToDlq(ConsumerRecord<String, String> record) {
        System.out.println("DLQ message received: " + record.value());
    }
}

[yw7148]

DLQ 처리 방식

• comsumer는 ACK/NACK를 통해 MQ에 성공/실패를 알림
• 실패의 경우 MQ의 재시도 정책 등을 확인 후에 DLQ로 이동

[KimH4nKyul]

이상적인 방식 -> 트랜잭셔널 아웃박스 .. -> 전투력 측정기

[yonghanyoon]

실무에서 아웃박스를 활용하기에 장점보다 단점이 더 많은가?

[KimH4nKyul]

• 인프라 제공만 된다면 아웃박스를 쓰는게 이점이 많다.
• 어디서 장애가 터졌는지 확실하게 알 수 있는 방법 중 하나
• 할 수 있다면 좋지만 여건상 하기 어려운 회사가 많음 -> ㄹㅇ 전투력 측정기 -> 이거 쓰면 좋은 회사

[yonghanyoon]

캐시 보관 만료 정책에 대해 어떤 상황엔 길게 가져가고 어떤 상황엔 짧게 가져갈까?

[KimH4nKyul]

[길게 가져가면 안되는 상황]

• 단시간에 많은 캐시가 확 들어오는 구조 -> 메모리 부족
• 데이터 변동성이 많은 구조 (+ 데이터 일관성이 중요한 경우) -> 1초라도 가져가는게 의미가 있음 -> 콘서트 좌석 선점의 경우는 ㅎㅎ?
• 특히 쿼리가 복잡한 경우
• 3~4초 정도 느린 쿼리는 적어도 3, 4초 캐싱할 필요가 있지 않을까? -> 통계 데이터는 캐싱을 하지 않는 편 -> 통/집계용 테이블이나 MView 같은 걸 두는게 더 효과적일 것임

[KimH4nKyul]

[짧게 가져가면 안되는 상황]

• 유저가 5초 마다 들어오는데, 캐싱은 1초간 유지?
• 영속 저장소와 실시간성이 반영되지 않아도 되는 경우
• 통계성 데이터?
• 최대한 길게 가져가되 일관성과 메모리 문제가 발생하지 않는 선에서 길게 가져가자 (@yw7148 )
• 콘서트 처럼 순간 확 몰리는 것은 어떻게 대처해야 할까?
• 데이터 변동이 거의 없는 부분에 대해 적용 (동하님)

[KimH4nKyul]

[이상적인 상황]

캐시 스토어의 메모리 용량을 압도적으로 높인다. (수직적 확장)

• 스택오버플로우 사례

[KimH4nKyul]

[365일 24시간 자유 토론 내용]
캐싱 전략을 적용해 본 경험 공유

[KimH4nKyul]

[365일 24시간 자유 토론 내용]
로드밸런서를 적용해 본 경험 공유