週刊Railsウォッチ（20190717-2/2後編）NFSのよさとは、Linuxカーネル5.2リリース、Puppeteerでメモリリーク検出ほか

こんにちは、hachi8833です。昨日の願いが通じたのかいきなり晴れました。

各記事冒頭にはでパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ

「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です

毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください

クラウド/コンテナ/インフラ/Linux/Serverless

Prometheusでの測定時間のバイアスを避けるには（Hacklinesより）

元記事: Avoid time-of-measurement bias with Prometheus | Lawrence Jones

つっつきボイス:「Ruby系の記事ですが内容的にインフラかなと思って」「インシデントの発生と測定値の間にズレがあった↓という事例らしき」「こういうのはだいたい測定の粒度が問題になるヤツ」

同記事より

「この記事でやったことをprometheus-client-tracerというgemに切り出して公開してますね↓」

リポジトリ: lawrencejones/prometheus-client-tracer-ruby: Tracer for accurately tracking long-running operations with Prometheus metrics

「記事の方は特に珍しい話ではなさそうですが、監視とかジョブのスケジューリングの頻度って雑にデフォルト値のままでやったりするとこういうことになりがちですし」「やはり〜」「しきい値やサンプリングインターバルとかをちゃんと設定しないと、誤検知とか、メトリックスが実はちゃんと取れてなかったなんてことになりかねませんし」「というようなことが書いてあるんでしょうきっと」

サイト: Prometheus - Monitoring system & time series database

prometheus.ioより

Linuxカーネル5.2リリース

元記事: 「Linuxカーネル5.2」リリース | OSDN Magazine

つっつきボイス:「Linuxカーネルは最近全然追ってない〜」「Sound Open Firmware（SOF）とか知らない世界」

リポジトリ: thesofproject/sof: Sound Open Firmware

「おぉ、BFQ I/Oスケジューラーの性能を大幅に改善とは！」「BFQはBudget Fair Queueing…」

参考: Ubuntu 19.04 その6 - UbuntuとLinux I/Oスケジューラー（後編） - kledgeb
参考: https://www.kernel.org/doc/Documentation/block/bfq-iosched.txt

「ちょ『ext4ファイルシステムでは大文字と小文字を区別しないファイル名参照がオプションとして加わった』って」「こ、怖〜」「そういえばmacOSのファイルシステムって基本的にケースインセンシティブだったんじゃないかな？」「一応フォーマット時に選択可能だった覚えが」「最近のMac知らんけど、システム的にはケースインセンシティブが前提だったと思います」

参考: Mac OS 拡張（大文字／小文字を区別）に気を付けよう ( Macintosh ) - Re: From: Suzuchi - Yahoo!ブログ

後で自分のMacbook Proで見たら、大文字小文字を区別しない設定でした。うかつに「はい」にしないようご注意。

「そしてとうとう『レガシーのIDEドライバーは非推奨に』」「かつてIDEが主流だったのに」「悲しい〜」「今やIDEをテストする環境を作るのも維持するのもだるいし」「IDEのチップセットも今や昔」「今の主流は、えっと」「SATAですね」

参考: Advanced Technology Attachment - Wikipedia — IDE（Integrated Drive Electronics）
参考: シリアルATA（SATA） - Wikipedia

Google CloudのElastifile買収とNFS（Publickeyより）

元記事: Google Cloud、ペタバイトクラスのスケーラブルなNFSサーバを実現するElastifileの買収を発表－ Publickey

つっつきボイス:「実はクラウドでNFSを使うメリットってよくわかってなくて」「AWSのAmazon EFSなんかで前からNFSサービス提供してますヨ」「やはりそうでしたか〜」

参考: Amazon EFS（EC2 用フルマネージド型ファイルシステム）| AWS

NFSのよさとは

「NFSは、低レイヤかつ複数箇所をマウントできる機能を提供します: かつUnixファイルシステムでUIDとかを変換しないで使えるファイルシステムですし」「おぉ」「NFSはUnixシステムを前提としていますし、昔から使われていて枯れていますし」

参考: 知っておきたいNFSの基本と活用法 | 物理サーバ愛が止まらないホスティング事業者のブログ | ベアメタルブログ

「sambaとかだと、結局sambaデーモンを立ち上げて、sambaデーモンの設定でsambaプロトコル（SMB）上のユーザーIDとUnixのユーザーIDを管理したりだとか、Windows用ネットワークの設定管理だとかも別途必要なんですよ」「いかにも大変そう」

参考: Samba - Wikipedia
参考: Server Message Block（SMB） - Wikipedia

サイト: Samba - opening windows to a wider world

samba.orgより

