느슨한 결합
Amazon SQS 대기열과 Elastic Load Balancer는 느슨한 결합을 위한 중간 계층을 추가할 수 있는 두 가지 방법의 예입니다.
AWS 클라우드에서는 Amazon EventBridge를 사용하여 이벤트 기반 아키텍처를 구축할 수도 있습니다.
Amazon EventBridge는 클라이언트(이벤트 소비자)가 사용하는 서비스에서 클라이언트(이벤트 생산자)를 추상화할 수 있습니다.
Amazon Simple Notification Service는 높은 처리량의 푸시 기반 다대다 메시징이 필요할 때 효과적인 솔루션입니다.
Amazon SNS 주제를 사용하면 게시자 시스템에서 다수의 구독자 엔드포인트로 메시지를 팬아웃하여 병렬 처리를 수행할 수 있습니다.
대기열은 다수의 장점을 제공하지만 대부분의 강성 실시간 시스템에서 임계 시간(주로 초 단위)을 초과한 요청은 무효한 요청(클라이언트가 포기하여 더 이상 응답을 기다리지 않는 요청)으로 간주되어 처리되지 않습니다. 이렇게 하면 오래된 요청 대신 여전히 유효한 요청일 가능성이 큰 최근 요청을 처리할 수 있습니다.
약결합 종속성 구현
- 대기열 처리 시스템(SQS)
- 스트리밍 시스템(Kinesis)
- 로드 밸런서(ELB)
- 워크플로(SWF)
위와 같은 종속성은 약결합됩니다.
What is "Amazon Simple Workflow Service (SWF)" ?
SWF는 클라우드에서 완전하게 관리되는 상태 추적기 및 작업 조정자 역할을 합니다.
개발자는 Amazon SWF를 사용하여 병렬 또는 순차 단계가 있는 백그라운드 작업을 구축하고 실행하고 확장할 수 있습니다.
- 사용사례: 동영상 인코딩, 데이터 센터 마이그레이션, 작업자와 제품 카탈로그
- 사례 연구: NASA JPL과 Amazon SWF (데이터 처리 파이프라인)
앱 단계가 완료되기까지 500밀리초 이상이 걸릴 경우 처리 상태를 추적해야 하며 작업이 실패하는 경우 복구하거나 재시도해야 합니다.
이러한 일련의 작업을 Amazon SWF가 지원합니다.
느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다.
한 구성 요소에 대한 변경이 다른 종속 구성 요소의 변경을 강제하는 경우 이러한 구성 요소는 강하게 결합된 것입니다. 느슨한 결합에서는 이 종속성이 분리되므로 종속 구성 요소에서는 버전이 지정되고 게시된 인터페이스만 알면 됩니다.
종속성 간에 느스한 결합을 구현하면 한 구성 요소의 장애가 다른 구성 요소에 영향을 미치지 않도록 분리됩니다.
느슨한 결합을 사용하면 종속 구성 요소에 미치는 위험을 최소화하면서 추가 코드 또는 기능을 추가할 수 있습니다. 또한 종속성의 기본 구현을 확장하거나 변경할 수 있으므로 확장성이 개선됩니다.
느슨한 결합을 통해 복원력을 추가로 개선하려면 가능한 경우 구성 요소가 비동기식으로 상호 작용하도록 합니다. 이 모델은 즉각적인 응답이 필요하지 않고 요청이 등록되었다는 확인으로 충분한 상호 작용에 적합합니다. 이러한 상호 작용에는 이벤트를 생성하는 구성 요소와 이벤트를 사용하는 구성 요소가 포함됩니다. 두 구성 요소는 직접적인 지점 간 상호 작용을 통해 통합되지 않으며 일반적으로 내구성이 있는 중간 스토리지 계층(예: SQS 대기열 또는 Amazon Kinesis 또는 AWS Step Functions와 같은 스트리밍 데이터 플랫폼)을 통해 통합됩니다.
워크로드 서비스 아키텍처 설계
SOA(서비스 지향 아키텍처) 또는 마이크로서비스 아키텍처를 사용하여 확장성과 안정성이 뛰어난 워크로드를 구축합니다. SOA(서비스 지향 아키텍처)는 서비스 인터페이스를 통해 소프트웨어 구성 요소를 재사용 가능하게 만드는 방식입니다. 마이크로서비스 아키텍처는 구성 요소를 더 작고 간단하게 만듭니다.
작은 세그먼트를 사용하면 민첩성, 조직의 유연성 및 확장성이 향상됩니다.
복잡성에는 지연 시간 증가, 디버깅 복잡성, 운영 부담 증가가 포함됩니다.
- 각 아키텍처를 선택할 때는 이점과 복잡성의 균형을 고려합니다.
처음에 모놀리식 아키텍처를 선택하더라도, 사용자 채택에 따라 제품을 확장할 때 SOA 또는 마이크로서비스로 변경할 수 있는 기능이 있는 모듈식 아키텍처인지 확인해야 합니다. SOA와 마이크로서비스는 더 작게 분할할 수 있기 때문에 현대의 확장 가능하고 안정적인 아키텍처로 선호되지만 특히 마이크로서비스 아키텍처를 배포하는 경우 절충을 고려 해야 합니다.
그 중 하나는 분산 컴퓨팅 아키텍처가 구축되므로 사용자 지연 시간 요구 사항을 충족하기가 더 어려워지며, 사용자 상호 작용을 디버그하고 추적하는 과정이 더 복잡해진다는 것입니다.
AWS X-Ray를 사용하면 이 문제를 해결할 수 있습니다.
관리 중인 애플리케이션의 수가 증가함에 따라 운영 복잡성이 증가하므로 다수의 독립 구성 요소를 배포해야 한다는 점도 고려해야 합니다.
AWS 기반 마이크로 서비스
- 민첩성
- 유연한 확장성
- 손쉬운 배포
- 기술적 자유
- 재사용 가능한 코드
- 복원성
분산 시스템의 장애방지를 위한
일정한 작업 처리
대규모 로드가 급속도로 변경되면 시스템에서 장애가 발생할 수 있습니다.
예를 들어 서버 수천 대의 상태를 모니터링하는 상태 확인 시스템은 매번 동일한 크기의 페이로드(현재 상태의 전체 스냅샷)를 전송해야 합니다. 장애가 발생한 서버가 없든 모든 서버에서 장애가 발생하든, 상태 확인 시스템은 대규모의 급속한 변경이 없는 일정한 작업을 처리합니다.
예를 들어 상태 확인 시스템이 100,000개의 서버를 모니터링하는 경우 서버 장애율이 정상적으로 낮을 때는 서버에 가해지는 로드가 작습니다. 그러나 중대한 이벤트로 인해 이러한 서버의 절반이 비정상 상태가 될 때 상태 확인 시스템에서 알림 시스템을 업데이트하고 클라이언트로 상태를 전달하려면 상태 확인 시스템이 과부하가 될 수 있습니다. 그렇기 때문에 상태 확인 시스템에서는 매번 현재 상태의 전체 스냅샷을 전송하는 것이 낫습니다.
100,000개의 서버 상태(각각 비트로 표시됨)는 12.5KB 페이로드에 불과합니다.
- 12.5KB = 12,500 Byte = 100,000 bit
장애가 발생한 서버가 없든 모든 서버에서 장애가 발생하든 상태 확인 시스템은 일정한 작업을 처리하므로 대규모의 급속한 변경이 시스템 안정성에 위협이 되지 않습니다.
실제로 Amazon Route 53 상태 확인의 제어 영역은 이 방식으로 설계되었습니다.
모든 응답의 멱등성 유지
멱등성이 있는 서비스는 각 요청이 정확히 한 번만완료되도록 합니다.
이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다.
멱등성이 있는 서비스를 사용하면 클라이언트가 요청이 오류로 여러 번 처리될 것이라는 염려 없이 재시도를 시행할 수 있습니다.
- 여러가지 기능을 합친 API 서버를 만들면 실패한 기능을 위해 앞단의 로직을 여러번 수행해야 된다.
이를 위해 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다.
멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다.
분산 시스템에서 작업을 최대 한 번(클라이언트가 한 번만 요청) 또는 최소 한 번(클라이언트가 성공 확인을 수신할 때까지 계속 요청) 수행하기는 쉽습니다. 그러나 작업의 멱등성을 보장하기는 어렵습니다. 즉 작업을 정확히 한 번 수행하여 다수의 동일한 요청에서 단일 요청과 동일한 결과를 얻기는 어렵습니다.
API에서 멱등성 토큰을 사용하면 서비스가 중복 레코드를 생성하지 않고 부작용 없이 변경 요청을 한 번 이상 수신할 수 있습니다.
