SlideShare a Scribd company logo
1 of 90
Download to read offline
대규모 서비스를 설계하는 기술
- 중급(일반편)
강대명(charsyam@naver.com)
발표자 소개
● 오픈 프론티어 5기 파트타임(현)
● Data Engineer at Udemy(현)
● Software Engineer at Kakao(카카오 스토리)
● Software Engineer at Naver(네이버 메일)
● Software Engineer at Finaldata
배틀그라운드
Facebook
대용량 서비스 설계 방법
● SPOF 제거
● 오브젝트 스토어
● 데이터 샤딩
● 코디네이터
● Circuit Breaker
● 블루/그린 배포, 카나리 배포
● Feature Flag(Switch)
SPOF
SPOF
Single Point Of
Failure
SPOF
여기가 죽으면…
다 죽습니다.
이런 구조라면!!!
Web Browser
Mobile Apps
API Server DB
이런 구조라면!!!
Web Browser
Mobile Apps
API Server DB
API Server 가 죽으면?
Web Browser
Mobile Apps
API Server DB
DB 가 죽으면?
Web Browser
Mobile Apps
API Server DB
그래서 보통 이런 구조
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Secondary
API Server 가 죽어도?
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Secondary
DB 가 죽어도?
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Secondary
DB 가 죽어도?
Web Browser
Mobile Apps
API Server 1
API Server 2
DB
Primary
DB
Primary
SPOF
SPOF를 없애는
것이 관건!!!
그래도 서버가 물리 서버 한대면
DB
Primary
API Server 1
Web Browser
Mobile Apps
API Server 2
DB
Secondary
그래도 서버가 물리 서버 한대면
DB
Primary
API Server 1
Web Browser
Mobile Apps
API Server 2
DB
Secondary
Object
Storage
Object Storage
이미지나 동영상을
어떻게 관리해야 할까요?
Object Storage
NAS나
서버 한대에서
자체 관리
자체 관리하면 서버가 여러대일때...
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
자체 관리 방식의 문제점
● 디스크 등의 증설 시기를 맞추기가 어렵다.
● 데이터 유실 확률이 높다.
● Object Store 형태로 갈려면, 구현하기가 어려움.
○ 큰 회사들은 대부분 자체 구현해서 씀.
3개의 복제본
Data Loss : 보통 3개의 복제본을 두면 99.999% 보
장
보장율 복제 개수
99.99% 2
99.999% 3
Object Store 의 역할
● 이미지 등의 파일(오브젝트)를 저장함.
● 내부적으로 복제본이 생겨서 유실의 가능성이 적음
○ 사람이 실수로 지울때는…(S3는 Versioning을 지원)
● 스토리지의 사이징, 장애등에 대한 고민이 적어짐.
Object Store
잘 동작하는 오브젝트 스토어를
만들기는 쉽지 않습니다.
있는 걸 잘 씁시다.(AWS S3)
외부 서비스 형태로 이용이 편하다.
Web Browser
Mobile Apps
API Server 1
API Server 2
Object
Storage
데이터 샤딩
데이터 샤딩
필요한 메타 정보들이
엄청나게 거대하다면?
데이터 샤딩
데이터 샤딩
데이터를 어떻게 나누고
찾을것인가?
다음 데이터를 두 개로 나누면 어떻게 해야 할까요?
1
2
3
4
5
두 개로 나누기
1
2
3
4
5
아무렇게나?
1 2
3
4
5
이러면 각 숫자가 어디에
있는지 알 수가 없습니다.
어디에 있는지를 모르면
전체를 찾아야 합니다.
전체를 찾게 되면
모든 노드에 매번
부하를 주게됩니다.
데이터를 나누는 기준,
규칙이 필요합니다.
한 군데로 몰기
1
2
3
4
5
순서대로
1
2
3
4
5
2로 나눠서 나머지가 1이면 앞에, 0이면 뒤에
1 2
3 4
5
여기서 서버 수가 변하면
어떻게 될까요?
2로 나누는게 아니라 3으로 나눠야 하면?
1 2
3 4
5 6
7 8
2로 나누는게 아니라 3으로 나눠야 하면?
5
1 2 3
4 6
7 8
많은 수의 데이터가
이동을 해야 합니다.
그런데
어디로 이동할지 모릅니다.
모듈러는 2^N 으로 증가하는게 좋습니다.
1 2 3 4
5 6 7 8
2^N으로 증가하면 이동하는 서버가 고정됩니다.
1 2 3 4
5 6 7 8
확장에 데이터가 적게
움직이는 방법을
연구해야 합니다.
코디네이터
코디네이터
추가되고 삭제되는
서버 목록을 어떻게 관리할 것인가?
코디네이터
서버의 추가 삭제시, 이를 이용하는
서비스에 알려준다.
코디네이터
API Server
API Server
API Server
Cordinator
Auth Server
Auth Server
코디네이터
API Server
API Server
API Server
Cordinator
Auth Server
Auth Server
Auth Server
2. Auth Server 추가
3. Auth Server 가 추가
되었음, 다시 목록을 가
져가시오.
1. Auth Server 의 변동
을 알려줘!!!
코디네이터
Zookeeper
Etcd
consul
Circuit Breaker
Circuit Breaker 의 필요성
● 현재의 서비스는 다 수의 많은 외부 서비스의 API(자기 팀 이외에, 또는
자기 팀에서 관리하더라도 다른 서버의)를 사용하게 됨.
● 보통은 장애를 대비해서 Timeout을 설정하게 되는데…
○ Timeout 이 길면... 전체적인 서비스가 계속 느려지게 됨.
○ 해당 스레드/프로세스가 Timeout 동안 다른 작업을 못함.
● API 중에 중요하지 않은 서비스들도 있음(광고를 보여준다거나…)
Circuit Breaker
Timeout 이 3초면 해당 스레드는 중요
하지 않은 API를
기다린다고 3초를 허비
Circuit Breaker
요청이 쌓이면... 해당 서비스도 응답이
느려지기 시작함.
Circuit Breaker
차라리 빨리 실패하고, 다른 값을 주자
!!!
Fast Fail Back!!!
Return (미리 정의된 값)
Circuit Breaker
광고를 못가져오면,
그냥 다른 이미지로 대체
광고 API가 죽더라도
서비스는 느려지지 않는다.
블루/그린 배포, Canary 배포
배포
기존의 배포가 힘든 이유
기존의 배포가 힘든 이유
● 버그의 존재
○ 문제가 발생했을 때, 해당 범위가 클 수 있다.
● 배포에 시간이 너무 많이 걸린다.
○ 롤백 시간도 배포시간 만큼 오래걸린다.
배포
이런 문제를 해결하기 위한 방법
배포
쉬운 배포 방법(자동화된 배포)
버튼 하나, 명령 하나로...
수많은 자동화된 테스트가 필요
(CI/CD)
커밋될 때마다...
배포
롤백 시간을 줄일려면?
Blue/Green 배포
새로운 한벌을 구성해서 배포, 그리고 라우터의 변경으로
서버군을 변경
Blue/Green 배포
롤백은 다시 라우터
변경으로 순식간!!!
Blue/Green 배포
그런데 항상 두벌씩 유지하라굽쇼!!!!
클라우드 아니면 힘듭니다.
Blue/Green 야매 버전 배포
Blue/Green 야매 버전 배포
Blue/Green 야매 버전 배포
Blue/Green 야매 버전 배포
Blue/Green 야매 버전 배포의 문제점
● 결국 둘 다 리소스를 많이 사용하는 경우, 시스템에 장애가 발생할 수
있다.
● 피크 타임은 피해서 배포해야 한다.
● Graceful Shutdown 잘 되어 있어야 한다. (Router 의 역할도 중요함.)
Blue/Green 배포와 데이터베이스 스키마 변경
● DB 스키마 변경은 지옥으로 가는 지름길…
○ 최대한 추가만 하고, 삭제와 변경은 하지 않는다.
○ 몇번의 배포이후 확실히 사용하지 않는다는 것이 확인될 때
삭제가능.
● 롤백보다는 빨리 고치는 걸 추천
● Feature Flag를 활용해보자.
Canary 배포
블루/그린을 하더라도 장애가
발생하면 대상의 범위가 넓다
Canary 배포
데이터가 지워지는 심각한 문제라면?
Canary 배포
일부 유저에게만 적용해보자.
서버가 100대면 유저의 1%만…
잘되면 10%... 더 잘되면 전체 배포
Canary 배포 : 한대만 배포해서 제대로 동작할까?
User #1이 다음번에
요청을 하게 되는 서버는?
항상 4번으로 간다는 보장이 없다.
Canary 배포
유저의 격리가 선행될 수 있어야 함.
서버군이 아예 다르거나…
A/B Test 형태로 적용이 가능하거나...
Feature Flag(Switch)
Feature Switch
새로 나갈 기능을 배포없이 옵션으로
실시간으로 끄고 켤 수 있도록 준비
Feature Flag(Switch) 의 장점
● 특정 기능에 문제가 생겼을 때, 해당 기능을 꺼버리면 된다.
○ 롤백 배포도 필요 없음.
● 다만 특정 기능이 동작하지 않는다면, UI에서는 어떻게 보여질지, 협의
가 필요.
○ 클라이언트 작업이 필요할 수 있음.
■ 클라이언트는 특정값이 오는 걸로 가정해버리면... 다 함께
Crash!!!
요약
● 대용량 서비스 설계는
○ SPOF를 줄이고 가능한 장비추가로 인한 선형적인 성능 증대가 필
요하다.
● 여러가지 상황에 맞추기 위해 자동화가 필수(배포/테스트)
○ 몇 백대 이상의 서버를 관리해야 한다.
● 항상. 이러면 수백만명이 동시에 써도 괜찮을까를 물어보자.
감사합니다.

