ウォンテッドリーにおける Platform Engineering

by Atsushi Tanaka

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© 2025 Wantedly, Inc. 今日話すこと選択肢を絞る移行をやり切る小さく試す新しい仕組みが組織に馴染むかを確認するフェーズ。⼀気に導⼊しても使われないと意味がない。フィードバックを得ながら勝ち筋を探す。ユーザーがやりたいことを迷わず実現できるように選択肢を洗練させておくことが重要。プラットフォーム利⽤のハードルを低くし、使わない理由を減らす。⼀部のシステムやチームで上⼿くいった取り組みを更に広げるために既存のシステムから移⾏する。並⾏運⽤のコストは⾼いため、中途半端にはせずやり切る。ウォンテッドリーでは 2016年から Platform Engineering を実践している。総じて上手く運用できているが使われなかった仕組みも多い。過去の取り組みを振り返り「利用されるプラットフォーム」の共通点を紹介する。利用されるプラットフォームの共通点

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2025 Wantedly, Inc. ウォンテッドリーでは Infra Squad というチームで Platform Engineering を実践開発⽣産性と信頼性の両⽴を⽬指している ● "強いシステム" の実現（= Site Reliability） ● "スケーラブルな開発組織を⽀える Platform" の実現（= Developer Productivity） Infra Squad のミッション

Slide 12

Slide 12 text

© 2025 Wantedly, Inc. 2015年以前: インフラ作業がボトルネック現在: プラットフォームを通してエンジニア⾃⾝でインフラ操作なぜ Platform Engineering を採用したのかエンジニアとサービスの増加新しいエンジニアが増え新規サービスの開発が活発化インフラ構築以外で忙しく改善タスクが回せない依頼が来ると2〜4週間は⼿が離せなくなり運⽤改善の時間が取れないエンジニアにリソース管理を移譲 Kubernetes リソースは各マイクロサービスのリポジトリ内で管理 AWS リソースも Terraform Module を使って気軽に作成できる⼿順を⽤意インフラエンジニアはプラットフォームの開発運⽤に専念レビューとトラブルシューティング以外はメンテと改善活動に取り組む

Slide 13

Slide 13 text

© 2025 Wantedly, Inc. 1. AWS と Google Cloud のハイブリッドクラウドワークロードは AWS に寄せデータ基盤は BigQuery を利⽤ 2. EKS (Kubernetes) を中⼼としたマイクロサービス構成運⽤と開発を同じ環境で⾏うために EKS を利⽤ひとつのクラスタに全てのマイクロサービスをデプロイ 3. シンプルな構成セットを使いまわすコンピューティング: EKS の Deployment + Service / CronJob データストア RDB : RDS / Aurora Redis : ElastiCache Storage : S3 ネットワーク : EKS の Ingress により ALB を作成 4. リソースは Terraform で管理 1〜3のリソースは全て Terraform から作成インフラ構成の特徴

Slide 14

Slide 14 text

© 2025 Wantedly, Inc. 2011/09 サービス開始   インフラは Heroku を利用 2014/?? AWS に移行  自律的なデプロイのため Docker を採用  2015/11 マイクロサービス化を検討   k8s の採用前は内製 PaaS を開発していた  2016/11 Kubernetes 本番導⼊一つのマイクロサービスから運用開始当時は EC2 上にクラスタを構築 2018/01 共通ライブラリ “servicex” 誕⽣マイクロサービスが備えるべき機能を扱いやすい・統一的な形で提供 2018/08 全マイクロサービスの k8s 化最後のマイクロサービス移行が完了   2020/04 kube fork による開発が開始自分だけのクラスタで開発できる体験初めは特定のサービスでしか利用できなかった 2021/05 PR 毎のプレビュー環境   PR に対して fork を実行する仕組みが登場  2024/12 監視サービスを Datadog に統一  役割の被っていた New Relic を廃止  ウォンテッドリーの開発プラットフォーム変遷

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2025 Wantedly, Inc. ● まず新規サービスに導⼊して効果を計測した ○ 新規サービスの中でも影響の⼩さい単機能をマイクロサービスとして開発しデプロイした ○ 期待した効果があったので既存システムも移⾏ ● ⼀番⼤きいマイクロサービスは移⾏完了まで4年かかった ○ 2016, 2017年とチャレンジして失敗していた ○ 少しずつ課題を潰して3回⽬の2018年で完了した ○ 本番環境の前に開発/検証環境を移⾏して問題点を洗い出した ● 社内の規約を作成 ○ 例: commit 毎に git hash が tag の container image を作る 1 microservice = 1 git repository = 1 k8s namespace ○ 構成の相談はほぼなくマイクロサービスがデプロイされる ○ 後のプラットフォーム改善が進めやすくなっている事例紹介 Kubernetes 導入移行

Slide 18

Slide 18 text

