Rubykaigi2007 presentation

1. RubyKaigi 2007
AP4R
Kiwamu Kato & Shun’ichi Shinohara
Future Architect, Inc.
1

2. • Introduction
• Demo
• Real world examples
• Technical topics
2

3. Introduction
3

4. Self Introduction
4

5. Kiwamu Kato
• Majored in Civil Engineering
• Has Enhanced and maintained
messaging middleware in company
5

6. Kiwamu Kato
• Started Ruby since last year
• Leader of the AP4R team
• http://d.hatena.ne.jp/kiwamu/
6

7. shino
• Programmer, I love coding !
• The language of the year is C or Haskell
7

8. shino
• Last year, made a debut to
the OSS world
• http://d.hatena.ne.jp/ita-wasa/
8

9. What is AP4R ?
9

10. Lightweight
Messaging
10

11. What is AP4R ?
• Asynchronous Processing for Ruby
• Loose coupling by messaging
11

12. What can we do w/ AP4R ?
• Quicker response to users
• Load distribution
12

13. Press release 2006/09/05
http://itpro.nikkeibp.co.jp/article/NEWS/20060905/247218/
13

14. Key points are ..
14

15. Lightweight
and
Robust
15

16. When is it useful ?
16

17. Quicker response
to users
17

18. If NO speedy response is needed,
execute it later

19. Before
Client Server
A B C D ...
19

20. After
Client Server Messaging Server
A B
20

21. After
Client Server Messaging Server
A B C D ...
21

22. Useful cases
• Logging
• Sending mail
• Creating heavy summary data
• Collaboration with other systems
22

23. Moreover,
load distribution
23

24. Easy to scale out
Client Server Messaging Server
24

25. Easy to scale out
Client Server Messaging Servers
25

26. Only good things ?
26

27. Sounds easy ?
27

28. (Maybe) No
28

29. If message deliveries
are NOT guaranteed,...
29

30. it may lead to
message lost and
message duplication
30

31. In other words...
31

32. •You can’t receive the
goods despite payment !
• Double withdrawals !
32

33. Messages should be
delivered in a reliable way,
33

34. No matter what happens
• Database trouble
• Network trouble
• Server down
• Busy and timeout
• ... etc
34

35. Lightweight
and
Robust
35

36. In Future Architect ...
36

37. We use messaging a lot
• Developed own messaging library
• Named “RtFA”
37

38. We use messaging a lot
• Pure Java
• Its own protocol, API (≠ JMS)
• Time-proven on various systems
38

39. One of illustrative cases
Mission critical system
in transportation business
http://japan.internet.com/linuxtoday/20061228/5.html
39

40. PJ summary
• Over 100 million package data per day
• Load distribution and parallel processing
on 8 nodes of Oracle 10g RAC
40

41. PJ summary
• Approx 100 servers
• Used “RtFA”, an in-house
middleware
41

42. Messaging is important

43. 43

44. Lightweight
Messaging
44

45. http://www.pragmaticprogrammer.com/titles/fr_j2r/
http://www.oreilly.co.jp/books/9784873113203/
45

46. From RtFA to AP4R
• Based on implementation/experiences with Java,
kept good parts, improved bad parts
• Focus on ease of use API, configuration
46

47. Lightweight
and
Robust
47

48. Demo
48

49. Outline
• Shopping store application
• Order and payment
49

50. Shopping store app.
Client Rails
Order
.
Payment
50

51. Loose coupling
AP4R
Client Rails Rails × 3
Order
51

52. Loose coupling
AP4R
Client Rails Rails × 3
Payment
Order
52

53. Loose coupling
AP4R
Client Rails Rails × 3
Payment
Order Sleep 1
53

54. Outline
• Use mongrel cluster
• Stress by ab
• Monitor queue retaining status
54

55. Real world
examples
55

56. Two examples
• Work With Rails
• Our internal project
56

57. Working With Rails
http://workingwithrails.com/
57

58. WWR
• is who’s who for Rails developers
• listed 7,000 people
from 104 countries
58

59. 59

60. WWR
• aggregates feeds from user’s blog
• has scaling problem in fetching
them slow/stale
60

