私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT に行ってきた #TiDB_findy

メモ TiDB

私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT に参加しました。オンライン参加。簡単に所感をまとめます。

findy.connpass.com

所感

特に全体的に共通して言われてたのは書き込みのスケーラビリティと MySQL 互換であること。今回、既存システムの DB を移行する事例が多かった気がするので、互換性の高さが大きなメリットになったんだろうと思いました。たしかにアプリケーションコードを変更しなくてもいいのは助かる。あと、学習コストが低く抑えられるっていうのもいい。

HTAP という言葉は初めて知りました。Google Cloud だと Spanner + Big Query みたいなもんなのかしら。LINE ヤフーさんの話は性能検証の観点として参考になりました。

Spanner にも go-tpc みたいなツールあるのかな...。あと、プッシュダウンみたいな考え方は Spanner にもあったような気がする。(たぶん)

GitHub - pingcap/go-tpc: A toolbox to benchmark TPC workloads in Go

以下、メモから抜粋。(資料が公開されたらリンク追加します)

最近たまに見かけるTiDBってなんだ？

  • TiDB
    • MySQL互換
    • 分散型SQLデータベース
  • NewSQL
  • computing nodes
  • マルチマスター
  • PKのレンジでチャンクを持つ
  • リーダー: R/W
  • フォロワー: バックアップ
  • 自動フェイルオーバー
  • HTAP
  • アーキテクチャ
  • TiKV
    • Row型
    • ストレージ
    • 分散型 KVS
  • PD
    • チャンクの物理的な配置場所を管理
  • TiFlash
  • Serverless
    • マルチテナント
  • Dedicated
    • 専有型

検証を通して見えてきたTiDBの性能特性

  • Write Heavy
  • 書き込みのスケーラビリティ
  • go-tpc
    • TPC-C シナリオ
    • パフォーマンステスト
  • 書き込みのスケーラビリティ
  • PK range update
    • QPS
    • 小さい range だと MySQL の方が高速
    • range が増えても TiDB は安定する
  • クエリレイテンシ
    • 小さいクエリだと MySQL より遅い
    • TiDB → TiKV の rpc リクエストが占める
  • inner join / 相関サブクエリ
    • TiDB の方が5倍以上早い
    • 大きめのクエリで TiKV にプッシュダウンできると早くなる
      • TiKV 側で複数ノードで並列処理できるため

@cosmeのTiDB採用までの道のりとか

www.docswell.com

  • SQL Server/MySQL → TiDB
  • Aurora
    • 強制バージョンアップ
  • 無停止バージョンアップ
    • ローリングアップデート

DMMプラットフォームがTiDBを採用した背景

  • TiDB Cloud
  • 書き込みのスケール
  • 強整合性
  • 耐障害性
  • DB起因のダウンタイムを避けたい
  • パフォーマンスはRDBに劣る
    • APIレベルのレイテンシ劣化は100ms未満
  • Spannerの方がDBとしては完成されている
    • インターリーブ
  • MySQLプロトコル互換
    • テーブル定義の変更が不要
  • アプリケーションコードの変更不要
  • MySQLエコシステムを活用できる
  • 学習コストが低く抑えられる

コロプラでの長期運用プロジェクトでMySQLからTiDB移行の検証について

  • MySQL互換
  • スケールアウト/スケールイン
  • メンテナンスなしでバージョンアップ可能
    • ローリングアップデート
  • データ圧縮によるディスク削減
    • 1/3くらいまで圧縮できた
  • 大量データのときに TiKV 上でリージョン分割が発生
    • リージョン間のやりとりで TiKV の負荷上昇
    • PKやインデックス追加で軽減できる
  • 広い範囲を見るクエリは苦手
    • それを補完するのが TiFlash
  • トランザクション分離レベル
    • REPEATABLE READ
  • InnoDB エンジンに依存するロジックの改善は必要
    • InnoDB は SELECT のときに Transaction ID が発行される
    • TiDB は BEGIN のときに発行される
    • InnoDB で見えていたデータが TiDB では見れなかったり

