데이터 수집과 분석에 사용되는 Kinesis

Kinesis를 사용하면 다음과 같은 작업을 수행할 수 있습니다.

• 실시간으로 데이터 스트림을 수집 처리 분석할 수 있습니다. Kinesis는 어떤 규모에서든 스트리밍 데이터를 처리할 수 있는 용량을 제공합니다. 그러므로 애플리케이션의 요구 사항을 비용 효율적인 방식으로 가장 적절하게 충족하는 도구를 유동적으로 선택할 수 있습니다.
• 비디오, 오디오, 애플리케이션 로그, 웹 사이트 클릭스트림, 사물 인터넷(IoT) 원격 측정 데이터와 같은 실시간 데이터를 수집할 수 있습니다. 수집된 데이터는 기계 학습, 분석 및 기타 애플리케이션에 사용할 수 있습니다.
• 정형 쿼리 언어(SQL) 또는 Apache Fink를 사용하여 수신되는 데이터를 처리 및 분석한 후 응답을 즉시 제공할 수 있습니다. 모든 데이터가 수집될 때까지 기다렸다가 처리를 시작할 필요가 없습니다.

Kinesis Data Streams

Kinesis Data Streams 사용을 시작하려면 스트림을 생성하고 샤드 수를 지정합니다. 각 샤드는 스트림에서 고유하게 식별되는 데이터 레코드 시퀸스입니다. 스트림은 각 샤드에서 초당 1MB를 수신할 수 있습니다. 각 샤드에는 2MBs 애플리케이션 읽기 제한이 있습니다. 스트림의 총 용량은 해당 샤드 용량의 합계입니다. 리샤딩을 사용하여 필요에 따라 스트림의 샤드 수를 늘리거나 줄입니다.

생산자는 스트림에 데이터를 씁니다. 생산자는 EC2 인스턴스, 모바일 클라이언트, 온프레미스 서버 또는 IoT 디바이스일 수 있습니다. 인프라 로그, 애플리케이션 로그, 시장 데이터 피드, 웹 클릭스트림 데이터 등의 데이터를 전송할 수 있습니다.

소비자는 생산자가 생성하는 스트리밍 데이터를 읽습니다. 소비자는 EC2 인스턴스 또는 AWS Lambda에서 실행 중인 애플리케이션일 수 있습니다. EC2 인스턴스에 있는 애플리케이션은 스트리밍 데이터 증가에 따라 확장되어야 합니다. 이러한 경우 Auto Scaling 그룹에서 애플리케이션을 실행할 수 있습니다. 소비자 애플리케이션을 쓰는 또 한 가지 방법은 Lambda 함수를 사용하는 것으로, 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있습니다. 스트림의 동일한 데이터를 처리하는 애플리케이션이 두 개 이상 있을 수 있습니다.

소비자 애플리케이션의 결과를 저장하기 위해 S3, DynamoDB, Redshift 등의 AWS 서비스를 사용할 수 있습니다.

샤드(Shard)
샤드란 데이터베이스를 물리적으로 분할하는 기법 중 수평분할(수평 파티셔닝)을 했을 때 그 분할된 파티셔닝을 가리키는 말입니다. 샤드로 분리하는 이유는 데이터의 양이 많아지면 그 만큼 성능이나 퍼포먼스가 떨어지기 때문에 이를 케어하기 위해 사용됩니다.

Kinesis Data Firehose

이는 데이터를 거의 실시간으로 처리하는 역할을 합니다. Kinesis Data Firehose는 레코드를 S3, Redshift, OpenSearch service 및 사용자가 소유한 임의의 HTTP 엔드포인트로 전송할 수 있습니다. 또한 레코드를 Datadog, New Relic, Splunk 등 모든 서드 파티 서비스 공급자로 전송할 수 있습니다.

Kinesis Data Firehose는 전송 스트림의 버퍼링 구성을 기반으로 여러 수신 레코드를 연결합니다. 그런 다음 연결된 레코드를 S3에 S3 객체로 전달합니다.

Redshift에 데이털르 전송하기 위해, Kinesis Data Firehose는 다음 작업을 수행합니다.

1. 수신 데이터를 앞서 설명한 형식으로 S3 버킷에 전송합니다.
2. Redshift COPY 명령을 실행하여 S3 버킷에서 Redshift 클러스터로 데이터를 로드합니다.

