팔로잉/팔로워 구현에서 마주친 동시성

프로젝트를 진행하며 팔로워 수를 증가하거나 줄일때 동시성 문제에 대해 고민했던 내용입니다. 학습과정에서 작성되었기 때문에 잘못된 내용이 있을 수 있습니다. 

 

 

 

 

 

1. 동시성 문제

---

현재 팔로우/언팔로우 기능을 구현하는 로직은 아래와 같습니다. 팔로잉/언팔로우을 하게되면 회원 테이블이 가지고 있는 팔로잉 컬럼의 값이 1 증가하거나 감소하는 로직인데요, 이 부분에서 동시성 이슈가 발생했습니다.

 

 

 

 

 

 

 

여기서 왜 회원 테이블이 팔로잉 카운트를 가지고 있는지에 대해 의문이 생길 수 있습니다. 이는 조회의 편의성을 위해 이렇게 설계했습니다. 한 회원의 몇명의 팔로잉/팔로워 수를 알기 위해 서는 조인으로 데이터를 찾아와 갯수를 세거나 데이터베이스에 직접 카운트 쿼리를 날려야 하는데, 이렇게 매번 조인/카운트 쿼리를 날리는 것은 데이터가 많아졌을경우 데이터베이스에 부담을 줄 수 있다고 판단했기 때문입니다. 

 

 

예를들어 한 명의 회원이 10만명의 팔로워를 가지고 있다면 회원-팔로잉 테이블로 조인해서 10만개를 모두 가져와야 할까요? 조인을 하지 않는다면 10만개를 세는 카운트 쿼리를 날려야 할까요? 두 방법 모두 데이터베이스에 많은 부담이 갈 것입니다. 따라서 반대편 테이블에서 팔로잉 수를 가지고 있도록 설계했습니다.

 

만약  한 회원이 10만명의 팔로워를 가지고 있다면 10만개를 조인해서 개수를 세거나 10만개를 세는 카운트 쿼리를 날려야 하기 때문에 반대편 테이블에서 개수를 가지고 있습니다.

 

 

 

 

 

 

실제 인스타그램의 API를 보더라도 비슷하게 설계되어 있습니다. 메시, 호날두와 같이 유명인들은 수 천만, 억 단위의 팔로워가 있는데 이를 join이나 다른 방법으로 찾아오는 것이 비효율적이거나 불가능하기 때문일 것입니다. 

 

 

 

 

 

 

 

 

 

다시 문제로 돌아와서 이슈가 발생했던 과정을 그림으로 나타내면 아래와 같습니다. 한 사용자(J)의 현재 팔로워 수는 10명이고 사용자 A, B가 J를 동시에 팔로잉 하는 상황을 가정해보겠습니다. A가 J를 팔로잉해서 11명으로 업데이트하고 B가 사용자를 팔로잉하면 12명이 되어야 할 것 같지만 결과는 11명 입니다. 이는 트랜잭션 B가 사용자의 팔로워 수를 읽었을때의 값(11)을 기준으로 업데이트되기 때문입니다.

   

 

 

 

 

 

단계별로 요약해보면 아래와 같은데요, A가 J를 팔로우 하더라도 B가 J의 팔로잉 수를 읽었을때의 값은 10이기 때문에 A가 업데이트(10->11)한 후 B가 업데이트(10->11) 해도 11이 되는 것입니다. 

 

        1. A가 사용자의 팔로워 수(10명) READ

        2. B가 사용자의 팔로워 수(10명) READ.        -> B가 팔로워 수를 읽었을 때는 10명

        3. A가 사용자의 팔로워 수 업데이트 (11명) 

        4. B가 사용자의 팔로워 수 업데이트 (11명)     ->   2번에서 10명으로 읽었기 때문

 

 

 

 

 

 

2. 실제 서비스 관찰하기

---

이를 해결하기 위해 깃허브와 인스타그램을 참고했었는데, 우선 깃허브부터 살펴보겠습니다. 깃허브에서는 팔로잉/언팔로잉 할때 잠깐의 딜레이가 있습니다. 약 0.5초~1초 정도 되는 것 같았는데 자세히 보면 Follow 하고 잠깐의 대기시간이 있은 후 연한 회색으로 바뀌었다가 Unfollow가 나타나는 것을 볼 수 있습니다.

 

실제로 락을 잡고 업데이트 하는지는 알 수 없습니다. 락은 안 잡는데 단순히 로딩바를 추가했을 수도 있고 혹은 제가 모르는 더 좋은 방법으로 구현했을 수도 있기 때문입니다. 현재 제 수준에서 관찰한 후 나름의 가설을 세우고 추측을 한 것 뿐입니다. 이 부분에 대해서는 '저렇게도 생각할 수도 있구나' 하고 읽어주시면 감사하겠습니다. 

 

Follow/UnFollow를 누르고난 후 잠깐의 대기시간 존재. GIF로 만들어 여러번 클릭한 것처럼 보이는데 당연히 클릭은 한 번만했다.

 

 

 

 

 

