지식 줍줍 🐿️

RESTful, 비효율적 텍스트 기반 메세지 프로토콜

RESTful 서비스는 HTTP 1.x 와 같은 텍스트 기반 전송 프로토콜로 구축되고, JSON 처럼 사람이 읽을 수 있는 텍스트 포맷을 활용함.
그런데, 서비스간 통신을 할 경우(common server - user server 이런식?) 사람이 읽을 수 있는 텍스트 기반 포맷을 사용할 필요가 없음!
→ 비효율적이라 판단함. 

클라이언트가 서버로 전송할 바이너리 콘텐츠를 만든 후, 바이너리 구조체를 텍스트로 변환함.
그리고 네트워크를 통해 텍스트로 전송하고 서비스측에서 다시 바이너리 구조로 변환함.
→ 이럴바에 비즈니스 로직으로 바로 매핑될 수 있는 바이너리 형식으로 쉽게 전송하는것이 낫다고 판단!

RPC

설명

클라이언트 - 서비스 애플리케이션을 구축하는 데 널리 사용되는 프로세스간 통신 기술
RPC을 통해 클라이언트는 로컬 메서드를 호출하는 것처럼 원격으로 메서드 기능을 호출할 수 있다.

gRPC

설명

구글에서 만든 오픈소스 원격 프로시저 호출 시스템.

※ 원격 프로시저
별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술이다.
다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.

로컬함수를 호출하는 것 만큼 쉽게 분산된 이기종 애플리케이션을 연결/호출/운영/디버깅 할 수 있는 프로세스 간 통신 기술.
주로 통신에 동기식 요청-응답 스타일을 사용하나, 초기 통신이 설정되면 완전 비동기식이거나 스트리밍 모드에서 작동할 수 있다.
프로토콜 버퍼와 HTTP/2 프로토콜 위에 구축됨.

※ 프로토콜 버퍼
구조화된 데이터를 직렬화하고자 언어에 구애 받지 않고 플랫폼 중립적이며 확장 가능한 메커니즘인 데이터 직렬화 프로토콜.
데이터가 직렬화되면 이 프로토콜은 일반 JSON 페이로드보다 크기가 작고 강력한 형식의 바이너리 페이로드를 생성함.
→ HTTP/2라는 바이너리 전송 프로토콜을 통해 전송!

구성 프로젝트

● 인터페이스 정의
‣ 서비스를 사용하는 방법, 원격으로 호출되는 메서드 종류, 해당 메서드를 호출하기 위한 파라미터, 메세지 형식등을 포함.
‣ *.proto 파일로 정의(=인터페이스 정의 언어), 이는 프로토콜 버퍼 메세지로 RPC 메서드 파라미터 및 반환 타입과 함께 gRPC 서비스를 일반 프로토콜 버퍼 형식으로 정의함.
‣ 프로토 파일에서 코드를 생성하고자 gRPC 플러그인이 사용된다.

※ gRPC 플러그인
gRPC 서버측, 클라이언트측 코드 뿐만이 아니라
정의된 메세지 타입의 데이터 지정, 직렬화, 데이터 취득의 일반 프로토콜 버퍼 코드도 생성할 수 있다.

● 서버
‣ 인터페이스 정의가 완료되면, protoc을 사용해 서버측이나 클라이언트 측 코드를 생성할 수 있다.
‣ 스켈레톤(server skeleton) 이라는 서버측 코드 생성가능. 저수준의 통신 추상화를 통해 서버 측 로직 단순화 가능.
  (gRPC 관련 상위 서비스 클래스를 오버라이드 하여 스켈레톤(server skeleton) 이라는 서버측 코드 구현!)
‣ 로직 구현 후, 서버 실행하여 클라이언트 요청 수신 및 응답!

● 클라이언트
‣ 스텁(client stub) 이라는 코드를 생성할 수 있음. 메소드 함수 호출하는것처럼 쉽게 클라이언트측에서 원격 호출 가능.
‣ 스텁(client stub)은 서버와 동일한 메서드를 제공하는데, 클라이언트 코드에서 메서드들의 호출을 네트워크상 원격 함수 호출로 변환함.

으로 구성.

클라이언트-서버 흐름

▶︎ 네트워크 통신은 HTTP/2를 통해 이루어짐
▶︎ (java 기준) *.proto 파일 생성 후, 빌드하면(물론 관련 패키지 import하고,,) grpc 사용관련 클래스들이 생성되고, 이를 서버와 클라이언트가 사용하는것으로 확인

gRPC 장점

• 프로세스간 통신 효율성이 증대
텍스트 형식 대신 프로토콜 버퍼 기반 바이너리 프로토콜을 사용하여 gRPC 서비스 및 클라이언트와 통신하며,
HTTP/2 프로토콜 버퍼로 구현되기에 프로세스 간 통신 속도가 매우 빨라진다.

• 간단 명확한 서비스 인터페이스 스키마
먼저 서비스 인터페이스를 정의 하고나서 구현 세부 사항을 작업한다. (구현이 간단)

• 엄격한 타입 점검 형식
프로토콜 버퍼를 사용하기에 gRPC 서비스 계약은 애플리케이션간 통신에 사용할 데이터 타입을 명확하게 정의한다.

• 폴리글랏
여러 프로그래밍 언어와 작동하도록 설계됨. 특정언어에 구애 안받음!

• 이중 스트리밍

• 유용한 내장 기능 지원

• 클라우드 네이티브 생태계와 통합
넷플릭스 도커 시스코 등에서 채택

gRPC 단점

• 외부 서비스 부적합
외부 클라이언트에 제공하려는 경우는 적합하지 않을 수 있음.
계약 기반이고, 강력한 타입 속성을 갖기 때문
그래서 gRPC 게이트웨이는 이 문제를 해결책으로 설계됨.

