SlideShare ist ein Scribd-Unternehmen logo
1 von 103
Downloaden Sie, um offline zu lesen
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
実録Blue-Green Deployment導入記
2016/12/3 JJUG CCC 2016 Fall
大中浩行
この作品は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
注意!
このセッションでは、以下の様なイカしたキー
ワードは出てきません!
• Infrastructure as Code
• Docker
• Serverless Architecture
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
今日お話すること
一つの組織の中でメンテナンスするアプリケー
ションを分割して開発・運用する時に、
• システム同士をどう連携させるか
• 稼働する系統(Blue/Green)の切替えをどう
行うか
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
お品書き
• Blue-Green Deploymentとは
• Blue-Green Deployment導入の障壁
• GSLB
• データベース
• Blue-Green
#ccc_g11
Copyright 2016 Hiroyuki Onaka
Blue-Green
Deploymentとは
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「継続的デリバリー」
「本番環境としてまったく同じ環境を2組用意す
るという考え方で、それぞれをブルーおよびグ
リーンと呼ぶ。」
Jez Hunble, David Farley(著) 和智右桂、髙木正広(訳)
「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#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
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#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
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• All at once: 全台を一斉に新しいリビジョン
でデプロイする
• One by one: 1台ずつ新しいリビジョンをデ
プロイする
• Batch: 数台(例えば半数)ずつ新しいリビ
ジョンをデプロイする
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
今日お話しするのは「In PlaceのBatch」の話に
なります。(アプリの入替を、半分のインスタン
スに対して行う)
#ccc_g11
Copyright 2016 Hiroyuki Onaka
サービスの紹
介
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
2014年秋のJJUG CCCで、TDD導入に
ついて発表しました
http://www.slideshare.net/setoazusa/jug-2014-fall-how-to-intoroduce-tdd
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
今日は、その続きの話です
その後どうなったか
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「TDDの導入したいんです」
→「CI導入しましょう」
→「デプロイ自動化したいですね」
→「インフラの自動化もお願いしたく」←イマココ
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
インフラエンジニア爆誕
By Gsmith1of2 at English Wikipedia [Public domain], via Wikimedia Commons
https://commons.wikimedia.org/wiki/File%3ANetworkOperations.jpg
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
インフラエンジニアとは
• 開発チームの時…主にJava
• インフラチーム…主にシェルスクリプトと
ruby、たまにGo言語
• データセンターのラックの配線とか、しませ
んよ?
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• 通信事業者の法人向けサービス基盤
• 開発プロセスはスクラム
• 日本と海外拠点での並行開発(同一コード
ベース)
• サービスインして2年半
#ccc_g11
Copyright 2016 Hiroyuki Onaka
ロードバランサー
認可サーバー
Webサーバー&APIサーバー
データ連携サーバー
データベース
認証サーバー
AZ1 AZ2
Blueサーバー Greenサーバー
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
システムの構成
• ユーザー向け機能およびバックオフィスと、
ユーザーの認証およびシングルサインオンを
行うサーバー(認証サーバー)の二系統
• 認証サーバーはMulti-AZ(Availability Zone)
• 外部へのデータ連携はデータ連携サーバーが、
Spring Batchのジョブを随時起動する
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• サービスイン当初は、夜間の計画メンテナン
スによるリリース作業を行っていました
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• 夜間帯も含めて、ユーザーにリアルタイムに
通知を行う機能の追加
• 海外に拠点を持つユーザーが使用を開始
→夜間とはどこのTimeZoneの夜間なのか
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
そして何より、リリース時にサービス停止を伴
うことにより、頻繁なリリースによるフィード
バックを得ることが難しくなること。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ということで、Blue-Green
Deploymentに取り組むわけですが...
最初からBlue-Green Deploymentを想定して
開発できるなら、その方が絶対にいいです!
Blue-Green Deploymentの導入のために何回
夜勤をしたことか...(TT)
#ccc_g11
Copyright 2016 Hiroyuki Onaka
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/
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「準備が整えば、新しいバージョンを公開する
のは単にルーターの設定を変えるだけの作業と
なる。これまでグリーン環境に向けていた設定
を、ブルー環境向けに切り替えればよいの
だ。」
「継続的デリバリー」から
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「切り替えればよいのだ」
By DanR
https://www.flickr.com/photos/dansdata/4083643660
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
最初は、こう
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「静的コンテンツのためにWebサーバー
いるよね」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「認可のこと考えるとリバースプロキシー
おいたほうが」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「データベースのこと忘れてました」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「外部のデータ連携は非同期で行いたい
んですよ」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「切替ポイントがいっぱいあるんですが…」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
Sam Newman(著) 佐藤直生(監訳)
「マイクロサービスアーキテクチャ」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
本来なら、独立したサービスがそれぞれ
ルーティングを切り替えればよい
BY Rose and Trev Clough(CC-BY SA 2.0) http://www.geograph.org.uk/photo/1490900
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
だが実際には、Blue/Greenのサーバ群の稼
働する系統を切り替えることになる
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
デプロイした後、サーバープロセスの起動だけ
確認してサービスインするつもりですか?
普通サービスインの前に動作確認ってするもの
じゃないんですか?
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
サービス特有の事情
「デプロイした後、本番環境上でシステムテス
トを行わないとサービスイン不可」という内部
ルール。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
結果として、この事例において「Blue-Green
Deploymentを導入する」ということは、「同
時に稼働するバージョンが違う本番環境が二つ
できる」ということになりました。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
このようなアプリケーション層の問題を乗り越
えたところで、Blue-Green Deploymentの実
現にはラスボスがいます
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1By NY
http://www.thebluediamondgallery.com/scrabble/d/database.html
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
データベースの手強さ
• Blue-Greenなのに環境間で共有している
• サービスインしたままでデータ構造の変更っ
てどうやるのさ?
#ccc_g11
Copyright 2016 Hiroyuki Onaka
冬の陣
(GSLB)
ムカイ(Public Domain) https://ja.wikipedia.org/wiki/%E5%A4%A7%E5%9D%82%E5%9F%8E
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
まず、ここの話
認証サーバー
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
認証サーバーは、それぞれのAZの稼働を交互に
切り替えてデプロイすることで、サービス無停
止でリリースが出来るようにします。
切替には、GSLBというアプライアンスを使いま
す。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLB
• 広域負荷分散(Global Site Load Balancing)
• DNSの応答を制御するタイプのロードバラン
サー
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLB
DNS制御
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLBを使えば、AZをまたいだサイト切
替が実現できます。
…カタログスペック上はね?
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLBの運用で考慮が必要なもの
• DNSクライアントのキャッシュ
• クライアントのkeep-alive
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#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/
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Public CloudのDNSフェイルオーバーの検証記
事で、切替時にブラウザーを再起動しているも
のが散見されますが、これはブラウザーのプロ
セス上のDNSキャッシュが原因です。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
もう一つの問題
GSLB
DNS制御
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Javaプログラムから外部サーバーに接続する際、
JVM上のDNSキャッシュを無効にするために起
動オプションを付与する
(例: -Dsun.net.inetaddr.ttl=0
-Dsun.net.inetaddr.negative.ttl=1)
というノウハウがありますが、それだけでは不
十分なケースがあります。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
アプリケーショサーバー上でのkeep-alive接続
接続元のサーバーでkeep-aliveしている接続は、
DNSが切り替わってもそのまま使われます。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blue-Green Deploymentを実現する上では、
DNSを切り替えてもクライアントの接続先サー
バーは切り替わらない。
というのが実態です。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
どうするか
GSLB
DNS制御
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
こうする
GSLB
DNS制御
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ロードバランサーでサーバーへの接続をTCPレ
ベルで切断すると、クライアントがそれをトリ
ガーにしてDNSのキャッシュを更新するので、
そうすると切替先のサーバーへ接続が向くよう
になります。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• ネットワーク構成や通信プロトコルによって、
実際の挙動はかわってきます。
• DNSを用いた負荷分散を行う場合は、切り替
え時の実機・実サーバー上の挙動について
しっかり検証を行いましょう。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
真田丸
(データベース)
By うぃき野郎 (Own work)
[CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons
https://commons.wikimedia.org/wiki/File:Restructured_Model_of_Sanadamaru_Fort1.jpg
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
基本的な考え
• データベースのスキーマーは、データベース
マイグレーションツールを使って、アプリ
ケーションのリリース時に更新する。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• 動作確認のために新バージョンのアプリケー
ションが作成したデータを旧バージョンのバッ
クオフィス機能で参照した時に、エラーが発生
しないようにする
• エンドユーザー向け機能はマルチテナントのアーキテ
クチャーになっているため新旧のデータが動作時に混
在することは少ないが、バックオフィス機能は全テナ
ントのデータを一括で扱うため
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
原則
• データ構造の互換性を失うようなマイグレー
ションは行わない
• データ構造を変更する場合は、新規カラムの
追加を最初のリリースで行い、その次のリ
リースで不要なカラムを削除する
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
で、うまくいくと思ったのですが...
• データ構造の変更を伴わないマスターデータ
の更新(仕様変更)を行った際に、切り替え元
(旧バージョン)の動作で支障を来すケースが
発生。
• 具体的にはURLに対するアクセス認可のマス
ター
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
解決策
• 主系(旧バージョン)と副系(新バージョン)で
仕様が変わることがあり得るマスターに対し
てはデータベースで保持するのをやめて、ア
プリケーション側で設定ファイルとして保持
するようにする
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「マイクロサービスアーキテクチャ」から
「第2の選択肢は、代わりにこの共有静的データ
をコードとして扱うことです。...データの一貫
性に関する問題は残りますが、経験から、稼働
中のデータベーステーブルを変更するよりも変
更を構成ファイルに展開する方がはるかに簡単
であることがわかります。」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
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)
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• ロードバランサーのルーティング
• 非同期処理の連携
• Blue-Greenの切替
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
その前に、私達のドメインの用語の確認
をさせてください
• 主系…Blueサーバー/Greenサーバーの内、サービス
インしている系統。本番環境。切替後は副系になる。
• 副系…もう一方の、新しいバージョンをデプロイし
て、動作確認を行っている系統。切替後は主系にな
る。
「Blueが主系、Greenが副系」という言い方をします。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ロードバランサーのルーティング
• ユーザーからのアクセスは主系に、動作確認
のためのアクセスは副系に振り分ける
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
グローバル
IPアドレス1
(主系用)
グローバルIP
アドレス2
(副系用)
Blueサーバー ○ ×
Greenサーバー × ○
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
グローバル
IPアドレス1
(主系用)
グローバルIP
アドレス2
(副系用)
Blueサーバー × ○
Greenサーバー ○ ×
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
非同期処理の連携
アクセスが来た後、データ連携を行うまでの、サー
バー間のトランザクションは、主系サーバー、副系
サーバー相互で連動して動くようにする
Blueサーバーが主系の時、主系(Blueサーバー)が登
録したデータは、同じく主系(Blueサーバー)のデー
タ連携サーバーが処理する
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ここが問題
※非同期
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
対処法
• BlueサーバーとGreenサーバーどちらが主系でどち
らが副系かをデータベース上に保持し、参照する。
• O/Rマッパー(Hibernate)上の処理にinterceptorを
適用して、データベース上に投入するレコードが、
主系が投入したレコードなのか、副系で投入したレ
コードなのか、区別がつくようにする
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blue-Greenの切替
主系、副系の切り替え時は、処理途中で主系
サーバーがBlue(Green)サーバーから
Green(Blue) サーバーに切り替わる場合がある
ので、それに対応できるようにする。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
切り替え手順を見てみましょう
以下は、
Blueサーバー主系、Greenサーバー副系
から、
Greenサーバー主系、Blueサーバー副系
に切り替える場合の手順
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
初期状態
GreenBlue
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
図の見方
GreenBlue
Blue
赤の線…主系
黒の線…副系
実線( )
…ユーザーのアクセス
破線( )
…動作確認のためのアクセス
…プロセス起動
…プロセス停止
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
両方主系にする(1/5)
Blue Green
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blueサーバーのデータ連携サーバーを
停止する(2/5)
Blue Green
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ロードバランサーを切り替える(3/5)
Blue Green
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blueサーバーを副系にする(4/5)
Green
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
副系になったデータ連携サーバーを起動する(5/5)
Blue Green
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ポイント
切替処理はCIサーバーからワンクリックで出来
るようにしている
切替処理に冪等性を持たせている
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
切替の手順自体は、システムの構成に依存して
いるので、汎用的にこの手順が使えるわけでは
ないです。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
なぜこうなるか
ロードバランサーやサーバーなど、複数の機器
の状態を手順を踏んで変更しているが、その操
作をアトミックにはできないため、両方のサー
バーが一旦主系になるなど、手順を踏む数が多
くなっている。
このこと自体は、どこでも起き得ることです。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
http://startupstockphotos.com/post/82514406502/we-create-here-in-the-making-folks-read-the-blog
Blue-Green
Deployment
を支える技術
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
自動化
切替時にロードバランサーやアプリケーション
の切替に複雑な手順を踏んでいますが、Blue-
Green Deploymentの導入前からリリースに関
する作業の自動化を地道に進めていたので、CI
サーバーからワンクリックで切り替えられるよ
うになっています。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
テスティング
データ連携に関係する主系・副系の切り替えの
ためのコード修正は、自動化されたユニットテ
ストとCIなしでは実現できませんでした。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
テスティング(2)
Blue-Green構築時のインフラ観点でのシステム
テストでは、Gebによる自動化されたend to
end のテストを最大限に活用しました。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
pull requestによるコードレビュー
• インフラの担当エンジニアがプロダクション
コードの修正をレビューする
• 開発の担当エンジニアがデプロイスクリプト
の修正をレビューする
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blue-Green Deploymentを支える技術
• 自動化
• テスティング
• バージョン管理
#ccc_g11
Copyright 2016 Hiroyuki Onaka
まとめ
「冗談じゃない、ベンダーは私達よ、他の誰でもない!私達が作って私達が運用する。
それ以外に技術屋の動きなんてありえない!」
- 夏見公司「なれる!SE3 失敗しない?提案活動」
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
最終成果
• 日中でのサービス無停止リリースが実現
• サービス無停止リリースを実現したことにつ
いて、お客様の企画部門で表彰される
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
コードレビューの事例に代表されるように、開
発チームとインフラチームが実現すべきゴール
を共有した上で、お互いの役割を発揮できたか
らこそ、Blue-Green Deploymentを導入でき
たと思います。
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
私たち、DevOpsしています(ドヤッ)
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「素早くリリースする」のがDevOpsではない
「Opsの役割は、ビジネスを実現することであ
る」
- John Allspaw, 「10+ Deploys Per Day: Dev and
Ops Cooperation at Flickr」から
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
誰がDevOpsするのか
私はどこのポジションなのか
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
SlackをSIerに導入した話
小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来
http://blog.livedoor.jp/lalha/archives/50528045.html
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
富士通がAdvent Calendarに参加することになった理由
富士通がAdvent Calendarに参加することになった理由 – blog
http://tnaoto.hatenablog.com/entry/2016/12/02/114611
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• SIの現場でも技術の追求は出来ます
• オワコンではないです
• 僕たちの業界はもっとよくなれる
#ccc_g11
Copyright 2016 Hiroyuki Onaka
日本のDevOpsはSIがリードする
青空白帆(CC BY 2.1 JP)
http://photozou.jp/photo/show/254715/28171547
#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ありがとうございました!
• 大中浩行(Onaka,Hiroyuki)
• @setoazusa
• グロースエクスパートナーズ株式会社
アーキテクチャソリューション部
テクニカルリード
• http://blog.fieldnotes.jp/

