사이드 프로젝트 진행 전 기술 스텍을 정하기 위한 나의 생각을 정리한다.
두 번째로 도커를 사용 할 것인가에 대해 정리해본다.
도커가 뭔데 ?
도커 : 컨테이너 기반의 오픈소스 가상화 플랫폼
컨테이너 : 개별 애플리케이션 실행에 필요한 실행환경을 독립적으로 운용할 수 있도록 기반환경 또는 다른 실행환경과의 간섭을 막고 실행의 독립성을 확보해주는 운영체계 수준의 격리 기술
도커 왜 쓰는데 ?
도커에 관한 다른 장단점이 많겠지만 이번에 처음으로 사용해보려는 입장에서
짧은 지식으로 우리 상황에 와닿는 내용들만 정리해서 적어본다.
도커를 사용하지 않고 서버 구성을 했을 때 문제점
- 서버 확장 또는 이전하는 경우 라이브러리, 패키지 등 설정들을 반복 해주어야하며 각각의 버전에 따라 변화가 있을 수 있으니 버전도 신경써줘야한다.
- OS 환경마다 명령어나 설치과정 등 다른 부분이 많다.
도커를 사용 했을 때 장점
- 도커 파일을 통해 서버 설정(운영 기록)을 관리하게 되고 도커 이미지를 만들면서 해당 설정에 관한 테스트가 가능하다.
예시 : 특정 라이브러리 설치 또는 실행 명령어를 도커 파일로 작성후
이미지 빌드 시 도커 파일이 실행 되면서 오류 사항 처리 가능- 도커 이미지를 통해 도커 컨테이너를 띄울 때 필요에 따라 환경 변수 형식으로 간단하게 변형을 줄 수 있다.
- OS를 신경쓰지 않고 도커 명령어만 숙지해도 운영이 가능하다.
- 운영 기록과 실행 시점이 담긴 도커 이미지의 존재로 인해 서버 확장 또는 이전이 매우 간단하다.
그래서 너는 쓰고 싶어 ?
결론 : 필요하다고 생각한다.
이전 글인 AWS EC2 / Lightsail 중 어떤 것을 사용할 것인가에 관한 내용에서 Lightsail을 선택 했고 이것이 팀의 결정이 되었다면 도커의 사용은 필요하다고 생각한다.
Lightsail의 단점 중 큰 것이 인스턴스 확장/수정이 불가능 하다는 것이다.
그렇다면 우리가 개발 단계 에서는 낮은 가격의 인스턴스를 사용하다가 트래픽이 몰리거나 모종의 사건으로 성능이 부족해졌다면 Lightsail의 경우 인스턴스를 다시 구축해야한다.
이와 같은 상황을 쉽게 타파 하려면 도커를 사용하여 우리 프로젝트를 이미지화 시키고
새로운 인스턴스를 사용해야 할 경우 해당 이미지를 컨테이너 환경에서 배포한다면
Lightsail의 단점을 상쇄 시킬 수 있다고 생각한다.
컨테이너 환경인데 쿠버네티스는 안 써 ?
결론: 안 쓰는게 좋다고 생각한다. (오버 엔지니어링 이라고 생각한다.)
쿠버네티스란 컨테이너 오케스트레이션 플랫폼으로, 컨테이너화된 애플리케이션을 배포, 확장 및 관리하는 데 사용된다고 하는데 우선 아직 이해도가 부족하다.
짤막한 지식으로 느끼는 쿠버네티스는 규모가 큰 대규모 서비스의 경우 빛을 본다고 생각한다.
트래픽이 높아져서 스케일링, 로드 밸런싱 등과 같은 작업이 많아지는 환경에서
쿠버네티스와 같은 툴을 사용해 자동화를 구성하면 매우 좋을 것 같다고 느꼈다.
하지만 우리가 개발하려는 서비스는 규모가 작은 사이드 프로젝트이며
대규모 트래픽을 받을 것이라는 보장이 없다.
물론 대비한다 라는 의견은 좋은 의견이 될 수 있지만
이것이 과하면 가능한 빨리 마무리 하려는 프로젝트의 기한이 늘어나게될 것이라고 생각한다.
정해진 기한이 있다면 선택과 집중이 필요할 것 같고
쿠버네티스는 우리의 상황에 적합하지 않은 선택이라고 생각된다.
