서비스를 만들면서 피할 수 없는 주제 중 한가지가 바로 비동기 처리입니다. 무겁고 오래 걸리는 일에 대한 처리뿐 아니라, 주기적으로 수행해야 하는 일까지 대부분 서비스에 반드시 라고 할 만큼 겪게 되는 문제죠. Python을 쓰는 우리에게는 물론 싱싱하고 훌륭한 해법인 Celery가 있습니다. 요구되는 거의 모든 기능을 제공할 뿐만 아니라, 유연하게 설계되어 있고 관리툴 같은 부가 기능까지, 비동기에 관련된 모든 부분을 책임져주죠. 하지만 Celery에 이런 빛과 같은 아름다움만 존재하는 것은 아닙니다. 싱싱한 채소를 맛있게 먹기 위해서는 몇 가지 공부가 필요한 것처럼, 때로는 Celery의 의아스러운 점을 잘 다루고, 우리의 서비스에 맞게 이용하기 위해서는 몇 가지 알아야 할 점이 있습니다. 지난 1년여간 최대 1만 건/초의 요청을 Celery로 처리하면서 제가 얻은 경험을 나누고자 합니다.

1. Celery의 빛과 그림자
PYCON KOREA 2015
정민영
THE BEATPACKING COMPANY

2. 발표자
• 정민영
• 비트패킹컴퍼니 CTO
• PyconKR 2014/Deview 2014 ‘제약을 넘어: Gevent’
발표 (Deview 2014 Top 10)
• AWSKRUG Founder / AWS Community Hero

3. 이런 분들을 위해 준비했어요!
• 비동기 처리를 해야되긴 한다던데… 뭐가 뭔지 모르겠던 분!
• Celery가 뭔가 좋은거 같긴한데…써도 되나 의심스러우셨던
분들!
• Celery를 쓰고 있는데 뭔가 작동이 이상해서 고민이셨던 분
들!

4. Celery?

5. Distributed
Task
Queue

6. 혹은

7. (종합적인)비동기 처리기

8. 비동기 처리기?

9. 비동기 처리기는 왜 필요한걸까?
고갱님 어떤 서비스
진지하게 가입을 해볼까?
이메일, 이름, .. 좋아 가입!

10. 비동기 처리기는 왜 필요한걸까?
어떤 서비스
진지하게 가입을 해볼까?
이메일, 이름, .. 좋아 가입!
에.. 고객님 프로필 사진을
업로드하고.. 크기도 적당히
3개쯤 준비해두고..
고갱님

11. 비동기 처리기는 왜 필요한걸까?
어떤 서비스
진지하게 가입을 해볼까?
이메일, 이름, .. 좋아 가입!
에.. 고객님 프로필 사진을
업로드하고.. 크기도 적당히
3개쯤 준비해두고.. 요즘 유
행이니까 배경 블러도 만들
어 두고…
고갱님

12. 비동기 처리기는 왜 필요한걸까?
어떤 서비스
진지하게 가입을 해볼까?
이메일, 이름, .. 좋아 가입!
에.. 고객님 프로필 사진을
업로드하고.. 크기도 적당히
3개쯤 준비해두고.. 요즘 유
행이니까 배경 블러도 만들
어 두고… 아 친구도 찾아
드려야 하는데 까먹을뻔 했
네 데헷(*^^*)..
고갱님

13. 비동기 처리기는 왜 필요한걸까?
어떤 서비스
에.. 고객님 프로필 사진을
업로드하고.. 크기도 적당히
3개쯤 준비해두고.. 요즘 유
행이니까 배경 블러도 만들
어 두고… 아 친구도 찾아
드려야 하는데 까먹을뻔 했
네 데헷(*^^*).. 자 다했다
이제 이메일 보내드려야지!

14. 비동기 처리기는 왜 필요한걸까?
어떤 서비스
어…어.. 고..고갱님??

15. 비동기 처리기는 왜 필요한걸까?
• 비동기 처리기는 동기적으로 수행하지 않아도 되는 일들을 처
리해 주는 역활을 합니다.
• 즉 결과를 즉시 받을 필요 없거나, 지연하여 처리해야 되는 일
들을 보통 처리합니다.
• 물론 그것이 제대로 처리가 되지 않아도 된다는 이야기는 아
니기 때문에, 별도의 잘 만들어진 처리기가 필요해요!

16. 그런데 왜 꼭
여야 하나요?

