- Ruby / Rails関連
週刊Railsウォッチ: RubyのGCコンパクション改修、jemalloc、ReDoSの自動検出修正ほか（20220419後編）
こんにちは、hachi8833です。
🔗Ruby
🔗 GCコンパクションの2つのカーソル移動順序を入れ替え
- PR: Reverse the order of GC compaction cursor movement by eightbitraptor · Pull Request #5637 · ruby/ruby -- マージ済み
つっつきボイス:「先週のウォッチ（ウォッチ20220412）で取り上げたRecently in Ruby Core — March edition記事でこのプルリクを知りました」「お〜、スキャン用のカーソルと再配置用のカーソルがあって、後者を先に動かすことでGCの効率を高められる感じっぽい」「ちゃんと読まないとわからないけどアルゴリズム凄そう」「既にmasterにマージされているので次のRubyに入る流れですね」
https://github.com/ruby/ruby/pull/5637より
🔗 Rubyにシンボルがある理由（Ruby Weeklyより）
つっつきボイス:「RubyのシンボルをASTやVMなども掘りながら詳しく解説した記事です」「Rubyのシンボルは、文字列と違ってその都度のアロケーションが不要で比較が高速などの特徴がありますよね」
参考: class Symbol (Ruby 3.1 リファレンスマニュアル)
参考: Rubyのシンボルを丁寧に理解する
「たしかにシンボルはRubyの特徴的な機能」「他の言語であまり見かけませんね」「Matzが何かの言語からヒントを得たとどこかで見た気がする」「そうだったかも」
「今のRubyはコードに#frozen_string_literal: trueを書くことで同一の文字列リテラルが使い回されるようになったので、それ以前よりも文字列リテラルの効率が高まってシンボルに近づいたというのはあると思います: もちろんシンボルの方がIDEの補完での先読みが効きやすくなったりすると思いますし、シンボルは今後もRubyで使われるでしょうね」
後で探すと、Rubyのシンボルは主にLISP（Emacs LISP）に影響されたのではという指摘があります。"string".internで文字列からシンボルを生成できるのもEmacs LISPの影響のようです。Emacs LISPのシンボルリテラルは'symbolという記法で、概念や細かな部分も少しずつ違うようです。
参考: language design - Why did Ruby creator chose to use the concept of Symbols? - Software Engineering Stack Exchange
参考: GNU Emacs Lisp Reference Manual - シンボルの作成と interning
参考: LISP - Wikipedia
🔗 Rubyでjemallocを使う
- 元記事: Part1 「Rubyのメモリ肥大化はfragmentation（断片化）が原因（かもしれない）」
- 元記事: Part2 「Rubyのメモリ仕様 -ブラックボックスを覗く-」
- 元記事: Part3 「jemallocがRubyアプリケーションのメモリ利用効率を向上させるのか...？」
つっつきボイス:「以下のTechRacho記事が引用されていたことでこの記事を知りました」「実際にCRubyでjemallocを使ってみたんですね」「Redisはもうjemallocに移行しているのか」
「現在のCRubyではjemallocをデフォルトでは使いませんが（コンパイルオプションでの指定は可能）、たしかglibcか何かのライブラリとの関係にも影響するからデフォルトにしていないという話があった気がする」「ありそうですね」「このあたりうろ覚えですが、glibcのバージョン依存やOSのカーネル依存などにも関連していた気がします」「そういう事情があるんですね」「もちろん使いたければ自分で--with-jemallocオプションを指定してRubyをコンパイルすればよいと思います」
参考: GNU Cライブラリ - Wikipedia -- glibc
後で探すと、以下のissueで議論されています。かなり長いです。
参考: Feature #14718: Use jemalloc by default? - Ruby master - Ruby Issue Tracking System -- 現在オープン
🔗 moneta: さまざまなキーバリューのインターフェイスを共通化（Ruby Weeklyより）
つっつきボイス:「モネタ？」「キーバリューストアのインターフェイスを同じにしたい人向けなのかしら」
# 同リポジトリより
require 'moneta'
# Create a simple file store
store = Moneta.new(:File, dir: 'moneta')
# Store some entries
store['key'] = 'value'
# Read entry
store.key?('key') # returns true
store['key'] # returns 'value'
store.close
「対応リストを見ると、MemcadhedやRedisといったさまざまなバックエンドのキーバリューストアに共通のインターフェイスでアクセスできるんですね」「Berkeley DBという言葉もある」「ファイルシステムの項にはPStoreなども入っていますね」「PStoreって何でしたっけ？」「Rubyコアに標準で入っているファイルベースのデータストアライブラリです」「Pはpersistent（永続化）のPなのか」
参考: class PStore (Ruby 3.1 リファレンスマニュアル)
参考: Berkeley DB - Wikipedia
「monetoのような抽象化は、自分は使わないと思うけど使いたい人にはいいかも」「キーバリューストアのインターフェイスってそれほど複雑でもないし大きな違いもないですよね」
🔗 Rubyのアンチパターン: なんでもHash
せやね( ˘ω˘) / “Rubyアンチパターン: なんでもHash” https://t.co/4g8J0EUPJ4
— Watson (@watson1978) April 11, 2022
つっつきボイス:「なんでもHashは実はPHPにも同じアンチパターンがありますね」「そうそう」「イミュータブルなオブジェクトクラスを作るという対策は、@t_wadaさんのスライド『予防に勝る防御なし』（ウォッチ20220418）にも登場してた↓」
🔗 その他Ruby
nextstepとか今更いらねえだろと思うんだよなあ。でも消せないんだよなあ。https://t.co/X0mB0oGBrz
— 7594591200220899443 (@shyouhei) March 9, 2022
つっつきボイス:「NEXTSTEP以外にSolarisなんかもでもRubyが動くんですね」「Rubyのconfigureみたいなものは自分で触るのはつらいので自動生成したい↓」「使っている人がいる可能性がある以上なくしにくいのはわかる」
参考: configureの作り方(autotoolsの使い方） - のぴぴのメモ
「このドキュメントにサポートされているOSのリストがあった↓」「お〜、AIXやFreeBSDもRubyのサポートリストにあるんですね」「FreeBSDはさくらのレンタルサーバなど多くの場所でずっと使われているので当然あります」「そうそう」
参考: ruby/maintainers.rdoc at master · ruby/ruby
参考: AIX - Wikipedia
参考: さくらのレンタルサーバ FreeBSDのアップデートに伴う変更点 | さくらのサポート情報
「ところでNEXTSTEPって何ですか？」「OPENSTEPを経て今のmacOSの元になったOSですよ」「そうそう、スティーブ・ジョブスのNeXT社で作られた、macOSのご先祖」「う、それでしたか」「NSObjectのように、macOSのコードのあちこちにNSで始まる名前があるのはその名残ですね」
参考: NEXTSTEP - Wikipedia
参考: swift のNSArrayとかのNSの意味
🔗クラウド/コンテナ/インフラ/Serverless
🔗 2022年のAWSコンテナのスケーリング
つっつきボイス:「BPS社内Slackに貼っていただいた記事です」「そうそう、AWS Fargateの大規模なスケールアウト時の速度が以前より向上したようですね」
参考: AWS Fargate（サーバーやクラスターの管理が不要なコンテナの使用）| AWS
「ところで記事を読んでいると、Fargateを使っている人たちのほとんどはグラフのこのあたり（赤の点線囲み）↓のほとんど原点近くに収まるんだろうなという気持ちになりましたね」「まあたしかに」「縦軸のコンテナ数で最初の目盛りの500を超えることすら普通めったにないと思います」
同記事より（赤の点線囲みは編集部で追加）
「同じグラフのLambda（点線）はさすがに原点からほぼ垂直に急上昇している↑」「こうして見るとLambdaの立ち上がりの速さは凄いですね」
参考: AWS Lambda（イベント発生時にコードを実行）| AWS
🔗JavaScript
🔗 書籍『プロを目指す人のTypeScript入門』
これから読ませていただきます🙏 期待大!!https://t.co/izXhQ77zBd
— Junichi Ito (伊藤淳一) (@jnchito) April 14, 2022
つっつきボイス:「ブルーベリーとチェリー、なるほど」「来週発売で予約中ですって、買おうかな〜」「電書が出たら買いたい（編集部注: 既にKindle版も販売されています）」
「ところで、電書を予約で買いたい気持ちがあるんですけどあんまりやってないんですよね...」「電書の予約販売は、決済をいつ確定するかみたいな部分が結構複雑になっていることが想像できるので、取り入れにくいんじゃないかな」「あ〜ありそう」「物理本の予約販売なら既存の在庫管理や返金対応があると思うのでそれでできると思いますが、電子コンテンツの予約は本のような物理の商品といろいろ違っていそうな気がします」「電書を発売したらメールで知らせてくれるだけでもありがたいんですけどね」
🔗CSS/HTML/フロントエンド/テスト/デザイン
🔗 PSLとsession.cookieの変更
つっつきボイス:「これもBPS社内Slackに貼っていただいた記事です」「そうそう、これは大変そうな話: サイトのドメインをPublic Suffix List（PSL）↓に登録したのが始まりだったとあるけど、それでこんなことになるとはなかなか気付けなさそう」
「PSLには誰でもドメインを登録できるんでしょうか？」「ドメイン所有者なら、基本的に正式な手続きを経たうえでできるでしょうね」
「記事にもあるように、ドメインはTLD（Top-Level Domain）としてPSLに登録される↓のでCookieを保存できなくなる: TLDにcookieを保存できてしまうのはたしかにヤバい」「仮にco.jpにcookieが設定できたらどうなるかを考えれば、TLDのcookie設定が禁止されているのもわかりますね」「今どきはcookieがないと大抵のサービスが使えないので、ドメインをPSLに登録するなら、そのドメインで何もサービスしないぐらいの気持ちでいる方がよさそう」
ところで、 PSLに登録したドメインにはCookieを保存することができなくなってしまいます。
仮にjpのようなTLDに対してCookieを保存可能にしてしまうと、そのドメインを使用している全てのWebサイトでそのCookieを共有できることになってしまいます。TLDは不特定多数の利用者が様々な目的でサブドメインを取得して運用していることが多く、このような広範囲に対してCookieを参照可能な状態にしてしまうことはセキュリティリスクが高いため推奨されるものではありません。
同記事より
「問題が顕在化するのが数か月後というのも怖い」「PSLへの登録は慎重に行わないといけないという点では、HSTS（HTTP Strict Transport Security）↓のpreload listに登録するときと似ているところもありますね」「HSTSのpreload listに登録すると次のバージョンのブラウザに取り込まれて配布されるということですけど、PSLもそうなのか...」「どちらも、登録しても有効になるまでに時間がかかるし、一度ブラウザに取り込まれて世界中のユーザーに配布されると修正がものすごく大変」「うわ〜」
参考: Strict-Transport-Security - HTTP | MDN
参考: HTTP Strict Transport Security - Wikipedia
「どういうときにPSLに登録したくなるんでしょう？」「記事の冒頭を見るとマーケティングの都合で必要になったようですね↓」
ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。
（中略）
結論としてeTLD+1なドメインを認証することで合算イベント測定を使用可能になるということがわかったため、当時開発チームはショップ開設時に選択することができるドメイン群をPublic Suffix List（PSL）に登録するという対応を行っていました。
同記事より
参考: IDFAとは？| Adjustモバイルマーケティング用語集 | Adjust
「PSLに登録したことでまさかこんなことになるとは思わないでしょうね」「誰も悪くないのに...という感じ」「怖い」「これは知らないと踏んでしまいそう」「PSLやHSTSのような、ミスしたときのリカバリーが難しい機能は慎重に扱いたい」
参考: Public Suffix List の用途と今起こっている問題について | blog.jxck.io
「もっともHSTSについては、新規のWebサービスならほぼ確実にHTTPSで通信するでしょうから、HSTS Preload list↓に登録してHTTPS通信のみにすることについてはそれほど心配しなくてもいいと思います」「たしかに」
参考: HSTS Preload List Submission
🔗言語/ツール/OS/CPU
🔗 正規表現のReDoSを自動検出・修正
強そう。DoSにならない正規表現のサブセットを(形式的に)定義できたということだね
— 7594591200220899443 (@shyouhei) March 23, 2022
つっつきボイス:「正規表現のReDoS脆弱性を自動検出して修正って、にわかに信じがたい感じ」「従来の理論ではReDoS脆弱性を扱うのが難しいと書かれている↓けど、自分もそう思います」
正規表現は形式言語理論に端を発していますが、パターンマッチの発展・応用に伴って利用可能な演算子が拡張され、実際のソフトウェアで利用される実世界の正規表現（※3）は従来の理論では扱うのが難しいことが知られています。これまで、実世界の正規表現のReDoS脆弱性を自動的に修正する技術は存在しませんでした。
本成果では、実世界の正規表現を対象にReDoS脆弱性および脆弱性のないことを保証する条件を厳密に定義してReDoS脆弱性の修正問題を形式化し、その修正問題を解くアルゴリズムを考案し、理論的な保証付きのReDoS脆弱性自動修正技術を世界に先駆けて実現しました。
同記事より
「ある程度までならRoDoSの存在チェックをパターン化したりすればやれそうな気もするけど、正規表現の方言ごとに記法や実装の違いもあるし、バックトラックやキャプチャのような拡張機能も考えると、どうやって理論化するのか見当もつかない感じ」「実世界の正規表現を対象にしていると書かれているということは、そういうのも扱えるということなのかも」「ReDoS脆弱性の修正問題の論理モデルとして正確に定義したんですって」「脆弱性のないことを保証する条件を厳密に定義するところまでやってる」「本当だったら凄い」
「そういえば最近Ruby 3.2.0 Preview1に入ったタイムアウト機能（ウォッチ20220412）もReDoS対策の一環ですね」「タイムアウト機能だけだとReDoS対策にはまだ足りないんですが、ないよりある方が絶対いいです」「これまでReDoSの理論がなかったので、今まで理論的にアプローチできなかったのもしょうがない」
「記事にあった論文タイトルでググると出てきました↓」「う、数式がいっぱい...」
参考: PDF Repairing DoS Vulnerability of Real-World Regexes
「こちらはお楽しみで、正規表現を学べるゲームを作った方の記事です↓」
後編は以上です
バックナンバー（2022年度第2四半期）
週刊Railsウォッチ: RailsConf 2022が5月17〜19日開催、認可機能解説記事ほか（20220418前編）
- 20220412後編 HashieでRubyのハッシュを強化、最近のRubyコア解説記事ほ
- 20220411前編 Turbo Railsチュートリアル、Active Recordの「Leaky Abstraction」を削減ほか
- 20220406後編 RBS関連記事、Ruby formatterプロジェクト、Google Cloud Runほか
- 20220404前編 Ruby 3.2.0 Preview 1リリース、Rails向けDocker環境ジェネレータ、scientist gemほか
今週の主なニュースソース
ソースの表記されていない項目は独自ルート（TwitterやはてブやRSSやruby-jp SlackやRedditなど）です。
週刊Railsウォッチについて
TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ）