SpinnakerとKayentaで 高速・安全なデプロイ！
•
5 gostaram•4,609 visualizações
各機能ごとに開発チームを分け、それらをAPIなどで疎結合させるMicroservicesな開発体制の問題点の一つとして、各チームごとのノウハウが共有されず、チームごとのリリースや更新までのスピードにばらつきがあります。また、サービスが複数にまたがり複雑化することで、サービス間の挙動が分かりづらく問題が見つけにくいといったこともあります。 現在NTTコミュニケーションズではこうした問題を解決し、高速かつ継続的にデプロイを行うために、Continuous deliveryのプラットフォームであるSpinnakerと、分散したサービス間の情報をトレースするための分散トレーシングツール、そしてサービスの新しいバージョンを一部先行してリリースをすることで動作検証を行うカナリアリリースを行うためのKayentaを導入した、開発チームが共通して利用するためのサービスデプロイ基盤の検証を行っております。 本資料ではSpinnaker, 分散トレーサー, カナリアリリース(Kayenta)などについてお話します。
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a SpinnakerとKayentaで 高速・安全なデプロイ！
Semelhante a SpinnakerとKayentaで 高速・安全なデプロイ！ (20)
Mais de NTT Communications Technology Development
Mais de NTT Communications Technology Development (20)
SpinnakerとKayentaで 高速・安全なデプロイ！
- 1. SpinnakerとKayentaで 高速・安全なデプロイ！ Cloud Native Days Tokyo 2018 2018 年 8 月 3 日
- 2. Mahito Ogura <m.ogura@ntt.com> NTTコミュニケーションズ株式会社 技術開発部 業務：IoT関連 (2018/7〜) ● クラウドや分散システムの調査検証 ● 分散トレーシングなどの分散システムの調査検証 ● OpenStackやコンテナに関する調査検証 ● インフラ構築（Chef, Ansible） ● アプリケーション開発 ● 採用のお手伝いとか各種イベント業, etc... About me
- 3. セッション概要 ● Continuous DeliveryプラットフォームのSpinnaker ● Automated Canary Analysisを実現するKayenta ● Microservicesの挙動を把握するための分散トレーシング これらを利用した 高速で安全な継続的デリバリーを実現する方法の紹介
- 4. Microservices Team A Service A Team B Service B Team C Service C I/F Ruby Chef Document Python Ansible Document Java Puppet Document 各チームが開発するサービスはI/Fを通じて他サービスと連携を行うため、 I/Fをあわせておけば各チームの開発方法は各チームに移譲が可能
- 5. Dev/Ops Dev Team A Service A Dev Team B Service B Dev Team C Service C I/F Dev Ops Ops Team Ruby Chef Document Python Ansible Document Java Puppet Document DevとOpsが分かれていると Opsは運用しきれない...
- 6. DevOops 問題を起こさないための作業にDevもOpsも疲弊し、開発は遅れる・・・ dev staging productiondocuments Dev Teams Senior managersmanagermanager Operators
- 7. サービスが大きくなり機能が増えるとシステムの挙動や性能の把握は難しい Microservices ≒ Very complex ... 例：OpenStackのアーキテクチャ
- 8. 問題の把握 Microservicesへの対応 1. 組織構造（Dev/Ops） 2. ナレッジの分散 3. 数多くの手作業 4. 複雑で不可視な問題 情報共有や問題解析に時間がかかり サービスのデプロイに手が回らない
- 9. サービスのデプロイを加速: ● Devはサービスの実装及び改善に専念 ● デプロイ工程を統一化＆自動化 ● サービス間の問題を把握するしくみの導入
- 10. SREチームによる共通のCI/CD基盤 (PoC) の提供 dev staging production Developer integration canaria stablemanager Developer Jenkins Spinnaker Operators SRE Team
- 14. Spinnaker
- 15. Spinnakerとは ● マルチクラウド上でContinuous Delivery（CD）を実現するツール ● Imageの作成やサーバグループの作成、デプロイ、条件に応じたスケールなどをパ イプラインとして組むことでマルチクラウドの上でMicroservicesを実現するためのデ プロイツール ● CDツールでありCIツールやPaaSではない ● Netflix社が開発し、OSSとして公開されているが現在はGoogleやPivotal, Microsoft, Mirantisなども開発に参加している ● 公式ドキュメント以外の情報を得るためにはコミュニティに頼るのが現状 ● また、Spinnaker自体がMicroservicesでありちょっと複雑
- 16. Blue / Green Deployment SpinnakerはBlue/green（Red/black）デプロイメントを実現する Green (最新版)に問題があった場合はBlue（旧版）にRollbackすることも可能 https://www.spinnaker.io/concepts/
- 17. Spinnaker Cloud Target 詳細はリポジトリを御覧ください https://github.com/spinnaker/clouddriver/ ● AWS (EC2) ● Docker ● GCP (AppEngine, GCE, GKE) ● Kubernetes ● Microsft Azure ● OpenStack ● etc...
- 19. SpinnakerとGCPを利用したCI / CD Pipline Integration Staging Canary Production JenkinsDeveloper build register trigger trigger push test test deploy & test Manager approve
- 21. Canary Release CC 表示-継承 3.0 File:Gelber Kanarienvogel.JPG
- 22. Canaryとは Canary = カナリア = 鳥 炭鉱のカナリア 炭鉱においてしばしば発生する毒ガス早期発 見のための警報として使用された。本種はつ ねにさえずっているので、異常発生に先駆け まずは鳴き声が止む。つまり危険の察知を目と 耳で確認できる所が重宝され、毒ガス検知に 用いられた （カナリア - Wikipedia より） CC BY-NC 2.0 David & Angie - Canary in a Coal mine... wear a mask! https://www.flickr.com/photos/studiomiguel/3946174063
- 24. NetflixのCanary Release Process 3つのクラスタで運用しそれぞれに同じトラフィックから量を変えて流す 1. Production：本番環境 (many servers) 2. Baseline：Canaryと比較するための現行バージョン(1 + m servers) 3. Canary：新バージョン(1 + m servers) Traffic Router Metrics Canary Analysis Production(v1.0) Baseline(v1.0) Canary(v2.0)
- 25. Kayenta [1] 2018年4月にNetflixとGoogleが共同でOSS化したAutomated Canary Analysis (ACA)の 基盤。[2][3] 実際にはKayentaはSpinnakerの一機能としてACAの動作を行う 基準（Baseline）と新バージョン（Canary）から取得するメトリクスを比較することで、メトリク スに差分（上、下、上下）にブレがないかを確認することで、新バージョンに問題がないか を分析することができる。 メトリックスの取得に使えるのは現在 Stackdriver, Prometheus, Datadog 参考 ● [1] : https://github.com/spinnaker/kayenta ● [2] : Automated Canary Analysis at Netflix with Kayenta ● [3] : Introducing Kayenta: An open automated canary analysis tool from Google and Netflix
- 26. Canary Analysis Configuration ● Analysis Type ○ Real Time or Retrospective ● Analysis Config ○ Config Name (詳細は次ページ) ○ Delay, Interval, Lookback Type ● Metrics Scope ○ Baseline の設定 ○ Canaryの設定 ○ Step ○ Lifetime ○ Resource Type ● Scoring Thresholds ● Execution Options ● Notifications
- 27. Canary Configs ● Metrics ○ どの値をテストに利用するか ● Filter ○ Metricsの対象をフィルタ ● Scoring ○ しきい値の設定 ○ メトリクスのウェイトの設定
- 28. Canary Report
- 29. まとめ - パイプラインの自動化 - Pros ● ソースコードの変更を契機にビルド〜テストまでのパイプラインを自動化 ● カナリアリリースで小さく試すことで問題をいち早く発見 ● 最新バージョンに問題があった際は前バージョンに切り戻し可能 Cons ● Spinnakerの管理が少々複雑 ● 公式の情報以外があまりない ● Pipelineの作成がGUIベース(pipline-templates はあるけど...?) ● 現在Spinnakerと連携可能なCIツールがJenkinsとTravisCIしかない ● Kayentaで使えるメトリクスが限られている
- 32. 分散トレーシング 分散トレーシングに必要な仕組みは次の2つ 1. 分散トレーシングの仕組み（ライブラリ含む） 2. トレースの結果をモニタリングするためのしくみ トレーサがシステムの性能に影響を及ぼさないように、 一部の処理だけをトレースするSamplingの方法とその割合を設定できる ものもある(ex. Zipkin, OpenTracing, etc...)
- 33. 分散トレーシングのユースケース ● プログラム内の関数レベルのトレース ● サーバのエンドポイントのトレース ● クライアントコールのトレース ● 分散環境におけるデータの分散 / 転送 ● イベントのロギング ● メッセージバス（Message Queue, Pub/Sub）シナリオのトレース
- 35. 分散トレーシング(ex. OpenTracing)用語解説 -1/2- Trace：Span全体のStartからFinishまでを含むSpanの集合体 Span：ひとつのサービス（境界）内の処理 User Request API RPC DB API RPC Time Trace Span
- 36. 分散トレーシング(ex. OpenTracing)用語解説 -2/2- Span内の要素 ● Operation Name ● Start Timestamp ● Finish Timestamp ● Span Context ○ Baggage Items ○ Trace ID / Span ID ● Span Tag ● Span Log ● References (他Spanとの関係性)
- 37. Jaeger[1] Uber社がGo言語で開発しているOpenTracing互換の分散トレーサーとそのUI 2017年9月にプロジェクトがCNCFにホストされることになった Go言語で書かれた自前のモニタリングツールが用意されている Go, Python, Node, C#, JavaなどのTracerが用意されている [1]: https://www.jaegertracing.io/
- 39. Jaeger sample (OpenStack Nova)
- 40. [1]：http://zipkin.io/pages/architecture.html Zipkin GoogleのDapperを参考に作られた分散トレーシングシステム 分散システムのレイテンシ問題の トラブルシューティングに必要な データを収集し（Zipkin）、 システムの依存関係を参照するための UI（Zipkin UI）を提供する アーキテクチャは右図[1]参照 ● ReporterはTransportにデータを転送 ● Transporはcollectorにデータを転送 ● CollectorはStorageにデータを格納
- 41. サービス間のlatencyなどのメトリックとトレースを収集し、さまざまなバックエンドにエクス ポートすることができるライブラリ。 Googleの社内で使われていたものを書き直したベンダーニュートラルなOSS Go, Java, C++, Ruby, Erlang, Python, PHPに対応 ExporterにはAWS X-Ray, Stackdriver, Jaeger, Datadog, Prometheus, Zipkinが利用可能 ※言語によって対応しているものしていないものがあるので注意 OpenCensus[1] [1]: https://opencensus.io/
- 42. 分散トレーシングの導入にあたって 1. 何をしたいのかを明確にする (Traging or Traginc + Logging, etc...) 2. トレースしたい対象の処理（REST, DB, gRPC, etc...）を明確にして対応を調べる 3. 利用しているプログラミング言語に対応しているかを調べる 4. 他の分散トレーシングツールとの互換性を考える 5. データストアについて考える (データをどれだけ、どの期間持つかなど )
- 43. Stackdriver Trace[1] Google Cloud Platformが提供する分散トレースシステム アプリケーション内のリクエストのトレースや、 ロギングなどを行ったのを右図のように結果として 表示ができる OpenCensusのライブラリを使ってデータを転送 ※Zipkinのトレーサーからデータを送信することも可能 [2] GCPを使っている場合は無料で利用可能 [1]: https://cloud.google.com/trace/ [2]: https://github.com/openzipkin/zipkin-gcp
- 44. まとめ - サービス間の問題把握 - Pros ● サービスの挙動やレイテンシを把握できる Cons ● トレーサーごとの互換性などを ● プログラミング言語のライブラリごとにできることが異なる ● トレースしたデータの取り扱いが難しい ● そもそも過渡期なので選択が難しい ...
- 45. 今後の予定 ● VMで動かしているサービスをパイプラインに載せる ● Chaos Engineeringの導入 ○ Chaos Monkey ○ Kube-monkey … ? ● シナリオ試験などでStackdriver Traceの結果を利用
- 48. Presentation by NTT Communications