TechReport

技術者情報

ソリューション

2019年11月20日(水)公開

第230回

速いことは良いことです [新]デスクトップクラウド 開発よもやま話

生まれ変わった「お名前.com デスクトップクラウド」~開発振り返り編~

「お名前.com デスクトップクラウド」は、新しい開発コンセプトで、様々なチャレンジ要素を取り入れて作り上げました。

開発にまつわるよもやま話をご紹介してみたいと思います。

記事INDEX

越えなければいけない壁

GMOインターネットでは様々なホスティングサービスが開発・運用されています。メインのプラットフォームは大半がKVM + OpenStackというOSS主体で作られています。当然、新しいサービスを作るときにはOpenStackベースのシステム開発が当たり前の文化で、「大規模システム」の考え方でうまくサービス提供ができています。

その中で「お名前.com デスクトップクラウド」というサービスは、MicrosoftのWidows Server + Hyper-Vがプラットフォームとなっていて、ホスティング業界では稀なサービスとなっていました。旧デスクトップクラウドは、2010年からサービスが開始され、延べ14万台の仮想マシンをホストしてきたという実績があるサービスでした。開始当初はそれなりのスペック、パフォーマンスを実装していたものの、10年も経つとテクノロジーやサーバーのスペックも格段にアップしており、さすがに見劣りするサービスになってしまい、旧デスクトップクラウドを刷新して、よりユーザーの方々に喜んでもらえるサービスとして生まれ変わることが必要となりました。

新たにデスクトップクラウドを開発するとなった場合、社内のエンジニアの比率では大多数がOSS系なので、当然OpenStackベースでの開発と考えられていました。ですが、これまでのデスクトップクラウドの開発ノウハウが全く利用できないこと、新しいデスクトップクラウドでは差別化のためにVM内のカスタマイズが必須であること、そのためにはHyper-Vが必須であり、OpenStackとHyper-Vの組み合わせにいくつか問題があることが分かり、OpenStackは使わずにゼロベースからWindows ServerのAPIとPowerShellで作る方向で進めることになりました。

さて、ここからがいろいろ問題が出てくるところです。

OSS系のエンジニアにいきなり「Windows Serverでサービスを作れ」と言ってもできません。Windows Serverでサービス開発をしたことのある人員が圧倒的に少ないのです。サービスリリース後を考えると、分からないことづくしで運用にも不安があります。そんな状態でそもそもサービスを作ってよいのか? 問題点を上げればキリがないほどの意見が飛び交いました。

確かに、OpenStackベースのように、ある程度の初期投資をしてシステムを作り上げてサービスを始める場合は、投資が無駄にならないよう万全の体制で開発に取り組み、リスクをできるだけ少なくしてプロジェクトをやり遂げる必要があります。そこで今回の試みとして、大規模でモノリシックなシステムではなく、初期投資は最小限(例えばサーバー1台から)で、いわゆるStackというものを必要としないマイクロサービス化したサービス基盤にすることにし、限られたエンジニアリソースを有効に使うために人の手をできるだけ煩わせないよう全てをコードで実現する「as code」の考え方などを取り入れて、ハードウェアの部分と仮想化+ソフトウェアの部分を分離して開発を開始しました。ダメだったら傷が浅いうちにいつでもやり直しができる、という気持ちでのチャレンジ開発です。

社内で採用されていたのは、「いつまでに」「どのチームが」「何を作る」といった、いわゆるウォーターフォール型のサービス開発手法です。この手法ですと、スモールスタートという開発コンセプトにはマッチしないので、会社全体でコンセンサスを取って始めるというよりは、プロダクトファースト、少人数で小さく作って実際に動くものを見せて納得させるというゲリラ的手法でのチャレンジとなりました。


新サービス開発 越えなければいけない壁
● 新しいもの、チャレンジに対して否定的
● これまで作り上げてきたものへの自信とこだわり
● 大企業ほど新製品が生まれない
● サービスは重厚なシステムで武装して大勢で作って運用するもの
● 致命的な問題が起きた場合誰がどう責任を取るのか

新しい試み Stackを使わないサービス基盤

Stackを使わないシステム構成はどうなっているのかといえば、Stack一点集中のシステムではなく、サーバー1台1台、全てが等しくStackと同等の機能を実装しているという考え方です。OpenStackで見てみると、IaaSのプロビジョニングだけではなく、ストレージの管理、マスターイメージの管理、仮想ネットワークの管理と、様々な機能が1つにまとめて盛り込まれています。各機能が密接して関連付けられていて、それゆえに必要とされるスペック、構成などが大がかりになりがちと判断しました。

