テレビ・レコーダーのバックエンドにおけるCI/CDへの取り組み

Slide 1

Slide 1 text

1 1 テレビ・レコーダーのバックエンドにおける CI/CDへの取り組み 2018/12/3 DevOps祭りソニーネットワークコミュニケーションズ株式会社佐藤瞬

Slide 2

Slide 2 text

自己紹介 2 • 佐藤瞬 • 所属 – ソニーネットワークコミュニケーションズ株式会社 Metaチーム • 経歴 – 2011-2016 SIとして受託開発 – 2016- 転職し、現在の会社へ • 過去のスライド – https://www.slideshare.net/tenbo07 – https://speakerdeck.com/tenbo07

Slide 3

Slide 3 text

Metaサービスについて

Slide 4

Slide 4 text

Meta Service Overview 4 TV SideView Music Center • テレビ番組、ビデオ、音楽のコンテンツメタデータの配信や関連する機能の提供を行う，ソニー社内のクラウドサービスプラットフォーム • ソニーのホーム機器 (BRAVIA / BDRE / BDP) 上のアプリやモバイルアプリ (TV SideView / Music Center) 向けにサービスを提供 • フロントエンドの Web API サービス、およびバックエンドのデータアグリゲーション／検索／推薦などのサブコンポーネントで構成 BRAVIA BD Recorder BD Player 300,000,000 request / day Meta Service

Slide 5

Slide 5 text

BRAVIA 5

Slide 6

Slide 6 text

• Metaサービスから以下を配信 – 番組表 – 予約ランキング – リアルタイム視聴数 – 番組検索 – 番組詳細 – 人物詳細 – VoDコンテンツ検索 • YouTube、ニコニコ動画など – おすすめ番組 – ブックマーク機能 6 Video & TV Side View

Slide 7

Slide 7 text

新作ドラマ・アニメガイド 7 新作ドラマ・アニメガイドの配信 – 次クールで始まる新ドラマ、新アニメの番組リストを前月から配信 – 新番組を1か月前から一気に録画可能 – 録画忘れ、録画漏れの防止にも！

Slide 8

Slide 8 text

全体構成

Slide 9

Slide 9 text

Data Store Worker/ Batch job HTTP API 全体構成 9 app A Proxy Batch A Client app B Batch B DB B DB A DB C Analysis Batch Scheduler app C ・・・・・・・・・

Slide 10

Slide 10 text

Data Store Worker/ Batch job HTTP API 全体構成 10 app A Proxy Batch A Client app B Batch B DB B DB A DB C Analysis Batch Scheduler app C ・・・・・・・・・主にこの部分の話

Slide 11

Slide 11 text

Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 11

Slide 12

Slide 12 text

Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 12

Slide 13

Slide 13 text

CI/CDパイプライン構築

Slide 14

Slide 14 text

Pipeline • MetaチームではCodePipelineを使ってPipelineを構築している • 現在、Dev/Staging/Prod合わせて40本程度のパイプラインが存在 – コンテナのDeploy Pipeline – EC2インスタンスのAMI更新Pipeline – ServerlessアプリケーションのデプロイPipeline 14

Slide 15

Slide 15 text

コンテナのDeploy Pipeline

Slide 16

Slide 16 text

コンテナの更新Pipeline パイプラインの流れ(Staging) 16 Commit 起動 Developer Build Staging Deploy Staging Test Staging Switch 新バージョンの起動新バージョンのテスト新バージョンへ切り替え Clean up 旧バージョンの停止 Docker Imageの作成

Slide 17

Slide 17 text

コンテナの更新Pipeline パイプラインの流れ(Prod) 17 Commit 起動 Developer Copy Image Prod Deploy Prod Test Prod Switch 新バージョンの起動新バージョンのテスト新バージョンへ切り替え Clean up 旧バージョンの停止 StagingのECRからDocker Imageのコピー Copy Staging Prod

Slide 18

Slide 18 text

コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 18 Target Group Client default.example.com Deploy前

Slide 19

Slide 19 text

コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 19 Target Group Target Group default.example.com Deploy時（新バージョンの起動） new.example.com 新バージョンにアクセスできるサブドメインを作成

Slide 20

Slide 20 text

コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 20 Target Group Target Group default.example.com Test new.example.com new.example.com

Slide 21

Slide 21 text

コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 21 Target Group Target Group Switch(新バージョンへ切り替え) Client default.example.com Listener Rule の切り替え

Slide 22

Slide 22 text

コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 22 Target Group Client default.example.com Clean Up

Slide 23

Slide 23 text

