Recommended
More Related Content
What's hot
What's hot (19)
Similar to Go conference 2021 autumn
Similar to Go conference 2021 autumn (20)
Recently uploaded
Go conference 2021 autumn
- 1. Go Contextを完全に理解する 伊藤 真彦 The Gopher character is based on the Go mascot designed by Renée French
- 2. 伊藤真彦 Masahiko Ito フューチャー株式会社 TIG DXチーム所属 担当領域: コンサルタントとしてなんでもやっています 趣味: ギター 資格: @it_guitar 自己紹介
- 4. 自己紹介 発表のモチベーション ● よくわからないまま使っている機能があるので理解したかった ○ 例: ポインタ、2020年のGoアドベントカレンダーのネタにした ● contextが期待通りの状態になっているかデバッグするのに苦労した、 発表を通してしっかり理解し、また理解できるコンテンツを作りたい ● contextは少ない行でGoのテクニックをたくさん使っている 実装を深堀すると学びになる
- 5. Contextとは
- 7. Contextとは 例: AWS SDKのLambdaハンドラ→Amazon Dynamo DB SDKを利用したDBリクエスト
- 11. Contextとは タイムライン(言い訳) プロポーザル提出 zenn無料書籍公開 プロポーザル採択 2021/08/03 2021/08/28 2021/09/15
- 13. Contextの内部実装
- 19. Contextの内部実装 ContextのベースとなるemptyCtxが定義されています intがベースとなっているのはこの型の値の全てが 異なるアドレスを持つようにするためです Interfaceとしての仕様を満たす関数を備えつつ、 それぞれの型の0値を返します Deadline()で名前付きの戻り値を利用することで、 return一行で 0001-01-01 00:00:00 +0000 UTC, false を返却するのはGoにしては珍しいトリッキーな書き方 String()だけはbackgroundとtodoを区別するための switch文が書かれています
- 24. Contextの内部実装 少々難しい処理ですが、parentCancelCtxで親contextの状態、型を確認しながら キャンセル状況を伝播させるか否か整理しています 実装部分のコメントを翻訳 parentCancelCtxは、親の基になる* cancelCtxを返し ます。 これは、parent.Value（＆cancelCtxKey）を検索し て見つけることによって行われます。 最も内側の囲んでいる* cancelCtxをチェックし、 parent.Done（）はその* cancelCtxと一致します。 （そうでない場合、* cancelCtx 別の完了チャネルを提供するカスタム実装にラップ されています。その場合、それをバイパスしないで ください。）
- 36. Contextの内部実装 func (t *timerCtx) Done()のような記述は一切ありませんが、 構造体の埋め込みによりtimerCtxはcancelerのインターフェース仕様を 満たしています
- 43. Contextの内部実装 valueCtxも独自のString()関数を持っています stringify は、fmt を使わずに v を文字列化しよ うと少しだけ試みます。 というのは、 私たちはcontextがunicodeテーブルに依存する 事を望まないからです。 これは*ValueCtx.String()でのみ使用されます 。
- 51. まとめ
- 63. 技術を読む 人・企業を知る 技術を聴く 勉強会に参加する フューチャーの技術ブログ。 業務で利用している幅広い技術について 、最新のトピックを交えて紹介します。 フューチャーの技術者によるポッドキャスト。 技術の深堀りトークやブログ記事の裏に隠され た秘話をお届けします。 フューチャーの人、カルチャー、イベントレ ポートなどを幅広く発信。ありのままのフュ ーチャーをタイムリーに紹介します。 未来報 connpass エンジニアや IT コンサルタント向けの勉強会 を定期的に開催。フューチャーが業務を通して 得た技術的な知見やナレッジを共有します Future Tech Blog Future Tech Cast https://future-architect.github.io/ https://anchor.fm/futuretechcast https://note.future.co.jp/ https://future.connpass.com/ フューチャーをもっと知るには?
Editor's Notes
- 自己紹介です。私は伊藤真彦と申します。フューチャー株式会社という会社で、ITコンサルタントとして働いています。担当領域は要件定義から実装まで全てです。今年はAWSの資格を取ることに力を入れていました、気持ちよく自己紹介するために先週11個すべてを取得しました。
- 会社の説明もさせていただきます。フューチャーはITコンサルティングを中心に、開発、保守までを一気通貫の体制で行う会社です。Go Conferenceのブロンズスポンサーをやっています。本日は私を含め3名の社員が登壇しています。
- 発表のモチベーションですが、皆さんはGoでいうとポインタやインターフェースなど、熟知しているとはいえないものの使えている機能に心当たりは無いでしょうか。私にとってはContextもそのうちの一つでした、抽象化されたインターフェースがある事は素晴らしい事ですが、そういったものを一度立ち止まって深く理解する機会を設けたいなと思い、発表のテーマに選びました。また、今回の発表はcontextの内部実装を追う事で知らなかった、忘れていた、というGoのテクニックを学べるものになるように意識しています。
- それでは、Contextの概要から説明します。
- contextはAPIの境界を越えて、プロセス間で、期限、キャンセルシグナル、 およびその他のリクエストスコープの値を伝達します、と公式の説明に記載されています。平たく言うと、採用したライブラリがContextを提供してくれたり、DBクライアントライブラリなどがcontextを受け取る機能を用意している場合があります。 そこでcontextをバケツリレーのように渡していくだけでタイムアウトやキャンセルが適宜制御される、といったものです。
- 例えば、AWS Lambdaの上で動くコードを書く際に利用するライブラリを利用すると、エントリポイントとなる関数のlambda.Startに渡す任意の実装がcontextを受け取るようになっています。 また、DynamoDBに接続するためのクライアントライブラリはcontextを受け取り、contextに設定されたタイムアウト時間を過ぎるとDBへのアクセスを中断できる関数が存在します。
- もちろん任意の実装も可能です、ここで書いている処理は、context.WithTimeout関数で作ったcontextに対して設定した時間、処理を繰り返すコードになっています。 コードを読んでみます、5秒後にタイムアウトする設定をしたcontextの変数を作成して、execute関数に渡しています、execute関数では無限ループを行っていますが、select文でcontextのタイムアウトを監視し、タイムアウトした場合は処理を終了するように実装しています、処理は一秒間待機してExecute Somethingという文字列を吐いているだけですが、実行結果のように5秒間処理を繰り返したあとに停止しています。
- より実用的な例として、Go1.16から採用されたsignal.NotifyContext()を用いたgracefulシャットダウンを紹介します。gracefulシャットダウンとはつまりユーザーがプロセスをキルしても安全に停止できる処理ですね。これは渋川さんがフューチャー技術ブログに書いています。
- このように、contextには様々な使い方が存在しますが、最近zennにわかりやすい書籍が公開されました。目次の通り、contextがもっている機能とその使い方が説明されています。これを読めば基本的な使い方はマスターできます。
- なぜ質の高い情報があるのに発表するのか、という言い訳なんですが、私がcontextをテーマに登壇するプロポーザルを提出してから先ほどの書籍が公開されました。そしてわざわざ撤回するべきかと迷っている間に採択された形です。正直焦りました。
- しかし、この本のお陰で私の発表は内部実装にフォーカスしたものにすることができます、ありがとうございます。
- というわけで、次のセクションからは内部実装を深堀していきます
- Contextは発表段階で593行ですべてが実装されています。 そのくらいの量であれば今日の発表で全部コードリーディングできるだろう、というのが発表の趣旨です
- 頭からコードを読む前にcontextとは、という話をします contextの実態はinterfaceです、Deadline Done Err Valueの4つのインターフェース使用を満たしたcontext構造体がいくつか存在し、外部からはそれらを抽象化して利用しています
- 序盤はコメントが多いので、これだけで154行まで説明が済みます
- 次に、キャンセル、タイムアウト時に所定のメッセージを返すためのエラーが2種類定義されています。Canceldはシンプルなエラーです DeadlineExceededは通常のエラーより拡張された独自のエラー型です、拡張機能として実装されたTimeout, Temporaryは内部では利用されていません これらはnetパッケージで提供されているエラーと同じインターフェース使用を満たすことで、呼び出し元でのリトライ制御に役立てることができます
- 参考までにnetパッケージのErrorインターフェースを見てみましょう、左上の画像の通り、素朴なerrorに加えtimeout, Temporaryが拡張されたインターフェースが実装されています。このインターフェース仕様を満たす独自の構造体errNetClosingなどがnetパッケージには存在します。context内部の独自エラーはこの作法に則っています。使い方は右側の画像の通り、型アサーションでnet.Errorインターフェースの仕様を満たすかを確認してからTemporaryメソッドを呼び出して、リトライやログレベルの分岐などの制御が行えます。
- contextの話に戻りますが、エラーなど定数的な情報の記述が終わったら、最も素朴なemptyCtxが定義されています。emptyCtxはintがベースとなった型です。この型の変数が全て異なるアドレスを持つために、structではなくintから型を定義しているとコメントに書いてあります、詳しくは後で説明します。 emptyCtxはInterface仕様を満たすための関数を備えています。いずれもnilやfalseのような値を返すものが多いです。Deadline関数では、名前付きの戻り値を使う事でreturn文をシンプルに書いたままtime.Timeとboolの0値を返却する、というトリッキーな書き方になっています。この手法を業務で上手く使う人は少ないと思いますので、テクニックとして覚えておきたいですね。Stringだけはbackgroundとtodoを区別するためのswitch文が書かれています。
- Background, todoは内部で変数定義されています、この二つのemptyCtxを外部から取得する Background, TODOが定義されています。一見するとbackgroundとtodoはStringメソッドの処理の分岐結果以外に違いがありません。実際持っている機能としては完全に同じで、後続処理でもこの二つを区別していません。コメントを読んでみると、可読性のためにわけられている事がわかります。context.Backgroundは、これから設定を詰めるための初期化のために取得するcontextです。一方todoは用途が明確でない、もしくは必要か明確に定まっていないときに一時的に置いておくものとして呼び出します。意義としての使い分けはされていますが、backgroundを使って欲しいタイミングでtodoを呼び出してもバグが起きることはありません
- 値のすべてが異なるアドレスを持つ、とはどういう事なのかは、実際に動かしてみるとわかります。intを基にした型とstructを基にした型を用意し、その方の変数を複数作ります。これらは同じ型なので==で比較できますが、intを基にした型は一つ一つの変数を宣言するたびに新しくメモリを確保し、違うアドレスが割り当てられますが、空のstructを基に型を作ると、同じデータが使いまわされ、メモリが節約されます。この挙動の違いがあるため、emptyCtxがstructで作られた場合はbackgroundとtodoを比較するとtrueになります。これを回避するためにemptyCtxはintを拡張したものとして作られています。
- emptyCtxは以上です、続いてcancelCtxの実装が始まります、cancelCtxはその名の通り処理のキャンセル機能を作るうえで役立つ実装が組み込まれたcontextです、WithCancel関数でcancelCtxと、それをキャンセルするための関数を取得できます。emptyCtx以外はWith～の関数で呼び出すときに親のコンテキストを渡して、親子関係をネストする仕組みが作られています。
- 245行目あたりから、親子関係としてネストしているコンテキストのキャンセル情報を伝播させるための関数が実装されています。言葉にするとシンプルですがcontextパッケージの中では読み解くのが難しい部類です。
- propagateCancel内部で呼び出されているparentCancelCtxで、親コンテキストの状態、型を確認しながら、キャンセル状況を伝播させるための関係性を整理しています、コメントを読んでみても割と内容が伝わりづらいです。
- 314行目でremoveChildが実装されています、その名の通り、cancelCtxに登録されたchildrenを掃除するための処理です
- 326行目でcanceleインターフェースが定義されています、これはcancelCtxと、このあと紹介するtimerCtxがこの仕様を満たします。
- 333行目でclosedchanとcancelCtxが定義されています、closedchanはその名の通りinitで即閉じられるチャネルです。 cancelCtxがキャンセルされているか否かはチャンネルの状態で判断しています。
- 351行目から、Value Done Errが定義され、contextのインターフェース仕様を満たしています。cancelCtxは並行処理で動作する事を見越して作られているので、読み込むと並行処理の勉強になります。
- 380行目~ String()とそれで用いる関数が定義されています StringはinterfaceとしてのContextに定義されていないため、直接呼び出すことはできません
- 試してみると画像のようになります、画像右のようにstringerインターフェースを定義して型アサーションする事で無理やり呼び出すことは可能です。
- ややこしい事をしなくても、fmtパッケージのPrint関数に渡すことで同じことができます。
- 397行目から、cancelが実装されています。これはcontext.WithCance関数lで取得できるキャンセル機能です。これを実行するとcancelContextの持っているチャンネルがcloseされます。同時に親子関係を参照し、キャンセル状況を伝播させるべきcontextもキャンセルします。
- cancelCtxについては以上です。425行目から、WithDeadLine関数が実装されています。この関数には親のcontextとデッドラインとなる時刻を引数で渡します。親のコンテキストが既にタイムアウト済であったり、与えたデッドラインが過去の時間だった場合の保険も実装されていますが、デッドラインの時刻でキャンセルが呼び出されるように予約されたtimerCtxと、それを任意のタイミングでキャンセルする関数が返却されます。
- ここで使われているtime.AfterFuncは、処理を遅延実行させることが簡単に行える便利な機能です、覚えておくと予約実行機能を実装したい時に役に立ちます。
- 465行目にtimerCtxが定義されています。cancelCtxがフィールドに埋め込まれており、timerCtxはcancelCtxの拡張であることがわかります。cancelCtxに、キャンセルの予約実行機能と、デッドライン時刻の返却機能をもたせたものがtimerCtxという事になります。
- func (t *timerCtx) Done()のような記述は一切ありませんが、構造体の埋め込みによりtimerCtxはcancelerのインターフェース仕様を満たしています,Goはこのように埋め込んだ構造体、インターフェースが持っている関数を直接呼び出すことができます。
- 一方cancelは埋め込んだcancelCtxのcancelを呼び出しつつ、 タイマーを掃除するtimerCtx独自のものが実装されています
- 472行目〜 DeadLine()が実装されています emptyCtxと比較すると0値でない値が取得できていることがわかります cancelCtxは独自のDeadline関数を持たず、埋め込まれた親コンテキストのDeadlineを呼んでいます
- 476行目から、timerCtxのString関数が実装されています。思ったより素朴に文字列が+演算子で結合されています。
- 496行目からWithTimeout関数が実装されています。実装を見てみると、WithDeadLineのラッパー関数である事がわかります。
- timerCtxについては以上です、続いて最後のcontextであるvalueCtxの説明に入ります。510行目からWithValue関数が定義されています。親コンテキストと、key, valueを受け取り、任意の値をもったvalueCtxを返却します。
- valueCtxは親Contextとkey, valを持った比較的シンプルな構造体です、keyもvalも空のinterfaceです
- valueCtxも独自のString()関数を持っています 敢えてfmtパッケージには依存せずに独自のstringify関数をもっています、unicode tablesに依存したくないとコメントがありますが、話が高度すぎて意図を完璧に理解できているか自信がありませんが。
- 実際にシンプルなコードで試してみましたが、fmtパッケージをインポートするとビルド結果が800KBほど大きくなりました
- ともかくこれで全てのcontextのString関数を読み込みました、ここで大事な事は、contextはプリントデバッグすると持っている情報を全て吐き出すという事です。一緒に働いている辻さんがブログにしてくれたのですが、GoのコードでLambdaを呼び出すときに、Contextに詰めた値を取り出そうとして取り出せず混乱した経験があります
- どういう事かというと、クライアント側でAWS Lambdaを起動するために呼び出す関数にcontextを渡すことができるのですが、そのcontextに詰めたValueがLambda上で動くコードでは消滅するのが仕様なのか否かを判断するのにそこそこ時間を使って調査したことがありました。 情報がプリントデバッグして無いなら無いんだ、と自信をもって判断して良い、という事が発表から伝われば幸いです。
- さてcontextの実装の話に戻ります、562行目から、valueCtxの目玉機能のValue関数が実装されています、keyが一致したらvalを返すという、シンプルな実装ですね
- Valueに渡す値は==で一致するものであればなんでも良いですがcontextパッケージの内部実装ではint型の変数を○○keyの名称で用意して、そのポインタ型を利用する使い方が良く使われています。おそらくメモリ効率を考えるとこの手法が一番スマートです。
- ポインタ型を投げなくてももちろん動きます。文字列などでラフに値を取り出したいかkeyの重複を考慮せずに済む方が良いかで使い分けできます
- 最後に内部で呼び出されるvalue関数の実装をもって593行が終了です、keyがヒットするかemptyCtxにたどり着くまで無限に各context型のValueとほぼ同じことをします 再帰関数になりそうでならない実装です
- さて、これでcontextのコードリーディングは終了です、駆け足でしたが、これを読み込むことで何が勉強になるかを整理してみます。