• 서비스 정의의 급격한 변경에 따른 개발 프로세스 복잡성
gRPC 서비스가 재정의되면, 클라이언트 및 서버 코드 모두 변경을 해야함;

• 상대적으로 작은 생태계
브라우저 및 모바일 애플리케이션에서 gRPC 지원은 초기 단계라고함.

..

참고

책: http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791161754635
링크: https://thenewstack.io/grpc-remote-procedure-calls-in-a-nutshell/

링크: https://grpc.io/

링크: https://ko.wikipedia.org/wiki/%EC%9B%90%EA%B2%A9_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80_%ED%98%B8%EC%B6%9C

목적

작업 결과물(Springboot jar file, gradle 이용)을 AWS EC2에 반영해보기
‣ jenkins 서버에 작업 결과물을 빌드 / 배포하는 셈.
‣ 작업 결과물은 개인 github 에서 가져옴! (github 의 webhook 기능 이용) 

작업순서

1️⃣ EC2 생성 및 터미널 접속
‣ EC2 생성방법은 생략함. (t2.micro 이용 (메모리 1GB..jenkins 배포는 되긴함!..), aws linux 이용)
‣ pem key 소중하게 보관하도록하기 (ssh 폴더에 이동시키는 등)

1-1. EC2 보안그룹 설정하기 (인바운드 규칙 설정)

1-2. EC2 인스턴스 서버 접속 시도 (2가지)

- pem key 을 .ssh 폴더로 옮겨주는 작업을 추가함.

$ sudo mv {pem key 위치경로}/jenkins.pem ~/.ssh

⭐️ 참고로 실습의 상황이기에 EC2 서버를 내리고 올리는 경우가 존재한다면
[1. ssh 으로 접속하는 방법] 으로 하는것이 맞을듯. (IPv4가 서버 재시작시 바뀜)

  1-2-1. ssh 으로 접속하는 방법

# ssh -i {pem key 경로} {ec2 인스턴스 계정ID}@{퍼블릭 IPv4 DNS or 퍼블릭 IPv4 IP}
$ ssh -i ~/.ssh/jenkins.pem ec2-user@ec2-2-3-4-5.ap-northeast-2.compute.amazonaws.com

# root 권한이 아닌 경우 
$ sudo ssh -i ~/.ssh/jenkins.pem ec2-user@ec2-2-3-4-5.ap-northeast-2.compute.amazonaws.com

  1-2-2. ~/.ssh/config file 에 접속정보 추가 후, Host 명으로 접속하는 방법

$ vi ~/.ssh/config 

# 열어서 아래내용 추가
Host test_jenkins

 User ec2-user
 HostName ec2-2-3-4-5.ap-northeast-2.compute.amazonaws.com
 IdentityFile ~/.ssh/jenkins.pem
 
# 그리고 저장 (:wq!)
 
# 접속시도는 아래와 같이 함. (root 권한 아닌 경우 sudo ssh ~)
$ ssh test_jenkins

💥 그런데, Host 명으로 접속 시도중 오류가 발생했다면 ? 

> pem key 권한을 변경해주니 접속이 가능함! (chmod 400 ~ 나에게만 읽기 권한 설정) 

2️⃣ EC2 서버 접속 후, 프로그램 설치 및 서버 셋팅

2-1. java 설치
   ‣ 나의 경우, aws linux을 사용했기에 해당문서 ← 를 참고하여 설치함 

2-2. 타임존 변경 (한국 시간)

$ sudo rm /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

# 날짜 확인
$ date

2-3. 호스트네임 변경

$ sudo hostnamectl set-hostname mungmang-jenkins
$ sudo reboot

# 몇분 후 다시접속

# 확인
$ hostname

2-4. jenkins 설치

# jenkins repository 에 설정파일 생성 
$ sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
$ sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key

# jenkins 설치
$ sudo yum install jenkins

# jenkins 실행
$ sudo systemctl start jenkins

# 만약 부팅시 가능하게 설정하려면 다음도 추가
$ sudo systemctl enable jenkins

2-5. jenkins 접속 및 플러그인 설치

.. 플러그인 설치 후,
jenkins 유저 등록 화면에서 로그인할 계정정보 입력 ↓ ↓ ↓ (계정명 및 암호로 jenkins 로그인 가능!)

2-6. gradle 설치 https://docs.gradle.org/6.9.1/userguide/installation.html 참고함

$ mkdir /opt/gradle
$ unzip -d /opt/gradle gradle-6.9.1-bin.zip
$ ls /opt/gradle/gradle-6.9.1

$ export PATH=$PATH:/opt/gradle/gradle-6.9.1/bin
$ gradle -version

2-7. git 설치 https://gamoo12.tistory.com/205 참고함

$ sudo yum update -y
$ sudo yum install git -y
$ git version

3️⃣ github 설정

3-0. 반영할 프로젝트는 있다고 가정 (작업 결과물)
3-1. EC2에서 ssh key 생성

$ cd ~/.ssh
$ ssh-keygen

# id_rsa key 생성

3-2. github project 내 XXX.pub key 등록 필요
    3-2-1. https://github.com/{git계정}/{git프로젝트}/settings/keys/new 이동 

$ cat ~/.ssh/id_rsa.pub

# ssh-rsa ~ 내용을 복사

3-3. github 프로젝트 내 webhook 설정필요
    3-2-1.https://github.com/{git계정}/{git프로젝트}/settings/hooks/new 이동 
        • Payload URL : http://{ec2에 jenkins 띄운 주소 (ex. ec2~~:8080}/github-webhook/ 입력
        • Content type :  application/json

4️⃣ jenkins 설정

1. Credentials 등록 필요 (github 🔛 jenkins 연결유도)

