문제를 풀어봅시다 1

[renechoi]

문제

당신은 금융 거래를 처리하는 웹 애플리케이션을 운영하고 있으며, 하루 평균 100만 명의 사용자가 이용하고 있습니다. 사용자들은 계좌 조회, 자금 이체, 거래 내역 확인 등의 기능을 사용합니다. 특히 오전 9시부터 11시, 오후 8시부터 10시 사이에 트래픽이 집중되어, 시스템은 최대 초당 10,000 QPS(Query Per Second) 의 요청을 처리해야 합니다. 그러나 이 시간대에는 시스템 응답 속도가 현저히 느려져 사용자 경험에 부정적인 영향을 미치고 있습니다.

현재 시스템은 MySQL 기반의 단일 마스터 데이터베이스를 사용하여 모든 읽기 및 쓰기 요청을 처리하고 있으며, CPU 사용률은 85%를 초과하고 있습니다. I/O 대기 시간 또한 증가하고 있어, 읽기와 쓰기 성능 모두 저하되고 있습니다. 특히 단일 마스터 구조로 인해 하나의 노드에 모든 부담이 집중되고 있어 시스템의 안정성이 위협받고 있습니다.

피크 시간대의 트래픽은 다음과 같습니다:

• 읽기 요청: 초당 약 8,000 QPS
• 쓰기 요청: 초당 약 2,000 QPS

현재 MySQL 서버는 최대 초당 1,000 QPS 의 처리량을 감당할 수 있습니다(읽기 및 쓰기 요청 포함). 이 중 쓰기 요청은 트랜잭션 처리와 데이터 일관성을 보장해야 하므로, 성능에 더 큰 영향을 미칩니다. 그러나 시스템의 요구 사항인 10,000 QPS는 MySQL 서버의 처리 용량을 훨씬 초과하고 있어, 피크 시간대에는 성능 저하가 발생하고 있습니다.

이러한 상황에서, 시스템의 확장성과 안정성을 높이기 위해 어떤 조치를 취할 수 있을까요?

힌트

1. 애플리케이션 서버는 이미 수평 확장이 완료되어 있습니다. 병목 현상은 데이터베이스 계층에서 발생하고 있습니다.
2. NoSQL 전환은 데이터 일관성 요구사항 때문에 적합하지 않다고 가정합니다.
3. 데이터베이스 계층에서의 확장성을 고려하여 솔루션을 제시해 보세요.

[renechoi]

현재 성능 저하의 정확한 영향 범위는 무엇인가요 ? 그러니까, 데이터베이스 처리 속도 지연이 전체 응답 시간에 미치는 영향이 몇 초 이상인지를 확인하고 싶습니다. api에서 전체 응답 시간과 성능 지연으로 발생하는 지연이 어느 정도인지 궁금합니다. 또한, 성능 문제가 특히 심각하게 발생하는 기능(예: 자금 이체, 계좌 조회)이 있나요?

[renechoi]

좋은 질문입니다. 😀 성능 저하가 구체적으로 어떤 영향을 미치는지 말씀드릴게요.

우선, 현재 피크 시간대에 저희 시스템은 일반적으로 응답 시간을 1초 이하로 유지하는 것을 목표로 하고 있습니다. 하지만 최근 데이터베이스 처리 속도가 느려지면서, 주요 기능에서 2초에서 3초 정도까지 응답 시간이 증가하고 있어요. 특히, 자금 이체나 거래 처리 같은 트랜잭션이 포함된 요청은 더 심각해서 최대 5초 이상 지연되는 경우도 발생합니다.

역시 가장 두드러지는 기능은 자금 이체와 계좌 조회 기능인데요. 자금 이체는 트랜잭션을 필요로 하다 보니 쓰기 부하가 상당히 높고, 일관성을 꼭 유지해야 해서 성능에 큰 영향을 받고 있습니다. 반면, 계좌 조회는 피크 시간대에 워낙 많은 읽기 요청이 몰리면서 응답 시간이 길어지는 상황입니다.

그 외에, 거래 내역 확인 기능도 성능 저하가 나타나고 있는데, 이것 역시 읽기 요청이 많아서 피크 때 부하가 집중되고 있는 상태입니다.

답변이 되셨을까요?

[renechoi]

또 한가지 질문드리고 싶은 것이... 데이터 일관성에 대한 구체적인 요구사항은 어떻게 되는지입니다. 물론 금융 서비스이기 때문에 일관성은 매우 중요할 것 같은데요. 그런데 모든 읽기 요청에서 최신 데이터를 필요로 하는 것인지, 일부 조회는 약한 일관성을 허용할 수 있는 것인지 궁금합니다.

[renechoi]

아, 아주 중요한 포인트를 짚어주셨습니다. 맞습니다, 금융 서비스이기 때문에 데이터 일관성은 정말 중요하게 고려됩니다. 하지만 모든 기능에서 강한 일관성이 필요한 것은 아닙니다.

구체적으로 말씀드리면, 자금 이체나 잔액 조회 같은 거래와 직접 관련된 요청은 반드시 최신 데이터를 기반으로 해야 합니다. 이런 요청들은 실시간 일관성이 보장되어야 하기 때문에, 강한 일관성을 유지하는 것이 필수적입니다.

반면에, 거래 내역 조회나 일부 통계 정보 같은 경우는 약한 일관성이 허용될 수 있습니다. 예를 들어, 거래 내역이 몇 초 정도 지연되어 보이더라도 서비스의 본질적인 신뢰성에는 큰 문제가 없기 때문입니다. 이 경우에는 약한 일관성을 유지하면서 성능을 높일 수 있는 캐싱 같은 접근도 고려할 수 있습니다.

그래서, 요약하자면 핵심적인 금융 트랜잭션에는 강한 일관성이 필수지만, 일부 조회성 데이터는 약한 일관성으로도 허용될 수 있다는 점입니다.

[renechoi]

아 네 이해했습니다. 이제 답변을 드려보려고 합니다. 먼저 제가 주목하고 싶은 부분은 문제의 본질인 병목에 대해서인데요. 문제의 핵심은 단일 MySQL 마스터가 처리할 수 있는 한계를 넘어서는 트래픽에서 시작하는 것 같습니다. 즉, 읽기와 쓰기 요청을 단일 서버가 모두 떠안고 있어 마스터에 과부하가 발생한 것이죠.

네, 좋은 접근입니다. 단일 마스터에 과부하가 발생하고 있다는 점이 문제의 핵심이죠. 그렇다면 이 부분을 해결하기 위해 어떻게 할 수 있을까요?

네, 병목이 핵심이니 그 부분을 개선해주는 것입니다. 우선 읽기 요청과 쓰기 요청을 분리하는 것이 가장 중요한 접근이라고 생각합니다. 예를 들어, MySQL 레플리카 구조를 활용해서 읽기 전용 복제본(Read Replica)을 추가하고, 읽기 트래픽을 여러 복제본에 분산시키면 마스터에 가해지는 부하를 크게 줄일 수 있을 것입니다. 이렇게 하면 마스터는 쓰기 요청에만 집중할 수 있게 되어 성능이 안정화될 것입니다.

말씀하신 대로 읽기/쓰기 분리는 실질적인 성능 개선에 효과적이겠네요. 그런데 복제본을 사용하면 그 나름대로 또 여러 문제들이 생길 수 있을 것 같은데요. 어떤 게 있을까요 ?

일관성 문제가 있을 것 같습니다.

우선, 일관성 문제는 여러 원인으로 발생할 수 있는데, 대표적인 이유는 동기화 지연 현상을 들 수 있을 것 같아요. 마스터에서 처리된 변경 사항이 복제본에 즉시 반영되지 못해서 발생하는 문제입니다. 예를 들어, 사용자가 자금 이체를 완료한 직후에 계좌 잔액을 확인하려고 할 때, 복제본에 동기화가 완료되지 않으면 사용자가 실제보다 낮은 잔액을 확인하게 될 것입니다.

하지만 동기화 지연 이외에도, 데이터 유실이나 복제 오류로도 일관성 문제가 발생할 수 있을 텐데요. 예를 들어, 네트워크 지연이나 장애로 인해 마스터에서 복제본으로의 전송 중 일부 데이터가 손실되거나, 복제 설정이 올바르게 되지 않아 특정 트랜잭션이 일부 복제본에 반영되지 않을 수 있습니다.

