このチュートリアルでは、Alibaba Cloud ECS上でDockerコンテナのリソース制限機能を利用した実践的な体験ができます。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

#前提条件
最新バージョンのDockerがすでにインストールされているECSサーバーにアクセスする必要があります。もしまだ持っていない場合は、このチュートリアルの手順に従ってください。

これらのリソース制限テストでは20～30MBのRAMを使用するので、合計512MBのRAMしかないサーバでも問題ありません。

CPUテストは2コアのみのサーバで行われます。サーバーのコア数が 4 つ以上の場合、テストの一つとして、より興味深い結果が得られるでしょう。

いくつかの CPU テストでは、15 秒間すべての CPU を占有します。このチュートリアルを共有開発サーバではなく、あなたのコンピュータで直接行った方が、あなたのチームメイトのためにも良いでしょう。

私はCentOSを使ってこのチュートリアルを書いています。Debian / Ubuntuを使用することができます。このチュートリアルは主にDockerコマンドを使用しているので、99%はどのLinuxディストロでも動作します。

Docker、イメージ、コンテナ、そしてdocker runとdocker ps -aの使用については、非常に基本的な理解が必要です。

#クリーンアップの準備
実行中のコンテナーが少ない（できればない）場合に非常に役立ちます。このようにすると、Docker ps -a出力リストでチュートリアルコンテナーを簡単に見つけることができます。

そこで、実行している必要のないすべてのコンテナを停止してプルーニングしてください。

（開発環境で）次のようにしてすばやく実行できます。

docker stop $(docker ps -a -q) #stop ALL containers

すべてのコンテナを削除するには、次のように実行します。

docker rm -f $(docker ps -a -q) # remove ALL containers

#––memory-reservation
https://docs.docker.com/config/containers/resource_constraints/ より

メモリ不足や競合をDockerが検知したときに起動する--memoryよりも小さいソフトリミットを指定することができます。もし --memory-reservation を使用する場合は --memory よりも小さい値を設定しなければ優先されません。ソフトリミットなので、コンテナがリミットを超えないことを保証するものではありません。

私はこれを1GB RAMのサーバーで実行しています。

5つのコンテナをそれぞれ250MBのRAMを確保して実行してみましょう。

docker container run -d --memory-reservation=250m --name mymem1 alpine:3.8 sleep 3600
docker container run -d --memory-reservation=250m --name mymem2 alpine:3.8 sleep 3602
docker container run -d --memory-reservation=250m --name mymem3 alpine:3.8 sleep 3603
docker container run -d --memory-reservation=250m --name mymem4 alpine:3.8 sleep 3604
docker container run -d --memory-reservation=250m --name mymem5 alpine:3.8 sleep 3605

私は250 MBのRAMを過剰予約したにもかかわらず、すべてのコンテナが実行されています。つまり、これは絶望的です: そして、過剰予約を防ぐことはできません。

topを実行すると、仮想RAMが割り当てられていないことがわかります。この設定はDockerの内部です。

 PID USER        VIRT    RES    SHR S %MEM     TIME+ COMMAND
  933 root      967.4m  86.0m  24.3m S  8.7   0:55.87 dockerd
  940 root      582.0m  36.3m  12.3m S  3.7   0:46.50 docker-containe
13422 root        8.7m   3.3m   2.5m S  0.3   0:00.02 docker-containe
13309 root        7.3m   3.0m   2.3m S  0.3   0:00.02 docker-containe
13676 root        7.3m   2.9m   2.2m S  0.3   0:00.01 docker-containe
13540 root        7.3m   2.8m   2.1m S  0.3   0:00.01 docker-containe
13793 root        8.7m   2.7m   2.1m S  0.3           docker-containe

docker stats は RAM の予約状況を表示しません。

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
a1a4bd1c226b        mymem5              0.00%               1.086MiB / 985.2MiB   0.11%               578B / 0B           1.19MB / 0B         0
9ced89c63a7e        mymem4              0.00%               1.105MiB / 985.2MiB   0.11%               648B / 0B           1.19MB / 0B         0
696f1cef7d57        mymem3              0.00%               1.113MiB / 985.2MiB   0.11%               648B / 0B           1.19MB / 0B         0
77d61012b5fd        mymem2              0.00%               1.086MiB / 985.2MiB   0.11%               648B / 0B           1.19MB / 0B         0
fab3faa6d23d        mymem1              0.00%               1.043MiB / 985.2MiB   0.11%               648B / 0B           1.19MB / 0B         0

docker ps -a

