企業のADCとWAAPプラットフォームは単一のモノリシックなプロセスから成るわけではありません。トラフィック統計を収集するworker、ネットワーク処理、firewall管理、CLIサービス、routing consoleプロセス、ログとRRDのcollectorが共に動作します。これらのプロセスの一つが静かに停止したり、誤ったリソースプロファイルで動作したりすると、問題はトラフィックプレーンの前に管理と可視性のプレーンで始まります。
従来のアプローチではプロセス監視は外部エージェントや汎用のプロセスマネージャーツールに委ねられます。これらのツールはプロセスが稼働しているかどうかを見られますが、そのプロセスのTR7内での役割、どのリソースプロファイルで動作すべきか、どのエラー状態でreloadかrestartかを判断するかは知りません。結果として監視は一般的なものにとどまり、アクションは手動になります。
マルチプロセスのNode.jsベースのシステムではリソース設定も重要です。すべてのプロセスに同じheap上限と同じスレッドプール値を与えるのは正しくありません。軽量なCLIプロセスと大量処理のRRD collectorを同じプロファイルで動作させると、リソースの浪費が生じるか、または大量処理プロセスが不十分な上限で抑圧されます。
再起動の挙動も慎重に設計されなければなりません。あまりに頻繁な再起動は根本原因を隠します。あまりに遅い再起動は障害のあるプロセスが長時間影響を及ぼすことにつながります。トラフィックを運ぶADC containerではまずsoft reloadを試行し、失敗時にはhard restart fallbackを行うべきです。
TR7 プロセス監視は、プロセスタイプ別のパフォーマンスプロファイル、ForkManagerベースの子プロセス管理、RRDベースの統計収集、soft-to-hard再起動フローにより、内部プラットフォームプロセスを運用的に制御下に保ちます。
TR7は、プロセス監視を単なる『プロセスは稼働しているか？』のチェックとしてではなく、プロセスタイプ、リソースプロファイル、再起動挙動とともに扱います。
各プロセスタイプは自身のワークロードに応じてdefault、light、heavy、worker、ioIntensiveのいずれかのプロファイルで実行されます。heap、semi-space、UVスレッドプールの設定がこのプロファイルに応じて生成されます。
RRD collectorプロセスがCPU、メモリ、ディスク、ネットワークのイベントを時系列のロジックで収集します。これらのデータは監視画面、アラームロジック、運用分析の基礎を提供します。
TR7の内部プロセスはchild processとして起動され、ForkManager registryの下で追跡されます。プロセスがクラッシュした場合、managerが再起動フローを管理でき、プロセスツリーが運用的に分離されます。
ADC統計エラーが特定のしきい値に達したとき、まずsoft reloadが試行されます。soft reloadが失敗するとhard restart fallbackによりcontainerが制御された形で再起動されます。
プロセス監視は、TR7の内部コンポーネントをプロファイルベースのリソース管理、自動再起動、中央のプロセス追跡で運用します。
TR7はdefault、light、heavy、worker、ioIntensiveの5つのパフォーマンスプロファイルを使用します。各プロファイルは異なるmax-old-space-size、max-semi-space-size、UVスレッドプールの設定を持ちます。軽量プロセスはより低いheapで動作する一方、大量処理のcollectorプロセスはより広いリソースで起動されます。このモデルは、すべてのプロセスに単一タイプの上限を与える誤りを減らします。
UV_THREADPOOL_SIZE値はシステムのCPU数に応じて計算されます。値は最小4、最大32になるよう、CPUコア数の2倍のロジックで決定されます。これは大量のI/Oを行うプロセスでスレッドプールが小さくなりすぎることを防ぎます。同時に、制御されない高い値による不要なリソース消費の発生を制限します。
Node.jsプロセスの起動時にmax-old-space-size値がプロファイルを通じて与えられます。Defaultプロファイルは1024 MB、lightとworkerプロファイルは512 MB、heavyプロファイルは2048 MB、ioIntensiveプロファイルは1024 MBのheap値で動作できます。この設定はプロセスのメモリ使用を役割に応じて制限します。大きいcollectorプロセスと小さい管理プロセスが同じメモリプロファイルに強制されません。
Semi-space値はgarbage collectionの挙動に影響する重要な動作パラメータです。Lightプロファイルで8 MB、defaultプロファイルで16 MB、heavyプロファイルで32 MBといった値を使用できます。この区別は大量のデータを処理するプロセスがより楽に動作し、軽量プロセスは小さいフットプリントで保たれることを実現します。リソース設定がプロセスタイプに応じてより予測可能になります。
rrd-collectorとrrd-websocketのようなデータ集約型プロセスはheavyプロファイルに結びつけられます。pool-stats-workerはworkerプロファイル、network-forkはioIntensiveプロファイル、frr-consoleとcli-serverはlightプロファイルで動作できます。このマッピングは運用標準を提供し、誤ったプロファイル選択のリスクを減らします。新しいプロセスが追加されたとき、どのプロファイルに結びつくかが明確に定義されます。
buildExecArgvフローが、プロセス起動時に必要なNode.js動作引数をプロファイル値から生成します。max-old-space-sizeとmax-semi-space-sizeといったパラメータが手動のコマンドライン編集に委ねられません。これはデプロイの一貫性を高めます。異なる環境が同じプロファイル定義を使用して同様の挙動を生成します。
buildEnvVarsフローが、UV_THREADPOOL_SIZEといった環境設定をプロセスプロファイルに応じて生成します。特にI/O集約型プロセスでは正しいスレッドプール値がパフォーマンスと安定性のために重要です。このアプローチはシステム管理者が各プロセスごとに個別の環境ファイルを管理する必要を減らします。リソースの挙動が中央のプロファイルモデルに結びつきます。
network_fork、firewall_fork、stat_forkといったプロセスファミリーがForkManagerインフラの下で追跡されます。各子プロセスが独立したchild processとして動作します。クラッシュや予期しない終了の場合、managerが再起動と状態更新のフローを実行できます。この構造は、内部サービスが単一のメインプロセス内で不可視のままになることを防ぎます。
プロセス管理イベントを別のログチャネルを通じて監視できます。起動、停止、エラー、再起動、internal exceptionのイベントが運用チームが確認できる形で記録されます。これらの記録は繰り返されるプロセス問題における根本原因分析を容易にします。監視が瞬間的な状態だけにとどまらず、過去の挙動も調査できます。
ADC statエラーカウンターが特定のしきい値に達したとき、システムが自動修復フローを開始できます。最初のステップはsoft reloadです。失敗時にはhard restart fallbackが適用されます。この挙動は、一時的なランタイム障害が手動対応を待たずに回復することを助けます。継続的に繰り返される状態は別途運用調査を必要とします。
プロセス監視は、プロファイル値、プロセスタイプのマッピング、UVスレッドプールの上限、fork管理、再起動挙動とともに運用されます。
Defaultプロファイルは汎用プロセス向けに1024 MBのheapと16 MBのsemi-space値で使用できます。UVスレッドプール値はCPU数に応じて計算されるデフォルト値に従います。特別なニーズが定義されないプロセス向けにバランスの取れた出発点を提供します。
Lightプロファイルは512 MBのheapと8 MBのsemi-spaceといったより低いリソース値で動作します。FRR consoleとCLI serverのような軽量プロセスに適しています。このプロファイルは不要なメモリ消費を減らします。
Heavyプロファイルは2048 MBのheapと32 MBのsemi-space値で大量処理のcollectorプロセス向けに割り当てられます。rrd-collectorとrrd-websocketのようなより多くのデータを処理するプロセスで使用できます。UVスレッドプールの上限は32まで上げられます。
Workerプロファイルは512 MBのheapでより狭く、業務重視のプロセス向けに使用されます。UVスレッドプール値は最小8でCPU数に応じて調整でき、上限はより制御された形で保たれます。pool-stats-workerのようなプロセスで選択できます。
ioIntensiveプロファイルは1024 MBのheapでI/O重視のプロセス向けに使用されます。UVスレッドプールはCPUコア数に応じて拡大され、32の上限まで上げられます。network-forkのようなネットワークとI/O重視の業務に適しています。
PROCESS_TYPE_PROFILES構造がプロセスタイプを該当するパフォーマンスプロファイルに結びつけます。rrd-collectorはheavy、pool-stats-workerはworker、network-forkはioIntensive、frr-consoleはlight、cli-serverはlightとしてマッピングできます。このマッピングは運用標準を提供します。
新機能の後にpool-stats-workerがリソース圧迫を受けている場合、プロセスプロファイルをworkerからより適切なプロファイルに移せます。heapとUVスレッドプールの値が中央のプロファイルモデルで更新されます。運用チームは個別にruntime引数を編集する必要がありません。
ADC統計エラーが特定のしきい値を超えるとTR7は自動的にsoft reloadを試行できます。soft reloadが成功すれば、トラフィックへの影響を減らしながらプロセスが回復します。失敗の場合はhard restart fallbackが適用されます。
ネットワーク運用チームはプロセス状態、システムコマンド、監視出力で関連プロセスの健全性を単一の運用フローで評価できます。network fork、firewall fork、collectorプロセスの状態がインシデント調査を加速します。
Failoverまたはメンテナンス後に、どのプロセスがいつ再起動したかを運用記録から調査できます。これらの記録は障害分析とchange managementのプロセスに利用されます。個別のプロセス再起動を全体のシステム挙動と関連づけられます。
プロファイルベースのリソース上限、自動再起動フロー、中央のプロセス可視性。お客様自身の環境でライブ構築をご案内します。