Fly.io の Postgres クラスターが3日間ダウンし、その件について何の情報もありません
(community.fly.io)- 2023年7月、Fly.io ホストの緊急メンテナンス（emergency maintenance）中に、複数ユーザーのマシンが「stopped」およびゾンビ状態で止まり、再起動・削除・再デプロイのいずれもできなくなった障害事例
- ダッシュボードには「Service Interruption」バナーだけが表示され、status pageには関連情報がなく、原因や復旧 ETA を把握できない
- fly machine コマンドが **「could not get machine」**エラーで失敗し、machine list の作成日が 「1970-01-01」 と表示されるなど、異常なデータを確認
- 一部では fly scale で新しい VM を立ち上げて一時復旧したが、故障した VM は削除できないまま課金が継続する懸念
- 12〜15時間以上、公式の返答やステータス更新がなく、プラットフォームの信頼性低下につながった
障害発生と初期症状
- 朝、アプリのヘルスチェックが失敗し始め、マシンが **「stopped」**状態であることを確認
- ダッシュボードには「We are performing emergency maintenance on a host some of your apps instances are running on」というService Interruptionバナーだけが表示され、それ以外の情報はなし
- status page にはこの障害が表示されておらず、解決手順や ETA を見つけられない
- 停止したマシンインスタンスを再起動・削除しようとするとタイムアウトが発生
- 再デプロイ時に unmanaged マシン関連のエラーが発生
fly deployはメタデータにfly_platform_version=v2があるマシンだけを更新するため、fly machine update --metadata fly_platform_version=v2 <machine id>で個別のマシンを手動更新する必要がある
ゾンビマシン状態と回避方法
- 一部のマシンが **「zombie mode」**に入り、すべての fly machine コマンドに「Error: could not get machine」と応答
- fly scale で VM を追加割り当てしてアプリの可用性は復旧したが、故障した VM は不確定な状態のまま残り、削除もアカウント削除もできない
fly machine listが作成日 **「1970-01-01T00:00:00Z」**のような誤ったデータを表示- 別のユーザーも同様にスケールアップで新しいマシンを作って回避したが、元のマシンは **「connection refused」**エラーで削除できない
- 整理されていないゾンビ VM と追加作成した VM の両方に課金されることを懸念
- ステージング環境も同じ状態
データベースコンテナへの影響
- あるユーザーは約14時間前から同じ問題に遭遇しており、対象がデータベースコンテナのため、単純なスケールアップだけでは復旧できない
- 有料プランで数時間前に support へメールしたが返答なし
- 当該アプリは syd リージョンにホストされており、そこの1〜2台のホストに問題がある可能性に言及
広範な影響と一時復旧
- 昨日までアプリ + Postgres（ステージング・プロダクション）のマシン4台を運用していたが、データベース2つを含む3台がまだダウン
- 当該アプリは会社の外部 API アプリであるため、すべての連携（integration）が停止
- 運用を維持するため Fly に新しいプロジェクトを作ってインスタンスを立ち上げ、環境変数や設定のバックフィルに数時間を要した
- 意図せずDR（災害復旧）能力のテストになった
- DB マシンからデータを取り出す方法はなかったが、メインのプロダクション DB ではなかったため、必要な内容をリバースエンジニアリングして復旧
プラットフォームの信頼性への懸念
- 12時間が経っても公式の返答がないことへの驚きを表明
- 同じ問題を経験したのは2回目で、サービスがダウンしていても Fly は正常と報告し、情報も対応もないため待つしかない状況
- Herokuとの比較：ホストが不安定になると dyno が自動移動されるため、このような心配はなかった
- 小規模で標準的な Rails + Postgres アプリでも発生した問題で、より複雑なアプリなら対応はさらに難しくなるとの懸念
- こうした問題がプラットフォームへの信頼を完全に崩すと表現
1件のコメント
Hacker Newsのコメント
Flyがサポートスレッドに返信: フォーラムは定期的に確認しているが今回はこの投稿を見落としており、sydリージョンでの単一ホスト障害が長引いたと説明
ホストは再起動後に正常復帰できず、サービスディスカバリーにも接続されなかったため、手動復旧が必要だった
複数インスタンスで動かしているアプリは一部インスタンスのみが影響を受けたが、単一インスタンスのアプリは障害中アクセス不能で、Flyは複数インスタンス構成を強く推奨している
グローバル/リージョン障害は status.fly.io に掲載し、単一ホストの問題はダッシュボードのステータスタブに表示してきたが、今回のような長時間の単一ホスト障害におけるコミュニケーション方法は見直し中とのこと
https://community.fly.io/t/service-interruption-cant-destroy...
再起動でも復旧せず、古いバックアップをRDSに復元したが、移行して正解だったと感じている
しかもユーザーコンテナ1つではなく、マネージドPostgreSQLサービスの話のようなので、ホスト障害への耐性を期待する方がなおさら妥当に思える
月 $5〜10 くらいなら払えるが、3日間の障害は望んでいないサイドプロジェクトには使う気になれない
[1] https://fly.io/docs/about/support/
数時間も障害が続いたなら、Ansibleでも何でも使って新しいマシンを立ち上げるべきだったと思う。ハードウェアでもAWS/GCPの仮想マシンでもできたはずだ
Flyがこの問題を隠そうとしているように見える形で、スレッド[1]を未ログインユーザーに対して非公開に変更した
スレッドには、サービスが落ちているのにFlyのステータスは正常表示で、情報もなく待つ以外にできることがなかったという事例があった
別のユーザーは、アプリと staging/production PostgreSQL を含む4台のうち3台が依然として落ちたままで、外部APIアプリが壊れてすべての連携がだめになったと述べていた
新しいFlyプロジェクトを作って一時インスタンスを立ち上げるのに数時間かかり、DBマシンからデータを取得する方法も見つけられなかったという
組織のステータスページが「障害なし」と表示しているのに、同じページでアプリはメンテナンス中かつアクセス不能と表示されるのは侮辱のように感じる、という反応もあった
17時間のあいだステータスページの更新も通知もほとんどなく、Better Stackの通知だけを受け取ったという投稿もあった
スレッド全文のバックアップ: https://pastebin.com/ebmCSZkC
Fly CEOに送ったツイート: https://twitter.com/SouthPawNZ/status/1682181533673857024
[1] https://community.fly.io/t/service-interruption-cant-destroy...
Flyの最悪な点は、何か問題が起きると一つだけ壊れるのではなく、複数のものが同時に壊れ、ステータスページは全部グリーンに見えることだと思う。
反応もたいてい沈黙か、「金曜にデプロイするとこういうことが起きる」といった軽すぎる態度だ。
プロダクトは魅力的に見えるが、私が使ったホスティングサービスの中で最も不安定なものをきれいに包んだような印象だ。
毎週のように人の作業を壊し、週末の夜を復旧に費やさせたうえで「もっとうまくできたはずだった」で済ませることはできない。それは例外への言い訳であって、繰り返されるパターンには通用しない。
このHNスレッドにはノイズも多いが、要点はこうだと思う。社員たちは顧客が気づく前から問題を把握していたようで、有料サポートにメールを送った後も返答までに数時間かかり、停止したホストに関する更新は約20時間後にようやく出た。
影響を受けたユーザーにホスト障害や復旧方法を適切に知らせず、ダッシュボードには緊急メンテナンスを表示しながら、ステータスページでは全面的に正常と表示していた。
プランやアーキテクチャの性質上、こうしたダウンタイムが織り込み済みで珍しくないことは理解できるが、ここまでコミュニケーションが悪いと顧客を失う。
他のプロバイダーのように、自分が載っているホストに少しでも異常があればメールを送ってくれれば、少なくとも自分のアプリについてすぐ何か対応できる。
ただし、自分たちがそういう状態にあったことを十分理解していたかどうかについては意見が分かれる。
特定の1台のサーバーで異常に長い障害が起き、それらが重なって、多くの人が説明のない長時間障害を経験した。
ダッシュボードはリージョン／サービス障害しか表示せず、個別サーバー障害は表示しないため、人々はそれを知らず、虚偽表示のように受け取った。
Discourseのタグ設定の奇妙な挙動のせいで、問題を隠そうとしているようにも見えた。
要するに、運が悪く、顧客対応の手順も悪く、ドキュメントも一部不足していたかもしれないが、炎上というより煙の多い出来事だったと見ている。
タイムラインはUTC基準で、2023-07-17 16:19にホストダウン、16:49にパーソナライズされたステータスページを掲載、2023-07-19 15:00にホスト復旧、15:17にステータスページを解決済みと表示した。
[1] https://community.fly.io/t/new-status-page/11398
Fly.ioはHerokuクローンになりたくなかったが、マーケティングと洗練されたユーザー体験のせいで、結局そう見えるようになった。
その結果、単一ホスト障害のたびにブランドに大きな打撃を与えかねないHeroku的なユーザー層まで相手にすることになった。
遊びの個人プロジェクトだったので構わなかったが、もっと真剣な用途なら使いやすいかは分からない。
それに、20時間のダウンタイムを「織り込み済みで正常」と呼べるようなクラウドプロバイダーがそんなに多い、というのは納得しがたい。
残念ながら、Fly.ioが関わるHNスレッドではかなりの受動攻撃的な態度をいつも感じてきた。
Fly.ioを本当に好きになりたかった。設定も利用もとても簡単だが、正直言ってミッションクリティカルなアプリケーションをこのサービス上に載せるべきではないと思う。
最終的には全部AWSに移したが、本当はそうしたくなかった。
マシンはしばしば起動せず、ランダムな障害が起き、ビルドは失敗し、サポートのために上位ティアへ課金したのに、サポートは反応が遅く質問もきちんと読んでいなかった。
サイドカーを追加できず、外部監視との統合も難しく、ドキュメントはハッピーパスには十分でもエッジケースではかなり不足していた。
趣味プロジェクトには向いており、今でも個人プロジェクトをたくさん載せているが、会社のインフラとしては時間コストとフラストレーションが大きすぎて移行せざるを得なかった。
Herokuの精神的後継者のように聞こえて期待していたが、まだその水準ではないと思う。
前週にはビルドでき、ローカルでも問題なく、後になってFlyでもまた通るようになったが、原因の説明もサポートの返答もない理解不能なダウンタイムだった。
無料ティアは非常に寛大で、課金上限未満でもいろいろできるが、私は自由時間が少なく、その時間にはただプロジェクトをビルドしたいだけだ。
Nodeでビルドする小さな静的サイトにすぎなかったのにそうなった。
ツール自体は素晴らしいので、インフラが安定したらまた使ってみたい。
同じ労力でその情報をドキュメントに入れられないのだとしたら、ドキュメント化パイプラインがどれほど悪いのか分からない。
利用に関するフォーラムの質問への答えは、「ドキュメントにあります。なければ今追加しました」と「分かりづらければ教えてください。ドキュメントを更新します」であるべきだ。
自分でflyログを掘って、プロキシがサーバーに到達できていないことを確認するしかなく、私に直せる方法はなかった。
数時間後にフォーラムへ issue を投稿したが、返答も既読の痕跡もなく、しばらくしたら魔法のように直っていた。
成功してほしいと思っているが、このコミュニケーション不足と何もできない無力感のせいで、当面fly.ioは使わないだろう。
あまり満足のいく答えではないですが、個人的に言えるのはこの程度です。私たちのコミュニティサイトのこのスレッドがなぜ一覧から外れていたのかは、まったく分かりません。
管理者UIを見ていますが、投稿の横に小さな鍵はあるものの、「unlist story」オプションは依然としてクリック可能な状態です。
私が言える最善のことは、このスレッドを隠せという上からの指示があったとはかなり確信していない、ということです。サイトは公開されており、誰でもアカウントを作ってスレッドを見ることができます。
私たちについて何を言っても構いませんが、こういうことを隠れるのは私たちの欠点の一つではありません。
Sydneyサーバーの問題については、まだ十分に把握しておらず、そこでインスタンスを動かしていた人たちの助けになる答えはできません。外出から戻って、今まさに状況を把握しているところです。
すぐに確認したところ、app-not-workingカテゴリーのすべての投稿が「private」のように見え、たぶんカテゴリー設定のようです。ここでのprivateは、Discourseアカウントに登録しないと見られないという意味です。
この回答のトーンや他のfly.ioのコミュニケーションを見ると、fly.ioに対する世論を考えれば、そうした要素が不足していることの表れに見えます。
従業員が60人以上いて、問題がこれほど多いのであれば、人間味のある親しみやすいトーンというより、スケールできていないビジネスの兆候に見えます。
成長するB2B事業が成功するには、プロセスや監督のようなものが必要ですが、他の回答を見る限り、そういったものを望んでいないように見え、それは良くない兆候です。
1回壊れれば事故、2回壊れれば不運、しかし3回壊れればプロセスが壊れているということです。ここでのコメントを見ると、Fly.ioでは3回どころではなくもっと頻繁に壊れているようです。
障害そのもののせいではなく、サポートを受けるまでに数日かかる可能性があるからです。
次はサポートがもっと良くなると、コミュニティにどんな保証ができますか？
私たちは2022年4月から https://changelog.com をFly.io上で運用しており、現在のアーキテクチャは https://github.com/thechangelog/changelog.com/blob/master/IN... にあります。
15か月の間、Fly.io上のPhoenix + PostgreSQLアプリで1億件以上のリクエストを処理してきましたが、不満を言う理由はほとんど見当たりません。
何度かデプロイに失敗しましたが、パイプラインの再実行で直りましたし、2023年7月初旬にはFrankfurtで9千件のリクエストが10秒間503を返し、machines実験中に削除されなかったボリュームが1つ翌日に消えた、という程度でした。
KaizenポッドキャストではFly.ioでの経験をよく話しています: https://changelog.com/topic/kaizen
マイグレーション発表のエピソード: https://changelog.com/shipit/50
関連PR: https://github.com/thechangelog/changelog.com/pull/407
apps v1(Nomad) から apps v2(flyd) へのマイグレーション計画についても最近話しました: https://changelog.com/friends/2#transcript-138
多くの人が良い体験をできていないのは残念ですが、Fly.ioは今後も良くなっていくと思います。いつかこの大変な時期が良い物語になることを願っています。
希望を持てる投稿: https://community.fly.io/t/reliability-its-not-great/11253
fly.ioのことはかなり好きですし、成功してほしいと思っています。難しいことをやっているのだから、壊れること自体はあり得ます。
ただ、コミュニケーション不足は残念で、特に3月にCEOがコミュニティへ投稿した大きな信頼性に関する記事で、自ら改善したいと名指ししていた部分でもあるだけに、なおさら惜しいです。
https://community.fly.io/t/reliability-its-not-great/11253#s...
影響を受けたユーザーのダッシュボードには単一ホスト障害を表示し、プラットフォーム/リージョンの問題はステータスページに反映してきましたが、伝えている状態と実際のユーザー体験が一致しない中間地帯が明らかに存在します。
最近は容量問題を避けるためにハードウェアを大幅に追加しており、予想通り全体的な障害確率は下がった一方で、ハードウェア由来の障害件数は増えました。
ユーザーがこうした問題を避けられるよう支援すること、復旧をより速くすること、影響を受けた際にもっと適切に知らせること、そのすべてでもっと改善できます。
私たちがコミュニケーションで失敗していても、こうしたフィードバックには耳を傾けています。
より大きな危険信号は、Fly には故障したサーバーから正常なサーバーへワークロードを素早く移す自動化された方法がないように見えることだ
コンテナやオーケストレーターが接続・切り離し可能なデータボリュームという概念を抽象化しているにもかかわらずだ
もちろん、これを提供するには大きな技術投資が必要であり、ビッグ3クラウドでストレージが高価な理由の1つでもあると思う。それでも、データ永続性サービスを提供するなら必須の能力だ
Fly が提供したいものと、市場が期待しているものの間に食い違いがある
Fly は複数のデータセンターでアプリを実行できる革新を目指していたが、まともなデータ永続性サービスなしでは、その機能は大多数にとって有用ではない
SQLite のレプリケーションで永続性の問題を解こうとしているようだが、そうなると大多数の開発者は Fly プラットフォームに合わせてアプリの開発方法を変えなければならない
Fly は、安定していて安価な Heroku の代替になるのか、それとも世界中のユーザーに最高の性能を与える独自のアプリ開発方式を提示するのかを選ぶ必要がある
App Engine は興味深い事例だ。時代を先取りし、非常に高いトラフィックまでスケール可能な開発方式を提示していたが、人々はそれに合わせて開発方法を変えたがらなかった
今は1つ火を消すとすぐ別の火が出るような形で右往左往しているように見え、技術ロードマップに信頼が持てない
多くの人が Fly.io を「あとでまた確認」リストに入れてから、もう2年ほど経っているのではないか？
人々に不安定だと認識されると評判の回復は本当に難しく、特に IT 分野ではなおさらだ
データ永続性は、24時間ごと、または手動で作成した LVM スナップショットを S3 にエクスポートする方式だ
永続ワークロードを動かす場所ではまったくないと思う。そこで PostgreSQL を動かすなら、新しいインスタンスへデータをホットロードするか、バックアップから復元する準備が必要だ
同じ理由で、以前から HN では Fly を使うなと言われてきた: https://news.ycombinator.com/item?id=31394179
アカウント削除を依頼したあと、何のコミュニケーションもなく自分のアカウントが一種のシャドウバン状態になった
メールも送ったが、今に至るまで返答は一度もなく、その後すべて Railway アプリと Google Cloud Run に移した
無害な質問をしただけで、なぜ会社がシャドウバンするんだ？
興味深いのは、Fly.io では歴史が繰り返されているように感じることだ。最初に Heroku に出会ったときに似ている
昔の Fly.io は、Heroku が最初に登場したときのように新鮮で面白く、シンプルさと使いやすさに感心した
しかし時間が経つにつれて小さな問題の兆候が見え始め、ダウンタイムが増え、速くて滑らかだったデプロイも苦痛なほど遅く感じられるようになった
Heroku の長所が失われ始めた頃のデジャヴのようだ
より多くの人がプラットフォームに集まるほど性能が悪化し、人気が高まるほど安定性が低く見えるという道を、Fly.io もたどっているようで残念だ
有望なプラットフォームもこうして転落しうることを示す警鐘のように感じられ、Fly.io にはこの循環から抜け出し、Heroku のどん底のように役に立たない存在になる前に踏みとどまってほしい
業界の良心を過大評価していたのではないかと思ったし、Heroku のように広く知られるようになれば、金を払いたくない人たちが殺到するのは目に見えていた
寛大な無料提供を再び試みるには、強力で高コストな不正利用対策組織があるか、あるいは初期の不在を埋められるだけのハードウェアを投入できる潤沢な資金が必要だ
Fly はそのどちらも強そうには見えない。だからこそ好きな面もある。そういうものは大企業的な無駄に見えるし、Fly にはそういう臭いがあまりしない
しかし、Fly のエンジニアたちが長期的なインフラ信頼性や開発者体験よりも、ただ乗りの暗号資産マイナーや詐欺師、濫用者への対処と、リソース割り当てや自動制限の最適化に大半の時間を使っていても驚かない
規模と関係があるのか気になる。会社が収益性や投資可能性が見えるだけの有料顧客を確保する頃には、同時に十分な問題も積み上がっていて、最初の新鮮で面白い感覚から、徐々に置き換えようとしていた古い競合のように変わっていくのではないか？
私の経験でもそうだった。会社がピザ数枚の規模から「会場を予約した」レベルまで大きくなると、エントロピーが忍び込み、コンウェイの法則や Brooks の法則のような格言がますますはっきり見えてくる