部署内クラウドが使っている主要技術である、OpenStack as a Service、OpenStackのコンテナ化、構築試験自動化(CI/CD)、周辺ツール郡をご紹介します。

OpenStackの上にOpenStackの開発環境を用意した話

部署内クラウドを開発するにあたっては、OpenStackの開発や運用していく中で生じる課題を真っ先にクリアする必要がありました。

OpenStackを開発、運用する際の課題の一例 ・OpenStackの構築が難しい ・開発のために同一環境を複数人に提供したい ・1環境用意するのに何時間もかかる。 ・障害の再現環境を用意したい。 ・過去のバージョンで動作検証したい ・基盤は半年に1回アップデート対応する。 ・アップデート検証のためのサーバが用意できない。 ・...等

様々ありますが、これらの課題はすべてOpenStack as a serviceを目指すことで解決しました。

まず初めにややこしい階層解説です。

読んでいて今どこの話をしているのか分からなくなったらこちらを見てください

・1F ：物理層。物理サーバとOpenStackプロセスのあるレイヤ

・2F ：1FのOpenStackが提供する仮想資源のレイヤ。
仮想ネットワーク、仮想インスタンス等があるところです。
OpenStack as a Serviceは2F相当します。

・3F ：2FのOpenStackで作った仮想資源のレイヤ

OpenStack as a serviceができると何がいいの？

まず、部署内クラウドを開発する際に、2段階のリリース方式をとりました。

アルファ版とベータ版です。

アルファ版の時にはスピード重視でOpenStackを構築し、バグも残したままリリースしました。

なぜかというと、アルファ版の上の仮想環境、つまり2階部分で複数人が複数のOpenStack環境の開発や、CI/CDの仕組みで自動試験を行えるようにするためです。

OpenStackの上でOpenStackをサービスのように貸し出すことができる。これがOpenStack as a Serviceです。

簡単な絵でご説明すると、アルファ版OpenStackが払い出す仮想環境で、複数のベータ版OpenStackが動作するイメージです。

2F部分のOpenStackで試験を行い、バグを検出する。バグに対する修正パッチは1階部分に反映する。そのようなフローを実現するために、アルファ版の早期リリースが必要でした。

アルファ版は実験的なリリースのため品質が低くても、VMとネットワークさえ動作すれば問題のない最低限の品質で問題ないのです。

アルファ版があることで、後続ベータ版の開発スピードやバグ検出の頻度が格段に高まります。

OpenStack as a Serviceが実現できると、複数人が複数のOpenStack環境を操作できるので、開発中の競合が発生しないことや、CIが利用できることが最大の利点でした。

OpenStackをコンテナ化している話

また、基盤側のアップデートを容易にするための仕組みとして、OpenStackの各プロセスをDockerコンテナ上で動かしています。

開発するうえで真っ先に課題となったのが、「OpenStackのアップデート」です。

半年に１回のメジャーアップデートだけでなく、パッチ追加や設定値のパラメータ修正等日常的に更新が必要です。

そのため今回のバージョンアップを容易にするために部署内クラウドでは、「1Fにパッケージは入れない。必要なものはすべてDockerコンテナで実装する。」というポリシーを掲げました。

Dockerコンテナですべてを実装することで、バージョンアップはコンテナを差し替えるだけで済み、バージョンアップの難易度を下げるだけでなく、事前検証の容易化や対応時間の削減に繋がりました。

OpenStackプロセスのコンテナ化としてOpenStack Kollaがありますが、今回は自前でDockerfileを作成し、Ansibleで各ノードにDockerコンテナを配置するようにしています。

仕組みとしてはOpenStack Kollaと同じですが、Kollaはまだ検証中であったため今回は採用を見送りました。

検証結果によってはOpenStack Kollaに置き換わる可能性はあります。このポリシーであれば簡単に置き換えられるでしょう。

Blue/Green Deploymentを応用したバージョンアップ

OpenStackのプロセスがコンテナ化されているため、パッチ適用等の簡易バージョンアップも容易になりました。

最近ではHorizonにパッチを適用する必要が発生したため、部署内クラウドのCICD機能を利用したバージョンアップを行いましたので、そのときの方式を紹介します。

Blue/Greem Deploymentの考え方を応用し、1F:Blue面 2F:Green面としています。

ダウンタイムはHAProxyの切り替え10秒程度。MemcachedでBlue面,Green面のcacheを共有しているため、利用者への影響は限りなく0に抑えることが出来ました。

最後に

4月1日よりNTTソフトウェアはNTTテクノクロスに社名が変わりましたが、部署内クラウドを活用してよりよい製品開発に努めてまいります。

今回の記事に関してご質問のある方や、OpenStackの導入や運用にご興味のある方は、ぜひ弊社にお問い合わせください。

OpenStack®はOpenStack, LLCの登録商標又は商標です。