<h1 id="h8cc66f2129">dotenvxによる暗号化だけでは不十分</h1>つい最近、X（旧Twitter）でこんな話題が盛り上がっていました。 「LLMと開発する上で、.envファイルをどう管理するか」 「dotenvxで暗号化すればOK」という回答をよく見かけました。しかし、この問い自体が狭い。LLMが同じ実行環境にいる時に危険にさらされるのは.envだけではありません。 SSOセッション、1Passwordのアンロック状態、シェル履歴、実行中のプロセスの環境変数——全部同じ土俵の話です。 さらに言えば、議論の多くが「どこに保存するか（Write）」にばかり目を向けていて、「誰が読み出せるか（Read）」の経路を議論していなかった。 本質的な問いは「LLMが同じ実行環境にいる時、何が危険にさらされるか」です。この記事ではその問いから設計を考え、最終的には社会的な信頼の話にまで行き着きました。 <h2 id="hcf83e1357e"> </h2><h1 id="h95484ce73d">脅威モデルの定義</h1><blockquote>Claude CodeなどのLLMは「同一ユーザー権限を持つSuper Hacker」と仮定する。実行環境に存在すれば、原理的になんでもできる。</blockquote>これは極端な仮定ですが、安全側に倒した脅威モデルとしては妥当です。脅威は大きく2つに分けられます。<h3 id="h92e81d2632">脅威1：ローカルに保存されたクレデンシャルを読み出す</h3>同じユーザーで動いているプロセスから、以下のようなことが原理的に可能です。<ul><li>環境変数の読み取り（<code>/proc/&lt;pid&gt;/environ</code>）</li><li>シェル履歴の参照</li><li><code>ps aux</code> によるプロセス引数の盗み見</li><li>1Password CLIのセッションが解除済みであれば <code>op read</code> での取得</li></ul><h3 id="hc410c635d1">脅威2：クラウドから読み出す</h3>ローカルにクレデンシャルが存在しなくても、クラウドCLIの認証情報がローカルに残っていれば、本番環境のクレデンシャルを取得・操作できます。 人間のエンジニアが本番環境を操作するとき、それは意識的な判断の結果です。しかしエージェントが自律的にタスクをこなす時代になると、同じ操作がタスク完了の過程で副作用として実行される可能性があります。「ローカルに置いていないから安全」だけでは不十分な理由がここにあります。<h2 id="hcf83e1357e"> </h2><h1 id="he963550fa9"> 結論1：ローカルには本番環境のクレデンシャルを保存しない</h1>本番クレデンシャルをローカルに置かない。それだけでClaude Codeは物理的に触れなくなります。インフラのapplyやdeployはCIに完全に委ねて、クレデンシャルはCIのクレデンシャル管理にのみ存在させる。クレデンシャルが存在しなければ、Claude Codeが何をしようと触れるものがない。制限するより、存在を消す方が強い。 <h1 id="he5274ad2e0">結論2：ローカルから本番環境のクレデンシャルをReadできないようにする</h1>「安全な場所に保存した」だけでは不十分で、「ローカルからReadできない」設計になっているかを確認する必要があります。 ここが最も見落とされがちな観点です。 例えばAWS Secrets Managerに本番のクレデンシャルを保存していても、クラウドCLIの認証情報がローカルに残っていれば、ローカルから普通に取得できます。Claude Codeも同様です。<pre><code># 認証情報があれば実行できてしまう
aws secretsmanager get-secret-value --secret-id prod/api-key</code></pre>これを根本的に解決するには、Claude Codeを隔離された環境で動かし、そこに渡す認証情報を開発用のみに絞ることが筋です。開発者のフル権限の認証情報はホスト側に置いたまま、Claude Codeの環境には渡さない。<pre><code>ホスト（開発者）
├── 本番クレデンシャル → CIのみ（結論1）
├── フル権限のクラウド認証情報 → ホストのみ、Claude Code環境に渡さない
└── Claude Code環境（Docker等）
 └── 開発用クレデンシャルのみ（結論3）</code></pre>この構造が完成したとき、Claude Code環境の中で<code>--dangerously-skip-permissions</code>を打っても、触れられる本番クレデンシャルがそもそも存在しない状態になります。 <h1 id="h4b1d20dd0b">結論3：開発用のクレデンシャルは流出しても被害が少ないようにする</h1>結論1・2を徹底すると、ローカルに残るのは開発用のクレデンシャルだけになります。これをゼロにするにはClaude Codeを開発環境から完全に排除するしかなく、現実的ではありません。セキュリティと利便性のバランスを見極めることが重要です。 開発用クレデンシャルが漏れても本番データへのアクセス権はないため、情報漏洩の観点でのダメージはありません。残るリスクはAPIを悪用されてコストが跳ね上がることで、以下の対策でカバーします。<ul><li>開発環境キーの権限を最小にする（サンドボックス・読み取り専用等）</li><li>請求のリミットを設定してアラートを出す</li><li>サービスごとにキーを分けて影響範囲を限定する</li></ul><h2 id="hcf83e1357e"> </h2><h1 id="hf7b12f2d8c">最後に：これは過渡期の設計である</h1>この設計を考えながら、ふと気づいたことがあります。 人間のエンジニアが本番のクレデンシャルにアクセスできるのは、雇用契約・法的責任・社会的評判という信頼のインフラがあるからです。悪用すれば訴えられ、クビになり、業界で生きていけなくなる。そのブレーキが機能しています。LLMに今それがないのは、技術的な問題というより、信頼のインフラがまだ整備されていないという話です。 Claude自身のpermission設定を細かく調整するアプローチもありますが、突き詰めると「Anthropicをどこまで信じるか」という話になります。それは技術的に検証できる問題ではなく、信頼の問題です。この記事で提案した設計は、その信頼に依存しない構造を作ることを目指しています。 Anthropicが「このモデルはこういう行動をしない」という保証が法的・社会的に意味を持つようになったとき、LLMにより多くの権限が委譲されていくでしょう。今やっていることは、その信頼のインフラが整備されるまでの、普通の運用判断に過ぎないのかもしれません。 <h1 id="hcf83e1357e"> </h1>