Jenkins 관리 > Manage Credentials > Stores scoped Jenkins 의 Jenkins 클릭 > Global credentials
 
Kind : SSH Username with private key 선택
Private Key: .ssh/id_rsa 을 입력

2. 빌드 및 실행 (Dashboard > 대상 프로젝트 > 구성) 

빌드유발
GitHub hook trigger for GITScm polling 선택 

[플러그인 설치 필요] post build task (아래의 내용 기입, 작업 결과물 jar 파일로 만든 것을 실행)
JAR=$(ls -tr /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs | grep jar | tail -n 1)
echo $JAR
nohup java -jar /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs/$JAR &

• $(ls -tr /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs | grep jar | tail -n 1) : jar 파일명 추출 위함.
• nohup java -jar /var/lib/jenkins/workspace/{jenkins working directory 명}/build/libs/$JAR & : jar 실행위함, nohup 을 붙임으로써 백그라운드에서 실행! (터미널 종료 하더라도 작업 결과물은 계속 서버에 실행되어 있도록 하기위함)

느낀점

‣ 삽질을 줄일 필요성이있겠다.
‣ 파이프라인 작성을 이용한 배포도 한번 해보아야 할것같다. 
‣ docker..kubernetes 등을 이용한 배포방법도 해보아야 할것같다. + 다른 서버에 배포하는 방법 등 

참고

책: 스프링 부트와 AWS로 혼자 구현하는 웹 서비스

링크: https://lemontia.tistory.com/656

리액티브 프로그래밍

변화의 전파와 데이터 흐름과 관련된 선언적 프로그래밍 패러다임

• 변화의 전파와 데이터 흐름: 데이터가 변결될 때 마다 이벤트를 발생시켜서 데이터를 계속적으로 전달
• 선언적 프로그래밍: 실행할 동작을 구체적으로 명시하는 명령형 프로그래밍과 달리 선언형 프로그래밍은 단순히 목표를 선언.
• 데이터 발행(Observable), 가공(Operator), 구독(Subscribe) 흐름으로 구성
• 멀티스레딩 환경에서 둘 이상의 스레드가 하나의 변수를 사용하면서 발생하는 이슈를 방지하여 개발이 가능함. (stream..)

참고
https://www.youtube.com/watch?v=2McwNWO8MIw&list=PLr-ObTx8qMl9APSlvIhAah1mq3tyD1AYN

서버간 통신 중 지연 발생시 해결방법

    ‣ 네트워크 타임아웃 설정
    ‣ 대기중 요청수 제한
    ‣ 여러 부하 분산 기법 구현
    ‣ 서킷 브레이커 패턴과 폴백 구현 설정

부하 분산 룰(rule)

스프링 클라우드 넷플릭스에서는 다양한 부하분산 알고리즘을 제공해주는데,
넷플릭스OSS 에서는 해당 알고리즘을 룰이라고 함

종류

    ‣ RoundrobinRule
        → 라운드 로빈 사용, 유입되는 요청은 모든 인스턴스에 순차적으로 분산. 기본!

    ‣ AvailabilityFilteringRule
        → 세번 연결 실패하면 서킷 차단됨.
        → 서킷 차단 및 동시연결이 많은것으로 표시된 서버 제외.
        → RoundrobinRule 을 베이스 클래스로 사용.

    ‣ WeightedReponseTimeRule
        → 인스턴스로 전달되는 트래픽의 규모는 인스턴스의 평균 응답시간에 반비례.
        → 응답시간 길수록 더 작은 가중치 가짐.
        → 부하분산클라이언트는 모든 서비스 인스턴스의 트래픽과 응답시간 기록함.

    ‣ BestAvailableRule
        → 서킷브레이커가 차단된 서버를 제외하고 동시 요청을 가장 적게 받은 서버를 선택.

호버플라이 (Hoverfly)

설명

HTTP 서비스를 스텁하고 시뮬레이션하는 가벼운 시각화 도구.
DSL 정의에서 메서드 하나를 호출해 모든 시뮬레이션중인 서비스의 메서드에 지연을 쉽게 추가 가능.
    → maven or gradle 에 hoverfly-java import 필요, JUnit에 @ClassRule 정의 필요. 

실습

‣‣‣ 실습 코드 링크 🙂

• junit test 실행시 hoverflyRule 을 먼저 실행하고 각 테스트메소드를 실행한다. (ex. test() 실행)
• test() 메소드를 호출한 결과는 아래에 있다. ↓ ↓ ↓ ↓ ↓

※ https://www.baeldung.com/hoverfly 에도 잘 설명되어 있다. (사실 해당기능을 많이 쓰는지는 잘 모르겠다;)

리본(Ribbon)

설명

- Client LoadBalancer 이다.
- 개발자가 로드밸런싱 기능 구현을 가능하도록 한다. (L4 사용없이)
- 클라이언트 서버가 로드밸런싱을 한다! 
- 유레카랑 사용시 강력크하다 👍
- 더이상 업그레이드를 하지 않음.

※ 보통은 물리적으로 L4 switch 을 이용하여 로드밸런싱 처리를 할것이다.
이를 이용시 추가 서버비용 등이 발생할것이다.
이에따른 절차도 필요할것으로 보인다. 

실습 

‣‣‣ 실습 코드 링크 🙂

🔆 서버간 통신하여 로드밸런싱 처리 확인: Ribbon 적용 서버에서 Demo1 서버 호출 (포트를 여러개로 정의하여 서버띄우기)

• Ribbon 적용 서버

# .. gradle 파일 내 아래의 내용을 추가함 

implementation 'org.springframework.cloud:spring-cloud-starter-netflix-ribbon:2.1.4.RELEASE'

