自宅のTV録画サーバ兼NASを新調した

自宅のTV録画サーバ兼NASを新調した。
録画サーバとNASを前に作ったのは 8 年前で、ほぼ8年間稼働しっぱなしだったので、さすがに古くなってきたと思って新調した。
今年始めにメインのデスクトップPCを組んだので、今年に入ってから2台目の自作PCとなった。まぁ、そういうこともある。

ハードウェア構成

ハードウェア構成はこんな感じ。ケースとケースファンは流用。

項目型番とか大体の値段
マザーボードASRock H610M-HDV/M.2\11000 くらい
CPUintel Celeron G6900(Alder Lake)\7000 くらい
メモリADATA AX4U320088G16A-DCBK20 8GBの2枚セット\7300 くらい
システム用 m.2 SSDWestern Digital WDS480G2G0C 480GB\6300 くらい
電源Scythe CORE-TFX275\3300 くらい
データ保存用 HDDSeagate ST8000DM004 8TB\15000 くらいを2台
合計\65000 くらい

データ保存用のHDD を除くと \35000 くらいで、既製品の NAS の箱と同じくらいの値段になったりするのだけど、メモリを16GB積めていてこれがキャッシュとしてきいてくれていい感じであってくれ、という気持ち。
でも家のネットワークが未だに 1GBit Ethernet なので結局こっちがネックになる感じはある。

CPU はAlder Lake世代で一番性能が低いものだけど、用途を考えれば十分だと思う。というか、シングル性能は i9-10900 と変わらないということらしくなんか未だに CPU は進化を続けているのだなぁと思う。
いろいろなことをしたくなって性能に不足を感じるようになってきても、多分 i3 くらいまでは載せ替えても電源の面でも熱の面でも問題は起きないと思う。

録画機能の選定

8年前は、chinachu というTV録画用のwebサービスを使って、環境を構築した。
今回も chinachu を使おうと考えていたのだけど、この8年の間に chinachu のテレビ録画ボードを操作するAPIを提供することを目的とした部分が Mirakurun として切り出され、 chinachu 自体にはこの API を操作するための Web UI が残されるという機能分割が行われたようだった。
で、その Web UI の方についても obsolete になるらしく、じゃあどうやって使えばいいのかと思ったんだけど、 Web UI の部分を置き換えるいくつかの代替品があるらしく、それと組み合わせて使うといった形になったらしい。

今回は、Web UI としては EPGStation というものを使うことにした。
EPGStation と chinachu はともに Docker 内で動くようになっており、両方をまとめて起動できる docker-compose 用のファイルも配布されていたので、これを使うことにした。

心残り

標準の状態では Quick Sync Video を使わずに、完全にソフトウェアでトランスコードするので、トランスコード時の CPU の負荷が高い。
Dockerfile 内で FFMpeg をコンパイルしているので、ここで必要なライブラリやコンパイルオプションの追加をすれば、 QSV を利用可能になる。でも、とりあえずソフトウェアエンコーディングでも性能が足りているようなので、後回しにすると決めた。

OS の選定

録画機能がDocker コンテナの中で動くということで、物理マシンに直接インストールする OS についての制限はなさそうだったので、長期的にちゃんとアップデートを行っていくことを念頭に置き、 arch linux をホストの OS として用いることにした。

NAS 機能

録画機能が docker-compose で管理されているので、NAS機能の方も docker-compose で管理することにした。
debian のベースに samba をインストールした Dockerfile を書いて、それを使った。
NAS 用のディスクは btrfs の RAID 1 でフォーマットした。1台壊れても大丈夫だし、容量足りなくなったら大きめのディスクを足せば良いだけのはず。

心残り

samba に対する書き込みを行っている際に、 docker-proxy というプロセスがそこそこ CPU を使っていることに気づいた。
このプロセスはコンテナの中と外の通信を仲介する役割であり、–userland-proxy=false オプションを docker daemon に与えるとこれを使わずに、iptables で代替の処理を処理を行うようになるようだ。多分、iptables でやったほうが軽くなるだろうとは思うのだけど、とりあえず性能面で今すぐ困る感じにはならなかったので、標準の状態でいいやと言うことにした。
今後、コンテナで大量の通信を行うような利用法を考えるときにはこのオプションについて真面目に検討しようと思う。

