Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sentry GKEに リプレイス 1年間の 知見見せます / Migrated to GKE Sentry #pixivdevmeetup

Sentry GKEに リプレイス 1年間の 知見見せます / Migrated to GKE Sentry #pixivdevmeetup

エンジニア勉強会 in PIXIV DEV MEETUP ( https://conference.pixiv.co.jp/2021/dev-meetup )で喋ったLT資料です。

sue445
PRO

May 12, 2021
Tweet

More Decks by sue445

Other Decks in Technology

Transcript

  1. Sentry GKEに リプレイス
    1年間の 知見見せます
    2021/05/12 エンジニア勉強会@PIXIV DEV MEETUP
    pixiv Inc.
    sue445
    2021.5.12

    View Slide

  2. 2
    自己紹介
    ● sue445
    ● 2018年7月入社
    ○ もうすぐ4年目
    ● インフラ部所属
    ● #z-アニメ, #z-precure, #z-pretty-series
    sue445

    View Slide

  3. 3
    ● AWS, GCP, CI, GitLab, Sentry etc…
    ● 最近は各チームがやりたいことに対して
    AWS, GCP, オンプレでいくつか案を出してアドバイ
    スしたり、実際に自分でシステムを構築
    ● 例)オンプレで動いてたSentryをGKEに移行、Herokuで動いてたアプリをECSに移行
    ● publicな業務内容: https://inside.pixiv.blog/search?q=sue445
    業務内容

    View Slide

  4. 4
    ● AWS, GCP, CI, GitLab, Sentry etc…
    ● 最近は各チームがやりたいことに対して
    AWS, GCP, オンプレでいくつか案を出してアドバイ
    スしたり、実際に自分でシステムを構築
    ● 例)オンプレで動いてたSentryをGKEに移行、Herokuで動いてたアプリをECSに移行
    ● publicな業務内容: https://inside.pixiv.blog/search?q=sue445
    業務内容

    View Slide

  5. 5
    ● Sentryとは?
    ● 劇的Before/After
    ● リプレイスについて
    ● Datadogで見る1年間
    ● Sentryをリプレイスしたことによるメリット
    ● 今後の課題
    Agenda

    View Slide

  6. 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とは?

    View Slide

  7. 7
    ● Before : オンプレのサーバ1台
    ○ そんなにスペックは高くない
    ○ アプリとミドルウェア一式がdocker-composeで雑に実行
    ● After : 全てGCP
    ○ GKE
    ○ Cloud SQL for PostgreSQL
    ○ Cloud Memorystore for Redis
    ○ 業務でGCPやkubernetesを使ったのはこれが初めて
    劇的Before/After

    View Slide

  8. 8
    ● オンプレのSentryのスペックがそんなに高くないので、どこかのアプリでエラーが大量に発
    生すると高負荷で他アプリにも通知遅延などの影響が出る問題があった
    ● ストレージの容量が逼迫してた
    ○ 試算したらこのまま行くと3ヶ月くらいでdisk fullになりそうだったので「100日後
    に死ぬサーバです(なので早く新Sentryに移行してください)」って全社アナウン
    スした
    ● 2019年末にインフラ部内で来期(FY2020)の予算計画を立てることになって、そのタイミン
    グでリプレイスすることにした
    リプレイスの理由

    View Slide

  9. 9
    ● リプレイスの際に下記の3つで検討した
    ○ SaaS
    ○ Self hosting (オンプレ)
    ○ Self hosting (クラウド)
    ● 最終的には「Self hosting (クラウド)」を選択したのだが、そこに至るまでの変遷を紹介
    実装&選択方針

    View Slide

  10. 10
    ● オンプレ単一サーバ構成
    ○ 構成が同じだとスペックだけ上げてもいずれは頭打ちになるのでスケールアウト
    をしたい
    ● オンプレ複数サーバ構成
    ○ SentryがDockerイメージ利用を推奨してるのだが、オンプレで
    Dockerのクラス
    タを自前で管理しようとすると実行環境以外にもサーバが必要で台数がかさむ
    ○ kubernetesだとクラスタの管理で最低3台必要になる
    ● オンプレだとアプリで急激にエラーが増えた場合に増設しづらい
    【ボツ案】Self hosting (オンプレ)

    View Slide

  11. 11
    ● SaaS案だと旧Sentryのイベント数(2019年末時点で1,500万イベント)で月1万ドルの試算
    になったので費用感が合わなかった
    ● 問い合わせたらディスカウントでも月
    2,800ドルくらいだった
    ○ 費用面だけならGKE案と割といい線いってた
    ● アプリからパスワードなどの機微情報を含むエラーが送られた場合に
    sentry.ioに機微情報
    が保存されてしまうので、(オンプレ使うにしろクラウド使うにしろ)
    SaaSよりも自前のサーバ
    で管理するのがよいと判断
    【ボツ案】SaaS

    View Slide

  12. 12
    ● クラウドのフルマネージドのDockerクラスタで作るのが前述の問題を解決でき、アーキテク
    チャ的にも筋が良さそうだった
    ○ SentryのHelm chartがあったのが一番大きい(後述)
    ● この時点でEKS(AWSのKubernetes)かGKE(GCPのKubernetes)の二択になったが、自分
    自身とインフラ部内でのGCPの運用経験値を貯めるためにGKEを選択した
    ○ 「知らないからやらなかったら一生新しいことはできない」 が持論なので、敢えて
    やったことないものを使いたかった
    ○ EKSとGKEで費用的にはそんなに変わらなかった
    【採用】Self hosting (クラウド)

    View Slide

  13. 13
    GKE版Sentryの構成
    Cloud SQL
    (PostgreSQL)
    Cloud Memorystore
    (redis)
    GCS
    GKE
    node x 20台以上
    pod x 60〜100台くらい

    View Slide

  14. 14
    ● ウェブアプリケーションが動く環境を全部作った
    ○ 新sentryのドメイン取得
    ○ GCPのプロジェクトを作成してインフラを全て作った
    ○ Sentry本体のデプロイ
    sue445がやったこと

    View Slide

  15. 15
    ● 2020年1月:新Sentryの開発開始
    ● 2020年2月:本番環境が完成し、一部のアプリのみ新
    Sentryを開放
    ○ 自分がメンテしてたアプリと旧Sentryで一番エラーの多かったアプリ
    ● 2020年3月:新Sentryを全社に開放
    リリースノート

    View Slide

  16. 16
    ● GCPもkubernetesも全く分からない状態
    ● Google App Engineは趣味で多少使ったことはあったけど、
    GCPのプロジェクト全体をガッ
    ツリ触ったのは今回が初めて
    ● 1ヶ月でブラウザで一通り動く状態の開発環境を作りきった
    開発当初のsue445の経験値

    View Slide

  17. 17
    https://www.credential.net/9643f19d-5584-40b6-a330-5b966a26f310
    【余談】GCP赤ちゃんの状態から1年で認定資格をとった

    View Slide

  18. 18
    ● Terraformリポジトリ:GCPのインフラ全般
    ○ Deployment Manager(GCP公式の構成管理ツール)を使うという選択肢もあっ
    たが、TerraformだとAWSとGCPの両方に対応していて運用コストや学習コスト
    が抑えられた
    ○ ピクシブではAWSとGCPの両方運用してるので同じツールでやりたい
    ● Dockerイメージ:アプリケーション本体
    ○ 公式のDockerイメージだとGCS対応に必要なライブラリがなくて自分でビルドし

    ● デプロイ用リポジトリ:アプリケーションの実行環境
    ○ KubernetesにはHelmという公式パッケージマネージャがあり、そこで配布され
    てるHelm chartをCIでデプロイしてる
    作ったもの

    View Slide

  19. 19
    ● 開発環境:masterブランチが自動デプロイ、必要に応じてトピックブランチを手動デプロイ
    ● 本番環境:必要に応じてmasterブランチを手動デプロイする
    デプロイフロー

    View Slide

  20. 20
    1. 最初はdevelopブランチを開発環境に自動デプロイ、
    masterブランチをproductionに自動
    デプロイにしてたのだが、git-flowが社内ではあまり浸透してなくて自分以外がブランチ運
    用できる気がしないので途中でやめた
    2. 次は開発環境と本番両方手動デプロイにしてたのが、開発環境デプロイするのに毎回デプ
    ロイボタンをポチるのが面倒なのでやめた
    3. そして今の構成(開発環境は自動
    or手動デプロイ、本番環境は手動デプロイ)に落ち着い

    デプロイフローの歴史

    View Slide

  21. 21
    ● 1年間運用してどのように成長したのかを紹介
    Datadogで見る1年間

    View Slide

  22. 22
    ● オートスケールによって常時20〜30台くらい稼働してる
    ● VMが増えすぎるとDatadogのコストになるため台数が増えすぎないように
    VMをスペック
    アップしてる
    ● 例)「n1-standard-1のVM2台」と「n1-standard-2のVM1台」とではGCEの金額は同じなの
    だが、Datadog agentは監視する台数によって変わるので後者の方が安くなる
    GKE: node(VM)

    View Slide

  23. 23
    ● GKEのnode全体で初期は20コアくらい、 今は200コアくらい
    ● 去年6月に増えてるのはpodが自動で増えずに無理やり増やしたため
    GKE: vCPU

    View Slide

  24. 24
    ● GKEのnode全体で200〜400GBくらい
    ● 4月にガクッと減ってるのは、nodeのスペックを調整したため(後述)
    GKE: Memory

    View Slide

  25. 25
    ● Sentryのpodのスペックを細かく調整していった結果、
    CPUに対してメモリが無駄になってた
    ので調整した
    ● Before: n1-highmem-8 (メモリ52GB)
    ● After: n1-custom-16-30720 (n1-standard-16の半分のメモリ)
    GKE: Memory

    View Slide

  26. 26
    ● web(httpのリクエストを受けるpod)が50〜60個、worker(エラーをバックグラウンドで処理す
    るpod)が20〜30個くらい
    GKE: pods

    View Slide

  27. 27
    ● 1年間で約100GBくらい
    ● 上の線がCloud SQLに割り当てられたストレージサイズで、下の線が実際に使用してるスト
    レージサイズ。(容量逼迫すると自動でストレージが増えて便利)
    Cloud SQL(PostgreSQL): ストレージ

    View Slide

  28. 28
    ● 100〜200万くらいのkey
    ● 一気にKeyが0になってるのはSentryのqueueが詰まってRedisのメモリが溢れて死んだ時
    や、メモリが溢れる直前にflushallした時
    Memorystore (Redis): Keyの数

    View Slide

  29. 29
    ● 今はだいたい200万くらいのオブジェクト数
    ● Datadogだとバケット全体のサイズが取れないので
    GCPのコンソールで確認したら66GiBく
    らいだった
    GCS: オブジェクト数

    View Slide

  30. 30
    ● リプレイス前はオンプレサーバのストレージサイズを逼迫してたが、リプレイス後は
    Cloud
    SQLやGCSにデータが保存されるので容量問題が完全に解決した
    ● 全てをクラウドに移したことにより
    Sentry全体のスペック変更がしやすくなった
    ● GKEのオートスケールにより社内の利用状況やエラーの量によって自動でサーバが増減
    するようになった
    ● インフラ部内でのGCPやKubernetesの運用経験値が上がった
    Sentryをリプレイスしたことによるメリット

    View Slide

  31. 31
    ● GKEのオートスケールで無限にサーバを増やせると思ったが、サーバを増やしすぎると
    DB
    やRedisが高負荷になってSentryの挙動がおかしくなるのであまり増やせない
    ○ 特にSentryはRedisをヘビーに使ってる
    ○ DBやRedisのスペックを上げるとお金がかかる
    ● pgbouncerを入れてPostgreSQLのコネクションをプールしてるのだが、
    INSERT時には効
    かないのでエラーが大量に飛んできた時に
    PostgreSQLのコネクションが枯渇する
    Sentryを1年間運用しての学び

    View Slide

  32. 32
    ● サーバサイドのエラーよりもフロントエンドのエラーの方が
    Sentryに飛んでくる圧倒的にエ
    ラーが多い
    ○ サーバサイドのエラーは送信元がピクシブのサーバだけだが、フロントエンドの
    エラーはユーザのブラウザからSentryにリクエストが飛んでくるため
    ○ アプリだけじゃなく広告系のjsがエラーになってもSentryにエラーが飛んでくるの
    でつらい
    ○ jsのエラーが大量発生した時にSentryが死ぬことがしょっちゅうあったので
    ReteLimitを設定するようにしてる
    Sentryを1年間運用しての学び

    View Slide

  33. 33
    ● Sentryのメジャーバージョンアップ
    ○ 今ピクシブで使ってるのは9系なので最新まで上げたいのだが、今使ってる
    helm chart( https://github.com/helm/charts/tree/master/stable/sentry )
    だと最新版に対応していないので
    https://github.com/sentry-kubernetes/charts に移行する必要があって大変
    今後の課題

    View Slide