【検証完了】あのバグと、あのCPU爆破祭りのその後。〜自動配信＆Synology Photosのアンサー編〜　

　ここ最近、自宅のインフラ環境で色々と検証を重ねていたのですが、それぞれの件について「ケリ」がついたので、アンサー編としてまとめておきます。

1. YouTube Live自動配信のストリームキー問題：完全勝利

　まずは、PythonのAWS Lambdaスクリプトを使って自動化を試みていた、防犯カメラ（セキュリティカメラ）のYouTube Live配信枠作成の件。

前回の配信ではストリームキー周りの挙動が怪しく、枠は作れても上手くストリームを掴んでくれないという謎の挙動に頭を抱えていたのですが……

結論から言うと、6月1日の処理でストリームキーも正常に反映され、普通に大成功しました！

仕様の壁を綺麗にクリアして、想定通りの自動化ラインが綺麗に開通した瞬間の快感はやっぱりたまらないですね。これで我が家の防犯カメラ配信システムは完全に安定運用フェーズに入りました。これにて一件落着！

2. Synology Photosで画像9万枚シバき倒し事件：無念の全面撤退

　さて、問題はこっちです。
我が家のエントリーモデルのNAS（DS220j）に過去の一眼レフ画像やウマ娘のキャプチャなど9万枚以上をブチ込み、DatadogのダッシュボードでCPU使用率「1350%」というセルフDoS攻撃を記録したあの事件。

大雨の日にフレックス特権を使ってインストールしてから丸9日。
「100%になってインデックス生成タスクが終われば、きっと快適なAI画像管理ライフが待っているはず……！」と健気に信じて待っていたのですが。

結局、サムネの処理がすべて終了した後も、信じられないくらい遅いまま。

どれくらい使い物にならないかと言うと、別フォルダに置いているただのmp4ファイルを再生しようとするだけで、画面がカクついてまともに再生できないレベルでシステムリソースを喰い潰されます。

「あ、これアカンわ。DS220jの細いCPUでこのパッケージを回すのは人権がない」

と冷徹に判断し、『Synology Photos』は速攻でアンインストール（削除）しましたwwww 丸9日間、我が家のNASが全力でファンを回して部屋を暖め続けたあの時間は一体何だったのか。

データの行方

とはいえ、行き場を失った大量の過去データたち。 昔一眼レフで撮った、めちゃくちゃ可愛い懐かしの「ねこ」の写真たちの遺産は、もう割り切ってすべてAmazon Photosの闇（クラウドストレージ）に送り込みました。

スマホの画像と一緒に、あっちのクラウドで雑にバックアップされておくれ……（ねこ、パッと検索できるようになるといいな）。

やはり、NASでAIベースのゴリゴリしたマルチメディア管理をやりたいなら、大人しく「+」シリーズ（DS224+など）のような、Intel製などのつよつよCPUを積んだ上位モデルを買えという、公式からの無言の圧力を身を以て思い知らされた検証結果となりました。

まとめ

　テレビ録画の格納先やファイルサーバーとしての基本機能（物理置き場）なら、あたしのDS220jは今でも現役で十分にいい仕事をしてくれます。
身の丈に合わない最新のAI機能を入れてシバき倒すのはやめて、これからも静かに我が家のインフラの土台を支えてもらうことにします。

現場からは以上です。明日からの週明けの仕事（月曜日）、現実逃避せずにはま寿司の混雑を思い出して頑張りましょう……！