사용자 증가 시 문제가 될 수 있는 부분

[kyum-q]

현재 팀의 아키텍처에서 사용자가 늘어났을 때 문제가 될 수 있는 부분을 이야기하고, 이를 개선할 수 있는 방법에 대해 논의한다

기능적인 문제 + 아키텍처 상 문제

현재 아키텍쳐

[zangsu]

• 전문 검색이 느리다.
  • Elastic Search 를 도입해서 검색의 성능을 높인다.
• 구경가기 첫 화면 로딩이 느리면 사용자 이탈이 클 것 같다.
  • Redis 를 사용해 첫 화면 캐싱
• 좋아요 카운트 로직때문에 검색 성능에 영향이 간다.
  • 역정규화=> 좋아요 개수를 DB 필드로 직접 관리한다.

[jminkkk]

새로 추가되는 핫한 템플릿 배너, 구경가기 페이지 등 템플릿 목록 조회에 요청이 과다하게 몰릴 경우

변경이 자주 일어나지 않는 목록이 중복적으로 조회되어 쿼리가 발생하게 된다. (변경보다 조회의 요청이 월등하게 많다)
DB 레플리케이션을 통해 Reader 인스턴스가 2개 있긴 하지만, 변경이 자주 일어나지 않는 템플릿들에 대해 계속해서 조회하는 것은 불필요하다.

분산 환경이기 때문에 캐시 서버를 두어 미리 배너들에 대해 조회를 해놓는 방식으로 개선하는 것이 어떨까요?

[HoeSeong123]

• 테이블의 크기가 과하게 커질 수 있다.
  • 1000만 명이 가입한다고 했을 때, 멤버 테이블에만 1000만개의 데이터가 들어가고, 템플릿은 말도 못할거고, 태그는 한 템플릿에 여러 개의 태그를 생성할 수도 있으니까 기하급수적으로 늘어날 것으로 예상된다. 분리하는 것을 고려해봐야 할 것 같음.

[HoeSeong123]

• 로드밸런서에 대한 부하도 걱정됨
• 현재 1대의 로드밸런서만을 사용중이기 때문에 로드밸런서 자체가 과부하가 되는 경우 서비스 자체를 이용할 수 없게 됨.
• 이에 대한 해결책으로는 2대의 로드밸런서를 사용하고, DNS에서의 로드밸런싱 기술을 적용하는 것을 고려해볼 수 있음

[zeus6768]

1000만 명이 사용해도 서비스할 수 있도록 개선하려면?

1. TPS 현재 최대 100 ~ 200 수준인데, 1만 ~ 수십만까지 가능하게 만들어야 한다. 그러려면 스프링 서버와 DB의 scale-out, scale-up이 되어야 한다.
2. 현재 코드잽의 api 대부분은 read 연산을 요구한다. 읽기 전용 DB를 잔뜩 만들어 부하를 분산해야 한다.
3. 서비스가 커진다면 모니터링 서버도 여러 대가 되어야 한다. 각각 다른 AZ에 위치시킨다.
4. 로그 용량을 관리해야 한다. 꼭 필요한 메시지만 남기도록 로그를 최적화한다.
5. 해외에서도 사용할 수 있도록 서비스 사용자들이 주로 사용하는 해외 AZ를 골라 CDN 등으로 정적 자원을 배포한다.

[kyum-q]

• 검색 성능 개선
  • 캐시 및 elasticsearch 사용
• 좋아요 카운트 개선
  • 템플릿 테이블에 좋아요 카운트 추가
  • 그럼 한번에 좋아요를 여러명이 누르면,,,? 문제 안되나?
• (+) 삭제 로직
  • 현재 템플릿 하나 삭제 시 많은 DB를 접근해야한다. cascade 사용으로 삭제 로직을 더 빠르게 구현.
• 데이터가 많아지면서 복제 지연 문제

[zangsu]

사용자가 늘어남에 따라 복제 지연이 발생할 가능성이 커지고, 최신순 정렬을 구경가기에서 보여줄 경우 사용자 경험이 낮아질 수 있다.
이에 구경가기의 기본 정렬을 좋아요순 으로 변경한다.

