introduction to scalability
TRANSCRIPT
들어 가기 전에
지난 수년간의 IT trend 변화 원인은 ?
Cloud/Open source/NOSQL, ...
C 에서 Java 를 넘어 각종 script 언어들로
오픈 소스 SW 의 수준이 갑자기 좋아져서 ?Java 들의 Language 의 성능이 향상되어 ?
10 년간의 환경 변화x86 성능 향상 : 지난 10 년간 최소 100 배
NW 속도 100 배 증가
소비자용 Platform 공유 : x86 의 신뢰성 향상
So What?
단위 performance 최적화 불필요
NW 활용에 따른 성능저하 / 장애가능성 감소
시스템 구축에서 인건비 비중 급증
시스템 SW 에 대한 요구 변화
낮은 성능 / 단일 장비 => Performance, Reliability : UNIX/C/TUXEDO
높은 성능 / 저가 다중 장비 => 개발 용이성 , Connectivity : Linux/Java/Tomcat
가변적 장비 수량 : 오픈소스는 무료라서가 아니라 Site License 와 같이 장비 변동에 독립적이기 때문에 선택되는 것임
Myth?
서비스의 기능을 보고 최적화된 architecture를 구성해야 한다 .
사용자 수 , 또는 예측 사용량을 기준으로 Infra 필요 규모를 추측할 수 있다 .
성능이 부족할 경우 문제 있는 부분의 장비를 늘리면 된다 .
Fact!
시스템 Architecture 는 기능별 사용량에 가장 크게 영향을 받는데 , 서비스가 본격화 되기 전의 예상은 보통 큰 의미가 없다 .
사용량을 안다고 해도 신뢰할만한 Infra 소요 예측을 하는 것은 불가능할 뿐만 아니라 사용량이라는 것에 대해 제대로 정의가 되는 경우도 없다 .
서비스 용량한계는 bottleneck 에 의해 결정되는데 우선 순위가 있을 뿐 끝은 없다 .
What is Scalability?
Scalability
대량의 처리를 할 수 있는 능력
또는 처리용량의 증설이 요구 될 때 대응할 수 있는 능력
Performance : 단위 작업에 대한 처리 속도
Latency : 처리지연시간 . 통상 Latency 가 낮은 것을 Performance 가 높다고 함
Throughput : 단위 시간내 처리 할 수 있는 업무량 . 개별 처리의 Latency 를 낮추거나 동시에 처리할 수 있는 개수를 늘리면 증가함 .시스템 구성시 이야기되는 “용량”이 이것임
관련이 있는 다른 단어들
Scalability 의 중요성
시스템에서 결국 필요한 것은 Throughput
Scalability 란 요구되는 Throughput 이 증가할 때 대응할 수 있는 능력
따라서 요구 Throughput 의 가변성이 높은 웹서비스들에서는 Scalability 가 매우 중요함
필요없는 경우도 있다 .
제일 쉬운 방법- Scale up
더 크고 빠른 장비로 교체하는 것
할수만 있다면 무조건 이것을 선택하라 .
장점 : 구축이 쉬우며 관리도 용이하다 .
단점 : 단계적 증가가 어렵고 비싸며 이것으로 해결되지 않는 경우가 더 많다 .
Scalable 그 자체- Scale out
더 많은 장비를 추가하는 것
어려운 선택
장점 : 점진적인 증가가 가능하다 . 보통 scale up 보다는 싸다 .
단점 : 설계 , 구축 모두 어려우며 관리도 어렵다 .
Scale out 하기- Partitioning
장비를 늘려서 해결하는 것이니 전체 시스템을 조각 내어야 함
자르는 방법으로 Horizontal Partitioning 과 Vertical Partitioning 이 있음
각각 똑같은 역할의 개수 늘리기 , 역할을 나누어서 개수 늘리기임 .
Horizontal Partitioning
같은 역할을 하는 장비의 수량을 늘리는 것
Scalability 는 이것이 가능하냐의 여부라고 볼 수 있음 .
통상 Scale out 은 이것을 의미함 .
예 ) L4 sw + Web server, Oracle RAC, Hadoop system
Vertical Partitioning
단일 서비스 내에서 기능별로 장비를 분화하는 것
시스템의 변경이 발생하므로 증설을 위해 이것을 시도하는 것은 Scale out 이 아님
Horizontal Partitioning 이 효율적으로 가능할 수 있도록 기능별로 분화시키는 설계 작업
예 ) Web/WAS/DB 구조 , image 서버 분리 , 용도별 DB 분리
이야기 순서
Horizontal Partitioning 에 대한 이야기
Vertical Partitioning 에 대한 이야기
Database 를 Scalable 하게 구성 하려면 ?
Horizontal Partitioning
장비 수량을 늘려서 Throughput 을 늘리는 방법 , 또는 그 구조
당연히 개별 처리건의 최소 Latency 를 낮추는 데는 기여를 .
보통 coordinator 가 필요하며 이들이 성능 저하나 장애의 원인이 된다 .
통상 대외용 Virtual Address 가 제공된다 .
Mediator Pattern
개별 노드가 완전히 동일한 경우가 Load Balancer( 예 . L4 switch for Web server)
Load 외에 요청의 내용에 따라 처리 장비간 업무 배분을 하는 경우도 있다 .( 예 . Global Server Load Balancing, NDDS 의 사용자별 QOS 레벨 관리 ,HDFS Name Node)
요청을 직접 relay 하는 방법외에 요청자에게 사용할 노드를 안내하는 방식도 있다 .
Virtual Address
외부와 독립적으로 Horizontal scale out 이 가능하게 하는 요소
Virtual IP, DNS 기반 URL, Partitioned Table 에서의 Table Name
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
CasesL4 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
Vertical Partitioning
기능 요소별로 Resource 의 필요량이나 종류가 다른 것을 구분 하는 것
통신 구간이 생길 수 있으므로 Latency 증가와 함께 장애가능성이 폭증할 수 있음
분화된 기능들끼리의 연동 방식이 부적절할 경우 장비 추가의 효과가 없을 수 있음
도구들
Platform 으로부터의 자유 : Human Readable Text over HTTP(XML,JSON 등 )
비동기 처리를 통한 성능 향상 : Messaging System, File 송수신을 통한 Batch 처리
Data 신뢰도와 성능을 맞바꾸기 : Cache
Messaging System
Synchronous 연동의 단점
Message Oriented Architecture/Middleware
JMS, AMQP, XMPP, ActiveMQ
Cache
“ 읽기” 성능 향상을 위한 요소
Read 의 비율이 압도적인 웹 서비스의 특성 상 Data 의 불일치를 약간만 허용해도 크게 성능을 높일 수 있다는 것을 활용한 것
File Cache : L7 Web Cache, CDN
Data Cache : Key-Value 기반 Memory Cache( MemcacheD, EHCache 등 )
Database
거의 모든 시스템들의 bottleneck
Scalable 하게 만들기 가장 어려운 IT 요소
가장 중요하다고들 하는 시스템
법률 규제가 가장 많은 시스템
...
RDBMS 란 ?
Relational Database Management System
Oracle Database 를 부르는 또다른 이름
메인프레임 시절에 처음 만들어진 물건
UNIX 로의 downsizing 을 성공하게 한 주역
Cloud/ 오픈소스의 물결에 흘러가는 SW
Data 의 종류들
NXMile/Gifticon/NDDS 에서의 Data 들 성향을 나누어 보기
Data 별로 요구되는 Data Storage - DB 의 requirement 는 ?
“Oracle RAC 를 써야만 할 것 같은 Data” vs. “DB 를 안써도 될 지 모르는 Data”
DBMS 다시 생각해보기
DBMS 란 ?
읽기 Schema vs. 쓰기 Schema
DB 에서 Column 의 용도는 무엇인가 ?
오픈 소스 DB 의 신뢰성은 ? In-house sw 의 품질과 같이 고려해본 오픈소스 SW
Database Partitioning- Vertical
모든 Data 가 똑같이 관리될 필요는 없다 .
Database Partitioning- Horizontal
같은 종류의 Data 라도 꼭 같이 있어야 하는 것은 아니다 .
용어 정리Big Data
Hadoop/MongoDB/Cassandra/HBase/Hive...
NOSQL
Open source Database
Distributed Database
In-Memory Database
...
Thank you