第8回東京Redmine勉強会の感想 #redmineT

第8回東京Redmine勉強会の感想をメモ。
興味のあることだけ書く。

【参考】
第8回勉強会 - redmine.tokyo

第8回東京Redmine勉強会 #redmineT - Togetterまとめ

第8回redmine.tokyo勉強会に行って来た #redmineT - やっさんメモ

redmine.tokyo 第8回勉強会に参加しました(#redmineT) - torutkの日記

【1】今回の勉強会は、テーマが玄人向けの話が多かったので、Redmineを既に運用されている人にとってはツボにはまったと思う。
逆に、Redmine初心者の観点では、レベルが高すぎて理解しにくかったかもしれない。
でも、現時点のRedmineでのノウハウはある程度出し尽くせたと思う。

個人的に今回の勉強会で感じたことは二つある。

【2】一つは、Redmineのチューニングを駆使すれば、200万件のチケットでも業務で使える可能性が高い点。

【2－1】@akahane92さんの計測データでは、OOBGCのおかげでRuby2.2を使うと画面レスポンスが高速化される。
また、Rails4.2にするとマルチスレッド化による内部改善のおかげで、約7％ほど高速化されるらしい。
つまり、RubyやRailsのミドルウェアをバージョンアップする恩恵が受けられる。

【2－2】実は、Redmineは、Ver2.6に至るまで一貫して性能が劣化してきたらしい。
おそらくその原因は、度重なる機能追加と性能要件の対応が後回しになったからだろう。

しかし、3.0では、2.6よりもRedmineの性能が改善されているらしい。
つまり、Ver3以降では、Redmineの性能改善も改善テーマの一つとしてJPLは捉えられていると思われる。

【2－3】Redmineのミドルウェア本体のチューニング以外に、サーバーにSSDを使う対策もある。
SSDを適用すると、3.0では明確な性能改善があった、とのこと。
最近は、SSDも安くなってきたから、数年後にはサーバーにSSDをまるごと入れる手段もありえるだろう。

【2－4】但し、Redmineの性能要件で一番のボトルネックは、全文検索機能だろう。
全文検索だけは、SSDにしても効果がなかった、とのこと。
以前から、@akahane92さんはチケットが20万件を超えると、Redmineの全文検索機能の応答時間が大きくかかるようになり、業務に支障が出るとお話されていた。

おそらくJPLもこの点は気づいており、内部リファクタリングによるチューニングや、デフォルトでは全文検索しないように検索条件を絞っておくなどの改善を行なっているようだ。

Redmine 3.0新機能紹介: 検索機能の改善 | Redmine.JP Blog

@akahane92さんの講演では、Redmine本家チケットのどこかで、JPLがRedmineがMySQLからPosgtresSQLに近い将来変更する理由として、PostgresSQLのマテリアライズド・ビューを使って全文検索を高速化する手法を使うのではないか、と言われていた。

Oracleではマテリアライズド・ビューを使うことで、トランザクションテーブルの検索を高速化する手法はよく使われるが、PostgresSQLでもその機能はあるから、上手く使えば対応できると思われる。

PostgreSQLのマテリアライズドビュー

SIOS "OSSよろず" ブログ出張所: PostgreSQL : マテリアライズドビューを利用した設計

※@akahane92さんの資料では、下記チケットのコメントに記載があるらしい。
Defect #15781: Customfields have a noticable impact on search performance due to slow database COUNT - Redmine

【2－5】以前のバージョンのTracは1案件ごとに環境構築していたが、情報がサーバーごとに散在してしまう弱点があった。
一方、Redmineは一つのサーバーだけで、一案件だけでなく、一つの組織の全ての案件を管理できることで、情報をRedmineだけに集約できる。
つまり、Redmineは、ソフトウェア開発企業の基幹系業務システムになりうるわけだ。
それによって、開発案件の企画段階から、開発・保守に至るまで、全ての工程の作業と情報を一元化できるメリットが生まれる。

すると、Redmineが組織全体で使うとなると、ユーザも案件もチケットの数も膨大に増え、性能悪化によって業務に支障が出てくるリスクが出てくる。
せっかくRedmineに蓄積したデータも、好きな時にすぐに検索したり更新できなければ意味が無い。

しかし、以上の話を踏まえると、Ruby・Rails・DB、Apacheなどのミドルウェア、SSD導入や仮想環境でのCPUコア数の追加などによって、Redmineの性能改善は可能という評価といえる。
これは大きな希望だ。

はてなブックマーク - ledsunのブックマーク - 2015年5月17日　130 projects, 350 users, 3000 tickets/month の規模のRedmine運用って世界でも有数なのでは？

【3】もう一つは、Redmine本体の品質は割と高いのではないか、という点。

【3－1】@akahane92さんの話では、RedmineのException検知プラグインを使っているが、Redmine本体の障害は今までほとんど検知したことがない。
障害のほとんどは導入したプラグインばかりだった、とのこと。

※Redmineプラグイン集 - r-labsを見ると、下記のプラグインと思われる。

PluginExceptionHandler - Redmine

【3－2】@g_maedaさんに聞いた所によれば、JPLのRedmineの開発スタイルは非常に保守的である。
大幅な機能追加はやらないし、FunctionalTestが通らないパッチは受け取らない。
テストカバレッジは基本は100％になるまでリリースしない。

また、redmine はバージョンが上がっても見た目はあまり変わってない。
でも、ソースの中身は細かく対応されている。

その保守的な開発スタイルが、逆にRedmineの開発では有効に作用している。
実際、今までRubyやRailsのバージョンアップに追随できたのは、そのおかげではないか、と。

【3－3】@agilekawabataさんの講演では、数多くのオープンソースのツールの中で、Redmine はテストカバレッジが基本は100パーセント。
他ではあまり聞かない。
だから、Redmineは安心してバージョンアップに対応できる、と。

※下記で、Redmineの自動テストのビルド結果が公開されている。
エンタープライズ開発の観点で考えれば、世界中の人にテスト結果を公開しているのはすごいことだ。
普通はテスト結果は恥ずかしくて見せられない。

Redmine build status
Redmine code coverage
marutosi/redmine - Travis CI

【3－4】以上を踏まえると、RedmineのFunctionalTest、自動テスト環境がしっかりしているおかげで、単体テストレベルのバグはおそらくほとんど無いのだろう。

但し、Ver3に入って、3.0.3まで小刻みにリリースされているのは、細かなバグが見つかったため、その対応をしていたからだ。
Ver 3.0.3でようやく機能も落ち着いたのではないだろうか。

【3－5】そんなことを思うと、Redmineはオープンソースの中でも品質がかなり優秀な部類に入るだろうと思う。
Redmine本体の品質が良いと思われることによって、ユーザもRedmineに対して信頼度が増すだろう。
また、品質に自信があるからこそ、頻繁なバージョンアップも可能になるし、今後の機能追加もやりやすくなるだろう。

特に、RubyやRailsのバージョンアップにRedmineが追随していくことは、Redmineの寿命の観点で最重要だ。

例えば、Rubyは既に1.9のサポートが終了しており、2.0も来年にはサポートが終わってしまう。
つまり、セキュリティホールが見つかったとしても、Rubyの古いバージョンはサポートが受けられないため、古いRubyを使い続けることは非常にリスキーになってくるからだ。

すなわち、RedmineがSIの基幹業務システムになったとしても、Redmineのバージョンアップに追随していくことで、安定して使い続けられることを意味している。
Redmineは今後も進化していける条件が整っているからこそ、信頼して使える。

その信頼感があることは、RedmineがRailsのキラーアプリとして、またRailsが生み出したアプリの中でも優秀な部類に入るものとして評価できるだろうと思っている。

【追記】
主な資料は既に下記で公開されている。

Redmine.tokyo 08 questionnaire from Jun Naitoh

Redmineによるwebサポート窓口の実装と運用 from Go Maeda

Redmineチューニングの実際と限界 from Kuniharu AKAHANE

チケットの棚卸し ウチではこうしてます from 靖宏 田中

『うわ、Redmineバージョンが上がった！へなちょこプラグイン開発者はどうするか？』 from akiko_pusu

Redmine Ansible from ITO Yoshiichi

Redmine 300 310_new_feature from Jun Naitoh