실제 걸린 시간을 보니 얼추 0.5 ~ 0.6으로 체감상으로는 약 1초 정도 걸리는 것 같았습니다. **본사 데이터베이스가 아닌 리전의 데이터베이스가 존재하고, 그 곳으로 전송할 것으로 추측됐는데 그래서 꽤 빠르게 업데이트가 되는것 같았습니다.

 

 

 

 

 

 

 

 

이번엔 인스타그램을 살펴보겠습니다. 인스타그램 또한 팔로잉/언팔로우를 하는 순간 꽤 오랜시간 대기시간이 있습니다. 깃허브 보다 조금 더 길었던 것 같은데요 로딩바가 나타나면서 약 1~1.5 초를 기다린 후 언팔로우로 바뀌는 것 같았습니다. 인스타그램이 깃허브보다 조금 더 오래 걸린 이유는 아마 사용자 수 때문일 것 같은데요, 깃허브는 개발자를 대상으로 한 서비스지만 인스타그램은 전 세계 사람을 대상으로 했기 때문입니다. 즉, 사용자 수가 압도적으로 차이나서 그런것 같았습니다. 

 

인스타그램은 확실히 체감할 수 있을 정도로 딜레이가 더 길었다.

 

 

 

 

 

 

 

마찬가지로 네트워크 탭을 보니 약 1초 정도의 시간이 걸린 것을 볼 수 있는데 체감상으로는 1초 ~ 1.5초정도 걸렸습니다. 

 

 

 

 

 

 

 

 

 

여담으로 GIF로 만드는 과정에서 끊김 현상이 발생해 오해할 수 있는데요, 현재 컴퓨터 사양은 맥프로 2020 모델, 램 64G / 하드 1TB로 나쁜 사양이 아닙니다. 원본을 보고 싶으신 분들은 아래 파일을 다운 받아 보시면 될 것 같습니다. 

 

화면 기록 2022-09-19 오후 9.38.49.mov

2.21MB

화면 기록 2022-09-19 오후 9.15.55.mov

1.69MB

 

 

 

 

 

 

깃허브와 인스타그램의 정확한 내부 로직은 알 수 없지만 대략적으로 깃허브는 약 0.5 ~ 1초, 인스타그램은 1~1.5초 정도의 로딩이 있은 후 팔로우/언팔로우가 되는 것 같았습니다. 이 기간동안 해당 부분에 대해 락을 걸고 업데이트가 이루어진다고 추측했는데, 만약 추측이 맞다면 빠르게 업데이트가 이루어지기 보다는  정확성을 보장하기 위해 이렇게 구현하지 않았을까 하는 생각이 들었습니다.

 

 

핑 지연시간(latency)에 대한 읽어보았는데 미국 동부-서부도 약 215ms밖에 걸리지 않는데 저렇게 약 1초 정도의 딜레이가 있다는 말은 속도보다는 정확성을 더 중요시해서 내부에 어떤 작업이 있다고 판단했기 때문입니다. **물론 데이터가 엄청나게 많아서 데이터베이스도 나누어 놓았고, 각 리전별 데이터베이스간 동기화도 했겠지만 현재 제 수준을 넘어가기 때문에 간단하게만 생각해보았습니다.

How much network latency is "typical" for east - west coast USA?

 

 

 

 

 

여담으로 글로벌 서비스들이 이 문제를 어떻게 해결했는지 너무 궁금했습니다. 데이터베이스가 해외에 있다면 어떻게 저렇게 빠르게(?) 락을 잡고 푸는 것이 가능했을까? 데이터가 수천억, 조 단위 일텐데 저렇게 빠르게 가능할까? 만약에 본사랑 레플리카랑 데이터 정합이 틀리면 어떻게 이를 맞출까? 와 같은 궁금증이 들었기 때문입니다.

 

      - 데이터베이스가 해외에 있다면 어떻게 저렇게 빠르게 락을 잡고 푸는 것이 가능할까?

      - 데이터가 수천억, 조 단위 일텐데 저렇게 빠르게 데이터를 찾고 업데이트 하는게 가능할까?

      - 본사 데이터베이스와 레플리카 있고 데이터베이스 정합성이 다르면 어떻게 싱크를 맞출까?

 

 

 

 

 

 

글로벌 기업들은 본사의 데이터베이스 레플리카를 여러개의 리전에 두고 있을테고, 하나의 리전에도 여러개의 데이터베이스 레플리카가 존재할 것 같은데, 여튼 실제 이런지도 모르겠고 된다 하더라도 이렇게 복잡한 설계와 구현은 현재 제 수준에서 할 수 없기 때문에 그냥 "이렇지 않을까?" 하고 열심히 상상의 나래를 펼쳐봤습니다. 

 

 

 

 

 

 

3. 해결

---

