自然災害に負けない社会に向けて

こんにちは、CTOの藤門（@mikanmarusan）です。

2019年10月12日、関東に上陸した台風の中では過去最大級となる台風19号が上陸し、大きな被害をもたらしました。台風の被害にあわれました皆様にお見舞い申しあげるとともに、犠牲になられた方々とご遺族の皆様に対し、深くお悔やみを申しあげます。

この日、ヤフーのサービス開発現場では、昨年発生した平成最大の水害とも言われる平成30年7月豪雨レベルを想定して準備していましたが、メディア関連サービスを中心に想定を超えるアクセスが急増し対応に追われました。各所でサーバーを増強しながら、機能ごとの負荷対策を実施し、ユーザーの皆様への情報提供を行っていました。

ヤフーでは「自然災害に負けない社会」に向けてさまざまなサービスを通じた取り組みを行っています。この記事では、これらのサービスを運営するための技術的な取り組みを紹介します。

提供している主なサービス

まずはヤフーが提供しているサービスや機能を紹介します。

Yahoo!防災速報

緊急地震速報・豪雨予報・避難情報などをいち早くお知らせします。災害が起こる前にいち早くアプリのPush通知やメールにてお知らせします。これひとつであらゆる災害関連の情報をキャッチできます。

Yahoo!防災速報

Yahoo!天気・災害

毎日の天気情報はもちろん災害関連の情報まで提供するサービスです。またアプリでは、高性能な「雨雲レーダー」で雨の降り始めを予測・通知する機能があり多くのユーザーの皆様にご利用いただいています。必要な情報がひと目でわかるので普段使い派にもオススメです。

Yahoo!天気・災害

自然災害特有の機能

災害関連情報をすべてのページに表示する

災害が発生した際に、多くの方に地震や津波、大雨警戒レベルなどの情報をお知らせするため、通常はバナー広告が表示されているスペースを利用して、災害関連情報をYahoo! JAPANのすべてのページに表示しています。ヤフーをお使いのみなさんであれば一度は見ていただいたことがあるかと思います。表示基準は、震度3以上の地震、また津波警報・大津波警報や大雨特別警報などが気象庁から発表された場合です。

災害情報の表示例

すべてのページで表示するためには、大量のトラフィックを処理できることはもちろん、高トラフィック低レイテンシーなシステムである必要があります。少し前までは米ヤフーの技術に頼っていた時代があり、そのディスプレイ広告の仕組みを利用して配信していました。最近では、サービスの提供環境のモダナイゼーションを進めており、災害情報表示においても自社開発のプラットフォームに切り替わりつつあります。

災害関連情報をユーザーに通知する

ヤフーでは、Yahoo! JAPANアプリ、Yahoo!天気アプリ、Yahoo!防災速報アプリなどを利用しているユーザーに向けて、災害関連情報をアプリのPush通知の機能を利用して提供しています。通知内容は大きく2つに分けられます。

• 緊急地震速報
  • 緊急地震速報は、地震の揺れの予報・警報です。地震の発生直後に震源近くの震度計がとらえた観測データを素早く解析して、震源や地震の規模の推定を行うものです。これに基づいて各地の震度や到達予想時刻を予測し、可能な限り素早く知らせるものです。緊急地震速報の情報は、防災速報アプリのPush通知で通知しています。緊急地震速報は、1回の通知量は限定されるものの「とにかく素早く」配信する必要があります。したがって他の災害関連情報の通知状況に影響されてはならないので、専用の通知システムを構築しています。
• 緊急地震速報以外の災害関連情報（地震発生、警報、豪雨、河川氾濫、熱中症など）
  • 緊急地震速報以外の災害関連情報は、その通知の種類の豊富さもあって、数千万人のユーザーのみなさんに一斉にPush通知をする必要があり、システムでは様々な工夫をしています。とにかく通知量が大きくなるので「短時間で多くの通知」ができることが重要になります。配信タイミングをコントロールしたり、並列処理によって配信数をスケールできるようにしたり、なかにはサーバーのカーネルチューニングまで施すなどしたり、可能な限り短時間で多くの通知ができるよう日々改善を続けています。

災害関連のPush通知のシステム

災害関連情報をユーザー間で共有する

防災速報アプリに、ユーザーの皆さまで情報を共有しあえる「災害マップ」という機能があります。昨今の大雨災害の状況から、公的情報だけでなく、その場にいる住民の方々から得られる情報を活かし、大雨災害の被害を減らすための試みです。台風19号が上陸する前日に期間限定でリリースし、多くの方にご利用いただきました。（2019年12月時点では、本サービスとしての提供は行っておりません）

新機能「災害マップ」については、12/10（火）に、松尾より詳しくご紹介します。

10月25日の千葉・福島豪雨の際の災害マップの画面

大量のトラフィックをどう処理するか

