今日は、第8回勉強会 - redmine.tokyo に参加してきました。
場所は東京駅八重洲口南すぐにあるグラントウキョウサウスタワービルの41Fと超高層な場所でした。八重洲ブックセンターの向かいに割りと新しくできたビルです。
開会
参加者アンケート結果 の紹介からちょっとメモ。
- 使用しているRedmineのバージョンは、2.6が多く、3.0もそれなりに多い
- 使用しているバージョン管理ツールは1位がSubversion、割と肉薄して2位がGit
- 使用しているプラグインは1から6個の範囲が多い
定番のWiki extensionsとIssue Templateが人気でした。どちらも使っています。
Redmineによるwebサポート窓口の実装と運用
Redmine.JPサイトやRedmine入門本でおなじみの前田さんによる、Webヘルプデスクの運用紹介です。お客さんがWeb上で問い合わせフォーム(実はRedmineチケット)に入力するとサポート担当者がそれに回答をして、お客さんが得心したらクローズするという運用です。ポイントと思われる項目をメモします。
- お客さん入力フォームは項目を絞った(Webメールフォーム程度)
- 権限で読み取り専用にすると作成・編集時には見えなくなるようにできる
- お客さんは自分のチケットだけが見える(サポート担当は全て見える)
- お客さんは非メンバーとする権限制御、非メンバーの権限を減らす
- ワークフローは最小限
- カスタムクエリとしてステータス順・更新日順のグループ条件を提供
- 活動画面が便利(チケットのコメントがインデントされるので最後のコメントがお客さんの場合未返信として把握できる)
- メールをRedmineに登録するのはうまくいかなかった。題名がいい加減(過去の古いメールの返信で題名そのままとか)、全文引用メールとか
- チケットの表示でトラッカーの下にそのトラッカーの説明文章を挿入するプラグインを作成(次のURL)
https://github.com/farend/redmine_farend_support
Redmine標準機能で実現してるとのことです。
Redmineチューニングの実際と限界
関西で開催のRxStudyなどで以前からRedmineパフォーマンスチューニングを紹介していた赤羽根さんのセッションです。私にとっては本日の目玉セッションです。
情報系子会社で業務システム開発に携わる社員2百〜3百人がほぼ一日中使っているRedmine環境でのパフォーマンス向上/維持を対象としてチューニングの紹介です。
1台で運用している中でのチューニングなのでクラスタリング等は対象外です。
チューニングの対象としてのRedmineの使い方について、情報の一元化とIT統制や各種認証の監査に対応するための情報基盤を構築しているという所もすごいと思いますが、今回はチューニングのお話メインです。
まず、話がおもしろい&うまいです。
- 「Excelいじると受ける、これ世界共通」
- 「Redmineは文房具」
- 「お金をかけずに。稟議書書いたことないです。SSDだけお金だした」
- 「バージョン番号末尾が3になってから使う(Redmine 3.0.3)」
- 「production.logは大事にとっておく(性能解析の大事な資料)」
- 説明はデータドリブン、定量化の度合いが徹底
スライドの量も説明の量も相当な大きさなので、以下は200万チケットを格納したRedmineにおいてサクサクを実現する画面応答100msを目指したチューニングの紹介のメモです。
- RDBMS、アプリケーションサーバー、Webサーバー、バージョン管理サーバーを1箇所にまとめ、通信(Ethernet)を減らす
- 通信経路のEthernet帯域を見直す(Switch Hub化、Gigabit化)
- 通信データの削減
- HTTP圧縮。HTMLで100KB超、JavaScriptで300KB超になるので効果大
- Subversionも通信内容の圧縮
- キャッシュを最大限活用(メモリを潤沢に)
- Subversionにセッションキャッシュを指定
- ディスクをSSDにしてI/O処理を高速化(25%性能向上)
- チケットはシンプルに(性能だけでなく、200人もいては複雑なチケットは使い方を周知できないため)
- 仮想インスタンスで本番、テスト
- Redmine 3.0での最速な構成は、Ruby 2.1.6でOOBGCを使い、MySQLのバッファサイズは8GB
- Ruby 2.0から2.1/2.2で20%アップ
- Redmine 2.6から3.0にアップすると7.4%性能向上
- プラグインの多くは画面処理にHookで割り込みかけるので応答性能に影響するものがある。不要なプラグインは削除する。
- 全文検索は20万チケットが待てる限界、それ以上は数分から数百分かかる
- MySQL(PostgreSQL)はデフォルト設定のままではなく設定を変更する。SQLiteはだめ(せいぜい1万件以下)
- WindowsでBitnamiのRedmineは、rubyが2.0、MySQLが32bit版と制約があり、せいぜい5万件までの運用
- カスタムフィールドは「(全文検索の)フィルタとして使う」をなるべく外す
- メール送信はAsync
- CPUはキャッシュが大きいもの
懇親会でいろいろ質問したメモ
Q&Aの時間がなかったので懇親会にていろいろ質問させていただきました。
- Unicornはメモリ喰い(メモリをがんがん使って性能を稼ぐ)
- Passengerはメモリは喰わない
- Apacheはプロセスモデル(スレッドモデルではなく)
- RbenvでRubyバージョン切り替え
- 仮想化ソフトウェアはVMware
- MySQLは5.6の一択、Buffer Pool save & loadを使うため
- OOBGCは、Passengerの設定で実現
- SSL化はしていない
- コアは物理コア
- 100msの応答性能を達成することで、窓口4つでも200人を捌ける
- 添付ファイルはたくさんあるがサイズ上限を30MBにしている。それより大きいものはファイルサーバーに置いてUCNをチケットに記載
- 差分をとってうれしいファイルはSubversionに入れる
- バックアップはmysqldump、差分ではなく毎回全部
- 200万レコードでも容量は十数GB
- 添付ファイルのバックアップはrsyncで差分のみコピー
- 監査上、チケットの削除は許されないので、チケット削除権限は外している
- 削除したいという声多し、それには理由を書いてクローズしてもらっている
- 説明欄が少ないチケット、不要チケットは全文検索対象にならないよう凍結プロジェクト
- MySQLからPostgreSQLへのデータ移行は確立済み
- 「情報を預けると倍になって返ってくる」というシステムが理想
Lycheeの紹介など(アジャイルウェア)
最初に製品紹介の動画を流していましたが、ぼんやりしていて(前のセッションのクールダウンで脳が非活性化)内容を聞いてませんでした。
今週開催されていたIT Weekに出展、タレント(辻村ゆりなさん)も起用。デブサミ等と違って来場者はスーツを着た管理職(のおじさん)なので営業戦略。My.Redmineに対抗?
昨日会社で同僚にRedmineのガントチャートプラグインですごい便利なのあるから使いたい!と言われたのがこのLycheeガントチャート、でも有償なので、草の根Redmineに入れるのは厳しいかも。機能強化されて、この夏でる版ではガントチャート上に線を引っ張ってチケットができるそうです。
有償のプラグインだけではないですよ、と紹介。でも上位機能の有償版を今後作る予定とのこと。
ディスカッション
すこし抽象度が高いお題だった気がします。それでもいろいろ意見が聞けました。
Redmine最新動向〜3.0の変更点と3.1について
最近のRedmineのバージョンアップは、使い勝手の小さな改善が積み重なって使い勝手のよさにつながっているので、ひとことでバージョン3.0って何?と聞かれると答えられないので、このように変更点から要点を抽出した上で一つ一つ紹介していただけるとうれしいですね。
便利そうなと思った機能
- チケットのコピー時にコピー元/コピー先の関連を付けるか付けないか都度選択とするかを設定可能(グローバル)
- チケット作成時のデフォルトステータスをトラッカーごとに設定可能
- チケット・WikiのPDF出力時、{{collapse}},{{hello_world}},{{include}}マクロを展開。{{thumbnail}}, {{toc}}, {{child_pages}}は未対応
- ruby 2.2対応
- Wikiページを別プロジェクトへ移動可能
Redmine 3.0に早めにバージョンアップしたくなりますね。
懇親会
30人くらい参加していたようです。70人募集なので懇親会参加率50%というところでしょうか?
次回はもっとやさしい内容にしたいねという話もあがっていました。
懇親会のあとも、2次会、3次会と続いたようです。私は懇親会で離脱しました。