クラウドネイティブ評価即応サービス：適合性保証を備えたスケーラブルAIモニタリングのためのマイクロサービスアーキテクチャ

ステートレスマイクロサービス対モノリシック評価パイプライン

  • 主張：* 従来のAIモニタリングアーキテクチャは評価ロジックをモノリシックなデプロイメントに統合しており、スケーリングのボトルネックと統計手法間の密結合を生み出しています。クラウドネイティブ評価即応サービス（EaaS）は評価を6つの独立したKubernetesマイクロサービスに分離し、それぞれが異なる関心事をカプセル化しています。適合予測、キャリブレーション評価、ドリフト検出、公平性モニタリング、ワークフロー調整、結果永続化です。

  • 根拠と前提条件：* モノリシック評価システムは統計手法を更新するたびにパイプライン全体を再デプロイする必要があり、関心の分離原則に違反しています。ステートレスマイクロサービスは独立した水平スケーリングを可能にします。高ボリューム推論期間中に追加の適合予測ポッドをプロビジョニングでき、ドリフト検出や公平性サービスに影響を与えません。このアーキテクチャは以下を前提としています。（1）評価ロジックを明確に定義されたインターフェースを持つ疎結合関数に分解できること、（2）Kubernetesまたは同等のコンテナオーケストレーションが利用可能であること、（3）サービス間のネットワーク遅延が許容範囲内であること（サービス間呼び出しあたり500ms未満）、（4）結果ストレージが外部化され標準APIでアクセス可能であること。

  • 具体例：* 1日1000万件の予測を処理する不正検出モデルを考えます。リアルタイム公平性監査とドリフトアラートが必要です。モノリシックパイプラインはこれらのチェックを順序立てて実行し、ブロッキングI/Oと順序実行により、バッチあたり2～5秒のレイテンシを追加します。6つの並列マイクロサービスは同じバッチを約400ミリ秒で処理します。適合予測は専用ポッドを通じて非同期に予測セットを生成し、ドリフト検出はRFF近似最大平均乖離を並列に計算し、公平性ブートストラップ信頼区間は独立して実行されます。このサービスが上流の完了を待たないため、5～12倍のレイテンシ削減が達成可能です。

  • 前提条件と制限事項：* この比較は評価チェックが本当に独立しているか、統計的仮定に違反することなく並べ替え可能であることを前提としています。実際には、適合予測はキャリブレーションデータを必要とし、ハード依存を生じさせる可能性があります。400msの数値は最適なネットワーク条件と十分なポッドレプリカを前提としており、実際のパフォーマンスはクラスタ構成とリソース競合に依存します。

  • 実行可能な示唆：* 統計チェックとその依存関係をマッピングして、現在の評価インフラストラクチャを監査してください。チェックが順序立てて実行されるか、ユニットとして再デプロイされる場合は、コンテナ化されたマイクロサービスへの移行を優先してください。適合予測とキャリブレーション評価から始めてください。これらのサービスは適用範囲保証に対して最も高い投資収益率を提供し、他のサービスへの依存が最も少ないです。Kubernetesの HorizontalPodAutoscaler を設定して、集計CPU負荷ではなくキュー深度（保留中のリクエスト）に基づいてサービスを独立してスケーリングしてください。集計CPU負荷は個別サービスのボトルネックを隠す可能性があります。

モノリシック構造とマイクロサービスのレイテンシ比較を示す棒グラフ。モノリシック構造は2000～5000msの範囲で複数の処理パイプラインにおいて高いレイテンシを示し、マイクロサービスは全パイプラインで400msに統一されており、5～12.5倍のレイテンシ削減を視覚化している。

  • 図3：モノリシック vs. マイクロサービスのレイテンシ比較（1000万予測/日の処理）*

Kubernetesクラスタ内に配置された6つの独立したマイクロサービスのアーキテクチャ図。外部データソース（トレーニングデータ、本番データ、ラベルデータ）からWorkflow Orchestration Podへ入力され、4つの独立したサービスポッド（Conformal Prediction、Calibration Assessment、Drift Detection、Fairness Monitoring）に対してAPI呼び出しで並列に処理が分散される。各サービスは非同期通信で連携し、すべての結果がResult Storage Podに集約される。矢印は実線でAPI呼び出しと並列実行フロー、点線で非同期通信を表現。

  • 図2：クラウドネイティブEaaS 6マイクロサービスアーキテクチャ（Kubernetes環境での独立並列実行）*

