Go1.24におけるruntime.mutex最適化
はじめにの前に 昨年12月初めに、一般社団法人Gophers Japanのご協力を得てGoLab2025 Recapを開催しました。 この記事では、せっかくなのでそのGoLab2025 Recapの発表でのrecap部分を文章にしました。 発表スライドとアーカイブ動画は以下です。 登壇までの流れなどはそちらで詳しく触れているのでよかったら見てみてください! 発表スライド アーカイブ動画 また、Golab2025での登壇自体は、一般社団法人Gophers Japanの海外カンファレンススカラーシップに採択していただいたおかげで、参加することができました。ぜひ興味を持った皆様はチェックしてみてください💪 ※この記事は2026年1月13日時点での情報を元にしています。 はじめに GoLab2025で、Raiza Claudinoさんが「Smarter Locks: Diving into Go
Writing mutexes from scratch in Go
Did you know that in programming, threads have been locking in before it was cool? A mutex (also known as a lock) is an object used to guarantee that only one thread can run a critical section of code at a time. The name “mutex” is short for mutual exclusion. Using a lock is straightforward in most popular backend languages: // Java Lock lock = new ReentrantLock(); lock.lock(); try { // critical s
株式会社Stackの2025年開発体制の振り返り｜sonatard
エンジニアは17人。 2025年は、チームとして機能開発やデリバリーに集中することができた1年だった。Go や Cloud に関する技術基盤の変化が小さく安定していたことが大きい。 改善面は、主にサーバ費用の削減、AI と多人数開発を前提とした制約の追加、内部ライブラリの品質向上に取り組んだ。 2024年と比較すると技術基盤の大きな変更は少なく、基盤が安定してきたことがわかる。代わりに2025年は、完成度を上げるための詳細な改善が増加した。 改善の加速Stackでは、専門の Enabling チームや Platform チームを設けていないため、構造的に改善を進めにくい環境にある。それでも開発と並行して積極的に改善に取り組んでくれるメンバーが増え、新たな視点からの改善が進んだ。 ドキュメントこれまでチームで管理するドキュメントは、品質や効果を安定させることが難しいと考えており、チームでのド
Dockerの裏側を知るために、Goで最小限のコンテナランタイムを作ってみた
コンポーネントと依存関係 各インターフェースがどのように実装の詳細を隠蔽(抽象化)しているか、メモ程度ですが具体的なメソッドレベルで書きます。 1. Domain Layer(internal/domain) ビジネスロジックが依存する仕様、振る舞いを定義しています。 ContainerInstance(Interface) 役割: libcontainerなどの低レベルなコンテナランタイム操作を抽象化。 マッピング: libcontainer.Container構造体が持つメソッド群（Run, Destroy, Signal, Status）を定義。 メリット: これにより、Usecase層はlibcontainerの実体を知らなくても、このインターフェースを通じてコンテナを操作(起動・停止)できる。 また、テスト時にはモックへの差し替えが容易になる。 ContainerReposito
Go の test における flag パッケージ活用Tips
先日、Findy さんのイベントにて testdata ディレクトリの活用についての発表をさせていただきました。 このイベントの中で、Golden Test の実現に標準の flag パッケージを活用できる話をしました。 testdata 利用の有無に限らずこのTipsは便利なので、知見の共有がしやすくなるように記事にしようと思います。 利用方法 test での flag パッケージの使い方は3ステップです。 // 1. パッケージをインポート import "flag" // 2. グローバル変数としてフラグを定義 var example = flag.Bool("example", false, "example flag.") // 3. テスト内で値を参照（*exampleでポインタから値を取得） func TestExample(t *testing.T) { if *examp
GoのMySQLドライバは、なぜパラメータ数が増えるとPrepared Statementが急激に遅くなるのか？
こんにちは、株式会社 PKSHA Technology ソフトウェアエンジニアの中西です。 1. はじめに Go 言語で MySQL を利用する場合、標準ライブラリの database/sql と、ドライバである go-sql-driver/mysql を組み合わせるのが一般的です。この構成は、事実上のデファクトスタンダードとして定着しています。[1] また、セキュリティ対策も重要です。特に SQL インジェクションを防ぐため、プレースホルダ ? を用いた Prepared Statement の利用はベストプラクティスと言えます。[2] しかし、この標準的で安全な構成でも、パフォーマンスが著しく劣化するケースはあります。本稿では Prepared Statement の 2 方式を整理し、Go のデフォルト設定で性能が落ちる原因をベンチマーク結果と合わせて示します。解決策と採用時のトレー
Go 1.26 は、軽くなり速くなる
はじめに この記事は Go Advent Calendar 2025、最終日 25 日目の記事です。 今年も皆さんお疲れ様でした。Go 1.26 がまもなくリリースされます。今回のリリースは派手さは無いにしろ、Go を使っておられる皆さんにとってはとても大きなリリースになるんじゃないかと思っています。 短い文章で言えば「軽くなり」「速くなる」です。 パフォーマンスに関する大きな変更2つ Green Tea GC Go 1.25 まで実験的に導入された Green Tea GC が 1.26 でデフォルトで導入されました。 これまで Go には数多くの GC 実装が取り込まれてきました。それぞれの GC により細かなチューニングがされ、パフォーマンス改善が行われました。 これまでの GC は、ヒープ上のオブジェクトへのポインタを追跡して個別にマークしていました。その結果メモリアクセスがランダ
タイミーの1,200万超ユーザーを支える認証基盤を Go と Ory Hydra で作っている話
はじめに こんにちは。タイミー CTO 室の成田（@7riatsu）です。 現在、タイミーは 1,200 万人以上のワーカーの皆様にご利用いただいています。そんなタイミーの認証基盤をゼロから作り直しています。 本記事では、CTO 室で開発を進めている Worker IdP（Identity Provider）について、技術選定やアーキテクチャ、Ory Hydra を選んだ理由、1,200 万人のデータ移行の品質保証の仕組みを、実際の設計判断を踏まえて紹介します。 Worker IdP は、タイミーで働くワーカー（エンドユーザー）向けの認証基盤です。セキュリティ強化や今後の事業展開を見据えた認証基盤を構築することを目的としています。既存システムから認証・ID 管理を独立した基盤として切り出し、OAuth2/OpenID Connect に準拠した設計とすることで、将来の拡張性も確保しています
実践ドメインモデリング！Modeling Forum 2025
こんにちは！ハコベル開発チームの古賀です。 「Hacobell Developers Advent Calendar」12日目の記事を担当します。 先日、Modeling Forum 2025 で開催されたドメインモデリングワークショップに参加してきました。 ドメイン駆動設計のモデリングをいちから体感する内容だったのですが、非常に学びが多かったのでその内容を紹介します。 ワークショップの概要 ドメイン駆動設計の基本コンセプトの一つである「モデル駆動設計」の考え方とやり方を手を動かしながら体験的に学ぶ内容です。講師は増田亨氏、佐藤治夫氏でした。 調整さん風アプリケーションを題材に、チームで議論をしながらイチからドメインモデルを実装していきました。この記事では、追加要件1までを実装した流れを紹介します。 モデルとは何か？ まず、ドメイン駆動設計において「モデルとは何か？」ということからディスカ
バリデーションとパースの分離。Goで実装する「変更に強い」CSV 処理の設計 - カミナシ エンジニアブログ
こんにちは。カミナシで「カミナシ 従業員」の開発を行っている nilpoona です。 業務アプリケーションを作っていると、避けて通れないのが CSV インポート機能 です。 最初は「encoding/csv で読んでループ回せば実装できる」と考えて作り始めるのですが、仕様が複雑になるにつれて、以下のような課題に直面することがあります。 バリデーションとパース処理が混在し、エラーの発生箇所が追いづらい。 「文字コードが Shift_JIS だった」など多様なエンコーディングへの対応で、ビジネスロジックが複雑になる。 パースやバリデーションエラーを即座にリターンしてしまうと、ユーザーは一つのエラーを直してもまた次のエラーが出る「モグラ叩き」のような修正サイクルを繰り返すことになる。 データが正しい状態か保証されないまま、後続の処理（DB 保存など）に渡されてしまう。 今回は、こういった CS
Go 1.26で生まれ変わるimage/jpegパッケージ
なぜ速くなったか 興味深いことに、旧実装も新実装も、同じLoefflerアルゴリズムをベースにしています。 Go 1.25までのfdct.goが参考にしていたIJGのFDCTの実装jfdctint.cには、ヘッダーコメントに以下の記述があります。 This implementation is based on an algorithm described in C. Loeffler, A. Ligtenberg and G. Moschytz, "Practical Fast 1-D DCT Algorithms with 11 Multiplications", Proc. Int'l. Conf. on Acoustics, Speech, and Signal Processing 1989 (ICASSP '89), pp. 988-991. これにより、性能差は「アルゴリズムの
docker-buildのチューニングTips全部書く【Go×GitHubActions】
docker の最新記法や、GitHubActions でのビルドチューニングについて網羅的に書かれている記事って意外と少ない！ 主に Go*GitHubActions での image ビルドについて、実行時間を短く・レイヤーを小さくする Tips を共有します 🚀 はじめにQualiArts Advent Calendar 2025 の 4 日目の記事です！ 最近 Go のビルド周りを改善するのが趣味で、情報が結構散らばっていて困った経験があるのでまとめます。 皆様の docker-build 改善のきっかけになれるような記事を目指します！どれか刺され！🔥 目次 1. .dockerignore を適切に設定するまずどのように docker がファイルを扱うのかを確認しましょう。 docker build時、docker デーモンに指定ディレクトリ配下のファイルを tar アーカイ
『リファクタリングは余裕ができたら』を卒業した話 〜ロードマップと歩むコード改善〜 - ANDPAD Tech Blog
この記事はANDPAD Advent Calendar 2025の 2 日目の記事です。 メリークリスマス🎄 バックエンドエンジニアの武山 (bushiyama) です。 去年に引き続き、ANDPAD請求管理のバックエンドを担当しています。 多くの開発現場で聞かれる「余裕ができたらやろう」。 しかし、ロードマップは常に詰まっており、その「余裕」は永遠に来ないのでは？ その考え方を「卒業」し、今年1年かけて実践してきました。 ロードマップ(機能開発)という「攻め」と、 リファクタリングという「守り（であり攻めでもある）」を両立させるためにどんなことをして、どんな成果をあげたかアウトプットするものです。 なぜ「卒業」する必要があったのか よくある話。 「余裕ができたら」と後回しにし続けた結果、以下のような症状が慢性化していました。 「あの機能、直したいけど触りたくない…」 軽微な修正のはずが
Go のアーキテクチャどうしてる？ ギフティで実際に試した構成パターンを紹介します - giftee Tech Blog
こんにちは、ギフティでエンジニアをやっている中屋(@nakaryo79）です! これは「ギフティ Advent Calendar 2025」と「Go Advent Calendar 2025」2日目の記事になります。 はじめに ギフティではここ数年、Go を採用したプロダクトが徐々に増えてきました。 採用の背景については、こちらの記事で詳しく紹介しています。 tech.giftee.co.jp さて、Go には Rails や Laravel のような「フルスタック Web フレームワーク」の決定版が存在せず、パッケージ設計についても明確なデファクトスタンダードがありません。 公式が提示している パッケージレイアウトのガイドラインも基本的な構成の話に留まっており、サーバーアプリケーションの内部構造をどう設計すべきかまでは踏み込んでいません。 そのため、ギフティでも新しい Go プロジェクト
Go + クリーンアーキテクチャで AI エージェント基盤を再設計した話【前編】
AIエージェントの開発を一気に行っていたのでそのまとめとなる記事を書いてみようと思います。 エージェント開発のSDKやノーコードツールは充実してきていますが、MVPとしてバックエンドとして使ってる Go でライブラリなどをあまり使わず開発を進めた結果、ほぼ自前で実装することになったので一からのAIエージェント開発ということで参考になるかと思います。 1. はじめに：なぜ Go で AI エージェント基盤を作るのか AI エージェントの実装といえば、一般には Python が選ばれます。 LangChain / LangGraph や LlamaIndex など、強力なエージェントフレームワークのサポートが充実しているからです。 ではなぜ筆者は、Go で、しかも（ほぼ）自前の AI エージェント基盤を一から構築したのか？ その理由は以下の 3 点に集約されます。 既存のバックエンドが Go
git worktreeをもっと便利に使うCLIツール `wtp` を作った
Claude Code で並行で複数の作業をすることが日常になってきており、 git worktree が欠かせない最近です。 git worktree は便利なのですが、毎日何度も worktree を作ったり消したりしているうちに以下が気になってきました。 worktree add のコマンドがやや冗長で面倒 ブランチ名を基に worktree を作る場合、ブランチ名を2度打つことになる 既存ブランチの場合: git worktree add .worktrees/hoge hoge 新規ブランチの場合: git worktree add -b hoge .worktrees/hoge 作成後に .env のコピーや npm install をほぼ毎回手動でやるので自動的にやってほしい Claude Code も必要なときにやってくれますが、ほぼ毎回必要なら AI に任せない方が早い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Are Atomic Operations Faster and Better Than a Mutex? It Depends
Building a Corruption-Proof Write-Ahead Log in Go
Goで作るセキュリティ分析LLMエージェント
Serverless Speed: Rust vs. Go, Java, and Python in AWS Lambda Functions