개발자는 왜 쿠버네티스를 쓸까? | 두 번째 이유: 서비스 디스커버리 & 로드 밸런싱

14 sec read

사라지는 IP 주소와 트래픽 분산, ‘서비스(Service)’ 하나로 해결하기

지난 글에서는 쿠버네티스가 어떻게 컨테이너를 최적의 서버에 자동으로 배치(Scheduling)하는지 알아보았습니다. 이제 우리의 애플리케이션 컨테이너들은 클러스터 어딘가에서 잘 실행되고 있습니다.

하지만 여기서 새로운 질문이 생깁니다. 여러 개의 컨테이너(마이크로서비스)로 구성된 애플리케이션은 서로를 어떻게 찾아서 통신할 수 있을까요? 이것이 바로 쿠버네티스를 사용하는 두 번째 핵심 이유, ‘서비스 디스커버리 및 로드 밸런싱’과 관련이 있습니다.


💬 개발자의 고민: “서로 다른 서비스끼리 어떻게 통신하죠?”

컨테이너가 성공적으로 배포되었다고 해도, 개발자의 고민은 끝나지 않습니다. 특히 여러 개의 마이크로서비스를 운영할 때는 다음과 같은 복잡한 문제에 부딪힙니다.

“제 애플리케이션은 사용자 서비스, 상품 서비스, 주문 서비스로 나뉘어 있어요. 이 서비스들끼리 어떻게 서로를 찾아서 API를 호출해야 할까요?”

컨테이너(Pod)의 IP 주소는 재시작할 때마다 계속 변하는데, 이걸 일일이 추적할 수도 없고요.”

“또, 주문 서비스에 트래픽이 몰려서 컨테이너를 3개로 늘렸는데, 요청을 어떻게 이 컨테이너들에게 골고루 분산시키죠?

이 모든 것을 직접 해결하려면 복잡한 네트워크 설정이나 별도의 서비스 레지스트리, 로드 밸런서가 필요합니다.


🔧 쿠버네티스의 우아한 해결책: ‘서비스(Service)’라는 해결사

쿠버네티스는 이 모든 문제를 ‘서비스(Service)’라는 아주 단순하면서도 강력한 개념 하나로 해결합니다. 서비스는 보이지 않는 곳에서 두 가지 중요한 역할을 수행하는 교통 경찰과 같습니다.

  1. 고정된 주소 부여 (서비스 디스커버리): 여러 개의 Pod 그룹에 대해 고정된 IP 주소변하지 않는 DNS 이름을 부여합니다. Pod가 죽고 새로 생겨 IP가 바뀌어도, 이 서비스의 이름과 주소는 그대로 유지됩니다.
  2. 트래픽 분산 (로드 밸런싱): 자신에게 오는 모든 요청(트래픽)을 그룹에 속한 Pod들에게 알아서 골고루 나누어 줍니다.

개발자는 다음과 같이 간단한 YAML 파일로 서비스를 정의하기만 하면 됩니다.

# 예시: 'user-service'라는 이름의 서비스 정의
apiVersion: v1
kind: Service
metadata:
  name: user-service # 이 서비스의 고유한 이름 (DNS 이름으로 사용됨)
spec:
  # 'app: user' 라는 라벨(label)이 붙은 모든 Pod를 찾아 하나의 그룹으로 묶습니다.
  selector:
    app: user
  ports:
    # 이 서비스는 80번 포트로 요청을 받아서,
    - port: 80
      # Pod 내부의 8080 포트로 전달합니다.
      targetPort: 8080

✨ 어떻게 동작할까요?

위와 같이 user-service를 생성하면, 이제 클러스터 내의 다른 애플리케이션(예: order-service)은 더 이상 user Pod들의 실제 IP 주소를 알 필요가 없습니다.

주문 서비스http://user-service 로 요청 전송 → user-service (서비스) 가 요청을 받음 → user Pod 1, 2, 3... 중 하나로 자동 전달

이처럼 애플리케이션은 고정된 서비스 이름(user-service)으로만 통신하면, 쿠버네티스가 내부적으로 모든 복잡한 연결과 트래픽 분산을 처리해 줍니다.


🎁 개발자가 얻는 실질적인 혜택

쿠버네티스 서비스를 통해 개발자는 다음과 같은 놀라운 이점을 누리게 됩니다.

IP 주소로부터의 해방: 계속 변하는 Pod의 IP 주소를 더 이상 추적하거나 설정 파일에 하드코딩할 필요가 없습니다.

안정적인 서비스 간 통신: 서비스의 고유한 DNS 이름을 통해 언제나 안정적으로 다른 서비스를 호출할 수 있어, 마이크로서비스 아키텍처 구현이 매우 쉬워집니다.

내장된 로드 밸런싱과 확장성: 별도의 로드 밸런서 장비나 복잡한 설정 없이도, Pod를 추가하는 것만으로 자동으로 트래픽이 분산되어 서비스의 확장성과 고가용성을 손쉽게 확보할 수 있습니다.

결국 쿠버네티스의 ‘서비스’는 개발자가 네트워크의 복잡함에서 벗어나, 비즈니스 로직에만 집중하도록 도와주는 핵심적인 기능입니다.

쿠버네티스 시크릿 관리, 어떤 방법이 최선일까? 4가지 방식 장단점…

쿠버네티스에서 애플리케이션을 운영할 때, DB 접속 정보나 API 키 같은 민감한 정보, 즉 ‘시크릿(Secret)’을 어떻게 관리해야 할지는 모두의 공통된 고민입니다. 관리 방식은 보안, 운영...
eve
13 sec read

[MSA] Spring Cloud Gateway VS Apache APISIX : 단계별…

마이크로서비스 아키텍처(MSA)에서 API 게이트웨이는 시스템의 관문 역할을 하는 핵심 컴포넌트입니다. 수많은 Java 개발팀이 Spring 생태계와의 완벽한 통합성을 자랑하는 Spring Cloud Gateway를 선택해왔습니다. 그러나 시스템이...
eve
1 min read

[Kafka] 카프카의 심장: 토픽, 파티션, 프로듀서, 컨슈머 완벽 해부

Apache Kafka가 어떻게 대용량 데이터를 실시간으로, 그리고 안정적으로 처리할 수 있는지 궁금하신가요? 그 비밀은 Kafka를 구성하는 핵심 요소들의 유기적인 협력에 있습니다. Kafka는 마치 잘...
eve
1 min read