GMOインターネットのネットワークエンジニア中里氏に聞いた、OpenStack採用の裏話

OpenStackベースの「Z.com Cloud」はわずか4カ月でできた？

OpenStackの理想と現実、パブリッククラウドで使うために日々格闘

　さて、そもそもGMOインターネットが、パブリッククラウドサービスの基盤としてOpenStackを積極的に採用してきたのには、いくつかの理由がある。

　ひとつは低コストであることだ。海外勢、国内勢が入り乱れての激しい競争が続くIaaS市場で勝ち残るためには、できるだけコスト効率の良いサービスを提供しなければならない。そのために、同社はベンダー製のOpenStackディストリビューションではなく、オープンソース版（コミュニティ版）のOpenStackを採用している。

　「最初にOpenStackの採用を決めたメンバーに聞くと、やはり『安いクラウドサービスを出せる』という期待が大きかったようです。クラウドプラットフォームを構築するためのコンピュート／ストレージ／ネットワークのコンポーネントがすでに揃っており、あらためて自社開発することもなく、無償で使えますから」

　また、さまざまなコンポーネントを操作するための各種APIも提供されており、それを操作するツール群がコミュニティで開発、公開されていることも、サービス開発を効率良く、迅速に進めるに当たっては有利な点だった。

　もっとも、クラウドサービス開発部に異動した中里氏が実際にOpenStackに触れてみると、理想と現実とは大きく違った。現実のOpenStackは「改良を加えてクラウドサービスを作るベースとなる玄人向けの荒削りなキット」（中里氏）であり、理解するには時間のかかる複雑なシステムだった。加えて、特にパブリッククラウドの基盤として活用するためには、いくつもの障壁があったという。

中里氏は経験を基に考察したOpenStack導入のノウハウをまとめ、講演資料として公開している（リンクは本文末）

　「そもそもOpenStackは、企業の社内プライベートクラウド環境を想定して開発されています。当社のように多数の顧客向けパブリッククラウドサービスで採用する場合には、そのままでは使えない部分がありました」

　たとえば、OpenStackでは多くの機能がAPI経由で操作できる。プライベートクラウドならば問題ないが、パブリッククラウドでAPIをそのままユーザーに公開してしまうと、どんな操作でもできてしまい危険である。そこで、ユーザー向けのAPIに独自のロジックを追加して、機能制限を加えた。

　スケーラビリティの面でも課題があった。管理者が使い方を指示できるプライベートクラウドとは違い、数万ものユーザーが同時に、まったく異なる使い方をするのがパブリッククラウドだ。そのため、ユーザー規模が拡大しても、障害やセキュリティホールが発生しないよう配慮する必要があったという。

　また、ソフトウェアコードにもバグや変更が多かった。そのため、開発チームでコードを修正し、サービスのリリース前には繰り返し動作チェックを行った。同社には、サービス開発を手がけたメンバーが最後まで面倒を見るべしというルールがあり、開発者やエンジニアたちは、コード修正や動作チェックにかなりの労力を割いたという。

　「OpenStackの採用で大変なのは、人的リソースをかなり割かなければならないこと。CAPEX（導入コスト）は抑えられますが、OPEX（運用コスト）を非常に食います」

パブリッククラウドサービスとして提供するため、GMOではネットワーク関連の機能にかなり手を入れたという（中里氏の講演資料より）

　結局、ConoHaのリニューアル作業にはおよそ1年がかかった。そこでは多くの苦労があったものの、反面で、クラウドサービスの開発に初めて携わることになった中里氏にとってはいい刺激にもなったようだ。

　「ネットワークだけでなく、サーバーインフラ、OS、OpenStackと、異なるレイヤーのスペシャリストたちが集結した開発チーム内で、お互いの持つ情報、専門知識を共有することの大切さも実感しました」