Claude Codeを「Super Hacker」と仮定したインフラセキュリティ設計

Goの標準test/testingモジュールにはテスト結果に色をつける方法が提供されていません。 sedコマンドで testコマンドの結果の特定の文字列に色をつけることができます。 Goのテストに失敗するとexits code 1を返却します。 sedの色付けの部分が成功するとテストが失敗した場合でもexits code 0を返却します。 GithubActionsではコマンドの実行ステータス(exits code)を評価し、成功(0)でない場合はPull Requestをマージできないように設定できます。 <a href="https://docs.github.com/ja/actions/creating-actions/setting-exit-codes-for-actions" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/creating-actions/setting-exit-codes-for-actions</a> <a href="https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule</a> sedコマンドで色をつけた場合、 go testのexits codeを返却する必要があります。 bashではPIPESTAUS変数から任意の結果にアクセスできます。 この結果を返すbashスクリプトを実行することで、Goのテスト結果をsedコマンドで色付きで表示しつつexits codeを返却できます。 <pre><code>#!/bin/bash		
set -o pipefail
go test -v ./... \
 | sed 's/PASS/'"$(printf "\033[32mPASS\033[0m")"'/g' \
 | sed 's/FAIL/'"$(printf "\033[31mFAIL\033[0m")"'/g'
exit ${PIPESTATUS[0]}</code></pre>

Goのテスト結果をsedコマンドで色付きで表示しつつexits codeを返却する方法

以前から名前は知っていたけど触ったことのなかったgRPCを触ってみたので備忘として残しておきます。 Zennの本を読みました。これさえ読めば大体概要は掴めると思います。 <a href="https://zenn.dev/hsaki/books/golang-grpc-starting" target="_blank" rel="noopener noreferrer">https://zenn.dev/hsaki/books/golang-grpc-starting</a> 個人的なポイントは以下の通り<ul><li>クライアントストリーミング、サーバーストリーミング、双方向通信を手軽に実装できる。</li><li>protoファイルを書いてprotocコマンドを実行するとProcedureを生成してくれる。</li><li>ストリーミング、通信の基盤となるロジックは生成されるので、ビジネスロジックを書くことに集中できる。</li></ul> Zennの本を読み終わって自分でも何か作ってみたいと思ったので、ChatGPTに題材を考えてもらいました。 <img src="https://images.microcms-assets.io/assets/81f983243e9f4cfc9a2c552fe620be13/2419f7721bc14da9b1e2a9206a80b8b9/Screenshot%202024-02-05%20at%2018.11.48.png?w=560&amp;h=246" alt=""> なかなか面白そう、、 というわけで、ログをクライアントストリーミングでサーバーに送信するコードを書いてみました。 リポジトリ -&gt; <a href="https://github.com/sano11o1/snack_logger/" target="_blank" rel="noopener noreferrer">https://github.com/sano11o1/snack_logger/</a> （Zennのコードちょっといじっただけじゃない？？ってツッコミがありそう。それはそう） おおまかな処理を書くと以下のようになる。<ul><li>echoサーバーを起動する</li><li>echoサーバーがリクエストごとにストリームを作成、Handlerが吐き出すログをクライアントストリーミングし、サーバーに送信する</li><li>echoサーバーがレスポンスを返す直前にストリームを閉じ、それまでログを受け付けていたサーバーがechoサーバーにレスポンスを返し、echoサーバーがレスポンスを返す</li></ul> <img src="https://images.microcms-assets.io/assets/81f983243e9f4cfc9a2c552fe620be13/530c929ee23946d79e520122426a47e7/Videotogif%20(1).gif?w=1200&amp;h=600" alt=""> (左がechoサーバー、右がログを受け取るサーバー) 一点問題があって、ログを送信する際にechoサーバー側では以下のように明示的にログ出力のためのメソッドを呼ぶ必要があり大変不便である。 <pre><code>if err := Info(fmt.Sprintf("Hello, World! %d", i), stream); err != nil {
 return err
 }</code></pre> この問題を解決するにはechoサーバーの標準出力を監視する何らかの仕組みが必要になります。 例えばAWS Lambdaで吐き出したログは自動的にCloudWatchに転送されるけど、どういった仕組みになっているんでしょうかね、、 これはもはやgRPC関係ないですが面白そうなのでいつか試してみたいです。 それでは、また

gRPCを使ってクライアントストリーミングを試してみる

<a href="https://brandur.org/idempotency-keys" target="_blank" rel="noopener noreferrer">https://brandur.org/idempotency-keys</a> を読んでいて以下の疑問が湧いた。<ul><li>そもそもWebAPIにおける冪等性の正確な定義はなんでしたっけ？</li><li>どのような時に冪等性が求められるか?</li></ul>以前考えた記憶があるが忘れているので文章に残しておく。 <h1 id="h36baca63f6">冪等性の正確な定義</h1><a href="https://developer.mozilla.org/ja/docs/Glossary/Idempotent" target="_blank" rel="noopener noreferrer">https://developer.mozilla.org/ja/docs/Glossary/Idempotent</a> では以下の通り<blockquote>ある HTTP メソッドがべき等であるとは、サーバーが同じ状況にあるとき、特定のリクエストに対して何回でも続けて同じ効果が起こることをいいます。このことは、べき等なメソッドでは (統計を取る際のことを除いて) 副作用が生じるはずではないと言うこともできます 。</blockquote>「何回でも続けて同じ効果が起こる」= 同じリクエストを複数回行っても効果が起きるのは1度だけであるということ。 ここでいう効果とは、データベースに保存しているレコードの状態の変化やサーバーがリクエストする別のAPIによる変化が含まれる。 ちなみにレスポンスコードは変わっても良いとのこと。<blockquote>べき等であるためには、サーバーにおける裏側の実際の状態だけが考慮されるので、返される状態コードはリクエストごとに異なる場合があります。</blockquote>このAPIが冪等か？を考えるには、そのAPIを同じリクエストで複数回叩いた時の効果に注目する。 ここからは自分の考えだが、「同じリクエストを複数回行っても効果が起きるのは1度だけ」であるなら、1回は確実に効果を起こす必要があり、安全にリトライできるはずである。 もしあるAPIを1度実行した時に500が返ってきて、何度リトライしても500を返すとする。 リクエストが正常であるのに、500を返すならこのAPIは一度も効果を発揮していないことになるため、冪等の厳密な定義からは外れる。 とはいえ、現実問題としてサーバーに保存されているレコードの状態や、依存する外部のAPIの状態によっては一度も効果を発揮しないAPIも存在する。 できる限り安全にリトライ可能なAPIを構築したい。 <h1 id="he8f63a27ba">冪等性を担保した方が良いパターン</h1>同じリクエストを複数回行っても効果が起きるのは1度だけにしたい具体的なパターンを挙げる。<h2 id="h2be645e81c">SNSのいいね機能</h2>いいねをつけられるのは投稿, ユーザー単位で1つまでであるため。 複数回リクエストを送った時、1ユーザーが複数のいいねを同じ投稿に作成できてしまうのはまずい。<h2 id="hcf66a64548">決済を実行するAPI</h2>このAPIを実行すると銀行口座から引き落とし決済を実行する。 リクエストに成功、決済が完了したが、クライアント側のネットワークの不調によりリトライすることになる。 リトライのリクエストは成功した。この時引き落とし(APIの効果)は何回実行されるだろうか？ 冪等性が担保されていれば1回。されていなければリクエスト回数分の2回実行される。 <h1 id="hcd0c3c1749">冪等性を担保しなくても良いパターン</h1>リクエスト毎にリソースを操作したい/作成しても困らない場合。 GitHubのIssuesの作成はこれに該当する。<a href="https://auth0.com/docs/api/management/v2/users/post-users" target="_blank" rel="noopener noreferrer">https://auth0.com/docs/api/management/v2/users/post-users</a> もし誤って同じ内容のIssueを2つ作成しても後から消せば大きな問題には繋がらないはず。 <h1 id="hced4a05afe">どのHTTPメソッドを使うか?</h1>教科書的な回答は冪等なAPIはPUTを使うことになる。 POSTのAPIでも「同じリクエストを複数回行っても効果が起きるのは1度だけ」な実装にすることは可能である(もちろんPUTの場合も同じ実装をすることになる) 例えばAuth0にユーザーを作成するAPIのHTTPメソッドはPOSTだが、再度同じリクエストをすると409を返す。 <a href="https://auth0.com/docs/api/management/v2/users/post-users" target="_blank" rel="noopener noreferrer">https://auth0.com/docs/api/management/v2/users/post-users</a> 結局のところ「同じリクエストを複数回行っても効果が起きるのは1度だけ」と制御するかは実装次第である。 APIのインタフェースから冪等であることを表現できるので、冪等なAPIにはやはりPUTを使った方が良いと考えている。 <h1 id="ha214098e44">まとめ</h1>APIの利用者のユースケース、システム全体への影響度によって冪等性を担保するべきかが決まる。 APIを設計の初期段階で冪等であるべきか？を考えていきたい。

WebAPIの冪等性についておさらい

<a href="https://brandur.org/idempotency-keys" target="_blank" rel="noopener noreferrer">https://brandur.org/idempotency-keys</a> を読んだのでその感想。 Idempotency KeysとはAPIのリクエストを冪等に処理するための仕組み。 概念だけ知りたい人は以下の記事がおすすめです。<ul><li><a href="https://stripe.com/blog/idempotency" target="_blank" rel="noopener noreferrer">https://stripe.com/blog/idempotency</a></li><li><a href="https://multithreaded.stitchfix.com/blog/2017/06/26/patterns-of-soa-idempotency-key/" target="_blank" rel="noopener noreferrer">https://multithreaded.stitchfix.com/blog/2017/06/26/patterns-of-soa-idempotency-key/</a></li></ul> <a style="background-color:#ffffff" href="https://brandur.org/idempotency-keys" target="_blank" rel="noopener noreferrer">https://brandur.org/idempotency-keys</a> ではIdempotency Keysをどのように実装するか具体的なコード、テーブル構成とともに解説している。 <img src="https://images.microcms-assets.io/assets/81f983243e9f4cfc9a2c552fe620be13/0926320067bd49c49ecda1a4634e5014/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-11-26%200.32.30.png?w=1400&amp;h=788" alt=""> 以下メモ<ul><li>WebAPIはいつどんな理由で失敗するか分からないため、決済のようなAPIは副作用が一度しか起こらないことを保証するべき。</li><li>Idempotency Keysを実装することで安全にリトライできるAPIを実装する。</li><li>APIの処理を複数のRDBMSのトランザクション(記事の中ではAtomic phaseと表現されている)に分割する。</li><li>Idempotency Keysの状態を各トランザクションで変更することで、リトライする際にどこまで進んでいるかを判別し処理を続行できる。</li><li>実装するAPI内で叩くAPI(記事の中ではStripe API)がIdempotencyなAPIでない場合は注意が必要<ul><li>1. クライアントがIdempotency Key「A」を使ってリクエスト</li><li>2. サーバーは外部のAPIにリクエストし、外部サーバーは曖昧なエラーをサーバーに返す</li><li>3. サーバーはクライアントにエラーを返す</li><li>4. クライアントがリトライする</li><li>5. サーバーは外部のAPIにリクエストし成功する</li></ul></li><li>もし上記の2でレスポンス上は失敗していても内部的に処理が成功していた場合、2と5で2回処理が実行される。そのため2のエラーが返ってきた時点で、Idempotency Key「A」を使ったリクエストは今後受け付けないようにするべき</li></ul> 今までなんとなく理解していたことがまとまった。冪等性が求められるAPI(決済など)を実装する時は参考にしたい。

Implementing Stripe-like Idempotency Keys in Postgres を読んだ

今まで関わってきたGoのプロジェクトでは構造体のフィールドに独自の型を定義していなかった。 <pre><code>type User struct {
 ID string
}

type Post struct {
 ID string
}</code></pre> 振り返るとこれはバグの温床になるので、面倒くさがらずに型をつけた方がよかったかなと考えている。 Goでは関数が複数の値を返却できる。複数の値の型が同じだった場合、その値がどのような値か？を関数を使う側に教える必要がある。<pre><code>// どっちがuserID, postIDかわからない
func f() (string, string, error) {
}

// ので名前をつける
func f() (userID string, postID string, error) {
}</code></pre> 上記の実装にも問題がある。関数を実装した人がuserIDとpostIDの順番を間違える可能性がある。<pre><code>func f() (userID string, postID string, error) {
 return postID, userID, err
}</code></pre> 最初から型をつけておけばシンプルになる。<pre><code>type UserID string
type PostD string

type User struct {
 ID UserID
}

type Post struct {
 ID PostID
}

func f() (UserID, PostID, error){
}</code></pre> 型の恩恵を最大限受けて堅牢なコードを書きたいですね。

Golang 構造体のフィールドには独自の型を定義したいね

<h1 id="h8d027c8ed3">はじめに</h1>Sentryではどのユーザーでエラーが発生したのかを送信することができる。 echoを使ってWebサーバーを立ち上げる構成の場合、Sentryが提供している<a href="https://github.com/getsentry/sentry-go/tree/master/echo" target="_blank" rel="noopener noreferrer">sentry-go/echo</a> を使った方が、安全かつ手軽にユーザー情報をSentryに送信できることがわかったので、忘れないようにメモしておく <h1 id="h75a6ced616">Hub, Scopeについて　</h1>普段Sentryに通知するメソッドを呼び出すだけでは意識することはないが、SentryにはHubとScopeという概念がある。<ul><li>Hub: SentryとSentrySDKを繋ぐモノ。Sentry.Initすると作られる</li><li>Scope: Hubを介して送られる情報を入れておくモノ</li></ul> https://docs.sentry.io/platforms/go/enriching-events/scopes に詳細な説明がある <h1 id="h9ea17406de">ユーザー情報をSentryに送信する際の注意点</h1><a href="https://docs.sentry.io/platforms/go/enriching-events/identify-user/" target="_blank" rel="noopener noreferrer">ConfigureScope, SetUserメソッド</a> を使うとユーザー情報を送信できる。 <pre><code>sentry.ConfigureScope(func(scope *sentry.Scope) {
	scope.SetUser(sentry.User{Email: "sano11o1@example.com"})
})</code></pre> <a style="background-color:#ffffff" href="https://docs.sentry.io/platforms/go/concurrency/?original_referrer=https%3A%2F%2Fwww.google.com%2F" target="_blank" rel="noopener noreferrer">concurrency</a> に記載があるが、複数の非同期処理で1つのHubに対してScopeを設定する場合、競合が発生する可能性がある。 競合が発生すると、本来エラーが起きたはずのユーザーとは異なるユーザー情報が送信されるので、非常にまずいことになる。 echoは非同期でリクエストを捌くので、例えば以下のようなコードではユーザー情報の競合が発生しうる。 <pre><code>import (
 "fmt"
 "net/http"
 "github.com/getsentry/sentry-go"
 "github.com/labstack/echo/v4"
 "github.com/labstack/echo/v4/middleware"
)

if err := sentry.Init(sentry.ClientOptions{
 Dsn: "",
 TracesSampleRate: 1.0,
}); err != nil {
 fmt.Printf("Sentry initialization failed: %v\n", err)
}


app := echo.New()

app.Use(middleware.Logger()) // JWTからユーザーを特定し、contextにuser_idを格納するMiddlewareと仮定

app.GET("/", func(ctx echo.Context) error {
 // ハンドラの様々な処理 
 // エラーが発生したらユーザー情報と共にSentryに送信
 if err != nil {
 sentry.ConfigureScope(func(scope *sentry.Scope) {
 scope.SetUser(
 sentry.User{
 ID: c.Value(UserIDKey).(*model.UserID),
 }
 )
 })
 sentry.CaptureException(err)
 return err
 }
 return ctx.String(http.StatusOK, "Hello, World!")
})

app.Logger.Fatal(app.Start(":3000"))</code></pre><h1 id="h7ec8c26d0e"> ユーザー情報の競合を防ぐ</h1><a style="background-color:#ffffff" href="https://docs.sentry.io/platforms/go/concurrency/?original_referrer=https%3A%2F%2Fwww.google.com%2F" target="_blank" rel="noopener noreferrer">concurrency</a> にもあるように、リクエスト毎にHubを複製するのが良い。 <a href="https://github.com/getsentry/sentry-go/tree/master/echo" target="_blank" rel="noopener noreferrer">sentry-go/echo</a> が提供するMiddlewareは内部的にHubの複製をやってくれる。 具体的には<a href="https://github.com/getsentry/sentry-go/blob/master/echo/sentryecho.go#L49-L54" target="_blank" rel="noopener noreferrer">以下のコード</a> でHubを複製していることがわかる。<pre><code>func (h *handler) handle(next echo.HandlerFunc) echo.HandlerFunc {
　　return func(ctx echo.Context) error {
　　　　　hub := sentry.GetHubFromContext(ctx.Request().Context())
	　　if hub == nil {
	　　　　　hub = sentry.CurrentHub().Clone()
	　　　}
 　　//　後続の処理
}</code></pre> Middlewareはリクエスト毎に呼ばれるので、複数のリクエストが共通のHubを変更することはない。 Hubはecho.Contextに格納されるので、エラーを通知する処理ではecho.ContextからHubを取り出すことになる。 最終的には以下のようなコードになる。<pre><code>sentryHub := sentryecho.GetHubFromContext(c)
sentryHub.ConfigureScope(func(scope *sentry.Scope) {
　　scope.SetUser(sentry.User{
　　　　ID:　c.Value(UserIDKey).(*model.UserID),
　　})
})
sentryHub.CaptureException(err)</code></pre>

echoサーバーからSentryにエラー通知する時はsentry-go/echoが便利

<h1 id="h8d027c8ed3">はじめに</h1>echoを使ってAPIを開発している際に、1リクエストに対してHTTPErrorHandlerがなぜか2回呼ばれる挙動に遭遇したので、その原因と対策について書き留めておく。 <h1 id="hf8de78968f">HTTPErrorHandler の使い方</h1>ハンドラがerrorを返したとき呼ぶメソッドを定義できる。 エラーをログに出力したり、Sentry等のエラートラッキングのシステムにエラーを送るコードを仕込めたりする。 <a href="https://echo.labstack.com/docs/error-handling#custom-http-error-handler" target="_blank" rel="noopener noreferrer">参考</a> <pre><code>e.Use(xxx.HogeMiddleware())

e.Use(func(next echo.HandlerFunc) echo.HandlerFunc {
 return func(c echo.Context) error {
 return errors.New("エラーです")
 }
})

func customHTTPErrorHandler(err error, c echo.Context) {
 c.Logger().Error(err)
 sentry.CaptureException(err)
}

e.HTTPErrorHandler = customHTTPErrorHandler</code></pre> 上記のコードでログが2回出力され、Sentryに2回エラーが送信されていた。 期待している動作はログに1回出力、Sentryに1回送信することなので、どこかで余分にHTTPErrorHandlerが呼ばれていることになる。 <h1 id="h9c1f22bd6d">原因</h1>HogeMiddlewareの中でc.Error()メソッドを呼び出し、HTTPErrorHandlerが呼ばれていた。 echoのMiddlewareではハンドラ側でerrorが発生していたら、c.Errorを呼ぶ構成になっていることが多い。 <pre><code>func HogeMiddleware(opts ...Option) echo.MiddlewareFunc {
 return func(next echo.HandlerFunc) echo.HandlerFunc {
 return func(c echo.Context) error {
 if err := next(c); err != nil { // 次のMiddlewareもしくはハンドラの呼び出し
 c.Error(err)
 return err
 }
 // HogeMiddleware特有の処理
 }
 }
}</code></pre> <a href="https://github.com/labstack/echo/blob/master/context.go#L172-L177" target="_blank" rel="noopener noreferrer">Errorメソッド</a> はHTTPErrorHandlerを呼び出す。 副作用としてHTTPレスポンスをクライアントに送信(コミット)する。 <pre><code>// Error invokes the registered global HTTP error handler. Generally used by middleware.
// A side-effect of calling global error handler is that now Response has been committed (sent to the client) and
// middlewares up in chain can not change Response status code or Response body anymore.
// Avoid using this method in handlers as no middleware will be able to effectively handle errors after that.
Error(err error)</code></pre> <h1 id="hb109fbdd18">対策</h1>Commit済みの場合は、Response().Committedの値がTrueに更新される。 Response().Committedの値を見て、Commit済みであれば早期Returnすることで重複呼び出しを防げる <pre><code>func customHTTPErrorHandler(err error, c echo.Context) {
 if context.Response().Committed {
 return
 }
 c.Logger().Error(err)
 sentry.CaptureException(err)
}</code></pre> 実は<a href="https://github.com/labstack/echo/blob/master/echo.go#L419-L423" target="_blank" rel="noopener noreferrer">デフォルトのHTTPErrorHandler</a> ではCommit済みであれば早期Returnする実装になっている <pre><code>func (e *Echo) DefaultHTTPErrorHandler(err error, c Context) {
	if c.Response().Committed {
		return
	}
}</code></pre>

echoのHTTPErrorHandlerが重複して呼ばれる挙動の対策

<h1 id="h8d027c8ed3">はじめに</h1>ビジネスロジック層の中でトランザクションを使いたい、でもビジネスロジック層にデータベース,トランザクション等の特定の永続化層のコードを書きたくない、そんなことはないでしょうか。 トランザクションを抽象化してビジネスロジック層の中で扱うコードを、Golang, ORマッパーのGORMを使って紹介します。 サンプルコードは以下のリポジトリに置いてます。 <a href="https://github.com/sano11o1/go-transaction" target="_blank" rel="noopener noreferrer">https://github.com/sano11o1/go-transaction</a> 本投稿は <a style="background-color:#ffffff" href="https://blog.devgenius.io/go-golang-clean-architecture-repositories-vs-transactions-9b3b7c953463" target="_blank" rel="noopener noreferrer">Go (Golang): Clean Architecture &amp; Repositories vs Transactions</a> の実装を参考にしています。 <h1 id="h26ce8905f1"> 想定するファイル構成</h1>ビジネスロジックを置く層をUsecase層と呼びビジネスロジックはここにまとめることとします。 Usecase層はプロジェクトによってはService層とも呼ばれていたりします。 Service層はApplicationService、DomainServiceに分かれている実装もありますが、説明をシンプルにするため、今回はUsecase層とします。<pre><code>├── entity
│&nbsp; &nbsp;└── user.go
├── go.mod
├── go.sum
├── main.go
├── repository
│&nbsp; &nbsp;└── user_repository.go
└── usecase
&nbsp; &nbsp; └── register_user_usecase.go</code></pre> Repository層はInterfaceとImplementに別れています。Implementで実際にデータベースにアクセスする処理を書きます。<pre><code>package repository

# repository/user_repository.go

import (
 "github.com/sano11o1/go-transaction/entity"
 "gorm.io/gorm"
)

type IUserRepository interface {
 AddUser(entity.User) error
}

type UserRepositoryImpl struct {
 db *gorm.DB
}

func NewUserRepositoryImpl(db *gorm.DB) IUserRepository {
 return &amp;UserRepositoryImpl{
 db: db,
 }
}

func (r *UserRepositoryImpl) AddUser(user entity.User) error {
 return r.db.Create(&amp;user).Error
}</code></pre> Usecase層の中でrepsitory層のInterfaceに定義されたメソッドを呼び出すことで、Usecaseが特定の永続化層を意識する必要しなくても良い構成になっています。<pre><code>package usecase

# usecase/register_user_usecase.go

import (
 "time"
 "github.com/google/uuid"
 "github.com/sano11o1/go-transaction/entity"
 "github.com/sano11o1/go-transaction/repository"
)

type RegisterUserUsecase struct {
 baseRepository repository.IBaseRepository
 userRepository repository.IUserRepository
}

func NewRegisterUserUsecase(userRepository repository.IUserRepository) *RegisterUserUsecase {
 return &amp;RegisterUserUsecase{
 userRepository: userRepository,
 }
}

func (u *RegisterUserUsecase) Execute(user entity.User) error {
 if err := u.userRepository.AddUser(entity.User{
 Name: "sano11o1",
 }); err != nil {
 return err
 }
 return nil
)</code></pre> データの保存先がデータベースからインメモリに変わっても、Usecase層に変更を加えなくても良いのです。 最後にmain.goです。データベースの構造体、RepositryのImplementを外から注入します。<pre><code>package main


import (
 "fmt"


 "github.com/sano11o1/go-transaction/entity"
 "github.com/sano11o1/go-transaction/repository"
 "github.com/sano11o1/go-transaction/usecase"
 "gorm.io/driver/postgres"
 "gorm.io/gorm"
)


func main() {
 db, err := initDB()
 if err != nil {
 panic(err)
 }
 userRepository := repository.NewUserRepositoryImpl(db)
 registerUserUsecase := usecase.NewRegisterUserUsecase(userRepository)
 newUser := entity.User{
 Name: "sano11o1",
 }
 if err := registerUserUsecase.Execute(newUser); err != nil {
 fmt.Println("failed to register user", err.Error())
 panic(err)
 }
}


func initDB() (*gorm.DB, error) {
 host := "127.0.0.1"
 port := "5431"
 user := "postgres"
 dbName := "postgres"
 password := "passw0rd"
 dsn := fmt.Sprintf("host=%s user=%s password=%s dbname=%s port=%s sslmode=disable TimeZone=Asia/Tokyo", host, user, password, dbName, port)
 var err error
 db, err := gorm.Open(postgres.Open(dsn))
 if err != nil {
 fmt.Println("failed to connect database", err.Error())
 return nil, err
 }
 return db, nil
}</code></pre> まあ、よくある構成でしょうか。 <h3 id="hcf83e1357e"> </h3><h1 id="had6ddb8f1d">この記事で書かないこと</h1>そもそもUsecase層にトランザクションを扱わず、Repository層に書けば良いのではないか？という意見もあると思います。 私自身どの層でトランザクションで扱うべきかさまざまな実装、本を読んで勉強中です。 自分の中でどこに置くべきかは結論は出ていないため、どこでトランザクションを扱うべきかについては書きません。 もしもビジネスロジックの中でトランザクションを扱うなら、どのように実装するかのサンプルとして参考にしていただけたらと思います。 <h1 id="hac57b6c780">トランザクションをUsecase層で扱う例</h1>ユーザーを作成するUsecaseで、データベースと外部サービスの両方にユーザーを保存するケースを例に考えてみます。 最終的に、自社データベースと外部サービスの両方にデータがあるか、もしくは両方ともにデータがないことのどちらかに定まることを期待します。 APIを叩いた後にInsertする、DBにInsertした後にAPIを叩く、2通りの実装パターンが考えられます。 厳密に両方にデータが作られることを保証したい場合、前者は不適格でしょう。<pre><code>func (u *RegisterUserUsecase) Execute(user entity.User) error {
 // 外部サービスにUserを作成
 req, err := http.NewRequest("POST", "https://example.com/user", nil)
 if err != nil {
 return err
 }
 req.Header.Set("Content-Type", "application/json")
 client := new(http.Client)
 _, err = client.Do(req)
 if err != nil {
 return err
 }

 // DBにUserを作成
 if err := u.userRepository.AddUser(entity.User{
 Name: "sano11o1",
 }); err != nil {
 // Insertに失敗した場合外部サービスにのみデータが存在する
 return err
 }
 return nil
}</code></pre> レコード作成が何らかの理由で失敗した場合、外部サービスにのみデータが存在することになります。 外部サービスにユーザー作成を取り消すエンドポイントが実装されているかもしれません。 取り消しのリクエストを送信する実装も考えられますが、この通信が成功する保証はありません。 サービスにどれほどのデータの厳密さを求めるかによりますが、データの整合性を求めるなら順番を入れ替えるべきです。<pre><code>func (u *RegisterUserUsecase) Execute(user entity.User) error {
 // トランザクションの中で行いたい処理
 {
 // DBにUserを作成
 if err := u.userRepository.AddUser(entity.User{
 Name: "sano11o1",
 }); err != nil {
 return err
 }
 // 外部サービスにUserを作成
 req, err := http.NewRequest("POST", "https://example.com/user", nil)
 if err != nil {
 return err
 }
 req.Header.Set("Content-Type", "application/json")
 client := new(http.Client)
 _, err = client.Do(req)
 if err != nil {
 // 外部サービスとの通信が失敗した場合ロールバックする
 return err
 }
 return nil
 }</code></pre> もしレコードのInsertに失敗した場合、APIへのPOSTは実行されません。 APIへのPOSTが失敗した場合、ロールバックすることでレコード作成を取り消します。<h3 id="hcf83e1357e"> </h3><h1 id="h3e0add6b10">トランザクションを抽象化する</h1>本題です。 Usecase層の中でトランザクション、データベースという永続化層の具象型を意識したコードは書きたくないですよね。 トランザクションを扱うコードをRepository層のImplementに実装するコードを紹介します。 <pre><code>package usecase

# usecase/register_user_usecase.go

import (
 "net/http"

 "github.com/sano11o1/go-transaction/entity"
 "github.com/sano11o1/go-transaction/repository"
)

type RegisterUserUsecase struct {
 baseRepository repository.IBaseRepository
}

func NewRegisterUserUsecase(baseRepository repository.IBaseRepository) *RegisterUserUsecase {
 return &amp;RegisterUserUsecase{
 baseRepository: baseRepository,
 }
}


func (u *RegisterUserUsecase) Execute(user entity.User) error {
 atomicBlock := func(r repository.IBaseRepository) error {
 userRepo := r.GetUserRepository()
 if err := userRepo.AddUser(user); err != nil {
 return err
 }
 // 外部サービスにUserを作成
 req, err := http.NewRequest("POST", "https://example.com/user", nil)
 if err != nil {
 return err
 }
 req.Header.Set("Content-Type", "application/json")
 client := new(http.Client)
 _, err = client.Do(req)
 if err != nil {
 // 外部サービスとの通信が失敗した場合ロールバックする
 return err
 }
 return nil
 }
 err := u.baseRepository.Atmoic(atomicBlock)
 return err
}</code></pre> <pre><code>package repository

# repository/base_repository.go

import (
 "gorm.io/gorm"
)

type IBaseRepository interface {
 Atmoic(fn func(IBaseRepository) error) error
 GetUserRepository() IUserRepository
}

type BaseRepositoryImpl struct {
 db *gorm.DB
}

func NewBaseRepositoryImpl(db *gorm.DB) IBaseRepository {
 return &amp;BaseRepositoryImpl{
 db: db,
 }
}

func (r *BaseRepositoryImpl) Atmoic(fn func(IBaseRepository) error) error {
 // r.dbするにはmain.goでdbを初期化しBaseRepositoryImplを生成する際に渡す必要がある
 return r.db.Transaction(func(tx *gorm.DB) error {
 return fn(NewBaseRepositoryImpl(tx))
 })
}

func (r *BaseRepositoryImpl) GetUserRepository() IUserRepository {
 // NewUserRepositoryImplの引数にはBaseRepositoryImplのDBを渡す
 return NewUserRepositoryImpl(r.db)
}</code></pre> 新たにbase_repository.goを定義し、トランザクションで実行する関数を受け取る<code>Atomic</code>メソッドを定義します。<pre><code>func (r *BaseRepositoryImpl) Atmoic(fn func(IBaseRepository) error) error {
}</code></pre> <code>Atomic</code>メソッドの引数には、トランザクションで実行する処理をまとめた関数を渡します。 変数<code>atomicBlock</code>に代入した関数は引数に<code>IBaseRepositoy</code>を受け取り、<code>error</code>を返す関数です。<pre><code> atomicBlock := func(r repository.IBaseRepository) error {
 userRepo := r.GetUserRepository()
 if err := userRepo.AddUser(user); err != nil {
 return err
 }
 // 外部サービスにUserを作成
 }
 err := u.baseRepository.Atmoic(atomicBlock)</code></pre> あくまで<code>atomicBlock</code>は関数そのものの代入であり実行結果を代入しているわけではありません。 そのため引数<code>r</code>の実態は関数を定義した段階では確定しないことに注意してください。 <code>Atomic</code>メソッドの実装をみていきます。<pre><code>func (r *BaseRepositoryImpl) Atmoic(fn func(IBaseRepository) error) error {
 // r.dbするにはmain.goでdbを初期化しBaseRepositoryImplを生成する際に渡す必要がある
 return r.db.Transaction(func(tx *gorm.DB) error {
 return fn(NewBaseRepositoryImpl(tx))
 })
}</code></pre> 引数には、<code>fn func(r repositoy.IBaseRepository) error</code> を受け取ります。 受け取った関数<code>fn</code>を呼び出しています。呼び出している箇所に注目してください。 GORMではトランザクションで実行したい処理を<code>func(tx *gorm/DB) error</code>関数のブロックに記述、<code>db.Transaction</code>メソッドの引数に渡します。 <code>func(tx *gorm/DB) error</code>関数が<code>error</code>を返した場合、ロールバックします。 参考: <a href="unsafe:トランザクション">トランザクション</a> つまり、変数<code>AtomicBlock</code>に代入した関数が<code>error</code>を返すとロールバックされるということです。 引数には<code>IBaseRepository</code>の実態である<code>BaseRepositryImpl</code>を生成し渡しています。 <code>BaseRepositryImpl</code>の生成時に<code>tx</code>を渡しています。<code>tx</code>は<code>BaseRepositryImpl</code>構造体のフィールド<code>db</code>にセットされます。 <code>tx</code>は<code>Transaction</code>メソッドを実行した時に確定する値で、同じ<code>tx</code>に対しメソッドを実行することで、共通のトランザクションを共有することができます。 <code>Atomic</code>メソッドの引数に戻って<code>IBaseRepository</code>の実態である<code>BaseRepositryImpl</code>がどのように使われるか確認します。<pre><code>atomicBlock := func(r repository.IBaseRepository) error {
 userRepo := r.GetUserRepository()
 if err := userRepo.AddUser(user); err != nil {
 return err
 }</code></pre> <code>r</code>の実態は<code>BaseRepositryImpl</code>です。<code>r</code>に対して<code>GetUserRepository</code>を呼び出します。<pre><code>func (r *BaseRepositoryImpl) GetUserRepository() IUserRepository {
 // NewUserRepositoryImplの引数にはBaseRepositoryImplのDBを渡す
 return NewUserRepositoryImpl(r.db)
}</code></pre>すると、構造体<code>BaseRepositryImpl</code>の<code>db</code>フィールドの値を元に、<code>UserRepositoryImpl</code>が作成されます。 これにより<code>db</code>フィールドに<code>tx</code>を持ちます。 <code>AddUser</code>メソッド内部では<code>r.db</code>が<code>tx</code>となるため、同一のトランザクションで<code>Insert</code>が実行されることになります。<pre><code>func (r *UserRepositoryImpl) AddUser(user entity.User) error {
 return r.db.Create(&amp;user).Error
}</code></pre> 最後に<code>main.go</code>を紹介します。<pre><code>package main

import (
 "fmt"

 "github.com/sano11o1/go-transaction/entity"
 "github.com/sano11o1/go-transaction/repository"
 "github.com/sano11o1/go-transaction/usecase"
 "gorm.io/driver/postgres"
 "gorm.io/gorm"
)

func main() {
 db, err := initDB()
 if err != nil {
 panic(err)
 }
 baseRepostiry := repository.NewBaseRepositoryImpl(db)
 registerUserUsecase := usecase.NewRegisterUserUsecase(baseRepostiry)
 newUser := entity.User{
 Name: "sano11o1",
 }
 if err := registerUserUsecase.Execute(newUser); err != nil {
 fmt.Println("failed to register user", err.Error())
 panic(err)
 }
}
// initDB は割愛</code></pre><h1 id="hcf83e1357e"> </h1>当初は<code>NewRegisterUserUsecase</code>の引数に<code>UserRepositoryImpl</code>を渡していましたが、<code>UserRepositoryImpl</code>は<code>BaseRepository.GetUserRepository</code>を経由して生成することになったため、引数からは消えています。 新たに<code>BaseRepositoryImlp</code>を渡しています。<code>BaseRepositoryImpl</code>には<code>*gorm.DB</code>を渡必要があります。 ここで渡さないと、Atomicメソッド内部で<code>r.db.Transaction</code>を呼び出すことができません。<pre><code>func (r *BaseRepositoryImpl) Atmoic(fn func(IBaseRepository) error) error {
 // r.dbするにはmain.goでdbを初期化しBaseRepositoryImplを生成する際に渡す必要がある
 return r.db.Transaction(func(tx *gorm.DB) error {
 return fn(NewBaseRepositoryImpl(tx))
 })
}</code></pre> <h1 id="h0f5de14ac4">懸念点</h1><ul><li>RegisterUserUsecaseの依存するRepository層が、RegisterUserUsecaseの<code>Exexcute</code>メソッドの実装を見ないと把握できない。(<code>UserRepositoryImpl</code>は<code>BaseRepository.GetUserRepository</code>を経由して生成することになったため）</li><li>抽象化によりロジックを読み解くのに時間がかかる。このメソッドの戻りがここにきて〜最終的にこの値がセットされて〜とコードを行ったり来たりする必要がある。</li></ul> <h1 id="hcbec2bf0d9">終わりに</h1>ビジネスロジック層の中でトランザクションをいい感じに扱う方法を検討しました。 repository層のInterface, Usecase層では「GORM」を一切使用していないコードになっています。 そのため他のORマッパーに書き換える場合はrepository層のImplementを書き換えるだけで良いはずです。 同様にImplementに手を入れるだけで、他の永続化層に乗り換えることができるはずです。 しかし永続化層を乗り換えるなんてこと、今後のプログラマー人生で経験することはあるのでしょうか。 その時は本実装のように、永続化層が抽象化されビジネスロジックと分離している実装になっていて欲しいものですね。

Golangでトランザクションを抽象化してビジネスロジック層の中で扱う

大抵のAPIにはレート制限が設けられており、レート制限を超えるリクエストは無効扱いになります。 例えばLINE Messaging APIの「WebhookエンドポイントのURLを設定するAPI」には以下のようなレート制限があります。 <a href="https://developers.line.biz/ja/reference/messaging-api/#rate-limits" target="_blank" rel="noopener noreferrer">レート制限</a> <blockquote>WebhookエンドポイントのURLを設定する 1,000リクエスト/分</blockquote> 外部サービスのAPIを叩く処理をLambda関数に委譲する実装パターンを考えます。 Lambda関数は同時実行数を設定できます。同時実行数とは1秒間にLambda関数を最大でいくつ起動するかを決める値です。 <a href="https://aws.amazon.com/jp/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/" target="_blank" rel="noopener noreferrer">必要な同時実行数の制限を計算する</a><blockquote>リージョンのデフォルトの同時実行数は 1,000 インスタンスとなっています。</blockquote> 外部サービスのAPIを叩くLambda関数の同時実行数に大きな値を設定するとレート制限を超えてしまうかもしれません。 できるだけ多くのLambda関数を起動し処理を速く終わらせつつ、レートリミットを超えない値を設定する時の考え方を説明します。 1秒間に2000リクエストまでを許容する外部のAPIを例に考えます。 まずLambda関数の実行にかかる時間と外部のAPIを叩く処理にかかる時間を計測し比較します。※ Lambda関数内の処理が外部のAPIを叩くだけの場合、片方の数値で十分です。 両者の値がほぼ変わらない場合、Lambda関数の実行にかかる時間 = 外部APIを叩くときにかかる時間 と考えて問題ないでしょう。 今回の例では、Lambda関数内の処理が外部のAPIを叩くだけで、外部のAPIを叩く処理にかかる時間は0.1sとします。 次に同時実行数が1の場合、同じ関数インスタンスが1秒間に何度呼びされるかを考えます。 1回の呼び出しにかかる時間は0.1秒なので、最大で10回の呼び出しが想定されます。 <img src="https://images.microcms-assets.io/assets/81f983243e9f4cfc9a2c552fe620be13/9d19bffc3be142edbb026fb7b1995025/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202022-11-30%201.26.26.png?w=397&amp;h=375" alt="緑の正方形: 外部APIのリクエスト"> 緑の正方形: 外部APIの1リクエスト, 1S: 1秒間, L1: 1Lambda関数 を表します。 最後に同時実行数を決めます。 同時実行数が1の場合1秒間に10回の呼び出しが実行されます。1秒間に2000リクエストまでなので、同時実行数は193くらいが妥当でしょう。Lambda関数は1秒間に最大で合計1930回呼び出されます。 <img src="https://images.microcms-assets.io/assets/81f983243e9f4cfc9a2c552fe620be13/e172ee903c444bddb143079c4c252dab/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202022-11-30%209.15.37.png" alt=""> AWSのデフォルトの設定をそのまま使うのではなく、適切な値を設定することで安全に運用していきたいですね。