클라우드가 대세가 되기 전을 한번 생각해보자.
지금처럼 클라우드가 대세가 되기 이전에는 인프라를 운영하는 것이 상당한 작업이었다. 물리적인 인프라를 서비스 운영을 위해서는 유지 보수를 해야 했기 때문이다. 그래서 서비스를 위해 인프라를 세팅하고 서비스를 운영하고 있을 때는 인프라 변경이 어렵고 고통스러운 작업이었다.
그래서 배포라고 하면 단지 바뀐 애플리케이션에 대해서만 배포를 하는 수준이었다. 그리고 서비스의 상황에 따라 애플리케이션 실행환경이 바뀌면 기존 인프라를 업데이트하면서 계속적으로 인프라를 유지 보수하였다.
이렇게 운영을 할 때 단점은 유연한 인프라 관리가 힘들다는 점이다.
실제로 저도 예전에 프로젝트에서 경험했던 케이스를 예로 실제 서비스 운영에서 단점을 알아보도록 하자.
일반 유저들을 상대로 하는 쇼핑몰 서비스였는데 회원도 몇백만 명이 될 정도로 많았다. 그런데 하루는 이벤트로 인해 동접 좌수가 급속하게 많아졌다.
인프라를 증설해야 되는 상황이었는데 즉각적 대응이 되지 않고, 사이트가
계속적으로 오류가 나고 몇 시간 이후에 인프라를 IDC 센터에 물리적으로 증설해서 가까스로 문제를 해결했다.
여기서 문제가 2가지 정도가 있다.
- 물리적 인프라를 준비하려면 즉각적으로 대처가 되지 않는다.
- 물리적 인프라 준비가 완료되었더라도 애플리케이션 실행환경을 준비하려면 또 시간이 걸린다.
첫 번째 부분은 설명을 안 해도 다들 이해할 내용이고,
클라우드라는 부분으로 지금은 충분히 해결된 내용이다.
그리고 두 번째 내용이 Immutable infrastructure 패러다임에서 좀 더 부각되고 있는 부분이다.
예를 들어 jdk 1.8의 환경이 필요한 애플리케이션을 위해서는 서버에 jdk를 설치해야 한다. 그러므로 해당 애플리케이션의 실행환경이 무엇인지 인지하고
해당 버전을 설치해 주어야 애플리케이션이 정상적으로 동작할 것이다.
그런데 서비스를 운영하다 보면 jdk 버전을 어떤 문제로 인해 업데이트도 하고 jdk 버전뿐만 아니라 해당 애플리케이션을 작동시키기 위해 많은 의존적인 환경이 존재한다. 이 부분은 서비스의 크기가 크면 클수록 더 많은 부분이 존재할 것이다. 그러나 기존의 방식대로 운영할 경우 인프라의 변경 내용에 대해서는 버전 관리를 하지 못하게 된다.
이런 부분들은 서비스가 성장할수록 더욱더 운영에 마이너스로 작용할 것이다. 그리고 관리하는데 생각보다 상당한 어려움을 겪게 된다.
그래서 클라우드가 대세가 되면서 동시에 Immutable infrastructure라는 패러다임이 대세가 되었다.
docker 뿐만이 아니더라도 많은 인프라 관련 프로그램들이 Immutable infrastructure라는 개념을 지원하고 있지만 이 글에서는 docker에 집중해서 설명해 보려고 한다.
이전 글에서 설명한 대로 docker는 애플리케이션뿐만 아니라 실행환경 자체를 이미지화해서 컨테이너를 실행할 때 기반이 되게 함으로써 실행환경 자체를 버저닝 하고 관리할 수 있다. 마치 github에 소스의 버전을 관리하는 것과 같이 인프라의 실행환경 자체를 버저닝 해서 관리할 수 있다.
docker를 사용하여 인프라를 버저닝 해서 관리하게 되면 인프라를 관리자가
수작업으로 관리할때 일어날 수 있는 오류들을 미연에 방지해주고 프로그램 소스와 마찬가지로 인프라의 실행환경을 버저닝하고 변경 history를 관리해줌으로써 서비스 운영에 중요한 인프라 변경들을 인지하게 해준다.
그리고 갑작스러운 서버자원의 스케일업을 docker로 인해 자동화 함으로써
대응 시간을 줄여준다.
이 글에서는 가볍게 Immutable infrastructure의 개념을 알아보았고,
docker를 사용해서 이 개념을 활용했을 때 이점을 간단하게 알아보았다.
1편으로 끝내려고 했는데 실질적인 예시를 제시하지 못한 것 같아서
예시를 좀 준비해서 2편은 실질적으로 배포 시 해당 개념을 어떻게 활용했는지 적어봐야겠다.