長期間TiDBを使ってきた話

  • メンテナンス/スケールアウトが容易
    • tiup コマンド
  • TiFlash
    • OLTP + HTAP が1システムで実現できる
  • dashboard 便利
  • TiProxy
    • TiDB の前段にいるプロ棋士
    • 無停止アップデート
      • ローリングアップデートしても外から見るとコネクションは切れない
  • TiFlash 活用
    • ヒント句で TiFlash のテーブルを読むようにする

あとで読む。

Cloud Spanner で分間の注文数を集計するクエリが書きたい

Cloud Spanner

Cloud Spanner で分間の注文数を集計するクエリが書きたかったので書いてみた。なお、注文日時 (OrderDateTime) は UTC で格納されているが、集計期間の指定や集計結果では JST で扱いたいものとする。

SELECT
  FORMAT_TIMESTAMP('%Y-%m-%d %H:%M', TIMESTAMP_ADD(Orders.OrderDateTime, INTERVAL 9 HOUR), 'UTC') ordered_at,
  COUNT(1) cnt
FROM Orders
WHERE Orders.OrderDateTime BETWEEN '2024-03-26 10:00:00+9:00' AND '2024-03-26 23:59:59+9:00'
GROUP BY FORMAT_TIMESTAMP('%Y-%m-%d %H:%M', TIMESTAMP_ADD(Orders.OrderDateTime, INTERVAL 9 HOUR), 'UTC')
ORDER BY ordered_at;

GCP の Spanner Studio から実行した際、以前はこのクエリだとエラーになったような気がするんだけど、今は特に問題なく実行できている。(こんな感じのエラーが出てたような記憶...)

SELECT list expression references Orders.OrderDateTime which is neither grouped nor aggregated at line XX, column XX...

ちなみに、秒間で集計したい場合は FORMAT_TIMESTAMP を %Y-%m-%d %H:%M:%S のようにする。

現場からは以上です。

(追記)

FORMAT_TIMESTAMP とか TIMESTAMP_ADD が冗長だったのでまとめた。

WITH row_data AS (
  SELECT
    FORMAT_TIMESTAMP('%Y-%m-%d %H:%M', TIMESTAMP_ADD(Orders.OrderDateTime, INTERVAL 9 HOUR), 'UTC') AS ordered_at
  FROM Orders
  WHERE Orders.OrderDateTime BETWEEN '2024-03-26 10:00:00+9:00' AND '2024-03-26 23:59:59+9:00'
)
SELECT
  row_data.ordered_at,
  COUNT(*) cnt
FROM row_data
GROUP BY ordered_at
ORDER BY ordered_at;

GitHubのエンジニアが語る！MySQL5.7→8.0へのサービス無停止アップグレードの内幕 に行ってきた #GitHub_findy

メモ MySQL

GitHubのエンジニアが語る！MySQL5.7→8.0へのサービス無停止アップグレードの内幕 に参加しました。オンライン参加。簡単に所感をまとめます。

findy.connpass.com

所感

これだけの規模の移行をサービス無停止でやってるのがすごいけど、最後にもっと早くに準備するべきだったと話しててやっぱり計画と準備が重要なんだなと思いました。逆方向のレプリケーションとか考えたこともなかった...。でもこういう取り組みによってサービス無停止が実現できるんだと思う。

いろいろ話に付いていけてないところもあったので資料とか公開されたら見直してみよう。

関連記事。

github.blog

www.itmedia.co.jp

以下、メモから抜粋。

MySQL 8 Upgrade at GitHub

  • 秒間500~800万リクエスト
  • 300+ TB
  • 100+ クラスタ
  • 1500+ MySQLインスタンス
  • github.com
  • 縦方向/横方向のパーティショニング
  • ProxySQL
  • Vanilla
  • GitHub Enterprise
  • Azure
  • 要件
  • MySQL 8.0 の変数/設定をすべて確認
  • 非推奨機能が使われていないか
  • コードベースは両バージョンで動くか
    • CI
    • テストがすべて通るか
  • インプレースアップグレード
  • トポロジー
    • 5.7 → 8.0 → 5.7/8.0
  • プライマリをアップグレード
    • 5.7から8.0に切り替える
  • デフォルトの文字セット照合順序 (COLLATION)
  • 権限
    • Puppet
    • 誤ったロールが作成される？
  • レプリケーション遅延
    • レプリカのタイムスタンプを保存して監視している
    • 20ms (5.7) → 100~150ms (8.0)
    • datadog プラグインの問題？
  • I/O増
    • fsync
  • 実行計画
    • Large IN
    • 5.7 では statistics で止まる？
    • 8.0 だとオプティマイザがクラッシュする
  • 自動化
    • フェイルオーバー自動化
    • Orchestrator
      • 旧バージョンへのフェイルオーバーもできるように
  • Vitess
  • VTGate
  • 準備をもっと早く
  • クラスタ管理部分の自動化をしたい

