[CJ 올리브네트웍스] CLOUD WAVE 4 - 프로젝트
이번 포스팅은 CLOUD WAVE 교육에서 진행한 프로젝트를 소개하려고 한다 .
1. 프로젝트 주제
주제 : "CGV 영화관 광고 동기화 및 시사회 라이브 스트리밍 서비스"
선정 배경 :
- 영화관 광고 동기화 송출 서비스
- 관람 시작 전 광고가 길어 사용자 불편함이 발생함.
- 사용자에게 실질적 상영 시작 시간을 제공해 편의성 높이고자 함.
- 제 시간에 영화관에 도착하지 못했을 때, 앱을 통해 상영 시작까지 남은 시간 제공함.
- 시사회 실시간 스트리밍 서비스
- 제한된 인원만 참여 가능한 기존 시사회 한계가 있었음.
- 스트리밍으로 접근성을 높이고 실시간 소통 가능하게 하고자 함.
2. 아키텍처
개발계 : CGV 플랫폼의 개발 담당
미디어계 : 광고 송출과 실시간 라이브 구현 담당
배포계 : 서비스를 실제로 배포하기 위한 인프라 구축
DR : 재난 상황 시 복구 모델 구현
3. 아키텍처 설명
[ 배포계 flow ]
1. 사용자가 서비스에 요청을 보내면, 해당 요청은 Application Load Balancer로 전달됨
2. ALB는 클라이언트의 요청을 받아 Kubernetes 클러스터 내에서 실행 중인 Pod로 트래픽을 분배함
3. 트래픽 갑자기 증가할 경우, Karpenter를 이용해 클러스터의 리소스 상태를 실시간으로 모니터링하여, Pod을 실행할 공간이 부족하면 자동으로 새로운 노드를 추가함
4. 새로운 Pod가 생성되어 준비 상태(Ready)에 도달하면, 자동으로 ALB의 Target Group에 등록되어 요청을 처리할 수 있게 됨
=> 서비스는 예상치 못한 트래픽 증가에도 유연하게 확장되며, 사용자에게 안정적인 경험 제공 가능!!
[ Kubeops-View를 통한 검증 ]
➡️ 다량의 트래픽이 발생했을 때 Karpenter를 활용한 Auto Scaling의 작동 과정
1. (좌하단) K6 부하테스트를 통해 서비스에 트래픽이 몰리는 상황을 가정
- 1초에 가상 사용자 1000명이 요청을 보냈을 때
2. Karpenter가 자동으로 노드를 추가하는 과정을 좌측상단에 보이는 Kube-Ops-View 대시보드를 통해 확인
- 원래의 배포 환경에서는 기본적으로 설정된 pod (초록색 박스)만 띄워져 있음
- 트래픽이 증가함에 따라 서버에 부하가 가해지면서 pod (초록색 박스)가 늘어나는 모습 확인 가능
- pod를 실행시킬 노드가 부족해지면 Karpenter는 자동으로 node (보라색 박스)를 증가 시키고 새로 생성된 pod를 배치함
[ RDS ]
- RDS (Relational Database Service)에서 가용 영역 존을 달리하여 Read/Write를 분리함으로써 고가용성 보장
[미디어계 flow]
[개발계 flow]
4. 비용 절감
프로젝트 특성상 2,000달러 예산 내에서 진행해야 했기 때문에, 비용을 고려한 설계가 특히 중요했다. 우리 팀의 비용 절감 포인트는 다음과 같다.
- 슬랙 알림과 람다 함수를 활용
- 오픈소스를 활용한 모니터링 시스템을 구축
- 비용 임계값 알림 설정
[슬랙 알림과 람다 함수 활용]
용량 기반 과금 모델을 사용하는 IVS와 Lambda에서는 불필요한 리소스 정리가 비용 절감에 영향을 미치므로, 슬랙 알림과 람다 함수를 활용하여 리소스 사용 시간을 최적화였다. 또한 사용하지 않는 리소스는 자동으로 중지하거나 삭제할 수 있도록 하였다. IVS 채널의 경우, 상영 종료 시간이 되면 이벤트 브릿지와 람다 함수를 통해 채널과 채팅방을 자동으로 삭제하고 슬랙으로 알림을 전송받습니다.
또한, 사용하는 개발, 스테이징 환경의 EC2와 RDS 인스턴스가 평일 업무시간에만 작동하도록 설계하여 불필요한 리소스 사용을 줄였다.
[ 오픈소스를 활용한 모니터링 시스템을 구축 ]
Prometheus-Grafana 통한 모니터링 시스템을 구축하였다. 오른쪽은 ELK의 모니터링 도구로, 리소스의 로그를 추적하고 있다. 상용 모니터링 솔루션과 비교했을 때, 오픈소스 도구를 활용함으로써 큰 비용 절감 효과를 얻을 수 있다. 예를 들어, Datadog이나 Cloud Watch과 같은 상용 솔루션은 월 수천 달러의 비용이 발생할 수 있지만, 오픈소스 기반 시스템은 인프라 비용 외에 추가 라이선스 비용이 발생하지 않는다.
[ 비용 임계값 알림 설정 ]
미디어 서비스에서 발생할 수 있는 비용과 인프라 부분에서 발생할 수 있는 비용을 대략적으로 산출하여 (*트래픽 증가 기준) 산출한 수치를 바탕으로 AWS에서 예산 임계치를 설정하여 그 기준을 초과하면 이메일로 알림이 오도록 하였다.
5. 보안
[ WAF & IAM ]
WAF를 활용하여 접속 유형을 감지하고, 이를 기반으로 봇의 접근은 차단하는 등, 접근 제어 정책을 적용하였다.
또한, IAM을 통해 각 사용자의 역할과 필요에 맞는 최소 권한만 부여하여 보안을 강화하였다. 이를 통해 불필요한 권한 부여를 방지하고, 보다 안전한 서비스 운영이 가능하도록 하였다.
[ CI/CD 파이프라인 내에서 총 세단계의 체계적인 보안 검사 ]
CI/CD 과정에서도 보안성을 향상시키기 위해, CI/CD 파이프라인 내에서 총 세단계의 체계적인 보안 검사를 진행하였다.
1. 프로젝트에 설치된 모든 의존성은 OWASP의 Dependency Check를 통해 보안 검증을 거친다.
2. 그 다음으로, SonarQube를 활용하여 소스코드 품질 및 보안 취약점을 분석한다.
3. 마지막으로, Trivy(트리비)를 이용하여 컨테이너 이미지의 잠재적 취약점을 검출한다.
=> 이러한 다층적 보안 검사 체계를 구축하여 개발부터 배포까지 전 과정에서 보안을 강화하였다.
6. 자체 평가 및 회고
프로젝트에 대해 자체적인 평가를 해보았을 때, 크게 3가지의 장점을 꼽을 수 있다. 🔥
첫째, '명확한 MVP 설계'이다. 핵심 기능을 우선 구현하여, 사용자 피드백을 빠르게 받고 개선해 나가는 방식을 채택하여 프로젝트를 진행했으며, 필수 기능 구현에 집중하여 개발 속도와 효율성을 높였다.
둘째, '자동화'이다. 테라폼으로 인프라를 구축하여 자동화된 인프라 관리가 가능하며, CI/CD 파이프라인을 통해 변동 사항이 자동으로 배포된다. 또한, 람다 함수를 활용한 서버리스 방식으로 미디어 서비스 상당 부분을 자동화하였다.
마지막으로, '마이크로 서비스' 아키텍처 도입이다. 광고 동기화 송출 서비스와, 시사회 라이브 스트리밍 서비스 두 가지 기능은 하나의 서비스에 문제가 발생해도 다른 서비스에 영향을 미치지 않는 독립적인 구조를 갖고 있다. 이를 통해 하나의 큰 애플리케이션을 여러 개의 작은 독립적 서비스로 분리된다.
7. 프로젝트를 끝마치며
좋은 팀원들을 만나 즐겁게 프로젝트를 마무리할 수 있었고 , 많은 것들을 얻고 배워가는 프로젝트였다. 🍀✨🔥
보다 자세한 프로젝트 내용은 다음 링크에서 확인할 수 있다.