안녕하십니까. 최근에 AWS 관리 콘솔에서 ELB를 새로 생성할때 뭔가 달라진 부분이 없으셨나요? 특히 미주쪽 리전에서 생성해보셨다면 뭔가 달라진 부분이 분명 있을겁니다. ELB의 유형을 선택하는 첫 화면에 기존에는 ALB, NLB, 그리고 예전세대인 CLB가 있었는데요. 최근에 Gateway LB라는 친구가 하나 더 생겼습니다. 오늘은 이 친구가 어떤 역할을 하는 LB인지.. 보안 계층을 구성하는 통시적인 관점에서 살펴보도록 하겠습니다.

이야기는 아주 예전으로 거슬러 올라갑니다. AWS의 VPC 환경에서 "IDS/IPS/UTM 같은 보안 계층을 어느 위치에 배치해야 하느냐"를 두고 여러가지 방법론이 있었는데요. 레거시의 관점과 동일한 Gateway 방식과, 동적으로 자원이 빈번하게 바뀌는 환경에 적합한 Agent(Hosted) 방식이 있었죠. 여타 클라우드 서비스와 마찬가지로 이건 정답이 있다기보다, 각자의 환경과 요구사항에 맞춰 최선을 취하는 방식이기 때문에 누구는 Gateway 방식을 또 다른 누구는 Agent 방식을 사용해왔습니다.

Gateway 방식은 전통적인 방식과 비슷해서 인터페이스가 친숙하고 중앙관리가 쉽다는 장점이 있었지만, 해당 계층의 가용성과 탄력성을 구현하기 어렵다는 단점도 있었습니다. 특히 가상화된 네트워크 환경에서 "해당 Gateway가 구성된 VM의 장애"가 결국 "전체 서비스 장애"로 이어진다는 취약점을 피할 수 없었죠. 이런 제약사항을 기술적으로 극복할 수 없거나 서비스 연속성 관점에서 용인할 수 없어서 Agent 방식을 사용하는 곳도 꽤나 많았습니다.

AWS도 이런 부분을 잘 알고 있었기 때문에, 이를 해결하기 위한 다양한 방법을 고민해온것 같습니다. 오늘 소개해드릴 Gateway LB도 그 연장선상에 있구요. 그럼 지금부터 내가 Gateway 형태의 보안 장비(3rd-Party)를 사용한다고 가정하고 그간 적용할 수 있는 여러 구성요소들이 어떻게 변화해 왔는지 4단계로 나눠서 살펴보도록 하겠습니다.

자, Lv1입니다. VPC가 하나 있구요. 맨 앞단에 UTM이 있네요. MarketPlace에서 제품을 하나 골라서 EC2로 배포했습니다. 서비스 도메인은 해당 인스턴스의 공인IP로 매핑했구요. 외부 사용자의 요청은 해당 UTM을 거쳐 백엔드에 도달하게 됩니다. 백엔드에서 인터넷 구간으로 트래픽이 나갈때도 UTM을 경유하도록 VPC의 Route Table을 설정하고, 이 과정에서 URL Whitelisting 처리를 하거나 기타 보안 제어기능을 활용할 수 있었습니다.

그렇다면 우리는 이 구성에서 무엇을 더 고려해야 할까요? 맞습니다. 가용성. 어느 계층의 가용성? UTM이 구성된 계층의 가용성이죠. 저 계층이 무너지면 모든것이 무너지는 셈입니다. 유사시 트래픽을 Transparent하게 뒤로 흘릴 수도 없는 노릇이구요. 단순히 가용성 뿐만이 아니라 전체적이 트래픽 규모가 늘어났을때 해당 계층의 자원을 늘리고 클러스터링을 할 수 없는 부분도 문제입니다. 그렇게 되면 해당 구간의 성능이 결국 서비스 전체의 병목 요소로 작용할 수 있습니다.

​이번엔 Lv2입니다. 무엇이 바뀌었죠? 가용성을 높이기 위해 이중화가 되었네요. 해당 보안 계층을 Active-Active 또는 Active-Standby 구조로 구성할 수가 있습니다. A-A 구조에서는 서비스 끝점을 하나로 모으기 위해 보통 앞에 ELB를 하나 더 붙여주고요. A-S 구조에서는 Active 계층의 Health Check에 이상이 생겼을때, 서비스 끝점주소를 Standby쪽으로 변경하고 백엔드가 위치한 Subnet의 Route Table을 Standby 인스턴스쪽으로 변경해주는 로직이 추가되었습니다. 이런 부분은 AWS API를 써야 하기 때문에 보통 3rd-Party쪽 Application에 사전에 관련 IAM 권한을 추가하도록 되어 있었구요.

이 구성에서는 여전히 VPC에서 VPC 내부로 들어오는 트래픽의 끝점은 해당 보안 계층 인스턴스의 공인IP가 됩니다. 만일 On-Prem쪽에 VPN 연결을 통해 뭔가 요청이 들어온다면 어떻게 될까요? 혹시 IGW나 VGW같은 가상의 Gateway 계층을 거쳐 트래픽이 오갈때.. 강제로 저런 보안 계층을 지나가도록 이정표를 세워줄 수는 없을까요? 그래서 나온 VPC 기능이 있었으니, 이를 VPC Ingress Routing이라고 합니다.

