RDS Aurora MySQLのPerformance InsightsによるPerformance Schema自動管理はt4g.mediumだけ特殊な動きをするので気をつけろ

言いたいことはタイトルの通り．

まずRDSにはPerformance Ingishtsというものがある．これは今までのRDSのMonitoringに加えて，もっと詳細なクエリ等の情報までが見える分析ツールである．

www.youtube.com

これは AWS RDSによって提供されている機能である．

対して，Performance Schemaというのは MySQLで提供されている機能であり，MySQLサーバのモニタリングのための機能である． 通常のMySQLサーバであれば，管理者が

[mysqld]
performance_schema=ON

こういう設定を書くことで有効化できる． 名前が似ていてややこしいので，performance_schema と書くことにする．

さて，こいつをAWS RDSでどうやって有効化するのかという話である．

デフォルトではperformance_schemaはPerformance Insightsによって自動管理される

RDS MySQLの設定は，(Cluster|Instance)ParameterGroupによって設定されている． ちなみに，ClusterParameterGroupとInstanceParameterGroupどちらが優先されるかについては以下の記事が詳しい．

dev.classmethod.jp

で，ややこしいのだがParameterGroupをいじってない状態だと，performance_schemaは0 つまり無効化されているように見える．

しかし，こちらのドキュメントでも触れられている通り，performance_schemaの項目がデフォルト値である場合は，Performance Insightsによる自動管理状態になっている．

docs.aws.amazon.com

この場合は，単にPerformance Insightsを有効化してインスタンスを再起動すれば，performance_schemaは有効化される．

dev.classmethod.jp

なお，ここを変更した時点でPerformance Insightsの自動管理から外れるので，1にすると自動管理されなくなるのである．ややこしいわ．

ただしt4g.mediumだけは自動管理対象外になる

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.EnableMySQL.html#USER_PerfInsights.EnableMySQL.options

Automatic management of the Performance Schema isn't supported for the t4g.medium instance class.

t4gファミリーとかではなく，なぜかt4g.mediumだけ．一部のインスタンスでこのインスタンスタイプを使っているやつだけハマった．

この場合どういう挙動になるのかを書いていく．

まず，このt4g.mediumでperformance_schemaを有効化するためには，ParameterGroupによる手動管理設定が要る．

performance_schema: 1
performance-schema-consumer-events-waits-current: ON
performance-schema-instrument: wait/%=ON
performance_schema_consumer_global_instrumentation: 1
performance_schema_consumer_thread_instrumentation: 1

というようにParameterGroupを設定しておく．

この状態で再起動する……前に確認すべきなのはPerformance Insightsである．

t4g.mediumはPerformance Insightsによるperformance_schema自動管理外になるので，一見無関係に思えるがそうでもなかった．

1. t4g.mediumをPerformance Insights有効にして再起動すると，どう頑張ってもperformance_schemaは無効化される
2. t4g.mediumでperformance_schemaを有効化するためには，一度Performance Insightsを無効化して再起動する必要がある
3. Performance Insightsはインスタンスの再起動無しで有効化できるので，これをやったあとに再度Performance Insightsを有効化する必要がある

面倒すぎるだろう． まじでなぜt4g.mediumだけこうなった？smallとかlargeではこうならないんでしょ？

これは勘だけれど，Performance Insightsが有効な時点でperformance_schema自動管理を動かそうとしているんじゃないだろうか．t4g.mediumなので，その判定で除外されて，以降performance_schemaの設定が確認されないまま起動しているように見える．Performance Insightsが無効化されていれば，そこの確認をスキップしてParameterGroupの設定どおりにperformance_schemaを設定しているように見える．

いや，まじでなんでt4g.mediumだけこうなったのか謎すぎるわ． というかperformance_schemaなしでもPerformance Insightsは使えるわけだし，なんでここを自動管理にしたのか意味不明．普通にParameterGroupの設定どおりに起動してくれたほうが全然明示的じゃん．こんな暗黙的な自動管理をやらないでほしい．

ゼンハイザーHD600を買った

持っていたヘッドホンのヘッドバンド部分，合皮でできている部分が経年劣化でボロボロになってきた．イヤーパッドは結構替えパーツが売っていることが多いのだが，ヘッドバンド部分はどうにもならなくて，結局こうなると捨てるしか無い．

