〜2度に渡る受験と合格までの経緯〜

こんにちは。ARIGATOBANK の丸山です。主にバックエンド開発を行っております。

Google Cloud 認定 Professional Cloud Architect 試験に合格しましたのでそれまでの経緯、勉強内容や感想などを綴りたいと思います。

Professional Cloud Architect とは

公式から引用しますと、

「Professional Cloud Architects は、組織が Google Cloud 技術を利用できるように支援します。クラウドアーキテクチャと Google Cloud に関する専門的な知識を活かして、ビジネス目標を実現するために、スケーラブルで高可用性を備え、堅牢かつ安全な動的ソリューションを設計、開発、管理します。」

とのことです。

詳しくは公式の案内をご参照ください。

試験を受けたきっかけ

本試験を受けるきっかけとしてはGoogle Cloud Japan 主催の Google Cloud Innovators Gym Japan (G.I.G Japan)というGoogle Cloud のスキル習得のための招待制のプログラムを受けた事から始まります。

上記プログラムでは主に Cousera で提供される学習コースを受講し、期間中の各セッションで学習内容の説明や質疑応答などでスキルや知識を深めます。

最終的に以下のいずれかの認定資格の取得を以てプログラム修了と認められるため、資格の取得を目指しました。

• Professional Cloud Architect
• Professional Cloud Developer
• Professional Data Engineer

私自身は主にアプリケーション開発がメインなので実務的には Professional Cloud Developer が近い内容なのですが、上記プログラムで習得出来るスキルに近いとのことだった Professional Cloud Architect の取得を目指しました。

Professional Cloud Architect 受験に向けた勉強内容

まずは公式の模擬試験を問いてみました。

Couseraで学習した内容などが出題されますが、選択式の回答がどれも合っているように思えたり、逆にどれも間違ってるように思えたりして初めは正答率は50%くらいでした。。

次に オンライン学習コンテンツを利用し、こちらの問題集をやり込むことにしました。（私はUdemyを利用しましたが、公式からも Cloud Skills Boost というコンテンツが提供されているようです ）

問題集は全170問あるため全て正解しようと思うとなかなかシビれます。

不合格

受験方法は

• 遠隔監視オンライン試験
• テストセンターでオンサイト監視試験

の2パターンあり、遠隔監視オンライン試験は自宅でも受験出来るようですが、試験環境を整えられるか不安だったので、テストセンターでオンサイト監視試験で受験する事にしました。場所はテストセンター秋葉原昭和通。

しかし1度目の Professional Cloud Architect 試験は不合格となりました。。

試験終了後すぐに合否がわかるのですが不合格が表示された瞬間、その場で自分が数分フリーズしていたのを覚えています🫥

不合格の場合、2週間は同じ試験を受けることができないため期間的にG.I.Gプログラムは未修了という事が確定。。

メンタルはズタボロです。

しかしここで腐らず再起を誓い、しっかり準備して次の受験に備えることを決めます。

2度目の Professional Cloud Architect 受験に向けた勉強内容

公式の模擬試験、こちらは何度やっても正答率100%になるまでやり込みました。

オンライン学習の問題集、こちらも正答率100%になるまでやり込もうと意気込みましたが、全170問はなかなか厳しく、前日の時点で94%程度。

しかしこれだけやり込んでおけば大丈夫だろうと、1度目の受験に比べかなりの自信を持って試験当日を迎えます。

合格

1度目の試験から約2ヶ月を空け、今回も1度目と同様のテストセンターでオンサイト監視試験で受験。

今回は見事合格！

試験終了後、すぐに合格が表示されましたが、嬉しさと興奮で今回も自分が数分フリーズです🫥

Cousera の内容を理解し、出題傾向を完全に把握するという当たり前ながら大変なハードルを超えられたことは自分の自信に繋がり、実務にも価値のあるスキルが得られた（はず）と思います。

最後に

総勉強時間は約20〜25時間くらい( Cousera は除く)。自分はどちらかというと開発の人間なので上記の勉強時間でしたが、実務で Google Cloud を普段から活用している方ならもっと短い勉強時間で合格出来ると思います。

合格に向けて勉強していくことで実務でまだあまり触れていない部分（ネットワーク関連、コンプライアンス関連、データ転送関連など）についても知識を得られた事が自分にとって特に有益だったと感じました。

今回の合格だけで満足せず、次の資格取得、スキル取得に向けて頑張っていきたいと思います！

余談ですが、Google Cloud 認定試験に合格すると頂ける品物が色々あるのですが、自分は使い勝手良さそうなこちらのバックパックにしました。こういった手元に残る品物を頂けるのも嬉しいですね。

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムをすべて Google Cloud で開発・運用しています。今後も「お金で困っている人をゼロにする」世界を実現するために Google Cloud をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

Google Cloud 認定 Professional Cloud Architect 合格記 was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

この記事は Go Advent Calendar 2023 7 日目の記事です。

こんにちは。ARIGATOBANK バックエンドエンジニアの富樫です。

私たちのチームでは、バックエンドシステムのすべてを Go 言語で構築しています。これまでロギングライブラリとして主に zap を利用してきましたが、最近 Go 1.21 で追加された log/slog を本番環境の一部サービスで利用し始めました。

この記事では、log/slog を開発や本番環境へ投入するにあたってカスタマイズした実装の詳細について共有します。

log/slog とは

Go 1.21 で標準ライブラリに加わった log/slog は、構造化ロギングをサポートするログパッケージです。

slog package — log/slog — Go Packages

基本的な使い方はこんな感じです。

package main

import (
  "log/slog"
  "os"
)

func main() {
  slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stdout, nil)))
  slog.Info("hello, world!", slog.String("user", "gopher"))
}

実行すると以下のように出力されます。

{"time":"2023-12-03T16:56:12.194852+09:00","level":"INFO","msg":"hello, world!","user":"gopher"}

これまで構造化ロギングには logrus 、zap、zerolog などのサードパーティライブラリが利用されてきました。Go の標準ライブラリには初期から log パッケージがありますが、基本的な機能の提供に留まります。構造化ロギングの重要性の高まりや、大規模なプログラムにおいて複数ログパッケージの混在による一貫したログ出力の難しさなどの課題を受けて、今回新たに標準ライブラリとして追加されました。
（参考: Structured Logging with slog）

log/slog の API は、フロントエンドの Logger とバックエンドの Handler に分かれています。共通のバックエンドである Handler を標準ライブラリとして提供することで、既存のログパッケージを含めて相互運用可能になっています。また、context.Context 型を標準でサポートし、Handler でコンテキスト情報を抽出できるなど、後発パッケージならではの設計がなされています。

log/slog を利用したログ出力実装の詳細

開発および本番環境への投入に向けて、Google Cloud や OpenTelemetry との統合を実現する必要がありました。そこで、log/slog を利用して以下の 3 つを実装しました。

• Cloud Logging と既存の zap 構成との互換性を保つ ReplaceAttr 関数
• OpenTelemetry の TraceID と SpanID を Cloud Logging の指定フィールドに埋め込む Handler
• 既存ログモジュールと互換性のある独自ログ出力関数

最終的には以下のコードに対して次のような出力が得られる実装になりました。

// ハンドラの設定
slog.SetDefault(slog.New(NewHandler("foobar")))

// ログ出力
Info(ctx, "Hello, ARIGATOBANK Tech Blog!", slog.String("user", "gopher"))

{
  "time": "2023-12-04T08:48:47.220523+09:00",
  "severity": "INFO",
  "caller": "sample/main.go:25",
  "message": "Hello, ARIGATOBANK Tech Blog!",
  "user": "gopher",
  "logging.googleapis.com/trace": "projects/foobar/traces/8416afb165e7189003dce7f8617c17ba",
  "logging.googleapis.com/spanId": "9620652c5aabf556",
  "logging.googleapis.com/trace_sampled": false
}

以下で各実装について詳しく説明します。

slog.HandlerOptions.ReplaceAttr の実装

ReplaceAttr はログ出力の直前に呼び出される関数で、フィールドの変換や削除に利用します。

ここで実装したのは 2 つです。1 つは Cloud Logging の構造化ロギングにおける 特別な JSON フィールド への対応、もう 1 つは既存のログモジュールで利用していた zap の構成との互換性を維持する対応です。