Weitere ähnliche Inhalte

Was ist angesagt?

Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016
Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016
Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016JUNICHI YOSHISE
 
割と新し目の Open shift origin で作る自宅 paas 作成記
割と新し目の Open shift origin で作る自宅 paas 作成記割と新し目の Open shift origin で作る自宅 paas 作成記
割と新し目の Open shift origin で作る自宅 paas 作成記Hara Yoshihiko
 
Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較Kazuto Kusama
 
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くしたNginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くしたtoshi_pp
 
What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318Yuhki Hanada
 
Kubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CD
Kubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CDKubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CD
Kubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CDPreferred Networks
 
DCK Server プロトタイプ
DCK Server プロトタイプDCK Server プロトタイプ
DCK Server プロトタイプEtsuji Nakai
 
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春VerMasahito Zembutsu
 
OpenShift 3で、DockerのPaaSを作る話
OpenShift 3で、DockerのPaaSを作る話OpenShift 3で、DockerのPaaSを作る話
OpenShift 3で、DockerのPaaSを作る話Kazuto Kusama
 
Microservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on AzureMicroservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on AzureTsukasa Kato
 
Rookの基礎・バージョンアップ
Rookの基礎・バージョンアップRookの基礎・バージョンアップ
Rookの基礎・バージョンアップTakashi Sogabe
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018Yoshio Terada
 
