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

CASH を支える Google Kubernetes Engine

30f225267161deef6146671e4b118dfb?s=47 Bank, Inc
October 09, 2018
2.3k

CASH を支える Google Kubernetes Engine

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

30f225267161deef6146671e4b118dfb?s=128

Bank, Inc

October 09, 2018
Tweet

Transcript

  1. D2-3-S08 CASH を支える Google Kubernetes Engine 高橋 拓也 中村 勇介

    株式会社バンク SokoP Urasoko Google Cloud 2018/09/20
  2. Happy?

  3. SokoP (sokopiː)

  4. Happy? SokoP GCP!

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

    28 km 走って出勤した経験あり。 Speaker
  6. Happy?

  7. None
  8. None
  9. 高橋 拓也 株式会社バンク (サーバサイド | クラウドインフラ)エンジニア 2018 年 5 月ジョイン

    インフラエンジニアとしてプライベートクラウドを作った 後,サービスロジックを書きたくて入社 サーバサイド,インフラの両面から サービスをより良くしようと奮闘中 Speaker
  10. 中村 勇介 (うなすけ) 株式会社バンク エンジニア 2018 年 2 月入社。 Rails

    アプリが GKE 上で運用 されているという部分に魅力を感じ入社を決意 主に Rails によるアプリケーション開発を担当 Photo Speaker
  11. • 事業紹介 • BANK におけるインフラのミッション • CASH を支えるインフラストラクチャ ◦ 開発環境

    ◦ CI/CD ◦ プロダクション環境 • CASH を支えるアプリケーション開発 • BANK を支えるエンジニア文化 • まとめ Agenda
  12. 1 事業紹介

  13. None
  14. None
  15. None
  16. image

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

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

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

  21. すごくはやい

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

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

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

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

  26. 開発環境

  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
  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
  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
  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
  31. Ingress • Kubernetes にデプロイしたアプリケーションを 外部公開するために利用するリソース • インターフェースのみを定義し, 実際の疎通のための実装は Ingress Controller

    に任せる • GKE では ingress-gce を利用して, HTTPS LoadBalancer を自動作成できる ◦ プロダクション環境ではこちらを利用
  32. • 爆速開発環境構築には不向き ◦ リソース新規作成 → UP になるまでが遅い ▪ 平均 10

    分 ~ 15 分 ◦ 1 リソースにつき 1 グローバル IP を利用する ▪ 都度 DNS 登録が必要 • DNS 反映の待ち時間がかかる なぜ開発環境で ingress-gce を使わない?
  33. • ゼットラボ株式会社が開発している OSS ◦ https://github.com/zlabjp/nghttpx-ingress-lb ◦ L7 loadbalancer として nghttpx

    を利用 ▪ HTTP/2 利用可能 ▪ grpc 対応 • 比較検討の結果,動作が安定していたため採用 nghttpx ingress controller
  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
  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秒に短縮
  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
  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
  38. デバッグ用エンドポイント取得 API 1. APIの向き先変更のために,iOSアプリのビルドが必要だった 2. URL を配信するだけの API を作成し,アプリで利用する a.

    https://github.com/bank/k8s-ingress-exporter b. Ingress Resources を取得し配信する
  39. エンドポイント取得

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

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

  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
  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 で アプリビルド時間をゼロに 開発環境自動構築で 環境構築コスト大幅ダウン
  44. CI/CD

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

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

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

    kick RSpec
  48. build build node Container Registry app node pr-100-api Build サーバに

    リクエスト RSpec
  49. build build node Container Registry app node pr-100-api GKE 上の

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

    Build サーバで Image Build & Push CircleCI 上で Rspec を実行 この 2 つを 非同期実行 RSpec
  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 サーバ
  52. None
  53. None
  54. CI にかかる時間が 7 ~ 10分 → 3 ~ 5分に!

  55. build build node Container Registry app node pr-100-api GKE 上の

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

    開発環境を自動デプロイ RSpec
  57. Helm • k8s における Package Manager ◦ CentOS でいう yum

    ◦ template 化した k8s yaml をまとめた Chart を作成して利用する • k8s に簡単にアプリケーションをデプロイ可能
  58. Helm • api の repository に chart を commit してある

    • こんな感じで実行する ◦ --set-string で value の override が可能 ◦ -f filename.yaml で value の一括指定も可能
  59. • ちょっとした変数を変えたい場合にとても便利 ◦ URL を pr-100-api.example.com にしたい ◦ namespace をいい感じに分けたい

    ◦ etc • ユーザー(API 開発者) のインターフェースが統一される ◦ ユーザーが意識せずともインフラが良くなっていく Helm を使うメリット
  60. • デメリットも浮き彫りに... ◦ 秘伝の Chart が出来上がる ▪ → メンテナンスコスト増大 ◦

    ユーザーが気軽に設定変更できない ▪ → インフラ要因の工数増大 ◦ microservice ごとに Chart を用意 ▪ → 管理コスト大幅増大 Helm を使うデメリット
  61. 進捗は技術ブログで報告します • https://tech.bank.co.jp

  62. build build node Container Registry app node pr-100-api RSpec 爆速ビルド環境を

    独自開発し, スピードと安全性を両立 開発環境自動デプロイ により,API 開発者の 無駄な工数削減
  63. プロダクション環境

  64. api-blue api-green sidekiq Cloud Load Balancing Cloud SQL Replica GKE

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

    node redis service type: NodePort 開発環境との違い: API で Blue-Green-Deployment を 実施している
  66. Blue-Green-Deployment • Active-Standby 2 つのプロダクション環境を持つ ◦ Blue 系と Green 系

    ◦ Active と Standby はデプロイのたびに切り替わる ▪ 色により Active-Standby は決まらない
  67. 1 回目更新 1. green を更新する (v1→v2) 2. 正常性確認を実施 3. green

    を Active にする 2 回目更新 1. blue を更新する (v1 → v3) 2. 正常性確認を実施 3. blue を Active にする 更新後に待機系を破棄せずに 動かしておくことにより, 問題発生時にロールバックが可能
  68. Blue-Green-Deployment • 実現方法: Helm Chart ◦ blue, green で 2

    つの deployment を作成 ◦ svc の selector を切り替えることにより, blue, green を switch させている ◦ シンプル & 愚直に開発 Ingress Service Deploy ment Deploy ment
  69. Blue-Green-Deployment • 利点たくさん ◦ shutdown が勝手に graceful になる ▪ 更新中は

    Active に変更が加わらないため ▪ ユーザーリクエストロスを根絶できる! ◦ 問題発生時のロールバックが一瞬 ▪ svc で切り替えるため,切り替えが高速 ▪ 1 世代前の環境がそのまま残っている ▪ Try & Error のサイクルを高速に回せる!
  70. api-blue api-green sidekiq Cloud Load Balancing Cloud SQL Replica GKE

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

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

    node redis service type: NodePort Blue-Green-Deployment により 事故によるユーザー影響を 瞬時にハンドリング可能に
  73. 3 CASH を支える アプリケーション開発

  74. Ruby on Rails on AWS

  75. Ruby on Rails on GCP

  76. Ruby on Rails on GKE

  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 日時点
  78. GKE ならではのアプリケーション構成 • 始めから Kubernetes だった ◦ 創業・事業開始からまだ 1 年とちょっと

    ▪ はじめからモダンな構成 • (Beyond) The 12 Factor App に則った構成 ◦ stateless, disposable, versioning... 今、新規にアプリを開発するならコンテナ稼動前提な設計にする
  79. CASH の API 開発について • 全体構成 • ログ・監視 • データ解析

    • CASH ならではの色々
  80. CASH の API 開発について : 全体構成 使用している色々 • Rails 5.x

    ◦ Puma ◦ Sidekiq • PostgreSQL (Cloud SQL) • Redis (Redis Cloud)
  81. CASH の API 開発について : ログ・監視 • ログ → Stackdriver

    Logging • 監視 → Stackdriver Monitoring
  82. CASH の API 開発について : データ解析 • BigQuery • Redash

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

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

  85. CASH の API 開発について : CASH ならではの 色々 • 通知基盤

    • TV 放映によるアクセスのスパイク • CI による DB Schema の検査
  86. 「全ては実験」 光本 勇介

  87. CASH の API 開発について : CASH ならではの 色々 • 通知基盤

    ◦ 大量のユーザーに Push 通知を送りたい! • TV 放映によるアクセスのスパイク ◦ 新規ユーザーを獲得したい! • CI による DB Schema の検査 ◦ 複数の施策を同時に実装したい!
  88. CASH ならではの色々 : 通知基盤 • 突然 「こういう属性のユーザーに通知を送りたい」 ◦ データ解析班から渡される大量の User

    ID ▪ ある施策では 42 万件の通知を送った
  89. CASH ならではの色々 : 通知基盤 • 42 万件の Push 通知 ◦

    愚直に 1 件ずつ Firebase の API を叩く ▪ 「送信完了は今晩 23 時頃になりますね」 ▪ ◦ 存在しない Device Token でエラーになる
  90. CASH ならではの色々 : 通知基盤 • FCM の Topic を用いた大量通知配信 ◦

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

  92. CASH ならではの色々 : 通知基盤 • Cloud Functions によって FCM に

    Request を送信 ◦ Promise を使用して並列化 • 急な大量通知の要望に応えられるように ◦ https://github.com/bank/baramaki
  93. CASH ならではの色々 : TV 放映によるアクセスのスパイ ク

  94. CASH ならではの色々 : TV 放映によるアクセスのスパイ ク • 普段の十数倍のリクエストが来た • 行なった事前準備

    ◦ Quota 上限緩和申請 ◦ Cloud SQL scale up ◦ Pod の増加 • リクエストを受けきれずダウン
  95. CASH ならではの色々 : TV 放映によるアクセスのスパイ ク • 原因 : Cloud

    SQL の Connection が枯渇 • 障害に対してのポストモーテムを作成
  96. CASH ならではの色々 : CI による DB Schema の検 査 •

    複数人が複数の git branch で開発 • 各 branch で別々に DB Schema を変更する • いつの間にか production と local の Schema が違う!
  97. CASH ならではの色々 : CI による DB Schema の検 査 •

    次の 2 つが違うと何かがおかしい ◦ ローカルで実行済みの Schema ◦ 全ての migration を実行した Schema • CI で $ bundle exec rails db:create db:migrate ◦ その結果 db/schema.rb に diff が出たら CI fail
  98. 4 BANK を支える エンジニア文化

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

  100. BANK を支えるエンジニア文化 • 月ペースで増えるエンジニア ◦ 環境構築 ◦ 文化のキャッチアップ ◦ ビジネスロジックのキャッチアップ

    • 頻繁に変わるアーキテクチャ ◦ 例 : 複数開発環境 、 Blue-Green Deployment ……
  101. モブコードリーディング

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

    Helm による deploy フロー変化についての説明 • 週 2 回ペースで開催
  103. ポストモーテム • 発生した障害について何が起こっていたのかを記録 ◦ SRE 本 15 章 • 幸いにもあまり書かれたことはない

    ◦ 現在 3 記事
  104. BANK を支えるエンジニア文化 • モブコードリーディング • ポストモーテム • ( まだ生まれてない最高の文化 )

    ◦ 創業間もないベンチャー企業 ◦ いい文化はこれからいくらでも創っていける
  105. 5 まとめ

  106. まとめ • GKE を活用した開発を足止めしないインフラ環境 ◦ Blue-Green Deployment ◦ Multi Development

    Environments • GCP を活用した Rails アプリケーション開発 ◦ Firebase, Stackdriver, BigQuery Data Studio and so on... • まだまだ成長中の IT ベンチャー企業 ◦ WE ARE HIRING!
  107. WE ARE HIRING!

  108. セッションへのご感想 ウェブまたはアプリのセッション ページか ら、すぐにご感想を送信できます ! ご予約したセッション終了 5 分前に、アプ リまたはウェブのセッションページに "

    ★ 評価 " が表示されます。 そちらからフィードバックをぜひ送信くださ い。 #GoogleNext18
  109. Thank you.

  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 を使う
  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