具体的には以下のように実装しています。

func NewHandler(projectId string) *Handler {
  opt := slog.HandlerOptions{
    AddSource:   true,
    ReplaceAttr: replaceAttr,
  }
  return &Handler{
    Handler:      slog.NewJSONHandler(os.Stderr, &opt),
    GcpProjectId: projectId,
  }
}

func replaceAttr(groups []string, a slog.Attr) slog.Attr {
  switch a.Key {
  case slog.LevelKey:
    // Cloud Logging 対応: level -> severity
    return slog.String("severity", getSeverity(a.Value.Any().(slog.Level)))
  case slog.MessageKey:
    // Cloud Logging 対応: msg -> message
    return slog.Attr{Key: "message", Value: a.Value}
  case slog.SourceKey:
    // zapcore.ShortCallerEncoder 相当
    return slog.Any("caller", getCaller(a.Value.Any().(*slog.Source)))
  }
  switch a.Value.Kind() {
  case slog.KindDuration:
    // zapcore.StringDurationEncoder 相当
    return slog.String(a.Key, a.Value.Duration().String())
  }
  return a
}

slog.Handler.Handle の実装

Handler はログ出力の実体を担うインターフェースです。カスタマイズとしては、標準ライブラリが提供する slog.JSONHandler などに出力を任せつつ、出力したいフィールドを追加する機能などをここに実装していくことになるでしょう。

特に slog.Handler.Handle は context.Context 型が引数に入ってきます。私たちのチームでは OpenTelemetry を利用しているので、SpanContext から TraceID や SpanID などを取り出してログに埋め込む機能を実装しました。ここでも Cloud Logging の特別な JSON フィールドに出力し、Cloud Trace の Trace や Span と紐づくようにしています。

type Handler struct {
  slog.Handler
  GcpProjectId string
}

const (
  keyGcpTrace        = "logging.googleapis.com/trace"
  keyGcpSpanId       = "logging.googleapis.com/spanId"
  keyGcpTraceSampled = "logging.googleapis.com/trace_sampled"
)

func (h *Handler) Handle(ctx context.Context, r slog.Record) error {
  if h.GcpProjectId != "" {
    spanCtx := trace.SpanContextFromContext(ctx)
    if spanCtx.IsValid() {
      r.AddAttrs(
        slog.String(keyGcpTrace, fmt.Sprintf("projects/%s/traces/%s", h.GcpProjectId, spanCtx.TraceID().String())),
        slog.Bool(keyGcpTraceSampled, spanCtx.IsSampled()),
        slog.String(keyGcpSpanId, spanCtx.SpanID().String()),
      )
    }
  }

  return h.Handler.Handle(ctx, r)
}

独自のログ出力関数を定義する

log/slog では、各ログレベルごとに context.Context 型の引数を取る関数と取らない関数が用意されています。例えば Info レベルのログ出力関数として以下の 2 つがあります。

func InfoContext(ctx context.Context, msg string, args ...any)
func Info(msg string, args ...any)

しかし、開発者にとってはどちらを使うべきか迷いが生じたり、誤って Context を引数にとらないメソッドを利用し TraceID が出力されないといった不具合に繋がる可能性があります。 私たちのチームでは以前から Logger ライブラリを社内で独自に整備していたこともあり、log/slog の利用においても以下のようなログ出力関数を独自に定義することにしました。

func Info(ctx context.Context, msg string, args ...any)
func Infof(ctx context.Context, format string, args ...any)
// 他のログレベルの関数も同様

ここで問題になるのが、出力に含まれるファイル名や行番号の取得です。これらの独自関数から単純に slog.InfoContext などの関数を呼び出すと、ログ出力元のファイル名や行番号として独自関数の定義位置が出力されてしまいます。

この問題については log/slog のパッケージドキュメントにも言及があり、解決策が Example に示されています。ドキュメントに沿って以下のように実装しました。

func Info(ctx context.Context, msg string, args ...any) {
  log(ctx, slog.LevelInfo, msg, args...)
}

func log(ctx context.Context, level slog.Level, msg string, args ...any) {
  logger := slog.Default()
  if !logger.Enabled(ctx, level) {
    return
  }

  var pcs [1]uintptr
  runtime.Callers(3, pcs[:]) // Skip(3): Callers, log, Debug[f]/Info[f]/Warn[f]/Error[f]/Fatal[f]

  r := slog.NewRecord(time.Now(), level, msg, pcs[0])
  r.Add(args...)

  _ = logger.Handler().Handle(ctx, r)
}

独自関数の導入には多少の迷いがあり、Go らしく Linter を実装して利用する関数を強制することも検討しました。最終的には slog.InfoContext などの名前がほんのちょっとだけ長いと感じたことや、既存の使い勝手を維持したいという考えから導入を決めました。

また、これらの関数は、実質的には slog の Handler を呼び出す実装でしかありません。いざとなれば slog.InfoContext などの標準ライブラリの関数を使えますし、それにより出力内容に影響を与えることはありません。この柔軟性に気付いたとき、log/slog の設計の巧妙さに改めて感心しました。

今後の log/slog に期待すること

log/slog が標準ライブラリに追加されたことにより、ログ出力の共通バックエンドとしてのインターフェースが標準化されました。

今後は各 Observability バックエンドが Handler や ReplaceAttr 関数の実装を提供し、開発者にとって適切なログ出力の実装が容易になることを期待しています。OpenTelemetry における instrumentation のようにエコシステムが充実すると良いですね。

例えば Cloud Logging のフィールドに対応する Handler や ReplaceAttr 関数が Google Cloud 自身のメンテナンスによって公開されることを期待したいです。

まとめ

この記事では Go 1.21 で新しく標準ライブラリに加わった log/slog の本番環境投入にあたって実装した内容について紹介しました。これから log/slog の利用を検討している方にとって、参考になる情報があれば幸いです。他にもこういう実装を slog でやってみたよ、という話があればぜひ教えてください。

参考資料

• log/slog パッケージドキュメント
• Structured Logging with slog
• A Guide to Writing slog Handlers
• A consistent logging format for Go
• Structured logging | Cloud Logging
• Cloud Logging 構造化ログの特別な JSON フィールドまとめ

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムをすべて Go で開発しています。今後も「お金で困っている人をゼロにする」世界を実現するために Go をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

Go 1.21 で追加された log/slog を本番環境に実戦投入しました was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

11月15日(水)・16日(木) 東京ビッグサイトで開催される「Google Cloud Next Tokyo ‘23」にて、ブレイクアウトセッションのスピーカーとして登壇します。

Google Cloud Next Tokyo ’23 について

このイベントは、公式サイトにもあるように、Google Cloud の最新情報や実践的な活用事例を学べるカンファレンスです。

生成 AI からセキュリティ、アプリケーション開発、データ分析に至るまで、多岐にわたるセッションやハンズオンが企画されており、参加者にとってはボリューム満点の 2 日間となっています。

昨年の Google Cloud Next Tokyo ’22 はオンラインでの開催でしたが、今回のイベントは 4 年ぶりのリアル開催です。

私は 11月16日(木) DAY2 の 16:00–16:30 のブレイクアウトセッションに登壇いたします。

セッションの内容について

今回のセッションは「Cloud Spanner の Fine-grained Access Control と BigQuery の Federated Query で作るコスト パフォーマンスに優れたリアルタイム分析基盤」です。ARIGATOBANK が実際に構築したリアルタイム分析基盤のアーキテクチャと構築過程を中心にお話しします。

Cloud Spanner における BigQuery へのデータ連携はなかなか悩ましい点がありました。現状 Datastream は未サポートであり、Change streams を利用した Dataflow のストリーミングパイプラインはデータベース数の増加とともにコストも高まります。多くの方が同じ悩みを感じているかもしれません。

ARIGATOBANK では Google Cloud のカスタマーエンジニアとの連携や、さらには Cloud Spanner の新機能リリースタイミングなども幸いし、最終的には Cloud Spanner の Fine-grained Access Control と BigQuery の Federated Query を組み合わせるアプローチを採用しました。結果として高いコストパフォーマンスのリアルタイム分析基盤を実現できました。