네, 좋은 점들을 잘 짚어주셨습니다. 읽기 전용 복제본을 사용할 때 일관성 문제와 동기화 지연이 발생할 수 있다는 점을 잘 설명해주셨네요.

그렇다면 여기서 궁금한 점이 있습니다. 어떻게 복제본의 일관성을 유지할 수 있을지 또는 동기화 지연을 줄일 수 있는 구체적인 방법에는 어떤 것이 있을까요? 금융 서비스에서는 특히 자금 이체나 잔액 조회와 같이 실시간성을 보장해야 하는 요청에서 최신 데이터를 어떻게 보장할 수 있을지에 대한 고민이 필요할 것 같습니다. 이 부분에 대해 어떻게 접근하실지 듣고 싶습니다.

제 생각에는 두 가지 방법이 있을 것 같습니다. 첫 번째는 특정 요청에 대해서는 강한 일관성을 보장하도록 하는 것입니다. 즉, 중요한 요청은 마스터에서 직접 처리하는 것입니다. 예를 들어, 자금 이체 직후에 즉시 잔액을 확인하려는 요청은 마스터에서 직접 보내도록 하고, 읽기 지연이 크게 상관 없는 거래 내역 조회 같은 경우에만 복제본을 사용하는 것입니다. API 레벨에서부터 읽기 요청을 분리하여 마스터와 복제본 참조 경로를 다루는 것도 한 방법이지 않을까 싶습니다.

두 번째는 동기화 방식 자체를 조정해보는 것입니다. 기본적으로 MySQL의 복제는 비동기 방식을 사용하는 것으로 알고 있는데요. 반동기화(semi-synchronous replication)를 설정하면 마스터에서 트랜잭션을 커밋할 때 적어도 하나의 복제본이 해당 변경 사항을 수신할 때까지 대기하게 됩니다.

그렇다면, 그냥 동기화를 사용해도 되지 앟나요? 굳이 반동기화를 사용해야 할 이유가 있을까요? 오히려 특정 레플리카에만 동기화되고 트랜잭션이 종료되면, 위에서 언급한 일관성 문제가 크게 해결되지 않을 것 같고, 오히려 더 혼란스러울 수도 있을 것 같은데요?

단순 비동기화가 아닌 반동기화를 선택하는 이유는 일관성을 좀 더 보장하면서도, 완전한 동기화의 성능 부담을 줄이기 위해서입니다.

비동기화 방식은 확실히 성능상 유리하지만, 금융 서비스처럼 실시간성이 중요한 환경에서는 일관성 측면에서 다소 위험할 수 있습니다. 예를 들어, 비동기화에서는 트랜잭션이 마스터에서 완료되더라도 복제본에 언제 반영될지 보장할 수 없기 때문에, 자금 이체나 잔액 조회 같은 중요한 요청에서는 데이터 일관성 문제가 발생할 가능성이 큽니다.

반면, 반동기화 방식은 트랜잭션이 마스터에서 커밋될 때 적어도 하나의 복제본이 해당 트랜잭션을 수신했음을 확인한 후 마스터에서 커밋을 완료합니다. 이를 통해 완전한 동기화 방식의 높은 오버헤드 없이도, 복제본이 최신 상태를 유지하도록 도울 수 있습니다. 특히 금융 서비스와 같은 환경에서는 동기화 지연을 줄이고, 중요한 데이터의 일관성을 더 잘 유지하는데 반동기화 방식이 효과적입니다.

물론 반동기화 방식에서도 복제본 간의 미세한 지연은 있을 수 있지만, 적어도 하나의 복제본이 최신 상태를 반영하게 되므로, 여러 복제본을 두는 경우에 비해 데이터 일관성을 보장할 수 있는 확률이 더 높아집니다. 이런 이유로 금융 서비스와 같이 실시간 일관성이 중요한 상황에서는 반동기화 방식이 적절하다고 판단했습니다.

좋은 관점입니다. 그런데, 여기서 다시 처음 문제로 돌아가서 현재 해결 방법이 실제로 문제를 완화할 수 있는지 조금 더 검토해보면 좋겠습니다.