Stackのように様々な機能があらかじめ用意されているのではなく、必要な機能はその都度作成して、「仮想マシンを作る」「ユーザーを作成する」など、関数のレベルまで細分化して、それぞれ独立して機能を提供できるようにします。できるだけ機能を限定してコンパクトにし、必要機能だけ実装して、足りなければその都度追加できるシステム構成にするということです。これらを実現させるためには、「全てのサービス、機能、設定をコード(プログラム)で実現する」という考え方が必須となります。「Infrastructure as code」「Configuration as code」の考え方です。

Windows Serverで「as code」を実現するには、PowerShellのモジュールで全ての機能を実装して提供することが一番簡単な方法です。最大の利点は、複雑なシステムをインストールする必要がなく、テキストベースの小さなファイルを各サーバーにコピーするだけで、等しく同じことができるようになります。各機能は一つひとつの関数として提供されているので、修正もテキストファイルを直すだけ、再コンパイルも必要ありません。サーバー1台から始められるので、初期投資もほとんど必要ありません。これらの考え方の元となっているのは、マイクロサービス、ブロックチェーン、コンテナサービス、アジャイル、DevOpsなどです。これらトレンドの手法をそのまま取り入れているわけではありませんが、基本的な意図としては、「小さく」「簡単に」「スピーディーに」コードで実現するといったものになります。

ブロックチェーン 全てのサーバーが平等の機能を持つ
マイクロサービス Stackに依存しないモジュールベースの機能提供
サービスは小さな関数の組み合わせで提供
アジャイル マイクロサービス化された機能ごとの小規模開発を繰り返す
コンテナ サーバー1台あたりの収容率を上げるための工夫
運用管理効率の向上
DevOps as codeで開発者が仮想化されたインフラ構築、オペレーションまで担当
インフラとサービスの分離


壁を越える
● ユーザーは安くて使いやすく、パフォーマンスが良いものを待ち望んでいる
● ユーザーが喜んで儲かるなら、ルールはそれに合わせて変えるべき
● インターネットの世界で5年前の正義は必ずしも通用しない
● サイクルの速いサービス提供が当たり前、乗り遅れは致命的
● サービス運用も攻める
● as Codeで目指すのは究極の運用No Ops!
● サービス開発者にも、マネジメントとは別の適切な権限とリソースを与えられる仕組みが必要
● 責任を取ることは謝ることではなく技術力でなんとかすること

サーバーそれぞれが独立した機能を持つ構成
サーバーそれぞれが独立した機能を持つ構成
コンテナ技術の応用でイメージ管理
コンテナ技術の応用でイメージ管理
サービス開発で考えるべきこと

ゲリラ的な開発でもなんとか周囲のコンセンサスをとることができると、担当各部署に仕事が割り当てられてプロジェクトが回りだします。毎週の定例ミーティング、コミュニケーショーンツールでは分単位で様々な意見が飛び交います。

今回新しいサービスを作るにあたって、技術以外でも色々と考えさせられることがありました。サービスコンセプト、作り方、チーム、社内ルール、利益とコスト、事業部門とシステム部門、大きな組織の中でサービスを作ること、などなど。事業部門からすれば、コスト最小、利益最大が必須要件です。システム部門からすれば、新しい技術手法、新しいサーバー、万全なシステム構成などどうしても技術先行になりがちです。会社全体でみれば、ユーザーに喜んでもらえて、たくさん使ってもらえるサービスが絶対条件です。これらの考え方がすべてマッチして1つになるということはおよそありえません。どこか妥協があり、これだけは譲れないという部分もあり、それらのせめぎ合いです。

やはり、企業が提供する「サービス」であるがゆえ、「最優先に考えるべきはユーザー」というのは間違いありません。ユーザーが満足する価格、スペック、使いやすさです。次に、利益とコスト。技術者からすると残念ですが、最後に技術とシステムという優先順位となります。事業部門とシステム部門の目指す方向はユーザーのためという点で合致しているのですが、それぞれ言語というか、考えに至るプロセス、会話のプロトコルが完全に異なることを改めて実感した次第です。

それぞれ異なる優先順位をどうまとめるか。これはもう人の力、コミュニケーションでの解決しかありません。各部門の主義主張を御用聞きのごとくあちらこちら飛び回って話を聞き、それぞれの落としどころを探っていくしかありません。いずれAIが最適解を探してくれるようになる時代が来るかもしれませんが、今はやはり「人」が重要な要素になります。アジャイル、スクラムなどトレンドの理想的な開発手法でもなく、プロジェクトリーダーがリーダーシップを発揮してグイグイ引っ張って行くというような恰好の良いものでもありません。各部門から嫌がられ憎まれもしますし、派手さも無くいたって地味な仕事ですが、この役割が無いとサービス開発が進まないのです。


サービス開発で考えるべきこと
● サービスは誰のもの?
● 事業部門にも技術の仕組み、理解は絶対必要
● 何ができて、何ができないのかを全員が理解すべき
● 思い付きでコロコロ変わる要件・仕様はマイクロサービスレベルで対応して影響とストレスを最小限に
● サービスはエンジニアが技術を試す自己満足のための場所ではない
● すべてはユーザーのため、儲けるため
● エンジニアのミスリードがサービスのボトルネックとなる
● 古い技術だろうと考え方だろうと、新しすぎて実績が無かろうと、分からないことだらけであろうとも、ユーザーに喜んでもらえて儲かるなら選択するべき
● エンジニアはもっと自分のサービスに愛着を
● ユーザーアンケートは開発者こそ読むべき

ユーザー側から見てみれば

いろいろと試行錯誤して作り上げたサービスですが、ユーザー側からすると画面の中で見える部分でしか評価しようがありません。価格、スペック、使いやすさ、これに限ります。


ユーザーの立場から
● 安心して使うことができて、
● パフォーマンスが良くて、
● 安いものであれば、
● どんなシステムで、
● どれだけコストがかかっていようが、
●  誰が、
    どう作ろうが、
        どうでもいい。


結論として、色々なサービス、開発のプロジェクトの進め方、考え方があり、型どおりには進みません。何度やっても難しいものです。会社、部門、人、それぞれ立場が違えば、考え方、主義主張が違って当たり前。人が手で作り上げるものであるからこそ、変化に富んだ柔軟なサービスを作ることができ、たくさんの問題も出てくるということです。その労を惜しんだら良いサービスは作れません。行きつくところはユーザーファースト「ユーザーに喜んでもらえる」ということに尽きるのです。

[新]デスクトップクラウド開発は、こんなことを改めて考えさせられる良い機会となりました。

樋口 勝一

GMOインターネット株式会社

1999年6月GMOインターネットに入社。Windowsを用いたホスティング事業の立ち上げの際、サービス開発からその後の保守・運用まで1人で担当。2010年には「お名前.comWindowsデスクトップ」をリリースし、マイクロソフト社と強い信頼関係を構築。2007年から連続で「マイクロソフトMVPアワード」を受賞し、Windowsのスペシャリストとして活躍。

執筆者一覧

Hyper-Vで本格的なサーバー仮想環境を構築。仮想環境を設定・操作できる!

できるPRO Windows Server 2016 Hyper-V
GMOインターネット株式会社 樋口 勝一 著

◇Hyper-Vのさまざまな機能がわかる
◇インストールからの操作手順を解説
◇チェックポイントやレプリカも活用できる
Windows Server 2016 Hyper-Vは、仮想化ソフトウェア基盤を提供する機能であり、クラウドの実現に不可欠のものです。
本書では、仮想化の基礎知識から、Hyper-Vでの仮想マシンや仮想スイッチの設定・操作、プライベートクラウドの構築、Azureとの連携などを解説します。

詳細はこちら → Amazonインプレスブックス

初めてのWindows Azure Pack本が発売

Windows Azure Pack プライベートクラウド構築ガイド
GMOインターネット株式会社 樋口 勝一 著

本書は、Windows Azure PackとHyper-Vを利用し、企業内IaaS(仮想マシン提供サービス)を構成するための、IT管理者に向けた手引書です。試用したサーバーは、最小限度の物理サーバーと仮想マシンで構成しています。Windows Azure Packに必要なコンポーネントのダウンロード、実際にプライベートクラウド構築する過程を、手順を追って解説しています。これからプライベートクラウドの構築を検討するうえで、作業負担の軽減に役立つ一冊です。

詳細はこちら