Network 周りの設定は App 側でやるべきか、Infra 側でやるべきか¶

はじめに¶

リトライ処理や認証など、ネットワークに関する処理は、状況に応じて実装方法が変わる。アプリケーション側とインフラ側の両面で実装可能であるが、本稿はインフラ（ミドルウェア）側で設定を行うメリットに焦点を当てる。

ネットワーク設定を App 側で行う場合¶

アプリケーション側でネットワーク設定を行うのであれば、設定がコード内に直接記述されるか、環境変数により設定される。 その結果、プログラミング言語やフレームワークへの依存が生じ、設定の統一や移植が困難になる。組織が推奨する設定を準拠できているかの確認は難しく、実装がどうなっているかの深掘りが求められる。 また、設定変更が発生した場合、アプリケーションの再デプロイや再起動が必要となる。

ネットワーク設定を Infra 側で行う場合¶

インフラ側でネットワーク設定を管理すれば、アプリケーションコードに依存しない形で設定を管理できる。各々のプログラミング言語やフレームワークに依存しないことで、設定の統一および移植が容易になる。設定をうまく切り出せていれば設定変更があった場合でも、アプリケーションの再デプロイや再起動を回避できる。ただし、Side Car パターンを採用する場合、Side Car を再起動するためにアプリケーション用の ReplicaSet も再デプロイや再起動が必要になる。 インフラ側で設定を行う場合、設定の変更が容易になる一方で、ミドルウェアが単一障害点となる懸念があったり、ミドルウェア採用の認知負荷が発生する可能性がある。

ミドルウェアの例¶

あまり詳しく触れないが、ミドルウェアの例として Kubernetes の Gateway API などがある。Gateway API を利用することで、ネットワーク設定をアプリケーションから切り出してインフラ側で管理できる。

まとめ¶

アプリケーション側でネットワーク設定を行う場合、プログラミング言語やフレームワークへの依存により、設定の統一や移植が困難になる。一方、インフラ側で設定を管理すれば、設定の統一や移植が容易になる。設定変更があった場合でも、アプリケーションの再デプロイや再起動を回避できる。ただし、ミドルウェアが単一障害点となる懸念があったり、ミドルウェア採用の認知負荷が発生する可能性がある。