yyu-nim/yyu-nim.github.io

Production-ready Rust Libraries (PRL)

Production-ready Rust Libraries (PRL)

Production Service에 사용할 만한 RUST 라이브러리의 사용법 소개

(Blog) https://yyu-nim.github.io/

yyu-nim.github.io's Issues

https://yyu-nim.github.io/rust/nvmf/chatgpt/2023/03/18/nvmf-1-intro.html

nvmf <1> - introduction (feat. ChatGPT) | Production-ready Rust Libraries (PRL)

ChatGPT를 사용하면 블로그를 편하게 찍어낼 수 있다는 이야기를 들어, 아침에 일어나 “폰”으로 ChatGPT 에게 물어보았다, 아니 여쭤보았다:

https://yyu-nim.github.io/rust/nvmf/chatgpt/2023/03/18/nvmf-1-intro.html

https://yyu-nim.github.io/rust/lldb/debugging/2022/12/04/lldb-programmatic-debugging.html

lldb <1> - programmatic debugging | Production-ready Rust Libraries (PRL)

오랜시간 동안 사랑받아 온 디버깅 방법이 있다. 그것은 바로, 디버그 코드를 삽입하여 println을 통해 콘솔이나 파일로 프로세스의 상태를 출력하는 것이다.

https://yyu-nim.github.io/rust/lldb/debugging/2022/12/04/lldb-programmatic-debugging.html

https://yyu-nim.github.io/actix/rust/crossbeam/shardedlock/2022/08/15/crossbeam-shardedlock.html

crossbeam <4> - sharded lock | Production-ready Rust Libraries (PRL)

State machine을 구현하다 보면, 이런 경우에 고민이 될 수 있다: “State A 에서 State B로 전환을 해야 하는데, State A에서 외부 Event가 들어오지 않도록 잠깐 막고 싶다”.

https://yyu-nim.github.io/actix/rust/crossbeam/shardedlock/2022/08/15/crossbeam-shardedlock.html

https://yyu-nim.github.io/rust/nvmf/chatgpt/read/write/command/2023/03/21/nvmf-3-readwrite.html

nvmf <3> - read/write command | Production-ready Rust Libraries (PRL)

이번에는 실제 사용자 데이터의 read/write를 어떻게 처리하면 좋을지가 궁금해서, ChatGPT에게 여쭤보았다:

https://yyu-nim.github.io/rust/nvmf/chatgpt/read/write/command/2023/03/21/nvmf-3-readwrite.html

https://yyu-nim.github.io/rust/crossbeam/concurrent/queue/2022/08/21/crossbeam-queue.html

crossbeam <7> - non-blocking concurrent queues | Production-ready Rust Libraries (PRL)

코드 리뷰 중에, 누군가가 만약 queue에 아이템을 넣고 빼는 연산의 전후에 lock을 잡고 획득하고 풀어주는 패턴으로 작성한 것을 보았다면, 보통은 아래와 같은 코멘트를 달게 될 것이다: 본 PR에서 사용된 queue가 thread-safe 하지 않기 때문에, lock을 사용하신 것으로 이해하면 될까요? Lock이 coarse-gr

https://yyu-nim.github.io/rust/crossbeam/concurrent/queue/2022/08/21/crossbeam-queue.html

https://yyu-nim.github.io/rust/diesel/facebook/tectonic/metadata/name/2022/10/09/diesel-mini-tectonic-2.html

diesel <2> - mini tectonic in rust - name layer | Production-ready Rust Libraries (PRL)

지난 포스트의 메타데이터 스키마를 다시 한번 살펴 보고, schema migration을 해보도록 하자.

https://yyu-nim.github.io/rust/diesel/facebook/tectonic/metadata/name/2022/10/09/diesel-mini-tectonic-2.html

https://yyu-nim.github.io/crossbeam/rust/2022/07/21/crossbeam-workstealing-2.html

Crossbeam work-stealing queue <2> | Your awesome title

