entry-header-eye-catch.html
entry-title-container.html

entry-header-author-info.html
Article by

特別コラボ企画の爆発的アクセスを捌き切るエンジニアリングと腕力

こんにちは。ピクシブの社内エンジニア職横断組織「エンジニアギルド」マネージャのbashです。主にエンジニア採用プロセスを取りまとめています。

ピクシブでは複数の事業部があり、様々な専門性を持ったメンバーが集って事業領域にフォーカスする体制を取っています。各事業部にいる技術のキーパーソンがどのような考えでエンジニアリングを進めているのかを紹介したいと思います。

先日、pixivFACTORYというプロダクトで特別コラボ企画があり、普段とは違ったスペシャルな体制でリアルタイム対応が行われました。その件をテーマとして、pixivFACTORYのプロダクト開発と運用を主導しているFACTORY部エンジニアhayaと、ピクシブの全サービスインフラを横断的に管理しているインフラ部SREチームリーダーkonoizに、当日対応や準備の様子について話を聞いてみたいと思います。


まずは自己紹介をお願いします。

haya

pixivFACTORY の開発を担当しております齊藤隼人です。2016年入社以降ずっと、クリエイターの活動を応援するプロダクトの開発に専念しています。 普段はグッズのデザインシステム、プレビュー生成処理の開発に加えて、注文システム、受発注システムの開発・メンテナンスも行っています。

konoiz

全サービスのインフラの整備や運用を担当しています山根です。齊藤と同じく2016年入社で、いわゆるインフラエンジニアとしてずっとピクシブのサービスを下支えしてきました。

技術的な背景について教えていただけますか?

haya

pixivFACTORYはグッズ作成サービスです。システム的には様々な機能から成り立っていますが、特徴的な部分としては、グッズ作成プレビューをその場で生成して、いわば見積もり時に仕上がり概要を確認できる点があります。

factory.pixiv.net

実物に極力近いプレビュー画像をリクエストに応じて素早く作り出す必要があるため、この機能は一般的なWebサービスよりコンピューティングリソースが必要です。

inside.pixiv.blog

このプレビュー機能はコアとなる部分ですが、pixivFACTORYは基本的にクリエイター向けサービスであるため、総リクエスト中のトラフィックとしてはある程度限られています。一年を通して激しいスパイクはしないため、日々のアクセス傾向に合わせて余裕をもったキャパシティプランニングをしています。

pixivFACTORYのチームでは、Datadogで主にページのレスポンスタイムから重いエンドポイントを見極めて、必要に応じてチューニングを行っています。

konoiz

SREチームではコンピューティングリソース全体をサービス横串でモニタリングしています。 外形監視と、メモリ、CPU、ストレージなどの個別のメトリクスのグラフ化と、それぞれのしきい値超過によるアラート捕捉で、安定的なサービス稼働を支えています。

haya

今回は特別コラボ企画としてライブ配信が予定されており、その時間帯に普段とは桁違いのユーザが来訪する期待がありました。そして今回の企画では普段はpixivFACTORYを使っていない方やそもそもこのサービスを知らなかった方がグッズ作成を行うことにつながるため、処理時間がかかるプレビュー作成リクエストが多くなり、普段とは全く違うアクセス傾向になると考えました。

そのため、明らかに普段のキャパシティでは対応しきれない読みが立ったため、事前対策をインフラ部に相談しました。

どういうチーム体制で取り組みましたか?

haya

pixivFACTORYそのものは、わたしの所属するFACTORY部という部署で開発運営を行っています。 ビジネスメンバー、エンジニア、デザイナ、コミュニティマネジメントと様々な職種のメンバーで成り立っており、この企画時点では部の責任者であるマネージャを含めて9名、内エンジニアは3名です。

konoiz

インフラ面はわたしが率いているインフラ部SREチームが4名体制です。 この件はわたし自身が主導し、他のメンバーにはサポート役として手の回りきらないことを支えてもらいました。

事前対策としてはどのようなことを行いましたか?

haya

まずはピーク時のアクティブユーザ数と、そのうちのプレビュー機能利用数の想定を行い、同時にプレビュー機能を使うことができる限界数を見積もりました。要はプレビューがボトルネックと想定して、その機能に集中して考えることにしました。

konoiz

プレビュー機能はメモリーを多く使うため、メモリの増設を行いました。バックエンドではUnicornを用いていることもあり、多くのUnicorn Workerが必要になることもメモリ増設の根拠となりました。

加えて、pixivFACTORYの大きな連携先であるBOOTHとのエンドポイントとなるサーバをスケールしました。データベースへの依存が少ない箇所で効果的にスケールできるポイントで、かねてからリクエストを受けていて、今回の企画によって実施タイミングが早まったかたちです。

当日はどのような様子でしたか?

haya

実は当日にも追加で対策を打ちました。

事前対策で相応の手は打ったものの、やはり配信時にpixivFACTORYがサービス不能になるとライブに合わせたコンテンツがなくなってしまうため、ユーザにもクリエイターにも悪い体験を及ぼしてしまう。事業的にも大きな損失になってしまいます。 クリエイターがコンテンツを届けること、広くユーザにものをつくるたのしさを味わってもらうことをより確実にしよう、より万全を期そうというマネージャ判断で、急遽追加対策を講じることとなりました。