というわけで新しいヘッドホンを買おうと思ってゼンハイザーを探した．今までは密閉型だったのだが，どうにも開放型が欲しくなったので，開放型といえば老舗のゼンハイザーだ．

いくつか視聴してみて，ハイエンド機は今の俺には不要だろう，という結論に至った．残った候補は

• HD599
• HD560S
• HD600

このうち，HD599はヘッドバンドが同じく合皮でできているので，その寿命くらいしか持たないだろうと予想できる．この理由のため，最初からHD599SEも除外した．それに対してHD560Sはベロアのヘッドバンドなので，この点は少しマシなんじゃないかと思っている．また，HD600以上のシリーズになればベロア素材のヘッドバンドの替えパーツが売られているので，ヘタったとしても交換することができる．

となると候補は

• HD560S
• HD600

になった．HD650やHD660S2までは手が出ない．

というわけでこの2つを念入りに聴き比べた． ちなみに，デスクトップPCで使う．ゲームはほとんどやらない．音楽を聞くかアニメを見るかのどちらか．

聞く音楽はほぼクラシック．ピアノソロ，ピアノ協奏曲多め．

聴き比べ

第一印象はHD560Sの方が良かった．まず高音の響きが良い．今まで音として鳴っていたが目立っていなかった高音が非常によく響いていて聞こえやすい．全体的にスッキリ全部の音が聞こえる感じがしていて，これは流石に新しいだけはある．また，開放型だけれど低音もしっかり聞こえていて良い． インピーダンス120Ωだけど，スマホにつないでもそこまで音量調節せずにしっかり聞こえている．

これに対し流石にHD600はインピーダンス300Ωだけあって，スマホの音量は最大にしないと聞こえない．それでも音量不足は否めない．これはアンプを通していないから当然のことではあるが．また，音のスッキリ感はHD560Sに一歩劣る．全体的に柔らかくなっている代わりに，スッキリした感じは一段劣る．また，低音はHD560Sよりちょっと軽い感じがする．

ちなみに最終的にMac Book Proと，それにつないだFiio E10Kを持って視聴に行った．

で，一番の問題点は響き方の違いだった．オーケストラ曲だとそこまで違和感はなかったのだが，ピアノソロを聞いてみると一目瞭然の差がある． まず，HD560Sは先程書いたように高音の響きが非常に良い．まるでホールに響いて消えていく残響音が強調されているかのような聞こえ方をする．しかし，これが高音だけなのだ．中音域になるといきなりその響きがなくなる．低音域も同じく．また，音がスッキリ聞こえるのも相まって，中音域のアクセント，sfが非常に強く聞こえる．ベートヴェンのピアノソナタ17番，テンペストの第3楽章みたいに使う音域が真ん中あたりに寄っていればそこまでこれは気にならない．しかし，ショパンのスケルツォとか聞くと違和感の塊になる．高音域はホールに響いている音を聞いているようで，中音域になるといきなり目の前で弾いているような音になる．聞いてる音じゃない，弾いてる音になる．本来，こういうときに聞く音源というのは録音された音源であるし，それを聞いているのだから弾いている音になるのはあまりいいことじゃない．

これに対して，HD600は全体的に整っている．高音域はHD560Sより伸びないけど，全体的な響きが統一されていて，音の距離感が変わらない．これだけでかなり違和感がなくなる．あと，アクセント，sfも柔らかくなっているので，こちらのほうが聞きやすい．HD560Sみたいな，目の前で弾いているような音はせずに，全体的にちゃんとホールで聞くような音になっている．

ちなみに店にあるアンプを借りたところ，更に良くなることはわかった．HD560S -> HD600に変えたときの低音の軽さも，アンプによりかなりしっかりと重さがのるようになっている．ただ，値段はそれなりに上がっていくので，値段相応かは人による．

というわけでHD600を買った．

ちなみに公式で買うのが一番安かった．

www.sennheiser-hearing.com

公式で44000円．いくつか店舗を回ったけれど，だいたいHD600は54000円以上で売られていることが多かった．HD560Sは公式と変わらず，

www.sennheiser-hearing.com

むしろ27000円を切るくらいの値段で売っていることもあった．何が違うのかわからないけど，公式で買った．特に問題はない．

視聴に行った場所

だいたいここで全部聞けるし，視聴ブースもあるのでいろいろ試しやすかった．

