脱炭素とはなにか
BUSINESS INSIDER編集部では、比喩的表現の箇所が技術的な誤解を招いたことを踏まえ、改めてA氏やその他の開発者とも意見交換のうえ、6月23日に公開した本記事の加筆・修正を決定しました。合わせて、A氏が改めて今回の流出問題を語った記事『[メルカリ流出] 匿名エンジニアA氏が語る｢流出問題の本質｣とは？』もご覧ください。
メルカリの個人情報流出騒動が昨日からネットを騒がせている（BUSINESS INSIDER JAPANの第一報はこちらから）。
メディアの立場から見ると、メルカリの広報対応は及第点だ。短時間で、できる限りクリアに情報露出をすることで、ブランドへのダメージは最小限に留めているように感じる。
その一方で、コンテンツ配信設計のプロから見て｢メルカリの裏側の仕組み｣や｢謝罪リリース文｣の説明はどう映ったのか。国内で有料会員 数百万MAU（Monthly Active Users＝月間ユーザー数）級の大規模コンテンツ配信プラットフォームの設計と開発全般を統括する上級エンジニア（仮にA氏）が、匿名を条件にBUSINESS INSIDERからの取材にこたえた。
——今回の個人情報流出事故を、まず第一報としてどう見ました？
A氏｢すぐに技術的な詳細報告を出すあたりは感心しますが、個人的には設計に疑問を感じました。個人的にはそもそも設計が悪かったんだと思います。いくつか可能性があるので、報告資料の情報だけでは断定できませんが、"CDNの設定ミスでキャッシュが有効になった"という話と、"他のユーザの情報が見られてしまう"という話は、本来別物じゃないかと感じました。｣
——そこに違和感がある、と。
A氏｢キャッシュとは、本来同じファイルを何度も取りに行かなくてもいいようにするための技術ですから、中身がコロコロ変わるものは通常キャッシュを有効にしません。つまり、変更を即反映するためにキャッシュを無効にします。
一方で、CDN（コンテンツ配信ネットワーク）は同じ中身のファイルを大量のユーザに配布するための仕組みです。だから、中身がコロコロ変わるものや、ユーザ毎に内容が違うものには適さないんですよ。（※以下、加筆・修正）ちなみに、CDNでキャッシュを有効にすると"複数のユーザで同じファイルを共有する"ことになります。
また、CDNは大量のアクセスに耐えるための負荷分散装置としても使われます。
しかし、CDNはサイバー攻撃の影響範囲を局所化したり、急なアクセス増加にも運用負担をかけずに対応できますから、最近ではセキュリティ対策も兼ねて動的なコンテンツの配信にも使われるようになってきています。我々のサービスでも、本来はCDNに向かない"中身がコロコロ変わる情報"を、負荷分散のためにキャッシュを無効にしてCDNに置いていたりします。｣
——個人情報のデータがこういう形で漏えいする可能性についてはどう見ていますか？
A氏｢そこなんですが、今回の問題は、本来はCDNで取り扱うのには向かない"ユーザ毎に固有の情報（個人情報そのもの、もしくはセッション情報）で、かつ中身が変わる可能性があるもの"を、おそらく同じファイル名で処理する設計だったのかもしれません。を、（推測ですが）CDN側で同じデータとして処理されてしまう状況になっていたのが原因の1つではないか？と考えました。（※技術的に誤解を招く表現との指摘のあった"ファイル名"という表現を加筆・修正）
その場合、CDNを使わなければキャッシュが有効になったとしても、ユーザーに返される情報が古い場合があるだけで済みますが、CDNのキャッシュが有効になったとたんに、同時期にアクセスした別の人の情報がCDNで共有されて返されてしまう。私にはこういうメカニズムで発生した事象のように見えます。
通常はユーザ毎に固有の情報は、セッション管理されてユーザ毎に別々のデータとして処理されるため、CDNを経由しなければ（キャッシュが有効になったとしても）、ユーザに返される情報が古い場合があるだけで済みます。ですが、（推測どおりだとして）CDN側でキャッシュされる際に元々別々のデータであったものが同じものとして扱われてしまうと、CDNのキャッシュが有効になったとたんに、複数のユーザで同じデータを共有することになり、同時期にアクセスした別の人の情報がCDNで共有されて返されてしまう。私にはこういうメカニズムで発生した事象のように見えます。
通常はユーザーごとの情報はセッション管理されて別々のデータで扱われるべきで、サーバの内部（複数処理を並列で走らせると同じ変数を共有するリスク）ならともかく、物理的なファイルという形で同じファイル名を使っているのだとすれば、それは設計上の問題です。CDNを利用するならキャッシュを無効にするだけではなく、CDNの特性を考慮して設計を見直すべきです。
実際には、CDNを使わなければ起こらない問題でもあります。現場目線で考えると、サービス規模が拡大してどこかの段階でCDNを活用するようになった、しかし設計は古いままで無理やり動かしていた、そして、今回のシステム改修時に過去の状況を知らないメンバーが作業をして、そのギリギリのバランスを崩してしまった、という背景かもしれません。｣
——"中の人"目線で考えると、実にあり得そうな経緯ですね。（※上記"物理的なファイル"という表現に関する箇所を、技術的に誤解を招かない形で以下に加筆・修正。）
もちろん、CDNのキャッシュが正しく無効にされていれば、CDNを経由しても問題は起こらなかったかもしれません。
しかし、人間はミスをするものですし、CDN側の障害や仕様変更で意図に反してキャッシュが有効となってしまうこともあるかもしれません。
ですから、個人情報のようなリスクの高いデータに対してCDNを利用するなら、キャッシュが正しく無効化されることを前提にせず、仮にキャッシュが有効になったとしても問題が生じないような設計に見直す、というぐらいの慎重さが必要だったんじゃないか、と感じました。 ｣
メルカリ コーポレートサイトのお詫びのインフォメーション。あくまで迅速な情報公開という前提で、｢詳しい内容につきましては、再度ご報告いたします。｣としている。
A氏｢報告資料では、ユーザーの利便性向上のためにキャッシュを無効にしているという説明がありますよね。推測ですが、今回のようなケースでCDNを使うなら、キャッシュを無効にせざるを得ません。しかし、CDNはキャッシュを有効にしてこそユーザー体験が向上するので、ユーザの利便性ではなく負荷分散のためにCDNを使おうとして、その使い方がうまくなかった、というように読めます。今回の実装は、CDN本来の使い方というよりは"キャッシュを無効にしてCDN経由にすることによるメリットを採った"結果、設定を誤ってしまった、というように読めます。
ただトラブル対応の点では難しい面もあるんです。今回のようなトラブルは、実は複数同時アクセスが発生する状況でないと起こらない。だから、開発中にはその状況を再現するのが難しく、サービスリリース前の検証やテストの段階で問題を発見するのは困難です。さらに設計上の問題でもあるので、システム全体を把握している人間が隅々までチェックしないと気付かない。役割分担して作業している開発の現場では、かなりの確率で気付けないでしょう。
さらに設計におけるリスク管理の問題でもあるので、システム全体を把握している人間が隅々までチェックしないとなかなか気付きません。｣
——再発防止について"外形監視を利用した仕組みを導入する"ということですが、これは具体的にどういう防止策になるんでしょう？
A氏｢外形的とはシステムそのものや開発している現場からではなく、そのシステムを利用する側の環境から監視することで障害の早期発見に努めるということでしょうね。
例えば、システムに繋がらない理由がネットワーク障害などの場合だと、システム自体は異常を検知し難く、アラートメールも送れないなんて状況が起こります。
今回のメルカリの流出事故は、個人情報流出の問題発生から発見まで5時間かかっています。なぜかというと、システム自体が異常な動作をしているわけではないので（設計・実装通りには動いている）、通常のシステム監視では気付けない。だから、"外形的"という表現を使ったんだと思います。
メルカリに限らず、急に大きくなったサービスは、古い設計（負の遺産）がいっぱいあるものです。猛烈な規模でスケールしていくサービスの状況に対して、エンジニアは"できない"とは決して言えない。結果として"トリッキーなテクニック"や"潜在的にリスクのある仕組み"を使ってしまうというのは、我々からすれば、あり得なくはない話なんです。
今回採用した方法の、個人情報に対する潜在的リスクが判明した以上、"問題発生後の早期発見"のための対策だけでは不十分なことはメルカリも認識しているのではないでしょうか。開発段階でのリスクの把握や試験の強化、あるいは設計変更を考慮していかざるをえないんじゃないか、と思います｣
（※文末の下線の箇所を加筆）