현재 문제는 단일 MySQL 마스터가 초당 최대 10,000 QPS의 요청을 처리해야 하는 상황에서 발생하고 있습니다. 이 중 읽기 요청이 약 8,000 QPS, 쓰기 요청이 약 2,000 QPS를 차지하고 있습니다. 그런데 현재 시스템의 MySQL 서버는 초당 최대 1,000 QPS를 감당할 수 있는 용량을 초과하고 있습니다. CPU 사용률은 이미 85%를 넘었고, I/O 대기 시간도 증가하면서 시스템 성능이 현저히 저하되고 있는 상황이죠. 지금 제시하신 방법은 읽기 DB와 쓰기 DB를 분리하는 것이었는데요. 그렇다면 구체적으로 MySql DB 몇 대를 어떻게 구성해야 할지 실무 관점에서 직접 서버를 어떻게 구성하실 것인지 한번 그려주실 수 있으신가요?

네, 그러면 실제 구성 방식을 좀 더 구체적으로 설명드리겠습니다.

현재 문제는 읽기 요청이 8,000 QPS, 쓰기 요청이 2,000 QPS로 나뉘어 있고, MySQL 단일 마스터 서버가 이 트래픽을 모두 감당하기 어려운 상황입니다. 이를 해결하기 위해, 우선 쓰기 전용 마스터 서버와 여러 개의 읽기 전용 복제본 서버를 나눠서 구성할 계획입니다.

1. 쓰기 전용 마스터 서버부터 설명드리면, 트랜잭션 처리나 자금 이체 같은 즉각적인 일관성이 필요한 쓰기 요청(2,000 QPS)은 이 마스터 서버에서 처리합니다. 여기에는 강한 일관성을 보장해야 하므로, 쓰기 전용으로 두고 반동기화 방식으로 복제본에 동기화합니다. 그리고 장애 대비를 위해 백업 마스터 서버를 구성해서, 장애 발생 시 빠르게 페일오버하도록 설정할 예정입니다.

2. 읽기 요청 처리는 8,000 QPS를 목표로 읽기 전용 복제본 서버를 총 8대 두어, 각 복제본이 약 1,000 QPS를 처리할 수 있도록 합니다. 이렇게 하면 읽기 요청이 복제본 서버들에 분산되기 때문에 마스터의 부담을 크게 줄일 수 있습니다. 읽기 전용 복제본은 주로 계좌 조회나 거래 내역 조회와 같이 실시간 일관성이 아주 엄격하게 요구되지 않는 요청을 처리하게 됩니다.

3. 또한, 복제본 서버로의 로드 밸런싱이 필요하기 때문에 로드 밸런서를 두어 요청을 고르게 분배하도록 하고요. 추가로 Redis 같은 캐시도 적용해서, 자주 조회되는 데이터를 캐시에 저장해 빠르게 응답하도록 하겠습니다. 이렇게 캐시를 사용하면 데이터베이스 부하가 더 줄어들어 전체적인 성능이 개선될 수 있습니다.

4. 마지막으로, 동기화 지연을 줄이기 위해 모니터링 시스템을 통해 복제본의 동기화 상태를 실시간으로 추적하고, 문제가 발생하면 바로 알림을 받도록 구성하겠습니다. 이렇게 하면 시스템 성능을 안정적으로 유지할 수 있을 것으로 생각됩니다.

이 구성을 통해 읽기/쓰기 분리가 확실히 되고, 총 10,000 QPS의 트래픽을 안정적으로 처리할 수 있을 것 같습니다.

좋습니다. 그런데 현재 단일 MySql 서버는 최대 1,000 QPS만을 감당할 수 있는 상황입니다. 그렇다면 마스터 서버 하나만으로 쓰기 요청을 전부 감당하지 못할 것 같은데요? 어떻게 생각하시나요?

흠... 네. 현재 단일 MySQL 서버가 최대 1,000 QPS까지 처리할 수 있는 상황이라면... 피크 시간대의 2,000 QPS 쓰기 요청을 단일 마스터가 전부 감당하기엔 무리가 있을 것 같네요.

