Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

[Book] 코드로 인프라 관리하기

코드로 인프라 관리하기

코드로 인프라 관리하기 - 6점
키프 모리스 지음
강재준 옮김
한빛미디어


인프라 관련 스터디에서 주제로 선택해서 읽은 책이었다. 작년부터 클라우드 인프라를 만지기 시작하면서 Terraform을 쓰고 있지만 원래 인프라를 쭉 하던 개발자는 아니라서 제대로 공부를 하진 않았기 때문에 책은 나오자마자 샀지만 안 읽고 있다가 이번에 스터디를 계기로 다 읽었다.

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

AWS를 엄청 잘 만지는 건 아니고 인프라를 오래 연구한 것도 아니지만 어느 정도 지식은 가지고 있었다. 팀 내에서 의논해서 인프라를 어떤 방향으로 구축해 갈지를 1년 정도 논의해 오기도 했고 이전과는 다른 개념인 Infrastructure as Code를 적용할 때 현실적인 문제들의 해결이 될 실마리를 이 책이 제공해주길 바랐다. 결과부터 말하면 나로서는 실망이다. 전체를 다 읽고 느낀 점은 책이 너무 추상적이다. 처음부터 너무 쉬운 이론 얘기 들이 나와서 "다음 장 가면 실무 얘기 나오겠지..."하다가 책이 끝났다. 인프라 혹은 Infrastructure as Code에 대한 개념이 전혀 없다면 도움이 될 수도 있겠지만 아무래도 이쪽에 관심 있는 사람들은 사전지식을 꽤 많이 갖고 있지 않나 싶은데 이 책은 너무 이론적이라서 뻔한 말만 하다가 끝난 느낌이다.

이 책이 말하고자 하는 것은 클라우드 시대가 오면서 기존에 진짜 서버를 직접 관리하던 전통방식과는 완전히 달라졌고 여기에 더해 코드로 관리하는 접근이 왜 필요하고 어떻게 해야 하는지를 설명하고 있다. 결론부터 얘기하다 보니 좀 박하게 평했는데 좀 더 자세히 얘기하자면 초기에는 왜 코드로의 접근이 필요하고 어떤 도구들이 있는지 이를 적용하는 과정이나 개념은 어떻게 되는지를 조목조목 설명한다. 결국, 코드로 접근하다 보니 그동안 프로그래밍에서 애자일에서 하던 빠른 실패, 빠른 이터레이션, 완벽한 설계보다는 빠른 변경, 자동화 같은 개념을 그대로 인프라를 대상으로 설명하고 있다. 개발자가 아닌 사람들을 대상으로 설명한다면 (인프라라는 관점에서) 신선한 접근일 수도 있지만, 개발자로서는 굳이 안 해도 되는 설명을 하고 있고 일부 부분에 대해서는 인프라라는 말을 빼면 프로그래밍에 관한 얘기인지 인프라에 관한 얘기인지 모를 정도이다.

1장 문제와 원칙

클라우드 시대의 동적 인프라에서 우리가 겪는 문제, 서버 폭증, 눈송이 서버, 구성 편차, 자동화 공포 등을 설명한다. 이를 해결하기 위해 정의파일을 사용하고 문서화 및 버전 관리를 함으로써 해결하는 접근을 설명한다.

철기 시대와 클라우드 시대의 근본적인 차이는 '매우 신뢰할 수 있는 하드웨어 위에서 동작하던 신뢰할 수 없는 소프트웨어'가 '신뢰할 수 없는 하드웨어 위에서 신뢰성 있게 동작하는 소프트웨어'로 바뀐 것이다.

시스템을 안전하고 빠르게 변경하는 가장 좋은 방법은 구성을 자주 변경해보는 것이다.

2장 동적 인프라 플랫폼

코드로 인프라를 관리하기 위해 플랫폼이 갖추어야 할 특성을 설명하고 있다. 코드로 관리해야 하므로 플랫폼을 프로그래밍으로 다룰 수 있어야 하고 온디맨드여야 한다.

3장 인프라 정의 도구

인프라 정의 도구의 조건으로 스크립트로 사용할 수 있어야 하고 무인 실행이 가능해야 하며 구성이 외부에 노출되어야 한다는 점을 꼽고 이에 해당하는 현대의 도구들을 소개하고 있다.

4장 서버 구성 도구

