[ssuper 성.게군]

Swagger UI 운영환경 노출 위험에 대한 기술 가이드

성게군. — Sun, 30 Nov 2025 21:38:33 +0900

1. 개요

Swagger UI는 API 명세와 테스트 기능을 제공하여 개발 단계에서는 매우 유용하다.
그러나 운영환경(Production)에 노출될 경우, 단순한 문서 노출 수준을 넘어
시스템 내부 구조와 실행 기능이 외부 공격자에게 통째로 제공되는 심각한 보안 리스크를 초래한다.

Swagger UI는

API 구조(명세)
API 호출 기능(Try It Out)
UI 자체 취약점 가능성
을 모두 포함하는 복합적 공격 지점이 된다.

이 문서는 Swagger UI 운영환경 노출이 왜 위험한지, 어떤 공격이 가능한지,
그리고 조직에서 어떤 정책을 가져야 하는지 이해하기 쉽게 설명한다.

2. Swagger UI 운영환경 노출이 왜 위험한가

Swagger UI 노출은 아래 네 가지 문제를 동시에 발생시키며,
각 문제는 서로 연결되어 전체 공격 표면을 기하급수적으로 확장시킨다.

2.1 API 구조 전체 노출

Swagger UI는 API 문서 이상의 기능을 제공한다.
운영환경에 노출되면 다음 정보가 외부에 공개된다.

전체 엔드포인트 목록
요청 파라미터 및 검증 규칙
응답 모델과 데이터 구조
인증 필요 여부
내부용/관리자용 API 포함 여부
에러 메시지 및 동작 패턴

이 정보는 공격자가 내부 API를 역설계하지 않고도 공격 전략을 수립하도록 돕는다.
즉, 블랙박스 공격 → 화이트박스 공격으로 변환된다.

레퍼런스

StackOverflow – https://stackoverflow.com/questions/62201695/best-practices-for-swagger-ui-in-production

2.2 “Try It Out” 기능을 통한 실제 운영 데이터 접근

Swagger UI는 단순한 문서가 아니라,
운영 API를 직접 호출할 수 있는 실행 도구다.

공격자는 운영 데이터를 대상으로 다음을 시도할 수 있다.

파라미터 변조에 따른 데이터 상태 변경
인증이 느슨한 API 반복 호출 → DoS 상황 발생
관리자/정산/배치 등 내부용 API 호출
시스템 상태를 파악하기 위한 probing

레퍼런스

Codidact – https://software.codidact.com/posts/290498

2.3 인증·인가 우회 가능성

개발환경에서 Swagger를 편하게 사용하기 위해
아래 같은 설정이 종종 존재한다.

Swagger UI는 인증 없이 접근 가능
일부 API에 인증 건너뛰기 옵션 존재
Try It Out 요청 시 인증 헤더 자동 삽입
내부용 API도 문서에 표시

이 설정이 운영까지 그대로 배포되면,
인증이 필요한 API도 인증 없이 호출 가능한 보안 사고가 발생한다.

레퍼런스

Medium – https://r0x5r.medium.com/the-hidden-risk-of-swagger-ui-a-real-world-case-of-unauthorized-access-790ea9bdb033

2.4 Swagger UI 자체 취약점 악용 가능성

Swagger UI는 UI 레벨에서도 보안 취약점이 보고된 바 있다.

XSS (스크립트 실행)
HTML Injection
쿼리 파라미터 조작 기반 공격

운영환경에 Swagger UI가 노출될 경우
브라우저 측 공격(토큰 탈취, 세션 하이재킹) 의 통로가 된다.

레퍼런스

InfoSec Writeups –
https://infosecwriteups.com/the-dark-side-of-swagger-ui-how-xss-and-html-injection-can-compromise-apis-1b670972a443

3. 공격 시나리오 예시

Swagger UI가 운영환경에 노출되었을 때 실제로 가능한 전형적 공격 흐름은 다음과 같다.

공격자가 /swagger-ui 또는 /v3/api-docs에 접근
내부·관리자·정산 API 등 민감 엔드포인트 확인
인증이 없는 API 또는 인증 취약점 탐색
Try It Out 기능으로 실제 운영 데이터 호출
파라미터 변조, 권한 우회, 대량 요청 등 공격 수행
결과: 데이터 오염, 서비스 중단, 권한 침해, 내부 정보 유출

4. 운영환경에서의 관리 원칙

4.1 기본 원칙

운영환경에서는 Swagger UI 및 api-docs는 기본적으로 비활성화한다.

4.2 예외 허용 기준

부득이한 경우 아래 조건 모두 충족 시 제한적 허용 가능.

VPN/사내망/IP 화이트리스트 기반 접근 제한
별도 인증(Basic Auth, OAuth 등) 적용
비표준 Swagger 경로 사용 (/swagger → /internal-docs 등)
Try It Out 기능 비활성화 고려
외부공개 절대 금지

레퍼런스

Baeldung – https://www.baeldung.com/swagger-ui-turn-off-in-production

5. 결론

Swagger UI는 개발환경에서는 생산성을 높이는 도구이지만,
운영환경에서는 “API 문서 + API 실행기 + 잠재적 취약점”을 외부에 제공하는 공격 표면이 된다.

운영환경 Swagger 노출은
내부 설계서 + API 호출 도구 + 디버깅 콘솔을 공격자에게 무료로 제공하는 것과 같다.

따라서 운영환경에서는 반드시 비활성화 하며,
예외가 필요한 경우에도 강력한 접근 제어가 필수적이다.

Appendix. Swagger UI 운영환경 노출 관련 다이어그램

본 Appendix는 본문 설명을 시각적으로 이해할 수 있도록
“공격 흐름”과 “공격 표면 확장 구조”를 다이어그램으로 정리한 것이다.

A-1. Attack Flow

sequenceDiagram
    participant A as 공격자
    participant S as Swagger UI (운영환경)
    participant API as 내부 API 서버

    A->>S: 운영환경 Swagger UI 접근 (/swagger-ui)
    S-->>A: API 엔드포인트·요청/응답 스키마 노출
    A->>A: 민감/내부용 API 식별
    A->>S: Try It Out으로 요청 생성
    S->>API: 실제 운영 API 호출
    API-->>S: 실제 데이터/에러정보 반환
    S-->>A: 응답 노출
    A->>API: 대량 호출·변조 공격 실행

A-2. Attack Surface

graph TD

    A[운영환경 Swagger UI 노출] --> B[API 스펙·구조 전체 노출]
    A --> C[Try It Out 기능 활성화]
    A --> D[인증/인가 우회 가능성]
    A --> E[Swagger UI 자체 취약점 노출]

    B --> F[엔드포인트 수집]
    B --> G[파라미터 브루트포싱]
    C --> H[운영 데이터 변조]
    C --> I[대량 호출·서비스 부하]
    D --> J[내부용 API 접근]
    E --> K[XSS·브라우저 공격]

    F --> L[화이트박스 기반 공격]
    J --> M[권한 오용·정보 유출]

성수동 월정기 주차 신청 가이드 (2025년 6월)

성게군. — Sun, 29 Jun 2025 02:17:55 +0900

성수동 월정기 주차 신청 가이드

성수동에서 월정기 주차를 신청하려면, 공영주차장과 민간 주차장을 각각 어떻게 이용할 수 있는지 알아보는 것이 중요합니다. 이 포스팅에서는 공영주차장과 민간 주차장 월정기 신청 절차와 각각의 장단점을 상세히 비교해드리겠습니다.

1공영주차장 월정기 신청 절차

회원가입 및 본인인증

성동구 도시관리공단 홈페이지에서 회원가입 후 본인인증 진행

배정기준 확인

거주기간, 대기기간 등 배점 기준 미리 확인

정기권 신청

매월 공고에 따라 선착순 또는 추첨으로 신청

결제 및 이용시작

1개월 선납 결제 후 바로 이용 가능

신청 방법

사이트: 성동구 도시관리공단 홈페이지

회원가입: 회원가입 바로가기

필요 서류: 주민등록증, 차량 등록증

주요 사항: 온라인 서비스에서 회원가입 후 본인 인증을 거쳐 차량 정보를 등록합니다.

배정 기준 확인

배점 기준: 성동구 거주 기간, 대기 기간 등

우선순위: 장애인, 국가유공자 등의 특혜 대상

배정경쟁률: 실시간 경쟁률 확인

정기권 신청

매월 정기권 신청 공고에 따라 신청 가능

선착순 또는 추첨 방식으로 진행

신청 사이트: 서울시설공단 정기권 신청

결제 및 이용

결제 방식: 1개월 선납

이용 기간: 매월 1일부터 말일까지 이용 가능

환불 및 취소 정책

중도 해지 시 잔여 기간 80% 환불 가능하며, 감면 적용 후 소급 환불은 불가합니다.

할인 혜택:

80% 할인: 장애인, 국가유공상이자, 고엽제후유증환자
50% 할인: 경차(1,000cc 미만), 저공해차량, 5.18민주유공자, 다둥이카드(3자녀 이상)
30% 할인: 다둥이카드(2자녀)

2민간 주차장 월정기 신청

성수동 민간 주차장 현황

이용 가능

이용 중

민간 주차장은 성수동 일대에서도 이용 가능하며, 주차 요금은 공영주차장보다 다소 높을 수 있습니다. 하지만 일부 민간 주차장에서는 공영주차장보다 더 유연한 시간대와 장소에서 월정기를 신청할 수 있는 장점이 있습니다.

주요 민간 주차장 현황

성수역 인근 자주식 주차장

월정기 요금: 약 400,000원

주차 방식: 자주식 주차

위치: 성수역 인근

모두의 주차장 앱 제휴

월정기 요금: 100,000원~200,000원

위치: 서울숲 디타워, 갤러리아포레더몰

주차 방식: 기계식 및 자주식

앱 다운로드: Android | iOS

성수빌딩 주차장

월정기 요금: 100,000원~200,000원

특징: 건물별 개별 문의 필요

3공영주차장 vs 민간주차장 비교

비교 항목	공영주차장	민간주차장
신청 절차	온라인/대면 신청, 배점 및 추첨 기준	현장 등록, 문의 후 신청
월정기 요금	약 70,000원	100,000원~400,000원
할인 혜택	장애인, 저공해차량 등 할인 적용	일부 업체에서 자체 할인 적용 가능
경쟁률	높음 (선착순/추첨)	상대적으로 낮음
이용 편의성	제한적	상대적으로 유연함

4민간주차장 월정기 이용 가능 현황

최소 확인된 곳: 1곳 이상

예상 가능한 주차장: 3~5곳 (주차장 앱, 커뮤니티, 현장 문의를 통해 확인 필요)

참고사항: 성수동 일대의 민간주차장은 건물별로 운영 정책이 다르므로 개별 문의가 필요합니다.

유용한 사이트:

모두의주차장 웹사이트 - 월정기권 검색
모두의주차장 지도 - 성수동 주변 주차장 검색
TMAP 앱 - 통합 모빌리티 플랫폼

5성공적인 주차장 신청을 위한 팁

알아두면 유용한 팁

공영주차장: 매월 발매 공고를 미리 확인하고, 신청 시작과 동시에 빠르게 접속하여 선착순으로 신청
민간주차장: 모두의주차장, TMAP 등의 앱을 활용하여 사전에 요금과 위치를 비교 검토
가격 vs 편의성: 공영주차장은 저렴하지만 경쟁이 치열하고, 민간주차장은 비싸지만 선택지가 많음
할인 혜택: 저공해차량, 장애인 등 해당 사항이 있다면 반드시 할인 혜택을 확인하고 신청

️ 공영주차장 신청 전략

• 성동구 거주 기간이 길수록 유리

• 매월 15일경 다음 달 신청 공고 확인

• 신청 시간 정확히 맞춰서 접속

• 여러 주차장에 동시 신청 가능한지 확인

민간주차장 이용 전략

• 주차장 앱으로 사전 요금 비교

• 월정기 할인 이벤트 시기 노려보기

• 건물 관리사무소에 직접 문의

• 계약 조건 및 환불 정책 확인

문의 및 신청 연락처

️ 성동구 도시관리공단

홈페이지: parking.happysd.or.kr

전화번호: 02-2202-5077

업무시간: 평일 09:00~18:00

주차장 현황: 공영주차장 현황 보기

주차 앱 관련 연락처

모두의주차장: 1899-8242

웹사이트: moduparking.com

TMAP 주차: 1544-7116

앱 다운로드: TMAP 주차 앱

특징: 실시간 주차장 정보 및 할인 혜택 제공

국내 주요 증권사 앱(MTS) 비교 정리 (2025년 6월 기준)

성게군. — Sun, 29 Jun 2025 01:52:07 +0900

증권사 MTS 간단 비교

1. 수수료 비교

증권사	앱명	수수료율	1천만원 거래시	비고
삼성증권	mPOP	0.0036%	364원	최저 수준
미래에셋증권	m.Stock	0.0036%	364원	최저 수준
한국투자증권	eFriend Smart	0.0036%	364원	최저 수준
NH투자증권	나무	0.0043% → 0.01%	433원 → 1,000원	이벤트 기간 후 인상
키움증권	영웅문S#	0.015%	1,500원	전문가 기능 특화
KB증권	M-able	0.015%	1,500원	초보자 친화적
메리츠증권	mCLASS	0.015%	1,500원	미국주식 무료
한화투자증권	통합 MTS	0.015%	1,500원	AI 기능 강화
토스증권	토스증권	0.015%	1,500원	최고 UX 평가
카카오페이증권	카카오페이증권	0.015%	1,500원	간편 송금 연계

수수료 핵심 정리

최저 수수료: 삼성, 미래에셋, 한국투자증권 (0.0036%)
NH투자증권은 이벤트 기간 후 수수료 인상 예정
1천만원 거래 기준 최대 4배 차이 (364원 vs 1,500원)
빈번한 거래자는 수수료 차이가 크게 영향

2. 월간 활성 사용자 수 (MAU)

순위	증권사	MAU	특징
1위	NH투자증권 나무	418만명	압도적 1위, 꾸준한 상승
2위	키움증권 영웅문S#	260만명	전문가층 중심 안정적 유지
3위	삼성증권 mPOP	228만명	AI 기능으로 사용자 증가
4위	미래에셋증권 m.Stock	225만명	해외주식 기능 개선으로 상승
5위	KB증권 M-able	194만명	편의성으로 꾸준한 증가
6위	한국투자증권 eFriend	80만명	안정적 유지

3. 앱 활용성 및 주요 기능

키움증권 영웅문S#

전문가 선호

• HTS급 기능 제공

• 고급 차트 분석

• 자동매매 시스템

삼성증권 mPOP

AI 특화

• 리서치 기능 우수

• AI 포트폴리오 제공

• 인공지능 투자 도구

미래에셋증권 m.Stock

해외투자

• 해외주식 원스톱 기능

• 직관적 UI

• 글로벌 투자 특화

NH투자증권 나무

사용자 1위

• 빠른 속도

• 초보자 친화적 인터페이스

• 편리한 기능 제공

토스증권

최고 UX

• 직관적이고 깔끔한 디자인

• 핀테크 기반 혁신

• 간편한 사용성

메리츠증권 mCLASS

미국주식 무료

• 미국주식 거래 특화

• 해외투자 혜택 중심

• 급성장 중

투자 스타일별 맞춤 추천

최저 수수료 중심

삼성증권, 미래에셋증권, 한국투자증권

동일한 최저 수수료 0.0036%, 빈번한 거래자에게 유리

전문가급 기능

키움증권 영웅문S#

HTS급 차트, 자동매매, 고급 분석 도구 제공

초보자 & UX 우선

NH 나무, KB M-able, 토스증권

직관적 인터페이스, 편리한 기능, 높은 사용자 만족도

해외투자 & AI

한화투자증권, 미래에셋증권

AI 기능, 해외주식 특화, 글로벌 투자 도구

미국주식 중심

메리츠증권 mCLASS

미국주식 거래 수수료 무료, 해외투자 혜택

간편투자

토스증권, 카카오페이증권

핀테크 기반, 간편 송금 연계, 혁신적 UX

증권사 홈페이지 바로가기

삼성증권

미래에셋증권

한국투자증권

NH투자증권

키움증권

KB증권

메리츠증권

한화투자증권

토스증권

카카오페이증권

Software Algorithm 10

성게군. — Fri, 25 Oct 2024 23:13:39 +0900

1. DFS (깊이 우선 탐색, Depth-First Search)

사용: 그래프 탐색, 백트래킹, 경로 찾기
특징: 한 경로를 끝까지 탐색한 후 다른 경로로 넘어가는 방식
응용 문제: 미로 찾기, 섬의 개수 세기, 그래프에서의 경로 탐색

def dfs(graph, v, visited):
    visited[v] = True
    print(v, end=' ')
    for i in graph[v]:
        if not visited[i]:
            dfs(graph, i, visited)

2. BFS (너비 우선 탐색, Breadth-First Search)

사용: 그래프 탐색, 최단 경로 탐색
특징: 가까운 노드부터 탐색하는 방식 (큐를 사용)
응용 문제: 최단 경로 문제, 미로 찾기

from collections import deque

def bfs(graph, start, visited):
    queue = deque([start])
    visited[start] = True
    while queue:
        v = queue.popleft()
        print(v, end=' ')
        for i in graph[v]:
            if not visited[i]:
                queue.append(i)
                visited[i] = True

3. 이진 탐색 (Binary Search)

사용: 정렬된 배열에서의 탐색
특징: 중간값과 비교해 탐색 범위를 절반씩 줄여나가는 방식
응용 문제: 특정 값 찾기, 범위를 빠르게 좁히는 문제

def binary_search(arr, target):
    left, right = 0, len(arr) - 1
    while left <= right:
        mid = (left + right) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid - 1
    return -1