그렇다면 결국 멀티 마스터로 구성을 하거나 아니면 샤딩을 통해 쓰기 요청을 분산하는 방법을 고려해야 할 것 같습니다. 먼저 질문을 드려보고 싶은데요.

우선, 현재 시스템에서 처리하는 쓰기 요청의 특성이 궁금합니다. 예를 들어, 쓰기 요청이 특정 테이블에 집중되는 경향이 있는지, 아니면 여러 테이블에 고르게 분산되는지에 따라 샤딩 방식이나 멀티 마스터 선택에 영향을 줄 수 있을 것 같습니다.

또 하나는, 읽기와 쓰기 요청의 트래픽 패턴에 대한 건데요. 특정 시간대에 특히 읽기 요청이 더 집중된다든지, 혹은 어떤 기능에서 쓰기 요청이 많이 발생하는 경향이 있는지 궁금합니다. 이런 정보가 있으면, 마스터-슬레이브 구조와 캐시를 활용하는 방식도 고려해볼 수 있을 것 같아서요.

마지막으로, 피크 시간대에만 2,000 QPS 쓰기 요청이 발생하는지, 또는 트래픽 증가로 인해 QPS가 더욱 높아질 가능성도 있는지 알고 싶습니다.

좋은 질문들이네요. 하나씩 답변드리겠습니다. 😊

1. 쓰기 요청의 특성에 대해 말씀드리면, 현재 쓰기 요청은 특정 테이블에 다소 집중되는 경향이 있습니다. 주로 자금 이체나 거래 기록 업데이트와 같은 요청이 잦고, 금융 트랜잭션에서 발생하는 쓰기 요청은 대부분 이 테이블에 모이게 됩니다. 따라서 트랜잭션이 많은 시간대에는 쓰기 부하가 더 커지는 상황입니다.

2. 읽기와 쓰기 요청의 트래픽 패턴에 대해서는, 읽기 요청은 피크 시간대인 오전 9시에서 11시, 그리고 저녁 8시에서 10시에 특히 집중됩니다. 이런 시간대에는 계좌 조회나 거래 내역 조회 같은 읽기 요청이 급증하는데요, 자금 이체와 같은 쓰기 요청도 함께 증가합니다. 즉, 피크 시간대에 읽기와 쓰기 요청이모두 급증하지만, 특히 읽기 요청이 압도적으로 많다고 할 수 있습니다.

3. 마지막으로, 트래픽이 더욱 높아질 가능성에 대한 부분입니다. 피크 시간대에 10,000 QPS에 도달하는 수준이지만, 앞으로 사용자 수가 증가할 것으로 예상되어 QPS가 점진적으로 증가할 가능성이 큽니다. 따라서, 10,000 QPS를 넘어서는 추가 트래픽까지 감당할 수 있는 유연한 확장 구성을 고려해주시면 좋을 것 같습니다.

[renechoi]

네, 답변 주신 내용을 종합해보면, 멀티 마스터 구성보다는 샤딩을 적용하는 방식이 적절할 것 같습니다.

말씀하신 대로, 현재 시스템에서 쓰기 요청이 특정 테이블에 집중되고 있고, 특히 금융 트랜잭션에서는 강한 일관성이 중요한 요소입니다. 멀티 마스터 구성을 사용하면 여러 마스터 간 데이터 동기화가 필요해지고, 이로 인해 데이터 충돌 가능성이 높아질 수 있으며 일관성 관리가 더 복잡해집니다. 앞선 질문에서, 약한 일관성을 허용할 수 있다고 답변 주신 부분이 있지만, 이 부분은 주로 조회성 요청에 적용될 것으로 봅니다. 예를 들어, 거래 내역 조회나 계좌 잔액 조회와 같은 경우, 실시간의 강한 일관성이 조금 약해져도 사용자 경험에 크게 영향을 주지 않는 요청들이라 할 수 있습니다. 금융 서비스의 특성상 이런 복잡성은 서비스의 안정성에도 영향을 미칠 수 있기 때문에, 멀티 마스터보다는 일관성 유지가 용이한 샤딩 구성이 더 적합하다고 판단했습니다.

