はじめに こんにちは、VRoid部所属のエンジニアのyueです。 この度VRoid Hubで3Dモデルの配信サーバーの見直しを行い、技術選定から始めRustとZstandard (zstd)を採用した実装に切り替えました。 結論から見るに従来のNode.js製サーバーと比べて以下のことを実現しました。 最大のレスポンス時間が 1.5　~　2.5s から 300　~　400msまで低下 平均のレスポンス時間が 700　~　800ms から 150　~　200msまで低下 サーバーのCPU使用率が ~　50% から ~　10%まで低下 docker image のサイズが ~　346mb から ~　21mb程度まで削減 配信されるファイルサイズが平均 10 ~ 20% 軽量化されました レスポンス時間 CPU使用量 (上からAVG(MAX), AVG, AVG(MIN)) メモリー使用量に関し

こんにちは。福岡オフィスエンジニアの @petamoriken です。趣味でFloat16Arrayのponyfill1を公開しECMAScriptに入れてもらうように活動していたところ、喜ばしいことに2023年5月のTC39会議にてStage 3となりました。折角なのでその経緯を書いていこうと思います。 ECMAScript excitement 😉@TC39 advanced these proposals this week 🎉 4️⃣ Atomics.waitAsync 4️⃣ RegExp v flag 4️⃣ Well-Formed Unicode Strings 3️⃣ Decorator Metadata 3️⃣ Float16Array 2️⃣ Base64 for Uint8Array 2️⃣ Promise.withResolvers 2️⃣ TimeZone C

アドプラットフォーム事業部 アドプロダクト部 データチームでアナリティクスエンジニアをしているucchi-です。普段は主に、pixiv Adsという広告ネットワークのデータ周りを開発しています。 ads.pixiv.net 今回は、pixiv Adsで採用している、Lookerの埋め込みダッシュボードについて紹介します。 はじめに ピクシブでは全社的にLookerを使用しています。Lookerを使うことで、BigQueryに保存されている品質の高いデータを気軽に分析することができ、社内の仮説検証や意思決定に役立っています。 一方で、Lookerは社内の分析用途だけではなく、社外へのデータ提供にも活用できます。 具体的な手段はいくつかありますが、pixiv Adsでは、「シングルサインオン（SSO）組み込み」という形式で、クライアント向けの広告管理画面にLookerのダッシュボードを埋め込ん

CTOのharukasanです。 pixivをはじめとするピクシブが運営している各サービスにおいて、ユーザーの投稿した作品を不当な目的を持って取得する行為から守ることは、プラットフォームとして重要な責務のひとつであるとピクシブは考えています。これまでもピクシブでは、作品が不当な目的で大量に取得されないよう機械的なクローリングを検知し、ブロックするために様々な手段を講じてきました。この記事では、現在行っている対策と、今後実施していくために現時点で取り組んでいる施策についてご説明します。 English version is available here これまでに実施している不当な目的での作品大量取得への対策について ピクシブでは不当な目的で作品を大量取得されることを防止するため、基本的な対策に加え、様々なソリューションを導入しています。ここでは特徴的な技術についていくつかの例を紹介します。

10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し

こんにちは、4月からBOOTH部になったorekyuuです。 この記事では、転属後の一番大きな成果である、BOOTHで発生する大量の注文(ピーク毎分約1400件)を整合性を取りつつ高速にさばく改善について解説します。 BOOTHが抱えていた課題 まずはBOOTHが抱えていた課題について説明します。 BOOTHでは販売開始時刻が事前に予告されていた場合などの理由で瞬間的に決済が集中し、サーバーが大量の注文に耐えきれないケースが度々ありました。 その原因は在庫の処理にありました。擬似コードですが、注文の処理は以下のようになっていました。 def checkout! ActiveRecord::Base.transaction do 商品の悲観的ロック # 在庫数を同時に編集しないようにロックを取る 商品の在庫の減算処理 注文を確定済みにする 決済の請求APIを叩く end end 上記のコード

※本記事に出てくるアニメーションは全てCSSで作られています はじめまして、新卒エンジニアの yui540(@yui540)です。普段は、pixivFANBOXというサービスのCSSエンジニアをしています。 今回は、私がコーディング&ページ演出のアニメーションを担当させていただいたPIXIV TECH FES. の LP(第一弾)の CSSアニメーションの実装方法を一部解説します。 第一弾 conference.pixiv.co.jp 第二弾 conference.pixiv.co.jp とその前に、「PIXIV TECH FES.って何？」という方もいると思うので、簡単にご説明します。 PIXIV TECH FES. は、私たちピクシブのエンジニアが普段からお世話になっている方や、 お話ししてみたい方をお招きして、サービス開発で得た技術的知見とピクシブの未来についてお話しするテックカンフ

福岡オフィスで課題解決チームに所属しているエンジニアの @petamoriken です。弊社では drawr というサービスを11年間提供していましたが、2019年12月2日13:00をもってサービスを終了することとなりました。詳しくは drawr 特設サイトを御覧ください。 drawr はサービスの中核が Flash の技術で成り立っています。特にイラストを描くドロー画面と、投稿された作品の筆跡再生機能がブラウザにプラグインとして搭載されている Flash Player を使って提供されています。 drawrのサービス終了にともない、以下の機能を新規開発・提供しました。 投稿作品一括ダウンロード機能 お絵かきコミュニケーションサービス「pixiv Sketch」への引っ越しツール drawrの描き味を再現したドロー機能「シンプルドローモード」(pixiv Sketch で利用可能) その

