티스토리 뷰
대규모 인프라 운영에 사람의 수작업을 최소화하려면 결국 자동화만이 해답이다. 자동화는 곧 스크립트나 소프트웨어의 영역이라는 점에서 클라우드 인프라 운영자라면 어쩔 수 없이 개발 세계를 기웃거릴 수 밖에 없게 된다. 계발 세계의 초기 진입 장벽을 고려하려면 개발자가 인프라 운영을 배우는 게 더 나아보이기도 한다.
어쨌든 인프라 운영자는 자동화를 위한 최소한의 개발 능력과 한두 가지의 언어를 익히는 일이 필수가 되었으며, 반대로 개발자도 네트워크와 스토리지는 물론이고 가상화와 구성관리까지 아우르는 전반적인 개념을 이해해야 하는 고단한 시대가 오고 말았다.
위의 인용에서 확인할 수 있듯 개발자와 운영자 사이의 장벽을 없애려는 개발 문화를 추구하는 움직임이 많은 곳에서 이루어지고 있고, DevOps 엔지니어라는 포지션이 탄생했으며 작년에 이직하게 된 회사에서 나는 본격적인 DevOps 엔지니어의 역할을 하고 있다. 제품의 새 피쳐 개발부터 배포를 위한 자동화 스크립트 구현, 그리고 배포 및 QA까지 우리의 프로덕트의 시작과 끝을 내 손으로 직접 하고 있다.
백엔드 엔지니어이고자 했던 나에게는 새로운 환경과 도전이었고, 인프라의 운영에 대해서 아는 바가 많이 없었기 때문에 처음엔 혼란스럽기도 했다. 내가 합류한 팀은 프로덕트의 인프라를 모두 코드와 템플릿으로 관리하고 이를 통해 재현 가능(Reproducibility), 반복 가능 (Repeatability), 신뢰 가능(Reliability)한 배포 파이프라인을 구축한 케이스를 직접 만들어나가고 있었다.
내가 이 글을 통해 소개할 책은 "인프라를 모두 코드와 템플릿으로 관리"하는 이른바 "Infrastructure as Code (IaC)" 의 원칙과 패턴을 설명하고있다.
IaC는 우리에게 지루하고 반복적인 작업, Human error 가 발생할 수 있는 작업을 코드와 템플릿에 맡기고 사람의 능력이 필요하는 개발에 더 집중하게 해준다. 실제로 우리 팀의 모든 개발자들은 IT 인프라 담당자없이 원하는 컴퓨팅 리소스를 정의하고 프로비저닝하고 관리할 수 있다.
인프라를 정의하고 있는 템플릿 파일은 단순히 코드를 위한 정보파일 뿐만 아니라, json이나 yaml 파일과 같이 사람이 읽기 쉬운 수준으로 작성되어 있으므로, 그 자체가 하나의 사람을 위한 문서 / 커뮤니케이션 도구가 된다. 인프라를 파악하기 위해 누군가가 작성해놓은 다이어그램을 보는 것보다 어쩌면 템플릿 파일을 보는 것이 최신일 것이다.
개발 과정 뿐만 아니라 결과물에도 큰 장점을 가져다 준다. 인프라가 견고함을 넘어 반취약성(Antifragibility)을 갖게 해주는게 바로 IaC를 해야하는 이유다.
인체에 가해진 물리적 충격으로 인한 영향이 반취약성에 관한 하나의 실례다. 운동은 근육과 뼈 충격과 손상을 주지만, 한편으로는 근육과 뼈를 더 강하게 만들어준다. 몸을 보호한다는 핑계로 물리적 충격과 운동을 피하면 실제로는 몸이 약해져, 큰 충격에 손상을 입을 가능성이 커진다.
인프라에 문제가 발생했을 때, 단순히 그 문제를 해결하는 것이 아니라 비슷한 문제에 대처할 수 있도록 시스템의 기능을 개선하는 것. IaC를 달성했을때 이는 매우 쉬워진다.
Infrastructure as Code를 달성하기 위해서는 아래의 여러가지 요건을 만족시켜야 한다.
1. 스크립트로 작업 가능한 인터페이스
aws에서는 2가지 방식의 서비스 접근 권한을 제공한다. Console Access 와 Programmatic Access 인데, Console Access는 웹 GUI를 통해 인프라를 관리할 수 있도록 한다. GUI는 사용자의 편의를 위해 많은 부분을 추상화하여 관리 작업은 편하게 해준다는 장점이 있는 반면, Programmatic Access 는 인프라 내부로 들어갈 수 있는 수단이라고 할 수 있겠다.
자동차 산업에 비유하면, 보닛이 용접되어 붙어있는 자동차가 아직 이 세계에 존재하지 않듯, 내부를 들여다볼 필요 없는 완벽한 인프라도 존재하지 않는다.
2. 무인 방식의 명령줄 도구
이 책에서 이야기하는 "무인 방식"이란, 대화식 수동 입력을 요구하지 않는 UNIX 명령 줄 도구와 같은 CLI 설계를 이야기한다.
3. 무인 실행의 지원
- 멱등성을 갖추고 있어야 한다. 즉, 동일한 스크립트나 작업을 악영향 없이 여러 번 실행할 수 있어야 한다.
- 사전 점검을 포함해야 한다. 올바른 시작조건을 검증해야 하기 떄문이다.
- 사후 점검을 포함해야 한다. /echo/와 같은 요청을 보내 가상 호스트를 점검하는 것이 하나의 예다.
- 실패를 쉽게 확인할 수 있어야 한다.
- 매개변수화. 스크립트는 비슷한 유형의 여러 작업에 적용될 수 있어야 한다.
인프라 정의 도구
소개하는 책에서는 aws 뿐만 아니라 일반적인 이야기를 다루고 있다. 실제로 디팩토 스탠다드가 aws이므로.. aws서비스를 이용할 수 있는 다양한 방법들을 정리해보면 아래와 같다.
1. Web Console - 수작업
웹 콘솔에서 aws서비스를 이용할 수 있다. GUI 와 마우스 클릭으로 인프라를 생성할 수 있다. 매우 쉽지만 우리가 이야기하는 자동화, IaC와 가장 거리가 먼 방법이다.
2. AWS SDK / AWS CLI 이용. - Script 기반
aws서비스를 원하는 언어로 스크립팅할 수 있도록 언어 별로 SDK가 존재한다. 프로덕트의 백엔드 서버가 다른 aws서비스를 이용할 때 SDK를 사용할 수도 있겠지만, 지금 이야기하고자 하는 건 아니다. AWS SDK를 이용해서 EC2같은 기본적인 서비스부터 SQS, SNS, Lambda같은 서버리스 서비스까지 모두 프로비저닝할 수 있다. 스크립트로 원하는 작업을 절차적으로 배치할 수 있기 때문에 리소스의 반복작업에 적합하다.
3. 프로비저닝 엔진 사용 - Declarative 방식
aws CloudFormation 이라던지, Hashicorp Terraform 같은 프로비저닝 엔진을 사용하여 인프라를 관리할 수 있다. 인프라를 json, yaml 파일 (혹은 HCL)로 정의한 템플릿 파일을 기반으로 자동화된 프로비저닝을 할 수 있고, 이런 도구들도 역시 반복작업에 적합하다. 서버리스 어플리케이션이라면 Cloudformation을 래핑한 serverless framework 도 좋은 도구라고 생각한다.
주로 주변 이야기를 들어본다면 2번, 3번 방식이 주를 이루고 그 중에서도 Terraform 을 이용하는 경우가 꽤 있는듯 하다. 하지만 Terraform 같은 경우는 아직 0.x 버전이라서 하위호환성에 대한 아쉬움이 많이 이야기되고 있다. (참고자료 :https://www.hashicorp.com/resources/the-path-to-terraform-1-0)
usecase 1. HBsmith - Johanna
https://github.com/HardBoiledSmith/johanna
python 으로 작성된 aws cli 래핑 기반의 프로비저닝 도구다. IAM, VPC, EC2, S3와 같은 기초적인 서비스부터 Lambda, SQS, SES, Cloudfront, Elastic Beanstalk 와 같은 aws의 서비스를 프로비저닝할 수 있는 스크립트가 작성되어있다. .run.py 한 번이면 JSON 으로 정의된 인프라가 순차적으로 프로비저닝되고, 내가 속한 팀도 이 도구를 이용하여 인프라를 운영하고 있다. aws cli를 래핑했고, 사람의 행위를 그대로 자동화한 python 코드뭉치.
Johanna를 약 1년간 쓰다보면서 드는 생각으로는, 어떤 인프라 관리 도구를 쓰는가의 문제는 백엔드 기술 스택을 고르는 것과는 다른 의사결정문제같다. 당장 새로운 피쳐를 만들고 새로운 개발자가 빠르게 공급되어야하는 백엔드 개발과는 다르기 때문이다. 차라리 그 개발팀의 문화와 아키택쳐에 최적화된 방식을 채택하는게 가장 좋은 것이 아닐까라는 생각한다.
usecase 2. beNX - Goployer
https://github.com/DevopsArtFactory/goployer, https://goployer.dev/
AWS Autoscailing, Load Balancer, EC2 인스턴스를 띄워주는 모든 과정을 yaml 파일로 정의하면 프로비저닝해주는 도구다. 요즘 핫한 golang 으로 만들어졌다. goployer가 만들어진 계기가 매우 흥미로웠다. 시간이 허락한다면 컨트리뷰션도 해보고싶다.