実録Blue-Green Deployment導入記

#ccc_g11

Copyright 2016 Hiroyuki Onaka

#ccc_g1

実録Blue-Green Deployment導入記

2016/12/3 JJUG CCC 2016 Fall

大中浩行この作品はクリエイティブ・コモンズ表示 4.0 国際ライセンスの下に提供されています。

http://creativecommons.org/licenses/by/4.0/

#ccc_g11


#ccc_g1

注意！

このセッションでは、以下の様なイカしたキー

ワードは出てきません！

• Infrastructure as Code

• Docker

• Serverless Architecture

#ccc_g11


#ccc_g1

今日お話すること

一つの組織の中でメンテナンスするアプリケー

ションを分割して開発・運用する時に、

• システム同士をどう連携させるか

• 稼働する系統(Blue/Green)の切替えをどう

行うか

#ccc_g11


#ccc_g1

お品書き

• Blue-Green Deploymentとは

• Blue-Green Deployment導入の障壁

• GSLB

• データベース

• Blue-Green

#ccc_g11


Blue-Green Deploymentとは

#ccc_g11


#ccc_g1

「継続的デリバリー」

「本番環境としてまったく同じ環境を2組用意す

るという考え方で、それぞれをブルーおよびグ

リーンと呼ぶ。」

Jez Hunble, David Farley(著) 和智右桂、髙木正広(訳)「継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」

#ccc_g11


#ccc_g1

クラウド時代のBlue-Green Deployment

「Deep Dive into Blue/Green Deployments on AWS」http://www.slideshare.net/AmazonWebServices/dvo401-deep-dive-into-bluegreen-deployments-on-aws

http://www.slideshare.net/AmazonWebServices/dvo401-deep-dive-into-bluegreen-deployments-on-aws

#ccc_g11


#ccc_g1

Blue-Greenを実現する方法

• In Place: インスタンスはそのままに、新し

いリビジョンのアプリのみその場で反映され

る

• Blue/Green: 新しいリビジョンのアプリ用に、

新しいインスタンスを構築して入れ替える

AWS Solutions Architect ブログ: Blue/Greenデプロイとは？

http://aws.typepad.com/sajp/2015/12/what-is-blue-green-deployment.html

http://aws.typepad.com/sajp/2015/12/what-is-blue-green-deployment.html

#ccc_g11


#ccc_g1

• All at once: 全台を一斉に新しいリビジョン

でデプロイする

• One by one: 1台ずつ新しいリビジョンをデ

プロイする

• Batch: 数台(例えば半数)ずつ新しいリビ

ジョンをデプロイする

#ccc_g11


#ccc_g1

今日お話しするのは「In PlaceのBatch」の話に

なります。(アプリの入替を、半分のインスタン

スに対して行う)

#ccc_g11


サービスの紹介

#ccc_g11


#ccc_g12014年秋のJJUG CCCで、TDD導入について発表しました

http://www.slideshare.net/setoazusa/jug-2014-fall-how-to-intoroduce-tdd

http://www.slideshare.net/setoazusa/jug-2014-fall-how-to-intoroduce-tdd

#ccc_g11


#ccc_g1

今日は、その続きの話です

その後どうなったか

#ccc_g11


#ccc_g1

「TDDの導入したいんです」

→「CI導入しましょう」

→「デプロイ自動化したいですね」

→「インフラの自動化もお願いしたく」←ｲﾏｺｺ

#ccc_g11


#ccc_g1

インフラエンジニア爆誕

By Gsmith1of2 at English Wikipedia [Public domain], via Wikimedia Commonshttps://commons.wikimedia.org/wiki/File%3ANetworkOperations.jpg

https://commons.wikimedia.org/wiki/File:NetworkOperations.jpg

#ccc_g11


#ccc_g1

インフラエンジニアとは

• 開発チームの時…主にJava

• インフラチーム…主にシェルスクリプトと

ruby、たまにGo言語

• データセンターのラックの配線とか、しませ

んよ？

#ccc_g11


#ccc_g1

• 通信事業者の法人向けサービス基盤

• 開発プロセスはスクラム

• 日本と海外拠点での並行開発(同一コード

ベース)

• サービスインして2年半

#ccc_g11


ロードバランサー

認可サーバー

Webサーバー&APIサーバー

データ連携サーバー

データベース

認証サーバー

AZ1 AZ2

Blueサーバー Greenサーバー

#ccc_g11


#ccc_g1

