코드로서의 인프라란?

Infrastructure as Code (IAC)

소프트웨어 개발 관례에 기반을 둔 인프라 자동화 방법

왜 코드로서의 인프라인가?

기존의 인프라 변경 관리 방식은 클라우드와 자동화가 제공하는 변경의 속도를 따라잡기 어렵다.
그러나 클라우드와 자동화 도구 때문에 계속 늘어나고 끊임없이 변화하는 시스템 환경에 대처해야만 한다.

IT 철기시대

• 시스템이 물리 하드웨어에 직접 연결
• 인프라는 수동으로 프로비저닝
• 변경에 매우 많은 작업이 필요 -> 변경 관리 절차가 복잡해짐

클라우드 시대

• 물리 하드웨어와 분리
• 프로비저닝, 관리 작업을 소프트웨어에 전담
• 인프라 변경은 몇 내지는 몇초 -> 높은 신뢰성 보장, 빠른 서비스 출시

코드로서의 인프라의 목표

• IT 인프라가 변경의 장애물이나 제약이 되는 것이 아니다.
• 변경을 지원하고 가능하도록 한다.
• IT 담당자의 지원 없이도 원하는 자원을 정의하고, 프로비저닝하고, 관리할 수 있다.
• 고장을 쉽고 빠르게 복구할 수 있다.
• 개선은 대규모 프로젝트가 아니고, 지속해서 꾸준히 이루어진다.
• 문제의 해결책은 회의나 문서에서 논의하는 것이 아니라, 구현, 시험, 측정을 통해 검증한다.

동적 인프라의 문제점

1. 서버 폭증

클라우드와 가상화를 사용하면 새 서버를 손쉽게 프로비저닝 할 수 있다.
이로 인해 관리능력 이상으로 서버의 수가 늘어날 수 있다.

2. 구성 편차

처음엔 일관되게 구성하더라도 시간이 갈수록 점점 차이가 발생한다.
구성이 다른것이 나쁜 것은 아니다.
구성이 다른 서버를 파악해 서버나 서비스를 쉽게 재 생성할 수 있게 관리해야 한다.
관리되지 않은 구성이 다른 서버는 결국 Snowflake 서버와 자동화 공포를 일으킨다.

3. 눈송이 서버 (Snowflake server)

네트워크상의 다른 서버들과는 다르게 구성된 서버를 지칭한다.
다르게 구성된 것이 나쁜게 아니다.

문제는 해당 서버가 다른 서버와 어떻게, 왜 다른지를 알지 못해
서버를 다시 만들 수 없는 경우가 문제가 된다.

4. 취약한 인프라

쉽게 고장나지만 쉽게 고칠 수는 없다.
이는 Snowflake server 문제가 시스템 전체 포트폴리오로 확장된 경우이다.

5. 자동화 공포

자동화 공포의 악순환을 끊어야 한다.

1. 새 서버를 만들거나 특정 구성을 변경할 때에만 선택적으로 자동화 사용
2. 자동화 도구를 사용할 때마다 특정 작업에 맞춰 구성 정보 수정
3. 자동화 도구가 하는 일에 확신이 없어서 의지 하지 못함
4. 자동화 도구를 지속해서 사용하지 않게됨
5. 관리하는 서버들의 구성이 일관되지 못하게 됨

6. 침식

새로운 요구가 없으면 인프라는 시간이 갈수록 노후화 된다.
침식은 시간이 갈수록 동작 중인 시스템에 서서히 문제가 발생하는 현상이다.

침식의 예

• OS 업그레이드, 커널 패치, 인프라 소프트웨어 업데이트
• 로그 파일로 가득 찬 서버의 디스크
• 애플리케이션 프로세스의 충돌이나 먹통
• 하드웨어의 고장
  

코드로서의 인프라 원칙

1. 시스템은 쉽게 다시 만들 수 있다.
2. 시스템은 일회용이다.
3. 시스템은 일관성이 있다.
4. 절차는 반복 가능하다.
5. 설계는 항상 변한다.