我が家のプライベートクラウド(自宅サーバ)について紹介します

この記事は Akatsuki Games Advent Calendar の18日目の記事です。

昨日は AZQ1994 さんのSSHで繋がらなくなったOCIサーバーを直した話、
おとといは Yuto Hamada さんの 自宅 kubernetes で cloudflare-tunnel-ingress-controller を使ってお手軽外部公開 でした。

はじめに

もうアドベントカレンダーの後半になり、自宅サーバの排熱で暖を取るのにちょうどいい季節になりました。この記事を書いている 12月15日現在、我が家ではまだ暖房を使わずに過ごしています。

Github のリポジトリのスター数から Unity エンジニアと誤解されることがあるのですが、サーバサイドエンジニアとして働いてます。(趣味の一つとして Unity ライブラリを作ってるだけです)

一応サーバサイドエンジニアが本職なので、今回は趣味で運用している自宅サーバについて書こうと思います。

ネットワーク構成

自宅のネットワーク構成と論理構成図は以下の通りです。

※ ブログ用に実際の論理構成図から一部省略・ポート番号を変えていたりします。

機器選定条件としては、手頃な価格であること・ファンレスであることを重視しています。 枕元から1mもない距離にネットワーク機器とPC類を置いている添い寝自宅サーバなので、静音性が非常に重要な要素です。 そのため、我が家ではファンレスのネットワーク機器にし、PC のファンは静音性が高いものを使っています。

一時期 L2 スイッチの Allied Telesis GS924M V2 を Allied Telesis x510 に変えるか検討したのですが、ファンレスではないので交換を見送りました。

ネットワーク機器に関しては一応19インチラック内の、3U 分(実際は使ってない機器を置いていたりするのでもっと幅を取ってますが) に収まっています。 このラックの上の方に音響機器が入ってたり、これとは別の音響・映像機器が入ってるラックケースがありますが、今回の主題ではないので割愛します。

(ホコリで汚いですが)

1. メインルーター

逸般の誤家庭御用達の YAMAHA ルーターです。 さすが中小規模拠点向けのルーターというだけあって、機能が豊富な上に安定して動作しています。

RTX1210 から標準搭載された LANマップ という機能が非常に便利です。 ネットワーク機器を管理するのに非常に便利な機能で、家のネットワーク機器全部 YAMAHA 製品で統一しようかなと思うくらいです。

あと YAMAHA ルータの特徴としてルータ上で Lua スクリプトを動かすことができます。そのため、我が家では Lua スクリプトで簡単な監視を行っています。

YAMAHA 製品は公式ドキュメントが充実している上、比較的古い機器に対してもファームウェアのアップデートを提供してくれるなど、サポートがしっかりしているので、今後リプレイするとしても YAMAHA 製品になるかなと思っています。

2 . L2スイッチ

一般的な L2 スイッチです。ルータで VLAN を切ってるので、L2 スイッチではタグ VLAN からポート VLAN に変換しています。

3 . PoE ハブ

よく "八丁" と呼ばれているハブです。このハブには 2.5Gbps ポート(SFP は 10Gbps)がついてますが、AP を稼働させるためのただの PoE ハブとして使っています。

4 . アクセスポイント

YAMAHA の AP 製品の中でも小規模拠点向けのものです。小規模拠点向けと言っても、2.4GHz と 5GHz それぞれ50台接続可能なので、家庭用途としては十分な性能です。我が家は ESP32 とかを使っているので、同時接続台数が多いですが、特に問題なく動作しています。

業務用APはコンソールポートから設定するのが一般的ですが、YAMAHA ルータと併用しているので、ルータの Web UI から HTTP プロキシー経由で AP の Web UI にアクセスできるので便利です。また、LANマップ機能を使うと接続している機器の情報も確認できます。この機能を使いたいために YAMAHA の AP を購入しました。

