SlideShare a Scribd company logo
1 of 161
Download to read offline
신입사원을 위한
웹서비스 확장 전략
강대명 (CHARSYAM@NAVER.COM)
본인 소개
현) 유데미 데이터 엔지니어
구) 카카오 스토리 백엔드 엔지니어
구) 네이버 메일 백엔드 엔지니어
여러 오픈 소스에 컨트리뷰션 중입니다.
주제
웹서비스를 확장하기 위해서 알아야 할 방법들
쉬운 방법
서버를 빵빵하게 넣어둡시다.
다만 버는 것보다 쓰는 게 많으면…
대규모 서비스 개발
노하우의 필요성
2011년 bit.ly
하루에 1억 5백만 클릭
(실제 사람이 한 것만)
대략 초당: 1216 clicks
현재는?
2010년-2011년 Netflix API
1년 사이에 트래픽
20배 증가
20B =
20,000,000,000
2017년 배틀그라운드
6월7일에 대략 20만
9월5일에는 100만
우리는 이런 서비스 트래픽
증가를 버틸 수 있을까?
첫번째 고려 사항
1. 이 정도의 서비스 증가가 일어나면 어떻게 해야할까?
2. 한동안 서비스가 안된다면 어떤 일이 벌어질까?
대규모 서비스의 특성
Elastic
Resiliency
대규모 서비스의 특성
 Elastic
트래픽이나 상황에 따라서 서버의 추가/제거가 쉬워야 한다.
 Resiliency
특정 장비의 장애 등은 자동으로 복구가 되어야 한다.
서버가 복구되는 건 아님
해당 장비의 장애로 인해 다른 쪽이 영향 받지 않아야 함
Scale Up
VS
Scale Out
Scale Up
초당 1000 TPS
초당 3000 TPS
3배 처리 가능한 서버를 투입
Scale Out
초당 1000 TPS
초당 2000 TPS
초당 3000 TPS
SPOF
Single Point Of Failure
여기에 장애가 나면
서비스 전체를 마비시키는
병목지점
SPOF
API Server
DB Server
한대의 물리 서버
SPOF
API Server
DB Server
한대의 물리 서버
SPOF
API Server DB ServerClientClientClient
SPOF
API Server DB ServerClientClientClient
SPOF
API Server DB ServerClientClientClient
SPOF
ClientClientClient
API
Server
API
Server
DB
SPOF
ClientClientClient
API
Server
Master
DB
Slave
DB
Replication
SPOF
ClientClientClient
API
Server
API
Server
API
Server
Master
DB
Slave
DB
Replication
Name Service - DNS
ClientClientClient
API
Server
API
Server
API
Server
Master
DB
Slave
DB
DNS Query Result
Domain IP
www.naver.com 125.209.222.142
202.179.177.21
www.google.com 203.233.96.58
203.233.96.57
203.233.96.56
Name Service - LB
ClientClientClient
API
Server
API
Server
API
Server
L
B
Master
DB
Slave
DB
어디를 확장해야 할까?
API 서버?
DB 서버?
API 서버
 API 서버에만 부하가 몰리는 작업은 어떤 것이 있을까?
파일 IO가 많은, 정적 파일 서빙
웹 스크래핑과 같은 디비 작업 자체보다는 다른 작업이 많은 녀석들
독립적인 작업이 가능한데, CPU나 다른 작업이 많이 필요한
LOL, 배그같은 MO 게임서버
이미지의 영상 인식이나 전처리 이런것도…
DB 서버
 카톡방의 대화는?
 페이스북의 글, 댓글, 친구 관계?
 유투브 등에 올라가는 비디오나 댓글등
 생각보다 우리가 아는 대부분이 여기에 부하를 줌.
Stateless
State
State
Client API #1
User #1
API #2
User #2
User #3
User #4
State
Client API #1
User #1
API #2
User #2
User #3
User #4
1. 5번 유저 추가되면 어디로 가야할까?
State
Client API #1
User #1
API #2
User #2
User #3
User #4
1. 장애가 났을 때 User #3, #4의 데이터는
어디로?
Stateless
Client API Storage
API
API
API 서버는 비즈니스 로직만 가짐
조삼모사?
Client API
StorageAPI
API
크고 안정적인 디비가 필요하게 됨.
Stateless 한 서버의 경우
 장점
