コンクリートから何処へ？
R219の工事はまだ続いている。
道路の復旧 八代復興事務所｜国土交通省 九州地方整備局 http://www.qsr.mlit.go.jp/yatsushiro_r/douro/dourofukkyu/index.html
そういえばどうなったのかなーと思ったら、大分前に仮橋が完成していた。
国道445号（金内橋）仮設道路（仮橋）の完成について - 熊本県ホームページ https://www.pref.kumamoto.jp/soshiki/102/189543.html
北朝鮮すらお見舞い電報送ってくる事態の中、自国の首相にヘイトメッセージを送りつけて表現の自由を満喫する皆さん、お元気ですか。
TLS本の改訂部分中心の長い書評と、より細かい話への参照。正直このレベルのツッコミは理解できないところも多いけど、本の雰囲気は分かるかも？
書評 プロフェッショナルTLS&PKI 改題第2版 (PR) - ぼちぼち日記 https://jovi0608.hatenablog.com/entry/2024/01/05/0945
(ただまあ、負荷感に関してはもうおじさんの肌感覚と最新環境は乖離しすぎてて、コメントできねーなーみたいなところis正直ある。
プロフィール画面とかは通常の配信とは関係なく都度取得してる？ はずなので、ポーリングしてれば配信が遅延してても見えるだろうけど、配信の仕組みの逆行になるので単純に負荷かける形になるんだろうなとは。
やぁ、misskey.ioのキュー凄いねえ。
いま、だいたいfedibird.comに11時間半（ほぼ半日）ぐらい遅れて届いてる……というかもはや止まっているような速度だね。
ActivityPubの投稿の連合は、投稿者のサーバ側が、各ユーザーのフォロワーのいるサーバに新規の投稿があったことを伝える（相手サーバにPOSTする）仕組みです。
misskey.ioで1,100万個の外部配送が待機中になっている状況で、少しずつしか消化されないので、どんどん遅れが増えていってます。
ちなみにmisskey.ioで投稿のURLを拾ってきてそれを検索すると個別にfetchできるので、配送を待たずに受け取ることはできます。
誰かがブーストした場合も、まだ受け取っていなければ個別にfetchするので、それも届いたりします。
村上さんや運営のアナウンスがあったら、他鯖でブースト（リノート）することで伝えて回るっていうことはできるかな。あとはあんまりやっても仕方ないか……。
ま、個人的に自分の投稿を流したいサーバにもって来ちゃうっていう使い方はできますけどw
連休明けに読むとキくやつだ(
世話やきキツネの仙狐さん 第九十三尾｜コミックNewtype https://comic.webnewtype.com/contents/sewayaki/1930/
fedibird.comの場合、ingressキューが詰まる現象というのは見たことがなくて、基本的にdefaultキューが処理仕切れなくて溢れるよ。
でも元凶はingressキューからdefaultキューに投げられる大量の配送処理なので、ingressキューをわざと絞り込んで、処理を遅延させて負荷を軽くすることはできる。
defaultの処理が追いつかなくて死にそうだったら、一時的にingressキューを止めちゃうっていう手もあるよ。
特定のサーバからの処理がキツければ、たとえばlow_priority_ingressキューを別に作って、そこで処理件数を制限しながらゆっくり処理する。で、pumaの方でmisskey.ioから来たActivityだけlow_priority_ingressに積むって感じ。
ま、fedibird.comでは今回、流れてくるものなら全力で処理する方針だけどね。
このingressキューは、mastodon.socialが大量流入で人口爆発したときに生み出されたやつで、これで調整するようにしたらしいよ。重くて動かない状態から、サーバ内動作はなんとかなる、というところまで回復させたりね。
いまのMastodonはリモートから配送されてきた投稿について、まずmastodon-web（puma）が受け取って、送信元の身元確認などを行ったあと、ingressキューに積む。
ingressキューで順番に処理していくんだけど、重複を無視したりして、新規投稿ならデータベースに投稿データとして保存する。
で、この保存した投稿データを内部で配送する。配送はdefaultキューに積んで、順番に処理する。フォローしている人のホームとかリスト、公開タイムライン（連合やローカル、ハッシュタグ）などに差し込む処理ね。
タイムラインに差し込まれるときに、redisのpub/sub channelsを使って、ストリーミングで繋がっているブラウザ・クライアントに結果を流し込む処理を行う。ストリーミングはnode.jsで動いている本体とは別のプロセスが処理するので、redisを仲介にして分離されている。
新規投稿じゃない場合、たとえば絵文字リアクションとかお気に入りなら、ingressキューのワーカーの段階でredisに通知をpubしてストリーミング経由でブラウザ・クライアントに流す。
そういう感じ。
で、もの凄く大量の処理が必要なときに、どこがボトルネックになるかってことを見極めるのが重要なのね。
今年はまだあと362日もあるけど、移動平均とれば大丈夫……だよね？(
21世紀になってもご丁寧に米国の元メーカー関係者にインタビューしにいって責任を問い詰める特番を全国放送するくらいなので、そういうののほうが国民のウケはいいのかもしれないし、安全対策は事業者が真剣に受け継いで先日も成果を発揮してたので、安心して会見で攻め潰しても大丈夫なのかもだけど。
管制の自動化とか何とかたいへん結構なことだと思うけど、123便の頃からずっとずっとずっとずっと指摘され続けて全く変わらない、事故対策より「犯人探しと公開処刑」を優先するマスコミとか警察とかの対応改善にまずは着手されたらいいんじゃないですかね。
航空無線の英単語はそれぞれ意図を定義して選択されてるらしいので、日本語訳みたいなのは厳密にはそのへんの意味を喪失してる点で全く参考にならない点を考慮して参考にする必要がある点に注意が必要だと思う(意訳：無意味
発生時点で何も言わないのが玄人、詳しくて責任の話をしないのが専門家、どれだけ詳しくても責任の話をするのは有害な素人、と思えばいいかなーと。
マスコミは有害な素人、警察は有害な玄人って感じかしらね。
正月なのでTLS&PKI本を読んでた。個人的に微妙に勘違い(?)してたけどソフトウェアじゃなくてプロトコルの解説なので、暗号技術は最低限、ネットワーク(TCP/UDP)・アプリケーション(HTTP/DNS)は言及はするけど解説なしで、プロトコルの歴史は脆弱性の歴史だってばかりに30年分総まとめした感じの本だった。コードも数式も設定記述もないので手を動かす参考にする本ではないけど、今時フルTLS化してるし、証明書とか触るひとなら基礎知識として読んでおいたほうがいいかも？ な感じ。
脱出というより機体轢かれて吹き飛ばされたんでは……(クロトワさん的
NERVは(速報優先気味なのか)時々やるけど、WNとNHKの判定系が怪しいの出すのは珍しい気がするなあ、と思ってたら3に修正された。
https://twitter.com/wni_jp/status/1741823888416477497
インプレBOTも当然ながら意味も分からずトレンドワード取り込んでるけど、そういうの除外する開発するより、数で押し切ってイーロンからお年玉もらうほうが儲かるのかな。
いつものことだけど、陰謀論キーワードのトレンド入りの副作用で、文脈無視したトレンド参照キーワードスパムが炙りだされてるのを観察している。
fediverse系はスパムも専門家気取りも本物の専門家もまだいないので、良くも悪くもマイペースすぎるというかいつも通りに見える。
twitterさんは負荷で落ちないのはやはりさすがなのよねえ、惜しいサービスを失くした(過去形かよ(まあ内容に関しては構築したタイムライン次第なので、極端なまでに人によるだろうけど
政府会見の記者質問も馬鹿しかいないので、ほんとTV役に立たないな……まだ正月バラエティやってたほうがマシだ。
気象庁の会見、記者質問するだけの知識ないなら黙ってるくらいの知恵を期待させてほしい。専門家出てるのに、まだLIVEと警告流してるほうがマシとか勘弁して。
再稼働に期待してるって言葉は、あれから10年動いてないってのと同じ意味なんですよ。
まだtwitter使ってる人で暇な人は、現地の人にリプライ飛ばしてるクズを通報ブロックしておくと、少しはサービス延命になるかもしれないし、焼け石に水かもしれない(どっちだ？
中継映像、白波は普通の風波だろうけど、港内の流れは津波っぽいなあ。
あけおめ負荷試験、無事終了ということで簡単にご報告を。
Mastodonは、処理を小さな単位に分割し、それらを大量に処理する構造になっています。
具体的には、投稿の処理、お気に入りの処理、誰かのタイムラインに投稿が届いた処理、リモートサーバに届ける処理、などの小さな単位に分かれていて、これをdefault、pushなどの分野ごとにわけ、順番に処理しています。
処理の一つ一つを『ジョブ』と呼び、順番に処理する待機列を『キュー』と呼んでいます。
『Sidekiq』という仕組みがこれを支えています。
新年は、いつもよりたくさんのユーザーがアクセスし、新年の挨拶などを大量に投稿しますので、膨大な『ジョブ』が発生し、『Sidekiq』の『キュー』で長い順番待ちが発生します。
そうすると、タイムラインに5分前や10分前の投稿は届くけれども、いま自分が行った投稿は流れてこないなど、処理の遅延が発生します。
時間をかけて順番に処理しているだけなので、待ってさえいれば確実に終わるということでもあります。
こうした状況は意図して発生させることが難しく、地震のように予測できないものに比べ、新年は発生タイミングがわかっているので、貴重な機会になっています。