• 중고거래 사이트 프로젝트를 하며 로그인 기능을 개발 중이었습니다.

  • 대용량 트래픽을 대비하여 설계하고 있었기에 사용자가 한계치만큼 들어왔을 때를 가정하면 서버의 용량과 성능 업그레이드를 고려해야 했습니다.

  • 서버 리소스를 증설할 수 있는 두 가지 방법은 스케일 아웃과 스케일  두 가지 방식이 있습니다.

scale out 과 scale up 방식

  • 스케일 아웃(scale out)
    • 서버의 대수를 늘려 처리 능력을 향상하는 방법입니다.

    • 장점
      • 스케일 업에 비해 가격이 저렴한 소프트 웨어를 여러 대 사용합니다. 
           
      • 여러대로 분산되어 있어 장애 발생 시 영향도가 적습니다. 
               
      • 하나의 장비에서 처리하던 일을 여러 장비에서 나눠 처리하여 지속적 확장 가능(수평 확장)
    • 단점
      • 병렬 컴퓨팅 환경을 구성 유지하려면 아키텍처(로드 벨런싱)에 대한 높은 이해도가 필요합니다.
               
      • 코어가 늘어남에 따라 성능이 증가하지 않고, 코어 증가에 따라 대역폭은 증가해 지연이 발생할 가능성이 있습니다.

  • 스케일 업(scale up)
    • 서버에 CPU나 RAM 등을 추가하여 서버의 처리 능력을 향상하는 방법입니다.

    • 장점
      • 제어가 힘들거나 분할 구성이 어려운 복잡한 서비스를 처리할 수 있습니다.

    • 단점
      • 서버  대에 모든 부하가 집중되므로 장애  영향을 크게 받을  있는 위험성이 있습니다.

  • 문제 상황
    • RDBMS를 사용할시 대량의 데이터를 처리하려면 스케일업을 해야하는데 스케일업은 한계가 있다.
    • 데이터 증가시 새로운 장비를 교체하는 방법은 데이터 마이그레이션 작업이 필요하고 새로운 장비를 교체할때 서버 다운이 불가피 합니다.

    • 또한, 디스크에서 불러오기 때문에 읽고 쓰는 속도가 느립니다. 이유는 디스크에서 디스크 헤드가 원하는 위치까지 이동하기 위해 필요한 시간이 매우 길기 때문이다.

    • RDBMS 부하의 분산이 어렵습니다. 보통 마스터는 프로그램단에서 입력만 하게끔 하고, 복제 DB 부하 분산 시스템을어느 정도 구축할 있지만 복제 DB 비동기 방식이라 가끔 데이터가 안 맞거나 마스터가 죽을 대체 동작(Failover) 를 해야 한다.

    • 이러한 단점들을 보안하기 위한 솔루션
      • MMM(Multi-Matser Replication Manager) 마스터가 죽을 슬레이브를 마스터로 변경
      • Mha(Matser High Ability) MMM + 앞단에 MHA 매니저 서버 ( 빠른 failover 슬레이브 릴레이 로그까지 취합 산하여 데이터 정합성 향상)
      • Mysql-Proxy 읽기 부하 분산 전용, 쓰기와 읽기를 구분 하는 방식들이 있긴 하지만 근본적인 해결책은 아니다.

  • 디스크 저장 시에 오는 속도 저하의 해결 방법
    • -메모리 컴퓨팅
      • 즉, 특정 데이터를 특정 만료시간안에 들고 있어서 데이터의 정합성은 양보하지만 데이터 처리 속도는 빨라집니다.
    •  로컬 캐싱
      • 특정 장비 안에서만 캐시를 참조하기 때문에 처리 속도가 빠릅니다. 하지만 근본적인 문제점이 있습니다.

      • 보통의 애플리케이션 데이터인 서비스 캐시는 메모리 또는 서비스에 대한 외부에서 구현될 수 있다. 캐시 된 데이터가 서버 사이에서 일관되지 않다는 점입니다.

      • 캐시 일관성 불일치. 예를 들면 클라이언트가 서비스에 대한 호출을 반복하면 요청을 처리하는 서버에 따라 첫 번째는 최신 데이터가, 두 번째 호출에는 이전 데이터가 사용될 수 있습니다.

      • 또한, 서버 수가 늘어나면 로컬 캐싱을 사용하는 서버에서도 부하가 발생할 수 있습니다.

      • 인 메모리 캐시도 "콜드 스타트" 문제에 취약합니다. 이 문제는 새 서버가 완전히 빈 캐시로 시작할 때 발생합니다. 경우 캐시가 채워지면 종속된 서비스에 대한 요청이 갑자기 늘어날 있습니다.

    •  로벌 캐싱 
      • 여러 서버에서 캐시 서버에 접근하여 참조 할수 있기 때문에 보통의 애플리케이션 서비스 캐시의 요구사항을 만족시킵니다.

      • 다만 별도의 캐시 서버를 이용하기 떄문에 캐시 서버와 통신하는 비용이 듭니다. 이렇게 캐시 서버를 분산하여 저장하는 방식은아래와같습니다.

      • Replication 방식은 동일한 데이터를 master/slave 저장하는 방식이 있고,

      • Sharding 방식은 테이블 스키마를 가진 데이터를 다수의 데이터 베이스에 분산 저장하는 방식이 있습니다. 이위 방식들로 디스크 처리 속도를 보완할 있습니다.

      • 그리고 근본적인 스케일업의 한계를 고치려면 스케일 아웃이라는 개념이 필요합니다.

  •  스케일업의 한계
    • 다만 스케일업을 할수록 기존 하드웨어의 냉각, 공간, 전력공급 등의 문제가 발생할 수 있고, 하드웨어 허용 범위 내에서만 확장이 가능하기 때문에 그 이상으로 업그레이드를 하고자 한다면 새로운 장비로 교체하는 방법밖에 없습니다.
    • 새 장비로 교체 시에도 데이터 전체의 마이그레이션 작업이 필요해 HA 구성이 아닌 이상 다운타임이 불가피하며, 저장된 데이터양에 따라 작업이 수개월 걸리는 경우도 있습니다.

  • 하드디스크 vs -메모리 컴퓨팅 기술
    • 인메모리 컴퓨팅이란 애플리케이션이 운영을 위한 데이터를 하드디스크가 아닌 메인 메모리에 올려두고 서비스를 수하는 것을 말한다. (WAS Heap 공간을 의미하는것 같다.)
    • 이게 가능해진 이유는 메인 메모리의 가격이 하락했기 때문이다.

 

 

  • 결론
    • 환경에 따라 어떤 방식이 더 합리적인 이유로 적합한지 고려하며 구축하는 것을 권장합니다.

    • 예를 들면, 웹사이트의 접속자가 증가해서 트리팩이 많이 발생할 경우에는
      웹 서버 특성() 데이터 변화가 적으므로 스케일 아웃 방식이 효과적이며, 비용도 저렴합니다.

    • 그 반면,  데이터베이스 서버와 같이 빈번한 갱신이 필요하며 분할 구성이 어려운 복잡한 서비스에는
      스케일 업 방식으로 시스템을 확장해야 합니다.

    • 중고거래 사이트 경우 모든 서버가 동일한 데이터를 가지고 있어야 하고, 데이터 변화가 적으므로
      스케일 아웃 방식을 사용하기로 했습니다.

 

프로젝트 참고

 

junshock5/used-market-server

중고거래 프로젝트. Contribute to junshock5/used-market-server development by creating an account on GitHub.

github.com

다음 포스팅에는!

다중 서버 환경에서 Session 공유법 - 2편(Sticky Session , Session Clustering , Inmemory DB)

+ Recent posts