portal shit!

最近、やたらこのブログにスパムコメントが来るようになった。コメントがあったらメールで通知されるようにしてるのだけど、コメント通知メールが一日十件くらい届く。

Google の reCAPTCHA を入れたことでほぼほぼスパムコメントは弾けていたのだけど、最近のスパムは reCAPTCHA をすり抜けるようになってしまったっぽい。加えて Akismet のスパム判定ロジックもポンコツになってしまったようで、ほぼほぼすべてのコメントをスパムと判定しなくなってしまった。

Lokka では Akismet でスパム判定されたコメントは一括削除できるようになっている（この機能は自分で作った）が、スパム判定されなかったコメントはちまちま一つずつ削除しなければならないのが非常に煩わしかった。

なのでコメント一覧にチェックボックスを表示して、チェックを入れたコメントを一括で削除できるようにしてみた。めっちゃ便利。

Akismet プラグインも少し改造して、自分で NG ワードを設定できるようにした。最近のスパムは露骨に Viagra とか Cialis みたいなキーワードが入ってて、どうしてこんなわかりやすいやつを Akismet は素通りさせてしまうのかわからないのだけど、自前の NG ワードフィルターで二重にチェックするようにした。

最後にアクセスログからスパムっぽいコメントの数を集計して管理画面のダッシュボードで閲覧できるようにした。引き続き監視していきたい。

ブログで使ってる Amazon S3 のバケットの画像のほとんどをミスって空ファイルにしてしまった…。 S3 に上がっている画像、 Cache-Control ヘッダーが付与されていないのですべての画像ファイルに Cache-Control ヘッダーを付与しようとしての事故だった。ファイル一覧を取得して AWS SDK Ruby で Cache-Control だけ付与するつもりだったのにファイルそのものを空で上書きしてしまって無となった。

大した操作じゃないと思って事前にバックアップを取っていなかった＆ S3 に上げておけば安心だと思って日常のバックアップも行っていなかった。スーパーアホ。写真ならアップロードし直すことは可能だけど、キャプチャとか、アニメーション Gif とか、ブログの内容に合わせて OmniGraffle で描いた画像は基本的には元のファイルが残ってなくて元に戻すことができなかった…。

CDN に残っていたものとローカルでキャッシュされていたものを探したが、 500 ファイル以上が失われてしまった。つらい…。

画像の吹っ飛び、過去にも何回か起こっている。レンタルサーバーの障害で消えたパターンもあったけど、自分のミスで消してしまうパターンが多い。自分が一番信用ならないので画像はプロに管理してもらうのが一番だなと身にしみて思った…。とりあえず S3 バケットのバージョンコントロールを有効にしたいと思います…

追記

AWS SDK Ruby での正しい Cache-Control ヘッダー付与の仕方は以下だった。

object.copy_from(object, cache_control: 'max-age=2592000,s-maxage=31536000', metadata_directive: "REPLACE")

#copy_from の引数に medata_directive: "REPLACE" を渡す必要がある。

🙅🏻‍♀️🙅🏻‍♀️🙅🏻‍♀️以下は NG なので注意されたし ☠️☠️☠️

object.put(cache_control: 'max-age=2592000,s-maxage=31536000')

これやるとファイルの body が空になります 🈳🈳🈳

CloudFront 転送量削減の試みで色々やっていて、そういやウェブサイトのキャッシュについての説明記事っぽいの読んだことないし、開発現場だと「じゃあキャッシュすればいいじゃん」みたいな発言が行き交うけど、ひとくちにキャッシュと言っても色々あって、ウェブ開発始めたばかりの人にはよく分からないんじゃないかと思ったので書いておきます。

CloudFront 転送量削減を試みる

関連記事のサムネイル表示導入でCloudFront転送量が急増し請求が約15倍になった。原因はimageproxy経由でのCloudFrontアクセスとキャッシュ設定の非効率。対策としてNgin...

portalshit.net

キャッシュの目的

キャッシュの目的は大きく二つあって、コンテンツ表示の高速化とコストの削減がある。コンテンツの表示高速化は、時間のかかる処理の結果を捨てずに再利用して二回目以降の表示を高速化すること、コストの削減は、処理結果の再利用によってコンピューターの利用時間を減らしたり、データの通信量を減らすことをそれぞれ目的としている。表示高速化とコスト削減はどちらか一方だけを達成するものではなく、多くの場合で両方が同時に実現される。

