Upload
amazon-web-services-korea
View
765
Download
9
Embed Size (px)
Citation preview
대규모 분산 시스템”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 서버군 백엔드서버군
AZ3
Auto scaling
Group
AZ1
AZ2
Amazon SQS
AZ3
Auto scaling
Group
AZ1
AZ2
Amazon ELB
작업 전달
2. Retries with Exponential Backoff
Exponential Backoff• 재시도간격을기하급수적으로증가시킴
예:1초후, 2초후, 4초후, 8초후…
• 장기장애발생시시스템에불필요한부담을낮출수있음
대규모 분산 시스템에서는 항상 부분 장애가 발생중• 장애발생시일일이시스템을중지하면고가용성의혜택을제공할수없음
재시도시 성공 가능성을 높여줌
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) {
// 예외 처리}
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