대용량 트래픽 처리 전략, 2편 데이터베이스

개요

이번시간에는 데이터베이스를 통해서 대용량 트래픽의 처리 성능을 높이는 법을 알아볼것이다.

본 글에 들어가기 전에 대용량 트래픽 발생시 어떤 부분에서 성능을 향상 시킬지는 잘 판단해야한다. 예를 들어 웹 어플리케이션은 여유로운데 데이터베이스에서 처리를 못하고 있는 상황에서 웹 어플리케이션 확장만 시키면 무엇이 달라지겠는가.

 

그럴때는 APM을 사용해서 하나의 큰 요청 트랜젝션을 분석하여 병목 지점을 알아내야한다. 웹 어플리케이션에선 처리가 1초 내로 되는데 데이터베이스에선 5~6초가 걸린다면 데이터베이스를 최적화 해야하는 상황이라고 판단한다. 이렇게 적절한 대응 지점을 찾는것이 1순위이다.

데이터베이스 Replication

레플리카 라는 말은 일상에서 가끔 들을 수 있는 말이다, 무엇을 의미하냐 하면 원작을 복제한 모작이란 의미이다. 데이터베이스에서도 비슷한 개념으로 적용된다. 정확한 의미는 두개 이상의 데이터베이스를 사용하여 Master/Slave의 수직적 구조로 확장하는 방식이다.

 

하지만 데이터베이스를 여러개 만들어버리면 트래픽은 어떻게 분배할것이며 데이터도 제각각 저장되지 않겠는가? 그러기 때문에 읽기 전용 데이터베이스와 쓰기 전용 데이터베이스를 구분한다.

https://nesoy.github.io/articles/2018-02/Database-Replication

Master 데이터베이스는 쓰기, 수정, 삭제를 담당하고 Slave 데이터베이스는 조회만을 담당한다. 이러한 방법이 효과적인 이유는 물론 도메인마다 다르지겠지만 대부분은 쓰기, 수정, 삭제보단 조회 요청이 훨씬 많이 발생하기 때문이다. 또한 여러 조건이 들어간 읽기 요청은 단순하게 쓰고 지우는것보다 처리가 오래 걸리고 성능 저하의 요소가 많기 때문이다.

 

둘의 데이터 연동과정을 이 글에선 다루지 않겠다, 언급하면 내용이 좀 많아지기 때문이다. 

 

신경 써야 하는 부분은 Master, Slave의 하드웨어 스펙이 비슷하거나 Slave가 더 좋아야한다, Slave가 Master의 처리량을 따라가지 못한다면 데이터의 정합성이 깨지는 대참사가 발생한다. 또한 Master가 다운될시 Slave가 Master로 전환되는 Fail-Over를 지원하지 않기 때문에 이 부분에 관해선 Replication이 아닌 다른 이중화 방법을 따로 구축해서 진행해야 한다.

데이터베이스 Sharding

샤딩은 데이터를 쪼갠다고 생각하면 편하다, 2개 이상의 데이터베이스에 고유키와 특정 조건들을 기준으로 하여 데이터베이스에 데이터를 분산하여 저장한다. 정말 간단하게 예시를 들어보자면 고유키가 짝수이면 1번 데이터베이스에 저장하고 홀수이면 2번 데이터베이스에 저장한다고 생각하면 된다.

샤딩의 기준이 되는 방법의 종류는 정말 많지만 이 글에서 다루진 않겠다. 다만 샤딩을 할때 주의해야할점을 알아보겠다.

 

Hotspot이라는 유명한 문제이다, 예를 들어서 SNS 플랫폼을 개발한 상황에서 5개의 데이터베이스에 유저의 데이터를 나누었다, 그런데 만약 전세계적으로 인기 있는 축구선수가 2번 데이터베이스에 저장되어 있다하면 사람들이 유명 축구 선수의 프로필을 조회할때마다 해당 데이터베이스에 부하가 생길것이다. 이렇게 때문에 샤딩도 무적의 방법이 아니다, 또한 샤딩을 어떤 기준으로 분류할것인지 어떻게 관리가 되고 있는지 등 많은 고민이 필요하고 한번 샤딩한 아키텍쳐를 다시 하나로 합치기도 어려운 일이다.

마무리하며

오늘은 데이터베이스단에서의 트래픽 처리에 대해서 알아보았다, 위에서도 언급했듯이 트래픽을 최적화할 수 있는 스팟은 정말 다양하다, 맨 앞단 게이트웨이에서 트래픽을 분산시킬수도 있고 웹 어플리케이션 내부 최적화를 통해서도 개선할 수 있으며 이번 글처럼 데이터베이스단에서도 성능을 개선할 수 있다. 

 

정말 중요한것은 정확한 성능 테스트와 분석을 통하여 병목 지점을 찾고 투자한 자원대비 제일 효과가 좋은 최적화 스팟을 찾아내는것이라고 생각한다, 솔직히 성능 최적화나 대용량 트래픽 처리하는 방법은 구글에 치면 널리고 널렸다. 자신의 프로덕트에 적재적소에 맞게 적용하는것이 개발자의 역량이라고 생각이 든다.