aptpod Advent Calendar 2020の2日目を担当します、研究開発グループの大久保です。 弊社では、新しいプロトコルであるQUICの利用法を調査しています。そこで今回は、RustのQUIC実装の1つであるQuinnを用いて、受け取ったリクエストをそのままクライアントへ返送するechoサーバを実装してみます。RustのQUIC実装には、他にquicheというものもありますが、Quinnはtokioの上に実装されているため、Rustのasync機能を活用して楽に書くことができます。 構成 quinn-echo-serverとquinn-echo-clientという2つのクレートを作り、それぞれのCargo.tomlに以下の依存関係を追記します。 [dependencies] anyhow = "1" clap = "3.0.0-beta.2" futures = "0.3"

OTチームの大久保です。 エッジデバイス上でのデータ処理やネットワーク周りの実装に、速度と生産性の両面で優れるRust言語を利用できないかをここ最近は検討しています。特に、tokioのバージョン1.0がリリースされたように、最近はRustの非同期関連のエコシステムが充実してきたので、エッジデバイスでも応用できそうです。Rustのasync/awaitはゼロコストを謳っているので、安心して使うことができます。しかしながら、極めて高頻度に呼び出される関数がasyncであった場合、普通の同期的(asyncではない普通のfn)な関数に比べて、asyncであることによる関数の呼び出しコストの増加は無いのでしょうか。実用上は、asyncな関数は内部で非同期IOを行うはずなので、それに比べれば関数の呼び出しコストは微々たるもので気にする必要はありませんが、以下のような場合には問題に成りえます。 asyn

はじめに こんにちは。 アドベントカレンダー ８日目担当、 サーバーサイドエンジニアの miyauchi です。 昨年は「 Goとクリーンアーキテクチャとトランザクションと」と「Vim初心者から中級者の入り口くらいまで」を書きました。 早いものでもう一年経つのですね。 さて、弊社ではバックエンドシステムを従来のモノリス型のサービスから、徐々にマイクロサービスへ移行中です。 そんな中で分散トレーシング（とりわけOpenTracing）について調査する機会がありました。 よって、今年はGoのアプリケーションで、OpenTracingを使うときのコード集を、解説ありで書いていきたいと思います。 「OpenTracingとは！」や、「分散トレーシングとは！」のような概念部分は書きません。 また、OpenTracingのTracer実装であるjaegerについても詳細は書きません。 OpenTrac

はじめに VPoP として弊社の製品全体を統括しております、岩田です。 弊社では以前から、自社製品が使用する通信方式の下回りとして QUIC を使用することができないか 、継続的に調査や検討を行ってきました。QUIC が HTTP/3 をメインターゲットとして最低限の仕様策定を進める方向になって以降、QUIC 検討に対する社内の熱量も多少減退してはいたものの、昨年の WebTransport 周辺の動きを受けて、再度勢いを取り戻しつつあります。 QUIC DATAGRAM は、QUIC を HTTP 向けの ベターTCP としてだけではなく、UDPベース であることを生かしたユースケースで利用できるようにするための追加仕様で、UDP Like な通信を導入することで QUIC の用途を映像伝送やゲームなどのリアルタイム通信に拡張しようとするもの です。QUIC DATAGRAM 自体は、提

はじめまして！WEBチームの黒川と申します！昨年7月にaptpodに入りましてもうすぐaptpod歴1年になります！ aptpodでは主にフロントエンドエンジニアとしてReact/TypeScriptを用いて、お客様向けアプリケーションのUI部分を実装しております。 ご存じの方も多いように、Reactの状態管理にはいくつか方法があり、何を用いるべきかなどでしばしば議論が起こりがちです。代表的なものだけでも、標準APIを用いるuseStateとContextやデファクトスタンダードとなってきているRedux、そして新興のRecoilがあります。 弊社のWEBチームではReduxを採用するケースが多いです。私もReduxについては一通りの知識と経験は持っていたつもりだったのですが、先日担当させていただいたプロジェクトで初めてReduxの設計に取り組んだところ、自分がReduxの思想や勘所につい