[Reinvent2019] 서버랙이 배송된다고? – AWS Outposts 출시
들어가며
안녕하십니까. GS네오텍 황성영입니다.
AWS는 기본적인 IaaS 서비스까지 수많은 PaaS/SaaS 서비스까지 실로 다양한 서비스를 제공하고 있습니다. 그리고 그 서비스들은 모두 다수의 (데이터 센터 내의) 서버 자원을 기반으로 하구요. 물론 그 물리 인프라는 Service Provider인 AWS가 관리합니다. 이 때 그 서버 인프라를 고객 환경 인근에 설치할 수 있다면 어떨까요? 먼저 AWS 인프라와 고객 환경의 물리적 거리가 줄어들기 때문에 네트워크 지연 시간이 크게 줄어듭니다. 덧붙여 클라우드 환경에서만 사용할 수 있었던 각종 관리형(Managed) 서비스를 지척에서 활용할 수도 있습니다. 어찌 보면 On Premise와 Cloud의 경계를 옅어지게 만드는 아주 오묘한 컨셉의 그 무엇이 되겠죠.
이 컨셉을 기준으로 만들어진 서비스가 AWS Outposts입니다.
오늘 포스팅에서는 Outposts의 서비스 소개와 구성에 대해서 알아보도록 하겠습니다.
AWS Outpost 서비스 개요
AWS Outposts는 AWS 인프라, 기본 AWS 서비스, API 및 도구를 제공하는 물리적 인프라를 고객의 환경으로 옮길 수 있습니다. 실제로 주문을 하게 되면 위의 사진과 같은 42U 서버 랙을 배송 해줍니다. 그렇다면 왜? 물리적인 인프라를 굳이 고객 환경에 위치시켜야 할까요? 그 이유는 고객의 환경에 가깝게 배치함으로써 지연시간을 크게 낮추거나, 로컬에서 대용량 데이터 처리와 같은 워크로드를 지원할 수 있기 때문입니다.
설치 이후에는 Outposts 주변의 물리적인 부분(전원, 사용자 접근 등)은 고객이 관리하고, 그외의 부분은(소프트웨어 업그레이드, 패치 등) AWS에서 원격으로 관리하는 것으로 책임 영역이 분리되어 있습니다.
▨ 배포할 수 있는 AWS 서비스 (`19년 12월 기준)
- 컴퓨팅 및 저장: EC2 (M5, C5, R5, I3en, G4), EBS (gp2)
- 컨테이너: ECS, EKS
- 데이터 분석: EMR
- 네트워킹: VPC, 로컬 게이트웨이
- 데이터베이스 Amazon RDS (MySQL 5.7.26, PostgreSQL 10.9) – Preview
- AWS Tool: CloudFormation, CloudWatch, Snapshot, AMI 등
▨ 제약 사항 (`19년 12월 기준)
- 북아메리카(미국), 유럽(모든 EU 국가, 스위스, 노르웨이), 아시아 태평양(일본, 한국, 오스트레일리아) 지역 지원
- AWS Enterprise Support 가입 필수
- 3년 약정 필수(All/Partial/No Upfront)
▨ 요금
지역별, 구성별로 가격이 다르기 때문에 링크를 참조하시기 바랍니다.
AWS Outposts 구성 요소
Outposts는 위와 같은 네트워크 구성을 가지고 있습니다.
▨ VPC 및 서브넷
- 해당 리전의 VPC에 Outposts 서브넷을 추가하여 사용 가능, 서브넷 생성 시 Outposts의 ARN을 지정
▨ IP 주소
- 온 프레미스 네트워크의 정보를 기반으로 한 customer-ownded IP address pool 라는 주소 풀을 생성하여 Outposts 서브넷 내에 있는 리소스에 인터넷 연결 제공
- EIP를 사용하여 Outposts 내의 자원에 Public한 주소를 할당 할 수 있음
▨ 라우팅
- Outposts의 서브넷은 가용 영역(AZ)의 서브넷과 동일하게 동작
▨ DNS
- Outposts의 EC2 인스턴스는 Route 53 DNS 서비스를 사용할 수 있음 (Outposts에서 AWS 리전의 서비스 링크 연결이 설정 되있어야함)
- 로컬에 설치된 DNS 서버를 사용할 수 있음
▨ Local Gateway
- Outpost와 On-Premise 네트워크 간의 통신을 가능케 하는 논리적 네트워크 장치
- Outposts와 AWS 리전 간 통신에 사용할 수 있음
AWS Outposts 연결 방식
앞에서 아웃포스트의 네트워크 구성을 알아봤습니다. 이번에는 Outposts의 연결 방식에 대해서 구체적으로 알아보도록 하겠습니다.
Outposts는 물리적으로 네트워크 회선이 연결이 되어 논리적으로 AWS 리전과 사용 되는 서비스 링크, 로컬 네트워크와 사용 되는 로컬 게이트웨이 링크로 나눠져 있습니다.
▨ 로컬 네트워크에 대한 연결
OSI 7계층에서 물리적 계층, 데이터 링크 계층, 네트워크 계층 3개의 계층 별로 연결 방식을 다루겠습니다.
@ 물리적 계층
아웃포스트 랙에는 로컬 네트워크에 연결되는 2개의 물리적 네트워크 장치가 있습니다.
아웃포스트의 네트워크 장치와 로컬 네트워크 장치간에 최소 2개의 물리적 링크가 필요하고, 아래와 같은 조합을 지원
@ 데이터 링크 계층
Outposts과 연결을 할 때, Link Aggregation이라는 기술이 사용됩니다.
예를 들어 서비스를 하다보면 연결 회선이 1Gbps를 쓰다가 병목 현상이 발생하여 대역폭을 늘리기 위해 1G -> 10G로 업그레이드를 하려고 했더니 비용이 만만치 않습니다. 그래서 Link Aggregation(LAG)이라는 여러개의 물리적인 포트를 묶어서 마치 하나의 논리적인 포트처럼 만드는 기술이 나오게 되었습니다. 이 기술을 이용하면 업그레이드를 하지 않고 연결 속도를 향상시키거나 가용성을 향상 시킬 수 있습니다.
아웃포스트는 LACP (Link Aggregation Control Protocol)을 사용하여 각각의 디바이스에 2개의 LAG 연결을 설정합니다.
LAG 구성 이후에는 VLAN을 설정하여 논리적으로 서비스 링크, 로컬 게이트웨이 2개로 네트워크를 분리합니다.
서비스 링크 – Outposts내 리소스와 AWS 리전의 리소스 사이에서 발생하는 트래픽(모니터링, API 조작, Cloudwatch Metric 등) / 로컬 게이트웨이 – Outposts내 리소스와 온 프레미스 환경 사이에서 발생하는 사용자 트래픽
@ 네트워크 계층
Outposts 네트워크 장치에는 각 VLAN의 IP주소가 필요합니다. / 30, / 31 CIDR과 함께 전용 서브넷을 사용하는 것이 좋습니다. 예를 들어, 서비스 링크와 로컬 게이트웨이 VLAN을 아래와 같이 지정 할 수 있습니다.
▨ AWS 리전에 대한 연결
@ 서비스 링크로 통신
Outposts가 프로비저닝되면 Outposts와 AWS 리전 사이에서 VPN 연결을 구축합니다. 서비스 링크 통신은 공용 인터넷 또는 DirectConnect 공용 연결이 필요합니다. 서비스 링크에서는 AWS 지역과의 통신 때문에 아래와 같이 주소/포트를 허가합니다.
@ 로컬 게이트웨이로 통신
LAN과 AWS Site-to-Site VPN 또는 Direct Connect가 연결되어 있다면 동일한 경로로 Outposts와 AWS 리전간 비공개로 연결이 가능합니다.
구성 요소와 연결 방식에 대한 자세한 정보들은 링크를 통해서 확인하시면 되겠습니다.
마무리
이번 리인벤트때 등장한 서비스로 Local zone이란 서비스가 있습니다. 두 서비스 모두 사용자와 가까이 자원을 배치시킴으로써 물리/네트워크상 지연을 최소화하자는 컨셉을 가지고 있습니다. 다만 차이점이 있다면 Outposts는 직접 서버랙을 받아서 고객이 원하는 환경에 설치하는 반면(고객이 물리 인프라를 관리), Local Zone은 AWS가 동일하게 물리 인프라를 관리하면서 자체적으로 인프라를 지역적으로 확장시키는 개념에 가깝습니다.
생각해보면 Outposts 서비스가 보안 컴플라이언스 관점에서의 이득도 일부 있을지 모르겠습니다. 어쨌든 기존과 달리 가시적으로 보이는 위치에 Compute/Storage/Network 자원을 배치하기 때문입니다.
암튼 오늘 포스팅은 여기까지입니다. 이 서비스가 어떤 서비스인지 대충 감을 잡으시는데 도움이 되셨으면 좋겠네요. 끝!
최신 댓글