teratail
回答率
85.47%
質問するログイン新規登録
トップに関する質問nodeでのCPUバウンドな処理、分散処理への考え方について（child_processを使う？clusterを使う？）

編集履歴

質問編集履歴

2

コードの修正

2016/04/11 15:43

投稿

bleurouge
bleurouge

スコア161

test CHANGED
File without changes
test CHANGED
@@ -126,7 +126,7 @@
126
126
 
127
127
  heavyDataKeyArr.forEach(function(redisKey) {
128
128
 
129
- redisKey.get(redisKey, function(err, heavyData){
129
+ redis-client.get(redisKey, function(err, heavyData){
130
130
 
131
131
  // redisに保存されている redisKey:heavyData に対する計算
132
132
 

1

補足情報を追記

2016/04/11 15:43

投稿

bleurouge
bleurouge

スコア161

test CHANGED
File without changes
test CHANGED
@@ -1,72 +1,244 @@
1
- clusterモジュールを用いて特定の計算処理のみ子プロセスで処理を行っていましたが、結局のところ、clusterを用いた方法が効率的なのか分からなくなっています。定期的に発生する頻度の高いCPUバウンドな処理はchild_processのpool系モジュールを使った子プロセスで分散処理が良いのでは？？とも思います。
2
-
3
-
4
-
5
- nodeでの分散処理の手法について、以下の考え方で妥当なのか、向き不向きについて知見がありましたら、ご意見いただければ幸いです。
1
+ clusterモジュールを用いて特定の重い計算処理のみ子プロセスで処理を行っていましたが、結局のところ、clusterを用いた方法が手法として効率的なのか分からなくなってきました。定期的に発生する頻度の高いCPUバウンドな処理はchild_processのpool系モジュールを使った子プロセスで分散処理が効率的ではないかと感じています。nodeでの分散処理の手法について、以下の考え方で妥当なのか、向き不向きについて知見がありましたら、ご意見いただければ幸いです。
2
+
3
+
4
+
5
+ ▼当初clusterを用いて分散処理を行った手法
6
+
7
+ ```javascript
8
+
9
+ /////////////////////
10
+
11
+ // master.js
12
+
13
+ ////////////////////
14
+
15
+ var cluster = require('cluster');
16
+
17
+ var numCPUs = require('os').cpus().length;
18
+
19
+ var HeavyFunc = require('./heavy-func');
20
+
21
+
22
+
23
+ ：
24
+
25
+ if(cluster.isWorker) {
26
+
27
+ // master 側から処理対象データを受け取る箇所
28
+
29
+ process.on('message', function(msg) {
30
+
31
+ if(msg.signal === 'heavy-data') {
32
+
33
+ HeavyFunc(msg.data)
34
+
35
+ .then(function() {
36
+
37
+ // cluster で終了した処理を master 側に通知する箇所
38
+
39
+ process.send({ workerId: msg.workerId, status: 'complete' });
40
+
41
+ })
42
+
43
+ .catch(function(e) {
44
+
45
+ console.log(e);
46
+
47
+ });
48
+
49
+ }
50
+
51
+ });
52
+
53
+ return;
54
+
55
+ }
56
+
57
+ if(cluster.isMaster) {
58
+
59
+ ：
60
+
61
+ // master 側から処理対象のデータを cluster に引き渡す箇所
62
+
63
+ Object.keys(cluster.workers).forEach(function(id) {
64
+
65
+ cluster.workers[id].send(
66
+
67
+ { workerId: id, signal: 'heavy-data', data: heavyDataKeyArr }
68
+
69
+ );
70
+
71
+ });
72
+
73
+ ：
74
+
75
+ // cluster で終了した処理通知を master 側で受ける箇所
76
+
77
+ var returnWorkersId = [];
78
+
79
+ Object.keys(cluster.workers).forEach(function(id) {
80
+
81
+ cluster.workers[id].on('message', function(msg){
82
+
83
+ if(msg.status === 'complete') {
84
+
85
+ returnWorkersId.push(msg.workerId);
86
+
87
+ if(returnWorkersId.length === numCPUs) {
88
+
89
+ console.log('worker processes complete the computing');
90
+
91
+ returnWorkersId = [];
92
+
93
+ }
94
+
95
+ cluster.workers[msg.workerId].removeAllListeners('message');
96
+
97
+ }
98
+
99
+ return;
100
+
101
+ });
102
+
103
+ });
104
+
105
+ ：
106
+
107
+ }
108
+
109
+ ：
110
+
111
+
112
+
113
+ ////////////////////
114
+
115
+ // heavy-func.js 分散処理対象のモジュール
116
+
117
+ // masterプロセスのみで処理する場合、5000ms以上費やす計算
118
+
119
+ ////////////////////
120
+
121
+ function HeavyFunc(heavyDataKeyArr) {
122
+
123
+ return new Promise(function(resolve) {
124
+
125
+ ：
126
+
127
+ heavyDataKeyArr.forEach(function(redisKey) {
128
+
129
+ redisKey.get(redisKey, function(err, heavyData){
130
+
131
+ // redisに保存されている redisKey:heavyData に対する計算
132
+
133
+ :
134
+
135
+ RedisSetter(redisKey, heavyData); // 場合により Promise then から resolveへ
136
+
137
+ resolve();
138
+
139
+ });
140
+
141
+ });
142
+
143
+ ：
144
+
145
+ });
146
+
147
+ }
148
+
149
+ ：
150
+
151
+ ```
152
+
153
+
154
+
155
+ 上記方法により各プロセスごとに計算処理を振り分けることは可能でしたが、
156
+
157
+ そもそも、
158
+
159
+ - **親プロセス←→子プロセスでのデータの受け渡しと処理終了通知の通信が必要となる**
160
+
161
+ - **上記特定処理（heavy-func.js）のみのために、記載コードすべてを含んだ子プロセス（アプリのコピー）が上がっている ※1 無駄な感じがある**
162
+
163
+ - **上2点あわせて、無駄なコード・無駄なメモリ消費につながっている**
164
+
165
+
166
+
167
+ 以上、clusterを利用する手法はnodeアプリ自体を並列化・スケールさせる際に有効な手法なのではないかと感じました。それは、ドキュメントの[サンプル](https://nodejs.org/api/cluster.html#cluster_cluster)がwebサーバを並列化させていることとも関連していそうです。
168
+
169
+
170
+
171
+ ※1（補足）
172
+
173
+ [http://postd.cc/setting-up-a-node-js-cluster/](http://postd.cc/setting-up-a-node-js-cluster/)
174
+
175
+ > cluster.fork()とchild_process.fork()には、いくつかの主な違いがあります。
176
+
177
+ > ：
178
+
179
+ > clusterが、自身が実行を始めたのと同じモジュールの先頭からワーカの実行コードを起動することです。
180
+
181
+ > したがって、アプリケーションのエントリポイントがindex.jsでありながらワーカがcluster-my-app.jsの
182
+
183
+ > 中で生成された場合でも、ワーカはやはり、index.jsの先頭から実行コードを起動します。
184
+
185
+
186
+
187
+ よって、nodeでの分散処理を考える場合、以下ケースになりそうだと感じています。再掲になりますが、nodeでの分散処理の手法について、以下の考え方で妥当なのか、向き不向きについて知見がありましたら、ご意見いただければ幸いです。
188
+
189
+
190
+
191
+ ---
192
+
193
+ **▼nodeアプリケーション自体を並列化、スケールさせたいケース**
194
+
195
+ →cluster.forkを使う
196
+
197
+
198
+
199
+ clusterモジュールはアプリケーション自体を並列状態にしてスケールさせたいケースで有用
200
+
201
+
202
+
203
+ 使用例）
204
+
205
+ nodeのwebサーバを含めて、nodeアプリ自体を並列化してスケールできる場合
6
206
 
7
207
 
8
208
 
9
-
10
-
11
- ---
209
+ ---
12
-
210
+
13
- **▼nodeアプリケーション自体を並列化、スケールさせたいケース**
211
+ **▼発生頻度の低いCPUヘビーな処理をnodeで行いたいケース**
14
-
212
+
15
- →cluster.forkを使う
213
+ →child_process.forkを使う
16
-
17
-
18
-
214
+
215
+
216
+
19
- clusterモジュールはアプリケーション自体を並列状態にしてスケールさせたいケースに向いている？？
217
+ 処理発生時に子プロセスを立ち上げて処理終了時にクローズ。頻度の低い重い処理が発生した際、メインのイベントループがブロックされないように、処理を逃したいケースで有用
20
-
21
- 特定の処理を分散させるためにclusterでアプリ全体の子プロセスを持つのは非効率？？
218
+
22
-
23
-
24
-
219
+
220
+
25
- 例）
221
+ 使用例）
26
-
27
- webサーバのリクエスト待ち受け等、nodeアプリ全体を並列化してスケールさせたい場合
222
+
28
-
29
-
30
-
31
- **【補足】**
32
-
33
- [http://postd.cc/setting-up-a-node-js-cluster/](http://postd.cc/setting-up-a-node-js-cluster/)
34
-
35
- > cluster.fork()とchild_process.fork()には、いくつかの主な違いがあります。
36
-
37
- > ：
38
-
39
- > clusterが、自身が実行を始めたのと同じモジュールの先頭からワーカの実行コードを起動することです。
40
-
41
- > したがって、アプリケーションのエントリポイントがindex.jsでありながらワーカがcluster-my-app.jsの
223
+ バッチ処理的な用途ほか、動画のエンコード、画像処理等ほか、頻度は低いが、数十秒〜数分の長い時間を要する計算処理（そもそもnodeでやるかは置いといて）
42
-
43
- > 中で生成された場合でも、ワーカはやはり、index.jsの先頭から実行コードを起動します。
44
-
45
-
46
-
47
-
48
224
 
49
225
 
50
226
 
51
227
  ---
52
228
 
53
- **▼発生頻度の低いCPUヘビーな処理をnodeで行いたいケース**
229
+ **▼発生頻度が高い、あるいは、定期的に発生するCPUバウンドな処理をnodeで行いたいケース**
54
-
55
-
56
-
57
- →child_process.forkを使う
230
+
58
-
59
-
60
-
61
- 処理発生時に子プロセスを立ち上げて自分で管理。メインのイベントループがブロックされないように、処理を逃したいケースに向いている？？
62
-
63
- 処理が頻繁に発生する場合はnode-worker-farm等のpool系モジュールを利用したほうが効率的？？
231
+ →node-worker-farmなどchild_processプール系モジュール利用
232
+
233
+
234
+
64
-
235
+ プール状態のchild_processで、頻繁に発生する負荷のある処理を行いたいケースで有用
65
-
66
-
236
+
237
+
238
+
67
- 例）
239
+ 使用例）
68
-
240
+
69
- バッチ処理的な用途ほか、動画のエンコード、画像処理等ほか、頻度は低いが、数十秒〜数分の長い時間を要する計算処理（nodeでやるかは抜きで）
241
+ リアルタイム性の高い計算処理、集計処理など、頻度の高い数秒〜数十秒時間を要する計算処理。私が上記コードでclusterを用いて行っていたような特定処理の分散用途
70
242
 
71
243
 
72
244
 
@@ -74,29 +246,7 @@
74
246
 
75
247
  ---
76
248
 
77
- **▼発生頻度が高い、あるいは、定期的に発生するCPUバウンドな処理をnodeで行いたいケース**
78
-
79
-
80
-
81
- →node-worker-farmなどchild_processプール系モジュール利用
82
-
83
-
84
-
85
- プール状態のchild_processで、頻繁に発生する負荷のある処理を行いたいケースに向いている？？
86
-
87
-
88
-
89
- 例）
90
-
91
- リアルタイム性の高い計算処理、集計処理など、頻度の高い数秒〜数十秒時間を要する計算処理
92
-
93
-
94
-
95
-
96
-
97
- ---
98
-
99
- **【参考情報】**
249
+ **【参考にした情報】**
100
250
 
101
251
  [Why you should use Node.js for CPU-bound tasks](http://neilk.net/blog/2013/04/30/why-you-should-use-nodejs-for-CPU-bound-tasks/)
102
252