🛠️ EKS 기반 아키텍처 구상
SAA 자격증 시험을 준비하면서 최종 프로젝트 아키텍처에서 프론트엔드 서버 구성을 더 효율적으로 개선할 수 있다는 걸 알게 됐다. 그래서 이번 글에서는 공부했던 내용을 토대로 아키텍처를 보완해보려 한다.
초기 아키텍처
이 아키텍처의 흐름을 정리해보면 다음과 같다.
1. CI/CD 파이프라인
- 개발자가 GitHub에 코드를 push하면, GitHub Actions의 CI 파이프라인이 트리거된다.
- 어플리케이션 코드를 기반으로 컨테이너 이미지를 빌드하고, ECR에 업로드한다.
- ArgoCD는 GitHub에 저장된 Manifest를 지속적으로 모니터링하며, 변경 사항이 감지되면 이를 기반으로 EKS 클러스터에 자동으로 배포한다.
2. IaC
- 인프라 리소스는 CloudFormation을 이용한 IaC 방식으로 관리되고 있다.
3. 클러스터 및 노드 구성
- EKS 클러스터는 3개의 AZ에 걸쳐 구성된 워커 노드와 Auto Scaling Group을 통해 고가용성과 확장성을 제공한다.
- ASG 예약 조정 기능을 통해 시간대별 트래픽 패턴을 가정해서 노드 수를 조절한다.
- 워크로드 부하 증가 시에는 Karpenter를 활용해 스팟 인스턴스를 중심으로 자동 확장된다.
4. 보안
- 외부 요청은 ACM이 적용된 ALB를 통해 HTTPS로 안전하게 처리된다.
5. 정적 데이터 및 데이터베이스
- 사용자 업로드 파일은 S3 버킷을 통해 저장된다.
- 데이터베이스는 RDS for MySQL이 Multi-AZ 구성으로 배포되어 장애 발생 시 자동으로 장애 조치를 수행할 수 있다.
6. 모니터링 및 알림 시스템
- Prometheus와 Actuator를 이용하여 어플리케이션 메트릭을 수집하고, Grafana를 통해 이를 시각화한다.
- 특정 이벤트 발생 시, Discord Webhook을 통한 실시간으로 알림을 전송하여 빠르게 대응할 수 있다.
아키텍처 보완
기존에는 프론트엔드(WEB) 어플리케이션을 EKS 내부 Pod에서 실행했지만, React 어플리케이션은 정적 자산이기 때문에 EKS pod에서 실행할 필요가 없다. S3 정적 호스팅 + CloudFront 구조로 전환하는 것이 더 효율적이다.
- S3 버킷에 빌드 파일을 업로드하고, EKS 리소스 사용 또한 감소시킬 수 있다.
- 또한, CloudFront를 통해 글로벌 캐싱 및 빠른 응답 속도를 확보할 수 있다.
- CloudFront에 us-east-1 리전의 ACM 인증서를 적용하여 HTTPS 요청 보장할 수 있다.
흐름
사용자는 오직 CloudFront + S3로 배포된 정적 웹 앱에 접근하며, 웹 앱이 동적으로 백엔드 API를 호출한다.
사용자 ─▶ CloudFront (정적 자산) ─▶ S3 (React)
↓
웹 앱에서 동적 API 요청 발생
↓
ALB ─▶ 백엔드 서버 (EKS)
↓
RDS 등 데이터 계층CloudFront 오리진 구성
- S3 오리진 : 정적 파일 경로를 처리
- ALB 오리진 :
/api/*같은 API 요청 전용 경로를 처리
이를 위해 CloudFront에서 오리진 기반 라우팅 설정을 사용하여 경로별로 요청을 분기 처리한다.
보안 구성
- S3 : 퍼블릭 접근을 차단하고, OAC 정책 적용을 통해 CloudFront만 접근 가능하도록 제한
- ALB : CloudFront가 인터넷을 통해 접근해야 하므로 퍼블릭 서브넷에 두고, 보안 그룹을 통해 CF만 접근 가능하게 설정 + ACM 인증서 적용하여 CloudFront -> ALB간 HTTPS 통신 보장
구성도
바뀐 부분을 중심으로 하여 구상도를 다시 만들어보았다. 하나하나 세세하게 반영하면 너무 오래 걸려서....
이번 글에서는 파이널 프로젝트 당시 구성했던 아키텍처를 기반으로 전체 시스템을 재구성해보았다. 당시에 인프라를 CloudFormation으로 관리했는데, Terraform을 활용하지 못한 점이 아쉬움으로 남았다. 남은 기간 동안 Terraform을 좀 더 공부해서 Terraform 기반으로 아키텍처를 다시 배포해보아야겠다.
부지런히 살자