> For the complete documentation index, see [llms.txt](https://docs.wantedly.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wantedly.dev/fields/infrastructure/infrastructure-history.md).

# インフラ構成の変遷

ウォンテッドリーのインフラはサービス開始から2026年現在まで大きく5つのフェーズを経て進化してきました。

![ウォンテッドリーの開発プラットフォーム変遷](/files/fBv1sdy2FX2WxdEjf5cJ)

各フェーズの技術的な転換点とその背景を紹介します。

## フェーズ 1: PaaS 依存期 （2011〜2014年）

サービス開始時、Wantedly は Heroku 上で動作していました。 当時専任のインフラエンジニアは存在せず、インフラ機能を PaaS に委ねることで少人数チームでもプロダクト開発に集中できる体制を実現していました。

## フェーズ 2: AWS への移行 （2014〜2016年）

サービス利用者が増えレイテンシー等の問題が課題となり、2014年8月に AWS への移行を実施しました。 当時の Heroku には US と EU リージョンしかなく、特にモバイル環境でのユーザー体験のボトルネックになっていました。

![Wantedly on AWS ctonight New Challenges](/files/B6UJKHGGlEL8kfpjuCMR)

AWS に移行することにはなりましたが、Heroku のビジネスロジックの実装に集中できる開発体験は気に入っていたため、2013年にリリースされたばかりの Docker を採用し自律的にデプロイできるコンテナ基盤で環境を構築しました。

* ホスティング: Amazon EC2
* コンテナランタイム: Docker
* デプロイ基盤: Heroku ライクな内製 PaaS
* OS: Ubuntu 14.04 → CoreOS（2016年2月に移行。systemd によるサービス管理）
* デプロイツール: Capistrano と SSH を組み合わせた内製デプロイツール「sap」

初めは手動でインフラリソースの管理をしていましたが、2015年5月に Terraform を導入しインフラをコードで管理できるようになりました。 これによりインフラチームに限らず全エンジニアがインフラリソースの追加や変更を GitHub の Pull Request で行える体制が整いました。

## フェーズ 3: マイクロサービス化と Kubernetes 移行 （2015〜2018年）

2015年頃、新しいサービスの開発が頻繁に行われるようになりました。 リリースにはインフラチームがサーバー等の環境構築を行う必要があり、ボトルネックとなっていることが課題となりました。 今後もサービスが増えていくことを見据え、セルフサービスでリリースできる環境への移行を検討し始めます。

Kubernetes 採用前は内製 PaaS「paus」を開発しコンテナを管理していました。 しかし、サービス数の増加に伴い、安定したリソース管理やセルフサービスでのデプロイに限界が見え始めました。

2016年11月に Kubernetes を本番導入しました。 当時利用できるマネージド Kubernetes が存在しなかったため、EC2 上に自己管理のクラスタを構築していました。 その後 kOps によるクラスタ管理に移行しています。

マイクロサービスの増加に伴い本格的なオーケストレーション基盤が必要になり、全マイクロサービスの Kubernetes 化を段階的に進め、2018年8月に移行が完了しました。

* アーキテクチャ: モノリス Rails → マイクロサービス（Go, Ruby, Python, Node.js など各チームが技術選択）
* オーケストレーション: Kubernetes（EC2 上で自己管理）
* API 設計: gRPC + Protobuf による型安全なサービス間通信
* サービス間共通基盤: servicex（2018年1月誕生）
  * 構造化ロギング、分散トレーシング、コンテキスト伝播など共通機能を提供するライブラリ群
* 設計原則: 1マイクロサービス = 1リポジトリ = 1 Kubernetes Namespace

この時期に確立した原則が現在のアーキテクチャの骨格を形成しています。

### servicex について

マイクロサービス化が進む中で、ロギング・トレーシング・認証などの横断関心事を各チームが個別実装するコストが課題になりました。 `servicex` はこれらの共通基盤を一元化し、Go/Ruby/Python/Node.js など複数言語で提供しています。

詳しくは[マイクロサービス共通ライブラリ "servicex" の紹介](/fields/the-system/servicex.md)を参照してください。

## フェーズ 4: 運用成熟・Observability 強化期（2018〜2020年）

2018年8月に全マイクロサービスの Kubernetes 移行が完了した後、プラットフォームの安定化と運用品質の向上に取り組んだ時期です。 Kubernetes クラスタと社内共通ライブラリの servicex を拡張することによりできることを増やし、改善を進めました。

### Observability の確立

マイクロサービス間の障害調査やパフォーマンス分析が難しいという課題から分散トレーシングの導入を進めました。 始めはどのサービスも成熟していなかったため、ロックインを避けるために複数の基盤を併用し、検証を進めました。

### gRPC の標準化

マイクロサービス間通信の効率化のため、gRPC をサービス間通信の標準とする方針を策定しました。 Protobuf による型安全なインターフェース定義と、言語横断のクライアント生成を整備しています。

### Kubernetes クラスタの成熟

kOps を用いたクラスタ管理の標準化を進め、バージョンアップやクラスタ再構築を安全に行える体制を構築しました。 2020年2月には Production クラスタの再構築を完了しています。

内製ツール kube-go による Kubernetes マニフェスト生成の標準化も進め、ベストプラクティスを全リポジトリに一貫して適用できるようになりました。

### デプロイの改善

Canary Release を worker process にも拡張し、リリース時の安全性を向上させました。 Canary ごとの error rate 変化を検知する仕組みも構築し、デプロイ起因の障害の早期発見につなげています。

### SLI/SLO 運用の強化

SLO は2018年頃から運用していましたが、大規模障害に気付けず被害が拡大したことが課題になりました。 システム障害への体制強化のため、SLI/SLO に対する Design Proposal を策定して運用を再整備しました。

### 主な出来事

| 時期       | 転換点                                  |
| -------- | ------------------------------------ |
| 2018年3月  | Istio (service mesh) の検証開始           |
| 2018年9月  | gRPC の最適構成の検証開始                      |
| 2019年1月  | kOps による新 Production クラスタ移行計画        |
| 2019年4月  | RailsConf 2019 で分散トレーシングの発表          |
| 2019年7月  | Canary Release を worker process にも拡張 |
| 2019年9月  | gRPC をマイクロサービス間通信のスタンダードに策定          |
| 2019年11月 | 大規模障害対応体制の強化                         |
| 2020年2月  | SLI/SLO Design Proposal の策定          |
| 2020年2月  | Production k8s クラスタの再構築完了            |

## フェーズ 5: Platform Engineering 成熟期（2020年〜現在）

運用基盤が成熟したことを受け、Developer Experience と運用安定性のさらなる向上に注力するフェーズに入りました。

### 主な出来事

| 時期       | 転換点                                         |
| -------- | ------------------------------------------- |
| 2020年4月  | **kubefork** 開発開始（PR ごとのプレビュー環境基盤）          |
| 2020年5月  | **Argo CD** の検証開始（GitOps によるデプロイ管理）         |
| 2021年5月  | **PR ごとプレビュー環境**の本番導入                       |
| 2021年7月  | **Argo CD** の本格運用開始                         |
| 2021年9月  | **kOps → EKS 移行**プロジェクト開始                   |
| 2022年6月  | **EKS** (Elastic Kubernetes Service) への移行完了 |
| 2024年12月 | 監視基盤を **Datadog に統一**（New Relic を廃止）        |

### 現在のアーキテクチャ（2025年時点）

* ハイブリッドクラウド: AWS（主要ワークロード）+ Google Cloud（データ基盤）
* EKS（Elastic Kubernetes Service）中心のマイクロサービス構成
* Terraform による統一的なリソース管理（wantedly/wantedly-terraform）
* Datadog による統一監視

### kubefork について

PR ごとに独立したプレビュー環境を自動生成するための内製基盤です。 レビュアーが実際の動作を確認できるため、レビュー品質とデプロイ安全性が向上しました。 詳しくは [Kubefork](/fields/dev-tools/fork.md) を参照してください。

| フェーズ                    | 時期         | キーテクノロジー                                   |
| ----------------------- | ---------- | ------------------------------------------ |
| PaaS 依存                 | 2011〜2014年 | Heroku                                     |
| コンテナ化                   | 2014〜2016年 | AWS, Docker, paus, Terraform               |
| マイクロサービス・K8s 化          | 2015〜2018年 | Kubernetes（EC2）, servicex                  |
| 運用成熟・Observability 強化   | 2018〜2020年 | kOps, gRPC, OpenCensus, Canary Release     |
| Platform Engineering 成熟 | 2020年〜現在   | EKS, Argo CD, kubefork, Terraform, Datadog |

## 参考資料

* [ウォンテッドリーにおける Platform Engineering (speakerdeck, bgpat, 2025)](https://speakerdeck.com/bgpat/uontetudoriniokeru-platform-engineering)
* [Docker をフル活用したインフラの紹介と成長し続けるためのインフラ戦略 (speakerdeck, dtan4, 2016)](https://speakerdeck.com/dtan4/number-abejameetup)
* [Wantedly における プロダクト、技術、組織 7年間の進化 (speakerdeck, kawasy, 2018)](https://speakerdeck.com/kawasy/wantedly-niokeru-purodakuto-ji-shu-zu-zhi-7nian-jian-falsejin-hua)
* [社内の Platform を作る取り組み (speakerdeck, koudaiii, 2016)](https://speakerdeck.com/koudaiii/number-ocif16)
* [実践！マイクロサービス (speakerdeck, awakia, 2016)](https://speakerdeck.com/awakia/shi-jian-maikurosabisu)
* [インフラ構成概要](/fields/infrastructure/infrastructure.md)
* [Infrastructure Squad](/fields/infrastructure/infrastructure-squad.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.wantedly.dev/fields/infrastructure/infrastructure-history.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.