https://www.e-earphone.jp/

ヨドバシカメラにも行ったのだが，ヨドバシ，お前はダメだ． ノイズキャンセリングヘッドホンを買うのであればよいだろう．しかしオープンエアーのヘッドホンを買う場所じゃない． ところ構わず流れる「まあるい緑の山手線♪」，それが終わったと思えば「ただいま4階にて……」とひたすら売出しセールの呼び込み，そして背後には自動演奏の電子ピアノ．ふざけているとしか思えない． こんな環境なのでeイヤホンと違って誰もヘッドホンの視聴なんかしてないじゃないか．

WhalebirdをReactで書き直した

長らくVue.jsだったWhalebirdをReact.jsで書き直した．というよりNext.jsになった．

github.com

当初，Svelteで書き直してみたんだけど，これがあまり思い通りにはならないことがわかって，Next.jsでの書き直しになった． 6.0.0がNext.jsの初版で，6.1.0まで来たところで，まぁ少しは使えるようになってきたので書き残しておく．

まず，最初に書き直しを考えたのは2023年の4月くらいだ．2023年の改修で，今までNode.js側のストアとしてnedbを使っていたものをbetter-sqlite3に置き換えていた．これは単純にセキュリティ的な理由と，SQLの強力さを求めて載せ替えた．

ただ，この選択はあまり正解だったとは言えずに後悔することになった．better-sqlite3はsqlite3を使うことから考えても，native extentionだった．これにより，クロスビルドをすると必要なsqliteのバイナリがパッケージに含まれないという問題が頻発した．

github.com

github.com

github.com

次に，Vue3だ．2022年にかなりの部分をVue3に書き換えたのだが，これがあまり楽しくなかった．もともとVue2の時代は，確かに型定義は全然なかったしエディタの補完も効かない状態ではあったが，Easyという点において秀でるものがあった．まぁそれが，アプリケーションがでかくなるとともに辛くなる要因でもあったので，Vue3みたいなものが求められたのだろうが．Vue3にした結果，たしかにそれなりに型はつかえるようになったが，それでもまだまだ全然型がつかない場所は多く，結局Vue2のEasyだけが奪われたような感触を感じた．

そのため2023年後半から書き換えを視野にいくつか試してみた．Svelteもその一環ではあったが，結局エディタの補完がよく効く以上の魅力は感じられず，またVueみたいなものを作るのであればReactに移行することにした．

Next.jsを選んだことに大きな理由はないが，Electronに乗せる都合上，枯れているというのは大きい．

github.com

あと，Next.jsでもReact.jsでもRemixでもなんでもいいのだが，昔ながらのSPAで，Client-side Renderingをしたいというのがある．そういう意味でもSvelteは選択肢から外した．

結局ほぼすべてのコードが書き直しとなった．その結果，現状ではかなり軽くなっている． あと，以前と違ってほぼすべてのロジックをフロント側に持ってきた．これによりipcも最小限になっている．まぁ結果としてバックグラウンド動作みたいなことはほぼできなくなっているが……そもそもレンダリングが重いからバックグラウンドにしたいわけであって，軽いのであれば不要なんじゃないかな．

cssはtailwindを使っている．これはこれで非常に良いので今後もぜひ使っていきたい．のだが，components libraryがtailwind対応してないと結構盛大にぶっ壊れることがわかったので，採用できるcomponents libraryの選択肢は狭まった．

で，今後実装しなきゃいけないものたち

• 検索
• ユーザ名/ハッシュタグ/絵文字の自動補完
• プロキシ設定
• フォローリクエストのハンドリング

GitHub ActionsでTauriアプリのSnapパッケージを自動ビルドする

Tauriでアプリを作っているんだけど，snapパッケージをビルドしてSnap Storeにアップロードしたいと思った．

しかしドキュメントにはsnapに関する記述がない．

tauri.app

また，Tauriは公式でGitHub Actionsを提供していて，こいつを使ってビルドできるのだが，こいつもsnapをサポートしている様子がない．

github.com

tauri-snap-packager

というわけで別のパッケージを使ってsnapをビルドするわけだが，

github.com

こいつを使ってみた．

ただし，これにはいくつか問題点がある．

