KOF2009웹서비스 퍼포먼스와스케일러빌러티

저자 : 하테나 田中 慎司 stanaka @ hatena.ne.jp번역 :Onnetmns 허태길 heo@onnetmns.co.kr http://d.hatena.ne.jp/stanaka/http://twitter.com/stanaka/

목차 웹서비스 퍼포먼스

Back-End 와 Front-End 시스템의 스케일러빌러티

웹서비스의 특성 부하 , 효율 , 안정성 하드웨어

하테나 웹서비스종류

서비스 규모 등록유저수 : 120 만 월간유니크유저수 : 1200 만

웹서비스 퍼포먼스 기본 : Firebug 로 계측

퍼포먼스 모델

Response HTMLPage Page 요소取得

렌더링 완료

주요요소 HTML 페이지의반환시간 포함되는 페이지요소의 시간 포함되는 페이지요소의수 렌더링속도

시간

주로 Back-End

주로 Front-End

ResponseHtmlPage

Page 요소취득

Front-End 의 퍼포먼스 포함되는 Page 요소 수

CSS Sprite 에의해 삭감 화상 Request 의 압축

렌더링속도 광고의지연로드

Adsense 를 차후처리

Firefox 확장 Google .. Page Speed Yahoo .. YSlow

Back-End 의퍼포먼스 HTMLPage 의 Response 시간 포함되는 Page 요소의 Response 시간

퍼포먼스의 향상 스케일러 빌러티의 확보

포함되는 Page 요소의수 헤더를 적절히 사용

ETag, Cache-Control, Last-Modified 등→ 처음부터 Request 되지 않도록 한다 .

Response 시간을계측 계측방법

특정 URL 를 이용하여、그 시간을 계측 Live Access Log 에서 수집

Live Access Log 를 분석 Hadoop 클러스터

Core2Quad 서버 10 대 하테나다이어리 ( 하테나블로그서비스 ) 의 Log4GB → 10 분

정도에 처리 분포를 그래프화

Response 시간의분포그래프

양호한 Response 의 예

캐쉬에 의한 영향

시스템의 기본구성

proxy proxy

LVS

LVS

mod_perl mod_perl mod_perl mod_perl

LVS

MySQL MySQL

LVS

LVS

LVS

Reverse Proxy

Application Sever

DataBase Sever

LoaderBalancer

하테나 북마크의 경우

Application(user)

DBcontent

Application(bot)

DBentry

DBhtml

DBkeyword

memcached

hadoop

searchersquid

worker관련문서

Categorize

계수 10 대LoaderBalancerRevers

e Proxy

Application(image)

Sever 약 500 대 → 가상화해서 약1150 대

하테나의서버대수

WebService 의 3 가지 지표 스케일러빌러티

대량의 Request 각각의 Request 는 비교적 단순 Service 의 성장을 예상하기 어렵다 .

고가용성 24/365 (24 시간 365 일 )

Cost 퍼포먼스 한개의 Request 처리에 걸리는 Cost 는 작다 처리의 대부분은 비 Critical

1. 스케일러빌러티 다수의 Service 는 Sever1 대로 동작한다

하테나표준 Sever 4 core CPU, 8GB RAM Peak 성능은、수천 Request/ 분

고만고만한 Sever 4 core CPU x 2, 32GB RAM

대규모 Service 는 Sever1 대로 동작하지않는다 100 만 PV/ 달 정도가 지금의 한계

→ 하테나에서는 、수억 PV/ 달

Layer 별 스케일러빌러티 Application Sever

구성이 동일한 상태를 가지지 않음 → 용이 DataBase (DB, File Sever etc)

Read 의분산 → 비교적용이 Memory 를 최고까지 올리는 방법도 있음

Write 의분산 → 어려움

부하의파악 부하의파악

