シニアDevOpsエンジニア面接質問

シニア DevOps 面接で見られること

シニア DevOps 面接では、ツール名を知っているかよりも、本番システムを運用できるかが問われます。Kubernetes 障害、Terraform State の安全性、GitOps のロールアウト、クラウドの耐障害性、セキュリティ統制、可観測性、インシデント対応について、シナリオ形式で聞かれることが多いです。

このガイドでは、何を最初に確認するか、どのリスクを下げるか、修正をどう検証するか、そして engineering・security・product にどのようにトレードオフを説明するかを練習できます。

高度な Kubernetes

1. Kubernetes のアーキテクチャと主要コンポーネントの役割について説明してください。

回答: Kubernetes は、コントロールプレーンとワーカーノードで構成されるアーキテクチャを採用しています。シニアらしい回答では、各コンポーネントと、望ましい状態がシステム内でどのように反映されるかを説明します。

コントロールプレーンコンポーネント:

API Server: Kubernetes コントロールプレーンのフロントエンドで、すべての REST リクエストを処理します。
etcd: クラスタ状態のための分散キーバリューストアです。
Scheduler: リソース要件に基づいて Pod をノードに割り当てます。
Controller Manager: コントローラプロセス（レプリケーション、エンドポイントなど）を実行します。
Cloud Controller Manager: クラウドプロバイダーの API と統合します。

ノードコンポーネント:

kubelet: コンテナが Pod で実行されていることを保証するエージェントです。
kube-proxy: Pod 通信のためのネットワークルールを維持します。
Container Runtime: コンテナを実行します（Docker、containerd、CRI-O）。

Loading diagram...

仕組み:

ユーザーは kubectl 経由でデプロイメントを送信します。
API Server が検証し、etcd に保存します。
Scheduler が Pod をノードに割り当てます。
ノード上の kubelet がコンテナを作成します。
kube-proxy がネットワークを構成します。

頻度: 非常に多い
難易度: 難しい

2. CrashLoopBackOff 状態の Pod のトラブルシューティング方法を教えてください。

回答: 体系的なデバッグアプローチ：

# 1. Pod のステータスとイベントを確認します。
kubectl describe pod <pod-name>
# 確認事項: イメージのプルエラー、リソース制限、ヘルスチェックの失敗

# 2. ログを確認します。
kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # 前のコンテナログ

# 3. リソース制約を確認します。
kubectl top pod <pod-name>
kubectl describe node <node-name>

# 4. 活性/準備プローブを確認します。
kubectl get pod <pod-name> -o yaml | grep -A 10 livenessProbe

# 5. コンテナに exec します（短時間起動する場合）。
kubectl exec -it <pod-name> -- /bin/sh

# 6. イメージを確認します。
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].image}'
docker pull <image>  # ローカルでテストします。

# 7. ConfigMap/Secret を確認します。
kubectl get configmap
kubectl get secret

# 8. デプロイメント/Pod の仕様を確認します。
kubectl get deployment <deployment-name> -o yaml

一般的な原因:

アプリケーションが起動時にクラッシュする
環境変数の欠落
正しくない活性プローブの構成
リソース不足 (OOMKilled)
イメージのプルエラー
依存関係の欠落

修正例:

# リソース制限を増やします。
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# プローブのタイミングを調整します。
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # アプリの起動時間を確保します。
  periodSeconds: 10
  failureThreshold: 3

頻度: 非常に多い
難易度: 普通

3. Kubernetes ネットワーク（Service、Ingress、Network Policy）について説明してください。

回答: Kubernetes ネットワークのレイヤー：

Service: Service 公開の種類：

# ClusterIP（内部のみ）
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort（ノード IP 経由での外部アクセス）
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer（クラウドロードバランサー）
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: HTTP/HTTPS ルーティング：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

Network Policy: Pod 間の通信を制御します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

頻度: 非常に多い
難易度: 難しい

4. Kubernetes での自動スケーリングの実装方法を説明してください。

回答: 複数の自動スケーリング戦略：

Horizontal Pod Autoscaler (HPA):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # または "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: 保留中の Pod に基づいて、クラスタサイズを自動的に調整します。

