비동기 환경 탐색 - async-std와 Tokio 심층 분석

소개

Rust의 강력한 소유권 및 빌림 시스템은 성능과 안전성에 대한 집중과 함께 강력하고 효율적인 애플리케이션 개발을 위한 매력적인 선택으로 자리매김했습니다. 현대 소프트웨어의 중요한 측면은 동시성이며, Rust의 경우 비동기 프로그래밍은 고성능, 논블로킹 I/O 작업을 작성하기 위한 사실상의 표준이 되었습니다.

Rust 1.39에 도입된 async/await 키워드에 의해 크게 주도된 이 패러다임 전환은 확장 가능한 네트워크 서비스, 웹 애플리케이션 및 기타 I/O 바운드 시스템을 구축하는 데 새로운 가능성을 열었습니다.

그러나 async/await 구문 자체만으로는 완전한 솔루션을 제공하지 않습니다. 이러한 Future를 실행하려면 "비동기 런타임"이 필요합니다.

Rust 생태계에서는 Tokio와 async-std라는 두 가지 저명한 비동기 런타임이 선두 주자로 부상했습니다. 둘 다 개발자가 효율적인 비동기 코드를 작성할 수 있도록 지원하지만, 문제에 약간 다른 각도로 접근하여 프로젝트의 특정 요구 사항에 따라 고유한 장점과 단점을 제공합니다.

이러한 차이점을 이해하는 것은 비동기 Rust 여정을 시작하는 모든 Rust 개발자에게 매우 중요합니다. 런타임 선택은 개발 경험, 성능 특성 및 특수 라이브러리 가용성에 상당한 영향을 미칠 수 있기 때문입니다. 이 글은 이 두 거인을 명확히 하고 포괄적인 비교를 제공하여 선택 과정을 안내하는 것을 목표로 합니다.

Rust 비동기 런타임 해부

async-std와 Tokio의 구체적인 내용을 살펴보기 전에 Rust 비동기 프로그래밍의 몇 가지 핵심 개념을 파악하는 것이 중요합니다.

Future: Rust에서 Future는 값을 생성할 수 있는 비동기 계산을 나타내는 트레이트입니다. JavaScript의 Promise 또는 C#의 Task와 유사합니다. Future는 "게으릅니다"; 실행자(executor)에 의해 폴링될 때까지 아무것도 하지 않습니다.

Executor: Executor는 Future를 폴링하고 상태를 진행하는 역할을 합니다. Future가 I/O 이벤트(예: 네트워크 소켓에 데이터 도착)를 기다려야 할 때 Poll::Pending을 executor에 반환합니다. 그러면 executor는 이벤트가 준비되었을 때 알림을 받도록 자신을 등록하고 Future를 다시 폴링할 수 있습니다.

이 논블로킹 특성은 단일 스레드가 여러 동시 작업을 처리할 수 있도록 하는 요소입니다.

Reactor (Event Loop): Reactor는 비동기 런타임의 핵심 구성 요소로 I/O 이벤트를 모니터링합니다. 종종 지속적으로 새로운 이벤트를 기다리는 이벤트 루프(예: 데이터 사용 가능, 연결 종료)로 구현됩니다.

운영 체제의 I/O 시설(Linux의 epoll, macOS/BSD의 kqueue 또는 Windows의 IOCP와 같은)에서요.

이벤트가 발생하면 reactor는 적절한 Future 또는 작업에 실행을 재개하도록 알립니다.

이제 async-std와 Tokio를 탐색해 봅시다.

Tokio: 성능 지향적인 강력함

Tokio는 특히 고성능 네트워크 서비스에서 비동기 Rust 개발의 사실상의 표준으로 간주됩니다. 멀티스레드 스케줄러, I/O 드라이버 및 다양한 프로토콜 및 유틸리티를 위한 방대한 관련 크레이트 생태계를 포함하여 비동기 애플리케이션을 위한 포괄적인 빌딩 블록 세트를 제공합니다.

주요 원칙 및 기능:

• 멀티스레드 스케줄러: Tokio의 기본 스케줄러는 멀티 코어 시스템에서 높은 처리량을 위해 설계되었습니다.
• .. 작업 훔치기(work-stealing) 알고리즘을 사용하며, 유휴 상태의 작업자 스레드는 바쁜 스레드에서 작업을 "훔칠" 수 있어 CPU 활용도를 극대화합니다.
• 계층적 설계: Tokio는 모듈식, 계층적 아키텍처로 구축되었습니다.
• .. 핵심 tokio 크레이트는 런타임을 제공하고, tokio-util, hyper, tonic 등과 같은 별도의 크레이트는 더 높은 수준의 추상화 및 프로토콜 구현을 제공합니다.
• 성능 집중: Tokio는 원시 성능을 우선시합니다.
• .. 내부적으로 일반적인 네트워크 프로그래밍 패턴에 대해 고도로 최적화되어 최소한의 지연 시간과 최대 처리량을 요구하는 애플리케이션에 탁월한 선택이 됩니다.
• 풍부한 생태계: 인기 덕분에 Tokio는 방대한 생태계를 자랑합니다.
• .. Rust 커뮤니티의 많은 라이브러리, 특히 네트워킹, 데이터베이스 및 웹 프레임워크와 관련된 라이브러리는 Tokio를 기반으로 구축되거나 잘 통합됩니다.

Tokio를 사용한 간단한 TCP 에코 서버 예시

use tokio::net::TcpListener;
use tokio::io::{AsyncReadExt, AsyncWriteExt};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let listener = TcpListener::bind("127.0.0.1:8080").await?;
    println!("Tokio Echo Server listening on 127.0.0.1:8080");

    loop {
        let (mut socket, peer_addr) = listener.accept().await?;
        println!("Accepted connection from: {}", peer_addr);

        tokio::spawn(async move {
            let mut buf = vec![0; 1024];
            loop {
                match socket.read(&mut buf).await {
                    Ok(0) => break, // Connection closed
                    Ok(n) => {
                        // Echo the data back
                        if socket.write_all(&buf[..n]).await.is_err() {
                            break;
                        }
                    }
                    Err(_) => break, // Error
                }
            }
            println!("Connection from {} closed.", peer_addr);
        });
    }
}

이 예시에서 @tokio::main은 Tokio 런타임을 설정하고 컨텍스트에서 main 함수를 실행하는 매크로입니다.

tokio::spawn은 동시적으로 실행되는 새로운 비동기 작업을 생성합니다.

tokio::io의 AsyncReadExt 및 AsyncWriteExt를 사용하는 것을 확인하세요. 이는 논블로킹 I/O 작업을 제공합니다.

async-std: 단순성 우선 접근 방식

async-std는 "비동기 프로그래밍을 위한 표준 라이브러리"를 제공하는 것을 목표로 합니다.

.

그 설계 철학은 친숙한 std 라이브러리 API를 모방하는 데 중점을 두어 비동기 코드로의 전환을 더욱 자연스럽고 덜 위협적으로 느끼게 합니다.

주요 원칙 및 기능:

• 표준 라이브러리 API 패리티: async-std는 가능한 경우 I/O 및 동시성을 위한 표준 라이브러리의 API를 미러링하기 위해 노력합니다.
• .. 예를 들어, async_std::fs::File은 std::fs::File과 유사한 메서드를 가지고 있지만 비동기입니다.
• 단일 스레드 또는 멀티스레드: 멀티스레드 실행자를 제공하지만, async-std의 설계는 단순한 단일 스레드 모델 또는 작은 스레드 풀의 이점을 얻을 수 있는 애플리케이션에서 종종 빛을 발합니다.
• .. 일반적으로 동시성 모델을 추론하기가 더 쉽습니다.
• 사용 용이성 및 단순성: async-std는 사용 편의성과 낮은 학습 곡선을 우선시합니다.
• .. API는 표준 라이브러리에 익숙한 사람들에게 매우 관용적인 Rust처럼 느껴집니다.
• surf 웹 프레임워크: async-std는 async-std를 위해 설계된 인기 있는 웹 프레임워크인 surf와 긴밀하게 통합되어 웹 개발 경험을 간소화합니다.
• async-graphql 및 tide의 기반: async-graphql 및 tide 웹 프레임워크와 같은 프로젝트는 async-std를 기반으로 구축되어 해당 도메인에 대한 강력한 도구를 제공합니다.

async-std를 사용한 간단한 TCP 에코 서버 예시

use async_std::net::TcpListener;
use async_std::io::{ReadExt, WriteExt};
use async_std::task; // Corrected import for task::spawn

