はじめに Goは GCを備えており、開発者がメモリ管理を直接気にする場面はそう多くありません。 「ヒープに乗ったオブジェクトは、いずれ自動で解放される」....この前提でコードを書けるのは、Goの大きな魅力のひとつです。 GCは自動で動きますが、いつ動くかは決まったルールで制御されています。 そのルールを知らないまま「いつかGCが回収してくれるはず」と思ってコーディングしてしまうと、OOMを引き起こしてしまう可能性があります。 本記事では、Goランタイムが持つ4つのGC発火タイミングを、サンプルコードを動かしながら整理します。 GC(Garbage Collection)とは Garbage Collectionとは、プログラムが使用しなくなったヒープ領域のメモリを自動的に回収する仕組みのことです。これにより、開発者はメモリ管理を意識せずにコードを書くことができます。 ざっと、コンテナでG
はじめに こんにちは、タイミーでエンジニアをしている徳富(@yannkazu1)です。 クラウドネイティブ会議2026で発表された「ペアーズ本番環境でのcgroup-aware化との死闘録」がめちゃくちゃ面白かったので、自分の手でも体感したくなりました。 GoのGOMAXPROCSがコンテナのCPU制限を無視するって、実際に見るとどうなるのか？ 過剰並列のスループット低下って、数字で見るとどのくらいインパクトがあるのか？ スロットリングとスレッド数の関係を自分の目でたしかめたい！ 自分で動かして数字を見ないと腑に落ちないタイプなので、ローカルのMac環境で全部再現してみました。 発表の要約 ペアーズのバックエンド pairs-main はGo製でAmazon EKS上で稼働。48コアのNodeで limits.cpu: 5000m（5コア）のPodが動いていたが、GoのGOMAXPROCS
Hey, dipshit. You know what compiles in two seconds, deploys as a single binary, and doesn't shit itself when a transitive dependency gets yanked from npm at 3am? Go. The same way HTML has been sitting there since the dawn of the goddamn internet waiting for you to stop overcomplicating the frontend, Go has been sitting there for over a decade waiting for you to stop overcomplicating the backend.
レイヤードアーキテクチャのルールを守りつつ、RDBのトランザクションを管理する方法は悩みの種になるポイントだと思います。 本記事では「 口座の送金処理 *」を題材に、 Golang + GORM を使った4つのトランザクション管理パターンをまとめてみます *送金元口座から残高を引き出し、送金先口座に入金する処理の一貫性を保証する話です。失敗が発生した場合は操作をロールバックする必要があります 前提 本記事では、レイヤードアーキテクチャの構成を以下のように定義します。特に、Application, Domain, Infrastructure層についての実装を紹介していきます Presentation層 : UIやAPIレイヤー、ユーザー入力や出力を扱う層 Application層 : アプリケーション全体のビジネスロジックを統括する層 Domain層 : エンティティや集約、ドメインサービ
前提 「これは違う」と否定したいわけではなく自分の中で納得したいから突き詰めて考える記事です！ ドメインサービスでrepositoryを呼んでるコード 弊社のコードベースにはドメインサービスでrepositoryを実行してるコードがたくさんあった。 前職の技術顧問から「ドメインサービスでrepositoryを呼んではいけない」と聞いていたので違和感を持ちました。ただ昔すぎて詳細に関しては忘却の彼方でした。 DDDで有名な人も呼んでる DDDで有名な松岡さんの記事でもドメインサービスでrepositoryを呼んでいます。 この記事の中の「Taskが作成されたらActivityReportが作成される」ということはドメイン層の知識として重要なのに、その知識がドメイン層に書かれていない(=ドメイン層のコードを読んでも読み取れない)」という文章に関して確かにと思いました。 そもそもドメインサービス
本記事は私がGoでクリーンアーキテクチャを採用したプロジェクトを運用する中で得た気づきをまとめたものです。各セクションの根拠となる一次情報源は、該当箇所に参照リンクを記載しています。 Goでクリーンアーキテクチャを導入したとき、私が最初にぶつかった壁は「interfaceが多すぎる」という問題でした。 Repository、InputPort、OutputPort、UseCase、Presenter…レイヤーごとにinterfaceと実装のペアが増殖しました。1つの機能を追加するのに何ファイルも触る状態でした。 しかし運用を続ける中で、interfaceの数そのものは問題ではないと分かりました。本当の問題は1つのinterfaceが太すぎることと、Go の言語特性を活かせていないことでした。 この記事では、教科書通りに作った設計をGo の思想で見直すプロセスを共有します。 教科書通りに作っ
GoでよくDockerfileとComposeを書いてるんですが、いい感じの書き方が固まってきたので共有します。 コード例 もあるのでご自由にどうぞ！ 1. マルチステージビルドにする もう当たり前だと思うので割愛しますが、マルチステージビルドは必須です。 ビルドに必要なものと、実行に必要なものを分けるだけで、最終イメージのサイズと攻撃面をかなり抑えられます。 2. Distrolessを使用する 実行イメージは小さいほど扱いやすいですが、単にAlpineを選べばよいわけでもありません。 Alpineだと実効性能が落ちるケースもあるらしいので、Distrolessを選びましょう。 静的リンクできるGoのバイナリなら、static 系の最小構成イメージでそのまま動かせます。 更に nonroot タグを使って、最初から非rootで動かすのもおすすめです。 また必要なら cosign でイメー
はじめに Go のコンパイラにはスライスや配列へのアクセス時に、インデックスが範囲内にあるかを実行時にチェックする仕組みがあります。いわゆる境界チェック (Bounds Check) です。この境界チェックは安全性の為に必要な物ですが、ループの中で何万回も実行されると無視できないオーバーヘッドになります。 Go のコンパイラは SSA (Static Single Assignment) の最適化パスの中で、境界チェックが不要と証明できたアクセスについてはチェックを除去します。これを BCE (Bounds Check Elimination) と呼びます。つまり、コンパイラが「このアクセスは絶対に範囲内だ」と証明できる様にコードを書けば、余分な境界チェックが消えて速くなるという訳です。 encoding/hex パッケージに対して、まさにこの BCE を活かした高速化の PR が提出され
CLIをAI AgentフレンドリーにするためにAgent Skillsがあると嬉しい。Agent Skillsは絶賛リポジトリで協議されているが、オープンスタンダードであり、各ベンダーがそれなりに足並みをそろえながら仕様がアップデートされている。フロントマッター付きのSKILL.md というMarkdownを .agents/skills/skill-name/SKILL.md のような場所に配置することで、Agentにskillを備えさせられる。配置場所も各ベンダー独自の場所もあったが、最近は主要ベンダーが .agents/skills もサポートし、その点では安定した。 OSS作者もリポジトリルートに skills/ ディレクトリを掘り、その中にAgent Skillsを置く人も増えてきた。そうしておけば、skills add などのインストーラーでスキルを導入しやすくなる。 そこで
はじめに Go 1.26からは、 go fix コマンドによって古い書き方のコードを自動的にモダンな書き方に修正できるようになりました。この処理は golang.org/x/tools/go/analysis/passes/modernizeパッケージに定義されている種々の静的解析器 (Analyzer) によって実現されています。 これらのAnalyzerがどのようなコードを修正してくれるのか知ることで、我々もモダンなGoの書き方を速習できるのではないでしょうか。……ということで、この記事ではmodernizeパッケージが提供するAnalyzerに対応するモダンなGoの書き方をまとめてみました。 はじめに Analyzerに対応するモダンな書き方の一覧 any (Go 1.18) appendclipped (Go 1.22) bloop (Go 1.24) errorsastype (
はじめにTIG（Technology Innovation Group）の真野です。 Go 1.26ブログ連載 の3日目は、go fix コマンドのアップデートについて解説します。 go fix の出発点リリース内容へ入る前に、go fix そのものについて解説します。 まず、Go 1.26で新しく go fix コマンドが追加されたわけではありません。コマンド自体は2011年4月15日に公開されたIntroducing Gofixというブログで紹介され、その翌月リリースのr57 で追加されました。つまり、誕生から15年近く経過する由緒ある（？）ツールとも言えます。 それにも関わらず、 go fix コマンドはあまり有名で無いと思います。なぜでしょうか。 まず、Go言語が1.0に到達したのは、2012年3月28日で、go fix コマンドが紹介されたのはその1年前です。現在と大きく異なり、
はじめに 最近、Jeremy Morrell氏の「A Practitioner's Guide to Wide Events」という記事を読んで、Wide Eventという概念に出会いました。 Observabilityの世界では「ログ・メトリクス・トレース」の3本柱が有名ですが、Wide Eventはこれらとは少し異なるアプローチを取ります。 この記事では、Wide Eventの概念を紹介しつつ、GoとOpenTelemetryでの実装方法を解説していきます。 Wide Eventとは Wide Eventとは、「関連しうる情報を可能な限り詰め込んだ構造化イベントのこと」です。構造化イベントという言葉はオブザーバビリティにおいては多義的なものですが、基本的にWide Eventを実装する際は、リクエストがきた時のスパン等のメインのスパンに対してなるべく多くの情報を付与しようという考え方で
コンポーネントと依存関係 各インターフェースがどのように実装の詳細を隠蔽(抽象化)しているか、メモ程度ですが具体的なメソッドレベルで書きます。 1. Domain Layer(internal/domain) ビジネスロジックが依存する仕様、振る舞いを定義しています。 ContainerInstance(Interface) 役割: libcontainerなどの低レベルなコンテナランタイム操作を抽象化。 マッピング: libcontainer.Container構造体が持つメソッド群（Run, Destroy, Signal, Status）を定義。 メリット: これにより、Usecase層はlibcontainerの実体を知らなくても、このインターフェースを通じてコンテナを操作(起動・停止)できる。 また、テスト時にはモックへの差し替えが容易になる。 ContainerReposito
こんにちは、株式会社 PKSHA Technology ソフトウェアエンジニアの中西です。 1. はじめに Go 言語で MySQL を利用する場合、標準ライブラリの database/sql と、ドライバである go-sql-driver/mysql を組み合わせるのが一般的です。この構成は、事実上のデファクトスタンダードとして定着しています。[1] また、セキュリティ対策も重要です。特に SQL インジェクションを防ぐため、プレースホルダ ? を用いた Prepared Statement の利用はベストプラクティスと言えます。[2] しかし、この標準的で安全な構成でも、パフォーマンスが著しく劣化するケースはあります。本稿では Prepared Statement の 2 方式を整理し、Go のデフォルト設定で性能が落ちる原因をベンチマーク結果と合わせて示します。解決策と採用時のトレー
こんにちは。カミナシでID管理・認証基盤の開発に携わっている小松山です。私の携わっているプロダクト『カミナシ ID管理』では、バックエンドに Go を採用しています。この記事では、Go のエラーハンドリングとエラーロギングの改善事例を紹介します。 はじめに 私たちのチームでは、定期的にシステムのメトリクス・トレース・ログなどを確認し、運用の健全性を確認する「サービスレビュー」という取り組みを行っています。その一環で出力されたエラーログを確認しているのですが、以下のような課題がありました。 同じerr を関数・メソッドから受け取った直後にロギングしてしまっている箇所が多く、リクエスト内で発生したエラーに対して複数回エラーログが出力されている context canceled やクライアントエラーのログも Error レベルで出力されている 上記問題のため、サービスレビューを行うたびに「このエ
mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日本語化やプラグイン、Go言語などでOSS（オープンソースソフトウェア）の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023年 GitHub Stars。著書に『みんなのGo言語』（2016年、2019年に改訂2版、技術評論社、共著）、『Go 言語プログラミングエッセンス』（2023年、2025年に改訂新版、技術評論社、単著）がある。関西在住。 X:@mattn_jp GitHub プログラミング言語の学習において、チュートリアルや書籍で基本文法を押さえたあと、「手を動かして何かを作る」というのはよくあるステップです。しかし、基礎を終えたばかりのエンジニアにとって「何をつくればその言語の特性を深く理解できるのか
この記事は「Hacobell Developers Advent Calendar」ー 8日目の記事です。 はじめに 「あの言語の並行処理って、結局どう動くんだっけ？」 日々の開発業務に追われる中で、ふと立ち止まってしまうことはありませんか？現代のアプリケーション開発において、マルチコアCPUの性能を最大限に引き出し、ユーザーに快適なレスポンスを返すために並行処理の理解は不可欠です。 しかし、使用する言語によって、そのアプローチや内部的な挙動は驚くほど異なります。 本記事では、Node.js, Python, Ruby, Goをピックアップし、それぞれの並行処理モデルが「CPUバウンドなタスク」と「I/Oバウンドなタスク」に対してどのように振る舞うのか、具体的なコード例を交えながらその違いを再整理します。 対象読者 本記事は以下のような方を想定しています。 複数の言語を日常的に使用している
起動してから、指定された処理を「s秒ごと」のように固定間隔で実行し続ける、というワーカー的なプログラムを考える。 何も考慮しない場合 最も原始的には以下のように time.Ticker を使ってループし続ければ良い。 type Worker struct { interval time.Duration task func(context.Context) } func NewWorker(interval time.Duration, task func(context.Context)) *Worker { return &Worker{ interval: interval, task: task, } } func (w *Worker) Start(ctx context.Context) { ticker := time.NewTicker(w.interval) defer
エージェント実装の理解を深めたいなと思い、「Goで作る自作コーディングエージェント nebula 開発入門」を読みながらコーディングエージェント実装の写経をしてみた。学びが多く、非常に良かった。 zenn.dev 実際に作ったコードは https://github.com/shibayu36/nebula にある。資料と違って、ちょっとだけ設計を変えてみたり、セッション一覧表示を作ったり、編集時のdiff表示を作ってみたりなどもしてみた。 この実践では、エージェントを作る時の基本構成や設計パターンについて概要を学ぶことができた。たとえばツールコール、システムプロンプト設計、メモリ機能設計など。この辺りはAIエージェントを作る上でコーディングエージェント作り以外にも役立つ知識なので、手を動かして深めに理解できたのは良かった。 Goを普段書いていて、AIエージェント作りに挑戦してみたい人にとっ
OAuth 2.0 / OIDCを理解するために、自分でGoで実装してみました。 以下のハンズオンに従って実装していただくと、OAuth認可コードフローとOIDCの一連の流れの理解が深まると思います。 概要 OAuth 2.0は、ユーザーの認証情報を直接アプリに渡すことなく、外部サービスを通じて安全に認可を行うためのプロトコルです 。特にWebやモバイルアプリ開発では、認証と認可を分離しセキュアに委譲する手段として広く利用されています。OpenID Connect (OIDC)はOAuth2.0を拡張してユーザーのアイデンティティ情報を扱う仕組みで、OIDCではIDトークンと呼ばれるJWT形式のトークン（署名付き）が発行され、これによってクライアントはユーザーを識別できます。OAuth2.0単体ではユーザー個人を表すトークンは発行されませんが、OIDCではscopeにopenidを含めるこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
