この記事は セゾンテクノロジー Advent Calendar 2024 3日目の記事です。
シリーズ2は HULFT10 のエンジニアによる投稿をお届けします。
はじめに
既存製品に、HULFT を使ってインターネット経由でファイル転送を行うインターネットファイル転送サービス SaaS形式の WebConnectがありますが、今回、外部サービスを利用することなく、オンプレ環境に導入してファイル転送の中継を行う、SmartProxyを開発しました。
開発にあたって管理サーバー側は、golang で作成し、ファイル転送の中継部分は、rustを使って開発を行いました。
今回はWebSocketを使い中継する製品を作成するにあたり、言語選定で気を付けたこと、選択したライブラリ（クレート）などを記載します
言語選定の要素
経緯は、上記に書いた通り。技術要素は、WebSocket Secure(TLS経路暗号) を用いる事でした。
HULFTは、OSネイティブなC/C++言語、機種によってはアセンブラで開発しているからこそ、効率もさることながら、メモリーやソケット、ディスク等のOSから得られるリソースの情報を制御、取得することで、障害発生時の回復やエラー報告などに定評を得ている製品です。
言語（ライブラリ）から得られる品質や脆弱性などの要素も、選定の一つでした
websocket を実現する際の選定要素
- 言語
- 対応OS
- ライセンス
- 脆弱性がないか
- リソース利用の効率性
言語
-
システムプログラミング言語である事
- 候補 : C, Rust
- デーモン化が出来る
- raw socket を扱うことができる
-
C
- 対応プラットフォームが多い
- 全てはCで出来ていると考えても良い
- 開発者が確保しやすい
-
Rust
- 対応プラットフォームが少ない
- Rust 自身は Linux / Windows では動作するが）
- 開発者は確保しにくい
- 対応プラットフォームが少ない
対応OS
- ターゲット Linux, Windows で動作する物
- HUFTと同一プラットフォーム上で動作する必要はなく、通信プロトコルだけ中継できればよい
ライセンス
- 商用利用するため、コードの公開の必要がないもの
脆弱性がないか
- rust : rustls rust 製のTLSライブラリ も存在するが、rust製のもの
- C : openssl-nativeだと脆弱性報告が多い(CVE結果)
リソース利用の効率性
- GC を利用する物は除外
- メモリー使用量の多い物は除外
- C10K 問題を回避している事
利用クレート
すでに社内で利用実績のあった以下のクレートを利用しました
- tokio
- tokio-rustls
- tokio-tungstenite
- tracing
- tracing-appender
- tracing-subscriber
まとめ
製品開発に Rust を利用して感じた事を以下につらつらと記載してみます。
- rustup update でツールを新しくしておく事
- 公開されているコードサンプルが利用したいクレートと組み合わせてコンパイルできないということが多々発生した
- クレートは、Cargo.toml に直接記述せず、cargo add で追加する
-
~/.cargo/registry/src/配下に、cargo add でdownloadしたソースとともに testコード存在している事がわかり、新しいバージョンでの記述の参考になった
- borrow checker とはまだ仲良くなれない
- rust-analyzer は必須
終わりに
もともと、C10K問題は解決したいと思っていたのですが、rust tokio, channel など非同期やリソース共有の機能がこんなに簡単に得られるとは思っていなかったので、Rust を選択してよかったと感じています。
Rustのごくごく一部しか理解していないので、学習を続けていきたいと思います
参考情報
- 2022/09/20 - 「Linux」、バージョン6.1でRustを導入へ--トーバルズ氏が明言
- 2022/09/23 - MS、AWS、Googleも本格採用へ--プログラミング言語「Rust」の最新動向を振り返る
- 2022/11/15 - 米国家安全保障局、CやC＋＋からメモリ安全なプログラミング言語への移行を推奨する文書を公開
- 2022/12/06 - google、Rust採用で「Android」のメモリーに関わる脆弱性が激減
- 2023/01/30 - 疑われる「C++」の安全性、今後の動きはどうなる