技術の深掘り・日常など幅広く紹介してます
ゲーマー向けのテキストチャットサービスとして有名な Discord は、内部コンポーネントの一つである「Read States」を Go から Rust に再実装し、パフォーマンスが大幅に向上したことを発表しました。Discord のホットパスである「Read States」は、特に膨大なリクエストを捌く必要があり、システム自体に高いパフォーマンスが要求されるコンポーネントだそうです。 これまで、Discord の大部分は Go で実装されていましたが、2020 年初頭に Rust へ移行したことが明らかになりました。最近、Rust のキャッチアップをしていることもあり、なぜ、Discord は Go から撤退して Rust を採用したのか気になったので、公式ブログ を参考にまとめてみたいと思います。
ネットワーク経路上のルータ（ソフトウェアルータ）をはじめとし、ロードバランサやキャッシュサーバ等のミドルウェアは、特に高いパケットレートを処理する必要があります。 これらのシステムは、膨大なパケットを迅速かつ効率的に処理するために、物理および論理の両方で高いパフォーマンスが要求されます。ネットワークトラフィックの処理は、コンピュータシステムにとって非常にリソース集約的な作業であり、高パケットレート環境下では CPU に掛かる負荷が非常に大きくなってきます。 ネットワークミドルウェアでは、多数のクライアントからの要求を捌くために、マシン内の処理に起因する負荷を効率的に分散・軽減させる必要があります。アプリケーションをマルチコア環境でスケールさせる際、CPU 負荷が特定のコアに集中することでシステム全体のパフォーマンスが低下する場合があります。 この問題を解決するため、Linux ネットワークスタックの NAPI や NIC のオフロード機能が、CPU の割り込み処理を効率化し、パフォーマンスを最適化する上で重要な役割を果たします。また、マルチコアスケーリングを効果的に実現するためには、NIC の RSS やカーネルの RPS/RFS といった機構も活用する必要があります。 これらの技術により、パケット処理を複数の CPU コアに分散させ、システム全体のパフォーマンスを最適化することが可能です。今回のブログでは、高パケットレート環境下において膨大なリクエストデータを捌くために Linux カーネルが取った対策について紹介したいと思います。
Go で競技プログラミングに臨んだことがある人なら、一度は fmt.Scan 関数の落とし穴にハマったことがあるのではないでしょうか。 Go では標準入力を受け付ける際に、fmt.Scan 関数、もしくは bufio.Scanner メソッドや bufio.ReadLine メソッドをよく用います。 しかし、Go を使って競技プログラミングをやる場合、bufio.Scanner を使用しなければ困る場面があります。 今回のブログでは、fmt パッケージの Scan 関数と bufio パッケージの Scanner メソッドに注目しながら、fmt.Scan で TLE が発生する原因と解決策について紹介します。