AWS
프로젝트가 끝나면 어떤 방식으로 배포할 지 결정해야 한다. 배포는 온프레미스와 클라우드 두 가지 서버 운영 방식이 있다. 온프레미스는 전산실에 서버를 설치하여 자체 로컬 서버를 운영하는 방식이고, 클라우드는 데이터 센터를 만들고 필요한 만큼 할당받아 원격 환경에서 서버를 운영하는 방식이다. 보안이나 비용 등 각각의 장단점이 존재하지만 오늘은 AWS(클라우드)에 대해 알아보자.
기능
AWS는 필요로 하는 스펙에 따라클라우드 프로덕트 명칭을 약어로 표현한다. 약어와 기능을 알아보자.
EC2 : Elastic Compue Cloud
EC2는 AWS가 제공하는 독립적인 컴퓨터 서버이다. 클라우드 공간 안에 원하는 OS(Linux, Ubuntu, Cent OS 등)를 선택하여 원하는 서버를 설치할 수 있으며 생성된 EC2 하나를 인스턴스라고 부른다.
EC2를 생성하기 위해서는 아래의 선택 사항이 있다.
-
애플리케이션 및 OS 이미지(Amazon Machine Image) 정보
AMI는 인스턴스를 시작하는 데 필요한 소프트웨어 구성(운영 체제, 애플리케이션 서버 및 애플리케이션)이 포함된 템플릿이다. 원하는 운영체제로 EC2 서버가 구성된다. -
가상 서버 사양 선택
vCPUs, 메모리, 스토리지, 네트워크 성능 등을 선택할 수 있다. EC2는 기본적으로 EBS(Elastic Block Store)라는 스토리지에 정보를 저장하는데 이는 추후 설정을 통해 용량을 변경할 수 있다. -
네트워크 설정
네트워크, 서브넷, 퍼블릭 IP 자동 할당, 보안 그룹(방화벽)을 설정하고, 새 보안 그룹을 생성한다. -
키 페어(로그인)
공개 키와 개인 키로 구성된 키 페어는 Amazon EC2 인스턴스에 연결할 때 ID를 증명하는 데 사용하는 보안 자격 증명 세트이다. Amazon EC2는 인스턴스에 공개 키를 저장하고 사용자는 개인 키를 저장한다. Linux 인스턴스의 경우 프라이빗 키를 사용하여 인스턴스에 SSH로 안전하게 연결할 수 있다.
ELB
Elastic Load Balancing의 약자로 서버의 부하 조절을 담당한다. 타겟 서버에 과부하가 발생할 경우 트래픽을 분산시키거나 오토 스케일링을 통해 추가적인 인스턴스 추가/삭제가 이루어진다.
RDS
RDS는 관계형 데이터베이스를 위한 AWS 서비스다. 서버 컴퓨터 역할을 하는 EC2 내부에 MySQL, PostgreSQL 등을 깔아서 EC2 내부에서 동작하게 만들 수도 있지만, 보통은 DB를 위한 별도 RDS를 만들어 작업한다. DB 서버를 분리하는 것과 같은 개념인데 이렇게 해야 서버 부하나 장애도 줄이고 서버를 옮길 때 편리하게 작업할 수 있다.
S3 : Single Storage Service
AWS에서 사용되는 스토리지 유형 중 하나이고 가장 널리 사용되는 스토리지이다.
AWS에서 EC2는 데이터 저장을 위한 공간이라기보다는 서버의 성격이 강해 대용량 데이터를 저장하지 않는다. 웹어플리케이션에서는 보통 이미지나 css, 미디어 파일을 s3에 저장해 관리한다.
S3는 이외에도 로그 수집 등 다른 AWS 요소들과 연결되어 사용된다. 형식을 지정하지 않은 채로 원하는 스토리지에 저장하기 전에 데이터를 담아두는 용도로 많이 활용된다.
IAM
Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스다. AWS는 한 계정으로 다양한 서비스를 관리하는데, IAM은 우리가 사용하는 Linux에서 root 관리자와 같은 역할을 하며 사용자라고 정의한다. 사용자는 IAM을 사용하여 리소스를 사용하도록 인증(로그인) 및 권한 부여(권한 있음)된 대상을 제어한다.
Lambda
Lambda는 서버 구성 없이 코드로 작성된 함수를 호출할 수 있도록 구성된 서비스이다. 파이썬, 자바스크립트 등 다양한 언어를 바탕으로 람다 서비스를 만들 수 있다. 많은 서버 설정이 필요 없을 때 EC2 대신 람다로 기능을 구현해 사용할 수 있다.
warm / cold start
람다에는 Warm Start와 Cold Start가 있어 미리 예열된 상태라면 이전보다 훨씬 빠른속도로 함수들을 처리한다. Warm / Cold를 우리말로 바꾸자면 람다가 바로 준비 된 상태 / 람다가 바로 준비되지 않은 상태가 제일 적절할 것 같다.
람다는 처음 호출한다면 Cold Start를 한다. 이 경우 초기 지연시간이 발생한다. 그리고 Warm 상태를 유지하며, 이 경우에는 람다를 다시 호출해도 지연시간이 발생하지 않고 빠르게 응답한다. 그러다 약 5분여 이상 호출이 되지 않는다면 Cold상태로 바뀌고 다시 호출될 경우 지연시간을 가지고 Cold Start를 한다.
EC2 - Lambda 차이
비용
컴퓨팅 자원으로만 본다면 람다는 EC2에 비해 월등히 비싸고 온디맨드로 한다면 차이는 배 이상으로 발생한다. 그런데도 Lambda는 비용을 줄일 수 있다. 우리가 일반적으로 서비스를 운영할 때 CPU 사용률이나 메모리 사용량을 약 70%로 설정하고 넘어갈 경우 서버가 스케일링 되도록 구성한다. 그리고 다시 70~80% 이하로 유지하도록 설정한다. 하지만 Lambda를 사용한다면 항상 100%의사용량을 달성할 수 있고 사용을 하지 않는 동안에는 유휴상태로 금액을 지불하지 않기때문에 클라우드의 가장 큰 장점인 내가쓴만큼만 비용을 지불할 수 있다.
람다는 최대 5분까지 사용할 수 있고, 메모리 사용량 또한 제한이 있다. 이 때문에 디비백업, 영상 인코딩 같이 많은 컴퓨팅용량이 단시간내에 많이 필요할경우 상당히 비효율적이다. 그렇다고 EC2 인스턴스를 사용하기도 애매할때가 있다.
이럴때는 ECS Fargate를 사용하면 경제적으로 사용할 수 있다. ECS Fargate는 사용자가 만든 도커이미지를 별도의 EC2 인스턴스나 기타설정없이 실행하고 실행된 시간만큼만 금액을 지불한다. 동영상 구간별 썸네일 추출같이 단시간 많은량의 메모리가 필요한 경우 아주 효율적으로 사용할 수 있다.
serverless
서버를 구성하는 것은 서버 하드웨어만 있는 것이 아니다. 다음과 같은 것들이 모두 있어야 서버로서의 역할을 한다.
인터넷 망 / 서버 하드웨어 서버 / 운영체제 서버 / 미들웨어 서버 / 애플리케이션
클라우드 서버를 구축하는 경우 위에 중 인터넷 망, 서버 하드웨어, 서버 운영체제 부분까지는 구축하는 노력을 안 해도 된다. 클라우드 서버가 인기가 있는 이유이기도 하다.
그러나 사람들은 서버 미들웨어와 서버 애플리케이션도 노력을 안 하게 만드는 방법을 연구했고, 그 결과 서버리스 아키텍처가 등장하게 되었다.
서버리스 아키텍처는 인프라를 관리할 필요 없이 애플리케이션과 서비스를 구축하고 실행하는 방식이다. 애플리케이션은 여전히 서버에서 실행되지만, 모든 서버 관리는 인프라 업체에서 한다. 더 이상 애플리케이션, 데이터베이스 및 스토리지 시스템을 실행하기 위해 서버를 확장 및 유지 관리할 필요가 없다.
서버리스 아키텍처를 사용하면 개발자가 클라우드나 온프레미스의 서버 또는 런타임 관리와 운영에 대해 걱정하기보다는 핵심 제품에 집중할 수 있다. 이렇게 오버헤드가 줄어들면 개발자의 시간 관리 능력이 증가하고 안정적인 제품을 개발하는 데 사용할 수 있다.
AWS Lambda, Amazon API Gateway 및 Amazon DynamoDB와 같은 서비스가 존재하며, 애플리케이션의 실행 및 관리와 관련된 운영 복잡성을 줄여준다.
[참조]
