Cloud Computing

등장 배경

기존 서버의 방식은 같은 공간에 더 많은 컴퓨터를 추가하면 공간이 모자라지는 문제점이 있었다. 컴퓨터 성능 업그레이드를 통한 문제 해결방식도 있지만, 궁극적인 해결책은 아니였다.

  • 주기적인 유지 관리가 필요하다.
    서버실 고장은 인력 및 비용이 투입되어야했다.
    (컴퓨터 수가 증가함에 따라 인력 및 비용도 함께 증가한다.)

  • 공간의 한계
    일정한 공간에 컴퓨터를 무한하게 배치할 수 없는 문제에 직면했다.

위와 같은 이유로 서버의 자원과 공간, 네트워크 환경을 제공해 빌려 사용하는 클라우드 컴퓨팅이 시작됐다.


Cloud 등장

서버의 자원과 공간, 및 네트워크 환경 제공 필요할 때마다 컴퓨팅 능력을 유연하게 조절
(사용한 만큼의 요금만 지급) 다른 컴퓨터로 즉시 이주가 가능하다.

Cloud

  • 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있다.
  • 고정 비용과 달리 사용한 만큼 요금을 지불하면 된다.
  • 컴퓨터의 스냅샷을 이용해 다른 컴퓨터로 즉시 이주가 가능하다.

Cloud 단점

  • 운영 환경 자체가 클라우드 제공자에게 종속되어 버린다. 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향을 미친다.

  • 특정 회사 이용 시 운영환경을 특정 회사에 맞춰야 한다.


Cloud 서비스 범위

  • SaaS: Software as a Service
    클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당된다.

  • PaaS: Platform as a Service
    클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 PaaS에 해당된다.

  • IaaS: Infrastructure as a Service
    클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 IaaS에 해당된다.

AWS는 IaaS에 가깝습니다.


Deploy (배포)

배포란 개발한 서비스를 사용자들이 이용 가능하게 하는 일련의 과정입니다.
(기본적으로 4단계 거쳐 개발한 서비스를 배포하게 됩니다.)

Development

  • Local 환경에서 개발 및 테스트
  • Sample Data 이용
  • 변경사항이 있어도 문제가 없다.
  • 모든 구성원이 각자의 환경에서 진행

Integration

  • 각자 환경에서 개발된 부분을 취합
  • 코드간 conflict 없는지 확인하는 단계
  • 작성한 코드가 다른 코드에 문제를 발생시키지 않는지 확인

Staging

  • Production 단계와 가장 유사한 환경에서 테스트
  • 실제 데이터를 이용해서 테스트
  • 모든 관계자들이 검증

Production

  • 개발 환경과는 구분 된 환경
  • 실제 데이터를 사용
  • 실제로 서비스 제공

배포에서는 Local 환경과의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요합니다.


작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?

  • 절대경로 대신 상대경로를 사용한다.
  • 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정한다.
  • Docker와 같은 개발 환경 자체를 통일시키는 솔루션을 사용한다.

작성한 코드를 다른 환경에서 정상 작동할 수 있게하려면, 설정을 환경 변수 (env or envvars)에 저장해야 합니다.
(환경 변수는 코드 변경 없이 배포 마다 쉽게 변경할 수 있습니다.)

코드 상의 모든 경로는 절대 경로가 아닌 상대 경로를 사용해야 하며, .env 를 이용해 환경 변수를 설정합니다.

그 외 docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아 모든 개발 환경을 통일 시킵니다.


EC2 (Elastic Compute Cloud)

아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스입니다.
클라우드 컴퓨팅은 인터넷(클라우드)를 통해 서버, 스토리지, 데이터 베이스 등의 컴퓨팅 서비스를 제공합니다.

그냥 아마존에서 컴퓨터 한대 빌린다고 생각하면 된다.
(집에다 고가의 컴퓨터를 구매할지, PC방 가서 게임할지..?)

EC2 장점

  • 구성하는 데 필요한 시간이 짧다. (클릭 몇 번으로 컴퓨팅 서비스를 받을 수 있다.)

  • 다양한 운영체제에 대한 선택이 가능하다. (Window, Linux, Ubuntu 등)
    운영체제 뿐 아니라 CPU, RAM, 용량까지 쉽게 구성할 수 있다.


AWS에서 빌리는 컴퓨터를 Instance라고 한다.

EC2의 가장 기본적인 일은 웹 서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것입니다.
(Instance는 1대의 컴퓨터를 의미하고 AWS에서 컴퓨터를 빌리는 것을 Instance를 생성한다고 합니다.)


AMI는 소프트웨어 구성이 기재된 템플릿

운영체제(Window, Ubuntu, Linux)가 깔려있는 템플릿을 선택할 수 있고, 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있습니다.

AWS에서 빌릴 PC는 사용용도에 맞게 운영체제, 런타임 등이 구성된 Settings를 선택할 수 있습니다.

다양한 AMI 세팅이 준비되어 있고, 손쉽게 인스턴스의 운영체제를 구성할 수 있습니다.