5つのコンテナが正常に動作していることを表示します。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
a1a4bd1c226b        alpine:3.8          "sleep 3605"        2 minutes ago       Up 2 minutes                            mymem5
9ced89c63a7e        alpine:3.8          "sleep 3604"        4 minutes ago       Up 4 minutes                            mymem4
696f1cef7d57        alpine:3.8          "sleep 3603"        5 minutes ago       Up 5 minutes                            mymem3
77d61012b5fd        alpine:3.8          "sleep 3602"        6 minutes ago       Up 6 minutes                            mymem2
fab3faa6d23d        alpine:3.8          "sleep 3600"        8 minutes ago       Up 8 minutes                            mymem1

これらのコンテナは終了しました。止めてからプルーニングすればいいのです。

docker container stop mymem1 -t 0
docker container stop mymem2 -t 0
docker container stop mymem3 -t 0
docker container stop mymem4 -t 0
docker container stop mymem5 -t 0
docker container prune -f

--memory and --memory-swap (スワップ不可)

https://docs.docker.com/config/containers/resource_constraints/ より

-m または --memory= コンテナが使用できる最大メモリ量。このオプションを設定した場合、最小許容値は 4m (4 メガバイト) です。
--memory-swap このコンテナがディスクにスワップすることを許可するメモリの量です。
memory-swap が --memory と同じ値に設定され、 --memory が正の整数に設定されている場合、コンテナはスワップにアクセスできません。
現在、スワップを許可しないことをテストしています。

慎重にMB単位でRAMを割り当てるためのツールが必要です - そうすれば、定義されたRAMの限界を慎重に超えてしまうだけです。私はPythonに決めました。( ここで使用されている4行のコードを理解するためにPythonを知る必要はありません。)

このチュートリアルの後編では、実際のベンチマークツールを使用します。

PythonのDockerイメージをまだお持ちでない方はダウンロードしてください。

docker pull python:3-alpine

コンテナを実行し、RAMを制限: --memory=20m --memory-swap=20m

docker container run -d --memory=20m --memory-swap=20m --name myPython python:3-alpine sleep 3600

docker exec -it myPython /bin/sh

シェルプロンプトでpython3と入力して、対話型のPythonエディタに入ります。以下のコードをカットアンドペーストしてください。Pythonではスペースには構文上の意味があるので、スペースやタブを追加しないように注意してください。

longstring = []
for x in range(17):
    len(longstring)
    longstring.append('1' * 10**6)

Enterキーを押してステートメントブロックを終了します。これでコードが実行されます。

期待される出力 .

>>> for x in range(17):
...     len(longstring)
...     longstring.append('1' * 10**6)
...
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Killed

このコンテナに20MBのRAMを割り当てました。Python は 5 MB を使用しています。forループは16MBの'1'文字をlongstring変数に追加しようとするとkillされてしまいます。

3つの注意点があります。

20 MB の制限内で RAM を割り当てた場合は動作しました。
制限を超えたRAMの割り当ては強制終了しました。
スワップを使用しない：スワップを使用することで、割り当てが静かに動作を継続しませんでした。

要約: --memory と --memory-swap (スワップは許可されていません) は両方とも同じ値に設定されている場合に動作します。コンテナ内で実行されているアプリケーションの知識に基づいて、これらの値を適切に設定する必要があります。

これでこのコンテナは終了です。これでこのコンテナは終了です。

docker container stop myPython
docker container prune -f

#––memory and --memory-swap (スワップ可能)
memory=20m と --memory-swap=30m を指定すると、10MBのスワップが可能になります。

どのように動作するか見てみましょう。

docker container run -d --memory=20m --memory-swap=30m --name myPython python:3-alpine sleep 3600
    
docker exec -it myPython /bin/sh

シェルプロンプトでpython3と入力して、インタラクティブなPythonエディタを起動します。以下のコードをカットアンドペーストしてください。Pythonではスペースには構文上の意味があるので、スペースやタブを追加しないように注意してください。

longstring = []
for x in range(24):
    len(longstring)
    longstring.append('1' * 10**6)

ENTERを押してfor文ブロックを終了します。これでコードが実行されます。

期待される出力 .

0 to 24 shown ... no killing

Pythonが使用する5MBのRAM。上記のように25MBのRAMを確保していますが、エラーはありません。

メモリ=20m --メモリスワップ=30mを指定しています。

30MBを使っただけなので、10MBがスワップされていることになります。topを別のシェルで実行して確認してみましょう。

top - 13:20:38 up  4:41,  2 users,  load average: 0.11, 0.05, 0.06
Tasks: 119 total,   1 running, 118 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.2 us,  0.3 sy,  0.0 ni, 99.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  985.219 total,  466.879 free,  190.812 used,  327.527 buff/cache
MiB Swap: 1499.996 total, 1490.078 free,    9.918 used.  618.730 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND             SWAP
  933 root      20   0  967.4m  91.5m  24.3m S        9.3   0:45.46 dockerd
  940 root      20   0  579.9m  33.1m  12.3m S   0.3  3.4   0:36.73 docker-containe