인프라 정의 도구 외에 서버 구성 도구에 관해서 설명하고 있다. 여기에는 Ansible, Chef, Puppet 등이 포함된다. 모두 자동화를 위한 도구로 현재의 도구들의 특성을 정리해 놓았다.

5장 일반적인 인프라 서비스

인프라 서비스에서 필요한 내용을 정리하고 있다. 인프라에 공통으로 필요한 감시, 경보, 로깅 등의 관점을 설명하고 요즘 가상화된 특징 아래 서비스 탐색과 분산 프로세스 관리에 관해서도 얘기해서 구축해야 할 인프라의 전반적인 이해를 돕고 있다.

6장 서버를 프로비저닝하는 패턴

본격적으로 서버를 프로비저닝하는 여러 접근방법을 소개한다. 실제 도구는 아니고 패턴을 나누어서 서버의 스냅숏으로 서버를 띄운다거나 새 서버를 처음부터 프로비저닝하는 방법을 소개하고 있다.

7장 서버 템플릿을 관리하는 패턴

서버의 템플릿(AWS라면 AMI가 대표적)을 사용하는 다양한 패턴을 소개한다. 여기서는 템플릿으로 서버를 띄울 때 프로비저닝하거나 템플릿 자체를 프로비저닝 된 상태로 만들어두거나 두 가지를 섞어서 하는 접근 방법을 비교하고 이를 업데이트하는 등의 관리에서 발생할 수 있는 이슈도 소개한다.

중요한 모든 것을 템플릿에 프로비저닝한 후, 그 템플릿으로 서버를 생성하고 난 다음에는 런타임 데이터를 제외한 어떠한 변경도 허용하지 않는 것이 불변 서버의 핵심 개념이다.

8장 서버를 업데이트하고 변경하는 패턴

서버를 구축하고 나면 설정을 바꾸거나 새로운 버전을 적용하는 등 계속 업데이트해야 하는데 이 업데이트 일관성 있게 하기 위해 밀어 넣기/끌어오기 방식 혹은 마스터 없는 구성 등의 방법을 비교하고 업데이트할 때 조심해야 하는 부분 등을 설명한다.

9장 인프라를 정의하는 패턴

전체 인프라를 관리하는 방법을 소개하는 장이다. 직접 서버를 만들거나 환경별로 따로 정의해서 사용할 때의 문제점을 지적하고 인프라를 구조화해서 관리하기 쉽게 하려면 어떻게 해야 하는지 설명한다. 여기서는 애플리케이션 코드와 인프라 코드를 함께 관리하고 인프라 설계의 범위를 변경 범위를 기준으로 맞추라고 권장하고 있다.

기존 정적 인프라를 보유한 조직은 결국 정적 인프라의 아키텍처적 패턴과 구현에 익숙해지게 마련이다. 동적 인프라 플랫폼으로 넘어갈 때도 여전히 과거의 패턴과 구현을 유지하는 것이 의미 있고 필요하다고 생각하기 쉽다.

10장 인프라를 위한 소프트웨어 엔지니어링 관례

인프라 코드를 잘 관리하는 얘기인데 코드 얘기랑 같다. 품질 유지에 신경 써야 하고 VCS 사용하고 CI/CD를 적용하라고 하고 있다.

시스템을 코드로서의 인프라로 정의하고 도구를 사용해 구축한다고 해서 품질이 더 좋아지는 것은 아니다. 최악의 경우 상황이 더 복잡해질 수도 있다.

특정 변경이나 릴리스를 상용 환경에 실제로 투입할 시점을 결정하는 일은 여전히 필요하다. 이 결정은 사람이 하지만 실행은 도구가 한다.

11장 인프라 변경 시험하기

인프라를 정의했으면 코드와 마찬가지로 테스트하는 방법이다. 실제 테스트하는 예시나 구체적인 부분보다는 테스트 접근의 이론적인 부분이라 크게 도움 되진 않았다.

12장 인프라의 변경 관리 파이프라인

여기서 파이프라인은 인프라 적용을 자동화해서 코드가 올라가면 적용되는 자동화 흐름을 얘기한다. 이 장에서 한 설명은 나는 좀 과하게 느껴졌는데 파이프라인에는 어떤 단계가 있어 설계할 때의 주의점을 소개하고 실제 파이프라인의 여러 가지 패턴, 많은 팀에서 쓸 수 있는 패턴 등을 소개한다.

13장 인프라팀의 작업 흐름