추가/삭제가 간단함.
사용하는 쪽에서 주소만 추가하거나 제거하는 걸로 가능
Or 로드밸런서에 추가하거나 제거 하기만 하면 OK
 단점
결국 데이터의 저장이 필요하므로, 뒤에 책임을 떠 넘기는 구조임.
개별 성능은 Stateful 한 경우보다 떨어질 수 있음
그런데 왜 Stateless 인가?
 Stateless 한 서버에 신경을 쓰지말고
 중요한 DB(Storage) 쪽에 집중을 하는게 더 좋다라는 판단.
 두 마리 토끼를 다 쫓지 말고, 한 놈만 팬다.
Shard Nothing
API 서버는 Stateless
그럼 DB는!!!
일반적인 DB 서버의 부하
200 writes/s
800 reads/s
Read > Write
읽기 분배 - Query Off
WEB/AS
Master
Slave
ONLY WRITE
Slave Slave
Only READ
REPLICATION
읽기 분배 - Query Off
200
writes/s
800
reads/s
200
writes/s
400
reads/s
200
writes/s
400
reads/s
Read/1 Server Read/2 Server
Slave 장비를 추가하면
계속 성능이 증가할까?
읽기 분산의 한계
700
writes/s
50
reads/s
700
writes/s
50
reads/s
700
writes/s
50
reads/s
700
writes/s
50
reads/s
700
writes/s
50
reads/s
Write Heavy Situation
Database
Partitioning
Vertical Partitioning
Horizontal Partitioning
Sharding
Horizontal Partitioning
특정 Key 를 어디에
저장할 것인가?
특정 Key 를 저장하는 방법
특정 Key 를 찾는 방법
질문: 어떻게 데이터를 나눠야 할까?
 가정 #1
하나의 서버에는 최대 5개의 데이터만 저장
1, 2, 3, 4, 5, 6 의 데이터가 있을때, 어떻게 데이터를 나눠야
데이터를 잘 저장했다고 할 수 있을까?
질문: 어떻게 데이터를 나눠야 할까?
 가정 #2
7,8 의 데이터가 더 들어왔을때는?
Range
특정 범위대역으로 나누기
Server #1 Server #2 Server #3
User #1 ~ 100 User #101 ~ 200 User #201 ~ 300
Modular
서버 대수로 나누기
Server #1 Server #2
0 % 2 = 0 1 % 2 = 1
2 % 2 = 0 3 % 2 = 1
4 % 2 = 0 5 % 2 = 1
Modular
Modular의 단점 한대가 추가되면?
데이터의 이동이 심해진다.
Server #1 Server #2
0 % 3 = 0 1 % 3 = 1
Server #3
2 % 3 = 2
3 % 3 = 0 4 % 3 = 1 5 % 3 = 2
6 % 3 = 0 7 % 3 = 1 8 % 3 = 2
Modular
두배로 늘리기
1에서는 3으로 절반이, 2에서는 4로 절반이 이동
Server #1 Server #2
0 % 4 = 0 1 % 4 = 1
Server #3 Server #4
2 % 4 = 2 3 % 4 = 3
4 % 4 = 0 5 % 4 = 1 6 % 4 = 2 7 % 4 = 3
8 % 4 = 0 9 % 4 = 1 10 % 4 = 2 1 % 4 = 3
Indexed
특정 데이터의 위치를 가리키는 서버가 존재
Server #1 Server #2 Server #3
User #1
Index
User #1 -> 3
User #100 -> 1
User #102 -> 1
User #100
User #102
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
Consistent Hashing
A
Add A,B,C Server
A
B
Add A,B,C Server
A
B
C
Add A,B,C Server
A
B
C
1
Add Item 1
A
B
C
1
2
Add Item 2
A
B
C
1
2
3
4
5
Add Item 3,4,5
A
B
C
2
3
4
5
Fail!! B Server
A
B
C
1
2
3
4
5
Add Item 1 Again -> Allocated C
Server
A
B
C
1
2
3
4
5
1
Recover B Server -> Add Item 1
C가 죽으면 A 부하가 너무
커지지 않을까요?
A
B
C
1
2
3
4
5
1
예상도
그러나 실제로는?
A
B
C
Real Implementation
A+1
A+2
A+3
B+1
B+2
C+1
C+2
A+
4
C+3
B+3
Consistent Hashing 의 구현 #1
Hash(key) value
Hash(server_1) 100
Hash(server_2) 200
Hash(server_3) 300
동일한 Hash 함수를 사용한다면, 같은 KEY에 대해서 Value가 바뀌는 경우가 있을까?
Consistent Hashing 의 구현 #2
Hash(key) value Server
Hash(Key_1) 50 Server_1
Hash(server_1) 100
Hash(Key_2) 150 Server_2
Hash(server_2) 200
Hash(Key_3) 230 Server_3
Hash(Key_4) 270 Server_3
Hash(server_3) 300
Hash(Key_5) 350 Server_1
해쉬 값이 자기보다 큰거나 같은 서버들 중에서 가장 가까운 서버로 KEY가 할당됨
메일서비스를 한 번 설계해봅시다.
 사용자가 가입하는 경우
 사용자가 메일을 수신하는 경우
 사용자가 메일 리스트를 보는 경우
 사용자가 메일의 상세 내용을 보는 경우