クラウドを『作る』ってどういうこと?
クラウドを『作る』ってどういうこと?クラウドを『作る』ってどういうこと?
クラウドを『作る』ってどういうこと?Kazuto Kusama
 
KubernetesとOpenShiftの話
KubernetesとOpenShiftの話KubernetesとOpenShiftの話
KubernetesとOpenShiftの話Kazuto Kusama
 
はじめての CircleCI
はじめての CircleCIはじめての CircleCI
はじめての CircleCIYosuke Mizutani
 
Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話Masaki Yamamoto
 
Wasm blazor and wasi 2
Wasm blazor and wasi 2Wasm blazor and wasi 2
Wasm blazor and wasi 2Takao Tetsuro
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021Preferred Networks
 
NTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみよう
NTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみようNTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみよう
NTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみようMidori Oge
 
20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on LinuxTakayoshi Tanaka
 

Was ist angesagt? (20)

Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016
Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016
Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016
 
割と新し目の Open shift origin で作る自宅 paas 作成記
割と新し目の Open shift origin で作る自宅 paas 作成記割と新し目の Open shift origin で作る自宅 paas 作成記
割と新し目の Open shift origin で作る自宅 paas 作成記
 
Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較
 
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くしたNginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
 
What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318What's new in open shift container platform 4.7 japan_20210318
What's new in open shift container platform 4.7 japan_20210318
 
Kubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CD
Kubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CDKubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CD
Kubernetes Meetup Tokyo #35_GitOps Toolkit による Kubernetes マニフェスト CD
 
DCK Server プロトタイプ
DCK Server プロトタイプDCK Server プロトタイプ
DCK Server プロトタイプ
 
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver
 
OpenShift 3で、DockerのPaaSを作る話
OpenShift 3で、DockerのPaaSを作る話OpenShift 3で、DockerのPaaSを作る話
OpenShift 3で、DockerのPaaSを作る話
 
Microservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on AzureMicroservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on Azure
 
Rookの基礎・バージョンアップ
Rookの基礎・バージョンアップRookの基礎・バージョンアップ
Rookの基礎・バージョンアップ
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018
 
クラウドを『作る』ってどういうこと?
クラウドを『作る』ってどういうこと?クラウドを『作る』ってどういうこと?
クラウドを『作る』ってどういうこと?
 
KubernetesとOpenShiftの話
KubernetesとOpenShiftの話KubernetesとOpenShiftの話
KubernetesとOpenShiftの話
 
はじめての CircleCI
はじめての CircleCIはじめての CircleCI
はじめての CircleCI
 
Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話
 
Wasm blazor and wasi 2
Wasm blazor and wasi 2Wasm blazor and wasi 2
Wasm blazor and wasi 2
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
 
NTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみよう
NTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみようNTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみよう
NTTコミュニケーションズ Cloudn勉強会資料 SDKでAPIをたたいてみよう
 
20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux
 

Ähnlich wie Jjug ccc 2016_fall_blue_green_deployment

Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介
Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介
Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介Kohei Nishikawa
 
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Appsグリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & AppsGoogle Cloud Platform - Japan
 
私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由gree_tech
 
2021/03/19 パブリッククラウドを活かす運用プロセス自動化
2021/03/19 パブリッククラウドを活かす運用プロセス自動化2021/03/19 パブリッククラウドを活かす運用プロセス自動化
2021/03/19 パブリッククラウドを活かす運用プロセス自動化Issei Hiraoka
 
Bluemixクラウド開発入門 Devlivery Pipeline デモ
Bluemixクラウド開発入門 Devlivery Pipeline デモBluemixクラウド開発入門 Devlivery Pipeline デモ
Bluemixクラウド開発入門 Devlivery Pipeline デモHideaki Tokida
 
(IDEユーザのための) ClojureのEmacs開発環境について
(IDEユーザのための) ClojureのEmacs開発環境について(IDEユーザのための) ClojureのEmacs開発環境について
(IDEユーザのための) ClojureのEmacs開発環境についてKazuhiro Hara
 
Microsoft MVP から見たクラウド サービスの現状と今後について
Microsoft MVP から見たクラウド サービスの現状と今後についてMicrosoft MVP から見たクラウド サービスの現状と今後について
Microsoft MVP から見たクラウド サービスの現状と今後についてIIJ
 
Garden introduction for dea users public
Garden introduction for dea users   publicGarden introduction for dea users   public
Garden introduction for dea users publicTakehiko Amano
 