ARM64 な VM に サーバーの引っ越しをした

今あなたが見ているこの blog の html は ARM プロセッサ上の VM から送られてきているんだ。(唐突)

Oracle Cloud の ARM インスタンスの無料枠に引っ越した

というわけで、海外の VPS (vultr) に乗り換えてから2年くらい経って、なんだか大したことしてないのに結構高くついちゃってるのが気にかかっている状況が割と長く続いていたので、この blog を含む各種サービスを Oracle Cloud の ARM インスタンスの上に引っ越しました。

VM の上では、この blog であったり、ちょっとしたツールを雑に作るための nodered であったり、grafana や chronograf といった可視化ツールを docker-compose で管理して動かしています。この blog には大したアクセスはないし他のサービスは自分しか使っていなくて CPU の負荷は小さい一方、いろんなサービスを動かし続けて置く必要はあってメモリは割りと多く使う状況で、CPU弱くてもメモリがたくさんある、安く使える環境があったらいいなぁと思っていました。

そんな中、 Oracle Cloud では ARM の CPU を 4コア分、メモリは24GB 分無料で使えるぞということを聞きつけ、こりゃあいいと思って、思い切って移行しました。

もともと各種サービスはすべて docker-compose による管理を行っていたものの、 x86_64 で動かすことしか考えておらず、ちゃんと移行できるんだろうかというのがネックでしたが、サーバサイドの ARM64 も出てきてずいぶん時間が経ったせいか、使っていた docker のイメージについては cAdvisor 以外は ARM64 のイメージがあり、MySQL については新しいメジャーバージョンにしか ARM64 用のイメージがなくバージョンを移行する必要があったりもしましたが、おおよそつつがなく移行できました。

昔、docker とサーバーサイドの ARM64 が出て来つつあるのを、自分はほぼほぼ同じタイミングで認識しました。で、イメージが cpu のアーキテクチャにがっつりと依存する docker が流行ったので、docker のせいで ARM64 がサーバサイドで広く使われるようになるのは少し遠のいたようなきがするなぁと思ったりもしたのですが、それから結構経って、ARM64 でも docker がずいぶん普通に使えるようになったことが確認できました。
今や macbook さえ ARM64 な時代ですしね。そんなもんなのかもしれません。

そんなわけで、 ARM1コア 6GBメモリで機嫌よく動いています。
無料の範囲だ。本当にええんか。

今後の予定

引越し後も相変わらず docker-compose でサービスを管理しているのですが、まだARMが 3コア、メモリは18GB 残っていて、かつ k8s のマネージドサービス自体はこっちも無料で使える ので、残ったコアとメモリで k8s の素振りでもして慣れてきたあたりでまたそちらへ引っ越そうかなぁと思っています。
最近、仕事で k8s に触れる機会が増えてきたので、趣味と実益を兼ねてぼちぼちやっていきたいですねぇ。

core i7-12700 を CPU に使ったPCを組んだ

あけましておめでとうございます。
最近、メインで使っている Windows のデスクトップ PC で曲を書いているときに CPU の不足を如実に感じるようになってきたので、PC を新調しました。
前回、前々回購入したデスクトップ PC は、 mouse computer で買って、出来合いのデスクトップ PC に SSD やら GPU やらのパーツを足して使っていました。
今回は、core i7-12700 という CPU がどんなもんなのか気になって仕方なかったので、パーツごとに自分で買って、いわゆる自作 PC を作りました。

今回使ったパーツ類

最後に PC を自作したのは、およそ 8 年前で、そのときには celeron j1900 ベースの録画マシンを作りました。
その頃と比べると、最近は CD-ROM/DVD-ROM ドライブはそもそもつけなかったり、HDD/SSDも m.2 でマザーボードに直接つけるようになっていたりと、配線が随分少なくなり最近は随分手軽になったんだな、という印象を持ちました。