다시 문제로 돌아와 제가 생각했던 방법은 아래 네 가지인데, 저는 첫 번째 방법으로 문제를 해결했습니다. 회원을 상세조회할때마다 count 쿼리나 조인이 발생하는 것을 원하지 않았기 때문입니다. 또한 낙관적/비관적 락을 걸려면 엔티티에 @Version 컬럼이 들어가는데 엔티티를 가능한 순수하게 유지시키고 싶었으며, RDB에 락을 거는 것은 조회 병목점이 생길것 같아 꺼려졌습니다.

 

 

      1. 팔로워 수를 업데이트할때 데이터베이스가 아닌 레디스로 락을 잡는다.

      2. 팔로워 수를 조인으로 찾은 후 개수를 센다.

      3. 데이터베이스에 count쿼리를 날려 개수를 찾는다. 

      4. 낙관적/비관적 락을 사용한다.

 

 

 

 

 

따라서 레디스를 통해 팔로잉 업데이트 시 락을 잡아 문제를 해결했는데요, RedissonClient를 사용했습니다. RedissonClient가 어떻게 동작하는지 간략하게 살펴보겠습니다.

 

 

 

 

 

 

Redisson은 스핀 락이 아닌 pubsub 방식을 사용함으로써 레디스에 부담을 덜 주는데, 이는 락이 해제될 때마다 subscriber에게 알림을 주기 때문입니다. 스핀락과 달리 일일이 레디스에 요청을 보내 락의 획득가능여부를 체크하지 않아도 되기 때문에 오버헤드가 비교적 적습니다.

 

 

즉, 스핀락처럼 while문을 돌면서 기다리지 않고 메시지가 오는 순간 알림을 받고 다음 작업을 진행하기 때문에 레디스에 부하를 덜 주는 것입니다. RedissonClient는 Lua 스크립트를 통해 락을 구현하고 있는데요, 스크립트까지 가기 위해서는 아래의 과정을 거치며 최종 잠금은 원자성을 보장합니다.

 

 

 

 

 

 

 

Lua 스크립트를 간단히 살펴보면, 처음 들어와서 if문 내부에서 락이 있는지(KEYS[1])에 대해 먼저 살펴본 후 락이 있다면 기다리고 없다면 락을 겁니다. 락을 걸때 hincrby명령어를 사용하는데 이는 해시자료구조를 사용하는 것으로 재진입 잠금을 위한 값을 위한 것입니다. hincrby 명령어 호출 후 락이 형성됩니다. 

 

KEYS[1]	락의 이름
ARGV[1]	락을 잡는 시간
ARGV[2]	락의 고유 ID.  하나의 Redisson 클라이언트 하나의 UUID,UUID 고유한 클라이언트를      나타냅니다. 따라서 UUID와 스레드 id에 의해 잠금의 고유 식별을 구성하며 클라이언트의      스레드를 잠금으로 이해하는 것으로 이해할 수 있습니다.

 

 

 

 

 

 

이때 수동으로 잠금의 만료 시간을 설정하지 않으면 기본 잠금 시간은 30초입니다. 만료 시간을 설정하지 않으면 불필요하게 락을 잡고 있는데,  예를들어 작업 시간은 1초인데 락을 해제하지 않으면 뒤에 있는 스레드는 불필요하게 30초간 대기하기 때문에 기본 시간을 반드시 지정해주는 것이 좋습니다. 여튼 이후 unlock unlockAsync를 호출하고 스레드 ID를 전달한 후 락을 해제합니다. 

 

 

 

 

 

 

 

RedissonClient는 위와 같이 RDB가 아닌 매개변수와 레디스를 이용해 락을 걸기 때문에 RDB에 부담이 가지 않아 이를 채택하게 되었습니다. 물론 지금처럼 사용자가 적을때는 이 방식이 괜찮을 것 같지만 만약 사용자가 많아진다면 이 방식이 유용할지에 대해서는 솔직히 잘 모르겠습니다. 이 부분에 대해서는 조금 더 고려해봐야할 것같습니다. 

 

 

 

 

 

 

 

4. Conclusion

---

생각지도 못했던 부분에서 동시성 문제가 터져서 당황했는데요, 조회의 편의성을 위해 회원 테이블에 컬럼을 생성했기 때문에 발생했던 문제였습니다. 락을통해 이 문제를 풀었던 이유는 조회 편의성이 주는 이점을 포기할 수 없었기 때문입니다. 또한 회원을 조회하는 횟수가 그렇게 많지 않기 때문에 이 부분에서 락을 잡아도 큰 문제가 없다고 판단했는데요, 만약 회원이 자주 조회/업데이트되는 상황이었다면 락보다는 차라리 count 쿼리를 매번 날리지 않았을까 하는 생각도 들었습니다. 말이 조금 길어졌는데 조회의 편의성을 얻기 위해 업데이트가 빈번하지 않은 팔로잉/팔로우 기능을 락을 통해 해결했던 상황이었습니다.

 

 

Redis distributed lock 15 ask, what have you mastered?