웹사이트 검색

불변 인프라란?


소개

기존의 변경 가능한 서버 인프라에서 서버는 지속적으로 업데이트되고 제자리에서 수정됩니다. 이러한 종류의 인프라로 작업하는 엔지니어와 관리자는 SSH를 통해 서버에 접속하고, 패키지를 수동으로 업그레이드 또는 다운그레이드하고, 서버별로 구성 파일을 조정하고, 새 코드를 기존 서버에 직접 배포할 수 있습니다. 즉, 이러한 서버는 변경 가능합니다. 만든 후에 변경할 수 있습니다. 변경 가능한 서버로 구성된 인프라는 자체적으로 변경 가능하거나 전통적이거나 (비하적으로) 장인적이라고 할 수 있습니다.

불변 인프라는 서버가 배포된 후 수정되지 않는 또 다른 인프라 패러다임입니다. 어떠한 방식으로든 업데이트, 수정 또는 수정이 필요한 경우 적절한 변경 사항이 포함된 공통 이미지에서 구축된 새 서버가 기존 서버를 대체하도록 프로비저닝됩니다. 유효성이 확인된 후 사용에 투입되고 이전 항목은 폐기됩니다.

변경 불가능한 인프라의 이점에는 인프라의 일관성 및 안정성 향상과 더 간단하고 예측 가능한 배포 프로세스가 포함됩니다. 구성 드리프트 및 눈송이 서버와 같이 변경 가능한 인프라에서 일반적으로 발생하는 문제를 완화하거나 완전히 방지합니다. 그러나 이를 효율적으로 사용하려면 포괄적인 배포 자동화, 클라우드 컴퓨팅 환경에서 빠른 서버 프로비저닝, 로그와 같은 상태 저장 또는 임시 데이터를 처리하기 위한 솔루션이 포함되는 경우가 많습니다.

이 기사의 나머지 부분은 다음과 같습니다.

  • 변경 가능한 인프라와 변경 불가능한 인프라 사이의 개념적 및 실질적인 차이점 설명
  • 변경할 수 없는 인프라 사용의 이점을 설명하고 복잡성을 맥락화합니다.
  • 불변 인프라에 대한 구현 세부 정보 및 필수 구성 요소에 대한 높은 수준의 개요 제공

변경 가능한 인프라와 변경 불가능한 인프라의 차이점

변경 가능한 인프라와 변경 불가능한 인프라 사이의 가장 근본적인 차이점은 중앙 정책에 있습니다. 전자의 구성 요소는 배포 후 변경되도록 설계되었습니다. 후자의 구성 요소는 변경되지 않고 궁극적으로 교체되도록 설계되었습니다. 이 자습서는 이러한 구성 요소를 서버로 집중적으로 다루지만 컨테이너와 같이 동일한 상위 수준 개념을 적용하는 변경 불가능한 인프라를 구현하는 다른 방법이 있습니다.

더 자세히 알아보기 위해 서버 기반 변경 가능 인프라와 변경 불가능 인프라 사이에는 실용적이고 개념적인 차이가 있습니다.

개념적으로 말하면 두 종류의 인프라는 서버를 처리하는 방법(예: 생성, 유지 관리, 업데이트, 파괴)에 대한 접근 방식이 크게 다릅니다. 이것은 일반적으로 애완 동물 대 소 비유로 설명됩니다.

실질적으로 말하면, 변경 가능한 인프라는 변경 불가능한 인프라를 가능하고 실용적으로 만드는 가상화 및 클라우드 컴퓨팅과 같은 핵심 기술 이전의 훨씬 오래된 인프라 패러다임입니다. 이 역사를 알면 둘 사이의 개념적 차이와 현대 인프라에서 둘 중 하나를 사용할 때의 의미를 맥락화하는 데 도움이 됩니다.

다음 두 섹션에서는 이러한 차이점에 대해 자세히 설명합니다.

실질적인 차이점: 클라우드 수용

가상화와 클라우드 컴퓨팅이 가능해지고 널리 사용되기 전에 서버 인프라는 물리적 서버를 중심으로 이루어졌습니다. 이러한 물리적 서버는 생성하는 데 많은 비용과 시간이 소요되었습니다. 새 하드웨어를 주문하고 기계를 구성한 다음 콜로 또는 유사한 위치에 설치하는 데 걸리는 시간 때문에 초기 설정에 며칠 또는 몇 주가 걸릴 수 있습니다.