# AWS の例
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

頻度: 多い
難易度: 普通

高度な Terraform

5. Terraform の状態管理とベストプラクティスについて説明してください。

回答: Terraform の状態は、インフラストラクチャを追跡し、運用に不可欠です。

リモート状態の構成:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

状態ロック:

# 状態ロック用の DynamoDB テーブル
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

ベストプラクティス:

1. 状態ファイルを Git にコミットしない

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. 環境にワークスペースを使用する

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. 既存のリソースをインポートする

# 既存の EC2 インスタンスをインポートする
terraform import aws_instance.web i-1234567890abcdef0

# 検証
terraform plan

4. 状態操作（慎重に使用）

# 状態のリソースをリストする
terraform state list

# 特定のリソースを表示する
terraform state show aws_instance.web

# 状態のリソースを移動する
terraform state mv aws_instance.old aws_instance.new

# 状態からリソースを削除する（削除はしない）
terraform state rm aws_instance.web

5. 大幅な変更の前に状態をバックアップする

terraform state pull > backup.tfstate

頻度: 非常に多い
難易度: 難しい

6. 大規模プロジェクト向けに Terraform コードをどのように構成しますか？

回答: 保守性のためのモジュール構造：

ディレクトリ構造:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

モジュールの例:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "VPC の CIDR ブロック"
  type        = string
}

variable "environment" {
  description = "環境名"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "プライベートサブネットの CIDR ブロック"
  type        = list(string)
}

variable "availability_zones" {
  description = "アベイラビリティゾーン"
  type        = list(string)
}

variable "tags" {
  description = "共通タグ"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

モジュールの使用:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

頻度: 多い
難易度: 難しい

クラウドアーキテクチャ

7. AWS で高可用性マルチリージョンアーキテクチャを設計してください。

回答: 高可用性のためのマルチリージョンアーキテクチャ：

Loading diagram...

主要コンポーネント:

1. DNS とトラフィック管理:

# ヘルスチェック付きの Route 53
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. データベースレプリケーション:

# クロスリージョンリードレプリカ付きの RDS
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. データレプリケーション:

# S3 クロスリージョンレプリケーション
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

設計原則:

アクティブ-アクティブまたはアクティブ-パッシブ構成
ヘルスチェックによる自動フェイルオーバー
最小限の遅延でのデータレプリケーション
リージョン間の一貫したデプロイメント
両方のリージョンの監視とアラート

頻度: 多い
難易度: 難しい

GitOps と CI/CD

8. GitOps と、ArgoCD での実装方法について説明してください。

回答: GitOps は、Git を宣言型のインフラストラクチャおよびアプリケーションの信頼できる唯一の情報源として使用します。

原則:

Git での宣言的な構成
自動同期
すべての変更のバージョン管理
継続的な調整

ArgoCD の実装:

# アプリケーションマニフェスト
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

ディレクトリ構造:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

利点:

監査証跡としての Git
簡単なロールバック (git revert)
宣言的な目的の状態
自動ドリフト検出
マルチクラスタ管理

頻度: 多い
難易度: 普通

セキュリティとコンプライアンス

9. Kubernetes でセキュリティのベストプラクティスをどのように実装しますか？

回答: 多層防御セキュリティアプローチ：

1. Pod Security Standards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (ロールベースアクセス制御):

# 開発者向けのロール
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. Network Policy:

# デフォルトで全てのイングレスを拒否
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. シークレット管理:

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. イメージスキャン:

# OPA を使用したアドミッションコントローラ
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("Image %v is not from approved registry", [image])
    }

頻度: 非常に多い
難易度: 難しい

可観測性と SRE

10. 包括的な可観測性スタックを設計してください。

回答: 可観測性の 3 つの柱：メトリクス、ログ、トレース

アーキテクチャ:

Loading diagram...

1. メトリクス (Prometheus + Grafana):

# アプリのメトリクス用 ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. ログ (Loki):

# ログ収集用の Promtail 構成
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. トレーシング (Jaeger):

# アプリケーションのインストルメンテーション
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# トレーシングの設定
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# コードで使用
with tracer.start_as_current_span("process_request"):
    # ここにコードを記述します
    pass

4. アラートルール:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "高いエラー率が検出されました"
        description: "エラー率は {{ $value | humanizePercentage }} です"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "高いレイテンシが検出されました"

5. SLO 監視:

# SLO 定義
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "API リクエストは成功する必要があります"
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

頻度: 多い
難易度: 難しい

ディザスタリカバリ

11. Kubernetes クラスタのディザスタリカバリをどのように実装しますか？

回答: 包括的な DR 戦略：

1. バックアップ戦略:

# Velero バックアップスケジュール
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 毎日午前2時
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30 日

2. etcd バックアップ:

#!/bin/bash
# 自動 etcd バックアップスクリプト

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# S3 にアップロード
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# 古いバックアップをクリーンアップ
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. 復元手順:

# スナップショットから etcd を復元する
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Velero でアプリケーションを復元する
velero restore create --from-backup daily-backup-20231125
velero restore describe <restore-name>

4. マルチリージョンフェイルオーバー:

# マルチリージョンセットアップ用の Terraform
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... 構成
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... 構成
}

# Route 53 ヘルスチェックとフェイルオーバー
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. RTO/RPO ターゲット:

RTO (目標復旧時間): 1 時間未満
RPO (目標復旧時点): 15 分未満
定期的な DR 訓練 (毎月)
文書化されたランブック
可能な場合は自動フェイルオーバー

頻度: 多い
難易度: 難しい

サービスメッシュ

12. サービスメッシュアーキテクチャと、いつ使用するかを説明してください。

回答: サービスメッシュは、サービス間の通信のためのインフラストラクチャレイヤーを提供します。

コアコンポーネント:

Loading diagram...

Istio の実装:

# トラフィックルーティング用の Virtual Service
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20

# Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews

使うべき場面:

Microservices 間の通信が複雑な場合
mTLS、認可、トラフィック制御を統一したい場合
Canary release や traffic splitting を安全に行いたい場合
Service-to-service の可観測性を揃えたい場合

注意点: Service mesh は複雑性、レイテンシ、運用負荷を増やします。シニア面接では、そのコストを上回る価値がなぜあるのかを具体的に説明しましょう。

まとめ

ツールの定義だけを暗記するのではなく、本番障害をどう切り分け、どのリスクを優先し、修正をどう検証し、恒久対応につなげるかまで話せるように準備しましょう。

最新のキャリアアドバイス

シニアDevOpsエンジニア面接質問：本番システム編

シニア DevOps 面接で見られること

高度な Kubernetes

1. Kubernetes のアーキテクチャと主要コンポーネントの役割について説明してください。

2. CrashLoopBackOff 状態の Pod のトラブルシューティング方法を教えてください。

3. Kubernetes ネットワーク（Service、Ingress、Network Policy）について説明してください。

4. Kubernetes での自動スケーリングの実装方法を説明してください。

高度な Terraform

5. Terraform の状態管理とベストプラクティスについて説明してください。

6. 大規模プロジェクト向けに Terraform コードをどのように構成しますか？

クラウドアーキテクチャ

7. AWS で高可用性マルチリージョンアーキテクチャを設計してください。

GitOps と CI/CD

8. GitOps と、ArgoCD での実装方法について説明してください。

セキュリティとコンプライアンス

9. Kubernetes でセキュリティのベストプラクティスをどのように実装しますか？

可観測性と SRE

10. 包括的な可観測性スタックを設計してください。

ディザスタリカバリ

11. Kubernetes クラスタのディザスタリカバリをどのように実装しますか？

サービスメッシュ

12. サービスメッシュアーキテクチャと、いつ使用するかを説明してください。

まとめ

実際に機能する週次のキャリアのヒント

実際に機能する週次のキャリアのヒント

関連投稿

Node.jsシニアバックエンド面接質問集

Pythonシニアバックエンド開発者の面接質問

Goバックエンド開発者の面接質問：実践ガイド

次の面接は履歴書一つで決まる

この投稿を共有

50%速く採用される