GKE+Istio+GitOpsで作る日経電子版の次世代マイクロサービス基盤

Transcript

1. Google Cloud
   Anthos Day
   GKE + Istio + GitOps で作る
   日経電子版の新 Microservice 基盤
   日本経済新聞社 安田 竜
   

   View Slide

2. About me
   - 名前: 安田 竜 (Ryo Yasuda)
   - 所属
   - 2015-2016: 日本電信電話 (NTT 研究所)
   - 2016-: 日本経済新聞社
   - やっていること
   - 日経電子版サービス開発
   - バックエンド開発・インフラ構築 (AWS・GCP)
   - SRE
   

   View Slide

3. 日経電子版 SRE チームとは
   - 責務
   - 日経電子版全体のシステム全体の信頼性を担保する
   - 日経電子版全体のアーキテクチャに責任を持つ
   - 活動内容の詳細
   - SRE NEXT:
   https://speakerdeck.com/osamunmun/ri-jing-dian-zi-ban-sretimuli-tishan
   g-gezhong
   

   View Slide

4. 日経電子版
   - 日経の記事を Web で配信
   - 有料ユーザ 60 万人以上
   - 無料ユーザ 300 万人以上
   - API 2000req/sec
   

   View Slide

5. 日経電子版 開発上の課題
   

   View Slide

6. 課題 1 - リリースで壊れやすい
   - 事前確認では動いてたのに本番に出したら壊れた...
   - テストしてたのに本番に出したら壊れた...
   - よく壊れるのでリリース頻度を落とした...
   - => 開発速度と信頼性の低下
   (もちろん、全てのサービスが壊れやすいわけではない
   )
   

   View Slide

7. 課題 2 - Microservices の監視・運用が大変
   API Gateway
   Top Page
   Article
   Page
   Account
   API
   My
   API
   Search
   API
   Payment
   API
   Paper
   Viewer
   BFF for
   NativeApp
   Data
   Platform
   Mail
   System
   Ads
   System
   

   View Slide

8. 課題 2 - サービスとチームがいっぱい
   API Gateway
   Top Page
   Article
   Page
   Account
   API
   My
   API
   Search
   API
   Payment
   API
   Paper
   Viewer
   BFF for
   NativeApp
   Data
   Platform
   Mail
   System
   Ads
   System
   = チーム
   

   View Slide

9. 課題 2 - 各チーム個別にインフラ頑張ってる
   Infra
   ServiceA
   Prometheus Grafana
   Logging
   Monitoring
   Availability
   ...
   ServiceB
   Deploy
   Pipeline
   Infra
   ServiceC
   ES Kibana
   Logging
   Monitoring
   Availability
   ...
   ServiceD
   Deploy
   Pipeline
   

   View Slide

10. 課題 2 - 監視や運用の手法・品質がバラバラ
    Infra
    ServiceA
    Prometheus Grafana
    Logging
    Monitoring
    Availability
    ...
    ServiceB
    Deploy
    Pipeline
    Infra
    ServiceC
    ES Kibana
    Logging
    Monitoring
    Availability
    ...
    ServiceD
    Deploy
    Pipeline
    

    View Slide

11. 課題 2 - サービス横断的な監視や調査も困難
    Infra
    ServiceA
    Prometheus Grafana
    Logging
    Monitoring
    Availability
    ...
    ServiceB
    Deploy
    Pipeline
    Infra
    ServiceC
    ES Kibana
    Logging
    Monitoring
    Availability
    ...
    ServiceD
    Deploy
    Pipeline
    どこにどんなログ・メトリクスが保存
    されてるか分からない
    

    View Slide

12. 新基盤の目的 - SRE の下地作り
    - 信頼性の改善
    - 開発速度と信頼性を両立できるリリースフロー
    - シンプルで安全で統一された運用を強制する仕組み
    - 信頼性の把握
    - サービスやチームに依らず統一された監視と運用
    

    View Slide

13. k8s/istio
    ServiceA
    新基盤の概念図
    Stackdriver
    ServiceB ServiceC ServiceD
    GitOps
    - k8s/istio による安全なリリースフロー
    - GitOps によるシンプルで安全な運用
    - istio/stackdriver による統一された監視
    

    View Slide

14. 01
    開発速度と
    信頼性の両立
    

    View Slide

15. 開発速度と信頼性の両立
    リリースの速度・頻度を落とさず信頼性も維持
    サービスを壊す変更を、
    開発サイクルの初期に検出
    

    View Slide

16. 今までのリリースフロー
    開発環境
    機能
    改修
    A
    機能
    改修
    B
    機能
    改修
    C
    本番環境
    レビュー
    レビュー
    レビュー
    master branch release branch
    feature/A branch
    feature/B branch
    feature/C branch
    

    View Slide

