HTTP ロード バランサの背後に 2 つのインスタンスがあるインスタンス グループがあります。1 つのインスタンスは正常に動作しており (http 200 を返す)、もう 1 つはクラッシュしています (HTTP 要求がタイムアウト)。何が間違っているのかわかりませんが、ドキュメントによると、障害が発生したインスタンスはロード バランサから自動的に削除されるはずです。
関連するドキュメントは次のとおりです:https://cloud.google.com/compute/docs/load-balancing/health-checks 関連する段落:
ヘルス チェックが成功したとみなされるためには、バックエンドがコード 200 の有効な HTTP 応答を返し、timeoutSec 期間内に正常に接続を閉じる必要があります。インスタンスがヘルス チェックに失敗すると、通知は送信されずにグループまたはプールから削除されます。その後、ヘルス チェックに合格すると、通知なしでグループまたはプールに戻されます。
以下は、HTTP ロードバランサのバックエンドの Google Cloud Console ページに現在表示されている内容です。
私のサイトを訪問すると（http://stage2.phantomjscloud.com）私が得る時間の半分は
エラー: サーバー エラー サーバーで一時的なエラーが発生したため、リクエストを完了できませんでした。30 秒後にもう一度お試しください。
HTTP ロード バランサ (およびヘルス チェック) は障害が発生したインスタンスを明確に検出しますが、トラフィックは引き続きそのインスタンスに配信されます。
どうすれば問題を解決できますか?
答え1
ヘルスチェック マネージドインスタンスグループ VS ヘルスチェック ロードバランシング
マネージド インスタンス グループで使用されるヘルスチェックは、ロード バランシングで使用されるヘルスチェックと同じですが、動作に若干の違いがあります。ロード バランシング サービスに適用するヘルスチェックは、ロードバランサがネットワーク トラフィックの送信先を決定するのに役立ちます。これらのヘルスチェックによって Compute Engine がインスタンスを再作成することはありません。マネージド インスタンス グループに適用するヘルスチェックは、インスタンスが UNHEALTHY になった場合に、マネージド インスタンス グループにインスタンスを削除して再作成するようにプロアクティブに通知します。
大半のシナリオでは、負荷分散とマネージド インスタンス グループのモニタリングに別々のヘルスチェックを使用します。負荷分散のヘルスチェックは、インスタンスがユーザー トラフィックを受信するかどうかを判断するため、より積極的に行う必要があります。顧客がサービスに依存している可能性があるため、応答しないインスタンスをすばやく検出して、必要に応じてトラフィックをリダイレクトする必要があります。対照的に、インスタンス グループのヘルスチェックでは、Compute Engine が障害のあるインスタンスをプロアクティブに置き換えるため、ロードバランサのヘルスチェックよりも保守的なヘルスチェックを作成できます。
答え2
この種のバグはしばらく（6 か月ほど）見られなかったので、Google Cloud のバグだったと思いますが、修正されました。