ヤプリ新卒SREの オンボーディング

Yappli Tech Conference 2024 にて表題タイトルで登壇した際の資料です。
24新卒でSREとして入社した眞田( https://x.com/ma_rururu12 )が、「ヤプリの新卒エンジニアとは？」「新卒SREってどんな感じ？」といった内容を発表しました！

Transcript

1. Yappli Tech Conference 202 2024.10.17 ヤプリ新卒SREの オンボーディング
2. Speaker 開発統括本部 プロダクト開発本部 開発3部 SREグループ 眞⽥ 将希 • 2024年にヤプリに新卒SRE⼊社 • ⾼専在学後, ⾼専専攻科‧⼤学院へと進学 • 元々ネットワークやプログラミングに興味があり, インフラやAWSを触るようになった • 好きな分野はCI/CD
3. 本⽇お伝えすること ✅ ヤプリの新卒エンジニアってどんな感じ？ • 成⻑環境、他社との違い → ヤプリに新卒⼊社した場合の解像度をUP！ ✅ 新卒でSREってどんな感じ？ • 新卒SREの事例はまだまだ少ない → ヤプリの場合をご紹介！
4. ⽬次 1. 新卒の過ごし⽅ 2. SREとして取り組んだこと 3. ⼊社からこれまで振り返って 4. まとめ
5. 新卒の過ごし⽅
6. ヤプリ新卒の⼊社前（⾃分の場合） • 就活時 ◦ 1ヶ⽉のインターンを実施 ▪ SREでSentry改善に取り組む • https://tech.yappli.io/entry/sre-intern-sentry-replace • 内定後 ◦ 内定時に配属先はSREに決定 ◦ 内定者インターン（任意参加） ◦ 内定者研修 → 内定者同⼠仲良くなれる 01 新卒の過ごし⽅
7. • 「BootCamp」と呼ばれる研修 ◦ ⼊社して3ヶ⽉間、新卒が各部署での業務を経験する ◦ 実際に展⽰会や商談の同席する ◦ Yappliが売られる → 運⽤までの流れを⼀通り体験する ヤプリならではの研修プログラム 01 新卒の過ごし⽅
8. BootCampのスケジュール 01 新卒の過ごし⽅ フィールドセールス (FS) マーケティング カスタマーサクセス (CS) インサイドセールス (IS) 申請チーム 問い合わせチーム 開発企画部
9. BootCampのスケジュール 01 新卒の過ごし⽅ フィールドセールス (FS) マーケティング カスタマーサクセス (CS) インサイドセールス (IS) 商談同席 展⽰会 申請チーム 問い合わせチーム 開発企画部
10. BootCampのスケジュール 01 新卒の過ごし⽅ フィールドセールス (FS) マーケティング カスタマーサクセス (CS) インサイドセールス (IS) アプリ制作/運営 メール‧架電 申請チーム 問い合わせチーム 開発企画部
11. BootCampのスケジュール 01 新卒の過ごし⽅ フィールドセールス (FS) マーケティング カスタマーサクセス (CS) インサイドセールス (IS) 申請チーム 問い合わせチーム 開発企画部 ストア申請 問い合わせ対応 機能仕様書の作成
12. BootCampのスケジュール 01 新卒の過ごし⽅ フィールドセールス (FS) マーケティング カスタマーサクセス (CS) インサイドセールス (IS) 上記BootCampに加えてSRE業務をこなす 申請チーム 問い合わせチーム 開発企画部
13. ヤプリ新卒SREのオンボーディング オンボーディングの目的 ヤプリSREの基本的な業務を理解して , 実際に一人で担当できるようになる 01 新卒の過ごし⽅ ヤプリのSRE • 累計2億ダウンロード数のアプリプラットフォームを⽀えている ◦ インフラの構築や保守/運⽤ ◦ オブザーバビリティの強化 • その他の業務 ◦ 定例 → サービスの状態やコストを確認 ◦ 勉強会 → ドメイン知識や利⽤可能性のある技術について勉強する ◦ 依頼対応
14. SREチームによる⼿厚いサポート 個⼈にパーソナライズされた⼀⼈前のSREになるためのロードマップを⽤意 01 新卒の過ごし⽅ 実際の資料
15. SREとして取り組んだこと
16. • PostgreSQLのアップグレード • ログ収集基盤の変更（コスト削減） • Google CloudのTerraform化 取り組んだSRE業務 02 SREとして取り組んだこと
17. • PostgreSQLのアップグレード • ログ収集基盤の変更（コスト削減） • Google CloudのTerraform化 取り組んだSRE業務 02 SREとして取り組んだこと
18. 02 SREとして取り組んだこと - PostgreSQLのアップグレード 対象となるPostgreSQL • Redashで利⽤されているPostgreSQL ◦ Redash：ダッシュボード作成のための社内ツール
19. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレードタスクの⽬的 • 延⻑サポートからの脱却 ◦ PostgreSQLのバージョンが11で延⻑サポートの対象となっていた ◦ 追加で費⽤が発⽣するため、12以上にアップグレードする必要があった • オンボーディングの⽬的 ◦ 何種類かの⽅法からメリット‧デメリットを整理して⼿順を選定する ◦ ⼿順書作成‧レビュー ◦ 開発環境 ⇨ STG環境 ⇨ 本番環境 といった運⽤の際の流れを知る
20. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成 ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺
21. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成 ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ ECS, Aurora等を利⽤して構築 アーキテクチャ理解，設計に慣れる
22. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成 ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ アップグレード⼿順を調査する メリット‧デメリットを整理する 開発環境で検証
23. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成 ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ アップグレードの⼿順書を作成する 作成後，レビューをしてもらう
24. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成 ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ ⼿順書通りにSTG環境でアップグレード 不⾜があれば⼿順書に追記する
25. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成 ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ STGと同様にアップグレード
26. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレードを⾏ってみて • 技術的に困難だった点 ◦ バージョンアップグレードに伴う互換性調査 ◦ 本番環境にて⼀度アップグレードできずに切り戻し ▪ AWSのブルーグリーンデプロイを利⽤したが, DDLの制約上できなかった ▪ 事前に切り戻しの⼿順を⽤意していたため, 切り戻し⾃体は容易だった • SREメンバーによる⼿厚いフォロー ◦ ⼿順書のレビュー会 ▪ 漏れや考慮事項の確認 ◦ 定期的な作業確認 ▪ 進捗状況や⼿詰まりを確認
27. • PostgreSQLのアップグレード • ログ収集基盤の変更（コスト削減） • Google CloudのTerraform化 取り組んだSRE業務 02 SREとして取り組んだこと
28. 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） Yappliのログ収集基盤 リクエスト アプリからリクエストされた際のログを収集
29. アプリからリクエストされた際のログを収集 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） Yappliのログ収集基盤 リクエスト 調査は主にNew Relicで
30. 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） ログ収集基盤の課題 リクエスト エンドユーザが多く ⼤量のリクエストが発⽣する
31. 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） ログ収集基盤の課題 リクエスト ⼤量のログデータがCloudWatch Logsに 取り込まれる → USD 0.76/GB Amazon CloudWatch Logsにログを取り込む際の料⾦が⾼い
32. 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） ログ基盤変更の⽬的 • ログ基盤にかかるコストの削減 ◦ 特にコストのかかるCloudWatch Logsを廃⽌して、別の⽅法を検討する ◦ またCloudWatch Logs利⽤にかかる保存料等をなくす • オンボーディングの⽬的 ◦ コスト最適化に伴うコスト試算 ◦ 影響調査 ◦ ヤプリのリリースフローの体験
33. 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） ECSのログの排出先を変更 ログの排出先をCloudWatch Logs → FireLens (fluentbit)に変更する データ収集量 1TB/⽉あたり724USD/⽉の削減（760USD → 36USD） データ収集にかかるコスト (2024/08現在) Amazon CloudWatch Logs 0.76USD/GB Amazon Data Firehose 0.036USD/GB
34. 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） ECSのログの排出先を変更 ⼿順 1. アーキテクチャ設計 2. コスト試算 3. 開発環境での動作確認 4. 影響範囲調査 5. 本番環境のインフラ変更
35. 02 SREとして取り組んだこと - ログ収集基盤の変更（コスト削減） ログ収集基盤変更をやってみて • 技術的に困難だった点 ◦ FireLens(fluentbit)からのログ転送設定の理解 • 想定よりも影響範囲が⼤きかった ◦ 多くの部署がログを利⽤しており, CloudWatch Logsが⾒れないと困るというケースもあった ◦ New Relicのアラートやダッシュボード周りの変更も必要だった ◦ 開発環境はこれまで通りCloudWatch Logsを利⽤するようにしたかった ▪ 開発環境と ステージング環境‧本番環境で設定を分ける必要があった • Yappliのプロダクトに関わることができた ◦ ビジネスに直接影響のある業務の体験 ◦ Yappliのリリースフローを味わえた ◦ 開発者が普段利⽤する開発環境を確認できた
36. • PostgreSQLのアップグレード • ログ収集基盤の変更（コスト削減） • Google CloudのTerraform化 取り組んだSRE業務 02 SREとして取り組んだこと
37. 02 SREとして取り組んだこと - Google CloudのTerraform化 ヤプリのデータ基盤【Yappli Data Hub】 • アプリ内の⾏動データ（閲覧/⾏動イベント）‧属性データ（フォーム機能で 取得したデータ）を「ユーザー単位」で分析することができる機能 Yappli Data Hub
38. 02 SREとして取り組んだこと - Google CloudのTerraform化 Yappli Data Hubのインフラ構成 • データ収集‧集計の部分でGooogle Cloudを利⽤
39. 02 SREとして取り組んだこと - Google CloudのTerraform化 Yappli Data Hubのインフラ構成 • データ収集‧集計の部分でGooogle Cloudを利⽤ 分析のためにデータの収集‧集計
40. 02 SREとして取り組んだこと - Google CloudのTerraform化 Yappli Data Hubのインフラ構成 • データ収集‧集計の部分でGooogle Cloudを利⽤ アーキテクチャが少し複雑 IaC化されていない
41. 02 SREとして取り組んだこと - Google CloudのTerraform化 Yappli Data Hubのインフラ構成 • データ収集‧集計の部分でGooogle Cloudを利⽤ → Google CloudリソースのTerraform化を⾏う
42. 02 SREとして取り組んだこと - Google CloudのTerraform化 Terraform化の⽬的 • コード管理されていないことによって... ◦ 開発環境‧STG環境‧本番環境で差分が⽣じていた ◦ また⼿動変更のたびに差分が増えていく ◦ 開発環境の複製に⼿間がかかる • オンボーディングの⽬的 ◦ Terraformの理解 ◦ Google Cloudへの理解 ◦ Yappli Data Hubのアーキテクチャ理解
43. Terraform化の進め⽅ 1. Yappli Data Hubのアーキテクチャ理解 ◦ 開発環境で同じ仕組みを構築 2. 既存リソースをTerraformに取り込む ◦ terraform planでコードとインフラの間で差分がなくなる状態にする ◦ 環境ごとに差分あれば都度開発チームに確認 02 SREとして取り組んだこと - Google CloudのTerraform化
44. Terraform化をやってみて • 技術的に困難だった点 ◦ Google Cloudのサービス理解 • サービスと技術の理解度向上 ◦ TerraformとGoogle Cloudを利⽤したことがなかったため, 理解する良い機会となった ◦ Yappli Data Hubの理解度もアップ！ • 開発チームと連携したことで、Yappli Data Hubの課題を認識できた ◦ Yappli Data Hubでこれまで管理できていなかった箇所の洗い出しができた ◦ 開発チームやデータサイエンティストが持っている課題感の認識 02 SREとして取り組んだこと - Google CloudのTerraform化
45. ⼊社からこれまで振り返って
46. BootCampを通して 03 ⼊社からこれまで振り返って
47. 03 ⼊社からこれまで振り返って SRE視点の「BootCamp」 ① クライアントの⽣の声が聞ける • これからYappliを導⼊しようとしている会社から聞けること ◦ なぜ⾃社開発ではなく、Yappliを利⽤するのか ◦ アプリを導⼊する上でどういうハードルがあるのか • 現在Yappliを利⽤している会社から聞けること ◦ Yappliで解決できている課題 ◦ Yappliでできたら嬉しいこと ⇨ Yappliのどの部分においての開発‧改善のニーズがあるかが把握できる
48. 03 ⼊社からこれまで振り返って SRE視点の「BootCamp」 ② ビジネス職の⽅と仲良くなれる • Yappliの運⽤の側⾯を知ってもらえる ◦ Yappliが安定しているのは, ⽇々サービスを⽀えている⼈がいるということ • SREの役割を知ってもらえる ◦ ビジネス職はSREについて知らないため、知ってもらうためのいいきっかけになる ▪ 機能がうまく動作しない → サーバサイド ▪ システムが安定しない → SRE ◦ 潜在的なリスクに対するアプローチができる可能性がある ▪ クライアントのキャンペーン等の施策による負荷の向上をキャッチアップ ⇨ 普段のSREが関わりが少ないビジネス職との仕事に繋げられる
49. SREオンボーディングを通して 03 ⼊社からこれまで振り返って
50. ⾃分に合わせた課題設定 • 初めてのSRE業務という中で... ◦ 基礎的なSRE業務の進め⽅を理解するためのロードマップ ◦ 勉強会で基本的な技術やプロダクトのドメイン領域の理解 • 技術⼒向上というモチベーションに対して... ◦ 練習⽤のAWS環境の提供 ◦ 実際のサービスや技術を扱うようなタスク • ビジネス影響の⼤きいところに関わりたいという要望 ◦ 実際のプロダクトに関する実践的な課題を選定 ◦ ビジネス影響がある分, リスクを考慮し⼿厚いフォロー 03 ⼊社からこれまで振り返って
51. • 「BootCamp」という新卒研修プログラムが存在する ◦ Yappliという製品について理解を深められる ◦ ビジネス職と仲良くなれる • 個⼈にあったタスクの割り振りがある ◦ 決まったエンジニア研修が⽤意されているわけではないが, 個⼈に合わせたタスク設計 ◦ 実践的な課題があるため, プロダクトの理解が⾼まりやすい ヤプリの新卒オンボーディングまとめ 03 ⼊社からこれまで振り返って
52. まとめ
53. まとめ • ヤプリの新卒研修について紹介 ◦ BootCamp ◦ ヤプリのSREについて • ⾃分がSREとして取り組んだことを紹介 ◦ PostgreSQLのアップグレード ◦ ログ収集基盤の変更 ◦ Google CloudのTerraform化 • ⼊社からこれまでを振り返って ◦ ヤプリでの⼊社を振り返って ◦ ヤプリの新卒オンボーディングまとめ 04 まとめ