という感じで作ってましたが AWS CodeDeploy による AWS Fargate と Amazon ECS での Blue/Greenデプロイメントの実装 – https://aws.amazon.com/jp/blogs/news/use-aws-codedeploy-to- implement-blue-green-deployments-for-aws-fargate-and-amazon- ecs/ 23 ほぼ同じなので今からやるならCodeDepoyですかね

Slide 24

Slide 24 text

EC2インスタンスのAMI更新Pipeline

Slide 25

Slide 25 text

EC2インスタンスのAMI更新Pipeline パイプラインの流れ(Staging) 25 Commit 起動 Developer Build Deploy Rolling Update Docker Imageの作成 AMI Instances Auto Scaling Update

Slide 26

Slide 26 text

EC2インスタンスのAMI更新Pipeline パイプラインの流れ(Prod) 26 Commit 起動 Developer Copy Deploy Rolling Update Docker Imageの作成 AMI Instances Auto Scaling Update AMI Staging Prod Copy

Slide 27

Slide 27 text

ServerlessアプリケーションのDeploy Pipeline

Slide 28

Slide 28 text

ServerlessアプリケーションのDeploy Pipeline パイプラインの流れ(Staging/Prod) 28 Commit 起動 Developer Deploy Test Switch 新バージョンのStage/aliasを作成新バージョンのテスト新バージョンへ切り替え Clean up 旧バージョンのStageを削除（5世代前） SAMでLambda functionのデプロイ Build AWS SAM Custom Domainの向き先を新バージョンへ変更

Slide 29

Slide 29 text

ServerlessアプリケーションのDeploy Pipeline • Deploy～Clean Up – SAMはLambdaのデプロイパッケージ作成とfunction作成のみ – Deploy部分は直接APIからの操作で作成 29 v1.0.0 Stage /api v1.0.0(alias) Custom Domain Deploy前

Slide 30

Slide 30 text

ServerlessアプリケーションのDeploy Pipeline • Deploy～Clean Up – SAMはLambdaのデプロイパッケージ作成とfunction作成のみ – Deploy部分は直接APIからの操作で作成 30 v1.0.0 Stage /api v1.0.0(alias) v2.0.0 v2.0.0(alias) Custom Domain /test 新バージョンのStage/Aliasを作成

Slide 31

Slide 31 text

ServerlessアプリケーションのDeploy Pipeline • Deploy～Clean Up – SAMはLambdaのデプロイパッケージ作成とfunction作成のみ – Deploy部分は直接APIからの操作で作成 31 Test v1.0.0 Stage /api v1.0.0(alias) v2.0.0 v2.0.0(alias) Custom Domain /test テスト実行

Slide 32

Slide 32 text

ServerlessアプリケーションのDeploy Pipeline • Deploy～Clean Up – SAMはLambdaのデプロイパッケージ作成とfunction作成のみ – Deploy部分は直接APIからの操作で作成 32 Switch v1.0.0 Stage /api v1.0.0(alias) v2.0.0 v2.0.0(alias) Custom Domain /test

Slide 33

Slide 33 text

ServerlessアプリケーションのDeploy Pipeline • Deploy～Clean Up – SAMはLambdaのデプロイパッケージ作成とfunction作成のみ – Deploy部分は直接APIからの操作で作成 33 CleanUp Stage /api v2.0.0 v2.0.0(alias) Custom Domain

Slide 34

Slide 34 text

Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 34

Slide 35

Slide 35 text

CodePipelineの導入経緯

Slide 36

Slide 36 text

CodePipelineの導入経緯 36 CodePipelineの導入前、コード化されたPipelineは存在しなかった各工程（Build/Testなど）はジョブ化されているもののデプロイフロー全体を俯瞰できる場所がなかった Runbook Build等の各ジョブ実行

Slide 37

Slide 37 text

CodePipelineの導入経緯 37 CodePipelineの導入前、コード化されたPipelineは存在しなかった各工程（Build/Testなど）はジョブ化されているもののデプロイフロー全体を俯瞰できる場所がなかった Runbook Build等の各ジョブ実行

Slide 38

Slide 38 text

CodePipelineの導入経緯 38 Pipelineを作成する選択肢はいくつかある

Slide 39

Slide 39 text

CodePipelineの導入経緯 39 Pipelineを作成する選択肢はいくつかあるなぜCodePipelineを選択したか

Slide 40

Slide 40 text