17. 今までのリリースフローの問題点
    - 手元と実環境の環境の差異で壊れる可能性
    - 手元では動いたのに実際の DB やサービスと結合したら動かない
    開発環境 本番環境
    レビュー
    レビュー
    レビュー
    

    View Slide

18. 今までのリリースフローの問題点
    - 開発と本番の環境の差異で壊れる可能性
    - 開発環境では動いてたのに本番のネットワークだと動かない
    開発環境 本番環境
    レビュー
    レビュー
    レビュー
    

    View Slide

19. 今までのリリースフローの問題点
    - リリースフロー後半で手戻りするので時間かかる
    開発環境 本番環境
    レビュー
    レビュー
    レビュー
    

    View Slide

20. 対策
    - 開発初期の段階で実際にサービスが動く環境で検証す
    ることで、問題を検出し手戻りを減らす
    - 開発・修正サイクル高速化、信頼性の向上
    - リリース前の確認環境と本番環境の差を極力なくし、リ
    リースで壊れなくする
    - 信頼性の向上
    

    View Slide

21. 速度と信頼性を両立させるリリースフロー
    開発環境
    機能検証環境
    機能
    改修
    A
    機能
    改修
    B
    機能
    改修
    C
    staging 環境
    機能検証環境
    機能検証環境
    レビュー
    レビュー
    レビュー
    feature/A branch
    master branch release branch
    feature/B branch
    feature/C branch
    本番環境
    

    View Slide

22. 速度と信頼性を両立させるリリースフロー
    開発環境
    検証環境 staging 環境
    検証環境
    検証環境
    レビュー
    本番環境
    - feature branch ごとに用意される独立した検証環境
    - 開発初期に実環境上での挙動を確認でき、手戻り少なく修正可能
    - レビュー時に実環境での挙動確認まで行えて問題を検出しやすい
    レビュー
    レビュー
    

    View Slide

23. 速度と信頼性を両立させるリリースフロー
    - 本番と全く同じ条件下で動く staging 環境
    - 動いてるバイナリ・network・環境変数・ドメインなど全て同じ
    - リリース前に本番での正確な挙動を事前にテストできる
    開発環境
    検証環境 staging環境
    検証環境
    検証環境
    レビュー
    本番環境
    レビュー
    レビュー
    

    View Slide

24. 実現方法
    

    View Slide

25. 1branch 1環境をどう実現するか
    開発環境
    機能検証環境
    機能
    改修
    A
    機能
    改修
    B
    機能
    改修
    C
    staging 環境
    機能検証環境
    機能検証環境
    レビュー
    レビュー
    レビュー
    feature/A branch
    master branch release branch
    feature/B branch
    feature/C branch
    本番環境
    

    View Slide

26. 1 branch 1 環境をどう実現するか
    機能検証用 VM
    APP
    - feature branch への push の度にインスタンスを起動す
    るのは時間的にもコスト的にも非効率
    - もっとサクッと立ち上げたい
    機能検証用 VM
    APP
    機能検証用 VM
    APP
    

    View Slide

27. 1branch 1環境をどう実現するか
    機能検証用pod
    - k8sなら、既に立ち上がっているマシンの上でpodの追
    加・削除するだけなので効率的
    k8sクラスタ
    機能検証用pod 機能検証用pod
    APP APP APP
    

    View Slide

28. 検証環境と実際の環境の差異をなくすには
    開発環境
    機能検証環境
    機能
    改修
    A
    機能
    改修
    B
    機能
    改修
    C
    staging 環境
    機能検証環境
    機能検証環境
    レビュー
    レビュー
    レビュー
    feature/A branch
    master branch release branch
    feature/B branch
    feature/C branch
    本番環境
    

    View Slide

29. 検証クラスタ
    検証環境と実際の環境の差異をなくすには
    - クラスタもドメインも分けて実現する場合
    - クラスタ・ドメインの差異による条件・挙動の違いが出る
    - クラスタの構成の違い・異なるドメインの Cookie の扱いの違い等
    開発クラスタ
    開発 pod
    nikkei.dev.com
    検証 pod A
    nikkei.test-a.com
    

    View Slide

30. 検証環境と実際の環境の差異をなくすには
    - 同一クラスタ上で同一ドメインでアクセスできるようにし、
    実行環境を揃える必要
    開発クラスタ
    開発 pod
    ・
    ・
    ・
    nikkei.dev.com
    検証 pod A
    検証 pod B
    

    View Slide

