사용자 증가 등으로 인해 서버를 늘려야 한다면 스케일 업과 스케일 아웃으로 해결할 수 있다

1. 성능 유지

• 서버는 동시에 처리할 수 있는 요청의 수에 한계가 있음
• 사용자 수 증가 => 동시 요청 수 증가 => 서버의 처리 능력을 초과할 수 있음
• 서버를 늘려서 늘어난 요청을 효과적으로 분산 => 시스템의 응답 시간 개선 & 사용자 경험 유지

2. 가용성 향상

• 단일 서버에 문제가 발생하면 전체 서비스에 영향을 미칠 수 있음
• 서버를 여러 대 운영하면 하나의 서버에 문제가 생겨도 다른 서버가 처리를 계속 수행할 수 있음 => 서비스의 중단 시간 줄임 => 고가용성 보장

가용성: 서버 또는 네트워크 시스템이 게획된 운영 시간 동안 얼마나 안정적으로 접근 가능하고, 정상적으로 가능한지 나타내는 지표

• 시스템이 사용자의 요구를 충족시키며 요청된 서비스를 제공할 수 있는 능력 의미
• 주요 오소: 연속성과 신뢰성 (지속적으로 작동, 다운타임 최소화), 복구력 (장애 후 얼마나 빠르게 복구되는지), 확장성 (사용자 수나 데이터량 증가를 수용하는지)

가용성을 높이는 방법

1. 하드웨어 중복: 중요한 서버 및 네트워크 구성요소 복제 => 하나가 실패해도 다른 하나가 기능 지속
2. 로드 밸런싱: 트래픽 분산
3. 장애 조치: 서버가 실패할 경우 자동으로 백업 시스템으로 전환
4. 정기적인 백업 및 복구 테스트: 데이터를 정기적으로 백업 & 장애 발생시 복구 프로세스가 효과적으로 작동하는지 주기적으로 테스트
5. 분산 아키텍쳐: 지리적으로 분산된 데이터 센터를 사용하여 자연 재해나 지역적 장애의 영향을 최소화

Scale up & Scale out

• Scale out: 수평 확장 방식을 더 많이 사용하는 이

1. 유연성과 확장성

• 스케일 아웃은 서버나 리소스를 추가하거나 제거하는데 유연함
• 서버 추가 배치

2. 비용 효율성

• 추가적인 고성능 서버를 구매하는 것보다 비용 효율적

3. 고가용성

• 여러 노드에서 애플리케이션을 운영 => 하나가 실패해도 시스템 전체에는 큰 영향 없음

4. 부하 분산

• 수평 확장을 통해 트래픽이나 작업 부하를 여러 서버에 분산
• 단일 서버에 과부하 방지

5. 기술 발전과 클라우드 컴퓨팅

• 클라우드 서비스 제공자들은 사용자가 손쉽게 리소스를 추가하거나 줄일 수 있는 유연한 서비스 제공

도커 오케스트레이션

도커 오케스트레이션의 중요성

1. 자동화된 관리
   • 도커 오케스트레이션 도구는 컨테이너의 배포, 관리 및 확장을 자동화
   • 수동 작업의 필요성 줄여줌
   • 시간 및 리로스 절약
2. 확장성
   • 오케스트레이션 도구로 컨테이너 스케일아웃 용이
   • 트래픽 증가 시 컨테이너 수 늘릴 수 있음
3. 부하 분산
   • 여러 컨테이너와 서버에 걸쳐 트래픽과 부하 자동 분산
4. 서비스 발견과 네트워킹
   • 오케스트레이션 도구는 컨테이너 간의 네트워킹과 서비스 발견 관리
   • 각 컨테이너가 필요한 리소스와 서비스를 찾아서 소통할 수 있도록
5. 상태 관리와 자가 치유
   • 시스템이 정의한 상태를 유지하도록 설정 가능
   • 문제 발생시 오케스트레이션 도구가 자동으로 문제 해결 시도

주요 도커 오케스트레이션 도구

• Kubernetes
  • 현재 가장 널리 사용되는 컨테이너 오케스트레이션 플랫폼
  • 컨테이너화된 애플리케이션을 배포, 관리, 확장할 때 수반되는 다수의 수동 프로세스를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼
• Docker Swarm
  • 도커에서 공식적으로 지원하는 오케스트레이션 도구
  • 도커 엔진에 내장되어 있어 설정이 간편
• Apache Mesos
  • 대규모 클러스터 관리에 적합

도커 오케스트레이션 도구는 컨테이너화된 애플리케이션의 운영을 간소화, 자동화, 최적화하는데 중요한 역할을 함

쿠버네티스 (Kubernetes)