​이번엔 Lv3입니다. 사실 Ingress Routing 기능은 Lv3 라기 보다는 Lv1이나 Lv2에서 좀 더 유연하게 라우팅을 해줄수 있는 보충 기능이라고 이해하는 것이 더 정확합니다. Internet G/W나 Virtual Private G/W에 라우팅을 넣어줄 수 있는 기능이구요. 이 부분의 Destination 주소에 보안 계층의 eni값을 넣어줌으로써, 특정 백엔드의 주소로 향하는 트래픽을 보안계층으로 넘어갈 수 있게끔 강제할 수 있습니다. 

자, 그래서 Lv1부터 Lv2/3까지 Gateway형 보안계층 구성 방식의 흐름에 대해 짧게 살펴봤습니다. 어떤게 떠오르시나요? 여전히 문제되는 부분은 없을까요? 가용성 이슈는 해결된걸까요? 만일 해결되지 않았다면 그건 VPC의 제약사항일까요? 아님 3rd-Party의 제약사항일까요? 이런것들을 한번 쭉 생각하고 나서, 결국 답을 AWS가 줘야될것 같은데.. 라는 결론을 내셨다면 그 답이 오늘 소개해드릴 Gateway LB가 될지도 모르겠습니다.

이 그림은 새로나온 Gateway LB의 구성도입니다. 이 그림을 이해하기 위해서는 직접 구성을 해보는게 가장 빠릅니다. 다만 오늘 포스팅에서는 전체 구성까지 보여드릴 수는 없고 전체적인 구성 흐름이 어떻게 흘러가는지까지 설명을 드려볼 생각입니다. 그럼 왜 AWS가 이런 타입의 LB를 새로 만들었는지를 이해할 수 있을거에요. 먼저 위 그림을 1분 정도 지긋이 바라보시고 나서 아래 글을 읽어주시기 바랍니다.

1단계. 보안 계층의 EC2를 구성합니다. 물론 Application을 새로 설치할 수도 있지만, 굳이 그럴 필요는 없습니다. 이미 Marketplace에 이미지가 준비되어 있으니까요. 원하는 회사의 제품을 골라서 원하는 VPC의 원하는 Subnet에 새로운 EC2 인스턴스를 구성합니다. 저 위에 있는 그림 중 우측에 있는 인스턴스라고 보시면 됩니다. 이 EC2 인스턴스로 어떻게 트래픽을 흘릴지에 대해서는 뒤에서 고민합시다.

2단계. Gateway LB를 만듭니다. 그리고 뒤에 Target Group을 연결하고, 해당 Target Group에 1단계에서 만든 보안계층의 EC2 인스턴스를 바인딩합니다. 마치 웹서버 앞에 LB를 두는것처럼 동일하게 구성하시면 됩니다. 그럼 LB에서는 같은 역할을 합니다. 앞단에서 요청 끝점을 한군데로 모아주고, 백엔드에 있는 대상을 헬스체크해서 멀쩡한 애들에게만 요청을 나눠주는 로직을 수행합니다. 서비스 트래픽을 어떻게 이 LB를 거쳐 백엔드로 흘릴지는 뒤에서 고민합시다.

3단계. Gateway LB Endpoint라는 것을 만듭니다. 이건 Lv1/2/3에서 구성했던 보안 계층의 EC2 인스턴스와 같은 지점이라고 이해하시면 됩니다. 기존에는 EC2 인스턴스로 구성했던 지점을 Gateway LB Endpoint라고 하는 가상의 계층으로 대체하는 개념입니다. 이 Endpoint에 도달하는 요청은 어디로 갈까요? 네 맞습니다. 2단계에서 만들었던 Gateway LB로 갑니다. 그리고 이 LB를 거쳐서 백엔드의 보안 계층으로 전달되는 흐름입니다.

4단계. 이제 VPC로 들어오고 나가는 트래픽이 Gateway LB Endpoint를 반드시 지나가도록 하고 싶습니다. 어떻게 해야 할까요? Lv3에서 소개드렸던 VPC Ingress Routing 기능이 생각나시나요? 요 기능을 활용하여 Destination의 Next hop을 GWLB Endpoint로 지정해주시면 됩니다. GWLB의 Endpoint를 AZ마다 하나씩 구성하셨다면 각 AZ에 위치한 Endpoint로 각기 할당해주시면 되겠죠.

자, 이제 구성이 완료되었습니다. 무엇이 달라졌을까요? 먼저 이 구성의 가장 큰 장점은 보안 계층의 인스턴스를 좀 더 탄력적으로 조정할 수 있다는 것입니다. 수평적으로 인스턴스를 확장할수도 있고 축소할 수도 있습니다. 왜냐하면 서비스 트래픽이 들어오는 지점은 GWLB의 Endpoint로 대체되었고, 그 지점을 거쳐 Gateway LB로 요청이 넘어오기 때문에. 실제 패킷이 유입되는 앞단 주소를 변경할 필요가 없기 때문입니다.

물론 복수개의 보안 계층이 구성되었을때.. 그리고 이것들이 동적으로 변경되었을때, 정책을 Sync하거나 로그를 한곳에 모아주는 로직이 필요할 수 있습니다. 이건 아마 3rd-Party 업체에서 이미 구현했거나 고민해야 될 문제구요. 최소한 VPC 구성상에서는 이제 가용성이나 탄력성을 따로 고민할 필요가 없다는 것이 가장 큰 미덕 아닐까요? 한가지 유의할 부분은 제가 글을 작성하고 있는 20년 12월 기준으로 Gateway LB는 아직 서울 리전에 런칭이 되지 않았습니다. 좀 더 자세한 내용을 알고싶으시면 아래 링크를 참고하시구요. 그럼 마칩니다. 끝!

https://aws.amazon.com/ko/blogs/aws/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/