항공대 산학 R&D 수행기 - 01. 요구사항 분석

한국항공대 소프트웨어학과에서는 캡스톤 디자인(종합설계) 대신 교내 스타트업에서 파트타임 인턴십을 수행해야 하는데요, 제가 수행중인 프로젝트의 기록을 간단하게나마 남겨보고자 합니다.

이번 글에서는 본격적인 과제 구현 이전 수행한 요구사항 분석 및 도출 결과 등을 다룹니다.

과제 - AWS 기반 장애 복구용 백업 인프라 구성

현재 파트타임 R&D 활동을 진행하고 있는 업체는 가수의 음반(앨범)과 비슷한 상품을 판매하는 회사인데요, 인기있는 가수가 신규 음반을 발매하면 트래픽이 집중되어 서버에 부하가 발생하는 문제가 있었습니다.

 

따라서, 이번 프로젝트 기간 동안 고객이 다수 몰리더라도 필요한 만큼 탄력적으로 인스턴스를 스케일링할 수 있는 클라우드 기반 백업 인프라를 구현하고자 합니다.

현재 상황

문제가 되는 서비스는 평소에는 거의 트래픽이 발생하지 않지만, 신규 앨범 발매 등의 이벤트가 있을 때마다 많은 트래픽이 발생합니다.

이 때 사용자가 해당 페이지에 진입할 시 약 30 ~ 40건의 HTTP 요청에서 고해상도 이미지(※ 약 8 ~ 10메가 상당, 이미지 용량을 줄일 수는 없는 상태)를 다수 전송하고 있었습니다.

따라서 신규 앨범 발매로 인해 순간적으로 서버에 가해지는 부하를 현재 On-prem 서버에서 감당하지 못해 접속이 불가한 문제가 간헐적으로 발생했습니다.

요구사항

• 평소에는 트래픽이 거의 없음을 고려해 Passive한 DR 전략을 수립해야 합니다.
• 최소한의 비용으로 백업 인프라를 구성해야 합니다.
• RTO(복구 시간 목표)를 최소화한 인프라를 구성해야 합니다.
• 프로젝트 기간이 끝나 운영인력이 바뀌어도 누구나 간단히 운영할 수 있어야 합니다.
• 최대한 간단한 기술 & 아키텍처를 도입해야 합니다. (🥲)

목표

따라서 트래픽이 몰릴 때마다 자동으로 스케일링된 환경을 구성하기 위해, 메인으로는 기존 On-prem 인프라를 활용하면서 부하 발생 시 AWS의 Auto Scaling Group을 활용한 클라우드 인프라를 구성하고자 합니다.

또한, 프로젝트 기간이 끝난 이후에도 누구나 클라우드 인프라를 쉽게 배포 / 회수할 수 있도록 IAC 기반의 인프라를 구성하고자 합니다.

아키텍처 산출물 (1차 기획)

파악해야 할 점

• 어떤 CloudWatch 메트릭을 통해 Auto Scaling을 사용할 지 파악해야 합니다.
• 몇 명의 사용자부터 서버가 죽는지 파악해야 합니다.
• 현재 사용중인 서버 스펙을 파악해야 합니다.
• 수직 스케일링 후 컨테이너 앞에서 로드밸런싱을 수행하는 것이 효과적일지, 수평 스케일링 후 각 인스턴스 앞에서 효과적일지 파악해야 합니다.

예상되는 어려움

1. 100% 인프라 자동화의 어려움

규모가 크지 않은 스타트업이자 평시에는 자주 사용되지 않는 어플리케이션이라는 특징으로 인해, 사실상 클라우드 인프라 운영비용이 나가지 않는 방법으로 백업 아키텍처를 구현해야 합니다.

 

또한, 현재 On-prem 인스턴스는 KT Cloud의 것을 사용하고 있어 CloudWatch를 통한 메트릭을 수집하려면 CloudWatch Agent를 설치해야 하는데, 파트타임 신분 상 아직 운영 서버에 접근할 수 없다는 문제가 있습니다.

 

따라서 우선은 CloudWatch & CloudWatch Alarm을 통한 자동 인프라 구성 대신, 트래픽 과밀이 예상되는 시점(Ex. 신규 음원 발매 10분 전)에 수동으로 Terraform을 통해 인프라를 배포해야 할 것으로 예상됩니다.

 

2. Bitbucket 문제

Bitbucket으로 관리하는 코드를 S3에 배포해 버저닝하는 과정에서, Bitbucket Pipeline(Github Action과 유사한 CI/CD 파이프라이닝 도구)이 기본적으로 월 50분의 가용시간만을 제공합니다.

그러나 PHP 어플리케이션 특성상 대용량의 소스 코드(현재 약 700MB)를 업로드할 때 약 10분 이상이 소요되어, 코드를 자동으로 압축해 업로드하는 방법을 찾기 전까지는 Bitbucket → S3로의 배포 과정이 원활하지 않을 것으로 예상됩니다.