マルチクラウド・コンテナに最適化したリスクを最小化するContinuous Delivery

2019/11/30に開催された「Developers Boost 2019～U30エンジニアの登竜門～」にて発表した資料です。

Transcript

1. マルチクラウド・コンテナに 最適化したリスクを最小化する 株式会社ナビタイムジャパン 研究開発 インフラグループ 　清水健司
2. 自己紹介 清水 健司 • クラウド移行メインの インフラエンジニア • Docker/Kubernetes/Spinnaker • たまにJavaとGo • AWS Re:Invent2019参加予定！ • 筆圧強め
3. 今日話す内容 デプロイパイプライン クラウド環境上にあるKubernetesに対して Spinnakerを使用して、リスクの低く安全なデプロイを実現させた話 ※ ビルド / 単体テストなど所謂CIの部分に関しては今回触れません Commit Stage Automated Acceptance Test Manual Test Release
4. ナビタイムジャパンについて
5. ナビタイムジャパンのサービス概要 公共交通 ドライブ ツーリング 外国人＆海外 トラベル ＆ フィットネス PC / SPブラウザ NAVITIME 乗換NAVITIME バスNAVITIME こみれぽ ドライブサポーター カーナビタイム トラックカーナビ ツーリングサポーター 自転車NAVITIME NAVITIME for Japan Travel NAVITIME Transit NAVITIME Travel ALKOO PLAT
6. ナビタイムジャパンのサービス概要 ビジネスナビタイム 動態管理ソリューション ビジネスナビタイム 交通費精算パッケージ 広告 / アライアンス オウンドメディア 交通コンサルティング 電鉄・バス事業者向け ソリューション API / SDK テレマティクスサービス
7. ナビタイムジャパンでのクラウド活用 メインとしてAWSを利用しつつ、 GCPやAlibabaでもサービスを展開 機械学習ではAzureをメインに使用している コンピューティングリソース 機械学習 ログ基盤
8. ナビタイムジャパンでの 活用 全てマネージドサービスを利用して Kuberntesクラスタを構築しています ※ コンテナ活用という意味ではAmazon ECSが多くの割合を占める コンピューティングリソース 機械学習 ログ基盤
9. Why Spinnaker?
10. きっかけ EKSが東京リージョンにやってまいりました！ 全文検索エンジンのSolrをAmazon EC2の固定台数で運用しているんだけ ど、輻輳の抑制や運用コストの削減のためにオートスケーリングできるように ならないかな…？ 社内でGKEでの構築事例もあるしEKS上に構築するか！
11. きっかけ EKSが東京リージョンにやってまいりました！ 全文検索エンジンのSolrをAmazon EC2の固定台数で運用しているんだけ ど、輻輳の抑制や運用コストの削減のためにオートスケーリングできるように ならないかな…？ 社内でGKEでの構築事例もあるしEKS上に構築するか！ Kubernetesを使う上での デプロイフローも考え直すことに
12. ソフトウェアデリバリの原則 ソフトウェアをリリースするための、 反復可能で信頼できるプロセスを 作り上げよ 　　　　　　　　　　− 第1章7節より　　　　　　　 • 全てを自動化すること • アプリケーションをビルド・デプロイ・テスト・リリースす るのに必要なものを全てバージョン管理下に置くこと　　　　　
13. 全て自動化すること 全社的に利用されている Jenkins 　 を使う？ • 学習コストが少ない • 既存の環境で事足りるので新しくコストが発生することが無い 1 • マニフェストを取得して、kubectl applyするだけのジョブであれば 既に運用に載っているため検証が必要ない
14. 全て自動化すること 高度なデプロイメント戦略 • Rolling Updateでは要件が満たせないことが存在 ◦ リスクの高いリリースを行ったときに直ぐに戻せない ◦ 新しいバージョンを出す前に本番と全く同じ環境で検証したいという 要望を満たせない Jenkins　 採用時の問題点①
15. 全て自動化すること 運用のコスト • いくつもあるPJ毎に所有しているため、 各サーバで共通の処理を用意するのが難しい ◦ 構築自体は各PJで行う ◦ 利用するPJが増えるたびに権限設定が必要になる ◦ pythonのライブラリが更新されてクラウド操作用のCLIが 動かなくなったり… Jenkins　 採用時の問題点②
16. 全て自動化すること ツールを増やすことを恐れるな 成熟した環境では汎用的なツールと専門的な ツールを組み合わせよ Kubernetesへのデプロイ専門のツールを採用 Kubernetesのエコシステムを成熟してきており デプロイのためのツールもたくさん出てきている NAVITIMEに必要な要素はなんだろう…？ 　　
17. 全て自動化すること 必要なこと • クラウドプロバイダの違いが抽象化されていること（＝ マ ルチクラウドへのデプロイ可能） • B to B 事業もあるため Continuous Deployment で 共通化するのは難しい • 豊富なデプロイメント戦略が取れること • Helmを使用しない（Kustomizeで差分吸収する） 　　
18. 全て自動化すること 選ばれたのはSpinnakerでした Kubernetes V2 Provider (Manifest Based) が BetaからGAになったのも大きいです NETFLIXが公開したCDに特化したツール
19. 必要なものをすべてバージョン管理下に置く Single Source of Truthは可能？ • SpinnakerのパイプラインはJsonで吐ける + k8sリソースはyamlで宣言できる 実現において必要とされるテンプレートエンジン • 2019年9月のリリースまでKustomizeサポートが 無かったため検証/本番で完全にファイルが別に
20. 必要なものをすべてバージョン管理下に置く Spinnakerパイプラインの管理 • Jsonを直接作成/改修するのは辛い CloudFormationの比ではない • 運用フロー ◦ 検証環境はGUIでパイプラインを作成・編集 ◦ CLI（spin）を使用してJSONを取得してソースリポジトリに保存 ◦ パイプラインをリポジトリから取得し、CLI（spin）から本番環境へパイプ ラインを登録
21. How to Use it?
22. ２つの事例 本番環境に対してSpinnakerを使用してデプロイを 行っているものを2つ取り上げます • 全文検索エンジンSolr • BtoBのオウンドメディア（Java製Webアプリ） どちらもBlue/Greenデプロイがベースにあり それぞれの要件に合わせてパイプラインに処理が加わる
23. 我々の知る限りで最も強力なリリース管理である 　本番環境としてまったく同じ環境を2組用意する 　それぞれをブルーおよびグリーンと呼ぶ 　新しいバージョンを公開するのはルータ設定の更新のみとなる 　公開するまでの作業はもう一つの環境に影響しない
24. での Podの管理にはReplicasetリソースを使うことになる ※ Deploymentリソースは使えません😢 Deployment Replicaset-1 Replicaset-2 Pod Container Pod Container kind: Deployment metadata: name: sample-deployment spec: template: metadata: labels: app: sample-app ココを書き換えることによって ルーティングを変えている Deploymentリソースだと RollingUpdateがかかってしまう
25. での 考えられるデプロイの実行フロー DeployのStageはデフォルトで通信が流れるようになってるため、このま まだと新バージョンはデプロイ直後に通信が流れてしまう ※ Enable ：指定したリソースにTrafficが流れるようにする 　　Disable： 指定したリソースにTrafficを流さないようにする 新バージョンの デプロイ （新バージョンに 対する処理） 新バージョンを Enableする 旧バージョンを Disableする
26. での 実際に有効なデプロイの実行フロー Podのreplica数を0で宣言したマニフェストでデプロイ その後にTrafficが流さないようにDisableを行ってから数を増やす Pod数が0で 新バージョンの デプロイ （新バージョンに 対する処理） 新バージョンを enableする 旧バージョンを disableする 新バージョンへ Trafficを流さない Pod数を増加
27. 全文検索エンジン での α Warming Up Query JobリソースとHeadless Serviceを組み合わせることで 新バージョンに均等にリクエストを送信した後に切替 Job Pod Container Headless Service Pod Pod Pod ラウンドロビン
28. アプリでの α Manual Test 本番環境の新バージョンに対してテストを行う 結果によってManual Judegmentを行いデプロイを 継続するかRollbackするかを決める Test Service に付与される を利用して を新しいバー ジョンのみに向ける new-version Pod Client
29. まとめ・今後の展望
30. • SolrをKubernetes基盤に移行 + Spinnakerの構成を 取ることで運用が楽に ◦ 今までと振る舞いを大きく変えることなく、オートスケーリングが出来るよ うになった ◦ 構築が簡単になったことで、Solrを扱うチームやインフラの負荷が減りま した • デプロイをSpinnakerに集中させることで、 実行環境が統一された まとめ
31. • パイプラインテンプレート使って保守性を高めたい • より安全なロールバックを行いたい ◦ ソースリポジトリがサービス不全になった際に障害となった ◦ デプロイに必要な条件などを厳しく監視する • 社内でのSpinnaker布教 ◦ プロダクトを知り尽くしている開発者の方がパイプラインを改善できる状 態に持っていく 今後の展望
32. ブースにて抽選会やってます ハズレ無しの抽選会 やってます！ もし良かったらどうぞ！！ 書籍販売の２つ隣の ブースにてお待ちして おります！
33. ご清聴ありがとうございました