86. 레플리카셋 (ReplicaSet) - 자가 치유와 스케일링

⚠️ 이 문서는 쿠버네티스(Kubernetes) 환경에서 관리자가 "나는 항상 Nginx 웹 서버 3대가 켜져 있었으면 좋겠어"라고 선언(Desire)하면, 서버가 고장 나거나 트래픽이 몰려 파드(Pod)가 죽어버리더라도 **귀신같이 알아채고 새로운 파드를 재생성하여 반드시 3대(Replicas)라는 숫자를 영원히 유지해 주는 무한 책임 컨트롤러인 '레플리카셋'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 쿠버네티스의 철학인 '선언적 시스템(Declarative System)'의 핵심 엔진이다. "지금 파드 몇 개 켜져 있어?"가 아니라, "항상 3개가 켜져 있는 상태(Desired State)를 만들어 놔"라는 목표를 달성하기 위해 끊임없이 현재 상태와 목표 상태를 비교하는 무한 루프(Reconciliation Loop) 감시자다.
  2. 가치: 새벽에 서버 랙 전원이 나가 파드 1개가 타버리더라도, 관리자가 알람을 받고 깰 필요 없이 시스템이 **스스로 판단해 0.1초 만에 다른 건강한 서버에 새 파드 1개를 다시 띄워 채워놓는 자가 치유(Self-healing)**의 기적을 보여준다.
  3. 기술 체계: 레플리카셋은 직접 파드를 콕 집어 관리하지 않고, 오직 파드에 붙어있는 **라벨(Label Selector, 예: app=web)**만을 쳐다본다. 이 라벨이 붙은 파드의 개수가 지정된 숫자와 다르면 무조건 파드를 죽이거나 생성한다. (현대엔 Deployment 객체의 하수인으로 쓰임)

Ⅰ. 파드의 죽음과 매뉴얼 복구의 한계

Pod는 소모품이다. 누군가는 죽은 Pod의 빈자리를 채워야 한다.

  1. Bare Pod (벌거벗은 파드)의 위험성:
    • 쿠버네티스에 그냥 .yaml 파일로 Kind: Pod를 만들어 띄웠다 치자.
    • 이 파드가 구동 중인 리눅스 노드(서버)가 갑자기 커널 패닉으로 뻗어버리면, 그 안에 있던 파드도 흔적도 없이 사라지고 다시는 돌아오지 않는다. 접속자는 에러 화면을 보게 된다.
  2. Reconciliation Loop (조정 루프):
    • 이를 막기 위해 레플리카셋이라는 매니저를 고용한다. 매니저에게 "Replicas: 3"이라는 목표를 적어준다.
    • 매니저는 1초에도 수십 번씩 묻는다. "지금 몇 개지? 3개. 목표는? 3개. 오케이."
    • 갑자기 서버가 죽었다. "지금 몇 개지? 2개. 목표는? 3개. 어라 1개가 모자라네? 묻지도 따지지도 말고 지금 당장 1개를 새로 만들어!" (자가 치유 발동)

📢 섹션 요약 비유: 양 떼 목장에서 양치기 개(레플리카셋)에게 "항상 양 3마리를 유지해"라고 명령한 것입니다. 늑대가 나타나 양 1마리를 물어가면, 양치기 개는 누가 양을 물어갔는지 슬퍼하거나 원인을 찾지 않고, 그냥 창고에서 새끼 양 1마리를 꺼내와 들판에 던져서 어떻게든 숫자 '3'을 맞추는 데에만 혈안이 된 기계적인 숫자의 화신입니다.

Ⅱ. 라벨 셀렉터 (Label Selector)의 접착 마법

레플리카셋은 눈이 나빠서 오직 '이름표(Label)' 색깔만 본다.

  1. 라벨 기반의 느슨한 결합 (Loose Coupling):
    • 레플리카셋은 특정 파드의 IP나 ID를 외우지 않는다. 오직 스티커(Label)만 본다.
    • "내 목표는 tier=frontend라는 라벨이 붙은 파드를 3개 유지하는 것이다"라고 세팅된다.
  2. 스케일 아웃(Scale-out)과 스케일 인(Scale-in):
    • 블랙프라이데이 세일로 접속자가 폭주하면, 관리자는 단순히 Replicas 숫자를 3에서 10으로 바꾼다. 레플리카셋은 즉시 tier=frontend 라벨을 쥔 똑같은 파드 7개를 미친 듯이 찍어낸다.
    • 세일이 끝나 숫자를 다시 3으로 줄이면, 레플리카셋은 자비 없이 파드 7개를 임의로 골라 도끼로 찍어 죽여버린다.
  3. 라벨 장난(Label Tampering)이 부르는 현상:
    • 재밌는 현상이 있다. 정상적으로 3개가 돌아가고 있는데, 관리자가 실수로 파드 1개의 라벨을 tier=backend로 떼어버렸다(수정).
    • 레플리카셋은 "어라? 내 구역에 frontend 스티커 붙은 놈이 2개밖에 없네?"라며 즉시 새로운 파드 1개를 새로 찍어내어 3개를 맞춘다. (라벨이 바뀐 파드는 통제 밖의 고아가 되어버린다.)

📢 섹션 요약 비유: 양치기 개는 눈이 안 보여서 오직 양 엉덩이에 붙은 '빨간 스티커(라벨)'의 개수만 셉니다. 멀쩡한 양이라도 장난으로 빨간 스티커를 떼어 파란색으로 바꾸면, 양치기 개는 양이 없어졌다고 착각하고 창고에서 빨간 스티커가 붙은 새 양 한 마리를 또 끌고 나오는 지독한 안면 인식 장애를 가졌습니다.

Ⅲ. 레플리카셋의 쇠퇴와 Deployment의 등장

현대 쿠버네티스에서 레플리카셋을 직접 손으로 다루는 일은 거의 없다.

  1. 버전 업데이트 (Rolling Update)의 한계:
    • v1 앱이 돌아가는 파드 3개를 v2로 업데이트하고 싶다.
    • 레플리카셋 하나만으로는 "v1을 하나 죽이고 v2를 하나 살리는" 복잡하고 우아한 무중단 배포(롤링 업데이트)를 혼자서 통제할 지능이 없다.
  2. 상위 포식자: 디플로이먼트 (Deployment)의 지배:
    • 이 멍청한 숫자 맞추기 기계(레플리카셋) 위에, 배포 전략을 전담하는 똑똑한 사령관인 디플로이먼트(Deployment) 객체를 하나 더 얹었다.
    • 디플로이먼트에게 "v2로 바꿔줘"라고 명령하면, 디플로이먼트는 백그라운드에서 v2용 새 레플리카셋을 만들고 그 숫자를 0에서 3으로 서서히 늘리면서, 동시에 v1용 옛날 레플리카셋의 숫자를 3에서 0으로 서서히 줄이도록 조종(Orchestration)한다.

📢 섹션 요약 비유: 레플리카셋은 오직 무식하게 덤벨 개수(파드 수)만 맞추는 헬스장 알바생입니다. 알바생에게 운동 루틴(버전 업데이트)까지 짜라고 하면 사고가 나기 때문에, 쿠버네티스는 그 알바생 위에 PT 트레이너(Deployment)를 고용했습니다. 우리는 이제 알바생(레플리카셋)에게 직접 지시하지 않고, 항상 PT 트레이너(Deployment)에게 결재를 올려 알바생을 조종하게 하는 간접 명령 체계를 씁니다.