지식 줍줍 🐿️

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

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

부하 분산 룰(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

스프링 클라우드

설명

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

    ▶︎ 분산 / 버전 컨피규레이션
        • 분산 컨피규레이션은 클라우드 네이티브 환경에서 인기있는 표준이다. 
        • 스프링 컨피그는 분산시스템에서 외부 컨피규레이션을 위해 서버 측과 클라이언트 측을 지원한다.
            → 중앙 단일 저장소 생성됨. ... 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​