OpenSearch Service는 OpenSearch API 및 실시간 분석 기능을 제공하는 완전관리형 서비스입니다. 처리된 데이터를 사용하여 기존 비즈니스 인텔리전스 도구 및 대시보드로 준실시간 분석을 생성할 수 있습니다. OpenSearch Service를 사용하면 Kinesis Data Firehose가 전송 스트림의 버퍼링 구성에 따라 수신 레코드를 버퍼링합니다. 그런 다음 Kinesis Data Firehose는 대량 요청을 생성하여 OpenSearch Service 클러스터에 여러 레코드를 인덱싱합니다.

SNS

SNS는 클라우드에서 손쉽게 알림을 설정, 운영 및 전송할 수 있는 웹 서비스입니다. 이 서비스는 게시-구독(pub-sub) 메시징 패러다임을 따르며 푸시 메커니즘을 사용하여 클라이언트에 알림을 전달합니다.

사용자는 주제를 생성하고 어떤 게시자 및 구독자가 주제와 통신할 수 있는지를 결정하는 정책을 정의함으로써 주제에 대한 액세스를 제어합니다. 게시자는 자신이 생성한 주제 또는 게시할 권한이 있는 주제로 메시지를 보냅니다.

게시자는 각 메시지에 특정 대상 주소를 포함하는 대신 메시지를 해당 주제로 전송할 수 있습니다. SNS는 주제와 해당 주제의 구독자 목록을 일치시켜 각 구독자에게 메시지를 정송합니다.

각 주제에는 SNS 엔드포인트를 식별하는 고유한 일므이 있으므로, 게시자는 메시지를 게시하고 구독자는 알림을 받도록 등록할 수 있습니다. 구독자가 구독하는 주제에 게시된 모든 메시지를 수신합니다. 특정 주제의 모든 구독자는 동일한 메시지를 수신합니다.

SNS는 암호화된 주제를 지원합니다. 암호화된 주제에 메시지를 게시하면 SNS는 AWS Key Management Service(AWS KMS)키를 사용하여 메시지를 암호화합니다.

SNS 알림을 사용하는 예시는 다음과 같습니다.

• Auto Scaling 그룹에 특정 변경 사항이 발생하는 등의 이벤트가 있을 경우, 사용자는 즉시 알림을 받을 수 있습니다.
• 구독자에게 이메일 또는 SMS로 특정 뉴스 헤드라인을 푸시할 수 있습니다. 수신한 이메일 또는 SMS 문자에 흥미를 느낀 사람은 자세한 내용을 확인하기 위해 웹사이트를 방문하거나 애플리케이션을 시작할 수 있습니다.
• 업데이트가 가능함을 나타내는 알림을 앱으로 전송할 수 있습니다. 알림 메시지는 업데이트를 다운로드 및 설치하기 위한 링크를 포함할 수 있습니다.

SNS의 특성

모든 알림 메시지에는 게시 메시지가 하나만 포함됩니다. SNS는 게시자가 주제에 게시한 메시지를 그 순서 그대로 전송하려고 시도합니다. 하지만 네트워크 문제로 인해 구독자에게 순서가 바뀌어 전송될 가능성도 없진 않습니다. 엄격한 메시지 순서 및 하나 이상의 구독자에게 중복 제거된 메시지 전달이 필요한 경우 SNS FIFO 주제를 사용합니다.

SNS의 특징은 다음과 같습니다.

• 메시지가 성공적으로 전송되면, 이를 회수할 방법은 없습니다.
• SNS 전송 정책을 사용해 재시도 패턴(선형, 기하학, 지수 백오프, 최대/최소 재시도 지연 및 기타 패턴)을 제어할 수 있습니다.
• 메시지가 손실되지 않도록 모든 메시지는 여러 서버와 데이터 센터에 걸쳐 중복 저장됩니다.
• SNS는 가장 크고 수요가 가장 많은 애플리케이션의 요구 사항에 부합하도록 설계되어, 어플리케이션이 무제한의 메시지를 게시할 수 있습니다.
• SNS를 사용하면 다양한 디바이스의 애플리케이션 및 최종 사용자가 모바일 푸시 알림에 의해 알림을 수신할 수 있습니다. 여기에는 Apple, Google, 및 Kindle Fire 디바이스, HTTP 또는 HTTPS, 이메일 또는 이메일-JSON, 는 또는 SQS 대기열, 그리고 Lambda 함수가 포함됩니다.
• SNS는 액세스 제어 메커니즘을 갖추고 있어 주제와 메시지가 무단 액세스로부터 확실하게 보호됩니다. 주제와 메시지가 무단 액세스로부터 확실하게 보호됩니다. 주제의 소유자가 주제 별로 일정한 정책을 수립해 주제를 게시하거나 구독할 수 있는 대상을 제한할 수 있습니다. 주제 소유자는 전송 메커니즘을 HTTPS로 지정하여 알림을 암호화할 수도 있습니다.

