[배포] Amazon Web Service

 

 

• 학습 내용

작성한 코드를 로컬 환경에서만이 아닌 도메인과 같은 주소를 통해서 다른 사람이 서비스를 이용하게 하기 위해선 배포가 필요하다. 내가 진행한 두 번의 프로젝트에서는 aws를 이용하여 프리티어 ec2와 rds 그리고 s3를 빌려 배포를 했다. 첫 번째 프로젝트에서는 http까지 배포를 성공했고, 두 번째 프로젝트에서는 https까지 진행했다. 하면서 느낀 점은 생각보다 엄청 까다롭고 다루기가 어렵다는 것이다. 특히 보안에 관련된 문제들이 머리를 많이 아프게 했다. 그리고 지금 다시 이 레퍼런스를 정리하면서 느낀 것은 이 문서를 좀 더 꼼꼼히 보았다면 좀 더 빨리 해결할 수 있지 않았을까란 생각이 든다. 돌아와서 배포에 관한 기본적인 개념과 원리를 정리해보고자 한다.

 

• Cloud Computing

컴퓨터를 확장하고자 할 때 두 가지 방법을 사용할 수 있다. 먼저 컴퓨터의 성능을 높이는 방법, 그리고 컴퓨터의 개수를 늘리는 방법이다. 그러나 이러한 방법들에 문제점들이 있다. 첫 번째로 주기적인 관리가 필요하다. 컴퓨터의 개수를 늘리면 관리해야 하는 컴퓨터의 개수가 늘어나기 때문에 많은 인력 및 비용이 소요된다. 둘째로 공간의 한계가 있다. 지속적인 확장이 필요할 때 더 이상 컴퓨터를 배치할 수 없는 문제에 반드시 직면하게 된다. 이런 상황들로 일부 거대 기업은 데이터 센터라는 거대한 건물을 세우기 시작했다. 이때부터 데이터 센터의 유휴 자원을 대여하는 서비스가 등장하기 시작했다. 즉, 서버의 자원과 공간, 및 네트워크 환경을 제공받아 사용하는 클라우드 컴퓨팅이 시작된 것이다.

 이러한 데이터 센터에서 서버의 자원과 공간, 및 네트워크 환경을 제공하는 환경을 '온프레미스'라고 한다. 현대의 클라우드 컴퓨팅은 앞서 설명한 데이터 센터와 비슷한 역할을 하지만 물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여한다는 점이 다르다. 이는 가상화(Virtualization) 기술의 발전으로부터 비롯되었다. 따라서 최근의 가상화 기술을 사용하는 클라우드 서비스는 기존의 온프레미스 형식과는 다르게 필요할 때마다 컴퓨팅 능력을 유연하게 조절하거나 고정적인 비용이 들어가는 온프레미스와 달리 사용한 만큼만 요금을 지불하거나 컴퓨터의 스냅샷('이미지')을 이용해 다른 컴퓨터로 즉시 이주가 가능하다는 장점들이 있다.

 그러나 이런 클라우드도 단점이 있는데, 운영 환경 자체가 클라우드 제공자에게 종속되어 버려서 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향을 미친다는 것이다. 그리고 운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 것은 백엔드 구성 자체가 특정 회사의 기술로만 구성해야만 하는 경우가 발생할 수 있다.

 이런 클라우드들은 모든 것을 서비스화하는 것을 목표로 한다. 대표적인 클라우드 서비스의 형태는 SaaS, IaaS, PaaS 세 가지가 있다. SaaS는 Software as a Service의 약자로 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당한다. PaaS는 Platform as a Service로 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우에 해당하고 마지막으로 IaaS는 Infrastructure as a Service의 약자로 클라우드 제공자가 가상 컴퓨터를 제공하는 경우 대부분을 말한다.

 

• Deploy

배포란 개발한 서비스를 사용자가 이용 가능하게 하는 과정이다. 기본적으로 4단계를 거쳐 개발한 서비스를 배포한다. 먼저 Development 단계는 각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정이다. 개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트한다. 변경사항이 있어도 문제가 되지 않으며 모든 구성원이 각자의 환경에서 진행한다. Integration 단계는 각자의 컴퓨터에서 작성한 코드를 합치는 과정이다. 내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지 코드 간에 conflict가 있지는 않은지 확인하는 과정이다. 작성한 코드가 다른 코드에 문제를 발생시키지 않는지 확인한다.

 Staging 단계에서는 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행한다. 실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행한다. 또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거친다. 예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀이 예산했던 결과인지 확인을 거치는 과정이다. 마지막으로 Production 단계는 개발된 서비스를 출시하는 단계이다. 사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공한다. 실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안 되는 단계이다.

 Development 환경과 Production 환경은 서로 다를 수가 있다. 여러 명이 함께 작업하는 프로젝트의 경우 node 버전이 제각각이고 인증 정보나 데이터베이스 등에 접근하기 위해 사용하는 엔드포인트도 제각각이다. 따라서 배포에서는 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요하다. 작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면 설정의 환경 변수(envvars나 env라고도 불림)에 저장해야 한다. 환경 변수는 코드 변경 없이 배포 때마다 쉽게 변경할 수 있다. 설정 파일과 달리 잘못해서 코드 저장소에 올라갈 가능성도 낮다. 그 외에도 docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일시켜준다.

 

