이번 포스팅에서는 클라우드의 개념과 AWS EC2, S3 등에 대한 내용을 정리하겠습니다.
클라우드란?
과거에는 회사의 전살실 등에 컴퓨터(서버)를 배치하고 인터넷을 연결해서 네트워크를 구성했습니다. 시간이 지남에 따라 자원들을 집중 관리하기 위해서 데이터 센터에서는 슈퍼 컴퓨터(서버)를 배치하여 다양한 자원과 공간 및 네트워크 환경들을 제공했습니다. 데이터 센터에서 유휴 자원을 대여하는 것을 온 프레미스 방식이라고 합니다.
기존의 온 프레미스 방식은 서버의 수가 많을 수록 관리하기 어려워지고 비용이 증가하며 공간적 한계를 가진다는 단점이 있었습니다. 이러한 문제를 해결하고자 가상화 기술 사용해 가상 컴퓨터를 사용자에게 대여하는 클라우드 서비스가 등장했습니다.
클라우드 서비스는 가상화된 컴퓨터를 대여한다는 점에서 효율적인 서비스 구축 방법이지만 클라우드 서비스에 장애가 발생할 경우 제공자에게 종속되어 운영 중인 서비스 환경에 영향을 미칩니다.
클라우드 종류
SaaS
SaaS는 Software as a Service의 약자로 클라우드 제공자가 네트워크, 하드웨어, 운영체제, DB 등 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당합니다.
Paas
PaaS는
IaaS
IaaS는
EC2(Elastic Compute Cloud)
EC2(Elastic Compute Cloud)는 AWS에서 원격으로 제어할 수 있는 가상의 컴퓨터를 빌리는 것을 의미 합니다. Elastic이라는 단어 처럼 탄력적으로 사용한 만큼 비용을 지불하는 서비스입니다. 그리고 빌릴 수 있는 컴퓨터의 성능, 자원 또한 탄력적으로 조절이 가능합니다.
AWS 홈페이지에서 클릭 몇 번만으로도 가상화된 컴퓨터를 대여 받을 수 있습니다. 우선, CPU, RAM, 운영체제들을 선택한 후 가상화된 컴퓨터 1대 대여 받습니다. 이렇게 대여받은 컴퓨터를 인스턴스라고 부릅니다.
AMI
AMI는 소프트웨어 구성이 기재된 템플릿입니다. 컴퓨터를 대여할 때, 운영체제만 설치된 환경을 선택할 수도 있고 Node.js, JVM 등 프로그래밍 언어의 런타임이 설치된 환경도 선택할 수 있습니다.
RDS(Relational Database Service)
EC2 서비스를 통해서 컴퓨터를 대여 받아 웹 서비스를 배포할 때, DB 설치에 대한 고민을 하게 됩니다. 물론 대여받은 컴퓨터에 DB를 설치할 수 있겠지만 DB 설치, 규모 확장, 가용성, 데이터 백업 등 많은 수고가 들어가는 작업 입니다. AWS에서는 별도의 RDS 대여하고 자동적으로 관리하는 기능을 지원합니다. 사용자는 초기 설정만 하면 별도로 DB를 관리할 필요가 없습니다.
S3(Simple Storage Service)
S3는 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스입니다. S3에서는 스토리지의 용량을 무한히 확장할 수 있습니다. 그리고 사용한 만큼만 비용을 지불하면 되기 때문에 비용적인 측면에서 매우 효율적입니다.
AWS는 전 세계에 많은 데이터 센터를 가지고 있어 하나의 센터가 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 불러와 사용할 수 있습니다. 그렇기에 가용성이 매우 높습니다.
S3의 종류
가장 많이 사용하는 클래스로는 Standard 클래스와 Glacier 클래스가 있습니다.
Standard 클래스
Standard 클래스는 범용적인 목적으로 사용하기 좋습니다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠릅니다. 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아닙니다. 보관 비용이 높게 발생하기 때문입니다.
Glacier 클래스
비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있습니다.
그 외 클래스
이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있습니다.
정적 호스팅
S3를 사용하면 정적 웹 사이트 호스팅이 가능합니다. S3의 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공합니다. 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있습니다.
버킷
버킷이란 S3에 저장되는 파일들이 담기는 바구니입니다. 파일을 저장하는 최상위 디렉터리라고도 설명할 수 있습니다.
S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있습니다. 그리고 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 합니다.
또한 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있습니다.
S3에서 버킷에 담기는 파일을 객체라고 부릅니다. 왜 객체라고 부를까요?? S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문입니다.
S3에 저장되는 객체는 파일과 메타데이터로 구성됩니다. 파일에 대해서 먼저 알아보겠습니다. 파일은 위에 설명한 대로 키-값 페어 형식으로 데이터를 저장합니다.
파일의 값에는 실제 데이터를 저장합니다. S3 객체의 값으로써 저장될 수 있는 데이터의 최대 크기는 5TB입니다.
파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 합니다. 파일의 키를 이용하여 원하는 객체를 검색할 수 있습니다.
메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터입니다. 객체를 설명하는 데이터라고 이해하시면 좋습니다.
모든 객체는 고유한 URL 주소를 가지고 있습니다.
URL 주소는 http://[버킷의 이름].S3.amazonaws.com/[객체의 키]의 형태를 띠고, URL 주소를 통해서도 원하는 데이터에 접근할 수 있습니다.
웹 서비스 배포 전략
Client 배포
Client를 배포할 때 S3를 이용해서 클라이언트를 정적 파일로 빌드한 후 배포합니다. 빌드란 쉽게 말해서 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것입니다. 빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다는 장점이 생깁니다.
하지만 일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미합니다. 웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다릅니다. 웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 합니다.
asset 자체가 정적인 경우, 있는 그대로 배포하면 됩니다. React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 됩니다. 사용하고 있는 환경에 따라 빌드 과정은 다를 수 있습니다.
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있습니다.
Server Application 배포
AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다. AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있습니다.
AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있습니다.
RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있습니다.
도메인 접근
AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있습니다.
실제 배포 하기
서비스를 개발하면 기본적으로 다음과 같은 4단계를 거쳐서 개발한 서비스를 배포하게 됩니다.
-
[Development]
각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정입니다.개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트합니다. -
[Integration]
각자의 컴퓨터에서 작성한 코드를 합치는 과정입니다. 내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드 간에 conflict가 있지는 않은지 확인하는 과정을 거칩니다. -
[Staging]
실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행합니다. 실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행합니다. 또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다. 예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀이 예상했던 결과인지 확인을 거치는 과정입니다. -
[Production]
개발된 서비스를 출시하는 단계입니다. 사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공합니다. 실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안 되는 단계입니다.
하지만, Development 환경과 Production 환경은 서로 다를 수가 있습니다. node 버전, 인증정보, 데이터 베이스 접근 방식 등 신경써야할 것이 많습니다. 이런 문제를 해결하기 위해서는 환경 설정을 코드와 분리 해야합니다.
다른 환경에서 코드가 작동하기 위한 방법
- 절대경로 대신 상대경로를 사용합니다.
- 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정해줍니다.
- Docker와 같은 환경 자체를 통일시키는 솔루션을 사용합니다.(docker와 같은 가상화 도구로 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일시킵니다.)