• aka K8s
• 컨테이너화된 애플리케이션의 배포, 스케일링 및 관리를 위한 오픈소스 시스템
  • 관리와 발견 용이성을 위해 애플리케이션을 논리적 단위로 나눈다
• 논리적 단위로 그룹화한다
  • 컨테이너들을 효과적으로 관리하고 조정하기 위해 관련 컨테이너들을 하나의 그룹 (Pod, 파드)라는 단위로 묶는다
  • 파드: 쿠버네티스에서 생성 및 관리되는 가장 작은 배포 단위
    • 서로 긴밀하게 협력하는 컨테이너들로 구성됨
    • 배포 가능한 가장 작은 컴퓨팅 단위

파드의 역할과 중요성

• 공유 리소스와 통신
  • 파드 안에 있는 컨테이너들은 같은 네트워크 네임스페이스와 스토리지 공유 가능
  • 컨테이너들 간 통신 용이
  • 필요 데이터 쉽게 접근
• 컨테이너 조정
  • 파드를 사용해 관련된 여러 컨테이너들을 한 그룹으로 관리 가능
  • 배포, 스케일링 및 관리 간소화
  • (예) 하나의 파드에 포함된 컨테이너들은 함께 시작되고 종료됨 & 동일 하드웨어 리소스 공유
• 서비스 디스커버리
  • 파드는 하나의 로지컬 호스트로 취급됨
  • 하나의 IP주소와 포트 범위를 가짐
  • 네트워크를 통한 서비스 발견/라우팅 단순화
• 부하 분산과 자동 복구
  • 쿠버네티스는 파드를 여러 노드에 걸쳐 자동으로 배포 가능
  • 파드가 실패하면 자동으로 북구(재시작) 가능
  • 애플리케이션의 가용성과 내구성 향상

쿠버네티스 구조

1. 마스터 노드

마스터 노드: 쿠버네티스 클러스터의 제어 허브

• 클러스터의 관리 및 조정 담당

컴포넌트:

• API 서버 (kube-apiserver): 클러스터와의 모든 통신을 처리하는 엔드포인트
  • 사용자, 외부 시스템, 클러스터 내부 컴포넌트들이 API 서버를 통해 상호작용
• 컨트롤러 매니저: 다양한 컨트롤러 실행
  • 복제 컨트롤러, 엔드포인트 컨트롤러 등
  • 클러스터의 상태를 원하는 상태로 유지하는데 필요함
• 스케쥴러: 새로 생성된 파드를 적절한 노드에 배치
  • 파드의 요구사항과 노드 리소스 상태 고려
• etcd: 모든 클러스터 데이터를 저장하는 경량 데이터베이스 시스템

2. Worker Node

워커 노드: 실제 애플리케이션 컨테이너가 실행되는 서버

컴포넌트:

• kubelet: 각 노드에서 실행되는 에이전트
  • 마스터 노드의 지시를 받아 컨테이너가 파드 내에서 올바르게 실행되도록 관리
• kube-proxy: 네트워크 프록시 및 로드 밸런서 역할을 하는 컴포넌트
  • 노드의 네트워크 규칙을 관리
  • 연결 및 트래픽 라우팅을 처리
• 컨테이너 런타임: 컨테이너를 실행하기 위한 환경 제공
  • Docker, containerd, CRI-O 등 사용 가능
• 추가적인 구성요소
  • 네트워크: 쿠버네티스는 파드 간 통신을 위해 자체 네트워킹 모델을 제공함
    • 각 파드는 고유한 IP주소를 가짐
    • 파드 간 플랫 네트워크에서 서로 통신할 수 있음
  • 스토리지: 쿠버네티스는 볼륨을 사용하여 데이터 저장
    • 로컬 스토리지, 네트워크 스토리지, 클라우드 제공자의 스토리지 서비스 등

클러스터

쿠버네티스에서 노드는 파드를 실행하는 물리적/가성 서버

파드는 쿠버네티스에서 기본적인 배포 단위, 하나 이상의 컨테이너로 구성될 수 있음

파드의 구성 요소와 특징

1. 컨테이너

   • 파드는 하나 이상의 컨테이너를 포함할 수 있음
   • 컨테이너들은 동일한 네트워크 및 UTS 네임스페이스 공유
     • 필요한 경우 IPC 통신
   • 각 파드는 하나의 주요 애플리케이션 컨테이너 포함

2. 공유 네트워크

   • 모든 컨테이너는 동일한 IP주소와 포트 공간 공유
   • 외부에서 파드에 접근할 때 마치 하나의 엔티티처럼 보이게 함
   • 로컬호스트를 통해 컨테이너 간의 통신 가능

3. 공유 스토리지 볼륨

   • 파드는 하나 이상의 볼륨을 정의할 수 있음
   • 볼륨은 파드 내의 컨테이너들 사이에 공유됨
     • 파일 시스템을 통한 데이터 공유 용이
   • 쿠버네티스는 다양한 유형의 볼륨 지원

