サービスアカウントのロール付与で試行錯誤が必要だったのでメモです。ロールで権限付与していくならこれが一番コンパクトだと思う。
- ServiceAccount の作成
.github/workflows/actions.yml
の定義
*1:1年ぐらい前に go のプロジェクトで同じことやったときは不要だった気がする、今回は node だから使ってるのかな?
サービスアカウントのロール付与で試行錯誤が必要だったのでメモです。ロールで権限付与していくならこれが一番コンパクトだと思う。
.github/workflows/actions.yml
の定義
*1:1年ぐらい前に go のプロジェクトで同じことやったときは不要だった気がする、今回は node だから使ってるのかな?
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
読んだ。社会人になって5年ぐらい、大体のチームでふりかえりはやってきたけど、ちゃんと勉強したこと無いことに気がついて正月ぐらいからちまちま読んでいた。
ふりかえりの効果について整理できたことや、ファシリテータの役割や進行時の注意点について学べたこと、イテレーションごとのふりかえりとプロジェクトのふりかえりの違い、みたいなのを確認できてよかった。
また、3章にあった「あなたの管理」っていう節はいいこと書いてあったので定期的に読みたい。
それ以降はアクティビティカタログみたいな感じで、ふりかえりのフェーズごとにアクティビティが紹介されている。ここはやってみたいとわからないことが多そうだったのであんまり理解できなかった。
付録のCにこの本で紹介されているアクティビティを俯瞰できる表があるので、ここをみながら気になるアクティビティについて読んで見る、ぐらいの距離感が良さそう。
ところでこの本は読むにあたってなぜかめちゃくちゃ目が滑って大変だった。文章と僕の相性の他、過去の失敗したふりかえりや計画が思い出されて意識を奪われる感じ。
そこで Scrapbox でガツガツメモを取りながら読むというアプローチをとった。
章を進むごとにページを作り、メモを取りながら読み進めて、最後にメモのまとめを上記の様にまとめて終わり、というスタイル。4章以降はカタログっぽかったのでやめたけど、メモを取りながら読むのはハイカロリーな反面、うまく頭に入らない内容でも読み進めることができてよかった。
どうも最近家のネットワークの具合が悪いので、 ping の様子をみることにした。 kazeburo さんの mackerel-plugin-pingin を使わせてもらった。
あとはカスタマイズしたグラフを表示する - Mackerel ヘルプで、グラフを作る。書いた式はこんな感じ。
alias( divide(host(3Nkp8cgs2mU, custom.pinging._rtt_count.error), sum(host(3Nkp8cgs2mU, custom.pinging._rtt_count.success))), 'packet loss' )
出てくるグラフはこんな感じになる。
パケロスの様子をじっくり観察したことなくて、調子悪いなとおもったときに ping 打つ程度だったのでよくわからない。監視に使ってるデバイスが wifi っていうのも関係あるかな、とおもったけど、それでいうと家の中の端末はほぼ wifi なので同じ条件ということになる(問題の切り分けを考えると有線でも測定したいな)。
この記事は はてなエンジニア Advent Calendar 21日目の記事です。昨日は id:papix さんでした。
この記事では、はてなの開発合宿で AWS メディアサービスをつかってVOD動画配信の仕組みを作ったときの様子を紹介します。
合宿初日にチームメンバーの id:masawada と
id:hokkai7go とAWSのドキュメントを眺め、以下のようなアーキテクチャを目指すことにしました。
配信までの流れは以下のとおりです。
- アップロード用の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 で行うように変更しました。
- アップロード用の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:これは今考えるとたしかに難しいですね。
こんにちは、私は id:side_tana。この記事は Mackerel Advent Calendar 17 日目の記事です。昨日は koudenpa さんでした。
この記事では部屋にモニタリングを導入するまでの経緯とその結果をご紹介します。
私は春に引っ越したのですが、引っ越してからしばらく睡眠の質が低い日々を過ごしていました。1週間ほどその状態で過ごしたとき、夜間に寝室のCO2濃度が高まって、それが悪影響となっているのではないか、とひらめきました。
その日の晩に寝室のドアを開けて寝たところ、寝苦しさについてはかなり改善されました。おそらくこれが原因だったのではないか、と思っています。
ともあれ私は睡眠の質を取り戻しました。めでたしめでたし。
果たして本当にそうでしょうか? 私は専門家ではないので睡眠の質とCO2の関係性はわかりません。しかし本当にCO2が変化したのかは計測できるはずです。
まずは現時点での部屋の可観測性を確認します。私の部屋にはすでに Nature Remo があります。Nature Remo はスマートリモコンと呼ばれる製品です。リモコンを登録したり、学習させることでスマートフォンから家電を操作することができます。
Nature Remo には「ルール」という機能があり、例えば「部屋が暗くなったら照明をオン」「室温が15度を下回ったら暖房をオン」といったルールを設定することで、家電の操作を自動化することができます。そしてそのためのセンサと、APIがあります。これを使わない手はありません。
幸い Mackerel エージェント向けのプラグインを papix さんが公開されています。
こうして「室温」「明るさ」「湿度」については Mackerel 上から確認することができるようになりました。*1
しかし私が今測りたいのは CO2 濃度です。入門監視にも「ツールに依存しても監視の仕組みはよくならない」といったエピソードが最初に有りました。また、「自分でツールをつくらなければならない時もある」とも書かれています。
ということで CO2 の濃度を測りましょう。今回は CO2mini という製品を使います。実はこの製品はUSBで接続すると HID デバイスとして認識され、センサー情報を取得できることが知られています。
http://r-kurain.hatenablog.com/entry/2016/01/26/164648
https://dounokouno.com/2018/05/27/raspberry-pi-co2-mini/
https://hackaday.io/project/5301-reverse-engineering-a-low-cost-usb-co-monitor
今回はこの製品を用い、Goでセンサ情報を取得する Mackerel Agent 向けのプラグインを実装しました。こうして私の部屋は CO2 濃度に対する可観測性を獲得したのです。
$ ./bin/mackerel-plugin-co2mini --local room --path /dev/co2mini0 CO2Mini.co2ppm.room 484 1576503848 CO2Mini.temperature.room 15.100000 1576503848
ちなみにこんな動きをします。CO2 の値が低いのは、今棒鱈煮をつくっており、換気のため窓を開けているからです。
なおホストの端末には Raspberry Pi を使っています。Mackerel Advent Calendar 3日目でhnw さんが紹介されているようにインストールが簡単になりました。助かりますね。
実際に寝室のドアを締めて寝てみると Mackerel 上で以下のようなグラフを確認できました。
一方で、寝室のドアを開けっ放しにして寝ると次のようになりました。
寝室のドアを閉めて寝ると CO2 濃度が高まる、という当初の仮説は正しかったようです!*2
監視、というとアラートとは切っても来れない関係があります。しかし今回のケースに関しては「安眠のための監視によって安眠を阻害される」といった結果になるのが目に見えているので設定しませんでした。
確かにこれがプロダクションサービスなら「睡眠中にCO2 濃度が一定の基準を超えた場合にアラートを発報する」モニタリングルールを設定します。そしてオンコールの担当者が私の家にやってきて寝室のドアを開け、去っていくでしょう。。。*3
以上、Mackerel Advent Calendar 17日目の記事でした。明日は cm-watanabeseigo さんです。