本番環境で環境依存の問題が散見されたのでSpinnakerの導入を検討してみました
はじめに
会社で、 検証環境 では障害が発生しないが 本番環境 では障害が発生する、といったことが何度か続きました。
原因は 検証環境 と 本番環境 のクラウドサービスの設定の差異でした。
再現性のある方法でクラウド上の環境を構築してこなかったことが原因ではありますが、できてしまっているものはしょうがないです。
「カナリアデプロイ」 と呼ばれる、 本番環境 に部分的にデプロイして動作確認し、問題なければ全展開するデプロイ方法があります。
これはぜひ導入したい!そこで見つけた名前が Spinnaker でした。
Spinnakerを使って「カナリアデプロイ」が実現できる、という話を耳にしたので調べてみました。
graph LR;
load_balancer-->|95% Traffics| web_server(Web Server);
load_balancer-->|5% Traffics| new_web_server(Web Server); subgraph Old
web_server-->applicacion_server(Application Server)
applicacion_server(Application Server)-->database(Database);
end
subgraph New
new_web_server-->new_applicacion_server(Application Server)
new_applicacion_server(Application Server)-->new_database(Database);
end
継続的インテグレーション( CI )
素早いソフトウェアの改善・改良や新機能追加が求められる時代がありました。(当時は僕もJavaばっかり触っていました。)
当時、開発された分割モジュールを統合してビルドすると、、、
- ビルドに失敗する!
- 正常に動作しない!
なんてことはよくありました。
そこで偉い人?が「開発の早い段階から継続的に以下のステップを実施すればいいんじゃね?」と考えました。
- コードチェック
- ビルド
- ユニットテスト
こうして、継続的インテグレーション(CI)が誕生しました。
継続的デリバリ( CD )
更に時が過ぎ、「継続的インテグレーション」を更に推し進める思想が生まれました。
偉い人?が「ソフトウェアのデプロイも継続的に、自動的に行ったらいいんじゃね?」と考えました。
こうして、継続的デリバリ(CD)が誕生しました。
ちなみに、 「継続的デリバリ」 を行うためには、以下の2つが必要となります。
- ビルドされたパッケージ
- パッケージを運用環境にデプロイする手段
それを踏まえて、昨今の状況の話に移ります。
クラウドへの対応が求められている「継続的デリバリ」
最近では、クラウド環境を利用してサービスをデプロイするケースが増えてきました。
先の「継続的デリバリで必要なもの」のうち "2. パッケージを運用環境にデプロイする手段" もクラウドに対応する必要が生まれました。
Spinnakerの登場
そんな中塔城したのが Spinnaker というツールです。
特徴を簡単に上げてみます。
- Netflix が2015年11月に公開したツール
- クラウド環境のAPIを利用することで、スクリプトやツールを使ってデプロイを行える
- Webブラウザ経由で操作する フロントエンド + さまざまなクラウドインフラに対応する バックエンド のセット
- 処理が実行されるトリガーは2つ
- 手動実行(GUIから)
- 自動実行(Docker Registryへのイメージプッシュやcronなど)
- Kubernetesでも動作可能
ブルーグリーンデプロイに対応
万が一に備えて、デプロイ時には全く新しいインフラ基盤にデプロイし、
問題があった場合直ちに古いインフラ基盤に切り戻しする、という方法に対応しているようです。
graph LR;
load_balancer-.->|0% Traffics| web_server(Web Server);
load_balancer-->|100% Traffics| new_web_server(Web Server);
subgraph Old
web_server-->applicacion_server(Application Server)
applicacion_server(Application Server)-->database(Database);
end
subgraph New
new_web_server-->new_applicacion_server(Application Server)
new_applicacion_server(Application Server)-->new_database(Database);
end
カナリアデプロイに対応
当然のことながら、今回求めていた カナリアデプロイ 機能が提供されています。
まずは小さくデプロイして一部のユーザに利用できる形で様子を見て、問題なさそうなら100%トラフィックを新しいインフラ基盤に切り替える( rollout )、という方式です。
graph LR;
load_balancer-->|95% Traffics| web_server(Web Server);
load_balancer-->|5% Traffics| new_web_server(Web Server);
subgraph Old
web_server-->applicacion_server(Application Server)
applicacion_server(Application Server)-->database(Database);
end
subgraph New
new_web_server-->new_applicacion_server(Application Server)
new_applicacion_server(Application Server)-->new_database(Database);
end
Automated Canary Analysis (ACA) と呼ばれる機能が面白い
面白いな、と思った機能として Automated Canary Analysis (ACA) というものがありました。
- Canary Deploy を行ったあと、アプリケーションのレイテンシやログのエラーレートを計測し、デプロイに点数をつける
- 点数が設定値を満たしている→ Rollout(全展開)
- 点数が設定値を満たしていない→ Rollback(切り戻し、デプロイの撤退!)
インストール方法
インストールや設定を行うための専用ツール「halyard」を利用する。(2017年6月に公開された Spinnaker ver1.0 移行であれば利用可能。)
- halyardをインストール
- halyardが提供する「hal」コマンドを使ってコンポーネントの設定やインストールを行う
ひとこと
今日はここまで。
インストール方法まで理解できました。
インストールして、実際に触ってみたいと思います。
ディスカッション
コメント一覧
まだ、コメントがありません