日経電子版の新 microservice 基盤 gke + istio + …...google cloud anthos day gke + istio +...

Google Cloud

Anthos Day

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

About me

- 名前: 安田竜 (Ryo Yasuda)

- 所属

- 2015-2016: 日本電信電話 (NTT 研究所)

- 2016-: 日本経済新聞社

- やっていること

- 日経電子版サービス開発

- バックエンド開発・インフラ構築 (AWS・GCP)

- SRE

日経電子版 SRE チームとは

- 責務

- 日経電子版全体のシステム全体の信頼性を担保する

- 日経電子版全体のアーキテクチャに責任を持つ

- 活動内容の詳細

- SRE NEXT:

https://speakerdeck.com/osamunmun/ri-jing-dian-zi-ban-sretimuli-tishan

g-gezhong

日経電子版

- 日経の記事を Web で配信

- 有料ユーザ 60 万人以上

- 無料ユーザ 300 万人以上

- API 2000req/sec

日経電子版開発上の課題

課題 1 - リリースで壊れやすい

- 事前確認では動いてたのに本番に出したら壊れた...

- テストしてたのに本番に出したら壊れた...

- よく壊れるのでリリース頻度を落とした...

- => 開発速度と信頼性の低下

(もちろん、全てのサービスが壊れやすいわけではない)

課題 2 - Microservices の監視・運用が大変

API Gateway

Top Page Article Page

AccountAPI

MyAPI

SearchAPI

PaymentAPI

Paper Viewer

BFF for NativeApp

Data Platform

Mail System

Ads System

課題 2 - サービスとチームがいっぱい

API Gateway

Top Page Article Page

AccountAPI

MyAPI

SearchAPI

PaymentAPI

Paper Viewer

BFF for NativeApp

Data Platform

Mail System

Ads System

= チーム

課題 2 - 各チーム個別にインフラ頑張ってる

Infra

ServiceA

Prometheus Grafana

LoggingMonitoringAvailability

...

ServiceB

DeployPipeline

Infra

ServiceC

ES Kibana


...

ServiceD

DeployPipeline

課題 2 - 監視や運用の手法・品質がバラバラ

Infra

ServiceA

Prometheus Grafana


...

ServiceB

DeployPipeline

Infra

ServiceC

ES Kibana


...

ServiceD

DeployPipeline

課題 2 - サービス横断的な監視や調査も困難

Infra

ServiceA

Prometheus Grafana


...

ServiceB

DeployPipeline

Infra

ServiceC

ES Kibana


...

ServiceD

DeployPipeline

どこにどんなログ・メトリクスが保存されてるか分からない

新基盤の目的 - SRE の下地作り

- 信頼性の改善

- 開発速度と信頼性を両立できるリリースフロー

- シンプルで安全で統一された運用を強制する仕組み

- 信頼性の把握

- サービスやチームに依らず統一された監視と運用

k8s/istio

ServiceA

新基盤の概念図

StackdriverServiceB ServiceC ServiceD

GitOps- k8s/istio による安全なリリースフロー

- GitOps によるシンプルで安全な運用

- istio/stackdriver による統一された監視

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

開発速度と信頼性の両立

リリースの速度・頻度を落とさず信頼性も維持

サービスを壊す変更を、

開発サイクルの初期に検出

今までのリリースフロー

開発環境

機能改修

A

機能改修

B

機能改修

C

本番環境

レビュー

レビュー

レビュー

master branch release branch

feature/A branch

feature/B branch

feature/C branch

今までのリリースフローの問題点

- 手元と実環境の環境の差異で壊れる可能性

- 手元では動いたのに実際の DB やサービスと結合したら動かない

開発環境本番環境

レビュー

レビュー

レビュー


- 開発と本番の環境の差異で壊れる可能性

- 開発環境では動いてたのに本番のネットワークだと動かない


レビュー

レビュー

レビュー


- リリースフロー後半で手戻りするので時間かかる


レビュー

レビュー

レビュー

対策

- 開発初期の段階で実際にサービスが動く環境で検証す