여러 SQS 대기열에 SNS 게시

SNS와 같은 고가용성 서비스를 사용하여 기본 메시지 라우팅을 수행하는 것은 메시지를 마이크로서비스로 배포하는 효과적인 방법입니다. 마이크로서비스의 두 가지 주요 통신 형태는 요청-읍답과 관찰자입니다.

위 예시에는 SNS 및 SQS를 사용하는 팬아웃 시나리오가 나와 있습니다. 팬아웃 시나리오에서는 메시지가 SNS 주제로 전송된 후 복제되어 여러 SNS 대기열, HTTP 엔드포인트 또는 이메일 주소로 푸시됩니다. 따라서 비동기식 병렬 처리가 허용됩니다.

여기서 SNS는 서로 다른 두 SQS 대기열로 주문을 팬아웃합니다. 2개 EC2 인스턴스가 각각 대기열을 관찰합니다. 두 인스턴스 중 하나는 주문 처리 과정을 진행하고, 다른 하나는 데이터 웨어하우스에 연결되어 접수되는 모든 주문을 분석합니다.

SNS 알림을 SQS 대기열로 전송하려는 경우 주제를 구독하고 SQS를 전송 프로토콜로, 유효한 SQS 대기열을 엔드포인트로 지정합니다. SQS 대기열에 SNS의 알림을 수신하도록 하려면, SQS 대기열 소유자는 SNS의 주제에 해당 SQS 대기열을 구독해야 합니다. 사용자가 구독 대상인 SNS 주제와 알림을 수신하는 SQS 대기열을 소유하고 있다면 추가로 필요한 작업은 없습니다. 주제에 게시되는 모든 메시지는 지정된 SQS 대기열로 자동 전송됩니다. 사용자가 SQS 대기열은 소유하고 있지만 주제 소유자는 아닌 경우 SNS는 구독 요청에 대한 명시적인 확인을 요구합니다.

SNS 및 SQS

SNS 메시지는 영구적이지 않습니다. SNS에서는 각 전송 프로토콜에 대한 전송 정책을 정의합니다. 전송 정책은 서버 측 오류 발생 시 SNS에서 메시지 전송을 재시도하는 방법을 정의합니다. 정송 정책이 다사용되면 SNS에서 전송 재시도를 중지하고 메시지를 폐기합니다. 예외의 경우는 DLQ(Dead Letter Queue)가 구독에 연결되어 있는 경우입니다.

SNS를 사용하면 애플리케이션에서 푸시 메커니즘을 통해 타임 크리티컬 메시지를 여러 구독자에게 전송할 수 있습니다.

SQS는 폴링 모델을 통해 메시지를 교환합니다. 즉, 전송 및 수신 구성 요소가 분리됩니다. 또한, 애플리케이션의 분산 구성 요소를 위한 유연성을 제공하므로 각 구성 요소를 동시에 사용하지 않고도 메시지를 송신 및 수신할 수 있습니다.

SQS

SQS는 관리 부담 없이 최소한의 구성으로 바로 사용할 수 있는 완전 관리형 서비스입니다. 이 서비스는 방대한 규모로 작동하느므로 하루에 수십억 건의 메시지를 처리할 수 있습니다. SQS는 여러 이중화 가용 영역을 사용하여 가용성이 높은 단일 AWS 리전에 모든 메시지 대기열과 메시지를 저장합니다. 그러므로 단일 컴 퓨터, 네트워크 또는 가용 영역 장애로 인해 메시지에 액세스하지 못하는 경우가 없습니다. 메시지는 동시에 보내고 읽을 수 있습니다.

개발자는 SQS 대기열을 익명으로 또는 특정 AWS 계정과 안전하게 공유할 수 있습니다. 특정 IP 주소와 특정 시간으로 대기열 공유를 제한할 수도 있습니다. 스트리밍 SIMD(Single Instruction  Multiple Data) 확장 (SSE)은 AWS KMS에서 관리되는 키를 사용하여 SQS 대기열에 있는 메시지의 콘텐츠를 보호합니다. SIMD 확장은 SQS가 메시지를 수신하는 즉시 이를 암호화합니다. 이 메시지는 암호화된 형태로 저장되며 SQS는 권한이 있는 사용자에게 전송할 메시지만 복호화합니다.

SQS 대기열

