RedmineバージョンアップとともにDBMS変えてみた.pdf

Transcript

1. Redmineバージョンアップとともに DBMS変えてみた 2019/08/31 第20回 Redmine大阪 @ryouma_nagare
2. 自己紹介 • @ryouma_nagare（りょうま） • 今はインフラ系エンジニア＆マネージャ • Redmine/Ansible/ElasticStack/Zabbix/PostgreSQL • 好きなディストリビューションはVineLinux • redmine歴：８年 • redmine.tokyo スタッフ • 趣味：技術的人柱、監視、昔のガジェット
3. 質問！
4. Redmineのバージョンは？ ①4.0 ②3.x ③2.6以前 ④trunk
5. RedmineのDBMSは？ ①MySQL ②PostgreSQL ③上記以外
6. 今回やったこと
7. Redmineバージョンアップ＆DBMS変更 対象 以前 直前 今回 OS CentOS5→6→7 CentOS7 CentOS7 Redmine 1.3→2.0→2.2～ 3.3 3.4 4.0 DBMS MySQL5.1 →MariaDB5.5 →MariaDB10 MariaDB10 PostgreSQL11 Ruby 忘れた 2.4 2.5 Web/AP サーバ apache/passenger →nginx/unicorn nginx/unicorn nginx/unicorn
8. そもそも、なぜMariaDB？ ここを参考に初めてRedmineをインストール。 そのまま惰性でMySQL→MariaDBとしていた…
9. ということで4.0に向けて試行錯誤 embulkではダメなことも… pgloaderでOK！
10. おれは人間 MariaDBをやめるぞ！
11. 無事完了
12. 環境を変更したので メトリックを確認
13. 監視対象 ※サイジング／データ量 • ４コア／8GB • チケット数：５万強 • DBサイズ：１GB強 監視対象 監視方法 メトリック production.log logstash リクエストごとの処理時間 Rails ElasticAPM トランザクションごとの処理時間 サーバリソース Zabbix 一般的なサーバリソース access.log logstash 一般的なWebアクセス解析 DBMS Zabbix コネクション数、CacheHitRatioなど
14. 監視サーバ （Zephyranthes） 監視構成 Amazon Elasticsearch Service production.log解析 パフォーマンスメトリック収集 ダッシュボード
15. 可視化
16. production.log – active_record_time グラフの変化っぷりが 激しい
17. APM – max(duration) MariaDB10 PostgreSQL11 桁が変わった
18. APMで確認したSQLを投げてみる
19. 実行計画（サブクエリ部のみ） PostgreSQL11 -> Index Scan using idx_113458_enabled_modules_project_id on enabled_modules em (cost=0.28..1.31 rows=1 width=8) Index Cond: (project_id = wikis.project_id) Filter: ((name)::text = 'wiki'::text) MariaDB10 +------+--------------+-------------+--------+----------------------------+--------------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+--------------+-------------+--------+----------------------------+--------------+---------+------+------+-------------+ | 1 | PRIMARY | <subquery2> | eq_ref | distinct_key | distinct_key | 4 | func | 1 | | | 2 | MATERIALIZED | em | ALL | enabled_modules_project_id | NULL | NULL | NULL | 3499 | Using where | +------+--------------+-------------+--------+----------------------------+--------------+---------+------+------+-------------+ キーを使用せず、行数がふくれる →MySQL8でも実行計画は変わらず メインテーブルのキーを使用
20. Durationを比較 Duration(msec) 16029 12333 5604 遅いクエリも出てきたが、あき らかに体感で速い ※３週間経過後
21. サーバリソース CPU使用率 空きメモリ CPU／メモリの使用率低下はDB変更により フルスキャンが減ったためと想定 ※定期的にCPUが跳ねてるのはDBバックアップ バージョンアップ
22. ちょっとだけ不具合
23. オブジェクト名の64byte制限 移行時のWarningだけなので 特に問題ない
24. UTF8のCOLLATEの問題 気づいたところだけ対応 すればいいんじゃね？
25. 結論
26. の前に 対応いただいたプラグイン作者の みなさまに感謝です！
27. 結論 • ユーザに優しい機能が多いので、Redmineは4.0にあげよう ➢アクティブに更新しているプラグインを選べばバージョンアップについていけるはず ➢動かないプラグインは捨てる勇気も必要 • DBはできればPostgreSQLを使おう ➢速度的なメリットは大きい ➢MySQLではRedmineの既知の問題とか、ギャップロックとか、古いバージョンのパラメータデフォルト値とか … • 失敗の試行錯誤も、最新を突っ込みすぎたがゆえのバグを踏んだとしても、それはそれで ネタとしておいしい
28. APPENDIX
29. Qiita • Redmine4.0でプラグインの動作確認をした • Redmineのproduction.logを監視する • AmazonES、オンプレKibanaでRedmineのパフォーマンス監視を行う • RaspberryPi3のRedmine4.0.2のデータベースをMySQLからPostgreSQLに pgloaderで移行した
30. ふだんはこういう遊びをしています 石川さんありがとう @forenoonMありがとう
31. ご静聴ありがとう ございました