台風や豪雨の時には1日1億PVを超え、特に地震発生時はスパイクトラフィックとなり、秒間1万リクエスト以上になります。そのため大量のトラフィックを処理できるよう、トラフィック予測に基づきアプリケーションを書き換えたり設備増強をしたりしています。また、首都圏での地震発生や重大な災害が差し迫っているときなどには特にスパイクトラフィックとなることが多く、通常と比較して50倍以上のトラフィックとなります。そのピークの継続時間は、数時間にわたるものもあればたった数秒のスパイクということもあります。常に最大トラフィックを処理できるように設備投資をすると経済合理性が得られないですし、オートスケールを働かせたとしてもスケールアウトできたときにはすでにトラフィックが減少しつつあるということもあり、常に頭を悩ませるところです。ヤフーでは具体的対策として以下の4つの戦略をとっています。

• キャッシュ戦略
• 冗長構成＋負荷分散の戦略
• コンテナテクノロジー環境下でのスケーリング戦略
• それでもだめなときの戦略

過去最大級となる台風19号の際のトラフィック（2019年10月12日）

ここでは、主にYahoo! 天気・災害の仕組みを中心にお伝えします。

キャッシュ戦略

天気・災害サービスでは、コンテンツ特性に応じて異なるキャッシュを持つことで内部処理を減らしています。一方でキャッシュを持つということは内部にステートを持つことにつながりシステムが複雑化しやすいので、キャッシュを利用してもシステム全体としてはシンプルになるようにというポリシーを持ちつつ、以下のような取り組みをしています。

• CDN(Content Delivery Network)やリバースプロキシレベルでのキャッシュ

  • APIレスポンスのキャッシュ
  • オリジン（フロントエンド）のコンテンツのキャッシュ
  • コンテンツププロバイダーから提供された画像のキャッシュ
  • ...

