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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

日経電子版開発上の課題

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

課題 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

Slide 8

Slide 8 text

課題 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 = チーム

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

実現方法

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

02 シンプルで安全な運用

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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 を管理するレポジトリ

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

03 一貫した監視

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

Stackdriver - 統一された Monitoring

Slide 70

Slide 70 text

Stackdriver - 統一された Logging

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

基盤の安全なメンテナンス - 改善 - 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

Slide 79

Slide 79 text

旧環境からの移行状況

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

旧環境からの移行状況 - 現在移行中 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 ・・・

Slide 82

Slide 82 text

旧環境からの移行状況 - 次に移行検討中 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 ・・・

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

Thank you