→ 빨간박스를 보면, demo1 으로 도메인을 정의해놓았다.
이는 application.yml 의 demo1: ribbon: listOfServers 정보를 호출하도록 한 것이다. (내부적으로 인터셉터 처리를 한다고함)

• Ribbon 적용 서버에서 호출할 서버 실행구성 

...그리고 테스트! (API 호출)
로드밸런싱 처리가 됨! 왔다갔다,, 서버별 API 호출 결과 로그를 확인할 수 있다.

히스트릭스 (Hystrix)

설명

- 분산시스템 내에서 서비스 간의 액세스 지점을 격리하고, 서비스 전반에 걸쳐 계단식 오류를 중지하고, 폴백 옵션을 제공하여 이를 수행
- RxJava 에 의해 만들어짐
- Failure as a First class citizen
   → 분산시스템에서는 실패를 1급 시민으로 간주.
- 더이상 업그레이드를 하지 않음. 

실습

‣‣‣ 실습 코드 링크 🙂

💥 서버(PirServer → Demo1Server 호출)간 통신 중, 에러발생 유도

1️⃣ Hystrix 미적용: 에러 노출 확인

2️⃣ Hystrix 적용: @HystrixCommand 및 fallback 적용

@HystrixCommand
- 메소드 호출시 메소드 실행 성공/실패 결과를 통계냄
- 통계에 따라 서킷 오픈 여부를 판단하고 조치함.

※ 서킷 오픈
주어진 시간동안 호출제한 / 에러반환 함
조기차단하여 본인을 보호함

- 정의해놓은 모든 메소드는 정해진 응답시간 내에 반환되어야 함. 그렇지 않으면 Exception 발생 & fallback 정의 수행

⭐️ Hystrix 보단 Resilience4j 을 사용하는것이 좋음.
- Resilience4j 가 Java8 지원 및 함수형 프로그래밍을 지원해준다고 함.

참고

책: 마스터링 스프링 클라우드
링크: https://www.youtube.com/watch?v=K4laj5cDYLg&list=PL9mhQYIlKEhdtYdxxZ6hZeb0va2Gm17A5&index=5 

서비스 디스커버리 (Service Discovery)

설명

서비스 클라이언트가 다른 서비스를 호출시, 서비스의 위치(IP, port) 를 알아낼 수 있는 기능
관련 오픈소스로 넷플릭스 OSS의 유레카(Eureka)가 존재!

유레카 (Eureka)

설명

서버가 새롭게 시작되면 그것을 감지하여 자동으로 추가되고, 서버가 종료되면 자동으로 목록에서 삭제하기 위한 방법 ?!
유레카와의 통합을 위한 스프링 클라우드 라이브러리는 클라이언트와 서버 두부분으로 구성되어있다!

    ‣ 서버
      등록된 서비스의 목록을 수집하기 위한 API & 새로운 서비스를 네트워크 위치 주소와 함께 등록하기 위한 API 으로 구성
      각 서버의 상태를 다른 서버로 복제해 설정하고 배포함으로써 가용성 높일 수 있다!
      서비스의 각 인스턴스로부터 생존신호(heartbeat) 메시지를 받는다. 설정된 기간동안 생존신호를 받지 못하면 레지스트리에서 서비스가 삭제된다.

    ‣ 클라이언트 
      애플리케이션 시작 후 등록 & 종료 전 등록 해제를 담당하고 유레커 서버로부터 주기적으로 최신 서비스 목록을 받아옴!

실습

• eureka server 1개 (eureka server) , client server 2개 (demo1, demo2)

    ‣ eureka.client.service-url.defaultZone 에는 유레카 서버 여러개 설정도 가능하다

    ‣ @EnableDiscoveryClient: spring-cloud-commons에 존재
    ‣ @EnableEurekaClient: spring-cloud-netflix에 존재하며, 유레카만을 위해 작동

    ‣ spring-cloud-starter-eureka-server vs spring-cloud-starter-netflix-eureka-server : 차이없음. 근데 netflix 붙은것을 권장하는듯

참고

링크: https://bcho.tistory.com/1252

링크: https://stackoverflow.com/questions/49885718/difference-between-spring-cloud-starter-eureka-server-and-spring-cloud-starte

책: 마스터링 스프링 클라우드

스프링 클라우드 (Spring Cloud)

‣ 분산/버전관리, 서비스 등록 및 검색 가능, 라우팅, 서비스간 호출, 부하분산, 회로차단기, 분산메세지 등의 기능을 사용할 수 있는 도구이다.
‣ https://spring.io/projects/spring-cloud

‣ 스프링부트 버전, 스프링클라우드 버전 유의해서 사용 필요!

12-팩터 앱(The Twelve-Factor App)

‣ 확장 가능하고 쉽게 클라우드 플랫폼에 배포할 수 있음.
‣ 지속 배포 프로세스에 따라 배포되는 Software as a Service(SaaS)를 개발하는 방법론.
‣ 스프링 부트 & 스프링 클라우드는 12-팩터룰에 부합하는 애플리케이션 만드는 기능 & 요소 제공
‣ https://12factor.net/ko/

※ Software as a Service(SaaS)
서비스 사업자가 인터넷을 통해 소프트웨어를 제공하고 사용자가 인터넷상에서 이에 원격 접속해 해당 소프트웨어를 활용하는 서비스 모델.
ERP..CRM..SLACK..

‣ https://medium.com/dtevangelist/12-factors-%EB%9E%80-b39c7ef1ed30

넷플릭스(Netflix) OSS

‣ 모놀리식 애플리케이션 기반 전통적 개발 모델 → 마이크로서비스 기반 개발 방식으로 전환한 선구자
‣ 많은 오픈소스가 존재하며, 유레카(Eureka), 히스트릭스(Hystrix), 리본(Ribbon), 줄(Zuul) 등과 스프링 클라우드와 통합됨.