このセッションでは、分析基盤のアーキテクチャの詳細や構築過程、さらには Google Cloud へのフィードバックを通じた協業の成果を紹介いたします。特にアーキテクチャ部分は、多くの方にも参考にしたいと感じていただける内容となっていると思います。ぜひご聴講ください。

セッションの後には Ask the Speaker という来場者からの質疑応答ブースが設けられています。質問やフィードバックがある方は、この機会にぜひ直接ディスカッションできれば幸いです。

さいごに

Google Cloud Next Tokyo ’23 は、Google Cloud の最新情報や活用事例を学べる機会として非常に価値のあるイベントです。ARIGATOBANK としても、自社での取り組みや成果を共有し、参加されるみなさんと知識や経験を共有できることを楽しみにしています。

イベント当日は、データベースに関するセッションやその他の興味深いトピックに関するセッションも盛りだくさんです。私も特に「Google における次世代データベースの構築 〜 Cloud Spanner の内側 〜」のセッションに注目しています。興味を持たれた方は、ぜひこちらもチェックしてみてください。

多くのみなさまのご参加を心からお待ちしています。

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムをすべて Google Cloud で開発・運用しています。今後も「お金で困っている人をゼロにする」世界を実現するために Google Cloud をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

Google Cloud Next Tokyo ’23 にて Cloud Spanner × BigQuery をテーマに登壇します was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Google Cloud Japan 様よりご招待頂き、第6期 Google Cloud Innovators Gym Japan (G.I.G Japan)に参加し修了しましたので、プログラムの内容やを記事にします。

G.I.G プログラムとは

Google Cloud が主催する、エンジニアに向けた Google Cloud スキルを習得のための招待制のトレーニングプログラムです。Google Cloud Innovators Gym の略で、約 3 ヶ月間のトレーニングを通じて、Google Cloud の基礎知識を習得し、Google Cloud 認定資格を取得することを目指します。

トレーニングは以下の 2 つの学習コンテンツで構成されています。

• 集合形式のオンラインセッション
• Coursera を使ったオンライン自習

また、トレーニングの修了には以下のいずれかの Google Cloud Certificate 試験の取得が必要です。

• Professional Cloud Architect
• Professional Data Engineer
• Professional Cloud Developer

トレーニング参加前の私の状況

私は Google Cloud Certificate 試験のうち、「Professional Cloud Architect」と「Professional Data Engineer」2つの資格を取得したことがあり、「Professional Cloud Developer」を取得しようとトレーニングに参加しました。

実務面でも、ARIGATOBANK ではサービスの提供基盤として Google Cloud を利用し、Google Kubernetes Engine や Cloud Run などのサービスを利用しており、Google Cloud に初めて触れるわけではありませんでした。

しかし、サービス概要は理解していましたが Google Kubernetes Engine や Cloud Run などの構築経験は少なく、ベストプラクティスに沿った設計や具体的な設定方法について学びたいと思いトレーニングに参加しました。

セッション

集合形式のオンラインセッションは合計3回あり、Google Cloud のエンジニアによるプロダクト紹介やハンズオンを行います。

それぞれ以下のような内容でした。

• Google Cloud のサーバーレス ソリューション
• Google Cloud のデータベース ソリューション
• Google Cloud の CI / CD ソリューション

プロダクト紹介では Google Cloud のサービス概要を網羅的に聴くことができます。
比較的新しいサービスや既存のサービスのアップデート情報なども聴くことができ、知らなかったサービスもあり情報を更新することができました。
ハンズオンでは実際に Google Cloud のコンソールを操作し、デモ環境の構築等を行いました。

また、セッションの後に懇親会も企画されており、興味のあるジャンルを選択し参加者同士でグループトークをしました。
私は普段の業務に近い「Web アプリ開発」を選択しましたが、他社の Google Cloud のサービス利用状況や、技術選定の方法などを貴重な話を聴くことができました。

Coursera

Coursera は、オンライン学習プラットフォームです。G.I.G の期間中 Google Cloud が提供している学習セッションを無償で利用できます。

また、受験予定の試験ごとにいくつか学習コースが用意されており、その中から最低5つのセッション受講が必要です。

私は「Professional Cloud Developer」試験を受験予定でしたので、主に以下の内容を重点的に受講しました。

• Google Cloud を使ったアプリケーション開発
• アプリケーションのデプロイ、デバッグ、パフォーマンス測定
• 認証と認可の設定、Pub/Sub, Cloud Function を使ったイベントドリブン処理
• Google Kubernetes Engine
• Cloud Run

特に Coursera を使った学習では、動画やテキストでの学習だけでなく、実際に Google Cloud のコンソールの操作ができます。
公式ドキュメントを読んでサービスの概要を知っていても、コンソールを操作し環境を構築、CLIで設定を変更するとより理解が深まり、「 Cloud Endpoints を使って OpenAPI をベースに API のエンドポイントを構築する」や「 Cloud Run Workflow を使ってバッチ処理を実行する」など、業務で使いたいと思うことがありました。

また、Google Cloud のベストプラクティスについても学ぶことができたので、業務環境として使っていた Google Kubernetes Engine や Cloud Run についても理解が深まりました。

Google Cloud Certificate 試験

最後に、Google Cloud Certificate Professional Cloud Developer 試験を受験しました。

G.I.G プログラムに参加することで試験の受験費用が無料になるクーポンがもらえるので、費用面では安心して受験することができましたが、試験の準備が遅く期日ギリギリのタイミングで試験を受験することになりました。

G.I.G プログラム修了のためには必ず期日までに試験に合格し、Google Cloud Certificate 認定を受けた上で認定コードを Google Cloud Japan に報告する必要があります。

不合格になった場合は2週間同じ試験を受けることができないため、受験そのもののプレッシャーに加えて1回で合格しなければいけない状況の中で試験を受けることになりました。

また、テストセンターで試験を受けてからGoogle Cloud Certificate 認定証がメールで届くまでには1週間以上かかることもあり、テスト受験後も期日までに認定証が届くかハラハラしながら過ごすことになってしまいました。

私は運良く試験に合格し、ギリギリのタイミングで認定コードを報告することができましたが、今後 G.I.G プログラムに参加される方は十分に余裕を持って試験を受けることをお勧めします。

まとめ

Professional Cloud Developer 試験を取得し、無事プログラムを修了することができました。
3ヶ月間のトレーニングを通じて、Google Cloud を使ったアプリケーション開発について学ぶことができ、当初知りたかったベストプラクティスや設定方法について学ぶことができました。

また、交流会等によって他社の技術選定の方法や、Google Cloud の利用状況などを聴くことができたのも予想外の収穫でした。

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムをすべて Google Cloud で開発・運用しています。今後も「お金で困っている人をゼロにする」世界を実現するために Google Cloud をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

Google Cloud Innovators Gym Japan (G.I.G Japan)プログラム参加レポート was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。ARIGATOBANK バックエンドエンジニアの富樫です。

今回は、Cloud Spanner における行削除の仕組みと、その挙動を認識していなかったために発生したクエリパフォーマンス(レイテンシ)悪化の事例、および対策についてお伝えします。

Cloud Spanner の行削除の仕組み

いきなり本題ですが、Cloud Spanner における行削除の仕組みは以下の通りです。

• Cloud Spanner では、削除された行はすぐにはデータベース上から物理的に削除されない
• 削除された行は非同期のガベージコレクションにより数日間維持された後に物理的に削除される
• 削除された行が物理的に削除されるまでの間、クエリは削除された行もスキャンする
• この挙動は内部メカニズムでありユーザーが制御できる点はない

削除した行がすぐには物理的に削除されない点は、マルチバージョン同時実行制御の仕組みを持つデータベースとしては一般的な挙動です。 Cloud Spanner でもこの仕組みが採用されていることはドキュメントから確認できます。

注意すべきは、ガベージコレクションされていない削除済みの行がスキャン対象となる点です。

これからお伝えするクエリレイテンシ悪化の事象は、削除済み行のスキャンが原因で発生しました。ここからはその事象を詳しく見ていきます。

発生した事象について

ARIGATOBANK のバックエンドシステムでは、マイクロサービスにおける分散トランザクションの整合性担保を Transactional outbox パターン を用いた実装で実現しています。

