2014/08/20にコワーキングスペース茅場町 Co-Edoで行われた「約10年最新版のRailsに追従してきた運用ノウハウをビール片手に聞きましょう！」のイベントで利用したスライドです。

1. 約10年年
2014年年08⽉月20⽇日
SonicGarden 安達輝雄
サービスを日々運用し続けながら
最新版のRailsに追従させる極意

2. 安達 輝雄 ( Teruo Adachi )
福岡出⾝身の⾃自称フルスタックエンジニア
teruo.adachi @interu
http://interu.hatenablog.com/

3. 約10年年、
開発／運⽤用してるサービス

4. http://www.skip-‐‑‒sns.jp/

5. • 機能開発／リリース
• バージョンアップ
• フレームワーク／ライブラリ（Rails／Gems）
• ミドルウェア（Apache／Nginx／Ruby／MySQL）
• サーバ（OS／IaaS）
• バックアップ（ログ／データ）
• 緊急対応（脆弱性／不不具合）
• ユーザサポート
⽇日々のサービス運⽤用で
やっていること

6. エンジニア視点で
もっとも 面倒 な作業は？？

7. • 機能開発／リリース
• バージョンアップ
• フレームワーク／ライブラリ（Rails／Gems）
• ミドルウェア（Apache／Nginx／Ruby／MySQL）
• サーバ（OS／IaaS）
• バックアップ（ログ／データ）
• 緊急対応（脆弱性／不不具合）
• ユーザサポート
不不具合出ると怒怒られる…
クリエイティビティがない…

8. ⾯面倒なことをやって
享受される 恩恵 は？

9. • OS／MW／FWの新機能を使えるように
→ 開発がラクに
→ 時代のトレンドに対応しやすく（ライブラリ充実）
• パフォーマンス向上
→ 開発／運⽤用がラクに
• オレオレメンテ不不要
→ 独⾃自パッチ不不要、パッケージ更更新がラクに
⾯面倒事よりもメリットの⽅方が⼤大きい

10. ⾯面倒なことをよりラクに
解決 できないか？

11. を例例に、
取り組みをご紹介

12. 2005 年年〜～ Rails 0系
開発開始
2007 年年〜～ Rails 1系
2008 年〜～
イントラからAWSへ移行
2009〜～2010 年年〜～ Rails 2系
楽天アワード2009受賞
フクオカRuby⼤大賞受賞
2012 年年〜～ Rails 3系
2014 年年〜～ Rails 4系
歴史

13. Rails 4化にフォーカスして
実施したタスクを紹介

14. （１）テストの最新化
• テストライブラリの更更新とテストコードの修正
• Rspec / cucumber

15. （２）影響範囲の⼩小さいライブラリの更更新
• 単機能のライブラリを少しずつ更更新
• Paperclip（ファイルアップロード）
• jQuery
• Ransack（検索索）
• … etc

16. （３）Rubyのバージョンアップ
Ruby from 1.9 to 2.1
• Linux OSの最新化
• 基本設定／セキュリティ設定
• Serverspec
• M/W設定⾒見見直し
• Apache / Nginx / Ruby
• アプリケーションの全体テスト
• 複数ブラウザで動作確認

17. （４）Rails 4へ向けたリファクタリング
• Rails 3系のままRails 4系に移⾏行行出来る箇所の改善
• confirm / disable_̲with
• vendor/plugins の廃⽌止
• named_̲scope 記法
• … etc

18. （５）Railsのバージョンアップ
• ⼤大変なところはのちほど対応するように
• ⾮非strong parameter（protected_̲attributes）
• ⾮非assets digest（non-‐‑‒stupid-‐‑‒digest-‐‑‒assets）
• DEPRECATION WARNINGの改善
• vendor/plugins の廃⽌止
• アプリケーションの全体テスト
• 複数ブラウザで動作確認

19. クソ真面目に、
１回のリリースで、
バージョンアップ
するのは大変

20. ラクするための取り組み
〜あぷりけーしょん編〜

21. （１）テストの最新化 （1回）
（２）影響範囲の⼩小さいライブラリの更更新 （5回）
（３）Rubyのバージョンアップ （1回）
（４）Rails4化へ向けたリファクタリング （3回）
（５）Railsのバージョンアップ
細かい単位でリリースするようにして
リスクを⼩小さく
①細かくリリースを実施
ラクするための取り組み
+ 迅速に切切り戻せるように

22. ②⽇日々の開発時から意識識
• 機能開発前にリファクタを実施
• 過去の負債を少しずつ返済
• テストコードの追加
• 不不具合を減らす、バージョンアップがラクに
• コードレビューの実施
• コードの負債を貯めこまないように
ラクするための取り組み

23. ラクするための取り組み
③動作確認をアウトソース
http://fjord.jp/
フィヨルドさまに協⼒力力いただき、
インターン⽣生に複数ブラウザでの動作確認を依頼

24. ④その分野の番⻑⾧長を巻き込む
• 番⻑⾧長をいい気分にしましょう
• 番⻑⾧長に頼ってみましょう
• 番⻑⾧長に感謝しましょう
『RspecによるRailsテスト⼊入⾨門』著者
ラクするための取り組み

25. ラクするための取り組み
〜いんふら編〜

26. ⑤サーバ運⽤用はPAASを積極活⽤用
EC2
OpsWorks
⽐比率率率
６ ： ２ ： ２

27. ⑥統⼀一プラットフォーム化
HerokuやOpsWorksなどのPaaSを利利⽤用しない場合は、
EC2で以下を実施
• ミドルウェアの統⼀一化
• リリース処理理を統⼀一化
• RDSの利利⽤用
アプリさえ⼊入れ替えれば動くようにしておくことで
サーバのOSリプレースもラクに
Serverspecも少なく！

28. ⑦旧版／新盤を同時稼働
• Rails 3版と Rails 4版のサーバを同時稼働
• 内部メンバのみRails4版を本番環境でテスト
ひと通りさわったら安⼼心して切切り替え

29. ラクするための考え方

30. • エラーゼロを⽬目指すのではなくすぐに改善してリ
リースできるように
• 守るべきところはしっかりテストを書いて担保
• サービスメンテによる停⽌止を許容する
• なるべく短くなるように努⼒力力はするが、ノンストップ
でないとNGとすることはしないようにすることで対
応コストを下げる
ラクするための考え⽅方
運⽤用／メンテにかかる負荷を下げつつ
考え⽅方に縛られないように

31. 完