대규모 분산 시스템”Amazon Web Services”

橋本 幸司

Software Development Engineer

Amazon Web Services

번역:정윤진솔루션스아키텍트

Agenda

Amazon Web Services (AWS)의개요

AWS를 사용한 대규모 분산 시스템• Asynchronous IO

• Retries with Exponential Backoff

• Idempotency

• Eventual Consistency

정리

대규모 분산 시스템의 특징

대량의 요청 및 대량의 데이터를 처리하기위해 많은컴퓨터 자원을 사용

시스템은 항상 장애가 발생• 일시적장애

• 영구적장애

전체 시스템의 정확하고 상세한 상태를 파악하는것이어려움

대규모 분산 시스템의 세부 상태를사용자에게 투명하게 제공하는것은 매우어려움

대규모 분산 시스템의 기반 기술

1. Asynchronous IO

2. Retries with Exponential Backoff

3. Idempotency

4. Eventual Consistency

1. Asynchronous IO（비동기API）

많은 사용자로부터 수신되는 대량의 요청을효율적으로 처리하기 위한 방법

처리가완료된것은아니지만

요청에고유 ID로응답

API 요청

API 응답

처리 요청

처리 요청

작업 요청 큐API 서버군

백엔드서버군

Asynchronous IO（API）의 장점

사용자• 응용프로그램에응답지연으로인한중지가능성이낮아진다

서버측• 백엔드를대규모로확장가능하다

• API 를정지시키지않고백엔드를쉽게유지보수가능

• 낮은 API 서버처리량으로도많은작업요청을수신가능

• 요청의순차적인처리및재시도등의제어가매우용이함

비동기 API의예：Amazon EC2

EC2 (Elastic Compute Cloud)

EC2 인스턴스시작 ： RunInstances

• EC2 인스턴스 ID가즉시리턴됨

• 실제로 EC2 인스턴스가 AWS 에서사용가능하게되는시점은수분후

EC2 인스턴스상태확인：DescribeInstances

• 응답PENDING | RUNNING | SHUTTING-DOWN | TERMINATED

비동기 API의예：Amazon ELB

ELB (Elastic Load Balancing)

백엔드 인스턴스의 등록：RegisterInstancesWithLoadBalancer

• 실제로백엔드에인스턴스가등록되는것은수초후

백엔드 인스턴스의 상태 확인：DescribeInstanceHealth

• InService | OutOfService

비동기 API - AWS API

크게 2가지의 범주• 비동기 Mutating API –AWS 리소스에대한변경

예：RunInstances, RegisterInstancesWithLoadBalancer

• Inquiry API AWS 리소스의 상태 확인

예：DescribeInstances, DescribeInstanceHealth

AWS 사용자측프로그래밍모델은쿼리API 를이용한polling 이기본

ELB 및 SQS를사용한비동기 API

API 요청

API 응답

작업 전달

API 서버군 백엔드서버군

AZ３

Auto scaling

Group

AZ１

AZ２

Amazon SQS

AZ３

Auto scaling

Group

AZ１

AZ２

Amazon ELB

작업 전달

2. Retries with Exponential Backoff

Exponential Backoff• 재시도간격을기하급수적으로증가시킴

예：１초후, ２초후, ４초후, ８초후…

• 장기장애발생시시스템에불필요한부담을낮출수있음

대규모 분산 시스템에서는 항상 부분 장애가 발생중• 장애발생시일일이시스템을중지하면고가용성의혜택을제공할수없음

재시도시 성공 가능성을 높여줌

AWS API 사용시재시도가이드라인

HTTP Status Code 재시도

200 (OK) N/A

400 (Client Error) 비추천（회복 가능성 없음）

500 (Server Internal Error) 추천

503 (Server Unavailable) 추천

3. Idempotency（멱등성）

연산을 여러번 적용하더라도 결과가 달라지지 않는성질