ることで、問題を検出し手戻りを減らす

- 開発・修正サイクル高速化、信頼性の向上

- リリース前の確認環境と本番環境の差を極力なくし、リ

リースで壊れなくする

- 信頼性の向上

速度と信頼性を両立させるリリースフロー

開発環境機能検証環境

機能改修

A

機能改修

B

機能改修

C

staging 環境

機能検証環境

機能検証環境

レビュー

レビュー

レビュー

feature/A branch

master branch release branchfeature/B branch

feature/C branch

本番環境


開発環境検証環境 staging 環境

検証環境

検証環境

レビュー

本番環境

- feature branch ごとに用意される独立した検証環境

- 開発初期に実環境上での挙動を確認でき、手戻り少なく修正可能

- レビュー時に実環境での挙動確認まで行えて問題を検出しやすい

レビュー

レビュー


- 本番と全く同じ条件下で動く staging 環境

- 動いてるバイナリ・network・環境変数・ドメインなど全て同じ

- リリース前に本番での正確な挙動を事前にテストできる

開発環境検証環境 staging環境

検証環境

検証環境

レビュー

本番環境

レビュー

レビュー

実現方法

1branch 1環境をどう実現するか


機能改修

A

機能改修

B

機能改修

C

staging 環境

機能検証環境

機能検証環境

レビュー

レビュー

レビュー

feature/A branch


feature/C branch

本番環境

1 branch 1 環境をどう実現するか

機能検証用 VM

APP

- feature branch への push の度にインスタンスを起動す

るのは時間的にもコスト的にも非効率

- もっとサクッと立ち上げたい

機能検証用 VM

APP

機能検証用 VM

APP

1branch 1環境をどう実現するか

機能検証用pod

- k8sなら、既に立ち上がっているマシンの上でpodの追

加・削除するだけなので効率的

k8sクラスタ

機能検証用pod 機能検証用pod

APP APP APP

検証環境と実際の環境の差異をなくすには


機能改修

A

機能改修

B

機能改修

C

staging 環境

機能検証環境

機能検証環境

レビュー

レビュー

レビュー

feature/A branch


feature/C branch

本番環境

検証クラスタ


- クラスタもドメインも分けて実現する場合

- クラスタ・ドメインの差異による条件・挙動の違いが出る

- クラスタの構成の違い・異なるドメインの Cookie の扱いの違い等

開発クラスタ

開発 podnikkei.dev.com

検証 pod Anikkei.test-a.com


- 同一クラスタ上で同一ドメインでアクセスできるようにし、

実行環境を揃える必要

開発クラスタ

開発 pod

・・・

nikkei.dev.com

検証 pod A

検証 pod B

開発クラスタ


- 同一クラスタ上で、リクエストヘッダによってアクセス先

環境を分けることで実現

開発 pod

・・・

nikkei.dev.com

検証 pod A

検証 pod B

開発クラスタ


- 同一クラスタ上で、リクエストヘッダによってアクセス先

環境を分けることで実現

開発 pod

・・・

nikkei.dev.com

検証 pod A

検証 pod B

version: test-A

staging 環境

- 同様に、staging も本番と全く同じ環境を実現

本番クラスタ

v1 pod

・・・

nikkei.com

v2 pod

本番

staging

staging 環境


- stagingは本番と同じ環境・条件で動いている

本番クラスタ

本番pod

・・・

nikkei.com

staging pod

v1 pod

v2 pod

本番

staging

staging 環境


- stagingは本番と同じ環境・条件で動いている

- 開発者はリクエストヘッダをつけると staging へアクセスできる

本番クラスタ

本番pod

・・・

nikkei.com

staging pod

version: stagingv1 pod

v2 pod

本番

staging

staging 環境


- リリース後の挙動を事前に高い精度で検証できる

本番クラスタ

本番pod

・・・

nikkei.com

staging pod

v1 pod

v2 pod

本番

staging

staging から本番への安全なリリース

- リリース時は、ユーザからのリクエストの向き先を

