skip to Main Content

컨테이너 통합 관리 솔루션 Use Case (1)

컨테이너를 쉽게 사용하기 위해 필요한 배포, 관리, 모니터링 등 여러 기능을 제공하는 통합 관리 솔루션은 여러 상황에서 효과적으로 사용됩니다.

이번 포스트에서는 컨테이너 통합 관리 솔루션이 어떻게 사용되는지 안내해드리도록 하겠습니다.

Case 1. 기존 애플리케이션의 컨테이너화

첫번째는 기존 애플리케이션을 컨테이너로 마이그레이션 하는 것입니다. 주로 개발자들이 애플리케이션을 개발할 때는 개인 환경에서 개발한 뒤에 통합 환경에서 여러 개발자의 코드를 통합합니다. 그 다음 테스트 환경에서 애플리케이션을 테스트 한 뒤에, 실제 운영 환경으로 애플리케이션을 이전하게 됩니다.

이렇게 수차례 환경을 이전하다 보면 소프트웨어의 버전이나 서버 설정의 차이로 인해 다양한 장애가 매우 빈번하게 발생하고 이를 해결하기 위해 많은 시간이 소요됩니다.

컨테이너를 사용하면 환경 이전이 쉽기 때문에 소요 시간을 대폭 줄일 수 있습니다. 

컨테이너에 애플리케이션과 애플리케이션을 구동하는 환경을 그대로 담고 그 환경 자체를 다른 서버로 이전하면, 장애 걱정 없이 신속하고 안정적으로 환경을 이전할 수 있습니다.

베어메탈 또는 VM에서 기동 되는 애플리케이션들은 각자의 운영체제, TCP 및 파일 스택 등이 필요하며 호스트 시스템의 상당한 처리 성능과 메모리를 사용합니다.

반면에 컨테이너화된 앱은 적은 메모리와 CPU 오버헤드를 사용하며, 호스트 운영체제의 커널, TCP 및 파일 스택 등의 리소스를 공유하면서 서로 독립적으로 격리됩니다. 따라서 다른 컨테이너에 영향을 끼치지 않고 유연하게 확장될 수 있어, 성능과 리소스 측면에서 활용도가 높습니다.

기존 애플리케이션을 컨테이너로 마이그레이션 하는 것의 동기는 이제 충분합니다. 그러면 어떻게 기존 애플리케이션 앱을 컨테이너화 할까요?

우선 기존 애플리케이션 앱을 분석하여 분해 가능한 마이크로서비스를 식별해야 합니다. 

기존 애플리케이션을 논리적으로 분해될 수 있는 작은 독립된 서비스로 쪼개는 것은 마이그레이션의 첫 걸음입니다. 식별된 마이크로서비스를 도커의 도움으로 컨테이너화 할 수 있습니다. 컨테이너화된 마이크로서비스를 쿠버네티스를 통해 클러스터에 배포함으로써 마이그레이션은 최종 마무리 됩니다.

전통적인 3-tier 구조의 WEB, WAS, DB로 구성된 시스템에서 WAS를 가지고 예를 들어보겠습니다.

상용 WAS인 경우 이를 운영하기 위한 3가지 종류의 인스턴스가 있습니다. Domain Admin Server, Node Manager, Managed Server 입니다.

Domain Admin Server는 도메인의 모든 리소스를 구성하고 관리 운영하는 매니저 역할을 하며, Node Manager는 관리 서버 추가 및 삭제를 담당합니다. Managed Server는 실제 서비스를 수행합니다.

도커 엔진을 통해서 Managed Server의 컨테이너 이미지를 만들어야 합니다. 이 시점에서는 노드에 대한 관리가 필요 없기 때문에 Node Manager 컨테이너가 필요 없어져 인프라 구조가 심플해 집니다.

