ユン氏による公開自己批判が話題に：私たちは信頼できない、ネットユーザー：わかっています！

​コンピレーション|影

企画 |趙雲

クラウドネイティブ時代において、信頼性の高いクラウド製品を選択することは、アーキテクチャを設計および展開する際に技術者が直面しなければならない困難な問題となっています。メモリ、容量、データベース、トラフィック課金などはすべて一般的なオプション パラメーターです。

しかし、公式サイトで「高可用性、弾力的な拡張性、リアルタイムスケーリング」を謳う製品は本当に信頼できるのでしょうか？

著名なクラウドサービスプロバイダーである Fly.io のリーダーによる「自己レビュー」が、すべての人に答えを与えてくれるかもしれません。

アメリカのスタートアップ企業である Fly.io は、アプリケーション サーバー プロバイダーです。無料パッケージを考慮しなくても、価格は非常に手頃なので、無料割り当てを超えた後の価格を心配する必要はありません。特にコンテナの導入に関しては、導入が非常に簡単でコスト効率が高いため、開発者の間で非常に人気があります。そのため、近年の発展は極めて急速ですが、急速な発展が必ずしも良いこととは限りません。

最近、「自己検査」ブログ投稿「信頼性: あまり良くない」が Fly.io コミュニティで人気となり、すぐに話題になりました。ネットユーザーたちは「正直に言ってくれてありがとう！」と叫んだ。

原文は次のとおりです。

過去4か月間は大変でした。私たちには対処できる以上の問題があります。

私がこれを共有することを躊躇していたのは、失敗という衰弱させる感覚に苦しんでいたからです。改善しなければ会社は消滅してしまいますが、私はこの会社で働くことを本当に楽しんでいます。

私たちが直面した興味深い問題は、私たちの人気が爆発したことでした。なんと素晴らしいことか！しかし、私たちはプラットフォームの当初の設計意図を超えてしまいました。私たちは、プラットフォームの拡大とエンジニアリング組織の改善に多大な労力とリソースを投入してきました。しかし、もう遅すぎました！

しかし、ユーザーにとって、クラウド製品の人気は気になりません。実際には、ユーザーは自信を持ってアプリを公開したいだけなのです。

これが私たちが製品に求めるものです。しかし、それは大変な苦労であり、私たちは本来すべきほど努力していません。我々は全員開発者なので、いくつかの「汚い詳細」を明らかにする必要があります。

1. 公開された詳細

編集者注: Fly.io は、Web サイトの所有者が顧客と簡単に接続できるように設計されたアプリケーション配信ネットワーク (ADN) を提供するアプリケーション サーバー プロバイダーです。同社のアプリケーション配信ネットワークは、サーバーのグローバル ネットワークを使用して訪問者のトラフィックを受け入れ、リクエストに基づいてミドルウェアを実行し、それらをバックエンド アプリケーションにルーティングします。これにより、Web サイトの所有者は、数回のクリックだけで訪問者を安全なアクセスに誘導できます。

私たちのプラットフォームは、率直に言えば、一連の可動「パーツ」であり、これらはすべて連携して動作する必要があるため、アプリケーションを展開し、再度展開し、いったん離れてから 24 か月後に再び戻ってきても、まだ動作していることを確認できます。これが達成される理由は次のとおりです。

• データベースの認証と CRUD のための集中型 API。

• 組織のプライベート ネットワークに接続するための WireGuard ゲートウェイ。

• アプリケーションを Docker イメージにビルドするために使用されるリモート Docker ビルダー仮想マシン flyctl。

• これらの Docker イメージを保存するグローバル Docker イメージ レジストリ。

• 秘密の保管庫

• VM で Docker イメージを起動するスケジューラ (最近は主に Nomad)。

• サービス検出は、インフラストラクチャ内で実行されているすべての VM に関する情報を配布します。

• アプリケーション インスタンスにトラフィックをルーティングするプロキシ。

