in GCP |

CloudSQLとお友達になる

TL;DR

仕事でCloudSQLを触っているので知見を書く。

結論から言うと、GCP特有のポイントにいくつか気をつければ、あとはMySQLをチューニングするのと対して変わらない。

はじめに

パラメータはインスタンスタイプを変えたところで自動で変わってくれない。

なので、ちゃんとしたいなら自分で変えてあげる必要がある。ログはデフォルトでは吐き出さないので出力する設定＆ファイルに吐き出す設定にする、など。

query_cache_typeもデフォルトoff。もろもろパラメータの設定はアプリケーションにあわせて設定していかないと、インスタンスタイプあげてもお金の無駄遣いになる。

ちなみにinnodb_buffer_pool_sizeだけはCloudSQLは自動で変えてくれる。db-n1-standard-1のインスタンスはメモリ3.7Gとかだけど、2Gとかに勝手にあげてくれた。

ディスクサイズ

ある程度いっぱいになったら自動であげてくれる。もし心配なら自分であらかじめ256Gとか指定しておくこともできる。ただ、一度あがったディスクサイズは元に戻せないので「念のため1TB」みたいな使い方はやめた方がいいかも。

アプリケーションの運用を続けていて、状況をみてあげるのがいいと思う。自動であがっていくので、使い方には注意。

再起動/インスタンスタイプ変更

再起動は10秒ほど。一瞬で終わる。パラメータの変更時に再起動が必要なものとかあれば深夜に1時間ほどとるか、あまり大量アクセスを前提としないなら平日昼間とかにやってもいいんじゃないかなとかいう肌感。

インスタンスタイプ変更は5分ほどかかる。AWSでは割と時間かかった気がするけど、この辺はGCPは優秀。

VPC / ネットワーク

独立したネットワークに存在しているらしい。なのでVPCにいるGCEインスタンスとかからローカルIPでアクセスさせたいなら、自分のVPCとCloudSQLのネットワークをピアリングさせる必要がある。AWSでは好きなネットワークにRDSを作れたけど、こういうところ知らないと混乱するので注意。

グローバルIP

実はついている（なんだって）

設定でグローバルIPからアクセスできないようにできるが、すると手元からCloudSQL Proxyでアクセスして、クエリ流すとかはできなくなる。ただし、VPC内からピアリングさせておくと、VPC内のインスタンスから普通に接続できるので、個人的に静的IPアドレスのアクセスはOFFにして、踏み台専用GCEインスタンスを用意してローカルネットワークでのアクセスが個人的にはいいかな。

公式によると通信量もかからず、速度も早い。

インスタンスタイプ

この辺に書いてある。

https://cloud.google.com/sql/pricing

東京リージョン、割とお高めなので、個人で使う時はアメリカのほうのでもいいかも。日本のプロダクトなら頑張って東京リージョンつかってねって感じ。

ただ本番ではdb-g1-small* / db-g1-microは絶対使いたくない。DBのCPUを他社と共有とか怖すぎる。

ログインユーザ

コンパネからぽちぽち作る。基本root権限で作成される。ちなみにterraformでは作れない。

アクセス範囲も指定しないといけないので、注意が必要。個人的にはローカルからのみ接続にして、ローカルネットワークでの接続がいい。

パラメータ

最初に書いたけどデフォルト値があり、innodb_buffer_pool_size以外はインスタンスタイプをあげさげしてもそのまま。インスタンスタイプあげてもいい感じにしたいならパラメータをきちんと設定してあげる。お金で叩くだけでは解決しない。そしてデフォルト値はみたかんじあまりいけてないので、最低限設定はしたい。

connect_timeoutとかのtimeout系は設定しても変更できなかった。

変更できる値は公式に書いてあるからそちらを参照

https://cloud.google.com/sql/docs/mysql/flags?hl=ja

個人的にこの辺りは変更してもいいかなとは思った。数字はデフォルト値。

max_connection = 4030
wait_timeout = 28800
thread_cache_size = 48
slow_query_log = OFF
long_query_time = 10
query_cache_type = OFF
query_cache_limit = 1M
query_cache_size = 1M
join_buffer_size = 256K
read_buffer_size = 128kb
read_rnd_buffer_size =256k

join_buffer_sizeの変更するくらいならアプリケーション側のクエリを見直したほうがいいとは思うけど、個人的には念のためくらい。max_connectionも普通のアプリケーションなら100〜200くらいでいいんじゃなかろうか。wait_timeoutは正直8時間もいらないので1分くらいにしたかったが、なぜか変更が反映されなかった。固定で設定されているのかな。

query_cache_typeはシステムの要件にもよるので、なんとも言えない。僕が今まで関わっているところはOFFにするようなところはあまりなかった。ここは変更すると再起動が必要。

ログは全部OFFられているが、slow_logは出しておきたい。のでONにしたい。気をつけるとしたら、log_outputをFILEにするところ。こうしないとStackdriverに流れてくれない。ただしログを流せばながすほどStackdriverの使用料金はあがるので、general_logとかを有効にするのは深掘りしたい時だけにしておきたい。

第二世代と第一世代があるんだけど、第二世代のパラメータは結構beta版がおおかったりする。すこし不安ではあるけれど、show variableしたら変更してくれていたので、大丈夫なのかも。

Terraform

注意点としてはパラメータはdatabase_flagという項目で変更されるので、CloudSQLのことを書く場所にきちんと明記すること。VPCとピアリングするか、ローカルネットワークでの接続はできるようにするかなどの設定も書く。google_sql_database_instanceの項目のなかにsettingsというのがあるので、そこに延々と羅列していく。本番、ステージングとわけるだろうなので、環境ごとの変数にしておく。

そうしないと手動でパラメータ設定したら、次ながしたら全部リセットとかあり得るので注意。

概要にあるグラフ

CloudSQLのインスタンスを選択して最初にいくページのグラフ。

正直あまりあてにならないという感じはうけたが、参考くらいには見ておくといい気はする。過去は瞬間最大風速ではなく平均が表示されるので、ちゃんと測定するならログはきちんと出すことがおすすめかな。

バックアップ

自動バックアップと手動バックアップができる。

自動バックアップは1日に1回、好きな時間が指定できる。7日まで保存できてあとは削除される。

ポイントインリカバリも有効にできる。こっちはバイナリログを有効にする必要があって、最初は再起動が必要。ただ一旦有効にしてしまえば1秒単位で前に戻れる。

まとめ

GCP特有の癖を理解できればそれほど難しくはない、むしろ僕的にはRDSより親切で使いやすい。起動速いしメンテナンスもRDSより苦しくないだろう。

ただしドキュメントはあまり親切ではない印象をうけたので、そこは頑張ってほしいなと思った。

Published