こんにちは。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 に携わる方にとって学びに
前置き hakobera.hatenablog.com この記事を公開した当時はまだオープンにできなかったのですが、実はこの記事は2月25日にリリースされたスタディサプリ（受験サプリ）を Quipper のプラットフォームに載せ替えるという移行プロジェクトを前提として内容も含んでいました。 【公式】スタディサプリ｜苦手克服・定期テスト対策～大学受験まで 無事にリリースできたので、このプロジェクトで変わったことや導入したソフトウェア、ツールについていくつかピックアップして書いていきたいと思います。 目次 メンバーが増えた Infra as Code Deis AWS ECS + Docker + Locust による負荷テスト nginx (HTTP/2, ngx_mruby) 分析基盤 技術的課題 メンバーが増えた 前回の記事を書いた時はインフラ関連のエンジニア（Quipper では En
リリース完了 スタディサプリ高校講座/大学受験講座を無事リリースすることができた。 大きなトラブルもなくリリース後数日での「数字」的なものもとりあえず一安心という状況だ。 人生何度ものリリースを経験してきたが、今回のリリースは今までとは違う大変さがあった。 このプロジェクトが始まったのはリクルートの昨年のQuipper買収後少し経ってからになる。既存の受験サプリをQuipperプラットフォームに載せ替えるというのが大きなお題だ。リリース予定は2016年2月末。教育業界、季節性がとても大きいのでこのデッドラインは遅らせることのできない厳しいものだ。 また、今回はシステム面の置き換えだけでなく、受験サプリからスタディサプリへのブランド統合も同時に行った。Quipper開発陣も当然のことながらこれにも関わることになった。 そして、受験サプリからの継続ユーザーもたくさんいるので、課金機能などは既に
注記: なんとなく個人ブログとは切り離したくてgistで始めたのですがあまり意味がなさそうなので統合します。これは ここ に載せたものの転載です。 今回は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人くらいの増強を考えている。拠点毎、職種毎の大まかな計画はあるが、いい人がいたら拠点/職種毎の採
注記: なんとなく個人ブログとは切り離したくてgistで始めたのですがあまり意味がなさそうなので統合します。これは ここ に載せたものの転載です。 これはなに なんとなく始めてみた短期集中のQuipperのCTOブログ。リクルートグループに入り、ますます日本での活動が増えているQuipperなので、CTOとして、開発、プロダクト、サービス、チームに関わることを書いていこうと思っている。今回は、第1回ということで、Quipperの現状について書いてみようと思う。 最近のQuipper関連記事 まず、最近、世の中に出たQuipperについての記事を。 https://newspicks.com/news/1317287/body - 【渡辺雅之×山田進太郎】グローバルスタートアップの世界戦略 https://mirai.doda.jp/series/interview/quipper/ - 生
注記: なんとなく個人ブログとは切り離したくてgistで始めたのですがあまり意味がなさそうなので統合します。これは ここ に載せたものの転載です。 前回、現在のQuipperの状況みたいのを書いたが、今回は、普段CTOとして、どういうことを意識して開発チームを作っているか、どういう開発チームになって欲しいと思っているか、というのを書いてみたいと思う。 この辺り、自分自身の経験からくる「好み」とか「美学」みたいなものが強めな部分でもあるので、表に出すのはなかなか勇気がいるが、co-founder/CTOである自分のそういうところが、開発チームのカルチャーに当然影響しているし、一緒に働くことになる人ととはカルチャーのマッチがとても大事だと思っているので出してみる。 まず、以前、社内でなんとなく書いた文章があるのでそのまま出してみる。これは開発者の採用活動に当たり、どんな人が欲しいと思っているか
技術的課題を書くと、それを解決してくれるエンジニアが採用できるって話は本当ですか？というのは冗談としても、今の技術的課題をブログにまとめて公開するノーガード戦法も良いかと思う。— Kazuyuki Honda (@hakobera) May 25, 2015 このツイートがそれなりに反応があったので、有言実行してみる。 最初に書いておくと、これはQuipperの採用のための記事です。Quipper では下記のようなお仕事、技術的課題の解決に興味がある DevOps エンジニアを絶賛大募集しております。興味のある方は、Wantedlyの募集ページ から「話を聞きに行きたい」をクリックしてみてください。応募までは行かないけど、もっと詳しい聞いてみたいという方は私個人にでも良いのでご連絡ください。（Twitter で @hakobera にメンション or DM、または hakoberaアットg
これ @mizchi がIncrementsにJoinしました - Qiita Blog 特に転職したとは一言も報告してなかったけど、先月末でQuipperを退職し、二週間ほどのモンハン廃人を経て、先週からQiitaを運用しているIncrementsで働いている。 自分が使ってるサービスのドッグフーディングが出来て、将来性があって、大きすぎずに自分の手が届く範囲にやり甲斐があり、JavaScriptエンジニアとして自分にとっての技術的課題がたくさんありそうなIncrementsに行くことにした。 一週間ぐらい働いて、やっと慣れてきて、デプロイももう何度かやったし、Githubのstatsみると一週間で25000行ぐらい書き換えてユーザーの手元に届いてるっぽいんだけど、これは最初に取り組んだのが外部アセットを連結して圧縮したりこねくり回したりしたりするという作業で、作業量以上に行数に出ている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
