こんにちは。スタディサプリの小中新規開発チームで Web エンジニアをしている @YutaUra です。 去年の４月に新卒で入社をしまして約 1 年が経ちました。インターン生時代にもブログを書いているのでご興味あれば合わせてご覧ください。 GraphQL と Persisted Query スタディサプリ小中講座ではデータ通信に GraphQL を採用しています。 GraphQL を利用することで、クライアントはスキーマに定義された範囲で自由にデータを取得することができます。 query GetUser { user { name age } } また、 GraphQL はデータのグラフ構造に基づいて関連する複数のデータを一度に取得することができます。 query GetUser { user { name age posts { title content } } } GraphQL の

こんにちは。SREのkyontanです。Rubyが大好きなのでRubyの話をします。ちなみにリクルートはRubyKaigi 2024へGold Sponsorとして協賛しています! *1。ぜひ沖縄でお会いしましょう。 これはあるアプリケーションのメモリ消費量を示すグラフなのですが、まさかgemを入れ替えるだけでこんなに嬉しい変化が見られるとは思っていませんでした。今日はそんなgemの話をします。 話は遡って2023年4月のある日、インターネットを眺めていたところ、ShopifyがpitchforkというOSSを公開したという情報が目に留まりました。 調べてみると、どうやら著名なRackサーバー実装の1つであるunicornの派生版であり、メモリ使用量の削減に特化しているらしいのです。 github.com これはスタディサプリ小中高のあのリソースドカ食いマイクロサービス第一位である api

こんにちは。@chaspy です。プロダクト開発部の技術戦略グループのマネージャをしています。 技術戦略グループでは、日頃開発する上での課題の投げ込みや議論、解決するための計画をボトムアップで行っています。技術戦略グループの活動については過去のアウトプットもご覧ください。 blog.studysapuri.jp また、本稿のテーマである、組織やシステムの状況を把握するための Fact 収集については技術戦略 DevOps WG が担当しています。以前発表した資料もご覧ください。 このように、技術戦略グループではエンジニア1人1人が課題だと思うことを表明、宣言し、その課題をトリアージすること、および課題を評価するための Fact の発見・提供を行う仕組みが組織としてボトムアップで行える状態になっています。一方、開発部長として、事業戦略と結びつける形で技術戦略を策定する際には、現場のエンジニア

この記事は Enginnering Manager Advent Calendar その２の1日目の記事です。（大遅刻しました） こんにちは。@chaspy です。10月からスタディサプリ小中高*1プロダクト開発部の部長をしています。 本記事では、我々の組織で取り組んでいる技術戦略の現状と今後についてお伝えします。 技術戦略とは何か スタディサプリ小中高の技術戦略 開発比率適正化 課題発見と改善サイクルの確立 直近の取り組み ガイドラインの策定 マイクロサービスの命名 今後追加が予定されているもの monolith の方針検討 共有データベースに対する Model 層の管理方針 api endpoint ごとのオーナーシップ策定 技術戦略グループとして実現したいこと おわりに 技術戦略とは何か ざっくりいうと、事業計画に対して、技術投資をどこにするのか、しないか、です。"技術"投資と言って

スタディサプリにおけるKarpenterの導入トラブル振り返り こんにちは。スタディサプリ小中高SREの@aoi1です。 スタディサプリでは、Kubernetesを利用しているのですが、Nodeの運用自動化のために2023年3月から本番環境を含む全環境でKarpenterを導入しています。 Karpenterのおかげで開発者体験を向上させることができたり、コスト削減を行うことができました。便利で良いことが沢山ある一方、本番環境で問題が発生するなどいくつかハマったこともありました。 本ブログでは私たちがハマったポイントを通じて、Karpenterの導入を検討している方、あるいは既に本番環境でKarpenterを運用している方にとって参考になればと思います。 Karpenterとは KarpenterはAmazon Web Sevice(AWS)が開発しているOSSで、「Karpenter s