17. 근데 왜 꼭 Celery여야 하죠?
• 완전 쉽게 연동할 수 있어요!
• (아마도) 당신이 상상할 수 있는 모든 기능을 제공해요!
• 일단 남들이 제일 많이 써요!

18. Celery… 너란 채소….

19. 완전 쉽게 연동할 수 있어요!
from

20. celery

21. import

22. Celery
app

23. =

24. Celery('hello',

37. broker='amqp://guest@localhost//')

38.
@app.task
def

39. add(a,

40. b):

44. return

45. a

46. +

47. b

48. 완전 쉽게 연동할 수 있어요!
from

49. tasks

50. import

51. add
add.delay(1,

52. 2)

54. 완전 쉽게 연동할 수 있어요!
from

55. tasks

56. import

57. add
r

58. =

59. add(1,

60. 2)
r.get(timeout=1)

62. 완전 쉽게 연동할 수 있어요!

63. (아마도) 당신이 상상할 수 있는 모든 기능

64. (아마도) 당신이 상상할 수 있는 모든 기능

65. (아마도) 당신이 상상할 수 있는 모든 기능
T.delay(arg,

66. kwarg=value)

67.
!
T.apply_async((arg,

68. ),

69. {'kwarg':

70. value})

71.
!
T.apply_async(countdown=10)

72.
!
T.apply_async(eta=now

73. +

74. timedelta(seconds=10))

75.
!
T.apply_async(countdown=60,

76. expires=120)

77.
!
T.apply_async(expires=now

78. +

79. timedelta(days=2))

81. (아마도) 당신이 상상할 수 있는 모든 기능
from celery import chain
# 2 + 2 + 4 + 8
res = chain(add.s(2, 2), add.s(4), add.s(8))()
res.get()
16

82. (아마도) 당신이 상상할 수 있는 모든 기능
from celery import chain
!
# 2 + 2 + 4 + 8
res = chain(add.s(2, 2), add.s(4), add.s(8))()
res.get()
16
!
(add.s(2, 2) | add.s(4) | add.s(8))().get()
16

83. (아마도) 당신이 상상할 수 있는 모든 기능
new_user_workflow = (create_user.s() | group(
import_contacts.s(),
send_welcome_email.s())
)
new_user_workflow.delay(username='artv',
first='Art',
last='Vandelay',
email='art@vandelay.com')

84. (아마도) 당신이 상상할 수 있는 모든 기능
from datetime import timedelta
!
CELERYBEAT_SCHEDULE = {
'add-every-30-seconds': {
'task': 'tasks.add',
'schedule': timedelta(seconds=30),
'args': (16, 16)
},
}
!
CELERY_TIMEZONE = 'UTC'

85. (아마도) 당신이 상상할 수 있는 모든 기능

86. (아마도) 당신이 상상할 수 있는 모든 기능

87. 뭐… 좋은건 알겠는데….

88. There ain't no such thing as a free lunch

89. There ain't no such thing as a free lunch

90. – kkung
비트 성장의 가장 첫번째 난관은 셀러ㄹ…

92. –고..고갱님
푸시가 새벽 2시에 왔습니다. 미ㅊ..거 아닙니까?

94. 잘 알고 써야 하는 Celery!
• 적은 규모에서, 간편하게 쓰기에는 더 없이 훌륭하지만…
• 의외로 조금만 규모가 커져도 신경써야 할 부분이 많아요!
• 특히 처음부터 고려하지 않으면 알 수 없는 이상작동처럼 느
껴질 수도 있으니 주의가 필요한 부분이 있어요!

95. Broker

97. 나..나쁜거?

98. 어떤 녀석이 일(Task)을
처리할지 중개(Broker)

99. Celery 구조
Web APP Broker
Worker
Worker
Worker

100. Celery는 무수히 많은
Broker를 지원 하지만..

102. AMQP 모사 일부 기능 제한

103. AMQP 모사 일부 기능 제한

104. 특히 AMQP중에서도..

106. RabbitMQ is the default broker so
it does not require any additional
dependencies or initial
configuration

107. 그래도 굳이 다른
Broker를 쓰시겠다면….

108. http://raksik.funshop.co.kr/goods/detail/27795

109. ack, visibility_timeout

110. ack
Broker Worker
Message
Ack
Consume

111. ack + visibility timeout
Broker Worker
Message
Message
Visibility Timeout

