1.
대규모 서비스를 설계하는 기술
- 중급(일반편)
강대명(charsyam@naver.com)

2.
발표자 소개
● 오픈 프론티어 5기 파트타임(현)
● Data Engineer at Udemy(현)
● Software Engineer at Kakao(카카오 스토리)
● Software Engineer at Naver(네이버 메일)
● Software Engineer at Finaldata

3.
배틀그라운드

4.
Facebook

5.
대용량 서비스 설계 방법
● SPOF 제거
● 오브젝트 스토어
● 데이터 샤딩
● 코디네이터
● Circuit Breaker
● 블루/그린 배포, 카나리 배포
● Feature Flag(Switch)

6.
SPOF

7.
SPOF
Single Point Of
Failure

8.
SPOF
여기가 죽으면…
다 죽습니다.

9.
이런 구조라면!!!
Web Browser
Mobile Apps
API Server DB

10.
이런 구조라면!!!
Web Browser
Mobile Apps
API Server DB

11.
API Server 가 죽으면?
Web Browser
Mobile Apps
API Server DB

12.
DB 가 죽으면?
Web Browser
Mobile Apps
API Server DB

13.
그래서 보통 이런 구조
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Secondary

14.
API Server 가 죽어도?
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Secondary

15.
DB 가 죽어도?
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Secondary

16.
DB 가 죽어도?
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Primary

17.
SPOF
SPOF를 없애는
것이 관건!!!

18.
그래도 서버가 물리 서버 한대면
DB
Primary
API Server 1
Web Browser
Mobile Apps
API Server 2
DB
Secondary

19.
그래도 서버가 물리 서버 한대면
DB
Primary
API Server 1
Web Browser
Mobile Apps
API Server 2
DB
Secondary

20.
Object
Storage

21.
Object Storage
이미지나 동영상을
어떻게 관리해야 할까요?

22.
Object Storage
NAS나
서버 한대에서
자체 관리

23.
자체 관리하면 서버가 여러대일때...
Image 2는 어디서 찾아야 할까?
Web Browser
Mobile Apps
API Server 1
API Server 2 File Server
Image 2
Image 9
Image 3
File Server
Image 1
Image 10
Image 4

24.
자체 관리 방식의 문제점
● 디스크 등의 증설 시기를 맞추기가 어렵다.
● 데이터 유실 확률이 높다.
● Object Store 형태로 갈려면, 구현하기가 어려움.
○ 큰 회사들은 대부분 자체 구현해서 씀.

25.
3개의 복제본

26.
Data Loss : 보통 3개의 복제본을 두면 99.999% 보
장
보장율 복제 개수
99.99% 2
99.999% 3

27.
Object Store 의 역할
● 이미지 등의 파일(오브젝트)를 저장함.
● 내부적으로 복제본이 생겨서 유실의 가능성이 적음
○ 사람이 실수로 지울때는…(S3는 Versioning을 지원)
● 스토리지의 사이징, 장애등에 대한 고민이 적어짐.

28.
Object Store
잘 동작하는 오브젝트 스토어를
만들기는 쉽지 않습니다.
있는 걸 잘 씁시다.(AWS S3)

29.
외부 서비스 형태로 이용이 편하다.
Web Browser
Mobile Apps
API Server 1
API Server 2
Object
Storage

30.
데이터 샤딩

31.
데이터 샤딩
필요한 메타 정보들이
엄청나게 거대하다면?

32.
데이터 샤딩

33.
데이터 샤딩
데이터를 어떻게 나누고
찾을것인가?

34.
다음 데이터를 두 개로 나누면 어떻게 해야 할까요?
1
2
3
4
5

35.
두 개로 나누기
1
2
3
4
5

36.
아무렇게나?
1 2
3
4
5

37.
이러면 각 숫자가 어디에
있는지 알 수가 없습니다.

38.
어디에 있는지를 모르면
전체를 찾아야 합니다.

39.
전체를 찾게 되면
모든 노드에 매번
부하를 주게됩니다.

40.
데이터를 나누는 기준,
규칙이 필요합니다.

41.
한 군데로 몰기
1
2
3
4
5

42.
순서대로
1
2
3
4
5

43.
2로 나눠서 나머지가 1이면 앞에, 0이면 뒤에
1 2
3 4
5

44.
여기서 서버 수가 변하면
어떻게 될까요?

45.
2로 나누는게 아니라 3으로 나눠야 하면?
1 2
3 4
5 6
7 8

46.
2로 나누는게 아니라 3으로 나눠야 하면?
5
1 2 3
4 6
7 8

47.
많은 수의 데이터가
이동을 해야 합니다.
그런데
어디로 이동할지 모릅니다.

48.
모듈러는 2^N 으로 증가하는게 좋습니다.
1 2 3 4
5 6 7 8

49.
2^N으로 증가하면 이동하는 서버가 고정됩니다.
1 2 3 4
5 6 7 8

50.
확장에 데이터가 적게
움직이는 방법을
연구해야 합니다.

51.
코디네이터

52.
코디네이터
추가되고 삭제되는
서버 목록을 어떻게 관리할 것인가?

53.
코디네이터
서버의 추가 삭제시, 이를 이용하는
서비스에 알려준다.

54.
코디네이터
API Server
API Server
API Server
Cordinator
Auth Server
Auth Server

