DevOpsナレッジハブ
DevOpsナレッジハブ

CPUとメモリ制限でDockerコンテナのパフォーマンスを最適化する

CPUおよびメモリ制限を設定することにより、Dockerコンテナのパフォーマンスを最適化する方法を学びます。このガイドでは、CPUシェア、クォータ、メモリ制限、スワップなどの重要な設定オプションについて説明します。`docker stats` を使用してコンテナのリソース使用量を監視する方法を発見し、リソースの枯渇を防ぎ、アプリケーションの安定性を向上させ、システム全体の効率を高めるためのベストプラクティスを実装します。

41 ビュー

CPUおよびメモリ制限によるDockerコンテナのパフォーマンス最適化

Dockerは、アプリケーションとその依存関係を軽量でポータブルなコンテナにパッケージ化できるようにすることで、アプリケーション展開に革命をもたらしました。Dockerは一貫性とスケーラビリティの面で大きな利点を提供しますが、リソース管理を怠ると、パフォーマンスのボトルネック、アプリケーションの不安定性、および非効率的なリソース利用につながる可能性があります。DockerコンテナのCPUおよびメモリ制限を適切に構成することは、アプリケーションがスムーズかつ確実に実行されるようにするための、パフォーマンス最適化の重要な側面です。

このガイドでは、DockerコンテナのCPUおよびメモリ制限を設定する際の詳細について掘り下げます。これらの制限が不可欠な理由、Dockerの組み込み機能を使用してそれらを構成する方法、およびコンテナのリソース消費を監視するために利用できるツールについて探ります。これらの戦略を理解し、実装することで、リソースの枯渇を防ぎ、アプリケーションの応答性を高め、全体的なシステム効率を向上させることができます。

CPUおよびメモリ制限を設定する理由

コンテナは、デフォルトではホストマシンが許容する限り多くのリソースを消費できます。単一のホストで複数のコンテナが実行されている動的な環境では、これはいくつかの問題を引き起こす可能性があります。

  • リソースの枯渇（Resource Starvation）： 暴走した、またはリソース集約型の単一のコンテナが、CPUまたはメモリを不均衡に大量消費し、他のコンテナやホストシステム自体を枯渇させる可能性があります。これにより、アプリケーションが応答しなくなったり、クラッシュしたりする可能性があります。
  • パフォーマンスの低下： 明確なクラッシュがない場合でも、過剰なリソース消費は、ホスト上のすべてのアプリケーションで全体的なパフォーマンス低下を引き起こす可能性があります。
  • 予測不可能な動作： 制限がないと、アプリケーションのパフォーマンスは、同じホスト上の他のコンテナの活動に大きく左右され、一貫したパフォーマンスを保証することが困難になります。
  • 課金の非効率性： クラウド環境では、管理されていないコンテナの消費によるリソースの過剰なプロビジョニングは、不必要なコストにつながる可能性があります。

明示的なCPUおよびメモリ制限を設定することで、各コンテナがアクセスできるリソースを制御および分離するメカニズムが提供され、公平なリソース割り当てと予測可能なパフォーマンスが保証されます。

CPU制限の構成

Dockerでは、主に2つのメカニズムを使用して、コンテナが利用できるCPUリソースを制御できます。それは、CPU shares（CPU共有）とCPU CFS（Completely Fair Scheduler）のクォータ/期間です。

CPU Shares（「--cpu-shares」）

CPU sharesは相対的な重み付けシステムです。絶対的な制限を設定するのではなく、同じホスト上の他のコンテナと比較して、コンテナが受け取るCPU時間の割合を定義します。デフォルトでは、すべてのコンテナは1024 CPU sharesを持ちます。

  • --cpu-shares 512を持つコンテナは、--cpu-shares 1024を持つコンテナの半分のCPU時間を受け取ります。
  • --cpu-shares 2048を持つコンテナは、--cpu-shares 1024を持つコンテナの2倍のCPU時間を受け取ります。

これは、ホストが重いCPU負荷にある場合に、特定のコンテナを他のコンテナよりも優先するのに役立ちます。ただし、ホストに十分なCPU容量がある場合、コンテナはsharesによって制限されない可能性があります。

例：

コンテナにデフォルトの2倍のCPU優先度を与えるには：

docker run -d --name my_app --cpu-shares 2048 nginx

CPU CFSクォータと期間（「--cpu-period」、「--cpu-quota」）

より正確な制御のために、CPUクォータと期間を使用できます。このメカニズムは、特定の期間内にコンテナが使用できるCPU時間の絶対的な制限を設定します。

  • --cpu-period: CPU CFS期間をマイクロ秒単位で指定します（デフォルトは100000です）。
  • --cpu-quota: CPU CFSクォータをマイクロ秒単位で指定します。これは、コンテナが1つの--cpu-period内で使用できるCPU時間の最大量を定義します。

コンテナが利用できる合計CPU時間は、--cpu-quota / --cpu-periodです。たとえば、コンテナを単一のCPUコアの50%に制限するには：

  • --cpu-period 100000（100ミリ秒）を設定します。
  • --cpu-quota 50000（50ミリ秒）を設定します。

これは、コンテナが100ミリ秒ごとに50ミリ秒のCPU時間を使用できることを意味し、事実上、CPUコアの半分に制限されます。

コンテナを2つのCPUコアに制限するには、次のように設定します。

  • --cpu-period 100000
  • --cpu-quota 200000

例：

コンテナを1つのCPUコアの50%に制限します：

docker run -d --name limited_app --cpu-period 100000 --cpu-quota 50000 ubuntu

CPUリアルタイムスケジューラ（「--cpu-rt-runtime」）

