Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチクラウド・コンテナに最適化したリスクを最小化するContinuous Delivery
Search
NAVITIME JAPAN
PRO
November 30, 2019
Technology
0
31
マルチクラウド・コンテナに最適化したリスクを最小化するContinuous Delivery
2019/11/30に開催された「Developers Boost 2019~U30エンジニアの登竜門~」にて発表した資料です。
NAVITIME JAPAN
PRO
November 30, 2019
Tweet
Share
More Decks by NAVITIME JAPAN
See All by NAVITIME JAPAN
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
22
15k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
430
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
160
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
2.5k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.4k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
270
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.3k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.3k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
5.3k
Other Decks in Technology
See All in Technology
ローカルLLMを活用したコード生成と、ローコード開発ツールへの応用
kazuhitoyokoi
0
130
Windows の新しい管理者保護モード
murachiakira
0
170
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
820
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
2
510
「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly
i35_267
1
510
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
370
なぜ私は自分が使わないサービスを作るのか? / Why would I create a service that I would not use?
aiandrox
0
870
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
65k
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
200
一度 Expo の採用を断念したけど、 再度 Expo の導入を検討している話
ichiki1023
1
230
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
250
「海外登壇」という 選択肢を与えるために 〜Gophers EX
logica0419
0
900
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Practical Orchestrator
shlominoach
186
10k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Documentation Writing (for coders)
carmenintech
67
4.6k
The Cult of Friendly URLs
andyhume
78
6.2k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Done Done
chrislema
182
16k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Site-Speed That Sticks
csswizardry
4
390
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Transcript
マルチクラウド・コンテナに 最適化したリスクを最小化する 株式会社ナビタイムジャパン 研究開発 インフラグループ 清水健司
自己紹介 清水 健司 • クラウド移行メインの インフラエンジニア • Docker/Kubernetes/Spinnaker • たまにJavaとGo
• AWS Re:Invent2019参加予定! • 筆圧強め
今日話す内容 デプロイパイプライン クラウド環境上にあるKubernetesに対して Spinnakerを使用して、リスクの低く安全なデプロイを実現させた話 ※ ビルド / 単体テストなど所謂CIの部分に関しては今回触れません Commit Stage
Automated Acceptance Test Manual Test Release
ナビタイムジャパンについて
ナビタイムジャパンのサービス概要 公共交通 ドライブ ツーリング 外国人&海外 トラベル & フィットネス PC /
SPブラウザ NAVITIME 乗換NAVITIME バスNAVITIME こみれぽ ドライブサポーター カーナビタイム トラックカーナビ ツーリングサポーター 自転車NAVITIME NAVITIME for Japan Travel NAVITIME Transit NAVITIME Travel ALKOO PLAT
ナビタイムジャパンのサービス概要 ビジネスナビタイム 動態管理ソリューション ビジネスナビタイム 交通費精算パッケージ 広告 / アライアンス オウンドメディア 交通コンサルティング
電鉄・バス事業者向け ソリューション API / SDK テレマティクスサービス
ナビタイムジャパンでのクラウド活用 メインとしてAWSを利用しつつ、 GCPやAlibabaでもサービスを展開 機械学習ではAzureをメインに使用している コンピューティングリソース 機械学習 ログ基盤
ナビタイムジャパンでの 活用 全てマネージドサービスを利用して Kuberntesクラスタを構築しています ※ コンテナ活用という意味ではAmazon ECSが多くの割合を占める コンピューティングリソース 機械学習 ログ基盤
Why Spinnaker?
きっかけ EKSが東京リージョンにやってまいりました! 全文検索エンジンのSolrをAmazon EC2の固定台数で運用しているんだけ ど、輻輳の抑制や運用コストの削減のためにオートスケーリングできるように ならないかな…? 社内でGKEでの構築事例もあるしEKS上に構築するか!
きっかけ EKSが東京リージョンにやってまいりました! 全文検索エンジンのSolrをAmazon EC2の固定台数で運用しているんだけ ど、輻輳の抑制や運用コストの削減のためにオートスケーリングできるように ならないかな…? 社内でGKEでの構築事例もあるしEKS上に構築するか! Kubernetesを使う上での デプロイフローも考え直すことに
ソフトウェアデリバリの原則 ソフトウェアをリリースするための、 反復可能で信頼できるプロセスを 作り上げよ − 第1章7節より • 全てを自動化すること • アプリケーションをビルド・デプロイ・テスト・リリースす
るのに必要なものを全てバージョン管理下に置くこと
全て自動化すること 全社的に利用されている Jenkins を使う? • 学習コストが少ない • 既存の環境で事足りるので新しくコストが発生することが無い 1
• マニフェストを取得して、kubectl applyするだけのジョブであれば 既に運用に載っているため検証が必要ない
全て自動化すること 高度なデプロイメント戦略 • Rolling Updateでは要件が満たせないことが存在 ◦ リスクの高いリリースを行ったときに直ぐに戻せない ◦ 新しいバージョンを出す前に本番と全く同じ環境で検証したいという 要望を満たせない
Jenkins 採用時の問題点①
全て自動化すること 運用のコスト • いくつもあるPJ毎に所有しているため、 各サーバで共通の処理を用意するのが難しい ◦ 構築自体は各PJで行う ◦ 利用するPJが増えるたびに権限設定が必要になる ◦
pythonのライブラリが更新されてクラウド操作用のCLIが 動かなくなったり… Jenkins 採用時の問題点②
全て自動化すること ツールを増やすことを恐れるな 成熟した環境では汎用的なツールと専門的な ツールを組み合わせよ Kubernetesへのデプロイ専門のツールを採用 Kubernetesのエコシステムを成熟してきており デプロイのためのツールもたくさん出てきている NAVITIMEに必要な要素はなんだろう…?
全て自動化すること 必要なこと • クラウドプロバイダの違いが抽象化されていること(= マ ルチクラウドへのデプロイ可能) • B to B
事業もあるため Continuous Deployment で 共通化するのは難しい • 豊富なデプロイメント戦略が取れること • Helmを使用しない(Kustomizeで差分吸収する)
全て自動化すること 選ばれたのはSpinnakerでした Kubernetes V2 Provider (Manifest Based) が BetaからGAになったのも大きいです NETFLIXが公開したCDに特化したツール
必要なものをすべてバージョン管理下に置く Single Source of Truthは可能? • SpinnakerのパイプラインはJsonで吐ける + k8sリソースはyamlで宣言できる 実現において必要とされるテンプレートエンジン
• 2019年9月のリリースまでKustomizeサポートが 無かったため検証/本番で完全にファイルが別に
必要なものをすべてバージョン管理下に置く Spinnakerパイプラインの管理 • Jsonを直接作成/改修するのは辛い CloudFormationの比ではない • 運用フロー ◦ 検証環境はGUIでパイプラインを作成・編集 ◦
CLI(spin)を使用してJSONを取得してソースリポジトリに保存 ◦ パイプラインをリポジトリから取得し、CLI(spin)から本番環境へパイプ ラインを登録
How to Use it?
2つの事例 本番環境に対してSpinnakerを使用してデプロイを 行っているものを2つ取り上げます • 全文検索エンジンSolr • BtoBのオウンドメディア(Java製Webアプリ) どちらもBlue/Greenデプロイがベースにあり それぞれの要件に合わせてパイプラインに処理が加わる
我々の知る限りで最も強力なリリース管理である 本番環境としてまったく同じ環境を2組用意する それぞれをブルーおよびグリーンと呼ぶ 新しいバージョンを公開するのはルータ設定の更新のみとなる 公開するまでの作業はもう一つの環境に影響しない
での 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がかかってしまう
での 考えられるデプロイの実行フロー DeployのStageはデフォルトで通信が流れるようになってるため、このま まだと新バージョンはデプロイ直後に通信が流れてしまう ※ Enable :指定したリソースにTrafficが流れるようにする Disable: 指定したリソースにTrafficを流さないようにする 新バージョンの
デプロイ (新バージョンに 対する処理) 新バージョンを Enableする 旧バージョンを Disableする
での 実際に有効なデプロイの実行フロー Podのreplica数を0で宣言したマニフェストでデプロイ その後にTrafficが流さないようにDisableを行ってから数を増やす Pod数が0で 新バージョンの デプロイ (新バージョンに 対する処理) 新バージョンを
enableする 旧バージョンを disableする 新バージョンへ Trafficを流さない Pod数を増加
全文検索エンジン での α Warming Up Query JobリソースとHeadless Serviceを組み合わせることで 新バージョンに均等にリクエストを送信した後に切替 Job
Pod Container Headless Service Pod Pod Pod ラウンドロビン
アプリでの α Manual Test 本番環境の新バージョンに対してテストを行う 結果によってManual Judegmentを行いデプロイを 継続するかRollbackするかを決める Test Service
に付与される を利用して を新しいバー ジョンのみに向ける new-version Pod Client
まとめ・今後の展望
• SolrをKubernetes基盤に移行 + Spinnakerの構成を 取ることで運用が楽に ◦ 今までと振る舞いを大きく変えることなく、オートスケーリングが出来るよ うになった ◦ 構築が簡単になったことで、Solrを扱うチームやインフラの負荷が減りま
した • デプロイをSpinnakerに集中させることで、 実行環境が統一された まとめ
• パイプラインテンプレート使って保守性を高めたい • より安全なロールバックを行いたい ◦ ソースリポジトリがサービス不全になった際に障害となった ◦ デプロイに必要な条件などを厳しく監視する • 社内でのSpinnaker布教
◦ プロダクトを知り尽くしている開発者の方がパイプラインを改善できる状 態に持っていく 今後の展望
ブースにて抽選会やってます ハズレ無しの抽選会 やってます! もし良かったらどうぞ!! 書籍販売の2つ隣の ブースにてお待ちして おります!
ご清聴ありがとうございました