Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SpinnakerとKayentaで 高速・安全なデプロイ!

1,629 views

Published on

各機能ごとに開発チームを分け、それらをAPIなどで疎結合させるMicroservicesな開発体制の問題点の一つとして、各チームごとのノウハウが共有されず、チームごとのリリースや更新までのスピードにばらつきがあります。また、サービスが複数にまたがり複雑化することで、サービス間の挙動が分かりづらく問題が見つけにくいといったこともあります。
現在NTTコミュニケーションズではこうした問題を解決し、高速かつ継続的にデプロイを行うために、Continuous deliveryのプラットフォームであるSpinnakerと、分散したサービス間の情報をトレースするための分散トレーシングツール、そしてサービスの新しいバージョンを一部先行してリリースをすることで動作検証を行うカナリアリリースを行うためのKayentaを導入した、開発チームが共通して利用するためのサービスデプロイ基盤の検証を行っております。
本資料ではSpinnaker, 分散トレーサー, カナリアリリース(Kayenta)などについてお話します。

Published in: Technology
  • Be the first to comment

SpinnakerとKayentaで 高速・安全なデプロイ!

  1. 1. SpinnakerとKayentaで 高速・安全なデプロイ! Cloud Native Days Tokyo 2018 2018 年 8 月 3 日
  2. 2. Mahito Ogura <m.ogura@ntt.com> NTTコミュニケーションズ株式会社 技術開発部 業務:IoT関連 (2018/7〜) ● クラウドや分散システムの調査検証 ● 分散トレーシングなどの分散システムの調査検証 ● OpenStackやコンテナに関する調査検証 ● インフラ構築(Chef, Ansible) ● アプリケーション開発 ● 採用のお手伝いとか各種イベント業, etc... About me
  3. 3. セッション概要 ● Continuous DeliveryプラットフォームのSpinnaker ● Automated Canary Analysisを実現するKayenta ● Microservicesの挙動を把握するための分散トレーシング これらを利用した 高速で安全な継続的デリバリーを実現する方法の紹介
  4. 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. 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. 6. DevOops 問題を起こさないための作業にDevもOpsも疲弊し、開発は遅れる・・・ dev staging productiondocuments Dev Teams Senior managersmanagermanager Operators
  7. 7. サービスが大きくなり機能が増えるとシステムの挙動や性能の把握は難しい Microservices ≒ Very complex ... 例:OpenStackのアーキテクチャ
  8. 8. 問題の把握 Microservicesへの対応 1. 組織構造(Dev/Ops) 2. ナレッジの分散 3. 数多くの手作業 4. 複雑で不可視な問題 情報共有や問題解析に時間がかかり サービスのデプロイに手が回らない
  9. 9. サービスのデプロイを加速: ● Devはサービスの実装及び改善に専念 ● デプロイ工程を統一化&自動化 ● サービス間の問題を把握するしくみの導入
  10. 10. SREチームによる共通のCI/CD基盤 (PoC) の提供 dev staging production Developer integration canaria stablemanager Developer Jenkins Spinnaker Operators SRE Team
  11. 11. Microservices内外での動きを可視化するために分散トレーシングを導入 分散トレーシングによる可視化 User Request API RPC DB API RPC API User Service Time
  12. 12. 取り組んだこと 1. パイプラインの自動化 2. サービス間の問題の把握
  13. 13. パイプラインはアプリケーションのコードをプロダクションにリリースするために必要なすべ ての手順を実行するプロセス Pipline Build Deploy Test Approve
  14. 14. Spinnaker
  15. 15. Spinnakerとは ● マルチクラウド上でContinuous Delivery(CD)を実現するツール ● Imageの作成やサーバグループの作成、デプロイ、条件に応じたスケールなどをパ イプラインとして組むことでマルチクラウドの上でMicroservicesを実現するためのデ プロイツール ● CDツールでありCIツールやPaaSではない ● Netflix社が開発し、OSSとして公開されているが現在はGoogleやPivotal, Microsoft, Mirantisなども開発に参加している ● 公式ドキュメント以外の情報を得るためにはコミュニティに頼るのが現状 ● また、Spinnaker自体がMicroservicesでありちょっと複雑
  16. 16. Blue / Green Deployment SpinnakerはBlue/green(Red/black)デプロイメントを実現する Green (最新版)に問題があった場合はBlue(旧版)にRollbackすることも可能 https://www.spinnaker.io/concepts/
  17. 17. Spinnaker Cloud Target 詳細はリポジトリを御覧ください https://github.com/spinnaker/clouddriver/ ● AWS (EC2) ● Docker ● GCP (AppEngine, GCE, GKE) ● Kubernetes ● Microsft Azure ● OpenStack ● etc...
  18. 18. Spinnaker Architecture Gate Orca Front50 Clouddriver Rosco Kayenta Igor Echo Script Dec Fiat 外部
  19. 19. SpinnakerとGCPを利用したCI / CD Pipline Integration Staging Canary Production JenkinsDeveloper build register trigger trigger push test test deploy & test Manager approve
  20. 20. Sample Spinnaker Pipeline
  21. 21. Canary Release CC 表示-継承 3.0 File:Gelber Kanarienvogel.JPG
  22. 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
  23. 23. ソフトウェア開発におけるCanary 新しいソフトウェアのバージョンをプロダクション環境へデプロイする際のリスクを減らす一つの技術 にCanary Releaseがある。プロダクトやサービスの新機能を一部のユーザ向けに開放した状態でリ リースを行い、新機能に問題がないことを確認しながら段階的に全体に向けて展開していく。Canary に問題があった際はデプロイした機能をロールバックすることで元のバージョンに戻すことも可能。 Production (v1.0) Canary (v2.0)Canary Release or Rolleback Analysis Developer Users Metrics
  24. 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. 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. 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. 27. Canary Configs ● Metrics ○ どの値をテストに利用するか ● Filter ○ Metricsの対象をフィルタ ● Scoring ○ しきい値の設定 ○ メトリクスのウェイトの設定
  28. 28. Canary Report
  29. 29. まとめ - パイプラインの自動化 - Pros ● ソースコードの変更を契機にビルド〜テストまでのパイプラインを自動化 ● カナリアリリースで小さく試すことで問題をいち早く発見 ● 最新バージョンに問題があった際は前バージョンに切り戻し可能 Cons ● Spinnakerの管理が少々複雑 ● 公式の情報以外があまりない ● Pipelineの作成がGUIベース(pipline-templates はあるけど...?) ● 現在Spinnakerと連携可能なCIツールがJenkinsとTravisCIしかない ● Kayentaで使えるメトリクスが限られている
  30. 30. 取り組んだこと 1. パイプラインの自動化 2. サービス間の問題の把握
  31. 31. 分散トレーシング 最近のシステムは分散し複雑化され、機能ごとの関係性を把握することは難しく、エラー や性能問題などが起きた際にその原因特定が非常に難しくなる。 こうした問題に取り組むべく、分散されたサービス内のリクエストをトレース可能な、分散ト レーシング技術が現在注目を浴びている。 しかしながら分散トレーシングはここ最近の技術ではなく10年以上前から存在している が、2010年にGoogleが公開したDapperの論文をもとに、以降Twitter社が開発してOSS 化したZipkin, Hadoopなどで利用されているHTraceが登場
  32. 32. 分散トレーシング 分散トレーシングに必要な仕組みは次の2つ 1. 分散トレーシングの仕組み(ライブラリ含む) 2. トレースの結果をモニタリングするためのしくみ トレーサがシステムの性能に影響を及ぼさないように、 一部の処理だけをトレースするSamplingの方法とその割合を設定できる ものもある(ex. Zipkin, OpenTracing, etc...)
  33. 33. 分散トレーシングのユースケース ● プログラム内の関数レベルのトレース ● サーバのエンドポイントのトレース ● クライアントコールのトレース ● 分散環境におけるデータの分散 / 転送 ● イベントのロギング ● メッセージバス(Message Queue, Pub/Sub)シナリオのトレース
  34. 34. 一般的なプラットフォームに向けて、一貫したベンダ非依存なAPIを提供することで、開 発者に容易にシステムへトレーサの追加、またはトレーサの切り替えを行うことが出来るし くみを提供する分散トレーシングの実装。 2016年10月にCNCFのプロジェクトになった。 また、実装以外にもプラットフォーム固有のトレーサーに向けた共通仕様も用意しており、 他の分散トレーシングツールはこの仕様を実装することで、OpenTracing互換のトレー サーとして実装することが出来るため、ユーザは設定の変更だけでトレーサの切り替えを 行うことができる。 OpenTracing[1] [1]: http://opentracing.io/
  35. 35. 分散トレーシング(ex. OpenTracing)用語解説 -1/2- Trace:Span全体のStartからFinishまでを含むSpanの集合体 Span:ひとつのサービス(境界)内の処理 User Request API RPC DB API RPC Time Trace Span
  36. 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. 37. Jaeger[1] Uber社がGo言語で開発しているOpenTracing互換の分散トレーサーとそのUI 2017年9月にプロジェクトがCNCFにホストされることになった Go言語で書かれた自前のモニタリングツールが用意されている Go, Python, Node, C#, JavaなどのTracerが用意されている [1]: https://www.jaegertracing.io/
  38. 38. Jaeger’s Architecture[1] [1]: http://jaeger.readthedocs.io/en/latest/architecture/
  39. 39. Jaeger sample (OpenStack Nova)
  40. 40. [1]:http://zipkin.io/pages/architecture.html Zipkin GoogleのDapperを参考に作られた分散トレーシングシステム 分散システムのレイテンシ問題の トラブルシューティングに必要な データを収集し(Zipkin)、 システムの依存関係を参照するための UI(Zipkin UI)を提供する アーキテクチャは右図[1]参照 ● ReporterはTransportにデータを転送 ● Transporはcollectorにデータを転送 ● CollectorはStorageにデータを格納
  41. 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. 42. 分散トレーシングの導入にあたって 1. 何をしたいのかを明確にする (Traging or Traginc + Logging, etc...) 2. トレースしたい対象の処理(REST, DB, gRPC, etc...)を明確にして対応を調べる 3. 利用しているプログラミング言語に対応しているかを調べる 4. 他の分散トレーシングツールとの互換性を考える 5. データストアについて考える (データをどれだけ、どの期間持つかなど )
  43. 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. 44. まとめ - サービス間の問題把握 - Pros ● サービスの挙動やレイテンシを把握できる Cons ● トレーサーごとの互換性などを ● プログラミング言語のライブラリごとにできることが異なる ● トレースしたデータの取り扱いが難しい ● そもそも過渡期なので選択が難しい ...
  45. 45. 今後の予定 ● VMで動かしているサービスをパイプラインに載せる ● Chaos Engineeringの導入 ○ Chaos Monkey ○ Kube-monkey … ? ● シナリオ試験などでStackdriver Traceの結果を利用
  46. 46. まとめ SpinnakerとKayentaを利用することで、 CI/CDからカナリアリリースまでのパイプラインを実現し、 人手を介さない高速で安全なデプロイを実現 また、分散トレーシングを用いてMicroservices間のレイテンシや挙動を 把握することで、問題を見つけすばやく改善につなげる事が可能に
  47. 47. 宣伝 https://ntt-developers.github.io/ntt-tech-conference/03/
  48. 48. Presentation by NTT Communications

×