전체 가정
 사용자의 메일 정보는 다음과 같이 각각 분리되어 있다.
사용자의 메일 수신 리스트
각 메일의 실제 파일 내용
 한 계정의 메일 목록 정보는 모두 같은 DB 안에 존재한다.
즉 한 계정의 정보는 분산되지 않는다.
 EML을 저장하는 부분은 AWS S3 같은 서비스를 이용한다고 가정합니다.
여기서 설계나 구조를 현재는 다루지 않습니다.
사용자가 가입하는 경우 #1
 어떤 방식을 고려할 것인가?
Range
Modular
Indexed
사용자가 가입하는 경우 #2
 한국의 사용자는 많아도 5천만명, 계정을 3~4개씩 만든다고 하더라도
 2억개 정도
 메모리가 충분한 DB한대로 충분히 커버가 되는 수준
 계산 방법
이메일 주소 : 256 bytes 그 외 추가 정보로 1개당 1024 bytes 라고 가정
1024 * 2억 = 190기가 정도면 모두 메모리에 저장됨.(디스크에 갈 일도 없음.)
8:2 법칙에 의해서 20% 정도가 빈번하게 액세스 된다고 하면 190 * 0.2 = 38G
64G 정도 메모리 머신이면 aws m4.4xlarge 정도 시간당 $1, 한달에 $720 정도 듬.
장애 대비하면 720 * 2 = $1440 정도로 구성 가능(Index 서버만)
실제로 1k 도 안될 가능성이 크므로 더 작게도 구성이 가능함.
사용자가 가입하는 경우 #3
 사용자의 메일서비스에 가입할 때, 사용자의 메일 리스트를 저장
할 서버는 현재 서비스 중인 서버들 중에서 가장 사용량이 적은 서
버로 선택
사용량이 적은 서버
디스크 사용량, CPU 사용량이 적은 서버
가장 할당된 사용자가 적은 서버) 서버 평균 사용량(100이 한계라고 가정)
A 100
B 90
C 70
D 20
사용자가 가입하는 경우 #4
 User Table Schema
컬럼명 추상타입 비고
user_id Long(64bit) 유니크 고유 아이디(각 DB별)
email String 이메일 주소
shard Long 자신의 메일 리스트를 저장한 서버 번호
type int 활성화 유저인지, 아니면 다른 특징정보
created_at timestamp 계정 생성시간
last_login_time timestamp 최종적으로 로그인한 시간
사용자가 메일을 수신하는 경우 #1
 가정
