Mutable Infrastructure? Immutable Infrastructure?

 Mutable Infrastructure

필요할 때 변경하고 업그레이드하는 인프라를 말한다. 예를 들어 10 대의 VM 혹은 여러 대의 물리 서버가 있을 경우, 관리자는 SSH 접속을 통해 하나하나 접속하여 패키지를 수동으로 업그레이드 하거나 다운그레이드 하면서 직접 관리한다. 그리고 기존 서버에 직접 새 코드를 배포한다. 이 과정에서 패키지 설치 혹은 변경에 실패할 수 도 있고 성공할 수 도있다. 이로 인해서 서버간의 조금씩 차이가 발생하게 된다. 제각기 다른 크기의 눈송이와 같다고 하여 snowflake server 라 부른다. 다른 용어로는 configuration drift 라고 한다.

Immutable Infrastructure

Mutable 과는 다르게, 한 번 프로비전되거나 배포가 되었을 때 해당 서버의 변경을 만들지 않는다. 변경사항이 발생하거나 업데이트가 필요할 때는 해당 서버에서 작업하지 않고, 새로운 VM 혹은 이미지를 통해서 서버를 생성하고 교체한다. 이전 버전의 서버는 버려진다. 재에서 부터 다시 살아나는 피닉스에 비유하여 Phoenix server 라 부른다.


Pet (Snowflake Server) and Cattle (Phoenix Server)

눈송이 서버와 피닉스 서버 처럼 비유되는 또 다른 표현이 있다. 바로 pet 과 cattle 이다.



왜 snowflake server 를 pet 에 비유했을까? pet 은 애완동물이다. 애완동물은 하나하나 제각기 주인들에게 특별하게 여겨지며 사랑받는다. 강아지의 경우 이름은 "호두", "룽지", "희동이" 등 각각 특별하다. 이는 snowflake server 처럼 각각의 서버가 다르게 설정될 수 있다는 것에 비유해서 pet 이라는 별칭이 붙게 되었다.


그렇다면 phoenix server 는 어째서 cattle 에 비유될까? cattle 은 소, 가축을 의미한다. 보통 농장에서 가축을 키울 때, 애완동물과는 다르게 사육한다. 가축에게는 애완동물처럼 특별한 이름이 없다. 그리고 소1, 소2, 소3, 돼지1, 돼지2, 돼지3 처럼 큰차이가 없다. 이처럼 각각의 가축을 서로간의 거의 동일한 것을 의미한다. 그리고 광우병이나 구제역으로 인해서 죽을 경우 새로운 가축으로 교체된다는 점에서 Immutable Infrastructure 에 비유된다.

Cloud 이전과 이후



현재는 Cloud 의 시대이다. 빅3 aws, azure, gcp 이외에도 클라우드 서비스는 너무나도 넘쳐난다. IaaS 가 아니라도, Heroku 와 같은 PaaS 들이 너무나도 많다. 너무나도 쉽게 서비스를 호스팅할 수 있다. 하지만, Cloud 이전에는 서비스를 운영하기 위해서는 개인 혹은 기관 조직들이 각자가 물리 머신을 관리하고 운영해야 되었다. 이는 금전적인 면이나 시간적인 면에서 비용이 많이 든다. 특히 초기 설비를 설정하는데 더욱이 많이 든다.

Mutable Infrastructure 는 Cloud 이전 시대에 매우 적절했다. server 를 교체하는 비용은 매우 크기 때문이다. 중지 시간을 최소한으로 유지하면서 계속해서 서버를 돌리는 것이 가장 실용적이다. 정기 배포 및 업데이트 그리고 임시 수정, 조정 및 패치에 대해서도 해당 서버 내에서 일어났다. 빈번한 수동 변경의 결과는 동일한 환경을 유지하기 어려워 졌으며 각각의 서버는 좋지 않은 고유함을 유지하게 되었다.

Cloud 의 시대가 오면서, server architecture 에 전환점이 되었다. 물리 서버를 운영하는 것에 비해서 가상 서버는 비교적 저렴하고 확장에도 굉장히 쉬웠다. 생성 및 파괴에 몇분이면 되었다. configuration management 혹은 cloud apis 를 이용한 새로운 배포 워크플로우 그리고 서버 관리 기술들이 생겨났다. 이러한 기술들은 매우 빠르게 프로그래밍적으로 그리고 자동화를 통해서 새로운 서버를 프로비전 할 수 있게 했다. 이러한 가격 경쟁과 속도로 인해서 Immutable Infrastructure 를 시작하게 한다.

Immutable Infrastructure 장점

