オープンワーク株式会社、インフラエンジニアの小沢です。
今回は今まさに実施しているオープンワークの広告プロモーションとそれに伴う負荷対策について書きたいと思います。オープンワークのエンジニアの業務を少しでも知って頂ければ幸いです。
私の事
大学卒業後、某ソフトウェアメーカーで品質エンジニアとして6年ほどパッケージソフトの開発に携わったのち、ごにょごにょ。縁あって2015年にオープンワーク（当時はヴォーカーズ）に入社して以来、インフラエンジニアとしてオープンワークのサーバー構築/管理をメインに仕事をしています。
IaC、コンテナについてスキルアップしたい今日この頃な1児の父です。
オープンワークの広告プロモーション
弊社は2019年5月23日に「株式会社ヴォーカーズ」から「オープンワーク株式会社」へ社名変更をおこないました。それに伴い、5月27日から交通広告(駅や電車)を中心として大々的な広告プロモーションが行われています。
※詳しくは弊社プレスリリースをご覧ください
せっかくのプロモーションもサイトが止まってしまっては効果が半減してしまうので、インフラチームとしてはサイトを停止させない為に対策をしています。
サーバー構成
弊社ではインフラにAWSを採用しています。
構成としては一般的なWebウェブサービスの構成となっており、
WebサーバーはApache、DBはAmazon Aurora（MySQL互換）、全文検索にElasticsearch、セッション用にMemcached、キャッシュサーバーにRedis、CDNにFastly, CloudFrontを併用しています。
負荷対策
今回の方針として「基本的には何があってもサイトを停止させない」としています。
もちろん不測の事態が起こる可能性もありますが、できるかぎり事前準備する事として、対策は主に下記２点になりました。
- リクエスト増加量を見積もってサーバーを増強する
- 上記対策をしてもリクエストを受けきれない場合の為にサイトを止めない方法を整備する
構成を見直して根本的に解決したい部分もありますが、プロモーション開始までの時間の制約もあるので、出来ることで対策を講じる事にしました。
アクセス数の見積もり
増加するアクセスに対して必要なサーバーを準備する為、できるだけ正確に増加量を見積もります。 広告の出稿場所が複数あるので個別に見積もって最大リクエスト量を求めていきます。
見積もり算出において前提として下記のように仮定しました。
- 流入の8割は一日の内の6時間に集中する
- 流入したユーザーは平均 3.6 ページ閲覧する
日経電子版
日経電子版はトップページやサイドバー、モバイルのインフィードなどに広告が掲載されています。
想定クリック数：12,500 Click / Month
想定流量：12,500 * 3.6 * 80% / 30 / (6 * 3600) ≒ 0.056 Request/sec
NewsPicks
NewsPicksではオープンワークの特設タブが設置されていました。（～6/3）
想定流入数：4,800 Click / Week
想定流量：4,800 * 3.6 * 80% / 7 / (6 * 3600) ≒ 0.09 Request/sec
交通広告
今回のプロモーションでもっとも規模が大きいのがこちら。
新宿駅のプロムナード（〜6/2）を筆頭に新宿、渋谷、丸の内などの都内の主要駅、JR、東京メトロの電車内、などにオープンワークの広告が掲載されていました。
サイトへの流入は広告出稿の内容や規模、またSNSなどでの拡散度合いなどによってかなり幅があるらしいですが、過去の事例をもとに最もアクセスが伸びた場合を想定して算出します。
想定PV数：9,000,000 PV / Day
想定リクエスト量：9,000,000 * 80% / (6 * 3600) ≒ 333 Request/sec
テレビ取材（ニュース番組）
大規模なプロモーションを行うことを事前にプレスリリースしているので、ニュース番組などで取り上げられる可能性もあります。ですので、テレビ放映によるサイトへの流入量も算出が必要です。 結果、実際にWBS（ワールドビジネスサテライト）に取り上げられることに…！
算出方法についてはテレビ放送に向けての負荷対策(AWS x Rails の場合)[前編] を参考にさせて頂きました。
下記のように仮定し計算します。
リーチ人数 ：4000 万人 視聴率 ：4 % サイト流入率 ：1 % ページ／セッション：3.6 PV/Session
想定PV数：4000万人 * 4% * 1% * 3.6 = 57,600 PV
このPVが放映開始から5分間に集中すると仮定すると、
想定リクエスト量：57,600 / 300 = 192 Request/sec
対応すべき最大リクエスト量
各媒体からのアクセスのピークは重複しないとすると、
日経電子版 ：0.056 Request/sec NewsPicks ：0.09 Request/sec 交通広告 ：333 Request/sec テレビ放映(WBS) ：192 Request/sec
増加するリクエスト量は
333 Request/sec ！！
オープンワークの最近のピークタイムのリクエスト量はおよそ「90 Request/sec」なので、
今回備えるべきリクエスト量は、
333 + 90 = 423 Request/sec
このリクエスト量の負荷が掛かったとしても、サイトが問題なく稼働し続けられるようにサーバーリソースを確保します。
サーバーリソース見積もり
オープンワークのインフラチームでは、サイトの性能確認、ボトルネックの把握/解消を目的として定期的にパフォーマンス検証をしています。
本来であればサーバーリソースを増強しつつ負荷を掛けて、必要となるサーバーリソースを確定させるべきですが、期限との兼ね合いで十分な検証時間を確保できなかった為、2019年3月に実施したパフォーマンス検証の結果をもとに必要なリソース量を見積もることにしました。
パフォーマンス検証の結果(2019/3)
WEB ：m5.xlarge × 12 DB ：db.r4.4xlarge × 2(Writer/Reader) Memcached ：m4.xlarge × 1 Redis ：r4.large × 1 Elasticsearch：m4.xlarge × 6 この構成で処理可能な最大リクエスト：260 Request/sec
リクエスト量に比例してサーバーリソースも必要と仮定すると、「423 Request/sec」を達成するために必要なリソースは、
423 / 260 ≒ 1.63倍
「基本的には何があってもサイトを停止させない」方針という事もあり、+αの余力を持たせる為にパフォーマンス検証時の「2倍」のリソースを用意する事にしました。
ざっくり過ぎて正確なリクエスト見積もり必要だったのか？とは思いつつ、サーバーリソースは下記のように決定しました。
WEB ：m5.xlarge × 24 DB ：db.r4.4xlarge × 2(Writer/Reader) Memcached ：m5.2xlarge × 1 Redis ：r5.xlarge × 1 Elasticsearch：m5.2xlarge × 6
- インスタンスサイズまたは台数をスケールさせることでリソースを2倍に設定
- DBについてはもともと余剰にリソースを確保していたので変更なし
- ロードバランサーは急激なリクエスト増の可能性があるのでAWSサポートから暖気申請
これで「520 Request / sec」まで耐えられる！
はず、、、
リソース増強以外の対策
サーバーリソースは余力も含めて確保しますが、それでも何かしらの要因で負荷が高くなってしまう可能性もあるのでいくつか回避策を用意しておきます。
- ALBのパスベースルーティングを利用して一部リクエストを逃がす 特定のpath、UA、IPアドレスなどを条件に一定量のアクセスの向き先を静的リソース（サイトが混みあっています）などにすることでサーバー負荷を低減させます。
- サイト全体をメンテナンスモードにする サイトを訪問して頂いた方に迷惑をかけてしまう事になるので最後の手段ですが、いざという場合はサイトをメンテナンス中にします。サーバーリソースのボトルネックがあればその場で増強を検討、変更の余地が無ければアクセスが落ち着くまで待ちます。サーバーが停止して長時間復旧できない事態になるよりはマシという場合に利用する想定です。
なにかあった時の対応策もなんとか準備できたので、あとは当日を迎えるばかり。
いざプロモーション初日
27日早朝から都内各所に広告が！
たくさんの方に見て頂けることを願いつつ、インフラチームはサイトを監視します。
早朝～夕方まで
サイトの状態はというと、、、
特に問題もなく普段と変わらないアクセス量でした。（まぁ始まったばかりで認知されていないので、当たり前と言えば当たり前ですが。）
WBS放映
夜を迎え、いよいよWBSの放送が近づいてきました。 事前の情報によると、他に大きなニュースがあった場合は放映されないとか、、、
番組予告にはしっかりと「100社の社員評価が読める図書館？」の文字が！
番組開始から待つことおよそ30分、、、ついに！！
ｷﾀ━━━ヽ(∀ﾟ )人(ﾟ∀ﾟ)人( ﾟ∀)人(∀ﾟ )人(ﾟ∀ﾟ)人( ﾟ∀)ノ━━━!!!!
サイトアクセス状況はこんな感じ。
瞬間的に約2.5倍程度（目測）に増えていましたが、障害/速度劣化など起こることなく無事に乗り切ることが出来ました。
アクセスのピークは放映開始後1-2分頃、10分後には普段と変わらない状態に落ち着いていたので、事前に備えていないとなかなか対応は難しそうな印象です。
初日まとめ
日中のアクセス
初日という事で大きな変化はありませんでした。日が経つにつれて全体的に増加すると思いますので、引き続き注意して観察したいと思います。
テレビ放映時
前週同一時間帯（23時台）とアクセス数を比較することで、テレビ放映時の増加量を算出します。
5/20
リクエスト数：221,045 ピーク値 ：107 Request/sec
###5/27 リクエスト数：269,405 ピーク値 ：290 Request/sec
増加したリクエスト数が「48,360（見積もり：57,600）」なので、想定よりやや少ない結果でした。 ピーク値については想定値とほぼ同一となっている事から、思っていた以上に放映と同時に集中してアクセスされたことが分かります。 次回以降はこの点に注意したいと思います。
前週の同一時間帯とのアクセス比較（増加も減少もあっというまでした）
オープンワークのプロモーションはまだまだ続くので、最後まで油断せずに乗り切りたいと思います。
今後の課題
今回の対応で改めて認識した課題がありましたので、今後、解決策を検討していきます。
- 瞬間的なリクエスト増加には対応しきれない 今回は事前にリクエスト増加が見込まれていたのでサーバーを増強して待ち構えることで対応できましたが、突然リクエストが増えた場合はオートスケールを待つことになります。 起動にはある程度時間が必要なので、起動するまでの間、サイトパフォーマンスが下がる可能性があります。ある程度は仕方ない部分ではありますが、いかに素早くスケールできるかが今後のポイントです。
- スケールに限界のあるリソースが存在する 一部のリソースにおいてインスタンスサイズを大きくすることで増強する方法をとりました。 インスタンスサイズには上限があるので、今後の事を考えると台数を増やすことでスケールが可能な構成にしていく必要があります。
おわりに
オープンワークでは理念、VISIONに共感し、一緒にサービス価値を高めてくれる仲間を募集しています。ブログやサービスを通して、興味を持っていただけたら、一緒に働いてみませんか？
(※本記事は2019年6月7日にWantedlyに掲載した記事を移行したものになります)
