개발의 마지막 과정 배포
클라우드 컴퓨팅
영화에서 서버실을 해커가 침투해서 해킹을 하는 장면이 많이 나오는데
그 서버실에서 추가적으로 많은 일을 처리하기 위해 서버를 증진 해야하는데,
기존의 서버 이를 해결하기 위해
-
같은 공간에 더 많은 컴퓨터를 추가
-
컴퓨터 한 대의 성능을 업그레이드한다 (한 컴퓨터가 기존 2대 컴퓨터의 일을 하는 방식)
이 방식의 한계는 바로 나타나는데
-
많은 컴퓨터를 추가 했다는 것은 곧 주기적인 관리에 있어서 많은 인력과 비용이 투입되어야한다는 것.
-
공간의 한계 (요즘 땅 값도 비싼데 계속 늘릴 수 없음)
이 특히 공간의 한계를 해결하기 위해서 대기업들이 데이터 센터라는 거대한 건물을 짓고 그곳에서
서버를 개설하였는데 원래 기존보다 당연히 많은 자원이 남아돌게 되었고 자연스럽게
렌트카 마냥 유휴 자원을 대여하는 서비스가 등장하기 시작했는데 이것이 바로
클라우드이며 서버의 자원과 공간 및 네트워크 환경을 제공을 빌려 사용하는 클라우드 컴퓨팅이 시작되었다.
-데이터센터-
클라우드 서비스 등장과 장점
위에 설명했듯이 클라우드가 등장하면서 서버의 자원과 공간 네트워크 환경 제공이 필요한 사람들이
필요할 때마다 피씨방 마냥 사용한 만큼의 요금을 주면서 이용할 수 있게 되었다.
또한 다른 컴퓨터로 즉시 이주도 가능!
조금 더 자세하게 들여다보면
유휴 자원이 있는 데이터 센터에서 서버의 자원과 공간 네트워크 환경 제공을 해주는데 이러한 환경을 온프레미스라고 부른다.
즉, 온프레미스는 물리적으로 존재하는 컴퓨터를 대여하는 것
하지만 가상화 기술이 날로 발전함에 따라 물리적인 컴퓨터가 아닌 가상 컴퓨터를 대여해주게 되었다.
그래서 최근의 클라우드 서비스는 가상화 기술을 이용하며 장점으로는
-
필요할 때마다 컴퓨터 능력을 유연하게 조절
-
고정적인 비용이 들어가는 온프레미스와 달리 사용한 만큼 요금 지불
-
컴퓨터의 스냅샷(이미지)를 이용해 다른 컴퓨터로 즉시 이주(migration) 가능
클라우드의 단점
운영 환경 자체가 AWS같은 웹 서비스를 빌려 쓰는 거기 때문에 제공해주는 데이터 센터 자체에 문제가 발생하면 당연히 그걸 가져다가 쓰는 사용자들도 영향이 올 수 밖에없다.
(피씨방에서 피씨를 사용하기 위해 돈을 지불하고 피씨를 이용하고있는데 정전이 되었다고 생각해보자.)
즉, 운영 환경이 클라우드 제공자에게 종속이 되어서 클라우드 서비스에 문제가 생기면 배포하고 관리하는 환경에도 영향을 미치게 되는 단점이 존재한다.
note: 운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 얘기는, 백엔드 구성 자체가 특정 회사의 기술로만 구성 해야만 하는 경우가 발생할 수도 있다는 이야기입니다.
클라우드 서비스 형태
-
Saas(Software as a Service)
-App, data, O/S 등등 클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 -
Iaas(Infrastructure as a Service)
- AWS, Microsoft Azure, Google Cloud Platform(firebase)
- 클라우드 제공자가 가상 컴퓨터까지 제공하는 경우
- Paas(Platform as a Service)
- API를 제공하는 개발 가능한 플랫폼
- 대부분 클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우
배포(Deployment)
개발한 서비스를 사용자들이 이용가능하게 하는 일련의 과정
기본적인 4단계를 거친 후에 배포(회사마다 다름)
Development -> Intergration -> Staging -> Production
-
개발(Development)
1-1) 각자의 Local 컴퓨터 환경에서 개발 및 테스트
1-2) 개발 단계이며 실제 데이터를 사용하지 않고 Sample Data를 이용하여 개발
1-3) 변경사항이 있어도 문제가 되지 않음
1-4) 모든 구성원이 각자의 환경에서 진행 -
통합(Intergration)
1-1) 각자의 환경에서 개발된 코드를 합치는 과정
1-2) 작성한 코드들이 서로 Conflict가 없는지 확인하는 단계 -
시연, 상연(Staging)
1-1) 실제 출시 단계인 Production와 유사한 환경에서 테스트를 진행
1-2) 복제된 실제 데이터를 이용하여 테스트
1-3) 모든 관계자들에게 검증하는 단계 -
출시(Production)
1-1) 실제 개발된 서비스를 출시하는 단계(실제로 서비스가 제공되는 단계)
1-2) 개발된 환경과는 구분된 환경
1-3) 실제 데이터를 이용하여 사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공(여기서 문제시 초비상)
- Development 환경과 Production 환경은 서로 다를 수가 있습니다.
따라서 배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요합니다
작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?
1. 절대경로 대신 상대경로를 사용
2. 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정
3. Docker와 같은 개발 환경 자체를 통일 시키는 솔루션 사용
NOTE: 작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?
설정을 환경 변수(envvars나 env라고도 불림)에 저장해야한다.
환경 변수는 코드 변경 없이 쉽게 배포 때마다 쉽게 변경할 수 있습니다.
설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮습니다.
애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은 어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다.
슬라이드에 나온 내용은 이러한 환경 설정을 코드로부터 분리하는 방법론을 이야기하고 있습니다.
코드상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용해야 하며, .env 등을 이용해 환경 변수를 설정하세요.
그 외에도 docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일시킵니다.
