当社では最近、IBM Instana Crush Detectorを導入しました。これは、Linuxカーネル4.8以上を実行しているすべてのLinuxマシンで、異なプロセス終了を自動的に検出し、報告します。IBM Instanaプラットフォームは、LinuxカーネルのExtended Berkeley Packet Filter（eBPF）機能を利用してカーネル自体にフックし、プロセスの終了をリッスンし始めます。異常終了はすべてホスト・エージェントに通知され、ホスト・エージェントは監視対象のプロセスに対して異常終了をスクリーニングして、関連のないプロセスに関するノイズを回避し、情報を上流の IBM Instana バックエンドに送信します。この機能は、インシデントのトラブルシューティングに取り組むクライアントにとって、極めて有用であることが実証されています。

Crash Detectorを使用すると、IBM Instanaソフトウェアは、クライアントのアプリケーションのパフォーマンスに影響を与えている多くの問題に関する重要なデータを提供します。現在、Crash DetectorにOut of Memory Killer（OOM Killer）イベントを追加することでこの機能を強化していますが、これはコンテナ化されたアプリケーションとの関連性から、非常に価値のある追加機能です。

クラウドでは、十分な予算があれば、無限の計算能力を自由に使えるように思うかもしれません。ただし、その計算能力は断片的に提供されます。ホスト（物理ホストと仮想ホストの両方）、コンテナ、関数には、割り当てられるメモリーの量に制限があります。

Linuxでは、OOM Killerは、他のプロセスがホストのメモリーを全体的に使い果たすのを防ぐ役割を担います。プロセスが使用可能なメモリーよりも多くのメモリーを割り当てようとすると、例えば、許可されているメモリーを超えて割り当てたメモリーの量に基づいて、全体的に最も悪いスコアを持つプロセスがOOMシグナルを受け取ります。これは基本的に、「上限を超えています。終了するか、子プロセスの一部を終了させてください。そうしないと、完全に機能しなくなります」という意味です。

OOMをトリガーするプロセスは、OOM信号を受信するプロセスではない場合があることに注意してください。最近メモリー使用量が増加していないアプリケーションでも、同じホスト上で使用しているアプリケーションが多すぎるために、突然 OOM 信号が発行されることもあります。

OOM信号の仕組みは厳しいように聞こえますが、実際には、特にアプリケーションのサイズが適切でない場合や、同時に実行しているアプリケーションの数が多すぎる場合（つまり、ホストがワークロードに対して適切にサイズ設定されていない場合）に、ホスト上のメモリー枯渇を防ぐのに非常に効果的なメカニズムです。

Kubernetes、Cloud Foundry、Nomadなどのコンテナ化されたプラットフォームでは、アプリケーションのサイズを適切に設定することと、ホスト上で一度に実行するアプリケーションの数の両方の観点から、メモリーの使用がさらに重要になります。通常、どのノードでどのアプリケーションが実行されているかを詳細に計画することはありません。多くのセットアップでは、コンテナはオーケストレーターによって何らかの論理に従って割り当てられます。最大メモリー消費を強制することは、Linux上のほぼすべてのコンテナ・テクノロジーの基盤であるコンテナとコントロール・グループ（cgroup）にとって重要です。これらは、OOM Killerシステムも使用して、同じグループ（つまり、コンテナ）で実行されているプロセスが許可されている以上のメモリーを割り当てないようにします。コンテナ内のプロセスが許可されている以上のメモリーを割り当てようとすると、一部のプロセスが終了し、コンテナもダウンしてしまうことがよくあります。

規模が大きくなると、サイズ設定を含め、すべてが難しくなります。これは、環境内で実行するコンテナの数が増えるほど、コンテナの一部がいつ、どのように、なぜダウンしたのかを把握することが難しくなるためです。OOM Killerは、常にどこかで何かがクラッシュして再起動されるという、アプリケーションにとって不健全な状況を作り出すと同時に、エンド・ユーザーに対して継続的にエラーを発生させ、サービス・レベル目標（SLO）の達成を難しくし、トラブルシューティングが非常に困難になります。

単一のプロセスがOOM Killerにより強制終了された理由を特定する方法は、使用するテクノロジーに大きく依存します。独自のログに記録されるソフトウェア・パッケージもあります。または、各ホストで次のようなコマンドを実行することになるかもしれません。

     #CentOS
     grep -i "out of memory" /var/log/messages
     #Debian / Ubuntu
     grep -i "out of memory" /var/log/kern.log

一見、平凡な作業のように見えますが、MySQLが午前3時に再びダウンした理由を解明するために、本番環境で実行したい種類のタスクではないでしょう。特に、データベース・プロセスが存在しなくなった理由を他に説明できるものがないように思われるため、「これに違いない」と、勘に頼らざるを得ない場合もあるでしょう。

言い換えれば、OOM キラーは、信頼性にとって否定できないほどの重要性と有効性を備えているにもかかわらず、十分な可観測性を提供できないシステムです。しかし、IBM Instanaプラットフォームを使えば、この問題を解決できます。

Crash Detectorを利用可能にしたeBPFをベースにして構築されたIBM Instanaソフトウェアには、すぐに使用できるOOM Killer検出器が搭載されています。プロセスがIBM Instanaソフトウェアによって監視されている場合、プロセスはリアルタイムでOOM信号を受信します。それが起こったということだけでなく、その状況がどのように解決されたか（つまり、どのプロセスが強制終了されたか）もわかります。

ほとんどのIBM Instana機能と同様、ユーザーがすべきことは、IBM Instanaホスト・エージェントをインストールして、OOM Killerがその任された役割を果たすのを待つだけです。また、イベント発生時に強制終了されたプロセスが割り当てたメモリー量も表示されるため、OOM Killerがなぜ特定のプロセスが「不良」とマークされた理由もわかります。

適切なツールがなければ、プロセスがどのように、なぜ終了したか、またはプロセスが OOM Killerによって強制終了された理由を特定するには、数時間、場合によっては数日かかることがあります。IBM Instana Crash Detectorを使用すると、ユーザーはすべての異常なプロセス終了とOOM Killerにより強制終了されたプロセスの終了理由をすぐに理解できるようになります。

コンテナが停止した理由を理解する必要がありますか。心配はいりません。IBM Instana Crash Detector OOM Killerを使用すると、重要なバッチ・ジョブを実行しているJava仮想マシン（JVM）が、許可された以上のリソースを割り当てた可能性があることがわかります。あるいは、ハイパーテキスト・プリプロセッサー（PHP）の要求が頻繁に失敗する理由や、データベースが消失した理由を特定する必要がある場合でも、IBM Instana Crash Detector OOM Killerを使用すると、これらの問題の根本原因をすぐに解明できます。

Linux OSに IBM Instanaエージェントをインストールするだけで、OOM Killerイベントのトラブルシューティングを迅速に行い、DevOpsチームの作業時間を節約できます。IBM Instanaインスタンスをまだお持ちでない場合は、無料の評価版でOOM Killer検出機能を備えたIBM Instana Crash Detectorがどのように機能するかをご確認ください。