こんにちは！クラダシの徳山です。

株式会社クラダシは、社会貢献型フードシェアリングプラットフォーム「KURADASHI」を運営している会社です。世界的な社会課題のひとつである”フードロス”を解決すべく事業を展開しています。
おかげさまでメディアからも注目を多く集めており、テレビで特集を組んでいただく機会が増えています。
今回は、2014年のクラダシ創業を支え、2020年9月からは技術顧問に就任している荻野に、テレビ放映の裏側をお聞きしました。

ー最近のテレビ露出はすごいですね。

SDGsが定められるよりも早い、2014年に創業していたこともあってか、当時から取り上げていただく機会は多かったですが、ただ特にここ半年くらいはかなり加速している印象がありますよね。

ーなぜテレビ放映でインフラづくりが重要なんですか？

テレビ放映前後で、トラフィックが激増します。
当然ですが、何も対応をしなければ、サーバーが落ちることになります。

仮に全国放送で視聴率が10％だったとして、
100人に1人が気まぐれにスマホを見たとしても
120,000,000×0.1×0.01 = 120,000人

単純計算で12万人のユーザーがアクセスしてくることになります。
実際に、内容や時間帯にもよりますが全国ネットの放送では
近しい数字の人数がアクセスしてくることが分かっています。

20年9月の技術顧問就任当時は、まさにそうしたテレビ放映にサーバーが耐えられないということがあり、、、テレビはインフラエンジニアにとっては「宿敵」とも言えます笑

　　　　　　　　　　　　　　シューイチ放映時のリクエスト数推移

ー最近はかなり安定しているように思いますが、どのように対応していったのですか？

もともとEC CUBEというPHPのパッケージでできていました。
EC CUBEの詳細については触れませんが、9月当時は状況的に課題がかなり多く、
細かいところは省きますが下図のような構成でした。
ECというデータの変更に比べ読み取りが多いワークロードに対して問題点をクリアにしました。

【問題点】
CDNが使われていない
　└　CDNキャッシュが使えていない
　└　すべての負荷がWEBインスタンスにかかる
セッションがDBで管理されている
　└　DBに高負荷がかかる
Aurora MySQLクラスタじゃなくてRDS MySQLを使っている
　└　冗長性がない。MySQLを使うのであれば、Aurora MySQLのほうが高速
DBのクエリ結果をキャッシュしていない
　└　毎回RDSにクエリ投げてるので高負荷
サーバーが高負荷になると、管理画面も止まる
　└　日常業務が全くできなくなる・・・。

それから、どれくらいリクエストと帯域（通信料）があるのかを知る必要があるので
ざっくり計算すると・・・

2台だと、180リクエストしか捌けないということになります。。
つまり、リクエスト数を下げて、同時接続数を上げる必要がありました。

ー解決策はそれぞれどのように？

CDNが使われていない
　⇒　CloudFrontを配置
　　/assets/ や /uploads/などを指定して、画像、JS、CSSなどはすべてS3から配信してキャッシュさせる
　⇒　CloudFrontは150Gbps捌けるので容量は問題ない
　⇒　オリジンWEBサーバーへのリクエストは1ページあたりほぼ1になる

セッションがDBで管理されている
　⇒　Memcached（ElastiCache）でセッションの管理を行う

Aurora MySQLクラスタじゃなくてRDS MySQLを使っている
　⇒　Aurora MySQLに移管。冗長性とクエリの高速化を達成。
　
DBのクエリ結果をキャッシュしていない
　⇒　Memcached（ElastiCache）でクエリ結果をキャッシュする

サーバーが高負荷になると、管理画面も止まる
　⇒　/[pathToAdmin]/のpathに関しては、別のALBを立てて、別インスタンスを。

そのほかにも、下記のような対応を行いました。

普段は小さいインスタンスで、直前にサーバー増設作業をする
　└　TV用の構成は非常にコストが高いのでなるべく時間を短くする。
ALBの暖機申請
　└　ALBは基本的に自動スケールですが、急激にアクセスがある場合はスケールが間に合わない可能性があります。事前にAmazonに申請しておく。
インデックスページやよく見られるページの静的化
　└　TOPページやクエリの重たいページはできるだけ静的にしてCloudFrontにキャッシュさせる
　└　デメリットもある（SOLD OUTが一覧でわからなくなる）
キャッシュのTTLを長くしておく
　└　短いとキャッシュスタンピードが起きる
　└　テレビ放映は得てして5分～10分以内にアクセスが集中しがちなので、1時間ほどに設定しておく。
事前に人力でページを徘徊しておく
　└　キャッシュミスが起こるとキャッシュスタンピードが起こるのでテレビ放送数分前にメンバーでよくみられるページを見てキャッシュさせる

ここまで対応すると、サーバー1台あたりでどれだけ捌けばいいかが見えてくるのでそれに応じて
Apacheのpreforkチューニングを行います。

ーとはいえ、想定外につながりにくくなることもあると思いますが？

最後の最後の砦として、それでも502や504エラーが出てしまったときの対策として、
逆手にとってクーポンを発行するページを用意し、アクセスできなかったユーザーもフォローできる仕組みを作っています。

これらの結果、数々のテレビ放映にも耐えられるサーバー環境を実現し、
万が一アクセスできなかった方にもできるだけストレスのないサービスに進化させられたと考えています。

とはいえ、まだまだクラダシのサービスが成長していくと、状況は変わっていきます。
テレビのようなバーストするトラフィックに対しての残課題としては、下記があります。

• EC CUBEのデフォルトのコードでは、Aurora　MySQLのMasterSlave構成に対応してないので、
  トランザクションがないSELECTクエリに対してはReadOnlyのクラスタを見に行くように変更する。
• クエリのキャッシュが長いので、確率的キャッシュを導入してなるべく最新のデータをユーザーに提供する。

参考: 確率的キャッシュ
https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf
https://www.slideshare.net/RedisLabs/redisconf17-internet-archive-preventing-cache-stampede-with-redis-and-xfetch


常に先回りをして理想の姿に少しでも近づけて行きたいと思っているので、「我こそは！」という方はぜひエントリーしてみてください！