さくらのIaaS基盤を支えるしくみと課題

この記事は2025年7月5日(土)に行われたオープンソースカンファレンス 2025 Hokkaidoにおける発表をさくナレ編集部で記事化したものです。

はじめに
さくらのクラウドについて
さくらのIaaS基盤開発
IaaS基盤開発は今後何を目指すのか
VMが増えた時の課題
まとめ

はじめに

さくらインターネットの廣瀬です。

今日は「さくらのクラウドのIaaS基盤を支える仕組みとOSSへのつながり」というタイトルで発表します。3人で発表しますが、私からはさくらのIaaS基盤を支えるしくみと課題をお話しして、皆さんにIaaS基盤について知ってもらえればと思っています。

自己紹介

私は2024年12月にさくらインターネットに入社しました。今はクラウド事業本部クラウドサービス部バックエンドユニットのIaaS基盤開発チームというところで働いています。今はサブリーダーという役職で開発をしています。前職でもクラウドの開発をしていました。その時も基盤の開発をしていて、当時はOSSのOpenStackを使ってプライベートクラウドの開発をしていました。

今日のお話

私から話すこととしては、まずさくらのクラウドについて皆さんに知ってもらって、その後、さくらのIaaS基盤の開発としてどういったことをやっているのかというような流れで発表させていただきます。

さくらのクラウドについて

まずさくらのクラウドについてお話ししていきます。

これはホームページにも書いてありますが、さくらのクラウドは2011年にサービスを開始しています。特徴としては明確な料金体系であったり、国内のデータセンターにあったりといったところが挙げられます。明確な料金体系とはどういうことかと言うと、時間単位や日単位などの料金がリソース作成時に明示されます。月20日以上は定額です。データセンターは、札幌の北にある石狩と、それから東京の2リージョンがあります。複数リージョンを使って構築することでDR対策などを取ることができて、安心な環境が作ることができます。

そして、さくらのクラウドは先ほどIaaS型のクラウドと説明しましたが、最近はPaaSやSaaSレイヤーのアプリケーションをいろいろとリリースしています。SaaSレイヤーだと、APIゲートウェイ、EventBus、オブジェクトストレージなどですね。PaaSレイヤーでは、AppRun、高火力 DOK、MariaDBやPostgreSQLなどが使えるデータベースアプライアンスなどのサービスがあります。その下に私たちのチームが管理しているIaaSレイヤーがあり、ここではサーバやスイッチ、それから普通のストレージなどを提供しています。

それで、なぜこんなにいろいろなサービスを提供しているかというと、弊社は2023年11月にガバメントクラウドの仮認定を受けています。そして、2025年度末に305項目の技術要件を満たす必要があり、そのためにいろいろなサービスの開発や運用改善をしています。ガバメントクラウドがどういうものかは割と知られてないようだったので簡単に図を書きましたが、デジタル庁がAWSやGoogle、Microsoftなどと契約して、各行政機関や地方自治体がクラウドを利用するという形を取るものになります。さくらインターネットもその契約先のひとつになろうとしているところです。

さくらのIaaS基盤開発

ここからはさくらのIaaS基盤の開発について、いろいろと話をしていこうかと思います。

IaaS基盤開発って何してるの？

これはさくらのIaaS基盤というよりも一般的にIaaS基盤開発って何をしているのかという話になりますが、低レイヤーに近いものをAPIで動かせるようにしているというのがIaaS基盤の開発になります。

もう少し具体的に言うと、物理サーバからネットワークやストレージを切り出してVMに使ったりだとか、あとはVMを作る時にOSイメージが管理されているものがあるので、そこからOSのイメージを持ってきたりだとか、そのようにしてうまく組み合わせていい感じにVMを作れるようにするというのがIaaS基盤の仕事になります。そして、ここで「いい感じに」というのがポイントです。ただVMが作れればいいというだけでなく、いかにユーザーに対して快適なVMを届けるかというのを一番に考えて提供するようにしています。

IaaS基盤の仕組み

このIaaS基盤の仕組みを図を用いて説明します。

ユーザがさくらのクラウドのWeb UIからVMを作成したいとなったときに、その裏側では、コントローラーに対してリクエストが来て、それに対してOSのイメージを持ってきたり、ネットワークからIPアドレスを払い出したり、ストレージからそのVMが使うディスクを持ってきたり、DNSを登録したり、そういったことをした上で、たくさんあるホストの中から最適なホストを選定してVMを立ち上げる、というのが大まかなIaaSの仕組みになります。

そして、上図が弊社のIaaSを支える技術スタックです。これによると、ホストレイヤーではPerlとGoを使っていると書いてあります。さくらのクラウドは2011年から存在する歴史があるサービスで、もともとはPerlで書いていたのですが最近はGoに書き換えたりしています。VMを立ち上げたりする部分はKVMとかQemuといったものを使っています。それからIaaSのコントローラーにも歴史があって、もともとPHPやPerlを使っていたのですが、最近はPythonやGoで書き換えたりしています。あとはデータストアにMySQLを使ったりだとか、プロキシにApacheを使ったりだとか、ログの転送にkafkaを使ったりしています。

IaaS基盤開発は今後何を目指すのか

ここまででIaaS基盤の基本的な構成や技術スタックの説明はほぼ終わりですが、では今後は何を目指すのかという話をします。具体的な数字は書けませんが、VM数が現在の2倍に増えても安定したVMが届けられるようなIaaS基盤の開発というのを目指して、今のIaaS基盤開発チームは動いています。

