개발일지

Nested Set Model: 계층적 데이터 관리를 위한 효율적인 접근법

-JUNHEOK- — Tue, 18 Mar 2025 23:54:18 +0900

1. Nested Set Model 개요

Nested Set Model은 데이터베이스에서 계층적 데이터를 저장하고 관리하는 방법 중 하나입니다. 이 모델에서는 각 노드를 두 개의 숫자(lft, rgt)로 표현하여 계층 구조를 효율적으로 조회할 수 있도록 합니다.

2. Nested Set Model의 원리

트리 구조의 각 노드는 왼쪽 값(lft)과 오른쪽 값(rgt)을 가지며, 이를 통해 트리 계층을 표현합니다.

예를 들어, 다음과 같은 트리 구조를 생각해 보겠습니다.

       A
      / \
     B   C
    / \   \
   D   E   F

이를 Nested Set Model로 변환하면 다음과 같이 저장됩니다.

ID	Name	lft	rgt
1	A	1	10
2	B	2	5
3	C	6	9
4	D	3	4
5	E	5	6
6	F	7	8

3. Nested Set Model의 장점과 단점

장점

효율적인 계층적 데이터 조회
- 트리의 특정 서브트리를 SQL 한 번으로 조회할 수 있음
- JOIN 없이 계층 구조를 쉽게 표현 가능
부모-자식 관계를 빠르게 조회 가능
트리 전체를 빠르게 탐색 가능

단점

삽입, 삭제, 이동이 복잡함
- 새로운 노드를 추가하거나 삭제할 때, 기존의 lft, rgt 값을 변경해야 함
- 노드 이동 시 전체 lft, rgt 값 조정이 필요하여 성능 부담이 있음
트리 구조 변경 시 성능 저하
- 노드 추가, 삭제, 이동 시 전체 데이터에 영향을 미칠 수 있음

4. Nested Set Model을 활용한 SQL 쿼리

4.1 서브트리 조회하기

특정 노드(A)의 모든 자식 노드 조회:

SELECT * FROM tree WHERE lft BETWEEN 1 AND 10;

4.2 부모 노드 찾기

특정 노드(E)의 부모 찾기:

SELECT * FROM tree WHERE lft < 5 AND rgt > 6 ORDER BY lft DESC LIMIT 1;

4.3 노드 삽입 알고리즘

새로운 노드를 추가할 때는 lft, rgt 값을 조정하는 알고리즘이 필요합니다.

새로운 노드를 삽입할 위치를 결정
기존 노드들의 rgt 값을 조정하여 공간 확보
새 노드의 lft, rgt 값을 설정

4.4 노드 삭제 알고리즘

삭제할 노드의 lft, rgt 범위에 있는 값을 삭제한 후, 나머지 값을 업데이트하는 방식으로 진행됩니다.

DELETE FROM tree WHERE lft BETWEEN 3 AND 4;
UPDATE tree SET lft = lft - 2 WHERE lft > 4;
UPDATE tree SET rgt = rgt - 2 WHERE rgt > 4;

5. Nested Set Model vs. Adjacency List Model

Nested Set Model을 선택해야 하는 경우

트리 구조에서 조회가 빈번하고, 변경이 드문 경우
계층 구조를 SQL 한 번으로 쉽게 조회해야 하는 경우

Adjacency List Model을 선택해야 하는 경우

삽입/삭제가 빈번한 트리
parent_id를 이용한 단순한 계층 구조가 필요한 경우

6. 결론

Nested Set Model은 계층적 데이터를 SQL 한 번으로 효율적으로 조회할 수 있는 강력한 모델이지만, 삽입/삭제가 빈번한 경우 성능 문제가 발생할 수 있습니다. 따라서, 사용 목적에 따라 Nested Set Model과 Adjacency List Model을 적절히 선택하는 것이 중요합니다.

Traefik + Prometheus + Grafana 모니터링 설정 (Docker Swarm)

-JUNHEOK- — Wed, 12 Mar 2025 12:02:31 +0900

Docker Swarm 환경에서 Traefik을 활용한 서비스 라우팅과 함께 Prometheus로 메트릭을 수집하고, Grafana를 통해 시각화하는 방법을 정리합니다.

설정 결과

Traefik에서 Prometheus 메트릭 수집
Prometheus가 메트릭을 저장 및 분석
Grafana에서 시각화

이 설정을 통해 실시간 트랙픽 모니터링, 서비스 상황 확인, 장애 감지 등을 할 수 있습니다.

1. Prometheus와 Grafana란?

Prometheus란?

Prometheus는 오픈소스 모니터링 시스템으로, 메트릭 수집 및 저장을 담당합니다.

Pull 방식으로 메트릭 수집 (Server 가 Client의 /metrics 에서 데이터 가져오지만)
시계열 데이터 저장 및 분석
Alerting 시스템 부원 (기본적인 경고 막상)
Grafana와 통합 가능

Grafana란?

Grafana는 Prometheus 등의 메트릭을 시각화하는 대시보드 툴입니다.

Prometheus 데이터를 그래프, 차트로 시각화
대시보드 컴터먼트화 가능
실시간 모니터링 가능
Slack, Discord 등과 연동해 경고 (Alert) 가능

전체 아키텍처

아래와 같은 구조로 구성됩니다.

사용자 요청 → Traefik → 서비스 컨테이너
                     ↘ 
                      Prometheus (메트릭 수집)
                                ↘
                                 Grafana (시각화)

