Upgrade to Pro — share decks privately, control downloads, hide ads and more …

비트윈 서버 아키텍처와 그에 따른 배포 방법

VCNC
February 16, 2013

비트윈 서버 아키텍처와 그에 따른 배포 방법

커플 앱 비트윈은 AWS상에서 구동됩니다. 비트윈 서버의 아키텍처와 그에 따른 배포 방법에 대해 설명합니다.
http://engineering.vcnc.co.kr/2013/04/between-system-architecture/

VCNC

February 16, 2013
Tweet

More Decks by VCNC

Other Decks in Programming

Transcript

  1. 비트윈 서버 아키텍처와
    그에 따른 배포 방법
    VCNC 개발팀 이정행
    2013.02.16
    아마존 웹 서비스 한국 사용자 모임
    VCNC 개발팀 이정행 (@eincs)
    2013.02.16

    View full-size slide

  2. 비트윈?
    커플들을 위한 모바일 서비스
    • 2.57M downloads
    • 611K weekly active users
    • 19M message per day
    • 160K photos per day

    View full-size slide

  3. 비트윈 서버 개발 스택
    JAVA로 개발되었고, Tokyo region에서 운영됨
    • Netty for network framework
    • Thrift for defining protocol
    • HBase for storing data

    View full-size slide

  4. 비트윈 서버 아키텍처
    서비스 상태 또는 제공되는 기능에 따라 변경됨
    • Single instance for closed beta
    • Multi instance for open beta
    • Shared instance for tcp chatting

    View full-size slide

  5. 비트윈 아키텍처 #1 (closed beta)
    한 개의 인스턴스, 가정집의 Mac mini로 운영

    View full-size slide

  6. 비트윈 아키텍처 #1 (Cont'd)
    세 개의 Git repository로 개발 및 배포
    dev
    build
    deploy
    HBase
    (Standalone)
    API Server
    (HTTP)
    stunnel
    (for HTTPS)
    dev에서 작업한 내용을 deploy에 반영 후, 운영 서버에서 git pull
    S3

    View full-size slide

  7. 비트윈 아키텍처 #2 (open beta 이후)
    여러 대의 인스턴스, AWS에서 운영
    HBase
    (Cluster)
    ELB
    API
    API
    API
    S3
    다운 타임을 최소화하기 위해, 인스턴스를 차례대로 롤링 업데이트
    (특정 인스턴스를 ELB에서 떼어낸 후, pull 받고 Netty서버 재시작)
    HTTP

    View full-size slide

  8. 비트윈 아키텍처 #3 (빠른채팅 이후)
    메세징에 대하여 TCP 프로토콜을 구현
    HBase
    (Cluster)
    ELB
    (HTTP)
    API #1
    API #3
    API #2
    HTTP
    • TCP를 위한 ELB를 하나 두기
    • 작성 중 상태가 변경 될 때 마
    다 HBase 요청이 일어나게 됨
    • 메모리에 들고 있고 싶지만 각
    연인이 다른 서버로 연결 됨
    ELB
    (TCP)
    TCP
    HBase 요청이 지나치게 많이 일어나므로
    실제 시스템에 적용하기에 부적절함

    View full-size slide

  9. 비트윈 아키텍처 #3 (cont'd)
    특정 API 서버가 특정 커플을 샤딩
    HBase
    (Cluster)
    ELB
    (HTTP)
    API #1
    API #3
    API #2
    HTTP
    ELB #1
    (TCP)
    ELB #2
    (TCP)
    ELB #3
    (TCP)
    TCP
    • 채팅 상태를 메모리에 들고 있음
    • 특정 커플은 특정 서버에 할당
    • 어떤 서버로 할당될지는
    Consistent Hashing으로 결정
    • 각 API 서버가 살아있는
    API서버 리스트를 관리해야함
     각 API서버의 설정을 매번 바꾸어
    줘야하므로, 새로운 버전 배포가 매우 복잡함

    View full-size slide

  10. 비트윈 아키텍처 #3 (cont'd)
    샤딩 정보를 ZooKeeper에서 관리
    HBase
    (Cluster)
    ELB
    (HTTP)
    API #1
    API #3
    API #2
    HTTP
    ELB #1
    (TCP)
    ELB #2
    (TCP)
    ELB #3
    (TCP)
    ZooKeeper
    TCP
    • API 서버가 추가 되거나 삭
    제되면 샤딩 정보가 바뀜
    • 샤딩 정보 변경시 ZK에서 살
    아 있는 API 서버로 바로 알
    려줌 ZooKeeper에서 살아있는 API서버를 바로바로
    알려주므로 그나마 간편한 롤링업데이트가 가능

    View full-size slide

  11. 비트윈 아키텍처 #3 (cont'd)
    그나마 간단하게 롤링 업데이트가 가능함
    HBase
    (Cluster)
    ELB
    (HTTP)
    API #1
    API #2
    HTTP
    ELB #1
    (TCP)
    ELB #2
    (TCP)
    ZooKeeper
    TCP
    1. ELB(HTTP)에서 API #3 제거
    2. ZooKeeper 업데이트하여
    살아 있는 노드에서 API #3 제거
    3. API #1, API #2는 API #3가 제거
    되었다는 사실을 즉시 알게 되고
    커플은 다시 샤딩 됨
    4. API #3에서 pull받고 Netty 재시작
    5. 다시 ELB들을 붙이고 ZooKeeper 업데이트
    API #3
    ELB #3
    (TCP)
    pull 받고 Netty서버 재시작
    여전히 복잡함

    View full-size slide

  12. 비트윈 아키텍처 #3 (cont'd)
    인스턴스가 새로 추가 될 때, ELB Warm-up이 필요함
    HBase
    (Cluster)
    ELB
    (HTTP)
    API #1
    API #2
    HTTP
    ELB #1
    (TCP)
    ELB #2
    (TCP)
    ZooKeeper
    TCP
    1. AMI에서 인스턴스 생성
    2. 새로 붙이는 ELB를 Warm-up
    3. ZooKeeper에 새로운 인스턴스
    붙이기
    4. HTTP ELB에 새로운 인스턴스
    추가
    API #3
    ELB #3
    (TCP)
    Warm-up 과정 때문에 오토스케일링이 어려움

    View full-size slide

  13. 비트윈 아키텍처 #4 (가까운 미래)
    자동화가 어려운 문제를 해결하기 위한 Multitier 아키텍처
    HBase
    (Cluster)
    ELB
    (HTTP)
    APP #1
    APP #3
    APP #2
    HTTP
    ELB
    (TCP)
    TCP
    Presentation
    #1
    Presentation
    #2
    Presentation
    #2
    Rocky
    Presentation Tier는 Stateless하므로, 오토 스케일이 쉽게 가능
    Application Tier는 Rocky의 도움을 받아, 배포 자동화, 오토 스케일, Failover가 가능
    (Rocky는 Between 서비스를 위해 개발한 일종의 Coordinator)

    View full-size slide

  14. 비트윈 아키텍처 #5 (먼 미래)
    좀더 나아가서, HBase 리전들을 APP 서버 로컬에 할당
    HBase
    (Cluster)
    ELB
    (HTTP)
    APP #1
    APP #3
    APP #2
    HTTP
    ELB
    (TCP)
    TCP
    Presentation
    #1
    Presentation
    #2
    Presentation
    #2
    Rocky
    HBase 리전들을 분산에 따라 APP서버의 담당 커플을 결정함특정 유저로 국한 됨
    Application Tier와 HBase Region간 통신이 로컬에서 이루어 지기 때문에 응답속도에 유리함
    http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ko//people/jeff/MIT_BigData_Sep2012.pdf
    HBase
    Region #1
    HBase
    Region #3
    HBase
    Region #2

    View full-size slide

  15. 비트윈 아키텍처 #5 (cont’d)
    Multizone으로 구성이 가능해짐
    APP#1
    APP#3
    APP#2
    P #1
    P #2
    P #3
    Rocky
    APP#1
    APP#3
    APP#2
    P #1
    P #2
    P #3
    Rocky
    ELB
    (HTTP)
    HTTP
    ELB
    (TCP)
    TCP
    • Presentation Tier는 비동기식으로 동작하므로 Zone간 Latency가
    부담이 없음
    • HBase에 Haeinsa 적용 후, Region서버간 통신은 묶여서
    호출되므로, HBase Cluste의 Rack설정을 잘하면 하면 부담이 적음

    View full-size slide

  16. Thank you for listening

    View full-size slide