はじめに
プラットフォームエンジニアに限らず様々な職種の IT エンジニアにとって、今や Docker の知識は必須になっています。たとえばプラットフォームエンジニアは、開発環境を整備するという文脈で Docker に触れることがあります。
そういった背景の元、この記事では Docker の実践的な知識の一つとしてコンテナの適切な粒度について考えます。大切な知識なので、ぜひ最後までご覧ください。
1 コンテナ = 1 プロセスという説がかつてあった
Docker の黎明期において、一部のユーザが「1 コンテナ = 1 プロセス」を厳守すべきという説を唱えていたようです。シンプルでわかりやすそうな考え方なのですが、必ずしも最適とは限りません。
たとえば、コンテナ化した nginx を使うことを考えます。nginx にはマスタープロセスとワーカープロセスがあります。ワーカープロセスは複数ありえます。このとき、nginx の各プロセスを別々のコンテナに分けようとすると、設定が非常に複雑になり管理が困難になります。
このように「1 コンテナ = 1 プロセス」が必ずしも適切だとは言えないことがわかります。
1 コンテナ = 1 つの関心事という考え方をしてみよう
では、どうすればいいのでしょうか。実は Docker 公式にコンテナの粒度についてベストプラクティスが明記されています。それが「1 コンテナ = 1 つの関心事」という考え方です。
Each container should have only one concern.
Building best practices | Docker Docs
よりわかりやすい考え方が『Docker/Kubernetes実践コンテナ開発入門 改訂新版』に記載があります。それが以下です。
それぞれのコンテナが担うべき役割を適切に見定め、かつそれがレプリカとして複製された場合でも副作用なくスタックとして正しく動作できる状態になるか？」という考えにもとづいて設計すると良い
山田 明憲. Docker/Kubernetes実践コンテナ開発入門 改訂新版 (p.179). 株式会社技術評論社. Kindle 版.
先ほどと同じく nginx を例に考えます。無理やり「1 コンテナ = 1 プロセス」に分けず、「リクエストを受け取ってレスポンスを返す」という 1 つの関心事と捉えます。そうすると、nginx はこの場合は 1 つのコンテナで良さそうです。こんなふうに考えます。
さいごに
Docker コンテナの粒度を決定する際には、「1 コンテナ = 1 プロセス」という考え方に固執せず、「1 コンテナ = 1 つの関心事」というアプローチを採用することが重要です。これにより、システムの複雑さを軽減し、パフォーマンスや管理の効率を向上させることができます。適切なコンテナの粒度設定は、柔軟で強力なコンテナベースのアーキテクチャを実現するための鍵となります。
コメント