メモリエラーは最も厄介なハード障害、Googleが対抗策を展開へ：2021年第4四半期に提供開始

クラウドを利用している場合であっても、メモリエラーから逃れることは難しい。自社の仮想マシンとは無関係な領域で発生したメモリエラーの巻き添えを食らってしまい、仮想マシンの再起動が必要な場合もある。Googleはこのような問題を解決する対抗策を2021年第4四半期から、Google CloudのIaaS「Google Compute Engine」で展開する。

[＠IT]

　Googleは2021年9月4日（米国時間）、メモリエラーが「Google Cloud」の顧客とそのクラウドワークロードに与える影響を最小限に抑えるために開発した「Memory Poisoning Recovery」（MPR：メモリポイズニングからの回復）機能について公式ブログで解説した。特に「SAP HANA」をクラウドで運用している企業にとって、これは重要なイノベーションだとしている。

　Googleは2021年第4四半期から、Google CloudのIaaS「Google Compute Engine」について、メモリ最適化マシンファミリーの第2世代インスタンスで、MPR機能を利用できるようにする計画だ。

実は頻発しているメモリエラー

　Googleは、「（サーバの）メモリエラーは最も一般的なタイプのハードウェア障害であり、本番ワークロードとシステムの信頼性への影響という点で、最も厄介な障害の一つだ」と述べ、メモリエラーについて、次のように説明している。

　メモリエラーは頻発しており、優先順位の高い課題だ。Googleが2009年に発表したメモリの信頼性に関する同社初の大規模調査の結果によると、同社の本番システムに組み込まれたDIMMモジュールの年間エラー率は平均8％以上だった。

　DDR RAMは世代を追うごとに、より小型のパッケージで大容量を搭載しているため、メモリハードウェアの信頼性は当時より下がっていると考えるのが無難だ。

メモリエラーの影響は大きい

　モダンCPUはエラー訂正メモリ機能を備えており、単純なメモリエラーなどをECC（エラー訂正コード）で訂正できる。ただしそれでも訂正不能なメモリエラーが発生する場合がある。

　ホストシステムで動作するソフトウェア（ハイパーバイザー、仮想マシン、OS、データベース、アプリケーションなど）の大半は、訂正不能なメモリエラーに遭遇すると、直ちにクラッシュしてしまう。

　クラウド環境では、クラッシュしたアプリケーションは回復するものの、そのプロセスで数分間のダウンタイムが発生する。データが多ければ、回復プロセスにかかる時間もそれだけ長くなる。

　例えば、ビジネスクリティカルなSAPアプリケーションとインメモリのSAP HANAデータベースをGoogle Cloudで大規模に運用している企業は、ダウンタイムが長時間に及び、多額の売上高を失う恐れがある。Googleによればこのような企業の場合、ダウンタイム中に1分当たり1万ドル以上のコストがかかるという。

　多くのSAP HANAデータベースはTB（テラバイト）級のメモリにロードされており、クラッシュ後に全てを再起動して正常に戻すには1時間以上かかることもある。SAP HANAの場合、最大10分のダウンタイムで高速に復旧するためには、常にプロビジョニングされた冗長レプリカが必要となる。つまりコストが倍増するということだ。

仮想マシンが「隣人の巻き添え」でクラッシュ

　クラウドでは、1台の物理ホストはマルチテナント環境であり、数十台の仮想マシン（VM）が動作している可能性がある。これらのVMは数十の顧客が所有している場合がある。

　メモリエラーは不良セクションを実際に使用するVMだけでなく、システム上で動作する全てのVMをクラッシュさせる。これは、ホストシステム上のメモリエラーに対するVMの一般的な反応だ。

　こうした「隣人の巻き添え」となるVMは、物理サーバのメモリエラーでダウンするVMの90％以上を占める。

メモリエラーの影響を最小化する「Memory Poisoning Recovery」

　Google Cloudはこれまでも、顧客が計画外のダウンタイムを最小化するのに役立つ「ライブマイグレーション」のようなユニークなツールを提供してきた。