Message Relay コンポーネントは、Cloud Spanner にある Outbox テーブルからポーリングで未処理メッセージを取り出し、Pub/Sub に送信します。 メッセージの送信に成功したメッセージは処理済み時刻が設定され、次回のクエリでは参照されなくなります。

クエリパフォーマンスの悪化は、Message Relay における未処理メッセージを取り出すクエリで発生しました。

開発時はクエリの実行計画からインデックススキャンが適用されることを確認していましたし、運用当初はパフォーマンスに問題は見られませんでした。しかしながら、機能追加に伴い非同期メッセージの追加頻度が増えた時点からクエリの実行時間が顕著に延びていることに気づき、調査を開始しました。

調査から原因判明まで

Query Insights から、該当クエリの状況を確認しました。まず確認したのは以下の 2 点です。

• 改めて実行計画を確認し、インデックススキャンされている(フルスキャンになっていない)こと
• スキャン行数(Rows scanned)、および返された行数(Rows returned)が開発時の想定通りに抑えられていること

クエリレイテンシと CPU 実行時間のグラフは以下のようになっていました。

機能追加のタイミング以降、明らかにパフォーマンスが悪化しています。いくつか改善しているポイントがありますが、何か改善のアクションを取ったわけではありません。その後再び時間とともに悪化するという挙動でした。

また、検証のため開発環境にダミーデータを投入して同じクエリを実行しましたが、スキャン行数やレスポンスサイズが本番環境よりも大きい場合でもパフォーマンスに問題は見られませんでした。

この時点でテーブル行数の増加による影響であると見当をつけていました。しかしながら、インデックススキャンでスキャン行数が抑えられているにもかかわらずテーブル行数増加に伴いクエリのレイテンシが悪化する状況は、一般的なデータベースの挙動としては不可解です。

そこで、ここまでの事象や挙動、推測をもとに Google Cloud のサポートケースを作成し、レイテンシ悪化の原因調査について協力を仰ぎました。結果として「削除済みの行に対するスキャン行数の肥大化」が原因であると判明しました。

このとき Google Cloud のサポートチームから Cloud Spanner における行削除の仕組みについて説明があり、はじめて削除済みの行がスキャン対象となることを認識しました。

ガベージコレクションによって行が物理削除されると当然ながら削除済み行のスキャン行数は減少します。時折クエリレイテンシと CPU 使用率が改善しているのもガベージコレクションによるものと考えられ、すべての事象が説明できるようになりました。

削除済み行のスキャン行数を確認する

Cloud Spanner には Cloud Console の Web 画面から利用できる強力なパフォーマンス分析ツールが揃っています。 特にクエリのパフォーマンスは Query Insights や、クエリの実行計画を視覚化して確認できる クエリプランビジュアライザ から分析できます。

注意点として、削除済み行のスキャン行数は上記ツールの画面上には表示されません。削除済み行のスキャン行数は、画面に表示されたビジュアライザから実行計画を JSON 形式でダウンロードしたファイルに含まれています。

また、実行計画を取得する方法は 2 つあります。1 つはクエリの実行とともに実行計画を取得する方法(単に実行ボタンを押す場合)、もう 1 つは実行計画のみを取得する方法(下図の“説明のみ”を選択した場合)です。

いずれの場合も JSON がダウンロードできますが、実行計画のみを取得した場合はスキャン行数などの情報が含まれない点に注意してください。

また、コマンドラインクライアントの spanner-cli でも実行計画とともにスキャン行数などの情報を取得できます。

% spanner-cli -p PROJECT_ID -i INSTANCE_ID -d DATABASE_ID -t -e 'EXPLAIN ANALYZE SELECT ...'

...

3 rows in set (309.74 msecs)
timestamp:            2023-09-06T09:56:51.751186+09:00
cpu time:             474.42 msecs
rows scanned:         (スキャン行数) rows
deleted rows scanned: (削除済み行のスキャン行数) rows
optimizer version:    5
optimizer statistics: auto_20230905_03_39_08UTC

考察: インデックスの仕組み

さて、Cloud Spanner では GC されていない削除済みの行がスキャン対象となることがわかりましたが、今回パフォーマンス悪化の発生したクエリはインデックススキャンでした。削除済みの行がスキャン対象となる挙動が、インデックススキャンに対してどのように影響を与えるのでしょうか。

今回インデックススキャン対象に削除済みの行が含まれていた点から察するに、セカンダリインデックスの内部表現は、インデックス対象列を PK として保持するテーブルにより実装されていると考えています。

対象のテーブルに行が INSERT されると、対応するインデックスがインデックステーブルに INSERT されます。

インデックスに含まれる値が UPDATE された場合、古い値に対応したインデックスはインデックステーブルから DELETE され、新しい値に対応するインデックス行が新たに INSERT されます。この挙動は UPDATE 時のミューテーション数からも推測できます。UPDATE ではなく DELETE と INSERT なのは、インデックスが対象列を PK としているためと考えています。

このときインデックステーブルから DELETE されたインデックス行は、非同期のガベージコレクションにより数日間維持されます。この間、インデックススキャンの対象となります。

改めて、今回のレイテンシ悪化の事例におけるインデックススキャンへの影響を考えます。

未処理メッセージを取り出すクエリは、処理済み時刻が未設定の行を SELECT します。処理済み時刻はインデックスに含まれるため、これはインデックススキャンです。

Message Relay は処理したメッセージに処理済み時刻を設定して UPDATE します。このとき「処理済み時刻が未設定」時点の行に対するインデックスは DELETE されるものの、ガベージコレクションされるまでは「削除済みの行」として残り続けます。これがインデックススキャンの対象となったと考えています。

削除済み行のスキャンへの対策

対策としては、削除済みの行に対してもスキャン範囲を限定するようなクエリが有効です。

今回の事例では Message Relay の実装を以下の通り修正しました。

• Outbox テーブルのインデックスに、最終更新時刻のカラムを追加
• 一定時間ごとに Outbox テーブルの未処理メッセージから最も古い最終更新時刻(t)をもつ行を取得
• Outbox テーブルから未処理メッセージを取り出すクエリに「最終更新時刻 が t 以降」の条件を追加

結果として、削除済みの行に対するスキャン行数が常に一定以下に抑えられ、 パフォーマンスが改善しました。

まとめ

今回は Cloud Spanner で発生したクエリパフォーマンス悪化の事例をもとに、Cloud Spanner における行削除の仕組みについてお伝えしました。

削除済みの行がスキャン対象になる点は、この記事を書いている 2023–09–25 時点では Cloud Spanner のドキュメントに記載されていません。今後ドキュメントに記載されることを期待したいです。また、削除済み行のスキャン行数もクエリプランビジュアライザの UI に表示されるといいですね。（どちらも Google Cloud にはフィードバック済みです）

それまでの間はこの記事が、同じくクエリパフォーマンスに問題を抱えている方の参考になれば幸いです。

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムのデータベースに Cloud Spanner を全面的に採用しています。今後も「お金で困っている人をゼロにする」世界を実現するために Cloud Spanner をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

知っておきたい Cloud Spanner の行削除の仕組み: クエリパフォーマンス悪化の事例 was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

時間があいてしまいましたが、先日 6月23日（金）に Google Cloud Japan 様よりご招待頂き「第 3 回 Digital Native Leader’s Meetup」に参加してきました。この記事では参加レポートとして、イベントの内容を振り返っていきます。

Digital Native Leader’s Meetup とは

Google Cloud Japan 主催の招待制オフライン Meetup イベントで、普段から Google Cloud を利用している現場のエンジニアや、リモート越しにサポートいただいているカスタマーエンジニアの方々が集まり、Google Cloud 活用の知見や事例についてオフラインで語り合える場です。

会場は前回同様 Google 渋谷オフィスでした。

イベントは Beer Bust 形式で、軽食やドリンクがたくさん準備されていると事前に聞いていたので、その辺りもとても楽しみに行きました。

色とりどりのとても美味しそうな軽食・・・・！だったのですが、LTの枠を頂いていて極度に緊張しており、軽食はほとんど喉を通りませんでした。

イベント内容

今回のテーマは「データベース」で、Spanner や Cloud SQL、 AlloyDB などをテーマとして、参加者によるアンカンファレンス形式で進行されます。

