webサービスと瞬間風速
Keyword: web,データベース,isucon, 瞬間風速,RDB.
Written by @cielo5150 / modified: 2022-08-22 08:00:00.
はじめに
4月から以前よりも大きなサービスを扱っている会社に転職しました。以前の職場でもプレスや大型ニュースサイト等で取り上げられると「システム大丈夫なんだろうか?」「噂っていうフラグで、おちるわけないだろwww」「うわ、落ちた」みたいなことがありました。時として「突風」が吹くこと、予期した「暴風」が来ることがこの界隈はあり得ます。
そんなこんなで、過去を振り返りつつ、突風を凌ぐためにしたことを書いていこうと思います。
※ ここでは、手軽く、エンジニア的な知識がなくても提案できそうな内容を記載します。最低限まずはこれはできるよね、の個人的なリストにしたく、今回まとめてます。本当の気休め程度の情報です。
問題はこれだけじゃないので、悪しからず。そしてこのブログはそこまで考えたサーバーではございません。
ボトルネックを最低限知っておく
これまで携わったサービスで原因になったことは大体、
- データベース CPU
- データベース Connection
- 同時接続数
だいたいデータベース、あとは同時接続、何かが鍵だと思います。大事なのは、どの画面、どの処理が負荷が高いのか、どうすると危ないのかなどをしっておくことです。
負荷をかけてるバッチを止めてみる
バッチとは、定期実行される処理をバッチ(Batch)と呼んだりします。毎分、毎時で行うような処理を登録しておき、計算させたり、データを登録したりなどしています。
このバッチですが、実行された際、一定時間 データベースに負荷をかける状態ができるものだとします。バッチの実行タイミングで、「突風」が吹いてしまっている場合、ユーザが見えるところに支障がでる可能性があったり。
基本的に、今までいた職場だと重たい処理を実行する場合、アクティブユーザが少ない時間帯での実行だったり、データのレプリカを別のデータベースに転送し終えた後で、独立したバッチサーバーでバッチの実行をしていたのですが、どうしても毎分、毎時間、回さなければいけない、本番と切り離されていないバッチがある場合、「バッチを止めてみる」という手段があります。
とはいえ、ちゃんと時間帯や条件を管理しておけば、バッチを止めずしもどうにかなります。
キャッシュの効きを見直す
サービスによってですが、同じ情報を繰り返し取りに行く箇所があったりします。例えば、未ログインユーザと、ログインずみユーザで表示を出し分けてて、未ログインユーザに見せる情報をデータベースから取りに行く、など。その際都度リクエストが生じる状態だとしたら、瞬間風速が吹き荒れた、対象ページがそれだったら「逝き」ます。会員制サービスじゃなくても都度情報を取りに行くみたいなことが起こればいくでしょう。
そんな時のために、キャッシュを用意していて、時間で切れるようなキャッシュの場合問題にならないかなど、エンジニアと相談してみましょう。
静的ファイルに変える
更新頻度が比較的少ない場合、情報を静的ファイルに置き換え対処するのも1つの手です。例えばAPIレスポンスをjsonファイルに出力、基本的に利用する側はjsonファイルを見て、batch等でjsonファイルを一定周期で更新できれば問題ない場合があります。
以前の職場でワードプレスを利用していて、rssを取得する処理起因で、サービスが落ちたことがありました。もちろん当たり前のデータベースのキャッシュは効いていて、通常通りの利用であれば問題はなかったのですが、突風によってもらい事故を受けました。
簡単な説明ですが、データ(情報)を取りに行くという処理は、アクセスが増えると、ファイルをブラウザに渡すだけよりも苦しいということです。なので、ここでの対応は静的ファイルに置き換え、定期的に更新する、ということに変えました。
WordPressのフィードはデータベースから投稿情報を取得して、リスト化、XML形式として情報を返すものです。リクエストされた際にデータベースにアクセスし、データを取得するリクエストが起こります。ここがボトルネックになったりします。リクエストされた際、当然キャッシュがヒット、レスポンスをすぐ返すことはしているのですが、膨大なリクエストであると捌ける必要もなく。もちろん相応のスペックのサーバーを用意しているなら大丈夫ですが、想定の範囲を超えたものがきたとします。落ちますね。
上記の例ですが、要件次第では大きな効果を発揮でます。データベースの負荷やコネクションを下げ、静的ファイルになるので、サーバーの設定次第で静的ファイルのキャッシュが有効になってたりするので、レスポンスタイムの大幅な改善にもつながったりします。
別の例で行くと、インデックスをはれなくなったデータベース(レコード数が膨大でサービスを止めなければいけないようなもの、パーティションやシャーディングができないもの)とかでもこのアプローチであれば、一時凌ぎにはなります。
まとめ
簡単ではありますが、過去に携わったサービスの突風対策について触れてみました。サービスに携わっている人で、何かの一助になってくれれば幸いです。