| @WWW

Santorini sunset

去年の秋( 2018 年 11 月)に、 Flickr が課金ポリシーを変更することがアナウンスされていた。これまですべてのユーザーに無料で与えられていた 1TB のストレージは撤廃され、無料ユーザーは 1000 枚までしか画像をアップロードできないことになった(上限を超えている分は削除される)。料金プランも見直され、既存の Pro ユーザーは $24.95 / 年で Pro プランを利用できていたのが $49.99 / 年(アメリカ国外在住者は $59.99 / 年)と大幅な値上げとなった。 Flickr は 2018 年の 4 月に SmugMug に買収されている。

SmugMug CEO Don MacAskill's statement

Flickr を買収した SmugMug の CEO の Don MacAskill が Flickr のブログで記事を書いている。

要約するとこんな感じ。

  • SmugMug は写真を撮る人にフォーカスしたビジネスを 16 年以上続けてきた
  • 資金調達はしておらず、自己資金で運営されている
  • ユーザーのデータを広告業者に売って広告収入を得ることもしていない
  • 写真家の人々と向き合い、彼らが何を必要としているのかを注意深く聞いてきたのが成功の秘訣
  • そのやり方を Flickr にも適用したい
  • 我々はユーザーのためのサービスであり、投資家や広告会社のためのサービスではない
  • 無料プランは残すが 1000 枚までしかアップロードできず、広告が表示される(プロには表示されない)

要は SmugMug で成功したやり方を Flickr でも踏襲したいということらしい。広告主の為にユーザーを売りたくないと言っておきながら相変わらずフリープランはあって広告を表示するというのは矛盾している気がする。

阿蘇山上から見る普賢岳 / Mount Fugendake from Mount Aso

Flickr VP of Product Andrew Stadlen's statement

Flickr のプロダクト責任者の Andrew Stadlen も無料ユーザーへの扱いの変更について書いている。

  • Yahoo! 子会社時代に無料ユーザーに 1TB のストレージを与えた結果、非常に大きな負の影響があった
  • 無料に釣られて入ってきたユーザーによるコミュニティの破壊
    • 無料のストレージに釣られてくるユーザーは写真に情熱を傾けるユーザーとは属性が異なり、従来 Flickr を特別なものとしていたコミュニティでの交流や関心を共有する場としての雰囲気を後退させた
    • 活気のあるコミュニティを愛する多くの Flickr ユーザーはこのような変化を望まないはずであり、もう一度、写真コミュニティでの交流にフォーカスすることにした
  • 脱広告主優先
    • これまで無料のストレージを提供するために、ユーザーではなく広告主ファーストの状態になっていた
    • Flickr を買収した SmugMug の "You are not our product. You are our priority." というポリシーに共鳴し、広告主ではなく、ユーザーが喜ぶ機能開発を行う
  • Flickr = 無料というイメージの打破
    • 1TB の無料ストレージを与えたことで、ストレージや Flickr 自体が無料のものという認識が広まってしまった
    • 活発に利用しているユーザーにサイトの安定運営と成長、イノベーションを継続するための支援をしてほしい

Nagatare beach

Pro プラン値上げに対する Flickr ユーザーの反応

ヘルプフォーラム内に上の Andrew Stadlen が既存ユーザー向けの料金プランを改定する旨を書いていて炎上している( 1300 個以上レスがついている)。

Pro であることで得られるメリットは広告なしブラウズとアクセス解析と制限なしのアップロードだが、いまでも値段に見合わないと思いながら払っている、という書き込みがほとんどで、このままメリットが増えない状態で値上げされるんだったら更新しない、という書き込みが目立つ。

この説明では結局なぜ値上げをするのかが書かれておらず、「2年は値上げしないという約束を守ったんで上げますね」ということしか書かれていない。 SmugMug の最安料金プランが $48 / 年なのでそれに合わせるように SmugMug から指示されたのだと思う。

DSC_6062


考察

Flickr が直面している事業領域は、写真共有(家族・友人)、クラウドストレージ、 SNS という三つだと思う。今日ではそれぞれの市場に強豪がひしめいていてかなり厳しそうだが、昔はそうではなかったはずで、 Flickr が Yahoo! に買収された 2005 年頃は以下のような感じだったはずだ。

Photo Sharing Product Market 2005

Photo Sharing Product Market 2005

この頃は iPhone も Android もなかったし、 iCloud も Picasa Web Album も Google Photos も、 Facebook も Twitter も Instagram もなかった。家族と写真を共有するには CD や DVD に写真を「焼いて」手渡すか、メールに縮小した画像をちまちま添付して送るしかなかった。そこに Flickr が登場して、インターネット越しに簡単に家族や友人に対して写真を共有できるようになった。煩わしいリサイズのことは考えなくてもよい。

家族や友人と共有するだけではなく、写真をインターネット全体に公開して見ず知らずの人と交流することもできた。この頃、写真を公開して人々の反応を得ることができる SNS は Flickr だけだった。他のサービスは家族・友人間の共有やクラウドストレージの機能を売りにしていたが、見ず知らずの人と写真を通してつながれるのは Flickr だけで、そこが写真愛好家の心を捉えた。共有範囲をコントロールできる仕組みと SNS 機能(コミュニティ)によって初期の Flickr は成長した。

その勢力図がいまでは以下のようになってしまった。

Photo Sharing Product Market 2019

Photo Sharing Product Market 2019

スマートフォンが普及して人々がスマートフォンで写真を撮るようになると、WhatsApp や LINE のようなメッセンジャーで写真が共有されるようになった。 日常的に利用しているチャットアプリでの写真共有は Flickr よりもはるかに便利で、身近な人に写真を共有できる Flickr の強みはコモディティ化し、強みではなくなってしまった。

クラウドストレージ市場には Apple や Google がそれぞれ iCloud Photo Stream と Google Photos を投入し、 iPhone ユーザーと Android ユーザーはデフォルトでこれらのサービスを利用することになった。 OS に統合されたこれらのクラウドストレージの利用にはアプリのインストールすら不要でユーザーが深く意識することなくクラウドストレージに写真が保存されるようになった。おまけに Dropbox や Evernote 、 Amazon Drive などの競合もこの市場に参入し、瞬く間にレッドオーシャンと化してしまった。 Google Photos がローンチした 2015 年から Flickr への画像アップロード数が減少し始めている(How many photos are uploaded monthly to Flickr? Flickr may… | Flickr)。

SNS としての Flickr の強みも揺らいでくる。普段使っている SNS で写真を公開できるようになると、わざわざ Flickr を使う必要がない。 Facebook や Twitter で写真を共有できるならわざわざほかの SNS を使う理由はなくなるだろう。写真をキーにオンラインで人とコミュニケーションするときに、 Flickr を使う必要がなくなった。

極めつけは Instagram の登場で、まだスマートフォンで撮られた写真の画質が悪い頃からフィルターをかけるという機能を呼び水に人を集め、スマートフォンによる写真共有 SNS の代表格として君臨した。ハイアマチュアの人々が撮影した綺麗すぎる写真を敬遠して普通のスマートフォンユーザーは Instagram を使ったのだ、と書いている人もいた。

In recent times the nature of photography has shifted quite far from what it used to be. Ten years ago, both amateur and professional photographers were focusing on taking breath-taking pictures of landscapes, people, nature and different environments and cultures. These days people are taking pictures of their cats, their shoes and their meals.

Why is Flickr not Growing as Quickly as Instagram? - Flickr Embed

この辺はバカと暇人の話に通じるのかもしれない。インターネットがバカになって Flickr が廃れ、 Instagram が流行った。超絶美麗な風景写真よりも自撮り画像とかメシ写真の方が人目を引くのだろう。

こうして Flickr は写真共有、クラウド画像ストレージ、 SNS のすべての市場において強みを失ってしまった。

深江海岸の夕焼け

収益モデル

収益モデルを検証する。 Flickr の収益モデルは 3 つあって、 Ad (無料ユーザー向け)と Subscription ( Pro ユーザー向け)と Merchandise (写真のプリント)だ。