112. Redis/SQS에서의 visibility timeout
• visibility timeout내에 ack가 전달되지 않으면, task가 중
복 실행됩니다.
• eta, countdown 시간보다 visibility timeout이 커야해요.
• AWS SQS의 최대 시간 제한은 12시간!

113. 그 외의 고생길(!)
• Redis는 메모리가 부족한 상황에서 임의로 key가 삭제될 수
있어요!
• SQS는 API요청당 과금을 하고, Pub/Sub이 아닌 Polling
모델 이에요. 자주 땡길(!)수록 요금이 나와요.
• SQS를 Broker로 사용하면 Celery의 주요한 모니터링 기
능 대부분을 사용할 수 없어요.

114. 왜 고생을 사서 하는 거죠? ….

115. prefetch의 배신

116. prefetch의 배신(?)
• prefetch에 대한 일반적인 기대는….
• Task들을 그냥 미리 땡겨두는거죠. 심플하게. 다른 뜻 없이.
• 여기에 무슨 다른 오해의 소지가 있겠어…?

117. S S S L S S S S
S S S L
prefetch : 4
L S S S
queue size : 8
concurrency: 1

118. 이렇게 되는거 아냐?
라고 생각하셨다면…

120. 아니 진짜… 진짜… 이거 아냐…?

121. Prefetch is a term inherited
from AMQP that is often
misunderstood by users.

122. The prefetch limit is a limit for
the number of tasks (messages)
a worker can reserve for itself

123. S S S L S S S S
S S S L
prefetch : 4
L / / /
queue size : 8
S S S S
concurrency: 1

124. 오해받기 쉬운 그/그녀 prefetch….
• prefetch된 단위 전체의 작업을 소비해야(ack*) 다음
prefetch가 수행 됩니다.
• task가 비워지는 대로 다음 task를 broker에서 가져올꺼라
는 일반적인 기대와 차이가 있어요!(often
misunderstood)
• 물론 task payload의 크기가 적고, latency가 중요하다면
합리적인 결정이기도 합니다.

126. Prefork pool prefetch

127. P1PA P2
T1
T2
T3

128. -ofair

129. 그런데 무조건 쓸 수 있는건
아니고요….

130. 에헤이.. 방법이 있겠죠? 좀 나눕시다 에헤

132. Task를 한 큐에 담지 마세요!
• prefetch의 특성상 평균 수행 시간이 비슷한 것들이 같은
Queue에 있는 것이 성능상 훨씬 유리합니다.
• 또한 Task의 절대적인 수 자체도 중요한 요소에요.
• 처리의 중요도/시급도(Priority)에 따른 분류도 중요해요.
• 위와 같은 요소를 고려해서 Queue를 나눠 주세요

133. CELERY_ROUTES

134. =

135. {

140. 'feed.tasks.import_feed':

141. {

150. 'queue':

151. 'feeds'

156. }

157.
}

159. $ celery -A pykr worker -Q feeds

160. 정말 간단한데
성능에 큰 영향을 주는
또 다른 요소

161. 무시를 무시하지 마세요

162. 무시를 무시하지 마세요?

164. ignore_result

165. ignore_result
• Celery는 기본적으로 수행 결과(return)를 ‘저장’ 해야 작업
이 끝납니다.
• 하지만 대부분 Task내에서 직접 결과를 다른 곳에 저장하지,
`return` 자체를 쓰는 경우는 드물어요!
• 보통은 Task 연계를 하는 경우만 필요하답니다!
• 결과를 저장하는 비용이 적지 않기 때문에 이걸 끄기만 해도
무척 성능이 좋아져요!

166. 그래서 Celery를 쓰라는거야 말라는 거야…?

167. 잘 쓰면 됩니다!

169. 그래도 역시 Celery!
• 비록 여러 어려움을 설명하긴 했지만, 이는 꼭 잘못된 디자인
/구현 이라기 보다는 여러 제약속에서 특정 선택을 했을 뿐인
경우가 많아요!
• Celery 없이 문제를 해결하려다 보면 결국 바퀴를 다시 만들
게 되는 경우가 많아요!
• Celery는 요집도 조집도 우리집도 너희집도 많이 쓰기 때문
에 같이 어려운 문제를 같이 해결해 줄 사람이 많아요!
• 본래 ‘분산’ ‘비동기’ 이런 단어 들어가면 복잡도가 만배(…)

170. 감사합니다.

171. 절
찬
채
용
중
부
스
상
담
환
영