2017/06/22 21:01:41
masalib
CDNの切り替えは怖いな〜やることないと思うけど切り替え時の確認ポイントに追加する
2017/06/22 21:16:01
paradisemaker
うひょーこれはシビれる
2017/06/22 21:17:12
shinagaki
失敗事例を公開する姿勢は素晴らしい
2017/06/22 21:17:42
hyaknihyak
原因も影響範囲もきっちり説明しててえらい
2017/06/22 21:23:34
ktakeda47
CDN とお漏らし
2017/06/22 21:30:28
daruyanagi
なるほど
2017/06/22 21:34:05
neotag
やっぱこういうのは外形監視しかないか。。
2017/06/22 21:50:38
murasaki11
わかる
2017/06/22 21:52:22
razokulover
ひゃぁ〜〜
2017/06/22 21:55:46
gragragracia
あるある
2017/06/22 21:58:33
wh11e7rue
こわい
2017/06/22 22:02:19
ch3cooh393
全部漏れたっぽい
2017/06/22 22:05:09
tomiyanx
そんなことが発生していたとは
2017/06/22 22:06:37
masutaka26
つらい
2017/06/22 22:13:40
pismo
原因の詳細情報を開示している。コレはいいね。
2017/06/22 22:16:14
halfrack
極めてインパクトある経験の共有で価値がある、ありがたく他山の石としたい・・・。追記:動的ページも含め全部 CDN 通すのは DDoS 対策として一般的な手法ですね。
2017/06/22 22:17:20
konisimple
メルカリの件、CDNの切り替えで Cache-control の扱いが変わったのが原因だったとのこと。個人情報流出はダメだけど、エンジニアとしてはちょっと気持ちわかる。そしてここまで詳細に原因書いてて凄い。
2017/06/22 22:26:56
W53SA
ここまで詳細に書いてくれると参考になるけど、どこのCDNが斯様な挙動をしたのかも書いてほしかった感はある
2017/06/22 22:27:45
netcraft3
同種の問題は自分も過去に経験あったな…。CDNとNginxあるある。
2017/06/22 22:31:33
tofu-kun
俺もこれやったことがある。
2017/06/22 22:33:59
kuracom
詳細な原因と対策が明示された良い報告。ありがたい。
2017/06/22 22:38:16
manaten
ユーザー個別の情報もCDN通すんだ・・・という感想 / WAFとか証明書のために使う、というのを教えてもらった。なるほど
2017/06/22 22:39:35
motchang
あー。個人情報ではないけどいらんキャッシュは露出させちゃったことあるわ…(´・_・`)
2017/06/22 22:41:34
mh615033891
Cache-controlでアクセスコントロールしようとするのがそもそも変なんだけど。
2017/06/22 22:42:43
fire_0218
[] CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
2017/06/22 22:43:55
Andrion
調べたところ現時点でメルカリは「Akamai」を使ってる模様。ただ原因は「Cache-Control: no-cache」の用途を間違ってることなんだけど。
2017/06/22 22:44:23
rlans
メルカリで電話番号とか住所漏れたら過去にトラブった人から嫌がらせされそうだよなぁ。どんな対応するんだろう。中の人大変そうだね。
2017/06/22 22:45:43
hideo54
詳しいw お疲れ様です。
2017/06/22 22:45:53
takazoom
問題が起きて解決したらtechブログで公表する取り決めになってたんだろうか?なってたら方針・姿勢が凄いし、なってなかったら判断のスピード感が凄い。
2017/06/22 22:46:32
kitokitoki
有効期限を保持している点は PCIDSS から外れていますね
2017/06/22 22:46:57
monmon225197810
有り難すぎる情報公開
2017/06/22 22:47:26
yosida95
CDN を切り替えたら "Cache-Control: no-cache" がキャッシュされて意図しないユーザーに配信されてしまった / これを公開する姿勢は誠実だなぁ
2017/06/22 22:48:28
tengo1985
エンジニアブログを自社ドメインでやらないのか。
2017/06/22 22:51:39
fellfield
個人情報や決済まわりはCDNに載せないほうが良い気がする。画像やJSなど静的ファイルの配信に使うものだと思っていたけれど。
2017/06/22 22:53:59
kiri3
なるほどな
2017/06/22 22:59:17
user8107
こういう事例を共有してくれるのは助かる。
2017/06/22 23:00:21
nikoli
直接関係ないけど、hostsファイルの編集というところに懐かしさを覚えた
2017/06/22 23:01:02
marshi
公開するのが良いしありがたい。
2017/06/22 23:03:09
Makots
古いcdnキャッシュの漏洩か
2017/06/22 23:04:45
ockeghem
『Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました』<具体的な説明ありがたい
2017/06/22 23:05:24
showii
ポジティブなコメント多くて怖いね~。しかしこの場合って不正アクセスにはならんのかしら。
2017/06/22 23:06:25
s-tomo
キャッシュされてたわけだから表にある人数は「他の人のデータが見えてしまった」人数でであって他人に対して表示されちゃった方の人数は大幅に少ないものと思われる(汗
2017/06/22 23:06:53
otherworld
全てCDNを経由してるということは、CDNの中の人は個人情報を見ることができるということか…。そういう設計が普通なのかな。
2017/06/22 23:07:08
electrica666
個人情報周りの取り扱いが甘かった感がそこはかとなく。
2017/06/22 23:11:08
ming_mina
メルカリユーザーの半分くらいにはよくわからない解説なきがする…
2017/06/22 23:15:12
fensuke
CDN切り替えって色々起こるなー
2017/06/22 23:15:44
sonots
技術的詳細
2017/06/22 23:16:05
shag
カード番号の下4桁がCDNから流出するってことは大本はカード番号普通に保持してるんだ。非保持化待ったなしだけど、本人であっても下4桁しか表示しない仕様なのは不幸中の幸いというか安全弁が正常稼働したというか。
2017/06/22 23:16:06
Kosecci
どの点がダメで、どう改善するかを示した点は評価
2017/06/22 23:19:02
djkaz
所詮メルカリだし、どーせ形だけのお詫びなんだろうと思ったら、教科書のような細かい、というか技術的バックグラウンドを必要とするレベルの内容だった。運営的には色々言われてるけど、しっかりしてる印象を受けた
2017/06/22 23:19:13
testedquality
原因を詳細まで発表していただけるのは非常に真摯な対応だと思う。
2017/06/22 23:21:36
beerbeerkun
うーん、イマイチこのブログ読んでも分からんのは自分のCDNノウハウが足りないせいなのかな
2017/06/22 23:23:35
adeu_w
キャッシュ周りの適切な制御はマジムズい。こういうのどうやってテストするべきなんだろうか。
2017/06/22 23:24:02
dowhile
こわいこわい
2017/06/22 23:24:07
ohesotori
CDNってやっぱりそういうことになるのか。どうやってんのかなーって思ったら・・・
2017/06/22 23:26:40
fukumura
問題発覚から解決までの時間が1時間ちょっとで、このレベルの障害でこの対応スピードはすごすぎる、一方でCDNにここまで情報載せちゃってたの?感はある(けど載せてたかはわからない。)
2017/06/22 23:27:33
yass
" キャッシュをしないのは Cache-Control: private が含まれている場合のみとわかりました。Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました "
2017/06/22 23:28:34
ravelll
メルカリほど優秀なエンジニアが集まる会社でもこういうことが起きると思うと、改めて気を引き締めなければなあと思う。
2017/06/22 23:31:03
ngyuki
Cache-Control: no-cache だとキャッシュはされるから?
2017/06/22 23:31:24
aodifaud09
うおおおおおおおお。なるほどなるほど。なるほど~!って感じ。これは公開してくれてありがたい。
2017/06/22 23:33:38
nacrie
現場で報告を受けてる気分になった。対応の早さと情報公開の姿勢に逆に好感が持てるIR。
2017/06/22 23:34:41
Chisei
CDNごとに異なる設定があると思うので事前のリスク事項とテストパターンの洗い出しとテスト実施という王道を踏むしかないと思いつつじゃあリスク提示のときに思いつくかと言われると時と場合によっては自信がない。
2017/06/22 23:35:09
tanakh
そもそもそういう情報をcdnに通すもんなんですか(´・_・`)
2017/06/22 23:36:55
jaguarsan
id:shag クレカの場合、他に識別子無くて下4桁使わざる事が多いので非保持化とは関係ないかも
2017/06/22 23:38:37
t_masuda
検証が雑すぎでは、、「切替前の検証では手元のマシンのhostsファイルを編集し、数回アクセスを行い問題なく動作していることを確認」
2017/06/22 23:38:47
chuukai
(読む前)メルカリどんなポカをやったんだよwww→(読んだ後)そ、それは災難でしたね…/門外漢だけど、昔は有名なサイトでも他者のアカウントのページが表示されたことがあったような気がします
2017/06/22 23:41:38
taketyan
動的なページに CDN 通すの怖過ぎないですか... / なるほど DDoS 対策
2017/06/22 23:42:01
yug1224
デカい事故ほどチョンボだったりするんだよなぁ
2017/06/22 23:42:57
a_micchan
キャッシュ制御をインフラ設定に頼りっきりではダメですよ、ちゃんとアプリでも見てね、と理解
2017/06/22 23:43:21
itsumonotakumi
こういうの見る度に「企業が運営してるから安心」とかは無いことに気付かされるんですよね。自衛すると言っても限界があるし、罰則が制度かされないのでしょうか?
2017/06/22 23:43:50
chaz_21
CDNだったのか… それはちょっと気の毒
2017/06/22 23:45:52
wushi
恥を忍んで原因を公開した点は評価する
2017/06/22 23:47:22
ya--mada
cdnて、気軽に変えるものなんだな。客は災難だけどメルカリは災難じゃなくてミスだわよなぁ。だよね、やっぱおかしいよね
2017/06/22 23:49:47
Cujo
「動かないコンピュータ」ならぬ「働きすぎたコンピュータ」?
2017/06/22 23:50:14
koseki
いいレポート。前に Pixiv もキャッシュ設定ミスで個人情報漏洩させてたよね。自分も危なかったことある。/認証やら決済やらを CDN 通したくない気持ちはあるけど、ドメイン分ける必要があり、それはそれで難しいのです
2017/06/22 23:51:10
anoncom
自分たち(アプリケーション側)では十分に注意していてもIaaSやPaaSの仕様もしっかり理解していないと痛い失敗する事があると。勉強になる。/それにしても動的ページすらCDN配信してるのか
2017/06/22 23:51:24
bobbyjam99
CDNの切替こえー
2017/06/22 23:52:48
konbu13
ここまで技術情報を説明してくれるのが素晴らしい。
2017/06/22 23:52:49
HILOKI-T
技術的原因まで詳述された「お詫び」は門外漢による不当な罵倒を排除する効能があることがよくわかった。
2017/06/22 23:53:56
awkad
災難だけど、こんなこと起こってもさらっとHPで説明するだけでいいんだから気楽だよな。そりゃ新しい技術ガンガン使える。同じことを銀行や公共が起こしたら即新聞、〇〇省からお達しがくるのに。
2017/06/22 23:54:44
maruware
良いレポート。ひとごとじゃない。
2017/06/22 23:57:18
ozuma
静的ファイルじゃなくて、個人情報ある動的ページもCDN使ってるのに驚いた。画像ファイル配信とかだけかと思ってたよ
2017/06/22 23:58:54
mar33
せっかくだからキャッシュ制御のアンチパターン本でも出品していただきたい
2017/06/22 23:59:51
isano
わぁ
2017/06/23 00:02:08
mkusunok
こりゃ事前に詰めるのが大変なパターン、早期に技術解説を出す姿勢は好感を持てる。気をつけないと
2017/06/23 00:03:32
takohaka
CDNがCache-controlヘッダー見てCDN内のキャッシュを制御していたということ(・∇・)?
2017/06/23 00:04:23
endor
ここまで情報が公開されるのはすごい。監視だけを強化しても再発防止はできませんが。
2017/06/23 00:04:27
Futaro99
あるある
2017/06/23 00:11:51
droplet81
障害
2017/06/23 00:13:26
lizy
同一URLでユーザ毎に内容の異なるページをキャッシュしていた……?
2017/06/23 00:15:25
sabacurry
問題を起こしたときにその後の対応で好感度上がるやつだ
2017/06/23 00:17:58
nachurie
門外漢だけどやらかしたあとにやらかしたことの説明きちんとしてると印象が全然違う
2017/06/23 00:18:11
lambdalisue
なんでこの手の情報が CDN 通ってんだろうという話は置いとくとして、 ちゃんと説明されてるし良い。真摯な対応だと思う
2017/06/23 00:22:15
rti7743
キャッシュするのは画像やcss,jsなどの静的コンテンツにmimeでしぼったほうが良かったのかも。問題は最近はフォントや音声などの種類が増えている所だな
2017/06/23 00:22:34
RM233
エンジニアを尊重してる企業なのは分かった。
2017/06/23 00:24:28
Mint0A0yama
事はどうあれ、これだけ大きな事故の原因を具体的に、それも当日のうちに公開するスピード感はすごい。
2017/06/23 00:32:45
ttop
なるほど
2017/06/23 00:34:10
tatsumack
それぞれのCDNプロバイダを知りたい
2017/06/23 00:36:01
kibitaki
田中に「テ・ス・ト・し・た・の・か・よ!」とスリッパで頭叩かれるレベル。旧世代IEの挙動に鍛えられた年寄りは本番移行時セッションデータや受け口、Cookie等全て殺す工程と道具は体で覚えてる。原因迄CDNに甘えるな
2017/06/23 00:37:27
kei_1010
エンジニアにしたみたら悪夢のような事態。ゾッとしただろうな。
2017/06/23 00:43:32
Fuetaro
なんだかよくわかんないけどこんなに詳しく経緯を記載するのって珍しくない?
2017/06/23 00:53:26
irodori_kotori
こういう事例を公開してくれるのはありがたい。参考になる。
2017/06/23 00:54:12
civitaspo
丁寧に説明してくれて助かる
2017/06/23 00:55:14
cl-gaku
これはこわいな
2017/06/23 00:58:45
akghuaiooajt
詳しい!この対応はあり。
2017/06/23 01:02:47
inazuma2073
メルカリユーザーの何割が理解できるのかな…
2017/06/23 01:15:27
dogusare
めも
2017/06/23 01:17:43
ZuiUrs
CDN切替時にはちゃんと必要な仕様は読むよう覚えておこう
2017/06/23 01:18:37
blue1st
CDNは色々落とし穴あるよなー、一部だけバイナリ壊れてたりとか。
2017/06/23 01:21:02
OKIIZO
akamai→fastlyの移行失敗ドア破壊事例っぽい。 https://docs.fastly.com/guides/tutorials/cache-control-tutorial
2017/06/23 01:21:27
snowlong
人員の増加が質の低下を招いているフェーズなんですかね
2017/06/23 01:21:52
miz999
たとえばhttp://b.hatena.ne.jpというアドレスにアクセスした時、みんなが違うページを見てるっていう現実って当たり前すぎて忘れてしまいがちだな
2017/06/23 01:30:18
ntfs
Akamaiはヘッダコントロールは穴が多いのでパネル設定限定だったけど、CloudFrontやFastlyはこういう穴を承知の上でコントローラブルにする感じ。ただしほとんどの利用者に理解されてないのはLLN絶頂期から変化なしか。
2017/06/23 01:30:34
f-miyaji
SRE頑張ってる感
2017/06/23 01:30:42
ichinotani
日本の組織は隠ぺい体質なところが多くて辟易していたなか、この対応は本当に素晴らしく感じられる。しかしCDNを経由して生成したHTML渡すというのは一般的なのかな?
2017/06/23 01:35:38
schwer_metall
好感の持てる情報開示
2017/06/23 01:39:50
unagiga
技術担当者は信頼出来る人間だった、という話。失敗はしたが。
2017/06/23 01:40:11
cateching
情報公開の姿勢が評価されてるのはわかるけど、再発防止策にツッコミが入ってないのが驚き。要はもっとちゃんと試験やれって話でしょうに。
2017/06/23 01:42:37
temmings
うわあ、って事例。事前に(おそらく手動で)数回しか確認してないんかい、とは思うけど、正直に記述してあって好感は持てる。
2017/06/23 02:01:25
tackman
うひー同業者としてこわい、ちゃんと仕事したけどこうなったっぽいのが…
2017/06/23 02:07:56
nagapad
ピーク帯は含んでないとはいえ、Webのアクティブユーザーは54000人ってことか
2017/06/23 02:09:14
ffwfwtfwt4fwt4
これは良いが被害者への個別お詫びに項目毎の人数など何故報せないのだろうか?お詫び文面に誤解が生じる記載があり混乱が生じている。別項目に見えるが「購入履歴」には住所が表示されるので事実上の住所流出と同義
2017/06/23 02:09:15
catatsuy
技術的なことをちゃんと共有する姿勢素晴らしい
2017/06/23 02:12:19
note103
詳しい内容を簡潔な構成で説明していてとても良いと思うけど「お客さまのメルカリでの体験をよりよくするため」だけ変だと思った
2017/06/23 02:28:58
kiichi55
ひぇぇ
2017/06/23 02:59:12
urr7t0nnolce7pest9ofa0eon
もともとはユーザー側で毎回リロードしなくても良いようにしてたってことですよね?でも、結局仕様の未確認・・・?
2017/06/23 03:02:30
mamacake
リリースまでの検証環境の運用や実効、フローの妥当性がヌルかったから起こった事故だろうに、それに対する言及や改善策が付いているわけでもなく、直ぐ言ったからえらい、みたいなブコメ多くて本当どうかしてる。
2017/06/23 03:19:46
yooven
なんでも売れるわ、個人情報もメルカリで出品か??
2017/06/23 03:44:26
ANNotunzdY
ひとごとじゃない
2017/06/23 04:04:29
fashi
新しいCDNで使えるようになった機能を試したら使い方間違えてて使えてなかったってことか
2017/06/23 04:23:24
mimura-san
こまかに開示していく姿勢には好感もてる。きちんと対応がとれる企業が増えてそれが当たり前になり、隠蔽体質の企業が駆逐されていくといいな。
2017/06/23 05:01:11
Fivestar
HTTPのキャッシュ系を使いこなすのは結構むずかしいなあと思う。
2017/06/23 05:07:36
hotu_ta
GitLabと着実に同じ道を歩もうとしてる気がするので…
2017/06/23 05:10:55
sakuya_little
とてもありがたい。
2017/06/23 05:44:05
rsakamot
あららら
2017/06/23 05:56:27
jnoir
好感度上がるとか言ってるのは関係者か技術にしか興味ないエンジニアな人達だから気にしなくてよいかと。一般ユーザからの好感度は間違いなく下がってるのでアンチメルカリな人は素直に喜べば良いかと。
2017/06/23 05:59:11
zakochan
でも運営はunk
2017/06/23 06:11:03
LawNeet
Expiresヘッダうんぬんの段落の「no-cacheオプション」のcacheはCDNキャッシュ、「キャッシュ無効時」のキャッシュはブラウザキャッシュ、その次の段落以降は全部CDNキャッシュの話ということ?ド素人には分かりづらかった。
2017/06/23 06:24:01
Chinosoko
赤の他人に見られても害はない、とか思ってたら、組織のプロキシサーバーにキャッシュされて知人に見られたりすることも。これは理解が難しい問題らしく、Yahoo! JAPANに指摘した時の対応は温く、事後の公表もなかった。
2017/06/23 06:28:34
bathrobe
どこのCDN?
2017/06/23 06:39:28
TakiTake
X-CacheヘッダーでHITしたかどうか見れなかったんかな?AkamaiだとPragmaヘッダー付けてリクエスト投げると、X-Cache返ってくる。 Pragma: akamai-x-cache-on
2017/06/23 06:42:02
a-know
素晴らしい
2017/06/23 06:47:45
hogetahogeko
CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは Cache-Control: private が含まれている場合
2017/06/23 06:53:45
tbpg
仕組みができたら公開してもらえそうだ。※個人情報ではなく仕組みをね "外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組みを導入します。"
2017/06/23 07:01:44
havanap
事前検証が足りなかったような雰囲気
2017/06/23 07:10:17
hazeblog
キャッシュ制御難しいんだよなあ
2017/06/23 07:10:56
junmk2
それでエンジニアは怒られて終わりなわけ?何か事が起こる度に原因分析して再発防止策打ってそれは良いことだけどリスク負わなすぎじゃないの。他の職種なら大ポカやらかしたら何かしら処分されるのが普通なんだけど
2017/06/23 07:12:53
Rinta
素早い対応ご苦労様。技術的にはなるほどねーという感じ。
2017/06/23 07:25:20
wata88
なるほどなーっとなる
2017/06/23 07:34:08
aoi-sora
IPAのサイトに、同じ内容の解説があったけど。https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/405.html /メルカリの方は、微妙に仕様が把握できてないような気がする(素人の印象だけど)。
2017/06/23 07:34:32
shoh8
切り替え先のCDNのキャッシュ仕様を誤認してて、意図しないキャッシュがCDNに残ってたということか。知見知見
2017/06/23 07:36:37
tetsuya_m
魑魅魍魎感のある出品物で話題になるメルカリだけどこういう時に技術情報をしっかり開示してくるのか、とても興味深い
2017/06/23 07:38:50
proverb
これもメルカリ開発チームの素晴らしいブランディングに繋がっている
2017/06/23 07:40:10
igtm
マイページもCDN通すんだ。。こわいな
2017/06/23 07:41:32
gfx
知見の共有ありがたい…。お疲れさまでした。
2017/06/23 07:47:54
cco
Cache 怖い。Java だけじゃなくて httpd も面倒見てるんだけど、Cache-Control は設定組合せとブラウザ実装によって挙動が異なるから、重要な情報は別対処も必要なこともある認識
2017/06/23 07:48:00
gendou
詫びポイント出るのかな?
2017/06/23 07:48:03
THAL
なるほど。
2017/06/23 07:49:53
psyii
公開する姿勢は素晴らしいんだけどこの内容で当事者が当日に公開することかっつうとちょっと。カスタマーサポート部門が泣いちゃうよ
2017/06/23 07:51:39
tazyamah
こういうのが怖くて動的ページへのアクセスをCDN通すように組んだことがないので勉強になる
2017/06/23 07:52:19
tanayuki00
ミスしたことは(あってはならないことだけど)しかたない。その後の対応で評価がガラリと変わる好例。
2017/06/23 07:56:12
marisatokinoko
この場合privateが正しいような気はするもののno-cacheでwebサーバーに問い合わせ来てないならそれは辛い。外部サービスが仕様通り動いてるかの検証どこまでするか難しい。個人情報絡むのでこの件はテスト不足感あるけど。
2017/06/23 07:57:54
magnoliak
凄まじいスピード感で知見がまとまってる
2017/06/23 08:00:55
likepop
これ、ウチにも来てた。技術視点からも大事だろうけど、こんなん見てもわかんないし。言い訳されてる気分。
2017/06/23 08:08:43
luccafort
CDN切り替えでそんなことが?という印象が先にあって読後はこういうことをきちんと報告するその企業姿勢に好感持つ。
2017/06/23 08:09:35
uturi
ここまで技術的な内容を公開するとは思わなかった。
2017/06/23 08:10:25
l83DK
メルカリのイメージ変わった。(但し技術部門の
2017/06/23 08:12:30
gami
あるあるすぎて、こわい
2017/06/23 08:12:34
keidge
最近トレンドの技術的側面から見た原因公開事例。web系
2017/06/23 08:13:35
yantzn
わかりやすい
2017/06/23 08:14:54
mori99
CDN、知らなかったorz。そんなことになってるのか
2017/06/23 08:16:23
lli
こっちの方が詳しかった。なるほど。
2017/06/23 08:28:39
psfactory
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
2017/06/23 08:29:37
quick_past
LINEもだけど未熟なサイトはバグが出きってしまうか、担当の技術者がレベルアップするまで使わないことにしてる。
2017/06/23 08:33:34
u4k
コーポレートサイトでお詫びし、技術ブログで詳細を説明する。しかも対応速い。
2017/06/23 08:38:34
mini_big_foo
こんなに詳しく説明してくれるんだすごいな。テックブログとは言え
2017/06/23 08:38:55
kattton
有用な失敗事例だ…
2017/06/23 08:40:36
yulalila
知見共有ありがたい。サーバの設定とか本当魔物なんですけど。
2017/06/23 08:42:14
Mist
メルカリの印象がよくなってしまったんじゃ。
2017/06/23 08:42:55
hpdaikilif
メルカリは個人情報まで売り出しのか 対応は丁寧でよかったね
2017/06/23 08:46:56
raysato
技術的な情報を公開するの素晴らしいですね。対応も早い。
2017/06/23 08:46:56
K2ICE
“Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました。”
2017/06/23 08:48:37
tyru
詳しい技術的な原因の詳細についても書かれてある
2017/06/23 08:49:14
SigmaG2
CDNの仕様差分かー
2017/06/23 08:51:38
zetta1985
Cache-Controlヘッダのno-cacheは地雷
2017/06/23 08:53:48
Akaza
これは怖い
2017/06/23 08:54:16
auient
httpとキャッシュ難しい
2017/06/23 08:54:25
T-norf
なるほど。単純に言えばテストの問題だけど、クラウド含めて100%コントロールできないL7の経路増えてるので、テストは入念にやった方がいいって話よね。
2017/06/23 08:58:54
sai0ias
お詫び文にここまで技術的な話載せる必要あるのか?と思ったけど、よくわからんクレーマーの牽制にはなると思った。それはそれで「意味が分からない」っていうクレームが来そうだが。
2017/06/23 08:59:06
hiroomi
”外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組みを導入します”ログ見ながらテストケース実行か。
2017/06/23 09:05:28
BritanJP
メルカリのくせに生意気な!ww
2017/06/23 09:06:49
gusyazero
はわわ…(((((((・・;) こんな形で流出とかありうるのか…他人事じゃないので覚えとこう…
2017/06/23 09:10:57
syunnchang
やらかさない事よりやらかしたあとどうするかが大事って感じだなーしっかりしてる
2017/06/23 09:13:20
touka_tt
知見だ
2017/06/23 09:20:22
naopr
個人情報流出があったのに逆に会社の評価を上げているのではないかとすら思われるメルカリすごい
2017/06/23 09:22:22
shngmsw
原因は違うけどAWS備え付けロードバランサ(ELB)のIPアドレス再利用間隔が短すぎるせいでイントラのシステム内で他人のアカウントでログインされてる事象が起こったらしいのでAWS切り替え案件のSIerは注意されたし。
2017/06/23 09:22:43
enemyoffreedom
「Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました」
2017/06/23 09:23:36
hevohevo
仕様だと、privateだと各ユーザーごとにキャッシュ(他ユーザーと共有しない)だよね?つまり各ユーザーではキャッシュしちゃう。Expiresを参照してくれないなら動的ページ無理なのでは。そういうもの?
2017/06/23 09:24:05
kuroaka1871
紋切り型でないところが良い
2017/06/23 09:25:31
kamip
きゃわわ
2017/06/23 09:26:21
yutamoty
このような正しいエンジニアから、あのようなカオスなサービスが生まれたのかという気持ちです。
2017/06/23 09:31:37
kazukazu0404
ミスを共有してもらえるのは、ありがたい…
2017/06/23 09:32:14
bettychang
"本エントリでは技術的観点から詳細をお伝えさせていただきます"
2017/06/23 09:34:57
tettekete37564
ここって運営サイドはアレだけど技術サイドは本当に同じ会社かと思うほど高い技術力と良い文化持ってるよね。スライドとかも勉強になる資料多くていいねと思う
2017/06/23 09:36:08
nomuken
今一番、悪い意味で注目されて襟を正してなきゃいけなトコだけに、やっちゃった感がハンパないね #メルカリ
2017/06/23 09:36:49
radiatastories
今後、社内外の人にとって有益な情報。
2017/06/23 09:37:24
hgn117
失敗した事はしたこととして共有してくれるのはとても有り難いし素晴らしい姿勢。
2017/06/23 09:38:58
pawpuro10
URL単位ではなくてヘッダでキャッシュコントロールしてるのが災いしてしまったのか。。
2017/06/23 09:39:51
ifttt
まず背景の明度が変わってチカチカしないところがえらい
2017/06/23 09:41:05
napsucks
CDNにマイページをキャッシュさせちゃったのか。あり得ないほど間抜けだけどミスの可能性としてはあるあるすぎるな。
2017/06/23 09:42:06
calcan
cacheかぁ…やらかしには違いないけどcache周りはややこしいし検証しづらいし同情する。
2017/06/23 09:43:59
khtno73
公開する姿勢は立派だけど、凡ミスではある。
2017/06/23 09:44:49
ay-movie
色々なビジネスチャンスが広がっている中、セキュリティが追いついていない印象が…ネット社会自体で情報の防衛意識を高めないと
2017/06/23 09:44:55
u1_113
該当しちゃったよ…
2017/06/23 09:48:04
runpel
CDNが原因の個人情報流出は最近よく聞くので気をつけないと。。
2017/06/23 09:50:27
hdampty7
というか、マイページ系をキャッシュする可能性がある構成にしていることがそもそもの問題かなぁ。負荷対策と情報流出のリスクをどうバランスして判断したのかが気になる。
2017/06/23 09:57:14
fukuiretu
せめてこれがキャッシュに含まれていなければねぇ... “名前・住所・メールアドレス・電話番号 銀行口座情報、クレジットカードの下4桁と有効期限”
2017/06/23 09:57:15
miyashitank
えらいぜメルカリ
2017/06/23 10:01:27
t-wada
"Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様になっておりました" "外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組みを導入します"
2017/06/23 10:05:13
ork_shinnosuke
失敗事例を公開するのは業界全体にとって有益。メルカリの姿勢ありがたいです
2017/06/23 10:09:47
khtokage
原因とか知らん言い訳はいいから責任取らせろ、みたいな人がちょいちょいいるの驚く。誰か(あなた)の溜飲を下げさせて解決を図り社内的にはミス即断の恐怖政治、より、再発防止を徹底する組織の方が信用できない?
2017/06/23 10:10:22
vvakame
これはCDNプロバイダ切り替えにおいて仕様確認が甘かったという事であーあという感想だ…
2017/06/23 10:14:49
comuchi
細かいことは意味不明だけど、ネガティブ情報もしっかり公開する姿勢は伝わりました!日々のアップデートもユーザー目線だし、上場したら買っちゃいそう。
2017/06/23 10:16:16
sisidovski
Fastlyかな。失敗事例の共有ありがたい…お疲れ様でした。
2017/06/23 10:16:21
estragon
身につまされる。淡々と情報公開する姿勢は、非常に好ましい
2017/06/23 10:19:29
baca-aho-doji
大きな問題なのにその技術的な原因、解決の手段が書かれててすごくいい記事だった。バッドノウハウだけど、こういうのがたくさん上がると世の中良くなると思う。
2017/06/23 10:19:49
FromAtom
ちゃんとしてる
2017/06/23 10:21:30
t_yamo
個人情報は原則CDNを通さない、DoS攻撃対策等の意図でCDN通すのならバックエンドの実装に関わらずCDNの設定で明示的にキャッシュはオフ、それができないCDNはその用途で使わない、というのがよいのかな。
2017/06/23 10:21:55
haruna777
昨日友達とメルカリの話ししたばかりでこのニュース!
2017/06/23 10:22:45
honeybe
何やらかしたのかを見に来た。 / なるほど… / 挙動が想定外だとなかなか気付きにくいですしね…(胃が痛い
2017/06/23 10:23:33
treeapps
この失敗を糧にして皆で改善して成長していくのか、袋叩きにして出る杭を打って強制終了させるのか。日本のIT業界の将来が見える気がする
2017/06/23 10:24:23
NOV1975
テクニカルな原因はそれだとして、単にテスト不足のだめなやつじゃないのこれ?
2017/06/23 10:25:04
ymzkmct
対応の速さや失敗事例の公開の姿勢が素晴らしいですね
2017/06/23 10:26:57
nottegra
問題発覚から1時間以内に問題解消まで持っていけるのは凄いですね。
2017/06/23 10:29:02
Allajah
CDN難しい
2017/06/23 10:30:05
matsukaz
DDoS対策として全リクエストCDN通してるんだと思うけど、切り替え先はGoogle Cloud CDNなのかな? 「Cloud CDN のキャッシュに保存しない場合には、Cache-Control: private ヘッダーを追加します。」 https://cloud.google.com/cdn/docs/caching?hl=ja
2017/06/23 10:34:17
peacemakerz
誠実な対応
2017/06/23 10:40:09
akanehara
値にmax-ageを含まなくともCache-ControlがあればExpiresがきかなくなるというRFC 7234と異なるこのCDN固有の仕様。これ事前に気づく自信ない。 http://httpwg.org/specs/rfc7234.html#calculating.freshness.lifetime
2017/06/23 10:41:24
t14kw
さくらからGoogle Cloudの切り替え?
2017/06/23 10:41:34
kanpuri
テクニカルな説明は他山の石として勉強させてもらいます。
2017/06/23 10:47:23
oakbow
「ユーザ個別の情報もCDN使うの?」ってブコメがあるけど、使わないようにcache-cotrol ヘッダ通じて制御してたって説明だと思うんだけど、違うのかな。
2017/06/23 10:48:46
stealthinu
失敗事例詳細報告してくれるのはありがたい。CDNのキャッシュか… ログインページもCDN通すのはDDoS対策というブ米指摘とか色々と勉強になる。がこういうの見るとやっぱ怖いなそれは。
2017/06/23 10:49:41
mumincacao
きゃっしゅ周りのへっだはあんまり信用できない印象あるけど最近は改善してきてるのかなぁ? がっこや会社の串鯖でも誤きゃっしゅ発生することあるし制御法が統一されてないのがなぁ・・・ (-ω【みかん
2017/06/23 10:51:30
yoiIT
事象が細かく説明されてる
2017/06/23 10:52:48
ryota-murakami
基礎の基礎やん…
2017/06/23 10:54:30
sho
Cache-Controlの用途が不適切な気がする。CDNによって解釈が変わるのも怖いなぁ。
2017/06/23 10:55:33
solidstatesociety
いずれCDN側で情報を忖度してくれる、「Privacy CDN」みたいなサービスができるんでしょうね。
2017/06/23 11:00:45
nakayuki805
キャッシュの出品を潰したと思ったらキャッシュにやられた話
2017/06/23 11:07:58
rikochanhayatokun
nginxだけにおそロシアですね
2017/06/23 11:13:00
koba789
処分や罰則を求めるブコメがあって驚く。罰則があると事故が防げるとでと思っているのか? それとも処分がされれば事故っても許せるのか?
2017/06/23 11:18:06
tetsutalow
おー。こういうのはCDNでの運用経験がそれなりにあっても、やらかす可能性がある。事故は大変だが、こういう情報共有は助かりますね。
2017/06/23 11:19:44
rjge
“キャッシュをしないのは `Cache-Control: private` が含まれている場合のみ” ”Expiresヘッダが過去の日付であっても、Cache-Controlヘッダが存在している場合は利用されないという仕様”
2017/06/23 11:20:20
teckl
某さくらのウェブアクセラレータでは `Cache-Control: s-maxage=1` とかしてても200以外がキャッシュされちゃって、 `Cache-Control "no-store"` にする必要があったような…
2017/06/23 11:25:00
yyamano
問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは Cache-Control: private が含まれている場合のみとわかりました。
2017/06/23 11:35:55
yoshikidz
“外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組み”ってどういうのだろ。この仕組みだけが気になるわー。hashでも作って照合するのかなー。規模は思ったより小さそうだしよかった。
2017/06/23 11:36:07
uchimata
なるほどねぇ。
2017/06/23 11:37:43
mellhine
はてなWeb技術者多すぎない?
2017/06/23 11:56:36
hiroponz
知見だ
2017/06/23 12:04:00
Harnoncourt
エンジニアリングブログって書いてあるのに賞賛してる人アホちゃうか/CDNによる意図しないキャッシュを早期に検知できる仕組みをいつまでにどうやって導入するのか。時期が未定ならいつ決まるのか。
2017/06/23 12:04:22
koiwaiyon
社内向けの資料がでてきたかのような印象。こういうのがもっとでればいいのにな
2017/06/23 12:07:43
s025236
昔はHTTPが主流だったしブラウザの挙動上ドメイン分散したほうが早かったけど、最近は全頁HTTPS化やh2の登場でドメイン統一した方が早いし、環境次第じゃSSL複合までCDNに任せれるので一旦はCDN通す案件が多いな
2017/06/23 12:08:08
assaulter
しゅごい...
2017/06/23 12:14:37
pmakino
CDNに限らずキャッシュ設計で犯しがちなミス。「外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組みを導入」ってそんなもの存在するんです?
2017/06/23 12:19:05
yu_wasama
「だろう運転」の末路。サービスミドルウェアサーバかかわらず移行においては移行先の仕様を確認することと、「変わってないこと」のテストをするべきだった。後から外からは何とでもでも言える。頑張ってください
2017/06/23 12:19:48
jitojito
CDNとかProxyでやらかすやつ。しかしキャッシュコントロールのベストプラクティスってあるのかな。
2017/06/23 12:22:39
TownBeginner
しっかり技術的なところまで踏み込んで原因調査の報告するのって良いな。情報管理をどこまでしっかりやってるかの裏付けにもなる。
2017/06/23 12:52:01
sin20xx
その認識ではダメよ。そもそもコレはインフラ設計時点でのミスで切替作業には関係ない。選定時点で仕様に違いを認識できておらず、且つ、その状態で変更手順やテスト手順を作成した事が原因。それでも普通は発覚する
2017/06/23 12:55:59
namisk
なんで先に仕様を確認しなかったのかな。挙動から勝手に推測して設定してたように見えるが。あとテストで気がつかなかったのはキャッシュまわりは難しいからかな…。
2017/06/23 13:00:57
Gonzoo
この速さで公開できるのはすばらしい
2017/06/23 13:01:25
sylph01
解説記事載せてるのはすごく好感が持てる
2017/06/23 13:16:34
tyamamoto
「再発防止について」に、「今後はちゃんとテストします」と記載したほうが良いぞ。
2017/06/23 13:17:11
snobsnog
ブコメが概ね好意的だし個人的にもこういう事実報告は好感度高いなあ。
2017/06/23 13:19:43
tm8r
“れ”
2017/06/23 13:19:50
tiki0108
こういう失敗例をみんなが読めるドキュメントにしてくれるのはありがたい!
2017/06/23 13:20:22
Soraneko
事例公開はとても好感がもてます
2017/06/23 13:27:06
michiomochi
なるほどな... お疲れ様でした。
2017/06/23 13:43:13
otameshi61
切替前の検証が問題なく動作してた、というのが気になりました
2017/06/23 13:50:14
sekirei-9
技術的な説明があると納得感がある不思議
2017/06/23 13:51:24
u-li
“本エントリでは技術的観点から詳細をお伝えさせていただきます。”
2017/06/23 13:51:29
omron
CDNであるあるな現象
2017/06/23 13:58:17
thingsym
キャッシュコントロールむずかしい。CDNによって挙動が違うのか。どこをどう見直す必要があるのか十分でなかった。稼働中の切り替えはなかなか検証が進められず不十分になりがち。
2017/06/23 14:12:31
marimonbunny
なるほどなあ。CDN使ったことなかったから備忘としてとっとこ。
2017/06/23 14:13:46
rryu
HTTP的にはCache-Controにmax-ageが指定されていたらExpiresは無視というの仕様なのだが、Cache-Controlがあるだけで無視するCDNにはまったということらしい。Cache-Controlだけで完結するように設定すべきということか…
2017/06/23 14:29:02
haratakedn
失敗をオープンにできる会社の風土はいいと思う。
2017/06/23 14:43:06
umakoya
たしかに技術的には「あるある」かもしれないけど、ユーザー的にはプロフィールに別人情報が表示されているとかになってるわけで、致命的な気もする・・・。
2017/06/23 14:52:49
tolkine9999h
普通にCDNサーバの仕様確認漏れだけど、こういうネタの時ってはてブは優しいね。
2017/06/23 15:05:00
birdtomita
仕様確認漏れ ってのと、テスト漏れ、ですよね。はてブの村民はなぜか(後ろめたいのか)優しいけど、結構トラウマレベルにヤヴァイですね。
2017/06/23 15:06:56
toenobu
A good article to me. I hope this article is going to be translated to English.
2017/06/23 15:09:39
nilab
「本来キャッシュされるべきでない情報がCDN側にキャッシュされてしまい、該当時間帯にアクセスしたお客さまに、他のお客さまの情報が表示されておりました」
2017/06/23 15:16:04
miyamae
これは仕方ない!と思えてしまってつらい…、キャッシュ周りのトラブル怖いよね » CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
2017/06/23 15:16:12
migrant777
発生原因はよく判ったけど、根本原因の追究と恒久対策が甘すぎだなぁ。/つっても外向きの報告書だしそこまで書かんか。
2017/06/23 15:21:58
lbtmplz
Cache-control怖い
2017/06/23 15:29:29
totoadad
“外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組みを導入します。”うーんなんか違う気がする…
2017/06/23 15:35:12
gohairgrowth
Web版メルカリの個人情報流出の原因
2017/06/23 15:39:57
adliblogger
cash問題の次はcache問題か
2017/06/23 15:46:42
junorag
問題については把握。でもプライベートなページがキャッシュされることと、それがログインコントロールを超えて他ユーザと混線することは別問題ではないのかな?
2017/06/23 15:49:59
mizuotoha
甘いな
2017/06/23 15:52:30
suquiya0
キャッシュは色々あるのな…。
2017/06/23 15:56:19
Nobeee
対応に大変好感がもてるなー
2017/06/23 16:07:12
potato777
動的コンテンツにもCDNを通すのは、①パフォーマンス向上: https://goo.gl/gARVfD (メルカリの発表資料) ② DDoS 対策。の 2点 でしょ(たぶん
2017/06/23 16:11:39
KoshianX
うへあ、こんなんでキャッシュされてしまうのか……。
2017/06/23 16:12:42
tmatsuu
CDNサービスを名乗っていてもサービスによって本当にバラバラでビックリした経験は自分もある。ドキュメントとヒアリングが必須。5種類ぐらい使ったことあるけど全部違った。結構厳しいよね
2017/06/23 16:25:43
tanimiyan
CDNサービスの比較とかやったことあるけど結構事業者ごとによって挙動や設定違うんだよね。すぐに失敗原因を公開するの、他者のためにもなるし良いことだ
2017/06/23 16:44:07
otihateten3510
障害報告書の簡易版だよねこれ この規模の会社なら普通じゃない?(できてないところ多いけどね!)
2017/06/23 17:15:39
weep
CMに出てる有吉さんに、このトラブルの呼称を名付けて貰いましょう。
2017/06/23 17:17:42
bushimichi
動的ページもCDN通したほうが負荷分散になるのかそれはあまり認識してなかったな。DDOS対策ともいわれてたな。ユーザごとにURLにパラメータ含めて別URLとかにしとけばよかったね。
2017/06/23 17:18:31
tzt
このエイヤ感はいかにもWeb系()っぽい。
2017/06/23 17:29:38
nisisinjuku
詳細な情報は後で助かる。(助かるような事態が起きないように目を通しておくことも必要だね)
2017/06/23 17:53:10
miragestlike
ブコメが勉強になります
2017/06/23 18:32:55
houyhnhm
調査(仕様確認)漏れ、修正漏れ、テスト漏れ。根本には、技術者の知識優先検証軽視があるかと思う。どうやってCDNの選定を行ったの?とかも考える必要があるかな。まあ、テスト重視が一番いいと思うけど。
2017/06/23 18:47:05
yzx
no-cache無視するのはブラウザには毎回リクエスト送信させてCDNのサーバでキャッシュを返して欲しい場合があるから?紛らわしいからキャッシュしない指示はCache-Controlではなく独自ヘッダにしてほしいな
2017/06/23 18:51:29
zu2
“コンテンツキャッシュをしているCDNのプロバイダ切り替えを行い" "その際本来キャッシュされるべきでない情報がCDN側にキャッシュされてしまい、該当時間帯にアクセスしたお客さまに、他のお客さまの情報が表示”
2017/06/23 19:20:32
iuhya
メルカリ特に好きじゃないけど、見直したわ。
2017/06/23 19:33:57
tincast
なるほど分からん。んでも失敗情報の共有って意味では有意義そう。
2017/06/23 20:35:04
baronhorse
理由はわかったけど被害者にはどうお詫びするのかね
2017/06/23 22:11:43
lazex
詳しい原因とかまで公開してくれるのはいいねー。メルカリユーザじゃなくてもサービス作る上での注意点とかわかるし
2017/06/23 22:45:44
dltlt
「CDNによる意図しないキャッシュ」
2017/06/23 23:12:18
ka-ka_xyz
しかしまー、機微情報が乗ってる動的生成ページ(あるいはデータ)をサーバ側キャッシュに乗っけるとかいうあたり、イントラ内Webアプリ屋からしたら異世界の話だなあ。キャッシュ使うなら、何かトークンで管理する感
2017/06/24 00:07:09
komz
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして
2017/06/24 00:15:36
Derabon
真正面から問題に答えていて印象が良かった。自分の知見にもなりました。
2017/06/24 00:51:09
catnapper_mar
キャッシュ無効設定が「ユーザ体験の向上」ってのは違和感ある。普通逆だから。
2017/06/24 01:24:34
typex2
再発防止策がおかしい。商用リリース後に監視しても情報が漏洩した後になってからの発見になるので根本的対策にはならないので、商用リリースする前にきちんとテストするべきだと思うんだけど。。
2017/06/24 15:05:03
orihime-akami
pixiv / apolloの問題と同類項の気がする。怖い。/平時にこれが起きたら全力で叩くのみだけど、切り替えやトラブル対処のイレギュラーで起きるのを避けようとすると外形検査くらいしか手はない気がする。
2017/06/24 17:56:56
ryochack
技術的原因を公開しているの素晴らしい
2017/06/24 18:14:04
erukiti
なるほど知見だ。これは見習いたいし、他の会社でもやって欲しい
2017/06/24 19:33:21
raitu
メルカリの技術面の信頼性
2017/06/24 23:01:55
bleu-bleut
Cache-Controlはno-cacheではなく、private。
2017/06/25 18:50:23
garage-kid
1714: 失敗を公開する姿勢については素直に評価したい。
2017/06/26 04:33:23
itochan
何人で作業したのかとかは書いてない。何人で検証したのかとかは書いてない。
2017/06/26 10:30:42
gosho-kazuya
ちゃんと説明するのすごいなあ
2017/06/26 10:32:34
versatile
勘違いしてはいけないが、技術的な原因を公開したからって起こった現象についての消費者の不利益はなにも変化しない
2017/06/26 12:26:33
cubed-l
privateのみ?no-storeは無視?
2017/06/27 16:17:07
drylemon
コーポレートサイトと合わせて読了。私の知識では、そもそもの設計、テスト、再発防止策の妥当性判断まではできないが、技術者と企画、広報サイドがちゃんと連携とれているみたいで良いなぁと思いました。