• EC2

EC2(Elastic Compute Cloud)란 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스이다. 클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스이다. Elastic이란 '탄력적인'이라는 의미를 가지고 있는 단어이다. 즉 비용적인 부분뿐만 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미를 가진다. 즉 EC2 서비스는 AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있다. 

 EC2 서비스의 장점으로 먼저 구성하는 데 필요한 시간이 짧다. 왜냐하면 EC2 서비스는 몇 번의 클릭만으로 PC를 구성할 수 있기 때문이다. 둘째로 AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능하다. EC2에서 AMI라는 다양한 템플릿을 제공하고 있어서 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있다. 운영체제뿐만 아니라 CPU와 RAM, 용량까지도 손쉽게 구성할 수 있다. 셋째로 EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다. 빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에 컴퓨터를 조작하기 위해 네트워크를 통해서 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점이 없다. 아마존 EC2를 옹해서 할 수 있는 가장 기본적인 일은 웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것이다. 인스턴스는 1대의 컴퓨터를 의미하는 단위이고 AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 말한다.

 위에서 잠깐 언급한 AMI에 대해 살펴보면 AMI(Amazon Machine Image)는 소프트웨어 구성이 기재된 탬플릿이다. 이미지 종류로 단순히 운영체제(윈도우, 우분투, 리눅스 등)만 깔려있는 탬플릿을 선택할 수도 있고 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있다. (우분투 + node.js, 윈도우 + JVM 등) AWS에서 빌릴 PC는 사용용도에 맞게 운영체제, 런타임 등이 구성된 Setting을 선택할 수 있다.

 Instance는 선택한 AMI를 토대로 구성한다. AWS에 상당히 많은 양의 AMI 세팅이 준비되어 있기 때문에 손쉽게 인스턴스의 운영체제를 구성할 수 있다. 세팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성할 수도 있다. 즉, AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것을 말한다.

 

• RDS

RDS란 Relational Database Service의 약자로 AWS에서 제공하는 관계형 데이터베이스 서비스이다. EC2가 가상의 컴퓨터를 임대하는 서비스이기 때문에 EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하면 굳이 RDS를 사용할 필요가 없을 수도 있다. 그러나 EC2 인스턴스에 관계형 데이터베이스 엔진을 설치해서 데이터를 관리하는 것은 RDS를 통해 데이터를 관리할 때의 차이는 개인 소유 차량과 리스차의 차이로 비유할 수 있다. 그래서 전자의 경우는 정비나 관리를 개인이 지속적으로 해줘야 하는 부담이 있다. 그러나 반대로 후자의 경우는 관리의 영역은 RDS를 대여해준 곳에서 대신해준다. 사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있는 것이다. 또한 RDS를 이용하면 데이터베이스 엔진 선택지를 제공받을 수 있다는 장점이 있다. 실무지의 필요한 데이터베이스 엔진을 취사선택해서 이용할 수 있는 것이다.

 

• S3