유레카(Eureka)

‣ 서비스 디스커버리 (전화번호부 책)
    → 외부의 서비스들이 마이크로서비스를 검색하기 위해 사용되는 개념
    → 클라이언트가 로드밸런서 or API Gateway을 전달하게되면 serviceDiscovery 에 전달되어 필요 정보를 찾음
‣ 서비스 정보 및 위치정보 확인 등 (Naming server)
‣ 서버가 새롭게 시작되면 그것을 감지하여 자동으로 추가되고, 서버가 종료되면 자동으로 목록에서 삭제하기 위한 방법.

‣ 클라이언트 & 서버로 구분
    • 클라이언트 (discovery client)
          → 애플리케이션의 일부로 원격 디스커버리 서버에 연결하는 일을 담당
          → 연결되면 서비스 이름 & 네트워크 위치를 담은 등록 메세지를 보냄
          → 현재 마이크로서비스가 다른 마이크로서비스의 종단점을 호출해야 할 경우, 서버로부터 등록된 서비스 목록을 담은 최신의 컨피규레이션(설정정보)를 가져옴.
          → 서버로부터 데이터를 가져와 캐싱하고 주기적으로 변경사항 체크한다.
          → 유레카 서버가 멈추더라도 서비스들끼리 통신이 가능하다! 서비스 레지스트리를 로컬에 캐싱했기 때문
          → spring-cloud-starter-netflix-eureka-client 사용

    • 서버 (Service registry)
          → 각 서비스들로부터 생존신호? 메세지를 받고, 메세지를 못받으면 레지스트리에서 서비스 삭제된다.
          → 독립적인 스프링 부트 애플리케이션으로 설정되고 실행됨. 각 서버의 상태를 다른 서버에 복제해 가용성(=서비스 정상 사용 가능정도)이 높음.
          → pring-cloud-starter-netflix-eureka-server 사용

히스트릭스(Hystrix)

‣ 서킷브레이커패턴 구현 도와주는 라이브러리 
‣ 폴백(fallback) 로직 쉽게 구현 가능
‣ spring-cloud-starter-hystricx 스타터 사용

※ 서킷 브레이커 패턴 (circuit breaker pattern)
성공 및 실패 요청 횟수를 센 다음, 에러 비율이 가정된 임계치를 넘으면 차단 발생 및 이후 실패처리한다.
→ 문제되는 부분(느린부분)을 특정 호출을 감지하여 스레드를 소진하지 않고 빠르게 실패시켜 버림(원격 자원 사용 부분 제거)
→ 다른서비스에 영향 안가도록!
지정된 시간이 지나고 나면, 재요청 후 서킷은 닫혀 정상처리가 되도록 한다. 

리본(Ribbon)

‣ 클라이언트 로드밸런서 역할,, 근데 비동기 처리가 잘 되지 않음,, 잘 사용 안하게됨
‣ IP..port..호출이 아닌 이름만 가지고 호출이 가능... 
‣ 클라이언트 측 부하 분산기
‣ HTTP, UDP, TCP 등 가장 유명한 프로토콜 지원
‣ 동기방식의 REST호출, 비동기, 리액티브 모델도 지원
‣ 서비스 디스커버리, 캐싱, 일괄처리, 장애 내성과 통합 가능.
‣ spring-cloud-starter-ribbon 스타터 사용
‣ springboot 2.4 이후 Maintenance 상태 

줄(Zuul)

‣ API 게이트웨이 or API Service, Edge Service
‣ JVM 기반 라우터, 서버 측 부하 분산 or 일부 필터링 수행
‣ 인증, 부하 평균 분배, 정적 응답 처리, 부하 테스트 등에 사용.
‣ 설정 가능 및 독립적 스프링 부트 애플리케이션으로 실행됨.
‣ spring-cloud-starter-zuul 스타터 사용
‣ springboot 2.4 이후 Maintenance 상태 

✻ 최근에는 Ribbon,, Zuul 보단, Spring Cloud Gateway 을 사용하는것을 권장하고 있다고 함.
https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now#spring-cloud-netflix-projects-entering-maintenance-mode

https://happycloud-lee.tistory.com/218​

페인(Feign)

‣ REST Client
‣ Interface 선언을 통해 자동으로 HttpClient 을 생성 
‣ 웹 서비스 클라이언트를 쉽게 작성하도록 도와줌.
‣ 관심사 분리 (리턴값만 관심,, 어떤 URL 인지 어떻게 응답값을 파싱할지는 관심없음)
‣ spring-cloud-starter-feign 스타터 사용
‣ 리본 클라이언트와 통합돼 디스커버리 서비스와 통신, 부하분산 같은 기능 제공.

분산 컨피규레이션 관리

‣ 설정정보 파일을 프로젝트 내부가 아닌, 외부에서 관리하는것 (중앙화 된 저장소에서 구성 요소 관리)
‣ 각 서비스를 다시 빌드하지않고 바로 적용! (중앙에 있으므로)
‣ 서버는 단 하나의 중앙 장소, 애플리케이션을 위한 모든 외부 속성이 모든 환경에 대해 서버에서 관리됨. (key, value.. yml file..)
‣ 설정 파일은 파일 시스템 또는 서버 클래스 경로에 있을 수 있다. (vault..)

※ Vault 
토큰 및 패스워드 자격증명을 관리할 수 있는 오픈 소스 도구
해시코프(HashCorp)에서 만듬
자격 정보 등을 안전한 장소에 저장이 가능하여 보안이슈에 도움이 될 수 있다.
API 을 통해 쉽게 접근 가능 (API는 기본 인증으로 보호됨)
키/공개 키 인증을 사용한 SSL 연결 설정도 할 수 있다.

‣ spring-cloud-config-server 의존성 추가하여 활성화

