こんにちは。 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

こんにちは。SRE の @chaspy です。 Quipper では Kubernetes Horizontal Pod Autoscaler (以下、HPA) を利用して Pod のオートスケーリングを実現しています。 HPA は非常に便利で、ほとんどのトラフィック増減に対応できます。しかし、オートスケーリングの宿命ではありますが、突発的なアクセス、いわゆるスパイクアクセスにはどうしても対応できません。CPU 利用率が急激に上がり、HPA がすぐに Desired Replicas を増やしたとしても、Node*1 のスケールアウトに5分程度はかかってしまいます。 CPU 使用率に基づくオートスケーリングに対して、決まった時間に決まった個数を事前にスケールしておくことを Scheduled-Scaling と呼ぶことにしましょう。前者のオートスケーリングと併用して Scheduled-S

こんにちは。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 に携わる方にとって学びに

こんにちは。SRE の @chaspy です。 みなさん Kubernetes Horizontal Pod Autoscaler は使っていますか？Quipper では先月導入したところ、便利すぎて仕事を奪われてしまいました。 本記事では、Horizontal Pod Autoscaler（以下 HPA）の基本原理を簡単に説明したのち、実運用で導入する際の注意点について話そうと思います。 HPA とは何か 名前のままではありますが、Pod を水平方向（Horizontal）に自動的にスケールしてくれる君です。 対になる存在として、垂直方向にスケールする Virtical Pod Autoscaler も存在します。Resource request を動的に変更してくれる君ですね。こちらは未導入です。*1 なぜ HPA を導入したのか 教育サービスということで、基本的にトラフィックの傾向は

こんにちは。@hotchemiです。 今回は、最近始まったQuipperのAlumni Network(卒業生ネットワーク)についてご紹介できればと思います。 Alumni Networkとは ALLIANCE　アライアンス―――人と企業が信頼で結ばれる新しい雇用より引用します。 ７、会社は「卒業生」ネットワークを作ろう 卒業生ネットワークをつくり、退職した人ともいい関係を作っておくことは双方にとってメリットがある。 会社にとっては、やめた人から人材を紹介してもらえる、出戻りの率があがる、情報を教えてもらえる、顧客を紹介してもらえるなど。 退職者にとっては会社から転職先を紹介してもらえる、退職者同士のネットワークが使える、やめた企業から仕事をもらえるなど。 現役、退職した人の両方を含めたネットワークをオンラインでつくる、定期的にイベントを開催して食事代の費用を負担するなどのそれほど大きくな

はじめまして、Web Engineer の @ywada526 です。 8月から Quipper で働いています。 今日日、データ分析への関心の高まりなどから、"Fact based" の考え方が広く普及し、ビジネスの世界では一般化してきているように思います。 Quipper でも "Fact based" が行動指針のひとつとなっており、日々実践されています。 ( 過去のブログで Quipper における "Fact based" の実践例 が紹介されていますので、ご興味のある方はこちらも併せてご覧ください。) 他方、一般化のゆえ、無批判に信仰されたり、言葉がひとり歩きしたりして、"Fact based" 自体が目的になってしまっている向きもあるように思えます。 今回は、"Fact based" が気になっている方向けに、"Fact based" でありがちな失敗をライトに紹介していきた

こんにちは、データグループのマネージャーをやっています beniyama と申します。 先の記事『プロダクトの「負債」を「機能」と呼び直す 〜A/Bテストを用いた"価値"の定量化〜』でも触れられていますが、データグループではデータ分析基盤の構築（参考資料）からデータ分析、あるいは学習データを活用した研究開発までスタディサプリのデータに関わることほとんど全てを担当しています。 プロダクトや事業 KPI の社内向けモニタリング環境の構築・整備も行なっているのですが、今回、既存の環境を刷新して Looker というまだ日本ではほとんど無名？のツールを導入することにしましたのでその経緯をお話ししつつ、今後国内でもユーザーが増えていくといいなという願いを込めて１エンジニアとして興奮したポイントを書き連ねていこうと思います。 最初の１年間は DOMO を導入して運用 スタディサプリではもともと各種 K