ARIGATOBANK のバックエンドシステムは Cloud Spanner を活用しており、なにか新しい情報や知見を得つつ、他の参加者の方にも良い知見をフィードバックできると良いなと思い参加しました。

ロードマップセッション

このセッションでは、Google Cloud が提供するデータベースに関する今後の機能について紹介がありました。

Google Cloud ではいくつかのデータベースソリューションが提供されていますが、それぞれの今後出てくる新機能や方向性等について説明がありました。弊社でも活用できそうなものがいくつかあり、リリースされたら検証を進めていきたいです。（やはり、Cloud Spanner に力を入れているという印象が強かったです。）

ライトニングトークセッション

ライトニングトークは Google Cloud を活用している企業のセッションが２つ（うち１つが私）と、Google Cloud の方のセッションでした。

Database Migrate Service を使って AlloyDB に移行した事例

Cloud SQL の PostgreSQL から AlloyDB に Database Migrate Service に移行した事例についてご紹介頂きました。

データベースの移行はダウンタイムをどれだけ短くできるかが重要且つ最も難しい点だと考えていますが、この移行ではダウンタイムは30秒程度に抑えられていて、素直にすごいなと思いました。

今後弊社でもシステム構成の最適化を進めていく中でデータベースの移行を行うタイミングが来るかもしれないので、ソリューションの１つとして非常に興味深かったです。

はじめて Spanner を使ってみた1年間

というタイトルで、Spanner についてLTをさせて頂きました！

Spanner のスケーラビリティがいかに素晴らしいか、弊社のトラフィック特性や全員お金贈り等の経験を踏まえてご紹介させて頂きました。

ARIGATOBANK では Spanner のスケーラビリティを最大限活用し、絶壁のようなトラフィックに備えて予め大規模にスケールアウトし、トラフィックが落ち着いたらアグレッシブにスケールダウンする運用を日頃からしています。直近では以前より更に細かくスケールの調整を行っていたり、オートスケーラーの導入を進めてます。

LT自体はひどい緊張で呼吸するタイミングを失ったりしたのですが、内容についてはまた別の記事で改めて紹介できればと思います。

Cloud Spanner はじめの 1 歩

Google Cloud の Database Specialist の方から、Cloud Spanner の紹介と、実際に触ってみるはじめの１歩についてのセッションでした。

90日間使える無料インスタンスについて、負荷試験やトランザクションの挙動を検証するのには不向きである話だったり、ドキュメントの歩き方についての話だったりと日頃 Cloud Spanner を使っていても勉強になるトピックは多かったです。

アンカンファレンスセッション

アンカンファレンスセッションでは参加者を「課題解決したい」人と「課題発見したい」人に大別し、活発にコミュニケーションが生まれるようにルールが設定されてグループ毎にディスカッションを行いました。

私がいたグループでは Cloud Spanner の導入を検討している方が多く、実際に使ってみた側として色々とお話させて頂きました。やはり Cloud Spanner のスケーラビリティやパフォーマンスに興味がありつつ、コスト面が気になるという方が多かったです。

（Google 様のイベントではあったものの）コスト面は高いは高いという話をしました！一方でかなり細やかにスケールができるので、ちゃんとコントロールさえすれば高いスケーラビリティや運用コストなど、 Cloud Spanner ならではのメリットを享受できるバランスには十分なり得るのではないかと考えています。

マルチリージョン構成への無停止変更など、出来ないと思っていたことが実はできるようになっていたという話や、よりパフォーマンスが良くなりそうな機能の話などを聞くこともでき、和やかな雰囲気で話ができとても楽しかったです。

最後に

「第 3 回 Digital Native Leader’s Meetup」に参加させて頂いたので、イベントレポートとしてまとめました。

他社がどんな課題に対してどんな取り組みをしていてどんな悩みを持っているのか、普段なかなか生の声を知ることができません。こういった情報をただ読む・聞くのではなく、情報交換できる機会はやはり貴重ですし、とても良い刺激になりました。

今後もこういった機会には積極的に参加してプロダクトの改善に繋げていければと思います。

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムをすべて Google Cloud で開発・運用しています。今後も「お金で困っている人をゼロにする」世界を実現するために Google Cloud をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

Google Cloud Japan 主催 “第 3 回 Digital Native Leader’s Meetup” 参加レポート was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。ARIGATOBANK バックエンドエンジニアの富樫です。

この記事では、Go で Printf のようなフォーマット引数をとる関数を自作した場合に、静的解析で引数の正しさをチェックするための実装方法について紹介します。

Printf 関数と静的解析

Go の fmt.Printf や fmt.Sprintf、ユニットテスト時に利用する t.Logf などのフォーマット引数は、 go vet を使った静的解析によって引数の正しさをチェックできます。たとえば以下のコードに対して go vet を実行すると、fmt.Printf のフォーマット文字列に対する引数の誤りが検出されます。

fmt.Printf("hello, %d", "world")
fmt.Printf("hello, %s, %s", "world")

% go vet ./...
./main.go:6:2: fmt.Printf format %d has arg "world" of wrong type string
./main.go:7:2: fmt.Printf format %s reads arg #2, but call has 1 arg

Visual Studio Code などの IDE を利用していれば、コードを書いている時点でフォーマット引数の指定が正しいかどうかチェックされている場合が多いはずです。

自作ログ出力ライブラリの引数に対して静的解析をかける

ARIGATOBANK のバックエンドチームでは、Go のアプリケーションログを出力する Logger ライブラリを社内で独自に整備し利用しています。

Logger 関数のシグネチャは以下のとおりです。各種ログレベルに対して、メッセージとキーバリュー形式の任意の引数を取る関数、および Printf のようなフォーマット引数を取る関数が定義されています。

func Debug(ctx context.Context, msg string, keysAndValues ...interface{})
func Debugf(ctx context.Context, format string, v ...interface{})
func Info(ctx context.Context, msg string, keysAndValues ...interface{})
func Infof(ctx context.Context, format string, v ...interface{})
func Warn(ctx context.Context, msg string, keysAndValues ...interface{})
func Warnf(ctx context.Context, format string, v ...interface{})
func Error(ctx context.Context, msg string, keysAndValues ...interface{})
func Errorf(ctx context.Context, format string, v ...interface{})
func Fatal(ctx context.Context, msg string, keysAndValues ...interface{})
func Fatalf(ctx context.Context, format string, v ...interface{})

これらの自作 Logger ライブラリに定義した Debugf や Infof といったフォーマット引数を取る関数に対しては、前述のような静的解析が働いていませんでした。引数を誤って実装すること自体は少ないのですが、それゆえに動作確認やコードレビューでも比較的漏れがちで、稀に不具合を埋め込んだままリリースに至ってしまう場合もありました。

実はこのような関数でも、関数の先頭で fmt.Sprintf のような標準ライブラリの関数をダミーで呼び出す実装を加えることで、静的解析の対象となります。

func Infof(ctx context.Context, format string, v ...interface{}) {
  if false {
    _ = fmt.Sprintf(format, v...)
  }
  // ...
}

同様に go vet による静的解析でフォーマット引数の正しさをチェックすると、以下のように引数の誤りが検出されます。

log.Infof(ctx, "hello, %d", "world")
log.Warnf(ctx, "hello, %s, %s", "world")

% go vet ./...
./main.go:11:2: github.com/arigatobank/*****/log.Infof format %d has arg "world" of wrong type string
./main.go:12:2: github.com/arigatobank/*****/log.Warnf format %s reads arg #2, but call has 1 arg

もちろん外部のモジュールをインポートした場合でも有効です。また、Visual Studio Code のような IDE による静的解析結果にも反映されます。

printf Analyzer について

この静的解析は、go vet に標準で備わっている静的解析器のうち、printf Analyzer によって実装されています。

% go tool vet help
...
    printf       check consistency of Printf format strings and arguments
...

printf Analyzer については go doc に詳細なドキュメントがあります。

printf package — golang.org/x/tools/go/analysis/passes/printf — Go Packages

printf Analyzer は、fmt.Printf や fmt.Sprintf などの関数およびそれらを呼び出す関数に対して静的解析が適用されます。一方で、動的メソッド呼び出しなどが挟まっている場合は検出できません。

