はじめに
株式会社つみきの久松と申します。映画・ドラマ・アニメのレビューサービス「Filmarks（フィルマークス）」のSREとして、サーバーサイドの様々な改善に取り組んでいます。また、インターネット上ではkariaというハンドルネームで活動しております。
今回はFilmarksにおける高トラフィック対策についてご紹介します。
Filmarksとは
FilmarksはiOS/Android向けアプリとWebで映画・ドラマ・アニメのレビューサービスを提供しており、累計レビュー数は2億件を突破しています。
サーバーサイドのインフラにはAWSを利用しており、ECS on EC2の構成を採用しております。EC2インスタンス1台につきECSコンテナ1個が起動する仕組みとなっており、EC2インスタンスをスケールアウトさせることで、簡単により多くのトラフィックを処理することが可能となります。
FilmarksにおけるEC2 Auto Scalingの活用
Filmarksのトラフィックの特徴として、映画を観る方が多いタイミングに連動してリクエストが伸びるという点が挙げられます。週末や長期休暇のタイミングではリクエストが増加するため、平日に比べてキャパシティも余裕を持たせる必要があります。
意外なところでは、大型台風が接近するタイミングと週末が重なるとリクエスト数が大幅に増加するという事象がありました。これは、外出を控えて自宅で映画を楽しむ方が通常より多くなるためと考えられます。
一方、私が入社した時点でFilmarksのEC2は台数を固定して運用されており、ピーク時間帯に合わせて台数を増減させるスケジュールのみが組まれていた状況でした。
そこで、EC2 Auto Scalingのターゲットトラッキングスケーリングポリシーを導入し、CPU使用率の平均値に応じて自動でEC2の台数が増減するようにしました。これにより、台数やスケジュールを細かく調整する手間をなくし、安心して週末を過ごすことができるようになりました。また、リクエストが少ないときは自動でシャットダウンされていくので、無駄なくコストパフォーマンスのよい負荷対策を行えることにも繋がっています。
スパイクアクセスの課題と対処
対策に頭を悩まされたのは、通常時の数倍のリクエストが突然押し寄せる、いわゆる「スパイクアクセス」と呼ばれる事象でした。
課題
一般的にスパイクアクセスが発生するのは、プッシュ通知を一斉に打ったり、テレビCMを放映するなど自社のプロモーションに伴うケースが考えられます。しかしFilmarksでは完全な不意打ちのスパイクアクセスが時折発生しており、SNS検索やアクセスログ調査から以下の傾向があることがわかりました。
- テレビで話題の映画が放送されエンドロールまで達したとき、アプリが一斉に起動される
- テレビ番組で有名タレントがオススメの映画作品を挙げたとき、Web検索で流入が発生する
上記のようなテレビ放送のタイミングを事前に予測するのは困難です。また、テレビ放送に伴うリクエスト数増は、ほんの1〜2分で数倍に膨れあがる性質を持っています。ターゲットトラッキングスケーリングポリシーはこのような突然のリクエスト急増には応えてくれません。
現在のFilmarksの構成では、EC2のCPU使用率が増加してから新たなEC2インスタンスが起動完了しサービスインするまでに10分程度かかります。これにはEC2起動やプロビジョニングなどの時間が含まれ、AWSの仕様上完全にゼロにすることはできません。突然のリクエスト急増によりEC2の台数が増加するより早くキャパシティを使い切ってしまうと、レスポンスの劣化を招きます。
スパイクアクセスに対してターゲットトラッキングスケーリングポリシーでの対処が難しいことはAWSのセミナー等でも言及されており、私が確認した範囲では（非常に古い資料で恐縮ですが）以下のスライドにて言及がありました。
対処
このような予測困難な事象についても、サービスの信頼性を保つためには何らかの対処を考えなくてはなりません。Filmarksでは以下の様な対処を取りました。
まず、各テレビ局の放送枠を調査しリクエストが集中しやすい作品がよく放送される放送枠をピックアップしました。「リクエストが集中しやすい」とは以下全ての条件を満たす作品です。
- Mark!やClip!の数が多い作品
- 地上波で初めて放送される作品
- 19時台や21時台に放送開始される作品
「Mark!」とは作品を観たユーザーの鑑賞ログ、「Clip!」とはその作品を観たい！と思ったユーザー向けの記録機能です。Mark!やClip!の数が多い作品はユーザーの注目度が高いため、地上波初放送やゴールデンタイムといった要素が重なるとリクエスト数が増加する傾向があります。
ただ、毎週放送される作品を見て予測・調整を行うことは工数的に困難である（トイルになってしまう）ため、スケジュールは毎週固定で設定することにしました。また、時間帯・EC2の台数共に十分に余裕を持ったスケジュールを組むようにしました。台数が多すぎる分には、多少コストはかかりますがサービスに影響を与えることはありません。
こうすることで、話題の作品であっても特にレスポンス遅延を発生させることなくリクエストを処理できるようになりました。
また、ピーク時のリクエスト数に対してAWSインフラの各種リソースにどの程度余裕があるかを月1回程度確認し、余裕がない場合はスケールアップ（インスタンスサイズの引き上げ）を実施するという対策も行うようにしました。これは現在も継続して実施しており、CloudWatch, Aurora Performance Insights, NewRelicといったオブザーバビリティツールが活躍しています。
これらの対策により、完全な不意打ちのスパイクアクセスについてもほとんどのケースで耐えられるようになりました。
おわりに
本稿ではFilmarksの高トラフィック対策についてご紹介しました。どんなときでも安定したサービス提供を行えるよう今後も取り組んでいきます。
つみきではこのような高トラフィック環境を支えるエンジニアを募集しています！
Discussion