【shownet.conf_2023】TTDB と Rails の10年間の振り返りとこれからshownet

shownet.conf_ での講演資料(TTDB)

Transcript

1. TTDB と Rails の10年間の 振り返りとこれから shownet.conf_ 2023 Interop Tokyo 2023 ShowNet NOCチームメンバー 高嶋健人
2. agenda • ShowNet と TTDB • 10年間でやったこと (2014 – 2023) • 開発し続けるための仕組みや考え方 • TTDB と Ruby / Rails の拡張 • TTDB のこれから/今後について 2
3. ShowNet と TTDB
4. ShowNetの特徴 • 約2週間という短期間で大規模イベントネットワークを構築 • NOC/STM/コントリビュータ: 約500人 • 約500人でのタスク管理と情報共有/集約 • 機器数: 400台以上 • 機器のポートやIPアドレスの管理 • 短期間で大量の機器への設定 • 出展社へのインターネット接続サービスの提供 • 出展社ごとの接続情報の管理
5. TTDB:トラブルチケットデータベース • ShowNet構築・運用支援のためのシステム • 各種情報の連携・統合管理 • トラブルチケット • 出展社情報 • ネットワーク機器情報 • 2003年から機能拡張しながら利用
6. Ruby on Rails • Ruby on Rails • Ruby 製の Webアプリケーションフレームワーク • 2005/12/13 Rails v1.0.0 リリース • 現在(2023/9時点)は Rails v7.0 • TTDB • 2006年ごろ(?)〜: Ruby on Rails を利用して開発・運用 • (Rails の機能拡張するコードのライセンスファイルを発掘)
7. TTDB の歴史 • 1990年代: OSS チケットシステム • 2000年ごろ(?): 掲示板 (Perl) • 2003年〜: 現在のチケットシステム形で TTDB 利用開始 • 2006年ごろ(?)〜: Ruby on Rails で開発・運用 • 2012年: 1年だけ Node.js 版 TTDB で運用 • 2014年〜: (TTDB 担当としてNOCチームに参加)
8. 10年間でやったこと (TTDB 2014 – 2023) レガシーな Rails アプリのリアーキテクトと、継続的な機能追加
9. レガシーな Rails アプリのリアーキテクト • 2014年時点で数年メンテナンスされていない状態 • バージョンが古い • Ruby 1.8 / Rails 2.3 (EoL) • UI 表示崩れ • 当時の最近のブラウザで表示が崩れる • スマホ未対応 • 開発環境で $ rails server するのもひと苦労
10. レガシーな Rails アプリのリアーキテクト • Ruby などのバージョンが古すぎてそのままアップデートで きない • やったこと • 新しく別の Rails アプリを作成してコードを移植 • 機能やコードの基礎部分はそのままに作り直し • UI 刷新・スマホ/タブレット対応
11. レガシーな Rails アプリのリアーキテクト • Rails / Ruby のアップデート • いきなり最新バージョンに上げれないので少しずつバージョンを 上げる • テストでエラーになる箇所を修正しながらアップデート • 複数メジャーバージョンアップで非互換の変更がたくさん • アップデートパス • Rails: v2.3 -> v3.2 -> v4.0 -> v4.1 • Ruby: v1.8 -> v1.9 -> v2.0 -> v2.1
12. レガシーな Rails アプリのリアーキテクト • レールに乗せる • 独自実装の機能を OSS のライブラリに置き換え • 認証(devise)、認可(pundit)、 ページネーション(kaminari)、 UI フレーム ワーク(twitter bootstrap)、etc… • あるものは作らない、ないものは作る • UI 刷新 • UI フレームワーク(Bootstrap)で作り直し • HTML の DOCTYPE の変更 (HTML 4.01 -> HTML5) • テンプレートエンジン(rhtml -> slim)の置き換え
13. レガシーな Rails アプリのリアーキテクト • テストコードの追加 • テストの自動化 • コードを移植するタイミングで、テストコードを追加 • レガシーコードからの脱却 • 「レガシーコード」の定義 • 「テストのないコード」 • (レガシーコード改善ガイドより)
14. Rails / Ruby の継続的なアップデート • メンテナンスポリシーの策定・運用 • Ruby / Rails / gem / npm / Node.js はなるべく最新を利用する • テストが通ることでアップデート後の動作を担保 • ShowNet 構築中にアップデート することも • 2023年は Hotstage 直前に rails 7.0.5 がリリース
15. Rails / Ruby アップデート • TTDB で利用した Rails / Ruby のバージョン Rails Ruby Node.js 2014年6月 4.1.1 2.1.2 2015年6月 4.2.2 2.2.2 2016年6月 4.2.7 2.3.1 2017年6月 5.1.1 2.4.1 2018年6月 5.2.0 2.5.1 2019年6月 5.2.3 2.6.3 2020年2月(開催中止) 6.0.2.1 2.6.5 12.13.0 2021年4月 6.0.3.6 2.7.3 14.16.1 2022年6月 7.0.4 3.1.2 16.17.1 2023年6月 7.0.5 3.2.2 18.14.1
16. 継続的な機能追加 • その年々で変化する要件 • ShowNet は、3-5年後に利用される技術に先駆けて挑戦している • まだ世の中にない仕組みが必要になることも多い • 機能実装だけでなく運用設計から必要 • 2017年 サービスチェイニング • 出展社ごとに適用するサービスの管理 • 2022年 リモートオペレーション対応 • SSO のための SAML IdP • 認可の前提の要件の変化
17. 10年間、開発し続けるための 仕組みや考え方 継続的なアップデート、式年遷宮、テスト、ドキュメント
18. 継続的なアップデートの必要性 • 最近のミドルウェアのライフサイクル • 毎年メジャーアップデート級の大きなアップデート • 2年で EoL (Ruby、Node.js など) • 脆弱性対応のセキュリティパッチリリース • 依存するライブラリの数: 約800 (gem/npm) • 月に1つはセキュリティパッチリリースされる • アップデートを溜めるほど対応の難易度が上がる • 複数メジャーバージョンアップ対応は大変 • ライブラリやミドルウェアのバージョンの依存関係のパズル
19. 継続的なアップデートの必要性 • 多岐にわたるアップデート対象 • Webアプリケーションフレームワーク: Rails • UIフレームワーク: Bootstrap • ミドルウェア: Ruby / Node.js • DB: RDB(PostgreSQL) / Redis • OS、コンテナベースイメージ、仮想化基盤、etc… • EoL スケジュールとの戦い
20. 継続的なアップデート方法 • 優先度をつけてアップデートしつづける • セキュリティパッチ • なるべく早く適用 • GitHub dependabot alert などでなるべく早く検知 • 主要ライブラリ(Ruby/Rails) • パッチバージョンが出たら適用 • 差分が大きいほどアップデート内容の確認が大変 • その他のライブラリ(gem/npm) • 定期的にアップデート(月1回など)
21. 式年遷宮 • ソフトウェアの式年遷宮 • 定期的にソフトウェアの一部を部分的に作り直すこと • 式年遷宮の目的 • 定期的に作り直す事によって耐用年数を伸ばすことができる • 定期的に作り直す事によって技術継承できる • Ruby/Rails の新しい機能や新しいライブラリなどを利用する ことで、過去に解決できなかった問題を解決できるように なることも多い
22. 式年遷宮 • TTDB では毎年、部分的に作り直し • Rails の新しいバージョンの仕組みに置き換え • 例. asset pipeline -> webpacker -> jsbundling-rails • 機能単位での置き換え • 例. 機器情報の論理モデル、チケット関連、UIナビゲーション、etc… • 作り直しのリスク • 必ずしもうまく作り直しが成功するわけではない • 失敗しても影響が少ないように「部分的」に作り直す
23. テスト • テストコードでテストを自動化 • 機能変更やRails/Rubyアップデートで、だいたいエラーなく動く ことを担保 • RSpec テストケース: 約3,000 • テストポリシー • どこで何のテストをするか 決めておく
24. ドキュメント • 目的 • 開発メンバーのオンボーディング • 設計上の判断の記録 • 内容 • 現状のシステム構成やポリシー • 機能追加変更の設計資料 • 将来、システムや機能を「捨てやすく」できる • 捨てやすく = 作り直ししやすく
25. ドキュメント: 設計資料 • Design Docs (or ADR) 風のフォーマット • 何を・なぜ・どのように作るかを記したもの • 問題点・課題 • 機能開発・改善の背景 • 選定した解決手段と、選定しなかった解決手段 • 選定の根拠、トレードオフ • ワークフローへの影響 • 既存のワークフローからの変更点と影響
26. TTDB と Ruby / Rails の拡張
27. TTDB で実装した Ruby/Rails拡張 • 2006年ごろから Ruby や Rails に足りなかった機能拡張を実 装して利用 • IPAddr / Hash クラス • Rails Cache • 認証/認可 • has_and_belongs_to_one
28. Ruby/Rails拡張: IPAddr クラス • Ruby: IPAddr クラス • Ruby で IP アドレスを扱うためのクラス • TTDB で Prefix や CIDR を利用できるように拡張 (2010年以前) • ipaddr-ext gem • TTDB で利用していた IPAddr クラスの拡張をまとめた ruby gem • https://github.com/interop-tokyo-shownet/ipaddr-ext IPAddr.new('2001:0db8::1') => #<IPAddr: IPv6:2001:0db8:0000:0000:0000:0000:0000:0001/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff> > IPAddr.new('2001:0db8::/32').to_s_with_prefix => "2001:db8::/32"
29. Ruby/Rails拡張: Rails Cache • Rails 4.1 時点では、Rails Low-Level Cache で利用できない キャッシュがあった • ActiveRecord::Relation のキャッシュキーが未対応 • キャッシュする仕組みを独自実装 • updated_at が最新のデータ1件のみ参照する仕組み • Rails 5.2 から導入された cache_versioning とほぼ同等の機能 • Rails 5.0 (2016/6リリース)で ActiveRecord::Relation 対応されたので 徐々に廃止中
30. ShowNet で遭遇した Ruby / Rails のバグ • Rails Low-Level Cache で大きオブジェクトを読み込むとエラーに なる • Rails 7.0 / Ruby 3.2 • 回避策 • Rails は 7.1 で修正予定 (Cache で Marshial を使わなくなる) • TTDB では、cache fetch 時に該当エラーが出たら、DB から値を取得す るように対応 • 似たような Issue • Ruby 3.2.1 500 errors | mastodon • https://github.com/mastodon/mastodon/issues/23644
31. TTDB のこれから 今後について
32. 未解決の問題 • ネットワーク機器のさらなる高密度化/仮想化への対応 • 機器情報仮想化/多様化対応のデータモデル再設計 • ポート情報のモジュールタイプとフォームファクタの分離 • ラック図の高密度化 • 運用負荷を上げずに、情報の密度を上げる仕組み • ポート割当て自動化、接続情報の俯瞰 • UI改善、パフォーマンスチューニング
33. TTDBのこれから • ShowNet の構築・運用を支援する機能の継続的な開発 • 機能開発を続けるための、継続的なアップデート • Rails 7.1、Ruby 3.3、Node.js v20、etc… • 毎年変化する要件への対応
34. まとめ • TTDBの10年間でやったことの振り返り • レガシーな Rails アプリのリアーキテクト • 継続的な機能追加 • 開発し続けるための仕組みや考え方 • 継続的なアップデート • 式年遷宮 • テスト • ドキュメント • TTDBのこれから • ShowNet の構築・運用を支援する機能の継続的な開発