애플리케이션 개발 트렌드는 기술 및 비기술 업계를 막론하고 디지털 우선 전략을 통해 보다 클라우드 네이티브 및 분산 모델을 지향하고 있습니다. 많은 기업이 경쟁력을 유지하기 위해 새로운 기술과 분산 워크플로를 채택하고 있습니다.
소프트웨어 개발 파이프라인을 통해 팀은 효율적으로 협업하고 생산성을 유지할 수 있습니다. 특히, 컨테이너화 및 멀티 클라우드 환경을 일찍 채택한 많은 조직이 현재 민첩성과 확장성을 선도하고 있습니다. SaaS 플랫폼을 개발하든, 레거시 시스템을 현대화하든, 지속적인 배포를 지원하든, 컨테이너와 오케스트레이션 도구가 전체 상황에 어떻게 부합하는지 이해하면 도움이 됩니다.
Docker 소개
Docker는 오픈 소스 컨테이너 기술이자 소프트웨어 컨테이너의 기본 플랫폼입니다. 이 컨테이너로 애플리케이션을 라이브러리, 도구 및 런타임을 포함한 복제 가능한 단일 패키지로 캡슐화하여 AWS, Microsoft Azure 및 Google Cloud와 같은 여러 호스팅 환경에서 일관되게 실행할 수 있습니다.
Docker 컨테이너는 기본 인프라에 관계없이 애플리케이션이 동일한 방식으로 작동할 수 있도록 지원하여 소프트웨어 개발 세계에 혁신을 가져왔습니다.
오늘날 개발자는 Docker를 사용하여 마이크로서비스이라는 모듈을 빌드합니다. 마이크로서비스는 패키지를 분산하고 작업을 독립적인 통합 단위로 분할하여 협업하도록 지원합니다. 예를 들어 전국 피자 체인점의 개발자는 주문을 받고, 결제를 처리하고, 요리사의 ‘조리하기’ 티켓과 배달원의 배달 티켓을 생성하는 마이크로서비스 애플리케이션을 구축할 수 있습니다. 이러한 마이크로서비스는 함께 작동하여 전국 각지에서 피자를 조리하고 배달합니다.
Docker 아키텍처의 주요 구성 요소
사람들이 Docker를 얘기하는 경우, 컨테이너를 빌드하고 실행할 수 있는 런타임을 의미하는 Docker 엔진을 가리킵니다. 하지만 Docker 컨테이너를 실행하려면 먼저 Dockerfile을 만들어야 합니다.
- Dockerfile: OS 네트워크 사양 및 파일 위치 등 컨테이너 이미지를 실행하는 데 필요한 모든 것을 정의합니다.
- Docker Image: Docker 파일이 있으면 Docker 엔진에서 실행되는 포터블 정적 구성 요소인 Docker 이미지를 빌드할 수 있습니다. Docker Image는 Docker 컨테이너를 빌드하기 위한 일련의 지침(또는 템플릿)입니다.
- Docker Compose: 주로 단일 호스트에서 멀티 컨테이너 Docker 애플리케이션을 정의하고 실행하는 데 사용되며, 개발에 이상적입니다. 호스트 간 클러스터링하는 경우, Kubernetes가 이제 표준이 되었습니다.
- Docker Swarm: 개발자는 Docker Swarm을 사용하여 Docker 호스트 풀을 단일 가상 Docker 호스트로 전환할 수 있습니다. Swarm은 멀티 호스트 애플리케이션에 자동으로 설치됩니다.
- Docker Hub: Docker Hub는 컨테이너화된 마이크로서비스로 구성된 방대하고 발전하는 에코시스템입니다. NGINX, MySQL, Redis와 같은 유명 서비스의 공식 빌드는 물론 커뮤니티에서 관리하는 수천 개의 이미지를 포함하여 수백만 개의 컨테이너 이미지를 호스팅합니다.
AWS에서 실행하는 경우 Amazon EC2 컨테이너 서비스(ECS)는 Docker 컨테이너를 지원하는 컨테이너 관리 서비스로, Amazon EC2 인스턴스 관리형 클러스터에서 애플리케이션을 실행할 수 있습니다. ECS는 작업 관리 및 스케줄링을 포함한 클러스터 관리 기능을 제공하므로 애플리케이션을 적극적으로 확장할 수 있습니다. 또한 Amazon ECS를 사용하면 기업 클러스터 관리자를 설치 및 관리할 필요가 없습니다. ECS를 사용하면 Docker 지원 애플리케이션을 설치 및 삭제하고, 클러스터의 상태를 쿼리하고, API 호출을 통해 AWS 서비스(예: CloudTrail, ELB, EBS 볼륨) 및 보안 그룹 같은 기능에 액세스할 수 있습니다.
Docker에서 마이크로서비스를 사용하여 설계하려면 새로운 사고와 접근 방식뿐만 아니라, 안정적이고 확장 가능한 통합을 구축할 수 있는 독보적인 능력도 필요합니다.
마이크로서비스 소개
마이크로서비스은 기존의 모놀리식 애플리케이션 개발 방식에서 벗어난 변화를 의미합니다. 개발자는 대규모 애플리케이션 하나를 개발하는 대신 특정 비즈니스 기능에 특화된 클라우드 호스팅 하위 애플리케이션을 만듭니다. 마이크로서비스는 애플리케이션 로드 밸런싱을 분산하고 복제 가능하고 확장 가능한 서비스 상호 작용을 통해 안정성을 보장합니다.
그렇다면 모놀리식 통합을 분리하는 적절한 접근 방식은 무엇일까요? 엔지니어는 애플리케이션을 모듈로 분해할 때 계획된 분해 패턴을 따라 새 소프트웨어 모듈을 논리적 작업 그룹으로 분류하는 경향이 있습니다.
예를 들어, 현재 과일 애플리케이션을 사용하는 식료품 체인점의 배송 및 추적 소프트웨어는 바나나, 오렌지 등을 처리하는 모듈로 분해될 수 있습니다. 이렇게 하면 추적 기능은 개선될 수 있지만 논리적 하위 도메인(이 경우 과일)을 따라 소프트웨어를 분해하면 경영 능력 면에서 뜻밖의 결과를 초래할 수 있습니다.
마이크로서비스 아키텍처는 다른 방식으로 모듈을 구성합니다. 비즈니스 역량을 중심으로 애플리케이션을 분해하고 마이크로서비스를 개발, 지원 및 지속적으로 배포할 교차기능 팀을 만듭니다. 파울러는 ‘프로젝트가 아닌 제품’이라는 비즈니스 중심 분해 접근 방식을 강조합니다. 패키지를 제공하는 것은 완료와 동시에 팀이 해체되는 일회성 프로젝트가 아니라 우수한 제품을 꾸준히 제공하기 위한 지속적, 협력적 결속입니다.
마이크로서비스로 모놀리식 애플리케이션 개발에서 볼 수 있는 기존 스토리지 모델도 분산시킬 수 있습니다. 마이크로서비스는 동일한 데이터베이스 기술의 반복 인스턴스 또는 서비스에 가장 적합한 별도의 데이터베이스 유형을 혼합한 자체 데이터 저장소의 네이티브 방식으로 관리하는 것이 가장 효과적입니다. 마이크로서비스 접근 방식의 장점은 여전히 연구 중입니다. 따라서 모든 시스템과 마찬가지로 이 방식의 잠재적인 위험과 한계에 유의해야 합니다.
마이크로서비스 아키텍처 구축 문제
마이크로서비스의 이점에는 몇 가지 문제가 있습니다.
- 서비스 추적: 여러 컨테이너와 호스트에 분산된 서비스는 추적하기 어려울 수 있습니다. 한 곳에서 모놀리식 통합을 조정하는 대신 환경 전체에 흩어져 있는 협업 마이크로서비스를 인벤토리화하여 빠르게 액세스할 수 있어야 합니다.
- 신속한 리소스 확장: 마이크로서비스는 모놀리식 애플리케이션보다 훨씬 적은 리소스를 소비하지만, 아키텍처가 확장됨에 따라 운영 중인 마이크로서비스의 수가 급격히 증가한다는 점을 기억하세요. 적절한 관리가 이루어지지 않으면 많은 소규모 호스트가 모놀리식 애플리케이션만큼 많은 컴퓨팅 성능과 스토리지를 소비할 수 있습니다.
- 비효율적인 최소 리소스: AWS 환경을 사용하는 경우 모든 작업에 할당할 수 있는 리소스의 하한선이 있습니다. 마이크로서비스가 너무 작아서 최소한의 Amazon EC2 인스턴스만 필요할 수 있으며, 이로 인해 마이크로서비스 리소스 실제 수요보다 많은 리소스 및 비용이 낭비될 수 있습니다.
- 배포 복잡성 증가: 마이크로서비스는 독립형이며 다양한 프로그래밍 언어로 개발할 수 있습니다. 그러나 모든 프로그래밍 언어는 자체 라이브러리와 프레임워크에 의존하므로 완전히 다른 라이브러리와 프레임워크 세트가 필요합니다. 이로 인해 리소스 오버헤드(및 비용)가 증가하고 배포를 복잡하게 만드는 고려 요인이 됩니다.
하지만 이러한 장애 요소를 극복할 수 없는 것은 아닙니다. 바로 이 단계에서 Docker와 같은 컨테이너 기술로 기존의 격차를 메울 수 있습니다.
마이크로서비스를 지원하는 Docker
Docker 기술은 다음을 통해 마이크로서비스 문제를 해결합니다:
- 작업 격리: 마이크로서비스마다 Docker 컨테이너를 만듭니다. 이렇게 하면 오버프로비저닝된 인스턴스가 거의 존재하지 않는 단독 서비스의 부담으로 인해 유휴 상태가 되는 리소스 부풀리기 문제를 해결할 수 있으며 인스턴스당 여러 개의 컨테이너를 실행할 수 있습니다.
- 코딩 언어 지원: 라이브러리 및 프레임워크 정보를 포함하여 프로그래밍 언어 실행에 필요한 모든 서비스를 연결된 컨테이너로 나누어 여러 플랫폼을 간소화하고 관리합니다.
- 데이터베이스 분리: 스토리지 분리를 위해 Docker 볼륨 또는 전용 데이터 컨테이너를 사용합니다.
- 모니터링 자동화: Sumo Logic과 같은 도구와 Docker를 통합시켜 실행 중인 컨테이너, 로그 및 지속적 배포 파이프라인의 성능 메트릭을 모니터링합니다.
아키텍처 구현을 위한 5가지 원칙
- 기반을 탄탄하게 다지기. 모든 것은 사람으로부터 시작되므로 마이크로서비스 환경에서 살아 숨 쉴 준비가 되어 있는지 확인하세요.
- API 우선 설계. 마이크로서비스마다 통신 인터페이스 역할을 하는 명확하게 정의된 API 계약(주로 REST 또는 gRPC)이 있어야 합니다. 느슨한 결합 및 검색 가능성을 지원하는 서비스 API 우선 설계
- 관심사의 분리 보장. 마이크로서비스마다 단일 목적이 정의되어야 합니다. 작업을 추가해야 한다고 느껴지면 대신 새 마이크로서비스(및 새 API)를 추가하세요.
- 테스트를 통한 생산 승인. 각 마이크로서비스에 대한 포괄적인 테스트 매개 변수를 작성한 다음 이를 전체 테스트 집합으로 결합하여 지속적 배포 파이프라인에서 사용하세요.
- 배포 자동화. 마이크로서비스 환경에서 코드 분석, 컨테이너 보안 검사, 합격/불합격 테스트 및 기타 가능한 모든 프로세스를 자동화하세요. 컨테이너 오케스트레이션 도구와 지속적 배포 파이프라인을 활용하여 대규모 마이크로서비스를 관리하세요.
Docker와 Kubernetes는 어떤 연관성이 있나요?
Kubernetes와 Docker는 자주 함께 언급되지만 컨테이너 에코시스템에서 각각 다른 역할을 합니다. Docker는 컨테이너 런타임을 제공하며 Docker CLI, Docker Daemon, Docker Desktop, Docker Compose 및 Docker Hub와 같은 도구를 포함합니다. 또한 머신 클러스터 전반에서 컨테이너를 오케스트레이션하고 스케줄 예약하는 기본 클러스터링 도구도 제공합니다.
반면, Kubernetes는 컨테이너 오케스트레이션 플랫폼으로 클러스터 전반에서 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하도록 개발했습니다. 프로덕션 환경에서 대규모 노드 클러스터를 효율적으로 조정하기 위해서죠. 이는 Kubernetes 에코시스템에서 예약 단위(하나 이상의 컨테이너를 포함할 수 있음)이며 고가용성을 제공하기 위해 노드 간에 분산되는 파드라는 개념을 중심으로 작동합니다.
Kubernetes 클러스터에서 Docker 빌드를 쉽게 실행할 수 있지만, Kubernetes 자체는 완전한 솔루션이 아니며 사용자 지정 플러그인이 있어야 합니다.
Kubernetes와 Docker는 근본적으로 다른 기술이지만, 함께 잘 작동하며 분산 아키텍처에서 컨테이너의 관리 및 배포를 용이하게 해줍니다.
마이크로서비스로 전환하기
Docker 컨테이너로 구동되고 Kubernetes 클러스터를 통해 오케스트레이션되는 마이크로서비스로 전환화면 확장성, 복원력, 민첩성이 뛰어난 애플리케이션을 구축할 수 있습니다. DevOps 자동화와 결합된 컨테이너화 전략을 도입하면 애플리케이션 개발 및 배포 프로세스를 현대화할 수 있습니다.
컨테이너 관리에 대해 자세히 알아보려면 Sumo Logic의 Docker 앱 으로 Docker 컨테이너 및 Kubernetes 환경을 모니터링하고 최적화하여 성능과 가시성을 개선하는 방법을 확인해 보세요.
