[AWS] Advanced Architecting on AWS - 2

 

홍혜선님이 진행하는 Advanced Architecting on AWS 과정을 기반으로 작성한 글 입니다. AWS서비스를 파악하고 복원력, 보안성, 가용성이 우수한 IT솔루션을 설계하기 위한 모범사례와 함께 설계능력을 습득합니다.

 

 

3. 하이브리드 연결

요구사항

• 온프레미스 VPN을 사용하지 않고 AWS에  연결하려면 어떻게 해야합니까?

• VPN 설계를 최적화하려면 어떻게 해야합니까?

• 일관된 대역폭을 유지하고 잠재적인 연결 손실로 인한 위험을 최소화하려면 어떻게 해야합니까?

• 온프레미스사용자가 프라이빗영역의 리소스에 연결하려면 어떻게 해야합니까?

 

 

AWS Client VPN

AWS Client VPN은 AWS 리소스와 온프레미스 네트워크의 리소스에 안전하게 액세스하는데 사용 할 수 있는 관리형 클라이언트 기반 VPN 서비스입니다. 사용자가 VPN 엔드포인트를 생성하여 임의의 위치에서 네트워크에 접근이 가능합니다.

 

 

 

AWS Site-to-Site VPN 

별도에 설정없이 안정적으로 암호화하여 통신을 가능하도록 합니다. 연결옵션에는 3가지가 있습니다.

 

 

옵션1. VPC당 하나씩 해당 온프레미스 데이터센터와 연결합니다. IPsec 프로토콜을 사용합니다. 

 

 

옵션2. EC2 기반으로 VPN을 연결합니다. 직접 회사에서 VPN을 관리할 수 있는 환경을 갖는 장비를 연결할 때 사용합니다. IPsec이 아닌 다른 프로토콜을 사용해야 할 때 적합합니다.

 

 

옵션3. Transit Gateway를 이용한 연결입니다. 

 

 

 

각각의 터널은 active-stand_by 구조가 됩니다.  

 

 

ECMP 프로토콜을 이용하여 대역폭을 확장할 수 있습니다. 

 

 

멀티리전을 사용하는 경우, 하나의 리전처럼 묶어서 동작하도록 엣지 로케이션에 AWS Global Accelerator 로드밸런서를 배치합니다.

 

 

 

AWS Direct Connect

VPN과 다르게 좀 더 고성능으로 사용하기 위한 전용라인을 사용합니다. 이 연결을 구성하면 네트워크경로에서 인터넷서비스공급자를 우회하여 퍼블릭 AWS 서비스 또는 Amazon VPC에 직접 가상 인터페이스를 만들 수 있습니다. 기본적으로 VPN은 인터넷을 통하지만 Direct Connect는 사설통신을 하기 때문에 암호화하지 않습니다.

 

 

AWS Direct Connect 로케이션에서Direct Connect를 사용하려면 네트워크가 다음 조건 중 하나를 충족해야 합니다.

• 네트워크가 기존 Direct Connect 로케이션과 공동 배치되어 있습니다.

• AWS Partner Network(APN)의 멤버인 Direct Connect 파트너와 협력하고 있습니다.

• 독립 서비스 공급자와 협력하여 Direct Connect에 연결합니다.

아키텍처를 보면 하나의 공인IP를 이용하여 서비스에 접근합니다.

 

 

연결옵션에는 아래와 같이 5가지가 있습니다.

 

 

 

하나의 리전에 VPC 를 연결할때는 아래와 같이 프라이빗 인터페이스를 연결해서 사용합니다.

 

 

서로 다른 리전에서는 통신이 불가능합니다.

 

 

Transit Gateway를 사용하면 서로 다른 리전의 VPC도 통신이 가능합니다.

 

 

내부 규정상 암호화통신이 필요한 경우 VPN을 사용합니다. 퍼블릭 인터넷을 기반으로 하기때문에 퍼블릭 가상 인터페이스를 사용합니다.

 

 

옵션4에서 프라이빗 가상 인터페이스를 사용하고자 한다면 DX 게이트웨이를 사용하는데 이때 transit 가상 인터페이스(전송VIF)를 사용합니다.

 

 

예를들어 서버 다운시간동안 백업으로도 사용할 수 있습니다. 추가적으로 아래와 같 DC 로케이션을 분리하여 고가용성 설계가 가능합니다.

 

 

 

Amazon Route 53 Resolver

기본적으로 네트워크에서 5개의 IP주소는 기본적으로 사용할 수 없다. (네트워크, 브로드케스트, 게이트웨이, DNS, 예약)

이때 DNS로서 도메인을 내부 네트워크에서 프라이빗 호스팅 할 수 있도록 합니다.

 

 

도메인 접속 시나리오

 

