본문 바로가기
나만의 정리

대용량 트래픽 처리(입문)

by 코리늬 2019. 3. 4.

최소한의 아키텍처 구성

API-Server 2개
  • 실제 비즈니스 로직 처리
Load Balancer
  • Request를 연결된 서버들에게 나누어줌
  • 장애 발생시 해당 LB에게 할당된 IP를 다른 LB에게 넘겨줌
DBMS 2개
  • primary(실제 서비스)

  • secondary(데이터 복사)

    두대를 두고 primary의 데이터를 secondary로 계속 Replication을 통해 복제한다.

    primary에서 장애 발생시 secondary가 primary로 되고, 장애가 해결되도 primary는 secondary 역할을 하게 된다.

    마스터, 슬레이브

Object Storage Service (File-Server)
  • 파일을 저장할 서버를 둘 경우 총 3개의 File-server가 필요하다.
  • 3개를 사용할 시 Data Loss : 99.999%가 보장된다.
  • AWS S3, AZURE Blob, Gcp Google Storage에서 서비스를 제공한다.

하지만 데이터가 많아질 수록 DBMS의 TPS 한계가 온다.

TPS(Transaction Per Second)
  • 초당 몇개의 명령을 처리할 수 있는가
  • ex) MAX 1000 TPS = 1초에 1000개의 명령을 처리
  • CPU, 메모리, 디스크 등 하드웨어 적인 부분이 속도에 영향을 미친다.
  • 너무 많은 경우 오래걸리거나 장비가 고장날 수 있다.

대규모 서비스의 특성

  • Elastic

    트래픽이나 상황에 따라서 서버의 추가/제거가 쉬워야 한다.

  • Resiliency

    특정 장비의 장애 등은 자동으로 복구가 되어야 한다.

    ​ 서버가 복구되는 건 아님

    ​ 해당 장비의 장애로 인해 다른 쪽이 영향을 받으면 안됨

  • Scale UP

    장비의 성능을 UP

  • Scale Out

    장비의 수를 늘려 성능을 UP

  • SPOF (Single Point Of Failure)

    장애 발생시 서비스 전체를 마비시키는 병목지점


  • API 서버에 부하가 물리는 작업은 ?

    파일 IO가 많은 정적 파일

    웹 스크래핑과 같은 디비 작업 자체보다 다른 작업이 많은 작업

    독립적인 작입이 가능하지만, CPU나 다른 작업이 많이 필요한 작업 (ex lol, 배그 같은 게임서버)

    이미지, 영상 인식, 전처리 작업

  • DB 서버에 부하가 물리는 작업은 ?

    카톡방 대화, 페이스북 댓글, 대부분의 작업

  • Stateless - API 서버는 비즈니스 로직만 가짐

    • 장점

      추가/삭제가 간단 - 주소만 추가/제거로 가능

    • 단점

      결국 데이터의 저장이 필요해 뒤로 책임을 떠 넘기는 구조

  • DB의 경우 일반적인 서버의 부하
    • 800 reads/s , 200 writes/s => Read > Write
    • 읽기의 분배 - Query Off 필요 (Master, Slave 개념)
    • Slave 장비를 추가해도 한계가 발생 => Database Partitioning
  • Database Partitioning

    • Vervical Partitioning
    • Horizontal Partioning
    • Sarding Horizontal Partitioning
  • 특정 key를 저장하는 방법, 특정 Key를 찾는 방법

    • Consistent Hashing - 해쉬 값이 자기보다 크거나 같은 서버들 중 가장 가까운 서버로 KEY가 할당됨
  • Key만 보고 어떤 서버에서 찾아야 할지 알 수 있나 ?

    • Unique 해야함
  • Key만 보고 시간 순을 알 수 있나 ?

    • UUID (Universally Unique Identifier)
    • 128 bit
    • 36 characters
    • ex) 123e4567-e89b-12d3-a456-426655440000
  • UUID의 단점

    • 128 bit는 너무 용량이 큼, 그래서 보통 Shard Id가 들어간다.
  • shard

    자신의 메일 리스트를 저장한 서버 번호

    • Shard Id와 실제 서버의 매핑
    • 시간 정보가 들어가면 ID 만으로 시간 정렬이 가능
    • 변화하지 않을 특별한 정보를 넣으면 좋음
    • {TimeStamp}-{ShardId}-{Type}-{seq}

ex) Twitter의 ID : timestamp + datacenter ID + worker ID + sequence

​ instagram의 ID : timestamp + logical shard ID + auto increment

  • 데이터의 Scale Out

    • Range - 특정 범위대역으로 나누기
    • Modular - 서버 대수로 나누기 (서버가 추가될 때마다 데이터의 이동이 심해지는 단점)
    • Indexed - 특정 데이터의 위치를 가리키는 서버가 존재

  • 대용량 서비스 설계 방법

    • SPOF 제거
    • 오브젝트 스토어
    • 데이터 샤딩
      • 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법을 의미
    • 코디네이터
    • Circuit Breaker
    • 블루/그린 배포, 카나리 배포
    • Feature Flag(Switch)

참고

https://12bme.tistory.com/100

https://www.slideshare.net/charsyam2/webservice-scaling-for-newbie

'나만의 정리' 카테고리의 다른 글

자바 제네릭 완전정복  (2) 2019.03.21
빌더 패턴(Builder Pattern)  (0) 2019.03.21
인터넷 용어 정리  (0) 2019.03.02
cmd telnet으로 메일 보내기 window10  (0) 2019.03.02
[Java]Comparable, Comparator 정리(+ 자료형)  (0) 2018.11.19

댓글