More Related Content

What's hot

백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
NAVER D2
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교
Woo Yeong Choi
 

What's hot (20)

NoSQL 위에서 MMORPG 개발하기
NoSQL 위에서 MMORPG 개발하기NoSQL 위에서 MMORPG 개발하기
NoSQL 위에서 MMORPG 개발하기
 
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
 
로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법
 
Little Big Data #1. 바닥부터 시작하는 데이터 인프라
Little Big Data #1. 바닥부터 시작하는 데이터 인프라Little Big Data #1. 바닥부터 시작하는 데이터 인프라
Little Big Data #1. 바닥부터 시작하는 데이터 인프라
 
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
 
Spark 의 핵심은 무엇인가? RDD! (RDD paper review)
Spark 의 핵심은 무엇인가? RDD! (RDD paper review)Spark 의 핵심은 무엇인가? RDD! (RDD paper review)
Spark 의 핵심은 무엇인가? RDD! (RDD paper review)
 
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
 
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
 
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
 
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
 
[DevGround] 린하게 구축하는 스타트업 데이터파이프라인
[DevGround] 린하게 구축하는 스타트업 데이터파이프라인[DevGround] 린하게 구축하는 스타트업 데이터파이프라인
[DevGround] 린하게 구축하는 스타트업 데이터파이프라인
 
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
 
