일일 활성 사용자Daily Active Users(DAU)가 많은 경우 어떻게 개발할지 궁금했다. 그래서 DAU가 백만이 넘는 회사에 입사해서 살펴봤다. 개인적인 경험이라 기업마다 차이가 있을 수 있다.
DAU가 많다는 의미
DAU가 많다는 건 결국 백엔드 입장에서는 요청Request이 많다는 것이다. 그것도 굉장히 많이. 간단히 비유하면 손님이 끊이지 않고 줄서서 먹는 맛집 같다. 음식을 빠르게 대접해야 일일평균 최대한 많은 손님을 처리할 수 있고 음식 맛이 일정해야 손님이 끊이지 않게 된다. API 서버 기준으로 설명하면 손님이 오래 기다리지 않도록 빠르게 대접하는 건 응답 속도이고, 맛이 일정한 것은 오류 없이 응답을 제공하는 것으로 볼 수 있다. 식당과 차이는 식당은 손님을 오래 기다리게 할 수는 있지만 중단은 없는데, 웹서비스는 너무 몰리면 아예 서비스가 중단된다는 점이다.
DAU가 많은 서비스의 백엔드 개발 시 중요한 것
빠른 응답 속도와 중단 없이 오류 없이 서비스를 제공하는 안전성이다.
DAU가 많은 서비스와 적은 서비스 개발의 차이
응답 속도와 안전성 모두 DAU가 적은 서비스 개발에서도 당연히 중요하다. 하지만 중요성을 체감하기 어렵다. 그래서 사소해 보이지만 사소하지 않은 세부사항, 디테일에서 차이가 발생한다. 그 차이는 경험에서 나온다. DAU가 적은 서비스만 경험한 개발자는 결과가 나오는 구현에만 신경 쓴다. 식당으로 치자면 손님이 하루 열명 올까말까한 식당으로 비유할 수 있다. 띄엄띄엄 오는 손님한테 음식을 제공하는 요리사라고 볼 수 있다. 가끔 손님이 오니 음식을 한 두개만 만들면 되니 꽤 빠르게 만든다. DAU가 많은 서비스의 백엔드 개발자는 손님이 끊이지 않는 맛집 요리사와 비슷하다. 손님이 별로 없는 시간에도 손님이 많을 경우를 대비해서 준비한다.
디테일의 차이: 데이터베이스 쿼리 비용에 대한 민감성
DAU가 적은 서비스의 개발자는 데이터베이스 쿼리 비용의 중요성을 알기 어렵다. 요청이 별로 없으니 쿼리가 비효율적이라도 응답 속도가 느리지 않기 때문이다. 하지만 DAU가 많은 경우 응답 속도에 엄청난 차이가 발생한다.
왜 데이터베이스일까
서비스 운영을 위해 필요한 여러 자원 중 데이터베이스가 가장 비싼 자원이기 때문이다(참고. Q. 웹서비스 운영 중 가장 비싼 자원은?). 부하분산을 위해서 읽기용 데이터베이스는 여러 개 둘 수 있으나 그마저도 한계가 있고 쓰기용 데이터베이스는 하나 뿐이다.
느린 응답 속도의 주요 원인
API 서버가 느린 응답속도의 원인이라면 필요에 따라 개수를 100개 200개 늘리면 쉽게 해결할 수 있다. 하지만 데이터베이스가 원인이라면 돈이 있어도 늘리기 어렵다. 부하가 데이터베이스에 몰리게 되어 데이터베이스가 느린 서비스 응답 속도의 주요 원인이 된다.
데이터베이스 쿼리 비용 감소시키면 응답 속도 현저히 개선
당연히 주원인이 데이터베이스이므로 쿼리 비용을 감소시키는 방향으로 개발하면 응답 속도가 현저히 개선된다. 예를 들어 장고Django ORM에서 흔히 발생하는 n+1 이슈가 있다(참고 Q. 장고Django ORM에서 n+1 이슈란? n+1 이슈 해결 방법은?). 목록 조회 개수가 100개일 때 n+1 이슈가 있게 구현하면 101번 데이터베이스 조회가 발생하고 n+1이슈 없이 구현하면 2번만 조회한다. 단순 조회 횟수만 비교해도 50배 이상 차이가 발생한다. 쿼리 비용을 최소화하는 방향으로 구현하면 데이터베이스 서버 요청 횟수가 50분의 1로 줄게 되는 것이다.
또 테이블 풀스캔이 필요한 쿼리는 최소화하고 가능하면 데이터베이스 서버에 대한 요청을 줄이고 API 서버 내에서 자체 처리하는 방향으로 개발한다. 이렇게 개발하려면 코드도 길어지고 생각할 것도 많아진다. ORM이 제공하는 기능들 중 많은 것들을 아예 쓸 수 없다.
디테일의 차이: 응답 속도 및 안전성 모니터링
DAU가 적은 서비스 백엔드 개발자는 모니터링의 중요성을 깨닫기 어렵다. 그래서 응답 속도가 오래 걸리는 API들이 존재해도 심지어 오류가 있어도 존재 자체를 모르게 된다. 식당으로 비유하면 하필 평소보다 손님이 몰려서 나중에 온 손님이 와서 한 시간을 기다려서 음식을 받았다고 치자. 그 손님은 그 뒤로는 다시 그 식당에 안 갈 것이다. 모니터링이 없다는 건 그 손님이 한 시간 기다렸다는 걸 요리사가 모르는 상태인 것과 같다. 모르니 개선하지 못하고 그래서 식당 손님은 늘지 않고 계속 제자리가 된다.
맛집 잘 나가는 식당은 시시티비를 활용하든 홀 직원들을 통하든 상시 모니터링을 한다. 손님의 대기시간에 민감하다. DAU가 많은 서비스 개발자도 마찬가지다. Sentry 등 툴을 활용해서 끊임 없이 응답 속도 및 오류를 모니터링하고 개선한다. 응답 속도가 느리면 오류가 많다면 손님들이 떠나간다는 것을 알고 있으니까.