業務用APなので電源アダプタが付属していないので別途購入するか PoE 給電が必要です。我が家では先述の八丁のハブから PoE 給電しています。また、壁掛け金具が付属しており、我が家は賃貸なので壁付できないので 2x4 アジャスターで立てた柱に取り付けて運用しています。

予備・稼働していない機器

現在常時稼働しておらず、論理構成図に記載していない機器だが、所有している機器としては以下のものがあります。 (普通の電気屋に売ってる家庭用のルータとかハブを何台か持っていますが、これらは省略しています)

  • YAMAHA RTX1200
  • NEC IX2215 (2台)
  • ELECOM WAB-i1750-PS (2台)

IX2215 と ELECOM の AP に関しては使い道は無いが安かったから買ったものです。IX2215 は購入後動作確認とファームウェア更新をしましたが、何も設定が入ってないです。何か実験的なことをする時用に使えるかなと買ったのですが、使う機会がないまま放置しています。

YAMAHA RTX1200 に関しては現用の RTX1210 購入前に使っていたものになります。 メインルータが壊れたとき用の予備機として一応設定はしてありますが、電源を入れずに保管している状態です。

サーバ構成

サーバ構成としては Proxmox が入ってる PC を1台、監視用としてラズパイが 1台稼働しています。 また QNAP の NAS がストレージ用として稼働しています。

Proxmox のサーバを2台体制にしても良いのですが、現状サーバの CPU リソースが余っているので1台体制で運用しています。VM のバックアップを定期的にとって NAS に保存しているので、万が一サーバが壊れたときはバックアップから復元する気持ちで運用しています。

VM の管理ですが、Terraform と Ansible で構築したものと手動で構築したものがあります。 動かしたいものが確実に決まっているものに関しては Terraform と Ansible で構築しています。 サンドボックス環境であったり、USB, PCI Express, SATA ディスクをパススルーしている様なハードウェア依存の高いものは手動で構築しています。ちなみにですが、5日目の記事で使っている Prometheus と Grafana は Terraform と Ansible で構築した VM の上で動いています。

VM で動いている OS ですが、個人的な好みで基本 Arch Linux を使っています。 デスクトップ環境が必要なものは Arch 系の Manjaro Linux で、一部 Debian と Rocky Linux を使っています。 また、Windows もありますが、特に使っておらず遊んでいる状態です。

VM の構築

VM 構築ですが、宗教的な理由で Arch Linux を使ってる関係で他のディストリビューションに比べちょっとインストールに手間がかかります。 毎回手動インストールするのは大変なので、Packer を使って作成したイメージに cloud init を使って VM を構築しています。

Packer では Arch Linux のインストール後、ある程度のパッケージをインストールを行っています。 Arch Linux をインストールしただけだと、git や wget, vim すら入っておらず、VM を使う時にインストールするのが面倒なので Packer で入れています。また、AURヘルパーとして yay、Proxmox との連携のために qemu-guest-agent も入れています。 あとは VM 構築時の初期設定用に cloud-init をインストールしたイメージにしています。

Packer で作成したイメージを Terraform や手動で VM を作成するのですが、初期設定に関しては cloud-init で行っています。 cloud-init を使うことで、VM のユーザ名やIP アドレス、SSH 用の公開鍵を VM 作成時に設定できるので、VM 構築時に手動で設定する項目がほとんどなくなります。立ち上がったら yay -Syu をしてパッケージを更新するぐらいです。

Proxmox から各 VM のメトリクスを収集しているのですが、VM 構築時に docker で Node Exporter を動かし Prometheus で監視することが多いです。ただ、VM によっては Node Exporter が不要な場合があるので Packer で入れておらず、exporter インストール用の専用シェルスクリプトで毎回入れています。あと一部の VM に関しては Web コンソールとして Cockpit も入れています。

なぜ自宅サーバを運用しているのか

検証環境をサクッと作れたり、環境構築周りで色々勉強になるので自宅サーバを運用しています。 ちょっと何か動かしたい時にすぐに動かせる環境が用意できるのも理由の一つです。 また、クラウドでは運用できないもの(Flightradar24 feed とか)をしている関係上、自宅に 24/365 で稼働している PC が必要なので自宅サーバを運用しています。

