이번 포스팅은 스푼라디오에서 플랫폼 엔지니어링으로 가기 위한 여정으로 Multi-Account와 Multi-Region을 관리하며 겪었던 경험과 도전, 그리고 그 과정을 공유하는 시리즈의 세번째 글입니다.
소수의 팀에서 발생한 문제를 해결해 나가는 과정에서 마주한 요구사항과 그 해결책을 통해, 비슷한 상황에 처한 다른 기업이나 엔지니어들에게 유용한 인사이트를 제공하고자 합니다. 아래 링크를 통하여 공감대를 형성하고 기술검토에 도움이 되기를 바랍니다.
안녕하세요. SpoonRadio의 SRE팀의 Ash(박민호)입니다.
이전 포스팅에서 개발 조직을 위한 셀프 서비스 시스템을 구축하여 릴리즈과정을 단순화하는 방법을 공유했습니다. 이 과정 덕분에 중복된 작업 과정을 감소시키는데 도움이 되었고 Mutli-Account 관리와 보안 및 규정 준수를 할 수 있도록 시간을 벌 수 있었습니다.
그 다음 단계인 ‘목적에 맞는 Private network routing 과 비용 절감’에 대한 과정을 이야기하고자 합니다.
모니터링을 위한 데이터 전송 요금
첫 시작은 모니터링으로 사용하고 있던 Datadog에서 발생한 예상치 못한 OutBound 트래픽 비용이었습니다. AWS의 Multi-Region에 여러 서비스를 운영하고 있는데 Virginia Region에 위치한 Datadog으로 데이터를 전송하는 과정에서 데이터 전송 비용이 발생하였습니다.
AWS의 데이터 전송 과금 정책은 Source에서 발생한 트래픽을 기준으로 발생할 뿐만 아니라 NAT 게이트웨이를 통한 데이터 요금까지 포함됩니다. 이때문에 데이터 전송 비용을 무시할 수 없는 수준의 명세서를 받게 되었습니다.
Datadog은 Log, Trace, Metric 등의 데이터를 보내면서 매분 약 250MB의 트래픽이 발생했습니다. 이런 데이터 전송량은 한 달에 약 $1,500의 추가 비용을 발생시켰고 이 비용은 도입 당시에 예상치 못한 부분이었습니다.
비용 문제를 해결하기 위해 Datadog의 AWS PrivateLink*를 활용하는 방안을 검토하였습니다. AWS PrivateLink를 이용한다면 내부 네트워크 통신을 가능하게 해주어 NAT 게이트웨이를 통한 데이터 전송으로 인한 비용을 줄일 수 있다는 가능성을 보았습니다.
AWS Cloud WAN
Datadog은 Virginia Region에 위치하고 있어 Multi-Region, Multi-Account 환경에서 발생하는 지표 데이터를 내부 네트워크를 통해 Virginia Region의 AWS PrivateLink로 전송하도록 구성해야 했습니다. 네트워크 통합에 대한 요구 조건을 충족시키기 위해 다음과 같은 기준을 설정했습니다.
- 확장성: 다수의 VPC와 서비스가 글로벌하게 분포되어 있으므로, 확장성 있는 솔루션을 필요로 합니다.
- Multi-Region 지원: Multi-Region에 걸쳐 있는 서비스 간의 원활한 데이터 교환을 지원해야 합니다.
- 관리의 용이성: 네트워크 구성 및 유지보수의 복잡성을 최소화하며, 소규모 팀도 효과적으로 관리할 수 있는 구조를 요구합니다.
위와같은 요구사항으로 VPC Peering과 Transit Gateway를 검토하였지만 다음과 같은 이유로 부합하지 않다는 것으로 결론지었습니다.
VPC Peering
VPC Peering은 두 개의 VPC 간에 네트워크 연결을 가능하게 하는 AWS의 서비스입니다. 하지만 1:1 연결 기반의 설계는 대규모 환경에서의 확장성과 Multi-Region 지원이라는 우리의 요구 사항을 만족시키지 못하였습다. 각각의 VPC를 개별적으로 연결해야 하는 구조는 VPC가 증가될 수록 관리의 복잡성을 증가시키고 특히 Multi-Region을 지원하지 않다는 점에 적합하지 않았습니다.
Transit Gateway
VPC 및 on-premise 네트워크를 단일 게이트웨이를 통해 연결하여 관리할 수 있게 해줍니다. 이를 통해 사용자는 복잡한 네트워크 간소화를 가능하게 하고 중앙 집중식 라우팅을 통해 네트워크 관리를 용이하게 할 수 있습니다. 확장성이 뛰어나고 다양한 네트워킹 시나리오를 지원한다는 강력한 장점이 있지만 각 연결 설정이 수동으로 이뤄져야 한다는 단점이 있습니다. 대규모 네트워크 환경에서는 이러한 설정이 관리와 유지보수 측면에서 운영난이도가 올라가 소수의 인력으로 관리하기에는 매우 복잡한 서비스입니다.
여럿 서비스를 검토하는 과정에서 트래픽을 중앙에서 효율적으로 라우팅할 수 있는 AWS Cloud WAN이 가시권으로 들어오게되었습니다. 여러 VPC를 AWS Cloud WAN에 연결만 하고 라우팅을 돌려주도록 하는 Core network policies*을 조작한다면 Multi VPC간 통신을 조절 할 수가 있습니다.
AWS Cloud WAN의 Network Policy
AWS Cloud WAN은 RouteTable을 조작하는게 아닌 Segments간의 연결로 경로를 조절합니다. 하나의 Segments에는 여러 Attachment를 등록하고 각 Attachment는 VPC, Transit Gateway, VPN등 여러가지 리소스를 칭합니다. 하나의 Segments를 다른 한쪽의 Segments와 공유(share)하도록 구성을 하면 양쪽의 Segments에 대한 라우팅 정책은 완료가 됩니다. 나머지는 각 Attachment의 RouteTable의 정책대로만 네트워크가 흐르게됩니다.
이런 방식으로 Datadog을 사용하는 모든 VPC를 하나의 Segment로 구성하고 Core Network로 연결했습니다. Core Network의 라우팅 정책으로 Datadog의 AWS PrivateLink로 직접 라우팅되도록 구성하였습니다. 이 구성 덕분에, Multi Region 환경에서도 NAT Gateway를 사용하지 않고 Datadog 서비스에 효율적으로 접근할 수 있는 환경을 구축할 수 있었습니다.
Supernetting
다수의 VPC를 Core Network에 연결하는 과정인 Segment 구성 과정에서 일부 환경에서 IP 주소 범위가 겹치는 문제가 발생했습니다. 초기 설계 단계에서 Subnet mask를 충분히 고려하지 않고 사용 유무만을 기준으로 구성하다 보니 더 넓은 범위를 사용하는 것이 어려워졌습니다. 이로 인해 라우팅 규칙을 구성할 때 좁은 대역을 대량으로 설정해하는 상황이 생겼습니다.
좁은 IP range를 넣었다고 사용하지 못하진 않았지만 24bit 14개보다는 16bit 1개로 구성하는것이 설정이 간단하다고 판단하여 IP Range를 재정렬하기로 결정했습니다. 그래서 IP 주소 범위 충돌 문제를 해결하고, 네트워크 설계의 효율성을 개선할 수 있었습니다.
적극적인 사용
Datadog AWS PrivateLink로 인하여 NAT Gateway 비용을 줄일 수 있었지만 여전히 AWS Cloud WAN의 서비스 자체의 금액적인 유지 비용이 높다는 문제가 있었습니다. 그래서 이 서비스를 더욱 더 활용하기위해 보안적인 측면을 강화하고 안정성을 높이는 동시에 비용 절감까지 고려한 방법으로 다음 스탭을 준비하였습니다.
중복 서비스 병합
각 지역마다 서로 다른 서비스라는 이유로 동일한 운영 도구를 중복으로 설치하여 최소한의 서비스를 유지하고 있었습니다. 운영 도구의 사용률은 그리 높지 않았지만 최소한의 서비스를 위해 구성하다보니 평상시에는 낭비가 발생하고 있었습니다. 일부 도구는 유료 솔루션을 사용함으로써 라이센스 비용까지 중복으로 발생하는 문제도 있었습니다.
AWS Cloud WAN의 도입으로 내부 통신이 가능한 환경을 구축함으로써, 우리는 여러 지역에 분산된 운영 자원을 통합할 수 있었습니다. 이로 인해, 인프라 배포가 더욱 간소화되어 유지보수 비용이 줄어드는 효과를 볼수가 있었습니다.
사내망과 연결
사내에서 데이터 분석을 위해 on-premise 환경을 구축하여 사용하고 있습니다. 분석에 필요한 데이터는 AWS S3에서 데이터를 가져오며 처리된 데이터를 다시 업로드하는 과정에서 트래픽 비용이 발생합니다. 또한 데이터 전송은 인터넷을 통해 흐르기 때문에 보안상의 취약점이 발생할 위험이 있었습니다.
이러한 문제를 해결하기 위해 on-premise 환경과 AWS Cloud WAN을 site-to-site 으로 연결함으로써 터널링 환경을 구축하였습니다. 사내 방화벽에서 정책을 적용하여 VPN 없이도 안전하게 AWS 리소스에 내부에서 접근할 수 있는 환경을 마련하였습니다.
보안이 강화된 DB 접근제어 서비스
Database 접근제어 서비스는 보안 요구 사항을 충족하는 환경 사용할 수 있도록 구성하였습니다. 서비스 접근을 위한 환경은 높은 수준의 보안을 필요로 하기에 VPN, Appstream 등 복잡한 환경이 구성하였습니다. 이 지점에 AWS Cloud WAN을 활용하여 기존에 복잡하게 관리되던 관계 시스템의 필요성을 대폭 줄일 수 있었습니다. 전체적인 네트워크 보안 구조를 유지하면서 관리의 복잡성을 줄이고 보안 위협에 대한 노출을 최소화하는 데 도움이 되었습니다.
모니터링의 한계점
위와 같이 AWS Cloud WAN은 네트워크 통합에 대한 요구 조건을 충족한 서비스로 검토가 되었습니다. 하지만 서비스의 안전성과 유지보수를 위한 모니터링 지표의 부족은 주요 단점 중 하나입니다. 특히 종단간 모니터링을 위한 환경을 제공하고 있지 않습니다.
복잡하게 얽힌 Segments와 Attachment라는 낯선 환경속에서 유지보수를 진행하게 될 경우 모든 인프라를 확인 할 수가 없습니다. 운영 트래픽은 서비스 트래픽에 비해 중요도가 낮아 알람에 대한 우선순위가 낮게 측정되어있습니다. 이로 인해 변경 사항에 따른 장애를 즉시 알기 어려워, 운영 서비스의 이슈를 넘어 AWS Cloud WAN의 관점에서도 접근해야 합니다.
현재 AWS Cloud WAN은 사용량에 대한 기본적인 지표만 제공하고 있으며, 각 환경에서 서비스가 안정적으로 운영되고 있는지에 대한 세부적인 모니터링 도구를 제공하지 않습니다.
AWS Cloud WAN은 출시된 지 약 2년밖에 되지 않은 상대적으로 새로운 서비스로, 국내에서는 선제적으로 도입하여 사용하는 경우이며, 또한 관련해서 글로벌하게 기능개선 요청을 받고있는 서비스입니다. 앞으로 AWS는 Cloud WAN의 모니터링 기능을 강화하여, 사용자가 네트워크의 성능과 안정성을 보다 정밀하게 관리하고, 잠재적인 문제를 사전에 식별할 수 있도록 지원하는 기능을 추가할 필요가 있어보입니다.
이러한 단점을 극복하기 위해 별도의 모니터링 도구를 활용하고 있습니다. 서비스 트래픽과 별개로 모니터링 전용 트래픽을 의도적으로 발생시켜 서비스의 안전성과 성능을 지속적으로 수집하여 검증하고 있습니다.
마치며
이번 포스팅을 통하여 Multi-Region과 Multi-Account 환경에서 AWS Cloud WAN을 활용한 네트워크 통합 과정을 어떻게 하였는지 소개하였습니다. 서로 다른 네트워크 환경에서 네트워크 라우팅을 손쉽게 컨트롤 할 수 있는 환경을 구성 할 수 있었으며 그 덕분에 관리의 복잡성을 낮추고 보안을 강화하는데 도움이 되었습니다.
하지만 네트워크에 유지를위한 단가가 비싼 서비스임을 잊지말아야 합니다. Global Region으로 서비스하는 특성상 서비스에 쓰일 Edge(Region)를 추가할때마다 비용이 증가합니다.* 검토부터 도입까지 기존의 네트워크인프라를 파악하고 개선해야 할 점을 면밀히 파악하여 비용이 낭비되지 않도록 고집해야합니다.