Ndc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCNdc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABC
 
[NDC 2018] Spark, Flintrock, Airflow 로 구현하는 탄력적이고 유연한 데이터 분산처리 자동화 인프라 구축
[NDC 2018] Spark, Flintrock, Airflow 로 구현하는 탄력적이고 유연한 데이터 분산처리 자동화 인프라 구축[NDC 2018] Spark, Flintrock, Airflow 로 구현하는 탄력적이고 유연한 데이터 분산처리 자동화 인프라 구축
[NDC 2018] Spark, Flintrock, Airflow 로 구현하는 탄력적이고 유연한 데이터 분산처리 자동화 인프라 구축
 
Redis
RedisRedis
Redis
 
Log design
Log designLog design
Log design
 
Twitter의 snowflake 소개 및 활용
Twitter의 snowflake 소개 및 활용Twitter의 snowflake 소개 및 활용
Twitter의 snowflake 소개 및 활용
 

Similar to How to build massive service for advance

홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
devCAT Studio, NEXON
 
임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012
devCAT Studio, NEXON
 
임태현, 서버점검 제로에의 도전, NDC2011
임태현, 서버점검 제로에의 도전, NDC2011임태현, 서버점검 제로에의 도전, NDC2011
임태현, 서버점검 제로에의 도전, NDC2011
devCAT Studio, NEXON
 

