환경 배포 살펴보기

서버에 발생한 크래시 때문에 한밤중에 긴급 지원 전화를 받은 적이 있다고 가정해 보겠습니다.

이 경우 새 머신을 설정하는 수동 단계에 액세스하기 위해 여러 스프레드시트나 심지어 메모리를 검색하는 데 따른 어려움을 잘 알고 있습니다.

그 이후에는 개발 및 프로덕션 환경을 일관되게 유지하는 어려움도 있습니다.

머신을 초기화할 때 사용자 오류가 발생할 가능성을 없애는 더 쉬운 방법은 IaC(Infrastructure as Code)를 사용하는 것입니다.

수동 배포와 IaC(Infrastructure as Code) 비교

수동 배포와 IaC(Infrastructure as Code) 간의 차이점을 일반적인 비유를 통해 이해하려면 반려동물을 소유하는 것과 소를 소유하는 것의 차이점을 생각해 보면 됩니다.

반려동물이 있는 경우 각 반려동물의 이름을 정하고 각기 개별 개체로 간주합니다. 반려동물 중 하나에게 끔찍한 문제가 발생하는 경우에는 해당 반려동물에게 많은 관심을 가질 것입니다.

소 떼가 있는 경우에도 각 소의 이름을 정해줄 수는 있지만, 소 떼로만 간주합니다.

인프라 측면에서 단일 시스템이 충돌하고 이를 교체해야 하는 경우(애완 동물) 수동 배포 접근 방식에 심각한 영향을 미칠 수 있습니다.

IaC(Infrastructure as Code) 방식을 채택하면 머신 한 대가 다운되는 경우 전체 인프라(소 떼)에 부정적인 영향을 주지 않고 다른 머신을 손쉽게 프로비저닝할 수 있습니다.

IaC(Infrastructure as Code)를 사용하면 환경(한 개 또는 여러 개)을 텍스트 파일(스크립트 또는 정의)로 캡처할 수 있습니다.

파일에는 네트워크, 서버 및 기타 컴퓨팅 리소스가 포함될 수 있습니다.

스크립트 또는 정의 파일을 버전 제어에 체크 인한 후 기존 환경을 업데이트하거나 새 환경을 만들기 위한 원본으로 사용할 수 있습니다.

예를 들어 릴리스 파이프라인을 환경으로 원격 처리하고 수동으로 새 서버를 프로비저닝하는 것이 아니라 텍스트 파일을 편집하고 릴리스 파이프라인을 실행하여 새 서버를 추가할 수 있습니다.

다음 표에는 수동 배포와 IaC(Infrastructure as Code) 간의 중요한 차이점이 나열되어 있습니다.

수동 배포	코드 제공 인프라(Infrastructure as code)
Snowflake 서버	환경 간 일관된 서버
배포 단계가 환경에 따라 달라짐	환경이 쉽게 만들어지거나 스케일링됨
더 많은 확인 단계와 더 정교한 수동 프로세스	환경 업데이트가 완전히 자동으로 생성됨
차이점을 고려하기 위한 설명서가 늘어남	변경이 불가능한 인프라로 전환
오류에서 복구할 시간을 확보하기 위해 주말에 배포	블루/그린 배포 사용
번거로움과 주말에 긴 시간을 할애하는 일을 최소화하기 위해 릴리스 주기가 긺	서버를 반려동물이 아닌 소로 처리

다음 목록은 IaC(Infrastructure as Code)의 이점입니다.

배포된 항목, 시기, 방법을 더 쉽게 추적할 수 있도록 하여 감사를 향상합니다. (즉, 추적 가능성을 개선합니다.)
릴리스에서 릴리스까지 일관된 환경을 제공합니다.
개발, 테스트, 프로덕션 환경에서 일관성이 향상됩니다.
스케일 업 및 스케일 아웃 프로세스를 자동화합니다.
구성의 버전을 제어할 수 있습니다.
인프라 변경 내용을 관리하는 데 유용한 코드 검토 및 단위 테스트 기능을 제공합니다.
불변 서비스 프로세스를 사용합니다. 즉, 환경에 변경이 필요한 경우 새 서비스가 배포되고 이전 서비스가 중단되면 업데이트되지 않습니다.
블루/그린 배포를 허용합니다. 이 릴리스 방법론은 두 개의 동일한 환경(하나는 라이브이고 다른 하나는 그렇지 않음)이 존재하는 가동 중지 시간을 최소화합니다. 업데이트는 라이브 상태가 아닌 서버에 적용됩니다. 테스트가 확인 및 완료되면 다른 라이브 서버로 교체됩니다. 해당 서버가 새 라이브 환경이 되며 이전 라이브 환경은 더 이상 라이브 상태가 아닙니다.
인프라를 필요에 따라 프로비저닝, 프로비전 해제, 다시 프로비저닝할 수 있는 유연한 리소스로 처리합니다.