-
Notifications
You must be signed in to change notification settings - Fork 5
사용자가 늘어났을 때 발생 가능한 문제와 개선 방향
구체적인 사용자 수에서도, 사용자 패턴에 따라 발생할 문제와 개선 방향이 완전히 달라질 것이라 판단했습니다. 따라서, 다음과 같은 규칙을 적용해가며 생각해봤습니다.
- 매 단계별로 응답이 기존보다 2배 느려질 만큼의 트래픽이 발생합니다.
- 단계별로 추가로 주어지는 예산은 0.5배 증가합니다.
- 응답이 느려진다.
-
캐시 서버 추가 : 미션과 풀이, 디스커션 데이터 일부를 캐시 서버에 캐싱을 해둔다면, 응답 성능을 개선할 수 있을 것이라 판단했습니다. 대부분의 조회 요청에서 사용되는 데이터이기 때문입니다. 또한, 커뮤니티라는 서비스 특성상 조회가 쓰기보다 많을 것으로 예상되어 조회 성능 개선에 초점을 두었습니다.
-
목록 조회에서 첫 20 페이지만 응답한다. : 서비스에 트래픽이 많아지면, 필터링 대상이 되는 데이터의 크기를 최근에 생성된 데이터로 한정하여 제공하면 사용자에게 충분한 양의 데이터를 제공하면서, 성능을 향상시킬 수 있습니다.
-
역정규화 : 풀이 목록 조회의 경우 연관된 미션을 통해 필터링을 구현합니다. 미션에 달린 해시태그를 솔루션 테이블에 직접 저장하는 방식을 통해 성능을 개선할 수 있습니다.
- 응답이 느려진다.
- 방대한 로그 데이터가 생성된다.
-
미션 등 자주 사용되는 데이터를 캐시가 아닌 정적인 영역에 고정 : 미션 데이터는 사용자가 생성하는 것이 아니기 때문에, 데이터가 고정되어 있습니다. 이와 관련된 정보를 정적인 영역에 저장한다면, 이를 사용하는 요청에서 성능을 향상시킬 수 있습니다.
-
스케일 아웃 고려 : 이전 단계에서 캐싱을 통해 데이터베이스 부하는 어느정도 해소된 상태라 판단했습니다. 그렇다면, WAS를 스케일 아웃 하여 요청을 더 많이 받을 수 있도록 할 수 있습니다.
-
로깅 정책 및 알림 정책 추가 : 요청이 많아지므로 이에 대한 로그를 지금 방식대로 생성한다면, 데이터가 매우 많이 쌓일 것으로 판단됩니다. 따라서, 로그 보관 저장소나 로그 보관 기간 등을 세부적으로 정의할 필요가 있습니다. 또한, 모니터링 시스템의 효과적인 활용을 위해 알림 정책을 추가하고 필요하다면 이를 위한 시스템을 추가 구축합니다.
- 응답이 느려진다.
- 특정 종류의 데이터가 많이 쌓인다.
-
읽기 db 추가 : 이전 단계의 변경으로 인해 다시 DB가 병목지점이 될 수 있습니다. 특히, 읽기 요청이 많을 것으로 판단되어 읽기 DB를 추가합니다.
-
데이터베이스 서버 스케일 업 : 데이터베이스 서버의 성능을 향상시키면 커넥션 풀의 크기를 늘릴 수 있고, 이에 따라 데이터베이스의 성능이 향상될 수 있습니다.
-
댓글 수 제한 정책 추가 : 커뮤니티에서 발생하는 쓰기 요청 중 가장 많은 것을 차지하는 것은 댓글입니다. 그러나, 댓글이 많아질 경우 데이터 관리 및 사용자에게 적절히 보여줄 수 있는 방법의 어려움에 비해 효용이 적습니다. 따라서 댓글 수 제한 정책을 통해 신규 게시글의 생성을 유도하여 댓글 데이터만 과도하게 쌓이는 것을 방지할 수 있습니다.
-
도메인 분리 : 서비스가 성장하면서 특정 종류의 데이터가 많아지면, 관련도메인을 분리해 별도 서버로 제공하는 것이 유리할 수 있습니다. 언제든 이것이 가능하도록 코드 레벨에서 도메인 간의 의존을 끊는 작업을 합니다.
- 캐시 부하가 늘어난다.
- 캐시 서버 복제 : 캐시 서버를 복제합니다. 캐시 서버에 문제가 생길 경우 방대한 트래픽이 데이터베이스에 전달되어 장애가 전파될 가능성이 높습니다. 이를 방지하기 위해 캐시 서버를 복제하여 만일의 경우를 위한 대비를 합니다.
이런 작업들을 한 뒤에도 서비스가 발전한다면 다음과 같은 것들을 고려할 수 있습니다.
- 클라우드 서비스 다중화
- MSA 도입
- 샤딩, 파티셔닝