컨설(Consul)

‣ 넷플릭스 리본과 동적 라우터, 넷플릭스 Zuul의 filter를 지원
‣ spring-cloud-starter-consul-discovery 의존성 사용

아파치 주키퍼(Apache Zookeeper)

‣ 컨피규레이션과 이름을 유지하는 중앙 서비스로 분산 동기화, 그룹 서비스를 가능하게 함. 
‣ 분산 처리된 메세지 큐 정보들 관리, kafka 서버 가동하려면 zookeeper가 구동되어 있어야 함.
‣ 클라이언트 측에 주키퍼를 사용한 서비스 디스커버리를 사용하려면 spring-cloud-startet-zookeeper-discovery, 아파치 큐레이터를 의존성에 포함.
‣ 분산 컨피규레이션 클라이언트를 활성화 하기 위해서는 spring-cloud-starter-zookeeper-config 의존성을 추가필요.

분산추적

슬루스(Sleuth)

‣ 하나의 요청을 여러 마이크로서비스로 처리할때 이어지는 요청을 연관지음
‣ Slf4j, MDC로 개발되었다.
‣ spring-cloud-starter-sleuth 의존성 추가하여 활성화

※ Slf4j
로그백 log4j, logging 등과 같은 특정 로깅 프레임워크의 추상화 퍼사드(Facade=커다란 코드부분에 대해 간략화된 인터페이스를 제공)를함

※ MDC (mapped diagnostic context)
다양한 소스의 로그 출력을 구분하고 실제 범위에 없던 부가 정보를 추가하는 솔루션 

메세징

버스(bus)

‣ 분산시스템의 노드(마이크로서비스)를 경량 메세지 브로커(RabbitMQ)와 연결
‣ 상태 및 구성에 대한 변경사항을 연결된 노드에게 전달 (마이크로 서비스에게 변경사항을 알려줌)
‣ 컨피규레이션 변경 이벤트의 전달 등 공통 오퍼레이션을 위한 분산 메세징 기능을 사용할 수 있다.

스트림(Stream)

‣ 메세지 중심 마이크로 서비스로 구성된 시세틈을 개발하기 위한 올바른 프레임워크
‣ 두개의 바인더가 존재 (AMQP, Apache Kafka)
‣ 스프링 인테그레이션에 기반. 종단점, 채널, 애그리게이터, 트랜스포머와 같은 대부분의 엔터프라이즈 통합 패턴을 지원하는 프로그래밍 모델을 제공
‣ 마이크로시스템 내의 애플리케이션은 스프링 클라우드 스트림 입력 & 출력 채널을 통해 통신함. 
‣ 구독/게시 등 메세지 공유 토픽을 통해 전파. (웹소켓 통신방식 같은건가,,)

※ AMQP (Advanced Message Queue Protocol)
메세징 프로토콜 (MQ(메세지큐) 기반)
HTTP 프로토콜과 달리 네트워크 프로토콜의 정의 뿐 아니라 서버 측 서비스와 동작 방식도 정의한다.
관련 미들웨어 : RabbitMQ, Erlang
메세지브로커
오픈소스 메세지 소프트웨어
https://www.youtube.com/watch?v=80y2C54KPxg
받는 소비자 중심

※ Apache Kafka
Scala언어로 개발된 오픈소스 메세지 브로커 프로젝트
이벤트브로커 (메세지 브로커 기능 포함)
분산 스트리밍 데이터 처리하기 위한 목적으로 설계된 오픈소스 메세징 플랫폼
메세지 발행/구독 시스템 (Pub/Sub)
보내는 생산자 중심

클라우드 플랫폼 지원

‣ 피보탈..SQS,,SNS,,ElasticCache,,RDS,,등이 있다.
‣ 스프링 클라우드 펑션 프로젝트가 있다. FaaS(Function-as-a-Service),,AWS Lambda
‣ SMTP..rabbitMQ,,Redis,,

보안관리 활성화

‣ spring-cloud-starter-security 의존성 추가

릴리즈 트레인

‣ 하위 프로젝트의 혼란을 피하기 위해 릴리즈를 버전이 아닌 이름으로 구분
‣ BOM(Bill of materials)에 기반 → 아티팩트 버전을 독립적으로 관리하는 표준 메이븐 개념.
‣ https://spring.io/projects/spring-cloud-stream

참고

링크: https://m.blog.naver.com/quart21c/173614581

링크: https://coe.gitbook.io/guide/gateway/zuul

링크: https://sup2is.github.io/2020/04/12/spring-cloud-hystrix-circuit-breaker-with-fallback.html

책: http://www.yes24.com/Product/Goods/66581779

링크: http://blog.skby.net/amqp-advanced-message-queue-protocol/

강의: https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4/lecture/68407?tab=curriculum&volume=1.00&speed=1

WebSocket

설명

TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜
HTTP 폴링과 같은 반이중 방식에 비해 더 낮은 부하를 사용하여 웹 브라우저와 웹 서버간의 통신을 가능하게 함. 
서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공
연결이 유지된 상태에서 메세지들을 오갈 수 있게 허용함. (양방향)

※ 전이중 통신 (Full Duplex)
두 지점(시작과 끝) 사이에서 정보를 주고받는 전자 통신 시스템

※ TCP (Transmission Control Protocol), 전송제어프로토콜
서버끼리 통신을 하기 위한 규약(프로토콜)
웹브라우저들이 WWW에 서버 연결할때 사용
이메일 전송 및 파일 전송시 사용

✱ 최초 연결시  
    1. 클라이언트가 서버에 웹소켓 핸드셰이크 요청을 보냄
    2. 서버는 웹소켓 핸드셰이크 응답을 보냄
    3. 이후로 클라이언트는 요청에 대한 응답을 기다리지 않고 요청을 보낼수 있음. (!= HTTP)

