티스토리 뷰

SW 개발

AWS, 클라우드 솔루션 비교 정리

지단로보트 2018. 10. 24. 17:54

AWS CloudTrail

  • AWS CloudTrailAWS 자체의 사용 이력을 기록해주는 서비스이다. 시간순으로 사용 이력을 편리하게 확인할 수 있어 서비스 구축 초기에 가장 먼저 셋업해야할 상품으로 추천된다. 추적을 활성화하는 방법은 아래와 같다.
AWS CloudTrail 콘솔 접속
→ [추적 생성] 클릭

# 빠른 추적 생성
→ 추적 이름: foobar-management-events (입력)
→ [추적 생성] 클릭

AWS CodeCommit

  • AWS CodeCommit은 기업을 위한 비공개 Git 저장소와 웹 UI를 제공하는 서비스이다. 가장 큰 장점은 가격으로, 무제한 리피타지터리에 최초 5명까지는 무료, 추가 사용자당 매월 1USD를 요구하여 인원수가 적은 개발팀은 굉장히 저렴한 비용으로 소스 코드 저장소를 안전하게 관리할 수 있다는 것이다. GitHub, GitLab보다는 UI가 단순한 편이지만 필요한 기능은 다 갖추고 있다. (가장 중요한 UI에서의 Pull Request를 통한 코드 리뷰 기능을 지원한다.) [관련 링크]

Amazon EC2

  • Amazon EC2AWS 생태계에서 가장 많이 사용되는 가상 서버 솔루션이다. 일반적인 가상 서버 호스팅과 동일하게 최초 인스턴스를 생성하면 운영체제의 root 권한을 받아 거의 모든 것을 물리 서버에서 했던 것과 동일하게 작업할 수 있다. 엔터프라이즈 레벨의 마이크로서비스를 배포, 운영하는 목적에 적합하다.
  • 새로운 인스턴스를 시작하면 Amazon Machine Image(AMI)라고 불리우는 운영체제 템플릿을 선택할 수 있다. 다양한 템플릿이 제공되는데 물리 서버에서 CentOS를 운영하던 개발자의 경우 Amazon Linux 2 AMI(AmazonRHEL을 기반으로 제작한 리눅스로 CentOS 7과 완전히 동일하지는 않지만 유사)를 선택하면 된다.
  • Amazon EC2의 장점은 부하 증가에 대비한 Auto Scaling 기능의 제공이다. 부하 증가가 필요한 Amazon EC2 인스턴스를 그룹으로 묶어 오토 스케일링의 최소, 최대 인스턴스 수를 설정하면 부하 수준에 따라 자동으로 인스턴스의 수를 조절해준다. [관련 링크]
  • Amazon EC2AWS 가입 후 최초 1년까지만 무료로 사용 가능한 제한적 프리 티어 상품에 해당한다. 최초 가입 후 1년 이내라면 인스턴스 생성시 t2.micro(CPU 코어 수 1개, 메모리 1GB)를 선택하여 매월 750시간을 무료로 사용할 수 있다.
  • 2018-11 서울 리전에 T3 3세대 인스턴스가 추가되었다. T2 대비 10%의 비용 절감 효과가 있어 새롭게 시작하는 인스턴스에 추천할만 하다.
  • 2019-04 서울 리전에 T3a 3세대 인스턴스가 추가되었다. T3와 같은 특징을 가지면서 AMD EPYC 기반 아키텍쳐를 기반으로 한다. T3보다 10% 저렴하다.
  • T2, T3, T3a 인스턴스 유형은 CPU 크레딧이라는 개념이 존재한다. CPU 개수당 기준 성능을 두어(t3a.xlarge는 40%) 평소 이 기준 성능 이하로 작동할 경우 CPU 크레딧을 적립하고(t3a.xlarge는 시간당 96크레딧, 최대 2,304크레딧) 기준 성능을 초과하여 작동할 경우 CPU 크레딧을 소모한다. (CPU 1개당 1분당 1크레딧) 모든 CPU 크레딧이 소모되면 기준 성능으로만 작동한다. (또는 무제한 모드로 변경하여 초과 작동에 대해 제한 없이 사용하고 추가 요금을 지불하는 방법도 있다. 콘솔 페이지에서 대상 인스턴스 선택 후 작업인스턴스 설정Change T2/T3 Unlimited를 클릭하면 적용된다.) 콘솔 페이지의 모니터링 메뉴에서 사용량과 적립량을 확인할 수 있다.
  • t3.xlarge(CPU 코어 수 4개, 메모리 16GB)는 애플리케이션 서버 운영에 적합하다. 온디맨드 월 166,656원, RI/선결제 없음 월 99,993원(40% 할인), RI/부분 선결제 월 96,660원(42% 할인), RI/전체 선결제 월 93,276원(44% 할인)을 과금한다.
  • 인스턴스 생성시 키 페어를 생성하거나 선택할 수 있는데 .pem 확장자 파일만 지원하기 때문에 PuTTY 클라이언트 사용자는 PuTTYgen을 이용하여 .ppk로 변환해야 SSH 접속시 자동 로그인이 가능하다. 생성된 인스턴스는 ec2-user 사용자로 로그인이 가능하다.

