본문 바로가기

AWS

AWS S3 와 CodeDeploy

S3란?

Simple Storage Service의 약자로 파일 서버의 역할을 하는 서비스다. 일반적인 파일서버는 트래픽이 증가함에 따라서 장비를 증설하는 작업을 해야 하는데 S3는 이와 같은 것을 대행한다. 트래픽에 따른 시스템적인 문제는 걱정할 필요가 없어진다. 또 파일에 대한 접근 권한을 지정 할 수 있어서 서비스를 호스팅 용도로 사용하는 것을 방지 할 수 있다. 아래는 S3의 주요한 기능적인 특성들이다. 

주요특징

  • 많은 사용자가 접속을 해도 이를 감당하기 위해서 시스템적인 작업을 하지 않아도 된다.
  • 저장할 수 있는 파일 수의 제한이 없다. 
  • 최소 1바이트에서 최대 5TB의 데이터를 저장하고 서비스 할 수 있다. 
  • 파일에 인증을 붙여서 무단으로 엑세스 하지 못하도록 할 수 있다. 
  • HTTP와 BitTorrent 프로토콜을 지원한다.
  • REST, SOAP 인터페이스를 제공한다. 
  • 데이터를 여러 시설에서 중복으로 저장해 데이터의 손실이 발생할 경우 자동으로 복원한다.
  • 버전관리 기능을 통해서 사용자에 의한 실수도 복원이 가능하다.
  • 정보의 중요도에 따라서 보호 수준을 차등 할 수 있고, 이에 따라서 비용을 절감 할 수 있다. (RSS)

주요개념

객체

object, AWS는 S3에 저장된 데이터 하나 하나를 객체라고 명명하는데, 하나 하나의 파일이라고 생각하면 된다.  

버킷

bucket, 객체가 파일이라면 버킷은 연관된 객체들을 그룹핑한 최상위 디렉토리라고 할 수 있다. 버킷 단위로 지역(region)을 지정 할 수 있고, 또 버킷에 포함된 모든 객체에 대해서 일괄적으로 인증과 접속 제한을 걸 수 있다. 

버전관리

S3에 저장된 객체들의 변화를 저장. 예를들어 A라는 객체를 사용자가 삭제하거나 변경해도 각각의 변화를 모두 기록하기 때문에 실수를 만회할 수 있다. 

BitTorrent

분산된 파일 배포 시스템이라고 정의 할 수 있다. 여기서 분산이란 하나의 서버에서 파일을 배포하는 것이 아니라, 파일을 가지고 있는 컴퓨터들로부터 조금씩 파일을 다운받은 후에 이것을 붙여서 완전한 파일을 만드는 방식이다. 대용량의 파일을 배포할 때 BitTorrent를 사용하면 비용을 크게 절감 할 수 있다. BitTorrent에 대한 자세한 설명은 생활표현의 BitTorrent 수업을 참고한다.

RSS

Reduced Redundancy Storage의 약자로 일반 S3 객체에 비해서 데이터가 손실될 확률이 높은 형태의 저장 방식. 대신에 가력이 저렴하기 때문에 복원이 가능한 데이터, 이를테면 섬네일 이미지와 같은 것을 저장하는데 적합하다. 그럼에도 불구하고 물리적인 하드 디스크 대비 400배 가량 안전하다는 것이 아마존의 주장

Glacier

영어로는 빙하라는 뜻으로 매우 저렴한 가격으로 데이터를 저장 할 수 있는 아마존의 스토리지 서비스

 

출처 : https://opentutorials.org/course/608/3006

 

Simple Storage Service(S3) - 생활코딩

S3란? Simple Storage Service의 약자로 파일 서버의 역할을 하는 서비스다. 일반적인 파일서버는 트래픽이 증가함에 따라서 장비를 증설하는 작업을 해야 하는데 S3는 이와 같은 것을 대행한다. 트래픽

opentutorials.org

 


 