キャッシュに向いているコンテンツ

キャッシュには向いているコンテンツと向いていないコンテンツがある。

ウェブサイトで配信するものに関して何でもキャッシュできるわけではなく、多くの人が共通して閲覧するものか、更新頻度が低いものでないとキャッシュしてはいけない。更新頻度が低くて多くの人が共通して閲覧するもの（画像、 CSS 、 JavaScript など）はキャッシュしやすい。だがショッピングサイトの購入履歴などは人それぞれなので一律にキャッシュしてはいけない。

キャッシュの種類

キャッシュにはブラウザーキャッシュとサーバーサイドのキャッシュがある。

ブラウザーキャッシュ

ブラウザーキャッシュは、同じ人が繰り返し訪問するサイトで繰り返し利用されるサイト内画像や JavaScript 、 CSS （静的コンテンツ）に対して提供するのに向いている。二回目以降のアクセス時に前回端末にダウンロードした内容を使い回し、転送量を削減してユーザーの閲覧体験を高速化する。

同じ人が繰り返し訪問しないタイプのサイト（ SNS でバズって多くの人が訪れるが、一ページ見ただけで離脱するようなサイト）ではブラウザーキャッシュをフルに効かせても転送量の削減効果はない。逆に一度訪れた人が何度も訪れるような再訪率の高いウェブサイトでは、静的コンテンツに対して Cache-Control ヘッダーを付与することでブラウザーキャッシュを効かせ、転送量の削減とコンテンツの表示速度を高速化させることができる。

ブラウザーキャッシュを聞かせるには、適切な HTTP ヘッダー（ Cache-Control ヘッダーなど）を付けてレスポンスを返せばよい。

サーバーサイドキャッシュ

サーバーサイドでキャッシュできるのは多くの人が共通して閲覧する、更新頻度の低いデータだけということに注意が必要。ログインが必要なサイトで、アクセスする人によってコンテンツを出しわけないといけないようなシステムではサーバーサイドのキャッシュはあまり利用できない。

サーバーサイドのキャッシュには転送量の削減効果はない（少なくとも自サイト訪問者との通信では）が、ランキング集計処理や外部 API の呼び出しなど CPU への負荷や時間がかかる処理の結果をキャッシュし、コンテンツの表示を高速化したいときに有効。

例えばこのサイトでは Amazon のアフィリエイトを利用しているが、 Amazon の API にリクエスト回数制限やリクエスト間隔制限があるので適度にキャッシュを行い、リクエスト回数制限に引っかからないようにしている。

サーバーサイドのキャッシュのやり方は色々ある。アプリケーションにキャッシュするためのコードを書いてメモリ上に保持したり、テキストファイルに保存したり、データベースに保存したり、 Redis などを使ったり。ウェブサーバーのキャッシュを使う方法もある。このブログでもいくつかのキャッシュ機構を組み合わせている。

表示に関わる部分の一部をキャッシュする場合や、キャッシュの無効化をアプリケーションでコントロールしたい場合はアプリケーションでキャッシュする必要がある。

レスポンス全体をキャッシュしてよい場合にはウェブサーバーのキャッシュを使うとよい。その方がアプリケーション層までリクエストが届かず、コンピューターリソースを節約できる。

様々なキャッシュの組み合わせ

更新頻度が低く、多くの人が共通して閲覧するコンテンツはサーバーサイドでもキャッシュできるしブラウザーキャッシュを効かせることができる。画像、 CSS 、 JavaScript などがそれで、これらのファイルはよく CDN （ Content Delivery Network ）から配信される。 AWS だと CloudFront というのがある。この手のサービスはサーバーサイドのキャッシュとブラウザーキャッシュを効かせることに特化したもので、コンテンツの転送量を抑えつつウェブサイトの表示速度を高速化してくれる。

CDN もそうだが、サーバーサイドキャッシュとブラウザーキャッシュを併用すると、コンテンツを更新したいときに問題が出てくる。画像ファイルを新しいものに差し替えたが CSS が更新されず古いキャッシュが参照され、画像が非表示になってしまったり、ということが発生する。そういうことが起こらないように、 HTTP にはいくつか仕組みがある。

ETag - HTTP | MDN

ETag （またはエンティティタグ）は HTTP のレスポンスヘッダーで、リソースの特定バージョンの識別子です。ウェブサーバーは、コンテンツが変更されていない場合はレスポンス全体を再送する必要がないので、キャッシュがより効率的になり通信帯域を節約することができます。加えて、 ETag はリソースが同時に更新されて互いを上書きすること (「空中衝突」) を防ぐのに役立ちます。

