Google、訂正不可能なメモリエラーによるクラッシュを回避する「Memory Poisoning Recovery」をGoogle Cloudで提供へ

ずっと安定して稼働していたシステムが、ある日突然エラーでクラッシュ。調べても原因が分からないので、「何らかのノイズや放射線などの影響でメモリエラーが起きたのでは？」という推測を顧客に報告した、なんて経験を持つベテランのITエンジニアは少なくないのではないでしょうか。

実際のところ、2009年のGoogleの調査では同社の本番システムにおいて、1年間で8％以上のDIMMモジュールにメモリエラーが発生していたと報告されています。想像以上にメモリエラーというのは起きているのですね。

ただし、現代のメモリとCPUなどではエラー訂正機能を備えているため、多くのメモリエラーは訂正され、システムの動作に影響を与えないようになっています。

しかし訂正しきれない規模のメモリエラーもまれに発生します。多くの場合、それはシステムに致命的な影響を与えます。

メモリエラーで巻き添えになる「犠牲者の隣人」

例えば、訂正できないメモリエラーが発生した物理マシン上で仮想マシンが複数稼働していた場合、メモリエラーが発生した箇所を踏んだ仮想マシンだけでなく、それ以外の仮想マシンもクラッシュするとGoogleは説明しています。

これは仮想マシンのアーキテクチャが何であれ発生するとのことで、Googleはこれを「Victim Neighbor」（犠牲者の隣人）と呼んでいます。

この現象は、1つの物理ホストに複数の顧客のインスタンスが稼働する可能性のあるクラウドでは深刻な問題です。

また、メモリ上に大規模にデータベースを展開するインメモリデータベースのようなミッションクリティカルなアプリケーションでも大きな問題といえるでしょう。

たとえデータを失わなかったとしても、クラッシュしてから再起動するまでのあいだ業務が停止し、大きな損害が発生しかねないためです。

「Memory Poisoning Recovery」でクラッシュを回避

そこで、メモリシステムが訂正不可能なメモリエラーが発生してたとしても、仮想マシンやアプリケーションのクラッシュを回避する仕組みをGoogleが発表しました。

それが「Memory Poisoning Recovery」（MPR）と呼ばれる仕組みです。

これにより、Google Cloud上の仮想マシンや、ミッションクリティカルなインメモリデータベースであるSAP HANAを、メモリエラーを原因とするクラッシュから保護できるようになります。

この仕組みは、インテルのCPUによるメモリエラーのハンドリング機能、強化された仮想化技術、メモリエラー対応を組み込んだアプリケーション、そしてGoogle Cloudのライブマイグレーション機能などで構成されています。

Googleの説明によると、MPRの実行は次の4段階に分けられます。

第一段階
メモリエラー対応に強化された仮想化技術により、仮想化レイヤでCPUからのメモリエラーのシグナルをキャッチ。メモリエラーが発生したメモリモジュールの領域に対して「Poisoned」（毒された）フラグを立てる。

第二段階
データの整合性を保つため、この毒された領域が影響している仮想マシンを追跡。

第三段階
毒された領域に関連した仮想マシン内のゲストOSとメモリエラー対応アプリケーションに対して、メモリエラーが記録されたことを通知。アプリケーションがメモリエラーに対処開始。

第四段階
と同時に、Google Cloudのライブマイグレーション機能により、メモリエラーを起こした物理ホストから別の正常なホストへ仮想マシンの移動を開始。これによりさらなる訂正不可能なエラーが発生することを回避。

こうしたMPRの対応により、 メモリエラーで巻き添えになる「犠牲者の隣人」としての仮想マシンの発生を回避し、またメモリエラーが発生した領域のOSやアプリケーションも迅速なリスタートを開始するなど、障害を最小限の影響にとどめることができるとのこと。

下記はGoogleの説明図を引用しています（一部のみ切り取って横幅に合わせて加工しました）。

Googleは、SAPと協力してインメモリデータベースであるSAP HANAにメモリエラー対応機能を組み込み、MPRの仕組みで上記のような動作を可能にしていると説明しています。

こうした仕組みが実現されることで、クラウドはオンプレミスよりも高い信頼性を提供できるようになるわけです。

MPRはGoogle Cloudのメモリ最適化コンピュートエンジンの第二世代インスタンスで、今年の第四四半期から提供開始予定とのこと。