dev.j

Ceph 장애가 발생했을 때, 왜 BE가 느려졌을까?

:j — Tue, 31 Mar 2026 20:49:40 +0900

Ceph 클러스터 장애가 발생했을 때,BE가 계속 retry를 하면서 오히려 응답이 더 느려지고 있었습니다.

배경

현재 Ceph API를 활용해서 Ceph 데이터를 서빙하는 백엔드를 개발하고 있습니다.

FE → G/W → BE → Ceph MGR API (Active-Standby 구조)

서비스 흐름 자체는 단순한데, Ceph의 Active-Standby 구조 때문에

303 Redirect, Fallback, Retry, Active MGR 갱신 같은 걸 전부 BE에서 직접 처리하고 있었습니다.

평소에는 별 문제 없이 돌아갔는데, Ceph 장애 상황에서는 다음과 같은 문제가 발생했습니다.

평균 응답 시간이 1.15초까지 증가
redirect → retry → host 순회 → 재귀 호출 구조
장애 원인 파악이 어려움(인프라 문제인지, Ceph 문제인지, BE 문제인지)
코드 복잡도 증가 및 유지보수 비용 상승

처음에는 "성능 최적화 문제겠지" 하고 단순하게 생각했습니다. 재시도 로직을 좀 더 정교하게 만들면 되지 않을까?

근데 장애 상황을 재현해보면서 생각이 바뀌었습니다.

이 문제의 본질은 성능이나 재시도 로직이 아니라, "장애 처리 책임이 잘못된 레이어에 있었다"는 점이었습니다.

Active MGR 선택, Failover, Health Check — 이건 인프라가 해야 하는 일입니다.

그때부터 이 문제를 단순 리팩토링이 아닌 구조적 재설계 문제로 다시 정의했습니다.

1단계: 측정 가능한 상태 만들기

예상치 못한 발견

구조를 개선하기 전에, 먼저 기존 구조가 장애 상황에서 실제로 어떻게 동작하는지 측정해야 했습니다.

k6로 부하 테스트를 구성해서 두 가지를 비교했습니다. (Ceph 클러스터 장애 상황 기준)

기존 로직 (redirect → retry → host 순회)
redirect 및 fallback 제거 후 단순 호출

그런데 테스트를 돌리자 예상과 전혀 다른 결과가 나왔습니다.

장애를 측정하려 했는데 측정 자체가 불가능한 상태였습니다.

원인을 분석해보니 Thundering Herd 문제가 숨어있었습니다.

동일 Provider에 동시 요청 → 인증 토큰 발급 API가 요청 수만큼 중복 호출
토큰 캐시 덮어쓰기
Active MGR 갱신 이벤트가 중복 발행 → DB Optimistic Lock 충돌

BE 내부가 안정적이지 않으면 인프라 구조 개선의 효과를 검증할 수 없는 상태였습니다.

Single-flight 패턴 도입

우선 측정 가능한 상태를 만드는 게 첫 번째라고 판단했습니다.

처음에는 synchronized나 ReentrantLock으로 토큰 발급 구간을 순차 실행하는 방식을 검토했습니다.
근데 락 내부에서 외부 HTTP 호출이 수행되는 구조다 보니, 응답이 지연되면 모든 요청이 임계 구역 앞에서 줄을 서게 됩니다.

동시성 제어가 아니라 병목을 만드는 방식이었습니다.

그래서 Redis 기반 분산 락을 검토했습니다. 멀티 인스턴스 환경이니까 당연히 떠오르는 선택지였는데, 설계를 구체화하다 보니 고민이 생겼습니다.

Redis 추가 네트워크 왕복
락 타임아웃 및 실패 처리 로직
락 보유 인스턴스 장애 시 복구 설계

문제를 해결하려고 또 하나의 장애 지점을 추가하는 꼴이었습니다.

여기서 한 가지 기준이 생겼습니다.

"이 토큰 발급 과정에서 정말 모든 인스턴스 사이에 완벽한 상호배제가 필요할까?"

실제 운영 환경에는 약 3개의 인스턴스가 돌고 있습니다.
분산 락 없이 최악의 상황에서도 동시 중복 호출은 최대 3회입니다.
토큰은 Redis에 TTL 15분으로 캐시되고 대부분의 요청은 캐시 히트로 처리됩니다.

문제가 되는 구간은 토큰 만료 직후의 매우 짧은 순간뿐이었습니다.

Ceph 인증 API는 JWT 기반의 stateless 구조라서, 반복 호출해도 클러스터 상태를 변경하지 않습니다.
중복 호출은 기능적 부작용 없이 외부 API 부하만 일시적으로 증가시키는 형태였습니다.

"복잡하게 해결하기보다, 지금 시스템에 맞는 수준에서 단순하게 해결"

분산 락으로 시스템 복잡도를 올리는 것보다, 인스턴스 내부에서만 동시 요청 제어만으로 충분하다고 생각해서,

Single-flight 패턴 을 적용했습니다.

getOrIssueToken()
├─ Redis 캐시 조회 (Cache Hit 시 즉시 반환)
├─ cache miss
│
├─ inFlight.computeIfAbsent(providerId)
│ └─ VirtualThreadExecutor.supplyAsync()
│   └─ issuer.call() ← Ceph /api/auth
│
├─ 다른 요청 → future.join() (가상 스레드 파킹 후 결과만 공유)
└─ 결과 반환

첫 요청만 외부 호출을 수행하고, 나머지 요청은 그 결과를 공유합니다.

완벽한 상호배제는 아니지만, 실질적 중복 호출은 대부분 제거 가능하고 추가 인프라 의존성도 없습니다.

결과적으로:

토큰 발급 API 호출 중복 제거 (N → 1 수준으로 수렴)
DB Lock 경합 해소
신뢰할 수 있는 테스트 환경 확보

Single-flight를 먼저 도입해서 "측정 가능한 상태"를 만든 것이 이후 모든 개선의 시작점이 되었습니다.

2단계: 인프라 책임 분리 (HAProxy + VIP)

BE 내부를 안정화한 뒤, 이제 진짜 궁금했던 걸 측정할 수 있게 됐습니다.

동일한 장애 상황(Ceph Cluster Down)에서 비교해봤습니다.

구분	평균 응답 시간
기존 로직 (redirect → retry → host 순회)	1,150ms
redirect 및 fallback 제거 후 단순 호출	7.2ms

1,150ms → 7.2ms. 160배 차이.

이 수치를 보고 확신이 들었습니다. 문제는 "재시도를 어떻게 잘 할 것인가"가 아니라, "이 로직들이 애초에 BE의 책임인가"였습니다.

기존 BE는 Active MGR 선택, StandBy 판단, 장애 감지와 Fallback까지 전부 직접 하고 있었습니다.
장애가 발생하면 BE 내부 로직이 복잡하게 얽히면서 원인 분리도 안 되고, 레이턴시만 올라갔습니다.

"장애를 더 잘 처리하는 코드보다, 장애가 BE로 전파되지 않도록 경계를 명확히 하는 게 더 중요하다"

그래서 BE가 더이상 MGR 선택과 장애 판단을 직접 하지 않도록, Ceph Cluster 앞에 Reverse Proxy를 두고 BE는 항상 단일 진입점(VIP)만 호출하는 구조로 바꿨습니다.

Reverse Proxy로 Nginx도 가능했지만, HAProxy + Keepalived를 선택했습니다.

Ceph 공식 문서가 MGR HA 구성의 표준으로 제시하는 조합이었고, 검증된 아키텍처를 따르는 게 장애 대응과 협업 측면에서 리스크가 낮다고 판단했습니다.

HAProxy 책임:

Active MGR 선택 (Health Check 기반)
StandBy / Down MGR 자동 제외
BE는 VIP만 호출

BE에서 제거된 로직:

303 Redirect 파싱
Host 순차 Fallback
재귀적 재시도
Active MGR 갱신 이벤트

BE에 남긴 최소 책임:

401 Unauthorized → Single-flight 기반 토큰 갱신 1회 재시도
그 외 timeout / 5xx → Fast-Fail

정리하면:

가용성 판단 → 인프라 책임
인증 관리 → 애플리케이션 책임

코드는 더 단순해졌고, 장애 원인은 명확히 분리됐습니다. 그리고 가장 중요한 건 시스템이 예측 가능해졌다는 점입니다.

3단계: 애플리케이션 회복력 (Resilience4j)

HAProxy 도입으로 MGR 선택과 장애 차단은 인프라로 넘겼습니다. BE는 이제 "어디로 요청을 보낼지"를 고민하지 않아도 됩니다.

근데 여전히 남은 문제가 있었습니다. "실패를 애플리케이션이 어떤 규칙으로 다룰 것인가"에 대한 정책이 없었습니다.

