도커 컨테이너 쓰는이유

환경 일관성: 도커 컨테이너는 애플리케이션과 그에 따른 모든 종속성을 패키지로 묶습니다. 이로 인해 개발, 테스트, 프로덕션 환경 간에 일관성을 유지할 수 있습니다. 이는 "내 컴퓨터에서는 잘 돌아갔는데..."라는 문제를 방지하는 데 도움이 됩니다.

포트 이용성: 컨테이너는 서로 격리되어 있으며, 각각의 컨테이너는 호스트의 OS와 상호작용하기 위해 특정 포트를 사용합니다. 이것은 다른 버전의 동일한 애플리케이션을 동시에 실행하는 등의 유연성을 제공합니다.

빠른 배포와 스케일링: 컨테이너는 빠르게 시작되고 종료되며, 필요에 따라 손쉽게 수평 확장 및 축소가 가능합니다. 이는 빠르고 유연한 배포 및 스케일링을 가능하게 합니다.

경량성: 컨테이너는 자체 OS를 가지고 있지 않으며, 호스트 OS의 커널을 공유하기 때문에 메모리와 스토리지 사용량이 더 적습니다. 이로 인해 동일한 하드웨어에서 더 많은 컨테이너를 실행할 수 있습니다.

마이크로서비스 아키텍처: 도커는 서비스를 독립적으로 배포하고 관리하는 마이크로서비스 아키텍처를 지원합니다. 이는 개발과 운영에 있어서 큰 유연성을 제공하며, 대규모 애플리케이션의 복잡성을 관리하는 데 도움이 됩니다.

CI/CD 통합: 도커는 Jenkins, Travis CI 등과 같은 CI/CD 툴과 잘 통합되어, 애플리케이션의 빌드, 테스트, 배포 파이프라인을 자동화하는데 도움을 줍니다.

===========================================================================================================================

도커 컨테이너 관리 서비스 사용 

도커 컨테이너를 관리하는 서비스는 도커 컨테이너의 실행, 배포, 스케일링 등을 간소화하고 자동화하기 위해 사용됩니다. 이러한 서비스의 예로는 쿠버네티스(Kubernetes), Docker Swarm, Amazon ECS(Amazon Elastic Container Service), Google GKE(Google Kubernetes Engine) 등이 있습니다.

도커 컨테이너 관리 서비스를 사용하는 주요 이유는 다음과 같습니다:

자동 스케일링: 컨테이너 관리 서비스는 트래픽이 증가하거나 감소할 때 컨테이너를 자동으로 스케일링할 수 있습니다. 이를 통해 리소스 사용을 최적화하고, 트래픽에 따라 신속하게 응답할 수 있습니다.

높은 가용성: 컨테이너 관리 서비스는 컨테이너의 상태를 모니터링하고, 문제가 발생하면 자동으로 복구합니다. 이는 시스템의 가용성을 높이고, 서비스 중단 시간을 최소화합니다.

배포 및 롤백 용이성: 컨테이너 관리 서비스는 새로운 버전의 애플리케이션을 배포하거나 이전 버전으로 롤백하는 것을 용이하게 합니다. 이를 통해 지속적인 통합 및 지속적인 배포(CI/CD)를 지원합니다.

리소스 최적화: 컨테이너 관리 서비스는 서버 클러스터의 리소스를 최적화하여 사용합니다. 이는 각 컨테이너가 필요로 하는 CPU, 메모리 등의 리소스를 미리 정의하고, 이러한 요구 사항에 따라 컨테이너를 적절한 서버에 스케줄링함으로써 이루어집니다.

서비스 검색 및 로드 밸런싱: 컨테이너 관리 서비스는 서비스 검색과 로드 밸런싱 기능을 제공하여, 클라이언트의 요청을 여러 컨테이너에 분산시킵니다. 이는 시스템의 로드를 균등하게 분산시키고, 높은 트래픽을 처리하는 데 도움이 됩니다.

