대형 클라우드 컴퓨팅 플랫폼 분포식 기술 구축의 실천

본고는 장문숭 박사가 2014년 7월 18일의 글로벌 프로그래머 정상 회의인 Arch Summit에서의 주제 강연인 을 바탕으로 정리했다.연설 슬라이드는 ArchSummit 홈페이지에서 다운로드할 수 있다.

강연자 소개

장문숭 박사는 아리그룹의 고급 연구원과 부회장으로 주로 기초 핵심 소프트웨어 연구와 클라우드 컴퓨팅 제품의 연구 개발을 책임지고 인터넷 소프트웨어와 하드웨어 분야의 성능 최적화를 추진하며 차세대 저탄소 저원가 전자상거래 인프라를 구축한다.그도 원본 코드와 리눅스 핵을 개방한 개발자로 유명한 리눅스 집단 프로젝트 LVS(리눅스 Virtual Server)의 창시자이자 주요 개발자이다.LVS 집단 코드는 리눅스 2.4와 2.6의 공식 내부 핵에서 전 세계에서 수만 세트의 LVS 집단 시스템이 운행되고 있으며 10억 달러에 가까운 가치를 창출했다고 보수적으로 추정된다.알리에 입사하기 전 텔텔의 수석 과학자이자 공동 창시자이며 국방과학기술대학 컴퓨터대학 부교수였다.그는 대형 시스템, 리눅스 운영체제, 시스템 소프트웨어 개발, 시스템 안전과 소프트웨어 개발 관리에 풍부한 경험을 가지고 있다.장문숭 박사는 2009년에 알리바바에 가입한 후에 타오바오의 핵심 시스템 연구와 알리바바그룹의 기초 연구를 맡았다. 2013년 10월부터 알리바바그룹의 시스템 연구와 알리바바그룹의 기초 연구 개발을 동시에 맡았다.
이 강연은 주로 다섯 부분으로 나뉜다.

클라우드 컴퓨팅의 도전과 수요

ECS의 분산 스토리지 설계

SLB, RDS 및 OCS의 디자인

전체 링크 모니터링 및 분석 시스템

향후 사업 전망

클라우드 컴퓨팅의 도전과 수요

클라우드 컴퓨팅과 타오바오는 업무 특징에 있어 비교적 큰 차이가 있다. 그 중에서 가장 큰 차이는 타오바오, 티몰은 4천여 개의 작은 응용 프로그램에서 지원되고 모두 분포식 디자인이다. 많은 상황에서 한두 개의 응용 프로그램이 다운되어도 전체적인 서비스에 영향을 주지 않고 순서대로 복구할 수 있다.타오바오의 경우 거래량이 10% 이상 줄어든 경우만 P1 고장으로 간주해 전역에서 사용할 수 없는 시간을 계산하기 시작한다.
클라우드 컴퓨팅의 장면에 있어 하나의 클라우드 호스트가 다운되면 이 고객에게 100% 사용할 수 없다. 이것은 이 고객의 모든'몸과 마음'일 수 있다.그래서 클라우드 컴퓨팅 플랫폼은 신뢰성, 안정성에 대한 수요가 매우 높다.이전에 우리는 네트워크에 문제가 생겼을 수도 있지만 상부의 응용이 잘 되어 이 문제를 은폐했다.한편, 클라우드 플랫폼에 대한 요구는 더욱 높은 신뢰성을 요구하고 데이터를 잃어버려서는 안 되며 시스템이 안정적이고 성능이 좋아야 한다. 현재는 사용자가 물리적 컴퓨터를 사는 것과 성능이 차이가 많지 않다. 또한 문제를 신속하게 포지셔닝할 수 있어야 한다. 사용자가 문제를 발견하기 전에 문제를 해결하고 사용자가 감지하지 못하게 하는 것이 가장 좋다.그리고 원가가 낮아 사용자가 직접 서버를 사는 것보다 싸다는 것이 최하위권이다.

ECS의 분포식 저장 설계

