WEB BE Repository 42

[쿠버네티스 튜토리얼] 7. 쿠버네티스의 리소스 조절

본 글은 GPT 정리를 참고하였습니다. 쿠버네티스(Kubernetes)에서 “리소스 조절”은 크게 2가지 의미로 쓰인다.한 컨테이너/파드(Pod)가 쓰는 CPU·메모리 양을 정하는 것부하에 따라 파드/노드 개수를 자동으로 늘리고 줄이는 것1) 가장 기본: requests / limits (리퀘스트 / 리밋)파드 안의 컨테이너마다 CPU, 메모리 사용량을 어느 정도로 잡을지를 선언한다.requests (요청량): “최소 이 정도는 필요”쿠버네티스 스케줄러(Kubernetes Scheduler)가 파드를 어느 노드(Node)에 올릴지 결정할 때 참고한다.limits (제한량): “최대 이 이상은 못 씀”실행 중 제한을 넘으면 제어가 들어가게 된다.CPU는 보통 쓰로틀링(throttling, 속도 제한)이 걸..

[쿠버네티스 튜토리얼] 6. Helm 설치 및 애플리케이션 관리

Kubernetes에서는 복잡한 애플리케이션 배포를 쉽게 하기 위해 Helm 패키지 매니저를 널리 사용한다.Helm은 차트(Chart)라는 단위로 Kubernetes 매니페스트들을 묶어 패키징하고, 템플릿화하여 재사용 가능하게 한다. 차트는 애플리케이션(예: WordPress, MySQL 등)의 Kubernetes 리소스 정의들을 포함하며, 값 파일(values.yaml)을 통해 환경별 설정을 바꿀 수 있다. 간단히 말해, Helm은 Kubernetes 세계의 apt/yum/npm 같은 패키지 매니저이다. (사용법은 도커허브와 유사하다.)차트를 이용하여 복잡한 앱을 한 줄로 설치하거나, 버전 관리를 할 수 있다.Helm CLI 설치 (로컬 환경)Helm 설치Ubuntu에서는 snap으로 설치하거나, 스크..

[쿠버네티스 튜토리얼] 5. 쿠버네티스 네트워크 동작원리

쿠버네티스 네트워킹은 Pod 간 통신, 서비스 디스커버리, 외부 접근 등을 포함한다.앞서 서비스, 인그레스 등을 다뤘지만, 이번에는 내부 네트워크 동작 원리에 초점을 맞춰 간략히 정리한다.Pod간 통신 관점Pod IP 및 통신Kubernetes에서 각 Pod는 고유 IP를 갖는다 (Pods are given unique IPs). 클러스터 내 모든 Pod는 하나의 가상 네트워크에 연결되어 있으며, IP를 통해 서로 직접 통신 가능하다. (클러스터의 CNI 플러그인, k3s 기본은 Flannel VXLAN이 이를 구현)즉, Pod A에서 Pod B의 IP로 요청을 보내면, 노드 경계와 상관없이 네트워크 패킷이 전달된다. 이는 kube-proxy와 CNI가 협력하여 이루어진다.그러나 직접 Pod IP를 사용..

[쿠버네티스 튜토리얼] 4. ConfigMap과 Secret 활용

애플리케이션 설정 관리는 애플리케이션 컨테이너화 및 배포 시 중요한 부분이다.Kubernetes에서는 ConfigMap과 Secret을 사용하여 설정값을 관리한다.ConfigMap: 환경설정 등의 비밀이 아닌 데이터를 키-값 형태로 저장하는 객체.예를 들면 애플리케이션 설정 파일, 환경 변수 등등Secret: 비밀번호, API 키 등 민감한 정보를 저장하는 객체이다.Secret의 데이터는 base64로 인코딩되어 저장되지만 기본적으로 암호화되진 않으므로 적절한 권한 관리와 필요 시 암호화 설정이 필요하다.ConfigMap과 Secret 모두 Pod에 주입할 수 있다.환경변수로 노출하거나파일로 마운트하여컨테이너 내에서 읽도록 할 수 있다. 이번 섹션에서는 ConfigMap과 Secret을 생성하고 Pod에..

[쿠버네티스 튜토리얼] 3. 서비스 노출: ClusterIP, NodePort, Ingress

Kubernetes에서 Service(서비스) 객체는 Pod들의 논리적인 집합에 단일 접근 포인트(IP 및 DNS 이름)을 제공하는 역할을 한다.앞서 Deployment로 Nginx Pod 여러 개를 띄웠다면, 클라이언트가 그중 어떤 Pod에 접속해야 할지 알기 어렵다.Service를 사용하면 여러 Pod들을 하나의 서비스로 묶고, 부하 분산(Load Balancing) 및 서비스 디스커버리(DNS)를 제공할 수 있다. Kubernetes에는 몇 가지 서비스 유형(Service Types)이 있다.ClusterIP (기본값)클러스터 내부에서만 접근 가능한 가상 IP를 부여한다.내부 서비스 용도로 사용된다.NodePort각 Node의 IP에서 정해진 포트를 열어, 외부에서 노드IP:포트로 접근할 수 있게 ..