システムの構成

• ユーザー向け機能およびバックオフィスと、

ユーザーの認証およびシングルサインオンを

行うサーバー(認証サーバー)の二系統

• 認証サーバーはMulti-AZ(Availability Zone)

• 外部へのデータ連携はデータ連携サーバーが、

Spring Batchのジョブを随時起動する

#ccc_g11


#ccc_g1

• サービスイン当初は、夜間の計画メンテナン

スによるリリース作業を行っていました

#ccc_g11


#ccc_g1

• 夜間帯も含めて、ユーザーにリアルタイムに

通知を行う機能の追加

• 海外に拠点を持つユーザーが使用を開始

→夜間とはどこのTimeZoneの夜間なのか

#ccc_g11


#ccc_g1

そして何より、リリース時にサービス停止を伴

うことにより、頻繁なリリースによるフィード

バックを得ることが難しくなること。

#ccc_g11


#ccc_g1ということで、Blue-Green Deploymentに取り組むわけですが...

最初からBlue-Green Deploymentを想定して

開発できるなら、その方が絶対にいいです！

Blue-Green Deploymentの導入のために何回

夜勤をしたことか...(TT)

#ccc_g11


Blue-Green導入の障壁

https://pixabay.com/ja/%E8%83%B8%E5%A3%81-%E5%A3%81-%E7%9F%B3%E5%A3%81-castelgrande-%E3%83%99%E3%83%AA%E3%83%B3%E3%83%84%E3%82%A9%E3%83%BC%E3%83%8A-%E4%B8%AD%E4%B8%96-418950/

https://pixabay.com/ja/%E8%83%B8%E5%A3%81-%E5%A3%81-%E7%9F%B3%E5%A3%81-castelgrande-%E3%83%99%E3%83%AA%E3%83%B3%E3%83%84%E3%82%A9%E3%83%BC%E3%83%8A-%E4%B8%AD%E4%B8%96-418950/

#ccc_g11


#ccc_g1

「準備が整えば、新しいバージョンを公開する

のは単にルーターの設定を変えるだけの作業と

なる。これまでグリーン環境に向けていた設定

を、ブルー環境向けに切り替えればよいの

だ。」

「継続的デリバリー」から

#ccc_g11


#ccc_g1

「切り替えればよいのだ」

By DanRhttps://www.flickr.com/photos/dansdata/4083643660

https://www.flickr.com/photos/dansdata/4083643660

#ccc_g11


#ccc_g1

最初は、こう

#ccc_g11


#ccc_g1「静的コンテンツのためにWebサーバーいるよね」

#ccc_g11


#ccc_g1「認可のこと考えるとリバースプロキシーおいたほうが」

#ccc_g11


#ccc_g1

「データベースのこと忘れてました」

#ccc_g11


#ccc_g1「外部のデータ連携は非同期で行いたいんですよ」

#ccc_g11


#ccc_g1

「切替ポイントがいっぱいあるんですが…」

#ccc_g11


Sam Newman(著) 佐藤直生(監訳) 「マイクロサービスアーキテクチャ」

#ccc_g11


#ccc_g1本来なら、独立したサービスがそれぞれルーティングを切り替えればよい

BY Rose and Trev Clough(CC-BY SA 2.0) http://www.geograph.org.uk/photo/1490900

http://www.geograph.org.uk/photo/1490900

#ccc_g11


#ccc_g1だが実際には、Blue/Greenのサーバ群の稼働する系統を切り替えることになる

#ccc_g11


#ccc_g1

デプロイした後、サーバープロセスの起動だけ

確認してサービスインするつもりですか？

普通サービスインの前に動作確認ってするもの

じゃないんですか？

#ccc_g11


#ccc_g1

サービス特有の事情

「デプロイした後、本番環境上でシステムテス

トを行わないとサービスイン不可」という内部

ルール。

#ccc_g11


#ccc_g1

結果として、この事例において「Blue-Green

Deploymentを導入する」ということは、「同

時に稼働するバージョンが違う本番環境が二つ

できる」ということになりました。

#ccc_g11


#ccc_g1

このようなアプリケーション層の問題を乗り越

えたところで、Blue-Green Deploymentの実

現にはラスボスがいます

#ccc_g11


#ccc_g1By NYhttp://www.thebluediamondgallery.com/scrabble/d/database.html

http://www.thebluediamondgallery.com/scrabble/d/database.html

#ccc_g11


#ccc_g1

