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

by ShowNet

Slide 1

Slide 1 text

TTDB と Rails の10年間の振り返りとこれから shownet.conf_ 2023 Interop Tokyo 2023 ShowNet NOCチームメンバー高嶋健人

Slide 2

Slide 2 text

agenda • ShowNet と TTDB • 10年間でやったこと (2014 – 2023) • 開発し続けるための仕組みや考え方 • TTDB と Ruby / Rails の拡張 • TTDB のこれから/今後について 2

Slide 3

Slide 3 text

ShowNet と TTDB

Slide 4

Slide 4 text

ShowNetの特徴 • 約2週間という短期間で大規模イベントネットワークを構築 • NOC/STM/コントリビュータ: 約500人 • 約500人でのタスク管理と情報共有/集約 • 機器数: 400台以上 • 機器のポートやIPアドレスの管理 • 短期間で大量の機器への設定 • 出展社へのインターネット接続サービスの提供 • 出展社ごとの接続情報の管理

Slide 5

Slide 5 text

TTDB:トラブルチケットデータベース • ShowNet構築・運用支援のためのシステム • 各種情報の連携・統合管理 • トラブルチケット • 出展社情報 • ネットワーク機器情報 • 2003年から機能拡張しながら利用

Slide 6

Slide 6 text

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 の機能拡張するコードのライセンスファイルを発掘)

Slide 7

Slide 7 text

TTDB の歴史 • 1990年代: OSS チケットシステム • 2000年ごろ(?): 掲示板 (Perl) • 2003年〜: 現在のチケットシステム形で TTDB 利用開始 • 2006年ごろ(?)〜: Ruby on Rails で開発・運用 • 2012年: 1年だけ Node.js 版 TTDB で運用 • 2014年〜: (TTDB 担当としてNOCチームに参加)

Slide 8

Slide 8 text

10年間でやったこと (TTDB 2014 – 2023) レガシーな Rails アプリのリアーキテクトと、継続的な機能追加

Slide 9

Slide 9 text

レガシーな Rails アプリのリアーキテクト • 2014年時点で数年メンテナンスされていない状態 • バージョンが古い • Ruby 1.8 / Rails 2.3 (EoL) • UI 表示崩れ • 当時の最近のブラウザで表示が崩れる • スマホ未対応 • 開発環境で $ rails server するのもひと苦労

Slide 10

Slide 10 text

レガシーな Rails アプリのリアーキテクト • Ruby などのバージョンが古すぎてそのままアップデートできない • やったこと • 新しく別の Rails アプリを作成してコードを移植 • 機能やコードの基礎部分はそのままに作り直し • UI 刷新・スマホ/タブレット対応

Slide 11

Slide 11 text

レガシーな Rails アプリのリアーキテクト • Rails / Ruby のアップデート • いきなり最新バージョンに上げれないので少しずつバージョンを上げる • テストでエラーになる箇所を修正しながらアップデート • 複数メジャーバージョンアップで非互換の変更がたくさん • アップデートパス • Rails: v2.3 -> v3.2 -> v4.0 -> v4.1 • Ruby: v1.8 -> v1.9 -> v2.0 -> v2.1

Slide 12

Slide 12 text

レガシーな Rails アプリのリアーキテクト • レールに乗せる • 独自実装の機能を OSS のライブラリに置き換え • 認証(devise)、認可(pundit)、ページネーション(kaminari)、 UI フレームワーク(twitter bootstrap)、etc… • あるものは作らない、ないものは作る • UI 刷新 • UI フレームワーク(Bootstrap)で作り直し • HTML の DOCTYPE の変更 (HTML 4.01 -> HTML5) • テンプレートエンジン(rhtml -> slim)の置き換え

Slide 13

Slide 13 text

レガシーな Rails アプリのリアーキテクト • テストコードの追加 • テストの自動化 • コードを移植するタイミングで、テストコードを追加 • レガシーコードからの脱却 • 「レガシーコード」の定義 • 「テストのないコード」 • (レガシーコード改善ガイドより)

Slide 14

Slide 14 text

Rails / Ruby の継続的なアップデート • メンテナンスポリシーの策定・運用 • Ruby / Rails / gem / npm / Node.js はなるべく最新を利用する • テストが通ることでアップデート後の動作を担保 • ShowNet 構築中にアップデートすることも • 2023年は Hotstage 直前に rails 7.0.5 がリリース

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

継続的な機能追加 • その年々で変化する要件 • ShowNet は、3-5年後に利用される技術に先駆けて挑戦している • まだ世の中にない仕組みが必要になることも多い • 機能実装だけでなく運用設計から必要 • 2017年サービスチェイニング • 出展社ごとに適用するサービスの管理 • 2022年リモートオペレーション対応 • SSO のための SAML IdP • 認可の前提の要件の変化

Slide 17

Slide 17 text

10年間、開発し続けるための仕組みや考え方継続的なアップデート、式年遷宮、テスト、ドキュメント

Slide 18

