Docker를 사용한 배포 방식 덕분에 다중 환경 배포에 걸리는 시간을 10분의 1로 줄였으며, 10명으로 구성된 팀에게 운영 및 유지보수 업무를 담당할 인력을 2명이나 절약할 수 있었습니다.

지난달 싱가포르에 있는 우리의 소규모 전자상거래 SaaS 팀이 거의 파산할 뻔했습니다. 대규모 프로모션을 앞두고 동남아시아의 3개 사이트에 재고 동기화 기능을 업데이트했는데, 현지에서는 모두 잘 테스트되었습니다. 하지만 인도네시아의 클라우드 서버에 배포하자마자 의존성 문제가 발생하여 2개의 백엔드 서버와 1개의 운영팀이 18시간 동안 문제를 해결하기 위해 애썼습니다. 그로 인해 3일 앞당겨야 했던 스트레스 테스트 계획이 지연되었습니다.

먼저 이해해야 할 것은: Docker 배포가 도대체 무엇인가입니다.

간단히 말해, 앱 코드, 의존 라이브러리, 설정 파일, 심지어 운영체제 커널 설정까지 모두 표준화된 “컨테이너 이미지”로 패키징하는 것입니다. 로컬에서 어떻게 실행되는지와 상관없이, Docker 엔진이 설치된 어떤 서버에서도 동일하게 실행됩니다.단일 이미지의 최소 크기는 20MB까지 가능하며, 시작 시간은 1초를 초과하지 않습니다.。

우리는 3개월 동안의 실제 수익을 사용했습니다.

먼저, 환경 불일치 문제를 완전히 해결했습니다. 이전에는 각 사이트에 맞는 다른 Node.js 버전과 데이터베이스 드라이버를 설정하는 데만 반나절이 걸렸는데, 이제는 패키징된 이미지를 이미지 저장소에 바로 업로드하면 세 사이트를 한 번에 설치할 수 있습니다. 배포 시간이 평균 4시간에서 24분으로 줄었으며, 대규모 프로모션 전에 버전을 업데이트할 때도 밤새 기다릴 필요가 없습니다.

둘째로, 서버 자원의 활용률이 두 배로 증가했습니다. 이전에는 각 사이트마다 2코어의 4G 클라우드 서버를 별도로 임대했는데, 여유 시간에 CPU 사용률이 10%도 되지 않았습니다. 이제는 Docker를 사용하여 세 사이트의 애플리케이션, 캐시, 예약 작업을 모두 4코어의 8G 서버에 통합했더니, 자원이 딱 충분히 활용되고 있습니다.매월 서버 비용이 620달러나 절약되었습니다.10명 미만의 소규모 팀에게는 그다지 적은 수가 아닙니다.

마지막으로, 확장 속도가 급격한 트래픽 증가에 완전히 대응할 수 있습니다. 지난해 블랙프라이데이에는 임시로 서버를 추가하는 데 거의 2시간이 걸렸지만, 올해는 피크 시간 10분 전에 12개의 컨테이너 복제본을 준비하여 평소 트래픽의 3배에 달하는 부하를 견뎌냈으며, 요청 시간 초과가 발생한 적이 없습니다.

차에 타기 전에 조금만 기다려주세요. 이 몇 개의 구덩이들은 이미 우리가 대신 피해봤어요.

첫 번째 문제는 이미지가 너무 복잡하고 용량이 크다는 것이었습니다. 처음에는 공식 Node.js 전체 기능을 포함한 이미지를 그대로 사용하여 애플리케이션 이미지를 패키징했는데, 이 이미지의 크기가 1.2G에 달했고 해외 이미지 저장소로 전송하는 데 20분 이상이 걸렸습니다. 그 후 Alpine 기반의 이미지로 바꾸고 불필요한 의존성들을 모두 제거한 결과, 이미지의 크기가 90MB로 줄어들어 전송 속도가 10배 이상 빨라졌습니다.

두 번째 문제는 데이터가 컨테이너 안에 저장되어 있다는 것이었습니다. 처음에는 이를 주의하지 못해서 사용자가 업로드한 상품 이미지를 컨테이너의 로컬 디렉터리에 그대로 저장했는데, 컨테이너가 재시작되면서 모든 이미지가 사라졌습니다. 하루 종일 백업에서 데이터를 복구하는 데 시간이 걸렸습니다. 그 후로는 모든 영구화된 데이터를 서버의 로컬 디렉터리나 객체 저장소에 저장하게 되었고, 이후로는 더 이상 문제가 발생하지 않았습니다.

세 번째 문제는 리소스 제한을 설정하지 않은 것입니다. 처음에 서비스를 온라인으로 출시할 때 컨테이너에 CPU와 메모리의 상한을 설정하지 않았는데, 어느 사이트의 정기 작업에 버그가 발생하여 전체 서버의 CPU 자원을 모두 소모해버렸고 그 결과 다른 두 사이트도 모두 다운되었습니다. 그 후에는 각 컨테이너에 리소스 상한을 설정했기 때문에, 단일 서비스에 문제가 발생하더라도 전체 시스템에 영향을 미치지 않게 되었습니다.

Docker를 사용할지 말지에 대한 결정 기준은 매우 간단합니다.

사용 시나리오: 여러 서버에 동일한 애플리케이션을 배포해야 하거나, 개발/테스트/생산 환경을 자주 전환해야 하며, 팀 규모가 3명 이상이고 각자의 개발 환경이 다를 경우, Docker를 사용하면 효율성이 향상됩니다.

사용해서는 안 되는 경우: 당신이 가진 블로그가 하나뿐이고, 단 한 대의 서버에서만 운영되고 있으며, 코드를 6개월에 한 번만 업데이트한다면 Docker를 배울 필요가 전혀 없습니다. 그냥 보타(Baota)를 사용하거나 수동으로 배포하는 것이 더 편리할 것입니다.

처음 사용하는 분들을 위한 3가지 구체적인 조언

• 처음 3번의 이미지 패키징은 공식의 최상의 관행 템플릿을 그대로 사용하세요. 직접 Dockerfile을 임의로 작성하지 마세요. 이렇게 하면 이미지의 불필요한 부분을 80% 이상 줄이고 권한 문제를 피할 수 있습니다.
• 처음에는 K8s와 같은 복잡한 오케이션 도구를 사용하지 않고, Docker Compose를 사용하여 3개 이하의 서비스를 관리하는 것만으로도 충분합니다.
• 미러 저장소는 클라우드 제공업체의 해외 노드를 사용하세요. 직접 설정하는 것보다 시간을 절약할 수 있으며, 그 시간으로 다른 기능들을 더 많이 개발할 수 있습니다.

흔한 작은 문제들에 대한 통합 답변

질문: Docker가 서버 성능을 많이 소모하나요? 저희가 테스트해본 결과, 성능 저하가 5% 미만이어서 대부분의 중소 규모 팀들은 전혀 느끼지 못할 것입니다.

질문: 이전에 사용하던 구형 애플리케이션을 Docker로 마이그레이션할 수 있을까요? 물론 가능합니다. 저희는 3년 동안 사용해온 PHP 프로젝트가 있는데, 2일 만에 이미지를 만들어 마이그레이션을 완료했습니다. 새로운 환경을 설정하는 것보다 훨씬 빠르죠.