行ったことは、リクエストの多いエンドポイント単位で他サーバにオフロードすることです。

実は当日のプレスリリースの反響から、プレビュー機能のボトルネックで対策の中心に据えたメモリより先に、CPU使用率の大幅な伸びがみられました。重いリクエストであるプレビューではない、純粋なトラフィックの総量が圧倒的に増えたためです。

このまま配信がスタートした場合、サービス全体のレスポンスタイムが悪化します。またグッズ作成の要であるプレビュー機能はターンアラウンドタイムが長くなってWorkerプロセスが枯渇しやすくなり、リクエストを捌けなくなってしまいます。 しかしpixivFACTORYはオンプレミス環境で運用しており、しかもそのプレビュー機能の特殊性から他サービス用のサーバに比べて特別な構成を組んでいて、調達には相応の時間がかるということは認識していました。

konoiz

たまたま他用途で構築しかけていたサーバがあり、プレビュー以外ならばそのサーバで十分耐えきれるスペックだったため、急遽FACTORY用に転用し、プレビュー以外の通常のWebアプリケーション的な処理を選別してそちらに流すようにしました。 これによってモノリシックアーキテクチャなアプリケーションのままで、既存のpixivFACTORYのサーバではプレビュー機能のためにコンピューティングリソースに確保しつつ、トータルのトラフィックを扱えるようにしました。

haya

なお、他にも一見現実的ではないものもふくめて、複数のプランを構想して動けるようにしていました。

では配信自体はスムーズに迎えることができたわけですね?

haya

実は...配信が始まった時点ではまだサーバの準備が間に合っていませんでした。そこから徐々に既存サーバ群のCPU使用率が上がっていきましてやきもきしていたのですが、ちょうど当初想定キャパシティに達するかどうかのときにキッティングが完了し、一息つくことができました。

その後は一部レスポンスが少し遅れるときがありましたが、サービス全体としては稼働状態を維持していました。

konoiz

配信中はずっとサーバのキッティングに、割り振るべきエンドポイントの絞り込みに、その後の運用対処にと貼り付いていたので、配信の様子そのものは全然みることができませんでした。 チームメンバーにはリソースのモニタリングや各種ミドルウェアのインストールなど、個別作業を巻き取ってもらったため、もっとも大事な部分に集中することができました。

haya

わたしたちの他にも、コミュニティマネージャーたちには実際に実機でのサービス確認をとってもらっていました。 また複数のシナリオを想定して、いざというときは緊急アナウンスを発信する体制を整えてもらっていました。

konoiz

配信が終わって状況が収束してから社内Slackを見て知ったのですが、自部署・他部署問わず配信を見守っていたり、配信に合わせて実況やリアクション飛ばしをして盛り上がっていたようでした。

配信を緊張感高く見守るpixivFACTORYチーム

部署・職種関係なく、わくわくしながら配信をたのしむ社内メンバー

配信内で「今日の案件は何点?運営さんから100点もらいました!」的なシーンで💯で溢れる会社Slack

こうやって部署を超えて熱く関わってくれるのはとてもうれしいことです。また、いざというときは部署や職種を超えてトラブルシュートに駆けつけてくれるので心強さもあります。

haya

ただ、技術的には手放しで💯とは言い切れないと思っています。 事前のキャパシティプランニングと実際の乖離、利用シナリオによるボトルネック変動、スケール容易性やキャッシュフレンドリー性の考慮、稼働率の効果的な高め方など様々あります。

konoiz

FACTORYの特性上どうしても社内の他サービスに比べて特殊なことも多いので、FACTORY部と一緒に解決を進めていきます。


hayaさん、konoizさん、ありがとうございました。

今回紹介したpixivFACTORYをはじめ、ピクシブでは多くのウェブアプリケーションを擁しており、フロントエンドエンジニア、バックエンドエンジニア、そしてインフラエンジニアが中心となって企画・開発・運用を行っています。 それぞれ新たな仲間を募集しています。本ブログの内容をご覧いただき、興味をお持ちの方は下記募集ページよりエントリーをお願いいたします。

hrmos.co hrmos.co hrmos.co

まずカジュアル面談希望の場合はこちらから応募をお願いします。 www.wantedly.com www.wantedly.com

bash
経営企画補佐 兼 エンジニアリング室長。 2013年に広告配信エンジニアとして入社し、その後開発マネージャ、関連会社CTO、VPoE、コーポレートIT立ち上げと、支える活動をひたすら切り拓く挑戦を繰り返してきた。 現在は、solver & right handの経営企画分野スタッフ業とEngineering Office運営業を持つ。 タイプとしては知略が使える本能型。キャッチフレーズは「真面目なSE、真面目にSE」。 プライベートでは #RubyMuscleMixin ハッシュタグで健康のためのウェイトトレーニングに日々取り組んでいる。 個人の公式FANBOX https://bash0c7official.fanbox.cc/
20191219010821
haya
2016年ピクシブ株式会社に入社。 主にRuby on Railsでサーバサイドアプリケーションの開発を行っている。「ものづくりがもっと楽しくなるアイテム制作サービス - ピクシブファクトリー - pixivFACTORY」の開発を行っており、ビジネスロジック開発の他、2D・3D画像処理の自動化を手がける。
konoiz
2016年ピクシブ株式会社に入社。 インフラエンジニア。インフラ部SREチームリーダー。