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-tishang-gezhong日経電子版- 日経の記事を Web で配信- 有料ユーザ 60 万人以上
- 無料ユーザ 300 万人以上
- API 2000req/sec

日経電子版 開発上の課題

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

SearchAPI

Payment
API

Mail
SystemAPI Gateway

Top Page

ArticlePage

Paper
ViewerData
Platform

BFF forNativeApp

Ads
System課題 2 - サービスとチームがいっぱい
Account
API= チーム

Top Page

MyAPI

SearchAPI

Payment
API

Mail
SystemAPI Gateway

ArticlePage

Paper
ViewerData
Platform

BFF forNativeApp

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

Grafana

ESKibana

ServiceA

ServiceB

ServiceC

ServiceD

Infra

InfraDeploy
Pipeline

DeployPipeline

Logging
Monitoring
Availability...

Logging
Monitoring
Availability...

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

Grafana

ESKibana

ServiceA

ServiceB

ServiceC

ServiceD

Infra

Infra

DeployPipeline

DeployPipeline

Logging
Monitoring
Availability...

Logging
Monitoring
Availability...

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

GrafanaES

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

ServiceA

ServiceB

ServiceC

ServiceD

Infra

Infra

DeployPipeline

DeployPipeline

Logging
Monitoring
Availability...

Logging
Monitoring
Availability...

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

新基盤の概念図
Stackdriver

ServiceA

ServiceB

ServiceC

k8s/istio-

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

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

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

GitOpsServiceD

開発速度と信頼性の両立

01開発速度と信頼性の両立
リリースの速度・頻度を落とさず信頼性も維持サービスを壊す変更を、開発サイクルの初期に検出今までのリリースフロー
機能
改修
A

レビュー
feature/A branch

機能
改修
B

レビュー
feature/B branch

機能
改修
C

レビュー
feature/C branch

開発環境

本番環境

master branchrelease branch今までのリリースフローの問題点- 手元と実環境の環境の差異で壊れる可能性-

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

レビュー

開発環境

本番環境

今までのリリースフローの問題点- 開発と本番の環境の差異で壊れる可能性-

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

レビュー

開発環境

本番環境

今までのリリースフローの問題点- リリースフロー後半で手戻りするので時間かかる

レビュー
レビュー

レビュー

開発環境

本番環境

対策
- 開発初期の段階で実際にサービスが動く環境で検証することで、問題を検出し手戻りを減らす-

開発・修正サイクル高速化、信頼性の向上- リリース前の確認環境と本番環境の差を極力なくし、リリースで壊れなくする-

信頼性の向上速度と信頼性を両立させるリリースフロー
機能改修
A

機能検証環境レビュー

feature/A branch
機能改修
B

機能検証環境レビュー

feature/B branch
機能改修
C

機能検証環境feature/C branch

レビュー

開発環境

staging 環境

master branchrelease branch
本番環境速度と信頼性を両立させるリリースフロー- feature branch ごとに用意される独立した検証環境-

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

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

レビュー

検証環境

レビュー

検証環境

レビュー

開発環境

staging 環境
本番環境

速度と信頼性を両立させるリリースフロー- 本番と全く同じ条件下で動く staging 環境-

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

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

レビュー

検証環境

レビュー

検証環境

レビュー

開発環境

staging環境
本番環境

実現方法

1branch 1環境をどう実現するか
機能改修
A

機能検証環境レビュー

feature/A branch
機能改修
B

機能検証環境レビュー

feature/B branch
機能改修
C

機能検証環境feature/C branch

レビュー

開発環境

staging 環境

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

APP

APP

機能検証用 VM

機能検証用 VM

機能検証用 VM

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

機能検証用pod

機能検証用pod

機能検証用pod

APP

APP

APP

k8sクラスタ検証環境と実際の環境の差異をなくすには
機能改修
A

機能検証環境レビュー

feature/A branch
機能改修
B

機能検証環境レビュー

feature/B branch
機能改修
C

機能検証環境feature/C branch

レビュー

開発環境

staging 環境

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

開発クラスタ開発 podnikkei.test-a.com

検証クラスタ検証 pod A

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

開発クラスタ開発 pod検証 pod A・・・

検証 pod B

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

開発クラスタ開発 pod検証 pod A・・・

検証 pod B

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

開発クラスタ開発 pod検証 pod A
検証 pod B

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

nikkei.com

・・・

本番クラスタv1 podv2 pod

本番stagingstaging 環境- 同様に、staging も本番と全く同じ環境を実現-stagingは本番と同じ環境・条件で動いている

nikkei.com

・・・

本番クラスタ本番pod
v1 pod本番

stagingv2 podpod

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

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

開発者はリクエストヘッダをつけると staging へアクセスできる
nikkei.com
version: staging
・・・

本番クラスタ本番pod
v1 pod本番

stagingv2 podpod

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

・・・

本番クラスタ本番pod
v1 pod本番

stagingv2 podpod

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

・・・本番クラスタ
v1 podv2 pod本番

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

・・・

本番クラスタv1 podstagingv2 pod

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

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

・・・

