GoでオリジナルのErrorパッケージを作って運用してみた

GoでオリジナルのErrorパッケージを作って運用してみた　Finatext × エブリー〜スタートアップ最前線のGo事例〜 2020-6-26

Copyright © every, Inc. All rights reserved. 自己紹介 2 2
　 @kondroid00 　新卒で営業職をしつつ、独学でプログラミングを習得して　エンジニアにキャリアチェンジ。スマホゲームや受託案件　や決済サービスの開発を担当。現在は株式会社エブリーで　Goを書いたり、Prestoでクエリを書いたりしてます。

Copyright © every, Inc. All rights reserved. 本出しました 3 3
社内で開いたポインタの勉強会が好評だったので、内容を書籍にして技術書典応援祭に出展しました。気になる方はBOOTHにて「Go ポインタ」で検索 >>

Copyright © every, Inc. All rights reserved. 株式会社エブリーとは 4 4
４つの動画メディアを運営する会社です DELISH KITCHEN 「だれでもおいしく簡単に作れるレシピ」を毎日配信するレシピ動画メディア KALOS 「何度だって、可愛いに出会える」をコンセプトとしたライフスタイル動画メディア MAMADAYS 「ママの課題を解決する」をコンセプトとした　ファミリー向け動画メディア TIMELINE 「知的好奇心を刺激し、あなたの人生にきっかけを届ける」ニュース＆エンタメ動画メディア

Copyright © every, Inc. All rights reserved. エブリーの技術スタック 5 5
サーバー Go フロントエンド Nuxt.js, Next.js ネイティブアプリ Swift, Kotlin データ TreasureData, Spark, MLflow, Redash... インフラ（AWS） ECS, EKS, Lambda, S3, RDS, ElasticCache... その他 Fluentd, Firebase, ElasticSearch... サポートツール CircleCI, Sentry, Datadog, PagerDuty... 社内ツール Slack, Asana, Confluence... 実は創業初期からずっとGoを使ってます

Copyright © every, Inc. All rights reserved. エラーに関する３つの課題 7 課題１
　開発メンバーの増加などでerrorsとpkg/errorsが混在してしまい、Sentryに　スタックトレースを送れないケースが出てきてしまった。課題２　Go1.13が出てerrorsパッケージにIs()とAs()が追加された直後だったため、　errorsとpkg/errorsが混在してエラーハンドリングができないバグが必ず発生　してしまうと思った。　（現在はpkg/errorsがGo1.13のerrorsの実装に合わせているので問題なし）課題３　Sentryにエラーイベントを非同期送信する時にchanのバッファがいっぱいに　なってしまうとイベントがドロップする。 7

Copyright © every, Inc. All rights reserved. 課題１ Sentryにスタックトレースを送れてない 9
9 errorsの使い方 errorsはエラーの発生箇所を Sentryで補足するにはエラーメッセージとして記入する必要がある。 middlewareでSentryにエラーを送信すると、 handler内で発生したエラーは補足できない。エラーの発生場所をトレースするには、例えば以下のような実装を全てのエラーに対して適用する必要がある。 if err != nil { _, file, line, _ := runtime.Caller(0) return nil, fmt.Errorf("%w, file:%s, line:%d\n", err, file, line) }

Copyright © every, Inc. All rights reserved. 課題１ Sentryにスタックトレースを送れてない 10
10 pkg/errorsの使い方 pkg/errorsでは内部でruntime.Caller()を呼び、内部の構造体にスタックトレースを保持しておく。 Sentry送出時にStackTrace()を呼び出し、スタックトレースを送信する。 middlewareでSentryにエラーを送信しても、エラー発生箇所のスタックトレースがちゃんと送信される。途中でerrors.Wrap()でスタックトレースを上書きしなければ何もしなくていいので楽。できればerrorsよりもpkg/errorsを使ってスタックトレースを Sentryに送信したい。

