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

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

Ryo yasuda
January 30, 2020

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

Ryo yasuda

January 30, 2020
Tweet

More Decks by Ryo yasuda

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. 実現方法

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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



    nikkei.dev.com
    検証 pod A
    検証 pod B

    View full-size slide

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



    nikkei.dev.com
    検証 pod A
    検証 pod B

    View full-size slide

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



    nikkei.dev.com
    検証 pod A
    検証 pod B
    version: test-A

    View full-size slide

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



    nikkei.com
    v2 pod
    本番
    staging

    View full-size slide

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



    nikkei.com
    staging pod
    v1 pod
    v2 pod
    本番
    staging

    View full-size slide

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



    nikkei.com
    staging pod
    version: staging
    v1 pod
    v2 pod
    本番
    staging

    View full-size slide

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



    nikkei.com
    staging pod
    v1 pod
    v2 pod
    本番
    staging

    View full-size slide

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



    nikkei.com
    v2 pod
    本番
    staging

    View full-size slide

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



    nikkei.com
    v2 pod
    staging
    本番

    View full-size slide

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



    nikkei.com
    v2 pod
    staging
    本番

    View full-size slide

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



    nikkei.com
    v2 pod
    本番
    staging

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  43. 現状の問題点と対策
    - 本番の負荷・リクエストパターンでしか再現しない問題を検出できな

    - 本番と同じリクエストを受けても壊れないことをstaging 段階で保証
    する必要がある

    View full-size slide

  44. 本番クラスタ
    現状の問題点と対策 - Mirroring
    v1



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

    View full-size slide

  45. 本番クラスタ
    現状の問題点と対策 - Canary
    v1



    - Weighted Routing 使って Canary Release
    - 同一ユーザが常に同一グループに振り分けられるとは限らない
    - アクセス毎にv1に振られたりv2に振られたりする
    - https://github.com/istio/istio/issues/9764
    v2
    30%
    70%

    View full-size slide

  46. 本番クラスタ
    現状の問題点と対策 - Canary
    v1



    - Fastlyで weight を制御する
    - ユーザ ID や UA をベースに Fastly で version を振り分ける
    - アクセス毎に振り分け先が変わることのない安定した
    Canaryが実現
    v2
    70%
    version: v1
    Fastly
    30%
    version: v2

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  66. 03
    一貫した監視

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  69. Stackdriver - 統一された Monitoring

    View full-size slide

  70. Stackdriver - 統一された Logging

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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


    View full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide