「OpenStackを選んだ理由は？」「VM屋になるためにどういった経験が大切か？」　元Web系エンジニアのVM屋に聞くQ＆A

OpenStackはどれくらい改造しているのか？

司会者：佐野さんありがとうございます。ここからは私のほうでSlidoを投映して、和田さんにモデレーションをお願いしたいと思います。では和田さん、お願いします。

和田卓人氏（以下、和田）：今もガンガン（質問を）書き込んでもらってかまいませんし、「この質問いいね」と思ったら「いいね」ボタンをどんどん押してください。みなさんが聞きたいと思った質問を基本的には優先しながら、時々、恣意的にピックアップしながら質疑応答をやっていきます。

今、3票（「いいね」が入っている質問）が2つかな。最後にちょっと説明があったところに関わっているので、先にコントリビューションの話から質問しようと思います。

「OpenStackを内部で改造している部分が大きいのでしょうか？」。つまり、内部でいじってカスタマイズしている部分が大きいのか、それともアップストリームにコントリビューションしていく開発が多いのかとか。割合とかのあたりも含めて、最後に説明がありましたが、もう1度お願いしたいと思います。

佐野成氏（以下、佐野）：まず、どのぐらい改造しているかというと、ちょっと（説明が）難しいのですが、それほどアップストリームにコントリビューションはできていません。ただ、アップストリームのものをフォークして自分なりのパッチを書いたりで、手は加わっている感じですね。

その中でアップストリームにないから実装するものが当然あるわけですけが、それはビジネスロジックの実装であったり、アップストリームにコミットするほどのことじゃないものがけっこう多かったりもして。

ということで、「開発としては内部で改造している部分が大きいが、アップストリームをフォークしてやっているので、常に追従してはいます」という感じですかね。答えになっているかしら。

和田：ありがとうございます。ビジネスモデルに関わるところとか、ビジネスロジックに関わるところ、つまりOSSのアップストリームに反映しても仕方がないというか、反映するのがふさわしくないところに関しては内部でやっている。逆に、不具合修正とか、あるいは十分に抽象的なものとかは、アップストリームにフィードバックしているというところですかね。

佐野：そうですね。

和田：はい。ありがとうございます。

開発のパイプラインとCI/CDはどうなっている？

和田：みなさんどんどん質問を……。あっ、下に追加されているな。いいねもお願いします。もう1つ、いいねが3票入っているのがあって。「CI/CDはどうやって回していますか？」というところは、最後のほうにちょっとだけ説明があったと思うんですが。

（お話の）最後にあったのは、例えばArgo CDとかを入れてGitOpsとかをこれから回していきたいとか、いろいろあったと思います。As-Isのところとか、あるいはその難しさやCI/CDとまとめています。

CI/CD（について）だとほかの質問にもあったのですが、「どうやってテストしていますか？」「どのくらい自動化していますか？」とかも含めた開発のパイプラインについて、「VM屋さんの開発のパイプラインとCIとCDってどうなっているの？」ということはたぶんみんないろいろ聞きたいところだと思うので、そのあたりを聞きたいと思います。

佐野：ありがとうございます。まずCloud Operator Days Tokyo 2022でまさにそのあたりについて話しているので、それを見るというのは1つあります。

それはそれとして、先ほどArgo CDの話が出ましたが、Argo CDって、私の知っている範囲だとKubernetesありきのものですよね、きっと。

和田：うんうん。

佐野：そうですよね。しかもKubernetes自体が宣言的である、Reconcileという仕組みがあるということとうまくマッチしてていると思うんですが、我々はKubernetesではなくOpenStackとか、より抽象化されていない部分で勝負をしていて。

そのためになにが必要かというと、Argo CDに代わるものを自前である程度書かなきゃいけなくて。どういうことかというと、宣言的であるために、コンテナとかホストとかの情報をある程度バージョン管理ができるようにしないといけない。そのためにはas Codeも進めないといけないという部分ですかね。

Argo CDに代わるような、宣言的な記述をすると現場が変わるというような仕組みを今まさに作っていますが、これも「KubernetesとかならArgo CDを入れて終わりなんだからいいよな」と思いながらやっていますね。

和田：仕組みとしてなので、宣言的な管理とReconcileのReconciliation Loopを回せばいろいろはかどるベストプラクティスだとはわかっている。

