사용자 수에 따른 규모 확장성

해당 챕터의 내용을 보면서 느낀점이 첫 위메프에 입사했을때가 생각이 났다. 첫 회사에서는 서버를 DB 1개 API 1개 만 두고 사용했으나, 위메프에서는 API서버를 쿠폰(36개), 리뷰(9개)를 사용하였다. 쿠폰, 리뷰의 master DB는 3개씩 존재했으며, slave는 6개 이상이 존재하였다. 서버들을 보면서 느낀점이 위메프는 수평적 확장을 주로 진행을 했구나 라는 것이었다. 그리고 각각의 서버의 CPU사용률 및 RAM 사용률이 높은 경우 수직적인 확장을 진행하였다. 이처럼 사용자가 많으면 2가지를 섞어 쓰는 것을 배웠으며, 좀더 디테일하게 해당 내용을 공부할 예정이다. 

 

 

수직적 확장(Scale up & vertical scaling)

• 서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM)을 추가하는 행위를 뜻한다.

수평적 규모 확장(scale out)

• 더 많은 서버를 추가항 성능을 개선하는 행위를 뜻한다.

장단점

• 수직적 규모 확장에는 한계가 존재
  • 한 대의 서버에 CPU나 메모리를 무한대로 증설할 방법은 없다.
• 수직적 규모 확장법은 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 않는다. 
  • 서버에 장애가 발생하면 서버는 중단
• 대규모 애플리케이션을 지원할 때는 수평적 규모 확장법이 적절

로드밸런서(Load balancing set)

• 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다.
• 사용자는 로드밸런서의 공개 IP 주소에 접속을 진행하여 로브밸런서를 통해 웹서버에 접근한다.
• 로드밸런서는 서버 1이 다운되면 모든 트래픽은 모두 서버 2로 전송
  • 웹 서버의 전체 다운을 방지
• 웹사이트로 유입되는 트래픽이 많아지는 경우 웹 서버를 단순히 추가하면 된다.

로드밸런서

데이터베이스 다중화

• 서버 사이에 주(master)-부(slave) 관계를 설정하고 데이터 원본은 주버서에, 사본은 부 서버에 저장하는 방식
• 데이터 변경 연산은 주 데이터베이스 서버로만 전달되는 반면 읽기 연산은 부 데이터베이스 서버들로 분산되어 서능이 좋아진다.
• 데이터를 지역적으로 떨어진 여러 장소에 다중화를 시켜 놓을 수 있으므로 안전하다
• 하나의 데이터 베이스에 장애가 발생되더라도 다른 서버에 있는 데이터를 가져와 계속 서비스할 수 있다.

사용자가 많은 경우 기본적인 구조

캐시

자주 참조되는 데이터를 메모리 안에 저장하여 빠르게 참조하여 사용자에게 제공할 수 있는 저장소

캐시 계층

데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다. 별도의 캐시 계층을 두면 선응이 개선될 뿐 아니라 데이터베이스의 부하를  줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해진다.

읽기 주도형 캐시 전략(Read-through caching strategy)

캐시에 응답이 저장되어 있는지 확인 한 후 저장되어 있으면 해당데이터를 반환 아닌 경우 데이터베이스 조회를 통해 데이터를 찾아 캐시에 저장 한 후 클라이언트에 반환하는 전략

메세지 큐

• 메세지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트
  • 무손실이란?
    • 메세지 큐에 일단 보관된 메세지는 소비자가 꺼낼 때까지 안전히 보관
• 메세지의 버퍼 역할을 하며 비동기적으로 전송
• 전 회사에서 메세지 큐는 카프타랑 RabbitMQ를 사용했는데 결국 데이터를 DB에 저장전 작업해야될 내용을 보정하여 대용량으로 DB에 넣었다.
  
  • 예를들면 대용량 쿠폰발급, 대용량 쿠폰 상태 확인 등등

 

 

자 위의 내용을 토대로 전체적인 아키텍쳐를 그려보면 아래와 같다.(전회사랑 비슷한 아키텍쳐를 가졌음)