GCPで室温の監視確認ツールを作った
はじめに
みなさん、ギターみたいな弦楽器を持ってたりしますか?
私は持ってます(自慢)
ギターみたいな木製の弦楽器をお持ちの皆様はご存知かもしれませんが、
弦楽器は室温と湿度に関してデリケート
だったりします。
そのため、うまくエアコンで室温とかをコントロールするのですが、 エアコンの電気代もばかにならないので、室温をモニタリングできるツールを作りました。
つくったものの概要
nature remoを使って室温を記録し、それをいつでも確認できるようなWebアプリケーションです。 リアルタイム性は低いため、現在の室温を取得するには不向きですが、気温の遷移が確認できるので
ちょっとエアコンつけ忘れちゃったけど室温大丈夫かな?
とかが確認できます。
どういうふうに動かしてるの?
室温の取得と保存
上の図の中だと上半分が室温の取得と保存に利用されます。
Cloud SchedulerがCronの役割をして3時間ごとにCloud Pub/Subを発火します。 Cloud Pub/Subを経由してCloud Functionsが発火し、Cloud Functions内でジョブが実行されます。
Cloud Functions内では
- nature remoのapiを叩いて室温を取得
- 室温のデータをCloud SQLに保存
が行われます。
Cloud Functionsの実装は、そこそこ軽量で速度も出るのと自分の勉強のためにGo言語で書いてます。
室温閲覧を行うWebアプリケーション
Cloud SQL上に保存された室温の情報を閲覧するアプリケーションはBlitz.jsで実装しています。 Blitz.jsは、公式で
"Zero-API" Data Layer — Built on Next.js — Inspired by Ruby on Rails
と謳われているように、Next.jsをベースにしつつ、データ永続層やBE APIといった機能も追加された Ruby on Railsを彷彿させるようなフルスタックフレームワークです。
Blitz.jsを用いることで、
- リッチなUIをReactで簡潔に書ける
- BE側の実装自体も低コストで行える
- FE/BEと別々で用意・運用が必要なくなる
といった利点を享受できます。
特に、小規模でBEのAPIなどがないけどリッチなUIも必要なケースでBlitz.jsが便利かと思います。
最初は、
- GoでBEのAPIを生やし、React/Next.jsで書いたFEから呼び出す
- GoでBEだけでなくテンプレートエンジン + jsのFEも返す
等を検討していましたがBlitz.jsで実装して正解でした。
(少しBlitz.js周りの知識とかもついたのですがそちらは別でブログにしようと思います)
さて、Blitz.jsでアプリケーション自体を実装しましたが、 実行用のContainer Imageを作成してCloud Runで動かしています。 (これに関してはこれ以上いうことはないですかね。)
開発そのものを支える技術
今回、デプロイ周りを楽にするため、GitHub Actionsを使ってデプロイしました。
どちらとも、main
ブランチに対してcommitが走った場合、
デプロイがされるというシンプルな仕組みです。
ただ、Cloud Runへのデプロイに関してはちょっと特殊で、
- Cloud Registryに対してDocker Containerをpush
- Cloud runに対して上記container imageを使ってdeploy
という手順になってます。
これにより、とりあえずコードを書きさえすればそれが反映されるのでオペレーションコストは 低いです。
(とはいえ、デプロイの設定とか諸々でゴミみたいなコミットとかが入っているので少し恥ずかしいです。)
最後に
個人的にクラウドプラットフォーム自体をしっかり使ったのが3年前で、それ移行ずっとFEで完結するものを作ることが多い状態でした。 それでもなんとか利用できたので、情報等がしっかりまとまってたり、公式のドキュメントも丁寧でGCPは使いやすいですね。 Blitz.jsに関してはまた別途記事にしたいと思いますmm