1. Introduction to
Scalable System
jaehonglim@gmail.com

2. 들어 가기 전에
지난 수년간의 IT trend 변화 원인은?
Cloud/Open source/NOSQL, ...
C에서 Java를 넘어 각종 script 언어들로
오픈 소스 SW의 수준이 갑자기 좋아져서?
Java들의 Language의 성능이 향상되어?

3. 10년간의 환경 변화
x86 성능 향상 : 지난 10년간 최소 100배
NW속도 100배 증가
소비자용 Platform 공유 : x86의 신뢰성 향상
So What?
단위 performance 최적화 불필요
NW활용에 따른 성능저하/장애가능성 감소
시스템 구축에서 인건비 비중 급증

4. 시스템 SW에 대한 요구 변화
낮은 성능/단일 장비 => Performance,
Reliability : UNIX/C/TUXEDO
높은 성능/저가 다중 장비
=> 개발 용이성, Connectivity :
Linux/Java/Tomcat
가변적 장비 수량 : 오픈소스는 무료라서가
아니라 Site License와 같이 장비 변동에
독립적이기 때문에 선택되는 것임

5. Myth?
서비스의 기능을 보고 최적화된 architecture를
구성해야 한다.
사용자 수, 또는 예측 사용량을 기준으로 Infra
필요 규모를 추측할 수 있다.
성능이 부족할 경우 문제 있는 부분의 장비를
늘리면 된다.

6. Fact!
시스템 Architecture는 기능별 사용량에 가장
크게 영향을 받는데, 서비스가 본격화 되기
전의 예상은 보통 큰 의미가 없다.
사용량을 안다고 해도 신뢰할만한 Infra 소요
예측을 하는 것은 불가능할 뿐만 아니라
사용량이라는 것에 대해 제대로 정의가 되는
경우도 없다.
서비스 용량한계는 bottleneck에 의해
결정되는데 우선 순위가 있을 뿐 끝은 없다.

7. What is Scalability?
Scalability
대량의 처리를 할 수 있는 능력
또는 처리용량의 증설이 요구 될 때 대응할
수 있는 능력

8. 관련이 있는 다른 단어들
Performance : 단위 작업에 대한 처리 속도
Latency : 처리지연시간. 통상 Latency가 낮은
것을 Performance가 높다고 함
Throughput : 단위 시간내 처리 할 수 있는
업무량. 개별 처리의 Latency를 낮추거나
동시에 처리할 수 있는 개수를 늘리면 증가함.
시스템 구성시 이야기되는 “용량”이 이것임

9. Scalability의 중요성
시스템에서 결국 필요한 것은 Throughput
Scalability란 요구되는 Throughput이 증가할
때 대응할 수 있는 능력
따라서 요구 Throughput의 가변성이 높은
웹서비스들에서는 Scalability가 매우 중요함
필요없는 경우도 있다.

10. 제일 쉬운 방법
- Scale up
더 크고 빠른 장비로 교체하는 것
할수만 있다면 무조건 이것을 선택하라.
장점 : 구축이 쉬우며 관리도 용이하다.
단점 : 단계적 증가가 어렵고 비싸며 이것으로
해결되지 않는 경우가 더 많다.

11. Scalable 그 자체
- Scale out
더 많은 장비를 추가하는 것
어려운 선택
장점 : 점진적인 증가가 가능하다. 보통 scale
up보다는 싸다.
단점 : 설계, 구축 모두 어려우며 관리도 어렵다.

12. Scale out 하기
- Partitioning
장비를 늘려서 해결하는 것이니 전체 시스템을
조각 내어야 함
자르는 방법으로 Horizontal Partitioning과
Vertical Partitioning이 있음
각각 똑같은 역할의 개수 늘리기, 역할을
나누어서 개수 늘리기임.

13. Horizontal Partitioning
같은 역할을 하는 장비의 수량을 늘리는 것
Scalability는 이것이 가능하냐의 여부라고 볼
수 있음.
통상 Scale out은 이것을 의미함.
예) L4 sw + Web server, Oracle RAC, Hadoop
system

14. Vertical Partitioning
단일 서비스 내에서 기능별로 장비를 분화하는
것
시스템의 변경이 발생하므로 증설을 위해
이것을 시도하는 것은 Scale out이 아님
Horizontal Partitioning이 효율적으로 가능할 수
있도록 기능별로 분화시키는 설계 작업
예) Web/WAS/DB구조, image서버 분리,
용도별 DB분리