위 예시에서는 생산자 애플리케이션이 고객 주문을 생성한 후 SQS 대기열로 전송합니다. 소비자 애플리케이션 티어가 생산자 애플리케이션 티어의 주문을 처리합니다. 이 애플리케이션은 대기열을 폴링하고 메시지를 수신합니다. 그런 다음 RDS DB에 기록하고 처리된 메시지를 SQS 대기열에서 삭제합니다. SQS는 처리할 수 없는 메시지를 나중에 처리할 수 있는 DLQ(Dead Letter Queue)로 전송합니다. 이 대기열에서 해당 메시지를 나중에 처리할 수 있습니다.

SQS 대기열을 사용하면 다음과 같은 이점이 있습니다.

• 느슨한 결합
  SQS를 사용하면 전처리 단계를 컴퓨팅 단계 및 후처리 단계와 분리할 수 있습니다. 비동기식 처리가 사용되므로 생산자 로직이 소비자 로직과는 별도의 자체 구성 요소에 격리됩니다.
• 내결함성
  애플리케이션 예외나 트랜잭션 장애가 발생하는 경우 주문 처리를 재시도할 수 있습니다. 최대 재시도 횟수에 도달하면 SQS는 SQS DLQ로 메시지를 리디렉션할 수 있습니다. 그러므로 나중에 이 대기열에서 메시지를 다시 처리하거나 디버그할 수 있습니다. 느슨하게 결합된 워크로드에서 한 노드 또는 작업이 손실되어도 일반적으로 전체 계산이 지연되지 않습니다.
• 급증하는 트래픽 처리
  SQS 대기열 사용 시에는 시스템의 복원력이 향상됩니다. 대기열은 급증하는 트래픽 처리를 위한 버퍼로 사용됩니다. 그러므로 애플리케이션이 확장 작업을 완료할 수 있는 추가 시간이 제공됩니다. 그리고 급증하는 트래픽 처리를 위한 유휴 컴퓨팅 리소스를 프로비저닝할 필요가 없으므로 비용 효율성도 높아집니다.

SQS는 다음과 같은 사례에서 사용을 검토할 수 있습니다.

• 작업 대기열
  동일한 양의 작업을 동시에 처리하지 못할 수 있는 분산 애플리케이션의 구성 요소를 분리합니다. 애플리케이션의 요구 사항에 따라 표준 대기열 또는 FIFO(선입선출) 대기열을 선출할 수 있습니다.
• 버퍼링 및 배치 작업
  아키텍처에 확장성과 안정성을 더하고, 메시지를 손실하거나 지연시간을 늘리지 않고 일시적인 볼륨 스파이크를 원활하게 처리합니다.
• 요청 오프로딩
  요청을 대기열에 전송하여 대화식 요청 경로에서 속도가 느린 작업을 이동합니다.
• 인스턴스 자동 크기 조정
  SQS 대기열을 사용하여 애플리케이션의 로드를 확인할 수 있습니다. 자동 크기 조정과 함께 사용하면 트래픽 볼륨에 따라 EC2 인스턴스 수를 늘리거나 줄일 수 있습니다.

대기열 종류

1. 표준 대기열
   최소 1회 메시지 전송을 지우너하고 최선의 정렬로 제공합니다. 메시지는 일반적으로 수신된 순서와 동일한 순서로 전송됩니다. 하지만 고도로 분산된 아키텍처의 특성상 때로는 2개 이상의 메시지 사본이 순서가 맞지 않게 전송될 수 있습니다. 포준 대기열은 처리할 수 있는 초당 API 호출 수에 거의 제한이 없습니다. 한 번 이상 잘못된 순서로 도착하는 메시지를 애플리케이션에서 처리할 수 있는 경우, 포준 메시지 대기열을 사용할 수 있습니다.
2. FIFO 대기열
   작업 및 이벤트 순서가 중요하거나 중복 항목이 허용되지 않는 경우에 애플리케이션 간 메시징을 강화하도록 설계되었습니다. 또한 FIFO 대기열은 정확히 한 번 처리를 제공하지만 초당 API 호출수가 제한됩니다.

구성 최적화

SQS 대기열 애플리케이션을 생성할 때는 애플리케이션이 대기열과 상호 작용하는 방식을 고려해야 합니다. 이 정보는 대기열 구성을 최적화하여 비용을 제어하고 성능을 향상시크는 데 도움이 됩니다.

