[Ticketing] 인프라 아키텍처 설계 및 구축

프로젝트의 전체 그림을 설계하고 AWS를 활용해 배포한 내용을 서술합니다.

 

전체 그림을 살펴보고 세부적인 내용을 살펴보겠습니다. 

전체 구조

가장 큰 특징은 개발자의 인프라 관리 포인트를 최소화한 *서버리스 아키텍처*라고 말씀드릴 수 있습니다.

 

1. Frontend

Frontend 흐름

 

- Web Hosting

웹 서버를 호스팅하는 다양한 방식이 있지만, 인스턴스를 직접 사용하지 않고 AWS CloudFront + S3 Web Hosting을 사용한 이유는 다음과 같습니다.

1. 관리 포인트 최소화 : 표면적으로 S3는 객체 스토리지 입니다. 정적 파일(.html)을 업로드하고 해당 버킷을 Web Hosting으로 동작시키면 개발자가 직접 nginx와 같은 웹 서버를 관리할 필요가 없습니다. 
2. 높은 가용성 : 트래픽이 순간적으로 급증하는 상황에서 웹 서버를 직접 인스턴스에서 다룬다면, 로드 밸런싱 및 스케일 아웃 등 추가적인 조정 정책이 필요할 것입니다. S3는 연간 99.99%의 응답 가능성을 보증합니다. 이는 연간 약 9시간 미만의 다운타임이 발생할 수 있다는 것을 의미합니다. 여기에 CloudFront를 더해, 글로벌 캐싱 전략으로 부하 분산을 구현할 수 있습니다. 

 

반면 CloudFront의 단점도 존재했습니다.

S3 버킷 내 코드가 재배포 되었을 때, 이전 객체를 CloudFront에서 캐싱하고 있다면 여전히 이전 버전의 View를 사용자는 볼 수 밖에 없습니다.

물론 TTL 정책으로 일정 시간이 지나면 자동으로 가능하겠지만, 재배포가 이뤄진 후에는 즉각적인 캐시 무효화가 필요하다고 생각했습니다.

 

CloudFront는 관련된 기능으로 캐시 무효화를 지원합니다.

CloudFront의 캐시 무효화

다만 위 사진의 작업은 수동으로 이뤄지기에, S3 버킷 객체 업로드를 트리거로 잡아 무효화를 생성하는 일련의 과정을 추가해야할 것으로 판단됩니다.

 

 

2. Backend

Backend 흐름

 

- API Gateway & Lambda Authorizer

API Gateway는 클라이언트 측 모든 요청의 단일 진입 지점입니다. API 요청을 한 곳에서 관리가 가능합니다.

AWS API Gateway는 내구성이 뛰어나며, 단순 라우팅 기능을 넘어서 트래픽 모니터링 등 다양한 기능을 지원합니다.

또한 클라이언트 입장에서는 https를 지원하는 API Gateway와 통신하는 것이기에, CORS 정책 때문에 백엔드 단까지 억지로 https 설정을 해줄 필요가 없습니다.

 

Lambda Authorizer은 요청이 넘어가기 전 미리 JWT를 통해 적절한 권한을 가지고 있는지 판단하게 됩니다. 

Lambda Authorizer의 경우 Java를 사용하면 Cold Start 시간이 길기 때문에, Node.js를 활용해 개발했습니다.

 

참고:

https://dong-woo.tistory.com/entry/Ticketing-AWS-Lambda-%EA%B6%8C%ED%95%9C-%EB%B6%80%EC%97%AC%EC%9E%90%EB%A1%9C-%EC%9D%B8%EC%A6%9D-%EC%84%9C%EB%B2%84-%EA%B0%9C%EB%B0%9C%ED%95%98%EA%B8%B0

[Ticketing] AWS Lambda Authorizer를 활용한 인가 서버 개발

 

- Application Load Balancer

실제 호출되는 WAS는 ECS 클러스터 내 서비스 레벨로 존재하기에, 트래픽에 따라 컨테이너가 자동으로 확장/축소되는 상황에서 해당 서비스에 대한 디스커버리 전략이 필요했습니다.

 

이에 대응해 ALB를 API Gateway와 ECS 클러스터 사이에 배치시켜 문제를 해결하기로 했습니다.

ALB의 타겟 그룹으로 ECS 서비스를 등록함으로써, 서비스 내 여러 컨테이너에 대해 로드 밸런싱이 가능했으며 서비스 디스커버리를 구현할 수 있었습니다.

 

- ECS + Fargate

백엔드 서버를 띄우는데도 여러가지 옵션이 있었는데요, AWS ECS를 활용해 얻은 이점은 다음과 같습니다.

1. 관리 포인트 최소화 : Fargate를 사용해 컨테이너를 띄움으로써 개발자가 직접 인스턴스를 관리하지 않아도 됩니다.
2. 자유로운 스케일링 : 트래픽을 유연하게 대처하는 것이 중요하다고 생각했는데, 최소 컨테이너 수 및 최대 컨테이너 수를 지정하고 다양한 시스템 매트릭(CPU, Memory)를 기반으로 조정 정책을 간단히 설정해 스케일링을 구현할 수 있었습니다.

물론 VM 레벨에서도 오토 스케일링이 가능하지만, 저는 컨테이너 레벨로 스케일링 하는것이 더욱 가볍고 필요한 만큼 확장/축소 된다고 생각해 WAS를 컨테이너로 배포했습니다.

 

 

3. CI/CD

프론트엔드와 백엔드 배포를 자동화하기 위해서 Git Actions와 AWS CodeBuild를 활용했습니다.

자세한 내용은 아래의 포스팅에서 확인하실 수 있습니다.

 

참고:

https://dong-woo.tistory.com/entry/Ticketing-FEBE-%EC%9E%90%EB%8F%99%ED%99%94%EB%90%9C-%EB%B0%B0%ED%8F%AC-%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

[Ticketing] Git Actions와 AWS CodePipeline을 활용한 자동화된 배포 파이프라인 구축