15. 이야기 순서
Horizontal Partitioning에 대한 이야기
Vertical Partitioning에 대한 이야기
Database를 Scalable하게 구성 하려면?

16. Horizontal Partitioning
장비 수량을 늘려서 Throughput을 늘리는 방법,
또는 그 구조
당연히 개별 처리건의 최소 Latency를 낮추는
데는 기여를 .
보통 coordinator가 필요하며 이들이 성능
저하나 장애의 원인이 된다.
통상 대외용 Virtual Address가 제공된다.

17. Mediator Pattern
개별 노드가 완전히 동일한 경우가 Load
Balancer(예. L4 switch for Web server)
Load외에 요청의 내용에 따라 처리 장비간
업무 배분을 하는 경우도 있다.
(예. Global Server Load Balancing, NDDS의
사용자별 QOS레벨 관리,HDFS Name Node)
요청을 직접 relay하는 방법외에 요청자에게
사용할 노드를 안내하는 방식도 있다.

18. Virtual Address
외부와 독립적으로 Horizontal scale out이
가능하게 하는 요소
Virtual IP, DNS기반 URL, Partitioned
Table에서의 Table Name

19. Shared Nothing?
Shared Everything?
Shared Nothing vs. Shared Everything
Web servers vs. Session Clustered Web
Servers vs. Oracle RAC
Sharing something : Lock, Sync
HA에 의한 공유 요소 : Server-side Session

20. Cases
L4 switch
IBM SAN Volume Controller
HDFS Name Node vs. Memcached
Oracle Real Application Server
Portal site의 이미지/광고서버 분산 방식
Global Server Load Balancing
NDDS의 요청 별 QOS분리
Database Table Partitioning

21. Vertical Partitioning
기능 요소별로 Resource의 필요량이나 종류가
다른 것을 구분 하는 것
통신 구간이 생길 수 있으므로 Latency 증가와
함께 장애가능성이 폭증할 수 있음
분화된 기능들끼리의 연동 방식이 부적절할
경우 장비 추가의 효과가 없을 수 있음

22. 도구들
Platform으로부터의 자유 : Human Readable
Text over HTTP(XML,JSON등)
비동기 처리를 통한 성능 향상 : Messaging
System, File 송수신을 통한 Batch처리
Data신뢰도와 성능을 맞바꾸기 : Cache

23. Messaging System
Synchronous 연동의 단점
Message Oriented Architecture/Middleware
JMS, AMQP, XMPP, ActiveMQ

24. Cache
“읽기” 성능 향상을 위한 요소
Read의 비율이 압도적인 웹 서비스의 특성 상
Data의 불일치를 약간만 허용해도 크게 성능을
높일 수 있다는 것을 활용한 것
File Cache : L7 Web Cache, CDN
Data Cache : Key-Value기반 Memory
Cache( MemcacheD, EHCache등)

25. Database
거의 모든 시스템들의 bottleneck
Scalable하게 만들기 가장 어려운 IT 요소
가장 중요하다고들 하는 시스템
법률 규제가 가장 많은 시스템
...

26. RDBMS란?
Relational Database Management System
Oracle Database를 부르는 또다른 이름
메인프레임 시절에 처음 만들어진 물건
UNIX로의 downsizing을 성공하게 한 주역
Cloud/오픈소스의 물결에 흘러가는 SW

27. Data의 종류들
NXMile/Gifticon/NDDS에서의 Data들 성향을
나누어 보기
Data별로 요구되는 Data Storage - DB의
requirement는?
“Oracle RAC를 써야만 할 것 같은 Data” vs.
“DB를 안써도 될 지 모르는 Data”

28. DBMS 다시 생각해보기
DBMS란?
읽기 Schema vs. 쓰기 Schema
DB에서 Column의 용도는 무엇인가?
오픈 소스 DB의 신뢰성은? In-house sw의
품질과 같이 고려해본 오픈소스 SW

29. Database Partitioning
- Vertical
모든 Data가 똑같이 관리될 필요는 없다.

30. Database Partitioning
- Horizontal
같은 종류의 Data라도 꼭 같이 있어야 하는
것은 아니다.

31. 용어 정리
Big Data
Hadoop/MongoDB/Cassandra/HBase/Hive...
NOSQL
Open source Database
Distributed Database
In-Memory Database
...

32. Thank you