CodePipelineの導入経緯 • Jenkinsの除外 – Jenkins自体のブラックボックス化が進み管理が難しくなっていたので、これ以上Jenkinsに役割を増やしたくない – 将来的にはBuild等もマネージドサービスに移管したい • Jenkins資産も活用したい – Pipelineの構築前、Build・Testなどの各ジョブはJenkinsで実行 – Jenkins環境に依存している部分が大きかったので、まずはそのまま使ってPipelineを構築したかった • コスト管理 – CircleCIなど別サービスを使う場合は支払先が増える – CodePipelineであればAWSのコストが増えるだけでコスト管理が楽 40

Slide 41

Slide 41 text

CodePipelineを導入してみて

Slide 42

Slide 42 text

CodePipelineを導入してみて良かった点 • Sourceの柔軟性 – Github以外のSourceを指定できる • S3、ECRへのPut/Pushを起点にPipelineを起動できる – 複数のリポジトリをInputにできる • GithubとS3オブジェクトの両方をInputにすることができる 42 リポジトリA リポジトリB

Slide 43

Slide 43 text

CodePipelineを導入してみて良かった点 • AWSの他サービスとの連携 – CodeBuild / ECS / CloudFormation / Lambdaなど – 最初は便利だが、最終的にはCodeBuild やLambdaで APIを叩いていることが多い • DeployやBuildといった作業自体が繊細なものなので、サービスやアプリケーションによって変えたいことが多いため – CodePipelineの利点ではあるが、他のCI/CDサービスと比較して大きな優位性というわけではないと思う • API叩けば他でもできてしまうため 43

Slide 44

Slide 44 text

CodePipelineで困りごと 44

Slide 45

Slide 45 text

CodePipelineで困りごとありましたが、改善されてきている • CodeBuildにInputを一つしか渡せない – CodeBuildのMulti Input Sourcesで改善 • 2018/9/4 Update • Githubトリガーがポーリングなので起動が遅い – AWS Codepipeline Supports Push Events from GitHub via Webhooks • 2018/5/1 Update • Stage間の遷移が遅い – AWS Codepipeline Now Executes Faster • 2018/11/19 Update 45

Slide 46

Slide 46 text

Slide 47

Slide 47 text

CodePipelineで困りごと現状ワークアラウンド的なことをしている部分 47

Slide 48

Slide 48 text

CodePipelineで困りごと現状ワークアラウンド的なことをしている部分 • SourceでGit Tagを指定できない（Branchのみ） – JenkinsでTagを取ってきてZipで固めてS3へUploadし、 S3 TriggerでPipelineを起動している • リリースブランチを切るという選択もある • CodePipelineの実行時にパラメーター指定ができない – （そもそも、その運用が正しいかはありますが） – S3にパラメーターを置いたり、Pipelineの途中でLambdaで生成している – 環境名（dev/staging/prod）などを渡したい 48

Slide 49

Slide 49 text

Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 49

Slide 50

Slide 50 text

Canary Deploymentへの取り組み

Slide 51

Slide 51 text

Canary Deploymentへの取り組み • Canary Deploymentとは – 新バージョンを本番環境の一部にリリースし、少しずつトラフィックを流していくデプロイ手法 • 基本的にはBlue/Green Deploymentですが、一部でCanary Deploymentを導入して運用中 – 試験的な部分があるので、今後どうするかは未定 – 負荷を見るために実施しているのみで、A/Bテスト的なことはしていない – ALB（Target Group）の機能を使って実施 • 同じTarget Groupに複数のECS Serviceを登録すると、コンテナ数比に応じてトラフィックが分散される 51

Slide 52

Slide 52 text

カナリアリリース方式 52 ECS Cluster Target Group • ECSで新バージョンのImageを指定したServiceを起動 • 既存のTarget Groupに起動したServiceを追加 • ALBがコンテナ数比に応じて各 Serviceにリクエストを振り分ける ①Service起動 ②Target Groupへ追加

Slide 53

Slide 53 text

カナリアリリース時の重みづけ変更 53 v1.0.0 v2.0.0 バージョン毎のメトリクス送信 ①新バージョンのエラー率確認 ②問題なければタスク数変更 Target Group バージョン毎のエラー率を確認するために X-Rayを使用

Slide 54

Slide 54 text

という感じで作りましたが 54 Service mesh導入して、再設計していきたい気持ち

Slide 55

Slide 55 text

Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 55

Slide 56

Slide 56 text

継続的デリバリーについて

Slide 57

Slide 57 text

継続的デリバリーについて継続的デリバリーの活動では、継続的にデプロイしていくことになる 57

Slide 58

Slide 58 text

継続的デリバリーについて継続的デリバリーの活動では、継続的にデプロイしていくことになる 58

Slide 59

Slide 59 text

継続的デリバリーについて継続的デリバリーの活動では、継続的にデプロイしていくことになる 59 デプロイにはリスクも含まれる

Slide 60

Slide 60 text