「その点NFSなら、UnixのUIDそのまま投げられるからとってもシンプル」「ElastifileのはSMBでもアクセスできるとありますね」

「クラウドのNFSを使いたい場合ってどんなときなんでしょう？」「そりゃもういつだって普通に使いたいです」「おおそんなに！」「だってEFS超便利だし」「複数台のマシンでマウントできて、Availability Zone（AZ）をまたいでマウントできる、もうこれだけでEFSめちゃめちゃ便利」

参考: リージョンとアベイラビリティーゾーン - Amazon Elastic Compute Cloud

「対照的にAWS S3のようなオブジェクトストレージだと直接fopen()とかできないですし」「そういう違いだったんですね！」「オブジェクトストレージは、その特性に合った使い方をする分にはもちろんとてもいいものですけど、普通のファイルシステムのように使おうとすると効率がどっかん下がっちゃいますので」「あぁ〜！」

参考: Amazon S3（拡張性と耐久性を兼ね揃えたクラウドストレージ）｜AWS
参考: fopen()

「S3でもFUSE系のドライバを入れればマウントしたりはできるんですが、FUSEのドライバを経由してやろうとすると、思いつくだけでもたとえばfseek()とかめちゃめちゃ遅くなりますし」「」「オブジェクトストレージでfseek()とか無茶ですし」「appendとかもね」「排他処理なんかも」「appendは原理的に複数のプロセスを同時に開けちゃうので、そういうのの排他制御とかを考えると…」「それがNFSなら直接ブロックリードできるので効率がもう圧倒的に違います」「Unixファイルシステム互換でやれるのはマジ強い」

参考: Filesystem in Userspace（FUSE） - Wikipedia
参考: fseek

「それでGoogleもNFSやるぜってことになったんでしょうね」「AWSにあるんだから、Googleにないの？って言われないように」「NFSのメリットの学び大きかったー: ありがとうございます！」

その他インフラ

つっつきボイス:「FIDOって前も扱った気が（ウォッチ20180413）」「そういう名前が付いたのね」「うご、PCがフリーズ…」

DB

PostgreSQLのクエリプランナーをデバッグした話

元記事: Debugging the Postgres query planner — GoCardless Blog

つっつきボイス:「検索で見つけた記事ですけど、クエリプランナーのバグを追ってとうとうPostgreSQLのソースコードまで見に行ってました↓」「クエリプランナーのバグじゃしょうがないけど、普通そこまで見に行くのはあんまりしないし」「記事長いんでちゃんと見ないとわかりませんが、本当にバグだったのか、特定のエッジケースにハマったのかで違いそう」

リポジトリ: postgres/pathnode.c at REL_11_2 · postgres/postgres

/* 同記事より */
/* src/backend/optimizer/util/pathnode.c:3414
 * 'count_est' is the estimated value of the LIMIT expression
 */
LimitPath *
create_limit_path(
  PlannerInfo *root, RelOptInfo *rel, Path *subpath,
  Node *limitOffset, Node *limitCount,
  int64 offset_est, int64 count_est)
{
  ...

  if (count_est != 0)
  {
    if (subpath->rows > 0)
      // subpath->rows is an estimated row count of our
      // source query, while count_est will be the LIMIT
      // value when known. This means we're discounting our
      // cost by the fraction of the source query we expect
      // to use.
      pathnode->path.total_cost = pathnode->path.startup_cost +
        (subpath->total_cost - subpath->startup_cost)
        * count_est / subpath->rows;
    ...
  }
}

後で記事をざざっと見てみると、productionでPostgreSQLのパフォーマンスが明らかに落ちてきたのに、クエリプランにそれがうまく表れてこないという問題だったようです。ソースは修正せずに、サンプルのサイズなどを工夫して解決したようです。

この人の他の記事も面白そうです。

元記事: Building a PostgreSQL load tester | Lawrence Jones

JavaScript

Puppeteerでメモリリークを自動検出（JavaScript Weeklyより）

元記事: Automatically detect memory leaks with Puppeteer - Article by Christoph Guttandin - Media Codings
サイト: Puppeteer v1.18.1

pptr.devより

// 同記事より
describe('memory leak tests', () => {

    let browser;
    let context;
    let page;

    before(async () => {
        browser = await puppeteer.launch();
    });

    beforeEach(async () => {
        context = await browser
            .createIncognitoBrowserContext();
        page = await context.newPage();
    });

    it('should ...', () => {
        // The actual test will be executed here.
    });

    afterEach(() => context.close());

    after(() => browser.close());

});

つっつきボイス:「タイトルそのまんまですが」「まあPuppeteerならやれますけど」「何のメモリリークなんでしょう？」「ブラウザJSのGC周りとか？」「JSHeapUsedSizeとあるし↓」「V8エンジンが対象か」

