Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ウォンテッドリーにおける Platform Engineering
Search
Atsushi Tanaka
April 07, 2025
Technology
0
320
ウォンテッドリーにおける Platform Engineering
Platform Engineering Meetup #12
https://platformengineering.connpass.com/event/348986/
Atsushi Tanaka
April 07, 2025
Tweet
Share
More Decks by Atsushi Tanaka
See All by Atsushi Tanaka
Wantedly での Datadog 活用事例
bgpat
2
4.7k
KubernetesでDatadogを飼うならオートディスカバリーを使わないと損
bgpat
2
720
マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由
bgpat
12
3.3k
400万ユーザーに価値を届けるエンジニアを を支えるインフラ基盤
bgpat
3
420
Ruby製社内ツールのGo移行
bgpat
2
640
導入から5年が経って見えた Datadog APM 運用の課題
bgpat
3
1.3k
取っていてよかった Kubernetes のバックアップ
bgpat
1
720
Terraform と Kubernetes の共存による IaC の実践
bgpat
0
2k
Kubernetes Cluster Migration
bgpat
4
4.7k
Other Decks in Technology
See All in Technology
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
200
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
940
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
2
270
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
240
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
1
950
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
0
800
Geminiとv0による高速プロトタイピング
shinya337
0
200
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
1.3k
Node-REDのFunctionノードでMCPサーバーの実装を試してみた / Node-RED × MCP 勉強会 vol.1
you
PRO
0
130
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
5
590
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
0
320
ハッカソン by 生成AIハッカソンvol.05
1ftseabass
PRO
0
150
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Building Applications with DynamoDB
mza
95
6.5k
Practical Orchestrator
shlominoach
188
11k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Fireside Chat
paigeccino
37
3.5k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
GraphQLとの向き合い方2022年版
quramy
49
14k
Designing for Performance
lara
609
69k
Transcript
© 2025 Wantedly, Inc. ウォンテッドリーにおける Platform Engineering Platform Engineering Meetup
#12 Apr.7 2025 - Atsushi Tanaka @bgpat
© 2025 Wantedly, Inc. ⽥中 篤志 Atsushi Tanaka 2018年にインフラエンジニアとして新卒で入社。 2024年からインフラ領域のリーダーを担当。
趣味はバイクと日本酒とスキー ウォンテッドリー株式会社 Infra Squad Leader 自己紹介 bgpat bgpat_
© 2025 Wantedly, Inc. 今日話すこと 選択肢を絞る 移行をやり切る 小さく試す 新しい仕組みが組織に馴染むかを 確認するフェーズ。⼀気に導⼊し
ても使われないと意味がない。 フィードバックを得ながら勝ち筋 を探す。 ユーザーがやりたいことを迷わず 実現できるように選択肢を洗練さ せておくことが重要。プラット フォーム利⽤のハードルを低く し、使わない理由を減らす。 ⼀部のシステムやチームで上⼿く いった取り組みを更に広げるため に既存のシステムから移⾏する。 並⾏運⽤のコストは⾼いため、中 途半端にはせずやり切る。 ウォンテッドリーでは 2016年から Platform Engineering を実践している。 総じて上手く運用できているが使われなかった仕組みも多い。 過去の取り組みを振り返り「利用されるプラットフォーム」の共通点を紹介する。 利用されるプラットフォームの共通点
© 2025 Wantedly, Inc. Agenda 01 ウォンテッドリーについて 02 ウォンテッドリーの開発プラットフォーム 03
成功/失敗例の紹介 04 まとめ
© 2025 Wantedly, Inc. ウォンテッドリーについて 01
© 2025 Wantedly, Inc. ミッション ウォンテッドリーは、⾃律‧共感‧挑戦のある適材適所を、 ⼀時的でも、局所的でもなく、構造的に⽣み出し続けることによって、 あらゆる⼈がシゴトに没頭し成果を上げ、その結果成⻑を実感できるような 「はたらくすべての⼈のインフラ」を構築していきます。
究極の適材適所により シゴトでココロオドル ひとをふやす
© 2025 Wantedly, Inc. 提供サービス ATS 採⽤サービス 福利厚⽣ マネジメントツール 社内報
© 2025 Wantedly, Inc. 1. 400万⼈のユーザーと4万社が利⽤ toC と toB の両⽅でサービスを展開
2. 少数精鋭 社員約120名のうちエンジニアが約50名 3. 裁量が多く⾃律的な⾏動を推奨 ≠ 与えられた仕事だけをこなす プロダクトと開発組織の特徴
© 2025 Wantedly, Inc. アーキテクチャ
© 2025 Wantedly, Inc. Platform Engineering の取り組み 02
© 2025 Wantedly, Inc. ウォンテッドリーでは Infra Squad という チームで Platform
Engineering を実践 開発⽣産性と信頼性の両⽴を⽬指している • "強いシステム" の実現(= Site Reliability) • "スケーラブルな開発組織を⽀える Platform" の実現(= Developer Productivity) Infra Squad のミッション
© 2025 Wantedly, Inc. 2015年以前: インフラ作業がボトルネック 現在: プラットフォームを通して エンジニア⾃⾝でインフラ操作 なぜ
Platform Engineering を採用したのか エンジニアとサービスの増加 新しいエンジニアが増え新規サービスの開発が活発化 インフラ構築以外で忙しく改善タスクが回せない 依頼が来ると2〜4週間は⼿が離せなくなり運⽤改善の時間が取れない エンジニアにリソース管理を移譲 Kubernetes リソースは各マイクロサービスのリポジトリ内で管理 AWS リソースも Terraform Module を使って気軽に作成できる⼿順を⽤意 インフラエンジニアはプラットフォームの開発運⽤に専念 レビューとトラブルシューティング以外はメンテと改善活動に取り組む
© 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 から作成 インフラ構成の特徴
© 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 を廃止 ウォンテッドリーの開発プラットフォーム変遷
© 2025 Wantedly, Inc. 取り組みの事例紹介と学び 03
© 2025 Wantedly, Inc. • Kubernetes 導⼊移⾏ • kubefork 開発導⼊
• Elasticsearch 移⾏ • RDB 作成 Terraform Module • 社内共通ライブラリ “servicex” 導⼊ 今日紹介する事例
© 2025 Wantedly, Inc. • まず新規サービスに導⼊して効果を計測した ◦ 新規サービスの中でも影響の⼩さい単機能を マイクロサービスとして開発しデプロイした ◦
期待した効果があったので既存システムも移⾏ • ⼀番⼤きいマイクロサービスは移⾏完了まで4年かかった ◦ 2016, 2017年とチャレンジして失敗していた ◦ 少しずつ課題を潰して3回⽬の2018年で完了した ◦ 本番環境の前に開発/検証環境を移⾏して問題点を洗い出した • 社内の規約を作成 ◦ 例: commit 毎に git hash が tag の container image を作る 1 microservice = 1 git repository = 1 k8s namespace ◦ 構成の相談はほぼなくマイクロサービスがデプロイされる ◦ 後のプラットフォーム改善が進めやすくなっている 事例紹介 Kubernetes 導入移行
© 2025 Wantedly, Inc. • ⼀部のエンジニアから徐々に導⼊ ◦ 社内でも基盤に興味のあるエンジニアから導⼊ ◦ フィードバックを貰いながら徐々に改善を進めた
• 必要なシステムも徐々に導⼊ ◦ Istio 導⼊に失敗し検証環境を壊したことで 開発環境が誕⽣した • kubefork を使えば楽に開発できることを周知 ◦ 社内外で kubefork について伝えることに⼒を⼊れ 発表やドキュメント整備を⾏った ◦ 古い開発⽅法⽤のスクリプトやドキュメントは削除 ◦ 開発時は kubefork を使う共通認識が形成された 事例紹介 kubefork 開発導入
© 2025 Wantedly, Inc. • 検索や推薦のために Elasticsearch を活⽤ ◦ 全⽂検索や構造化データの検索は
RDB ではやりづらい • 運⽤環境を統⼀するため EC2 から k8s に載せ替え ◦ 専⽤ツールを他のマイクロサービスと同じ kube に移⾏しメンテが楽に ◦ エンジニア⾃⾝でデプロイするドキュメントも⽤意 ◦ 結果インフラはレビューするだけでデプロイ可能に • 利⽤はされているが運⽤負荷が⾼すぎる ◦ ステートを持つと Pod 削除前にデータ退避が必要になり Node ⼊れ替えに時間がかかる ◦ さらにマネージドサービスへの移⾏を検討中 ◦ 問題は多いが移⾏元は1パターンの考慮だけでよい 事例紹介 Elasticsearch 移行
© 2025 Wantedly, Inc. • RDB を Terraform から作成しやすくする Module
を開発 ◦ k8s の次に作成されることの多いリソースだったので改善 ◦ インフラがボトルネックになっていたのを解消したかった ◦ 推奨設定や監視も⾃動で⼊るようにしたかった • Module 以外の⽅法で管理されている RDB がまだ多い ◦ 既存 DB の数が多かったので後回しにした ◦ 既存 DB の移⾏はせず新しい DB 作成が楽になれば良いと考えた • ドキュメントは書いたが⾒られない ◦ そもそも RDB 作成の機会が少なく思い出してもらえない ◦ 意図に反した⽅法で RDB が作られていて困った ▪ 古い Terraform のコードをコピペして推奨設定が⼊らなかった ▪ k8s 上に野良 DB を⽴てるオリジナルの⽅法でデータ移⾏ができなかった 事例紹介 RDB 作成 Terraform Module
© 2025 Wantedly, Inc. • 必要な機能から徐々に導⼊ ◦ 共通マイクロサービスの API 処理共通化のために作られた
◦ 少ない機能のうちに広く導⼊されたので プラットフォームに必要な共通の処理を注⼊しやすかった • ドキュメント整備により新規サービスはほぼ導⼊済み ◦ マイクロサービスの作り⽅ドキュメントや Production Readiness Review チェックリストに追加 • 古いマイクロサービスには⼊っていないことがある ◦ 導⼊されていないとデバッグしづらく困る ◦ ⼀部同じ処理が実装されていて競合することがある 事例紹介 社内共通ライブラリ “servicex” 導入
© 2025 Wantedly, Inc. • ⼩さく試せたものの⽅が最終的に利⽤されている確率が⾼い ◦ 試せる状況にないものは環境作りから始める必要がある ◦ ⼩さく試せないものは利⽤されないリスクが⾼い
• 移⾏をやりきらないことで後で困ることが多い ◦ 既存実装がドキュメント扱いされることもある ◦ 移⾏はやれるときに完了させるべき • 導⼊と移⾏だけでなく利⽤させる仕組みも必要 ◦ 選択肢が減ることで開発スピードが上がる ◦ 規約を作るのも効果的 得られた学び
© 2025 Wantedly, Inc. まとめ 04
© 2025 Wantedly, Inc. まとめ 選択肢を絞る 移行をやり切る 小さく試す 新しい仕組みが組織に馴染むかを 確認するフェーズ。⼀気に導⼊し
ても使われないと意味がない。 フィードバックを得ながら勝ち筋 を探す。 課題があっても撤退が容易で、⾜ りない要素も確認できる。 試せる環境がなければ作るところ から。 ユーザーがやりたいことを迷わず 実現できるように選択肢を洗練さ せておくことが重要。プラット フォーム利⽤のハードルを低く し、使わない理由を減らす。 使うユーザーの割合が増えること で改善効率が上がり、⾏動が集約 されることで次の施策にも繋げや すくなる。 ⼀部のシステムやチームで上⼿く いった取り組みを更に広げるため に既存のシステムから移⾏する。 並⾏運⽤のコストは⾼いため、中 途半端にはせずやり切る。 最後までやり切ることでプラット フォーム⾃体の改善や次の移⾏が 実施しやすくなる。 開発者に利用されるプラットフォームに貢献している要素を 3つピックアップした。 利用されているプラットフォームは改善サイクルも回しやすく、プラットフォームを開発して いる側にとっても扱いやすいシステムになっている。 利用されるプラットフォームの共通点
© 2025 Wantedly, Inc.