技術ネタ。仮想化技術は便利だが、思わぬ落とし穴があることを実感したことについて書いてみます。
コンピュータにおける仮想化
今回のネタは最近開発しているシステムで発生した問題です。
近年はコンピュータシステムを仮想化基盤上に実装することも増えています。
仮想化技術自体は、それなりに歴史を積んできていて、いわゆる枯れてきた技術ですが、それでも思わぬ落とし穴に遭遇することを身をもって体験しました。
もともとの仮想化技術は、コンピュータリソースが潤沢になってきたことに伴いそれらをうまい具合に分割して、一つのコンピュータ上に独立した複数のシステムを持たせることによりリソースの有効活用を意図しています。
実際多くのコンピュータシステムで仮想化技術が用いられて、現在は運用されています。
有名どころでいえば商用のレンタルサーバなどがそれにあたります。
こういった具合で一定の成功を収めているわけですが、やはりホストの上にゲストが存在するということでどこかしら完全に独立にできない部分は出るようです。
ホストとゲストの時刻同期
今回直面した問題は、ホストとゲストの時刻同期です。
結論から言うとCPUのクロックをホストとゲストで同期しているため、ホスト/ゲストの時刻修正が反対側に波及することが発生しました。
この問題自体は、限られた条件でしか発生しないと考えています。
時刻同期の方式
時刻同期の方式自体は大きく分けて、一括同期させる微修正を積み重ねて同期させるかの方法に分かれます。
一括同期というのは、文字通り配信サーバの時刻に自システムの時刻を一括で合わせる方法です。
主に時刻ずれが大きい場合に実行されます。
一方、微修正を積み重ねて同期させる方法は、自システムの時刻を徐々に早めるor遅くすることで徐々に正規の時刻に合わせこみます。
こちらは時刻の飛びがなく、ログなどの面で有効です。
通常はシステムが時刻同期を常に行っているため大きな時刻ずれは発生しないことから、実行される方法は微修正の積み重ねとなります。
クロックの共有による時刻同期の問題
問題が発生したのは、微修正の積み重ね方式を大きく時刻がずれているにも関わらず実行した時です。
仮想化時に、ホストorゲストのどちらかが時刻が正確であり、もう片方がある程度ずれている場合に、上記の方法で時刻同期を実行するとどうなるか。
時刻同期が実行されるため、徐々に時刻は修正されます。
しかしながらホストとゲストはCPUのクロックを共有しているため、一方の修正は時刻が正常なもう片方へ影響を及ぼします。
この修正は時刻のずれが大きいほど、積み上げが多くなるため元々正常であった側へ与える影響が大きくなります。
そのため、正常であった方の時刻が今度は逆にずらされるという問題が発生します。
これが今回は発生した問題の経緯です。
一括同期を使うほうを推奨すべき？
今回の問題は、一応ある程度の時刻ずれが発生していた場合、必ず一括同期を実行させるという方式を組み込むことで回避できました。
この方法が最善かどうかは議論が必要ですが、今のところ際立った問題は発生していません。
あとがき
今回は仮想化技術という、ある程度成熟している技術において発生した問題について記載しました。
ホストとゲストのリソースは独立していると思い込んでいましたが、ホストの上にゲストが立っているという前提は厳然としてあります。
開発上は何らかの影響をお互いに受けるというは、あらためて認識しながら作りこみを行わないと思わぬバグを発生させる、ということを感じました。
