CO2 監視復活させた

去年の秋ぐらいに raspberry pi が不調になり、そのタイミングから自室のco2モニタリングが動かなくなっていた。

当初いくつか試したところハードウェアのトラブルが疑わしいように感じた。ので、新しく CO2mini を購入し直すことにしたがメーカー欠品ということでこの春まで手に入らなかった*1。

時は流れ、春先に新品が届いたのだがAmazonの袋に入った状態で半年ほど寝かしていたところ、昨晩急にやる気が発生したのでやっと開封した。こういうやる気任せなのがダメなんだよな、多分、わかっちゃいるんだけど、、、。

で、新しいデバイスでもやっぱり動かない。これはソフトが怪しいということで既存の Python モジュールで動かしてみると普通に値が読み取れる。

どうやら自作のソフトがダメだったっぽい。不思議なこともある*2。新しいハードウェアでは暗号化が解かれているらしいけど、当時はハードも変えてないわけだし。

ともかくハードの問題じゃなさそうだし、もし新しいハードが非暗号化版だとすると逆に古いコードは動かないことがわかったので https://github.com/heinemml/CO2Meter/ で mackerel の拡張を作り直した。

udev ルールは上記のリポジトリの README をそのまま利用させてもらった。作り直した拡張は以下の通り。

実行時は以下のような形で co2mini の置き場所とデバイスがマウントされているパスを指定する。

./mackerel-plugin-co2mini --local bed-side --path /dev/co2mini0

*1:新型コロナウィルスの流行に伴い、店舗等での換気レベルの確認用途でかなりの需要が発生したのだと思われる

*2:golang で書いたので実行ファイルはバイナリで、再ビルド等はしてないので壊れる余地がほとんどない

2020-05-09

GitHub Actions で Google App Engine Project の自動デプロイを構成する

サービスアカウントのロール付与で試行錯誤が必要だったのでメモです。ロールで権限付与していくならこれが一番コンパクトだと思う。

ServiceAccount の作成
1. サービスアカウントへのロール設定
  - App Enging デプロイ担当者 or App Engine サービス管理者
    - デプロイだけする場合はプロイ担当者、トラフィックの切り替えまで行う場合はサービス管理者を付与する
  - Cloud Build サービスアカウント *1
2. デプロイに使われるCloud Storageバケットへの権限設定
  - <project_id>.staging.appspot.com のストレージのオブジェクト管理者として 1. で作成した ServiceAccount を設定する
.github/workflows/actions.yml の定義
- GitHub - GoogleCloudPlatform/github-actions: A collection of GitHub Actions for interfacing with Google Cloud Platform.にサンプルがあるのでみながらよしなにする

*1:1年ぐらい前に go のプロジェクトで同じことやったときは不要だった気がする、今回は node だから使ってるのかな?

2020-02-17

アジャイルレトロスペクティブズ強いチームを育てる「ふりかえり」の手引きを読んだ

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

作者:Esther Derby,Diana Larsen
出版社/メーカー: オーム社
発売日: 2007/09/01
メディア: 単行本

読んだ。社会人になって5年ぐらい、大体のチームでふりかえりはやってきたけど、ちゃんと勉強したこと無いことに気がついて正月ぐらいからちまちま読んでいた。

ふりかえりの効果について整理できたことや、ファシリテータの役割や進行時の注意点について学べたこと、イテレーションごとのふりかえりとプロジェクトのふりかえりの違い、みたいなのを確認できてよかった。

また、3章にあった「あなたの管理」っていう節はいいこと書いてあったので定期的に読みたい。

それ以降はアクティビティカタログみたいな感じで、ふりかえりのフェーズごとにアクティビティが紹介されている。ここはやってみたいとわからないことが多そうだったのであんまり理解できなかった。

付録のCにこの本で紹介されているアクティビティを俯瞰できる表があるので、ここをみながら気になるアクティビティについて読んで見る、ぐらいの距離感が良さそう。

ところでこの本は読むにあたってなぜかめちゃくちゃ目が滑って大変だった。文章と僕の相性の他、過去の失敗したふりかえりや計画が思い出されて意識を奪われる感じ。

そこで Scrapbox でガツガツメモを取りながら読むというアプローチをとった。

f:id:side_tana:20200217095803p:plain — 様子

章を進むごとにページを作り、メモを取りながら読み進めて、最後にメモのまとめを上記の様にまとめて終わり、というスタイル。4章以降はカタログっぽかったのでやめたけど、メモを取りながら読むのはハイカロリーな反面、うまく頭に入らない内容でも読み進めることができてよかった。