온프레미스에서 클라이언트가 exam.com을 웹브라우저에서 http요청 -> 해당 클라이언트에 등록된 네임서버 (온프레미스 DNS 서버IP) -> 일부 주소들만 등록되어있는데 루트 도메인 네임서버에 물어봄 (여기도 모름) ->  com 도메인에 네임서버에 물어봄 (여기도 하위 주소는 모름) -> exam.com을 쓰는 로컬 DNS에 IP주소가 등록되어 있어서 여기서 알려줌 -> 네임서버에서는 이 주소를 캐싱하고 클라이언트에게 전달 -> 클라이언트에서 IP주소로 해당 서버에 요청

 

 

따라서 Resolver 인바운드 엔드포인트를 생성하면 DNS서버가 Resolver에게 주소를 물어봅니다. 이후 Route53에게 주소를 반환받아 다시 전달합니다. 이때 클라우드 쪽 EC2에서  온프레미스 서버에 접근하려면 DNS 쿼리를 보내기위해 아웃바운드 엔드포인트를 생성해야 합니다. 

 

이때 다른 VPC와 이 레코드를 공유하고 오버헤드를 줄이기 위해 AWS Resource Access Manager(RAM)을 이용합니다.

 

 

 

4. 전문 인프라

 

AWS Storage Gateway

온프레미스 환경의 데이터를 클라우드로 마이그레이션 할 때 사용합니다. 지연시간을 최소화하고 데이터를 암호화하여 보안을 보장합니다. 자주사용하는 데이터는 로컬에 저장을해서 지속적으로 동기화하고 데이터를 이중화 할 수 있습니다.

 

 

 

VMware Cloud on AWS

기존 사용하는 가상머신방식을 클라우드에서 그대로 쓰기위해 사용합니다. 퍼블릭 클라우드와 함께 하이브리드 형태로 확장할 때 유용하게 사용할 수 있습니다.

 

 

 

AWS Outposts

outposts는 AWS 인프라, 서비스, API 및 도구를 고객 프레미스로 확장하는 완전관리형 서비스입니다. 중요한 데이터를 온프레미스에 보관할 때, 민감하거나 매우 방대한 데이터를 가진 경우 또는 규정준수를 위해 데이터베이스를 로컬에 유지하여 인프라를 구성할 수 있습니다.

 

 

고객은 AWS 관리형 인프라에 대한 로컬 액세스를 제공하여 AWS 리전에서와 동일한 프로그래밍 인터페이스를 사용하여 온프레미스에서 애플리케이션을 구축하고 실행하면서 더 짧은 지연시간 및 로컬 데이터 처리 요구사항을 위해 로컬컴퓨팅 및 스토리지 리소스를 사용할 수 있습니다. 즉, 온프레미스 환경에서 관리형 서비스로써 사용할 수 있습니다.

 

 

 

AWS Local Zones

최종 사용자와 지리적 위치가 가까운 곳에서 상위 AWS 리전의 VPC를 Local Zones로 확장하여 지연시간을 최소화할 수 있습니다. 즉, 엣지로케이션의 주요 서비스들을 제공하기 위한 서비스입니다. 

 

 

 

AWS Wavelength

AWS 클라우드의 성능을 네트워크 엣지로 가져와 실시간에 가까운 응답를 가져옵니다. IOT 기반 또는 모바일환경에서 클라우드를 거치면 지연시간이 증가하는데 이를 해소하기위해 사용합니다. SKT와 같은 통신사와 협력하여 위치를 확장하고 있습니다.

 

 

 

6. 컨테이너

컨테이너가 도입되기 전에는 개발자 및 관리자는 사전 결정된 환경에 맞춰 애플리케이션 또는 워크로드를 구축 해야하는 복잡한 호환성 제한에 자주 직면했습니다. 예를들어 이 워크로드를 베어메탈에서 VM으로(또는 VM에서 클라우드로 또는 서비스 공급자간에) 마이그레이션 해야하는 경우 일반적으로 새 환경에서 호환성을 보장하기 위해 애플리케이션 또는 워크로드를 완전히 다시 구축해야 했습니다. 컨테이너는 환경간에 애플리케이션을 마이그레이션 하기위한 공통 인터페이스를 제공함으로써 이러한 제한 및  비호환성에 대한 해결책으로 구상되었습니다.

 

 

아래 사진과 같이 컨테이너의 경우 가상머신과 다르게 호스트OS의 커널을 공유하여 따로 OS를 구성하지 않으므로 가상머신에 비해 성능 오버헤드가 적습니다.

 

 

도커

도커는 컨테이너 방식으로 가상화를 하도록 런타임을 제공하고, 도커 명령어 형태로 컨테이너를 관리할 수 있습니다. 도커를 사용하는 이유는 단일 프로세스 컨테이너, 스테이트리스, 이식성, 변경 불가능한 단일 아티팩트, 마이크로 서비스 아키텍처 등의 이점을 가지기 때문입니다.

 

 

