`hyperium/tonic`이 `grpc/grpc-rust`로 전환되고 새로운 `grpc` 크레이트의 프리뷰 릴리스를 준비하면서, Rust의 gRPC 생태계가 공식 gRPC 프로젝트와 CNCF 안에서 다음 단계로 나아갑니다.
앞으로 일주일 안에 hyperium/tonic은 grpc/grpc-rust가 되고, 새로운 grpc 크레이트의 프리뷰 릴리스를 배포할 예정입니다. 이는 tonic 프로젝트와 Rust에서 gRPC를 사용하는 모든 사용자에게 중요한 다음 단계이며, 공식 gRPC project에 업스트림될 예정임을 의미합니다. gRPC 프로젝트는 Cloud Native Computing Foundation(CNCF)의 일부이며, The Linux Foundation의 한 부문입니다.
세부 사항에 들어가기 전에, 먼저 tonic의 역사에 대해 짧게 요약하고 싶습니다. 저는 2019년 여름에 이 프로젝트를 만들었는데, 주된 이유는 Rust로 분산 시스템을 작성하고 싶었기 때문입니다. 원래 Carl Lerche가 tower-grpc를 작성했고, 당시 Buoyant에서 사용되고 있었는데, 이것이 Rust용 진짜 gRPC 라이브러리를 쓰기 시작하기에 완벽한 초기 기반을 제공해 주었습니다. 이 모든 것은 async/await가 막 출시되기 직전의 시기와 맞물려 있었고, 그래서 저는 최초의 프로덕션 준비가 된 async/await Rust 라이브러리를 만들겠다는 목표를 세웠습니다. 프로젝트를 세상에 내놓기 위해 제 모든 여가 시간을 쏟아부어 개발했습니다. 그리고 마침내 2019년 가을에 첫 0.1 릴리스를 내놓았습니다. 그 시점 이후로는 말 그대로 역사가 되었고, 이제 이 프로젝트는 GitHub에서 12k개가 넘는 스타를 모았으며 많은 대규모 엔지니어링 조직에서 사용되고 있습니다.
프로젝트가 커뮤니티와 저 자신에게 가져다준 성장과 지원에 매우 감사하고 있지만, 유지 관리는 꽤 어려워졌습니다. 새로운 기능을 구축하려면 상당한 시간 투자가 필요하고, 새로운 변경 사항을 검토하는 일도 프로젝트에 उपलब्ध한 유지 관리 자원의 양으로는 지속 가능하지 않은 수준이 되었습니다. 여기에 더해 prost 프로젝트가 더 이상 유지 관리되지 않게 되었고, 이것이 핵심 의존성이었기 때문에 tonic 메인테이너들은 어쩔 수 없이 이를 우리 생태계 안으로 가져와야 했습니다. 이로 인해 유지 관리 부담은 크게 늘어났습니다. 세월이 흐르며 제 삶도 변했고, 프로젝트를 충분히 유지 관리하는 데 필요한 시간을 점점 잃기 시작했으며 오래 함께할 메인테이너를 찾는 데도 어려움을 겪었습니다. 이는 대형 OSS 프로젝트에서 매우 일반적인 과정이며, OSS 커뮤니티에서 흔히 볼 수 있는 주제이기도 합니다. 이 모든 결과로 프로젝트는 새로운 기능을 받아들이지 않게 되었고, 실제로는 중요도 높음/긴급 우선순위의 버그와 무엇보다도 보안 문제를 해결하는 데에만 집중하게 되었습니다.
시간을 2024년 초로 돌려보면, 저는 Google의 gRPC 팀에 있는 Doug Fawley로부터 이메일을 받았습니다. 그는 협업에 열려 있는지 물어보며 연락해 왔고, 자신이 gRPC-Rust 작업을 하게 될 예정인데 생태계를 불필요하게 분열시키고 싶지 않다고 말했습니다. 이것이 gRPC-Rust의 시작이었습니다. 그 이후로 우리는 매주 만나고 있으며, 저는 그들이 자신들의 요구와 tonic 커뮤니티의 요구를 가장 잘 반영할 수 있는 방향을 찾도록 돕는 데 시간을 쏟고 있습니다.
지난 2년 동안 Google의 팀은 많은 새로운 최적화를 포함하고, 전반적으로 gRPC 구현을 다른 gRPC 구현들이 이미 도달해 있는 품질 수준까지 끌어올릴 새로운 크레이트로서 gRPC-Rust를 개발해 왔습니다. 이를 지원하기 위해 할당 제어 같은 기능을 지원하는 새로운 API를 활용하는 완전히 새로운 구현도 만들어졌습니다. 이는 훌륭한 일이지만, 여전히 많은 사용자가 tonic을 사용하고 있고 이 새로운 구조에 맞춰 코드베이스를 쉽게 다시 작성할 수는 없습니다. 현재 커뮤니티를 지원한다는 우리의 원래 핵심 원칙을 지키기 위해, 우리는 새로운 전송 계층 기능들(사용자 코드 생성이 아닌 부분)이 tonic의 코드 생성과도 호환되도록 설계했습니다. 이는 새로운 전송 계층에 추가될 로드 밸런서와 두꺼운 클라이언트 기능들을 현재 tonic 사용자가 채널만 변경함으로써 사용할 수 있게 된다는 뜻입니다. 이는 결국 우리가 기존 tonic 전송 계층을 더 가볍게 만들고, 많은 이점을 계속 얻으면서도 더 인체공학적이고 Rust다운 구현으로 전환하기 위해 예전 tonic 전송 계층을 폐기 예정 처리하게 될 가능성이 높다는 의미이기도 합니다. 우리는 여전히 이 부분의 세부 사항을 조율 중이며, 곧 나올 프리뷰 릴리스는 실제로는 여전히 tonic 전송 계층을 기반으로 할 예정입니다. 하지만 grpc-rust에서 새로운 클라이언트와 서버를 계속 구현해 나가면서 이 방향으로 나아갈 것입니다.
이 워킹 그룹을 만든 이점 중 하나는 기여에 관심이 있는 다른 회사들을 찾을 수 있었다는 점입니다. 그리고 여기서 LinkedIn의 분들이 가장 많이 요청되었고 구현하기도 가장 어려운 기능 중 하나인 xDS에 기여하기 위해 참여했습니다. 아직 xDS를 잘 모르신다면, 이것은 gRPC 클라이언트에게 서비스에 어떻게 도달하고 그 위에 어떻게 로드 밸런싱을 할지에 대한 자세한 정보를 제공하는 디스커버리 서비스입니다. 이는 Envoy 같은 서비스 메시 제품의 핵심 프로토콜로 사용됩니다. 매우 복잡하며, tonic에서는 이를 구축할 자원이 한 번도 충분했던 적이 없습니다. LinkedIn의 분들이 해주신 작업 덕분에 우리는 새로운 tonic-xds 크레이트를 배포하게 될 것이며, 또한 내부 메커니즘을 재사용하여 새로운 grpc 크레이트용 구현도 제공할 예정입니다.
워킹 그룹이 수행해 온 이 모든 작업을 통해, 마침내 tonic 프로젝트를 CNCF가 소유한 grpc 조직으로 업스트림할 준비가 되었습니다. 저는 계속해서 이 프로젝트의 핵심 메인테이너로 남겠지만, Google, LinkedIn, Datadog의 엔지니어들을 맞이하여 새 프로젝트와 기존 프로젝트 모두의 유지 관리를 함께 하게 될 것입니다. 이것은 tonic이 성숙한 단계에 이르러 마침내 다음 단계로 도약하는 순간입니다. Rust 사용자들은 앞으로 1년 동안 gRPC-Rust 팀으로부터 매우 훌륭하고 탄탄한 프로덕션 준비 구현을 기대할 수 있습니다. 이 전환을 계속해 나가는 동안, 이전 것과 새로운 것 모두를 위한 길을 함께 만들어 가기 위해 모두가 적극적으로 의견을 내고 피드백을 제공해 주시기를 권장합니다.