けれど、自分たちが扱っているところはそれよりレイヤーが低いので、宣言的な定義のところやReconcileするところなどの足回り系を自分たちでがんばることで、世の中のCI/CDのベストプラクティスみたいなものを自分たちのレイヤーでも回せるように、今、まさにがんばっているというところが伝わるといいなという感じですね。

佐野：そうです。

和田：これ、ほかの質問とも実は絡んでいたので、たぶん2つ（の質問に）同時に答えた感じになります。

OpenStackではなにかしらのReconciliation Loopが回っているのか？

和田：状態管理の難しさ（の質問）は0票でしたが、「シビアに状態を管理する必要があり、状態の不整合など起きないのでしょうか？　OpenStackではなにかしらのReconciliation Loopが回っているのでしょうか？」というところだったんですけれども。

佐野：回っています。ただ正確にいうと、periodic taskというものがあって、それがじっと監視をしてくれるわけです。「うむ、君は稼働中だな」「うむ、君は起動中だな」と監視しています。それによって状態が期待した状態じゃなくなることはもちろんありますが、直してくれるところまでしっかりはやってくれないんですね。

つまり、OpenStackにReconcileに相当する仕組みがあるのかというと、たぶんない。部分的にあるかもしれないが、たぶんないですね。

和田：検出はできるけど、適当な状態に収束するための仕組みはないという感じですかね？

佐野：そうです。この質問された方に誤解なく伝わっているかちょっと自信がないですが、その認識で合っていると思います。

和田：ありがとうございます。という感じでどんどん質疑応答を回していきます。

プライベートクラウドかパブリッククラウドかの選定観点は？

和田：（画面を見て）あと5票（「いいね」が）入っていて。これは僕に対する質問なのかな。「和田さんに質問です。自社でOpenStackのようにプライベートクラウドを抱えるorパブリッククラウドを使うという方針相談を受けた時に、どのあたりの要素が技術選定観点になるのでしょうか？」。

難しいんですが、与件とコストだと思います。与件というのは、例えば金融系のシステムを新規事業で立ち上げたい時は、金融系のシステムを作る以上、法の観点が必要です。要するに、日本で金融系のシステムを作る際は、ネットワークはこうしなきゃいけない、例えば高度に分離されてなければならないとか、その事業に参入するためのそもそもアーキテクチャ的な観点みたいなのがあったりするんですね。

となると、「これはなパブリッククラウドではできないな」「やりにくいな」とか、ゲームに入っていくためにそもそもプライベートクラウドとかのほうが有利、あるいは事実上ほぼそれしか選択肢がないような戦いのフィールドがある時は、必然的に「パブリッククラウドを使いたいけど使えない」みたいな感じになっていきます。これが条件その1です。

インフラの推奨としては、私個人としては基本的にパブリッククラウドを使うこと推奨していて。それは、新規事業とかを立ち上げる時の初期コストや見積もりのコストなども含めて、見えないところで小さく実験することがやりやすいからなんですけど。

逆に事業がどんどんどんどん伸びてユーザーの動向が読めるようになってくると、パブリッククラウドのほうがコストが高くなってくることはあります。そうすると、パブリッククラウドを離れて自社で運用するほうがコストとして低く抑えられることができて、かつ予測可能になる領域がまたやってくるというような感じです。

例えばDropboxがパブリッククラウドをやめたのは、そういうコストと予測可能性が関わっていると思います。大きく育っていった結果、コスト構造としてパブリッククラウドを卒業するようなところがあるので、そのあたりは違います。

なので、新規事業をいろいろやる場合はパブリッククラウド、あるいは自社でPaaSみたいなのを作って新規事業とかを立ち上げやすくしている場合は、基本はそれがいい感じになりますね。ざっくりとした返答ですが、こんな感じです。

若手の育成はどのように行っているか？

和田：では次の質問にいきます。僕がしゃべっている間にババッと5票（「いいね」が）入ったものがあって。「若手はどのようなかたちで育成していますか？　資格以外で」と。「以外で」という言葉がついていましたね（笑）。ということで（回答を）お願いします。

佐野：まず、うちのチームでは資格とかは特に……。もしかしたら英語は求めるケースもあるかもしれませんが（必要な資格は）なくて。私も何の資格も（持ってい）ないんですね。