• アプリケーションを相互に接続するネットワーク インフラストラクチャ。

しかし、上記のすべては、実に驚くべきことに、非常に失敗した方法で実行されました。もちろん、ユーザーが発見して気づかなかったことに感謝しています。以下は、過去 4 か月間に発生した最も重要な事件の一部です (順不同)。

（１）サービスの発見と腐食

（２）機密情報の集中保管

（３）ポストグル

（４）容量の問題

（５）ホストハードウェアに固定された容量

（6）ステータスページング

2. サービスの検出と腐食

インターフェースの有効期限、内部DDos

あらゆる地域での活用事例や健康情報を発信します。こうすることで、プロキシはリクエストをルーティングする場所を認識し、DNS サーバーは返す名前を認識します。

この操作には HashiCorp Consul を使い始めました。しかし、私たちは Consul をグローバル サービス検出の役割に押し込めましたが、それは Consul には不向きでした。 Consul には、単一のデータセンターに展開するために設計された集中型サーバー モデルがありました。その結果、データが永続的に古くなり、プロキシは時代遅れのインターフェースにルーティングされ、独自の DNS には古い用語が含まれることが多くなります。

これらすべては、すべての状態更新 (すべての VM の起動と停止) を中央のサーバー クラスター (多くの場合、大陸をまたいで) を介してラウンドトリップで実行した結果です。

この目的のために、私たちは Corrosion というプロジェクトをリリースしました。 Corrosion はゴシップベースのサービス検出システムです。仮想マシンが起動すると、ホストはインスタンス情報を公開します。 Corrosion の目標は、1 秒未満 (可能な限り瞬時に近い) で世界中に変更を伝播することです。

しかし、ゴシップに基づく一貫性の問題が課題となっています。 Consul がユーザーに多大な迷惑をかけたため、私たちは Corrosion プロジェクトをすぐに閉鎖しました。新しいソフトウェアは2度問題を引き起こしました。どちらも、グローバル サービス検出状態が壊れていることを示します。

最初の発生は、当社のプロセスの 1 つが Corrosion をスパムして更新を行い、実質的に内部 DDoS 攻撃になったときに発生しました。 2 回目は定期更新中に発生し、実際にデータベースが混乱しました。

これら 2 つの問題の結果として、アプリケーションは展開中に壊れてしまいます。仮想マシンの登場と廃止に伴い、プロキシ サーバーと DNS サーバーは古くなったデータを処理できなくなることが分かりました。

腐食は破損に対して十分な耐性が必要です。私たちはこれを改善するために段階的なステップをいくつか実行しています（例：レート制限、「内部 DDoS」リスクの軽減）。同時に、アーキテクチャの変更にも取り組んでいます。ゴシップ パターンは、問題のある特定のノードを追跡するのが容易ではなく、急速に広がるため扱いにくく、これはまさに望ましくないことです。

Nomad を削除すると、腐食の問題も軽減されます。 Nomad はデプロイメントごとにまったく新しいインスタンスを作成するため、サービス検出の変更が多く発生します。毎秒多くのイベントが更新されます。幸いなことに、Fly のマシンベースのアプリケーションはそれほど複雑ではありません。マシン上で実行されているアプリケーションを更新すると、その場で更新されます。

最終的に、問題はサービス検出の域を超え、1 週間でプラットフォームに多くの変更が展開されました。変更がユーザーと競合する場合があります。アプリケーションのデプロイメントがタイミングが悪いと、アプリケーションが不安定な状態になる可能性があります。この期間中にアプリケーションのデプロイメントを一時停止するために、ツールを更新しています。紛争が発生した場合、その理由を可能な限り明確に説明します。

3. 集中型秘密ストレージ

検索に失敗しました。アクセスできません

アプリケーションシークレットは HashiCorp Vault に保存されます。 HashiCorp Vault は、サーバーの中央クラスターを備え、Consul と非常によく似た動作をします。

