ユーザーが抱えるデプロイの悩みを解決すべくツールを模索
インフラの設計構築や運用に豊富な実績を持つエーピーコミュニケーションズ。アプリケーション開発チームを置くようになった現在も、社員の約7割はインフラエンジニアだという。セッション冒頭では、同社ITソリューション事業本部 IaC技術推進部長の飯島英和氏が、ITインフラ業界に起きている変化について語った。
「オンプレミスから仮想化、クラウド、コンテナへと変革が進む中で、インフラエンジニアの仕事も大きく変化している。インフラもソフトウェアやデータと同じように扱い、ソースコードで管理する世界になってきた。そういった変化を受け、われわれもスピーディーなインフラを実現するために、ソフトウェアの開発技術や管理技術にも踏み込んで検証を進めている」
こうした背景から同社では継続的デリバリ（CD）を重視。その一環としてSpinnakerの構築・活用に取り組んでいる。
続いて、本セッションのメインテーマであるSpinnakerの紹介については、ITソリューション事業本部 プロフェッショナル職エンジニアの溝内崇（mzu1h）氏が担当。同氏がSpinnakerを扱うことになったのは、アプリケーション開発を行うあるユーザー企業からの要望がきっかけだったという。その要望とは、次のとおりだ。
- アプリケーションをデプロイするときは確実に実施したい。問題があったら即時に切り戻したい。
- アプリケーションのデプロイに手間をかけたくない。
- プロジェクトごとでクラウド環境が変わってくるが、デプロイ方法は同じにしたい。
特に上の2つは、多くのアプリケーション開発者に共通する要望といえる。溝内氏は、それぞれの解決策として「切り替わり時間の短縮化」と「自動化」が必要であり、CIツールのJenkinsで解決できると考えた。しかし、「複数の異なるクラウド環境へのデプロイ方法を統一したい」といった、このユーザー特有の3つ目の要望に応えるには、各クラウドのAPIに対応したデプロイのプログラムを作らなければならない。API自体が拡充される可能性もあり、メンテナンスのコストもかかってしまう。
そこで導き出した解決策が、ツールを活用した「APIの差分吸収」だ。これら3つの要素を網羅できるツールを模索してたどり着いたのが、CDツールのSpinnakerだったという。
Spinnakerの特徴として、まずBlue/Greenデプロイメント（Spinnakerでは「Red/Black Deploy」）を含めた複数のデプロイ方法をサポートしていることが挙げられる。Red/Black Deployでは、本番運用中のサーバと同じロードバランサ配下にある別のサーバにアプリケーションをデプロイしてロードバランサの向き先を変えることで、ほぼダウンタイムゼロで新しいアプリケーションに切り替えられる。問題が発生した場合も、ロードバランサの向き先を元に戻すだけで即時の切り戻しが可能だ。
ロードバランサの向き先を元のサーバに変更することで容易に切り戻しできる
また、アプリケーションをデプロイしたイメージの作成からインスタンス作成、ロードバランサ配下への配置まで、一連の動作をパイプラインで自動化することもできる。Spinnakerのパイプラインには各種ステージが提供されており、それらを連結して自動化のフローを構成する。溝内氏は、代表的なステージとして「Bake」と「Deploy」の2つを紹介した。
「Bakeはマシンイメージの作成、Deployにはインスタンス作成、サーバグループ作成、ロードバランサ配下への配置といった挙動が含まれる。AWS上でSpinnakerを動かす場合なら、BakeでAMIを作成、Deployではオートスケーリンググループを作って任意のインスタンスを起動し、それをELB（Elastic Load Balancing）配下にぶら下げることになる」
そして、Spinnakerの最大の特徴ともいえるのが、複数のクラウドのAPIをサポートしていることだ。AWSをはじめMicrosoft Azure、Google Compute Engine、OpenStack、Kubernetesなど、幅広いクラウドプラットフォームに対応できる。
