Slide 1

Slide 1 text

© 2024 Wantedly, Inc. 400万ユーザー を⽀えるインフラ基盤 Wantedly TECH NIGHT 2024.5 May. 25 2024 - Atsushi Tanaka @bgpat

Slide 2

Slide 2 text

© 2024 Wantedly, Inc. 400万ユーザーに価値を届けるエンジニアを を⽀えるインフラ基盤 Wantedly TECH NIGHT 2024/5 May. 25 2024 - Atsushi Tanaka @bgpat

Slide 3

Slide 3 text

© 2024 Wantedly, Inc. $ whoami @bgpat / Atsushi Tanaka ウォンテッドリー株式会社 Infrastructure Squad Leader Infrastructure Engineer Kubernetes / Terraform SRE / Platform Engineering

Slide 4

Slide 4 text

© 2024 Wantedly, Inc. 話すこと ● ⽬指すインフラ像 ● 取り組んでいること ● 現状の課題

Slide 5

Slide 5 text

© 2024 Wantedly, Inc. Why: Wantedly のインフラの存在意義 『プロダクト開発の価値を⾼速に信頼性⾼く出⼒し続ける』 既存のプロダクト価値を絶え間なくユーザーに提供し、 プロダクト開発で⽣み出した新たな価値をできる限り早く ユーザーに届けられるようにすることがミッションです。

Slide 6

Slide 6 text

© 2024 Wantedly, Inc. What: プラットフォームの提供により価値を出す 実現するためには ● 変更しても壊れない (= 強い) システム ● 開発者がビジネスロジックに集中できる環境 の2つが必要 ⇨ ウォンテッドリーの解は「プラットフォーム」

Slide 7

Slide 7 text

© 2024 Wantedly, Inc. What: プラットフォームの提供により価値を出す インフラや開発運⽤に関わる機能とプラクティスをプラットフォームとして提供していく

Slide 8

Slide 8 text

© 2024 Wantedly, Inc. What: プラットフォームの設計⽅針 ● インフラがボトルネックにならない ○ プロダクトチームが⾃律的に動ける ● 基盤の運⽤コストを極⼒下げる ○ やりたいことの90%をカバーできる共通基盤 ○ マイクロサービスのテンプレート‧ドキュメント整備

Slide 9

Slide 9 text

© 2024 Wantedly, Inc. How: プラットフォームの構成要素 マイクロサービス前提のプラットフォーム ● Kubernetes (EKS) ● Terraform (tfaction) ● 共通ライブラリ “servicex” ● 内製ツール “kube” ● CIサービス (GitHub Actions / CircleCI / Travis CI / Bitrise) ● モニタリングサービス (Datadog / New Relic / Honeybadger)

Slide 10

Slide 10 text

© 2024 Wantedly, Inc. How: プラットフォームの構成要素 Kubernetes (EKS) ● マイクロサービス基盤として利⽤ ○ オートスケールやクラスタ内通信の機能が標準で内蔵されている ○ sidecar パターンにより基盤側で追加処理が可能 ● 開発基盤のハブとしても活⽤ ○ API 経由で操作できるため⾃動化しやすい ○ 標準機能で⾜りない部分は Custom Controller を実装 ■ kubefork ■ CronJob 通知

Slide 11

Slide 11 text

© 2024 Wantedly, Inc. How: プラットフォームの構成要素 Terraform (tfaction) ● インフラリソースをコードで管理 ○ 参照が記述できどこで利⽤されているのか⼀⽬瞭然 ○ 機械的に扱いやすいフォーマットのため⾃動化も容易 ● Terraform Module を整備することでセルフサービス化 ○ 開発者が簡単に追加できる仕組み ○ インフラはレビューするだけなので待ち時間も少ない ● GitHub と組み合わせて統制フローとしても利⽤ ○ plan 実⾏とレビューを必須にしている ○ インフラの変更経緯が追跡可能に

Slide 12

Slide 12 text

© 2024 Wantedly, Inc. How: プラットフォームの構成要素 共通ライブラリ “servicex” ● よく使う共通機能を提供 ○ サーバーのデフォルト設定や API クライアント等 ● マイクロサービスの内側に基盤の処理を埋め込む ○ 全体に共通の処理を⼊れたいときに注⼊できる場所があって便利 ○ 例: ログやエラー通知等

Slide 13

Slide 13 text

© 2024 Wantedly, Inc. How: プラットフォームの構成要素 内製ツール “kube” ● エンジニアが開発基盤を扱うためのツール ○ Kubernetes クラスタの選択と認証の機能により簡単かつ安全に操作が可能 ○ 社内ルールに沿ったデプロイフローの⾃動化を実現 ● CI でも同じコマンドを利⽤ ○ ローカル環境でも利⽤しているコマンドのため覚えることが少なくて済む ○ 1箇所の変更で全体に反映されるため常にベストプラクティスが利⽤可能

Slide 14

Slide 14 text

© 2024 Wantedly, Inc. How: プラットフォームの構成要素 CIサービス (GitHub Actions / CircleCI / Travis CI / Bitrise) ● ⾃動テスト ○ テストコードがあれば⾃動で実⾏して安全にリリースできるか確認 ● ⾃動デプロイのトリガーとしても利⽤ ○ コンテナイメージのビルドと Kubernetes へのデプロイを⾃動実⾏ ○ リリースサイクルの⾼速化に貢献

Slide 15

Slide 15 text

© 2024 Wantedly, Inc. How: プラットフォームの構成要素 モニタリングサービス (Datadog / New Relic / Honeybadger) ● リリース後に問題なく動作していることを保証 ○ servicex の機能により各サービスにメトリクスやログを送信 ○ 問題があれば Slack 等に通知してエンジニアに対応を促す ● 開発環境でも利⽤できデバッグ時に活⽤ ○ マイクロサービス内部で何が起きているのか把握するのに便利 ○ リリース前に問題に気付くことにも役⽴っている

Slide 16

Slide 16 text

© 2024 Wantedly, Inc. 課題: メンテナンスコストの増⼤ 持ち物が多すぎるため整理が必要 必要なものは⾃動化によりメンテナンスしやすく ● 3ヶ⽉毎の Kubernetes アップグレード ● 30超の k8s cluster addon 管理 ● 100超のデータベース管理 ● 類似ツールの利⽤: Datadog vs New Relic

Slide 17

Slide 17 text

© 2024 Wantedly, Inc. 課題: PDCA サイクルが回せていない メンテナンスコストの増加等により 取り組める施策に制限がある ● とりあえず試すところまではできている ● その先は他社事例のない新しい挑戦になりがち ○ 試⾏錯誤が必要なので時間もかかる

Slide 18

Slide 18 text

© 2024 Wantedly, Inc. まとめ ● 社内のエンジニアにプラットフォームを提供 ○ ビジネスロジックに集中できる環境で頻繁なリリースが可能に ○ 横展開により信頼性の⾼いサービスを⼿軽に構築 ● これからのインフラは選択と集中が鍵 ○ まずはメンテナンスコストとの戦い ○ とりあえず⼊れれば良くなる時代は終わった ○ 組織やプロダクトに合わせた最適化が次の挑戦