続・気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話

まず、北海道胆振東部地震で被災された方にお見舞い申し上げます。
今回の地震は熊本地震と同様の最大震度7が観測された為、自分自身が2年前に体験した熊本地震の時の様子を思い出しながら、今必要な情報は何か？を考えて仕事をしていました。

それにしても、まさか札幌にお天気カメラを設置しに行った3日後に大地震が発生するとは思ってませんでしたが...

（中の人）
札幌のみなさーん。
NERVが独自に設置を進めているお天気カメラですが、札幌・中央区にも設置しました。きょうはあいにく曇っていますね…。画像もどんよりしています(´・ω・｀)
2枚目の画像は装置の収容ケースです。エヴァ感をお楽しみくださいｗ pic.twitter.com/9fsxWiVsEW

— 特務機関NERV (@UN_NERV) September 3, 2018

設置の翌日、台風が北上してくる中、15時の便にフライトを振り替えて新千歳空港から飛び立ち、17時ごろに羽田についたら以降の便が全便欠航していた＆翌日(5日)も台風による悪天候でダイヤが乱れていたので、振り替えていなければ人生で2度目の震度7クラス地震を体験するかもしれないところでした...

さて、今回は、気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話 の続きのお話です。
※これは防災情報デザインと配信に関する個人的な研究の一環として私費でやっている物の話です。

あれから半年程度運用を続けてきましたが、全体の運用に毎月1500円〜1700円の費用が掛かっていました。(それでも十分に安い)

この「全体」というのは、気象庁XML受信のためのサブスクライバ＆閲覧のためのビューアをホストしているAppEngine、XMLやJSON、画像保存のためのStorage、QUAKE.ONEをホストしているFirebase、その他内部的な処理に使っているCloud Functions (15個の関数)、Pub/Sub (5個のトピック)、JMAXMLのメタデータや地震情報、気象警報・注意報のステートを保存しているDatastoreを含みます。

例えば、2018年6月に掛かった実際の費用はこんな感じ。

全体の費用として一番大きいのが、Compute Engine g1-smallインスタンスx1で毎月2000円から継続利用の割引で約1400円と実に全体の80%以上。
このインスタンスは、Twitterへの投稿やPushbulletでのプッシュ通知の際に添付される震源・震度マップ画像を、headless Chrome&PuppeteerでレンダリングしてCloud Storageに保存するためにだけに使用されているものです。
f1-microインスタンスでは、CPUバーストが効いた状態でレンダリング(960x540)に10秒以上掛かる上に、地震が頻発すると何度目かのレンダリングでCPUバーストが効かずに実行がタイムアウトしてしまうという残念なことが発生したため、g1-smallインスタンスで運用していました。

ところが、2018年8月のアップデートで、Cloud FunctionsにてNode.js 8系が利用できるようになると共にheadless Chromeが利用可能であることがアナウンスされました。

Introducing headless Chrome support in Cloud Functions and App Engine | Google Cloud Blog

これに伴って、構成を以下のように変更。

(クリックで拡大してご覧ください)

大きな変更点は以下の通りです。

1. 画像のレンダリングをCloud Functionsで実行
2. 画像レンダリング用のg1-smallインスタンスを廃止
3. WebSocket配信サーバをConoHaからf1-microインスタンスに変更

これにて、毎月の利用額がCloud Storageのオペレーションとデータの保管に掛かる費用のみとなり、200円以下となりました。
(f1-microインスタンス1台はAlways-freeなので0円)

Cloud Functionsでのレンダリングは、asia-northeast1のメモリ2GBで最短3900ミリ秒(ページの読み込みのために入れたwait 3000ミリ秒を含む)、最大でも7秒程度とブラウザを利用した画像の生成(かつ無料枠範囲内)の方法としては優秀。
もちろん、スピードが重視されるような防災情報配信用途としてはとてもとても遅い(ゲヒルンで製作・運用している描画エンジンはフルHD1枚200ミリ秒程度)ので、あくまで実験・実証としての利用、またはスピードが求められない場面での利用に限られるのですが...。

ひとまず、ConoHaに全てを載せていた時の価格(毎月1000円程度)と比較して1/5くらいになったので、クラウドは上手く使えば安くなりますよ事例として記しておきます。
ただし、これはアクセス数に大きく依存するので、今くらいの利用者数であれば200円で済むものが、利用者が数倍になればGCPに支払う費用も数倍、数十倍以上になり得るということです。
あくまで個人的な実験・試行というところでの運用を続けているので、流石にそういう状況になったら続けることはできませんが、こういった複数の要素を使ったサービスを数十円、数百円のレベルから始めることが出来るのがGCPやAWS、Azureといったクラウドのメリットということでしょう。

