SlideShare a Scribd company logo
1 of 146
Download to read offline
대규모 서비스를 지탱하는 기술
- 기초편
강대명(charsyam@naver.com)
발표자 소개
● Data Engineer at Udemy(현)
● Software Engineer at Kakao(카카오 스토리)
● Software Engineer at Naver(네이버 메일)
● Software Engineer at Finaldata
배틀그라운드
Facebook
이런 서비스는
어떻게 만들어야 할까요?
서버 한대로 가능할까요?
질문
이런 서비스를 운영하기
위해서 몇 대의 서버가
필요할까요?
막 시작하는 초기 스타트업의 구조
DBMS
API ServerWeb Browser
Mobile Apps
용어 설명
● API Server
○ 실제적인 로직을 처리하는 서버, 회원 가입
● DBMS(DataBase Management System)
○ 실제 데이터가 저장되는 곳
○ Mysql, Postgresql, Oracle 등등
처음에는 한대로!!!
● 처음에는 한대로 시작합니다.
○ 왜?
■ 돈이 없습니다.
■ 사용자도 없습니다.
질문
그런데 서버가 한대인데…
서버가 고장나면?
물리 서버가 장애
DBMS
API ServerWeb Browser
Mobile Apps
Web Server 가 장애
DBMS
API ServerWeb Browser
Mobile Apps
DBMS 가 장애...
DBMS
API ServerWeb Browser
Mobile Apps
이럴 때는 어떻게?
두 대를 둡니다.
DBMS
API Server
Web Browser
Mobile Apps
DBMS
API Server
한 대가 죽더라도... 서비스가...
DBMS
API Server
Web Browser
Mobile Apps
DBMS
API Server
잘 될까요?
두 대일 때의 문제점!!!
User의 친구 목록을 가져
온다고 합시다.
두 대 일때의 문제점!!!
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
Friends
User #2
Friends
User #3
Friends
User #1은 어디로 가야하나요?
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
User #1
Friends
User #2
Friends
User #3
Friends
API Server 1로 가면?
- 찾을 수 있습니다.
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
User #1
Friends
User #2
Friends
User #3
Friends
API Server 2로 가면
- 못찾습니다.
DBMS 1
API Server 1
Web Browser
Mobile Apps
DBMS 2
API Server 2
User #1
User #1
Friends
User #2
Friends
User #3
Friends
데이터가 분리되어 있으면
찾기 어렵습니다.
그래서 DB는 따로 분리해서
하나만 바라봅니다.
DB가 하나면…
어디로 가든 데이터를
찾을 수 있습니다.
Web Browser
Mobile Apps
User #1
API Server 1
API Server 2
DBMS
User #1
User #1
Friends
User #2
Friends
User #3
Friends
장애가 나도 다른 서버가 서비스가 가능합니다.
Web Browser
Mobile Apps
User #1
API Server 1
API Server 2
DBMS
User #1
User #1
Friends
User #2
Friends
User #3
Friends
장애가 나도 다른 서버가 서비스가 가능합니다.
Web Browser
Mobile Apps
User #1
API Server 1
API Server 2
DBMS
User #1
User #1
Friends
User #2
Friends
User #3
Friends
잘 될까요?
그런데 우리는 어떻게
API Server 1,2 가 있다는
것을 알고 찾을 수 있을까
요?
가설 1 : 사용자가 우리 서버의 주소와 상태를 항상 알
고 있다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
지금 서비스 서버는 2대고 주소는
API Server 1 과 API Server 2
모두 정상이야!!!
가능할까요?
서버가 추가되거나?
주소가 바뀌면?
가설 2 : 사용자는 대표 주소 하나만 알고 우리가 알아
서 나눠준다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
DNS
● Domain Name Service
○ 실제로 인터넷 주소는 IP라는 여러 숫자의 조합으로 이루어져 있습
니다.
■ Udemy.com -> 104.18.134.108
● (이건 IPv4, 더 많은 주소를 위한 IPv6도 있습니다.)
DNS
> nslookup udemy.com
Server: 1.214.68.2
Address: 1.214.68.2#53
Non-authoritative answer:
Name: udemy.com
Address: 104.18.134.108
Name: udemy.com
Address: 104.18.133.108
Name: udemy.com
Address: 104.18.130.108
Name: udemy.com
Address: 104.18.132.108
Name: udemy.com
Address: 104.18.131.108
DNS를 이용하면?
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
API Server 1
Response
API Server 1
is 1.1.1.3
DNS
● apiserver.com 이라는 주소에
○ 1.1.1.3
○ 1.1.1.4를 할당합니다.
DNS를 이용하면 apiserver.com 을 접속하면 두 서버
중에 하나로 접속이 가능합니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.3 and 1.1.1.4
잘 될까요?
친구 목록을 여러번 호출한다고 합시다. 그 때마다 DNS
를 호출한다면?
getFriends()
API Server 1
1.1.1.3
DNS
Request: apiserver.com
Response: 1.1.1.3
getFriends()
Request: apiserver.com
Response: 1.1.1.3
DNS 는
TTL(Time to Live) 라는
일종의 캐시를 가지고 있
습니다.
DNS TTL
● Facebook 을 하루에 12억명이 사용합니다. 매번 기능을 호출 할 때 마다
DNS를 호출한다면, DNS 서버는 얼마나 커야 할까요?
이미 apiserver.com 은 1.1.1.3이라는 걸 알고 있으므로
30초간 그냥 1.1.1.3을 사용한다.
getFriends()
API Server 1
1.1.1.3
DNS
Request: apiserver.com
Response: 1.1.1.3 TTL: 30
getFriends()
이미 알고 있으므로 바로 1.1.1.3
으로 접속
그런데 장애가 나면?
장애가 나도 응답은 여전히 1.1.1.3 과 1.1.1.4 입니다.
1.1.1.4를 받으면 어떻게 될까요?
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.3 and 1.1.1.4
IP 주소가 바뀌면?
이미 apiserver.com 은 1.1.1.3이라는 걸 받았으므로
1.1.1.5로 바뀐걸 TTL 이내에는 알 수 없다.
getFriends()
API Server 1
1.1.1.3
DNS
Request: apiserver.com
Response: 1.1.1.3 TTL: 30
getFriends()
이미 알고 있으므로 바로 1.1.1.3
으로 접속 시도
API Server 1
1.1.1.5
Load Balancer
Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2
REQ #3
Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2
REQ #3
Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2REQ #3
Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.2
REQ #1
REQ #2
REQ #3
Load Balancer가
고장나면 어떻게 되나요?
Load Balancer(LB) 의 동작
Request 를 연결된 서버들에게 나누어 줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.10
Active
REQ #1
REQ #2
REQ #3
LB
1.1.1.11
StandBy
1.1.1.2
LB가 장애가 나면? 해당 LB에게 할당된 IP를 다른 LB
에게 넘겨줍니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
LB
1.1.1.10
Active
REQ #1
REQ #2
REQ #3
LB
1.1.1.11
Active
1.1.1.2
Cloud 서비스 제공자(AWS, GCP, AZURE) 등의 Load
Balancer 는 하나로 보이지만 내부적으로 장애시 위와
같이 동작합니다.
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
DNS
Request
apiserver.com
Response
apiserver is
1.1.1.2
ELB
1.1.1.2
REQ #1
REQ #2
REQ #3
DNS로 돌아가서
이 ip 들은
서버일까요?
LB일까요?
> nslookup udemy.com
Server: 1.214.68.2
Address: 1.214.68.2#53
Non-authoritative answer:
Name: udemy.com
Address: 104.18.134.108
Name: udemy.com
Address: 104.18.133.108
Name: udemy.com
Address: 104.18.130.108
Name: udemy.com
Address: 104.18.132.108
Name: udemy.com
Address: 104.18.131.108
잘 될까요?
Data
그런데 DBMS는 한대인데?
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
그러면 두대로?
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
DBMS
그러면 처음과 같은 문제가
다시 생깁니다.
Data Replication
데이터 복제
Data Replication
● 한 대의 서버의 내용을 지속적으로 다른 서버로 복제해주는 작업
○ Primay(서비스를 하고 있는 DB)의 내용을 자동으로 Secondary(백
업용 DB) 에 데이터를 복제해줍니다.
● 두 대가 같은 내용을 가지므로, 한 대에 문제가 생기더라도 다른 서버로
서비스가 가능합니다.
데이터 복제
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
Primary
DBMS
Secondary
Name Email Password
Name Email Password
DBMS 장애
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
Primary
DBMS
Primary
복구 되면!!!
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
Secondary
DBMS
Primary
Name Email Password
Name Email Password
최소한의 서비스 안전성
을 위한 모습
최소한의 모습
Web Browser
Mobile Apps
API Server 1
1.1.1.3
API Server 2
1.1.1.4
ELB
1.1.1.2
DBMS
Primary
DBMS
Secondary
여기까지가 서비스를 위
한 기본입니다.
대규모 서비스
사용자가 많다.
트래픽이 많다.
데이터가 많다.
Facebook
2.27 billion
MAU
사용자가 많다.
트래픽이 많다.
데이터가 많다.
Netflix
사용자가 많다.
트래픽이 많다.
데이터가 많다.
Data
유저 정보, 친구 목록
글, 사진, 비디오
Facebook
하나의 이미지 사이즈는
얼마일까요?
제 폰에서는 대략 4MB
4MB * 1000 = 4GB
4GB * 1000 = 4TB
백만 장 정도의
사진 저장에
4TB
이런 구조?
Web Browser
Mobile Apps
API Server 1
API Server 2
File Server
4TB
4TB
4TB
어떤 문제가 있을가요?
File Server 가 장애나면?
Web Browser
Mobile Apps
API Server 1
API Server 2
File Server
4TB
4TB
4TB
결국 데이터 복제가
필요합니다.
그러면 몇개의 복제본을 둬야 할까요?
Web Browser
Mobile Apps
API Server 1
API Server 2 File Server
4TB
4TB
4TB
File Server
4TB
4TB
4TB
3개의 복제본
Uptime : 서비스가 기동 중인 시간
가동율 장애 시간(1년 기준)
90% 36일
99% 3.65일
99.5% 1.83일
99.9% 8.76 시간
99.99% 52.56 분
99.999% 5.25 분
99.9999% 31.5 초
Data Loss : 보통 3개의 복제본을 두면 99.999% 보
장
보장율 복제 개수
99.99% 2
99.999% 3
4MB 사진 백만장을
저장하려면?
4TB * 3 = 12TB 가 필요.
저장 공간만 있으면
충분할까요?
각각의 사진 정보가
어느 서버에 있는지도
관리해야 합니다.
Object Storage
클라우드에서는 보통
이런 서비스를 제공해줍
니다.
AWS S3
AZURE Blob
GCP Google Stroage
P2P 기반의 IPFS 라는
프로젝트도 있습니다.
이런 Object 스토리지 서비스는 큰 회사는 자체적으로,
작은 곳에서는 그냥 클라우드껄 쓰는게 이득입니다.
Web Browser
Mobile Apps
API Server 1
API Server 2
Object
Storage
Service
그런데 잘 동작할까요?
이미지나 동영상은 외부에
저장하더라도, 그 정보는
따로 관리할 필요가 있습니다.
예를 들면
데이터의 종류
doc1 doc2
abcdefg1
doc1 이라는 주소를 가진 문서가
abcdefg1 이라는 이미지를 가지고
있다고 합니다.
doc1 이 abcdefg1 이라는
이미지를 가진다는 정보를
관리할 필요가 있습니다.
이런 식으로...
Web Browser
Mobile Apps
API Server 1
API Server 2
DBMS
primary
DBMS
secondary
Object
Storage
Service
abcdefg1
abcdefg2
abcdefg3
abcdefg1
abcdefg2
abcdefg3
doc1
doc2
doc3
그런데 잘 동작할까요?
어느 정도 규모까지는 잘
동작할껍니다.
데이터 팽창의 시
대
Giga : 1000 MB
Tera : 1000 GB
Peta : 1000 TB
Exa : 1000 PB
Zeta : 1000 Exa
Limitation
한계
DBMS 의 한계
DBMS 의 한계
TPS
TPS
Transaction Per Second
초당 몇개의 명령을 처리할 수 있는
가?
TPS
만약 MAX 1000TPS 라면
1초에 1000개의 명령이
처리가 가능합니다.
TPS
CPU 나 메모리, 디스크 속도등에
영향을 받게됩니다.
너무 많은 명령을 처리해야 하
면 아주 오래걸리거나
장비가 고장날 수 있습니다.
Response Time
Facebook 글 하나 보는데
클릭 후 한시간 뒤에 보인다면?
Scale Up
Vs
Scale Out
하드웨어 성능은 좋아지고
가격은 싸지고 있습니다.
(메모리 제외... 그래픽카드 제외)
클라우드 에서는 instance type
을 바꾸는 것도 쉽습니다.
그러면 Scale Up만
적용하면 될까요?
하드웨어 성능에는 한계가
있습니다.
그 한계보다 많은 요청이
들어오면...
위에서 API 서버를 2대 이상
두는 것도 Scale Out 입니다.
데이터의 Scale out
다음 데이터를 두 개로 나누면 어떻게 해야 할까요?
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
2로 나누는게 아니라 3으로 나눠야 하면?
5
1 2 3
4
많은 수의 데이터가
이동을 해야 합니다.
확장에 데이터가 적게
움직이는 방법을
연구해야 합니다.
정리
● 대규모 서비스는 수백만, 수천만명이 사용하는 서비스입니다.
● 대규모 데이터를 다루는 것은 상당히 재미있으면서도, 어려운 일입니다.
● 클라우드(AWS, Azure, GCP) 공부하시면 좋습니다.
Thank you!!!