1. multipassが必要になる
2. ビルドするとsnapcraft.ymlが生成されるが，grade: 'devel' 指定のため，このままだと snapcraft upload できない
3. summaryやdescription もデフォルトのままなのでカスタマイズできない
4. core18に依存しており，かなり古い

1の大きな問題点は，GitHub Actionsだ．GitHub Actionsでmultipassを動かすのはかなり難しい．

github.com

このため，使うのであれば，lxdの方を推奨されており，これはActionsが用意されている．

github.com

しかしここまでクリアしても， gradeの問題は残る． ローカルでやるのであれば，一度 tauri-snap-packager でビルドしたあと，snapcraft.ymlを修正し snapcraft コマンドを再度実行することで再ビルドされる．

しかし，GitHub Actionsでビルドされるとなると，これを毎回シェルスクリプトでやるのは虚しい．

というわけで作った

github.com

独自のtauri-snap-packagerを作った．

差分としては，

1. core20にアップデート
2. grade: 'stable'
3. summaryとdescriptionはtauri.conf.jsonから取ってくる

状態にしたので，ビルドしたらそのままアップロードできる．

全体としてはこんな感じ

jobs:
  snap:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    env:
      SNAPCRAFT_BUILD_ENVIRONMENT: lxd
      SNAPCRAFT_STORE_CREDENTIALS: ${{ secrets.SNAPCRAFT_STORE_CREDENTIALS }}

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Node.js setup
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - uses: pnpm/action-setup@v2
        with:
          version: 8
      - name: Rust setup
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      - name: Install dependencies
        run: |
          sudo apt-get update
          sudo apt-get install -y libgtk-3-dev webkit2gtk-4.0 libappindicator3-dev librsvg2-dev patchelf
      - name: Setup LXD
        uses: canonical/setup-lxd@main
        with:
          channel: latest/stable
      - name: Install snapcraft
        run: |
          sudo snap install snapcraft --classic
      - name: Install app dependencies and build
        run: pnpm install --frozen-lockfile && pnpm tauri build

      - name: Build snap
        run: |
          pnpm run snap
      - name: Publish
        working-directory: src-tauri/target
        run: |
          snapcraft upload ./*.snap --release beta

これでGitHub Actionsから自動でsnapパッケージをビルドして，betaにアップロードするところまでやってくれる．

『駒田蒸留所へようこそ』が良すぎた

今年はなんといっても『駒田蒸留所へようこそ』が良かった． TVアニメ含めた 2022年 2023年アニメの中で一番の出来といっても過言ではない．

見るのが遅くなってしまったので，今頃これを書いているけど，終盤なのでおそらくもう上映館もかなり減ってしまっていると思う．

www.youtube.com

P.A.WORKSのアニメのお仕事シリーズというのは，背後に壮大なストーリーもなければ世界を救ったりもしない，もちろん異世界に行ったりもしないごく平凡な日常ではある． けれど，2010年代に流行った日常系ゆるふわアニメとは少し違っていて，多少の事件はあるし，そこには成長も挫折もある場合が多い． こういう塩梅が非常にちょうど良くて，リアルなアニメに仕上がっている．

さらに早見沙織はこのアニメの声にぴったりだ．実に落ち着いていて空気感にマッチしている．むしろこれを見たあとでは早見沙織以外この声は思いつかない．

駒田蒸留所も，この路線は健在で，実にいい塩梅で仕上がっている．いや，むしろ短い，もっと長い時間かけて見せてほしいくらいのアニメだった． テーマ自体に「時間がかかるもの」であることが読み取れるので，劇場版120分弱だと，アニメのほうが短く感じてしまう．まぁ作るのには相当時間がかかったのだろうが．

吉原正行監督作品は『有頂天家族』以来だけど，あれよりはだいぶリアルによった作品になっている．ただ，気になるのは背景美術くらい． ウィスキーやグラスの表現力はさすがP.A.WORKSという実に見事な仕上がりだけど，空や雲といった美術は『有頂天家族』のときのようなアニメ調．雲を見るとはっきりアニメだと認識させられるのだけれど，これにはなにか意味があるんだろうか． ここまでリアルによった表現で，綺麗になっているのに，なぜ空だけ「アニメです」というような主張にするんだろう．そこだけがちょっと気になった．

mantan-web.jp

これはもっと早く見に行けばよかったと後悔．もう一度劇場に行ってもいいくらいの作品だった．