あとは個人的に下手にクラウドサービスでコンピュートリソースを借りるより、自宅サーバを運用した方が安上がりだと思っています。 自宅サーバはペットを飼っているようなもので、面倒を見る人的コストのことを考えてはいけません。 サーバの面倒見るのが嫌だったり、お金を出せるのであればクラウドサービスを使うのが一番です。自宅サーバはあくまでも盆栽遊びの延長だと思っています。

自宅の消費電力を可視化してみた

この記事は Akatsuki Games Advent Calendar 2024 の5日目の記事です。

はじめに

近年夏場の電力需要の増大による電力不足が問題になっていたり、電気料金の値上げにより、電気代の請求金額に驚くことがあります。 そこで今回は節電意識の向上と興味から自宅の消費電力をメトリクスとして計測してみました。

スマートメータ

昔の電力量計はアラゴの円板を利用してメーターを動かし積算電力量の測定を行うアナログな誘導型電力量計でしたが、最近の電力量計はスマートメーターと呼ばれるデジタル化された電子式電力量計になっています。

このスマートメーターは単に積算電力量をデジタル化されたものではなく、通信機能も搭載しており、スマートメーター本体と電力会社と通信することが可能になっています。(スマートメータは内部的に計量部・通信部・端子部の3つのブロックで構成されています)

スマートメータと電力会社との通信方法としてはマルチホイップ方式、1:N方式(携帯回線)、電力線通信(PLC)が存在します。 電力会社との主の通信方式として九州以外ではマルチホップ方式が採用され、主方式での通信が難しい場所に関しては1:N方式やPLCが採用されています。 (九州では主に1:N方式が採用され、関西はマルチホイップ方式ですが 2.4GHz 帯を使ってます。電力会社によって主方式が異なってるのが興味深いです。) https://www.meti.go.jp/shingikai/energy_environment/jisedai_smart_meter/shiyo_kento_wg/pdf/001_03_01.pdf#page=4

スマートメータと電力会社が通信可能なため、毎月電気代の請求のために検針員の方が電力量計を見て回る必要が無くなる上に、電力供給の停止・開始などの遠隔で制御が可能になっているようです。 (一部のガスメータもスマートメーターになっているようで、遠隔検針も行っているようです。)

参考までにスマートメーターの通信方式はのこのページに詳しく書かれています www.tepco.co.jp

Bルートとは

スマートメータの通信機能は電力会社との通信目的ではなく、需要家(消費者)への情報提供も可能になっています。

スマートメータが計量したデータを送るルートによって Aルート、Bルート、Cルートという名称があり、
スマートメータと電力会社(送配電事業者)との通信を Aルート、
スマートメータと需要家との通信を Bルート、
電力会社と小売事業者との通信を Cルートと呼びます。

この Bルートの詳細としては、スマートメータから需要者側で用意したHEMS (Home Energy Management System) 機器へ計測データを直接送信する電力メーター情報発信サービスとなってます。Bルートで取得可能な情報としては積算電力量測定値(kWh)、瞬時電力測定値(W)、瞬時電流測定値(A)などがあり、これらは随時取得可能です。

スマートメータとHEMS 機器との通信に関しては Wi-SUN 方式が採用されています。 *1 驚くべきことに、スマートメータから電力会社まで送るAルートと需要者側へ送るBルートでは異なる通信方式が採用されていたりします。(以外とスマートメータは高性能だったりします)

余談ですが、Bルートを使う以外にも自宅の消費電力を計測する方法も一応存在し、電流測定アダプタを分電盤内などに取り付け計測するか、パナソニックのスマートコスモのような計測アダプタ一体型の分電盤に交換する必要があります。(※ 分電盤交換には電気工事士の資格が必要です。) 幸いにも自分は有資格者なので分電盤交換で各回路ごとの計測が可能になるのですが、賃貸に住んでいるため貸主の許可なく構造物の変換ができません。

