mhKubernetesを使うと、アプリケーションの冗長化（＝同じアプリを複数動かす）がとても簡単になります。この冗長性は、障害が起きてもサービスを止めない仕組みの基本です。その中核となるのが Replica（レプリカ）数 の設計です。
✅ Replicaとは？
Replica（レプリカ）とは、Pod（アプリケーションの実行単位）を何個動かすかの数です。たとえば：
replicas: 3と指定すると、Kubernetes は同じPodを常に3つ動かし続けます。
🧠 なぜ複数必要なの？
以下のような場面を考えてみてください：
- 1つのPodが突然落ちた
- ノードが再起動された
- トラフィックが急増して負荷が上がった
→ Podが1つしかないと、すぐにサービス停止に直結します。
でも、3つあれば？
- 1つ落ちても、他の2つが生きていればサービスは継続
- Serviceが自動でトラフィックを他のPodに振り分ける
これが**冗長性（Redundancy）**の考え方です。
📦 実際のマニフェスト例
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp:latest⚖️ 適切なReplica数の考え方
冗長性を確保するには、最低でも2つ以上のReplicaが推奨されます。
| Replica数 | 冗長性 | 主な用途 |
|---|---|---|
| 1 | なし | テスト環境や単純なツール |
| 2〜3 | あり | 小規模本番サービス |
| 5以上 | 高 | 負荷分散・高可用性が必要な大規模サービス |
また、**水平オートスケーリング（HPA）**を併用すれば、負荷に応じて自動でPod数を増減することもできます（→後述章で解説）。
☁️ ノード単位の冗長性も意識しよう
冗長性を考える際、Replica数を増やすだけでは不十分なこともあります。例えば：
- Replica 3個がすべて同じノードに載っていたら、そのノードが死んだら全滅です。
Kubernetesでは、Podはなるべく異なるノードに分散配置されるようにスケジューリングされますが、より厳密にしたい場合は PodAntiAffinity などの設定を加えることもあります。
🧪 テスト方法
たとえば、Replicaが3つあるとき、1つのPodを強制削除してみてください：
kubectl delete pod myapp-xxxxx→ 数秒後にはKubernetesが自動で新しいPodを立ち上げて、常に3つになるように調整してくれます。
💡 まとめ
| ポイント | 内容 |
|---|---|
| Replica数 | 同じPodをいくつ動かすか |
| 冗長性 | Podが落ちてもサービスが継続する仕組み |
| 最低限の推奨 | 本番は2以上（1つでは片肺飛行） |
| オートスケーリング | 後述のHPAで自動化可能 |
| ノード分散 | Podが同じノードに集まりすぎないように注意 |
Replica数の設計は、サービスの安定稼働を支える第一歩です。特に本番環境では「1つ落ちても大丈夫」という設計が必須となります。シンプルな設定ですが、システム全体の信頼性を大きく左右する重要な要素です。
