IaaSのVM屋さんって、実際どんな開発をしているの？　「新規」と「保守」で見るそれぞれの作業例と問題点

IaaSのVM屋さんの保守開発

佐野成氏：ここまででインフラのIaaS、VM屋さんの話をしてきましたが、「実際開発ってなにしてんの？」という話をもう少し話そうと思います。

まず開発といった時に、「保守系統の開発」と「新規の機能開発」という分類をしてみようと思います。実際は別々のチームがやっているのではなく同じチームが対応していますが、そういう感じで話していこうと思います。

まず保守ということで、（それはつまり）今動いているものを維持する営みが必要です。さまざまな理由により保守開発がやはり必要です。主にはセキュリティの脅威や、ベンダーのサポートを受けるためにバージョンアップをしなければならないといった理由によるものです。

（スライドを示して）ここには、バージョンアップしか書いていませんが、ほかにもトラブルシュートや故障対応とかもありますよね。

それをやらないといけないのですが、こういったホストOSのバージョンアップや、ファームウェアのバージョンアップは、たいていの場合はホストをダウンさせないといけません。みなさんもラップトップをバージョンアップする時に、1回シャットダウンしますよね。

しかし、このゲストOSのVMの正体は、実際はただのホストOSの1プロセスに過ぎません。なので、「ホストOSの停止を伴うバージョンアップをするぞ」となると、当然ホストがダウンするので、VMももちろんダウンします。

仮想サーバーを売り物にしているわけなので、「なんかよくわからないけどVMが勝手に落ちたんだけど」という荒っぽいことは当然できません。

プロセス自体は無停止のまま、ホストOSに対してなんらかの変更を加えたい。ホストOSのバージョンアップのようなリブートを伴う変更を行いたい時にどうすればいいのかというと、Live Migrationという機能があります。

これがなにかというと、VMプロセスをほかのホストに移動するもので、仮想サーバー屋さん、VM屋さんを作る時に巨大なストレージを用意する話をしたと思いますが、この巨大なストレージを、たくさんのサーバーがマウントしています。

（スライドを示して）右下を見てみると、Storageの上にServer、Server、Serverと複数のサーバーがマウントしていることを伝えたかったのですが、こんなふうになっていて。Live Migrationという機能を使うことで、移行先のホストにメモリコピー、転送して、移行元から移行先へVMを引っ越しできます。

例えば、ホストにはゲストOSがいますが、このサーバーになにか致命的な問題が起きたとか、サーバーにリブートを伴う変更を加えたいという時に、Live Migrationでほかの空いているホストに引っ越しをさせます。

引っ越しをさせると、なにも載っていないホストが出来上がるので、安心してホストをダウンさせることができます。ただ、このLive Migratioは、まったくゲストに影響を与えないわけではなくて。これは本日話せるかどうかわからないのですが、万能ではありません。

ともかく、これによって保守上は空っぽのホストを作れるので、一応ローリングアップデートみたいなことができます。

ちなみに、こうした保守のための開発（についての発表）は過去何回か登壇していて、2021年にはLive Migrationを繰り返してホストOSをローリングアップデートしたという話をしてきました。ありがたいことにCODT（Cloud Operator Days Tokyo）という、これまたニッチな集まりがあるのですが、そこで大賞をいただきました。

ここで「ローリングアップデートとかLive Migrationとかマジつらすぎ。ホスト重すぎ。開発できねぇ」という話があって、この保守のコストが重すぎるので下げる営みをするための取り組みを話したのが、2022年（に開催された）Cloud Operator Days Tokyo 2022の登壇でした。

個人的にはこっちの（発表の）ほうが好きなんですけど、特になんの賞にも引っかかりませんでした。気になる方はこのあたり（の資料）を見て、「なんか大変そうだな」「楽しそうだな」と感じてもらえればと思います。

IaaSのVM屋さんの新規開発

今まで話したのはすでに登壇（で話）もした保守の話で、「じゃあ、新規開発とかってなにやってんの？」という話があります。

例えばWebアプリ、雑にTwitterを想像してみます。Twitterの新規開発となると、例えば検索機能の強化やユーザーに対するトレースのためのフラグをいっぱいつけるとか、タグをつけるとか。それによって収益を上げやすくするということがあると思います。

「インフラの場合って何？」というと、基本的には（スライドの）1番が一番大きいかなと思っています。つまり、ハードウェアの進化で生まれた新しい機能を仮想的にも提供できるようにするということです。

QEMUはエミュレーターでもあるので、ハードウェアとして持っていないものでも仮想的なハードウェア上でエミュレーションすることはできるのですが、基本的にはハードウェアのほうでその機能を持っていたほうが、なにかと効率がいいんですね。というわけで、新しいハードウェアを買って、その新しいハードウェアについている新機能を仮想的にも使えるようにするのが、1つ大きな取り組みとしてあります。

例えば、暗号化の機能を提供可能にしたい。新しいハードウェアの新しいストレージの暗号化機能を提供したいとか、新しいCPUを仮想的に提供したい。ほかにも、新しいゲストOSのWindowsやRed HatやUbuntu。新しいOSは当然新しいCPU、新しいハードウェアであることがある程度期待されて作成されているので、プラットフォーマーとしてそれに対応した仮想的なハードウェアを出さないといけないものもあります。