第1回 AWSコスト削減 天下一武道会 に行ってきた #costdown_2024

メモ

第1回 AWSコスト削減 天下一武道会 に参加しました。オンライン参加。簡単に所感をまとめます。

no1.connpass.com

所感

コスト削減は、分析からボトルネックの調査、改善まで地道な活動が必要。その分、やりがいもありそうでよさそう。刺激になる話が聴けてよかったです。

インフラコスト削減代行サービスってのがあるのか、強そう...。代行サービスとはいえ表面的ではなくドメインの深いところまで理解するから大きい効果が生み出せる。ここまでやらないといけないのね。

事業成長とコスト削減については事業フェーズによって攻めと守りのバランスが必要とのこと。あと、コスト最適化とシステム最適化が繋がる話もよかった。

パネルディスカッションでも話があったけど、他社事例やアンチパターンから学ぶことは多いのでそのあたりをアンテナ張っておくといいのかもしれない。あと、そもそもコスト意識と周りへの働きかけが大事なんだなと感じました。

そういえば、自分も気軽にデバッグしやすいようにどんどんログ埋め込んでおこうとはならなくなった。Datadog 高いし。そういう意味では以前よりコスト意識が身に付いてきたのかもしれない...。(たぶん)

アーカイブこちら。

youtu.be

以下、メモから抜粋。

100社のコスト診断から見えてきた、コスト削減の王道とケモノ道

  • コスト削減代行サービス
  • コスト削減は総力戦
  • FinOps
    • 全員がコストに対して責任を持つ
  • AWS Well-Architected
  • 料金モデル分析
    • RIが使えるか
    • ワークロード伸縮性 (休日夜間縮退など)
    • コストに基づいてリージョンを選択する
  • コスト削減の成果が早く出るだけ事業インパクトが大きい
  • 全員参加
    • モブコスト分析
    • 各領域のエンジニアがそれぞれの観点で考える (FE/BE/インフラ)
  • ドメインとアーキテクチャを繋げてみる
  • Elephant in The Room に向き合う
  • バックアップ戦略見直し
    • ロジック見直して無駄を削減する
  • アーキテクチャ更改
    • シングルテナント → マルチテナント
  • データ通信量削減
    • 使ってないレスポンスをなくす

節約は技術！削減は芸術！何より必要なものは覚悟！

  • ボトルネックから潰す
  • 覚悟を持つ
  • プロダクト急成長
    • 3年でMAU5倍
    • 1~2万rps (スパイク時)
    • AWS月額利用料 $146000
  • パフォーマンスチューニング
    • ボトルネックから潰す
    • 支配的なコストから減らす (大きな部分から)
  • 事業成長
    • コスト削減が後回しになりがち
    • 覚悟
  • 早く削減するほど効果が大きい
  • VPC Endpoint 導入
    • NAT Gateway 経由でインターネットに出る通信
    • ECR/S3 に対する VPN Endpoint 作成
    • NAT Gateway 通信料削減
  • ECR pull through cache
    • ECR Public キャッシュ
  • WAF ログ配信先
    • CloudWatch Logs → S3
    • 可視化/分析は難しくなるので注意
  • 不要リソース削除
    • アタッチされていないEIP削除
    • 使っていない環境削除
  • Gravitonインスタンス利用
    • Intelに比べてコスト効率20%向上
  • Auto Scaling Policy 見直し
  • CloudFront Request Collapsing
    • オリジンへのリクエストの折りたたみ
    • TTL1秒でもキャッシュヒット率がそこそこ高い
  • 削減しないと削減されない

dev.classmethod.jp