HDピコレーザープロジェクター 自作キットを組み立ててみた

つい先日、Twitterのタイムラインを眺めていたら、こんなものを発見。

【新商品】HD ピコ レーザー プロジェクター 自作キット for Pi [HD301D1]☆税込￥15,120☆「持ち運べる大画面」として注目のピコプロジェクターをあなたのラズパイプロジェクトにも！レーザーだからフォーカスフリーで熱くない！MEMSスキャナーだから超小型で低消費電力！ https://t.co/n6YSxevpWf pic.twitter.com/rPzx273gYj

— KSY@Raspberry Pi (@KSY_RasPi_Shop) July 11, 2018

これは試してみるしかない、と1台買ったので組み立ててみました。
ちなみに、お値段は購入時点で税込15,120円。限定数販売後は値上げするようです。

届いた中身はこんな感じ（写真には写ってませんが、レーザー出力部とHDMI信号を受ける基板を繋ぐフレキも入っています）

ひとまず、ベースとなるアルミプレートに基板とレーザー出力部を仮置きしてみる。
基板はそのまま「1」の番号が振ってあるネジで5箇所を固定。

レーザー出力部に付属のフレキを「TOP」の刻印がある向きで接続。
反対側を基板に繋ぎつつ、固定場所に位置合わせします。

レーザー出力部を「1」の番号が振ってあるネジで3箇所 固定。

トップのアクリルパネルを固定するためのシャフト(3番の部品)を、アルミプレートの裏側から「2」の番号が振ってあるネジで5箇所 固定。

最後に、アクリルパネルの保護紙を剥がして、「4」の番号が振ってあるネジで5箇所 固定。

なかなかコンパクトで、サイズはiPod Classicと同じくらい、重さは87gでした。

同じくレーザー走査型のプロジェクターで、SONYが海外にて販売しているMP-CL1Aとサイズ比較。
MP-CL1Aは個人輸入で1台5万円くらいだった記憶...

少し明るい環境だったので、はっきりとした比較にはなりませんが、レーザークラス3RのMP-CL1A(左)と比較して、HDピコレーザープロジェクター(右)はクラス1にしては健闘していると感じました。

ちなみに、MacとHDMIで接続したところ、YPbPrの信号には対応してないようで、画面全体がピンク色に...
手元にあるRaspberry PiやPINE64では問題なく表示されました。

次は真っ暗な環境で試してみようと思います。（続報はTwitterに書くかも

追記：真っ暗な部屋で映してみました。

投影先は天井、距離は2mくらいで、正確に測ってないけど50インチくらいはあるはず。
小さい文字はボケるけど、動画を見る分には悪くないかなというところです。

iPod Classicに大容量ストレージとバッテリーを搭載してみた

「ぼくのかんがえたさいきょうのiPod Classic」を作ります😎 pic.twitter.com/Y29WpHJKan

— けーいち (@9SQ) July 9, 2018

というわけで、長年考えていた「最強のiPod Classicを作りたい」という目標を実行してみたお話です。

改造に必要なiPod Classic(最終世代)の調達
ヤフオクやメルカリ等で電池消耗はあるけど外観の状態が良さそうな物を4つ(シルバーとブラック2個ずつ)購入、うち2個はApple Storeにてバッテリー交換して保管用に、残り2つのうち1個を比較用に未改造状態、もう1個を改造用として用意しました。

iPod Classic ... 1個 約1万円

ストレージ用の変換基板
iPod 第5世代やiPod Classic(6世代以降)に対応した、microSDカードが４枚挿しできる基板を購入。
https://www.iflash.xyz/store/iflash-quad/

iFlash Quad ...  42ドル = 約5,000円

ストレージ用のSDカード
ここ1年くらい大容量MicroSDカードの値動きを追っていて、200GBが1枚6000円を切ったら実行しようと思っていて...
ついに、先日、テクノハウス東映でSanDisk Ultraの200GBが6000円を切ったため4枚まとめ買い。

SanDisk Ultra microSD 200GB ... 1枚5,880円 x4 =23,520円

256GBを4枚挿しで1TBというのも憧れるけど、200GBと比較して256GBはまだまだ高いので、次やる時の楽しみにとっておきます。

「800GB」刻印のバックパネル (スリム仕様)
せっかく大容量化するので、刻印も実際の容量と同じ 800GB の物を購入。
あと、フロントもバックパネルも金属製のClassicは開ける作業が非常に難しく、歪みや傷が入ること必至なので元のバックパネルは使わないという前提です。
Aliexpressにて購入。

バックパネル ... 950円 + 送料 200円くらい = 1,150円