수신받는 메일 도메인은 하나로 가정한다.(사실 여러 개라도 상관은 없다.)
메일 내용(EML)은 DB가 아닌 다른 곳에 저장된다.
AWS의 S3 같은 것을 생각하자.
메일을 가져가는 방법은, 일단 수신 받은 시간 순으로만 된다고 가정한다.
송신자 순, 메일 제목 순, 이런 건 고려하지 않는다.
사용자가 메일을 수신하는 경우 #2
 Mails Table Schema
컬럼명 추상타입 비고
mail_id Long(64bit) 유니크 고유 아이디(각 DB별)
receiver String or Long 수신자
sender String or Long 송신자
subject String 메일 제목
received_at timestamp 수신 시간
eml_id String or Long 메일 본문 저장 id(or url)
is_read boolean 읽었는지 여부
contents String 보여줄 내용의 일부?(중요하지 않음)
사용자가 메일을 수신하는 경우 #3
송신자
메일 서버
수신자
메일 서버
메일 전송
메일 수신
User
Service
정상 유저 확인
메일 파싱
메일 메타 정보 저장
DB #1 DB #2 DB #3
Eml
Storage
Eml
Storage
Eml
Storage
eml
Storage
메일 본문 정보 저장
이해를 돕기 위한 아주 추상적인 구조입니다.
사용자가 메일을 수신하는 경우 #4
 EML 저장을 위한 서비스가 추가로 필요.
 AWS S3 같은 것을 이용한다고 하더라도
 결국 해당 EML 파일에 대한 key를 무엇을 할 것인지가 중요함.
 EX)
 Unique 한 값을 만들어낼 수 있어야 한다.
{receiver_id}_{mail_id}
Mail_id 자체로는 나눠진 shard 마다 중복이 존재 가능함.
{receiver_id}_{mail_id}는 Unique
사용자가 메일 리스트를 보는 경우
사용자
Mail
Service
목록 요청
목록 전송
User
Service
정상 유저 확인
메일 리스트 요청
select * from mails where receiver=charsyam order by created_at
desc
DB #1 DB #2 DB #3
이해를 돕기 위한 아주 추상적인 구조입니다.
charsyam: 3
charsyam
메일 리스트 전달
사용자가 메일의 상세 내용을 보는 경우
사용자
Mail
Service
이해를 돕기 위한 아주 추상적인 구조입니다.
charsyam_1
메일 요청
eml_id 전달
메일 상세
전달
Eml
Storage
Eml
Storage
Eml
Storage
eml
Storage
메일 EML을 저장하는 KEY
 EML ID를 왜 {receiver}_{mail_id} 로 했을까?
KEY를 만드는 방법은 굉장히 다양할 수 있음.
 좀 더 좋은 KEY를 만들 수 있을까?
질문
 EML ID 필드가 필요할까요?
이미 receiver 와 mail_id가 있으므로 그냥 조합하면 되지 않을까?
 데이터를 다른 서버로 이전해야 하는 경우?
다시 돌아와서!!!
KEY 설계를
어떻게 할 것인가?
키만 보고 어떤 서버에서
찾아야 할지
알 수 있지 않을까?
Unique 해야함
Key만 보고
시간 순을 알 수 있을까?
UUID
 Universally Unique Identifier
 128 bit
 36 characters
 123e4567-e89b-12d3-a456-426655440000
UUID의 단점
 128 bit는 너무 용량이 크다.
보통 Shard ID 가 들어감
Shard ID와
실제 서버의 매핑
시간 정보가 들어가면 ID
만으로 시간 정렬이 가능
뭔가 변화하지 않을 특별
한 정보가 있다면 ID에
들어가 있으면 좋음.
오픈 채팅
단톡방
그룹채팅방
비밀채팅방
필요 정보들
 시간정보(Timestamp)