© 2025 Wantedly, Inc. ● ⼀部のエンジニアから徐々に導⼊ ○ 社内でも基盤に興味のあるエンジニアから導⼊ ○ フィードバックを貰いながら徐々に改善を進めた ● 必要なシステムも徐々に導⼊ ○ Istio 導⼊に失敗し検証環境を壊したことで開発環境が誕⽣した ● kubefork を使えば楽に開発できることを周知 ○ 社内外で kubefork について伝えることに⼒を⼊れ発表やドキュメント整備を⾏った ○ 古い開発⽅法⽤のスクリプトやドキュメントは削除 ○ 開発時は kubefork を使う共通認識が形成された事例紹介 kubefork 開発導入

Slide 19

Slide 19 text

© 2025 Wantedly, Inc. ● 検索や推薦のために Elasticsearch を活⽤ ○ 全⽂検索や構造化データの検索は RDB ではやりづらい ● 運⽤環境を統⼀するため EC2 から k8s に載せ替え ○ 専⽤ツールを他のマイクロサービスと同じ kube に移⾏しメンテが楽に ○ エンジニア⾃⾝でデプロイするドキュメントも⽤意 ○ 結果インフラはレビューするだけでデプロイ可能に ● 利⽤はされているが運⽤負荷が⾼すぎる ○ ステートを持つと Pod 削除前にデータ退避が必要になり Node ⼊れ替えに時間がかかる ○ さらにマネージドサービスへの移⾏を検討中 ○ 問題は多いが移⾏元は1パターンの考慮だけでよい事例紹介 Elasticsearch 移行

Slide 20

Slide 20 text

© 2025 Wantedly, Inc. ● RDB を Terraform から作成しやすくする Module を開発 ○ k8s の次に作成されることの多いリソースだったので改善 ○ インフラがボトルネックになっていたのを解消したかった ○ 推奨設定や監視も⾃動で⼊るようにしたかった ● Module 以外の⽅法で管理されている RDB がまだ多い ○ 既存 DB の数が多かったので後回しにした ○ 既存 DB の移⾏はせず新しい DB 作成が楽になれば良いと考えた ● ドキュメントは書いたが⾒られない ○ そもそも RDB 作成の機会が少なく思い出してもらえない ○ 意図に反した⽅法で RDB が作られていて困った ■ 古い Terraform のコードをコピペして推奨設定が⼊らなかった ■ k8s 上に野良 DB を⽴てるオリジナルの⽅法でデータ移⾏ができなかった事例紹介 RDB 作成 Terraform Module

Slide 21

Slide 21 text

© 2025 Wantedly, Inc. ● 必要な機能から徐々に導⼊ ○ 共通マイクロサービスの API 処理共通化のために作られた ○ 少ない機能のうちに広く導⼊されたのでプラットフォームに必要な共通の処理を注⼊しやすかった ● ドキュメント整備により新規サービスはほぼ導⼊済み ○ マイクロサービスの作り⽅ドキュメントや Production Readiness Review チェックリストに追加 ● 古いマイクロサービスには⼊っていないことがある ○ 導⼊されていないとデバッグしづらく困る ○ ⼀部同じ処理が実装されていて競合することがある事例紹介社内共通ライブラリ “servicex” 導入

Slide 22

Slide 22 text

© 2025 Wantedly, Inc. ● ⼩さく試せたものの⽅が最終的に利⽤されている確率が⾼い ○ 試せる状況にないものは環境作りから始める必要がある ○ ⼩さく試せないものは利⽤されないリスクが⾼い ● 移⾏をやりきらないことで後で困ることが多い ○ 既存実装がドキュメント扱いされることもある ○ 移⾏はやれるときに完了させるべき ● 導⼊と移⾏だけでなく利⽤させる仕組みも必要 ○ 選択肢が減ることで開発スピードが上がる ○ 規約を作るのも効果的得られた学び

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2025 Wantedly, Inc. まとめ選択肢を絞る移行をやり切る小さく試す新しい仕組みが組織に馴染むかを確認するフェーズ。⼀気に導⼊しても使われないと意味がない。フィードバックを得ながら勝ち筋を探す。課題があっても撤退が容易で、⾜りない要素も確認できる。試せる環境がなければ作るところから。ユーザーがやりたいことを迷わず実現できるように選択肢を洗練させておくことが重要。プラットフォーム利⽤のハードルを低くし、使わない理由を減らす。使うユーザーの割合が増えることで改善効率が上がり、⾏動が集約されることで次の施策にも繋げやすくなる。⼀部のシステムやチームで上⼿くいった取り組みを更に広げるために既存のシステムから移⾏する。並⾏運⽤のコストは⾼いため、中途半端にはせずやり切る。最後までやり切ることでプラットフォーム⾃体の改善や次の移⾏が実施しやすくなる。開発者に利用されるプラットフォームに貢献している要素を 3つピックアップした。利用されているプラットフォームは改善サイクルも回しやすく、プラットフォームを開発している側にとっても扱いやすいシステムになっている。利用されるプラットフォームの共通点