今回の自作 Logger ライブラリの関数は、内部の Logger 実装をインターフェース化して差し替え可能にしていました。このため解析対象になっていなかったのですが、fmt.Sprintf の呼び出しを加えることにより解析対象となり、フォーマット引数の誤りを検出できるようになりました。

また、ダミー呼び出しを実装する以外に、-funcs フラグで printf Analyzer の解析対象に追加できます。go vet から呼び出す場合は -printf.funcs フラグとなります。

func Foo(ctx context.Context) {
  myPrintf(ctx, "hello, %d", "world")
  myPrintf(ctx, "hello, %s, %s", "world")
}

func myPrintf(ctx context.Context, format string, v ...interface{}) {
 // ...
}

% go vet -printfuncs myPrintf
./main.go:8:2: sample.myPrintf format %d has arg "world" of wrong type string
./main.go:9:2: sample.myPrintf format %s reads arg #2, but call has 1 arg

今回は引数を与えずとも標準的に解析対象にできる方法として、ダミーの fmt.Sprintf 呼び出しを加える方法を選択しました。

なお、printf Analyzer の内部挙動については、以下の動画でコードリーディングを通して詳しく解説されています。analysis パッケージを利用した静的解析周りの実装の知識が少し必要ですが、analysis.Fact インターフェースの使い方などを含めて非常に興味深い内容でした。

まとめ

今回は Go で Printf のようなフォーマット引数をとる自作関数の引数に静的解析をかける方法を紹介しました。静的解析が有効に働くだけで実装時の安心感が増します。また、コードレビュー時の CI による静的解析で、不具合を埋め込んだままリリースに至ることを防ぐことができるようになりました。

ARIGATOBANK のバックエンドチームでは、これ以外にも社内の実装ルールやライブラリの使い方に注意が必要なポイントなどを静的解析ツールとして実装しています。これらを Pull Request 時の CI に組み込み、より品質の高いコードをリリースできるようにしています。

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムをすべて Go で開発しています。今後も「お金で困っている人をゼロにする」世界を実現するために Go をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

Go で Printf のような自作関数の引数に静的解析をかける方法 was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

かなり間が空いてしまいましたが、3 月 24 日(金) に「第 2 回 Digital Native Leader’s Meetup」に参加してきました。この記事では参加レポートとして、イベントの内容を振り返っていきます。

Digital Native Leader’s Meetup とは

Google Cloud Japan 主催の招待制オフライン Meetup イベントです。会場は Google 渋谷オフィスでした。

普段から Google Cloud を利用している現場のエンジニアや、リモート越しにサポートいただいているカスタマーエンジニアの方々が集まり、Google Cloud 活用の知見や事例についてオフラインで語り合える場です。

イベントは Beer Bust 形式で、軽食（と聞いていましたが、実際はなかなかボリューム満点でした 😋）やドリンクをごちそうになりつつ、終始和やかな雰囲気で楽しめました。

イベント内容

今回のテーマはデータアナリティクスということで、BigQuery をはじめとしたデータ分析や BI 関連プロダクトを中心としたセッションとアンカンファレンスが行なわれました。

ちょうど ARIGATOBANK でもデータ分析基盤の構築・改善に力を入れているタイミングで、実践的な話が聞けるということで興味を持って参加しました。

アップデート＆ロードマップセッション

はじめに短いオープニングセッションの後、Google Cloud のアップデート情報と今後のロードマップに関するセッションと、最新技術トレンドに関するセッションがありました。

アップデート＆ロードマップのセッションでは、直近で発表のあった BigQuery の新しい価格体系や新機能をはじめ、現在プレビュー中のものから最近 GA になったばかりの機能まで、Google Cloud のデータアナリティクス領域に関する最新情報を聞くことができました。

紹介があった中では、特に Cloud Logging のバケット内を SQL で分析できる Log Analytics は、すぐにでも業務に活用できる機能だと感じました。単発の調査で Datadog だけではログを追いかけづらい状況でも、この機能を利用することで効率化できそうです。

最新技術トレンドセッション

最新技術トレンドは、データサイロとデータメッシュについてのセッションでした。データサイロとデータメッシュに関する説明と、Google Cloud でデータメッシュを構築するにあたりキープロダクトとなる Dataplex と Analytics Hub について紹介がありました。データサイロとデータメッシュについては、まだまだデータ分析基盤の構築過程にある ARIGATOBANK においては少し遠い話のように感じたのが正直なところです。ただ、今後プロダクトや組織の成長とともに増えていくデータに対する向き合い方について、とても参考になる話が聞けたと感じました。

Lightning Talk

セッションの後は Lightning Talk でした。参加企業のエンジニアや Google Cloud のカスタマーエンジニアが、データアナリティクス関連のプロダクトを具体的にどのように利用しているか、といった実践的な内容が聞けるセッションでした。内容は以下のとおりです。

• BigQuery の Remote Functions 機能を利用してビッグデータと大規模言語モデルの API を連携したレコメンドエンジンの構築例
• 社内外のデータ分析ニーズに対して Looker, Looker Studio をフル活用して応えている事例
• Google Cloud のカスタマーエンジニアが普段どのように社内のデータプラットフォームを活用しているのか

特に最初のセッションは、私自身が BigQuery の Remote Functions に対して具体的な利用イメージを持っていなかったので、とても参考になりました。また Google Cloud のカスタマーエンジニアの方のセッションでは、データ活用に向けては適材適所でそれぞれのツールを駆使して地道なデータとの向き合いが必要であることを改めて感じました。

アンカンファレンス

後半はアンカンファレンスです。参加者 5 名ごとに 8 つのグループを作り、各グループに Google Cloud のカスタマーエンジニアの方がファシリテーターとして入る形でディスカッションが行われました。

はじめに、参加者の中には「課題解決したい参加者」と「課題発見したい参加者」がいるはずであり、それぞれにとるべき行動指針を示したルール説明がありました。

このルールに則り、まずは各参加者が今日一番話したい、聞きたいことを自己紹介を交えて話し、そのあと休憩をはさみつつ 30 分 × 2 回のディスカッションを行いました。

私達のグループでは、前半は各社が BI をどのように活用しているかといった点や、Looker を導入している企業から実際の使い勝手や他 BI ツールとの両立に関する議論が中心でした。私自身、せっかくならこのイベントを通して Looker の使い勝手やメリット・デメリットを聞いて導入を検討できたら良いと思っていたので、非常に参考になりました。

後半は BigQuery のクエリを誰が作ってビジネスサイドとエンジニアサイドでどうやって共有しているか、といった話からプロダクトでデータベースと BigQuery をどう使い分けていくか、連携していくかといった話に波及していきました。各社それぞれ、やはりさまざまな苦労があるなあという印象でしたが、近い課題感を持っている企業も多く親近感が湧きました。

また、アンカンファレンスでのディスカッション内容からカスタマーエンジニアの方が Google Cloud プロダクト側へのフィードバックを吸い上げてくださっているのも印象的でした。こういった場があることで、プロダクトとユーザーの距離が近くなり、より良いプロダクトが生まれていくのだなあと感じました。

最後に

今回は Google Cloud Japan 主催の “第 2 回 Digital Native Leader’s Meetup” にご招待いただき参加してきたので、そのイベントのレポートをお伝えしました。

他社の具体的な事例や課題、工夫している点などが生の声で直接聞ける場は非常に貴重です。何より技術者の方々が集まり技術に対して熱く議論を交わす場で、とても楽しめました。今後もこのようなイベントに積極的に参加し、プロダクトの改善につなげていきたいと思います。

We are Hiring!

ARIGATOBANK の提供するモバイルアプリ “arigatobank” は、バックエンドシステムをすべて Google Cloud で開発・運用しています。今後も「お金で困っている人をゼロにする」世界を実現するために Google Cloud をフル活用して様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

Google Cloud Japan 主催 “第 2 回 Digital Native Leader’s Meetup” 参加レポート was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。ARIGATOBANK バックエンドエンジニアの富樫です。

ARIGATOBANK バックエンドチームではチームの成長やシステムの規模拡大に合わせて、アプリケーションアーキテクチャや CI/CD の仕組み、サービスの運用を常に見直しながら日々開発しています。

この記事では、Google Kubernetes Engine (GKE) 上で扱うシークレットの管理方法を External Secrets Operator の導入によって改善した話を紹介します。