Websocket in Spring

관련 예제 

https://spring.io/guides/gs/messaging-stomp-websocket/ 을 참고하여 실습을 해 보았다. 
해당 링크는 STOMP(Simple Text Messaging protocol)을 사용하였다.

※ STOMP(Simple Text Messaging protocol)
텍스트 기반 메세징 프로토콜
이를 이용하여 Binary, Text가 아닌 규격을 맞춘 메세지를 보낼 수 있다. 
발행(pub), 구독(sub), 메세지브로커(=발신자가 메세지 받아와 수신자에게 전달) 등의 개념이 있다.

+ Fallback Options으로 SockJS을 사용하였다. 

테스트 화면

브라우저에서 Send 버튼 클릭 시, /app/hello 을 호출하고
메세지 브로커 핸들러 내에서 처리 후 /topic/greetings 으로 결과정보를 반환함!

참고

링크: https://ko.wikipedia.org/wiki/%EC%9D%B4%EC%A4%91%ED%86%B5%EC%8B%A0

링크: https://ko.wikipedia.org/wiki/%EC%9B%B9%EC%86%8C%EC%BC%93

링크 :https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EC%A0%9C%EC%96%B4_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

링크: https://namu.wiki/w/TCP

링크: https://tecoble.techcourse.co.kr/post/2021-09-05-web-socket-practice/

링크: https://tech.kakao.com/2020/06/22/websocket-part3/

링크: https://www.youtube.com/watch?v=rvss-_t6gzg

스프링 클라우드

설명

클라우드 어플리케이션을 구축하기 위한 프레임워크
아래와 같은 내용들을 제공해준다.

    ▶︎ 분산 / 버전 컨피규레이션
        • 분산 컨피규레이션은 클라우드 네이티브 환경에서 인기있는 표준이다. 
        • 스프링 컨피그는 분산시스템에서 외부 컨피규레이션을 위해 서버 측과 클라이언트 측을 지원한다.
            → 중앙 단일 저장소 생성됨. ... vault..
        • 주키퍼(Zookeeper) 등이있다..

    ▶︎ 서비스 등록 & 디스커버리
        • 디스커버리는 컴퓨터 네트워크상의 디바이스가 제공하는 디바이스&서비스를 자동으로 감지하는 서비스이다.
            → 각 서비스들 실행시 중앙 서버에 자신(서비스)을 등록하는것. (IP, Port 등)
            → 클라우드 환경에서 각 서버인스턴스들이 오토스케일링 되거나, 생성 확장등이 될때 IP or Port 등이 변경될 가능성이 높아지기 때문에 이러한 정보들을 캐치하기 위하여 사용함.
        • 넷플릭스 OSS(Open Source Software) 의 디스커버리 패키지 유레카(Eureka)가 있다.
        • 유레카는 클라이언트 & 서버로 구성이 되며, 클라이언트는 원격 디스커러비서버에 연결하는 일을 담당하고
서버는 독립적인 스프링부트 어플리케이션을 담당한다.


    ▶︎ 라우팅
        • 넷플릭스 OSS(Open Source Software) 의 줄(Zuul)이 있다.
        • 줄은 부하분산 및 필터링을 수행하고, 게이트웨이로써의 중요한 역할을 한다.

    ▶︎ 서비스간 호출

        • API 게이트웨이에서 각 서비스를 호출할 때, 도메인으로 호출하지 않고 IP등으로 호출하게 되면 변경된 IP에 대해서는 관련 내용을 업데이트 해줘야 함
        • 디스커버리 서비스는 인스턴스의 ID나 이름으로 호출하기에, 변경된 정보를 불러오는데 문제가 없음. 
        • API 통신할때 사용하는 RestClient 종류로 넷플릭스 OSS(Open Source Software) 의페인(Feign) 이 있다.

    ▶︎ 부하분산
        • 라운드 로빈 규칙을 가지고 디스커버리에 등록된 인스턴스 목록을 가져오는 역할을 한다. (부하분산기)
        • 넷플릭스 OSS(Open Source Software) 의 리본(Ribbon) 이 있다.

    ▶︎ 서킷브레이커
        • 네트워크 타임아웃 문제 해결 
        • 서킷 브레이커: 성공 & 실패 확률을 저장
        • 임계치가 넘으면 차단! 
        • 폴백(fallback) 로직 수행!


    ▶︎ 분산 메세징 
        • AMQP, Apache kafka 등이 있다.

클라우드 네이티브 어플리케이션

설명

클라우드 환경을 위해 잘 설계된 프로그램
https://docs.spring.io/spring-cloud-commons/docs/3.1.1/reference/html/

참고

책: http://www.yes24.com/Product/Goods/66581779
링크: https://mangchhe.github.io/springcloud/2021/04/07/ServiceDiscoveryConcept/

링크: https://www.baeldung.com/spring-cloud-bootstrapping

하나의 어플리케이션을 여러 어플리케이션으로 쪼갠것 (느슨한 연결)
    → 프로젝트 참여자가 서비스 파악에 용이 (쪼개져 있으므로!)
    → 분리된 서비스를 각 담당자들이 나눠 관리함.
    → 쪼개져있어 서비스간 배포에 영향도 X
    → 확장성, 독립성, 유연성

작고 독립적인 단위이고 중앙에서 관리가 됨.
    → 네트워크 위치, 컨피규레이션(configuration), 로깅파일, 메트릭등은 중앙에서 관리됨.

※ 메트릭
소프트웨어의 속성이나 규격을 측정할 수 있는 지표.
프로그램의 복잡성, 코드별 버그의 수, 수요자 요구 사항의 수 따위를 측정한다.

참고

책: http://www.yes24.com/Product/Goods/66581779

