[catarie] AWS 서비스 정리

글 목적

https://sihanni.tistory.com/258

[Catarie] 회고

지난번에 Catarie 서비스 종료를 하고 아직 정리를 하지 못한 aws 서비스를 정리하며 VPC 구성을 복기하는 글입니다.

---

VPC

Catarie의 VPC(Virtual Private Cloud) 구조

VPC는 AWS 클라우드 서비스 내에서 사용자가 정의하는 논리적으로 분리된 가상 네트워크입니다. IP 주소 범위, 서브넷, 라우팅 테이블 등을 직접 제어할 수 있습니다. 이 VPC는 AWS 리소스(EC2, RDS 등)가 실행되는 가장 기본적인 격리 환경입니다.

 

Catarie의 VPC 내에는 2개의 public 서브넷과 2개의 private 서브넷으로 총 4개의 서브넷으로 구성되어 있습니다.

이 서브넷은 VPC 내의 IP 주소 범위 세그먼트로, VPC 내의 리소스를 가용 영역(Availability Zone) 별로 격리하고 조직화합니다.

 

서브넷이 각각 종류별로 2개씩 구성된 이유는 일반적인 아키텍처 패턴으로 보안과 기능 분리, 안정성과 고가용성, 인터넷 접근성이라는 목적에 있습니다.

• 보안과 기능 분리
  • Pubilc Subnet : 인터넷 게이트웨이(IGW)로 가는 경로가 라우팅 테이블에 있어 인터넷 통신이 가능한 서브넷입니다.
    외부(인터넷)와의 통신을 위한 접근 점을 제공하여 외부 트래픽을 허용하지만 핵심 데이터를 주로 저장하진 않습니다.
    프론트엔드 웹서버, 로드 밸런서 등이 배치되게 됩니다.
  • Private Subnet : 인터넷 게이트웨이로 가는 경로가 없어 인터넷 통신이 불가능한 서브넷입니다. 
    인터넷의 직접적인 접근을 완벽히 차단하고 Public subnet을 통한 간접 접근만 허용하므로 핵심 비즈니스 로직 및 데이터 저장을 하는 백엔드 애플리케이션 서버, 캐시 서버, 데이터베이스 등이 배치되게 됩니다.
• 안정성과 *고가용성
  • 서비스의 모든 계층(Public, Private)이 최소 두 개의 물리적으로 독립된 데이터 센터에 분산 배치되어 하나의 AZ에 장애가 발생해도 다른 AZ는 정상 작동하여 하나의 서브넷에 장애가 발생하는 문제가 생기더라도 나머지 서브넷의 서버에서 트래픽을 처리하여 서비스 다운 타임을 최소화할 수 있게 됩니다.
• 인터넷 접근성
  • Private Subnet에 있는 서버는 외부에서 접근할 수 없어서 NAT Gateway를 사용하여 트래픽을 IGW로 전달하도록 설정되어, 외부로는 나가지만 외부에서 직접 들어올 수는 없게할 수 있습니다. 이를 통해 AWS의 S3와 같은 다른 서비스를 사용하거나 외부 API 호출이 가능하게 됩니다.

 

그리고 각 서브넷은 private, public 라우팅 테이블로 연결되어있습니다. 라우팅 테이블은 네트워크 트래픽의 경로를 결정하는 규칙들의 집합이며 서브넷에서 발생하는 트래픽을 어디로 보낼지 지정하게 됩니다.

 

인터넷 게이트웨이(IGW)는 VPC와 인터넷 간의 통신을 가능하게 하는 VPC의 컴포넌트로, VPC의 라우팅 테이블이 인터넷으로 향하는 트래픽을 보낼 수 있는 타겟 역할을 하고, 퍼블릭 서브넷 내의 인스턴스에 퍼블릭 IP 주소를 할당 받을 수 있도록 합니다. (탄력적 IP 또는 퍼블릭 IPv4 주소)

 

탄력적 IP (Elastic IP, EIP) 는 AWS 계정에 할당되는 고정적인 퍼블릭 IPv4 주소이며, 인스턴스가 중지되거나 교체되어도 변경되지 않는 공인 IP 주소를 말합니다. 이로 인해 인스턴스의 장애나 변경시에도 서비스 연속성을 유지할 수 있습니다.

 

그리고 로드 밸런서(ALB)를 API 서버 앞단에 위치시켜, Public Subnet에서 들어오는 트래픽을 Private Subnet 내에 위치한 API 서버그룹으로 분산시키고, 자동으로 https 인증서도 관리하도록 하였습니다.

CloudFront

Amazon CloudFront는 AWS에서 제공하는 콘텐츠 전송 네트워크(Content Delivery Network, CDN) 서비스입니다.

전 세계에 분산된 엣지 로케이션 (Edge Locations)이라는 데이터 센터에 콘텐츠를 캐시(복사본 저장)해 두었다가, 사용자가 콘텐츠를 요청하면 가장 가까운 엣지 로케이션에서 콘텐츠를 전달하게 됩니다. 

• 속도 향상 (Latency 감소): 콘텐츠가 사용자 가까이에 있으므로 전송 거리가 짧아져 로딩 속도가 빨라진다.
• 부하 분산: 오리진 서버(S3, Ec2 등 원본 저장소)로 가는 직접적인 요청 수를 줄여 서버 부하를 분산하고 비용을 절감한다.
• 보안:AWS WAF 등 보안 기능을 통합하여 콘텐츠를 보호한다.

