CASH を支える Google Kubernetes Engine

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

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?
9. 高橋 拓也 株式会社バンク （サーバサイド | クラウドインフラ）エンジニア 2018 年 5 月ジョイン インフラエンジニアとしてプライベートクラウドを作った 後，サービスロジックを書きたくて入社 サーバサイド，インフラの両面から サービスをより良くしようと奮闘中 Speaker
10. 中村 勇介 (うなすけ) 株式会社バンク エンジニア 2018 年 2 月入社。 Rails アプリが GKE 上で運用 されているという部分に魅力を感じ入社を決意 主に Rails によるアプリケーション開発を担当 Photo Speaker
11. • 事業紹介 • BANK におけるインフラのミッション • CASH を支えるインフラストラクチャ ◦ 開発環境 ◦ CI/CD ◦ プロダクション環境 • CASH を支えるアプリケーション開発 • BANK を支えるエンジニア文化 • まとめ Agenda
12. 1 事業紹介
16. image
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 サーバ
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