至高のGoプラグイン用ツールを作った - knqyf263's blog
最近YouTuberのリュウジの料理を毎日作っているので至高とか無限とか言いがちですが個人の感想です。万人にとって美味しい料理はないように、万人にとって至高のツールは存在しません（何の話？）。ちなみに公開してすぐバグを見つけてしまったので全然至高じゃありませんでした。 要約 概要 特徴 使い方 流れ 事前準備 インタフェースの定義 SDKの生成 プラグインの実装 ホストの実装 実行 発展 Host Functions ファイルアクセス その他 苦労した点 まとめ 要約 Goでプラグイン機構を実現するためのツールを作りました。Protocol Buffersのスキーマからコードを自動生成するので簡単にプラグイン機構を実現可能です。内部的にはWebAssembly（Wasm）を使っています。最近はWasmはブラウザ外での利活用が進んでおり、今回のツールもブラウザは一切関係ないです。Wasmはサ
Goにおける型によってSQLインジェクションを防ぐ方法
はじめに 2022年のセキュリティ・キャンプ全国大会に講師として参加しました。その際に、Goにおける脆弱性への対策はどうなっているのか調べました。この記事では、github.com/google/go-safeweb/safesqlがどのようにSQLインジェクションを防いでるのかについて解説します。 なお、@rungさんの文書を多いに参考にしております。また、セキュリティ・キャンプで用いた資料はこちらから閲覧できます。 SQLインジェクションとは？ 独立行政法人情報処理推進機構（IPA）が公開している安全なウェブサイトの作り方を見ると、SQLインジェクションは以下のように説明されています。 データベースと連携したウェブアプリケーションの多くは、利用者からの入力情報を基にSQL文（データベースへの命令文）を組み立てています。ここで、SQL文の組み立て方法に問題がある場合、攻撃によってデータベ
Go製ミドルウェアのメモリリークを解決した話 - Mirrativ Tech Blog
インフラ・ストリーミングチームの id:udzura （@udzura）です。今回は、Goミドルウェアのメモリリークを見つけて解決する際に、どのようなプロセスを踏んでいったかを解説します。 Go製のミドルウェアの概要 ミラティブでは、Webアプリケーションのみならず、ミドルウェアに相当する部分についても必要なものは内製しています。その中の一つに、社内で「Radisha」と呼んでいる各種集計とキャッシュなどを行うためのミドルウェアがあります。Radishaは以下のような特徴を備えています。 GET、SET、SETEXなど基本的なRedis互換のコマンドを実装している。そのため、既存のRedisクライアントライブラリから操作が可能である。 ランキング集計、一定時間内のアクセス集計などが行えるよう、Redis にない独自のコマンドを実装している。 高い可用性を志向しており、オンメモリのデータは
Reducing Memory Allocations in Golang
Go’s place between C and Python in terms of abstraction and garbage collection memory management model has made it attractive to programmers looking for a fast but reasonably high level language. However, there is no free lunch. Go’s abstractions, especially with regards to allocation, come with a cost. This article will show ways to measure and reduce this cost. Measuring On posts about performan
Goのロギングライブラリ 2021年冬 - moriyoshiの日記
この記事はPySpa Advent Calendar 2021の14日目のエントリーとして書かれました。昨日のエントリーは冷凍食品でウキウキ引きこもり生活 でした。ちなみに私も70ℓの冷凍庫を購入しましたが本当にライフチェンジングでした。 総論: なぜログが必要か 可観測性 たとえ目的は自明でも、その動作までが自明なアプリケーションというものはほぼ存在しません。現実の世界のアプリケーションというものは、動作パラメータだったり実行環境だったり、起動時点でのさまざまな要因によって挙動を変えるものだからです。そして、そうしたアプリケーションにはライフサイクルというものがあります。ここでいうライフサイクルは、アプリケーションの処理が実行されるにつれ、アプリケーションの内外との情報のやりとりで生じる大局的な状態の変化のことです。アプリケーションが並行処理を行うようなものであれば、個々の並行処理の単位
Goとマルチコアスケール実装
マルチコア化の未来予測 半世紀前にSF映画「2001年宇宙の旅」に登場するコンピューターHAL-9000が並列コンピューティングの未来を示しました。マルチコアで構成されたコンピューターの物理コアを取り除いてもすぐにクラッシュせずに性能ダウンして処理が継続するという演出がありました。 当時ですらシングルコアコンピューティングの限界が予想されていて、現状のコンピューティングがマルチコア化しているという未来をしっかり予測できていたことがわかります。 演出はコア数に応じてコンピューティング性能がスケールしていることを表現しています。これはマルチコアスケールするソフトウェア実装の未来を示していたと思います。 シングルコア性能向上の頭打ち 2003年以降あたりはCPUの動作周波数が伸び悩み出したところ。 https://queue.acm.org/detail.cfm?id=2181798 より その
Deep Dive into The Go's Web Server
Goのnet/httpパッケージはとてもよくできており、Webサーバーを動かすのに必要になる「httpコネクションを確立してリクエストを読んでルーティングして……」という手続き的な処理を気にせずとも誰でも簡単にWebサーバーを立てられるようになっています。 ですが、そのnet/httpが代わりにやってくれている「裏側の処理」の部分が気になる、何やっているんだろう？と不思議に思っている方はいませんか？ この本では、実際に筆者がnet/httpパッケージのソースコードを読み込んだうえで、「GoのWebサーバーがどのような仕組みで起動・動いているのか」というところについて、図を使いながら解説しています。
GitHub - cloudwego/netpoll: A high-performance non-blocking I/O networking framework focusing on RPC scenarios.
Netpoll is a high-performance non-blocking I/O networking framework, which focused on RPC scenarios, developed by ByteDance. RPC is usually heavy on processing logic and therefore cannot handle I/O serially. But Go's standard library net is designed for blocking I/O APIs, so that the RPC framework can only follow the One Conn One Goroutine design. It will waste a lot of cost for context switching,
解説&翻訳 - A Quick Guide to Go's Assembler
この記事について Goの実装というのは基本的にはGo言語そのもので行われますが、runtimeパッケージやmath/bigといった低レイヤ・マシンと密接に関わる部分に関してはGoアセンブリで実装されています。 そしてGoアセンブリについては、公式ドキュメントであるA Quick Guide to Go's Assemblerにある程度の説明が記載されています。 この記事では、前半ではドキュメント"A Quick Guide to Go's Assembler"を読むために必要になる前提知識をまとめ、後半ではドキュメントの翻訳を行います。 使用する環境・バージョン go version go1.16.2 darwin/amd64 想定読者 この記事では、以下のような方を想定しています。 runtimeパッケージやmath/bigパッケージ内に存在するアセンブリを読んで、何やってるのかある程度
GoはいつGCするのか?
TL;DR Go(のランタイム)は以下のタイミングで自動的にGCを実行する 前回のGC後に占有していたメモリと同量を新たに確保したとき 前回のGCから2分後 cgroupなどでメモリ制限しているときは、メモリ使用量が制限の50%以上になったらruntime.GC()を呼び手動でGCすべきである 前置き: GoとOOMのこれまで 以下はGo 1.16での調査結果です。Goのバージョンが異なった場合は事情が異なる可能性があります。 Goでプログラムを書く際に、使用メモリ量を気にしなければならないシーンはGCのおかげでそう多くはありません。実際それは間違いではないのですが、運用まで視野に入れるとそうは言ってられないことがあるのもまた現実です。昨今はコンテナの利用が当たり前になったことに伴い、OOMによりプロセスが強制的に終了させられることもあり、それを避けるために一定量以下のメモリで動くことが重
Goで開発した配信サーバーのメモリ使用量問題に向き合う - Mirrativ Tech Blog
こんにちは。ストリーミングチームの松本です。 Mirrativのストリーミングチームは、低遅延配信や、通知ぼかしというような機能を追加するため、配信のorigin serverの前段にtranscoder serverというものを導入してきました。 tech.mirrativ.stream tech.mirrativ.stream transcoder serverはGoによる内製のミドルウェアであり、主に映像の変換を行う目的で作られました。現在は配信プロトコルの変換（既存プロトコル -> 低遅延プロトコル）などを行っています。また、実際にはサーバー上のDockerコンテナ内で動作しています。 transcoder serverを展開していくにあたり、メモリ使用量が常に増え続ける問題が起きていたため、その際に直面したGoの実メモリ使用量に関する話を書きたいと思います。 メモリ使用量の増加問
Go コンパイラのコードを読んでみよう - kosui
はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ？」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか...。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分解することで、少しずつ読み進めることができると分かったのです！ 何よりも感動したことは、 gc そのものが全て Go で書かれていて、
Chris's Wiki :: blog/programming/GoConcurrencyStillNotEasy
Even in Go, concurrency is still not easy (with an example) Go is famous for making concurrency easy, through good language support for goroutines. Except what Go makes easy is only one level of concurrency, the nuts and bolts level of making your code do things concurrently and communicating back and forth through channels. Making it do the right things concurrently is still up to you, and unfort
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reddit - Dive into anything
GitHub - soypat/ieeeztreme14: IEEExtreme 14.0 solved problems for team finally_cflat
よくわかるcontextの使い方
research!rsc: Memory Models
Goでの並行処理を徹底解剖！
Go言語低レイヤー入門 Hello world が 画面に表示されるまで (GoConforenceTokyo2021)
Learn Go with tests