Sever 관리툴 (http://servers.hatena.ne.jp/) 상태의감시

부하를 가시화해서 、 Bottleneck 과 이상을 파악가능 하게한다 .

OS 의 동작원리를알고 , 올바른 성능을 끌어낸다 .

把握

스케일러빌러티와소프트웨어개발 개발의전제

대량의 PV 발생하는것 대규모데이터가 축적되는것

얼마안되는부하의증대가 예상외의 영향을 일으키는 일도 .. 실행하는 SQL 가 변화 참조하는 DataBase 의 증가

2. 고가용성 24/365 내장해성

冗長化 (redundancy)

Failover 안정된 인프라

과도한 자원소비의 회피 적절한 버퍼의유지

안정성 24 시간 365 일 100% 의 가동율요구 SPOF (Single Point of Failure) 의 제거

冗長性 (redundancy) 의 확보

冗長性 (redundancy) 확보의실제 Application Sever 은冗長化 (redundancy)

하기쉽다 . 상태를 가지지 않는다 .

DataBase 은冗長化 (redundancy) 가 어렵다 . 상태의 복제・동기

기간부분의 네트워크는冗長化 (redundancy) 가 비교적 어렵다 .

안정시키기위해서 트레이드오프

안정성 ←→ 자원효율 안정성 ←→ 속도

아슬아슬할때까지 메모리를튜닝 메모리소비가증가 → 성능정하 → 장해

아슬아슬할때까지 CPU 사용 1 대 Down → Capacity Over → 장해

환경의불안정 요인 Application

기능추가 메모리누수 유저 액세스패턴의 변동 데이터량 의 증가 외부제휴 의 추가

하드웨어 메모리・ HDD ・ NIC 장해

부하증대

능력저하

튼튼한 시스템 상태를 가지는 프로세스를 줄인다 .

기본 DB 에 집약한다 상태를 재구성 할 수 있도록 한다 .

잃어버려서 곤란하지 않도록 한다 . 국소적인 장해의 영향을 억제한다 .

冗長度 (redundancy) 를 높여 장해에 의한 부하의 집중 ・증대를 억제한다 .

冗長性 (redundancy) 싼 하드로 신뢰 멀티마스터 무정지 Maintenance

MasterDB

Master DB

ApplicationSever

X

상호 replication

무정지 Maintenance 무정지 DB Maintenance

Rolling ・ Update 조건

Maintenance 전후로 모순되지 않는 것 1 대로 견딜수 있는 것

Master DB Master DB

ApplicationSever

Master DB Master DB

ApplicationSever

Maintenance

3. Cost 퍼포먼스 1 대의하드로 많은 Request 를처리

리소스효율

1 대의단가를 내린다 HardCost

운용 Cost 를 내린다 . 일인당의 하드 수

저비용을 실현하는 기술 #1 지수적인 성능이 향상되는 하드웨어 무어의법칙 ( ムーアの法則 )

「 집적회로상의 트랜지스터 카운트는 18 개월 마다 배가 된다 」

出典 : http://www.intel.co.jp/jp/intel/museum/processor/index.htm

저비용을 실현하는 기술 #1 Memory ・ HDD 도빠르게 가격이 싸지고 있

다 . 3년전 .. 2GB 에 30,000엔

8GB 에 120,000円 현재 .. 2GB x 2 에 5,000엔정도

8GB 에 10,000円

4core 8GB Sever 가 3년전 수십만엔 현재 8만엔

Memory ・ HDD 가격의 추이

참조 : http://www2s.biglobe.ne.jp/~sakharov/research/pfo_main.htmlMemory HDD

저비용을 실현하는 기술 #2 상품화・오픈화하는 소프트웨어 오픈소스

OS(Linux) 언어 (C, C++, Perl, Ruby, …) DataBase(MySQL, PostgreSQL, …) WEBSever(Apache, Lighttpd) 프레임워크 (Ruby on Rails, Catalyst, …) 대규모 컴퓨팅 (Hadoop)

시스템을 염가로 구축 소프트웨어로 노력할 수 있는 곳은 노력한다

NAS ・ SAN → 보통 PCSever + MogileFS 상용 Router → 보통 PC Router

참조 : Google ECC 메모리 사용 RAID 는 사용하지 않음

하드웨어 요구 사양 CPU → 그 나름대로 고속 메모리 → 8G 정도 스토리지 → 2.5”HDD or SSD

hot swap 은 하고 싶다 NIC → 기본 1 포트 충분히 원격 관리 기능→거의 필요 없다 전원 이중화→거의 불필요

세상에 탐나는 사양이 별로 없다 .

가상화를 전제로 한 하드웨어 염가의 하드를 유효이용

최소한의 관리기능 다 ( 多 ) 코아의 CPU 대량의메모리 유연한 IO 성능

Diskless 하드웨어 RAID-10 SSD RAID-0

관리용 하드콘솔을불필요하게 한다 . IPMI \1〜2 万 /Sever → Intel AMT

독자 하드웨어 세밀하고 빠르게 집적밀도의 향상 신규파츠 (parts) 의 조달

독자 하드웨어

독자 하드웨어 데스크탑용 M/B

Intel AMT 데스크탑용 CPU 네트워크포트 x 1 ECC없는 메모리 RAID없이 or Software RAID

독자 하드웨어

참조 : Google 의 Sever

出典 : http://news.cnet.com/8301-1001_3-10209580-92.html

독자 하드웨어 신구

하드웨어성능을 끌어낸다 . 염가의하드로 구축 하드의 특성을 이용

데이터를 메모리에 올린다 MySQL, TokyoTyrant 라든지

IO 성능의분산

데이터량에 메모리량을 맞춘다32G 16G

단체 성능의 향상예 SSD: Solid State Drive 액세스 성능

양호한 랜덤 억세스 성능 메모리 > SSD > HDD RAID-0/10 > HDD

RAID-1 메모리만큼은 아니지만 , 충분히 고속

Intel SSD X-25E/M 실전 환경에서 가동중

On Memory vs SSD32G 16G + SSD

Iowait 는거의발생하지않음

32GB … 거의 On memory

SSD … 대량의 ioread

SQL 처리 성능은거의 동일

SSD 의 리스크 아직 리스크도 ..

장해 패턴이 불명 작년의 초가을에 구입한 염가 SSD 는 반년에

고장 Intel SSD 는 미고장

언제라도 재구성 가능한 곳에서 사용

그밖의 요소기술 네트워크 가상화 기술 커스텀 엔진 계산 클러스터 글로벌 대응

네트워크의 이중화

IDC 거점별 최대 65534host

IDC 내 각 블록 별 대응 1440host 정도

2-4Rack 분 대응 1022host 까지

Core층 : 트래픽의 큰흐름을 맡는 층

Distribution층 : 트래픽각 서브네트워크에 배송하는층

Access층 : 서버에 Endpoint 를제공한다 .

라우터용 하드웨어 조금좋은 M/B

ASUS/SuperMicro 데스크탑용 CPU 네트워크포트 x 2 ECC 메모리 IPMI

가상화기술

가상화기술에대한 기대 스케일러빌러티

오버헤드의 최소화 Cost 퍼포먼스

리소스의 소비 효율의 향상 운용의유연함

환경의단순화 고가용성

환경의격리

가상화기술의 메리트 IPMI 의 대체로서의 하이퍼 바이저 환경의 추상화

하드 차분의 흡수 리소스 소비의제어

과부하 에대한 경보 부하조정

자율제어 monit*1 과의 조합

*1: 리소스감시툴 http://mmonit.com/monit/

가상화기술의 메리트 IPMI 의 대체로서의 하이퍼 바이저 환경의 추상화

하드 차분의 흡수 준가상화 (ParaVirtualization) 를 사용

vs 완전 가상화 (FullVirtualization) 리소스 소비의 제어

과부하에 대한 경보 자율제어 monit*1 과의 조합

*1: 리소스감시툴 http://mmonit.com/monit/

가상화 Sever 의 구축 정책 하드웨어 자원의 이용율의 향상

비어 있는 자원을 주로 이용하는 DomU 를 투입 CPU 가 비어 있는→웹 Sever IO 가 비어 있는→ DBSever 메모리가 비어 있는→캐쉬 Sever

동거를피하는 조합 같은 경향 AND 부하의 높은 용도끼리

별도 Sever 의 웹 Sever끼리 등 .. 중앙 스토리지는 사용하지 않는다

하드웨어

가상화 Sever WEB Sever

WEBSever

메모리량 : 4GBDom0: 0.5GBWEBSever 3.5GB

하드웨어

WEBSever

메모리 : 8GBDom0: 0.5GBWEBSever 5.5GB캐쉬 Sever 2GB

캐쉬 Sever주로 CPU-bound

주로 메모리를 소비

CPU 는 소비하지 않는다

가상화 Sever DataBase Sever

하드웨어

DBSever

메모리 : 4GBDom0: 0.5GBDBSever 3.5GB

하드웨어

DBSever

메모리 : 8GBDom0: 0.5GBDBSever 3.5GBWEBSever 4GB

WEBSever주로 IO-bound

주로 CPU-bound

Sever 관리 툴어느 Rack 에 포함되는

Sever 구성의부하와일람

Sever 관리 툴 가상화대응

Sever 의 부모자식관계와、자식

Sever 의부하 일람

가상화에 의해서 얻을 수 있는 것 물리적인 자원 제약으로부터의 해방

자원의 동적인 변경 VM 의 마이그레이션・복제

소프트 레벨의 강력한 호스트 제어 이상 동작시의 국소화 호스트의 제어가 용이해진다

용이한 Sever 증설 → 스케일러빌러티

하드 Cost ・운용 Cost 저하 → Cost 퍼포먼스・고가용성

커스텀 엔진 RDBMS 에서는퍼포먼스적으로 어려운용도

유사 기사 검색 카테고리 판정 전치인덱스에 의한 검색

어느 정도의 규모의 데이터 컴팩트한 데이터 형식 3000 만 엔트리 x 100 words→3.5 GB

독자적인 알고리즘으로 고속 처리

계산 클러스터 MapReduce

出典 : MapReduce: Simplified Data Processing on Large Clusters, Jeffrey Dean and Sanjay Ghemawat

Hadoop Apache project 에 의한 MapReduce 의 편입 MapReduce HDFS (Hadoop Distributed File System) Java

Facebook, Yahoo! Inc. (& はてな )에서채용

글로벌 전개

글로벌 전달 태평양을 넘는 것은 상당한 오버헤드

6 MB 의 미디어 파일

태평양 넘는것→ 30초 정도 CDN → 5초정도

글로벌 전달 CDN 을 사용

Amazon Cloudfront

Amazon Cloudfront 오리지날의 데이터는 일본의 DC 참조 빈도의 높은 파일을 Amazon S3 에 업로드 Amazon Cloudfront 로 전달

정리 WEB Service 의퍼포먼스

Back-End 와 Front-End 양쪽 모두의 개선이 필수

시스템의스케일러빌러티 WEBService 의 특성 부하와효율과안정성 하드웨어

양퍼포먼스・고스케일러빌러티・안정

Q&Astanaka@hatena.ne.jp