Traefik: 트래픽을 라우팅하고 Prometheus 메트릭을 노출 (/metrics)
Prometheus: Traefik에서 메트릭을 수집하고 저장
Grafana: Prometheus 데이터를 시각화하여 운영 현황을 쉽게 확인

1. Traefik 설정 (Prometheus 메트릭 활성화)

Traefik이 Prometheus 메트릭을 보도할 수 있도록 설정합니다.

services:
  traefik:
    image: traefik:2.9
    command:
      - "--metrics.prometheus=true"
      - "--metrics.prometheus.addEntryPointsLabels=true"
      - "--metrics.prometheus.addServicesLabels=true"
      - "--metrics.prometheus.buckets=0.1,0.3,1.2,5.0"
      - "--entryPoints.metrics.address=:8080"
    ports:
      - "8080:8080"  # ✅ Prometheus가 메트릭을 가져가도록 필요

--metrics.prometheus=true: Prometheus 메트릭 활성화
--entryPoints.metrics.address=:8080: Prometheus가 Traefik의 /metrics 엔드포인트에서 데이터를 가져가도록 설정

Traefik 배포 후 /metrics 엔드포인트 확인

curl -s http://localhost:8080/metrics | head -n 20

Prometheus 설정 (Traefik 메트릭 수집)

Prometheus가 Traefik의 /metrics 엔드포인트에서 데이터를 가져오도록 설정합니다.

global:
  scrape_interval: 10s  # 10초마다 데이터 수집

scrape_configs:
  - job_name: 'traefik'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['traefik:8080']

version: '3.9'

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
    ports:
      - "9090:9090"
    networks:
      - traefik-network

Prometheus.yml

Grafana 설정 (Prometheus 데이터 시각화)

Grafana를 설정하여 Prometheus 데이터를 시각화할 수 있도록 합니다.

version: '3.9'

services:
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=yourpassword
    networks:
      - traefik-network

Grafana 접속: http://<클러스터_IP>:3000

ID: admin
PW: yourpassword

1) 데이터 소스 추가

http://localhost:3000 접속
데이터 소스 추가 → Prometheus 선택
URL: http://prometheus:9090 입력
Save & Test → 정상 연결 확인

2) Traefik 2.0 대시보드 추가

Grafana에서 Import 클릭
Dashboard ID: 4475 입력
Prometheus 데이터 소스를 선택 후 Load

실시간 모니터링 가능한 Prometheus 메트릭

traefik_entrypoint_requests_total	엔트리포인트별 요청 수
traefik_service_requests_total	서비스별 요청 수
traefik_backend_request_duration_seconds	백엔드 요청 응답 시간
traefik_backend_requests_total	백엔드 요청 횟수
traefik_tls_certs_not_after	TLS 인증서 만료 시간

Grafana에서 트래픽 요청, 응답 속도, TLS 상태 등을 한눈에 모니터링 가능!

결론

이제 Traefik + Prometheus + Grafana를 통해 실시간으로 트래픽을 모니터링할 수 있습니다.

1) Prometheus에서 Traefik 메트릭 수집
2) Grafana에서 실시간 요청량, 응답 속도 시각화
3) 장애 감지 및 알림 설정 가능

실시간 트래픽 분석 및 운영 모니터링을 강화할 수 있습니다

Jasypt를 활용한 Spring Boot 환경 변수 암호화

-JUNHEOK- — Wed, 5 Feb 2025 14:49:42 +0900

Spring Boot 프로젝트에서 환경 변수나 민감한 정보를 안전하게 관리하기 위해 Jasypt를 사용할 수 있습니다. Jasypt를 이용하면 application.yml에 있는 데이터베이스 연결 정보나 API 키 등을 암호화하여 보안성을 높일 수 있습니다.

1. Jasypt 의존성 추가

Spring Boot에서 Jasypt를 사용하려면 아래와 같이 build.gradle에 의존성을 추가해야 합니다.

// Jasypt 암호화
implementation 'com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.5'

2. Jasypt 설정 (JasyptConfig.java)

Jasypt의 암호화 설정을 위한 @Configuration 클래스를 생성합니다.

@Configuration
public class JasyptConfig {

    @Bean(name = "jasyptStringEncryptor")
    public StringEncryptor stringEncryptor() {
        PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
        SimpleStringPBEConfig config = new SimpleStringPBEConfig();

        // 환경 변수에서 Jasypt 암호화 키 가져오기
        String password = System.getenv("JASYPT_ENCRYPTOR_PASSWORD");
        if (password == null || password.isEmpty()) {
            password = ""; // 기본값 제공 (운영 환경에서는 사용 지양)
            System.out.println("[WARNING] JASYPT_ENCRYPTOR_PASSWORD가 설정되지 않아 기본 키를 사용합니다.");
        }
        config.setPassword(password);
        
        // 암호화 알고리즘 설정
        config.setAlgorithm("PBEWITHHMACSHA512ANDAES_256");
        config.setKeyObtentionIterations("1000");
        config.setPoolSize("1");
        config.setProviderName("SunJCE");
        config.setSaltGeneratorClassName("org.jasypt.salt.RandomSaltGenerator");
        config.setIvGeneratorClassName("org.jasypt.iv.RandomIvGenerator");
        config.setStringOutputType("base64");

        encryptor.setConfig(config);
        return encryptor;
    }
}

3. Jasypt 암호화 테스트 (EncryptionTest.java)

Jasypt 암호화 및 복호화가 정상적으로 동작하는지 확인하는 JUnit 테스트 코드를 작성합니다.