staging へ変更し、staging 環境を本番環境に昇格

本番クラスタ

v1 pod

・・・

nikkei.com

v2 pod

本番

staging




本番クラスタ

v1 pod

・・・

nikkei.com

v2 pod

staging

本番




- staging から本番へ移行する際の変化を最小化

本番クラスタ

v1 pod

・・・

nikkei.com

v2 pod

staging

本番

Rollback

- 問題が起きたら Routing を戻すだけで Rollback できる

- blue/green と同じ

本番クラスタ

v1 pod

・・・

nikkei.com

v2 pod

本番

staging

Routing 制御のための istio の設定

Header に app-version: v1がついてたら v1 へ Routing


Default で v1 へ Routing

Virtual Service

Routing 制御のための istio の設定



Default で v2 へ Routing

Virtual Service

現状の問題点と対策

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

い

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

する必要がある

本番クラスタ

現状の問題点と対策 - Mirroring

v1

・・・

- Request Mirroring で、本番と同じリクエストを staging に送る

- 実際のリクエストや負荷で問題ないか、ユーザ影響なく検証できる

- 更新系リクエストを Mirroring すると、データに不整合が起こる可能性がある

- 裏にいるシステムに 2 倍の負荷がかかる...

v2

GET /api/hoge

GET /api/hoge

GET /api/hoge

本番クラスタ

現状の問題点と対策 - Canary

v1

・・・

- Weighted Routing 使って Canary Release

- 同一ユーザが常に同一グループに振り分けられるとは限らない

- アクセス毎にv1に振られたりv2に振られたりする

- https://github.com/istio/istio/issues/9764

v230%

70%

https://github.com/istio/istio/issues/9764

本番クラスタ

現状の問題点と対策 - Canary

v1

・・・

- Fastlyで weight を制御する

- ユーザ ID や UA をベースに Fastly で version を振り分ける

- アクセス毎に振り分け先が変わることのない安定したCanaryが実現

v2

70% version: v1

Fastly

30% version: v2

02シンプルで安全な運用

シンプルで安全な運用

- 人為的な事故が起きづらい

- 操作ミス・設定ミス・うっかりによる環境破壊など

- 事故が起きてもすぐに元の状態に戻せる

- 運用のための学習コストが低い

- 誰でもできて属人性が低い

kubectl による運用の問題点

kubectl apply

Developer

Developer

強力な権限が必要操作の学習コスト高操作ミスのリスク高

運用負荷高変更履歴が追えない

GitOps

- サービス A は v1・v2 が存在- サービス B は v1・v2 が存在- サービス A は v1 へ Routing- サービス B は v2 へ Routing- Rate Limit は 100req/sec

Sync

- クラスタ上の状態を全て Git 上で管理

- クラスタは常に Git 上の状態と同一の状態に同期される

GitHub

Developer

CI

GitOps

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

GitOps でシンプルで安全な運用が実現

- PR レビューを通じて、操作ミス・設定ミス・うっかりを防止

- 変更履歴が管理されてるので、何かあってもすぐ戻せる

- 運用ツールが git・github のみなのでシンプル

GitOps による運用例 - リリース

- リリースも PR を通じて行われる

1. staging 環境へデプロイするPR

2. staging 環境を本番へ昇格させるPR


- 1つめの PR をマージすれば staging へデプロイ

- 最新バージョン (v6601) の pod が作成される

本番クラスタ

v6592

v6601


- 2 つめの PR をマージすれば staging が本番へ昇格

- 最新バージョン (v6601) へ Routing を変更する

本番クラスタ

v6592

v6601

GitOps による運用例 - Rollback

- リリースで問題起きたら、PR を revert するだけで Rollback

- 誰でもどこでもできるので、問題発生時の一時対応が迅速 (数十秒)

GitOps を使った実際のリリースフロー

Developer Source Repo

Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

アプリケーションコードを管理するレポジトリ



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

全サービスのk8s/istioの manifest を管理するレポジトリ



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

Manifest Repo とクラスタを同期するツール



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