31. 開発クラスタ
    検証環境と実際の環境の差異をなくすには
    - 同一クラスタ上で、リクエストヘッダによってアクセス先
    環境を分けることで実現
    開発 pod
    ・
    ・
    ・
    nikkei.dev.com
    検証 pod A
    検証 pod B
    

    View Slide

32. 開発クラスタ
    検証環境と実際の環境の差異をなくすには
    - 同一クラスタ上で、リクエストヘッダによってアクセス先
    環境を分けることで実現
    開発 pod
    ・
    ・
    ・
    nikkei.dev.com
    検証 pod A
    検証 pod B
    version: test-A
    

    View Slide

33. staging 環境
    - 同様に、staging も本番と全く同じ環境を実現
    本番クラスタ
    v1 pod
    ・
    ・
    ・
    nikkei.com
    v2 pod
    本番
    staging
    

    View Slide

34. staging 環境
    - 同様に、staging も本番と全く同じ環境を実現
    - stagingは本番と同じ環境・条件で動いている
    本番クラスタ
    本番pod
    ・
    ・
    ・
    nikkei.com
    staging pod
    v1 pod
    v2 pod
    本番
    staging
    

    View Slide

35. staging 環境
    - 同様に、staging も本番と全く同じ環境を実現
    - stagingは本番と同じ環境・条件で動いている
    - 開発者はリクエストヘッダをつけると staging へアクセスできる
    本番クラスタ
    本番pod
    ・
    ・
    ・
    nikkei.com
    staging pod
    version: staging
    v1 pod
    v2 pod
    本番
    staging
    

    View Slide

36. staging 環境
    - 同様に、staging も本番と全く同じ環境を実現
    - リリース後の挙動を事前に高い精度で検証できる
    本番クラスタ
    本番pod
    ・
    ・
    ・
    nikkei.com
    staging pod
    v1 pod
    v2 pod
    本番
    staging
    

    View Slide

37. staging から本番への安全なリリース
    - リリース時は、ユーザからのリクエストの向き先を
    staging へ変更し、staging 環境を本番環境に昇格
    本番クラスタ
    v1 pod
    ・
    ・
    ・
    nikkei.com
    v2 pod
    本番
    staging
    

    View Slide

38. staging から本番への安全なリリース
    - リリース時は、ユーザからのリクエストの向き先を
    staging へ変更し、staging 環境を本番環境に昇格
    本番クラスタ
    v1 pod
    ・
    ・
    ・
    nikkei.com
    v2 pod
    staging
    本番
    

    View Slide

39. staging から本番への安全なリリース
    - リリース時は、ユーザからのリクエストの向き先を
    staging へ変更し、staging 環境を本番環境に昇格
    - staging から本番へ移行する際の変化を最小化
    本番クラスタ
    v1 pod
    ・
    ・
    ・
    nikkei.com
    v2 pod
    staging
    本番
    

    View Slide

40. Rollback
    - 問題が起きたら Routing を戻すだけで Rollback できる
    - blue/green と同じ
    本番クラスタ
    v1 pod
    ・
    ・
    ・
    nikkei.com
    v2 pod
    本番
    staging
    

    View Slide

41. Routing 制御のための istio の設定
    Header に app-version: v1
    がついてたら v1 へ Routing
    Header に app-version: v2
    がついてたら v2 へ Routing
    Default で v1 へ Routing
    Virtual Service
    

    View Slide

42. Routing 制御のための istio の設定
    Header に app-version: v1
    がついてたら v1 へ Routing
    Header に app-version: v2
    がついてたら v2 へ Routing
    Default で v2 へ Routing
    Virtual Service
    

    View Slide

43. 現状の問題点と対策
    - 本番の負荷・リクエストパターンでしか再現しない問題を検出できな
    い
    - 本番と同じリクエストを受けても壊れないことをstaging 段階で保証
    する必要がある
    

    View Slide

44. 本番クラスタ
    現状の問題点と対策 - Mirroring
    v1
    ・
    ・
    ・
    - Request Mirroring で、本番と同じリクエストを staging に送る
    - 実際のリクエストや負荷で問題ないか、ユーザ影響なく検証できる
    - 更新系リクエストを Mirroring すると、データに不整合が起こる可能性がある
    - 裏にいるシステムに 2 倍の負荷がかかる...
    v2
    GET /api/hoge
    GET /api/hoge
    GET /api/hoge
    

    View Slide

45. 本番クラスタ
    現状の問題点と対策 - Canary
    v1
    ・
    ・
    ・
    - Weighted Routing 使って Canary Release
    - 同一ユーザが常に同一グループに振り分けられるとは限らない
    - アクセス毎にv1に振られたりv2に振られたりする
    - https://github.com/istio/istio/issues/9764
    v2
    30%
    70%
    

    View Slide