Timestamp 는 1970년 1/1일 기준, 우리는 2018년 부터 시작해도…
언제까지의 시간 정보가 필요할까?
4byte를 다 쓰면 2106년 2/7일 06:28분 까지 커버됨(32bit)
 채팅방 정보
 Shard 정보
{TIMESTAMP}_{SHARD_ID}_{TYPE}_{SEQUENCE}
KEY의 설계 #1
 Simple 버전
64bit = 8 bytes
기존 userid 를 생성되는 key 와 붙여서 사용하는 방법
6209324585984
Timestamp = 6209324585984 >> 12 =
1515948385
Sequence = 6209324585984 & 0xFFF = 1024
charsyam_ 6209324585984
Timestamp sequence
52 bits 12 bits = 4096
KEY의 설계 #2
Client Service
KEY 전송 User
Service
정상 유저 확인
KEY 파싱
DB #1 DB #2 DB #3
이해를 돕기 위한 아주 추상적인 구조입니다.
charsyam_6209324585984 charsyam
Shard : 3
KEY 6209324585984 요청
각 유저의 데이터는 각 유저가 지정된 Shard
이외에는 저장될 수 없다.
데이터는 서로 다른 서버
로 나눠질 수 있다면?
KEY의 설계 #3
 약간 복잡해진 버전
64bit = 8 bytes
6209324585984
Timestamp = 6209324585984 >> 20 =
1515948385
Shard Id = (6209324585984 & 0xFFF000) >>
12 = 2048
Sequence = 6209324585984 & 0xFFF = 1024
Timestamp Shard ID sequence
40 bits 12 bits = 4096 12 bits = 4096
KEY의 설계 #4
Client Service
KEY 전송
KEY 파싱
DB #1 DB #2 DB #3
이해를 돕기 위한 아주 추상적인 구조입니다.
6209324585984
KEY 6209324585984 요청
6209324585984 = Shard ID 2048
Shard Server
……. ……
…… DB #1
2048 DB #2
…… DB #3
…… ……
Check Shard Map
IDC 가 다르다면?
Twitter의 ID
Instagram 의 ID
MongoDB 의 ID
Service Discovery
Client Side VS Server Side
Client Side
ClientClient예약
Server
결제
Server
결제
Server
결제
Server
예약 서버가 결제 서버를 호출한다고 하면?
1
2
3
Server Side
ClientClient예약
Server
결제
Server
결제
Server
결제
Server
예약 서버가 결제 서버를 호출한다고 하면?
Proxy
LB
서버들의 목록은
어디서 가져올까?
서버의 추가
서버의 삭제(장애)
질문
 어떤 서비스가 정상인지 알아보는 HealthChecker를 만든다고
가정합니다.
 http://api.bob.com/health 를 호출해서 체크한다고 하면,
HealthChecker가 정상이라는 건 어떻게 보장할 수 있을까요?
간단한 방법?
HealthChecker를 체크하는 HealthChecker를 두자? 언제까지?
API 서버
Health
Checker #1
Health
Checker #2
……
Health
Checker #N
질문
ClientClient예약
Server
결제
Server
결제
Server
결제
Server
결제 서버가 추가/삭제 될때 LB를 쓸 수 없다면 어떻게 해야 할까?
결제
Server
Coordinator
Zookeeper
Etcd
Consul
Eureka
Zookeeper Data Model
그냥
디렉토리
Zookeeper 의 특징
 절대로 죽지않는다.(거짓말)
잘 안죽는다.(몇대 죽어도 상관은 없다.)
그러나 다 죽을때도 종종 있음.
 임시 노드의 경우, Health Check를 통해서 자동적으로 접속된 노
드가 사라지면 데이터가 사라진다.(30초가 기본…)
Cluster Membership
 노드의 순서를 보장해준다.
Leader Election
Leader Election
Cluster Membership
Zookeeper
Ephemeral Node
서버와의 연결이 끊어지면
노드 정보도 사라짐
질문 #1을 다시 살펴보자 : HealthCheck
그냥 API 서버를 체크하는 HealthCheck를 여러 대 두자.
API 서버
Health
Checker #1
Health
Checker #2
Health
Checker #3
질문 #1을 다시 살펴보자 : HealthCheck
장애가 나면 장애 알람이 몇 개나 가게 될까?
API 서버
Health
Checker #1
Health
Checker #2
Health
Checker #3
여러 대 가 있지만,
한 대만 동작하면 좋겠어…
질문 #1을 다시 살펴보자 : HealthCheck
Leader 만 동작
API 서버
Health
Checker #1
Health
Checker #2
Health
Checker #3
Leader
Leader Election
여러 대의 서버 중에서
한대만 그 일을
하게 하고 싶을 때
(or 분산 Lock)
Leader Election
클라이언트들 간의 약속으로 정해둠.
질문 #2을 다시 살펴보자 #1
ClientClient예약
Server
결제
Server
결제
Server
결제
Server
서버목록 정보를 바꿔서 재배포 하는 방법
결제
Server
그러면 사람 손이 들어갑니다.
Cluster Membership
 Cases
API Server 가 추가/변경 되었다.
Database Master 장비가 추가/변경되었다.
Cache 장비가 추가/변경 되었다.
 우리의 대응은?
목록을 추가하고, 배포해야 합니다.
목록만 추가하면 알아서 동작합니다.
장비만 추가하면 알아서 동작합니다.
해당 노드의 Child 정보만
읽어와서 접속하면
목록 관리 가능
Zookeeper Event Notification #1
zookeeper
예약 서버
예약 서버
예약 서버결제 서버
결제 서버
/znode/payment/
znode_0000001
znode_0000002
서버 시작시
/znode/payment/
에 임시 노드 등록
Zookeeper Event Notification #1
zookeeper
특정 znode 변경
서버 추가/삭제/변경
예약 서버
예약 서버
예약 서버결제 서버 #1
결제 서버 #2
/znode/payment/
znode_0000001
znode_0000002
결제 서버 #2
znode_0000003
특정 node 변경 이벤트
/znode/payment/
를 다시 읽어서 서버로
접속
용어
 Release/Deploy/Delivery
새로운 기능을 출시/배포 하는 것을 의미
 Rollback
새로운 기능 배포에 문제가 있을 때, 이전 버전으로 되돌리는 것을 의미
질문
 새로운 기능을 배포했는데, 문제가 발생했습니다.
해당 증상을 제거할 수 있는 방법에는 어떤 것들이 있을까요?
Ex) 버그 수정 후 재 배포, 롤백
질문
 만약에 한번 배포할 때 마다 몇 시간씩 걸린다면?
Feature Flag(Feature Toggle)
기능 Feature를 동적으로 끄고 켤 수 있는 방식
Ex)
카카오톡 대화방의 눈은 어떤 조건으로 내리기 시작할까?
이런 기능을 제공하기 위해서 준비해야 하는 것은?
그러나
훨씬 중요한 것들
좋은 엔지니어가 되기 위해서
동료들에게 올바른 질문하기
 질문을 하기 위해서…
 문제의 증상을 정리
 어떤 오류가 나오는지
 자신이 정말 알고자 하는 것…
 자신이 시도한 방법…
올바른 답변 적용하기
 알려준 방법으로 문제가 해결된다면
 문제의 근본적인 원인은 무엇인가?
 알려준 해결책은 어디에 적용되는가?
 옵션을 추가하세요.
 그 옵션을 알고만 끝날 것인가?
 그 옵션이 어떻게 동작하는지를 완전히 이해하고 유사한 문제를 해
결 할 수 있을것인가?
자동화(Automation)
 사람의 손으로 반복해야 하는 부분들…
 로그에서 특정 키워드 검색
 특정 키워드 변환등
 세번 이상 하게 되면, 자동화
문서화와 공유
 내가 문제를 해결한 것만으로는 모든 것이 해결될까?
 내가 해결한 방법으로 팀의 누구나 해결할 수 있다면?
나는 이제 이 문제를 던지고 새로운 재미난 문제로…
 문서화
원인/증상/해결책(Opertaion)
 그리고 공유
발표 및 문서 위치 공유
항상 호기심을 가지세요.
Thank you.