ECS는 알리 클라우드의 클라우드 서버 제품 라인이자 가장 많이 팔리는 제품입니다.그 뒤에는 분포식 파일 저장으로 스냅샷 제작, 스냅샷 롤백, 사용자 정의 렌즈, 고장 이전, 네트워크 그룹 격리, 공격 방지, 동적 업그레이드 등 기능을 지원한다.ECS의 관리는 방대한 제어 시스템을 바탕으로 한다. 현재 하나의 제어 시스템은 3600대의 물리 기기의 규모를 제어할 수 있고 앞으로 5000대에서 2만 대까지 할 계획이다.
그 중에서 데이터의 신뢰성은 매우 관건적이다.아리운의 이전 방법은 데이터를 쓸 때 분포식 저장소의chunk 서버에 세 부를 동시 작성한 후에야 성공한 것이다. 이런 실현의 비용이 크고 시간이 길어서 당시 아리운의 사용자들은 성능이 좋지 않다고 불평했다.이후에 우리는 2-3의 비동기, 즉 2부를 동시 작성하여 성공을 확보했고 3부를 동시 작성하여 IO 성능이 어느 정도 개선되었다.우리는 지금 이 과정에 대해 다시 최적화를 한다. 읽기와 쓰기 성능 최적화의 관건은 성공한 시간을 되돌리는 데 있다. 왜냐하면 삼키는 확률은 시간의 꼴찌이기 때문에 시간 지연과 단축 성능이 향상될 것이다.지연 시간을 단축하는 사고방식 중 하나는 원래 너무 긴 노정을 차단하여 단축하는 동시에 데이터의 신뢰성을 확보하는 것이다.구체적인 사고방식은 다음과 같다.

SSD+SATA의 혼합 저장 방안은chunk 서버에 2단계 저장을 한다.이 방안은 현재 vm에서 이루어지고 있는randwrite-4K-128은 5500 IOPS 정도

에 달한다.

cache 메커니즘

다중 스레드 이벤트 구동 구조로 TDC와 Chunk Server를 재구성하여 IO 요청이 물리적 기기에서 하나의 스레드로 모든 작업을 완성하고 잠금과 상하문 전환을 피한다

다음은 이 몇 가지 메커니즘의 설계를 상세하게 소개한다.

입출력 경로의 각 층 캐치와 입출력을 쓰는 몇 가지 모드 탐색

응용 프로그램에서 디스크에 데이터를 쓰기 위한 요청을 보내는 경로에는 응용 프로그램의user cache(예를 들어 MySQL buffer pool), 운영체제의 캐시(예를 들어 Linux page cache), 하드웨어를 저장하는cache(예를 들어 디스크의 캐시) 등 3층 캐시가 있다.
따라서 다음과 같은 입출력 쓰기 모드를 설명할 수 있습니다.

buffer write, 쓰기 대상은guest OS의 페이지 cache이며, writeback을 통해 하드디스크 캐시를 긁어낸 다음 자동 긁어내거나sync 명령을 터치하는 방식으로 지구화 메모리 미디어에 긁어낸다.이런 쓰기 방안의 속도가 매우 빠르기 때문에 데이터의 완전성이 엄밀하게 보장되지 못할 뿐만 아니라 (쓰기 정책에 따라) 쓰기가 막혀서 서비스 품질에 영향을 미칠 수 있다는 단점이 있다

direct write, 응용 프로그램에서 하드웨어에 직접 쓰는 캐시로 운영체제의 페이지 캐치를 돌아갑니다.예를 들어 MySQL 엔진은 자체적으로 캐시 메커니즘이 있기 때문에direct write를 사용하여 하드디스크 캐시에 쓴 다음sync 명령을 통해 아래의 메모리 미디어로 긁을 수 있다.페이지 캐치를 돌아다니는 장점은 리셋의 영향을 피하는 것이지만 데이터는 절대적으로 신뢰할 수 없고sync가 완료되기 전에 데이터는 안전하지 않다

write+sync, 페이지 캐치에 쓰기와sync/fsync를 호출하여 메모리 미디어에 직접 쓰기,sync 반환에 성공했습니다.이 방법의 장점은 데이터가 충분하고 안전하다는 것이다. 단점은 느리다는 것이다. 구체적인 대기 시간은 운영체제 메모리 사용 상황에 따라 다르다

