Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Sentry GKEに リプレイス 1年間の 知見見せます / Migrated to GKE...
Search
sue445
May 12, 2021
Technology
0
730
Sentry GKEに リプレイス 1年間の 知見見せます / Migrated to GKE Sentry #pixivdevmeetup
エンジニア勉強会 in PIXIV DEV MEETUP (
https://conference.pixiv.co.jp/2021/dev-meetup
)で喋ったLT資料です。
sue445
May 12, 2021
Tweet
Share
More Decks by sue445
See All by sue445
Road to RubyKaigi 2025 #rubykaigi2026_saisoku
sue445
0
59
Kaigi Effect 2025 #rubykaigi2025_after
sue445
0
1.2k
Road to Go Gem #rubykaigi
sue445
0
1.4k
pixiv Cloud Journey #pixivmeetup
sue445
0
1.4k
Road to RubyKaigi Speaker (case sue445) #rubykaigi2023_after
sue445
0
2.1k
Fix SQL N+1 queries with RuboCop #rubykaigi
sue445
2
5.8k
sue445とOSSと社内ツール #subcul_dev
sue445
0
850
sue445謹製社内ツール十一選 / su445 in-house tools #pixivdevmeetup
sue445
1
500
Ruby on CI #ginzarails
sue445
3
2.6k
Other Decks in Technology
See All in Technology
250627 関西Ruby会議08 前夜祭 RejectKaigi「DJ on Ruby Ver.0.1」
msykd
PRO
2
330
【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術
cygames
0
1.1k
Prox Industries株式会社 会社紹介資料
proxindustries
0
330
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 完全版 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming - Expanded
tomzoh
4
3.3k
Snowflake Summit 2025 データエンジニアリング関連新機能紹介 / Snowflake Summit 2025 What's New about Data Engineering
tiltmax3
0
320
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
190
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
480
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
17
5.7k
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
4
2.6k
Delegating the chores of authenticating users to Keycloak
ahus1
0
130
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
240
OpenHands🤲にContributeしてみた
kotauchisunsun
1
470
Featured
See All Featured
How to Ace a Technical Interview
jacobian
277
23k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Practical Orchestrator
shlominoach
188
11k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Being A Developer After 40
akosma
90
590k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Designing for humans not robots
tammielis
253
25k
Unsuck your backbone
ammeep
671
58k
Writing Fast Ruby
sferik
628
62k
A Tale of Four Properties
chriscoyier
160
23k
Transcript
Sentry GKEに リプレイス 1年間の 知見見せます 2021/05/12 エンジニア勉強会@PIXIV DEV MEETUP pixiv Inc. sue445 2021.5.12
2 自己紹介 • sue445 • 2018年7月入社 ◦ もうすぐ4年目 • インフラ部所属
• #z-アニメ, #z-precure, #z-pretty-series sue445
3 • AWS, GCP, CI, GitLab, Sentry etc… • 最近は各チームがやりたいことに対して
AWS, GCP, オンプレでいくつか案を出してアドバイ スしたり、実際に自分でシステムを構築 • 例)オンプレで動いてたSentryをGKEに移行、Herokuで動いてたアプリをECSに移行 • publicな業務内容: https://inside.pixiv.blog/search?q=sue445 業務内容
4 • AWS, GCP, CI, GitLab, Sentry etc… • 最近は各チームがやりたいことに対して
AWS, GCP, オンプレでいくつか案を出してアドバイ スしたり、実際に自分でシステムを構築 • 例)オンプレで動いてたSentryをGKEに移行、Herokuで動いてたアプリをECSに移行 • publicな業務内容: https://inside.pixiv.blog/search?q=sue445 業務内容
5 • Sentryとは? • 劇的Before/After • リプレイスについて • Datadogで見る1年間 •
Sentryをリプレイスしたことによるメリット • 今後の課題 Agenda
6 • アプリケーションのエラーを収集するウェブアプリ ◦ https://docs.sentry.io/ • クライアントライブラリが充実しててメジャーどころの言語は全部対応してる • SaaS(https://sentry.io/)が有名だが、Sentry自体もOSSなので自分でホスティングするこ ともできる
◦ https://develop.sentry.dev/self-hosted/ ◦ https://github.com/getsentry/onpremise ◦ https://hub.docker.com/r/getsentry/sentry • 似たようなアプリとしてAirbrake, Errbit, RollberなどがあるがSentryが一番メジャーだと思 う Sentryとは?
7 • Before : オンプレのサーバ1台 ◦ そんなにスペックは高くない ◦ アプリとミドルウェア一式がdocker-composeで雑に実行 •
After : 全てGCP ◦ GKE ◦ Cloud SQL for PostgreSQL ◦ Cloud Memorystore for Redis ◦ 業務でGCPやkubernetesを使ったのはこれが初めて 劇的Before/After
8 • オンプレのSentryのスペックがそんなに高くないので、どこかのアプリでエラーが大量に発 生すると高負荷で他アプリにも通知遅延などの影響が出る問題があった • ストレージの容量が逼迫してた ◦ 試算したらこのまま行くと3ヶ月くらいでdisk fullになりそうだったので「100日後 に死ぬサーバです(なので早く新Sentryに移行してください)」って全社アナウン
スした • 2019年末にインフラ部内で来期(FY2020)の予算計画を立てることになって、そのタイミン グでリプレイスすることにした リプレイスの理由
9 • リプレイスの際に下記の3つで検討した ◦ SaaS ◦ Self hosting (オンプレ) ◦
Self hosting (クラウド) • 最終的には「Self hosting (クラウド)」を選択したのだが、そこに至るまでの変遷を紹介 実装&選択方針
10 • オンプレ単一サーバ構成 ◦ 構成が同じだとスペックだけ上げてもいずれは頭打ちになるのでスケールアウト をしたい • オンプレ複数サーバ構成 ◦ SentryがDockerイメージ利用を推奨してるのだが、オンプレで
Dockerのクラス タを自前で管理しようとすると実行環境以外にもサーバが必要で台数がかさむ ◦ kubernetesだとクラスタの管理で最低3台必要になる • オンプレだとアプリで急激にエラーが増えた場合に増設しづらい 【ボツ案】Self hosting (オンプレ)
11 • SaaS案だと旧Sentryのイベント数(2019年末時点で1,500万イベント)で月1万ドルの試算 になったので費用感が合わなかった • 問い合わせたらディスカウントでも月 2,800ドルくらいだった ◦ 費用面だけならGKE案と割といい線いってた •
アプリからパスワードなどの機微情報を含むエラーが送られた場合に sentry.ioに機微情報 が保存されてしまうので、(オンプレ使うにしろクラウド使うにしろ) SaaSよりも自前のサーバ で管理するのがよいと判断 【ボツ案】SaaS
12 • クラウドのフルマネージドのDockerクラスタで作るのが前述の問題を解決でき、アーキテク チャ的にも筋が良さそうだった ◦ SentryのHelm chartがあったのが一番大きい(後述) • この時点でEKS(AWSのKubernetes)かGKE(GCPのKubernetes)の二択になったが、自分 自身とインフラ部内でのGCPの運用経験値を貯めるためにGKEを選択した
◦ 「知らないからやらなかったら一生新しいことはできない」 が持論なので、敢えて やったことないものを使いたかった ◦ EKSとGKEで費用的にはそんなに変わらなかった 【採用】Self hosting (クラウド)
13 GKE版Sentryの構成 Cloud SQL (PostgreSQL) Cloud Memorystore (redis) GCS GKE
node x 20台以上 pod x 60〜100台くらい
14 • ウェブアプリケーションが動く環境を全部作った ◦ 新sentryのドメイン取得 ◦ GCPのプロジェクトを作成してインフラを全て作った ◦ Sentry本体のデプロイ sue445がやったこと
15 • 2020年1月:新Sentryの開発開始 • 2020年2月:本番環境が完成し、一部のアプリのみ新 Sentryを開放 ◦ 自分がメンテしてたアプリと旧Sentryで一番エラーの多かったアプリ • 2020年3月:新Sentryを全社に開放
リリースノート
16 • GCPもkubernetesも全く分からない状態 • Google App Engineは趣味で多少使ったことはあったけど、 GCPのプロジェクト全体をガッ ツリ触ったのは今回が初めて •
1ヶ月でブラウザで一通り動く状態の開発環境を作りきった 開発当初のsue445の経験値
17 https://www.credential.net/9643f19d-5584-40b6-a330-5b966a26f310 【余談】GCP赤ちゃんの状態から1年で認定資格をとった
18 • Terraformリポジトリ:GCPのインフラ全般 ◦ Deployment Manager(GCP公式の構成管理ツール)を使うという選択肢もあっ たが、TerraformだとAWSとGCPの両方に対応していて運用コストや学習コスト が抑えられた ◦ ピクシブではAWSとGCPの両方運用してるので同じツールでやりたい
• Dockerイメージ:アプリケーション本体 ◦ 公式のDockerイメージだとGCS対応に必要なライブラリがなくて自分でビルドし た • デプロイ用リポジトリ:アプリケーションの実行環境 ◦ KubernetesにはHelmという公式パッケージマネージャがあり、そこで配布され てるHelm chartをCIでデプロイしてる 作ったもの
19 • 開発環境:masterブランチが自動デプロイ、必要に応じてトピックブランチを手動デプロイ • 本番環境:必要に応じてmasterブランチを手動デプロイする デプロイフロー
20 1. 最初はdevelopブランチを開発環境に自動デプロイ、 masterブランチをproductionに自動 デプロイにしてたのだが、git-flowが社内ではあまり浸透してなくて自分以外がブランチ運 用できる気がしないので途中でやめた 2. 次は開発環境と本番両方手動デプロイにしてたのが、開発環境デプロイするのに毎回デプ ロイボタンをポチるのが面倒なのでやめた 3.
そして今の構成(開発環境は自動 or手動デプロイ、本番環境は手動デプロイ)に落ち着い た デプロイフローの歴史
21 • 1年間運用してどのように成長したのかを紹介 Datadogで見る1年間
22 • オートスケールによって常時20〜30台くらい稼働してる • VMが増えすぎるとDatadogのコストになるため台数が増えすぎないように VMをスペック アップしてる • 例)「n1-standard-1のVM2台」と「n1-standard-2のVM1台」とではGCEの金額は同じなの だが、Datadog
agentは監視する台数によって変わるので後者の方が安くなる GKE: node(VM)
23 • GKEのnode全体で初期は20コアくらい、 今は200コアくらい • 去年6月に増えてるのはpodが自動で増えずに無理やり増やしたため GKE: vCPU
24 • GKEのnode全体で200〜400GBくらい • 4月にガクッと減ってるのは、nodeのスペックを調整したため(後述) GKE: Memory
25 • Sentryのpodのスペックを細かく調整していった結果、 CPUに対してメモリが無駄になってた ので調整した • Before: n1-highmem-8 (メモリ52GB) •
After: n1-custom-16-30720 (n1-standard-16の半分のメモリ) GKE: Memory
26 • web(httpのリクエストを受けるpod)が50〜60個、worker(エラーをバックグラウンドで処理す るpod)が20〜30個くらい GKE: pods
27 • 1年間で約100GBくらい • 上の線がCloud SQLに割り当てられたストレージサイズで、下の線が実際に使用してるスト レージサイズ。(容量逼迫すると自動でストレージが増えて便利) Cloud SQL(PostgreSQL): ストレージ
28 • 100〜200万くらいのkey • 一気にKeyが0になってるのはSentryのqueueが詰まってRedisのメモリが溢れて死んだ時 や、メモリが溢れる直前にflushallした時 Memorystore (Redis): Keyの数
29 • 今はだいたい200万くらいのオブジェクト数 • Datadogだとバケット全体のサイズが取れないので GCPのコンソールで確認したら66GiBく らいだった GCS: オブジェクト数
30 • リプレイス前はオンプレサーバのストレージサイズを逼迫してたが、リプレイス後は Cloud SQLやGCSにデータが保存されるので容量問題が完全に解決した • 全てをクラウドに移したことにより Sentry全体のスペック変更がしやすくなった • GKEのオートスケールにより社内の利用状況やエラーの量によって自動でサーバが増減
するようになった • インフラ部内でのGCPやKubernetesの運用経験値が上がった Sentryをリプレイスしたことによるメリット
31 • GKEのオートスケールで無限にサーバを増やせると思ったが、サーバを増やしすぎると DB やRedisが高負荷になってSentryの挙動がおかしくなるのであまり増やせない ◦ 特にSentryはRedisをヘビーに使ってる ◦ DBやRedisのスペックを上げるとお金がかかる •
pgbouncerを入れてPostgreSQLのコネクションをプールしてるのだが、 INSERT時には効 かないのでエラーが大量に飛んできた時に PostgreSQLのコネクションが枯渇する Sentryを1年間運用しての学び
32 • サーバサイドのエラーよりもフロントエンドのエラーの方が Sentryに飛んでくる圧倒的にエ ラーが多い ◦ サーバサイドのエラーは送信元がピクシブのサーバだけだが、フロントエンドの エラーはユーザのブラウザからSentryにリクエストが飛んでくるため ◦ アプリだけじゃなく広告系のjsがエラーになってもSentryにエラーが飛んでくるの
でつらい ◦ jsのエラーが大量発生した時にSentryが死ぬことがしょっちゅうあったので ReteLimitを設定するようにしてる Sentryを1年間運用しての学び
33 • Sentryのメジャーバージョンアップ ◦ 今ピクシブで使ってるのは9系なので最新まで上げたいのだが、今使ってる helm chart( https://github.com/helm/charts/tree/master/stable/sentry ) だと最新版に対応していないので
https://github.com/sentry-kubernetes/charts に移行する必要があって大変 今後の課題