Amazon EC2 요금제

  • Amazon EC2 요금은 기본적으로 시간 단위로 과금된다. 인스턴스를 생성하고 1분만 사용하더라도 1시간의 사용료를 과금한다. 또한 인스턴스 사용 과금 외에 아웃바운드 트래픽에 대해 과금한다는 것을 잊지 않아야 한다.(인바운드 트래픽은 무료이다.)
  • Amazon EC2 요금제는 2개로 분류된다. 먼저 시간 단위로 사용료를 과금하는 온디맨드 요금제가 있다. 언제든지 인스턴스를 종료하면 과금 또한 중단되어 비지니스가 확실한 기간 시스템의 운영 목적으로 적합하다는 장점이 있다. 단점은 비용이 가장 많이 발생하는 요금제라는 것이다.
  • 두번째는 RI(예약 인스턴스) 요금제가 있다. 1년치 또는 3년치를 장기 계약하고 과금하는 일종의 정액제라고 볼 수 있는데 온디맨드 대비 최대 75%까지 비용이 저렴하다는 장점이 있다. (요금의 전부 또는 일부를 선결제하면 추가 할인 또한 가능하다. 3년 약정, 전체 선결제가 가장 저렴하다.) 단점은 계약 기간 동안은 인스턴스를 종료해도 환불이 되지 않고 과금되기 때문에 불확실한 비지니스에 적합하지 않다는 것이다. [관련 링크]
  • RI를 구매하는 방법은 AWS 콘솔에서 EC2 선택 → 왼쪽 메뉴에서 예약 인스턴스 클릭 → 예약 인스턴스 구매 버튼을 클릭하여 진행하면 된다. 구매가 완료되면 작동 중인 온 디맨드 인스턴스에 자동으로 RI 요금제가 최우선으로 적용된다. [관련 링크]
  • 한편, Savings Plans은 2019-11-06 새로 출시된 요금제이다. RI 요금제가 개별 EC2 인스턴스에 대한 약정이라면 Savings Plans는 전체 EC2 인스턴스 그룹군에 대한 약정이다. 약정한 전체 컴퓨터 사용량을 초과하지 않는 범위 내에서 EC2 인스턴스를 자유롭게 변경할 수 있으면서 RI 요금제와 거의 동일한 수준(최대 72%)으로 비용을 절약할 수 있다는 장점이 있다. [관련 링크]