今日から始めるDigitalOcean
今日から始めるDigitalOcean今日から始めるDigitalOcean
今日から始めるDigitalOceanMasahito Zembutsu
 
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~Yuki Ando
 
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -Yukihiko SAWANOBORI
 
ToolChainを使った次世代DevOps環境の作り方
ToolChainを使った次世代DevOps環境の作り方ToolChainを使った次世代DevOps環境の作り方
ToolChainを使った次世代DevOps環境の作り方Harada Kazuki
 
DevOps with Cloud services
DevOps with Cloud servicesDevOps with Cloud services
DevOps with Cloud servicesYoichiro Shimizu
 
激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】
激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】
激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】WESEEKWESEEK
 
Innovator Live Japan 3_23 【現場の本音】App Engine から Cloud Run に移行してみた.pdf
Innovator Live Japan 3_23  【現場の本音】App Engine から Cloud Run に移行してみた.pdfInnovator Live Japan 3_23  【現場の本音】App Engine から Cloud Run に移行してみた.pdf
Innovator Live Japan 3_23 【現場の本音】App Engine から Cloud Run に移行してみた.pdfsaka75
 
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話JustSystems Corporation
 
いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達softlayerjp
 

Ähnlich wie Jjug ccc 2016_fall_blue_green_deployment (20)

Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介
Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介
Mautic Meetup Tokyo #3 データベース不要CMS:Gravの紹介
 
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Appsグリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
 
私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由私たちがGCPを使い始めた本当の理由
私たちがGCPを使い始めた本当の理由
 
Katib
KatibKatib
Katib
 
2021/03/19 パブリッククラウドを活かす運用プロセス自動化
2021/03/19 パブリッククラウドを活かす運用プロセス自動化2021/03/19 パブリッククラウドを活かす運用プロセス自動化
2021/03/19 パブリッククラウドを活かす運用プロセス自動化
 
Bluemixクラウド開発入門 Devlivery Pipeline デモ
Bluemixクラウド開発入門 Devlivery Pipeline デモBluemixクラウド開発入門 Devlivery Pipeline デモ
Bluemixクラウド開発入門 Devlivery Pipeline デモ
 
(IDEユーザのための) ClojureのEmacs開発環境について
(IDEユーザのための) ClojureのEmacs開発環境について(IDEユーザのための) ClojureのEmacs開発環境について
(IDEユーザのための) ClojureのEmacs開発環境について
 
Microsoft MVP から見たクラウド サービスの現状と今後について
Microsoft MVP から見たクラウド サービスの現状と今後についてMicrosoft MVP から見たクラウド サービスの現状と今後について
Microsoft MVP から見たクラウド サービスの現状と今後について
 
Garden introduction for dea users public
Garden introduction for dea users   publicGarden introduction for dea users   public
Garden introduction for dea users public
 
今日から始めるDigitalOcean
今日から始めるDigitalOcean今日から始めるDigitalOcean
今日から始めるDigitalOcean
 
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
 
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
 
Oracle GoldenGate Cloud Service(GGCS)概要
Oracle GoldenGate Cloud Service(GGCS)概要Oracle GoldenGate Cloud Service(GGCS)概要
Oracle GoldenGate Cloud Service(GGCS)概要
 
ToolChainを使った次世代DevOps環境の作り方
ToolChainを使った次世代DevOps環境の作り方ToolChainを使った次世代DevOps環境の作り方
ToolChainを使った次世代DevOps環境の作り方
 
第9回しゃちほこオラクル倶楽部
第9回しゃちほこオラクル倶楽部第9回しゃちほこオラクル倶楽部
第9回しゃちほこオラクル倶楽部
 
DevOps with Cloud services
DevOps with Cloud servicesDevOps with Cloud services
DevOps with Cloud services
 
激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】
激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】
激白!GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】
 
Innovator Live Japan 3_23 【現場の本音】App Engine から Cloud Run に移行してみた.pdf
Innovator Live Japan 3_23  【現場の本音】App Engine から Cloud Run に移行してみた.pdfInnovator Live Japan 3_23  【現場の本音】App Engine から Cloud Run に移行してみた.pdf
Innovator Live Japan 3_23 【現場の本音】App Engine から Cloud Run に移行してみた.pdf
 
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
 
いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達いまからでも遅くない Docker事始め&愉快な仲間達
いまからでも遅くない Docker事始め&愉快な仲間達
 

