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など、幅広いクラウドプラットフォームに対応できる。

AWS上で実際に試してみたSpinnakerの実力は?

 続いて溝内氏は、AWS上で実際に行った簡単な検証について、Spinnakerの画面の動きを見せながら説明した。

 検証内容は「GitHubにコードをアップロードするだけで、デプロイまで動くのか?」「それにどのくらいの時間がかかるのか?」「Red/Black Deployの実際の(切り替え・切り戻し)動作は?」の3点。手順としては、現アプリケーションで表示される「Hello World01」を「Hello World02」に変更した新アプリケーションをGitHubにアップロードし、正常に本番環境までデプロイできたら1つ前の状態に切り戻す、というものだ。

 まず、GitHubに新アプリケーションのプログラムをアップロードすると、Jenkinsが変更を検知してSpinnakerに通知する。通知を受けたSpinnakerは、ステージング環境でBake→Deployを実行。なお、ステージング環境へのデプロイはRed/Black Deployではなく、現アプリケーションのサーバグループへの上書きとなる。

 Spinnakerの画面では、タスクバーでこれらの進捗状況を確認可能だ。例えばBakeが完了し、Deployを実行中なら、前者は緑、後者は青で表示される。また、Bakeで実際に動いているのはイメージ生成ツールのPackerであり、そのログが出力されるので、それを見てBakeの詳細な実行状況を確認することもできる。

「Pipelines」の画面に表示されるタスクバーで進捗状況を確認できる(実行中は青、完了は緑)
「Pipelines」の画面に表示されるタスクバーで進捗状況を確認できる(実行中は青、完了は緑)

 ステージング環境に新アプリケーションのデプロイが完了した後、SpinnakerはSlackで管理者に通知する。管理者がパイプラインを次に進めることを承認すると、ステージング環境のBakeで作成したイメージを使って本番環境でDeployを実行。ここではRed/Black Deployを行うので、新規でサーバグループが作成される。本番環境へのデプロイ完了後は、ブラウザで実際に「Hello World02」が表示されることを確認する。

 ここまでの検証結果としては、「GitHubにコードをアップロードするだけで、デプロイまで動いた」、そして「所要時間は約14分」だった。

 切り戻しについては、Spinnakerの画面で[Roleback]を選択して、切り戻し先のサーバグループを指定すれば自動実行される。こちらは、ブラウザで「Hello World01」が表示されることで切り戻しできたことを確認する。実際に行われる処理は、大まかにいえばキャッシュのクリアとロードバランサの向き先変更くらいであり、検証結果としては「2~3クリックの簡単な操作で切り戻しできた(所要時間約1分)」とのこと。

 なお、Spinnakerの画面に表示されるアイコンの色により、サーバグループの状態を確認することも可能だ。正常なら緑、異常な場合は赤、また、ロードバランサから切り離された無効な状態では半透明で表示される。例えば、切り戻しの完了は、元のアプリケーションのサーバグループが半透明から緑色に変わった(有効になった)ことで確認できる。

 溝内氏は今回の検証を通じて感じたSpinnakerのメリットとして、1つの画面で状況を把握できるうえ、さまざまな操作が行えることを挙げた。

 「タスクバーの状態でGitHubへのアップから本番環境にデプロイするまでの進捗状況を確認できるのは、運用者の視点からしてありがたいこと。AWSのマネジメントコンソールにログインする必要がなく、Spinnakerの画面からELBやセキュリティグループ、オートスケーリンググループ、AMIを作成できるのも便利。また、今回の検証ではそれぞれ2台のサーバグループしか使っていないが、数百台を対象とする場合などは、異常なインスタンスをひと目で判断できる色分け表示の機能も重宝する」

 一方で、今後の改善を期待したい点もあるという。具体的には、GUI上でプルダウンから選択する際に項目が表示されない場合があるなど若干動作が不安定なことや、AWS特有の問題でサブネット名の命名規則が決まっていること、同じくAWS特有の問題としてSpinnaker上でセキュリティグループを作るときに送信元・送信先がIPアドレスを指定できないことなどを挙げた。

 とはいえ、SpinnakerはOSSとしてまだ発展途上にあるツールだ。NetflixやGoogle、Microsoftといった有名企業の開発者を中心に、現在も鋭意開発・改善が進められており、今後さらに便利で使いやすい機能が実装されていくことが期待できる。

 溝内氏は最後に「クラウド環境へのデプロイに悩んでいる方は、一度検討してみる価値はある」と語り、セッションを締めくくった。

お問い合わせ

 株式会社エーピーコミュニケーションズ

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

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

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