@SpringBootTest
public class EncryptionTest {
    
    @BeforeAll
    static void setup() {
        System.setProperty("JASYPT_ENCRYPTOR_PASSWORD", "");
    }
    
    @Test
    public void testEncryption() {
        // 환경 변수에서 암호화 키를 가져옴
        String password = System.getenv("JASYPT_ENCRYPTOR_PASSWORD");
        if (password == null || password.isEmpty()) {
            password = "keystrom";
        }

        // 암호화기 설정
        StringEncryptor encryptor = new JasyptConfig().stringEncryptor();

        // 테스트할 데이터
        String dbUrl = "your-db-url";
        String dbUsername = "your-username";
        String dbPassword = "your-password";

        // 암호화
        String encryptedUrl = encryptor.encrypt(dbUrl);
        String encryptedUsername = encryptor.encrypt(dbUsername);
        String encryptedPassword = encryptor.encrypt(dbPassword);

        // 암호화된 결과 출력
        System.out.println("Encrypted URL: " + encryptedUrl);
        System.out.println("Encrypted Username: " + encryptedUsername);
        System.out.println("Encrypted Password: " + encryptedPassword);

        // 암호화된 값이 null이 아닌지 확인
        assertNotNull(encryptedUrl);
        assertNotNull(encryptedUsername);
        assertNotNull(encryptedPassword);
    }
}

4. IntelliJ 환경 변수 설정

로컬 개발 환경에서 JASYPT_ENCRYPTOR_PASSWORD를 설정하려면 IntelliJ Run/Debug Configurations에서 환경 변수를 추가해야 합니다.

설정 방법

Run/Debug Configurations 창을 엽니다.
실행할 애플리케이션을 선택한 후 Edit Configurations... 클릭
Environment Variables 섹션에서 JASYPT_ENCRYPTOR_PASSWORD=your-secret-key 추가
Apply → OK → 애플리케이션 실행

5. Docker 환경에서 Jasypt 적용

서버에 배포할 때, 환경 변수를 올바르게 설정해야 합니다.

docker-compose.yml에서 설정

version: '3'
services:
  app:
    image: your-image-name
    environment:
      - JASYPT_ENCRYPTOR_PASSWORD=your-secure-password

6. application.yml에서 암호화된 값 사용하기

암호화된 데이터를 application.yml에 저장할 때는 ENC()로 감싸야 합니다.

spring:
  datasource:
    url: ENC(encrypted-db-url)
    username: ENC(encrypted-username)
    password: ENC(encrypted-password)

Jasypt를 활용하면 민감한 정보를 안전하게 관리할 수 있습니다.

개인 서버의 무중단 서버 구축

-JUNHEOK- — Tue, 21 Jan 2025 20:25:15 +0900

안녕하세요. 현재 저의 서버로 구축하고 있는 환경에 관해 설명하고자합니다.
저는 온프레미스(On-premise) 환경에서 Docker Stack 배포하는 docker swarm , 그리고 kuberneter k8s 를 구축한 경험을 가지고 있습니다.

해당 블로그는 Docker Swarm 을 기반으로 온프레미스(On-premise) 환경에서의 죽지 않는 서버 즉, 무중단 서버로 구축을 하였습니다.

서바가 죽지 않는 이유는 Docker Swarm이 제공하는 내재적인 고가용성(High Availability) 및 복구 메커니즘 때문입니다.

아래와 같은 9가지를 적용하며, 구축을 진행했습니다.

서비스 복제(Replication)
오토 힐링(Auto-Healing)
서비스 상태 관리(desired state reconciliation)
리소스 분산 및 로드 밸런싱
리더 선출 및 매니저 노드 복구
노드 장애 복구
재시작 정책(Restart Policy)
NFS와 같은 공유 스토리지의 활용
스케일링 및 롤링 업데이트

1. 서비스 복제(Replication)

deploy:
  replicas: 3

복제(replication) 를 정의할 수 있습니다. 복제본이 항상 정해진 수로 유지되도록 관리하며, 특정 노드나 컨테이너가 장애가 나도 서비스가 지속됩니다.

우선적으로 매니저노드와 워커노드에 관련해서 알아봐야 합니다.
매니저 노드와 워커노드는 서버하나당 지칭을 합니다. 그 중에서 매니저 노드는 리더 선출(Leader Election) 알고리즘을 사용해서 고가용성을 보장합니다.
이 알고리즘은 Raft Consensus를 기반으로 하며, 다음과 같은 특징이 있습니다

클러스터에서 합의(consensus)를 이루기 위해 전체 매니저 노드 중 과반수의 동의가 필요합니다.
과반수는 n/2 + 1의 노드가 필요하므로, 다음과 같은 매니저 노드 구성이 가능합니다.
- 1개 : 단독 운영이 가능하지만 고가용성 불가
- 3개: 1개의 노드가 장애가 나도 과반수 유지 가능(고가용성)
- 5개: 2개의 노드가 장애가 나도 과반수 유지가능(고갸용성 강화)
- 짝수 매니저는 권장되지 않습니다. 과반수를 구성하기 어려운 구조이기 때문입니다.

그렇기 때문에 매니저 노드가 최소 3개여야합니다. 즉 장애 복구 및 리더 선출이 가능합니다. 워커노드는 몇개든지 유연하게 스케일 아웃(Scale-Out)을 할 수 있습니다.
결국 Docker Swarm 클러스터는 스케일 아웃(Scale-Out) 아키텍처로 설계된 오케스트레이션 도구입니다. 스케일 아웃은 수평확장을 통해 시스템의 성능과 가용성을 높이는 방식입니다.