Jjug ccc 2016_fall_blue_green_deployment

  • 1. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 実録Blue-Green Deployment導入記 2016/12/3 JJUG CCC 2016 Fall 大中浩行 この作品は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。
  • 2. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 注意! このセッションでは、以下の様なイカしたキー ワードは出てきません! • Infrastructure as Code • Docker • Serverless Architecture
  • 3. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 今日お話すること 一つの組織の中でメンテナンスするアプリケー ションを分割して開発・運用する時に、 • システム同士をどう連携させるか • 稼働する系統(Blue/Green)の切替えをどう 行うか
  • 4. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 お品書き • Blue-Green Deploymentとは • Blue-Green Deployment導入の障壁 • GSLB • データベース • Blue-Green
  • 5. #ccc_g11 Copyright 2016 Hiroyuki Onaka Blue-Green Deploymentとは
  • 6. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「継続的デリバリー」 「本番環境としてまったく同じ環境を2組用意す るという考え方で、それぞれをブルーおよびグ リーンと呼ぶ。」 Jez Hunble, David Farley(著) 和智右桂、髙木正広(訳) 「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」
  • 7. #ccc_g11 Copyright 2016 Hiroyuki Onaka #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
  • 8. #ccc_g11 Copyright 2016 Hiroyuki Onaka #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
  • 9. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • All at once: 全台を一斉に新しいリビジョン でデプロイする • One by one: 1台ずつ新しいリビジョンをデ プロイする • Batch: 数台(例えば半数)ずつ新しいリビ ジョンをデプロイする
  • 10. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 今日お話しするのは「In PlaceのBatch」の話に なります。(アプリの入替を、半分のインスタン スに対して行う)
  • 11. #ccc_g11 Copyright 2016 Hiroyuki Onaka サービスの紹 介
  • 12. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 2014年秋のJJUG CCCで、TDD導入に ついて発表しました http://www.slideshare.net/setoazusa/jug-2014-fall-how-to-intoroduce-tdd
  • 13. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 今日は、その続きの話です その後どうなったか
  • 14. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「TDDの導入したいんです」 →「CI導入しましょう」 →「デプロイ自動化したいですね」 →「インフラの自動化もお願いしたく」←イマココ
  • 15. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 インフラエンジニア爆誕 By Gsmith1of2 at English Wikipedia [Public domain], via Wikimedia Commons https://commons.wikimedia.org/wiki/File%3ANetworkOperations.jpg
  • 16. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 インフラエンジニアとは • 開発チームの時…主にJava • インフラチーム…主にシェルスクリプトと ruby、たまにGo言語 • データセンターのラックの配線とか、しませ んよ?
  • 17. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • 通信事業者の法人向けサービス基盤 • 開発プロセスはスクラム • 日本と海外拠点での並行開発(同一コード ベース) • サービスインして2年半
  • 18. #ccc_g11 Copyright 2016 Hiroyuki Onaka ロードバランサー 認可サーバー Webサーバー&APIサーバー データ連携サーバー データベース 認証サーバー AZ1 AZ2 Blueサーバー Greenサーバー
  • 19. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 システムの構成 • ユーザー向け機能およびバックオフィスと、 ユーザーの認証およびシングルサインオンを 行うサーバー(認証サーバー)の二系統 • 認証サーバーはMulti-AZ(Availability Zone) • 外部へのデータ連携はデータ連携サーバーが、 Spring Batchのジョブを随時起動する
  • 20. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • サービスイン当初は、夜間の計画メンテナン スによるリリース作業を行っていました
  • 21. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • 夜間帯も含めて、ユーザーにリアルタイムに 通知を行う機能の追加 • 海外に拠点を持つユーザーが使用を開始 →夜間とはどこのTimeZoneの夜間なのか
  • 22. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 そして何より、リリース時にサービス停止を伴 うことにより、頻繁なリリースによるフィード バックを得ることが難しくなること。
  • 23. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 ということで、Blue-Green Deploymentに取り組むわけですが... 最初からBlue-Green Deploymentを想定して 開発できるなら、その方が絶対にいいです! Blue-Green Deploymentの導入のために何回 夜勤をしたことか...(TT)
  • 24. #ccc_g11 Copyright 2016 Hiroyuki Onaka 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/
  • 25. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「準備が整えば、新しいバージョンを公開する のは単にルーターの設定を変えるだけの作業と なる。これまでグリーン環境に向けていた設定 を、ブルー環境向けに切り替えればよいの だ。」 「継続的デリバリー」から
  • 26. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「切り替えればよいのだ」 By DanR https://www.flickr.com/photos/dansdata/4083643660
  • 27. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 最初は、こう
  • 28. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「静的コンテンツのためにWebサーバー いるよね」
  • 29. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「認可のこと考えるとリバースプロキシー おいたほうが」
  • 30. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「データベースのこと忘れてました」
  • 31. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「外部のデータ連携は非同期で行いたい んですよ」
  • 32. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「切替ポイントがいっぱいあるんですが…」
  • 33. #ccc_g11 Copyright 2016 Hiroyuki Onaka Sam Newman(著) 佐藤直生(監訳) 「マイクロサービスアーキテクチャ」
  • 34. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 本来なら、独立したサービスがそれぞれ ルーティングを切り替えればよい BY Rose and Trev Clough(CC-BY SA 2.0) http://www.geograph.org.uk/photo/1490900
  • 35. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 だが実際には、Blue/Greenのサーバ群の稼 働する系統を切り替えることになる
  • 36. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 デプロイした後、サーバープロセスの起動だけ 確認してサービスインするつもりですか? 普通サービスインの前に動作確認ってするもの じゃないんですか?
  • 37. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 サービス特有の事情 「デプロイした後、本番環境上でシステムテス トを行わないとサービスイン不可」という内部 ルール。
  • 38. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 結果として、この事例において「Blue-Green Deploymentを導入する」ということは、「同 時に稼働するバージョンが違う本番環境が二つ できる」ということになりました。
  • 39. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 このようなアプリケーション層の問題を乗り越 えたところで、Blue-Green Deploymentの実 現にはラスボスがいます
  • 40. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1By NY http://www.thebluediamondgallery.com/scrabble/d/database.html
  • 41. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 データベースの手強さ • Blue-Greenなのに環境間で共有している • サービスインしたままでデータ構造の変更っ てどうやるのさ?
  • 42. #ccc_g11 Copyright 2016 Hiroyuki Onaka 冬の陣 (GSLB) ムカイ(Public Domain) https://ja.wikipedia.org/wiki/%E5%A4%A7%E5%9D%82%E5%9F%8E
  • 43. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 まず、ここの話 認証サーバー
  • 44. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 認証サーバーは、それぞれのAZの稼働を交互に 切り替えてデプロイすることで、サービス無停 止でリリースが出来るようにします。 切替には、GSLBというアプライアンスを使いま す。
  • 45. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 GSLB • 広域負荷分散(Global Site Load Balancing) • DNSの応答を制御するタイプのロードバラン サー
  • 46. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 GSLB DNS制御
  • 47. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 GSLBを使えば、AZをまたいだサイト切 替が実現できます。 …カタログスペック上はね?
  • 48. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 GSLBの運用で考慮が必要なもの • DNSクライアントのキャッシュ • クライアントのkeep-alive
  • 49. #ccc_g11 Copyright 2016 Hiroyuki Onaka #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/
  • 50. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 Public CloudのDNSフェイルオーバーの検証記 事で、切替時にブラウザーを再起動しているも のが散見されますが、これはブラウザーのプロ セス上のDNSキャッシュが原因です。
  • 51. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 もう一つの問題 GSLB DNS制御
  • 52. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 Javaプログラムから外部サーバーに接続する際、 JVM上のDNSキャッシュを無効にするために起 動オプションを付与する (例: -Dsun.net.inetaddr.ttl=0 -Dsun.net.inetaddr.negative.ttl=1) というノウハウがありますが、それだけでは不 十分なケースがあります。
  • 53. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 アプリケーショサーバー上でのkeep-alive接続 接続元のサーバーでkeep-aliveしている接続は、 DNSが切り替わってもそのまま使われます。
  • 54. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 Blue-Green Deploymentを実現する上では、 DNSを切り替えてもクライアントの接続先サー バーは切り替わらない。 というのが実態です。
  • 55. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 どうするか GSLB DNS制御
  • 56. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 こうする GSLB DNS制御
  • 57. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 ロードバランサーでサーバーへの接続をTCPレ ベルで切断すると、クライアントがそれをトリ ガーにしてDNSのキャッシュを更新するので、 そうすると切替先のサーバーへ接続が向くよう になります。
  • 58. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • ネットワーク構成や通信プロトコルによって、 実際の挙動はかわってきます。 • DNSを用いた負荷分散を行う場合は、切り替 え時の実機・実サーバー上の挙動について しっかり検証を行いましょう。
  • 59. #ccc_g11 Copyright 2016 Hiroyuki Onaka 真田丸 (データベース) By うぃき野郎 (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons https://commons.wikimedia.org/wiki/File:Restructured_Model_of_Sanadamaru_Fort1.jpg
  • 60. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 基本的な考え • データベースのスキーマーは、データベース マイグレーションツールを使って、アプリ ケーションのリリース時に更新する。
  • 61. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • 動作確認のために新バージョンのアプリケー ションが作成したデータを旧バージョンのバッ クオフィス機能で参照した時に、エラーが発生 しないようにする • エンドユーザー向け機能はマルチテナントのアーキテ クチャーになっているため新旧のデータが動作時に混 在することは少ないが、バックオフィス機能は全テナ ントのデータを一括で扱うため
  • 62. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 原則 • データ構造の互換性を失うようなマイグレー ションは行わない • データ構造を変更する場合は、新規カラムの 追加を最初のリリースで行い、その次のリ リースで不要なカラムを削除する
  • 63. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 で、うまくいくと思ったのですが... • データ構造の変更を伴わないマスターデータ の更新(仕様変更)を行った際に、切り替え元 (旧バージョン)の動作で支障を来すケースが 発生。 • 具体的にはURLに対するアクセス認可のマス ター
  • 64. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 解決策 • 主系(旧バージョン)と副系(新バージョン)で 仕様が変わることがあり得るマスターに対し てはデータベースで保持するのをやめて、ア プリケーション側で設定ファイルとして保持 するようにする
  • 65. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「マイクロサービスアーキテクチャ」から 「第2の選択肢は、代わりにこの共有静的データ をコードとして扱うことです。...データの一貫 性に関する問題は残りますが、経験から、稼働 中のデータベーステーブルを変更するよりも変 更を構成ファイルに展開する方がはるかに簡単 であることがわかります。」
  • 66. #ccc_g11 Copyright 2016 Hiroyuki Onaka 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)
  • 67. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • ロードバランサーのルーティング • 非同期処理の連携 • Blue-Greenの切替
  • 68. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 その前に、私達のドメインの用語の確認 をさせてください • 主系…Blueサーバー/Greenサーバーの内、サービス インしている系統。本番環境。切替後は副系になる。 • 副系…もう一方の、新しいバージョンをデプロイし て、動作確認を行っている系統。切替後は主系にな る。 「Blueが主系、Greenが副系」という言い方をします。
  • 69. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 ロードバランサーのルーティング • ユーザーからのアクセスは主系に、動作確認 のためのアクセスは副系に振り分ける
  • 70. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 グローバル IPアドレス1 (主系用) グローバルIP アドレス2 (副系用) Blueサーバー ○ × Greenサーバー × ○
  • 71. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 グローバル IPアドレス1 (主系用) グローバルIP アドレス2 (副系用) Blueサーバー × ○ Greenサーバー ○ ×
  • 72. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 非同期処理の連携 アクセスが来た後、データ連携を行うまでの、サー バー間のトランザクションは、主系サーバー、副系 サーバー相互で連動して動くようにする Blueサーバーが主系の時、主系(Blueサーバー)が登 録したデータは、同じく主系(Blueサーバー)のデー タ連携サーバーが処理する
  • 73. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 ここが問題 ※非同期
  • 74. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 対処法 • BlueサーバーとGreenサーバーどちらが主系でどち らが副系かをデータベース上に保持し、参照する。 • O/Rマッパー(Hibernate)上の処理にinterceptorを 適用して、データベース上に投入するレコードが、 主系が投入したレコードなのか、副系で投入したレ コードなのか、区別がつくようにする
  • 75. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 Blue-Greenの切替 主系、副系の切り替え時は、処理途中で主系 サーバーがBlue(Green)サーバーから Green(Blue) サーバーに切り替わる場合がある ので、それに対応できるようにする。
  • 76. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 切り替え手順を見てみましょう 以下は、 Blueサーバー主系、Greenサーバー副系 から、 Greenサーバー主系、Blueサーバー副系 に切り替える場合の手順
  • 77. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 初期状態 GreenBlue
  • 78. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 図の見方 GreenBlue Blue 赤の線…主系 黒の線…副系 実線( ) …ユーザーのアクセス 破線( ) …動作確認のためのアクセス …プロセス起動 …プロセス停止
  • 79. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 両方主系にする(1/5) Blue Green
  • 80. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 Blueサーバーのデータ連携サーバーを 停止する(2/5) Blue Green
  • 81. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 ロードバランサーを切り替える(3/5) Blue Green
  • 82. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 Blueサーバーを副系にする(4/5) Green
  • 83. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 副系になったデータ連携サーバーを起動する(5/5) Blue Green
  • 84. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 ポイント 切替処理はCIサーバーからワンクリックで出来 るようにしている 切替処理に冪等性を持たせている
  • 85. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 切替の手順自体は、システムの構成に依存して いるので、汎用的にこの手順が使えるわけでは ないです。
  • 86. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 なぜこうなるか ロードバランサーやサーバーなど、複数の機器 の状態を手順を踏んで変更しているが、その操 作をアトミックにはできないため、両方のサー バーが一旦主系になるなど、手順を踏む数が多 くなっている。 このこと自体は、どこでも起き得ることです。
  • 87. #ccc_g11 Copyright 2016 Hiroyuki Onaka http://startupstockphotos.com/post/82514406502/we-create-here-in-the-making-folks-read-the-blog Blue-Green Deployment を支える技術
  • 88. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 自動化 切替時にロードバランサーやアプリケーション の切替に複雑な手順を踏んでいますが、Blue- Green Deploymentの導入前からリリースに関 する作業の自動化を地道に進めていたので、CI サーバーからワンクリックで切り替えられるよ うになっています。
  • 89. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 テスティング データ連携に関係する主系・副系の切り替えの ためのコード修正は、自動化されたユニットテ ストとCIなしでは実現できませんでした。
  • 90. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 テスティング(2) Blue-Green構築時のインフラ観点でのシステム テストでは、Gebによる自動化されたend to end のテストを最大限に活用しました。
  • 91. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 pull requestによるコードレビュー • インフラの担当エンジニアがプロダクション コードの修正をレビューする • 開発の担当エンジニアがデプロイスクリプト の修正をレビューする
  • 92. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 Blue-Green Deploymentを支える技術 • 自動化 • テスティング • バージョン管理
  • 93. #ccc_g11 Copyright 2016 Hiroyuki Onaka まとめ 「冗談じゃない、ベンダーは私達よ、他の誰でもない!私達が作って私達が運用する。 それ以外に技術屋の動きなんてありえない!」 - 夏見公司「なれる!SE3 失敗しない?提案活動」
  • 94. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 最終成果 • 日中でのサービス無停止リリースが実現 • サービス無停止リリースを実現したことにつ いて、お客様の企画部門で表彰される
  • 95. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 コードレビューの事例に代表されるように、開 発チームとインフラチームが実現すべきゴール を共有した上で、お互いの役割を発揮できたか らこそ、Blue-Green Deploymentを導入でき たと思います。
  • 96. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 私たち、DevOpsしています(ドヤッ)
  • 97. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 「素早くリリースする」のがDevOpsではない 「Opsの役割は、ビジネスを実現することであ る」 - John Allspaw, 「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」から
  • 98. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 誰がDevOpsするのか 私はどこのポジションなのか
  • 99. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 SlackをSIerに導入した話 小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来 http://blog.livedoor.jp/lalha/archives/50528045.html
  • 100. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 富士通がAdvent Calendarに参加することになった理由 富士通がAdvent Calendarに参加することになった理由 – blog http://tnaoto.hatenablog.com/entry/2016/12/02/114611
  • 101. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 • SIの現場でも技術の追求は出来ます • オワコンではないです • 僕たちの業界はもっとよくなれる
  • 102. #ccc_g11 Copyright 2016 Hiroyuki Onaka 日本のDevOpsはSIがリードする 青空白帆(CC BY 2.1 JP) http://photozou.jp/photo/show/254715/28171547
  • 103. #ccc_g11 Copyright 2016 Hiroyuki Onaka #ccc_g1 ありがとうございました! • 大中浩行(Onaka,Hiroyuki) • @setoazusa • グロースエクスパートナーズ株式会社 アーキテクチャソリューション部 テクニカルリード • http://blog.fieldnotes.jp/