Just do debug

서킷브레이커 정리 및 resilience4j 적용기

큐범 — Tue, 6 Aug 2024 15:07:00 +0900

resilience4j

MSA 환경에서 서킷브레이커, 유량제어는 매우 중요한 개념으로 보다 더 안전한 서비스 운영을 위해 사용되는 개념이다.

서비스가 확장되면서 같은 팀 내에서 분리된 서비스가 한 쪽으로 의존(트래픽)을 하면서 A의 서버가 B의 API를 비동기로 호출하면서 데이터를 가져오는 상황이 발생한다.

A의 서버를 개발하는 나는 몇 가지 상황을 대비해야한다.

B의 서버가 죽어있다면?
B의 서버가 CPU 자원 부족으로 죽기 직전이라면?
B의 서버가 순간적인 에러를 뱉는다면?

여기서 A서버는 B의 서버가 회복할 수 있도록 기다려줌과 동시에 장애가 전파되지 않도록 막아야한다. 여기서 내가 가져올 수 있는 것은 서킷브레이커이다.

서킷브레이커란?

서킷브레이커

집에서 사용하는 두꺼비집이라 불리는 누전차단기, 회로차단기가 서킷브레이커이다.

개발자들 세계에서 사용하는 서킷브레이커는 각각의 시스템간 장애가 전파되지 않도록 차단을 목적으로 두는 것을 말한다. 서킷브레이커는 상태에 따라서 서로 다른 동작을 한다.

서킷브레이커의 상태

서킷브레이커 상태

서킷브레이커의 상태는 보통상태와 특별한 생태가 있다.

보통상태에서 3개로 분류가 된다.

CLOSED: 정상적으로 호출되고 응답을 주는 상태로 실패율이나 느린 호출 비율이 임계값을 넘지 않은 경우이다.
OPEN: 문제 발생이 감지된 상태, 일정 기간동안 너무 많은 요청이 실패했거나 너무 느리게 응답하는 경우 서킷 브레이커가 열려 더이상 요청을 막은 상태이다.
HALF_OPEN: 문제 발생이 감지된 상태, 서킷 브레이커가 일정 시간이 지난 후 다시 닫힐지 열릴지 결정하기 위해 일부 요청을 허용 하는 상태

특별한 상태는 2개로 분류된다.

DISABLED: 항상 호출을 허용하는 상태
FORCE_OPEN: 항상 호출을 거부하는 상태

서킷 브레이커는 슬라이딩 윈도우(Sliding Window)를 사용하여 상태의 변화여부를 결정한다. 슬라이딩 윈도우는 횟수 방식(COUNT-BASED)과 시간 방식(TIME_BASED)가 있는데 방식에 따라 슬라이딩 윈도우 안에서 정해진 확률보다 높은 확률로 호출에 실패하게 되면 상태를 OPEN으로 변경한다.

OPEN 상태에서는 연동된 시스템 호출을 시도하지 않으며, 바로 호출 실패 Exception이 발생하여 정해진 Fallback동작을 수행한다.

OPEN 이후 설정한 시간이 지나면 HALF_OPEN 상태로 변경되며 호출이 정상화되었는지 다시한번 실패 확률로 확인한다. 정상화되었다고 판되면 CLOSED 상태로 변경되지만 아직 정상화되지 못했다고 판단되면 다시 OPEN 상태로 되돌아간다.

서킷브레이커 라이브러리

서킷 브레이커를 처리할 수 있게 도와주는 라이브러리는 대표적으로 4개가 있다.

Resilience4J
Spring Cloud Circuit Breaker
Hystrix
Sentinel

이 중 최근에도 커밋이 찍혀있으며 활발하게 오픈소스로 개발이 이루어지는 것은 Resilience4J이다. 따라서, Resilience4J를 선택하였다.

https://github.com/resilience4j/resilience4j

Resilience4J란?

Resilience는 회복 탄력성이다. 4는 For J는 Java

Resilience For Java 즉, 회복 탄력성을 자바를 위해 만들어진 라이브러리이다. 우리는 여기서 회복 탄력성에 집중해야한다. 시스템은 나날이 복잡해져 가면서 고객들에게 고가용성을 유지해야하고 장애는 전파가 되지 않도록 해야한다. 그렇다면 의존성이 있는 시스템끼리는 서로 장애가 일어나지 않도록 연산작업(트래픽)에 대해서 보낼지 말지를 결정하여 트래픽을 받는 시스템에서 자원이 부족한 상황에서 다운이 되는 상황이 발생하지 않도록 막아야한다. 여기서 다시 회복을 할 수 있도록 하는 것이 회복탄력성이다.

Resilience4J 적용하기

Getting Started를 확인하여 적용하기 (Java 17 이상을 요구한다.)

https://resilience4j.readme.io/docs/getting-started

    //Resilience4J
    implementation("io.github.resilience4j:resilience4j-spring-boot3:2.2.0")

config는 boot의 application.yml 혹은 application.properties를 통해 스프링 빈에 설정 값을 주입할 수 있다.

resilience4j:
  circuitbreaker:
    configs:
      default:
        registerHealthIndicator: true
        slidingWindowType: COUNT_BASED
        slidingWindowSize: 10
        minimumNumberOfCalls: 5
        slowCallRateThreshold: 100
        slowCallDurationThreshold: 60000
        failureRateThreshold: 60
        permittedNumberOfCallsInHalfOpenState: 3
        waitDurationInOpenState: 60s
        automatic-transition-from-open-to-half-open-enabled: true
    instances:
      circuit-sample-common: # circuitbreaker name
        baseConfig: default # 기본 config 지정
      circuit-sample-3000:
        baseConfig: default
        slowCallDurationThreshold: 3000 # 응답시간이 느린것으로 판단할 기준 시간 [ms]

SlidingWindowType

SlidingWindowType에 COUNT_BASED, TIME_BASED가 있다. 공식문서에 의하면 둘의 시간 복잡도는 O(1)이고 공간 복잡도는 O(WindowSize)이다.

COUNT_BASED: 마지막 슬라이딩 WindowSize 호출이 기록되고 집계된다.

TIME_BASED: 마지막 슬라이딩 WindowSize 초의 호출이 기록되고 집계된다.

slidingWindowSize

서킷의 상태가 CLOSED일 때 요청의 결과를 기록하기 위한 슬라이딩 윈도우의 크기

minimumNumberOfCalls

서킷이 실패율 또는 지연된 응답을 계산하기 전 요구되는 최소 요청의 수, 예시에서는 최소 5개의 요청이 있어야 서킷이 계산을 한다.

slowCallRateThreshold

지연된 응답 Threadhold 퍼센트 값으로 느린 호출의 백분율이 임계값과 같거나 크면 CircuitBreaker가 개방으로 전환되고 단락 호출이 시작된다.

slowCallDurationThreshold

요청이 느린 것으로 간주되는 기간

failureRateThreshold

실패율 Threadhold 퍼센트 값으로 실패율 임계값보다 크거나 같으면 CircuitReaker가 개방으로 전환하고 단락 호출을 시작한다.

permittedNumberOfCallsInHalfOpenState

서킷이 HALF_OPEN상태일 때 허용되는 호출수를 의미한다.

waitDurationInOpenState

서킷의 상태가 OPEN에서 HALF_OPEN으로 변경되기 전에 Circuit Break가 기다리는 시간이다. 예시에서는 20초 이후에 변경된다.

automatic-transition-from-open-to-half-open-enabled

true/false로 Wait Duration In Open State기간이 지난 이후에 Open에서 Half-Open으로 자동으로 상태가 변경된다. 하나의 쓰레드가 CircuitBreaker의 모든 인스턴스들을 모니터링하며 상태를 확인한다.

Resilience4J 상황 시연

@Slf4j
@Service
public class AService {

    @CircuitBreaker(name = "circuit-sample-common", fallbackMethod = "fallback2")
    public String callOutService() {
        throw new RuntimeException("에러발생!");
    }

    private String fallback2(CallNotPermittedException e) {
        log.error("Circuit breaker is open {}", e.getMessage());
        return "fallback";
    }

}

OUTPUT

2024-08-02T13:56:42.277+09:00 ERROR 84435 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.RuntimeException: 에러발생!] with root cause
java.lang.RuntimeException: 에러발생!
2024-08-02T13:56:43.324+09:00 ERROR 84435 --- [nio-8080-exec-2] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.RuntimeException: 에러발생!] with root cause
java.lang.RuntimeException: 에러발생!
2024-08-02T13:56:44.361+09:00 ERROR 84435 --- [nio-8080-exec-3] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.RuntimeException: 에러발생!] with root cause
java.lang.RuntimeException: 에러발생!
2024-08-02T13:56:45.406+09:00 ERROR 84435 --- [nio-8080-exec-4] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.RuntimeException: 에러발생!] with root cause
java.lang.RuntimeException: 에러발생!
2024-08-02T13:56:46.455+09:00 ERROR 84435 --- [nio-8080-exec-5] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.RuntimeException: 에러발생!] with root cause
java.lang.RuntimeException: 에러발생!

2024-08-02T13:56:47.493+09:00 ERROR 84435 --- [nio-8080-exec-6] com.example.resilience.a.AService        : Circuit breaker is open CircuitBreaker 'circuit-sample-common' is OPEN and does not permit further calls

설정해둔 임계치인 5회를 넘기자 그대로 fallbackMethod를 실행하고 있다.

현재 설정에서는 최소 5개의 호출이 발생하고 그 중 3개(60%)가 실패할 경우 서킷이 OPEN 상태로 변경된다. 서킷이 열리면 설정된 시간(60초) 동안 새로운 호출을 차단한다. 이후 서킷은 Half-Open 상태로 전환되고 일부 호출을 허용하여 시스템의 상태를 확인한다.

주의 Catch한 에러는 CircuitBreaker에 포함되지 않는다.

CircuitBreaker를 적용한 분들은 짐작을 하였겠지만, CircuitBreaker의 내부는 AOP를 통해 구현되어 있습니다. 따라서, 해당 메서드에서 발생하는 catch가 이루어질 경우, CircuitBreaker는 포함되지 않습니다.

    @CircuitBreaker(name = "circuit-sample-common", fallbackMethod = "fallback2")
    public String callOutService() {
        try {
            throw new RuntimeException("에러발생!");
        }catch (Exception e) {
            log.error("에러발생: {}", e.getMessage());
            return "catch error";
        }
    }

모니터링

https://resilience4j.readme.io/docs/micrometer 매트릭 정보는 해당 사이트에서 확인 가능하다. (본 글은 Spring Actuator를 통해 확인)

https://resilience4j.readme.io/docs/grafana-1 해당 사이트가서 확인을 한다.

grafana JSON 파일 링크 https://resilience4j.readme.io/docs/grafana-1

서킷브레이커가 작동하는 일이 없도록....

Reference.

CircuitBreaker

Getting started with resilience4j-circuitbreaker

resilience4j.readme.io

[Java] 릴리즈 버전별 특징

큐범 — Tue, 30 Jul 2024 15:54:33 +0900

Java 8 LTS (2014.03)

지원 기간 : 2030.12

람다 표현식 (Lambda Expressions)
스트림 API (Streams API)
새로운 날짜와 시간 API (java.time)
- Ex) LocalDateTime
인터페이스의 디폴트 메서드 (Default Methods)
메타공간 (Metaspace) 메모리 관리
- Permanent Heap 영역이 제거 - Perm은 JVM에 의해 크기가 강제되던 영역
- Metaspace영역은 OS레벨에서 관리하는 영역이 되기에 Metaspace가 Native메모리를 이용함으로서 개발자는 영역 확보의 상한에 대한 오버헤드가 감소한다.

Java 9 (2017.09)

모듈 시스템 (Project Jigsaw)
- Jigsaw는 모듈을 만들고 모듈에 명시적으로 외부에서 호출할 수 있는 API를 선언한다. 언어 레벨에서 API 작성자가 외부에 노출한 API 외에는 접근할 수 없도록 설계 되어 있고 사용할 다른 모듈을 사용하는 경우는 선언적으로 사용한다.
JShell (REPL)
HTTP/2 클라이언트 API

Java 10 (2018.03)

지역 변수 타입 추론 (var)
가비지 컬렉터 개선
병렬 풀 GC

Java 11 LTS (2018.09)

지원 기간 2026.09

새로운 String 메서드(lines, strip, repeat 등)
HTTP 클라이언트 API 표준화 (HttpClient)
Lambda 파라미터의 지역변수 문법
JavaFX 분리

Java 12 (2019.03)

Switch Expressions (프리뷰)
G1 가비지 컬렉터 개선
JVM Constants API

Java 13 (2019.09)

Switch Expressions (프리뷰 개선)
텍스트 블록 (Text Blocks) (프리뷰)

Java 14 (2020.03)

Switch Expressions 표준화
텍스트 블록 (Text Blocks) (프리뷰 개선)
레코드 (Records) (프리뷰)
패턴 매칭 (Pattern Matching) for instanceof (프리뷰)

Java 15 (2020.09)

텍스트 블록 (Text Blocks) 표준화
숨겨진 클래스 (Hidden Classes)
ZGC 개선
Records (프리뷰 개선)
패턴 매칭 for instanceof (프리뷰 개선)

Java 16 (2021.03)

레코드 (Records) 표준화
패턴 매칭 for instanceof 표준화
Vector API (Incubator)

Java 17 LTS (2021.09)

지원 기간 2029.09

장기 지원 (LTS) 버전.
패턴 매칭 for switch (프리뷰).
String result = switch (obj) { case Integer i -> "Integer: " + i; case Long l -> "Long: " + l; case Double d -> "Double: " + d; case String s -> "String: " + s; default -> "Unknown type"; };
Sealed Classes.
// Animal.java public sealed class Animal permits Dog, Cat { // Animal class implementation } // Dog.java public final class Dog extends Animal { // Dog class implementation } // Cat.java public final class Cat extends Animal { // Cat class implementation }
Foreign Function & Memory API (Incubator).
System.loadLibrary("example"); // Load the native library
난수 생성 API 추가
// 기본 랜덤 생성기 사용 RandomGenerator random = RandomGenerator.of("Random"); System.out.println("Random: " + random.nextInt()); // L64X128MixRandom 생성기 사용 RandomGenerator l64x128MixRandom = RandomGenerator.of("L64X128MixRandom"); System.out.println("L64X128MixRandom: " + l64x128MixRandom.nextInt()); // Xoshiro256PlusPlus 생성기 사용 RandomGenerator xoshiro256PlusPlus = RandomGenerator.of("Xoshiro256PlusPlus"); System.out.println("Xoshiro256PlusPlus: " + xoshiro256PlusPlus.nextInt());

Java 18 (2022.03)

UTF-8 기본 인코딩
Simple Web Server
Code Snippets in Java API Documentation

Java 19 (2022.09)

Project Loom (Virtual Threads) (프리뷰)
Foreign Function & Memory API 개선
Vector API 개선

Java 20 (2023.03)

Scoped Values (Incubator)
Improved Pattern Matching
Further Virtual Threads improvements

Java 21 (2023.09)

Project Panama (Foreign Function & Memory API)
Enhanced Pattern Matching for switch (표준화)
Improved Virtual Threads (Hit)
Structured Concurrency (Incubator)

[JAVA] Arrays.sort() Collection.sort() 정렬 알고리즘

큐범 — Mon, 17 Jun 2024 11:00:23 +0900

Java에서 정렬에 대해서 크게 Arrays.sort()와 Collection.sort()가 존재하는데 이 두 메서드는 내부 구현에 차이가 있어 정리를 하고자 한다.

Arrays.sort()

배열을 정리하는데 사용된다. 원시 타입 배열(int[], char[], etc.)와 객체 배열(String[], Integer[], etc.) 모두 정렬할 수 있다.

정렬 방식

원시 타입 배열의 경우, Dual-Pivot Quicksort

객체 배열의 경우, TimSort

Collection.sort()

List를 정렬하는데 사용되어 List 인터페이스를 구현한 모든 컬렉션(ArrayList, LinkedList 등)을 정렬할 수 있다.

정렬방식

TimSort 방식으로 정렬을 하는데 TimSort를 정렬에 Arrays.sort()의 메서드를 사용한다.

Arrays.sort는 왜 DualPivotQuickSort를 채택했을까?

성능
- Quick sort의 경우 pivot 주변에서 데이터의 위치 이동이 빈번하게 발생하기에 참조 지역성이 좋으며 메모리를 추가로 사용하지 않는다.
- 비교 연산 감소 - Dual Pivot Quicksort는 두 개의 피벗을 사용하여 배열을 세 부분으로 나누어 이로인해 평균적으로 비교 연산의 수가 줄어들어 single pivot Quicksort보다 더 빠르게 동작할 수 있습니다.
Tim Sort와의 비교
- 배열에서는 리스트보다 더 빠르게 요소에 접근 할 수 있기 때문에 timsort 보다는 dual pivot quicksort가 더 적합하다.

Tim Sort

이 정렬 알고리즘은 Insertion sort와 Merge Sort를 결합하여 만들어졌으며, 안정적인 두 정렬 방법을 결합했기에 안정적이며, 추가 메모리는 사용하지만 기존의 Merge sort에 비해 적은 추가 메모리를 사용하여 다른 정렬 알고리즘의 단점을 최대한 극복한 알고리즘이다.

동작원리

데이터를 최소 크기의 run(부분적으로 정렬된 데이터의 연속된 구간)으로 분할:
- 입력 배열을 여러 개의 run으로 나눕니다. MIN_RUN이라는 값이 있으며, 이는 보통 32에서 64 사이입니다.
- 하지만 run의 크기는 고정되지 않으며, 이미 정렬된 부분을 최대한 활용합니다. 예를 들어, 배열의 일부가 이미 정렬되어 있으면, 그 부분 전체를 하나의 run으로 취급합니다.
각 run을 삽입 정렬(Insertion Sort)로 정렬:
- 작은 run들은 삽입 정렬을 사용하여 정렬합니다. 삽입 정렬은 작은 배열에서 매우 효율적으로 동작합니다.
정렬된 run들을 병합:
- 정렬된 run들을 병합하여 더 큰 정렬된 run을 만듭니다. 이 과정은 병합 정렬(Merge Sort)을 사용합니다.
- 병합 과정에서 galloping mode라는 최적화 기법을 사용하여 두 run이 많이 정렬되어 있을 때 병합을 가속화합니다.
반복적인 병합:
- 병합된 run들을 다시 병합하여 최종적으로 하나의 정렬된 배열을 만듭니다.
- 병합 규칙에 따라 stack-like 구조를 사용하여 병합 순서를 관리합니다. 예를 들어, 특정 크기 조건을 만족하지 않으면 병합을 지연시키거나 조정합니다.

Collection.sort는 왜 Tim Sort를 채택했는가?

하이브리드 알고리즘
- Tim Sort는 삽입 정렬(Insertion Sort)과 병합 정렬(Merge Sort)의 하이브리드 알고리즘으로 삽입 정렬은 작은 데이터 세트에 대해 매우 빠르게 동작하고 병합 정렬은 큰 데이터 세트에 대해 안정적이고 효융적으로 동작한다.
최악의 경우에 대한 고려
- Tim Sort는 최악의 경우에도 O(n log n)의 시간 복잡도를 보장하여 정렬 알고리즘에서 매우 중요한 요소로 최악의 경우에도 예측 가능한 성능을 제공한다.
안정 정렬
- TimSort는 안정 정렬 알고리즘으로 동일한 값의 요소들이 정렬 후에도 원래의 상대적인 순서를 유지한다.

결론, 그래서 뭐를 써야하나?

늘 개발하면서 겪는 문제지만 이것은 결국 Trade Off 관계이다. 안전성을 중요시 할 경우, Tim Sort를 속도를 우선시 할 경우, Quick Sort를 사용하면 된다.

Reference.

https://d2.naver.com/helloworld/0315536

https://www.baeldung.com/cs/quicksort-vs-timsort

https://velog.io/@disdos0928/어떤-정렬-알고리즘을-사용할까

[DB] Mysql 옵티마이저 힌트

큐범 — Tue, 23 Apr 2024 08:54:08 +0900

옵티마이저

MySQL 옵티마이저는 SQL 쿼리를 가장 효율적인 방법으로 실행하기 위해 쿼리를 분석하고 실행 계획을 선택하는 구성 요소입니다. 데이터베이스 내부에서 쿼리를 처리할 때 여러 가지 실행 경로가 가능할 수 있는데, 옵티마이저의 역할은 가능한 실행 경로 중에서 비용(리소스 사용, 시간 등)이 가장 낮은 경로를 찾아 선택하는 것입니다.

MySQL 옵티마이저의 주요 기능

쿼리 분석: 옵티마이저는 제공된 SQL 쿼리를 분석하여 구문적, 의미적 오류가 없는지 확인합니다. 이 단계에서 쿼리가 유효하고 실행 가능한지 검토합니다.
쿼리 최적화: 옵티마이저는 다양한 최적화 기법을 사용하여 쿼리를 개선합니다. 예를 들어, 필요없는 조건을 제거하거나, 조인 순서를 변경하거나, 인덱스를 활용하는 방법 등을 적용할 수 있습니다.
실행 계획 생성: 옵티마이저는 가능한 여러 실행 계획을 고려하여 각각의 비용을 추정합니다. 이 추정은 통계 정보를 바탕으로 하는데, 이 정보는 테이블의 행 수, 열의 분포, 인덱스의 특성 등을 포함할 수 있습니다.
실행 계획 선택: 모든 가능한 실행 계획의 비용을 추정한 후, 옵티마이저는 가장 비용이 낮은 실행 계획을 선택합니다. 이 계획이 실제 쿼리 실행 시 사용됩니다.
통계 관리: 옵티마이저의 성능은 사용 가능한 통계 정보의 정확성에 크게 의존합니다. MySQL은 통계 정보를 자동으로 갱신하거나 사용자가 수동으로 갱신할 수 있게 관리 도구를 제공합니다.
MySQL 옵티마이저는 이러한 과정을 통해 쿼리의 성능을 향상시키고, 시스템 리소스를 효율적으로 사용하도록 돕습니다. 특히 대규모 데이터를 처리하거나 복잡한 쿼리를 실행할 때, 옵티마이저의 역할은 매우 중요합니다.

옵티마이저 힌트

MySQL에서 옵티마이저 힌트는 개발자가 SQL 쿼리의 실행 계획에 직접 개입할 수 있도록 해주는 도구이다. MySQL 8.0 버전에서 사용 가능한 힌트는 종류가 매우 다양하며, 옵티마이저 힌트가 미치는 영향 범위도 매우 다양하다.

옵티마이저 힌트 종류

인덱스: 특정 인덱스의 이름을 사용할 수 잇는 옵티마이저 힌트
테이블: 특정 테이블의 이름을 사용할 수 있는 옵티마이저 힌트
쿼리 블록: 특정 쿼리 블록에 사용할 수 있는 옵티마이저 힌트, 힌트가 명시된 쿼리 블록에 대해서 영향을 미치는 힌트이다.
글로벌(쿼리 전체): 전체 쿼리 블록 대해서 영향을 미치는 힌트

[DB] 풀 테이블 스캔과 인덱스 스캔

큐범 — Tue, 9 Apr 2024 09:02:14 +0900

mysql 옵티마이저는 다음과 같은 조건이 일치할때 주로 풀 테이블 스캔

테이블의 레코드 건수가 너무 작아서 인덱스를 통해 읽는 것보다 풀 테이블 스캔을 하는 편이 더 빠른경우
WHERE 절이나 ON 절에 인덱스를 이용할 수 있는 적절한 조건이 없는 경우
인덱스 레인지 스캔을 사용할 수 있는 쿼리라고 하더라도 옵티마이저가 판단한 조건 일치 레코드 건수가 너무 많은 경우
강제 풀 테이블 스캔을 해야하는 경우

스트리밍 처리

mysql 스트리밍 처리

서버 쪽에서 처리할 데이터가 얼마인지에 관계없이 조건에 일치하는 레코드가 검색될 때마다 바로바로 클라이언트로 전송해주는 방식을 의미한다. 이 방식으로 쿼리를 처리할 경우 클라이언트는 쿼리를 요청하고 곧바로 원했던 첫 번째 레코드를 전달 받는다.

특징

쿼리 결과를 한 번에 모두 생성하지 않는 방식이다.
대신 서버는 결과를 한 행씩 또는 작은 묶음 단위로 클라이언트에게 전송한다.
스트리밍 처리는 전체 결과 집합을 메모리에 저장할 필요가 없어 메모리 사용량을 줄일 수 있다.
결과를 점진적으로 받기 때문에, 첫 번째 결과를 빠르게 얻을 수 있고, 전체 데이터를 기다리지 않아도 된다.
대용량 데이터 처리나 실시간 처리가 필요한 어플리케이션에 적합하다.

mysql 버퍼링 처리

Order by나 Group by와 같은 처리는 쿼리의 결과가 스트리밍되는 것을 불가능하게 한다. 우선 where 조건에 일치하는 모든 레코드를 가져온 후, 정렬하거나 그루핑해서 차례대로 보내야 하기 때문이다.

특징

서버가 쿼리의 전체 결과를 먼저 생성하고 이를 메모리에 저장한 후 클라이언트에게 전송하는 방식이다.
결과 집합이 클라이언트로 전송되기 전에 서버 메모리에 저장되므로, 대용량 결과 집합을 처리할 때는 메모리 사용량이 증가할 수 있다.
작은 결과 집합을 빠르게 전체적으로 받을 수 있으므로, 데이터 크기가 작은 어플리케이션에 유리하다.
일반적인 웹 어플리케이션과 같이 결과 집합이 크지 않은 경우에 적합하다.

JDBC는 MySQL 서버는 레코드를 읽자마자 클라이언트로 그 결과를 전달할 것이다. 하지만 JDBC는 MySQL 서버로부터 받는 레코드를 일단 내부 버퍼에 모두 담아둔다. 그리고 마지막 레코드가 전달될 때까지 기다렸다가 모든 결과를 전달받으면 그때서야 비로소 클라이언트의 애플리케이션에 반환한다. 즉, MySQL 서버는 스트리밍 방식으로 처리해서 반환하지만 클라이언트의JDBC 라이브러리가 버퍼링하는 것이다.

Reference.

Real MySQL 8.0 (1권) | 백은빈 - 교보문고

Real MySQL 8.0 (1권) | MySQL 서버를 활용하는 프로젝트에 꼭 필요한 경험과 지식을 담았습니다!《Real MySQL 8.0》은 《Real MySQL》을 정제해서 꼭 필요한 내용으로 압축하고, MySQL 8.0의 GTID와 InnoDB 클러스

product.kyobobook.co.kr

[Spring] @Async vs WebFlux

큐범 — Mon, 25 Mar 2024 14:22:01 +0900

Spring @Async vs Spring WebFlux

글을 작성하게된 계기

실무에서 서버간 통신을 할때 비동기로 호출해야하는 경우가 있었다. 처음에는 @Async를 사용하였는데 좀 더 깊게 파보니 Spring WebFlux도 많이 사용하는 것을 확인하고 WebFlux도 동시에 써보았는데 WebFlux가 더 빠른 것을 보았다.

Spring @Async

설명

@Async 어노테이션은 Spring에서 제공하는 비동기 실행 방법으로 메서드를 별도의 스레드에서 비동기적으로 실행한다.