Amazon Lightsail

  • Amazon LightsailAmazon EC2의 저가형 상품이라고 말할 수 있다. 인스턴스 생성시 최저 사양으로 Amazon Linux 운영체제를 선택할 경우 최소 월 $3.50 USD(512MB RAM, 1vCPU, 20GB SSD, 한달 최대 1TB 트래픽, 최초 30일은 무료)의 요금제로 가상 서버 환경을 완전히 구축할 수 있다. 원클릭으로 다양한 운영체제 및 애플리케이션을 설치할 수 있는 편리함을 제공한다. [관련 링크]
  • 사용 중 추후 EC2 인스턴스로 확장이 가능하며, ELB, RDS, S3AWS 생태계의 다른 제품군과의 서비스 연결이 가능하다는 장점이 있다.
  • 요금제는 가상 서버 인스턴스의 생성 시점부터 삭제 시점까지 과금되므로 과금 계산을 중지하려면 가상 서버 인스턴스를 완전히 삭제해야 한다. (중지해도 과금이 되는 것에 유의해야 한다.) 또한, 한달 최대 트래픽을 초과하면 1GB 초과시 $0.13 USD를 추가 과금한다.
  • Amazon Lightsail은 인스턴스에 연결된 조건으로 최대 5개의 무료 고정 IP 주소를 제공한다. 이를 통해 인스턴스에 중단 여부과 관계 없이 항상 변하지 않는 IP 주소를 확보할 수 있다.

Amazon RDS

  • Amazon RDS는 고전적인 RDBMS 저장소를 클라우드로 제공하는 솔루션이다. AmazonMySQL 또는 PostgreSQL을 자체적으로 최적화한 Amazon Aurora 엔진을 선택하거나, 또는 순정 버전의 MySQL, MariaDB, PostgreSQL, Oracle, MSSQL 엔진을 선택하여 인스턴스를 생성할 수 있다. 패치, 모니터링, 장애 복구, 백업, 로드 밸런싱, 스케일링을 완전히 대신 해준다는 것을 제외하고는 물리 서버에서의 그 것과 동일하다.
  • Amazon Aurora 엔진을 선택할 경우 인스턴스 생성시 쓰기 마스터 1개(확장 불가), 읽기 전용 슬레이브 1개(최대 15개까지 확장 가능), 총 2개의 인스턴스가 1개의 클러스터로 기본 구성된다. 애플리케이션에서의 연결을 위해 제공되는 엔드포인트는 쓰기 1개, 읽기 전용 1개가 제공된다. 애플리케이션 개발자는 이 2개의 엔드포인트에 대한 커넥션 풀만 유지하면 나머지는 모두 Amazon RDS가 대신해준다. 예를 들어 쓰기 마스터에서의 장애 발생시 읽기 전용 슬레이브의 마스터 승격 작업 또는 읽기 전용 인스턴스가 다수일 경우의 로드 밸런싱 등 많은 부분을 대신 수행해준다. [관련 링크]
  • Amazon Aurora 엔진과 MySQL 엔진 만을 놓고 비교하면 Amazon Aurora 엔진이 나은 성능을 보여준다. [관련 링크] Amazon Aurora 엔진에서의 마스터의 쓰기 성능은 r4.16xlarge 인스턴스 기준 초당 최대 200,000개라고 공식적으로 밝히고 있다. [관련 링크]
  • 한편, 성능을 극대화하기 위해 애플리케이션과 Amazon Aurora 인스턴스 사이에 ProxySQL가 설치된 Amazon EC2 인스턴스를 두는 사례도 있다. 이 경우 성능의 이점과 함께 애플리케이션 레이어로부터 데이터베이스 레이어를 격리시킬 수 있는 장점도 얻을 수 있다. [관련 링크]
  • Amazon RDS의 장점은 오토 스케일링 외에도 언제든지 운영 중인 인스턴스의 사양(Class)을 변경할 수 있다는 것이다. 단, 인스턴스의 재부팅을 필요로 한다.
  • Amazon RDS는 아쉽게도 2019-12 현재 MariaDB 10.3까지 지원하며, 갈레라 클러스터를 제공하지 않는다. MariaDB 10.4부터 제공되는 Galera Cluster 4.0의 성능이 워낙 막강하여 Amazon EC2에 직접 이를 설치하여 운영하는 사례도 있다. [관련 링크] Galera Cluster 4.0으로 구성된 3대의 MariaDB 10.4 인스턴스를 두고 그 앞단에 2대의 ProxySQL 2.0/Keepalived 인스턴스를 두면 최소의 구성으로 완벽한 HA가 가능하다. [관련 링크1] [관련 링크2]