스케일 아웃의 장점

고가용성(HA): 매니저 노드와 워커 노드가 장애를 일으켜도 시스템이 지속적으로 동작.
확장성: 시스템의 요구에 따라 노드를 추가하여 처리량을 유연하게 확장.
비용 효율성: 스케일 업보다 저비용으로 처리량을 증가시킬 수 있음(저가 하드웨어 활용 가능).
부하 분산: 여러 노드에 워크로드를 분산하여 성능을 최적화.

2. 오토 힐링(Auto-Healing)

Docker Swarm은 컨테이너를 지속적으로 모니터링하고, 문제가 발생한 컨테이너를 자동으로 재시작하거나 다른 노드에 재배치합니다.

오토 힐링의 작동 방식:

컨테이너가 중단되거나 비정상적으로 종료되면, Swarm은 즉시 상태를 감지합니다.
Swarm은 장애 컨테이너를 종료하고, 정의된 상태(desired state)를 복구하기 위해 새로운 컨테이너를 배포합니다.

Swarm 오토 힐링 동작

결과적으로 서비스의 가용성을 유지.

deploy:
      replicas: 3
      restart_policy:
        condition: any  # 컨테이너가 어떤 이유로든 종료되면 재시작

또한 아래와 같이 서비스를 업데이트할 때 전략을 세부적으로 제어할수 있습니다.

update_config:
  delay: 15s       ##각 업데이트 작업 간의 대기 시간을 지정
  parallelism: 1  ##한번에 업데이트할 컨테이너(태스크) 수를 지정합니다
  monitor: 10s   ##헬스체크 및 안정성 모니터링 시간을 설정합니다.
  failure_action: rollback  ##업데이트 실패 시 수행할 동작 정의
  max_failure_ratio: 0.55 ##업데이트 실패 허용 비율을 설정합니다.

3. 서비스 상태 관리(desired state reconciliation)

Docker Swarm은 원하는 상태와 현재 상태를 비교해서 클러스터를 관리합니다.

예를 들어, 5개의 복제본이 필요한 서비스에서 1개의 컨테이너가 실패하면 Swarm은 현재 상태를 원하는 상태와 일치시키기 위해 즉시 새 컨테이너를 생성합니다.

4.. 리소스 분산 및 로드 밸런싱

Docker Swarm은 클러스터의 리소스를 최적화하면서 서비스를 실행합니다. 이를 통해 특정 노드가 과부하로 인해 실패하더라도 다른 노드가 이를 처리할 수 있습니다.

내장 로드 밸런서: Swarm은 서비스의 요청을 복제본 간에 분산합니다. 사용자는 단일 VIP(Virtual IP) 또는 DNS 이름을 통해 서비스를 호출하며, Swarm은 이를 적절히 라우팅합니다.

5. 리더 선출 및 매니저 노드 복구

Swarm 클러스터는 매니저 노드의 고가용성을 보장하기 위해 리더 선출(Leader Election) 알고리즘을 사용합니다.

매니저 노드가 여러 개일 경우, 한 노드가 장애가 나도 다른 매니저가 리더로 선출되어 클러스터를 계속 운영합니다.
장애가 난 매니저 노드를 복구하거나 새로운 노드를 추가하면 자동으로 클러스터에 다시 합류됩니다.

6. 노드 장애 복구

Docker Swarm은 노드의 상태를 지속적으로 모니터링합니다.

만약 워커 노드가 장애를 일으키면 Swarm은 해당 노드에서 실행되던 모든 서비스를 다른 가용 노드에 재배치합니다.

7. 재시작 정책(Restart Policy)

스택 배포 시, 각 서비스에 재시작 정책(restart policy)을 설정할 수 있습니다. 이는 컨테이너의 실패를 감지하고 자동으로 재시작하게 만듭니다.

deploy:
  restart_policy:
    condition: on-failure ##컨테이너가 오류로 종료되었을때만 재시작.

8. NFS와 같은 공유 스토리지의 활용

Docker Swarm에서 NFS와 같은 공유 스토리지를 사용하면, 서비스 데이터가 노드 간에 공유되므로 특정 노드 장애가 발생해도 데이터 손실 없이 다른 노드에서 서비스를 계속 실행할 수 있습니다.

해당 서버같은 경우는 NFS ( network file system) 서버를 구축한 후 마운팅을 진행하여 데이터 손실없이 다른 노드 서비스에서도 실행할 수 있게 구축을 진행했습니다.

9.스케일링 및 롤링 업데이트

Docker Swarm은 서비스를 동적으로 스케일링하거나 롤링 업데이트를 지원합니다. 이를 통해 서비스 중단 없이 애플리케이션을 업데이트하거나 확장할 수 있습니다.

결론: Docker Swarm으로 구축한 서버가 죽지 않는 이유

Docker Swarm은 클러스터의 서비스 상태를 지속적으로 모니터링하고, 컨테이너와 노드의 장애에 대해 자동으로 복구 작업을 수행합니다. 또한, 리소스 분산, 복제, 오토 힐링, 재시작 정책, 리더 선출 등 여러 고가용성 메커니즘을 통해 장애 상황에서도 서비스 중단을 최소화합니다.

[Elasticsearch] ELK 이슈 해결 - Kibana server is not ready yet

-JUNHEOK- — Wed, 20 Nov 2024 00:45:00 +0900

