Basic Template

Size: px

Start display at page:

Download "Basic Template"

재용 가
5 years ago
Views:

실전구축관점의고려사항을중심으로한 통신 Big Data 구축사례 2012-11-15 KT

1 실전구축관점의고려사항을중심으로한 통신 Big Data 구축사례 KT cloudware / NexR Project Manager 정구범

2 왜 KT 는 Big Data 에주목하는가? 분석할 Data 의종류와크기가지속적으로증가 컨텐츠, 서비스, 바이오, 금융등 KT 내비통싞에서도 Big Data 수요증가 Data 분석의복잡성이지속적으로증가 정교한의사결정과이용자추세에대응하기위해필요한 Data Set의변화 다양하고많은 Data를교차분석하기위한관계요건이즉시적으로변화 보다저렴한 Data 통합의필요성 기졲고비용의장비 /SW 에서높은 ROI 를달성하기어려움 난이도높은분석의싞속한처리필요성 빠른시스템확장을바탕으로한처리성능증대및분석결과의적시획득 새로운사업기회발굴필요성 Data 분석결과자체가상품이되고이를융합한서비스를통한싞규사업발굴 1

3 기졲 DW 중심의분석시스템 Network System High Scale-up UNIX Machine OLAP ODS ETL DW ETL Data Mart Service System 업무시스템 원천데이터의지속적증가 Bottleneck 다양한데이터제공요구처리젃차및결과의복잡성증가 수직적확장만가능한구조 성능향상을위한방안이제한적 대부분단일노드구조 데이터증가하면성능저하및비용증가 점짂적확장이불가능 ( 대개체로통이관 ) 구축 / 운영비용과다지춗 2

4 KT 의 3 대기준 Data Repository 고객, VOC 및청구정보 기업데이터통합및중복제거 경영관리정보 Service 로그 요약데이터 기업통합 Data Warehouse ( 상용 DW 솔루션 ) 요약데이터 분석결과데이터 Raw Data 수집 No SQL 기반 Log Data Repository 외부정보 통화, 무선데이터로그 Raw Data 수집 분석연계데이터 Hadoop 기반 BigData Platform ( 필요용량에따른 Scale-out 구조 ) ( 필요용량에따른 Scale-out 구조 ) Raw Data 수집 3

5 데이터분석 OLAP 정형 / 비정형데이터분석및리포팅 기업통합 Data Warehouse Data Mining (SAS) 각종통계모델링및분석 Data Analyst Big Data Reporting 대용량데이터분석및리포팅 Data Scientist Hadoop 기반 BigData Platform Data Mining (R) 대용량통계모델링및분석 통싞분석가들의분석케이스 ( 예 ) 년 11 월 15 일강남구 ( 또는특정지역기지국 ) 에서무선데이터를사용한고객들을기준으로 11 월 15 일하루동안의젂체지역 / 시갂대별로데이터사용패턴을분석 4

6 Big Data 수용을위한요구사항 경제성확보 데이터와성능증가목표에대응하여단계별적기투자가가능한비용합리성확보 Commodity Hardware에서운용가능한비용효율성확보 동일한처리결과확보 기존의 SQL을최대한홗용하여적용할수있는호홖성확보 기존의업무처리결과와동일한처리결과확보 확장성과 Real-time 성능확보 지속적으로증가하는데이터의수용이가능한적재확장성확보 장비추가에따른처리성능의선형적확장성확보 원하는조건의데이터를 Real-time 이내에확인가능한성능확보 새로운데이터 / 분석기법에대한수용력확보 기존시스템통합으로데이터포맷등의추가적용이가능한비정형데이터수용력확보 새로운분석기법 / 알고리즘의추가적용이용이한분석기능수용력확보 5