[jminkkk]

템플릿 목록 조회 시

1. 템플릿을 생성할 경우 새로 생성된 템플릿에 대한 데이터를 글로벌 캐시에 저장한다.
2. 구경가기 첫 페이지에 진입할 경우, 캐시 서버에서 최신 조회된 템플릿들을 조회한다.

캐시는 비용이 비싸기 때문에 일정 시간이 지날 경우 비운다.

[zangsu]

발생할 수 있는 문제상황 & 개선사항

사용자가 늘어남에 따라 복제지연이 발생할 수 있다.

문제 상황

1. 사용자가 템플릿을 생성함.
2. 자동으로 템플릿 상세 페이지로 리다이렉트 됨
3. 템플릿 상세 페이지 조회 요청은 READER DB 가 처리하기 때문에 복제 지연 발생이 발생할 경우 잘못된 요청 처리된다.

해결 방법

1. 템플릿을 생성할 경우 새로 생성된 템플릿에 대한 데이터를 글로벌 캐시에 저장한다.
2. 캐시는 비용이 비싸기 때문에 일정 시간이 지날 경우 비운다.

문제 상황 2

1. 사용자가 템플릿을 생성함.
2. 구경가기로 이동한 경우 디폴트 정렬은 "최신순" 이나, 복제 지연이 발생하여 자신이 생성한 템플릿이 보이지 않는다.

해결 방법

1. �사용자가 충분히 많아진 경우 좋아요 순 정렬을 기본값으로 변경한다.
2. 좋아요 순 정렬의 경우 가장 상위의 데이터는 변경이 적어 캐싱이 쉽다.
3. 최신순에 비해 복제 지연을 확인할 가능성이 낮아지고, 사용자 경험이 높아진다.
4. 캐시는 비용이 비싸기 때문에 일정 시간이 지날 경우 비운다.
5. 구경가기 첫 페이지에 진입할 경우, 캐시 서버에서 최신 조회된 템플릿들을 조회한다.
   +) 캐시는 비용이 비싸기 때문에 일정 시간이 지날 경우 비운다.

자주 조회되는 데이터에 대해 성능을 개선한다.

개선 이유

코드 템플릿은 도메인 특성상 생성/변경보다 조회가 훨씬 자주 일어난다.
변경이 자주 일어나지 않는 목록이 중복적으로 조회되어 쿼리가 발생하게 된다.
DB 레플리케이션을 통해 Reader 인스턴스가 2개 있긴 하지만, 변경이 자주 일어나지 않는 템플릿들에 대해 계속해서 조회하는 것은 불필요하다.

개선 방법

분산 환경이기 때문에 캐시 서버를 두어 조회가 잦은 배너 검색 결과, 구경가기 결과에 대해 캐시를 적용한다.

검색이 느려진다.

문제 상황

1. 키워드 검색은 프로젝트의 핵심 기능이지만, 성능이 느리다.
2. 3초 이상 걸리는 응답 때문에 사용자 이탈이 발생할 수 있다.

해결 방법

1. ES 를 사용하는 전문검색을 활용한다.

좋아요 개수 조회 쿼리로 인한 성능 저하

문제 상황

1. 현재 좋아요 수는 template 테이블과 Like 중간 테이블을 조인하여 계산하고 있다.
2. 템플릿, 좋아요 수가 많아질수록 좋아요 수의 집계가 더욱 오래 걸릴 것이며, 좋아요순 정렬에 많은 시간이 걸려 성능이 저하될 것이다.

해결 방법

1. Template 테이블에도 좋아요 수를 컬럼으로 가지도록 반정규화를 진행한다.
2. 좋아요 수가 적당히 많은 템플릿에 대해서는 좋아요 업데이트를 배치로 업데이트 한다.

[zangsu]

발생할 수 있는 문제상황 & 개선사항

사용자가 늘어남에 따라 성능을 더 높일 수 있어야 한다.

• 사용자가 만명 이상이라고 가정한다.
  • 스프링 서버, DB, 모니터링 서버의 Scale out & Scale up 이 함께 고려되어야 한다.
  • 특히 코드잽의 대부분의 API 는 read 연산이므로 읽기 전용 DB 를 위주로 증설한다.
  • 각각 다른 AZ 에 위치시킨다.