이번 글에서는 Docker Swarm 환경에서 ELK(Elasticsearch, Logstash, Kibana) 스택을 설치하고, Kibana 접속 시 자주 발생하는 문제인 'Kibana server is not ready yet'를 해결한 경험을 공유하고자 합니다.

1. Docker Swarm에서 ELK 스택 설치

ELK 스택은 로그 수집, 분석, 시각화에 널리 사용되는 도구입니다. 아래는 제가 사용한 docker-compose.yml 설정입니다.

ELK 스택 구성 파일

version: '3.9'

networks:
  elk:
    driver: overlay

volumes:
  elk-data:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /volumes/elk

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.10.2-arm64
    ports:
      - "9200:9200"
      - "9300:9300"
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - network.host=0.0.0.0
      - xpack.license.self_generated.type=trial
    volumes:
      - elk-data:/usr/share/elasticsearch/data
    networks:
      - elk
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.elasticsearch.rule=Host(`ex.domain`)"
        - "traefik.http.services.elasticsearch.loadbalancer.server.port=9200"
        - "traefik.http.routers.elasticsearch.entrypoints=websecure"
        - "traefik.http.routers.elasticsearch.tls=true"
        - "traefik.http.routers.elasticsearch.tls.certresolver=letsencrypt"

  kibana:
    image: docker.elastic.co/kibana/kibana:8.10.2-arm64
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - "5601:5601"
    networks:
      - elk
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.kibana.rule=Host(`ex.domain`)"
        - "traefik.http.services.kibana.loadbalancer.server.port=5601"
        - "traefik.http.routers.kibana.entrypoints=websecure"
        - "traefik.http.routers.kibana.tls=true"
        - "traefik.http.routers.kibana.tls.certresolver=letsencrypt"

2. Kibana 오류: 'Kibana server is not ready yet'

설치 후 브라우저에서 https://kibana.keystrom.site에 접속했을 때, 다음 오류를 만났습니다.

Kibana server is not ready yet

이 오류는 Elasticsearch와 Kibana 간 연결이 원활하지 않거나 설정에 문제가 있을 때 발생합니다.

3. 문제 원인과 해결 방법

문제 원인

Elasticsearch 연결 설정 문제
- Kibana가 Elasticsearch에 올바르게 연결되지 못했을 가능성.
- ELASTICSEARCH_HOSTS 환경 변수가 잘못된 값을 참조하고 있었습니다.
추가 호스트 설정 문제
- extra_hosts로 Elasticsearch IP를 강제로 맵핑하여 Docker 네트워크 해석이 충돌할 수 있었습니다.

extra_hosts:
  - "elasticsearch:10.0.25.14"

이 설정은 Docker Swarm 기반으로 Traefik과 ELK 스택의 통합을 목표로 하고 있습니다. 주요 문제는 Kibana와 Elasticsearch 간의 연결 문제입니다. 최종 연결 테스트를 진행하였습니다.

Kibana 서비스와 Elasticsearch 연결 테스트

1. Elasticsearch 연결 확인

Docker Swarm 노드에서 Elasticsearch 서비스가 정상적으로 응답하는지 테스트합니다.

curl -X GET http://elasticsearch:9200

정상 응답 시: Kibana와 연결 가능
오류 발생 시: Docker 네트워크 설정을 점검하세요.

2 Kibana 로그 확인

Kibana 서비스의 로그를 확인하여 추가적인 오류 메시지를 파악합니다.

docker service logs kibana --follow

개인 서버에서 Elasticsearch와 Kibana를 Docker Swarm 클러스터 환경에서 구축했습니다.

rabbitmq[5] RabbitMQ 관리 플러그인 사용법 정리

-JUNHEOK- — Tue, 19 Nov 2024 22:21:17 +0900

RabbitMQ 관리 플러그인은 RabbitMQ의 동작을 직관적으로 이해하고 관리할 수 있도록 돕는 도구입니다.

Docker를 사용해 RabbitMQ를 설치했다면, 기본적으로 이 플러그인은 활성화되며 포트 15672에서 작동합니다.

이전 게시물에 Docker 에서 RabbitMQ를 설치하였습니다.

https://float.tistory.com/313

rabbitmq[4] Docker를 사용하여 RabbitMQ를 설치하고 설정하는 방법

Docker를 사용하여 RabbitMQ를 설치하고 설정하는 방법 Docker Stack을 사용하여 RabbitMQ를 설치 및 설정하는 방법을 소개합니다. RabbitMQ는 Windows, Linux, macOS 등 다양한 환경에서 설치가 가능하지만,

float.tistory.com

RabbitMQ 관리 플러그인을 활용하여 큐와 교환기(Exchange)를 생성하고 바인딩하는 과정을 정리한 내용입니다.

1. RabbitMQ 관리 플러그인 접속

로그인하면 RabbitMQ 관리 플러그인의 대시보드 화면이 표시됩니다.

2. 주요 메뉴 소개

Connections: RabbitMQ 서버와 연결된 TCP 연결 정보를 확인할 수 있습니다.
Channels: 메시지가 송수신되는 채널 정보를 확인할 수 있습니다.
Exchanges: 메시지를 큐로 전달하기 위한 교환기를 관리합니다.
Queues: 메시지를 저장하고 소비자(Consumer)가 가져가는 큐를 관리합니다.

3. Exchange 생성

Exchanges 탭 클릭 → Add a new exchange 버튼 클릭
설정값 입력:
- Exchange 이름: exchange_demo
- 유형: Direct (기본값)
- 나머지 값은 기본값 유지.
Add exchange 클릭 → exchange_demo 교환기가 생성됩니다.

