DEVELOPyo

preferences -> file Types -> File type auto-detected by file content 선택 후 File name patterns 제거

DATADOG -> Integrations -> AWS Install -> Configure -> Account 선택 -> Metric Collection 에서 search -> enable

파일 간의 이동(hierarchy / reference 이동) 할 때 ctrl / command 키 + 클릭 으로 이동이 가능한데

"cannot find declaration to go to" alert 과 함께 이동이 안되는 현상.

[ 해결방법 ] 

src 폴더 우클릭 -> Mark directory as -> Sources Root 클릭

Cold Sequence

구독 할 때마다 타임라인이 새로 생성됨

구독하는 시점과 상관없이 첫번째로 emit 된 데이터부터 읽을 수 있음

ex) Flux.fromIterable(Array.asList("A", "B", "C")

subscribe(data -> Logger.info("data : {}", data) // ABC

subscribe(data -> Logger.info("data : {}", data) // ABC

Hot Sequence

타임라인이 하나만 존재

구독하는 시점에 따라 구독 시점 이후로 emit 된 데이터만 읽을 수 있음

ex) Flux.fromStream(Stream.of("A", "B", "C").delayElements(Duration.ofSeconds(1)).share()

subscribe(data -> Logger.info("data : {}", data) // A B

TimeUtils.sleep(2000)

subscribe(data -> Logger.info("data : {}", data) // C

* share() : cold 시퀀스를 hot 시퀀스로 변환해줌

Reactive System 설계 원칙

아래 네가지 원칙을 잘 반영한 시스템

Responsive : 응답성 즉각적인 응답

Resilient : 회복성 장애시 회복성

Elastic : 탄력성 작업량 변화에도 응답성을 유지하는 것

Message Driven : 비동기(async) 메시지 주고받아 느슨한 결합(loose coupling), 위치 투명성(location transparency) 보장

Reactive programming 특징

1) 데이터 소스에 변경이 있을때마다 데이터를 전파 - publisher 데이터 전파, subscriber 전파된 데이터를 받아서 처리

2) 선언형 프로그래밍 패러다임 : 실행할 동작을 구체적으로 명시하지 않고 목표만 정의 

3) 함수형 프로그래밍 기법 사용

명령형 프로그래밍 vs 선언형 프로그래밍

명령형 프로그래밍

List<Integer> numbers = Arrays.asList(1,3,21,10,8);
int sum = 0;

for (int number: numbers) {
 if (number > 6 && (number % 2 != 0)) {
   sum += number;
 }
}

선언형 프로그래밍

List<Integer> numbers = Arrays.asList(1,3,21,10,8);

int sum = numbers.stream()
	.filter(number -> number > 6 && number%2!=0)
	.mapToInt(number -> number)
	.sum();

Reactive Streams 란?

리액티브 프로그래밍을 표준화 한 명세

https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.3/README.md#specification

reactive streams 4가지 인터페이스

1) Publisher : 데이터 통제

2) Subscriber : 퍼블리셔가 통제한 데이터를 구독하는 구독자

3) Subscription : 구독 자체를 정의

4) Process : Publisher & Subsriber 역할을 동시에 할 수 있는 인터페이스

Reactive Streams 구현체

1) RxJava

2) Java 9 Flow API

3) Akka Streams

4) Reactor

5) RxJS, RxScala, RxAndroid 등..

참고 :

reactivemanifesto.org

Intellij Syntax highlighting has been temporarily turned off 에러 발생시

Bean 주입받는 모든 곳에서 import 에러 발생

File > Repair IDE 클릭 > 문제가 해결될 때 까지 Fix Next Step

출처 :

https://github.com/kotest/kotest-intellij-plugin/issues/168

서킷브레이커(CircuitBreaker)란

서킷브레이커 패턴이란 외부 서비스에 의한 문제를 방지하기 위해 등장한 디자인 패턴으로 문제가 발생한 지점을 감지하고 실패하는 요청을 계속하지 않도록 방지합니다.
그리고 이를 통해 시스템의 장애 확산을 막고 장애 복구를 도와주며 유저는 불필요하게 대기하지 않게 됩니다.
가정집에 있는 누전차단기가 화재를 막는 것과 비슷하게 CircuitBreaker(직역하면 회로차단기)는 서비스의 장애 전파를 막는다고 이해하면 됩니다.

아래 그림과 같이 ServiceA가 ServiceB를 호출 할 때
ServiceB가 반복적으로 실패한다면 CircuitBreaker 를 Open 하여 ServiceB에 대한 흐름을 차단하는게 서킷브레이커의 역할입니다.
* CircuitBreaker 의 Open 은 흐름을 차단하는 것으로, 흐름을 열어둔다(opened) 라는 의미가 아닙니다.
* 반대로 CircuitBreaker 의 Closed 상태는 흐름을 허용하는 정상상태를 의미합니다.

