もはやWebサービスの開発に不可欠なDocker。
私も普段の業務でDockerを使わない日はないです。BiTT開発でもお客様からフロントエンドのとバックエンドの開発をフルスクラッチでお願いされることがあります。一般的かどうか微妙ではありますが、その際にコンテナをフロントエンドとバックエンド両方に分けるか、それとも一つにまとめるか検討が必要になってくると思います。
これは絶対的にどちらかが良いということはないのですが、私は1コンテナ派です。そのため今回は1コンテナ化のメリットについてお話ができればと思います。
目次
1コンテナのメリット
メリット①システム性能とコストにも優しい
もしフロントエンドとバックエンドを2コンテナ化した場合はどうでしょう？？ 少なくともDocker上に二つのOSを入れる必要があります。
仮想的にはあたかも二つのOSがノンストレスで動いているような状況にはなりますが、実際にコンテナを動かしているサーバーは限られたハード資源で動いている状況です。
イメージとしてはご覧の通りです。
つまり、一つのサーバー上に展開されるコンテナが増えれば増えるほど、システムとしてのパフォーマンスが低下します。パフォーマンスを上げるとなるとハードのスペックを上げる必要が出てくるため、AWSを使う場合は結果的にランニングコストが増してしまいます。
そのため、システムとしてのパフォーマンスやコストを重視するという観点では、1コンテナのほうが断然良い結果がもたらせれます。
メリット②本番環境へのポーティングが容易
以下は1コンテナ化した際の例です。
ご覧のとおり、リバースプロキシ、フロントエンド、バックエンドが盛り込まれている状況となります。この状態でDocker上にポーティングすれば、localhostと本番環境が同じ条件で動くことが可能になります。
つまりシステムのメンテナンス性の向上と本番環境へのポーティングを容易にできます。特にこのようなケースは、アプリケーションの開発はLIGで行い、インフラの構築はお客様側で行う場合などに大変役立ちます。
メリット③フロントエンドとバックエンドで位相を合わせながら開発が可能
基本的にはバックエンドのAPIが改修した場合ですが、プルリクエストをエンジニアから受け取って、テクニカルディレクターはその内容を確認します。ただこのタイミングでフロントエンド側の影響度などについても同時に確認することになります。
例えばメインのブランチに影響を与えたくない場合は、APIの改修と同時にフロントエンドの修正コミットを1プルリクエストに入れることも可能です。
また何か不都合な問題が発生し、ロールバックが必要となった場合は、バックエンド並びにフロントエンド両方ともコミットをロールバックすることが可能です。結果的にシステムのメンテナンス性を向上させることができます。
コンテナを分けた方が良いケース
FEとBEを分けた方が良いケースについて考察してみました。例えば以下のケースが該当するのではないでしょうか。
ケース①APIをマイクロサービスとして汎用的に使えるようにしたい
例えば、APIをマイクロサービスとしてあらゆるサービスが汎用的に使えるようにしたい、となった場合はどうでしょうか。様々なFEからAPIが呼ばれるかたちになりますよね？？ その際は、そもそも1コンテナということはできないので、複数コンテナ化が望ましいです。
ケース②FEとBEを別々のベンダーで協業しながら開発したい
例えばFEがLIG、BEがお客によるが開発となった場合はどうでしょう？？ もし1コンテナ化してしまうとお客様のBEのロジックが剥き出しになってしまいます。重大なBEのプログラムロジックがベンダーに知られてしまう恐れがあります。
そうならないようにするためにも、このようなケースにおいてはコンテナは別々で分けて運用するかたちが望ましいです。
まとめ
いかがでしたでしょうか。簡単にまとめるとBEとFEを1コンテナで実装すると、性能面並びにメンテナンス性において、複数コンテナに比べると優位になります。ただし開発体制並びにアーキテクチャによっては別々のコンテナが望ましいというケースもあります。
もしFEとBEを一括して請け負うかたちの開発が可能であれば、1コンテナ化が望ましいと思います。これについては、皆さんの開発のスタイルに応じて適宜検討しながら進めていってもらえたらと思います。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