※ 以下、特に断りのない限りパスワードやトークン、キーなどの機密データを指して「シークレット」、Kubernetes の Secret リソースを指して「Secret」と表記します。

これまでのシークレット管理

ARIGATOBANK のサービスは基本的に GKE をアプリケーションのプラットフォームとして構築しています。このため、シークレットは Kubernetes の Secret リソースで管理します。Secret に含まれる値は base64 でエンコードされているのみで容易にデコード可能です。このためマニフェストの yaml ファイルは直接 Git リポジトリで管理しない方針に定めています。

これまでの Secret リソースの管理は以下の方法をとっていました。

1. アプリケーションごとに Secret リソースの yaml を手作業で作成する
2. 作成した Secret リソースを手作業で Kubernetes クラスタに apply する
3. Deployment リソースは envFrom プロパティを利用して Secret リソースを参照させる
4. Secret リソースの yaml はバックアップとしてチーム共有の 1Password に保存する

手作業の多い運用ですが、2021 年 4 月頃の開発スタート時点では上記の方法が最適と考え採用していました。

Secret の運用管理については、ソースコードリポジトリ内で暗号化して管理する方法や GCP 上で管理して Kubernetes 上で生成する方法などさまざまなソリューションが存在しています。ただし、いずれも開発プロセスや運用に多少の煩雑さを持ち込むことは避けられません。

検討当初はシステムの構成やソースコードの管理運用をできる限りシンプルにすることで、開発速度の低下要因や運用上のリスク減らしたい思惑がありました。

当時のチーム規模では上記の手運用にチーム内の相互チェックをガバナンスとして加える形で問題ないと考え、システムの規模拡大やチームの成長とともに必要になったタイミングで運用を再検討することにしました。

運用ニーズから理想の運用をイメージする

サービスローンチから約 1 年が経過する頃になると、運用上のニーズとして以下のような意見が出てきました。

• デプロイに必要な Kubernetes マニフェストすべてを Git リポジトリ上で管理したい
• マイクロサービス間の認証につかうシークレットが同じ値であることを仕組みで保証したい
• Secret マニフェストの管理・設定を手動で実施しているため、操作が必要になった際のデプロイ手順が煩雑

また、開発を進めていくなかで Cloud Functions や Cloud Run を採用するシーンがいくつかありました。これらのサービスにはシークレットを Secret Manager で管理し環境変数への埋め込む機能が提供されています。この管理方法が非常に手軽で便利であったため、GKE でも Secret Manager を使って Secret リソースを管理したいと考えるようになりました。

このときイメージした運用は以下のようなものです。

1. シークレットを Google Secret Manager に登録する
2. シークレットの所在を示す設定ファイルをアプリケーションの Kubernetes マニフェストと同様に Git リポジトリで管理する
3. 何らかのソリューションを用いて上記設定ファイルから Kubernetes 内に Secret リソースを生成する
4. Deployment リソースの envFrom プロパティは生成後の Secret リソースを参照する

この運用であればニーズを満たせると考え、実現するためのソリューションを検討し始めました。

External Secrets Operator 選定のポイント

検討にあたっては Google Cloud のカスタマーエンジニアの方からさまざまな参考情報をいただきました。（大変お世話になりました！）最終的には以下の 2 つに絞り込んで比較検討しました。

• External Secrets Operator
• Kubernetes Secret Store CSI Driver

主に上記のポイントを比較し、結果として External Secret Operator を採用しました。

最も大きな理由として Secret Store CSI Driver は汎用性に欠けると感じた点が大きいです。特に Pod への mount に応じて Secret が生成される点から生まれる制約が多く、例えば Ingress の TLS を Secret で設定したい場合には利用できません。一方で External Secrets Operator はシンプルに Secret の生成にフォーカスしたソリューションです。Creation Policy, Deletion Policy によるライフサイクルの設定も可能で、多少特殊な Secret 利用シーンにも柔軟に対応可能であると感じました。

また、External Secrets Operator は Secrets Manager へアクセスするサービスアカウントを Pod の実行サービスアカウントと分離できる点が優れています。外部からアクセスされ得る Pod に対して Secret Manager へアクセスする権限を持たせる必要がないため、比較的安全性を確保できます。

以上のことから、今回は External Secret Operator を採用しました。しかしながら kubernetes-sigs 配下の Kubernetes Secrets Store CSI Driver が将来的にデファクトスタンダードになっていく可能性もあります。今後のアップデートについては引き続き注視していく必要があるものと考えています。

安全な移行を実現するための工夫

ここからは External Secrets Operator の導入にあたり、安全に移行し運用していくために行なった工夫を紹介していきます。

ExternalSecret のリリースと、生成された Secret を利用する Deployment のリリースを分ける

値に誤りがあると直接システム障害に繋がるため、ExternalSecret リソースの導入は慎重に行なう必要がありました。サービスごとに以下の手順で移行を進めました。

1. ExternalSecret リソースを作成し、Secret を自動生成する
2. これまで利用していた Secret と ExternalSecret により自動生成された Secret を比較し、内容に差分がないことを確認
3. Deployment リソースの envFrom プロパティで参照する Secret を切り替える

まだ全サービスの移行が完了したわけではありませんが、Secret 値が移行前と全く同一であることを確認しながら、とても安全に移行作業をすすめることができています。

このように Secret 生成と Deployment への設定値注入を分割して作業できることも External Secret Operator を選択したメリットであると感じています。

シークレット追加リリース時の Secret 同期ラグ対策

アプリケーションにシークレットを追加する場合は「ExternalSecret リソースへのシークレット定義追加」「アプリケーションでシークレットを読み込む修正」の 2 つを同時にリリースしています。

ExternalSecret を変更すると External Secret Operator がそれを検知し Secret を更新しますが、これには数秒かかります。このとき同時に Apply した Deployment リソースによる Pod のロールアウトが先に動く場合があり、この場合アプリケーションはシークレットを期待通り読み込むことができません。

以前は事前に Secret を手動で更新してから Deployment を Apply していたため、こういった問題は起きていませんでした。とはいえ以前のように Secret のリリースと Deployment のリリースを毎回分けてしまうと、せっかくの手軽さが台無しになってしまいます。

そこで対策として、アプリケーション起動処理でサーバーを起動する前に期待するシークレットが読み込めているかチェックし、問題がある場合は強制終了させています。プロセスが終了しても Kubernetes のオートヒーリングにより、シークレットが期待通り読み込まれるまで自動的に再起動されます。Pod には Readiness Probe を設定しているため、サーバーが起動してから一定時間正常に動作していない限りリクエストを受け付けることはありません。これは期待通り動作しており、現在特に問題は起きていません。

注意点として、この対策はシークレット値の変更に対しては効果がありません。現状は単純に値を変更するだけになるケースが少ないため(シークレットの主な用途であるマイクロサービス間の認証において、値の変更時は一時的に新旧を併存させる必要がある)、変更時は別名でシークレットを追加し、不要になったシークレットを後から削除する運用としています。

さいごに

本記事では、ARIGATOBANK バックエンドチームで行なった External Secrets Operator の導入についてご紹介しました。

External Secrets Operator 自体は、あまり気を使うことなく運用できていますが、今後知見としてシェアできることがでてきたら、またこのブログに記事を書こうと思います。

We are Hiring !

ARIGATOBANK では、今後も「お金で困っている人をゼロにする」世界を実現するために様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

GKE の Secret 手動管理を脱却すべく External Secrets Operator を導入しました was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

初めまして、小泉と申します。ARIGATOBANK で Tech Lead として決済システム全般の技術リードを行っています。

ARIGATOBANK では、2022年4月から電子マネーサービスを開始しました。

今回は、この決済システムにおける決済処理のデータ設計について、お伝えしたいと思います。

ARIGATOBANK が提供する電子マネーサービス

ARIGATOBANKは前払式支払手段（第三者型）として登録しており、各種キャンペーンの当選金を蓄積する「受取り待ち残高」と、Visaプリペイドカードとして利用できる「ARIGATOBANK残高」の２種類の電子マネーを提供しています。

お金の流れの概要は以下のようになります。

