この記事は、合併前の旧ブログに掲載していた記事（初出：2021年3月8日）を、現在のブログへ移管したものです。現時点の情報に合わせ、表記 やリンクの調整を行っています。
こんにちは。Yahoo!天気・災害でエンジニアをしている瀬川です。
2011年3月11日に発生した東日本大震災から、今年で10年がたちます。この2月13日にも福島県沖を震源とする震度6強の地震が発生し余震が頻発しています。
日本で暮らすわれわれには、地震の不安のなか生活しなければならない時期が残念ながらあります。
今回は、このような地震の際に皆様の身を守る手助けができればと開発した「リアルタイム震度」について紹介したいと思います。
「リアルタイム震度」とは？
「リアルタイム震度」は、日本列島に設置された地震計の揺れを、ほぼリアルタイムに情報提供するサービスです。地震の揺れを感じたり緊急地震速報を受け取った時に、揺れの大きさや広がる様子を視覚的に表現するもので、いち早く身を守る行動をとるための判断材料になればと考えております。
2021年2月13日のリアルタイム震度の様子のムービーを用意しましたので、ご覧いただくとわかりやすいかと思います。（4倍速再生）
Yahoo!天気・災害のウェブサイトで提供していますので、ぜひご利用ください。
- リアルタイム震度（Yahoo!天気・災害）
防災科学技術研究所の協力
地震観測点のリアルタイムデータは、国立研究開発法人 防災科学技術研究所から、全国1000カ所以上のMOWLAS（陸海統合地震津波火山観測網）のデータを提供していただいております。このデータは気象庁が発表する緊急地震速報や震度速報の元となるものでもあります。
防災科学技術研究所では、以前より「強震モニタ」という、より高機能なサービスを提供されております。それをより多くの人に届けられるようにと協力し出来上がったのがヤフーの「リアルタイム震度」です。
- 防災科学技術研究所：強震モニタ（外部サイト）
緊急地震速報のしくみ
ここで、緊急地震速報のしくみについて紹介します。
地震が発生すると、震源からは揺れが波となって地面を伝わっていきます（地震波）。地震波にはP波（Primary「最初の」の頭文字）とS波（Secondary「二番目の」の頭文字）があり、P波の方がS波より速く伝わる性質があります。一方、強い揺れによる被害をもたらすのは主に後から伝わってくるS波です。このため、地震波の伝わる速度の差を利用して、先に伝わるP波を検知した段階でS波が伝わってくる前に危険が迫っていることを知らせることが可能になります。
出典：気象庁 緊急地震速報のしくみ（外部サイト）
緊急地震速報が発表された時、「リアルタイム震度」では、P波を青色の円、S波を赤色の円で表現しています。強い地震の場合、S波の円の拡大とともに揺れが大きく（点が赤く）なっていきます。実際に揺れを感じる場所にいた場合、赤い円が通りすぎるタイミングで揺れを感じることができると思います。
緊急地震速報が発表された場合は、この赤い円（S波）が到達する前に身を守る行動をとってください。
「リアルタイム震度」を実現するための工夫
ここから「リアルタイム震度」ページを実現するために直面した課題と工夫について紹介します。
災害に関わるような皆様の命を守る情報は、1ミリ秒でも早く誤解のないように伝えなければなりません。そして、大きな地震の際にヤフーをお使いの多くの皆様にリアルタイムに情報提供する。というのは前例のない課題でした。
工夫1：データ入手は最短
最初が遅いと、どんな工夫をしても遅いままです。ここはコストをかけ、防災科学技術研究所とヤフーのサーバー間は専用線で常時接続することで速度を担保しました。
工夫2：データ処理を速く
高機能を求めると、その機能を実現するための処理が増えていきます。速度を優先するために「本当に必要な情報は何か」と取捨選択し、表現するものを絞ることで処理自体を減らすことにしました。
表現を絞るという点は、速度の面だけでなく「皆様に誤解や混乱をまねかないよう、どなた様にもわかりやすくする」という視点としても重要なポイントです。高度な機能が必要な方は防災科学技術研究所の「強震モニタ」を、一般向けにはヤフーの「リアルタイム震度」と使い分けいただければと思います。
工夫3：データ量を小さく
リアルタイム震度情報は、1秒ごとのデータなので、通信コストやキャッシュの容量の面からも、データ量が小さいことはとても重要なことです。表示に必要な情報だけにデータを変換していき、容量を少しでも小さくできるように絞っていきました。
工夫4：高負荷対策
大きな地震が発生した瞬間のYahoo!天気・災害のアクセス数は、1秒間に2万を超える巨大なものです。「リアルタイム震度」は、ユーザーがページを開いて限り毎秒リクエストする仕組みなので、アクセス数は積算されていく性質があります。秒間2万のアクセスが10秒継続すれば、10秒後には秒間20万アクセスになるわけです。
大きな地震のときは、しばらくページに滞在されることが予想されるので、そのリクエストを返し続けるのは難しい課題です。そして、この課題が解決できないと公開できません…
最初は一般的なAPIシステム構成で考えてみました。
ここで、仮にAPIのレスポンス（応答までの処理時間）が1秒かかるとすると、CDNにキャッシュが登録されるのも、およそ1秒後になります。大きな地震が発生し、1秒間2万のリクエストがあった場合は、キャッシュの無い1秒の間の2万リクエストをAPIが返さないといけなくなります。
また仮に、APIが1秒間100リクエスト返せる性能だとすると、単純計算でAPIサーバーは200台必要になります。リアルタイム震度の場合、アクセス数は毎秒積算されるので、200台では足りなくなってしまいます。
そもそも毎秒更新される情報ですから、APIのレスポンスが1秒かかると、CDNのキャッシュが作られたころには、そのデータは過去のものなってしまい、なんともリアルタイムでないシステムになってしまいます。
（実際にはAPIのレスポンスは1秒もかからないので無意味ではないのですが、ここでは極端な例として書いています）
この構成での改善点を考えると以下のようなものが考えられます。
- APIサーバー1台あたりの返せるリクエスト数を増やす。
- APIサーバーのレスポンスタイムをすごく速くする。
- キャッシュをすごく速く作れるようにする。
しかしながら、この構成で改善していっても安全に運用できる状態までたどりつくのは難しいと考えるようになりました。台数を増やすにしても何千台も用意するわけにもいかないですし、処理速度もそもそも機能を少なくしているのでこれ以上の速度改善も微々たるものです。
発想の転換
結果から考えると、リクエストのほとんどをCDNのキャッシュから返す状態になれば問題はなくなるはずです。
なるべく速くキャッシュを作るには、処理が必要なAPIでは限界があるので、処理の必要ない静的なファイルを用意する方法を試しました。時間の指定は、APIのパラメタ（t=20210308123456）ではなく、1秒ごとのファイル（ファイル名を時分秒とした20210308123456.json）を用意する方法です。
静的なファイルですのでリクエストに対して何も処理できませんが、事前にバッチサーバーで必要なデータ変換を行うことで対応しました。
この方法であればストレージにある静的なファイルを返却するだけなので、APIより格段にレスポンスが速く、すぐにCDNにキャッシュを登録できるようになりました。これにより、ほぼ全てのリクエストをCDNのキャッシュから返せるようになり、安全に運用できる状態を作ることができたわけです。
おわりに
リアルタイム配信の 技術には新しいものも数多くありますが、今回の課題を解決してくれたのは最新の技術ではなく昔からよくある手法でした。ほんとうに課題に見合った解決方法はなにかと、固定観念にとらわれずに柔軟に考えられることが振り返ると重要だったと思います。
このような工夫で完成した「リアルタイム震度」、皆様の防災にお役立ていただければ幸いです！