Wi-SUNモジュール

スマートメーターと HEMS 機器との通信規格に Wi-SUN (Wireless Smart Utility Network) が採用されています。 この Wi-SUN はIEEE 802.15.4g規格に基づく通信になります。

日本の Wi-SUN は ISM バンドのうち 920MHz (サブギガ)帯を利用した特定小電力無線となっています。 日常生活で使う ISM バンドの無線機器の代表例として 2.4GHz 帯の Wi-Fi や Bluetooth がありますが、Wi-SUN ではそれらより低い周波数帯域の 920MHz 帯を利用しています。

920MHz 帯ですが、2.4GHz 帯と比べ波長が長くなるため回折性が高く、建物内部への伝播特性が良いという特徴があります。また、通信距離も長くなり、消費電力の面でも有利になります。デメリットとしては伝送能力が低いため、大量のデータを送信するのには向いていないという点があります。 スマートメータは基本的に宅外に設置されるため、より建物内部で電波が届き、伝搬距離の面でも有利になる 920MHz 帯が採用されたのは不思議ではありません。

ただ、Wi-SUN は既存の 2.4GHz 帯の通信技術とは全く別物ということに注意が必要です。さらに、Wi-SUN の普及率が良いとは言えません。そのためか、販売されている Wi-SUN モジュールの選択肢が少く、Wi-Fi モジュールに比べると高価です。

スマートメータとの接続準備

スマートメータと接続するには HEMS 機器(Wi-SUN モジュール)を用意する必要があるのですが、今回は ROHM 社の BP35A1を利用しました。*2 Wi-SUN モジュール(BP35A1)の制御は M5StickC Plus で行うのですが、BP35A1 との接続変換に M5StickC/Plus用Wi-SUN HATキット を利用しました。

Wi-SUN モジュールを用意するだけではスマートメータと接続できず、送配電事業者(関東であれば東京電力パワーグリッド株式会社)へ申請を行う必要があります。申請方法に関しては各電力会社のホームページに記載されています。申請内容に問題がなければ数日後、電力会社からスマートメータの接続に必要なIDとパスワードが送られてきます。

スマートメータとの接続

M5StickC/Plus用Wi-SUN HATキットの作者さんがサンプルスクリプトを公開してくれていますが、MicroPython で書かれており、個人的に Arduino ベースで動作させたかったのでライブラリ含め自作しました。

github.com

接続フロー

スマートメータとの接続フローをざっくり書くと以下の通りです。

  1. Bルート接続用 ID/パスワードを設定
  2. チャンネルスキャン
  3. スキャン結果から各種パラメータ設定 (IPv6アドレス, 使用チャンネル, PAN ID)
  4. PANA セッション接続

BP35A1 のコマンドリファレンスがメーカーが公開しているので、基本的にはリファレンスを参考にしながらコマンドを送信し、レスポンスを読み取る形になります。

この時に注意しないといけないのが、BP35A1 を購入した状態ではレスポンスがバイナリ形式で帰ってくるため、ASCII 変換モードを有効にする必要があります。GitHub 公開時にこの処理が抜けていたため Pull Request をいただきました。*3 Pull Request に書いてある通り、ASCII 変換モードが有効かは BP35A1 の内部フラッシュに記録するため、一度有効にしてしまえば次回以降も有効になるのですが、書き込み制限があるため注意が必要です。

送信コマンド

コマンドは改行コード CRLF で区切られた1行の文になります。コマンド引数に関してはスペース を利用します。

例えば確立している PANA セッションを終了するには、SKTERM\r\n というコマンドを送信します。その結果、OK\r\n または FAIL ER10\r\n のどちらかが返ってきます。また BルートIDを送信するには SKSETRBID <ID>\r\n というコマンドを送信することになります。

スマートメータとの電波が悪かったり、設定が間違っていたりするとチャンネルのアクティブスキャンや PANA 接続のタイミングで失敗すると思います。

