Erlangの99.9999999％（ナインナイン）の信頼性

アーランは、稼働システムで20年以上使用されており、稼働率は99.9999999％であると報告されています。

私は次のように計算しました：

20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s

つまり、システムのダウンタイムは20年間で1秒未満です。私はこれの妥当性に異議を唱えるつもりはありません。たった0.631秒でシステムを（故意にまたは偶然に）シャットダウンする方法に興味があります。大規模なソフトウェアシステムに精通している誰かがこれを私たちに説明できますか？ありがとうございました。

処理ユニット（またはマシン）のクラスターでサービスのダウンタイムを計算する方法を知っている人はいますか？

信頼性の数値は、AXD301（問題のプロジェクト）のいずれかの部分が20年以上シャットダウンされた合計時間を測定するためのものではありませんでした。これは、AXD301システムによって提供されたサービスがオフラインであったこれらの20年間の合計時間を表します。微妙な違い。Joe Armstrongがここで言うように：

AXD301は、ナインナインの信頼性を達成しました（そうです、あなたはその通りに読みます、99.9999999％）。これを文脈に当てはめてみましょう。ファイブナインは良いと見なされます（年間5.2分のダウンタイム）。セブンナインはほとんど達成できません...しかし、私たちは9をしました。

どうしてこれなの？共有状態はなく、高度なエラー回復モデル。

Erlangの原作者であるJoeが書いた博士論文（のケーススタディを含むAXD301）を少し深く掘り下げると、次のようになります。

この章で説明するプロジェクトの1つは、高性能で信頼性の高いATMスイッチであるエリクソンAXD301 です。

したがって、スイッチが含まれていたネットワークがダウンタイムなしで稼働している限り、著者は「ナインナインの信頼性」について述べることができますAXD301（これまで彼が言ったことはすべて、詳細は避けました）。Erlangがそのような高い信頼性の唯一の原因であるとは限りません。

編集：実際、「20年」自体は誤解のように見えます。Joeは同じ記事で20年という数字について言及していますが、実際には、はるかに短い研究から得られた可能性がある（他の人が述べたように）ナインナインの信頼性の数字とは関係ありません。

他の人はあなたが尋ねている特定のケースに対処しましたが、あなたの質問は誤解に基づいているようです。あなたが質問をした方法は、システムがクラッシュしたり、メンテナンスのために停止した後に、システムを再度実行するための手動のプロセスがあると考えていることを私に信じさせます。

Erlangには、ダウンタイムの原因として人間の作業時間を取り除くいくつかの機能があります。

1. ホットコードの再読み込み。Erlangシステムでは、既存のモジュールの代わりのモジュールをコンパイルしてロードするのは簡単です。BEAMエミュレータは、明らかに何も停止することなく、自動的にスワップを行います。この転送が発生する時間はごくわずかですが、人間の時間ではなく、コンピュータの時間で自動的に発生します。これは本質的にアップグレードを行うことを可能にするゼロダウンタイム。（交換用モジュールにシステムをクラッシュさせるバグがある場合、ダウンタイムが発生する可能性がありますが、それが本番環境にデプロイする前にテストする理由です。）

2. 監督。ErlangのOTPライブラリには、監視フレームワークが組み込まれており、モジュールがクラッシュした場合のシステムの反応を定義できます。ここでの標準的なアクションは、失敗したモジュールを再起動することです。再起動されたモジュールがすぐに再度クラッシュしないと仮定すると、システムに対して請求される合計ダウンタイムは数ミリ秒の問題になる可能性があります。クラッシュすることがほとんどない強固なシステムは、実際には、何年にもわたる実行時間にわたって合計ダウンタイムの1秒のほんの1秒しか蓄積しません。

3. プロセス。これらは、他の言語のスレッドにほぼ対応していますが、永続的なデータストアを使用しない限り状態を共有しません。それ以外は、メッセージパッシングを介して通信が行われます。Erlangプロセスは非常に安価（OSスレッドよりもはるかに安価）であるため、疎結合設計が奨励され、プロセスが停止しても、システムのごく一部のみがダウンタイムを経験します。通常、スーパーバイザはその1つのプロセスを再起動しますが、システムの他の部分にはほとんど影響を与えません。

4. 非同期メッセージパッシング。あるプロセスが別のプロセスに伝えたい場合、Erlang言語にはそれを可能にするファーストクラスの演算子があります。メッセージ送信プロセスは、受信者がメッセージを処理するのを待つ必要がなく、送信されるデータの所有権を調整する必要もありません。Erlangのメッセージパッシングシステムの非同期機能の性質は、これらすべてを処理します。これにより、システムのある部分のダウンタイムが他の部分に及ぼす影響を低減できるため、アップタイムを高く維持できます。

5. クラスタリング。これは前のポイントから続きます。Erlangのメッセージ受け渡しメカニズムは、ネットワーク上のマシン間で透過的に機能するため、送信プロセスは、受信者が別のマシン上にあることを気にする必要さえありません。これにより、ワークロードを多くのマシン間で分割する簡単なメカニズムが提供されます。各マシンは、システム全体の稼働時間を損なうことなく個別にダウンできます。

99.9999999％の可用性の数値は、よく引用されますが、根本的に誤解を招く統計です。AXD-301チームメンバーの1人であるMats Cronqvist がプレゼンテーションを行いました （ビデオ）サンフランシスコで開催された2010 Erlang Factoryカンファレンスで（私が参加した）を行い、この正確な可用性統計について説明しました。彼によると、それはAXD-301を使用した「5ノード年」の試用期間（私は2002年1月から9月と信じています）のためにブリティッシュテレコムによって主張されました。トライアルの終わりまでに14のノードがライブトラフィックを運んでいました。

Cronqvistは、これはAXD-301の歴史全体またはErlang全般を表すものではなく、Joe Armstrongがこれを引用し続けてErlangの信頼性に過度の期待をもたらしたことに不満を抱いていると明確に述べました。他の人は、ファイブナインがより現実的な図であると書いています。

私は、Erlangの熱心なサポーター兼開発者であり、Erlangの専門家の使用が非常に高可用性システムにつながる可能性があると信じていますが、誇大広告を減らしたいだけです。もちろん、Cronqvistによる事実の表現は正確であり、そうでないと信じる理由は何もないと思います。

それらの統計についての私の理解は、それが生産中のすべてのAXD301システムで計算されるということです。AXD301に深刻な問題がある場合、0.631秒以上ダウンすることが予想されます。この期間中、他のAXD301が引き継ぎ、ネットワークの運用を維持します。

ただし、実行中のすべてのAXD301の合計時間数を合計すると、障害が発生したAXD301の比率を作成すると、99.999999％になります。

それが私がこの図を理解する方法です。

この助けを願っています。