Similar to How to build massive service for advance (20)

홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
 
동시성 프로그래밍 기초 in GO
동시성 프로그래밍 기초 in GO 동시성 프로그래밍 기초 in GO
동시성 프로그래밍 기초 in GO
 
Internet Scale Service Arichitecture
Internet Scale Service ArichitectureInternet Scale Service Arichitecture
Internet Scale Service Arichitecture
 
멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면
 
MSA와 infra
MSA와 infraMSA와 infra
MSA와 infra
 
중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직
 
[PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System [PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System
 
[PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System [PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System
 
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
 
게임 분산 서버 구조
게임 분산 서버 구조게임 분산 서버 구조
게임 분산 서버 구조
 
KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론KGC 2014: 분산 게임 서버 구조론
KGC 2014: 분산 게임 서버 구조론
 
임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012임태현, MMO 서버 개발 포스트 모템, NDC2012
임태현, MMO 서버 개발 포스트 모템, NDC2012
 
분산저장시스템 개발에 대한 12가지 이야기
분산저장시스템 개발에 대한 12가지 이야기분산저장시스템 개발에 대한 12가지 이야기
분산저장시스템 개발에 대한 12가지 이야기
 
Spark machine learning & deep learning
Spark machine learning & deep learningSpark machine learning & deep learning
Spark machine learning & deep learning
 
임태현, 서버점검 제로에의 도전, NDC2011
임태현, 서버점검 제로에의 도전, NDC2011임태현, 서버점검 제로에의 도전, NDC2011
임태현, 서버점검 제로에의 도전, NDC2011
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
 
[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영
 
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
[2A1]Line은 어떻게 글로벌 메신저 플랫폼이 되었는가
 
Ndc12 이창희 render_pipeline
Ndc12 이창희 render_pipelineNdc12 이창희 render_pipeline
Ndc12 이창희 render_pipeline
 

More from DaeMyung Kang

More from DaeMyung Kang (20)

Count min sketch
Count min sketchCount min sketch
Count min sketch
 
Ansible
AnsibleAnsible
Ansible
 
Why GUID is needed
Why GUID is neededWhy GUID is needed
Why GUID is needed
 
How to use redis well
How to use redis wellHow to use redis well
How to use redis well
 
The easiest consistent hashing
The easiest consistent hashingThe easiest consistent hashing
The easiest consistent hashing
 
How to name a cache key
How to name a cache keyHow to name a cache key
How to name a cache key
 
Integration between Filebeat and logstash
Integration between Filebeat and logstash Integration between Filebeat and logstash
Integration between Filebeat and logstash
 
How To Become Better Engineer
How To Become Better EngineerHow To Become Better Engineer
How To Become Better Engineer
 
Kafka timestamp offset_final
Kafka timestamp offset_finalKafka timestamp offset_final
Kafka timestamp offset_final
 
Kafka timestamp offset
Kafka timestamp offsetKafka timestamp offset
Kafka timestamp offset
 
Data pipeline and data lake
Data pipeline and data lakeData pipeline and data lake
Data pipeline and data lake
 
Redis acl
Redis aclRedis acl
Redis acl
 
Coffee store
Coffee storeCoffee store
Coffee store
 
Number system
Number systemNumber system
Number system
 
Bloomfilter
BloomfilterBloomfilter
Bloomfilter
 
Redis From 2.8 to 4.x(unstable)
Redis From 2.8 to 4.x(unstable)Redis From 2.8 to 4.x(unstable)
Redis From 2.8 to 4.x(unstable)
 
Redis From 2.8 to 4.x
Redis From 2.8 to 4.xRedis From 2.8 to 4.x
Redis From 2.8 to 4.x
 
Soma search
Soma searchSoma search
Soma search
 
Redis 2017
Redis 2017Redis 2017
Redis 2017
 
Using spark data frame for sql
Using spark data frame for sqlUsing spark data frame for sql
Using spark data frame for sql
 

How to build massive service for advance