2020-02-02

部屋のネットワークの様子を見ることにした

暮らしを豊かにする

どうも最近家のネットワークの具合が悪いので、 ping の様子をみることにした。 kazeburo さんの mackerel-plugin-pingin を使わせてもらった。

github.com

あとはカスタマイズしたグラフを表示する - Mackerel ヘルプで、グラフを作る。書いた式はこんな感じ。

alias(
  divide(host(3Nkp8cgs2mU, custom.pinging._rtt_count.error), 
    sum(host(3Nkp8cgs2mU, custom.pinging._rtt_count.success))),
  'packet loss'
)

出てくるグラフはこんな感じになる。

f:id:side_tana:20200202150546p:plain

パケロスの様子をじっくり観察したことなくて、調子悪いなとおもったときに ping 打つ程度だったのでよくわからない。監視に使ってるデバイスが wifi っていうのも関係あるかな、とおもったけど、それでいうと家の中の端末はほぼ wifi なので同じ条件ということになる（問題の切り分けを考えると有線でも測定したいな）。

2019-12-22

開発合宿で AWS メディアサービスをつかってVOD動画配信の仕組みを作ったときの話

この記事ははてなエンジニア Advent Calendar 21日目の記事です。昨日は id:papix さんでした。

この記事では、はてなの開発合宿で AWS メディアサービスをつかってVOD動画配信の仕組みを作ったときの様子を紹介します。

初期のアーキテクチャ案

合宿初日にチームメンバーの id:masawada と id:hokkai7go とAWSのドキュメントを眺め、以下のようなアーキテクチャを目指すことにしました。

f:id:side_tana:20191221101655p:plain

配信までの流れは以下のとおりです。

- アップロード用のS3バケットに動画を保存する
- ファイル保存イベントをトリガとして MediaConvert に変換 job を投入する
- HLS フォーマットの配信データを配信準備用S3バケットに保存する
- m3u8 ファイルの作成をトリガに MediaPackage にアセットを登録する
- MediaPackage で HLS / MPEG-DASH で配信するためのエンドポイントを公開する
- 再生準備が整うと CloudWatch Event に <code>VodAssetPlayable</code> イベントが通知されるので、これをトリガに lambda を起動して配信アプリケーションにエンドポイントを登録する

また、 MediaPackage の前段に CloudFront を配置し、m3u8 ファイルの配信には短命な署名済みURLを用いることにしました。

実際に動かしてわかったこと

上記の構成は合宿初日の夜にはほぼ出来上がったのですが、MediaPackage で VOD 配信をする場合に、エンドポイントのアクセスコントロールができないことがわかりました*1

そこで、MediaPackage で行っていた処理をすべて MediaConvert で行うように変更しました。

最終的なアーキテクチャ

f:id:side_tana:20191221103608p:plain

- アップロード用のS3バケットに動画を保存する
- ファイル保存イベントをトリガとして MediaConvert に変換 job を投入する
- HLS / MPEG-DASHフォーマットの配信データを配信準備用S3バケットに保存する
- m3u8 / mpd ファイルの作成をトリガに配信アプリケーションにObjectKey を通知する
- s3 をバックエンドにした CloudFront を構成し、署名済み URL で配信する

今後の課題

このようにしてs3へのアップロードから配信まで自動化されたVOD配信システムを実現することができました。m3u8 / mpd の配信時には短命な署名済み URL を用いているので、閲覧権限のないユーザに URL を共有された場合でもすぐに URL が無効となるため不正な閲覧も保護できます。

一方で課題も有り、 m3u8 / mpd の中身について思いを馳せますと、これらには署名されていない状態のパスが保管されているため、現状では完全にURLが保護されている状態では有りません。

このため、コンテンツ保護については課題がある状態です。これについては m3u8/mpd の動的生成や、SPEKE での DRM などによって対応を進める必要があるでしょう。

感想

自宅のサーバで動画を管理していたころは ffmpeg の設定だけでも苦労したものですが、AWS Media サービスを利用することで手軽に HLS /MPEG-DASH での動画配信を実現でき、感動しました。また、DRMについてもソリューションプロバイダとの連携であれば比較的容易に実現できそうで、機会があれば触れてみたいです。

明日は id:nabe1216 さんです！

*1:これは今考えるとたしかに難しいですね。

暮らしの技術

暮らしを豊かにする技術や、特に暮らしを豊かにしない技術があります