回答編集履歴
3
誤字訂正
answer
CHANGED
|
@@ -1,16 +1,16 @@
|
|
|
1
|
-
質問者のいう様な非常に大きなバイナリになる製品は単一のプロセスで全ての機能を賄う「モノ
|
|
1
|
+
質問者のいう様な非常に大きなバイナリになる製品は単一のプロセスで全ての機能を賄う「モノリシック」な設計と言えます。
|
|
2
2
|
|
|
3
3
|
また、コンテンツ（HTMLや画像）をバイナリに含めたままだと巨大なコンテンツを扱うと結合コストがバカにならなくなるのでおそらくコンテンツをバンドルする様な構成はどこかで破綻します。
|
|
4
4
|
|
|
5
5
|
そしてロジックだけなら数百メガバイトからはなかなか増えないと思います。（ウインドウズとかを提供するレベルならあり得るわけですが、それでも多数のアプリを含むから数ギガのサイズになってるわけで。）
|
|
6
6
|
|
|
7
|
-
またモノ
|
|
7
|
+
またモノリシックな製品はアップデートが行いにくくなるので結果として単一バイナリのモノリシックな構成は小さなプロダクト向けだという認識です。（ウインドウズアップデートがいつも数ギガダウンロードでディスク大量書き換えだと大変ですよね）
|
|
8
8
|
|
|
9
|
-
巨大な仕組みの場合はおっしゃる通り責任分岐点を見極め、分離したマイクロサービスで構築するのがアップデートも行いやすくなりモノ
|
|
9
|
+
巨大な仕組みの場合はおっしゃる通り責任分岐点を見極め、分離したマイクロサービスで構築するのがアップデートも行いやすくなりモノリシックのいろんな欠点を回避できます。
|
|
10
10
|
|
|
11
|
-
モノ
|
|
11
|
+
モノリシック製品最大の欠点はとある小さな業務の変更（例えば誤字の訂正）なのに全ての業務を止めて差し替えなければならなくなる点です。
|
|
12
12
|
|
|
13
|
-
もちろん運用次第ではそれでも構わないということはあるかもしれませんが、こういうリスクを抱えたまま巨大な仕組みをモノ
|
|
13
|
+
もちろん運用次第ではそれでも構わないということはあるかもしれませんが、こういうリスクを抱えたまま巨大な仕組みをモノリシックな設計にわざわざ振ることはしないでしょう。
|
|
14
14
|
|
|
15
15
|
プロセス内のメモリは複数のスレッドから参照可能なのでスレッドごとに冗長なメモリを占有する必要はあまりありませんが、プロセスをまたぐ情報は相互参照をOSにより禁止されているのでほとんどの場合は冗長に持たせることになります。Goの場合、1プロセスだけでホストのマルチコア性能を引き出す運用が可能ですのでその場合、マルチプロセスで性能を稼ぐやり方に比べ冗長なメモリを浪費することが無いのは利点の一つですね。
|
|
16
16
|
|
2
文言整理
answer
CHANGED
|
@@ -18,7 +18,8 @@
|
|
|
18
18
|
|
|
19
19
|
まとめると、
|
|
20
20
|
|
|
21
|
+
- 数ギガに及ぶバイナリはビルド・運用・維持全てに無理が出る
|
|
21
|
-
- コンテンツとロジックを分けよう
|
|
22
|
+
- まずはコンテンツとロジックを分けよう
|
|
22
23
|
- Goなら1プロセスサービスで大量の処理を捌けるのはメモリに優しい
|
|
23
24
|
- 多岐にわたる業務は分離実装の方がメンテしやすい
|
|
24
|
-
- ある程度大きな仕組みにな
|
|
25
|
+
- ある程度大きな仕組みになる予定ならリバースプロキシやロードバランサーを活用した設計に
|
1
プロセスとスレッドの事を追記
answer
CHANGED
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
|
|
13
13
|
もちろん運用次第ではそれでも構わないということはあるかもしれませんが、こういうリスクを抱えたまま巨大な仕組みをモノシリックな設計にわざわざ振ることはしないでしょう。
|
|
14
14
|
|
|
15
|
-
Goの場合、1プロセスだけでホストのマルチコア性能を引き出す運用が可能です
|
|
15
|
+
プロセス内のメモリは複数のスレッドから参照可能なのでスレッドごとに冗長なメモリを占有する必要はあまりありませんが、プロセスをまたぐ情報は相互参照をOSにより禁止されているのでほとんどの場合は冗長に持たせることになります。Goの場合、1プロセスだけでホストのマルチコア性能を引き出す運用が可能ですのでその場合、マルチプロセスで性能を稼ぐやり方に比べ冗長なメモリを浪費することが無いのは利点の一つですね。
|
|
16
16
|
|
|
17
17
|
traefikやnginxなどのリバースプロキシサービスを前段に置くことで複数のWebアプリへ振り分けることができますし、業務別にWebアプリを分離して構築するのは簡単です。（URLのプレフィックスで別のサーバーに中継など）
|
|
18
18
|
|