インフラ構成の変遷
ウォンテッドリーのインフラはサービス開始から2026年現在まで大きく5つのフェーズを経て進化してきました。
各フェーズの技術的な転換点とその背景を紹介します。
フェーズ 1: PaaS 依存期 （2011〜2014年）
サービス開始時、Wantedly は Heroku 上で動作していました。 当時専任のインフラエンジニアは存在せず、インフラ機能を PaaS に委ねることで少人数チームでもプロダクト開発に集中できる体制を実現していました。
フェーズ 2: AWS への移行 （2014〜2016年）
サービス利用者が増えレイテンシー等の問題が課題となり、2014年8月に AWS への移行を実施しました。 当時の Heroku には US と EU リージョンしかなく、特にモバイル環境でのユーザー体験のボトルネックになっていました。
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" の紹介を参照してください。
フェーズ 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 を参照してください。
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
参考資料
最終更新