More Related Content

What's hot

[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
 
MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현YEONG-CHEON YOU
 
Data Engineering 101
Data Engineering 101Data Engineering 101
Data Engineering 101DaeMyung Kang
 
중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직Hoyoung Choi
 
NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현noerror
 
Ndc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCNdc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCHo Gyu Lee
 
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...Amazon Web Services Korea
 
[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기Chanwoong Kim
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019devCAT Studio, NEXON
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교Woo Yeong Choi
 
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
 
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들Chris Ohk
 
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)Brian Hong
 
NDC 11 자이언트 서버의 비밀
NDC 11 자이언트 서버의 비밀NDC 11 자이언트 서버의 비밀
NDC 11 자이언트 서버의 비밀승명 양
 
Windows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCPWindows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCPSeungmo Koo
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
 
임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013devCAT Studio, NEXON
 
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)Heungsub Lee
 
로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법Jeongsang Baek
 
실시간 게임 서버 최적화 전략
실시간 게임 서버 최적화 전략실시간 게임 서버 최적화 전략
실시간 게임 서버 최적화 전략YEONG-CHEON YOU
 

What's hot (20)

[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유
 
MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현MMOG Server-Side 충돌 및 이동처리 설계와 구현
MMOG Server-Side 충돌 및 이동처리 설계와 구현
 
Data Engineering 101
Data Engineering 101Data Engineering 101
Data Engineering 101
 
중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직중앙 서버 없는 게임 로직
중앙 서버 없는 게임 로직
 
NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현NDC12_Lockless게임서버설계와구현
NDC12_Lockless게임서버설계와구현
 
Ndc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCNdc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABC
 
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
 
[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교
 
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
 
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
 
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
 
NDC 11 자이언트 서버의 비밀
NDC 11 자이언트 서버의 비밀NDC 11 자이언트 서버의 비밀
NDC 11 자이언트 서버의 비밀
 
Windows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCPWindows Registered I/O (RIO) vs IOCP
Windows Registered I/O (RIO) vs IOCP
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
 
임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013임태현, 게임 서버 디자인 가이드, NDC2013
임태현, 게임 서버 디자인 가이드, NDC2013
 
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
 
로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법
 
실시간 게임 서버 최적화 전략
실시간 게임 서버 최적화 전략실시간 게임 서버 최적화 전략
실시간 게임 서버 최적화 전략
 

Similar to Massive service basic

Internet Scale Service Arichitecture
Internet Scale Service ArichitectureInternet Scale Service Arichitecture
Internet Scale Service ArichitectureDaeMyung Kang
 
안정적인 서비스 운영 2014.03
안정적인 서비스 운영   2014.03안정적인 서비스 운영   2014.03
안정적인 서비스 운영 2014.03Changyol BAEK
 
build a linux webhosting server
build a linux webhosting serverbuild a linux webhosting server
build a linux webhosting server정현 윤
 
Tdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalabilityTdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalability흥배 최
 
시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015
시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015
시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015Goonoo Kim
 
서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infra서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infraHwanseok Park
 
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유Kyoungchan Lee
 
SK플래닛_README_마이크로서비스 아키텍처로 개발하기
SK플래닛_README_마이크로서비스 아키텍처로 개발하기SK플래닛_README_마이크로서비스 아키텍처로 개발하기
SK플래닛_README_마이크로서비스 아키텍처로 개발하기Lee Ji Eun
 
CoreDot TechSeminar 2018 - Session2 Ji Donghyun
CoreDot TechSeminar 2018 - Session2 Ji DonghyunCoreDot TechSeminar 2018 - Session2 Ji Donghyun
CoreDot TechSeminar 2018 - Session2 Ji DonghyunCore.Today
 
ASP.NET과 C#으로 개발하는 대규모 소셜 게임
ASP.NET과 C#으로 개발하는 대규모 소셜 게임ASP.NET과 C#으로 개발하는 대규모 소셜 게임
ASP.NET과 C#으로 개발하는 대규모 소셜 게임흥배 최
 
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016Amazon Web Services Korea
 
추천서비스고군분투기 On Aws - 박진우 (레코벨)
추천서비스고군분투기 On Aws - 박진우 (레코벨)추천서비스고군분투기 On Aws - 박진우 (레코벨)
추천서비스고군분투기 On Aws - 박진우 (레코벨)AWSKRUG - AWS한국사용자모임
 
Webservice cache strategy
Webservice cache strategyWebservice cache strategy
Webservice cache strategyDaeMyung Kang
 
Rhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_ArchitectureRhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_ArchitectureRhea Strike
 
Java rmi 개발 가이드
Java rmi 개발 가이드Java rmi 개발 가이드
Java rmi 개발 가이드중선 곽
 
AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집
AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집
AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집AWSKRUG - AWS한국사용자모임
 
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017Amazon Web Services Korea
 

Similar to Massive service basic (20)

Internet Scale Service Arichitecture
Internet Scale Service ArichitectureInternet Scale Service Arichitecture
Internet Scale Service Arichitecture
 
Elastic webservice
Elastic webserviceElastic webservice
Elastic webservice
 
안정적인 서비스 운영 2014.03
안정적인 서비스 운영   2014.03안정적인 서비스 운영   2014.03
안정적인 서비스 운영 2014.03
 
build a linux webhosting server
build a linux webhosting serverbuild a linux webhosting server
build a linux webhosting server
 
Tdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalabilityTdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalability
 
시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015
시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015
시간당 수백만 요청을 처리하는 node.js 서버 운영기 - Playnode 2015
 
서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infra서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infra
 
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유
2014.4.30 프라이머 개발자 모임 - 서버 장애 예방 및 대응 방법 공유
 
SK플래닛_README_마이크로서비스 아키텍처로 개발하기
SK플래닛_README_마이크로서비스 아키텍처로 개발하기SK플래닛_README_마이크로서비스 아키텍처로 개발하기
SK플래닛_README_마이크로서비스 아키텍처로 개발하기
 
CoreDot TechSeminar 2018 - Session2 Ji Donghyun
CoreDot TechSeminar 2018 - Session2 Ji DonghyunCoreDot TechSeminar 2018 - Session2 Ji Donghyun
CoreDot TechSeminar 2018 - Session2 Ji Donghyun
 
KGC 2013 DevSisters
KGC 2013 DevSistersKGC 2013 DevSisters
KGC 2013 DevSisters
 
ASP.NET과 C#으로 개발하는 대규모 소셜 게임
ASP.NET과 C#으로 개발하는 대규모 소셜 게임ASP.NET과 C#으로 개발하는 대규모 소셜 게임
ASP.NET과 C#으로 개발하는 대규모 소셜 게임
 
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
 
추천서비스고군분투기 On Aws - 박진우 (레코벨)
추천서비스고군분투기 On Aws - 박진우 (레코벨)추천서비스고군분투기 On Aws - 박진우 (레코벨)
추천서비스고군분투기 On Aws - 박진우 (레코벨)
 
Webservice cache strategy
Webservice cache strategyWebservice cache strategy
Webservice cache strategy
 
Rhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_ArchitectureRhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_Architecture
 
Java rmi 개발 가이드
Java rmi 개발 가이드Java rmi 개발 가이드
Java rmi 개발 가이드
 
AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집
AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집
AWS 서버리스 신규 서비스 총정리 - 트랙2, Community Day 2018 re:Invent 특집
 
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
 
Place site Design
Place site DesignPlace site Design
Place site Design
 

More from DaeMyung Kang

More from DaeMyung Kang (20)

Count min sketch
Count min sketchCount min sketch
Count min sketch
 
Redis
RedisRedis
Redis
 
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
 

Massive service basic