인프라팀의 일하는 방식을 설명하는 장으로 모든 것을 자동화하고 로컬에서는 Vagrant 등으로 샌드박스 환경을 만들어서 사용하도록 권장하고 있고 이렇게 했을 때 얻는 장점 등을 설한다.

좋은 자동화 작업 흐름의 주요 특성은 속도와 신뢰성이다. 긴급 상황에 충분히 대처할 수 있을 정도로 변경을 빠르게 시스템에 적용할 수 있어야 한다.

코드로 인프라를 관리하는 일은 IT 운영자 대부분의 작업 방식과는 근본적으로 다르다. 가장 큰 변화는 서버와 인프라에서 직접 작업하던 것에서 벗어나 간접적인 방식으로 작업하게 된 것이다. 처음에는 좌절감을 줄 수 있다. 간단한 것을 더 느리고 더 복잡한 방식으로 하는 것처럼 느껴질 수 있기 때문이다.

인프라 코드를 효과적으로 작성하는 사람의 가장 중요한 습관은 가능한 모든 작업을 자동화하는 것이다.

14장 동적 인프라의 지속성

인프라에서 서비스를 중단없이 제공하기 위해 관심을 가지어야 할 지표와 무중단 배포를 하기 위해서 블루/그린 배포, 블루/그린인데 동적 인프라에서 필요할 때만 띄우는 피닉스 배포, 대량의 서버 중 일부에만 먼저 배포하는 카나리아 배포 방법을 소개한다.

사소한 문제와 '알려진 문제'를 감내할 수 있는 '충분히 좋은' 문화가 필요하다.

15장 코드로서의 인프라 준비하기

마지막으로 조직에서 Infrastructure as Code를 하려는 자세로 정리한다. 완벽한 설계가 아니라 계속 변경되는 진화적 아키텍처를 만들어야 하고 효과성을 측정하는 방법 등도 소개한다. 마지막으로 큰 조직에서 권한을 어떻게 나누는 게 좋고 안 좋은 점이 있는지를 설명한다.

2017/09/22 17:50 2017/09/22 17:50

Terraform 0.10.x에서 분리된 Provider의 사용

지난 8월 Terraform이 0.10 버전으로 올라왔다. 0.10에서는 몇 가지 큰 변경사항이 생겼는데 가장 대표적인 부분이 Provider의 분리이다.

별도로 관리되는 Provider

이전 버전까지는 Terraform안에 모든 Provider가 모두 담겨 있었다. 여기서 Provider는 AWS, Google Cloud Platform, GitHub, InfluxDB 등 Terraform으로 관리하고자 하는 서비스를 의미한다. 이 중에는 AWS나 GCP처럼 대형 클라우드도 있고 아주 간단한 서비스도 있지만, 현재는 60개 이상의 Provider가 존재한다.

HashiCorp에서 밝힌 내용에 따르면 Provider가 70개가 넘어가면서 각 서비스에 새로운 기능이 나와도 사용자들은 Terraform의 새로운 버전을 항상 기다려야 하고 또 이 복잡도로 인해서 Terraform에 버그가 생길 가능성도 커지고 있다. 예를 들어 Amazon이 re:invent에서 새로운 AWS 서비스를 발표하면 사용자들은 이 기능을 Terraform에 추가해 달라고 요청하고 이 기능을 사용하려면 Terraform의 새 버전이 나와야 한다는 것이다.

그래서 0.10부터는 Provider를 모두 별도의 플러그인으로 분리하고 Terraform은 그 자체의 핵심 기능만 제공하기로 했다. 그래서 Terraform을 본연의 기능에 충실하고 각 Provider에 새로운 기능이나 버그에 대해서는 각 플러그인이 해결하고 릴리스함으로써 더 유연하게 대처할 수 있게 된 것이다. 이 Provider를 제공하는 GitHub 조직을 terraform-providers라고 새로 만들고 여기서 각 Provider의 개발과 릴리스를 진행하고 있다. Provider 버전과 관련한 최근 글을 보면 SemVer 따르기로 했고 현재는 초기 개발 단계인 0.x.x 버전에 있지만 각 Provider 팀에서 어느 정도 준비가 되면 1.0.0을 릴리스 할 것이라고 한다.

Terraform 0.10의 사용

현재 Terraform 최신 버전은 0.10.5이다. 아무것도 없는 상황에서 다음과 같이 S3 버킷을 AWS에 만드는 Terraform 구성 파일을 만든다고 해보자.

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_s3_bucket" "kr_ne_outsider_test" {
  bucket = "kr.ne.outsider.test"
  acl    = "private"
}