利用者は、付与された受取り待ち残高をアプリ上から受け取る、もしくはクレジットカードかセブン銀行ATMから、ARIGATOBANK残高にお金がチャージできます。チャージした残高は、Visa加盟店で利用することができます。

ウォレットシステムのアーキテクチャ

ARIGATOBANK では、決済システムが「ウォレット」という名前で呼ばれておりますので、以降ウォレットシステム、と呼びます。

ウォレットシステムは、マイクロサービスアーキテクチャをベースに設計しています。

残高の管理や決済処理を担うコアコンポーネントと、ユースケースを実現する為のユースケースコンポーネント、更に外部との接続を担うフロントエンドコンポーネントといった、役割ごとにレイヤーを分けるイメージで全体を設計しました。

この記事では、コアコンポーネントで担っている決済処理のデータ設計について、付与から支払いの処理にフォーカスして説明します。

コアとなるデータの設計

ウォレットは今後多様なサービスと接続し、複雑なトランザクションや外部との接続といった拡張を想定しています。それらを実現していくための包括的な設計として、ウォレットシステムのコアコンポーネントは以下のように管理する対象をレイヤー分離して設計しました。

電子マネーの残高を管理する

電子マネーをサービス化するにあたって最も大切な機構として、ユーザが保有している残高を管理する仕組みが必要です。

図の黄色部分が、残高を管理するモデルです。

この残高を管理する概念を、Account と命名しました。Account は保有者、口座の種類や残高といった属性情報を持ちます。

残高の動きを管理する

次に、残高の加減算を正しく管理する仕組みが必要です。

冒頭の図の緑色部分が、残高の動きを管理するモデルです。

残高の加減算は、ひとつの口座に着目してその口座の残高の加減算を記録する仕組みだと、整合性の確認ができないトランザクションが発生する可能性があります。これは加算される残高の原資を無視した場合に陥りがちなトラブルです。

そこで、ウォレットシステムでは残高は必ず口座から口座の移動によって管理する設計をしており、突然とある口座に残高が増えるといったことが発生しないように設計しています。

ある口座の残高が加算されると、必ず別の口座が減算されるので、マイナス残高を許容する口座が必要になります。そういった口座の特性は、口座の種類によって制御します。

この、口座から口座への残高の動きを管理する概念は、Transfer と命名しました。

また、１回の取引が複数の Transfer から構成されることがあり、部分的に成立することを避ける必要があります。これを解決するために Transfer を束ねる Transfer Request という概念を定義しました。

Transfer Request で束ねられた Transfer は、部分的に成立するということはなく、全て成立するか、全て不成立かのどちらかとなります。システム上は、データベースのトランザクションによって一貫性を保ちます。

決済の状態を管理する

残高と加減算は管理できるようになりましたが、もうひとつ上位概念として、決済の状態を管理する仕組みを設計しました。例えば、決済が「成立」した後の「返金」は、残高の動きとしては２度発生していますが、単一の決済が状態遷移していると言えます。

先程示した下記の図の青い部分が、決済の状態を管理するモデルです。

この決済の状態を管理する概念を Payment、Payment の状態を変更する概念を Payment Request と命名しました。

今回設計した Payment の状態遷移図は以下の通りです。

Created は、Payment を作成した状態で、残高は動いていません。

Captured は、決済が成立した状態を表します。

Canceled は、移動した残高を元に戻した状態を表します。

Held は少し特殊で、宛先口座にはまだ残高は移動していないが、元口座からは引かれている状態を表します。

ユースケース毎の実装では、Payment を作成して、Payment Request を発行することによって Payment の状態を遷移させ、状態遷移にあわせた Transfer を作る処理が行われます。

具体的なユースケースの実装

決済処理を行うデータの設計ができたので、各ユースケースでどのように処理するかを見ていきます。

各キャンペーンの当選金の付与

当選金の付与は、「キャンペーン管理口座」から「ユーザの 受取り待ち残高口座」へ決済処理を行います。

図に登場しているキャンペーン管理口座は、内部的にキャンペーンの原資となる口座で、所有者は ARIGATOBANK（弊社） です。

Payment を初期状態の Created で作成します。その後 Capture の Payment Request を発行すると、指定した金額の残高を移動する Transfer が生成され、Payment の状態が Captured に遷移し処理が完了します。

受取待ち残高の受け取り（ARIGATOBANK残高へのチャージ）

受取待ち残高に付与された残高は、ユーザがアプリで受け取り操作を行うことによって、ARIGATOBANK残高へチャージされます。

当選金の付与と同様の手順で、「ユーザの 受取待ち残高口座」から「ユーザの ARIGATOBANK残高口座」へ決済処理を行います。

Visa加盟店での利用

ARIGATOBANK では、電子マネーを使う手段として、Visaプリペイドカードを発行しています。

プリペイドカードはクレジットカードとは異なり、支払いの際には事前に電子マネーをチャージしておく必要があります。

また、Visa加盟店での支払い処理は、支払い時点でリアルタイムに処理する与信枠の確保（オーソリ）と、日次などの周期で加盟店から連携される売上の確定（クリアリング）があります。処理の概要を図に示すと以下の通りです。

クレジットカードの場合は、オーソリ時点では与信枠を確保するだけなので、カード所有者へ請求はありません。クリアリングがあった利用について、1ヶ月分をまとめて翌月にカード所有者に請求を行います。

一方でプリペイドカードの場合は、オーソリの時点で電子マネーの残高を減算します。先にチャージしてある残高をオーソリ時に減算しているので、クリアリングであった利用を翌月まとめて請求することはありませんが、差額があればその差額を電子マネーの残高に反映するので、残高が変動します。

具体的な処理の流れを説明します。まずはオーソリです。

まず、Visa加盟店での利用を管理するために、「帳簿口座」と命名した口座を作成しました。所有者は ARIGATOBANK（弊社） です。

また、ユーザの ARIGATOBANK残高を一時的に仮押さえしている状態を管理するために「ARIGATOBANK残高(HOLD)」という口座を作成しました。こちらはまだ売上が確定していない電子マネーになるので、所有者はユーザです。

オーソリ処理は、Payment を作成し、Hold の Payment Request を発行します。Payment は Held 状態となり、指定した金額の残高が ARIGATOBANK残高(HOLD)口座に移動します。

このオーソリに対して、同額のクリアリングが来た場合は、以下のようになります。

新しい Payment は作成せずに、オーソリで作成した Payment に対して更に Capture の Payment Request を発行します。元のステータスが Held なので、Payment は ARIGATOBANK残高(HOLD) から帳簿口座への Transfer を作成し、Payment が Captured に状態遷移して処理が完了します。

オーソリ時と金額が違うクリアリングが連携され、差額の調整が必要になった場合は、以下のようになります。

上記は、2000円のオーソリに対して、1500円の売上の確定が連携された例です。

Hold 時と金額が違う Capture の Payment Request を受け付けると、まず確定で連携された金額を ARIGATOBANK残高(HOLD) から帳簿口座に移動する Transfer と、同時に差額を ARIGATOBANK残高に戻す Transfer を作成し、Payment が Captured に状態遷移して処理が完了します。

この例では、ユーザは売上の確定のタイミングで残高が 500円返ってきたように見えます。

以上が、Visa 加盟店で利用する際の処理です。

まとめ

ARIGATOBANK の決済システムにおけるデータの設計について、ご紹介しました。また、具体的な残高の付与からVisa加盟店での利用までのユースケースについて、どのようなデータが作られるかをご紹介しました。

これからの機能追加で新しいユースケースが増えたり、新しい残高が増えることもあると思いますが、今後の改修に耐えうるいい基盤が作れたのではないかと思います。

また、特に決済システムのコアな部分のデータ設計は、後からの変更が容易ではありませんが、その一方で、なかなか他社の設計を見る機会は多くありません。今後電子マネーサービスの立ち上げをするようなことがある際には、何かの参考になれば幸いです。

We are Hiring !

ARIGATOBANK では、今後も「お金で困っている人をゼロにする」世界を実現するために様々な機能やサービスを創出していきたいと考えています。

新しいお金の流れをつくるプロダクト開発に一緒に取り組む仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思います。お気軽に 採用ページ からご連絡ください！

ウォレットシステムのデータ設計 was originally published in ARIGATOBANK Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.