[쿠버네티스 튜토리얼] 2. Deployment 생성과 ReplicaSet 이해

Deployment는 Kubernetes에서 애플리케이션의 배포(Deployment)와 업데이트를 관리하는 상위 리소스이다.Deployment를 생성하면 Kubernetes는 자동으로 ReplicaSet이라는 객체를 만들고, ReplicaSet이 정의된 수만큼 Pod를 생성하여 애플리케이션을 실행한다.Deployment를 통해 롤링 업데이트, 자동 복구, 배포 이력관리 등이 가능하며, 운영 환경에서 주로 사용된다.ReplicaSet은 말 그대로 Pod 레플리카(복제본) 집합을 관리하는 객체이다.“이런 Pod를 N개 running 시켜라”라는 역할을 하며, 자체적으로는 수평 확장만 관리할 뿐 업데이트 전략 등은 없다.Deployment가 ReplicaSet을 감싸서 관리한다고 이해할 수 있다. 요약하면, ..

[쿠버네티스 튜토리얼] 1. k3s로 배워보자.

서비스를 배포할 때, 롤링/카나리/블루 그린같은 무중단 배포 전략을 고려하다 보면, 자연스레 컨테이너를 다루는 방식으로 손이 가게 된다. 현재 진행하고 있는 프로젝트 Pinit의 경우, MSA로 구성되어 있어서, 무중단 배포를 위한 전략을 쉽게 선택할 수 있는 도구가 필요했다. 이때, 도커 컴포즈와 쿠버네티스를 보통 이야기하는데, 이번 기회에 쿠버네티스를 한번 쭉 써보면서 MSA의 인프라 구성에 대해 이해하고자 다음과 같이 튜토리얼을 시작했다. k3s는 Rancher사가 배포한 경량 Kubernetes로, 리소스가 적은 환경이나 로컬 실습에 적합하다.k3s는 설치가 매우 간단하며, 단일 바이너리에 Kubernetes의 핵심 기능을 모두 포함하고 있다.이 섹션에서는 Ubuntu 20.04+ 환경에 k3..

Java - classpath

우리가 특정 데이터를 JVM에 올리고 싶을 때, 이를 안정적으로 업로드할 "마법"이 필요해진다.이 예로는 공개 키 파일과 같은 것들이 있다.만약 키를 평범한 상대경로/절대경로로 가져오고 있다면, 이는 현재 환경에 종속적인 빌드 결과가 된다.(참고로 비밀 키와 같은 secret값들은 엄격한 운영 상황에서는 배포의 범위가 빌드 수준까지 넓어져 클래스패스에 올리지 않는다.)이때, 클래스패스라는 용어를 곧잘 접하게 된다. 클래스패스는 자바의 JVM 이 클래스를 로드할 때 사용하는 클래스로더와도 곧잘 얽히는데, 지금부터 이 클래스패스에 대해 빠르게 알아보자.1. 클래스패스란 무엇인가간단히 말하면JVM이나 컴파일러가 .class 파일과 리소스(예: .properties, .json, .xml)를 찾기 위해 검색하는..

[RabbitMQ] Rabbit MQ의 이름 짓기

개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다. 생산자 선언ExchangeRouting Key소비자 선언QueueBinding key (routing key에 의존적)나는 딱히 이름 짓기에 재능이 없어서 매번 AI에게 도움을 많이 받는데, 적어도 이름을 짓는데 어느정도 규칙이 있어야 나중에 읽을 때 무리가 없기 때문에, 각각의 수행하는 역할과 책임에 집중해서 이름을 짓는 규칙을 정해본다.과거 scheduleMemberNestedDtoMap 이라는 해괴한 이름을 짓고 팀원에게 쓴소리를 들은적도 있었다... 기본적으로 위 세 요소는 각각 다음과 같은 역할..

DB 설계와 쿼리 최적화

주의: 본 내용은 DB 내용에 대한 기초 지식이 어느정도 있음(DB 스캔의 작동 방식)을 가정하고 작성되었습니다.DB는 백엔드에서 가장 중요한 역할을 수행한다.DB 성능은 연동하는 모든 서버 성능에 영향을 주기 때문에, DB에 존재하는 기능을 전문가 수준으로 깊이 이해할 수 있다면 이상적이겠지만 조금만 신경 써도 DB 성능 문제를 충분히 줄이거나 없앨 수 있다.인덱스 설계예상하지 못한 테이블 풀 스캔은 DB 성능에 좋지 않은 영향을 끼친다.이를 피하기 위해서 보통 인덱스를 사용하는데, 이때 인덱스를 제대로 알고 써야 원하는 성능 효율을 얻을 수 있다.인덱스는 조회 패턴을 기준으로 설계해라.단일 인덱스 vs 복합 인덱스의 차이를 고려해라선택도(Selectivity)를 고려해라가능하다면, 커버링 인덱스를 활..