注意点

コマンドを送ってスマートメータからデータを取得する時に注意しなければならない点に通信時間の制限があります。 920MHz 帯は電波法で1時間あたりの送信時間総和が360秒以下と規定されています。法令で規定されていますが、電波は共通資源なため、無闇矢鱈に通信して帯域を占有してはいけません。

スマートメータからデータを取得

PANA のセッション確立後はスマートメータから消費電力などの情報を取得できるのですが、この時 BP35A1 の SKSENDTO コマンドのパラメータとして ECHONET Lite フレームを送信する必要があります。 ECHONET Lite の仕様も公開されています。 実際に詳細規定を見てもらうと分かるのですが、様々な機器の規定が書かれているため膨大な量になっています。

ECHONET Lite の説明をすると長くなるので省略しますが、 ECHONET Lite フレームはヘッダ情報やオブジェクト情報に加えデータが欲しいパラメータのコマンドで構成されています。 GitHub で公開しているものだとフレーム作成はこのあたりの処理になります。

例えば、瞬時電力計測値(W)を取得する場合は以下のフレームになります。

{0x10, 0x81, 0x00, 0x01, 0x05, 0xFF, 0x01, 0x02, 0x88, 0x01, 0x62, 0x01, 0xE7, 0x00}

動作例

送信時間総和を超えなように sleep を入れつつ瞬間電力量・瞬間電流量を取得したものを M5StickC のディスプレイに表示するとこんな感じになります。

※ この gif は消費電力が上がるのが分かりやすいようにドライヤーを稼働された時のものを早送りにしています。

青字で瞬間電力、その下に瞬間電流を R相、T相 それぞれの値が取得できるので分けて表示しています。

R相 ですが ECHONET Lite の仕様では少数も送られてくるように書かれているのですが、実際は少数以下を切り捨てられた値が送られてきます。そのため、R相は 0.0A の表記になっています。 自宅の電気配線が R相にキッチン・水回り・エアコンが配線され、T相が居室になっている都合上、エアコンやキッチンの電化製品を動かさない限り相のバランスが悪いです。冷蔵庫のコンプレッサが止まっているとさらに片相に負荷が集中してしまいます。

今回は極端な例でドライヤーを稼働させましたが、部屋のLEDシーリングライトを消すだけでも消費電力が十数ワット減り、節電の実感が得られます。

メトリクスを収集する

スマートメータから瞬間電力量・瞬間電流量が取得できるようになりましたが、これらをグラフで可視化するためにメトリクスを収集することにしました。

メトリクス収集には Prometheus を採用しました。Prometheus 以外のメトリクス収集ツールや、可視化用の SaaS など選択肢がありますが、既に Prometheus を使って別のメトリクスを収集しているため Prometheus で統一することにしました。

Prometheus のメトリクス収集ですが、Grafana Labs の prometheus-arduino というライブラリを利用しました。

github.com

リポジトリの Readme に書かれていますが、このライブラリは Prometheus の remote write という機能を利用しています。Prometheus は pull 型のメトリクス収集ですが、十数秒に一度データ取得している関係上、pull 型だとデータ取得できないと過去のメトリクスを返すことになります。そのため、remote write endpoint を利用して push 型のようにメトリクスを送信しています。

また、Prometheus にメトリクスを送る頻度ですが、Batching 機能である程度メトリクス貯めてから送信しています。

Grafana で可視化する

Prometheus でメトリクスを収集しているので Grafana の DataSource に Prometheus を設定することで Grafana のダッシュボードで可視化できます。 また、アラート設定をして月の消費電力量が一定以上になったら通知を飛ばすとかも可能になります。

参考までに自分が見ているダッシュボードはこんな感じです

この画像から帰宅後に増えた消費電力や、どれぐらい家電が電力を消費しているか分かります。 また、部屋の温度のメトリクスを別途取っておくとエアコン稼働開始時の消費電力と室温の推移が見れて面白いかもしれません。