ほかにも、物理的なサーバーでは出来ない、仮想サーバーだからこそ実現可能な新しい機能もあって。これはお客さまに見えるかたちでなにかパッとは出ないですが、Live Migrationを楽にするための機能や、テレメトリのために便利な機能があります。そのためにも、ホストOSに対して新機能、仮想化のレイヤーの機能を使って利活用したいというのがあります。

そういったものが終わってインフラ側の準備が整ってから、ようやくインターフェイスとしてOpenStackを通じて機能を公開する流れになっています。（スライドを示して）2番と3番。ほかにもちょっとありますが、それはこの後に話します。

とにかく重要で重いのは、我々が提供したいものはハードウェアの仮想化であるがゆえに、最初にハードウェアが必要ということです。

ハードウェアの新機能を仮想的にも提供したい時になにが必要なのかというと、まず現物がないといけないので、その検証機を購入します。今は納期などもみなさん苦労されていると思いますが、大変です。

とにかく購入して、これを現在あるいは未来のホストOSと結合させて問題ないか。さらにその上で、ゲストOSとの結合は問題ないか、既存の機能との互換性はあるのかを検証し終わった後で、ようやくそのハードウェアの新機能が有効に使えるかの検証に入ります。

この検証が終わったら、OpenStackから新機能を使うための実装をしていくわけです。（スライドを示して）要するに、この下から上まで横断的な知見が必要で、かつ単純に工数が多いです。これによってインフラのデリバリーコストがすごく重くて、課題になっています。

『Clean Architecture』を読んだことがある方はもしかするとわかってくれるかもしれないのですが、ホストOSに手を加えるのが、すごく苦痛なんですよね。いわゆる安定度の高い具象コンポーネントがホストOSですが、サービス提供のためのすべてに密結合しているので、ここに手を加えるのは「マジつらいよな」というのがあります。

このハードウェアの新機能以外に、管理上、より利便性の高いインターフェイスをお客さまに提供したい。オブザーバビリティや仮想サーバーの多様な変数をより簡便に管理したいとか、あるいは収益効率の高い収容設計の見直しやスケジューリングを実装したいというものもあります。

この2番や3番は、先ほどのハードウェアの機能追加に比べると、かなり染み出す範囲が狭くて、というか、なんならほとんどOpenStackに閉じています。OpenStackは、あくまでVMをマネジメントするためのサービスなので、実際のハードウェアとはある程度独立して機能できるんですね。

ただ、OpenStackは仮想化の知識がそれほどなくても貢献できるんですが、チームメンバーが保守開発とハードウェアの機能開発で手一杯で、余力としてなかなか手が回らないのが現実です。

もし今見ている方の中で「これからインフラをやってみたい」とか、仮想化の知見を深めたいとWeb系のエンジニアの方がいたら、ぜひ転職先として弊社、幣チームを検討してもらえればと思います。

「インフラだからデリバリーに時間がかかるのはしょうがない」に立ち向かう

（スライドを示して）今後、この開発をどうしていきたいのかの話も少し話しておくと、インフラのデリバリーコストの最適化問題に取り組みたいです。「インフラだからデリバリーに時間がかかるのはしょうがないよね」という、このやるせなさに立ち向かいたいなと思っていて、大きくは2つのことに取り組む予定です。（というか）取り組んでいます。

サーバーの多様化や増加に対しても、スケーラブルなチーム開発体制の強化をするために、1つは物理的、しかも多種多様かつ台数の多いサーバー、ストレージというものをなるべく抽象的に扱えるようにしたいと思っています。

今後、総数や変数が増えて売上が増えていくことに反比例するように、保守運用上のコストを下げて利益を上げていきたいです。そのためには適切な抽象化が必要なので、それをやっていきたいです。そのために、より多くのものをIaC（Infrastructure as Code）で管理して、Argo CDのようなGitOpsを物理のホストやストレージにまで拡充したいなと思っています。

もう1つが、コストの支配項の1つであるLive Migrationの運用コストの低下で、ホストダウンを伴う変更作業、これは基本的にはLMが必須になりますが、そのコストが高いんですよね。

これをもう少し手懐けたい。Live Migrationはすごく便利ですが、理論的にはLive Migrationが完了しないような、メモリをいっぱいいじめているようなVMに対してデータを取得して、なんらかのワークアラウンドシステムを作るとか。

あるいは、そもそもVirtualizationレイヤーを専任とするスペシャリスト採用の強化や、Live Migrationの実験場の構築を今後やっていこうと思っています。これを見て、「ちょっと楽しそうだな」「興味があるな」という人は、ぜひ声をかけてもらえればと思います。

VM屋がしていることのまとめ

いろいろ話してきたのですが、まとめです。まずVM屋さんは、巨大な計算機のリソースのプールを切り売りしているということです。SDPFクラウドでは、そのためにOpenStackというOSSを使っています。あと言い忘れていたのですが、スポンサーをしていて、コミュニティのリポジトリにコミットもしています。

VM屋さんは、その機能の保守のためにハードウェアやホストOSのメンテをしていて、ネットワークとストレージを共有しているホスト間でなら、VMはLive Migrationでほかのホストに移れます。

新規機能の開発には下から上までの横断的な知見が必要ですが、下から上まで知らなくても一部を知っていればコントリビュートは可能なので、経験者採用の応募をお待ちしています。

というわけで発表は以上です。

（次回に続く）