클라우드 스토리지란 인터넷 공간에 데이터를 저장하는 저장소이다. 컴퓨터 부품으로 비유하면 하드디스크 역할을 하는 서비스이다. 예시로 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 것들이 있다. 이와 같은 클라우드 스토리지 서비스의 장점은 뛰어난 접근성이 있다. 컴퓨터의 하드디스크의 경우 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 한다. 그러나 클라우드 소토리지를 이용하면 웹 환경에선 언제나 저장된 파일에 접근할 수 있다. 컴퓨터의 하드디스크의 경우 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 한다. 그러나 클라우드 스토리지를 이용하면 웹 환경에선 언제나 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 한다. 그러나 클라우드 스토리지를 이용하면 웹 환경에선 언제나 저장된 파일에 접근할 수 있다. 

 여기서 S3란 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스이다. S3 역시 뛰어난 접근성을 가지고 있다. 뿐만 아니라 확장성, 내구성, 가용성, 다양한 클래스 제공, 정적 웹 사이트 호스팅 가능이라는 장점들을 가진다. S3는 높은 확장성을 가진다. 확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있다. 무한히 확장할 수 있고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서도 매우 효율적이다. 또한 강력한 내구성을 가지는데, S3는 99.999999999%의 내구성을 보장한다. 내구성이 높으면 저장된 파일을 유실할 가능성이 적어진다. 높은 가용성으로 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다. S3는 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있다. 이는 다른 말로 1년 동안 S3에 파일을 저장했을 시, 8.76시간 동안만 스토리지를 이용하는 데 있어서 장애가 발생한다는 뜻이다.

 그러면 어떻게 이런 높은 가용성과 높은 내구성을 보장할 수 있을까? 리전(Region)이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻한다. 그리고 가용 영역이란 각 리전 안에 존재하는 데이터 센터(IDC)를 뜻하는데, 이 가용 영역이 각각 개별적인 위치에 떨어져서 존재하여 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되도록 한다는 것에 그 이유가 있다. 이런 가동 방식 덕분에 AWS에서 제공하는 서비스들은 높은 가용성과 내구성을 보장하는 것이다.

 또한 S3는 다양한 스토리지 클래스를 제공한다. 목적에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라지는 것이다. 대표적으로 많이 선택하는 소토리지 클래스에 Standard 클래스와 Glacier 클래스가 있다. Standard 클래스는 범용적인 목적으로 사용하기 좋다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르기 때문이다. 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아니다. 보관 비용이 높게 발생하기 때문이다. 반대로 장기적인 보관 목적으로 스토리지를 사용할 때는 Glacier를 사용하는 것이 효율적이다. 저장된 데이터에 액세스하는 속도는 느리지만 데이터를 보관하는 비용이 매우 저렴하다.

 S3 사용 시 얻는 이점 중 하나로 정적 웹 사이트 호스팅이 가능하다. 정적 웹 사이트 호스팅을 알기 위해서 '정적' 파일에 대한 이해가 필요하다. 정적 파일은 서버의 개입 없이 생성된 파일을 뜻한다. 물론 반대로 클라이언트가 서버에 요청을 보내서 서버가 요청에 맞추어 그 자리에서 생성한 파일을 '동적'파일이라고 부른다. 그리고 웹 호스팅이란 서버의 한 공간을 임대해 주는 서비스를 뜻한다. S3에서 버킷이 사용자이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다. 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.

 여기서 또 버킷이란 무엇일까? 버킷이란 S3에 저장되는 파일들이 담기는 바구니이다. 파일을 저장하는 최상위 디렉토리라고도 설명할 수 있다. S3에 저장되는 모든 파일은 버킷 안에 저장되어야 하고 버킷에는 무한한 양의 파일을 저장할 수 있다. 그리고 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다. 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수도 있다. S3에서 버킷에 담기는 파일을 객체라고 부르는데 왤까? 왜냐하면 S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문이다. S3에 저장되는 객체는 파일과 메타데이터로 구성된다. 파일의 값에는 실제 데이터를 저장하고 S3 객체의 값으로써 저장될 수 있는 데이터의 최대 크기는 5TB이다. 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 한다. 파일의 키를 이용하여 원하는 객체를 검색할 수 있는 것이다. 메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터이다. 모든 객체는 고유한 URL 주소를 가지고 있고 URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띤다. 이 URL 주소를 통해 원하는 데이터에 접근할 수도 있다.

 

• 배포 전략

개발한 서비스를 사용자가 이용할 수 있도록 하는 것을 배포라고 한다. 먼저 작성한 Client 코드를 사용자들에게 제공하기 위해서 AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공할 수 있다. 로컬 환경에서는 자체 개발 서버를 이용해서 클라이언트 앱을 실행시키는 것이 보통이다. 그러나 클라이언트 앱을 정적 파일로 빌드하여 제공할 수 있다. 따라서 S3를 이용해서 클라이언트를 배포한다. 여기서 필요한 것이 빌드이다. 빌드란 불필요한 데이터를 없애고 여러 걸래로 퍼져있는 데이터들을 통합/압축하여 배포하기에 최적화된 상태를 만드는 것이다. 빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고 웹 사이트의 로딩 속도가 빨라진다는 장점이 생긴다.

 그러나 일반적인 의미의 빌드는 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미한다. 웹 앱에서와 같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다르다,. 웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 한다. asset 자체가 정적인 경우 있는 그대로 배포하면 된다. React의 경우 npm run build와 같은 명령을 사용해서 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 된다.

 또 AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있다.

 AWS EC2 서비스를 활용하면 손쉽게 서버를 구성하고 서비스를 제공할 수 있다. 또한 AWS에서는 Datebase 특화 서비스인 RDS 서비스를 제공하고 있다. AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있다. RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있다. 

 마지막으로 S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 계획한 서비스와는 전혀 상관없는 긴 도메인 주소를 통해 접근하게 된다. 이때 AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있다.