HW/OTチームの織江です。
今回は先日リリースされた弊社の新製品「EDGEPLANT T1 」の製品開発の軌跡を紹介したいと思います。 開発者視点から見た製品が出来上がるまでの経緯を眺めてもらえばと思います。
製品の企画や量産に伴うアレコレは別途改めてこのブログで紹介させていただきたいと思います。
続きを読む
HW/OTチームの織江です。
今回は先日リリースされた弊社の新製品「EDGEPLANT T1 」の製品開発の軌跡を紹介したいと思います。 開発者視点から見た製品が出来上がるまでの経緯を眺めてもらえばと思います。
製品の企画や量産に伴うアレコレは別途改めてこのブログで紹介させていただきたいと思います。
続きを読む
OTチームの大久保です。
エッジデバイス上でのデータ処理やネットワーク周りの実装に、速度と生産性の両面で優れるRust言語を利用できないかをここ最近は検討しています。特に、tokioのバージョン1.0がリリースされたように、最近はRustの非同期関連のエコシステムが充実してきたので、エッジデバイスでも応用できそうです。Rustのasync/awaitはゼロコストを謳っているので、安心して使うことができます。しかしながら、極めて高頻度に呼び出される関数がasyncであった場合、普通の同期的(asyncではない普通のfn)な関数に比べて、asyncであることによる関数の呼び出しコストの増加は無いのでしょうか。実用上は、asyncな関数は内部で非同期IOを行うはずなので、それに比べれば関数の呼び出しコストは微々たるもので気にする必要はありませんが、以下のような場合には問題に成りえます。
今回は、このうち2番目のような状況を想定し、何度も値を取り出すイテレータの非同期版、つまりストリームを複数の方法で作って、実行速度を検証してみたいと思います。
続きを読む
こんにちは、aptpodのサーバーサイドエンジニアの宮内です。
突然ですが、APIのレートリミット実装していますか? 最近、弊社のバックエンドAPIでもレート制限を実装しました。
Generic Cell Rate Algorithm (GCRA) を使ったのですが、 このアルゴリズムが面白かったので、今回はこのGCRAについてと、GoでGCRAを利用したレートリミットについて説明します。
続きを読む
SRE チームの川又です。
Volterraはグローバルで優れたEdge-as-a-Service プラットフォームサービスを提供する事で注目を集めています。 先日、F5, Inc. に買収された事でも話題になりました。
一方、弊社intdash の一部を構成する intdash Server は基本的にクラウド上で動作させます。 ですが、お客様の要件によってはEdge 環境で動作させる事もあります。 SRE チームの検討課題の1つとして、Edge 環境における効率的なサーバアプリケーションの管理・提供 があります。
以上の背景から、今回はVolterraのサービスプラットフォーム上でintdash Server の一部であるintdash のbackend service を簡易に動作させてみましたのでご紹介します。
VPoP として弊社の製品全体を統括しております、岩田です。
弊社では以前から、自社製品が使用する通信方式の下回りとして QUIC を使用することができないか 、継続的に調査や検討を行ってきました。QUIC が HTTP/3 をメインターゲットとして最低限の仕様策定を進める方向になって以降、QUIC 検討に対する社内の熱量も多少減退してはいたものの、昨年の WebTransport 周辺の動きを受けて、再度勢いを取り戻しつつあります。
QUIC DATAGRAM は、QUIC を HTTP 向けの ベターTCP としてだけではなく、UDPベース であることを生かしたユースケースで利用できるようにするための追加仕様で、UDP Like な通信を導入することで QUIC の用途を映像伝送やゲームなどのリアルタイム通信に拡張しようとするもの です。QUIC DATAGRAM 自体は、提唱されてから意外と時間の経っている仕様ではありますが、ここ最近 WebTransport や WebRTC での活用という話題が出始めて以降、動きが活発化してきているように感じています。
そんな矢先、以前から検証に使用していた Go製の QUIC ライブラリである quic-go が QUIC DATAGRAM に対応した ので、早速試して記事にしてみたいと思います!
続きを読む