• 가시성 제한시간
  소비자가 수신한 SQS 메시지는 소비자가 삭제할 때까지 대기열에 유지됩니다. 해당 메시지가 일정 기간동안 다른 소비자에게는 표시되지 않도록 SQS 대기열의 가시성 제한 시간 설정을 구성할 수 있습니다. 그러면 다른 소비자가 같은 메시지를 처리하지 못하도록 설정할 수 있습니다. 가시성 제한 시간의 기본값은 30초 입니다. 소비자는 처리를 완료한 메시지를 삭제합니다. 가시성 제한 시간이 만료되기 전에 소비자가 메시지를 삭제하지 않을 경우, 다른 소비자가 메시지를 볼 수 있게 되며 해당 메시지는 다시 처리될 수 있습니다.
  
  일반적으로 가시성 제한 시간 설정 시 애플리케이션이 대기열에서 메시지를 처리하고 삭제하는 데 걸리는 최대 시간으로 설정해야 합니다. 시간 제한을 너무 짧게 설정하면 애플리케이션이 메시지를 두 번 처리할 가능성이 높아집니다. 반면 가시성 제한 시간을 너무 길게 설정하면 후속 메시지 처리 시도가 지연됩니다.
  
  
• 폴링 유형
  짧은 폴링이나 긴 폴링을 사용하도록 SQS 대기열을 구성할 수 있습니다.
  • 짧은 폴링을 사용하는 SQS 대기열의 특징을 다음과 같습니다.
    
    • 요청을 수신하는 즉시 소비자에게 응답을 전송하므로 응답이 더 빠르게 제공됩니다.
    • 응답 수가 늘어나므로 비용도 증가합니다.
  • 긴 폴링 시간을 사용하는 SQS 대기열의 특징은 다음과 같습니다.
    • 메시지가 하나 이상 도착하거나 폴링 시간이 초과될 때까지는 응답을 반환하지 않습니다.
    • 응답 빈도는 낮아지지만 비용 또한 감소합니다.

대기열에 메시지가 도착하는 빈도에 따라서는 짧은 폴링을 사용하는 대기열의 응답 중 대다수가 빈 대기열을 보고하게 될 수 있습니다. 애플리케이션이 폴링 요청의 응답을 즉시 받아야 하는 경우가 아니라면 긴 폴링 옵션을 사용하는 것이 좋습니다.

메시지 대기열을 사용해야 하는 이유

특정 기술이 사용 사레에 적합하지 않은 경우를 아는 것도 중요합니다. 메시징에는 일반적으로 보게 되는 고유한 안티 패턴이 있습니다. 특정 속성 집합과 일치하거나 심지어 일회성 논리적 쿼리와 일치하는 메시지를 대기열에서 선택적으로 검색하기를 원할 수 있습니다. 예를 들어 서비스는 특정 속성이 있는 메시지를 요청하는데, 서비스가 전송한 다른 메시지에 대한 응답이 포함되어 있기 때문입니다. 이로 인해 아무도 폴링하지 않고 결코 소비되지 않는 메시지가 대기열에 있는 시나리오가 발생할 수 있습니다.

대부분의 메시징 프로토콜과 구현은 메시지의 크가가 적절할 때(수십 또는 수백 킬로바이트) 가장 효과적입니다. 메시지 크기가 커진다면, S3와 같은 전용 스토리지 시스템을 사용하고 해당 스토어에 있는 객체에 대한 참조를 메시지 자체에 넣어 전달하는 것이 가장 좋습니다.

서버리스

서버리스는 더욱 민첩한 애플리케이션을 구축하는 데 사용할 수 있는 서비스, 사례 및 전략입니다. 서버리스 컴퓨팅을 사용하면 혁신하고 변화에 더 빠르게 대응할 수 있습니다. AWS에서 용량 프로비저닝, 패치 적용 등의 인프라 관리 태스크를 처리하므로 고객을 위한 코드 작성 작업만 중점적으로 수행할 수 있습니다.

서버리스 컴퓨팅은 다음과 같은 이점을 제공합니다.

• 프로비저닝하거나 관리할 인프라가 없음
• 서버를 프로비저닝, 운영 또는 패치할 필요가 없음
• 서버 단위가 아니라 소비 단위별로 오토 스케일링
• 종량제 결제 모델(서버 단위가 아닌 해당 단위에 대해 비용 지불)
• 가용성 및 내결함성 기본 제공
• 서비스에 내장되어 있으므로 가용성을 고려한 설계가 필요 없음

서버리스에는 다음과 같은 서비스들이 있습니다.

상세

API Gateway

API Gateway를 사용하여 API 생성, 게시, 유지 관리, 모니터링 및 보호할 수 있습니다. API Gateway를 사용하여 애플리케이션을 AWS 서비스와 기타 퍼블릭 또는 프라이빗 웹 사이트에 연결할 수 있습니다. 또한 모바일 및 웹 애플리케이션이 AWS 서비스 및 AWS 외부에서 호스팅되는 다른 리소스에 액세스할 수 있도록 일관된 RESTful 및 HTTP API를 제공합니다.