有限標本保証対漸近仮定

  • 主張：* 古典的な統計モニタリングは漸近近似に依存し、無限キャリブレーションデータまたは大標本正規性を仮定しています。実際のデプロイメントは有限キャリブレーション分割で動作します（通常、交差検証用にK=50のランダム分割）。有限標本補正適応予測セットは、すべての分割にわたって経験的適用範囲が名目目標の1.4パーセントポイント以内に留まることを保証します。これは漸近手法に欠ける実用的保証です。

  • 根拠と前提条件：* 適合予測の周辺適用範囲保証は任意の有限標本サイズで成立します（Vovk et al., 2005）が、素朴な実装は予測セット構築時に大標本近似を適用します。特に分位数推定においてです。有限標本補正は分位数閾値を上方調整して実際のキャリブレーション集合サイズを考慮し、小規模データセットでの過度に楽観的な適用範囲主張を防ぎます。このアプローチは以下を前提としています。（1）キャリブレーションデータとテストデータが交換可能であること、（2）非適合性測度（例えば、残差の大きさ）が明確に定義されていること、（3）補正係数が理論的漸近ではなく実際のキャリブレーション集合から計算されること。

  • 具体例：* 医療画像分類器が500画像でキャリブレーションされ、名目適用範囲目標が95%です。有限標本補正なしの標準適合予測は95%の適用範囲を主張するかもしれませんが、分位数推定誤差により経験的には91%しか提供しません。有限標本補正適応予測セットは分位数閾値を約0.5～1.0パーセントポイント上方調整し、経験的に93.8%の適用範囲を提供します。これは1.4ppの許容範囲内です。臨床医は適度なキャリブレーションデータでも適用範囲保証を信頼でき、体系的な過小適用範囲のリスクを低減できます。

  • 前提条件と制限事項：* 1.4ppの許容範囲は特定の補正方法を前提としています（例えば、Mondrian適合予測またはBarber et al., 2023で説明されている適応予測セット）。異なる非適合性測度と補正スキームは異なる境界を生じさせる可能性があります。保証は周辺的に成立します（すべてのテストポイントにわたって平均化）が、条件付きではありません（特定の部分群）。これは公平性が重要なアプリケーションにとって重要な制限です。

  • 実行可能な示唆：* 適合予測サービスに有限標本補正を直ちに実装してください。50のランダムキャリブレーション/テスト分割にわたって経験的適用範囲を測定してください。いずれかの分割が名目目標から2パーセントポイント以上逸脱する場合は、キャリブレーション集合サイズを増やすか、より厳密な分位数調整を適用してください。理論的境界ではなく、本番環境で達成された実際の適用範囲を文書化してください。分割ごとおよびデータ部分群ごとに適用範囲を追跡する監視ダッシュボードを確立して、条件付き適用範囲の失敗を検出してください。