따라서, 도커 컨테이너 관리 서비스는 도커 컨테이너의 운영을 단순화하고, 대규모 컨테이너화된 애플리케이션의 운영을 가능하게 합니다.

오토스케일링 설명

EC2 오토스케일링:

• EC2 오토스케일링은 AWS에서 제공하는 기능으로, EC2 인스턴스의 그룹(인스턴스 풀)을 대상으로 작동합니다.
• 특정 트리거(예: CPU 사용률, 네트워크 I/O 등)에 응답하여 EC2 인스턴스의 수를 자동으로 늘리거나 줄입니다. 이는 "수평 스케일링"이라고도 합니다.
• EC2 오토스케일링을 사용하면 애플리케이션의 로드에 따라 자동으로 서버의 수를 조절할 수 있어서, 서버의 유휴 상태를 최소화하고 필요한 시점에서 최적의 성능을 제공합니다.

도커(컨테이너) 오토스케일링:

• 도커나 컨테이너 오토스케일링은 컨테이너화된 애플리케이션을 대상으로 합니다.
• 쿠버네티스 같은 컨테이너 오케스트레이션 플랫폼에서 제공하는 기능으로, 특정 조건에 따라 컨테이너의 수를 자동으로 조절합니다.
• 이는 각각의 컨테이너가 독립적으로 실행되는 마이크로서비스 구조에서 특히 유용합니다. 예를 들어, 하나의 서비스에 대한 요청이 증가하면 해당 서비스의 컨테이너만 추가로 배포할 수 있습니다.

따라서, 이 두 가지 스케일링 전략은 다른 레벨에서 작동하며 서로 보완적으로 사용될 수 있습니다. 예를 들어, 컨테이너 수를 늘리기 위한 스케일링이 필요하면 컨테이너 오토스케일링을 사용하고, 더 많은 컴퓨팅 리소스가 필요하다면 EC2 오토스케일링을 사용할 수 있습니다.

ecs , k8s 가 꼭 필요할까?̊̈ (고려해볼사항)

1. 컨테이너의 규모와 복잡성: 당신의 애플리케이션이 복잡하고 다수의 컨테이너로 구성되어 있다면, ECS나 Kubernetes를 사용하여 컨테이너를 관리하고 조율하는 것이 좋습니다. 이런 플랫폼들은 컨테이너 배포, 스케일링, 네트워킹, 서비스 검색 등의 작업을 자동화해줍니다.
2. 자동 복구 및 로드 밸런싱 필요성: 컨테이너가 실패하거나 서비스가 중단되는 경우 자동으로 복구할 필요가 있거나, 트래픽을 여러 컨테이너에 자동으로 분산시키고 싶다면 이러한 플랫폼들이 유용합니다.
3. 확장성: 애플리케이션이 빠르게 성장하고 있거나, 트래픽 패턴이 불규칙하다면 컨테이너의 수를 자동으로 늘리거나 줄일 수 있는 자동 스케일링 기능이 필요할 수 있습니다. ECS와 Kubernetes는 이러한 오토스케일링 기능을 제공합니다.
4. 마이크로서비스 아키텍처: 당신의 애플리케이션이 마이크로서비스 아키텍처로 설계되었다면, 각 서비스를 별도의 컨테이너로 패키징하고 이들을 독립적으로 배포하고 스케일링하는 것이 유리합니다. 이 경우, 컨테이너 오케스트레이션 플랫폼이 매우 유용합니다.

하지만, 애플리케이션 규모가 작거나 간단하고 별도의 스케일링이나 복잡한 관리 기능이 필요하지 않다면, 이러한 플랫폼 없이도 충분히 관리가 가능합니다. 또한, 이러한 플랫폼들을 사용하려면 추가적인 학습과 운영 비용이 들 수 있으므로, 이러한 투자가 가치가 있다고 판단되는 경우에만 사용하는 것이 좋습니다.