여기서 다루는 내용
· Quiz
· VPC 설계 트랜드
· 중계하는 역할의 형태
· 구성 데모
· 정리
Quiz
안녕하십니까, GS네오텍 최준승입니다.
리인벤트 2018 특집글을 연재하고 있습니다.
오늘 주제는 "Transit Gateway" 입니다.
제가 보기엔 매우 획기적이고 중요한. 그야말로 大왕건이 업데이트라고 할 수 있는데요.
이번 포스팅을 읽기 위해서는 자격 조건이 있습니다. 먼저 아래 3개의 퀴즈를 맞추셔야 합니다.
각 문제를 클릭하면 정답이 표시됩니다.
1. VPC 2개가 있을때 2개의 네트웍 구간을 사설망으로 묶는 가장 간편한 방법은?
VPC Peering
2. VPC-VPC or VPC-On Prem 구간을 사설망으로 묶되. Public망을 거쳐 암호화 통신하도록 하는 구성은?
VPN (EC2 / VPN 물리장비 / Virtual Private Gateway 조합)
3. VPC-On Prem 구간의 네트웍을 Dedicate하게 전용망으로 구성하려면?
Direct Connect
문제가 영 구리다구요? 맞습니다.
하지만 문제는 구릴지언정. 오늘 소개드릴 기능은 구리지 않습니다. 대신 재미가 없죠.
저도 이 주제를 어떻게 정리할지 판단이 어려워서. 오늘은 최대한 직관적으로 서비스 컨셉만 소개하고 빠지려고 합니다.
상세한 내용은 기회가 되면 2부로 다시 한번 다루도록 하겠습니다.
VPC 관리와 연동 이슈
AWS를 사용해서 어떤 서비스를 설계하고 구성할때. 제일 처음 고려해야 할것은.
AWS 계정과 VPC를 어느 수준으로. 어느 규칙에 따라 분리해서 운영할 것인가? 의 문제입니다.
예를 들면 제가 게임서비스를 한다고 하면 이런 질문들을 할 수 있겠죠.
- 게임 단위로 AWS 계정을 나눌까? 아님 한 계정 내에 VPC 단위로 게임을 나눌까?
- 각 게임에서 공용으로 사용하는 API 계층은 VPC를 나눌까? 계정 단위로 나눌까?
- 관리 주체를 개별적으로 제어할 수 있게. 최대한 단위-모듈별로 계정과 VPC를 나누고 필요한 부분만 연동하도록 구성할까?
이 부분에 정답은 없습니다.
내가 컨트롤할 수 있다면. 최대한 객체 단위를 나눠서 권한(VPC)과 비용(AWS 계정)을 분리하면 좋구요.
그게 아니라면 필요한 수준에 따라. 단위를 좀 큰 덩어리로 분리해야 겠지요. 이건 오늘 주제가 아니라 생략하겠습니다.
중요한건 VPC의 가장 본질적인 기능은 네트웍 공간의 격리이므로.
VPC를 용도에 따라 잘게 쪼개 놓으면. VPC간 또는 On-Prem의 자원간 연동을 하고 관리해야하는 영역이 생긴다는 것이죠.
요즘 AWS에서 제공하는 네트웍 연동 기능은 AWS 계정-초월적(?)으로 개선이 꽤나 잘 되어 있기 때문에.
다시 말해 네트웍 공간을 붙였다 떼었다 하는 기능을 풍부하게 제공하기 때문에.
제어/관리할 자신이 있다면. 단위 객체를 최대한 나누는 것을 권장합니다. 개인적인 견해입니다.
그럼 다시 새로운 질문이 도출됩니다.
VPC간, VPN간, Direct Connect간 상호 연동은 어떤 방법으로 할것인가?
그리고 이 연동 작업을 비용-효율적이고. 관리부담은 최소화하는 방법은 무엇일까?
연동해야 할 구간이 여럿일때의 고민
의식 흐름에 따라 복수의 네트웍 단위를 연동해 보겠습니다.
2개부터 시작합니다.
※ A와 B는 VPC가 될수도 On-Prem의 무엇이 될수도 있습니다. 연두색 연동도 VPC Peering이 될수도. VPN이 될수도 있구요
연동을 어떻게 하느냐는 나중에 생각하고. 그냥 추상적인 수준에서 생각을 이어가 봅시다.
이번엔 객체가 3개고. 3개 모두 Full-Mesh 구조로 상호 연동이 필요하다고 가정합니다.
※ 아직까지는 할만합니다
하나 더 추가해서 4개가 되면요? 5개면? 6개면?
※ 새로 1개의 객체가 추가되었을때. 뒤로 갈수록 복잡도가 증가하고 있음을 알 수 있다
동일한 구성을 계속 해나간다고 하면 N개의 객체를 풀-매시 구조로 만들었을때.
필요한 연동 구간은 총 n-Combination-2니까. n(n-1)/2가 됩니다. 객체가 10개라면. 연동 구간이 총 45개나 되는 셈이죠.
허나 이렇게 모두 연동이 되어야 하는 경우가 많지 않기도 하고.
이 방식은 객체가 늘어났을때. 관리 포인트가 너무 많아지기 때문에. 보통은 이렇게 구조를 변경하곤 합니다.
모든 길은 로마를 통하는. 이른바 중계용 객체가 생기는 것이지요.
※ 이제 새로운 객체가 추가되어도 중계맨과의 연동만 추가하면 된다
이 방법을 사용하면 라우팅도 일부 간소화되고. 관리포인트도 상대적으로 줄어들게 됩니다.
다만 중계 객체가 SPOF가 되면 곤란하므로. 가용성 관리도 해줘야 하고. 일부 환경에서 병목 구간이 될 수 있는 점은 감안해야 합니다.
그럼 중계는 누가 할거임?
아시다시피 VPC Peering이나 Virtual Private G/W를 통한 VPN 연결은
Transitive하게 패킷을 다른데서 받아서 또 다른곳으로 넘겨주는 역할은 할 수 없기에.
저 중계용 객체는 주로 EC2 기반의 가상 라우터 장비. Cisco나 Vyatta같은 애들을 올리고 이를 통해 연결은 VPN으로 합니다.
※ 실제 AWS 공식 문서로 Cisco 장비를 사용한 구성이 소개되어 있다
그리고 이 객체의 역할-성능은 자연스레 EC2 Instance Type 스펙에 의존성이 걸림은 물론.
EC2 레벨에서 장애가 생기면. 곧 로마의 통신 두절로 이어지므로. 이 레이어의 모니터링 및 가용성을 사용자가 직접 관리해야 합니다.
이제 드디어 오늘 주제의 결론을 말씀드릴 수 있겠네요.
이번에 새로 나온 "Transit Gateway" 기능은 바로 이 중계 역할을 AWS Managed 방식으로 해주겠다는 것입니다.
UI는 좀 생소할 수 있지만 우선 가용성 관리 이슈에서 벗어날 수 있고. CloudWatch를 통해 일부 가시성을 제공하며.
해당 중계단에 붙일 수 있는 객체는 복수의 VPC/VPN/Direct Connect 객체 모두를 지원합니다. ('18/12 기준, D/X는 지원 예정)
※ 결국 이렇게 된다는 말씀입니다
그럼 직접 해보자
서론이 참 길었구요.
실제 구성이 어떻게 되는지 가장 간단한 구성을 보여드릴텐데요.
VPC가 3개가 있고. 이 3개의 VPC를 하나의 Transit Gateway에 매핑해서 모든 구간에서 통신이 가능하도록 구성해보겠습니다.
※ [AWS Management Console] ▷ [VPC] ▷ [Transit Gateways] ▷ [Create Transit Gateway]
약 10여분 후에 Transit Gateway 객체가 생성 완료되었습니다.
이제 여기에 연동할 객체를 붙여(Attach)볼텐데요. 예시에서는 편의상 VPC 객체를 붙여보겠습니다.
※ VPC 3개를 붙이는 아주 단순한 구성입죠
※ [Transit Gateway Attachments] ▷ VPC1를 등록. 이후 VPC2 / VPC3도 동일한 작업을 반복했다
행여 다른 AWS 계정의 VPC를 붙이고 싶으면. 별도 작업으로 해당 VPC를 참조할 수 있게 VPC Share 설정을 해주면 된다.
※ Transit G/W의 Route 탭에 가보면. 자동으로 중계단의 Route Table에 Propagated 처리가 되어 있다
마지막으로 각 VPC Subnet의 Route Table에 상대방 주소대역의 Target을 Transit G/W로 지정해 주면 된다.
※ 1번 VPC의 Subnet의 Route Table 룰에 2번 VPC와 3번 VPC로 넘어가는 규칙을 만들어주었다
2번 VPC와 3번 VPC에도 동일한 Route Table 룰을 넣어주고요.
Security Group은 적당히 열어놓고. 상대방 인스턴스로 22번 포트가 열려 있는지. 확인해 보았습니다.
[ec2-user@ip-10-0-2-41 ~]$ telnet 10.0.1.24 22
Trying 10.0.1.24...
Connected to 10.0.1.24.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4
2번 VPC에서 1번 VPC로 라우팅이 잘 되는군요.
[ec2-user@ip-10-0-2-41 ~]$ telnet 10.0.3.62 22
Trying 10.0.3.62...
Connected to 10.0.3.62.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4
마찬가지로 2번 VPC에서 3번 VPC로도 라우팅이 잘 되는걸 확인할 수 있습니다.
정리
물론 이 기능에도 몇가지 수치상 Limit이 있습니다.
- Total number of transit gateway attachments per Region per account: 5,000
- Number of transit gateways per Region per account: 5
- Number of transit gateway attachments per VPC: 5
- Number of transit gateway route tables per transit gateway: 20
- Number of routes per transit gateway route table: 10,000
- Maximum bandwidth per VPN connection: 1.25 Gbps
- Maximum bandwidth (burst) per VPC connection: 50 Gbps
이런 제약사항은 언제든지 변경될 수 있으니.
공식 문서를 항상 참조하시구요.
공식문서를 잘 살펴보시면 이 Transit G/W 객체 단위로 제공하는 CloudWatch 메트릭 목록도 확인하실 수 있습니다.
잘 생각해보면. 여러개의 Transit G/W를 만들고. 연동이 필요한 그룹끼리 각각 클러스터를 묶는것도 가능하겠네요.
덧붙여 타 계정의 Transit G/W를 참조하려면. '18/12에 발표된 Resource Access Manager (RAM)의 공유 기능을 활용할 수 있습니다.
마지막으로 과금은 각 Connection당 시간-과금, 경유하는 Data Transfer 누적용량-과금 2가지 요소가 있습니다.
글이 너무 길어졌네요. 상세 내용은 AWS가 제공하는 각종 소개자료를 참고하시기 바랍니다.
마칩니다. 끝!