Amazon ElastiCache

  • Amazon ElastiCache는 대표적인 고속의 인메모리 Key-Value 저장소인 Redis 또는 Memcached를 클라우드로 제공하는 상용 솔루션이다. 패치, 모니터링, 장애 복구, 백업, 스케일링을 완전히 대신 해준다는 것을 제외하고는 물리 서버에서의 그 것과 동일하다.
  • 단순히 캐시로서만 사용할 때는 Memcached 엔진이 Redis 엔진보다 미약하지만 나은 성능을 보여준다. [관련 링크]

AWS Lambda

  • AWS Lambda는 대표적인 Serverless 솔루션으로 이 분야의 선두주자라고 할 수 있다. 아마존이 개발하여 2014년에 처음 출시하였으며 현재 Java를 비롯하여 다양한 메이저 언어를 지원한다. 극단적인 경우 Amazon API Gateway로 인증과 요청을 처리하고 각 요청 이벤트에 대해 AWS Lambda에서 작성한 Function을 맵핑하면 애플리케이션 개발을 완성할 수 있다. [관련 링크]
  • AWS Lambda의 작동 원리는 전통적인 아키텍쳐와 확연히 다르다. 개발작 전체 애플리케이션을 제작하여 배포하고 운영하는 것이 아니라, 선호하는 언어로 단일 기능을 작성하여 업로드하고 그 기능을 작동시킬 트리거를 정의하면 개발이 완료된다. 개발자는 업로드한 기능이 실제 실행된 시간과 실행되는 동안 쓰인 메모리의 사용량 만으로 사용료를 지불하면 된다.
  • AWS Lamda가 주목받는 것은 아키텍쳐의 특이성 때문 만은 아니다. 가장 중요한 애플리케이션 운영 비용이 기존의 40% 수준으로 줄어든다는 장점을 가진다.
  • 장점만 있는 것은 아니다. AWS Lambda에는 Amazon EC2에는 없는 Cold Start라는 개념이 존재한다. 트리거에 의해 최초 호출되거나 오랜 시간 호출된 적이 없는 FunctionCold Start 후에 실행되어 느린 실행 시간을 가질 수 있다. 이러한 현상을 예방하기 위해 5분 간격으로 주기적으로 모든 FunctionPing을 수행하는 스케쥴러를 작성하는 편법이 이용되기도 한다. 문제는 이렇게 호출되어 사용된 시간도 마찬가지로 과금된다는 것이다. [관련 링크1] [관련 링크2]

API 버저닝 전략은?

  • 전통적인 물리 서버에서의 API 버저닝은 https://some-api.com/v1/some-request와 같이 URI에 버전 정보를 포함하는 방법이었다. 클라우드 기반에서의 API 버저닝은 https://v1.some-api.com/some-request와 같이 서브 도메인에 버전 정보를 포함하는 방법을 권장한다. 이 방법을 통해 특정 도메인에 따라 특정 클라우드 인스턴스 또는 클러스터로 요청의 분기를 달리하는 것이 가능해진다. [관련 링크]

극단적인 동시성이 요구된다면?

  • 극단적인 동시성이 요구되는 아키텍쳐라면 Amazon RDS(이 경우 Aurora 엔진) 저장소를 기반으로 Amazon ElastiCache(이 경우 Redis 엔진) 저장소를 운용하는 것이 바람직하다. 다만 Amazon ElastiCache의 경우 내장된 인증 솔루션이 없기 때문에 Amazon EC2 인스턴스가 필수적으로 요구된다. [관련 링크]

관련 글

댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함