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

Transcript

1. Google Cloud Anthos Day GKE + Istio + GitOps で作る 日経電子版の新 Microservice 基盤 日本経済新聞社 安田 竜
2. About me - 名前: 安田 竜 (Ryo Yasuda) - 所属 - 2015-2016: 日本電信電話 (NTT 研究所) - 2016-: 日本経済新聞社 - やっていること - 日経電子版サービス開発 - バックエンド開発・インフラ構築 (AWS・GCP) - SRE
3. 日経電子版 SRE チームとは - 責務 - 日経電子版全体のシステム全体の信頼性を担保する - 日経電子版全体のアーキテクチャに責任を持つ - 活動内容の詳細 - SRE NEXT: https://speakerdeck.com/osamunmun/ri-jing-dian-zi-ban-sretimuli-tishan g-gezhong
4. 日経電子版 - 日経の記事を Web で配信 - 有料ユーザ 60 万人以上 - 無料ユーザ 300 万人以上 - API 2000req/sec
5. 日経電子版 開発上の課題
6. 課題 1 - リリースで壊れやすい - 事前確認では動いてたのに本番に出したら壊れた... - テストしてたのに本番に出したら壊れた... - よく壊れるのでリリース頻度を落とした... - => 開発速度と信頼性の低下 (もちろん、全てのサービスが壊れやすいわけではない )
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
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 = チーム
9. 課題 2 - 各チーム個別にインフラ頑張ってる Infra ServiceA Prometheus Grafana Logging Monitoring Availability ... ServiceB Deploy Pipeline Infra ServiceC ES Kibana Logging Monitoring Availability ... ServiceD Deploy Pipeline
10. 課題 2 - 監視や運用の手法・品質がバラバラ Infra ServiceA Prometheus Grafana Logging Monitoring Availability ... ServiceB Deploy Pipeline Infra ServiceC ES Kibana Logging Monitoring Availability ... ServiceD Deploy Pipeline
11. 課題 2 - サービス横断的な監視や調査も困難 Infra ServiceA Prometheus Grafana Logging Monitoring Availability ... ServiceB Deploy Pipeline Infra ServiceC ES Kibana Logging Monitoring Availability ... ServiceD Deploy Pipeline どこにどんなログ・メトリクスが保存 されてるか分からない
12. 新基盤の目的 - SRE の下地作り - 信頼性の改善 - 開発速度と信頼性を両立できるリリースフロー - シンプルで安全で統一された運用を強制する仕組み - 信頼性の把握 - サービスやチームに依らず統一された監視と運用
13. k8s/istio ServiceA 新基盤の概念図 Stackdriver ServiceB ServiceC ServiceD GitOps - k8s/istio による安全なリリースフロー - GitOps によるシンプルで安全な運用 - istio/stackdriver による統一された監視
14. 01 開発速度と 信頼性の両立
15. 開発速度と信頼性の両立 リリースの速度・頻度を落とさず信頼性も維持 サービスを壊す変更を、 開発サイクルの初期に検出
16. 今までのリリースフロー 開発環境 機能 改修 A 機能 改修 B 機能 改修 C 本番環境 レビュー レビュー レビュー master branch release branch feature/A branch feature/B branch feature/C branch
17. 今までのリリースフローの問題点 - 手元と実環境の環境の差異で壊れる可能性 - 手元では動いたのに実際の DB やサービスと結合したら動かない 開発環境 本番環境 レビュー レビュー レビュー
18. 今までのリリースフローの問題点 - 開発と本番の環境の差異で壊れる可能性 - 開発環境では動いてたのに本番のネットワークだと動かない 開発環境 本番環境 レビュー レビュー レビュー
19. 今までのリリースフローの問題点 - リリースフロー後半で手戻りするので時間かかる 開発環境 本番環境 レビュー レビュー レビュー
20. 対策 - 開発初期の段階で実際にサービスが動く環境で検証す ることで、問題を検出し手戻りを減らす - 開発・修正サイクル高速化、信頼性の向上 - リリース前の確認環境と本番環境の差を極力なくし、リ リースで壊れなくする - 信頼性の向上
21. 速度と信頼性を両立させるリリースフロー 開発環境 機能検証環境 機能 改修 A 機能 改修 B 機能 改修 C staging 環境 機能検証環境 機能検証環境 レビュー レビュー レビュー feature/A branch master branch release branch feature/B branch feature/C branch 本番環境
22. 速度と信頼性を両立させるリリースフロー 開発環境 検証環境 staging 環境 検証環境 検証環境 レビュー 本番環境 - feature branch ごとに用意される独立した検証環境 - 開発初期に実環境上での挙動を確認でき、手戻り少なく修正可能 - レビュー時に実環境での挙動確認まで行えて問題を検出しやすい レビュー レビュー
23. 速度と信頼性を両立させるリリースフロー - 本番と全く同じ条件下で動く staging 環境 - 動いてるバイナリ・network・環境変数・ドメインなど全て同じ - リリース前に本番での正確な挙動を事前にテストできる 開発環境 検証環境 staging環境 検証環境 検証環境 レビュー 本番環境 レビュー レビュー
24. 実現方法
25. 1branch 1環境をどう実現するか 開発環境 機能検証環境 機能 改修 A 機能 改修 B 機能 改修 C staging 環境 機能検証環境 機能検証環境 レビュー レビュー レビュー feature/A branch master branch release branch feature/B branch feature/C branch 本番環境
26. 1 branch 1 環境をどう実現するか 機能検証用 VM APP - feature branch への push の度にインスタンスを起動す るのは時間的にもコスト的にも非効率 - もっとサクッと立ち上げたい 機能検証用 VM APP 機能検証用 VM APP
27. 1branch 1環境をどう実現するか 機能検証用pod - k8sなら、既に立ち上がっているマシンの上でpodの追 加・削除するだけなので効率的 k8sクラスタ 機能検証用pod 機能検証用pod APP APP APP
28. 検証環境と実際の環境の差異をなくすには 開発環境 機能検証環境 機能 改修 A 機能 改修 B 機能 改修 C staging 環境 機能検証環境 機能検証環境 レビュー レビュー レビュー feature/A branch master branch release branch feature/B branch feature/C branch 本番環境
29. 検証クラスタ 検証環境と実際の環境の差異をなくすには - クラスタもドメインも分けて実現する場合 - クラスタ・ドメインの差異による条件・挙動の違いが出る - クラスタの構成の違い・異なるドメインの Cookie の扱いの違い等 開発クラスタ 開発 pod nikkei.dev.com 検証 pod A nikkei.test-a.com
30. 検証環境と実際の環境の差異をなくすには - 同一クラスタ上で同一ドメインでアクセスできるようにし、 実行環境を揃える必要 開発クラスタ 開発 pod ・ ・ ・ nikkei.dev.com 検証 pod A 検証 pod B
31. 開発クラスタ 検証環境と実際の環境の差異をなくすには - 同一クラスタ上で、リクエストヘッダによってアクセス先 環境を分けることで実現 開発 pod ・ ・ ・ nikkei.dev.com 検証 pod A 検証 pod B
32. 開発クラスタ 検証環境と実際の環境の差異をなくすには - 同一クラスタ上で、リクエストヘッダによってアクセス先 環境を分けることで実現 開発 pod ・ ・ ・ nikkei.dev.com 検証 pod A 検証 pod B version: test-A
33. staging 環境 - 同様に、staging も本番と全く同じ環境を実現 本番クラスタ v1 pod ・ ・ ・ nikkei.com v2 pod 本番 staging
34. staging 環境 - 同様に、staging も本番と全く同じ環境を実現 - stagingは本番と同じ環境・条件で動いている 本番クラスタ 本番pod ・ ・ ・ nikkei.com staging pod v1 pod v2 pod 本番 staging
35. staging 環境 - 同様に、staging も本番と全く同じ環境を実現 - stagingは本番と同じ環境・条件で動いている - 開発者はリクエストヘッダをつけると staging へアクセスできる 本番クラスタ 本番pod ・ ・ ・ nikkei.com staging pod version: staging v1 pod v2 pod 本番 staging
36. staging 環境 - 同様に、staging も本番と全く同じ環境を実現 - リリース後の挙動を事前に高い精度で検証できる 本番クラスタ 本番pod ・ ・ ・ nikkei.com staging pod v1 pod v2 pod 本番 staging
37. staging から本番への安全なリリース - リリース時は、ユーザからのリクエストの向き先を staging へ変更し、staging 環境を本番環境に昇格 本番クラスタ v1 pod ・ ・ ・ nikkei.com v2 pod 本番 staging
38. staging から本番への安全なリリース - リリース時は、ユーザからのリクエストの向き先を staging へ変更し、staging 環境を本番環境に昇格 本番クラスタ v1 pod ・ ・ ・ nikkei.com v2 pod staging 本番
39. staging から本番への安全なリリース - リリース時は、ユーザからのリクエストの向き先を staging へ変更し、staging 環境を本番環境に昇格 - staging から本番へ移行する際の変化を最小化 本番クラスタ v1 pod ・ ・ ・ nikkei.com v2 pod staging 本番
40. Rollback - 問題が起きたら Routing を戻すだけで Rollback できる - blue/green と同じ 本番クラスタ v1 pod ・ ・ ・ nikkei.com v2 pod 本番 staging
41. Routing 制御のための istio の設定 Header に app-version: v1 がついてたら v1 へ Routing Header に app-version: v2 がついてたら v2 へ Routing Default で v1 へ Routing Virtual Service
42. Routing 制御のための istio の設定 Header に app-version: v1 がついてたら v1 へ Routing Header に app-version: v2 がついてたら v2 へ Routing Default で v2 へ Routing Virtual Service
43. 現状の問題点と対策 - 本番の負荷・リクエストパターンでしか再現しない問題を検出できな い - 本番と同じリクエストを受けても壊れないことをstaging 段階で保証 する必要がある
44. 本番クラスタ 現状の問題点と対策 - Mirroring v1 ・ ・ ・ - Request Mirroring で、本番と同じリクエストを staging に送る - 実際のリクエストや負荷で問題ないか、ユーザ影響なく検証できる - 更新系リクエストを Mirroring すると、データに不整合が起こる可能性がある - 裏にいるシステムに 2 倍の負荷がかかる... v2 GET /api/hoge GET /api/hoge GET /api/hoge
45. 本番クラスタ 現状の問題点と対策 - Canary v1 ・ ・ ・ - Weighted Routing 使って Canary Release - 同一ユーザが常に同一グループに振り分けられるとは限らない - アクセス毎にv1に振られたりv2に振られたりする - https://github.com/istio/istio/issues/9764 v2 30% 70%
46. 本番クラスタ 現状の問題点と対策 - Canary v1 ・ ・ ・ - Fastlyで weight を制御する - ユーザ ID や UA をベースに Fastly で version を振り分ける - アクセス毎に振り分け先が変わることのない安定した Canaryが実現 v2 70% version: v1 Fastly 30% version: v2
47. 02 シンプルで 安全な運用
48. シンプルで安全な運用 - 人為的な事故が起きづらい - 操作ミス・設定ミス・うっかりによる環境破壊など - 事故が起きてもすぐに元の状態に戻せる - 運用のための学習コストが低い - 誰でもできて属人性が低い
49. kubectl による運用の問題点 kubectl apply Developer Developer 強力な権限が必要 操作の学習コスト高 操作ミスのリスク高 運用負荷高 変更履歴が追えない
50. GitOps - サービス A は v1・v2 が存在 - サービス B は v1・v2 が存在 - サービス A は v1 へ Routing - サービス B は v2 へ Routing - Rate Limit は 100req/sec Sync - クラスタ上の状態を全て Git 上で管理 - クラスタは常に Git 上の状態と同一の状態に同期される GitHub Developer CI
51. GitOps - git 上の manifest を変更することでのみシステムを変更可
52. GitOps でシンプルで安全な運用が実現 - PR レビューを通じて、操作ミス・設定ミス・うっかりを防止 - 変更履歴が管理されてるので、何かあってもすぐ戻せる - 運用ツールが git・github のみなのでシンプル
53. GitOps による運用例 - リリース - リリースも PR を通じて行われる 1. staging 環境へデプロイするPR 2. staging 環境を本番へ昇格させるPR
54. GitOps による運用例 - リリース - 1つめの PR をマージすれば staging へデプロイ - 最新バージョン (v6601) の pod が作成される 本番クラスタ v6592 v6601
55. GitOps による運用例 - リリース - 2 つめの PR をマージすれば staging が本番へ昇格 - 最新バージョン (v6601) へ Routing を変更する 本番クラスタ v6592 v6601
56. GitOps による運用例 - Rollback - リリースで問題起きたら、PR を revert するだけで Rollback - 誰でもどこでもできるので、問題発生時の一時対応が迅速 (数十秒)
57. GitOps を使った実際のリリースフロー Developer Source Repo Manifest Repo Push Trigger Push Watch Sync k8s cluster Pull Container Registry Argo CD Circle CI PR & Merge
58. GitOps を使った実際のリリースフロー Developer Source Repo Manifest Repo Push Trigger Push Watch Sync k8s cluster Pull Container Registry Argo CD Circle CI PR & Merge アプリケーションコードを管 理するレポジトリ
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 を管理するレポジトリ
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 とクラスタを同 期するツール
61. GitOps を使った実際のリリースフロー Developer Source Repo Manifest Repo Push Trigger Push Watch Sync k8s cluster Pull Container Registry Argo CD Circle CI PR & Merge コードの変更を push
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
63. GitOps を使った実際のリリースフロー Developer Source Repo Manifest Repo Push Trigger Push Watch Sync k8s cluster Pull Container Registry Argo CD Circle CI PR & Merge リリース用 PR を 自動作成 & マージ
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 の変 更を検知して
65. GitOps を使った実際のリリースフロー Developer Source Repo Manifest Repo Push Trigger Push Watch Sync k8s cluster Pull Container Registry Argo CD Circle CI PR & Merge クラスタに manifest の内容が反映される
66. 03 一貫した監視
67. 一貫した監視 - Istio ならサービスに影響を与えることなくメトリクス収集・監視可能
68. 一貫した監視 - GKE なら Istio で集めたメトリクス・ログを Stackdriver に集約してくれる Stackdriver
69. Stackdriver - 統一された Monitoring
70. Stackdriver - 統一された Logging
71. 一貫した監視 - 監視手法・ログ・メトリクス・運用方法が統一された - => 基盤上のサービスであれば統一した手法で初期調査・復旧可能 - 開発に全く関わってないサービスの調査も可能 - サービス・チームをまたがる横断的な対応が可能になる
72. 04 基盤の安全な メンテナンス
73. 基盤の安全なメンテナンス - k8s/istio は更新が早く状況が変わりやすい - 大規模な構成変更をやりやすくし、常に安全&管理しやすい 状態を保つ必要性がある - クラスタの再生成が必要な変更 (GKE 新機能の利用の際など) - ServiceMesh や Network 構成の変更 - etc...
74. 基盤の安全なメンテナンス - Cluster レベルの Blue/Green で安全にクラスタの更新・変更が可能 Manifest Repo Argo CD Watch Sync blue cluster
75. 基盤の安全なメンテナンス - green cluster を作成し、ArgoCD で blue cluster と全く同じ環境を再現 Manifest Repo Argo CD Watch Sync blue cluster green cluster
76. 基盤の安全なメンテナンス - green cluster に更新を加えて Manifest Repo Argo CD Watch Sync blue cluster updated green cluster
77. 基盤の安全なメンテナンス - DNS を切り替える Manifest Repo Argo CD Watch Sync blue cluster updated green cluster
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
79. 旧環境からの移行状況
80. 旧環境からの移行状況 Fastly Service A Service B Service C Service A Service B Service C CI/CD 常に両環境に Deploy 移行するサービス だけ Routing 変更 旧 新
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 ・・・
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 ・・・
83. 旧環境からの移行状況 - 旧環境からどうしても移行できないものもある - 永続化したデータの移行に大きなコストがかかるものなど - でもコンテナの実行環境の移行自体は可能なものが多い - それぞれの環境内に k8s を立てて、k8s へ載せ替えていきたい
84. 旧環境からの移行状況 GKE Other Cluster Other Cluster Service Service Service Service Service Service istio istio istio Stackdriver - k8s に乗せられればクラスタ上の構成や運用は再現可能 - 監視・メトリクス・運用の統一の恩恵は受けられる
85. 旧環境からの移行状況 GKE Other Cluster Other Cluster Service Service Service Service Service Service istio istio istio Stackdriver - k8s に乗せられればクラスタ上の構成や運用は再現可能 - 監視・メトリクス・運用の統一の恩恵は受けられる
86. まとめ - k8s/istio で、信頼性と開発速度を両立できるフローを実現 - GitOps で運用もシンプルかつ安全に - istio で、サービス間で統一された監視・メトリクス収集が実現 - 監視・運用基盤を統一し開発チームの負荷削減 - 更新しやすいインフラで常に安全&管理しやすい状態に保つ
87. 日経はエンジニアの仲間を募集中 - SRE チームは中途・フリーランスどちらも募集中 - エンジニアが 1 名増えることの効果が大きい状況 - 興味ある方は twitter( @nikkeideveloper )にDMを - Wantedly: https://www.wantedly.com/projects/367306 - オフィス見学歓迎
88. Thank you