Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to PayPayでのk8s活用事例
Similar to PayPayでのk8s活用事例 (20)
Recently uploaded
Recently uploaded (7)
PayPayでのk8s活用事例
- 1. PayPayでのk8s活用事例 Kubernetes Meetup Tokyo #22 Masaya Ozawa
- 2. Masaya Ozawa/@_M_S_Y_ - Yahoo! JAPAN -> PayPay に出向 - 自分に合うキーボードを探求中 - HHKB -> Thinkpad keyboard ときて、 - 最近キーボードを割りました！
- 7. PayPay株式会社 2018年6月15日 PayPay株式会社設立 2018年10月5日 サービス開始 2018年12月4日〜12月13日 100億円あげちゃうキャンペーン（第1弾） 2019年2月12日〜5月13日 第2弾100億円キャンペーン 2019年6月〜 ワクワクペイペイ開催中！ 2018/07/01 BE App 担当として PayPayに Join 2019/05 platform チーム に 異動
- 12. PayPayのシステム概要 Amazon Aurora ElastiCache Elasticsearch other 4clusterを 環境毎に運用 (dev/stg/perf/prod)
- 19. PayPay での k8s 活用事例
- 20. PayPay の歩み 2018/6/15 2018/10/5 2018/12/4 2019/2/12 2019/6 ~ 100億円あげちゃう キャンペーンリリース 第2弾100億円 キャンペーン ワクワクペイペイ 設立
- 21. PayPay の歩み 2018/6/15 2018/10/5 2018/12/4 2019/2/12 2019/6 ~ 100億円あげちゃう キャンペーンリリース 第2弾100億円 キャンペーン ワクワクペイペイ 設立 環境構築・開発フェーズ
- 22. PayPay の歩み 2018/6/15 2018/10/5 2018/12/4 2019/2/12 2019/6 ~ 100億円あげちゃう キャンペーンリリース 第2弾100億円 キャンペーン ワクワクペイペイ 設立 第１弾キャンペーン実施時
- 25. PayPayでのk8s活用事例 課題 - サービスのCore機能を担うAPIに予想以上のアクセスが。。 解決方法 - サービスを複製(別のdeployment/serviceを用意) - それぞれ、Read 専用/Write 専用として利用 - 中身はすべて一緒、 endpoint だけ呼び分けた - 裏側のDBは、Write -> master/Read -> slave を向けた - 上記対応を、deployment/service/configmap/secret 等の修正で対応
- 26. PayPay の歩み 2018/6/15 2018/10/5 2018/12/4 2019/2/12 2019/6 ~ 100億円あげちゃう キャンペーンリリース 第2弾100億円 キャンペーン ワクワクペイペイ 設立 第２弾キャンペーン準備中
- 28. PayPayでのk8s活用事例 課題 - パフォーマンスチューニングをするまえに、ボトルネックの調査にコストがかかって いる 解決方法 - 全サービスで利用しているBase の Docker Image に、New Relic を追加 - サービス側に特別な対応なしに、可視化を実現を導入！！ - あとは、New Relic を見ながらチューニングを実施
- 29. PayPayでのk8s活用事例 課題 - アプリケーション間の認証を担っているサービスにほとんどの負荷が集中 - このサービスはUser情報を管理しているサービス - 各アプリケーションも、サービスユーザという扱いで上記サービスで管理 - ユーザ情報管理、ユーザの認証、サービス間の認証という役目を担った結果負荷が集中
- 30. PayPayでのk8s活用事例 課題 - アプリケーション間の認証を担っているサービスにほとんどの負荷が集中 - このサービスはUser情報を管理しているサービス - 各アプリケーションも、サービスユーザという扱いで上記サービスで管理 - ユーザ情報管理、ユーザの認証、サービス間の認証という役目を担った結果負荷が集中 解決方法 - 上記サービスから、認証機能のみを切り出す - だが、新規サービスに実装している余裕はなかった - Deployment/Service を新規に作成し、まずは同じイメージを利用しつつ負荷対策 - 結果、認証機能による負荷が分けられ、システムが安定 - システム改善を行う時間が稼げた
- 31. PayPay の歩み 2018/6/15 2018/10/5 2018/12/4 2019/2/12 2019/6 ~ 100億円あげちゃう キャンペーンリリース 第2弾100億円 キャンペーン設立 ワクワクペイペイ 無事乗り切った！
- 32. PayPay の歩み 2018/6/15 2018/10/5 2018/12/4 2019/2/12 2019/6 ~ 100億円あげちゃう キャンペーンリリース 第2弾100億円 キャンペーン ワクワクペイペイ 設立 今何を行っているか！
- 35. PayPay での Kafka - PayPay では、以下の用途に Kafka を利用 - アプリケーション用途 - ログ収集用途
- 36. PayPay での Kafka - ログ収集用途 - PayPay では、以下の様にログを集めています - データのロストを避けるためにログの連携に、 Kafka を利用 Kafka Logstash Elasticsearch 各アプリケーショ ン
- 37. PayPay での Kafka - Kafka での課題 - EC2 上に、自分たちで Kafka を建てて運用をしている - アプリケーション毎の影響を分けようにも、簡単に cluster を増やせない - topic の作成や状況を見るために、 kafka manager 等を見る必要がある
- 38. Kafka on kubernetes - kafka も kubernetes 上に載せてしまえば良いじゃないか - Strimzi を利用することに - https://strimzi.io/ - Customi Resource になっているので、cluster 構築が楽 - Topic の生成も、operator がいるので yaml で定義できる - まずはログ用の cluster から導入し、検証中！
- 39. Canary Release
- 40. 既存のデプロイフロー 1. アプリケーションの修正 2. Jenkins により、build & publish 3. kubernetes の manifests を修正 4. dev 環境にデプロイするための Job を実行 5. stg/performance/production 環境へのデプロイも Job を実行
- 41. 既存のデプロイ周りの課題 - Deploy は、Jenkins 上の Job の実行 - また、deploy するイメージタグは、Jenkins 上から指定できる仕様 - kubernetes 上の状態は、Jenkins の実行結果から導き出さなければならない - 手動の箇所を減らしたい orz
- 42. 既存のデプロイ周りの課題 - どう解決するか? - GitOps - a single source of truth !
- 44. Argo CD とは、 - argo project の中の一つ - Github 上の yaml と k8s 上の状態を揃えるよう な動きをする CRD を提供してくれる - 自分自身のデプロイも可能 - https://argoproj.github.io/argo-cd/ - Gitops !!
- 45. 新しいデプロイフロー ● github を見れば状態がわかる様にしたい ○ 但し、secret 以外 ● production リリースの権限を一部の人に絞りたい ○ 承認をもらった上でリリース
- 46. 新しいデプロイフロー - リポジトリ構成の変更 - Argo CD Application 設定が集まるリポジトリ - アプリケーション毎の、 manifests リポジトリ - Kustomize の Images で、 デプロイイメージを指定するように変更
- 47. 新しいデプロイフロー - branch 戦略 - 以下の2ブランチで運用することに - master - 開発環境やステージング環境へのデプロイに利用 - production - 本番環境へのデプロイに利用 - github team によって、マージ権限を制限
- 48. 新しいデプロイフロー 1. アプリケーションの修正 2. Jenkins で build & publish 3. k8s manifests リポジトリに PR を作成 4. マージでデプロイ 検証が終わり、サービス展開準備中！
- 49. Canary Release
- 50. デプロイ時の課題と要望 - 課題 - Rolling update でのデプロイでは、仕様エラーやレイテンシの劣化などが万が一起きた場合、影響 が 100 % になってしまう - 要望 - 新バージョンを一部だけ出して、新バージョンだけの動作検証をしたい - 新バージョンを一部だけ出した状態で、新バージョンだけのメトリクスを確認したい
- 52. Argo Rollouts とは、 - Deployment に Canary や Blue Green ストラテジを追加してくれる - Rollout という Deployment の拡張のようなリソースを提供してくれる - https://argoproj.github.io/argo-rollouts/
- 53. Canary Service - 要望 - 新バージョンを一部だけ出して、新バージョンだけの動作検証をしたい - 手段 - Canary Service - Rollouts の機能の一つ - Canary デプロイメントを実行するときに、 新しいバージョンのみの動作確認をするために利用 - port-forward などで、動作検証が可能
- 54. Metrics - 要望 - 新バージョンを一部だけ出した状態で、新バージョンだけのメトリクスを確認し たい - 手段 - DATADOG に rollouts-pod-template-hash ラベルの値を送信する - この値で、フィルターをかける - (docker image の tag が取得できればもっと良かった)
- 55. Canary Release - Argo Rollouts の、Canary strategy を利用することで実現 - Canary Service を用意することで、新機能のみの動作検証も可能 - kubernetes の、pod-template-hash ラベルを DATADOG に連携し、 メトリクスの filter として利用 - 現在絶賛導入準備中！
- 56. まとめ
- 57. まとめ - リリースから10 ヶ月少し、サービスを支えるために走ってきました - 大規模キャンペーンを支えるために、短期的な施策も行ってきました - 今は、platform チームとしては改善の時期と捉え、デプロイ周りの改善やミドルウェ アのアーキテクチャの見直しなどを行っています - Kubernetes 周り、まだまだ改善できる点が多々あるので、一緒にやってくれる仲間 を募集しています！
- 58. We are hiring!