💬

面接で語れる：ECサイトでマイクロサービス基盤を担当していた時の実務と挑戦

に公開
Kubernetes
Terraform
IaC
中野哲平
zennfes2025free
idea

転職面接で「ECサイトでインフラ/プラットフォーム／マイクロサービスの仕事をしていた」と話すときに、説得力を持って具体的に語れるように作ったブログ記事（テンプレート）です。

以下は「面接で語るストーリー」「直面したチャレンジ」「具体的に取ったアクション」「得られた成果」を含め、聞き手がイメージしやすい形にまとめています。実際にやったことに合わせて数値や固有のツール名を差し替えて使ってください。

イントロ（話し出しの例）

「私はECサイトのプラットフォームチームに所属し、KubernetesクラスターとTerraformを中心に、RailsやGoなど多言語混在のマイクロサービスの運用・移行を担当していました。特に、モノリスからの段階的な分離と、クロスサービスのデータ整合性、可観測性の向上に注力しました。」

この冒頭で、役割（Platform / SRE / Backend Lead等）、担当範囲（クラウド、K8s、CI/CD、DB移行など）、貢献領域を簡潔に伝えます。

背景・状況（Situation）

  • プロダクト特性：EC型サービス（大量の画像、検索、レコメンド、広告など高負荷領域が混在）
  • 既存構成：Railsを中心としたモノリシックアプリが存在し、多くの機能が同一DB・同一デプロイ単位で動いていた
  • 目標：可用性と開発スピードを両立させるため、段階的にマイクロサービス化を進め、Kubernetes上での運用基盤を整備する

直面した主なチャレンジ（一覧）

  1. モノリス分割に伴うデータ所有権の整理（誰がどのテーブルを責任持つか）
  2. DBスキーマ変更とオンラインマイグレーションの安全な実行
  3. マルチランゲージ環境での通信・遅延・エラー対処（Rails⇄GoのRPC/HTTP連携）
  4. サービス間の可観測性不足（ログ/メトリクス/トレースの分散）
  5. デプロイ戦略とリリースの複雑化（DB移行を含むローリング/カナリア）
  6. 運用コストとクラスタ肥大化（コスト管理/ガバナンス）
  7. インシデント対応とナレッジの散逸（オンコール負荷、属人化）
  8. データ整合性とユーザー体験の担保（キャッシュ不整合や遅延表示）

各チャレンジに対する実践（Task → Action → Result）

以下は面接で語ると効果的な“短いストーリー（STAR）”です。立場や担当範囲に合わせて主語を調整してください。

1) データ所有権の整理

  • Task（課題）: モノリスから機能を切り出す際、どのサービスがどのデータを『正』として保持するかが未整理で、サービス間での書き込み競合や責任の不明確さが発生していた。

  • Action（対応）: ドメイン駆動設計（DDD）の観点でドメイン境界をワークショップ形式で定義。各サービスの「データオーナーシップ（canonical source）」を明文化し、API契約（OpenAPI）とイベント契約（Kafka topic schema）を定義した。

    • 具体的には「Userはuser-serviceが唯一の真（source of truth）」「Productのメタ情報はproduct-serviceが持ち、ユーザー表示情報はuser-serviceのAPI呼び出しで補完する」等。
    • 契約違反を防ぐため、CIでOpenAPIとスキーマ検証を導入した。

  • Result（成果）: サービス間の責任が明確になり、クロスサービスのバグが半分以下に削減。新サービスのオンボーディングがスムーズになり、チームの独立性が向上した。

2) DBスキーマ変更／オンラインマイグレーション

  • Task: 本番DBのスキーマ変更でダウンタイムを避けつつ、安全にカラム追加やリネーム、データ移行を行う必要があった。
  • Action: ①後方互換なスキーマ変更（カラム追加）、②アプリ側で新旧フィールドを一時的に両対応、③CDC（Change Data Capture、例: Debezium）でデータを新DBへ逐次転送、④最終フェーズで切り替え、⑤旧スキーマのクリーンアップという手順を採用した。
  • Result: サービス停止なしでスキーマ移行を完了し、ユーザー影響はゼロ。移行作業の標準化により、以後の変更が安全に実行できるようになった。

3) 言語が異なるサービス間の通信と遅延対策

  • Task: Railsで実装されたフロント系がGo実装の重い処理を呼ぶとき、レイテンシやエラー伝播でユーザー体験が悪化していた。

  • Action:

    • gRPCを導入してプロトコルを統一し、IDLで型の整合性を確保
    • タイムアウト、リトライ、サーキットブレーカーをライブラリレベルで標準化（例: Envoy + circuit breakerパターン）
    • 非同期化できる処理はキュー（Kafka）経由に変更して、ユーザー同期パスを軽くした

  • Result: 平均APIレイテンシのp95が低下し、エラーの波及が抑えられた。開発者は言語の違いを意識せずに、安全に相互通信できるようになった。

4) 可観測性の改善（ログ・メトリクス・トレース）

  • Task: 分散システムで障害の原因を突き止めるのに時間がかかっていた。

  • Action:

    • 分散トレーシング（Jaeger/Zipkin）を導入し、リクエストの全経路を可視化
    • 共通のログフォーマット（JSON）と構造化ログ、中央集約ログ基盤（ELK/Fluentd）を整備
    • PrometheusとGrafanaでサービス単位・API単位のSLO監視を導入し、アラートをSLOに基づくものにした

  • Result: Mean time to detect（MTTD）とMean time to recover（MTTR）が共に改善。インシデント後の調査時間が短縮され、サービスの信頼性が向上した。

5) デプロイ戦略の整備（DBを含むリリース）

  • Task: DBスキーマ変更を伴う機能リリースがリスクを伴っていた。

  • Action:

    • Feature Flagで段階ロールアウトを行い、Canary/Blue-Greenリリースを組み合わせた
    • データ書き込み側を先にデプロイして互換性を確保し、段階的に読み取り側を差し替える
    • ArgoCD（GitOps）でマニフェストを管理し、Terraformはインフラ変更のみを担当

  • Result: リリース失敗時のロールバックが容易になり、リリースによる障害が大幅に減少した。

6) コストとクラスタのガバナンス

  • Task: 開発チームが独自にクラスターや大きなリソースを作ることでコストが肥大化していた。

  • Action:

    • Terraformモジュールを作成し、標準的なクラスタ・ネットワーク構成を提供
    • ポリシー（ラベル付け、命名規約、リソースクォータ）をCIで検証
    • コスト可視化ツールを導入し、チームごとの利用状況をダッシュボード化

  • Result: 無秩序なリソース作成が止まり、クラウドコストの無駄削減につながった。

7) インシデント対応とナレッジ共有

  • Task: インシデント発生時の対応が属人化しており、復旧手順が曖昧だった。

  • Action:

    • Runbook（復旧手順書）を整備し、Playbookに沿ったオンコール訓練を実施
    • 全てのインシデントはBlamelessでポストモーテムを実施し、原因と対策を

Discussion