Revenue Model

Flickr 同様に広告モデルを採用している Instagram や Facebook は、写真好きではない普通の人の生活に深く入り込んでおり、 Flickr の何倍もの PV を集めているはずだ。広告による収益モデルはとにかく PV を集めてインプレッションを増やすことが重要なのでこの分野で Flickr は苦戦することが予想される。しかも無料ユーザーに対する制限を強化するとなれば、益々広告収入の額は少なくなっていくだろう。

サブスクリプション領域で最大の競合である iCloud や Google Photos をやっている Apple と Google はハードウェアが売れたり iOS / Android のプラットフォームが拡大することが目的なので、サブスクリプションモデルではあるがぶっちゃけ単体で儲からなくても大丈夫なはずだ。 Flickr や SmugMug は単体で利益を上げることを重視して運営しなければならないので、いわゆる捨て身の状態で運営できる iCloud や Google Photos とまともに勝負するとかなり苦戦を強いられるだろう。

写真のプリント販売に関しては、この先は厳しくなっていくばかりだろう。むかし iPhoto にあったプリント販売を利用したことがあるがいまいちだったし、もはや Photos にはそんな機能は付いてない( App Store でプリントできるアプリを探しましょうと表示される)。印刷したければ印刷サービスを使えばいいだけで、わざわざ中間マージンを取られる Flickr を使うメリットがない。そもそもプリントした写真を好むユーザーは Flickr を使うとは思えない。高齢者はプリントを好むかもしれないが、 Flickr の主なユーザー層はミレニアム世代以下の若い世代だろう。

どの領域においても Flickr が儲けられる要素が見つからない。

今宿夕焼け

課金ポリシー

個人的には $44.95 / 2 年 で Flickr Pro を利用していたので今回の値上げはかなり高いなという印象だった。アメリカ国外居住者に対しては $49.99 ではなく $10 上乗せした $59.99 を提示するなど料金プランには不公平感がある。

さらに運営にかかるコストを、コミュニティに貢献し最もアクティブに使っているユーザーから徴収するというのもいい印象を持てない。リポジトリに課金していた頃の GitHub が OSS には無料で利用させていたように、コミュニティに活気をもたらすユーザーはむしろ優遇しなければならないのではないかと思う。熱心に良い写真を投稿し、 Flickr の PV や MAU 増に貢献する Flickr にとってありがたいユーザー(プラットフォーム革命でいうところの生産者)に課金して、ただ見に来るだけのユーザー(消費者)は無料で使えるのには違和感がある。

あるいは Flickr は写真を投稿せず見に来るだけのユーザーこそコミュニティに活気をもたらすと考えているのだろうか。 SmugMug CEO の Don MacAskill のブログ記事には「無料ユーザーがコミュニティに活気をもたらす」と書いてあったので、そういうスタンスなのかもしれない。写真を投稿するユーザーはいいねが欲しく、いいねをもらうために Flickr にお金を払って Pro ユーザーになり写真をアップロードする。すると無料で利用している閲覧ユーザーたちがやってきていいねを押していく。いいねをもらった Pro ユーザーは承認欲求をみたされる。この考え方ではいいねを送る方が生産者であり、受け取る(写真をアップロードする)方が消費者だといえるのだろう。そうなると写真をアップロードする側に課金するポリシーは分からなくもない。

ただ一方で VP of Product の Andrew Stadlenは「無料の 1TB ストレージにつられてやってきたユーザーはコミュニティを破壊した」とも述べている。いいねをもらったり送ったりを Pro ユーザー同士で行わせたいのだろうか。誰もが消費者であり誰もが生産者である eBay や Etsy のような市場構造にしたいのかもしれない。ただそれでは市場(コミュニティ)はしぼんでしまうだろう。

DSC_1021

SmugMug way は Flickr に適合するか

Flickr は家族や友だちと写真を共有する他に、 SNS 上で写真をベースに交流するという側面があった。プロではない、普通の写真好きな人たちが撮った写真を披露しあい、お互いの写真を褒め合う場所。上の方で引用した記事にもそのようなことが書かれている。