11900 root      20   0  253.5m  19.1m  10.5m S        1.9   0:00.25 docker
11941 root      20   0   39.1m  17.4m        S        1.8   0:00.39 python3             9.5m

予想通り、10MBのスワップが使用されています。(SWAPフィールドをトップに表示する必要があります。)

慎重に2MB以上のRAMを使うようにしましょう - コンテナはRAMを使い果たしているはずです。

これを切り取り、Pythonエディタに貼り付けます。ENTERキーを押して実行します。

longstring = []
for x in range(26):
    len(longstring)
    longstring.append('1' * 10**6)

期待される出力 .

it gets killed

このコンテナが完成しました。停止してプルーニングすることができます。

docker container stop myPython
docker container prune -f

概要: --memoryと--memory-swap (スワップ可能)は--memory-swapが--memoryよりも大きい場合に動作します。

制限は完全に適用されます。

本番環境ではコンテナに適切な制限を指定する必要があります。

現在のprodシステムのRAM使用量を調査してください。それに応じて制限値を定義することで、エラーの可能性を大きく広げながらも、暴走したコンテナがprodサーバをクラッシュさせるのを防ぎます。

#--ooom-kill-disable
これまでのところ、自動的に有効になったアウトオブメモリ機能は、私たちの暴走するPythonプログラムをkillしてしまいました。

これを無効にするとどうなるか見てみましょう。

以下の --oom-kill-disable に注意してください。

docker container run -d --oom-kill-disable --memory=20m --memory-swap=30m --name myPython python:3-alpine sleep 3600

無防備なコンテナに入力してください。

docker exec -it myPython /bin/sh

python3エディタを入力し、そのコードを貼り付け、ENTERを押して実行します。

python3    
a = []
for x in range(26):
    len(a)
    a.append('1' * 10**6)

コンテナがハングします。

別のシェルコンソールで top を実行します。

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND             SWAP
12317 root      20   0   41.0m  17.6m   0.0m D        1.8   0:00.32 python3            10.7m

コンテナの状態は D : uninterruptible sleep

別のシェルでは

docker exec -it myPython /bin/sh

これもハングします。

別のシェルを使用して、ぶら下がっているコンテナのPIDを取得して、強制終了できるようにします。

docker inspect myPython

PIDを取得します。

topかkill -9 your-PIDを使用して、それを強制終了します。。

結論:
ooom-kill-disableは使用しないでください。

あなたのハングアップしたシェルは、Linuxプロンプトに戻っています。これらを終了することができます。

#––cpu-shares
https://docs.docker.com/config/containers/resource_constraints/#cpu より

--cpu-share. このフラグをデフォルトの1024よりも大きいか小さい値に設定することで、コンテナの重量を増減させ、ホストマシンのCPUサイクルの大きいか小さいかの割合でアクセスできるようにします。
これは、CPU サイクルが制限されている場合にのみ適用されます。多くのCPUサイクルが利用可能な場合、すべてのコンテナは必要なだけのCPUを使用します。これはソフトリミットです。--cpu-sharesは、スウォームモードでコンテナがスケジューリングされるのを防ぐものではありません。
利用可能なCPUサイクルに対してコンテナのCPUリソースを優先します。特定のCPUアクセスを保証したり予約したりするものではありません。

計画：100、500、1000のCPUシェアを提供する3つのコンテナを実行します。

以下はひどいテストです。上記の説明をもう一度注意深く読んでから、次の3つのコマンドを読んで、なぜ正しく割り当てられたCPUの割合が明確に表示されないのかを判断できるかどうかを確認してください。

これらの CPU テストは、あなたが自分のコンピュータでこれを実行していて、共有開発サーバではないと仮定していることに注意してください。3つのテストでは、20秒間100%のCPUを占有します。

このチュートリアルシリーズの後半では、実際の Linux ベンチマークツールを使用して、独自のベンチコンテナを使用してこれらのテストを行います。特に、これらの CPU ホッグを非常に短いランタイムで実行して、正確な結果を得ることに焦点を当てます。

しかし、これらの CPU テストを読んで、このクイックハックテストがいかに間違っていて遅いかを知ってください。

dd, urandom, md5sum はベンチツールではないことに注意してください。

問題はddやそのタイミングではありません。

CPUストレスアプリケーション: time dd if=/dev/urandom bs=1M count=2 | md5sum

ベンチマークの説明:

time ... 経過時間を測定します。
dd if=/dev/urandom bs=1M count=2 ... copies bs=blocksize 1MBのランダム性を2回繰り返す
md5sum ... md5セキュリティハッシュを計算 (CPUに負荷を与える)

実行して結果を調べてみましょう。

