Self-Hosted Cluster から EKS への移行と Platform の Production Readiness - スタディサプリ Product Team Blog
こんにちは。SRE の @chaspy です。 Quipper では AWS 上で Kubernetes Cluster を運用してサービスを提供しています。 これまで kube-aws を用いて Kubernetes Cluster を Self Host してきましたが、このたび Managed Services である Amazon EKS に移行しました。（以下、 Amazon EKS を EKS と表記します） 本記事では、 Kubernetes Cluster の移行で遭遇した問題をどのように解決したかを説明します。また、数多くの Application が稼働している Platform を移行する際にどのような点を考慮するとよいのか、経験を通して学んだことを共有します。 EKS への移行を検討している方はもちろん、Platform Migration に携わる方にとって学びに
リモート環境でも同じように楽しくやりたい！（前編） 〜2020年度Coaching チームのリモートふん闘記〜 - スタディサプリ Product Team Blog
こんにちは、 自分が入社した時に憧れた先達がいなくなって寂しき中も、自身はもうすぐ Quipper 2年生をそつ業しようとしている、危うげな Quipper web エンジニアの @motorollerscalatron です。 stay home と言われて久しいですが、今回はそんな中でも私のいる ToC Coaching チーム が、どのように今までやっていたプラクティスをリモート主体の会社生活でも再現しようとしているかをブログ記事にしてみました。 お断りのようなもの 普通の我々の Product Blog では、対象読者をわりかし最初のほうできちんと定義していますが、今回に関しては明確にしていません。 表題の件に関して、結論から言うと、「正解」を私たちはいまだに見つけられずにいます。 wantedly では 弊社 @akane-suzuki568 により3月頃に に Quipper流
Shadow Proxyのご紹介 at Quipper - Qiita
この記事はQuipperのテックブログに書いた以下の記事の日本語版での要約です。 http://quipper.github.io/2015/11/11/introducing-shadow-proxy.html Shadow Proxyとは？ 本番のHTTPリクエストから同等のリクエストをステージング環境に適用するための仕組みです。主な目的は、2年以上の運用で肥大化したMongoDBに対するindexの追加/削除/つけ忘れなどを事前に検証・検知するためです。 構成 Fluentdが大活躍しています。 Reverse Proxy Log AggregatorにNginxのアクセスログを転送する Log Aggregator S3(バックアップ),BigQuery(調査用),Shadow Proxyにアクセスログを転送する アクセスログをもとにステージングのアプリにHTTPリクエストを送信す
わたしたちがチームであるために"期待合わせ会"をやりました、という話 - スタディサプリ Product Team Blog
はじめまして、Web Developerの@tricknotesです。 今回はチームの期待を合わせるためのワークショップである「ドラッカー風エクササイズ」をわたしたちのチームで実践してみました、というお話です。 背景 なんでこのワークショップをやってみようと思ったのか…という話をする前に、まずわたしたちのチームの状況をお伝えさせてください。 わたしたちのチームは、ここ半年ほどで多くのメンバーが増えました。 その結果、古くからのドメイン知識に明るい古株層とまだまだドメイン知識の吸収を必要としている新入りメンバー層の間で大きな知識の隔たりがあるという状況になっています。*1 そんな中、歴史的経緯は気にせずいまの開発に集中してほしい古株メンバーと、そういった歴史的経緯を含めて吸収していきたい新入りメンバーの思いがそれぞれある、ということが振り返りの場で明らかになりました。 どちらもチームのためを
VP of Engineering やめた - @kyanny's blog
2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数
みんなでつくる Production Readiness - スタディサプリ Product Team Blog
こんにちは。SRE の @chaspy です。 以前、Production Readiness Checklist に関する記事を書きました。 quipper.hatenablog.com Production Readiness Checklist の運用開始から1年ほどの月日が経ち、27ものサービスが無事 Production へ出ていきました。 サービスを安心して Production へリリースするために役立っている Production Readiness Checklist ですが、Product Team がこの Check List を進める上でいくつか課題がありました。 本記事では、Production Readiness Checklist 運用開始後に、どのような改善が行われてきたのか、その内容と方法を説明します。また、1年以上の運用を通して、Production R
プロダクトの「負債」を「機能」と呼び直す 〜A/Bテストを用いた"価値"の定量化〜 - スタディサプリ Product Team Blog
Quipper で Web Engineer 兼 Engineering Manager を務める @ohbarye です。スタディサプリの開発、その中でも特に合格特訓コースや決済周りの機能開発・保守が主な業務です。 弊社が開発するプロダクト「スタディサプリ」ではA/Bテストを用いたプロダクトの改善を行っています。Quipper の行動指針の一つに "Fact based" という言葉が含まれており、憶測や独断ではなく計測されたデータや事実に基づいて意思決定することが強く推奨されているためです。 このたびスタディサプリにおいて負債と考えられていた機能を「消してよいかどうか」、A/Bテストを通して判断しました。その際に用いた手法や結果、そこから見えたこと、考えたことをご紹介します。 プロダクトの負債とは プロダクトチームにとって負債と考えられていたのは「キャリア決済」という決済手段でした。そ
Kubernetes 上のアプリケーションから Stackdriver Logging に構造化ログを送る - スタディサプリ Product Team Blog
SRE チームの @yuya-takeyama です。 Quipper の SRE チームでは AWS や Kubernetes を用いたインフラの構築、CI/CD パイプラインの構築・改善等様々な Developer Experience の向上、社内のあらゆるサービスのマイクロサービス化のサポート、そしてそれに伴う複雑化にも耐え得るよう、サービスの安定稼働を支えるためのルール・ツール群を整備しています。 今日はその中でも、簡単かつより精緻に Logs-Based Monitoring が行えるよう、GCP の Stackdrider Logging に構造化ログを送る方法について紹介します。 構造化ログとは ここではとりあえず「Machine-Readable なログ」として定義します。通常のログはテキストベースの Human-Readable なもので、UNIX 哲学においては行指向
採用候補者から見る、Quipperのエンジニア採用フロー - スタディサプリ Product Team Blog
こんにちは、2019年10月からQuipperにjoinした @qsona です。ということはつい数ヶ月前までは一採用候補者としてQuipperの採用を受けていたことになりますが、その中で、Quipperの採用には良い特色が多くあると感じました。今後はQuipperの一員として採用する側に回ることになりますが、採用候補者の視点から感じたことを忘れないうちにこの記事に書きたいと思います。(この記事の9割は入社前に書き上げていたのですが、入社後は普通に仕事が面白すぎて記事を放置してしまい、4ヶ月も経ってしまいました。こうならないように、書いたらさっさと出すのが鉄則です!) 概要 Quipperの面接のフローや各ステップの目的は、ガイドにまとめられています。以下はWebエンジニアの面接ガイドです。 Quipper Web Engineer 東京オフィス採用面接ガイド また、ここに書かれている以外
Kubernetes導入で実現したい世界とその先にあるMicroservices - スタディサプリ Product Team Blog
はじめに CTO兼SREエンジニアリングマネージャーの中野です。ここしばらくの間、CTO/SREエンジニアリングマネージャーとして注力しているKubernetes導入について紹介したいと思います。 今回は、Kubernetes自体がどういうものなのかということより、それをツールとしてどう使い、それでどういう世界を実現したいのかみたいなところを中心に紹介できたらと思います。 まず現在の状況ですが、Quipperでは、大きく分けてスタディサプリの小中高校生向けと日本以外向けの2つのサービスを展開しています。サービスとしての構成はほぼ同じですが、基盤としては別々のAWSアカウントで運営されています。このうち日本国外向け環境では、Kubernetes化がほぼ完了というステータスになっています。目下、スタディサプリも移行中です。 Kubernetes化以前は、Deis(Herokuクローン的なもの)
ブログ再開しました - スタディサプリ Product Team Blog
@kyanny です。先日 Vice President of Engineering になりまして、スタディサプリを開発する Quipper 日本オフィスのプロダクト開発部門の責任者をやっております。 僕はかれこれ 15 年くらいブログを書いています。ウェブエンジニアはみんな自宅サーバーに blosxom や Movable Type をインストールしてブログを公開したり、はてなダイアリーが流行ってたり、 WordPress が出てきたとき「再構築しなくていいからすごく速い！」とみんな驚いたり、そんな頃からブログを書いています。 それほど長いあいだ続けていられるのは、ひとえにブログが僕にとてもよく合っているからです。自分の思考を整理したり、思いのたけをぶちまけたりしながら、人生を綴り人生を切り拓く手段としてブログよりよいものを僕は知りません。フィードを購読するかわりに Twitter で
How Quipper tests software - @kyanny's blog
Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ
CTOより 第3回 「Quipperの開発体制の今」
quipper-cto-3.md 今回はQuipperの開発体制と進め方について書いてみようと思う。 開発チームの規模 第一回で紹介したように、Quipperは、ロンドン、東京、マニラ、ジャカルタ、メキシコシティにオフィスがあり、そのうちロンドン、東京、マニラが開発拠点になっている。 内訳としては、以下の様な状況だ。 Web iOS/Android Engineering Design Total London 3 0 0 1 4 Tokyo 5 4 3 1 13 Manila 7 1 0 2 10 Total 15 5 3 4 27 30人弱。この規模から、今年中に3拠点合計で10人くらいの増強を考えている。拠点毎、職種毎の大まかな計画はあるが、いい人がいたら拠点/職種毎の採用の増減はある感じで、3拠点全職種トータルで考えて一番強いチームにしたい。 Engineeringは、Quippe
CTOより 第2回 「Quipper開発チームに入って欲しい人」
quipper-cto-2.md 前回、現在のQuipperの状況みたいのを書いたが、今回は、普段CTOとして、どういうことを意識して開発チームを作っているか、どういう開発チームになって欲しいと思っているか、というのを書いてみたいと思う。 この辺り、自分自身の経験からくる「好み」とか「美学」みたいなものが強めな部分でもあるので、表に出すのはなかなか勇気がいるが、co-founder/CTOである自分のそういうところが、開発チームのカルチャーに当然影響しているし、一緒に働くことになる人ととはカルチャーのマッチがとても大事だと思っているので出してみる。 まず、以前、社内でなんとなく書いた文章があるのでそのまま出してみる。これは開発者の採用活動に当たり、どんな人が欲しいと思っているか率直に書いたものである。 以下、「開発者」と書いてある部分は、Web開発者/iOS開発者/Android開発者/デ
Ginza.rb で Quipper のシングルページアプリケーション開発について発表しました - @kyanny's blog
ginzarb.doorkeeper.jp Ginza.rb 第26回 シングルページアプリケーションのためのRailsとJavaScript フレームワーク という勉強会で、 Quipper で JavaScript (CoffeeScript) と Rails によるシングルページアプリケーション開発をどうやっているかについて発表しました。お声がけいただいた @willnet さん、 Ginza.rb のみなさま、ありがとうございました。 発表で使った資料はこちらです。 Backbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷 もともと YAPC::Asia の CFP に応募して落選したネタだったのだが、ある意味で自分がこの 2 年間やってきた仕事の集大成ともいえる内容だっ
Quipperを退職しました & 求職中です - fujimuradaisuke's blog
一言でいうと: Quipperを退職しました。Quipperの皆さん、本当にどうもありがとうございました！現在求職中です。ご興味あれば me@fujimuradaisuke.com か https://facebook.com/dfujimura までご連絡ください。Ruby、JavaScript、チーム開発のリード、などができます。wishlistはこちら 2015年6月末日をもって、Quipperを退職しました。 立ち上げ当初のMercariを体を壊して*1辞めて*2入院して手術受けて退院、さて今後どうしようと悩んでいるところで、ひとまずフリーランスで働こうとQuipperで働き始めました。2013年6月でした。 当初からフリーランスはあくまでモラトリアム期間という位置づけで、いずれは正式に会社に入るつもりでした。働いてみるとQuipperは想像以上によいところで、9月には正社員になっ
Quipper の DevOps のお仕事と技術的課題 - hakobera's blog
技術的課題を書くと、それを解決してくれるエンジニアが採用できるって話は本当ですか？というのは冗談としても、今の技術的課題をブログにまとめて公開するノーガード戦法も良いかと思う。— Kazuyuki Honda (@hakobera) May 25, 2015 このツイートがそれなりに反応があったので、有言実行してみる。 最初に書いておくと、これはQuipperの採用のための記事です。Quipper では下記のようなお仕事、技術的課題の解決に興味がある DevOps エンジニアを絶賛大募集しております。興味のある方は、Wantedlyの募集ページ から「話を聞きに行きたい」をクリックしてみてください。応募までは行かないけど、もっと詳しい聞いてみたいという方は私個人にでも良いのでご連絡ください。（Twitter で @hakobera にメンション or DM、または hakoberaアットg
不便さを我慢しないカルチャー - @kyanny's blog
Quipper, 採用は基本的に 24/7 いつでもウェルカム！なんだけど、とはいえ対外的にちゃんと求人を掲載して「募集中ですよ！」とアピールする必要もあるよね、ということで、 Wantedly でソフトウェアエンジニアと DevOps エンジニアの採用を開始した。 Quipperで新しい学びの形を創造したいエンジニアをウォンテッド！ - Quipper Ltdの求人 - Wantedly https://www.wantedly.com/projects/6602 @ffu_ とチャットで「こんなことやります」欄の内容を相談していて、「改めて考えると、自分たち普段いろんなことをどうやってるんだっけ？」と考えた末にひねり出した一文がこれ。 Quipperのエンジニアリングは「生産性」にフォーカスしています。運用に人手のかかるインフラ部分はHerokuやCircleCI等の外部サービスを積極
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Heroku を利用した Quipper の開発事例紹介
