[Container 이론] 6. 파드를 구성하기 위해 생각해봐야 할 것들

목차

1. 여러 특정 애플리케이셔을 하나의 파드안에 넣어도 될까?
2. 문제점 예시
3. 개별 확장이 가능하도록 파드를 분할하자.
4. 파드에서 여러 컨테이너를 사용하는 경우

---

1. 여러 특정 애플리케이셔을 하나의 파드안에 넣어도 될까?
   
   파드를 각각 별도의 머신으로 생각할 수도 있을 것 같습니다. 하지만, 파드는 특정한 애플리케이션만을 호스팅합니다. 즉, 한 호스트에 모든 유형의 애플리케이션을 넣었던 이전과 달리, 파드는 그렇게 사용하지 않는다는 뜻입니다. 파드는 상대적으로 가볍기 때문에 오버헤드 없이 필요한 만큼 파드들을 가질 수 있습니다. 모든 것을 파드 하나에 넣는 대신 애플리케이션을 여러 파드로 구성하고, 각 파드에는 밀접하게 관련있는 구성 요소나 프로세스만 포함해야 합니다.
   
   그렇다면 프론트엔드 애플리케이션 서버와 백엔드 데이터베이스로 구성된 다중 레이어 애플리케이션을 구성할 때 단일 파드 또는 두개의 파드로 구성해야만 할까요?
   
   이전에 다루었던 것과 마찬가지로 하나의 파드에는 하나의 컨테이너를 동작시키는 것을 권장했었는데요. 일반적으로 프런트엔드 애플리케이션 서버와 백엔드 데이터베이스도 마찬가지로 두 개의 별도 포드로 분리하는 것이 좋은데, 리소스 요구 사항과 확장 요구 사항이 다르기 때문입니다.
   
   프런트엔드 애플리케이션 서버는 사용자 요청을 처리하고 애플리케이션 로직을 실행하기 위해 더 많은 CPU 및 메모리 리소스가 필요할 수 있는 반면, 백엔드 데이터베이스는 데이터를 관리하기 위해 더 많은 스토리지 및 디스크 I/O 리소스가 필요할 수 있습니다. 또한 증가된 트래픽을 처리하기 위해 프런트엔드 애플리케이션 서버를 수평으로 확장해야 할 수 있는 반면 백엔드 데이터베이스는 증가한 데이터 볼륨을 처리하기 위해 수직으로 확장해야 할 수 있습니다.
   
   프런트엔드와 백엔드를 두 개의 별도 포드로 분리하면 내결함성과 안정성이 향상됩니다. Pod 중 하나에 오류가 발생하면 다른 포드가 중단 없이 계속 작동하여 전체 애플리케이션에 대한 오류의 영향을 줄일 수 있습니다.
   
   
2. 문제점 예시
   
   실제로 프론트엔드 서버와 데이터베이스 컨테이너 두 개로 구성된 단일 파드를 실행하지 못하는 것은 아닙니다. 하지만 프론트엔드와 백엔드가 같은 파드에 있다면, 둘은 항상 같은 노드에서 실행될 것 입니다. 만약에 두 노드를 가진 쿠버네티스 클러스터가 있고 이 파드 하나만 있다면, 워커 노드 하나만 사용하고 두 번째 노드에서 이용할 수 있는 컴퓨팅 소스(GPU, 메모리)를 활용하지 않고 그냥 버리게 됩니다. 파드를 두 개로 분리한다면 쿠버네티스가 프론트엔드를 한 노드로 그리고 백엔드는 다른 노드에 스케줄링해 인프라스트럭처의 활용도를 향상시킬 수 있습니다.
   
   
3. 개별 확장이 가능하도록 파드를 분할하자.
   
   두 컨테이너를 하나의 파드에 넣지 말아야 하는 또 다른 이유는 스케일링 때문입니다. 파드는 스케일링의 기본 단위인데, 쿠버네티스는 개별 컨테이너를 수평으로 확장할 수 없습니다. 대신 전체 파드를 수평으로 확장합니다. 만약 프론트엔드와 백엔드 컨테이너로 구성된 파드를 두 개로 늘리면, 결국 프론트엔드 컨테이너 두 개와 백엔드 컨테이너 두 개를 갖습니다.
   
   위에서 설명한 것 처럼 일반적으로 프론트엔드 구성 요소는 백엔드와 완전히 다른 스케일링 요구 사항을 갖고 있어 개별적으로 확장하는 경향이 있습니다. 데이터 베이스와 같은 벡엔드는 (상태를 갖지 않는) 프론트엔드 웹 서버에 비해 확장하기가 훨씬 어렵습니다. 컨테이너를 개별적으로 스케일링하는 것이 필요하다면, 별도 파드에 배포해야 합니다.
   
   
