Golangのシングルバイナリの分離について

Question

これからGolangの勉強をしようと考えているものです。
基本的な質問でしたら申し訳ありません。

GolangでWebサーバー等を作った際、シングルバイナリになると思います。
確かにシングルバイナリは取り回しに非常に便利ですが、一方で気になる点があります。

もし、Webサーバーの処理内容が多岐に渡った場合（業務アプリケーションなど）、非常に巨大なバイナリが作成されると思います。（数GB）

1. このときWebサーバーの実行中は、それらすべてがメモリ上に常に上げられているという認識でよいでしょうか？（マルチスレッド等の場合は　バイナリサイズ×スレッド分？）
2. 他言語などでは、動的にそのHTTP呼び出しで使用するモジュールファイルのみを読み込んで実行することが可能かと思います。Golangでも同様の対応が可能でしょうか？参考サイトなどいただけると幸いです。
3. そもそも、そのような巨大なバイナリを作らず、マイクロサービスアーキテクチャ等を採用して、Webサーバー自体分けるべきでしょうか？

よろしくお願いします。

Answer 1

質問者のいう様な非常に大きなバイナリになる製品は単一のプロセスで全ての機能を賄う「モノリシック」な設計と言えます。

また、コンテンツ（HTMLや画像）をバイナリに含めたままだと巨大なコンテンツを扱うと結合コストがバカにならなくなるのでおそらくコンテンツをバンドルする様な構成はどこかで破綻します。

そしてロジックだけなら数百メガバイトからはなかなか増えないと思います。（ウインドウズとかを提供するレベルならあり得るわけですが、それでも多数のアプリを含むから数ギガのサイズになってるわけで。）

またモノリシックな製品はアップデートが行いにくくなるので結果として単一バイナリのモノリシックな構成は小さなプロダクト向けだという認識です。（ウインドウズアップデートがいつも数ギガダウンロードでディスク大量書き換えだと大変ですよね）

巨大な仕組みの場合はおっしゃる通り責任分岐点を見極め、分離したマイクロサービスで構築するのがアップデートも行いやすくなりモノリシックのいろんな欠点を回避できます。

モノリシック製品最大の欠点はとある小さな業務の変更（例えば誤字の訂正）なのに全ての業務を止めて差し替えなければならなくなる点です。

もちろん運用次第ではそれでも構わないということはあるかもしれませんが、こういうリスクを抱えたまま巨大な仕組みをモノリシックな設計にわざわざ振ることはしないでしょう。

プロセス内のメモリは複数のスレッドから参照可能なのでスレッドごとに冗長なメモリを占有する必要はあまりありませんが、プロセスをまたぐ情報は相互参照をOSにより禁止されているのでほとんどの場合は冗長に持たせることになります。Goの場合、1プロセスだけでホストのマルチコア性能を引き出す運用が可能ですのでその場合、マルチプロセスで性能を稼ぐやり方に比べ冗長なメモリを浪費することが無いのは利点の一つですね。

traefikやnginxなどのリバースプロキシサービスを前段に置くことで複数のWebアプリへ振り分けることができますし、業務別にWebアプリを分離して構築するのは簡単です。（URLのプレフィックスで別のサーバーに中継など）

まとめると、

• 数ギガに及ぶバイナリはビルド・運用・維持全てに無理が出る
• まずはコンテンツとロジックを分けよう
• Goなら1プロセスサービスで大量の処理を捌けるのはメモリに優しい
• 多岐にわたる業務は分離実装の方がメンテしやすい
• ある程度大きな仕組みになる予定ならリバースプロキシやロードバランサーを活用した設計に

Comments

[nobonobo]

traefikの後ろに多数のモノリシックなWebサービスを並べて業務システムを作るというのはオススメの構成の一つです。

[nobonobo]

もちろん、さらに便利な仕組みとしてk8sやGKE、AWS-ECSなどがありこちらを利用すると運用や維持がしやすくて良いです。