- [C911] 가변적(mutable) 인프라와 불변적(immutable) 인프라의 차이는 무엇인가요?
가변적(mutable) 인프라
'가변'이라는 단어는 바뀌거나 달라질 수 있다 를 의미한다. 새로운 것으로 변화할 수 있다. DevOps 세계에서는 새로운 인프라 확보 걱정 없이 이전 데이터를 보존하고자 할 때 가변성의 이점이 매우 중요합니다. 패치를 적용하고, 업그레이드 또는 다운그레이드하며, 스케일업 및 스케일다운할 수 있습니다.
웹 서버를 만들어 기존 가변 인프라에 배포했다고 가정해보겠다. 사용자는 계속해서 서버에 요청을 하고, 잠시 후 서버를 변경해야 한다는 것을 알게 되었다.
이러한 변경의 장점은 기존 데이터를 새 시스템으로 이동할 필요가 없다는 것입니다. 변경 내용을 기존 버전에 적용하고 업그레이드를 원격 설치할 수 있습니다. 적절한 구성 관리를 통해 업그레이드를 성공적으로 할 수 있다.
그러나 업그레이드가 의도한 대로 원활하게 실행되지 않을 수 있다. 대부분의 변경 및 업그레이드가 결함없이 실행될 거라는 보장도 없고 운영 보안을 침해할 수도 있다. 또한 계획되지 않은 버전의 업그레이드가 완료될지도 모른다.
가변 인프라의 장점
- IT 팀은 변경이 필요할 때마다 처음부터 서버를 구축할 필요가 없습니다.
- 개별 서버에 대한 업데이트를 롤아웃하여 업데이트 프로세스를 더 빠르게 할 수 있습니다.
- 사용된 인프라가 각 사용자의 특정 요구 사항을 충족하는지 확인할 수 있습니다.
- 각 서버를 개별 수준에서 이해할 수 있으므로 문제를 진단하기가 더 쉽습니다.
가변 인프라의 단점
- 각 서버의 구성이 고유하기 때문에 각 서버를 진단하고 관리하기가 더 어려워지며 이것을 구성 드리프트라고 합니다.
- 불연속 버전 관리 - 서버에 대한 변경 사항이 문서화되지 않아 추적이 어렵고 진단이 거의 불가능합니다.
- DNS 오류 또는 네트워크 연결 불량과 같은 여러 가지 이유로 업데이트가 실패할 수 있으며, 모두 인식하고 수정하는 데 시간이 걸립니다.
- 업데이트 추적 문제로 인해 디버깅에 시간이 많이 걸립니다. 문제에 대한 통찰력 없이 여러 버전의 업데이트로 끝날 수 있습니다
불변적(immutable) 인프라
"불변"은 불변의 상태이며 이는 가변의 반대말입니다. 즉, 일단 배포되면 인프라를 수정할 수 없습니다. 변경이 필요한 경우 새로 배포하고 인프라를 추가하고 기존 인프라를 폐기해야 한다.
위의 예시를 불변적 인프라로 다시 예를 들어보겠다. 서버를 업그레이드할 때 업그레이드를 배포하지 않고 새로운 서버를 만들어 고유한 새 시스템을 만든다.
그런 다음 새로 생성된 서버가 완벽해질 때까지 여러 테스트를 수행한 다음 트래픽을 전송합니다. 이렇게 하면 문제가 있는 업그레이드 배포를 방지하고 새 서버의 기능을 확신하는 경우에만 사용자를 이전할 수 있습니다. 또한 기존의 서버를 사용할 수 없는 것도 아니다.
새 서버가 만들어지면 기존의 서버의 사용 권한을 해제할 수 있다.
클라우드 또는 마이크로서비스와 같이 상호 의존도가 높은 환경에서는 구성 드리프트를 줄일 수 있다.
불변 인프라의 장점
- 개별 버전 관리 - 각 서버 버전은 서로 독립적이며 동시에 두 가지 버전을 실행할 수 없다.
- 손쉬운 추적 - 변경이 필요할 때 새 버전의 서버를 생성하기 때문에 각 버전의 실수를 추적할 수 있습니다. 중간 영역이 없습니다.
- 각 서버의 구성이 일관되기 때문에 다른 서버를 테스트하고 업데이트를 배포하는 것이 더 쉽다.
- 서버가 동일하게 유지되므로 예측 가능성을 누릴 수 있습니다.
- 클라우드 기술과 같은 상호 의존적인 환경에 적합합니다.
- 이전 버전은 영향을 받지 않으므로 배포를 롤백할 수 있습니다.
불변 인프라의 단점
- 기존 서버는 수정할 수 없어 사소한 변경에도 서버에 대한 완전한 점검이 필요합니다.
- 데이터 저장소를 로컬 디스크에 복사하는 대신 외부화해야 합니다.
당신에게 적합한 인프라는 무엇일까?
장단점을 비교하는 것이 가장 좋은 방법이다.
가변 인프라를 선택하면 종종 스노우 플레이크 서버의 위험이 따릅니다.
한번 설치한 서버에 계속해서 설정을 변경하고 패치를 적용하는 등의 업데이트를 지속적으로 적용하여 운영하는 서버를 스노우 플레이크 서버 (눈송이 서버)라고 하는데, 이렇게 설정된 서버는 다시 똑같이 설정하기가 매우 어렵다.
가변 인프라는 고유한 구성을 가진 서버이므로 수동 관리가 필요하며 문제가 발생하면 서버에 대해 잘 알고 있는 IT 담당자 한 명만 문제를 해결할 수 있다. 특정 IT 담당자가 주변에 없으면 모든 작업을 중단해야 할지도 모른다.
또한 여러 시스템을 변경하는 경우 시간이 많이 걸리며 또한 정리 과정이 복잡합니다. 계속해서 업그레이드를 배포하는 경우 가변 인프라는 적합하지 않을 수도 있다.
불변 인프라는 자동 배포를 지원합니다. 이러한 유형의 인프라는 주로 가상화를 중심으로 구축된다. 따라서 필요에 따라 하드웨어와 소프트웨어의 프로비저닝 및 디프로비저닝에 대해 걱정할 필요가 없으며 클라우드 환경에서는 리소스를 생성하기 위해 수행한 모든 프로세스를 문서화할 수 있습니다.
DevOps 세계에서 종속성을 제한하면 시간이 절약된다. 자동화된 테스트 및 배포를 지원하는 파이프라인을 생성할 수 있고 개발 속도를 높일 수 있다.
하지만 수동 검증은 중요한 시간을 빼앗고 새로운 애플리케이션을 더 빨리 시작하는 것을 방해한다. 또한 불변적 인프라를 사용하면 시나리오를 재현하고 자동으로 재해 복구를 수행할 수 있습니다.
즉, 가변 인프라는 기존의 인프라를 변경할 수 있어 업데이트를 할 수 있는 인프라를 말하며. 불변 인프라는 기존의 인프라를 변경할 수 없어 업데이트를 하려면 새로운 인프라를 만들어야 하는 인프라를 말한다.
https://www.bridge-global.com/blog/mutable-vs-immutable-infrastructure/
- [C912] Terraform의 선언적 방식으로 작성된 코드는 항상 인프라의 최신 상태를 의미합니다. Terraform은 어떤 방식으로 인프라를 최신 상태로 유지할 수 있는 걸까요?
선언적 언어
선언적 언어는 구현하려는 최종 상태를 지정하는 코드를 말하며 이때 코드형 인프라 자체는 그러한 최종 상태를 어떻게 구현할 것인지 계산하는 역할을 말합니다.
절차적 방식
- ec2:
count: 10
image: ami-000000000
instance_type: t2.micro
-선언적 방식
resource "aws_instance" "example" {
count = 10
ami = "ami-000000000"
instance_type = "t2.micro"
}
위 두 코드는 10대의 인스턴스를 만드는 같은 코드입니다.
서버의 개수가 10대에서 15대로 변경이 필요하다고 하면 앤서블 같은 경우는 현재 배포되어 있는 서버가 몇 대 인지 파악 후 코드를 수정해야 합니다.
- 절차적 접근 방식
- ec2:
count: 5
image: ami-000000000
instance_type: t2.micro
하지만 선언적 코드는 이전 서버의 상태를 종료 후 새롭게 서버를 배포합니다.
- 선언적 접근 방식
resource "aws_instance" "example" {
count = 15
ami = "ami-000000000"
instance_type = "t2.micro"
}
Terraform init
- 지정한 backend에 상태 저장을 위한. tfstate파일을 생성합니다. 여기에는 가장 마지막에 적용한 테라폼 내역이 저장됩니다.
- init 작업을 완료하면, local에는. tfstate에 정의된 내용을 담은. terraform파일이 생성됩니다.
- 기존에 다른 개발자가 이미. tfstate에 인프라를 정의해 놓은 것이 있다면, 다른 개발자는 init작업을 통해서 local에 sync를 맞출 수 있습니다.
즉, terraform init는 가장 마지막에 적용한 테라폼 내역이 저장돼있으며 init작업을 하면 최신 버전의 내용이 담긴 terraform파일이 생기며 선언적 방식으로 작성된 코드는 서버를 업그레이드 하는 것이 아닌 기존 서버를 종료하고 새로운 서버를 만드는 것이기 때문에 늘 최신 상태의 서버를 동일하게 유지할 수 있다.
https://terraform101.inflearn.devopsart.dev/preparation/terraform-basic/