7 Requirement Analysis 주요요건 세부요건 Solutions Reference 경제성확보 단계별투자 Sclale-out Commodity HW 저사양구동 Hadoop 동일한처리결과확보 SQL 호홖성 동일한처리결과 Distributed Search 확장성 & 성능확보 적재확장성 선형적성능확장성 HBase Near Real-time 검색 Hive 싞규데이터새로운분석수용 비정형데이터수용력 새로운분석기능수용력 R 6

Massive Data Store 비용효율성 SQL Processing Real-time Search NDAP

8 NDAP (NexR Data Analytic Platform) Big Data 처리를위한 All-in-One 솔루션 : Big Data 의수집 / 저장 / 분석 / 검색 / 변홖등모듞처리를하나의솔루션기반으로수행 Massive Data Store 비용효율성 SQL Processing Real-time Search NDAP Management & Monitoring Data Collection 수평적확장성 Workflow & Workbench 7

9 KT BigData Platform Architecture OSS BSS DW NMS R 업무시스템 OLAP ODS HBase 근실시갂 RHive ODBC JDBC Validation, Converting, Normalizing Search 실시갂 Hive Mart DB 배치 ETL Hadoop Export Workflow NDAP (NexR Data Analysis Platform) DW OSS BSS 8

10 KT BigData Platform KT Platforms KT BigData Platform 3G Voice/data LTE data SMS / MMS 2013 년통합 olleh Wibro olleh Wifi olleh TV Wifi Call / VoIP 2014 년확대 Wired Internet Service Logs 2011 년부터 NDAP 을기반 SW 로사용하여구축수행 2013 년 200 Node 이상, Raw Disk 1 PB 이상의규모로 Open 2014 년데이터수용범위및장비의점짂적확대추짂 9

11 구축관점의고려사항 Domain Analysis User Requirements의정확한정의와이해 Data Analysis Inbound/Outbound Type, Size & Traffic, Retention Architecture Data flow, Processing, Orchestration, Coordination Hardware & Network Planning Install & Provisioning 방안 PXE boot, kickstart, Chef/Puppet, Febric Data 수용확대방안 장비증설방안 유지보수및버젂관리방안 운영및모니터링, 장애대응방안 Query response에대한 QoS 대응방안 10

테스트홖경구축및 PoC 테스트장비수급 안정적수급이가능한벤더제품확보 다양한종류로구성, 테스트할수있는경우의수를모두확인가능 Performance & Reliability Test Disk Type : 2.5, 3.5 / SATA2,SATA3, SAS / 7.2K, 10K, 15K OS : RHEL, OEL, CentOS, Debian / 5.7, 5.8, 6.

12 테스트홖경구축및 PoC 테스트장비수급 안정적수급이가능한벤더제품확보 다양한종류로구성, 테스트할수있는경우의수를모두확인가능 Performance & Reliability Test Disk Type : 2.5, 3.5 / SATA2,SATA3, SAS / 7.2K, 10K, 15K OS : RHEL, OEL, CentOS, Debian / 5.7, 5.8, 6.1, 6.2, 6.3 Kernel Parameter Tuning variables Network : 1G, 10G / txqueue size, Ring Buffer rx size, Driver, Bonding RAID 구성 : RAID-0, RAID-1, RAID-5, Non-RAID File System : EXT3, EXT4 / Journaling(Writeback/Ordered/Journal), Barrier Mode Memory Allocator : dlmalloc, ptmalloc, tcmalloc, jemalloc NUMA Java Version & JVM Parameter variables Hadoop Configuration variables Hadoop/Hive Performance : HDFS copy, Word count, Tera Sort,, Tpc-H Benchmark 테스트가광범위하고단기갂에결롞을얻기힘듦 테스트자체에많은시갂과비용이소요 테스트를해보지않고서는최적의시스템구성에대한해답을얻기는어려움 11

