Kubernetes & MLOps について気をつけるところ

## **1. Kubernetes に詳しいと印象づける発言**
### **(1) K8s の導入理由を語る**
✅ **悪い例（表面的な説明）**
> 「Kubernetesはコンテナオーケストレーションツールで、スケーラビリティや可用性を向上させます。」

✅ **良い例（実践的な説明）**
> 「私が関わったプロジェクトでは、推論APIの負荷が変動しやすく、**スケーリングの柔軟性が必要でした**。  
>  当初はEC2 Auto Scalingを試しましたが、コンテナ単位でスケールできず、**Kubernetes + KServeを導入することで最適化** しました。」

---
### **(2) スケール戦略を具体的に話す**
✅ **悪い例**
> 「KubernetesのHPA（Horizontal Pod Autoscaler）でスケールします。」

✅ **良い例**
> 「HPAでPodをスケールさせていますが、CPUベースのスケーリングでは不十分な場合がありました。  
>  そのため、**カスタムメトリクス（Prometheusベース）を導入し、推論リクエスト数に応じたスケーリング** を実装しました。」

---
### **(3) Kubernetesのデプロイ戦略を話す**
✅ **悪い例**
> 「GitHub Actionsを使ってCI/CDをしています。」

✅ **良い例**
> 「モデルの更新時に手動デプロイの負担が大きかったため、**GitHub Actions + KServe のワークフローを組み、プルリクエストのマージで自動デプロイ** する仕組みを作りました。  
>  これにより、**手動作業を80%削減** できました。」

---
### **(4) トラブルシューティング経験を語る**
✅ **悪い例**
> 「デプロイ時にエラーが出たので、調べて修正しました。」

✅ **良い例**
> 「Kubernetesでデプロイ後、**モデルの推論APIのレスポンスが遅くなる問題** が発生しました。  
>  `kubectl describe pod` で調査すると、リソース制限（CPU/GPU）が適切に設定されておらず、**ノードのスケジュールが偏っている** ことが判明しました。  
>  そこで、`requests/limits` を適切に設定し、Node Affinityを使ってGPUノードに最適化することで解決しました。」

---

## **2. MLOps に詳しいと印象づける発言**
### **(1) モデルのバージョン管理**
✅ **悪い例**
> 「MLflowを使っています。」

✅ **良い例**
> 「モデルの実験管理にMLflowを導入し、**バージョン管理を統一** しました。  
>  以前は手作業で精度のログを管理していましたが、MLflowの `log_metrics()` を使い、精度・推論速度・データセットバージョンを自動記録する仕組みにしました。」

---
### **(2) CI/CDのMLOps統合**
✅ **悪い例**
> 「モデルを更新したら自動でデプロイされます。」

✅ **良い例**
> 「CI/CDパイプラインで、**モデルの精度テストが基準値を下回った場合はデプロイを止める仕組み** を導入しました。  
>  `pytest + BLEU/ROUGE` で精度を評価し、閾値を超えた場合のみKServeにデプロイします。  
>  これにより、**精度劣化したモデルが本番環境に入らないようにしました。**」

---
### **(3) A/Bテスト・モデル評価**
✅ **悪い例**
> 「新しいモデルを試して、良ければ本番に適用します。」

✅ **良い例**
> 「Kubernetes上でA/Bテストを行うために、**Istioのトラフィックルーティングを活用** しました。  
>  具体的には、新モデルのデプロイ後、10%のリクエストを新モデルへ振り分け、Prometheusで `p95 latency` や `エラー率` を比較し、**パフォーマンスが向上していた場合のみ100%適用** しました。」

---

## **3. GitHub Actions に詳しいと印象づける発言**
### **(1) テストの自動化**
✅ **悪い例**
> 「GitHub Actionsでテストを動かしています。」

✅ **良い例**
> 「GitHub Actionsで `pytest` を使い、**推論の精度（BLEU, ROUGE）や推論速度を自動テスト** するワークフローを組みました。  
>  Pull Request作成時に `pytest` が走り、**閾値を下回ったら自動的にブロック** する仕組みを導入しました。」

---
### **(2) CI/CDの最適化**
✅ **悪い例**
> 「GitHub Actionsでデプロイを自動化しました。」

✅ **良い例**
> 「以前は `docker build` に15分以上かかっていましたが、**GitHub Actionsのキャッシュ機能（`cache@v3`）を活用し、ビルド時間を60%削減** しました。  
>  さらに、**並列ジョブを活用して `pytest` と `docker push` を同時実行** し、全体の処理時間を短縮しました。」

---

## **4. Kubernetes & MLOps について質問されたときの回答例**
### **Q1. Kubernetesでスケーリングする方法は？**
✅ **回答**
> 「用途に応じて **Horizontal Pod Autoscaler（HPA）とVertical Pod Autoscaler（VPA）** を使い分けます。  
>  例えば、LLMの推論APIでは、リクエスト数に応じてPodをスケールするHPAを利用しましたが、GPUリソースの利用最適化にはVPAも組み合わせました。」

---
### **Q2. Kubernetes上でのモデルデプロイの課題は？**
✅ **回答**
> 「LLMのデプロイでは、**推論時のGPUメモリ使用量が高くなる** ため、`requests/limits` を適切に設定する必要があります。  
>  また、複数バージョンのモデルを運用する際には、**Istioを使ったトラフィック管理** や、**KServeのマルチモデルサービング** を活用することで、リソースを最適化しました。」

---
### **Q3. CI/CDを設計するときのポイントは？**
✅ **回答**
> 「CI/CDのポイントは **テストの自動化、ビルド最適化、失敗時のロールバック** です。  
>  具体的には、**GitHub Actionsで `pytest + MLflow` による品質チェック** を組み、**KServeの`canary rollout` を活用して新モデルの段階的リリース** を行いました。」

---

## **結論**
- **経験ベースで話す（自分が何をしたか）**
- **技術用語を適切に使う（KServe, HPA, Istio, MLflow, GitHub Actionsなど）**
- **具体的な課題と解決策を話す（before → after）**

この話し方ができれば、**KubernetesやMLOpsに精通している印象を強く与えられます**。  
面接での **「実際にやっている感」** を出すために、事前に **「自分の経験 + 具体的な改善点」** を整理しておくと効果的です！