Docker, K8S 같은 Container 기반 아키텍처의 장점

https://kubernetes.io/docs/concepts/overview/#going-back-in-time

Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

위에 잘 나와 있는데, 일부 특히 중요해 보이는 부분 발췌

1. 개발, 테스트 및 프로덕션 전반에 걸친 환경 일관성

• 클라우드에서와 마찬가지로 노트북에서도 동일하게 실행된다.
• 애플리케이션 구동에 필요한 모든 것이 컨테이너로 패키징 되기 때문에, OS level나 java 같은 애플리케이션 외부 실행 환경에 구애받지 않을 수 있다. 이는 개발 장비가 바뀌거나 서버를 새로 세팅 해야 하는 경우 아주 유용하다.

2. 리소스 격리, elastic auto scale

• 하나의 PM 서버에 애플리케이션 여러개를 띄워 실행하는 경우, 한 애플리케이션이 서버 자원 대부분을 소모해 버릴 수 있다.
  • memory limit 정도는 지원하는 애플리케이션이 있지만, 이마저도 안되는 케이스도 많고, CPU 자원 분배 설정은 애플리케이션 단에서는 불가능하다 봐야한다. (잘 지원 해봐야 thread 수 제어 수준)
• 그렇다고 이런 문제를 방지하기 위해서 1 애플리케이션 1 PM 으로 구성하게 되면
  • 한 애플리케이션의 트래픽 급증이 다른 애플리케이션 까지 영향을 주는 것은 해결했지만
  • 트래픽 급증이 예상되는 애플리케이션을 띄울 PM은, 넉넉한 스펙으로 구성해야 한다. = 비용 문제 발생
  • 또한, 그렇게 구성한 PM이 정말로 넉넉한 스펙일지에 대한 불확실성도 존재한다. (넉넉하게 구성 할 수록, 비용 낭비가 된다)
• 이런 문제는 컨테이너 기반의 auto scale로 해결 할 수 있다. => 리소스 격리로 장애 격리 & 비용 절감 & burst 트래픽 수용
• 또한, 하나의 장비에 상호 간섭 없이 여러 컨테이너를 띄울 수 있다는 점에서, 애플리케이션을 작게 쪼개는 부담이 적어진다. => MSA에 적합

[!info] auto scale이 만능은 아니다. pod가 준비되는 몇 분 사이 트래픽이 싹 빠져버리는 경우도 종종 경험한다.
이 때는 동시성을 개선하거나, 자원을 좀 더 쓰더라도 평시 pod 수를 늘려야 한다.