100만개의 일을 만들어서, 10개의 worker들에게 나눠주기. 방식은 work-stealing으로 worker들이 일을 빼앗아 감. ```rust use std::thread; use std::time::Duration; use crossbeam::deque::{Steal, Worker};

https://yyu-nim.github.io/crossbeam/rust/2022/07/21/crossbeam-workstealing-2.html

https://yyu-nim.github.io/rust/diesel/facebook/tectonic/2022/10/03/diesel-mini-tectonic-1.html

diesel <1> - mini tectonic in rust | Production-ready Rust Libraries (PRL)

Facebook에서 2021년도에 FAST’21에 발표한 Tectonic 이라는 흥미로운 논문이 있다. 쉽게 말하면, 스토리지 서버들로 Exabyte 스케일의 분산 파일 시스템을 구축했다는 이야기 이다. 여기서 생길 수 있는 의문은, “File A를 읽고 싶을 때, 어떤 서버의 어떤 디스크의 어떤 블럭 주

https://yyu-nim.github.io/rust/diesel/facebook/tectonic/2022/10/03/diesel-mini-tectonic-1.html

https://yyu-nim.github.io/actix/rust/actor/service/registry/2022/07/31/actix-registry-example.html

actix <6> - looking up addr from SystemRegistry | Your awesome title

Actix의 문서에는 중요한 기능들에 대한 설명이 상당 부분 빠져 있는데, 그 중 하나가 System Registry 이다. 소스 코드 로부터 이해해보면, Actor를 SystemService라는 형태로 생성할 수 있는 방법이 있음을 알게 되는데, 이 경우 다음의 두 가지 혜택이 자동으로 따라온다:

https://yyu-nim.github.io/actix/rust/actor/service/registry/2022/07/31/actix-registry-example.html

https://yyu-nim.github.io/rust/crossbeam/chatgpt/parker/tcp/2023/03/25/crossbeam-parker-tcp-chatgpt.html

crossbeam <8> - parker/unparker (feat. ChatGPT) | Production-ready Rust Libraries (PRL)

이전의 crossbeam-parker/unparker 포스팅에서 TCP state transition을 Parker/Unparker API를 사용해서 시뮬레이션 하는 예제를 공유하였었다. 이걸 ChatGPT에게 시키면 어떻게 예제를 작성해줄 수 있을까 문득 궁금해졌다.

https://yyu-nim.github.io/rust/crossbeam/chatgpt/parker/tcp/2023/03/25/crossbeam-parker-tcp-chatgpt.html

https://yyu-nim.github.io/rust/dashmap/concurrent/hashmap/2022/08/28/dashmap-counters.html

dashmap <1> - concurrent hashmap | Production-ready Rust Libraries (PRL)

Concurrent hashmap의 사용 동기는 익히 알려진 대로, map 전체의 lock을 잡는 대신 critical section 을 최소한으로 설계하여 lock의 사용 기간과 범위를 극단적으로 줄이도록 하여, 겹치지 않는 영역에 대한 자료 구조 연산들을 최대한 동시적으로 진행될 수 있도록 하겠다는 것이다. 물론, lock의 사용을 사용자로

https://yyu-nim.github.io/rust/dashmap/concurrent/hashmap/2022/08/28/dashmap-counters.html

Load error: cannot load such file

Load error: cannot load such file – webrick

https://yyu-nim.github.io/rust/lazy_static/async_once/2022/09/25/lazy-static-async-init.html

lazy_static <3> - lazy eval. with async/await | Production-ready Rust Libraries (PRL)

lazy_static!{} 내부에 싱글턴 생성 로직을 넣다보면 궁금할 때가 있을 것이다; async/await을 쓰고 싶으면 어떻게 하지? tokio 기반의 application에 싱글턴을 도입하려 한다면 꼭 한번 묻게되는 질문일 것이다. 단순하게, 새로운 async runtime을 생성해서 (e.g., tokio::runtime::Runtime::new()), block_o

https://yyu-nim.github.io/rust/lazy_static/async_once/2022/09/25/lazy-static-async-init.html

https://yyu-nim.github.io/rust/lazy_static/event/crossbeam/2022/09/23/crossbeam-event-channel.html

lazy_static <1> - global event channel | Production-ready Rust Libraries (PRL)

Thread-safe concurrent application을 작성할 때 자주 사용되는 방법은, 두 쓰레드간 channel을 만들어 message를 통해서만 상태 변환을 하는 것이다. 메모리 주소를 다수의 쓰레드간 공유하는 방식과 비교해보면 lock의 획득 순서라던지, critical section 구간을 줄이기 위한

https://yyu-nim.github.io/rust/lazy_static/event/crossbeam/2022/09/23/crossbeam-event-channel.html

https://yyu-nim.github.io/rust/crossbeam/mpmc/channel/k8s/2022/08/18/crossbeam-mpmc-channel.html

crossbeam <6> - mpmc channel | Production-ready Rust Libraries (PRL)

crossbeam 문서 에 보면, std::sync::mpsc에는 없는 multi-producer multi-consumer channel 기능이 있다고 한다. std에 포함된 채널은 multi-producer single-consumer channel을 구현하고 있는데, thread간 message passing을 구현하기 위한 primitive로 볼 수 있고, 가장 대중적인 사용법이라 볼 수 있겠다. Message를 보낼 때에는, 내가 원하

https://yyu-nim.github.io/rust/crossbeam/mpmc/channel/k8s/2022/08/18/crossbeam-mpmc-channel.html

Installing on mac m1

https://jekyllrb.com/docs/installation/macos/

https://yyu-nim.github.io/actix/rust/recipient/actor/2022/07/31/actix-recipient-usage.html

actix <5> - recipient vs. addr | Your awesome title

Actix에서 actor에게 메시지를 보낼 때, 두 종류의 addressing을 사용할 수 있다. 한 가지는 Addr 이고, 다른 한 가지는 Recipient 이다. 둘 모두 do_send, send 를 사용하여 메시지를 보내기 때문에 유사해 보이는데, 결정적인 차이는, Addr의 generic type "T"는 actor type이 들어가고, Recipient의 generic t

https://yyu-nim.github.io/actix/rust/recipient/actor/2022/07/31/actix-recipient-usage.html

https://yyu-nim.github.io/rust/crossbeam/chatgpt/nvmf/k8s/manifest/2023/03/26/nvmf-7-k8s-manifest.html

nvmf <7> - availability | Production-ready Rust Libraries (PRL)

NVMe-oF 가 어떤 이유로든 멈췄다고 생각해보자. Rust로 짠다면 memory safety 이슈로 인한 크래시는 없을 테니 그 부분은 안심할 수 있겠지만, 의도치 않게 무한 루프를 돌면서 객체를 무한 생성해서 Linux OOM 킬러에 의해 종료가 될 수도 있을 것이고, 연동된 C 라이브러리에서의 invalid memory acces

https://yyu-nim.github.io/rust/crossbeam/chatgpt/nvmf/k8s/manifest/2023/03/26/nvmf-7-k8s-manifest.html

https://yyu-nim.github.io/actix/rust/actor/weak/address/2022/08/14/actix-weak-address.html

actix <7> - weak address | Production-ready Rust Libraries (PRL)

Actix examples 중에 weak address 에 대한 재밌는 예제가 있어 포스팅한다.

https://yyu-nim.github.io/actix/rust/actor/weak/address/2022/08/14/actix-weak-address.html

https://yyu-nim.github.io/actix/rust/crossbeam/coordination/2022/08/14/crossbeam-waitgroup.html

crossbeam <3> - WaitGroup | Production-ready Rust Libraries (PRL)

Multi-thread application을 작성하다 보면, 다음과 같은 상황을 마주할 때가 있을 것이다: 모든 쓰레드들이 동일 선상에 도착했을 경우, 특정 연산을 수행하도록 하고 싶다! 예를 들면, storage perf benchmark를 작성한다고 해보자. 사용자에게 주어진 concurrency 설정만큼 thread를 생성하고

https://yyu-nim.github.io/actix/rust/crossbeam/coordination/2022/08/14/crossbeam-waitgroup.html