읽게 된 이유

docker, kubernetes에 대해 알아보면서 인프라를 명시적으로 정의해 관리하는 과정을 자연스럽게 접했다. 처음에는 툴이나 튜토리얼을 주먹구구식으로 해보는것이 좋지만, 삽질했던 것들을 정리할 베이스 지식이 궁금하여 이 책을 접하게 되었다.

정의

Infrastructure as Code ( 이하 IaC ) - 말그대로 기존의 인프라 셋업 과정을 코드로 관리하는 것을 일컫는 말이다.

IaC는 일반적인 툴이나 프로세스가 아니라 패러다임에 가깝다.

왜 등장했는가?

IT 운영관리 쪽의 기존의 과중한 업무를 최근 발달한 기술을 통해 더욱 자동화되고 그 과정에서 나온 패러다임이다.

물론 이러한 방식이 새로 나온 개념은 아니라고 생각한다. 그 전부터도 SE 엔지니어 쪽에서 가상화 등으로 하던 방식이 컨테이너(docker), 클라우드 같은 툴과 기술의 발전으로 진입장벽이 낮아지고, 또한 그에 따라 많은 개발자들이 관심을 가지기 시작했다.

IaC의 장점?

• 기존의 주먹구구식이 아닌 일관성 있는 관리 가능
• snowflake server 생성 방지
• 인프라 관리도 기존 코드 관리의 장점을 따름 ( 협업, 모듈화, 버전 관리, CI/CD 등 )
• 애플리케이션 개발자도 IT 인프라 담당자를 거치지 않고 원하는 자원을 정의, 프로비저닝 관리 가능

IaC의 조건

• 멱등적이어야 한다.
• 쉽게 만들 수 있어야 한다. 이렇게 해야 구성을 변경할때 위험 요소와 두려움을 제거해줌
• 시스템은 일회용이다라고 가정하고 쉽게 삭제/교체/재조정 이동이 가능해야 한다. 하드웨어 신뢰성이 보장되지 않을때 필요

"서버를 애완동물이 아닌 가축처럼 취급하라"

"신뢰할 수 있는 하드웨어 위에 있는 신뢰할수 없는 소프트웨어" -> "신뢰할 수 없는 하드웨어 위에서 신뢰성 있게 동작하는 소프트웨어"

• 작은 요소라도 일관성이 있어야 한다. 이렇게 해야 자동화를 신뢰할 수 있게된다.
• 절차가 반복가능해야 한다. -> 스크립트 작성
• IaC != 클라우드
• 클라우드랑 공유하는 장단점이 있지만 둘은 다르다.
• IaC는 베어메탈 서버에도 가능함, 물론 클라우드 쪽에서 많이 쓰긴하지만

키워드

• snowflake(눈송이) server

  재현할 수 없는 서버, "눈처럼 녹아버리는" 서버, 예를 들어 여러 서버를 관리하다보면 일부 서버에만 설정이 변경되어 일관적이지 않은 상태가 되고, 거기에 문서화까지 되어 있지 않아 다른 장비에 os를 새로 인스톨하여 환경을 재현하려 해도 제한이 있는 상황이 있다. 작은 설정이면 문제가 안되겠지만 가능성이 분명히 존재한다.

후기

이론적인 내용만 나와서 실망했다는 후기 블로그를 봤는데 이해가 간다. 뭔가 나올거 같은 느낌이 들면서도 비슷한 얘기가 반복된다.

사실 전체적으로 개발, CI/CD, 테스트 등 반복적으로 언급된 내용에서 '인프라'를 '코드'으로 바꿔도 문장에 크게 이질감이 없고 또한 그렇게 의도한듯 하다. 결국 인프라라는 것도 코드처럼 생각하라는 뜻이니까.

카페24 호스팅을 사용중이기 때문에 이 책에 등장한 툴들을 적용하는 것은 불가능하고 굳이 하자면 서버 셋업 스크립트 정도는 만들어 유지할 수 있겠다. 물론 이것도 IaC와는 거리가 멀다. 사실 이런 식의 인프라 관리는 특히 클라우드를 사용할때 빛을 발하는 접근 방식이다.