사용자 증가 시 발생할 수 있는 문제 상황과 개선 방안

자용자 증가 시 발생할 수 있는 문제 상황과 그에 따른 개선 방안

• 사용자가 만 명 이상이라고 가정한다.

1. 성능 저하 문제

시스템이 한정된 리소스 안에서 처리할 수 있는 용량을 넘어서게 되어, 요청에 대한 응답 시간이 길어지거나 에러가 발생하는 상황

문제 상황

• 읽기 작업 집중: 코드잽의 대부분 API가 읽기 연산에 집중되어 있기 때문에, DB가 처리할 수 있는 읽기 요청의 한계에 도달할 수 있다.
• 네트워크 지연: 사용자가 해외에서 접속할 때, 데이터가 멀리서 전송되면서 응답 시간이 길어질 수 있다.
• 로그 과다 생성: 불필요한 로그가 많이 쌓여 로그 처리에 리소스가 많이 소비되면서 성능에 악영향을 줄 수 있다.

해결 방법

• 읽기 전용 DB 증설: 읽기 요청을 분산하여 성능을 개선한다.
• 해외 AZ 및 CDN 활용: 해외 사용자가 가까운 지역에서 더 빠르게 데이터를 받을 수 있도록 한다.
• 로그 최적화: 불필요한 로그는 제거하고, 필요한 메시지만 기록하여 시스템 자원 소비를 줄인다.

2. 확장성 문제

시스템이 더 많은 사용자나 데이터, 요청을 처리하기 위해 유연하게 리소스를 늘리거나 조정할 수 있는 능력

확장성이 부족하면 시스템이 일정 수준 이상의 부하를 감당하지 못하고 성능이 급격히 저하된다

문제 상황:

• 사용자 증가: 한정된 서버와 DB 용량으로는 급격히 증가하는 사용자 수를 감당할 수 없게 되는 상황을 말한다.
• 모니터링 및 로그 관리 부족: 사용자와 요청이 증가할 때, 모니터링과 로그 관리 시스템이 적절하게 확장되지 않으면 시스템 상태를 제대로 파악하지 못하고 장애를 초래할 수 있다.

해결 방법:

• 서버와 DB의 Scale out & Scale up: 수평적, 수직적 확장을 통해 시스템이 증가하는 사용자 수와 데이터 요청을 처리할 수 있도록 한다.
• 다중 AZ 분산: 시스템을 여러 지역으로 분산 배치하여 가용성을 높이고, 동시에 확장성을 강화한다.
• 로그 용량 관리: 로그 관리 시스템도 함께 확장 가능하도록 하여 리소스 소모를 효율적으로 통제한다.

3. 복제 지연 문제

DB 복제가 지연될 때, 최신 데이터를 조회하지 못하거나 잘못된 데이터를 반환하는 문제

문제 상황

템플릿 생성 후 복제 지연 발생 시 다음 페이지에서 생성된 템플릿이 조회되지 않을 수 있다.

• 템플릿 상세 페이지:
  • 사용자가 템플릿을 생성한 후, 자동으로 템플릿 상세 페이지로 리다이렉트된다.
  • 이때 READER DB에서 조회 요청을 처리하는데, 복제 지연이 발생하면 생성한 템플릿이 제대로 조회되지 않을 수 있다.
• 구경가기 페이지:
  • 사용자가 템플릿을 생성한 후 구경가기 페이지로 이동하면 기본 정렬이 최신순으로 설정되어 있다.
  • 복제 지연으로 인해 방금 생성한 템플릿이 최신순 목록에 표시되지 않을 수 있다.

해결 방법:

• 글로벌 캐시 저장: 템플릿 생성 시, 해당 템플릿 데이터를 글로벌 캐시에 저장하여 복제 지연 동안 최신 데이터를 제공한다.
• 캐시 만료 설정: 캐시 비용 절감을 위해 일정 시간이 지나면 캐시 데이터를 비워 비용을 관리한다.
• 구경가기 캐시 사용: 첫 페이지에 진입할 때, 캐시 서버에서 최신 템플릿 목록을 조회하여 복제 지연 문제를 완화한다.
• 좋아요 순 정렬 변경: 사용자가 많아진 경우 기본 정렬을 "좋아요 순"으로 변경한다.
  • 상위 데이터는 변경이 적어 캐싱이 용이하고, 복제 지연 문제를 겪을 가능성이 줄어든다.

결론

복제 지연 문제는 캐시를 활용해 해결하고, 비용 효율성을 고려하여 캐시를 적절히 관리한다.

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

문제 상황

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에서의 로드밸런싱 기술을 적용하는 것을 고려해볼 수 있음