まとめ

今回は Bルートを使って現在使ってる消費電力を M5StickC Plus のディスプレイに表示して収集したメトリックから Grafana で可視化してみました。 ただ電源を消すだけだと節電に繋がってるか実感しにくいですが、M5StickC に表示されている消費電力が下がったりすると節電したぞという実感がより得られます。

*1:設置環境等で Wi-SUN 方式が困難な場合 PLC 方式を採用する規定ですが、よっぽどの理由がない限り低圧受電では Wi-SUN 方式のようです。

*2:この記事を書いてる 2024年12月時点では 製造中止を申請中のステータで、小売での購入は可能ですが、そのうち販売終了になりそうです。

*3:https://github.com/nasshu2916/BP35A1-Wi-SUN-Arduino/pull/2

MotionBuilder のスケルトンを強制的にTポーズにさせるスクリプト

この記事は Akatsuki Games Advent Calendar 2023 の19日目の記事です。

昨日の記事はぐんそうさんの エンジニアチームの成長を目指した、輪読会の取り組み ~どんな形式で、どんな書籍を読んできたか？~ でした。 チームみんなで輪読会で、技術的な知識の向上だけでなく、チーム全体の共通の認識を作る行う取り組り、書籍の選定から輪読会、振り返りのサイクルをうまく回してる素敵なチームですね。

はじめに

MotionBuilder でキャラクタライズをする際に スケルトンを Tポーズにする必要があります。Character Controls を見ると Bone が正しく Tポーズになっていないと、警告が表示されます。

これを解決するには、 Bone を1つ1つTポーズになるように回転させる必要があります。数体であれば気合いの手動でやることもできますが、モーションキャプチャーで撮影したモーションデータをキャラクタライズする場合など、数十体行う必要がある場合手動では到底無理です。そのため、選択したスケルトンを 強制的に Tポーズにするスクリプトを作りました。

続きを読む

ぼくのかんがえたさいきょうのバーチャル美少女配信システム

この記事は Akatsuki Games Advent Calendar 2022 の 20 日目の記事です。 昨日は @yuji_ap さんの「UI Toolkitでステージエディタを作ってみた」でした。 今までの IMGUI でのエディタ拡張は全て C# のコードで書いていたのに対して、UI Toolkit は構造の定義は UXML USS で、見た目を定義は USS というのはどことなく Web ページの構成と似ていますね。

adventar.org

はじめに

アカツキゲームスではオフィス出社に加え在宅のハイブリッドワークの形で仕事をしています。 Zoom 会議がしばしばあるのですが、アカツキゲームスの一部メンバーはバーチャル美少女の姿で参加していたりします。去年の Akatsuki Advent Calendar 2021 にもバーチャル美少女でZoom参加する記事があったりします。

バーチャル美少女のZoom 参加するためのシステムを自作しているのですが、その遍歴とその概要を紹介しようと思います。 ぼくがつくったさいきょうのば〜ちゃるびしょうじょのはいしんしすてむです。

続きを読む

物理照明卓で Unity のクリスマスツリーをライティングしてみた

この記事は，Akatsuki Advent Calendar 2021 の21日目の記事です．

adventar.org

昨日は @sejimhp さんの「DCGAN(深層畳み込み敵対的生成ネットワーク)のコードを追ってみる」でした。

qiita.com

はじめに

クリスマスまであと数日。なので、クリスマスツリーのライトアップ をUnity でします。

Unity の Timeline でライトアップのアニメーションを作っても面白くないので、物理照明卓(照明用コントローラー)から Unity のクリスマスツリーのライトアップを制御しようと思います。

舞台やステージの照明では、照明卓から DMX512-A という制御信号で、一般照明や LED ライト、ムービングライトなどの制御しています。

DMX512 - Wikipedia

この照明制御の信号読み取って Unity に送り、照明卓から Unity 内の照明も一緒に制御をしようという作戦です。

続きを読む