AWS EC2 Instance를 생성한다는 것은 AMI를 바탕으로 운영체제, CPU, RAM 등이 구성된 컴퓨터를 빌리는 것입니다.


RDS (Relational Database Service)

AWS에서 제공하는 관계형 데이터베이스 서비스 입니다.

RDS를 사용하는 이유

EC2는 가상의 컴퓨터를 임대하는 서비스입니다. EC2 Instance에 MySQL과 같은 데이터베이스 엔진을 설치해 사용하면 관리를 담당하는 사람이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 합니다.
(EC2에서는 데이터베이스 규모의 확장 또한 어렵습니다.)

따라서 RDS를 사용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 관리합니다.


S3 (Simple Storage Service)

클라우드 스토리지란?

인터넷 공간에 데이터를 저장하는 저장소
(컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스입니다.)

ex) 구글의 Google Drive, 네이버의 MyBox, Microsoft의 OneDrive

S3 사용 시 장점

  • 확장성
    데이터를 무한히 저장 가능하다.
    확장성이 높으면 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소 할 수 있습니다. (비용만 지불한다면 무한히 확장 가능하다.)

  • 내구성
    데이터가 유실된 가능성이 매우 낮습니다.

  • 가용성
    스토리지에 저장된 파일들이 정상적으로 사용될 수 있는 시간이 길어집니다.
    (S3는 1년에 8시간 정도만 점검을 합니다.)

S3의 종류 (Standard & Glacier)

  • Standard: 범용적으로 사용됩니다. 데이터에 빠른 속도로 접근할 수 있고, 엑세스 요청에 대한 처리 속도가 빠르다. 하지만 데이터를 오래 보관하기에는 좋지 않다. (보관비용이 높다.)

  • Glacier: 장기적인 보관을 해야한다면 Glacier가 효율적입니다. 속도는 느리지만 데이터 보관비용이 저렴하다.

S3 사용 시 장점2

정적 웹 사이트 호스팅이 가능하다.

서버의 개입 없이 생성된 파일을 뜻합니다.

S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공합니다. 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성해 정적 웹 사이트를 배포할 수 있습니다.

버킷이란?

  • 버킷은 파일을 담는 바구니로 최상위 디렉토리입니다.
  • 무한히 많은 파일 저장이 가능하다.
  • 버킷의 이름은 각 리전에서 고유하다.
  • 버킷의 정책을 생성해 엑세스 권한을 부여할 수 있다.

S3에서 버킷에 담기는 파일을 객체라고 부릅니다. S3에 저장될 데이터는 키-값 페어 형식으로 저장됩니다.
(파일의 키는 식별자 역할을 한다.)

  • S3객체의 값으로 저장될 수 있는 데이터의 최대 크기는 5TB입니다.

모든 객체는 고유한 URL 주소를 가지고 있고, 양식이 있다.
http://[버킷이름].S3.amazonaws.com/[객체키] 형태다. URL 주소를 통해 원하는 데이터에 접근할 수 있다.


Deploy Strategy (배포 전략)

개발한 서비스를 사용자가 이용할 수 있도록 하는 것을 배포라고 합니다.

배포 전 생각해봐야 할 것!

  • 사용자들에게 Client는 어떻게 제공할지
  • Server는 어떻게 제공할 것인지
  • Database는 어떻게 제공할 것인지

Client 배포

AWS에서 제공하는 S3를 통해 Client를 제공할 수 있습니다.

Client를 위해 EC2 Instance를 반드시 사용할 필요는 없습니다.
Client 앱을 정적 파일로 빌드하여 제공할 경우 S3를 이용해 Client를 배포할 수 있습니다.

이때 필요한 것이 빌드입니다.

빌드란 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터를 통합/압축하여 배포에 최적화된 상태를 만드는 것입니다. (빌드를 하면 데이터의 용량이 줄어들고, 웹 사이트 로딩 속도가 빨라진다.)

일반적으로 빌드는 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미합니다. 웹앱에서와 같이 HTML, CSS, JS의 형태로 배포하는 경우는 다릅니다. 웹앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 합니다.

AWS에서 제공하는 CDN 서비스 CloudFront는 데이터 센터에 데이터를 분산 저장해 사용자에게 빠른 서비스를 제공합니다.


Server Application 배포

안정적으로 서비스를 제공하기 위해 EC2를 빌려 서버코드를 구동할 수 있습니다.

Database 배포

AWS Database 특화 서비스 RDS를 통해 서비스를 제공합니다.

RDS서비스를 통해 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 DB를 배포할 수 있습니다.

DNS

직관적으로 서비스를 이해할 수 있고 짧은 주소를 통해 서비스에 접근할 수 있게 하기 위해서는 Route53 서비스를 이용합니다.

profile
메일은 매일 확인하고 있습니다. 궁금하신 부분이나 틀린 부분에 대한 지적사항이 있으시다면 언제든 편하게 연락 부탁드려요 :)

0개의 댓글