リアルタイムアプリケーション向けに、Dockerはリアルタイムスケジューラ構成もサポートしていますが、これらは高度な設定であり、一般的に通常のWebアプリケーションには必要ありません。

メモリ制限の構成

メモリ制限は、コンテナが過剰なRAMを消費するのを防ぎます。これは、ホスト上でのスワッピングやパフォーマンスの問題につながる可能性があります。

メモリ制限（「--memory」）

このオプションは、コンテナが使用できるメモリ量にハードリミットを設定します。コンテナがこの制限を超えると、カーネルのOOM（Out-Of-Memory）キラーが通常、コンテナ内のプロセスを終了します。

制限は、b、k、m、またはgのようなサフィックスを使用して、バイト、キロバイト、メガバイト、またはギガバイトで指定できます。

例：

コンテナを512メガバイトのメモリに制限します：

docker run -d --name memory_limited_app --memory 512m alpine

メモリスワップ（「--memory-swap」）

このオプションは、コンテナが使用できるスワップメモリの量を制限します。これは、--memoryと組み合わせて使用されることが多いです。--memory-swapが設定されていない場合、コンテナは--memoryによって設定された制限まで、無制限のスワップを使用できます。

  • --memoryが設定されている場合、--memory-swapはデフォルトで--memoryの値の2倍になります。
  • --memoryと--memory-swapの両方が設定されている場合、コンテナは--memoryの制限までのメモリと、--memory-swapの制限までのスワップを使用できます。
  • --memory-swapを-1に設定すると、スワップが無効になります。

例：

コンテナを256MBのRAMと256MBのスワップに制限します：

docker run -d --name swap_limited_app --memory 256m --memory-swap 512m alpine

（注：この例では、コンテナは最大256MBのRAMを使用でき、RAMとスワップの使用量の合計は512MBを超えることはできません。事実上、スワップ制限は256MBです）。

コンテナリソース使用量の監視

制限を設定したら、コンテナがどのように機能しているか、リソース制約に達していないかを監視することが重要です。Dockerは、この目的のために組み込みツールを提供しています。

docker stats

docker statsコマンドは、実行中のコンテナのリソース使用統計のライブストリームを提供します。表示される情報は次のとおりです。

  • CONTAINER ID と NAME
  • CPU %: コンテナが使用しているホストのCPUの割合。
  • MEM USAGE / LIMIT: 現在のメモリ使用量と構成されたメモリ制限の比較。
  • MEM %: コンテナが使用しているホストのメモリの割合。
  • NET I/O: ネットワーク入出力。
  • BLOCK I/O: ディスク読み取り/書き込み操作。
  • PIDS: コンテナ内で実行されているプロセス（PID）の数。

例：

実行中のすべてのコンテナの統計を表示するには：

docker stats

特定のコンテナの統計を表示するには：

docker stats <container_name_or_id>

docker statsを観察することで、CPUまたはメモリの制限に頻繁に達しているコンテナを特定でき、それらの制限を増やすか、アプリケーション自体を最適化する必要があることを示しています。

その他の監視ツール

より高度な監視とアラートのために、Dockerを以下と統合することを検討してください。

  • PrometheusとGrafana： 時系列監視と可視化のための一般的なオープンソースツール。
  • cAdvisor (Container Advisor)： コンテナメトリクスを収集、処理、エクスポート、および視覚化するためのGoogleのオープンソースエージェント。
  • クラウドプロバイダーの監視サービス： AWS CloudWatch、Google Cloud Monitoring、Azure Monitor。

ベストプラクティスと考慮事項

  • 適切なデフォルトから始める： 制限を恣意的に設定しないでください。通常時およびピーク負荷時のアプリケーションの一般的なリソースニーズを理解します。
  • 監視と反復： コンテナのパフォーマンスを継続的に監視し、必要に応じて制限を調整します。パフォーマンスチューニングは継続的なプロセスです。
  • 制限を低く設定しすぎない： アプリケーションの不安定性や頻繁なOOMエラーにつながる可能性があります。
  • 制限を高く設定しすぎない： これはリソース制御の目的を損ない、非効率的なリソース割り当てにつながる可能性があります。
  • アプリケーションアーキテクチャを考慮する： マイクロサービスの場合、各サービスで必要なリソースが異なる場合があります。サービスごとに制限を調整してください。
  • 負荷テストを行う： 常に、構成された制限の下で、シミュレートされたピーク負荷時のアプリケーションのパフォーマンスと安定性をテストしてください。
  • OOMキラーの影響を理解する： メモリ制限に達すると、OOMキラーがプロセスを終了します。アプリケーションがそのようなイベントを適切に処理できること、またはこれを防ぐために制限が適切に設定されていることを確認してください。
  • 優先順位付けにCPU sharesを使用する： 複数のコンテナがあり、競合中に一部のコンテナが他のコンテナよりも多くのCPUを獲得するようにする必要がある場合は、--cpu-sharesを使用します。
  • ハードリミットにCPUクォータを使用する： コンテナが特定のCPU容量を超えないようにする必要がある場合は、--cpu-periodと--cpu-quotaを使用します。

まとめ

DockerコンテナのCPUおよびメモリリソースを効果的に管理することは、安定性、高性能、および効率性の高いアプリケーションを構築するための基本です。Dockerに組み込まれているリソース制限機能を活用し、docker statsなどの監視ツールを利用することで、コンテナ化された環境を制御できます。観測されたパフォーマンスに基づいてこれらの制限を定期的に確認および調整し、リソースの競合を防ぎ、ホストインフラストラクチャの利用を最大化して、アプリケーションが最適に実行されるようにしてください。