이 게이트웨이는 최대 수십만 개의 동시 API 호출을 수락하고 처리하는데 관련된 모든 태스크를 처리합니다. 이러한 작업에는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링, API 버전 관리가 포함됩니다.

API Gateway의 가능한 작업은 다음과 같습니다.

• 다양한 버전과 단계의 API를 호스팅 및 사용
• API 키를 생성하고 개발자에게 배포
• Signature Version 4(SigV4)를 활용하여 API에 대한 액세스 권한 부여
• RESTful 또는 WebSocker API 사용

주된 기능은 다음과 같습니다.

• 여러 마이크로서비스를 위한 통합 API 프런트 엔드를 생성
• 백엔드에 분산 서비스 거부(DDoS) 보호 및 제한
• 백엔드에 대한 요청을 인증 및 권한 부여
• 서드 파티 개발자에 의해 API 사용을 조절, 측정 및 수익화

예시 아키텍처

위 예시에서는 클라이언트 브라우저가 S3에서 호스팅된 정적 웹 페이지를 요청합니다. 클라이언트 브라우저는 이 웹 페이지를 사용하여 REST API를 통해 API Gateway와 통신합니다. API Gateway는 요청을 인증하고 권한을 부여하며, DynamoDB와 통신하는 Aambda 함수를 호출합니다. 반복 요청을 처리할 때 지연 시간과 백엔드 로드를 줄이기 위해, 이 예에서는 API Gateway 캐시가 포함되어 있습니다.

API Gateway는 Amazon CloudWatch에도 로그를 전송합니다. API Gateway는 API의 각 단계 또는 사용하는 각 메서드에 해당하는 로그를 CloudWatch에 전송할 수 있습니다. 로깅 세부 사항(오류 또는 정보), 그리고 전체 요청 미 ㅊ응답 데이터를 로깅해야 하는지 여부를 설정할 수 있습니다.

API Gateway가 CloudWatch로 전송할 수 있는 세부 지표는 다음과 같습니다.

• API 호출 건수
• 지연 시간
• 통합 지연 시간
• HTTP 400 및 500 오류

또한 액세스 로깅을 활성화하여 누가 API에 액세스했는지, API에 어떤 방식으로 액세스했는지 기록할 수 있습니다.

Transit Gateway

Transit Gateway는 스포크 역할을 하는 연결된 모든 네트워크 간에 트래픽이 라우팅되는 방식을 제어하는 허브 역할을 합니다. 이 허브 및 스포크 모델은 각 네트워크에서 기타 모든 네트워크에 연결할 필요 없이 Transit Gateway에만 연결하면 되므로 관리를 크게 단순화하고 운영 비용을 크게 줄여줍니다. 새로운 VPC를 Transit Gateway에 연결하면 연결된 다른 몯느 네트워크에서 자동으로 해당 VPC를 사용할 수 있습니다.

Transit Gateway를 통한 라우팅은 3 계층에서 작동하며, 패킷은 대상 IP 주소에 따라 특정 다음 홉 연결로 전송됩니다. Transit Gateway는 Transit Gateway 라우팅 테이블을 사용하여 연결 간에 인터넷 프로토콜 버전 4(IPv4) 및 인터넷 프로토콜 버전 6(IPv6) 패킷을 라우팅합니다. 연결된 VPC 및 VPN 연결에 대한 라우팅 테이블에서 라우팅을 전파하도록 테이블을 구성합니다. Transit Gateway 라우팅 테이블에 정적 라우팅을 추가할 수 있습니다.

Transit Gateway는 VPC와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브로, 트래픽에 따라 탄력적으로 크가기 조정됩니다.

상세

네트워크 크기 조정

Transit Gateway는 클라우드 라우터 역할을 하므로 네트워크 아키텍처가 단순화됩니다. 네트워크 확장 시 증가하는 연결 관리로 인한 복잡성이 발생하지 않습니다. 글로벌 애플리케이션을 구축하는 경우 리전 간 피어링을 사용하여 Transit Gateway를 연결할 수 있습니다.

Transit Gateway Network Manager를 사용하면 중앙 콘솔에서 VPC 및 엣지 연결을 모니터링할 수 있습니다. 주요 SD-WAN(Software-Defined Wide Area Network) 디바이스와 통합되므로 TGNM를 사용하여 글로벌 네트워크에서 문제를 실별할 수 있습니다.

VPC와 Transit Gateway 간의 트래픽은 AWS의 글로벌 프라이빗 네트워크에서 유지되며 퍼블릭 인터넷에 노출되지 않습니다. Transit Gateway 리전 간 피어링은 모든 트래픽을 암호화합니다. 단일 장애 발생 지점 또는 대역폭 병목 없이 DDoS 공격을 비롯한 일반적인 공격으로부터 보호해 줍니다.

