2024년 5월 1주차 주간회고

 

 

대용량 트래픽 & 데이터 처리 챕터 시작

본격적으로 대용량 트래픽과 데이터를 처리하기 위한 과정이 시작되었다.

 

이번주는 현재 이커머스 서비스에서 발생할 수 있는 동시성 상황들을 분석해 보고 여라가지 방법들의 각각의 장단점을 파악하여 직접 동시성 문제를 해결해 보았다.

 

우선 나는 이전까지 개인적으로 진행하는 프로젝트나 실무에서 조차 동시성 문제를 직접 고려해 본 적이 없다. 그래서 어떤 상황에서 동시성이 발생하는지 1도 모르고 더군다나 DB에 대한 공부를 거의 하지 않아서 어떻게 해결해야 하는지 1도 모르는 상황이었다.

 

 

그래서 DB를 먼저 공부해야겠다고 생각을 하여 현재 주로 사용하는 DB인 MySQL을 공부하기 위해 Real MySQL8.0을 사서 먼저 트랜잭션과 잠금 파트를 읽어보았다.

덕분에 MySQL의 격리 수준에 대해 알 수 있었고, MySQL의 기본 격리 수준(InnoDB 엔진 -> "REPEATABLE READ")과 격리 수준이 낮을 때("READ UNCOMMITTED") 동시성 문제가 발생하는 이유에 대해 알아볼 수 있었다.

 

동시성 이슈 제어하기

이번주는 동시성 문제를 db의 격리 수준으로 해결하는 것이 아닌 테이블 설계와 DB 락, 분산 락을 이용해 해결해 보는 것이 목표였다.

 

그래서 DB 락(낙관적 락, 비관적 락, 네임드 락)의 각각의 방법에 대해 학습하면서 실제로 프로젝트에 구현해 보면서 동시성 문제를 해결해 보고 어떤 상황에서 어떤 락을 이용해 제어하는 게 좋을지 고민해 보았다.

 

https://seungjjun.tistory.com/332

[E-commerce] 동시성 문제 해결하기 (비관적 락, 네임드 락, 분산 락)

 

비관적 락을 구현해 보고 테이블 자체에 락을 거는 행위가 동일 테이블을 사용하는 다른 비즈니스 로직에 영향이 가기 때문에 락 전용 테이블을 이용해 분리를 하거나 MySQL의 네임드 락을 이용해 테이블에 락을 거는 게 아닌 문자열에 락을 걸어 이러한 문제를 해결할 수 있었다.

 

MySQL을 사용하면 네임드 락으로 동시성 문제를 해결할 수 있는데 레디스를 왜 이용하지? 이런 생각이 있었는데, 분산 락에 대해 학습하면서 DB가 다수인 경우인 상황에서는 네임드 락으로는 해결할 수 없다는 것을 깨달았다.

 

그리고 네임드 락이나 비관적 락은 DB와 커넥션을 맺어야 하기 때문에 락 획득을 위해 대기하는 커넥션이 발생할 수 있어 다른 비즈니스 로직이 커넥션을 맺지 못해 서비스의 장애가 발생할 수 있는 문제가 있는데, 레디스를 이용하면 락을 얻기 위해 DB에 커넥션을 요청하는 행위를 하지 않고 레디스에서 잠금 획득을 시도하기 때문에 이러한 문제도 해결할 수 있다는 것을 알게 되었다.

 

그렇다고 무조건 레디스를 이용하는 건 추가적인 관리 비용이 들기 때문에 "동시성 제어에는 레디스가 최고야!" 보다는 서비스의 크기에 따라 이용할 수 있는 락 방법을 달라질 수 있을 것 같다.

결국 어떤 락을 이용해 해결하는 게 더 효율적인지를 판다 하는 게 개발자의 역량인 것 같고 항상 어떤 방법을 선택하기 위해서는 상황에 따라 장단점을 분석하여 선택해야 한다는 것을 배웠다.

 

돌아오는 주부터는 대용량 트래픽을 효율적으로 처리하기 위한 index 및 캐싱에 대해 배우는데 인덱스에 대한 개념도 부족하기 때문에 Real MySQL의 인덱스 챕터를 읽고 과제를 시작해 보자!