コードの変更を push



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

CI で Docker Image をbuild & push



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

リリース用 PR を自動作成 & マージ



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

ArgoCD が manifest の変更を検知して



Manifest Repo

Push Trigger

Push

Watch Sync

k8s cluster

Pull

Container Registry

Argo CDCircle CI

PR &Merge

クラスタにmanifest の内容が反映される

03一貫した監視

一貫した監視

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

一貫した監視

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

Stackdriver

Stackdriver - 統一された Monitoring

Stackdriver - 統一された Logging

一貫した監視

- 監視手法・ログ・メトリクス・運用方法が統一された

- => 基盤上のサービスであれば統一した手法で初期調査・復旧可能

- 開発に全く関わってないサービスの調査も可能

- サービス・チームをまたがる横断的な対応が可能になる

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

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

- k8s/istio は更新が早く状況が変わりやすい

- 大規模な構成変更をやりやすくし、常に安全&管理しやすい

状態を保つ必要性がある

- クラスタの再生成が必要な変更 (GKE 新機能の利用の際など)

- ServiceMesh や Network 構成の変更

- etc...


- Cluster レベルの Blue/Green で安全にクラスタの更新・変更が可能

Manifest Repo

Argo CD

Watch Syncblue cluster


- green cluster を作成し、ArgoCD で blue cluster と全く同じ環境を再現

Manifest Repo

Argo CD


green cluster


- green cluster に更新を加えて

Manifest Repo

Argo CD


updatedgreen cluster


- DNS を切り替える

Manifest Repo

Argo CD



基盤の安全なメンテナンス - 改善

- DNS 切り替え前に secondary の挙動を本番同様の状況で確認できると安全

Manifest Repo

Argo CD



Fastly

Default Routing

HTTP Headercluster: secondary

旧環境からの移行状況


Fastly

Service A

Service B

Service C

Service A

Service B

Service C

CI/CD

常に両環境にDeploy

移行するサービスだけ Routing 変更

旧

新

旧環境からの移行状況 - 現在移行中

API Gateway

Web Apps (Microservices)BFF for

NativeApp

CMS for paper

CMS fordigital

APIs (Microservices)

PaperViewerWeb

Legacy Web App

BFF APIGW

Top Page

ArticlePage ・・・

SearchAPI

PaperAPI

PushAPI ・・・

Payment Account ・・・

旧環境からの移行状況 - 次に移行検討中

API Gateway

Web Apps (Microservices)BFF for

NativeApp

CMS for paper

CMS fordigital

APIs (Microservices)

PaperViewerWeb

Legacy Web App

BFF APIGW

Top Page

ArticlePage ・・・

SearchAPI

PaperAPI

PushAPI ・・・

Payment Account ・・・


- 旧環境からどうしても移行できないものもある

- 永続化したデータの移行に大きなコストがかかるものなど

- でもコンテナの実行環境の移行自体は可能なものが多い

- それぞれの環境内に k8s を立てて、k8s へ載せ替えていきたい


GKE Other Cluster Other Cluster

Service Service Service Service Service Service

istio istio istio

Stackdriver

- k8s に乗せられればクラスタ上の構成や運用は再現可能

- 監視・メトリクス・運用の統一の恩恵は受けられる

まとめ

- k8s/istio で、信頼性と開発速度を両立できるフローを実現

- GitOps で運用もシンプルかつ安全に

- istio で、サービス間で統一された監視・メトリクス収集が実現

- 監視・運用基盤を統一し開発チームの負荷削減

- 更新しやすいインフラで常に安全&管理しやすい状態に保つ

日経はエンジニアの仲間を募集中

- SRE チームは中途・フリーランスどちらも募集中

- エンジニアが 1 名増えることの効果が大きい状況

- 興味ある方は twitter( @nikkeideveloper )にDMを

- Wantedly:

https://www.wantedly.com/projects/367306

- オフィス見学歓迎

Thank you

日経電子版の新 microservice 基盤 gke + istio + …...google cloud anthos day gke + istio +...

Documents