views4GCPのストレージサービスについてまとめてみた。アクセンチュアにて5年間システム開発を経験。CP300のアジア初取得者。Google基盤上でのシステム開発の普及を目標として日々活動中。TweetShareHatena注意この記事は2018年7月24日に更新されたもので、内容が古い可能性がありますのでご注意ください。皆さん、GCE使ってますか?今更IaaSはもう使ってねーよと言う方にも関係あります、コンテナのベースも所詮はIaaSです。IaaSレイヤでメンテナンスが発生する場合はその上のコンテナは死んじゃいます。そのIaaSレイヤを無停止でメンテナンスさせるというパブリックIaaSではGoogleしか実現していないと言われるライブマイグレーションについて、実際本当に停止しないのか?というところを検証してみた結果、驚きの結果が出ましたので是非ご覧ください。1.ライブマイグレーションとは無停止で物理ホストを移動してしまう技術ライブマイグレーションはGCEの基本機能として実装され、このためだけにGCEのG.A.が半年遅れたと言う伝説の機能です。具体的には、物理サーバ上の仮想マシンの状態を別の物理マシンに事前にコピー・同期を取り続け、ディスクの状態もメモリの状態も完全に一致したあとブラックアウト期間(全停止)を少しだけ設けてTCP/IPレベルでの宛先を旧物理マシンから新物理マシンに切り替えることで、外から見ると全くわからない間に仮想マシンが物理マシン間で移動してしまう、という技術です。詳しい内容などは以下の記事を参考ください。https://qiita.com/kazunori279/items/41520689337a644a87b4実は、これまではライブマイグレーションはGoogleの社内でだけ行うことが出来る操作でして、特段理由無く検証やテストを実施することが困難でしたが、今年に入ってgcloudコマンド等から操作して発生させることが出来るようになりました。言うことで上記記事でも0.5秒しか停止がないと言う記載がありましたが、本当なのか?という疑問が湧き上がりますよね?ですので、実際に起こして検証してみました。2.ライブマイグレーションでの停止時間は最大でも200ms程度さて、実際どう検証したのかというと。同一のゾーン内のサーバからライブマイグレーションを起こす仮想マシンに対してpingを大量に打って、遅延がどの程度増えるのか、で検証・確認してみました。ちなみにライブマイグレーションを起こす仮想マシン内からいくらログを取ろうがライブマイグレーションを起こした形跡を検知することは不可能でした。(何か手段が思いつく方は是非教えてください!)実行環境はシンプルですが以下のような形です。単純に同一ゾーン内で2台のマシンを立てて、ping打ちながらライブマイグレーションを実行する、ということですね。asia-northeast1-b結果は以下の通り。ライブマイグレーションはコマンドの後、メモリやディスクの状態を同期する必要があるので、即座にブラックアウトタイムが訪れる訳ではありませんので、そのタイミングを調べるのは少し面倒です。ライブマイグレーションが起こっているであろうタイミングでpingの遅延が明らかに遅くなる(2ms以上)タイミングを確認し、その影響を確認してみました。通常0.1ms以下くらいで戻ってくるpingが10msを超える程遅れるタイミングの前後のログを抜粋しますと以下です。ライブマイグレーションが起こっているであろう箇所を赤字にしてあります。念のため3回程計測してみました。ms約20msの期間に渡って最大70msの遅延。ms約60msの期間に渡って最大131msの遅延。ms約80msの期間に渡って最大145msの遅延ということで、パケットロスどころか、100ms以下の期間で最大でも200ms程度の遅延にしかならなそう、ということがわかりました。ライブマイグレーション、やばいですね。これじゃあ監視でも検知出来ない訳ですよ。ちなみに、今回は簡易な構成のサーバを使ったためOS上ではライブマイグレーションが起こっているであろう事象を検知出来ませんでしたが、恐らく負荷を大量にかけた状態であれば何かメモリの同期等でオーバヘッドが出るものと思いますが、なかなか明確にはわからないでしょう。今回はブラックアウト期間の検証でしたので、あまり構成(HDDの容量やメモリサイズ)には影響を受けないであろうということで簡易な構成にて検証しております。GCEはこのように非常に可用性の高い運用が可能な高度なテクノロジーで構成されてます。GCEのみならずGCP全般についてクラウドエースでは豊富な技術者によるサポートで快適なGCP生活のお手伝いをしておりますので、是非ご相談ください。