0.9.x 까지는 여기서 terraform plan을 하면 결과가 나오지만, 이제는 오류가 발생한다.

$ terraform plan
Plugin reinitialization required. Please run "terraform init".
Reason: Could not satisfy plugin requirements.

Plugins are external binaries that Terraform uses to access and manipulate
resources. The configuration provided requires plugins which can't be located,
don't satisfy the version constraints, or are otherwise incompatible.

1 error(s) occurred:

* provider.aws: no suitable version installed
  version requirements: "(any version)"
  versions installed: none

Terraform automatically discovers provider requirements from your
configuration, including providers used in child modules. To see the
requirements and constraints from each module, run "terraform providers".

error satisfying plugin requirements

플러그인 요구사항을 만족하게 하지 못했으므로 terraform init을 실행하라는 문구이다. 앞에서 설명한 대로 Terraform Provider가 분리되었으므로 terraform init으로 이를 받아와야 한다. 이는 Terraform이 자동으로 추적하는데 provider "aws"이 아니더라도 설정에서 AWS 리소스를 사용하고 있으므로 aws Provider가 필요하다. 해당 설정에서 필요한 Provider 정보를 보고 싶으면 terraform providers를 실행하면 된다. 뒤에서 설명하겠지만 provider의 버전을 명시하면 여기에 지정한 버전 조건이 같이 나온다.

$ terraform providers
.
└── provider.aws

이제 terraform init으로 플러그인을 설치해보자.

$ terraform init

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "aws" (0.1.4)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 0.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

AWS Provider 0.1.4가 설치된 것을 볼 수 있다. 따로 Provider의 버전을 지정하지는 않았으므로 최신 버전을 가져와서 설치한다.

설치하면 .terraform 폴더 아래 구조로 설치가 된다.(이 폴더는 git에서 관리할 필요가 없다.)

.terraform/
└── plugins
  └── darwin_amd64
    ├── lock.json
    └── terraform-provider-aws_v0.1.4_x4


Provider 버전 지정

경험상 Provider의 버전마다 지원 내용이 다르고 Terraform이 인프라를 다루고 있으므로 약간 조심스럽게 다루는 편이 좋다고 생각한다. 같이 Terraform을 사용하는 사람 간에 Provider의 버전을 맞추려면 다음과 같이 버전을 지정할 수 있다.

provider "aws" {
  version = "~> 0.1.4"
  region = "ap-northeast-1"
}

이렇게 하면 0.1.4 버전 이상의 버전을 사용하게 되고 버전을 특정 버전으로 고정하려면 version = "= 0.1.4"처럼 사용하면 된다.

Provider 업데이트

이렇게 사용해보자 Provider를 사용하다가 새로운 버전이 나왔을 때 어떻게 되는가가 궁금해졌다. 현재 AWS Provider의 최신 버전은 0.1.4이지만 강제로 0.1.2를 설치했다.

.terraform/
└── plugins
  └── darwin_amd64
    ├── lock.json
    └── terraform-provider-aws_v0.1.2_x4

설치된 버전을 확인하는 명령어는 몰라서 폴더를 보면 설치된 버전을 알 수 있다. 이 상태에서 terraform init을 해도 새 버전을 설치하거나 하진 않는다.

$ terraform init

Initializing provider plugins...

Terraform has been successfully initialized!

문서를 보면 이미 Provider가 설치된 경우 설치된 것을 그대로 사용하고 이를 업그레이드하려면 terraform init -upgrade를 사용하라고 되어 있다.

$ terraform init -upgrade

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "aws" (0.1.4)...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

로그를 보면 새 버전을 다운로드 받는 것을 볼 수 있다. 폴더를 열어보면 새 버전으로 업그레이드가 되어 있다.

.terraform/
└── plugins
  └── darwin_amd64
    ├── lock.json
    └── terraform-provider-aws_v0.1.4_x4


기존에 0.9.x 이하에서 관리하던 Terraform

기존 0.9.x 이하 버전의 Terraform으로 관리하던 부분이 있어도 마이그레이션의 크게 어려움은 없다. 개인적으로 관리하는 Terraform에서도 같게 init을 하고 프로바이더를 설치한 뒤에 plan을 하자 바로 사용할 수 있었다.

$ terraform providers
.
├── provider.aws
└── provider.terraform

provider.terraform.tfstate를 원격으로 관리하기 위함이다.

2017/09/19 18:15 2017/09/19 18:15