はじめに
kazu_iroiroと申します！
1年以上ぶりにQiitaへ戻ってきました。
大学生になって、これまで触れてこなかった言語を学んだり、趣味だった電子工作にお金をつぎ込めるようになったりと、日々を満喫しています。
今年の4月からは2年生になり、そろそろアウトプットをしたいなと感じていたので、記事投稿キャンペーンを機に、アウトプットの回数を増やしていこうと思います。
この記事では、バックエンドにClickHouse + Cloudflare Workers + Honoを、フロントエンドにDocker + nfcpy + PaSoRiを利用した、合宿参加者の状況把握システムについて紹介します！
この記事は Qiita Tech Festa Sprint 記事投稿キャンペーン 『「AI時代のデータベース、何が変わる？」について語ろう！』の投稿記事です
経緯
私は大学でデジタル創作系の団体に所属しています。
この団体で今年度の合宿担当をしているのですが、この夏の合宿参加者数が80人規模となる見込みで、大変不安に思っています。
この人数を目視でカウントすることは非現実的なので、今部員がどこにいるのか、状況をリアルタイムで確認できたらいいよねということになり、開発を始めました。
リアルタイム把握系のプロダクトは、プライバシーと利便性の間でバランスを取るのが難しかったり、誰かが操作を忘れたりして、破綻しがちです
できるだけノンストレス、かつプライバシーに配慮した形として、所属している全部員が持っている「学生証」に目をつけました。
「改札」を宿泊先の各所に設け、部員が通行する際に「学生証」で認証してもらえば、リアルタイムでの位置確認を実現できそうです。
仕様の検討
学生証について
弊学の学生証はFeliCaをベースとしており、これをPaSoRiにかざすことで学籍番号とIDmを取得できます。
FeliCaなら読み取り速度も速く、改札として運用するのに最適です。
また、部員のみが使う前提のため、IDm（各FeliCaカードに固有のID）を利用したシステムでもセキュリティ上の心配はありません。
利便性向上のため、部員が持っている任意のFeliCaを学生証と紐づける仕組みを導入し、任意のFeliCaをかざしても反応させることとしました。
（自分がモバイルSuicaで通りたかっただけ）
ネットワーク環境について
合宿先では安定したインターネット環境が手に入りません。
毎年、複数の通信回線を束ねた冗長化回線を構築していますが、どうしてもレイテンシが大きくなってしまったり、接続が途切れてしまうことがあります。
そんな時でもログを保持できるような仕組みが必要です。
パソコンの台数について
デジタル創作サークルのため、もちろん部員から募ることでパソコンは沢山手に入ります。
しかし改札用に「放置してよいパソコン」というのは少なく、できる限りクライアントになる端末数は削減したいです。
したがって、2台のPaSoRiを1台のパソコンで管理することを要件としました。
これにより、「改札」を出るとき、入るときで別々のPaSoRiに学生証をタッチすることができるので、通過時の利便性を向上できます。
技術検討と失敗
最終的な構成に至るまでに、いくつかの試作を行ったので紹介します。
クライアント側
- Go (github.com/ebfe/scard)
ライブラリの仕様上モバイルSuicaの読み取りができなかった - Python (nfcpy)
Windowsだとドライバーの入れ替えが必要だった - .NET (felicalib)
ライブラリの仕様上、複数台のPaSoRiを同時に扱えなかった
サーバー側
- GAS + Googleスプレッドシート
認証APIとして動かすにはレスポンスが遅く、スプレッドシート側の情報表示も遅い - Cloudflare Workers (Hono)
認証APIとしては優秀だが、Workersに重たいDB処理をさせるわけにいかない（CPUの実行時間に制限がある）ので、単体では使いにくい
最終的に
どうしようか悩んでいたところで、ちょうどQiitaの記事投稿キャンペーンからClickHouseを知り、Cloudflare Workersと組み合わせることにしました。
Windowsでnfcpyを使う際にドライバの入れ替えが必要な問題については、usbipd-winを通してWSL上のDockerコンテナにPaSoRiをアタッチしてあげることで解決できることが分かりました。
ClickHouseって？
列でデータを管理する、オープンソースのデータベースです。
PostgreSQLなどは、行単位でデータを管理するので、データの持ち方が異なります。
列ごとにデータを処理できるため、分析に向いているらしく、今回のような蓄積したログを管理するのにも向いていそうです。
逆に、Cloudflare D1のような、Key-Value型のDBが得意とする「認証」には向いてないわけですね。
だからこそ、Cloudflare Workers と ClickHouseの組み合わせがちょうど良さそうです。
実際に作ってみた
構成
以下のような構成で作ってみました。
【Reader: 検知部】
Windows + usbipd-win + WSL2 + Docker + nfcpy + PaSoRi RC-S380
【認証】
Cloudflare Workers + Hono + Cloudflare D1
【DB】
ClickHouse Cloud
【Viewer: Webダッシュボード】
Cloudflare Workers + Hono + Cloudflare Pages
の組み合わせです。
他の記事で楽だと言われていたので、ClickHouseはセルフホストではなく、Cloud版の無料トライアルで試してみました。
ClickHouse Cloudの登録から認証情報の取得まで
登録手順
-
トップページにアクセス
-
アカウント登録
-
メール認証をして
-
ログイン
-
ダッシュボード画面が開けました
-
コストが安そうなのでGCPを選択
-
作成したサービスのダッシュボードを確認できました
-
DBの構造を指定してあげて
-
認証情報をコピーして取得します
この認証情報を、Cloudflare Workersに登録してあげれば、準備完了です。
利用規約がシンプルで読みやすく、簡単に登録できて便利でした。
ランニングコストの観点から、セルフホスト版のClickHouseも試してみたいです。
クラウド系のサービスを展開しつつも、オープンソースかつ自前の環境ですぐ動かせる、というのは珍しく、大変ありがたいです。
動いた！！
パソコンに2台のPaSoRiを繋いだ状態で、実際にWebダッシュボードがリアルタイムに更新されることを確認できました。
感想
GAS + Googleスプレッドシートでバックエンドを構成していた時よりも、圧倒的に速くなって感動しました。
検討していた仕様も満たせたので、大変満足です。
ClickHouse側の更新がとても速いため、Webダッシュボードのデータ取得間隔が、表示の更新頻度に大きく影響を与えるようになってしまいました。
今後の展望
実運用を始めると、ClickHouseに蓄積されるデータ量も膨大になると思うので、これからレスポンス速度がどうなるのかが楽しみです。
合宿まではもう少し時間があるので、Cloudflare Workersの改修をして、少しでもレイテンシが短くなるようにしようと思います。
ダッシュボードのUI・UX向上もしていきたいです。
最後までお読みいただきありがとうございました！
参考文献