또한, 샤딩 방식은 트래픽 증가에 유연하게 대응할 수 있는 확장성을 확보하는 데 유리합니다. 피크 시간대뿐만 아니라, 장기적으로 QPS가 더 증가할 가능성을 고려했을 때, 샤딩을 통해 필요한 만큼 수평 확장을 지속할 수 있다는 장점이 있습니다. 예를 들어, 사용자 ID나 거래 ID를 기준으로 데이터 샤드를 나눠 트랜잭션을 분산하면, 각 샤드가 독립적으로 쓰기 요청을 처리하게 되어 전체 쓰기 부하가 효과적으로 분산됩니다.

따라서, 샤딩을 통해 쓰기 요청을 여러 샤드로 분산하고, 각 샤드의 쓰기 부하를 관리하면서도, 강한 일관성이 요구되는 금융 트랜잭션의 안정성을 유지할 수 있을 것으로 생각합니다.

샤딩 구성을 통해 쓰기 요청을 분산하고 강한 일관성을 유지하려는 접근이 금융 서비스에 적절한 선택으로 보입니다. 그렇다면, 그렇다면 샤딩은 구체적으로 어떻게 구성할 수 있을까요? 좀 더 구체적인 상황을 가정해볼게요.

현재 시스템의 주요 데이터는 **사용자 정보, 계좌 정보, 트랜잭션 데이터(예: 자금 이체 기록)**와 같은 테이블로 구성되어 있다고 해보죠. 트랜잭션 테이블에는 특히 많은 쓰기 요청이 집중되고 있고, 해당 테이블은 높은 일관성 요구사항을 갖는 것으로 설정하겠습니다.

피크 시간대에 2,000 QPS의 쓰기 요청이 트랜잭션 테이블에 집중되고 있으며, 이를 4개의 샤드로 나누어 각 샤드가 약 500 QPS씩 처리할 수 있도록 목표를 설정해 봅니다.

이런 상황에서 어떻게 샤딩을 구성해볼 건가요 ?

네, 먼저 생각해볼 수 있는 샤딩 기준으로는 말씀드린 대로 사용자 ID를 사용하는 것입니다. 예를 들어, user_id % 4와 같은 해시 함수 연산을 통해 트랜잭션 요청이 특정 샤드로 분배되도록 할 수 있습니다. 이렇게 하면 각 샤드가 독립적으로 500 QPS씩 분산 처리할 수 있게 됩니다.

구체적으로는, 어플리케이션 레벨에서 요청이 들어올 때마다 이 해시 연산을 수행하여 해당 사용자 ID가 어느 샤드로 라우팅될지 결정하게 됩니다. 예를 들어, 트랜잭션을 처리하는 요청이 들어오면:

1. 어플리케이션이 user_id % 4 연산을 통해 어느 샤드로 요청을 보내야 할지 계산하고, 결과에 따라 해당 샤드의 데이터베이스로 연결을 설정합니다.
2. 각 샤드는 독립적인 트랜잭션 테이블을 가지기 때문에, 이 방식으로 트랜잭션 데이터를 샤드별로 분산해 쓰기 부하를 분배할 수 있습니다.
3. 또한, 각 샤드에 대해 별도의 **읽기 복제본(Read Replica)**을 두어 읽기 트래픽을 복제본으로 분산함으로써 마스터 샤드의 부하를 더욱 줄일 수 있습니다.

이와 같은 방식으로 어플리케이션 레벨에서 트랜잭션 요청의 분산을 관리하면, 샤드별로 균등하게 트래픽을 나눌 수 있을 것 같습니다.

좋습니다. 그런데 만약 특정 사용자에 대한 트래픽이 집중적으로 발생해서 특정 샤드에 부하가 몰리는 상황이 생긴다면 어떻게 해결할 수 있을까요? 예를 들어, 특정 VIP 고객의 거래가 매우 많은 겁니다.

음. 조금 더 구체적으로 상황을 가정해볼게요.