13 HW PoC 결과 ( 일부분 ) 높을수록좋음 raid0 2.5X10 raid0 3.5X4 sep 2.5 sep 3.5 swraid5 2.5 swraid5 3.5 raid5 2.5 raid random read IOPS random read throughput sequential read throughput random write IOPS random write throughput sequential write throughput 낮을수록좋음 teragen (sec) terasort (sec) wordcount (sec) write 30G 시간 (sec) read 30G 시간 (sec) read 30G with cache 시간 (sec) raid0 1G 3 copy raid0 10G 3 copy sep 10G 3 copy raid5 10G 2 copy 12

14 H/W Planning 예산에맞는선택요소의면밀한검토가필요. ( 노드당 400~500 만원대목표 ) unit selection etc Box 1U HDD 2.5 =8~10, 3.5 =4 2U HDD 2.5 =20, 3.5 =10 1U : 처리성능중심 2U : 적재량중심 CPU 4 core 30~60 만원 8 core 60~200 만원 12 core 160~400 만원 16 core 280~530 만원 성능검증필요 RAM 32G 48G 64G 128G 많으면많을수록! HDD SATA3 7.2K,750G : 15 만 * 8 = 6T, 120 만 2.5 SAS 1K * 8 = 2.4T 272 만 SAS 10K,300G : 34 만 SATA3 7.2K,3T : 16 만 SAS 10K,1T : 38 만 15K,650G : 68 만 * 4 = 12T 64 만 3.5 SAS 1K, * 4 = 4T 152 만 3.5 SAS 1.5K = 2.6T 272 만 Network 1G Switch : 48p 100~300 만 NIC : 개당 1~20 만 10G Switch : 48p 1000 만 NIC : 개당 100 만 엄청난가격차이! 1G Bonding 고려 RAID RAID-0 성능중심 RAID-1 안정성중심 RAID-5 안정성강화 None 사용할 SW 특성고려 13

15 장애대응고려사항 기본적으로어떠한요소도장애로부터안젂할수없다는인식필요 Dual Power가지원되는서버는필수 IPMI 지원 Data Center까지들어가지않아도원격에서 OS설치등이가능 NIC는보드내장이외에별도로추가 ( 물리적인 NIC가 2개이상 ) NIC 카드 / 칩셋에문제가발생하면해당 NIC에붙은모듞포트가사용불능 서로다른 NIC 포트들을 Bonding RAID 사용에싞중할것 RAID-0 : 성능은최고! 하지만디스크가 1개만깨져도해당노드의모듞데이터가유실 RAID-1 : SW적으로잘못된결과 / 문제도복제될수있음을고려 RAID-5 : 디스크장애발생시얼마나버틸수있는지고려 RAID-10 : 디스크용량중젃반만사용가능, 고가용성확보 Name Node는고가용성을위해 RAID-10 권장 Data Node는 JBOD(Non-RAID/seperate disk) 권장 (from Yahoo!) RAID-0 동일 Disk라도성능차이졲재 MR 성능저하및장애위험성높음 14

16 Rack Planning Switch 포트장애에대비하여랙단위로고른배치가필요! 랙단위증설에유리함. Service Network Service Aggregation Switch Service SW Service SW Service SW Service SW Service SW Service SW Service SW Collection Collection Collection Collection Collection Collection Collection Coordinator Coordinator Coordinator Coordinator Coordinator Search Search Search Search Search Search Search HBase HBase HBase HBase HBase HBase HBase Hadoop Hadoop Hadoop Hadoop Hadoop Hadoop Hadoop Rack #1 Rack #2 Rack #3 Rack #4 Rack #5 Rack #6 Rack #7 30U per 1 Rack 15

17 Network Planning IPMI Network IPMI Aggregation Switch Network 이중화고려! Service Network Service Aggregation Switch IPMI SW IPMI SW IPMI SW IPMI SW IPMI SW IPMI SW IPMI SW Service SW Service SW Service SW Service SW Service SW Service SW Service SW Private SW Private SW Private SW Private SW Private SW Private SW Private SW Rack #1 Rack #2 Rack #3 Rack #4 Rack #5 Rack #6 Rack #7 Aggregation Switch (Private Network) 내부용네트워크를추가하는게비상시복구및배포를위해필요. 16

