컨테이너를 통한 서비스의 확장
스타트업 전문 DevOps/SRE 컨설팅 및 교육 서비스를 제공하는 Devlift 입니다. 저희는 싱가포르와 한국에서 근무하는 DevOps/SRE 현직자로 이뤄져 있는 팀입니다.
Devlift에서 발신하는 컨텐츠에 관심이 있으신 분들은 링크 통해서 이메일 남겨주시면 주기적으로 다양한 DevOps/SRE 컨텐츠 및 강의 할인 정보 등을 전달해드릴게요.
오늘 다뤄볼 주제는 서비스의 확장성(Scalability)입니다.
현재 서비스를 어떻게 배포하고 운영하고 계신가요? 스타트업 개발자 분들과 미팅을 하다보면, 대체로 EC2를 통해서 서비스를 배포하고 운영하고 계신 거 같아요. 서버리스나 컨테이너 등 새로운 기술들이 있다는 것도 알고 있지만, 주어진 시간에 맞춰서 기능을 배포하려면 배포 방식까지 최적화하기란 쉬운 일이 아닙니다.
(참고로 EC2는 AWS에서 운영하는 가상머신을 의미하며, 실제 서버 컴퓨터를 구매할 필요 없이 굉장히 적은 컴퓨터 리소스를 대여할 수 있는 서비스입니다.)
서비스 극초기에는 하나의 EC2에 서버와 데이터베이스를 함께 운영하시기도 하고, 서비스가 베타 단계가 지나가면 그래도 Autoscaling group 등을 통해서 EC2가 자연스럽게 늘어날 수 있게 세팅 정도는 해주시는 것 같아요. 데이터베이스도 별도로 구성해주시고요. 개인적으로는 개발 인원 5인 이하의 개발팀에서 저 정도 구성만 해주셔도 훌륭하다고 생각을 합니다. 서비스에 따라서 다르겠지만, 동시 접속자가 1000명 이하의 서비스라면 저정도 구성으로도 충분히 운영이 가능할 거에요.
[갑자기 서비스의 확장이 필요할 때]
그런데 갑자기 서비스가 너무 잘 되면 어떻게 될까요? 비지니스 관점에서는 너무 좋은 일이지만, 개발팀에게는 아주 곤란한 상황이 벌어질 수 있습니다. 서비스가 계속 터지고, 신규 고객들이 돌아가지 않는 서비스에 이탈하는 건 제법 흔한 일이에요. 특히 한국은 Java를 기업에서 많이 활용하는데, 서비스가 내려가고 다시 올리는 과정에서 리눅스 서버가 실행되고 거기에 Java 어플리케이션이 돌아가는 시간은 제법 깁니다. 그러면 하얗게 변한 브라우저 화면을 보면서 개발팀원 분들 머리도 새하얗게 변하기 쉽죠.
흔히 일어나는 일을 예시로 들어봤는데요. 그렇다면 이런 상황을 어떻게 방지할 수 있을까요? 그 답은 컨테이너 기술에 있습니다. 컨테이너는 아주 간단하게는 경량화된 가상머신이라고 생각할 수 있습니다. 컨테이너는 실행될 때 일반적인 가상머신들처럼 운영체제를 별도로 실행시키지 않아도 되기 때문에, 새로운 서비스를 실행할 때 소요되는 시간을 매우 단축시킬 수 있습니다. 또한 운영체제가 하나 설치 되는데 최소 몇 GB는 소모되는데 반해, 컨테이너는 서비스가 실행되기 위한 최소한의 요소를 가지고 있기 때문에 불필요한 서버 자원을 아낄 수 있는 장점도 있습니다.
[컨테이너, 그 외의 장점들]
그 외에도 컨테이너가 가지는 여러 가지 장점들이 있는데요. 그 중 하나는 같은 이미지를 통해서 생성된 컨테이너는 모두 동일하다는 점입니다. 실제 배포 및 운영 업무를 해보지 않으신 분이라면 이게 왜 장점인지 이해하기 어려우실 거에요.
위에서 소개한 것과 같은 EC2를 통해서 직접 배포하는 경우에는 SSH라는 프로토콜을 통해서 해당 서버에 접속을 해서 배포하는 경우도 흔히 있습니다. 이때 문제가 되는 점은 여러 서버를 한 번에 관리할 때 서버별로 환경이 조금씩 달라질 수 있다는 점입니다. 그래서 배포를 할 때 분명히 같은 스크립트를 실행시켜도 실패하는 경우가 생길 수 있습니다.
컨테이너를 활용하면 언제든 같은 환경에서 실행된다는 보장이 되기 때문에 운영 측면에서 훨씬 안정성이 확보가 됩니다. 같은 맥락에서 만약에 새롭게 배포한 서비스에 문제가 있는 경우에는 서버마다 하나하나 들어가서 기존의 코드로 돌리는 수고로움 없이, 이전에 사용한 컨테이너 이미지를 활용하여 쉽게 롤백이 가능하기도 합니다.
[마치며]
EC2와 같은 가상머신 환경에만 익숙하신 분이라면, 컨테이터 기술을 처음 배울 때는 분명히 학습 과정에서 다양한 어려움이 있을 수 밖에 없습니다. 컨테이너가 기존의 가상머신 배포 방식을의 단점을 극복하기 위해서 나온 만큼 그를 보완하기 위한 다양한 기능을 가지고 있기 때문입니다.
또한 기존에 Jenkins 등과 같은 CI/CD 파이프라인으로 가상머신 배포 환경이 세팅되어 있는 경우에는, 새로운 배포 파이프라인을 구축해야하기 때문에 그것도 심리적인 장벽으로 느껴지기가 쉽습니다.
하지만 초반의 그런 불편함을 조금만 참아내면, 새로운 세상이 펼쳐집니다. 어떠신가요? 컨테이너로 한 번 배포해보시겠어요?
