Introduction to scalability

1,181 views

Published on

  • Be the first to comment

  • Be the first to like this

Introduction to scalability

  1. 1. Introduction toScalable System jaehonglim@gmail.com
  2. 2. 들어 가기 전에지난 수년간의 IT trend 변화 원인은? Cloud/Open source/NOSQL, ... C에서 Java를 넘어 각종 script 언어들로오픈 소스 SW의 수준이 갑자기 좋아져서?Java들의 Language의 성능이 향상되어?
  3. 3. 10년간의 환경 변화x86 성능 향상 : 지난 10년간 최소 100배NW속도 100배 증가소비자용 Platform 공유 : x86의 신뢰성 향상So What? 단위 performance 최적화 불필요 NW활용에 따른 성능저하/장애가능성 감소 시스템 구축에서 인건비 비중 급증
  4. 4. 시스템 SW에 대한 요구 변화낮은 성능/단일 장비 => Performance,Reliability : UNIX/C/TUXEDO높은 성능/저가 다중 장비=> 개발 용이성, Connectivity :Linux/Java/Tomcat가변적 장비 수량 : 오픈소스는 무료라서가아니라 Site License와 같이 장비 변동에독립적이기 때문에 선택되는 것임
  5. 5. Myth?서비스의 기능을 보고 최적화된 architecture를구성해야 한다.사용자 수, 또는 예측 사용량을 기준으로 Infra필요 규모를 추측할 수 있다.성능이 부족할 경우 문제 있는 부분의 장비를늘리면 된다.
  6. 6. Fact!시스템 Architecture는 기능별 사용량에 가장크게 영향을 받는데, 서비스가 본격화 되기전의 예상은 보통 큰 의미가 없다.사용량을 안다고 해도 신뢰할만한 Infra 소요예측을 하는 것은 불가능할 뿐만 아니라사용량이라는 것에 대해 제대로 정의가 되는경우도 없다.서비스 용량한계는 bottleneck에 의해결정되는데 우선 순위가 있을 뿐 끝은 없다.
  7. 7. What is Scalability?Scalability 대량의 처리를 할 수 있는 능력 또는 처리용량의 증설이 요구 될 때 대응할 수 있는 능력
  8. 8. 관련이 있는 다른 단어들Performance : 단위 작업에 대한 처리 속도Latency : 처리지연시간. 통상 Latency가 낮은것을 Performance가 높다고 함Throughput : 단위 시간내 처리 할 수 있는업무량. 개별 처리의 Latency를 낮추거나동시에 처리할 수 있는 개수를 늘리면 증가함.시스템 구성시 이야기되는 “용량”이 이것임
  9. 9. Scalability의 중요성시스템에서 결국 필요한 것은 ThroughputScalability란 요구되는 Throughput이 증가할때 대응할 수 있는 능력따라서 요구 Throughput의 가변성이 높은웹서비스들에서는 Scalability가 매우 중요함필요없는 경우도 있다.
  10. 10. 제일 쉬운 방법 - Scale up더 크고 빠른 장비로 교체하는 것할수만 있다면 무조건 이것을 선택하라.장점 : 구축이 쉬우며 관리도 용이하다.단점 : 단계적 증가가 어렵고 비싸며 이것으로해결되지 않는 경우가 더 많다.
  11. 11. Scalable 그 자체 - Scale out더 많은 장비를 추가하는 것어려운 선택장점 : 점진적인 증가가 가능하다. 보통 scaleup보다는 싸다.단점 : 설계, 구축 모두 어려우며 관리도 어렵다.
  12. 12. Scale out 하기 - Partitioning장비를 늘려서 해결하는 것이니 전체 시스템을조각 내어야 함자르는 방법으로 Horizontal Partitioning과Vertical Partitioning이 있음각각 똑같은 역할의 개수 늘리기, 역할을나누어서 개수 늘리기임.
  13. 13. Horizontal Partitioning같은 역할을 하는 장비의 수량을 늘리는 것Scalability는 이것이 가능하냐의 여부라고 볼수 있음.통상 Scale out은 이것을 의미함.예) L4 sw + Web server, Oracle RAC, Hadoopsystem
  14. 14. Vertical Partitioning단일 서비스 내에서 기능별로 장비를 분화하는것시스템의 변경이 발생하므로 증설을 위해이것을 시도하는 것은 Scale out이 아님Horizontal Partitioning이 효율적으로 가능할 수있도록 기능별로 분화시키는 설계 작업예) Web/WAS/DB구조, image서버 분리,용도별 DB분리
  15. 15. 이야기 순서Horizontal Partitioning에 대한 이야기Vertical Partitioning에 대한 이야기Database를 Scalable하게 구성 하려면?
  16. 16. Horizontal Partitioning장비 수량을 늘려서 Throughput을 늘리는 방법,또는 그 구조당연히 개별 처리건의 최소 Latency를 낮추는데는 기여를 .보통 coordinator가 필요하며 이들이 성능저하나 장애의 원인이 된다.통상 대외용 Virtual Address가 제공된다.
  17. 17. Mediator Pattern개별 노드가 완전히 동일한 경우가 LoadBalancer(예. L4 switch for Web server)Load외에 요청의 내용에 따라 처리 장비간업무 배분을 하는 경우도 있다.(예. Global Server Load Balancing, NDDS의사용자별 QOS레벨 관리,HDFS Name Node)요청을 직접 relay하는 방법외에 요청자에게사용할 노드를 안내하는 방식도 있다.
  18. 18. Virtual Address외부와 독립적으로 Horizontal scale out이가능하게 하는 요소Virtual IP, DNS기반 URL, PartitionedTable에서의 Table Name
  19. 19. Shared Nothing? Shared Everything?Shared Nothing vs. Shared Everything Web servers vs. Session Clustered Web Servers vs. Oracle RACSharing something : Lock, SyncHA에 의한 공유 요소 : Server-side Session
  20. 20. CasesL4 switchIBM SAN Volume ControllerHDFS Name Node vs. MemcachedOracle Real Application ServerPortal site의 이미지/광고서버 분산 방식Global Server Load BalancingNDDS의 요청 별 QOS분리Database Table Partitioning
  21. 21. Vertical Partitioning기능 요소별로 Resource의 필요량이나 종류가다른 것을 구분 하는 것통신 구간이 생길 수 있으므로 Latency 증가와함께 장애가능성이 폭증할 수 있음분화된 기능들끼리의 연동 방식이 부적절할경우 장비 추가의 효과가 없을 수 있음
  22. 22. 도구들Platform으로부터의 자유 : Human ReadableText over HTTP(XML,JSON등)비동기 처리를 통한 성능 향상 : MessagingSystem, File 송수신을 통한 Batch처리Data신뢰도와 성능을 맞바꾸기 : Cache
  23. 23. Messaging SystemSynchronous 연동의 단점Message Oriented Architecture/MiddlewareJMS, AMQP, XMPP, ActiveMQ
  24. 24. Cache“읽기” 성능 향상을 위한 요소Read의 비율이 압도적인 웹 서비스의 특성 상Data의 불일치를 약간만 허용해도 크게 성능을높일 수 있다는 것을 활용한 것File Cache : L7 Web Cache, CDNData Cache : Key-Value기반 MemoryCache( MemcacheD, EHCache등)
  25. 25. Database거의 모든 시스템들의 bottleneckScalable하게 만들기 가장 어려운 IT 요소가장 중요하다고들 하는 시스템법률 규제가 가장 많은 시스템...
  26. 26. RDBMS란?Relational Database Management SystemOracle Database를 부르는 또다른 이름메인프레임 시절에 처음 만들어진 물건UNIX로의 downsizing을 성공하게 한 주역Cloud/오픈소스의 물결에 흘러가는 SW
  27. 27. Data의 종류들NXMile/Gifticon/NDDS에서의 Data들 성향을나누어 보기Data별로 요구되는 Data Storage - DB의requirement는?“Oracle RAC를 써야만 할 것 같은 Data” vs.“DB를 안써도 될 지 모르는 Data”
  28. 28. DBMS 다시 생각해보기DBMS란?읽기 Schema vs. 쓰기 SchemaDB에서 Column의 용도는 무엇인가?오픈 소스 DB의 신뢰성은? In-house sw의품질과 같이 고려해본 오픈소스 SW
  29. 29. Database Partitioning - Vertical모든 Data가 똑같이 관리될 필요는 없다.
  30. 30. Database Partitioning - Horizontal같은 종류의 Data라도 꼭 같이 있어야 하는것은 아니다.
  31. 31. 용어 정리Big DataHadoop/MongoDB/Cassandra/HBase/Hive...NOSQLOpen source DatabaseDistributed DatabaseIn-Memory Database...
  32. 32. Thank you

×