티스토리 뷰

블로그읽기

gRPC, Protocol Buffers, Cache

Нуеоп 2020. 5. 11. 16:27

Understanding gRPC

https://medium.com/better-programming/understanding-grpc-60737b23e79e

 

Understanding gRPC

And the differences between REST vs. RPC architectures

medium.com

MSA에서는 서비스간 통신이 많아진다.

기존엔 HTTP 기반의 REST protocol을 많이 사용했으나, 다시 RPC가 인기를 끌고 있다.

gRPC는 구글에서 만든 가장 최신 RPC protocol 중 하나이다.

 

REST는 보통 JSON을 사용하는데, JSON은 text-based format이다보니 protocol buffer를 사용하는 gRPC에 비해 데이터 압축 효율성에서 더 무겁다.

 

그리고 REST는 HTTP 1.1기반 request-response model인데 반해, gRPC는 HTTP 2 기반이다. (REST도 HTTP 2에서 구현할 수 있긴하다.)

 

HTTP 2를 이용하여 bidirectional communication도 되고, multiplexing도 된다.

 

gRPC는 큰 규모의 마이크로서비스 통신에 다양한 프로그래밍 언어를 사용할 수 있고, 그리고 프로그래밍 언어 API 사용성을 유지할 수 있다. 

 

 

 

Understanding Protocol Buffers

https://medium.com/better-programming/understanding-protocol-buffers-43c5bced0d47

 

Understanding Protocol Buffers

A deep dive into Protobufs

medium.com

 

 

 

 

Everything you need to know about Caching — System Design

https://levelup.gitconnected.com/everything-you-need-to-know-about-caching-system-design-932a6bdf3334

 

Everything you need to know about Caching — System Design

Introduction, Use cases, Strategies & Policies to cache data

levelup.gitconnected.com

캐싱의 주요 컨셉은 다음과 같다.

 

모든 데이터를 캐시에 저장할 순 없다.

일부 데이터는 캐시에서 쫒아내야한다.

 

보통은 최신 데이터는 접근이 잦고, 시간이 지나면 관심도는 떨어진다.

 

따라서 시간에 따른 Eviction Policy가 필요하다.

 

LRU (Least Recently Used)

LFU (Least Frequently Used)

MRU (Most Recently Used)

 

 

캐시의 종류

 

Write Through Cache

 

데이터를 캐시에 먼저 저장하고 곧바로 메인 데이터베이스에 저장한다.

 

메인 데이터베이스의 데이터와 캐시의 데이터의 일치를 보장한다.

캐시에서 데이터를 읽을 땐 가장 최근에 저장한 데이터를 읽기 때문에 최신성이 유지된다.

 

하지만 write latency가 늘어나므로 write-heavy system엔 어울리지 않는다.

한번 저장하면 여러번 읽는 서비스에 적합하다.

 

write latency는 있지만, lower read latency와 consistency는 상대적으로 장점이 된다.

 

 

Write Back Cache

 

캐시에 쓰고, 데이터가 수정되었음을 표시만 한다. (데이터베이스 업데이트는 나중에 한다.)

비동기적으로 캐시와 데이터베이스를 싱크맞춘다.

이 작업은 read와 write latency에 영향을 주지 않는다.

 

단점은 데이터베이스가 the source of truth이어야 하는데, 데이터베이스로부터 읽은 데이터는 최신성을 보장받지 못한다.

 

유튜브 같은 서비스에서 view count는 Write Back Cache를 쓴다.

영상을 볼 때 마다 view count를 매번 데이터베이스에서 업데이트 하는 것은 비효율적이다.

 

Write Around Cache

 

일부 백엔드 서비스의 경우 최근 데이터를 읽는 빈도가 적은 경우가 있다.

이 경우 Write Around Cache가 적합하다.

 

write는 데이터베이스에 직접한다. 그리고 캐시엔 쓰지 않는다.

read는 캐시에서 하고, 캐시 미스인 경우 데이터베이스에서 캐시한다.

 

 

다음은 인메모리 캐시 제품이다.

 

Redis

Memcached

VoltDB

Aerospike DBS

Apache Ignite

 

 

https://www.geeksforgeeks.org/write-through-and-write-back-in-cache/

https://shahriar.svbtle.com/Understanding-writethrough-writearound-and-writeback-caching-with-python

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함