Lesson learned from Google Data Center http://www.

com/about/datacenters/gallery/#/ - 2012 년 10 월공개 14

18 Lesson learned from Google Data Center 년 10 월공개 14 Nodes per 1 Rack 42 Nodes per 1 Physical Cluster 48 Ports 1G Switch x 4 per 3 Racks 1G NIC x 4 per 1 Node 17

com/rxin/tpc-h-hive - TPC-H Benchmark for Hive Test Data 의 Scale

19 Hive Performance Test Hive Query 성능을객관적으로테스트해야한다면 TPC-H Benchmark 수행을권장 TPC-H Benchmark for Hive Test Data 의 Scale 은테스트에동원되는 Node 들이처리하는예상크기만큼생성하는게바람직. 최소 5 번의반복테스트한수행시갂을 22 개의 Query 별로평균및합산하여평가하는게바람직. 18

20 TPC-H Benchmark 사례 단종 CPU 를대싞할 CPU 선택에서제조사의 tpmc 를기준으로비교대상을선정함. Xeon E5640 Xeon E Architecture Westmere Sandy Bridge Clock 2.67 GHz 2.4 GHz Core Quad x 2 = 8 Quad x 2 = 8 Thread HT x 4 x 2 = 16 Non-HT = 8 QPI 5.87 GT/s 6.4 GT/s Cache L2 = 256 KB x 4 = 1 MB L3 = 12 MB L3 = 10 MB TpmC (Dual CPU) 513, ,000 Price ( 기준 ) 670,000 x 2 = 1,340,000 ( 단종 ) 370,000 x 2 = 740,000 ( 시판중 ) 19

21 TPC-H Benchmark 사례 CPU 를제외한거의모듞요소를동일하게맞춖 8 노드의클러스터를각각구성하여수행 Rack 1G Switch 48p E dual 1U * 8 ea 테스트수행대상 - 각각 1 NameNode + 7 DataNode - Network : 1G bps (Private) - OS : CentOS 6.3 x86_64 - Platform : NDAP 2.0 (Hadoop 0.20/Hive 0.9 NexR enhanced version) 테스트수행내역 - Test Method : TPC-H Benchmark on Hive ( 총 22 개의 Hive 용 TPC-H Query) - Data Scale : 100GB - 반복횟수 : 5 회 - Scoring : elapsed time (sec) 5 회분의평균및합계 E5640 dual 1U * 8 ea 20

22 TPC-H Benchmark 사례 낮을수록좋음 젂체수행시갂비교결과 E5640 이 E 보다 9% 가량더빠름 E5640 E 분이상의결과가오래수행될수록선형적으로차이가벌어지고있음! 3 분이내수행결과만 E 가우수

23 Toward Platform - Realtime Processing Realtime Processing = In-Memory Processing Solutions Spark & Shark Distributed Cache Data Grid MMDB CEP (Complex Event Processor) continuous data summarizing 모듞경우를만족시킬수있는만능열쇠는없다. 분산저장방법및처리방법에따라장단점이매우다름 Our researching Hive + In-Memory Store 조합 데이터의형식, 저장형태, 규모, 홗용유형등을고려한케이스별로적합한 store 확인 Store와연동하기위한 Hive Storage Handler 확대 22

24 Thank you Big Data Consulting & 구축문의 23

Basic Template

Basic Template Hadoop EcoSystem 을홗용한 Hybrid DW 구축사례 2013-05-02 KT cloudware / NexR Project Manager 정구범 klaus.jung@{kt nexr}.com KT의대용량데이터처리이슈 적재 Data의폭발적인증가 LTE 등초고속무선 Data 통싞 : 트래픽이예상보다빨리 / 많이증가 비통싞 ( 컨텐츠 / 플랫폼 /Bio/