Microsoftware (8) Kubernetes

대용량 트래픽 처리법
1. 수평적 확장: 서버를 여러 대로 확장하여 트래픽 부하를 분산시키는 것
2. 캐싱: 캐싱을 사용하여 반복적으로 요청되는 데이터나 계산 결과를 저장하여 서버 부하 감소
3. 비동기 처리: 동기적인 요청-응답 패턴이 아닌 비동기 처리 방식을 사용하여 서버의 응답 대기 시간을 감소
4. 데이터베이스 최적화: 데이터베이스 쿼리의 성능을 최적화하여 대량의 트래픽 처리
5. 클라우드 서비스 활용: 대용량 트래픽을 처리하기 위해 클라우드 서비스를 활용니다.

Microservice

Monolithic Architecture

• 하나의 애플리케이션 안에 모든 것이 구현돼 있는 구조
• 사용자의 트래픽 증가로 용량 증설이 필요하다면?
  • 모든 기능이 구현된 쌍둥이 같은 애플리케이션이 가동 중인 컴퓨터 추가
• 코드의 밀결합
  • 개발 완료 후 코딩 바인드를 맞추는 과정 오래 소요
  • 하나의 기능에서 오류가 발생하면 전체 서비스 마비
• Monolithic Architecture의 경우 용량을 키울 때 똑같은 프로그램을 여러 컴퓨터에서 실행
  • 소프트웨어를 새로운 컴퓨터에 최적화하지 않고 그냥 올리기 때문에 덜 효율적
• 개발진을 키울 경우 신입 개발자는 본인의 업무 외에도 알아야 할 선수 지식이 많음
• 사용자 트래픽이 급증하지 않는 경우에 적합

Microservice Architecture

• 애플리케이션을 구성하는 요소들을 각각 독립적으로 분리해서 독립적으로 실행
• API를 통해 각 서비스끼리 정보 교환
  • API만 준수한다면 각 서비스들은 다른 서비스들의 변경 사항을 알 필요가 없음
• 수정과 업그레이드가 자유로워서 회의가 줄어들고 결합도가 낮아짐
• 다음 버전 릴리즈까지의 시간 단축 → Agile
• 필요한 서비스에 대해서만 용량 증설 가능 → 차별화된 용량 증설 가능
• 본인 부서만 잘 알면 되기에 선수 지식이 적어서 개발진 확장 용이
• 통신하는 API를 맞춰야 한다는 번거로움

Why Microservice?

• Scalability: Microservice는 잘게 쪼개져 있어 증설이 필요한 서비스의 용량만 필요한 만큼 늘릴 수 있음
• Availability: 서비스 중 하나가 죽더라도 다른 서비스는 가용함
• Fault Tolerance: 장애 대응에 유리
• Agile: 시장의 반응을 보며 짧은 개발 주기 유지
  • 서비스마다 다른 개발 주기를 가질 수 있음
• Polyglot Persistance: 독립된 프로그램의 개발 방법 자유 선택 → 목적에 맞는 도구를 최적화해서 쓸 수 있음

Kubernetes

Kubernetes

• 컨테이너의 군집 관리
• 애플리케이션 개발 관련 기능 제공
• 용량 관리
• 하드웨어와 독립된 동작 지원
• 효율적인 재시작 & 시스템간 이동

Pods

• 비슷한 일을 하는 컨테이너의 묶음
• Kubernetes에서는 Pod이 가장 작고 단순한 빌딩 단위
• Pod: 여러 컨테이너 + Storage + 하나의 IP 주소
  • 하나의 Pod 안에 있는 컨테이너끼리는 localhost를 쓴 호출 사용 가능
  • 하나의 Pod은 Unique한 IP를 가지고 Pod 안에 있는 컨테이너끼리는 네트워크 이름 서로 공유
  • Pod 안의 컨테이너들은 IP 주소가 같고 포트 번호가 달라야 함

Nodes

• 물리적인 컴퓨터나 가상 머신
• 노드들에서 label을 붙여 서비스인 Pods을 생성

Cluters

• Kubernetes에 의해 관리되는 컨테이너화된 앱들이 실행되는 Set
• 노드의 네트워크는 공개된 인터넷 범위가 아니고 방어되어 있음 → 외부와 소통하기 위한 구멍 필요
  
• 군집을 관리하기 위한 Master Pod 존재

Deployment

• Kubernetes에서 앱을 실행하는 것
• 개발자는 앱을 직접 실행하는 것이 아니라 Desired State를 YAML 파일에 기술해서 Kubernetes에게 부탁
• 전달된 상태가 유지되는 것

Service

What is Service?

• Pod에 접근하거나 연결하기 위한 Kubernetes의 추상화
• Service는 YAML 파일에 의해 정의
• 서비스를 만들고 필요할 때 호출하고 제어하기 위해 Label 사용 (도메인처럼)
• Pod은 하나의 IP 주소를 공유하지만 내부에서만 작동하고 외부로는 공개되지 않음
• 내부와 외부가 통신할 포트 구멍을 ServiceSpec에 기술

ServiceSpec

• Cluster IP
  • local에서만 curl을 통해 pod에 접속하고 pod끼리 소통하게 해 주는 default service
  • 외부와의 통신은 불가능
• NodePort Service
  • 클러스터를 구성하고 있는 Node에 외부의 입력을 받는 포트를 하나 여는 것
  • 가상 머신도 가능
• LoadBalancer Service
  • 입력받은 트래픽을 노드들에게 균등 분배
    
  • 물리적인 컴퓨터가 두 대 이상일 때만 동작

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application
  labels:
    app: application
spec:
  replicas: 2
  selector:
    matchLabels:
      app: application
  template:
    metadata:
      name: application
      labels:
        app: application
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
        - name: redis
          image: redis
          volumeMounts:
            - mountPath: /data/redis
              name: redis-storage
      volumes:
        - name: redis-storage
          emptyDir: {}

apiVersion: v1
kind: Service
metadata:
  name: simple
spec:
  type: Ingress
  selector:
    app: application
  ports:
    - name: http
      port: 80