クラウドサービスにおける自動制御基盤(HaaS API)

2010年6月10日(木)
阿部 博(あべひろし)

クラウドコンピューティングが大流行するなか、APIを利用したクラウドシステムの制御がさまざまなところで利用され始めている。 株式会社インターネットイニシアティブ(以下、IIJ)ではクラウド基盤「IIJ GIO(以下、GIO)」をサービス提供しており、 GIOの内部でもAPIを利用したシステムの制御が行われている。今回は、世の中のメジャーなAPIの紹介と、GIOの内部APIについて解説していきたい。

世の中のAPI

クラウドプロダクトがあれば、ほぼ間違いなくそれらのシステムのAPIが公開されているのが現状である。 APIの標準化という話も進みつつあるようだが、現時点で固まった仕様が採用されたということはあまり聞かず、 各社おのおの独自実装のAPIを定義している。以下に、現時点でメジャーであるいくつかのAPI実装をあげる。

Amazon Web Service API
EC2(Elastic Compute Cloud)はAmazonの代表なクラウドサービスであるが、 制御はWebUIだけではなくAPIをラップしたコマンドラインでの操作が可能である。 (http://docs.amazonwebservices.com/AWSEC2/2009-11-30/APIReference/
代表的なものとして生成系(CreateXXX)、削除系(DeleteXXX)、参照系(DescribeXXX)、 VM操作系(Start/Stop/Reboot Instances)、Image管理系、etc...などがある。 公開されているインタフェースとして、Query APIとSOAP APIがあり、APIをたたくコマンドを自作することが可能である。
Eucalyptus
http://www.eucalyptus.com/
Amazon EC2のAPIと同等に操作できるOSS(Open Source Software)のクラウド基盤としてEucalyptusがある。 Amazon互換をうたっていることからわかるように、EC2, S3と互換を持ったプロダクトとしてじわじわと人気が出てきている。 APIがAmazonと互換ということで、管理ツールなどをEC2と統合して作成することが可能である。
libcloud
http://incubator.apache.org/libcloud/
Eucalyptusなどの様にAmazonに限定して、互換性を持たせるプロダクトもあるが、特定サービスに依存しない形で汎用的な操作を行いたいという場合がある。 クラウドサービスではVMに対する特定の操作を大まかに分類することができる。VMのlist一覧取得、VM作成、VM削除、VM起動、VM停止、イメージ操作、情報取得である。 これら汎用的な機能をライブラリ化したlibcloudというライブラリが、python実装で公開されている。対応するサービスとして、 AmazonEC2, Eucalyptusはもとより、flexiscale、GoGrid、Linode、OpenNebula、Rackspace、vCloud、etc...など、20近いサービスに対応している。 API公開とは違うアプローチになるが、汎用性を考えると有益である。

3層構造のGIO-HaaSシステム

図1:3層構造のGIO-HaaSシステム(クリックで拡大)

IIJ GIOについて

IIJ GIOは、HaaS/IaaS/PaaS/SaaSとすべてのサービスレイヤで利用可能な包括的なクラウドサービスとして作られた。 IaaS/PaaS/SaaSはすべてHaaSの基盤の上に成り立つことになる。HaaS(Hardware as a Service)と言うくらいで、 HaaS基盤はAPIにより制御可能である。具体的には、VMの作成、ネットワークの作成、OSのインストール、ファイルの初期化、 起動/停止などがすべてAPIで制御可能になっている。世の中のHaaS制御基盤の実装はあまり公開されているものではないが、 今回はGIO HaaSの内部について少し解説を行う。

GIO HaaS について

IIJ GIOのHaaSは顧客(IaaS事業者)に対し、VM,ストレージ、ネットワークなどのリソースを提供するHardware as a Serviceである。 GIO HaaSは一枚岩のシステムとして図示されるが、内部的には大きくサービス層、ファシリティ層、コントロール層の3つの層に分かれている。おのおのの層について解説を行う。

サービス層
APIの受け口となりクライアントから見た場合のサービス窓口になる。APIから渡されるデータを精査し、必要な処理を行う。 サービス層で扱うデータはすべて論理的なデータとなり、物理的なデータは隠ぺいされる。同期リクエストはすべてサービス層で処理される。
ファシリティ層
サービス層では論理的なデータを扱っていたが、ファシリティ層では論理データと物理データの変換を行いサービス層との通信を行う。 また、物理データを元にコントロール層へと処理の指示を投げる。主に非同期系リクエストを制御する。
コントロール層
Hypervisor、ストレージ、ネットワークなどの物理機器をコントロールする処理群。おのおのの機器に対応するコントロールDaemonが存在する。 指示はすべてファシリティ層から行われる。

これら3つの層が連携し合い、クライアントからのリクエストを処理することになる。

著者
阿部 博(あべひろし)
株式会社インターネットイニシアティブ

IIJ プラットフォームサービス部サーバプラットフォーム課に所属。IIJ GIO-HaaSシステムの開発や、分散処理システムの検証や構築など行っている。次世代の大規模システム管理手法を模索中。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています