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

Transcript

1. 1 1 テレビ・レコーダーのバックエンドにおける CI/CDへの取り組み 2018/12/3 DevOps祭り ソニーネットワークコミュニケーションズ株式会社 佐藤瞬
2. 自己紹介 2 • 佐藤 瞬 • 所属 – ソニーネットワークコミュニケーションズ株式会社 Metaチーム • 経歴 – 2011-2016 SIとして受託開発 – 2016- 転職し、現在の会社へ • 過去のスライド – https://www.slideshare.net/tenbo07 – https://speakerdeck.com/tenbo07
3. Metaサービスについて
4. 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
5. BRAVIA 5
6. • Metaサービスから以下を配信 – 番組表 – 予約ランキング – リアルタイム視聴数 – 番組検索 – 番組詳細 – 人物詳細 – VoDコンテンツ検索 • YouTube、ニコニコ動画など – おすすめ番組 – ブックマーク機能 6 Video & TV Side View
7. 新作ドラマ・アニメガイド 7 新作ドラマ・アニメガイドの配信 – 次クールで始まる新ドラマ、新アニメの 番組リストを前月から配信 – 新番組を1か月前から一気に録画可能 – 録画忘れ、録画漏れの防止にも！
8. 全体構成
9. 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 ・ ・ ・ ・ ・ ・ ・ ・ ・
10. 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 ・ ・ ・ ・ ・ ・ ・ ・ ・ 主にこの部分の話
11. Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 11
12. Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 12
13. CI/CDパイプライン構築
14. Pipeline • MetaチームではCodePipelineを使ってPipelineを構築している • 現在、Dev/Staging/Prod合わせて40本程度のパイプラインが存在 – コンテナのDeploy Pipeline – EC2インスタンスのAMI更新Pipeline – ServerlessアプリケーションのデプロイPipeline 14
15. コンテナのDeploy Pipeline
16. コンテナの更新Pipeline パイプラインの流れ(Staging) 16 Commit 起動 Developer Build Staging Deploy Staging Test Staging Switch 新バージョンの起動 新バージョンのテスト 新バージョンへ切り替え Clean up 旧バージョンの停止 Docker Imageの作成
17. コンテナの更新Pipeline パイプラインの流れ(Prod) 17 Commit 起動 Developer Copy Image Prod Deploy Prod Test Prod Switch 新バージョンの起動 新バージョンのテスト 新バージョンへ切り替え Clean up 旧バージョンの停止 StagingのECRからDocker Imageのコピー Copy Staging Prod
18. コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 18 Target Group Client default.example.com Deploy前
19. コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 19 Target Group Target Group default.example.com Deploy時（新バージョンの起動） new.example.com 新バージョンにアクセスできる サブドメインを作成
20. コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 20 Target Group Target Group default.example.com Test new.example.com new.example.com
21. コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 21 Target Group Target Group Switch(新バージョンへ切り替え) Client default.example.com Listener Rule の切り替え
22. コンテナの更新Pipeline • Deploy～Clean Up – ECSとALBを使ったBlue/Greenデプロイ 22 Target Group Client default.example.com Clean Up
23. という感じで作ってましたが 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ですかね
24. EC2インスタンスのAMI更新Pipeline
25. EC2インスタンスのAMI更新Pipeline パイプラインの流れ(Staging) 25 Commit 起動 Developer Build Deploy Rolling Update Docker Imageの作成 AMI Instances Auto Scaling Update
26. EC2インスタンスのAMI更新Pipeline パイプラインの流れ(Prod) 26 Commit 起動 Developer Copy Deploy Rolling Update Docker Imageの作成 AMI Instances Auto Scaling Update AMI Staging Prod Copy
27. ServerlessアプリケーションのDeploy Pipeline
28. 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の 向き先を新バージョンへ変更
29. ServerlessアプリケーションのDeploy Pipeline • Deploy～Clean Up – SAMはLambdaのデプロイパッケージ作成とfunction作成のみ – Deploy部分は直接APIからの操作で作成 29 v1.0.0 Stage /api v1.0.0(alias) Custom Domain Deploy前
30. 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を作成
31. 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 テスト実行
32. 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
33. ServerlessアプリケーションのDeploy Pipeline • Deploy～Clean Up – SAMはLambdaのデプロイパッケージ作成とfunction作成のみ – Deploy部分は直接APIからの操作で作成 33 CleanUp Stage /api v2.0.0 v2.0.0(alias) Custom Domain
34. Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 34
35. CodePipelineの導入経緯
36. CodePipelineの導入経緯 36 CodePipelineの導入前、コード化されたPipelineは存在しなかった 各工程（Build/Testなど）はジョブ化されているものの デプロイフロー全体を俯瞰できる場所がなかった Runbook Build等の各ジョブ 実行
37. CodePipelineの導入経緯 37 CodePipelineの導入前、コード化されたPipelineは存在しなかった 各工程（Build/Testなど）はジョブ化されているものの デプロイフロー全体を俯瞰できる場所がなかった Runbook Build等の各ジョブ 実行
38. CodePipelineの導入経緯 38 Pipelineを作成する選択肢はいくつかある
39. CodePipelineの導入経緯 39 Pipelineを作成する選択肢はいくつかある なぜCodePipelineを選択したか
40. CodePipelineの導入経緯 • Jenkinsの除外 – Jenkins自体のブラックボックス化が進み管理が難しくなっていたので、 これ以上Jenkinsに役割を増やしたくない – 将来的にはBuild等もマネージドサービスに移管したい • Jenkins資産も活用したい – Pipelineの構築前、Build・Testなどの各ジョブはJenkinsで実行 – Jenkins環境に依存している部分が大きかったので、 まずはそのまま使ってPipelineを構築したかった • コスト管理 – CircleCIなど別サービスを使う場合は支払先が増える – CodePipelineであればAWSのコストが増えるだけでコスト管理が楽 40
41. CodePipelineを導入してみて
42. CodePipelineを導入してみて良かった点 • Sourceの柔軟性 – Github以外のSourceを指定できる • S3、ECRへのPut/Pushを起点にPipelineを起動できる – 複数のリポジトリをInputにできる • GithubとS3オブジェクトの両方をInputにすることができる 42 リポジトリA リポジトリB
43. CodePipelineを導入してみて良かった点 • AWSの他サービスとの連携 – CodeBuild / ECS / CloudFormation / Lambdaなど – 最初は便利だが、最終的にはCodeBuild やLambdaで APIを叩いていることが多い • DeployやBuildといった作業自体が繊細なものなので、 サービスやアプリケーションによって変えたいことが多いため – CodePipelineの利点ではあるが、他のCI/CDサービスと比較して 大きな優位性というわけではないと思う • API叩けば他でもできてしまうため 43
44. CodePipelineで困りごと 44
45. 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
46. 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 46 （一番ストレスだった部分が改善されてしまって、今あまり思いつかない）
47. CodePipelineで困りごと 現状ワークアラウンド的なことをしている部分 47
48. CodePipelineで困りごと 現状ワークアラウンド的なことをしている部分 • SourceでGit Tagを指定できない（Branchのみ） – JenkinsでTagを取ってきてZipで固めてS3へUploadし、 S3 TriggerでPipelineを起動している • リリースブランチを切るという選択もある • CodePipelineの実行時にパラメーター指定ができない – （そもそも、その運用が正しいかはありますが） – S3にパラメーターを置いたり、Pipelineの途中でLambdaで生成している – 環境名（dev/staging/prod）などを渡したい 48
49. Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 49
50. Canary Deploymentへの取り組み
51. Canary Deploymentへの取り組み • Canary Deploymentとは – 新バージョンを本番環境の一部にリリースし、少しずつトラフィックを流していく デプロイ手法 • 基本的にはBlue/Green Deploymentですが、 一部でCanary Deploymentを導入して運用中 – 試験的な部分があるので、今後どうするかは未定 – 負荷を見るために実施しているのみで、A/Bテスト的なことはしていない – ALB（Target Group）の機能を使って実施 • 同じTarget Groupに複数のECS Serviceを登録すると、 コンテナ数比に応じてトラフィックが分散される 51
52. カナリアリリース方式 52 ECS Cluster Target Group • ECSで新バージョンのImageを 指定したServiceを起動 • 既存のTarget Groupに起動 したServiceを追加 • ALBがコンテナ数比に応じて各 Serviceにリクエストを振り分け る ①Service起動 ②Target Groupへ追加
53. カナリアリリース時の重みづけ変更 53 v1.0.0 v2.0.0 バージョン毎のメトリクス送信 ①新バージョンのエラー率確認 ②問題なければタスク数変更 Target Group バージョン毎のエラー率を確認するために X-Rayを使用
54. という感じで作りましたが 54 Service mesh導入して、再設計していきたい気持ち
55. Agenda • CI/CD パイプライン構築 – Pipeline / Build /Test / Deployをどのように行っているか • CodePipelineの導入経緯と使い勝手 • Canary Deploymentへの取り組み • 継続的デリバリーについて • まとめ • 今後やっていきたいこと 55
56. 継続的デリバリーについて
57. 継続的デリバリーについて 継続的デリバリーの活動では、 継続的にデプロイしていくことになる 57
58. 継続的デリバリーについて 継続的デリバリーの活動では、 継続的にデプロイしていくことになる 58
59. 継続的デリバリーについて 継続的デリバリーの活動では、 継続的にデプロイしていくことになる 59 デプロイにはリスクも含まれる
60. 継続的デリバリーについて • デプロイはリスクでもある – 実際にデプロイしてみないとわからないことは多々ある – 何が起きるかわからない 60
61. 継続的デリバリーについて • デプロイはリスクでもある – 実際にデプロイしてみないとわからないことは多々ある – 何が起きるかわからない • 一方で、デプロイしなければサービスの価値は上がらない – ゆるやかな死 61
62. 継続的デリバリーについて • デプロイはリスクでもある – 実際にデプロイしてみないとわからないことは多々ある – 何が起きるかわからない • 一方で、デプロイしなければサービスの価値は上がらない – ゆるやかな死 62 継続的デリバリー（デプロイ）を成立させるためには、 どのようにリスク管理していくかが重要
63. リスク管理 • リスクの低減（どのようにリスクを減らしていくか） 63
64. リスク管理 • リスクの低減（どのようにリスクを減らしていくか） – 信頼できるテストを作る – デプロイ手法を工夫 • Blue/Green、Canary – 切り戻し対策 • バックアップなど 64
65. リスク管理 • リスクの低減（どのようにリスクを減らしていくか） – 信頼できるテストを作る – デプロイ手法を工夫 • Blue/Green、Canary – 切り戻し対策 • バックアップなど 65 リスクの低減は重要ではあるが、終わりがない
66. リスク管理 66 リスクの低減は重要ではあるが、終わりがない
67. リスク管理 67 リスクの低減は重要ではあるが、終わりがない リスクの可視化・数値化も同時に行う必要がある
68. リスク管理 68 リスクの低減は重要ではあるが、終わりがない リスクの可視化・数値化も同時に行う必要がある SLI/SLO エラーバジェット
69. SLI/SLO・エラーバジェット • SLI/SLO – Service Level Indicator (SLI) • サービスレベルを計測するための値 例) HTTPリクエスト成功率 – Service Level Objects(SLO) • SLO = SLI + objective（目標） 例) HTTPリクエスト成功率 > 99% • エラーバジェット – リスクとして許容可能な範囲を示す値 • SLOが99%であれば、1％はエラーを許容できる 1％ ＝ エラーバジェット 69
70. SLI/SLO・エラーバジェット • SLI/SLO – Service Level Indicator (SLI) • サービスレベルを計測するための値 例) HTTPリクエスト成功率 – Service Level Objects(SLO) • SLO = SLI + objective（目標） 例) HTTPリクエスト成功率 > 99% • エラーバジェット – リスクとして許容可能な範囲を示す値 • SLOが99%であれば、1％はエラーを許容できる 1％ ＝ エラーバジェット 70 エラーバジェットを満たしているかが、 デプロイに問題がないかの指標になる
71. SLI/SLOの定義と可視化 • SLI/SLOを定義することで、許容できるリスクが明確になる – SLOさえ維持していれば、デプロイし続けることができる – 逆に、SLOを維持できていない状況であればデプロイを止めることでリスク回避もできる • 継続的デリバリーを行う前に、SLI/SLOを定義しておくことは重要 – 継続的デリバリーも運用の一種だとみれば、運用の基本はモニタリング – システムのどういった状態が正常なのか定義しておくことが継続的デリバリーの第一歩 71
72. MetaチームでのSLI/SLO • 各システムについて、機能の重要度に応じてSLI/SLOを定義 • SLI/SLOダッシュボードを作成し、常時確認 • 定期的にSLI/SLO自体の見直しを実施 – SLI/SLOが正しくサービスの状態を表しているかは実際に運用してみないとわからない – サービスのアップデートによっても変化する 72 グラフの例
73. まとめ
74. まとめ • CodepipelineなどAWSサービスをガッツリ使ってパイプライン構築してます – CodepipelineをはじめとしたCode兄弟もアップデートを重ねてよくなってきている • 継続的デリバリーをやる際にはSLI/SLOの整備が重要 – リスク管理を行うことで健全な継続的デリバリーの運用ができる 74
75. 今後やっていきたいこと
76. 今後やっていきたいこと • クライアントも含めたCI/CD – Pipelineにクライアントアプリも含める形でリリースしたい • クライアントとの連結は別途テストを行っている • Service meshの導入 – App meshも出たのでアーキテクチャを再設計していきたい • アプリ作り直したい – それなりに歴史を重ねてきたのでレガシーな部分が多い 76
77. We are hiring!! 今書いたようなことやそれ以外も、 一緒にやってくれる方、募集しています！ （リンク先は会社名が異なりますが同じチームになります） https://www.careers.sony.co.jp/u/job.phtml?job_code=1240&job_category_code=111 77
78. ご清聴ありがとうございました 78