개발자를 위한 인프라 기초 총정리 - 인프라 구성관리

인프라 구성 관리

인프라 구성 관리란 인프라를 구성하는 하드웨어, 네트워크, OS, 미들웨어, 애플리케이션 등의 구성 정보를 관리하고 적절한 상태로 유지하는 작업을 의미합니다. Docker 를 이해하는데 필요한 몇 가지 개념을 살펴봅니다.

Immutable Infrastructure

온프레미스 환경에서는 인프라 환경을 구축하는 것도 큰 일이고, 일단 구축하면 변경 이력을 정리하면서 상당히 오랜 기간 사용합니다. 하지만 클라우드는 가상 환경이기 때문에 필요하면 구축하고 불필요하면 바로 폐기해도 상관 없습니다. 즉 서비스가 업데이트되면 기존 운영 환경을 변경하는 대신 이미지를 새로 생성해 배포합니다. 이를 변경하지 않는다는 뜻의 Immutable Infrastructure 라고 합니다.

https://www.oreilly.com/ideas/an-introduction-to-immutable-infrastructure

Immutable 인프라는 이미지 하나로 서버를 쉽게 찍어낼 수 있고 해당 이미지만 관리하면 되기 관리도 용이합니다. 또한 환경 자체를 배포하기 때문에 동일한 환경에서 테스트도 쉽습니다.

Infrastructure as Code

새로 서버를 설치한다고 합시다. 온프레미스 환경에서는 물리 서버나 네트워크 장비를 데이터 센터에 설치한 후 여러가지 설정을 해야 합니다. 만약 서버 100대를 수작업으로 설정한다면 어떨까요? 단순 반복 작업이라 시간도 오래 소요될 뿐더러 수작업으로 하다보면 실수가 나올 수도 있습니다.

또한 이후 OS 와 미들웨어의 버전 관리 및 보안 패치 적용을 생각했을 때 구성 관리를 효율적으로 하는 것이 앞으로의 운영 효율을 높이는 데 중요합니다. 이력이 제대로 관리되지 않으면 버전 정보와 설정 항목을 적어놓은 파라미터 시트와 값이 맞질 않아서 제대로 동작하지 않는 경우가 있습니다.

그래서 수작업 대신 프로그램 코드를 기반으로 관리하는 것이 좋습니다다. 이렇게 하면 편하고 작업 실수도 줄일 수 있을 뿐더러 Git 과 같은 버전 관리 소프트웨어를 이용해 변경 이력을 관리할 수 있습니다. 이렇게 코드 기반으로 인프라 구성을 관리하는 방식을 Infrastructure as Code 라고 합니다.

인프라 구성 관리 툴

• Bootstrapping : OS 시작을 자동화
  • 서버 OS 를 설치, 가상 환경 설정, 네트워크 구성 설정 등
  • Vagrant
• Configuration : OS 나 미들웨어의 설정을 자동화
  • OS 설정, 각종 미들웨어 설치 및 설정
  • Ansible, Chef, Puppet
• Orchestration : 여러 서버 관리를 자동화
  • Kubernetes : 컨테이너 오케스트레이션의 사실 살 표준(de facto standrad). 줄여서 k8s 라고도 부름.

Continuous Integration 와 인프라

http://www.pepgotesting.com/continuous-integration/

지속적인 통합은 제대로 동작하는 코드를 자동으로 유지하기 위한 방법입니다. CI 환경이 구성되어 있지 않으면 빌드가 깨지는 경우도 많고 심지어 깨진 걸 모르는경우도 있습니다. CI 환경에서 개발자가 코드를 커밋하면 Jenkins 와 같은 인테그레이션 툴이 코드 커밋을 감지해 자동으로 빌드와 테스트를 수행하고 코드 품질을 점검합니다. 문제가 있을 경우 해당 개발자에게 피드백이 가서 빠르게 조치하고 좋은 품질의 코드를 계속 유지할 수 있습니다.

단위 테스트를 통과한 모듈이 다른 환경에서도 똑같이 동작한다는 보장은 없습니다. 각종 설정이나 네트워크, 권한 등 인프라 환경에 의존하는 부분이 많은데요, 이러한 부분을 코드로 관리한다면 개발 멤버가 항상 동일한 환경에서 개발할 수 있어 테스트가 쉽고 환경 구성 관리가 더욱 쉬워집니다.

Continuous Delivery 와 인프라

http://www.pepgotesting.com/continuous-integration/

폭포수 모델에서는 처음 요구사항을 정의하는 시기와 실제로 SW를 고객에게 전달(delivery)하는 시기가 워낙 차이가 나다보니 문제가 생기곤 합니다. 물론 그 과정에서 고객이 아예 관여하지 않는 것은 아니지만, 대규모 프로젝트의 경우 몇 년이 소요되기도 하다보니 계속 변화하는 고객의 생각과 니즈를 충족시키기 어렵습니다.

고객의 입장에서는 시간이 지나면서 다른 기능이 계속 눈에 들어오다보니 실제 결과물이 마음에 차지 않게 되고, 개발하는 입장에서는 처음에 말한대로 다 만들었는데 개발 막바지에 수정이나 추가 개발을 해야하는 상황이 되는 것이죠.

http://www.pepgotesting.com/continuous-integration/

그래서 서로를 만족시키기는 방법은 고객의 니즈는 변한다는 것을 인정하고, 그 대신 개발 사이클 자체를 짧게 해서 개발과 릴리즈를 반복하는 것입니다. 실제로 동작하는 SW 를 고객에게 주기적으로 딜리버리함으로써 고객의 피드백을 받고 반영하는 것을 Continuous Delivery 라고 합니다.

그런데 지속적으로 딜리버리하는 과정에서 테스트 환경과 실제 운영 환경이 달라서 문제가 발생하기도 합니다. 인프라 환경도 포함한 애플리케이션 실행 환경을 그대로 제품 환경에 딜리버리할 수 있다면 안전하게 버전업을 할 수 있게 됩니다.