43. Modular
여기서 서버가 한대가 추가되면 무슨 난리가…
데이터가 모두 섞여야 한다.
Server #1 Server #2
User #0 User #1
User #3 User #4
Server #2
User #2
User #5
44. Modular
두배로 늘리기
1에서는 3으로 절반이, 2에서는 4로 절반이 이동
Server #1 Server #2
User #0 User #1
Server #3 Server #4
User #2 User #3
User #4 User #5 User #6 User #7
49. Complexed
Master
Index
User RANGE #1 -> 1
Slave Slave
Master
Slave Slave
Master
Slave Slave
ONLY WRITE
ONLY READ
User RANGE #10 -> 1
User RANGE #20 -> 3
64. Zookeeper 의 특징
절대로 죽지않는다.(거짓말)
잘 안죽는다.(몇대 죽어도 상관은 없다.)
그러나 다 죽을때도 종종 있음.
임시 노드의 경우, Health Check를 통해서 자동적으로 접
속된 노드가 사라지면 데이터가 사라진다.(30초가 기본…)
Cluster Membership
노드의 순서를 보장해준다.
Leader Election
92. Blue-Green Deployment
Blue Set 과 Green Set이 존재.
현재 Blue Set으로 서비스 중이라면, 같은 양의 Green을
준비해서 Green Set에 새로운 버전을 배포…
일부 트래픽을 Green Set에 투입해서 테스트…
정상적이면, Blue Set을 바라보는 설정을 모두 Green을
바라보도록 수정
문제가 있다면, Blue Set으로 롤백
문제가 없다면, Blue Set 제거
93. Blue-Green 는 쉬운가?
같은 수의 장비를 쉽게 준비할 수 있을까?
Cloud 라면 손쉬움(두 벌을 유지하는 시간이
음.)
IDC 라면 어떻게?
예전에 모 B사의 W모 게임이 그렇게 했다고 합
니다.(거기는 부자니…)
94. Blue-Green 싸게 도입하기
점검 기간 두기
4대 보검중에 하나, 정기정검(게임쪽)
무정지 서비스가 안됨
Rolling Update
한대씩 로드밸런서나 설정에서 제거 후 배포
백업이나 배포 자체가 느릴 수 밖에 없음.
95. Blue-Green 싸게 도입하기
리소스를 제한해서 한 서버에서 두 개의 프로
세스 실행
Port 10000, 20000 번으로 배포.
Nginx 나 Proxy 단에서 설정 변경으로 새로운 서버로
전환
리소스를 적절하게 나누지 못하면 리소스 부족으로 서
버 장애 발생 가능
105. Location Latency #1
Seoul Busan
DB Server
Select * from posts
where id=123;
results
Select member from members
where id=poster.group;
results
API Server
Logic
Server
110. 결론
Internet Scale의 서비스를 만들기 위한 방법을 이해한다.
Kubernetes 나 Mesos 등등을 적용하면 직접 하는 것 보다 더
손쉽게 가능하기도(이건 저도 잘 모름)
Rolling Update, 자동재시작 이런것들을 처리해주는…
모니터링/로그는 더더욱 중요합니다.