@Async는 Spring의 AOP 기능을 활용하여 메서드 호출을 비동기적으로 처리한다. 이는 스레드 풀을 사용하여 별도의 스레드에서 실행되며, 비동기 작업의 결과 또는 상태는 Future 객체를 통해 관리할 수 있다. @Async는 간단하고 효율적인 비동기 처리 방법을 제공하여, 리소스를 효율적으로 사용하면서 애플리케이션의 성능을 향상시킬 수 있다.

적용 사례

@Async는 주로 단일 작업에 대한 비동기 처리가 필요할 때 사용됩니다. 예를 들어, 이메일 보내기, 파일 업로드, 복잡한 계산 수행 등의 작업에 적합합니다.

장점

구현이 간단하고, 기존 코드에 쉽게 통합할 수 있다.

단점

복잡한 비동기 작업 흐름이나 백프레셔(backpressure) 관리 등에는 적합하지 않다.

예시 코드

@Configuration
@EnableAsync
public class AsyncConfig {
    // 필요한 경우 여기에 사용자 정의 스레드 풀 설정을 추가할 수 있습니다.
}

public class AsyncService {
    @Async(name = 'test')
    public void asyncTest() {
        try {
            Thread.sleep(1000);
            log.info("Async Test");
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

Spring Webflux

설명

Spring WebFlux는 Spring 5에서 도입된 반응형 프로그래밍을 위한 웹 프레임워크이다. 이는 논블로킹(non-blocking) I/O와 비동기적 실행을 지원하며, 더 효율적인 리소스 사용과 높은 처리량을 제공한다. Mono와 Flux와 같은 리액티브 타입을 사용하여 데이터 스트림을 처리한다.

적용사례

WebFlux는 동시에 많은 요청을 처리해야 하거나, 데이터 스트림을 연속적으로 처리해야 할 때 유용하다. 예를 들어, 실시간 데이터 처리, 대규모 파일 처리, 웹 소켓 통신 등에 적합하다.

장점

높은 동시성 처리 능력, 리소스 효율성, 백프레셔 관리 기능을 제공한다.

단점

비동기와 반응형 프로그래밍 모델은 학습 곡선이 높으며, 복잡할 수 있다.

예시 코드

@Configuration
public class WebClientConfig {

    @Bean
    public WebClient webClient() {
        return WebClient.create("http://example.com/api"); // 여기에 외부 API의 기본 URL을 설정합니다.
    }
}

@Configuration
public class RouterConfig {

    @Bean
    public RouterFunction<ServerResponse> personRouter(PersonHandler handler) {
        return route(GET("/person/{id}"), request -> handler.getPerson(request.pathVariable("id")))
                .andRoute(GET("/persons"), request -> handler.getAllPersons());
    }
}

@Component
public class ApiService {

    public Mono<String> getExternalData() {
        return webClient.get()
                        .uri("/data") // 외부 API의 특정 경로
                        .retrieve()
                        .bodyToMono(String.class); // 응답을 String으로 변환
    }
}

@RestController
public class ApiController {

    private final ApiService apiService;

    @Autowired
    public ApiController(ApiService apiService) {
        this.apiService = apiService;
    }

    @GetMapping("/external-data")
    public Mono<String> fetchExternalData() {
        return apiService.getExternalData(); // 서비스에서 외부 API 호출
    }
}

[JAVA] GC(Garbage Collector) 동작과정, 종류, Java Default GC, Java Command

큐범 — Thu, 29 Feb 2024 11:03:37 +0900

GC(Garbage Collector)

동적으로 할당한 메모리 영역 중 사용하지 않는 영역을 탐지하여 해제하는 기능

GC 종류

SerialGC
- 단일 스레드로 작동한다.
- JVM 옵션: -XX:+UseSerialGC
ParallelGC
- 여러 개의 스레드를 사용하여 Young Genertaion영역에서 가비지 컬렉션을 수행한다.
- JVM 옵션: -XX:+UseParallelGC
Parallel Old GC
- Parallel GC의 구세대 버전으로 Old Generation 영역에서 병렬로 가비지 컬렉션을 수행한다.
- JVM 옵션: XX:+UseParallelOldGC
- JVM 옵션: XX:+UseParallelOldGC
Concurrent Mark Sweep(CMS) GC
- 낮은 중지 시간을 목표로 하는 멀티프로세싱 환경에 적합하다.
- JVM 옵션: -XX:+UseConcMarkSweepGC
G1(Grabage-First) Collector
- 큰 힙을 관리하고 예측 가능한 중지 시간을 제공하는 데 적합하다.
- 힙을 여러 개의 작은 영역으로 나누어 관리한다.
- JVM 옵션: -XX:+UseG1GC
ZGC(Z Garbage Collector)
- Java 11부터 사용 가능한 저지연(law latency) 가비지 컬렉터
- 대규모 힙과 멀티 프로세서 환경에서 중지 시간을 최소화하는 데 초점을 맞춘다.
- JVM 옵션: XX:+UseZGC
Shenandoah
- ZGC와 유사하게 저지연 가비지 컬렉션을 목표로한다.
- 대규모 힙에서도 짧은 중지 시간을 제공한다.
- JVM 옵션: XX:+UseShenandoahGC

stop-the-world

GC를 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 것이다. stop-the-world가 발생하면 GC를 실행하는 쓰레드를 제외한 나머지 쓰레드는 모두 작업을 멈춘다. GC 작업을 완료한 이후에야 중단해 두었던 작업을 다시 시작한다. 모든 GC 알고리즘은 stop-the-world가 발생한다. 대부분의 GC 튜닝은 stop-the-world의 시간을 줄이는 것이다.

GC에서 관리하는 JVM의 영역

힙(Heap): JVM에서 가장 큰 메모리 영역, 힙은 다음과 같은 세부 영역으로 나뉜다.
1. Young Genertaion
  1. 새로 생성된 객체들이 할당되는 영역으로 대부분의 객체가 금방 사용하지 않게 되는 객체를 위한 곳이다. Eden영역과 Survivor 영역이 포함된다.
  2. 해당 영역에서 발생하는 GC를 Minor GC라고 하며 Major GC에 비해 빠르다.
2. Old Generation
  1. Young에서 오래 살아남은 객체들이 이동되는 곳이다. 이 영역은 객체가 더 오래 존재한 곳이다.
  2. 해당 영역에서 발생하는 GC를 Major GC라고 하며 Minor GC에 비해 느리다.
3. Permanent Generation Or Metaspace
  1. 클래스와 메소드에 대한 메타데이터가 저장되는 영역 PS. Java 8부터는 PerGen이 Metaspace로 대체되었다.
스택(Stack): Java 메소드의 호출과 실행에 사용된다.
코드(Code): 프로그램의 바이트코드 즉 컴파일된 클래스와 인터페이스의 코드가 저장되는 영역
네이티브 메소드 스택(Native Method Stack): 자바 외의 언어로 작성된 네이티브 코드를 위한 스택

가비지 컬렉션은 힙 영역을 주 대상으로 관리하며 힙 내의 객체들 중에서 더이상 사용되지 않는 객체들을 식별하고 이를 수집하여 메모리를 해제한다. 다른 영역들은 각각 스레드나 JVM자체에 의해 관리가 되며 가비지 컬렉션의 대상이 아니다.

GC 과정

1. 새로운 객체가 Eden 공간에 할당된다. 두 Survivor 영역은 빈 공간으로 시작한다.

2. Eden 공간이 가득차면 Minor GC가 작동한다.

3. 참조된 객체는 첫번째 Survivor 영역으로 이동하고 참조가 없는 객체는 Eden 영역에서 제거한다.

4. 다음 Minor GC에서는 Eden 공간에서도 동일한(1~3) 작업이 발생합니다. 참조되지 않은 객체는 삭제되고 참조된 객체는 생존 공간으로 이동한다. 다만, 이 경우에는 두 번째 생존 공간(S1)으로 이동하고 첫 번째 생존 공간(S0)의 마지막 마이너 GC의 객체는 수명이 증가하고 S1으로 이동한다. 살아남은 모든 객체가 S1으로 이동하면 S0와 Eden 모두 지워진다. 이제 생존자 공간에는 서로 aged를 가지는 객체가 있는 것을 염두하자.

5. 다음 Minor GC 에서는 동일한 프로세스가 발생한다. 하지만, 이번에는 Survivor 영역이 전환된다. 참조된 객체는 S1(두번째 Survivor 영역)에서 S0(첫번째 Survivor 영역)으로 이동된다. 살아남은 객체들은 aged 된다.

6. 아래의 슬라이드에서는 프로모션을 보여준다. Minor GC 후에 오래된 객체가 특정 연령 임계값(해당 예에서는 8)에 도달하면 Young Genertaion에서 Old Generation로 전환된다.

7. Minor GC가 계속 발생하면 객체는 Young Genertaion에서 Old Generation으로 이동한다.

Java에서 GC 사용 예시

명령어

System.gc();
Runtime.getRuntime().gc();

이 명령어들은 JVM에게 가비지 컬렉션을 실행하도록 요청한다. 하지만, 실제로 가비지 컬렉션이 실행될 시기와 방식은 JVM의 가비지 컬렉터 구현에 달려있다.

JVM 옵션을 통한 가비지 컬렉터 설정

XX:+UseSerialGC: 시리얼 가비지 컬렉터를 사용하도록 설정합니다.
XX:+UseParallelGC: 병렬 가비지 컬렉터를 사용하도록 설정합니다.
XX:+UseParallelOldGC: 구세대 영역에 대해 병렬 가비지 컬렉터를 사용합니다.
XX:+UseConcMarkSweepGC: CMS(Concurrent Mark-Sweep) 가비지 컬렉터를 사용합니다.
XX:+UseG1GC: G1(Garbage-First) 가비지 컬렉터를 사용합니다.

Ex)

java -XX:+UseG1GC -Xms512m -Xmx4g -XX:NewRatio=3 -XX:SurvivorRatio=6 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc-log.txt -jar application.jar

XX:+UseG1GC: G1 가비지 컬렉터를 사용합니다.
Xms512m: JVM의 초기 힙 크기를 512MB로 설정합니다.
Xmx4g: JVM의 최대 힙 크기를 4GB로 설정합니다.
XX:NewRatio=3: 신세대와 구세대의 메모리 비율을 1:3으로 설정합니다.
XX:SurvivorRatio=6: 신세대 내의 에덴 영역과 서바이버 영역의 비율을 1:6으로 설정합니다.
XX:+PrintGCDetails, XX:+PrintGCDateStamps: 가비지 컬렉션의 상세 정보와 타임스탬프를 콘솔에 출력합니다.
Xloggc:gc-log.txt: 가비지 컬렉션 로그를 'gc-log.txt' 파일에 기록합니다.

JVM옵션을 통한 가비지 컬렉션 튜닝

Xms<size>: JVM의 초기 힙 크기를 설정합니다.
Xmx<size>: JVM의 최대 힙 크기를 설정합니다.
Xmn<size>: 신세대 영역의 크기를 설정합니다.
XX:NewRatio=<ratio>: 신세대와 구세대의 비율을 설정합니다.
XX:SurvivorRatio=<ratio>: 에덴 영역과 서바이버 영역의 비율을 설정합니다.
XX:+PrintGCDetails, XX:+PrintGCDateStamps, Xloggc:<file>: GC 로그를 상세하게 출력하거나 파일로 저장합니다.

Ex)

java -Xms512m -Xmx4g -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+ScavengeBeforeFullGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc-log.txt -jar application.jar

java -Xms512m -Xmx4g -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+ScavengeBeforeFullGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc-log.txt -jar application.jar

Xms512m: JVM의 초기 힙 크기를 512MB로 설정합니다.
Xmx4g: JVM의 최대 힙 크기를 4GB로 설정합니다.
XX:+UseConcMarkSweepGC: CMS(Concurrent Mark-Sweep) 가비지 컬렉터를 사용합니다.
XX:+CMSParallelRemarkEnabled: CMS 가비지 컬렉션 중 병렬 리마크 단계를 활성화합니다.
XX:+UseCMSInitiatingOccupancyOnly: 힙 사용량 기반의 CMS 가비지 컬렉션 시작을 활성화합니다.
XX:CMSInitiatingOccupancyFraction=70: 힙의 70%가 사용되었을 때 CMS 가비지 컬렉션을 시작합니다.
XX:+ScavengeBeforeFullGC: 전체 GC 전에 젊은 세대의 가비지 컬렉션을 수행합니다.
XX:+PrintGCDetails, XX:+PrintGCDateStamps: 가비지 컬렉션의 상세 정보와 타임스탬프를 콘솔에 출력합니다.
Xloggc:gc-log.txt: 가비지 컬렉션 로그를 'gc-log.txt' 파일에 기록합니다.

Java 버전별 디폴트 GC 알고리즘

Java 1.3 이하
- Serial GC
Java 1.4 ~ Java 5
- Parallel GC
Java 6 ~ Java 8
- Parallel Old GC
- Java 8u40부터 G1 GC가 도입되었으나, Parallel Old GC가 여전히 디폴트다.
Java 9 ~ Java 10
- G1 GC
Java 11 이후
1. G1 GC
2. Java 11부터 ZGC가 실험적으로 도입되었으나 디폴트는 G1GC이다.
3. Java 15부터 Shenandoah가 실험적으로 추가되었다.

Reference.
https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
https://wiki.openjdk.org/display/zgc/Main#Main-JDK11
https://stackoverflow.com/questions/33206313/default-garbage-collector-for-java-8

레디스 RedLock의 수행방식과 한계

큐범 — Mon, 19 Feb 2024 09:52:51 +0900

레디스 분산락

해당 글에서는 Redis의 분산락에 대한 개념을 설명한다.

글을 쓰게 된 이유

현재 진행하고 있는 프로젝트에서 선착순 이벤트를 진행하는데 현재 소프트웨어 아키텍쳐로는 선착순에 대해서 보장할 방법이 없었다. MySQL에 부담을 주기에는 사이드 이펙트가 크고 DB를 하나의 백엔드만 사용하고 있는 것이 아니고 다른 서버에서도 사용하고 잇기에 만약 DB에 문제가 생길 경우, 이펙트가 큰 상황이라서 DB 부담하는 것은 보기에서 제거를 했다.

앞으로의 기획 로드맵과 현재의 기획 부분에서 Redis가 적합한 선택이 될 것 같아 Redis를 선택하여 도입하였다. 도입과 동시에 선착순 이벤트에 대해서 정상적인 처리가 이루어졌지만 급하게 적용한 탓에 레디스의 분산락에 대한 이해가 부족하여 해당 개념에 대해서 정리를 해보고자 한다.

분산락(Distributed Lock)은 여러 컴퓨터 시스템이 네트워크를 통해 연결된 분산 시스템 환경에서 자원에 대한 동시 접근을 조절하기 위해 사용되는 동기화 메커니즘이다. 이는 여러 노드가 동일한 데이터나 자원에 접근하고자 할 때 발생할 수 있는 충돌을 방지하는 데 필요하다.

Point. 레디스는 싱글 스레드로 동작한다.

[Redis에서 분산락을 제공하는 이유]

단일 레디스 노드는 단일 장애 지점(Single Point Of Failure)이 될 가능성이 있다. 해당 문제를 해결하기 위해서는 Master-Slave 복제(replication) 레디스 서버를 구축하기도 하나, 해당 아키텍쳐는 경쟁상태(race condition)이 발생할 수 있다.

단일 장애 지점(Single Point Of Failure) : 시스템 구성 요소 중에서 동작하지 않으면 전체 시스템이 중단되는 요소

경쟁 상태(Race Condition) : 여러 개의 프로세스가 공유 자원에 동시 접근할 때 실행 순서에 따라 결과값이 달라질 수 있는 현상이다.

경쟁 상태가 발생하는 시나리오

클라이언트 A는 마스터에서 잠금을 획득한다.
키에 대한 쓰기가 복제본으로 전송되기 전에 마스터가 충돌이 발생한다..
복제본이 마스터로 승격됩니다.
클라이언트 B는 A가 이미 잠금을 보유하고 있는 동일한 리소스에 대한 잠금을 획득합니다. SAFETY VIOLATION!

[RedLock]

레디스는 위의 단일 장애 지점과 경쟁 상태를 해결하기 위해 Red Lock 알고리즘을 제안한다. Red Lock은 Redis Lock이라고도 불린다. 레드락은 N개의 단일 레디스 노드들을 이용하여, Quorum 이상의 노드에서 잠금을 획득하면 락을 획득하는 매커니즘이다.

Redlock은 아래의 3가지 특성을 지킨다고 이야기한다.

상호배제 : 오직 한 순간에 하나의 워커 락을 획득한다.
데드락 방지 : 락 이후 어떠한 문제로 인해 락을 풀지 못하고 종료된 경우라도 다른 워커가 락을 획득할 수 있어야한다.
내결함성 : Redis 노드가 작동하는 한 모든 워커는 락을 걸고 해제할 수 있어야한다.

[Red Lock 작업 수행]

현재 시간을 ms단위로 가져온다.
모든 인스턴스에서 동일한 키 이름과 임의의 값을 사용하여 모든 N 인스턴스에서 순차적으로 잠금을 획득하려고 시도한다. 2단계에서 각 인스턴스에 잠금을 설정할 때 클라이언트는 잠금을 획득하기 위해 총 잠금 자동 해제 시간에 비해 작은 제한 시간을 사용한다. 예를들어, 자동 해제 시간이 10초인 경우 제한 시간은 5~50ms 범위 일 수도 있다. 이렇게 하면 클라이언트가 다운된 Redis 노드와 통신하려고 오랫동안 차단되는 것을 방지할 수 있다.
클라이언트는 1단계에서 얻은 타임 스탬프를 현재 시간에서 빼서 잠금을 획득하는 데 경과된 시간을 계산하여 클라이언트가 대부분의 인스턴스(최소 3개)에서 잠금을 획득할 수 있었던 경우에만 해당된다. 잠금을 획득하는데, 소요된 총 시간이 잠금 유효 시간보다 작을 경우 잠금을 획득한 것으로 간주된다.
잠금이 획득된 경우 유효 시간은 3단계에서 계산된 대로 초기 유효 시간에서 경과 시간을 뺀 것으로 간주한다.
클라이언트가 어떠한 이유로 잠금 획득에 실패한 경우(N/2+1 인스턴스를 잠글 수 없거나 유효 시간이 음수인 경우) 모든 인스턴스의 잠금을 해제하려고 시도한다.(그렇지 않다고 생각되는 인스턴스도 포함)

[RedLock의 한계]

Clock Drift

RedLock은 노드간의 동기화된 시계는 없지만, 로컬 시간에 기반하여 작동하기에 현실에서 클럭이 정확한 속도 동작하지 않으면 클럭 드리프트(Clock Drift) 현상으로 인해 알고리즘이 보장이 안될 수 있다.

클라이언트 1이 분산락을 획득한다.
클라이언트 1에서 애플리케이션이 중지가 발생하고, 그 사이에 분산락이 만료된다.
클라이언트 2는 분산락을 획득하고 파일에 접근한다.
클라이언트 1의 애플리케이션이 복구되고 파일을 접근한다.
동시성 문제가 발생한다.

일반적으로 GC 시간이 짧으나, Stop-The-World GC는 잠금이 만료될 수 있을 만큼 충분히 오래 지속될 수 있기에 GC 일시 중지는 때때로 몇 분 동안 지속되는 것으로 알려져 있다. 따라서, 락 점유의 만료 기간을 가지는 것은 선택이 아닌 필수다. 하지만 프로세스를 멈추는 이유는 GC외에도 다양한데 이 중 문제가 될 만한 것은 네트워크 지연 등에 의해서도 RedLock 알고리즘을 보장 못받을 수 있다.

위의 네트워크 문제를 해결하기 위해 모든 펜싱 토큰 또는 버전을 포함하여 아래와 같이 처리할 수 있다.

Network에 기반한 운영

RedLock에는 기본으로 제공하는 펜싱 토큰 기능이 없으므로, 클라이언트에서 네트워크 문제로 인해 경쟁 상태(race condition)가 발생하여 동시성 문제가 발생할 수 있다. 해당 문제를 해결하기 위해 Redis의 단일 노드에 카운터를 관리하며 단일 장애 지점이 되어 해당 레디스가 사이드 이펙트가 매우 커지는 경우가 있을수 있다. 여러 노드에 카운터를 유지하면서 카운터가 동기화되지 않을 수 있다.

따라서, 위의 그림과 같이 펜싱 토큰 또는 버전이 필요할 텐데 이는 레드락에서 기본으로 제공하지 않기에 불안정한 부분이 있다.

Reference.

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

[DB] PK AutoIncrement VS UUID

큐범 — Sat, 19 Aug 2023 23:15:09 +0900

테이블을 설계하는 과정에서 PK에 대한 고민을 많이 갖게 되었다. PK를 부여하는 방식에 여러 방식이 있지만, 대표적인 두가지는 UUID와 AI(Auto Increment)를 대표적으로 사용한다.
나는 현재 AI(Auto Increment)를 사용 중이다. AI를 선택하게 된 이유는 현재 서비스는 하나의 데이터베이스에서 서비스를 운영중이기에 PK생성을 DBMS에 이관하여도 괜찮다고 판단하였다. 하지만, 여러개의 DBMS에서 사용할 경우 한 row의 고유한 값을 보장할 수 없다.

해당 고민을 하면서 AI와 UUID에 대한 어떠한 트레이드 오프가 있는지 정리해보고자 한다.

Auto Increment

데이터베이스에서 사용되는 속성으로, 특정 필드의 값이 자동으로 증가하는 기능이며 해당 기능은 테이블에 새로운 레코드를 추가할 때마다 해당 필드의 값이 자동으로 증가하게 된다. 예를들어, 사용자 정보를 저장하는 테이블에서 각 사용자에게 고유한 ID를 부여하고 싶을 때 'autoincrement' 속성을 사용할 수 있다. 처음 사용자가 추가되면 ID는 1로 설정되며, 다음 사용자가 추가될 때 ID는 자동으로 2가 된다.

Auto Increment를 PK로 설정할 경우 이점

성능 최적화 : 많은 데이터베이스 시스템에서, 연속된 정수 값으로 구성된 기본 키는 인덱싱 및 조회 성능에 이점을 제공할 수 있다. 인덱스의 이점을 가지고 있다.
- MySQL의 기본 엔진인 InnoDB는 B+tree 구조로 이루어져 있는데 해당 구조는 UUID에 비해 Auto Increment가 성능의 이점을 가진다.
- UUID는 16Byte의 길이를 가진 문자열은 대표적인 Int(4Byte) or Long(8Byte)에 비해 속도가 느려 Auto Increment가 성능의 이점을 가진다.
고유성 보장 : 자동으로 값을 증가시켜 중복 없이 고유한 값을 생성하므로, 이를 기본 키로 사용할 경우 중복된 값을 걱정할 필요가 없다.

UUID(Universally Unique Identifier)

네트워크상에서 고유성을 보장하는 ID 표준 규약으로 UUID는 여러 시스템에서 객체나 정보를 고유하게 식별하는 데 사용될 수 있는 고유한 ID를 제공하기 위해 설계되었다.

UUID의 버전별 특징

버전 1: 현재의 타임스탬프와 MAC 주소를 기반으로 생성
버전 2: DCE 보안의 특정 값과, 타임스탬프 및 MAC 주소를 기반으로 생성
버전 3: 이름 기반 UUID로, MD5 해시를 사용
버전 4: 무작위 생성
버전 5: 이름 기반 UUID로, SHA-1 해시를 사용

UUID를 PK로 설정할 경우 이점

전역적 고유성(Global Uniqueness) : UUID는 전 세계적으로 고유한 값을 가지기에 여러 데이터베이스나 시스템 간의 데이터를 병합하거나 이동할 때 기본 키 충돌의 위험이 매우 적다.
중앙 관리 불필요 : UUID는 중앙에서의 관리나 생성 없이도 고유한 값을 생성할 수 있다. 따라서, 분산된 시스템에 유용하며, 클라이언트에서 직접 레코드의 키를 생성할 수 있다.
비 예측 값 : UUID는 무작위 생성으로 Auto Incremet와 달리 이전과 이후 레코드의 고유 값을 알 수 없기에 보안성을 상승시킨다.
데이터베이스 독립적, 복제 및 백업 용이성....
단점: 크기, 성능, 가독성

결론

나는 데이터베이스를 설계할 기회가 있어 한다면, 요구사항에 MSA가 없고 한 테이블에 40억 row가 생길 일이 없다면 Auto Increment로 설정한다. 그 이유는 UUID는 16Byte로 인덱스 성능 저하를 초래하며 가독성이 안좋다는 것은 개발자 입장에서 매우 큰 단점을 가진다.
예를들어 A라는 개발자가 B라는 개발자에게 132번 Row를 확인하라고 하는 것과 550e8400-e29b-41d4-a716-446655440000의 Row를 확인하라는 것은 생각보다 많은 리소스가 소모된다.
그럼 무조건 적으로 PK에는 Auto Increment가 옳은 것인가? 그렇지는 않다. 요구사항에 MSA가 있어 다양한 데이터베이스를 사용하며 UUID를 사용한다면 시스템의 전체 데이터베이스의 각각의 Row의 고유성을 가지기에 서버간 통신에도 많은 안전성을 가져다준다. 또한, 개발 도중에 데이터베이스를 변경해야하는 경우가 있다면 UUID가 Auto Increment에 비해 종속성이 매우 낮다.

해당 케이스도 Trade-Off 관계로 모든 개발은 Trade-Off 관계에서 적절한 관계를 찾아야한다.
상황에 맞게 사용하는 것이 무엇보다 중요하다.

[DB] MySQL 내부 엔진

큐범 — Sat, 5 Aug 2023 13:23:37 +0900

강의를 듣던 중 MySQL 서버의 내부를 소개해주는 내용이 있어 정리하고자 한다.

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템(RDBMS)이다. MySQL은 웹 애플리케이션을 위한 데이터베이스로 특히 많이 사용된다.

MySQL 아키텍처

MySQL 엔진 내부

그러면 MySQL 엔진의 내부는 다음과 같이 쿼리 파서, 전처리기, 옵티마이저, 쿼리실행기를 거쳐서 스토리지 엔진으로 넘어간다.

해당 글에서는 MySQL 엔진 내부에서 어떠한 역할을 하는지 확인하려한다.

쿼리파서

SQL을 파싱하여 Syntax Tree를 만든다.
이 과정에서 문법 오류 검사가 이루어진다.

전처리기

쿼리파서에서 만든 Tree를 바탕으로 전처리 시작한다.
이블이나 컬럼 존재 여부, 접근권한 등 Semantic 오류 검사를 진행한다.

쿼리파서와 전처리기는 컴파일 과정과 매우 유사하지만, SQL은 프로그래밍 언어처럼 컴파일 타임때 검증할 수 없어 매번 구문 평가를 진행한다.

옵티마이저

쿼리를 처리하기 위한 여러 방법들을 만들고, 각 방법들의 비용 정보와 테이블의 통계정보를 이용해 비용을 산정한다.
테이블 순서, 불필요한 조건 제거, 통계정보를 바탕으로 전략을 결정한다. (실행 계획 수립)
옵티마이저가 어떤 전략을 결정하느냐에 따라 성능이 많이 달라진다.
가끔씩 성능이 나쁜 판단을 해 개발자가 힌트를 사용해 도움을 줄 수 있다.

MySQL 캐시

MySQL 5.0 까지는 쿼리 캐시라는 것이 있었으나, 8.0대에 들어와서는 쿼리 캐시가 폐기되었다.

파싱

소프트 파싱: SQL, 실행 계획을 캐시에서 찾아 옵티마이저 과정을 생략하고 실행 단계로 넘어간다.
하드 파싱: SQL, 실행 계획을 캐시에서 찾지못해 옵티마이저 과정을 거치고나서 실행 단계로 넘어간다.

MySQL에는 소프트 파싱이 없다. 하지만, 5버전 까지는 쿼리 캐시가 있었다. 쿼리 캐시는 SQL에 해당 데이터를 저장하는 것인데 데이터를 캐시하기 때문에 테이블의 데이터가 변경되면 캐시의 데이터도 함께 갱신시켜줘야한다.

Oracle에는 소프트 파싱이 존재한다. 실행계획까지만 캐싱을 진행하고, 모든 SQL 매핑하여 데이터까지 캐싱하지는 않는다. 하지만, 힌트나 설정으로 가능하다.

쿼리 캐시 결론

MySQL의 쿼리캐시, Oracle의 소프트 파싱 모두 성능 최적화를 위해 캐시라는 기술을 도입한 사례이다. 하지만, 캐시의 범위가 각 다르다. 캐시를 도입할때는 항상 만료 정책을 고려해야하며 쿼리캐시는 소프트 파싱에 비해 조회성능은 더 높지만 캐시 데이터 관리에 더 높은 비용이 들어간다.

스토리지 엔진

디스크에서 데이터를 가져오거나 저장하는 역할을 한다.
MySQL 스토리지 엔진은 플러그인 형태로 Handler API만 맞춘다면 직접 구현해서 사용할 수 있다.
InnoDB, MyIsam 등 여러개의 스토리지 엔진이 존재한다.
8.0 버전 부터는 InnoDB 엔진이 디폴트이다.

InnoDB

InnoDB는 MySQL의 기본 스토리지 엔진입니다. 이 엔진은 트랜잭션-세이프(transaction-safe) 기능을 제공하며, 대규모 데이터베이스 시스템에서 높은 성능과 확장성을 제공하기 위해 설계되었습니다.
트랜잭션 지원: InnoDB는 완전한 ACID(원자성, 일관성, 고립성, 지속성) 호환 트랜잭션을 지원합니다. 이는 트랜잭션 중 하나라도 실패하면 변경 사항을 롤백(undo)하고, 모든 트랜잭션이 성공적으로 완료되면 커밋(commit)하는 기능을 의미합니다.
행 수준 잠금: InnoDB는 동시성을 높이기 위해 행 수준의 잠금을 지원합니다. 이는 여러 사용자가 동시에 다른 행에 접근할 수 있게 해주어 성능을 향상시킵니다.
외래 키 지원: InnoDB는 외래 키(foreign key) 제약 조건을 지원합니다. 이는 한 테이블의 데이터가 다른 테이블의 데이터에 의존할 때 데이터 무결성을 보장하는 데 도움이 됩니다.
MVCC(Multi-Version Concurrency Control): InnoDB는 MVCC를 사용하여 여러 트랜잭션이 동시에 같은 데이터에 접근할 수 있도록 합니다. 이는 읽기와 쓰기 동작간의 잠금 경합을 줄이며, 동시성을 높이는 데 도움이 됩니다.
크래시 복구 기능: InnoDB는 트랜잭션 로그와 체크포인트를 사용하여 시스템 장애 후에도 데이터를 안전하게 복구할 수 있습니다.

Reference.

백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리 초격차 패키지 Online. | 패스

데이터 처리 4대장 : MySQL, MongoDB, Kafka, Redis 외 31가지 기술스택 활용을 담은 초격차 강의! 실무 경험에 기반한 18가지 Use Case와 105개 실습 클립으로 대용량 테이터 & 처리를 완벽하게 경험해보세요!

fastcampus.co.kr

[모니터링] loki, Promtail를 통해 log 모니터링

큐범 — Mon, 19 Jun 2023 09:13:36 +0900

프로젝트를 진행하면서 어플리케이션, CPU 모니터링에 대해서는 진행중이었으나 WAS에 에러가 발생하면 이를 로컬 환경에서 같이 에러시연을 하는데 문제는 에러 시연이 발생하지 않는 경우에 로그를 직접 보거나 프로세스의 콘솔을 확인하는 상황도 종종 발생했다.

Log 모니터링을 찾아보던 중 elasticsearch와 Loki가 나왔다. 현재 프로젝트에는 grafana가 적용되어 있고 이를 기반으로 작성하기는 loki가 더욱 적용하기 편해보였다.

Loki

특징

수평 확장
다중 로그 집계 시스템
대규모 시스템에도 효율적인 데이터 처리
오픈소스

loki는 promtail을 통해 로그를 가져와서 로그를 저장한다.

promtail은 그라파나 로키(Loki)의 로그 수집 에이전트로 사용되는 오픈 소스 소프트웨어이다.

역할

Promtail : 로그 파일이 존재하는 서버에서 로그를 loki로 전송한다.

Loki : promtail 로그를 수신받아서 이를 저장/분류한다.

최종 아키텍쳐

Promtail을 통해 로그를 loki로 보내고 이를 grafana에서 모니터링 한다.

모든 것은 Docker로 진행된다.

실습

본 실습은 grafana가 설치되어 있는 가정 하에 진행한다

1. loki 설치

wget https://raw.githubusercontent.com/grafana/loki/v2.8.0/cmd/loki/loki-local-config.yaml -O loki-config.yaml
docker run --name loki -d -v $(pwd):/mnt/config -p 3100:3100 grafana/loki:2.8.0 -config.file=/mnt/config/loki-config.yaml

2. promtail 설치

wget https://raw.githubusercontent.com/grafana/loki/v2.8.0/clients/cmd/promtail/promtail-docker-config.yaml -O promtail-config.yaml
docker run --name promtail -d -v $(pwd):/mnt/config -v /var/log:/var/log --link loki grafana/promtail:2.8.0 -config.file=/mnt/config/promtail-config.yaml

<현재 실행하는 디렉토리에>

promtail-config.yaml과 loki-config.yaml이 있어야한다.

3. 그라파나 데이터 소스 추가

datasources -> add new data source

4. URL에 IP:3100하고 Save&Test 진행

추가로 Auth가 있다면 Basic Auth로 설정하면 된다.

5. 연결 확인

Explore에서 Loki를 선택 후 원하는 로그 파일을 확인한다.

추가 경로 설정 원할 경우

promtail-config.yaml

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs # 로그 파일 수집 모음
      __path__: /var/log/*log # 로그파일 경로
  - targets: #example
      - localhost
    labels:
      job: WAS-LOG
      __path__: /var/log/was/*log

추가 로그를 설정 후 컨테이너를 재시작해주면 적용된다.

공식문서(꼭 확인!)

Install Grafana Loki with Docker or Docker Compose | Grafana Loki documentation

Open source Install Grafana Loki with Docker or Docker Compose You can use Grafana Cloud to avoid installing, maintaining, and scaling your own instance of Grafana Loki. Create a free account to get started, which includes free forever access to 10k metric

grafana.com

[강의 후기] Practical Testing: 실용적인 테스트 가이드 후기

큐범 — Sun, 11 Jun 2023 18:55:52 +0900

TDD 스터디를 마치고 실제 회사에서는 어떤 방식으로 테스트를 진행하는지 궁금증을 가지던 중에

인프런에 테스트에 대한 신규 강의와 수강평이 좋아 수강을 하게 되었다.

해당 글은 내가 테스트 강의를 들으면서 공감이 되는 부분을 중점으로 기술한다.

테스트는 왜 필요할까?

강사의 테스트 생각 : 귀찮다.

나의 생각 : 고려해야 할 것이 많다.

QA에 대한 테스트

커버할 수 없는 영역이 발생한다.
경험과 감에 의존한다.
늦은 피드백이 발생한다.
유지보수의 어려움
소프트웨어 신뢰도가 낮아진다.

테스트를 하는 이유

빠른 피드백
자동화
소프트웨어 신뢰도 상승

테스트 코드를 작성하지 않을 경우

변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야 한다.
변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야한다.
빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.

테스트 코드가 병목이 된다면

프로덕션 코드의 안정성을 제공하기 힘들어진다.
테스트 코드 자체가 유지보수하기 어려운, 새로운 짐이 된다.
잘못된 검증이 이루어질 가능성이 생긴다.

올바른 테스트 코드는

자동화 테스트로 비교적 빠른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.
소프트웨어의 빠른 변화를 지원한다.
팀원들의 집단 지성을 팀 차원의 이익으로 승격시킨다.
가까이 보면 느리지만, 멀리 보면 가장 빠르다. -> 소프트웨어의 검증이 코드로 한번 더 검증이 된다는 것은 질 좋은 소프트웨어임을 증명한다.

테스트하기 어려운 영역

관측할 때마다 다른 값에 의존하는 코드
- 현재 날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등
외부 세계에 영향을 주는 코드
- 표준 출력, 메시지 발송, 데이터베이스에 기록하기 등

강의에서는 LocalDateTime.now()를 사용하지 않고 특정 시점에 대해서 테스트를 했다. 즉, 테스트를 할때마다 변하는 시간에 대해서 테스트를 하는 것은 올바른 설계가 아니다. (물론 예외 상황도 존재할 수 있다)

@NotBlank, @NotNull, @NotEmpty

@NotNull = “ ”
@NotEmpty = “”, “ “
@NotBlank = 문자가 필수로 필요한 경우 (공백을 인정하지 않음)

컨트롤러에 필요한 Validation인지 Service에서 필요한 Validation처리인지 역할을 구분해야한다.

책임분리를 고려하여 Service의 dto와 controller의 dto를 분리할 수 있다.

나는 현재까지 @Valid에 대한 테스트를 컨트롤러가 아닌 Service Layer에서 처리했다. 이는 잘못된 설계였다. 강사님은 Controller와 Service에 대한 DTO도 분리하였다. (개인적으로 가장 많이 배운 설계) 객체 지향적 설계로 각각의 Layer는 다른 Layer에 종속적이지 않은 하나의 '모듈'이 되어야한다. Controller의 Request와 Service Request가 동일하지 않게 가져오는 것이 객체지향 SOLID에서 SRP원칙으로 하나의 클래스는 하나의 책임을 가지도록 했다. 하지만, 이는 특정 상황에 필요한 설계로 MSA와 같은 분리가 필요한 상황에서 필요하기에 프로젝트의 성격에 따라 다른 적절한 설계 방식을 사용해야한다.

Test Double - 이는 TDD 스터디에서 정리했기에 간단하게 정리한다.

Dummy : 아무 것도 하지 않는 깡통 객체

Fake : 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체

Stub : 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체 그 외에는 응답하지 않는다.

Spy : Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체 일부는 실제 객체처럼 일부만 Stubbing 할 수 있다.

Mock : 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체

결론

강사님께서 강의중 가장 많이 이야기한 것은 "테스트는 문서다"이다.

현재 새로운 회사에서 개발을 임하면서 테스트에 대해서 깊게 생각을 하게 되었고 실제 다른 회사에서는 어떤 방식으로 테스트를 하는지 궁금하여 수강하게된 강의에서 많은 것을 배우면서 가장 많이 배운 것은 "테스트는 문서의 역할을 가지게 해야한다"이다. 현재 내가 맡은 프로젝트의 이전 개발자는 코드에 대해서 컨벤션도 엉망이며 테스트는 물론 코드에 대한 메타 데이터도 존재하지 않다. 이를 하나하나 이해하며 새롭게 바꾸면서 테스트 코드의 중요성을 깨우치고 있다. 단순히 테스트 코드는 나에게 빌드할때 한번 더 검증하는 수단이었으나, 테스트 코드는 이 프로젝트를 맡게되는 이후의 개발자와의 소통이다. 테스트 코드를 통해 로직의 깊이 있게 검증하며 이해할 수 있다. 실제로, TDD 스터디를 통해 테스트 로직이 얼마나 비즈니스 로직을 이해하는 것에 도움이 된다는 것을 몸소 느겼다. 테스트는 그 어떠한 설명서보다 이해하기 쉽게 만들어지는 소프트웨어의 설명서이다.

출처

Practical Testing: 실용적인 테스트 가이드 - 인프런 | 강의

이 강의를 통해 실무에서 개발하는 방식 그대로, 깔끔하고 명료한 테스트 코드를 작성할 수 있게 됩니다. 테스트 코드가 왜 필요한지, 좋은 테스트 코드란 무엇인지 궁금하신 모든 분을 위한 강

www.inflearn.com

[DB] 데이터 플랫폼 사업단의 Data 이야기

큐범 — Sat, 20 May 2023 15:44:59 +0900

회사에서 진행하는 사내 기술 세미나를 참석하게 되어 이를 정리하기로 하였다.

2022년 가트너의 IT 전략 기술 트렌드

성장 가속 부문
- 제너레이티브 AI : 제너레이티브 AI는 텍스트 설명을 기반으로 이미지를 생성하는 인공지능 프로그램입니다.
- 오토노믹 시스템 : 주위 환경에 맞춰 스스로 관리하는 시스템이다.
변화 형성 부문
- 컴포저블 애플리케이션 : 비즈니스 중심의 모듈식 컴포넌트로 구성되어 있는 어플리케이션을 뜻한다.
- 의사결정 인텔리전스 : 상황에 따라 스스로 일을 결정해 처리함으로써 결정을 돕는 인공지능이다.
신뢰 구축 부문
- 데이터 패브릭 : 분산 데이터에 대한 액세스를 최적화하고 데이터 소비자에게 셀프 서비스 제공을 위해 지능적으로 큐레이션 및 오케스트레이션 할 수 있는 데이터 관리 아키텍처이다.
- 사이버보안 메시 : 이용자나 신원을 중심으로 보안 경계를 정의해, 독립된 환경과 컴퓨팅 환경에서도 회사 보유 데이터에 안전하게 접근할 수 있도록 해준다.

2023년 가트너의 IT 전략 기술 트렌드

디지털 면역체계
응용 관측 가능성
AI 신뢰 위험 보안관리(AI TRiSM)
산업 클라우드 플랫폼
플랫폼 엔지니어링
무선 가치 실현
슈퍼앱
적응형 AI
메타버스 (사업단의 핵심) : "디지털 화폐와 대체불가능한 토큰(NFT)으로 구현되는 자체적 가상 경제를 갖출 것이다."
지속가능한 기술

데이터의 과거와 현재

과거에는 데이터와 콘텐츠의 개념을 구분한다.

하지만 현재는 데이터 콘텐츠가 포함되고 있다.

과거에는 데이터와 정보의 개념을 구분해서 생각한다.

데이터 : 데이터는 발생한 상태 그대로 기록한 것이다.
정보 : 의도를 가지고 데이터를 가공한 결과

현재는 데이터와 정보를 엄격하게 구분하지 않는다.

→ 처리시간의 감소와 단계의 축소

데이터 웨어하우스의 용어와 의미

복잡도의 상승에 따라 데이터 웨어하우스의 탄생 배경

미국 컴퓨터 전문가 빌 인먼은 창고를 보고 데이터 웨어하우스를 떠올린다.

데이터 생산지 → 데이터 웨어하우스 → 데이터 소비자

빅데이터의 등장과 문제점

문제 발생 : 비구조적 데이터를 DW에 쌓을 수 없다.

DW에 보관하기 위해서는 데이터 식별자와 데이터 형태 등을 정해야한다.
비구조적 데이터는 사이즈가 너무 크다.
DW에 담기에는 비용이 비싸진다.
발생한 데이터를 화용하지 못하고 버릴 수는 없다.

데이터 레이크의 등장

데이터를 가공하여 사용할 수 있는 형태로 보관하기 보다는 발생한 모습 그대로 일단 한 곳에 모아두고 필요할 때 가공하여 사용하자는 것

레이크, 즉 호수는 모든 강에서 흘러 들어오는 물줄기를 버리지 않고 일단 담아둔다는 의미와 상통한다.

사전처리보다 필요시 처리하는 데이터 레이크가 더 비용적으로 효율적이다.

데이터 레이크는 대규모 데이터를 수집하고 저장하는 고도로 확장 가능한 저장소다. 데이터 레이크는 다양한 형식의 데이터를 수집하고 저장하며, 원시 형식으로 저장된다. 이는 데이터의 유연성과 다양성을 보장하며, 데이터가 수집되는 단계에서부터 분석 및 가공이 필요한 시점까지의 모든 단계에서 데이터를 보존한다.

데이터 카탈로그의 등장

데이터 카탈로그는 조직 내의 데이터 자원을 관리하는 중앙 집중식 메타데이터 저장소다. 데이터 카탈로그는 데이터 레이크 및 다른 데이터 소스에서 추출된 데이터에 대한 메타데이터를 기록하고 관리한다. 이는 데이터의 검색, 이해, 공유 및 재사용을 용이하게 한다. 데이터 카탈로그는 데이터의 위치, 보안 정책, 데이터 소유자 등의 정보를 추적하며, 데이터에 대한 검색 및 엑세스를 표준화한다.

3가지 메타데이터의 조합

기술 메타 데이터 : 데데이터 자원과 관련된 기술적인 세부 정보를 포함한다.
프로세스 메타데이터 : 기술 메타데이터는 데이터 자원과 관련된 기술적인 세부 정보를 포함한다.
비즈니스 메타데이터 : 데이터의 비즈니스적 의미와 관련된 정보를 담고 있다.

[TDD] 테스트 범위와 종류

큐범 — Mon, 6 Mar 2023 00:55:00 +0900

테스트 범위

하나의 기능이 올바르게 동작하려면 컨트롤러, 서비스, 모델과 같은 자바 코드와 프레임워크, 설정에 문제가 없어야 할 뿐 아니라 브라우저에서 실행되는 자바스크립트 코드, HTML과 CSS 등이 정상 동작해야 한다. 또한, DB의 테이블도 올바르게 생성해야한다.

기능 테스트와 E2E테스트

기능 테스트(Functional Testing)는 사용자 입장에서 시스템이 제공하는 기능이 올바르게 동작하는지 확인한다. 이 테스트를 수행하려면 시스템을 구동하고 사용하는데 필요한 모든 구성요소가 필요하다.

기능 테스트는 사용자가 직접 사용하느 웹 브라우저나 모바일 앱부터 시작해서 데이터베이스나 외부 서비스에 이르기까지 모든 구성 요소를 하나로 엮어서 진행한다. 기능 테스트는 끝에서 끝가지 올바른지 검사하기 때문에 E2E(End to End)테스트로도 볼 수 있다.

통합테스트

통합 테스트(Integration Testing)는 시스템의 각 구성 요소가 올바르게 연동되는지 확인한다. 기능 테스트가 사용자 입장에서 테스트하는데 반해 통합 테스트는 소프트웨어의 코드를 직접 테스트한다.

단위 테스트

단위 테스트(Unit Testing)는 개별 코드나 컴포넌트가 기대한대로 동작하는지 확인한다. 지금까지 이 책에서 살펴본 테스트가 주로 단위 테스트 코드이다. 단위 테스트는 한 클래스나 한 메서드와 같은 작은 범위를 테스트한다.

테스트 범위 간 차이

통합 테스트를 실행하려면 DB나 캐시 서버와 같은 연동 대상을 구성해야 한다. 기능 테스트를 실행하려면 웹 서버를 구동하거나 모바일 앱을 폰에 설치해야 할 수도 있다. 또한, 통합 테스트나 기능 테스트는 테스트 상황을 만들어내기 위해 많은 노력이 필요하다. 반면에 단위 테스트는 테스트 코드를 빼면 따로 준비할 것이 없다.
통합 테스트는 DB 연결, 소켓 통신, 스프링 컨테이너 초기화와 같이 테스트 실행 속도를 느리게 만드는 요인이 많다. 기능 테스트는 추가로 브라우저나 앱을 구동하고 화면의 흐름에 따라 알맞은 상호 작용을 해야 한다. 반면에 단위 테스트는 서버를 구동하거나 DB를 준비할 필요가 없다. 테스트 대상이 의존하는 기능을 대역으로 처리하면 되므로 테스트 실행 속도가 빠르다.
통합 테스트나 기능 테스트로는 상황을 준비하거나 결과 확인이 어렵거나 불가능할 때가 있다. 외부 시스템과 연동해야 하는 기능이 특히 그렇다. 이런 경우에는 단위 테스트와 대역을 조합해서 상황을 만들고 결과를 확인해야 한다.

테스트 범위에 따른 테스트 코드 개수와 시간

테스트를 자동화한다는 것은 결국 코드로 작성한 테스트를 실행한다는 것을 의미한다. 통합 테스트는 기능 테스트에 비해 제약이 덜하다. 단위 테스트는 통합 테스트로도 만들기 힘든 상황을 쉽게 구성할 수 있다. 기능테스트나 통합 테스트에서 모든 예외 상황을 테스트하면 단위 테스트는 줄어든다.

외부 연동이 필요한 테스트 예

모든 외부 연동 대상을 통합 테스트에서 다룰수 없지만 일부 외부 대상은 어느정도 수준에서 제어가 가능하다.

WireMock을 이용한 REST 클라이언트 테스트

통합 테스트 하기 어려운 대상이 외부서버이다. WireMock을 사용하면 서버 API를 스텁으로 대체할 수 있다.

WireMockServer는 HTTP 서버를 흉내 낸다.

테스트 실행 전에 WireMockServer를 시작한다. 실제 HTTP 서버가 뜬다.
테스트에서 WireMockServer의 동작을 기술한다.
HTTP 연동을 수행하는 테스트를 실행한다.
테스트 실행 후에 WireMockServer를 중지한다.

스프링 부트의 내장 서버를 이용한 API 기능 테스트

스프링 부트를 사용한다면 API에 대한 테스트를 JUnit 코드로 작성 할 수 있다.

Refence.

테스트 주도 개발 시작하기 - YES24

TDD(Test-Driven Development)는 테스트부터 시작한다. 구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그다음에 구현한다. 구현 코드가 없는데 어떻게 테스트할 수 있을까? 여기

www.yes24.com

[Cloud] AWS, Azure, GCP에 대한 비교

큐범 — Sun, 26 Feb 2023 16:16:18 +0900

들어가며

클라우드 서비스 세계적으로 유명한 곳은 AWS, Azure, Google이 존재한다. 그 외에도 국내에는 Naver Cloud Flattform이 존재한다. AWS는 Amazon Web Service로 아마존에서 제공하고 Azure는 Microsoft, Google Colud Platform은 구글에서 제공한다.

AWS

AWS는 가장 많은 시장 점유율로 33%를 차지하고 있어 Private Cloud 서비스 분야에서 타 서비스 대비 장점을 갖고 있다.

AWS의 IaaS는 Elastic Compute Cloud(EC2)가 그 예이며 메인 컴퓨팅 서비스. 프로세서, 스토리지 네트워크, 운영체제 등 폭넓고 세분화된 스펙을 제공한다. EC2의 경우, 가장 많이 사용해봤기에 어떠한 장단점이 있는지 파악하고 있다. 내가 느낀 EC2의 장점은 첫째, 초보자도 쉽게 IaaS를 누릴수 있는 것이었다.

<사이드 프로젝트의 EC2 - 모니터링>

EC2를 만들때 유저는 실제로 옷을 사듯이 OS, 유형, 네트워크, 키 등을 편리하게 사용할 수 있으며 AWS는 해당 탭마다 정보를 제공해 사용자는 해당 탭에 대한 내용도 알아볼 수 있게하였다. 둘째, 타사 대비 많은 레퍼런스와 공식문서의 정리가 제일 잘 되어 있었다. 셋째, 서비스의 범위가 매우 높아 AWS파트너쉽을 통해 업체는 AWS가 직접 관리를 해주는 서비스도 제공해준다. 단점은 첫째, EC2에 대한 커스텀이 복잡하고 과금에 대해서 프리티어가 주어지나 타사 대비 비싼 감이 있었다. 둘째, 세부적인 컨트롤이 가능하기에 다소 복잡하게 관리가 이루어지는 경우가 있었다.

AWS의 Paas는 Elastic Beanstalk, Lightsail, AWS App Runner가 존재한다. Elastic Beanstalk는 다양한 언어와 서버 프로그램이 내장되어 있어 코드만 업로드하면 용량 프로비저닝(자원할당)과 로드 밸런싱, 오토 스케일링 및 모니터링까지 이르는 배포과정을 자동으로 처리해준다. Lightsail는 저렴한 비용으로 애플리케이션 및 웹 사이트를 빠르게 구축할 수 있는 서비스이며 Word 등 사전에 구성된 애플리케이션을 통해 빠르게 웹 사이트 구축이 가능하다. AWS App Runner는 컨테이너와 된 애플리케이션 및 API를 대규모로 빠르게 배포할 수 있도록 지원하는 완전 관리형 서비스이다. 웹 애플리케이션을 자동 구축 및 배포하고 암호화를 통한 트래픽 로드 밸런싱 수행 및 오토스케일링을 수행한다.

AWS의 컨테이너 관리는 Amazon ECR(Elastic Container Registry)서비스를 통해 구축이 가능하다. ECR을 통해 컨테이너 이미지를 푸시하고 모든 도구를 관리할 수 있다.

<출처-AWS ECR작동방식>

AWS ECS Anywhere를 통해 컨테이너를 실행할 수 있다. ECS는 컨테이너기반 애플리케이션에서 도구를 제공해준다.

<출처-AWS ECS Anywhere 작동방식>

그러면 쿠버네티스의 주 목적인 컨테이너의 관리가 이루어져야하는데 이것을 Amazon EKS Anywhere가 한다.

EKS Anywhere를 통해 쿠버네티스 클러스터를 운영이 가능하다.

<출처 – AWS EKS anywhere 작동방식>

Azure

Azure는 점유율 20%로 MS사에서 만들었기에 MS관련 서비스와 높은 호환성을 가진다. Azure의 IaaS는 Azure Virtual Machines에는 Linux, Window Server가 존재하고 가상 머신에는 A시리즈부터 N시리즈가 존재한다. PaaS는 App Service, Batch, Azure Spring Cloud, Cloud Services가 존재하는데 학부 수준에서 공부를 위해 유용하게 쓰일만한 것은 App Service는 Application Service를 구축하기 위한 완전 관리형 플랫폼이다. Azure Spring App은 Spring Boot와 호환성이 좋으며 Spring Cloud Azure는 Spring 공식적으로 지원하는 서비스이기에 Azure와 호환성이 매우 좋다.

Azure Spring Apps

Azure Kubernetes Service는 운영 오버헤드를 Azure가 관리하여 Kubernetes 클러스터 배포를 단순화할 수 있다. 호스팅 되는 Kubernetes 서비스인 Azure는 상태 모니터링 및 유지관리 등 작업 처리를 할 수 있다. Azure Kubernetes Service는 크게 4가지의 서비스를 제공한다. 첫째,엔터프라이즈급 컨테이너 오케스트레이션을 위해 Kubernetes 클러스터의 자동화된 관리를 할 수 있다. 둘째, 디버깅, CI/CD, 로깅 등 자동 노드 유지 관리를 통한 엔드투엔드 개발자의 생산성을 높여준다. 셋째, 대규모 거버넌스를 위해 컨테이너 보안을 모니터링 및 유지 관리하는 고급 ID 및 액세스 관리한다. 넷째, Azure Arc를 사용하여 인프라에 AKS배포를 통해 Linux, Windows Server 및 IoT 리소스 지원을 받을 수 있다.

GCP

Google Cloud Platform은 구글에서 제공하는 클라우드 컴퓨팅 서비스로 시장 점유율 10%로 앞서 소개한 클라우드 회사 대비 낮은 점유율을 갖고 있다. 구글 클라우드 플랫폼은 IaaS서비스는 구글 컴퓨트 엔진(Goole Compute Engine, GCE), 빅테이블, 빅쿼리가 있다. 구글 컴퓨트 엔진의 운영체제는 리눅스, 윈도우, FreeBSD, NetBSD가 있고 GCE는 FM 런칭 이전에 Oauth 2.0 기반의 인증을 수행해야 하는 단점이 있다. 빅테이블은 구글의 파일 시스템으로 고성능 데이터 스토리지 시스템이다. 그리고 빅 쿼리는 대용량, 페타바이트급 이상의 데이터에 대해 분석을 가능하게 하는 관리형 서버리스 컴퓨팅 데이터 웨어하우스이다. 그 다음 GCP의 PaaS는 구글 앱 엔진으로(Google App Engine, GAE) 웹 응용 프로그램을 개발하고 구글의 인프라에서 실행하고 버전 관리할 수 있다. Google Kubernetes Engine(GKE) Kubernetes를 자동으로 배포, 확장, 관리할 수 있으며 안전한 Google 인프라에서 컨테이너화된 애플리케이션을 배포, 확장 및 관리하기 위한 관리형 환경을 말한다.

AWS, Azure, GCP 장단점 비교

첫째, AWS에 대해서 장단점을 파악 해보면 AWS의 장점은 가장 높은 시장 점유율로 많은 레퍼런스와 성공사례가 있다는 것이다. 따라서 서비스를 제공하는 범위가 타사 대비 매우 높으며 파트너 생태계가 매우 잘 이루어져 있다. 단점은 AWS를 사용하기 위해서 AWS의 시스템에 대한 이해도가 필요하며 규모가 큰 하이브리드 클라우드의 지원이 부족하고 AWS의 서비스의 범위가 크기에 파악하기 힘든 경향이 있다.

둘째, Azure의 장단점을 파악해보면 Azure의 장점은 다른 MS 서비스 및 제품과의 이식성이 좋기에 MS teams, word 등 다른 서비스와 같이 사용하기 좋다. 오픈 소스 애플리케이션 스택에 대한 많은 도움을 받을 수 있다. AWS에서 부족한 하이브리드 클라우드에 대해서 솔루션이 제공된다. 가상 환경에서도 모두 잘 실행되는 사용 사례가 만이 존재한다. 하지만 단점은 대규모 구현의 빈약한 규모가 있으며 Azure 또한, 구현하기 위해서 인프라에 대해서 전문 지식이 필요하다.

셋째, GCP의 장단점을 파악해보면 GCP의 장점은 오픈 소스 커뮤니티에 대한 기여했다. 또한, 현재 각광받는 분야인 분석 및 머신러닝에 대한 많은 투자가 이루어지고 빅데이터 애플리케이션, ML 벤처 및 클라우드 네이티브 애플리케이션을 위한 최적의 옵션이다. 단점은 타사 대비 시장 점유율이 낮아 성공 레퍼런스가 비교적 부족하고 계약협상에 대해서 타사 대비 까다로운 계약 협상이 있다. 또한, 규모가 다른 회사에 비해 적기에 파트너 생태계가 규모가 작다.

만약 내가 클라우드를 도입한다면 3가지 클라우드 기업 중 어느 것을 선택하겠는가?

만약 서비스 스타트업에서 클라우드 컴퓨팅을 도입한다면 단연, AWS를 채택할 것이다. 그 근거를 3가지가 있다.

첫째, 가장 높은 시장 점유율

AWS는 국내를 넘어 전 세계적으로 가장 높은 클라우드 시장성을 가지고 있다. 또한, 시장 점유율은 기업 경쟁간의 우의를 점하고 있다는 지표를 나타내기도 한다. 실제로 AWS를 운용해보며 런칭을 진행해 본 결과 AWS는 가장 많은 레퍼런스가 나왔다.

둘째, 합리적 가격

3사 중 가장 저렴한 가격이라면 그것은 아니다. 단, 합리적인 가격이라고 생각한다. AWS는 파트너십을 통해서 직원이 직접 관리해주는 서비스도 제공하며 시장에 DevOps 개발자의 선택 비중으로 본다면 AWS 관련 개발자가 채용과정에서 가장 수월할 것으로 생각된다. 실제로 AWS의 설정을 통해서 AWS의 가상서버는 코크로치랩스가 TPC-C 테스트에서 파생시킨 OLTP 성능평가 결과상 가장 비용효율적인 상품으로 AWS의 c5a.4xlarge 인스턴스는 GCP의 가성비 최고상품대비 12% 저렴하고 MS애저 대비로는 35% 저렴한 기사가 있다. 그리고 AWS는 스타트업 클라우드에는 사용료를 일정 부분 할인해주는 서비스도 지원하고 특정 기간에 사용률을 기반으로 앞으로의 추세를 분석해주는 서비스가 존재하기에 스타트업에서 매우 필수적인 클라우드 제공 업체이다. 스타트업의 효율적인 클라우드 사용을 위해 각 기업의 상황에 맞는 기간할인, 금액설정, 단기 사용등 3가지 경우를 권고하는데 이를 AWS에서 분석 및 결과를 추출해주니 매우 유용하다.

셋째, AWS 스타트업 서비스

AWS에서는 스타트업을 지원해주는 AWS 스타트업 서비스가 있다. AWS 상에서 스타트업을 구축하기에 다른 스타트업 창업자들과 매칭시켜주기도 하며 이를 통해 비즈니스 성장을 도모한다. 다양한 AWS 스타트업 프로그램을 지원하고 있는데 이를 이용하면 인프라 서비스를 넘어 스타트업의 시작, 성장, 비즈니스 확장을 받을 수 있다. 이를 기반으로 Airbnb, Zocdoc 등의 유니콘 기업의 클라우드 서비스를 제공해준 이력이 있기에 스타트업과 자사 대형 고객들을 연결해주는 프로그램인 AWS 커넥션, 스타트업의 빠른 시작을 지원하는 AWS Public Sector Startup Ramp도 있으며 스타트업의 운영 가속화를 위한 검증, 출시, 지원, 영업에 대한 지침을 제공하는 AWS 파트너 네트워크 서비스도 제공한다.

위의 3가지의 근거를 통해 만약 내가 스타트업의 클라우드 컴퓨팅을 도입한다면 AWS를 채택 할 것이다.

Reference.

AWS App Runner – 손쉽게 코드를 높은 확장성의 안전한 웹 애플리케이션 배포하기 | Amazon Web Services

컨테이너는 웹 애플리케이션을 패키징하는 기본 방법이 되었습니다. 저는 컨테이너가 제공하는 속도, 생산성 및 일관성을 선호하지만 컨테이너 개발 워크 플로우에는 컨테이너 이미지를 처음

aws.amazon.com

가상 프라이빗 서버 및 웹 호스팅–Amazon Lightsail—Amazon Web Services

WordPress, Magento, Prestashop, Joomla와 같은 사전 구성된 애플리케이션을 통해 단 몇 번의 클릭으로 블로그, 전자 상거래 또는 개인 웹 사이트를 구축합니다.

aws.amazon.com

Virtual Machines 시리즈 | Microsoft Azure

개발/테스트용 초급 수준 VM부터 집약적 워크로드를 위한 GPU 지원 VM에 이르기까지 모든 애플리케이션 요구 사항을 위한 Azure의 다양한 VM(가상 머신)을 확인하세요.

azure.microsoft.com

App Service — Build and Host Web Apps | Microsoft Azure

Migrate and build apps. Azure App Service is a fully managed platform for creating web applications. The app service offers a range of app development plans and services.

azure.microsoft.com

Spring | Home

Cloud Your code, any cloud—we’ve got you covered. Connect and scale your services, whatever your platform.

spring.io

Azure Kubernetes Service 소개 - Azure Kubernetes Service

Azure에서 컨테이너 기반 애플리케이션을 배포 및 관리하는 Azure Kubernetes Service의 기능 및 이점을 알아봅니다.

learn.microsoft.com

아마존 선두, 다음은 구글…가성비로 본 클라우드 빅3 | 아주경제

세계 클라우드 시장 점유율 1위 아마존웹서비스(AWS)가 일반적인 온라인트랜잭션처리(OLTP) 환경에서 마이크로소프트(MS)와 구글클라우드보다 나은 가성비를 보여주는 것으로 나타났다.19일 분산

www.ajunews.com

스타트업을 위한 AWS - Amazon Web Services(AWS)

Airbnb에서 Zocdoc에 이르기까지 세계 최고의 스타트업들이 AWS를 기반으로 구축되었습니다. 하지만 이들의 성공 뒤에는 전폭적인 지원이 있었습니다. 기술 과제를 해결해야 하거나, 훌륭한 엔지니

aws.amazon.com

[GDSC] CICD 세션 결말 해석

큐범 — Fri, 24 Feb 2023 17:01:36 +0900

GDSC(Google Developer Student Club)에서 개발 기술에 대해서 하나씩 선정하여 세션을 진행하게 되었다.

나는 CICD에 대해서 진행하였고 CICD의 필요성과 수동 배포 방식의 워크플로우와 비교하여 설명하였다.

[Session] CICD / 한규범

CI/CD 의미 CI ⇒ Continuous Intrgration (지속적 통합) CD ⇒ Continous Delivery (지속적 전달) CD ⇒ Continuous deployment (지속적 배포) Continuous Intrgration 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미

gdsc-mju.tistory.com

나의 CICD 세션의 목표는 툴에 의존하기 보다는 CICD를 도입하면 개발방식에 대해서 변화를 가져오는 것을 이해하기 바라는 마음으로 작성하였다.

결론 해석

결론의 내용은 "열차를 타지 말고 택시를 타라"이다.

"열차를 타지 말고 택시를 타라"는 데브옵스(DevOps)에서의 일종의 말장난으로, 소프트웨어 배포를 비유적으로 비교한 것이다.

여기서 "열차"는 예전에 많이 사용되었던 워터폴 방식의 소프트웨어 개발 모델을 의미하며, 이 모델은 소프트웨어 개발 생명주기를 단계별로 구분하여 한 단계가 끝나면 다음 단계로 넘어가는 선형적인 방식으로 작업을 처리했다. 이 방식은 전체적으로 진행 상황을 파악하기 어렵고, 문제 발생 시 수정하기 어려워지는 등 여러 가지 문제점이 있다.

반면에 "택시"는 데브옵스에서 추구하는 지속적인 통합/배포(CI/CD)를 의미하며, 이는 소프트웨어 개발과 운영을 하나로 통합하여 작은 단위로 빈번한 배포를 통해 빠른 피드백과 지속적인 개선을 가능하게 한다.

따라서, "열차를 타지 말고 택시를 타라"는 더 빠르고 유연한 소프트웨어 배포 방식을 추구하자는 의미의 말이다.

[TDD] 테스트 가능한 설계

큐범 — Sun, 19 Feb 2023 23:05:04 +0900

테스트 어려운 코드

모든 코드를 테스트할 수 있는 것은 아니다. 개발을 진행하다 보면 테스트하기 어려운 코드를 만나게 된다. 이를 살펴보고 이를 어떻게 테스트 가능한 코드로 변경하는 지 파악한다.

하드 코딩된 경로

Path path = Paths.get("D:\\\\data\\\\pay\\\\cp0001.csv)

하드 코딩된 경로뿐만 아니라 하드코딩된 IP 주소, 포트 번호도 테스트를 어렵게 만든다.

의존 객체를 직접 생성

private PayInfoDao payInfoDao = new PayInfoDao();

테스트를 어렵게 만드는 또 다른요인은 의존 대상을 직접 생성하고 있다는 점이다. 해당 코드를 테스트 하려면 PatInfoDao가 올바르게 동작하는데 필요한 모든 환경을 구성해야한다. DB를 준비해야하고 필요한 테이블도 만들어야 한다.

정적 메서드 사용

public LoginResult login(String id, String pw) {
    int resp = authService.authenticate(id, pw);
    if (resp == -1) return LoginResult.badAuthKey();

    if (resp == 1) {
        Customer c = customerRepo.findOne(id);
        return LoginResult.authenticated(c);
    } else {
        return LoginResult.fail(resp);
    }
}

해당 코드는 AuthUtil 클래스의 정적 메서드를 사용하고 있다. AuthUtil 클래스가 인증 서버와 통신하는 경우 이 테스트하려면 동작하고 있는 인증 서버가 필요하다.

실행 시점에 따라 달라지는 결과

LocalDate now = LocalDate.now();

같은 테스트 코드라도 어제가지는 문제 없이 성공하던 코드가 오늘 실패할 수 있다.

역할이 섞여 있는 코드

포인트 계산 로직만 테스트하기 어렵다. 포인트 계산 자체는 이 두 DAO와 상관이 없다. 포인트 계산에 필요한 것은 두개의 DAO가 필요하기 때문이다.

그 외의 테스트가 어려운 코드

메서드 중간에 소켓 통신 코드가 포함한다.
콘솔에서 입력을 받거나 결과를 콘솔에 출력한다.
테스트 대상이 사용하는 의존 대상 클래스가 메서드가 final이다. 이 경우 대역으로 대체가 어려울 수 있다.
테스트 대상의 소스를 소유하고 있지 않아 수정이 어렵다.

테스트 가능한 설계

하드 코딩된 상수를 생성자나 메서드 파라미터로 받기

public void setFilePath(String filePath) {
    this.filePath = filePath;
}

의존 대상을 주입 받기

public void setPayInfoDao(PayInfoDao payInfoDao) {
    this.payInfoDao = payInfoDao;
}

테스트하고 싶은 코드를 분리하기

public class PointRule {

    public int calculate(Subscription s, Product p, LocalDate now) {
        int point = 0;
        if (s.isFinished(now)) {
            point += p.getDefaultPoint();
        } else {
            point += p.getDefaultPoint() + 10;
        }
        if (s.getGrade() == GOLD) {
            point += 100;
        }
        return point;
    }
}

public int calculatePoint(User u) {
    Subscription s = subscriptionDao.selectByUser(u.getId());
    if (s == null) throw new NoSubscriptionException();
    Product p = productDao.selectById(s.getProductId());
    LocalDate now = times.today();
    return pointRule.calculate(s, p, now);
}

클래스로 분리하여테스가 가능하도록 한다.

시간이나 임의 값 생성 기능 분리하기

현재 일자를 구하는 기능을 분리하고 분리한 대상을 주입할 수 있게 변경하면 테스트를 원하는 상황으로 쉽게 제어할 수 있다.

외부 라이버리는 직접 사용하지 말고 감싸서 사용하기

대역으로 대체하기 어려운 외부 라이브러리가 있다면 외부 라이브러리를 직접 사용하지 말고 외부 라이브러리와 연동하기 위한 타입을 따로 만든다. 테스트 대상 코드는 새로 분리한 타입을 사용함으로써 외부 연동으로 필요한 기능을 쉽게 대역으로 대체할 수 있게 된다.

Reference.

테스트 주도 개발 시작하기 - YES24

www.yes24.com

[TDD] 대역

큐범 — Mon, 13 Feb 2023 01:51:17 +0900

외부 요인은 테스트 작성을 어렵게 만들 뿐만 아인라 테스트 결과도 예측할 수 없게 만든다.

Double

영어로 된 테스트 관련 글을 읽으면 test double이란 표현이 자주 나오는데 여기서 double은 본 장에서 설명하는 대역에 해당한다. 즉, test double은 테스트에서 진짜 대신 사용할 대역을 의미한다.

대역의 종류

대역종류 설명

대역종류	설명
스텁(Stub)	구현을 단순한 것으로 대체한다. 테스트에 맞게 단순히 원하는 동작을 수행한다.
가짜(Fake)	제품에는 적합하지 않지만, 실제 동작하는 구현을 제공한다. DB대신에 메모리를 이용해서 구현한 것과 같다.
스파이(Spy)	호출된 내역을 기록한다. 기록한 내용은 테스트 결과를 검증할 때 사용한다. 스텁이기도 하다.
모의(Mock)	기대한대로 상호작용하는지 행위를 검증한다. 기대한 대로 동작하지 않으면 익셉션을 발생할 수 있다. 모의 객체는 스텁이자 스파이기도 된다.

구현 전에 설계해보기

구현전에 모든 기능을 설계하는 것은 불가능하다. 왜냐면 개발을 진행하는 동안에도 요구사항이 계속해서 바뀌기 때문이다. 그럼에도 불구하고 단위 기능을 구현하기에 앞서 어떤 구성 요소가 필요할지 고민하는 것은 의존 대상을 도출할 때 도움이 된다.

상황과 결과 확인을 위한 협업 대상(의존) 도출과 대역 사용

한 테스트는 특정한 상황에서 기능을 실행하고 그 결과를 확인한다. 실제 구현을 이용하면 상황을 만들기 어려울 때가 많다. 제어하기 힘든 외부 상황이 존재하면 다음과 같은 방법으로 의존을 도출하고 이를 대역으로 대신할 수 있다.

제어하기 힘든 외부 상황을 별도 타입으로 분리
테스트 코드는 별도로 분리한 타입의 대역을 생성
생성한 대역을 테스트 대상의 생성자 등을 이용해서 전달
대역을 이용해서 상황 구성

대역은 의존하는 대상을 구현하지 않아도 테스트 대상을 완성할 수 있게 만들어주며 이는 대기 시간을 줄여주어 개발 속도를 올리는 데 도움이 된다.

모의 객체를 과하게 사용하지 않기

모의 객체는 스텁과 스파이를 지원하므로 대역으로 모의 객체를 많이 사용한다. 모의 객체를 이용하면 대역 클래스를 만들지 않아도 되니까 처음에는 편할 수 있다. 하지만 결과 값을 확인하는 수단으로 모의 객체를 사용하기 시작하면 결과 검증 코드가 길어지고 복잡해진다. 특히 하나의 테스트를 위해 여러 모의 객체를 사용하기 시작하면 결과 검증 코드의 복잡도는 배로 증가한다. 게다가 모의 객체는 기본적으로 메서드 호출 여부를 검증하는 수단이기 때문에 테스트 대상과 모의 객체 간의 상호 작용이 조금만 바뀌어도 테스트가 깨지기 쉽다.

DAO나 리포지토리와 같이 저장소에 대한 대역은 메모리를 이용한 가짜 구현을 사용하는 것이 테스트 코드 관리에 유리하다.

Reference.

테스트 주도 개발 시작하기 - YES24

www.yes24.com

[TDD] 테스트 코드의 구성

큐범 — Mon, 6 Feb 2023 21:17:09 +0900

이번 주차 블로그 글은 GDSC에서 제가 직접한 글을 첨부하도록 하겠습니다.

[TDD] 5. 테스트 코드의 구성

작성자 : 한규범 기능에서의 상황 주어진 상황에 따라 기능 실행 결과는 달라진다. 이는 테스트 코드 구조에도 영향을 주는데 이에 관한 내용을 이어서 살표보자. 상황 찾기 노련한 개발자는 어

gdsc-mju.tistory.com

Reference.

테스트 주도 개발 시작하기 - YES24

www.yes24.com

[TDD] JUnit5 기초

큐범 — Sun, 29 Jan 2023 00:11:37 +0900

Junit5 모듈 구성

Junit5는 크게 세 개의 요소로 구성되어 있다.

JUnit 플랫폼: 테스팅 프레임워크를 구동하기 위한 런처와 테스트 엔진을 위한 API를 제공한다.

JUnit 주피터(Jupiter): JUnit5를 위한 테스트 API와 실행 엔진을 제공한다.

JUnit 빈티지(Vintage): Junit 3과 4로 작성된 테스트를 Junit5 플랫폼에서 실행하기 위한 모듈을 제공한다.

Junit5 는 테스트를 위한 API로 주피터 API를 제공한다.

@Test 애노테이션과 테스트 메서드

JUnit 모듈을 설정했다면 JUnit을 이용해서 테스트 코드를 작성하고 실행할 수 있다.

Junit의 Assertions 클래스는 assertEquals() 메서드와 같이 값을 검증하기 위한 목적의 다양한 정적 메서드를 제공한다.

public class SumTest {

    @Test
    public void sum(){
        int result = 2 + 3;
        Assertions.assertEquals(5,result);
     }
     
}

주요 단언 메서드

메서드 설명

메서드	설명
assertEquals(expected, actual)	실제 값(actual)이 기대하는 값(expectec)과 같은지 검사한다.
assertNotEquals(unexpected, actual)	실제 값(actual)이 특정 값(unexpected)과 같지 않은지 검사한다.
assertSame(Object expected, Object actual)	두 객체가 동일한 객체인지 검사한다.
assertNotSame(Object unexpected, Object actual)	두 객체가 동일하지 않은 객체인지 검사한다.
assertTrue(boolean condition)	값이 true인지 검사한다.
assertFalse(boolean condition)	값이 false인지 검사한다.
assertNull(Object actual)	값이 null인지 검사한다.
assertNotNull(Object actual)	값이 null이 아닌지 검사한다.
fail()	테스트를 실패 처리한다.

Exception관련 메서드

메서드 설명

메서드	설명
assertThrows(Class<T> expectedType, Executable excutable)	executable을 실행한 결과로 지정한 타입의 익셉션이 발생하는지 검사한다.
assertDoesBotThrow(Executable executable)	executable을 실행한 결과로 익셉션이 발생하지 않는지 검사한다.

경우에 따라 일단 모든 검증을 실행하고 그중에 실패한 것이 있는지 확인하고 싶을 때가 있다. 이럴때 사용할 수 있는 것이 assertAll() 메서드이다. 다음은 assertAll() 메서드의 사용 예이다.

assertAll(
        () -> assertEquals(3,5/2),
        () -> assertEquals(4,2*2),
        () -> assertEquals(6,11/2)
);

테스트 라이프 사이클

@BeforeEach 애노테이션과 @AfterEach 애노테이션

jUnit은 각 테스트 메서드마다 다음 순서대로 코드를 실행한다.

테스트 메서드를 포함한 객체 생성
(존재하면) @BeforeEach 애노테이션이 붙은 메서드 실행
@Test 애노테이션이 붙은 메서드 실행
(존재하면) @After 애노테이션이 붙은 메서드 실행

public class LifecycleTest {

    public LifecycleTest(){
        System.out.println("new LifecycleTest");
    }

    @BeforeEach
    void setUp(){
        System.out.println("setUp");
    }

    @Test
    void a(){
        System.out.println("A");
    }

    @Test
    void b(){
        System.out.println("B");
    }

    @AfterEach
    void tearDown(){
        System.out.println("tearDown");
    }

}

결과

new LifecycleTest
setUp
A
tearDown
new LifecycleTest
setUp
B
tearDown

@BeforEach : 테스트를 실행하는데 필요한 준비 작업을 할 때 사용한다.

@AfterEach : 테스트를 실행한 후에 정리할 것이 있을 때 사용한다.

BeforeAll 애노테이션과 AfterAll 애노테이션

@BeforeAll : 정적 메서드에 붙이는데 이 메서드는 클래스의 모든 테스트 메서드를 실행하기 전에 한 번 실행된다.

@AfterAll : 클래스의 모든 테스트 메서드를 실행한 뒤애 실행된다. 이 역시 정적 메서드에 적용한다.

테스트 메서드간 실행 순서 의존과 필드 공유하지 않기

각 테스트 메서드는 서로 독립적으로 동작해야한다. 한 테스트 메서드의 결과에 따라 다른 테스트 메서드의 실행 결과가 달라지면 안 된다. 그런 의미에서 테스트 메서드가 서로 필드를 공유한다거나 실행 순서를 가정하고 테스트를 작성하지 말아야한다.

추가 애노티에션 : @DisplayName, @Disabled

@DisplayName : 테스트에 표시 이름을 붙일 수 있다.

@Disabled : 특정 테스트를 실행하지 않고 싶을 때 사용한다.

모든 테스트 실행 명령어

mvn test (래퍼를 사용하는 경우 mvnw test)

gradle test (래퍼를 사용하는 경우 gradlew test)

5주차 - JUnit 5 기초 - 한규범 · Issue #49 · GDSC-MYONGJI/22-23-TDD-Study

⭐ Chapter 5. JUnit 5 기초 JUnit 5 모듈 구성, 애노테이션과 메서드들과 라이프 사이클 등을 이해하고 테스트 코드를 더 능숙하게 작성할 수 있도록 한다. JUnit 5에 대해 알아보고, 숙지하기 Chap 5의 내

github.com

Reference.

테스트 주도 개발 시작하기 - YES24

www.yes24.com

[TDD] 기능 명세 ∙ 설계

큐범 — Fri, 20 Jan 2023 14:17:38 +0900

기능 명세

개발자는 코드를 작성하고 빌드하여 이를 사용자가 사용할 수 있게 배포한다. 설계는 기능 명세로부터 시작한다. 스토리보드를 포함한 다양한 형태의 요구사항 문서를 이용해서 기능 명세를 구체화한다. 기능 명세를 구체화하는 동안 입력과 결과를 도출하고 이렇게 도출한 기능 명세를 코드에 반영한다. 기능 명세의 입력과 결과를 코드에 반영하는 과정에서 기능의 이름, 파라미터, 리턴 타입 등이 결정된다.

설계 과정을 지원하는 TDD

TDD에서 가장 중요한 것을 테스트 코드를 먼저 작성한다는 점이다. 리턴 타입과 파라미터 타입에 대해서 고민은 곧 설계 과정이다. 타입의 이름을 정의하고 타입이 제공할 기능을 결정하는 것은 기본 적인 설계 행위이다. TDD 자체가 설계는 아니지만, TDD를 하다 보면 테스트 코드를 작성하는 과정에서 일부 설계를 진행하게 된다.

이름

이름은 설계에서 매우 중요하다. 설계 과정에서 구현하는 기능을 정확하게 표현하는 이름을 사용한 것 만큼 중요한 것은 없다. 잘못 지은 이름은 두고두고 개발자를 속인다. 테스트 코드는 시작부터 이름을 고민하게 만든다. 이 순간은 그래서 중요하다. 시간이 다소 걸리더라도 알맞은 이름을 찾아야 한다. 이름을 고민하는 시간을 아까워하지 말자.

필요한 만큼 설계하기

TDD는 테스트를 통과할 만큼만 코드를 작성한다. 필요한 것으로 예측해서 미리 코드를 만들지 않는다. 유연한 설계는 필요한 시점에 추가하고 설계가 불필요해지는 것을 방지한다.

기능 명세 구체화

모호한 상황을 만나면 이를 구체적인 예로 바꾸어 테스트 코드에 반영한다. 즉 테스트 코드는 예를 이용한 구체적인 명세가 된다. 구체적인 예는 개발자가 요구사항을 더 잘 이해할 수 있도록 만든다. 복잡한 로직을 구현하는 것은 결국 개발자 이므로 개발자는 최대한 예외적인 상황이나 복잡한 상황에 해당하는 구체적인 예를 끄집어내야 한다. 이를 위한 가장 좋은 방법은 담당자와 대화를 하는 것이다.

4주차 - TDD ∙ 기능 명세 ∙ 설계 - 한규범 · Issue #40 · GDSC-MYONGJI/22-23-TDD-Study

#37 ⭐ Chapter 4. TDD ∙ 기능 명세 ∙ 설계 설계하고 정의하는 과정을 TDD와 함께 정리해본다. 기능 명세, 설계 및 구체화 과정 이해하기 Chap 4의 내용을 개인 기술 블로그에 정리한 후 자신의 issue에 c

github.com

Reference.

테스트 주도 개발 시작하기 - YES24

www.yes24.com

[TDD] 테스트 코드 작성 순서

큐범 — Fri, 13 Jan 2023 21:49:51 +0900

테스트 코드 작성 순서

쉬운 경우에서 어려운 경우로 진행
예외적인 경우에서 정상인 경우로 진행

초반에 복잡한 테스트부터 시작하면 안되는 이유

초반부터 다양한 조합을 검사하는 복잡한 상황을 테스트로 추가하면 해당 테스트를 통과시키기 위해 한 번에 구현해야 할 코드가 많아진다.

구현하기 쉬운 테스트부터 시작하기

가장 구현하기 쉬운 경우부터 시작하면 빠르게 테스트를 통과시킬 수 있다. 보통 수 분에서 십여분 이내에 구현을 완료해서 테스트를 통과시킬 수 있을 만큼 쉬운 것을 선택한다.

예외상황을 먼저 테스트해야 하는 이유

예외상황을 전혀 고려하지 않은 코드에 예외 상황을 반영하려면 코드의 구조를 뒤집거나 코드 중간에 예외 상황을 처리하기 위해 조건문을 중복해서 추가하는 일이 벌어진다.

완급조절

정해진 값을 리턴
값 비교를 이용해서 정해진 값을 리턴
다양한 테스트를 추가하면서 구현을 일반화

뻔한 구현이라도 위 단계를 거쳐서 연습하는 것과 바로 구현하는 것에는 차이가 있다. 단계적으로 나아가는 연습을 하지 않는 개발자는 조금만 구현이 떠오르지 않아도 진전을 이루지 못하고 막혀 있거나 한 번에 많은 코드를 구현하려고 시도하다 구현에 실패하게 된다. 중요한 것은 테스트 - 구현 - 확인이다.

구현코드에 대해서 분리하고 생각해내며 코드를 작성하는 것을 연습해야한다. 한번에 많은 구현을 하려는 것은 버그를 야기한다.

지속적인 리팩토링

테스트를 통과한 뒤에는 적당한 후보가 보이면 리팩토링을 진행한다.

테스트 작성 순서 연습

매달 비용을 지불해야 사용할 수 있는 유료 서비스를 가정한다.

서비스를 사용하려면 매달 1만원을 선불로 납부한다. 납부일 기준으로 한 달 뒤가 서비스 만료일이 된다.
2개월 이상 요금을 납부할 수 있다.
10만원을 납부하면 서비스를 1년 제공한다.

다음 테스트를 추가하기 전에 리팩토링

메서드의 파라미터 개수가 세 개 이상이면 객체로 바꿔 한 개로 줄이는 것을 고려해야한다.

시작이 안 될 때는 단언부터 고민

테스트 코드를 작성하다 보면 시작이 잘 안될때가 있다. 이럴땐 검증하는 코드부터 장성하기 시작하면 도움이 된다.

구현이 막히면

TDD를 하다 구현이 막힐 때가 있다. 과감하게 코드를 지우고 미련없이 다시 시작한다. 어떤 순서로 테스트 코드를 작성했는지 돌이켜보고 순서를 바꿔서 다시 진행한다.

쉬운 테스트, 예외적인 테스트
완급조절

3주차 - 테스트 코드 작성 순서 - 한규범 · Issue #25 · GDSC-MYONGJI/22-23-TDD-Study

⭐ Chapter 3. 테스트 코드 작성 순서 어떤 테스트로 시작해야 하는지, 우선시 되어야 하는 테스트는 무엇인지를 공부하고 완급 조절을 통해 TDD에 보다 능숙해질 수 있도록 한다. 테스트 작성 순서

github.com

테스트 주도 개발 시작하기 - YES24

www.yes24.com

[TDD] 시작하기

큐범 — Fri, 6 Jan 2023 02:39:21 +0900

TDD, 즉 테스트 주도 개발(Test-driven Development)

테스트부터 시작한다. 구현을 먼저하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그 다음에 구현한다.

TDD 예: 암호 검사기

검사할 규칙

길이가 8글자 이상
0부터 9사이의 숫자를 포함
대문자 포함

등급

3개의 규칙을 충족하면 암호는 강함
2개의 규칙을 충족하면 암호는 보통
1개의 규칙을 충족하면 암호는 약함

assertEquals(기댓값,결과값);

테스트 코드 작성

첫 번째 테스트 - 모든 규칙을 충족하는 경우

public enum PasswordStrength {
	INVALID,NORMAL,STRONG
}

@Test
void meetsAllCriteria_Then_Strong(){
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("ab12!@AB");
    assertEquals(PasswordStrength.STRONG, result);
    PasswordStrength result2 = meter.meter("abc1!Add");
    assertEquals(PasswordStrength.STRONG, result2);
}

두 번째 테스트 - 길이만 8글자 미만이고 나머지 조건은 충족하는 경우

@Test
void meetsOtherCriteria_except_for_Length_Then_Normal(){
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("ab12!@A");
    assertEquals(PasswordStrength.NORMAL,result);
    PasswordStrength result2 = meter.meter("Ab12!c");
    assertEquals(PasswordStrength.NORMAL,result2);
}

세번째 테스트 - 숫자를 포함하지 않고 나머지 조건은 충족하는 경우

@Test
void meetsOtherCriteria_except_for_number_The_Normal(){
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("ab!@ABqwer");
    assertEquals(PasswordStrength.NORMAL,result);
}

코드 정리 - 중복 제거

위의 중복코드를 제거하면 첫 번째 예시 기준으로 다음과 같은 코드가 된다.

public class PasswordStrengthMeterTest {

    private PasswordStrengthMeter meter = new PasswordStrengthMeter();

    @Test
    void meetsAllCriteria_Then_Strong(){
        PasswordStrength result = meter.meter("ab12!@AB");
        assertEquals(PasswordStrength.STRONG, result);
        PasswordStrength result2 = meter.meter("abc1!Add");
        assertEquals(PasswordStrength.STRONG, result2);
    }
}

다음 중복 코드를

PasswordStrength result = meter.meter("ab12!@AB");
assertEquals(PasswordStrength.STRONG, result);

아래와 같이 메서드를 생성해

private void assertStrength(String password, PasswordStrength expStr){
    PasswordStrength result = this.meter.meter(password);
    assertEquals(expStr,result);
}

아래와 같이 중복 코드를 제거한다.

@Test
void meetsAllCriteria_Then_Strong(){
    assertStrength("ab12!@AB",PasswordStrength.STRONG);
    assertStrength("abc1!Add",PasswordStrength.STRONG);
}

@Test
void meetsOtherCriteria_except_for_Length_Then_Normal(){
    assertStrength("ab12!@A",PasswordStrength.NORMAL);
    assertStrength("Ab12!c",PasswordStrength.NORMAL);
}

@Test
void meetsOtherCriteria_except_for_number_The_Normal(){
    assertStrength("ab!@ABqwer",PasswordStrength.NORMAL);
}

주의할 점 : 중복을 제거 이후에도 꼭 테스트 코드를 실행해보고 무분별한 제거는 가독성을 떨어뜨릴 수 있다.

네 번째 테스트: 값이 없는 경우

@Test
void nullInput_Then_Invalid(){
    assertStrength(null,PasswordStrength.INVALID);
}

@Test
void emptyInput_Then_Invalid(){
    assertStrength("",PasswordStrength.INVALID);
}

아래와 같은 검증을 추가해준다.

if (s == null || s.isEmpty()) return PasswordStrength.INVALID;

다섯번째 테스트: 대문자를 포함하지 않고 나머지 조건을 충족하는 경우

@Test
void meetsOtherCriteria_except_for_Uppercase_Then_Normal(){
    assertStrength("ab12!@df",PasswordStrength.NORMAL);
}

아래와 같은 검증을 추가해준다.

private boolean meetsContainingUppercaseCriteria(String s) {
    for (char ch : s.toCharArray()){
        if (Character.isUpperCase(ch)){
            return true;
        }
    }
    return false;
}

여섯 번째 테스트: 길이가 8글자 이상인 조건만 충족하는 경우

@Test
void meetsOnlyLengthCriteria_Then_Weak(){
    assertStrength("abdefghi",PasswordStrength.WEAK);
}

meter함수의 내용을 다음과 같이 수정한다.

public PasswordStrength meter(String s) {
    if (s == null || s.isEmpty()) return PasswordStrength.INVALID;
    boolean lengthEnough = s.length() >= 8;
    boolean containsNum = meetsContainingNumberCriteria(s);
    boolean containsUpp = meetsContainingUppercaseCriteria(s);
    if(!lengthEnough){
        return PasswordStrength.NORMAL;
    }
    if (!containsNum) return PasswordStrength.NORMAL;
    if (!containsUpp) return PasswordStrength.NORMAL;
    return PasswordStrength.STRONG;
}

위의 코드를 보면 if 절의 위치를 두 로직을 구분하기 위해 이동하였다.

개별 규칙을 검사하는 로직
규칙을 검사한 결과에 따라 암호 강도를 계산하는 로직

일곱 번째 테스트: 숫자 포함 조건만 충족하는 경우

@Test
void meetsOnlyNumCriteria_Then_Weak(){
    assertStrength("12345",PasswordStrength.WEAK);
}

meter함수의 내용을 다음과 같이 수정한다.

if (!lengthEnough && containsNum && !containsUpp)
    return PasswordStrength.WEAK;

여덟 번째 테스트: 대문자 포함 조건만 충족하는 경우

@Test
void meetsOnlyUpperCriteria_Then_Weak(){
    assertStrength("ABZEF", PasswordStrength.WEAK);
}

meter함수의 내용을 다음과 같이 수정한다.

if (!lengthEnough && !containsNum && containsUpp)
    return PasswordStrength.WEAK;

코드정리: meter() 메서드 리팩토링

전체 리팩토링 이전

public class PasswordStrengthMeter {
    public PasswordStrength meter(String s) {
        if (s == null || s.isEmpty()) return PasswordStrength.INVALID;
        boolean lengthEnough = s.length() >= 8;
        boolean containsNum = meetsContainingNumberCriteria(s);
        boolean containsUpp = meetsContainingUppercaseCriteria(s);

        if (lengthEnough && !containsNum && !containsUpp)
            return PasswordStrength.WEAK;
        if (!lengthEnough && containsNum && !containsUpp)
            return PasswordStrength.WEAK;
        if (!lengthEnough && !containsNum && containsUpp)
            return PasswordStrength.WEAK;

        if(!lengthEnough){
            return PasswordStrength.NORMAL;
        }
        if (!containsNum) return PasswordStrength.NORMAL;
        if (!containsUpp) return PasswordStrength.NORMAL;
        return PasswordStrength.STRONG;
    }

    private boolean meetsContainingUppercaseCriteria(String s) {
        for (char ch : s.toCharArray()){
            if (Character.isUpperCase(ch)){
                return true;
            }
        }
        return false;
    }

    private boolean meetsContainingNumberCriteria(String s) {
        for (char ch : s.toCharArray()){
            if(ch >= '0' && ch <= '9'){
                return true;
            }
        }
        return false;
    }
}

WEAK 리팩토링

리팩토링 이전

if (lengthEnough && !containsNum && !containsUpp)
    return PasswordStrength.WEAK;
if (!lengthEnough && containsNum && !containsUpp)
    return PasswordStrength.WEAK;
if (!lengthEnough && !containsNum && containsUpp)
    return PasswordStrength.WEAK;

리팩토링 이후

int metCounts = 0;
boolean lengthEnough = s.length() >= 8;
if (lengthEnough) metCounts++;
boolean containsNum = meetsContainingNumberCriteria(s);
if (containsNum) metCounts++;
boolean containsUpp = meetsContainingUppercaseCriteria(s);
if (containsUpp) metCounts++;

if (metCounts == 1) return PasswordStrength.WEAK;

NORMAL 리팩토링

리팩토링 이전

if(!lengthEnough){
    return PasswordStrength.NORMAL;
}
if (!containsNum) return PasswordStrength.NORMAL;
if (!containsUpp) return PasswordStrength.NORMAL;

리팩토링 이후

if (metCounts == 2) return PasswordStrength.NORMAL;

전체 리팩토링

    public PasswordStrength meter(String s) {
        if (s == null || s.isEmpty()) return PasswordStrength.INVALID;
        int metCounts = 0;
        if (s.length() >= 8) metCounts++;
        if (meetsContainingNumberCriteria(s)) metCounts++;
        if (meetsContainingUppercaseCriteria(s)) metCounts++;

        if (metCounts == 1) return PasswordStrength.WEAK;
        if (metCounts == 2) return PasswordStrength.NORMAL;

        return PasswordStrength.STRONG;
    }

아홉 번째 테스트: 아무 조건도 충족하지 않는 경우

@Test
void meetsNoCriteria_Then_Weak(){
    assertStrength("abc",PasswordStrength.WEAK);
}

meter함수의 내용을 다음과 같이 수정한다.

if (metCounts <= 1) return PasswordStrength.WEAK;

코드정리: 코드 가독성 개선

int metCounts = 0;
if (s.length() >= 8) metCounts++;
if (meetsContainingNumberCriteria(s)) metCounts++;
if (meetsContainingUppercaseCriteria(s)) metCounts++;

public PasswordStrength meter(String s) {
        if (s == null || s.isEmpty()) return PasswordStrength.INVALID;
        int metCounts = getMetCriteriaCounts(s);

        if (metCounts <= 1) return PasswordStrength.WEAK;
        if (metCounts == 2) return PasswordStrength.NORMAL;

        return PasswordStrength.STRONG;
    }

    private int getMetCriteriaCounts(String s) {
        int metCounts = 0;
        if (s.length() >= 8) metCounts++;
        if (meetsContainingNumberCriteria(s)) metCounts++;
        if (meetsContainingUppercaseCriteria(s)) metCounts++;
        return metCounts;
    }

이제 다른 개발자가 보더라도 다음과 같은 코드를 읽을 수 있다.

암호가 Null이거나 빈 문자열이면 암호 강도는 INVALID이다.
충족하는 규칙 개수를 구한다.
충족하는 규칙 개수가 1개 이하면 암호 강도는 WEAK이다.
충족하는 규칙 개수가 2개면 암호 강도는 NORMAL이다.
이 외 경우(즉 충족하는 규칙 개수가 2개보다 크면) 암호 강도는 STRONG이다.

TDD 흐름

테스트 - 코딩 - 리팩토링 - 테스트를 반복한다.

TDD는 테스트를 먼저 작성하고 테스트를 통과시킬 만큼 코드를 작성하고 리팩토링으로 마무리 하는 과정을 반복한다.

아래의 1번부터 4번을 반복한다.

기능을 검증하는 테스트를 작성
작성한 테스트를 통과하지 못하면 통과하는 코드를 작성
작성한 코드를 리팩토링
리팩토링 후 다시 테스트 실행

레드-그린-리팩터

TDD 사이클을 레드(Red)-그린(Green)-리팩터(refactor)로 부르기도 한다.

레드는 실패하는 테스트를 의미한다. 레드는 테스트 코드가 실패하면 빨간색을 이용해서 실패한 테스트를 보여주는데서 비롯했다.

그린은 성공한 테스트를 의미한다.

리팩터는 리팩토링 과정을 의미한다.

Reference.

테스트 주도 개발 시작하기 - YES24

www.yes24.com

프로젝트 회고 [명식이 - 명지대의 식사를 책임지다! ver1.0 ]

큐범 — Wed, 4 Jan 2023 15:39:09 +0900

개발기간 2022.10 ~ ING

플랫폼 Android, IOS

참여인원 서버 1명, AOS 1명, IOS 1명, 디자이너 2명 (총 5명)

담당역할 PM, 기획, Back-end, DevOps

명식이는 "명지대학교의 식사를 책임지다!"를 슬로건을 가지고 출발한 앱이다. 첫 시작은 인문 캠퍼스 공사를 거치며 학생식당이 신규로 들어오며 기존의 학식메뉴를 제공해주는 에브리타임에서는 제공하지 않고 학생들은 직접 학생식당에 가서 사진을 찍고 이를 에브리타임 커뮤니티에서 공유하여 많은 학생들이 불편함을 느끼는 것을 들었다. 안드로이드 친구와 학생식당 메뉴를 알려주는 앱을 만들자는 의견에서 시작했다. 시작을 하기로 마음을 먹고 1주일 만에 개발을 마치고 배포를 진행했다.

배포를 진행하고 커뮤니티와 오프라인 홍보물을 부착하여 유저가 900명까지 모이기 시작하며 실제 배포를 하는 개발자의 느낌을 느끼며 내가 개발한 것에 성취감을 느끼며 고맙다는 학생들의 이야기를 들을 때면 보람을 크게 느꼈다. 해당 프로젝트를 진행하며 내가 배운 것, 개선사항을 포스핑하기로 했다.

배운것

1. 실제 서비스 운영 경험

실제 서비스 운영 해본 다는 것은 단지 개발을 해서 커밋을 하고 PR을 날리는 것이 아니고 상상 이상으로 떨리는 것이었다. 당장 내 PR로 인해서 수 백명의 유저들이 즉각적인 불편함을 느낀다는 것이 부담스러웠으며 CICD 파이프라인이 잘못되는 것은 아닐지 걱정이 많았다. 걱정이 많을 수록 고민은 많이 했고 고민은 나에게 성장을 가져다줬다. 걱정은 Dev(개발), Prod(배포) 서버를 분리하게 하였고 DB 또한 분리하였으며 브랜치별 CICD 전략 구성하여 main 브랜치에 PR이 발생할 경우, prod서버에 배포가 되고 develop 브랜치의 경우, dev서버에 배포가 진행되도록 하였다.

2. 인터뷰

감사하게도 학생회에서 서면 인터뷰를 진행 요청을 받고 인터뷰를 진행하였다. 내가 개발한 것을 비개발자와 개발자들에게 글로 설명해야하는 부분을 배우게 되었다. 예를들어 Server를 Dev와 Prod로 분리한 것과 CICD 구축한 것을 설명하는 것을 개발자들을 위해 Spring yml설정 파일을 통해 매개변수로 Dev와 Prod를 입력받고 이에 해당하는 DB서버에 접속하다록 구축하였다고 설명하고 CICD를 Jenkins에서 gradle을 통해 빌드하여 jar파일을 도커로 이미지로 만들어 도커허브로 배포서버로 간다는 것을 설명하였다. 여기서 비개발자들에게는 해당 기술이 서비스에 어떤 방향으로 유저에게 전달되는지를 설명하였다. CICD를 구축하여 긴급하게 수정할 오류가 있을 경우, 기존의 반영 속도보다 더 빠르게 반영되는 방식이라고 설명하였다.

3. 소규모 팀의 힘

이전의 진행한 프로젝트를 보면 서버를 개인 프로젝트 외에는 가장 소규모로 진행된 프로젝트였다. 소규모로 진행되기에 기민성이 올라가며 팀은 개발 및 디자인에 있어서 즉각적인 결과물이 보였으며 배포 이후에도 가장 많이 수정작업이 이루어져 1.9.1버전까지 업데이트를 진행했다. 배포 이후에도 유지보수를 진행한 첫 프로젝트였다. 유지보수를 하기에 이후에 수정을 고려한 코드를 작성하며 주기적인 회의를 거치며 개발을 짧은 시간에 큰 성과를 가져왔다.

개선사항

1. 로드 밸런스

명식이 서버에는 로드 밸런스를 적용하지 못했다. 그 말은 Prod서버에서 문제가 발생할 경우, 서비스의 이용에 차질이 바로 이어진다는 것이다. 이것이 늘 걱정이었다. 물론 Jenkins에서 파이프라인을 구축하여 문제가 생길 경우 이전의 배포로 이루어지지만, Jenkins의 생명주기는 배포 서버에서 문제가 생기는 것은 막지 못한다. 다행스럽게 서비스를 런칭하는 동안 Prod서버에 문제가 생긴 적은 없으나 로드 밸런스를 적용했더라면 더욱 안정적인 서비스를 제공할 수 있었지 않을 가 하는 아쉬움이 있다.

다음 버전에는 Nginx를 적용하여 로드 밸런스를 적용할 예정이다.

2. 모니터링의 부재

모니터링은 직접 로그를 확인하거나, AWS에서 직접 제공하는 모니터링을 활용하였다. 모니터링을 못하는 것이 이렇게 불편한 일인줄 몰랐다. 다른 프로젝트에서 모니터링에 대해서 필요성을 느끼지 못했지만 실제 유저가 있는 서비스에서 모니터링은 매우 중요한 요소였다. 모니터링의 데이터를 의사결정에 큰 지표가 되었으며 개발 팀이 언제 배포를 이루어지게 할 것인지, 특정 시간에 Scale-out할 것인지 등 다양한 의사결정에 활용할 수 있을 것 같다.

다음 버전에는 prometheus grafana를 사용하여 모니터링과 시각화를 적용할 예정이다.

3. 조회를 더욱 빠르게는 못했을 까?

대부분의 유저는 간단하게 금일 메뉴만 확인 할 것으로 예상된다. 그렇다면, 금일 메뉴만을 캐시 메모리(Redis)에 넣고 관리를 했다면 더욱 빠르게 조회가 가능하지 않았을까? 하는 아쉬움이 있다.

Redis에 대해서 다양한 테스트를 거치고 적용을 검토해봐야겠다.

App DownLoad Link

AppStore

‎명식이 : 명지대의 식사를 책임지다!

‎주요 기능 안내 1. '오늘의 학식' 메뉴 일간 / 주간 조회 - 메뉴을 일 단위 / 주 단위로 조회가 가능합니다. - 메뉴에 대하여 맛있어요 / 맛없어요 평가를 선택할 수 있습니다. 2. 명지 맛집 - 명지

apps.apple.com

PlayStore

명식이 : 명지대의 식사를 책임지다! - Google Play 앱

명지대학교 인문캠퍼스 학식 식단표와 주변 식당, 카페 정보를 제공합니다

play.google.com

GitHub

GitHub - MYONGSIK/Server: 명식이 : 명지대의 식사를 책임지다!

명식이 : 명지대의 식사를 책임지다! Contribute to MYONGSIK/Server development by creating an account on GitHub.

github.com

Skill Stack

Infra Structure

CICD

[gRPC] gRPC 사용후기

큐범 — Sat, 31 Dec 2022 14:00:47 +0900

이번 22-2 클라이언트 서버 프로그래밍 수업에서 gRPC 기술을 적용하여 수강신청 시스템을 구축하였다.

해당 포스터에서는 gRPC를 사용하면서 느낀 사용후기와 깃을 포스팅하겠다.

사용후기

우선, 수업에서는 RMI(자바 원격 함수 호출)로 메서드를 호출하는 기술인데 같은 호출 기술인 gRPC로 진행하였다. 내가 진행한 프로젝트는 수강신청 시스템 구축으로 아래와 같은 프로세스간 통신을 한다.

내가 느낀 장점

통신

프로세스간 통신은 현재 기술 발전의 핵심인 분산에서 관심있는 분야이다. 서비스를 좀 더 안정적으로 배포하기 위해서 서비스를 나누는데 필요한 것이 통신이다. gRPC는 통신을 매우 효율적으로 할 수 있게 해준다. proto3버전을 사용하면 넓은 언어 호환성과 xml, json에 비해 빠른 속도와 가벼운 데이터 크기 이 점에서 통신의 속도와 호환성에 보장받을 수 있었다.

공식문서

공식문서가 매우 잘되어있었다. 거기서 써져있는 코드를 따라치면 자동으로 실행해 볼 수 있는 코드가 제공되었고 해당 기술에 대해서도 gRPC뿐 아니라 RPC의 기술에서 어떤 점이 다른지, 왜 나오게 되었는지를 잘 설명해주었다.

내가 느낀 단점

사례

gRPC를 사용하면서 많은 오류를 접했지만 검색할때 다른 기술에 비해(스프링, DB 등) 많은 사례가 없는 것이 아쉬웠다. 이는 시간이 해결해줄 것이라 생각한다. 그래서 더욱 공식문서를 들여다보게 되었다.

proto 파일의 수정

위의 Client, Server, Data 프로젝트에는 각각의 proto 파일이 존재하는데 어느 한곳에서라도 proto 파일의 변경이 가해지면 다른 곳의 proto 파일도 최신화를 해줘야한다는 점이 아쉬웠다.

GitHub - Qbeom0925/grpc-enrolmentSystem: gRPC를 이용한 수강신청 시스템 구축

gRPC를 이용한 수강신청 시스템 구축. Contribute to Qbeom0925/grpc-enrolmentSystem development by creating an account on GitHub.

github.com

[gRPC] gRPC 특징, 장단점

큐범 — Fri, 30 Dec 2022 02:35:10 +0900

gRPC 소개

gRPC는 protocol buffer와 RPC를 사용한다.

2022.12 당시, IDL로는 proto3를 사용하며 호환하는 언어로는 Java, C++, Python, Java Lite, Ruby, JavaScript, Objective-C, C#을 호환한다.

gRPC의 핵심은 분산으로 클라이언트 응용 프로그램을 서버에서 함수를 원격 호출할 수 있어 MSA(Micro Service Architecture)를 구현하기 수월하다. gRPC 서버에서는 Stub을 통한 호출을 처리할 수 있다.

gRPC 특징

1. Protocol Buffere

gRPC는 IDL을 Protocol Buffere(.proto)를 사용한다.

2. Service definition

service EducationService {
	rpc basicRead(BasicRequest) returns (BasicResponse){}
}

message BasicRequest {
  string message = 1;
}

message BasicResponse {
  string message = 1;
  string statusCode = 2;
  string statusMessage = 3;
}

3. Channels

gRPC channel은 특정 host와 port에 대해 gRPC서버에 대한 연결을 제공한다.

4. RPC Life Cycle

단항(Unary) RPC

a. 클라이언트가 Stub메서드를 호출하면 이 호출에 대한 클라이언트의 메타데이터를 RPC가 호출되었음을 알린다. 서버는 호출을 확인하고 초기 메타데이터를 바로 되돌려 보내거나 클라이언트의 요청 메시지를 기다릴 수 있다.

b. 서버가 클라이언트의 요청 메시지를 받으면 응답을 생성하고 채우는 데 필요한 모든 작업을 수행한다.

c. 그런 다음 응답은 상태 세부 정보 및 선택적인 후행 메타데이터와 함께 클라이언트에 반환된다.

d. 응답상태가 OK이면 클아이언트는 클라이언트 측에서 호출 응답 완료를 응답 받는다.

Server Streaming RPC

클라이언트 request 1번, 서버 Response 유지

서버가 클라이언트 요청에 대한 응답으로 메시지 스트림을 반환한다는 점을 제외하면 Unary RPC와 유사하다. 모든 메시지를 보낸 후 서버의 상태 세부 정보 및 선택적 메타데이터가 클라이언트로 전송된다. 이렇게 하면 서버측에서 처리가 완료되고 클라이언트는 서버의 모든 메시지를 받으면 된다.

Client Streaming RPC

클라이언트 request 1번, 서버 Response 1번

클라이언트가 단일 메시지 대신 서버에 미시지 스트림을 보낸다. 서버는 일반적으로 클라이언트의 모든 메시지를 수신한 후에 대개 단일 메시지로 응답한다.

Bidirectional streaming RPC

DEADLINE_EXCEEDED gRPC를 사용하면 클라이언트는 RPC가 오류로 종료되기 전에 RPC가 완료될 때까지 대기할 시간을 지정할 수 있다.

RPC termination

gRPC에서 클라이언트와 서버는 모두 호출의 성공 여부를 독립적이고 로컬에서 결정하므로 결론이 일치하지 않을 수 있다. 예를 들어 서버 측에서는 성공적으로 완료되었지만(“내 모든 응답을 보냈습니다!”) 클라이언트 측에서는 실패한 RPC가 있을 수 있다(“응답이 마감 시간 이후에 도착했습니다!”). 클라이언트가 모든 요청을 보내기 전에 서버가 완료를 결정할 수 있다.

Cancelling an RPC

클라이언트나 서버는 언제든지 RPC를 취소할 수 있다.

gRPC 장점

protocol buffer사용

protocol buffere는 IDL xml, json에 비해 데이터 크기가 작아 결과적으로 리소스 사용량을 줄여 응답시간을 줄일 수 있다.

xml, json으로도 변환하는 기능도 지원한다.

HTTP 2.0지원

HTTP1.1은 TCP연결 관련하여 비효율적인 연결방식을 HTTP2.0을 통해 서버푸시와 1.1버전 대비 효율적인 연결이 가능해졌다.

넓은 언어 호환성

현재 Java, Python, Objective-C, C++을 지원하고 proto3의 경우 Kotlin, Dart, Go, Ruby, C#을 추가적으로 지원한다.

분산 환경

최근의 개발 환경을 보면 핵심은 분산이다. 기존의 서비스를 분산하여 에러에 대해서 대처를 유연하게 대응하는 것이 중요한 시대이다. 이를 해결할 수 있는 것이 gRPC환경으로 분산환경 구축이 가능하다.

gRPC 단점

.proto파일에 대한 업데이트

gRPC로 연결되어 있는 서버 클라이언트에서 어느 한쪽에서라도 변경이 일어나면 proto파일을 업데이트 해야하는 단점이 있다.

Reference.

Introduction to gRPC

An introduction to gRPC and protocol buffers.

grpc.io

Core concepts, architecture and lifecycle

An introduction to key gRPC concepts, with an overview of gRPC architecture and RPC life cycle.

grpc.io

[gRPC] Protocol Buffere(proto3) 소개, 사용법

큐범 — Thu, 29 Dec 2022 00:13:31 +0900

Protocol Bufferes

구조화된 데이터를 직렬화 하기 위한 구글의 언어 중립적, 확장 가능한 메커니즘이다.

데이터를 한 번 구성하는 방법을 정의한 후에 특수 생성된 소스 코드를 사용하여 다양한 데이터 스트림과 다양한 언어를 사용하여 구조화된 데이터를 쉽게 쓰고 읽을 수 있다.

Protocol Buffere은 IDL로서 data structure를 정의한 다음, proto파일을 protocol buffere compiler를 통해 컴파일한다. 컴파일된 소스코드를 사용하여 데이터를 읽고 쓴다.

Protocol Bufferes는 현재 Java, Python, Objective-C, C++을 지원하고 proto3의 경우 Kotlin, Dart, Go, Ruby, C#을 추가적으로 지원한다.

Proto3

서버는 클라이언트로부터 응답(Response)를 하는데 거기서 대부분 들어가는 statusCode와 statusMwssage가 있습니다. 아래의 예시 코드를 통해서 다음과 같이 구성할 수 있습니다.

Code

syntax = "proto3";
option java_package = "com.grpc.education";
option java_multiple_files = true;
package education;

message BasicResponse {
  int32 userNum = 1;
  string statusCode = 2;
  string statusMessage = 3;
}

BasicResponse 메시지 선언에서 볼 수 있는 것은 메시지를 구성하는 데이터에 대해서 각각 선언을 해주는 형식을 가진다.

Field 특징

Field Types은 scalar types, enum, fild type선언이 가능하다.

각 field는 고유한 field 번호를 갖는다.

field 번호에 따라 다른 인코딩 방식 - 1~15 방식이 효율적이다.

1~15 1Byte
16~2047 2byte

Proto 장단점

Proto 장점

1. 데이터의 크기가 작다.

데이터의 크기가 작은 경우, 통신이 빠르다는 이점이 있다.

2. proto <-> json 전환 유틸을 지원한다.

3. xml비해 3~10배 작고 20~100배 빠르고 더 간결하고 덜 모호하고 더 쉬운 데이터 엑세스 클래스를 제공. <- 공식문서

Proto 단점

1. Proto 포맷에 대한 사전지식이 요구된다.

2. 바이트 형태로 인해서 가독성 저하된다.

Reference.

Protocol Buffers | Google Developers

Protocol buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data.

developers.google.com

[Clean Code] 1장 깨끗한 코드

큐범 — Wed, 28 Dec 2022 11:45:00 +0900

데이브 토마스 “깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다.”

마이클 페더스 “깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다.”

중복과 표현력에 신경써서 코드를 작성하자.

“중복줄이기, 표현 높이기, 초반부터 간단한 추상화 고려하기, 한 기능만 수행하라.”

프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다. 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다.

저자

우리는 저자다

@author필드는 저자를 소개한다. 저자가 있다는 것은 독자가 있다. 그리고 저제에게는 독자와 잘 소통할 책임이 있다. 우리는 새 코드를 짜면서 끊임없이 기존 코드를 읽는다. 그 말은 기존 코드가 읽기 쉬워야 쓸때 편하다는 것이다.

보이스카우트 규칙 “캠핑장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라”

체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.

지속적인 개선이야말로 전문가 정신의 본질이 아니던가?

내 생각

시간이 없어 급하게 짠 코드를 보고 새로운 코드를 짜는 것은 읽기 어렵기 때문에 다시 시간이 낭비가 된다. 여기서 모순이 발생한다. 시간이 없어 급하게 짠 코드가 시간을 더 없게 만드는 것이다. 우리는 코드를 짤 때 읽기 쉽게 쓰는 것이 가장 시간을 절약하는 것임을 알아야한다.

Reference.

Clean Code 클린 코드 - YES24

애자일 소프트웨어의 혁명적인 패러다임을 제시하는 책이다. 저자 로버트 마틴은 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제

www.yes24.com

[gRPC] gRPC 개념, RPC, IDL비교(XML, JSON, Protocol Buffer)

큐범 — Thu, 15 Dec 2022 22:05:36 +0900

gRPC란?

구글이 개발한 오픈 소스 원격 프로시저 호출 시스템(RPC)이다. 호출을 위해 TCP/IP 프로토콜과 HTTP2.0 프로토콜을 사용하고 IDL(Interface Definication Language)로 protocol buffer를 사용한다.

RPC(Remote Procedure call)란?

한 프로그램이 네트워크의 세부 정보를 이해하지 않고도 네트워크 안의 다른 컴퓨터에 있는 프로그램에서 서비스를 요청하는 프로토콜

Microsoft RPC 작동방식

HTTP 2.0

HTTP(Hypertext Transfer Protocol)는 웹 환경에서 사용되는 통신 프로토콜로 OSI 7 Layer에서 최상위인 Application Layer에서 사용한다.

HTTP에 대한 역사

[Network] HTTP(Stateful Stateless 차이, 비 연결성, 클라이언트 서버 구조 ...)

HTTP (HyperText Transfer Protocol) - 역사 HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X HTTP/1.0 1996년: 메서드, 헤더 추가 HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 RFC2068 (1997) -> RFC2616 (1999) ->

kbcoding.tistory.com

HTTP는 기본적으로 서버-클라이언트 구조를 따라 HTTP 프로토콜 통신을 위해서는 클라이언트는 서버로 Requst를 보내고 Response를 받는 형태를 갖는다.

HTTP 2.0은 한 Connection으로 동시 여러개 메시지를 주고받으며, 비동기적으로 1.1버전에 비해 효율적이다.

IDL(Interface Definition Language)

서버와 클라이언트가 정보를 저장하는 규칙이다.

XML(eXtensible Markup Langauge)

데이터를 정의하는 규칙을 제공하는 마크업언어로 다른 프로그래밍 언어와 달리 XML은 다체적으로 컴퓨팅 작업을 수행할 수 없다. 데이터를 저장하고 전달하기 위해 만들어졌다.

JSON(JavaScript Object Notation)

기존 XML의 가독성과 속도를 보완하여 등장한 것으로 key-value구조를 갖는다.

Protocol buffer(proto)

구조화된 데이터를 직렬화하는 방식으로 유선이나 데이터 저장을 목적으로 서로 통신할 프로그램을 개발할때 유용하다. 프로토콜 버퍼는 데이터를 이진수로 변환하는 특징이 있다. 그렇기에 다음과 같은 장점을 가진다.

1. 빠른 전송 속도

2. CPU 사용량 감소

3. 파일크기의 감소

4. XML대비 가독성이 좋다.

proto 코드 예시

syntax = "proto3";
option java_package = "com.grpc.education";
option java_multiple_files = true;
package education;

message EmptyRequest{
}

message BasicRequest {
  string message = 1;
}

message BasicResponse {
  string message = 1;
  string statusCode = 2;
  string statusMessage = 3;
}

gRPC

gRPC는 protocol buffer와 RPC를 사용한다.

2022.12 당시, IDL로는 proto3를 사용하며 호환하는 언어로는 Java, C++, Python, Java Lite, Ruby, JavaScript, Objective-C, C#을 호환한다.

gRPC의 핵심은 분산으로 클라이언트 으용 프로개름을 서버에서 함수를 원격 호출할 수 있어 MSA(Micro Service Architecture)를 구현하기 수월하다. gRPC 서버에서는 Stub을 통한 호출을 처리할 수 있다.

gRPC 구조

Reference.

Introduction to gRPC

An introduction to gRPC and protocol buffers.

grpc.io

RPC 작동 방식 - Win32 apps

RPC 도구는 클라이언트가 원격 서버 프로그램에 있는 프로시저를 직접 호출하는 것처럼 사용자에게 표시됩니다.

learn.microsoft.com

gRPC 1 - gRPC란?

배경지식 gRPC는 Google에서 개발한 RPC(Remote Procedure Call) 시스템입니다. 전송을 위해 TCP/IP 프로토콜과 HTTP 2.0 프로토콜을 사용하고 IDL(Interface Definition language)로 protocol buffer를 사용합니다. gRPC에 대

chacha95.github.io

What is the Difference between HTTP 1.2 and HTTP 2.0 versions? why should I care?

Well, this question is very basic, but many of us don't know what is the exact purpose, and why the name has changed and what might be the difference. Since, we all know HTTP is protocol that is widely used over internet, HTTP 1.

www.linkedin.com

[CS] 컴퓨터의 구성(Software, Hardware, SystemBus)

큐범 — Mon, 21 Nov 2022 20:51:18 +0900

컴퓨터의 구성

하드웨어( Hardware): 컴퓨터를 구성하는 기계적 장치
소프트웨어(Software) : 하드웨어의 동작을 지시하고 제어하는 명령어 집합

하드웨어(Hardware)

CPU(중앙처리장치) : 프로그램의 모든 정보를 처리하는 역할을 담당한다.

RAM(주기억 장치) : 프로그램 실행과 휘발성 데이터를 저장하는 공간

HDD,SDD(보조기억 장치) : 내장형 기억 장치로 비휘발성 데이터를 저장하는 공간

IO Device(마우스, 프린터, 모니터 등)

소프트웨어(Software)

시스템 소프트웨어(System Software) : OS, 로더, 장치 드라이버, 컴파일러

응용 소프트웨어(Application Software) : 크롬, 유튜브, 멜론 등

펌웨어(Firmware)

특정 하드웨어 장치에 포함된 소프트웨어로 소프트웨어를 읽어 실행하거나 수정이 가능한 장치를 뜻한다.

하드웨어의 제어와 구동을 담당하는 일종의 운영체제이다.

대부분의 펌웨어는 ROM, PROM에 저장된다.

예) 바이오스, 스마트폰, 가전 전자제품의 프로그램

하드웨어 구성

출처 : https://velog.io/@mee9204/컴퓨터의-구조

하드웨어의 구성은 각 화살표는 시스템 버스(SystemBus)라 한다.

중앙처리장치(Central Processing Unit, CPU)

컴퓨터는 인간을 형상화해서 만들어진 기계인데 CPU는 인간의 두뇌 역할을 담담한다. 주기억장치에서 프로그램의 명령과 데이터를 읽어 처리하고 명령어의 수행 순서를 제어한다. 중앙처리장치는 비교와 연산을 담당하는 ALU(산술 논리 장치)와 명령어의 해석과 실행을 담당하는 제어장치, 속도가 빠른데이터 기억 장소인 레지스터로 구성한다.

기억장치

프로그램, 데이터, 연산값 등을 저장하는 장치이다. 주기억장치와 보조기억장치로 나눠지며

주기억 장치는 RAM, ROM으로 실행중인 프로그램과 같은 프로그램에 같은 프로그램에 필요한 데이터를 일시적으로 저장해 휘발성 특징을 가지고 있다. 보조기억장치는 HDD, SDD 등을 의미하며 주기억장치에 비해 속도성은 떨어지지만 비휘발성으로 영구적인 보관이 가능하다.

입출력장치

입력, 출력 장치로 나뉘어진다.

입력장치는 컴퓨터 내부로 값을 입력하는 장치로 키보드, 마우스가 대표적이다.

출력장치는 컴퓨터 외부로 값을 표현하는 장치로 프린터, 모니터, 스피커가 대표적이다.

시스템 버스

출처 : Wikipedia - System Bus

각 구성 요소가 다른 구성 요소로 데이터를 보낼 수 있도록 통로가 된다. 용도에 따라 데이터 버스, 주소 버스, 제어 버스로 나뉘어진다.

주소 버스(Address Bus)

메모리의 주소나 I/O Unit의 포트 번호를 전달한다.
중앙처리장치가 주기억장치나 입출력장치로 기억장치 주소를 전달하는 통로로 '단방향'버스이다.

데이터 버스(Data Bus)

데이터를 전달하는 통로
각 구성요소(CPU, Memory, I/O Unit)는 양방향으로 데이터 전달이 가능한 버스를 사용한다.

제어버스(Control Bus)

제어 신호 전달한다.
Read/Write 신호를 전달한다.
각 구성요소(CPU, Memory, I/O Unit)는 양방향으로 데이터 전달이 가능한 버스를 사용한다.

[DB] 동시성 이슈(Concurrency Issue)

큐범 — Tue, 15 Nov 2022 01:11:06 +0900

동시성(Concurrency)

동시성은 운영체제에서 사용되는 용어로 동시에 실행되는 것처럼 보이는 것으로 논리적인 개념으로 싱글코어와 멀티코어에서 가능하다. 해당 글에서 사용되는 DB에서의 여러개의 스레드(요청)이 동시에 같은 주소의 값(데이터)을 참조하여 접근 및 수정하는 것을 의미한다.

예를들어, 트랜젝션 A가 알렉스라는 이름을 읽고 트랜젝션 B가 밥을 추가해 같은 트랜젝션에서 1번의 리드와 3번의 리드가 다른 것을 확인한다. 유령 레코드가 나타나는 현상으로 이를 팬텀리드(Phantom Read)라 한다.

일반적으로 문제 해결 방식에는 두 가지 방법이 존재한다.

1. 비관적 동시성 제어

데이터를 비관적으로 바라보며 다른 요청에 의해서 수정될 가능성을 염두하여 Lock을 거는 방식이다.

데이터베이스의 데이터를 잠그고 다른 사용자가 동일한 잠금을 보유하지 못하도록 한다. 이는 데이터베이스로 통하는 문을 하나만 놔두고 하나의 트랜젝션이 DB에 접근할 동안 다른 트랜젝션이 접근을 못하게 하는 방식이다.

장점

구현이 간단하다. 데이터 서버는 잠금을 지원하기 때문에 제어를 쉽게 구현할 수 있다.
매우 간단하다.

단점

확장성이 좋지 않다.
교착 상태(Dead Lock)에 빠지기 쉽다.
- 예를들어, 치킨집 지점관리자 1은 A지점 데이터에 대해서 수정을 하고 2는 B지점 데이터에 수정을한다. 수정을 하는 동안 각각의 A, B지점에 데이터는 '잠금'상태에 들어간다. 이후 관리자 1은 B를 2는 A를 수정하기 원하는데 '잠금' 상태로 인하여 각각 원하는 다음 지점에 대해서 기다리로 결정하면 교착상태가 발생한다.
잠금이 오래 지속될 수 있다.

적용방식

1. DB에서 제공하는 데이터 Lock수준을 높인다.

2. select for update 활용하여 Lock을 잡는다.

3. transaction의 write Lock(Exclusive Lock)을 사용한다. DB는 데이터를 수정할 경우, write lock이 발동되고 트랜젝션이 끝날때까지 Lock은 유지된다.

2. 낙관적 동시성 제어

데이터가 다른 요청에 의해 변경되지 않고 한 트랜잭션에 의해서 수정될 것을 염두한 방법으로

장점

확장성이 높다.
구현이 간단하다. 행 버전을 사용할 경우 구현하기가 비교적 쉽다.
교착상태의 위험이 적다.

단점

안전성이 떨어진다.
요청을 재시도하는 경우가 많아진다.

적용방식

1. 마지막 업데이트를 최신으로 덮어쓴다.

2. 사용자가 변경한 필드를 비교한다. 이는 데이터 변경 이후 커밋을 하기 이전에 사용자가 데이터를 읽을 때와 동일한지 확인하는 작업이다. 기존에 읽은 데이터와 데이터베이스의 데이터가 같지 않으면 서버는 사용자의 변경 사항을 커밋하지 않고 사용자에게 알린다.

3. 행 버전 비교한다. 데이터에는 서버가 데이터를 업데이트할 때마다 변경되는 타임스탬프 필드를 추가하여 행 버전을 관리하는 방식이다.

Reference

Phantom Read

I. Phantom Read 정의 한 트랜잭션 내에서 같은 쿼리를 두 번 수행 시, 첫 번째 쿼리에서 없던 레코드(유령, Phantom)가 두 번째 쿼리에서 발생하는 현상 절차 절차 트랜잭션 데이터 예제 설명 ① Read Tran

itpenote.tistory.com

Database Concurrency Conflicts in the Real World

A lot of articles have been written about database concurrency conflict detection and the various ways of handling them.Unfortunately most of these arti...

www.codemag.com

[DB] 동시성 문제 해결방법

동시성 문제가 무엇이고 해결방법에 대하여 알아보도록 한다.

chrisjune-13837.medium.com

[JPA] N+1 문제 및 해결 방안

큐범 — Sun, 9 Oct 2022 21:23:16 +0900

N+1이란?

연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수 N번 만큼 연관관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어와 서버와 데이터의 접촉이 N번 발생하는 현상이다.

예시로 게시물과 해시태그를 예시로 들어 확인해본다.

가정

한 게시물에는 여러개의 해시태그를 들 수 있다.
해시태그는 한 게시물에만 속한다.

@Entity
@Getter
@Setter
@NoArgsConstructor
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "board_id")
    private Long id;
    private String content;

    @OneToMany(mappedBy = "board", fetch = FetchType.EAGER)
    private List<HashTag> hashTags = new ArrayList<>();

    public Board(String content) {
        this.content = content;
    }


}

@Entity
@Getter
@Setter
@NoArgsConstructor
public class HashTag {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    @ManyToOne
    private Board board;

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

테스트 케이스 가정

4개의 해시태그를 생성했다.
10개의 게시물을 생성한다.
각 게시물에는 4개씩 해시태그가 들어가있다.

@Test
@Commit
public void 게시물조회(){

    ArrayList<HashTag> hashTags = new ArrayList<>();
    for(int i=0; i<4; i++){
        HashTag hashTag = new HashTag("hashtag" + i);
        hashTags.add(hashTag);
    }
    hashTahRepository.saveAll(hashTags);

    List<Board> boards = new ArrayList<>();
    for(int i=0; i<10; i++){
        Board board = new Board("board" + i);
        board.setHashTags(hashTags);
        boards.add(board);
    }

    em.clear();

    System.out.println("------------------------------------------------------------------------");
    List<Board> boardAll = boardRepository.findAll();
    assertFalse(boardAll.isEmpty());
 }

아래와 같이 단순 게시물을 조회했을 뿐인데 해시태그의 select 문이 나가는 것을 알 수 있다.

그러면 entity의 연관관계에서 fetch를 즉시로딩(EAGER)이 아니라 지연로딩(LAZY)라면 다른가??

@OneToMany(mappedBy = "board", fetch = FetchType.LAZY)
private List<HashTag> hashTags = new ArrayList<>();

위와같이 쿼리문이 한번 날라가게 되었지만

System.out.println("------------------------------------------------------------------------");
List<Board> boardAll = boardRepository.findAll();
System.out.println("------------------------------------------------------------------------");
boardAll.forEach(board -> {
    board.getHashTags().size();
});

다음과같이 접근을 하게되면 아래와 같은 N+1의 문제가 다시 생긴다.

문제해결 방법

Fetch join

@Query("select b from Board b join fetch b.hashTags")
List<Board> findAllJoinFetch();

Hibernate: select board0_.board_id as board_id1_0_0_, hashtags1_.id as id1_2_1_, board0_.content as content2_0_0_, hashtags1_.board_board_id as board_bo3_2_1_, hashtags1_.name as name2_2_1_, hashtags1_.board_board_id as board_bo3_2_0__, hashtags1_.id as id1_2_0__ from board board0_ inner join hash_tag hashtags1_ on board0_.board_id=hashtags1_.board_board_id

다음과 같이 INNER JOIN으로 필요한 hashtag를 불러오는 쿼리를 볼 수 있다.

하지만, fetch join은 Entity연관관계에서 FetchType을 설정했다면 사용할수 없는 단점이 있다. 따라서, 현재 LAZY로 해놓은 상황에서는 select를 하는 순간 연관 관계의 데이터를 가져오기 때문에 Fetch Join으로 해결 할 수 없다. 그리고 페이징 쿼리를 사용할 수 없는 단점이 있다.

EntityGraph

@EntityGraph(attributePaths = "hashTags")
@Query("select b from Board b")
List<Board> findAllEntityGraph();

Hibernate: select board0_.board_id as board_id1_0_0_, hashtags1_.id as id1_2_1_, board0_.content as content2_0_0_, hashtags1_.board_board_id as board_bo3_2_1_, hashtags1_.name as name2_2_1_, hashtags1_.board_board_id as board_bo3_2_0__, hashtags1_.id as id1_2_0__ from board board0_ left outer join hash_tag hashtags1_ on board0_.board_id=hashtags1_.board_board_id

Fetch Join과는 다르게 Left Outer Join이 나가는 것을 볼 수 있다. @EntityGraph attributePaths의 역할은 가져올 필드명을 지정하면 면 지연로딩이아닌 즉시로딩으로 가져온다.

Fetch Join과 EntityGraph 사용시 주의점

Fetch Join과 EntityGraph는 JPQL을 사용해 Join문을 사용한다. 공통적으로 Catesian Product에 의해 Board수 만큼 Hashtag가 중복이 발생할 수 있다. 따라서, 중복에 대해서 주의해야한다.

중복발생시

컬렉션 Set을 사용한다.
distinct를 사용한다.

BatchSize

@BatchSize(size = 5)
@OneToMany(mappedBy = "board", fetch = FetchType.LAZY)
private List<HashTag> hashTags = new ArrayList<>();

Hibernate: select hashtags0_.board_board_id as board_bo3_2_1_, hashtags0_.id as id1_2_1_, hashtags0_.id as id1_2_0_, hashtags0_.board_board_id as board_bo3_2_0_, hashtags0_.name as name2_2_0_ from hash_tag hashtags0_ where hashtags0_.board_board_id in (?, ?, ?, ?, ?)
Hibernate: select hashtags0_.board_board_id as board_bo3_2_1_, hashtags0_.id as id1_2_1_, hashtags0_.id as id1_2_0_, hashtags0_.board_board_id as board_bo3_2_0_, hashtags0_.name as name2_2_0_ from hash_tag hashtags0_ where hashtags0_.board_board_id in (?, ?, ?, ?, ?)

지연로딩이기에 Board를 조회해서 해시태그에 접근할 경우 다음과 같은 IN절을 배치 사이즈만큼 인자로 넘어가서 2번이 날라가는 것을 알수 있다.

EX) BatchSize 20 해시태그 100개 IN절이 5번 조회

FetchMode.SUBSELECT

@Fetch(FetchMode.SUBSELECT)
@OneToMany(mappedBy = "board", fetch = FetchType.LAZY)
private List<HashTag> hashTags = new ArrayList<>();

Hibernate: select hashtags0_.board_board_id as board_bo3_2_1_, hashtags0_.id as id1_2_1_, hashtags0_.id as id1_2_0_, hashtags0_.board_board_id as board_bo3_2_0_, hashtags0_.name as name2_2_0_ from hash_tag hashtags0_ where hashtags0_.board_board_id in (select board0_.board_id from board board0_)

다음과 같이 모든 로딩에 대해서 대응이 가능하고 성능최적화 부분에서 좋은 전략이다.

QueryDSL의 QueryBuilder를 사용!

프로젝트 회고 [플랩업]

큐범 — Thu, 29 Sep 2022 00:36:40 +0900

개발기간 2022.06 ~ 2022.09 (3개월)

플랫폼 Android

담당역할

유저 (로그인, 수정, 보안) 개발, CICD(Docker, DockerHub, Jenkins) 파이프라인 구축

infra 서버 구축, NCP이용한 SMS 문자 인증

패키지 구조 설정, Exception Handler구성

이번 앱런칭은 방학기간에 사이드 프로젝트를 진행하고싶어 지인들로 구성하여 앱런칭을 진행하였다.

이번 앱런칭에 회고를 작성한다.

회고

첫째, 코드리뷰의 부재

기술 발전에 큰 도움이 된 것은 '집단지성'이라고 생각한다. 코드리뷰는 집단지성을 극대화 할 수 있다. 하지만, 각각의 팀원은 사이드 프로젝트이기에 투자할 수 있는 시간은 모두가 달랐다. 그렇기에 코드리뷰를 진행하게 되면 누군가에게 업무가 몰리는 현상이 일어나 코드리뷰를 진행하지 않았다. 하지만, 프로젝트가 끝나고 난 이후 다른 사람들의 코드를 보면 충분히 배울 점과 아쉬운 부분이 있었는데 이것들을 서로 짚어줬더라면 서로 성장하는 프로젝트가 됐을텐데 아쉬움이 남는다.

둘째, 모니터링과 이중화

"실제 서비스를 한다고 생각했으면 아래와 같은 아키텍쳐를 가졌을까?" 라는 생각에서 시작되었다. 실제 서비스와 사용 유저가 있었으면 단순히 2개의 서버로 CI서버와 CD서버로 구성하지 않았을 것이다. 개발 서버와 배포 서버를 분리하고 사용자들의 안정적인 사용이 가능하게 설계를 해야했는데 이중화 작업을 하지 못해서 DB만 이중화를 진행하고 서버는 이중화를 진행하지 않았다. 또한, 모니터링을 통해 몇 명의 유저가 어떠한 호출에 서버의 자원이 어느정도 사용되는지 모니터링 툴을 반영했어야 했다. 그 점에서 사이드 프로젝트를 단순히 토이 프로젝트 수준으로 내가 규제한 것은 아닌지? 생각하게 되며 다음 프로젝트에서는 실제 서비스와 유저가 있다고 생각하고 설계를 하는 것이 나에게 많은 성장할 것 같다.

셋째, 실제 사용자 유치

총 3번의 앱 출시를 거치면서 실제 유저가 있던 적은 없다. 출시에 의의를 두고 개발하였지만 실제 사용자가 없는 것은 때로는 허망함을 줄 때도 종종 있었다. 실제 트래픽을 관리해보고 싶은 욕구도 있는데 막상 출시가 이루어지면 다들 개발에도 루즈해지는 것도 있으며 새로운 프로젝트를 시작하는 경우가 많았다. 이제는 실제 사용자를 유치해보고 싶다. 그렇다면 다시 서비스(앱)를 돌아보면 유저가 좋아하는 서비스인지 내가 성장을 위한 서비스인지 묻는다면 나는 내가 성장을 위한 서비스였다. 내가 넣고싶은 기술과 아키텍쳐를 넣었다. 그 부분에서 사용자 유치는 힘들지않았을까 라는 생각과 이제는 내가 하고싶은 기술을 사용자가 원하는 서비스에 넣는 프로젝트를 진행하고 싶다.

개발 구성

개발환경

Language	JAVA (JDK 1.8)
Infra	AWS EC2(Ubuntu 20.04), RDS, S3
Framework	Spring Framework 2.7.1, Hibernate
DB	MySQL
Library, API	JPA, Naver Cloud Platform, JWT
CICD	Jenkins, Docker, DockerHub
Collaboration	Slack, Swagger, Figma, Discord

CICD

ERD

[Network] HTTP 상태코드

큐범 — Thu, 22 Sep 2022 16:45:03 +0900

상태코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

1xx(Informational): 요청이 수신되어 처리 중을 의미한다.
2xx(Successful): 요청 정상 처리한다.
3xx(Refirection): 요청을 완료하려면 추가 행동이 필요하다.
4xx(Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없다.
5xx(Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못한다.

미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.

299 -> 2xx(Successful)

451 -> 4xx(Client Error)

599 -> 5xx(Server Error)

2xx(Sucessful) - 클라이언트의 요청을 성공적으로 처리

200 OK - 요청 성공

201 Created - 요청 성공해서 새로운 리소스가 생성된다.

202 Acepted - 요청 접수되었으나 처리가 완료되지 않았다.

204 No Content - 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없다.

save 버튼의 결과로 아무 내용이 없어도 된다.
save 버튼을 눌러도 같은 화면을 유지해야 한다.
결과 내용이 없어도 204메시지 만으로 성공을 인식할 수 있다.

205 Reset Content

206 Partial Content

207Multi-Status

....

3xx (Redirection) - 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요하다.

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)

자동 리다이렉트의 흐름

예로는 JWT토큰만료에 의한 재인증 토큰 발급이 될 수 있다.

리다이렉션의 종류

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동한다.

301, 308

ex) /members -> /users || /event -> /new-event
301 Moved Permanetly
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.

영구 리다렉션 - 301

308 Permanent Redirect
- 301과 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

일시 리다이렉션 - 일시적인 변경

주문 완료 후 주문 내역 화면으로 이동한다.
PRG: Post/Redirect/Get
- PRG 이후 리다이렉트
  - URL이 이미 POST -> GET으로 리다이렉트 된다.
  - 새로 고침 해도 GET으로 결과 화면만 조회된다.

특수 리다이렉션 - 결과 대신 캐시를 사용

3xx 목록

300 Multiple Choices

301 Moved Permanetly

302 Found

303 See Other (since HTTP/1.1)

304 Not Modified (RFC 7232)

305 Use Proxy (since HTTP/1.1)

306 Switch Proxy

307 Temporary Redirect (since HTTP/1.1)

308 Permanent Redirect (RFC 7538)

결론

307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용한다.

자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제는 없다.

304 Not Modified

캐시를 목적으로 사용한다.
클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다.
304 응답은 응답에 메시지 바디를 로컬 캐시를 사용해야 하므로 포함하면 안된다.
조건부 GET, HEAD요청시 사용한다.

4xx - 클라이언트 오류

클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없다.
오류의 원인이 클라이언트에 있다.
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패한다.

400 Bad Request - 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없다.

요청 구문, 메시지 등등 오류
클라이언트는 요청 내용을 다시 검토하고 보내야한다.
요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 400번 에러가 발생한다.

401 Unauthorized - 클라이언트가 해당 리소스에 대한 인증이 필요하다.

인증이 되지 않는 경우에 발생.
401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.
Ex)
- 인증(Authentication): 본인이 누구인지 확인, (로그인)
- 인가(Authorization): 권한부여 (ADMIN 권한 처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 존재한다)
- 오류 메시지가 Unauthorized이지만 인증이 되지 않는다.

403 Forbidden - 서버가 요청을 이해했지만 승인을 거부한다.

주로 인증 자격은 증명 되었지만, 접근 권한이 불충분한 경우에 사용한다.
예를들어, 일반 회원이 관리자 페이지에 접근시.

404 Not Found - 요청 리소스를 찾을 수 없다.

요청 리소스가 서버에 없다.
또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 경우에도 사용한다.

5xx - 서버 오류

서버 내부 문제로 오류 발생에 사용한다.

서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있다.(복구가 되거나 등등)

500 Internal Server Error - 서버 문제로 오류 발생, 애매하면 500 오류

서버 내부 문제로 오류 발생에 사용된다.
애매한 경우에 500 오류

503 Service Unavailable - 서비스 이용 불가

서버 일시적인 과부화 또는 예정된 작업으로 잠시 요청을 처리할 수 없는 경우에 사용
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있다.

[Network] HTTP 메서드 활용

큐범 — Sat, 17 Sep 2022 20:46:20 +0900

클라이언트에서 서버로 데이터 전송

데이터 전달 방식은 크게 2가지이다.

1. 쿼리 파라미터를 통한 데이터 전송

GET, 정렬 필터로 주로 검색어에 사용된다.

2. 메시지 바디를 통한 데이터 전송

POST, PUT, PATCH
회원 가입, 상품 주문, 리소스 등록, 리소스 변경

4가지 상황

1. 정적 데이터 조회

이미지, 정적 텍스트 문서

2. 동적 데이터 조회

주로 검색, 게시판 목록에서 정렬 필터로 쓰인다.

3. HTML FORM을 통한 데이터 전송

회원 가입, 상품 주문, 데이터 변경에 쓰인다.

4. HTTP API를 통한 데이터 전송

회원가입, 상품 주문, 데이터 변경
서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

정적 데이터 조회의 경우(쿼리 파라미터 미사용)

이미지, 정적 텍스트 문서
조회는 GET 사용
정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능하다.

동적 데이터 조회의 경우(쿼리 파라미터 사용)

주로 검색, 게시판 목록에서 정렬 필터(검색어)
조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용한다.
조회는 GET 메서드를 사용한다.
GET은 쿼리 파라미터 사용해서 데이터를 전달한다.

HTML Form 데이터 전송

POST 전송 저장 과정

GET 전송 저장 과정 - 리소스 변경이 발생하는 곳에 사용하면 안된다.

multipart/form-data

HTML Form 데이터 전송

HTML Form submi시 POST 전송 - 데이터 변경에 관한 것들이 해당한다.
Content-Type: application/x-www-form-urlencoded 사용한다.
- form의 내용을 메시지 바디를 통해서 전송한다. (key = value, 쿼리 파라미터 형식이다.)
- 전송 데이터를 url encoding 처리한다. ex) 김abc -> %EA%B9%80abc
HTML Form은 GET 전송도 가능
Content-Type: multipart/form-data
- 파일 업로드 같은 바이너리 데이터 전송시 사용한다.
- 다른 종류의 여러 파일과 폼의 내용을 함께 전송이 가능하다.
HTML Form 전송은 GET, POST만 지원한다.

HTTP API 설계 예시

HTTP API - 컬렉션

POST 기반 등록

HTTP API - 스토어

PUT 기반 등록

HTML FORM 사용

GET, POST만 지원

API 설계 - POST 기반 등록

회원 목록 /members -> GET
회원 등록 /members -> POST
회원 조회 /members/{id} -> GET
회원 수정 /members/{id} -> PATCH, PUT, POST 회원 삭제 /members/{id} -> DELETE

POST 신규 자원 등록의 특징

클라이언트는 등록될 리소스의 URI를 모른다.

회원 등록 /members -> POST
POST /members

서버가 새로 등록된 리소스 URI를 생성해준다.

컬렉션(Collection)

서버가 관리하는 리소스 디렉토리
서버가 리소스의 URI를 생성하고 관리한다.
여기서 컬렉션은 /members이다.

API 설계 - PUT 기반 등록

파일 목록 /files -> GET

파일 조회 /files/{filename} -> GET

파일 등록 /files/{filename} -> PUT

파일 삭제 /files/{filename} -> DELETE

파일 대량 등록 /files -> POST

PUT 신규 자원 등록 특징

클라이언트가 리소스 URI를 알고 있어야 한다.

파일 등록 /file/{filename} -> PUT
PUT /files/kbcoding.jpg

클라이언트가 직접 리소스의 URI를 지정한다.

스토어(Store)

클라이언트가 관리하는 리소스 저장소
클라이언트가 리소스의 URI를 알고 관리한다.

HTML FORM 사용할 경우

HTML FORM은 GET, POST만 지원한다.

AJAX 같은 기술을 사용해서 해결 가능 하다.

GET, POST만 지원하므로 제약이 존재하다.

HTML FORM 설계 예시

회원 목록 /members -> GET

회원 등록 폼 /members/new -> GET

회원 등록 /members/new, /members -> POST

회원 조회 /members/{id} -> GET
회원 수정 폼 /members/{id}/edit -> GET

회원 수정 /members/{id}/edit, /members/{id} -> POST

회원 삭제 /members/{id}/delete -> POST

Reference.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

[Network] HTTP Method(GET, POST, PUT, PATCH, DELETE)

큐범 — Fri, 16 Sep 2022 21:48:24 +0900

URI 설계의 중요한 것은 리소스 식별

API URI(Uniform Resource Identifier)

리소스의 의미
- 회원을 등록하고 수정하고 조회하는 것은 리소스가 아니다.
- 예를들어 자원을 캐라 -> 자원이 리소스이다.
- 회원이라는 개념 자체가 바로 리소스인 것이다.
회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑하면 된다.

좋지 못한 URI설계
- 회원 목록 조회 /read-member-list
- 회원 조회 /read-member-by-id
- 회원 등록 /create-member
- 회원 수정 /update-member
- 회원 삭제 /delete-member

좋은 URI 설계
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}

Post. 계층 구조상 상위 컬렉션으로 보고 복수 단어 사용을 권장한다.

리소스와 행위를 분리

URI는 리소스만 식별하고 리소스와 해당 리소스를 대상으로 하는 행위를 분리하는 것이 옳다

- 리소스: 회원

- 행위: 조회, 등록, 삭제, 변경

위의 좋은 URI 설계를 보면 구분하는 방법이 의아할 수 있다.

이를 구분 짓는 것은 HTTP 메서드이다.

HTTP 메서드의 종류

GET: 리소스 조회한다.

POST: 요청 데이터 처리, 주로 등록에 사용한다.

PUT: 리소스를 대체, 해당 리소스가 없으면 생성한다.

PATCH: 리소스 부분 변경한다.

DELETE: 리소스 삭제한다.

기타 메서드

HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환한다.

OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)한다.

CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정한다.

RACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다.

GET

리소스 조회한다.

서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달한다.

메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.

GET 동작 과정

1. 메시지 전달

2. 서버 도착

3. 응답 데이터

POST

요청 데이터를 처리한다.

메시지 바디를 통해 서버로 여청 데이터를 전달한다.

서버는 요청 데이터를 처리하고 메시지 바디를 통해 들어온 테이터를 처리하는 모든 기능을 수행한다.

주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용된다.

POST 동작 과정

1. 메시지 전달

2. 신규 리소스 생성

3. 응답 데이터

POST에서 요청 데이터를 처리한다는 뜻은

공식 스펙: POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다.

이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 -> 정해진 것이 없음

POST 총정리

1. 새 리소스 생성(등록)

- 서버가 아직 식별하지 않은 새 리소스를 생성한다.

2. 요청 데이터를 처리

- 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야하는 경우.

예를들어, 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우

- POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다.

예를들어, POST /orders/{orderId}/start-delivery (컨트롤 URI)

3. 다른 메서드로 처리하기 애매한 경우

예를들어, JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

애매한 것들은 POST로 처리하자.

PUT

리소스를 대체

- 리소스가 있으면 대체

- 리소스가 없으면 생성

- 리소스를 덮어버린다.

클라이언트가 리소스를 식별

- 클라이언트가 리소스 위치를 알고 URI 지정한다.

- 이 점이 POST와 다르다.

PUT 동작 과정

리소스가 있는경우 1

리소스가 있는 경우 2

리소스가 없는 경우 1

리소스가 없는 경우 2

리소스를 완전히 대체한다 1

리소스를 완전히 대체한다 2

PATCH

리소스를 부분 변경한다.

PATCH 동작 과정

리소스 부분 변경1

리소스 부분 변경2

DELETE

리소스를 제거한다.

DELETE 동작 과정

리소스 제거 1

리소스 제거 2

HTTP 메서드 속성

안전(Safe Methods)

멱등(Idempotent Methods)

캐시가능(Cacheable Methods)

안전 - 호출해도 리소스를 변경하지 않는다.

멱등(Idempotent)

f(f(x)) = f(x)

한 번 호출하든 두 번 호출하든 n번 호출하든 결과가 같다.

멱등 메서드

GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

멱등의 활용으로 자동 복구 메커니즘을 가질 수 있다.

Q: 재요청 중간에 다른 곳에서 리소스를 변경해버리는 경우는??

Ex)

사용자1: GET -> username:A, age:20

사용자2: PUT -> username:A, age:30

사용자1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회

A: 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.

캐시가능(Cacheable)

응답 결과 리소스를 캐시해서 사용해도 되는가?

GET, HEAD, POST, PATCH 캐시가능

실제로는 GET, HEAD 정도만 캐시로 사용

- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지않다.

Reference.

HTTP - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. HTTP(HyperText Transfer Protocol, 문화어: 초본문전송규약, 하이퍼본문전송규약)는 W3 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에

ko.wikipedia.org

HTTP 요청 메서드 - HTTP | MDN

HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부

developer.mozilla.org

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

[Network] HTTP(Stateful Stateless 차이, 비 연결성, 클라이언트 서버 구조 ...)

큐범 — Thu, 15 Sep 2022 16:31:20 +0900

HTTP (HyperText Transfer Protocol)

- 역사

HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X

HTTP/1.0 1996년: 메서드, 헤더 추가

HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전

RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

HTTP/2 2015년: 성능 개선

HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

- 기반 프로토콜

TCP: HTTP/1.1, HTTP/2

UDP: HTTP/3

현재 HTTP/1.1 주로 사용

- HTTP/2, HTTP/3 도 점점 증가

- HTTP 특징

클라이언트 서버 구조를 갖는다.

무상태(Stateless) 프로토콜, 비연결성

- 클라이언트 서버 구조

Request Response구조를 갖는다.

클라이언트는 서버에 요청을 보내고, 응답을 대기한다.

서버가 요청에 대한 결과를 만들어서 응답한다.

Stateful, Stateless

- 무상태 프로토콜 [스테이리스(Stateless)]

서버가 클라이언트의 상태를 보존하지 않는다.

장점: 서버 확장성이 높다.(Sacle out)

단점: 클아이언트가 추가 데이터를 전송한다.

Stateful의 상황

고객: 이 노트북 얼마인가요?

점원: 100만원 입니다.

고객: 2개 구매하겠습니다.

점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?

고객: 신용카드로 구매하겠습니다.

점원: 200만원 결제 완료되었습니다.

Stateful의 점원이 중간에 바뀐다는 상황

고객: 이 노트북 얼마인가요?

점원A: 100만원 입니다.

고객: 2개 구매하겠습니다.

점원B: ? 무엇을 2개 구매하시겠어요?

고객: 신용카드로 구매하겠습니다.

점원C: ? 무슨 제품을 몇 개 신용카드로 구매하시겠어요?

상태 유지- Stateful

고객: 이 노트북 얼마인가요?

점원: 100만원 입니다. (노트북 상태 유지)

고객: 2개 구매하겠습니다.

점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요? (노트북, 2개 상태 유지)

고객: 신용카드로 구매하겠습니다.

점원: 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지)

무상태 - Stateless

고객: 이 노트북 얼마인가요?

점원: 100만원 입니다.

고객: 노트북 2개 구매하겠습니다.

점원: 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?

고객: 노트북 2개를 신용카드로 구매하겠습니다.

점원: 200만원 결제 완료되었습니다.

무상태 - Stateless, 점원이 중간에 바뀌면?

고객: 이 노트북 얼마인가요?

점원A: 100만원 입니다.

고객: 노트북 2개 구매하겠습니다.

점원B: 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?

고객: 노트북 2개를 신용카드로 구매하겠습니다.

점원C: 200만원 결제 완료되었습니다

Stateful, Stateless 정리

- Stateful(상태 유지): 중간에 다른 점원이 바뀌면 안된다.

(중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.)

- Stateless(무상태): 중간에 다른 점원으로 바뀌어도 된다.

- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.

- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

- 무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능

Stateful(상태 유지) - 항상 같은 서버가 유지 되어야한다.

중간에 서버가 장애가 나면? 클라이언트의 상태 정보가 사라진다.

반면에, Stateless(무상태)는 아무 서버나 호출하면 되기에 서버2에서 호출하면된다.

Stateless의 한계

- 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.

- 무상태 • 예) 로그인이 필요 없는 단순한 서비스 소개 화면

- 상태 유지 • 예) 로그인

- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지

- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지

-상태 유지는 최소한만 사용

비 연결성

HTTP는 기본이 연결을 유지하지 않는 모델이다.

일반적으로 초 단위의 이하의 빠른 속도로 응답한다.

1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리한느 요청은 수십개 이하로 매우 작다.

- 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.

서버 자원을 매우 효율적으로 사용할 수 있다.

비 연결성 - 한계와 극복

TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가된다.

웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 등 수 많은 자원이 함께 다운로드된다.

지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다.

HTTP/2, HTTP/3에서 더 많은 최적화가 이루어진다.

HTTP 초기

HTTP 지속 연결

HTTP 메시지

시작 라인 - 요청 메시지

start-line = request-line / status-line

request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

HTTP 메서드 (GET: 조회)

요청 대상 (/search?q=hello&hl=ko)

HTTP Version

시작 라인 - 요청 메시지(HTTP 메서드)

종류: GET, POST, PUT, DELETE...

서버가 수행해야 할 동작 지정

- GET: 리소스 조회

- POST: 요청 내역 처리

시작 라인 - 요청 메시지(요청 대상)

absolute-path[?query] (절대경로[?쿼리])
절대경로= "/" 로 시작하는 경로

참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.

+ 마지막은 HTTP Version = HTTP/1.1

시작 라인 - 응답 메시지

start-line = request-line / status-line

status-line = HTTP-version SP status-code SP reason-phrase CRLF

HTTP 버전

HTTP 상태 코드: 요청 성공, 실패를 나타낸다.

200: 성공

400: 클라이언트 요청 오류

500: 서버 내부 오류

이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글

HTTP 헤더

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name은 대소문자 구문 없다.

HTTP 전소에 필요한 모든 부가정보가 들어간다.

HTTP 메시지 바디

실제 전송할 데이터

HTML, 이미지, 영상 등등 byte로 표현할 수 있는 모든 데이터 전송 가능하다.

Reference.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

[MSA] Micro Service Pattern(API Gateway, Service discovery, Service Mesh)

큐범 — Wed, 14 Sep 2022 17:08:39 +0900

Micro Service Pattern - API Gateway

service1,2,3가 전부 사용되는 데이터가 필요해지면 각각의 서비스를 호출해야해서 총 6번의 호출과 반환이 이루어지는데 각각의 결과 값을 기다려야한다. 여기서의 문제점은 service1,2,3 각각의 주소를 알아야하는 단점이 있다.

위의 상황은 Application과 service사이에 API gatway를 두어서, 요청을 동시에 service1,2,3에 보낸 후, 데이터를 취합하여 다시 클라이언트로 보낸다. API Gateway를 두어서 하나의 api point만 알아도 되는 이점이 있다.

- 마이크로 소프트 공식문저 중 -

API Gateway 이점

- 클라이언트와 서비스가 분리된다. 모든 클라이언트를 업데이트 하지 않고도 서비스 버전을 관리하거나 서비스를 리팩토링할 수 있다.

- 서비스가 웹 우호적이 아닌 *AMQP(Advanced Mwssage Queuing Protocol) 등의 메시징 프로토콜을 사용할 수 있다.

- API 게이트웨는 인증, 로깅 SSL 종료, 부하 분산 등의 다른 교차 기능을 수핼할 수 있다.

- 제한, 캐싱 변환 또는 유효성 검사와 같은 즉시 사용 가능한 정책이다.

*AMQP: 메시지 지향 미들 웨어를 위한 개방형 표준 응용 계층 프로토콜.

Micro Service Pattern - Service discovery

탄생배경

클라우드를 사용할 경우, auto scaling에 따라 service instance가 유동적으로 변하며 IP 주소가 계속 바뀌게 되며, 이데 대한 정보를 취득할 수 있는 방법일 필요해진다.

클라이언트나 API 게이트웨이가 호출할 서비스를 찾아주는 메커니즘이 필요하게 되었다.

이를 Client-Side/Server-Side Discovery Pattern을 적용하면 해결이 가능하다.

MSA와 같은 분산 환경은 서비스 간의 원격 호출로 구성된다. 원격 서비스 호출은 IP 주소와 포트를 이용하는 방식으로 클라우드 환경이 되면서 서비스가 오토 스케일링 등에 의해서 동적으로 생성되거나

컨테이너 기반의 배포로 인해서, 서비스의 IP가 동적으로 변경되는 일의 빈도가 늘어난다.

Service A의 인스턴스들이 생성될때, Service A에 대한 주소를 Servie registry(서비스 등록 서버)에 등록해놓는다. Service A를 호출하고자 하는 클라이언트는 Service registry에 Service A의 주소를 물어보고 등록된 주소를 받아서 그 주소로 서비스를 호출한다.

- Service discovery 기능을 구현하는 방법으로는 크게 Client discovery방식과 Server side discovery 방식이 있다. Service Client가 Service registry에서 서비스의 위치를 찾아서 호출하는 방식을 Client side dicovery이다.

- 호출이 되는 서비스 앞에 일종의 proxy서버(로드밸런서)를 넣는 방식인데, 서비스 클라이언트는 이 로드 밸런서를 호출하면 로드밸런서가 Service registry로 부터 등록된 서비스의 위치를 리턴하고, 이를 기반으로 라우팅 하는 방식이다.

Micro Service Pattern - Service Mesh

Service Mesh

서비스 간의 전체 연결 구조를 파악하기 어려우며 이로 인해서 장애가 났을 경우, 어느 서비스에 장애가 났는지 추적에 대한 어려움이 생긴다. 또한, 특정 서비스의 장애가 다른 서비스에 영향을 주는 문제들을 겪을 수 있다.

앞의 문제와 같은 장애 전파의 예는 써킷 브레이커(Circit breaker)라는 디자인 패턴으로 해결할 수 있다.

서킷 브레이커 패턴

Reference.

마이크로 서비스 아키텍처 스타일 - Azure Architecture Center

Azure에서 마이크로 서비스 아키텍처 스타일의 이점, 과제 및 모범 사례에 대해 알아봅니다.

docs.microsoft.com

AMQP - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. AMQP(Advanced Message Queuing Protocol, 어드밴스트 메시지 큐잉 프로토콜)는 메시지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜이다. AMQP의 정의 기능들은

ko.wikipedia.org

서비스 메쉬(service mesh) 개념, 기능, 작동방식, 최적화 방법

서비스 메쉬(서비스 메시)란 애플리케이션에 구축된 인프라 레이어를 뜻하며, 마이크로서비스 라우팅을 요청하고 개별 프록시들이 모여 메쉬 네트워크를 형성합니다.

www.redhat.com

[MSA] MSA(Micro Service Architecture) 정의

큐범 — Tue, 13 Sep 2022 16:22:43 +0900

MSA의 정의를 알기 위해서는 그와 반대되는 모노리스 시스템에 대해서 이해해야한다.

모노리스(Monoliths)

- 프로젝트에 모든 코드가 모여있어, 시스템 구조가 간결하고 빠르게 구축할 수 있다,

- 애플리케이션이 한 덩어리로 구성하며 단일 프로세스로 실행해야한다.

- 한꺼번에 수정, 배포되어야한다. 하나가 실패하면 모두 실패됨을 의미한다.

문제점: 작은 부분을 수정해도 전체 부분에 대해서 영향을 줄 수 있다.

모노리스를 클라우드 인프라에서 활용시에 스케일 아웃의 대상은 모노리스 전체가 된다. 그것만으로 충분히 확장성, 탄력성이 보장가능하나 비용효율적이지 않다.

그에 비해 마이크로 서비스는 애플리케이션이 여러개의 서비스 조각으로 구성된다.

Micro Service Architecture 정의

Micro Service는 작고, 독립적이며, 느슨하게 결합되어 있어 하나의 소규모 개발자 팀이 작성하고 유지 관리할 수 있다.

서비스는 각기 독립적인 기능을 제공한다. 서비스가 사용하는 저장소는 다른 서비스와 완벽히 격리된다. 따라서 독립적으로 수정 가능하며 별도 배포, 확장 가능하다. 따라서, 하나의 서비스 실패는 전체 실패가 아닌 부분적인 실패를 의미한다.

확장시, 특정 기능별 독립적으로 확장 가능하며 특정 서비스의 변경 시 서비스 만 빌드, 배포가 진행된다. 독립적으로 서로 다른 언어로 개발 가능하다.

MSA의 특징

- 하나의 시스템에서 개발 기술 환경이 다르다.

- n개의 인스턴스가 있는데 이를 MSA라 한다.

- 서비스 자체 외에도 관리/오케스트레이션, API 게이트웨이와 같이 몇 가지 다른 구셩 요소가 기존 마이크로 서비스 아키텍쳐에 추가된다.

Reference.

What are microservices?

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous

microservices.io

마이크로 서비스 아키텍처 스타일 - Azure Architecture Center

Azure에서 마이크로 서비스 아키텍처 스타일의 이점, 과제 및 모범 사례에 대해 알아봅니다.

docs.microsoft.com

[MSA] MSA(Micro Service Architecture) 탄생배경 사용이유

큐범 — Mon, 12 Sep 2022 16:07:10 +0900

왜 MSA인가?

MSA의 탄생과 배경에는 아키텍쳐의 히스토리를 살펴볼 필요가 있다.

*아키텍쳐는 시스템의 구조이다.

과거에는 시스템의 구조보다는 알고리즘, 데이터 구조에 집중적이었다. 소프트웨어의 복잡도와 활용도가 올라감에 따라 구조에 대한 중요도가 올라가게 되었다. 즉, 과거에는 클래스나 모듈 내부에 관심이 있었다. 왜냐하면 컴퓨터의 자원이 현 시대와는 다르게 성능 확장 및 시스템에 대한 접근성이 좋지 않았다. 하지만 현재는 어디에서나 네트워크의 발전과 클라우드 컴퓨팅을 통해 시스템에 접근이 가능하다. 위의 표를 보면, 소프트웨어 아키텍쳐는 1990년대에 크게 관심을 갖기 시작했다.

그러면 왜 소프트웨어 아키텍쳐가 관심을 가지게 된건지 알아볼 필요가 있다.

시간이 지남에 따라 소프트웨어는 현대 시대에 스며들어 고객의 요구사항은 복잡도를 갖고 발전했다. 한 예로는 소프트웨어가 이제는 사람의 생명과 직결되는 경우가 있다. 테슬라의 자율주행 차량을 보면 인명피해가 있는 것을 확인할 수 있다.

분산 컴퓨팅이 등장하고 그와 맞게 더 잘게 분산 되어진 MSA가 등장하였다.

아키텍쳐 트렌드의 흐름

1. Main-Frame

2. Client/Server

3. Web

4. SOA(Service Oriented Architecture)

5. REST

6. MSA

MSA는 공식적인 정의가 없다.

따라서 이를 정리하면서 나의 정리는 'MSA는 분산되어지는 것이다.'라고 생각한다.

MSA의 특징

1. 마이크로 서비스 아키텍처의 서비스들은 독립적인 deploy가 이루어져야한다.

2. 서비스의 교체가 쉽다.

3. 서비스 기능별로 분류된다.

4. 서비스들은 규모가 작고, 메시지 전달이 가능하며 컨텍스트별로 묶이며 자율적으로 개발되며 독립적으로 전개할 수 있으며 분산적이며 빌드가 되며 자동화된 프로세스들로 출시된다.

MSA의 장점:

1. 독립적인 배포로 빠르게 변하는 시대에 발 맞게 서비스를 배포할 수 있다.

2. 오류처리에 대한 서비스 격리로 서버 정상화에 대한 시간 단축할 수있다.

3. 유연한 확장으로 과부화된 서비스에 대해서만 확장이 가능하다.

MSA의 단점:

1. 개발 복잡도와 숙련도가 많이 요구된다.

2. 트랜잭션 처리 가 복잡하므로 데이터 동기에 대한 처리를 신경써야한다.

3. 통합 테스트의 어려움이 존재한다.

4. 배포의 복잡도 상승

위의 사진을 보면 각각의 클라이언트에서 각각의 다른 서비스에서 다른 DB를 통해 하나의 시스템을 완성하는 것을 볼 수 있다.

넷플릭스의 아키텍쳐를 보면 연두색은 서비스이도 서비스들끼리 연결된 모습을 볼 수 있다. 서비스 간의 연결성이 매우 많은 것을 확인 할 수 있다.

총평

현재 IT업계에서 시대를 이끌어가는 대표적인 기업들은 MSA로 개발이 진행된다. 이런 것처럼 나는 MSA가 왜 나오게 되었고 기술의 발전에서 공통된 기술은 무엇인지 고민하며 앞으로 나올 기술에서도 공통된 기술이 무엇인지 생각해보아야 한다.

Reference.

에스코어

에스코어는 디지털 혁신을 위한 고급 프로페셔널 서비스를 제공합니다. 매니지먼트 컨설팅과 소프트웨어 테크놀로지 서비스 오퍼링을 살펴보세요.

s-core.co.kr

What are microservices?

microservices.io

[Network] URI, URL, URN

큐범 — Sun, 11 Sep 2022 01:43:38 +0900

URI, URL, URN

URI는 로케이터(locator), 이름(name) 또는 둘다 추가로 분류 될 수 있다.

https://www.ietf.org/rfc/rfc3986.txt - 1.1.3. URI, URL, and URN

URI: 리소스의 식별

URL: 리소스의 위치

URN: 리소스의 이름

URI

Uniform: 리소스 식별하는 통일된 방식

Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)

Identifier: 다른 항목과 구분하는데 필요한 정보

URL, URN

URL - Locator: 리소스가 있는 위치를 지정한다.

URN - Name: 리소스에 이름을 부여한다.

위치는 변할 수 있지만, 이름은 변하지 않는다.

URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않는다.

URL분석

https://www.google.com/search?q=hello&hl=ko

URL

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

프로토콜(https)

호스트명(www.google.com)

포트 번호(443)

패스(/search)

쿼리 파라미터(q=hello&hl=ko)

URL - scheme

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

- 주로 프로토콜을 사용한다.

- 프로토콜은 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙이다. 예를들어, Http, Https, ftp 등이 있다.

- http는 80포트, https는 443포트를 주로 사용하고 포트는 생략이 가능하다.

- https는 http에 보안 추가한 것이다.

URL-userinfo

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

- URL에 사용자 정보를 포함해서 인증하는 방식이다.

URL-host

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

- 호스트명으로 도메인명 또는 IP 주소를 직접 사용가능하다.

URL-PORT

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

- 접속 포트로 일반적으로 생략하며 생략시에는 http는 80, https는 443을 넣는다.

URL-path

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

- 리소스 경로(path), 계층적 구조

- 예를들어 /home/file1.jpg. /members/100. /items/iphone12.

URL-query

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

- key = value형태로 ?로 시작해서 &로 추가 가능하다. Ex)keyA=valueA&keyB=valueB

- query parameter, query string 등으로 불린다. 웹서버에 제공하는 파라미터, 문자 형태이다.

URL-fragment

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://docs.spring.io/spring-boot/docs/current/reference/html#getting-started.html#getting-started-introducing-spring-boot

- html 내부 북마크 등에 사용되며 서버에 전송하는 정보가 아니다.

Reference.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

[Network] PORT, DNS(Domain Name System)

큐범 — Sat, 10 Sep 2022 01:22:08 +0900

PORT의 탄생 배경

하나의 IP에서 한번에 둘 이상의 연결을 해야하는 경우는

TCP/IP 패킷 정보를 보면 출발지 PORT와 목적지 PORT를 넣어서 패킷 보내기에 PORT를 알 수 있다.

따라서, 아래와 같은 방식으로 서버와 PORT를 포함해 통신한다.

화상통화의 경우,

클라이언트에서 서버로 200.200.200.2:32202 로 요청을 보내고

서버에서 클라이언트로 100.100.100.1:21000로 응답을 보낸다.

PORT

- 0 ~ 65535 할당 가능하다.

- 0 ~ 1023 잘 알려진 포트로 사용하지 않는 것이 좋다.

- FTP - 20,21
TELNET - 23
HTTP - 80
HTTPS -443

DNS 탄생 배경

IP는 기억하기 어렵고, 변경될 수 있다.

DNS

도메인 네임 시스템(Domain Name System)

전화번호부 같은 역할로 도메인 명을 IP 주소로 변환해주는 역할을 한다.

DNS 동작 방식

Reference.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

[Network] TCP, UDP

큐범 — Fri, 9 Sep 2022 01:07:51 +0900

TCP 전송 제어 프로토콜(Transmission Control Protocol)

TCP 특징

1. 연결지향 - TCP 3 way handshake (가상 연결)

2. 데이터 전달 보증

3. 순서 보장

4. 신뢰할 수 있는 프로토콜

5. 현재는 대부분 TCP 사용

TCP/IP패킷 정보

TCP 3 way handshake

SYN은 synchronized로 동기화라는 뜻이다.

ACK는 acknowledgement code 확인이라는 뜻이다.

데이터 전달 보증

순서 보장

UDP 사용자 데이터그램 프로토콜(User Datagram Protocol)

UDP 특징

1. 하얀 도화지에 비유해서 기능이 거의 없다.

2. 연결 지향 - TCP 3 way handshake를 지원하지 않는다.

3. 데이터 전달 보증을 지원하지 않는다.

4. 순서를 보장하지 않는다.

5. 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다.

UDP -> IP와 거의 같다. +PORT +체크섬 정도만 추가하고 애플리케이션에서 추가 작업이 필요하다.

Reference.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

[Network] 인터넷 네트워크

큐범 — Fri, 9 Sep 2022 00:51:29 +0900

인터넷에서 컴퓨터 통신하는 방법

예) 클라이언트가 서버로 부터 통신하는 방법

서버는 해당 메시지를 받고 OK 라는 반환을 한다.

인터넷 망에는 수 많은 노드가 존재하는데 다음과 같이 각각의 IP(Internet Protocol)를 부여한다. 실제 생활에 적용을 하면, 집 주소와 같은 역할을 한다.

IP의 역할

지정한 IP 주소(IP Address)에 데이터를 전달한다.
패킷(Packet)이라는 통신 단위로 데이터 전달한다.

그러면 아래와 같이 클라이언트에서 "Hello, world!"라는 문구를 보내는 경우, 인터넷의 노드를 통해 서버로 전달한다.

그 다음 아래와 같이 서버는 다시 클라이언트에게 OK를 반환한다. 즉, 전달이 잘 되었다는 것을 알려준다.

IP 프로토콜의 한계

1. 비연결성

패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송한다.

2. 비신뢰성

중간에 패킷이 사라지거나 패킷이 순서대로 오지 않는 것에 대해서 컨트롤할 수 없다.

3. 프로그램 구분

같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면 구분을 할 수 없다.

IP 프로토콜의 한계를 극복할 수 있는 것이 TCP, UDP이다.

Reference.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...

www.inflearn.com

[Cloud] 스케일업(Scale-up)과 스케일 아웃(Scale-out)

큐범 — Thu, 8 Sep 2022 17:10:14 +0900

스케일링에는 스케일업, 스케일아웃이 존재한다.

Scale up은 인스턴스의 성능을 늘리는 상황이며 수직 스케일링이라고도 한다.

반면, 스케일 아웃은 물리적인 규모를 늘리 것이며 수평 스케일링이라고도 한다.

스케일 업과 스케일 아웃에 대한 정리

	스케일업(수직 스케일링)	스케일아웃(수평 스케일링)
확장성	성능 확장에 한계가 있다.	지속적 확장이 가능하다.
서버비용	성능 증가에 따른 비용 증가폭이 크며, 일반적으로 비용부담이 크다.	비교적 저렴한 서버를 사용하므로 일반적으로 비용부담이 적다.
운영비용	관리 편의성이나 운영비용은 스케일업에 따라 큰 변화는 없다.	대수가 늘어날수록 관리편의성이 떨어지며, 서버의 상면비용을 포함한 운영비용이 증가한다.
장애	한대의 서버에 부하가 집중되는 만큼 장애시 장애 영향도가 크다.	읽기/쓰기가 여러대의 서버에 분산되어 처림됨으로 장애 시 전면 장애의 가능성이 적다.

[Cloud] 오토 스케일링(Auto Scaling)

큐범 — Wed, 7 Sep 2022 17:08:35 +0900

오토 스케일링(Auto Scaling)

Auto = 자동

Scaling = [컴퓨터] 크기 조정

자동으로 크기를 조정 즉, 컴퓨터의 크기(성능)을 탄력적으로 축소 확장을 할 수 있는 유연성을 말한다.

오토 스케일링은 클라우드의 CPU, Memory, Traffic과 같이 증가되는 특정 시간 및 상황에 알맞게 시스템이 자동으로 오토 스케일리을 통해 시스템의 부하를 막는다.

실제 사용중인 EC2 모니터링

대표적인 클라우드 제공 기업(CSP) AWS의 오토 스케일링을 보면 간단하게 EC2, DB, Aurora 등 리소스에 대한 규모 조정 계획을 수립을 통해 사용자에게 클라우드의 규모를 간단하게 조정할 수 있는 서비스를 제공해준다.

오토스케일링의 동작 원리

AWS는 특정 시점에 네트워크 정보와 시스템 리소스 메트릭 정보들을 모니터링 서비스로 수집한 이후, 사용자가 지정한 일정 임계치를 넘어가면 오토스케일링 그룹으로 알림을 발송해 서버수를 늘리거나 줄이는 방식으로 작동한다. 위의 사진과 같이 최소 사이즈 단위를 규정하고 디폴트 성능을 정하고 디폴트 성능을 초과하면 Scale out이 필요하다는 것을 알림 보내는 방식이다.

Reference

https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html

[Algorithm] JAVA 코드업 기초 100제 (기초-1차원배열, 2차원배열) 1093 ~ 1099

큐범 — Tue, 6 Sep 2022 02:50:42 +0900

1093 : [기초-1차원배열] 이상한 출석 번호 부르기1(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s1 = sc.nextLine();
		String s2 = sc.nextLine();
		
		int[] array = new int[23];
		int[] call = Arrays.stream(s2.split(" "))
				.mapToInt(Integer::parseInt)
				.toArray();
		
		for(int i=0; i<Integer.parseInt(s1); i++) {
			array[call[i]]++;
		}
		
		for(int j=1; j<23; j++) {
			System.out.print(array[j]+" ");
		}
	}

1094 : [기초-1차원배열] 이상한 출석 번호 부르기2(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		int s1 = sc.nextInt();
		int[] array = new int[s1];

		
		for(int i =0; i<s1; i++) {
			array[i] = sc.nextInt();
		}
		
		for(int j = array.length-1; j>=0; j-- ) {
			System.out.print(array[j]+" ");
		}
	}

1095 : [기초-1차원배열] 이상한 출석 번호 부르기3(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		int s1 = sc.nextInt();
		int[] array = new int[s1];

		
		for(int i =0; i<s1; i++) {
			array[i] = sc.nextInt();
		}
		
		int min=23;
		
		for(int j=0; j<array.length; j++) {
			if(array[j]<min) min= array[j];
		}
		
		System.out.println(min);
	}

1096 : [기초-2차원배열] 바둑판에 흰 돌 놓기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		int n = sc.nextInt();
		int[][] array = new int[19][19];
		
		for(int i=0; i<n; i++) {
			int x = sc.nextInt();
			int y = sc.nextInt();
			
			array[x][y]=1;
		}
		
		for(int j=1; j<array.length; j++) {
			for(int k=1; k<array.length; k++) {
				System.out.print(array[j][k]);
			}
			System.out.print("\\n");
		}
	}

1097 : [기초-2차원배열] 바둑알 십자 뒤집기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		int[][] array = new int[20][20];
		
		for(int i=1; i<array.length; i++) {
			for(int j=1; j<array.length; j++) {
				array[i][j]=sc.nextInt();	
			}
		}
		
		int n = sc.nextInt(); 
		
		for(int i=0; i<n; i++) {
			int x = sc.nextInt();
			int y = sc.nextInt();
			
			for(int j=1; j<array.length; j++) {
				if(array[x][j]==0) array[x][j]=1;
				else array[x][j]=0;
			}
			for(int k=1; k<array.length; k++) {
				if(array[k][y]==0) array[k][y]=1;
				else array[k][y]=0;
			}
		}
		
		
		for(int j=1; j<array.length; j++) {
			for(int k=1; k<array.length; k++) {
				System.out.print(array[j][k]);
			}
			System.out.print("\\n");
		}
	}

1098 : [기초-2차원배열] 설탕과자 뽑기

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		int[][] array;
		
		int h,w,n,l,d,x,y; 
		h=sc.nextInt();
		w=sc.nextInt();
		
		array=new int[h][w];
		
		n=sc.nextInt();
		
		for(int i=0; i<n; i++) {
			l=sc.nextInt();
			d=sc.nextInt();
			x=sc.nextInt();
			y=sc.nextInt();
			
			for(int j=0; j<l; j++) {
				if(d==0) array[x-1][y-1+j]=1;
				else array[x-1+j][y-1]=1;
			}
		}
		
		for(int i=0; i<w; i++) {
			for(int j=0; j<w; j++) {
				System.out.print(array[i][j]+" ");
			}
			System.out.print("\\n");
		}
	}

1099 : [기초-2차원배열] 성실한 개미

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		int[][] array=new int[11][11];
		
		for (int i=1; i<=10; i++) {
			for (int j=1; j<=10; j++) {
				array[i][j] = sc.nextInt();
			}
		}
		
		int x = 2;
		int y = 2;
		
		while(true) {
			if(array[x][y]==0) {
				array[x][y]=9;
				y++;
			}
			if(array[x][y]==1) {
				y--;
				x++;
			}
			if(array[x][y]==2) {
				array[x][y]=9;
				break;
			}else if(array[x][y]+1 ==1 && array[x+1][y]==1) {
				if(array[x][y]==0) array[x][y]=9;
				
				break;
			}
		}
		
		for(int i=1; i<=10; i++) {
			for(int j=1; j<=10; j++) {
				System.out.print(array[i][j]+" ");
			}
			System.out.print("\\n");
		}
	}

[Algorithm] JAVA 코드업 기초 100제 (기초-종합) 1078 ~ 1092

큐범 — Mon, 5 Sep 2022 02:10:25 +0900

1078 : [기초-종합] 짝수 합 구하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int s = sc.nextInt();
		
		int sum=0;
		for(int i=0; i<=s; i++) {
			if(i%2==0) {
				sum +=i;
			}
		}
		System.out.println(sum);
	}

1079 : [기초-종합] 원하는 문자가 입력될 때까지 반복 출력하기

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		
		String[] array = s.split(" ");
		
		for(String x: array) {
			System.out.println(x);
			if(x.equals("q")) break;			
		}

1080 : [기초-종합] 언제까지 더해야 할까?

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int key = sc.nextInt();
		int sum=0;
		
		for (int i=0; i<=key; i++) {
			sum+=i;
			if(sum>=key) {
				System.out.println(i);
				break;
			}
		}
	}

1081 : [기초-종합] 주사위를 2개 던지면?(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		int[] array = Arrays.stream(s.split(" "))
				.mapToInt(Integer::parseInt)
				.toArray();
		
		for(int i=1; i<=array[0]; i++) {
			for(int j=1; j<=array[1]; j++) {
				System.out.println(i+" "+j);
			}
		}
	}

1082 : [기초-종합] 16진수 구구단?

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int c = sc.nextInt(16);
		
		for(int i=1; i<=16; i++) {
			System.out.printf("%X*%X=%X\\n",c,i,c*i);
		}
	}

1083 : [기초-종합] 3 6 9 게임의 왕이 되자!(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int key = sc.nextInt();
		
		for(int i=1; i<=key; i++) {
			if(i%3==0) {
				System.out.print("X ");
			}else {
				System.out.print(i+" ");
			}
		}
	}

1084 : [기초-종합] 빛 섞어 색 만들기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		int[] array = Arrays.stream(s.split(" "))
				.mapToInt(Integer::parseInt)
				.toArray();
		
		int count=0;
		
		for(int i=0; i<array[0]; i++) {
			for(int j=0; j<array[1]; j++) {
				for(int k=0; k<array[2]; k++) {
					System.out.println(i+" "+j+" "+k+" ");
					count++;
				}
			}
		}
		System.out.println(count);
	}

1085 : [기초-종합] 소리 파일 저장용량 계산하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String key = sc.nextLine();
		
		String[] array = key.split(" ");
		
		double h = Double.valueOf(array[0]);
		double b = Double.valueOf(array[1]);
		double c = Double.valueOf(array[2]);
		double s = Double.valueOf(array[3]);
		
		System.out.printf("%.1f MB",(h*b*c*s)/8/1024/1024);
	}

1086 : [기초-종합] 그림 파일 저장용량 계산하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String key = sc.nextLine();
		
		String[] array = key.split(" ");
		
		double w = Double.valueOf(array[0]);
		double h = Double.valueOf(array[1]);
		double b = Double.valueOf(array[2]);
		
		System.out.printf("%.2f MB",(w*h*b)/8/1024/1024);
	}

1087 : [기초-종합] 여기까지! 이제 그만~(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int key = sc.nextInt();
		
		int sum=0;
		for(int i=0; i<=key; i++) {
			sum+=i;
			if(sum>=key) {
				System.out.println(sum);
				break;
			}
		}
	}

1088 : [기초-종합] 3의 배수는 통과?(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int key = sc.nextInt();
		
		for(int i=0; i<=key; i++) {
			if(i%3!=0) {
				System.out.print(i+" ");
			}
		}
	}

1089 : [기초-종합] 수 나열하기1

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		int a = Integer.parseInt(s.split(" ")[0]);
		int d = Integer.parseInt(s.split(" ")[1]);
		int n = Integer.parseInt(s.split(" ")[2]);
		
		for(int i=a; i<n; i++) {
			a+=d;
		}
		System.out.println(a);
	}

1090 : [기초-종합] 수 나열하기2

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		int a,r,n;
		a=Integer.parseInt(s.split(" ")[0]);
		r=Integer.parseInt(s.split(" ")[1]);
		n=Integer.parseInt(s.split(" ")[2]);
		
		for(int i=a; i<=n; i++) {
			a*=r;
		}
		System.out.println(a);
	}

1091 : [기초-종합] 수 나열하기3

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		int a,m,d,n;
		a=Integer.parseInt(s.split(" ")[0]);
		m=Integer.parseInt(s.split(" ")[1]);
		d=Integer.parseInt(s.split(" ")[2]);
		n=Integer.parseInt(s.split(" ")[3]);
		
		for(int i=a; i<n; i++) {
			a=a*m+d;
		}
		System.out.println(a);
	}

1092 : [기초-종합] 함께 문제 푸는 날(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		int a,b,c,day;
		a=Integer.parseInt(s.split(" ")[0]);
		b=Integer.parseInt(s.split(" ")[1]);
		c=Integer.parseInt(s.split(" ")[2]);
		
		day=1;
		
		while(day%a!=0 || day%b!=0 || day%c!=0) day++;
		System.out.println(day);
	}

[Algorithm] JAVA 코드업 기초 100제 (기초-반복실행구조) 1071 ~ 1077

큐범 — Sun, 4 Sep 2022 03:12:33 +0900

1071 : [기초-반복실행구조] 0 입력될 때까지 무한 출력하기1(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		
		String[] array = s.split(" ");
		
		for(String x : array) {
			if(!x.equals("0")) {
				System.out.println(x);
			}else {
				break;
			}
		}
	}

1072 : [기초-반복실행구조] 정수 입력받아 계속 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		int key = sc.nextInt(); 
		int[] array = new int[key];
		
		for(int i=0; i<array.length; i++) {
			array[i] = sc.nextInt();
		}
		
		for(int x : array) {
			System.out.println(x);
		}
		
	}

1073 : [기초-반복실행구조] 0 입력될 때까지 무한 출력하기2(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		
		while(true) {
			int i = sc.nextInt();
			
			if(i==0) break;
			System.out.println(i);
		}
	}

1074 : [기초-반복실행구조] 정수 1개 입력받아 카운트다운 출력하기1(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int i = sc.nextInt();

		while(i!=0) {
			System.out.println(i);
			i--;
		}
	}

1075 : [기초-반복실행구조] 정수 1개 입력받아 카운트다운 출력하기2(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int i = sc.nextInt();

		while(i!=0) {
			i--;
			System.out.println(i);
		}
	}

1076 : [기초-반복실행구조] 문자 1개 입력받아 알파벳 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		char c = sc.next().charAt(0);

		for(int i=97; i<=c; i++) {
			System.out.print(Character.toString(i)+" ");
		}
	}

1077 : [기초-반복실행구조] 정수 1개 입력받아 그 수까지 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int c = sc.nextInt();

		for(int i=0; i<=c; i++) {
			System.out.println(i);
		}
	}

[Algorithm] JAVA 코드업 기초 100제 (기초-삼항연산, 선택실행 구조) 1063 ~ 1070

큐범 — Sat, 3 Sep 2022 03:11:47 +0900

1063 : [기초-삼항연산] 두 정수 입력받아 큰 수 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		String[] data = s.split(" ");
		
		int a = Integer.valueOf(data[0]);
		int b = Integer.valueOf(data[1]);
		
		System.out.printf("%d", a>b?a:b);
	}

1064 : [기초-삼항연산] 정수 3개 입력받아 가장 작은 수 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		String[] data = s.split(" ");
		
		int a = Integer.valueOf(data[0]);
		int b = Integer.valueOf(data[1]);
		int c = Integer.valueOf(data[2]);
		
		System.out.printf("%d", (a<b ? a:b) < c ? (a<b?a:b):c);
	}

1065 : [기초-조건/선택실행구조] 정수 3개 입력받아 짝수만 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		String[] data = s.split(" ");
		
		for(int i=0; i<data.length; i++) {
			if(Integer.valueOf(data[i])%2==0) {
				System.out.println(data[i]);
			}
		}
	}

1066 : [기초-조건/선택실행구조] 정수 3개 입력받아 짝/홀 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		String[] data = s.split(" ");
		
		for(int i=0; i<data.length; i++) {
			if(Integer.valueOf(data[i])%2==0) {
				System.out.println("even");
			}else {
				System.out.println("odd");
			}
		}
	}

1067 : [기초-조건/선택실행구조] 정수 1개 입력받아 분석하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String s = sc.nextLine();
		String[] data = s.split(" ");
		
		for(int i=0; i<data.length; i++) {
			if(Integer.valueOf(data[i])>0) {
				System.out.println("plus");
			}else {
				System.out.println("minus");
			}
			if(Integer.valueOf(data[i])%2==0) {
				System.out.println("even");
			}else {
				System.out.println("odd");
			}
		}
	}

1068 : [기초-조건/선택실행구조] 정수 1개 입력받아 평가 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int i = sc.nextInt();
		
		if(i>=90) System.out.println("A");
		else if(i>=70) System.out.println("B");
		else if(i>=40) System.out.println("C");
		else if(i>=00) System.out.println("D");
	}

1069 : [기초-조건/선택실행구조] 평가 입력받아 다르게 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		String i = sc.nextLine();
		
		switch(i) {
			case "A":
				System.out.println("best!!!");
				break;
			case "B":
				System.out.println("good!!!");
				break;
			case "C":
				System.out.println("run!");
				break;
			case "D":
				System.out.println("solowly~");
				break;
			default:
				System.out.println("what?");
				break;
		}
	}

1070 : [기초-조건/선택실행구조] 월 입력받아 계절 출력하기(설명)

public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		int i = sc.nextInt();
		
		switch(i) {
			case 3:
			case 4:
			case 5:
				System.out.println("spring");
				break;
			case 6:
			case 7:
			case 8:
				System.out.println("summer");
				break;
			case 9:
			case 10:
				System.out.println("fall");
				break;
			default:
				System.out.println("winter");
				break;
		}
	}