컨테이너 이전 기술들

컨테이너에 대해 알아보기 전에 우리는 컨테이너 이전에 어떤 시스템을 사용하였고, 그 시스템에 문제점이 있었는지에 대해 알아볼 필요가 있습니다. 컨테이너의 목적도 모른 채 '그런가 보다'하는 것은 적절하지 않고, 이유와 목적을 뚜렷하게 알고 있으면 좀 더 생산적인 업무 효율로 반증될 테니 말이죠.

• monolithic virtual machine
  
  이전에 대부분의 소프트웨어 어플리케이션들은 하나의 프로세스 또는 몇 개의 서버에 분산된 프로세스로 실행되는 거대한 모놀리스(monolith)였습니다. 이 중 모놀리스틱 가상 장치는 전체 운영 체제가 가상화되어 물리적 호스트 장치에서 단일, 독립적인 인스턴스로 실행되는 방식을 말합니다.
  
  하나의 통합된 단위로 구축되어 다른 어플리케이션으로부터 독립적입니다. 이 방식은 전체 운영 체제, 미들 웨어 및 애플리케이션을 포함하며 여러 애플리케이션들을 한 번에 실행하거나 애플리케이션 간 격리, 레거시 애플리케이션 지원에 가장 적합합니다.
  
  하지만 이 장치는 리소스 비효율성, 한계적인 확장성, 제한된 유연성, 장애 발생 위험 증가 및 복잡성 증가와 같은 단점이 있습니다. 각 모놀리식 가상 머신은 전용 리소스 세트가 필요하기 때문에 수요 변화에 신속하게 대응하기 어렵고 하드웨어에 상당한 투자가 필요할 수 있습니다.
  
  또한, 모놀리식 가상 머신은 다른 가상화 유형보다 관리하기 복잡할 수 있으며, 각 가상 머신에는 운영 체제, 미들웨어 및 어플리케이션이 포함되어 있어 문제 해결이 어려울 수 있으며 더 많은 전문 기술과 전문 지식이 필요할 수 있습니다. 이러한 단점들은 점차 마이크로 서비스라는 독립적으로 실행되는 더 작은 구성 요소로 세분화되기 시작했습니다.
• microservice
  
  마이크로서비스(microservice)는 단일 어플리케이션을 여러 개의 작은 컴포넌트 혹은 서비스들로 이루어진, 느슨하게 결합되고 독립적으로 배포 가능한 클라우드 기반의 아키텍처 접근법입니다. 각각의 서비스들은 자체적으로 기술 스택과 데이터베이스와 데이터 관리 모델을 가지고 있으며, 비즈니스 기능을 구현합니다.
  
  이러한 마이크로서비스 아키텍처는 대규모, 복잡한 어플리케이션의 지속적인 배포 및 전달을 용이하게 하며 기술 스택 업데이트에도 적합합니다. 각각의 마이크로서비스들은 더 작은 단위로 개발되고, 독립적으로 배포될 수 있어 개발자들이 일부분만 수정하고 배포할 수 있습니다.
  
  이는 개발 효율성을 높이고, 유지보수를 용이하게 합니다. 마이크로서비스는 SOA(Service Oriented Architecture)와 비슷한 개념이지만, SOA가 다수의 웹 서비스를 묶어 하나의 애플리케이션으로 제공하는 것과 달리, 마이크로서비스는 하나의 애플리케이션을 여러 개의 서비스로 나누어 독립적으로 제공합니다. 또한, 마이크로서비스는 기존의 단일 애플리케이션 모놀리스(monolith)와 비교하여 기술 다양성, 오류 격리 등 다양한 장점을 가지고 있습니다.
  
  하지만 이런 마이크로서비스도 여러 단점들이 있습니다.
  1. 작업 구성이 복잡하며, 자동 배포가 필요합니다.
  2. 어플리케이션을 한 부분만 변경하더라도 전체 애플리케이션을 재배포해야 합니다.
  3. 컨텍스트 경계를 넘나드는 번역이 필요합니다.
  4. 분산 시스템과 관련된 모든 복잡성이 있으며, 서로 다른 서비스 간 통신 중 실패할 가능성이 높습니다.
  5. 대규모 서비스를 관리하기 어렵습니다.
  6. 개발자가 직접 네트워크 지연 및 부하 분산과 같은 문제를 해결해야 합니다.
• DevOps
  
  해당 포스팅에서는 데브 옵스를 간단하게 다루지만 기회가 된다면 더 자세히 다루도록 하겠습니다. 위와 같은 문제를 해결하기 위해 전체 애플리케이션 개발 프로세스와 프로덕션 환경에서 관리 방식이 점차 변경되었는데, 이전에 개발팀에서 애플리케이션을 배포하여 운영 팀에 넘겨주는 것 이었으나, 점차 개발 팀 자체적으로 배포하고 관리하는게 더 효율적이라는 것을 깨달았습니다. 즉, 개발자, QA, 운영 팀이 전체 프로세스에서 협업이 진행되어야 한다는 뜻이고, 이러한 방식을 DevOps라고 합니다.
  
  데브 옵스는 운영, 개발이 같이 이루어지면서 다음과 같은 장점을 갖게 되었습니다.
  1. 개발자가 프로덕션 환경에서 어플리케이션 실행에 더 많은 관여를 하게 되면서 사용자가 무엇을 필요로 하고 어떤 문제가 있는지 더 잘 이해할 수 있고, 빠른 피드백으로 고객 만족도를 높일 수 있습니다.
  2. 최신 버전 어플리케이션을 자주 릴리스하려면 배포 프로세스를 간소화해야 하는데, 팀이 나누어져 있을 때 보다 더 빠르게 의견을 주고받으며, 빠른 릴리스를 가능하게 합니다.
• NoOps
  
  데브 옵스에서 개발자들이 배포를 하기 위해서는 하드웨어 인프라를 알고 있어야 했지만, 많은 개발자들은 알고 싶어 하지 않았다고 합니다. 때문에 하드웨어 인프라를 알지 못해도 개발자가 운영팀을 거치지 않고 애플리케이션을 배포하기 위한 방식을 선택한 것이 바로 NoOps입니다.
  
  이러한 특징 덕분에 개발자는 애플리케이션 개발에 더 집중할 수 있으며, 더욱 신속한 배포 프로세스를 구성할 수 있습니다. 누군가가 하드웨어를 관리할 필요는 있지만, 이상적으로는 그 위에서 실행되는 각 애플리케이션의 특성을 다루지 않아도 됩니다.
  
  이러한 것들을 바람과 문제 해결을 하기 위해 쿠버네티스를 개발 및 활용되게 되었고 여기에서 사용되는 기술이 바로 컨테이너 기술입니다.