developer.mozilla.org

CDN だと ETag も自動付与してくれて、コンテンツの衝突を抑えてくれる。 CDN はよくできているのでよく分からない人はまずは CloudFront を使って勉強してみるとよいだろう。

特に注意が必要なのがアプリケーションキャッシュとウェブサーバーキャッシュの組み合わせだ。異なるレイヤーでキャッシュを効かせてしまうと、キャッシュを無効化したいときに狙い通りに無効化されず、意図しない障害になってしまったりする。コンテンツの特性に応じて、キャッシュは一つのレイヤーで行うようにするとよいだろう。画像や CSS はウェブサーバーでキャッシュし、更新頻度が低いが動的に生成される JSON はアプリケーションレイヤーでキャッシュするなど。

まとめ

• ウェブサイトのコンテンツは何でもキャッシュすれば良いわけでない
• サーバーサイドのキャッシュとブラウザーキャッシュの違いを理解する
• 多段キャッシュに注意（特にアプリケーションキャッシュとウェブサーバーキャッシュの併用）

このブログのフィードを誰が読みに来ているのか調べてみた。一ヶ月間で 100 回以上見に来ている上位の UA は以下。

なんと一位はフィードリーダーの bot ではなく Slackbot だった。 Googlebot よりも多い。もはや Slack が一番のフィードリーダーになっているのかもしれない。こうなると PubSubHubbub とかの仕組みに乗っかって無駄なクローリングが発生しないようにして欲しい。フィードを購読する Slack の Workspace が増えるほどクローリング回数が増えてしまうと負荷がバカにならない。

三番目の Hatena::Russia::Crawler/0.01 ってのは Hatena と名前に入っているが本当にはてなのクローラーなのだろうか。 Russia という文字列が怪しい。

Feedly はもっと多いかと思ったが非常に少なかった。意外と Fastladder が多い。みんなどこかのサーバーで運用しているのだろう。ご苦労様です。

今回、ログを調べていて Feedeen といったサービスが存在していることを初めて知った。他に Feedbin などいくつか有料の RSS リーダーが存在しているようだ。 Google Reader や Livedoor Reader が終了した後、国内外で有料のフィードリーダーが開発されサービス提供されているのだろう。 Feedeen は料金が月 200 円で安い。日本人が作っているというのも安心感がある。自分は Google Reader 終了後はまず The Old Reader を使っていたけどいまは Inoreader を使っている。 Inoreader も開発元はルーマニアのインディー感あふれる会社で、フィードリーダーの世界は独立系の企業やデベロッパーによって活況を呈しているようだ。よいことだと思う。昔のインターネットを思い出す。

ちなみにフィードリーダー系の Crawler は UA にそのフィードの購読者数を表示しているのがおもしろい。こんだけ購読者数がいるんですよ、ということをブログ主に伝えて UA でブロックされないようにしているのだろう。

関連記事に画像を表示するようにして喜んでいたが、先月の AWS の請求額を見てビックリ。普段の 15 倍くらいの金額になっていた。デイリーの利用料金を見ると関連記事に画像を表示するようになった日から高くなっている。

このブログの画像は S3 に置いてあって CloudFront から配信している。これまでたくさん写真を掲載しても特にコストは高くなかった（ Route 53 の費用など含めても $3 くらい、転送量だけだと $1.5 くらいだった）のが、転送量だけで $30 オーバーになっていた。ブログのサーバー代は Adsense 広告と Amazon アフィリエイトでまかなうつもりでやっているので、これでは完全に赤字になってしまう。

なぜ高くなったのかというと関連記事にサムネイル画像を表示することで、 imageproxy から CloudFront へのアクセスが発生するようになったからのようだった。こんな感じ。

imageproxy にもキャッシュの仕組みはあるが、 CloudFront が返す Cache Control ヘッダーの内容を理解せず決め打ちの時間でキャッシュを Expire させるので効率が悪い。

恐らく以下のように画像関連のインフラは AWS に寄せるのが一番効率的だと思う。Amazon の優秀なエンジニアが作ってる CDN が一番前段に出てブラウザーからのリクエストに答えるのがもっとも効率的に画像を配信できると思う。

ただ個人のブログレベルでここまでやるのは割に合わない感じがしたのでとりあえずは以下のような構成にした。

