Linuxコントロールグループのメモリ管理の問題がコンテナアプリケーションに影響

LinkedInのエンジニアリングチームが先日，“Don’t Let Linux Control Groups Run Uncontrolled”と題した記事を発表した。コントロールグループ(cgroup)は，DockerやCoreOSなどのプロジェクトが，プロセス毎のリソース使用量の制限に使用しているLinuxの機能だ。記事では，パフォーマンス低下につながる可能性のあるcgroupのメモリ管理のいくつかの問題と，その回避策についての概要を説明している。

cgorupは，アプリケーションが割り当て以上のリソースを使用しないことを保証する機構だが，アイソレーションを保証するものではない。オペレーティングシステムの同一インスタンスの中に複数のcgroupを実行することが可能で，RAMやCPUなど，それぞれが別のクォータセットを保持する。しかしながら，メモリ要求(記事では’メモリ圧力’と表現されている)に対するオペレーティングシステムの動作が，cgroup内で動作するアプリケーションにとって予期しない，望ましくない結果をもたらす場合があるのだ。

cgorupは，オペレーティングシステムを‘root’，その他をすべて子とする階層で構成されている。例えばDockerのコンテナは，root cgroupの子のcgroup内で実行される。

問題の概要は，プログラムが共有するメモリである‘匿名メモリ’と，プログラムデータのキャッシュを保存するためのもので，通常はハードディスクなど永続的ストレージにあり，プログラム実行時に使用される‘ページキャッシュ’に関するものとして，記事では説明されている。キャッシュはデータアクセスのスピードアップのために使用される。これら２つのメモリタイプの割り当ては，root cgroupあるいはオペレーティングシステムによって常に変更される可能性がある。

オペレーティングシステムは，メインメモリが使用可能な場合にキャッシュをRAMにロードするが，アプリケーションからの要求があると，そのメモリを回収する。回収によってページキャッシュの廃棄が行われるが，OSはcgroupの所有権設定を考慮していないため，複数のcgroupがその対象となる。これが結果として，cgroupとアプリケーションのパフォーマンス上の問題となるページキャッシュの不足につながるのだ。

cgroupのメモリ要求がページキャッシュの追い出しによって充足された場合には，また別の問題が発生する。ページキャッシュのストアに使用されているメモリは，cgroupのメモリ制限に含まれている。つまり，cgroup(Dockerの場合はコンテナ)に8GBのRAMが割り当てられているならば，その8GBはページキャッシュと匿名メモリの両方で使用されなくてはならない。このことが見落とされがちであり，パフォーマンスに対する誤った期待につながる可能性がある。

さらにOSは，メインメモリ要求がシステムの保有量を超過した場合に，メインメモリに格納されたプログラムデータをハードディスクなどの二次メモリに書き込むという，スワッピングも実行する。OSが子cgroupのユーザメモリをスワップアウトすることは，そのcgroup内で動作するアプリケーションのパフォーマンスを低下させることになる。

記事では，これら３つの問題の回避策を提案している。オンデマンドではなく起動時に必要なメモリが確実に割り当てられるように，メモリに事前にアクセスしておくことがそのひとつだ。これを正確に行なう方法はプラットフォームによって異なる。もうひとつの選択肢は，メモリ割り当てがより正確に実行できるように，アプリケーションのメモリ使用量を正しく評価することだ。ページキャッシュの使用量を予測するのは難しいが，匿名メモリについては困難ではなく，RSS(Resident Set Size)などのシステムメトリックから推定することができる。

改良されたcgroupの新バージョンがリリースされたが，これらのケースについてはまだテストされていない。