RFF近似対正確なカーネル手法によるドリフト検出

  • 主張：* 最大平均乖離（MMD）は参照分布と現在の分布のカーネル埋め込みを比較することで分布シフトを検出します。正確なMMD計算はデータサイズでO(n²)にスケーリングし、ストリーミング推論には実用的ではありません。ランダムフーリエ特徴（RFF）近似は計算複雑性をO(n)に削減しながら統計的検出力を維持し、ストリーミングデータでのリアルタイムドリフトアラートを可能にします。

  • 根拠と前提条件：* 本番システムは予測のすべてのバッチに対して二次複雑性を許容できません。RFF-MMDは小さく定量化可能な統計的精度損失と引き換えにデータサイズでの線形スケーリングを実現します。十分なランダム特徴（通常、データ次元性に応じて1000～5000）があれば、近似誤差は有限バッチに固有のサンプリングノイズと比較して無視できるようになります。このアプローチは以下を前提としています。（1）カーネルが並進不変であること（例えば、RBF、ラプラス）、（2）ランダム特徴がカーネルのフーリエ変換から抽出されること、（3）バッチサイズがサンプリングノイズが近似誤差を支配するのに十分であること。

  • 具体例：* 推奨モデルが1時間に100,000件のユーザーインタラクションを処理します。各時間バッチでの正確なMMD計算にはO(100,000²) = 100億のカーネル評価が必要で、標準計算（1秒あたり2億のカーネル評価を仮定）で約45秒かかります。2000のランダム特徴を持つRFF-MMDにはO(100,000 × 2000) = 2億の演算が必要で、約2秒で完了します。経験的検出力（合成ドリフトへの感度）は正確なMMDと比較して99%以上のままで、偽陽性率の増加は1%未満です。システムはSLA内でモデル劣化を検出しながら、コスト効率を維持します。

  • 前提条件と制限事項：* O(n)の複雑性はRFF特徴が事前計算またはキャッシュされることを前提としています。特徴をその場で計算するとオーバーヘッドが追加されます。検出力の比較はドリフトが十分に大きく検出可能であることを前提としています。非常に微妙な分布シフトはより大きな特徴セットを必要とする可能性があります。2秒の数値はGPU加速を前提としています。CPU専用実装は5～10秒を必要とする可能性があります。

  • 実行可能な示唆：* 最大本番バッチでRFF-MMDを正確なMMDに対してベンチマークしてください。正確な計算が5秒を超える場合は、2000以上のランダム特徴を持つRFF-MMDをデプロイしてください。合成ドリフト（例えば、特徴平均を0.5標準偏差シフト）を注入し、感度が正確な手法と比較して90%以上のままであることを確認して、検出力を測定してください。参照期間からベースラインMMD値を確立し、アラート閾値を履歴値の95パーセンタイルに設定してください。現在のMMDがこの閾値を超える場合は調査をトリガーしてください。

RFF近似とカーネル法の2つのドリフト検出パイプラインを比較する図。左側のRFF近似パイプラインは入力データからランダムフーリエ特徴生成、MMD計算（近似）を経て高速出力（O(nd)）に至る。右側の正確なカーネル法は入力データから完全カーネル行列計算、MMD計算（正確）を経て正確出力（O(n²)）に至る。両パイプラインはトレードオフ分析に集約され、計算複雑度と精度のトレードオフを示した後、ドリフト検出結果に統合される。

  • 図6：RFF近似 vs. 正確なカーネル法のドリフト検出フロー*

ブートストラップ信頼区間を用いた公平性モニタリング

  • 主張：* 公平性メトリクスの点推定値（人口統計的パリティ、等化オッズ、グループ内キャリブレーション）は有限標本サイズに起因する不確実性を隠しています。ブートストラップ信頼区間はこの不確実性を定量化し、統計的に有意な公平性ギャップをサンプリング成果物から区別します。EaaSはこれらの区間を人口統計的グループ全体で継続的に計算し、新しいデータが蓄積されるにつれて再計算します。

  • 根拠と前提条件：* 2パーセントポイントの人口統計的パリティギャップを示すモデルは、95%信頼区間が[−1%, 5%]である可能性があり、統計的に有意な格差がないことを示しています。逆に、1パーセントポイントのギャップで信頼区間が[0.5%, 1.5%]である場合は、体系的バイアスを示唆しています。信頼区間は誤検知（不要な再トレーニング）と見落とされた不公正（検出されない差別）の両方を防ぎます。このアプローチは以下を前提としています。（1）人口統計的グループラベルが正確で利用可能であること、（2）ブートストラップ再サンプリング手順がグループごとに層化されてグループサイズを維持すること、（3）公平性メトリクスが明確に定義され解釈可能であること。

  • 具体例：* ローン提供モデルが3つの人口統計的グループに承認率68%、70%、72%でサービスを提供しています。点推定値だけでは不公正を示唆しています。ブートストラップ信頼区間（1000回の再サンプル、グループごとに層化）は以下を明らかにします。グループ1 [66%, 70%]、グループ2 [68%, 72%]、グループ3 [70%, 74%]。区間は実質的に重なり、承認率に統計的に有意な差がないことを示しています。チームは不要な再トレーニングを回避しながら継続的なモニタリングを維持します。同じモデルが後にグループ1 [64%, 68%]、グループ2 [70%, 74%]、グループ3 [72%, 76%]を示す場合、重ならない区間は調査を保証する本当の公平性懸念を示唆しています。

  • 前提条件と制限事項：* ブートストラップ信頼区間は経験分布が真の母集団分布を近似することを前提としており、十分なグループサイズが必要です（通常、グループあたり100以上のサンプル）。非常に小さいグループの場合、正確な二項信頼区間がより適切である可能性があります。区間は周辺的です（グループごとに独立して計算）し、複数比較を考慮しません。ボンフェローニ補正を適用すると、区間はさらに広がります。

  • 実行可能な示唆：* ブートストラップ公平性モニタリングを評価パイプラインに統合してください。アラート閾値を下側信頼限界に設定してください。いずれかのグループの下側CI限界が公平性目標（例えば、最大承認率の95%）を下回る場合は調査をトリガーしてください。区間を毎日再計算してください。信頼帯が時間とともに狭くなるか（安定した信頼できる推定値を示唆）または広がるか（データ品質問題またはグループサイズ変動を示唆）を追跡してください。信頼できる区間推定に必要な最小グループサイズを文書化し、このしきい値を下回るグループをモニタリングから除外してください。