継続的デリバリーについて • デプロイはリスクでもある – 実際にデプロイしてみないとわからないことは多々ある – 何が起きるかわからない 60

Slide 61

Slide 61 text

継続的デリバリーについて • デプロイはリスクでもある – 実際にデプロイしてみないとわからないことは多々ある – 何が起きるかわからない • 一方で、デプロイしなければサービスの価値は上がらない – ゆるやかな死 61

Slide 62

Slide 62 text

継続的デリバリーについて • デプロイはリスクでもある – 実際にデプロイしてみないとわからないことは多々ある – 何が起きるかわからない • 一方で、デプロイしなければサービスの価値は上がらない – ゆるやかな死 62 継続的デリバリー（デプロイ）を成立させるためには、どのようにリスク管理していくかが重要

Slide 63

Slide 63 text

リスク管理 • リスクの低減（どのようにリスクを減らしていくか） 63

Slide 64

Slide 64 text

リスク管理 • リスクの低減（どのようにリスクを減らしていくか） – 信頼できるテストを作る – デプロイ手法を工夫 • Blue/Green、Canary – 切り戻し対策 • バックアップなど 64

Slide 65

Slide 65 text

リスク管理 • リスクの低減（どのようにリスクを減らしていくか） – 信頼できるテストを作る – デプロイ手法を工夫 • Blue/Green、Canary – 切り戻し対策 • バックアップなど 65 リスクの低減は重要ではあるが、終わりがない

Slide 66

Slide 66 text

リスク管理 66 リスクの低減は重要ではあるが、終わりがない

Slide 67

Slide 67 text

リスク管理 67 リスクの低減は重要ではあるが、終わりがないリスクの可視化・数値化も同時に行う必要がある

Slide 68

Slide 68 text

リスク管理 68 リスクの低減は重要ではあるが、終わりがないリスクの可視化・数値化も同時に行う必要がある SLI/SLO エラーバジェット

Slide 69

Slide 69 text

SLI/SLO・エラーバジェット • SLI/SLO – Service Level Indicator (SLI) • サービスレベルを計測するための値例) HTTPリクエスト成功率 – Service Level Objects(SLO) • SLO = SLI + objective（目標）例) HTTPリクエスト成功率 > 99% • エラーバジェット – リスクとして許容可能な範囲を示す値 • SLOが99%であれば、1％はエラーを許容できる 1％＝エラーバジェット 69

Slide 70

Slide 70 text

Slide 71

Slide 71 text

SLI/SLOの定義と可視化 • SLI/SLOを定義することで、許容できるリスクが明確になる – SLOさえ維持していれば、デプロイし続けることができる – 逆に、SLOを維持できていない状況であればデプロイを止めることでリスク回避もできる • 継続的デリバリーを行う前に、SLI/SLOを定義しておくことは重要 – 継続的デリバリーも運用の一種だとみれば、運用の基本はモニタリング – システムのどういった状態が正常なのか定義しておくことが継続的デリバリーの第一歩 71

Slide 72

Slide 72 text

MetaチームでのSLI/SLO • 各システムについて、機能の重要度に応じてSLI/SLOを定義 • SLI/SLOダッシュボードを作成し、常時確認 • 定期的にSLI/SLO自体の見直しを実施 – SLI/SLOが正しくサービスの状態を表しているかは実際に運用してみないとわからない – サービスのアップデートによっても変化する 72 グラフの例

Slide 73

Slide 73 text

まとめ

Slide 74

Slide 74 text

まとめ • CodepipelineなどAWSサービスをガッツリ使ってパイプライン構築してます – CodepipelineをはじめとしたCode兄弟もアップデートを重ねてよくなってきている • 継続的デリバリーをやる際にはSLI/SLOの整備が重要 – リスク管理を行うことで健全な継続的デリバリーの運用ができる 74

Slide 75

Slide 75 text

今後やっていきたいこと

Slide 76

Slide 76 text

今後やっていきたいこと • クライアントも含めたCI/CD – Pipelineにクライアントアプリも含める形でリリースしたい • クライアントとの連結は別途テストを行っている • Service meshの導入 – App meshも出たのでアーキテクチャを再設計していきたい • アプリ作り直したい – それなりに歴史を重ねてきたのでレガシーな部分が多い 76

Slide 77

Slide 77 text

We are hiring!! 今書いたようなことやそれ以外も、一緒にやってくれる方、募集しています！（リンク先は会社名が異なりますが同じチームになります） https://www.careers.sony.co.jp/u/job.phtml?job_code=1240&job_category_code=111 77

Slide 78

Slide 78 text

ご清聴ありがとうございました 78