이미지를 만들었으면 컨테이너의 데이터를 지속시키기 위해서 PV을 설정해야 합니다. 쿠버네티스에서는 여러 유형의 스토리지를 통해 PV를 제공합니다. PVC를 사용하면 컨테이너화된 WAS에서 사용하는 로그나 데이터를 스토리지에 영구적으로 저장할 수 있습니다.

인증 정보나 서비스의 구성의 하드 코딩 방지를 하고 배포의 유연함을 위해 모든 구성 정보는 환경 변수로 저장을 해야 합니다. 쿠버네티스에서는 Secret과 ConfigMap을 작성하여 이를 가능케 합니다.

이렇게 구성된 도커 이미지와 볼륨, 환경변수, Secret, ConfigMap을 조합하여 클러스터에 배포합니다. 

마이그레이션을 위해 도커 파일을 만들고, Deployment.yaml 파일을 작성하는 위와 같은 일련의 작업들은 운영자 입장에서 많은 어려움이 있습니다. 

컨테이너 통합 관리 솔루션은 이럴 때 필요합니다.

아코디언의 경우 도커 파일과 Jenkins 기반의 빌드를 수행 할 수 있는 애플리케이션 템플릿을 제공하며, 앱 배포 시 자동으로 Deployment.yaml 파일이 생성되고 커스터마이징 할 수 있는 환경을 제공하여 운영자는 손쉽게 기존 애플리케이션을 컨터이너화 하여 클러스터에 배포할 수 있습니다

CASE 2. 하이브리드/멀티 클라우드

서비스 애플리케이션에게 있어서 프라이빗과 퍼블릭 클라우드에 걸친 하이브리드 클라우드나 다양한 퍼블릭 클라우드로 구성된 멀티 클라우드 환경에 대한 배포는 필수가 되어가고 있습니다.

이미 많은 기업에서 중장기적으로 클라우드 활용을 확대하기 위한 전략을 수립하고 있습니다. 특히, 예측할 수 없는 트래픽 증가와 서비스 변경에 유연하게 대처할 수 있는 퍼블릭 클라우드 활용을 강화함으로써 기업의 IT 투자 및 운용비용을 절감하려는 시도를 하고 있습니다. 

중요 업무를 퍼블릭 클라우드로 이전하는 것에 대한 불안함이 존재하고, 퍼블릭 클라우드에서 제공되는 기능들이 기업의 요구사항에 부합하지 않을 수 있기 때문에 모든 비즈니스 프로세스를 퍼블릭 클라우드로 옮기는 것에는 부정적입니다. 그럼에도 불구하고 클라우드에서 제공하는 IT 인프라 운영의 편리함과 효율성이 훨씬 크기 때문에 이를 비즈니스 프로세스에 단계적으로 적용해가고 있습니다.

보안 위협 및 중단에 대비하여 온프레미스 기반의 비즈니스 프로세스를 일부는 퍼블릭 클라우드에서, 또 다른 일부는 자체적으로 구축한 프라이빗 클라우드로 병행하여 실행할 수 있습니다.

또한 퍼블릭 클라우드의 유연함을 최대한 활용하면서도, 하나의 클라우드에 락인(lock-in)되는 위험 요소를 최소화하기 위해서는 다수의 퍼블릭 클라우드 도입을 고려할 수도 있습니다.

이렇듯 다양한 클라우드를 운용하게 되면서 유연성 및 이식성 문제를 함께 고민할 수 밖에 없게 되었습니다.

하이브리드 클라우드는 퍼블릭 클라우드와 프라이빗 클라우드에 대해 다른 유형의 배포가 이루어지고 이들 사이에 통합이나 오케스트레이션이 특정 방식으로 이루어지는 반면,

멀티 클라우드는 2곳 이상의 클라우드 벤더가 제공하는 2개 이상의 퍼블릭 또는 프라이빗 클라우드로 구성된 클라우드 접근 방식입니다.