어떤 오류는 재시도해야 하고, 어떤 오류는 즉시 실패해야 하고, 어떤 장애는 공급자 단위로 격리되어야 했습니다.

인프라가 '빠른 실패'를 가능하게 만들었으니, 이제 애플리케이션은 실패에 어떻게 반응할지를 명시적으로 가져야 했습니다.

왜 Resilience4j인가

옵션	검토 결과
Spring Retry	CB/Bulkhead 미지원
Hystrix	2018년 deprecated
Resilience4j	경량, 모듈형, 설정 외부화

Spring Boot 3 환경에서 공식 지원되고, 설정 외부화와 메트릭 연동이 용이해서 선택했습니다.

필요한 만큼만, 하지만 확장 가능하게

도입하지 않은 패턴들도 있습니다. 현재 장애 패턴과 트래픽 특성에서 실질적 효용이 낮았기 때문입니다.

Bulkhead: CB OPEN 시 FE가 이미 차단 → 스레드 고갈 위험 낮음
RateLimiter: 내부망 환경으로 트래픽이 낮으며, Ceph에는 Rate Limit 없음
TimeLimiter: 동기 호출이라 RestClient 타임아웃으로 충분

최종적으로 필요한 건 Retry + CircuitBreaker 두 가지였습니다.

설계

실행 순서: CB( Retry( Supplier ) )
- Retry 먼저: 일시적 오류(502, 503) 복구 시도
- CB 나중: Retry까지 실패한 "최종 결과"만 실패율 반영
- 반대면? Retry 시도마다 CB 카운트 → 성급한 OPEN

resilience4j:
  retry:
    retryExceptions:
      - BadGateway          # 502: HAProxy 일시 오류 (재시도 가능)
      - ServiceUnavailable  # 503: MGR 준비 안 됨 (재시도 가능)
    ignoreExceptions:
      - InternalServerError # 500: Ceph 로직 오류 (재시도 무의미)

  circuitbreaker:
    ignoreExceptions:
      - InvalidCredentialsException  # 인증 오류 ≠ 시스템 장애

Provider별 격리

String key = "ceph-" + providerUuid;  // 클러스터마다 독립 CB

Supplier<T> decoratedSupplier = Retry.decorateSupplier(retry, supplier);
decoratedSupplier = CircuitBreaker.decorateSupplier(circuitBreaker, decoratedSupplier);
return decoratedSupplier.get();

Cluster A 장애 → A의 CB만 OPEN → B, C 정상 동작.

테스트 코드 작성

Resilience4j를 도입하면서 한 가지 의문이 들었습니다.

"application.yml의 설정값들이 실제 장애 상황에서 100% 의도대로 동작할까?"

설정이 복잡해질수록 런타임 동작은 예측 불가능해집니다.

그래서 장애 시나리오를 기반으로 테스트 코드로 직접 증명했습니다.

@Test
@DisplayName("InvalidCredentialsException 은 CircuitBreaker 실패로 기록되지 않는다")
void circuitBreakerIgnoreInvalidCredentialsException() {
    for (int i = 0; i < 10; i++) {
        assertThrows(InvalidCredentialsException.class, ...);
    }
    // CB는 여전히 CLOSED (의도한 동작)
    assertThat(cb.getState()).isEqualTo(CLOSED);
}

결과

구조 변경만으로 장애 상황에서 다음과 같은 개선을 얻을 수 있었습니다.

Before

After

항목	개선 전	개선 후
평균 응답시간	5.04s	36.5ms
P95 레이턴시	10.03s	78ms
dropped_iterations	989	11
최대 VUs	50 (max 도달)	16
장애 클러스터 fast-fail	불가	98~99% (100ms 이내)
CB 상태 모니터링	불가능	Actuator 실시간 조회

이 수치는 정상 상황의 성능 향상이 아니라, 장애 상황에서의 회복 탄력성 차이입니다.

전체 여정 요약

"장애를 어떻게 처리할지가 아니라, 누가, 어느 레이어에서 책임질 것인가"

1단계: 측정 가능한 상태 만들기 (Single-flight)
├─ BE 내부 동시성 문제 제거
├─ 토큰 재발급 Thundering Herd 해소
└─ 성과: 신뢰 가능한 장애 테스트 환경 확보

2단계: 인프라 책임 분리 (HAProxy + VIP)
├─ MGR 선택 / Failover → 인프라로 위임
├─ Fast-Fail → 장애 전파 차단
└─ 성과: 평균 응답 160배 개선 (1,150ms → 7.2ms)

3단계: 애플리케이션 회복력 (Resilience4j)
├─ Provider별 CircuitBreaker → 클러스터 격리
├─ 정밀 Retry 정책 → 불필요한 재시도 제거
└─ 성과: 장애 격리 + 실시간 관찰 가능성 확보

회고

문제 정의의 재발견

시작은 팀내 FE 개발자분이 "API 응답 속도가 너무 느리다"고 알려준 것이었습니다.

확인해보니 Ceph 클러스터 장애로 실제 API 통신이 불가능한 상황이었는데, BE는 매 요청마다 Ceph로 다시 시도하며 에러를 반환하고 있었습니다. 장애가 발생한 클러스터로의 요청이 계속 시스템 내부로 유입되면서 레이턴시와 리소스 점유가 누적되고 있었습니다.

그때까지 저는 이 문제를 "이 로직들을 어떻게 개선할까?"라는 How의 문제로만 보고 있었습니다.

근데 구조를 뜯어볼수록 의문이 들었습니다.

"왜 이걸 BE에서 다 처리하고 있지?", "이 책임들은 인프라가 가져야 하는 거 아닌가?"

그 순간 문제가 다르게 보였습니다. 단순한 성능 최적화가 아니라 책임을 다시 배치해야 하는 설계 문제였습니다.

복잡한 설정은 검증되지 않은 코드와 같다

Resilience4j 설정이 의도대로 동작하는지를 테스트 코드로 증명하면서 다시 한번 느꼈습니다.
복잡한 설정일수록 테스트를 통해 동작을 증명해야만 시스템을 신뢰할 수 있다는 걸요.

마치며

이번 개선을 통해 가장 크게 느낀 건, 장애를 코드로 막아내는 것이 아니라 장애가 전파되지 않을 구조를 설계하는 것이 더 중요하다는 점이었습니다.

Active MGR 선택, Failover, 장애 감지는 인프라가 더 안정적으로 수행할 수 있는 영역이었고, BE는 정상 요청 처리와 인증 관리에 집중하는 편이 시스템 전체의 예측 가능성과 안정성에 훨씬 유리했습니다.

결국 중요한 건 기술을 얼마나 많이 아느냐가 아니라, "각 레이어에 맞는 책임을 어디에 둘 것인가"를 판단하는 능력이라고 생각합니다.

[Ceph] Custom Container 배포를 해보자! (+Prometheus 연동)

:j — Wed, 26 Nov 2025 23:47:20 +0900

RBD 이미지 -> PG -> OSD 매핑

Ceph 클러스터를 운영하다 보면 장애 분석이나 성능·용량 이슈가 생겼을 때,“지금 보고 있는 RBD 이미지가 실제로 어떤 PG에 올라가 있고, 그 PG가 어떤 OSD 들에 퍼져 있는지”를 알고 싶은 순간이 생겼습니다.

예를 들어,

1. 특정 OSD 장애가 발생했을 때, 그 OSD에 어떤 이미지가 얼마나 몰려 있는지 보고 싶거나

2. 리밸런싱 이후 데이터가 의도대로 고르게 분산됐는지 확인하고 싶은경우

"Ceph 내부에서는 객체 이름과 풀 ID로 해시해서 PG를 계산하고 이 PG를 다시 CRUSH로 여러 OSD에 배치를 하게 됩니다."

그래서 저는 go-cpeh(librados를 go 언어로 래핑한 오픈소스)를 사용하여 RBD 이미지 -> PG -> OSD 매핑 API 개발을 진행했습니다.

이후 해당 관련 내용은 다음 포스팅에서 다루도록 하겠습니다!

Ceph MGR Module vs Custom Container

Ceph MGR Module

MGR Module: https://docs.ceph.com/en/latest/mgr/modules/

개요

- Ceph-Mgr 데몬 내부에 동작하는 Python 기반의 플러그인 모듈

- Python으로 MgrModule 클래스를 상속 받아서 구현해야 하며, serve(), notify(), handler_command()등의 메소드를 오버라이드 구현이 필요

장점

- Ceph 클러스터 내부 데이터(모니터, OSD, PG 등) 밀접하게 연동하여 기능 확장이 가능

- ceph mgr module enable <my_module> 로 활성화 가능

Custom Container

Custom Conatainer: https://docs.ceph.com/en/reef/cephadm/services/custom-container/

        [Ceph MON / MGR / OSD]                [Custom Service (go-ceph API)]
                 (Core Ceph)                        (독립 컨테이너)
                       │                                   │
                       └────── Ceph Protocols ──────┬──────┘
                                 (librados, REST 등)