パネルディスカッション

  • ドメイン
    • ヒアリングする
    • ノウハウが横展開できる
    • よくあるパターンがありそう
  • 他社事例を学ぶ
  • Aurora
  • ソフトウェアエンジニアを巻き込む
  • コスト削減に取り組むタイミング
    • 売上に対してシステム費用の割合のラインを決めてたり
  • コスト削減の必要性に気が付けるか
  • Azure
    • コスト削減のノウハウは少ない

AWSコストを全体で43.75%削減するためのコストモニタリング技術

www.docswell.com

  • 覚悟と計測
  • コスト管理責任者
    • コスト計測
    • 現状把握
    • いつでもコストについて説明できるように -　コスト管理タグ
  • Cost Explorer
  • コスト構造を把握する
  • 変動要因
    • サービスごとに分類する
  • コストモニタリング技術
    • ライトなコスト分析基盤
    • QuickSight

大規模通信制御信号ETLシステムにおける大幅なコスト削減・意識改革の取り組み

www.slideshare.net

  • EC2数百台規模
  • EC2 Savings Plans
  • Graviton 移行
  • コスト監視
    • slack
  • コストを見る会
    • コスト意識
  • 夜間縮退

クラウド利用料を半額にするために取り組んだ10+のコト

  • コスト構造の抽象度を上げる
    • システム最適化に付随するコスト最適化
  • リアーキ
  • 運用負荷/信頼性改善にも効果あるかも

新サービスリリースして早々に通信費が膨れた件

  • SDKダウンロード
    • 通信費増
  • CloudFront

機械学習で使用しているGCSの料金を激減させた話

  • 機械学習の中間成果物をGCSに保存
  • GCSコスト増
  • ストレージクラス最適化
  • GCSの用途を分析
    • アクセス頻度に応じてストレージクラスを変える
    • ライフサイクル

30%のMAU増加と78%のコスト削減を両立する方法

www.slideshare.net

  • Cloud Composer
    • 常時起動/常時課金 → 高コスト
    • 基盤移行
    • Cloud Scheduler + Workflows + Cloud Functions

VPCエンドポイントを活用したコスト削減

  • NAT Gateway 処理データ料金が高い

やらなきゃ損！ECS Fargateのコスト削減の手引

  • Backlog Gitホスティング
  • x86 → ARM64 移行
    • ローカルでは x86 を使う
    • マルチアーキテクチャビルド
      • 両方のイメージが作れるように
    • ビルド時間短縮
  • gRPCクライアントのメモリ使用量を抑える
    • http2 ウィンドウサイズが動的に変更される (増える)
    • ウィンドウサイズを 64k-1 以上に
    • メモリ使用量安定
  • Compute Savings Plans

Amazon Aurora のインフラコストを55％削減した話

  • OPTIMIZE TABLE
  • 書き込み多い
    • 秒間5~9万書き込み
    • SLO見直し
    • 1日N回に制限する
  • コスト削減祭り

プロダクトマネジメントのすべて著者 及川さんに聞く 技術から価値を生み出すエンジニアになるには に行ってきた #Offers_プロダクトマネジメントのすべて

メモ

プロダクトマネジメントのすべて著者 及川さんに聞く 技術から価値を生み出すエンジニアになるには に参加しました。オンライン参加。簡単に所感をまとめます。

offers.connpass.com

所感

ソフトウェア開発からプロダクト開発にマインドチェンジすることが重要。「エディタや管理画面の向こうにユーザーを見る」という言葉は刺さりました。

顧客価値をどうやって収益に結び付けるか、その収益をプロダクトの進化に還元し、新しいユーザー価値を提供する、その結果として収益を得る、このサイクルを回せるようにするにはどうするかというビジネス視点も大事。

『プロダクトマネジメントのすべて』は前にちょっと読んでたけど、またしばらく積読してる状態なので読み直そう...。

www.shoeisha.co.jp

