22/03/08 TIL

📌 Load Balancer

• 서버에 요청을 보내는 이용자가 적으면 관계없지만, 수백 수천만의 이용자가 동시에 서버를 이용하고 있다면 서버가 멈출 수도 있다.
• Scale-up과 Scale-out 두 방법이 있는데, Scale-out을 통해 위 문제를 해결할 수 있다. Scale-up은 하드웨어의 성능을 높이는거라 한계가 존재.

Scale-out의 장점

• Scale-up은 비용적인 측면에서 부담
• 여러 대의 server를 운영하여 무중단 서비스를 제공할 수 있음

Load Balancing

• 트래픽을 여러 대의 서버가 분산처리
• 서버의 로드율, 부하량, 속도저하 등을 고려하여 적절히 분산처리하여 해결
• Static
  • Round Robin : 순서대로
  • Ratio(가중치) : 가중치가 높은 서버
  • Priority Group Active : Active 장치
• Dynamic
  • Least Connection : 연결 수가 적은 서버
  • Fastest : 가장 빠르게 응답하는 서버
  • Least Loaded : 가장 부하가 적은 서버

Load Balancer

• OSI 7계층을 기준으로 layer 별 기준으로 load balancing을 수행
• 상위 계층을 기준으로 부하를 분산할수록 섬세한 부하 분산이 가능하지만 비용이 올라감
• L2 : Mac 주소를 바탕으로 수행
• L3 : IP 주소를 바탕으로 수행
• L4 : Transport Layer level에서 수행 (port)
  • 1.2.3.4:8080 -> 5.6.7.8
  • 1.2.3.4:8081 -> 5.6.7.10
• L7 : application Layer level에서 수행 (domain)
  • 1.2.3.4/hello -> 5.6.7.8
  • 1.2.3.4/hi -> 5.6.7.10

📌 Nginx

• Master Process와 Worker Process로 구성
• Master는 설정파일을 읽고, worker 관리
• 요청에 대한 실제 처리는 worker가 담당
• Event Driven
• 높은 성능, 동시성, 낮은 리소스 사용
• 웹서버: 정적 컨텐츠 제공을 위해 설계
• 리버스 프록시: 클라와 서버 사이에 존재하고 요청을 가로채 처리

📌 Kubernetes

• 컨테이너 오케스트레이션 도구
• 선언적, 자동화 관리 기능
• 클러스터는 전체를 관리하는 컨트롤러로 마스터가 존재하고, 커네이너가 배포되는 머신인 노드가 존재
• 오브젝트-컨트롤러의 구조

pod

• 리눅스 컨테이너를 하나 이상 모아 놓은 것
• 쿠버네티스 애플리케이션의 최소 단위
• 하드웨어 유닛
  • 노드: 최소 단위의 컴퓨팅 하드웨어, 개별 머신
  • 클러스터: 지능적인 리소스 공유와 균형 배분을 위해 여러 노드를 묶은 그룹
• 소프트웨어 유닛
  • Linux 컨테이너: 하나 이상의 프로세스 모음, 실행에 필요한 파일도 모두 들어있어 머신간 이식이 가능
  • pod: 하나 이상의 linux 컨테이너 몽므, 클러스터 관리를 통한 리소스 공유의 장점을 극대화하기위해 패키지로 관리

deployment

• 말 그대로 배포. 배포를 추상화한 Pod의 묶음
• 기본적으로 Replication Controller를 생성하고, 이를 관리하는 역할

service

• pod와 연결되는 논리적인 Endpoint
• 필요한 이유?
  • 고객들의 서비스 접근을 위한 고정된 IP가 필요
  • Pod가 죽어버리면, 해당 Pod를 다시 띄우는데 띄워질 때마다 동적 IP 할당
  • 여러개의 Pod을 하나의 서비스 객체로 선언할 수 있음
  • 서비스 객체는 트래픽을 전달하는 역할
  • 자신의 서비스와 연관된 Pod까지의 경로를 찾아 트래픽을 전달
  • label이라는 key-value를 이용해 endpoint Pod을 찾는다
• ClusterIP, NodePort, LoadBalancer 등의 종류가 있음

ingress

• 클러스터 외부에서 내부로 접근하는 요청을 어떻게 처리할지 정리해둔 규칙들의 모음
• 외부에서, k8s에서 실행 중인 deployment와 service에 접근하기 위한 일종의 관문(Gateway)같은 역할
• 위에서 공부했던 LB의 역할도 담당할 수 있는데, L7 layer 수준에서도 가능
• ingress-gce, ingress-nginx 두 가지 ingress controller가 있음
• 규칙의 예시
  • (1) xxx.com 이라는 호스트 명으로 접근하는 요청에 대해
  • (2) http 프로토콜을 통해
  • (3) /api/hostname-service 라는 경로로 접근하는 요청을
  • (4) hostname-service 라는 이름의 service의 xx포트로 전달하라
• ingress는 ingress controller 라는 특수한 서버 컨테이너에 적용되어야 함
• 직접 운영할지, 클라우드 플랫폼에 위임할지 정할 수 있음
  • 직접 controller를 구동하려면 nginx ingress controller를 사용
  • 위임하려면 Google Kubernetes Engine 기능을 사용할 수 있음