- Ceph 클러스터 내부에서 배포되지만, Ceph의 핵심 데몬 (OSD, MON, MGR등)에 직접 속하지 않는 독립 실행형 컨테이너를 의미

- Cephadm이 이서비스를 container 단위로 배포하고, 운영 관리를 도와주는 형태이지 Ceph 데몬처럼 클러스터의 핵심 구성요소는 아님

개요

- Ceph 크러스터 외부에 독립 실행형 컨테이너 서비스를 배포할 수 있는 기능

- ceph orch apply 명령으로 배포하고 Ceph-orchestrator가 lifecycle을 관리

주요 특징

- Ceph core 역할은 아니지만 Ceph 프로토콜(librados, REST)로 클러스터와 느슨하게 연결 (loose coupling)

- 배포는 원하는 노드에 자유롭게, cephadm orchestrator가 관리

Ceph-MGR Module vs Custom Container Servcie

항목	MgrModule	Custom Container Service
실행 위치	Ceph‑Mgr 데몬 내부	독립 실행 컨테이너
언어 제약	Python only	언어 제한 없음 (Go, Java, Python 등)
클러스터와 연동도	매우 밀접 (내부 기능)	느슨한 결합 (REST, librados 등 사용)
배포 대상	모든 mgr 노드	지정한 노드에 선택 배포
관리 주체	Ceph‑Mgr 데몬	cephadm orchestrator
라이프사이클 관리	ceph mgr module enable/disable	ceph orch apply/update/remove

선택 배경 및 결정 이유

이번에 개발한 API는 go-ceph 기반으로 구현하였으며, Ceph 클러스터 내부의 상태 정보를 활용하는 구조입니다. 이 기능을 실 서비스 환경에 통합하기 위해 처음에는 Ceph-MGR Module을 고려했습니다. MGR Module은 Ceph 클러스터 내부 기능과 밀접하게 연동할 수 있다는 점에서 매력적이었지만, 몇 가지 현실적인 제약이 있었습니다.

첫 번째로, MGR Module은 Python 기반으로만 개발할 수 있으며, ceph-mgr 데몬 내부에서 동작하기 때문에 실제 Ceph 환경이 갖춰진 상태에서만 테스트가 가능합니다. 이로 인해 개발 및 디버깅 속도가 느려지고, 개발 환경 구축이 까다롭습니다.

두 번째로, 저희는 cephadm 기반으로 클러스터를 운영하고 있는데, 이 환경에서는 mgr 데몬이 컨테이너로 실행되므로, 직접 소스 파일을 수정하거나 테스트하는 데 제약이 따릅니다. 예를 들어, 새로운 mgr 모듈을 반영하려면 컨테이너에 볼륨 마운트 설정을 추가하거나 재시작해야 하고, ceph mgr module enable/disable 과정을 반복해야 합니다.

이러한 이유들로 인해 결국 Custom Container Service를 선택하게 되었습니다. Custom Container는 Ceph 클러스터 외부에서 독립적으로 동작하는 서비스이기 때문에, 언어나 프레임워크에 제한이 없고, 개발 및 테스트도 로컬에서 쉽게 수행할 수 있습니다. 배포 또한 ceph orch apply 명령어 한 줄로 가능하며, 전체 라이프사이클을 Ceph의 orchestrator가 관리해주기 때문에 운영 측면에서도 효율적입니다.

결과적으로 여러 요소를 고려했을 때, Custom Container Service가 우리 팀에게 더 적합한 방향이라고 판단되었고, 이에 따라 실제 구현과 배포를 진행하게 되었습니다.

과정

우선 제 목표는 클러스터에 컨테이너가 잘 올라가는지 테스트를 하는게 목적이었기 때문에, go로 간단하게 API를 하나 만들었습니다.

Dockerfile

# 빌드 단계
FROM --platform=linux/amd64 golang:1.24-bookworm AS builder
WORKDIR /app
LABEL ceph="true"