Amazon ECR Public 및 ECR Public Gallery

도커 허브와 같은 역할로 공개목적으로 도커 이미지를 관리합니다.

 

 

 

AWS에서 컨테이너 호스팅

ECS와 EKS가 컨테이너 오케스트레이션을 제공합니다. 이때 시작 유형으로 EC2와 Fargate를 고를 수 있는데 EC2의 경우 고객이 작업노드에 대해 직접 관리할 수 있도록 합니다. Fargate의 경우 관리형으로 컨테이너 배포에 더 집중할 수 있습니다.

 

 

Amazon ECS

Amazon ECS는 Docker 컨테이너를 지원하는 확장성과 성능이 뛰어난 컨테이너 관리 서비스 입니다. Amazon ECS를 사용하여 Amazon EC2 인스턴스의 관리형 클러스터에서 애플리케이션을 실행합니다. API를 통해 확장 가능합니다.

 

 

Amazon EKS

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화 하기 위한 오픈소스 시스템입니다. Kubernetes를 사용하려면 애플리케이션을 실행할 클러스터가 있어야 합니다.

 

이때 EKS는 자체에서 컨트롤 플레인을 제공하고, 사용자는 직접 접근할 수 없는 완전 관리형 서비스입니다. 

원활하게 마이그레이션 하려는 전체 도메인이 있는 경우 Amazon Route 53 가중치 기반 라우팅을 활용할 수 있습니다. 문제가 없다면 라우팅을 모두 EKS 클러스터로 통하면 마이그레이션이 완료됩니다.

 

7. 지속적 통합 / 지속적 전달 (CI/CD)

CI/CD

Devops의 핵심기능인 자동화를 구현하기 위해 사용합니다. 기존의 레거시 개발환경에서는 개발자가 코드를 개발하는데 빌드 및 테스트, 배포는 인프라 개발자가 담당하였습니다. 이때 환경구성의 문제 또는 불필요한 반복 및 개발주기가 늘어나는 문제가 발생합니다. 이를 해결하기 위해 CI/CD를 통해 개발 프로세스를 자동화합니다.

 

 

CI/CD를 자동화하는 파이프라인을 구축하고 이를 관리 및 제공합니다.

 

 

 

AWS 코드서비스 

1. 개발자가 코드를 CodeCommit 리포지토리로 커밋합니다. 

2. CodePipeline이 CodeCommit 리포지토리에서 새로운 코드 변경사항을 지속적으로 폴링합니다. 이후 CI/CD 파이프라인의 후속 스테이지를 시작합니다.

3. CodePipeline이 새로 커밋된 코드 수정버전을 CodeBuild로 보냅니다. 

4. CodeBuild가 빌드 아티팩트를 Amazon Simple Storage Service(Amazon S3)로 출력합니다.

5. CodeDeploy가 스테이징 환경에 설치하고 문제가 없으면 승인 후 프로덕션 배포를 진행합니다.

 

 

1. 개발자가 코드를 CodeCommit 리포지토리로 커밋합니다. 

2. CodePipeline이 CodeCommit 리포지토리에서 새로운 코드 변경사항을 지속적으로 폴링합니다. CI/CD 파이프라인의 후속 스테이지를 시작합니다.

3. CodePipeline이 새로 커밋된 코드 수정버전을 CodeBuild로 보냅니다. CodeBuild가 코드에서 Docker 컨테이너 이미지를 빌드합니다.

4. CodeBuild가 빌드 ID가 태그로 지정된 Docker 컨테이너 이미지를 Amazon Elastic Container Registry(Amazon ECR) 리포지토리로 푸시합니다.

5. CodePipeline이 AWS CloudFormation을 배포 도구로 사용하고 CloudFormation 스택을 업데이트하여 Amazon ECS 태스크정의 및 서비스를 다시 정의합니다.

6. CloudFormation이 새로 생성된 Docker 이미지를 참조하여 새 태스크 정의를 생성하고 Amazon ECS를 업데이트 합니다(그러나 이 시나리오에서는 CloudFormation을 매번 실행 할 필요가 없습니다).

7. Amazon ECS가 Amazon ECR에서 새 컨테이너를 가져와서 이전 태스크를 새 태스크로 교체하고 배포를 완료하는 서비스를 다시 시작합니다.

 

 

 

AWS CloudFormation

지속적 전달을 사용하여 CloudFormation 템플릿을 프로덕션 스택에 적용하기 전에 변경사항을 자동으로 빌드하고 테스트합니다. 이 프로세스를 이용하면 AWS 인프라를 신속하게 안정적으로 변경할 수 있습니다.