46. 本番クラスタ
    現状の問題点と対策 - Canary
    v1
    ・
    ・
    ・
    - Fastlyで weight を制御する
    - ユーザ ID や UA をベースに Fastly で version を振り分ける
    - アクセス毎に振り分け先が変わることのない安定した
    Canaryが実現
    v2
    70%
    version: v1
    Fastly
    30%
    version: v2
    

    View Slide

47. 02
    シンプルで
    安全な運用
    

    View Slide

48. シンプルで安全な運用
    - 人為的な事故が起きづらい
    - 操作ミス・設定ミス・うっかりによる環境破壊など
    - 事故が起きてもすぐに元の状態に戻せる
    - 運用のための学習コストが低い
    - 誰でもできて属人性が低い
    

    View Slide

49. kubectl による運用の問題点
    kubectl apply
    Developer
    Developer
    強力な権限が必要
    操作の学習コスト高
    操作ミスのリスク高
    運用負荷高
    変更履歴が追えない
    

    View Slide

50. GitOps
    - サービス A は v1・v2 が存在
    - サービス B は v1・v2 が存在
    - サービス A は v1 へ Routing
    - サービス B は v2 へ Routing
    - Rate Limit は 100req/sec
    Sync
    - クラスタ上の状態を全て Git 上で管理
    - クラスタは常に Git 上の状態と同一の状態に同期される
    GitHub
    Developer
    CI
    

    View Slide

51. GitOps
    - git 上の manifest を変更することでのみシステムを変更可
    

    View Slide

52. GitOps でシンプルで安全な運用が実現
    - PR レビューを通じて、操作ミス・設定ミス・うっかりを防止
    - 変更履歴が管理されてるので、何かあってもすぐ戻せる
    - 運用ツールが git・github のみなのでシンプル
    

    View Slide

53. GitOps による運用例 - リリース
    - リリースも PR を通じて行われる
    1. staging 環境へデプロイするPR
    2. staging 環境を本番へ昇格させるPR
    

    View Slide

54. GitOps による運用例 - リリース
    - 1つめの PR をマージすれば staging へデプロイ
    - 最新バージョン (v6601) の pod が作成される
    本番クラスタ
    v6592
    v6601
    

    View Slide

55. GitOps による運用例 - リリース
    - 2 つめの PR をマージすれば staging が本番へ昇格
    - 最新バージョン (v6601) へ Routing を変更する
    本番クラスタ
    v6592
    v6601
    

    View Slide

56. GitOps による運用例 - Rollback
    - リリースで問題起きたら、PR を revert するだけで Rollback
    - 誰でもどこでもできるので、問題発生時の一時対応が迅速 (数十秒)
    

    View Slide

57. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    

    View Slide

58. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    アプリケーションコードを管
    理するレポジトリ
    

    View Slide

59. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    全サービスのk8s/istioの
    manifest を管理するレポジトリ
    

    View Slide

60. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    Manifest Repo とクラスタを同
    期するツール
    

    View Slide

61. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    コードの変更を push
    

    View Slide

62. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    CI で Docker Image を
    build & push
    

    View Slide

63. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    リリース用 PR を
    自動作成 & マージ
    

    View Slide

64. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    ArgoCD が manifest の変
    更を検知して
    

    View Slide

65. GitOps を使った実際のリリースフロー
    Developer Source
    Repo
    Manifest
    Repo
    Push Trigger
    Push
    Watch Sync
    k8s cluster
    Pull
    Container
    Registry
    Argo CD
    Circle CI
    PR &
    Merge
    クラスタに
    manifest の内容が反映される
    

    View Slide

66. 03
    一貫した監視
    

    View Slide

67. 一貫した監視
    - Istio ならサービスに影響を与えることなくメトリクス収集・監視可能
    

    View Slide

68. 一貫した監視
    - GKE なら Istio で集めたメトリクス・ログを Stackdriver に集約してくれる
    Stackdriver
    

    View Slide

69. Stackdriver - 統一された Monitoring
    

    View Slide

70. Stackdriver - 統一された Logging
    

    View Slide

71. 一貫した監視
    - 監視手法・ログ・メトリクス・運用方法が統一された
    - => 基盤上のサービスであれば統一した手法で初期調査・復旧可能
    - 開発に全く関わってないサービスの調査も可能
    - サービス・チームをまたがる横断的な対応が可能になる
    

    View Slide

72. 04
    基盤の安全な
    メンテナンス
    

    View Slide