예를 들어, 현재 시스템을 사용하는 하루 평균 100만 명의 사용자 중 약 10%의 사용자가 거래 빈도가 높은 VIP라면 어떨까요? 일반 사용자는 하루에 1~2건의 거래를 하지만, VIP 사용자는 하루 100건 이상의 거래를 하는 상황입니다. 피크 시간대에는 전체 거래의 절반 이상이 VIP 사용자에게서 발생할 가능성도 있고요.
이런 경우, 사용자 ID를 기준으로 4개의 샤드로 데이터를 분산하면, VIP 사용자가 특정 샤드에 몰리면서 트래픽이 불균형해질 수도 있지 않을까요?

네, 이런 경우라면, VIP 사용자의 거래 빈도가 높다면 특정 샤드에 부하가 집중될 수 있기 때문에, 균형 잡힌 샤딩을 위해 다른 방식의 샤딩 전략을 고려해야 할 것 같습니다. 음, VIP와 일반 사용자를 분리하여 각각 다른 샤드 그룹으로 관리하는 방법을 사용할 수 있을 것 같은데요.

예를 들어, 특정 거래 빈도나 사용자 등급을 기준으로 VIP 사용자 그룹을 별도의 샤드로 이동시킵니다. 예를 들어, VIP 사용자는 vip_shard 그룹으로 보내고, 일반 사용자는 standard_shard 그룹으로 분리하여 트래픽을 분산할 수 있습니다.

음... VIP 사용자와 일반 사용자를 분리해 샤드를 구성하면 트래픽이 집중되는 문제를 어느 정도 해결할 수 있을 것 같네요. 그런데 이런 문제가 있을 것 같은데요?

예를 들어, VIP 사용자의 수는 고정적이지 않을 수 있다는 것입니다. 기존 일반 사용자가 VIP 그룹으로 이동하게 되는 경우도 있을 것이고, 기존의 VIP 사용자가 일반 사용자가 될 수도 있을 텐데요. 그리고 VIP 사용자 수가 증가하거나 감소할 수도 있을 것 같구요.

또 다른 문제는, VIP와 일반 사용자를 분리했을 때 각 샤드 그룹의 리소스 활용도가 균형을 이루지 못할 가능성도 있는데요. 예를 들어, 일반 사용자 샤드는 상대적으로 부하가 낮고 VIP 사용자 샤드는 부하가 집중될 수 있습니다.

마지막으로, VIP와 일반 사용자 그룹이 각각 다른 샤드에 분리되어 있을 때, VIP 샤드와 일반 샤드 간의 동기화나 데이터 공유가 필요하다면 어떻게 접근해야 할까요? 예를 들어, 특정 트랜잭션에서 VIP 사용자의 거래 내역을 일반 사용자와 조합해야 하는 경우가 발생할 수 있을 텐데요, 이때 데이터 동기화나 일관성 유지하는 것이 쉽지 않을 수 있을 것 같아요.

어떤가요?

네, 말씀하신 점들을 생각해보니 VIP와 일반 사용자를 샤드로 분리하는 전략은 확실히 이점보다는 잃는 것이 많은 것 같습니다.

생각을 해보면 결국 문제는 특정 사용자 패턴이 존재하는 상황에서, 완전하게 고르게 분포하는 것을 전제로 하는데요. 거래 id를 사용하지 않고 계좌번호를 사용하여 샤딩을 하고, 해당 계좌번호에서 유의미한 정보가 있다면, 이를 기반으로 샤딩을 하면 이 부분에서 어느 정도 효과가 있을 것 같긴 합니다. 하지만 지적하신 부분처럼 동적으로 바뀔 수 있는 부분에 대한 대응이 근본적으로 어려울 것 같다는 생각이 듭니다.

그래서 다시 생각해 보면, 계좌 번호를 기반으로 샤딩을 하되, 동적 라우팅이나 동적 파티셔닝을 함께 적용해서 하이브리드 방식으로 접근해보아야 할 것 같습니다.

먼저, 계좌 번호를 기준으로 샤드를 나눠서 각 계좌의 데이터가 특정 샤드에 모이도록 구성하는 거죠. 이렇게 하면 한 계좌의 모든 거래 기록이 같은 샤드에 저장되므로, 위에서 지적하신 동기화 문제나 불균형 문제도 어느 정도는 해소할 수 있을 것 같구요. 조회 시 여러 샤드를 검색할 필요가 없을 것입니다. 그리고 만약 계좌 번호에 일정 패턴이 있다면 특정 그룹으로 나누는 효과도 어느 정도 볼 수 있지 않을까 합니다.

