db tech showcase に行ってきた #dbts2022

Cloud Spanner メモ

db tech showcase に参加しました。オンライン開催。簡単に所感をまとめます。

www.db-tech-showcase.com

所感

Twitter に流れてきたのをたまたま見つけて参加しました。とは言っても最終日の1セッションのみ。今後、Cloud Spanner を使う予定なので。

前に見つけたこちらの記事では、Cloud Spanner には SELECT FOR UPDATE がないような感じで書かれてましたが、どうやら LOCK_SCANNED_RANGES=exclusive というヒント句がありそう。

recruit.gmo.jp

ただし、ヒント句なので必ず排他ロックされるわけではない模様。このあたりはイマイチ理解できてないのでもう少し調べたい。(ヒント句なのでっていうところがよく分かってない)

ただ、Cloud Spanner のクライアントライブラリには abort したときにでリトライする仕組みがあるようで、排他ロックじゃなくても abort + リトライ でいいのかなと思いました。たぶん。

あと、リトライの仕組みでは、クライアント側のコードブロックごとリトライされるようです。なので、冪等でない処理はリトライ対象のコードに含めない方がいいとのこと。なるほど。

今回の話を聴いて、Cloud Spanner は SERIALIZABLE なのでわりと考え方としてはシンプルな感じがしたけど、SQL を書いたりレビューする際には特にロックについてかなり意識する必要がありそうな気がしました。ロックの粒度がセル単位ということもあり、いかに不要なロックを取らないかがポイントかもしれない。

以下、メモから抜粋。

分散データベース Cloud Spanner のトランザクションの仕組み

  • 可用性に特化している
  • 1ノードであっても冗長化される
    • デフォルトで3ゾーンに冗長化される
  • ダウンタイムなしでノード削除可
  • マルチリージョンで冗長可
    • リージョンごとに act/standby ではない
  • 分散ストレージ (Colossus)
  • 自動シャーディング
    • スプリットごと
  • SQL
  • NoSQL の上に SQL レイヤーを構築している
  • ACID トランザクション
  • 分離レベルが下がると異常 (Anomaly) が起こる
  • Phantom Read を許容するかどうか
  • Write Skew
  • 原子時計のタイムスタンプでコミット順序を判断している
  • Lost Update は起こらない
    • Lost Update を引き起こす更新は abort する
    • ヒント句で排他ロックを取るのは可
      • LOCK_SCANNED_RANGES=exclusive
  • Write Skew は起こらない
  • トランザクションの追い越しは禁止
    • External Consistency (外部整合性)
    • Serializable より強い
    • 発生したイベントは実時間ベースの順序でコミットしたい
  • abort は自動リトライする
    • クライアントのコードブロックごとリトライする
    • 冪等ではない処理はリトライ対象のコードに含めない
  • セルロック
    • 同じ行であっても異なる列の更新は衝突しない
  • 代表的なロック3種類
    • ReaderShared
      • UPDATE の WHERE 句も ReaderShared ロックの対象に含まれる
    • WriterShared
      • SQL実行時ではなくコミット時にロックを取る
    • Exclusive
      • WriterShared + ReaderShared と同等
  • トランザクション統計テーブル
    • _exists はレコードの存在チェックのための隠しカラム
  • 読み込みだけなら読み取り専用トランザクションを使う
    • readonly transaction
    • ロックを取得しない
  • トランザクション内で不要なロックは避ける
  • ロックの対象はセル単位
    • SELECT 対象の列は絞る (SELECT * FROM ... にしない)
  • transaction tag

BtoB SaaS における技術課題との向き合い方 に行ってきた #BtoBSaaSTechnicalIssues

メモ

BtoB SaaS における技術課題との向き合い方に参加しました。オンライン開催。簡単に所感をまとめます。

sansan.connpass.com

所感

全体的に共感するところが多い内容でした。

チームごとに改善活動を持ち回るのはよさそう。ナレッジが組織全体で蓄積できるし。負債解消以上の改善については別チームや役割を設けるのがいいんだろうか。

テナントとユーザーの話は興味深かったです。ブログとか参考資料あとで見てみよう。フィーチャートグルも今のプロジェクトの中で検討してもいいかもしれない。

B2B SaaS だとドッグフーディングしにくいのは確かにありそう。ユーザーの業務をいかに吸い上げるかがポイントかもしれない。

しかし、SQLite のファイルをアップロードして同期を取るのはすごい...。(その発想はなかった)

以下、メモから抜粋。

SmartHR 基本機能の開発と並行してパフォーマンス系タスクを中心とした非機能要件に取り組んできた歴史

  • クロスファンクショナルチーム
  • スクラム (LeSS)
  • 履歴機能
    • 開始日/終了日
    • BiTemporal Data Model
  • モノリス
  • データ急増によるサーバー負荷
    • 初期開発ではパフォーマンスが考慮されていない (N+1とか)
  • 設計や使われ方の変化によるエラー増加
  • 規模が大きい問題は機能開発を止めて修正する
    • タスクフォース
  • 小さい問題の優先度判断が難しい
  • 有志の改善活動が滞りがち
  • スクラムで負債をどう扱うか
  • 改善活動に使う割合を固定する
  • チームごとに交代で改善活動を回す
    • 終わらなかったら次のチームに引き継ぎ
      • 引き継ぎコストは高い
    • チーム全体で学習できる
  • 改善タスクはエンジニアが管理する