Vault で発生した問題は、Consul で発生した問題とほぼ同じくらい深刻でした。新しい VM が起動するたびに、それを実行するワーカーは Vault からシークレットを取得する必要があります。これには 2 つの基本的な問題があります。

• Vault は米国にあり、遠隔地 (MAA など) と米国間のインターネット接続により機密情報の参照が失敗する可能性があります。

• 障害状態によっては、金庫にアクセスできなくなる場合があります。たとえば、Vault サーバーの 1 つに障害が発生し、広範囲にわたる VM 作成の失敗が発生しました。

サービス検出と同様に、Nomad はこれらの問題を悪化させますが、Fly Machines はそれらを緩和します。しかし、Vault の状態が悪い場合は、新しい Fly Machine の作成も失敗します。

既存のオープンソースは、グローバル展開向けに設計されていません。したがって、既存のインフラストラクチャ ソフトウェアを「購入」することを選択した場合、ある程度、世界規模での回復力に対して支払うことになります。

4. Postgres クラスター

非監護型を選択するという誤った決断を下した

私たちの Postgres クラスターには、Stolon クラスターと Consul クラスターへのライブ接続への依存と、「管理されていない Postgres」に対する誤った期待という 2 つの主な問題がありました。

1 つ目はアーキテクチャ上の問題です。 Postgres が依存する Consul クラスターは、サービス検出に使用するクラスターとは異なりますが、それでも奇妙な方法で「失敗」します。 Fly Postgres の最初のイテレーションで構築した Postgres クラスタリング ソフトウェアである Stolon は、Consul 接続をうまく処理できませんでした。

新しい Postgres クラスターでは Stolon は使用されず、代わりに repmgr が使用されます。 epmgr はクラスター内のリーダー選出を処理するため、2 番目のデータベースは不要になります。これらの新しい Postgres クラスターは、構成情報を共有するために Consul を引き続き使用しますが、Consul がクラッシュしても、クラスターは引き続き動作します。

以前に構成された Postgres DB を新しい repmgr セットアップにアップグレードする作業を進めています。多少の難点はありますが、引き続き公開していきます。

Postgres の 2 番目の問題は、それが誤った決断だったことです。適切なマネージド Postgres プロバイダーが登場するまでの時間を稼ぐために、「アンマネージド Postgres」を立ち上げることにしました。問題は、「fly-pg create」は管理された Postgres クラスターを取得することを意味します。これは、「シンプルな Postgres を取得する」機能を備えた各サーバーが、ユーザーに管理されたスタックを提供するためです。

これは私たちにとって非常に痛い教訓です。結局、ユーザーエクスペリエンスについて多くの約束をしましたが、それを実行することはできませんでした。私たちは価値観のスローガンを書くような会社ではありませんが、もしそうするなら、「開発者の期待に反して迷惑な疑似サプライズを作らない」というスローガンを追加するでしょう。

マネージド Postgre に対応できるようになるまでにはしばらく時間がかかりますが、これは当社のインフラストラクチャ スタックのコア コンポーネントであり、必要ではないふりをすることはできません。

5. 容量の問題: 当然のこととして受け止める

新規ユーザーの流入により、複数の地域でサーバーの容量が枯渇し、場合によっては複数回枯渇することもありました。これは 2 つのレベルで失敗でした。1 つは、サーバーの購入に十分迅速に対応しなかったことです。第二に、特定の領域における圧力を軽減するための優れたツールがありません。

昨年は、たとえ容量の問題があっても、特定のエリアで新規ユーザーの起動を阻止できると当然のことと考えていました。しかし、私は顔を平手打ちされました。

Heroku は、複数のプログラミング言語をサポートし、私たちが当たり前だと思っていた概念を打ち破るプラットフォームです。 Heroku 以前は、実行していたアプリケーションのほとんどは複数のリージョンにまたがっていました。そして、私たちは毎月約15％成長しています。しかし、Heroku 導入後は、アプリケーションの流入が月間 30% と非常に多いホットスポットがいくつかあるだけです。