#[async_std::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let listener = TcpListener::bind("127.0.0.1:8080").await?;
    println!("async-std Echo Server listening on 127.0.0.1:8080");

    loop {
        let (mut stream, peer_addr) = listener.accept().await?;
        println!("Accepted connection from: {}", peer_addr);

        task::spawn(async move { // Use task::spawn
            let mut buf = vec![0; 1024];
            loop {
                match stream.read(&mut buf).await {
                    Ok(0) => break, // Connection closed
                    Ok(n) => {
                        // Echo the data back
                        if stream.write_all(&buf[..n]).await.is_err() {
                            break;
                        }
                    }
                    Err(_) => break, // Error
                }
            }
            println!("Connection from {} closed.", peer_addr);
        });
    }
}

여기서 @async_std::main은 async-std 런타임을 초기화합니다.

task::spawn은 동시 작업을 생성하는 데 사용됩니다.

async_std::net::TcpListener 및 async_std::io::{ReadExt, WriteExt}가 구조 및 명명에서 해당 std 카운터파트를 직접 미러링하는 방식을 확인하세요.

비교 및 선택 고려 사항

Tokio를 선택해야 하는 경우:

• 높은 성능 요구 사항: 애플리케이션이 절대적으로 최고의 처리량과 가장 낮은 지연 시간을 요구하는 경우, 특히 네트워크 집약적인 워크로드의 경우 Tokio의 최적화된 스케줄러 및 I/O 스택이 가장 적합할 것입니다.
• 대규모 복잡한 애플리케이션: 엔터프라이즈급 서비스, 마이크로서비스 아키텍처 또는 고급 동시성 프리미티브가 필요한 시스템의 경우 Tokio의 포괄적인 도구 모음과 철저히 테스트된 특성은 견고한 기반을 제공합니다.
• 풍부한 생태계 활용: 프로젝트가 타사 라이브러리(예: gRPC 클라이언트/서버, 고급 HTTP 클라이언트, 데이터베이스 드라이버)에 크게 의존하는 경우 Tokio 생태계 내에서 더 광범위하고 성숙한 지원을 찾을 수 있습니다.

async-std를 선택해야 하는 경우:

• 단순성 및 사용 편의성: 비동기 Rust에 새로 입문하거나 원시 성능보다 개발 속도와 코드 명확성을 우선시하는 프로젝트의 경우, async-std는 더 쉽게 접근할 수 있는 API를 제공합니다.
• std 라이브러리 친숙성: 동기식 Rust 표준 라이브러리를 밀접하게 미러링하는 비동기 프로그래밍 모델을 선호하는 경우, async-std는 매우 자연스럽게 느껴질 것입니다.
• surf/tide를 사용한 웹 서비스: surf 또는 tide를 사용하여 웹 애플리케이션을 구축할 계획이라면, async-std가 기본이며 가장 통합된 선택입니다.
• 소규모 애플리케이션 또는 특정 도메인: 최대 성능이 절대적인 최우선 순위는 아니지만 비동기 I/O가 바람직한 소규모 유틸리티, 스크립트 또는 애플리케이션의 경우 async-std가 훌륭한 선택이 될 수 있습니다.

Rust 비동기 생태계는 futures::io::AsyncRead 및 futures::io::AsyncWrite와 같은 트레이트 덕분에 런타임에 구애받지 않는 라이브러리에 대한 초점을 점점 더 맞춰가고 있다는 점도 주목할 가치가 있습니다.

이를 통해 일부 라이브러리는 두 런타임 모두에서 작동할 수 있어 엄격한 결합을 줄일 수 있습니다.

그러나 핵심 I/O 추상화 및 실행자의 경우 여전히 선택이 필요합니다.

결론

async-std와 Tokio 모두 Rust를 위한 매우 강력하고 성숙한 비동기 런타임이며, 각각 고유한 설계 원칙으로 틈새 시장을 개척하고 있습니다.

Tokio는 고성능, 기능이 풍부한 작업마로, 까다롭고 복잡한 네트워킹 시스템에 이상적이며, async-std는 std와 유사한 사용 편의성 경험을 제공하여 단순성과 사용 편의성에서 탁월하며 다양한 애플리케이션에 적용됩니다.

최상의 선택은 궁극적으로 프로젝트의 특정 요구 사항, 팀의 각 런타임에 대한 친숙도 및 발생할 수 있는 특정 생태계 요구 사항에 달려 있습니다.