• 꼭 필요한 메시지만 남기도록 로그를 최적화 하고, 로그 용량을 관리한다.
• 해외에서 사용할 수 있도록 사용자들이 주로 사용하는 해외 AZ를 골라 CDN 등으로 정적 자원을 배포한다.

사용자가 늘어남에 따라 복제지연이 발생할 수 있다.

문제 상황

1. 사용자가 템플릿을 생성함.
2. 자동으로 템플릿 상세 페이지로 리다이렉트 됨
3. 템플릿 상세 페이지 조회 요청은 READER DB 가 처리하기 때문에 복제 지연 발생이 발생할 경우 잘못된 요청 처리된다.

해결 방법

1. 템플릿을 생성할 경우 새로 생성된 템플릿에 대한 데이터를 글로벌 캐시에 저장한다.
2. 캐시는 비용이 비싸기 때문에 일정 시간이 지날 경우 비운다.

문제 상황 2

1. 사용자가 템플릿을 생성함.
2. 구경가기로 이동한 경우 디폴트 정렬은 "최신순" 이나, 복제 지연이 발생하여 자신이 생성한 템플릿이 보이지 않는다.

해결 방법

1. �사용자가 충분히 많아진 경우 좋아요 순 정렬을 기본값으로 변경한다.
2. 좋아요 순 정렬의 경우 가장 상위의 데이터는 변경이 적어 캐싱이 쉽다.
3. 최신순에 비해 복제 지연을 확인할 가능성이 낮아지고, 사용자 경험이 높아진다.
4. 캐시는 비용이 비싸기 때문에 일정 시간이 지날 경우 비운다.
5. 구경가기 첫 페이지에 진입할 경우, 캐시 서버에서 최신 조회된 템플릿들을 조회한다.
   +) 캐시는 비용이 비싸기 때문에 일정 시간이 지날 경우 비운다.

자주 조회되는 데이터에 대해 성능을 개선한다.

개선 이유

코드 템플릿은 도메인 특성상 생성/변경보다 조회가 훨씬 자주 일어난다.
변경이 자주 일어나지 않는 목록이 중복적으로 조회되어 쿼리가 발생하게 된다.
DB 레플리케이션을 통해 Reader 인스턴스가 2개 있긴 하지만, 변경이 자주 일어나지 않는 템플릿들에 대해 계속해서 조회하는 것은 불필요하다.

개선 방법

분산 환경이기 때문에 캐시 서버를 두어 조회가 잦은 배너 검색 결과, 구경가기 결과에 대해 캐시를 적용한다.

검색이 느려진다.

문제 상황

1. 키워드 검색은 프로젝트의 핵심 기능이지만, 성능이 느리다.
2. 3초 이상 걸리는 응답 때문에 사용자 이탈이 발생할 수 있다.

해결 방법

1. ES 를 사용하는 전문검색을 활용한다.

좋아요 개수 조회 쿼리로 인한 성능 저하

문제 상황

1. 현재 좋아요 수는 template 테이블과 Like 중간 테이블을 조인하여 계산하고 있다.
2. 템플릿, 좋아요 수가 많아질수록 좋아요 수의 집계가 더욱 오래 걸릴 것이며, 좋아요순 정렬에 많은 시간이 걸려 성능이 저하될 것이다.

해결 방법

1. Template 테이블에도 좋아요 수를 컬럼으로 가지도록 반정규화를 진행한다.
2. 좋아요 수가 적당히 많은 템플릿에 대해서는 좋아요 업데이트를 배치로 업데이트 한다.

로드밸런서 다중화

• 로드밸런서에 대한 부하도 걱정됨
• 현재 1대의 로드밸런서만을 사용중이기 때문에 로드밸런서 자체가 과부하가 되는 경우 서비스 자체를 이용할 수 없게 됨.
• 이에 대한 해결책으로는 2대의 로드밸런서를 사용하고, DNS에서의 로드밸런싱 기술을 적용하는 것을 고려해볼 수 있음