HBase (Cluster) ELB (HTTP) API #1 API #3 API #2 HTTP • TCP를 위한 ELB를 하나 두기 • 작성 중 상태가 변경 될 때 마 다 HBase 요청이 일어나게 됨 • 메모리에 들고 있고 싶지만 각 연인이 다른 서버로 연결 됨 ELB (TCP) TCP HBase 요청이 지나치게 많이 일어나므로 실제 시스템에 적용하기에 부적절함
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서버의 설정을 매번 바꾸어 줘야하므로, 새로운 버전 배포가 매우 복잡함
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서버를 바로바로 알려주므로 그나마 간편한 롤링업데이트가 가능
(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서버 재시작 여전히 복잡함
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 과정 때문에 오토스케일링이 어려움
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)
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설정을 잘하면 하면 부담이 적음