「同期処理」と「非同期処理」

HaaS APIのシステムでは、処理は大きく二つに分けられる。「同期処理」と「非同期処理」である。同期処理は、サービス層で扱う論理的データを扱う処理であり、サービス層ですべて完結する。論理データはサービス層のDBへと登録されているものであり、DBトランザクションで処理できる。
しかしながら非同期処理は、サービス層だけでは処理できない。非同期処理には、VM起動やファイルの初期化など、物理デバイスに紐づく処理を行わなければならない。

非同期処理を行う場合には、サービス層で受けたリクエストをまとめあげ、サービス層からファシリティ層へとリクエストを送付する。その後、ファシリティ層でリクエストを処理し、論理データから物理データの変換を行った後、各種コントローラへとファシリティ層からリクエストを投げることになる。

リクエストを受け取った物理デバイスに紐づくコントローラは各機器を制御し、結果をファシリティ層へと投げ返す。必要なレスポンスをすべて受け取ったらファシリティ層は、サービス層へとコールバック通知という形で、非同期処理の終了を通知する。この一連の流れで非同期処理が完了することになる。一例として非同期処理の具体例をあげてみる

サービス層のRequest Brokerがリクエストを受け取る
Service Logic Managerがリクエストから必要な情報を処理しまとめあげ、ファシリティ層へとリクエストを投げる
Facility Logic Managerがサービス層からのリクエストを受け、論理データから物理データ変換を行い、物理データを用いてMaster Controllerへと指示を出す
Master Controllerは複数存在する物理機器に紐づくコントローラへと指示を投げる
VMコントローラ、Networkコントローラ、Storageコントローラは、Master Controllerから投げられた指示を並列に処理し結果をMaster Controllerへと返す
Master Controllerはすべてのコントローラの状況を確認し、問題が無ければサービス層へとコールバックを返す
コールバックを受けたService Logic Managerは、非同期処理の完了を記録する

書きだすと単純に見えるが、複数リクエスト処理時や、内部でのキューの制御、各機器の例外処理など、おおよそ想像もつかない制御をおのおのの層で実現しているシステムである。

図2：同期処理と非同期処理（クリックで拡大）

運用を始めてからの気が付いたこと、問題点、課題

当たり前であるが、一度サービスインしてしまったシステムのメンテナンスはやはり大変である。サービス層は外部からXML-RPCのリクエストを受ける部分なので、メンテナンスと言えども、停止させるわけにはいかない場合が多い。

そこで開発時から、最新のコード適用を行う時にLVS（Linux Virtual Server）を用いて切り倒しを行いながらリリースする仕組みを整えた。現状も計画メンテナンスや突然の改修でもサービス停止無しに作業を行っている。

また、自分たちで作り上げたシステムではあるが、機材にはベンダーの機器を利用しているので、ベンダーのファームウエアのバグなどに悩まされることが多い。十分検証して導入したにも関わらず、時限式バグの様なものはどうしても回避できないのが現状である。システムはすべて二重化しておりアップデートも切り倒しながら行えるが、突発的なバグの対処はベンダーの回答待ちということが多く、ことメンテナンスに関しては気をやきもきさせることが少なくない。

今後の予定

IIJ GIOはまだスタートを切ってから日が経っていない。同様にGIO HaaS システムも日が浅く、運用ノウハウはこれから蓄積していくフェーズにある。 GIO HaaSをどれだけ安定したシステムにできるかという部分が当面のわれわれの課題になっていく。

また、新しい技術がどんどん出現しており、どれだけ有益にそれらの技術を取り込めるかということがこれからのHaaS提供者としての命題になると思われる。

GIO HaaSのAPIシステムとして内部の解説がメインになった。しかしAPIと言うからには、受け口を柔軟に拡張することが望ましいのは目に見えている。現状対応プロトコルとしてIIJ社内で一番利用されているということでXML-RPCだけに対応したが、世の流れ的にSOAP, RESTなどを視野にいれたシステムへと改良していく予定である。