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