1950mAhのバッテリー
iFlash QuadとmicroSDの組み合わせでは元のHDDと比較してかなりスリム化するので、空きスペースに大容量バッテリーが入ります。
eBayでフレキが互換の交換用バッテリーを購入。

バッテリー ... 14.99ドル + 送料 350円くらい = 2,050円

これでパーツは一通り揃ったので分解作業開始...

想定どおり非常に開けづらいので、開腹作業には1時間くらい要しました...
今回はフロント側に傷を入れないようにし、バックパネルはどうなっても良いというスタンスで作業をしたので、バックパネルは縁が歪んで再度の取り付けは厳しい状態に。
また、クリックホイール操作時にクリック音を鳴らすための圧電スピーカーがイヤホンジャック下部のフレキに付いていましたが脱落... 慌てて追加でこのフレキ部品を発注するも、結局使わないことに（後述）

HDDを取り外して、iFlash QuadにmicroSDカードを4枚セット、HDDと同じ部分に置いてみる。
この状態だと元のHDDと比べて非常に薄いので、スッカスカです。
一応、iFlashにはバッテリーを増量せずにデフォルトのバッテリーで筐体を閉じるために、スペーサーとなる黒いスポンジも付いています。

次にバッテリーの接続。
左は元々の550mAhバッテリー、右が1950mAhバッテリーです。

1950mAhバッテリーを入れるには少々フレームに加工が必要で、元のHDDを固定するために付いている突起を削る必要あり。

こうして完成したものを閉めようとすると...
クリック音用のスピーカーが絶妙にバッテリーと干渉して液晶画面側が僅かに浮いてしまいます。
ということで結局、分解時にスピーカーが脱落してしまったフレキを再利用することに...

iPodをMacと接続し、iTunesからファームウェアを復元、実際に使用できる容量は730GB程度のiPod Classicが完成。

試しに90GBくらいの音楽ライブラリを同期して、LossLess音源を連続再生することでバッテリー持続時間を計測中...
48時間程度経過した段階で、バッテリー表示上は7割くらい残っているようです。

掛かった費用は4万5000円くらいでしょうか。
最近流行りのハイレゾ対応プレイヤーだと物によるけど5万円以上したりするので、ハイレゾとまでは行かないものの48kHz/16bitまで再生できて大容量で長時間再生できるプレイヤーとしては割とお得なのでは？と思ったり...

iTunesで10年以上続く音楽ライブラリを管理しているので、これからもiPod Classicには活躍してもらうことにします。

追記：重さの比較してみました。

シルバーが今回改造したiPod Classicで123g、ブラックが未改造で135gでした。
体感としては、僅かに軽くなったかなというくらい。
バッテリーが550mAhのデフォルトの物だと凄く軽く感じるけど、逆にオモチャっぽさを感じたので、ある程度の重さがある方が質感アップに寄与する模様。

気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話

そろそろ何かアウトプットしておかないとNo Activityマンになってしまうと思いつつも色々やることは山積みで筆の捗らない今日この頃、みなさんいかがお過ごしでしょうか。

さて、2015年12月にEVI 地震火山詳報を公開してから約2年と3ヶ月(その前身の桜島詳報から数えると3年7ヶ月)が経過しました。
実は、2017年10月頃のConoHaの障害によりサブスクライバが長時間止まってしまい、気象庁のPuSH配信から外されたため同月よりEVIのサービスが停止しておりました。
この際、本業(ゲヒルン＝UN_NERVへ作画提供)でも震源・震度地図の作画エンジンを作っているので完全にサービスを畳んでしまおうかとも思ったのですが...
振り返って周りを見てみれば、インタラクティブな震源・震度マップに挑戦している方が意外と少なく、作画方法も本業の仕組みとは全く異なるので 防災情報デザインに関する異なるアプローチの研究 ということで緩く継続してみようと思い立った訳です。

#防災情報デザイン、特に地震に関するものに関しては、様々な方が主にUN_NERVで提供されている地図デザインをパクって何度も何度も車輪の再発明をされていますが、みなさん少しは配色を変えてオリジナリティを出したり、「俺ならこうする！」といった伝え方の工夫を取り込んでみてはいかがでしょうか...? 芸が無さすぎて全くつまらんです。

EVI 地震火山詳報のサービスと後ろ側については、以前書いた記事をご覧ください。

地震とか火山噴火情報を閲覧できるWebサイトを作った (2015年12月)

上記の記事の通り、EVIは後ろ側がかなり複雑に絡み合っており、機能追加や改修をするにも面倒になっていました。
また、受信したXMLや生成したGeoJSON、画像の保管も同じインスタンス内に入っていたため、ある一定期間ごとに古いデータを削除する等のメンテナンスが必要でした。