링크: https://badadict.com/ko/1623891​

JPQL (Java Persistence Query Language)

설명

테이블 대상으로 한 언어가 아닌, 엔티티 객체 대상으로 쿼리한 것.
SQL을 추상화하여 특정 데이터베이스 SQL에 의존하지 않음.
JPQL → SQL 으로 변환함
객체지향SQL

특징

-- 일반 SQL 문
select * from Member as m where m.username = 'coffee' -- 별칭(m)은 필수다.

-- JPQL 문
/**
@Entity(name="memeber")
class Memeber {
  ...
  private String username;
}
*/
select m from memeber as m where m.username = 'coffee'
-- → 엔티티명(member)으로 조회해야한다.
-- → 그렇지 않으면 클래스명(Member)을 기본으로 사용한다. (클래스명 추천)
-- → 대소문자를 구분한다.

select m.username from member as m 
-- → username 을 조회 한다면, 별칭(m)은 필수로 사용해야함.

결과값을 받을 때 (createQuery 사용 시)

• TypeQuery: 반환타입(메소드 리턴타입)을 명확하게 지정할 수 있는 경우 사용.
• Query: 반환타입(메소드 리턴타입)을 명확하게 지정할 수 없는 경우 사용.

결과 조회 API

• query.getResultList(): 결과가 하나 이상일때 리스트 반환
• query.getSingleResult(): 결과가 정확히 하나, 단일 객체 반환.

JPQL 조인

• 내부 조인과 외부조인

-- 내부 조인 (INNER JOIN, INNER 생략 가능)
select m from Member m inner join m.team t where t.name = :teamName


-- 외부 조인 (LEFT OUTER JOIN, OUTER 생략 가능)
select m from Member m left join m.team t


-- 세타조인 (연관관계 없는데 조인하고 싶은 경우!!)
select count(m) from Member m, Team t where m.username = t.name

• 컬렉션 조인
  → 일대다 or 다대일 관계 처럼 컬렉션을 사용하는 곳에 조인하는 것. 
  → 일대다(=다의 연관필드 사용) or 다대일(=일의 연관필드 사용)
 
• 세타 조인
  → where 절 사용하여 조인 (select count(m) from Memeber m, Team t where m.username = t.name)

• JOIN ON 절 (JPA 2.1 부터 사용 가능)
  → 외부조인에서만 사용.

• 페치 조인 (FETCH JOIN)
  → JPQL에서 성능 최적화를 위해 제공하는 기능. 연관된 엔티티나 컬렉션을 한번에 같이 조회하는 기능. join fetch 으로 사용.
  → 페치조인 사용시, SQL 한번으로 연관된 엔티티들을 함께 조회할 수 있어, SQL 조회 횟수를 줄여 성능 최적화가 가능하다.
  → 지연로딩 사용 및  fetch join 적용하는것이 효율적.
  → 페치조인은 alias 사용을 못하며, 둘 이상의 컬렉션을 페치할 수 없다. 그리고 페이징 API을 사용할 수 없다...헉 
  → 페치조인은 객체 그래프 유지할때 사용하면 효과적!
  → 특정 데이터만 표현해야 한다면 구지 페치 조인을 사용할 필요는 없다.

-- fetch join 을 사용하는 경우, m 및 m.team 모두 조회됨.
-- >> JPQL 식
select m from Member m join fetch m.team where m.name = 'AA'

-- >> SQL 식 
select
  m.*, t.*
from Member m join Team t on m.team_id = t.id
where m.name = 'AA'




-- fetch join 이 아닌 일반 join 을 하는 경우는 SQL 에서 이렇게 나옴
-- >> JPQL 식
select m from Member m join m.team

-- >> SQL 식 
select
  m.*
from Member m join Team t on m.team_id = t.id

• 묵시적 조인
  → join 키워드 직접 사용 (select ~~ from Member m join m.team t)
  → 조인이 일어나는 상황,,을 한눈에 알아보기 어렵다,,?

• 명시적 조인 (추천⭐️)
  → 경로 표현식에 의해 묵시적으로 SQL 조인 발생 (내부 조인만 가능) (select m.team from Member m)

서브쿼리

where, having 절에서만 사용 가능하며, select, from 절에서는 사용 불가능! (ㅠㅠ)
• EXISTS(결과 존재시 참) → select ~~ where exsist (select t from ~~)
• ALL(모두 만족 참) → select ~~ where o.number > ALL (select b from ~~)
• ANY(조건이 하나라도 만족시 참=SOME) → select ~~ where a.tesm = ANY(select c from ~~) 
• IN(서브쿼리 결과 중 하나라도 같은 값이 있으면 참) select ~~ where a.count in (select d from ~~)

CASE 식

• COALESCE: 하나씩 조회해서 null 이 아니면 반환
• NULLIF: 두 값이 같으면 null 반환, 다르면 첫번째 값 반환

사용자 정의 함수

select function('group_concat', name) from ~~
→ 사용 전 group_concat을 사용한다는 정의를 해야 함. (DB방언 상속 받고, 사용자 정의 함수 등록 필요)

참고

- 책: https://www.coupang.com/vp/products/20488571?itemId=80660090&vendorItemId=3314421212&src=1042503&spec=10304982&addtag=400&ctag=20488571&lptag=10304982I80660090&itime=20220302010946&pageType=PRODUCT&pageValue=20488571&wPcid=16461509863931582782572&wRef=&wTime=20220302010946&redirect=landing&gclid=CjwKCAiApfeQBhAUEiwA7K_UHxuELLbyb9IhdrRf5inlJZLtN8-t8cUswFHeV6fFp-Yd4RThtzZvHxoCPFsQAvD_BwE&campaignid=12207438463&adgroupid=115720946583&isAddedCart=