大規模eコマースシステムの コマースシステムの DevOpsを実現する

大規模e
大規模eコマースシステムの
DevOpsを実現する
DevOpsを実現するExalogic
を実現するExalogic
9 / April / 2015
仲宗根徹也
EC architecture group, Rakuten, Inc.
http://www.rakuten.co.jp/
アジェンダ
1. 自己紹介と会社概要
2. Exalogic導入背景と結果
3. Engineered SystemsとDevOps
4. まとめ
2
アジェンダ
1. 自己紹介と会社概要
2. Exalogic導入背景と結果
3. Engineered SystemsとDevOps
4. まとめ
3
自己紹介
Tetsuya Nakasone
@tets01
Technical Managing Officer
EC Architecture group
EC Technology Section
Rakuten Ichiba Development Department
Rakuten, Inc.
4
Global Expansion
●●●●●●
●●● ●
● ●● ●
●● ●
●●
●● ● ●
●●
●●
●●
●●
●
●
●
●
●
●
●●●●●●
Head Office
●●
●● ●
●●
●●●
●●●
●
eコマース
電子書籍
トラベル
その他サービス&ビジネス
●
●
●
楽天技術研究所
開発拠点
本社 / 地域本社
5
アジェンダ
1. 自己紹介と会社概要
2. Exalogic導入背景と結果
3. Engineered SystemとDevOps
4. まとめ
6
Exalogicとは？
Exalogicとは？
Oracle Engineered Systems
Specialized Product
for Middleware
- WebLogic
- Coherence
- Tuxedo
Total Solution
7
楽天市場は様々な要素で出来ている
Biz App
Biz App
Biz API
Biz API
Biz App
Biz App
Biz API
8
大量のWebLogicドメインとインスタンス
ドメインとインスタンス
大量の
店舗ページ
商品ページ
オークション
店舗編集
商品登録
買い物かご
共同購入
プレゼント
受注処理
各種API
ケータイ
・・・
・・・
・・・
9
Exalogicで解決できるのでは？
で解決できるのでは？
大量のWLSインスタンスの集約
10
6
00:00
01:00
02:00
03:00
04:00
05:00
06:00
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
サービスごとに異なるピークタイム
System
Load
5
4
3
2
A Service
B Service
1
0
Time
11
Exalogicで解決できるのでは？
で解決できるのでは？
大量のWLSインスタンスの集約
リソースの有効活用
12
現状の開発（保守）・運用
RD
Coding
Test
Prepare
Deployment
Maintenance
Monitoring
Analysis
Enhancement
Improvement
Service
Operation
Trouble
shoot
各チーム単位で全て実施
13
サービス提供者は維持優先
RD
Coding
Test
Prepare
Deployment
Maintenance
Monitoring
Analysis
Enhancement
Improvement
Service
Operation
Trouble
shoot
各チーム単位で全て実施
運用に時間を割かれる
技術的負債の解消は後回し
14
Exalogicで解決できるのでは？
で解決できるのでは？
大量のWLSインスタンスの集約
リソースの有効活用
運用の集約化とDevOpsの実現
15
最初に掲げたビジョン
現状
RD
Coding
Test
Prepare
Deployment
Maintenance
Monitoring
Analysis
Enhancement
Improvement
Service
Operation
Trouble
shoot
各チーム単位で全て実施
After Exalogic
Exalogicチームによって提供されるサービス
各チームと一緒に作業
RD
Coding
Test
Prepare
Deployment
Maintenance
Monitoring
Analysis
Enhancement
Service
Operation
Trouble
shoot
赤を減らしていく
各チームは開発に専念
できるようにする
改善のためのFBをしつつ
ガバナンスを効かせていく。
標準化・自動化
16
最初に掲げたビジョン
４人で実現する
17
結果
WebLogic インスタンス数削減
１
〜
3
１
7
18
結果
WLSドメイン構築にかかる時間
ドメイン構築にかかる時間
1~2
Weeks
5
Min
19
結果
サービスリリースに掛かる時間
Hours
※ローリングアップデートの場合
Secs
20
Why？
？
21
Exalogic導入するだけでは
導入するだけでは
インスタンス集約
パフォーマンス向上
のみ。
22
Exalogicは
は
ミドルウェアエンジニアが
コントロール可能な
インフラ
でもある。
23
Engineered Systemsをフル活用する
をフル活用する
ZFSSAのパワーと潤沢なリソース
• 単一ディレクトリ上に構成されたWLSドメイン。
• 構成管理工数削減。
• インスタンス増減。
• ２面化構成。
24
Engineered Systemsをフル活用する
をフル活用する
フローティングIP
• WLSインスタンスの構成管理をシンプルに。
• ListenAddressとListenPortの固定化。
• 稼働するマシンを移動可能。
25
Engineered Systemsをフル活用する
をフル活用する
強力なソフトウェアバランサー
• Oracle Traffic Director。（OTD）
• 2面化構成の安全な切り替え。
• 無停止サービスリリースを実現可能。
26
Engineered Systemsをフル活用する
をフル活用する
インフラと組み合わせて考える。
構成管理を楽にする。
ツール化・自動化・効率化。
時間を作る。
FeedBackして改善に取り組む。
27
アジェンダ
1. 自己紹介と会社概要
2. Exalogic導入背景と結果
3. Engineered SystemsとDevOps
4. まとめ
28
構成概要
Exalogic Half Rack x 2
•
•
•
•
X3-2
マルチラック配線
EECS 2.0.3.0.4
仮想化無し
Middleware
• WebLogic Server 10.3.6.0.6 / 12.1.3.0.0
• Coherence 12.1.2.0.0
• Oracle Traffic Director 11.1.1.7
29
各CNの使い方
の使い方
exalogic2
- WLS インスタンス
- Coherence ノード
- OTD専用
EXALOGIC
EXALOGIC
exalogic1
- WLS 管理サーバ
- OTDバックアップ
30
Engineered Systemsをフル活用する
をフル活用する
ZFSSAのパワーと潤沢なリソース
• 単一ディレクトリ上に構成されたWLSドメイン。
• 構成管理工数削減。
• インスタンス増減。
• ２面化構成。
31
共有リソース
JDK
【 ZFS】
】
Middleware製品
製品
mount
mount
Coherence クラスタ
WebLogic ドメイン
設定ファイル
運用ツール
ログ専用
32
単一のWLS
単一のWLSドメインディレクトリ
WLSドメインディレクトリ
/xx/yy/domainA/
|-- bin/
|-- config/
|-- lib/
|-- security/
|-- startWebLogic.sh
|-- stopWebLogic.sh
|-- log/
| |-- instance01.log
| |-- instance02.log
| `-- instance03.log
`-- servers/
|-- AdminServer/
|-- instance01/
|-- instance02/
`-- instance03/
管理サーバ・管理対象サーバとして
動作可能。
Log4j等を使った独自のログも
インスタンス間で衝突しない。
<appender name=”log" class="org.apache.log4j.DailyRol..”>
<param name="File" value="log/${weblogic.Name}.log" />
..
33
単一のWLS
単一のWLSドメインディレクトリ
WLSドメインディレクトリ
/xx/yy/domainA/
|-- bin/
|-- config/
|-- lib/
|-- security/
|-- startWebLogic.sh
|-- stopWebLogic.sh
|-- log/
| |-- instance01.log
| |-- instance02.log
| `-- instance03.log
`-- servers/
|-- AdminServer/
|-- instance01/
|-- instance02/
`-- instance03/
管理サーバ・管理対象サーバとして
動作可能。
- pack.sh/unpack.sh （もしくはコピー）による
インスタンス専用ディレクトリをセットアップしなくてよい。
-
Log4j等を使った独自ログも
インスタンス間で衝突しない。
適当なCNにIPを割り当て、起動するだけでインスタンス
が立ち上がる。
<appender name=”log" class="org.apache.log4j.DailyRol..”>
<param name="File" value="log/${weblogic.Name}.log" />
..
34
Engineered Systemsをフル活用する
をフル活用する
フローティングIP
• WLSインスタンスの構成管理をシンプルに。
• ListenAddressとListenPortの固定化。
• 稼働するマシンを移動可能。
35
フローティングIP
フローティング
IP移動・アサイン
CNが持つIP一覧
IPからCNを逆引き
36
構成ルールの単純化
1インスタンス 1 IP 固定
管理サーバ
10.10.${ドメイン番号}.100
管理対象サーバ
10.10.${ドメイン番号}.${連番} : 7003
: 7001
37
フローティングIP
フローティング
WebLogic Domain
Instance 01 (10.10.1.1)
Instance 02 (10.10.1.2)
Instance 03 (10.10.1.3)
Instance 04 (10.10.1.4)
Instance 01 (10.10.1.1)
Failed
Instance 03 (10.10.1.3)
Instance 04 (10.10.1.4)
Instance 02 (10.10.1.2)
CNを移動
を移動
停止
IP移動
移動
起動
38
フローティングIP
フローティング
WebLogic Domain
- ListenAddressとListenPortを固定したまま
Instance 01 (10.10.1.1)
Instance 01 (10.10.1.1)
別のCNに移動して起動可能。
Instance
02 (10.10.1.2)
Instance 03 (10.10.1.3)
Instance 03 (10.10.1.3)
Instance
04 (10.10.1.4)
Instance 04 (10.10.1.4)
- CNの障害、メンテナンス、負荷状況に応じて
配置を変えることが可能。Instance 02 (10.10.1.2)
Failed
CNを移動
を移動
- ネットワークエンジニアじゃなくても実施可能。
停止
IP移動
移動
起動
39
Engineered Systemsをフル活用する
をフル活用する
強力なソフトウェアバランサー
• Oracle Traffic Director。（OTD）
• 2面化構成の安全な切り替え。
• 無停止サービスリリースを実現可能。
40
OTD(Oracle Traffic Director)
L７ ソフトウェアバランサー
• 振り先を複数のサーバプールとして管理。
• 複数のリスナーを付けられる。
• 条件に応じたルーティングを設定。
41
“Blue Green Deployment” とは?
とは
http://martinfowler.com/bliki/BlueGreenDeployment.html
42
A面
面/B面のアイデア
面のアイデア
同じ構成のWLSドメインA/BとOTDで無停止リリースできるのでは？
OTD
OTD
OTD
Ver 1.0
Test
Ver 1.1
Test
Ver 2.0
Ver 1.1
Ver 2.0
Test
Ver 2.1
A
B
A
B
A
B
43
BGD with OTD
本番リクエスト
“default-route”
は常に本番
OTD instance
OTD virtual server
OTD http-listener
OTD default-route
“fooA”のプール
OTD origin-server-pool
domain “fooA” instance
domain “fooB” instance
fooA
fooA01
fooA02
fooA03
44
BGD with OTD
本番リクエスト
fooA
fooA01
fooB01
OTD instance
OTD virtual server
OTD http-listener
OTD default-route
OTD test-route
OTD origin-server-pool
domain “fooA” instance
domain “fooB” instance
fooB
fooA02
fooB02
fooA03
fooB03
fooAとfooBの組み合わせ
45
BGD with OTD
本番リクエスト
“test-route”定義
fooA
fooA01
fooB01
“test-route”と
結びついた
“fooB”のプール
fooB
fooA02
fooB02
OTD instance
OTD virtual server
OTD http-listener
OTD default-route
OTD test-route
OTD origin-server-pool
domain “fooA” instance
domain “fooB” instance
fooA03
fooB03
46
BGD with OTD
本番リクエスト
fooA
fooA01
fooB01
- “fooA”と“fooB” は互いに独立したドメイン。
OTD instance
- どちらも同じアプリケーションが動く。
OTD virtual server
- configurationは基本的に同じ。
OTD http-listener
（“ListenAddress”と“Machine”は異なる）
OTD default-route
OTD test-route
- “test-route” が向いている面は
OTD origin-server-pool
次のリリース環境。domain “fooA” instance
domain “fooB” instance
fooB
fooA02
fooB02
fooA03
fooB03
47
BGD with OTD
新バージョンの“foo.war” を
fooBにデプロイ
OTD instance
OTD virtual server
OTD http-listener
OTD default-route
OTD test-route
OTD origin-server-pool
domain “fooA” instance
domain “fooB” instance
”fooB” AdminServer
本番リクエスト
fooA
fooA01
fooB01
fooB
fooA02
fooB02
fooA03
fooB03
48
BGD with OTD
内部から動作確認
本番リクエスト
fooA
fooA01
fooB01
- ”test-route”を介して新バージョンの
テストが可能。OTD instance
OTD virtual server
OTD http-listener
OTD default-route
OTD test-route
OTD origin-server-pool
domain “fooA” instance
domain “fooB” instance
fooB
fooA02
fooB02
fooA03
fooB03
稼働面 : fooA
テスト面 : fooB
49
BGD with OTD
本番リクエスト
切替！
fooA
fooA01
fooB01
fooB
fooA02
fooB02
OTD instance
OTD virtual server
OTD http-listener
OTD default-route
OTD test-route
OTD origin-server-pool
domain “fooA” instance
domain “fooB” instance
fooA03
fooB03
50
BGD with OTD
- “tadm”コマンドや管理コンソールで切替。
本番リクエスト
OTD instance
OTD virtual server
OTD http-listener
- A面は次のリリース環境。
OTD default-route
OTD test-route
- 切り替え後に新バージョンの不具合が
OTD origin-server-pool
見つかったら戻せる。
domain “fooA” instance
domain “fooB” instance
- シームレス。
fooA
fooA01
fooB01
fooB
fooA02
fooB02
fooA03
fooB03
稼働面 : fooB
テスト面 : fooA
51
BGD with OTD
- セッションを使うアプリケーションの場合、
coherence*web でA/Bを構成する。
- 全てのセッション情報はCoherenceの中。
local-storage=false
fooA01
fooB01
fooA02
- ただし、セッションで管理するデータの互換性、
デフォルト値を意識した開発が前提。
fooB02
fooA03
fooB03
HttpSession session = req.getSession(true);
Coherence Cluster
local-storage=true
domain “fooA” instance
domain “fooB” instance
Coherence node
52
A/B面に
面によるメリット
面によるメリット
リリースコスト削減
• ローリングアップデート作業不要。
• 切替は２０秒以下。
• 前バージョンへの戻しも一瞬。
サービス品質向上につながる
• ステージング（裏面）と本番（表面）の環境差異がない。
• テストしたものがそのまま出せる。
53
ツール化
構築
ツール
アプリケーション名
アプリケーション番号
54
ツール化
アプリケーション名
アプリケーション番号
構築
ツール
WebLogicテンプレート
構成ルール
fooA01
fooB01
管理サーバ
A面：10.10.${アプリ番号}.100
B面：10.10.${アプリ番号+100}.100
管理対象
サーバ
A面：10.10.${アプリ番号}.${連番}
: 7003
B面：10.10.${アプリ番号+100}.${連番} : 7003
: 7001
: 7001
55
ツール化
56
A面
面B面切替
面切替
only by pushing a button
57
稼働面確認
58
時間を作って
Exalogicチームによって提供されるサービス
各チームと一緒に作業
RD
Coding
Test
Prepare
Deployment
Maintenance
Monitoring
Analysis
Enhancement
Service
Operation
Trouble
shoot
赤を減らしていく
各チームは開発に専念
できるようにする
改善のためのFBをしつつ
ガバナンスを効かせていく。
標準化・自動化
改善に取り組む。
59
その他・モニタリング等
リアルタイムプロファイリング
（サードパーティ製ツール）
スマートなエラー検知とアラート
（自社開発）
60
FBの例
の例
「HttpClientの閉じ方が悪くてTIME_WAIT溜まってる」
「〜のログを出したらどうか？」
「〜が無駄にメモリ食ってるから、こう変更しない？」
61
ガバナンスについて
「これ作ったから運用頼む」
「運用に合わせた開発をしよう」
62
アジェンダ
1. 自己紹介と会社概要
2. Exalogic導入背景と結果
3. Engineered SystemsとDevOps
4. まとめ
63
まとめ
exalogic1
exalogic2
共有ディスク上に１アプリ２ドメイン
(domainA / domainB)
...
OTD
EXALOGIC
EXALOGIC
全てのインスタンスは移動可能
...
OTD
無停止リリース
B
A
WLS 管理対象サーバ
WLS 管理サーバ
64
まとめ
exalogic1
exalogic2
共有ディスク上に１アプリ２ドメイン
(domainA / domainB)
...
OTD
EXALOGIC
EXALOGIC
全てのインスタンスは移動可能
...
OTD
無停止リリース
B
A
WLS 管理対象サーバ
WLS 管理サーバ
65
まとめ
exalogic1
exalogic2
共有ディスク上に１アプリ２ドメイン
(domainA / domainB)
...
OTD
EXALOGIC
EXALOGIC
全てのインスタンスは移動可能
...
OTD
無停止リリース
B
A
WLS 管理対象サーバ
WLS 管理サーバ
66
まとめ
exalogic1
exalogic2
共有ディスク上に１アプリ２ドメイン
(domainA / domainB)
...
OTD
EXALOGIC
EXALOGIC
全てのインスタンスは移動可能
...
OTD
無停止リリース
B
A
WLS 管理対象サーバ
WLS 管理サーバ
67
まとめ
exalogic1
exalogic2
共有ディスク上に１アプリ２ドメイン
(domainA / domainB)
...
OTD
EXALOGIC
EXALOGIC
全てのインスタンスは移動可能
...
OTD
無停止リリース
B
A
WLS 管理対象サーバ
WLS 管理サーバ
68
まとめ
パフォーマンス改善、集約化はあたりまえ。
Engineered Systemsを前提とした運用でコスト削減。
開発と運用が協力できる体制を作れる。
69
Appendix – domain / address / port rules
WLS
Domain
Rules
Example
-
Always create 2 domains / 1 application,
call them domainA / domainB.
Call pair of domainA+domainB
“Virtual Domain”.
“domainA” and “domainB” have
same App / same configurations.
( except listen IP , name of managed ins.)
Virtual Domain has sequential ID number.
Listen IP address template.
A: 10.10.(ID).100
B: 10.10.(ID+100).100
Every AdminServer port is always :7001.
Virtual Domain Name: foo
domainA: fooA
domainB: fooB
Application: foo.war
Name = domain + %02d sequential No.
Listen IP address template.
A: 10.10.(ID).(seq)
B: 10.10.(ID+100).(seq)
Every instance port is always :7003.
Instance name:
-
-
WLS Managed
Instances
-
-
ID: 3
AdminServer:
-
-
fooA 10.10. 3.100:7001
fooB 10.10.103.100:7001
fooA: fooA01, fooA02, R
fooB: fooB01, fooB02, R
Listen Address:
-
fooA01: 10.10. 3.1:7003
fooA02: 10.10. 3.2:7003 R
fooB01: 10.10.103.1:7003 R
70
Appendix – domain / address / port rules
OTD
Virtual Server
Rules
Example
-
Virtual Server Name: foo
Listener port:
-
Virtual Server Name = “Virtual Domain”
Listener port rule
default-route: 8000 + ID
test-route: 9000 + ID
Name rule
“origin server pool” = “wls domain”
-
origin-server-pool
-
-
default-route can indicate domainA or domainB.
Keep test-route indicating converse side of default-route.
default-route: 8003
test-route: 9003
fooA : 10.10.3.1:7003,
10.10.3.2:7003, ...
fooB : 10.10.103.1:7003,
10.10.103.2:7003, R
Routing:
default-route: fooA
test-route: fooB
(or)
default-route: fooB
test-route: fooA
71
Appendix – domain / address / port rules
http://failovergroup-address:8003 http://failovergroup-address:8004
http://failovergroup-address:9003 http://failovergroup-address:9004
:8003 :9003
:8004
:9004
OTD instance
OTD virtual server
virtual-server: foo
virtual-server: bar
fooA
foo
10.10.3.1:7003
10.10.3.2:7003
10.10.3.3:7003
fooB
10.10.103.1:7003
10.10.103.2:7003
10.10.103.3:7003
barA
10.10.4.1:7003
barB
10.10.104.1:7003
OTD http-listener
OTD default-route
OTD test-route
OTD origin-server-pool
domain “fooA” instance
domain “fooB” instance
domain “barA” instance
domain “barB” instance
72
Thank you for listening!
73