변경 가능한 인프라는 여기에 그 기원이 있습니다. 서버를 교체하는 비용이 너무 많이 들기 때문에 가동 중지 시간을 최대한 줄이면서 실행한 서버를 최대한 오래 계속 사용하는 것이 가장 실용적이었습니다. 이는 정기적인 배포 및 업데이트뿐만 아니라 무언가 잘못되었을 때 임시 수정, 조정 및 패치에 대한 많은 변경 사항이 있음을 의미했습니다. 빈번한 수동 변경의 결과로 서버는 복제하기 어려워져 각 서버가 전체 인프라의 고유하고 깨지기 쉬운 구성 요소가 됩니다.

새로운 서버를 프로그래밍 방식으로 자동으로 프로비저닝하기 위한 클라우드 API의 출현. 새로운 가상 서버를 생성하는 속도와 저렴한 비용은 불변성 원칙을 실용적으로 만드는 것입니다.

기존의 변경 가능한 인프라는 원래 물리적 서버의 사용이 관리에서 가능한 것을 지시할 때 개발되었으며 시간이 지남에 따라 기술이 개선됨에 따라 계속 발전했습니다. 배포 후 서버를 수정하는 패러다임은 현대 인프라에서 여전히 일반적입니다. 반대로 불변 인프라는 처음부터 클라우드 컴퓨팅의 가상 서버와 같은 아키텍처 구성 요소의 빠른 프로비저닝을 위해 가상화 기반 기술에 의존하도록 설계되었습니다.

개념적 차이: 애완동물 vs 소, 눈송이 vs 불사조

클라우드 컴퓨팅이 발전하면서 근본적인 개념적 변화는 서버가 일회용으로 간주될 수 있다는 것입니다. 물리적 서버를 폐기하고 교체하는 것을 고려하는 것은 엄청나게 비현실적이지만 가상 서버를 사용하면 가능할 뿐만 아니라 쉽고 효율적입니다.

기존의 변경 가능한 인프라에 있는 서버는 대체할 수 없고 항상 실행해야 하는 고유한 시스템이었습니다. 이런 식으로 그들은 애완 동물과 같았습니다. 종류 중 하나이고 흉내낼 수 없으며 손으로 돌보는 경향이 있습니다. 하나를 잃는 것은 치명적일 수 있습니다. 반면에 불변 인프라의 서버는 일회용이며 자동화된 도구로 쉽게 복제하거나 확장할 수 있습니다. 이런 식으로 그들은 소와 같습니다. 독특하거나 없어서는 안 될 개인이 없는 무리의 많은 것 중 하나입니다.

클라우드 컴퓨팅에 처음으로 애완동물과 소의 비유를 적용한 Randy Bias의 말을 인용하면 다음과 같습니다.

이전 방식에서는 서버를 애완 동물처럼 취급합니다. 예를 들어 메일 서버인 Bob이 있습니다. Bob이 쓰러지면 모든 것이 갑판에 있습니다. CEO는 이메일을 받을 수 없으며 세상의 종말입니다. 새로운 방식으로 서버는 무리의 소처럼 번호가 매겨집니다. 예를 들어 www001에서 www100까지입니다. 한 서버가 다운되면 다시 꺼내어 총에 맞고 라인에서 교체합니다.

서버를 처리하는 방식의 차이가 의미하는 바를 설명하는 또 다른 유사한 방법은 눈송이 서버와 피닉스 서버의 개념을 사용하는 것입니다.