BtoB SaaS におけるテナント・ユーザー設計の悩みどころ

  • Row-Level Security
  • テナント/ユーザー
    • 3パターン
    • いくつのテナントに所属できるか
    • テナントに所属しないことがあるか
  • ログイン
    • テナント指定 → ログイン画面表示
    • URL/ドメインにテナントを含める
      • URL直アクセスでテナント指定なしでログイン画面表示できる
  • テナント/SSO
    • 3パターン
    • idp がどう決まるか
      • テナントごと
      • メールアドレスドメインごと
      • ユーザーごと

デスクレスSaaSが向き合う現場DXのための技術課題

  • ホリゾンタルSaaS
    • さまざまな業界で利用される
  • 帳票のカスタマイズ (ノーコードで)
    • 内部データを木構造で表現
    • 大量のテーブルが必要
      • 階層構造を表示するため
      • データの型ごとにテーブルが必要
  • データ増
    • Goルーチンで並行処理
  • オフライン
    • 端末に記録 (SQLite)
    • オンラインになったら同期
      • SQLite ファイルをアップロードして同期

要望と機能開発の狭間を繋ぐ技術

  • 機能開発のトリガー
    • ロードマップ
    • 顧客要望
    • 開発チームからの提案
  • セキュリティチェック
  • 安定したサービス運用
    • 頻繁な機能リリースでワークフローやマニュアルの改訂が間に合わない
    • お客さまは「製品を使いたい」わけではない
  • シンプルでわかりやすいプロダクトであり続けたい
  • 機能フラグ (フィーチャートグル)
    • 分岐が増える
    • コードやサービスを利用してシンプルに
  • 機能フラグの分類
    • release toggles
    • experimental toggles
    • ops toggles (問題があったら蓋閉じ)
    • permission toggles
  • 機能フラグOFFでも機能の存在は見せたい
  • ドッグフーディング
    • 自社の運用以外が想像しづらい
  • カラースキームはカスタマイズ不可
    • 各色のユーザービリティは検証不可能

レジャー施設向けSaaSでの外部システム連携について

  • OTA
    • 商品を連携して他社サイトで販売する
  • 施設運営支援システム
    • 他社の商品マスタを取り込んで自社で販売する
  • 商品連携/販売連携/ステータス連携
  • 商品情報のうちどの情報を取り込むか
    • 連携先との依存を局所化する
  • 同期連携のパフォーマンス問題
  • 非同期連携のリアルタイム性
  • ステータス連携の方向をシンプルに
    • 双方向にするとどちらが正か煩雑になる
  • 連携方式の個別対応を分離したい
    • インタフェースを決めて共通処理と分離する
  • Webhook で個別の連携処理を外に出せそう

「メタエンジニアリング」をもっと深ぼる に行ってきた #メタエンジニアリング_findy

メモ

「メタエンジニアリング」をもっと深ぼるに参加しました。オンライン開催。簡単に所感をまとめます。

findy.connpass.com

所感

engineer-lab.findy-code.io

このブログにも書かれてますが、浅くても幅広い知識や経験があるからこそ、エンジニアリングに関するいろいろな課題解決に取り組めるんだろうと思いました。

今回の話を聴いてて、エンジニアとマネージャーはわりと地続きな関係にあるというか、決して対立的な関係ではないんだなと改めて思いました。あと、こういう方々はものごとを言語化するのがとてもうまい。「メタエンジニアリング」という名前も絶妙ですね。

以下、メモから抜粋。

  • エンジニアとマネージャーの境界は曖昧
  • メタエンジニアリング
  • エンジニアの生産性を向上するための取り組み
    • 技術広報
      • 採用広報とは分けて考える
      • エンジニアのアウトプット重視 > スキル向上
      • 社外からの信頼を得て採用に繋げる
    • 採用
    • 組織開発
  • アウトプットするひとのところに情報が集まる
  • Scrum@Scale
  • 課題を言語化する (困っていること/悩んでいること)
  • 対話型アプローチ
    • スクラムマスターとしては全体を俯瞰して観察するのも大事
  • メタエンジニアリングはやることが無限にある
    • 個人よりチームで取り組んだ方がいいこともある
  • 談話室メソッド
  • 1on1
    • フリーで予定を入れることもある
    • 忙しいときに疎かになる > 定例で入れる
    • 頻度を柔軟にしてもよさそう (悩みが多そうなら毎週やったり)
  • 成果にレバレッジを効かせられる
  • マネージャーとして入社したときに何をやるか
    • 期待値を合わせる
  • マネージャーの育成
    • 泥臭い仕事を泥臭く支援する
    • 一緒に意思決定する/根拠を見せる
  • プロダクションコードは書いていない
    • 締切のあるタスクを抱えると死ぬ
  • テックブログ
    • アウトプットの習慣を自然に身に付けたい
    • 業務としてやるなら目的を伝える

