1. 데브옵스
기존에는 애플리케이션을 다루는 서버를 운영하는 Ops 그룹과 애플리케이션을 제작하고 런칭하는 Dev그룹이 나눠져 협동을 하였다. 다만 물리적인 서버에 변수가 너무 많고, 서비스를 늘리면 그에 맞는 서버들이 유기적으로 연동되야하고, 여기에 다시 애플리케이션을 올리다보면 설정이 달라지거나 서버가 불안정하면 서비스 자체가 흔들리는 경우가 많았다.
작업자체가 대규모다 보니 릴리즈 시간이 점차 늘어나고, 릴리즈가 늘어날 수록 개발 충돌이 많이 일어난다(버전이나 코드 등의 협의가 섞이기 시작) 이에 따랄 데브옵스 문화는 지속적으로 정착될 것이다.
- 데브옵스의 목적은 소프트웨어를 전달하기 위한 절차와 방법을 훨씬 효율적으로 만드는 문화
- 소스 코드를 자동으로 통합하고, 오류를 자동으로 검출하여 항시 배포가능한 상태를 만든다.
- 커밋만으로도 배포가 가능하도록 구성한다.
서비스 장애와 중지 시간을 고려해 자동으로 복구한다.
복구 못할 경우 모니터링 시스템에서 즉각적으로 감지하고 통보한다.
데브옵스의 움직임 : 문화, 자동화, 측정, 공유
목적 : 최대한 소프트웨어 배포 절차 자동화, 코드 형태로 인프라 관리.
2. 코드형 인프라 (IaC)
- 코드 형태로 인프라를 작성, 정의, 배포, 업데이트하는 것
물리 장비를 설정하는 것 뿐 아니라 모든 운영을 코드 형태로 진행 - 서버, DB, Network, 로그 파일, 애플리케이션 설정, 자동화된 검증 절차, 배포 방법 등 모든 것을 코드형태로 관리
IaC의 구분
- 애드 혹 스크립트
- 구성관리 도구
- 서버 템플릿 도구
- 서버 프로비전 도구
2.2애드혹 스크립트 도구
코드 형태로 자동화를 구현할 수 있는 것은 즉각적인 호출과 응답을 할 수 있는 스크립트를 제작하는 것
수동으로 작업하는 것을 절차로 정의하고, 스크립트 언어로 구현해 대상 장비에서 수행한다.
즉 스크립트를 작성하는 것이다.
직접 장비에 맞는 코드를 수작업으로 추가해야하며, 대규모 인프라에서는 구성하기 매우 까다롭고 어렵다는 단점이 있다.
2.2 구성 관리 도구
Chef, Ansible 등이 구성 관리 도구에 속하며, 서버에 소프트웨어를 설치하거나 관리하는 목적으로 상요한다.
특징 : 코딩 규칙
- 엔서블 자체의 문서화, 파일 배열 구성, 명확히 정의된 변수, 암호화 관리를 포함해 일관성이 있고 추후 다른 사람이 코드를 봐도 한 눈에 파악이 가능하다.
멱등성 - 같은 코드라면 수행 횟수에 상관없이 결과가 같은 것을 의미한다.
- 특히 이전에 스크립트로 1차 설치가 완료된 인프라에서 2차적으로 애드혹 스크립트를 돌릴 경우 기존에 설치된 것과 충돌할 수 있으나, 앤서블은 멱등성으로 인해 기존에 설치된 것은 기본적으로 감지하여 배제시킨다.
분산형 구조
- 애드혹 스크립트는 소규모 인프라 관리에 유리하고, 앤서블과 같이 구성 관리 도구는 대규모 인프라에 알맞도록 설계되었다.
2.3 서버 템플릿 도구
도커, 베이그란트와 같은 것으로, 소프트웨어와 수행 시 필요한 설정과 의존성이 있는 프로그램들을 포함한 특정 시점에 운영 체제와 함께 스냅샷하여 템플릿 이미지화 하는 것이다.
그래서 베이그란트를 통해서 VM을 생성한뒤 ansible로 관리하면 된다.
- 이미지는 가상머신과 컨테이너 두 분류로 나눈다.
가상머신은 하드웨어 레벨의 연관 관계를 포함한 시스템의 정보를 이미지화 한다. 실제 사용하는 물리적인 리소스 자체를 나누는 것이고, 운영체제를 포함하고 있기 때문에 배포하는데 시간이 길고, 오버헤드를 일으킬 수 있으나 컨테이너에 비해 보안적으로는 훌륭하다.
컨테이너는 운영체제의 사용자 영역만 에뮬레이트 한다.(기본적으로 사용자 영역과 커널 영역이 있는데, 커널 영역은 모든 하드웨어 까지 접근권한이 있어, 위험할 수 있다)
서버 템플릿의 경우 변하지 않는 인프라(Immutable Infrastructure)로 이미 fix된 버전으로 이미지를 만들어서 새로 버전 업그레이드 될 경우 별도의 이미지를 작성하지 않는 한 모두 동일한 세팅을 항시 유지할 수 있다는 장점이 있다.
2.4 서버 프로비전 도구
Terraform, CloudFormation 처럼 서버, DB 등 인프라 자체를 구성하기 위한 도구를 만들 수 있다.
3. 코드형 인프라의 장점
코드형 인프라를 적용하면 배포 주기가 수백배, 장애 복구시간이 수십시간 빨라지며, 상용 서비스 적용이 매우 빨라지는 효과를 얻었다.
- 셀프서비스 : 코드 형태로 인프라 관리하고 배포 절차를 자동화하면 개발시간을 자동화할 수 있다.
- 속도와 안정성 : 배포 절차가 자동화된다면, 운영자가 수동으로 배포하지 않고 컴퓨팅 리소스가 신속하게 배포하므로 속도와 안정성이 눈에 띄게 향상된다.
- 버전 관리 : 인프라 변경사항과 커밋 로그를 남겨, 신속하게 로그를 파악하거나 원하는 시점으로의 복구가 가능하다.
- 확인 및 검사 : 변경사항을 코드로 리뷰할 수 있어 확인이나 검사가 신속하며, 자동화된 형태로 코드 검사하듯 유효성 검사가 가능하다. 이는 결함가능성을 최소화 한다.
- 재사용성 : 인프라를 코드화하여 모듈화한다면 모든 배포 단계와 환경에서 처음부터 시작할 필요 없이 공통된 사항들을 재사용할 수 있다. 이 말은 검증된 것을 자유롭게 활용하여 서비스를 꾸릴 수 있다는 것이다.
- 운영 관리의 편안함 : 배포부터 관리까지 자동화로 이뤄지기 때문에 담당자가 코드를 입력하고 확인하면 그만이다. 또한 서비스 배포이전에 이미 유효성 검사가 진행되므로 서비스 안정성에 신뢰를 더하게된다. 또한 단순 반복적인 업무에 시간을 빼앗기지 않을 수 있다.
4. 테라폼의 동작방식
- 테라폼은 Go로 프로그래밍 되어있다.
- Go는 하나의 바이너리로 컴파일 되어있고, terraform 명령어로 수행한다.
- 기본적으로 개인 클라이언트가 있다면, AWS 등 퍼블릭 클라우드 이용시에는 AWS에서 제공하는 API서버의 자원을 활용하여 작동시키게 된다.
5. 다른 도구와의 차이
-
구성 관리 vs 배포 도구
구성 관리도 리소스 프로비저닝을 통해 배포 도구의 역할도 한다. 배포 도구 역시 스크립트를 통해서 구성 관리 정보를 수집할 수 있다. 도커 파일과 같은 탬플릿 이미지를 소유하고 있다면 서버 프로비전 도구가 가장 효과적이며, 서버 템플릿 도구가 없다면 설정 관리 도구와 프로비전 도구를 함께 사용하는 것이 최적이다.
예로 테라폼으로 인프라 리소스를 배포하고, 앤서블로 설정 관리를 수행하는 식이다. -
가변 vs 불변의 인프라
chef, ansible 등의 구성관리 도구는 가변적 인프라를 기본으로 한다. 따라서 구성 관리 도구로 소프트웨어 버전 업그레이드가 필요하면 개별적으로 진행되게 되며, 이 경우 추후 관리가 되지 않을 수 있다. 따라서 해당 내용들은 변하지 않는 인프라를 사용할 때 유리할 수 있다.
terraform과 같은 배포 도구는 업그레이드한 이미지를 새로 생성한 다음, 새 이미지를 배포하고, 기존 이미지를 회수하는 방식으로 진행해서 배포도 빠르고 회수나 복구도 빠르다.
-
절차적 언어 vs 선언형 언어
절차적 언어는 해당 언어가 절차적으로 지속 반영된다. 선언형 언어는 선언한 내용으로 실행한다.
즉, ansible과 같은 절차적 언어는 기존 10대의 서버 구성 코드에서 15대로 증강하려면 5를 추가해 넣어야 하나,
terraform과 같은 선언형 언어는 기존 10대의 서버 구성 코드에서 15대로 증강하려면 10을 15로 변경하면된다. -
마스터 유무
마스터 서버의 역할은 인프라를 한 곳에서 중앙 관리하고, 웹 인터페이스를 제공하는 곳도 많으며, 백그라운드에서 지속해서 실행되 구성 변경 감지가 쉽다.
다만, 클러스터를 구성하는 등 추가적인 리소스를 잡아먹고, 마스터 서버 자체가 중요해 관리, 운영, 업그레이드, 백업, 모니터링 작업이 필요하며, 모든 클라이언트와 소통 포트를 열어둬야하므로 보안적으로 위험할 수 있다. -
에이전트 유무
에이전트는 일반적으로 각 서버 백그라운드로 수행되며, 최신의 설정 관리 업데이트를 담당한다.
부트스트랩핑 : 서버를 프로비전하고 어떻게 소프트웨어를 설치하는가? 일부 구성 관리 도구는 일부 외부 프로세스가 처리할 것으로 가정하여 진행한다.
유지관리 : 에이전트 소프트웨어는 주의 깊게 정기적으로 업데이트하고, 마스터 서버와의 동기화를 신중하게 유지해야한다. 에이전트 소프트웨어가 재시작되거나 문제가 발생하면 모니터링 되어야한다.