4. 다익스트라 알고리즘 (Dijkstra's Algorithm)

사용: 가중치가 있는 그래프에서의 최단 경로 탐색
특징: 우선순위 큐(최소 힙)를 사용해 현재까지의 최단 경로를 계속 갱신하는 방식
응용 문제: 특정 노드에서 다른 노드까지의 최단 경로

import heapq

def dijkstra(graph, start):
    distances = {node: float('inf') for node in graph}
    distances[start] = 0
    queue = [(0, start)]
    
    while queue:
        current_distance, current_node = heapq.heappop(queue)
        
        if current_distance > distances[current_node]:
            continue
        
        for adjacent, weight in graph[current_node].items():
            distance = current_distance + weight
            if distance < distances[adjacent]:
                distances[adjacent] = distance
                heapq.heappush(queue, (distance, adjacent))
    
    return distances

5. 동적 계획법 (Dynamic Programming, DP)

사용: 작은 문제를 풀고, 그 결과를 저장해서 큰 문제를 푸는 방식
특징: 재귀적 접근과 메모이제이션을 사용해 중복 계산을 피함
응용 문제: 피보나치 수열, 배낭 문제, 최소 비용 경로

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n <= 1:
        return n
    memo[n] = fib(n-1, memo) + fib(n-2, memo)
    return memo[n]

6. 최소 신장 트리 (Minimum Spanning Tree, MST)

사용: 그래프에서 모든 정점을 연결하는 최소 비용의 트리 구하기
주요 알고리즘: Kruskal's Algorithm, Prim's Algorithm
응용 문제: 네트워크 연결, 도로 건설
크루스칼 알고리즘 (Kruskal's Algorithm):
- 간선을 정렬한 후 최소 비용으로 연결하는 방식 (Union-Find 사용)

def find(parent, x):
    if parent[x] != x:
        parent[x] = find(parent, parent[x])
    return parent[x]

def union(parent, a, b):
    rootA = find(parent, a)
    rootB = find(parent, b)
    if rootA < rootB:
        parent[rootB] = rootA
    else:
        parent[rootA] = rootB

7. 투 포인터 (Two Pointer)

사용: 배열에서 두 개의 포인터를 사용해 특정 조건을 만족하는 구간 찾기
특징: 양 끝에서 포인터를 이동시켜가며 문제 해결
응용 문제: 부분합 구하기, 특정 구간 찾기

def two_pointer(arr, target):
    left, right = 0, len(arr) - 1
    while left < right:
        current_sum = arr[left] + arr[right]
        if current_sum == target:
            return (left, right)
        elif current_sum < target:
            left += 1
        else:
            right -= 1
    return None

8. 슬라이딩 윈도우 (Sliding Window)

사용: 고정된 크기 또는 가변적인 크기의 구간을 이동하면서 문제 해결
특징: 부분 합, 최대값/최소값을 구하는 문제에 적합
응용 문제: 최대 부분합 구하기, 문자열에서 특정 패턴 찾기

def sliding_window(arr, k):
    current_sum = sum(arr[:k])
    max_sum = current_sum
    
    for i in range(k, len(arr)):
        current_sum += arr[i] - arr[i - k]
        max_sum = max(max_sum, current_sum)
    
    return max_sum

9. 유니온 파인드 (Union-Find)

사용: 그래프에서 연결된 컴포넌트를 찾는 알고리즘
특징: 집합을 합치고 연결 여부를 판단할 때 사용 (서로소 집합)
응용 문제: 사이클 판별, 네트워크 연결 여부 확인

def find(parent, x):
    if parent[x] != x:
        parent[x] = find(parent, parent[x])
    return parent[x]

def union(parent, a, b):
    rootA = find(parent, a)
    rootB = find(parent, b)
    if rootA != rootB:
        parent[rootB] = rootA

10. 백트래킹 (Backtracking)

사용: 가능한 모든 경우를 탐색하면서 조건을 만족하는 해를 찾는 방식
특징: 해를 찾다가 조건에 맞지 않으면 이전 단계로 돌아가는 방식
응용 문제: N-Queen 문제, 부분 집합 구하기

def backtracking(path, choices):
    if 조건에 만족:
        결과 저장
        return
    for choice in choices:
        if 조건에 맞는 choice:
            backtracking(path + [choice], choices)

이 외에도 정렬 알고리즘(퀵 정렬, 병합 정렬), 그리디 알고리즘, 문자열 처리 알고리즘(KMP, 라빈-카프 알고리즘) 등이 코딩 테스트에서 자주 사용됩니다.

Why you should never default to Microservices

성게군. — Fri, 25 Oct 2024 11:08:29 +0900

https://levelup.gitconnected.com/why-you-should-never-default-to-microservices-c952903fbcb6

Why you should never default to Microservices

Disclaimer: Grumpy Goose Warning

levelup.gitconnected.com

Complexity in Testing

소프트웨어는 99개의 기능이 올바르게 동작하고 1개의 기능이 실패했을 때, 그 99개의 성공에 대해 점수를 얻지 못하기 때문에 어렵습니다. 모든 것이 제대로 작동해야 합니다. 따라서 모든 것을 함께 테스트하거나, 테스트 범위가 넓어져야 합니다.
테스트 범위는 단일 테스트 내에서 얼마나 많은 것을 테스트할 수 있는지를 측정하는 척도입니다.
범위가 작을수록 실제 사용자 경험에서 멀어지게 됩니다. 즉, 테스트가 통과하더라도 기능이 제대로 동작한다는 의미는 덜하고, 테스트가 실패하더라도 기능이 제대로 작동하지 않는다는 의미는 덜하게 됩니다.

모놀리식 구조에서는 큰 범위를 테스트하는 것이 쉽습니다.
왜냐하면 모놀리식 구조는 모든 것을 다루기 때문입니다.

그러나 마이크로서비스에서는 같은 과정이 더 복잡해집니다.
마이크로서비스에서는 테스트 범위가 마이크로서비스의 자연적인 경계에 의해 제한됩니다.

일반적인 마이크로서비스 테스트 설정

이로 인해 우리는 동작을 모의(Mock)하거나 스텁(Stub)해야만 합니다.
이는 주문 서비스나 이행 서비스에서 변경되거나 추가된 동작이 무시된다는 의미입니다.
따라서, 테스트가 통과한다고 해서 기능이 제대로 작동할 가능성은 더 적어지고, 테스트가 실패한다고 해서 기능이 제대로 작동하지 않는다는 의미는 덜하게 됩니다.

이 수준에서 10,000개의 테스트가 통과하더라도, 여전히 아래와 같은 버그들이 발생할 수 있습니다.

비즈니스 로직의 변화로 인해 발생하는 다양한 오류
주문 서비스나 상품 서비스의 데이터나 계약에서 발생하는 문제

이러한 상호작용을 실제로 테스트하지 않고, 대신 이를 모의하고 있기 때문입니다.
처음에는 문제가 되지 않더라도, 프로세스가 복잡해지고 변화함에 따라 문제가 될 것입니다.
그 결과 UAT(사용자 수용 테스트)에서 더 많은 버그를 발견하게 되거나, 모의 객체들을 더 지능적으로 만들어야 할 것입니다. 이는 시간을 낭비하는 좋은 방법이죠.

이 방식은 각 개발자가 코드를 병합하기 전에 수동으로 두 가지를 함께 테스트해야 한다는 지식과 주의에 의존합니다. 제 경험상, 이것은 일관성이 없습니다.
결국, 버그는 자동화된 테스트보다는 수동 테스트를 통해 UAT에서 발견됩니다. 이는 마치 10파운드짜리 버거를 100파운드에 사는 것과 같습니다.
이러한 문제들이 놓쳐서 실제 프로덕션에 배포된다면, 이는 1000파운드를 쓰는 것과 마찬가지입니다.

모놀리식 구조에서는 이와 같은 테스트 스위트를 쉽게 가질 수 있습니다.
모의 객체(Mock), 스텁(Stub), 가짜 데이터(fake), 속임수 없이 모든 것을 테스트할 수 있는 범위를 제공하므로, 테스트가 통과하면 기능이 실제로 작동할 가능성이 더 높아지고, 테스트가 실패하면 기능이 작동하지 않는다는 의미가 더 명확해집니다.

이 방식은 훨씬 간단한 테스트 방법입니다.
이는 그날의 경험, 지식, 완벽함, 혹은 충분한 카페인이 없어도 작동합니다.
모의 객체(Mock)를 최신 상태로 유지하거나 지능적으로 만들 필요도 없습니다.
그리고 정말로 하나의 서비스를 모의하고 싶다면, 매우 간단하게 할 수 있습니다.

Complicating your infrastructure

복잡한 웹 시스템 안에서 서로 통신해야 하는 작업에 갇히면, 상황이 매우 빠르게 복잡해집니다.

단계 추가하기

예시: 새로운 엔드포인트 추가.

모놀리식 구조
1. 엔드포인트 생성
2. 엔드포인트에 대한 권한 생성
3. 프론트엔드에 엔드포인트 연결
마이크로서비스 구조
1. 엔드포인트 생성
2. 엔드포인트에 대한 사용자 권한 생성
3. 엔드포인트 인프라 생성
4. 새로운 마이크로서비스를 위한 파이프라인 생성
5. n — 모든 마이크로서비스가 이 엔드포인트와 통신할 수 있도록 권한 생성
6. n — 모든 인프라 코드를 올바르게 업데이트하고, 직접 수정된 것이 없는지 확인
7. n — 엔드포인트를 연결

이렇게 3단계에서 4 + (3 * n)단계로 바뀌었습니다.

또한 여러 가지 실패 지점을 만들었고, 테스트하기도 매우 어려워졌습니다.

Managing split timelines

만약 인프라가 완전히 별도의 인프라 팀에 의해 관리된다면(제가 절대 추천하지 않는 방식), 인도(배포)는 거의 확실하게 어려울 것입니다. 그들이 아무리 잘하더라도 말이죠.

당신이 답해야 하는 질문은 "다음 스프린트 내에 이 작업을 완료할 수 있을까요?"가 아닙니다.
대신에 다음과 같은 질문들을 답해야 합니다.

"다음 스프린트 내에 이 작업을 완료할 수 있을까요?"
"인프라 팀이 다음 스프린트 내에 이 작업을 끝낼 수 있을까요? 그리고 그들이 우리를 차단하지 않도록 제시간에 준비할 수 있을까요?"

역사적으로 볼 때, 첫 번째 질문에 대한 답은 "네"일지 몰라도, 두 번째 질문에 대한 답은 "아니요"일 가능성이 큽니다.
이는 인프라 팀의 잘못이 아니며, 그냥 현실입니다. 이 상황에서 그 팀을 비즈니스 팀, QA 팀, 배포 팀, 또는 다른 어떤 팀으로 대체해도 마찬가지입니다.
한 개의 타임라인이 아니라 여러 개의 타임라인을 관리하게 되면, 우선순위와 일정이 충돌하게 됩니다.

그래서 프로젝트 매니저가 "이 기간 내에 이 작업을 완료할 수 있나요?"라고 물으면, 대답이 "네/아니요"에서 "모르겠어요, 제 손에 달린 일이 아니에요"로 바뀌게 됩니다.

프로젝트에 얼굴을 내밀고, 손은 제어할 수 없는 상황에 놓이게 되면, 당신도 기분이 나빠질 것입니다.

타임라인을 분리하면 한 팀에서 할 수 있는 것에 따라 단축이나 타협을 유도할 수 있습니다. 이것은 더 나쁜 설계로 이어질 수 있으며, 이는 프로젝트에서 할 수 있는 두 번째로 비용이 많이 드는 일일 수 있습니다.

Are Microservices a terrible idea?

아니요, 그들이 그렇지는 않습니다. 그들에게는 대체할 수 없는 두 가지 장점과 대체 가능한 한 가지가 있습니다.

독립적인 배포 가능성 (147개의 파이프라인을 즐기세요) — 독립적인 개발 팀을 포함하여, 이런저런 것들.
독립적인 확장성.
관심사의 명확한 분리 — 이것은 원칙을 준수하는 강력한 개발 팀으로 대체할 수 있습니다.

하지만 그들은 많은 복잡성을 추가합니다.

만약 당신이 일을 끝내는 종류의 개발자라면 — 그리고 그래야 한다고 생각합니다 — 복잡성을 추가하는 것은 항상 강력한 이유가 필요합니다.

강력한 이유 없이 뛰어드는 것은 논리적인 것이 아닌, 교조주의적 결정에 기울어지기 쉽습니다. 그리고 그것은 아주 나쁜 생각입니다.

Conclusion

먼저 모놀리식 구조로 시작하세요. 큰 범위의 테스트를 잘 수행하고, 경계에 집착하세요. 모놀리식 경계를 마이크로서비스처럼 취급하며, API가 아닌 인터페이스를 통해 상호작용하도록 하세요. 경계를 나눌 필요성이 생길 때까지는 나누지 마세요. 배포성, 확장성, 독립적인 팀 작업에 대한 명확한 이유가 있을 때만 나누고, 테스트 수준을 유지할 방법을 구체적으로 문서화하세요. 좋은 이유가 있으면 진행하고, 그렇지 않으면 모놀리식 구조를 유지하세요.

빠르고 간편한 해결책을 찾는 것이 중요합니다.

System Design — Tips

성게군. — Thu, 10 Oct 2024 17:09:20 +0900

https://medium.com/javarevisited/system-design-tips-62c26366cf48

System Design — Tips

Designing a robust and scalable system involves careful planning and consideration of various factors. Here are some essential tips to…

medium.com

다음은 시스템 설계 시 유용한 몇 가지 팁입니다.

1. 요구 사항 이해하기

기능적 요구 사항: 시스템이 수행해야 할 기능 및 특징.
비기능적 요구 사항: 성능, 확장성, 보안, 가용성 등.

2. 적절한 아키텍처 선택하기

모놀리식 vs. 마이크로서비스: 하나의 큰 애플리케이션으로 만들지, 마이크로서비스로 분할할지 결정합니다.
계층형 아키텍처: 프레젠테이션, 애플리케이션, 비즈니스, 데이터 계층 등으로 나누어 관심사를 분리합니다.

3. 확장성

수평 확장(Horizontal Scaling): 서버를 추가하여 부하를 처리합니다.
수직 확장(Vertical Scaling): 기존 서버에 더 많은 자원(CPU, RAM)을 추가합니다.
로드 밸런싱: 트래픽을 여러 서버에 분산시켜 특정 서버가 과부하되지 않도록 합니다.

4. 데이터베이스 설계

정규화 vs. 비정규화: 중복을 줄이는 정규화와 읽기 성능을 높이는 비정규화 사이의 균형을 맞춥니다.
적절한 데이터베이스 선택: 관계형 데이터에는 SQL, 비정형 데이터에는 NoSQL을 사용합니다.
샤딩(Sharding): 대규모 데이터와 높은 트래픽을 처리하기 위해 데이터를 여러 데이터베이스로 분산합니다.
락 메커니즘: 낙관적/비관적 동시성 제어를 사용하여 데이터 충돌을 방지합니다.

5. 분산 락

데드락 방지: 프로세스가 크래시될 때를 대비해 락에 TTL(수명)을 설정합니다.
갱신 메커니즘: 락을 보유한 프로세스가 더 많은 시간이 필요할 경우 갱신할 수 있게 합니다.
Redis: SETNX 명령어를 사용해 간단한 락 메커니즘 구현.
Zookeeper & Etcd: 강력한 일관성 보장을 위한 복잡한 분산 락 시스템.

6. 분산 캐싱

데이터 캐싱: 자주 접근하는 데이터를 캐시에 저장하여 데이터베이스 부하를 줄이고 응답 속도를 높입니다.
CDN: 콘텐츠 전송 네트워크를 사용하여 정적 콘텐츠를 사용자에게 더 가까운 곳에서 제공.
파티셔닝: 높은 처리량을 위해 데이터를 여러 파티션 또는 샤드로 분산.

7. 장애 내성 및 고가용성

중복성: 단일 장애 지점을 방지하기 위해 중요한 구성 요소를 중복합니다.
페일오버 메커니즘: 장애 발생 시 대기 시스템으로 자동 전환.
백업 및 복구: 데이터를 정기적으로 백업하고 복구 계획을 마련합니다.

8. 보안

인증 및 권한 관리: 사용자가 자신이 누구인지 증명하고, 적절한 리소스에 접근할 수 있도록 합니다.
암호화: 중요한 정보를 보호하기 위해 데이터 저장 및 전송 중에 암호화를 사용합니다.
방화벽 및 침입 탐지: 네트워크 보안 조치를 통해 비인가 접근을 탐지하고 방지합니다.

9. 모니터링 및 로깅

실시간 모니터링: 시스템 성능과 상태를 실시간으로 추적하는 모니터링 도구 사용.
로깅: 시스템의 동작을 분석하고 디버깅할 수 있도록 로그를 유지합니다.

10. API 및 통신

RESTful API: 웹 서비스 확장성과 무상태 통신을 위해 REST를 사용합니다.
메시지 큐: 서비스 간 비동기 통신을 위해 RabbitMQ, Kafka와 같은 메시지 큐를 사용합니다.

11. 개발 모범 사례

버전 관리: Git과 같은 버전 관리 시스템을 사용하여 변경 사항을 추적하고 협업합니다.
CI/CD(지속적 통합/지속적 배포): 테스트와 배포를 자동화하여 빠르고 신뢰성 있는 업데이트를 제공합니다.
코드 리뷰: 정기적인 코드 리뷰를 통해 코드의 품질과 일관성을 유지합니다.

Throttling Design Pattern to Handle an Extreme Load

성게군. — Thu, 10 Oct 2024 16:59:24 +0900

https://medium.com/@dmosyan/throttling-design-pattern-to-handle-an-extreme-load-a0b24c31e3ec

리소스 소비 제어는 애플리케이션이나 서비스가 과도한 부하가 걸릴 때에도 시스템이 계속 작동하고 SLA(서비스 수준 협약)를 충족할 수 있게 해줍니다. 애플리케이션의 부하는 시간에 따라, 활성 사용자 수나 그들이 수행하는 활동의 종류에 따라 달라집니다. 만약 시스템의 처리 요구 사항이 사용 가능한 리소스 용량을 초과하면 성능 저하나 시스템 오류가 발생할 수 있습니다. 이를 해결하기 위해 클라우드에서는 여러 전략을 사용할 수 있으며, 그 중 하나가 자동 확장(autoscaling)을 통해 사용자의 요구에 맞게 리소스를 동적으로 조정하는 것입니다. 이 방법은 사용자 수요를 충족시키면서도 비용을 최적화할 수 있습니다.

문제점과 해결 방안

자동 확장은 추가 리소스 제공을 트리거할 수 있지만, 리소스가 즉시 제공되지 않는 경우가 있습니다. 수요가 급증할 때, 리소스 부족이 발생할 수 있는 짧은 시간 동안 문제가 생길 수 있습니다.

이를 해결하기 위한 대안 전략은 애플리케이션이 리소스를 일정 한도까지만 사용하도록 하고, 이 한도에 도달하면 요청을 제한하는 방식(스로틀링, throttling)을 사용하는 것입니다. 시스템은 리소스 사용을 모니터링하여 임계값을 초과하면 특정 사용자나 요청을 제한할 수 있어야 합니다.

스로틀링 전략

요청 거부: 특정 사용자가 정해진 시간 동안 시스템 API를 초과해 요청하면 요청을 거부하는 방식입니다.
비필수 서비스의 기능 제한: 중요한 서비스가 충분한 리소스를 확보하도록 비필수 기능을 비활성화하거나 기능을 저하시키는 방법입니다. 예를 들어, 스트리밍 서비스는 해상도를 낮출 수 있습니다.
부하 평준화: 우선 순위 대기열(priority queue)을 사용하여 SLA가 높은 테넌트의 요청은 즉시 처리하고, 그 외의 요청은 대기시키는 방식입니다.

3rd-party 서비스 통합 시 주의 사항

외부 서비스가 비활성화되거나 오류를 반환할 수 있으므로, 동시 요청 수를 줄여 오류 로그가 불필요하게 많이 쌓이지 않도록 해야 합니다. 성공적으로 처리된 후에는 다시 정상적인 요청 처리로 돌아갈 수 있습니다.

자동 확장과 스로틀링의 조합

자동 확장과 스로틀링을 결합하면 애플리케이션이 높은 수요 속에서도 SLA를 유지할 수 있습니다. 높은 수요가 지속될 것으로 예상되면 스로틀링을 임시적으로 사용하여 시스템이 확장될 시간을 확보할 수 있습니다.

고려 사항

스로틀링은 애플리케이션 설계 초기에 고려해야 하며, 구현 후 추가하기는 어렵습니다.
스로틀링은 빠르게 이루어져야 하며, 로드가 완화되면 원래 상태로 신속히 돌아가야 합니다.
스로틀링 중인 서비스가 사용자 요청을 거부할 때는 429(“Too many requests”) 또는 503(“Server Too Busy”)와 같은 오류 코드를 반환해야 합니다.

사용 시기

SLA를 유지하기 위해.
특정 테넌트가 리소스를 독점하지 않도록 하기 위해.
갑작스러운 부하를 처리하기 위해.
비용 최적화를 위해 리소스 사용을 제한하기 위해.

예시

여러 테넌트 조직의 사용자들이 설문조사를 제출하는 클라우드 애플리케이션에서, 한 테넌트의 사용자가 지나치게 많은 요청을 보내면, 다른 테넌트의 사용자들에게 영향을 미치지 않도록 요청 수에 한도를 설정하여 그 이상의 요청을 차단하는 방식입니다.

How to Prevent Duplicate Requests Effectively

성게군. — Wed, 9 Oct 2024 19:57:37 +0900

https://medium.com/javarevisited/rest-api-how-to-prevent-duplicate-requests-effectively-d3be88ef7838

Rest API: How to Prevent Duplicate Requests Effectively

The solution to prevent duplicate requests that I want to talk about here is that when a user manipulates an API feed

medium.com

구현 아이디어

사용자가 API를 호출할 때, 요청 본문(Request Body)에서 특정 데이터를 추출하여 Redis 키를 생성합니다.
이 키는 MD5로 해시되어 저장되며, Redis에 키가 이미 존재하는지 여부를 확인합니다.
만약 Redis에 키가 존재하면 중복 요청으로 간주하고 오류를 반환합니다.
키가 존재하지 않으면 Redis에 새로운 키를 저장하고, 이 키는 일정 시간이 지나면 만료됩니다.

구현 순서

특정 필드(예: productId, transactionId)를 기반으로 Redis 키를 생성하고, 필요 시 옵션 값을 추가하여 유연하게 중복 요청을 방지할 수 있도록 합니다.
생성된 키는 MD5로 해시하여 저장하고, 키의 유효 시간(예: 40초)을 설정합니다.
중복 요청이 발생하면 DuplicationException을 발생시켜 클라이언트에 오류 메시지를 반환합니다.

주요 클래스 및 설명

PreventDuplicateValidator : 중복 요청 방지를 위한 커스텀 어노테이션. 필드 목록과 키 만료 시간을 설정할 수 있습니다.
PreventDuplicateValidatorAspect : 어노테이션에 지정된 필드를 기준으로 Redis 키를 생성하고, 중복 요청을 확인하는 로직을 구현합니다.
Utils : 요청 본문을 추출하고 MD5 해시를 생성하는 유틸리티 클래스입니다.
HandleGlobalException : 중복 요청 발생 시 던져진 DuplicationException을 처리하여 클라이언트에 적절한 오류 메시지를 반환합니다.

테스트

Postman을 사용하여 API 요청을 보냅니다. 첫 번째 요청은 성공적으로 처리되고 Redis에 키가 저장됩니다.
두 번째로 동일한 요청을 보내면 Redis에 키가 이미 존재하므로 중복 요청으로 처리되고 오류 메시지가 반환됩니다.

결론

중복 요청 방지를 위해 어떤 필드를 사용할지 신중히 선택해야 합니다.
키의 만료 시간을 비즈니스 요구사항에 맞게 조정할 필요가 있습니다.
성능 최적화를 위해 MD5 해시 사용 여부를 고려해야 합니다.

Optimizing Java App Performance by understanding JVM Architechture

성게군. — Wed, 9 Oct 2024 00:16:49 +0900

https://medium.com/@kiarash.shamaii/optimizing-java-app-performance-by-understanding-jvm-architechture-7bd32eeac520

Optimizing Java App Performance by understanding JVM Architechture

As Java developers, we’re often tasked with building high-performance applications that can handle demanding workloads and provide a…

medium.com

힙 메모리 관리:
- 메모리 누수: 객체가 더 이상 필요 없는데도 메모리에서 해제되지 않으면 힙 메모리가 계속 커져서 시스템이 느려지고, 결국 메모리 부족으로 애플리케이션이 비정상 종료될 수 있습니다. 이를 방지하기 위해 Eclipse Memory Analyzer(MAT)나 JProfiler 같은 도구를 사용해 메모리 사용 현황을 분석합니다.
- 객체 생명주기 최적화: 객체가 필요 없어지면 참조를 명확히 해제해야 합니다. try-with-resources 같은 기능을 활용하면 자원을 자동으로 해제할 수 있습니다.
- 가비지 컬렉션 튜닝: JVM의 가비지 컬렉터는 더 이상 사용되지 않는 객체를 메모리에서 해제하는 역할을 합니다. G1GC 같은 최신 가비지 컬렉터를 사용해 성능을 최적화하고, GC가 실행되는 동안 애플리케이션의 정지 시간을 줄일 수 있습니다. 예를 들어, -Xms(초기 힙 크기)와 -Xmx(최대 힙 크기) 옵션을 조정하여 애플리케이션이 사용할 수 있는 메모리 양을 최적화합니다.
스레드 최적화:
- 불필요한 잠금 제거: 자바의 멀티스레딩 기능을 통해 병렬 처리가 가능하지만, 불필요한 동기화나 잠금이 있으면 성능 저하가 발생할 수 있습니다. 잠금이 필요한 부분을 최소화하고, 경합을 피할 수 있는 방안을 모색해야 합니다.
- 스레드 풀 사용: 새로운 작업마다 새로운 스레드를 생성하면 성능이 저하될 수 있으므로, 일정한 개수의 스레드로 작업을 처리하는 스레드 풀을 사용하는 것이 좋습니다. 예를 들어 Executors.newFixedThreadPool()로 고정된 크기의 스레드 풀을 생성하여 여러 작업을 처리하고, 작업이 끝나면 풀을 종료합니다.
- 블로킹 작업 피하기: I/O 또는 데이터베이스 작업처럼 오래 걸리는 블로킹 작업은 애플리케이션의 스레드를 정지시킬 수 있습니다. 비동기 작업이나 비블로킹 I/O를 사용하면 이러한 문제를 해결할 수 있습니다.
지속적인 모니터링:
- 애플리케이션의 성능을 지속적으로 모니터링하는 것은 매우 중요합니다. CPU 사용률, 힙 메모리 사용량, 스레드 상태, 응답 시간, 처리량 등의 주요 지표를 모니터링해야 합니다.
- Java Flight Recorder(JFR) 같은 도구를 사용하면 이러한 성능 지표를 실시간으로 모니터링하고 문제를 식별할 수 있습니다. 예를 들어, VisualVM을 통해 애플리케이션의 메모리 사용량, 스레드 활동, 가비지 컬렉션 빈도 등을 시각적으로 확인하고 분석할 수 있습니다.

E-commerce Platform like Amazon

성게군. — Tue, 8 Oct 2024 23:52:43 +0900

https://medium.com/@kevinchwong/e-commerce-platform-like-amazon-6adf3be577fd

사용자와 웹 애플리케이션 상호작용
- 사용자는 웹 애플리케이션을 통해 제품을 탐색하며, CDN을 통해 정적 콘텐츠와 캐시된 데이터를 제공합니다.
API 게이트웨이 및 로드 밸런서
- 웹 애플리케이션은 API 게이트웨이에 요청을 보내고, 이 요청은 로드 밸런서로 라우팅됩니다. 로드 밸런서는 백엔드 서비스로 요청을 분배합니다.
백엔드 서비스
- 제품 서비스는 캐시와 제품 데이터베이스(읽기 복제본 포함)에서 데이터를 가져옵니다.
- 사용자 서비스는 사용자 데이터베이스와 그 읽기 복제본을 조회합니다.
- 주문 서비스는 주문 데이터베이스와 그 읽기 복제본에 데이터를 씁니다.
- 결제 서비스는 결제 게이트웨이를 통해 결제를 처리하고 확인합니다.
- 재고 서비스는 재고 데이터베이스와 그 읽기 복제본에서 데이터를 업데이트합니다.
결제 및 재고 상호작용
- 결제 서비스는 결제 게이트웨이와 통신하며, 결제 게이트웨이는 은행과 연동하여 결제를 검증합니다. 재고 서비스는 재고 업데이트를 처리합니다.

Pessimistic Locking in Distributed Systems

성게군. — Tue, 8 Oct 2024 23:42:22 +0900

https://medium.com/@_sidharth_m_/how-distributed-systems-avoid-race-conditions-using-pessimistic-locking-1dc112a82b5e

How Distributed Systems Avoid Race Conditions using Pessimistic Locking?

Understanding Pessimistic Locks, Leases, and Fence Tokens in Distributed Systems

medium.com

잠금을 획득하는 것만으로는 충분하지 않습니다

노드가 잠금을 획득한 후 해제하기 전에 동결되거나 실패하는 시나리오를 생각해 보세요. 이 경우 노드가 잠금 데이터베이스/서비스에서 잠금 해제 정보를 업데이트하지 않았기 때문에 나머지 시스템에서 볼 때 노드는 여전히 잠금을 보유하고 있습니다.

이 문제를 해결하기 위해 노드가 잠금을 획득할 때마다 잠금 데이터베이스 레코드에 잠금에 대한 임대 기간이라고도 하는 TTL(Time to Live)이 설정됩니다. 임대가 만료되면 처음에 잠금을 획득한 노드가 업데이트를 완료했는지 여부에 관계없이 공유 리소스에 대한 잠금이 해제됩니다. 이를 통해 시스템은 노드가 장애로 인해 잠금을 해제하지 못하는 시나리오를 처리할 수 있습니다.

노드가 실패하지 않고 일시 정지되었다가 다시 시작됨

이제 임대가 있는 잠금이 있으므로, 노드 A가 임대가 있는 잠금을 획득한 후 공유 리소스를 업데이트하기 전에 어떤 이유로든 일시 중지하거나 동결하는 시나리오를 상상해 보겠습니다. 이 동결 기간 동안 임대가 만료되고 나머지 시스템에 대한 잠금이 해제됩니다. 다른 노드(예: 노드 B)가 공유 리소스에 대한 이 잠금을 획득하고 그 값을 업데이트합니다. 노드 B가 리소스를 업데이트하면 노드 A는 자신이 여전히 잠금을 소유하고 있다고 생각하여 리소스에 업데이트를 푸시하여 노드 B의 업데이트를 덮어씁니다. 이렇게 되면 공유 데이터 리소스가 잘못된 상태가 됩니다.

펜스 토큰

이 문제를 해결하려면 시스템의 각 노드가 공유 데이터 리소스에 대한 쓰기 요청과 함께 새 펜싱 토큰을 보내야 합니다. 공유 데이터 리소스는 이미 최신 펜싱 토큰을 확인한 경우 이전 펜싱 토큰을 거부합니다. 간단히 설명하자면, 이 펜싱 토큰은 공유 리소스에 대한 잠금이 요청될 때마다 잠금 데이터베이스가 증가시키는 숫자일 수 있습니다.

이전 시나리오에서는 노드 A가 잠금을 획득할 때 펜싱 토큰 값 10을 할당받았고, 노드 A가 동결된 후 노드 B가 잠금을 획득할 때 펜싱 토큰 값 11을 제공받았습니다. 노드 B가 업데이트를 실행했으므로 공유 데이터 자원은 이미 펜싱 토큰 값 11을 보게 됩니다. 따라서 노드 A의 펜싱 토큰이 (노드 A 이후에 잠금을 획득한) 노드 B보다 작으므로 재개된 후 A가 보낸 업데이트를 거부하게 됩니다.

다른 post 참고
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

How to do distributed locking — Martin Kleppmann’s blog

How to do distributed locking Published by Martin Kleppmann on 08 Feb 2016. As part of the research for my book, I came across an algorithm called Redlock on the Redis website. The algorithm claims to implement fault-tolerant distributed locks (or rather,

martin.kleppmann.com

k8s JVM memory Config

성게군. — Wed, 19 Jun 2024 16:41:48 +0900

개요

Pod total memory 대비 JVM memory 설정값 측정

Pod total memory

Pod에 지정 된 limit memory 값
ex) 2000M

Pod OS 기본 사용 memory

Pod 구동 시, 기본적으로 사용하는 memory
대략 200M 가정 ( 대체로 200M가 보다 더 작을 것이지만, 여유롭게 가정)

JVM memory

JVM total memory = heap + metaspace
- ex) 예제 가정값
- Pod total memory: 2000M
- metaspace: 256M
Pod total memory 대비 JVM memory Max 사용량 비율
- (Pod total memory * heap 사용 비율) + metaspace = JVM total memory → Pod total memory 대비 사용 비율
- (2000 * 0.5) + 256 = 1256 -> 62.8%
- (2000 * 0.6) + 256 = 1456 -> 72.8%
- (2000 * 0.7) + 256 = 1656 -> 82.8%
- (2000 * 0.8) + 256 = 1856 -> 92.8%

JVM memory 사용 비율 계산

Pod total memory(- OS 기본 메모리 제외)의 75% 까지 이용
- k8s OOM killer 대상에서 제외 되게끔
ex)
- ((Pod total memory - Pod OS 기본 사용 memory) * 0.75) = metaspace + (Pod total memory* heap 사용 비율) → heap 사용 비율 계산
- ((2000 - 200) * 0.75) = 256 + (2000 * x), x(heap 사용 비율) → 55%
- ((4000 - 200) * 0.75) = 256 - (4000 * x), x(heap 사용 비율) → 65%