実際の教育はどうやっているかというと、そもそもOpenStackはすごくニッチで、「OpenStackの人材を採ろう」といっても採れないから、コンピューターサイエンスとかをやってそうな人を連れてきて。（OpenStackをつかった開発の）歴史は6年とか7年とか、もっとあるかな。歴史が長いので、チーム内のドキュメンテーションもけっこうそろっているんですよね。なので、それを3ヶ月ぐらいかけて消化していくかたちになります。

もちろん最初はメンターがついて、徐々にトラブルシュートに入ってもらうとか、指示を受けながら……。基本的にリモートワーク下ではモブプロでみなさん仕事をするので、モブプロで仕事をして、プルリクを作って、徐々に独り立ちして。「1年目が終わる頃には1つか2つエピックを自分で持ってもらえるといいな」ぐらいのことをしていますかね。なので、育成は手取り足取りというと一番わかりやすいかな。

和田：ありがとうございます。そういう意味だと、リモートになってもモブ（プロ）で、けっこう分厚めに同期的に時間を取って育てていく感じですよね。

佐野：そうですね。

和田：ありがとうございます。かつ、けっこう成熟してきて、ドキュメントもそろっているという話ですね。

VM屋になるためにどういった経験が大切か？

和田：まだ時間がある。5票入りました。「この職に携わるにあたって、どういった経験が大切ですか？　個人でできることから、職場での経験まで教えてもらえると助かります」という質問です。

佐野：すごく難しい問いだと思います。あくまで「私が思うのは」という話ですが、不確実性に対してどう向き合ってきたかが大事な経験だと思います。

和田：不確実性。

佐野：みなさん、カーネルとかっていじったことあります？　カーネルをいじるとその上のソフトウェアにどういう影響を与えるかって想像つきますかね？　（想像）できる人はそんないないと思うんですけれど。

そういったことをしないといけない、だけどある程度計画も立てたいという時に、不確実性とどう戦っていくかがチームワークの中ですごく大事で。

チームプレイだとなお良いですが、個人の中で不確実性に対してどう向き合ってきたか。あるいは「こういう問題が出た時に君ならどう対処するか」を自分で考えられる人がいるとすごく良いなと思います。答えになったかな。なっていたらいいんだけれど。

プログラミングは多少書ければたぶん十分で、より重要なのは、コンピューターサイエンスの知識を持って不確実性にどう取り組むかという話かと思います。

和田：ありがとうございます。

OpenStackを選んだ理由は？

和田：時間的にはあと1問ぐらいですね。2つまとめて（回答）になるかな。4票が2つ。「なぜOpenStackを選んだのか、選んで良かったこと」「OpenStackを導入する、しないの損益分岐点みたいな。どういうきっかけで選んで、どういう良いことがあったか」とか、その判断あたり。OpenStackに関することを最後に2問まとめて答えていただいて終わりにしたいと思います。

佐野：まず、私が入った時にはもうOpenStackだったので、ちょっとその時の空気感はわかりません。Cephとか使っている方もそうかもしれませんけど、一番はたぶん自分でコントロールできるということが非常に大きいと思います。

中にはベンダーを叩いてもなしのつぶてみたいな話とか、ロックインが酷くて金ばっかりつり上がるみたいな話とかもある中で、エンジニアの技量があれば自分でハンドルできるのはやはり良かったことです。

それはコストの話にもなりますが、なぜOpenStackにしたかというと、漏れ聞くに、もともとのクラウドサービスのベンダーの請求が、法外な値段だったらしいんですよ。「これじゃまったくスケールせん」ということで、OpenStackを採用しています。

前の課長の話ですが「我々は自前でOpenStackをやっているからものすごい金額が浮いているぜ」みたいなことは聞くことはあるので、どのタイミングで損益分岐（をしたのか）は、パッとは言えませんが。ただやはりインフラなので解消にどうしても時間はかかりますが、プラットフォーマーをやるなら、自分で1つやるのもありなんじゃないかなと。

私は末端の人間なので、経営判断に及ぶようなことはまったく言えないんです。ごめんなさい（笑）。

和田：いや、実感のある言葉ですばらしいと思います。

佐野：ありがとうございます。

和田：ありがとうございます。ということで時間になりましたので、何問かまだもらっていて残念ですが、質疑応答自体はこれでいったん区切りにしたいと思います。