本番クラスタv1 podstagingv2 pod

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

blue/green と同じ

nikkei.com

・・・

本番クラスタv1 podv2 pod本番

stagingRouting 制御のための istio の設定
Header に app-version: v1がついてたら v1 へ Routing

Virtual Service

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

Default で v1 へ Routing

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

Virtual Service

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

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

現状の問題点と対策 - Mirroring-

Request Mirroring で、本番と同じリクエストを staging に送る-実際のリクエストや負荷で問題ないか、ユーザ影響なく検証できる-

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

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

GET /api/hoge
GET /api/hoge
・・・

本番クラスタv1
v2

GET /api/hoge

現状の問題点と対策 - Canary-

Weighted Routing 使って Canary Release-

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

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

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

70%

・・
・

本番クラスタv1
v2

30%

現状の問題点と対策 - Canary-

Fastlyで weight を制御する-

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

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

70%version: v1

本番クラスタv1

Fastly・・・

v2
30%
version: v2

シンプルで安全な運用

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

誰でもできて属人性が低いkubectl による運用の問題点
kubectl apply
Developer

Developer

強力な権限が必要
操作の学習コスト高
操作ミスのリスク高
運用負荷高
変更履歴が追えない

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

Sync

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

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

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

GitOps による運用例 - リリース
- 1つめの PR をマージすれば staging へデプロイ-

最新バージョン (v6601) の pod が作成される
本番クラスタ
v6592

v6601

GitOps による運用例 - リリース
- 2 つめの PR をマージすれば staging が本番へ昇格-

最新バージョン (v6601) へ Routing を変更する
本番クラスタ
v6592

v6601

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

Pull

Container
Registry

k8s cluster

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

Pull

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

k8s cluster

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

k8s cluster

Pull

Container
Registry

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

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

k8s cluster

Pull

Container
Registry

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

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

Pull

コードの変更を pushContainer
Registry

k8s cluster

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CDPull

CI で Docker Image を
build & pushContainer
Registry

k8s cluster

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

Pull

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

k8s cluster

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

k8s cluster

Pull

Container
Registry

ArgoCD が manifest の変更を検知して

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

Developer

PR &Merge

Trigger

SourceRepo

Circle CI
Push

Watch

Manifest
Repo

Sync

Argo CD

k8s cluster

Pull

Container
Registry

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

一貫した監視03一貫した監視-

Istio ならサービスに影響を与えることなくメトリクス収集・監視可能一貫した監視-GKE なら Istio で集めたメトリクス・ログを Stackdriver に集約してくれるStackdriverStackdriver - 統一された MonitoringStackdriver - 統一された Logging

一貫した監視- 監視手法・ログ・メトリクス・運用方法が統一された- => 基盤上のサービスであれば統一した手法で初期調査・復旧可能-

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

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

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

04

基盤の安全なメンテナンス- k8s/istio は更新が早く状況が変わりやすい- 大規模な構成変更をやりやすくし、常に安全&管理しやすい状態を保つ必要性がある-

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

ServiceMesh や Network 構成の変更-etc...

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

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

Watch

Manifest
Repo

Argo CDSync

blue cluster基盤の安全なメンテナンス-

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

Watch

Manifest
Repo

Sync

blue cluster

Argo CD

green cluster基盤の安全なメンテナンス-

green cluster に更新を加えて

Watch

Manifest
Repo

Sync

blue cluster

Argo CD

updatedgreen cluster基盤の安全なメンテナンス-

DNS を切り替える

Watch

Manifest
Repo

Sync

blue cluster

Argo CD

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

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

Manifest
Repo

Sync

Fastlyblue cluster

Argo CD

updatedgreen cluster

HTTP Header
cluster: secondary旧環境からの移行状況旧環境からの移行状況
Service A

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

旧Service B
Service C

CI/CD

FastlyService A

新Service B
Service C

常に両環境にDeploy旧環境からの移行状況 - 現在移行中
CMS forpaper

CMS fordigitalLegacyWeb App

APIs (Microservices)
SearchPaperPush
API
API
API

API Gateway

Web Apps (Microservices)
BFF
APIGW

Top
Page

ArticlePage・・・

Payment

BFF forNativeApp・・・

Account

PaperViewer
Web・・・

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

CMS fordigitalLegacyWeb App

APIs (Microservices)
Search
Paper
Push
API
APIAPIAPI Gateway

Web Apps (Microservices)
BFF
APIGW

Top
Page

ArticlePage・・・Payment

BFF forNativeApp・・・

Account

PaperViewer
Web・・・

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

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

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

それぞれの環境内に k8s を立てて、k8s へ載せ替えていきたい旧環境からの移行状況- k8s に乗せられればクラスタ上の構成や運用は再現可能- 監視・メトリクス・運用の統一の恩恵は受けられる
Stackdriver

ServiceServiceServiceService

Service

Service

istio

istio

istio

GKE

Other Cluster

Other Cluster

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

ServiceServiceServiceServiceServiceService

istio

istio

istio

GKE

Other Cluster

Other Cluster

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

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

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

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

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

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

オフィス見学歓迎Thank you