수학과의 개발자 도전기

gRPC란?

구글에서 개발한 어느 환경에서도 실행할 수 있는 최신 오픈 소스 고성능 RPC 프레임워크 

RPC(Remote Procedure Call)

프로세스 간 통신 기술. 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 해준다.

MSA 구조의 서비스에서 모듈 간의 언어에 구애받지 않고 원격에 있는 프로시저를 호출해 고유 프로그램의 개발에 집중할 수 있게 해주는 기술이다. (MSA의 각 모듈 간 통신을 원활하게 해주는 기술)

gRPC를 이용하면 원격에 있는 애플리케이션의 메서드를 로컬 메서드인 것처럼 직접 호출할 수 있기에 애플리케이션과 서비스를 보다 쉽게 만들 수 있다. 

gRPC 서버(Proto Response), gRPC 클라이언트(Proto Request 전송 부분)

Stub

서버와 클라이언트는 서로 다른 주소 공간을 사용하므로 함수 호출에 사용된 매개변수를 꼭 변환해줘야 한다. 그렇지 않으면 메모리 매개 변수에 대한 포인터가 다른 데이터를 가리키게 된다.

클라이언트 stub : 함수 파라미터 변환 -> 함수 실행 -> 서버 response 변환 담당

서버 stub : 클라이언트가 전달한 매개변수 역변환, 함수 실행 결과 변환 담당

Protocol Buffer

gRPC에서는 IDL(Interface Definition Language)로 protocol buffer를 사용한다. 

protocol buffer : 직렬화 데이터 구조. Json, XML

proto file : 직렬화하려는 데이터 구조 정의. 특정 언어에 대한 종속성이 없는 데이터 타입. 프로토 버퍼는 여러 프로그래밍 언어를 지원하기 때문.

프로토콜 버퍼 데이터는 ‘이름-값’의 쌍을 포함하는 작은 논리적 레코드인 메시지로 구성됨

proto file -> protoc 컴파일로 컴파일 -> 언어에 맞는 데이터 클래스 생성

만들어진 클래스는 각 필드를 위한 접근자 뿐 아니라 

전체 구조 -> 바이트 (직렬화)

바이트 -> 전체 구조 (파싱) 

메서드 제공

gRPC 특징

높은 생산성과 다양한 언어 및 플랫폼 지원

Protocol Buffer의 IDL만 정의하면 서비스와 메시지에 대한 소스코드가 자동으로 생성되고 데이터를 주고 받을 수 있따.

HTTP/2 기반 양방향 스트리밍

성능 이점

gRPC는 HTTP/2 레이어 위에서 Protocol Buffers를 이용해 직렬화된 바이트 스트림으로 통신해 JSON 기반 통신보다 더 가볍고 통신 속도가 빠르고, latency 감소, 더 많은 트래픽 처리 가능

-> 속도 빠르고, 더 많은 트래픽 처리 가능하며, 편리하다

서킷 브레이커란?

서킷 브레이커가 뭔가 하니 두꺼비 집에서 과부하, 단로, 누전으로부터 전기 회로를 보호하는 안전장치다.

서킷 브레이킹은 분산 시스템에서 서비스 간의 의존성과 가용성을 보장하기 위한 패턴 중 하나.

서킷 브레이킹 동작 방식

1. 장애 서비스 일시적으로 엔드포인트에서 제거

서비스 장애 상황 시 호출이 지연/실패할 경우, 서킷 브레이커는 장애 서비스를 일정 기간 동안 엔드포인트에서 제거하고 서비스의 상태가 정상으로 회복되기를 기다린다(모니터링). 

2. 장애 서비스로의 지연/장애 현상 전파 방지

장애 서비스에 대한 호출은 다른 서비스로 라우팅 되게 함으로써, 서비스 간의 지연 또는 장애 현상이 전파되는 것을 방지할 수 있게 해준다. 장애가 전체 시스템에 영향 최소화

서비스 메시

애플리케이션 서비스 간 모든 통신을 처리하는 소프트웨어 계층

애플리케이션이 확장되고, 마이크로서비스의 수가 증가함에 따른 성능 모니터링 문제 해결

서비스 간 연결을 관리하기 위해 모니터링, 로깅, 추적, 트래픽 제어와 같은 기능 제공

인프라 개발자, 서비스 개발자 -> 주로 인프라 개발자에게 서비스 메시는 이점을 준다

플랫폼 레이어(인프라 쪽)에 구성되는 네트워크 제어 방법

애플리케이션 트래픽을 관리, 추적 및 보안성을 강화하기 위해 사용

마이크로서비스 간 통신 문제 해결

대표 기능 -> 애플리케이션 트래픽 관리, 관찰 가능성, 보안

데이터 플레인, 컨트롤 플레인 두 개의 컴포넌트로 구성됨

데이터 플레인 : 애플리케이션 사이에 있는 프록시(envoy 서비스로 구성, 서비스와의 프록시 호출 담당) 네트워크로 구성됨, 서비스 메시의 모든 서비스에 대한 모든 인바운드 및 아웃바운드 트래픽 관장.

컨트롤 플레인 : 프록시에게 수행할 작업을 알려주고 메시를 작동하는 사람을 위한 인터페이스 제공, 서비스 검색(discovery), TLS 인증서 발급, 메트릭 집계 등 데이터 플레인이 작동하는데 필요한 컴포넌트 제공

컨트롤 플레인 <-> 프록시 <-> 애플리케이션

서비스 메시 툴

Istio

문제점

