[IaC 찍먹하기] 1. IaC란 무엇인가?

🗓️ : 2022/08/22(월)~27(토)
🚩 : 서울 구로구 벽산디지털밸리 7차 204호 CCCR 교육장
👨‍🏫 : 2022년 Devops를 위한 IaC 클라우드 인프라 자동화 전문가 과정
🏢 : CCCR (한국클라우드컴퓨팅연구조합)

들어가기에 앞서

• 해당 과정은 국비지원 과정이며, 무료로 수강하였습니다.
• 재직자 과정이고, 중소기업 > 중견/대기업 > 공공기관 순서로 선발 우선순위가 존재합니다.
• 국비교육이라 큰 기대는 하지 않았으나, 강사님(노브레이크 장성균 이사님)의 커리큘럼 및 교육장 환경이 좋았습니다.
• 교육에 대한 자세한 내용은 CCCR 아카데미를 참고하시기 바랍니다.
• 교육 내용에 더해 직접 찾아보면서 보완한 내용들 또한 포스팅할 예정입니다.

IaC는 어떻게 세상에 등장하게 되었는가?

기존 인프라 관리의 어려움

IaC 등장 이전의 관리는, 서버가 위치한 물리적 공간에서 KVM을 통한 접속 혹은 텔넷, SSH 등으로 변경사항을 적용할 모든 서버에 접근하는 방식으로 이루어졌을 것입니다. 물론 그 시대의 엔지니어들은 바보가 아니었기 때문에 스크립트를 작성하여 해결해보려 했겠지만, 여전히 많은 문제가 있었을 것이라고 생각이 됩니다.

AWS EC2의 등장

AWS, MS Azure, GCP, OCI, Alibaba Cloud, NAVER Cloud, Kakao i Cloud 등 정말 수많은 CSP들이 Public Cloud 시장에서 경쟁하고 있습니다. 지금 시점에서는 Pay-As-You-Go 방식이 모두에게 익숙하지만 IaaS 컴퓨팅 자원의 경우 2006년에 AWS에서 EC2 서비스가 출시되었습니다. 인터넷에서 대규모 다국적 비즈니스를 영위하는 대기업의 전유물이었던 스케일링과 민첩성에 대한 고민을 개인 개발자도 함께 시작할 수 있는 시점이 아니었나 생각합니다.

EC2의 출시와 더불어 당시 Ruby 언어로 구현된 백엔드 프레임워크 Ruby on Rails를 EC2에 대규모 배포했을 때 생기는 트러블 들이 크게 이슈가 되어 '배포와 관리를 좀 편하고 정교하게 할 수 없을까?' 라는 문제의식에서 IaC가 등장했습니다.

비즈니스 민첩성

비즈니스는 항상 시장의 변화에 대응할 수 있어야 하며, 비즈니스의 대부분이 IT 기반인 지금 시점에서는 개발과 인프라의 민첩성이 곧 비즈니스의 민첩성으로 연결되는 시대가 왔다고 생각합니다.

온프레미스 인프라가 주류이던 시절에 개발자가 신규 서비스 런칭을 위해 인프라 담당자에게 변경에 대한 요청을 했다고 가정해 봅시다.

1. 개발자가 요구사항을 정리해 인프라 담당에게 전달합니다.
2. 추가 장비가 필요한 경우 예산을 배정받아 구매합니다.
3. 장비 딜리버리 기간을 기다립니다.
4. 인프라를 구성하고 개발자에게 전달합니다.
5. 개발자는 새로 변경되고 추가된 인프라에 맞도록 개발합니다.

의사소통 과정에서 오해로 인한 불필요한 시간 소모가 있을 수도 있고, 계획부터 서비스 런칭까지 주기가 너무 길며, 단기간에 들이는 비용과 기다리는 시간이 커 민첩성을 확보하기가 어려웠습니다.

그러나 클라우드가 대중화되면서 개발자가 직접 클라우드 위에 인프라를 구성할 수 있게 되어 위에서 언급했던 5단계 중 1~3단계가 간소화 될 수 있었습니다. 그리고 온프레미스 진영 또한 클라우드에 인프라 시장 점유율을 내주는 걸 보고만 있을 순 없기에 가상화 솔루션 벤더들 또한 변화에 맞춰 API 지원 및 관리를 용이하게 하는 각종 솔루션과 지원을 꾸준히 하고있고, HPE의 경우 온프레미스 인프라를 대여하는 GreenLake 서비스를 출시하는 등 이에 대응하고 있습니다.

(뜬금없는 사족 : 온프레미스와 클라우드는 상호보완관계라고 생각합니다.)

여튼 인프라 운영관리 및 아키텍쳐의 역할이 점점 개발자 쪽으로 넘어가면서 (내 밥줄..) 또 다른 고민이 시작됩니다.

1. 다수가 협업하는 과정에서 인프라 명세를 공유할 수 있는 방법이 없을까?
2. 인프라 변경을 추적하고 기록할 수 없을까?
3. 반복되는 작업을 편하게 할 수 없을까?
4. 휴먼 에러를 제거할 수 있을까?
5. 다수의 CSP와 온프레미스 환경을 같이 구성한 경우, 일관적인 방법으로 인프라를 관리할 수 없을까?

Infrastructure as a Code (이하 IaC)가 이러한 고민을 해결해줄 수 있습니다.

IaC란 무엇인가?

• 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝 하는 것을 말합니다. (Red Hat)
• 모든 것을 코드로 정의하고, 지속적으로 테스트 및 딜리버리하며, 작고 느슨하게 결합된 조각으로 시스템을 구축한다 (Kief Morris, Infrastructure as Code: Dynamic Systems for the Cloud Age)

