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 に移行する必要があって大変 今後の課題