기존의 방식에 따르면 가상 머신(VM)과 해당 이미지를 각 클라우드에 맞춰 이전하고 빌드하여 애플리케이션을 포팅 해야 합니다. 컨테이너를 사용하게 되면 공통된 표준 이미지를 플랫폼에 상관없이 적용을 할 수 있으며, 컨테이너를 통해 애플리케이션을 패키징하여 앱 생성, 배포 및 확장, 모니터링, 로깅 등의 구현을 단순화 할 수 있습니다.

또한 하이브리드/멀티 클라우드를 운영하기 위해서는 네트워크, 보안, 스토리지, 관리 및 모니터링 등 다양한 고려사항이 존재하며 이를 일관되게 관리해야 하는데 쿠버네티스를 사용하게 되면 애플리케이션 배포 및 관리가 컴퓨팅 환경 전반에서 일관성이 있어 각 클라우드의 환경 설정을 일원화 할 수 있는 장점도 있습니다.

하지만 쿠버네티스는 사용하기 복잡하고 어렵기 때문에, 아코디언과 같이 대시보드를 통해 쉽게 관리할 수 있는 컨테이너 통합 관리 솔루션을 이용하면 다양한 클라우드 환경에서도 애플리케이션을 편리하게 운영할 수 있습니다.

예를 들어 보겠습니다.

온프레미스 기반에서 가상화 기반으로 워크로드를 이전하였고, 이벤트에 따라 트랜잭션 변동이 매우 심한 대외서비스를 컨테이너화하여 퍼블릭 클라우드에 배포하여 운영하고 있습니다.

시간이 지남에 따라 서비스 규모가 커지게 되면서 재해 복구를 고려해야 하고, 개인정보에 따른 보안 문제로 고객의 데이터 분리가 필요해졌습니다.

그에 따라 대외 서비스의 아키텍처를 변경하여 접근제어 및 보안과 고객 데이터 저장 모듈은 프라이빗 클라우드로, 그 외 나머지는 퍼블릭 클라우드로 구성하기로 하였습니다.

하지만 하이브리드/멀티 클라우드를 구성하는 것은 그리 간단하지 않습니다. 프라이빗, 퍼블릭 컴퓨팅, 네트워크 등 인프라의 차이로 성능이 달라질 수 있으며, 클라우드의 환경마다 정의되지 않는 미묘한 차이로 인하여 구성의 제약사항이 발생할 수 있습니다.

컨테이너 통합 관리 솔루션 ‘아코디언’의 클라우드 매니저는 클러스터 등록 및 모니터링, 클러스터 파이프라인 관리, 도커 레지스트리 관리, 퍼블릭 클라우드 관리, Helm Chart 지원 등 다양한 기능을 제공하여, 멀티 클라우드 환경에 내재된 복잡성을 해결함과 동시에 사용자에게 단순함을 제공합니다.

이를 통해 비용과 위험을 최소화 할 수 있는 하이브리드/멀티 클라우드를 손쉽게 구축 및 운영 할 수 있어 컨테이너 오케스트레이션을 향상시킬 수 있습니다.

CASE 3. 마이크로 서비스 아키텍처 (MSA)

마이크로 서비스는 복잡한 응용 프로그램을 설계하기 위한 아키텍처로 애플리케이션을 독립적인 요소로 분해하여 서비스를 제공합니다.

모든 요소를 하나의 애플리케이션에 구축하는 모놀리식 아키텍처와 달리 마이크로 서비스는 하나의 애플리케이션을 구성하면서 분할된 다수의 서버 또는 컨테이너를 통해 애플리케이션 기능뿐만 아니라 데이터까지 분리하여 격리된 독립 환경으로 구성합니다.

마이크로 서비스 아키텍처는 통상 MSA라고 부르는데, 개발 주기의 단축, 쉬운 배포와 복구, 높은 확장성과 개방성 때문에 클라우드 네이티브 아키텍처에서 반드시 필요한 기술로 언급됩니다.