6 Tips for Resolving Common Java Performance Problems

성게군. — Sun, 7 Apr 2024 01:12:04 +0900

https://medium.com/javarevisited/6-tips-for-resolving-common-java-performance-problems-b88f42dc6118

6 Common Java performance problems

1. Memory leaks

자바는 가비지 컬렉터를 통해 자동 메모리 관리를 제공함에도 불구하고, 성능 문제에 대한 보장을 하지 않습니다. 가비지 컬렉터는 더 이상 사용되지 않는 메모리를 자동으로 식별하고 회수하지만, 자동 메모리 관리에만 의존하는 것은 성능 문제에서 완벽한 방법은 아닙니다.

자바의 가비지 컬렉터는 더 이상 사용되지 않는 메모리를 자동으로 식별하고 회수하여 언어의 강력한 메모리 관리 시스템의 필수적인 기능 입니다.

그러나 이러한 고급 메커니즘을 사용하더라도, 심지어 가장 숙련된 프로그래머들도 자바 메모리 누수를 우연히 발생시킬 수 있습니다. 메모리 누수는 객체가 의도치 않게 메모리에 유지되어 가비지 컬렉터가 관련 메모리를 회수하지 못하게 하는 것으로, 시간이 지남에 따라 메모리 소비가 증가하고 응용 프로그램의 성능이 저하될 수 있습니다.

메모리 누수는 겹치는 증상 때문에 감지하고 해결하기 어려울 수 있습니다. 우리의 경우, 가장 명백한 증상 중 하나인 OutOfMemoryError 힙 오류가 있었으며, 시간이 지남에 따라 성능이 저하되었습니다.

자바에서 메모리 누수를 일으킬 수 있는 여러 가지 문제가 있습니다. 우리의 첫 번째 접근 방식은 이것이 정상적인 메모리 고갈(디자인의 부적절한 결과로 인한)인지 누수인지를 분석하여 메모리 부족 오류 메시지를 조사하는 것이었습니다.

우리는 먼저, static 필드, 컬렉션 및 애플리케이션의 전체 수명 동안 중요한 메모리를 차단할 수 있는 정적으로 선언된 큰 객체와 같은 가장 가능성이 높은 원인들을 확인하는 것으로 시작했습니다.

예를 들어, 아래의 코드 예제에서는 리스트를 초기화할 때 static 키워드를 제거하면 메모리 사용량이 급격하게 감소합니다.


public class StaticFieldsMemoryTestExample {
    public static List<Double> list = new ArrayList<>();
    public void addToList() {
        for (int i = 0; i < 10000000; i++) {
            list.add(Math.random());
        }
        Log.info("Debug Point 2");
    }
    public static void main(String[] args) {
        new StaticFieldsDemo().addToList();
    }
}

우리가 취한 다른 조치에는 메모리를 차단할 수 있는 열린 리소스나 연결을 확인하는 것이 포함되었습니다. 이에 따라 가비지 컬렉터의 도달 범위 밖에 있습니다. HashMaps와 HashSets에서 equals() 및 hashCode() 메서드의 잘못된 구현을 수정하여 적절한 equals() 및 hashCode() 메서드를 작성했습니다. 다음은 equals() 및 hashCode() 메서드를 올바르게 구현하는 예시입니다.

public class Person {
    public String name;

    public Person(String name) {
        this.name = name;
    }

    @Override
    public boolean equals(Object o) {
        if (o == this) return true;
        if (!(o instanceof Person)) {
            return false;
        }
        Person person = (Person) o;
        return person.name.equals(name);
    }

    @Override
    public int hashCode() {
        int result = 17;
        result = 31 * result + name.hashCode();
        return result;
    }
}

Memory leaks를 방지하는 tips

코드가 파일 핸들, 데이터베이스 연결 또는 네트워크 소켓과 같은 외부 리소스를 사용하는 경우, 해당 리소스가 더 이상 필요하지 않을 때 명시적으로 해제하십시오.
VisualVM이나 YourKit과 같은 메모리 프로파일링 도구를 사용하여 응용 프로그램에서 잠재적인 메모리 누수를 분석하고 식별하십시오.
싱글톤을 사용할 때, 싱글톤이 실제로 필요할 때까지 불필요한 리소스 할당을 피하기 위해 이른 초기화(eager loading) 대신 지연 로딩(lazy loading)을 사용하십시오.
코드가 파일 핸들, 데이터베이스 연결 또는 네트워크 소켓과 같은 외부 리소스를 사용하는 경우, 해당 리소스가 더 이상 필요하지 않을 때 명시적으로 해제하십시오.

2. Thread deadlocks

자바는 멀티쓰레드 언어입니다. 이것은 자바를 특히 복수의 작업을 동시에 처리하는 기업 애플리케이션을 개발하기에 적합한 언어로 만드는 기능 중 하나입니다.

멀티쓰레드라는 이름에서 알 수 있듯이 여러 쓰레드가 관련되며 각각이 가장 작은 실행 단위입니다. 쓰레드는 독립적이며 다른 쓰레드에게 영향을 미치지 않는 별도의 실행 경로를 가집니다.