그리고 VIP 사용자로 인해 특정 샤드에 트래픽이 집중될 때는, 동적 라우팅을 통해 일부 요청을 다른 샤드로 분산하는 방법도 생각해볼 수 있습니다. 예를 들어, VIP 계좌의 거래량이 갑자기 늘어나면, 그중 일부 요청을 임시로 다른 샤드로 보내서 트래픽을 분산하는 거죠.

마지막으로, 샤드에 부하가 몰릴 때는 동적 파티셔닝을 사용해 자동으로 샤드를 나누고 트래픽을 재분배할 수 있게 합니다. 특정 샤드에 트래픽이 과도하게 쌓이면 파티션을 추가해서 VIP 사용자 트래픽을 분산할 수 있게 하는 방식입니다.

이렇게 하면 계좌 번호 기반 샤딩을 유지하면서도, VIP로 인한 트래픽 변동에 더 유연하게 대응할 수 있을 것 같습니다!

[renechoi]

추가적인 방법들

캐싱 ?

DB 최적화 ?

[renechoi]

좋습니다. 지금까지 DB 레플리카와 샤딩을 통해 읽기와 쓰기 부하를 분산하는 방법을 잘 설명해주셨습니다. 이 방식으로 상당 부분 성능을 개선할 수 있을 것 같네요.

그런데, 여기서 한 가지 더 고려해볼 부분이 있을 것 같은데요. 😊 아무리 샤딩과 분산 구조를 잘 구축하더라도, 조회성 요청이 자주 발생하는 데이터에 대해 직접 DB 조회를 계속한다면, 시스템 부하가 다시 커질 가능성이 있습니다. 예를 들어, 자주 조회되는 계좌 잔액이나 거래 내역 같은 데이터는 캐싱을 활용하는 방법도 함께 고려해볼 수 있을 것 같은데요.

어떻게 생각하시나요? 캐싱을 적용한다면 어떤 방식으로 접근할 수 있을지 의견이 궁금합니다.

[KimH4nKyul]

단순히 데이터베이스 쓰기 작업 성능을 높이기 위해 샤딩을 도입하려 고려하는 것이 과연 적합한가? 는 의문입니다. 어차피 샤드를 늘려 분산한다고 해도 쓰기 트랜잭션 자체에 대한 작업의 성능이 평균 1000QPS를 상회하는 효과를 준다고 생각되지 않았습니다. :(
따라서 저는 애플리케이션 레벨에서 트랜잭션을 빠르게 처리하고 커넥션을 반납할 수 있는 구조로 변경되어야 할 거 같다고 생각했어요.

[KimH4nKyul]

• [힌트]에 애플리케이션 레벨은 고려하지 않는다고 했으므로, 패스!

[KimH4nKyul]

나왔던 의견 (1)

• 왜 꼭 2000QPS를 한 번에 처리해야 할까?
• 하나의 쓰기 DB에서 처리를 하는 방안을 고려하자.

[KimH4nKyul]

(2)

• 주식거래의 경우? 실시간으로 최대한 빠른 시간내에 처리가 되어야 한다는 조건이 있다면?
• 결국에는 DB를 늘리는 게 방법이지 않을까?
• 다른 저장소에 임시로 데이터를 저장하고 피크 시간 이후에 메인 DB로 옮기는 것은 어떨까?
• 이것은 '약한 일관성' 모델, 우리가 고려해야 하는건 '강한 일관성' -> 따라서 샤드나 레플리케이션 고려에 집중하는 게 맞음
• 특히, 문제의 조건을 고려한다면 샤드 도입이 최선일 수 있음

[vvoohhee]

DB 확장 없이 쓰기 작업을 처리하는 아이디어 (1)

• 사용자에게 대기열을 보여주지 않고, API서버와 DB 사이에 레디스를 두고 업데이트할 데이터를 일단 레디스에 쌓아놓기
• 그리고 DB가 처리 가능한 양�을 순차적으로 업데이트..?
• 강한 일관성이 필요한 경우에는 활용하기가 어렵다!