突然ローカルPCから、GCEインスタンスに接続できなくなった。

コンソールからSSH接続を試みたところ、以下のメッセージが表示されました。

Cloud Identity-Aware Proxy を介した接続に失敗しました
コード: 4003 理由: failed to connect to backend VM への接続が拒否されました。
次の点を確認してください。
- VM に、IP 範囲 x.x.x.x/20 からの TCP 上り（内向き）トラフィック（ポート: 22）を許可するファイアウォール ルールがある。
- ターゲット VM で SSH デーモンが起動されている Cloud Identity-Aware Proxy を使用せずに接続できる場合もあります。

GCEのインスタンスのページの シリアルポート 1（コンソール） 出力のログを確認

メモリ不足（OOM - Out of Memory）が発生していますというログが出力されていた

[222177.564502] Out of memory: Killed process 12405 (chrome) total-vm:1476514968kB, anon-rss:225920kB, file-rss:2648kB, shmem-rss:2304kB, UID:0 pgtables:5260kB oom_score_adj:300

VMのメモリが枯渇し、Chromeプロセスが強制終了されていたほか、メモリ不足の影響でSSHデーモンも正常に動作していなかったようです。

接続できないとこれ以上原因を調査できないため、まずはインスタンスを再起動しました。

gcloud compute instances reset <instance-name> --zone=<zone>

gcloud compute instances reset

再起動後に調査したところ、Puppeteerによるメモリリークが原因であることが分かりました。アプリケーションを修正し、問題は無事解決しました。

Claudeに聞いてみた

k8s 使ったらいい感じにできるのかな？

K8sでのPuppeteer運用は確実にメリットがありますね！現在の問題点と照らし合わせて整理してみます。

K8sでの改善ポイント

🎯 リソース制御

• ハードリミット: コンテナレベルでメモリ制限
• 現在: アプリレベルでの制限のみ

🔄 自動回復

• K8s: OOM時に自動でPod再起動
• 現在: PM2による再起動（手動介入必要な場合あり）

📊 水平スケーリング

• 適用場面: 定期スクレイピング処理
• メリット: 処理後に確実にリソース解放

2. Deployment + Serviceパターン

• 適用場面: API経由でのスクレイピング
• メリット: 負荷分散 + 可用性向上

メリット・デメリット比較

✅ K8sのメリット

1. リソース制御: コンテナレベルでの厳格な制限
2. 自動回復: OOM時の即座な再起動
3. スケーラビリティ: 負荷に応じた自動スケール
4. 監視・ログ: Prometheus + Grafana等との連携
5. デプロイ: ローリングアップデート

❌ K8sのデメリット

1. 複雑性: 運用・学習コストの増加
2. リソース: K8s自体がメモリ・CPU消費
3. オーバーヘッド: シンプルな構成には過剰

現在の構成での改善余地

e2-medium（4GB RAM）なら、K8s無しでも十分運用可能：

現在の最適化で十分な場合

• Puppeteer最適化: ✅ 実装済み（90%削減）
• プロセス監視: PM2で対応済み
• メモリ制限: アプリレベルで設定済み

提案

短期的（現在のまま）

• 現在の最適化で十分安定している
• 追加コストや複雑性なし

中長期的（K8s移行検討）

• 処理量増加時: HPA（水平スケーリング）が有効
• 可用性重視時: マルチPodでの冗長化
• 監視強化時: K8s + Prometheus/Grafana

現状の最適化で安定しているなら、まずはこのままで運用し、スケール要件が出てきたタイミングでK8s検討がおすす
めです！