이미지 출처 : https://symphony.is/blog/service-resiliency-with-spring-boot-and-resilience4j

"CircuitBreaker 가 무엇인지 그리고 어떤 역할을 하는지 알았으니, 이제 CircuitBreaker의 상태인 Closed/Open/Half Open에 대해 좀 더 알아보겠습니다."

서킷브레이커의 3가지 상태

* 서킷브레이커에서 장애판단의 기준(Closed 상태에서 Open 이 되기 위해 카운팅 되는 실패의 기준)은 아래와 같습니다.

1) slow call : 기준보다 오래 걸린 요청

2) failure call : 실패하거나 오류 응답을 받은 요청

* slow call 과 failure call 은 CircuitBreaker의 프로퍼티로 정의되어 있으며 사용자가 특정 값으로 지정할 수 있습니다.

"아래는 CircuitBreaker 의 3가지 상태에 대해 이해를 돕기 위한 순서도와 그림입니다."

서킷브레이커 상태 변경

이미지 출처 : https://martinfowler.com/bliki/CircuitBreaker.html

서킷브레이커의 상태는 아래와 같이 변경됩니다.

1. 정상 요청 수행(Closed)

2. 실패 임계치 도달(Closed → Open)

3. 일정시간 소요(Open → Half Open)

4. 요청 수행

     a. 수행 결과 정상 (Half Open → Closed)

     b. 수행 결과 실패 (Half Open → Open) 

서킷브레이커 라이브러리 종류

1) Netflix Hystrix

넷플릭스에서 개발한 라이브러리로 MSA 환경에서 분산된 서비스간 통신이 원할하지 않을 경우 각 서비스가 장애 내성과 지연 내성을 갖게하도록 하는 라이브러리
현재는 deprecated 된 상태로 Resilience4j 사용을 권장

2) Resilience4j

Netflix Hystrix 로부터 영감을 받아 개발된 Fault Tolerance Library 
Java 전용으로 개발된 경량화된 라이브러리

"Netflix Hystrix 공식 doc에서도 Resilience4j 사용을 권장하고 있으니, Hystrix 를 사용할 이유가 없습니다.

Hystrix 에 대해 알아볼 필요 없이 바로 Resilence4j 에 대해 알아보겠습니다."

Resilience4j 의 코어 모듈

1) CircuitBreaker : 장애 전파 방지 기능 제공

2) Retry : 요청 실패시 재시도 처리 기능 제공

3) RateLimiter : 제한치를 넘어서 요청을 거부하거나 Queue 생성하여 처리하는 기능 제공

4) TimeLimiter : 실행 시간 제한 설정 기능 제공

5) Bulkhead : 동시 실행 횟수 제한 기능 제공

6) Cache : 결과 캐싱 기능 제공

Resilience4j 의 코어 모듈은 위와 같으며 필요한 모듈의 의존성을 설정해 주어 필요한 모듈만 사용할 수 있습니다.

Gradle 예시

dependencies {
  implementation("io.github.resilience4j:resilience4j-circuitbreaker:${resilience4jVersion}")
  implementation("io.github.resilience4j:resilience4j-ratelimiter:${resilience4jVersion}")
  implementation("io.github.resilience4j:resilience4j-retry:${resilience4jVersion}")
  implementation("io.github.resilience4j:resilience4j-bulkhead:${resilience4jVersion}")
  implementation("io.github.resilience4j:resilience4j-cache:${resilience4jVersion}")
  implementation("io.github.resilience4j:resilience4j-timelimiter:${resilience4jVersion}")
}

Resilience4j 모듈의 우선순위

Retry ( CircuitBreaker ( RateLimiter ( TimeLimiter ( BulkHead ( TargetFunction ) ) ) ) )

위와 같은 우선순위로 모듈이 적용됩니다. (Retry 모듈이 가장 마지막에 적용됨)

이를 알아보기 위해 resilience4j jar의 CircuitBreakerConfigurationProperties, RetryConfigurationProperties 클래스 내부를 살펴보면, 

CircuitBreaker 와 Retry 의 Order 값이 각각 -3, -4 로

별도 처리가 없을 경우 CircuitBreaker 가 Retry 보다 우선으로 적용됨을 알 수 있습니다.

CircuitBreakerConfigurationProperties

public class CircuitBreakerConfigurationProperties extends
    io.github.resilience4j.common.circuitbreaker.configuration.CircuitBreakerConfigurationProperties {

    private int circuitBreakerAspectOrder = Ordered.LOWEST_PRECEDENCE - 3;
    ...
}

RetryConfigurationProperties

public class RetryConfigurationProperties extends
    io.github.resilience4j.common.retry.configuration.RetryConfigurationProperties {

    private int retryAspectOrder = Ordered.LOWEST_PRECEDENCE - 4;
    ...
}

CircuitBreakerAspect 

@Aspect
public class CircuitBreakerAspect implements Ordered {
   ...
   @Override
    public int getOrder() {
        return circuitBreakerProperties.getCircuitBreakerAspectOrder();
    }
}

AOP 기반하에 동작하므로 우선순위를 바꿔서 적용하고자 할 경우 annotation 방식을 사용하여 layer 를 분리하거나 aspectOrder 속성값을 수정하여 적용할 수 있습니다.

Resilience4j Configuration

Resilience4j 의 Configuration 은 yml 파일을 사용하거나, java 코드를 통해 설정할 수 있습니다.

1) yml 파일을 사용한 Config 예시

resilience4j.circuitbreaker:
    configs:
        default:
            slidingWindowSize: 100
            waitDurationInOpenState: 10000
            permittedNumberOfCallsInHalfOpenState: 30
            failureRateThreshold: 60
            eventConsumerBufferSize: 10
        custom:
            slidingWindowSize: 50
            permittedNumberOfCallsInHalfOpenState: 10
            ... 생략

2) Java 코드를 통한 Config 예시

@Configuration
class CircuitBreakerProvider(
    val circuitBreakerRegistry: CircuitBreakerRegistry,
) {

    companion object {
        const val CIRCUIT_MEMDB: String = "CB_MEMDB"
    }

    @Bean
    fun memDBCircuitBreaker(): CircuitBreaker {
        return circuitBreakerRegistry.circuitBreaker(            
            CIRCUIT_MEMDB, CircuitBreakerConfig.custom()
                .failureRateThreshold(10F)  // 실패비율 10% 이상시 서킷 오픈
                .slowCallDurationThreshold(Duration.ofMillis(500))  // 500ms 이상 소요시 실패로 간주
                .slowCallRateThreshold(10F) // slowCallDurationThreshold 초과 비율이 10% 이상시 서킷 오픈
                .waitDurationInOpenState(Duration.ofMillis(60000))   // OPEN -> HALF-OPEN 전환 전 기다리는 시간
                .minimumNumberOfCalls(5) // 집계에 필요한 최소 호출 수
                .slidingWindowSize(5)    // 서킷 CLOSE 상태에서 5회 호출 도달시 failureRateThreshold 실패비율 계산
                .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.COUNT_BASED)    // 호출 횟수 기준 계산 (TIME_BASED는 시간 기준)
                .ignoreExceptions(StockManageException::class.java)   // 화이트리스트로 서킷 오픈 기준 ex 관리
                .build()
        )
    }

"Resilience4j 모듈 중 가장 많이 사용되는 CircuitBreaker, Retry 모듈의 속성값에 대해 간단히 알아보겠습니다."

Resilience4j CircuitBreaker Property

Resilience4j Retry Property

* 그외 모듈에 대한 속성값이 궁금하시다면 아래의 Resilience4j 공식 document 를 참고해주세요.

참고 : 

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

아래 쿼리를 DBeaver 에 복붙시 따옴표 자동 제거하기

@NamedNativeQuery(
    name = "example",
    query = "   SELECT EX_CD AS exampleCd" +
            "     FROM EXAMPLE",
    resultSetMapping = "example"
)

DBeaver -> 윈도우 -> 설정 -> 편집기 -> SQL 편집기 -> Auto format -> Extract SQL from source code 활성화

아래와 같이 문자열 (" 포함) 을 복사후, 

"   SELECT EX_CD AS exampleCd" +
"     FROM EXAMPLE",

DBeaver 에 붙여넣기 할 경우  Auto format 되어 SQL 만 추출됨

SELECT EX_CD AS exampleCd
FROM EXAMPLE

/remind [수신자or채널] [메시지] [알림시간] 

eg) /remind #스쿼드채널 데일리미팅 at 10:00am every weekday

/remind list : 리마인드 목록 확인

https://slack.com/intl/ko-kr/resources/using-slack/how-to-use-reminders-in-slack

https://slack.com/intl/ko-kr/help/articles/208423427-%EB%A6%AC%EB%A7%88%EC%9D%B8%EB%8D%94-%EC%84%A4%EC%A0%95

옮길 모니터 하단(모니터 제일 아래 최하단 끝에 닿게)에 마우스를 놓고 

스크롤 아래로 내리면 해당 모니터로 Dock 옮겨진다.