Blog by Eunyoung

GSLB에 매핑된 VIP 변경 작업 기록

Wed, 19 Mar 2025 00:00:00 GMT

이번에 클러스터 이관작업을 하면서 GSLB에 매핑된 VIP 변경도 진행하게 되었는데, 이에 대한 작업 이력을 기록한다.

✔︎ GSLB에 새로운 VIP 추가

새로운 vip 추가시, 트래픽 분배 방식을 ratio 로 설정. (기존 트래픽 방식은 round robin)
한 리전씩 1%로 설정하여 투입.

✔︎ 1% 투입 후 테스트

도메인에 매핑되는 IP를 강제하여 새로 투입된 VIP 연결에 문제가 없는지 확인한다.
TLS 또는 Pod까지 플로우에 문제가 없는지 체크

확인방법 1) /etc/hosts 파일 수정

여태 /etc/hosts 파일을 수정해서 curl 테스트를 진행했었는데, 파일 수정 후 curl 명령어를 수행하는게 번거로웠다.

$ curl -v https://digitaldocs.kakao.com -o /dev/null -s

* Host digitaldocs.kakao.com:443 was resolved.
* IPv6: (none)
* IPv4: 121.53.108.101
*   Trying 121.53.108.101:443...
* Connected to digitaldocs.kakao.com (121.53.108.101) port 443

확인방법 2) curl resolve 옵션

curl에 —resolve 옵션을 사용하여 ip를 강제 지정하는 방법이 있다.

$ curl -v --resolve digitaldocs.kakao.com:443:211.183.222.21 https://digitaldocs.kakao.com -o /dev/null -s

* Added digitaldocs.kakao.com:443:211.183.222.21 to DNS cache
* Hostname digitaldocs.kakao.com was found in DNS cache
*   Trying 211.183.222.21:443...
* Connected to digitaldocs.kakao.com (211.183.222.21) port 443

ip가 잘못 들어가면 커넥션에 실패한다.

$ curl -v --resolve digitaldocs.kakao.com:443:211.183.222.222 https://digitaldocs.kakao.com -o /dev/null -s

* Added digitaldocs.kakao.com:443:211.183.222.222 to DNS cache
* Hostname digitaldocs.kakao.com was found in DNS cache
*   Trying 211.183.222.222:443...
* connect to 211.183.222.222 port 443 from 172.20.40.200 port 50047 failed: Operation timed out
* Failed to connect to digitaldocs.kakao.com port 443 after 75000 ms: Couldn't connect to server
* Closing connection

✔︎ dig 명령어로는 1% 테스트가 잘 안된다?

dig(Domain Information Groper)는 DNS(Domain Name System) 정보를 조회하는 명령어로, 주로 도메인의 IP 주소, 네임서버(NS)를 조회하는데 확인한다.
/etc/hosts 파일 수정 후, dig 명령어를 이용해도 동일하게 강제 설정된 IP가 조회될 것이라고 생각했지만, 예상과는 다르게 ratio가 높은 IP가 조회되었다.

원인)

/etc/hosts는 로컬에서만 적용됨
- /etc/hosts는 OS의 로컬 DNS 해석 단계에서만 사용.
- 하지만 dig는 기본적으로 네트워크상의 DNS 서버를 직접 조회하기 때문에 /etc/hosts의 설정을 반영하지 않음.
dig는 시스템 DNS 설정을 무시하고 네트워크 쿼리를 수행
- dig example.com을 실행하면, 현재 설정된 DNS 서버(ex. 8.8.8.8 같은 공용 DNS)를 사용해서 실제 네트워크에서 조회한 결과를 반환.
- 즉, /etc/hosts 설정을 사용하지 않고, 네트워크에 등록된 공식적인 DNS 정보를 가져온다.

당신의 파드는 graceful 하게 종료되고 있을까?

Mon, 10 Mar 2025 00:00:00 GMT

1. Kubernetes에서의 Graceful Termination

쿠버네티스를 사용을 한다면, 파드를 graceful 하게 종료시키기 위해 deployment 매니페스트에 preStop Hook, terminationGracePeriodSeconds 를 설정하곤 한다.

✔️ preStop Hook

파드가 종료를 요청받고, 컨테이너가 종료되기 직전 실행되는 훅
애플리케이션이 종료 전에 필요한 작업을 완료할 수 있도록 시간을 줄 수 있으며,
이는 서비스의 중단을 최소화하고, 데이터 무결성을 보장하는데 도움이 된다.
시간을 길게 설정할수록 안정성은 좋아지나 애플리케이션 다운시간이 길어지는 트레이드 오프가 생긴다.

✔️ terminationGracePeriodSeconds

파드 내의 모든 컨테이너가 종료 작업을 완료할 수 있도록 주어지는 유예기간 (초단위)
preStop Hook 과 마찬가지로 데이터 무결성 보장, 서비스 가용성 유지, 안정성 확보 등의 이점이 있다.
기본값은 30초이며, 설정된 시간이 넘게되면 파드는 SIGKILL 신호로 즉시 종료된다.

예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      terminationGracePeriodSeconds: 60  # 유예 기간을 60초로 설정
      containers:
      - name: example-container
        image: example-image:latest
        lifecycle:
          preStop:
            exec:
              command: ["sh", "-c", "echo 'PreStop Hook Triggered'; sleep 10"]  # preStop Hook 명령 설정
        ports:
        - containerPort: 80

✔️ Kubernetes에서 파드가 종료되는 순서

그럼, 쿠버네티스에서 파드가 종료되는 순서를 알아보자.

1. 파드 삭제 요청

deployment rollout, scale down 등의 사용자 또는 시스템으로부터 파드 삭제 요청을 받는다.

2. 파드를 종료중 상태로 업데이트

K8S API 서버는 파드의 상태를 ‘Terminating’으로 업데이트를 하고, 해당 파드는 모든 서비스의 endpodint에서 제거된다.
이 시점에 파드는 새 트래픽 수신을 중지하게되고, 실행중인 요청은 정상적으로 처리한다.

3. preStop Hook 실행

파드에 ‘preStop’ 훅이 정의되어 있으면, 종료 신호를 받았을때 정의된 명령어가 실행된다.

4. 컨테이너에 SIGTERM 신호 전송

preStop Hook 이 완료되면, K8S는 파드 내 컨테이너들에게 SIGTERM 신호를 보낸다.
이때 DB연결, WebSocket 스트림 등 오래 지속되는 연결에 대한 중지가 일어난다.

5. Graceful Termination Period

K8S는 파드에 정의된 ‘terminationGracePeriodSeconds’ 동안 컨테이너가 종료되기를 기다린다.

6. 파드 제거

마지막으로 파드가 제거된다.
이때, Graceful Termination Period 후에도 컨테이너가 계속 실행 중이면, SIGKILL 신호가 전송되어 강제로 컨테이너가 종료된다.

유의할점.

Graceful Termination Period 와 preStop hook, SIGTERM signal이 병렬로 발생한다.
때문에 ‘애플리케이션이 종료 전에 필요한 작업을 완료할 수 있는 시간(preStop Hook 수행시간) + 애플리케이션 종료시간’ 보다 ‘terminationGracePeriodSeconds’ 시간이 커야 Graceful Termination이 보장된다고 봐야한다.
정상적인 Graceful Termination

terminationGracePeriodSeconds 시간이 충분치 않은 경우

2. 컨테이너에서의 Graceful Termination

적당한 preStop Hook, terminationGracePeriodSeconds 설정으로 Graceful Termination 이 되었을까?
나도 그런줄 알았지만.. 컨테이너에 함정이 숨어 있었다.
리얼 환경 배포시에 위 설정값을 충분히 크게 줘도 DB 커넥션이 애플리케이션에서 강제로 종료되는 현상이 발생하였고,
팀 내에서 아래 글을 발견하게 되었다.
https://vinodhinic.medium.com/are-you-sure-sigterm-is-received-by-your-application-in-kubernetes-885a3ce7ae4e

정리하면 도커는 2가지 방식, Shell과 Exec 방식을 지원하는데, 도커파일에서 애플리케이션 실행 구문에 어떤 방식을 사용하냐에 따라 kubelet이 보낸 SIGTERM이 실제로 애플리케이션에 수신이 되지 않는다는 점이다.

✔️ Shell 방식

컨테이너 내 shell에서 해당 명령을 실행하며, PID 1 인 프로세스는 shell 이 된다.
계층 순서는 ‘파드 > 컨테이너 > shell > 애플리케이션’ 이 된다.
kubelet이 SIGTERM 신호를 보내면 shell 프로세스에서 소비된다.

ENTRYPOINT java -Dspring.profiles.active=${APP_PHASE:-sandbox} -jar /app/app.jar

✔️ Exec 방식

컨테이너에서 바로 애플리케이션이 실행되며, PID 1인 프로세스는 애플리케이션이다.
계층 순서는 ‘파드 > 컨테이너 > 애플리케이션’ 이 된다.
kubelet이 SIGTERM 신호를 보내면 애플리케이션 프로세스에서 소비된다.
최대 단점은 환경변수를 사용할 수 없다는 것이다.

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

✔️Shell 방식의 컨테이너 내 애플리케이션 종료

내가 서비스하고 있는 애플리케이션의 dockerfile 설정은 shell 방식으로 되어 있었고,

kubelet에서 SIGTERM 신호를 보내도 shell 이 받아버려 Graceful Termination 을 위해 세팅되었던 K8S 설정들이 무의미 했다는걸 알게 되었다.

shell 방식의 애플리케이션 종료

✔️그래서 어떻게 적용해야하나?

보통은 환경변수를 통해 애플리케이션의 페이즈 등을 애플리케이션으로 전달하기 때문에, Exec 방식은 사용하기 힘들다. 그럼 어떻게 PID가 1 인 애플리케이션의 컨테이너 환경을 만들 수 있을까?

아래 해결책이 있다!!

K8S 매니페스트에 command 와 args 필드를 이용하여 ENTRYPOINT 에 정의된 내용을 재정의 할수있다.

https://stackoverflow.com/questions/44316361/difference-between-docker-entrypoint-and-kubernetes-container-spec-command

아래는 실제 수정된 deployment.yaml 파일이다.

ENTRYPOINT에 정의한 내용을 다시 정의하고 있다. 여기서는 환경변수 사용도 가능하다.

수정 전/후 PID 상태

3. 테스트 해보자

간단하게 DB Pool 가진 Springboot 애플리케이션을 만들어서 테스트 해본다.

✔️Exec 환경 테스트

Exec 방식으로 ENTRYPOINT 를 수행하여 도커 이미지를 빌드한다.

ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=docker", "/app/check-pid-0.0.1-SNAPSHOT.jar"]

컨테이너 실행 후, PID 확인을 하면 java 가 PID 1 이다.

해당 컨테이너에 SIGTERM 신호를 보내면

docker kill --signal=SIGTERM check-pid-exec

start 로그 이후에 DB Pool이 정리되는 로그가 보인다.

✔️Shell 환경 테스트

Shell 방식으로 ENTRYPOINT 를 수행하여 도커 이미지를 빌드한다.

ENTRYPOINT java \
  -Dspring.profiles.active=${APP_PHASE:-docker} \
  -jar /app/check-pid-0.0.1-SNAPSHOT.jar

컨테이너 실행 후, PID 확인을 하면 java PID는 7 이고, 이를 수행하는 /bin/sh 이 PID 1 이다.

해당 컨테이너에 SIGTERM 신호를 보내면

docker kill --signal=SIGTERM check-pid-exec

아무런 반응이 없다. 애플리케이션 종료가 안된다.

해당 컨테이너 종료 명령어를 수행하면

docker stop check-pid-exec

SIGTERM 신호를 전달하고 10초간 대기 후 SIGKILL 신호를 전달하여 강제 종료한다. (start 로그 이후에 아무런 로그가 없다.)

4. 애플리케이션이 SIGKILL 신호를 못받으면 무엇이 문제가 될까?

✔️ 맺고 있었던 DB 커넥션 등이 클라이언트에서 강제 종료가 된다.

애플리케이션(클라이언트)에서 커넥션이 강제 종료 되면, 클라이언트가 보낸 데이터가 DB에 적용되지 않을 수 있고,
클라이언트가 트랜잭션을 진행 중이었다면, 해당 트랜잭션은 롤백될 수 있다.
또한, 강제로 종료된 커넥션은 DB 입장에서 종료되지 않은 상태로 남아있을 수 있어 자원 누수로 이어질 수 있다.

실제 Shell 환경 테스트를 진행해보면, DB에 클라이언트가 비정상적으로 종료된 흔적이 남는다.

SHOW STATUS LIKE 'Aborted%';

Aborted_clients: 클라이언트가 비정상적으로 종료되어 서버가 연결을 중단한 횟수
Aborted_connects: MySQL 서버에 접속을 시도했으나 실패한 연결 횟수

✔️ 애플리케이션 종료 리스너가 수행하지 않는다.

애플리케이션이 종료될때 이벤트 리스너를 받아 필요한 로직을 수행하는 경우가 있을 것이다.
애플리케이션이 강제 종료되면, 리스너 수행이 되지 않아 문제가 된다.

✔️ 기타

애플리케이션이 강제 종료되면, 메모리 누수, 파일 디스크립터 누수 등의 문제를 초래할 수 있고,
서비스가 갑자기 중단되므로 해당 서비스의 가용성이 저하된다.

프로메테우스 삽질기

Thu, 23 Jan 2025 00:00:00 GMT

1. 무엇을 표현하고 싶었는가?

✔︎ 서비스 지표

발급 건수, 카드 종류별 건수, 실패 건수 등 카드 발급 현황에 대한 지표 구성

무엇을 고려 하였는가?

카드별 발급 건수 표시로 카드 선호도/수요 분석
카드 발급 실패에 대한 원인 파악

✔︎ traffic (트래픽)

서버로 들어오는 총 요청에 대한 파악을 위해 지표 구성

무엇을 고려 하였는가?

부하 확인
리전별 요청 비율로 리전 이상 현상 감지

✔︎ atency (지연)

응답 시간에 대한 파악을 위해 지표 구성

무엇을 고려 하였는가?

일반 사용자가 체감하는 응답 시간 - P95, 성공 응답 평균 시간

✔︎ errors (오류)

에러 응답에 대해 파악하기 위한 지표 구성

무엇을 고려 하였는가?

5xx/ 4xx 에러율 확인에 따른 이상현상 감지 및 에러 메시지 확인
연동서버 이상현상 감지

2.︎ 무엇이 어려웠는가? (왜 안맞나?, 표현이 어려웠던 것은 무엇인가? …)

2.1. promQL 문법의 이해

✔︎ `http_server_requests_seconds_count{uri="/api"}[5m]`

http_server_requests_seconds_count 메트릭을 사용할꺼고,
uri가 “/api” 인 데이터만 필터 할꺼고,
지금 시점부터 5분 전까지의 데이터를 추출
현재 2dzzv 파드에서 발생한 이벤트 총 카운트는 2건, cxw24 파드는 1건

✔︎ `increase(http_server_requests_seconds_count{uri="/api"}[5m])`

위 결과에서 증가건수 계산
시간에 따른 카운트 변화가 없으므로 증가는 0

2.2. 프로메테우스에서 수집하는 메트릭 중에 무엇을 사용했나?

✔︎ `http_server_requests_seconds_count`

서비스 시작 이후의 누적 요청 횟수

✔︎ `http_server_requests_seconds_bucket`

요청 응답 시간의 분포

2.3. 지표를 표현하기 위해서 어떤 함수를 사용했는가?

✔︎ 단순히 카운터로 누적 수를 계산하면 될꺼 같은데, 왜 increase, rate 를 사용했을까?

프로세스가 재실행 될 경우 해당 메트릭의 값이 0으로 리셋된다.
increase, rate 함수는 리셋을 스스로 감지하여 이전 상태를 보정하여 증가량을 계산한다.

아래와 같이 카운터의 결과가 나왔을때, 각 increase의 값을 더해서 누적 수를 계산한다.

시간      누적수   증가
13:00:00 100
13:01:00 200 -> 100
13:02:00 300 -> 100
13:03:00 150 -> 0 (리셋 이벤트 발생)
13:04:00 0
13:05:00 0
13:06:00 50  -> 50
13:07:00 100 -> 50
--------------------
increase 결과: 300

✔︎ increase

주어진 시간 범위 내에서 카운터 값의 총 증가량

5분동안 요청된 총 증가량

increase(http_server_requests_seconds_count[5m])

✔︎ rate

초당 증가율

5분동안의 초당 증가율

rate(http_server_requests_seconds_count[5m])

✔︎ histogram_quantile

히스토그램 데이터 기반으로 특정 분위수(예: 50%, 90%) 값을 추정하는 데 사용
5분동안의 초당 증가율을 구하는데, 상위 1%는 제외하여 연산한다.
```
histogram_quantile(0.9, rate(http_server_requests_seconds_bucket[5m]))
```

✔︎ 왜 소수가 나올까?

선형 보간을 수행하기 때문이다.
실제 요청이 특정 시점에 몰려 있더라도 일정한 속도로 증가한다고 가정하여 1.009와 같은 소수점 값이 나올 수 있음.
보간: 주어진 데이터 사이의 값들을 추정하여 새로운 값을 생성하는 방법
참고:
https://promlabs.com/blog/2021/01/29/how-exactly-does-promql-calculate-rates/
https://velog.io/@skynet/Prometheus-rate-%EC%97%B0%EC%82%B0%EC%9D%98-%EC%8B%A4%ED%96%89-%EC%9B%90%EB%A6%AC

2.4. 그래서 그라파나에서 어떻게 사용하는데?

그라파나에서는 프로메테우스 웹 ui와는 다르게 from, to, step 를 추가 설정한다.

✔︎ from, to(range) 의 총 수치 나타내기

그라파나에서 지정한 시간 범위의 총 수치를 표현하기 위해서는 $__range 변수를 사용한다.

✔︎ 시간 흐름에 따른 수치 나타내기

시간 흐름에 따른 수치를 표현하기 위해서는 [계산시간범위:step] 을 사용한다.
아래 쿼리는 (sum by (uri) (rate(httpserverrequestssecondscount{namespace=“$namespace”, uri!~”^(/actuator|/swagger|/api-docs).*“}[1m:1m]))),
- 1. 그라파나에서 지정한 시간 범위(24h)를
- 1. 1분마다 쪼개 초당 증가율을 구하는데,
- 1. x축의 기준을 1분 단위로 가져간다.

두 포인트간 사이는 1분

2.5. 왜 기대한 값이 나오지 않을까?

rate, increase 를 쓰면 총 건수에 대한 값이 정확히 노출 될 줄 알았지…

✔︎ 소수로 나타나지는 결과

위에서 설명한 것 처럼 보간법 때문에 정수가 아닌 소수로 나타날 수 있다.

✔︎ 카운터 리셋 감지시에 기대와 다른 increase 결과

롤아웃 후, 각 파드 별로 1건의 요청이 들어왔을때, increase 의 결과는 1이 아니라 0으로 표시가 된다.
- 카운트가 0→1 로 변하는게 아니라 NaN → 1로 변화하는걸로 예상
때문에, 정확한 총 건수에 실패하며, 파드 수가 많을 수록 누락되는 건수가 많아 진다.

http_server_requests_seconds_count{uri="/card-types/{cardType}/intro"}[5m] 결과

increase(http_server_requests_seconds_count{uri="/card-types/{cardType}/intro"}[5m]) 결과

2건의 요청이 들어왔을땐?

http_server_requests_seconds_count{uri="/card-types/{cardType}/intro"}[5m] 결과

increase(http_server_requests_seconds_count{uri="/card-types/{cardType}/intro"}[5m]) 결과

2.5. 아쉬운 점

프로메테우스를 통해 수집한 지표들은 정확한 “건수”를 도출하기 힘들다.
실제, 건수가 많은 지표에 10건 이하의 건수 누락은 크게 문제가 안되겠지만, 카드 발급 현황의 경우, 파드 수 만큼 개수가 빠지므로 크게 표시가 남.
따라서, 정확한 건수를 위한 지표보다는 현황 및 이상 감지 용도로 적합하다.

rateLimit 고민 기록

Sun, 14 Jul 2024 00:00:00 GMT

이번에 톡사원증이 오픈을 하게 되었다.
톡사원증은 특정 증명서 발급을 통해 회사 이력을 카드로 인증해주는 서비스이다.
요 기쁜 소식을 사내에 오픈 공지를 올렸을때, 순간적으로 트래픽이 살짝 높아지게 되었는데, 이때 증명서 발급 신청 건이 우수수 실패가 되었다.

맙소사… 아직 대외로 오픈소식을 알리기도 전인데 이게 왠 날벼락인가…
이대로라면 프로모션시에 큰 장애가 날 듯 싶어 급하게 rate limiter 를 개발하게 되었다.

요구사항은,

증명서 별로, 발급 신청시 rate limit 을 적용한다.
분산환경에서 동작해야 한다.
발급신청시에 요청수 체크 및 카운트를 증가 시키고, 그외 특정 api 들에서도 요청수 체크를 할 수 있어야 한다.

구현방법

rate limit 를 구현하는 방법은 다양하다.

nginx에서 사용자 IP 별 요청을 제한하거나 어플리케이션 단에서 queue를 이용하는 방법, 또는 redis 를 이용하는 방법 등 여러가지 방법이 있는데, 이중 최대한 쉽게 구현할 수 있는 redis 를 사용하기로 했다. (예시도 많고..)

그리고 방법은 2가지를 정할 수 있는데,

구현방법1) 고정 윈도 카운터

타임라인을 고정된 윈도우로 나누고, 각 윈도우마다 카운트 체크를 한다.
카운트가 임계치를 넘어가면 새로운 윈도우가 열릴때까지 요청은 버려진다.

고정 윈도 카운터의 단점

이 방법은 redis 공식 문서에도 소개된 만큼 구현하기 쉬운 장점이 있지만, (https://redis.io/docs/latest/commands/incr/)
아래와 같이 윈도우 경계부근에서 일시적으로 많은 트래픽이 몰려드는 경우에는, 기대했던 시스템의 처리 한도보다 최대 2배의 많은양을 처리하게 된다.

ts = CURRENT_UNIX_TIME()
keyname = key+":"+ts
MULTI
    INCR(keyname)
    EXPIRE(keyname,10)
EXEC
current = RESPONSE_OF_INCR_WITHIN_MULTI
IF current > 100 THEN
    ERROR "too many requests per second"
ELSE
    PERFORM_API_CALL()
END

구현방법2) 이동 윈도우

매번 현재시간을 기준으로 윈도우를 나누고, 각 윈도우마다 카운트 체크를 한다.

이동 윈도우의 단점

위 그림만 봐서는 고정 윈도우의 단점을 해결 할 수 있을 듯.. 보였지만
실제 구현 방법을 보면 이 방법도 함정이 보인다..ㅠㅜ

current = 0
MULTI
ZREMRANGEBYSCORE $key 0 ($currentTime - $slidingwindow)
current = ZRANGE $key 0 -1
EXEC

IF current > 100 THEN
ERROR "too many requests per second"
ELSE
PERFORM_API_CALL()
MULTI
ZADD $key $currentTime
EXPIRE $key $slidingwindow
EXEC

위 코드는 sorted set를 이용한 이동 윈도우 구현 방법이고, 데이터는 현재 시간이 들어간다.
sorted set 이기 때문에 시간순으로 정렬이 되며, ZREMRANGEBYSCORE 명령어를 이용하여 현재 윈도우에서 제외되는 데이터를 지운다.

이때, ZREMRANGEBYSCORE 명령어와 ZADD 명령어는 한 트랜잭션에 존재하지 않기 때문에 정말 짧은 순간에 트래픽이 몰렸을 경우, 방어가 되지 않는 문제가 생긴다.

그래서 결론은?

각 단점을 다시 정리하면,

고정윈도우는, 정해진 시간(윈도우)에 burst traffic 발생시에 최대 2배 처리가 되고,
이동윈도우는, 동일하거나 정말 짧은 시간에 burst traffic 발생시 아예 방어가 안된다.

하지만 전자증명서 서비스 특성상, 정말 짧은시간에 burst traffic이 발생할 확률보단 정해진 시간에 burst traffic 이 발생할 확률이 높아 두번째 방법을 선택하게 되었다.

아직 개발 전이지만.. 시간이 너무 촉박하다ㅠㅜ 어휴

스프링 배치작업 기록

Sat, 22 Jun 2024 00:00:00 GMT

스프링 배치를 사용하여 매일 한번씩 카카오 계정 서버에서 휴면/탈퇴 계정 목록을 가져와 내가 담당하고 있는 서비스를 탈퇴 시키는 작업을 진행했고, 이에 대한 기록을 남긴다.

1. 요구사항

매일 휴면계정 목록을 가져와서 카카오 전자증명서 서비스를 탈퇴시킨다.
매일 탈퇴계정 가져와서 카카오 전자증명서 서비스 탈퇴 및 DB에 저장된 증명서 발급 내역 테이블에서 개인정보 컬럼을 null로 업데이트한다.

2. 배치 스케줄러를 어떻게 수행할 것인가?

2.1. k8s cronJob + api 서버

방법

스케줄러는 k8s cronJob 이 담당
배치 작업을 수행하는 api 를 생성하며, cronJob이 해당 api를 호출한다.
해당 api 의 배치 로직 실패시에 알람 구현 필요

배치 오류 발생시?

상세 에러 내용은 kibana에서 확인 (es에 서빙이 되도록 로그 작업 필요)
배치 작업을 수행하는 api 를 수동으로 호출 필요

2.2. jenkins + api 서버

방법

스케줄러는 jenkins cron이 담당
배치 작업을 수행하는 api 를 생성하며, jenkins가 해당 api를 호출한다.
실패에 대한 알람은 jenkins 플러그인 사용

배치 오류 발생시?

상세 에러 내용은 kibana에서 확인 (es에 서빙이 되도록 로그 작업 필요)
- 배치가 오래 걸릴수 있으니 http 커넥션을 계속 맺고 있을수 없다고 판단, @Async 어노테이션을 이용하여 비동기로 수행. 때문에 젠킨스에 배치에 대한 호출로그는 남겠지만, 수행 로그는 남지 않음.
수동으로 실행하는 젠킨스 파이프라인 미리 생성하여 해당 파이프라인 수행.

2.3. jenkins + springbatch

방법

스케줄러는 jenkins cron이 담당
배치 작업은 spring batch가 담당, jenkins cron은 springbatch 애플리케이션 파드를 실행시킴
수행 시간에 파드가 생겼다가 작업이 끝나면 사라짐.
실패에 대한 알람은 jenkins 플러그인 사용

배치 오류 발생시?

상세 에러 내용은 젠킨스 수행 로그에서 확인
수동으로 실행하는 젠킨스 파이프라인 미리 생성하여 해당 파이프라인 수행.

3번 사용 결정 이유

배치를 위한 파드(서버)를 계속 띄울 필요 없이, 배치가 수행되는 시간에만 파드를 띄울수 있다는 장점이 있다.
- 리소스 절약 및 서버에 대한 관리가 불필요.
- 파트 내에 이미 kubernetes plugin 이 설치된 젠킨스가 있어서 세팅이 간단 했던것도 한몫함.
  - Jenkins kubernetes plugin
한 곳에서 (jenkins) 수행 로그(결과 또는 에러 로그) 확인 및 재수행(retry)을 진행할 수 있다는 장점이 있다.
- api로 수행을 할 경우, 수행 로그 확인과 재수행(retry) 위치가 달라진다.

3. spring batch 작업을 진행하면서 겪은 일

3.1. multi datasource 설정

spring batch 를 사용하기 위해서는 기본적으로 필요한 메타 테이블들이 존재한다.
해당 테이블은 비즈니스 로직에서 사용하는 DB에 생성하기에는 너무 불필요한 테이블이였다.
때문에 비즈니스 DB와 spring batch DB를 분리하기로 결정.
- 비즈니스 DB는 기존대로 mysql 사용, spring batch DB는 h2 사용.
- 파드가 생성되어 애플리케이션이 시작될때 h2 로드 및 아래 spring batch 메타 테이블은 h2에 생성.
- 애플리케이션이 종료되면 h2에 생성된 테이블 삭제 및 h2도 같이 종료. (메타 테이블에 저장된 배치 이력 데이터 사라짐)

비즈니스 로직에서 사용하는 DB(mysql) 설정(application.yaml)

spring:
  jpa:
    database: mysql
    database-platform: org.hibernate.dialect.MySQL8Dialect
    ...

spring batch에서 필요한 메타 데이터 테이블 생성을 위한 설정 (BatchConfig.kt)

@EnableConfigurationProperties(BatchProperties::class)
@Configuration
class BatchConfig {
		// @Bean 없이 생성해야 primany datasource bean 은 mysql 이 된다.
    private val batchDataSource =
        EmbeddedDatabaseBuilder().setType(EmbeddedDatabaseType.H2)
            .addScript("classpath:org/springframework/batch/core/schema-drop-h2.sql")
            .addScript("classpath:/org/springframework/batch/core/schema-h2.sql")
            .build()

		// 메타 테이블 스키마에 대한 초기화를 진행한다. 해당 설정이 없으면 테이블 생성은 mysql에 생성된다.
    @Bean
    fun batchDataSourceInitializer(
        resourceLoader: ResourceLoader?,
        properties: BatchProperties?,
    ): BatchDataSourceInitializer =
        BatchDataSourceInitializer(
            batchDataSource,
            resourceLoader,
            properties,
        )

		// 배치설정를 진행하며, 여기서 설정된 datasource에 배치 메타 데이터에 대해 crud 가 발생
    @Bean
    fun batchConfigurer(): BatchConfigurer = DefaultBatchConfigurer(batchDataSource)
}

3.2. JPA로 수행되는 CUD 쿼리가 수행이 안되는 현상.

위처럼 생성하게 되면 batch 관련 DataSource 는 h2 기준으로 생성이 된다.
Spring Batch는 기본적으로 DataSourceTransactionManager 를 사용하므로 JPA로 수행되는 쿼리도 해당 트랜잭션 매니저로 수행이 된다.
DataSourceTransactionManager으로 수행이 되면 JpaTransaction이 생성되지 않아 기본 쿼리인 조회(select)만 수행이 가능하게 된다.
이를 해결하기 위해 JpaTransaction bean을 생성하여 batch job에 주입해준다.

@Configuration
class JpaConfig {
		// datasource bean 은 mysql 이다.
    @Bean
    @Primary
    fun jpaTransactionManager(dataSource: DataSource): JpaTransactionManager {
        return JpaTransactionManager().apply { this.dataSource = dataSource }
    }
}

class JobConfig {
		@Bean
    fun dormantStep(
        jpaTransactionManager: JpaTransactionManager,
    ): Step {
        return stepBuilderFactory["dormantStep"]
            .tasklet(dormantUserTasklet)
            .transactionManager(jpaTransactionManager)
            .build()
    }

    @Bean
    fun dormantJob(
        dormantStep: Step,
        jobCompletionListener: JobExecutionListener
    ): Job {
        return jobBuilderFactory["dormantJob"]
            .listener(jobCompletionListener)
            .start(dormantStep)
            .build()
    }
}

3.3. index가 없을 경우 update, delete 쿼리가 수행되면?

update, delete 쿼리에 필요한 인덱스를 DB팀에 요청 후에 jenkins 세팅을 하게 되었다.
리얼에서 파이프라인 세팅 및 테스트를 하다가 실수로 spring batch job을 수행하게 되었다.
갑자기 약 1-2분간 ‘PessimisticLockingFailureException’ 오류가 발생하여 서비스 불능 상태가 되었고, batch job 수행이 완료된 후 락이 풀렸다.
where 절로 인해 테이블 전체가 Lock이 걸리진 않을거라고 예상했는데… InnoDB에서 UPDATE또는 DELETE는 where 절과 상관없이 스캔된 모든 인덱스 레코드에 잠금을 건다. 수행 당시에는 조건에 걸린 필드에 인덱스가 없었기 때문에 모든 row에 락이 걸리게 된 것이다.
- https://dev.mysql.com/doc/refman/8.4/en/innodb-locks-set.html
실시간 서비스에서 서치가 오래걸리는 update, delete 의 경우는 꼭꼭 인덱스를 세팅하고 수행하자.

4. Transaction 이 너무 긴 현상

class ATestlet() : Tasklet {
	override fun execute( {
		...
		loop (100) {
			run()
		}
	}
}

class RunnerClass() {
	@Transactional
	fun run() {
		...
	}
}

한개의 tasklet 을 사용하여 loop를 돌며 트랜젝션 어노테이션이 붙은 함수를 수행하도록 하였고, 해당 함수에서는 update, delete 쿼리가 수행된다.
loop 가 한번 돌떄마다 commit 이 발생할 것이라고 예상했는데, 예상한바와 다르게 프로세스가 끝나야 실제 DB에 반영이 되었다.
해당 원인파악은 아직 못한 상태…

Circuit 적용 고민

Sat, 15 Jun 2024 00:00:00 GMT

현재 맡고 있는 서비스는 정부전자문서지갑 API에 대한 의존도가 높은데, 이 API는 장애가 잦은 편이다. 장애가 발생하면 서비스 응답 속도가 느려지고, 결국 사용자 경험이 나빠진다.
이런 문제를 해결하기 위해 Circuit Breaker 적용을 좀 더 세분화하여 진행했다.
기존에는 큰 기능 단위로만 Client Bean을 나누었지만, API 특성별로 더 세분화하여 대응하기로 했다.

1. Client Bean 세분화

일반적으로 외부 API를 호출하는 Client Bean은 host 단위로 생성한다. 하지만 장애가 잦은 API에 대해 더 정밀한 대응이 필요했기에, 장애 유형별, 구간별로 Client Bean을 추가 분리했다. 분리된 client들은 서로 중복으로 api path를 가질 수 있으며, 각 client 객체는 호출되는 시점이 다르다.

✔︎ 구조 개선

기존 구조 (AS-IS)

개인 전자문서 지갑 관련 api 연동 client bean
수취기관 관련 api 연동 client bean
증명서 신청/제출 등 api 연동 client bean

개선된 구조 (TO-BE)

장애가 자주 발생하는 api별 client bean 생성
- 증명서 신청을 위한 부가정보 조회 api 전용 client bean
- 사용자의 전자문서지갑 상태 조회 api 전용 client bean
점검 유형 정하기 위한 구간별 client bean
- 전자증명서 홈 진입 시 사용되는 api 전용 client bean
- 증명서 신청 플로우에서 사용되는 api 전용 client bean
- 증명서 보냄/받음 플로우에서 사용되는 api 전용 client bean
- 내 증명서 확인 플로우에서 사용되는 api 전용 client bean
그외 api 전용 client bean 생성

✔︎ 적용 효과

서비스 특성상 read timeout이 15초로 설정되어 있었고, 정부전자문서지갑 서버는 Timeout 에러가 자주 발생하는 상태였다.

Circuit Breaker가 오픈되면서

15초 동안 기다리지 않고 빠르게 사용자에게 오류 페이지로 랜딩이 가능했다.

Client Bean을 세분화하면서

어떤 플로우가 문제인지 좀 더 명확하게 파악할 수 있었다.
점검 종류를 빠르게 파악이 가능하여 빠른 대응이 가능했다.

2. 불필요한 Pod 수 조정

Circuit Breaker는 각 파드에서의 에러율을 기준으로 동작하기 때문에, 트래픽 대비 Pod 수가 많으면 서킷이 제대로 동작하지 않는 문제가 있다.
현재 트래픽에 비해 설정된 Pod 수가 많았고, 적절한 Pod 개수로 조정하여 서킷이 정상적으로 동작할 수 있도록 했다.

✔︎ 적용 효과

트래픽이 많지 않은 시간대 & 요일에도 Circuit Breaker가 정상적으로 동작하도록 개선됨.

3. Sliding Window 타입 결정

Resilience4j의 Circuit Breaker는 아래 2가지 Sliding Window 방식을 지원한다. 참고

Count-based Sliding Window

요청 개수 단위로 데이터를 저장하고 집계하는 방식

Time-based Sliding Window

요청 시간 단위로 데이터를 저장하고 집계하는 방식

처음에는 Time-based 방식을 고려했지만, Client Bean 세분화 및 낮은 트래픽을 가진 서비스의 특성을 고려하여 Count-based로 결정했다.

✔︎ 적용 효과

트래픽이 낮은 늦은 밤, 새벽 시간대에도 서킷이 동작하도록 개선 됨

4. Fallback 적용 여부

✔︎ Fallback이란?

서비스를 차단한 경우, 예외를 발생시키는 대신 미리 준비된 동작을 실행하는 것을 의미한다.
즉, Circuit Breaker가 Open 상태일 때 요청을 에러로 응답하지 않고, 대체 응답을 제공하는 방식이다.

이번 작업의 목표는 빠르게 에러를 감지하고 사용자에게 안내하는 것이었기 때문에, Fallback을 적용하지 않고 즉시 에러 안내 페이지를 노출하도록 했다.

5. 최종 정리

장애가 자주 발생하는 API별로 Client Bean을 세분화하여 장애 감지 속도를 높임
Pod 개수를 조정하여 Circuit Breaker가 정상 동작하도록 개선
트래픽 특성을 고려해 Count-based Sliding Window 방식 적용
Fallback을 사용하지 않고 빠른 에러 안내 제공

nginx proxy serving 이슈

Sat, 15 Jun 2024 00:00:00 GMT

1. 구조 파악

구조가 좀 복잡하다…

모바일에서 요청시에 제일 먼저 webapp nginx 로 요청이 들어오고
사용자 인증을 위해 에서 kakaotalk pilsner server 프록시 하고
pilsner 서버에서 계정 인증 후 webapp server 로 또 프록시 된다.
그리고 webapp으로 프록시된 요청은 실제 api 서버로 요청을 하게된다.

요청 흐름도)

모바일 → webapp server -(proxy)→ 필스너 서버 -(proxy)→ webapp server -(proxy)→ 디지털카드 api server

응답 흐름도)

디지털카드 api server -(proxy res)→ webapp server -(proxy res)→ 필스너서버 -(proxy res)→ webapp server → 모바일

2. 이슈 내용

간헐적으로 모바일에서만 정적파일(js, css, html) 서빙시에 타임아웃 발생 또는 css가 깨진 화면이 노출

3. 원인

talk-pilsner OS upgrade를 작업을 위해 gslb 내 vip 하나를 Down 하였고,
webapp nginx 는 talk-pilsner dns의 변경사항을 감지하고 못하고 down 된 vip로 요청.
nginx는 proxy pass 할 talk-pilsner 도메인의 vip 목록을 서버 실행시 캐싱하여 계속 사용하기 때문에 down된 vip로 요청

4. 조치 내용

dns resolve 설정을 추가하여 talk-pilsner 도메인의 ip를 주기적으로 가져오도록 설정
인증이 불필요한 정적 파일은 talk-pilsner를 타지 않도록 수정.

resolver 10.20.30.40 valid=10s;
 
server {
    location / {
        set $talk_pilsner "talk-pilsner.kakao.com";
        proxy_pass http://$talk_pilsner;
    }
}

5. 참고 내용 - nginx 에서 도메인명을 이용하여 서비스를 검색하는 방법

5-1. proxy_pass 지시어에 도메인명 사용

가장 간단한 방법이지만 가장 유연성이 떨어지는 방법이며 다음과 같은 단점이 있다.

도메인 이름을 확인할 수 없는 경우 서버가 실행되지 않는다.
재시작 할때까지 DNS 레코드를 캐시하고 레코드의 TTL도 무시한다.
로드 밸런싱 알고리즘을 지정할 수 없다.

server {
    location / {
        proxy_pass http://talk-pilsner.kakao.com;
    }
}

5-2. Upstream Server Group에 도메인명 사용

로드 밸런싱 알고리즘을 지정할 수 있다. (ex> least_conn)

max_fails 를 지정하여 연속 요청이 지정한 횟수에 다다르면 서버가 다운 된것으로 표시.

다음과 같은 단점이 여전히 존재

도메인 이름을 확인할 수 없는 경우 서버가 실행되지 않는다.
재시작 할때까지 DNS 레코드를 캐시하고 레코드의 TTL도 무시한다.

upstream talk_pilsner {
    least_conn;
 
    server talk-pilsner.kakao.com max_fails=3;
}
 
server {
    location / {
        proxy_pass http://talk_pilsner;
    }
}

5-3. 변수에 도메인 이름 지정

도메인 이름을 다시 확인하는 빈도를 제어할 수 있다.

resolver valid 설정을 통해 지정된 시간마다 도메인 이름을 다시 확인 하도록 할수 있다.

도메인 이름을 확인 할 수 없을때 nginx 재시작 없이 서비스 탐색을 재시도 하기때문에 첫번째 방법의 두가지 단점을 보완할수 있다.

단, 로드 밸런싱 알고리즘을 지정 할 수 없다.

nginx plus를 사용하지 않는다면 가장 유연성이 높은 방법이다.

resolver 10.20.30.40 valid=10s;
 
server {
    location / {
        set $talk_pilsner "talk-pilsner.kakao.com";
        proxy_pass http://$talk_pilsner;
    }
}

GSLB에 대해 알아봅시다

Fri, 10 May 2024 00:00:00 GMT

1. GSLB 는 SLB와 무엇이 다른가?

SLB : Server Load Balancing
GSLB : Global Server Load Balancing
GSLB는 DNS + SLB
- 일반적인 DNS 기능 + LB Method 적용이 가능
- DNS는 단순 R/R 으로 IP만 응답함
- 위치(topology)를 기반으로 응답을 다르게 주거나
- Ratio를 줘서 6:4 등의 비율로 나누어 주거나
- 하는 등의 제어가 가능

2. SLB

구성단위는 VIP
VIP에 여러대의 서버를 바인딩
즉, LB가 실제 트래픽을 받는 구조, 때문에 트래픽 규모에 따른 한계가 있을 수 있다.

✔️ Traffic Flow

클라이언트는 DNS에서 도메인 주소의 IP 주소를 질의하여 얻어옴
레코드 타입: A (도메인에 IPv4 주소를 연결하는 방식)
이때 IP는 미리 등록한 SLB VIP
클라이언트는 DNS 질의를 통해 얻어온 VIP로 접속을 시도
해당 VIP를 가진 SLB는 Method에 따라 Client의 요청을 서버로 분배

✔️ Health Check

보통 아래 2가지를 방식을 표준으로 사용한다.
- L4 : TCP port check
- L7 : HTTP METHOD 를 사용하여 response code 또는 message 확인 (ex. health_check.html)
interval, response timeout, retry, down time 등의 정책을 정하여 헬스체크를 수행한다.

3. GSLB

구성단위는 도메인
도메인에 여러개의 서버 IP 혹은 VIP를 바인딩
도메인으로 들어오는 질의에 대해 GSLB에서 서버 IP 혹은 VIP를 응답
즉, GSLB는 DNS의 쿼리만 받음
- 클라이언트에서는 응답받은 서버 IP 혹은 VIP로 트래픽 전송
- 트래픽의 규모와는 직접적으로 연관이 없음
- DNS 질의양(QPS)에 따른 영향은 있을 수 있으나, 큰 문제가 되는 경우는 적음

✔️ Traffic Flow

클라이언트는 DNS에서 서비스 도메인 주소를 질의하여 얻어옴
레코드 타입: CNAME (Alias 형태로 다른 도메인을 연결하는 방식)
이때는 결과값은 GSLB의 도메인
클라이언트는 DNS 질의를 통해 얻어온 GSLB 도메인으로 다시 질의
요청을 받은 GSLB는 Method에 따라 VIP 또는 서버 IP를 응답
클라이언트는 질의를 통해 얻어온 VIP 또는 서버 IP로 접속을 시도

5-1. VIP로 시도했다면, 해당 VIP를 가진 SLB는 Method에 따라 Client의 요청을 서버로 분배

5-2. 서버 IP로 시도했다면, 바로 서버로 접근

✔️ Health Check

DNS는 H/C 가 안되지만, GSLB는 바인딩된 VIP 혹은 서버 IP에 대해 SLB H/C 가 가능

4. 도메인 구성은 어떻게 해야 하는데?

서비스 도메인 > CNAME : GSLB 도메인 > VIP 또는 서버IP

서비스 도메인 my-service.com 설정
- 레코드 타입: CNAME
- TTL : 600
- 레코드 값: my-service-hash.kgslb.com
GSLB 도메인 my-service-hash.kgslb.com 설정
- 레코드 타입: A
- 트래픽 분배 방식: R/R
- H/C : TCP 443, 80
- 레코드 값
- vip 10.1.1.1, 설정트래픽 50%
- vip 10.1.1.2, 설정트래픽 50%

5. H/C 는 어떻게 동작하고 있는거지?

아래 L4, L7 H/C 동작을 보면, L4는 80포트 커넥션 확인만, L7는 HTTP 요청까지 진행한다.

뭐가 더 좋을까?

✔️ L4 H/C

GSLB ↔ SLB, SLB ↔ 서버 각각 H/C 를 진행한다.

✔️ L7 H/C

GSLB ↔ 서버 H/C 진행도 가능하다.
때문에, 최종 endpoint 까지의 H/C 가 가능하다는 점에서 L7 H/C 가 매력적으로 보인다.

✔️ L7 H/C를 사용하는게 항상 좋을까?

SRV#2가 H/C에 실패하면
GSLB도 SLB#1 H/C를 실패로 간주할 수 있고,
실패로 간주되면 GSLB에서 VIP1이 다운이되어 Datacenter#1 로 트래픽 요청이 끊길 수 있다는 점을 고려해야하기 때문에 보통은 L4 H/C를 사용한다.

Backoff 정책 정리

Sat, 23 Mar 2024 00:00:00 GMT

진행하고 있는 프로젝트에서 사용하고 있는 backoff 내용을 정리한다.
사용중인 메시지 브로커: RabbitMQ

1. 용어 정리

✔︎ Exchange

Producer로 부터 전달받은 메시지를 어떤 큐들에게 발송할지 결정하는 객체
4가지의 타입이 있으며, 라우터 기능을 한다.
타입 4가지
- Direct: 라우팅 키가 정확히 일치하는 큐에 메시지 전송 (unicast)
- Topic: 라우팅 키 패턴이 일치하는 큐에 메시지 전송 (multicast)
- Headers: [key:value]로 이루어진 header값을 기존으로 일치하는 queue에 메시지 전송 (multicast)
- Fanout: 해당 exchange에 등록된 모든 큐에 메시지 전송 (broadcast)

✔︎ Binding

Exchange와 큐를 연결하는 관계
모든 메시지는 Exchange가 가장 먼저 수신하는데, Exchange 타입과 binding 규칙에 따라 적절한 큐로 전달된다.

✔︎ Dead Letter Queue(DLQ)

오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 메시지 대기열
소스 대기열에 처리되지 않은 메시지가 넘치지 않도록 잘못된 메시지 및 실패한 메시지의 임시 저장소 역할을 수행한다.
DLQ에 TTL을 지정하여, 일정 시간이 지난 후 다시 작업 큐로 라우팅 되도록 한다.

일반적인 메시지 큐에서 메시지가 정상적으로 소비되지 못하면 어떻게 될까?

계속 큐에 들어가게 되어 무한 재시도 수행, 이는 시스템 부하의 원인이 됨
무한 대기 상태가 되면 큐가 가득 차서 다른 메시지도 처리 불가능

문제가 있는 메시지는 기록하고 분석할 필요가 있기 때문에 RabbitMQ, Kafka 같은 메시지 브로커는 이런 메시지를 별도의 “Dead Letter Queue(DLQ)“에 저장하도록 지원

2. 구조

담당중인 서비스의 기능 중, 파트너사에 요청한 작업 상태를 polling 방식으로 체크하여 작업 완료시 사용자에게 알림을 보내는 기능이 있다.
해당 기능은 비동기로 수행되며, 이를 위해 RabbitMQ를 사용중이고, 수행 플로우는 아래와 같다.

플로우

파트너사로 작업을 요청 후, polling을 위해 작업 큐에 메시지를 넣는다.
큐에 담긴 메시지를 consume 하여 해당 message 기반으로 파트너사 쪽으로 상태를 체크한다.
만약 내부 서비스 오류 또는 통신 오류 등, 재시도가 필요한 오류가 발생하게 되면, retry 큐에 들어가게 된다.
이때, backoff 정책에 의해, 재시도를 수행한 횟수에 따라 매번 다른 dead letter queue에 들어가게 된다.
DLQ에 지정된 TTL이 만료되면 다시 작업 큐에 들어가게 된다.

3. Backoff 구성

일반적으로 재처리를 위해 requeue를 하는 방법을 사용하는데, 처리 서버 부하로 인해 requeue 를 반복적으로 수행하면 이는 부하만 가중될 뿐이다. (최악은 DDos)
일정시간 간격을 두고 재처리를 하는것도 동일하게 부하가 될 가능성이 크다고 한다.
그래서 도입된게 Exponential Backoff 전략이였나보다.
- 찾아보니 이 역시도 한계가 있다고 하며, Jitter(지연변이)를 사용하는 곳도 있다고 한다.
- Jitter: 재시도 간격에 무작위성을 추가하여 요청하는 시간대를 분산시키는 개념

플로우

작업에 실패하게 되면 retry.x Exchange에서 해당 작업의 재시도 횟수를 확인하여 그에 맞는 DLQ로 라우팅한다.
DLQ에 들어온 메시지는 지정된 TTL 동안 머무른다.
TTL이 만료되면 backoff.x Exchange로 이동하게 되고, header 값에 저장되어 있는 작업 큐 이름을 확인하여 해당 작업 큐로 requeue 된다.
이렇게 실패 횟수에 따라 1초, 5초, 10초 … exponential 하게 재시도 시간을 증가시키며 특정 작업을 반복한다.

Aritable 의 대체 오픈소스 NocoDB

Sun, 30 Jul 2023 00:00:00 GMT

✔️ NocoDB?

Aritable 의 대체 오픈소스로, MySql, MariaDB, PostgreSql, SqlServer, Sqlite, Amazon Aurora 등 관계형 데이터베이스를 스마트 스프레드 시트로 변경하여 사용 가능한 툴이다.
DB 데이터 CRUD를 위한 어드민 페이지 대체용으로 아주 적합하다.

✔️ 설치하기

1. docker로 설치하기

1.1. docker image pull

$ docker pull nocodb/nocodb

1.2. docker run

DB(d=nocodb)가 없을 경우, DB계정(u=user)은 데이터베이스 및 테이블 생성 권한이 있어야 한다.

$ docker run -d --name nocodb-mysql \
-v "$(pwd)"/nocodb:/usr/app/data/ \ # 볼륨 마운트
-p 18080:8080 \
-e NC_DB="mysql2://host.docker.internal:3306?u=user&p=user_password&d=nocodb" \
nocodb/nocodb:latest

2. K8S로 설치하기

NocoDB를 구성하기 위해서는 DB가 필요하기 때문에 mysql 컨테이너와 함께 pod를 구성하도록 한다.
만약 별도로 DB가 구성되어 있다면, DB 컨테이너를 제거하고 NocoDB 컨테이너의 env 필드를 수정한다.
deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: noco-deploy
  namespace: noco
  labels:
    app: noco-deploy
spec:
  selector:
    matchLabels:
      app: noco-deploy
  replicas: 1
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: noco-deploy
    spec:
      containers:
        - name: noco-mysql
          image: mysql:5.7.40-debian # 상황에 맞게 이미지 주소 수정
          imagePullPolicy: Always
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: root
          ports:
            - containerPort: 3306

        - name: noco-deploy
          image: noco # 상황에 맞게 이미지 주소 수정
          imagePullPolicy: Always
          livenessProbe:
            httpGet:
              path: /dashboard
              port: 8080
            initialDelaySeconds: 60
            periodSeconds: 5
            failureThreshold: 2
          resources:
            limits:
              cpu: 1
              memory: 1Gi
            requests:
              cpu: 1
              memory: 1Gi
          ports:
            - containerPort: 8080
          env:
            - name: NC_DB
              value: mysql2://localhost:3306?u=root&p=root&d=noco

✔️ 주요기능 사용해보기 (0.109.5 Releases 기준)

1. Super Admin 계정 생성

처음 접속하면 super admin 계정을 생성하기 위한 sign up 화면이 뜬다.
패스워드는 최소 8글자 및 한개 이상의 대문자, 숫자, 특수문자를 포함해야 한다.
super admin 계정 생성 버튼을 누르면 계정 생성과 동시에 로그인이 되며, project 목록을 볼 수 있는 대시보드로 이동된다.

2. Project 생성

New Project 버튼을 클릭하여 project를 생성한다.
이때 기본적으로 base DB가 생성되며, 생성된 프로젝트 내에서 기존 DB를 연결할 수 있다.

3. 기존 DB 연결

Add new table 옆 three-dot 메뉴버튼을 클릭하면 connect to new datasource 항목에서 연결할 DB 종류를 선택한다.
연결할 DB 정보 기입 후 test database connection 버튼을 클릭하여 연결 확인 후 생성한다.

연결을 완료하면, 이미 생성된 테이블 및 데이터를 볼 수 있다.

4. 계정&권한

nocoDB는 계정 관리 및 권한 관리 기능을 가지고 있다.
Team & Auth 탭에서 사용자 생성 및 권한 부여를 할 수 있다.

invite 버튼을 클릭하면 초대 url이 생성되며, 해당 url 을 통해 계정생성이 가능하다.

invite url 로 접근하면 해당 계정에 대한 sign up 이 가능해진다.

5. 쿼리 API 사용

생성된 테이블에 대한 쿼리를 API를 사용하여 할 수 있다.
api에 대한 swagger도 제공해주는데, 이는 프로젝트 → swagger: REST APIs 버튼을 클릭하면 접속할 수 있다.

API를 사용하기 위해서는 Authorization이 필요한데, 이는 프로젝트 → Team & Settings → API Tokens Management 탭에서 token을 생성하여 사용하면 된다.

생성한 token 은 swagger 페이지에서 우측에 Authorize 버튼 클릭 → xcToken 에 붙여넣기 → Authorize 버튼 클릭을 하여 사용한다.

curl 을 이용할 경우, xc-token 해더값에 발급한 토큰을 넣어 사용한다.

curl -X 'GET' \
  'http://localhost:18080/api/v1/db/data/v1/elsie-project/MemberTable?limit=25&shuffle=0&offset=0' \
  -H 'accept: application/json' \
  -H 'xc-token: KDOxfcagx7dgp0XcP07Cc0gBrAvI35eJ84ipppXS'

6. webhook 사용

nocoDB에서 발생된 insert, update, delete 이벤트 감지가 필요할 경우, webhook을 이용하면 된다.

아래 sample payload에 대한 테스트도 가능하니, 참고하여 이벤트 트리거를 개발하면 된다.

7. 그외..

그외 더 많은 기능들을 제공하고 있으니, 더 필요한 기능들에 대해서는 아래 nocoDB 문서를 참고한다.
https://docs.nocodb.com/

warm up 은 어떻게 수행을 하는게 가장 좋을까?

Mon, 10 Jul 2023 00:00:00 GMT

SpringBoot/Java + K8S 환경 기반에서 어떤 방식으로 웜업을 수행해야 좋을지 고민을 한 내용을 정리한다.

1. 스프링부트 애플리케이션 시작 시점에 웜업 수행

✔️ 방법

CommandLineRunner 또는 ApplicationRunner 인터페이스를 구현한 클래스에 @Component 를 선언하면, 컴포넌트 스캔 후에 override 된 run 메소드 로직이 수행된다.
여기서 웜업 로직을 넣어 애플리케이션 시작시에 웜업 코드가 돌도록 한다.

@Component
public class BeforeStartRunner implements CommandLineRunner {
	@Override
	public void run(String... args) throws Exception {
		// 웜업 로직
	}
}

또는

@Component
public class BeforeStartRunner implements ApplicationRunner {
	@Override
	public void run(ApplicationArguments args) throws Exception {
		// 웜업 로직
	}
}

✔️ 장점

애플리케이션 시작 시 무조껀 수행이 보장된다.

✔️ 단점

로컬, 개발 페이즈 등, 웜업이 불필요한 페이즈에 대해 예외처리를 해줘야 한다.
웜업이 끝나기 전까지 트래픽을 받을 수 없도록 조치가 필요하다. (ex. 로컬 메모리에 웜업 종료에 대한 플래그 저장 등)
liveness probe에서 지정한 timeoutSeconds값 보다 웜업 수행 시간이 길어질 경우, liveness probe 실패로 파드 무한 재시작이 될 수 있다.
그렇다고 timeoutSeconds 값을 크게주면, liveness probe 주기가 길어지게 되므로 적절하지 않다.

2. K8S Startup Probe 사용하여 웜업 수행

Pod Probe 중 startupProbe 는 아래 그림과 같이 성공이 될때까지 다른 probe를 활성화하지 않기 때문에, 웜업을 수행하기 적절하다.
만약 startupProbe 가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다.
실제, k8s 매뉴얼에도 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는 파드에 유용하다고 가이드가 되어있다.

✔️ 장점

필요한 페이즈의 매니페스트에 startupProbe를 등록하면 된다.
웜업이 끝나기 전까지 다른 probe가 활성화 되지 않으므로 트래픽을 받지 않는다.
웜업 수행시간이 길어지게 되면, startupProbe의 timeoutSeconds 값만 수정하면 된다.

✔️ 단점

startupProbe 를 위한 api 가 필요하다.

3. 결론

웜업 수행 시간이 짧다면 1번째 방법이 나쁘지 않다.
하지만 트래픽이 많은 컴포넌트의 경우, 배포 실패 및 파드 무한 재시작이 일어날 수 있다.
따라서 좀 더 안정적인 배포가 가능한 2번째 방법으로 선택하자.

참고)
https://nearhome.tistory.com/89
https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/

docker 로그 사이즈 16k limit 에 따른 조치

Sun, 29 Jan 2023 00:00:00 GMT

이번에 내가 담당하고 있던 한 서비스를 PM장비에서 K8S로 이전하는 작업을 진행하게 됐는데,
해당 서버가 출력하고 있던 로그 사이즈가 16k 가 넘어버려서 로그가 제대로 ES에 적재되지 못하는 이슈가 발생했다.
이에 fluentd concat plugin 을 적용한 내용을 기록한다.

Docker는 16k 버퍼에서 로그메시지를 받고 있기 때문에 기본적으로 16kb를 초과하는 로그 메시지를 분할한다.
때문에 로그가 16kb가 초과했을 경우 아래와 같이 다음줄에 이어서 로그가 출력된다.

k8s 환경의 container 로그

2023-05-29T17:31:12.139673797+09:00 stdout F {"log_index_type":"stat","request": {...,"service_id":"service-A"
2023-05-29T17:31:12.139673797+09:00 stdout F "service_name:":"서비스에이"},"response":{..}}, request_uuid: "TEST-01"}

우리 부서에서는 로그 수집기로 Fluentd 를 사용하고 있었고, 관련 plugin 을 찾아보니 fluent-plugin-concat 이 있다는걸 알게되었다.

참고: https://github.com/fluent-plugins-nursery/fluent-plugin-concat

1. fluent-plugin-concat 을 추가한 docker file 작성

https://github.com/fluent/fluentd-kubernetes-daemonset 에서는 여러 fluentd-daemonset 을 제공해준다. 여기서 베이스 이미지를 선택하였다.

## v1.16.1-debian-kafka2-1.2_plugin_concat.Dockerfile
FROM fluentd-kubernetes-daemonset:v1.16.1-debian-kafka2-1.2

# Install concat plugin
RUN gem install fluent-plugin-concat

# Environment variables
ENV FLUENTD_OPT=""
ENV FLUENTD_CONF="fluent.conf"

# Overwrite ENTRYPOINT to run fluentd as root for /var/log / /var/lib
ENTRYPOINT ["tini", "--", "/fluentd/entrypoint.sh"]

2. 어플리케이션 로깅 수정

concat plugin 의 usage 내용을 보면 여러 방법이 있지만, 현재 내 상황에 맞는 방법은 start, end regexp 를 사용하는 방법이라 판단하였고, 모든 로그의 시작을 log_type 으로, 끝을 log_end로 통일하였다.

k8s 환경의 container 로그

2023-05-29T17:31:12.139673797+09:00 stdout F {"log_type":"stat","request": {...,"service_id":"service-A"
2023-05-29T17:31:12.139673797+09:00 stdout F ...,"log_end":""}
2023-05-29T17:31:12.139673797+09:00 stdout F {"log_type":"stat",...,"log_end":""}

3. config 설정

input&parse 설정
- 로컬에서 테스트를 위한 설정 파일이므로, input을 forward 로 설정한다.
- 실제 concat이 필요한 부분은 맨 끝 어플리케이션 로그쪽이라 구분을 위해 파싱을 한다.
concat 설정
- 로그의 시작과 끝의 패턴을 설정해준다.
- 참고로, separator 은 로그를 concat 할때의 구분자이며, 기본값은 \n 이다. 따로 설정을 해주지 않으면 concat 된 두 로그 사이에 \n 값이 들어가게 된다.
output 설정
- 로컬에서 테스트를 위한 설정이므로 stdout으로 출력한다.

## fluentd.conf

# 데이터가 위 예시와 같은 포맷으로 들어올때의 input과 parse 설정
<source>
  @type                           http
  port                            9880
  bind                            0.0.0.0
  <parse>
    @type                         regexp
    expression                    /^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<flags>[^ ]+) (?<log>.*)$/
  </parse>
</source>

#multiline start&end regexp
<filter **>
  @type                           concat
  key                             log
  separator                       ""
  multiline_start_regexp          /^{\"log_type/
  multiline_end_regexp            /log_end\":\"\"}$/
</filter>

<match **>
  @type stdout
</match>

4. 도커파일 빌드 후 실행

위에서 작성한 도커파일 빌드 후 실행한다.

$ docker build -t fluentd-kubernetes-daemonset:v1.16.1-debian-kafka2-1.2-with_concat_plugin -f v1.16.1-debian-kafka2-1.2_plugin_concat.Dockerfile .

$ docker run --name fluentd \
	-p 9880:9880 \
	-v $(pwd)/fluentd.conf:/fluentd/etc/fluentd.conf \
	-e FLUENTD_CONF=fluentd.conf \
	fluentd-kubernetes-daemonset:v1.16.1-debian-kafka2-1.2-with_concat_plugin

5. 테스트

fluentd 로 보낼 테스트파일 2개를 생성한다.

# test1.text
2023-05-29T17:31:12.139673797+09:00 stdout F {"log_type":"stat","phase":"beta"

# test2.text
2023-05-29T17:31:12.139673797+09:00 stdout F "level":"INFO","log_end":""}

먼저 test1.text 파일을 보내면 fluentd 로그에 stdout 이 나오지 않지만,

curl -X POST "http://127.0.0.1:9880/sample.test" -d @test1.text

다음에 test2.text 파일을 보내면, test1.text의 로그와 함께 concat이 되어 fluentd 로그에 출력되는걸 확인할 수 있다.

curl -X POST "http://127.0.0.1:9880/sample.test" -d @test2.text

ES Node Role 정리

Sat, 07 Jan 2023 00:00:00 GMT

사내 스터디로 ES 책을 보고있는데, 문득 내가 사용하고 있는 ES 들의 role 구성이 궁금했고,
생각보다 node 들의 role 이 많아서 정리하려고 한다.

📢 환경

ElasticSearch 7.17.8

✔️ 노드 role 확인

노드 정보 확인 API 를 사용하면 노드의 role 을 확인할 수 있다.

여기서 node.role 필드 값에 대한 정의는 아래와 같다.

✔️ 노드 role 정의

m (master-eligible node)

마스터, 마스터 후보 노드

# elasticsearch.yaml

node.roles: ["master"]

v (voting-only node)

마스터 노드 선출을 위한 투표에는 참여하지만, 마스터 역할은 수행하지 않는 마스터 후보 노드
마스터 노드에만 해당 role을 줄 수 있다.
만약 장애로 마스터 노드가 3개에서 1개로 줄어 최소 마스터 노드의 수를 충족하지 못할 경우 클러스터 전체 장애로 이어지는데, 이를 방지하기 위해 낮은 스펙을 가진 voting_only 마스터 노드를 더 추가하여 마스터 후보 노드 수를 높이는 것도 괜찮을 듯 싶다.

# elasticsearch.yaml
node.roles: ["master", "voting_only"]

d (data node)

데이터 CRUD, 인덱싱, 검색 및 집계를 처리
multi-tier architecture 에서 사용할 수 있는 특수 데이터 역할이 있다.

# elasticsearch.yaml

node.roles: [ "data"]

s (data content node)

contents 를 저장하는 노드로, product catalog or article archive 와 같은 데이터를 CRUD, 검색 및 집계 처리

# elasticsearch.yaml

node.roles: [ "data_content"]

h (data hot node)

자주 업데이트되는 시계열 데이터를 저장하는데 사용
검색 및 인덱싱이 모두 빨라야하므로 많은 CPU, RAM 및 빠른 storage를 사용

# elasticsearch.yaml

node.roles: [ "data_hot"]

w (data warm node)

쿼리 빈도가 낮고 거의 업데이트되지 않는 시계열 데이터를 저장하는데 사용

# elasticsearch.yaml

node.roles: [ "data_warm"]

c (data cold node)

더 이상 정기적으로 검색할 필요가 없는 시계열 데이터는 warm에서 cold로 이동
검색 성능이 우선이 아니기 때문에 일반적으로 CPU, RAM 대비 큰 storage를 사용

# elasticsearch.yaml

node.roles: [ "data_cold"]

f (data frozen node)

거의 쿼리되지 않고 더이상 업데이트되지 않는 데이터는 cold에서 frozen으로 이동
해당 노드는 적은 비용으로 frozen 된 데이터를 운영하기 위함이다.

# elasticsearch.yaml

node.roles: [ "data_frozen"]

i (ingest node)

인덱싱에 전처리가 필요한 경우 사용
스택 모니터링 및 수집 파이프라인에는 ingest역할이 필요

# elasticsearch.yaml

node.roles: [ "ingest"]

(coordinating node only)

사용자 요청을 데이터 노드로 전달하고, 그 결과를 취합하는데 사용
기본적으로 모든 노드에 coordinating role을 가지고 있지만, 운영시에는 모든 사용자 요청은 coordinating only 노드로만 가도록 하여 다른 role을 가진 노드(master, data 등..)의 부하를 줄이도록 한다.

# elasticsearch.yaml

node.roles: []

l (machine learning node)

ES에서 제공하는 머신러닝 기능이 필요한 경우 사용

# elasticsearch.yaml

node.roles: ["ml"]

r (remote cluster client node)

다른 클러스터와의 검색이나 복제 등을 수행

# elasticsearch.yaml

node.roles: ["remote_cluster_client"]

t (transform node)

기존 인덱스를 변환하거나 insight 및 요약된 데이터 분석 등의 api 요청을 수행

# elasticsearch.yaml

node.roles: ["transform"]

모든 롤을 가진 node 설정 방법

# elasticsearch.yaml

# 아무런 설정을 하지 않는다. (default)
# node.roles: []

참고)
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
https://opster.com/guides/elasticsearch/data-architecture/how-to-configure-all-elasticsearch-node-roles/#Master-node
https://jeongxoo.tistory.com/12

무료 사용 가능한 오픈렌즈(OpenLens) 설치 방법

Thu, 22 Dec 2022 00:00:00 GMT

너무너무 잘 사용하던 Lens가 2023년 1월 2일 이후로는 기업에서 유료화가 된다고 한다.

https://medium.com/k8slens/lens-6-released-vision-for-the-future-new-subscription-model-and-features-available-628ff21fe14a

하지만 개인용, 교육용, 스타트업(연매출 또는 자금 1,000만 달러 미만) 은 무료라고 하니..
개인 노트북에서는 계속 사용해도 될 듯 싶다.

다만 기존 오픈소스는 ‘오픈렌즈(OpenLens)‘로 이름을 바꿔 유지되고, ‘MIT 라이선스’ 이니, 무료로 사용이 가능하다.
오픈렌즈를 설치하는 방법은 아래와 같다.

✔️ MacOS - Homebrew

brew install --cask openlens

✔️ Windows - Scoop

scoop bucket add extra
scoop install openlens

또는 아래 오픈렌즈 깃헙에서 빌드된 파일을 받아 설치해도 된다.
https://github.com/MuhammedKalkan/OpenLens

참고로, 오픈렌즈에서는 pod 메뉴가 없다.(pod 로그 보기 등.. 불가능)
이를 사용하려면 extension을 설치해야한다.

✔️ 설치 방법

메뉴 > extensions > 설치란에 @alebcay/openlens-node-pod-menu 입력 후 install 버튼 클릭

Unable to acquire JDBC Connection 에러 오답노트2

Fri, 09 Dec 2022 00:00:00 GMT

이전글)

Unable to acquire JDBC Connection 에러 오답노트1

현재글)

Unable to acquire JDBC Connection(DHCP lease lost) 에러 오답노트2

✔️ 문제 재확인

어플리케이션의 문제는 아닌듯 보여 VM 장비로 포커스를 맞춰 문제를 다시 파악했다.
여러 VM의 어플리케이션 로그들을 키바나에서 보고 있어서 몰랐는데, 자세히 보니 특정 패턴이 보였다.
각 장비마다 매일 특정 시간대에 connection 에러를 발생시키고 있었다..!!!
즉, 1번 워커노드의 서버는 매일 대약 2시쯤, 2번 워커노드의 서버는 매일 대략 3시 반쯤 등 timeout 오류를 발생시키고 있었다.

열심히 인사이트를 찾아보다가 syslog를 확인하게 되었는데,

# syslog 위치 (나는 무슨 문제였는지 몰랐기 때문에 syslog 내용을 확인 하였다.)
$ ll /var/log/syslog*

아래와 같이 systemd-networkd 에서 eth0: DHCP lease lost 가 발생이 되고 있다는 걸 알게 되었다.

참고) systemd-networkd 로그만 확인하는 방법

$ journalctl -u systemd-networkd

즉!! VM에서 커넥션 종료를 시켰고, 어플리케이션 서버에서는 이를 전혀 감지하지 못하고 dead connection 을 가지고 요청을 수행하려다가 결국 타임아웃 에러가 발생 한 것이다.

Hikari Pool 에서 타임아웃 에러가 발생한 이유는 아래와 같다.

DB 수행이 필요한 요청이 들어온다.
Connection Pool에서 커넥션을 가져온다.
Hikari CP에서 가져온 커넥션에 대한 validation을 진행한다. 이때, validation timeout은 default로 5초이다.
DHCP lease lost 때문에 dead connection으로 validation에 실패하게 되고(5초 소요)
해당 커넥션을 종료시키고 다시 2번부터 수행한다. (커넥션을 종료하면 Pool의 개수를 맞추기 위해 hikari 의 housekeeper 스레드에서 새로운 커넥션을 생성하여 pool에 넣는다.)
2-5번을 반복하며 vaildation을 하는데 시간을 계속 소비하여 available 한 커넥션을 찾지 못하고, 결국 db connetion timout 에러가 발생하게 된다. (기본 db connection timeout 시간은 30초이다. : spring.datasource.hikari.connectionTimeout )

DHCP 현상에 대한 인프라팀 답변으로는, 생성된 VM 들은 DHCP 기반으로 IP를 할당받도록 되어 있었고, DHCP 갱신을 24시간 주기로 수행하며 갱신하는 시점에 순간 네트워크 설정이 reset 되면서 기존 연결이 무효화가 되어 DB처럼 커넥션을 연결해놓고 사용하는 경우에는 해당 문제가 발생했다고 한다.

✔️ 문제를 확인 했으니, 조치를 해보자

ubuntu 18.04 기준으로 /etc/netplan/50-cloud-init.yaml 파일에 critical: true 필드를 추가 후 apply 하면 된다.

1. 설정파일 수정

# /etc/netplan/50-cloud-init.yaml
network:
    ethernets:
        eth0:
            dhcp4: true
            critical: true #추가
            match:
                macaddress: fa:...
            set-name: eth0
    version: 2

2. 설정파일 적용

$ sudo netplan apply

당일에는 DHCP 갱신이 이미 발생이 된 후라 다음날 확인을 해보니, 더이상 connection 오류가 발생하지 않았다.

어휴! 이슈 해결하느라 고생한 나 자신 칭찬한다.

참고)

dhcp란?
https://jwprogramming.tistory.com/3
dhcp ip 대여시간
https://points.tistory.com/15
dhcp message type
http://www.ktword.co.kr/test/view/view.php?m_temp1=5419&id=1244
라우터 vs 공유기
https://m.blog.naver.com/PostView.naver?blogId=msnayana&logNo=80105365859&proxyReferer=
configuring dhcp lease
https://serverfault.com/questions/1022612/configuring-dhcp-lease-when-using-systemd-networkd-on-ubuntu-18-04-server

Unable to acquire JDBC Connection 에러 오답노트1

Fri, 09 Dec 2022 00:00:00 GMT

현재글)

Unable to acquire JDBC Connection 에러 오답노트1

다음글)

Unable to acquire JDBC Connection(DHCP lease lost) 에러 오답노트2

내가 담당하고 있는 서비스에서 간헐적으로 DB Connection이 끊기는 현상이 발생했다.
처음에는 단순히 DB Connection Pool 의 개수가 모자른가? 라고 생각했었지만, 생각치도 못했던 여러 문제를 접하였고, 그에 대한 오답노트를 적어보려고 한다.

📢 환경
- Ubuntu 18.04.5 LTS
- SpringBoot 2.5.12
- MySQL 5.7.28

✔️ 1. 문제 확인

DB에서 데이터를 꺼내기 위해 커넥션을 사용하려고 하는데, 설정된 timeout 시간까지 커넥션 풀에서 사용 가능한 커넥션을 못찾아 에러가 발생하였다. stack trace 를 보면 아래와 같다.

DataAccessResourceFailureException

Unable to acquire JDBC Connection; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection


JDBCConnectionException

Unable to acquire JDBC Connection


SQLTransientConnectionException

HikariPool-1 - Connection is not available, request timed out after 15016ms.


SQLNonTransientConnectionException

No operations allowed after connection closed.

...

처음 저 에러를 접했을때, 오잉? Connection Pool Size 가 작은가?? 해당 서버에 요청이 많아졌나..?? 라고 생각했고, 단순하게 Pool Size만 늘리는 조치를 취했지만… 해당 에러는 계속 발생했다.

그래서 열심히 구글에 검색을 해보니, 아래와 같은 키워드를 발견하였다.

✔️ MySQL - wait_time

jdbc, odbc, php 등을 통한 커넥션 중 요청이 없는 커넥션(non-interactive 세션) 의 최대 수명시간
기본값은 28800s (8시간) 이다.

✔️ Hikari - max-lifetime

커넥션 풀에서 사용하지 않은 커넥션의 최대 수명시간
사용 후 반환 됐을때부터 wait 시간을 측정하게 된다.
풀 전체가 아닌 커넥션 별로 적용이 되는 이유는 풀에서 한번에 많은 커넥션들이 제거되는 것을 방지하기 위함이라고 한다.
0으로 설정하면 infinite lifetime이 적용된다.
기본값은 1800000ms (30분) 이다.

만약, wait_time < max-lifetime 일 경우 커넥션 풀에 존재하는 모든 커넥션이 유효한 커넥션이 아닐 수도 있게된다.
왜냐면, wait_time 시간이 지난 커넥션들은 DB서버에서 먼저 연결을 끊기 때문이다.
때문에 풀은 이걸 모르고 계속 가지고 있다가 어플리케이션에서 요청하면 유효하지 않은 커넥션을 계속 주게 될 수도 있다는거다.

✔️ 2. 문제를 확인 했으니, 조치를 해보자

1. 각 설정값 확인

MySQL의 wait_timeout 을 확인해보니 기본값인 8시간이다.

show global variables like 'wait_timeout';

오잉??
application.yaml 파일에도 max-lifetime을 설정하지 않았는데.. 그럼 기본값이니 30분일 텐데.. 충분히 작은데..?
그럼 max-lifetime을 10분으로 설정해서 max-lifetime에 새로 연결을 맺는지 한번 확인해보자.

2. 설정 내용 실제 동작 확인

참고) Hikari Pool 로그를 보기 위해 logback-spring.xml 를 아래와 같이 설정해야 한다. (logback 기준)

커넥션 max-lifetime 로그 확인

23:55분에 connection adder 스레드로 커넥션이 풀에 추가가 되었고, 00:05분에(10분 후) 해당 커넥션을 사용하지 않아 connection closer 스레드로 Closing 되었다.
그리고 바로 새로운 커넥션이 추가된 것을 볼 수 있다.
즉, 이건 아주 잘 작동이 되고 있다…

아니 그럼 대체 뭐가 문제인 것인가?? 뷁!

다음 페이지로 > Unable to acquire JDBC Connection(DHCP lease lost) 에러 오답노트2

리눅스 접속 로그 확인 명령어

Thu, 24 Nov 2022 00:00:00 GMT

이번에 업무 관련 검증을 받게 되면서 서버의 접속 로그를 신경쓸일이 생겼다.
접속로그는 /var/log/wtmp 에 기록이 된다고 하는데, tail, vi 등으로는 볼 수가 없었고, 찾아보니 last 명령어를 사용해야한다고 한다.

✔️ 리눅스 접속 로그 확인

last 명령어를 사용한다.
해당 명령어를 이용하여 /var/log/wtmp 에 기록된 내용을 보여준다.

$ last

✔️ 특정 계정 접속 확인

$ last root

✔️ 특정 시간 이전 접속 확인

# 시간 포맷: YYYYMMDDHHMMSS
$ last -t 202211242359

✔️ 연도 정보 같이 확인

$ last -F

✔️ 이번달 기록만 나올 경우

/var/log/wtmp 파일이 logrotate에 의해 순환될 경우 이번달만 나올 수 있다.
과거 기록을 보려면 rotate 된 파일을 지정해주면 된다.

$ last -f /var/log/wtmp.1

참고)
리눅스 접속기록 확인 last

Cordon, Drain 명령어를 이용하여 Node 작업하기

Sat, 29 Oct 2022 00:00:00 GMT

이번에 전사적으로 사용하고 있는 리소스 최적화 요청이 내려왔다.
때문에 내가 운영하고 있던 서비스들의 VM 스펙 변경 및 클러스터 노드를 줄이는 작업을 진행하게 되었다.

클러스터 노드를 줄이는 작업을 진행할때, 삭제 대상이 된 노드에 서비스하고 있는 파드들을 어떻게 옮길지에 대한 고민을 하게 되었다.

처음엔 nodeSelector 를 이용하여 삭제 대상 노드에서 파드들을 빼려고 했는데,

이를 쉽게 해주는 cordon, drain 기능이 있다는걸 알게 되었다..!

✔️ Cordon

지정된 노드에 더이상 Pod들이 스케줄링되지 않도록 한다.

$ kubectl cordon [노드명]

노드에 cordon 을 걸면 노드의 상태가 ScheduleingDisabled 가 된 것을 확인할 수 있다.
그럼 더이상 해당 노드에는 새로운 파드들이 들어오지 않게 된다.
다시 정상적으로 노드에 스케줄링을 하기 위해서는 uncordon을 수행하면 된다.

$ kubectl uncordon [노드명]

✔️ Drain

지정된 노드에 있는 Pod들을 다른 노드들로 재생성 후, 지정된 노드에서 Pod 삭제

$ kubectl drain [노드명] 

$ kubectl drain [노드명] --ignore-daemonsets

cordon 작업을 통해 삭제 대상 노드에 더이상 새로운 파드가 못들어오도록 막았다면, 이젠 삭제 대상의 노드들에 있는 Pod들을 삭제대상이 아닌 노드로 옮기는 작업을 할 차례이다.

식제 대상 노드의 pod들을 확인해보니, daemonset 등도 포함되어 있는 것을 확인할 수 있다.

daemonset 의 특성상 pod가 죽게되면 즉시 다시 생성되기 때문에 노드에 daemonset 이 있는 경우 drain 명령어를 실행하면 error: cannot delete DaemonSet-managed Pods 오류가 발생한다.

보통은 로깅, proxy, 네트웍 관련 데몬셋은 떠있기 때문에 꼭 --ignore-daemonsets 옵션을 주고 실행을 한다. 그럼 데몬셋 파드는 무시하고 나머지 파드들만 옮긴다.

삭제 노드에는 데몬셋 파드만 남은 것을 확인할 수 있다.

이후 삭제 대상 노드 처리를 해주면 끝!!

docker 호스트로 연결

Sat, 29 Oct 2022 00:00:00 GMT

docker 로 띄운 컨테이너에서 내 현재 로컬의 DB를 붙여 테스트를 하게 되었다.
때문에 컨테이너에서 호스트의 주소로 연결하는 방법이 필요했다.

docker 18.03 부터 호스트의 IP를 직접 입력하는 방법 외에 호스트 주소로 바로 연결이 가능하다.

✔️ Mac or Windows

'host.docker.internal'
또는
172.17.0.1

✔️ Linux

$ docker run --network="host"

localhost
또는
127.0.0.1

503 Service Unavailable 오류!! 범인은 누구냐! (WAS? Nginx? GSLB?)

Sun, 23 Oct 2022 00:00:00 GMT

503 Service Unavailable 오류가 발생하기 전, 해당 서비스의 인프라 구성은 아래와 같았다.

얼마전 IDC1 에 문제가 발생하였고, 결국 IDC1은 down이 되었다.

하지만, GSLB에 의해 요청은 모두 IDC2로 연결이 되었고, 해당 deployment 는 Autoscale도 걸려있었기 때문에 큰 문제없이 서비스가 정상으로 작동이 되는듯 하였다.

하지만, 어느순간부터 해당 서비스에서 503 오류가 발생한다는 제보가 들어왔다.

503 오류는 “서비스를 일시적으로 사용할 수 없음(503 Service Temporarily Unavailable Error)” 을 의미하고, 나는 로그도 제대로 확인도 안하고.. nginx에서 발생하는 오류라고 바로 판단을 해버렸다. (삽질의 시작…)

✔️ 첫번째 삽질!!

👀 첫번째 의심)

“(클라 요청수) > (pod 들이 수행할 수 있는 요청 수) 상태라서 nginx에서 was로 못보내고 있나?”
autoscaling이 발생되었지만, 순간 요청수가 많아 pod가 추가 생성되기 전에 요청을 모두 견뎌내지 못하여 503 오류가 발생한 것인가?

💩 첫번째 조치)

최소 pod수를 2배로 증가

하지만.. 503 에러는 계속 발생하였다….😢

✔️ 두번째 삽질!!

👀 두번째 의심)

두개의 ingress가 총 요청수를 못견디고 있는건가?
현재 ingress node는 2개인 상태였고, 해당 클러스터에 딱 그 시점에! 다른 서비스가 잠시 머물고 있었는데, nginx가 일시적으로 과부하가 되거나 리소스 제약에 직면하면 해당 오류가 발생할 수 있다는 글을 보게 되었고 nginx를 의심을 하게 됬었다.

💩 두번째 조치)

ingress pod 한개 추가

역시.. 503 에러는 계속 발생하였다….😢

✔️ 세번째 드디어!!!

“LB에서 요청을 잘못 전달하고 있는게 아닐까?”

👀 세번째 의심)

앞단 LB에서 로드밸런싱이 잘못되고 있는건 아닐까?
위 조치까지 하고 nginx 로그를 살펴보게 되었는데, 503 오류에 대한 로그가 딱히 보이지 않아서 물음표를 그리고 있다가 문득! 로드밸런싱이 잘못되고 있을수도 있겠다는 생각이 들었다.

🤡 세번째 조치)

GSLB로 묶은 VIP 중에 IDC1의 VIP를 제외하도록 요청을 하였다.

그랬더니!! 드디어 503 오류가 사라졌다!! 만쉐이! 🙌

아 진짜.. 경험에 의해 바로 판단하지 말고 로그를 꼭 확인하는 습관을 길러야겠다…ㅠㅜ
하지만 왜 지금 off 인 IDC1 쪽으로 로드밸런싱이 되고 있던건지, GSLB에 버그가 있던거지 정확한 원인은 파악을 하지 못한체, 일단 서비스가 정상화 된 것으로 만족하고 마무리를 지었다.

하루가 지난 후, 인프라팀에서 공지가 내려왔다.
아래 상황에서 장애가 난 IDC1에 구축된 클러스터로 트래픽이 인입되면서 서비스 장애로 이어지는 상황이 발생!!

worker node 가 하나라도 살아난 경우(pod 실행 여부와 상관 없이 핑만 나가는 경우)
ingress가 하나라도 살아난 경우
GSLB로 묶여있고, 해당 VIP를 제외(요청등을 통해)하지 않은 경우

즉, 풀어서 얘기하면 아래와 같다.

IDC1에 전력이 조금씩 on이 되면서 클러스터를 구성하는 일부 노드들이 정상화 되었고,
서비스 상태는 정상이 아니지만(pod가 없고 ingress만 있는 경우 등..) GSLB에서 health check를 성공으로 판단하였고,
때문에 트래픽이 인입되면서 서비스 장애가 발생하니, IDC1의 VIP를 제거 요청해라!!

그래 GSLB는 잘못이 없구나.. (policy 가 어떻게 설정이 되었는지는 난 알지 못하니깐) IDC에 문제가 생기면 일단 GSLB에 묶여있는 VIP를 제거하는게 안전하구나.. 라는 배움을 하나 얻게되었다.

파일 업로드 크기 제한 늘리기 (Ingress Nginx & SpringBoot)

Sun, 23 Oct 2022 00:00:00 GMT

1. Nginx 설정

nginx 의 기본 body sizesms 1MB이다.
이 때, 업로드 파일을 포함한 요청 사이즈가 1MB가 넘으면 413(Request Entity Too Large) 에러를 반환한다.

1.1. ConfigMap 으로 설정하기

apiVersion: v1
kind: ConfigMap
proxy-body-size: "10m"
data:
metadata:
labels:
  app: ingress-nginx
name: nginx-configuration

1.2. Ingress Annotation 으로 설정하기

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"

2. SpringBoot 설정

SpringBoot 에 설정된 기본값은 1048576 bytes 이다.
이 때, 업로드 파일 사이즈가 위 사이즈를 넘으면 “multipart.MaxUploadSizeExceededException” 에러가 발생한다.

2.1. SpringBoot 2.x 버전

# application.yaml
spring:
	servlet:
		multipart: 
			maxFileSize: 10MB
			maxRequestSize: 10MB

2.2. SpringBoot 1.4 & 1.5 버전

spring:
	http:
		multipart:
			maxFileSize: 10MB
			maxRequestSize: 10MB

2.3. SpringBoot 1.3.x 이하 버전

multipart:
	maxFileSize: 10MB
	maxRequestSize: 10MB

로컬에 있는 도커 이미지 수동으로 서버에 로딩 시키기

Wed, 19 Oct 2022 00:00:00 GMT

이번에 전사적으로 모든 CI/CD 툴이 작동하지 않는 상태에서 새로 빌드/배포를 해야하는 상황이 있었다.
이에 로컬에서 빌드한 docker 이미지를 k8s에 배포까지 수동으로 작업한 내용을 기록한다.

✔️ docker image 빌드

docker build -t {image명}:{tag} .

✔️ 컨테이너 이미지 tar 파일로 저장

$ docker save {image명}:{tag} -o dockerImage.tar

✔️ tar 파일 서버로 전송

$ scp ./dockerImage.tar {계정}@{host}:{경로}

✔️ 해당 서버에서 컨테이너 이미지 로딩

이미지를 로딩하면 k8s에서 해당 이미지로 배포가 가능하다.

$ sudo docker load -i dockerImage.tar

✔️ k8s 배포시

deployment.yaml 파일 내에 imagePullPolicy 필드값을 Never 로 설정하여 위에 로드한 이미지를 사용하도록 한다.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          imagePullPolicy: Never
...

Fluentd 설정파일 분석

Sat, 17 Sep 2022 00:00:00 GMT

✔️ 먼저 알아두면 좋은 내용

1. common plugin parameters

builtin plugin parameter 의 경우 prefix로 @ 가 붙는다

1.1. @type

specifies the plugin type

1.2. @id

specifies the plugin id.
in_monitor_agent uses this value forplugin_id field
버퍼, 스토리지, 로깅 및 기타 목적을 위한 경로로 사용됨

1.3. @label

specifies the label symbol. Seelabelsection.

1.4. @log_level

specifies per plugin log level. See Per Plugin Log section.

자세한 내용은 아래 참고

Config: Common Parameters

2. wildcards, expansions and other tips

match , filter 태그에서 사용한다.

2.1. *

single tag 와 매치
a.* 의 경우 a.b 와 매치, a 또는 a.b.c 와는 매치 안됨

2.2. ``**

zero or more tag 와 매치
a.** 의 경우 a, a.b, a.b.c 와 모두 매치

2.3. 그외

그외 regex, 값 매치 등은 아래에서 확인

Config File Syntax

3. Embedding Ruby Expressions

fluentd 1.4.0 부터 #{...} 표현식에 루비 코드를 넣을 수 있다.

<match "app.#{ENV['FLUENTD_TAG']}">
  @type stdout
</match>

✔️ Directive

1. source

input 에 대한 지시어
사용할 input plugin에 대한 값이 @type 으로 명시가 되야한다.

# Receive events from 24224/tcp
# This is used by log forwarding and the fluent-cat command
<source>
  @type forward
  port 24224
</source>

# http://<ip>:9880/myapp.access?json={"event":"data"}
<source>
  @type http
  port 9880
</source>

2. match

output plugin 으로 동작하며, 명시된 태그에 대해서만 output destination으로 보내진다.

# Receive events from 24224/tcp
# This is used by log forwarding and the fluent-cat command
<source>
  @type forward
  port 24224
</source>

# http://<ip>:9880/myapp.access?json={"event":"data"}
<source>
  @type http
  port 9880
</source>

# Match events tagged with "myapp.access" and
# store them to /var/log/fluent/access.%Y-%m-%d
# Of course, you can control how you partition your data
# with the time_slice_format option.
<match myapp.access>
  @type file
  path /var/log/fluent/access
</match>

3. filter

match 와 동일한 syntax를 가지고 있고, 로그 필터에 대한 지시어이다.
event flow 는 아래와 같다.

# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
  @type http
  port 9880
</source>

<filter myapp.access>
  @type record_transformer
  <record>
    host_param "#{Socket.gethostname}"
  </record>
</filter>

<match myapp.access>
  @type file
  path /var/log/fluent/access
</match>

✔️ 위 예제 동작 플로우

input 으로 tag: myapp.access, data: {”event”: “data”} 이벤트를 받고,
첫번째 filter인 recordtransformer 는 `“hostparam”` 필드를 이벤트에 추가한다.
그럼 {"event":"data","host_param":"webserver1"} 값이 ouput plugin 으로 보내져 파일로 출력하게 된다.

✔️ 서비스에 설정한 fluentd daemonset config 설정 분석

전체 설정 내용

data:
  fluent.conf: |
    <system>
      workers 1
      @log_level info
    </system>
    @include input-kubernetes.conf
    @include filter-kubernetes.conf
    <match **>
      @type copy
      <store>
        @type                         kafka2
        @id                           out_kafka
        brokers                       logis-kafka.dev.kakaoi.io:9092
        max_send_retries              10
        required_acks                 1

        default_topic                 xoauth-dev
    
        exception_backup              false
        compression_codec             gzip
    
        <format>
          @type                       json
        </format>

        <buffer topic,tag>
          @type                       file
          path                        /var/log/td-agent/buffer/td
          flush_interval              5s
          chunk_limit_size            16M
          queue_limit_length          32
          retry_forever               true
        </buffer>
      </store>
    </match>

  input-kubernetes.conf: |
    # Prevent fluentd from handling records containing its own logs. Otherwise
    # it can lead to an infinite loop, when error in sending one message generates
    # another message which also fails to be sent and so on.
    <match fluent.**>
      @type                           null
    </match>
    <source>
      @type                           tail
      @id                             in_tail_container_logs
      path                            /var/log/containers/xoauth*.log
      pos_file                        /var/log/fluentd-containers.log.pos
      tag                             kubernetes.*
      read_from_head                  "#{ENV['FLUENTD_INPUT_READ_FROM_HEAD'] || 'false'}"
      limit_recently_modified         "#{ENV['LIMIT_RECENTLY_MODIFIED'] || '120m'}"
      rotate_wait                     0
      enable_stat_watcher             false
      <parse>
        @type                         regexp
        expression                    /^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<flags>[^ ]+) (?<message>.*)$/
      </parse>
    </source>

  filter-kubernetes.conf: |
    <filter kubernetes.**>
      @type                           kubernetes_metadata
      @id                             filter_kube_metadata
    </filter>
    <filter kubernetes.**>
      @type                           record_modifier
      tag                             ${record.dig("kubernetes", "container_name").gsub('-', '.')}
      <record>
        @timestamp                    ${(Time.at(time) + (60*60*9)).strftime('%Y-%m-%dT%H:%M:%S.%L+09:00')}
        cluster_name                  "xoauth-dev"
        hostname                      "#{ENV['K8S_NODE_NAME']}"
        container_image               ${record.dig("kubernetes", "container_image")}
        pod_name                      ${record.dig("kubernetes", "pod_name")}
      </record>
    </filter>
    <filter kubernetes.**>
      @type                           parser
      key_name                        message
      reserve_data                    true
      remove_key_name_field           true
      <parse>
        @type                         json
      </parse>
    </filter>
    <filter kubernetes.**>
      @type                           record_transformer
      remove_keys                     $.kubernetes
    </filter>

1. Input에 대한 설정

input-kubernetes.conf: |
    <match fluent.**>
      @type                           null
    </match>
    <source>
      @type                           tail
      @id                             in_tail_container_logs
      path                            /var/log/containers/xoauth*.log
      pos_file                        /var/log/fluentd-containers.log.pos
      tag                             kubernetes.*
      read_from_head                  "#{ENV['FLUENTD_INPUT_READ_FROM_HEAD'] || 'false'}"
      limit_recently_modified         "#{ENV['LIMIT_RECENTLY_MODIFIED'] || '120m'}"
      rotate_wait                     0
      enable_stat_watcher             false
      <parse>
        @type                         regexp
        expression                    /^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<flags>[^ ]+) (?<message>.*)$/
      </parse>
    </source>

1.1. 로그 input

/var/log/containers/xoauth*.log 파일을 타겟으로 tail 을 사용하여 input을 수행한다.
해당 이벤트에 kubernetes.* 태그를 붙인다.

<source>
  @type                           tail
  @id                             in_tail_container_logs
  path                            /var/log/containers/xoauth*.log
  pos_file                        /var/log/fluentd-containers.log.pos
  tag                             kubernetes.*
  read_from_head                  "#{ENV['FLUENTD_INPUT_READ_FROM_HEAD'] || 'false'}"
  limit_recently_modified         "#{ENV['LIMIT_RECENTLY_MODIFIED'] || '120m'}"
  rotate_wait                     0
  enable_stat_watcher             false
  <parse>
    @type                         regexp
    expression                    /^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<flags>[^ ]+) (?<message>.*)$/
  </parse>
</source>

실제 들어온 이벤트의 레코드 데이터는 아래와 같다 (/var/log/containers/xoauth*.log 파일 포맷)

2022-08-23T16:20:02.313036458+09:00 stdout F {"@timestamp":"2022-08-23T07:20:02.312+00:00","@version":"1","message":"Running with Spring Boot v2.2.0.RELEASE, Spring v5.2.0.RELEASE","logger_name":"com.kakao.xoauth.XoauthApplication","thread_name":"main","level":"DEBUG","level_value":10000}

<parse> 의 regexp 를 통해 아래와 같이 파싱이 된다.
- regexp 의 결과값을 확인할 수 있는 사이트 : http://fluentular.herokuapp.com

1.2. fluentd 로그 제거

fluentd.** tag로 들어온 이벤트는 모두 버린다.

<match fluent.**>
  @type                           null
</match>

2. Filter에 대한 설정

✔️ 전체 코드

filter-kubernetes.conf: |
    <filter kubernetes.**>
      @type                           kubernetes_metadata
      @id                             filter_kube_metadata
    </filter>
    <filter kubernetes.**>
      @type                           record_modifier
      tag                             ${record.dig("kubernetes", "container_name").gsub('-', '.')}
      <record>
        @timestamp                    ${(Time.at(time) + (60*60*9)).strftime('%Y-%m-%dT%H:%M:%S.%L+09:00')}
        cluster_name                  "xoauth-dev"
        hostname                      "#{ENV['K8S_NODE_NAME']}"
        container_image               ${record.dig("kubernetes", "container_image")}
        pod_name                      ${record.dig("kubernetes", "pod_name")}
      </record>
    </filter>
    <filter kubernetes.**>
      @type                           parser
      key_name                        message
      reserve_data                    true
      remove_key_name_field           true
      <parse>
        @type                         json
      </parse>
    </filter>
    <filter kubernetes.**>
      @type                           record_transformer
      remove_keys                     $.kubernetes
    </filter>

2.1. K8S Metadata 정보 포함시키기

kubernetes_metadata 타입의 필터로 인해 해당 로그 레코드를 내보낸 컨테이너에 대한 기본 메타데이터(hostname, podname, containername 등) 가 해당 레코드에 포함된다.
해당 필터는 fluend 에 내장된 플러그인은 아니고, fluent-plugin-kubernetes_metadata_filter 를 설치해야 사용할 수 있다. (https://github.com/fabric8io/fluent-plugin-kubernetes_metadata_filter)

<filter kubernetes.**>
  @type                           kubernetes_metadata
  @id                             filter_kube_metadata
</filter>

✔️ fluent-plugin-kubernetesmetadatafilter 설치는 언제?

daemonset으로 설치된 fluentd pod 에서 Gemfile을 확인해보니 해당 플러그인이 포함되어 있었다.

✔️ input/output 에 대한 예제

2.2. 이벤트 레코드에 필드 추가하기

record_modifier 타입의 필터를 사용하여 필드를 추가/수정 할 수 있다.
추가/수정되는 필드는 <record> 내에 정의 해주면 된다.
기본 내장된 플러그인은 아니며, fluent-plugin-record-modifier 플러그인을 설치해줘야 한다. (https://github.com/repeatedly/fluent-plugin-record-modifier)

<filter kubernetes.**>
  @type                           record_modifier
  tag                             ${record.dig("kubernetes", "container_name").gsub('-', '.')}
  <record>
    @timestamp                    ${(Time.at(time) + (60*60*9)).strftime('%Y-%m-%dT%H:%M:%S.%L+09:00')}
    cluster_name                  "xoauth-dev"
    hostname                      "#{ENV['K8S_NODE_NAME']}"
    container_image               ${record.dig("kubernetes", "container_image")}
    pod_name                      ${record.dig("kubernetes", "pod_name")}
  </record>
</filter>

✔️ fluent-plugin-record-modifier 설치는 언제?

위 k8s metadata 필터와 동일하게 daemonset pod 의 Gemfile 에 명시가 되어있다.

✔️ record_transformer 와의 차이점은?

속도가 더 빠르다고 한다. 그외의 내용은 깃헙을 참고한다.

2.3. 서비스 Application에서 출력한 로그 파싱

parser 타입의 필터는 key_name에 명시된 필드를 파싱하고 이벤트 레코드를 파싱된 결과로 변경한다.
위 input의 <source> 태그에서 message 키에 매핑된 application 로그를 파싱한다.

<filter kubernetes.**>
  @type                           parser
  key_name                        message
  reserve_data                    true
  remove_key_name_field           true
  <parse>
    @type                         json
  </parse>
</filter>

✔️ reserve_data

파싱된 결과에서 원래 key-value 쌍을 유지한다.

<filter foo.bar>
  @type parser
  key_name log
  reserve_data true
  <parse>
    @type json
  </parse>
</filter>

✔️ removekeyname_field

파싱에 성공하면 key_name에 해당하는 필드를 지운다.

<filter foo.bar>
  @type parser
  key_name log
  reserve_data true
  remove_key_name_field true
  <parse>
    @type json
  </parse>
</filter>

2.4. 불필요한 K8S Metadata 정보 제거

위 recordmodifier filter에서 필요한 kubernetes 메타 정보만 새로 추가했으므로, kubernetesmetadata filter에서 추가한 메타정보를 모두 삭제한다.

<filter kubernetes.**>
  @type                           record_transformer
  remove_keys                     $.kubernetes
</filter>

위 필터를 추가하지 않으면 불필요한 kubernetes 메타정보들이 표시된다.
따라서 kubernetes_metadata filter 에서 생성된 메타정보 중, 필요한 정보만 새로운 key로 이벤트 레코드에 추가해주는것이 좋다.

3. Output에 대한 설정

<match **>
  @type copy
  <store>
    @type                         kafka2
    @id                           out_kafka
    brokers                       logis-kafka.dev.kakaoi.io:9092
    max_send_retries              10
    required_acks                 1

    default_topic                 xoauth-dev

    exception_backup              false
    compression_codec             gzip

    <format>
      @type                       json
    </format>

    <buffer topic,tag>
      @type                       file
      path                        /var/log/td-agent/buffer/td
      flush_interval              5s
      chunk_limit_size            16M
      queue_limit_length          32
      retry_forever               true
    </buffer>
  </store>
</match>

/var/run/docker.sock의 permission denied 발생하는 경우

Wed, 14 Sep 2022 00:00:00 GMT

아래 명령어 실행 후 docker 재시작 또는 해당 유저 ssh 재접속

# usermod로 사용자를 docker 그룹에 추가
$ sudo usermod -aG docker [계정명]

만약 위 명령어 실행 후 터미널 재접속까지 했으나 permission denied 이 계속 발생한다면..
/var/run/docker.sock 파일의 권한을 666으로 변경한다.
그럼 그룹 내 다른 사용자도 접근 가능하게 변경된다.

# chmod 이용하여 모든 유저 읽기/쓰기 가능하도록 파일 권한 변경
$ sudo chmod 666 /var/run/docker.sock

swap 메모리 초기화

Sat, 03 Sep 2022 00:00:00 GMT

리눅스에서 일시적 메모리 사용의 증가로 swap을 사용하게될 경우 메모리에 여유가 생겨도 swap 메모리는 자동으로 초기화되지 않는다.
이것을 수동으로 초기화하려면 아래의 명령을 입력하면 된다. 당연히 root 권한에서 실행해야 한다.

$ swapoff -a && swapon -a

swapoff 처리에 시간이 조금 오래 걸릴 수 있는데 서버가 멈춘 것은 아니므로 걱정하지 않아도 된다.
swap 메모리에서 필요한 부분을 물리 메모리로 옮기는 처리중인 것이다.

클러스터 이전 작업 로그

Tue, 23 Aug 2022 00:00:00 GMT

이번에 인프라 이전 작업이 잦아질 듯 싶다.
작업 기록을 정리하고 스크립트를 만들 수 있는 곳을 찾아봐야겠다.

✔️ 깃헙 레포 미러링

공동체 깃헙에서 kep 깃헙으로 미러링 필요시

$ git clone --mirror {기존 레포 주소}
$ cd {기존 레포명}.git
$ git remote set-url --push origin {신규 레포 주소}
$ git push --mirror

✔️ 클러스터 생성

IKE 클러스터 생성시에 커버로스 인증을 위해 아래 스크립트 수행이 필요하다.
```
curl -s https://kenopy.kakaoicloud.in/kenopy/IKE/kenopy-ike.sh | bash
```

✔️ 클러스터 세팅

1. ingress controller 설치

1.1 도커파일 세팅

필요시 nginx-ingress docker hub 사이트에서 도커 이미지를 받는다.
official 사이트에서 도커 이미지 받아서 사내 registry에 올릴 경우, 아래 명령어를 이용한다.

$ docker pull {official docker image}

# 이미지명 변경
$ docker image tag {이미지ID} {변경할 이름}:{태그}
또는
$ docker image tag {변경전 이름}:{태그} {변경할 이름}:{태그}

$ docker push {변경된 이름}:{태그}

터미널에서 docker login 명령어

echo {패스워드/CREDENTIAL_SECRET} | docker login {registry 주소} -u {아이디/CREDENTIAL_ID} --password-stdin

1.2. 설치

k8s 매니페스트로 설치
- https://github.com/kubernetes/ingress-nginx/blob/main/deploy/static/provider/cloud/deploy.yaml
- https://raw.githubusercontent.com/kakaoicloud-guide/kubernetes-engine/main/guide-samples/settingIC/ingress-nginx/controller-v1.3.1/deploy.yml

헬름으로 설치

헬름레포 추가

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
"ingress-nginx" has been added to your repositories 

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "ingress-nginx" chart repository
Update Complete. ⎈Happy Helming!⎈

배포

$ helm install ingress-nginx ingress-nginx/ingress-nginx \
    --version {버전} \
    --set controller.hostNetwork=true \
    --namespace ingress-nginx --create-namespace

1.3. 배포 확인

파드 정상 작동 확인

$ kubectl get pods -n ingress-nginx \
-l app.kubernetes.io/name=ingress-nginx --watch

설치 완료 후 LoadBalancer EXTERNAL-IP(엔드포인트) 확인

$ kubectl get service -n ingress-nginx
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.101.148.33   xxx.xxx.xxx.xxx   80:31027/TCP,443:31138/TCP   36m
ingress-nginx-controller-admission   ClusterIP      10.104.56.176   <none>            443/TCP                      36m

2. secret 생성

✔️ docker-registry

만약, 배포시 사용하는 registry가 public이 아닐 경우, docker 인증을 위한 secret 등록이 필요하다.

$ kubectl create secret docker-registry {docker-registry secret명} \
--docker-server={registry 주소} \
--docker-username={아이디/CREDENTIAL_ID} \
--docker-password={패스워드/CREDENTIAL_SECRET}
-n {namespace}

✔️ tls 인증서

https 프로토콜 사용을 위해 tls 인증서를 등록한다.

kubectl create secret tls {tls secret명} \
--key {private key} 
--cert {cert} 
-n {namespace}

만약 private key 가 암호화 되어있을 경우 openssl 을 이용하여 복호화하여 tls secret으로 등록한다.
```
$ openssl rsa -in key.pem -out decrypted_key.pem
```

3. proxy daemonset 설치

사내에서는 외부통신과 내부통신에 대한 proxy/non-proxy 설정이 필요하다.

아래 파일을 참고해서 http-proxy 데몬셋을 적용한다.

kind: DaemonSet
apiVersion: apps/v1
metadata:
  name: set-http-proxy
  labels:
    app: set-http-proxy
spec:
  selector:
    matchLabels:
      app: set-http-proxy
  template:
    metadata:
      labels:
        app: set-http-proxy
    spec:
      hostPID: true
      containers:
        - name: startup-script
          image: {아래 명령어를 실행할 수 있는 linux 이미지}
          securityContext:
            privileged: true
          env:
            - name: PROXY
              value: {proxy 주소}
            - name: NO_PROXY
              value: {non-proxy 주소들}
          command:
            - nsenter # namespace enter의 약어. 격리된 namespace에 진입하는 명령어
            - --mount=/proc/1/ns/mnt
            - --
            - sh
            - -xc
            - |
              # Create environment file
              cloud-init-per always set_proxy_to_environment cat << EOF >> /etc/environment
              http_proxy=$PROXY
              https_proxy=$PROXY
              HTTP_PROXY=$PROXY
              HTTPS_PROXY=$PROXY
              no_proxy=$NO_PROXY
              NO_PROXY=$NO_PROXY
              EOF
              # Configure containerd with proxy
              cloud-init-per always use_environment_to_containerd tee <<EOF /etc/systemd/system/containerd.service.d/proxy.conf >/dev/null
              [Service]
              EnvironmentFile=/etc/environment
              EOF
              # Reload the daemon and restart containerd
              cloud-init-per always reload_daemon_for_containerd systemctl daemon-reload
              cloud-init-per always restart_containerd systemctl restart containerd
              trap : TERM INT
              sleep infinity & wait

적용

$ kubectl apply -f http-proxy-daemonset.yaml

✔️ EFK 세팅

1. ES 설치는 인프라팀에 요청

2. Kibana 설치

yaml 파일

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kibana
  namespace: kibana
  labels:
    app: kibana
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kibana
  template:
    metadata:
      labels:
        app: kibana
    spec:
      containers:
      - name: kibana
        image: {kibana 이미지 주소}
        ports:
        - containerPort: 5601
        env:
            - name: ELASTICSEARCH_HOSTS
              value: {ES 주소}
---
apiVersion: v1
kind: Service
metadata:
  name: kibana
  namespace: kibana
  labels:
    app: kibana
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 5601
  selector:
    app: kibana
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kibana-ingress
  namespace: kibana
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: {Kibana 호스트주소}
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: kibana
            port:
              number: 80

3. Log Aggregator 서버 설치

fluentd 로 로그 수집서버를 세팅한다.

3.1. vm 생성 후 apt 업데이트

$ sudo apt -y update

3.2. td-agent 설치

참고: https://docs.fluentd.org/installation/install-by-deb

$ curl -fsSL https://toolbelt.treasuredata.com/sh/install-ubuntu-bionic-td-agent4.sh | sh

# 설치 후 fluentd 버전 확인
$ /opt/td-agent/bin/fluentd --version

만약 아래와 같은 오류가 발생한다면, /tmp 디렉토리의 권한을 777로 변경해준 후, 작업완료되면 775로 롤백한다

# 에러:
# Couldn't create temporary file /tmp/apt.conf.** for passing config to apt-key
##
# 조치:
$ sudo chmod 777 /tmp
# 작업 완료 후 롤백
$ sudo chmod 775 /tmp

3.3. /etc/td-agent/td-agent.conf 파일 수정

기본세팅

<system>
  @log_level info 
  workers    8 # 필요에 따라 워커수 조절
</system>

<source>
  @type     monitor_agent
  port      24420
</source>

<source>
  @id   in_forward
  @type forward
  port 24224
  <parse>
    @type json
    type_key @timestamp
    time_format %Y-%m-%dT%H:%M:%S.%N%z
    localtime
  </parse>
</source>

<match tag_prefix.**>
  @type copy
  <store>
    @id   copy_stdout
    @type stdout
  </store>
  <store>
    @type                         elasticsearch
    @id                           out_es
    include_tag_key               true
    host                          {es 주소}
    port                          9200
    scheme                        http
    reload_connections            "#{ENV['ELASTICSEARCH_RELOAD_CONNECTIONS'] || 'true'}"
    logstash_prefix               ${tag}
    logstash_format               true
    logstash_dateformat           %Y.%m.%d
    type_name                     fluentd
    id_key                        _uuid
    <buffer tag>
      @type                       file
      path                        /var/log/td-agent/buffer/es/
      flush_thread_count          1
      chunk_limit_size            16mb
      queue_limit_length          2560
      flush_interval              5s
      flush_at_shutdown           true
      retry_max_times             10
      retry_forever               false
    </buffer>
  </store>
</match>

해당 VM 인바운드 정책에 forward의 포트 24224 허용 필요!!!

3.4에서 서비스 실행 후 acl 확인

$ telnet {vm 주소 또는 로그어그리게이터서버 도메인주소} 24224

3.4. td-agent 실행

서비스 실행
```
$ sudo systemctl start td-agent.service
```

로그 확인

$ tail -f /var/log/td-agent/td-agent.log

4. fluentd 데몬셋 세팅

4.1. RBAC 설정

apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluentd-service-account
  namespace: fluentd

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: fluentd-cluster-role
  namespace: fluentd
rules:
  - apiGroups:
      - ""
    resources:
      - pods
      - namespaces
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: fluentd-cluster-role-binding
  namespace: fluentd
roleRef:
  kind: ClusterRole
  name: fluentd-cluster-role
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: fluentd-service-account
    namespace : fluentd

4.2. input, filter, output 에 대한 기본 설정 (configmap.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentd-configmap
  namespace: fluentd
  labels:
    k8s-app: fluentd-logging
    kubernetes.io/cluster-service: "true"
    version: v1
data:
  fluent.conf: |
    <system>
      workers 1
      @log_level info
    </system>
    @include input-kubernetes.conf
    @include filter-kubernetes.conf

    <match **>
      @type copy
      <store>
        @type                         forward
        @id                           out_ai_forward
        expire_dns_cache              60s
        <server>
          host                        {로그어그리게이터 서버주소}
        </server>
        <buffer>
          @type                       memory
          flush_interval              5s
          flush_at_shutdown           true
        </buffer>
      </store>
    </match>

  input-kubernetes.conf: |
    <match fluent.**>
      @type                           null
    </match>
    <source>
      @type                           tail
      @id                             in_tail_container_logs
      path                            /var/log/containers/*.log
      pos_file                        /var/log/fluentd-containers.log.pos
      exclude_path                    ["/var/log/containers/fluentd*.log"]
      tag                             kubernetes.*
      read_from_head                  "#{ENV['FLUENTD_INPUT_READ_FROM_HEAD'] || 'false'}"
      limit_recently_modified         "#{ENV['LIMIT_RECENTLY_MODIFIED'] || '120m'}"
      rotate_wait                     0
      enable_stat_watcher             false
      <parse>
        @type                         regexp
        expression                    /^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<flags>[^ ]+) (?<message>.*)$/
      </parse>
    </source>

  filter-kubernetes.conf: |
    <filter kubernetes.**>
      @type                           kubernetes_metadata
      @id                             filter_kube_metadata
    </filter>
    
    
    <filter kubernetes.**>
      @type                           record_modifier
      tag                             ${record.dig("kubernetes", "container_name").gsub('-', '.')}
      <record>
        @timestamp                    ${(Time.at(time) + (60*60*9)).strftime('%Y-%m-%dT%H:%M:%S.%L+09:00')}
        cluster_name                  "cluster name"
        hostname                      "#{ENV['K8S_NODE_NAME']}"
        container_image               ${record.dig("kubernetes", "container_image")}
        pod_name                      ${record.dig("kubernetes", "pod_name")}
      </record>
    </filter>
    
    <filter kubernetes.**>
      @type                           parser
      key_name                        message
      reserve_data                    true
      remove_key_name_field           true
      <parse>
        @type                         json
      </parse>
    </filter>
    
    <filter kubernetes.**>
      @type                           record_transformer
      remove_keys                     $.kubernetes
    </filter>

4.3. 데몬셋 설정

fluentd-daemonset 도커 이미지 official github - https://github.com/fluent/fluentd-kubernetes-daemonset

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-daemonset
  namespace: fluentd
  labels:
    k8s-app: fluentd-logging
    version: v1
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      k8s-app: fluentd-logging
      kubernetes.io/cluster-service: "true"
      version: v1
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        k8s-app: fluentd-logging
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      serviceAccount: fluentd-service-account
      serviceAccountName: fluentd-service-account
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoExecute
      containers:
        - name: fluentd
          image: {fluentd 이미지}
          imagePullPolicy: IfNotPresent
          env:
            - name: K8S_NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
          resources:
            limits:
              memory: 400Mi
            requests:
              cpu: 100m
              memory: 200Mi
          volumeMounts:
            - name: varlog
              mountPath: /var/log
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
            - name: resolvconf
              mountPath: /etc/resolv.conf
            - name: tz-config
              mountPath: /etc/localtime
              readOnly: true
            - name: fluentd-config
              mountPath: /fluentd/etc/
      terminationGracePeriodSeconds: 30
      volumes:
        - name: varlog
          hostPath:
            path: /var/log
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers
        - name: resolvconf
          hostPath:
            path: /etc/resolv.conf
        - name: tz-config
          hostPath:
            path: /etc/localtime
        - name: fluentd-config
          configMap:
            name: fluentd-configmap

위 순서대로 클러스터에 apply 한다.

5. Kibana에서 index 패턴 추가

메뉴 > stack management > index patterns 에서 인덱스 생성

SSL Offloading 작업

Sun, 21 Aug 2022 00:00:00 GMT

내가 담당하고 있는 서비스에서 클라이언트 IP가 필요한 상황이 생겼는데, 계속 서버IP가 들어와서 해당 작업을 하게되었다.
이때 offloading 개념을 알게되어 정리한다.

✔️ 기존 구성

ingress 까지 HTTPS 구간이라 클라이언트와 ingress의 구현체인 nginx가 SSL 커넥션을 맺고 있다.
그러다보니 빨간색 구간이 모두 암호화되어 LB에서 헤더를 삽입할 수 없어 클라이언트 IP를 얻을 수 없는 상태였다.
KIC의 LB가 아직 Terminated HTTPS(HTTPS Offloading) 도입이 되지 않아 현재 상태로는 클라이언트 IP를 얻는건 불가능 했다.
이때 LB 와 인그레스와의 설정은 아래와 같다.
- HTTPS → 443(HTTPS)
- HTTP → 80(HTTP)
- 인증서는 인그레스 쪽에 설치

✔️ 변경된 구성

그래서 별도로 LB VIP 요청을 하여 ssl offloading 및 x-forwarded-for 적용을 하였다.
이때 new LB 와 인그레스와의 설정은 아래와 같다. (계속 https → 443 으로 연결해서.. 삽질했다)
- HTTPS → 80(HTTP)
- HTTP → 80(HTTP)
- 인증서는 new LB에 설치

✔️ HTTPS Offloading ?

서버 애플리케이션 외에서 SSL/TLS(이하 TLS) 처리를 대신 하는 것을 말한다.
대부분의 서비스의 경우 API 서버군 앞에 Proxy 서버를 두고 해당 Proxy 서버에 SSL 관련 작업을 위임한다.
Proxy 서버를 거친 데이터는 decrpty 되어 HTTP 통신을 하게 되므로. HTTPS를 사용해 통신하는 것 보다 빠른 속도로 통신하게 된다.

✔️ X-Forwarded-For(XFF) 란?

XFF 는 HTTP Header 중 하나로 HTTP Server 에 요청한 Client 의 IP 를 식별하기 위한 표준이다.

참고)
[TIL] SSL offloading 이란 무엇일까?

cron 표현식

Sun, 21 Aug 2022 00:00:00 GMT

계속 까먹는다.. 표현식에 대해 정리한다.

✔️ 특수문자

✔️ 주기 설정

✔️ 예시

0-6시 사이에 11분 + 10분마다

11,21,31,41,51 0-6 * * *

0-6시 사이 매 5분 마다

*/5 0-6 * * *

SpringBoot 빌드시 2개 jar 파일 생성되는 이유?

Sun, 07 Aug 2022 00:00:00 GMT

최근에 빌드를 하면 jar 파일이 두개가 생성이 되는걸 확인하게 되었고, 해당 부분이 궁금해서 찾아봤다.

✔️ 왜 2개가 생성이 될까?

springboot 2.5 이후 부터는 빌드시 jar 파일이 2개 생긴다.
springboot 2.4.11 document 를 보면, jar or war tasks are disabled 이기 때문에 jar task 가 기본적으로 스킵이다.

springboot 2.5.0 이후부터는 bootJar, bootWar 수행시에 jar or war task are configured to use plain 이기 때문에 plain 이라는 이름으로 jar 파일이 한개 더 생긴다.

즉, 스프링부트의 버전에 따른 gradle 플러그인의 packageing 기본 설정 차이가 있기 때문이다.

✔️ executable jar, plain jar 의 차이가 뭐지?

plain jar 파일의 경우 어플리케이션 실행에 필요한 모든 의존성을 포함하지 않고 소스코드의 클래스파일과 리소스 파일만 포함한다.
executable jar 파일의 경우 실행에 필요한 모든 의존성을 함께 빌드한다. 따라서 해당 파일은 java -jar 명령어를 통해 실행이 가능하다.

✔️ plain jar 를 생성하지 않는 방법은?

jar task 를 수행하지 않으면 된다.

[대세는 쿠버네티스] Kubernetes Architecture

Sun, 07 Aug 2022 00:00:00 GMT

✔️ Kubernetes Concepts

K8S가 관리하는 각 항목은 객체로 표시되며 이러한 객체의 속성과 상태를 확인하고 변경할 수 있다.
Kubernetes는 ‘watch loop’를 사용하여 관리되고 있는 객체에 대해 원하는 상태를 지정할 수 있고, Kubernetes는 객체를 해당 상태로 전환&유지한다.

✔️ 제어 영역 Kubernetes 구성요소

제어 영역의 역할은 전체 클러스터를 조정하는 것이다.

1. kube API Server

사용자가 직접 상호작용하는 단일 구성요소
kubectl 명령어와 통신하는 서버
kubeconfig 값으로 수신된 요청을 인증하고 요청의 승인 여부와 유효성을 확인하며 허용 제어를 관리

2. etcd

클러스터의 데이터베이스
클러스터의 상태를 저장하는 역할을 한다.
여기에는 모든 클러스터의 구성 데이터와 많은 동적 정보(클러스터의 일부인 노드, 실행해야 하는 Pod, 실행 위치)가 포함된다.
사용자는 etcd와 직접 상호작용하지 않는다.

3. kube-scheduler

Pod의 요구사항을 평가하고 가장 적합한 노드를 선택하는 역할을 한다.
노드의 자원 사용량을 모니터링 하기때문에 적합한 노드 선택이 가능
kube-apiserver를 통해 etcd에 Pod생성 요청이 있는지 감시한다. (Watch 기능)
노드를 선택하는 방법
1. 노드에 아직 할당되지 않은 Pod 객체 발견
2. 모든 노드의 리소스를 확인하여 적합한 노드를 선택
3. 해당 노드의 이름을 Pod 객체에 작성
4. 시스템의 또 다른 구성요소가 Pod를 시작

4. kube-controller-manager

컨트롤러 오브젝트들의 요구사항을 수행
클러스터의 현재 상태가 원하는 상태와 일치하지 않을 때마다 kube-controller-manager는 원하는 상태를 달성하기 위해 변경을 시도
컨트롤러 종류
- ReplicaSet, Deployment, DaemonSet, Job, CronJob

5. Kubelet

각 워커 노드에서 클러스터 에이전트 역할을 한다.
kube-apiserver 에 watch 를 걸어 자신의 노드이름이 붙은 Pod 생성 및 변경 요청에 대해 수행한다.
Kubelet은 컨테이너 런타임을 사용하여 Pod의 컨테이너를 실행하고 Pod의 수명 주기를 모니터링하고 kube-apiserver에 다시 보고한다.

6. kube-proxy

클러스터에서 Pod 간 네트워크 생성 및 연결을 유지
DaemonSet으로 설치된다.

✔️ Pod 생성 플로우

사용자가 Pod 생성 요청 → kube-apiserver 로 명령어 전달
kube-apiserver는 etcd에 해당 Pod 정보를 저장
kube-scheduler는 kube-apiserver를 통해 etcd에 새로 들어온 Pod 생성 요청을 체크하고, 노드들의 자원상태를 확인하여 적합한 노드를 선택 후 해당 Pod에 노드명 기재
모든 노드의 kublet이 kube-apiserver 를 watch 하고 있다가 자신의 노드명이 붙은 Pod 생성 이벤트가 발생하면 해당 정보를 가져온다.
kublet은 Container Runtime에게 해당 파드 생성 및 컨테이너 실행 요청을 함
그리고 kublet은 kube-proxy에게 네트워크 생성 요청을 하게되고, kube-proxy는 새로 생성된 컨테이너가 네트워크 통신이 되도록 도와줌

✔️ Deployment 생성 플로우

Controller Manager Pod 내에 여러 컨트롤러들에 대한 기능들이 각각의 스레드 형태로 돌아가고 있다.
사용자가 Deployment 생성 요청 → kube-apiserver로 명령어 전달
kube-apiserver는 etcd에 해당 Deployment에 대한 정보를 저장
Controller Manager Pod 내의 Deployment 스레드가 이를 감지하여 ReplicaSet 생성을 요청한다.
Controller Manager Pod 내의 ReplicaSet 스레드가 이를 감지하여 replica 개수만큼 Pod 생성 요청을 한다.
이후에 파드 생성 플로우로 진행한다.

Bean 초기화/ 소멸 방법 3가지

Sat, 30 Jul 2022 00:00:00 GMT

1. InitializingBean, DisposableBean 인터페이스

이 인터페이스는 스프링 전용 인터페이스이다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
초기화, 소멸 메소드의 이름을 변경할 수 없다.
코드를 수정할 수 없는 외부 라이브러리에 적용할 수 없다.
현재는 이보다 더 좋은 방법이 있기 때문에 거의 사용 되지 않는다.

class BeanTest : **InitializingBean, DisposableBean** {

    init {
        println("call initBlock")
    }

    fun initTest() {
        println("call initTest")
    }

    fun destroyTest() {
        println("call destroyTest")
    }

    // 의존관계 주입이 끝나면 호출
    **override fun afterPropertiesSet**() {
        initTest()
    }

		// 스프링 컨테이너 종료시 호출
    **override fun destroy**() {
        destroyTest()
    }
}

2. initMethod, destroyMethod

빈을 생성하기 위한 @Bean 어노테이션에 initMethod와 destroyMethod를 사용하여 지정
스프링 빈이 스프링 코드에 의존하지 않는다.
메소드의 이름을 자유롭게 변경할 수 있으며, 코드에 접근할 수 없는 외부 라이브러리에도 초기화, 종료 메소드를 적용할 수 있다.

@Configuration
class WebConfig {

    **@Bean(initMethod = "initTest", destroyMethod = "destroyTest")**
    fun getBeanTest(): BeanTest {
        return BeanTest()
    }
}

class BeanTest {
    private val logger = LoggerFactory.getLogger("!!! bean check log !!!")

    init {
        logger.info("call initBlock")
    }

    fun initTest() {
        logger.info("call initTest")
    }

    fun destroyTest() {
        logger.info("call destroyTest")
    }
}

2.2. 종료 메소드 추론

또한 destroyMethod에는 inferred라는 추론 기능이 추가되어 있다.
일반적으로 종료 메소드의 이름으로 close 또는 shutdown을 많이 이용하기 때문에, close 또는 shutdown 함수가 존재하면 이를 소멸자 메소드로 인식하여 호출한다.
이러한 추론 기능을 사용하고 싶지 않으면 destroyMethod="" 처럼 destroyMethod를 공백으로 지정하면 된다.

@Configuration
class WebConfig {

    @Bean(initMethod = "initTest")
    fun getBeanTest(): BeanTest {
        return BeanTest()
    }
}

class BeanTest {
    private val logger = LoggerFactory.getLogger("!!! bean check log !!!")

    init {
        logger.info("call initBlock")
    }

    fun initTest() {
        logger.info("call initTest")
    }

    **fun close() { // 스프링 컨테이너 종료시 호출됨
        logger.info("call destroyTest")
    }**
}

3. PostConstruct, PreDestroy

최신 스프링에서 가장 권장하는 방법이다.
애노테이션 하나만 붙이면 되므로 매우 편리하다.
패키지를 확인해보면 javax.annotation.PostConstruct이다.스프링에 종속적인 기술이 아니라 JSR-250이라는 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 동작한다,.
컴포넌트 스캔과 잘 어울린다.
외부 라이브러리에는 적용하지 못하기 때문에 외부 라이브러리를 초기화, 종료해야 한다면 @Bean 기능을 사용하면 된다.

@Configuration
class WebConfig {

    @Bean()
    fun getBeanTest(): BeanTest {
        return BeanTest()
    }
}

class BeanTest {
    private val logger = LoggerFactory.getLogger("!!! bean check log !!!")

    init {
        logger.info("call initBlock")
    }

    **@PostConstruct**
    fun initTest() {
        logger.info("call initTest")
    }

    **@PreDestroy**
    fun destroyTest() {
        logger.info("call destroyTest")
    }
}

4. 정리

보통은 @PostConstruct, @PreDestroy 을 사용하는걸 권장하지만, 외부 라이브러리 초기화/ 소멸시 처리해야 할 과정이 있다면, @Bean 의 InitMethod, destroyMethod를 사용하면 된다.

4.1. 만약 SIGKILL 시그널(kill -9 {PID})로 종료가 되었다면,

SIGKILL은 프로세스를 즉시 종료 시킨다. 해당 시그널을 받으면 프로세스가 종료되기 전에 수행되어야 하는 종료 절차를 실행하지 않고 즉시 종료하므로 graceful shutdown을 위해서라면 해당 시그널을 통해 프로세스를 종료시키는 것은 피해야한다.

4.2. 호출 순서는?

init : @PostConstruct → InitializingBean 인터페이스 → @Bean initMethod
destroy : @PreDestroy → DisposableBean 인터페이스 → @Bean destroyMethod

동적 라이브러리 적용

Mon, 25 Jul 2022 00:00:00 GMT

이번에 사진 피처 추출 LIB를 프로젝트에 적용하게 되어 해당 작업에 대한 내용을 정리한다.

1. gradle 에 dependency 적용

files 함수를 사용하여 jar 파일 의존성 추가

2. intelliJ에 동적 라이브러리 적용

2.1. project settings 에 동적 라이브러리 적용

Project Structure(command + ;) → Libraries → New Project Library → Java

동적 라이브러리 디렉토리 선택 및 적용 모듈 선택

2.2. VM 옵션에 적용

Run/Debug Configuration → VM options 필드에 java.library.path 적용

-D**java.library.path=[동적 라이브러리 경로]**

3. UnsatisfiedLinkError

동적 라이브러리가 제대로 적용이 되지 않았을 경우, 아래와 같은 UnsatisfiedLinkError 오류가 발생한다.

java.lang.UnsatisfiedLinkError: no xxxxx in java.library.path: 
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2429) ~[na:na]
at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818) ~[na:na]
at java.base/java.lang.System.loadLibrary(System.java:1989) ~[na:na]
...

4. 기타 알게된 내용

4.1. 동적 라이브러리 확장자

window : *.dll
linux: *.so
mac : *.dylib

4.2. LDLIBRARYPATH와 java.library.path

LDLIBRARYPATH 환경변수는 ‘로더(Loader)‘가 공유 라이브러리나 동적 라이브러리를 찾아야 할 때 어떤 경로를 찾아가야 하는지를 지정하는 환경변수다. 실행 파일을 찾아가는 PATH 환경변수의 라이브러리 버전이라고 생각하면 된다.
로더가 라이브러리를 로딩할 때 우선적으로 LDLIBRARYPATH에 명시된 경로들을 찾아가면서 공유 라이브러리와 동적 라이브러리 파일을 찾게 되며, 그 다음에 표준 라이브러리 경로인 ‘/lib’과 ‘/usr/lib’을 찾게 된다.
자바 애플리케이션을 실행할 때 공유 라이브러리 경로를 -Djava.library.path 옵션으로 주게 되는데, LDLIBRARYPATH 환경변수로 경로를 지정한 경우 -Djava.library.path 옵션으로 입력한 것처럼 경로를 찾아서 라이브러리를 로드하게 된다.
결론은, LDLIBRARYPATH 로 OS에 적용하는것과 java 실행시 옵션을 주는것은 같은 역할을 한다.

Spring + Kotlin 멀티모듈 생성

Sat, 23 Jul 2022 00:00:00 GMT

이번에 본사 인프라에서 kep 인프라로 이전하게 되면서 Ruby on Rails 로 되어있는 프로젝트를 Kopring 으로 변경하기로 결정을 하였다.
해당 프로젝트는 여러개의 서비스가 한 프로젝트에 모두 담겨 있는데, 멀티 모듈로 구성하면 좋을 듯 하여 코프링으로 멀티모듈을 구성하게 되었다.

✔️ 환경

SpringBoot 2.7.2
Kotlin 1.6.21
Gradle 7.5

✔️ 구성 방법

현재 한 프로젝트 내에 여러 도메인의 서비스들이 존재한다.
추후 서비스 단위로 외주를 주거나, 다른 팀으로 넘어갈때를 대비하여 아래와 같은 구조로 생각했다.

✔️ 멀티 프로젝트 생성

1. 프로젝트 생성

1.1. 프로젝트 생성은 spring initializer / kotlin + gradle 로 구성하였다.

1.2. 상위 프로젝트의 src 디렉토리는 불필요하므로 삭제한다.

2. 서브 모듈 생성

2.1. core, api-server1, api-server2 모듈을 생성한다.

2.2. src를 제외하고는 불필요 하므로 삭제한다.

3. root 프로젝트 settings.gradle.kts 파일 설정

settings.gradle.kts 는 빌드 대상 프로젝트를 설정하는 파일이다.
서브 모듈을 include 해주면 gradle 탭의 root 프로젝트 하위에 모듈이 표시가 된다.

3.1. settings.gradle.kts 파일 수정

3.2. 같은 root 프로젝트와 같은 레벨에 생긴 모듈들은 모두 unlink를 해준다.

⚠️ 만약 unlink 를 안하면??

빌드를 시도할 경우 root 프로젝트의 하위 모듈이 빌드가 되지 않고, 같은 레벨에 있는 모듈이 빌드가 된다.
이는 파일명 자체에서도 확인할 수 있는데, 하위 모듈이 될 경우 해당 프로젝트 명은 콜론(:) 표시가 되어야 하는데, unlink를 하지 않은 api-server2의 경우 파일명 뒤에 프로젝트명에 콜론표시가 없다.

4. build.gradle.kts

많이 삽질한 단계…

각각 모듈 내의 build.gradle.kts 에 설정을 해줘도 되지만, 관리를 편하게 하기 위해 root 프로젝트의 build.gradle.kts 파일에 모두 설정하도록 하였다. (그래서 위 서브 모듈 생성시에 src를 제외하고 모두 지웠다.)

AS IS)

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
	id("org.springframework.boot") version "2.7.2"
	id("io.spring.dependency-management") version "1.0.12.RELEASE"
	kotlin("jvm") version "1.6.21"
	kotlin("plugin.spring") version "1.6.21"
}

group = "com.example"
version = "0.0.1-SNAPSHOT"
java.sourceCompatibility = JavaVersion.VERSION_17

repositories {
	mavenCentral()
}

dependencies {
	implementation("org.springframework.boot:spring-boot-starter-web")
	implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
	implementation("org.jetbrains.kotlin:kotlin-reflect")
	implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
	testImplementation("org.springframework.boot:spring-boot-starter-test")
}

tasks.withType<KotlinCompile> {
	kotlinOptions {
		freeCompilerArgs = listOf("-Xjsr305=strict")
		jvmTarget = "17"
	}
}

tasks.withType<Test> {
	useJUnitPlatform()
}

TO BO)

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
	id("org.springframework.boot") version "2.7.2"
	id("io.spring.dependency-management") version "1.0.12.RELEASE"
	kotlin("jvm") version "1.6.21"
	kotlin("plugin.spring") version "1.6.21"
}

allprojects {
	repositories {
		mavenCentral()
	}
}

subprojects {
	apply {
		plugin("org.springframework.boot")
		plugin("io.spring.dependency-management")
		plugin("kotlin")
	}

	group = "com.example"
	version = "0.0.1-SNAPSHOT"
	java.sourceCompatibility = JavaVersion.VERSION_17

	dependencies {
		implementation("org.springframework.boot:spring-boot-starter-web")
		implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
		implementation("org.jetbrains.kotlin:kotlin-reflect")
		implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")

		testImplementation("org.springframework.boot:spring-boot-starter-test")
	}

	tasks.withType<KotlinCompile> {
		kotlinOptions {
			freeCompilerArgs = listOf("-Xjsr305=strict")
			jvmTarget = "17"
		}
	}

	tasks.withType<Test> {
		useJUnitPlatform()
	}
}

project(":core") {
}

project(":api-server1") {
	dependencies {
		implementation(project(":core"))
	}
}

project(":api-server2") {
	dependencies {
		implementation(project(":core"))
	}
}

allprojects

root project 및 하위 프로젝트 모두에 대한 의존성 관리

subprojects

setting.gradle 에 include 된 프로젝트를 전부 관리

project

하위 프로젝트의 의존성 관리
core 의 경우 공통 모듈이기 때문에 api-server1, api-server2 에 의존성 주입

5. application.yaml 설정

각 api 모듈들은 각 다른 포트로 실행되어야 하므로 port 를 다르게 지정해준다.

✔️ 공통모듈 의존성 테스트

core 모듈에 요청 로깅 필터 클래스 생성 후 빈으로 등록하여 각 api 모듈에서 로깅이 되는지 확인 한다.

1. core 모듈에 RequestLoggingFilter 생성 후 Bean으로 등록

ReqeustLoggingFilter 클래스

class RequestLoggingFilter : OncePerRequestFilter() {

    private val accessLogger: Logger = LoggerFactory.getLogger("ACCESS_LOGGER")

    override fun doFilterInternal(originalRequest: HttpServletRequest, originalResponse: HttpServletResponse, filterChain: FilterChain) {
        filterChain.doFilter(originalRequest, originalResponse)
        accessLogger.info("access log")
    }
}

WebConfig 클래스에서 bean 으로 등록

@Configuration
class WebConfig : WebMvcConfigurer {

    @Bean
    fun requestLoggingFilter(): FilterRegistrationBean<RequestLoggingFilter> {
        val filterRegistrationBeanRequest: FilterRegistrationBean<RequestLoggingFilter> = FilterRegistrationBean<RequestLoggingFilter>(
            RequestLoggingFilter()
        )
        filterRegistrationBeanRequest.setName("RequestLoggingFilter")
        return filterRegistrationBeanRequest
    }
}

이때 아래와 같이 ‘open’ 키워드를 사용하라는 오류가 발생한다.

코틀린에서는 기본적으로 클래스에는 final 키워드가 추가되며, 상속이 불가능하도록 되어있는데,
Spring Boot 2.x 버전부터는 CGLIB Proxy 방식으로 Bean을 관리하고 있다. CGLIB Proxy는 Target Class를 상속받아 생성하기 때문에 open 으로 상속이 가능한 상태이어야 한다.
때문에 all-open 플러그인이 필요하다.

참고)
All-open compiler plugin | Kotlin
[kotlin] class 사용법

build.gradle.kts 의 subprojects/ apply 블럭 내에 kotlin-spring 플러그인을 추가해준다.
(kotlin-allopen 와 동일)

2. 각 api 모듈에 controller 생성 후 테스트

api-server1, api-server2 모두 테스트시에 logging이 되지 않는다. 왜?

3. ComponentScan 설정

프로젝트가 실행되면서 component scan을 하게되는데, 별도로 ComponentScan 관련 설정을 하지 않으면 @SpringBootApplication 이 정의된 곳이 base package 가 된다.

따라서 각 @SpringBootApplication 가 설정되어 있는 클래스에 ComponentScan 설정을 해줘야 한다.

다시 테스트를 해보면 api-server1, api-server2 모두 logging 되는것을 확인 할 수 있다.

참고)

[Spring] Kotlin Fuel

Tue, 31 May 2022 00:00:00 GMT

■ Fuel

The easiest HTTP networking library for Kotlin/Android.
request, response, result 를 구조분해하여 편리하게 가져다 쓸 수 있다.
Asynchronous 와 blocking 을 제공한다.
async request 취소기능 제공
Upload files 기능을 제공

■ Async mode

// Using httpGet() over a String is giving us a Triple<Request, Response, Result>.

"https://httpbin.org/get".httpGet().responseString { request, response, result ->
  when (result) {
    is Result.Failure -> {
      val errorData = String(result.error.errorData)
    }
    is Result.Success -> {
      val data = result.get()
    }
  }
}

FuelManager.instance.basePath = "https://httpbin.org"
"/get".httpGet().responseString { request, response, result ->
    val (data, error) = result
    if (error == null) {
        //do something when success
    } else {
        //error handling
    }
}

■ Blocking mode

// Using httpGet() over a String is giving us a Triple<Request, Response, Result>.
    
val (request, response, result) = "https://httpbin.org/get"
    .httpGet()
    .responseString()

■ Result

operation 의 결과 (success or failure) 를 포함하고 있는 functional-style data structure

fun response(handler: (Request, Response, Result<ByteArray, FuelError>) -> Unit)

fun responseString(handler: (Request, Response, Result<String, FuelError>) -> Unit)

fun responseJson(handler: (Request, Response, Result<Json, FuelError>) -> Unit)
val jsonObject = json.obj() //JSONObject
val jsonArray = json.array() //JSONArray


fun <T> responseObject(deserializer: ResponseDeserializable<T>, handler: (Request, Response, Result<T, FuelError>) -> Unit)

■ 무엇이 쉽나

Adding Parameters

URL encoded style for GET and DELETE request

Fuel.get("https://httpbin.org/get", listOf("foo" to "foo", "bar" to "bar"))
    .url
// https://httpbin.org/get?foo=foo&bar=bar

Support x-www-form-urlencoded for PUT, POST and PATCH

Fuel.post("https://httpbin.org/post", listOf("foo" to "foo", "bar" to "bar"))
    .also { println(it.url) }
    .also { println(String(it.body().toByteArray())) }

// https://httpbin.org/post
// "foo=foo&bar=bar"

Adding Request Body use application/json

Fuel.post("https://httpbin.org/post")
    .jsonBody("{ \"foo\" : \"bar\" }")
    .also { println(it) }
    .response { result -> }

Adding Progress callbacks

Request progress

Fuel.post("/post")
    .body(/*...*/)
    .requestProgress { readBytes, totalBytes ->
      val progress = readBytes.toFloat() / totalBytes.toFloat() * 100
      println("Bytes uploaded $readBytes / $totalBytes ($progress %)")
    }
    .response { result -> }

Response progress

Fuel.get("/get")
    .responseProgress { readBytes, totalBytes ->
      val progress = readBytes.toFloat() / totalBytes.toFloat() * 100
      println("Bytes downloaded $readBytes / $totalBytes ($progress %)")
    }
    .response { result -> }

Using multipart/form-data(UploadRequest)

Fuel.upload("/post")
    .add { FileDataPart(File("myfile.json"), name = "fieldname", filename="contents.json") }
    .response { result -> }

Fuel.upload("/post")
    .add(
        FileDataPart(File("myfile.json"), name = "files[]", filename="contents.json"),
        FileDataPart(File("myfile2.json"), name = "files[]", filename="contents2.json"),
        FileDataPart(File("myfile3.json"), name = "files[]", filename="contents3.json")
    )
    .response { result -> }

Cancle an async Request

val request = Fuel.get("https://httpbin.org/get")
  .interrupt { request -> println("${request.url} was interrupted and cancelled") }
  .response { result ->
    // if request is cancelled successfully, response callback will not be called.
    // Interrupt callback (if provided) will be called instead
  }

request.cancel() // this will cancel on-going request

Debug Logging

val request = Fuel.post("https://httpbin.org/post", parameters = listOf("foo" to "foo", "bar" to "bar", "key" to "value"))
println(request.cUrlString())

// curl -i -X POST -d "foo=foo&bar=bar&key=value" -H "Accept-Encoding:compress;q=0.5, gzip;q=1.0" -H "Device:Android" -H "Content-Type:application/x-www-form-urlencoded" "https://httpbin.org/post"

Asynchronous API

non-blocking asynchronous request 를 보통 사용한다고 하는데 이는 무엇인가?
먼저 Async, Sync & Blocking, Non-Blocking 의 차이를 살펴보자
작업을 요청하는 클라이언트 : A
작업을 수행해서 결과를 return : B

Sync & Async : 작업의 주체성을 누가 갖는가 => A / B
Blocking & Non-Blocking : 로직의 흐름 => 멈춘다. / 안 멈춘다.

Sync-Blocking : A 는 B 가 완료할 때까지 계속 기다린다.
Sync-Non-Blocking : A 가 작업의 주체성을 갖고 있으며, B 가 작업을 완료할 때까지 핑퐁하면서 완료 여부를 체크한다.

Non-Blocking : B 가 A 에게
Async-Blocking : A 가 넘겨준 콜백 함수를 B 가 실행하고 완료하는 것을 기다린다.
Async-Non-Blocking : A 가 B 에게 콜백 함수를 넘겨주고 A 는 자신의 일을 계속 진행하다가 B 가 작업 완료하면 A 가 넘겨 준 콜백 함수를 수행한다.

■ 제목입니당 ■ 서브제목입니당 ■ 서브제목2입니당

This is green color text
This is red color text
This is blue color text

안녕

이미지

- hello
+ green
! orange
# gray

[Github] Github Actions

Fri, 20 May 2022 00:00:00 GMT

참고

https://docs.github.com/en/actions

[K8S] ingress apiVersion 변경

Sat, 30 Apr 2022 00:00:00 GMT

ingress 리소스파일을 kubectl로 apply 할때 아래와 같은 경고 메시지가 발생하였다.

Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; 
use networking.k8s.io/v1 Ingress

ingress apiVersion 중 extensions/v1beta1 이 1.14 버전부터 deprecated 되었으니,
networking.k8s.io/v1 을 사용하라는 경고였다.

쿠버네티스 버전을 확인해보니 1.21 버전으로 확인이 되었다.

ingress apiVersion 변경 후에 다시 apply를 하니 serviceName, servicePort 필드를 해석할 수 없다는 오류가 발생하였다.
확인해보니 정의하는 부분이 변경되어 아래와 같이 적용하였다.

[Shell] 자주 사용하는 문법

Sat, 30 Apr 2022 00:00:00 GMT

■ 자주 사용하는 문법 정리 1. null 체크

if [ -z $1 ]
then
        echo "null input"
fi

[Shell] /dev/null로 출력 버리기

Fri, 29 Apr 2022 00:00:00 GMT

/dev/null 에 전송된 데이터는 버려지므로 출력이 불필요한 경우는 /dev/null에 출력을 지정하는게 좋다.

# 표준 출력만 무시
$ script.sh 1> /dev/null

# 표준 오류 출력만 무시
$ script.sh 2> /dev/null

# 표준 출력, 오류 모두 무시
$ script.sh > /dev/null 2>&1

# 표준 출력, 오류 각각 다른 파일로 저장
$ script.sh 2> fail.log 1> success.log

■ 파일 설명자

0 : 표준 입력
1 : 표준 출력
2 : 표준 오류 출력

[Docker] 이미지 삭제시 conflict 오류 발생

Fri, 29 Apr 2022 00:00:00 GMT

■ 문제
docker 이미지 삭제시에 아래와 같은 오류 발생

$ docker rmi {image id}
Error response from daemon: conflict: unable to delete {image id} (cannot be forced)
- image has dependent clid images

■ 원인
image id 를 특정하게 되면 보이지 않은 많은 여러 태그들 또한 같이 선택이 되기 때문

■ 해결
image-name:tag 로 특정 이미지만 삭제하도록 한다.

$ docker rmi {image-name}:{tag}

[Spring] application.yml 정리

Thu, 28 Apr 2022 00:00:00 GMT

■ JPA 관련 필드

■ spring.jpa.database-platform

JPA 데이터베이스 플랫폼 지정

■ spring.jpa.open-in-view

OSIV(Open Session In View)는 웹 요청이 완료될 때까지 동일한 EntityManager를 갖도록 해줍니다.
스프링부트에서 OSIV가 기본값으로 true인데, 성능과 확장상 면에서 안좋다고 해서 false로 설정을 껏습니다.

■ spring.jpa.show-sql

콘솔에 JPA 실행 쿼리를 출력합니다.

■ spring.jpa.hibernate.format_sql

콘솔에 출력되는 JPA 실행 쿼리를 가독성있게 표현합니다.

■ spring.jpa.hibernate.ddl_auto

데이터베이스 초기화 전략을 설정


none	아무것도 실행하지 않음
create	SessionFactory가 시작될 때 기존테이블을 삭제 후 다시 생성
create-drop	create와 같으나 SessionFactory가 종료될 때 drop을 실행
update	변경된 스키마만 반영(제거는 하지 않음)
validate	엔티티와 테이블이 정상적으로 매핑되었는지만 확인(다르면 예외 발생)

■ DB 관련 필드

■ logging.level.org.hibernate.type.descriptor.sql

SQL에서 물음표로 표기된 부분( bind parameter )을 로그로 출력해서 확인할 수 있습니다.

■ spring.datasource.initialization-mode

alwasy로 설정해야 외장 DB 초기화 가능
설정하지 않으면 기본으로 never로 설정: Embedded DB 사용 -> ex. HSQL, H2, Derby

■ spring.datasource.data

sql 파일 경로를 지정하면 지정된 파일의 스크립트를 실행
ex. spring.datasource.data=classpath:member.sql, book.sql
기본값은 classpath:schema.sql, classpath:data.sql
DB 종류에 따라 다른 스크립트를 사용하려면 spring.datasource.platform을 해당 DB종류(ex. mysql, posgresql)로 설정하고 schema-mysql.sql, data-mysql.sql과 같이 사용

■ 예제 ■ mysql 기준

server:
  shutdown: graceful

spring:
  main:
    banner-mode: off
  datasource:
    url: jdbc:mysql://{host}:{port}/{db}?useSSL=false&authcommit=false
    username: {uername}
    password: {password}
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    database-platform: org.hibernate.dialect.MySQL5InnoDBDialect
    database: mysql
    open-in-view: false
    show-sql: false
    hibernate:
      ddl-auto: none
    properties:
      hibernate:
        format_sql: true
  redis:
    host: {host}
    port: {port}
    database: 0

logging:
  level:
    root: DEBUG

■ h2 기준

spring:
  h2:
    console:
      enabled: true
      path: /test
  datasource:
    jdbc-url: jdbc:h2:mem:default
    driver-class-name: org.h2.Driver
    username: sa
    password: sa
  jpa:
    database-platform: org.hibernate.dialect.H2Dialect
    database: h2
    hibernate:
      ddl-auto: create-drop
    generate-ddl: true
    defer-datasource-initialization: true

[K8S] 컨트롤러

Sun, 10 Apr 2022 00:00:00 GMT

1. Controller

서비스를 관리하고 운영하는데 도움을 준다.
아래 기능들을 제공한다.

1.1 Auto Healing

파드에 문제가 생기거나 또는 파드를 스케줄링하는 노드가 다운이 될 경우 컨트롤러가 인지하여 새로운 노드에 파드를 재생성
종류:
- ReplicationController
- ReplicaSet
- StatusfulSet
- DaemonSet

1.2 Auto Scaling

파드의 리소스 상태가 limited 되었을 경우 컨트롤러가 인지하여 자동으로 파드를 한개 더 생성
부하분산 및 파드가 죽지 않도록 함
종류:
- HPA

1.3 Software Update

여러 파드에 대한 업그레이드를 지원한다.
업그레이드 도중 문제 발생시에 롤백도 지원한다.
종류:
- Deployment

1.4 Job

일시적인 작업이 필요할 경우 파드를 생성하여 작업을 수행하고, 완료 후에는 자원을 반납한다.
효율적인 자원 사용이 가능
종류:
- CronJob
- Job

2. Replication Controller/ ReplicaSet

Replication Controller는 deprecated 되었고, 대체로 ReplicaSet을 사용한다.
둘다 template, replicas 기능을 가지고 있다.
ReplicaSet에는 selector 기능이 추가되었다.

2.1. Template

컨트롤러와 파드는 label과 selector로 연결이 된다. (서비스와 동일)
컨트롤러를 만들때 template에 파드 내용을 저장하고, 컨트롤러에서 파드를 재생성 할 경우 해당 template 내용을 참고한다.
파드의 버전을 업데이트 하는 방법
- 먼저 template의 파드 내용을 업데이트 한 후,
- 기존에 연결되어 있는 파드를 다운
- 업데이트된 template로 파드 재생성

2.2. Replicas

replicas 만큼 파드가 관리된다.
pod를 따로 정의하지 않고 ReplicationController만 정의하게 되면, 정의된 template 내용으로 replica 개수 만큼 파드를 자동 생성해준다

2.3. Selector

Replication Controller의 경우 label 이 동일할 경우만 연결이 된다.
- label의 key와 value 중 하나라도 값이 다를 경우 연결하지 않는다
ReplicaSet의 경우 matchLabels 와 matchExpressions 을 제공한다.

2.3.1 Match Labels

Replication Controller 의 selector 와 같이 label이 동일할 경우 연결을 한다.

2.3.2 Match Expressions

label의 key와 value를 좀 더 상세하게 컨트롤할 수 있다.
operator에는 Exists, DoesNotExist, In, NotIn 이 존재한다.
잘 사용하지 않는다.

2.4. ReplicationController에서 ReplicaSet으로 변경방법

아래 명령어로 연결된 pod는 지우지 않고 ReplicationController만 삭제
```
$ kubectl delete replicationcontrollers replication1 --cascade=false
```
pod가 지워지지 않았는지 확인

ReplicaSet 생성

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: replica2
spec:
replicas: 2
selector:
matchLabels:
  cascade: "false"
template:
metadata:
  labels:
    cascade: "false"
spec: #아래 스펙내용은 기존 ReplicationController 와 동일하게
  containers:
  - name: container
    image: kubetm/app:v1

2.5. ReplicaSet 샘플

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replica1
spec:
  replicas: 2 #파드개수를 replicas 만큼 유지를 시킨다.
  selector:
    matchLabels:
      type: web #동일한 라벨링 된 파드와 연결이 된다.
      ver: v1 #만약 template 아래 labels에 존재하지 않는 라벨을 사용할 경우 에러 발생(ex. ver: v3)
  template:
    metadata:
      name: pod1 #ReplicaSet이 해당 템플릿으로 Pod를 생성하면 "pod1"로 파드명이 만들어지지 않고 임의의 파드명으로 생성된다.
      labels:
        type: web
        ver: v1
        ver: v2
    spec:
      containers:
      - name: container
        image: kubetm/app:v1
      terminationGracePeriodSeconds: 0

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replica1
spec:
  replicas: 1
  selector: 
    #matchLabels, matchExpressions 두 조건 모두 들어갈 수 있다. or 조건이다. (matchLabels or matchExpressions)
    #template 아래 labels에 존재하는 라벨만 사용가능
    matchLabels: 
      type: web
      ver: v1
    matchExpressions:
    - {key: type, operator: In, values: [web]}
    - {key: ver, operator: Exists}
  template:
    metadata:
      labels:
        type: web
        ver: v1
        location: dev
    spec:
      containers:
      - name: container
        image: kubetm/app:v1
      terminationGracePeriodSeconds: 0

3. Deployment

ReplicaSet 기능을 포함하며 배포/ 버전업데이트에 도움이 되는 컨트롤러
Deployment에 RelicaSet에 대한 정보를 같이 기입한다
Deployment를 적용하면 ReplicaSet을 생성 하게되고, 이 ReplicaSet이 replica 개수만큼 파드를 만들게 된다.

3.1. ReCreate

v1의 파드를 모두 삭제시킨 후 v2의 파드를 실행
다운타임이 발생
별도의 자원 사용량이 필요없음
상세플로우
1.기존 ReplicaSet의 replica를 0으로 변경
2.기존 파드 삭제
3.(다운타임 발생)
4.새 ReplicaSet 생성
5.파드생성
6.서비스와 연결됨

Recreate Deployment 리소스파일

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-1
spec:
  selector:
    matchLabels:
      type: app
  replicas: 2
  strategy:
    type: Recreate #type 설정
  revisionHistoryLimit: 1 #삭제하지 않고 유지 할 ReplicaSet 개수, 기본값은 10
  template:
    metadata:
      labels:
        type: app
    spec:
      containers:
      - name: container
        image: kubetm/app:v1
      terminationGracePeriodSeconds: 10

3.2. Rolling Update

v1 파드가 그대로 유지되면서 v2의 파드를 하나 생성
v2의 파드가 제대로 생성이 되었으면 v1의 파드를 하나 삭제
그 후 다시 v1 파드 삭제, v2 파드 생성 행위를 replica 개수 만큼 반복
하나 추가 생성된 파드만큼의 자원 사용량이 늘어남
다운타임이 발생하지 않음
상세플로우
1.Deployment의 template 변경
2.새 ReplicaSet 생성 (새로운 template 적용)
3.새 ReplicaSet의 replicas를 1로 하여 v2 파드 생성
4.v2 파드가 서비스와 연결됨
5.기존 ReplicaSet의 replicas 개수를 하나 줄여 v1 파드 하나 삭제 6.새 ReplicaSet의 replicas 개수를 하나 늘려 v2 파드 생성 후 서비스와 연결 7.v1 파드의 개수가 0이 될때까지 5-6반복
어떻게 새로 생성된 파드들은 새로 생성된 ReplicaSet을 구별하나?
- Deployment는 여러 ReplicaSet을 만들고, 각각의 ReplicaSet은 자신의 파드를 구별하기 위해 추가적인 라벨과 셀렉터를 붙인다.

RollingUpdate Deployment 리소스파일

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-2
spec:
  selector:
    matchLabels:
      type: app2
  replicas: 2
  strategy:
    type: RollingUpdate #type 설정
  minReadySeconds: 10
  template:
    metadata:
      labels:
        type: app2
    spec:
      containers:
      - name: container
        image: kubetm/app:v1
      terminationGracePeriodSeconds: 0

3.3. Blue/Green

다양한 방법으로 Blue/Green 배포를 할 수 있음(deployment 자체로 제공하진 않음)
v1 파드를 그대로 유지하면서 v2의 파드를 replica 개수만큼 생성
서비스의 label을 v2로 변경
문제 발생시 다시 서비스의 label을 v1으로 변경 (문제발생시 서비스의 라벨만 변경하면 되니 롤백이 쉬움)
문제가 없을 경우 기존 v1 파드 삭제
순간적으로 변경이 되기 때문에 다운타임이 발생하지 않음
자원 사용량은 기존의 2배가 필요
상세플로우
1.새로운 template 및 라벨이 적용된 새 ReplicaSet 생성 2.새 ReplicaSet에 의해 v2 파드가 생성됨
3.서비스에 적용된 라벨을 새로운 파드의 라벨로 변경
4.문제가 없을 경우 기존 v1 파드 및 ReplicaSet 삭제
어떻게 새로 생성된 파드들은 새로 생성된 ReplicaSet을 구별하나?
- Deployment는 여러 ReplicaSet을 만들고, 각각의 ReplicaSet은 자신의 파드를 구별하기 위해 추가적인 라벨과 셀렉터를 붙인다.

Blue/Green ReplicaSet 리소스파일

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replica1  # -> replica2로 변경하여 배포 (새로운 ReplicaSet 생성됨)
spec:
  replicas: 2
  selector:
    matchLabels:
      ver: v1 # -> v2로 변경하여 배포
  template:
    metadata:
      name: pod1
      labels:
        ver: v1  # -> v2로 변경하여 배포
    spec:
      containers:
      - name: container
        image: kubetm/app:v1  # -> 업데이트할 이미지로 변경하여 배포
      terminationGracePeriodSeconds: 0

Blue/Green Service 리소스파일

apiVersion: v1
kind: Service
metadata:
  name: svc-3
spec:
  selector:
    ver: v1 # -> v2로 변경하여 배포 (새로운 파드로 연결)
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080

3.4 Canary

불특정 다수 테스트
- v1 파드를 그대로 유지하면서 v2 파드를 생성하는데, v2 파드도 기존 서비스와 연결되도록 라벨링
- 그럼 서비스로 들어오는 일부의 트레픽은 v2 파드로 보내어 테스트 진행
- 문제 발생시 v2 파드의 컨트롤러의 replica를 0으로 변경
- 문제가 없을 경우 v2파드의 개수를 늘리고, v1파드의 개수를 줄여가며 배포 진행 (불특정 다수 테스트)
특정 타겟 테스트
- 각 버전별로 서비스를 생성후 Ingress Controller를 이용하여 유입되는 트레픽을 url로 나누어 테스트
- 문제가 없을 경우 v2 파드의 개수를 늘리고 url 원복하여 배포
- 자원 사용량은 종료시키는 v1과 새로 생성하는 v2 파드 개수에 따라 늘어남

4. DaemonSet

ReplicaSet과 다르게 노드의 자원상태와 상관없이 모든 노드에 파드가 한개씩 생긴다.
한 노드에 1개 이상의 DamonSet 파드를 띄울 수는 없지만, nodeSelector를 이용하여 제외할 노드를 선택할 수 있다.
hostPort를 사용하면 (service의 노드포트 설정) + (externalTrafficPolicy: Local) 옵션을 준 것과 동일하다.
- externalTrafficPolicy: Local 옵션은 요청한 NodeIP에 있는 Pod로 트래픽을 전달한다.
모니터링, 로그수집 등 모든 노드에 들어가야하는 서비스들을 구성할때 사용.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-2
spec:
  selector:
    matchLabels:
      type: app
  template:
    metadata:
      labels:
        type: app
    spec:
      nodeSelector: #node를 선택할 수 있다.
        os: centos
      containers:
      - name: container
        image: kubetm/app
        ports:
        - containerPort: 8080
          hostPort: 18080 #hostPort 옵션 적₩

5. Job

어떤 컨트롤러를 사용했냐에 따라 파드의 lifecycle이 달라진다.

5.1. Pod

컨트롤러를 사용하지 않고 파드로만 띄웠을 경우, 노드 또는 파드 장애시에 복구가 되지 않는다.

5.2. ReplicaSet

노드 또는 파드 장애시에 파드를 새로 생성한다. (Recreate)
파드가 일을 하지 않을 경우에 파드를 재시작해준다. (Restart)
지속적인 서비스가 요구될때 사용

Recreate vs Restart 
- Recreate는 파드를 재생성하여 IP나 파드명이 변경이 된다. 
- Restart는 파드를 재생성하지 않고 안의 컨테이너만 재시작한다.

5.3. Job

프로세스가 일을 하지 않을 경우 파드를 종료시킨다. (Finish)
이때 종료는 파드 삭제가 아닌 자원을 사용하지 않는 상태를 의미한다.

apiVersion: batch/v1
kind: Job
metadata:
  name: job-2
spec:
  completions: 6
  parallelism: 2
  activeDeadlineSeconds: 30
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: container
        image: kubetm/init
        command: ["sh", "-c", "echo 'job start';sleep 20; echo 'job end'"]
      terminationGracePeriodSeconds: 0

5. CronJob

주기적인 시간에 따라 Job을 생성하는 컨트롤러
대체로 Job은 CronJob으로 특정시간에만 작동하도록 사용한다.

#v1.22
apiVersion: batch/v1
kind: CronJob
metadata:
  name: cron-job
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: container
            image: kubetm/init
            command: ["sh", "-c", "echo 'job start';sleep 20; echo 'job end'"]
          terminationGracePeriodSeconds: 0

---
#v1.15
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cron-job-2
spec:
  schedule: "20,21,22 * * * *"
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: container
              image: kubetm/init
              command: ["sh", "-c", "echo 'job start';sleep 140; echo 'job end'"]
          terminationGracePeriodSeconds: 0

[K8S] kubectl 자주 사용하는 명령어

Mon, 04 Apr 2022 00:00:00 GMT

■ 오브젝트 생성/변경 ■ Create

같은 이름의 오브젝트가 존재할때 생성이 안됨

1. Yaml 파일로 생성

$ kubectl create -f [yaml 파일]

2. ConfigMap 생성

# file-c.txt 라는 파일로 cm-file라는 이름의 ConfigMap 생성
$ kubectl create configmap cm-file --from-file=./file-c.txt

# key1:value1 라는 상수로 cm-file라는 이름의 ConfigMap 생성
$ kubectl create configmap cm-file --from-literal=key1=value1

# 여러 key:value로 cm-file라는 이름의 ConfigMap 생성 
$ kubectl create configmap cm-file --from-literal=key1=value1 --from-literal=key2=value2

2. Secret 생성

# file-s.txt 라는 파일로 sec-file라는 이름의 Secret 생성
kubectl create secret generic sec-file --from-file=./file-s.txt

# key1:value1 라는 상수로 sec-file라는 이름의 Secret 생성
kubectl create secret generic sec-file --from-literal=key1=value1

■ Apply

기존에 같은 이름의 오브젝트가 존재할때 업데이트 됨

$ kubectl apply -f [yaml 파일]

■ Create/Apply 상태 확인

생성/업데이트 된 오브젝트 상태 확인
결과(성공 또는 실패)가 나올때까지 해당 명령어는 계속 수행중 상태가 됨

$ kubectl rollout status [오브젝트]/[오브젝트명] -n [네임스페이스명]
$ kubectl rollout status deployment/fifi-app -n dev

■ 오브젝트 조회 ■ Get 1. 파드 내용 조회

# 파드리스트 조회
$ kubectl get pods -n [namespace명]

# 좀 더 많은 내용 출력
$ kubectl get pods -n [namespace명] -o wide

# 특정 파드만 조회
$ kubectl get pod [파드명]

■ Describe

상세 내용 출력

1. 파드 내용 상세 조회

$ kubectl describe pod [파드명] -n [네임스페이스명]

2. 디플로이먼트 내용 상세 조회

$ kubectl describe deployment [디플로이먼트명] -n [네임스페이스명]

3. namespace의 resourcequota&limitrange 상세 조회

# nm-3의 Namespace에 있는 ResourceQuota들의 상세 조회
$ kubectl describe resourcequotas --namespace=nm-3

# nm-5의 Namespace에 있는 LimitRange들의 상세 조회
$ kubectl describe limitranges --namespace=nm-5

■ 오브젝트 삭제 ■ Delete 1. 파드 삭제

# 파일이 있을 경우 생성한 방법 그대로 삭제
$ kubectl delete -f ./pod.yaml

# Pod 이름 지정
$ kubectl delete pod pod1

2. ReplicationController 삭제 연결된 pod는 지우지 않고 ReplicationController만 삭제

$ kubectl delete replicationcontrollers [ReplicationController명] --cascade=false

■ 오브젝트 컨테이너 ■ Exec

# Container 들어가기
$ kubectl exec [파드명] -it /bin/bash

# Container가 두개 이상 있을때
$ kubectl exec [파드명] -c [컨테이너명] -it /bin/bash

■ Deployment Rollback 1. rollout 히스토리 확인

deployment 생성/적용시 —record=true 옵션을 넣으면 CHANGE-CAUSE 필드에 명령어가 표시됨

$ kubectl rollout history deployment [디플로이먼트명] -n [네임스페이스명]
$ kubectl rollout history deployment deployment-1 -n dev

2. 롤백

# 바로 이전 버전으로 변경
$ kubectl rollout undo deployment [디플로이먼트명] -n [네임스페이스명]
$ kubectl rollout undo deployment fifi-app -n dev

# 원하는 리비전으로 번경 (마지막 리비전이 현재 리비전)
$ kubectl rollout undo deployment [디플로이먼트명] -n [네임스페이스명] --to-revision=[리비전번호]
$ kubectl rollout undo deployment deployment-1 -n [네임스페이스명] --to-revision=2

■ Label 1. node에 라벨 추가/삭제

#os=centos 라벨 추가
$ kubectl label nodes [노드명] [라벨키]=[라벨벨류]
$ kubectl label nodes k8s-node1 os=centos

#라벨 삭제
$ kubectl label nodes [노드명] [라벨키]-
$ kubectl label nodes k8s-node1 os-

[K8S] 기본 오브젝트

Sat, 02 Apr 2022 00:00:00 GMT

1. Pod

한 파드내에서 같은 포트의 컨테이너를 가질 수 없다.
두 컨테이너 container1과 container2 는 한 호스트로 묶여 있다.
때문에 같은 파드의 각 컨테이너 내에서 다른 컨테이너로 접근시에 localhost 으로 접근할 수 있다.
파드 생성시에 고유의 아이피가 할당 된다.
이 아이피는 클러스터 내에서만 접근이 가능하며 외부에서는 접근이 불가능하다.
파드 재 생성시마다 IP가 계속 바뀐다.

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    type: web # 서비스, 디플로이먼트 등 매핑을 위한 라벨링
spec:
  containers:
  - name: container
    image: kubetm/app:v1
    ports:
    - containerPort: 8080
  terminationGracePeriodSeconds: 0 # 파드 삭제시 기본적으로 30초 후에 삭제가 되는데, 파드를 바로 삭제하기 위한 설정

2. Label

라벨은 파드뿐만 아니라 모든 오브젝트에 달 수 있다
보통은 파드에 많이 사용
목적에 따라 오브젝트들을 분리하고, 서비스로 연결하기 위함(묶어서 사용하기 위함)
라벨은 key와 value로 선언한다
한 파드에 여러개의 라벨을 달 수 있다.

3. Node Schedule

파드는 여러 노드들 중에 한 노드에 올라간다.
노드에 올라가는 방법으로는 2가지가 있는데, 한개는 스케줄러가가 자동으로 선택하는 방법과 직접 명시해주는 방법이 있다.
직접: 노드에 라벨을 달고 파드 생성시에 선택
자동 : 생성할 파드의 필요 리소스 사용량에 따라 노드 스케줄러가 판단하여 노드를 지정

4. Service

서비스도 파드와 마찬가지고 자신의 Cluster IP를 가지고 있다.
서비스와 연결된 파드들은 서비스의 Cluster IP를 통해서 접근이 가능하다.
파드는 언제든지 죽을 수 있고 재 생성이 될 수 있는 오브젝트이기 때문에 파드의 IP는 신뢰성이 떨어진다.
서비스는 사용자가 건들지 않으면 삭제되거나 재생성되지 않는다.
때문에 서비스 IP를 사용한다
서비스에서 파드의 접근을 도와주는 방식은 크게 3가지가 있다.

4.1. Cluster IP

외부에서 접근이 불가능하다.
서비스가 트레픽은 분산시켜 Pod에 연결해준다.
type 은 기본적으로 ClusterIP 이다.

$ curl 171.96.10.17:9000/health_check

4.2. Node Port

Cluster IP의 특징을 모두 가지고 있다.
모든 노드에 같은 Port가 할당이 된다.
- 주의할 점은 타겟 Pod가 있는 노드들에만 Port가 할당되는 것이 아니라 모든 노드에 Port가 할당된다.
할당된 NodeIP:Port 들이 해당 서비스로 연결이 된다.
외부에서 NodeIP:Port 로 접근이 가능하다.
nodePort 값은 옵셔널이고, 생략할 경우 자동으로 할당된다.
- Node Port의 범위 : 30000~32767
외부에서 Node1 IP: Port 로 접근을 했을 경우
- Node1에 있는 Pod로 연결되지 않고,
- 해당 서비스와 연결되어 있는 노드들 중 하나에게 트래픽을 전달한다.
- externalTrafficPolicy: Local 옵션을 사용하면 요청한 NodeIP에 있는 Pod로 트래픽을 전달한다.
순서
- External -> NodeIP:Port -> Service -> Pod

4.3. Load Balancer

Node Port의 특징을 모두 가지고 있다.
로드밸런서가 트래픽을 분산시켜 연결되어 있는 노드에게 전달한다.

■ Sample Service Yaml

apiVersion: v1
kind: Service
metadata:
  name: svc-3
spec:
  selector:             # Pod의 Label과 매칭
    app: pod
  ports:
  - port: 9000          # Service 자체 Port
    targetPort: 8080    # Pod의 Container Port
  type: ClusterIP, NodePort, LoadBalancer  # 생략시 ClusterIP
  externalTrafficPolicy: Local, Cluster    # 트래픽 분배 역할

Referenece

Kubernetes Service

https://kubernetes.io/docs/concepts/services-networking/service/

Kubernetes NodePort vs LoadBalancer vs Ingress?

https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

5. ConfigMap, Secret

image 별로 환경변수값을 정의하는것은 비효율적이므로 외부에 환경 변수를 담기위해 ConfigMap과 Secret을 사용한다.
key와 value로 정의하여 사용

5.1. ConfigMap vs Secret

ConfigMap은 일반적인 값, Secret은 보안적인 값을 저장(패스워드/ 인증키)
Secret 값을 넣을때 base64 인코딩을 해서 값을 넣어야 한다는 규칙을 가지고 있다.
Secret 값은 파드로 주입이 될때 자동으로 base64 디코딩이 되어 컨테이너 내 환경변수에 세팅이 된다.
일반적인 값들은 쿠버네티스 DB에 저장이 되는데, Secret 값은 메모리에 저장이 된다. (메모리에 저장되기 때문에 보안에 유리)
ConfigMap의 경우 key, value 값을 무한하게 넣을 수 있는데 반해, 한 Secret당 최대 1M까지만 저장이 가능하다.
Secret은 메모리에 넣어두기 때문에 많이 만들게 되면 시스템 자원에 영향을 미치게 된다.

5.2. 상수를 환경변수에 정의하여 사용

파드 생성시에 해당 파드에 정의된 ConfigMap, Secret 값을 가져와서 컨테이너 내 환경변수에 세팅을 한다.

5.3. 파일을 환경변수에 정의하여 사용

파일을 통으로 ConfigMap에 넣어 사용할 수 있다.
파일명이 key, 파일 내용이 value가 된다.
명령어를 이용하여 파일을 secret으로 만들 경우, 자동으로 base64 인코딩이 되므로 2중 인코딩이 되지 않도록 주의하자.
파드 생성시에 해당 파드에 정의된 ConfigMap, Secret 값을 가져와서 컨테이너 내 환경변수에 세팅을 한다.

5.3. 파일 마운트의 경우

원본 파일과 마운트가 되어 있으므로, ConfigMap이 수정이 되면 바로 반영이 된다.
이게 5.2과 가장 큰 차이점이다.

6. Volume 6.1. emptyDir

container 들끼리 데이터 공유를 하기 위해 volume을 사용
최초 해당 볼륨이 생성될때 항상 비어있기 때문에 emptyDir로 명칭한다.
pod 안에 생성이 되기 때문에 파드 생성시에 만들어지고, 삭제시 없어짐
해당 볼륨에는 일시적인 사용목적에 의한 데이터를 넣는다.

6.2. hostPath

한 호스트 즉, 노드의 path를 볼륨으로 사용
pod에서 해당 노드의 path를 마운트하여 사 용하므로 pod가 삭제가 되어도 노드에 있는 데이터는 삭제되지 않는다.
다만 파드가 재 생성될때 다른 노드에 생성이 될 수 있으므로 기존 노드에 사용하던 볼륨을 마운트 할 수는 없다.
- 사용자가 직접 각 노드의 볼륨들을 마운트 시키면 된다.
- 하지만, 쿠버네티스가 하는게 아니라 사용자가 직접 작업을 하므로 실수가 발생할 수 있다.
파드 자신이 할당되어 있는 호스트(노드)의 데이터를 읽거나 쓸때 사용한다.
hostPath Type
- DirectoryOrCreate : 실제 경로가 없다면 생성
- Directory : 실제 경로가 있어야됨
- FileOrCreate : 실제 경로에 파일이 없다면 생성
- File : 실제 파일이 었어야함

6.3. PVC/PV

파드에 영속성 있는 볼륨을 제공하기 위한 오브젝트
실제 필요할때 다시 공부

7. Namespace/ ResourceQuota/ LimitRange

클러스터에서 사용할 수 있는 리소스는 한정적이기 때문에 네이스페이스별로 리소스를 한정하여 사요하도록 하는 오브젝트
ResourceQuota는 Namespace 뿐만 아니라 Cluster 전체에 부여할 수 있는 권한이지만, LimitRange의 경우 Namespace내에서만 사용 가능

7.1. Namespace

한 네임스페이스 안에서 같은 종류의 오브젝트들은 같은 이름을 가질 수 없다.
- 에러: 파일 배포 실패 (pods “podName” already exists)
타 네임스페이스의 자원과 분리가 되어 관리가 된다.
- 파드의 라벨링으로 서비스와 연결을 하는데, 서로 다른 네임스페이스에 있을 경우 연결이 되지 않는다.
네임스페이스 삭제시, 그 안의 자원들도 모두 삭제가 된다.
각 네임스페이스의 파드의 IP끼리는 기본적으로 통신은 되지만, network policy 오브젝트를 이용하여 막을 수 있다.

7.2. ResourceQuota

네임스페이스의 자원한계를 설정하는 오브젝트
리소스쿼타가 지정된 네임스페이스에 파드를 생성할때는 꼭 스펙 명시를 해야한다.
- 하지 않을 경우 해당 네임스페이스로 pod 생성이 되지 않는다.
- 에러: must specify limits.memory, requests.memory
- limitRange에 default가 설정되어 있을 경우에는 상관없다.
현재 namespace에 사용된 requests 를 넘는 파드 생성 요청시 오류가 난다.
주의할 점은 ResourceQuota 생성 전에 이미 파드가 만들어져 있으면, 해당 파드들에게는 영향이 가지 않는다
- 따라서 ResourceQuota 생성 전에 파드들을 지우는게 안전하다.
- 그렇지 않을 경우, ResourceQuota 설정보다 over하여 네임스페이스에 파드들이 생성된다.
제한 가능한 항목
- Compute Resource: cpu, memory, storage
- Objects Count: Pod, Service, ConfigMap… 등 k8s 버전이 높아짐에 따라 제한할 수 있는 오브젝트가 늘어남

7.3. LimitRange

파드가 네임스페이스에 들어올 수 있는지 체크
설정값
- min: 최소 메모리값
- max: 해당 네임스페이스로 들어올 수 있는 파드의 최대 메모리 값
  -> Pod1의 경우 limit memory값이 5Gi이므로 생성이 불가능한다.
- maxLimitRequestRatio: request값과 limit값의 최대 비율
  -> Pod2의 경우 reuqest와 limit의 비율이 3을 넘어가므로 생성이 불가능한다.
- defaultRequest/ default: 스펙이 없는 pod가 들어올 경우 해당 값으로 세팅이 된다.
  -> Pod3의 경우 스펙이 없으므로 default 스펙을 따라간다.

[K8S] ingress 인증서 교체

Thu, 27 Jan 2022 00:00:00 GMT

■ 도메인에 적용되어 있는 인증서 확인 방법 1. openssl로 인증서 확인

$ openssl s_client -showcerts -connect {ip}:443 -servername {domain-name}

2. pem 인증서 디코딩 사이트에서 확인 https://www.sslcert.co.kr/tools/certificate-crt-decoder

■ 인증서 교체

인증서는 secret에 넣어 ingress 리소스 파일에 tls secret name을 매핑하는 방식을 사용했다.

1. 인증서 다운로드 및 key 파일 암호화 풀기

인증서 갱신 또는 재발급 후 인증서/키파일 다운로드
키파일이 암호화가 걸려있을 경우 복호화

$ openssl rsa -in {key파일} -out {output 파일명}
Enter pass phrase for {key파일} : pass phrase 입력
writing RSA key

2. secret 생성

# secret 생성
$ kb create secret tls {secret-name} --key {key파일} --cert {pem파일} -n {namespace}

# yaml 파일 생성
$ kb create secret tls {secret-name} --key {key파일} --cert {pem파일} -n {namespace} --dry-run=client -o yaml > secret.yaml

3. secret 확인

$ kb get secret -n dev

NAME                       TYPE                                  DATA   AGE
secret-name                kubernetes.io/tls                     2      7d20h

4. ingress resource 수정 후 적용

■ ingress resource에서 secretName 수정 후 적용

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  tls:
  - hosts:
    - example.foo.com
    secretName: {secret-name}

■ ingress 적용

$ kb apply -f ingress.yaml

■ 인그레스 목록 확인

$ kb get ing -n dev

NAME           CLASS    HOSTS                       ADDRESS         PORTS     AGE
ingress-name   <none>   onepass-app.dev.kakaoi.ai   10.183.xx.xx    80, 443   7d19h

■ ingress 상세 내용 확인

$ kb describe ing {ingress-name} -n {namespace}

Name:             ingress-name
Namespace:        namespace
Address:          10.183.xx.xx
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  wild-dev-kakaoi-ai terminates onepass-app.dev.kakaoi.ai
Rules:
  Host                       Path  Backends
  ----                       ----  --------
  onepass-app.dev.kakaoi.ai  
                             /   fifi-app:80 (192.168.46.228:8080)
  ...

참고

ingress troubleshooting

[Subject] title

Sat, 01 Jan 2022 00:00:00 GMT

■ 제목입니당 ■ 서브제목입니당 ■ 서브제목2입니당

This is green color text
This is red color text
This is blue color text

안녕

이미지

- hello
+ green
! orange
# gray

레디스 동시성 이슈

Sun, 05 Dec 2021 00:00:00 GMT

이번에 진행하게된 프로젝트에서 레디스 동시성 이슈에 대한 문제에 부딪혔다.
기존에는 어떤 방식을 사용했고, 어떻게 수정을 했는지에 대해 기록한다.

✔️ 이슈내용

레디스에 넣은 key 값이 expired 되었을 경우 특정 로직을 수행하는 기능이 있다.
만료된 키에 대한 이벤트는 Keyspace notifications 을 이용하였고, 이 이벤트는 레디스의 Pub/Sub으로 이벤트를 이용하게 된다.
즉, 서버에서 `__keyevent@__:expired`* 를 구독하고 있다가, 레디스 내의 키가 expired 가 되면, 서버에서 이벤트를 받아 처리하는 구조이다.
여기서 문제가 발생하는데, 서버가 1대 일 경우에는 문제가 없지만, 여러대의 서버일 경우에 모든 서버가 이벤트를 받아 처리하므로 중복처리가 발생하게 된다.
만약 expired 가 발생할 경우 알람이 발생하도록 로직이 구현되어 있다면, 서버 대수만큼 알람이 발생하게 된다.

✔️ 기존방식

기존에는 아래와 같은 로직으로 되어 있었다.

아직까지는 큰 문제는 없었다고 하지만, 만약 아래와 같은 상황이 발생한다면 장애로 이어지게 된다.

한 host에서 2개 이상의 pod가 뜬다면
deployment 의 replica 감소 등으로 레디스에 등록된 서버가 죽는다면

✔️ 수정된 방식

찾아보니 레디스에서 setnx 명령어를 활용하는 방법이 현재 상황에 가장 알맞아 보였다.

Redis의 setnx 명령어는 key값이 존재하지 않으면 데이터를 set하는 atomic한 명령어이다.
이 명령어를 활용하여 개발자가 직접 Lock 프로세스를 구현할 수 있다.

보통은 spin lock 으로 구현을 하는데 (lock 점유를 루프로 시도), 현재 나의 경우는 점유가 되어 있으면 skip 을 하면 되기 때문에 레디스 부하없이 쉽게 해결이 가능했다.

코드는 아래와 같다.

override fun doHandleMessage(message: Message) {
        val key = String(message.body)

        if (lock(key)) {
            try {
                // 로직 수행
            } finally {
                unlock(key)
            }
        }
    }

private fun lock(key: String): Boolean = redisTemplate.opsForValue().setIfAbsent(key, "lock") ?: false

private fun unlock(key: String) = redisTemplate.delete(key)

참고로, 스핀락을 구현해야하는 상황이면 Lettuce 라이브러리보단 Redisson 라이브러리를 사용하는게 더 낫다..!

[작업로그] CURL 을 이용하여 API 속도 체크

Fri, 24 Sep 2021 00:00:00 GMT

타 서비스 이용중에 API 타임아웃이 빈번하게 발생하여 해당 API 에 대한 응답 소요시간을 CURL 을 이용하여 체크하게 되었다.
서버 연결 소요시간 및 응답 소요시간을 각각 측정하는 옵션을 사용했다.

$ curl -sS -w " \
time_connect: %{time_connect} \
time_appconnect: %{time_appconnect} \
time_pretransfer: %{time_pretransfer} \
time_starttransfer: %{time_starttransfer} \
total_time: %{time_total}\n" \
-k -X POST https://test.com -o /dev/null

time_connect

tcp 연결하는데 걸리는 시간

time_appconnect

ssl handshake 소요 시간

time_pretransfer

HTTP인지 HTTPS인지에 따라 timeconnect 또는 timeappconnect와 거의 동일
이 값의 유일한 목적은 서버가 바이트 전송을 시작하는데 걸린 시간을 계산하기 위함이다
TTFB를 위한 준비단계로 보면 된다

time_starttransfer

서버가 응답을 준비하는데 걸린시간
TTFB(Time To First Byte)
클라이언트가 처음으로 byte를 받은 시간이다.

순서대로 curl이 시작된 이후 누적이 된다.
따라서 time_starttransfer - time_pretransfer 값이 실제 서버 처리 시간으로 볼 수 있다.

참고
https://speedtestdemon.com/a-guide-to-curls-performance-metrics-how-to-analyze-a-speed-test-result/
https://yfkwon.tistory.com/42#recentEntries

[작업로그] ObjectMapper로 String to Object 는 불가하다

Tue, 24 Aug 2021 00:00:00 GMT

이번에 RestTemplate 세팅을 하면서 req/res 로깅을 하도록 구성을 했다.
req/res 의 경우 당연히 Object(Null 포함)라 생각했기 때문에 ObjectMapper 클래스의 readValue 메소드를 이용하여
map 객체로 변환하였다.

테스트에서는 별 문제 없이 잘 작동하는 듯 하였으나…
응답값이 Json 포맷의 문자열이 아닐 경우 즉, 일반 문자열 일 경우, 오브젝트로 변환 시 아래와 같은 오류가 발생하였다.

com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'hello': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')
 at [Source: (byte[])"hello world"; line: 1, column: 7]

그래서 아래와 같이 테스트를 진행해봤다.

case1) readValue 메소드를 이용하여 string to object

val stringData = "hello world"
try {
    objectMapper.readValue(stringData.toByteArray(), String::class.java)
    println("success 1")
} catch (e: Exception) {
    println("error1 [stringData] : " + e.message) //에러 발생!!!
}

1번 케이스의 경우 에러가 발생했다.
readValue 메소드 내의 코드를 보니 JsonParser를 생성하는걸로 봐선 Json 포맷만 가능한걸로 보인다.

case2) writeValueAsString 메소드를 이용하여 object to string

val stringData = "hello world"

try {
    objectMapper.writeValueAsString(stringData)
    println("success 2") //성공!!!
} catch (e: Exception) {
    println("error2 [stringData] : " + e.message)
}

2번 케이스의 경우는 에러가 발생하지 않았다.
writeValueAsString 메소드에서는 param으로 받은 object를 serialize 하여 이를 문자열로 반환하기 때문에 정상적으로 작동한 것으로 보인다.

결론적으로,
req의 경우에는 모두 DTO 클래스로 정의를 했기 때문에 readValue 메소드를 이용하여 map 객체로 변환하였고,
res의 경우에는 DTO 클래스 또는 string 객체로 정의 했기 때문에

String(it, StandardCharsets.UTF_8)

을 이용하여 String 객체로 로깅하였다.

그런데 생각해보니.. ES를 이용하여 로깅수집을 하고 있기 때문에 type 검사 후에 string 또는 map 으로 변환하는게 가장 좋을 듯 싶다.
추후에 다시 수정해야겠다.

따라하며 배우는 MySQL on Docker 실습

Sun, 16 May 2021 00:00:00 GMT

# Summary

Docker 환경에서 MySQL Master-Replication 구성
Orchestrator를 이용한 HA 구성
ProxySQL을 이용한 Proxy Layer 구성
Prometheus와 Grafana를 이용한 모니터링 구성
Docker compose를 통한 일괄 서비스 배포
Swarm Mode를 통한 확장 가능한 구성

# Master, Slave Replication 구성

Volume 디렉토리 생성

mkdir -p /db/db001/data /db/db002/data /db/db/003/data \
mkdir -p /db/db001/log /db/db002/log /db/db003/log \
mkdir -p /db/db001/conf /db/db002/conf /db/db003/conf

chmod 777 -R /db

my.cnf 설정

my.cnf 의 permission은 644로 수정

1. db001 설정

master 설정

#my.cnf
[mysqld]
log_bin                     = mysql-bin
binlog_format               = ROW
gtid_mode                   = ON
enforce-gtid-consistency    = true
server-id                   = 100
log_slave_updates
datadir                     = /var/lib/mysql
socket                      = /var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links              = 0

log-error                   = /var/log/mysql/mysqld.log
pid-file                    = /var/run/mysqld/mysqld.pid

report_host                 = db001

[mysqld_safe]
pid-file                    = /var/run/mysqld/mysqld.pid
socket                      = /var/lib/mysql/mysql.sock
nice                        = 0

2. db002 설정

slave 설정, read_only 값 추가
server-id, report_host 유일값으로 수정

#my.cnf
[mysqld]
log_bin                     = mysql-bin
binlog_format               = ROW
gtid_mode                   = ON
enforce-gtid-consistency    = true
server-id                   = 200 
log_slave_updates
datadir                     = /var/lib/mysql
socket                      = /var/lib/mysql/mysql.sock
read_only

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links              = 0

log-error                   = /var/log/mysql/mysqld.log
pid-file                    = /var/run/mysqld/mysqld.pid

report_host                 = db002

[mysqld_safe]
pid-file                    = /var/run/mysqld/mysqld.pid
socket                      = /var/lib/mysql/mysql.sock
nice                        = 0

db003 설정

slave 설정, read_only 값 추가
server-id, report_host 유일값으로 수정

#my.cnf
[mysqld]
log_bin                     = mysql-bin
binlog_format               = ROW
gtid_mode                   = ON
enforce-gtid-consistency    = true
server-id                   = 300
log_slave_updates
datadir                     = /var/lib/mysql
socket                      = /var/lib/mysql/mysql.sock
read_only

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links              = 0

log-error                   = /var/log/mysql/mysqld.log
pid-file                    = /var/run/mysqld/mysqld.pid

report_host                 = db003

[mysqld_safe]
pid-file                    = /var/run/mysqld/mysqld.pid
socket                      = /var/lib/mysql/mysql.sock
nice                        = 0

Container 생성

Bridge Network 구성

container 의 network alias를 사용하기 위해 bridge network를 구성한다.
container가 재시작되어 Ip가 변경되더라도 문제가 발생하지 않는다.

docker network create --driver bridge db-bridge

Master Container 생성

docker run -i -t --name db001 -p 13306:3306 \
--net db-bridge --net-alias=db001 \
-v /db/db001/data:/var/lib/mysql \
-v /db/db001/log:/var/log/mysql \
-v /db/db001/conf:/etc/percona-server.conf.d \
-e MYSQL_ROOT_PASSWORD="root" -d percona:5.7.30

Slave Containers 생성

docker run -i -t --name db002 -p 13307:3306 \
--net db-bridge --net-alias=db001 \
-v /db/db002/data:/var/lib/mysql \
-v /db/db002/log:/var/log/mysql \
-v /db/db002/conf:/etc/percona-server.conf.d \
-e MYSQL_ROOT_PASSWORD="root" -d percona:5.7.30

docker run -i -t --name db003 -p 13308:3306 \
--net db-bridge --net-alias=db001 \
-v /db/db003/data:/var/lib/mysql \
-v /db/db003/log:/var/log/mysql \
-v /db/db003/conf:/etc/percona-server.conf.d \
-e MYSQL_ROOT_PASSWORD="root" -d percona:5.7.30

Container 생성 확인

docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Status}}"

Replication 설정

Replication user 생성(db001)

docker exec -it -uroot db001 bash
mysql -uroot -p

mysql> create user 'repl'@'%' identified by 'repl';
mysql> grant replication slave on *.* to 'repl'@'%';

Replication 설정(db002, db003)

docker exec -it -uroot db002 bash
mysql -uroot -p
mysql> change master to master_host='db001', \
        master_user='repl', master_password='repl', \
        master_auto_position=1;
mysql> start slave;
mysql> show status\G

Orchestrator를 이용한 HA 구성

master 가 장애가 났을 경우, 자동으로 failover가 되도록 구성

Orchestrator Container 실행

docker run -i -t --name orchestroator -h orchestrator \
--net db-bridge --net-alias=orchestrator
-p 13000:3000 -d openarkcode/orchestrator:latest

Orchestrator를 위한 mysql user 생성

orchestroator 를 위한 mysql user를 생성하는데,
db container의 IP대역 확인하여 user의 host로 사용한다.

docker inspect --format '{{.NetworkSettings.Networks.db-bridge.IPAddress}}' db001

172.18.0.2

db001에서 mysql user생성

docker exec -it -uroot db001 /bin/bash
mysql -uroot -p

mysql> create user orc_client_user@'172.%' identified by 'orc_client_password';
mysql> grant super, process, replication slave, reload on *.* to orc_client_user@'172.%';
mysql> grant select on mysql.slave_master_info to orc_client_user@'172.%';

HA 구성

http://{docker_host_ip}:13000/web/clusters 접속
Clusters > Discover 에서 instance 생성

db001, 3306 입력 후 submit

Cluster > Dashboard 에서 확인

Auto FailOver를 위한 Orchestrator의 설정 변경

docker exec -it orchestrator bash
cd vi /etc/orchestrator.conf.json

  "RecoverMasterClusterFilters": [ "*" ],
  ...
  "PromotionIgnoreHostnameFilters": [ "db003" ], //db003 은 승격되지 않는다.

orchestrator 재시작

docker restart orchestrator

ProxySQL을 이용한 Proxy Layer 구성

ProxySQL Container 실행

mkdir -p /db/proxysql/data /db/proxysql/conf
chmod 777 /db/proxysql /db/proxysql/data /db/proxysql/conf

conf 파일 생성

conf 디렉토리에 proxysql.cnf 파일 생성
파일 permission 은 644

#proxysql.cnf

Container 실행

docker run -i -t --name proxysql -h proxysql \
--net db-bridge --net-alias=proxysql \
-p 16032:6032 -p 16033:6033
-v /db/proxysql/data:/var/lib/proxysql \
-v /db/proxysql/conf/proxysql.cnf:/etc/proxysql.cnf \
-d proxysql/proxysql

ProxySQL Admin 접속

mysql -h127.0.0.1 -p16032 -uradmin -pradmin --prompt "ProxySQL Admin>"

테스트 환경 구성

테스트 데이터베이스 생성
어플리케이션에서 사용한 유저 생성
proxysql용 모니터링 user 생성

docker exec -it -uroot db001 bash
mysql -uroot -p

mysql> create database testdb default character set utf8;
mysql> create user appuser@'%' identified by 'appuser';
mysql> grant select, insert, update, delete on testdb.* to appuser@'%';
mysql> create user 'monitor'@'%' identified by 'monitor';
mysql> grant replication client on *.* to 'monitor'@'%';
mysql> flush privileges;

proxysql
- hostgroup에 db서버 정보 입력 — write group : 10, read group : 20
- app user 정보 입력
- 쿼리 룰 정보 입력

mysql -h127.0.0.1 -P16032 -uradmin -pradmin --prompt "ProxySQL Admin>"

ProxySQL Admin> insert into mysql_servers(hostgroup_id, hostname, port) values (10, 'db001', 3306);
ProxySQL Admin> insert into mysql_servers(hostgroup_id, hostname, port) values (20, 'db001', 3306);
ProxySQL Admin> insert into mysql_servers(hostgroup_id, hostname, port) values (20, 'db002', 3306);
ProxySQL Admin> insert into mysql_servers(hostgroup_id, hostname, port) values (20, 'db003', 3306);
ProxySQL Admin> insert into mysql_replication_hostgroups values (10, 20, 'read_only', '');

# app 
ProxySQL Admin> insert into mysql_users(username, password, default_hostgroup, transaction_persistent) values ('appuser', 'apppass', 10, 0)

ProxySQL Admin> insert into mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup) values (1, 1, '^SELECT.*FOR UPDATE$', 10);
ProxySQL Admin> insert into mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup) values (2, 1, '^SELECT', 20);


ProxySQL Admin> load mysql servers to runtime;
ProxySQL Admin> save mysql servers to disk;

[작업로그] Dto to Entity에 대한 고민

Tue, 20 Apr 2021 00:00:00 GMT

요즘 FMS 프로젝트에 대한 리펙터링을 열심히 진행하고 있다.
그 중 가장 초점을 맞추고 있는 작업은 Request/Response 객체로 사용되고 있는 Entity를 Dto로 바꾸는 것이다.
그래서 Dto to Entity, Entity to Dto 의 편리성을 위해 Mapstruct 를 도입하였고, 큰 문제가 없이 수월한 작업을 예상했는데
역시나.. 모든 리펙토링은 많은 고민이 필요하구나를 다시한번 느끼게 된다.

오늘 고민한 내용은 다음과 같다.
연관관계(FK)가 많은 Entity를 생성할때 모든 FK 객체는 어떻게 채울 것인가?
DTO가 가지고 있는 각 매핑 ID로 모두 조회를 해야하나?

일단, 간단하게 프로젝트를 구성하여 테스트를 했다.

생성요청 DTO 클래스에는 customerId (FK) 값이 존재한다.
DTO 클래스 안에 DTO to Entity 메소드가 존재한다.
- Case1) customerId 로 repository에서 select 한 Customer 객체를 추입받는다
- Case2) customerId 필드만 넣어 Customer 객체 생성을 한다.

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class ReservationDto {

    @Getter
    @NoArgsConstructor
    public static class CreateReq {
        private Long customerId;
        private PassengerType passengerType;
        private String usages;
        private String luggage;

        //case1. customer id로 repository에서 select 한 값을 주입 받아 entity 에 주입
        public ReservationPassenger toEntity(Customer customer) {
            ReservationPassenger reservationPassenger = ReservationDtoMapper.INSTANCE.toReservationPassengerEntity(this);
            reservationPassenger.setCustomer(customer);
            return reservationPassenger;
        }

        //Case2. id로 customer id 객체 생성 후 entity 에 주입
        public ReservationPassenger toEntity() {
            Customer customer = new Customer(this.customerId);

            ReservationPassenger reservationPassenger = ReservationDtoMapper.INSTANCE.toReservationPassengerEntity(this);
            reservationPassenger.setCustomer(customer);
            return reservationPassenger;
        }

    }
}

case1. customer id로 repository에서 select 한 값을 주입 받아 entity에 주입

public ReservationPassenger toEntity(Customer customer) {
    ReservationPassenger reservationPassenger = ReservationDtoMapper.INSTANCE.toReservationPassengerEntity(this);
    reservationPassenger.setCustomer(customer);
    return reservationPassenger;
}

// 호출 메소드 로직
public void createReservation(ReservationDto.CreateReq req) {
    // customer id로 select
    Customer customer = customerRepository.findById(req.getCustomerId()).orElseThrow(IllegalArgumentException::new);
    ReservationPassenger reservationPassenger = req.toEntity(customer);
    ReservationPassenger saved = reservationRepository.save(reservationPassenger);
}

그래.. 이게 정석이겠지,
그런데 Entity의 연관관계가 많으면? 저렇게 객체를 가져와서 매핑해야 하나?
실질적으로는 ID만 필요로 할 뿐인데?

case2. customerId 필드만 넣어 Customer 객체 생성을 한 후 entity에 주입

public ReservationPassenger toEntity(Customer customer) {
    Customer customer = new Customer(this.customerId);

    ReservationPassenger reservationPassenger = ReservationDtoMapper.INSTANCE.toReservationPassengerEntity(this);
    reservationPassenger.setCustomer(customer);
    return reservationPassenger;
}

// 호출 메소드 로직
public void createReservation(ReservationDto.CreateReq req) {
    ReservationPassenger reservationPassenger = req.toEntity();
    ReservationPassenger saved = reservationRepository.save(reservationPassenger);
}

헉! DB에는 문제없이 잘 매핑이 된다!
그럼 존재하지 않는 ID를 넣으면 어떻게 되지?

오~ 역시
could not execute statement; SQL [n/a]; constraint 오류가 발생한다.
똑똑하구로..

org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException: 
Referential integrity constraint violation: "FKT1K88T0M3HKQGVYFI365S5KV8: 
PUBLIC.RESERVATION_PASSENGER FOREIGN KEY(CUSTOMER_ID) REFERENCES PUBLIC.CUSTOMER(ID) (2)"; SQL statement:

물론 매핑 ID의 검증을 위해 첫번째 방법이 당연하다는건 알지만,
매핑 ID의 검증이 필요 없는 경우는 두번째 방법을 써도 되지 않을까?

좀 더 나은 방법이 없는지 더 고민 해봐야 겠다.

넷마스크, 서브넷 마스크, 브로드 캐스트

Fri, 19 Mar 2021 00:00:00 GMT

# 넷마스크 (netMask)

네트워크 주소 부분의 비트를 1로 치환한 것이 넷마스크이다.
IP 주소와 넷마스크를 AND연산을 하면 네트워크 주소를 얻을수 있다.

# 서브넷 마스크(subnet mask)

CIDR 이후(현재) subnet mask만 쓰고 있기 때문에 넷마스크와 서브넷마스크를 딱히 구분하진 않는다.
IP주소 뒤에 붙은 /24 같은 것들은 서브넷 마스크의 bit 수를 의미한다.

192.168.0.3/24
IP주소       : 192.168.0.3 
서브넷 마스크 : 255.255.255.0
2진수        : 11111111.11111111.11111111.00000000
256개의 호스트 주소를 사용할 수 있다.

192.168.0.3/25
IP주소       : 192.168.0.3 
서브넷 마스크 : 255.255.255.128
2진수        : 11111111.11111111.11111111.10000000
128개의 호스트 주소를 사용할 수 있다.

192.168.0.3/26
IP주소       : 192.168.0.3 
서브넷 마스크 : 255.255.255.192
2진수        : 11111111.11111111.11111111.11000000
64개의 호스트 주소를 사용할 수 있다.

192.168.0.3/23
IP주소       : 192.168.0.3 
서브넷 마스크 : 255.255.254.0
2진수        : 11111111.11111111.11111110.00000000
512개의 호스트 주소를 사용할 수 있다.

# 브로드 캐스트(broad cast)

특정 네트워크에 속하는 모든 호스트들이 갖게 되는 주소.
네트워크에 있는 클라이언트 모두에게 데이터를 보내기 위함.
해당 네트워크에 속하는 모든 IP 주소 가운데 맨 마지막 IP주소
계산방법 : 서브넷 마스크의 ‘0’인 부분을 모두 1로 바꾼다.

[작업로그] MHA Failover, RollChange 테스트

Wed, 03 Mar 2021 00:00:00 GMT

MySQL MHA 테스트에 대한 작업 로그를 기록한다.

시나리오

Failover
Failback
Roll Change
MHA Manager 기동

■ 1. Failover

#1번서버
- Ifconfig로 VIP up 확인 (master 확인)
- MySQL 종료
```
$ /usr/local/mysql/bin/mysqladmin -uroot -p shutdown
```
- Ifconfig 로 VIP down 확인
#2번 서버
- VIP up 확인
- MySQL Slave 상태 확인, empty 이면 정상적으로 failover 완료
```
mysql> show slave status;
```

■ 2. Failback

수동작업 진행

#2번 서버

Data Dump

$ mysqldump -u root -p --all-database > dump.sql

Master Status 확인
```
mysql> show master status;
```

#1번 서버

MySQL 기동

$ /usr/local/mysql/bin/mysqld_safe --user=mysql &

dump import
```
$ mysql -u root -p < dump.sql
```

Slave 등록

// 해당 쿼리문은 MHA.log에 기록되어 있음
mysql> change master to master_host=[#2번서버 HOST], master_port=[PORT], 
master_user=[replication db user], master_password=[replication user password],
master_log_file=[#2번 서버의 master log file], master_log_pos=[#2번 서버의 master log pos];

Slave 시작 및 확인

mysql> start slave;
mysql> show slave status;

이중화 되었는지 데이터 확인

■ 3. Roll Change

#2번 서버
- Failover가 실행되면 MHA manager는 자동 종료되며, masterha_default.failover.complete 파일이 생성됨.
- Roll 변경 전 해당 파일 삭제 필요
- masterha_master_switch 실행
```
masterha_master_switch --master_state=alive --conf=/etc/mha.cnf --orig_master_is_new_slave --interactive=0
```
- VIP down 확인
- slave 상태 확인
```
mysql> show slave status;
```
#1번 서버
- VIP up 확인
- master 및 slave 상태 확인

■ 4. MHA Manager 기동

#2번 서버

MHA Manager 현재 상태 확인

$ /usr/bin/masterha_check_status --conf=/etc/mha.conf

MHA Manager 기동

$ nohup /usr/bin/masterha_manager --conf=/etc/mha.cnf &

[작업로그] WCA, WVA 서비스 설치 스크립트 만들기

Mon, 22 Feb 2021 00:00:00 GMT

이번에 다른 부서에서 사온 제품 2개에 대한 설치 매뉴얼 검토중에 작업 단순화가 필요하다고 느꼈다.
이에 불필요한 작업 제거 및 설치 단순화를 하여 설치 스크립트를 생성하는 목적으로 이 작업을 진행하여 되었다.
이 작업을 진행하면서 배운 내용이나 기록이 필요한 내용을 정리한다.

■ 1. 수작업 최소화 1.1. Cloud, On-Premise 둘다 OS는 데비안 계열을 사용

Ubuntu 18.04 에서 진행

1.2. 두 제품에 대한 리펙토링을 진행하기 전까지 JAVA8, Tomcat8 사용 tomcat major 버전이 fix 이므로 8버전의 latest 파일을 받아 아래 파일들을 수정한다.

1.2.1. context.xml
— datasource 설정
1.2.2. server.xml
— 최대 2개의 WAS 서비스를 사용하므로 port 를 동적으로 설정

1.2.3. catalina.sh
— java system properties 설정
— http 포트가 8080 일 경우,
— 8005 -> ${port.shutdown}
— 8009 -> ${port.ajp}
— 8443 -> ${port.https} 가 된다.

■ 2. Service 등록 2.1. 서비스파일 생성

[Unit]
Description=WCA WAS
Requires=mysqld.service
After=network.target mysqld.service

[Service]
Type=forking
Environment=WCA_LIB=/opt/penta/wca-libs
Environment=SERVICE_PORT=8080
Environment=CATALINA_HOME=/opt/tomcat-wca
Environment=JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
Environment=LD_LIBRARY_PATH=/opt/penta/wca-libs:$LD_LIBRARY_PATH

User=autocrypt
Group=autocrypt

ExecStart=/opt/tomcat-wca/bin/startup.sh
ExecStop=/opt/tomcat-wca/bin/shutdown.sh

Restart=always

[Install]
WantedBy=multi-user.target

Requires vs After
— https://stackoverflow.com/questions/40593242/systemd-using-both-after-and-requires
Environment
— User를 설정하더라도 bash_profile이나 기타 쉘/유저 기반의 환경 변수는 먹지 않는다.
— 따라서 해당 프로퍼티를 사용하여 환경 변수를 설정한다.
Restart
— 해당 서비스가 강제 종료되었을 경우 재시작에 대한 정책이다.
— systemctl 로 종료했을 경우는 작동하지 않는다.
WantedBy
— [install] 은 “systemctl enable [service name]” 으로 서비스 등록 시 이용하는 섹션이다.
— WantedBy 는 이 서비스가 어떤 전제조건 하에서 실행되는 지를 결정한다.
— multi-user.target 은 runlevel 3 환경이 모두 구동되었을 때를 의미한다.
— run leval (리눅스시스템의 실행레벨)
▶ init 0 : halt, 시스템 종료
▶ init 1 : Single user mode, 관리 모드로 root 계정만 사용 가능
▶ init 2 : Multiuser, without NFS (The same as 3, if you do not have networking)
▶ init 3 : Full multiuser mode, default level
▶ init 4 : unused, 사용하지 않는 실행레벨, 커스텀레벨로 사용 가능
▶ init 5 : X11, X윈도우 환경으로 실행된 멀티유저 실행모드
▶ init 6 : reboot

2.2. 기타 설정 및 서비스 활성화 스크립트 생성

각 Step 별로 블럭지어 실패 시 메시지 출력 및 종료하도록 구성

서비스 활성화 Step
— service 파일 활성화 명령어 : $ systemctl enable {service 파일명}
— daemon reload 명령어 : $ systemctl daemon-reload

스크립트 생성하면서 리눅스 파일 시스템 계층 구조에 맞게 설정 등의 디렉토리를 구성하였다.
▶ 리눅스 파일 시스템 계층구조 표준 위키피디아

github

https://github.com/eunyoung-autocrypt/bash-scripts

linux 다중명령어 차이점 (&& || ; |)

Fri, 19 Feb 2021 00:00:00 GMT

■ Double Ampersand (&&)

첫번째 명령이 정상 종료 했을 경우 두번째 명령 수행

■ Double Vertical Bar (||)

첫번째 명령이 에러 일 경우 두번째 명령어 수행

■ Pipe (|)

첫번째 명령어 결과를 사용하여 두번째 명령어 수행

■ Semicolon (;)

한 라인에서 여러 명령어를 수행할때 사용
순차적으로 수행하며, 오류가 발생하더라도 다음 명령어는 계속 수행된다.

[Linux] sed 명령어 정리

Thu, 18 Feb 2021 00:00:00 GMT

sed ?

문자열 변환 편집기
원본은 변경없이, 변경된 결과를 출력
i 옵션으로 변경된 결과를 원본파일에 덮어쓸 수 있다.
e 옵션으로 정규식 사용이 가능하다.

치환(substitute)

# AAA를 BBB로 변환. 단, 원본파일을 바꾸지 않고 표준출력만 한다.
$ sed 's/AAA/BBB/' list.txt

# 탭문자를 엔터로 변환
$ sed 's/\t/\ /' list.txt

삭제(delete)

# AAA 문자가 포함된 줄을 삭제하여 출력
$ sed '/AAA/d' list.txt

# AAA 문자가 있는 줄만 지우지 않는다.
$ sed '/AAA/!d' list.txt 

# num 1,2 라인 삭제 
$ sed '1,2d' list.txt

# 공백라인 삭제
$ sed '/^$/d list.txt

init vs systemd

Wed, 10 Feb 2021 00:00:00 GMT

이번에 서비스 등록할때 “/etc/init.d, /usr/lib/systemd/system 디렉토리 밑에 모두 서비스 스크립트를 생성해야하나?” 라는 의문점이 생겨 두개의 차이를 찾아보게 되었다.
결론은 systemd 로만 등록하였다.

#. systemd?

위키피디아 https://ko.wikipedia.org/wiki/Systemd

#. init?

위키피디아 https://ko.wikipedia.org/wiki/Init

#. 차이점

왜 init이 systemd로 바뀌어야 하는가
init의 한계를 극복하기 위해 만들어진 새로운 시스템 관리 아키텍처로 systemd 가 나옴
To start less
— init : boot 시 많은 서비스를 실행
— systemd : boot 시 필요한 최소한의 서비스를 실행, 필요시 서비스 실행

And to start more in parallel
— init : 1 부터 5의 처리를 순서대로 진행
— systemd : 각 처리에는 의존관계가 정의되어 있고, 병렬로 실행하여 시간 단축

#. 명령어 비교

자동시작 등록/해제

# init
$ chkconfig [service명] on|off

# systemd
$ systemctl enable|disable [service명]

유효/무효 확인

# init
$ chkconfig [service명] --list

# systemd
$ systemctl is-enabled [service명]

실행/종료/상태확인

# init
$ /etc/init.d/[service명] start/stop/status

# systemd
$ systemctl start|stop|status [service명]

강제종료

# init
$ /etc/init.d/[service명] status (pid 확인 후)
$ kill [PID]

# systemd
$ systemctl kill [service명]

#. 기타 systemd 명령어

# 유효화 되어 있는 Unit 표시
$ systemctl list-units

# 설치되어 있는 Unit 표시
#   enable : 자동 시작 설정 활성화
#   disable : 자동 시작 설정 비활성화
#   static : 단독으로 자동 기동 할 수 없음
$ systemctl list-unit-files

@Value 사용 시, required a bean of type 'java.lang.Boolean' that could not be found. @value

Wed, 10 Feb 2021 00:00:00 GMT

무엇이 문제였나?

@Value 어노테이션을 이용하여 application.properties 변수 접근 시 아래와 같은 오류 발생
소스코드

에러 발생

원인이 뭔데?

의존성 주입 방식 중 필드 주입 방식(@Autowired 사용) 은 권장하지 않는 패턴이기 때문에 @RequiredArgsConstructor 를 사용하여 생성자 주입방식을 사용했었다.
final 이 붙었기 때문에 자동으로 생성자 생성시 필요 필드가 되어버렸다.
해당 변수는 스프링에서 관리하는 Bean이 아니기 때문에 의존성 자동 주입이 될 수 없다.

이렇게 해결했다!

final 제거
immutable 한 변수가 아닌데… 다른 방법도 찾아서 정리해 놔야곘네…

[작업로그] Mysql Index 미생성 이슈

Thu, 04 Feb 2021 00:00:00 GMT

현재 프로젝트중인 사이트에서 에이징 테스트 중에 DB 서버 CPU 사용량이 점차 증가하여 사용율이 90%까지 올라가는 현상이 발생했다.
결론적으로는 index를 생성하지 않아 select가 많은 특정 테이블에서 약 50만건 데이터를 계속해서 full scan 하여 해당 현상이 발생되었다.

#. 이를 위해 무엇을 확인했나?

#1. slow query 확인

1초 이상 수행되는 쿼리 검출

select *
from leaf_cert 
where actor='MO' and cn='KREVPABCDEF0052' and valid=1 and last_issued=1; 

select *
from leaf_cert leafcert0_ 
where actor='CPS' and valid=1 and last_issued=1;

#2. 조건절로 사용되는 컬럼의 cardinality 와 선택률

위의 쿼리문 확인 결과, leaf_cert 테이블에서는
cn 컬럼은 cardinality 가 높다
— 1년마다 인증서 갱신이 되면 동일 cn의 row 가 발생, 인증서 폐지 시 동일 cn으로 row가 발생할수 있다.
last_issued 컬럼은 cardinality가 낮지만 선택률이 낮다.
— 값은 true 또는 false 이다.
— 한개의 row만 true 이다.
actor가 CPS 일 경우 선택률이 낮다.

- cardinality  
    -- 값의 균형을 나타냄  
    -- 모든 레코드에 다른 값이 들어있으면 cadinality 가 높다.  
    -- 높을 수록, 즉 값이 평균치에서 많이 흩어져 있을수록 좋은 인덱스 후보이다.  

- 선택률  
    -- 테이블 전체에서 몇 개의 레코드가 선택되는지를 나타냄  
    -- 선택률이 낮을 수록, 즉 한 번의 선택으로 레코드가 조금만 선택되는 것이 좋은 후보이다.

#.인덱스 생성

create index idx__cn on leaf_cert(cn);
create index idx__last_issued on leaf_cert(last_issued);
create index idx__vaild on leaf_cert(valid);

#.근데?

확인해보니 에이징 테스트 셋이 잘못됐었다..
운영시 실제로는 cn 컬럼의 데이터가 중복 발생 할 경우가 낮아 cn의 cadinality는 높아야 하는데…
테스트 셋을 300개만 생성하여 테스트를 하니 동일 cn으로 생성/폐지가 계속 발생하게 되었다.

폐지가 계속 발생되는 테스트이다보니… cn은 cardinality 가 낮아지고, 폐지 여부 컬럼인 valid 가 선택률이 낮게 되었다. 어쩔 수 없이 valid 컬럼에 인덱스를 추가 생성했다.

create index idx__valid on leaf_cert(valid);

테스트 결과

결론적으로 CPU 사용량 및 응답속도에서 약 65~75% 의 개선 효과가 관찰됨.
인덱스 작업 전 CPU 사용량
인덱스 작업 전 응답시간

인덱스 작업 후 CPU 사용량
인덱스 작업 후 응답시간

느낀점

이번 프로젝트를 진행하면서 많은 경험을 하는것 같다.
실 운영 상황에 맞게 테스트 셋을 만들었어야 했고, 미리 index 작업을 했었어야 했다.
놓쳤던 부분이 많았다.

특히 인덱스 부분에서는 50만개 full scan 정도야 했는데… 이로인해 응답속도지연과 cpu 사용률이 문제가 되다니…
DB를 너무 신뢰했던거 같다. 반성한다.

엔티티 매핑

Thu, 28 Jan 2021 00:00:00 GMT

@Entity

JPA는 내부적으로 replication 등을 쓰기 때문에 동적으로 생성할 수 있어야 한다.
따라서 기본 생성자가 필요하다. (public 또는 protected)

데이터베이스 스키마 자동 생성

DDL을 애플리케이션 실행 시점에 자동 생성
데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
운영 장비에는 절대 create, create-drop, update 사용하면 안됨.
스테이징과 운영 서버는 validate 또는 none 사용
```
hibernate.hbm2ddl.auto=create
```

매핑 어노테이션 정리

Date 클래스 사용시 만 @Temporal 사용,
LocalData, LocalDateTime을 사용할때는 생략
@Transient 는 주로 메모리상에서만 임시로 보관하고 싶을 때 사용

기본 키 매핑 기본 키 매핑 어노테이션

@Id
@GeneratedValue (전략은 AUTO가 기본)

전략 종류

IDENTITY : 데이터베이스에 위임, MYSQL
SEQUENCE : 데이터베이스 시퀀스 오브젝트 사용, ORACLE
— @SequenceGenerator 필요
TABLE : 키 생성용 테이블 사용, 모든 DB에서 사용, 잘 사용하지 않음
— @TableGenerator 필요
AUTO : 방언에 따라 자동 지정, 기본 값

IDENTITY 전략 특징

주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (auto_increment)

SEQUENCE 전략 특징

주로 Oracle, PostgreSQL, DB2, H2 에서 사용 (auto_increment)
INSERT SQL 실행 후에 id 값을 알 수 있으므로 해당 전략에서는 persist(add) 시점에 즉시 SQL이 수행

연관관계 매핑 1) 단방향 연관관계

Member 와 Team 의 관계는 n:1
Member(n)에 Team(1)에 대한 FK가 들어간다.

2) 양방향 연관관계와 연관관계의 주인

연관관계의 주인은 외래키의 위치를 기준으로 정해야함
주인이 아닌쪽은 읽기 전용
주인이 아니면 mappedBy 속성으로 주인 지정
여기서는 Member.team 이 연관관계의 주인이 된다.

2) 양방향 연관관계 주의

순수 객체 상태를 고려해야 상항 양쪽에 값을 설정
연관관계 편의 메소드를 생성하자

@OneToMany(mappedBy = "member")
private List<Member> memberList = new ArrayList<>();

public void addMember(Member member) {
    // 양반향 연관관계 매핑
    this.memberList.add(member);
    member.updateTeam(this);
}

양방향 매핑시에 무한 루프를 조심하자
— ex) toString(), lombok, JSON 생성 라이브러리

영속성 관리 - 내부 동작 방식

Mon, 25 Jan 2021 00:00:00 GMT

#JPA에서 가장 중요한 2가지

객체와 관계형 데이터베이스 매핑
영속 컨텍스트 (매커니즘)

#Entity Manager Factory 와 Entity Manager

Factory에서 Entity Manager 생성
Manager에서 DB Connection을 사용

# 영속성 컨텍스트

엔티티를 영구저장하는 환경이라는 뜻
논리적인 개념
엔티티 매니저를 통해 영속성 컨텍스트에 접근

# 엔티티의 생명주기

비영속 (new/transient) — 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
영속 (managed) — 영속성 컨텍스트에 관리되는 상태
준영속 (detached) — 영속성 컨텍스트에 저장되었다가 분리된 상태
삭제 (removed) — 삭제된 상태

// 비영속
Member member = new Member();
member.setId(100L);
member.setUserName("member1");

//영속
entityManager.persist(member);

//회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
entityManager.detach(member);

//객체를 삭제한 상태(DB에서 삭제)
entityManager.remove(member);

# 영속성 컨텍스트의 이점 1) 1차 캐시

1차 캐시는 한 트랜젝션에서만 허용된다.
성능보다는 매커니즘에 이점에 있다.
1차 캐시에서 조회
데이터베이스에서 조회

2) 동일성 보장

Member a = entityManager.find(Member.class, "member1");
Member b = entityManager.find(Member.class, "member1");

System.out.println(a == b); // 동일성 비교 true

3) 트랜잭션을 지원하는 쓰기 지연 (transactional write-behind)

EntityManager entityManager = entityManagerFactory.createEntityManager();
EntityTransaction transaction = entityManager.getTransaction();

//엔티티 매니저는 데이터 변경 시 트랜잭션을 시작해야 한다.
transaction.begin();

entityManager.persist(memberA);
entityManager.persist(memberB);
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.

//커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit();

entityManager.persist(memberA/B);
transaction.commit();

4) 변경 감지 (Dirty Checking)

EntityManager entityManager = entityManagerFactory.createEntityManager();
EntityTransaction transaction = entityManager.getTransaction();

//영속 엔티티 조회
Member memberA = entityManager.find(Member.class, "memberA");

//영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);

//커밋하는 순간 데이터베이스에 UPDATE SQL을 보낸다.
transaction.commit();

5) 지연 로딩 (Lazy Loading)

추후 뒤에서 다시 정리

# 플러시

영속성 컨텍스트의 변경 내용을 데이터베이스에 반영
플러시가 발생되면 1차 캐시에 있는 정보가 사라지는게 아니라 쓰기 지연 SQL 저장소에 있는 SQL이 실행된다.
JPQL을 사용하면 자동으로 flush가 날라가고 해당 쿼리가 실행된다.
트랜잭션이라는 작업 단위가 중요! (커밋 직전에만 동기화 하면 된다.)

Git Repository 이동

Sat, 23 Jan 2021 00:00:00 GMT

생각보다 레파지토리 이동 작업을 많이한다..
commit 등의 이력까지 같이 이동하는 방법이다.

git clone --mirror [기존 리파지토리 주소]

cd [기존 리파지토리 명].git

git remote set-url --push origin [신규 리파지토리 주소]

git push --mirror

[작업로그] CI/CD 구축 #5

Sat, 23 Jan 2021 00:00:00 GMT

Sonarqube ?

20개 이상의 프로그래밍 언어에서 버그, 코드 스멜, 보안 취약점을 발견할 목적으로 정적 코드 분석으로 자동 리뷰를 수행하기 위한 지속적인 코드 품질 검사용 오픈 소스 플랫폼
중복 코드, 코딩 표준, 유닛 테스트, 코드 커버리지, 코드 복잡도, 주석, 버그 및 보안 취약점의 보고서를 제공.
sonar scanner에게 정적 분석 관련 데이터 제공

정적분석을 위한 Sonarqube 설치

https://hub.docker.com/_/sonarqube/

1. host 설정

sonarqube 내부에 Elasticsearch 를 사용하고 있기 때문에 필요 설정이 있다

# max_map_count ?
This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap and mprotect, and also when loading shared libraries.
While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation.
The default value is 65536.

2. DB 및 Volumes 설정 내용

3. Compose 파일 작성

sonarqube develop edition 버전 설치 (trial 라이센스 문의 함)
embedded db : postgres 사용

version: "3.7"
services:
  db:
    image: postgres
    container_name: sonar-postgres
    restart: always
    environment:
      POSTGRES_USER: sonar
      PASTGRES_PASSWORD: sonar
      TZ: Asia/Seoul
      POSTGRES_HOST_AUTH_METHOD: trust
    volumes:
      - ~/docker-volumes/sonar-postgres/postgres:/var/lib/postgresql/data
  
  sonarqube:
    image: sonarqube:8.6.1-developer
    container_name: sonarqube
    restart: always
    environment:
      SONARQUBE_HOME: ./
      SONARQUBE_JDBC_USERNAME: sonar
      SONARQUBE_JDBC_PASSWORD: sonar
      SONARQUBE_JDBC_URL: jdbc:postgresql://db:5432/sonar
    depends_on:
      - db
    ports:
      - 10002:9000
    volumes:
      - ~/docker-volumes/sonar-postgres/sonarqube/data:/opt/sonarqube/data
      - ~/docker-volumes/sonar-postgres/sonarqube/extensions:/opt/sonarqube/extensions
      - ~/docker-volumes/sonar-postgres/sonarqube/logs:/opt/sonarqube/logs
      - ~/docker-volumes/sonar-postgres/temp:/opt/sonarqube/temp

4. 서비스 기동

$ docker-compose -f sonarqube-compose.yml up -d

정적분석을 위한 Sonarqube 프로젝트 생성 및

1. Sonarqube 프로젝트 생성

10002 포트로 접속 후 로그인 & 프로젝트 생성
프로젝트 토큰 생성
을 하면 아래와 같이 sonar scanner 를 사용하기 위한 설정 방법이 나온다.

2. Scanner 설정 및 실행

build.gradle에 plugin 추가 후

plugins {
  id "org.sonarqube" version "3.0"
}

scanner 를 실행하면

./gradlew sonarqube \
  -Dsonar.projectKey=Test-Proj \
  -Dsonar.host.url=http://HOST:10002 \
  -Dsonar.login=***********************

정적분석 결과가 표시된다.

Pipeline 작성 1. Test Stage

테스트 코드를 수행한다.
테스트 실패 시 테스트 결과 게시 및 PR comment & decline api 전송 후 파이프라인을 종료한다.

stage ('Test') {
    sh '''
    {
        ./gradlew test \
        && curl -X POST -u "$USER" $COMMENT_URL -d '{"content": {"raw": "[TEST] SUCCESS"}}' -H 'Content-Type: application/json' > /dev/null 2>&1 \
        && echo [TEST] SUCCESS;
    }||\
    {
        ssh -ir ~/.ssh/v2g_srv $V2G_DEV_SERVER bash -c "'mkdir -p /docker-volumes/nginx/html/failed-test/$SOURCE_BRANCH'";
        scp -ir ~/.ssh/v2g_srv ./build/reports/tests/test $V2G_DEV_SERVER:/docker-volumes/nginx/html/failed-test/$SOURCE_BRANCH;
        curl -X POST -u "$USER" $COMMENT_URL -d '{"content": {"raw": "[TEST] FAIL"}}' -H 'Content-Type: application/json' > /dev/null 2>&1;
        curl -X POST -u "$USER" $DECLINE_URL -d '{"content": {"raw": "[TEST] FAIL"}}' -H 'Content-Type: application/json' > /dev/null 2>&1;
        echo [TEST] FAIL;
        exit 1;
    }
    '''
}

2. Jacoco & SonarQube Analysis & Quality Gate

테스트 성공 시 coverage 측정 및 정적분석 진행 후 Quality Gate 결과 확인
Qulicy Gate 실패 시 PR comment & decline api 전송 후 파이프라인을 종료한다.

stage ('Jacoco & SonarQube Analysis & Quality Gate') {
    withSonarQubeEnv('sonarqube') {
        sh "./gradlew jacocoTestReport sonarqube"
    }
    
    def qg = waitForQualityGate()
    if (qg.status != 'OK') {
        sh '''
            curl -X POST -u "$USER" $COMMENT_URL -d '{"content": {"raw": "[QualityGate] FAIL"}}' -H 'Content-Type: application/json' > /dev/null 2>&1;
            curl -X POST -u "$USER" $DECLINE_URL -d '{"content": {"raw": "[QualityGate] FAIL"}}' -H 'Content-Type: application/json' > /dev/null 2>&1;
            echo [TEST] FAIL;
            exit 1;
        '''
    } else {
        sh '''
            curl -X POST -u "$USER" $COMMENT_URL -d '{"content": {"raw": "[QualityGate] SUCCESS"}}' -H 'Content-Type: application/json' > /dev/null 2>&1;
        '''
    }
}

3. Approve PullRequest

해당 PR에 대한 승인 API 전송 후 파이프라인 종료

stage ('Approve PR') {
    timeout(time: 1, unit: 'MINUTES') {
        sh '''
            curl -X POST -u "$USER" $APPROVE_URL;
            echo Approve PullRequest;
        '''
    }
}

> [작업로그] CI/CD 구축 #1 - CI/CD 시나리오
> [작업로그] CI/CD 구축 #2 - Docker, Docker Compose 설치
> [작업로그] CI/CD 구축 #3 - BitBucket 설정 및 Jenkins 설치
> [작업로그] CI/CD 구축 #4 - Jenkins Item 등록 및 Pipeline 작성

JPA 왜 쓰는가?

Sat, 23 Jan 2021 00:00:00 GMT

# SQL 중심적인 개발의 문제점

SQL 중심적인 개발을 진행해오고 있다.
객체를 DB에 넣기 위해 SQL 의존적인 개 발을 할 수 밖에 없다.
CRUD SQL 개발에 대해 무한반복 작업을 한다.

패러다임 불일치 객채와 관계형 데이터베이스의 차이

1. 상속
1. 연관관계
1. 데이터 타입
1. 데이터 식별 방법

객체 모델링 Album 저장 방법

1. 객체분해
1. 각 객체 저장
  2.1) insert into item…
  2.2) insert into album..

Album 조회 방법

1. 각각의 테이블에 따른 Join SQL 작성
1. 각각 객체 생성 및 매핑
1. …복잡

그래서 DB에 저장할 객체에는 상속 관계를 안쓴다. 객체답게 모델링을 할수록 매핑만 늘어난다.

자바 컬렉션에 저장/조회 하면?

list.add(album);
Album album = list.get(albumId);
Item item = list.get(albumId);

정리 계속…

SSH Key

Fri, 22 Jan 2021 00:00:00 GMT

#. SSH Key란?

서버에 접속 할 때 비밀번호 대신 key를 제출하는 방식이다.

#. 동작 방법

클라이언트가 서버에 SSH 연결을 요청한다.
서버는 랜덤 챌린지(랜덤 데이터 스트링)를 생성해 클라이언트에게 보낸다.
클라이언트는 서버로 부터 받은 챌린지(C)를 자신이 가지고 있는 private 키로 암호화해서 암호화 된 메시지를 서버로 보낸다.
서버는 클라이언트에서 받은 암호화 된 메시지를 public 키로 해석한 후 그 결과를 2단계에서 자신이 클라이언트에게 보낸 랜덤 챌린지와 일치하는지 확인한다. (public 키로 해석할 수 있는 메시지는 그 쌍이 되는 private 키를 가진 사람만이 만들 수 있기 때문) 일치하면 클라이언트가 인증된 것이다.

#. 패스워드 없이 ssh 연결

#1. key pair 생성 [Client Side]

default 로 생성 시 ~/.ssh/idrsa , ~/.ssh/idrsa.pub 로 생성됨

$ ssh-keygen

파일 설명

파일명	설명
id_rsa	private key, 서버에 패스워드 없이 접속할때 해당 key를 사용한다
id_rsa.pub	public key, 접속하려는 서버의 authorized_key 에 등록하면 된다

#2. 접속하려는 서버에 public key 등록 [Server Side]

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

#3. 접속확인 [Client Side]

$ scp -i ~/.ssh/id_rsa [타겟파일] [서버계정]@[서버HOST]:~/

#ps. 관련 디렉토리, 파일 퍼미션

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub  
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts

[작업로그] CI/CD 구축 #4

Thu, 21 Jan 2021 00:00:00 GMT

1. Jenkins Item 생성 (Pull Request)

pipeline 선택

Build Trigger에서 generic Webhook Trigger를 선택한다.

2. webhook token 설정

BitBucket 에서 설정했던 token 값을 넣는다.

3. Parameters 정의

request payload 에서 사용할 값들을 정의한다.
bitbucket webhook 에 대한 각 이벤트 request payload는 여기 에서 볼 수 있다. 근데.. 난 보기 불편하다.

3.1. parameter catch 방법 선택

아래와 같이 paramters를 캐치할 수 있는 폼이 있는데, 해당 hook은 POST method 형식이므로 맨 첫번째를 선택한다.

3.2. 사용할 변수들을 정의한다.

Variable : 변수로 사용할 이름
Expression : payload에서 사용 할 값
JSONPath : payload가 json으로 들어오므로 해당 값을 선택한다.

3.3. 정의한 변수들

1. SOURCE_BRANCH  
  -- PR 타켓 branch  
  -- expression: $.pullrequest.source.branch.name

2. COMMENT_URL
  -- pipeline에서 정의한 stage 수행 시 comment 기록를 위한 url  
  -- expression: $.pullrequest.links.comments.href

3. DECLINE_URL
  -- pipeline에서 정의한 stage 실패 시 PR decline을 위한 url  
  -- expression: $.pullrequest.links.decline.href

4. REPO_URL
  -- git repository url 
  -- expression: $.pullrequest.destination.repository.links.html.href

4. Pipeline 작성

맨 아래 pipeline을 작성하는 폼이 있다.

아래와 같이 작성한다.
예제는 Develop Branch PR 로 한다.
그 외 3개 시나리오에 대해선 github에 정리하자.

node {
    withCredentials([usernameColonPassword(credentialsId: 'bitbucket-auth-id-pw', variable: 'USER')]) {
        stage ('Clone') { //clone 타켓 branch  
            try {
                git branch: '$SOURCE_BRANCH', credentialsId: 'bitbucket-auth-id-pw', url: '$REPO_URL'
            } catch(e) {
                sh '''
                    curl -X POST -u "$USER" $COMMENT_URL -d '{"content": {"raw": "[CLONE] FAIL"}}' -H 'Content-Type: application/json';
                    curl -X POST -u "$USER" $DECLINE_URL -d '{"content": {"raw": "[CLONE] FAIL"}}' -H 'Content-Type: application/json';
                    echo [CLONE] FAIL;
                    exit 1;
                '''
            }
        }
        
        stage ('Build') { //테스트 없이 소스코드 빌드 ( 컴파일 오류 체크 ), 실패 시 해당 PR comment 등록 및 decline
            sh '''
            {
                echo [BUILD - BACKEND]
                chmod +x ./gradlew
                ./gradlew clean build -x test \
                && curl -X POST -u "$USER" $COMMENT_URL -d '{"content": {"raw": "[BUILD] SUCCESS"}}' -H 'Content-Type: application/json' > /dev/null 2>&1 \
                && echo [BUILD] SUCCESS;
            }||\
            {
                curl -X POST -u "$USER" $COMMENT_URL -d '{"content": {"raw": "[BUILD] FAIL"}}' -H 'Content-Type: application/json';
                curl -X POST -u "$USER" $DECLINE_URL -d '{"content": {"raw": "[BUILD] FAIL"}}' -H 'Content-Type: application/json';
                echo [BUILD] FAIL;
                exit 1;
            }
            '''
        }
    }
}

> [작업로그] CI/CD 구축 #1 - CI/CD 시나리오
> [작업로그] CI/CD 구축 #2 - Docker, Docker Compose 설치
> [작업로그] CI/CD 구축 #3 - BitBucket 설정 및 Jenkins 설치

> [작업로그] CI/CD 구축 #5 - sonarqube 설치 및 pipeline 작성

Junit Test Reports

Wed, 20 Jan 2021 00:00:00 GMT

Junit 테스트를 진행하다가 Failure 케이스가 존재하는 경우 아래와 같은 로그를 보게 되었다.

해당 경로의 index.html 을 열어보니 아래와 같이 테스트에 대한 결과를 화면으로 출력해주고 있었다.

#. Test Summary

#. 실패된 테스트 로그

#. 테스트 클래스 별 정의된 테스트 메소드 및 성공/실패 여부

#. 모든 테스트 성공 시

이번 CI/CD 구축에서 테스트 실패시 해당 html를 제공하도록 해도 괜찮을꺼 같다.

ps. junit test reports 경로 수정 방법

build.gradle 의 test 블록에 reports destination 지정

Jacoco

Wed, 20 Jan 2021 00:00:00 GMT

#. Jacoco ?

수행되는 테스트가 작성된 코드를 얼마나 커버하는지를 체크해주는 라이브러리이다.
테스트코드를 돌리고 그 커버리지 결과를 눈으로 보기 좋도록 html이나 xml, csv 같은 리포트로 생성한다.
테스트 결과가 내가 설정한 커버리지 기준을 만족하는지 확인하는 기능도 있다.

#. Jacoco 적용

#. jacoco plugin 추가

plugins 블록에 id ‘jacoco’ 를 추가하면

jacocoTestReport 와 jacocoTestCoverageVerification task가 gradle verification 항목에 추가된다.
주의 해야 할 점은 생성된 두 개의 task는 test 가 먼저 실행된 다음에 실행이 되어야 한다.

#. jacoco version

toolVersion 을 다음과 같이 명시한다
버전 정보는 여기 에서 확인한다.

#. jacocoTestReports 설정

jacocoReport task는 html, csv, xml 형태로 커버리지 측정 결과를 알려주는 역할을 한다.
report 포맷 및 경로를 지정한다.

#. jacocoTestCoverageVerification

커버리지 검증 수준을 정의.
이 부분에서 jacoco의 report 검사하여 설정한 최소 수준을 달성하지 못하면 task는 실패를 한다.
여러 수준의 정의를 violationRules 에서 다수의 rule 에 정의하여 사용할 수 있다.

jacocoTestCoverageVerification {
  violationRules {
    rule {
      //해당 rule의 활성화 여부를 boolean으로 나타낸다
      //default는 true
      enabled = true
        
      // 측정의 큰 단위
      element = 'CLASS'

      // rule 적용 대상을 package 수준으로 정의
      // 아무런 설정을 하지 않는다면 전체 적용
      //includes = []
        
      // rule의 상세 설정을 나타내는 block
      limit {

        // 커버리지 측정의 최소 단위
        // 이 때 측정은 java byte code가 실행된 것을 기준으로 counting 된다
        // counter 종류 
        //  - CLASS : 클래스 내부 메소드가 한번이라도 실행된다면 실행된 것으로 간주
        //  - METHOD : 클래스와 마찬가지로 METHOD가 한번이라도 실행되면 실행된 것으로 간주
        //  - LINE : 한 라인이라도 실행되었다면 측정, 소스 코드 포맷에 영향을 받는 측정방식
        //  - BRANCH : if, switch 구문에 대한 커버리지 측정
        //  - INSTRUCTION : jacoco의 가장 작은 측정 방식(바이트 코드), LINE과 다르게 소스 코드 포맷에 영향을 받지 않는다.
        counter = 'LINE'

        // 측정한 counter의 정보를 어떠한 방식으로 보여줄지 정한다
        // value 종료
        //  - TOTALCOUNT: 전체 개수
        //  - MISSEDCOUNT: 커버되지 않은 개수
        //  - COVEREDCOUNT: 커버된 개수
        //  - MISSEDRATIO: 커버되지 않은 비율. 0부터 1 사이의 숫자로, 1이 100%
        //  - COVEREDRATIO (default): 커버된 비율. 0부터 1 사이의 숫자로, 1이 100%
        value = 'COVEREDRATIO'

        // count값을 value에 맞게 표현했을때 최소 값을 나타낸다
        // 이 값으로 jacoco coverage verification의 성공여부를 판단 (0.00~1.00)
        minimum = 0.60
      }
    
      // verify 에서 제외할 클래스를 지정 (패키지 레벨 경로)
      excludes = []
  }
    
  rule {
      ...
  }
}
}

#. finalizedBy

test task를 먼저 실행한 다음 jacoco task 가 실행되어야 한다.
test -> jacocoTestReport -> jacocoTestCoverageVerification
위 순서대로 task가 실행되도록 finalizedBy 를 적용한다.

#. 테스트 실행 및 결과 확인

테스트 실행

$ ./gredlew test

결과
coverage 66% 로 0.60 를 넘어 verification pass 했다.

[작업로그] CI/CD 구축 #1

Mon, 18 Jan 2021 00:00:00 GMT

#. CI/CD 구축 사용 도구 1. Jenkins

CI (Continuous Integration) / CD (Continuous Deploy) 도구
BitBucket webhook 이벤트 발생 시 test & build & deploy 를 진행
Pipeline 기술을 이용하여 stage 정의

2. Gradle

빌드 툴
Jacoco plugin / Sonarqube scanner plugin 을 사용하여 코드 분석

3. SonarQube

Sonarqube Scanner 에게 정적 분석 관련 데이터 제공
정적 코드 분석 및 버그, 코드 스멜, 보안 취약점 발견 등 코드 품질에 대한 검사 및 리포팅

4. Nginx

테스트 결과 게시
릴리즈 파일 이력관리

#. CI/CD 인프라 구조

#. 전략 & 정책

#. 구성 시나리오 통합 시나리오

시나리오1. Feature Branch 에서 PR 발생

시나리오2. Feature Branch 에서 Merge 발생

시나리오3. Develop Branch 에서 PR 발생

시나리오4. Develop Branch 에서 Merge 발생 (자동)

> [작업로그] CI/CD 구축 #2 - Docker, Docker Compose 설치
> [작업로그] CI/CD 구축 #3 - BitBucket 설정 및 Jenkins 설치
> [작업로그] CI/CD 구축 #4 - Jenkins Item 등록 및 Pipeline 작성
> [작업로그] CI/CD 구축 #5 - sonarqube 설치 및 pipeline 작성

[작업로그] CI/CD 구축 #2

Mon, 18 Jan 2021 00:00:00 GMT

1. Docker 설치

1-1. Docker 설치 및 구동 확인

docker 설치에 필요한 패키지 설치

$ sudo apt update && sudo apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common

도커의 공식 GPG 키와 패키지 저장소 추가

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

docker ce 설치

$ sudo apt update && sudo apt install docker-ce

docker 구동 확인

$ sudo systemctl status docker

1-2. docker 명령어 실행 시 오류

docker 설치 완료 후 명령어 실행 시 아래와 같은 permission 오류가 발생한다.

/var/run/docker.sock 파일을 확인하면 root 사용자, docker 그룹일 경우에만 read/ write 권한이 있다.

1-3. 해결방법

파일 권한을 666 으로 줘도 되지만, 현재 사용 계정을 docker group으로 묶는게 낫다고 판단했다.
만약 동일하게 permission 오류가 난다면 세션을 재시작해보자.

현재 사용자 docker 그룹에 추가

$ sudo usermod -a -G docker [현재계정]

계정이 속한 그릅 확인

# 현재 사용자가 속한 그룹 확인
$ groups

# [사용자 아이디]가 속한 그룹 확인
$ groups [사용자 아이디]

2. Docker Compose 설치

다운로드

$ sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

실행 권한 부여

$ sudo chmod +x /usr/local/bin/docker-compose

> [작업로그] CI/CD 구축 #1 - CI/CD 시나리오

> [작업로그] CI/CD 구축 #3 - BitBucket 설정 및 Jenkins 설치
> [작업로그] CI/CD 구축 #4 - Jenkins Item 등록 및 Pipeline 작성
> [작업로그] CI/CD 구축 #5 - sonarqube 설치 및 pipeline 작성

[작업로그] CI/CD 구축 #3

Mon, 18 Jan 2021 00:00:00 GMT

1. BitBucket Webhook 설정

Repository -> Pepository settings -> Webhooks -> Add Webhook
Push Webhook 설정
— URL : http://JENKINS-HOST/generic-webhook-trigger/invoke?token=build-test-wh-push
— token 값이 중요!

Pull Request Webhook 설정
— URL : http://JENKINS-HOST/generic-webhook-trigger/invoke?token=build-test-wh-pr
— 역시 token 값 중요!

2. Jenkins 설치 1. Compose 파일 작성

jenkins 는 docker 기반으로 설치를 진행하였다.
추후 테스트 도구 확장을 위해 docker-compose 파일을 생성하여 서비스 기동 시켰다.

# jenkins-compose.yml
version: "3.6"
services:
    jenkins:
        image: jenkins/jenkins
        container_name: jenkins
        ports:
            - 10000:8080
            - 50000:50000
        volumes:
            - ~/docker-volumes/jenkins:/var/jenkins_home

2. 서비스 기동

compose 파일 실행 전 volume 디렉토리를 생성한다.

$ mkdir ~/docker-volumes/jenkins
$ docker-compose -f jenkins-compose.yml up -d

3. Jenkins 기동 시 permission 오류

위에 compose 파일 실행 전 volume 디렉토리를 생성하지 않으면 아래와 같은 permission 오류가 난다.

Host에 생성된 volume 디렉토리 owner 가 root 이기 때문에 오류가 발생하였다.

해결방법은
— 이미 생성된 volume 디렉토리 owner 를 현재 사용자로 변경하거나
— compose 파일 실행 전 volume 디렉토리를 먼저 생성하면 된다.

# 서비스 기동 후 : permission 오류 해결
$ sudo chown 현재사용자:현재사용자 -R ~/docker-volumes/jenkins

# 서비스 기동 전 : ~/docker-volumes/jenkins 디렉토리 생성
$ mkdir ~/docker-volumes/jenkins

3. Jenkins 세팅

1. Unlock Jenkins

jenkins 웹페이지 접속 시 아래와 같이 init password를 등록하라고 나온다.

해당 디렉토리를 볼 필요 없이 jenkins 로그를 확인하면 password를 볼 수 있다.

$ docker logs jenkins

2. Jenkins 플러그인 설치 2-1. Jenkins 기본 플러그인 설치

2-2. BitBucket 연동 관련 플러그인 설치

jenkins 관리 > 플러그인 관리 > Bitbucket 검색 후 아래 두개 설치하면 된다.
— Generic Webhook Trigger
— Bitbucket Plugin

3. Jenkins Credential 등록

credential 는 보통 ssh로 등록하는데,
해당 시나리오의 경우 comments 등록이 필요하여 CI용 bitbucket 계정을 생성 후 등록하였다.

#. Jenkins Credential 등록 방법

jenkins 관리 > Manage Credentials
아래 그림 부분에 마우스 오버 시 작은 화살표가 생기는데, 그거 클릭하면 ‘add credential’ 버튼이 생긴다.
또는 global 클릭 후 좌측에 add credential 버튼을 클릭하면 된다.

‘bitbucket-auth-id-pw’ 라는 이름의 jenkins에서 사용할 bitbucket 계정을 등록하면 된다.

> [작업로그] CI/CD 구축 #1 - CI/CD 시나리오
> [작업로그] CI/CD 구축 #2 - Docker, Docker Compose 설치

> [작업로그] CI/CD 구축 #4 - Jenkins Item 등록 및 Pipeline 작성
> [작업로그] CI/CD 구축 #5 - sonarqube 설치 및 pipeline 작성

[작업로그] MySQL Optimize

Fri, 15 Jan 2021 00:00:00 GMT

요청사항

Replication 이 적용된 두 서버의 DB 의 몇몇 테이블 스페이스가 달라요. 확인 해주세요.

확인

DB 데이터 파일이 존재하는 디렉토리에서 데이터파일 사이즈 확인 결과 두개의 로그파일 사이즈가 달랐다.
ibd 파일 위치: my.cnf 파일안에 data 경로

혹시몰라 mysql 접속 후 data+index 사이즈를 확인했지만 현상은 동일했다.

확인해보니 각 DB는 알아서 Optimizer 가 돌기 때문에 사이즈가 조금 씩 다를 수 있다고 전달 받았다.
그래서 실질 적으로 해당 테이블에 optimize 를 진행해보았다.

# 명령어
mysql> optimize table [테이블명]

수행결과 (innoDB의 경우 아래와 같은 결과가 나옴, 오류가 아니라 수행이 완료 된 것임)

실제 ibd 사이즈도 동일해졌다.

테이블 최적화에 대한 몇 개의 글을 찾아보았다. 아래를 참고하자

[intelliJ] FAILURE: Build failed with an exception

Wed, 13 Jan 2021 00:00:00 GMT

문제

intelliJ에서 테스트 코드 수행 시 아래와 같은 오류 발생

원인

intelliJ 업데이트로 인해 발생

해결

settings -> Build, Execution, Deployment -> Build Tools -> Gradle 에서 Run tests using 에서 IntelliJ 선택

[Jenkins] hudson.plugins.git.GitException: Failed to fetch from repo

Tue, 12 Jan 2021 00:00:00 GMT

문제

jenkins에 webhook 이벤트 발생 후 아래와 같은 오류 발생

원인

origin에 있는 특정 브랜치 삭제 후 fetching이 되지 않아 오류 발생

해결

프로젝트 > 구성 > 소스관리 > Additional Behaviours 에서 Wipe out repository & force clone 추가 후 재빌드 한다.

해당 옵션은 webhook 이벤트 발생 시 마다 작업 공간 clean 후 clone 하므로 유지시켜야 할 파일이 있을 경우 백업 또는 이동이 필요하다.
소스 빌드가 완료 됐으면 해당 옵션 제거한다.

[bash] 파일 데이터로 CURL 요청

Mon, 11 Jan 2021 00:00:00 GMT

시나리오

test-csv.csv 파일 한줄 씩 리드
”,” 로 split
API POST 데이터 생성
API 요청
결과

#. test-csv.csv

emaid1,pcid1
emaid2,pcid2

#. Script File

#!/bin/bash

COUNT=0
while read LINE;
do
    # IFS 는 입력필드 구분자
    # ${vStr[0]} , ${vStr[1]} 로 사용
    IFS=',' read -ra vStr <<< $LINE

    COUNT=$(($COUNT + 1))
    DATA="{\"emaid\": \"${vStr[0]}\", \"pcid\": \"${vStr[1]}\"}"

    echo RequestData${COUNT} : ${DATA}

    curl -H "Content-Type: application/json" \
            -d "${DATA}" \
            -w " - status code: %{http_code}, sizes: %{size_request}/%{size_download}\n\n" \
            -X POST http://192.168.250.79:15000/api/v2/mo/contractById

done < test-csv.csv

#. 결과

[작업내역] Nginx 설치

Fri, 08 Jan 2021 00:00:00 GMT

폐쇠망에서 nginx를 설치하게 되어 rpm 으로 진행하였다.(CentOS 7)

#. RPM 다운로드

http://nginx.org/packages

# 금일 기준 stable version : 1.18
$ wget http://nginx.org/packages/centos/7/x86_64/RPMS/nginx-1.18.0-2.el7.ngx.x86_64.rpm

#. RPM 설치

$ sudo rpm -Uvh nginx-1.18.0-2.el7.ngx.x86_64.rpm

#. 서비스 파일 확인

$ll /usr/lib/systemd/system/nginx.service

#. systemctl daemon 재시작

$ systemctl daemon-reload

#.정상적으로 Service가 등록되었는지 확인

$ systemctl status nginx

#. 필요시 방화벽 해제

firewall 구동 확인

$ firewall-cmd --state

http, https 서비스에 대해 해제/제거

# 해제
$ sudo firewall-cmd --permanent --add-service=http
$ sudo firewall-cmd --permanent --add-service=https

# 제거
sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --permanent --remove-service=http

# --permanent : 영구적으로 실행 (default zone에 등록 : /etc/firewalld/zones/public.xml)
# --add-service : 해당 서비스를 추가
# --remove-service : 해당 서비스를 삭제

특정 port로 방화벽 해제/제거

# 해재
$ sudo firewall-cmd --permanent --add-port=80/tcp

# 제거
$ sudo firewall-cmd --permanent --add-remove=80/tcp

Intellij run configurations에 docker-compose 등록

Wed, 06 Jan 2021 00:00:00 GMT

#.1. docker-compose.yml 우클릭 후 Create docker-compose.yml.. 선택

#2. configuration 설정

server 는 디폴트로 생성
compose 파일이 선택되어 있는지 확인
빌드 옵션 추가

#3. run

#4. docker daemon 설정

아래와 같이 connection refused 가 발생하면 4.1 로 간다

#4.1 docker - settings

#4.2. Expose daemon on… 선택 후 도커 재시작

Docker 기반 Remote Debugging 개발 환경 설정

Wed, 06 Jan 2021 00:00:00 GMT

#. 작업 구성

작업 내용

git repository 이동

#1. WAS Dockerfile

FROM openjdk:8-jdk

# 환경 변수 및 작업 경로 설정
ENV WCA_LIB /usr/local/wca_libs
ENV CATALINA_HOME /usr/local/tomcat
ENV PATH $WCA_LIB:$CATALINA_HOME/bin:$PATH
ENV LD_LIBRARY_PATH $WCA_LIB:$LD_LIBRARY

COPY docker/lib/lib.tar.gz $WCA_LIB/
RUN tar -zxf $WCA_LIB/lib.tar.gz -C $WCA_LIB/
RUN mkdir -p "$CATALINA_HOME"
WORKDIR ${CATALINA_HOME}

# 패키지 설치 wget은 톰캣 설치 파일 다운로드 위한
RUN apt-get update;
RUN apt-get install -y --no-install-recommends
RUN apt-get install -y gnupg dirmngr
RUN apt-get install -y wget ca-certificates

# 톰캣 바이너리 다운로드 및 압축해제
ENV TOMCAT_VERSION 8.5.61
RUN wget http://apache.mirror.cdnetworks.com/tomcat/tomcat-8/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz;
RUN tar -xf apache-tomcat-$TOMCAT_VERSION.tar.gz  --strip-components=1;

# 불필요 파일 삭제 후 webapps 디렉토리 새로 생성
RUN find . -name "*.bat" -exec rm -rf {} \;
RUN rm -rf *tomcat*.tar.gz;
RUN mv webapps webapps.org
RUN mkdir webapps

# war 파일 복사
COPY build/libs/ROOT.war $CATALINA_HOME/webapps

# tomcat conf 파일 복사
COPY docker/tomcat-conf/* $CATALINA_HOME/conf/

# 컨테이너에서 사용할 포트 (서비스 포트, remote debugging 포트)
EXPOSE 8080 5000

# debugging 모드 시 필요 환경 변수
ENV JPDA_ADDRESS=5000
ENV JPDA_TRANSPORT=dt_socket

# 설정 완료 후 실행
#CMD ["catalina.sh", "run"]
CMD ["catalina.sh", "jpda", "run"]

2. DB Dockerfile

FROM mysql:5.7.32
#FROM mariadb:10.4.10

# my.cnf 파일 복사
ADD ./mysql-conf/my.cnf /etc/mysql/conf.d/my.cnf

3. docker-compose.yml

Docker-Compose 내용 정리

4. IntelliJ 원격 디버깅 설정

IntelliJ 설정 확인

Docker-Compose 내용 정리

Wed, 06 Jan 2021 00:00:00 GMT

Docker-Compose

Define and run multi-container application with Docker.
여러 개의 컨테이너를 동작시키기 위해 도커 어플리케이션을 정의하고 실행하는 도구

docker-compose.yml

컨테이너 실행에 사용되는 옵션과 컨테이너 간 의존성을 모두 docker-compose.yml 파일에 적어두고, docker-compose 명령어를 사용하여 컨테이너를 실행 및 관리

version

docker-compose.yml 파일의 첫 줄에는 파일 규격 버전을 적는다.
파일의 규격에 따라 지원하는 옵션이 달라진다. 참고

1| version: "3.1"

services

실행하려는 컨테이너들을 정의

 2| services:
 3|   ca-db:
       ...
18|  ca-was:
       ...

image

베이스 이미지를 지정

4| image: mariadb:10.4

build

도커파일을 이용하여 베이스 이미지 지정
도커 파일의 경로나 이름이 다르면 아래와 같이 지정

5| build:
6|   context: ./docker
7|   dockerfile: Dockerfile.db

restart

재시작 옵션

8| restart: always

# no : 
    container를 재시작 시키지 않는다. (default)  
# on-failure[:max-retries] :
    container가 정상적으로 종료되지 않은 경우(exit code가 0이 아님)에만 재시작 시킨다. 
    max-retries도 함께 주면 재시작 최대 시도횟수를 지정할 수 있고, 테스트 서버 등과 같은 리모트에 설정하면 좋을 것 같다.  
# always : 
    container를 항상 재시작시킨다. 
    exit code 상관 없이 항상 재시작 된다.
# unless-stopped : 
    container를 stop시키기 전 까지 항상 재시작 시킨다.

environment

docker run 명령어의 —env, -e 옵션과 동일, 환경변수

 9| environment:
10|   MYSQL_ROOT_PASSWORD: flatron123!
11|   MYSQL_DATABASE: webca

volumes

DB의 데이터를 로컬에 저장
sql을 /docker-entrypoint-initdb.d/ 에 저장하면 DB가 start 될 때 sql 문을 순차적으로 실행한다

12| volumes:
13|   - ./ca-db-data:/var/lib/mysql
14|   - ./docker/mysql-conf/init.sql/:/docker-entrypoint-initdb.d/

ports

HOST:CONTAINER 형식으로 호스트로 들어온 포트를 해당 컨테이너의 포트로 포워딩

15| ports:
16|   - 3333:3306

depends_on

서비스 간 의존 관계를 지정
명시된 컨테이너가 먼저 생성되고 실행

26| depends_on:
27|   - ca-db

도커와 기존의 가상화 기술과의 차이를 통한 컨테이너 이해

Sat, 02 Jan 2021 00:00:00 GMT

#. 하이퍼바이저 기반의 VM 구조

하이퍼바이저에 의해 구동되는 VM은 각 VM마다 독립된 가상 하드웨어 자원을 할당받는다.
논리적으로 분리 되어 있어 한 VM에 오류가 발생해도 다른 VM으로 퍼지지 않는다는 장점이 있다.

#. 도커 VS 기존 가상화 기술(VM)

#1. 공통점

도커 컨테이너와 가상 머신은 기본 하드웨어에서 격리된 환경 내에서 애플리케이션을 배치하는 방법

#2. 차이점

vm과 비교했을 때 컨테이너는 하이퍼바이저와 게스트 OS가 필요하지 않으므로 더 가볍다.

#2.1. 도커 컨테이너에서 돌아가는 애플리케이션은
컨테이너가 제공하는 격리 기능 내무에 샌드박스가 있지만, 여전히 같은 호스트의 다른 컨테이너와 동일한 커널을 공유한다.
컨테이너가 전체 OS를 내장할 필요가 없는 결과, 매우 가볍고 일반적으로 약 5-100MB 이다.

#2.2. 가상머신

VM 내부에서 실행되는 모든 것은 호스트 운영체제 또는 하이퍼바이저와 독립되어 있다.
게스트 OS를 부팅하여 어플리케이션을 실행하기 때문에 무겁다.

#. 도커

카카오톡 컨테이너와 노션 컨테이너는 커널을 공유하고 있다.
각 컨테이너는 실행 프로그램 및 필요한 양만큼의 리소스에 대해 격리가 되어 있다.

#.도커 컨테이너를 격리시키는 방법

컨테이너와 호스트에서 실행되는 다른 프로세스 사이에 벽을 만드는 리눅스 커널 기능인 Cgroup과 네임스페이스를 사용

컨테이너가 생성이 되는 방법

Sat, 02 Jan 2021 00:00:00 GMT

컨테이너 이미지

이미지는 응용 프로그램을 실행하는데 필요한 모든 것을 포함하고 있다.
- 1. 컨테이너가 시작 될 때 실팽되는 명령어
- 2. 파일 스냅샷 (디렉토리나 파일을 복사 한 것)

이미지로 컨테이너 만드는 순서

#1. Docker 클라이언트에 docker run <이미지> 입력

$ docker run helloworld

#2. 도커 이미지에 있는 파일 스냅샷을 컨테이너 하드 디스크에 옮겨 준다

#3. 이미지에서 가지고 있는 명령어 (컨테이너가 실행될때 사용될 명령어)를 이용하여 앱 실행

3.1. 명렁어 실행
3.2. 커널을 통해 앱 시작
3.3. 프로세스 작동

도커 이미지 생성

Sat, 02 Jan 2021 00:00:00 GMT

#. 도커 파일(Docker file)이란?

도커 이미지를 만들기 위한 설정 파일이며, 컨테이너가 어떻게 행동해야 하는지에 대한 설정들을 정의해 주는 곳

#. 도커 파일 만드는 순서

베이스 이미지를 명시해준다. (파일 스냅샷에 해당)
추가적으로 필요한 파일을 다운 받기 위한 몇가지 명령어를 명시 (파일 스냅샷에 해당)
컨테이너 시작시 실행 될 명령어를 명시 (시작시 실행 될 명령어에 해당)

#. 베이스 이미지란?

도커 이미지는 여러개의 레이어로 구성되어 있다.
그 중에서 베이스 이미지는 이 이미지의 기반이 되는 부분이다.
레이어는 중간 단계의 이미지라고 생각하면 된다.

#. 도커 파일로 이미지 생성

#1. 도커 파일 생성

기본적 토대

# 베이스 이미지를 명시
# 태그를 안붙이면 자동적으로 가장 최신것으로 다운
FROM <이미지이름>:<태그>

# 도커이미지가 생성되기 전에 수행할 쉘 명령어
RUN <command>

# 컨테이너 시작시 실행 될 파일 또는 명령어
CMD ["excutable"]

#2. 도커 파일 빌드

build 명령어 : 해당 디렉토리 내에서 명시된 도커파일을 찾아 도커 클라이언트에 전달

도커 이미지에 이름 부여 (-t : tagging)

$ docker build -t <나의 도커 아이디>/<저장소/프로젝트>:<버전> ./

JVM 분석 툴

Thu, 31 Dec 2020 00:00:00 GMT

#1. JPS

Java Virtual Machine Process Status Tool
JVM 프로세스 표시

// PID, 메인 메소드의 args 표시
$ jps -m 

// PID, jvm 파라미터 표시
$ jps -v

#2. JMAP

JVM 프로세스의 메모리 맵 표시

#2.1. heap 메모리 사용 현황에 대한 요약 정보

$jmap -heap <PID>

#2.2. 객체 타입 별 사용 내역

$jmap -histo:live <PID>

참고) [C, [I, [B 이란?

[L 은 class 또는 interface 즉, any non-primitives(Object)

#2.3. gc 대기중인 클래스 목록 확인

$jmap -finalizerinfo <PID>

#2.4. 덤프 파일 생성

파일 확장자는 일반적으로 .hprof 를 사용
힙 메모리의 크기가 GB 단위로 크다면, 분석할 덤프 파일 크기도 GB 단위로 늘어남
```
jmap -dump:[live,]format=b,file=<dump filename> <PID>
```

#3. JHAT

Java Heap Analyzer Tool
힙 메모리 분석 툴
입력한 포트(기본은 7000)로 덤프파일이 분석된 웹페이지가 구동
```
$ jhat [-port] <dump filename>
```

[작업로그] JVM OutOfMemory Error 분석

Thu, 31 Dec 2020 00:00:00 GMT

팀에서 서비스하고 있는 제품 중, 아이맘 택시 서비스에서 아래와 같은 현상이 발생 되었다.
당시, 해당 프로세스의 메모리 사용량이 8G를 넘고 있었고(평균 1G), CPU 사용량도 90% 이상이 넘고 있었다.

GC Overhead
JDBC Connection Pool Error
Java heap Out of memory

현재 내가 진행하고 있는 프로젝트가 아니라.. 로그만으로는 분석이 힘들어 jvm 분석 툴을 사용하여 아래와 같이 모니터링을 하였다.

#1. 모니터링 스크립트 만들기

#1.1. 사용 리소스 모니터링

해당 서비스의 메모리, cpu 사용률 및 부하 감지를 위한 서비스, DB 포트 연결 개수 모니터링

#!/bin/bash

LOG=log_res_mn
while [ true ]
do

        echo `echo \[;date;echo \]` >> $LOG
        echo `echo netstat 8000 cnt \[;netstat -na | grep 8000 | wc -l;echo \];` >> $LOG
        echo `echo netstat 3306 cnt \[;netstat -na | grep 3306 | wc -l;echo \];` >> $LOG
        ps -eo pid,rss,size,vsize,pmem,pcpu,time,cmd --sort -rss | grep NAMU | head -n 1 >> $LOG
        #ps -eo pid,rss,size,vsize,pmem,pcpu,time,cmd --sort -rss | head -n 5 >> $LOG
        echo ------------------------------------------------------------------------ >> $LOG
        sleep 1;
done;

#1.2. 해당 프로세스 PID의 메모리 사용 내용

jmap -histo:live [PID] 명령어를 이용
해당 프로세스에서 사용하고 있는 클래스 별 사용 내역 (인스턴스 개수, 사용된 메모리 크기)

#!/bin/bash

LOG=log_mn_jvm
while [ true ]
do
        PID=`sudo jps -v | grep "\-Xmx2048m" | awk '{print $1}'`
        echo `echo \[;date;echo \]` >> $LOG
        sudo jmap -histo:live $PID | head -n 10 >> $LOG
        echo ------------------------------------------------------- >> $LOG
        sleep 5;
done;

#2. 모니터링 결과

** 해당 결과는 새벽에 오류 재연을 한 것이므로 오류 상황보다 CPU 점유율이 낮게 나왔다. **

#2.1. 오류 발생 전

기본 사용 메모리, cpu
인스턴스 개수

#2.2. 오류 발생 후

문제 발생 시점부터 약 20초간 확 증가된 메모리 사용량
해당 시점의 인스턴스 상태

GC가 돌아 약 25초간 cpu 사용량 쭉 증가 후 약 40초간 유지
그 후 점차 감소

#2.3. 소스 검토

해당시간에 발생된 request url 검사 후 해당 로직 검토를 하였더니 Document 테이블에서 가져오는 row수가 1,713,561건 인것을 발견하였다.
해당 비즈니스 로직에 대한 이해도가 없어 왜 이런 상황이 발생이 됐는지는 모르겠지만, select 최대 row를 강제할 수 있는 방법을 찾아 팀 코드 컨벤션으로 정해야겠다.
좋은 경험 했다!!!!!!!

jmap 사용 시 main java.lang.reflect.InvocationTargetException 발생

Thu, 31 Dec 2020 00:00:00 GMT

문제

jmap 사용 시 아래와 같은 에러 발생

원인

기본적으로 설치한 jdk에는 debugging이 포함되어 있지 않다.

해결

openjdk-8-dbg 설치

설치 후

Docker? 및 명령어 정리

Wed, 30 Dec 2020 00:00:00 GMT

#. 도커는 무엇인가요?

컨테이너를 사용하여 응용프로그램을 더 쉽게 만들고 배포하고 실행할 수 있도록 설계된 도구 이며, 컨테이너 기반의 오픈소스 가상화 플랫폼이며 생태계

#. 컨테이너란?

코드와 모든 종속성을 패키지화하여 응용 프로그램이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행되도록 하는 소프트웨어의 표준 단위
컨테이너 안에 다양한 프로그램, 실행환경을 컨테이너로 추상화하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해준다.

#. 컨테이너 이미지

코드, 런타입, 시스템 도구, 시스템 라이브러리 및 설정과 같은 응용 프로그램을 실행하는 데 필요한 모든 것을 포함하는 가볍고 독립적이며 실행 가능한 소프트웨어 패키지
도커 이미지는 프로그램을 실행하는데 필요한 설정이나 종속성을 갖고 있으며, 도커 이미지를 이용해서 컨테이너를 생성하며(이미지의 인스턴스) 도커 컨테이너를 이용하여 프로그램을 실행

#. 도커 명령어 모음

#. 컨테이너

# 동작중인 컨테이너 확인
$ docker ps

# 정지된 컨테이너 확인
$ docker ps -a

# 컨테이너 삭제
$ docker rm [컨테이너 id], [컨테이너 id] 

# 컨테이너 모두 삭제
$ docker rm `docker ps -a -q`

# 중지된 모든 컨테이너 삭제
$ docker container prune

# 실행중인 컨테이너에 명령어 전달, interactive, terminal : 명령어 실행 후 터미널 계속 유지
# docker exec {-it} <컨테이너 아이디> <명령어>

# 해당 컨테이너의 ssh 접속
$ docker exec -it <컨테이너 아이디> sh

# 실행 시 volume 잡기, 맥에선 -v $(pwd):/usr/src/app
$ docker run -p 3000:3000 -v /usr/src/app/node_modules -v %cd%:/usr/src/app [이미지 아이디]

#. 이미지

# 이미지 확인
$ docker images
$ docker image ls

# 이미지 삭제, 강제옵션 -f
$ docker image {-f} rm [이미지id], [이미지id]
$ docker rmi {-f} [이미지id], [이미지id]

# 이름없는 모든 이미지 삭제
$ docker image prune

#. docker 리소스정리

# 중지된 모든 컨테이너, 사용되지 않은 모든 네트워크, 하나 이상의 컨테이너에서 사용되지 않는 모든 이미지를 삭제
$ docker system prune -a

#. dockerfile 빌드

$ docker build {-f dockerfile} {-t tag} [context 폴터위치]

#. docker compose 실행/종료

$ docker-compose up {-d --build}
$ docker-compose down

SpringBoot Remote Debugging

Tue, 29 Dec 2020 00:00:00 GMT

#1. 서버 설정

아래 옵션을 추가한다.

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=15001,suspend=n

실행 시 15001 포트로 접속하여 디버깅을 진행할 수 있다.

#2. IntelliJ 설정

서버와 동일한 프로젝트에서 아래와 같이 debug configuration 을 적용한다.
Remote 선택 후

Debugger mode 선택, Host, Port를 넣어 실행하면

아래와 같이 접속 성공 시 “Connedted to the target VM” 이 뜨고, 종료 시 “Disconnected” 가 출력된다.

프로젝트 gradle version 확인 및 업데이트

Tue, 29 Dec 2020 00:00:00 GMT

#1. gradle version 확인

gradle -> wrapper -> gradle-wrapper.properties 안에 해당 프로젝트의 gradle 버전이 명시되어 있다.

#2. gradle version 변경

// gradlew wrapper --gradle-version {변경 할 버전 정보}
$ gradlew wrapper --gradle-version 4.5.1

[MariaDB] Prepared statement needs to be re-prepared

Thu, 24 Dec 2020 00:00:00 GMT

문제

프로젝트 실행 시 아래와 같은 에러 발생

Cause: java.sql.BatchUpdateException: Prepared statement needs to be re-prepared

원인

로컬에 너무 많은 DB/테이블 생성으로 인한 table definition cache 부족

해결

table_definition_cache 값 변경
Default 값은 400

변경방법1) 쿼리문 (DB 재시작 시 기본세팅으로 변경됨)

MariaDB [(none)]> SHOW VARIABLES LIKE 'table_definition_cache%';
+------------------------+-------+                              
| Variable_name          | Value |                              
+------------------------+-------+                              
| table_definition_cache | 400   |                              
+------------------------+-------+                              
1 row in set (0.001 sec)                                        
                                                                
MariaDB [(none)]> SET GLOBAL table_definition_cache = 600;

변경방법2) my.cnf 수정

[mysqld]
table_definition_cache = 400

Table Definition Cache?

cf) https://mariadb.com/kb/en/server-system-variables/#table_definition_cache

[MariaDB] 현재 status 확인 방법

Tue, 22 Dec 2020 00:00:00 GMT

#. mysqladmin 명령어로 상태 출력

// -i5 : interval 5s
$ mysqladmin -i5 status -u root -p
Enter password: 
Uptime: 10578  Threads: 1  Questions: 4809  Slow queries: 589  Opens: 1321  Flush tables: 1  Open tables: 348  Queries per second avg: 0.454

# Uptime : MySQL server 시삭된 후 현재 시간 (초 단위)
# Threads : 현제 DB 서버에 연결된 유저수
# Questions : 서버 시작후 지금까지 요청된 쿼리수
# Slow queries : mysql 설정파일에 슬로우쿼리의 쿼리시간 이상을 가진 요청수
# Opens : 서버가 시작된 후 현재까지 열렸던 테이블수
# Open tables : 현재 열려 잇는 테이블 수
# Queries per second avg : 평균 초단 쿼리수

[MariaDB] SlowQuery 설정 및 확인

Tue, 22 Dec 2020 00:00:00 GMT

Slow Query(슬로우쿼리)

Slow Query(슬로우쿼리)는 지정된 시간보다 실행하는데 오래걸리는 쿼리에 대한 log
특정 작업이 오래 걸린다면 로그를 통해 원인을 파악이 가능

#. 설정 확인

slow query log 설정 상태 확인

# slow query 설정 정보
mysql> show global variables like 'slow%';

# 소요시간 확인
mysql> show global variables like '%long_query_time%';

# 로그파일 저장 방법 (FILE / TABLE)
mysql> show global variables like '%log_output%';

#. 설정 방법

#1. my.cnf 파일 설정 및 재기동

파일 설정

# 3초 이상 소요된 쿼리를 테이블에 기록
[mysqld]
slow_query_log=1
long_query_time = 3

log_output = TABLE
log_slow_queries       = /var/log/mysql/mysql-slow.log

재기동

$ /etc/init.d/mysqld restart

#2. 쿼리문 사용 (편하다…, 재기동시 날라간다…)

# 해당 값(초) 이상의 로그 기록
mysql> set global long_query_time = 3;

# 슬로우쿼리 활성 여부 (0 = 비활성 / 1 = 활성)
mysql> set global slow_query_log = 1;

# 로그파일 저장 방법 변경
mysql> set global log_output = 'TABLE';

#. 로그 확인

#. mysql.slow_log 테이블 확인

mysql> select sleep(3);

mysql> select * from mysql.slow_log\G

#. /var/log/mysql/mysql-slow.log 파일 확인

아래와 같은 형식으로 로그파일에 기록됨

# Query_time : 쿼리 처리시간  
# Lock_time : lock이 걸린 횟수  
# Row_sent : 조회 결과 Row 수  
# Rows_examined : 조회 대상 ROW 수  

# User@Host: DB_유저[DB_유저] @ server_hostname [서버IP]
# Query_time: 0.000599  Lock_time: 0.000163 Rows_sent: 3  Rows_examined: 86
SET timestamp=1489118717;
select count(*)

2021.02.01. 오늘 slow query 찾아보다가 내용이 부실해서 추가함...

Grep AND, OR, NOT 사용 명령어

Sun, 20 Dec 2020 00:00:00 GMT

#1. AND

#1.1. pipe를 이용해 여러번 사용

cat test.txt | grep pattern1 | grep pattern2

#1.2. -E 옵션 사용

순서가 pattern1 다음 pattern2 가 매치되는 라인
```
$ grep -E grep "pattern1.*pattern2"
```

순서가 상관 없으려면

$ grep -E grep "pattern1.*pattern2|pattern2.*pattern1"

#2. OR

#2.1. -e 옵션 사용

$ cat test.txt | grep -e pattern1 -e pattern2

#2.2. -E 옵션 사용

$ cat test.txt | grep -E "pattern1|pattern2"

#3. NOT

3.1. -v 옵션을 이용

cat test.txt | grep -v pattern1 | grep -v pattern2

(사용로그)

$ cat log | grep -E "Done createContract \[[0-9]{4,5}\]" -B32 | grep -E "Request|controller| \[[7-9]{1}[0-9]{2}| \[[0-9]{4,5}\]"
$ cat total2.log | grep -B25 "Done renewContract" | grep -E " \[1[5-9]{1}[0-9]{2}| \[[2-9]{1}[0-9]{3,4}\]| \[[1-9]{1}[0-9]{4}\]| \[[7-9]{1}[0-9]{2}"

리눅스 명령어를 이용한 시스템 모니터링하기

Sun, 20 Dec 2020 00:00:00 GMT

#1. uname: 시스템과 커널의 정보

$ uname -a
Linux V2G-Dev-Server 5.4.0-1034-azure #35~18.04.1-Ubuntu SMP Thu Dec 10 09:13:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

# [Linux] : 커널 명
# [V2G-Dev-Server] : 호스트 명
# [5.4.0-1034-azure] : 커널 릴리즈 정보
# [#35~18.04.1-Ubuntu SMP Thu Dec 10 09:13:52 UTC 2020] : 커널 버전
# [x86_64] : 머신 하드웨어 이름
# [x86_64] : 프로세서 종류
# [x86_64] : 하드웨어 플랫폼
# [GNU/Linux] : 운영체제

#2. top: 운영체제 작업 내역 모니터링

#2.1. CPU

User값이 높다면, 사용자 코드를 수행하는데 시간이 오래 걸린다면 내부적으로 계산을 많이 하고 있다는 것
System값이 높다면, 시스템에 의해 사용되고 있는 시간이 오래 걸린다면 프로세스들이 시스템 호출 또는 I/O가 많다고 할 수 있음
idle의 값이 항상 0이라면 CPU를 100% 사용하고 있다는 것을 의미

[us] : 사용자가 사용중인 사용률
[sy] : 시스템이 사용중인 사용률
[ni] : 프로세스 우선순위를 기반으로 사용되는 사용률(사용자 공간에서 사용됨)
[id] : 아무 일도 하지 않는 여유률
[wa] : 입출력을 기다리는 프로세스 사용률
[hi] : 하드웨어 인터럽트 사용률
[si] : 소프트웨어 인터럽트 사용률
[st] : 가상화 환경에서 손실률

#2.2. PROCESS

[PID] : 프로세스 ID
[USER] : 프로세스를 실행시킨 사용자 ID
[PR] : 프로세스의 우선순위
[NI] : NICE 값, 마이너스를 가지는 값이 우선순위가 높음
[VIRT] : 가상 메모리의 사용량(SWAP+RES)
[RES] : 현재 페이지가 상주하고 있는 크기
[SHR] : 가상 메모리 중 사용중인 메모리를 제외한 잔여 가상 메모리
[S] : 프로세스의 상태
[%CPU] : 프로세스가 사용하는 CPU의 사용률
[%MEM] : 프로세스가 사용하는 메모리의 사용률
[TIME+] : 프로세스가 CPU를 사용한 시간
[COMMAND] : 실행된 명령어

#2.3. 프로세스의 정렬 방법

[SHIFT + M] : 메모리 사용률 정렬
[SHIFT + N] : PID 기준 정렬
[SHIFT + P] : CPU 사용률 정렬
[SHIFT + T] : 실행시간 기준 정렬
[SHIFT + R] : 정렬 기준변경 (오름차순인 경우 내림차순으로, 내림차순인 경우 오름차순으로 변경)

[u] : 사용자 명 입력 시 해당 사용자의 프로세스만 표시

[1] : CPU Core 개수 만큼 표시

#3. free

[total] : 설치된 총 메모리 크기 / 설정된 스왑 총 크기
[used] : total에서 free, buff/cache를 뺀 사용중인 메모리. / 사용중인 스왑 크기
[free] : total에서 used와 buff/cahce를 뺀 실제 사용 가능한 여유 있는 메모리량 / 사용되지 않은 스왑 크기
[shared] : tmpfs(메모리 파일 시스템), ramfs 등으로 사용되는 메모리. 여러 프로세스에서 사용할 수 있는 공유 메모리
[buffers] : 커널 버퍼로 사용중인 메모리
[cache] : 페이지 캐시와 slab으로 사용중인 메모리
[buff/cache] : 버퍼와 캐시를 더한 사용중인 메모리
[available] : swapping 없이 새로운 프로세스에서 할당 가능한 메모리의 예상 크기. (예전의 -/+ buffers/cache이 사라지고 새로 생긴 컬럼)

참고) https://www.whatap.io/ko/blog/37/

#4. vmstat: 시스템 정보 모니터링

시스템 작업, 메모리, 페이징, 블록장치의 I/O, CPU상태 등을 확인
vmstat [delay [count]]를 사용하면 실시간으로 상태 확인 가능

#4.1. procs

[r] : CPU에서 대기중인 프로세스의 수를 의미, r의 개수가 CPU의 개수의 2배를 넘는다면 CPU의 성능을 올려줘야 함
[b] : 인터럽트가 불가능한 sleep 상태에 있는 프로세스의 수 (I/O 처리를 하는 동안 블록 처리된 프로세스), b의 수치가 높은 경우라면 CPU가 계속 대기상태로 있다는 의미이므로 디스크 I/O를 확인해 볼 필요가 있다

#5. iostat: CPU, 디스크 입출력 상태 모니터링

평균 CPU부하 와 디스크 I/O의 세부적인 내용을 확인
iostat [delay [count]]를 사용하면 실시간으로 상태 확인 가능

#5.1. Device

[tps] : 디바이스에 초당 전송 요청 건수
[kB_read/s] : 디바이스에서 초당 읽은 데이터 블록 단위
[kB_wrtn/s] : 디바이스에서 초당 쓴 데이터 블록 단위
[kB_read] : 디바이스에서 지정한 간격 동안 읽은 블록 수
[kB_wrtn] : 디바이스에서 지정한 간격 동안 쓴 전체 블록 수

#6. df: 디스크 모니터링

파일시스템 별 전체공간, 사용중인 공간, 여유 공간 표시

#7. du: 디렉토리 용량

특정 파일이나 디렉토리 용량 확인
du -s [파일이나 디렉토리] 를 사용하면 해당 파일이나 디렉토리 용량 확인(-s만 적을 경우 현재 디렉토리)

[작업로그] Jenkins/Bitbucket 연동

Tue, 15 Dec 2020 00:00:00 GMT

Jenkins/Bitbucket 연동

이번에 JIRA를 사용하면서 Bitbucket을 사용하게 되었다. 이에 따라 Jenkins/Github 에서 Jenkins/Bitbucket 으로 변경하는 작업을 하였다.

#1. Jenkins에 Bitbucket 플러그인 설치

Jenkins 관리 -> 플러그인 관리
Bitbucket 설치

#2. Jenkins Item 구성

프로젝트 -> 구성 -> 소스 코드 관리 및 빌드 유발 수정

Repository URL
— git clone 주소
Credentials
— Add 누른 후 bitbucket 계정 및 패스워드 입력

Build 에 Execute Shell 내용 추가

#3. Bitbucket Webhook 설정

Repository 선택 후, Repository settings -> Webhooks 에 들어가면 webhook 설정을 할 수 있다

Webhook 을 추가하여 아래와 같이 입력한다. — URL : http://{jenkins_host}/bitbucket-hook

Webhook History
— Enable History 버튼을 클릭하면 아래 그림과 같이 해당 Webhook에 대한 History 내역을 볼 수 있다.
— Webhook 추가시에 URL을 bitbucket-webhook으로 잘못적어 403 에러가 계속 났었다.. 404 에러로 좀 해주지…

[작업로그] Jenkins Timezone 변경

Tue, 15 Dec 2020 00:00:00 GMT

[작업로그] Jenkins Timezone 변경

jenkins 실행 파일에 아래 option을 추가하라는 가이드가 많았다.

JENKINS_JAVA_OPTIONS="-Dorg.apache.commons.jelly.tags.fmt.timeZone=Asia/Seoul"

jenkins 실행파일을 보니 java 옵션으로 줘도 괜찮겠다 싶어서 아래 처럼 진행하였다.

실행파일 위치 : /etc/init.d/jenkins
do_start 함수 안에 java 명령어에 ‘-Duser.timezone=Asia/Seoul’ 옵션 추가
jenkins 재시작

// jenkins 재시작
$ /etc/init.d/jenkins restart

참고로 -D 옵션은 아래와 같다

jenkins 시스템 설정 정보 보는 방법

http://{jenkins_host}/systemInfo

grep - Binary file (standard input) matches

Mon, 14 Dec 2020 00:00:00 GMT

문제

grep 명령어 시 “Binary file (standard input) matches” 에러 발생

원인

로그파일 grep 할때 텍스트 파일로 인식하지 않고 Binary file 로 인식

해결

-a 혹은 —text 옵션 추가

$ cat server.log | grep -E " \[[0-9]{4}\]" -a
or
$ cat server.log | grep -E " \[[0-9]{4}\]" --text

tcpdump 패킷 분석

Sat, 12 Dec 2020 00:00:00 GMT

성능 테스트 중에 솔루션 내에서 DB insert/select 할 때 소요시간이 오래 걸리는 현상이 발생되었다.
데이터가 많이 쌓인것도 아닌데..
해당 부분이 솔루션 문제인지, 네트워크 문제인지 DB 문제인지 확인을 위해 tcpdump를 분석하였다.

#. 사용 툴

WireShark

#. tcpdump file out 명령어

DB 서버에 tcpdump를 떠서 WAS 서버에서 오는 모든 패킷에 대해 파일로 저장하도록 함.

$ sudo tcpdump -w host {WAS_HOST} tcpdump.pcap

#. 파일 분석

1. Update 쿼리 요청

        RequestQuery    : Seq(192795), Len(8228), Ack(313141)   
[WAS] ---------------------------------------------------------> [DB]
 (WAS) : 쿼리 요청한다.
         내가 보냈던 총 데이터 길이(seq)는 192795였고, 지금 보내는 데이터 길이는 8228 이야. 
         그리고 너(DB)한테 받은 총 길이는 313141(ack) 이야.

2. Update 쿼리 요청에 대한 ACK

        Ack             : Seq(313141), Len(0), Ack(201023)
[WAS] <--------------------------------------------------------- [DB]  
 (DB) : 응 받았어, Ack 보낸다.
        너(WAS)한테 내가 313141 까지 보냈고, 너한테 받은 총 길이는 201023(192795+8228) 이야

3. Update 쿼리 요청에 대한 응답

        Response OK     : Seq(313141), Len(52), Ack(201023)
[WAS] <--------------------------------------------------------- [DB]  
 (DB) : 요청한거 응답이야.
        너(WAS)한테 내가 313141 까지 보냈었고, 쿼리 받은거 수행한 결과야(52)
        그리고 너한테 받은 길이는 201023 야

4. Commit 쿼리 요청

        RequestQuery     : Seq(201023), Len(11), Ack(313193)
[WAS] ---------------------------------------------------------> [DB]  
 (WAS) : Commit 해줘.
         너(DB)한테 내가 201023 까지 보냈고, 지금 보내는 데이터 길이는 11 이야.
         그리고 너(DB)한테 받은 총 길이는 313193(313141+52) 이야.

5. Commit 쿼리 요청에 대한 ACK

        Ack             : Seq(313193), Len(0), Ack(201034)
[WAS] <--------------------------------------------------------- [DB]  
 (DB) : 응 받았어, Ack 보낸다.
        너(WAS)한테 내가 313193 까지 보냈고, 너한테 받은 총 길이는 201034(201023+11) 이야

6. Commit 쿼리 요청에 대한 응답

        Response OK     : Seq(313193), Len(11), Ack(201034)
[WAS] <--------------------------------------------------------- [DB]  
 (DB) : 요청한거 응답이야.
        너(WAS)한테 내가 313193 까지 보냈었고, 쿼리 받은거 수행한 결과야(11)
        그리고 너한테 받은 길이는 201034 야

#. 파일 분석 결과

5번과 6번 소요시간이 약 10초 이상 딜레이된 것이 발견되었다.
솔루션 및 네트워크 문제는 아닌것으로 판단되어 DB 기술지원 업체에 문의하였다.
DB 로그를 DB 테이블에 쌓고 있었다는 답변이 왔다…

참고) wireShark 필터 사용 내역

Arrival Time
— frame.time <= “Dec 11, 2020 20:44:58.877172000”
Sequence
— tcp.seq eq 184381
mysql query target table
— mysql.field.org_table eq “ccp”

[Linux] 리소스 모니터링 오픈소스

Wed, 09 Dec 2020 00:00:00 GMT

Zabbix

https://www.zabbix.com/download

Graphite

https://logz.io/blog/grafana-vs-graphite/

[작업로그] DB Data Migration

Tue, 08 Dec 2020 00:00:00 GMT

#. 동일한 구조의 테이블 또는 다른 구조의 테이블에 select 한 내용을 insert 하는 방법

1. select 한 내용의 전체 컬럼 insert

select 테이블과 insert할 테이블의 구조가 일치해야 한다.
```
INSERT INTO [table] SELECT * FROM [table] WHERE [조건];
```

2. 원하는 컬럼만 select 해서 insert

특정 컬럼을 직접 선택해서 insert하는 방법

INSERT INTO [table] (column1, colum2, colum3) 
SELECT column1, colum2, colum3 FROM [table] WHERE [조건];

#. 조건에 따라 값을 지정해주는 Case 문

1. 여러 조건 비교

//Case
//    WHEN 조건1 THEN 출력1 
//    WHEN 조건2 THEN 출력2
//    ELSE 출력3
//END

SELECT 
    case 
        when sal >=0 and sal <= 1000 then 'E'
        when sal > 1000 and sal <= 2000 then 'D'
        when sal > 2000 and sal <= 3000 then 'C'
        when sal > 3000 and sal <= 4000 then 'B'
        when sal > 4000 and sal <= 5000 then 'A'
    end as sal_rank 
FROM table_name;

2. 특정 컬럼의 값으로 비교

//Case 컬럼명
//    WHEN 값1 THEN 출력1 
//    WHEN 값2 THEN 출력2
//    ELSE 출력3
//END

SELECT 
    case department
        when 'back-end' then 'BE'
        when 'front-end' then 'FE'
        when 'user-interface' then 'UI'
        else 'ETC'
    end as department_alias 
FROM table_name;

#. 작업내용

변경사항이 없는 테이블의 경우

insert into autocrypt_v2g_prod.table_name 
select * from autocrypt_v2g_1208.table_name order by created
;

CA_CERT 테이블 Migration

컬럼에 변경사항이 있는 경우, 각 컬럼을 명시
case 문으로 타입이 변경 된 컬럼 해결
bulk insert 가 되므로 한 row가 insert 될때마다 commit이 되지 않으므로 자신 테이블의 id를 참조하는 issuer_id는 NULL로 insert/commit 후 update문 실행

insert into autocrypt_v2g_prod.ca_cert
	(created, created_by, updated, updated_by,
	actor, cert, not_after, not_before, serial, subject_dn, ak_id, sk_id, path_length, provider_id, 
	
	wca_id,
	
	valid,
	last_issued,
	
	issuer_id )
select
	s.created, '' as created_by, s.updated, '' as updated_by,
	s.actor, s.cert, s.not_after, s.not_before, s.serial, s.subject_dn, s.ak_id, s.sk_id, s.path_length, s.provider_id,
	
    s.id as wca_id,
	
	case s.status when 'VALID' then true else false end as valid ,
	case s.last_issued when '1' then true else false end as last_issued,	
	
    NULL as issuer_id
from autocrypt_v2g_1208.ca_cert s order by s.created
;

update 
autocrypt_v2g_prod.ca_cert target,
(select
	s.id as id,
	(select t.id from autocrypt_v2g_prod.ca_cert t where t.wca_id = s.issuer_id) as issuer_id
from autocrypt_v2g_1208.ca_cert s order by s.created) result
set target.issuer_id = result.issuer_id
where target.wca_id = result.id
;

값이 잘못 들어 갔을 경우 id의 sequence 까지 (autoincrement) 초기화 하기 위해 truncate문 사용

truncate autocrypt_v2g_prod.tableName;

[PKI] issuer private key로 서명

Thu, 26 Nov 2020 00:00:00 GMT

서명로직 코드

WCA ServerKey로 암호화 + base64 인코딩된 mo sub2 private key 복호화 후 서명

    // private key 로 직접 서명
    String base64EncodedMoSub2PrivKey = "n2iWb4B7ES9Hc7HmAHvW5RMAAGUhwAJ3hOIUuqH9r9y5l4IGzg9nQfXxocKwJDIBSC/x67JcxNA6aALuz0gd+IQby7TTTfB74sxWSNjZUV67Xup0kPOx3wOWrxmO1R2/qGUkwflm3shSbz3YoWaavzipuYKen/6pBQ5kmKzONPFh+1Nprq34hY2lccf38QRp/aGXNbXvxRZcPsYGU5HIIw==";
    String caServerKey = "_u5PJineTniFyvQmHkWP6g";
    byte[] moSub2PrivateKeyByte = aesDecode(Base64.decode(base64EncodedMoSub2PrivKey), caServerKey);
    PrivateKey moSub2PrivateKey = PkiFactory.privateKeyByteToClass(moSub2PrivateKeyByte);

    SignatureType signature = new SignatureType();
    signature.setSignedInfo(signedInfo);
    JAXBElement<SignedInfoType> signedInfoJAXB = ObjectFactory.createSignedInfo(signedInfo);

    SignatureValueType signatureValue = new SignatureValueType();
    java.security.interfaces.ECPrivateKey ecPrivateKey = (java.security.interfaces.ECPrivateKey) moSub2PrivateKey;
    signatureValue.setValue(MsgFactory.signSignedInfoElement(signedInfoJAXB, ecPrivateKey));
    signature.setSignatureValue(signatureValue);

    byte[] signatureXmlByte = MsgFactory.marshalToByteArray(signature, SignatureType.class);
    String signatureXmlStr = new String(signatureXmlByte);

  private byte[] aesDecode(byte[] data, String secretKey) {
    final byte[] IV = Hex.decode("62EC67F9C3A4A407FCB2A8C49031A8B3");
    // TODO 16byte 넘어가는경우 자르지 말고, 16byte 길이를 유지할수 있는방법을 찾아봐야함.
    try {
      String password = secretKey.length() < 16 ? StringUtils.leftPad(secretKey, 16)
        : StringUtils.substring(secretKey, 0, 16);
      Key key = new SecretKeySpec(password.getBytes(), "AES");
      Cipher c = Cipher.getInstance("AES/CBC/PKCS7Padding", BouncyCastleProvider.PROVIDER_NAME);
      c.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec(IV));
      return c.doFinal(data);
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
  }

  public static PrivateKey privateKeyByteToClass(byte[] privKey) throws NoSuchProviderException, NoSuchAlgorithmException, InvalidKeySpecException {
    KeyFactory kf = KeyFactory.getInstance("EC", BouncyCastleProvider.PROVIDER_NAME);
    PrivateKey privateKey = kf.generatePrivate(new PKCS8EncodedKeySpec(privKey));
    return privateKey;
  }

[PKI] OCSP Request 생성

Wed, 25 Nov 2020 00:00:00 GMT

HashAlgorithm 에 따른 OCSP Request 생성 방법

SHA-1

id-sha1

    X509Certificate cert = PkiFactory.x509StringToClass("MIICmzCCAkGgAwIBAgIGAOjUpRAeMAoGCCqGSM49BAMCMEAxCzAJBgNVBAYTAktSMQwwCgYDVQQKDANITUMxDDAKBgNVBAsMA0hNQzEVMBMGA1UEAwwMSE1DX01PU3ViQ0EyMB4XDTIwMTEyNDEyNTk1N1oXDTIyMTEyNDE0NTk1OVowQzELMAkGA1UEBhMCS1IxDDAKBgNVBAoMA0hNQzEMMAoGA1UECwwDSE1DMRgwFgYDVQQDDA9LUkVWUDAwMDAwMDA1QVgwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQaoaM2ufpGTDqLVDPOYKJYeKb65vJ36EXY/zsTh/9EYi8yzPSQTrm0blb3s74YsvZ9BUJfDdX6Hh0X5gFTrugLo4IBIjCCAR4waAYDVR0jBGEwX4AULT3vADHec7fHnQwHDR1BvaZI8dihRKRCMEAxCzAJBgNVBAYTAktSMQwwCgYDVQQKDANITUMxDDAKBgNVBAsMA0hNQzEVMBMGA1UEAwwMSE1DX01PU3ViQ0ExggEwMB0GA1UdDgQWBBSHpsbH4R8RnTS3EDJ/8lS46eBRAzAOBgNVHQ8BAf8EBAMCA+gwRQYDVR0fBD4wPDA6oDigNoY0Y249ZHBfVmZ0Y05Ec3RRd21jYXg0TkZfZ3FmUXAwLG91PUhNQyxvPUhNQyxjPUtSLmNybDA8BggrBgEFBQcBAQQwMC4wLAYIKwYBBQUHMAGGIGh0dHA6Ly8xMjcuMC4wLjE6ODA4OS9PQ1NQU2VydmVyMAoGCCqGSM49BAMCA0gAMEUCIQDa2APe7zqfBBXBUtWjhwAkxxqJNiMHdnnGWRKL3/tdMgIgDuwTB/iByJO4uf+Mx/Sfs+vs5Snhi6DQ0A4lJyQLL1E=");
    X509Certificate issuerCert = PkiFactory.x509StringToClass("MIIB0zCCAXmgAwIBAgIBMDAKBggqhkjOPQQDAjBAMQswCQYDVQQGEwJLUjEMMAoGA1UECgwDSE1DMQwwCgYDVQQLDANITUMxFTATBgNVBAMMDEhNQ19NT1N1YkNBMTAeFw0yMDExMDQxNTAwMDBaFw0yMjExMDQxNTAwMDBaMEAxCzAJBgNVBAYTAktSMQwwCgYDVQQKDANITUMxDDAKBgNVBAsMA0hNQzEVMBMGA1UEAwwMSE1DX01PU3ViQ0EyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQevrFh4ZAsgrxz7mKT1igUUbiXnH5Yyj2bw7Fo07hluYWxtFQd8TYwwm5IYkudRNygj69OspvAQf0NdnonQ5BqNkMGIwDgYDVR0PAQH/BAQDAgHGMBIGA1UdEwEB/wQIMAYBAf8CAQAwPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vMTI3LjAuMC4xOjgwODkvT0NTUFNlcnZlcjAKBggqhkjOPQQDAgNIADBFAiEA7EU/OnEAChywBv+1RLh3mScq6HX9pGdQJl4wAzKMFGsCIBVKjvuqiQoaabi2s+9nLsLLLXO1hEElmJc/2noaB0FH");
    X509CertificateHolder issuerCertHolder = new X509CertificateHolder(issuerCert.getEncoded());

    DigestCalculator digestCalculator = new BcDigestCalculatorProvider().get(CertificateID.HASH_SHA1);
    CertificateID id = new CertificateID(digestCalculator, issuerCertHolder, cert.getSerialNumber());

    VerifyContractByOcspReq req = new VerifyContractByOcspReq(
      emaid,
      new OcspData[]{
        OcspData.builder()
          .hashAlgorithm("SHA1")
          .issuerNameHash(Base64.toBase64String(id.getIssuerNameHash()))
          .issuerKeyHash(Base64.toBase64String(id.getIssuerKeyHash()))
          .serialNumber(id.getSerialNumber().toString())
          .build()
      });

SHA-256

id-sha256 에 대한 정의를 못찾아서 직접 OID를 넣는 방법을 택

    X509Certificate cert = PkiFactory.x509StringToClass("MIICmzCCAkGgAwIBAgIGAOjUpRAeMAoGCCqGSM49BAMCMEAxCzAJBgNVBAYTAktSMQwwCgYDVQQKDANITUMxDDAKBgNVBAsMA0hNQzEVMBMGA1UEAwwMSE1DX01PU3ViQ0EyMB4XDTIwMTEyNDEyNTk1N1oXDTIyMTEyNDE0NTk1OVowQzELMAkGA1UEBhMCS1IxDDAKBgNVBAoMA0hNQzEMMAoGA1UECwwDSE1DMRgwFgYDVQQDDA9LUkVWUDAwMDAwMDA1QVgwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQaoaM2ufpGTDqLVDPOYKJYeKb65vJ36EXY/zsTh/9EYi8yzPSQTrm0blb3s74YsvZ9BUJfDdX6Hh0X5gFTrugLo4IBIjCCAR4waAYDVR0jBGEwX4AULT3vADHec7fHnQwHDR1BvaZI8dihRKRCMEAxCzAJBgNVBAYTAktSMQwwCgYDVQQKDANITUMxDDAKBgNVBAsMA0hNQzEVMBMGA1UEAwwMSE1DX01PU3ViQ0ExggEwMB0GA1UdDgQWBBSHpsbH4R8RnTS3EDJ/8lS46eBRAzAOBgNVHQ8BAf8EBAMCA+gwRQYDVR0fBD4wPDA6oDigNoY0Y249ZHBfVmZ0Y05Ec3RRd21jYXg0TkZfZ3FmUXAwLG91PUhNQyxvPUhNQyxjPUtSLmNybDA8BggrBgEFBQcBAQQwMC4wLAYIKwYBBQUHMAGGIGh0dHA6Ly8xMjcuMC4wLjE6ODA4OS9PQ1NQU2VydmVyMAoGCCqGSM49BAMCA0gAMEUCIQDa2APe7zqfBBXBUtWjhwAkxxqJNiMHdnnGWRKL3/tdMgIgDuwTB/iByJO4uf+Mx/Sfs+vs5Snhi6DQ0A4lJyQLL1E=");
    X509Certificate issuerCert = PkiFactory.x509StringToClass("MIIB0zCCAXmgAwIBAgIBMDAKBggqhkjOPQQDAjBAMQswCQYDVQQGEwJLUjEMMAoGA1UECgwDSE1DMQwwCgYDVQQLDANITUMxFTATBgNVBAMMDEhNQ19NT1N1YkNBMTAeFw0yMDExMDQxNTAwMDBaFw0yMjExMDQxNTAwMDBaMEAxCzAJBgNVBAYTAktSMQwwCgYDVQQKDANITUMxDDAKBgNVBAsMA0hNQzEVMBMGA1UEAwwMSE1DX01PU3ViQ0EyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQevrFh4ZAsgrxz7mKT1igUUbiXnH5Yyj2bw7Fo07hluYWxtFQd8TYwwm5IYkudRNygj69OspvAQf0NdnonQ5BqNkMGIwDgYDVR0PAQH/BAQDAgHGMBIGA1UdEwEB/wQIMAYBAf8CAQAwPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vMTI3LjAuMC4xOjgwODkvT0NTUFNlcnZlcjAKBggqhkjOPQQDAgNIADBFAiEA7EU/OnEAChywBv+1RLh3mScq6HX9pGdQJl4wAzKMFGsCIBVKjvuqiQoaabi2s+9nLsLLLXO1hEElmJc/2noaB0FH");
    X509CertificateHolder issuerCertHolder = new X509CertificateHolder(issuerCert.getEncoded());

    AlgorithmIdentifier HASH_SHA256 = new AlgorithmIdentifier(new ASN1ObjectIdentifier("2.16.840.1.101.3.4.2.1"), DERNull.INSTANCE);
    DigestCalculator digestCalculator = new BcDigestCalculatorProvider().get(HASH_SHA256);

    CertificateID id = new CertificateID(digestCalculator, issuerCertHolder, cert.getSerialNumber());

    VerifyContractByOcspReq req = new VerifyContractByOcspReq(
      emaid,
      new OcspData[]{
        OcspData.builder()
          .hashAlgorithm("SHA256")
          .issuerNameHash(Base64.toBase64String(id.getIssuerNameHash()))
          .issuerKeyHash(Base64.toBase64String(id.getIssuerKeyHash()))
          .serialNumber(id.getSerialNumber().toString())
          .build()
      });

[Gradle] 테스트 없이 빌드

Tue, 24 Nov 2020 00:00:00 GMT

$ gradle build --exclude-task test

[스프링 핵심 원리 리뷰] Container Bean 생성

Sat, 14 Nov 2020 00:00:00 GMT

# 스프링 컨테이너 생성

ApplicationContext applicationContext 
      = new AnnotationConfigApplicationContext(AppConfig.class);

# 스프링 빈 등록

빈 이름은 메서드 이름을 사용
빈 이름을 직접 부여할 수도 있다 @Bean(name”memberService2”)

# 스프링 빈 조회

  AnnotationConfigApplicationContext ac 
          = new AnnotationConfigApplicationContext(AppConfig.class);
  @Configuration
  static class AppConfig {
    @Bean
    public DataService dataService() {
      return new DataServiceImpl();
    }
  }

  @Test
  @DisplayName("빈 이름으로 조회")
  void findBeanByName() {
    DataService dataService = ac.getBean("dataService", DataService.class);
    assertThat(dataService).isInstanceOf(DataServiceImpl.class);
  }

  @Test
  @DisplayName("이름 없이 타입으로만 조회")
  void findBeanByType() {
    DataService dataService = ac.getBean(DataService.class);
    assertThat(dataService).isInstanceOf(DataServiceImpl.class);
  }

  @Test
  @DisplayName("구체 타입으로 조회")
  void findBeanByImplName() {
    // 좋은 코드는 아니다.
    // 항상 역활과 구현을 구분해야 한다.
    // 그리고 역할에 의존해야 한다.
    DataService dataService = ac.getBean("dataService", DataServiceImpl.class);
    assertThat(dataService).isInstanceOf(DataServiceImpl.class);
  }

  @Test
  @DisplayName("빈 이름으로 조회 실패")
  void findBeanByNameX() {
    assertThrows(NoSuchBeanDefinitionException.class, 
        () -> ac.getBean("xxx", DataService.class));
  }

스프링 빈 조회 - 상속관계

부모 타입으로 조회하면 자식 타입도 함께 조회
Object 타입으로 조회하면 모든 스프링 빈을 조회

AnnotationConfigApplicationContext acExtends = 
          new AnnotationConfigApplicationContext(TestConfig.class);
  @Configuration
  static class TestConfig {
    @Bean
    public DataPolicy rateDataPolicy() {
      return new RateDataPolicy();
    }
    @Bean
    public DataPolicy fixDataPolicy() {
      return new FixDataPolicy();
    }
  }

  @Test
  @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 중복 오류가 발생한다.")
  void findBeanByParentTypeDuplicate() {
    assertThrows(NoUniqueBeanDefinitionException.class,
      () -> acExtends.getBean(DataPolicy.class));
  }

  @Test
  @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 빈 이름을 지정하면 된다.")
  void findBeanByParentTypeBeanName() {
    RateDataPolicy rateDataPolicy = acExtends.getBean("rateDataPolicy", RateDataPolicy.class);
    assertThat(rateDataPolicy).isInstanceOf(RateDataPolicy.class);
  }

  @Test
  @DisplayName("특정 하위 타입으로 조회")
  void findBeanBySubType() {
    RateDataPolicy rateDataPolicy = acExtends.getBean(RateDataPolicy.class);
    assertThat(rateDataPolicy).isInstanceOf(RateDataPolicy.class);
  }

  @Test
  @DisplayName("부모 타입으로 모두 조회하기")
  void findAllBeanByParentType() {
    Map<String, DataPolicy> beansOfType = acExtends.getBeansOfType(DataPolicy.class);
    assertThat(beansOfType.size()).isEqualTo(2);

    for (String key : beansOfType.keySet()) {
      System.out.println("key = " + key + " value = " + beansOfType.get(key));
    }
  }

[스프링 핵심 원리 리뷰] Singleton Container

Sat, 14 Nov 2020 00:00:00 GMT

스프링 없는 순수한 DI 컨테이너

요청시마다 객체를 새로 생성한다

@Configuration
  static class AppConfig {
    @Bean
    DataService dataService() {
      return new DataServiceImpl();
    }
  }

  @Test
  @DisplayName("스프링 없는 순수한 DI 컨테이너")
  void pureContainer() {
    AppConfig appConfig = new AppConfig();

    // 호출시마다 객체를 생성
    DataService dataService1 = appConfig.dataService();
    DataService dataService2 = appConfig.dataService();

    // 참조값이 다른 것을 확인
    assertThat(dataService1).isNotSameAs(dataService2);
  }

싱글톤 컨테이너

스프링 컨테이너 덕분에 요청시마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 재사용한다.
스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.
이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.

@Test
  @DisplayName("스프링 컨테이너와 싱글톤")
  void springContainer() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    DataService dataService1 = ac.getBean("dataService", DataService.class);
    DataService dataService2 = ac.getBean("dataService", DataService.class);

    // 참조값이 동일한 것을 확인
    assertThat(dataService1).isSameAs(dataService2);
  }

싱글톤 방식의 주의점

무상태(stateless)로 설계해야 한다.

[스프링 핵심 원리 리뷰] @Configuration

Sat, 14 Nov 2020 00:00:00 GMT

# @Configuration과 바이트코드 조작의 마법

@Configuration 사용 시 ‘CGLIB’ 라는 바이트코드 조작 라이브러리를 사용하여 클래스 구성한다.
때문에 여러 곳에서 특정 Bean의 객체 생성을 유도하더라도 싱글톤이 보장되도록 해준다.

@Configuration
public class AppConfig {

  @Bean
  public MemberService memberService() {
    System.out.println("call AppConfig.memberService");
    return new MemberServiceImpl(memberRepository());
  }

  @Bean
  public OrderService orderService() {
    System.out.println("call AppConfig.orderService");
    return new OrderServiceImpl(memberRepository());
  }
 
  @Bean
  public MemberRepository memberRepository() {
    System.out.println("call AppConfig.memberRepository");
    return new MemoryMemberRepository();
  }
}

출력결과

call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService

# AppConfig@CGLIB 예상 코드

@Bean
public DataService dataService() {
  if(dataService 가 이미 스프링 컨테이너에 등록되어 있으면)
    return 스프링 컨테이너에서 찾아서 변환;
  else {
    기존 로직을 호출하여 dataService를 생성하고 스프링 컨테이너에 등록
    return 반환
  }
}

@Configuration 삭제 시 출력결과는

call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository
call AppConfig.memberRepository

@RequestBody, @ResponseBody

Tue, 10 Nov 2020 00:00:00 GMT

1. 자바 직렬화 (Serialize)

            Deserialize                   Serialize
Byte Data ---------------> Java Object ---------------> Byte Data

2. @RequestBody, @ResponseBody

@RequestBody 어노테이션과 @ResponseBody 어노테이션은 각각 HTTP 요청 몸체를 자바 객체로 변환하고 자바 객체를 HTTP 응답 몸체로 변환하는 데 사용된다.

3. HttpMessageConverter를 이용한 변환 처리

AnnotationMethodHandlerAdapter 클래스는 @RequestBody 어노테이션이 적용된 파라미터나 @ResponseBody 어노테이션이 적용된 메서드에 대해 HttpMessageConverter를 사용해서 변환을 처리한다. 주요 HttpMessageConverter 구현 클래스는 다음과 같다.

구현 클래스	설 명
ByteArrayHttpMessageConverter	HTTP 메시지와 byte 배열 사이의 변환을 처리한다. 컨텐츠 타입은 application/octet-stream이다.
StringHttpMessageConverter	HTTP 메시지와 String 사이의 변환을 처리한다. 컨텐츠 타입은 text/plain;charset=ISO-8859-1이다.
FormHttpMessageConverter	HTML 폼 데이터를 MultiValueMap으로 전달받을 때 사용된다. 지원하는 컨텐 츠 타입은 application-x-www-form-urlencorded이다.
SourceHttpMessageConverter	HTTP 메시지와 javax.xml.transform.Source 사이 변환을 처리한다. 컨텐츠 타 입은 application/xml 또는 text/xml이다.
MarshallingHttpMessageConverter	스프링의 Marshaller와 unMarshaller를 이용해서 XML HTTP 메시지와 객체 사 이의 변환을 처리한다. 컨텐츠 타입은 application/xml 또는 text/xml이다.
MappingJacksonHttpMessageConverter	Jackson 라이브러리를 이용해서 JSON HTTP 메시지와 객체 사이의 변환을 처 리한다. 컨텐츠 타입은 applicaion/json이다.

DTO 클래스?

Tue, 10 Nov 2020 00:00:00 GMT

DTO

Data Transfer Object
각 레이어 사이에 데이터를 전달하기 위한 목적으로 사용하는 Object
View Layer와 DB Layer의 역할 분리를 하기위함으로 사용
- API의 req와 res에 맞게 domain이 수정될 필요 없다.
- req, res에 불필요한 properties 가 들어가지 않는다.
필수 값에 대한 조건 체크하는 것이나 DTO 에서 Domain 으로 변환하거나, Domain 에서 DTO 로 변환하는 로직은 Domain 이 아닌 DTO 에 담겨야 한다.
@NotNull 과 같은 Data 의 Validation 도 DTO 의 역할 이기 때문에 DTO 에 넣어주게 되면 역할과 책임이 좀 더 명백해지게 된다.

[Code Convention] DTO Class

Tue, 10 Nov 2020 00:00:00 GMT

DTO Class Code Convention

#1.클래스 정의 방법

도메인 또는 리소스 별 DTO 클래스 생성 후(CouponDto), 각 API(Controller 에 정의된 메소드: CreateReq, CreateRes) 에 해당하는 DTO를 InnerClass 로 정의
CouponDto의 객체 생성을 하지 않으므로 InnerClass는 static 키워드를 명시한다.

#2.생성자의 접근자는 최소한으로

객체 생성이 불필요한 클래스의 기본 생성자 접근자는 Private로 지정
—> 개별 DTO는 InnerClass로 정의하기 때문에 객체 생성이 불필요하다.

#3. Request Dto 클래스

##3-1. @NoArgsConstructor 의 접근자는 Private로 한다.

@RequestBody 를 사용하면 Spring 내부에서 Jackson 라이브러리를 사용하여 Deserialize (JSON 데이터와 Request 객체 사이의 변환) 을 한다.
이때 기본 전략으로 Default Constructor + Reflection 을 사용한다. 이때 최소 접근자는 Private 이다.

##3-2. Data Validation

Bean Validation에서 제공하는 @NotNull, @NotBlank, @Pattern 등을 사용하여 Request Data에 대한 오류를 최소화 한다.
꼭 @RequestBody 옆에 @Valid 를 명시해줘야 한다.
Validation이 실패할 경우, MethodArgumentNotValidException 의 예외가 발생한다.

#4. Response Dto 클래스

##4-1. 객체 생성을 위해 필드가 3개 이상일 경우는 @Builder를 사용한다.

@Builder 사용 시 All Arguments Constructor 가 자동으로 생성된다.
생성자를 이용한 객체 생성을 막기 위해 생성자를 따로 정의한 후(@AllArgsConstructor) 접근제어자를 Private로 정의한다.

##4-2. 객체 생성을 위해 필드가 3개 이상일 경우는 @Builder를 사용한다.

##4-3. @Getter 필요 이유

@ResponseBody 를 사용하면 Spring 내부에서 Jackson 라이브러리를 사용하여 Response 객체를 Serialize(ByteCode로 변환) 하는데 이때 getter 메소드를 사용한다.
따라서 response 객체는 @Getter 를 사용해야 한다.

MapStruct

DTO -> Entity, Entity -> DTO의 객체 매핑을 위한 라이브러리

#1. gradle 추가

롬복과 함께 사용 시, lombok annotationProcessor 보다 mapstruct annotationProcessor가 먼저 선언이 되야 한다.
SpringBoot 버전에 호환하는 MapStruct 버전이 존재, 해당부분 확인 필요

#2. Mapper Interface 생성

##2-1. @Mapper 사용

매핑 정책(Policy)과 전략(Strategy)를 설정할 수 있다.

정책	값	설명	예시
unmappedSourcePolicy	IGNORE(default), WARN, ERROR	Source의 필드가 Target에 매핑되지 않을 때 정책이다.	ERROR로 설정하면 매핑 시 Source.aField가 사용되지 않는다면 컴파일 오류가 발생시킨다.
unmappedTargetPolicy	IGNORE, WARN(default), ERROR	Target의 필드가 매핑되지 않을 때 정책이다.	ERROR로 설정하면 매핑 시 Target.aField에 값이 매핑되지 않는다면 컴파일 오류가 발생시킨다.
typeConversionPolicy	IGNORE(default), WARN, ERROR	타입 변환 시 유실이 발생할 수 있을 때 정책이다.	ERROR로 설정하면 long에서 int로 값을 넘길 때 값에 유실이 발생할 수 있다. 이런 경우에 컴파일 오류를 발생시킨다.

전략	값	설명
nullValueMappingStrategy	RETURNNULL(default), RETURNDEFAULT	Source가 null일 때 정책이다.
nullValuePropertyMappingStrategy	SETTONULL(default), SETTODEFAULT, IGNORE	Source의 필드가 null일 때 정책이다.

##2-2. INSTANCE 생성

빌드 시점에 CouponMapper 를 상속받은 CouponMapperImpl(구현체) 클래스가 생성된다.
따라서 이 구현체를 사용할 수 있는 객체를 생성한다.

#3. Mapper 사용

#3-1. Dto to Entity 또는 Entity to Dto 선언부 생성

#3-2. @Getter, @Builder 설정

변환과정에서 꺼내오는 객체(source)에는 Getter가 있어야 하고, 변환해서 저장하고자 하는 객체(target)에는 Builder 혹은 Setter가 있어야 하는데 Setter는 지양한다.

201203 수정사항

Dto 클래스 내 Mapper 호출 메소드 명 변경
—> createReqToEntity() -> toEntity()
—> entityToCreateRes() -> of()
Response Dto 클래스 내 Validation 제거
— res Dto 클래스 serialize 전 validation 로직 없음
MethodArgumentNotValidException 이미지 추가

[SpringBoot]RequestBody Validation

Tue, 10 Nov 2020 00:00:00 GMT

Bean Validation (Hibernate Validation) 에서 제공하는 표준 Validation

사용법 : @AnnotationName(message=“Exception Message”)
validation 이 실패 할 경우, MethodArgumentNotValidException 의 예외가 발생.
이처럼 이러한 Validation 을 용도 및 상황에 맞게 사용한다면 사용자의 오류나 시스템의 오류를 최소화 할 수 있다.

Bean Validator	설명
@NotNull	Null만 허용안함, "" 이나 ” ” 일 경우 예외
@NotEmpty	Null, "" 허용 안함, ” ” 일 경우 예외
@NotBlank	Null, "", ” ” 일 경우 예외 (String 객체에서 주로 사용)
@Min(숫자)	최소값
@Max(숫자)	최대값
@Size(min=숫자, max=숫자)	Max, Min 모두 포함
@Email	이메일 형식이 아닌 경우 예외 발생
@Pattern(regexp = “정규식”)

참고) https://beanvalidation.org/2.0/spec/

Lombok - Can not find symbol

Tue, 10 Nov 2020 00:00:00 GMT

문제

Dto 클래스에 @Builder 사용 시 builder() 메소드를 찾을 수 없다는 에러 발생

원인

Lombok의 어노테이션을 사용할 경우 컴파일 시 어노테이션을 먼저 스캔해서 코드(getter, setter 등)로 변환해주는 선처리가 필요 또는 IntelliJ에서 “Enable annotation processing” 을 활성화

AnnotationProcessor?

어노테이션 프로세싱은 자바 컴파일러의 컴파일 단계에서, 유저가 정의한 어노테이션의 소스코드를 분석하고 처리하기 위해 사용되는 훅이다. 컴파일 에러나 컴파일 경고를 만들어내거나, 소스코드(.java)와 바이트코드(.class)를 내보내기도 한다.

해결

build.gradle 에 annotationProcessor 추가

annotationProcessor 'org.projectlombok:lombok'
testAnnotationProcessor 'org.projectlombok:lombok' // 테스트 코드에서 lombok 사용 시

- 2. IntelliJ File -> Settings 에서 아래 그림과 같이 설정
![](./001-03.PNG)

/etc/logrotate.d 설정하기

Fri, 06 Nov 2020 00:00:00 GMT

/home/jenkins/workspace/V2G-Prod-Server/logs/*log 
/home/jenkins/workspace/V2G-Dev-Server/logs/*log {
    daily                                         
    compress                                      
    dateext                                       
    maxage 365                                    
    notifempty                                    
    missingok                                     
    copytruncate                                  
}

옵션	설명
`rotate 숫자`	log 보관 갯수 ex) rotate 5 : log파일이 5개 이상시 삭제
`maxage 숫자`	log 파일 생명 주기 ex) maxage 20 : 20일 경과시 삭제
`size`	지정된 용량보다 클 경우 로테이트 실행 ex) size +100k : 100k 이상 시 로테이트
`daily`	일 단위 파일순환
`weekly`	주 단위 파일순환
`monthly`	월 단위 파일순한
`missingok`	파일이 없어도 상관없음(에러가 아니도록 처리)
`notifempty`	로그내용이 없으면 로테이트 안함
`ifempty`	로그 내용이 없어도 로테이트 진행
`compress`	로그파일을 gzip으로 압축하여 보관
`nocompress`	압축 안함
`dateext`	rotate된 로그파일명에 날짜 표시
`dateyesterday`	dateext 옵션과 함께 쓰면 파일명의 날짜에 어제 날짜로 저장
`copytruncate`	이 옵션을 넣지 않으면 현재 사용중인 로그를 다른이름으로 move하고 새로운 파일을 생성한다

# logrotate 수행

설정파일의 오류확인 - debug 모드로 실제 로테이션은 되지 않음
```
$ /usr/sbin/logrotate -d /etc/logrotate.d/v2g
```

설정파일을 강제수행

$ /usr/sbin/logrotate -f /etc/logrotate.d/v2g

# Cron 등록

syslog가 순환되고 있는 것은 cat /etc/cron.daily/logrotate 파일에 정의되어 crontab에서 실행되고 있다. 로테이션을 위해 생성한 /data/logs/test_logrotate 파일을 /etc/logrotate.d/ 하위에 두면 rsyslog가 로테이션되는 시간에 같이 로테이션 된다. 또는 해당 원하는 시간에 crontab에 추가하여 별도 관리하여도 된다. 1일치 로그로 관리하기 위하여 0시에 순환되도록 아래와 같이 설정한다.

$ sudo crontab -e

0 0 * * * /usr/sbin/logrotate -f /etc/logrotate/v2g

[MariaDB] DB 백업 및 복구

Fri, 06 Nov 2020 00:00:00 GMT

백업(Export)

// 전체 DB 백업 
// mysqldump -u [DB계정명] -p -A > [저장할 파일명]
// mysqldump -u [DB계정명] -p --all-databases > [저장할 파일명]
$ mysqldump -u root -p -A > all.sql

// 특정 DB 백업 
// mysqldump -u [계정명] -p [DB명] > [저장할 파일명]
$ mysqldump -u root -p v2g > v2g.sql

// 생성 스크립트만 백업
// mysqldump -u [계정명] -p -d [DB명] > [저장할 파일명]
// mysqldump -u [계정명] -p --no-data [DB명] > [저장할 파일명]
$ mysqldump -u root -p -d v2g > v2g_ddl.sql

// 특정 Table 백업
// mysqldump -u [계정명] -p [DB명] [Table명] > [저장할 파일명]
$ mysqldump -u root -p v2g ca_cert leaf_cert > v2g_certs.sql

// 특정 table 제외하고 백업
// mysqldump -u [계정명] -p [DB명] --ignore-table=[DB명].[테이블명] > [저장할 파일명]
$ mysqldump -u root -p v2g --ignore-table=v2g.ca_cert --ignore-table=v2g.leaf_cert > v2g_ignore_certs.sql

복구(Import)

// mysqldump -u [DB계정명] -p [DB명] < [불러올 파일명]
$ mysqldump -u root -p v2g < v2g.sql

logrotate: because parent directory has insecure permissions

Fri, 06 Nov 2020 00:00:00 GMT

문제

logrotate 설정 후 강제 수행 시 오류 발생

원인

디렉토리의 권한이 너무 많아 insecure 하여 생긴 오류

해결

group, other write 권한을 제거

$ chmod 755 /home/jenkins/workspace/V2G-Dev-Server/logs

[CURL] curl 사용법

Thu, 05 Nov 2020 00:00:00 GMT

CURL ?
다양한 프로토콜을 지원하는 데이터 전송용 Command Line Tool 이다. (Http, Https, FTP, SFTP, SMTP 등을 지원)

GET

$ curl -d "key1=value&key2=value2" -H "Content-Type: application/x-www-form-urlencoded" -X GET http://localhost:8080/data"

POST

# x-www-form-urlencoded
$ curl -H "Content-Type: application/x-www-form-urlencoded" -d "key1=value&key2=value2" -X POST http://localhost:8080/data"

# application/json
$ curl -H "Content-Type: application/json" -d '{"key1":"value", "key2":"value2"} -X POST http://localhost:8080/data"

옵션 정리 http의 메소드를 지정 [ -X ]

$ curl -X [PUT|GET|POST] http://www.example.net

response header 확인 [ -I, i ]

# 헤더만 출력
$ curl -I http://www.example.net

# header와 body 둘다 출력
$ curl -i http://www.example.net

SSL 인증서 에러 무시 [ -k ]

$ curl -k https://www.example.net

output [ -o ]

$ curl -o /dev/null http://www.example.net

특정 포맷에 맞게 write [ -w ]

# status code 출력
$ curl -w '%{http_code}\n' http://www.example.net

진척상황 표시하지 않기 [ -s ]

# 에러도 표시되지 않음
$ curl -s https://www.example.net

# 에러는 표시
$ curl -sS https://www.example.net

프록시 이용시 [ -x, —proxy ]

$ curl --proxy <proxyip>:<port> http://www.example.net
$ curl -x <proxyip>:<port> http://www.example.net

$ curl -x <proxyip>:<port> --proxy-user <username>:<password> http://www.example.net
$ curl -x <username>:<password>@<proxyip>:<port> http://www.example.net

최대접속시간제한을 설정 [ —connect-timeout ]

$ curl --connect-timeout 600 http://www.example.net

Linux에서 tcp dump 확인

Wed, 04 Nov 2020 00:00:00 GMT

sudo tcpdump -vvX "dst port 15000"

# 자주사용하는 옵션

옵션	설명
-c [Number]	제시된 수의 패킷을 받은 후 종료한다.
-i [Device]	어느 인터페이스를 경유하는 패킷을 잡을지 지정한다. 지정되지 않으면 시스템의 인터페이스 리스트의 가장 낮은 번호를 가진 인터페이스를 선택(이 때 loopback은 제외)
-v, -vv	상세한 정보 출력
-w	캡처한 패킷을 파일에 저장한다
-r file	패킷들을 ‘-w’ 옵션으로 만들어진 파일로 부터 읽어 들인다.
-x, -XXX	각각의 패킷을 헥사 코드로 출력한다.

# Primitive

//packet의 IP destination 항목이  HOST 패킷일 때 출력.
$ tcpdump -i any dst host 10.10.10.1

//packet의 IP source항목이 HOST패킷일 때 출력.
$ tcpdump -i any src host 10.10.10.1

//IP source, IP destination 항목 중 어느 하나라도 HOST 패킷일 때 출력.
$ tcpdump -i any host 10.10.10.1

//패킷이 ip/tcp, ip/udp 프로토콜의 패킷이고 destination port의 값이 PORT일 때 출력.
$ tcpdump -i any src port 23

//패킷의 source port의 값으로 PORT를 가지면 출력.
$ tcpdump -i any dst port 23

//port PORT : 패킷의 source, destination port 중에 하나라도 PORT이면 출력.
$ tcpdump -i any port 23

예외 발생 시 트랜젝션 처리

Mon, 02 Nov 2020 00:00:00 GMT

-	Exception	RuntimeException
정의	Runtime Exception을 제외한 모든 Exception	Runtime Exception 하위 Exception
예외처리	명시적인 예외처리 필요	명시적인 예외처리를 강제하지 않음
시점	Compile Time	Runtime
트랜젝션 처리	non-rollback	rollback

#. @Transactional

CheckedException 의 경우 롤백이 되지 않고, RuntimeException 의 경우 롤백이 된다.

#. rollbackFor 옵션

롤백이 되는 클래스 지정 방법

// Exception 예외로 롤백 
@Transactional(rollbackFor = Exception.class)

// 여러 예외 지정 
@Transactional(rollbackFro = {RuntimeException.class, Exception.class})

#. noRollbackFor 옵션

특정 예외 발생 시 롤백이 되지 않도록 하는 방법

@Transactional(noRollbackFor={IgnoreRollbackException.class})

[AWS] key 분실 시

Sun, 01 Nov 2020 00:00:00 GMT

1. keypair 재 생성

2. 인스턴스 복제를 위해 이미지 생성 (인스턴스 정지 후 진행)

3. 인스턴스 새로 생성

Machine Image 선택시, 2번째 탭의 나의 AMI 선택 후 생성된 이미지 선택
인스턴스 생성 후 새로 생성한 key 선택

[PKI] PKCS 표준

Wed, 28 Oct 2020 00:00:00 GMT

공개 키 암호 표준

PKCS #7 — 암호화 데이터/ 전자서명
PKCS #10 : CSR
PKCS #12 : p12 or pfx
— 개인키와 인증서를 합쳐 암호화하고 인증서 소유자에게 송부 방법

[Vue] Keep Alive

Tue, 27 Oct 2020 00:00:00 GMT

keep-alive

keep-alive 는 비활성 컴포넌트 인스턴스를 파괴하지 않고 캐시한다.
keep-alive 를 사용하면 컴포넌트 인스턴스가 전역 큐에 저장되고, 활성화 될 때는 기존 컴포넌트를 사용하여 activated 라이프 사이클 hook이 호출되며, 비활성화시에는 인스턴스를 소멸시키지 않고 deactivated 라이프사이클 hook이 호출된다.
ref) https://learnvue.co/2019/12/an-overview-of-vue-keep-alive/ https://velog.io/@kyusung/VUE-keep-alive

destroy component cash

clearComponentCache: (param) => {
    const component = param.matched[0].instances.default;

    if (component && component.$vnode && component.$vnode.data.keepAlive) {
      if (component.$vnode.parent && component.$vnode.parent.componentInstance && component.$vnode.parent.componentInstance.cache) {
        if (component.$vnode.componentOptions) {
          const key = component.$vnode.key ? 
            component.$vnode.key :
            component.$vnode.componentOptions.Ctor.cid + (component.$vnode.componentOptions.tag ? `::${component.$vnode.componentOptions.tag}` : '');
          const cache = component.$vnode.parent.componentInstance.cache;
          const keys = component.$vnode.parent.componentInstance.keys;
          if (cache[key]) {
            if (keys.length) {
              const index = keys.indexOf(key);
              if (index > -1) {
                keys.splice(index, 1);
              }
            }
            delete cache[key];
          }
        }
      }
    }
  }

[작업로그] 이중로그인 방지 (Spring Security)

Tue, 20 Oct 2020 00:00:00 GMT

의문사항

같은 Session 에서 중복 로그인이 가능하다.
같은 Session 에서 중복 로그인 시 session id가 변경된다.
로그아웃 후에 다시 로그인을 하면 ‘이미 접속된 아이디’ 오류가 난다.
session 사용시 cookie 에 저장되는 JSESSIONID 에 대한 보안 이슈가 없는가

1. session 설정 내용

maximumSessions : 최대 세션 개수
maxSessionsPreventsLogin : 기존에 접속한 사용자가 있을 경우 기존 사용자의 접속을 끊고, 나중에 접속한 사용자가 접속되도록 한다.(default: false)

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
      protected void configure(HttpSecurity http) throws Exception {
        http.sessionManagement()
          .maximumSessions(1)
          .maxSessionsPreventsLogin(true)
          .sessionRegistry(sessionRegistry())
        ;
    }
}

2. DEBUG

chrome 에서 admin 계정으로 로그인 후(SessionId를 부여 받음) 새탭에서 다시 admin 계정으로 로그인을 하면

동일한 SessionId 에서 로그인 시도를 했기 때문에
ConcurrentSessionControlAuthenticationStrategy.onAuthentication() 에서 123라인의 allowableSessionsExceeded() 메소드(중복로그인 exception)를 호출하지 않고 종료가 된다.

CompositeSessionAuthenticationStrategy.onAuthentication() 에서 fixation 기본값 인 migrateSession에 의해 AbstractSessionFixationProtectionStrategy 가 delegate 된다. (89라인)

AbstractSessionFixationProtectionStrategy.onAuthentication() 에서 Session Fixation Attack 방지로 인해 NewSessionId가 생성된다.
즉, 동일 로그인ID ‘admin’ 으로 SessionId, NewSessionId 각 2개가 생성되었다.

탬 1, 탭2 의 브라우저 cookie 에는 마지막으로 생성된 NewSessionId가 부여되며, 기존 SessionId를 해제를 하지 못한 상태로 Client 에서 사라지게 된다.
즉, NewSessionId로 로그아웃을 하더라도 ‘admin’ 계정에 대한 SessionId가 존재하므로 재 로그인 시 중복된 로그인 에러가 뜨게 된다.

3. 해결방안 : sessionFixation - none

Session Fixation Attack 방지
악의적인 사용자가 사이트에 접근하기 위한 세션을 만들고, 그 세션을 통해 다른 사용자로 로그인 하려고 하는 경우(예를 들어, 세션에 ID를 파라미터로 포함하여 전송하는 경우) Session fixation attack의 잠재적인 위험이 존재하게 된다.
스프링 시큐리티는 이러한 공격을 자동으로 막기 위하여 사용자 로그인 때마다 새로운 세션을 생성한다.
이러한 방지 기능이 필요하지 않거나, 다른 기능들과 충돌이 발생할 경우에는, 의 session-fixation-protection 속성값으로 동작을 제어할 수 있다.
속성은 다음과 같은 세가지 옵션값들을 가진다.
동일 세션에서 로그인이 재발생해도 동일한 session id를 갖도록 한다.
동일 세션에서 중복 로그인 후 로그아웃하면 해당 로그인 id에 대한 세션이 해제가 되어 재 로그인이 가능하다.
none 으로 설정 시 호출되는 Session Strategy Class

// migrateSession : 새로운 세션을 생성하고 기존의 세션 값들을 새 세션에 복사해준다. 기본값으로 설정되어 있다.
// none : 아무것도 수행하지 않는다. 원래의 세션이 유지된다.
// newSession : "깨끗한" 새로운 세션을 생성한다. 기존의 세션데이터는 복사하지 않는다.

http.sessionManagement()
  .sessionFixation().none()
  .maximumSessions(1)
  .maxSessionsPreventsLogin(true)
  .sessionRegistry(sessionRegistry())

4. JSESSIONID 는 안전한가?

기본적으로 HttpOnly 를 사용
HttpOnly는 Set-Cookie HTTP 응답 헤더에 포함 된 추가 플래그
쿠키를 생성 할 때 HttpOnly 플래그를 사용하면 보호 된 쿠키에 액세스하는 클라이언트 측 스크립트의 위험을 완화하는 데 도움이됩니다
XSS ( 교차 사이트 스크립팅 ) 결함이 존재하고 사용자가이 결함을 악용하는 링크에 실수로 액세스하더라도 브라우저 (주로 Internet Explorer)는 쿠키를 제 3 자에게 공개하지 않는다.

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템70) 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

복구할 수 있는 상황이면 Checked Exception, 프로그래밍 오류거나 확실하지 않다면 Runtime Exception 을 예외로 던지자.

Exception vs Error

오류(Error)는 시스템에 비정상적인 상황이 생겼을 때 발생한다(JVM 자원 부족 등).
이는 시스템 레벨에서 발생하기 때문에 심각한 수준의 오류이다.
따라서 개발자가 미리 예측하여 처리할 수 없기 때문에, 애플리케이션에서 오류에 대한 처리를 신경 쓰지 않아도 된다.

오류가 시스템 레벨에서 발생한다면, 예외(Exception)는 개발자가 구현한 로직에서 발생한다.
즉, 예외는 발생할 상황을 미리 예측하여 처리할 수 있다.
즉, 예외는 개발자가 처리할 수 있기 때문에 예외를 구분하고 그에 따른 처리 방법을 명확히 알고 적용하는 것이 중요하다.

Exception

예외 클래스 구조

모든 예외클래스는 Throwable 클래스를 상속받고 있다
Error는 시스템 레벨의 심각한 수준의 에러이기 때문에 시스템에 변화를 주어 문제를 처리해야 하는 경우가 일반적이다.
Exception은 개발자가 로직을 추가하여 처리한다.
RuntimeException은 CheckedException과 UncheckedException을 구분하는 기준

Checked Exception VS Unchecked(Runtime) Exception

가장 명확한 구분 기준은 ‘꼭 처리를 해야 하느냐’이다.
Checked Exception이 발생할 가능성이 있는 메소드라면 반드시 로직을 try/catch로 감싸거나 throw로 던져서 처리해야 한다.
Unchecked Exception은 명시적인 예외처리를 하지 않아도 된다.

//Before
public void method() throws Exception {
  throw RuntimeException();
}

//After
public void method() {
  throw RuntimeException();
}

예외 처리 방법

1.예외 복구
예외복구의 핵심은 예외가 발생하여도 애플리케이션은 정상적인 흐름으로 진행된다는 것이다.

int maxretry = MAX_RETRY;  
while(maxretry -- > 0) {  
    try {
        // 예외가 발생할 가능성이 있는 시도
        return; // 작업성공시 리턴
    }
    catch (SomeException e) {
        // 로그 출력. 정해진 시간만큼 대기
    } 
    finally {
        // 리소스 반납 및 정리 작업
    }
}
throw new RetryFailedException(); // 최대 재시도 횟수를 넘기면 직접 예외 발생

2.예외처리 회피
호출한 쪽에서 다시 예외를 받아 처리하도록 하거나, 해당 메소드에서 이 예외를 던지는 것이 최선의 방법이라는 확신이 있을 때만 사용해야 한다.

public void add() throws SQLException {  
    ... // 구현 로직
}

3.예외 전환
호출한 쪽에서 예외를 받아서 처리할 때 좀 더 명확하게 인지할 수 있도록 돕기 위한 방법이다.
어떤 예외인지 분명해야 처리가 수월해지기 때문이다.
예를 들어 Checked Exception 중 복구가 불가능한 예외가 잡혔다면 이를 Unchecked Exception으로 전환하여서 다른 계층에서 일일이 예외를 선언할 필요가 없도록 할 수도 있다.

catch(SQLException e) {  
   ...
   throw DuplicateUserIdException();
}

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템69) 예외는 진짜 예외 상황에만 사용하라

예외는 예외 상황에서 쓸 의도로 설계되었다.
정상적인 제어 프름에서 사용해서는 안되며, 이를 프로그래머에게 강요하는 API를 만들어서도 안된다.

예외는 일상적인 제어 흐름용으로 쓰여선 안된다.

Good 코드와 같은 표준적이고 쉽게 이해되는 관용구를 사용해라

//Bad
try {
  int i=0;
  while(true)
    range[i++].climb();
} catch(ArrayIndexOutOfBoundsException e) {
}

//Good
for (Mountain m : range)
    m.climb();

정상적인 제어 흐름에서 예외를 사용할 일이 없어야 한다.

특정 상태에서만 호출할 수 있는 ‘상태 의존적’ 메서드를 제공하는 클래스는 ‘상태 검사’ 메서드도 함께 제공해야 한다.

‘상태 의존적’ 메서드 : Iterator의 next()
‘상태 검사’ 메서드 : Iterator의 hasNext()

상태 검사 메서드 대신 사용할 수 있는 선택지

Optional, 특정 값(null) ---계속

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템71) 필요 없는 검사 예외 사용은 피하라

API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.
복구가 가능하고 호출자가 그 처리를 해주길 바란다면, 우선 옵셔널을 반환해도 될지 고민하자.
옵셔널만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 에외를 던지자.

검사 예외 회피 방법

적절한 결과 타입을 담은 Optional 반환
— 검사 예외를 던지는 대신, 단순히 빈 옵셔널을 반환하자
— 단점은 예외가 발생한 이유를 담을 수 없다.
검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 변경
단점)
— 1. none thread-safe : actionPermitted와 action 호출 사이에 객체의 상태가 변할 수 있음
— 2. actionPermitted 가 action 메소드의 작업 일부를 중복 수행한다면 성능 손해

//검사 예외를 던지는 메서드
try {
  obj.action(args);
} catch(TheCheckedException e) {
 ... 예외 상황에 대처
}

//상태 검사 메서드와 비검사 예외를 던지는 메서드
if(obj.actionPermitted(args)) {
  obj.action(args);
} else {
  ... 예외 상황에 대처
}

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템72) 표준 예외를 사용하라

상황에 부합한다면 항상 표준 예외를 사용하자
더 많은 정보를 제공하길 원한다면 표준 예외를 확장해도 좋지만, 예외는 직렬화 할 수 있다는 사실을 기억하자

Exception, RuntimeException, Throwable, Error 는 직접 재사용하지 말자

이 예외들은 다른 예외들의 상위 클래스이므로 안정적으로 테스트가 불가능하다.

흔하게 재사용되는 예외

예외	주요쓰임
IllegalArgumentException	허용하지 않는 값이 인수로 건네졌을 때(null은 따로 NullPointerException으로 처리)
IllegalStateException	args가 무엇이든 객체가 메서드를 수행하기에 적절하지 않은 상태일 때
NullPointerException	null을 허용하지 않는 메서드에 null을 건넸을 때
IndexOutOfBoundsException	인덱스가 범위를 넘어섰을 때
ConcurrentModificationException	허용하지 않는 동시 수정이 발견됐을 때
UnSupportedOperationException	호출한 메서드를 지원하지 않을 때

java exceptions handling mechanism

All-in-one Catch — 항상 try 문 안에서 던져질 수 있는 특정 예외들에 해당하는 것들을 캐치하도록 하는 것이 좋다.
이런 방식은 우리가 각 예외타입별 다른 방식으로 예외를 핸들 할 수 있는 가능성을 제공 한다. 아무런 조치를 취할 수 없다면, RuntimeException 을 통해 변환하는게 좋을 것이다.
```
public void method() throws Exception {
doSomething();
}
```
ref) https://m.blog.naver.com/PostView.nhn?blogId=sthwin&logNo=220846528466&targetKeyword=&targetRecommendationCode=1

Best Practices for Custom Exceptions

Always Provide a Benefit
— 자바의 표준 예외들에 포함되지 않는 정보나 기능을 제공하지 않는 한 표준 예외를 사용하라
Follow the Naming Convention
— 표준 예외 클래스는 모두 Exception 으로 끝난다
Provide Javadoc Comments for Your Exception Class
— Javadoc은 예외가 발생할 수도 있는 상황과 예외의 일반적인 의미를 기술한다.
목적은 다른 개발자들이 여러분의 API를 이해하도록 하고 일반적인 에러상황들을 피하도록 돕는것이다
Provide a Constructor That Sets the Cause
— 커스텀 예외를 던지기 전에 표준예외을 캐치하는 케이스가 꽤 많다.
보통 캐치된 예외에는 제품에 발생한 오류를 분석하는데 필요한 중요한 정보가 포함되어 있다.

public void wrapException(String input) throws MyBusinessException {
    try {
        // do something
    } catch (NumberFormatException e) { // set 'e (Throwable)'
        throw new MyBusinessException("A message that describes the error.", e, ErrorCode.INVALID_PORT_CONFIGURATION);
    }
}

ref) https://m.blog.naver.com/PostView.nhn?blogId=sthwin&logNo=221144722072&proxyReferer=https:%2F%2Fwww.google.com%2F

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템73) 추상화 수준에 맞는 예외를 던져라

아래 계층의 예외를 예방하거나 스스로 처리할 수 없고, 그 예외를 상위 계층에 그대로 노출하기 곤란하다면 예외 번역을 사용하라.
이때 예외 연쇄를 이용하면 상위 계층에는 맥락에 어울리는 고수준 예외를 던지면서 근본 원인도 함께 알려주어 오류를 분석하기에 좋다.

예외 번역 (exception translation)

예외 연쇄 (exception chaining)

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템75) 예외의 상세 메시지에 실패 관련 정보를 담으라

스택추적

실패 원인을 분석할 때 얻을 수 있는 정보는 스택 정보인 경우가 많다.
예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 많이 담아 반환하는 일은 아주 중요하다.

실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다.

관련 데이터를 모두 담아야 하지만 장황할 필요는 없다.
예외의 상세 메시지와 최종 사용자에게 보여줄 오류 메시지를 혼동해서는 안된다.
예외는 실패와 관련된 정보를 얻을 수 있는 접근자 메서드를 적절히 제공하는 것이 좋다.

java9에서 제공하는 IndexOutOfBoundsException

public class IndexOutOfBoundsException extends RuntimeException {
    private static final long serialVersionUID = 234122996006267687L;
    public IndexOutOfBoundsException() {
        super();
    }
    public IndexOutOfBoundsException(String s) {
        super(s);
    }
    public IndexOutOfBoundsException(int index) {
        super("Index out of range: " + index);
    }
}

저자가 권하는 방법

/**
 * IndexOutOfBoundsException을 생성한다
 * @param lowerBound 인덱스의 최솟값
 * @param upperBound 인덱스의 최댓값 + 1
 * @param index 인덱스의 실젯값
 */
public IndexOutOfBoundsException(int lowerBound, int upperBound, int index){
    // 실패를 포착하는 상세 메시지를 생성한다.
   super(String.format("최솟값: %d , 최댓값: %d, 인덱스: %d", lowerBound, upperBound, index));
   
   // 프로그램에서 이용할 수 있도록 실패 정보를 저장해둔다.
   this.lowerBound = lowerBound;
   this.upperBound = upperBound;
   this.index = index;
}

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템76) 가능한 한 실패 원자적으로 만들라

일반화 해서 말하자면 호출된 메서드가 실패 하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적(failure atomic)이라고 한다.

메서드를 원자적으로 만드는 방법

불변객체로 설계
작업 수행중에 매개변수의 유효성을 검사
객체의 임시 복사본에서 작업을한 후에 성공시 원래 객체와 교환
작업도중 실패를 가로채는 복구코드를 작성하여 작업전으로 돌리는것

public String substring(int beginIndex) {
    if (beginIndex < 0) {
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    int subLen = length() - beginIndex;
    if (subLen < 0) {
        throw new StringIndexOutOfBoundsException(subLen);
    }
    if (beginIndex == 0) {
        return this;
    }
    return isLatin1() ? StringLatin1.newString(value, beginIndex, subLen)
                      : StringUTF16.newString(value, beginIndex, subLen);
}

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

아이템77) 예외를 무시하지 말라

API 설계자가 메서드 선언에 예외를 명시하는 까닭은, 그 메서드를 사용할 때 적절한 조취를 취해달라고 말하는 것이다.
예외는 문제 상황에 잘 대처하기 위해서 존재하는데 catch 블록을 비워두면 예외가 존재할 이유가 없어진다.

try { 
  ... 
} catch(SomeException e) { }

예외를 무시해야 할 떄

FileInputStream을 닫을 때 (입력 전용 스트림이므로) 파일의 상태를 변경하지 않았으니 복구할 것이 없음 (스트림을 닫는다는 건) 필요한 정보는 이미 다 읽었다는 뜻이니 남은 작업을 중단할 이유도 없음

예외를 무시하기로 했다면 catch 블록 안에 그렇게 결정한 이유를 주석으로 남기고 예외 변수 이름도 ignore로 바꿔놓도록 하자 .

Future<Integer> f = exec.submit(planarMap::chromaticNumber); 
int numColors = 4; 
try { 
numColors = f.get(1L, TimeUnit.SECONDS); 
} catch(TimeoutException | ExecutionException ignored) { }

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

예외 처리에 대한 내 결론이올시다

Parameter Validation in Controller

parameter validation 은 controller 내에서 진행

Service (Business)

service 로직에서 발생한 예외에 대해서는 cause, stacktrace 가 필요함.
표준 예외를 적극적으로 사용 (정의된 메시지 사용)
특정 로직에 대한 예외처리가 필요한 경우 custom exception 사용
custom exception handling 은 controller 에서 정의

catch (NoSuchMethodException e) {
   throw new MyServiceException("Some information: " + e.getMessage());  //Incorrect way
}
catch (NoSuchMethodException e) {
   throw new MyServiceException("Some information: " , e);  //Correct way
}

Method (API)

checked exception 에 대해 throws 선언
빈 catch 블록을 생성하거나 예외를 무시하지 말 것

catch (NoSuchMethodException e) { //Incorrect way
   return null;
}

public void foo() throws Exception { //Incorrect way
}

public void foo() throws SpecificException1, SpecificException2 { //Correct way
}

ref)
standard exception vs custom exception
exception handling best practice
custom exception handling best practice

Ref [standard exception vs custom exception] 에 대한 소견

표준 예외를 적극적으로 사용하자!

예외 메시지로도 충분히 의미를 전달할 수 있다.
표준 예외를 사용하면 가독성이 높아진다.
일일히 예외 클래스를 만들다보면 지나치게 커스텀 예외가 많아질 수 있다.

사용자 정의 예외가 필요하다?

이름으로도 정보 전달이 가능하다. — 반론) message에서도 충분히 가능하다
상세한 예외 정보를 제공할 수 있다. — 반론) back 에서는 message로 충분히 커버가 가능하며, front에서 예외에 대한 상세 내용이 필요하다면 ErrorResponse에 대한 클래스가 정의를 한다
예외에 대한 응집도가 향상된다. — 전달하는 정보의 양이 많아질수록? 이건 오케이 — 책임소재? stacktrace 활용하면 되지 않나? — 같은 예외가 여러 곳에서 사용? standard exception 으로 충분히 커버 가능하지 않나?
예외 발생 후처리가 용이하다. — 발생위치 파악이 힘듬? stacktrace
예외 생성 비용을 절감 — stacktrace는 필요하다고 본다.

[책리뷰/Effective Java] 예외

Mon, 12 Oct 2020 00:00:00 GMT

https://jeong-pro.tistory.com/195 https://cheese10yun.github.io/spring-guide-exception/ https://wbluke.tistory.com/15

[Java] Enum

Sun, 04 Oct 2020 00:00:00 GMT

열거 타입(Enumeration Type)

한정된 값만을 갖는 데이터 타입
한정된 값은 열거 상수(Enumeration Constant)로 정의

열거 타입 변수

열거 타입 변수 선언
```
Week today;
```
열거 상수 값 저장 (열거 타입 변수값은 열거 상수 중 하나)
```
Week today = Week.SUNDAY;
```
열거변수는 참조타입
```
Week today = null;
```
열거 타입 변수는 참조 타입 열거 타입 변수는 참조 타입이므로 null 값 저장 가능

열거 상수는 열거 객체를 참조한다

Week week1 = Week.SUNDAY;
Week week2 = Week.SUMDAY;

System.out.println(wee1 == week2); // true

week1, week2 모두 참조 타입으로
힙에 생성된 Week.SUNDAY 객체의 주소값을 가지고 있으므로 주소 비교시 true 가 출력된다.

열거 객체의 메소드

열거 객체는 열거 상수의 문자열을 내부 데이터로 가지고 있음

열거 타입은 컴파일 시 java.lang.Enum 클래스를 자동 상속
열거 객체는 java.lang.Enum 클래스의 메소드 사용 가능

Week today = Week.SUNDAY;
today.name(); // SUNDAY
today.ordinal(); // 0 (enum 순서는 0부터 시작)
today.valueOf("SUNDAY") // Week.SUNDAY

[책리뷰/이것이 자바다] Class

Sun, 04 Oct 2020 00:00:00 GMT

Annotation

프로그램에게 추가적인 정보를 제공해주는 메타데이터(metadata)

어노테이션 용도

컴파일러에게 코드 작성 문법 에러 체크하도록 정보 제공
ex) 메소드가 재정의 되었는지 확인할 수 있다. (@Override)
소프트웨어 개발 툴이 빌드나 배치 시 코드를 자동 생성하게 정보 제공
ex)xml 설정 파일을 자동 생성하거나 배포를 위한 JAR 압축 파일을 자동 생성할 수 있다.
실행 시(런타임시) 특정 기능 실행하도록 정보 제공
ex) 객체가 애플리케이션 내부에서 해야할 역할을 정의할 수 있다. (컨트롤러, 서비스 등)

Annotation 정의 및 적용

// 정의
public @interface AnnotationName{
  String value(); //default 엘리먼트
  int elementName() default 5;
}

//적용
@AnnotationName("value 값");
@AnnotationName(value="value 값", elementName=3);

Annotation 적용 대상

[Java] Class

Sun, 04 Oct 2020 00:00:00 GMT

객체(Object) 란?

자신의 속성과 동작을 가진 모든 것
객체 vs 인스턴스
— 객체는 선언을 의미 — 인스턴스는 연산자를 통해 클래스로부터 실체화가 됨을 의미
```
class Car { ... }
Car tico, morning, matiz; // 객체
tico = new Car(); // 인스턴스
```
참고

https://dbnsecu.tistory.com/8
https://gmlwjd9405.github.io/2018/09/17/class-object-instance.html

객체간의 관계

관계의 종류

집합 관계: 완성품과 부품의 관계
사용 관계: 객체가 다른 객체를 사용하는 관계
상속 관계: 종류 객체와 구체적인 사물 객체 관계

클래스 변수

new 연산자에 의해 리턴 된 객체의 번지 저장 (참조 타입 변수)
힙 영역의 객체를 사용하기 위해 사용

인스턴스 멤버

인스턴스 생성 시 아래와 같은 메모리 구조를 갖는다.

this 키워드

인스턴스 자신의 주소를 가지고 있는 키워드

정적 멤버와 static

정적(static) 멤버란?

클래스에 고정된 필드와 메소드 - 정적 필드, 정적 메소드
정적 멤버는 클래스에 소속된 멤버
— 객체 내부에 존재하지 않고, 메소드 영역에 존재
— 정적 멤버는 객체를 생성하지 않고 클래스로 바로 접근해 사용

정적 초기화 블록

클래스가 메소드 영역으로 로딩될 때 자동으로 실행하는 블록
정적 필드 초기화 및 정적 메소드 호출 가능
인스턴스 멤버나 메소드 호출 불가능
```
static {
...
}
```

Annotation

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템1) 생성자 대신 정적 팩터리 메서드를 고려해라

정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋다. 그렇다고 하더라고 정적 팩터리를 사용하는 게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자.

정적 팩터리 메서드가 생성자보다 좋은 장점

1. 이름을 가질 수 있다.

어떤 역할의 객체 생성인지 명시 가능

값이 소스인 BigInteger를 반환  
생성자 :            BigInteger(int, int, Random)
정적 팩터리 매서드 : BigInteger.probablePrime(int, Random)

2. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.

플라이웨이트 패턴(Flyweight pattern)
데이터를 공유하여 메모리를 절약하는 패턴, 공통으로 사용되는 객체는 한번만 사용되고 Pool에의해서 관리, 사용된다. (JVM의 String Pool에서 같은 String이 잇는지 먼저 찾는다. [불변객체 String])
불변클래스
인스턴스를 미리 만들어 놓거나 인스턴스 캐싱으로 재사용하여 불필요한 객체 생성을 피할 수 있다. ex ) Boolean.valueOf(boolean b);
인스턴스 통제(instance-controlled) 클래스
정적 팩터리 방식의 클래스는 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제할 수 있다.
싱글턴 / noninstatntialbe로 만들 수 있다.
불변 값 클래스에서 동치 인스턴스 하나임을 보장 ex ) Enum : 인스턴스가 하나만 만들어짐

3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.

생성자의 경우에는 반환형 클래스가 정해져있지만, static factory method 는 하위타입을 반환할수도 있다.
java.util.Collections 가 예시다

ps. Java8 인터페이스

Default Method
— default 키워드를 통해 메서드를 구현할 수 있다.
또, 이를 구현하는 클래스는interface의 메서드를 @Override 할 수 있다.

public interface Coffee {  
  default String getBrandName() {
    return "MEGA";
  }
}
// getBrandName이 없는 DTO 클래스 생성
public class Americano implements Coffee {
  private long price;
  public Americano(long price) {
    this.price = price;
  }
}
// default 메소드에 적용되어있는 getBrandName() 메소드 사용
public class Test {    
  public static void main(String args[]) {
    Coffee coffee = new Americano();
    System.out.println(coffee.getBrandName());
  }
}

디폴트 메소드 vs 추상클래스 차이점
— 인터페이스는 private 값을 가지지 못한다.(오직 public, abstract, default, static 상태만 가질 수 있다.) — 인터페이스는 생성자를 가질 수 없지만 추상클래스는 생성자를 가질 수 있다.

참고 - 인터페이스에 대한 설명
https://wedul.site/320
https://m.blog.naver.com/heartflow89/220969525191

4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.

하위타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없다.
— EX) EnumSet
— 정적 팩터리 메소드인 noneOf() 에서,
원소가 64개 이하면 long 변수 하나로 관리하는 RegularEnumSet 을 반환하고,
65개 이상이면 long 배열로 관리하는 JumboEnumSet 을 반환 — 클라이언트에서는 이 두 객체의 존재를 모르고, 다음 릴리즈에서 이 내용을 변경할 수 있는 유연성을 가진다.

5. 정적 팩터리 메스드를 작성하는 시점에서는 반환할 객체의 클래스가 존재하지 않아도 된다.

— 다시

단점

정적 팩터리 메서드만 제공하는 클래스는 상속할 수 없다.
상속을 하려면 pubilc 이나 protected 생성자가 필요하기 때문이다.
정적 팩터리 메서드는 프로그래머가 찾기 어렵다. 생성자처럼 API 설명에 명확히 드러나지 않기 때문에 프로그래머가 직접 정적 팩터리 메서드를 찾아야 한다.

정적 팩터리 매서드 명명 방식

from
— 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 매서드
```
Date d = Date.from(instance);
```
of
— 여러 매개변수를 받아 적합한 타입으 ㅣ인스턴스를 반환하는 집계 메서드
```
Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);
```

valueOf
— from과 of의 더 자세한 버전

BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);

instance 혹은 getInstance
— 매개변수를 받는다면, 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지 않음
```
StackWalker luke = StackWalker.getInstance(options);
```
create 혹은 newInstance
— instance 혹은 getInstance 와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다.
```
Object newArray = Array.newInstance(classObject, arrayLen);
```
getType
— getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 매서드를 정의할 때 사용
```
FileStore fs = Files.getFileStore(path);
```
newType
— newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 매서트를 정의할 때 사용
```
BufferedReader br = Files.newBufferedReader(path);
```

type
— getType과 newType의 간결한 버전

List<Complaint> litany = Collections.list(legacyLitany)

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템2) 생성자에 매개변수가 많다면 빌더를 고려하라

생성자와 static factory method 의 똑같은 단점은 매개변수가 많을 때 적절히 대응하기 어렵다.
생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는 게 더 낫다.
매개변수 중 다수가 필수가 아니거나 같은 타입이면 특히 더 그렇다.
빌더는 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈보다 훨씬 안전하다.

점층적 생성자 패턴(telescoping constructor pattern)

매개변수가 많아지면 클라이언트 코드를 장성하거나 읽기 어렵다.

public 생성자(변수1);
public 생성자(변수1, 변수2);
public 생성자(변수1, 변수2, 변수3..);

자바빈즈 패턴(JavaBeans pattern)

setter를 이용
객체 하나를 생성하기 위해선 여러개의 매서드 호출이 필요

객체가 완전히 생성되기 전까지 일관성이 무너진 상태에 놓임

Coffee coffee = new Americano();
coffee.setPrice(3000);
coffee.setCapacity(500);
...

빌더 패턴(Builder Pattern)

필수 매개변수만으로 생성자 또는 정적 팩터리를 호출하여 빌더 객체를 얻음

public class NutritionFacts {
  private final int servingSize;
  private final int servings;
  private final int calories;
  private final int fat;

  // Builder
  public static class Builder {
    //필수 매개변수
    private final int servingSize;
    private final int servings;
    // 선택적 배개변수 - 기본값으로 초기화
    private int calories = 0;
    private int fat = 0;
    public Builder(int servingSize, int servings) {
      this.servingSize = servingSize;
      this.servings = servings;
    }
    public Builder calories(int val) { calories = val; return this; }
    public Builder fat(int val) { fat = val; return this; }
    public NutritionFacts build() { return new Nutrition(this); }
  }
  
  private NutritionFacts(Builder builder) {
    this.servingSize = builder.servingSize;
    this.servings = builder.servings;
    this.calories = builder.calories;
    this.fat = builder.fat;
  }
}

//사용
NutritionFacts cocaCola = NutritionFacts.Builder(240, 8).calories(100).build();

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템3) private 생성자나 열거 타입으로 싱글턴임을 보증하라

싱글턴(Singleton)

인스턴스를 오직 하나만 생성할 수 있는 클래스
함수와 같은 무상태(stateless) 객체나 설계상 유일해야 하는 시스템 컴포넌트에 사용

싱글턴을 만드는 방법 3가지

1. public static final 필드 방식

예외: reflection API 인 AccessibleObject.setAccessible을 사용하여 private 생성자 호출 가능 이를 방어하기 위해 생성자를 수정하여 두번째 객체가 생성되려 할 떄 예외를 던지게 한다.

public class Elvis {
  public static final Elvis INSTANCE = new Elvis();
  private Elvis() {...}

  public void leaveTheBuilding() {...}
}

2. public static method 방식

public class Elvis {
  private static final Elvis INSTANCE;
  private Elvis() {...}
  public static getInstance() { return INSTANCE; }

  public void leaveTheBuilding() {...}
}

1,2번의 예외

직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 생성
— 두번째 객체가 생성될때 예외를 던져도?? 테스트 해보기

이를 방지하기 위해 인스턴스 필드에 transient 키워드를 선언하고 readResolve 메서드를 생성한다.

private/public static final transient Elvis INSTANCE;
// 싱글턴임을 보장해주는 메서드, 역직렬화시 호출
public Object readResolve() { return INSTANCE };

참고

3. Enum 방식

public 필드 방식과 비슷하지만 더 간결하고 위의 예외에 대한 방어가 다 된다.
대부분 상황에서 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법이다.
상속(extends) 이 필요한 경우 이 방법은 사용 할 수 없다. (implements 는 가능)

public enum Elvis {
   INSTANCE;
   public void leaveTheBuilding() {...}
}

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템4) 인스턴스화를 막으려거든 private 생성자를 사용하라

정적 멤버만을 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 게 아니다.
생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어주며, 사용자는 이 생성자가 자동 생성된 것인지 구분할 수 없다.
상속이 불가능한 클래스가 된다.
— 모든 자식 생성자는 상위 클래스의 생성자를 호출하게 되는데, 이를 private로 선언하였기 때문에 호출이 불가능하다.

public class Utility {
  private Utility() {
    throw new AssertionError();
  }
}

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템5) 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다.
이 자원들을 클래스가 직접 만들게 해서도 안된다. 대신 필요한 자원을 생성자에게 넘겨주자.
의존 객체 주입 이 기법은 클래스의 유연성, 재사용정, 테스트 용이성을 개선해준다.

public class SpellChecker {
  private final Lexicon dictionary;
  public SpellChecker(Lexicon dictionary) {
    this.dictionary = Objects.requiredNonNull(dictionary);
  }

  public boolean isValid(String word) {...}
  public List<String> suggestions(String typo) {...}
}

생성자에 자원 팩터리를 넘겨주는 방식 (Factory Method Pattern)

클라이언트가 제공한 팩터리가 생성한 타일들로 구성된 모자이크를 만드는 메서드

Mosaic create(Supplier<? extens Tile> tileFactory) { ... }

참고

Supplier 예제

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템7) 다 쓴 객체 참조를 해제하라

메모리 누수는 겉으로 잘 드러나지 않아 시스템에 수년간 잠복하는 사례도 있다.
이런 누수는 철저한 코드 리뷰나 힙 프로파일러 같은 디버깅 도구를 동원해야만 발견되기도 한다.
그래서 이런 종류의 문제는 예방법을 익혀두는 것이 매우 중요하다.

메모리 누수 발생 코드

public class Stack {
  private Obejct[] elements;
  private int size = 0;
  private static final int DEFAULT_INITIAL_CAPACITY = 16;
  
  public Stack() {
    elements = new Object[DEFAULT_INITIAL_CAPACITY]; 
  }
  
  public void push(Object e) {
    ensureCapacity();
    elements[size++] = e;
  }
  public Object pop() {
    if(size == 0) throw new EmptyStackException();
    return elements[--size];
  }
  
  private void ensureCapacity() {
    if(elements.length == size)
      elements = Arrays.copyOf(elements, 2*size+1);
  }
}

해결방법

Object[]은 Arrays.copyOf()를 통해 길이조절이 되는 상황이다.
pop() 메소드에서 size를 감소시키나, 해당 값은 그대로 두고 있으므로 메모리 누수가 발생하는 것을 볼 수 있다.
이 경우 명시적으로 null 을 할당해줌으로써 참조해제를 통해 GC를 돌릴 수 있다.

  public Object pop() {
    if(size == 0) throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; // 참조값인데.... result도 null이 아닌가?? 확인 필요
    return result;
  }

메모리 누수 주범

자기 메모리를 직접 관리하는 클래스
캐시
리스너 혹은 콜백

메모리 누수 예방법

원소를 다 사용한 즉시 그 원소가 참조한 객체들을 null 처리 한다.
WeakHashMap 또는 LinkedHashMap의 removeEldestEntry() 를 사용
백그라운드 스레드 활용 (ScheduledThreadPoolExecutor)

참고

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템8) finalizer 와 cleaner 사용을 피해라

cleaner(자바 8까지는 finalizer) 는 안전망 역할이나 중요하지 않는 네이티브 자원 회수 용으로만 사용하자.
물론 이런 경우라도 불확실성과 성능 저하에 주의해야 한다.

참고

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템9) try-finally 보다는 try-with-resources를 사용하라

꼭 회수해야 하는 자원을 다룰 때는 try-finally 말고 try-with-resources 를 사용하면 정확하고 쉽게 회수할 수 있다.

try-finally

try 안에서 예외가 발생한 후에 finally 안에서 또 다시 예외가 발생 한 경우에는,
두번째 예외가 첫번째 예외를 집어삼키므로 디버깅이 어렵다.

void copy(String src, String dst) throws IOException {
  InputStream in = null;
  OutputStream out = null;
  try {
    in = new FileInputStream(src);
    out = new FileOutputStream(dst);

    byte[] buf = new byte[BUFFER_SIZE];
    int n;
    while((n = in.read(buf)) >= 0)
      out.write(buf, 0, n);

  } finally {
    if(in != null) in.close();
    if(out != null) out.close();
  }
}

try-with-resources

코드가 간결해진다.
try 안에서 발생된 예외가 기록된다.
AutoCloseable 을 이용하여 닫아야하는 자원에 대해 정의할 수 있다.
참고 - AutoCloseable 예제

void copy(String src, String dst) throws IOException {
  try (InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(dst)) {
    byte[] buf = new byte[BUFFER_SIZE];
    int n;
    while((n = in.read(buf)) >= 0)
      out.write(buf, 0, n);
  }
}

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

아이템6) 불필요한 객체 생성을 피해라

객체 재사용

String s = new String("data"); // bad
String s = "data"; // good

//bad
private static final String REGEX = ...;
static boolean isRomanNumeral(String s) {
  return s.matches(REGEX);
}

//caching - good
private static final String REGEX = ...;
private static final Pattern ROMAN = Pattern.compile(REGEX);
static boolean isRomanNumeral(String s) {
  return ROMAN.matcher(s).matches();
}

불필요한 객체를 만들어내는 예

1. Adapter (view)

실제 작업은 뒷단 객체에 위임하고, 자신은 제2의 인터페이스 역할을 해주는 객체
Map 인터페이스의 keySet 메서드

Map<String, Integer> serviceSinceMap = new HashMap<>(); 
serviceSinceMap.put("Kakao", 2010); 
serviceSinceMap.put("Naver", 1999); 

Set<String> test1 = serviceSinceMap.keySet(); 
Set<String> test2 = serviceSinceMap.keySet(); 
test1.remove("Kakao"); 

System.out.println(test1 == test2); // true 
System.out.println(test1.size()); // 1 
System.out.println(test2.size()); // 1 
System.out.println(serviceSinceMap.size()); // 1

2. Auto Boxing

프로그래머가 기본 타입과 박싱된 기본 타입을 섞어 쓸 때 자동으로 상호 변환해주는 기술
박싱된 기본 타입(Long) 보다는 기본 타입(long) 을 사용한다.

Long sum = 0l; 
for (long i = 0 ; i <= Integer.MAX_VALUE ; i++) { 
  sum += i; // 불필요한 Long 인스턴스가 2^31개가 만들어짐 
}

[책리뷰/Effective Java] 객체 생성과 파괴

Sun, 04 Oct 2020 00:00:00 GMT

[Design Pattern] Flyweight pattern

Sun, 04 Oct 2020 00:00:00 GMT

참고

https://beomseok95.tistory.com/259
https://nowonbun.tistory.com/447

[Java] Date, LocalDateTime 포맷팅

Mon, 28 Sep 2020 00:00:00 GMT

Date & SimpleDateFormat

String stringDate = " 2011-01-18 00:00:00.0"; 

SimpleDateFormat dateFormatter = new SimpleDateFormat("yyyyy-mm-dd hh:mm:ss"); 
Date stringToDate = dateFormatter.parse(stringDate); 

SimpleDateFormat dateFormatter2 = new SimpleDateFormat("yyyyy-mm-dd");
String dateToString = dateFormatter2.format(stringToDate);

LocalDateTime & DateTimeFormatter

String stringDate = " 2011-01-18 00:00:00.0"; 

LocalDateTime stringToDate = LocalDateTime.parse(stringDate, DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));

String dateToString = stringToDate.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));

Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test

Tue, 22 Sep 2020 00:00:00 GMT

문제

테스트 코드 실행 시 아래와 같은 오류가 발생하였다.

Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test
java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test

원인

@SpringBootApplication 애노테이션이 붙은 클래스가 존재하는 패키지의 하위 패키지에 테스트를 둬야 한다는 원칙을 어김

해결

test.java 패키지 바로 아래 있던 테스트 클래스를 ProjectApplication.java 의 패키지 depth 와 동일하게 맞춰서 재실행

main: com.company.project.ProjectApplication.java
test: com.company.project.TestApplication.java

[책리뷰] 리펙토링

Sat, 19 Sep 2020 00:00:00 GMT

Chapter3. 코드에서 나는 악취

리펙토링 기법: 패턴을 찾자.

1. 기이한 이름(Mysterious Name)

코드를 명료하게 표현하는 데 가장 중요하나 요소 하나는 바로 ‘이름’이다.
그래서 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 이름을 지어야 한다.
마땅히 떠오르지 않는다면 설계에 근본적인 문제가 있다.

2. 중복 코드(Duplicated Code)

중복된 코드는 하나로 통합하자.
— 함수 추출하기, 상속 사용하기

3. 긴 함수 (Long Function)

긴 함수는 이해하기 어렵다.
— 주석을 달아야 할 부분은 무조건 함수로 만든다
이해하기 쉬운 짧은 함수의 조건은 이름이다.
— 함수 이름을 잘 지으면 본문 코드를 볼 이유가 사라진다.
— 함수의 이름은 동작 방식이 아닌 의도 또는 목적이 드러나게 짓는다.
조건문/ 반복문
— 뒷부분에 계속

4. 긴 매개변수 목록(Long Parameter List)

매개변수 객체 만들기
여러 개의 함수가 특정 매개변수들의 값을 공통으로 사용할 때 클래스를 정의하여 공통 값을들 클래스의 필드로 정의 후 사용한다??
<>이건 아닌듯 싶다.. 목적이 있는 클래스에 맞는 함수들을 멤버화 시키는게 맞다고 생각한다.</>

5. 전역 데이터(Global Data)

클래스 변수, 싱글톤
코드베이스 어디에서든 수정이 가능하기에 버그 발생 요소가 높다.
변수 캡슐화
— 변수 캡슐화가 의미가 있을까??
전역 데이터는 되도록 상수화를 사용하도록 하며, 가변 데이터일 경우 접근제어를 사용하는게 낫지 않을까 싶다.

6. 가변 데이터(Mutable Data)

원본 데이터는 그대로 둔 채 변경하려는 값에 해당하는 복사본을 만들어 반환한다. (참조를 값으로 바꾼다)
데이터에 대한 갱신 로직은 따로 정의를 하는게 좋다.

7/8. 뒤엉킨 변경(Divergent Change) vs 산탄총 수술(Shotgun Surgery)

뒤엉킨 변경 - 함께 변경 할 대상을 한데 모으는 것 — 전략패턴, 방문자 패턴, 켄트 벡의 자기 위임
산탄총 수술 - JPA wrapper 도입 고민 필요

9. 기능 편애(Feature Envy)

정의된 목적에 해당하는 기능이 수행되도록 함수/클래스를 정의한다.
기능편애를 거스르는? 이라기보단 좀 더 advanced 예제 : 전략 패턴, 방문자 패턴, 켄트 백의 자기 위임

10. 데이터 뭉치(Data Clumps)

데이터 뭉치는 클래스화

11. 기본형 집착(Primitive Obsession)

전화번호 같은 문자열화된 변수(stringly type)를 객체로 바꾸어 사용하자
조건부 동작을 제어하는 타입 코드로 쓰였다면 다형성을 적용하자
— 서브 클래스 적용 및 조건부 로직에 다형성 적용?? 글쎄.. 뒤에서 다시 다루자

12. 반복되는 switch 문(Repeated Switches)

반복되고 중복된 조건부 로직에 대해 다형성 도입
— 조건절을 추가할 때마다 수정해야 할 부분이 여러 곳이면 안된다.

13. 반복문(Loop)

반복문을 파이프라인으로 바꾸기
— filter, map 같은 파이프라인 연산을 사용하면 코드에서 각 원소들이 어떻게 처리되는지 쉽게 파알할 수 있다.

14. 성의 없는 요소(Lazy Element)

역할이 거의 없는 클래스 또는 함수는 제거하자

15. 추측성 일반화(Speculative Generality)

미래를 대비해 작성한 후킹포인트와 특이 케이스 처리 로직은 불필요하다.
— 후킹포인트: 함수 호출, 메시지, 이벤트 등을 중간에서 바꾸거나 가로채는 명령, 방법 기술이나 행위

16. 임시 필드(Temporary Field)

특정 상황에서만 값이 설정되는 필드들은 따로 클래스화 한다. — 클래스 목적에 의해 정의된 필드들을 다시 세분화 한다?
필드가 많을 경우 그렇다고 하지만, nullable한 필드를 위한 세분화는 글쎄.. 차라리 nullable로 필드를 정의하여 assertion 하는게 낫지 않을까? 해당 부분은 정말 특이 케이스라 생각한다

17. 메시지 체인(Message Chains)

클라이언트가 객체 내비게이션 구조에 종속됐음을 의마한다. (다른 객체를 요청하는 작업이 연쇄적으로 이어지는 코드)
최종 결과 객체가 어떻게 쓰이는지 확인 후 체인을 숨기는 방법을 고민하자

18. 중개자(Middle Man)

위임이 지나치면 문제가 된다.
케이스에 따라 위임 메서드를 제거하여 실제로 일을 하는 객체와 직접 소통하게 하자(중개자 제거)

19. 내부자 거래(Insider Trading)

모듈간 결합도를 낮추기 위해 함수 또는 클래스를 세분화 한다.

20. 거대한 클래스(Large Class)

필드가 많으면 중복 코드가 생기기 쉽다
상속 또는 서브클래스를 사용하여 분할하자.

21. 서로 다은 인터페이스의 대안 클래스들(Alternative Classes with Different Interface)

인터페이스 또는 상속을 이용한 설계를 고민하자

22. 데이터 클래스(Data Class)

데이터 필드와 개터/세터 만으로 구성된 클래스
immutable 한 필드는 세터를 제거하자.
로직 단위를 쪼개 중간 결과 데이터의 구조(클래스)는 불변이다.
불변 필드는 굳이 캡슐화 할 필요가 없다?? Object 구조 일 경우 값이 변경될 수 있으므로 getter 는 사용하는게 나을거 같다.

23. 상속 포기(Refused Bequest)

일부 동작을 재활용하기 위한 목적으로 상속을 사용한다. (실무 관점에서 아주 유용하다에 동의)
인터페이스를 따르지 않는 경우 서브 클래스 생성 또는 ????????

24. 주석(Comments)

주석이 필요한 부분에 함수를 추출하여 이름을 잘짓자.
선행조건을 명시하고 싶다면 어서션을 추가하자.

[HKMC] 작업로그

Tue, 15 Sep 2020 00:00:00 GMT

1. DB Instance 생성

1.1. MYSQL CLI 로 접속

# mysql -u root -p

mysql 명령어를 찾을 수 없다는 오류가 나와서 프로세스 확인 및 mysql client 설치 확인을 하였다

# ps -ef | grep mysqld (프로세스 정상 동작 확인)
# rpm -qa | grep mysql (mysql 설치 안되어 있음)

mysql을 rpm 으로 설치를 진행하지 않고 바이너리로 설치 한 듯 싶었다. mysql 바이너리가 있는 디렉토리에서 직접 수행하였더니 아래와 같은 오류가 발생하였다.

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

mysql.sock 파일 위치 문제로 보였으나,
담당자가 root 계정(OS)으로 접속하여 시도하니 mysql 클라이언트가 정상 동작하였다.
mysql.sock 파일 permission 문제였나? 내일 확인해 봐야겠다.

mysql.sock 파일 위치 문제시 해결 방안

경로 명시

mysql -u root -p mysql -S /var/lib/mysql/mysql.sock

soft link

ln -sf /tmp/mysql.sock /var/lib/mysql/mysql.sock

/usr/local/mysql/bin/mysqld_safe 파일에서 아래 부분을 mysql.sock 파일이 있는 위치에 맞게 수정
```
safe_mysql_unix_port=${mysql_unix_port:-${MYSQL_UNIX_PORT:-/tmp/mysql.sock}}
```

1.2. DB 인스턴스 생성

mysql> create database DB_NAME default character set utf8 collate utf8_general_ci;

default character set 부분이 외워지질 않네..

1.3. 계정 생성

mysql> create user [USER_NAME]@'localhost' identified by '[PASSWORD]';
mysql> create user [USER_NAME]@'%' identified by '[PASSWORD]';

1.4. 권한 확인

1.4.1. 권한 확인

#접속된 계정 권한 확인
mysql> SHOW GRANTS FOR CURRENT_USER;
# 사용자별 권한 확인
mysql> SHOW GRANTS FOR '사용자계정'@'호스트';

1.4.2. 권한 추가

mysql> GRANT ALL PRIVILEGES ON [DB_NAME].[TABLE_NAME] TO [ID]@[HOST] IDENTIFIED BY '[PASSWORD]' with grant option;
# 권한 종류
- ALL PRIVILEGES : 모든 권한 추가 
- SELECT, INSERT, UPDATE, DELETE, ... : 권한을 일부분을 추가 
# with grant option 옵션
- with grant option : GRANT를 사용할 수 있는 권한 추가

2. 서비스 기동

nohup java -jar -Duser.timezone=Asia/Seoul ${JAR_FILE} --server.port=${PORT} --spring.profiles.active=${SVC_ENV},swagger >> ./logs/server.log &

옵션이 외워지지 않는다..
이제부턴 실행 스크립트도 같이 전달해야겠다.

ps. ssh timeout

타임 아웃이 걸린 ssh 접속을 오랜만에 했더니 명령어 기억이 나질 않았다.

export TMOUT=0

[코드리뷰] Null이 아닌 빈 컬렉션이나 배열을 반환하라

Mon, 14 Sep 2020 00:00:00 GMT

return result.isEmpty() ? null : new ArrayList<>(result);

위와 같이 null을 반환하는 메서드를 작성함에 있어 문제점을 느끼지 못했다.
값이 없으므로 당연히 null로 반환을 하는걸 당연하게 생각했다.

# Null 정의
 - 변수에 아무것도 할당되지 않았을 때
 - 정의되지 않음
 - 특별한 값이 없음

근데 아니였구나… 잘못 알고 있었구나.. 그랬구나..

아래와 같이 정리한다.

API에 null을 최대한 쓰지 말자

# 반환 값이 있어야 한다면 null 대신 예외를 던지자
# 빈 반환값은 빈 컬렉션이나 Null 객체를 사용하자

매번 빈 컬렉션 할당하여 반환하지 말고 빈 불변 컬렉션을 반환하도록 하자.

# Collections 상수사용
Collections.emptyList, Collections.emptyMap, ..
# 불변 객체 선언 후 사용
private static final String[] EMPTY_ARRAY = new String[0];

선택적 매개변수는 null 대신 다형성(overload)를 사용하자

계약에 의한 설계(Design by Contract)를 하자

# API 규약을 소비자와 제공자 사이에 지켜야 할 엄격한 계약으로 여기는 설계방법
# 형식적 규약 외에 사전 조건과 사후 조건과 유지 조건을 포함
## 사전조건: 보호절(guard clause)
- 단정문
- Objects 메서드
- IllegalArgumentException
- NullPointException

[Spring] SpringSecurity 에서 req/res에 대한 로깅은?

Wed, 09 Sep 2020 00:00:00 GMT

모든 req/res DB 로깅은 interceptor 에서 진행하였고,
로그인/ 로그아웃에 대한 req/res 로깅은 AuthenticationProvider 클래스를 구현한 곳에서 로깅을 하였는데, 로그인 로그아웃에 대한 로깅 위치에 대한 의문을 가지게 되었다.

#. Spring Security 구조

#. 구현내용

AuthenticationProvider 의 구현체에서 authenticate() 메소드를 Override 받아 로그인 확인 로직을 구현하였다.
req 데이터에 대한 로깅은 여기서 진행
로그인이 성공 할 경우 onAuthenticationSuccess() 를 재정의하여 res 데이터에 대한 로깅을 진행
로그인이 실패 할 경우 onAuthenticationFailure() 를 재정의하여 exception에 대한 로깅을 진행
AuthenticationException 에 대한 메시지 처리

#. AuthenticationException

UsernameNotFoundException : 계정 없음
BadCredentialsException : 비밀번호 불일치
SessionAuthenticationException : Invalid 한 세션
AccountStatusException
— AccountExpiredException : 계정만료
— CredentialsExpiredException : 비밀번호 만료
— DisabledException : 계정 비활성화
— LockedException : 계정잠기

참고

[Java] Final vs Static

Mon, 07 Sep 2020 00:00:00 GMT

서비스 클래스에서 constant 로 사용하기 위해 아래와 같이 변수를 선언했다

 private final List<String> ALPA_LIST = Arrays.asList("a", "b", "c")

접근제어자가 private 이고, 하나의 controller 에만 주입되어 사용하고 있어 static 키워드 없이 사용하였는데,
해당 변수에 대한 사용의도(private final이 constant로 적합한가?)에 대해 얘기를 하게 되었고 아래와 같은 의문을 갖게 되었다.

1. static vs final

static

means there is only one copy of the variable in memory shared by all instances of the class.

final

The final keyword just means the value can’t be changed. Without final, any object can change the value of the variable.

2. private final vs private final static

결론은…
constant 로서 사용되는 변수는

모든 인스턴스에서 동일한 값을 사용하고,
새로 메모리를 잡을 필요가 없고
초기화 후에 immutable 한 값이므로 static 키워드를 추가하여 사용한다.
```
private final static List<String> ALPA_LIST = Arrays.asList("a", "b", "c")
```

[ 200914 추가내용 ]

Arrays.asList()
# remove(), add()를 지원하지 않음. 사용시 java.lang.UnsupportedOperationException 발생
# ArrayList와 마찬가지로 set(), get(), contains() 제공

즉 value가 변할 수 있는 객체이므로, 상수로서 적합하지 않다. 따라서 immutable 하도록 아래와 같이 사용한다.

 private final static List<String> ALPA_LIST = Collections.unmodifiableList(Arrays.asList("a", "b", "c"))

Java 9부터는 List .of (E… elements) 정적 팩토리 메서드를 사용

@Test(expected = UnsupportedOperationException.class)
public final void givenUsingTheJava9_whenUnmodifiableListIsCreated_thenNotModifiable() {
    final List<String> list = new ArrayList<>(Arrays.asList("one", "two", "three"));
    final List<String> unmodifiableList = List.of(list.toArray(new String[]{}));
    unmodifiableList.add("four");

참고

Jenkins 빌드 후 실행 스크립트 작성

Wed, 02 Sep 2020 00:00:00 GMT

jenkins에서 github hook trigger 발생 후에 빌드 단계에서 실행 되는 스크립트를 작성하였다.

한 서버에 dev/ prod 두개의 서비스가 다 올라가야해서 스크립트 실행 시 parameter를 받는 방식으로 진행하였다.

if문 작성이 왜이리 오래 걸렸는지… 관련 내용을 기록 좀 해두고 써먹어야겠다.

작성내용

#!/bin/bash

cd frontend
npm install
npm run build
cd ..

gradle build
gradle bootjar
if [ "$1" == "dev" ]; then
        PORT=15000
elif [ "$1" == "prod" ]; then
        PORT=15118
else
        echo bad parameter
        exit 1
fi

PID=`ps -ef | grep V2G | grep ${PORT} | grep -v grep | awk '{print $2}'`
PID_LENGTH=${#PID}
if [ ${PID_LENGTH} -gt 0 ]
then
        kill $PID
fi

BUILD_ID=dontKillMe nohup java -jar -Duser.timezone=Asia/Seoul ./build/libs/AutoCrypt-V2G-0.0.1-SNAPSHOT.jar --server.port=${PORT} --spring.profiles.active=$1,swagger >> ./logs/server.log &

참고 내용

문자열 길이 구하기
```
${#PID}
```
변수의 값을 참조할때는 ${변수이름} 처럼 중괄호로 감싸주는 습관을 들이면 좋다.

if 문 사용법

FILENAME="/home/test/temp"
VALUE=10
if [ ${VALUE} -eq 10 ] ; then
echo "VALUE is 10!"
fi
# 아래 -a (&&) 조건문은 아래와 같이 변경 가능합니다.
# if [ ${VALUE} -gt 5 ] && [ ${VALUE} -lt 15 ] ; then
if [ ${VALUE} -gt 5 -a ${VALUE} -lt 15 ] ; then
echo "VALUE is greater than 5 and less than 15!"
fi
if [ -e ${FILENAME} ] ; then
echo "${FILENAME} exists"
fi

조건문 종류

비교식
[ -z ${A} ] : A 문자열의 길이가 0이면 TRUE
[ -n ${A} ] : A 문자열의 길이가 0이 아니면 TRUE
[ ${A} -eq ${B} ] : A와 B값이 같으면 TRUE
[ ${A} -ne ${B} ] : A와 B값이 다르면 TRUE
[ ${A} -gt ${B} ] : A가 B보다 크면 TRUE
[ ${A} -ge ${B} ] : A가 B보다 크거나 같으면 TRUE
[ ${A} -lt ${B} ] : A가 B보다 작으면 TRUE
[ ${A} -le ${B} ] : A가 B보다 작거나 같으면 TRUE
--
[ 조건식A -a 조건식B ] : 조건식 A와 B가 모두 TRUE이면 TRUE (&& 와 동일)
[ 조건식A -o 조건식B ] : 조건식 A가 TRUE거나 조건식B가 TRUE면 TRUE (|| 와 동일)
--
파일관련
[ -d ${A} ] : A 파일이 디렉토리면 TRUE
[ -e ${A} ] : A 파일이(노드, 디렉토리, 소켓 등등 모두) 존재하면 TRUE
[ -L ${A} ] : A 파일이 심볼릭 링크면 TRUE
[ -r ${A} ] : A 파일이 읽기 가능하면 TRUE
[ -s ${A} ] : A 파일의 크기가 0 보다 크면 TRUE
[ -w ${A} ] : A 파일이 쓰기 가능하면 TRUE
[ -x ${A} ] : A 파일이 실행 가능하면 TRUE
[ -c ${A} ] : A 파일이 Special character file 이면 TRUE
[ -f ${A} ] : A 파일이 디렉토리가 아닌 일반 regular 파일이면 TRUE
[ -S ${A} ] : A 파일이 소켓이면 TRUE
[ ${A} -nt ${B} ] : A 파일 B 파일보다 최신파일이면 참
[ ${A} -ot ${B} ]  : A 파일이 B 파일보다 이전파일이면 참
[ ${A} -ef ${B} ] : A 파일과 B 파일이 같은 파일이면 참

비교식 옵션 설명

-eq : EQual
-ne : NEgative
-gt : Greater Than
-ge : Greater than Equal
-lt : Less Than
-le : Less than Equal
-d : Directory
-e : Exist
-L : symbolic Link
-r : Readable
-w : Writeable
-x : eXecute
-nt : Newer Than
-ot : Older Than
-ef : Equal File

참고 사이트

문자열 길이 구하기

[StringBoot] Profile에 따른 application.yml 설정하기

Wed, 02 Sep 2020 00:00:00 GMT

1. yml 설정

수정 전

spring:
  active: cron_alert,swagger
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 10MB
  resources:
    static-locations: "classpath:/static/,classpath:/public/"
    add-mappings: true
  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://127.0.0.1:3306/autocrypt_v2g?autoReconnect=true
    username: root
    password: flatron123!
    hikari:
      idle-timeout: 10000
      max-lifetime: 420000
      connection-timeout: 10000
      validation-timeout: 10000
    dbcp2:
      test-while-idle: true
      validation-query: "SELECT 1"
  jpa:
    open-in-view: false
    generate-ddl: true
    properties:
      hibernate.dialect: org.hibernate.dialect.MySQL5InnoDBDialect
    show-sql: false
    hibernate:
      ddl-auto: update

2. 수정 후

profiles 구분자 ---
--- 를 이용하면 profiles 을 구분할 수 있다. 맨 위에 작성된 내용이 default 가 된다.
profile 활성화

[Node] gyp verb check python checking for Python executable "python" in the PATH

Sat, 29 Aug 2020 00:00:00 GMT

문제

gatsby node_modules 설치 도중 문제 발생

원인

phthon 2.7 미설치 또는 PYTHON 환경변수 없음

해결

python 미 설치시
```
(관리자 권한으로 실행)
npm install --global --production windows-build-tools
```
설치 경로 C:\Users\ben.windows-build-tools\python27\python.exe 참고 - 지원되지 않으므로 3.x가 아닌 python 2.7을 사용
node-gyp 설치
```
npm install --global node-gyp
```

일단 설치되면 모든 노드 - gyp 종속성이 다운로드되지만 여전히 환경 변수가 필요합니다. 유효성 검사 Python은 실제로 올바른 폴더에 있습니다.

환경변수 세팅

setx PYTHON "%USERPROFILE%\.windows-build-tools\python27\python.exe"

cmd를 재시작하고 후 PYTHON 변수 존재 여부 확인

set PYTHON

마지막으로 node module 재설치

npm install <module>

참고
https://code.i-harness.com/ko-kr/q/e6ce22

[JPA] No EntityManager with actual transaction available for current thread

Sat, 29 Aug 2020 00:00:00 GMT

문제

deleteBy.. 메소드 호출시 오류 발생

원인

https://stackoverflow.com/questions/32269192/spring-no-entitymanager-with-actual-transaction-available-for-current-thread

해결

메소드에 @transaction 을 추가하는 방법으로 해결하였다.
잘 모르겠는데… JPA delete transaction 을 찾아봐야겠다.

[TLS] Cipher Suite

Thu, 21 May 2020 00:00:00 GMT

Cipher Suite

TLS에서는 암호화하는 방법을 표준으로 특정하지 않고, server와 client가 합의해서 결정한다.
서로 합의해야 하는 알고리즘은 4가지이다.
— 대칭키 전달 방식,
— 인증서 서명 방식,
— 대칭키 알고리즘,
— HMAC 알고리즘
TLS에서는 서버와 클라이언트가 이 4가지 알고리즘을 세트로 합의하고, 합의된 알고리즘으로 application layer의 내용을 암호화해서 전송한다.
cipher suite는 TLSECDHERSAWITHAES256GCM_SHA384와 같이 표기한다. 이 cipher suite를 읽어보면, 다음과 같이 해석할 수 있다.
— 대칭키 전달 방식은 ECDHE(Elliptic Curve Diffie Hellman Ephermeral)을 사용하며,
— 인증서 서명 방식은 RSA로 서명된 인증서로 상호간의 신원을 확인하고,
— 대칭키 암호화 알고리즘은 AES 256bit와 GCM를 채택하고,
— HMAC 알고리즘으로는 SHA 384를 사용해서 메시지의 무결성을 확인한다.
cipher suite는 여러가지 있다. 그중에서 client가 지원하면서 취약하지 않은 cipher suite의 리스트를 서버에게 알려주면, 서버는 그중에 지원하는 cipher suite를 선택해서 보내 합의한다.

[작업로그] vue 빌드 사이즈 줄이기

Fri, 08 May 2020 00:00:00 GMT

how to enable GZIP compression in stringboot

https://frontbackend.com/spring/how-to-enable-gzip-compression-in-spring-boot

how to compress static files in vue

https://medium.com/@aetherus.zhou/vue-cli-3-performance-optimization-55316dcd491c

vue js bundle 줄이기

https://ui.toast.com/weekly-pick/ko_20190603/

[PKI] 인증서 파일 형식 및 확장자

Sun, 03 May 2020 00:00:00 GMT

1. 인코딩 (확장자로 쓰이기도 한다.)

# der

Distinguished Encoding Representation (DER)
바이너리 DER 형식으로 인코딩된 인증서. 텍스트 편집기에서 열었는데 읽어들일 수 없다면 이 인코딩일 확률이 높다.

# pem

X.509 v3 파일의 한 형태
PEM (Privacy Enhanced Mail)은 Base64인코딩된 ASCII text file이다.
원래는 secure email에 사용되는 인코딩 포멧이었는데 더이상 email쪽에서는 잘 쓰이지 않고 인증서 또는 키값을 저장하는데 많이 사용된다.
-----BEGIN XXX-----, -----END XXX----- 로 묶여있는 text file을 보면 이 형식으로 인코딩 되어있다고 생각하면 된다. (담고있는 내용이 무엇인지에 따라 XXX 위치에 CERTIFICATE, RSA PRIVATE KEY 등의 키워드가 들어있다)
인증서(Certificate = public key), 비밀키(private key), 인증서 발급 요청을 위해 생성하는 CSR (certificate signing request) 등을 저장하는데 사용된다.

2. 확장자

# crt, cer

인증서를 나타내는 확장자인 cer과 crt는 거의 동일하다고 생각하면 된다.
cer은 Microsoft 제품군에서 많이 사용되고, crt는 unix, linux 계열에서 많이 사용된다.
확장자인 cer이나 crt만 가지고는 파일을 열어보기 전에 인코딩이 어떻게되어있는지 판단하긴 힘들다.

# key

개인 또는 공개 PKCS#8 키를 의미

# p12

PKCS#12 형식으로 하나 또는 그이상의 certificate(public)과 그에 대응하는 private key를 포함하고 있는 key store 파일이며 패스워드로 암호화 되어있다.
열어서 내용을 확인하려면 패스워드가 필요하다.

# pfx

PKCS#12는 Microsoft의 PFX파일을 계승하여 만들어진 포멧이라 pfx와 p12를 구분없이 동일하게 사용하기도 한다.

[PKI] 인증서 유효성 검사

Sun, 26 Apr 2020 00:00:00 GMT

(계속)

[작업로그] 인증서 생성 요청 Flow

Mon, 13 Apr 2020 00:00:00 GMT

[작업로그] 서명 생성/검증

Mon, 13 Apr 2020 00:00:00 GMT

#1. 서명 생성

[param]
algo:
privKey: the private key of the identity whose signature is going to be generated.

[code]

Signature signer = Signature.getInstance(algo, "BC");
signer.initSign(this.privKey);
signer.update(plainText);
return signer.sign();

#2. 서명 검증

[param]
algo : the name of the algorithm requested.
pubKey: the public key of the identity whose signature is going to be verified.
plainText
signed: the signature bytes to be verified.

[code]

Signature signer = Signature.getInstance(algo, "BC");
signer.initVerify(pubKey);
signer.update(plainText);
return signer.verify(signed);

[PKI] 공개키 인증서 형식

Mon, 13 Apr 2020 00:00:00 GMT

[PKI] CSR(Certificate Singing Request)

Mon, 13 Apr 2020 00:00:00 GMT

[작업로그] Crontab 설정

Mon, 03 Feb 2020 00:00:00 GMT

작업내역

수정 (편집기 열기)
```
$ crontab -e
```
수정내용
- shell 이 설정되어 있지 않을 경우, bash로 생성한 스크립트는 오류가 발생할 수 있다.

저장 및 종료

^o // 저장 (control + o) 
^x // 종료 (control + x)

참고

https://zetawiki.com/wiki/%EB%A6%AC%EB%88%85%EC%8A%A4_%EB%B0%98%EB%B3%B5_%EC%98%88%EC%95%BD%EC%9E%91%EC%97%85_cron,_crond,_crontab

[작업로그] CertInstallationRes 구현

Mon, 27 Jan 2020 00:00:00 GMT

[ Error & Solv ]

#1. signature marshalling error

에러 메시지

[com.sun.istack.internal.SAXException2:
     @XmlRootElement 주석이 누락되어 "com.autocrypt.v2g.common.message.type.SignatureType" 유형을 요소로 마셜링할 수 없습니다.]

원인

// 작업 시 , SignatureType에 @XmlRootElement 누락
val signatureByteArray = MsgDigest.generateXMLToByteArray(signature, SignatureType::class.java)?: return null

해결

// SignatureType에 anotation 추가
@XmlRootElement(name = "Signature", namespace = "http://www.w3.org/2000/09/xmldsig#")

#2. grammarMsgDef로 EXI Encoding 후 Decoding 시 메시지가 짤려서 나오는 현상

원인
certChain의 namespace 잘못됨
해결
```
msgBody에서 MsgDataTypes 로 변경
```

[PKI] 용어정리

Mon, 27 Jan 2020 00:00:00 GMT

발행자 UID (akID)

발급자의 공개키의 해쉬값
issure DN이 동일할 수 있음
동일한경우 발행자 UID 를 확인하여 발급자를 찾는다

대상자 UID (skID)

내 공캐키의 해쉬값

self sign 인증서의 경우 (RootCA)

subjectDN == issureDN
발행자 UID == 대상자 UID

[Linux] DRBD 작업 내역

Tue, 17 Dec 2019 00:00:00 GMT

DRBD 사용하여 DB 이중화 작업 내역

DRBD

Distribute Replication Block Device
블럭 디바이스를 HA(High Availabilty, 고가용성) 구성을 위한 Network Raid-1(mirroring) 유틸

환경

Ubuntu 18.04
MariaDB 10.1
DRBD 8.9

장치준비

구성

하드웨어 hotlink 연결

두 서버간 파티션 및 drbd 연결 도식화

┌─────────────────────────┐    ┌────────────────────┐        
│  /opt/autocrypt/data2   │    │/opt/autocrypt/data1│        
┌───────────────────────────┐  ┌──────────────────────┐        
│                           │  │         ext4         │        
│            ext4           │──└──────────────────────┐      ┌───────────────────────────┐
│                           │            drbd         ├──────┤            drbd           │
┌───────────────────────────┐─────────────────────────┐      ┌───────────────────────────┐
│            sdb2           │            sdb1         │      │            sdb1           │ 
┌───────────────────────────────────────────────────────┐    ┌─────────────────────────────┐
│                           HDD                         │    │              HDD            │
└───────────────────────────────────────────────────────┘    └─────────────────────────────┘
                      Server1                                         Server2

작업내역

1. 추가된 하드 자동 마운트 작업 (불필요시 skip)

1.1. sdb 파티션 구성

# fdisk /dev/sdb

1.2. 파티션 포맷

# mkfs.ext4 /dev/sdb1
# mkfs.ext4 /dev/sdb2

1.3. 디바이스 UUID 확인

# blkid
/dev/sdb1: UUID="bf5b50eb-5a00-4dc4-b628-243bea114909" TYPE="ext4" PARTUUID="18c5e0b8-01"
/dev/sdb2: UUID="21d5fe61-691c-44fa-9066-d2365a52d45d" TYPE="ext4" PARTUUID="18c5e0b8-02"

1.4. 서버 시작 시 자동 마운트를 위한 UUID 등록 (파티션 포맷 시 UUID가 변경된다)

# vi /etc/fstab
UUID=21d5fe61-691c-44fa-9066-d2365a52d45d /opt/autocrypt/data2    ext4    defaults    0    0

1.5. 파티션 마운트 후 서버 재시작

# mount /dev/sdb2 /opt/autocrypt/data2
# reboot

1.6. 디스크 정보 확인

# df -h

2. hotlink 작업

2.1. hot link?
데이터나 파일의 변경이 발생하면 관련된 다른 프로그램의 데이터나 파일도 변경되도록 지시하는 연결

2.2 인터페이스 확인

ip a

2.2. hotlink용 네트워크 인터페이스 추가

# vi /etc/netplan/파일명.yaml

network:
    ethernets:
        enp0s3:
            dhcp4: true

        # enp0s9  : 테스트 장비 hotlink 네트워크 인터페이스 명
        # address : primary의 경우 addresses 10.1.1.1, secondary의 경우 10.1.1.2
        enp0s9:
            dhcp4: no
            addresses: [10.1.1.1/24]  
            gateway4: 10.1.1.1
    version: 2

2.2. 네트워크 적용

# netplan apply

3. drbd 작업

3.1. drbd 설치
```
# apt install drbd8-utils
```
***추가 내용 hostname 설정

3.2. 설정파일 수정

# vi /etc/drbd.conf

global {
    usage-count yes;
}
common {
    startup {
            wfc-timeout 10;
            degr-wfc-timeout 10;
            outdated-wfc-timeout 10;
    }
    syncer {
            rate 100M;
    }
    protocol C;
}
resource r0 {
net {
after-sb-0pri discard-least-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
    on vpki1 {
            device          /dev/drbd0;
            disk            /dev/sdb1; # drbd 대상 디바이스
            address         10.1.1.1:7789;
            meta-disk       internal;
    }
    on vpki2 {
            device          /dev/drbd0;
            disk            /dev/sdb1; # drbd 대상 디바이스
            address         10.1.1.2:7789;
            meta-disk       internal;
    }
}

3.2. 메타 데이터 생성
```
# drbdadm create-md r0
```
3.3. service 시작
```
service drbd start
```
3.4. Primary 서버 설정 (Primary 서버만 작업)
```
# drbdadm primary --force r0
```
3.5. drbd 파티션 포맷
```
# mkfs.ext4 /dev/drbd0
```

3.6. DBMS 데이터 디렉토리 생성 및 마운트

# mkdir -p /opt/autocrypt/data1
# mount /dev/drbd0 /opt/autocrypt/data1

3.7. 디스크 정보 확인
```
df -h
```

3.8. drdb 상태 확인

# cat /proc/drbd
또는
# drbd-overview
------------------------------------------------
#연결된 상태
Connected Primary/Secondary UpToDate/UpToDate
#싱크 작업 중 상태
SyncSource Primary/Secondary
#연결 시도중 상태
WFConnection Primary/Unknown
#미연결 상태
StandAlone Primary/Unknown

3.9. 미 연결 상태일 경우

# drbdadm connect r0
OR
# service drbd restart

참고 (연결 상태일 경우)

root@vpki1:~# drbd-overview
0:r0/0  Connected Primary/Secondary UpToDate/UpToDate
-----------------------------------------------------------------------------------
root@vpki1:~# netstat -anp | grep 7789
tcp        0      0 10.1.1.1:40083          10.1.1.2:7789           ESTABLISHED -
tcp        0      0 10.1.1.1:7789           10.1.1.2:49725          ESTABLISHED -

4. DB 작업

4.1. MariaDB 설치
```
# apt install mariadb-server
```

4.2. 초기 MariaDB 데이터 백업

# mv /var/lib/mysql ~/백업디렉토리/

4.3. 초기 MriaDB 데이터 /opt/autocrypt/data1 디렉토리로 복사
```
# cp -rf ~/백업디렉토리/mysql/* /opt/autocrypt/data1/
```

4.4. mysql 실행을 위한 링크 생성

# ln -s /opt/autocrypt/data1 /var/lib/mysql

4.5. mysql 디렉토리 owner 변경
```
# chown -R mysql:mysql /var/lib/mysql/
```
4.6. MariaDB 시작
```
# service mysql start
```

참고url

https://wlstnans.tistory.com/128

#### 테스트 내용

스플릿 브레인(Split Brain) 현상
: 일반적으로 클러스터로 구성된 두 시스템 그룹간 네트워크의 일시적 동시 단절현상이 발생 시 나타나는 현상. 클러스터 상의 모든 노드들은 노드 각자가 자신을 primary라고 인식하게 되는 상황을 말한다.

테스트:

 primary : drbdadm down r0  
 secondary: drbdadm primary --force r0  
 primary : drbdadm up r0  
  => Occur split brain

해결:

# drbdadm create-md r0  
# drbdadm up r0  
# drbdadm connect r0  
# service drbd start

모니터링

1. primary

monitoring target : was / db
문제 발생 시 :
- 1. stop was / db / drbd
- 2. ?

2. secondary

monitoring target : drbd-overview or /proc/drbd
check point :

# drbd-overview
0:r0/0  *Connected* Secondary/Primary UpToDate/UpToDate
---------------------------------------------------------
** 문제 발생 시 : status is not 'Connected'

스크립트 시나리오

-. secondary에서 primary로 변경

 # drbdadm primary --force r0

-. check changed state

 # drbd-overview

-. mount device

 # mount /dev/drbd0 /opt/autocrypt/data1

-. check mounted state

# df -h

-. service start : DB, WAS, Primary Script?

-. Secondary Script exit

[AWS] private key permission in Windows

Wed, 28 Aug 2019 00:00:00 GMT

Problem

Solution

1. 속성 -> 보안 -> 고급에서 상속 사용안함 클릭 후 명시적 사용 권한으로 변경

2. administrators 제외 모두 제거

3. 소유자 복사 -> 추가 -> 보안주체 선택 -> 이름 입력 후 이름 확인

4. 아래와 같이 설정이 됐는지 확인 후 적용

[백준] 3085번 사탕게임

Wed, 21 Aug 2019 00:00:00 GMT

목차
1.개발을 하고 싶어요
2.코딩을 잘하고 싶어요

개발을 하고 싶어요

Coding을 잘하고 싶어요

송은영

1. gatsby-cli 설치 및 프로젝트 생성 (lumen 테마 사용)

$ yarn add -g gatsby-cli
$ gatsby new devHistoryBlog https://github.com/GatsbyCentral/gatsby-v2-starter-lumen

2. gatsby 로컬 서버 구동 (기본포트 8000)

$ cd devHistoryBlog
$ gatsby develop

3. github repository 연동

//git remote add origin [repository_url]
$ git remote add origin https://github.com/SangBeo/devHistoryBlog.git

[브랜치 생성]
github 페이지는 최종적으로 master의 파일들이 배포된다.
master에서 gatsby 파일 관리와 gh-pages의 빌드를 같이 하니 난잡해서 보기 좋지 않다.
그래서 개발은 develop 브랜치에서 진행하고 master 브랜치는 gh-pages로 배포할때만 사용한다
-> develop branch : gatsby 파일 구조를 관리
-> master : build 된 파일들을 github 페이지에 배포

3.1. develop 브랜치 생성

//-m 옵션을 이용하여 develop 브랜치로 이동
$ git branch -m develop

3.2. 커밋과 푸쉬

$ git add *
$ commit -m "init commit"
//push 시 -u 옵션을 붙여 이후 push 할때마다 develop 브랜치로 푸쉬한다
$ git push -u origin develop

그럼 위와 같이 develop 브랜치에 소스 push가 된다.

4. gh-pages 설치 및 설정 파일 수정, 그리고 Deploy

$ yarn add --dev gh-pages

4.1. gatsby-config.js 수정

url 수정
pathPrefix 추가 4.2. package.json 필요시 수정

4.3. Deploy

//build 및 master branch로 push
$ yarn deploy

5. 실행

http://sangbeo.github.io/devHistoryBlog

Gatsby 구축

Sun, 18 Aug 2019 00:00:00 GMT

1. gatsby-cli 설치 및 프로젝트 생성 (lumen 테마 사용)

$ yarn add -g gatsby-cli
$ gatsby new devHistoryBlog https://github.com/GatsbyCentral/gatsby-v2-starter-lumen

2. gatsby 로컬 서버 구동 (기본포트 8000)

$ cd devHistoryBlog
$ gatsby develop

3. github repository 연동

//git remote add origin [repository_url]
$ git remote add origin https://github.com/SangBeo/devHistoryBlog.git

[브랜치 생성]
github 페이지는 최종적으로 master의 파일들이 배포된다.
master에서 gatsby 파일 관리와 gh-pages의 빌드를 같이 하니 난잡해서 보기 좋지 않다.
그래서 개발은 develop 브랜치에서 진행하고 master 브랜치는 gh-pages로 배포할때만 사용한다
-> develop branch : gatsby 파일 구조를 관리
-> master : build 된 파일들을 github 페이지에 배포

3.1. develop 브랜치 생성

//-m 옵션을 이용하여 develop 브랜치로 이동
$ git branch -m develop

3.2. 커밋과 푸쉬

$ git add *
$ commit -m "init commit"
//push 시 -u 옵션을 붙여 이후 push 할때마다 develop 브랜치로 푸쉬한다
$ git push -u origin develop

그럼 위와 같이 develop 브랜치에 소스 push가 된다.

4. gh-pages 설치 및 설정 파일 수정, 그리고 Deploy

$ yarn add --dev gh-pages

4.1. gatsby-config.js 수정

url 수정
pathPrefix 추가 4.2. package.json 필요시 수정

4.3. Deploy

//build 및 master branch로 push
$ yarn deploy

5. 실행

http://sangbeo.github.io/devHistoryBlog

Blog by Eunyoung

GSLB에 매핑된 VIP 변경 작업 기록

✔︎ GSLB에 새로운 VIP 추가

✔︎ 1% 투입 후 테스트

✔︎ dig 명령어로는 1% 테스트가 잘 안된다?

당신의 파드는 graceful 하게 종료되고 있을까?

1. Kubernetes에서의 Graceful Termination

✔️ preStop Hook

✔️ terminationGracePeriodSeconds

✔️ Kubernetes에서 파드가 종료되는 순서

2. 컨테이너에서의 Graceful Termination

✔️ Shell 방식

✔️ Exec 방식

✔️Shell 방식의 컨테이너 내 애플리케이션 종료

✔️그래서 어떻게 적용해야하나?

3. 테스트 해보자

✔️Exec 환경 테스트

✔️Shell 환경 테스트

4. 애플리케이션이 SIGKILL 신호를 못받으면 무엇이 문제가 될까?

✔️ 맺고 있었던 DB 커넥션 등이 클라이언트에서 강제 종료가 된다.

✔️ 애플리케이션 종료 리스너가 수행하지 않는다.

✔️ 기타

프로메테우스 삽질기

1. 무엇을 표현하고 싶었는가?

✔︎ 서비스 지표

✔︎ traffic (트래픽)

✔︎ atency (지연)

✔︎ errors (오류)

2.︎ 무엇이 어려웠는가? (왜 안맞나?, 표현이 어려웠던 것은 무엇인가? …)

2.1. promQL 문법의 이해

✔︎ http_server_requests_seconds_count{uri="/api"}[5m]

✔︎ increase(http_server_requests_seconds_count{uri="/api"}[5m])

2.2. 프로메테우스에서 수집하는 메트릭 중에 무엇을 사용했나?

✔︎ http_server_requests_seconds_count

✔︎ http_server_requests_seconds_bucket

2.3. 지표를 표현하기 위해서 어떤 함수를 사용했는가?

✔︎ 단순히 카운터로 누적 수를 계산하면 될꺼 같은데, 왜 increase, rate 를 사용했을까?

✔︎ increase

✔︎ rate

✔︎ histogram_quantile

✔︎ 왜 소수가 나올까?

2.4. 그래서 그라파나에서 어떻게 사용하는데?

✔︎ from, to(range) 의 총 수치 나타내기

✔︎ 시간 흐름에 따른 수치 나타내기

2.5. 왜 기대한 값이 나오지 않을까?

✔︎ 소수로 나타나지는 결과

✔︎ 카운터 리셋 감지시에 기대와 다른 increase 결과

2.5. 아쉬운 점

rateLimit 고민 기록

요구사항은,

구현방법

구현방법1) 고정 윈도 카운터

고정 윈도 카운터의 단점

구현방법2) 이동 윈도우

이동 윈도우의 단점

그래서 결론은?

스프링 배치작업 기록

1. 요구사항

2. 배치 스케줄러를 어떻게 수행할 것인가?

2.1. k8s cronJob + api 서버

2.2. jenkins + api 서버

2.3. jenkins + springbatch

3. spring batch 작업을 진행하면서 겪은 일

3.1. multi datasource 설정

3.2. JPA로 수행되는 CUD 쿼리가 수행이 안되는 현상.

3.3. index가 없을 경우 update, delete 쿼리가 수행되면?

4. Transaction 이 너무 긴 현상

Circuit 적용 고민

1. Client Bean 세분화

✔︎ 구조 개선

✔︎ 적용 효과

2. 불필요한 Pod 수 조정

✔︎ 적용 효과

3. Sliding Window 타입 결정

✔︎ 적용 효과

4. Fallback 적용 여부

✔︎ Fallback이란?

5. 최종 정리

nginx proxy serving 이슈

1. 구조 파악

✔︎ `http_server_requests_seconds_count{uri="/api"}[5m]`

✔︎ `increase(http_server_requests_seconds_count{uri="/api"}[5m])`

✔︎ `http_server_requests_seconds_count`

✔︎ `http_server_requests_seconds_bucket`