こんにちは、セキュリティエンジニアのkoboです。ピクシブでは2016年より脆弱性報奨金制度を運用していますが、2018年度に入ってから報奨金の増額や新しいプラットフォームへの参入など、これまでに増して注力しています。本記事では、最近のピクシブの脆弱性報奨金制度の動向と実際に報告された脆弱性の例を紹介していきます。 pixiv Bug Bounty Programの概要 期間: 2016/04〜 支払い済み報奨金総額: 300万円程度 報告総数: 294件 ピクシブでは2年半ほどに渡って脆弱性報奨金制度を実施してきましたが、2018年に入ってから脆弱性報告の件数、クオリティ向上の為に2つの重要な変更を行いました。 報奨金の増額 脆弱性を報告するハッカーに対してこれまでよりも高いインセンティブを提供することで報告を促すため HackerOneへの参入 世界最大のバグバウンティプラットフォーム

皆さんこんにちは。最近はGoでコードを書いてることが多いですが、実はRubyコミッターという肩書も持っているusaです。 Rubyといえば、毎年クリスマスの頃に新バージョンがリリースされる事が多いですね。 もちろん今年も、Ruby 2.6のリリースが予定されています。 新しいRubyではどんな変更が入るのか、ということに興味がある方も多いかとは思いますが、そういった記事は探せばたくさん見つかると思います。 本稿ではそういう話ではなくて、Rubyにどんな変更が入るのかがどうやって決められているのか、ということを紹介します。 Ruby開発者会議 普段から皆さんの目に触れるWebサービスなどで広く使われているRuby。もちろん、ピクシブ社内でも様々なサービスがRubyで作成され、ユーザーの皆さんに向けて提供されています。 コミッター さて、当然のことながら、Ruby自身もプログラムですから、誰か

2020/12/25 編注：この記事は2018年当時のエピソードです。現在はこの方法では審査に通らなくなりました。 おばんです、給料日であることをいいことに、にじさんじくじに課金しまくったBOOTH iOSエンジニアの @danbo-tanaka です。 平素よりBOOTH iOSアプリをご贔屓いただき、ありがとうございます。 みなさんもうアプリをアップデートしていただけましたでしょうか？ 8月16日(木)にリリースしたv2.12.0では、これまで要望の多かった有料ダウンロード商品の販売を実装しました！🎉 これまでiOSアプリにおいて、デジタルコンテンツの購入に対応したアプリは多くありませんでした。それはAppleが用意したアプリ内課金（通称Apple税。手数料として30%をAppleに支払う必要がある支払い方法）を通さなければ、基本的にデジタルコンテンツの取り扱いが許されなかったという

ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。 前編ではpixivを常時HTTPS化する前にやった前準備として、広告、画像といったリソースをHTTPSに切り替える際の手順を紹介しました。 pixivを常時HTTPS化するまでの道のり（前編） - pixiv inside 後編では実際にpixivのアプリケーション自体を常時HTTPS化していく手順を紹介します。 従来のHTTPS配信 pixivはPHPアプリケーションを実行するアプリケーションサーバー(Apache/mod_php)の前段にnginxを配置する構成になっています。以前からセキュリティ的に重要なページはHTTPSで提供しており、nginxでHTTPS終端処理を行っていました。HTTPSで応答する場合はアプリケーションサーバーにX-HTTPSヘッダーを付けてプロクシーしています。 具体的には以下のよ

ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。主にpixivの技術的な改善をしていますが、広告チームも兼任しているので広告周りの開発もしています。 今回pixivの常時HTTPS化を担当したのでやったことを紹介します。 pixivをHTTPS化した理由 現在のインターネット全体の流れとして常時HTTPS化が進んでいます。エドワード・スノーデン - Wikipediaが暴露したNSAの事件発覚や 公衆無線LANの利用拡大により、通信経路上でユーザーの個人情報を保護することがインターネット全体として非常に重要になってきました。Googleが行っている調査によると、HTTPSページの閲覧時間はウェブ全体の利用時間の3分の2にも及びます。 それだけではありません。ブラウザに新しく追加されるAPIや機能（HTTP2/WebRTC/ServiceWorkerなど）はHTT

こんにちは。 pixivの投稿ユーザ向けグロースを担当しているエンジニアのsestaです。 4月28日、ISUCON6本戦の問題を作ったedvakf、catatsuyと一緒に第2回社内ISUCONを開催しました！ ISUCONとは3人までのチームで参加し、与えられたウェブアプリケーションのチューニングを制限時間いっぱい行い、パフォーマンスに基づいたスコアで競いあうコンテストです。 去年の社内ISUCON開催記事に引き続き、 今年は当日の様子のレポートとベンチマークなどの全体構成について紹介します。 当日の様子 今年は38人もの社員が参加し、その中にはなんと、ビジネス職の新卒や人事（！？）も参加していました。 競技時間は10:30から18:00までと本番のISUCONと同様にしました。 10:30によーいどんで始めた社内ISUCONですが、前半はなかなかスコアを伸ばすチームが現れませんでした

おはようございます、ImageFlux開発責任者のharukasanです。3日前の4月14日、ピクシブではPawooが急にリリースされることになりまして、ここ数日はずっとPawooサーバにログインしていました。このPawooサーバ、既にピクシブの監視体制に入っており、アラート受信後インフラエンジニアが障害対応できる仕組みを整えています。案の定、リリース直後の15、16日は週末にもかかわらずアラートを受け取ることになり、サーバにはりつくことになったわけです。どんなシステムであろうとアラートを受け取ったら対応する、それが我らインフラエンジニアです。 pawoo.netの構成 さて、それではまずPawooの構成を見ていきましょう。digすればわかりますがpawoo.netはAWS上に構成されています。数百台以上の物理サーバを常時運用しているピクシブであっても、さすがにこんなにはやく物理サーバは用