예컨데, 서버에 API 요청이 수신되었지만 클라이언트에보낸 응답이 손실된 경우• 클라이언트는 재시도 （API 요청 재전송）

• Idempotency 있음 → 재해 복구

• Idempotency 없음 → 복구 불가（즉, 영구적 재시도 발생）

1. API 요청

3. API 응답

2. API 요청접수완료

API 서버

Idempotency의 예：EC2

EC2 인스턴스시작 API： RunInstances

%ec2-run-instances ami-b232d0db -k gsg-keypair

--client-token 550e8400-e29b-41d4-a716-446655440000

동일한 토큰을 제공하면 Idempotency이보장되는

동일한 토큰임에도 불구하고 입력 파라미터가 다른경우 클라이언트 오류

Idempotency의 예：ELB

모든 ELB API는 Idempotency를제공

백엔드인스턴스등록 API：RegisterInstancesWithLoadBalancer

%elb-register-instances-with-lb MyLoadBalancer

로드 밸런서 이름이 토큰의 역할• 예외 ：DeleteLoadBalancer* API 그룹

-i i-1a2b3c4d

여담：Exception 논쟁（？）

예외 체크：프로그래머는 Exception을처리하는코드를작성해야 한다

예외 처리 안함： 필요 없음

대규모 분산 시스템에서는 항상 장애가 발생하고 있다

• Exception 발생시일일이예외처리하지않음으로깨끗한코드를유지

• 대부분의 경우 종국에는 Retries with Exponential Backoff

try {

x = API_call(y, z);

} catch (API_Exception e) {

// 예외 처리}

Exception: AWS SDK의경우

AWS SDK에서제공되는 Exception 은모두 non-check

exception

4. Eventual Consistency

이상적인 consistency 모델은 update가끝나자마자모든노드에서 update 된내용이 read 가가능

실제로는 동일한 데이터를 복제하여 여러군데 분산저장함으로서 손실을 방지

모든 복제 데이터에 update 를 반영하는데 시간이 걸림• CAP Theorem（다음 페이지）

Eventual Consistency –모든복제노드에 update 가반영될때에비로소 consistency 가유지되는모델

CAP Theorem

Consistency, Availability, Network Partitioning 세가지를모두동시에충족하는것은불가능

Eric Brewer, PODC Keynote, 2000

Eventual Consistency의 예: Amazon S3

데이터를 복제하여 여러곳에 있는 데이터 센터의스토리지에 저장• 99.999999999%의내구성

Amazon S3의데이터 consistency 모델• 새로데이터를업로드하면, read 수행시 “데이터없음”이리턴될가능성이있음 （US Standard에만해당）

• 데이터를 update 하면, read 수행시 update 이전의데이터가반환될수도있음

Eventual Consistency의 예：EC2

EC2를시작하는 API：RunInstances• 인스턴스의 ID가리턴됨

EC2 인스턴스의상태확인 API：DescribeInstances

• 입력매개변수：인스턴스ID

RunInstances API 요청 직후 반환된 인스턴스ID를 기반으로 DescribeInstances 를 요청하면InvalidInstanceID.NotFound 가 리턴됨

Retries with Exponential Backoff 추천

21

Eventual Consistency의 예：SQS

큐 상태 확인 API： GetQueueAttributes• 대기열의메세지수： ApproximateNumberOfMessages

SQS 에서 사용하는 전체 시스템에서 현재 몇개의메세지가 있는지 한순간에 파악하는것이 어렵기 때문에“Approximate”

22

결론

대규모 분산 시스템“Amazon Web Services”

대규모 분산 시스템에서는 언제나 장애가 발생한다.• 모든장애발생시에전체서비스를중지할수는없다.

고가용성 시스템을 구축하기위한 4가지 기술 요소

고가용성 시스템에서 사용자에게 투명하게 모든 정보를제공하는것은 매우 어려움

대규모분산시스템의특징을이해하고 AWS를사용하세요

AWS의구조를반영하여대용량,고가용시스템을구축할수있습니다.