　Googleはこれらのツールと、IntelのCPUや特定のアプリケーション（特に、SAP HANA）に組み込まれたエラー処理機能を利用する最近の技術を統合することで、メモリエラーに関連するダウンタイムや中断を大幅に低減するMPRを開発した。MPRを利用すれば、顧客は多くの場合、問題が発生したことにすら気が付かないとしている。

　MPRには、Google Cloudの既存機能と新機能、サードパーティーからCPUレベル（Intel）とアプリケーションレベル（SAP HANA）で提供される機能が組み合わされている。MPRは、次の2つのメインプロセスに分解される。

・メモリエラーを隔離する

ステップ1　Googleはメモリエラーに対するVM技術の堅牢（けんろう）性を強化した。システムで発生したメモリエラーのシグナルを捉えて分析し、訂正不能なエラーが発生したDIMM上の領域に「poisoned」（汚染）というフラグを立てる。

ステップ2　「poisoned」領域と、この領域が影響を与えるVMを追跡するプロセスを起動する。この領域がデータの整合性に影響しないようにするためだ。

・メモリエラーから回復する

ステップ3　VMのゲストOSとメモリエラー処理に対応したアプリケーションへ、エラーが記録されたことを通知する。これによってアプリケーションは、関連するメモリエラー処理を実行できる。

ステップ4　Google Cloudのライブマイグレーションと連携し、エラーの影響を受けるホストからゲストOSを移行し始める。これにより、顧客は健全なホストでVMを運用でき、訂正不能なメモリエラーがさらに発生する可能性が減り、ダウンタイムを回避できる。

メモリエラーが起きた場合に何が起こるか　従来の流れ（上）：メモリエラーが起きてVMがクラッシュする、MPRを利用した場合（下）4段階をへてメモリエラーから回復できる（出典：Google）

MPRにはどの程度の効果があるのか

　Googleはメモリエラーのシナリオとの関連でGoogle Cloudの顧客を3つのグループに分類し、各グループについて、MPRを利用する場合としない場合に分けた。その上でメモリエラーの結果、何が起こるのか、どのような影響を受けるかを、次のように対比して示した。

顧客グループ1
　メモリエラーを起こしたVMとアプリケーションを使用しており、VMはメモリエラーの影響を直接受ける。メモリエラー処理に対応したSAP HANAをVMで運用しており、「高速再起動」機能を有効にしている。

	何が起こるか	影響
MPRを利用	Google CloudのMPRがHANAにシグナルを送信する。制御されたシグナルが送信され、高速再起動機能がHANAの高速な再起動を開始し、影響を受けるメモリ領域を置き換える	直接的なダウンタイムコストはほとんど発生しない。多くの顧客は問題に気付かない
MPRを利用しない	HANAはメモリエラー処理をサポートするシグナルを受信しない。メモリエラーがホストのクラッシュを引き起こし、完全な再起動／リロードが強制される	HANAの再起動時に多大なダウンタイムコストと大規模な中断が発生する可能性がある

顧客グループ2
　メモリエラーを起こしたVMとアプリケーションを使用しており、VMはメモリエラーの影響を直接受ける。メモリエラー処理に対応していないアプリケーションをVMで運用している。

	何が起こるか	影響
MPRを利用	メモリエラーでゲストOSとアプリケーションがクラッシュする	計画外ダウンタイムが発生する。ユーザーの介入が必要になる可能性がある
MPRを利用しない	メモリエラーがホストをクラッシュさせ、VMを再起動する	計画外ダウンタイムが発生する。ユーザーの介入が必要になる可能性がある

顧客グループ3
　VMはメモリエラーの影響を直接受けない。任意のアプリケーションをVMで運用している。従来であれば、「隣人の巻き添え」となっていた顧客グループに相当する。

	何が起こるか	影響
MPRを利用	Google Cloudのライブマイグレーションが、メモリエラー処理をサポートするシグナルを認識し、全ての顧客のVMを新しいホストシステムに直ちに移行する	ダウンタイムは発生しない。ユーザーの介入は不要。ユーザーはホストシステムの問題に気付かないだろう
MPRを利用しない	メモリエラーがホストをクラッシュさせ、ホストシステム上の全てのVMがクラッシュし、再起動する	計画外ダウンタイムが発生する。ユーザーの介入が必要になる可能性がある