Nginx の proxy cache を使う。

NGINX Documentation

Learn how to deliver, manage, and protect your applications using F5 NGINX products.

www.nginx.com

キャッシュ時間は長めにとって 30d にしておいた。

あわせてキャッシュの HIT 率を計測するようにした。ログに $upstream_cache_status を書き出すようにして、 awk で定期的に集計するようにした。こんな感じ。

cat log/access.log \
  | grep 'cache_hit:' | grep -v 'cache_hit:-' | cut -f16 | sort | uniq -c \
  | awk '{
      if ($2 ~ /HIT/) {
        hit = $1
      };
      if ($2 ~ /EXPIRED/) {
        expire = $1
      };
      if ($2 ~ /MISS/) {
        miss = $1
      };
      sum += $1
    } END {
      hit_rate = hit/sum*100;
      expired_rate = expire/sum*100;
      miss_rate = miss/sum*100;
      print "HIT\t"hit_rate"%\nEXPIRE\t"expired_rate"%\nMISS\t"miss_rate"%"
    }'

こいつを Lokka の Dashboard に表示させる。

加えて、 Google の以下の記事を参考に、画像の遅延読み込みを行うようにした。

Fast load times  |  web.dev

developers.google.com

とりあえずはこれで様子を見たい。いまのところ、ちょびっとずつ転送量は下がってきているような感じがする。もうちょい下げたいところ。

しかし、画像の配信で毎月 $30 もかかるようであれば自前で画像をホストするのは諦めて Flickr に金払って PRO プランを継続した方が安いなと思い始めてしまった…。 Google Photos でも良いが、 Exif がわからなくなるのと埋め込み用の画像を取得する作業（公開用のアルバムを作ってそこに埋め込みたい写真を入れていく必要がある）が面倒くさいので移行に踏み切れない。

以前、 OGP を読み込んでキャッシュする仕組みを作ってたけど、こいつをアップデートして iframe として静的な HTML を読み込むバージョンに作り直した。 URL をクエリパラメーターとして渡すと相手方のサイトにアクセスして OGP を読みに行き、プレビュー用の HTML を生成してキャッシュする。いまは Lokka Plugin として作ってるけどこいつはブログアプリケーションと密結合する必要はないので独立した Web アプリケーションにしてもよいかもしれない。

ブログにリンクを張ると OGP を展開する仕組み、いろんなサイトやサービスで独自実装されててもったいないと思う。 Facebook が OGP の仕様を作ったけど利用するかどうかはリンク元次第だし、 Twitter は Twitter Card という独自の仕組みを作ってる。この辺はいい感じに一本化して欲しさがあるが、大人の事情で多分できないだろう。

Open Graph protocol

The Open Graph protocol enables any web page to become a rich object in a social graph.

ogp.me

カードの利用開始 | Docs | X Developer Platform

developer.twitter.com

ということでグローバルな OGP 君があったら良いだろうと思う。 OGP 君は一枚噛ませるだけで OGP 関連の面倒なこと（リンク先サイトのOGP タグ読み込み、 OGP によるプレビュー生成、生成したパーシャル HTML のキャッシュ）などをやってくれる。様々なサイトでキャッシュが共有されるのでインターネット資源が有効活用される。OGP 君運営者は様々なサイトに script タグなり iframe タグなり¹を埋め込めるので、そこでサイトの利用状況などを副産物としてゲットすることができる。 Google あたりだったらこの辺の情報を金にできそう。

ちなみに同じようなことを考えた人はすでにいて Embedly というサービスがあるようだが、これはリンクを張る側からお金を取る仕組みのようでいまいちイケてないと感じる。見栄えの良いリンクにしたいのはリンクする側ではなくどちらかというとされる側なはずなので、リンクされる側からお金をもらうような仕組みの方が良いはず。

なぜ Day One は Markdown を捨てたのか

Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。

Day One がクソになった

Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー...

portalshit.net

自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する¹という戦略は疑問だった。

ひとむかし前の WYSIWYG は最悪で、Word での文書作成や Google Docs にも良い思い出がない。とにかく文章が書きにくい不自由なツールだった。

WYSIWYG 勢が力をつけてきている

一方で、お洒落な UI で話題になった Notion を使ってみると Markdown の要素を残した WYSIWYG だった。 Dropbox Paper も Markdown 風 WYSIWYG 、 Slack も最近段階的に WYSIWYG 化しつつある。