More Related Content

What's hot

[236] 카카오의데이터파이프라인 윤도영
[236] 카카오의데이터파이프라인 윤도영[236] 카카오의데이터파이프라인 윤도영
[236] 카카오의데이터파이프라인 윤도영NAVER D2
 
Data Engineering 101
Data Engineering 101Data Engineering 101
Data Engineering 101DaeMyung Kang
 
인공지능추천시스템 airs개발기_모델링과시스템
인공지능추천시스템 airs개발기_모델링과시스템인공지능추천시스템 airs개발기_모델링과시스템
인공지능추천시스템 airs개발기_모델링과시스템NAVER D2
 
[수정본] 우아한 객체지향
[수정본] 우아한 객체지향[수정본] 우아한 객체지향
[수정본] 우아한 객체지향Young-Ho Cho
 
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
 
BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편
BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편
BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편Seongyun Byeon
 
How To Become Better Engineer
How To Become Better EngineerHow To Become Better Engineer
How To Become Better EngineerDaeMyung Kang
 
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지Changje Jeong
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
 
대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐
대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐
대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐Terry Cho
 
성장을 좋아하는 사람이, 성장하고 싶은 사람에게
성장을 좋아하는 사람이, 성장하고 싶은 사람에게성장을 좋아하는 사람이, 성장하고 싶은 사람에게
성장을 좋아하는 사람이, 성장하고 싶은 사람에게Seongyun Byeon
 
프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)
프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)
프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)Amazon Web Services Korea
 
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기AWSKRUG - AWS한국사용자모임
 
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들Chris Ohk
 
Little Big Data #1. 바닥부터 시작하는 데이터 인프라
Little Big Data #1. 바닥부터 시작하는 데이터 인프라Little Big Data #1. 바닥부터 시작하는 데이터 인프라
Little Big Data #1. 바닥부터 시작하는 데이터 인프라Seongyun Byeon
 
서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해중선 곽
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
 
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈Amazon Web Services Korea
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리Junyi Song
 

What's hot (20)

[236] 카카오의데이터파이프라인 윤도영
[236] 카카오의데이터파이프라인 윤도영[236] 카카오의데이터파이프라인 윤도영
[236] 카카오의데이터파이프라인 윤도영
 
Data Engineering 101
Data Engineering 101Data Engineering 101
Data Engineering 101
 
인공지능추천시스템 airs개발기_모델링과시스템
인공지능추천시스템 airs개발기_모델링과시스템인공지능추천시스템 airs개발기_모델링과시스템
인공지능추천시스템 airs개발기_모델링과시스템
 
Redis
RedisRedis
Redis
 
[수정본] 우아한 객체지향
[수정본] 우아한 객체지향[수정본] 우아한 객체지향
[수정본] 우아한 객체지향
 
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)
 
BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편
BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편
BigQuery의 모든 것(기획자, 마케터, 신입 데이터 분석가를 위한) 입문편
 
How To Become Better Engineer
How To Become Better EngineerHow To Become Better Engineer
How To Become Better Engineer
 
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
 
대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐
대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐
대용량 분산 아키텍쳐 설계 #3 대용량 분산 시스템 아키텍쳐
 
성장을 좋아하는 사람이, 성장하고 싶은 사람에게
성장을 좋아하는 사람이, 성장하고 싶은 사람에게성장을 좋아하는 사람이, 성장하고 싶은 사람에게
성장을 좋아하는 사람이, 성장하고 싶은 사람에게
 
프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)
프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)
프론트엔드 개발자를 위한 서버리스 - 윤석찬 (AWS 테크에반젤리스트)
 
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
Spark + S3 + R3를 이용한 데이터 분석 시스템 만들기
 
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들
 
Little Big Data #1. 바닥부터 시작하는 데이터 인프라
Little Big Data #1. 바닥부터 시작하는 데이터 인프라Little Big Data #1. 바닥부터 시작하는 데이터 인프라
Little Big Data #1. 바닥부터 시작하는 데이터 인프라
 
서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
 
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
 
elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리elasticsearch_적용 및 활용_정리
elasticsearch_적용 및 활용_정리
 

Similar to webservice scaling for newbie

Webservice cache strategy
Webservice cache strategyWebservice cache strategy
Webservice cache strategyDaeMyung Kang
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드cranbe95
 
Internet Scale Service Arichitecture
Internet Scale Service ArichitectureInternet Scale Service Arichitecture
Internet Scale Service ArichitectureDaeMyung Kang
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019devCAT Studio, NEXON
 
게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...
게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...
게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...Amazon Web Services Korea
 
반복적인 코드 작업 자동화, Codebone으로 손쉽게
반복적인 코드 작업 자동화, Codebone으로 손쉽게반복적인 코드 작업 자동화, Codebone으로 손쉽게
반복적인 코드 작업 자동화, Codebone으로 손쉽게Sungju Jin
 
하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기Mijeong Park
 
버클리Db 를 이용한 게임 서버 제작
버클리Db 를 이용한 게임 서버 제작버클리Db 를 이용한 게임 서버 제작
버클리Db 를 이용한 게임 서버 제작Vong Sik Kong
 
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017Amazon Web Services Korea
 
[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영NAVER D2
 
안정적인 서비스 운영 2014.03
안정적인 서비스 운영   2014.03안정적인 서비스 운영   2014.03
안정적인 서비스 운영 2014.03Changyol BAEK
 
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)Amazon Web Services Korea
 
[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 API
[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 API[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 API
[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 APINAVER Engineering
 
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한국사용자모임
 
[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...
[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...
[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...Amazon Web Services Korea
 
관계형 데이터베이스의 새로운 패러다임 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
 
웹사이트기획 및 관리
웹사이트기획 및 관리웹사이트기획 및 관리
웹사이트기획 및 관리봉조 김
 
빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)
빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)
빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)Amazon Web Services Korea
 
효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...
효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...
효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...Amazon Web Services Korea
 

Similar to webservice scaling for newbie (20)

Elastic webservice
Elastic webserviceElastic webservice
Elastic webservice
 
Webservice cache strategy
Webservice cache strategyWebservice cache strategy
Webservice cache strategy
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
 
Internet Scale Service Arichitecture
Internet Scale Service ArichitectureInternet Scale Service Arichitecture
Internet Scale Service Arichitecture
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
 
게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...
게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...
게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming ...
 
반복적인 코드 작업 자동화, Codebone으로 손쉽게
반복적인 코드 작업 자동화, Codebone으로 손쉽게반복적인 코드 작업 자동화, Codebone으로 손쉽게
반복적인 코드 작업 자동화, Codebone으로 손쉽게
 
하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기
 
버클리Db 를 이용한 게임 서버 제작
버클리Db 를 이용한 게임 서버 제작버클리Db 를 이용한 게임 서버 제작
버클리Db 를 이용한 게임 서버 제작
 
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
 
[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영
 
안정적인 서비스 운영 2014.03
안정적인 서비스 운영   2014.03안정적인 서비스 운영   2014.03
안정적인 서비스 운영 2014.03
 
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
 
[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 API
[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 API[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 API
[16]Obfuscation 101 : 난독화, 프로가드, R8, 트랜스포머 API
 
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 특집
 
[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...
[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...
[Retail & CPG Day 2019] Amazon.com의 무중단, 대용량 DB패턴과 국내사례 (Lotte e-commerce) - ...
 
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
 
웹사이트기획 및 관리
웹사이트기획 및 관리웹사이트기획 및 관리
웹사이트기획 및 관리
 
빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)
빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)
빠르고 안전하게 간편한 AWS로 데이터 마이그레이션 하기::최유정 (AWS 솔루션즈아키텍트)
 
효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...
효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...
효과적인 NoSQL (Elasticahe / DynamoDB) 디자인 및 활용 방안 (최유정 & 최홍식, AWS 솔루션즈 아키텍트) :: ...
 

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
 
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 study
How to studyHow to study
How to study
 

webservice scaling for newbie