DAGベースのオーケストレーションとステートレス結果ストレージ

  • 主張：* 評価ワークフローは明示的な依存関係を含みます。キャリブレーションは適合予測の前に完了する必要があります。ドリフト検出は前の期間からの参照データを必要とします。有向非環グラフ（DAG）ベースのオーケストレーター（例えば、Apache Airflow、Argo Workflows）はこれらの依存関係を形式化し、可能な限り並列実行を可能にし、競合状態を防ぎます。ステートレス結果APIはストレージと計算を分離し、サービスがデータ損失なく再起動でき、調整オーバーヘッドなく水平にスケーリングできます。

  • 根拠と前提条件：* 明示的なDAGはアプリケーションコードに埋め込まれた暗黙的で誤りやすい順序付けロジックを置き換えます。ステートレスストレージは評価サービスがローカル状態を維持しないことを意味します。すべての結果はクラウドオブジェクトストレージ（S3、GCS、Azure Blob Storage）によってサポートされるREST APIを通じて流れます。このアーキテクチャは以下を前提としています。（1）すべての評価段階がDAGのノードとして表現でき、明示的な入出力依存関係があること、（2）結果ストレージが外部化され標準APIでアクセス可能であること、（3）ストレージへのネットワーク遅延が許容範囲内であること（読み取り100ms未満、書き込み500ms未満）、（4）オーケストレーターがサービス障害を検出して復旧できること。

  • 具体例：* 本番評価ワークフローは12段階で構成されます。データ取り込み、キャリブレーション集合準備、適合予測、ドリフト検出、公平性モニタリング、モデルパフォーマンス評価、アラート生成、結果永続化。DAG分析は公平性モニタリングとドリフト検出が独立していることを明らかにします。どちらも他方の出力に依存しません。これらの段階は並列に実行され、適合予測はキャリブレーション完了を待ちます。順序実行は45秒かかります。2つの独立した段階を持つ並列実行は壁時計時間を28秒に削減します。2番目の適合予測ポッドを追加する（キャリブレーションがボトルネックの場合）と、時間をさらに22秒に削減します。

  • 前提条件と制限事項：* 45秒と28秒の数値は各段階が5秒かかることを前提としています。実際の時間はデータボリュームと計算リソースに依存します。DAG表現は依存関係が決定論的であることを前提としています。段階の出力が実行時条件に依存する場合、DAGは条件付き分岐に対応するのに十分な柔軟性を持つ必要があります。

  • 実行可能な示唆：* 評価ワークフローをDAGとしてマッピングし、各段階とその依存関係を文書化してください。DAG可視化ツールを使用して、クリティカルパス（最長の依存段階チェーン）と並列化可能なタスクを特定してください。軽量なオーケストレーターをデプロイしてください。Kubernetes上のArgo Workflowsは本番対応で、クラウドストレージとよく統合されます。すべての結果をオブジェクトストレージに外部化してください。シンプルなREST API経由で（例えば、S3操作をラップするPython Flaskサービス）。サービス再起動シナリオをテストして、ステートレス性を確認してください。実行中のサービスポッドを強制終了し、結果が失われず、オーケストレーターが正常に復旧することを確認してください。

DAGベースのワークフロー編成図。入力データから3つの並列タスク（Conformal Prediction、Drift Detection、Fairness Monitoring）が同時実行され、検証ステップで統合される。合格時は結果集約、不合格時はアラート生成へ分岐し、両経路とも結果ストレージに出力される。最終的にダッシュボードに表示される一連のフロー。

  • 図10：DAGベースのワークフロー編成と依存関係*

