Cloud Taekwon 2015 - 비트패킹컴퍼니 사례 공유

정민영

CTOTHE BEATPACKING COMPANY

BEAT 소개

국내최초무료라디오서비스

숫자

2014. 4월비트라디오출시

2014. 4월비트라디오출시3~400% 성장/월

2014. 4월비트라디오출시2~300% 성장/월한달에 100만+씩성장중

30만+명/일 5분이상청취

30만+명/일 5분이상청취35만+시간/일

30만+명/일 5분이상청취35만+시간/일9백만+곡재생/일

30만+명/일 5분이상청취35만+시간/일9백만+곡재생/일5백만+곡정산/일

폭주성장에대처하는스타트업의자세

부제: 최대한사람이필요없는인프라만들기

부제: 최대한사람이필요없는인프라만들기그리고, 최대한저렴하게버텨보기

어떻게하면인프라를

어떻게하면인프라를안정적으로

어떻게하면인프라를안정적으로유연하면서도

어떻게하면인프라를안정적으로유연하면서도개발자를아껴가며(!)

어떻게하면인프라를안정적으로유연하면서도개발자를아껴가며(!)

돈도절약할까?

Elastic Compute Cloud

서버에대한기존의관점

PEAK

서버에대한 21세기클라우드의관점

3번강조해도부족한 AutoScale

Instance Hour

= 인스턴스사용시간= 과금단위

c3.xlarge * 4대 * 61분= 2 Instance Hour * 4

= 8 Instance Hour

= 2.04 USD / Hour

28만원/일 VS 12만원/일

Peak를처리하기위해 40대가필요하다면,

= 40 Instance Hour * 24

= 960 Instance Hour / Day

= 244.8 USD / Hour

Peak를처리하기위해 40대가필요하다면,

= 40 Instance Hour * 9

+ 5 Instance Hour * 15

= 435 Instance Hour / Day

= 110.925 USD / Hour

아무리잘나가는서비스도,

항상 PEAK일수는없는법

원하는조건에맞춰서(Policy)

원하는조건에맞춰서(Policy)

지정한설정값으로(Launch Configuration)

원하는조건에맞춰서(Policy)

지정한설정값으로(Launch Configuration)

인스턴스를자동으로생성/삭제

SPOT Instance

SPOT Instance

AWS의여유자원을경매를통해이용

0 0.05 0.1 0.15 0.2 0.25 0.3

On Demand

Reserved 1yr

Spot

C3.xlarge 가격비교

USD

SPOT Instance

단, 인스턴스생명주기를통제할수없음= 언제든빼앗길수있음

6:00 9:00 12:00 15:00 18:00 21:00 0:00

On-Demand Spot Load

Spot : 5분간평균 CPU이용률 40%

OD : 5분간평균 CPU이용률 60%

6:00 9:00 12:00 15:00 18:00 21:00 0:00

On-Demand Spot Load

Spot 확보에실패한경우On-Demand가 Scale-Up

Spot 확보에따른On-Demand Scale-Down

DynamoDB

처리량만결정하면알아서Scale 하는 NoSQL DB

처리량= 필요한초당읽기 (/4kb)

= 필요한초당쓰기 (/1kb)

평균 2kb인항목을 100번쓰고읽는다면= 100(Read) * 1 = 100

= 100(Write) * 2 = 200

요청수와크기에따라서자동으로 Scale

요청수와크기에따라서자동으로 Scale

= 데이터크기와트래픽증가에유연한 DB

두가지종류의인덱스지원

Local Secondary Index

= Alternate Range Key

= 특정 Hash Key의결과를필터링= 특정 Hash Key에서다른정렬

Global Secondary Index

= Alternate Key

= 테이블의 Hash Key와무관= 별도의읽기&쓰기처리량요구

다양한데이터타입지원

다양한데이터타입지원= String, Number, Binary

= String Set, Number Set, Binary Set

= JSON – Bool, Null, List, Map

고도화된 API 지원

고도화된 API 지원= 수정&조건표현식= Atomic

= Batch

파티션당 Read

= 5000/3 = 1666.67

파티션당 Write

= 500/3 = 166.67

Hash Key 에의해파티션이결정= Hash Key 선정이매우중요= 잘분산되는키를선택하는게중요

AGAIN,

아무리잘나가는서비스도,

항상 PEAK일수는없는법.

DB도유연할수없을까?

부하에따른좀더능동적인처리량조정

dynamo-autoscale

UpdateTable

= 읽기/쓰기처리요구량실시간조정= 올리는건하루에몇번이고가능= 내리는건 4회/24시간제하

RECAP

= API, API, API

= 부하수준에맞춰유연하게사용= AWS의다양한가격정책을적극활용

AWS 한국사용자모임

http://awskr.org

http://jobs.beatpacking.com

감사합니다.