[BE] 다수 사용자들이 사용할 수 있게 하는 인프라 아키텍처 개선 방향

[nayonsoso]

현재 팀의 아키텍처에서 사용자가 늘어났을 때 문제가 될 수 있는 부분을 설명하고, 이를 개선할 수 있는 방법에 대해 작성한다.
만명, 10만명, 1,000만명이 사용해도 서비스할 수 있도록 팀의 인프라 아키텍처 개선 방향을 공유한다.

[nayonsoso]

현재 구조

[donghoony]

1,000명이 리뷰미 동시 접속

리뷰 사이클과 같은 시나리오 아래에서는 현재 서버로 감당 가능하다. (TPS 시나리오 테스트에서 검증됨)

• 한 개의 서버가 약 700 VU를 안정적으로 감당할 수 있다.
• 1초 이내 응답 가능: TPS 개선을 위한 성능 테스트 결과 공유 #921

10,000명

• 스케일 업, 스케일 아웃 및 오토 스케일링을 통해 조절한다.
• ECS 등으로 여러 어플리케이션을 컨테이너화해 쉽게 관리하도록 한다. (모니터링까지)
• DB의 부하 또한 스케일 업 (CPU 개수를 늘려서 한 번에 처리할 수 있는 커넥션의 개수를 늘린다.

100,000 ~ 1,000,000명

• 스케일 업/아웃으로는 감당할 수 없다. 다른 방법을 생각해보아야 한다.
• DB에 실제적으로 저장되는 것은 <그룹 생성, 리뷰 생성, 하이라이트>
• 그 외 템플릿, 질문, 옵션과 같은 사항은 전부 캐싱 가능하다. 그리고 바뀔 일이 거의 없음. (쇼핑몰 도메인의 카테고리와 비슷)
• 템플릿/질문/옵션은 모두 캐싱한다. 그룹/리뷰/하이라이트 관련 최적화를 진행해야 한다.
• 캐싱을 좀 야무지게 쓸 수 없을까?

• 리뷰 그룹은 엄청나게 높은 Cardinality를 가지는 Index를 가지고 있다. 문제가 될 부분은 결국 커넥션 문제다 (DB 접근 시간은 충분히 빠르다), Disk 접근 시간은 굉장히 느리니까 캐싱을 하는 게 낫다.
• 주로 리뷰가 그룹이 만들어진 뒤 일주일 안에 많이 작성하더라: DB 저장한 뒤 캐시에 7일 TTL을 건다.
• 리뷰 그룹을 찾는 DB 접근은 최대 한 번 이뤄지고 나머지는 모두 캐시로 향한다. 그리고 이 요청이 리뷰미에서 제일 많이 들어오는 DB 요청 중 하나이다. 리뷰 작성, 권한 검증에서 제일 많이 쓰이기 때문이다.
• 아무리 시간이 덜 걸리는 연산이더라도, 커넥션을 사용하는 것 자체가 부담이기 때문에 이를 최소화한다.
• ReviewGroup 객체는 작다. 그래서 많이 넣을 수 있을 듯하다.

• 같은 맥락으로, 리뷰가 쓰인 뒤 일주일 이내에 가장 많이 조회된다는 점을 감안해서 리뷰 자체를 캐싱한다.
• 또는, 리뷰 테이블에 대해서 역정규화를 진행한다. Json 자체를 저장하는 등의 방법이 있을 수 있다.

10,000,000명

• ??? 일단 감사하다 🙇🏻‍♂️ 배민을 뛰어넘었다 ㅎㅎ

• 비동기를 최대한 활용해야 한다. 저장이 오래 걸릴 수 있는 것을 메시지 큐로 분리한다. 우리 서비스에서는 하이라이트가 꽤나 큰 부담인데, 많은 사용자를 고려한다면 하이라이트의 정규화도 깨야 할 수 있다. (현재 하이라이트의 정규화가 아주 잘게 되어 있다)
• 데이터의 중요도에 따라서 정합성 정확도를 조절할 수 있다. 물론 데이터가 유실되면 안 되지만, 어느 시간 동안은 사용자가 참을 수 있을지를 파악하는 것도 중요하다. 명심하자. 우리는 데이터를 항상 적시에 올릴 필요는 없다. 우리는 사용자에게 편의만 제공하면 된다.
• 대표적으로 쓰기를 직접 DB에 하지 않고, 캐시에 먼저 쓰기 (읽기/쓰기가 월등히 빠름), 캐시 -> Disk로 쓰기 작업을 스케줄 + 메시지 큐를 도입할 수 있음
• 리뷰 저장 자체를 두 곳에 저장한다 (Json과 같은 한 번에 넣기, 정규화되어있는 테이블) -> 조회 시 성능을 높이고, 추후 기능 확장 필요 시에 사용한다.