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
30
マルチクラウド・コンテナに最適化したリスクを最小化する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
14k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
260
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
91
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
2.3k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.3k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
220
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.2k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.2k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
5.2k
Other Decks in Technology
See All in Technology
New Relicを活用したSREの最初のステップ / NRUG OKINAWA VOL.3
isaoshimizu
3
650
アプリエンジニアのためのGraphQL入門.pdf
spycwolf
0
110
[CV勉強会@関東 ECCV2024 読み会] オンラインマッピング x トラッキング MapTracker: Tracking with Strided Memory Fusion for Consistent Vector HD Mapping (Chen+, ECCV24)
abemii
0
230
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
TanStack Routerに移行するのかい しないのかい、どっちなんだい! / Are you going to migrate to TanStack Router or not? Which one is it?
kaminashi
0
620
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
38
13k
"とにかくやってみる"で始めるAWS Security Hub
maimyyym
2
100
組織成長を加速させるオンボーディングの取り組み
sudoakiy
2
250
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
200
生成AIが変えるデータ分析の全体像
ishikawa_satoru
0
180
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
210
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
65
4.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
GraphQLとの向き合い方2022年版
quramy
43
13k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
A Philosophy of Restraint
colly
203
16k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Code Review Best Practice
trishagee
64
17k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
A Modern Web Designer's Workflow
chriscoyier
693
190k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
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つ隣の ブースにてお待ちして おります!
ご清聴ありがとうございました