장점을 이해하기 위해서는 mutable infrastructure 의 단점을 보완하기 위해서 immutable infrastructure 가 나오게 된 배경을 이해해야 한다.

mutable infrastructure server 는 문서화되지 않은 변화들이 서버의 설정들을 바꾸고 이는 각각의 서버가 본래의 의도와는 다르게 설정된 차이들이 매우 커지는 문제점을 겪는다. 이는 진실의 원천을 알 수 없으며, 재생산에 이슈를 유발하고 다른 서버로 교체하기 매우 곤란해진다. 또한 원인을 밝히기 굉장히 어렵다. 또한 운영환경과 스테이징 환경의 불일치를 유발할 수 있다.

수많은 수동 변경후에 각각의 서버들은 다른 설정을 가지게 되며 각각의 차이점에 대해서 불분명해지는 점이 가장 힘들며 이는 의도하지 않은 부수효과를 일으킨다.

긍정적으로 configuration drift 가 없는 상태에서라도, 시스템의 변경이 올바르게 작동할 것이라는 것을 보장하기 쉽지 않다.

이러한 문제점들을 해결해주는 것이 immutable infrastructure 이다. immutable infrastructure 는 단순하며, 안정적이고 일관적이다.

배포의 안정성

immutable infrastructure 에서 배포는 검증되고 버저닝이 되는 이미지를 통해서 새로운 서버를 프로비저닝한다. 이는 결과적으로, 이전 상태의 서버에 의존하지 않는 것을 말한다. 따라서 실패의 위험성이 적다.

새로운 서버들이 프로비전 되었을 때, 실제로 사용하기 이전에 테스트를 해볼 수 있다. 예를 들어 blue-green deployment 기법과 같이 새로 교체할 환경에 대해서 먼저 테스트를 진행하고 환경을 교체할 수 있다. 따라서 배포를 원자적으로 다룰 수 있다. 이는 보다 배포가 안정적이며 모든 서버의 상태를 검증할 수 있다. 또한 중지 없이 운영이 가능하다.

Configuration drift 또는 Snowflake Servers 가 없다

인프라에 대한 설정 변경은 문서화와 자동화 그리고 배포 프로세스를 통해서 이루어지며 검증된 이미지를 통해 서 서버가 교체된다. 또한 Shell Access 를 제한하여 운영 환경에서 부적절한 변경을 방지할 수 있다.

일관적인 스테이징 환경과 쉬운 수평 확장

모든 서버는 동일한 생성 프로세스를 거치기 때문에, 배포에 있어서 특별한 상황이 없다. 따라서 스테이징 환경과 프로덕션 환경 불일치를 예방할 수 있다. 또한 서버의 동일함을 쉽게 보장함으로써 수평확장에 어려움이 없다.

단순한 롤백과 장애 복구 프로세스

이미지에 대한 버저닝은 프로덕션 환경의 이슈 해결에 도움이 된다. 롤백에 있어서 이전 버전의 이미지를 사용함으로써 쉽게 해결할 수 있다.


Immutable Infrastructure 를 이행하기 위해서 어떤 것을 해야할까?

  • cloud computing 환경과 같이 custom image 를 사용하고 API 혹은 자동화 툴을 이용하여 인스턴스를 빠른속도로 생성하고 파괴 할 수 있어야 한다.
  • 전체 배포 파이프라인은 모두 자동화 되어야한다. 예를 들어 이미지를 생성한 후에 검증 및 테스트를 자동으로 해야된다. 
  • Service Decomposition - infrastructure 를 모듈로 분해하고, 네트워크를 통해서 통신할 수 있도록 한다. 이는 cloud computing 을 최대한 활용할 수 있다.
  • stateless, volatile application layer - immutable server 안에서 유지해야 한다. 데이터 손실 없이 언제든지 생성하고 파괴할 수 있어야한다. 
  • persistent data layer
    • Centralized logging  - server 는 언제든지 생성하고 파괴된다. 따라서 로그와 메트릭을 중앙화된 외부 시스템을 사용함으로써 언제든지 쉽게 debugging 이 가능하게 해준다.
    • External data stores - database 와 같이 다른 stateful layer 는 server 에 있어서는 안된다. server 는 휘발성이기 때문이다.
참조 및 읽어볼 거리

댓글

이 블로그의 인기 게시물

About JVM Warm up

About idempotent

About Kafka Basic

About ZGC

sneak peek jitpack

Spring Boot Actuator readiness, liveness probes on k8s

About Websocket minimize data size and data transfer cost on cloud

About G1 GC

대학생 코딩 과제 대행 java, python, oracle 네 번째