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
630
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
pixiv Cloud Journey #pixivmeetup
sue445
0
1.2k
Road to RubyKaigi Speaker (case sue445) #rubykaigi2023_after
sue445
0
1.7k
Fix SQL N+1 queries with RuboCop #rubykaigi
sue445
2
5.2k
sue445とOSSと社内ツール #subcul_dev
sue445
0
790
sue445謹製社内ツール十一選 / su445 in-house tools #pixivdevmeetup
sue445
1
430
Ruby on CI #ginzarails
sue445
3
2.4k
Best practices in web API client development #RubyKaigi
sue445
13
15k
スペックを上げてクラウドで殴るCI / pixiv TECH SALON #pixivTECHSALON
sue445
10
15k
OSS雑メンテ / OSS zatsu maintenance #railsdm
sue445
3
4.1k
Other Decks in Technology
See All in Technology
製造現場のデジタル化における課題とPLC Data to Cloudによる新しいアプローチ
hamadakoji
0
210
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
1
230
全社横断データ活用推進のコツと その負債とのつき合い方
masatoshi0205
0
170
Lambdaと地方とコミュニティ
miu_crescent
2
240
dev 補講: プロダクトセキュリティ / Product security overview
wa6sn
0
1.6k
マイベストのデータ基盤の現在と未来 / mybest-data-infra-asis-tobe
mybestinc
2
1.9k
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
110
AI長期記憶システム構築のための LLMマルチエージェントの取り組み / Awarefy-LLM-Multi-Agent
iktakahiro
2
350
Engineering at LY Corporation
lycorp_recruit_jp
0
320
音声×Copilot オンコパの世界
kasada
1
110
10分でわかるfreeeのQA
freee
1
3.5k
第23回Ques_タイミーにおけるQAチームの在り方 / QA Team in Timee
takeyaqa
0
190
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
How STYLIGHT went responsive
nonsquared
95
5.2k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Documentation Writing (for coders)
carmenintech
65
4.4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Git: the NoSQL Database
bkeepers
PRO
427
64k
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 に移行する必要があって大変 今後の課題