73. 基盤の安全なメンテナンス
    - k8s/istio は更新が早く状況が変わりやすい
    - 大規模な構成変更をやりやすくし、常に安全&管理しやすい
    状態を保つ必要性がある
    - クラスタの再生成が必要な変更 (GKE 新機能の利用の際など)
    - ServiceMesh や Network 構成の変更
    - etc...
    

    View Slide

74. 基盤の安全なメンテナンス
    - Cluster レベルの Blue/Green で安全にクラスタの更新・変更が可能
    Manifest
    Repo
    Argo CD
    Watch Sync
    blue cluster
    

    View Slide

75. 基盤の安全なメンテナンス
    - green cluster を作成し、ArgoCD で blue cluster と全く同じ環境を再現
    Manifest
    Repo
    Argo CD
    Watch Sync
    blue cluster
    green cluster
    

    View Slide

76. 基盤の安全なメンテナンス
    - green cluster に更新を加えて
    Manifest
    Repo
    Argo CD
    Watch Sync
    blue cluster
    updated
    green cluster
    

    View Slide

77. 基盤の安全なメンテナンス
    - DNS を切り替える
    Manifest
    Repo
    Argo CD
    Watch Sync
    blue cluster
    updated
    green cluster
    

    View Slide

78. 基盤の安全なメンテナンス - 改善
    - DNS 切り替え前に secondary の挙動を本番同様の状況で確認できると安全
    Manifest
    Repo
    Argo CD
    Watch Sync
    blue cluster
    updated
    green cluster
    F
    a
    s
    t
    l
    y
    Default Routing
    HTTP Header
    cluster: secondary
    

    View Slide

79. 旧環境からの移行状況
    

    View Slide

80. 旧環境からの移行状況
    Fastly
    Service A
    Service B
    Service C
    Service A
    Service B
    Service C
    CI/CD
    常に両環境に
    Deploy
    移行するサービス
    だけ Routing 変更
    旧
    新
    

    View Slide

81. 旧環境からの移行状況 - 現在移行中
    API Gateway
    Web Apps (Microservices)
    BFF for
    NativeApp
    CMS for
    paper
    CMS for
    digital
    APIs (Microservices)
    PaperViewer
    Web
    Legacy
    Web App
    BFF
    APIGW
    Top
    Page
    Article
    Page
    ・・・
    Search
    API
    Paper
    API
    Push
    API
    ・・・
    Payment Account ・・・
    

    View Slide

82. 旧環境からの移行状況 - 次に移行検討中
    API Gateway
    Web Apps (Microservices)
    BFF for
    NativeApp
    CMS for
    paper
    CMS for
    digital
    APIs (Microservices)
    PaperViewer
    Web
    Legacy
    Web App
    BFF
    APIGW
    Top
    Page
    Article
    Page
    ・・・
    Search
    API
    Paper
    API
    Push
    API
    ・・・
    Payment Account ・・・
    

    View Slide

83. 旧環境からの移行状況
    - 旧環境からどうしても移行できないものもある
    - 永続化したデータの移行に大きなコストがかかるものなど
    - でもコンテナの実行環境の移行自体は可能なものが多い
    - それぞれの環境内に k8s を立てて、k8s へ載せ替えていきたい
    

    View Slide

84. 旧環境からの移行状況
    GKE Other Cluster Other Cluster
    Service Service Service Service Service Service
    istio istio istio
    Stackdriver
    - k8s に乗せられればクラスタ上の構成や運用は再現可能
    - 監視・メトリクス・運用の統一の恩恵は受けられる
    

    View Slide

85. 旧環境からの移行状況
    GKE Other Cluster Other Cluster
    Service Service Service Service Service Service
    istio istio istio
    Stackdriver
    - k8s に乗せられればクラスタ上の構成や運用は再現可能
    - 監視・メトリクス・運用の統一の恩恵は受けられる
    

    View Slide

86. まとめ
    - k8s/istio で、信頼性と開発速度を両立できるフローを実現
    - GitOps で運用もシンプルかつ安全に
    - istio で、サービス間で統一された監視・メトリクス収集が実現
    - 監視・運用基盤を統一し開発チームの負荷削減
    - 更新しやすいインフラで常に安全&管理しやすい状態に保つ
    

    View Slide

87. 日経はエンジニアの仲間を募集中
    - SRE チームは中途・フリーランスどちらも募集中
    - エンジニアが 1 名増えることの効果が大きい状況
    - 興味ある方は twitter( @nikkeideveloper )にDMを
    - Wantedly:
    https://www.wantedly.com/projects/367306
    - オフィス見学歓迎
    

    View Slide

88. Thank you
    

    View Slide