마이크로 서비스가 구현되는 방식은 현대적이고 클라우드에 기반한 애플리케이션을 위한 자연스러운 토대를 만듭니다. 마이크로 서비스 아키텍처를 설계하면서 중요한 것은 기술적으로 아키텍처를 잘 설계하는 것도 있겠지만 서비스를 개발하는 팀의 구조를 아키텍처에 맞는 구조로 잘 만드는 것입니다.

여기에서 우리는 이미 클라우드 네이티브 아키텍처의 중요 요소로 언급했던 DevOps를 떠올리게 됩니다. 팀이 개발과 운영을 모두 담당함으로써 개발된 시스템을 빠르게 배포하고 운영 노하우를 반영하여 시장의 요구 사항에 빠르게 대응합니다.

이렇게 개발된 시스템을 직접 배포하고 운영하는 플랫폼을 지원하기 위해서는 벤더에 종속적이지 않고, 개발자가 쉽게 운영할 수 있는 인프라 관리 기술이 필요합니다.

여기서 등장하는 기술이 바로 도커 컨테이너 입니다.

확장성과 표준성을 특징으로 하는 도커는 마이크로 서비스의 유연하고 탄력적인 배포에 매우 적합합니다. 게스트 운영체제가 설치되지 않고, 프로세스 레벨의 분리가 가능한 컨테이너를 사용하는 경량화된 가상화 방식인 도커를 사용하는 것이 MSA를 구성하는데 장점으로 작용합니다.

하지만 MSA 도입은 단점도 존재합니다.

MSA는 모든 기능적 특성이 개별 서비스로 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있습니다. 컨테이너 통합관리 솔루션 ‘아코디언’을 이용하면 MAS도입에 따른 부작용을 최소화하면서 단점을 보완할 수 있는데, 이를 하나씩 살펴보도록 하겠습니다.

첫째, 하나의 커다란 서비스를 독립적인 운영 및 배포가 가능한 작은 서비스로 잘게 나누었기 때문에 쪼개진 서비스의 배포, 운영, 모니터링에 대한 관리 포인트가 증가합니다. 아코디언은 도커 컨테이너 오케스트레이션 툴인 쿠버네티스를 기반으로 설계되었기 때문에 쿠버네티스에서 제공하는 운영, 배포, 모니터링 기능뿐 아니라 마이크로 서비스 간의 전체 연결 구조를 파악하여 분배하고, 장애 대응 및 추적을 위한 ‘서비스 매쉬’를 제공합니다.

둘째, 클라이언트와 서비스 사이에 위치하는 API 게이트웨이를 구축해야 합니다. MSA환경에서는 필연적으로 다수의 마이크로서비스 End Point가 생기기 때문에 이를 단일화 하고 클라이언트로부터의 요청을 적절한 마이크로서비스로 라우팅해 주는 API 게이트웨이가 필요합니다. 아코디언은 자체적으로 제공하는 API Gateway뿐만 아니라, Nginx API Gateway 도 제공합니다. 신속한 다중 API 정의 및 구성, 사전 보안기능, 인스턴스 별 모니터링 등 효과적으로 통합된API관리를 할 수 있습니다.

셋째, 마이크로서비스는 개수가 많고 유동적이기 때문에 CI/CD가 체계적으로 구축이 되어야 합니다. 또한 서비스 간 복잡한 의존성이 있다면 빌드 및 배포에 확인 절차가 포함되어 까다로울 수 있습니다. 아코디언은 CI/CD를 위해 Jenkins를 활용하여 빌드, 컨테이너 이미지 생성, 배포를 자동으로 실행해 줍니다. 또한 사용자 파이프라인을 활용하여 맞춤형 빌드 및 배포를 제공합니다.

소프트웨어 개발 방법론이 시시각각 변화하는 가운데, 컨테이너 통합 관리 솔루션인 아코디언을 활용하여 모놀리스 아키텍처로 시작한 시스템을 마이크로 서비스로 손쉽게 전환하시기 바랍니다.

컨테이너 통합 관리 솔루션 Use Case는 2편으로 이어집니다.

Back To Top