一方で SmugMug は交流というよりも、写真を生業としている人たちのためのオンラインストレージで、無料プランはなく、利用するには必ず費用を払う必要があった。収益モデルこそ似ていて Subscription モデルだが、そもそものビジネスモデルが異なる。 Flickr はプラットフォームだが、 SmugMug はプラットフォームではない。プラットフォーム革命の定義にならうなら、 SmugMug はネットワーク効果の働かない単なる SaaS で、 20 世紀型の直線的ビジネスモデルに過ぎない。

SmugMug による Flickr 買収はきっとうまく行かないだろう。 The Verge の記事には以下のように書いてある。

But technology-wise, this acquisition might be a tall order for SmugMug, which isn’t nearly as big as the photo service it now owns

Flickr acquired by professional photo hosting service SmugMug - The Verge

サービス規模的には Flickr の方がでかいので、技術的には SmugMug には手に負えない仕事を請け負ってしまったことになりそうだ。


Flickr は単独で収益モデルを確立する前に Yahoo! に買収されて飼い殺し状態が長かったことが悔やまれる。正しくスマートフォン時代に適応できていたら、今頃は女子高生が利用するのは Instagram ではなく Flickr だったのかもしれない。

10 年前に書いた記事にこんなことを書いていた。

2007年の春、僕は病気で入院してた。抗がん剤やってたから自由に外を出歩くことは出来なかった(抗がん剤の副作用で免疫力が極端に低下し、すぐ風邪をひくから。免疫力が低下している状態で風邪をひくとすぐに肺炎になり、死に至る)。せっかく辺りに桜が咲いているのに、それを見に行くことも出来ない。でもFlickrがあった。僕はWILLCOMの遅い回線でFlickrにアクセスし、「桜」で検索した。健康な人達がアップロードした桜の写真を見ることが出来た。2007年春のささやかな花見でした。

Photo publication for the rest of us

さようなら、これまでありがとう。

| @WWW

2019 年 6 月の Google コアアルゴリズムアップデート

2019 年 6 月の頭に Google が検索結果のコアアルゴリズムをアップデートしたらしい。

自分のブログはこの影響をもろに受けて、アクセス数が激減してしまった。自分ではよく分かっていなかったが、コアアルゴリズムアップデート前は痔ろう関係の記事が結構 Google で上位に表示されてたみたいだ。 6 月のコアアルゴリズムアップデートではお金や健康系の記事に対する評価基準が変わったらしい。より専門的で正しい情報を掲載しているサイトの方が上位に表示されるようになったみたい。自分のブログは個人の日記レベルのことしか書いてないので評価が下がり、表示順位が下がるどころではなくそもそもほとんど表示されないようになってしまった。

肛門周囲膿瘍の検索パフォーマンス

狙って病気やお金のことを書いていたわけではなく、1000 件程度ある記事のうちのたまたま数件がお金や病気について書いてあって、それが結構アクセスを集めていたわけだが、それらが検索結果に反映されなくなってしまったので検索流入が激減してしまった。

お金や健康に関しての情報について、専門家が書いているわけではない記事が検索結果で上位表示されるのは確かに問題なので今回の Google のアルゴリズムアップデートは一ユーザーとしてはありがたいことだけど、 Google のお気持ち次第でこうもアクセス数が減るものかとビックリしてしまった。

| @WWW

明後日から仕事で北アルプス遠征に行くので以前映画館で見たことがある『劔岳 点の記』を再視聴しておこうとするも Amazon Prime Video にも Netflix にもなく、 Amazon Video で都度払いで借りることもできず、仕方なく iTunes のレンタルで借りようかなと調べると微妙に高くて昔見た映画見るのに 400 円も払えないなぁと調べてたら楽天TVにもあって価格は 324 円、楽天ポイント使って 172 円で借りることができたけど Apple TV にミラーリングして見ようとすると DRM かかってるようでミラーリングできなかった(予告編はミラーリングできたのに本編は不可)。頭にきたので即刻楽天TVアプリをアンインストールして近所のレンタル屋に行って DVD 借りてきていざ見ようとしたら別の DVD が入ってて、どうも店員が『劔岳 点の記』のジャケットに別のディスクを入れてたようだったけど、電話したところ「お客様が間違っただけでは」と言われてさらに頭にきて見ずに返しに行き、諦めて楽天TVで借りたやつを iMac で見ようとしたら「 Silverlight のインストールが必要です」と表示されて結局見ることはできなかった。もうアルプスで遭難するしかない。