📌CodeDeploy란?

 

CodeDeploy는 EC2, Lambda, On-Premise 등 다양한 컴퓨팅 서비스에 대한 배포를 자동화하는 완전 관리형 배포 서비스이다. AWS에서 완전히 관리해주는 서비스이기 때문에 신속하고 안전하게 배포가 가능하다. 또한 배포 방식도 다양하게 구성할 수 있는데 배포중인 애플리케이션이 완전히 다운되는 것을 막기 위해 최소한의 구동되고 있어야 할 인스턴스 퍼센트를 정의한다거나 Blue/Green Deployment를 수행하는 등의 과정으로 가동 중지 시간을 최소화할 수 있다.

 

CodeDeploy를 사용하기 위해서는 먼저 인프라를 프로비저닝해야 한다. Deployment에서 인프라를 자동으로 생성해주지는 않기 때문에 내가 어디에 이 애플리케이션을 배포할 것인지, 어떤 환경에 배포할 것인지 등을 정하여 미리 생성해두어야 한다. 그 후 배포하고자 하는 환경에 CodeDeploy Agent를 설치해야 한다. 설치된 agent가 지속적으로 CodeDeploy를 polling 하면서 새로 배포해야 할 정보들을 받아온다. 그 후 배포할 애플리케이션의 코드와 appspec.yml을 github 혹은 S3에 업로드한다. 여기까지 Deployment를 생성하기 위한 사전 설정이 끝났다면 CodeDeploy application을 생성한다. 그리고 배포를 수행할 배포 그룹을 설정하고 앞에서 프로비저닝한 인프라를 지정해준다. 배포 생성 후 Deploy를 생성하여 수행하면 정의한 appspec.yml에 따라 동작하며 배포한다.

 

배포 그룹을 설정하는 과정에서 생성한 인스턴스를 태그 등으로 구분할 수 있다. 여기서 CodeDeploy의 큰 장점이 등장한다. 인스턴스마다 Test, Prod, Dev 등 다양한 태그를 설정해놓은 후 각 태그별로 배포 그룹을 생성하면 각 용도에 맞는 배포 환경을 설정할 수 있다. 즉 인스턴스를 태그로 구분하여 그룹을 생성하고 각 그룹에 맞는 배포 환경을 따로 설정할 수 있다. 예를 들어 개발 환경의 경우 빠르게 결과를 확인하거나 동작 확인을 하기 위해 구성하였으므로 실제 애플리케이션 사용자에게 영향을 미치지 않기 때문에 인스턴스가 잠시 모두 다운되어도 괜찮다. 따라서 여러 인스턴스를 한번에 배포하는 'AllatOnce'로 선택하여 한번에 수행하도록 설정한다. 반면 Prod의 경우 실제 사용자에게 제공되는 배포 환경으로, 끊김없이 지속되어야 한다. 따라서 인스턴스 하나씩 배포하여 안정적인 상태를 유지하는 'OneatOnce'로 선택한다. 물론 이 외에도 원하는 만큼 인스턴스를 유지하도록 설정하는 등 다른 형태로도 배포가 가능하다.

 

CodeDeploy 역시 CloudWatch와 함께 사용할 수 있다. event의 경우 deploy가 실패했을 때 slack 알람을 가도록 설정한다던지, state가 변경될 때마다 스트림 분석을 위해 kinesis로 전송한다는 등의 설정을 할 수 있다. Logs의 경우 인스턴스에 CloudWatch log agent를 추가로 설치해야 하며 로그 정보를 확인할 수 있다.

 

배포가 실패하거나 설정한 알람이 울리는 경우 rollback 기능도 지원한다. 새로 배포한 인스턴스가 아얘 시작 자체가 안되거나 급격히 리소스 사용량이 많아지는 등 문제 상황이 발생했을 시 안정적인 버전의 애플리케이션을 다시 배포하기 위해 롤백한다.