55.
코디네이터
API Server
API Server
API Server
Cordinator
Auth Server
Auth Server
Auth Server
2. Auth Server 추가
3. Auth Server 가 추가
되었음, 다시 목록을 가
져가시오.
1. Auth Server 의 변동
을 알려줘!!!

56.
코디네이터
Zookeeper
Etcd
consul

57.
Circuit Breaker

58.
Circuit Breaker 의 필요성
● 현재의 서비스는 다 수의 많은 외부 서비스의 API(자기 팀 이외에, 또는
자기 팀에서 관리하더라도 다른 서버의)를 사용하게 됨.
● 보통은 장애를 대비해서 Timeout을 설정하게 되는데…
○ Timeout 이 길면... 전체적인 서비스가 계속 느려지게 됨.
○ 해당 스레드/프로세스가 Timeout 동안 다른 작업을 못함.
● API 중에 중요하지 않은 서비스들도 있음(광고를 보여준다거나…)

59.
Circuit Breaker
Timeout 이 3초면 해당 스레드는 중요
하지 않은 API를
기다린다고 3초를 허비

60.
Circuit Breaker
요청이 쌓이면... 해당 서비스도 응답이
느려지기 시작함.

61.
Circuit Breaker
차라리 빨리 실패하고, 다른 값을 주자
!!!
Fast Fail Back!!!
Return (미리 정의된 값)

62.
Circuit Breaker
광고를 못가져오면,
그냥 다른 이미지로 대체
광고 API가 죽더라도
서비스는 느려지지 않는다.

63.
블루/그린 배포, Canary 배포

64.
배포
기존의 배포가 힘든 이유

65.
기존의 배포가 힘든 이유
● 버그의 존재
○ 문제가 발생했을 때, 해당 범위가 클 수 있다.
● 배포에 시간이 너무 많이 걸린다.
○ 롤백 시간도 배포시간 만큼 오래걸린다.

66.
배포
이런 문제를 해결하기 위한 방법

67.
배포
쉬운 배포 방법(자동화된 배포)
버튼 하나, 명령 하나로...
수많은 자동화된 테스트가 필요
(CI/CD)
커밋될 때마다...

68.
배포
롤백 시간을 줄일려면?

69.
Blue/Green 배포
새로운 한벌을 구성해서 배포, 그리고 라우터의 변경으로
서버군을 변경

70.
Blue/Green 배포
롤백은 다시 라우터
변경으로 순식간!!!

71.
Blue/Green 배포
그런데 항상 두벌씩 유지하라굽쇼!!!!
클라우드 아니면 힘듭니다.

72.
Blue/Green 야매 버전 배포

73.
Blue/Green 야매 버전 배포

74.
Blue/Green 야매 버전 배포

75.
Blue/Green 야매 버전 배포

76.
Blue/Green 야매 버전 배포의 문제점
● 결국 둘 다 리소스를 많이 사용하는 경우, 시스템에 장애가 발생할 수
있다.
● 피크 타임은 피해서 배포해야 한다.
● Graceful Shutdown 잘 되어 있어야 한다. (Router 의 역할도 중요함.)

77.
Blue/Green 배포와 데이터베이스 스키마 변경
● DB 스키마 변경은 지옥으로 가는 지름길…
○ 최대한 추가만 하고, 삭제와 변경은 하지 않는다.
○ 몇번의 배포이후 확실히 사용하지 않는다는 것이 확인될 때
삭제가능.
● 롤백보다는 빨리 고치는 걸 추천
● Feature Flag를 활용해보자.

78.
Canary 배포
블루/그린을 하더라도 장애가
발생하면 대상의 범위가 넓다

79.
Canary 배포
데이터가 지워지는 심각한 문제라면?

80.
Canary 배포
일부 유저에게만 적용해보자.
서버가 100대면 유저의 1%만…
잘되면 10%... 더 잘되면 전체 배포

81.
Canary 배포 : 한대만 배포해서 제대로 동작할까?
User #1이 다음번에
요청을 하게 되는 서버는?
항상 4번으로 간다는 보장이 없다.

82.
Canary 배포
유저의 격리가 선행될 수 있어야 함.
서버군이 아예 다르거나…
A/B Test 형태로 적용이 가능하거나...

83.
Feature Flag(Switch)

84.
Feature Switch
새로 나갈 기능을 배포없이 옵션으로
실시간으로 끄고 켤 수 있도록 준비

85.
Feature Flag(Switch) 의 장점
● 특정 기능에 문제가 생겼을 때, 해당 기능을 꺼버리면 된다.
○ 롤백 배포도 필요 없음.
● 다만 특정 기능이 동작하지 않는다면, UI에서는 어떻게 보여질지, 협의
가 필요.
○ 클라이언트 작업이 필요할 수 있음.
■ 클라이언트는 특정값이 오는 걸로 가정해버리면... 다 함께
Crash!!!

86.
요약
● 대용량 서비스 설계는
○ SPOF를 줄이고 가능한 장비추가로 인한 선형적인 성능 증대가 필
요하다.
● 여러가지 상황에 맞추기 위해 자동화가 필수(배포/테스트)
○ 몇 백대 이상의 서버를 관리해야 한다.
● 항상. 이러면 수백만명이 동시에 써도 괜찮을까를 물어보자.

87.
감사합니다.