오늘의 토픽
간단한 제 소개
사이드 프로젝트에서 MSA를 꿈꾸다
기존 서비스 구조
사이드 프로젝트에서 MSA를 꿈꾸다
여러가지 예상되는 문제점
1. 스케줄러가 해야하는 역할이 많은데, 스케줄러에 문제가 생기면?
사이드 프로젝트에서 MSA를 꿈꾸다
여러가지 예상되는 문제점
2. 스케줄러가 Concurrent 하게 돌아갔으면 좋겠고,
동시에 안정적이였으면 좋겠다...
사이드 프로젝트에서 MSA를 꿈꾸다
우리가 내린 결론
"MSA 아키텍쳐를 도입하자."
사이드 프로젝트에서 MSA를 꿈꾸다
하지만, 우리가 생각한 목표를 달성하려면?
안정성+속도 라는 두마리 토끼
사이드 프로젝트에서 MSA를 꿈꾸다
답은...
gRPC가 우리에게 필요한 이유
1. 빠르다!
출처 : Scaling up REST versus gRPC Benchmark Tests
gRPC가 우리에게 필요한 이유
2. Type-safe 하다!
syntax = "proto3";
package calculator;
service Calculator {
rpc Add (AddRequest) returns (AddResponse);
}
message AddRequest {
int32 num1 = 1;
int32 num2 = 2;
}
message AddResponse {
int32 result = 1;
}
gRPC의 단점
1. REST에 비해 너무 복잡해요...
gRPC의 단점
2. 개발자 경험 (Developer Experience) 가 좋지 않아요...
protoc --go_out=. --go_opt=paths=source_relative \
--go-grpc_out=. --go-grpc_opt=paths=source_relative \
helloworld.proto
gRPC의 단점
2. 개발자 경험 (Developer Experience) 가 좋지 않아요...
gRPC의 단점
물론, 여러가지 솔루션들이 존재했지만.. 성에 차지 않았다
gRPC의 단점
그러던 어느날... 한줄기의 빛을 보게 되었습니다
Go 개발자지만 Rust가 좋아 👀
Rust와 Tonic이 어-썸 한점
mod pb {
tonic::include_proto!("helloworld");
}
Go 개발자지만 Rust가 좋아 👀
Rust와 Tonic이 어-썸 한점
Go 개발자지만 Rust가 좋아 👀
Rust와 Tonic이 어-썸 한점
딱 봐도 하기 싫게 생김...
Go 개발자지만 Rust가 좋아 👀
Rust와 Tonic이 어-썸 한점
단 두줄이면 끝
Server::builder()
.accept_http1(true)
.add_service(tonic_web::enabled(CalculatorServer::new(calc)))
우리가 gRPC를 도입하고서 배운 것들 🧐
gRPC 이거이거... 너무 쉬워진거 아니냐구 wwwww
우리가 gRPC를 도입하고서 배운 것들 🧐
MSA 개발에서 어려운 부분을 한결 덜어낸 느낌
우리가 gRPC를 도입하고서 배운 것들 🧐
MSA 아키텍쳐를 실사례에 적용해볼 수 있었던 흔치 않았던 사례
그리고 개발의 편리함까지
20분이라는 짧은 시간이라서 많은 설명을 생략했지만... 🥲
QnA