서버/인프라 엔지니어를 위한 DevOps 를 읽고 정리한 내용입니다.

Infrastructure as Code란?

: 자동화된 인프라를 실현하기 위한 방법 중 하나로, 지금까지 수작업으로 해오던 인프라 구축이나 변경 작업을 코드로 작성해서 자동화하는 것

기존 방식의 인프라 구축의 문제점

기존에 인프라를 구축할 때는 사전에 가이드라인이나 체크리스트를 준비해두고 이 가이드라인에 따라 사람이 하나씩 작업하는 것이 일반적이었다.
ex) 서버 구축 - 터미널 프로그램을 사용해 SSH로 서버에 접속해서 패키지를 설치하거나 설정

이러한 방식에는 아래와 같은 문제점이 있다.

1. 작업 대상이 늘어나면 그만큼 작업에 많은 시간이 걸린다.
2. 수작업으로 장시간 작업을 하면 실수할 가능성이 크다.
3. 실수를 피하려고 가이드라인이나 체크리스트를 작성해도 올바른지를 알 수 없다.
   (ex. 새로운 버전에 대응하지 못하거나, 사소한 작업 순서 변경에 따라 완성된 인프라의 상태가 달라지는 경우도 있다.)
4. 실수가 일어나도 잘못된 것을 알아차릴 장치가 없다.
5. 프로젝트나 서비스별로 다른 체제나 내용으로 가이드라인을 작성하게 되면 재사용이 어렵고 낭비가 발생한다.

코드에 의한 인프라 구축의 우위성

코드에 의해 인프라를 구축하면 앞서 설명한 문제 중 상당수가 해결될 수 있다.

1. 작업 대상이 늘어나더라도 작성한 코드를 적용하기만 하면 되므로 구축하는 데 시간이 오래 걸리지 않는다.
2. '코드 = 가이드라인'이 되므로 같은 코드를 동작시키면 같은 인프라가 왼성된다.
3. 코드를 지속적 통합 도구를 사용해서 테스트하고 계속 유지보수 함으로써 언제라도 해당 코드를 통해 인프라를 구축할 수 있다.
4. Serverspec과 같은 도구를 사용하여 완성된 인프라가 올바른지 자동으로 테스트할 수 있다.
5. 재사용이 쉽다.

코드에 의한 인프라 구축 방법

쉘 스크립트

#!/bin/sh
yum install -y httpd httpd-devel php php-mbstring php-pdo php-mysql mysql-server
/sbin/chkconfig --level 2345 httpd on
/sbin/chkconfig --level 2345 mysqld on
/etc/rc.d/init.d/mysqld start
/etc/rc.d/init.d/httpd start

CentOS에서 yum 명령을 사용해서 서비스를 활성화해서 시작하는 예시이다.

• 수작업으로 명령어를 입력하는 것과 큰 차이가 없으므로 이해하기 쉬움
• 비슷한 작업을 반복해서 작성해야만 하는 불편함이 있음
• 기존 서버를 고려해서 처리하기 위해서는 서버의 설정 상황에 맞게 제어 구문을 다수 삽입해야 하는 불편함이 있음

배포 도구

Capistrano나 Fabric과 같이 배포를 자동화해주는 도구를 사용하는 방법도 있다.
그러나 배포 도구는 어디까지나 소프트웨어를 배포할 목적으로 만들어진 것이다.

인프라 구축의 자동화를 위해 이용할 경우 배포 스크립트에 많이 삽입하는 형태가 되어 규모가 커짐에 따라 가독성이 떨어지기 쉬워 유지보수가 어려워진다.
(쉘 스크립트를 이용한 방식에서 발생하는 문제가 그대로 발생)

desc "Capistrano로 필요한 패키지를 설치하는 예"
task : install_amp, roles => :web do
	run <<-CMD
    	sudo yum install -y httpd httpd-devel php php-mbstring php-pdo php-mysql mysql-server &&
		sudo /sbin/chkconfig --level 2345 httpd on
        sudo /sbin/chkconfig --level 2345 mysqld on
        sudo /etc/rc.d/init.d/mysqld start
        sudo /etc/rc.d/init.d/httpd start
	CMD
 end

Infrastructure as Code 도구

• 패키지 설치나 서비스 실행 설정에서 OS의 명령을 직접 실행하지 않는다.
• 도구에서 정해진 문법에 따라 작성함으로써 가독성이나 재사용성이 향상된다.

아래는 Chef를 사용한 작업 자동화 코드를 일부 발췌한 것이다.

%w{httpd httpd-devel php php-mbstring php-pdo php-mysql mysql-server}.each do |p|
	package p do
    	action :install
    end
end

service "httpd" do
	action [:enable, :restart]
    supports :status => true, :start => true, :stop => true, :restart => true
end

service "mysqld" do
	action [:enable, :restart]
    supports :status => true, :start => true, :stop => true, :restart => true
end

코드에 의한 인프라 관리의 범위

기존에는 코드에 의한 인프라 관리를 서버 내 OS 설정이나 패키지 설치에 머물렀던 것이 일반적이지만 요즘은 AWS와 같은 클라우드 컴퓨팅이 일반화되며 상황이 달라졌다.

클라우드 컴퓨팅 서비스 자체가 API를 이용자에게 공개하고 있어 코드에서 API를 호출함으로써 서버 이외의 다양한 리소스를 다룰 수 있게 되었다.

