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

CASH を支える Google Kubernetes Engine

Bank, Inc
October 09, 2018
2.4k

CASH を支える Google Kubernetes Engine

Google Cloud Next 2018 in Tokyo で発表資料です.

Bank, Inc

October 09, 2018
Tweet

Transcript

  1. D2-3-S08
    CASH を支える
    Google Kubernetes Engine
    高橋 拓也
    中村 勇介
    株式会社バンク
    SokoP Urasoko
    Google Cloud
    2018/09/20

    View Slide

  2. Happy?

    View Slide

  3. SokoP
    (sokopiː)

    View Slide

  4. Happy?
    SokoP
    GCP!

    View Slide

  5. SokoP Urasoko
    Google Cloud
    カスタマーエンジニア
    業務系 Web アプリ開発からクラウド業界に転身。複数
    のクラウドプラットフォームに関わりながら現在にいた
    る。趣味はスノーボード、スケートボード、ランニング。
    28 km 走って出勤した経験あり。
    Speaker

    View Slide

  6. Happy?

    View Slide

  7. View Slide

  8. View Slide

  9. 高橋 拓也
    株式会社バンク
    (サーバサイド | クラウドインフラ)エンジニア
    2018 年 5 月ジョイン
    インフラエンジニアとしてプライベートクラウドを作った
    後,サービスロジックを書きたくて入社
    サーバサイド,インフラの両面から
    サービスをより良くしようと奮闘中
    Speaker

    View Slide

  10. 中村 勇介 (うなすけ)
    株式会社バンク
    エンジニア
    2018 年 2 月入社。 Rails アプリが GKE 上で運用
    されているという部分に魅力を感じ入社を決意
    主に Rails によるアプリケーション開発を担当
    Photo
    Speaker

    View Slide

  11. ● 事業紹介
    ● BANK におけるインフラのミッション
    ● CASH を支えるインフラストラクチャ
    ○ 開発環境
    ○ CI/CD
    ○ プロダクション環境
    ● CASH を支えるアプリケーション開発
    ● BANK を支えるエンジニア文化
    ● まとめ
    Agenda

    View Slide

  12. 1 事業紹介

    View Slide

  13. View Slide

  14. View Slide

  15. View Slide

  16. image

    View Slide

  17. View Slide

  18. 2 BANK における
    インフラのミッション

    View Slide

  19. 僕たちはスタートアップです

    View Slide

  20. 13 回
    1 日のプロダクションデプロイ回数

    View Slide

  21. すごくはやい

    View Slide

  22. ● デプロイは承認制
    ● リリースは月に一度まとめて
    ● リリースごとに手順書の作成とレビュー
    ● 膨大なリリース前テスト項目の手動実施

    View Slide

  23. ● デプロイは承認制
    ● リリースは月に一度まとめて
    ● リリースごとに手順書の作成とレビュー
    ● 膨大なリリース前テスト項目の手動実施
    重罪

    View Slide

  24. ミッション
    開発スピードを最大化する

    View Slide

  25. 2 CASH を支える
    インフラストラクチャ

    View Slide

  26. 開発環境

    View Slide

  27. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud Load
    Balancing
    Cloud SQL
    Replica
    end
    point
    GKE node

    View Slide

  28. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud SQL
    Replica
    CI により
    PR 番号ごとに
    api サーバが
    デプロイされる
    end
    point
    Cloud Load
    Balancing
    GKE node

    View Slide

  29. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud SQL
    Replica
    すべての api サーバは
    同一の DB を向いている
    end
    point
    Cloud Load
    Balancing
    GKE node

    View Slide

  30. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud SQL
    Replica
    end
    point
    外部疎通に
    nghttpx ingress controller
    を利用
    Cloud Load
    Balancing
    GKE node

    View Slide

  31. Ingress
    ● Kubernetes にデプロイしたアプリケーションを
    外部公開するために利用するリソース
    ● インターフェースのみを定義し,
    実際の疎通のための実装は Ingress Controller に任せる
    ● GKE では ingress-gce を利用して,
    HTTPS LoadBalancer を自動作成できる
    ○ プロダクション環境ではこちらを利用

    View Slide

  32. ● 爆速開発環境構築には不向き
    ○ リソース新規作成 → UP になるまでが遅い
    ■ 平均 10 分 ~ 15 分
    ○ 1 リソースにつき 1 グローバル IP を利用する
    ■ 都度 DNS 登録が必要
    ● DNS 反映の待ち時間がかかる
    なぜ開発環境で ingress-gce を使わない?

    View Slide

  33. ● ゼットラボ株式会社が開発している OSS
    ○ https://github.com/zlabjp/nghttpx-ingress-lb
    ○ L7 loadbalancer として nghttpx を利用
    ■ HTTP/2 利用可能
    ■ grpc 対応
    ● 比較検討の結果,動作が安定していたため採用
    nghttpx ingress controller

    View Slide

  34. nghttpx ingress controller
    ● host の Port:443 を直接 Bind して外部公開
    ● L4 LoadBalancer を作成し,GKE Node の 443 をバランシング
    ● L4 LoadBalancer の IP をワイルドカードで DNS 登録
    ○ HostHeader を見て nghttpx が適切な svc へバランシング
    pr-100-api
    nghttpx
    ingress
    controller
    Cloud Load
    Balancing
    https://pr-100-api.example.com
    443
    80
    GKE node
    *.example.com:443

    View Slide

  35. nghttpx ingress controller
    pr-100-api
    nghttpx
    ingress
    controller
    Cloud Load
    Balancing
    https://pr-100-api.example.com
    443
    80
    GKE node
    *.example.com:443
    ● host の Port:443 を直接 Bind して外部公開
    ● L4 LoadBalancer を作成し,GKE Node の 443 をバランシング
    ● L4 LoadBalancer の IP をワイルドカードで DNS 登録
    ○ HostHeader を見て nghttpx が適切な svc へバランシング
    API の UP までの時間を
    15分 → 10秒に短縮

    View Slide

  36. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud SQL
    Replica
    end
    point
    外部疎通に
    nghttpx ingress controller
    を利用
    Cloud Load
    Balancing
    GKE node

    View Slide

  37. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud SQL
    Replica
    使用可能な
    api サーバの
    エンドポイントを配信
    end
    point
    Cloud Load
    Balancing
    GKE node

    View Slide

  38. デバッグ用エンドポイント取得 API
    1. APIの向き先変更のために,iOSアプリのビルドが必要だった
    2. URL を配信するだけの API を作成し,アプリで利用する
    a. https://github.com/bank/k8s-ingress-exporter
    b. Ingress Resources を取得し配信する

    View Slide

  39. エンドポイント取得

    View Slide

  40. デバッグモードで利用

    View Slide

  41. デバッグモードで利用
    APIデバッグのための
    アプリビルドがゼロに

    View Slide

  42. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud SQL
    Replica
    使用可能な
    API サーバの
    エンドポイントを配信
    end
    point
    Cloud Load
    Balancing
    GKE node

    View Slide

  43. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    Cloud SQL
    Replica
    end
    point
    Cloud Load
    Balancing
    nghttpx ingress で
    デプロイ時間大幅短縮
    endpoint api で
    アプリビルド時間をゼロに
    開発環境自動構築で
    環境構築コスト大幅ダウン

    View Slide

  44. CI/CD

    View Slide

  45. build
    build node
    Container
    Registry
    app node
    pr-100-api
    RSpec

    View Slide

  46. build
    build node
    Container
    Registry
    app node
    pr-100-api
    PullRequest を
    作成
    RSpec

    View Slide

  47. build
    build node
    Container
    Registry
    app node
    pr-100-api
    CircleCI を kick
    RSpec

    View Slide

  48. build
    build node
    Container
    Registry
    app node
    pr-100-api
    Build サーバに
    リクエスト
    RSpec

    View Slide

  49. build
    build node
    Container
    Registry
    app node
    pr-100-api
    GKE 上の
    Build サーバで
    Image Build & Push
    CircleCI 上で
    Rspec を実行
    RSpec

    View Slide

  50. build
    build node
    Container
    Registry
    app node
    pr-100-api
    GKE 上の
    Build サーバで
    Image Build & Push
    CircleCI 上で
    Rspec を実行
    この 2 つを
    非同期実行
    RSpec

    View Slide

  51. ● Build サーバ登場前は,開発マシン (Mac) でビルド & プッシュ
    ○ いらないものが Image に紛れ込むことも...
    ● CircleCI の Image Build では Layer Cache が利用できず遅い
    ○ ローカルだと 10秒なのに 5分くらいかかる
    ○ Cloud Build も同様
    ● Pull -> Build -> Push するだけのシンプルな API を作成
    ○ https://github.com/takutakahashi/k8s-docker-image-builder
    Build サーバ

    View Slide

  52. View Slide

  53. View Slide

  54. CI にかかる時間が
    7 ~ 10分 → 3 ~ 5分に!

    View Slide

  55. build
    build node
    Container
    Registry
    app node
    pr-100-api
    GKE 上の
    Build サーバで
    Image Build & Push
    CircleCI 上で
    Rspec を実行
    この 2 つを
    非同期実行
    RSpec

    View Slide

  56. build
    build node
    Container
    Registry
    app node
    pr-100-api
    Helm を使って
    開発環境を自動デプロイ
    RSpec

    View Slide

  57. Helm
    ● k8s における Package Manager
    ○ CentOS でいう yum
    ○ template 化した k8s yaml をまとめた
    Chart を作成して利用する
    ● k8s に簡単にアプリケーションをデプロイ可能

    View Slide

  58. Helm
    ● api の repository に chart を commit してある
    ● こんな感じで実行する
    ○ --set-string で value の override が可能
    ○ -f filename.yaml で value の一括指定も可能

    View Slide

  59. ● ちょっとした変数を変えたい場合にとても便利
    ○ URL を pr-100-api.example.com にしたい
    ○ namespace をいい感じに分けたい
    ○ etc
    ● ユーザー(API 開発者) のインターフェースが統一される
    ○ ユーザーが意識せずともインフラが良くなっていく
    Helm を使うメリット

    View Slide

  60. ● デメリットも浮き彫りに...
    ○ 秘伝の Chart が出来上がる
    ■ → メンテナンスコスト増大
    ○ ユーザーが気軽に設定変更できない
    ■ → インフラ要因の工数増大
    ○ microservice ごとに Chart を用意
    ■ → 管理コスト大幅増大
    Helm を使うデメリット

    View Slide

  61. 進捗は技術ブログで報告します
    ● https://tech.bank.co.jp

    View Slide

  62. build
    build node
    Container
    Registry
    app node
    pr-100-api
    RSpec
    爆速ビルド環境を
    独自開発し,
    スピードと安全性を両立
    開発環境自動デプロイ
    により,API 開発者の
    無駄な工数削減

    View Slide

  63. プロダクション環境

    View Slide

  64. api-blue
    api-green
    sidekiq
    Cloud Load
    Balancing
    Cloud SQL
    Replica
    GKE node
    redis
    service
    type:
    NodePort

    View Slide

  65. api-blue
    api-green
    sidekiq
    Cloud Load
    Balancing
    Cloud SQL
    Replica
    GKE node
    redis
    service
    type:
    NodePort
    開発環境との違い:
    API で Blue-Green-Deployment を
    実施している

    View Slide

  66. Blue-Green-Deployment
    ● Active-Standby 2 つのプロダクション環境を持つ
    ○ Blue 系と Green 系
    ○ Active と Standby はデプロイのたびに切り替わる
    ■ 色により Active-Standby は決まらない

    View Slide

  67. 1 回目更新
    1. green を更新する (v1→v2)
    2. 正常性確認を実施
    3. green を Active にする
    2 回目更新
    1. blue を更新する (v1 → v3)
    2. 正常性確認を実施
    3. blue を Active にする
    更新後に待機系を破棄せずに
    動かしておくことにより,
    問題発生時にロールバックが可能

    View Slide

  68. Blue-Green-Deployment
    ● 実現方法: Helm Chart
    ○ blue, green で 2 つの deployment を作成
    ○ svc の selector を切り替えることにより,
    blue, green を switch させている
    ○ シンプル & 愚直に開発
    Ingress
    Service
    Deploy
    ment
    Deploy
    ment

    View Slide

  69. Blue-Green-Deployment
    ● 利点たくさん
    ○ shutdown が勝手に graceful になる
    ■ 更新中は Active に変更が加わらないため
    ■ ユーザーリクエストロスを根絶できる!
    ○ 問題発生時のロールバックが一瞬
    ■ svc で切り替えるため,切り替えが高速
    ■ 1 世代前の環境がそのまま残っている
    ■ Try & Error のサイクルを高速に回せる!

    View Slide

  70. api-blue
    api-green
    sidekiq
    Cloud Load
    Balancing
    Cloud SQL
    Replica
    GKE node
    redis
    service
    type:
    NodePort
    開発環境との違い:
    外部 SaaS の redis を用いている

    View Slide

  71. api-blue
    api-green
    sidekiq
    Cloud Load
    Balancing
    Cloud SQL
    Replica
    GKE node
    redis
    service
    type:
    NodePort
    開発環境との違い:
    ingress-gce を用いて GCLB を使っている

    View Slide

  72. api-blue
    api-green
    sidekiq
    Cloud Load
    Balancing
    Cloud SQL
    Replica
    GKE node
    redis
    service
    type:
    NodePort
    Blue-Green-Deployment により
    事故によるユーザー影響を
    瞬時にハンドリング可能に

    View Slide

  73. 3 CASH を支える
    アプリケーション開発

    View Slide

  74. Ruby on Rails on AWS

    View Slide

  75. Ruby on Rails on GCP

    View Slide

  76. Ruby on Rails on GKE

    View Slide

  77. Ruby on Rails on ...
    ● AWS 7,550,000 件
    ○ EKS 196,000 件
    ● GCP 255,000 件
    ○ GKE 29,400 件
    ● Azure 22,500,000 件
    ○ AKS 347,000 件 ※ 2018 年 8 月 16 日時点

    View Slide

  78. GKE ならではのアプリケーション構成
    ● 始めから Kubernetes だった
    ○ 創業・事業開始からまだ 1 年とちょっと
    ■ はじめからモダンな構成
    ● (Beyond) The 12 Factor App に則った構成
    ○ stateless, disposable, versioning...
    今、新規にアプリを開発するならコンテナ稼動前提な設計にする

    View Slide

  79. CASH の API 開発について
    ● 全体構成
    ● ログ・監視
    ● データ解析
    ● CASH ならではの色々

    View Slide

  80. CASH の API 開発について : 全体構成
    使用している色々
    ● Rails 5.x
    ○ Puma
    ○ Sidekiq
    ● PostgreSQL (Cloud SQL)
    ● Redis (Redis Cloud)

    View Slide

  81. CASH の API 開発について : ログ・監視
    ● ログ → Stackdriver Logging
    ● 監視 → Stackdriver Monitoring

    View Slide

  82. CASH の API 開発について : データ解析
    ● BigQuery
    ● Redash
    ● Data Studio

    View Slide

  83. CASH の API 開発について : BigQuery

    View Slide

  84. CASH の API 開発について : Data Studio

    View Slide

  85. CASH の API 開発について : CASH ならではの
    色々
    ● 通知基盤
    ● TV 放映によるアクセスのスパイク
    ● CI による DB Schema の検査

    View Slide

  86. 「全ては実験」
    光本 勇介

    View Slide

  87. CASH の API 開発について : CASH ならではの
    色々
    ● 通知基盤
    ○ 大量のユーザーに Push 通知を送りたい!
    ● TV 放映によるアクセスのスパイク
    ○ 新規ユーザーを獲得したい!
    ● CI による DB Schema の検査
    ○ 複数の施策を同時に実装したい!

    View Slide

  88. CASH ならではの色々 : 通知基盤
    ● 突然 「こういう属性のユーザーに通知を送りたい」
    ○ データ解析班から渡される大量の User ID
    ■ ある施策では 42 万件の通知を送った

    View Slide

  89. CASH ならではの色々 : 通知基盤
    ● 42 万件の Push 通知
    ○ 愚直に 1 件ずつ Firebase の API を叩く
    ■ 「送信完了は今晩 23 時頃になりますね」

    ○ 存在しない Device Token でエラーになる

    View Slide

  90. CASH ならではの色々 : 通知基盤
    ● FCM の Topic を用いた大量通知配信
    ○ Topic を作成 → Topic に配信
    ○ ひとまずこの方式で通知を送ることに
    ● Topic は作成にある程度時間がかかる
    ○ 「今、すぐ!」に応えられない

    View Slide

  91. CASH ならではの色々 : 通知基盤

    View Slide

  92. CASH ならではの色々 : 通知基盤
    ● Cloud Functions によって FCM に Request を送信
    ○ Promise を使用して並列化
    ● 急な大量通知の要望に応えられるように
    ○ https://github.com/bank/baramaki

    View Slide

  93. CASH ならではの色々 : TV 放映によるアクセスのスパイ

    View Slide

  94. CASH ならではの色々 : TV 放映によるアクセスのスパイ

    ● 普段の十数倍のリクエストが来た
    ● 行なった事前準備
    ○ Quota 上限緩和申請
    ○ Cloud SQL scale up
    ○ Pod の増加
    ● リクエストを受けきれずダウン

    View Slide

  95. CASH ならではの色々 : TV 放映によるアクセスのスパイ

    ● 原因 : Cloud SQL の Connection が枯渇
    ● 障害に対してのポストモーテムを作成

    View Slide

  96. CASH ならではの色々 : CI による DB Schema の検

    ● 複数人が複数の git branch で開発
    ● 各 branch で別々に DB Schema を変更する
    ● いつの間にか production と local の Schema が違う!

    View Slide

  97. CASH ならではの色々 : CI による DB Schema の検

    ● 次の 2 つが違うと何かがおかしい
    ○ ローカルで実行済みの Schema
    ○ 全ての migration を実行した Schema
    ● CI で $ bundle exec rails db:create db:migrate
    ○ その結果 db/schema.rb に diff が出たら CI fail

    View Slide

  98. 4 BANK を支える
    エンジニア文化

    View Slide

  99. 僕たちはスタートアップです

    View Slide

  100. BANK を支えるエンジニア文化
    ● 月ペースで増えるエンジニア
    ○ 環境構築
    ○ 文化のキャッチアップ
    ○ ビジネスロジックのキャッチアップ
    ● 頻繁に変わるアーキテクチャ
    ○ 例 : 複数開発環境 、 Blue-Green Deployment ……

    View Slide

  101. モブコードリーディング

    View Slide

  102. モブコードリーディング
    ● みんなで集まってアプリのコードを読む
    ○ モブプログラミングからアイデアを拝借
    ○ 複雑なビジネスロジックのリファクタリング
    ○ 施策についての説明と実装における懸念の共有
    ○ Helm による deploy フロー変化についての説明
    ● 週 2 回ペースで開催

    View Slide

  103. ポストモーテム
    ● 発生した障害について何が起こっていたのかを記録
    ○ SRE 本 15 章
    ● 幸いにもあまり書かれたことはない
    ○ 現在 3 記事

    View Slide

  104. BANK を支えるエンジニア文化
    ● モブコードリーディング
    ● ポストモーテム
    ● ( まだ生まれてない最高の文化 )
    ○ 創業間もないベンチャー企業
    ○ いい文化はこれからいくらでも創っていける

    View Slide

  105. 5 まとめ

    View Slide

  106. まとめ
    ● GKE を活用した開発を足止めしないインフラ環境
    ○ Blue-Green Deployment
    ○ Multi Development Environments
    ● GCP を活用した Rails アプリケーション開発
    ○ Firebase, Stackdriver, BigQuery Data Studio and so on...
    ● まだまだ成長中の IT ベンチャー企業
    ○ WE ARE HIRING!

    View Slide

  107. WE ARE HIRING!

    View Slide

  108. セッションへのご感想
    ウェブまたはアプリのセッション ページか
    ら、すぐにご感想を送信できます !
    ご予約したセッション終了 5 分前に、アプ
    リまたはウェブのセッションページに " ★
    評価 " が表示されます。
    そちらからフィードバックをぜひ送信くださ
    い。
    #GoogleNext18

    View Slide

  109. Thank you.

    View Slide

  110. api_chart/
    |- templates
    |- api-deployment.yaml
    |- api-service.yaml
    |- redis-deployment.yaml
    |- redis-service.yaml
    |- ingress.yaml
    |- etc
    api_chart/
    |- requirements.yaml
    |- namespace_chart
    |- redis_chart
    |- db_chart
    |- ingress_chart
    ● この辺の問題は,役割ごとに複数 chart を作成し,
    依存をもたせることで解決しそう
    OSS でない API で Helm を使う

    View Slide

  111. pr-100-api
    pr-101-api
    pr-102-api
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    nghttpx
    ingress
    controller
    New!
    APIサーバごとに
    個別のDBコンテナを持つ
    end
    point
    Cloud Load
    Balancing
    GKE node

    View Slide