61. WWR solution
• Queue Feeds
• Fetch async’ly
quot;Getting Distributed with Ruby on Railsquot;
slide #44 (from slideshare)
61

62. WWR solution
• Able to scale
• Flexible to feed types
62

63. Internal project
63

64. Briefing
• Work sheet management app.
newly-building in Ruby
• Labor cost accounting app.
existing in Java
64

65. Requirements
• Quick and rich UI
• Replicate data between Java and
Ruby
65

66. With AP4R
• Separate loads from UI
• Invoke Java from Ruby async’ly
66

67. Separate loads from UI
Client Server Messaging Server
67

68. Separate loads from UI
Client Server Messaging Server
67

69. Separate loads from UI
Client Server Messaging Server
67

70. Separate loads from UI
Client Server Messaging Server
Create summary data,
Send mails, etc.
68

71. Async’ly invoke Java
Client Server Messaging Server
69

72. Async’ly invoke Java
Client Server Messaging Server
69

73. Async’ly invoke Java
Client Server Messaging Server
data replication, etc.
69

74. Async’ly invoke Java
Client Server Messaging Server
data replication, etc.
69

75. Utilize Async! when
• Needless proc. for responce data
• Disjoined transactions are allowable
• External calls (often slow, unstable)
70

76. Technical topics
71

77. Two topics here
• API to put messages
and process flow
• Stored and Forward
72

78. API to put messages
and process flow
73

79. ap4r.async_to({specify next},
{request data}
[,{more opts}])
There’s also block style
c.f. RDoc: http://ap4r.rubyforge.org/doc/
74

80. Class ShopController < ApplicationController
def order # synchronous side
...
ap4r.async_to({:action => ‘payment’},
{:id => 1})
redirect_to ...
end
def payment # asynchronous side
id = params[:id]
...
render :text => “true”
end
end
75

81. Process flow
76

82. User Apache Rails AP4R
77

83. User Apache Rails AP4R
order
message put
78

84. User Apache Rails AP4R
dispatch
79

85. User Apache Rails AP4R
payment
80

86. Able to separate
sync/async servers
81

87. User Apache Rails AP4R
82

88. Architecture
AP4R
HTTP
AP4R DRB druby DRB
reliable-msg
SOAP
XML
-RPC
AP4R MySQL
mongrel
HTTP
83

89. Thanks to
DRb
4%
10%
reliable-msg
20%
mongrel
66%
rails

90. Stored And Forward
85

91. Stored ?
Forward ?
86

92. at-least-once
between Producer and Channel
87

93. Enterprise Integration Patterns:
Designing, Building, and
Deploying Messaging Solutions
by Gregor Hohpe,Bobby Woolf
Guaranteed Delivery [122]
88

94. Typical flow
to create async. messages
89

95. start
end
90

96. start
CRUD
end
90

97. start
CRUD
commit
end
90

98. start
CRUD
commit
message put / commit
end
90

99. start
CRUD
commit
message put / commit
end
data
90

100. start
CRUD
commit
message put / commit
end
data messages
90

101. Ensure (some)
Atomicness
of
updating database and
message creation
91

102. On updating database
• Error occurs,
• Any following messages
must NOT be queued
92

103. On updating database
• Everything succeeded,
• All following messages
must be queued
93

104. ☺
Relief
94

105. Lightweight
and
Robust
95

106. Ap4r::Client#transaction
Class ShopController < ApplicationController
def order # synchronous side
ap4r.transaction do
... # CRUD on database
ap4r.async_to ...
end
redirect_to ...
end
end
96

107. Process flow changes
in queueing sequence
97

108. Behind ap4r.transaction
ap4r.transaction do
... # CRUD on database
ap4r.async_to(...)
end
98

109. Behind ap4r.transaction
ap4r.transaction do
... # CRUD on database
Insert into SAF table
ap4r.async_to(...)
end
98

110. Behind ap4r.transaction
ap4r.transaction do
... # CRUD on database
Insert into SAF table
ap4r.async_to(...)
end Commit database
98

111. Behind ap4r.transaction
ap4r.transaction do
... # CRUD on database
Insert into SAF table
ap4r.async_to(...)
end Commit database
Queue messages
98

