.png&blockId=84f2744e-d182-4d6f-87f4-a66e251b2ea9)
배경 및 문제
기존에 저희 서비스의 모든 핵심 구성 요소, 즉 애플리케이션 서버, 클라이언트의 정적 파일, 그리고 MariaDB 서버가 하나의 AWS EC2 인스턴스에서 운영되고 있었습니다. 이러한 구조는 EC2 인스턴스에 문제가 발생할 경우, 전체 서비스가 중단되는 심각한 문제를 야기했습니다.
서버에 문제가 생기면 데이터베이스에 접근할 수 없을 뿐만 아니라, 정적 파일 제공도 중단되어 웹사이트에 오류 메시지조차 표시할 수 없었습니다. 더욱이, 애플리케이션 로그 파일이 모두 해당 인스턴스에 저장되어 있어, 문제의 원인을 파악하는 것이 매우 어려웠습니다.
무엇보다도 트래픽이 급증하는 경우 서비스의 확장성이 제한적이라는 한계점이 있었습니다. 이는 서비스의 성장과 안정성에 큰 장애가 될 수 있는 부분이었습니다.
아키텍처 구조 개선 방안
기존 단일 인스턴스 시스템의 한계를 극복하고 확장성을 강화하기 위해 다음과 같은 구조적 개선을 진행했습니다.
1.
EC2 인스턴스 최적화:
•
중점적으로 애플리케이션 서버와 필수 백그라운드 프로세스만을 EC2 인스턴스에서 운영하도록 변경했습니다. 이는 서버의 부하를 경감시키고, 효율적인 리소스 관리를 가능하게 했습니다.
2.
ALB와 SSL 인증서 관리:
•
ALB(Application Load Balancer)를 도입하여 트래픽 분산이 가능하도록 하였고, ACM(AWS Certificate Manager)을 통해 SSL 인증서 관리를 간소화했습니다.
•
ALB는 또한 Auto Scaling 그룹과 연계될 준비를 하여 미래의 서비스 확장성을 고려했습니다. 추후 Auto Scaling을 적용하여 서비스를 확장하게 된다면 CodeDeploy를 통해 여러 인스턴스에서의 자동화된 배포를 가능하게 할 것입니다.
3.
정적 파일의 S3와 CloudFront 활용:
•
클라이언트 정적 파일은 S3에 저장하고, CloudFront를 통해 효율적으로 전달되도록 했습니다. 이를 통해 원본 객체 보호와 비용 절감을 동시에 달성할 수 있었습니다.
•
CloudFront의 도입은 AWS Shield와 같은 추가적인 보안 솔루션 적용의 기반을 마련할 것으로 기대합니다.
4.
RDS를 통한 데이터베이스 관리:
•
데이터베이스는 Amazon RDS를 사용해 관리하도록 변경했습니다. 애플리케이션 서버와 분리되어 안정적으로 동작하고, 장애 혹은 데이터 안전 사고 발생 시 스냅샷을 통해 신속하게 데이터를 복구할 수 있게 되었습니다.
아키텍처 변경은 단순히 현재의 문제를 해결하는 것뿐만 아니라, 미래의 확장성과 안정성을 고려한 접근이었습니다. 서비스가 성장함에 따라 이러한 기반은 더욱 큰 가치를 발휘할 것이라고 생각합니다.
최종 시스템 구조 (기준: 2024/09/02)
1.
개발 및 배포 프로세스
push 이벤트가 감지되면 GitHub 저장소 내에서 자동화된 워크플로우를 실행합니다.
CI 워크플로우는 모든 브랜치에 적용되고, 빌드 및 테스트를 자동화하여 검증된 소스코드만 공유 브랜치에 병합될 수 있도록 합니다.
CD 워크플로우(server)는 개발과(dev) 운영(main) 브랜치에만 적용되며, CI 워크플로우 이후 이미지를 빌드하여 Dockerhub에 업로드 한 뒤, CodeDeploy를 트리거함으로써 실행됩니다.
서버 인스턴스 안에서 CodeDeploy Agent가 배포 스크립트를 실행하여 이미지를 받고 애플리케이션 서버를 가동시킵니다.
CD 워크플로우(client)에서는 빌드한 클라이언트 정적 파일들을 S3에 업로드 후 CloudFront에 캐시 Invalidate 요청을 보내어 변경사항이 모든 엣지 로케이션에 반영될 수 있도록 합니다.
2.
RDS 인스턴스
RDS는 보안그룹을 통해 애플리케이션 서버 인스턴스에서만 접속할 수 있도록 구성했습니다.
3.
ALB/EC2 인스턴스
EC2 인스턴스는 애플리케이션 서버 이미지를 컨테이너화하여 구동하도록 구성했습니다. 이식성있는 구조로 인해 추후 ALB를 활용하여 Auto Scaling을 적용하기 유리한 구조를 갖추도록 함으로써 확장에 열린 구조를 갖출 수 있었습니다.
4.
모니터링 인스턴스와 연계
모니터링 인스턴스에는 Pinpoint와 Prometheus, Grafana 애플리케이션이 도커 컨테이너를 통해 구동중입니다.
애플리케이션 서버의 메트릭 정보는 보안그룹을 통해 모니터링 인스턴스에서만 수집할 수 있도록 안전하게 관리했습니다.
관련 아카이브
[AWS] 까비 인프라 마이그레이션 스토리
과거 모놀리식 아키텍처로 구성되었던 인프라를 분산형 구조로 마이그레이션했던 스토리를 담은 글입니다.
https://cabi.oopy.io/archive/infra-migration
인프라 구조 개선 후기를 정리했던 아카이브입니다.
CodeDeploy로 Spring 배포 과정
CodeDeploy란?
https://cabi.oopy.io/archive/spring-codedeploy
CodeDeploy를 활용하여 CI/CD 워크플로우를 재구축한 과정을 정리했던 아카이브입니다.
[따배시] 따라하면서 배우는 시최의 AWS 프리티어로 프로젝트 배포하기
개요
https://cabi.oopy.io/archive/aws-deploy-freetier
현재 Cabi 프로젝트의 인프라와 비슷한 구조로 AWS 프로젝트를 배포 및 자동화하는 방법에 대해 정리한 아카이브입니다.