docker container run -d --cpu-shares=1024 --name mycpu1024 alpine:3.8 /bin/sh -c 'time dd if=/dev/urandom bs=1M count=100 | md5sum'
docker container run -d --cpu-shares=500 --name mycpu500 alpine:3.8 /bin/sh -c 'time dd if=/dev/urandom bs=1M count=100 | md5sum'
docker container run -d --cpu-shares=100 --name mycpu100 alpine:3.8 /bin/sh -c 'time dd if=/dev/urandom bs=1M count=100 | md5sum'

ランタイムを判断するためにログを調査してみましょう。

docker logs mycpu1024
docker logs mycpu500
docker logs mycpu100

期待される出力：

docker logs mycpu1024
real    0m 15.29s
user    0m 0.00s
sys     0m 14.51s

docker logs mycpu500
real    0m 18.65s
user    0m 0.00s
sys     0m 15.28s

docker logs mycpu100
real    0m 23.28s
user    0m 0.00s
sys     0m 13.09s

すべてのコンテナがほぼ同じ sys cpu 時間を使用していることに注意してください。

--cpu-shares=100 は明らかに時間がかかりますが、 --cpu-shares=500 は --cpu-shares=1024 よりもわずかに遅くなります。

問題は --cpu-shares=1024 が非常に高速に動作した後に終了してしまうことです。

すると、--cpu-shares=500と--cpu-shares=100がCPUをフルに利用できるようになります。

すると--cpu-shares=500はほとんどのCPUを占有しているので、すぐに終了します。

そして、--cpu-shares=100は、ほとんどのCPUのシェアを持っているので、すぐに終了します - 他には何も動いていません。

この問題とその解決方法を考えてみてください。

これ以上読む前に解決策を考えてみてください。

そしてあなたの解決策を試してみてください。

解決策:

これら3つのコンテナはすべて常時並列に動作しなければなりません。CPUシェアはCPUがストレスを受けているときにのみ動作します。

mycpu1024 - カウントは mycpu100 の 10 倍に設定する必要があります。
mycpu500 - カウントはmycpu100の5倍に設定する必要があります。

このようにして、3つのコンテナの実行時間はほぼ同じになります - CPUシェアに基づいて、CPUシェアに応じた似たような作業量になります。

次に、mycpu1024の実行時間を10で割ってみると、mycpu100の10倍のワークロードが得られます。
そして、mycpu500のランタイムを5で割ってみると、 mycpu100の10倍のワークロードが得られました。

DockerがCPUシェアを適当に分けたのは、ごくごく当たり前のことのはずです。

忙しいDocker管理者のショートカット/クイックメソッド：

上記のコンテナを全て提出して再度実行する。
以下も実行できるように準備しておきましょう。

--cpu-shares=250 and --cpu-shares=200 containers

次に別のシェルで docker stats を実行して ctrl c を押して表示をフリーズさせます。

CPUシェアが正しく割り当てられていることは明らかです。

コンテナをクリーンアップします:

docker container prune -f

#同一に割り当て --cpu-share

--cpu-share. このフラグを設定すると、コンテナの重量を増やしたり減らしたりして、ホストマシンのCPUサイクルの割合を増やしたり減らしたりします。

これは、CPU-sharesが同じに設定されていると、CPUの占有率が同じになることを意味します。

3つのコンテナを実行していて、すべてのコンテナのCPUシェアが1024であるとします。

docker container run -d --cpu-shares=1024 --name mycpu1024a alpine:3.8 /bin/sh -c 'time dd if=/dev/urandom bs=1M count=100 | md5sum'
docker container run -d --cpu-shares=1024 --name mycpu1024b alpine:3.8 /bin/sh -c 'time dd if=/dev/urandom bs=1M count=100 | md5sum'
docker container run -d --cpu-shares=1024 --name mycpu1024c alpine:3.8 /bin/sh -c 'time dd if=/dev/urandom bs=1M count=100 | md5sum'

実行：

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
c4625617f339        mycpu1024c          63.79%              1.262MiB / 985.2MiB   0.13%               648B / 0B           1.33MB / 0B         0
44362316e33a        mycpu1024b          68.44%              1.254MiB / 985.2MiB   0.13%               648B / 0B           1.33MB / 0B         0
a704aca5c0d7        mycpu1024a          66.27%              1.254MiB / 985.2MiB   0.13%               648B / 0B           1.35MB / 0B         0

予想通り、3つのコンテナはすべて同じ割合のCPU時間を取得します。

docker logs mycpu1024a
docker logs mycpu1024b
docker logs mycpu1024c

すべてが同じ経過時間を実行したことを確認するだけです。

docker logs mycpu1024a
real    0m 21.25s
user    0m 0.00s
sys     0m 14.72s

docker logs mycpu1024b
real    0m 22.53s
user    0m 0.00s
sys     0m 15.21s

docker logs mycpu1024c
real    0m 21.45s
user    0m 0.00s
sys     0m 15.09s

プルーンコンテナ、終了です。

docker container prune -f