Phoenix 서버는 소와 비슷합니다. 그들은 항상 처음부터 구축되고 자동화된 절차를 통해 쉽게 재생성(또는 "재에서 부활\)할 수 있는 서버입니다.

변경 불가능한 인프라는 거의 전적으로 가축 또는 피닉스 서버로 구성되는 반면 변경 가능한 인프라는 일부(또는 많은) 애완 동물 또는 눈송이 서버를 허용합니다. 다음 섹션에서는 둘 다의 영향에 대해 설명합니다.

불변 인프라의 장점

불변 인프라의 장점을 이해하려면 가변 인프라의 단점을 맥락화해야 합니다.

변경 가능한 인프라의 서버는 문서화되지 않은 즉석 변경으로 인해 서버의 구성이 서로 간에 그리고 검토, 승인 및 원래 배포된 구성과 점점 더 멀어지는 구성 드리프트로 인해 어려움을 겪을 수 있습니다. 이러한 눈송이 모양의 서버는 재생산 및 교체가 어렵기 때문에 확장 및 문제 복구와 같은 작업을 어렵게 만듭니다. 프로덕션 환경과 일치하는 스테이징 환경을 만드는 것이 어렵기 때문에 문제를 디버깅하기 위해 복제하는 것조차 어려워집니다.

서버의 다른 구성의 중요성이나 필요성은 많은 수동 수정 후에 명확하지 않으므로 구성을 업데이트하거나 변경하면 의도하지 않은 부작용이 발생할 수 있습니다. 최선의 경우에도 기존 시스템을 변경하는 것은 작동을 보장하지 않습니다. 즉, 변경에 의존하는 배포는 실패하거나 서버를 알 수 없는 상태로 만들 위험이 있습니다.

이를 염두에 두고 변경할 수 없는 인프라를 사용하는 주요 이점은 배포 단순성, 안정성 및 일관성이며, 이 모든 것이 궁극적으로 많은 일반적인 문제와 실패 지점을 최소화하거나 제거합니다.

정상 작동이 확인된 서버 상태 및 배포 실패 감소

변경할 수 없는 인프라의 모든 배포는 검증되고 버전 제어되는 이미지를 기반으로 새 서버를 프로비저닝하여 실행됩니다. 결과적으로 이러한 배포는 서버의 이전 상태에 의존하지 않으므로 이로 인해 실패하거나 부분적으로만 완료될 수 없습니다.

새 서버가 프로비저닝되면 사용하기 전에 테스트할 수 있으므로 로드 밸런서 업데이트와 같이 실제 배포 프로세스를 단일 업데이트로 줄여 새 서버를 사용할 수 있도록 합니다. 즉, 배포는 원자성이 됩니다. 성공적으로 완료되거나 아무 것도 변경되지 않습니다.

이렇게 하면 배포가 훨씬 더 안정적이고 인프라에 있는 모든 서버의 상태를 항상 알 수 있습니다. 또한 이 프로세스를 통해 가동 중지 시간이 없는 롤링 릴리스를 쉽게 구현할 수 있습니다.

구성 드리프트 또는 눈송이 서버 없음

변경할 수 없는 인프라의 모든 구성 변경은 업데이트된 이미지를 문서와 함께 버전 제어에 체크인하고 자동화된 통합 배포 프로세스를 사용하여 해당 이미지로 대체 서버를 배포하는 방식으로 구현됩니다. 서버에 대한 쉘 액세스는 때때로 완전히 제한됩니다.

이것은 눈송이 서버 및 구성 드리프트의 위험을 제거하여 복잡하거나 재현하기 어려운 설정을 방지합니다. 이것은 또한 누군가가 제대로 이해되지 않은 프로덕션 서버를 수정해야 하는 상황을 방지합니다. 이로 인해 오류 위험이 높고 가동 중지 시간이나 의도하지 않은 동작이 발생할 수 있습니다.

일관된 스테이징 환경 및 손쉬운 수평 확장

모든 서버가 동일한 생성 프로세스를 사용하기 때문에 배포 엣지 케이스가 없습니다. 이렇게 하면 생산 환경을 쉽게 복제할 수 있으므로 지저분하거나 일관되지 않은 스테이징 환경을 방지할 수 있으며 인프라에 더 많은 동일한 서버를 원활하게 추가할 수 있으므로 수평적 확장이 간소화됩니다.

간단한 롤백 및 복구 프로세스

버전 제어를 사용하여 이미지 기록을 유지하는 것도 생산 문제를 처리하는 데 도움이 됩니다. 새 이미지를 배포하는 데 사용되는 것과 동일한 프로세스를 사용하여 이전 버전으로 롤백할 수도 있으므로 다운타임을 처리할 때 탄력성을 추가하고 복구 시간을 줄일 수 있습니다.

불변 인프라 구현 세부 정보

변경 불가능한 인프라에는 특히 기존의 변경 가능한 인프라와 비교할 때 구현 세부 사항에 몇 가지 요구 사항과 미묘한 차이가 있습니다.

불변성의 핵심 원칙을 고수함으로써 자동화, 도구 또는 소프트웨어 설계 원칙과 독립적으로 불변 인프라를 구현하는 것이 기술적으로 가능합니다. 그러나 규모에 따른 실용성을 위해 아래 구성 요소(대략 우선 순위)를 강력히 권장합니다.

  • 클라우드 컴퓨팅 환경의 서버 또는 다른 가상화된 환경(컨테이너와 유사하지만 아래의 다른 요구 사항이 변경됨). 여기에서 핵심은 맞춤형 이미지에서 빠르게 프로비저닝할 수 있는 격리된 인스턴스를 보유하고 API 등을 통해 생성 및 소멸을 자동으로 관리하는 것입니다.\n
  • 이상적으로 생성 후 이미지 유효성 검사를 포함하여 전체 배포 파이프라인의 완전 자동화. 이 자동화를 설정하면 이 인프라를 구현하는 초기 비용이 상당히 추가되지만, 이는 빠르게 상각되는 일회성 비용입니다.\n
  • 유사한 서비스 지향(예: IaaS, PaaS).\n
  • 변경할 수 없는 서버를 포함하는 상태 비저장 휘발성 애플리케이션 계층입니다. 여기에 있는 모든 항목은 데이터 손실(상태 비저장) 없이 언제든지 신속하게 파괴 및 재구축(휘발성)될 수 있습니다.\n
  • 다음을 포함하는 영구 데이터 계층:\n
    • 버전 또는 Git 커밋 SHA를 통한 이미지 식별과 같은 서버 배포에 대한 추가 세부 정보가 포함된 중앙 집중식 로깅. 이 인프라에서는 서버가 일회용(및 자주 폐기)되기 때문에 외부에 로그 및 메트릭을 저장하면 셸 액세스가 제한되거나 서버가 파괴된 후에도 디버깅이 가능합니다.
    • 데이터베이스용 외부 데이터 저장소 및 개체 또는 블록 저장소(클라우드 제공 또는 자체 관리)와 같은 기타 상태 저장 또는 임시 데이터. 서버가 휘발성일 때 로컬 저장소에 의존할 수 없으므로 해당 데이터를 다른 곳에 저장해야 합니다.

    접근 방식에 협력하고 전념하기 위한 엔지니어링 및 운영 팀의 헌신. 최종 제품의 모든 단순성을 위해 변경 불가능한 인프라에는 움직이는 부분이 많이 있으며 아무도 그 모든 것을 알 수 없습니다. 또한 이 인프라 내에서 작업하는 일부 측면은 디버깅이나 셸 액세스 없이 일회성 작업을 수행하는 것과 같이 새롭거나 사람들의 안전 영역을 벗어날 수 있습니다.

    이러한 각 구성 요소를 구현하는 방법에는 여러 가지가 있습니다. 하나를 선택하는 것은 개인의 선호도와 친숙도, 그리고 유료 서비스에 의존하는 것과 비교하여 직접 구축하려는 인프라의 양에 따라 달라집니다.

    프로덕션 환경에서 임의로 서버를 죽이는 Netflix의 Chaos Monkey는 최종 설정에 대한 실제 시험입니다.

    결론

    이 기사에서는 변경 불가능한 인프라가 무엇인지, 변경 불가능한 인프라와 이전 스타일의 변경 가능한 인프라 사이의 개념적 및 실질적인 차이점, 이를 사용하는 이점 및 구현에 대한 세부 정보를 다루었습니다.

    불변 인프라로의 이동을 고려해야 하는지 여부 또는 시기를 아는 것은 어려울 수 있으며 명확하게 정의된 컷오프 또는 변곡점은 없습니다. 시작하는 한 가지 방법은 여전히 변경 가능한 환경에서 작업하는 경우에도 구성 관리와 같이 이 기사에서 권장하는 일부 설계 방식을 구현하는 것입니다. 이렇게 하면 향후 불변성으로의 전환이 더 쉬워질 것입니다.

    위의 구성 요소 대부분이 포함된 인프라가 있고 확장 문제에 부딪히거나 배포 프로세스의 투박함에 좌절감을 느낀다면 불변성이 인프라를 어떻게 개선할 수 있는지 평가하기 시작하기에 좋은 시기입니다.

    불변 인프라 구현에 대해 작성한 여러 회사(Fugue 포함)에서 자세히 알아볼 수 있습니다.