...そこで、今回EVIを改修するにあたり以下の目標を立てて移行計画を実行することにしました。

1. 出来る限りマネージドなクラウドサービスに載る(俗にいうサーバレス)システムにする
2. 出来る限り最新の設計・構築方法、技術を用いる
3. デザインをなんかイケてる感じにする←重要

ということで、これらを念頭に置きつつ、隙間時間を使って3ヶ月ほどで作ったものがこちらになります。(冒頭のスクリーンショットのサービス)

QUAKE.ONE
https://quake.one/

#火山要素が消えたことには目をつぶってください

Twitterは以前のIDのまま Prioris_EVI を使っています。

Pushbulletも以前のままです。

日本国内で発生した全ての震源・震度情報
earthquake_jp

日本国内で発生した震度3以上の震源・震度情報
earthquake_int3over

さて、ここからは技術的なお話。

EVIからの進化ポイントは以下の通り。

1. 小さな画面を持つデバイスにおいて、操作可能な地図が非常に小さくなる問題を解決
→どの画面サイズのデバイスにおいても全画面で地図を表示し、情報をマップ上に配置する新しいデザインを採用

2. OpenLayersのバージョンアップ
→OL3から最新のOL4へ移行

3. ページを動的から静的生成に変更、SPA(single-page application)化
→地震発生をトリガーにしてレンダリング用のJSONをあらかじめ生成

4. Twitter、Pushbulletにて配信する画像形式の震源・震度地図のデザイン変更
→画像の生成方法もwkhtmltoimageからPuppeteer + Headless Chromeに刷新

また、これに伴ってサブスクライバから後ろも全て刷新しました。
構成図は以下の通り。(横に非常に長いので、拡大してご覧ください)

使用したサービスは以下の通り。

Google Cloud Platform
・App Engine
・Compute Engine
・Cloud Functions
・Cloud Datastore
・Cloud Storage
・Cloud Pub/Sub
・Firebase Hosting

地震が発生して「震源・震度に関する情報」が流れてきた時のパターンを簡単に説明すると...

1. 気象庁からPubSubHubbubでJMAXML publishing feedを受ける
2. atomを解析してEntryを取り出し、Task Queueに投げ入れ、Entryの内容をDatastoreに書き込む
3. WorkerはXMLを取得、XMLスキーマを適用してJSON形式に変換、XMLとJSONをStorageに保存し、JSONをPub/Subに流す
4. 3種のPub/Subトピックのうち地震に関係するトピックにぶら下がっているCloud Functionsが実行、Datastore内の地域コード対地域重心座標に基づいてGeoJSONを生成してStorageに保存、概要をPub/Sub(topic: quake-one)に流す
5. Pub/Sub(topic: quake-one)にぶら下がっているCloud Functionsが実行、Puppeteer(+Express)が待ち受けているGCEインスタンスに画像生成リクエストを送信
6. Headless Chromeで画像用ページを表示して撮影、Storageに保存
7. 画像生成リクエストが成功すると、当該eventIDの地震の概要と画像のURLをPub/Sub(topic: quake-one-with-image)に流す
8. Pub/Sub(topic: quake-one-with-image)にぶら下がっている各Cloud Functionsが実行、PushbulletやTwitterへ投稿
9. QUAKE.ONE はStorageを参照し、概要の入ったJSONとインタラクティブ地図描画用のGeoJSONを取得、JavaScriptでレンダリング

以前の複雑に絡み合った状態からすれば、随分とメンテナンスしやすいシステムへと変わりました。

AppEngine、Firebase Hostingは自動的にLet's EncryptでSSL証明書を更新してくれるし、しっかりキャッシュ、CDNが効いてくれます。
Storageは、ライフサイクルを設定することで、古いXMLやJSON、画像データを自動的にNear line→Cold lineと安価なストレージに移行、あるいは削除してくれます。
Cloud Functionsは実行時課金で、気象庁XMLをトリガーにして実行する程度の回数では全て無料範囲内に収まります。
唯一、画像を生成するためのPuppeteer + Headless Chromeが入っているGCEインスタンスだけは面倒を見てあげなければなりませんが、これも永続化が必要なデータやステートは持っていないので管理は楽々です。

さらに、副産物としてJMAXML JSON Viewerも出来ました。
こちらはデータ保存期間が浅い＆検索が弱いので受信状況の確認程度用です。
商用利用は禁止ですので、お仕事で使いたい方はゲヒルンの気象庁XML Viewerをご契約ください。

というわけで、出来る限り新しめの手法でマネージドな感じのイケてるサービスが出来ました。

めでたし、めでたし。(終)

追記：その後の話を書きました。
続・気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話