그러나 쓰레드가 동시에 동일한 리소스(락)에 액세스하려고 시도하는 경우 어떻게 될까요? 이것이 데드락이 발생하는 경우입니다. 실시간 금융 데이터 처리 시스템에서 협업하면서 이를 경험했습니다. 이 프로젝트에서는 외부 API에서 데이터를 가져 오고 복잡한 계산을 수행하며 공유 인메모리 데이터베이스를 업데이트하는 여러 쓰레드가 있었습니다.

이 도구의 사용이 증가함에 따라 우리는 가끔씩 멈춤 현상이 발생하는 보고서를 받게 되었습니다. 쓰레드 덤프를 분석하면 일부 쓰레드가 락에 대한 원형 종속성을 형성하여 대기 상태에 갇혀 있는 것을 알 수 있었습니다.

이 예에서는 두 개의 쓰레드(thread1 및 thread2)가 서로 다른 순서로 두 개의 락(lock1 및 lock2)을 획득하려고 시도합니다. 이는 원형 대기를 도입하여 데드락의 가능성을 높입니다.

public class DeadlockExample {
    private static final Object lock1 = new Object();
    private static final Object lock2 = new Object();
    public static void main(String[] args) {
        Thread thread1 = new Thread(() -> {
            synchronized (lock1) {
                System.out.println("Thread 1: Holding lock 1");
                // Introducing a delay to increase the likelihood of deadlock
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock2) {
                    System.out.println("Thread 1: Holding lock 1 and lock 2");
                }
            }
        });
        Thread thread2 = new Thread(() -> {
            synchronized (lock2) {
                System.out.println("Thread 2: Holding lock 2");
                // Introducing a delay to increase the likelihood of deadlock
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock1) {
                    System.out.println("Thread 2: Holding lock 2 and lock 1");
                }
            }
        });
        thread1.start();
        thread2.start();
    }
}

이 문제를 해결하기 위해 쓰레드가 항상 일관된 순서로 락을 획득하도록 코드를 리팩토링할 수 있습니다. 이를 위해 락의 전역 순서를 도입하고 모든 쓰레드가 동일한 순서를 따르도록 할 수 있습니다.

public class DeadlockSolution {
    private static final Object lock1 = new Object();
    private static final Object lock2 = new Object();
    public static void main(String[] args) {
        Thread thread1 = new Thread(() -> {
            synchronized (lock1) {
                System.out.println("Thread 1: Holding lock 1");
                // Introducing a delay to increase the likelihood of deadlock
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock2) {
                    System.out.println("Thread 1: Holding lock 2");
                }
            }
        });
        Thread thread2 = new Thread(() -> {
            synchronized (lock1) {
                System.out.println("Thread 2: Holding lock 1");
                // Introducing a delay to increase the likelihood of deadlock
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock2) {
                    System.out.println("Thread 2: Holding lock 2");
                }
            }
        });
        thread1.start();
        thread2.start();
    }
}

Thread deadlocks를 방지하는 tips

락 순서 지정: 모든 쓰레드가 락을 획득할 때 동일한 순서를 따르도록하여 원형 대기를 방지합니다.
락 타임아웃 구현: 쓰레드가 특정 시간 내에 락을 획득할 수 없는 경우, 모든 획득한 락을 해제하고 재시도합니다.
중첩 락 회피: 다른 락이 이미 보유된 상태에서 중요한 섹션 내에서 락을 획득하는 것을 피합니다. 중첩 락은 데드락의 위험을 증가시킵니다.

3. Excessive garbage collection

자바의 가비지 컬렉션은 메모리를 관리해주는 주요한 기능입니다. 더 이상 필요하지 않은 객체를 자동으로 정리하여 개발자들의 삶을 훨씬 쉽게 만들어줍니다. 이 자동 가비지 컬렉션은 개발자들에게 편의를 제공하지만, 애플리케이션 성능에 영향을 미칠 수 있는 가비지 컬렉션에 할당된 CPU 사이클의 비용이 발생할 수 있습니다.

전형적인 메모리 부족 오류 외에도, 가끔씩 애플리케이션이 멈추거나 느려지거나 애플리케이션 충돌이 발생할 수 있습니다. 또한 클라우드를 사용하는 경우 가비지 컬렉션 프로세스를 최적화하면 컴퓨팅 비용을 크게 절약할 수 있습니다. Uber라는 회사가 그러한 사례입니다. 이 회사는 고도로 효과적이고 낮은 위험, 대규모, 반자동화된 Go 가비지 컬렉션 튜닝 메커니즘을 사용하여 30개의 중요 서비스 전체에서 70,000개의 코어를 절약할 수 있었습니다.

Excessive garbage collection을 방지하는 tips

로그 분석 및 튜닝: 완전한 가비지 컬렉션 주기나 긴 일시 정지 시간과 같은 패턴을 식별합니다.
다양한 가비지 컬렉션 알고리즘을 평가하고 전환합니다. JDK 알고리즘인 Serial, Parallel, G1, Z GC 등을 고려합니다.
애플리케이션의 작업 부하와 성능 특성을 기반으로 알고리즘을 선택합니다. 더 적합한 GC 알고리즘으로 전환하면 CPU 소비를 줄일 수 있습니다.
과도한 객체 생성을 줄이기 위해 코드를 최적화합니다. HeapHero 또는 YourKit과 같은 메모리 프로파일링 도구를 사용하여 과도한 객체를 생성하는 부분을 식별합니다. 객체 풀링을 구현하여 객체를 재사용하고 할당 오버헤드를 줄입니다.
가비지 컬렉션 중 CPU 소비에 영향을 미치도록 힙 크기를 수정합니다. 컬렉션 주기의 빈도를 줄이기 위해 힙 크기를 증가시키거나, 메모리 풋프린트가 낮은 애플리케이션의 경우 힙 크기를 감소시킵니다.
클라우드에서 실행 중인 경우 작업 부하를 여러 인스턴스에 분산합니다. 리소스를 더 잘 활용하고 개별 인스턴스에 가중 부하를 줄이기 위해 컨테이너 인스턴스나 EC2 인스턴스의 수를 늘릴 수 있습니다.

4. Bloated Libraries and Dependencies

Maven과 Gradle과 같은 빌드 도구는 자바 프로젝트에서 종속성을 관리하는 방식을 혁신적으로 바꿔 놓았습니다. 이러한 도구들은 외부 라이브러리를 포함하는 간소화된 방법을 제공하고 프로젝트 구성 프로세스를 단순화합니다. 그러나 이러한 편의성에는 Bloated 된 라이브러리와 종속성의 위험이 따릅니다.

실제로 2021년에 발표된 전체 연구에서는 애플리케이션의 컴파일된 코드에 포함된 종속성 중에 실제로 애플리케이션을 빌드하고 실행하는 데 필요하지 않은 것들이 있음을 밝혔습니다.

소프트웨어 프로젝트는 버그 수정, 새로운 기능 및 새로운 종속성 등의 결과로 빠르게 성장하는 경향이 있습니다. 때로는 프로젝트가 비례치 않게 커져 개발자로서 효과적으로 유지하기 어려울 수 있습니다. 이로 인해 보안 취약점과 추가적인 성능 오버헤드도 발생할 수 있습니다.

이러한 상황에 처한 경우, 사용되지 않는 종속성 및 라이브러리를 제거하는 방법을 찾는 것이 좋습니다.

자바 생태계 내에서는 종속성을 관리하기 위한 여러 도구들이 있습니다. 가장 일반적인 도구 중 몇 가지는 Maven 종속성 플러그인과 Gradle 종속성 분석 플러그인 등이 있습니다. 이 도구들은 사용되지 않는 종속성과 사용된 전이적 종속성(직접 선언하려는 것) 및 잘못된 구성(API vs implementation vs compileOnly 등)을 감지하는 데 꽤 효과적입니다.

또한 Sonarqube와 JArchitect와 같은 다른 도구들도 활용할 수 있습니다. Intellij와 같은 일부 최신 IDE도 꽤 괜찮은 종속성 분석 기능을 제공합니다.

Bloated Libraries and Dependencies를 방지하는 tips

종속성 검사: 사용되지 않거나 오래된 라이브러리를 식별하기 위해 정기적인 검사를 수행하십시오. Maven Dependency Plugin이나 Gradle의 dependencyInsight와 같은 도구를 사용하여 종속성 분석을 지원할 수 있습니다.
버전 관리: 종속성을 최신 상태로 유지하십시오. 버전 관리 시스템을 활용하여 종속성의 변경 사항을 추적하고 업데이트를 체계적으로 관리합니다.
종속성 범위: 종속성 범위(compile, runtime, test 등)를 효과적으로 활용하십시오. 최종 아티팩트의 크기를 줄이기 위해 컴파일 범위에 있는 종속성의 수를 최소화합니다.

5. Inefficient Code

비효율적인 코드

어떤 개발자도 의도적으로 비효율적이거나 최적화되지 않은 코드를 작성하려 하지 않습니다. 그러나 최선의 의도에도 불구하고, 다양한 이유로 인해 비효율적인 코드가 제품에 반영될 수 있습니다. 이는 프로젝트의 시간 제약, 기술의 제한된 이해, 또는 개발자들이 최적화보다는 기능을 우선시해야 하는 변화하는 요구사항에서 비롯될 수 있습니다.

비효율적인 예시

String result = "";
for (int i = 0; i < 1000; i++) {
   result += "example";
}

개선된 예시

StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
   sb.append("example");
}
String result = sb.toString();

비효율적인 코드는 증가된 메모리 사용, 더 긴 응답 시간, 전체 시스템 효율성 감소로 이어질 수 있습니다. 궁극적으로 비효율적인 코드는 사용자 경험을 저하시키고 운영 비용을 증가시키며 증가된 부하를 처리하기 위한 애플리케이션 확장을 제한할 수 있습니다.

비효율적인 코드를 제거하는 것은 비효율성을 나타내는 패턴을 식별하는 것으로 시작합니다. 항상 주의를 기울여야 할 패턴 중 일부는 적절한 종료 조건이 없는 중첩된 루프, 불필요한 객체 생성과 인스턴스화, 과도한 동기화, 비효율적인 데이터베이스 쿼리 등이 있습니다.

Inefficient Code를 방지하는 tips

코드를 리팩토링하고 모듈화하여 불필요한 중복을 피합니다.
I/O 작업 최적화: 주요 쓰레드를 차단하지 않도록 비동기 또는 병렬 I/O 작업을 사용합니다.
특히 코드의 성능이 중요한 섹션에서 불필요한 객체 생성을 피합니다. 가능한 경우 객체를 재사용하고 객체 풀링 기법을 사용하는 것을 고려합니다.
문자열을 빌드할 때 + 연산자로 문자열을 연결하는 대신 StringBuilder를 사용합니다. 이렇게 하면 불필요한 객체 생성을 피할 수 있습니다.
효율적인 알고리즘과 데이터 구조를 사용합니다. 작업에 적합한 알고리즘과 데이터 구조를 선택하여 최적의 성능을 보장합니다.

6. Concurrency problems

쓰레드 동시성 문제는 여러 쓰레드가 공유 리소스에 동시에 접근할 때 발생하며, 종종 예상치 못한 동작으로 이어집니다.

코드 작성에 오랜 시간을 보낸다면, 개발 주기 중에 나타나는 문제로 인한 좌절을 경험했을 것입니다. 이러한 문제를 효과적으로 식별하고 해결하는 것은 실제로 매우 어려운 일입니다.

정확한 현실 성능을 파악하지 못하면, 이러한 문제들은 애플리케이션을 계속해서 괴롭힐 수 있습니다. 특히 복잡한 분산 시스템을 다룰 때 이러한 고통은 더욱 현실적입니다. 적절한 통찰력 없이는 정보화된 설계 결정을 내리거나 코드 변경의 영향을 평가하기가 어려울 수 있습니다.

Concurrency problems를 방지하는 tips

원자 변수 사용: java.util.concurrent.atomic 패키지는 AtomicInteger 및 AtomicLong과 같은 클래스를 제공하여 명시적 동기화 없이도 원자적 작업을 가능하게 합니다.
변경 가능한 객체 공유 피하기: 가능한 경우 클래스를 변경할 수 없도록 설계하여 동기화 필요성을 없애고 쓰레드 안전성을 보장합니다.
Lock 경합 최소화: Lock 경합을 최소화하기 위해 미세한 잠금 또는 lock striping과 같은 기술을 사용하여 동일한 Lock에 대한 경쟁을 줄입니다.
synchronized 키워드 활용: synchronized 블록이나 메서드를 생성하여 한 번에 하나의 쓰레드만 synchronized 코드 블록에 액세스할 수 있도록 합니다.
쓰레드 안전한 데이터 구조 사용: Java의 java.util.concurrent 패키지는 ConcurrentHashMap, CopyOnWriteArrayList 및 BlockingQueue와 같은 쓰레드 안전한 데이터 구조를 제공하여 추가 동기화 없이도 동시 액세스를 처리할 수 있습니다.

Clean Code: Optional Parameters

성게군. — Sun, 7 Apr 2024 00:44:31 +0900

https://medium.com/@bubu.tripathy/clean-code-optional-parameters-327d67abbf90

메서드에서 선택적 매개변수를 다룰 때는 긴 매개변수 목록이나 널 값 사용을 피하는 것이 좋습니다. 대신 메서드 오버로딩 또는 빌더 패턴으로 코드 가독성과 유지 관리성을 향상 시키는 것이 좋습니다. 이 방법들은 다양한 매개변수 집합을 가진 메서드를 호출할 때 더 깔끔한 인터페이스를 제공합니다.

⭐️ 메서드 오버로딩을 활용하여 서로 다른 매개변수 집합을 가진 메서드의 여러 버전을 생성하세요. 이렇게 하면 선택적 매개변수에 의존하지 않고도 명확하고 명시적으로 호출할 수 있습니다.

⭐️ 선택적 매개변수의 수가 상당히 많아지면 빌더 패턴을 구현하는 것을 고려하세요. 이 접근 방식은 별도의 빌더 클래스를 생성하여 선택적 매개변수가 있는 인스턴스를 구성하는 것입니다.

⭐️ 수많은 매개변수 대신 구성 개체를 사용하여 선택적 매개변수를 캡슐화할 수 있습니다. 이는 많은 수의 선택적 설정을 처리할 때 특히 유용할 수 있습니다.

⭐️ 메서드 오버로딩 또는 빌더 패턴을 구현할 때는 가능한 모든 매개변수 조합을 테스트해야 합니다. 이렇게 하면 메서드의 각 버전이 예상대로 작동하고 매개변수 간의 예기치 않은 상호 작용을 방지할 수 있습니다.

어떤 접근 방식을 선택하든 명확성과 가독성을 우선시하세요.

What Is a Modular Monolith?

성게군. — Fri, 5 Apr 2024 23:49:29 +0900

https://medium.com/@MilanJovanovicTech/what-is-a-modular-monolith-babd989a4ea2

What is a Modular Monolith?

모듈형 모놀리스는 애플리케이션을 잘 정의된 경계를 가진 독립적인 모듈 또는 구성 요소로 구조화하는 아키텍처 패턴입니다. 모듈은 논리적 경계를 기준으로 분할되어 관련 기능을 함께 그룹화합니다. 이 접근 방식은 시스템의 응집력을 크게 향상시킵니다.

모듈은 느슨하게 결합되어 있어 모듈화와 분리를 더욱 촉진합니다. 모듈은 공용 API를 통해 통신하며, 이에 대한 자세한 내용은 모듈형 모놀리스 통신 패턴에 대한 글에서 확인할 수 있습니다.
그렇다면 모듈식 설계의 장점은 무엇일까요?

Benefits of a Modular Monolith

배포 간소화 - 복잡한 배포 전략이 필요한 마이크로서비스와 달리 모듈형 모놀리스는 단일 단위로 배포할 수 있습니다.
성능 향상 - 모듈 간의 통신은 프로세스 중에 이루어집니다. 즉, 네트워크 지연 시간이나 데이터 직렬화/역직렬화 오버헤드가 없습니다.
개발 속도 향상 - 관리할 코드베이스가 하나이므로 디버깅과 전반적인 개발 환경이 간소화됩니다.
간편한 트랜잭션 관리 - 분산 시스템에서 트랜잭션 관리는 매우 까다롭습니다. 모듈형 모놀리스는 모듈이 동일한 데이터베이스를 공유할 수 있으므로 이 작업을 간소화합니다.
운영 복잡성 감소 - 모듈형 모놀리스는 분산형 마이크로서비스 시스템을 관리하고 배포할 때 발생하는 운영 오버헤드를 줄여줍니다.
마이크로서비스로의 손쉬운 전환 - 잘 구조화된 모듈식 모놀리스는 마이크로서비스 아키텍처로 가는 명확한 경로를 제공합니다. 필요에 따라 점진적으로 모듈을 별도의 서비스로 추출할 수 있습니다.

Modular Monolith vs Microservices

모듈형 모놀리스와 마이크로서비스의 가장 큰 차이점은 배포 방식에 있습니다. 마이크로서비스는 모듈형 모놀리스 내부의 논리적 경계를 물리적 경계로 확장합니다.

마이크로서비스는 모듈화를 위한 명확한 전략을 제공하고 경계가 있는 컨텍스트를 분해합니다. 하지만 분산 시스템을 구축하지 않고도 이를 달성할 수 있습니다. 문제는 사람들이 마이크로서비스를 사용하여 코드 경계를 강제한다는 것입니다.

대신 모듈형 모놀리스를 구축하여 동일한 이점을 대부분 얻을 수 있습니다. 모듈형 모놀리스는 높은 응집력, 낮은 결합, 데이터 캡슐화, 비즈니스 기능에 대한 집중 등을 제공합니다.

마이크로서비스는 이 모든 장점에 더해 독립적인 배포, 독립적인 확장성, 서비스별로 다양한 기술 스택을 사용할 수 있는 기능을 제공합니다.

모놀리식 코드베이스가 복잡해서 마이크로서비스를 선택하는 것이 아니라 이점을 위해 마이크로서비스를 선택하세요.
— Simon Brown

mongodb bulk remove

성게군. — Wed, 3 Apr 2024 21:32:13 +0900

mongodb bulk remove

Git Branch Model/Strategy

성게군. — Sun, 14 Jan 2024 21:10:42 +0900

Release Train

IT회사에서 일상적으로 사용하는 RT는 "Release Train"의 약자입니다. 소프트웨어 개발과정에서 사용 되는 용어로, 주로 Agile 또는 린소프트웨어 개발 방법론에서 활용됩니다. Release Train은 여러 팀이 협력하여 일정 주기마다 새로운 소프트웨어 버전을 배포하는 프로세스를 나타냅니다. 이 프로세스는 큰 프로젝트 또는 제품을 관리하고 지속적으로 배포하기 위해 사용됩니다.

Release Train 접근 방식은 다음과 같이 동작합니다:

일정 주기: 일정한 주기(보통은 2주, 4주 등)로 소프트웨어 버전을 배포하는 시간 단위를 결정합니다.
팀 협력: 여러 개발 팀이 하나의 Release Train에 참여합니다. 이 팀들은 동시에 개발을 진행하며, 주기마다 생성된 기능이나 개선사항을 공유하고 통합합니다.
기능 묶음: 각 주기마다 새로운 기능, 버그 수정 등을 묶어서 배포할 준비를 합니다. 이 기능 묶음들이 전체적인 소프트웨어 배포의 핵심이 됩니다.
통합 및 테스트: 주기가 끝날 때, 다양한 팀에서 개발한 기능들을 통합하고 테스트합니다. 이 단계에서 각 팀이 개발한 코드들이 충돌하지 않도록 조치하고, 품질을 검증합니다.
릴리즈: 주기가 끝나면 통합 및 테스트를 마친 기능들을 하나의 큰 배포로써 출시합니다. 이것이 바로 Release Train이며, 사용자들에게 새로운 기능과 개선사항을 제공합니다.

VS. Git Branch Strategy

Git Flow , Github Flow

Git Flow는 흐름이 복잡하지만 branch를 체계적으로 관리할 수 있다. 따라서 긴 호흡으로 개발을 진행하며, 주기적으로 배포하고 QA, 배포 할 필요성이 있을 때 Git Flow를 추천한다.
반대로 Github Flow는 작업 과정이 매우 단순하다는 장점이 있다. 따라서 Git을 처음 접하는 인원이 많거나 지속적으로 테스트하고 빠르게 배포되어야하는 서비스라면 Github Flow가 적합하다

Github Flow , Gitlab Flow

둘 다 master branch에서 시작하여 개발 중인 코드를 관리하고 기능 개발을 위해 새로운 branch를 생성하며 완료된 기능을 master branch로 병합하는 과정이 동일합니다. 또한 테스트와 리뷰를 거친 후 안정화된 코드를 production 환경에 배포하는 것 역시 동일.
Gitlab flow가 Git flow와 Github flow의 특징을 결합한 방법론이라는 것입니다.
Gitlab flow는 개발과 배포를 위한 유연성과 간단한 프로세스를 조합하여 팀이 더욱 효과적으로 협업하고 production 환경에 안정적인 코드를 배포할 수 있도록 지원합니다.

Github Flow

특징

Git Flow에 비해 굉장히 간단함, 처음 git을 접하는 사람에게 가장 간단하고 적응하기 쉬운 전략.
master branch와 pull request 방식을 활용하여 굉장히 단순한 형태의 전략
hotfix와 가장 작은 기능(feature), 배포(release)을 구분하지 않는다. 단지 우선순위가 어디가 높은가 라는 단계적 처리가 필요 하다.
수시로 배포가 일어나고, CI/CD 파이프라인이 구성되어 있는 프로젝트에 유용
- CI가 거의 필수적이며, 배포는 자동으로 진행할 수 있다.
- GitHub의 서비스 특성상 릴리즈 라는 개념이 없는 서비스를 진행하고 있어서 그런 것으로 보임
release branch가 명확하지 않은 시스템에서 사용 하기 맞게 되어있다.

Branch 정의

master
- product 배포 branch
- master branch는 어떤 때든 배포가 가능하다.
- master branch는 항상 최신의 상태이며, stable 상태로 Product에 배포되는 branch이다.
새로운 feature branch
- 새로운 feature를 시작하기 위해 만드는 branch
- 항상 master branch에서 분기
- Git Flow와는 다르게 feature, release, develop 등을 나누지 않음 → commit 메시지를 명확하게 작성해야 함
- merge 준비가 완료되면 Pull Request를 통해 code review 단계를 진행
- Pull Request에서 code review가 완료 → master branch로 반영

작업 과정 설명

master에서 새로운 branch 분기
기능 개발 완료 시 master에 Pull Request 생성
Pull Request에서 code review
merge 시, product로 반영이 될 기능 이기에 이해관계가 연결된 사람들과 충분한 논의 이후 반영해야 한다 ← 배포 관련 부분이 확정 되야 5번 단계로 넘어 가야 한다.
review 및 test 완료 시 master branch로 merge
master branch에서 즉시 배포진행 ← 자동화 배포가 구성 되어 있어야 하지만, 수동으로 배포를 진행 해도 된다.

Git Flow

특징

명확한 릴리즈 버전 관리를 위한 branch를 따로 관리하기 때문에 한 버전에 대한 유지보수가 용이함
1. 운영 환경(master) 배포 branch와 개발 환경(develop) 배포 branch를 명시적으로 분리해서, 운영 환경에 어떤 코드 베이스가 배포 되어 있는지 한 눈에 확인할 수 있다는 점
2. 운영 환경에 언제 배포해도 상관없는 stable branch(master)를 별도로 관리해서, 장애 혹은 버그 수정이 필요한 경우 master branch를 기준으로 빠르게 수정 → 아직 테스트가 완료되지 않은 feature branch가 운영 환경에 배포 되는걸 방지
기능 개발 단위 사이사이의 conflict를 최소화 할 수 있음
명확한 배포 기간과 주기적인 버전이 정해진 프로젝트에 적합
Git Flow 설계자 Vincent Driessen의 2020년 추가 의견

이 모델은 지금으로부터 10년 전인 2010년에 고안된 것으로, Git 자체가 등장한 지 얼마 되지 않은 시점입니다. 이 글에서 설명하는 브랜칭 모델인 깃플로는 10년 동안 많은 소프트웨어 팀에서 큰 인기를 끌면서 사람들이 일종의 표준처럼 취급하기 시작했지만, 안타깝게도 도그마나 만병통치약처럼 여겨지기도 합니다.

지난 10년 동안 Git 자체는 전 세계를 강타 했으며, 적어도 제 필터 버블?에서는 Git으로 개발되는 가장 인기 있는 소프트웨어 유형이 웹 앱으로 더 많이 이동하고 있습니다. 웹 앱은 일반적으로 롤백 되지 않고 지속적으로 제공 되며, 여러 버전의 소프트웨어가 동시에 실행되도록 지원할 필요가 없습니다.

10년 전 블로그 게시물을 작성할 때 염두에 두었던 소프트웨어의 종류가 아닙니다. 팀에서 소프트웨어의 지속적 배포를 수행하는 경우, 팀에 Git Flow를 무리하게 도입하는 대신 훨씬 더 간단한 워크 플로(예: GitHub 플로우)를 채택하는 것이 좋습니다.

하지만 명시적으로 버전이 지정된 소프트웨어를 빌드 하거나 여러 버전의 소프트웨어를 지원해야 하는 경우에는 지난 10년 동안 사람들에게 그랬던 것처럼 Git Flow가 여전히 팀에 적합할 수 있습니다. 그렇다면 계속 읽어보세요.

결론적으로, 만병통치약은 존재하지 않는다는 사실을 항상 기억하세요. 자신의 상황을 고려하세요. 미워하지 마세요. 스스로 결정하세요.

Branch 정의

master branch: 안정화된 버전의 코드(버전태그 추가), 제품으로 출시 될 수 있는 branch, 사용자에게 배포 가능한 상태만을 관리
develop branch: 개발 중인 코드들의 base branch. 최신 개발 변경사항이 반영되어있는 branch(현재 개발중인 코드 반영)
feature branch: 각 기능마다 develop을 기준으로 feature를 생성해서 개발을 진행.
release branch: 이번 출시 버전을 준비하는 branch, QA 진행 및 배포 준비 역할, 해당 release가 종료 되면 삭제 가능
hotfix branch: 출시 버전에서 발생한 버그를 수정하는 branch. master Branch에서 버그 발생하면 바로 hotfix Branch를 분기해서 수정, 배포한 후 관리하는 branch

작업 과정 설명

master에서 develop을 분기
개발자들은 develop branch에 자유롭게 커밋
기능 구현이 있는 경우 develop에서 feature-* branch를 분기
배포를 준비하기 위해 develop에서 release-* branch를 분기
테스트를 진행하면서 발생하는 버그 수정은 release-* branch에 직접 수정 및 반영
테스트 완료 및 배포 준비를 완료하면 release -> main으로 merge하고, release -> develop으로 develop에도 동일하게 반영한다.
배포 이후에 bug가 있을 경우 hotfix branch를 사용하여 해결한다. 그리고 hotfix -> master, hotfix -> develop으로 해당 commit을 반영한다.
배포를 버전별로 관리하기 위해 master에 tag를 붙인다.

Gitlab Flow

2023년 추가 된 concept: https://about.gitlab.com/blog/2023/07/27/gitlab-flow-duo/

특징

Git Flow ↔︎ Github Flow의 절충안
Production branch가 존재(Git Flow의 master branch 역할과 같음)
Gitlab Flow의 master branch는 production branch로 merge됨
pre-production branch는 production branch로 넘어가기 전에 QA/Test를 진행하는 branch

Branch 정의

master
pre-prodution
- production으로 넘어가기 전의 branch
- QA/Test 등 배포 준비 작업을 담당
production
- 배포만을 담당
새로운 feature branch
- github flow의 새로운 feature branch처럼 사용

과정 설명

master에서 새로운 branch 분기
기능 개발 완료 시 master에 Pull Request 생성
Pull Request에서 code review
다음 배포 버전의 Pre-production branch 생성 후, QA/Test 진행
Production branch 생성 및 배포
(Github Flow에서 배포만을 위해 추가된 Production branch와 테스트를 위한 Pre-production branch 빼고 동일합니다.)

Trunk-Based Development

https://paulhammant.com/2013/04/05/what-is-trunk-based-development/

특징

작은 규모의 프로젝트나 소규모 개발팀에서 주로 사용되며 릴리즈 주기가 짧은 프로젝트에 적합한 전략
단일 branch를 사용하여 개발을 진행하며 모든 개발자가 동일한 branch(trunk)에서 작업.
개발자는 자신이 작업한 변경사항을 주기적으로 commit하고 다른 개발자의 변경사항과 통합합니다. 이로써 지속적인 통합과 릴리즈를 강조하며 branch 관리에 따른 복잡성을 줄 이는 장점.
그러나 branch 충돌이 발생할 수 있고 변경 사항이 모든 개발자에게 바로 적용되기 때문에 신중하게 사용.

Branch 정의

trunk(=master): 하나의 branch에서 모든 개발자가 작업을 합니다. 실제 개발과 배포를 위한 branch를 하나로 사용합니다.

참고(Updating,,)

https://techblog.woowahan.com/2553/

Brian Chesky’s new playbook : co-founder and CEO of Airbnb

성게군. — Sun, 10 Dec 2023 23:11:50 +0900

https://www.youtube.com/watch?v=4ef0juAMqoE&t=1s

브라이언 체스키는 에어비앤비의 공동창업자이자 CEO입니다. 브라이언의 리더십 아래 에어비앤비는 220여 개 국가와 지역에서 15억 명 이상의 게스트를 맞이한 400만 명 이상의 호스트가 참여하는 커뮤니티로 성장했습니다. 저는 브라이언의 리더십 아래에서 일할 수 있는 특권을 누렸기 때문에 방송에 브라이언을 모시게 되어 큰 영광입니다. 이야기를 나눠보겠습니다:
- 에어비앤비가 상품 관리에 대한 생각을 바꾼 방법
- 기업에서 관료주의가 발생하는 이유와 이를 방지하는 방법
- 창업자가 디테일에 집중하는 것의 중요성
- 에어비앤비가 전통적인 성장 채널에서 벗어난 이유와 그 대신에 하고 있는 일
- 에어비앤비가 새로 출시한 기능
- 브라이언이 팀원들에게 야심찬 목표를 세우도록 독려하는 방법과 이유
- 아직 증명해야 할 것이 많다고 말하는 이유

요약 포스트: https://www.linkedin.com/search/results/content/?keywords=%EC%9D%98%EC%82%AC%20%EA%B2%B0%EC%A0%95%20%EA%B3%BC%EC%A0%95%EC%9D%84%20%EC%9C%84%EC%9E%84%ED%96%88%EB%8D%94%EB%8B%88%2C%20%EC%86%8D%EB%8F%84%EA%B0%80%20%EB%8D%94%20%EB%8A%90%EB%A0%A4%EC%A1%8C%EC%8A%B5%EB%8B%88%EB%8B%A4.&sid=YVe&update=urn%3Ali%3Afs_updateV2%3A(urn%3Ali%3Aactivity%3A7139212930121682944%2CBLENDED_SEARCH_FEED%2CEMPTY%2CDEFAULT%2Cfalse)

[에어비앤비가 겪었던 문제]
- 조직이 커지면서, 팀들은 각 팀에게 오너십을 달라고 요청했다.
- 각 팀에게 의사결정권을 위임했더니, 오히려 프로덕트 런칭 속도가 느려졌다. 방향성을 결정하는 데 혼란이 있었기 때문이다.
- 이 영향으로 2015년부터 2020년까지 에어비앤비 프로덕트가 크게 바뀌지 못했다.

[문제를 겪으면서 갖게된 생각]
- 팀원들은 명확한 방향성을 원한다. CEO가 리더십을 가지고 프로덕트를 이끌어야 한다. 모두가 같은 방향을 바라볼 수 있도록 만드는 것이 가장 중요하다.
- 매니저의 가장 중요한 역할은 자신의 분야에서 중요한 결정을 내리는 것이다. 사람들을 관리하는 건 두번째로 중요한 역할이다. 실무를 못하면서 조직 구성원을 제대로 관리하는 건 불가능하다.
- 데이터를 보는 것이 중요하지만, 이해하지 못하는 데이터는 시체다. 결과를 이해하지 못하는 AB 테스트는 잘못된 방향으로 이끌 수 있다.
- 엔지니어와 마케터의 관계가 가까워야 한다. 엔지니어는 쉐프이고, 마케터는 웨이터다. 둘이 친하지 않으면 손님에게 최고의 경험을 줄 수 없다.

[변화]
- 관리자 직급을 크게 줄였다 (현재 직원은 7,000명, 기업가치는 100조)
- 진행하는 프로젝트를 크게 줄였다.
- 수천개의 AB 테스트 대신, 1년에 두번 크게 런칭 하는 것에 집중한다.
- CEO는 런칭의 모든 디테일에 참여한다.

TDD Isn't Design

성게군. — Fri, 8 Dec 2023 16:00:51 +0900

https://tidyfirst.substack.com/p/tdd-isnt-design?fbclid=IwAR2CvJPKgRkoSiKl6LfHIugUsFyJI2bFkfrB80oebLdb_V4PeWbJgaWBUBw

프롬프트는 다음과 같았습니다: "TDD만으로 훌륭한 시스템 설계가 나올 수 있다는 생각은 마음에 들지 않습니다."
결론적으로 동의합니다. 당신은 디자인 결정을 내려야 합니다. 더 자세한 답변은 다음과 같습니다.

조금이라도 상식이 있는 사람이라면 TDD가 디자인의 필요성을 대체한다고 말하지 않습니다. 핵심 질문은 '언제'입니다. 첫 번째 테스트를 작성하고 통과하기 전에 몇 가지 구현 디자인 결정을 제안하고 있습니다. 특히 몇 달에서 몇 년이 걸리던 과거의 디자인 '단계'와 비교하면 그렇게 끔찍해 보이지는 않습니다.

TDD offers:

인터페이스 디자인 결정에 대한 즉각적인 피드백. 여전히 결정을 내려야 합니다. 결정한 만큼 디자인이 좋아지지만, 결정의 질에 따라 고통도 반비례하게 됩니다.
인터페이스 디자인 결정과 구현 디자인 결정을 분리하세요. 이 방법은 누가 설명해주지 않아도 항상 저에게 권장되는 것이었습니다.
일단 인터페이스를 테스트하기 위한 결정을 내리고 노트를 작성하면 구현 디자인 결정이 가장 낮은 첫 번째 기준인 '코드가 작동하는가'를 통과했는지 여부에 대한 즉각적인 피드백을 받을 수 있습니다.

인터페이스 디자인 결정이 있는 상황에서 구현 디자인 결정을 내리는 데 자신이 없다면 괜찮습니다. 구현 디자인 결정을 몇 개만 내려야 하는지 실험해 보세요. 저는 최소한의 결정이 무엇인지 궁금합니다. 경험상 답은 '0'인 것으로 나타났습니다. 이 숫자는 직접 확인해 보시기 바랍니다.

Speeding Up Spring Boot/JUnit tests

성게군. — Sun, 26 Nov 2023 23:44:10 +0900

https://www.ankushchoubey.com/spring-boot-junit-faster/

Use Right Test Slice (Saved 25% running time)

여러 runner가 Spring Boot와 함께 제공됩니다.

SpringBootTest가 가장 일반적입니다. 주로 @DirtiesContent와 함께 사용되는데, 기본적으로 모든 테스트 클래스 후에 Springboot을 다시 시작하므로 이상적이지 않습니다.

스프링부트테스트는 통합 테스트에 사용됩니다. 모든 테스트가 이를 사용하는 것은 바람직하지 않습니다.
가능한 한 최소한의 스프링 부팅 인프라를 로드하면서도 정확한 테스트를 보장하고자 합니다.

몇 가지 도움이 될 수 있습니다:

테스트가 DB와 관련된 경우. 데이터몽고테스트 또는 @Import 어노테이션이 있는 동등한 JPA runner를 사용합니다.
테스트가 웹/컨트롤러와 관련된 경우. WebFluxTest 또는 이와 동등한 Spring MVC 런너를 사용합니다. 임베디드 MongoDB를 함께 사용하려면 @AutoConfigureDataMongo를 사용하세요. 대부분의 다른 시스템에도 @AutoConfigure{systemName}으로 시작하는 어노테이션이 있습니다.
중요: 테스트에서 단일 빈을 초기화해야 하는 경우. @import와 함께 @ExtendWith(SpringRunner.class)를 사용하여 초기화할 빈을 지정하세요.
가장 좋은 경우: 순전히 자바 기반이며 스프링 부팅을 포함하지 않는 테스트를 목표로 하되, 모든 시나리오에서 가능한 것은 아닙니다.

Speeding up @SpringBootTest and avoiding @DirtiesContext (Saved 25% running time)

DirtiesContext는 각 테스트 또는 각 테스트 클래스 후에 Spring 컨텍스트를 다시 생성하는 어노테이션입니다. DirtiesContext를 사용하지 않으려면 모든 테스트가 동일한 데이터에 의존하지 않도록 하세요. 이를 위해 테스트 데이터 팩토리에서 데이터 생성을 래핑하고 생성된 데이터가 무작위인지 확인할 수 있습니다.

앞서 언급했듯이 @SpringBootTest를 사용하지 않는 것이 좋지만, 어쩔 수 없이 사용해야 하는 경우 @DirtiesContext 없이 WebEnvironment.MOCK을 사용해야 합니다.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)

빈 생성을 제한하려면 @Import 또는 @ContextConfiguration과 함께 사용하세요.

Run tests in parallel (Saved 37% running time)

test/resource/junit-platform.properties에 junit-platform.properties 파일을 생성하고 다음 최소값을 추가합니다.