What you see is what you get and more and less | Slack Developer Docs

This autumn, Slack will make what-you-see-is-what-you-get (WYSIWYG) editing available to users.

api.slack.com

どうやら WYSIWYG の波が到来しつつあるようだ。

なぜ WYSIWYG なのか

Markdown は HTML を書いたことがない人には難しい

エンジニアやデザイナーなど、 HTML を理解している人からしたら Markdown は簡単だが、そうでない人には難しい。組織内に非エンジニア・非デザイナー（ HTML を書けない人）が増えてくると、途端に社内ドキュメント管理ツールがカオス（ ・ や全角空白 　 で装飾された文書が氾濫）になる。

プレーンな Markdown では、リストの概念や文書を構造化するということに対する理解がないと読みやすい文書は書けない。プレーンテキストベースの Markdown には読みやすく構造化された文書を書けるようになることを助ける仕組みが欠落している。

普通の人が Web 系のように働きはじめている

Slack は DAU が 1200 万を超えたらしい。もはやエンジニアだけのツールだけではなくなってきているようだ。

https://slackhq.com/intl-ja-jp-work-is-fueled-by-true-engagement

slackhq.com

チャット、 Wiki 、社内ブログ、タスク管理ツールなど、文章を入力させる系の SaaS が徐々に IT 産業以外の職場でも普及しつつあり、そのような環境でも受け入れられやすいようにプレーンテキストの Markdown ではなく、 Markdown 風の WYSIWYG を入れてきているのだと推察する。

普通の人でもぐちゃぐちゃにならないように文書を書くための仕組みとして WYSIWYG が注目され直しているのだろう。

抑制された WYSIWYG

Dropbox Paper や Notion の UI はシンプルでクール

MS Word や Google Docs など昔ながらの WYSIWYG はボタンが多く、出来ることが多すぎて逆に不自由だと感じる場面が多かった。一方で Dropbox Paper や Notion の WYSIWYG には悪い印象がない。Paper や Notion の WYSIWYG はできることが限定されていて、制限されているがゆえの使いやすさがある。 MS Word のような大小の文字が入り乱れ、文字が七色に輝いているような文書は書けない。

ぐちゃぐちゃな文書を書かせない仕組み

Paper や Notion はアウトライナーを WYSIWYG 化したような感じで、文章を並べ替えたり入れ子にしたりできる。

文章を構造化することに慣れていない人でも、まぁまぁ読みやすい構造化された文章を書ける、あるいは構造化された文章の書き方を学べるようになっている。

WYSIWYG 化で失うもの

文書のポータビリティー

WYSIWYG の前提として、下書きする場所と最終的な出力をする場所が同じだということが挙げられる。でないと独自の装飾フォーマットが使えない。

Notion で書いた文書は Notion でしか読めないし、 Dropbox Paper で書いた文書は Dropbox Paper でしか読めない。 Markdown で書いたテーブルならほかのツールに取り込めるが、 Notion で書いたテーブルは Notion でしか使えない。入れ子にしたり装飾したりする便利な機能も Notion で使うからこそ約束されているものだ。その場所でしかその書き方はできない。

だから、ローカルのお気に入りのテキストエディター（ Vim など）で書いたあとにクリップボードにコピーしてブラウザーに貼り付ける、という使い方が出来なくなってしまう。

いまこの文書は Notion を使って書いているが、プレーンテキストでコピーできない²のでブログにこの記事を投稿するときは一旦 Markdown フォーマットで書き出して Vim で開き、コピーしてブラウザーのブログ記事入力欄にペーストする必要がある。

冒頭に挙げた Day One も Markdown で文章をコピーすることができなくなった。文書作成・管理プラットフォームとして考えたときにはこれは正しい戦略で、 Markdown ではない独自のフォーマットで文書を書かせることでユーザーをロックインできる。ひとたび Notion や Dropbox Paper に文章を書きため、その独自フォーマットに慣れてしまえば、データと記法の両方によってロックインされてしまうわけだ。

Notion や Dropbox Paper はよくできていると思う。特に Notion は WorkFlowy のようなアウトライナー的な側面を持ち、いわゆる「ファイルの壁」問題を解決しつつ Markdown のサポート、画像の埋め込みや表の挿入などにも対応している。良いなと思う反面、一人のインターネットユーザーとしては、オープンかつ自由なフォーマットで書くことができる Markdown がやっぱり好きだとも思う。