データベースの手強さ

• Blue-Greenなのに環境間で共有している

• サービスインしたままでデータ構造の変更っ

てどうやるのさ？

#ccc_g11


冬の陣

(GSLB)

ムカイ(Public Domain) https://ja.wikipedia.org/wiki/%E5%A4%A7%E5%9D%82%E5%9F%8E

https://ja.wikipedia.org/wiki/%E5%A4%A7%E5%9D%82%E5%9F%8E

#ccc_g11


#ccc_g1

まず、ここの話

認証サーバー

#ccc_g11


#ccc_g1

認証サーバーは、それぞれのAZの稼働を交互に

切り替えてデプロイすることで、サービス無停

止でリリースが出来るようにします。

切替には、GSLBというアプライアンスを使いま

す。

#ccc_g11


#ccc_g1

GSLB

• 広域負荷分散(Global Site Load Balancing)

• DNSの応答を制御するタイプのロードバラン

サー

#ccc_g11


#ccc_g1

GSLB

DNS制御

#ccc_g11


#ccc_g1GSLBを使えば、AZをまたいだサイト切替が実現できます。

…カタログスペック上はね？

#ccc_g11


#ccc_g1

GSLBの運用で考慮が必要なもの

• DNSクライアントのキャッシュ

• クライアントのkeep-alive

#ccc_g11


#ccc_g1

WebブラウザーによるDNSキャッシュ

Ben Anderson 「Why Web Browser DNS Caching Can Be A Bad Thing」

http://dyn.com/blog/web-browser-dns-caching-bad-thing/

http://dyn.com/blog/web-browser-dns-caching-bad-thing/

#ccc_g11


#ccc_g1

Public CloudのDNSフェイルオーバーの検証記

事で、切替時にブラウザーを再起動しているも

のが散見されますが、これはブラウザーのプロ

セス上のDNSキャッシュが原因です。

#ccc_g11


#ccc_g1

もう一つの問題

GSLB

DNS制御

#ccc_g11


#ccc_g1

Javaプログラムから外部サーバーに接続する際、

JVM上のDNSキャッシュを無効にするために起

動オプションを付与する

(例: -Dsun.net.inetaddr.ttl=0

-Dsun.net.inetaddr.negative.ttl=1)

というノウハウがありますが、それだけでは不

十分なケースがあります。

#ccc_g11


#ccc_g1

アプリケーショサーバー上でのkeep-alive接続

接続元のサーバーでkeep-aliveしている接続は、

DNSが切り替わってもそのまま使われます。

#ccc_g11


#ccc_g1

Blue-Green Deploymentを実現する上では、

DNSを切り替えてもクライアントの接続先サー

バーは切り替わらない。

というのが実態です。

#ccc_g11


#ccc_g1

どうするか

GSLB

DNS制御

#ccc_g11


#ccc_g1

こうする

GSLB

DNS制御

#ccc_g11


#ccc_g1

ロードバランサーでサーバーへの接続をTCPレ

ベルで切断すると、クライアントがそれをトリ

ガーにしてDNSのキャッシュを更新するので、

そうすると切替先のサーバーへ接続が向くよう

になります。

#ccc_g11


#ccc_g1

• ネットワーク構成や通信プロトコルによって、

実際の挙動はかわってきます。

• DNSを用いた負荷分散を行う場合は、切り替

え時の実機・実サーバー上の挙動について

しっかり検証を行いましょう。

#ccc_g11


真田丸(データベース)

By うぃき野郎 (Own work)

[CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commonshttps://commons.wikimedia.org/wiki/File:Restructured_Model_of_Sanadamaru_Fort1.jpg

https://commons.wikimedia.org/wiki/File:Restructured_Model_of_Sanadamaru_Fort1.jpg

#ccc_g11


#ccc_g1

基本的な考え

• データベースのスキーマーは、データベース

マイグレーションツールを使って、アプリ

ケーションのリリース時に更新する。

#ccc_g11


#ccc_g1

• 動作確認のために新バージョンのアプリケー

ションが作成したデータを旧バージョンのバッ

クオフィス機能で参照した時に、エラーが発生

しないようにする

• エンドユーザー向け機能はマルチテナントのアーキテ

クチャーになっているため新旧のデータが動作時に混

在することは少ないが、バックオフィス機能は全テナ

ントのデータを一括で扱うため

#ccc_g11


#ccc_g1

原則

• データ構造の互換性を失うようなマイグレー

ションは行わない

• データ構造を変更する場合は、新規カラムの

追加を最初のリリースで行い、その次のリ

リースで不要なカラムを削除する

#ccc_g11


#ccc_g1

で、うまくいくと思ったのですが...

• データ構造の変更を伴わないマスターデータ

の更新(仕様変更)を行った際に、切り替え元

(旧バージョン)の動作で支障を来すケースが

発生。

• 具体的にはURLに対するアクセス認可のマス

ター

#ccc_g11


#ccc_g1

解決策

• 主系(旧バージョン)と副系(新バージョン)で

仕様が変わることがあり得るマスターに対し

てはデータベースで保持するのをやめて、ア

プリケーション側で設定ファイルとして保持

するようにする

#ccc_g11


#ccc_g1

「マイクロサービスアーキテクチャ」から

「第2の選択肢は、代わりにこの共有静的データ

をコードとして扱うことです。...データの一貫

性に関する問題は残りますが、経験から、稼働

中のデータベーステーブルを変更するよりも変

更を構成ファイルに展開する方がはるかに簡単

であることがわかります。」

#ccc_g11


By Snlf1 (Own work)[CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Akazonae_Sanada.jpg

夏の陣

(Blue-Green)

https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Akazonae_Sanada.jpg

#ccc_g11


#ccc_g1

• ロードバランサーのルーティング

• 非同期処理の連携

• Blue-Greenの切替

#ccc_g11


#ccc_g1その前に、私達のドメインの用語の確認をさせてください

• 主系…Blueサーバー/Greenサーバーの内、サービス

インしている系統。本番環境。切替後は副系になる。

• 副系…もう一方の、新しいバージョンをデプロイし

て、動作確認を行っている系統。切替後は主系にな

る。

「Blueが主系、Greenが副系」という言い方をします。

#ccc_g11


#ccc_g1

ロードバランサーのルーティング

• ユーザーからのアクセスは主系に、動作確認

のためのアクセスは副系に振り分ける

#ccc_g11


#ccc_g1

グローバルIPアドレス1(主系用)

グローバルIPアドレス2(副系用)

Blueサーバー ○ ×

Greenサーバー × ○

#ccc_g11


#ccc_g1

グローバルIPアドレス1(主系用)

グローバルIPアドレス2(副系用)

Blueサーバー × ○

Greenサーバー ○ ×

#ccc_g11


#ccc_g1

非同期処理の連携

アクセスが来た後、データ連携を行うまでの、サー

バー間のトランザクションは、主系サーバー、副系

サーバー相互で連動して動くようにする

Blueサーバーが主系の時、主系(Blueサーバー)が登

録したデータは、同じく主系(Blueサーバー)のデー

タ連携サーバーが処理する

#ccc_g11


#ccc_g1

ここが問題

※非同期

#ccc_g11


#ccc_g1

対処法

• BlueサーバーとGreenサーバーどちらが主系でどち

らが副系かをデータベース上に保持し、参照する。

• O/Rマッパー(Hibernate)上の処理にinterceptorを

適用して、データベース上に投入するレコードが、

主系が投入したレコードなのか、副系で投入したレ

コードなのか、区別がつくようにする

#ccc_g11


#ccc_g1

Blue-Greenの切替

主系、副系の切り替え時は、処理途中で主系

サーバーがBlue(Green)サーバーから

Green(Blue) サーバーに切り替わる場合がある

ので、それに対応できるようにする。

#ccc_g11


#ccc_g1

切り替え手順を見てみましょう

以下は、

Blueサーバー主系、Greenサーバー副系

から、

Greenサーバー主系、Blueサーバー副系

に切り替える場合の手順

#ccc_g11


#ccc_g1

初期状態

GreenBlue

#ccc_g11


#ccc_g1

図の見方

GreenBlueBlue

赤の線…主系

黒の線…副系

実線( )

…ユーザーのアクセス

破線( )

…動作確認のためのアクセス

…プロセス起動

…プロセス停止

#ccc_g11


#ccc_g1

両方主系にする(1/5)

Blue Green

#ccc_g11


#ccc_g1Blueサーバーのデータ連携サーバーを停止する(2/5)

Blue Green

#ccc_g11


#ccc_g1

ロードバランサーを切り替える(3/5)

Blue Green

#ccc_g11


#ccc_g1

Blueサーバーを副系にする(4/5)

Green

#ccc_g11


#ccc_g1

副系になったデータ連携サーバーを起動する(5/5)

Blue Green

#ccc_g11


#ccc_g1

ポイント

切替処理はCIサーバーからワンクリックで出来

るようにしている

切替処理に冪等性を持たせている

#ccc_g11


#ccc_g1

切替の手順自体は、システムの構成に依存して

いるので、汎用的にこの手順が使えるわけでは

ないです。

#ccc_g11


#ccc_g1

なぜこうなるか

ロードバランサーやサーバーなど、複数の機器

の状態を手順を踏んで変更しているが、その操

作をアトミックにはできないため、両方のサー

バーが一旦主系になるなど、手順を踏む数が多

くなっている。

このこと自体は、どこでも起き得ることです。

#ccc_g11


http://startupstockphotos.com/post/82514406502/we-create-here-in-the-making-folks-read-the-blog

Blue-Green Deploymentを支える技術

http://startupstockphotos.com/post/82514406502/we-create-here-in-the-making-folks-read-the-blog

#ccc_g11


#ccc_g1

自動化

切替時にロードバランサーやアプリケーション

の切替に複雑な手順を踏んでいますが、Blue-

Green Deploymentの導入前からリリースに関

する作業の自動化を地道に進めていたので、CI

サーバーからワンクリックで切り替えられるよ

うになっています。

#ccc_g11


#ccc_g1

テスティング

データ連携に関係する主系・副系の切り替えの

ためのコード修正は、自動化されたユニットテ

ストとCIなしでは実現できませんでした。

#ccc_g11


#ccc_g1

テスティング(2)

Blue-Green構築時のインフラ観点でのシステム

テストでは、Gebによる自動化されたend to

end のテストを最大限に活用しました。

#ccc_g11


#ccc_g1

pull requestによるコードレビュー

• インフラの担当エンジニアがプロダクション

コードの修正をレビューする

• 開発の担当エンジニアがデプロイスクリプト

の修正をレビューする

#ccc_g11


#ccc_g1

Blue-Green Deploymentを支える技術

• 自動化

• テスティング

• バージョン管理

#ccc_g11


まとめ

「冗談じゃない、ベンダーは私達よ、他の誰でもない！私達が作って私達が運用する。それ以外に技術屋の動きなんてありえない！」

- 夏見公司「なれる!SE3 失敗しない？提案活動」

#ccc_g11


#ccc_g1

最終成果

• 日中でのサービス無停止リリースが実現

• サービス無停止リリースを実現したことにつ

いて、お客様の企画部門で表彰される

#ccc_g11


#ccc_g1

コードレビューの事例に代表されるように、開

発チームとインフラチームが実現すべきゴール

を共有した上で、お互いの役割を発揮できたか

らこそ、Blue-Green Deploymentを導入でき

たと思います。

#ccc_g11


#ccc_g1

私たち、DevOpsしています(ドヤッ)

#ccc_g11


#ccc_g1

「素早くリリースする」のがDevOpsではない

「Opsの役割は、ビジネスを実現することであ

る」

- John Allspaw, 「10+ Deploys Per Day: Dev and

Ops Cooperation at Flickr」から

#ccc_g11


#ccc_g1

誰がDevOpsするのか

私はどこのポジションなのか

#ccc_g11


#ccc_g1

SlackをSIerに導入した話

小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来

http://blog.livedoor.jp/lalha/archives/50528045.html

http://blog.livedoor.jp/lalha/archives/50528045.html

#ccc_g11


#ccc_g1

富士通がAdvent Calendarに参加することになった理由

富士通がAdvent Calendarに参加することになった理由 – blog

http://tnaoto.hatenablog.com/entry/2016/12/02/114611

http://tnaoto.hatenablog.com/entry/2016/12/02/114611

#ccc_g11


#ccc_g1

• SIの現場でも技術の追求は出来ます

• オワコンではないです

• 僕たちの業界はもっとよくなれる

#ccc_g11


日本のDevOpsはSIがリードする

青空白帆(CC BY 2.1 JP)

http://photozou.jp/photo/show/254715/28171547

http://photozou.jp/photo/show/254715/28171547

#ccc_g11


#ccc_g1

ありがとうございました！

• 大中浩行(Onaka,Hiroyuki)

• @setoazusa

• グロースエクスパートナーズ株式会社

アーキテクチャソリューション部

テクニカルリード

• http://blog.fieldnotes.jp/

Software

実録Blue-Green Deployment導入記