junit.jupiter.execution.parallel.enabled = true

이제 다음 중 하나를 사용할 수 있습니다,

병렬로 실행하려는 모든 클래스에 다음을 추가합니다. @Execution(CONCURRENT)
junit-platform.properties에 추가하기

junit.jupiter.execution.parallel.mode.default = same_thread|concurrent
junit.jupiter.execution.parallel.mode.classes.default =  same_thread|concurrent

일부 테스트는 병렬로 실행할 수 없으므로 @Execution(CONCURRENT)를 수동으로 추가하는 것을 선호합니다.
다른 데이터에 대해 asserting하여 @DataMongoTest로 데이터 테스트를 찾았습니다.
@Execution(CONCURRENT)의 또 다른 긍정적인 효과는 이러한 테스트가 먼저 실행된다는 것입니다. 그리고 이러한 테스트는 SAME_THREAD mode보다 빠르기 때문에 즉각적인 피드백으로 이어집니다.

Optimizing Spring Integration Tests

성게군. — Sun, 26 Nov 2023 01:13:08 +0900

https://www.baeldung.com/spring-tests

주요 부분이라고 생각한 것만 한글화.

2. Integration Tests

통합 테스트는 자동화된 테스트 suites의 기본적인 부분입니다. 하지만 건강한 테스트 피라미드를 따른다면 단위 테스트만큼 많지는 않아야 합니다. Spring과 같은 프레임워크에 의존하면 시스템의 특정 동작에 대한 위험을 제거하기 위해 상당한 양의 통합 테스트가 필요합니다.

Spring 모듈(데이터, 보안, 소셜 등)을 사용하여 코드를 더 단순화할수록 통합 테스트의 필요성은 더 커집니다. 특히 인프라의 일부분을 @Configuration 클래스로 옮길 때 더욱 그렇습니다.

"프레임워크를 테스트"해서는 안 되지만, 프레임워크가 우리의 요구 사항을 충족하도록 구성되어 있는지 확실히 확인해야 합니다.

통합 테스트는 신뢰를 구축하는 데 도움이 되지만 대가가 따릅니다:

실행 속도가 느려지므로 빌드 속도가 느려집니다.
또한 통합 테스트는 더 넓은 테스트 범위를 의미하므로 대부분의 경우 이상적이지 않습니다.

3. Testing Web Apps

Spring에는 웹 애플리케이션을 테스트하기 위한 몇 가지 옵션이 있으며, 대부분의 Spring 개발자는 이러한 옵션에 익숙합니다:

MockMvc: 비반응형 웹 앱에 유용한 서블릿 API를 모의 처리 합니다.
TestRestTemplate: 특정 앱을 가리키는 데 사용할 수 있으며, 모의 서블릿이 바람직하지 않은 비반응형 웹 앱에 유용합니다.
웹테스트클라이언트: 모의 요청/응답을 사용하거나 실제 서버를 호출하는 반응형 웹 앱용 테스트 도구입니다.

이미 이러한 주제를 다루는 기사가 있으므로 이에 대해서는 따로 설명하지 않겠습니다.
더 자세히 알아보고 싶으시다면 언제든지 찾아보시기 바랍니다.

4. Optimizing Execution Time

통합 테스트는 훌륭합니다. 통합 테스트는 우리에게 상당한 자신감을 줍니다. 또한 적절하게 구현하면 앱의 의도를 매우 명확하게 설명할 수 있으며, 모의 테스트와 설정 노이즈가 줄어듭니다.

하지만 앱이 성숙해지고 개발이 쌓이면 빌드 시간은 필연적으로 늘어납니다. 빌드 시간이 길어지면 매번 모든 테스트를 계속 실행하는 것이 비현실적으로 될 수 있습니다.

그 후에는 피드백 루프에 영향을 미치고 모범 개발 사례를 따르는 데 방해가 됩니다.

또한 통합 테스트는 본질적으로 비용이 많이 듭니다. 일종의 지속성을 시작하거나, 요청을 전송하거나(로컬호스트를 벗어나지 않더라도), 일부 IO를 수행하는 데는 시간이 걸립니다.

테스트 실행을 포함하여 빌드 시간을 주시하는 것이 가장 중요합니다. 그리고 이 시간을 줄이기 위해 Spring에서 적용할 수 있는 몇 가지 트릭이 있습니다.

다음 섹션에서는 빌드 시간을 최적화하는 데 도움이 되는 몇 가지 사항과 속도에 영향을 줄 수 있는 몇 가지 함정에 대해 알아보겠습니다:

현명한 프로필 사용 - 프로필이 성능에 미치는 영향
MockBean 재검토 - 모킹이 성능에 미치는 영향
MockBean 리팩토링 - 성능 향상을 위한 대안
DirtiesContext에 대해 신중하게 생각하기 - 유용하지만 위험한 주석과 이를 사용하지 않는 방법
테스트 슬라이스 사용 - 도움이 되거나 방해가 될 수 있는 멋진 도구
클래스 상속 사용 - 안전한 방식으로 테스트를 구성하는 방법
상태 관리 - 엉성한 테스트를 방지하는 모범 사례
단위 테스트로 리팩토링하기 - 견고하고 빠른 빌드를 위한 가장 좋은 방법

4.1. Using Profiles Wisely

프로필은 매우 깔끔한 도구입니다. 즉, 앱의 특정 영역을 활성화 또는 비활성화할 수 있는 간단한 태그입니다. 심지어 기능 플래그를 구현할 수도 있습니다!

프로필이 더 풍부해지면 통합 테스트에서 가끔씩 프로필을 바꾸고 싶을 때가 있습니다. 액티브 프로필과 같은 편리한 도구가 있습니다. 하지만 새 프로필로 테스트를 실행할 때마다 새 ApplicationContext가 생성됩니다.

아무것도 없는 바닐라 스프링 부팅 앱을 사용하면 애플리케이션 컨텍스트를 빠르게 생성할 수 있습니다. ORM과 몇 개의 모듈을 추가하면 7초 이상으로 빠르게 늘어납니다.

여러 프로필을 추가하고 몇 가지 테스트를 통해 분산하면 60초 이상의 빌드를 빠르게 얻을 수 있습니다(빌드의 일부로 테스트를 실행한다는 가정 하에, 그리고 실제로 실행해야 합니다).

일단 충분히 복잡한 애플리케이션에 직면하게 되면 이 문제를 해결하는 것은 매우 어렵습니다. 하지만 미리 신중하게 계획을 세운다면 합리적인 빌드 시간을 유지하는 것은 그리 어려운 일이 아닙니다.

통합 테스트의 프로필과 관련하여 염두에 두어야 할 몇 가지 요령이 있습니다:

종합 프로필(예: 테스트)을 생성하고, 그 안에 필요한 모든 프로필을 포함하세요 - 어디에서나 테스트 프로필을 고수하세요.
테스트 가능성을 염두에 두고 프로필을 디자인하세요. 프로필을 전환해야 하는 경우 더 나은 방법이 있을 수 있습니다.
테스트 프로필을 중앙 집중식 장소에 명시하세요 - 이에 대해서는 나중에 설명하겠습니다.
모든 프로필 조합을 테스트하지 마세요. 또는 특정 프로필 세트로 앱을 테스트하는 환경별 e2e 테스트 스위트를 만들 수 있습니다.

4.2. The Problems with @MockBean

모의빈은 매우 강력한 도구입니다.

Spring의 마법이 필요하지만 특정 컴포넌트를 모방하고 싶을 때 @MockBean은 매우 유용합니다. 하지만 대가가 따릅니다.

클래스에서 @MockBean이 나타날 때마다 ApplicationContext 캐시가 더티로 표시되므로 테스트 클래스가 완료된 후 런너가 캐시를 정리합니다. 이는 다시 빌드에 몇 초를 더 추가합니다.

이것은 논란의 여지가 있지만, 이 특정 시나리오에 대해 모의 테스트 대신 실제 앱을 실행해 보는 것이 도움이 될 수 있습니다. 물론 여기에 만병통치약은 없습니다. 종속성 모킹을 허용하지 않으면 경계가 모호해집니다.

테스트하고 싶은 것이 REST 계층뿐인데 왜 계속 테스트해야 하냐고 생각할 수 있습니다. 이는 타당한 지적이며, 항상 타협점이 존재합니다.

하지만 몇 가지 원칙을 염두에 두면 테스트와 앱을 더 잘 설계하고 테스트 시간을 단축할 수 있는 이점으로 전환할 수 있습니다.

4.3. Refactoring @MockBean

이 섹션에서는 @MockBean을 사용하여 '느린' 테스트를 리팩터링하여 캐시된 ApplicationContext를 재사용하도록 해 보겠습니다.

사용자를 생성하는 POST를 테스트하고 싶다고 가정해 보겠습니다. 모의 테스트에서 @MockBean을 사용하면 서비스가 제대로 직렬화된 사용자로 호출되었는지 간단히 확인할 수 있습니다.

서비스를 제대로 테스트했다면 이 방법으로도 충분할 것입니다:

하지만 @MockBean은 피하고 싶습니다. 따라서 결국 엔티티를 유지하게 될 것입니다(서비스가 그렇게 한다고 가정할 때).

여기서 가장 순진한 접근 방식은 부작용을 테스트하는 것입니다: 게시 후 내 사용자는 내 DB에 있으며, 이 예제에서는 JDBC를 사용합니다.

그러나 이는 테스트 경계를 위반하는 것입니다:

이 특정 예제에서는 사용자를 전송하기 위해 앱을 HTTP 블랙박스로 취급하지만 나중에 구현 세부 정보, 즉 사용자가 일부 DB에 지속되었다고 주장하기 때문에 테스트 경계를 위반합니다.

HTTP를 통해 앱을 실행하면 결과도 HTTP를 통해 어설트할 수 있을까요?

마지막 접근 방식을 따르는 경우 몇 가지 장점이 있습니다:

테스트가 더 빨리 시작됩니다(실행하는 데 시간이 조금 더 걸릴 수 있지만, 그만한 가치가 있습니다).
또한, 테스트는 HTTP 경계와 관련이 없는 부작용(예: DB)을 인식하지 못합니다.
마지막으로, 이 테스트는 시스템의 의도를 명확하게 표현합니다: POST하면 GET 사용자가 가능합니다.
물론 여러 가지 이유로 항상 가능하지 않을 수도 있습니다:

'부작용' 엔드포인트가 없을 수도 있습니다: 여기서 한 가지 옵션은 '테스트 엔드포인트' 생성을 고려하는 것입니다.
앱 전체에 적용하기에는 복잡성이 너무 높은 경우: 슬라이스를 고려하는 옵션이 있습니다(이에 대해서는 나중에 설명하겠습니다).

4.4. Thinking Carefully About @DirtiesContext

때때로 테스트에서 ApplicationContext를 수정해야 할 수도 있습니다. 이 시나리오의 경우 @DirtiesContext가 정확히 그 기능을 제공합니다.

위에서 설명한 것과 같은 이유로 @DirtiesContext는 실행 시간 측면에서 매우 비싼 리소스이므로 주의해야 합니다.

애플리케이션 캐시 재설정 또는 메모리 내 DB 재설정을 위해 @DirtiesContext를 오용하는 경우도 있습니다. 통합 테스트에서 이러한 시나리오를 처리하는 더 좋은 방법이 있으며, 다음 섹션에서 몇 가지를 다룰 것입니다.

4.5. Using Test Slices

테스트 슬라이스는 1.4에 도입된 Spring Boot 기능입니다. 개념은 매우 간단합니다. Spring은 앱의 특정 슬라이스에 대해 축소된 애플리케이션 컨텍스트를 생성합니다.

또한 프레임워크는 최소한의 구성만 처리합니다.

Spring Boot에는 기본적으로 사용할 수 있는 적절한 수의 슬라이스가 있으며, 자체 슬라이스를 만들 수도 있습니다:

@JsonTest: JSON 관련 컴포넌트를 등록합니다.
@DataJpaTest: 사용 가능한 ORM을 포함한 JPA 빈을 등록합니다.
@JdbcTest: 원시 JDBC 테스트에 유용하며, 데이터 소스 및 메모리 내 DB를 ORM 없이 처리합니다.
데이터몽고테스트: 인메모리 몽고 테스트 설정을 제공하려고 시도합니다.
WebMvcTest: 앱의 나머지 부분이 없는 모의 MVC 테스트 슬라이스
... (소스를 확인하여 모두 찾을 수 있음)

이 기능을 현명하게 사용하면 특히 중소규모 앱의 경우 성능 측면에서 큰 불이익 없이 좁은 범위의 테스트를 구축하는 데 도움이 될 수 있습니다.

하지만 애플리케이션이 계속 커지면 슬라이스당 하나의 (작은) 애플리케이션 컨텍스트가 생성되므로 이 또한 쌓이게 됩니다.

4.6. Using Class Inheritance

모든 통합 테스트의 부모로 단일 AbstractSpringIntegrationTest 클래스를 사용하는 것은 빌드를 빠르게 유지하는 간단하고 강력하며 실용적인 방법입니다.

우리가 탄탄한 설정을 제공하면, 우리 팀은 모든 것이 '그냥 작동'한다는 것을 알고 간단히 확장할 수 있습니다. 이렇게 하면 상태 관리나 프레임워크 구성에 대한 걱정을 덜고 당면한 문제에 집중할 수 있습니다.

모든 테스트 요구 사항을 설정할 수 있습니다:

Spring 주자 - 나중에 다른 주자가 필요할 경우를 대비해 규칙을 설정하는 것이 좋습니다.
프로필 - 이상적으로는 우리의 종합 테스트 프로필
초기 구성 - 애플리케이션의 상태 설정

앞의 사항을 처리하는 간단한 베이스 클래스를 살펴봅시다:

4.7. State Management

단위 테스트의 '단위'가 어디에서 왔는지 기억하는 것이 중요합니다. 간단히 말해, 단일 테스트(또는 하위 집합)를 언제든지 실행하여 일관된 결과를 얻을 수 있다는 뜻입니다.

따라서 모든 테스트가 시작되기 전에 상태가 깨끗하고 알려져 있어야 합니다.

즉, 테스트가 단독으로 실행되든 다른 테스트와 함께 실행되든 관계없이 테스트 결과가 일관적이어야 합니다.

이 아이디어는 통합 테스트에도 동일하게 적용됩니다. 새 테스트를 시작하기 전에 앱이 알려진(그리고 반복 가능한) 상태인지 확인해야 합니다. 속도를 높이기 위해 재사용하는 구성 요소(앱 컨텍스트, DB, 대기열, 파일 등)가 많을수록 상태 오염이 발생할 가능성이 높아집니다.

클래스 상속을 사용했다고 가정하면 이제 상태를 관리할 수 있는 중앙 집중식 공간이 생겼습니다.

테스트를 실행하기 전에 앱이 알려진 상태에 있는지 확인하기 위해 추상 클래스를 개선해 보겠습니다.

이 예제에서는 다양한 데이터 소스의 여러 리포지토리와 와이어목 서버가 있다고 가정하겠습니다:

4.8. Refactoring into Unit Tests

이것이 아마도 가장 중요한 포인트 중 하나일 것입니다. 실제로 앱의 상위 정책을 실행하는 몇 가지 통합 테스트를 반복해서 수행하게 될 것입니다.

핵심 비즈니스 로직의 여러 사례를 테스트하는 통합 테스트를 발견할 때마다 접근 방식을 재고하고 단위 테스트로 세분화해야 할 때입니다.

이를 성공적으로 수행하기 위한 가능한 패턴은 다음과 같습니다:

핵심 비즈니스 로직의 여러 시나리오를 테스트하는 통합 테스트를 식별합니다.
제품군을 복제하고 복사본을 단위 테스트로 리팩터링 - 이 단계에서는 프로덕션 코드도 테스트할 수 있도록 세분화해야 할 수 있습니다.
모든 테스트를 녹색으로 설정
통합 제품군에서 충분히 주목할 만한 행복한 경로 샘플을 남겨둡니다 - 몇 가지를 리팩터링하거나 조인 및 재구성해야 할 수도 있습니다.
나머지 통합 테스트 제거

transaction isolation level

성게군. — Sat, 4 Nov 2023 23:43:29 +0900

대부분 업무를 하다 보면 기본적 level만 사용하기 때문에. (특별한 domain logic 처리가 요구 되지 않는한.)

이런 level들을 기억하기 쉽지 않다. 그렇다고 안 중요한 부분도 아니라서 세부내용은 그때 그때 찾아 볼수 있게 해두는게 좋다.

그래서 blogging...

meeting : where to go?

성게군. — Wed, 1 Nov 2023 01:30:53 +0900

최근에 했던 meeting들을 돌이켜 보면서 문득 스친 생각들을 적어본다.

key point(warm up) -> discussion -> decision making -> summary text

meeting의 목적은 여러 이유가 있을 수 있겠지만,
내가 참여하는 부분에서는 어떤 이슈에 대한 공유나 크던 작던 의사결정이 대부분이다.
그 외에 주제들은 다른 커뮤니케이션 도구들로 공유가 되게 된다.

그래서, 최근의 meeting들도 특정한 주제에 대한 논의들이 대부분이었고,
실제 어떤 이슈가 있었고, 어떤 방식으로 풀어 나갈지 의견을 교환을 했었다.

여기서 조금 잘 하지 못하거나 아쉬웠던 점들은
이 논의가 브레인스토밍 형태로 다양한 방법을 만드는데 목적인지?
지금 겪고 있는 이슈들에 대한 처리나 대응에 대한 의사결정이 목적인지?
과도한 issue one-shot 처리를 위한 meeting 이었는지?
....... 등등
위 물음에 대한 적절한 흐름으로 원하는 형태로 잘 도출 되었는지에 대한 인식이 부족했던 지점이다.

그래서,
meeting의 간략한 key point를 시작 전에 인지 할 수 있는 warm up이 필요하고,
애초에 목표한 성격으로 논의가 잘 진행 되게 컨트롤 하여야 하고,
meeting의 완료 될 시점에 분명한 텍스트가 정리가 되어서 기록이 남겨져야 한다는 것을 되새기게 되었다.

meeting의 무척 중요한 지점은 여러 참가자의 resource를 필요로 하기 때문이다.
그렇기 때문에 덜 준비 된 meeting내용과 참여자들의 불성실함들은 meeting무용론이 나오기 딱 좋은 원인이다.

수려하게 잘 정리 되는 것이 목적이 아닌,
적어도 참여자들이 최종적으로 논의/동의한 내용이 이해 할 수 있는 수준의 텍스트로만 정리가 되어도
그 meeting은 앞으로의 업무나 여러 여정에 큰 도움이 될 것이라 확신 한다.

A guide to input validation with Spring Boot

성게군. — Sat, 28 Oct 2023 00:58:43 +0900

https://medium.com/@snyksec/a-guide-to-input-validation-with-spring-boot-f041b19c82e6

A guide to input validation with Spring Boot

