기존 서버의 방식:
서버실과 같은 곳에 컴퓨터를 배치, 컴퓨팅 능력이 더 필요하다면?
같은 공간에 더 많은 컴퓨터를 제공하여 한 대가 해결할 수 있는 요청을 여러 대가 나누는 방식을 사용할 수 있습니다.
혹은 컴퓨터 한 대의 성능을 높이는 방식을 사용할 수도 있습니다.
하지만 이런 방식은 몇 가지 문제점들을 가지고 있습니다.
-
주기적인 관리가 필요합니다.
흔히 말하는 서버실에는 종종 고장이 나거나 인터넷과 연결이 되지 않는 컴퓨터가 생기기도 합니다. 이런 상황이 발생한다면 이를 해결하기 위한 인력 및 비용이 투입되어야 했습니다.
그러나 점차 관리해야 하는 컴퓨터 및 전자기기의 수가 많아지는 만큼 투입되어야 하는 인력 및 비용도 증가하기 시작했습니다. -
공간의 한계가 있습니다.
예전의 방식은 서버실이라는 공간에 컴퓨터를 배치해 두고 필요할 때마다 추가적인 컴퓨터를 추가하는 방식으로 수용 능력을 향상해 왔습니다.
하지만 이런 방식은 공간이 부족하여 컴퓨터를 더는 배치할 수 없는 문제에 직면하게 됩니다.
이런 상황에서 서버의 컴퓨팅 능력을 늘리려는 방법은 컴퓨터의 성능을 높이고 부피를 줄여 좀 더 많은 컴퓨터를 같은 동간에 배치하는 방법이었습니다.
이런 상황에서 추가적인 서버 증설이 어렵게 되자 일부 거대 기업은 데이터 센터라는 거대한 건물을 세우기 시작했습니다.
이때부터 데이터 센터의 유휴자원을 대여하는 서비스가 등장하기 시작했습니다.
즉 서버의 자원과 공간, 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작된 순간입니다.
클라우드의 등장
서버의 자원과 공간, 및 네트워크 환경 제공
필요할 때마다 컴퓨팅 능력을 유연하게 조절
사용한 만큼의 요금만 지급
다른 컴퓨터로 즉시 이주(migration)가 가능
앞서 말씀드렸다시피, 데이터 센터에서는 서버의 자원과 공간, 및 네트워크 환경을 제공합니다.
(이러한 환경을 "온프레미스"라고 부릅니다.)
현대의 클라우드 컴퓨팅은 앞서 설명한 데이터 센터와 비슷한 역할을 하지만,
물리적인 컴퓨터가 아닌, 가상 컴퓨터를 대여한다는 점이 다릅니다. 이는 가상화(Virtualization) 기술의 발전으로부터 비롯되었습니다.
따라서, 최근의 가상화 기술을 사용하는 클라우드 서비스는 기존의 온프레미스 형식과는 달리 다음과 같은 장점이 있습니다.
1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있습니다.
2. 고정적인 비용이 들어가는 온프레미스와는 달리 사용한 만큼의 요금만 지불하면 됩니다.
3. 컴퓨터의 스냅샷("이미지"라고 부릅니다.)을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능합니다.
- 클라우드 환경의 단점
아마존 웹 서비스의 장애로 특정 서비스의 서버가 지연되었다는 기사가 있음.
이처럼 운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향이 미칩니다.
운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 얘기는, 백엔드 구성 자체가 특정 회사의 기술로만 구성해야만 하는 경우가 발생할 수도 있다는 이야기입니다.
따라서 AWS와 같은 대표적인 클라우드 사업자가 제공하는 기술을 익히는 것도 중요하지만, 그만큼 이 인프라자체에 대한 이해가 더욱 중요합니다.
클라우드는 모든 것을 서비스화하는 것을 목표로 합니다.
대표적인 클라우드 서비스의 형태는 SaaS, IaaS, PaaS 세 가지입니다.
SaaS는 Software as a Service의 약자입니다.
클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우
PaaS는 Platform as a Service의 약자입니다.
클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우
IaaS는 Infrastructure as a Service의 약자입니다.
클라우드 제공자가 가상 컴퓨터까지 제공하는 경우
Deploy
사용자가 서비스를 이용할 수 있게 하는 배포에 대해 알아보자
Deployment
배포란 개발한 서비스를 사용자가 이용가능하게 하는 과정입니다.
4단계를 거쳐서 개발한 서비스를 배포
-
Development
Local 컴퓨터 환경에서 개발 및 테스트
Sample Data를 이용 (더미 데이터를 이용)
변경사항이 있어도 문제가 되지 않음
모든 구성원이 가자의 환경에서 진행 -
Integration
각자의 환경에서 개발된 부분을 취합
코드간 Conflict가 없는지 확인하는 단계
작성한 코드가 다른 코드에 문제를 발생시키지 않는지 확인 -
Staging
Production 단계와 가장 유사한 환경에서 테스트
복제된 실제 데이터를 이용해서 테스트
모든 관계자들에게 검증하는 단계
서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다.
작성된 코드가 마케팅팀 혹은 디자인팀이 예상했던 결과인지 확인을 거치는 과정입니다. -
Production
개발환경과는 구분된 환경
실제 데이터를 이용
실제로 서비스가 제공되는 단계
개발된 서비스를 출시하는 단계입니다.
배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요합니다.
작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?
설정을 환경 변수(envvars나 env라고도 불림)에 저장해야 합니다.
환경 변수는 코드 변경 없이 배포 때마다 쉽게 변경할 수 있습니다.
설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮습니다.
애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은 어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다.
슬라이드에 나온 내용은 이러한 환경 설정을 코드로부터 분리하는 방법론을 이야기하고 있습니다.
절대 경로 대신 상대경로를 사용합니다.
환경에 따라 포트를 분기할 수 있도록 환경변수를 설정해 줍니다. (.env등을 이용)
Docker와 같이 개발 환경 자체를 메타데이터로 담아서 통일시키는 솔루션(가상화 도구)을 사용합니다.
배포를 위한 다양한 플랫폼들:
aws, heroku, DigitalOcean, Microsoft Azure, Firebase
