Goのcontext.Contextはいつ使うべきか

概要

go 1.7からcontextパッケージが標準パッケージになりました。
タイムアウト、キャンセルなどのハンドリングができることから、ブロッキングする処理や外部APIリクエストなどを扱う時は基本的に第一引数に置くべきです。
またAPIやプロセス間通信のリクエストスコープの値を引き継がせる際にも利用されます。

例えばgoogleはAPIを叩くコードでは全ての関数にcontextが引数に存在します。

github.com

ブログでもこのように言っています。

At Google, we require that Go programmers pass a Context parameter as the first argument to every function on the call path between incoming and outgoing requests.

ref: Go Concurrency Patterns: Context - go.dev

一方でcontext.Valueになんでも詰め込めるため、汎用的な関数のインタフェースの引数として使うのは？という考え方もあります。

type Hoge interface {
    DoSomething(ctx context.Context)
}

こんな感じですね。引数になんでも詰め込めるので、簡単に共通のインタフェースを持たせることができます。

結論から言うとこの使い方は良くないです。今回はcontext.Contextの使う基準について考えてみます。

CircleCI 2.0 でworkflowを使ったtagからのデプロイ

概要

CircleCI 2.0でtagからのビルド＆デプロイをできるようにします。

主に使う機能としては

• workflow
• cache

です。workflowはビルドパイプラインのようなもので、実行ジョブを細かく分けて順に実行させることができます。

上の例ではmasterブランチにマージ後、testジョブが実行されてからdeploy_devというdev環境にデプロイするジョブが実行されています。

TerraformでNLBを使う

概要

先日新しいL4のロードバランサーであるNLBがAWSからリリースされました。
ALBはL7のロードバランサーであるため、これまでgRPCはCLBの方でしか利用できませんでしたが、これからはNLBを使うことで対応が可能です。
terraform-provider-awsの1.3.1から利用できるようになったので（1.3.0はバグが有りました）、その使い方を紹介します。

環境

• terraform 0.11.0
• terraform-provider-aws 1.3.1

前提知識

NLBはこれまでのCLBやALBと幾つか仕様が異なるため、それを理解していないと躓きます。
特にSecurityGroup周りが大きく違っていて、以下のことを知っていないと疎通がうまく行きません。

Travis CIのslack通知のtokenを暗号化

概要

publicなリポジトリもslack通知させたいけど、slackのtokenが見えるのは嫌なので暗号化して設定する方法です。

環境

• travis 1.8.8

CLIのインストール

Travis CIが出しているコマンドラインツールをインストールします。

$ gem install travis --no-rdoc --no-ri

BLPOPで優先順位を付けてタスクキューを実行

概要

タスクキューを操作する時に、特定の処理が他の処理よりも先に実行できるよう優先順位を付けたいケースがあります。
RedisのBLPOPは複数のリストを処理してくれるのでそれを実現できます。

前提

以下の優先度を決めたキューがあるとします。

キュー名	優先度	入ってるタスク
queue:high	高	ht1, ht2, ht3
queue:middle	中	mt1, mt2, mt3
queue:low	低	lt1, lt2, lt3

データ毎に実行スケジュールが異なる場合の実装方法を考えてみる

概要

Stripeの定期購読を使っていると、各ユーザの定期購読の更新タイミングでWebhook eventがちゃんと飛んできます。
ほぼリアルタイムで届くのでこのwebhookを使う側としては非常に助かる機能ですが、提供する立場から考えるとどうやるんだろう？と悩んだので幾つか自分でケースを考えてみました。

課題

今回やりたいことを実現する上で問題になるのは主に以下です。

• タイムスケジューラをどうするか
• データ量が増えたときにスケール可能か

cronのようなスケジューラだと、今回のような個々のデータに対するスケジューリングはできません。
またバッチ処理で扱おうとすると、データ量が増えた時に処理対象がどんどん増えるため、対象の抽出や処理自体に時間がかかって実行頻度を上げることが難しくなります。

手段

浮かんだのは以下の４つでした。

1. 全ユーザの更新期限を毎回チェックしてイベントを飛ばす
2. 更新日を迎えるユーザをあらかじめ別の場所に保持しておいて、それを定期的に処理
3. Redisのzsetを使う
4. Redis Keyspace Notificationsを使う

IAMグループのポリシーの管理

概要

IAMグループのポリシーをちゃんと役割に分けて管理しようという話です。

方針

admin, developer, operatorの３つの役割で分け、各グループに適切な権限を与えるようにします。
ただし

• パスワード変更
• MFAの設定

は各IAMユーザができるようにします。

付与する権限

グループ	権限
admin	AdministratorAccess
developer	PowerUserAccess IAMUserChangePassword AllowUsersToUseMFA
operator	ReadOnlyAccess IAMUserChangePassword AllowUsersToUseMFA