RUN apt-get update && apt-get install -y \
  build-essential \
  librados-dev \
  librbd-dev \
  ceph-common \
  && rm -rf /var/lib/apt/lists/*

COPY go.mod go.sum ./
RUN go mod download

COPY . .

RUN CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -tags no_encryption -o ceph-core-api ./cmd/api

# 실행 단계
FROM --platform=linux/amd64 debian:bookworm-slim
WORKDIR /app
RUN apt-get update && apt-get install -y librados2 ceph-common && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/ceph-core-api .

EXPOSE 9080
CMD ["./ceph-core-api"]

Ceph 클러스터와 통신할 수 있는 Go 기반 API를 효율적으로 빌드하고 실행하기 위해 멀티스테이지 빌드 방식을 사용했습니다. 이를 통해 불필요한 의존성을 제거한 경량 컨테이너 이미지를 만들 수 있습니다.

빌드

FROM --platform=linux/amd64 golang:1.24-bookworm AS builder

golang 이미지를 기반으로 Go 애플리케이션을 컴파일합니다.
--platform=linux/amd64는 호스트 아키텍처와 관계없이 명확한 타깃 플랫폼을 지정해 M1/M2 Mac 등에서도 호환 문제를 방지

RUN apt-get update && apt-get install -y \
  build-essential \
  librados-dev \
  librbd-dev \
  ceph-common \

Ceph 클러스터와 연동하기 위해 필요한 개발 헤더 및 라이브러리를 설치합니다.
Go의 CGO 기능을 활용해 librados를 사용하기 위한 필수 패키지입니다.

RUN CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -tags no_encryption -o ceph-core-api ./cmd/api

CGO를 활성화하여 Ceph C 라이브러리와 연동 가능하게 빌드합니다.
-tags no_encryption은 필요한 경우 빌드 태그를 조정할 수 있습니다. (해당 태그가 없는 경우 빌드 에러)

실행

FROM --platform=linux/amd64 debian:bookworm-slim

실행 이미지는 debian-slim 기반으로, 빌드 도구 없이 필요한 라이브러리만 포함해 이미지 크기를 최소화합니다.
Ceph 공식 컨테이너 이미지나 대부분의 Ceph 관련 컴포넌트는 linux/amd64를 기본으로 빌드됨
호스트와 상관없이 항상 Ceph 클러스터와 호환되는 아키텍처로 이미지를 고정 (플랫폼을 맞춰주지 않는 경우 컨테이너 에러)

RUN apt-get update && apt-get install -y librados2 ceph-common

런타임에서 librados를 활용하기 위해 필요한 패키지를 설치합니다.

COPY --from=builder /app/ceph-core-api .
EXPOSE 9080
CMD ["./ceph-core-api"]

빌드된 바이너리만 복사해 실행 환경을 구성하고, 9080 포트로 API를 제공하도록 설정합니다.

Dockerfile로 이미지를 빌드하고 컨테이너 허브에 push

docker buildx build --platform linux/amd64 -t harbor.tareun.kr/share/djlee/ceph-core-api:v1.0.3 --push .

현재 저는 맥북(arm64)을 사용하기 때문에 --platform 옵션 없이 빌드하면 arm64 아키텍처 이미지로 생성됩니다.

arm64 아키텍처로 Ceph 클러스터에 배포하면 컨테이너 실행이 실패합니다.

그럼 이제 실제 Cluster에서 Push한 컨테이너 이미지를 사용해서 배포를 진행하면 됩니다.

Spec 예시 및 옵션 (ceph-core-api.yml)

service_type: container
service_id: ceph-core-api
placement:
  hosts:
    - ceph152 
    - ceph153 
spec:
  image: harbor.xxx.kr/share/djlee/ceph-core-api:v1.0.4
  args:
    - "--net=host"
  ports:
    - 9080
  envs:
    - GIN_MODE=release
  bind_mounts:
    - ['type=bind', 'source=/etc/ceph', 'destination=/etc/ceph', 'ro=true']

배포

ceph orch apply -i ceph-core-api.yml

서비스 목록과 배포 상태 확인

결과

 curl http://121.141.64.152:9080/api/cluster/fsid
 
 {
  "status": "success",
  "data": {
    "fsid": "df5355e6-f66f-45c6-83b0-4680e086eff5"
  }
}

Prometheus 연동

Cephadm으로 관리되는 Prometheus에서 기본 Ceph exporter 외에 사용자 정의 메트릭 엔드포인트 수집하기 위함
기존 Ceph 모듈(ceph, ceph-exporter, node-exporter)의 scrape 설정 유지, 새로운 job 추가

1. 템플릿 파일 작성 (prometheus.yml.j2)

기존 job 설정을 모두 포함하지 않으면 기존 수집 항목이 사라질 수 있으니, 반드시 기존 job도 포함해야 함.

: 템플릿을 작성하기 전에, 현재 Cephadm에서 Prometheus가 수집 중인 모듈(job)확인 필수!

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'ceph'
    static_configs:
      - targets: ['ceph155:9283']

  - job_name: 'ceph-exporter'
    static_configs:
      - targets:
          - 'xxx.xxx.xx.xxx:9926'
          - 'xxx.xxx.xx.xxx:9926'
          - 'xxx.xxx.xx.xxx:9926'
          - 'xxx.xxx.xx.xxx:9926'

  - job_name: 'node'
    static_configs:
      - targets:
          - 'xxx.xxx.xx.xxx:9100'
          - 'xxx.xxx.xx.xxx:9100'
          - 'xxx.xxx.xx.xxx:9100'
          - 'xxx.xxx.xx.xxx:9100'

  - job_name: 'ceph-core-api'
    static_configs:
      - targets:
          - 'localhost:9080'

2. config-key로 등록

ceph config-key set mgr/cephadm/services/prometheus/prometheus.yml -i prometheus.yml.j2

3. Prometheus 서비스 재배포

ceph orch redeploy promoetheus

4. 결과

실행 파일을 생성하는 링커

:j — Sat, 27 Jul 2024 16:29:52 +0900

2024.07.27 - [CS] - 소스코드파일부터 실행파일까지 컴파일러 과정 알아보기

소스코드파일부터 실행파일까지 컴파일러 과정 알아보기

여러분들은 개발을 진행하면서 단순히 소스코드를 작성하게 되고, 개발한 소스코드를 토대로 실행파일이 생성이 됩니다.어떻게 우리가 작성한 소스코드가 실행파일이 되는지 알아가보겠습니

jhost.tistory.com

대상 파일(object file) 생성 과정에 대해서 궁금하신 분은 이전에 작성한 글을 참고해 주시면 됩니다.

링커

여러분들이 특정 프로그램을 실행할때 해당 프로그램을 실행하기 위한 실행 파일은 하나죠?

(물론 그 하나의 실행 파일을 실행 시키기 위해 부가적인 파일이 필요하기도 합니다.)

이전 글에서 말씀드린 컴파일러를 통해서 대상 파일(object file)이 생성된다는 걸 알았습니다.

컴파일러가 생성한 이 대상파일 파일을 여러개를 하나로 묶어서 최종 실행 파일을 생성해야 됩니다.

실행 파일을 생성하는 과정인 링커(linker)에 대해서 알아보겠습니다.

소스 코드 (func.c) -> 컴파일 (func.o)

func.o라는 이름의 기계명령어에 해당하는 코드를 저장하는 파일이 생성되고, 이 파일을 대상 파일(object file)이라고 합니다.

간단한 응용 프로그램부터 웹 브라우저나 웹 서버 같은 복잡한 응용프로그램들은 윈도에서 흔히 보이는 exe 형식의 실행 파일이나 리눅스의 elf 파일 같은 실행 파일은 링커가 필요한 대상 파일을 한데 모아 구성됩니다.

링커 작업 과정

링크의 전체 과정은 저자 여러명이 각각 특정 부분을 맡아 챕터별로 따로 집필하고, 개별 장을 묶어 책 한 권으로 출판하는 것과 비슷합니다.

1. 심벌 해석(symbol resolution)

심벌은 전역 변수와 함수의 이름을 포함하는 모든 변수 이름을 의미 합니다.

책의 특정 장이 다른 장의 내용을 참고할 때가 있는데, 이것은 우리가 작성하는 프로그램이 다른 모듈의 프로그래밍 인터페이스(programming interface) 또는 변수(variable)를 참조하는 것과 같습니다.

예를 들어서 list.c에서 일종의 연결 리스트(linked list)를 구현하고 다른 모듈에서 그 연결 리스트를 사용해야 한다면 이때 이 두 모듈 사이에 의존성이 있다고 말하죠.

즉, 링커가 하는 일 중 하나는 의존성(종속성)이 올바르게 설정되어 있는지, 다시 말해 인터페이스 구현이 의존성이 있는 모듈에서 사용 가능한지 확인하는 것입니다.

책 한 권이 오류 없이 완성되려면 서로 참고한 내용이 실제로 그 책 안에 정리가 되어 있어야겠죠?

실제 참조하고 있는 외부 심벌(external symbol)에 대한 실제 구현이 어느 모듈이든지 단 하나만 있어야 하는데, 링커는 이를 찾아내 연결하는 작업을 합니다.

2. 재배치(relocation)

책에서 어떤 하나의 장에서 다른 장의 내용을 인용할 때 몇 페이지의 내용이라고 언급해야 하는데, 각 저자가 집필할 때는 어느 페이지에 인용한 내용이 들어가는지 미리 알 수 없기 때문에 (책이 아직 완성된 상태가 아니기 때문에) 임시로 N 쪽이라고 표시하고 이후 책이 최종적으로 편집 작업에 들어가야 N 쪽이 몇 쪽인지 알 수 있습니다.

CPU에 대한 자세한 설명은 N 쪽을 참고하세요. -> 재배치 -> CPU에 대한 자세한 설명은 150쪽을 참고하세요.

이 과정에서 N 쪽이라고 표시된 부분을 전부 150쪽이라고 치환하는 과정을 재배치라고 합니다.

실제 코드에서도 위처럼 재배치가 일어납니다.

특정한 소스 파일에서 다른 모듈에 정의되어 있는 함수를 참조할 때, 컴파일러가 이 소스 파일을 컴파일하는 시점에서는 이 함수가 어느 메모리 주소(memory address)에 위치할지 정확히 알 수 없기 때문에 컴파일러는 이 함수를 N으로 표시해 두고 일단 넘어가게 됩니다.

이후 링크 과정에서 링커가 N으로 표시되어 있는 곳들을 확인하고 모아 실행 파일을 생성하는 과정에서 함수의 정확한 주소를 확인하고 실제 메모리 주소로 대체합니다.

각 저자가 자신 분량을 모두 집필하고 나면 이를 모아 하나로 합쳐야 책 한 권이 완성될 수 있는데, 이렇게 완성된 책 한 권은 링크 과정을 마친 후 최종적으로 생성된 실행 파일에 비유할 수 있습니다.

지역 변수는 모듈 내에서만 사용되어 외부 모듈에서 참조할 수 없기 때문에 링커의 관심 대상이 아니죠.

즉, 링커가 실제로 관심을 갖는 것은 전역 변수입니다.

1. 소스 파일에 다른 모듈에서 참조할 수 있는 심벌

2. 소스 파일이 다른 모듈에서 정의한 심벌 두 개를 참조

그렇다면 링커는 위 두 가지 정보를 어떻게 알 수 있을까요?

-> 컴파일러를 통해서 알 수 있습니다.

컴파일러는 소스 코드를 기계 명령어로 번역하고 그 정보를 대상 파일에 저장하는데, 기계 명령어 생성할 뿐만 아니라 이 명령어를 실행시키는 데이터도 생성합니다. 이 데이터는 대상 파일에 반드시 포함이 되어 있습니다.

생성된 대상 파일에는 코드영역, 데이터 영역이 포함됩니다.

코드 영역 : 소스 파일에 정의된 함수에서 변환된 기계 명령어가 저장되는 부분

데이터 영역 : 소스 파일의 전역 변수가 저장되는 부분

(지역 변수는 프로그램이 실행된 후 스택 영역에서 생성되고 사용하면 제거되기 때문에 대상 파일에는 별도로 저장되지 않음)

컴파일러가 링커 부담을 조금이나마 줄여주고자 추가적으로 하는 작어비 있습니다.

소스 파일마다 외부에서 참조 가능한 심벌이 어떤 것인지 그 정보를 기록하고, 반대로 어떤 외부 심벌을 참조하고 있는지 기록하여 링커에게 전달해 줍니다.

외부 심벌 정보를 기록하는 표를 심벌 테이블이라고 합니다.

이렇게 대상 파일에 코드 영역, 데이터 영역, 심벌 테이블이 저장됩니다.

링커는 컴파일러를 통해 필요한 정보를 얻고, 공급과 수요를 충족하는지 확인합니다.

실제 코드를 작성할 때는 공급이 수요를 초과할 수는 있지만 반대로 수요가 공급을 초과하는 상황이 발생해서는 안됩니다.

-> 실제로 사용하지 않는 함수를 정의할 수는 있지만 존재하지 않는 함수를 사용할 수는 없음

재배치 과정에 대해서 자세히 알아보면, 재배치는 실행 시 주소를 정확한 주소지를 결정해줘야 합니다.

링커는 실행 파일을 생성할 때 프로그램이 실행되는 시점에 함수가 적재될 메모리 주소를 확정해야 하는데 이 메모리 주소는 어떻게 알 수 있을까요?

컴파일러가 메모리 주소를 확정할 수 없는 변수를 발견할 때마다 . relo.text, . relo.data 파일을 생성합니다.

.relo.text : 해당 명령어를 저장

.relo.data : 해당 명령어와 관련된 데이터를 저장

최종 대상 파일

대상 파일에서 각 유형의 영역이 모두 결합되면 모든 기계 명령어와 전역 변수가 프로그램 실행 시간에 위치할 메모리 주소를 결정할 수 있습니다. 링커는 각 대상 파일의. relo.text 영역을 읽어 명령어를 확인하고, 심벌의 코드 영역 시작 주소 값을 확인합니다.

최초 주소는 0x00으로 표시되고,. relo.text,. relo.data를 읽어 들여 심벌의 코드 영역 시작 주소 기준 오프셋을 확인하고 실행 파일에서 해당 명령어를 찾아 이동할 소스 주소를 0x00에서 이동할 주소로 수정합니다.

이렇게 심벌의 메모리 주소를 수정하는 과정이 재배치입니다.

각 프로그램마다 변수나 명령어의 메모리 주소는 전부 다를 텐데, 링커가 프로그램이 실행된 후의 변수나 기계 명령어의 메모리 주소를 확인할 수 있는 이유는 무엇일까요? 이는 가상 메모리와 관련이 있습니다.

소스 코드 파일부터 실행 파일까지 컴파일러 과정 알아보기

:j — Sat, 27 Jul 2024 15:41:48 +0900

여러분들은 개발을 진행하면서 단순히 소스코드를 작성하게 되고, 개발한 소스코드를 토대로 실행파일이 생성이 됩니다.

어떻게 우리가 작성한 소스코드가 실행파일이 되는지 알아가보겠습니다.

인간이 인식할 수 있는 단어로 코드를 작성하는 것 == 소스 파일 (source file)

이 소스 파일을 컴파일러에게 전달하면 실행 파일 형태가 됩니다.

소스 코드 -> 컴파일러 -> 실행파일

컴파일러?

특정 프로그래밍 언어로 쓰여있는 문서를 다른 프로그래밍 언어로 옮기는 언어 번역 프로그램입니다. (번역기)

컴파일러는 고급 프로그래밍 언어를 저급 프로그래밍(CPU가 인식할 수 있는) 언어로 바꿔주는 역할을 하며, 컴파일된 이후의 코드를 목적코드(object code)라고 합니다.

왜 컴파일러를 사용할까?

간단한 코드 예시

int a = 1;
int b = 2;

while(a < b)
{
	b = b - 1;
}

인간의 관점

a 변수에 1을 할당합니다;
b 변수에 2를 할당합니다;
a < b 이면 b가 1씩 줄어듭니다;
더 이상 a < b가 성립하지 않을 때까지의 앞의 문장을 반복합니다;

CPU는 이런 추상적인 표현을 직접 이해할 수 없기 때문에 컴파일러의 도움을 받아야 합니다.

우리가 작성한 소스코드는 컴파일러를 통해 CPU가 인식할 수 있는 언어로 변환이 되어 우리가 작성한 소스코드대로 동작이 진행됩니다.

(CPU는 단세포 생물처럼 매우 원시적이며 멍청하지만, 이 멍청함을 상쇄하고도 남을 정도고 속도가 매우 빠릅니다.)

컴파일러 과정

첫 번째, 어휘 분석

컴파일러는 먼저 각 항목을 잘게 쪼개고, 각 항목이 가지고 있는 추가 정보를 묶어서 관리합니다.

컴파일러의 첫 번째 작업은 소스 코드를 돌아다니면서 모든 토큰을 찾아냅니다.

T_Keyword	int
T_Identifier	a
T_Assign	= 
T_Int	1
T_Semicolon	:
T_Keyword	int
T_Identifier	b
T_Assign	=
T_Int	2

위에서 작성한 소스코드를 예시로 이런 식으로 각 항목을 잘게 쪼갭니다.

1. 키워드

2. int 키워드라는 추가 정보를 포함

이렇게 각 항목에 추가로 정보를 결헙한 것을 전문용어로 토큰(token)이라고 합니다.

각각의 줄은 하나의 토큰을 의미하며, T로 시작하는 왼쪽 열은 토큰을 의미하며, 오른쪽 열은 각각의 토큰이 가지는 값을 나타냅니다.

이러한 소스 코드에서 토큰을 추출하는 과정을 어휘 분석이라고 합니다.

두 번째, 구문 분석

컴파일러는 구문에 따라 한 글자도 놓치지 않고 해석(parsing) 작업을 진행합니다.

예를 들어서 컴파일러가 while 키워드의 토큰을 찾으면 다음 토큰이 (라는 것을 알 수 있는데, 다음 토큰이 while 키워드에 필요한 토큰이 아니라면 컴파일러는 문법 오류(syntax error)를 보고 합니다.

컴파일러는 구문에 따라 해석을 하며 트리를 생성하고, 이 트리를 생성하는 전체 과정을 구문 분석이라고 합니다.

세 번째, 의미 분석

구문 분석을 통해 구문 트리가 생성되고 나면 구문 트리에 이상이 없는지 확인합니다.

즉, 정수 값에 문자열을 더하면 안 되고, 비교 기호의 좌우에 있는 값 형식이 다른 경우를 찾으며 이 단계를 통과하면 작성한 소스코드에 이상이 없기 때문에 컴파일 오류가 없다는 것이 증명됩니다.

이 과정을 의미 분석이라고 합니다.

네 번째, 중간 코드 생성

의미 분석이 끝나면 컴파일러는 구문 트리를 탐색한 결과를 바탕으로 좀 더 다듬어진 형태인 중간 코드(Intermediate Representation Code, IR Code)를 생성합니다.

중간 표현이라고도 불리며, 소스 코드를 표현하기 위해 컴파일러나 가상 머신에 의해 내부적으로 사용되는 데이터 구조 또는 코듭

a = 1
b = 2
goto B
A: b = b - 1
B: if a < b goto A

다섯 번째, 중간 코드를 어셈블리어 코드로 변환

movl $0x1, -0x4(%rbp) // a = 1
movl $0x2, -0x8(%rbp) // b = 2
jmp B // b로 점프
A: subl $0x1, -0x8(%rbp) // b = b - 1
B: mov -0x4(%rbp),%eax
cmp -0x8(%rbp),%eax // a < b ?
jl A	// a < b 이면 A로 점프

여섯 번째, 기계 명령어로 변환

마지막으로 컴파일러는 이 어셈블리어 코드를 기계 명령어로 변환합니다.

이런 방식으로 컴파일러는 인간이 작성한 소스코드라고 부르는 문자열을 CPU가 실행할 수 있는 기계 명령어로 변환합니다.

그렇다면 지금 까지 과정이 끝나면 실행 파일이 알아서 생성이 되는 걸까요?

-> 추가적으로 대상 파일을 병합하는 링크(link) 작업이 필요합니다.

모든 소스 파일에는 각각의 대상 파일이 존재하고, 프로젝트가 복잡해져서 소스 파일이 세 개 있다고 가정하면 대상 파일은 모두 세 개가 됩니다. 하지만 우리가 원하는 건 하나의 실행 파일이고 이 대상 파일 세 개를 하나의 실행 파일로 합쳐주는 작업을 링크 라고 합니다.

이 링크를 담당하는 프로그램을 링커(linker)라고 합니다.

참고

컴퓨터 밑바닥의 비밀

항해 플러스 4기 백엔드 솔직 후기

:j — Sun, 2 Jun 2024 19:29:11 +0900

벌써 항해 플러스 4기 10주간의 여정이 모두 마무리되었습니다.

10주 동안 많은 일이 있었지만 내용을 정리할 겸 회고를 작성해보려고 합니다

항해 플러스를 선택하게 된 계기

저는 현재 3년 차 그룹웨어 서비스에서 웹 개발자로 재직 중이며, 개발자가 되기 전에 학부 시절 개발에 대해서 관심을 가지게 되었고 졸업 후 국비학원을 통해서 개발자로 취업하게 되었습니다.

현재 회사에서는 솔루션 회사이다 보니 기존에 이미 잘 만들어져 있는 소스코드 기반 위에서 작업을 하기 때문에 타 회사에서 사용하는 기술들에 비해서 많이 노후된 기술들을 사용하기 때문에 업무시간 외에 혼자서 공부를 하는데 어느 정도 한계가 있었습니다.

우연히 항해 플러스 광고를 보게 되었는데, 항해 플러스에 들어오기 전에 제가 가장 고민이 되었던 부분은 물경력이라는 단어가 제일 눈에 들어왔습니다. 3년 차가 된 만큼 저 자신 스스로에게 변화가 필요하다고 느끼게 되어서 커리큘럼을 보고 실제 서비스 회사에서 사용하는 기술들을 보고 "10주간 한번 미친 듯이 해보자"라는 생각을 가지고 나름 열심히 참석했던 것 같습니다.

항해 플러스 백엔드 코스의 장점

실제 진행되는 커리큘럼!

저는 평소에 현재 회사를 다니면서 실제 좋은 서비스 회사에서는 다양한 기술들을 어떻게 활용해서 개발하는지 정말 궁금했습니다.

본 과정은 TDD, 클린아키텍처 기반 서버 구축, 통합 모니터링 시스템 구축, 대용량 트래픽 처리 등 매주 다양한 발제 주제들을 통해서 한 주마다 2번의 과제 제출로 진행하게 되는데 이런 과제들을 해결해 나가면서 퍼즐조각을 하나씩 맞춰졌습니다.

제가 제일 흥미롭게 진행했던 주제는 클린 아키텍처 서버 구축 + 대용량 트래픽입니다!

서버구축 발제를 하면서 본인이 원하는 API를 선택해서 진행하게 되는데 대기열 프로세스를 구현하는 API를 선택해서 개발하면서 REDIS사용 경험이 부족했던 저는 RDB를 사용해서 개발을 하다가 동시성 테스트를 통과하기 위해 지속적인 리팩토링 과정을 통해서 많은 성장을 했다고 생각합니다.

멘토링

엄청난 커리어를 가지신 시니어 멘토들과 발제 주제에 대해서 같이 고민하면서 해결해 나갈 수 있었고, 발제 주제가 아니더라도 다른 기술적인 고민이 있을 면 진심으로 같이 고민해 주시면서 해결책을 찾는 방법을 알려주셨습니다. 멘토링 시간이 매주 각 조마다 1시간 밖에 안되지만 항상 1시간 넘게 진행해 주시고 다른 조들의 멘토링 시간을 도강하면서 다른 사람들은 이런 고민도 하는구나 하면서 다양한 경험을 할 수 있는 시간이었습니다.

리뷰

매주 토요일 과제 대한 종합적인 검토를 통해서 평과 결과를 pass/fail 여부를 확인할 수 있으며, 과제에 대한 코치님들의 자세한 피드백도 확인이 가능합니다. 그리고 다른 동료들은 어떤 고민을 가지고 어떤 식으로 해결했는지 공유가 되는 부분도 정말 좋았습니다.

같은 팀끼리만 공유하는 게 아니라 모든 동료들과 같이 공유하며 매주 토요일 랜덤 피어 리뷰를 진행하게 됩니다. 이러한 시간을 통해서 다양한 관점에서도 생각할 수 있었습니다.

네트워킹

항해 플러스 과정의 또 다른 매력은 혼자서 하는 것이 아니라 팀원들과 함께 여정을 떠나면서 서로 편하게 피드백을 주고받으면서 같이 성장해 나간다는 부분도 정말 좋았습니다. 앞으로 같이 성장해 나갈 정말 좋은 동료들을 얻었습니다.

항해 플러스를 하면서 앞으로 공부해야 할 방향성에 대해서 잡게 되었고, 이번 계기를 통해서 정말 값진 경험을 했다고 생각합니다.

10주간 이 과정을 마무리했다고 해서 끝나는 것이 아닌 이 과정을 통해서 발판을 만들었고, 저는 이제 이 발판을 통해서 더욱 높게 올라가기 위해 꾸준히 공부를 할 생각입니다!

항해 플러스에 투자한 시간과 돈은 이 과정을 끝내면서 전혀 아깝다는 생각이 들지 않습니다.

200만 원 가까이하는 비싼 금액이지만, 그 이상의 값어치를 한다고 생각합니다.

또 하나의 장점은 발제에 대한 녹화본도 제공이 되기 때문에 부족한 부분에 대해서 스스로 복습할 수도 있고 수료 이후에도 선배 기수 역할로 한번 더 참여할 수 있는 기회도 제공되며, 멘토링을 참관하며 최신 문서로 복습할 수 있는 기회도 주어집니다.

아래 상황 중에 3가지 이상 해당이 되신다면 항해 플러스 코스는 도움이 된다고 생각합니다.

- 개발자로 현재 일을 하고 있는데 개발 외의 업무가 더 많다

- 주변에 아는 개발자가 없어서 기술적으로 커뮤니케이션할 동료가 없다.

- 스스로의 개발 실력이 부족하다고 느껴진다.

- 내가 지금 잘하고 있는 건지 판단이 안된다.

- 미래 커리어에 대한 고민

- 회사에서 쓰는 기술스택이 오래된 기술 스택인 경우

- 시니어 개발자가 없거나 회사의 시스템이 미비한 환경

특별할인

다양한 동료들과 네트워킹 하면서 소중한 경험을 쌓고 싶은 주니어 개발자라면 항해 플러스 백엔드 과정 신청하는 것을 적극 추천드립니다. 항해 플러스 과정의 중요한 장점은 공동 학습 및 네트워킹을 통해서 스스로의 학습능력을 키울 수 있는 점! 과정 전반에 걸쳐 다양한 동료들과 협력하고, 경험이 풍부한 코치와 함께 멘토링을 진행하게 되면서 개발자로서 성장하는데 도움이 될 뿐만 아니라 앞으로의 경력이 충분한 도움이 될 거라고 생각합니다.

만약에 항해 플러스 백엔드 코스가 관심 있으시다면 지인추천 제도를 이용하시면 특별할인(등록금 할인)도 있다고 하니 관심 있으신 분은 코드를 통해서 지원하시기 바랍니다!

코드 : ZOpfQY

모든 개발자분들 화이팅입니다!!!!!!!!!!!!!!!!!!!!!!!!

항해 플러스 9주차 회고

:j — Sun, 19 May 2024 19:53:34 +0900

9주차 책임 분리를 통한 애플리케이션 설계

1. 문제

비즈니스 로직과 트랜잭션 범위 고려

@Transactional
void payment() {
    결제_요청_검증()
    유저_포인트_차감()
    결제_정보_저장()
    주문_정보_전달() //외부 플랫폼 API 호출    
}

예를 들어서 상품을 결제하는 결제 함수가 있다.

결제처리 하는 비즈니스 로직 안에 여러 가지 함수들이 존재하며, 결제 처리가 끝난 후 최종적으로 주문 정보를 외부 API를 호출하여 전송해 주는 기능까지 존재한다. 즉, payment()가 정상적으로 성공 처리 되기 위해서는 외부 API에 호출 또한 정상적으로 통신이 되어야 한다.

위에 로직은 정상적인 것 같지만 심각한 문제가 있다.

- 외부 플랫폼 API 호출 시 네트워크 이슈로 인해 통신이 오래 걸리는 경우 pamyent()로직 자체가 오래 걸리게 된다. (하나의 트랜잭션으로 동작하기 때문에)

- payment()가 실행되면서 모든 로직이 성공적으로 다 처리 되었지만 외부 API에서 문제가 생기는 경우 전부 롤백된다.

주문 정보 전달은 부가 로직 이므로 주요 로직인 결제 처리에 영향을 끼치면 안 된다.

2. 시도 & 해결

문제점을 해결하기 위해서 이벤트를 사용해서 부가 로직과 주요 로직의 결합을 끊어낼 수 있다.

@Transactional
void payment() {
    결제_요청_검증()
    유저_포인트_차감()
    결제_정보_저장()
    applicationEventPublisher.publishEvent(주문_정보_전달()) //외부 플랫폼 API 호출    
}

스프링에서 제공하는 이벤트리스너 기 등을 사용해서 이벤트로 비즈니스 로직을 수정하였다.

이벤트의 동작 과정 : 이벤트 생성 주체 -> 이벤트 디스패처(이벤트 퍼블리셔) -> 이벤트 핸들러(이벤트 구독자)

스프링 이벤트를 사용

이렇게 이벤트를 사용해서 부가 로직(외부 API)에 의해서 주요 로직의 영향이 없도록 만들 수 있지만!!!! 단순히 이벤트로 처리한다고 해서 영향이 없는 건 아니다.

이벤트는 크게 동기 방식과 비동기 방식이 있는데 동기 방식으로 하는 경우에는 하나의 트랜잭션 범위로 동작하기 때문에 여전히 외부 서비스에 영향을 받게 된다.

비동기 방식은 (이벤트 리스너에서 @Async를 사용) 다른 스레드에서 동작하기 때문에 우리가 원하는 대로 처리하기 위해서는 비동기 방식을 사용해서 처리해야 한다. 외부 시스템과의 연동을 동기로 처리할 때 발생하는 성능과 트랜잭션 범위 문제를 해소하기 위해서는 이벤트를 비동기로 처리하거나 이벤트와 트랜잭션을 연계하는 방법이 있다.

비동기 방식을 사용하기 위해서는 @EnableAsync를 통해서 비동기를 활성화시켜야 한다!!!!

-> 처음에 @Async만 적용했다가 로그에 같은 스레드로 동작하는 걸 보고 이상함을 감지..

로컬 핸들러 비동기 실행이 아니라 외부 메시징 시스템을 이용해서도 해결할 수 있다.

나는 저기 저 어깨너머로 듣기만 했던 카프카를 사용해서 처리해 봤지만 카프카 너무 어렵다..

카프카를 적용하면서 만약 메시지 발행에 대해서 실패하는 경우? 에 대한 고민을 해결해 보기 위해서 Transactional Outbox Parttern을 사용하는 것을 보고 대략적으로 설계는 해봤지만 아직 실제로 적용해보진 못했다. 이 부분도 카프카를 공부해 보면서 나중에 적용해 볼 계획이다.

4. 목표

카프카를 (찍먹!?) 사용해봤지만.. 대용량 트래픽을 수월하게 카프카에 대한 필요성과 중요성이 느껴졌다.

조만간 아파치 카프카 애플리케이션 프로그래밍 with 자바 정독을 목표로 잡고 카프카에 대해서 제대로 알아 가는 시간이 필요할 것 같다.

https://www.yes24.com/Product/Goods/99122569

항해플러스 8주차 회고

:j — Sat, 11 May 2024 17:10:13 +0900

이번 주차는 콘서트 프로젝트를 진행하면서 대기열을 기존에는 RDB를 사용하여 구성하였으면, REDIS를 사용해서 구현하기 위해 다시 설계하고 구현해 보는 시간을 가졌다.

대기열 리팩토링

대기열은 기존에 동시성 유즈 케이스 고민하면서 사용했던 Redisson 라이브러리를 활용해서 Redis를 사용했다.

대기열은 두 가지 상태를 가지고 있으며, 서비스 이용을 위해 대기하거나, 서비스를 이용할 수 있고, 대기열 만료 시간이 지난 사용자는 대기열에서 삭제가 되기 때문에 별도의 상태를 관리하지 않는 구조로 설계 방향을 잡았다.

Wating Queue

redissonClient.getScoredSortedSet("waitQueue");

Redis Sorted Set 자료 구조를 기반으로 만들어진 RScoredSortedSet 사용
waitQueue.add(System.currentTimeMillis(), userId); Key는 userId, Score는 요청 시간을 저장
add 명령어는 내부적으로 Redis ZADD 명령어로 신규 대기열을 추가하고, RANK 대기열 순번을 반환
대기열에 이미 존재하는 사용자가(활성화되지 않은 사용자)가 대기열을 다시 신청하는 경우 순번은 맨 뒤로 밀리게 됩니다.

Ongoing Queue

redissonClient.getMapCache("ongoingQueue");

Redis Hash 자료 구조를 기반으로 만들어진 RMapCache 사용
Hash와 차이점은 Hash는 개별 요소 대해 TTL 설정이 불가능 하지만, RMapCache는 개별 요소에 대해 TTL 사용이 가능하다.(대기열 만료시간)
콘서트 최종 결제가 성공한 사용자는 OngoingQueue에서 제거

대기열 활성화 스케쥴러

스케쥴러를 통해서 QUEUE_LIMIT - iQueueRedisRepository.getOngoingCount() 대기열 진입 가능한 수 계산
대기열 진입 가능 한 수만큼 waitQueue.pollFirst(availableQueueCount). stream(). toList(); poll() -> 내부적으로 Redis ZRANGE 명령어를 사용해서 1번째 순번부터 availableQueueCount까지 삭제
waieQueue에서 삭제된 userId들을 OngoingQueue로 삽입하며 대기열 만료 시간만큼 활성화

대기열 설계 방향성 선정 과정

대기열 활성화의 경우 TTL 없이 OngoingQueue에서 만료된 토큰의 수만큼 WaitingQueue에서 전환되는 경우

서비스를 이용할 수 있는 사용자를 항상 일정 수 이하로 유지할 수 있다는 장점이 있지만
서비스를 이용하는 사용자의 액션 하는 속도에 따라 대기열의 전환시간이 불규칙하다는 단점이 있다.

N초마다 M개의 토큰을 OngoingQueue로 전환하는 경우

대기열 고객에게 서비스 진입 가능 시간을 대체로 보장할 수 있지만
서비스를 이용하는 사용자의 수가 보장될 수 없다.

첫 번째 방식에서 가장 큰 문제점인 앞사람이 완료하지 않으면 뒷사람이 들어갈 수 없는 문제를 해결하기 위해 각 사용자에 대하여 평균적인 시간(한 유저가 콘서트 조회를 시작한 이후에 하나의 예약을 완료할 때까지 걸리는 시간)을 고려하여 대기열 만료시간을 설정, 두 번째 방식에서 적절한 동시 접속자를 유지하기 위해서 서버 트래픽의 최대치를 고려하여 QUEUE_LIMIT로 동시 접속자 제한을 두어 처리하는 방향으로 1번과 2번 케이스에 대한 장단점을 최대한 살려서 가져가는 방식으로 설계를 진행했다.

Redis Hash는 기본적으로 개별 요소에 대한 TTL 설정이 불가능하기 때문에 내가 설계한 방향대로 구현하기 위해서 각 사용자마다 Hash를 생성해서 그 Hash에 대한 TTL을 걸어줘야 하는데, Hash를 생성하는 만큼 Redis에 대한 부하가 많이 심해질 거라고 예상이 되기 때문에 순수 Redis를 사용하는 경우에는 어떤 식으로 설계할지 고민해봐야 될 것 같다.

Redisson에서 제공해 주는 RMapCache는 개별 요소에 대한 TTL을 어떤 식으로 제공을 하는 건지 공부를 해봐야 할 것 같고, 순수 Redis를 사용하는 경우에는 어떤 식으로 설계할지 고민이 필요해 보인다.

항해 플러스 5주차 회고

:j — Sat, 20 Apr 2024 17:48:09 +0900

벌써 항해 플러스 과정이 절반이 지났다.

5주 차 동안 TTD, 아키텍처, 서버구축 등 과제를 하면서 정신없이 달려왔다.

(절반 이상의 시간이 그동안 배운 내용들에 대해서 정리해야 될 것 같다.)

이번 주차 발제 과제였던 콘서트 프로젝트를 진행하면서 필요한 도메인이 무엇인지 생각하고 도메인 중심적으로 개발을 진행하려고 했지만, 막상 개발을 하면서 데이터를 우선 적으로 가지고 와야 할 것 같은데?라는 느낌이 강하게 들어서 개발을 진행하고 돌이켜보니 서비스 코드에 비즈니스 로직이 다 들어가는 느낌 적인 느낌..

DDD에 대해서 조금이라도 감을 잡기 위해서 "도메인 주도 개발 시작하기 : DDD 핵심 개념 정리부터 구현까지 <최범균>" 책을 구매해서 읽어보고 있는데 (현재 3장..) 내가 한건 도메인 주도 개발 이라기보다 흉내만 낸 그냥 테이블(ERD) 중심적인 개발에 가까웠던 것 같다.

기존에 도메인 책임에 대한 개념이 잘 정리가 되지 않아서 조금 더 공부를 해보고 콘서트 프로젝트를 리팩토링 하는 시간을 가져야될 것 같다.

2024.04.18 - [회고] - 콘서트 예약 프로젝트 회고

콘서트 예약 프로젝트 회고

콘서트 예약 프로젝트를 진행하며 코딩을 하기 전에 시퀀스 다이어그램, ERD, API 명세를 만들면서 이걸 내가 할 수 있을까 라는 생각이 가장 먼저 들었지만 도메인을 나눠서 그 도메인에 맞는 책

jhost.tistory.com

콘서트 예약 프로젝트 회고

:j — Thu, 18 Apr 2024 23:53:23 +0900

콘서트 예약 프로젝트를 진행하며 코딩을 하기 전에 시퀀스 다이어그램, ERD, API 명세를 만들면서 이걸 내가 할 수 있을까 라는 생각이 가장 먼저 들었지만 도메인을 나눠서 그 도메인에 맞는 책임과 로직을 구현하다 보니 하나씩 완성할 수 있었다.

오늘은 고민을 많이 한 2가지 케이스에 대한 내용을 회고하려고 한다.

- 대기열 구현

- 포인트 충전 동시성 문제

대기열 구현

대기열 로직을 구현하고 동시성 테스트 케이스를 2가지 작성을 하였다. (테스트 환경 : 대기열이 0명인 경우)

1. 한명의 사용자가 대기열 신청을 동시에 여러 번 하는 경우 한 번만 신청이 완료되어야 한다.

2. 100명의 사용자가 동시에 신청하는 경우 ONGOING 상태를 가진 사용자가 QUEUE_LIMIT(대기열 제한수)와 같아야 한다.

앞전에 작성한 내용으로 AtomicLong을 사용해서 대기열 카운트를 제어해서 2번의 동시성 케이스를 통과를 하였지만 AtomicLong을 사용해서 처리한 경우에 분산환경에서는 의미가 없는 상태라는 피드백을 받아서 다시 수정을 하기로 했다.

2024.04.10 - [프로그래밍 언어/Java] - [Java] AtomicLong으로 동시성 문제 해결 (feat. 비관적 락을 사용하지 못한 이유)

[Java] AtomicLong으로 동시성 문제 해결 (feat.비관적 락을 사용 하지 못한 이유)

콘서트 예매 사이드 프로젝트를 진행하면서 대기열 관련해서 개발을 진행하면서 비관적 락을 사용해서 대기열 동시성을 풀어 나가려고 했습니다. 요구사항 중 멀티 스레드 환경에서 여러 번의

jhost.tistory.com

수정한 내역

1. 대기열 테이블에 unique 제약조건 추가(userId_status)

2. 기존 대기열 상태중 WAIT, ONGOING, DONE 상태에서 DONE 상태를 삭제

-> 대기열 만료시 상태를 DONE으로 update 하는 과정에서 unique 제약조건 위배 되기 때문에, 만료된 상태를 관리하는 별도의 필드를 추가 isExpired (true, false)하여 관리

수정한 후 동시성 테스트 케이스 실행 결과 이번엔 반대로 1번은 성공하지만 2번은 실패하는 상황..

1. 한명의 사용자가 대기열 신청을 동시에 여러 번 하는 경우 한 번만 신청이 완료되어야 한다. (성공)

-> 1번의 상황은 unique제약 조건으로 인해 insert자체가 되지 않아서 당연히 성공할 거라고 예상했다.

2. 100명의 사용자가 동시에 신청하는 경우 ONGOING 상태를 가진 사용자가 QUEUE_LIMIT(대기열 제한수)와 같아야 한다. (실패)

-> 2번 상황이 실패하는 이유는 대기열에 ONGOING 상태인 사용자가 QUEUE_LIMIT보다 적은 경우 ONGOING상태로 진입이 되어야 하기 때문에 요청이 들어오는 경우 SELECT COUNT(*) FORM QUEUE WHERE status = 'ONGOING' ONGOING 상태의 카운트를 확인하여 비교하여 대기열 추가

public void assignQueueStatusByAvailability(Queue queue) {
    //findByStatusWithPessimisticLock -> 비관적 락을 걸어도 동시성 의미 없는 상태
    List<Queue> ongoingStatus = iQueueRepository.findByStatusWithPessimisticLock(WaitingStatus.ONGOING);

    if (ongoingStatus.size() < QUEUE_LIMIT) {
        queue.toOngoing(QUEUE_EXPIRED_TIME);
    } else {
        queue.toWait();
    }
}

count() 쿼리의 경우 집계 연산이기 때문에 비관적 락을 걸 수 없기 때문에, 이를 해결해 보기 위해서 위에 코드처럼 SELECT 쿼리에 락을 걸어서 시도를 해봤지만 여전히 실패..

기존 대기열에 있는 ROW들에 대한 LOCK은 사실상 의미가 없기 때문에 영향이 없다.

사실상 syncronized 키워드를 사용하거나, RDB 대신 REDIS를 사용하면 쉽게 해결할 수 있지만 이왕 시작한 거 마무리를 하고 싶은 욕심이 있다.

아직 해결한 문제는 아니지만 저 2가지 케이스를 동시에 성공하기 위해서는 2가지 방법이 있을 것 같다.

1. 대기열 관련 테이블을 2개의 테이블로 구성하여 해결하는 방법

wait_table(status - WAIT), ongoing_table(status - ONGOING, DONE)

- 사용자가 대기열 신청을 하는 경우 ongoing 카운트와 상관없이 무조건 WAIT_TABLE에 insert

- 대기열 만료 스케쥴러 (ongoing_table 에서 만료 시간이 지난 사용자는 DONE 상태로 업데이트)

- 대기열 갱신 스케쥴러 (wait_table 에서 진입한 순서대로 QUEUE_LIMIT - ONGOING count() 만큼 ONGOING 상태로 갱신)

위 방법으로 해결할 경우 사실상 내가 고민한 동시성 고민을 할 필요가 없다.

2. ONGOING count의 컬럼만 존재하는 QUEUE_ONGOING_COUNT 테이블을 추가해서 ONGOING 카운트를 관리하는 방법

- 카운트 조회시 비관적 락을 잡아서 해결하는 방법

나머지 기능 구현을 완료하고 나서 아마도 위 2가지 방법 중 하나로 수정을 해야 할 것 같다.

포인트 충전 동시성 문제

point_table -> id, user_id, point로 간단하게 구성되어 있다.

문제가 발생하는 상황은 사용자가 포인트를 최초(첫) 충전하는 경우 발생하게 된다.

@Override
public Point findPointByUserId(Long userId) {
    return pointJpaRepository.findByUserId(userId)
            .map(PointConverter::toDomain)
            .orElseGet(() -> Point.builder()
                    .userId(userId)
                    .point(0L)
                    .build());
}

포인트 최초 충전시 point_table에 user_id에 대한 row가 없기 때문에 0L으로 도메인을 return 해서 서비스에서 point 객체에 충전할 금액을 더해서 save를 하게 된다.

기존에 포인트가 있는 유저의 충전이 다수로 들어올 경우에는 findByUserId 쿼리에서 락을 잡아서 해결하면 되지만, 첫 충전하는 경우에는 이런 상황을 어떤 식으로 풀어야 할지 도저히 모르겠다.

위와 같은 상황이 많이 나올 것 같은데 공부를 더 해봐야 될 것 같다..

위 내용 말고도 프로젝트를 진행하면서 아직 풀지 못한 내용이 많은데 하나씩 내용을 정리하는 시간을 가져야 할 것 같다.

항해 플러스 4주차 회고

:j — Sat, 13 Apr 2024 16:25:37 +0900

4주차 과제를 진행하면서 생긴 고민

콘서트 예약 프로젝트를 선정하고, 대기열 시스템을 구현하며 동시성 테스트를 작성했는데 통과하지 못하고 있다.

대기열 구현을 잘못한 것 같아서 지금 어떻게 해결해야 할지 고민하고 있다.

동시성 테스트 시나리오는 2가지로 구성

1. 여러 명의 사용자가 동시에 신청하는 경우

-> QUEUE_LIMIT 가 50인 경우, 100명의 사용자가 신청이 들어와도 50명의 사용자만 ONGOING 상태로 들어와야 한다.

2. 한 명의 사용자가 여러 번 신청하는 경우

-> QUEUE 테이블에 한 번만 들어와야 한다.

1. 여러 명의 사용자가 동시에 신청하는 경우

이 시나리오는 ONGOING 상태의 카운트를 QueueService가 init 되는 시점에 OngoingCount를 가지고 와서 QueueOption 도메인에 AtomicLong으로 카운트를 관리하는 식으로 해결했지만, 멘토링 결과 AtomicLong으로 해결하는 것은 동시성은 통과되어도 분산 환경에서 적절하지 않은 것이라고 판단.

2. 한 명의 사용자가 여러 번 신청하는 경우

아직 해결하지 못한 문제로 갈피를 못 잡고 있는 상황이다.

대기열을 로직을 우선적으로 다시 구현을 해야 할지 다른 로직부터 먼저 구현하고 진행을 해야 할지 고민이 된다.

위에 시나리오들을 해결하기 위해서 분산 환경 및 동시성 제어 키워드로 조금 더 공부를 해야할 것 같다.

3. 엔티티와 도메인을 분리해서 사용하는 경우 infra에서 조회했을 때 값이 없는 상태인 경우..

infra 계층에서 엔티티 조회 시 값이 없는 경우에 infra에서 EntitiyNotFoundException을 throw를 해야 하나?

service계층에서 throw를 하는 게 맞을 것 같다라고 고민을 했다.

멘토링 결과 : Infra에서 값이 없는 경우에 null로 service에서 return -> service에서 null check 하는 방식으로 권장하시는 것 같다.

이번 주를 마무리하며

이번 주에 대기열 도메인을 해결하기 위해 다양한 케이스와 예외사항을 생각하면서 정말 많은 시나리오를 구상했지만 결국은 FAIL..

다시 한번 작은 단위로 쪼개서 재구성을 해보는 시간이 필요할 것 같다.

위에서 시나리오를 통과하기 위해서 대기열 테이블에 대한 row를 insert를 하지 않고, 하나의 row로 update 하면서 userId에 대한 unique key를 만들어서 해결하는 시나리오로 고민을 해보고 재구성을 해봐야 될 것 같다.

다음 주차까지 까지 완벽한 구현을 위해서 파이팅!