• 프록시 자원은 인프라와 관련해 리소스를 소비하며 네트워크 지연을 발생시킴. 
• 프록시 사용 서비스 개수 증가 -> 메모리, CPU 소비량 증가, 커넥션 풀 수 증가(point of failure도 증가)
• 코드 수정 가능성(http 설정, 라이브러리 변경)
• 트러블 슈팅이 어렵다

대안

서킷 브레이커(Spring Cloud for Kubernetes), Observability의 대안(Jaeger, Zipkin 같은 분산 트레이싱 도구) 

Reference

https://aws.amazon.com/ko/what-is/service-mesh/

https://www.samsungsds.com/kr/insights/service_mesh.html

스로틀링(throtling)

스로틀링이란?

스로틀링은 전자 기기의 CPU, GPU 등이 지나치게 과열될 때 기기의 손상을 막고자 전압을 조절하는 것을 의미한다. 즉, 최악의 상황을 막기 위해 요청 개수나 속도를 조절하는 것을 의미한다. 

서버가 처리할 수 있는 요청보다 월등히 많은 요청을 받게되면 서버가 터질 수도 있기 때문에 서버로 가는 요청 수를 조절해 이를 방지하는 방법이다. 

너무 많은 요청으로 인해 API가 가득 차는 것을 방지하기 위함 -> API Gateway 레이어에서 API 요청 조절

서버 순간 처리 요청 수를 제한하고 바로 429 Too Many Requests 응답을 주면 클라이언트도 빠르게 파악 및 대응이 가능하고, 서버도 요청 수를 조절 할 수 있다. -> 요청 스레드가 밀려서 전체 사용자 응답 느려지는 것 방지 가능

API Gateway

MSA 패턴 중 하나로, API를 사용하는 클라이언트와 서버 사이에 위치해 다양한 목적으로 사용됨

• 인증 및 권한 부여
• 서비스 검색 통합
• 속도 제한
• 로깅을 반영 및 추적

대기열

서버가 처리 가능한 것을 넘은 요청이 올 때, 해결방법은 두 가지이다.

서버 자체의 크기 늘리기 or 서버의 처리량을 줄이는 것(대기열)

대량 접속이 동시다발적으로 요청될 경우 서버 및 시스템에 부하가 유발되어 사이트 단절 발생 가능.

대기열 시스템은 순차적 접속을 통해 부하가 유발되지 않도록 해 대규모 트래픽에도 흔들림 없이 사이트 운영을 도와주는 시스템이다.

활용 사례 

지마켓, 옥션은 Redis를 이용해 RedCarpet이라는 대기열 아키텍처를 도입 -> 어렵다,,,

Reference

스로틀링

https://12bme.tistory.com/504

https://rene-or-irene.tistory.com/22

대기열

https://dev.gmarket.com/46

프로젝트를 진행하면서 CPU가 새벽에 꺼지는 문제가 발생했었다. 프로젝트 진행 중에 원인이 무엇인지 알아보기는 했지만 단지 CPU 성능이 좋지 않아 트래픽을 견뎌내지 못한 것이라고 판단했지만, 찾아보니 성능을 향상하기 위한 기능이 많아서 관련 기술 찾아본 내용을 정리했다. 

찾아보니 위 기술들은 MSA 환경에서 대량 트래픽의 유량 제어를 위해 사용할 수 있는 옵션들이었다. 

스케줄러 분산

분산된 환경에서 스케쥴러를 관리하는 방법이 꽤 복잡하고 어려운 것 같다. 

상황

Scalling 중이고, Scheduler가 있는 서버인 경우 Multiple Scheduler Instances가 발생한다. 이때 고민할 수 있는 2가지는 다음과 같다.

1. Quartz와 같은 분산 스케줄링 프레임워크 사용해서 여러 인스턴스에서의 스케줄러 실행 조정하기
   1. 한 번에 하나의 스케쥴러 인스턴스만 실행하게 함 
2. SchedLock으로 한 번에 하나의 스케줄러 인스턴스만 실행되게 할 수 있음
   
   1. SpringBoot에서 Scheduler에 Lock을 거는 방법
   2. 한 번에 하나의 스케줄러 인스턴스만 실행하게 하기
   3. 스케줄러 인스턴스 실행 시 공유 자원에 잠금을 획득해 작업을 진행한다. 락이 없는 인스턴스는 대기한다

ShedLock

예약된 작업에 대한 분산 잠금을 제공하는 Spring Boot 라이브러다. 

잠금 데이터베이스 테이블과의 조합을 사용해 분산 환경에서 실행되는 애플리케이션의 여러 인스턴스에서 예약된 작업이 한 번만 실행되도록 한다.

• 예약된 작업 ShedLock에 등록
• 가용 테이블 확인 : ShedLock이 Lock DB 테이블 사용할 수 있는지 확인
  • Lock DB 테이블 사용할 수 없는 경우 경고 기록하고 작업 건너뜀
  • 사용할 수 있으면 예약된 작업의 cron 표현식을 기반으로 시간 계산

• 잠금 획득 시도 : 시간상 실행할 수 있는 예약된 작업인 경우, 테이블에 레코드를 삽입해 예약된 작업에 대한 잠금 획득 시도
  • 삽입 성공 : SchedLock이 잠금 획득 성공
  • 삽입 실패 : ShedLock 잠금 획득 실패, 경고 기록하고 작업 건너뜀

• 작업 완료: ShedLock은 Lock DB 테이블에서 잠금 레코드 삭제하고 잠금을 해제한다

잠금이 해제되기 전에 잠금을 보유한 응용 프로그램 인스턴스가 다운되면 ShedLock은 지정한 시간 초과 기간 후에 잠금을 해재해 다른 인스턴스가 차단되지 않도록 한다. 

Reference

https://developer-been.tistory.com/34