O_SYNC, 이 탭을 추가한 쓰기 작업은 데이터가 하드디스크 캐시에 쓸 때 디스크에 동기화됩니다

이상은 시스템이 제공하는 몇 가지 메커니즘이다.로컬 SAS 디스크를 참고로 가상 기기에서 4k의 블록 크기로 dd의 쓰기 속도를 하면 버퍼 write는 평균 212MB/s,direct write는 평균 68MB/s,direct+sync는 평균 257kB/s이다.실제 응용에서 서로 다른 상황, 서로 다른 응용에 따라 서로 다른 방식을 선택할 수 있다. 일반적으로 버퍼 write와direct write는 주류이고 둘을 합치면 97%의 쓰기 조작을 차지한다.

클라우드 컴퓨팅 환경에서의 IO

위에서 분석한 것은 로컬의 상황입니다. 쓰기 목표는 로컬의 하드디스크 캐시와 저장 미디어입니다.그러면 클라우드 컴퓨팅 환경에서 우리는 로컬을 선택할 수 있을 뿐만 아니라 분포식 저장도 할 수 있다.분포식 저장은 로컬 저장 매체와 맞먹는다. 우리의 현재 사고방식은 그 위에 분포식 캐시 시스템을 로컬 하드디스크 캐시로 대체하는 것이다.클라우드 컴퓨팅 환경에서 전체 쓰기 IO 경로가 다음과 같습니다.
VM SYNC->PV 프런트엔드 FLUSH-> 백엔드->host->cache 시스템-> 분산 스토리지 시스템
데이터의 완전성을 확보하기 위해 우리의 의미는 모두 POSIX에 부합되고 의미를 상기 경로에서 VM에서 IO 전체 체인으로 전송합니다.

cache 시스템 효과

ECS의 쓰기 성능을 테스트하기 위해 다음 명령을 사용합니다.

 ./fio -direct=1 -iodepth=1 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G

iodepth=1 ， SATA 200 iops， 8ms， （ ） 7ms。

SSD cache ，iops 600 ， 3ms， 2ms 。

 ./fio -direct=1 -iodepth=8 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G

iodepth 8 ， SATA iops 2100 ， 7ms， 7ms 。

SSD cache ，iops 2900 ， 5ms ， 1ms。

cache ：

1. 。
2. 。 ，Google Jeff Dean 2013 2 CACM The Tail at Scale ：“ 1% 1S， 100 ， ， 1S 63%”

ECS의 다른 스토리지 선택

ECS ： SATA ， ； IO ； SSD ， 11 /12 ， chunk server 18 iops， ，iops 9 ， 6 HT CPU， 。

， Hadoop、HBase、MongoDB 3 ， SATA SSD ECS， 。

ECS 。 ， 。 ， ， ——

SLB, RDS 및 OCS

SLB ， 4 （ LVS） 7 （ Tengine）， Anycast ， 。 12 SLB 1200 pps， ； ECS（ ） 70 pps， 。

RDS ， （ ）。RDS ， ， ； 、 ， （MySQL） ， ， ， ， MySQL 。RDS ， SLB ， ODPS ，SLS ，OSS ，OAS ， ， 。 ，RDS tps ECS 、 。

OCS ， Tair ， Proxy 、QoS、 。OCS ， ， 。 ，OCS 99% 2ms ， ， OCS 。 ，OCS ECS Memcached 。

전 체인 모니터링 및 분석 시스템

RDS 。 RDS ， ： ，MySQL ， ， ， ， 。 ， ， ， 。

， SQL 、 ， Kafka ， JStorm Spark ，ODPS 。 SQL T， ， ， ， 、 。

RDS ， ， 。

미래 사업 전망

，ECS IO ， 、 。 Cache ， SSD ， ， SSD ， ，GPU ，LXC/cgroups 。 SSD ，iops ， CPU ？Cache ， ， ， ？ SATA ， SSD ？ 90% ， ， 。 ， ， ， 。 、 ， ， ECS 。

RDS ， MySQL SQL Server， PostgreSQL Oracle 。 ， ， ， redo log， ， ， RDS ， MySQL ？ ， 。

， ， 。 ， 、 AliBench （ ）、OCR 、 CNN/DNN 。

。