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
   

   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