X（旧Twitter）で.envファイルの話が盛り上がっていたので、自分の考えを書き留めておきます。 <h1 id="hb0531df5de"> 最低限やっておきたいこと</h1>.envに絞って考えると、シンプルにまとめられます。<h2 id="h43d5173ea3"> 本番環境のクレデンシャルはローカルに置かない</h2>これでClaude Codeが読み込むことは100%ない。これはbefore LLMの時代からそうなっていることが多いですが、改めて徹底する価値があります。インフラのapplyやdeployはCIに委ねて、本番クレデンシャルはCIのシークレット管理にのみ存在させる。<h2 id="h652960f774"> 開発環境のAPI Keyは妥協する</h2>ローカルには開発環境用のAPI Keyを置くことは現実的な妥協です。漏洩しても顧客の個人情報が流出することはまずない。あるとしたら不正利用されてコストが異常にかかる懸念があります。以下の対策でカバーします。<ul><li>Claude Codeのpermissionを設定する</li><li>API Keyのアクセス権限を最小にする</li><li>請求のリミットを設定してアラートを出す</li></ul> <h1 id="h710097db3f"> --dangerously-skip-permissionsを使うならコンテナで隔離する</h1><code>--dangerously-skip-permissions</code>を使っていたり、Claude Codeの許可確認を真面目に見ずにYesを押している人は、コンテナを起動してその中でClaude Codeを起動するのが良いでしょう。 なぜかというと、<code>--dangerously-skip-permissions</code>で動かすとClaude CodeがAWS CLIなどのコマンドを実行することがあります。もしSSOでログインしている状態だと、開発者と同じ権限で本番環境を普通に操作できてしまいます。本番の.envを隔離していても、例えばAWS Secret Managerのコマンドを打たれると困ったことになります。 SSOのクレデンシャルをコンテナにマウントしなければ、この問題は防げます。<pre><code>ホスト（開発者）
├── 本番クレデンシャル → CIのみ
├── フル権限のクラウド認証情報 → ホストのみ、コンテナに渡さない
└── Claude Code環境（Docker等）
 └── 開発用クレデンシャルのみ</code></pre> あとは隔離しておくことでClaudeCodeを実行するコンテナのアウトバウンドトラフィックを厳格にcontrolすることも可能です。 <h2 id="h93d4791f95"> Claude標準のsandboxじゃダメなの？</h2>Claude Codeにはネイティブのサンドボックス機能があります。macOSはSeatbelt、LinuxはbubblewrapというOSレベルのプリミティブでファイルシステムとネットワークを分離できます。一見すると有効な対策に見えます。 しかし構造的な問題があります。<pre><code>Claude Codeのプロセス（サンドボックスの外）
 └── サンドボックス（コマンドの実行環境）</code></pre>サンドボックスはClaude Codeが実行するコマンドを隔離するものであって、Claude Code自身のプロセスはホストに存在しています。タスクを完了するために、実行されたら困るコマンドが打たれる可能性はゼロではありません。 <a href="https://ona.com/stories/how-claude-code-escapes-its-own-denylist-and-sandbox" target="_blank" rel="noopener noreferrer">「How Claude Code escapes its own denylist and sandbox」</a>という記事が詳しいですが、実際にエージェントがサンドボックス自体を無効化してコマンドを実行した事例があります。ジェイルブレイクも特別なプロンプトも不要で、ただタスクを完了させようとしただけで起きたことです。 自分を縛っているロープを自分で切れる構造になっている以上、根本的な限界があります。 Dockerコンテナはこの問題を外側から解決します。制約はClaude Codeの外側から与えられているので、Claude Code自身がその制約を外すことはできません。 <h1 id="hf7b12f2d8c"> 最後に：これは過渡期の設計である</h1>最終的にはClaude Codeのガードレールをどこまで信用するか、という話になってきます。 Anthropicとしては、AGI実現のためにClaudeが倫理観に基づいて物事を判断できる姿を目指しています。将来的には2つのシナリオが考えられます。<h2 id="h1324542050"> シナリオA：信頼のインフラが整備される</h2>Anthropicが「このモデルはこういう行動をしない」という保証が法的・社会的に意味を持つようになったとき、LLMにより多くの権限が委譲されていくでしょう。人間のエンジニアが本番のクレデンシャルにアクセスできるのも、雇用契約・法的責任・社会的評判という信頼のインフラがあるから。LLMにも同様のインフラが整備される未来です。 <h2 id="hc198c00eb0">シナリオB：便利さがセキュリティを上回る</h2>社会的な保証なしで、長時間のタスクを自律的に解けるようになるため「便利 &gt; セキュリティ」の構図になり大きな権限をなし崩し的に与える。 これは結構ありそうで、この時どういった環境でClaudeCodeを実行するかが重要なポイントになりそうです。 どちらのシナリオに転んでも、今のうちにDockerで隔離する習慣をつけておくのは良い筋だと思っています。現時点では<code>--dangerously-skip-permissions</code>を使うなら隔離された環境で実行するのが安全です。

.envの管理について思うこと——Claude Codeと本番クレデンシャル

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のデフォルトの設定をそのまま使うのではなく、適切な値を設定することで安全に運用していきたいですね。