そろそろ何かアウトプットしておかないと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に移行した話