概要

svir.jp（現在API URLは非公開）にて、緊急地震速報を2017年12月11日から提供しています。

提供開始数年は、アクセス量が低調（50rps未満）でしたが、2020年あたりからアクセス量が急増しその対策や利用者への依頼などを行いました。

これはその雑記となります。

また、このAPIは閉鎖予定（2022年08月01日）で有料サービス（開始日未定）に移行する計画を立てています。

大量のリクエスト

件のAPIがあるサーバーのリクエスト・トラフィック量の推移を下記に添付します。

これを、コア2・メモリ2GBのVPS 1台で捌いています。

CPU使用率は60%以下とrpsに対しては低調です。

処理する内容によりけりですが、案外いけます。

増えるリクエストとトラフィックに対応するため、以下のようなことを実施しました。

マルチスレッドでAPIを処理するようする以前はPHP-fpmで逐一処理していました。
こちらもリクエストをマルチで捌いてくれはするのですが、メモリやCPUリソースが余計に消費しており、増大するリクエストには対応できなくなりつつありました。

PHPからNode.jsへの乗り換えを行い、マルチスレッドで捌けるHTTP-Serverを作成しました、思ったより簡単でしたね。
レスポンスはユーザーによって変わらないのでデータを整形したらメモリに保存し、要求があったら返答しています。

実施した当時はCPU使用率が少し下がり、メモリ使用率がかなり改善した記憶があります（かなり前で資料が紛失しています・・・）。

CPUやメモリなどのリソース問題の他に、通信帯域を消費し通信ができなくなることがあります。
大きな地震で、緊急地震速報（警報）が発表されるとそれだけレスポンスサイズが大きくなります（圧縮なしで2倍以上）。

HTTPリクエストの圧縮通信を行わない実装（言語標準ライブラリを使用しているなど）している利用者へ、圧縮通信実装のお願いと更新を促しレスポンスサイズが大きくなっても急激に通信帯域を消費することを回避しました。

Nginxの設定に誤りがあると、パフォーマンスがかなり落ちCPUリソースを余計に消費します。

worker_processesと、events内のworker_connectionsの設定を見直したところ、パフォーマンスが大幅に改善しました。

設定は以下のようにしました。

worker_processes auto;
worker_rlimit_nofile 85000;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

worker_rlimit_nofile はディスクリプリンタの値の設定です。

ディスクリプタを変更するときはOS全体で扱える数を超えないようにする必要があります。確認方法は以下になります。

$ cat /proc/sys/fs/file-max
182027

ここでは半分以下の値を設定しています。

worker_connectionsは、Nginxで同時で処理できるコネクション数を指定します。
指定できる値はディスクリプタの値以上を設定することが出来ないので、変更する必要があります。
制限に余裕をもって、worker_rlimit_nofileの約20分の一の値にしています。

どうやら4096でも同時接続上限に達しているようなのでその倍、worker_connectionsを8192で様子を見ています。

OpenSSL 3.0.0、Nginx 1.21.4 から使える機能として、TLSの処理をKernelにほとんど一任しメモリやCPUリソースの移動を抑え、パフォーマンスを向上させるものです。

CPU使用率が数パーセント改善しました。

このAPIは、初めに書いた通り2022年08月01日に閉鎖となるものです。

有償API化については、決定次第私のTwitter @soshi1822などでお知らせしますのでよろしくお願いします。

緊急地震速報のAPI有償化をするにあたり、気象業務支援センターから直接取得する方式を採用します。
とある人にNTT IP-VPN Arcstar Universal Oneを契約してもらい、「JMAソケット付きTCP/IP」を引っ張る予定です。

初期投資もそれなりにかかるので、少しでも応援してくれるっていう人はぜひ使ってください（月1650円）。

APIの提供を通じて、大量に来るリクエストの扱い方やその対策など普段ではできない体験ができました。
今でも、ここまでリクエスト量が来るとは思わず日々驚愕しています。

以上、ありがとうございました。