Slide 1
Slide 1 text
2ヶ月かかるDBアップグレード検証を最大2週間に
短縮した自作Go製CLIツール「Platinum」を紹介する
Introducing a Go CLI tool "Platinum"
that shortened DB upgrade validation
Slide 2
Slide 2 text
● Joined Money Forward in October 2021
● Responsible for reliability of HR related products.
● At SRE NEXT 2022, I presented "How to start SRE in
a product team, all by yourself"
https://speakerdeck.com/vtryo/how-to-start-sre-in-
a-product-team-all-by-yourself
● At the Developers boost 2023, received the best
speaker award
https://speakerdeck.com/vtryo/career-planning-starti
ng-by-luckly
VTRyo（リョウ / Rio）
Slide 3
Slide 3 text
● 拙著「ITエンジニアのための偶然から始めるキャリアプ
ラン」etc
I am the author of “Career Planning for IT Engineers
Starting from serendipity”, etc
● 🍜, 🍛, 🍺
I eat curry or ramen almost every day. Beer is my
default.
VTRyo（リョウ / Rio）
Slide 4
Slide 4 text
マネーフォワード クラウドの人事労務領域やってます
I’m working on the HR and Labor area of the Money Forward
Could series.
Cloud Payroll
Cloud Attendance
Cloud personal management
Slide 5
Slide 5 text
● データベースエンジンを変更するとき
に実施している"pt-upgrade”
● 繰り返されるヘビーな運用作業を解決
するために Platinum というCLIツー
ルが生まれた
● 自分たちのためにツールを作ってどう
なったか
目次
Agenda
● “pt-upgrade” performed when
changing database engine.
● A CLI tool called Platinum was
created to solve repetitive and
heavy operational tasks.
● What happened when we created
this tool for ourselves.
Slide 6
Slide 6 text
● DBエンジンを変更するとき、高い可用
性を維持するためにやっていること
● 何に2ヶ月かかったのか
● 時短のアプローチ方法
● Platinumの機能例
今日の話でわかること
Takeaways from today's presentation
● What we do to maintain high
availability when changing DB
engines
● What took two months?
● Approaches taken to shorten the
time
● Examples of Platinum’s features
Slide 7
Slide 7 text
● AWS, Go, Terraformなどの使い方
● CLIの実装詳細
話さないこと
Things I won’t talk about today
● How to use AWS, Go and
Terraform
● Details of the CLI
implementation
Slide 8
Slide 8 text
©tottie / Renée French
Slide 9
Slide 9 text
DBエンジンを変更するとき
When changing the DB
Slide 10
Slide 10 text
● パフォーマンスが劣化しない
● クエリの互換性がある
● 非推奨クエリや非推奨パラメータがな
い
→ Percona社が開発している
"pt-upgrade"を利用してチェック
DBエンジンを変更するとき確認していること
What to check when changing a DB engine
● No performance degradation
● Query compatibility
● No deprecated queries or
parameters.
→ Use 'pt-upgrade' developed by
Percona to perform the checks
Slide 11
Slide 11 text
pt-upgrade とは？
What is pt-upgrade?
Slide 12
Slide 12 text
Percona Toolkit - pt-upgradeを採用
● 異なる2 version間で互換性をチェック
するベンチマークツール
● 2台のサーバでクエリを実行し、有意
差をレポートする
● slow.log, general.log, binary,
tcpdumpなどにも対応
互換性とクエリパフォーマンスチェックするために
To check compatibility and query performance
The Percona Toolkit - Adopt pt-upgrade.
● A benchmarking tool to check
compatibility between two different
versions.
● Run queries on two servers and
report significant differences.
● Supports slow.log, general.log,
binary, tcpdump.
Slide 13
Slide 13 text
Perconaのブログ
The Percona’s blog about pt-upgrade.
Arunjith Aravindan, Two Extremely Useful Tools (pt-upgrade and checkForServerUpgrade) for MySQL Upgrade Testing,PERCONA, August 29,
2022, https://www.percona.com/blog/two-extremely-useful-tools-pt-upgrade-and-checkforserverupgrade-for-mysql-upgrade-testing/
Slide 14
Slide 14 text
どのようにpt-upgradeを使うか
How to use pt-upgrade?
Slide 15
Slide 15 text
検証概要
Verification summary
general.logを2つのDBに流して
レポートを生成する
Send general.log to two DBs
and generates reports
Slide 16
Slide 16 text
pt-upgradeのコマンド例
Example command for pt-upgrade
filter 引数の例。本番環境では30個以上パイプしている
Example of filter argument. More than 30 are piped in production
environment.
Slide 17
Slide 17 text
生成されるレポート例
Example of generated reports
Slide 18
Slide 18 text
かんたんですね？
Easy, isn't it?
Slide 19
Slide 19 text
このレポート結果を得るまで…
It took to get the results of
this report...
Slide 20
Slide 20 text
2ヶ月もかかっている
almost two months.
Slide 21
Slide 21 text
なぜこんなに時間がかかっているのか
Why did it take so long?
Slide 22
Slide 22 text
● 社内制約を考慮した構成が必要だっ
た
● pt-upgrade実行準備の手間の多さ
● pt-upgrade実行中の手間の多さ
● 外部要因
なぜこんなに時間がかかったのか
Why did it take so long to verify this?
● The configuration needed to take
internal constraints into account.
● Preparation for pt-upgrade
execution required time and
effort.
● Running pt-upgrade required
time and effort.
● external factors.
Slide 23
Slide 23 text
● 本番環境のデータはProductionの
AWSアカウント上でしか扱えない
● 本番環境に影響しない形で検証できる
環境を構築するためのトライアンドエ
ラーに長時間使った
● 検証の度にDBを消したり作ったりする
だけでもTerraformで大幅変更が必
要だったりした
その1, 社内制約を考慮した構成が必要だった
No.1 The configuration needed to take internal constraints into
account.
● Production data can only be
handled on the Production AWS
account.
● We spent a lot of time on trial and
error to build an environment that
could run the verification without
affecting the production
environment.
● Just deleting and creating a DB for
each verification required major
changes in Terraform.
Slide 24
Slide 24 text
● 本番DBでgeneral.logを出力する
● 本番DBのSnapshotを取得する
● 新旧のDBインスタンスを作成
● これらのDBにアクセスできるサーバと
ネットワークの設定
（続く……）
その2, pt-upgrade実行準備の手間
No.2, Preparation for pt-upgrade execution required time and effort.
● Output general.log in the
production DB.
● Get a snapshot of the production
DB.
● Create old and new DB instances.
● Configure server and network
settings to access these DBs.
(continued…)
Slide 25
Slide 25 text
● general.logをpt-upgrade実行サー
バにダウンロードする
● 分割されたgeneral.logをひとつに結
合する
● pt-upgrade実行用のオプションを選
定する
その2, pt-upgrade実行準備の手間
● Download general.log to
pt-upgrade execution server.
● Merge the split general.log into
one file.
● Select options for pt-upgrade
execution.
No.2, Preparation for pt-upgrade execution required time and effort.
Slide 26
Slide 26 text
● pt-upgrade実行開始
● filterオプションが足りないと
pt-upgradeがエラーで止まるので
その都度オプションを追加する
● 完了したかどうか逐一EC2インスタン
スにログインして見に行く
その3, pt-upgrade実行中の手間
No.3, Running pt-upgrade required time and effort
● Start pt-upgrade execution
● If the filter option is missing,
pt-upgrade will stop with an
error, and options need to be
added each time.
● Log in to the EC2 instance to see
if pt-upgrade is completed.
Slide 27
Slide 27 text
● SnapshotはDBを停止して取得する
必要があったので夜間メンテナンス作
業が必須
-> general.logの開始地点と
Snapshotの断面を揃えるため
● メンテナンス実施調整
● 夜間ローテーション調整
その4, 外部要因
No.4, external factors.
● Since the snapshot required
stopping the database to be taken,
nighttime maintenance work was
necessary.
-> To align the starting point of
general.log with the cross-section of
snapshot.
● Coordination of maintenance
implementation.
● Setting up nighttime duty rotations.
Slide 28
Slide 28 text
初回利用時は大変な作業だった
Using pt-upgrade for the first time was
a very difficult task.
Slide 29
Slide 29 text
そして訪れた課題
And then the issue came
Slide 30
Slide 30 text
Amazon Aurora MySQL 互換エディション バージョン 2
標準サポート終了
Amazon Aurora MySQL-Compatible Edition version 2’s
standard support ends
Slide 31
Slide 31 text
EOL対象のDBが4つ。締切に間に合わない
Four DBs subject to EOL
We couldn't meet the deadline
Slide 32
Slide 32 text
せめて外部依存のない範囲は時短したい
At the very least, we wanted to shorten the time,
where there are no external dependencies
Slide 33
Slide 33 text
● SREチーム内に閉じている範囲
● 1. 検証環境構築
● 2. general.logのダウンロードや加工
● 3. pt-upgradeコマンド（オプションや
接続情報なども含めて）の準備
こちらで制御できる範囲とは
What is the scope we can control?
● Scope closed within SRE team.
● 1. Buildingthe verification
environment
● 2. Downloading and processing
general.log
● 3. Preparation of up-grade
commands (including options
and connection information)
Slide 34
Slide 34 text
重要なのは制限の中でどう戦うか
The key was how we fight within constraints
Slide 35
Slide 35 text
時間的課題をソフトウェアで解決する
Solving time-related challenges using software
Slide 36
Slide 36 text
CLI - Platinumの誕生
CLI - Platinum was born
pt-upgradeのPtから元素記号を連想し
て命名
ロゴはChatGPTで生成
Named after the chemical symbol
Pt in pt-upgrade.
The logo was generated by Chat
GPT.
Slide 37
Slide 37 text
● 長くて多いpt-upgradeコマンド引数を
config.ymlで管理する
● general.logのダウンロード、結合、
フォーマットする
● pt-upgradeの実行
● Slackへ完了通知
Platinumの主な機能
Platinum’s main features.
● Manage long and numerous
pt-upgrade command arguments
in config.yml.
● Download, merge and format
general.log.
● Execute pt-upgrade.
● Notify completion to Slack.
Slide 38
Slide 38 text
専用Terraform moduleを作成
Create dedicated Terraform module
必要なAWSリソース構築を
module化したことで時間短縮に成
功
Successfully reduced time by
modularizing the required
AWS resource setup
Slide 39
Slide 39 text
自動構築するリソース
Automatically build
resources
本番アカウント内に隔離されたリソー
スを毎回作る
Create an isolated resource in
the production account each
time.
Slide 40
Slide 40 text
ポイントはpt-upgrade実行準備から実行開始までの見積もり変化
The key is the change in estimated time from preparation to start
of pt-upgrade execution.
Slide 41
Slide 41 text
繰り返し作業が減って、幸せになった
Less repetitive work made us happier!
Slide 42
Slide 42 text
ということで
So as the next step
Slide 43
Slide 43 text
Platinumに実装した機能をﾁｮｯﾄ紹介する
Here are some of the features we’ve
implemented in Platinum
Slide 44
Slide 44 text
● go v1.21
● AWS SDK for Go v2
● CLI tool: urfave/cli
○ https://github.com/urfave/cli
Platinum 基本情報
Platinum basic information
Slide 45
Slide 45 text
Platinumの機能例 1
Platinum Features Example 1
ログの定期ダウンロード
downloadCompleteLogFile
へリクエストしている
Periodic log download.
Requests to
downloadCompleteLogFile.
Slide 46
Slide 46 text
● AWS CLIで利用できる
DownloadDBLogFilePortion
ファイルサイズが1MBまで
● CloudWatch logsがS3へ転送してダ
ウンロード可能
● REST endpoint
downloadCompleteLogFile
サイズに関係なくダウンロード可能
ログダウンロード方法はいくつか選択肢がある
There are several options for downloading logs.
● DownloadDBLogFilePortion
available in AWS CLI. File size up
to 1MB.
● CloudWatch logs can be
transferred to S3 for download.
● REST endpoint
downloadCompleteLogFile can
be downloaded regardless of size
Slide 47
Slide 47 text
● 一度に取得するログ行数を50行など
に分割してループで取得する実験をし
たがスロットリングエラー発生
● 仮に1行のサイズが1MBを超えた場
合は切り捨てられるはず
● aws-sdk issue "RDS log message
was truncated by
downloadDBLogFilePortion"参照
なぜDownloadDBLogFilePortionを使わないのか
Why not use DownloadDBLogFilePortion?
● We experimented splitting the
number of log lines to be retrieved at
a time to 50 lines and looping
through them, but a throttling error
occurred.
● If the size of one line exceeds 1MB, it
should be truncated.
● Refer to aws-sdk issue “RDS log
message was truncated by
downloadDBLogFilePortion”
Slide 48
Slide 48 text
● CloudWatch logsの最大イベントサ
イズが256KB
● 実際に1行がそのサイズを超えていた
ため不完全なログになった
なぜCloudWatch logsとS3を利用しないのか
Why not use CloudWatch logs and S3?
● Maximum event size in
CloudWatch logs is 256KB.
● One line actually exceeded that
size, resulting in incomplete logs.
Slide 49
Slide 49 text
● REST endpoint
downloadCompleteLogFile
サイズに関係なくダウンロード可能
● 自力でGETリクエストを生成する必要
がある
● https://docs.aws.amazon.com/ja_
jp/AmazonRDS/latest/AuroraUser
Guide/DownloadCompleteDBLog
File.html
なぜdownloadCompleteLogFileを使うのか
Why use downloadCompleteLogFile?
● REST endpoint
downloadCompleteLogFile can
be download regardless of size.
● Need to generate GET requests
on my own.
● https://docs.aws.amazon.com/A
mazonRDS/latest/AuroraUserGui
de/DownloadCompleteDBLogFile
.html
Slide 50
Slide 50 text
Platinumの機能例 2
Platinum Features Example 2
pt-upgradeコマンドをconfigで管
理する
Manage pt-upgrade
command using config
Slide 51
Slide 51 text
pt-upgradeコマンドはテンプレートを修正するだけで実行可能にした
pt-upgrade command can now be exectuted by simply modifying
the template.
Slide 52
Slide 52 text
● 長い、多い、は非常に読みづらい
● 何度もパラメータを変えて実行するこ
ともある。
眼精疲労を許容しがたい
● 最初はPlatinumの引数として渡そう
としていたが、YAMLを読み込む方向
性に変更した
持たせるパラメータが複雑だったためこの形に
The parameters to have were complex, so this is the form.
● Long, many, is very hard to read.
● Sometimes run with different
parameters many times.
Hard to tolerate eye strain.
● At first we were trying to pass
them as arguments to Platinum,
but changed direction to read
YAML.
Slide 53
Slide 53 text
Platinumの機能例 3
Platinum Features Example 3
Slackへ完了通知
いつ終わったかわざわざ調べに行かずに済
む
Notification of completion to Slack.
No need to go to check when it was
finished
Slide 54
Slide 54 text
©tottie / Renée French
Slide 55
Slide 55 text
AWS CLIの寄せ集めじゃだめなの？
Couldn't we have used a collection of
AWS CLI commands in a shell?
Slide 56
Slide 56 text
● Shell芸は避けたかった
というか最初の一回目からAWS CLIで
やっていた
● Shellよりも保守性がある
● 一連の作業をCLIにすれば他チーム
に展開できるポテンシャルがあった
● SREチームの開発能力向上に繋がる
ツール製作した理由とは
Why did we create the tool?
● We wanted to avoid using the shell
trick. We had actually used AWS CLI
since the first time
● Higher maintainability compare do
Shell
● There was potential to deploy to
other teams if a series of work was
done using CLI
● Improves the development
capability of the SRE team
Slide 57
Slide 57 text
自分たちのためのツールを作る効果
The impact of creating tools for ourselves
Slide 58
Slide 58 text
● コードネームを決めると案外テンション
上がる。愛着ってすごい
● "泥臭くてしんどい運用作業こそソフト
ウェアでなんとかするのもSREだ"とい
う初心を思い出す
● 需要が自分たちにある開発はそれだ
けで学びが大きい
● プログラミングを嫌がる人がいないの
で全員イキイキしていた
SREのSREによるSREのための開発
Development by SRE’s for SRE’s
● Deciding on a code name was
unexpectedly exciting. It feels great
to feel the attachment!
● Reminded us of the basics where “It
is SRE’s job to to manage
cumbersome and and tedious
operations using software
● Development where the demand is
on us is a great learning experience
in itself
● None of us dislike programming, so
everyone was very enthusiastic and
full of energy
Slide 59
Slide 59 text
ただしこれは序章に過ぎない
However, this is only the beginning
Slide 60
Slide 60 text
● メンテナンスモードやリリースのための
日程調整は別途必要
● レポートの分析は人間が実施する
● アプリケーションの修正が必要な場合
はその分の時間がかかる
● とはいえその前段が短くなっただけで
も非常に喜ばしい
時短したのはあくまで検証までである
The time was shortened only up to the verification
● Separate scheduling for
maintenance mode and release is
required
● Analysis of reports is performed by
humans
● If the application needs to be
modified, it will take time to modify
● However, we are extremely happy
we have been able to shorten that
first step!
Slide 61
Slide 61 text
©tottie / Renée French
Slide 62
Slide 62 text
No content