스프링 부트 빈 유효성 검사 구현하기
이 튜토리얼에서는 인메모리 데이터베이스를 사용하는 간단한 CRUD(생성, 읽기, 업데이트, 삭제) 애플리케이션에 대한 Bean 유효성 검사를 구현합니다. 사용자는 이름, 이메일 및 비밀번호를 제공하며, 특정 기준을 충족해야 허용됩니다. 여기서 사용되는 상위 수준 아키텍처는 RESTful API가 포함된 백엔드 서버와 인메모리 H2 데이터베이스로 구성됩니다.

클라이언트 애플리케이션이 웹 서비스(이 튜토리얼의 애플리케이션)를 호출하면 요청이 UserController로 전달됩니다. 그 후 컨트롤러는 요청에 데이터 유효성 검사를 적용합니다. 데이터가 유효하면 요청은 UserRepository로 이동하여 인메모리 데이터베이스와 통신하고 관련 응답을 반환합니다. 그렇지 않으면 데이터가 유효하지 않으며 요청은 오류 메시지와 함께 클라이언트로 다시 전송됩니다:

Monitoring Spring Boot 3

성게군. — Sat, 28 Oct 2023 00:50:08 +0900

Springboot 3이 출시 되면서, 기존 하위 버전이하를 포함해서 모니터링 관련 내용을 되새겨 볼만한 포스트.

https://medium.com/@minadev/monitoring-and-observability-with-spring-boot-3-2cb9cdb74a85

API Architectural Styles

성게군. — Wed, 20 Sep 2023 11:11:12 +0900

https://medium.com/@saadmujeeb/the-ultimate-guide-to-api-architectural-styles-c8c781014835

The Ultimate Guide to API Architectural Styles

Discover the top API architectural styles — SOAP, REST, GraphQL, gRPC, WebSocket, and Webhook — in this comprehensive, engaging guide.

medium.com

https://www.linkedin.com/posts/nelsonamigoscode_systemdesign-coding-interviewtips-activity-7107264125214277633-uW1E/?utm_source=share&utm_medium=member_ios

LinkedIn Nelson Djalo 페이지: #systemdesign #coding #interviewtips | 댓글 98

6️⃣ Popular API Architecture Styles 1. gRPC: A high-performance, language-agnostic remote procedure call (RPC) framework for efficient communication between… | 댓글 98

www.linkedin.com

1. gRPC: 분산 시스템 간의 효율적인 통신을 위한 고성능, 언어에 구애받지 않는 원격 프로시저 호출(RPC) 프레임워크로, 마이크로서비스 아키텍처에서 자주 사용됩니다.

2. SOAP: 웹 서비스 구현 시 구조화된 정보를 교환하기 위한 프로토콜로, 엄격한 표준과 XML 기반 메시지 형식으로 유명합니다.

3. GraphQL: 클라이언트가 필요한 데이터만 요청할 수 있도록 하여 데이터의 과다 가져오기 및 과소 가져오기를 줄여주는 API용 쿼리 언어 및 런타임입니다.

4. 웹후크: 애플리케이션이 미리 정의된 URL로 HTTP POST 요청을 전송하여 다른 시스템에서 작업을 알리고 트리거하는 실시간 통신 메커니즘입니다.

5. REST: 네트워크 애플리케이션을 설계하기 위한 아키텍처 스타일로, 리소스를 조작하기 위해 표준 HTTP 메서드(GET, POST, PUT, DELETE)를 사용하는 표현 상태 전송입니다.

6. 웹소켓: 수명이 긴 단일 연결을 통해 클라이언트와 서버 간의 양방향 실시간 통신을 가능하게 하는 프로토콜로, 채팅이나 게임과 같이 지연 시간이 짧은 업데이트가 필요한 애플리케이션에 이상적입니다.

How To Github Actions Local Test

성게군. — Sat, 19 Aug 2023 00:25:55 +0900

act

https://github.com/nektos/act
local 환경에서 github actions을 테스트 할 수 환경 구성
First act run
- GITHUB_TOKEN
  - gitbug token기반으로 github와 연결되어 있는 경우, 추가적인 shell option 필요
  - shell act -s GITHUB_TOKEN="$(gh auth token)" : github cli 방식 선호, gh 설치 필요
Secrets
- shell act --secret-file my.secrets : my.secrets 파일 내에 secret 변수 선언
  - ex) my.secrets -> SLACK_WEBHOOK_URL=xxxxxxxxxxxxxx

act local test shell

// Test 대상 git repository root 위치에서 아래 shell 실행

// 1. actions 목록조회
act -l
act -l --container-architecture linux/amd64 <- mac m1 이상 환경인 경우



// 2. 실행 방법

// 2-1. actions 특정 job 지정 실행
act -j "act -l 의 job name" --secret-file local.secrets -s GITHUB_TOKEN="$(gh auth token)"


// 2-2. 특정한 workflow만 실행하기
act -j lint -W .github/workflows/test.yml

slack webhook URL test

성게군. — Sat, 19 Aug 2023 00:16:54 +0900

slack을 통해서 여러가지 알림들을 받는게 기본이 된 시대.

의식적으로 채널에 알림연동을 하고, 실제 workin의 결과를 통해서 연동이 잘 되어 있음을 확인 하곤 했었다.
그러다, 최근 실제 working이 되기 전에 어떻게 Test 할 수 있나 라는 뒤늦은 생각이 들었다.

그래서. 기록으로 남겨둔다...

slack webhook URL test

POST https://hooks.slack.com/services/xxxxxx
Content-type: application/json
{
    "text": "Hello, world."
}

curl

curl --request POST \
  --url https://hooks.slack.com/services/xxxxxx \
  --header 'Content-type: application/json' \
  --data '{"text":"Hello, world."}'

httpie

// style1
echo '{"text":"Hello, world."}' |  \
http POST https://hooks.slack.com/services/xxxxxx \
Content-type:application/json

// style2
http --json -v POST https://hooks.slack.com/services/xxxxxx  "text"="Hello, world."

Spring Actuator Health Probe

성게군. — Mon, 31 Jul 2023 15:56:06 +0900

What’s Kubernetes Probe

Probe	설명
livenessProbe	livenessProbe를 통과하지 못하면, kubelet은 container를 종료하고, 해당 container는 재시작 정책의 대상이 됩니다.
readinessProbe	readinessProbe를 통과하지 못하면, endpoint controller는 pod와 연관된 모든 서비스의 endpoint에서 pod의 IP 주소를 제거합니다.
startupProbe	startupProbe가 시작되면 startupProbe를 통과하기 전까지 다른 Probe는 활성화되지 않습니다. 만약 startupProbe를 통과하지 못하면 kubelet은 container를 종료하고 해당 container는 재시작 정책의 대상이 됩니다.

Pod Lifecycle

https://loft.sh/blog/kubernetes-probes-startup-liveness-readiness/
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/
startupProbe에서 container상태를 확인하고, livenessProbe와 readinessProbe에서 container상태를 최종 확인하며 pod상태 결정
- 위 과정이 완료되기 전까지 network traffic을 차단
정상적으로 pod구동 된 이후,
- livenessProbe : 상태를 check 하고, pod을 재시작 할지 확인
- readinessProbe : pod에 traffic을 보낼지 결정

HowTo

Spring Framework

https://www.baeldung.com/spring-liveness-readiness-probes
Spring Actuator
- Liveness : /actuator/health/liveness
- Readiness : /actuator/health/readiness
- custom status
  - https://www.baeldung.com/spring-liveness-readiness-probes#1-updating-the-availability-state
  - AvailabilityChangeEvent 를 통해, 각 probe의 상태를 변경 할 수 있다
  - 서비스의 특정한 상황에 따른 상태변경 요청이 가능하다.

Git config - 사용자 정보 설정

성게군. — Fri, 21 Jul 2023 23:19:23 +0900

현재 설정 정보 확인

➜ ~ git config --list

credential.helper=osxkeychain

init.defaultbranch=main

user.name=블라블라(GP Kim) / Tech

user.email=gp.kim@sang.com

core.excludesfile=/Users/axxxxxxx/.gitignore_global

difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE"

difftool.sourcetree.path=

mergetool.sourcetree.cmd=/Applications/Sourcetree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED"

mergetool.sourcetree.trustexitcode=true

commit.template=/Users/axxxxxxx/.stCommitMsg

filter.lfs.process=git-lfs filter-process

filter.lfs.required=true

filter.lfs.clean=git-lfs clean -- %f

filter.lfs.smudge=git-lfs smudge -- %f

사용자 정보 변경

$ git config --global user.name "John Doe"

$ git config --global user.email johndoe@example.com

참고

Synchronous, Asynchronous, Blocking, Non-Blocking

성게군. — Tue, 4 Jul 2023 01:13:21 +0900

Synchronous vs Asynchronous

동기와 비동기를 구준하는 주요 기준은 작업순서의 보장 여부

Synchronous(동기화)

작업의 순서가 보장됨. Thread는 요청한 작업의 결과를 받고 다음 작업 진행
특정 API의 응답 반환 시간이 n분 소요 된다고 하면 이 요청이 실행 되는 n분 동안 Process/Thread는 다른 작업을 하지 못하고, 응답이 반환 되기를 기다려야 한다.
장점 : 설계가 간단하고 직관적이다.
단점 : 요청에 대한 결과가 반환되기 전까지 대기해야 한다.

Asynchronous(비동기화)

작업의 순서가 보장 되지 않음. Thread는 요청한 작업의 결과를 받지 않고 다음 작업 진행
특정 API를 실행 하는데 시간이 n분 소요 되어도 그 시간동안 다른 작업을 수행할 수 있다.
장점 : 요청에 대한 결과가 반환되기 전에 다른 작업을 수행할 수 있어서 자원을 효율적으로 사용할 수 있다.
단점 : 동기 방식보다 설계가 복잡하고, 논증적이다.

Asynchronous 구현 방식

Thread : 기본 구현 방식
Future : 요청 작업 비동기로 결과 반환
Completable Future : 의존성 있는 비동기 작업 처리
Spring Async Task : Spring Async Threadpool 내에서 Thread 처리

Blocking vs Non-Blocking

블럭킹과 논블럭킹을 구분하는 주요기준은 제어권의 양도 시점

Blocking

특정 함수(A)가 다른 함수(B)를 호출할 때, 호출한 함수(B)에게 제어권을 양도 → 함수 A는 제어권을 상실함으로써 일시적으로 작업을 멈춤
Process는 요청한 작업이 종료 될 때 까지 waiting

Non-Blocking

특정 함수(A)가 다른 함수(B)를 호출할 때, 호출한 함수(B)에게 제어권을 양도 하지 않음
Process는 요청한 작업이 끝나지 않더 라도 작업을 진행 할 수 있음

6-Caching Strategies to Remember while designing Cache System

성게군. — Sat, 17 Jun 2023 01:50:43 +0900

https://javascript.plainenglish.io/6-caching-strategies-to-remember-while-designing-cache-system-da058a3757cf

6-Caching Strategies to Remember while designing Cache System

How to invalidate the cache, strategies around Read v/s Write Cache,Ways to invalidate the Cache, terminologies around Cache System & Much…

javascript.plainenglish.io

캐시 시스템의 주요 성능 지표

캐시 적중률: 이 메트릭은 요청된 항목이 캐시에서 발견된 횟수의 비율을 측정합니다. 캐시 적중률이 높을수록 캐시에서 더 많은 데이터가 제공되어 외부 저장소에 액세스할 필요성이 줄어들고 성능이 향상됩니다.
지연 시간: 지연 시간은 데이터에 액세스하는 데 걸리는 시간을 의미합니다. 캐싱 시스템에서 지연 시간이 짧다는 것은 데이터가 더 빨리 제공되어 전반적인 성능이 향상된다는 것을 의미합니다.
처리량: 처리량은 주어진 시간 프레임에서 처리할 수 있는 데이터의 양을 측정합니다. 처리량이 높은 캐싱 시스템은 더 많은 요청을 처리하고 더 많은 데이터를 제공할 수 있으므로 전반적인 성능이 향상됩니다.
캐시 크기: 캐시 크기는 캐시에 할당된 메모리 또는 스토리지의 양입니다. 캐시 크기는 캐시의 적중률과 누락률에 영향을 줄 수 있습니다. 캐시 크기가 클수록 적중률이 높아질 수 있지만 캐싱 솔루션의 비용과 복잡성이 증가할 수 있습니다.
캐시 미스 비율: 이 지표는 요청된 항목이 캐시에서 발견되지 않아 외부 저장소에서 가져와야 하는 횟수의 비율을 측정합니다. 캐시 누락률이 높다는 것은 외부 스토리지에서 더 많은 데이터를 가져와 성능이 저하된다는 것을 의미합니다.

캐시 무효화 방법

시간 기반 무효화(TTL): 이 전략에서는 일정 시간이 지나면 캐시에 있는 데이터가 무효화됩니다. 이는 구현하기 쉬운 간단하고 효과적인 전략입니다. 그러나 일부 데이터는 다른 데이터보다 빠르게 오래될 수 있으므로 모든 사용 사례에 적합하지 않을 수 있습니다.
이벤트 기반 무효화: 이 전략에서는 기본 데이터 소스 변경 또는 기타 관련 이벤트와 같이 발생하는 특정 이벤트에 따라 캐시의 데이터가 무효화됩니다. 이는 필요한 경우에만 데이터가 무효화되도록 하는 보다 타깃화된 무효화 접근 방식입니다. 하지만 애플리케이션 및 기초 데이터 소스와의 향상된 통합이 필요합니다.
버전 기반 무효화: 이 전략에서는 캐시에 있는 각 데이터에 데이터가 변경될 때마다 증가하는 버전 번호가 할당됩니다. 데이터가 무효화되면 캐시에서 버전 번호가 업데이트되어 가장 최신 버전의 데이터만 사용되도록 합니다. 이 전략은 자주 변경되는 데이터에 효과적일 수 있지만 버전 번호를 관리하는 데 추가적인 오버헤드가 필요합니다.
가장 최근에 사용된(LRU) 무효화: 이 전략에서는 캐시가 용량 제한에 도달하면 캐시에서 가장 최근에 사용된 데이터가 무효화됩니다. 이렇게 하면 가장 자주 사용되는 데이터가 캐시에 남아 오래된 데이터를 저장할 위험이 줄어듭니다. 그러나 일부 데이터는 자주 액세스하지 않지만 여전히 캐시에 저장해야 할 수 있으므로 모든 사용 사례에 적합하지 않을 수 있습니다.
수동 무효화: 이 전략에서는 애플리케이션 또는 관리자가 수동으로 무효화를 트리거합니다. 이 방법은 캐시에 대한 유연성과 제어가 가장 뛰어나지만 무효화 프로세스를 관리하는 데 더 많은 오버헤드가 필요합니다. 여기에는 퍼지, 금지, 새로 고침과 같은 몇 가지 방법이 포함됩니다.

Five API Performance Optimization Tricks that Every Java Developer Must Know

성게군. — Sat, 10 Jun 2023 12:29:10 +0900

https://medium.com/javarevisited/five-api-performance-optimization-tricks-that-every-java-developer-must-know-75324ee1d244

Five API Performance Optimization Tricks that Every Java Developer Must Know

Why is your API response so slow? Maybe you need to solve these problems.

medium.com

Five Tricks

Parallel call
Avoid large transaction
Add appropriate index
Return fewer data
Use cache

Finally

여기에 5가지 일반적인 API 성능 최적화 요령을 나열했습니다. 이러한 트릭은 시스템에 특정 동시 접속자가 몰리는 경우에만 효과적입니다. 시스템 액세스가 많지 않은 경우에는 위의 제안을 신중하게 고려하시기 바랍니다. 보다 효과적인 다른 솔루션을 찾아보시기 바랍니다.

Databases: An Overview - MongoDB

성게군. — Fri, 9 Jun 2023 13:14:59 +0900

https://towardsdatascience.com/databases-an-overview-97c54628b824

Databases: An Overview

Part 2: Underlying Architecture of Distributed File Systems of MongoDB and HBase and Database Operations in Python

towardsdatascience.com

MongoDB

MongoDB is a document-based NoSQL database. It requires no fixed schema definition. Mongo DB stores data as Binary JSON or BSON. It supports horizontal scaling. Several servers instance group together as a cluster to support Mongo DB as a distributed system.

MongoDB uses MongoDB query language and supports Adhoc queries, Replication, and Sharding. Sharding is a feature of MongoDB that helps it to operate as a distributed data system. Let’s look at how MongoDB implements these features.

Replication in Mongo

Replication serves as a very important feature in order to protect data loss from one server, increase the availability of data, and give protection from failures.

MongoDB achieves replication using the concept replica sets. A replica set is a group of mongod instances that host the same data set. One of the nodes is selected as the primary or main node. This is called the primary node. All others are called secondary nodes. The primary node receives all the operations from the user and the secondaries are updated from the primary one by using the same operation to maintain consistency. If the primary node goes down, one of the secondary nodes is selected as the primary node and the operations are carried forward. When the fallen node recovers, it joins the cluster as the secondary nodes. We can control our cluster of mongo instances using Mongo Atlas. Mongo clusters are created based on the idea of horizontal scaling and adding of instances.

Replica set schematic: Image by Author

Sharding in Mongo DB

Sharding is used by MongoDB to store data across multiple machines. It uses horizontal scaling to add more machines to distribute data and operation with respect to the growth of load and demand.

Sharding arrangement in MongoDB has mainly three components:

Shards or replica sets: Each shard serves as a separate replica set. They store all the data. They target to increase the consistency and availability of the data.
Configuration Servers: They are like the managers of the clusters. These servers contain the cluster's metadata. They actually have the mapping of the cluster's data to the shards. When a query comes, query routers use these mappings from the config servers to target the required shard.
Query Router: The query router is mongo instances which serve as interfaces for user applications. They take in the user queries from the applications and serve the applications with the required results. Usually, there are multiple query router per cluster for load distribution.

Image by author

The above image shows the sharding arrangement for MongoDB. Though the image has only 2 query servers and shards, generally there are more in an actual cluster, though by default case there are 3 config servers in a cluster.

The ideas we talked about above are the two most important ideas behind MongoDB operations and its distributed data system architecture.

Now, let’s take a look at how Apache HBase implements the ideas of distributed systems.

Docker Architecture

성게군. — Fri, 9 Jun 2023 13:12:55 +0900

https://medium.com/@basecs101/understanding-docker-architecture-latest-c7a165571d89

Understanding Docker Architecture

Know the docker design and its complete working mechanism

medium.com

https://velog.io/@koo8624/Docker-%EB%B2%88%EC%97%AD-%EB%8F%84%EC%BB%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-Docker-Architecture-Overview

https://www.leafcats.com/146

The Architecture of Prometheus

성게군. — Fri, 9 Jun 2023 13:09:36 +0900

https://prometheus.io/docs/introduction/overview/

Overview | Prometheus

An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.

prometheus.io

https://badcandy.github.io/2018/12/25/prometheus-architecture/

Prometheus #1 - 아키텍쳐와 개념

