この投稿は 防災・減災 Advent Calendar 2016 の 15日目の記事です。
##はじめに
taskey株式会社でフロントエンジニアをやっております。
深見と申します。
私たちは熊本地震が起きた際、【熊本地震 情報掲示板】というWebサービスを開発しました。
そのWebサービスの内容や今回の開発で得た知見などを残しておきたくアドベントカレンダーに投稿させていただいてます。
稚拙な文章で伝わりづらい部分もあるかと思いますが、最後まで読んでいただけると幸いです。
また震災のこと + システム周りのことだったのでqiitaに投稿するか迷ったのですが、どたらかというとエンジニアの方向けの知見だったのでqiitaに投稿させていただきました。
熊本地震について
熊本地震（くまもとじしん）は、2016年（平成28年）4月14日21時26分（日本標準時[注釈 1]）以降に熊本県と大分県で相次いで発生している地震である。
気象庁震度階級では最も大きい震度7を観測する地震が4月14日夜（前記時刻）および4月16日未明に発生したほか、最大震度が6強の地震が2回、6弱の地震が3回発生している[JMA 2]。日本国内の震度7の観測事例としては、4例目（九州地方では初）[4]および5例目[JMA 3]に当たり[注釈 2]、一連の地震活動において、現在の気象庁震度階級が制定されてから初めて震度7が2回観測された[5]。また、一連の地震回数（M3.5以上）は内陸型地震では1995年以降で最多となっている[6]。
2016年4月14日に熊本で地震が起きました。
僕達taskeyチームは東京を開発拠点にしているので実際に被災したわけではありませんが、熊本に縁のあるメンバーも多く（僕は大学時代を熊本で、COOは生まれも育ちも熊本）、何かしたいと心のなかで思っていました。
そんな時、熊本地震の情報を得ようといろんなものを見ているうちにある問題点を見つけました。
災害時における情報の問題点
情報の判別の難しさ
何かの情報を見つけたい場合、身近なスマートフォンなどから情報を取得することが出来ます。
震災に関する情報ももちろんそうです。
震災時の場合、情報を得ることが出来る媒体として、facebook, twitter, instagramなどのSNS、熊本県や市役所などの行政機関が出している情報などが存在します。
ただ、２つの情報にもメリットデメリットがあります。
| 発信源 | メリット | デメリット |
|---|---|---|
| SNS | ユーザー投稿形なので情報の更新が非常に早い | 正しい情報もあれば間違った情報も含まれる |
| 行政 | 基本的に情報が正しい | 情報の更新が早いわけではない |
一般的にもよく言われていることですが、ユーザーが投稿するSNSの情報は更新が非常に早く、信頼度は高くはない。
震災などの緊急時は通常時より情報が非常に多く流れていくためどれが正しい情報であるかを判断することは非常に難しいです。本当に正しい情報が含まれている場合でも他の情報に埋もれてしまい発見できないこともあるでしょう。
こういう場合に本当に信頼できる情報は市役所などの行政機関が公式に発表している情報です。
正しい情報を得る手段がない
上の表でも書いたとおり、行政機関の情報のほうが信頼度としては高いですし、震災時には各機関のWebサイトに震災に関する情報などが掲載されていました。
- 熊本市役所 ・・・ 震災情報、避難情報, etc...
- 熊本水道局 ・・・ 水道情報、断水情報, etc...
- 気象庁 ・・・ 日本全体の地震速報
- その他行政 ・・・ 各自治体で同じように情報掲載
しかし、震災という緊急時に多くの人がアクセスし、市役所や水道局などのWebサイトへを開くのが非常に困難な状態になってしまっていました。
レスポンス自体が返ってこずタイムアウトしてしまうこともありました。
そこで上記問題点を解決すべく以下の3点に集中してサービスの開発を行いました。
- 多くのアクセスにも耐えることが出来るサーバを使用する
- 熊本市や水道局などの行政からでている正しい情報を記載している
- ユーザー投稿型で情報を記載することが出来る
次に開発したサービスに関して説明します。
熊本地震 情報掲示板に関して
僕たちは【熊本地震 情報掲示板】（既にサービス自体は閉じています）というものを作成しました。
縦に長くなってしまって申し訳ありませんがページ全体のスクリーンショットを全て貼っておきます。
サイト内にある情報は主に以下のとおりです。
また、詳細は画像を見ていただけると幸いです。
- 熊本市、水道局、気象庁などの行政機関から発信されている情報
- 避難所や炊き出し・配給所、給水場所、SOS情報、ボランティア応募などの一般の方が投稿できる情報
- 義援金などの外部の方からの支援の情報
アーキテクチャ全体
シンプルですが全体の構成図をまとめました。
システム全体の仕組みは以下の２つしかありません。
- サイトにアクセスしたユーザーはRoute53を通じS3バケットへアクセス。S3バケット内に存在する
index.htmlファイルを返す。 - 常に最新で、正しい情報を更新するためにEC2から熊本市役所、水道局、気象庁などの行政機関に定期的にアクセス。収集した情報から静的なhtmlファイルを生成しS3へアップロード
仕組みの解説も含め内容を紹介していこうと思います。
システム詳細
1. 多くのアクセスにも耐えることが出来るサーバを使用する
まず多くのアクセスが来ても問題なくレスポンスを返すことができるようなサーバを探しました。
確かにwebサーバの台数を増やし、ロードバランサー等の設定を行えば問題ないのでしょうが、そのようなものを用意する時間もありませんし、緊急時にどのくらいのアクセスが来るのかもわかりません。
サーバへの負荷のせいで情報へアクセスできないことは絶対に起きてはならないので同時リクエスト数が膨大な数になっても問題ないようなサービスを探していました。
幸いにもAWS（Amazon Web Service）のS3（Simple Storage Service）を業務で使用しており、1秒間に多くのリクエストが来ても問題ないと認識していたのでそちらを使うことにしました。
また、S3はストレージサービスなので静的ファイルしか置くことが出来ません。
なので今回はhtmlをEC2を利用してhtmlファイルを作成し、S3へアップロードする方法を取りました。
画像で言うと以下の部分になります。
2. 熊本市や水道局などの行政からでている正しい情報を記載している
S3上にhtmlファイルを置いておき、アクセスユーザーにそれを返すことで安定してアクセスをさばくことができました。
次に常に正しい情報をhtmlとしてS3においておく必要があります。
正しい情報とは繰り返しになりますが行政機関がWebサイトに載せている情報です。
- 熊本市役所 ・・・ 震災情報、避難情報, etc...
- 熊本水道局 ・・・ 水道情報、断水情報, etc...
- 気象庁 ・・・ 日本全体の地震速報
- その他行政 ・・・ 各自治体で同じように情報掲載
行政機関が掲載している情報をhtmlにまとめるのにはWebスクレイピングの技術を使用しました。
Webスクレイピングとは必要な情報を指定したWebサイトから取得するような技術のことです。
今回はWebスクレイピングを用い、上記サイトから情報を収集し、その情報からhtmlファイルを作成しS3へアップロードするようにしました。
また、スクレイピングのアクセス自体が行政のサイトへのアクセス負荷につながってはいけないのでスクレピング自体は1分間隔で行いました。
画像で言うと以下の部分になります。
3. ユーザー投稿型で情報を記載することが出来る
これにはgoogle formとgoogle spreadsheetを使用しました。
上記サービスを利用したのは、時前で作るよりも巨人の肩に乗ったほうが安定している&開発速度も上がるからです。
ここには、避難所情報や炊き出し、トイレ、コンビニ、SOSなどの多くの機能を投稿できるようにしました。
問題点
上記のようなシステムでWebサイトを作成したことで多くの人からアクセスがあっても目に見えてレスポンスの速度などが遅くなったことはありませんでした。
Google Analyticsの情報によると2300人くらいが同時アクセスしてもまったく問題ありませんでした。
また、このシステム自体の企画・開発・リリースまで約12時間ほどで行うことが出来ました。
数日ほど時間を書けて開発を行えばもっと立派？なものが出来たかもしれませんが、震災などのが起きているときにそのような悠長なことは言ってられないと思っていたので約半日で完成できたのは良かったと思っています。
しかし、完ぺきにできたわけではなく問題点も存在しました。
スクレイピング先Webサイト構造の変更
今回のWebサイトでは行政の情報を取得してくるWebスクレイピングの技術が非常に重要になりました。
Webスクレイピングとは実際にシステム側から行政webサイトにアクセスしその中のDOM（htmlの構造）から対象となる部分を見つけ出しそこから情報を抽出するといったことを行なっています。
そのため、行政側のWebサイトの構造が変更されてしまっては正しい情報が取得することが出来ません。
このようなことが実際数回起きてしまい、その間は正しい情報が取得できていないことがありました。
スクレイピング先Webサイトにアクセスできない
これは想定していたことですが、そもそもスクレイピング先のWebサイトにアクセス出来ないということもありました。
webブラウザを通じてアクセスするときと同じようにリクエストがタイムアウトしてしまうといった感じです。
幸いにも時間をかけるとレスポンスは返ってくることが多かったので、返ってこない場合は前回取得した情報を残したまま最終更新日時を前回のものにするという対応を行いました。
そもそもサイトが信用できない
僕達のサイトは正しい情報源の情報を取得して掲載していましたが、その情報が正しい情報かどうかはアクセスしていただいている人にはわかりませんし、運営元の僕達が信用できるかも非常に判断しづらいところでした。
個人的に思う解決策
アクセス増加をさばくようなサーバの設計にする
そもそも信頼できる情報を載せている行政機関のサイトのサーバを増強 or 高アクセス時にスケーリング出来るように設計するという方法です。
行政機関のWebの仕組みや予算などをまったく知らないのであまり詳しくお話することは出来ませんが、現実的ではなさそう。。。
APIを用意する
各行政機関には緊急時に情報を公開するAPIを作成していただければ非常に助かります。
通常のアクセスをさばくサーバとは別に用意していただき、そこへ開発者はアクセスし緊急の情報をjson形式で返してもらえるとそれを使って情報を公開することが出来ます。
また、そのようなAPI一覧が集まっているページなどを作ってそこにAPIの仕様をまとめるなども必要だなと思っています。
謝辞
今回は非常に多くの方に助けていただいて本サービスをリリースすることが出来ました。
僕たちtaskey株式会社はスタートアップ企業であるので僕達一人の工数を取ることは当たり前ですが会社としてはリスクになります。
そういう中でも「社会的に意義があることならやるべきだ」と開発を中断してもやるべきだと背中を推してくれた弊社CEOの沼澤には非常に感謝しています。
また、業務と並行しつつ外部とのやり取りや開発を続けた、弊社COO大石、エンジニア石山にも感謝しています。
また、Increments株式会社プロダクトマネージャーであり、IT DARTの代表理事である及川卓也さんにも様々なアドバイスを頂いたり、関連する救助団体の方や有識者の方とお話する機会をいただきました。ありがとうございます。
また、熊本地震情報掲示板に掲載されている情報を元に実際に被災地で救助活動などを行なってくれた熊本の方々にも本当に感謝しています。
SNSで拡散を手伝ってくださった多くの方にも非常に感謝しています。
わたしたちのサイトは正しい情報を載せているといっても実際にその根拠はありません。
そんな中twitterやfacebookなどで多くの方、SNS上で影響力のある芸能人の方や著名人の方にも多く拡散していただきました。
ありがとうございます。
個人的感想
実際にどのくらい影響があったか何人の人を助けることが出来たかは定かではないですが、SNSや実際の知人の感想をいただいてる様子だと少しは被災した方の役に立ったのではないかなぁと思っています。
好きでプログラミングをはじめて多くのサービスを出してきましたが熊本地震情報掲示板を開発して感謝の言葉を目にしたときに「プログラミングやってきて本当によかったな」と強く感じました。
多分単なる自己満足でしかないと思いますが、Webと言うかたちが見えないもので、人の力になれたことが本当に嬉しかったです。
長くなってしまいましたがこれで終わりです。
何か皆様の知見になっていたらうれしいです。
皆様ここまで読んでいただきありがとうございました。