以下、メモから抜粋。

  • オーナーシップを持ってプロダクトに向き合う
  • ユーザーに喜んでもらう
    • この体験を他メンバーに伝搬させる
  • ビジョンの実現
    • 事業価値の最大化
    • 顧客価値の最大化
  • ソフトウェア開発からプロダクト開発へ
  • ビジネス視点
    • ユーザーファーストの視点から
    • いかにユーザーに使ってもらうか
    • 顧客価値から収益に結び付けられるか
      • ビジネスモデルの話
      • ビジネスモデルが正しいかを考えられるように
        • コスト, 課金ポイント, ...
    • 収益 → プロダクト進化 → ユーザーへの価値 → 収益 → ...
  • 内発的動機づけ
  • 外発的動機づけ
  • ユーザーにとって必要なものと売上に直結するものは両立する
    • ビジネスモデルは適切に設定できているか
    • UX改善は売上向上に寄与するか
      • 因果関係が証明できるか
  • エンジニア/ビジネスのギャップ
    • それぞれに背景がある
    • 背景を理解する
  • 機能要望の優先順位付け
    • RICEスコア
    • アイゼンハワーマトリクス
    • KGI/KPI
    • ノーススターメトリック
    • 先行指標
    • KPIツリー
    • リリースした機能をモニタリングする
  • スピードと品質のバランス
    • 品質とは
      • ユーザーの期待のちょっと上を行ってればいい
      • 簡単に直せるものと難しいものがある
        • データモデルなどは最初のうちにしっかり考えた方がいい
    • スピードと品質は両立する
  • ユーザーヒアリング
    • 仮説を作ってからインタビューする
    • 定量調査
    • 仮説が正しくないことも貴重な情報

spanner-cli: command not found

Cloud Spanner

Homebrew で Go はインストール済みだったので、spanner-cli の README を参考にインストール。

github.com

$ go version
go version go1.21.6 darwin/arm64
$ go install github.com/cloudspannerecosystem/spanner-cli@latest
...

しかし、spanner-cli: command not found になってしまう...。

で、spanner-cli の README にある Install Go を見たら PATH を設定してねって書いてある。Go ってそういうものなのか。

export PATH=$PATH:$HOME/go/bin

現場からは以上です。

その他

spanner-cli で Cloud Spanner にアクセスして SQL を実行する。GCP コンソールの Spanner Studio でもトランザクション管理できるといいんだけど。

$ spanner-cli -p {PROJECT} -i {INSTANCE} -d {DATABASE}
Connected.
spanner> BEGIN;
Query OK, 0 rows affected (0.03 sec)

spanner(rw txn)> ...(略)
Query OK, 1 rows affected (0.34 sec)

spanner(rw txn)> COMMIT;
Query OK, 0 rows affected (0.04 sec)

spanner> exit;
Bye

2023年のふりかえりと2024年に向けて

雑記

年末年始は帰省先で過ごしています。

2023年早々に中学時代からのヒーローが逝ってしまった。2023年はずっとこの喪失感を引きずってしまった。R.I.P.

2022年のふりかえりと2023年に向けて - kntmr-blog

今は5-6名程度のチームなので、改めてスクラムチームとしてチームビルディングして開発をリードしたいお気持ち。

2023年前半は5-6名のチームの開発をリードするのが主な役割でした。不確定要素が多くて生産性は決してよくはなかったけど、メンバーがリズムよく開発できるような動き方がそこそこできたような気はする。たぶん。

後半はプロジェクトの方針転換と体制変更があり、リーダーからプレイヤー寄りに。機能開発よりは基盤構築周りのタスクを受け持つことが多くてインフラ周りの知見は増えたと思う。以前はインフラ周りのタスクは SRE チームに依頼することが多かったが、プロダクトチーム内でできることが増えたという意味では Embedded SRE としての役割を担えたと言ってもいいんだろうか...。

あと、会社でエンジニア Hub に Terraform 記事を寄稿することになり記事の一部を書いた。文章を書くのは好きな方なので楽しかったです。

とはいえ、仕事では思い悩むことも多くてそこそこ大変だったし、プライベートでは引っ越しもあってバタバタしたりで、個人的に趣味に興じる時間と気力はなかった。2023年はあまりいい年とは言えなかったような気がする。

今年からまた組織体制が変わりチームリードとテックリードを担う感じに。プロジェクトは去年から継続する感じだけど領域は少し変わる。メンバーは10名程度で、参画して間もないメンバーもいるので改めてチームビルディングからやっていきたい。というわけで、年末年始はこの本を読んでます。

gihyo.jp

あと、これまであまり関わってない領域をテックリードとして見ることになりそう。ただ、品質管理は既存の知見のあるメンバーに任せて、まずは自分は開発プロセスを整理していこうかと。