4. 생명주기와 관리

   • 파드는 불변성을 가짐
     • 한 번 생성되면 내부의 컨테이너는 변경 불가
     • 컨테이너를 업데이트해야 하면, 파드를 새로 생성하고 교체하는 방식으로 처리
   • 파드는 일반적으로 복제를 통해 고가용성을 보장받음
     • 쿠버네티스는 파드의 상태를 모니터링
     • 실패한 파드를 자동으로 대체하는 복제 컨트롤러나 레플리카셋을 사용하여 관리
   • 노드 내에서 각 파드는 독립적인 실행 환경을 제공받음
     • 노드의 리소스를 할당받아 사용함
     • 쿠버네티스 스케쥴러는 파드를 적절한 노드에 스케쥴링 => 리소스 사용 최적화, 시스템의 전반적인 효율성을 높임

쿠버네티스 특징

• Self-healing
  • 쿠버네티스는 실패한 컨테이너를 다시 시작하고 컨테이너를 교체한다
  • 사용자 정의 상태 검사에 응답하지 않는 컨테이너를 죽인다
  • 서비스 준비가 끝날 때까지 그 과정을 클라이언트에게 보여주지 않는다
• Auto scaling
  • 쿠버네티스의 오토스케일링은 시스템이 자동으로 파드의 수를 조정함
  • 변화하는 워크로드에 따라 애플리케이션의 리소스 요구를 충족시킬 수 있도록 해주는 기능
  • 클라우드 환경에서 유용함
  • Horizontal Pod Autoscaler
    • CPU 사용량 또는 다른 선택된 메트릭을 기반으로 파드의 인스턴스 수를 자동으로 스케일 아웃/인함
  • Cluster Autoscaler
    • 쿠버네티스의 클러스터 오토스케일러는 클러스터 내에서 노드의 수를 동적으로 조정하여 파드의 수요에 따라 클러스터의 리소스를 최적화하는 역할
• Automated rollouts & rollbacks
  • Automated rollouts & rollbacks 기능은 애플리케이션의 배포 과정 자동화
    • 새로운 버전의 애플리케이션을 안전하게 배포하고, 필요한 경우 이전 버전으로 롤백

Docker를 사용하는 클라우드 서비스

1. Amazon Web Services (AWS)

   • Amazon Elastic Container Service (ECS): AWS에서 도커 컨테이너를 쉽게 실행/중지/관리하게 해주는 컨테이너 관리 서비스
   • AWS Fargate: 서버를 관리할 필요 없이 컨테이너를 직접 실행할 수 있는 서버리스 컴퓨트 엔진
   • Amazon Elastic Kubernetes Service (EKS): 쿠버네티스 기반 관리 서비스, 도커 컨테이너를 쿠버네티스 클러스터에서 쉽게 실행

2. Google Cloud Platform (GCP)

   • Google Kubernetes Engine (GKE): 도커 컨테이너를 쿠버네티스 클러스터에서 관리하고 확장하는데 사용되는 서비스
   • Google Cloud Run: 도커 컨테이너를 서버리스 환경에서 실행, 사용한만큼만 비용 지불

주요 배포 전략

로컬 환경 배포 VS. 프로덕션 환경 배포

1. 목적과 사용 범위

• 로컬 환경 배포: 주로 개발자가 개인적으로 사용하는 환경
  • 개발 중인 애플리케이션의 코드 변경 테스트 및 디버깅
• 프로덕션 환경 배포: 실제 사용자가 사용하는 환경
  • 안정성, 보안, 성능이 중요
  • 고가용성과 높은 성능

2. 설정고 구성

• 로컬 환경: 개발 편의성을 위해 간소화된 설정
• 프로덕션 환경: 보안, 데이터 무결성, 백업 등 운영 관련 최적화
  • 트래픽 부하: 로드 밸런서, 클러스터링, 캐싱 전략

3. 테스트와 검증

• 프로덕션 환경이 로컬 환경보다 더 많은 단계의 테스팅 환경 (개발, 테스트, 스테이징)을 거쳐 성능 테스트, 보안 테스트 및 부하 테스트 포함

4. 배포 자동화와 롤백

• 로컬 환경: 배포는 대부분 수동
• 프로덕션 환경: ㅐㅂ포 프로세스 자동화
  • CI/CD 파이프라인 사용하기도 함

5. 모니터링과 로깅

• 로컬 환경: 로깅 도구 or 디버깅 출력
• 프로덕션 환경: 고급 모니터링 및 로깅 시스템 구축

---

출처
https://kubernetes.io/ko/docs/concepts/overview/
원티드 2024 4월 백엔드 자료