| @WWW

2018 年 7 月 10 日に天神の Fusic 社で開催された Scrapbox Drinkup #5 に参加した。

Nota 社の皆さんが福岡に訪れてユーザーと情報交換するという趣旨のイベントのようだった。 Scrapbox はほとんど使ったことなかったが、 @masui 先生や @shokai さんの発表が聞けるということなので行ってみることにした。

Nota 社のイベント、他社の採用目的感あふれるイベントと異なり牧歌的な感じがとてもよかった。 Nota 社の皆さんも参加者と同じテーブルに座ってピザ食ったりビール飲んだりでざっくばらんな感じだった。

最初にパスタケさんの概要説明的な話があったあと、 @masui 先生や @shokai さんの発表を聞いて「使ってみたい!」という気持ちが強くなり、発表を聞きながら一つプロジェクトを作った。

実は Drinkup 参加前に @ssig33 さんが書いていた Scrapbox についてのブログ記事(ssig33.com - Scrapbox Drinkup #4 にいってきた)を読んでいて「ふ〜ん」くらいに思っていたのだが、実際に利用事例やできることを知って、確かにこれは面白いものだなと思った。

@ssig33 さんが書いている通り、 Scrapbox は単に知識を集めて検索可能にするためのものではなく、コミュニケーションツールだなという感じがする。なので MTG の議事録などを複数人でとって理解が曖昧だったところを確認・補強したりするのに非常に向いてるだろうなと思った。リモートワーク主体のチームが Scrapbox を導入したら MTG の生産性が高まるのではないかと思う。

個人的に Scrapbox に対して良いなと思ったのは以下だ。

  • 共同編集
    複数人で同時に編集できる楽しさ
  • ドキュメント間のリンクが容易
    ハッシュタグやリンクは相互参照される
  • 動画や画像を簡単に貼れる
    コピペで画像をアップロードできる
  • 投稿・入力の敷居の低さ
    枠や升がなく、必須入力やバリデーションなどもほぼほぼなさそう
  • 検索

それぞれはすでにすぐれたツールが存在していると思うが、それが一つのツールですべて使えるようになっているところが便利なのだと思う。

以前アウトライナーについて記事を書いたことがあるが(アウトライナーで文章を書く - portal shit!)、その中で紹介したものに WorkFlowy というアウトラインプロセッサーがある。個人が思考を整理しながら文章を書くのに非常に適したソフトで、 Scrapbox に似ている側面があると思った。

WorkFlowy はアウトライナーからファイルやタイトル、ノードという概念の区別を取っ払い、すべての情報をノードとして扱いツリー構造にしてしまう。おかげですべての情報が容易に検索可能になり(情報がファイルで分割されない)、検索性も向上して知識の保存と参照が劇的にしやすくなる。 Scrapbox では階層構造を作ることはできないが、すべての情報はフラットな空間に書きためられ、それぞれの情報を非常に参照しやすいかたちでリンクさせることができる。

Scrapbox と WorkFlowy が大きく異なる点は、これらの情報を容易に共同編集できるかどうかだと思う。 WorkFlowy は非公開状態がデフォルトで、他者に閲覧を許可したり共同で編集したりするためにはその為に専用のリンクを発行して共有のレベルを設定しないといけない。 Scrapbox はデフォルトが公開状態で(少なくともプロジェクトの参加者の間では)、特に設定することなく情報を共有したり共同で編集したりできるようになっている。 URL は当然ながらドキュメントを作成したタイミングで生成される。わざわざ共有用 URL を発行する必要はない。デフォルトでは URL が存在しないため、 WorkFlowy ではドキュメント間のリンクもしづらい。

このように Scrapbox で初めて得られる文章編集体験というものが確実に存在すると思う。


個人的に作ったやつは会社の G Suite 内の Google Maps にあったランチスポット情報を集約したやつをエクスポートしたもの。Drinkup で @masui 先生が「ヘルプドキュメントの類を Scrapbox で構築したら便利なはず」という話をされていた1のに着想を得た。職場が福岡市の中心部でもマイナーなエリア(旧来の博多の街の中心部だけど天神と博多駅からも微妙に離れていて飲食店が少ない)にあり、食べログなどで探してもあまり有益な昼食スポットの情報が得られないため、これまで社内で情報をストックして共有していたが、この手のものは一社で作るよりも界隈にお勤めの皆さん全体で共有した方が効率がよいはず。 Scrapbox がこの用途にはピッタリなのではないかと思って作ってみた。

Spread Sheet や Google Maps の Data Table による管理では複数人からの情報を良い感じにまとめることができず、多くの人から情報を集める、という点で難があった。 Spread Sheet は入力しやすい UI であるとは言えないので、入力する側に根性や気合い、熱意が求められた。 Scrapbox であればテキストファイルに文章を入力するのと同程度の手軽さで情報を入力していくことができる。入力欄に枠や升があるわけではないので自由気ままに書くことができる。これは書き手にとって大いにストレスの軽減になると思われる。

もし福岡市地下鉄貝塚線呉服町駅周辺のランチスポット情報をお持ちの方がおられましたら以下のページから登録して情報共有しませんか。よろしくお願いいたします。


  1. 実際に Scrapbox のヘルプページは Scrapbox で作成されている。 Scrapbox ヘルプ 

| @WWW

| @WWW

先日書いた Day One のバックエンドで障害 - portal shit! について、 Day One のヘルプページで詳細を説明する記事が掲載されていました。

ウェブアプリケーションエンジニアの皆さんが読むと参考になるのではないかと思い、翻訳の可否をたずね許可をもらったので翻訳します。


2018 年 5 月の Day One 障害報告

執筆者: Paul Mayne (訳注:Day One の創業者)
今週更新(訳注:障害復旧日の午後に公開されました)

2018 年の 5 月 7 日から 10 日にかけて、 Day One は重大な Sync サービスの停止に陥りました。ユーザーの皆さんから堅牢な Sync サービスを期待されていることはわかっていますし、この出来事は我々の基準を満たすものでもありません。何が起こったのか、そして将来にわたってどのようにこの問題を回避していくかをユーザーの皆さんにお伝えしたいと思います。

簡単なまとめ

5 月 7 日にハードウェア障害が発生し、最初の Sync サービスの停止が発生しました。バックアップデータが不完全だったことが原因で、 5 月 8 日の Sync サービスの復旧処理中、一部のユーザーのアカウント ID が既存のユーザーのものと重複してしまいました。結果、一部の新規登録ユーザーは他人の記事を見ることができる状態となっていました。問題に気がついてすぐに Sync サービスを再び停止させました。対象のユーザーは 106 人で、これは我々のユーザー全体の 0.01% よりも少ない値です。

現在、 Sync サービスは正常に復旧しており、記事が他人に見られることはありません。近日中(訳註:すでにリリース済みです)に意図せず共有されてしまった記事を削除するアップデートを提供します。

End-to-end の暗号化を施していた記事は今回の事故の対象外です。

いかなる偶発的な個人情報の漏出も信用を毀損するものであると我々は認識しています。この不幸な状況にあって我々は、正直に状況を説明することが最善だと思っていますし、また信頼を回復するために全力を尽くしています。今回、個人情報の流出被害にあった 106 人のユーザーには終身の Premium メンバーシップを無償提供し、それぞれ個別に連絡を取っています。自分たちにできるあらゆることを行ってみなさんの信頼を回復していきたいと思っています。

障害の詳細

5 月 7 日月曜日、 Day One の社員が DB サーバーでハードウェア障害が発生していることに気がつきました。問題のあるサーバーをデータベースクラスターから取り除く作業とデータを残りのサーバーに分散する作業を始めました。

データの分散処理に失敗します。これが最初の障害です。すぐに Sync サービスを復旧させたかったため、新しいデータベースクラスターを作成して最新のバックアップデータを読み込むことにしました。新しいクラスターがセットアップされ、バックアップが読み込まれました。

5 月 8 日火曜日の早い時間に復旧処理が完了し、 Sync サービスを再開しました。当初は順調に動いているように見えました。しかし数時間で「自分の記事ではない記事が見える」という問い合わせが何人かのユーザーからありました。これは由々しき事態であり、我々はすぐに Sync サービスを再停止し、これ以上被害が拡大しないようにしました。

この時点で、問題と対応方法の調査を行う間、 Day One Sync を無期限に停止する旨をソーシャルメディアに投稿しました。何が原因なのか、何が起こっているのか、そしてもう問題が起こらないと確信できるまで Sync サービスは再開できませんした。

5 月 9 日水曜日の午前、問題の根本原因を突き止めました。復旧処理に用いたバックアップデータが不完全だったのです。記事データは完全なものでしたが、ユーザーアカウントデータに欠落がありました。具体的には、 3 月 22 日よりも後に作られたユーザーアカウントデータが含まれていなかったのです。その結果これらのユーザーはログインすることができていませんでしたし、特定の記事データが意図せず他人から見えてしまうという問題につながりました。

それぞれの記事データベースは “accountID” というフィールドを持ち、どのアカウントがその記事の所有者であるかを判断しています。全ての記事データは正しく復旧されましたが、ユーザーアカウントデータはそうではなかったため、データベースに所有者が存在しない記事ができてしまいました(例えば “My Travel Journal” という記事は 123456 というアカウントのものだったとしましょう。しかしそのアカウントが存在しなくなってしまったということです)。新しいユーザーアカウントの ID は連番で作られます。復旧されたデータは最新のユーザー情報を含んでいなかったため、 5 月 8 日に新規登録したユーザーは本来よりも小さな値の ID で登録され、既存のユーザーアカウントと重複することになったのです。その結果、これらの新規ユーザーはすでに存在する他人が書いた記事を読めるようになってしまったのです。

5 月 8 日の問題が発生していた期間のうちに、 326 アカウントが正しくない account ID で作成されました。その 326 個の ID のうち、 106 個が別人によって書かれた既存の記事データに結びついていました。 2018 年の 3 月 22 日から 23 日に作成されたアカウントは他人から記事が見られる状態になっていたということです。それらは account ID 1104506 から 1104831 の人たちでした。

現在のところそれらの記事のうちどれくらいが end-to-end の暗号化処理をされていたかはわかっていませんが、 end-to-end の暗号化をしていた記事は今回の問題でも他人に見られることはありませんした。

水曜日の調査の後、元のデータベースでデータの分散処理に失敗する問題を解決することが最善の選択肢だと判断しました。いくつか設定ミスがあり、データベースの負荷が高まる原因になっていることがわかりました。この負荷が原因でデータの分散処理が失敗していました。

水曜日の午後、この問題を修正し、元のデータベースクラスターで分散処理が正しく完了することを確認しました。しかしエンジニアチームとサポートスタッフが万全の態勢で臨めるよう、 Sync サービスの再開を木曜の朝まで遅らせることにしました。山岳時間で 5 月 10 日木曜の午前 8 時、 Sync サービスは再度有効化されました。

同期サーバーには大量の待機処理があったため、それらの処理が終わるまでは少しパフォーマンスに問題があるかもしれませんが、なるべく遅延が発生しないように対処しています。

今後どうするのか?

意図せず共有されてしまった記事を削除する機能が入った Day One.app のアップデート(バージョン 2.6.4 )をすぐにリリースします(訳注:すでにリリース済みです)。このアップデートをインストールすると、未ログイン状態のユーザーの端末からは非公開の記事はすべて削除されます。対象ユーザーはアップデートのインストール後 30 日以内に Day One アカウントにログインすることが必要で、このログインをもって Day One.app はログインユーザーを記事の所有者であると認定し、記事を復元します。 Day One.app は影響を受けるユーザーに対してこの変更内容を通知します。

今後、同様の問題が起こらないように、近々以下の改修を同期サーバーに対して施します。

  1. account ID の新規作成時、すでにその ID で記事が作成されていないかをチェックします
  2. 新規の account ID に対しては、連番の数字に加えてランダム生成された二桁の数字を末尾に付加することにします。将来、同じような問題が発生して連番 ID が若返ってしまったとしても ID の衝突が起こる可能性は非常に小さくなります。
  3. いくらかのユーザーアカウントがバックアップ対象から除外されてしまう問題を修正します。

他人に記事を見られてしまった 106 人のユーザーに対しては真摯に謝罪します。対象のユーザーには終身 Premium メンバーシップを提供するとともに、その他懸念点がないか個別に連絡をとっています。今回、大規模な情報流出は起こっていません。第三者がデータベースに侵入したということもありませんし、すべてのデータは我々のサーバーで安全に保管されています。しかしながら 106 人のユーザーの我々に対する信頼は失われてしまいました。信頼は獲得するものであり、与えられるものではないということを承知していますし、再び皆さんからの信頼を取り戻せる機会を得たいと思っています。ユーザーの皆さんには 2017 年 6 月にリリースした end-to-end の暗号化機能を利用することを推奨します。この機能は今回のような事故やその他の問題があったときにもあなたの個人情報を保護します。

今回の障害で Sync サービスを利用できなかった間、辛抱して下さったユーザーの皆さんに感謝します。皆さんが Day One を使って大事な思い出を記録していることを理解しています。今後、よりよくしていくことをお約束します。信頼を回復するため、全力を尽くします。

— Paul

| @WWW

Day One という日記書きソフト、愛用しているのだけど今週頭に障害が発生して日本時間で 2018/05/11 の明け方まで同期ができない状態になってた。

ユーザーとして不便だったけど復旧にかなり時間がかかったのがソフトウェア開発者の一人として興味深かった。何が原因で復旧が遅れたのか推測した。

Day One のバックエンドは AWS に構築してあるようで、負荷でサーバーがダウンしたのなら EC2 インスタンスを追加してサーバー再起動すれば良いはずなのですぐ復旧できるはずと思ったが、一向に復旧しない。復旧作業の状況報告ページにしきりに “server rebalance” というフレーズが出てきており、アプリケーションサーバーで “rebalance” なんてことはやらないから、どうもデータベースがクラッシュしたようだった。

Day One のバックエンドエンジニアの採用情報見たら技術スタックが書いてあって、開発言語は Scala で DB は Couchbase を使ってるとのことだった。で、 Couchbase では Shared Cluster の rebalance という作業が必要らしい。

Couchbase は CAP 定理のうち一貫性と分断耐性を保証していて、その代わりに可用性が犠牲になっている(Couchbase Server - Wikipedia)。 Day One では複数のクライアントからほぼ同時に同一ドキュメントに対して更新が走ることが多いし、 iOS からは不安定なモバイル回線経由で接続される。かつては Dropbox や iCloud も同期のバックエンドとしてサポートしていたが、コンフリクトしたり意図せぬデータ欠落などがあったと思われ、自前のバックエンドシステムに移行したのだろう。一貫性と分断耐性に特化した Couchbase はユースケースとして最適に思えるが、障害が起こるとリバランスに手間取り復旧の難易度が上がるようだった。

自分は大規模分散データベースみたいなやつは受託の会社に勤めてた下っ端の頃にしか使ったことがなく、自分でがっつり運用・構築したことがないので大規模データベースに対する知識が足りていないと思う。大した考察は出来ていないが、今後もバックエンド API おじさんとして余生を過ごしていく上で参考になる出来事だった。そのうち詳細な post-mortem が Day One のエンジニアによって公開されるようなのでこちらもあとで読んでおきたい。

あまりに復旧が遅かったのでこのままサービス終了するのではないかと心配になったが、何とか復旧出来たようである。 Day One のバックエンドの皆さんおつさまでした 🍵