実装リスクと軽減策

分散評価は新しい障害モード を導入します。マイクロサービス間のネットワーク遅延、結果ストレージの結果整合性、負荷スパイク中のカスケード タイムアウト。軽減にはサーキットブレーカー、キャッシング、グレースフルデグラデーションが必要です。

単一の遅い適合予測サービスはオーケストレーションをブロックできます。サーキットブレーカー（Nタイムアウト後に高速失敗）はカスケード遅延を防ぎます。最近のキャリブレーションデータのローカルキャッシングはストレージAPI呼び出しを削減します。グレースフルデグラデーション（サービス障害時に最後の既知の良好な結果を返す）はインシデント中もモニタリングを運用可能に保ちます。

トラフィックスパイク中、ドリフト検出サービスは10秒のレイテンシを経験します。軽減なしでは、オーケストレーションは30秒後にタイムアウトし、すべての評価を停止します。サーキットブレーカー（3秒後に失敗）を使用すると、オーケストレーターはドリフト検出を利用不可としてマークし、前の時間の参照分布をキャッシュし、15秒で完了します。アラートはドリフト検出が低下していることを記録しますが、他のメトリクスは最新のままです。

  • これを運用化するには：* オーケストレーターにサーキットブレーカーを実装してください。サービスあたり3～5秒のタイムアウト。キャリブレーションデータと参照分布をローカルにキャッシュしてください。1～4時間ごとに更新。グレースフルデグラデーション方針を定義してください。インシデント中にどのメトリクスがオプションですか。本番ロールアウト前にステージングで障害シナリオをテストしてください。

測定と次のステップ

運用化の成功には3つの次元の測定が必要です。適用範囲精度（経験的対名目）、レイテンシ（評価サイクルあたりの壁時計時間）、コスト（予測あたりの計算とストレージ）。

適用範囲精度は統計的保証を検証します。レイテンシは評価が同期的に実行できるか（推論をブロック）または非同期である必要があるかを決定します。コストはROIを駆動します。EaaSは推論インフラストラクチャの5%未満のコストであるべきです。

ベースライン比較は目標状態を示しています。モノリシックパイプライン：95%名目適用範囲（経験的92%）、60秒レイテンシ、100万予測あたり$0.08。EaaS目標：95%名目適用範囲（経験的94.2%）、20秒レイテンシ、100万予測あたり$0.04。毎週測定してください。サービスレプリカ数とキャッシング方針を調整して目標に達してください。

  • これを運用化するには：* 適用範囲、レイテンシ、コストの監視ダッシュボードを確立してください。SLOを設定してください。94%以上の経験的適用範囲、30秒未満の評価レイテンシ、100万予測あたり$0.05未満。毎週レビューを実行してください。リソース割り当てを反復してください。4週間後、EaaSを追加モデルに拡張するか、さらに最適化するかを決定してください。

測定・検証・運用ガバナンスの4段階フィードバックループを示す図。(1)メトリクス収集ステップでレイテンシ・スループット・カバレッジを収集し、(2)検証ステップでSLA達成度と統計的保証を確認し、(3)ガバナンスステップでポリシー適用とアラート設定を行い、(4)改善ステップでチューニングとスケーリングを実施した後、再び(1)へ戻るサイクルを表現している。

  • 図14：測定・検証・運用ガバナンスのフィードバックループ*