112. Behind ap4r.transaction
ap4r.transaction do
... # CRUD on database
Insert into SAF table
ap4r.async_to(...)
Store
end Commit database
Queue messages
98

113. Behind ap4r.transaction
ap4r.transaction do
... # CRUD on database
Insert into SAF table
ap4r.async_to(...)
Store
end Commit database
Queue messages
Forward
98

114. Sequence in detail
Without SAF
99

115. start
CRUD
commit
message put / commit
end
data messages
100

116. start
CRUD
commit
message put / commit
end
data messages
100

117. start
CRUD
commit
message put / commit
end
data messages
101

118. start
CRUD
commit
message put / commit
end
data messages
101

119. start
CRUD
commit
message put / commit
☠
end
data messages
101

120. start
CRUD
commit
message put / commit
☠
end
data messages
101

121. start
CRUD
commit
message put / commit
☠
end
data messages
101

122. start
CRUD
commit
counterchange
message put / commit
end
data messages
102

123. start
CRUD
message put / commit
counterchange
commit
end
data messages
103

124. start
CRUD
message put / commit
commit
end
data messages
104

125. start
CRUD
message put / commit
commit
end
data messages
104

126. start
CRUD
message put / commit
commit
end
data messages
105

127. start
CRUD
message put / commit
commit
end
data messages
105

128. start
CRUD
message put / commit
commit
☠
end
data messages
105

129. start
CRUD
message put / commit
commit
☠
end
data messages
105

130. start
CRUD
message put / commit
commit
☠
end
data messages
105

131. Better Safe than Sorry
• Database trouble
• Network trouble
• Server down
• busy and timeout
• ... etc
106

132. ☺
Embrace every exceptions
☠
107

133. Sequence in detail
With SAF
108

134. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
109

135. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
110

136. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
110

137. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
111

138. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
111

139. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
111

140. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
111

141. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
111

142. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
111

143. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
112

144. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
112

145. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
113

146. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
113

147. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
messages
113

148. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
messages
113

149. CRUD
start
SAF create
commit
message put / commit
Recoverable
SAF update
☺
end
data messages
messages
113

150. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
messages
113

151. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
messages
113

152. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
114

153. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
114

154. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
115

155. CRUD
start
SAF create
commit
message put / commit
SAF update
end
data messages
messages
115

156. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
messages
115

157. CRUD
start
SAF create
commit
message put / commit
Duplicated
SAF update
☺
end
data messages
messages
115

158. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
messages
115

159. CRUD
start
SAF create
commit
message put / commit
SAF update
☺
end
data messages
messages
115

160. Ensure (some)
Atomicness
of data and messages
116

161. at-least-once
between Producer and Channel
117

162. Summary
118

163. • Messaging with simple API,
simple configuration.
• Seamless collaboration with
Rails
119

164. • Automatic invocation of
async proc.
• Guaranteed delivery by SAF
120

165. Lightweight
and
Robust
121

166. Future Plans
122

167. Smooth operation ver.0.3.x
☑ Daemonize
☑ URL-rewrite filter
□ DLQ / SAF recovery
□ Protocols: Stomp, HTTP
123

168. Monitoring ver.0.4.x
□ Coordinate with Cacti,
Nagios, etc.
□ Many AP4R processes
□ Interactive management tool
124

169. Step to large scale ver.0.5.x
□ Dynamic configuration
□ Automatic recovery
□ Long running
125

170. Others
□ Security
□ Application testing support
□ Blocking queues
126

171. AP4R@RubyForge
• wiki: http://ap4r.rubyforge.org/wiki/wiki.pl?HomePage
• source: svn co svn://rubyforge.org/var/svn/ap4r
Your patches are welcome! Thank you.
127

172. • Future Architect logo belong to Future Architect, Inc.
Japan. All rights reserved.
• Rails logo are trademarks of David Heinemeier
Hansson. All rights reserved.
• The Ruby logo is copyright c 2006, Yukihiro
Matsumoto. It is released under the terms of the
Creative Commons Attribution-ShareAlike 2.5 License.
128