플레이데이터 풀스택 백엔드 9기 6월 4주차 회고

플레이데이터 풀스택 백엔드 9기 15주차 주간회고 및 학습기록 (열다섯번째 기록)

---

이번 주에는 kubernetes 공부와 함께 4차 프로젝트 프론트를 조금씩 이어나갔다. 어렵게 느껴졌던 node, pod 개념과 프론트를 진행하면서 중요하다고 느낀 것을 정리하고자 한다.

1. Kubernetes - Cluster, Node, Pod, Container, Service, Ingress

Kubernetes

• 컨테이너 오케스트레이션 도구
• 자동화된 컨테이너 배포, 스케일링, 관리를 제공하는 오픈소스 플랫폼
• 필요성 : 도커 이미지와 관리할 컨테이너가 늘어남 → 인스턴스 상태 관리나 자동화 툴의 필요

Kubernetes vs Docker Compose

Kubernetes	Docker Compose
1. yml 파일에 정의한 설정대로 컨테이너 생성, 삭제 → 바람직한 상태유지  2. 문제가 되는 컨테이너 삭제 및 새로 생성 3. 컨테이너가 삭제되면 설정대로 생성 등 정해진 상태 유지 4. 컨테이너 삭제는 명령으로 하지 않고 yml(매니페스트)에서 바람직한 상태를 수정해야 함	옵션을 지정해 수동으로 컨테이너의 수를 변경할 필요가 있음

 

Cluster

• 여러 개의 물리/가상 머신 (Node)들의 집합
• 컨테이너화된 애플리케이션을 배포/운영/관리하기 위해 하나의 통합된 시스템처럼 동작하도록 구성된 환경
• 물류센터 전체
• MSA 프로젝트 전체 시스템

Master Node

• cluster 전체를 관리, 제어, 스케줄링 (어떤 워커 노드에 pod를 배포할지 결정) 하는 컨트롤 타워
• 컨테이너 등의 상태를 관리하기 위해 etcd라는 키-값 타입의 데이터 베이스 설치
• 컨테이너의 라이프 사이클을 정의, 배포, 관리 
• Master Node 관리를 위해서는 관리자 컴퓨터에 Kubectl이 설치되어야 함
• 물류센터 관리자
• 전체 MSA 시스템을 관리하는 PM 같은 존재

 Worker Node

• 사용자가 배포한 애플리케이션 (pod/컨테이너)을 실제로 실행하는 물리/가상 머신
• 컨테이너가 실행되 곳 / 애플리케이션이 동작하는 공간
• 도커 엔진 같은 컨테이너 엔진 필요
• 구성
  • kube-let
    : 각 노드에서 실행되는 에이전트 → Master Node의 kube-scheduler와 연동해 Pod를 배치하고 확실하게 실행되도록 관리
  • kube-proxy
    : 각 노드에서 실행되는 네트워크 프록시로 쿠버네티스의 서비스 개념의 구현부
    → 네트워크 통신의 라우팅을 담당
• 개별 작업 구역 / 택배 분류 라인
• Spring Boot 서비스들이 실행되는 물리 서버 또는 가상 서버들

Pod

• Container + Volume
• 컨테이너를 관리하는 단위 
  • ReplicaSet
    : 특정 Pod의 복제본 개수를 유지 
    "같은 제품 박스 3세트 항상 준비해! 라고 외치는 담당자"
  • Deployment
    : Pod와 ReplicaSet에 대한 상태를 설정하고 Pod 배포를 관리하는 요소  → replicaset을 제어 
    (ReplicaSet을 자동으로 관리/업데이트/롤백해주는 상위 관리자)
    "박스 내용물 변경, 버전관리, 롤백! 이라고 외치는 담당자"
• 일반적으로 Pod에 컨테이너 1개 / 여러 컨테이너를 하나의 Pod에 묶어서 서로 네트워크/IP 공유 가능
• 하나의 배달 박스 세트
• user-service, movie-service 같은 각각의 Spring Boot 애플리케이션 실행 단위 (보통 하나 서비스당 하나 Pod)

Container

• 실제 실행 중인 애플리케이션 프로세스
• 박스 안의 개별 상품
• user-service.jar를 Docker로 싸놓은 실제 실행 단위

Service

• 동적으로 생성/삭제되는 Pod들 앞에 놓는 고정된 네트워크 출입구 (IP/도메인 역할)
• Pod들의 IP가 계속 바뀌어도, 클라이언트가 안정적으로 접속할 수 있게 중간에서 연결해 주는 추상화 계층
• 서비스는 고정된 IP(Cluster IP)를 부여 받아 외부에서는 이 IP 주소로 접근하며 이 때 서비스가 적절한 파드들로
  요청을 분배(로드 밸런서 역할)
• 정된 택배 송장번호
• recommend-service의 LoadBalancer 역할

Ingress

• 외부에서 클러스터 안으로 들어오는 HTTP/HTTPS 요청의 "입구 관문"
• "URL 경로", "도메인" 등을 기준으로 Service들로 트래픽을 자동 라우팅하는 역할
• 물류센터 입구 접수대
• 외부 사용자가 /recommend, /user 이런 URL로 접속할 때 Gateway 역할

 

---

2. 조건부 렌더링 - 전역 Header/Footer 숨기기 + 전용 Header/Footer 사용

4차 프로젝트(올리브영 클론 코딩)를 진행하면서 회원가입 창에서 사용할 전용 헤더와 푸터가 필요했다. 

올리브영 공식 사이트 전역 헤더

 

전역 헤더를 숨기는 설정을 제대로 해주지 않아 회원가입 창에서 전역헤더와 전용헤더 두 가지가 모두 보이는 상태가 되었다.

올리브영 공식 사이트 회원가입 창 헤더

SignUpHeader : 회원가입 창 전용 헤더 예시 코드

 

전역 헤더를 숨기고 전용 헤더를 보이기 위해 전역 layout을 다음과 같이 건드렸다.

전역 헤더&푸터를 숨기기 위한 전역 layout 코드

'페이지 경로가 /user/signup으로 시작하는지의 여부를 각각 hide___라는 변수로 저장한다. 

페이지 경로가 /user/signup에 시작한다면 !hide__는 false가 되어 && 뒤에 있는 <Header />와 <Footer /> 등을 렌더링하지 않고,

시작하지 않는다면  !hide__는 true가 되어 && 뒤에 있는 <Header />와 <Footer /> 등을 렌더링하게 되는 것이다.

 

물론 const isSignUpPage = pathName.startsWith('/user/signup'); 으로 변수를 하나만 선언해서 사용해도 되지만, 혹시 모를 유지보수를 생각해서 변수를 3개 모두 선언하였다.

 

---

약 2주만 더 지나면 플레이데이터에서의 학습 진도는 모두 끝나고 프로젝트만 남는다. 믿기지 않는다. 얼마 전에 git 사용법을 익힌 거 같은데...
새로운 도전들로 가득찬 7월이 기대되기도, 걱정되기도 한다. 걱정이 현실이 되지 않도록, 모르는 게 생기면 좌절하지 말고 진득하게 공부해야겠다.