実装上のリスクと緩和戦略

  • 主張：* 分散評価は、モノリシックシステムには存在しないマイクロサービス間のネットワークレイテンシ、結果ストレージにおける結果整合性、負荷スパイク時のカスケード的タイムアウトといった新たな障害モードをもたらします。緩和にはサーキットブレーカー、ローカルキャッシング、グレースフルデグラデーション方針が必要です。

  • 根拠と前提条件：* 単一の低速またはレスポンスしないコンフォーマル予測サービスが、オーケストレーションパイプライン全体をブロックし、タイムアウトと監視の停止を引き起こす可能性があります。サーキットブレーカー（N回連続のタイムアウト後に高速で失敗）は、サービスを利用不可としてマークし、それをバイパスすることでカスケード的遅延を防ぎます。最近のキャリブレーションデータと参照分布のローカルキャッシングは、ストレージAPI呼び出しとレイテンシを削減します。グレースフルデグラデーション（サービス障害時に最後に既知の良好な結果を返す）は、インシデント中も監視を運用可能に保ちますが、鮮度は低下します。このアプローチは以下を前提とします。（1）サービスが明確に定義されたタイムアウト閾値を持つこと。（2）キャッシュされたデータが定期的に更新されること。（3）単一の評価ステージを欠落させることの影響が許容可能であること（例えば、1サイクルのドリフト検出をスキップすることは、すべての監視を停止するよりも望ましい）。

  • 具体例：* トラフィックスパイク中、ドリフト検出サービスはリソース競合により10秒のレイテンシを経験します。緩和がない場合、オーケストレーターはドリフト検出の完了を30秒間待機します。タイムアウトした場合、評価パイプライン全体が失敗します。3回連続のタイムアウト後に失敗するように設定されたサーキットブレーカー（合計9秒）を使用すると、オーケストレーターは9秒後にドリフト検出を利用不可としてマークし、ローカルキャッシュから過去1時間の参照分布を取得し、15秒で評価を完了します。アラートはドリフト検出が低下していることを示しますが、他のメトリクス（コンフォーマル予測、公平性監視）は最新のままです。トラフィックスパイクが減少し、ドリフト検出が回復すると、サーキットブレーカーは自動的にリセットされます。

  • 前提条件と制限事項：* サーキットブレーカーはトレードオフをもたらします。カスケード障害を防ぎますが、注意深く監視されない場合、根本的な問題をマスクする可能性があります。キャッシュされたデータは古くなります。キャッシュが十分な頻度で更新されない場合、ドリフト検出は真の分布シフトを見落とす可能性があります。グレースフルデグラデーションには、どのメトリクスがオプションでどれが重要かを定義する必要があります。この決定はドメイン固有であり、時間とともに変わる可能性があります。

  • 実行可能な示唆：* オーケストレーターにサーキットブレーカーを実装します。サービスごとに3～5秒のタイムアウト、成功した呼び出しが60秒続いた後の自動リセットを設定します。キャリブレーションデータと参照分布をローカルにキャッシングします。データボラティリティに応じて1～4時間ごとに更新します。グレースフルデグラデーション方針を定義します。インシデント中にどのメトリクスがオプションでどれが重要かをドキュメント化します。オプションメトリクスについては、古さを示すタイムスタンプとともに最後に既知の良好な値を返します。ステージング環境で障害シナリオをテストします。ネットワークレイテンシ、サービスクラッシュ、ストレージ利用不可をシミュレートします。オーケストレーターが適切に回復し、監視が低下した機能で継続することを検証します。

測定、検証、運用ガバナンス

  • 主張：* 運用化の成功には、3つの次元の測定が必要です。カバレッジ精度（経験的対公称）、レイテンシ（評価サイクルあたりの経過時間）、コスト（予測あたりの計算とストレージ）です。各次元のサービスレベル目標（SLO）を確立することで、システムがビジネス要件を満たし、データ駆動型の最適化決定を可能にします。

  • 根拠と前提条件：* カバレッジ精度は、統計的保証が理論だけでなく実践でも成立することを検証します。レイテンシは、評価が同期的に実行できるか（推論をブロック）、または非同期である必要があるか（事後分析）を決定します。コストはROIを駆動します。EaaSは、運用複雑性を正当化するために、推論インフラストラクチャ総コストの5%未満を消費する必要があります。このアプローチは以下を前提とします。（1）メトリクスが継続的に収集および集約されること。（2）SLOが利害関係者（データサイエンティスト、MLエンジニア、ビジネスチーム）と協議して定義されること。（3）システムが週単位で監視され、反復的に調整されること。

  • 具体例：* ベースラインシステム（モノリシックパイプライン）：95%公称カバレッジ（経験的92%）、評価サイクルあたり60秒のレイテンシ、100万予測あたり0.08ドル。EaaS移行後の目標：95%公称カバレッジ（経験的94.2%）、20秒のレイテンシ、100万予測あたり0.04ドル。週単位で測定します。50のランダム分割全体で経験的カバレッジを収集し、各評価サイクルの経過時間を記録し、計算時間とストレージ消費に基づいて予測あたりのコストを計算します。4週間後、目標と比較します。レイテンシが30秒を超える場合、クリティカルパスサービスのポッドレプリカを増やします。コストが超過する場合