というのも、今はガバメントクラウドの認定を受けたりだとか、その過程でクラウドネイティブに移行してマネージドサービスが増えるとなったときに、割とVM数が増えたりします。私が以前働いていた会社でも、マネージドサービスが増えたときに管理コストが増大して障害が発生した経験がありますが、そういった意味も含めて安定提供できるIaaS基盤を目指しています。

マネージドサービスが増えるとどういうことが起きるかと言うと、IaaS基盤上で新しいサービス、例えば最近では「高火力 VRT」という、GPUを使うVMを提供し始めましたが、その時にどこにどのように影響するのかというのがわかりづらくなっているというのがあります。そのためにサービスをリリースしたところで障害が発生するようなことが起きていますので、リリース前にしっかりわかるような体制を作らなければなりませんし、もちろん障害が発生したらすぐに切り戻しをしないといけないというのもあります。そして、逆にPaaSレイヤーで何か障害があった時、例えばDBで障害があった時に、IaaS基盤が関係ないということもないので、そういった時にIaaS側では何が起きていたのかをいち早く共有できるような仕組みも必要なのかなと考えています。

VMが増えた時の課題

その他にも開発していかなければならないところはいろいろありますが、現在の課題としては、VMを作るためのスケジューラとか、ストレージのスケジューラーとか、デプロイのスケールというものを考えて開発をしています。これらについて1つずつ見ていこうと思います。

スケジューラの課題

そもそもスケジューラとは何かという話になりますが、クラウドサービスは限られたホスト上にVMをたくさん設置しなければならないサービスです。その中で、物理サーバの上に乗るVM数を最適化するロジックを考えたりしています。例えばCPUやメモリをホスト上でどのぐらい使っているかとか、特定のホストをユーザーが専有するVMを提供する(専有ホストプラン)だとか、ユーザが利用するOSごとにホストを変えるようなこともしていたり、さらに最近ではGPUなどもあります。

そういった時に、VMを作っている方だとよく聞く言葉かもしれませんが、オーバーコミットというものがあります。これは実CPUに対してだいたい3倍ぐらいが基本という風によく言われているのですが、CPUは24時間365日ずっと同じ使用率ということはありません。ですので、使用率をモニタリングしつつ、実際にVMを作る時にどの程度使われてるかなども確認しながら作っていかなければならないという風になっています。

そして、コントローラーからVMを作るホストを選定し、選定された候補の中からVMを作るために状態を確認するという2つの動きが、VM作成におけるスケジューラの挙動になります。

VMを作成する際にはコントローラーの中で、状態を取得する候補となるホストを列挙するためのロジックを持っています。そして、それらの候補の中でユーザーにとって一番利用しやすいVMはどこだったら作れるのかを調べるために、候補となるホストの今の状態を取得し、VMを作成するホストを選定するということをしています。

それから、VMを作成する際には、障害に対する耐性も考慮する必要があります。例えばVMを1台作りたいというだけならどこでも上図のような形で作れますが、

では2台作りたいとなったときに、それが同じホスト上にあってはいけません(ホストに障害が発生すると2台とも停止するため)。

では同じラック内だったらいいのかとか、別のラックだったらいいのかとか、あるいは別のゾーンにした方がいいのかとか、さらには別のリージョンに立てた方がいいのかとか、さまざまな障害耐性があるので、こういったところもケアできるように今後開発していかないといけないのかなと考えています。また、先ほどお話しした専用ホストみたいなものもあるので、そういったものも含めて私たちはスケジューラに対するロジックを考えています。

なので、今後のスケジューラの目指す先としては、もちろん今も適切に一応スケジュールできるようにしていますが、より良いスケジューリングができるようなロジックを考えて、ユーザーがリソースを公平に使えるようにしていくことを検討しています。

ストレージの課題

次の課題はストレージです。ストレージはVMと違って、CPUのようなすごく動的に変わるものではないのですが、ストレージにも限界はあるので、容量が足りなくならないようにするスケジューリングは必要です。

例えばバックアップを取る時に過去のバックアップと同じホストに取ってしまうと、ホストに障害が発生したときにバックアップが2つとも使えなくなってしまうので、同一ホストに被らないようにするような配慮が必要です。また、例えばユーザーが2人同時にバックアップを取った時に同じストレージにバックアップを取ってしまい、そのためにストレージが足りなくなってしまったというようなことがないようにロジックを考えています。

デプロイの課題

最後の課題はデプロイです。さくらのクラウドでは1台のホストに対してVMが数千台あるので、そこに対してVMを立てるためにいるエージェントなどの更新をかけると、デプロイに半日ぐらいかかります。さらにそこで障害があると今度は切り戻さなければならず、そうなるともう1日が終わってしまいます。さすがにそれはつらすぎるのですが、長年そうやって運用し続けたデプロイの仕組みというのもあるので、今後はもっと早く快適にデプロイできる仕組み作りもやっていかなくてはいけないのかなと考えています。ここは今後の大きな課題となっているので、チームメンバーで考えているところです。

まとめ

この発表では、さくらのクラウドのIaaS基盤の仕組みや課題をお話ししました。IaaS基盤としては、VMスケジューラやストレージやデプロイの課題を考えながら今後もIaaS基盤の開発を続けていって、マネージドサービスの土台として使われるVMとか、ユーザがIaaSとしてそのままVMを使うこともありますが、そういったVMを快適に使ってもらえるような仕組みを考えつつ、運用や開発を行っていこうと考えています。発表は以上です。ありがとうございました。