Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

デプロイ自動化をマルチクラウドで! CDツール「Spinnaker」をAWS上で検証してみた【デブサミ2018】

【15-B-L】Spinnakerで実現するデプロイの自動化

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/03/06 14:00

 頻繁に行われるアプリケーションのデプロイ作業。その負荷を軽減するとともに、継続的デリバリ(CD)を実現するうえでも重要となるのがデプロイ自動化だ。しかし昨今では、デプロイ先がクラウド環境であることに加え、利用するクラウドプロバイダが案件によって異なるケースも珍しくない。そのため、クラウド環境ごとにデプロイ自動化の手法やプログラムを設計し直さなければならないこともある。本セッションでは、そのような悩みを解消するマルチクラウド対応のCDツールとしてエーピーコミュニケーションズが顧客企業への導入を検討している「Spinnaker」について紹介。日本ではまだ事例もほとんど公開されていない、AWS上での稼働検証を交え、Spinnakerがサポートするデプロイ方式やパイプラインの機能を活用した自動化の流れを説明した。

目次
株式会社エーピーコミュニケーションズ ITソリューション事業本部 IaC技術推進部長 飯島英和氏
株式会社エーピーコミュニケーションズ ITソリューション事業本部 IaC技術推進部長 飯島英和氏
株式会社エーピーコミュニケーションズ ITソリューション事業本部 プロフェッショナル職エンジニア mzu1h氏
株式会社エーピーコミュニケーションズ ITソリューション事業本部 プロフェッショナル職エンジニア 溝内 崇(mzu1h)氏

ユーザーが抱えるデプロイの悩みを解決すべくツールを模索

 インフラの設計構築や運用に豊富な実績を持つエーピーコミュニケーションズ。アプリケーション開発チームを置くようになった現在も、社員の約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など、幅広いクラウドプラットフォームに対応できる。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2018】セッションレポート

もっと読む

All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5