4. Queue 생성

Queues 탭 클릭 → Add a new queue 버튼 클릭.
설정값 입력:
- Queue 이름: queue_demo
- 나머지 값은 기본값 유지.
Add queue 클릭 → queue_demo 큐가 생성됩니다.

5. Exchange와 Queue 바인딩

Exchanges 탭으로 이동 → exchange_demo 클릭.
Add binding from this exchange to queue 섹션에서 아래 값 입력:
- Queue 이름: queue_demo
- Routing Key: routing_key_demo
Bind 버튼 클릭 → exchange_demo와 queue_demo가 routing_key_demo를 통해 바인딩됩니다.

6. 메시지 전송 및 확인

1. Exchanges 탭 → exchange_demo 클릭.

2. Publish message 섹션에서 아래 값 입력:

Routing Key: routing_key_demo
Payload: 전송할 메시지, 예: hello word

3.Publish message 버튼 클릭 → 메시지가 전송됩니다.

4. Queues 탭 → queue_demo 클릭 → Get messages 버튼 클릭:

큐에 도착한 메시지를 확인할 수 있습니다. 예: hello word.

7. RabbitMQ 메시지 흐름

프로듀서(Producer): 메시지와 Routing Key를 Exchange로 전송.
Exchange: Routing Key를 사용해 적합한 큐로 메시지 전달.
큐(Queue): 메시지를 저장, 소비자가 가져가도록 대기.

RabbitMQ 관리 플러그인을 사용하면 큐와 교환기의 생성, 메시지 전송 및 흐름을 간편하게 확인하고 관리할 수 있습니다.

Docker Compose에서 Volume을 정의하는 이유

-JUNHEOK- — Mon, 18 Nov 2024 23:45:18 +0900

Docker Compose 파일에서 Volume(볼륨)을 정의하는 것은 컨테이너의 데이터를 영구적으로 저장하거나 호스트 시스템과 공유하기 위해 매우 중요합니다.
볼륨을 정의하지 않으면, 컨테이너가 삭제되거나 재시작될 때 모든 데이터가 사라질 위험이 있습니다. 아래에서는 볼륨을 사용하는 주요 이유를 설명합니다.

본 글은 아래 게시물에서 이어집니다.

https://float.tistory.com/313

rabbitmq[4] Docker를 사용하여 RabbitMQ를 설치하고 설정하는 방법

float.tistory.com

1. 데이터 영속성 유지

컨테이너 내부에 저장된 데이터는 기본적으로 **비영속적(temporary)**입니다. 컨테이너를 삭제하거나 재배포하면 해당 데이터는 손실됩니다.
이를 방지하기 위해 Volume을 사용하면 컨테이너 외부에 데이터를 저장할 수 있습니다.

예시: RabbitMQ 데이터 영속성
RabbitMQ는 메시지 큐 시스템으로, 처리된 메시지와 큐 상태를 유지해야 합니다. 볼륨을 정의하여 데이터를 컨테이너 외부에 저장함으로써 다음과 같은 상황에서도 데이터가 유지됩니다:

컨테이너가 삭제된 경우
컨테이너를 업데이트하거나 재시작한 경우

2. 호스트 시스템과 데이터 공유

볼륨을 통해 호스트 시스템의 디렉토리를 컨테이너와 연결할 수 있습니다.
이는 데이터를 관리하거나 백업하는 데 편리하며, 데이터를 직접 수정하거나 읽어야 할 경우 유용합니다.

예시: YAML에서 볼륨 정의

volumes:
  rabbitmq-data:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /volumes/rabbitMq

device: 호스트 시스템에서 실제 데이터를 저장할 디렉토리(/volumes/rabbitMq)를 지정합니다.
o: bind: 호스트 디렉토리를 컨테이너의 데이터 디렉토리(/var/lib/rabbitmq)와 연결합니다.

이 설정을 통해 RabbitMQ 컨테이너에서 발생하는 데이터가 /volumes/rabbitMq에 영구적으로 저장됩니다.
호스트 디렉토리에 접근해 데이터를 직접 확인하거나 백업할 수 있는 이점이 있습니다.

4. 데이터 백업 및 복구 용이

볼륨에 데이터를 저장하면, 호스트 시스템에 저장된 디렉토리를 통해 데이터 백업과 복구가 쉬워집니다.
이러한 설정은 RabbitMQ의 중요 메시지 데이터와 큐 상태를 안전하게 관리하는 데 필수적입니다.

5. 컨테이너와 애플리케이션의 독립성 보장

볼륨을 사용하면 애플리케이션 데이터와 컨테이너를 분리하여, 컨테이너를 삭제하거나 재배포해도 데이터가 영향을 받지 않습니다.
이로 인해 애플리케이션 업데이트, 롤백, 재배포 등의 작업이 훨씬 간단하고 안전해집니다.

6. 퍼포먼스 향상

Docker 볼륨은 호스트 시스템의 파일 공유 메커니즘을 활용하여 파일 읽기/쓰기 속도를 최적화합니다.
특히 bind mount 대신 Docker 네이티브 볼륨 드라이버를 사용하면, IO 성능이 더 좋아질 수 있습니다.

요약: RabbitMQ와 볼륨의 중요성

RabbitMQ와 같은 메시지 브로커는 데이터 무결성과 영속성이 매우 중요합니다.
Docker Compose에서 볼륨을 정의하면 아래의 장점이 있습니다:

데이터 손실 방지
컨테이너 업데이트 시 데이터 유지
호스트 시스템과 데이터 공유
백업 및 복구 용이
안정적인 서비스 운영 보장

RabbitMQ 설치 시, 데이터 저장 경로(/var/lib/rabbitmq)를 반드시 볼륨으로 마운트하는 것이 권장됩니다.
이를 통해 RabbitMQ의 메시지 데이터가 안전하게 관리되고, 서비스의 안정성과 신뢰성을 높일 수 있습니다.

https://float.tistory.com/312

RabbitMQ 목차

1. RabbitMQ와 메시지 큐의 이해 https://float.tistory.com/309 RabbitMQ[1] RabbitMQ와 메시지 큐의 이해: 마이크로서비스를 위한 비동기 통신RabbitMQ와 **메시지 큐(Message Queue)**에 대해 알아보고, 마이크로서비

float.tistory.com

rabbitmq[4] Docker를 사용하여 RabbitMQ를 설치하고 설정하는 방법

-JUNHEOK- — Mon, 18 Nov 2024 23:43:09 +0900

Docker를 사용하여 RabbitMQ를 설치하고 설정하는 방법

Docker Stack을 사용하여 RabbitMQ를 설치 및 설정하는 방법을 소개합니다. RabbitMQ는 Windows, Linux, macOS 등 다양한 환경에서 설치가 가능하지만, 저는 Linux 환경에서 Docker Stack를 활용해 설정을 진행했습니다.

아래에서는 RabbitMQ를 Docker Swarm 환경에서 YAML 파일을 이용해 설치하고, Traefik으로 라우팅을 설정하는 방법을 상세히 설명합니다.

1. Docker Network 생성

다음 명령어를 사용하여 네트워크를 생성합니다

docker network create --driver overlay --attachable rabbotmq-network

--driver overlay: Docker Swarm에서 여러 호스트 간 네트워크를 연결하기 위해 Overlay 네트워크를 사용합니다.
--attachable: 컨테이너가 실행 중에 이 네트워크에 연결 가능하도록 설정합니다.

2. docker-rabbitmq.yml 파일 구성

아래는 RabbitMQ를 설정하기 위한 YAML 파일입니다.

version: '3.9'

networks:
  traefik-network:
    external: true
  rabbitmq-network:
    driver: overlay

volumes:
  rabbitmq-data:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /volumes/rabbitMq


services:
  rabbitmq-onlyoffice-document:
    image: rabbitmq:management
    volumes:
      - rabbitmq-data:/var/lib/rabbitmq
    environment:
      RABBITMQ_DEFAULT_USER: 
      RABBITMQ_DEFAULT_PASS: 
    networks:
      - traefik-network
      - onlyoffice-network
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 10s
      timeout: 5s
      retries: 3
    deploy:
      mode: replicated
      replicas: 1
      placement:
        constraints:
          - node.hostname == master
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.rabbit.rule=Host(`ex.domain`)"
        - "traefik.http.routers.rabbit.service=rabbit"
        - "traefik.http.services.rabbit.loadbalancer.server.port=15672"
        - "traefik.http.routers.rabbit.entrypoints=websecure"
        - "traefik.http.routers.rabbit.tls.certresolver=letsencrypt"
        - "traefik.http.routers.rabbit.tls=true"
        - "traefik.http.services.rabbit.loadbalancer.passhostheader=true"
        - "traefik.http.routers.rabbit.middlewares=compresstraefik"

        # RabbitMQ Broker (TCP)
        - "traefik.tcp.routers.rabbitmq-broker.rule=HostSNI(`ex.domain`)"
        - "traefik.tcp.routers.rabbitmq-broker.entrypoints=amqps"
        - "traefik.tcp.services.rabbitmq-broker.loadbalancer.server.port=5672"
        - "traefik.tcp.routers.rabbitmq-broker.tls=true"  # Enable TLS for TCP router

구성 요소 설명

네트워크 설정

traefik-network: 외부에서 접근 가능한 네트워크. Traefik을 통해 라우팅됩니다.
rabbitmq-network: RabbitMQ와 관련된 내부 네트워크.

볼륨 설정

rabbitmq-data: RabbitMQ 데이터를 저장하기 위한 볼륨입니다.
driver_opts를 통해 로컬 경로(/volumes/rabbitMq)를 마운트했습니다.
volume 을 사용하는 이유는 아래 블로그에 정리되어 있습니다.

Docker Compose에서 Volume을 정의하는 이유

Docker Compose 파일에서 Volume(볼륨)을 정의하는 것은 컨테이너의 데이터를 영구적으로 저장하거나 호스트 시스템과 공유하기 위해 매우 중요합니다.볼륨을 정의하지 않으면, 컨테이너가 삭제되거

float.tistory.com

서비스 설정

image: RabbitMQ 관리 플러그인이 포함된 공식 Docker 이미지(rabbitmq:management)를 사용합니다.
environment: RabbitMQ 초기 관리자 계정과 비밀번호를 설정합니다.
healthcheck: RabbitMQ의 상태를 주기적으로 확인합니다.
deploy:
- replicas: 컨테이너 복제본 수를 1개로 설정합니다.
- constraints: master 호스트에서만 실행되도록 제한합니다.

Traefik 설정

HTTP 라우터: rabbitmq.keystrom.site 도메인으로 RabbitMQ 관리 웹사이트(포트 15672)에 접근합니다.
TCP 라우터: RabbitMQ 브로커(포트 5672)로 TLS를 사용해 안전한 연결을 제공합니다.