배포 (Distribution)은 CloudFront 서비스의 설정 단위로, 하나의 배포에서 원본, 캐싱 규칙, 대체 도메인 등을 지정해주어야합니다.

• 원본(Origin): 캐시할 콘텐츠가 실제로 저장된 위치(S3 버킷, Ec2 인스턴스 등)
• 캐싱 규칙(동작): 어떤 경로 패턴의 요청을 어떻게 처리하고 얼마나 오래 캐시할지 등의 규칙
• 대체 도메인: 사용자가 접근할 사용자 정의 도메인

Catarie의 경우 트랜스코딩 작업이 완료된 .m3u8 파일과 모든 *.ts 세그먼트 파일들이 S3 버킷에 저장되고, 이 버킷은 Catarie의 콘텐츠 원본 저장소(Origin) 역할을 하게 됩니다.

이후 사용자가 Catarie에 요청을 할 때 CDN인 CloudFront의 대체 도메인으로 요청하고, CloudFront는 S3에서 파일을 가져와 엣지 로케이션에 저장(캐시)을 하게 됩니다. 그리고 이후 해당 사용자의 재생기기가 요청하는 수많은 .ts 세그먼트들도 CloudFront를 통해 전송되어 빠르고 안정적인 스트리밍이 가능하게 됩니다.

요청 과정에 대한 더 자세한 정보는 아래 글에 자세히 정리가 되어있습니다.

https://sihanni.tistory.com/88

웹브라우저에 URL을 입력하면 일어나는 일

 

dynamoDB, Lambda, 외부 이메일 발송 서비스

Catarie는 회원가입 과정에서 이메일 인증을 위해 인증코드를 발송합니다.

DynamoDB

DynamoDB 는 트래픽이 급증해도 성능 저하 없이 자동으로 확장되는 AWS의 완전 관리형 서버리스 NoSQL 데이터베이스입니다.

Lambda 역시 사용량에 따라 자동으로 확장(Scale-out)되며, 두 서비스를 함께 사용함으로써 추가적인 인프라 관리를 하지않을 수 있었습니다.

otp_signups 라는 email 파티션 키를 사용하는 인증 코드와 만료 시간을 저장하는 테이블,

otp_rate 라는 key 파티션 키를 사용하는 요청 빈도 제한 (IP주소 별, 이메일 주소별로 요청 횟수 및 쿨다운 시간을 추적)을 사용하였습니다.

 

AWS Lambda

인증 코드를 발송하는 핵심 비즈니스 로직을 담당하는 서버리스 백엔드입니다.

로직을 요약하자면,

1. 요청 검증 : HTTP 메서드, JSON 형식, 이메일 유효성 검사
2. 레이트 리밋 처리 : 이메일 주소을 기반으로 요청 빈도를 DynamoDB(otp_rate)에서 확인하고 제한
3. 코드 생성 및 저장 : 코드 생성 후 보안을 위해 해시처리하여 otp_signups 테이블에 ttl과 함께 저장
4. 메일 발송 : Resend API를 사용하여 사용자에게 인증 코드가 포함된 이메일 전송 
   (사실상 무료 서비스인 resend.com 사용했습니다. AWS의 SES를 사용하려 했지만 서비스에 대한 상세 내용 부족으로 허가에 실패했습니다.)
5. 응답 처리 : CORS 헤더를 포함하여 클라이언트에게 최종 결과를 반환

해당 람다 함수는 사용만하지 않는다면 추가 비용이 없고, 추후에 충분히 재사용이 가능한 함수이므로 굳이 삭제를 통한 정리는 하지 않기로 결정했습니다.

정리하며

최근 서비스를 종료한 Catarie의 AWS 리소스를 정리하며, 단순히 서비스 운영을 넘어 처음에 왜 이렇게 서버 아키텍처를 구성했는지에 대한 근본적인 물음을 저에게 할 수 있는 짧지만 귀중한 시간이었습니다.

당시에는 잘 동작하는 서버를 구축하는 것이 목표였다면, 이번에 서브넷이나 cloudfront 배포등을 다시 살펴보며 보안, 고가용성, 비용 문제를 중심으로 개념을 재확인했고 이 과정에서 부족했던 개념은 더 명확히 할 수 있었고, 다음 서버 아키텍처 구성할 때는 조금 더 나은 구조를 고려할 수 있는 자신감을 얻게 된 것 같습니다. 여러모로 감사하고 재밌었던 프로젝트였습니다.

---

고가용성

서버, 네트워크, 프로그램 등 시스템이 장애 발생 시에도 서비스를 중단하지 않고 거의 100%에 가깝게 지속적으로 운영될 수 있는 능력을 말한다.

고가용성을 확보하는 방법

• 중복성(Redundancy): 여러 구성 요소가 동일한 작업을 수행할 수 있도록 하는 기술입니다. 예를 들어, 서버가 고장 나면 다른 백업 서버가 즉시 그 역할을 대신합니다.
• 장애 조치(Failover): 주 시스템에 장애가 발생하면 자동으로 백업 시스템으로 전환하여 서비스 중단을 최소화합니다.
• 오토 스케일링(Auto-scaling): 시스템의 부하에 따라 컴퓨팅 자원을 동적으로 할당하거나 해제하여 항상 적절한 성능을 유지하도록 합니다.