Prometheus #1 - 아키텍쳐와 개념 Dec 25, 2018 What is Prometheus? 메트릭 정보를 수집하여 시스템을 모니터링하고 Alerting을 지원하는 오픈소스 Architecture Concept Data Model Metric name 측정되는 시스템의 기능 ex)

badcandy.github.io

5 ways to review code without wasting everyone’s time

성게군. — Fri, 9 Jun 2023 13:05:29 +0900

https://medium.com/volvo-cars-engineering/5-ways-to-review-code-without-wasting-everyones-time-aedeecc51094

5 ways to review code without wasting everyone’s time

The what and how to review pull requests

medium.com

요약

다음은 다음에 코드를 검토할 때 기억했으면 하는 핵심 사항의 목록입니다:

다음은 다음에 코드를 검토할 때 기억했으면 하는 핵심 사항의 목록입니다:
합의 사항을 확인합니다(예: 단위 테스트가 있는가? 문서가 있는가?).
다른 시각을 제공하세요(예: 오타 확인, 혼동되는 부분 식별).
이해가 안 되는 부분이 있으면 질문하고 변경하고 싶은 부분이 있으면 피드백을 제공하세요.
풀 리퀘스트가 불분명하거나 검토할 수 없는 경우 거절하세요.
댓글을 작성할 때 무례하게 행동하지 마세요.

Avoiding cache stampede at DoorDash

성게군. — Tue, 30 May 2023 00:33:21 +0900

https://medium.com/@DoorDash/avoiding-cache-stampede-at-doordash-55bbf596d94b

Avoiding cache stampede at DoorDash

By Zohaib Sibte Hassan, Software Engineer at DoorDash

medium.com

DoorDash Cache 전략.

A typical caching setup

The debouncer approach

To solve the problem, we took inspiration from something front-end engineers use frequently. Debouncing is a common practice in the JS world to prevent duplicate events from firing and causing noise in the system. A well-known way to create a debouncing function looks something like this (using lodash or underscore.js):

https://github.com/syesildag/debounce/blob/master/src/main/java/debounce/DebounceExecutor.java

GitHub - syesildag/debounce

Contribute to syesildag/debounce development by creating an account on GitHub.

github.com

import java.util.concurrent.Callable;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.TimeUnit;

import java.lang.Thread;

public class DebounceExecutor
{
   private ScheduledExecutorService executor;
   private ScheduledFuture<Object> future;
   
   public DebounceExecutor()
   {
      this.executor = Executors.newSingleThreadScheduledExecutor(new ThreadFactory()
      {
         @Override
         public Thread newThread(Runnable r)
         {
            Thread t = new Thread(r, "Debouncer");
            t.setDaemon(true);
            return t;
         }
      });
   }
   
   public ScheduledFuture<Object> debounce(long delay, Callable<Object> task)
   {
      if (this.future != null && !this.future.isDone())
         this.future.cancel(false);
      
      return this.future = this.executor.schedule(task, delay, TimeUnit.MILLISECONDS);
   }
}

System Design — Scaling from Zero to Millions Of Users

성게군. — Tue, 30 May 2023 00:27:36 +0900

https://medium.com/geekculture/system-design-scaling-from-zero-to-millions-of-users-deca270ef784

System Design — Scaling from Zero to Millions Of Users

Note: I have read this great book System Design Interview — An insider’s guide by Alex Xu in depth. So most of my definitions and images…

medium.com

시스템설계/증설/변경 시, 필수참고

Load Balancer

A load balancer evenly distributes incoming traffic among web servers that are defined in a load-balanced set. The user connects to the public IP of the load balancer which further connects with the private IP of our defined servers.

Image source System Design Interview — An insider’s guide by Alex Xu

To handle it we can follow the Data Replication strategy.

Wikipedia: “Database replication can be used in many database management systems, usually with a master/slave relationship between the original (master) and the copies (slaves)”.

A master database generally only supports write operations. A slave database gets copies of the data from the master database and only supports read operations.

Most applications require a much higher ratio of reads to writes; thus, the number of slave databases in a system is usually larger than the number of master databases.

Image source System Design Interview — An insider’s guide by Alex Xu

After all the above discussions, our system design:

Image source System Design Interview — An insider’s guide by Alex Xu

Now, we have a basic understanding of the web and data tiers, it is time to improve the load/response time.

Caching

A cache is a temporary storage area that stores the result of expensive responses or frequently accessed data in memory so that subsequent requests are served more quickly. The application performance is greatly affected by calling the database repeatedly. The cache can help in solving this problem.

Once we get the request, the web server checks if the data is present in the cache. If it is present (also called cache-hit), then our cache access it and directly sends the data to the client. If data is not present in our cache (also called cache-miss), it queries the database then stores the response in the cache and sends data back to the client.

Image source System Design Interview — An insider’s guide by Alex Xu

CDN

A CDN is a network of geographically dispersed servers used to deliver static content. CDN servers cache static content like images, videos, CSS, JavaScript files, etc.

Note: There is also a concept of dynamic content caching which enables the caching of HTML pages that are based on request path, query strings, cookies, and request headers.

Workflow of CDN:

Image source System Design Interview — An insider’s guide by Alex Xu

Now let’s add cache and CDN to our existing system design:

Image source System Design Interview — An insider’s guide by Alex Xu

Database Scaling

Database Scaling can also be done in 2 ways: Vertical and Horizontal scaling

Vertical scaling, also known as scaling up, is the scaling by adding more power (CPU, RAM, DISK, etc.) to an existing machine. We can generally get highly powerful database servers say around 24 TB of RAM, these kinds of servers can store and handle lots and lots of data.

But it comes with few limitations: Restricted user base, higher risk of SPOF, and vertical scaling becomes highly expensive as you go higher to such powerful database servers.

Horizontal scaling, also known as sharding is the practice of adding more servers

Image source System Design Interview — An insider’s guide by Alex Xu

User data is allocated to a database server based on a particular sharding key. Anytime you access data, a hash function is used to find the corresponding shard.

In our example, user_id % 4 is used as the hash function. If the result equals 0, shard 0 is used to store and fetch data. If the result equals 1, shard 1 is used and so on…

Image source System Design Interview — An insider’s guide by Alex Xu

Sharding is a good enough strategy but it has quite a few limitations:

Resharding data: Resharding data is needed when 1) a single shard could no longer hold more data due to rapid growth. 2) Certain shards might experience shard exhaustion faster than others due to uneven data distribution. When shard exhaustion happens, it requires updating the sharding function and moving data around. Consistent Hashing is used to resolve this, which needs an article on its own.
To read about this, kindly check out this amazing article — A Guide To Consistent Hashing
Celebrity problem: Excessive access to a specific shard could cause server overload. Imagine data for Messi, CR7, and Neymar all end up on the same shard. For social applications, that shard will be overwhelmed with read operations. To solve this problem, we may need to allocate a shard for each celebrity. Each shard might even require further partition.

Logging, metrics, automation

Monitoring error logs is important because it helps to identify errors and problems in the system as our system and daily active users (DAU) grow.

Metrics: Collecting different types of metrics help us to gain business insights and understand the health status of the system.

When a system gets big and complex, we need to build or leverage automation tools to improve productivity. Each code check-in can be passed through some default checks and verified through automation, allowing teams to detect problems early. Besides, automating your build, test, deploy process, etc. could improve developer productivity significantly.

With all these things in place our final system design:

Image source System Design Interview — An insider’s guide by Alex

Publishing to Kafka — Synchronous vs Asynchronous

성게군. — Tue, 30 May 2023 00:19:03 +0900

https://medium.com/naukri-engineering/publishing-to-kafka-synchronous-vs-asynchronous-bf49c4e1af25

Publishing to Kafka — Synchronous vs Asynchronous

Kafka is widely used for the asynchronous processing of events/messages.

medium.com

비교수치를 찾기 힘들었는데. 잘 나온 차트!

Impact:

The average response time of API endpoints was reduced to 3 milliseconds from 100 milliseconds.

Netflix Timestone

성게군. — Tue, 30 May 2023 00:16:46 +0900

https://netflixtechblog.com/timestone-netflixs-high-throughput-low-latency-priority-queueing-system-with-built-in-support-1abf249ba95f

Timestone: Netflix’s High-Throughput, Low-Latency Priority Queueing System with Built-in Support…

by Kostas Christidis

netflixtechblog.com

System Architecture

Timestone is a gRPC-based service. We use protocol buffers to define the interface of our service and the structure of our request and response messages. The system diagram for the application is shown in Figure 2.

Figure 2. Timestone system diagram. Arrows link all the components touched during a typical Timestone client-server interaction. Numbers in red indicate sequence steps. Identical numbers identify concurrent steps.

System Design — Design A Rate Limiter

성게군. — Fri, 19 May 2023 18:21:36 +0900

https://medium.com/geekculture/system-design-design-a-rate-limiter-81d200c9d392

System Design — Design A Rate Limiter

Note: I have read this great book System Design Interview — An insider’s guide by Alex Xu in depth. So most of my definitions and images…

medium.com

Token Bucket Algorithm

5 Important Microservices Design Patterns

성게군. — Fri, 19 May 2023 18:19:12 +0900

https://medium.com/javarevisited/5-important-microservices-design-patterns-c4d636b0051

5 Important Microservices Design Patterns

Microservices design patterns have become increasingly popular due to their ability to improve software agility, scalability, resilience…

medium.com

Event Sourcing, Saga Pattern

위 두가지 패턴들을 구현하는 것은 참 고달픈 일이었다,,

API Design Practice

성게군. — Mon, 15 May 2023 14:52:34 +0900

https://medium.com/api-center/api-design-practice-7fce69e6336c

API Design Practice

A practical guide to API QA and the design of stable, coherent and composable business resource APIs

medium.com

SQL Performance Tuning

성게군. — Mon, 15 May 2023 14:51:16 +0900

1. IN 대신 EXISTS를 사용하여 데이터의 존재를 확인하십시오.
2. SELECT 문에서 *를 사용하지 마십시오. 필요한 열의 이름을 지정하십시오.
3. 적절한 데이터 유형을 선택합니다. 예를 들어 문자열을 저장하려면 텍스트 데이터 유형 대신 varchar를 사용하십시오. 큰 데이터(8000자 이상)를 저장해야 할 때마다 텍스트 데이터 유형을 사용하십시오.
4. 두 데이터 유형 모두 char 및 varchar만큼 이중 메모리를 사용하므로 가능하면 nchar 및 nvarchar를 사용하지 마십시오.
5. 고정 길이 필드에서 NULL을 피하십시오. NULL이 요구되는 경우에는 NULL에 대한 공간을 적게 차지하는 가변 길이(varchar) 필드를 사용하십시오.
6. 절을 피하십시오. 집계 결과를 추가로 필터링하려면 having 절이 필요합니다.
7. 클러스터형 및 비클러스터형 인덱스를 만듭니다.
8. 클러스터형 인덱스에서 사용되는 필드가 비클러스터형 인덱스에서도 사용될 수 있으므로 클러스터형 인덱스를 작게 유지하십시오.
9. 대부분의 선택적 열은 비클러스터형 인덱스의 키에서 가장 왼쪽에 배치해야 합니다.
10. 사용하지 않는 인덱스를 삭제합니다.
11. 문자 대신 정수 값이 있는 열에 인덱스를 만드는 것이 좋습니다. 정수 값은 문자 값보다 적은 오버헤드를 사용합니다.
12. 하위 쿼리 대신 조인을 사용합니다.
13. 조인으로 생성되는 결과 테이블의 크기를 제한하려면 WHERE 식을 사용하십시오.
14. 테이블에 삽입할 때 TABLOCKX를 사용하고 병합할 때 TABLOCK을 사용하십시오.
15. 테이블에서 데이터를 쿼리하는 동안 WITH(NOLOCK)를 사용합니다.
16. SET NOCOUNT ON을 사용하고 TRY-CATCH를 사용하여 교착 상태를 피하십시오.
17. 커서는 성능이 매우 느리므로 커서를 사용하지 마십시오.
18. 임시 테이블 대신 테이블 변수를 사용하십시오. Temp 테이블을 사용하려면 시간이 많이 걸리는 작업인 TempDb 데이터베이스와의 상호 작용이 필요했습니다.
19. 가능하면 UNION 대신 UNION ALL을 사용하십시오.
20. SQL 개체 이름 앞에 스키마 이름을 사용합니다.
21. 자주 사용하는 데이터와 더 복잡한 쿼리에는 저장 프로시저를 사용하십시오.
22. 트랜잭션이 처리 테이블 데이터를 잠그고 교착 상태가 발생할 수 있으므로 트랜잭션을 가능한 작게 유지하십시오.
23. 사용자 정의 저장 프로시저 이름을 접두사 "sp_"로 사용하지 마십시오. SQL 서버는 먼저 마스터 데이터베이스에서 사용자 정의 프로시저를 검색한 다음 현재 세션 데이터베이스에서 검색하기 때문입니다.
24. 상관 관계가 없는 스칼라 하위 쿼리를 사용하지 마십시오. 이 쿼리를 기본 쿼리의 일부가 아닌 별도의 쿼리로 사용하고 출력을 변수에 저장합니다. 이 변수는 기본 쿼리 또는 일괄 처리의 이후 부분에서 참조할 수 있습니다.
25. 다중 문 테이블 값 함수(TVF)를 피하십시오. 다중 문 TVF는 인라인 TVF보다 비용이 많이 듭니다.

https://connect2grp.medium.com/sql-performance-tuning-c200e7a8a556

SQL Performance Tuning

SQL performance tuning is a process of optimizing SQL queries to ensure they execute as fast as possible. There are many factors that…

connect2grp.medium.com

Review of Java Features From 11 to 17

성게군. — Mon, 15 May 2023 14:37:26 +0900

JDK 8에서 벗어나질 못하는 환경들이 많음.

개인적 선호도.

Switch expressions (Java SE 14, JEP-361)

Records (Java SE 16, JEP-395)

https://medium.com/@omernaci/review-of-java-features-from-11-to-17-a7ccbb9af133

Review of Java Features From 11 to 17

Java is a powerful and widely-used programming language that has been evolving over the years to stay relevant and up-to-date with the…

medium.com

Migrating Critical Traffic At Scale with No Downtime

성게군. — Mon, 15 May 2023 14:35:15 +0900

Netflix Tech Blog Post

part 2 update 되면 추가,,

https://netflixtechblog.com/migrating-critical-traffic-at-scale-with-no-downtime-part-1-ba1c7a1c7835

Migrating Critical Traffic At Scale with No Downtime — Part 1

Shyam Gala, Javier Fernandez-Ivern, Anup Rokkam Pratap, Devang Shah

netflixtechblog.com

5 Design Patterns in Java that Solve Major Problems

성게군. — Fri, 5 May 2023 10:45:23 +0900

https://levelup.gitconnected.com/5-design-patterns-in-java-that-solve-major-problems-8e85132cfb48

5 Design Patterns in Java that Solve Major Problems!

In a previous post, I showed you how the OOP world looks like. OOP is a pretty convenient paradigm for identifying requirements while also…

levelup.gitconnected.com

1. Singleton Pattern
2. Observer Pattern
3. Strategy Pattern
4. Decorater Pattern
5. Factory Pattern

Spring Data JPA Optimize

성게군. — Fri, 5 May 2023 10:39:57 +0900

https://medium.com/@eidan.khan659/how-to-optimize-performance-with-spring-data-jpa-c615db786f7

How to Optimize Performance with Spring Data JPA

Spring Data JPA is a powerful tool for working with databases in Java applications. It provides an easy-to-use and flexible interface for…

medium.com

1. Avoid N+1 Selects Problem
2. Use Lazy Loading
3. Use Caching
4. Use Paging and Sorting

덧붙이면.

index 최적화
Join 최적화...

Spring Security Filter Flow

성게군. — Thu, 4 May 2023 03:30:50 +0900

Good!

https://medium.com/@gaganjain9319/spring-security-features-and-secure-rest-api-using-spring-security-in-java-e4c812ed085

Spring security features and secure Rest API using spring security in JAVA

Spring Security is a powerful and widely used security framework for Java applications that provides authentication, authorisation, and…

medium.com

[ssuper 성.게군]

Swagger UI 운영환경 노출 위험에 대한 기술 가이드

1. 개요

2. Swagger UI 운영환경 노출이 왜 위험한가

2.1 API 구조 전체 노출

2.2 “Try It Out” 기능을 통한 실제 운영 데이터 접근

2.3 인증·인가 우회 가능성

2.4 Swagger UI 자체 취약점 악용 가능성

3. 공격 시나리오 예시

4. 운영환경에서의 관리 원칙

4.1 기본 원칙

4.2 예외 허용 기준

5. 결론

Appendix. Swagger UI 운영환경 노출 관련 다이어그램

A-1. Attack Flow

A-2. Attack Surface

성수동 월정기 주차 신청 가이드 (2025년 6월)

성수동 월정기 주차 신청 가이드

1공영주차장 월정기 신청 절차

회원가입 및 본인인증

배정기준 확인

정기권 신청

결제 및 이용시작

신청 방법

배정 기준 확인

정기권 신청

결제 및 이용

환불 및 취소 정책

2민간 주차장 월정기 신청

성수동 민간 주차장 현황

주요 민간 주차장 현황

성수역 인근 자주식 주차장

모두의 주차장 앱 제휴

성수빌딩 주차장

3공영주차장 vs 민간주차장 비교

4민간주차장 월정기 이용 가능 현황

5성공적인 주차장 신청을 위한 팁

알아두면 유용한 팁

️ 공영주차장 신청 전략

민간주차장 이용 전략

문의 및 신청 연락처

️ 성동구 도시관리공단

주차 앱 관련 연락처

국내 주요 증권사 앱(MTS) 비교 정리 (2025년 6월 기준)

국내 주요 증권사 MTS 비교

수수료 핵심 정리

키움증권 영웅문S#

삼성증권 mPOP

미래에셋증권 m.Stock

NH투자증권 나무

토스증권

메리츠증권 mCLASS

투자 스타일별 맞춤 추천

최저 수수료 중심

전문가급 기능

초보자 & UX 우선

해외투자 & AI

미국주식 중심

간편투자

증권사 홈페이지 바로가기

Software Algorithm 10

1. DFS (깊이 우선 탐색, Depth-First Search)

2. BFS (너비 우선 탐색, Breadth-First Search)

3. 이진 탐색 (Binary Search)

4. 다익스트라 알고리즘 (Dijkstra's Algorithm)

5. 동적 계획법 (Dynamic Programming, DP)

6. 최소 신장 트리 (Minimum Spanning Tree, MST)

7. 투 포인터 (Two Pointer)

8. 슬라이딩 윈도우 (Sliding Window)

9. 유니온 파인드 (Union-Find)

10. 백트래킹 (Backtracking)

Why you should never default to Microservices

Complexity in Testing

Complicating your infrastructure

Managing split timelines

Are Microservices a terrible idea?

Conclusion

System Design — Tips

1. 요구 사항 이해하기

2. 적절한 아키텍처 선택하기