こんにちは。スタディサプリの小中高プロダクト基盤開発グループでProduct Platform Engineer兼テックリードをやっている@tooooooooomyです。 今回は、WebアプリケーションにGoの並行処理機構を導入してSLOを改善し、WebAPIを100倍速くした話をしたいと思います。 前提条件 システムを0から作らない場合、アーキテクチャの改善の際には前提条件が付きものです。そこでまずは今回のシステムの前提条件をお話します。 対象となるシステムと、アーキテクチャ 今回対象とするシステムは、ここでは security-tracker と呼び、Webアプリケーション本体はGoで書かれています。 スタディサプリの各アプリケーションにおけるユーザーのログ1を、Amazon Kinesis Firehoseを通して、リクルート全体のセキュリティチームが管理するS3バケット(スタディサ

こんにちは。スタディサプリでプロダクトプラットフォームの開発を行っている @highwide です。 少し前の話になってしまいますが、2023-07-27に行われた「Developers Summit 2023 Summer」(以下、「デブサミ」と書きます)にて「アーキテクチャデシジョンレコード」(ADR)についての発表をしましたので、その報告をさせていただきます。 「日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード」というタイトルで発表しました。 発表資料はこちらです。 また、デブサミのサイトでは、発表の当日の録画が見られるようです。 途中、自分の声に反応してしまったApple Watchに焦る様子なども見られるかと思います...(恥ずかしい...) codezine.jp ベストスピーカー賞受賞 🎉 また、この度、本カンファレンスにおけるベストスピーカー賞(1位

こんにちは、Web Engineer の @wozaki です。 今回は、採用プロセスの改善として、職務経歴書に記載いただきたいことを公開した背景をご紹介します。 概要 職務経歴書に、採用チームとして期待する情報が不足していることがある 不足すると、以下の課題が発生することがある 書類選考は通過するが、その後の選考でミスマッチと分かる (経歴書が充足していたら、より早期にミスマッチが分かったかもしれない) 面接の前に経歴に踏み込んだ質問を設計できずに、面接時間内でマッチしているか情報を引き出す難易度が上がる 既存の対策として、情報の追記をお願いすることがある 新たな対策として、記載いただきたいことを ガイドとして公開 することにした 記載いただきたいこと 早期ミスマッチ解消の必要性 Web Engineer の採用は競争が激化している肌感があります。 応募者の方々にとっても、様々な企業の中

はじめに こんにちは！スタディサプリで開発者をしている @pankona です。今日は、最近スタディサプリでも頻繁に使われるようになってきた Go 言語の話をします。 先日、GitHub 上の gorilla/mux リポジトリがアーカイブされました。gorilla/mux は Go 言語での HTTP ルーター選択肢の一つで、シンプルながら必要十分なルーティング機能を提供するライブラリです。主観的な見解かもしれませんが、このライブラリは広く使われ、支持を得ていたと感じています。私のお気に入りのライブラリの一つでもあります。スタディサプリで稼働している一部のマイクロサービスでは現在も gorilla/mux を使用しています。 ライブラリがアーカイブされるということは、その開発が停止し、新機能の追加やセキュリティアップデートが提供されなくなるということです。また、新しい Go のバージョン

こんにちは、 Web フロントエンドエンジニアの @progfay です。 今回はプロジェクトで遭遇した URL 長による GraphQL Request の失敗と Apollo Link による解決方法を紹介します。 引数に配列を受け取る GraphQL field 私の所属するスタディサプリ中学講座の開発プロジェクト (通称: tara) では通信に GraphQL を採用しています。 その中で、以下のような field を実装しています。 type Query { entities(ids: [ID!]!): [Entity!]! } これに対して、以下のような Query を叩きます。 query specificEntities($ids: [ID!]!) { entities(ids: $ids) { name } } Request-URI Too Large ある日、この

こんにちは。スタディサプリ小中高 / Quipper SREの@kyontanです。 この記事は Recruit Engineers Advent Calendar 2022 の1日目の記事です。 開発チームが事実に基づいて(= fact-basedな)意思決定をできるようにするための一助として、SREチームではSLO (Service Level Objective)が設定されていることをサービス公開時の要件としています。 スタディサプリ小中高におけるSLOの運用については、以前弊チームの@chaspyが SRE NEXT 2020 で「SLO Review」というタイトルで登壇しました #srenext という記事を書いているので、こちらもご参照ください。 本記事では、これまでしきい値によるアラートを設定していたSLOについて、Burn Rateによるモニタリングを試してみたので、ざっ

こんにちは、 Web フロントエンドエンジニアの @progfay です。 今回は PR に紐づいたプレビュー環境のビルドに 10 分半かかっていたところを 3 分半ほどまでに短縮した改善活動についてお話しします。 技術改善 Day 私の所属するスタディサプリ中学講座の開発プロジェクト (通称: tara) では「技術改善 Day」を 2 週間に 1 回実施しています。 「技術改善 Day」とは、案件開発を進めていく中で出てきた技術的負債の解消に丸 1 日チームで集中して取り組む日です。 tara 内の Web フロントエンドメンバーで解消したい技術的負債を考えたところ、その中の一つに Web フロントエンドアプリケーションのビルドに時間がかかっている問題 が挙がりました。 tara プロジェクトではデバッグや QA を効率的に行うために PR ごとに紐づいたプレビュー環境を用意しています

こんにちは。フロントエンドエンジニアの @sakamuuy です。 私たちのチームではエラートラッキングに Sentry というサービスを利用しています。この運用を開始して半年が経過しました。 今回は私が所属するフロントエンドチームでのSentry運用について、苦労したこととその打ち手についてお話したいと思います。 はじめに エラーを検知し重大なバグなどに早めに気づくことは、Sentryを運用する一つの目的だと思います。 そのためには未解決のエラー件数をなるべく少なくし、発生したエラーを監視できている状態を保つことが必要だと考えています。この状態を保てるように運用で工夫していることについてお話します。 チーム チームでの運用についてお話する前に、私の所属しているtara学習コアチーム (taraとはスタディサプリ中学講座のリニューアルプロジェクトの通称です) についてお話します。 tara

こんにちは。QA Engineerの@testtattoです。 今回はE2Eテストの自動化にあたって、どういった考えでツール選定を行ったのかを話したいと思います。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 E2Eテスト自動化によって課題を解決したいが、どういった技術があるのか分からなくて困っている人 E2Eテストの自動化は実現できているが、継続に課題を抱えている人 テスト自動化なら何でも興味がある人 まえがき 読んでもらう前にいくつかの前提を共有します。 リリースサイクルについて 当社のwebプラットフォームのリリースサイクルは一部のマイクロサービスを除いて基本的には週次です。 決まった曜日で各プロダクトのプルリクエストを取り込んで、リグレッションテストを実施し、リリースブロッカーがなければリリースしています。 流れとしてはこんな感じです。 月 火 水 木 金 特

こんにちは。SRE Team の @chaspy です。次の10月で Engineering Manager をつとめて1年になります。 本記事ではもしかするとメンバーからわかりづらい Engineering Manager のしごとについて、昨年10月からの約1年間を振り返りながら説明しようと思います。 ところで「エンジニアリングマネージャのしごと」もうすぐ発売ですね。筆者もとても楽しみにしています。検索のノイズになるのは本意ではないので記事のタイトルはカタカナではなく英語表記にしました。 www.oreilly.co.jp なお、リクルートでは人事制度上 "Engineering Manager" というロールはなく、GM (Group Manager) が正式なロールです。EM と GM は重複する部分、そうでない部分ありますが本記事では割愛します。 基本情報 会社組織編 SRE T

（この記事は約5分で読めます） こんにちは、スタディサプリ TPM（Technical Product Manager）の@risa-hayashi です。 振り返りにGitHub Projects(beta)のInsightsという機能を利用してみたところ、振り返りが効果的にできるようになったのでその運用方法や効果を紹介したいと思います！ GitHub Projects(beta) Insightsとは？ とてもざっくり言うと、任意のGitHub Project(beta)に載せられたissueから、このようなチャートを作れる機能です。 しかもこのチャートの見た目（グラフの種類やX/Y軸の基準）は適宜カスタムすることができます。便利！ 私の所属しているスタディサプリ合格特訓コース、個別指導コースの開発チームでは、この機能を利用して数ヶ月前から振り返りの運用を行っています。 なぜInsig

こんにちは、ujihisa といいます。現在スタディサプリのProduct Platform の Software engineerとしての仕事を行っています。先月から社内留学で、開発支援チームからコーチングチームに一時的に移籍して、そちらの仕事をやっています。 Rubyのコードの書き方 まずは全体的なコーディングスタイルなどについて。 現在社内で統一的に使用しているコーディングスタイルの標準化などはとくに行われておりません。各チームごとに、それぞれのチームが開発運用している (= ownershipをもっている) コンポーネントそれぞれに対して個別のRuboCop設定などはあります。また、複数のチームの境界にある、歴史的な共有サービスに関しては (そう、まだあります、そしてこれは今後もかなり長いあいだ付き合っていくことになるでしょう) testdouble/standard というTes

こんにちは。SRE チームの@chaspy です。 本記事では私の所属する SRE チームにおける「ふりかえり」の文化を紹介します。 背景 最近のチームのふりかえり会 *1 で僕自身が以下のようなコメントを"Keep"として出しました。 これは、単にこのふりかえり会が継続している、という意味に留まりません。あらゆる物事に対してふりかえりが行われ、改善サイクルが高速に回っていると感じます。それはチームメンバー全員が以下の価値観で仕事を進められているからだと思います。 あらゆる問題、取り組み、事象について「それは本当に必要か？」「それはなぜやるのか？」といったことを問うことができる。いわゆるクリティカルシンキング。 あらゆる問題に対して、建設的・前向きに、他者や何かを否定することなく、より良い案を言葉にして提案できる。建設的思考。blameless。 やることにコストがかからず、やらない理由が

こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo に対する Renovate の大量の Pull Request を処理するための技術について紹介します。 背景 過去ブログで何度か紹介しているように、弊プロダクトでは Terraform の Monorepo を管理しています。 先日、 CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました。 blog.studysapuri.jp working directory (state) の数は 400 近くあり、 working directory ごとに以下のような tool のバージョンを管理しています。 Terraform Terraform Provider tflint tflint plugin tfsec etc これ

こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI を AWS CodeBuild (以下 CodeBuild) から GitHub Actions + tfaction に移行した話を紹介します。 これまでの Terraform Workflow (CodeBuild) 弊プロダクトの Terraform の CI に関しては過去の記事でも何度か紹介していますが、 元々 CodeBuild 上で CI を実行していました。 かつては CircleCI 上で実行していましたが、 CodeBuild に移行しました。 blog.studysapuri.jp CodeBuild に移行した理由は大きく 2 つありました。 Security 永続的な Access Key を発行することなく AWS のリソースを管理できる GCP に関しても Wor