Copyright © every, Inc. All rights reserved. 課題２エラーハンドリングのやり方が違う 12
12 import ( "errors" "fmt" ) var TestError = errors.New("TestError") func foo() error { // fmt.Errorfでラップする return fmt.Errorf("wrap %w", TestError) } func main() { if err := foo(); err != nil { if errors.Is(err, TestError) { fmt.Println(err.Error()) } } } import ( "errors" "fmt" ) type TestError struct{} func (e *TestError) Error() string { return "TestError" } func foo() error { // fmt.Errorfでラップする return fmt.Errorf("wrap %w", &TestError{}) } func main() { if err := foo(); err != nil { var target *TestError if errors.As(err, &target) { fmt.Printf(err.Error()) } } } errorsの使い方 fmt.Errorf()に%wを使ってエラーをラップしてからIs()とAs()でエラーハンドリングする。エラー構造体をレシーバーとする関数 Unwrap()が実装されていなければ Is()と As()でハンドリングができない。

13 import ( e "github.com/pkg/errors" "fmt" ) var TestError = e.New("TestError") func foo() error { // e.Wrapでラップする return e.Wrap(TestError, "wrap") } func main() { if err := foo(); err != nil { err1 := e.Cause(err) if err1 == TestError { fmt.Println(err.Error()) } } } import ( e "github.com/pkg/errors" "fmt" ) type TestError struct{} func (e *TestError) Error() string { return "TestError" } func foo() error { // e.Wrapでラップする return e.Wrap(&TestError{}, "wrap") } func main() { if err := foo(); err != nil { err1 := e.Cause(err) if _, ok := err1.(*TestError); ok { fmt.Println(err.Error()) } } } pkg/errorsの使い方(実装当時) Wrap()でエラーをラップしてから Cause()でエラーを取り出して、等価演算子や型アサーションでエラーハンドリングする。エラー構造体をレシーバーとする関数 Cause()が実装されていなければ e.Cause()でエラーを取り出せない。

14 import ( e "github.com/pkg/errors" "fmt" ) var TestError = e.New("TestError") func foo() error { // e.Wrapでラップする return e.Wrap(TestError, "wrap") } func main() { if err := foo(); err != nil { err1 := e.Cause(err) if err1 == TestError { fmt.Println(err.Error()) } } } import ( e "github.com/pkg/errors" "fmt" ) type TestError struct{} func (e *TestError) Error() string { return "TestError" } func foo() error { // e.Wrapでラップする return e.Wrap(&TestError{}, "wrap") } func main() { if err := foo(); err != nil { err1 := e.Cause(err) if _, ok := err1.(*TestError); ok { fmt.Println(err.Error()) } } } pkg/errorsの使い方(実装当時) Wrap()でエラーをラップしてから Cause()でエラーを取り出して、等価演算子や型アサーションでエラーハンドリングする。エラー構造体をレシーバーとする関数 Cause()が実装されていなければ e.Cause()でエラーを取り出せない。 fmt.Errorf()でラップしたエラーは e.Cause()でハンドリングできない。また、e.Wrap()でラップしたエラーは errors.Is()やerrors.As()でハンドリングできない。

15 import ( e "github.com/pkg/errors" "fmt" ) var TestError = e.New("TestError") func foo() error { // e.Wrapでラップする return e.Wrap(TestError, "wrap") } func main() { if err := foo(); err != nil { if e.Is(err, TestError) { fmt.Println(err.Error()) } } } import ( e "github.com/pkg/errors" "fmt" ) type TestError struct{} func (e *TestError) Error() string { return "TestError" } func foo() error { // e.Wrapでラップする return e.Wrap(&TestError{}, "wrap") } func main() { if err := foo(); err != nil { var target *TestError if e.As(err, &target) { fmt.Printf(err.Error()) } } } pkg/errorsの使い方(ver0.9.0) Wrap()が返す構造体にUnwrap()が実装されており、errorsのAs()とIs()をそれぞれラップしたものも実装されているので、Cause()を使わずにAs()とIs()を使うように統一すれば問題にはならなさそう。

Copyright © every, Inc. All rights reserved. 課題３エラーイベントがドロップする 17
17 type HTTPTransport struct { …. buffer chan *http.Request // Size of the transport buffer. Defaults to 30. BufferSize int …. } func (t *HTTPTransport) worker() { for request := range t.buffer { // 送信処理 } } func (t *HTTPTransport) SendEvent(event *Event) { …. select { case t.buffer <- request: …. default: …. // worker would block, drop the packet } .... } sentry-goの非同期イベント送信 chan *http.Request型のフィールド(buffer)にもつ構造体を定義。BufferSizeを変更することでbufferのサイズを変更可能。(bufferのことを以下送信バッファと呼ぶ ) まずはworker()を別goroutineで起動し、送信バッファに *http.RequestがPushされるのをforループで待ち受ける。送信バッファに*http.RequestがPushされるとrequestを取り出し、そのrequestを使ってSentryサーバーに送信する。問題はSendEvent()が呼ばれた時に送信バッファが満杯だった場合、エラーイベントが Sentryに送信されずにドロップする。ドロップを防ごうとしてエラーごとに送信バッファを新規作成したり、同期送信を使うとメモリを使い潰してサーバーが落ちるリスクがある。

Copyright © every, Inc. All rights reserved. 課題３エラーイベントがドロップする 18
18 type HTTPTransport struct { …. buffer chan *http.Request // Size of the transport buffer. Defaults to 30. BufferSize int …. } func (t *HTTPTransport) worker() { for request := range t.buffer { // 送信処理 } } func (t *HTTPTransport) SendEvent(event *Event) { …. select { case t.buffer <- request: …. default: …. // worker would block, drop the packet } .... } sentry-goの非同期イベント送信エラーの発生頻度より Sentryへの送出頻度が高ければ、エラーイベントがドロップすることはないので特に問題はない。しかし、DELISH KITCHENはアクセス数が多く、同じ箇所で大量の同じエラーが発生してしまうことがある。（サーバー内部で叩く他のAPIサーバーが500を返すときなど）結果、Sentryへの送出頻度よりエラーの発生頻度が高くなってしまい、送信バッファがすぐにチャネルの最大サイズに到達してしまう。この状態で別の箇所でクリティカルなエラーが発生した場合、エラーをSentryに送信することができないため、その場で重大なエラーの発生を見逃してしまう。

Copyright © every, Inc. All rights reserved. エラーに関する３つの課題（再掲） 19 課題１（未解決）
　開発メンバーの増加などでerrorsとpkg/errorsが混在してしまい、Sentryに　スタックトレースを送れないケースが出てきてしまった。課題２（未解決）　Go1.13が出てerrorsパッケージにIs()とAs()が追加された直後だったため、　errorsとpkg/errorsが混在してエラーハンドリングができないバグが必ず発生　してしまうと思った。　（現在はpkg/errorsがGo1.13のerrorsの実装に合わせているので問題なし）課題３（未解決）　Sentryにエラーイベントを非同期送信する時にchanのバッファがいっぱいに　なってしまうとイベントがドロップする。 19

Copyright © every, Inc. All rights reserved. 課題を解決する 21 解決手順１
　課題１と課題２を解決するために、原則errorsとpkg/errorsはimportさせない。　その代わりとして必要な機能を全て提供したオリジナルのエラーパッケージ　を定義し、それを機械的にimportするようにする。解決手順２　オリジナルのエラーパッケージに課題３を解決する機能を追加する。具体的　には送信するエラーごとにsentry.Clientを別のものを使うことで送信バッファ　を分け、同じエラーであればエラーイベントのドロップを許す。 21

Copyright © every, Inc. All rights reserved. 解決手順１エラーパッケージを作る 23
23 import ( "fmt" "errors" e "github.com/pkg/errors" ) func main() { if err := foo(); err != nil { fmt.Println(err.Error()) } if err := bar(); err != nil { fmt.Println(err.Error()) } } func foo() error { return errors.New("errors") } func bar() error { return e.New("pkg/errors") } errorsパッケージはこれだけimportしとけばOKというものを用意する import ( "fmt" "github.com/kondroid00/sample-grpc-point/package/errors" ) func main() { if err := foo(); err != nil { fmt.Println(err.Error()) } if err := bar(); err != nil { fmt.Println(err.Error()) } } func foo() error { return errors.New("package/errors") } func bar() error { return errors.New("package/errors") }

24 package errors import ( "errors" e "github.com/pkg/errors" ) type ( CustomError struct { // github.com/pkg/errorsの*fundamentalを入れる err error } ) // New messageとstacktraceを格納したエラーを返す func New(message string) *CustomError { return &CustomError{ err: e.New(message), } } // Stack 既存のエラーにstacktraceを格納したエラーを返す func Stack(err error) *CustomError { return &CustomError{ err: e.WithStack(err), } } CustomErrorを定義 pkg/errorsの*fundamentalをラップする構造体である CustomErrorを定義する。 pkg/errorsのNew()とWithStack()に相当するジェネレーター関数であるNew()とStack()を用意する。

25 package errors import ( "errors" e "github.com/pkg/errors" ) ……. // Error Errorインターフェースを満たす func (ce *CustomError) Error() string { return ce.err.Error() } // StackTrace StackTrace()が実装されている場合にそれを呼び出す。sentryにstacktraceを送信する際に利用する func (ce *CustomError) StackTrace() e.StackTrace { if stackTracer, ok := ce.err.(interface { StackTrace() e.StackTrace }); ok { return stackTracer.StackTrace() } return nil } // Unwrap errors.Isとerrors.Asで利用する func (ce *CustomError) Unwrap() error { // pkg/[email protected]以降であればe.Unwrap()でもOK return e.Cause(ce.err) } CustomErrorを定義 pkg/errorsの*fundamentalをラップする構造体である CustomErrorを定義する。 pkg/errorsのNew()とWithStack()に相当するジェネレーター関数であるNew()とStack()を用意する。 Errorインターフェースを満たすよう Error()を実装する。 StackTracerインターフェースを満たすよう StackTrace()を実装する。これがなければ middlewareでSentryに送信する時にエラー発生箇所のスタックトレースを送信できない。 Unwrap()を実装する。これがなければ後述の Is()とAs()でエラーハンドリングができない。

26 package errors import ( "errors" e "github.com/pkg/errors" ) ……. // Is errors.Isと同じ func Is(err, target error) bool { return errors.Is(err, target) } // As errors.Asと同じ func As(err error, target interface{}) bool { return errors.As(err, target) } CustomErrorを定義 pkg/errorsの*fundamentalをラップする構造体である CustomErrorを定義する。 pkg/errorsのNew()とWithStack()に相当するジェネレーター関数であるNew()とStack()を用意する。 Errorインターフェースを満たすよう Error()を実装する。 StackTracerインターフェースを満たすよう StackTrace()を実装する。これがなければ middlewareでSentryに送信する時にエラー発生箇所のスタックトレースを送信できない。 Unwrap()を実装する。これがなければ後述の Is()とAs()でエラーハンドリングができない。 errorsやpkg/errorsを別途importする必要をなくすためのラップ関数を用意。

Copyright © every, Inc. All rights reserved. 解決手順２エラーイベントのドロップを防ぐ 28
28 package alert type ClientKey string type AlertError interface { error ClientKey() ClientKey } AlertErrorインターフェースを定義 errorインターフェースをembedし、ClientKey()の実装を要求するAlertErrorインターフェースを定義する。

29 package errors import ( "errors" e "github.com/pkg/errors" ) ……. type CustomErrorWithKey struct { CustomError // CustomeErrorをembed clientKey string // alert.AlertErrorで使うclientKey } // NewWithKey messageとstacktraceとclientKeyを格納したエラーを返す func NewWithKey(message, clientKey string) *CustomErrorWithKey { return &CustomErrorWithKey{ CustomError: *New(message), clientKey: clientKey, } } // StackWithKey 既存のエラーにstacktraceとclientKeyを格納したエラーを返す func StackWithKey(err error, clientKey string) *CustomErrorWithKey { return &CustomErrorWithKey{ CustomError: *Stack(err), clientKey: clientKey, } } CustomErrorWithKeyを定義 CustomErrorをembedしてstring型のフィールドclientKey をもつCustomErrorWithKey構造体を定義する。 CostomErrorのNew()とStack()と同様にジェネレーター関数のNewWithKey()とStackWithKey()を定義。clientKeyを引数にとり、フィールドに設定する。

30 package errors import ( "errors" e "github.com/pkg/errors" ) ……. // Error Errorインターフェースを満たす func (ce *CustomErrorWithKey) Error() string { return ce.CustomError.Error() } // StackTrace StackTrace()が実装されている場合にそれを呼び出す。sentryにstacktraceを送信する際に利用する func (ce *CustomErrorWithKey) StackTrace() e.StackTrace { return ce.CustomError.StackTrace() } // Unwrap errors.Isとerrors.Asで利用する func (ce *CustomErrorWithKey) Unwrap() error { return ce.CustomError.Unwrap() } // ClientKey AlertErrorインターフェースを満たす func (ce *CustomErrorWithKey) ClientKey() string { return ce.clientKey } CustomErrorWithKeyを定義 CustomErrorをembedしてstring型のフィールドclientKey をもつCustomErrorWithKey構造体を定義する。 CostomErrorのNew()とStack()と同様にジェネレーター関数のNewWithKey()とStackWithKey()を定義。clientKeyを引数にとり、フィールドに設定する。 CustomErrorと同じくError()、StackTrace()、Unwrap()を実装する。 AlertErrorインターフェースを満たすように ClientKey()を実装し、フィールドの clientKeyを返却する

31 package alert ……. type Sentry struct { ……. clientPool map[ClientKey]*sentry.Client } func (s *Sentry) getClient(key ClientKey)(*sentry.Client, error) { ……. if c, ok := s.clientPool[key]; ok { return c, nil } else { client, err := sentry.NewClient(s.options) ……. s.clientPool[key] = client return client, nil } ……. } func (s *Sentry) Send(e error, info *Info) { clientKey := "default" if err, ok := e.(AlertError); ok { clientKey = err.ClientKey() } client := s.getClient(clientKey) ……. } Sentryにエラーイベントを送信する ClientKeyをkey、*sentry.ClientをvalueとするmapをフィールドにもつSentry構造体を定義。この構造体はサーバー起動時に一つだけ作成され、複数のリクエストで参照される。

32 package alert ……. type Sentry struct { ……. clientPool map[ClientKey]*sentry.Client } func (s *Sentry) getClient(key ClientKey)(*sentry.Client, error) { ……. if c, ok := s.clientPool[key]; ok { return c, nil } else { client, err := sentry.NewClient(s.options) ……. s.clientPool[key] = client return client, nil } ……. } func (s *Sentry) Send(e error, info *Info) { clientKey := "default" if err, ok := e.(AlertError); ok { clientKey = err.ClientKey() } client := s.getClient(clientKey) ……. } Sentryにエラーイベントを送信する ClientKeyをkey、*sentry.ClientをvalueとするmapをフィールドにもつSentry構造体を定義。この構造体はサーバー起動時に一つだけ作成され、複数のリクエストで参照される。 getClient()を定義し、引数のkeyに対応する*sentry.Client がmapに存在すればそれを返し、なければ新規作成して mapに詰めてから返す。複数のリクエストから叩かれる関数なのでスレッドセーフに作る必要がある。

33 package alert ……. type Sentry struct { ……. clientPool map[ClientKey]*sentry.Client } func (s *Sentry) getClient(key ClientKey)(*sentry.Client, error) { ……. if c, ok := s.clientPool[key]; ok { return c, nil } else { client, err := sentry.NewClient(s.options) ……. s.clientPool[key] = client return client, nil } ……. } func (s *Sentry) Send(e error) { clientKey := "default" if err, ok := e.(AlertError); ok { clientKey = err.ClientKey() } client := s.getClient(clientKey) ……. } Sentryにエラーイベントを送信する ClientKeyをkey、*sentry.ClientをvalueとするmapをフィールドにもつSentry構造体を定義。この構造体はサーバー起動時に一つだけ作成され、複数のリクエストで参照される。 getClient()を定義し、引数のkeyに対応する*sentry.Client がmapに存在すればそれを返し、なければ新規作成して mapに詰めてから返す。複数のリクエストから叩かれる関数なのでスレッドセーフに作る必要がある。 Send()にて送信するerrorがAlertErrorインターフェースを満たすかどうか型アサーションでチェックして、満たすならclientKeyを取得。clientKeyに対応する*sentry.Client を取得してSentryに送信する。

34 import ( "github.com/kondroid00/sample-grpc-point/package/errors" ) // エラーの発生が稀なところではCustomErrorを使う func foo() error { if !ok { return errors.New("error") } if err := hoge(); err != nil { return errors.Stack(err) } ……. } // 大量のエラーが発生すると見込まれるところCustomErrorWithKey を使う func bar() error { if !ok { return errors.NewWithKey("error", "bar") } if err := hoge(); err != nil { return errors.StackWithKey(err, "bar_hoge") } ……. } CustomError(WithKey)の使い方エラーの発生が稀だと思われるところでは CustomErrorを使うようにする。サーバーから叩くAPIが500を返すようになった場合など、大量のエラーが発生すると見込まれるところは CustomErrorWithKeyを使う。clientKeyが同じであれば、送信バッファに入り切らなくなったエラーはドロップするが、他で発生したエラーは別の送信バッファで影響を受けずに送信できる。オリジナルパッケージに As()とIs()も用意しているので、そちらを使ってエラーハンドリングも問題なく可能。

Copyright © every, Inc. All rights reserved. 課題を解決する（再掲） 35 解決手順１（済）
　課題１と課題２を解決するために、原則errorsとpkg/errorsはimportさせない。　その代わりとして必要な機能を全て提供したオリジナルのエラーパッケージ　を定義し、それを機械的にimportするようにする。解決手順２（済）　オリジナルのエラーパッケージに課題３を解決する機能を追加する。具体的　には送信するエラーごとにsentry.Clientを別のものを使うことで送信バッファ　を分け、同じエラーであればエラーイベントのドロップを許す。 35

Copyright © every, Inc. All rights reserved. 実際に運用してみて 37 その１
　複数のエラーパッケージがimportされることはなくなり、Sentryに　スタックトレースがちゃんと送られるようになった。その２　エラーハンドリングも明確になり、ハンドリングの不具合で事故が起きる　雰囲気はなくなった。その３　エラーイベントのドロップの件では、幸いにも大量のエラーが発生した　ケースは出なかったので、まだ恩恵を受けていない。 37

Copyright © every, Inc. All rights reserved. 個人的なぼやき 38 その１
　組み込みのerrorsを使うのがいいのかもしれないけど、Sentryを使うなら　今のところpkg/errorsの方がスタックトレースが取れて便利。ただし　　pkg/errorsの開発は止まり気味。その２　基本的にはpkg/errorsのVer 0.9.0以降で統一するのが良さそう。ただ、　Sentryのエラーイベント欠損を防ぐなど、独自機能を入れるとなると　Goならオリジナルパッケージを作るのが一番シンプルでいい気がする。その３　なんとなくエラーのオリジナルパッケージを作ることにうしろめたさは　あったが、今回の課題の解決方法としてはかなり機能した。その４　Goのエラーでいい方法あれば教えてくださいm(_ _)m 38

Copyright © every, Inc. All rights reserved. 関連リンク 40 DELISH
KITCHEN　〜「だれでもおいしく簡単に作れるレシピ」を毎日配信するレシピ動画メディア〜 - https://delishkitchen.tv MAMADAYS　〜「ママの課題を解決する」をコンセプトとしたファミリー向け動画メディア〜 - https://mamadays.tv KALOS　〜「何度だって、可愛いに出会える」をコンセプトとしたライフスタイル動画メディア〜 - https://www.instagram.com/kalos.tv TIMELINE　〜「知的好奇心を刺激し、あなたの人生にきっかけを届ける」ニュース＆エンタメ動画メディア〜 - https://www.facebook.com/TimelineNews.tv every.thing　〜エブリーのこと、ぜんぶ伝えるウェブマガジン〜 - https://everything.every.tv Goのポインタを完全に理解する本　〜技術書典応援祭に出展したポインタの解説書〜 - https://booth.pm/ja/items/1993101 40

GoでオリジナルのErrorパッケージを作って運用してみた

GoでオリジナルのErrorパッケージを作って運用してみた

More Decks by kondroid

Other Decks in Programming

Featured

Transcript