振り返ってみると、資金がまだあったときにもっと早く始めるべきでした。

キャパシティプランニングとロジスティクスはますます向上しています。キャパシティプランニングを私のToDoリストに入れました。会社には私よりも優れた能力を持った人が必要です。私たちは再雇用し、再編成し、状況は改善し、しかも急速に改善しています。

6. ボリュームはホストハードウェアに制限されます

メモリ不足によりシステムがクラッシュする

fly-volumes コマンドは、特定のホスト ハードウェア上にブロック デバイスを作成します。最初に公開したとき、このアプローチの限界を説明するコンテンツがたくさんありました。ボリュームは 2 以上の単位で実行されるように設計しました。

つまり、現在使用しているホストの容量が減ると、アプリケーションが停止します。ホストにアプリケーション VM を実行するのに十分なメモリまたは CPU がない場合、デプロイできない可能性があります。

しかし、ドキュメントが改善されるにつれてこれらの詳細は失われ、いくつかの厄介な驚きをもたらしました。これも直感に反します。人々は AWS EBS の魔法に慣れています。しかし、私たちのボリュームは EBS ではありません。

これは、UX が誤った期待を生み出すもう一つの例です。

7. ステータスページング：自社製品を自慢しあいまいな回答をする

弊社のステータス ページには、多くの正当な批判を受けた曖昧な投稿がいくつかありました。その一方で、私たちは恥ずかしげもなくブログで自分たちのスキルを自慢しています。問題が発生しましたが、問題が発生したときに、私たちは積極的にコミュニケーションを取りませんでした。

私たちは仕事に夢中になり、当初の意図を忘れてしまいます。ここで私が書いている課題のいくつかは、「コンピュータ テクノロジー」の観点から見ると難しいものです。しかし、この質問はそうではありません。これは許しがたいことであり、すぐに連絡を取る必要があります。

私たちはインフラストラクチャ/運用チームを構築するために本当に優秀な人材を採用しました。曖昧な投稿を削除するチームを強化するとともに、インシデント対応を標準化しました。開発者が問題に遭遇した場合、情報をより早く取得できるように、処理チェーンをできるだけ短くしたいと考えています。

パーソナライズされたステータス ページも開始しました。規模が大きくなるにつれてサーバーの数も増え、ハードウェア障害が発生する可能性も高まります。このため、完全に透明なステータス ページを維持することが困難になります。パーソナライズされたステータス ページにより、ハードウェア障害の影響を受けた特定の顧客に対して、「この地域に不良ドライブがあります。現在、修復中です」と簡単に伝えることができます。

8. 結びの言葉

Fly.io の顧客の多くは、この自己検査を理解できると述べました。 「これは難しいプロセスであることは確かですが、この大変な作業こそがあなた自身と顧客にとって長期的な価値を生み出すのです。」

「頑張ってください！透明性には感謝していますし、スタートアップのベテランとして同情します。最近、Fly に何度かがっかりさせられましたが、私はまだ有料顧客であり、皆さんが成功すると信じています。」

欠点が利点でもあると考える人もいます。「たとえば、ボリュームは EBS のように浮動するのではなく、ホストにバインドされます。これは利点です。EBS は遅くて高価です。データベースを実行するときは、マシン上のボリュームを選択します。マシン間でディスク イメージを移動する必要がなく、ボリュームまたはデータベースの信頼性の高いバックアップを作成する必要があるためです。」

実際、この記事で取り上げた問題の多くは、多かれ少なかれ他のクラウド製品でも発生します。 「自己点検」を公開することで、誰もが自分が使用している製品の弱点や、その対策について知ることができます。 Fly.io はかつてないほどの信頼と好意を獲得しています。

結局のところ、「透明性」こそが信頼を得るための最良の方法です!

オリジナルリンク: https://community.fly.io/t/reliability-its-not-great/11253/2