• 内部レベルでのキャッシュ

  • 表示に必要なデータ(JSON, HTML）を事前生成する
  • 超高速にアクセスできるよう検索エンジン化しておく
  • 外部システムのレスポンスのキャッシュ化。これは外部システムに大きなトラフィックが到達し破壊しないようにするための配慮
  • ...

冗長構成＋負荷分散の戦略

大量のトラフィックを処理するためにもそのインフラ自体が安定に稼働しなければなりません。ヤフーでは、東日本は東北、西日本は九州にそれぞれ自社データセンタを保有しており、ヤフーのサービスを稼働させるサーバーを設置して大量のトラフィックを処理できるようにしています。また、東日本は東京、西日本は大阪でインターネットと接続し、この2つの拠点に独自のCDNクラスタを配置しています。ユーザー（インターネット）に近いところでキャッシュを配信することで、「ユーザーには低レイテンシでコンテンツを提供できる」「オリジンサーバーへの負荷を下げることができる」というメリットがあります。

ヤフーの国内ネットワーク

また、インフラチームによって提供されているフルマネージドな負荷分散の仕組み（CDN、リバースプロキシ、ロードバランサ）などを利用できます。サービス開発者チームは、あまり手間をかけることなくサーバーのスケールアウトができるので、アプリケーションの開発に注力できるようにしています。

下記は、天気サービスのシステムのアーキテクチャを大まかに書いたものですが、冗長構成や負荷分散を社内のフルマネージドな仕組みをつかうことで、WebのアプリケーションやAPI開発に注力できることがわかるかと思います。

天気サービスのシステムのアーキテクチャ例（1〜7はデータの流れ）

コンテナテクノロジー環境下でのスケーリング戦略

ヤフーでは、サービスの開発環境のモダナイゼーションを進めています。特に、コンテナテクノロジーをベースとしたフルマネージドなサービス開発環境（以下、新環境）を利用することで、アプリケーション開発にフォーカスしてサービスリリースまでのサイクルを早くしていきたいと思っています。

新環境を利用することで、スケールアウトが非常にスムーズにできることもわかってきています。実際、台風19号の対応でも通常のバーチャルマシンに比べてより効率的にサーバー増強を行うことができました。現在はヤフーの全サービスのうち、約30%が新環境で動いています。モダナイゼーションをさらに進めていくことで、サービスの負荷対策に貢献できると信じています。

このフルマネージドなサービス開発環境については、12/22（日）に、増田より詳しくご紹介します。

それでもだめなときの戦略

それでも残念ながらトラフィックを処理できないときがあります。特に災害による被害が大きくなるときは、ユーザーのみなさんからのトラフィックもどんどん増えていきます。大量のトラフィックによりサーバーのパフォーマンスが低下し、繋がりにくくなったことでユーザーが再接続を試み、さらにパフォーマンスが低下し、さらにユーザーが再接続を... と一瞬で負の循環に陥ることがあります。こういうときはある種の「割り切り」も重要です。

処理できないような高いトラフィックが発生する、もしくは発生すると見込む場合は下記のような対策をとることができます。

• 流入制御
  • まず大量のトラフィックの元になっているところからの流入を遮断することによって「暴れている」システムをコントロールできるようにします。
• サーキットブレーカーの発動
  • 事前に設定した上限（Rate Limit）を超えた時に、処理を中断してあらかじめ用意された画面（例えば、「現在利用できません、しばらくお待ちください」のような画面）を出すことで、障害を大きくしないようにしたり、障害を他のシステムに伝播させないようにしたりします。
• 簡易ページへの切り替え
  • 上記のサーキットブレーカーと組み合わせて使うことも多いですが、処理を中断せず最低限の機能を提供する方法のひとつです。具体的には、負荷の高いモジュール（広告、レコメンデーション、ランキングなど）を取り除いた簡易な画面を出します。特に、Push通知にリンクするランディングページは、いわゆる「ヤフー砲」と呼ばれる大量のトラフィックを受けるページです。したがってキャッシュが有効に働くよう、パーソナライズ機能や広告モジュールを外します。

非常時におけるトップページのモジュール表示例

インフラ、プラットフォームチームとの連携

ヤフーでは、効率良くサービス開発を行うためにサービスがよく利用する機能は社内プラットフォームとして提供しています。メディアサービスやコマースサービスを開発しているエンジニアが、自分たちがやるべきアプリケーション開発に注力するためです。例えば下記のようなフルマネージドなプラットフォームを提供しています。

• サービス提供環境: IaaS, PaaS, CaaS, FaaS, ...
• ストレージ: ユーザーデータ, KVS, DBaaS, オブジェクトファイルストレージ, ...
• ネットワーク関連: CDN, リバースプロキシ, ロードバランサ, ...
• モニタリング、ログ: メトリックモニタリング, ログコレクタ, 監視,
• ...

自然災害が発生している時に、災害関連情報を提供するサービスがダウンしてはならないと考えています。いいかえると大量のトラフィックとの戦いは、社内プラットフォームチームの戦いでもあります。社内プラットフォームがトラフィックに耐えられなくなったり、障害によってダウンしてしまったりすることがないように、極めて安定的に稼働することが求めらるということです。したがって多くのプラットフォームが、複数のリージョンかつ複数のアベイラビリティーゾーンで稼働する冗長構成をとっています。

それでもハードウェアは必ず故障してしまうし、どんなに注意しても人はミスをしてしまうし、自然災害の時はプラットフォーム自らの設備がダメージを受ける可能性もあります。ただ、ユーザーの声が直接届くサービス開発メンバーからみると、少しでも社内プラットフォームに問題が生じると不満が出てしまうというのも事実です。

ヤフーでは、プラットフォームがそれぞれの品質基準「マニフェスト」を宣言することにしました。プラットフォーム提供者は各プラットフォームの品質基準を提示しその維持に責任を持つこと、プラットフォーム利用者は各プラットフォームの品質基準をもとに止まらないサービス作りに責任を持つことをともに明確にし、提供者と利用者が一体となってYahoo! JAPANサービスの安定稼働を実現する取り組みを始めています。

ヤフー主要プロダクトの安定性向上のための社内取り組み事例

プラットフォームが宣言する品質基準「マニフェスト」に記載されている項目の一例となります。

• インタフェース: WebUI, RESTful API, CLI, ... など
• 利用環境: 本番環境, 開発環境, セキュア環境, ... など
• リージョン: 地域冗長性の状態
• アベイラビリティゾーン: リージョン内のアベイラビリティゾーンの状態
• 関連するプラットフォーム: 依存しているプラットフォームの有無
• レイテンシ: 99%ileのレイテンシ
• スループット: 処理可能なrps
• 可用性: 稼働率の定義と目標稼働率
• メンテナンス: 計画停止の方法と影響、計画停止はいつまでにどのチャネルで案内するか, ... など
• バックアップ: バックアップの手法、取得時刻、取得頻度、保持期間, ... など
• ...

プラットフォーム提供者とプラットフォーム利用者の責任分界点が明確になりますが、この取組みの最も重要な考え方は、同じ目標に向かって提供者と利用者が手と手をとりあえるようにするということです。対立構造とは真逆の考え方です。

実際、台風19号の時は、メディアサービスのエンジニアだけでなく、インフラチームや社内プラットフォームチームのエンジニアが常に連絡を取り合いながら安定稼働に向けた対応をしていました。専用のSlackチャンネルでは、エンジニアだけでも350人以上が参加していましたし、東京・大阪・福岡などの複数のロケーションから対応をするためにビデオ会議システムのZoomを接続したままにしてコミュニケーションをしたケースもあります。

さいごに

自然災害に負けない社会に向けてヤフーが取り組んでいるサービスについて紹介しました。これらのサービスは自然災害が起きなければほとんどアクセスがないのも事実です。しかし有事の時にこそ多くのユーザーから頼りしていただける、そういうサービスをこれからも提供していきます。もしもの時にヤフーのメンバーが、愚直に取り組んでいることを知っていただけたら幸いです。