[Rust] Tokio 1.0 발표 (번역)

https://tokio.rs/blog/2020-12-tokio-1-0

Tokio의 1.0 릴리즈를 발표할 수 있게 되어서 참으로 기쁨이 한량없습니다. Tokio는 Rust 언어의 비동기 런타임입니다.

Tokio는 믿음직한 네트워킹 애플리케이션을 성능 저하 없이 작성할 수 있게 해주는 요소들을 제공합니다.
TCP, UDP, timer, 멀티스레드,work-stealing 스케줄러 등에 대한 비동기 API들이 있죠.

몇년간 우리 팀은 tokio의 사용자들이 놀라운 것들을 만들어내는 것을 즐겁게 보아왔습니다.

예를 들어, 디스코드는 tokio로 tail latencies를 5배 단축했습니다.

Fly.io는 Tokio를 통해 쉽게 성능 요구사항을 충족하고 기능을 제공하는 데 집중할 수 있었습니다.

Zcash Foundation은 Tokio를 기반으로 구축해 오용 방지(misuse-resistant) API를 설계 할 수 있었습니다.

AWS의 Lambda 팀은 Tokio를 사용해 더 믿음직하고 유연한 서비스를 구현했습니다.

Tokio를 시작하는 방법을 배우기 가장 좋은 곳은 튜토리얼입니다.

안정성 보장(stability guarantee)

우린 4년 전에 처음으로 tokio를 발표했습니다.
그 후로도 계속해서 크게 발전해왔고요.

Tokio에서 가장 중요한 변경점은 1년전 Rust에 async와 await가 추가된 때일 겁니다.

오늘날 tokio는 사용하기 더 쉬워졌고, 보다 강력해졌습니다.

하지만 이 진화는 약간의 마찰을 일으키기도 했죠.

이런 변경점들을 추적하기 위해 라이브러리들을 필요로 하기도 했고, 어쩌다 여러 버전의 tokio를 의존하는 경우 혼란스런 오류 메세지가 뜨기도 했습니다.

Tokio 1.0 릴리즈는 이러한 혼란들에 종지부를 찍을 겁니다.

그리고 릴리즈의 일환으로 생태계에 안정적인 기반들을 제공하기 위한 노력도 기울이고 있죠.

아직 2.0 버전에 대한 계획은 없습니다. 최소한 3년 동안은 버전 2에 대한 릴리즈는 보류할 것을 약속합니다.

그리고 최소 5년 동안은 1.0 버전대를 유지 관리할 계획입니다.

Tokio는 MSRV(최소 지원 Rust 버전:minimum supported rust version) 정책을 6달 동안은 유지할 것입니다.
MSRV를 늘릴 경우, 그 새 Rust 버전은 최소 6개월 전에 출시된 것이어야 하죠.

이 안정성은 tokio가 정체한다는 것이 아닙니다. 아직 여전히 해야할게 많거든요.

2021

내년에는 stream, io_uring, 추적 통합, Tokio 스택 등 몇 가지 영역에 집중할 예정입니다.

스트림(Stream)

현재. tokio-stream 크레이트는 Stream trait 기반의 비동기적인 반복 유틸리티들을 제공합니다.
Stream trait을 futures-core에서 Rust 표준 라이브러리로 옮기려는 RFC가 승인 대기중입니다.

표준 라이브러리가 Stream trait을 제공하면 Tokio의 Stream 유틸리티는 Tokio 크레이트 자체로 이동할 겁니다.

io_uring

io_uring은 디스크를 포함한 모든 형식의 I/O에 대한 비동기 연산을 제공하는 새 리눅스 인터페이스입니다. 필요한 syscall 수도 단축할 수 있고요.

현재 리눅스에서 Tokio는 epoll(7) 인터페이스를 사용합니다. 이건 디스크 접근에 대해서 작동하지 않는 걸로 악명이 높죠

이걸 작업하기 위해서 Tokio는 스레드풀에 동기 연산을 발송하는 것으로 비동기적 파일시스템 API를 제공합니다.
->To work around this, Tokio provides asynchronous filesystem APIs by dispatching synchronous operations to a thread pool.
이렇게 동작하는 동안은 최적의 상태가 아닙니다.

io_uring을 활용하면 Tokio는 더 멋진 비동기 파일시스템 연산을 제공할 수 있게 될 겁니다.

게다가, io_uring의 초기 벤치마크는 매우 유망합니다. 이러한 성능 향상이 Tokio에 이어지기를 희망합니다.

추적(tracing)

2021년에는 Tokio 애플리케이션 운영에 관한 first class 스토리를 정의하는 것이 초점이 될 것입니다.

이 이야기의 큰 부분은 추적과 metric에 대한 도구입니다.

tracing 크레이트는 이미 필요한 기반구조들을 많이 제공합니다.
이건 구조화된 진단을 위한 퍼사드(facade) 레이어와 데이터 모델을 구현합니다. 라이브러리와 애플리케이션 모두에게 다양한 방식으로 활용할 수 있는 기계친화적인(machine-readable) 데이터를 방출할 수 있게도 해주고요.

다가오는 해에는 tracing과 Tokio stack 간의 좀더 깊은 통합을 구축할 겁니다.
이 통합은 질문에 답하기 위해 Tokio의 내부에 필요한 가시성을 제공하는 데 도움이 될 거에요.

tail latencies를 줄이기 위해 Tokio 런타임을 튜닝하는 방법, 현재 실행중인 작업 또는 가장 경쟁이 심한 lock을 파악하는 방법과 같은 질문 말이죠.

또한 나머지 tracing 생태계를 지속적으로 개선하고 성장시킬 것입니다.

여기에는 core tracing 및 tracing-core 크레이트의 새 릴리스에 대한 작업, Tokio 스택의 라이브러리에 더 풍부한 도구 기능 추가, tracing-opentelemetry과 같은 다른 진단 및 관찰 도구와의 통합 제공이 포함됩니다.

The Tokio stack

Tokio는 소켓 및 타이머와 같은 표준 프리미티브에 대한 런타임과 비동기 API를 제공하지만, 네트워킹 애플리케이션은 종종 HTTP 및 gRPC와 같은 더 높은 수준의 프로토콜을 사용합니다.

Tokio Stack은 이러한 요구를 해결하기 위해 HTTP 용 Hyper와 gRPC 용 Tonic을 포함합니다.

현재 Tokio 1.0을 지원하는 Hyper 0.14를 릴리즈했습니다. Tonic는 곧 업데이트됩니다.

Tokio 1.0이 출시되면 Tower에도 초점을 맞출 것입니다. Tower는 믿음직한 클라이언트 및 서버를 구축하기 위한 재사용 가능한 구성 요소 집합입니다.

감사의 말씀

Tokio는 수많은 컨트리뷰터들의 지원이 없었다면 불가능했습니다. 특히 Alice Ryhl의 공헌이 지대했죠.

Tokio 스택 라이브러리들의 리더들에게도 감사를 표합니다.
Sean McArthur (Hyper)
Lucio Franco (Tonic)
Eliza Weisman (Tracing)
Thomas De Zeeuw (Mio)

또한 Tokio의 성립은 Aaron Turon과 Alex Crichton의 초기 참여 없이는 불가능했습니다.

마지막으로 Tokio에 재정적인 지원을 아끼지 않은 기업들에게도 큰 감사를 표합니다.
Mozilla
Dropbox
Buoyant
AWS

—Carl Lerche