기존의 스크립팅, 혹은 노가다로 자원을 프로비저닝하고 관리하는 것을 벗어나 코드로 인프라의 구성을 정의하고 프로비저닝/관리를 대신 해주는 도구라고 말할 수 있습니다.

 

1. 다수가 협업하는 과정에서 인프라 명세를 공유할 수 있는 방법이 없을까? 
   => 코드로 인프라를 작성하게 되어 누구나 읽고 이해할 수 있습니다. 
2. 인프라 변경을 추적하고 기록할 수 없을까?
   => git과 같은 형상관리 도구를 이용하여 변경추적 및 관리가 용이합니다.
3. 반복되는 작업을 편하게 할 수 없을까?
   => 한 번 작성을 잘해놓은 프로세스는 반복적으로 사용 가능합니다.
4. 휴먼 에러를 제거할 수 있을까?
   => 100% 없애지는 못하겠으나, 오타 등으로 발생하는 사소하지만 큰 실수를 방지할 수 있습니다.
5. 다수의 CSP와 온프레미스 환경을 같이 구성한 경우, 일관적인 방법으로 인프라를 관리할 수 없을까?
   => IaC 도구에서 지원하는 문법으로 명세한 인프라 구성이나 스크립트를 통해 온프레미스/다양한 CSP 모두를 지원할 수 있습니다. 

 

가변 인프라 VS 불변 인프라

가변 인프라(Mutable)

• VM 및 컨테이너가 가변 인프라에 해당합니다.
• 어떤 패키지를 설치하는지, 설정을 어떻게 변경하는지, 어떤 프로그램을 사용하는지 등에 따라 메모리나 VM/컨테이너의 상태(State)가 변하게 됩니다.

불변 인프라(Immutable)

• 이미지나 템플릿이 불변 인프라에 해당합니다.
• 이미지나 템플릿 등의 변경사항을 적용할 경우, 기존 이미지나 템플릿의 내용을 변경시키는 것이 아니라 새로운 이미지나 템플릿을 생성하게 됩니다. 

 

 

절차적 언어 VS 선언적 언어

Desired State : 한국어 번역은 '원하는 상태'인데, 딱히 와닿지 않는 번역이라 영어 단어 그대로 사용합니다. 말 그대로 특정한 의도와 목적을 달성하기 위해서 인프라가 갖추어야 할 상태를 이릅니다. 평범한 웹 어플리케이션을 예로 들자면, 방화벽, 스위치, WAS를 구동하기 위한 컴퓨팅 자원등이 갖추어 지고 올바르게 구성되어야 할 것인데, 그 때의 인프라 상태를 Desired State라고 이릅니다.

절차적 언어

• 절차적 언어란, 코드의 위에서 아래로 순차적으로 실행되는 특성을 가집니다.
• 사용자가 인프라를 Desired State에 도달하기 위한 작업 일체를 기술합니다.
• 추후 다루게 될 Ansible이 대표적입니다. 어떤 라이브러리를 구동하기 위한 일련의 활동(Ubuntu 기준 apt update, apt install {A Package} {B Package} {C Package}...., 호스트 설정 등등) 전체를 사용자가 기술하여야 합니다.

선언적 언어

• 선언적 언어란, Desired State 그 자체를 기술합니다.
• 특정 인스턴스는 특정 Subnet에 속하여 특정 Security Group에 속하고 등등... 인프라의 상태를 코드로 기술합니다.
• 추후 다루게 될 Terraform이 대표적입니다. 
• 코드로 기술한 Desired State가 변경된다면, 기존 Terraform이 가지고 있던 State와 비교하여 그 차이 만큼을 타겟 인프라에 반영하게 됩니다.
• Desired State에 도달하기까지의 세부 동작은 유저는 알 필요가 없습니다. IaC 도구에서 그 차이를 인식하고 세부 동작을 수행합니다.

Agent

• 관리 및 프로비저닝에 있어, 관리 대상 각 노드들에 Agent를 설치하는 방식으로 인프라 전체의 state를 관리 / 명령을 수행하도록 구현한 도구들이 있고, SSH 및 API, 각 CSP/가상화 벤더들이 제공하는 관리/제어 목적의 CLI를 이용하여 구현한 도구들이 있습니다.
• Ansible과 Terraform은 Agentless한 설계사상을 가지고 있습니다.
• Agent가 각 노드에 구동되는 것은, 컴퓨팅 자원이 IaC 도구에 의해 사용되어 컴퓨팅 자원 활용에 낭비가 됨을 의미합니다.
• 그렇다고 해서 Agentless가 항상 장점을 가지는 것은 아닙니다. SSH 통신을 하는 도구의 경우, SSH를 열어둔다는 것 자체가 보안을 위협하는 포인트가 될 수도 있고, 이를 방지하기 위하여 추가적인 보안 및 네트워크 설정(Bastion Host, Security Group, 방화벽 설정 등)이 필요할 수도 있습니다.

Push / Pull 방식

• Push 방식은 중앙에서 코드로 정의된 관리대상 노드들에게 작업을 전송하여 수행하는 방식입니다.
• Pull은 각 관리대상 노드들이 외부에 있는 정의 및 작업을 가져와서 수행하는 방식입니다.
• 두 방식의 차이는 '작업을 관리대상 노드가 수동적으로 받느냐, 능동적으로 땡겨오느냐'의 차이라고 보시면 이해에 도움이 되실 것입니다.
• Pull/Push 방식 구성에 따라 신경써야 하는 부분이 달라지며, 추후 Terraform 소개에서 다룰 기회가 있을 것입니다. 

시장에서 널리 쓰이는 IaC 도구들의 역할