主目的は先に書いたように CPU の性能不足の解消なのですが、CPU の新しい機能に興味があってそれがどのように動くかを見るというのもサブの目的としてある。というのも今回選んだ core i7 12700 には高性能な Performance-cores と高電力効率の Efficient-cores が乗っており、Windows 11 ではこれらをうまいこと使い分けることで高性能を実現しているらしい。
当然 Linux にも今後類似の機能が実装されていくことになるわけなので、その進化をソースコードレベルで負いつつ実感してみたいなと思っている。

というわけで、CPU の機能を直接叩くために、久々に VM 上ではなくベアメタルで Linux を動かす必要があるので、すごく久しぶりに、 Windows と Linux の dual boot 環境も作ってみるつもり。
楽しみだなぁ。

4K モニタを 2 枚買った

27 インチの 4K モニタを買いました。
LG の 27UL650-W というモデルで、1枚あたり4万3千円くらいでした。
電車が人身事故で止まってしまい、仕方ないなといって降りた駅近くにあった電器屋さんで見かけて、ベゼルも狭くてシンプルな出で立ちだし、これいいんじゃないか?って思ってこれに決めました。

https://www.lg.com/jp/monitor/lg-27UL650-W

これまでは、12年ものの 24 インチの WUXGA のモニタを 2 枚、縦にモニターアームを使って積んでいましたが、今回同じように縦に積みました。
12年も使ったんだから、もう流石に新調していいだろうって。

モニターアームは、24 インチから 27 インチに大きくなったんだから、モニターアームも長いものにしなきゃと思ったんですが、実際には長くする必要がなくて、上の方にはみ出してしまってなんか不格好になりました。
これは高さが 70cm あるんですが、60cm くらいで充分足りました。これはちゃんと計算すれば事前にわかったことなので、反省。

高解像度のディスプレイを使ってみて思ったのだけど、パソコンの文字が読みづらいと感じる一端は、解像度の不足だったかもしれないなーって思った。解像度が高いと単純に文字が読みやすくなる。

MacOS で使ってみた

最近 Macbook Pro 13 を買ったので、thunderbolt から hdmi への変換を 2 つ買って、2 枚のモニタに表示してみました。
仮想解像度は、2560 x 1440 くらいが、自分にはちょうどよかったです。
確か、27インチの5KディスプレイのiMacも仮想解像度の横幅が2560だったはずだなので、作ってる側も想定しているくらいの密度なんだろうなーと勝手に思いながら使っている。
画面に出せる情報量が増えて、文字もきれいで読みやすくなったので大満足。

主にブラウザ、vscode、IntelliJ、terminal くらいしか使っていないので、特段困ったことはありませんでした。
昔から高解像度モニタに対応しているからストレスなく使えるなーって感じ。

Windows 10 で使ってみた

Scaling は 175% にして使ってみた。
ブラウザ、vscode、IntelliJ あたりはまともに動く。

Studio Oneもまともにうごく。一部のvstプラグインについては、Studio One 側の機能であるスケーリングがまともに効かない。
普段から使用頻度が高いVSTがうまく動かなかったりするのでそこそこストレスフルだけど、まぁ許せる範囲。

Arch Linux(xfce4) で使ってみた

上記 Windows 10 にインストールされた VirtualBox 上に作った Arch Linux の VM に、以前から xfce4 環境を構築していたものの設定を変更。
設定を変更したのは下記URLに記載のある1箇所だけ。何の問題も生じていなくていい感じ。

https://wiki.archlinux.jp/index.php/HiDPI#Xfce

ノートPCを新調したりVPSを乗り換えたりした

なんか、最近、普段家で使ってるコンピューター周りを色々変えたのでそれについて書いてみる。

ノートPCを新調した

2014年頃のmacbook air 11inch から、色々悩んで2019年のmacbook pro 13inchのusb c端子が4つついてる方に乗り換えた。VMなどをそれなりに動かすことになるだろうと考え、メモリは16GB、SSDは512GBにした。
新調の一番の理由は、コタツを導入したのでコタツで色々できるようにしたかったけど、それには5年前のmacbook airでは主にメモリの量を中心に辛いと感じることが増えてきたこと。
新調にあたっては、現行の各種macbookはusb cしかついていないことが気に食わず、windows のノートPCにしようかなとも思ったのだけど、そうすると、ctrl + p,n,f,b あたりでのカーソルの移動ができない場面が増えてストレスを溜めるのだろうなぁと思ってしまったので、結局macにしてしまった。

