티스토리 뷰

SW 개발

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

지단로보트 2018.10.24 17:54

Amazon EC2

  • Amazon EC2AWS 생태계에서 가장 많이 사용되는 가상 서버 솔루션이다. 일반적인 가상 서버 호스팅과 동일하게 최초 인스턴스를 생성하면 운영체제의 root 권한을 받아 거의 모든 것을 물리 서버에서 했던 것과 동일하게 작업할 수 있다. 엔터프라이즈 레벨의 마이크로서비스를 배포, 운영하는 목적에 적합하다.
  • 새로운 인스턴스를 시작하면 Amazon Machine Image(AMI)라고 불리우는 운영체제 템플릿을 선택할 수 있다. 다양한 템플릿이 제공되는데 물리 서버에서 CentOS를 운영하던 개발자의 경우 Amazon Linux AMI(AmazonRHEL을 기반으로 제작한 리눅스로 CentOS와 완전히 동일하지는 않지만 유사)를 선택하면 된다.
  • Amazon EC2의 장점은 부하 증가에 대비한 Auto Scaling 기능의 제공이다. 부하 증가가 필요한 Amazon EC2 인스턴스를 그룹으로 묶어 오토 스케일링의 최소, 최대 인스턴스 수를 설정하면 부하 수준에 따라 자동으로 인스턴스의 수를 조절해준다. [관련 링크]
  • Amazon EC2AWS 가입 후 최초 1년까지만 무료로 사용 가능한 제한적 프리 티어 상품에 해당한다. 최초 가입 후 1년 이내라면 인스턴스 생성시 t2.micro(CPU 코어 수 1개, 메모리 1GB)를 선택하여 매월 750시간을 무료로 사용할 수 있다.

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 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 인스턴스가 필수적으로 요구된다. [관련 링크]

관련 글

댓글
댓글쓰기 폼