tech.smarthr.jp

開発効率が高いエンジニアを真似することから始めるエンジニア組織の改善サイクル に行ってきた #エンジニア組織_findy

メモ

開発効率が高いエンジニアを真似することから始めるエンジニア組織の改善サイクルに参加しました。オンライン開催。簡単に所感をまとめます。

findy.connpass.com

所感

PR を目標設定の指標にしている模様。PR から個人の活動がここまで分析できるのは興味深い...！「途中のコードでもプロダクションコードに混ぜることを許容する文化」はちゃんとテストがあるからこそ実現できるものなのかもしれない。

タスクの細分化を徹底しているようで、おそらく作業着手する前にしっかりプランニングしているんだと思う。自分のチームでも PR をいくつかに分けて出してくれるひともいるけど、このあたりは個人の裁量になってしまっているのでチームの中で仕組み化できるとよさそう。PR を小さくするとレビューしやすくていい。Files changed 100 over とか来るとツラい...。

一応、スクラムで開発しているけどちゃんとベロシティ計測できてないのでなんとかしないとなぁ...。

以下、メモから抜粋。

  • 開発アクティビティ可視化
  • いかにベロシティを最大化するか
  • チームによって性格が違う
    • 課題解決型チーム
    • 事業目標推進型チーム
  • プルリク作成数
  • リードタイム (マージするまでの時間)
  • Four Keys
    • デプロイ頻度
    • リードタイム
    • 変更障害率
    • 平均修復時間
  • 課題
    • リリース作業が煩雑
    • デプロイに時間がかかる (30分〜1時間)
    • 切り戻しにも時間がかかる
    • ジョブ実行中にデプロイできない
    • リリース前 QA の負荷が高い
  • リリース自動化
  • インフラ構成変更 (デプロイ時間短縮)
  • 自動テスト
    • E2E テスト/UI差分検知
  • 検証環境の取り合い
    • ブランチごとに検証環境を作成したい
    • E2E テストで品質担保
  • リリース頻度が増えたことでリリース内容が共有できないこともあったり
  • 目標管理/育成
    • PR 数
  • 最初のコミットから PR 作成までの平均時間
  • PRに対する平均コメント数
    • コメントで仕様すり合わせしていないか
    • 事前に口頭で話した方が早くないか
  • 定点観測
    • メンバー参画直後は一時的に数値が低下する
      • 2-3週間で戻るなら問題なし
  • 1つの PR は数時間で終わる粒度で分解する
  • リファクタリングは別 PR にする
  • 既存に影響がない PR はどんどんマージする
  • issue ベース
    • タスクを細分化する
    • PR はタスクごと
    • PR の詳細はタスクを見れば分かるように
  • 自動テスト
  • 途中のコードでもプロダクションコードに混ぜることを許容する文化

tfenv install で 404 が返るので手動でインストールする

Homebrew Terraform

M1 mac から tfenv で terraform 0.14.11 をインストールしようとしたらエラーになる。

$ tfenv install 0.14.11
Installing Terraform v0.14.11
Downloading release tarball from https://releases.hashicorp.com/terraform/0.14.11/terraform_0.14.11_darwin_arm64.zip
curl: (22) The requested URL returned error: 404                                                                                                                                               

Tarball download failed

Terraform v0.14.11 Binaries | HashiCorp Releases

微妙にファイル名が違う模様。古いバージョンだからだろうか。

対策

tfenv でインストールしたバイナリは /opt/homebrew/Cellar/tfenv/3.0.0/versions に配置される。今回は個別にダウンロードして手動で配置する。

$ cd /opt/homebrew/Cellar/tfenv/3.0.0/versions/
$ mkdir 0.14.11
$ cd 0.14.11/
$ wget https://releases.hashicorp.com/terraform/0.14.11/terraform_0.14.11_darwin_amd64.zip
$ unzip terraform_0.14.11_darwin_amd64.zip
$ /opt/homebrew/Cellar/tfenv/3.0.0/versions/0.14.11/terraform --version
Terraform v0.14.11

現場からは以上です。

DBeaver の接続設定を移行したい

DBeaver

作業マシンを移行するので DBeaver の接続設定を移行したい。備忘録。

DBeaver community Version 22.1.4.202208051447

旧マシンの DBeaver からエクスポートする

  1. File > Export でウィザードを開く
  2. DBeaver > Project > Next
  3. エクスポートするプロジェクトを選択して Finish

エクスポートしたファイル (.dbp) は新しいマシンにコピーする。

新マシンの DBeaver にインポートする

デフォルトで General という名前でプロジェクトが生成されているので同名にしたいときは先に削除する。もしくは別名でインポートしてもいい。

  1. File > Import でウィザードを開く
  2. DBeaver > Project > Next
  3. エクスポートしたファイルを選択する
  4. Import driver libraries はチェックしたままで OK
  5. プロジェクトを選択して Finish

現場からは以上です。