usb cについては、実はあんまり外に何かを付けて使うということ自体がないけれど、もしもつけたとしても、電源やら画面やらを1本のケーブルにまとめられて、今はもう便利だとしか思わない。
昔は、usb cからいろんな端子に変換するための変換器みたいなのの種類が少なかったり値段が高かったりで大変だったみたいだけど、2019年だともうそんなでもないのかなと思った。

そんな感じで、家に帰ってきてもコンピューターいじるときは机と椅子に座ってガッツリと向き合うしかなかった状態が、こたつで緑茶でも飲みながらのんびりと色々する、みたいに変わった。

あと、結構前だけどテレビにkindle fire tv stickを刺した。なので、家族と一緒にスマホで撮った写真をみたり、webページを一緒に眺めたりといったときも、kindle fire tv stick に Air Playで接続してさっさとテレビに画面を表示できるようになった。これが想像以上に便利で、テレビは見るだけのものから、家族の間で情報を共有するための道具に変わってきたな、みたいな意識の変化があった。

windowsのノートPCを選んでいたら、Air Playではなくmiracastで画面を表示することになると思うんだけど、miracastについては使ったことがなく、どの程度使い勝手が良いものなのか知らない。実際のところどんな感じなんだろうか。

VPS乗り換えた

かれこれ7年くらい、sakuraのVPSを何度かインスタンスのタイプを乗り換えつつメインで使い続けてきたけど、支払いが月極なので、遊ぶ際にインスタンスを新しく作ったり破棄したりといったことがやりづらくて辛いという理由で、色々お試しするときののVPSについては別の海外のVPS業者の日本リージョンを併用している状況が1年ほど続いていた。
(sakuraにおいて、インスタンスを上げたり壊したりといった用途には、おそらくsakuraのVPSではなくsakuraのクラウドが想定されている。だから、自分がsakuraのVPSがターゲットとする客ではなくなってしまったので辛いという話であって、sakuraのVPSのサービス内容が良くないというわけではないと思う。)
海外VPSを1年使って、これと言ったトラブルも特になかったため、sakuraの方は引き上げ、海外VPSの方に一本化した。
もともとsakuraにメモリ2GBのインスタンスが1台、海外VPSの方にメモリ1GBのインスタンスが1台あったが、これを4GBメモリの海外VPSに1台にまとめた。
値段的にはsakuraのメモリ2GBと海外VPSのメモリ4GBが同じ価格だったので、月々の支払いは減ることになったし、管理対象も減ったし、いい感じだなーと思っている。

引っ越しにあたり、勉強も兼ねて、ホストOSの上にソフトを色々インストールするのは控え、全部dockerコンテナの中に入れた。全部のサービスをdocker-composeで管理するようにした。
結果として、自分がどういうサービスを立てているのかということが明確になって、覚えておかなきゃいけないことが減ったので良かったなぁと思った。

あ、なので、このblogも実はお引越ししたあとだったりします。なんとなくテーマも変えました。

k8s のクラスタを組んでその上に全部移すということも考えたけれど、自分が動かしっぱなしにしておきたいアプリケーションの総量に対して、k8s 自体の主にメモリに対するオーバヘッドが大きすぎてなんかもったいない気がしたというのと、スケールアウトしなきゃいけないほど上で動くアプリケーションが増えたり減ったりするわけでもなく、コンテナ冗長化をかっこよく行う必要も特にないなーと思ったので、シンプルにdockerとdocker-composeで全部済ませてしまうことに今回はした。
k8s がこなれてきて、オーバヘッドがあんま気にならないくらい小さくなってくるというか、オーバーヘッドが小さい構成も手軽に組めるように状況が整ってきて、自分自身がそれを使いこなすノウハウがこの先数年で溜まったら、k8sベースにすることもあるのかもしれない。と思う。

なんかまぁ、そんな感じです。
全部コンテナに入って取り回しが良くなったので、調子よく色々やっていきたいなー。