4. 파드에서 여러 컨테이너를 사용하는 경우
   
   보통 하나의 파드에 여러 컨테이너가 들어간다면 그것은 밀접하게 관련되어 있으며, 일반적으로 주 컨테이너와 보조 컨테이너로 이루어 집니다. 이러한 방법은 다양한 시나리오에서 유용할 수 있지만 각 컨테이너의 책임과 리소스 요구 사항을 신중하게 고려해야 합니다.
   
   
   1. 사이드카 패턴
      Pod 내의 여러 컨테이너에 대한 일반적인 사용 사례는 기본 컨테이너가 기본 애플리케이션 로직을 실행하고 사이드카로 알려진 보조 컨테이너가 지원 서비스를 실행하는 사이드카 패턴입니다. 예를 들어 캐싱 및 연결 관리를 처리하는 사이드카 컨테이너를 통해 Redis 데이터베이스와 통신하는 웹 애플리케이션 컨테이너가 있을 수 있습니다.
      
      
   2. 다중 컨테이너 애플리케이션
      Pod 내 다중 컨테이너의 또 다른 사용 사례는 함께 실행해야 하는 여러 구성 요소로 구성된 복잡한 애플리케이션이 있는 경우입니다. 예를 들어 각 마이크로서비스가 단일 Pod 내의 자체 컨테이너에서 실행되는 마이크로서비스 기반 애플리케이션이 있을 수 있습니다.
      
      
   3. 로깅 및 모니터링
      Pod 내의 여러 컨테이너에 대한 또 다른 일반적인 사용 사례는 로깅 및 모니터링입니다. 기본 애플리케이션 논리를 실행하는 기본 컨테이너와 로그 및 메트릭을 수집하여 중앙 모니터링 시스템으로 보내는 보조 컨테이너가 있을 수 있습니다.
      
      
   4. 도우미 컨테이너
      데이터 백업, 구성 관리 또는 주기적인 데이터 처리와 같은 도우미 작업을 위해 Pod 내에서 여러 컨테이너를 사용할 수도 있습니다.
      
      
   5. 주요 컨테이너에 보완 프로세스 추가
      파드 안에 주 컨테이너는 특정 디렉터리에서 파일을 제공하는 웹 서버일 수 있으며, 추가 컨테이너는 외부 소스에서 주기적으로 콘텐츠를 받아 웹 서버의 디렉터리에 저장합니다. 두 컨테이너를 모두에 마운트하는 방법이 있는데, 이에 대해서는 차후에 다뤄보도록 하겠습니다.
      
      * 사이드카 컨테이너가 실제 사용 되는 예를 들어보자면, 로그 로테이터와 수집기, 데이터 프로세서, 통신 어댑터 등이 있습니다.
      
      
5. 파드에서 여러 컨테이너를 사용하는 경우 고려해볼 사항
   
   컨테이너를 파드로 묶어 그룹으로 만들 떄는, 즉 두 개의 컨테이너를 단일 파드로 넣을지 아니면 두 개의 별도 파드에 넣을지를 결정하기 위해서는 다음과 같은 질문에 대해 생각해봐야 할 필요가 있습니다.
   
   
   1. 컨테이너를 함께 실행해야 하는가, 혹은 서로 다른 호스트에서 실행할 수 있는가?
   2. 여러 컨테이너가 모여 하나의 구성 요소를 나타내는가, 혹은 개별적인 구성 요소인가?
   3. 컨테이너가 함께, 혹은 개별적으로 스케일링돼야 하는가?

기본적으로 특정한 이유 때문에 컨테이너를 단일 파드로 구성하는 것을 요구하지 않는다면, 분리된 파드에서 컨테이너를 실행하는 것이 좋습니다.

---

이번 포스팅은 구분선이 존재하지 않아 글을 읽는데 어려움을 느끼셨을지도 모르겠습니다. 아직 시작한지 얼마 되지 않아 다양한 시도를하고 있고, 해당 내용은 한 가지 내용에 대해 여러 측면을 설명하다 보니 이런 형식을 띄게 되었습니다. 피드백, 욕설, 칭찬 모두 환영합니다. 어떤 의견이든 댓글로 남겨주시면 그에 대해 조사하거나, 조취를 취해보겠습니다. 오늘도 읽어주셔서 감사합니다!