• 네트워크 구축
• 복수의 클라우드 서비스 및 데이터센터 구축과 설정
  • Terraform과 같은 도구를 사용하여 서비스별로 서로 다른 부분을 추상화해서 통일된 인터페이스로 자동화할 수 있다.
• 서버 자체의 구축 및 설정
• 가상 서버의 템플릿 구축
  • 클라우드 컴퓨팅 서비스나 가상화 도구에서 사전에 설정을 마친 머신 이미지를 템플릿으로 저장해두고 이를 이용해서 같은 서버를 여러 대 설치할 수 있다. (ex. AWS의 AMI)
  • 이미지를 미리 만들어두면 서버가 필요할 때 신속하게 대응 가능

심플한 OS 이미지

• 자신들의 환경에 맞게 OS를 최소한으로 설정
• 반드시 대응이 필요한 항목을 빠뜨리지 않고 설정해둘 수 있음
• 새로운 서버를 만들 때는 미들웨어나 라이브러리를 설치해야 하므로 갑작스레 운영 서비스에 서버를 추가해야 할 경우에는 추가 시간이 소요됨

범용적인 OS 이미지

• 소프트웨어 코드 이외의 것은 처음부터 설치해서 설정을 마친 상태
• 해당 이미지로 서버를 실행하고 소프트웨어 코드만 배포하면 바로 동작됨

전부 포함된 OS 이미지

• 소프트웨어 코드를 포함해서 전부 포함
• 부하에 다라 자동으로 서버 대수가 증감하는 구조를 만들기 쉬워짐
• 소프트웨어가 변경될 때마다 이미지를 다시 만들어야 함
  • 일정한 빈도로 갱신을 자동화해두어야 함 (ex. Packer)

Infrastructure as Code 실현 포인트

• 사전에 요건을 정리할 것
• 갑자기 모든 것을 자동화하려고 하지 말 것
• 현재의 팀 스킬도 고려해서 도구를 선택할 것
• 자동화 코드는 항상 지속해서 테스트할 것
  • 자동화 코드의 실행에 실패한 경우에는 그 다음 작업을 수작업으로 속행하지 말 것
• 해당 사항을 팀 구성원에게 철저하게 주지시킬 것

멱등성에서 Immutable Infrastructure로

멱등성: 몇 번이고 같은 작업을 실행하더라도 같은 결과로 수렴되는 것

위에서 들었던 Chef를 사용한 처리 자동화에도 문제가 있다.

%w{httpd httpd-devel php php-mbstring php-pdo php-mysql mysql-server}.each do |p|
	package p do
    	action :install
    end
end

코드를 동작시키는 타이밍에 따라 설치되는 패키지의 버전이 다를 가능성이 있다.
즉, 지금 만든 서버와 1개월 후 만든 서버가 같은 상태로 수렴하지 않을 수 있다는 것이다.

해당 문제를 방지하려면 :install을 :upgrade로 지정할 수 있다.

그러나, 이것만으로는 충분하지 않다.
만약 Chef Server가 아닌 Chef Solo나 Chef Client의 로컬 모드를 사용하고 있는 경우에는 새로운 서버를 만들 때 기존 서버에도 모두 이 코드를 적용하지 않는다면, 마찬가지로 버전 차이가 발생할 수 있다.

이처럼 자동화 코드를 준비할 때는 다양한 점을 고려해가며 만들어야 하며, 실제로 운용을 할 경우에는 이것이 부하를 유발할 가능성도 있다.

이러한 문제를 해결하기 위해 고안된 것이 Immutable Infrastructure 이다.
불변하는 인프라라는 의미이며, 서버를 예로 들면 일단 서버를 구축했으면 그 후에는 서버의 소프트웨어에 변경을 가하지 않는 것이다.
그 대신 새로운 서버를 만들어 기존 서버를 모두 대체하는 접근 방식이다.

Immutable Infrastructure를 채택했을 때 인프라 관점에서의 장점은 아래와 같다.

• 모든 서버가 같은 상태라는 게 보장된다.
• 다시 만드는 것을 전제로 하므로 자동화 코드가 간소해진다.
• 유지보수가 쉬워진다.
• 새로운 서버를 배포할 때는 로드 밸런서나 리버스 프록시 설정 변경을 통해서 하므로, 하나에 문제가 생기더라도 복원하기 쉽다.

주의해야 할 점은 아래와 같다.

• 빈번하게 서버를 다시 만들게 되므로 구축이 자동화되어야 한다.
• 구축한 서버가 올바르게 동작하는지 검증도 해야 하므로 구축과 함께 테스트도 자동화해야 한다.
• 서버를 다시 만든다는 것은 영구적인 데이터는 그 안에 보관할 수 없다는 것을 의미한다.
  • 데이터베이스 서버나 파일 스토리지에는 이 기술을 적용할 수 없다.
  • 서버를 다시 만들 때 로그 데이터는 다른 곳에 보관해야 한다.
• 위 내용과 관련해서 필연적으로 상태를 갖지 않도록(stateless한 상태로) 설계하고 구축해야 한다.

Immutable Infrastructure를 실현하는 대표적인 기술로는 컨테이너 기술이 있고, 컨테이너 기술에는 대표적으로 Docker가 있다.