規模に応じた信頼性の高いプロセッサ性能の保証
データセンターのインフラ管理にデータを活用
今日のデータセンター環境では、困難をしなやかに乗り越え回復する力が鍵となります。クラウドプロバイダーはas-a-serviceのビジネスモデルに基づいて構築されており、アップタイムが顧客の事業継続性を確保するために重要となっています。評判と競争力を保つには、計画外のダウンタイムやエラーを許さない、極めて高いパフォーマンス、低消費電力、高機能のサービスが必要です。
貴社がハイパースケーラー、あるいはハイパースケーラーにチップを供給しているのであれば、何十万台ものサーバーを持つシステムにおいては、時折本来の役割を果たさないCPUに遭遇する可能性があることをすでに理解していることでしょう。場合によっては、こうしたエラーを即座に検出したり、フラグを立てたりすることができない形で起こりますし、計算が間違った結果を出すこともあります。また、特定の命令が思ったようには正確に動作しないことだってあります。 さらには、エラーに一貫性がないため、再現性のある問題よりも発見するのが難しいこともあります。
ひとたびこのような問題が発生すると、追跡に非常に時間がかかることがあります。
こうした問題は、チップの設計や使用方法のせいではなく、半導体業界全体がコストを削減し、パフォーマンスをこれまで以上に向上させるために、微細化し続けるプロセス形状を使用していることに起因します。プロセスが縮小するにつれて、チップの動作はますます変化しやすくなります。これに加えて、長期間の使用によって特定のパラメータが変化した場合は問題を明らかにすることが難しく、またそれを乗り越えるにはコストがかかります。
実例紹介
Facebook のケースを見てみましょう。同社の 2021 年 2 月の文書「サイレント データ破損による大規模なデータ破損」[1] で説明されているように、ファームウェアのアップグレードにより、同社のある1か所のデータセンターにおいて突然、ランダムな問題が発生し始めました。1年半の間に、この問題は 1 つのプロセッサ チップ内の 1 つのコアにある程度限定され、それが数学ソフトウェア パッケージ Scala が非常に特殊な計算から誤った結果を返す原因となっていたことが明らかとなりました。
数値の計算の整数部分: 1.153 が、156 であるべきときにゼロとして返されました。システムにはこれをエラーとして示すものはありませんでした。このコアは 1.152 という正しい結果を出しましたが、パワーが 53 のときはゼロと答えました。この数値はファイルを圧縮した後のファイル サイズとして返されるため、システム ソフトウェアはファイルが存在しないか、基本的に失われたと判断しました。大変良くない状態です。
Google は 6 月に同様の話を自社の論文「カウントされないコア」で共有しました[2]。Google の場合、プロセッサ上の「mercurial」コアは予想とは異なる動作をしましたが、問題はすべてのプロセッサ チップの特定のコアに限定されていたため、Facebook の原因よりも発見が若干容易でした。Google はこれらを「破損した実行エラー（CEE）」と名付けました。これは、Facebook によって報告された一部の SDC (サイレント データ破損) の新たに発見された原因です。
これらは、決して検出されない誤った答えを引き起こす可能性があります。 ストレージ、メモリ、または I/O のエラーとは異なり、エラー修正を適用できないため、CEE を修復するのは困難です。Googleは、シリコンプロセスの微細化に伴い、この問題はますます困難になると予想しています。エンジニアとしての何十年にもわたる経験から、この問題を調査していたチームは、欠陥のあるコアを突き止め、隔離することができました。
Microsoft は、2020 年 5 月の OCP Global Summit において自らの考えを発表しました[3]。 具体的に同社が取り組んだ問題については明らかにしませんでしたが、大規模なシステムでは定期的に問題が発生するため、代わりにエラーを報告する統一的な方法を提案しました。同社は、現在のクラウドスケールHWの障害診断の課題について、明確で包括的なエラー報告の欠如、新たな障害の根本的な原因を特定するために必要な遠隔測定ソリューションのギャップ、標準ベースのエラー報告の欠如に起因するカスタムエラーログフォーマットなどの理由を挙げています。
その結果、「問題なし」の割合が高くなり、HWコンポーネントの交換率が高くなり、HW故障の緩和策の特定に費やす時間が長くなり、クラウドに対応していない複数のベンダーのツールを統合することになります。Microsoft は、業界全体が一致団結して、エラーを定期的に報告し、ソフトウェアによる修正の実現を望んでいます。
なぜこのようなことが起こっているのか？
半導体プロセスが微細化するにつれ、チップ・プロバイダーが直面する問題はますます複雑になっています。ノイズの問題は悪化し、メタルラインは時間とともに抵抗値が変化し始め、トラップされた電荷は使えば使うほどトランジスタの挙動を変化させます。このような影響が重なると、非常に綿密な量産テスト・スイートに対しては正しく挙動するチップでも、予期せぬ問題を引き起こす可能性が大きくなります。
一方、今日のプロセス形状ではトランジスタを計画どおりに動作させることがますます困難になっているため、半導体製造プロセスの規律は継続的に厳格化する必要があります。チップごとのばらつきが大きくなり、チップが仕様どおりに動作するかどうか、あるいは信頼性をテストできるかどうかを予測することが困難になります。
これらの問題は新しいものであり、頻度が増加しています。 前述のようなハイパースケーラーやその他の企業は、この増大する懸念を最初に特定し、それについて報告しています。しかし、それは決して無視できるような一度限りの不可解な謎ではありません。業界は遅かれ早かれそのニーズに対応する必要があるでしょう。今日のデータセンター・ネットワークが、非常に高価な冗長性のアーキテクチャに基づいて構築されているのも不思議ではありません。
さらに悪いことに、問題はすぐに出現するとは限りません。場合によっては、十分にテストされた小規模なソフトウェア パッチが展開された時に、完璧に動作していたデータ センターが突然誤動作を開始することだってあるのです。また、順調に稼働しているデータセンターでも、最初はごくまれにランダムなエラーが発生し始め、時間の経過とともに発生頻度が高くなる場合もあります。
現実の問題
いくつかの例を見てみましょう：
2019年10月のElectronic Design Process Symposiumでは、別のグーグルのチーム[4]が、時間の経過とともにチップの不具合を引き起こすさまざまなエラーメカニズムについて報告しました。発表者は7つの「主な信頼性劣化メカニズム」を挙げました： NBTI、PBTI、RTN、HCI、TDDB、EM、SERです。 詳細には言及しませんが、このうちNBTI、PBTI、HCI、TDDBの4つはすべてトラップされた電荷が原因であり、チップの電源が入っている時間が長いほど増加します。
RTN（ランダム・テレグラフ・ノイズ）は、どのような電子システムにおいても避けられないもので、純粋に「ランダム」なものです。RTNを避けることは不可能であり、チップの設計段階で、RTNがプロセッサを混乱させる可能性を低減するための対策を講じる必要があります。EM（エレクトロマイグレーション）は、時間とともに金属配線の抵抗を増加させるもので、チップの金属配線の高電流密度によって引き起こされます。チップのプロセスが微細化するにつれて、電流密度は増加し、問題を悪化させています。チップメーカーはこの問題に対処するため、10年以上前にアルミニウムから銅に移行しましたが、再び問題が発生したため、他の材料に移行する可能性があるという話も出ています。最後に、ソフトエラー率（SER）は放射線によって引き起こされるもので、地上波システムでも問題になりつつあります。
ハイパースケーラーだけでなくチップメーカーも、これらすべてのメカニズムに細心の注意を払っています。これは、データセンターがこれらの統計的逸脱によって機能不全に陥る可能性があるためです。 Facebook は、SDC の問題はデバイスのエラー、初期の故障、時間の経過による劣化、寿命末期の摩耗によって引き起こされる可能性があると説明しました。Googleは、「障害のあるコアは通常、断続的に繰り返し故障し、時間の経過とともに悪化することが多い」と述べています。
こうしたハイパースケーラーは、システムがこれらのエラーを認識して報告できるようにしたいと考えています。 予測できればさらに良いですし、 適切なモニタリング技術があれば、これは十分に達成できると思います。
継続的なモニタリング
このようなモニタリングを行うにはどうしたらいいのか?
これまで企業は、Facebook や Google によってもたらされた SDC および CEE の障害を検出できませんでした。 しかし現在では、システムのセンサーとして機能する非常に洗練された SoC を作成できるようになりました。 製造ロット間の変動から、材料の劣化、経年劣化、ソフトウェアの影響、アプリケーションのストレス、潜在的な製造欠陥、環境への影響に至るまで、あらゆるものを内部でモニタリングできます。
現在、この種のソリューションは proteanTecs を通じて入手できます。 ProteanTecs 予測分析エンジンである Proteus™ は、ML 駆動のオンチップ テレメトリを通じて長期にわたって詳細なデータを収集し、リスクの高い問題を特定し、学習に基づいてプロアクティブに追跡します。このプラットフォームでは、チップ テレメトリ データ、履歴データ、予測モデリング、機械学習アルゴリズムを活用することで、メーカーやブランド所有者が体系的な問題を特定し、迅速な根本原因分析で措置を講じることができ、システムの寿命を延ばし、感染の流行を防ぐことができます。継続的なモニタリングを通じて、既存のハードウェアに対するソフトウェアのアップグレードを検証し、信頼性の高いパフォーマンスを確保することもできます。
SDC と CEE は、チップ内およびチップが組み込まれているシステム内の他のパラメータと関連付けることができるため、プロセッサの動作を予測したり、フィールド エラーが発生する前にフラグを立てたりすることができます。これによって、プロセッサの導入ははじめてだというチップ開発者から、何年もプロセッサを使用しているシステム管理者まで、システムが現在どのように動作し、将来どのように動作する可能性があるかを理解することができます。
Proteus はデータセンター管理システムと統合し、学習した意思決定に繋がる情報に基づいて自動化されたアクションの展開を提供します。
モニタリング
さらに、類似のデバイスを監視することで、問題点の調査のための正確なデバイスごとの分析が可能になります。欠陥のあるCPUを検出し、潜在的にそのようなエラーを起こしやすい、同じ特性を共有する他のCPUと相関させることで、障害を防ぐことができます。
性能モニタリング、劣化モニタリング、根本原因分析のためのターゲットアプリケーションにより、予知保全はサプライチェーンへのフィードバックメカニズムで可能になります。設計、製造プロセス、テストプログラム、および現場での健全性追跡は、ハイパー・パーソナライゼーション化され、予測可能になります。
“Silent Data Corruptions at Scale”; Harish Dattatraya Dixit Et. Al., Facebook, arxiv.org/abs/2102.11245, Feb. 2021
“Cores that Don’t Count”; Peter H. Hochschild Et. Al., Google Research, Jun. 2021
“Improving Cloud Scale Hardware Fault Diagnostics”, Neeraj Ladkani, Rama Bhimanadhuni, Microsoft, Mar. 2020 OCP Virtual Summit
“Circuit Reliability Mitigation Techniques & EDA Requirements”, Georgios Konstadinidis, Google, EDPS 2019