Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

masaki-s
October 31, 2024

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

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

masaki-s

October 31, 2024
Tweet

Other Decks in Programming

Transcript

  1. Speaker 開発統括本部 プロダクト開発本部 開発3部 SREグループ 眞⽥ 将希 • 2024年にヤプリに新卒SRE⼊社 •

    ⾼専在学後, ⾼専専攻科‧⼤学院へと進学 • 元々ネットワークやプログラミングに興味があり, インフラやAWSを触るようになった • 好きな分野はCI/CD
  2. ヤプリ新卒の⼊社前(⾃分の場合) • 就活時 ◦ 1ヶ⽉のインターンを実施 ▪ SREでSentry改善に取り組む • https://tech.yappli.io/entry/sre-intern-sentry-replace •

    内定後 ◦ 内定時に配属先はSREに決定 ◦ 内定者インターン(任意参加) ◦ 内定者研修 → 内定者同⼠仲良くなれる 01 新卒の過ごし⽅
  3. BootCampのスケジュール 01 新卒の過ごし⽅ フィールドセールス (FS) マーケティング カスタマーサクセス (CS) インサイドセールス (IS)

    申請チーム 問い合わせチーム 開発企画部 ストア申請 問い合わせ対応 機能仕様書の作成
  4. ヤプリ新卒SREのオンボーディング オンボーディングの目的 ヤプリSREの基本的な業務を理解して , 実際に一人で担当できるようになる 01 新卒の過ごし⽅ ヤプリのSRE • 累計2億ダウンロード数のアプリプラットフォームを⽀えている

    ◦ インフラの構築や保守/運⽤ ◦ オブザーバビリティの強化 • その他の業務 ◦ 定例 → サービスの状態やコストを確認 ◦ 勉強会 → ドメイン知識や利⽤可能性のある技術について勉強する ◦ 依頼対応
  5. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレードタスクの⽬的 • 延⻑サポートからの脱却 ◦ PostgreSQLのバージョンが11で延⻑サポートの対象となっていた ◦

    追加で費⽤が発⽣するため、12以上にアップグレードする必要があった • オンボーディングの⽬的 ◦ 何種類かの⽅法からメリット‧デメリットを整理して⼿順を選定する ◦ ⼿順書作成‧レビュー ◦ 開発環境 ⇨ STG環境 ⇨ 本番環境 といった運⽤の際の流れを知る
  6. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成

    ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ ECS, Aurora等を利⽤して構築 アーキテクチャ理解,設計に慣れる
  7. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成

    ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ アップグレード⼿順を調査する メリット‧デメリットを整理する 開発環境で検証
  8. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成

    ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ アップグレードの⼿順書を作成する 作成後,レビューをしてもらう
  9. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレード作業の進め⽅ 開発環境でのRedashの構築 ❶ アップグレード⽅法の調査 ❷ ⼿順書の作成

    ❸ STG環境のアップグレード ❹ 本番環境のアップグレード ❺ ⼿順書通りにSTG環境でアップグレード 不⾜があれば⼿順書に追記する
  10. 02 SREとして取り組んだこと - PostgreSQLのアップグレード アップグレードを⾏ってみて • 技術的に困難だった点 ◦ バージョンアップグレードに伴う互換性調査 ◦

    本番環境にて⼀度アップグレードできずに切り戻し ▪ AWSのブルーグリーンデプロイを利⽤したが, DDLの制約上できなかった ▪ 事前に切り戻しの⼿順を⽤意していたため, 切り戻し⾃体は容易だった • SREメンバーによる⼿厚いフォロー ◦ ⼿順書のレビュー会 ▪ 漏れや考慮事項の確認 ◦ 定期的な作業確認 ▪ 進捗状況や⼿詰まりを確認
  11. 02 SREとして取り組んだこと - ログ収集基盤の変更(コスト削減) ログ基盤変更の⽬的 • ログ基盤にかかるコストの削減 ◦ 特にコストのかかるCloudWatch Logsを廃⽌して、別の⽅法を検討する

    ◦ またCloudWatch Logs利⽤にかかる保存料等をなくす • オンボーディングの⽬的 ◦ コスト最適化に伴うコスト試算 ◦ 影響調査 ◦ ヤプリのリリースフローの体験
  12. 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
  13. 02 SREとして取り組んだこと - ログ収集基盤の変更(コスト削減) ログ収集基盤変更をやってみて • 技術的に困難だった点 ◦ FireLens(fluentbit)からのログ転送設定の理解 •

    想定よりも影響範囲が⼤きかった ◦ 多くの部署がログを利⽤しており, CloudWatch Logsが⾒れないと困るというケースもあった ◦ New Relicのアラートやダッシュボード周りの変更も必要だった ◦ 開発環境はこれまで通りCloudWatch Logsを利⽤するようにしたかった ▪ 開発環境と ステージング環境‧本番環境で設定を分ける必要があった • Yappliのプロダクトに関わることができた ◦ ビジネスに直接影響のある業務の体験 ◦ Yappliのリリースフローを味わえた ◦ 開発者が普段利⽤する開発環境を確認できた
  14. 02 SREとして取り組んだこと - Google CloudのTerraform化 Terraform化の⽬的 • コード管理されていないことによって... ◦ 開発環境‧STG環境‧本番環境で差分が⽣じていた

    ◦ また⼿動変更のたびに差分が増えていく ◦ 開発環境の複製に⼿間がかかる • オンボーディングの⽬的 ◦ Terraformの理解 ◦ Google Cloudへの理解 ◦ Yappli Data Hubのアーキテクチャ理解
  15. Terraform化の進め⽅ 1. Yappli Data Hubのアーキテクチャ理解 ◦ 開発環境で同じ仕組みを構築 2. 既存リソースをTerraformに取り込む ◦

    terraform planでコードとインフラの間で差分がなくなる状態にする ◦ 環境ごとに差分あれば都度開発チームに確認 02 SREとして取り組んだこと - Google CloudのTerraform化
  16. Terraform化をやってみて • 技術的に困難だった点 ◦ Google Cloudのサービス理解 • サービスと技術の理解度向上 ◦ TerraformとGoogle

    Cloudを利⽤したことがなかったため, 理解する良い機会となった ◦ Yappli Data Hubの理解度もアップ! • 開発チームと連携したことで、Yappli Data Hubの課題を認識できた ◦ Yappli Data Hubでこれまで管理できていなかった箇所の洗い出しができた ◦ 開発チームやデータサイエンティストが持っている課題感の認識 02 SREとして取り組んだこと - Google CloudのTerraform化
  17. 03 ⼊社からこれまで振り返って SRE視点の「BootCamp」 ① クライアントの⽣の声が聞ける • これからYappliを導⼊しようとしている会社から聞けること ◦ なぜ⾃社開発ではなく、Yappliを利⽤するのか ◦

    アプリを導⼊する上でどういうハードルがあるのか • 現在Yappliを利⽤している会社から聞けること ◦ Yappliで解決できている課題 ◦ Yappliでできたら嬉しいこと ⇨ Yappliのどの部分においての開発‧改善のニーズがあるかが把握できる
  18. 03 ⼊社からこれまで振り返って SRE視点の「BootCamp」 ② ビジネス職の⽅と仲良くなれる • Yappliの運⽤の側⾯を知ってもらえる ◦ Yappliが安定しているのは, ⽇々サービスを⽀えている⼈がいるということ

    • SREの役割を知ってもらえる ◦ ビジネス職はSREについて知らないため、知ってもらうためのいいきっかけになる ▪ 機能がうまく動作しない → サーバサイド ▪ システムが安定しない → SRE ◦ 潜在的なリスクに対するアプローチができる可能性がある ▪ クライアントのキャンペーン等の施策による負荷の向上をキャッチアップ ⇨ 普段のSREが関わりが少ないビジネス職との仕事に繋げられる
  19. ⾃分に合わせた課題設定 • 初めてのSRE業務という中で... ◦ 基礎的なSRE業務の進め⽅を理解するためのロードマップ ◦ 勉強会で基本的な技術やプロダクトのドメイン領域の理解 • 技術⼒向上というモチベーションに対して... ◦

    練習⽤のAWS環境の提供 ◦ 実際のサービスや技術を扱うようなタスク • ビジネス影響の⼤きいところに関わりたいという要望 ◦ 実際のプロダクトに関する実践的な課題を選定 ◦ ビジネス影響がある分, リスクを考慮し⼿厚いフォロー 03 ⼊社からこれまで振り返って
  20. • 「BootCamp」という新卒研修プログラムが存在する ◦ Yappliという製品について理解を深められる ◦ ビジネス職と仲良くなれる • 個⼈にあったタスクの割り振りがある ◦ 決まったエンジニア研修が⽤意されているわけではないが,

    個⼈に合わせたタスク設計 ◦ 実践的な課題があるため, プロダクトの理解が⾼まりやすい ヤプリの新卒オンボーディングまとめ 03 ⼊社からこれまで振り返って
  21. まとめ • ヤプリの新卒研修について紹介 ◦ BootCamp ◦ ヤプリのSREについて • ⾃分がSREとして取り組んだことを紹介 ◦

    PostgreSQLのアップグレード ◦ ログ収集基盤の変更 ◦ Google CloudのTerraform化 • ⼊社からこれまでを振り返って ◦ ヤプリでの⼊社を振り返って ◦ ヤプリの新卒オンボーディングまとめ 04 まとめ