Amazon EC2

새 기능을 배포했는데 프로세스가 몇 시간씩 살아 있어야 하면, 요청이 없을 때도 서버는 계속 켜둬야 합니다. 물리 서버나 고정 용량 서버만 쓰면 트래픽이 늘 때 바로 늘리지 못하고, 줄어도 남는 용량 비용을 계속 냅니다.

예전에는 애플리케이션을 띄우려면 물리 서버를 먼저 구매하고 랙, 전원, 네트워크까지 준비해야 했습니다. 조달에만 수 주에서 수 개월이 걸렸고, 트래픽 피크를 대비해 평소 사용량보다 훨씬 큰 장비를 미리 사두는 과잉 투자가 흔했습니다. 반대로 예측이 빗나가면 증설이 늦어져 서비스가 느려지거나 멈추기도 했습니다. 이런 조달 지연과 비용 낭비를 없애기 위해 필요한 만큼 가상 서버를 즉시 할당하는 EC2 같은 모델이 등장했습니다.

EC2 인스턴스는 AMI(머신 이미지)를 골라 OS와 초기 소프트웨어를 결정하는 데서 시작합니다. 그 다음 인스턴스 타입을 지정해 CPU 코어 수와 메모리 크기를 할당하면, AWS 하이퍼바이저가 물리 호스트 위에 격리된 가상 머신을 생성합니다. 가상 머신이 뜨면 ENI(Elastic Network Interface)가 붙어 VPC 안에서 IP를 받고, EBS 볼륨이 루트 디스크로 연결되어 OS가 부팅됩니다. 이 과정이 수 십 초 안에 끝나기 때문에 물리 서버를 주문하던 시절과 달리 필요한 시점에 바로 컴퓨팅 자원을 확보할 수 있습니다.

EC2와 ECS는 둘 다 애플리케이션을 실행하지만 초점이 다릅니다. EC2는 서버 자체를 관리하는 선택이고, ECS는 컨테이너 단위 배포와 오케스트레이션에 초점이 있습니다. OS 설정, 런타임, 장기 실행 프로세스를 직접 제어해야 하면 EC2가 맞습니다. EC2와 Lambda도 둘 다 코드를 실행하지만 운영 모델이 다릅니다. EC2는 서버가 항상 떠 있고 프로세스 수명을 직접 관리하는 반면, Lambda는 이벤트가 올 때만 짧게 실행되고 서버 자체가 보이지 않습니다. 프로세스가 몇 시간~며칠 살아야 하거나 OS 수준 설정이 필요하면 EC2를, 짧은 이벤트 처리만 필요하고 서버 관리를 없애고 싶으면 Lambda를 보면 됩니다.

예를 들어 커머스 팀이 주문 처리 서버를 상시 운영하면서 프로모션 기간에 Auto Scaling으로 인스턴스를 늘리는 경우, 또는 데이터 팀이 야간에 대용량 ETL 배치를 스팟 인스턴스로 돌려 비용을 줄이는 경우가 전형적입니다. Jenkins 같은 CI/CD 빌드 서버처럼 특정 도구를 OS 위에 직접 설치해야 하는 경우에도 EC2가 자연스럽습니다. 컨테이너 단위 배포가 더 중요하거나 요청 단위의 짧은 실행만 필요한 경우에는 맞지 않습니다.