프로비저닝과 Iac의 대한 개인적인 고찰!

2019, Jun 10    

VM

현재 하드웨어를 사용하여 현재 운영체제와 다른 게스트 운영체제를 동작할 수 있도록 하는 에뮬레이션 소프트웨어이다.

Container

OS 전체를 가상화하지 않고 각자 독립된 프로세스로 실행하는것이다. 이 때 기동의 필요한 모든 파일은 고유한 이미지에서 제공됩니다.

그래서 프로비저닝은 뭔가?

  • 어떠한 장비에 대해 아래의 응용프로그램이 동작할 수 있는 환경을 셋팅해주는 작업을 의미한다.

    • install Library
    • network setting
    • disk volume setting
    • os setting (swapoff -a, ulimit)

그래서 뭐가 좋고 나쁜가?

- 일련의 배포 및 설정 변경 작업은 쉘 스크립트를 동작시켜 이용하여 작업한다.
- 이 경우에 SE가 얻을 수 있는 장점은 간단하게 작성하여 동작시킬 수 있다
- 다만 단점으로 디버깅, 유지보수가 어렵다는 점이 있다.

왜 배포 자동화를 해야할까?

우리는 고객의 요구를 반영하여 개발된 기능 피처들을 다른 경쟁 서비스보다 빠르게 배포하는 Time-to-market를 지향해야 한다.

위와 같이 서비스의 기능 피처를 빠르게 배포 하기 위하여 탄력적인 인프라스트럭처의 구축이 필요하다.

IaC (Infrastructure as code)

개발자나 운영자가 별도의 하드웨어 장치 및 운영 체제 환경을 구성하기 위해 수동 프로세스를 사용하는 것이 아니라 소프트웨어를 통해 애플리케이션에 대한 기술 스택을 자동으로 관리하고 프로비저닝하는 것의 일종이다.

  • 시스템을 담당하던 SE가 없이 인프라 자체를 코드로 관리하면 유지보수 용이하다

  • 한번 성공한 인프라 코드는 다음에도 성공한다는 안정성을 보장한다.

  • 코드를 기반으로 인프라스트럭처를 구성하면 스케일 아웃이 용이하다.

사용하는 코드 가능한 도구들

  • CMT (Config Manage Tool)

    • vagrant -> VM 기반 ~Ruby 개X~
    • Ansible SSH -> 리모트 쉘 기반

빌드 자동화로 얻을 수 있는 이점

  1. 개발자는 기능 개발에 열중할 수 있다.
  2. 빌드를 자동화하고 빌드된 앱을 버전 관리함으로써 문제 발생 시 빠르게 원복이 가능하다.

왜 모니터링을 해야하는가?

  1. 데이터를 기반으로 한 의사 결정이 가능하다
  2. 다양한 리소스에 대해 애플리케이션이 어떻게 점유하는지 확인 가능 이를 활용하여 장애 포인트를 분석할 수 있다