Slide 18 text

継続的なアップデートの必要性 • 最近のミドルウェアのライフサイクル • 毎年メジャーアップデート級の大きなアップデート • 2年で EoL (Ruby、Node.js など) • 脆弱性対応のセキュリティパッチリリース • 依存するライブラリの数: 約800 (gem/npm) • 月に1つはセキュリティパッチリリースされる • アップデートを溜めるほど対応の難易度が上がる • 複数メジャーバージョンアップ対応は大変 • ライブラリやミドルウェアのバージョンの依存関係のパズル

Slide 19

Slide 19 text

継続的なアップデートの必要性 • 多岐にわたるアップデート対象 • Webアプリケーションフレームワーク: Rails • UIフレームワーク: Bootstrap • ミドルウェア: Ruby / Node.js • DB: RDB(PostgreSQL) / Redis • OS、コンテナベースイメージ、仮想化基盤、etc… • EoL スケジュールとの戦い

Slide 20

Slide 20 text

継続的なアップデート方法 • 優先度をつけてアップデートしつづける • セキュリティパッチ • なるべく早く適用 • GitHub dependabot alert などでなるべく早く検知 • 主要ライブラリ(Ruby/Rails) • パッチバージョンが出たら適用 • 差分が大きいほどアップデート内容の確認が大変 • その他のライブラリ(gem/npm) • 定期的にアップデート(月1回など)

Slide 21

Slide 21 text

式年遷宮 • ソフトウェアの式年遷宮 • 定期的にソフトウェアの一部を部分的に作り直すこと • 式年遷宮の目的 • 定期的に作り直す事によって耐用年数を伸ばすことができる • 定期的に作り直す事によって技術継承できる • Ruby/Rails の新しい機能や新しいライブラリなどを利用することで、過去に解決できなかった問題を解決できるようになることも多い

Slide 22

Slide 22 text

式年遷宮 • TTDB では毎年、部分的に作り直し • Rails の新しいバージョンの仕組みに置き換え • 例. asset pipeline -> webpacker -> jsbundling-rails • 機能単位での置き換え • 例. 機器情報の論理モデル、チケット関連、UIナビゲーション、etc… • 作り直しのリスク • 必ずしもうまく作り直しが成功するわけではない • 失敗しても影響が少ないように「部分的」に作り直す

Slide 23

Slide 23 text

テスト • テストコードでテストを自動化 • 機能変更やRails/Rubyアップデートで、だいたいエラーなく動くことを担保 • RSpec テストケース: 約3,000 • テストポリシー • どこで何のテストをするか決めておく

Slide 24

Slide 24 text

ドキュメント • 目的 • 開発メンバーのオンボーディング • 設計上の判断の記録 • 内容 • 現状のシステム構成やポリシー • 機能追加変更の設計資料 • 将来、システムや機能を「捨てやすく」できる • 捨てやすく = 作り直ししやすく

Slide 25

Slide 25 text

ドキュメント: 設計資料 • Design Docs (or ADR) 風のフォーマット • 何を・なぜ・どのように作るかを記したもの • 問題点・課題 • 機能開発・改善の背景 • 選定した解決手段と、選定しなかった解決手段 • 選定の根拠、トレードオフ • ワークフローへの影響 • 既存のワークフローからの変更点と影響

Slide 26

Slide 26 text

TTDB と Ruby / Rails の拡張

Slide 27

Slide 27 text

TTDB で実装した Ruby/Rails拡張 • 2006年ごろから Ruby や Rails に足りなかった機能拡張を実装して利用 • IPAddr / Hash クラス • Rails Cache • 認証/認可 • has_and_belongs_to_one

Slide 28

Slide 28 text

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.new('2001:0db8::/32').to_s_with_prefix => "2001:db8::/32"

Slide 29

Slide 29 text

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 対応されたので徐々に廃止中

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

TTDB のこれから今後について

Slide 32

Slide 32 text

未解決の問題 • ネットワーク機器のさらなる高密度化/仮想化への対応 • 機器情報仮想化/多様化対応のデータモデル再設計 • ポート情報のモジュールタイプとフォームファクタの分離 • ラック図の高密度化 • 運用負荷を上げずに、情報の密度を上げる仕組み • ポート割当て自動化、接続情報の俯瞰 • UI改善、パフォーマンスチューニング

Slide 33

Slide 33 text

TTDBのこれから • ShowNet の構築・運用を支援する機能の継続的な開発 • 機能開発を続けるための、継続的なアップデート • Rails 7.1、Ruby 3.3、Node.js v20、etc… • 毎年変化する要件への対応

Slide 34

Slide 34 text

まとめ • TTDBの10年間でやったことの振り返り • レガシーな Rails アプリのリアーキテクト • 継続的な機能追加 • 開発し続けるための仕組みや考え方 • 継続的なアップデート • 式年遷宮 • テスト • ドキュメント • TTDBのこれから • ShowNet の構築・運用を支援する機能の継続的な開発