3. YAML 파일 배포

다음 명령어를 사용하여 YAML 파일을 배포합니다.

docker stack deploy -c docker-rabbitmq.yml rabbitmq

-c docker-rabbitmq.yml: YAML 파일 지정
rabbitmq: 배포 스택 이름

https://float.tistory.com/315

rabbitmq[5] RabbitMQ 관리 플러그인 사용법 정리

RabbitMQ 관리 플러그인은 RabbitMQ의 동작을 직관적으로 이해하고 관리할 수 있도록 돕는 도구입니다.Docker를 사용해 RabbitMQ를 설치했다면, 기본적으로 이 플러그인은 활성화되며 포트 15672에서 작동

float.tistory.com

RabbitMQ 목차

-JUNHEOK- — Mon, 18 Nov 2024 11:46:03 +0900

1. RabbitMQ와 메시지 큐의 이해

https://float.tistory.com/309

RabbitMQ[1] RabbitMQ와 메시지 큐의 이해: 마이크로서비스를 위한 비동기 통신

RabbitMQ와 **메시지 큐(Message Queue)**에 대해 알아보고, 마이크로서비스 아키텍처에서 어떻게 활용되는지 공부 및 정리한 내용입니다. RabbitMQ를 이해하기 전에, 먼저 메시지 큐가 무엇인지 간단히

float.tistory.com

2. RabbitMQ의 핵심 개념

https://float.tistory.com/310

RabbitMQ[2] RabbitMQ의 핵심 개념

Producer (생산자)Producer는 메시지를 전송하는 애플리케이션입니다.Producer는 Consumer(소비자)에게 직접 메시지를 보내지 않습니다.대신, 메시지를 RabbitMQ 브로커로 전송합니다.Producer는 메시지를 Rabbi

float.tistory.com

3. RabbitMQ의 아키텍처

https://float.tistory.com/311

RabbitMQ[3] RabbitMQ 아키텍처

일반적인 메시징 시스템 아키텍처우선, 일반적인 메시징 시스템 아키텍처를 살펴봅시다. Producer(생산자): 메시지를 생성하고 보냅니다.Consumer(소비자): 메시지를 읽어들이고 처리합니다.Message

float.tistory.com

4. Docker를 사용하여 RabbitMQ를 설치하고 설정하는 방법

https://float.tistory.com/313

rabbitmq[4] Docker를 사용하여 RabbitMQ를 설치하고 설정하는 방법

float.tistory.com

5. RabbitMQ 관리 플러그인 사용법 정리

https://float.tistory.com/315

rabbitmq[5] RabbitMQ 관리 플러그인 사용법 정리

float.tistory.com

RabbitMQ[3] RabbitMQ 아키텍처

-JUNHEOK- — Mon, 18 Nov 2024 11:43:50 +0900

일반적인 메시징 시스템 아키텍처

우선, 일반적인 메시징 시스템 아키텍처를 살펴봅시다.

Producer(생산자): 메시지를 생성하고 보냅니다.
Consumer(소비자): 메시지를 읽어들이고 처리합니다.
Message Broker(메시지 브로커): Producer와 Consumer 사이에서 메시지를 중계합니다.

흐름: Producer는 메시지를 브로커로 보내고, Consumer는 브로커에서 메시지를 읽습니다.
이것이 일반적인 메시징 시스템의 구조입니다.

RabbitMQ 메시징 시스템 아키텍처

RabbitMQ 아키텍처에서는 위 구조에 추가적으로 Exchange(교환기)라는 컴포넌트가 있습니다.
RabbitMQ의 흐름은 다음과 같습니다

Producer가 메시지를 Exchange에 보냅니다.
Exchange는 메시지를 적절한 Queue(큐)로 라우팅합니다.
Consumer는 해당 Queue에서 메시지를 읽어 처리합니다.

기본 구조는 간단하지만, 복잡한 애플리케이션에서는 여러 개의 큐를 생성해야 할 수 있습니다.

RabbitMQ 아키텍처(다중 큐)

RabbitMQ에서 여러 큐를 사용하는 아키텍처는 아래와 같은 구조를 가집니다:

Producer는 Exchange에 메시지를 보냅니다.
Exchange는 Routing Key(라우팅 키)를 사용해 메시지를 적절한 큐로 라우팅합니다.
Consumer는 각각의 큐에서 메시지를 읽어 처리합니다.

중요 포인트: Exchange는 RabbitMQ 아키텍처에서 핵심적인 역할을 하며, 메시지를 올바른 큐로 라우팅합니다.

예시: RabbitMQ 아키텍처 동작 원리

예제를 통해 동작 방식을 살펴봅시다.
RabbitMQ 아키텍처에 Queue1, Queue2, Queue3가 있다고 가정해 보겠습니다.

메시지를 Queue3으로 보내기

Producer는 Routing Key: 3을 포함한 메시지를 Exchange에 보냅니다.
Exchange는 이 Routing Key: 3을 확인하고 메시지를 Queue3으로 라우팅합니다.

메시지를 Queue1으로 보내기

Producer는 Routing Key: 1을 포함한 메시지를 Exchange에 보냅니다.
Exchange는 Routing Key: 1을 확인하고 메시지를 Queue1으로 라우팅합니다.

Binding(바인딩):
Exchange와 Queue 간의 연결(바인딩)은 Routing Key를 통해 설정됩니다.
이 연결이 있어야 Exchange가 메시지를 올바른 Queue로 라우팅할 수 있습니다.