[클라우드 활용 사례 #2] 빗썸: AWS 중앙화된 VPC 엔드포인트 구축을 통한 보안 강화 및 효율성 증대

이번 글에서는 대한민국 주요 가상자산 거래소인 빗썸(Bithumb)이 **AWS(Amazon Web Services) 인프라를 최적화하기 위해 중앙화된 AWS 서비스 엔드포인트 아키텍처를 어떻게 구현했는지** 실무적인 관점에서 분석합니다. 이로써 빗썸은 비용 및 관리 효율성을 향상시키고, 수많은 VPC(Virtual Private Cloud)와 AWS 서비스 간의 안전하고 효율적인 통신 환경을 구축했습니다.

---

목차

• 1. 빗썸의 초기 인프라 과제: 분산된 VPC 엔드포인트의 한계
• 2. 중앙화된 VPC 엔드포인트 아키텍처 도입
• 3. 중앙화 아키텍처의 주요 이점 분석
• 4. 고려사항 및 아키텍처 선택 시 중요 요소

---

1. 빗썸의 초기 인프라 과제: 분산된 VPC 엔드포인트의 한계

국내 주요 가상자산 거래소인 빗썸은 비즈니스 확장에 따라 AWS 상에서 운영되는 VPC의 수와 연동해야 할 AWS 서비스의 수가 기하급수적으로 증가했습니다. 초기에는 각 VPC마다 필요한 AWS 서비스 엔드포인트(Service Endpoint)를 개별적으로 생성하고 관리하는 방식을 사용했습니다. 이는 서비스 간 트래픽이 인터넷을 거치지 않고 AWS 내부 네트워크를 통해 안전하게 전달되도록 하는 AWS PrivateLink의 이점을 활용하는 방식이었습니다.

하지만 이러한 분산된 관리 방식은 몇 가지 심각한 과제를 야기했습니다.

• 복잡성 증가: 수많은 VPC에 개별 엔드포인트를 구성하면서 관리의 복잡성이 기하급수적으로 늘어났습니다.
• 운영 비용 상승: 각 VPC마다 동일한 엔드포인트를 생성하는 것은 중복 투자를 의미하며, 비용 효율적이지 못했습니다.
• IP 주소 고갈 문제: 특히 프라이빗 서브넷에서 인터페이스 엔드포인트를 위한 IP 주소 할당은 스포크(Spoke) VPC 내 IP 주소 고갈 문제를 가속화할 수 있었습니다.
• 일관성 유지의 어려움: 보안 그룹 및 DNS 설정 등을 각 VPC에서 개별적으로 관리해야 했기 때문에, 전체 인프라의 일관된 보안 정책 및 운영 표준을 유지하기 어려웠습니다.

빗썸은 이러한 문제들을 해결하고 더 나은 확장성 및 관리 효율성을 확보하기 위한 새로운 아키텍처를 모색하게 되었습니다.

---

2. 중앙화된 VPC 엔드포인트 아키텍처 도입

빗썸은 앞서 언급된 과제들을 해결하기 위해 **중앙화된 AWS 서비스 엔드포인트 아키텍처**를 채택했습니다. 이는 일반적으로 허브-앤-스포크(Hub-and-Spoke) 모델을 기반으로 합니다.

핵심 구성 요소는 다음과 같습니다.

• 중앙 허브 VPC 생성: 모든 AWS 서비스 엔드포인트(Interface Endpoints)를 통합하여 관리할 단일 중앙 허브 VPC를 구축했습니다. SSM 등 자주 사용되는 AWS 서비스에 대한 인터페이스 엔드포인트가 이 허브 VPC에 집중적으로 배포됩니다.
• AWS Transit Gateway 활용: 허브 VPC와 분산된 다수의 스포크 VPC(개별 서비스 VPC)들을 효율적으로 연결하기 위해 AWS Transit Gateway를 사용했습니다. Transit Gateway는 수많은 VPC 간의 네트워크 연결을 간소화하고 중앙 집중식 라우팅을 가능하게 합니다.
• DNS 규칙 및 라우팅 설정: 스포크 VPC의 애플리케이션이 AWS 서비스에 접근할 때, 인터넷을 통해 통신하는 대신 허브 VPC의 프라이빗 IP 주소를 통해 엔드포인트에 접속하도록 DNS 규칙을 설정했습니다. 이를 위해 Route 53 Resolver 등의 서비스가 활용될 수 있습니다. 이렇게 함으로써 모든 트래픽이 안전하게 AWS 내부 네트워크를 통해 중앙 허브 VPC를 경유하게 됩니다.

이러한 중앙화된 아키텍처는 빗썸이 AWS PrivateLink의 보안 이점을 유지하면서도, 복잡성과 비용 문제를 동시에 해결할 수 있는 기반을 제공했습니다.

---

3. 중앙화 아키텍처의 주요 이점 분석

빗썸이 중앙화된 VPC 엔드포인트 아키텍처를 도입함으로써 얻은 구체적인 이점들은 다음과 같습니다.

• 비용 절감: 각 스포크 VPC마다 개별적으로 생성해야 했던 Interface Endpoint의 수를 획기적으로 줄여, 관련 비용을 크게 절감할 수 있었습니다.
• 운영 효율성 향상: 보안 그룹, DNS 설정 등 엔드포인트 관련 모든 구성을 중앙 허브 VPC에서 일괄적으로 관리할 수 있게 되어 운영 복잡성이 감소하고, 관리 포인트가 단일화되었습니다. 이는 인프라 변경 및 문제 해결 시간을 단축시키는 데 기여합니다.
• IP 주소 고갈 문제 해결: 스포크 VPC 내에 별도의 인터페이스 엔드포인트를 위한 IP 주소를 할당할 필요가 없어지면서, 스포크 VPC의 IP 주소 고갈 문제를 효과적으로 해결했습니다.
• 보안 강화: 모든 서비스 트래픽이 중앙 허브를 경유하면서 일관된 네트워크 보안 정책을 적용하고 모니터링하기가 용이해졌습니다. 인터넷 노출 없이 AWS 내부에서만 통신하므로 보안 취약점이 줄어듭니다.
• 확장성 및 모니터링 용이: 새로운 스포크 VPC를 추가할 때마다 엔드포인트를 개별 설정할 필요 없이 Transit Gateway에 연결만 하면 되므로, 아키텍처의 확장성이 크게 향상됩니다. 또한 중앙에서 모든 엔드포인트 트래픽을 모니터링하기가 더 쉬워집니다.

이러한 이점들은 빗썸이 대규모 클라우드 인프라를 더욱 효율적이고 안전하게 운영할 수 있는 견고한 기반을 제공했습니다.

---

4. 고려사항 및 아키텍처 선택 시 중요 요소

중앙화된 VPC 엔드포인트 아키텍처는 많은 이점을 제공하지만, 모든 시나리오에 적합한 것은 아닙니다. 빗썸의 사례에서도 언급되었듯이, 다음과 같은 사항들을 고려해야 합니다.

• 고트래픽/저지연 서비스: 매우 높은 트래픽 볼륨을 처리하거나 극도로 낮은 지연 시간을 요구하는 서비스의 경우, 중앙 허브를 경유하는 것이 오히려 성능 병목을 일으킬 수 있습니다. 이러한 서비스에는 개별 스포크 VPC에 엔드포인트를 직접 구성하는 것이 더 적합할 수 있습니다.
• 아키텍처 복잡도: 초기 설정 시 Transit Gateway, 라우팅 테이블, DNS 규칙 등 네트워크 구성에 대한 깊은 이해가 필요할 수 있습니다.

결론적으로, 클라우드 아키텍처를 설계할 때는 서비스의 특성, 트래픽 볼륨, 지연 시간 요구사항, 관리의 복잡성 등 다양한 요소를 종합적으로 고려하여 중앙화된 아키텍처와 분산된 아키텍처 중 최적의 방식을 선택해야 합니다. 빗썸의 사례는 이러한 선택 과정에서 중앙화된 접근 방식이 어떻게 대규모 인프라의 보안과 효율성을 동시에 증대시킬 수 있는지를 잘 보여주는 모범 사례입니다.

---

 

도움이 되셨다면 댓글이나 구독 부탁드립니다! 🙏