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

GIO HaaS APIについて

GIO HaaSシステムでは、システムをコントロールするためのAPIが用意されている。3層でいう所のサービス層がクライアントからのAPI受け口になる。 APIリクエストを処理するために、サービス層には、Request Broker Daemonが動作している。このDaemonをHaas Request Brokerと呼ぶ。

APIのリクエストで使用されるプロトコルはXML-RPCである。XML-RPCを採用した理由は、IIJ社内で一番利用されているプロトコルであったためである。 APIは大きくいくつかの項目に分類される。VM管理、ネットワーク管理、ストレージ管理、初期化、VMイメージ管理、その他となる。

おのおのの分類のなかに細かいAPIが定義されることになる。例としていくつかを以下にあげる。

VM管理

VM情報を管理する。またイメージのインストールや電源管理なども含む。

• getVmInfo（VM情報取得）
• powerOnVm（VMパワーオン）
• powerOffVm（VMパワーオフ）
• restoreImage（イメージのインストール）
  ....

ネットワーク管理

ネットワーク情報を管理する。VMへのネットワークの付けこみ、IPアドレスの確保などを行う。

• getNetworkList（ネットワーク情報取得）
• allocateNetowrk（ネットワークリソース確保）
• allocateIpAddress（IPアドレス確保）
• attachNetwork（VMへネットワークの取りつけ）
  ....

ストレージ管理

ストレージ情報の管理を行う。拡張ディスクの管理や付けこみなどを行う。

• getVolumeList（ストレージ情報取得）
• allocateVolume（ストレージリソース確保）
• deallocateVolume（ストレージリソース解放）
• attachVolume（VMへストレージの取りつけ）
  ....

初期化

OS設定ファイルを扱う。現時点ではCentOSに特化した仕様になっている。

• setIpAddress（IPアドレス設定）
• setNetwork（ネットワーク設定）
• setPassword（パスワード設定）
• setSshKey（ssh keyの設定）
  ....

VMイメージ管理

インストールイメージ情報の管理を行う。

• getImageList（VMイメージの取得）
• getImageInfo（VMイメージ情報の取得）
  ....

その他

付加情報の管理を行う。コメント管理やリクエスト情報などを扱う。

• getRequestInfo（APIリクエスト情報の取得）
• setResourceComment（リソースへのコメント追加）
  ....

現在39個のAPIで、リソースの管理やVMの制御を行える状態になっており、VMの大量生成、同時起動などがAPI経由で簡単に行える仕組みになっている。 実際にIIJ社内から、サービスに提供されるシステムから利用されたり、コマンドラインベースのツールが作成されたりして、APIの利用が行われている。 APIの種類はさらに増加する予定であり、現在も機能追加は続いている。

GIO HaaS APIの設計思想

GIO HaaS APIシステムを実装する時に内部で議論があがったこととして、3層アーキテクチャが果たして有益かどうかという部分があった。 階層分けの利点としては、各層ごとに独立に開発が進められるということがある。HaaS APIの仕様は、HaaS側で一方的に決めたものではなく、 利用者(IaaS)側とも協議しながら決めていったものであり、サービス層のAPI仕様を決めている間に、物理デバイス制御に近い、 ファシリティ層とコントローラ層が明示的に分離した並行開発が可能になった。各層での通信プロトコル仕様を固め、最後に結合するというアプローチが実際に取られた。

欠点としては結合試験時の影響や、層をまたぐことによる処理レスポンスの低下、複雑性の増大などがあげられた。 欠点を理解した上で3層構造にて突き進んだ理由は、開発の人的リソースや開発期間の関係もあったが、コントロール層やファシリティ層の増減に対応した、 複数のデータセンター分散へのチャレンジを視野にいれた設計をしたかったというモチベーションも大きくあった。

API自体の設計思想としては、「プリミティブな機能を実現する」という部分が大きく仕様に反映されている。 APIの要求を聞き始めると、すべてがAPI経由でできる魔法のシステムの様な夢が膨らむ傾向にあった。 実際にいくつかのプリミティブなAPIを組み合わせればできるような要求も出てくる感じであったので、要求を細かく細分化した上で、 APIの仕様を作り上げることに大きく時間がかかった。その結果仕様として採用されたのが、39個の基本的なAPIになっている。