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
34
マルチクラウド・コンテナに最適化したリスクを最小化する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
23
15k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
780
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
240
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
3k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.6k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
370
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.6k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.3k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
5.7k
Other Decks in Technology
See All in Technology
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
43k
能登半島地震で見えた災害対応の課題と組織変革の重要性
ditccsugii
0
990
Railsの話をしよう
yahonda
0
160
新規事業におけるGORM+SQLx併用アーキテクチャ
hacomono
PRO
0
320
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
190
Node.js 2025: What's new and what's next
ruyadorno
0
360
Findy Team+ QAチーム これからのチャレンジ!
findy_eventslides
0
380
incident_commander_demaecan__1_.pdf
demaecan
0
150
プロダクトのコードから見るGoによるデザインパターンの実践 #go_night_talk
bengo4com
1
2.6k
ビズリーチ求職者検索におけるPLMとLLMの活用 / Search Engineering MEET UP_2-1
visional_engineering_and_design
1
140
AI Agent Dojo #2 watsonx Orchestrateフローの作成
oniak3ibm
PRO
0
120
React19.2のuseEffectEventを追う
maguroalternative
0
370
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1371
200k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Done Done
chrislema
185
16k
KATA
mclloyd
32
15k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
33
2.3k
Gamification - CAS2011
davidbonilla
81
5.5k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How to train your dragon (web standard)
notwaldorf
97
6.3k
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つ隣の ブースにてお待ちして おります!
ご清聴ありがとうございました