const { JSHeapUsedSize } = await page.metrics();

「Puppeteerで調べられるメモリリークなら相当再現性は高いはず」「たしかにユーザー操作と同じですし」「一応issue投げてますね↓」「AudioContextみたいにバッファを使いそうなものはメモリリークしやすそう」

issue: Memory leak with AudioContext · Issue #410 · chrisguttandin/standardized-audio-context

その他JS

リポジトリ: checkly/puppeteer-recorder: Puppeteer recorder is a Chrome extension that records your browser interactions and generates a Puppeteer script.
- ドキュメント: Overview | Checkly

同記事より

つっつきボイス:「上のPuppeteer記事にちょっと関連して、ブラウザ操作を記録して再生するレコーダーを見つけました」「Puppeteerのコードを吐いてくれるんでしょうね」「前にウォッチで紹介したRails向けのheavens_doorをちょっと思い出しました（ウォッチ20190218）」「あちらはRailsというかCapybara用でしたね」

リポジトリ: amatsuda/heavens_door: Capybara test scenario recorder for Rails

「こういうレコーダーってやっぱりあるとありがたそう」「自動生成したコードは人間が読むにはつらくなりがちですが、それでもないよりはあったほうがいいですね」

CSS/HTML/フロントエンド/テスト

User Inyerface: ダメUIをゲームで学ぶ

サイト: User Inyerface - A worst-practice UI experiment

同サイトより

つっつきボイス:「某所で知ったんですが、アカン感じのユーザーインターフェイスてんこ盛りのフォームに制限時間内に入力しきれるかどうかというゲーム形式になってます」「はてブでも見たような」「ちょっとだけやってみましたが勝てる気がしなくて」

「しょっぱなで丸い緑のNOボタンがいきなり押せない」「マウスオーバーするとボタンぴくつくのに〜」「どこをクリックせいと…？」「Please click HEREあたりにもクリックできそうなところ見当たらないし」「こういうUIで『実はボタンの文字そのものの部分しかクリックできない』とかたまにありますよ〜」「さっき次の画面に行ったけどどれを押したらできたのか思い出せない」

「え？、HEREという文字をクリックしたら次に進んだ！」「それや！」「やられた！」

「そこから先も、”Choose Password”という灰色の文字を消さないといけないとか」「メアドのトップドメイン名をわざわざプルダウンにしてるとか」「チェックボックスが『I do not accept the Term & Conditions』とか」「デフォルトがCancelとか」「あ〜うぜ〜」

「これはきっと、SI業界長くやってる強者なら解ける」「ああっ」「きっとたちどころに」

その他フロントエンド

元記事: ブログアイコン（favicon）をGoogleのガイドラインに準拠するよう変更しました - はてなブログ開発ブログ

つっつきボイス:「faviconのガイドラインがあるって知らなかったので」「まあ『Googleはこう解釈するよ』ってことでしょうけど」「faviconは複数サイズ用意しとけとか」「基本は.icoファイルで作るものだったと思いますし」「gifとかも本来はよくなかったはずだし」

参考: A New Design for Google Search on Mobile

言語・ツール

Sourcegraphとは

元記事: Gitリポジトリ上のソースコードをWebブラウザから検索・分析できるコード検索ツール「Sourcegraph」 | さくらのナレッジ

つっつきボイス:「Sourcegraphは前から割と有名ですよね」「あ、そうでしたっけ」「重いんであんまり使わなかったけど」「お、商用版があるとは！」「つか前は商用サービスだったのがオープンソースになってたのね」

サイト: Sourcegraph - Code search and intelligence

sourcegraph.comより

「Language Serverを使ってるのか」「なるほど、オープンソースだと自分でLanguage Serverを立てないといけなくて、商用だとホスティングされているものを使えると」「Language Serverが使えるというのはいいかもっ」「対応している言語ならどれでも使えるだろうし」「VSCodeなんかでLanguage Server使う感じでしょうか」「後発のIDEならすべて自前で作るよりはこういうのに乗る方がいいでしょうし」

サイト: Langserver.org

その他

AIは閾値を超えるか

つっつきボイス:「AI方面はだいたい騒がしいですけど」「ライブラリを触れますみたいなのはもう当たり前で、どんなデータをどうやって取ってきて、どんなアルゴリズムをどう組み合わせるかをひたすらやっていくところがノウハウですし」「それにしてもくずし字の解読は凄いかも」「CAPTCHAとかOCRとかがこういうのに近そうだから遅かれ早かれ攻略されたんでしょうけど」

参考: CAPTCHA - Wikipedia