구성 요소

Transit Gateway의 중요한 두 가지 구성 요소는 연결과 라우팅 테이블입니다.

연결(Attachment)

Transit Gateway Attachment는 패킷의 원본이자 대상입니다. 다음 리소스 중 하나 이상의 Transit Gateway와 동일한 리전에 있을 경우 연결할 수 있습니다.

• VPC
• VPN 연결
• Direct Connect Gateway
• Transit Gateway Connect
• Transit Gateway 피어링 연결

VPN 연결과 Direct Connect 게이트웨이를 사용하여 온프레미스 데이터 센터를 Transit Gateway에 연결할 수 있습니다. 이를 사용하면 AWS 클라우드 내 VPC에 연결할 수 있고 하이브리드 네트워크가 생성됩니다.

Transit Gateway에는 기본 라우팅 테이블이 있으며, 다른 라우팅 테이블도 선택적으로 포함할 수 있습니다. 라우팅 테이블에는 패킷의 대상 IP 주소에 따라 다음 홉을 결정하는 동적 및 정적 경로가 포함되어 있습니다. 이러한 경로의 대상은 모든 Transit Gateway Attachment일 수 있습니다. 기본적으로 Transit Gateway Attachment는 기본 Transit Gateway 라우팅 테이블과 연결됩니다.

각 연결은 정확히 하나의 라우팅 테이블과 연결됩니다. 각 라우팅 테이블은 0개 이상의 연결과 연결될 수 있습니다.

* 연결을 연결한다는 이상할 수 있는 소리를 적어놓은 것 같지만, 명사와 동사로 구분해주시면 감사하겠습니다...

Transit Gateway 설정

Transit Gateway는 여러 AWS 계정에서 작동합니다. AWS Resource Access Manager를 사용하여 Transit Gateway를 다른 계정과 공유할 수 있습니다. Transit Gateway를 다른 AWS 계정과 공유하면 계정 소유자는 자신의 VPC를 Transit Gateway에 연결할 수 있습니다. 두 계정의 사용자는 언제든지 연결을 삭제할 수 있습니다.

Transit Gateway 연결은 패킷의 원본이자 대상입니다. 다음 리소스를 Transit Gateway에 연결할 수 있습니다.

• 하나 이상의 VPC
• 하나 이상의 VPN 연결
• 하나 이상의 Direct Connect Gateway
• 하나 이상의 Transit Gateway 피어링 연결

Transit Gateway 피어링 연결하는 경우 Transit  Gateway는 다른 리전에 있어야 합니다. Transit Gateway는 연결된 VPC와 VPN 연결 간의 동적 및 정적 라우팅을 지원합니다. 각 연결에 대해 경로 전파를 설정 또는 해제할 수 있습니다.

상세

Transit Gateway를 통해 모든 VPC를 연결하거나 격리할 수 있으며, 일부 VPC 끼리만 연결하는 등 다양한 연결 방법이 있습니다.

Site to Site(S2S) VPN

S2S VPN 연결에서는 VPN 터널 2개가 제공됩니다. 이러한 터널은 AWS 측의 가상 프라이빗 게이트웨이나 Transit Gateway와 온 프레미스 측의 고객 게이트웨이를 연결합니다. S2S VPN의 특징은 다음과 같습니다.

• 가상 프라이빗 게이트웨이는 S2S VPN 연결의 AWS 측에 있는 VPN 집선기입니다.
• 한 VPN 연결의 VPN 터널이 서로 다른 가용 영역에서 종료됩니다.
• 고객 게이트웨이는 AWS에서 고객이 생성하는 리소스입니다. 온프레미스 네트워크의 고객 게이트웨이 디바이스를 나타냅니다. 네트워크 관리자가 원격 네트워ㅋ에서 고객 게이트웨이 디바이스 또는 애플리케이션을 구성합니다. AWS는 고객에게 필요한 구성 정보를 제공합니다.
• 고객 게이트웨이 장치의 기능에 따라 정적 라우팅 또는 동적 라우팅을 선택합니다. 동적 라우팅 옵션은Border Gateway Protocol(BGP)를 사용하여 자동으로 경로를 탐색합니다.

고객 게이트웨이 디바이스는 트래픽을 생성하고 Internet Key Exchange) 협상 프로세스를 시작하여 S2S VPN 연결을 위한 터널을 표시해야 합니다. 고객 게이트웨이를 생성할 때 디바이스에 대한 정보를 AWS에 제공합니다.

상세

Direct Connect

Direct Connect는 표준 이터넷 광 케이블을 통해 내부 네트워크를 Direct Connect 로케이션에 연결합니다. 케이블의 한쪽 끝은 사용자의 라우터에 연결되고 다른 쪽 끝은 Direct Connect 라우터에 연결됩니다. 이러한 방식을 교차 연결이라고 합니다. 이 연결을 구성하면 네트워크 경로에서 인터넷 서비스 공급자(ISP)를 우회하여 퍼블릭 AWS 서비스 또는 VPC에 직접 가상 인터페이스를 생성할 수 있습니다.

데이터 센터에서 교차 연결 생성 프로세스를 시작하려면 Letter of Authorization and Connecting Facility Assignment(LOA-CFA)가 필요합니다.

위 예시에서는 온프레미스 데이터 센터에 고객 게이트웨이 디바이스가 있습니다. 데이터 센터에서는 라우터가 있는 고객 케이지로 트래픽이 전달됩니다. 고객 케이지는 AWS 케이지의 AWS 라우터로 트래픽을 전송합니다. AWS 클라우드에서 가상 프라입시 게이트웨이는 AWS 백본을 통해 트래픽을 수신하여 온프레미스 데이터 센터를 VPC에 연결합니다. 이 연결이 설정되면 VPC에서 경로를 생성할 수 있습니다. 그러면 온프레미스 데이터 센터와 VPC의 프라이빗 서브넷 간 트래픽 흐름이 허용됩니다.

Direct Connect 로케이션에서 해당 로케이션과 연결된 리전의 AWS에 액세스할 수 있습니다. 퍼블릭 리전 또는 AWS GovCloud(미국)의 단일 연결을 사용하여 다른 모든 퍼블릭 리전 의 퍼블릭 AWS 서비스에 액세스할 수 있습니다.

Dircet Connect 로케이션에서 Direct Connect를 사용하기 위해 네트워크가 다음 조건 중 하나를 만족해야 합니다.

• 네트워크가 기존 Direct Connect 로케이션과 공동 배치되어 있습니다.
• Direct Connect 파트너와 협렵합니다.
• 독립 서비스 공급자와  협력하여 Direct Connect에 연결합니다.

상세

요금

1. Direct Connect 요금 정책 시에 사용되는 요인

• 용량
  네트워크 연결을 통해 데이터를 전송할 수 있는 최대 속도입니다. AWS Direct Connect 연결의 용량은 초당 Mbps 또는 초당 Gbps 단위로 측정됩니다.
• 포트 시간
  AWS 사용을 위해 포트가 프로비저닝되는 시간을 측정한 값입니다. AWS Direct Connect 위치 내에 있는 AWS Direct Connect 제공 파트너의 네트워킹 장비에서 측정한 값일 수도 있습니다. 포트를 통해 전달되는 데이터가 없어도 포트 시간 요금은 부과됩니다. 포트 시간 요금은 연결 유형(전용/호스트 연결)에 따라 결정됩니다.
• 데이터 송신(DTO)
  AWS Direct Connect를 통해 AWS 외부의 대상 위치로 전송되는 네트워크 트래픽의 누적 양을 지칭합니다. DTO 요금은 GB 단위로 부과됩니다. 그리고 용량 측정값과는 달리 DTO는 전송되는 데이터의 '속도'가 아닌 '양'입니다. DTO 계산 시 정확한 요금은 사용 중인 Direct Connect 로케이션과 리전에 따라 달라집니다.

2. Site to Site VPN 요금 정책

사용하는 연결의 시간당 연결 요금이 부과되며 Direct Connect와 마찬가지로 DTO 요금도 부과됩니다. S2S 사용 시 처음 데이터 전송 100GB는 무료입니다.

Direct Connect 요금 / S2S VPN

선택 기준

하이브리드 연결 요구를 가장 효율적으로 충족하는 제품을 선택하는 것이 좋습니다. 사용 사레에 따라 S2S VPN이나 Direct Connect 중 하나 또는 두 가지를 모두 선택할 수 있습니다.

1. S2S VPN (최대 전송 속도 1.25Gbps)

• 온 프레미스 네트워크와 VPC 간의 네트워크 연결을 빠르게 설정하는 방법이 필요한 경우
• 가용 예산이 많지 않은 경우
• 전송 데이터를 암호화해야 하는 경우

2. Direct Connect (연결 옵션 1/10/100 Gbps)

• AWS S2S VPN에서 제공할 수 있는 것보다 빠른 연결 옵션이 필요한 경우
• Direct Connect를 지원하는 공동 배치를 이미 사 용중인 경우
• 네트워크 성능을 예측할 수 있어야 하는 경우