CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日 CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない
Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive]
この記事は ピクシブ株式会社 Advent Calendar 2015 10日目の記事です。 qiita.com こんにちは。Androidアプリエンジニアのいとおちゃんです。 高校生の頃からアルバイトとしてピクシブに入社してから4年目になりました。昨年は若手アルバイトと名乗っていましたが、気づいたらもう大学生です。最近はpixivマンガアプリの開発をしています。 今回はAndroidアプリ開発の話ではなく、個人的に最もアツいと感じているLet's Encryptを使ってnginxでHTTP/2サーバを立てる話をします。 Let’s Encryptを使おう Let's Encryptを利用すると、無料で認証されたSSL証明書を簡単に発行することができ、ここ最近話題を集めています。今月、Let's EncryptはようやくPublic Betaになりました。そこで、まさに今が旬ともいえるLe
![Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4567d7f0adf50228a21ca960797fc34b9d5e6d7/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Fitochan315%2F20151209%2F20151209202000.png)
NginxでHTTPS：ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス | POSTD
NginxでHTTPS：ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス 今日のインターネットの世界では、一般的な静的Webサイトも含め、 全てのWebサイト に、強固で安全なHTTPSのセットアップが必要となります。この記事は、Nginxセキュリティをどのようにセットアップするのかに関するシリーズのパート2です。 パート1 は、Webサーバに有効な署名証明書をセットアップする話で終了しました。しかしこれには、最適な設定とは言い難い、デフォルトのNginxの設定を使用していました。 この記事を読み終えれば、SSL Labsのレポートで、A+の評価を獲得できる安全なHTTPSの設定ができます。それだけでなく、追加でいくつかの微調整も行い、パフォーマンスそしてUXも向上させていきます。 ここに掲載した記述やコードの抜粋の他にも、すぐに使
nginx で Too many open files エラーに対処する
nginx では1プロセスで多くのアクセスを捌くので、アクセス数が増えるとToo many open filesエラーが発生することがあります。 ここでは対処法と調べた内容を残しておきます。 1. fs.file-max の確認 まず fs.file-max の値を確認しておきます。fs.file-max は、システム全体でのファイルディスクリプタの上限数となっており、この値以上のファイルディスクリプタは確保することができません。 現在設定されている値は以下で確認できます。 $ cat /proc/sys/fs/file-max 167488 通常は上記の値で問題無いと思いますが、もしこの値が不足しているようなら設定値を更新します。 $ sudo -s # echo 320000 > /proc/sys/fs/file-max # cat /proc/sys/fs/file-max 320
nginxをロードバランサとして使うときのTips | Borders Labs
はじめまして、ボーダーズでインフラを担当しています。高田です。 みなさんはWebサーバーといえば、何をイメージするでしょうか。 ひと昔前、Webサーバーの代表格といえばapacheでしたが、近年はapacheとおなじくらいnginxが注目を浴びるようになってきています。 ...はじめまして、ボーダーズでインフラを担当しています。高田です。 みなさんはWebサーバーといえば、何をイメージするでしょうか。 ひと昔前、Webサーバーの代表格といえばapacheでしたが、近年はapacheとおなじくらいnginxが注目を浴びるようになってきています。 nginxのメリットはなんといっても軽量かつ高速であることです。 ボーダーズでもnginx を主にロードバランサとして利用しています。 アンケートを大量に配信したときなどアクセスが集中した場合でも、アンケートを中断させることなく実施するためです
nginx最大パフォーマンスを出すための基本設定 | Node.js技術
解説 worker_processes auto; - Nginx本体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf
Express / Socket.IO をスケールアウトしてみよう
20140826.md Express / Socket.IO をスケールアウトしてみよう Seiya Konno Works at Uniba Inc. (http://uniba.jp) https://twitter.com/nulltask https://github.com/nulltask https://fb.me/nulltask スケーラビリティとは システムの規模に依らず機能を適応できること リクエストに対するスケーラビリティ アプリケーションコードに対するスケーラビリティ Express https://github.com/strongloop/express 言わずと知れたウェブアプリケーションフレームワーク 右も左もわからなかった頃 => app.js の肥大化 メンテナビリティの低下 アプリの規模が大きくなってもメンテナビリティを確保したい Mounting
Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews
Randen Pederson 大規模なシステムであれば使っているであろうリバースプロキシ。 セキュリティや稼働率の観点からみて利用することは非常にメリットは高いです。 ただ、社内や周りであまり知見がなく、 「動くからいいや」という理由でApacheをそのままWebサービスの一次受けとして利用されている方も多いと思います。 動くという目的からすれば確かにその通りですが、ただ一枚リバースプロキシを入れるだけで ぐっと運用効率、稼働率も拡張性も上がります。 1. ルーティング処理の簡略化 例えばRESTfulな一般的なAPI構成を作りたいと思った時に以下のようなURL構成になると思います。 http://api.something.com/search/v1/item/list.json?cid=xxxx&gid=xxxxx もしアプリケーション側のルーティングしか知らなければframewor
nginx で SSL解きリバースプロキシな設定のお作法 - Qiita
フロントでSSL解いてリバースプロキシってのは割と良く作るのだけど、あれれ...? nginx, ときどき httpd で出来てたことが出来なくて「えっ？」てなる。今後のためにメモ。 server { listen 80; server_name www.example.com; rewrite ^ https://$http_host$request_uri? permanent; } server { listen 443; server_name www.example.com; ssl on; ssl_certificate ... ssl_certificate_key ... : location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header
nginxでメソッドごとにリクエスト数制限を掛けたい - 酒日記 はてな支店
アプリケーションでどうしても捌けない量のリクエストが一時的に押し寄せてしまう場合、アプリケーションサーバが死ぬのを避けるために GET は制限を掛けたいが、POST はリトライが面倒なのでなるべく通してあげたい、というような要求を nginx で処理できるかどうか。 実装として一番望ましいのは GET は 100 req/sec で制限 (超えたら503) POST は無制限 のようにメソッドごとに別々の制限を掛けることだったのですが、とりあえず HttpLimitReqModule を使うことで、メソッドごとに同一の上限を設定することはできました。 http { limit_req_zone $request_method zone=method:1m rate=100r/s; server { listen 80; location / { limit_req zone=method;
Ubuntu Upstart | NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
rhodecode1.4.4を試してみた #tokyomercurial
世の中GithubEnterpriseでpullrequest方式での開発が 一部では標準化しているんじゃないかと思われる今日この頃いかがお過ごしでしょうか？ とは言うものの、いくら有用性を語ってもそうそう導入されるような世界じゃないですよね？高いし。 せめてGithub/Bitbucketの有料アカウントを…と思ってもそれもねぇ…って世界ですよね(´；ω；｀) そんな僕達がPullRequest方式で開発したい！！そうだRhodeCodeがあるじゃないか！! という私やあなたみたいな方にお届けするエントリーですｗ あ、ちなみに件名に#tokyomercurial を追記した理由は特にありません。 あえていうなら、このツイートがあったので…ぐらいかな？ @3a3k 詳細を確認しようとしたら解決したみたいで何よりです。詳細を公開してもらえると、(バッド？)ノウハウ共有の上でも有難いです(笑)
ApacheとNginxの性能比較でevent_mpmの本気を見た
はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践nginx〜メルカリの場合〜
1000万ダウンロードアプリ『メルカリ』を支える技術
Sass を今すぐ実務で使おうよ！ « LINE Engineers' Blog
nginx proxy based on host when using https
nginxの紹介
