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
頑張らないKubernetes/ Real World Kubernetes
Search
Shinichi Morimoto
December 18, 2018
Technology
4
2k
頑張らないKubernetes/ Real World Kubernetes
Shinichi Morimoto
December 18, 2018
Tweet
Share
More Decks by Shinichi Morimoto
See All by Shinichi Morimoto
Actor Model meets the Kubernetes - CNDT 2019
shnmorimoto
6
5k
AdTech on Azure - Cosmos DBを利用した配信システムの全て -
shnmorimoto
2
2.5k
Akka Cluster 超入門 - 2019 Fringe81 大新年勉強会
shnmorimoto
1
370
circeから学ぶ GenericProgramming入門 - Scala関西Summit 2018
shnmorimoto
4
3.4k
Other Decks in Technology
See All in Technology
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.7k
BLADE: An Attempt to Automate Penetration Testing Using Autonomous AI Agents
bbrbbq
0
320
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
180
Zennのパフォーマンスモニタリングでやっていること
ryosukeigarashi
0
150
日経電子版のStoreKit2フルリニューアル
shimastripe
1
140
TanStack Routerに移行するのかい しないのかい、どっちなんだい! / Are you going to migrate to TanStack Router or not? Which one is it?
kaminashi
0
600
Lambda10周年!Lambdaは何をもたらしたか
smt7174
2
110
プロダクト活用度で見えた真実 ホリゾンタルSaaSでの顧客解像度の高め方
tadaken3
0
180
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
AI前提のサービス運用ってなんだろう?
ryuichi1208
8
1.4k
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
Happy Clients
brianwarren
98
6.7k
For a Future-Friendly Web
brad_frost
175
9.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
The Cult of Friendly URLs
andyhume
78
6k
The Invisible Side of Design
smashingmag
298
50k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Making Projects Easy
brettharned
115
5.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Transcript
頑張らない 株式会社 技術開発本部 森本 真一
Fringe81 • 六本木の会社 • Ad Tech系/HR Tech系の領域で様々なサー ビスを展開 ◦ Ad
Tech系: docomo Ad Network, GrowLio, etc ◦ HR Tech系: Unipos • 絶賛エンジニア募集中
Unipos • • ピアボーナスサービス ◦ 組織風土の変革 ◦ 従業員エンゲージメントの向上 ◦ 若手・中間マネジメント層の育成
https://unipos.me/ja/
GrowLio • • アプリメディア向け広告サービス ◦ 広告配信プラットフォームの開発~保守 運用まで含めた支援 ◦ ナショナルクライアントを含む広告主や広 告代理店への営業活動支援
◦ 広告事業全般に関するオペレーション支 援
今日お話しすること 新規プロダクト(GrowLio)にてKubernetesを導入した経験を元に • 導入した背景・経緯 • 構成詳細 • 導入した結果/感想
導入した背景・経緯
導入した背景 • これまで経験した辛みを解消したい => 過去の経験を活かす的ななにかカッコいい言葉をイメージしてください • 新規プロダクト開発なので、積極的に新技術を導入したい => 未来を見据えて的ななにかカッコいい言葉をイメージしてください
Kubernetes採用前(過去のプロダクトの構成) インスタンス/VM docker Web Server • デプロイが大変 ◦ 手順書に沿って、手動でデプロイ ◦
オレオレ deploy shell scripts • リソースマネージメントが大変 ◦ 手動でスケールアップ or スケールア ウト • 障害時の対応が大変 ◦ 手動で復旧 App Server other インスタ ンス/VM docker C C C 同一セット …
Kubernetes採用後(イメージ) インスタンス /VM Kubernetes Web Server • デプロイが大変 => YAML適用のみ
=> ローリングデプロイも可能 • リソースマネージメントが大変 => Podのオートスケール • 障害時の対応が大変 => 落ちても自動でPodが復旧する App Server other インスタンス /VM インスタンス /VM 同一 Pod
Kubernetes採用に関しての障壁 • Kubernetesの知見がない ◦ ほぼアプリケーションエンジニア ◦ 全員k8s実運用経験なし! • 対象とするシステムがシビア ◦
後述
Kubernetes採用に関しての障壁 • Kubernetesの知見がない ◦ ほぼアプリケーションエンジニア ◦ 全員k8s実運用経験なし! • 対象とするシステムがシビア ◦
後述 障害が起きたときに 対応できるか 不安 k8sにのせて、パ フォーマンス要求を 満たせるだろうか? 不安
ざっくり配信プラットフォームの構成 広告配信システム 入稿管理システム 各種バッチ ユーザー 広告主
ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ(レスポンスがもの凄く速い 数十 ) ◦
ミッションクリティカル(落ちると非常にまずい) • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面
ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ(レスポンスがもの凄く速い 数十 ) ◦
ミッションクリティカル(落ちると非常にまずい) • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面 停止した際の影響度 少し大変 非常に大変!!
ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ(レスポンスがもの凄く速い 数十 ) ◦
ミッションクリティカル(落ちると非常にまずい) • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面 停止した際の影響度 少し大変 非常に大変!! k8sで稼働できそう
Kubernetes採用に関しての障壁 => 導入 • Kubernetesの知見がない ◦ 影響がないシステムから導入する ◦ 最悪落ちた際のリカバリ手段を用意 =>
docker on インスタンス(過去の構成)で動かせる用に準備しておく ◦ 運用を通して知見をためる • 対象とするシステムがシビア ◦ パフォーマンス要求が厳しいものについては、k8sにのせない ◦ 知見が貯まった際に再度検討
Kubernetes採用に関しての障壁 => 導入 • Kubernetesの知見がない ◦ 影響がないシステムから導入する ◦ 最悪落ちた際のリカバリ手段を用意 =>
docker on インスタンス(過去の構成)で動かせる用に準備しておく ◦ 運用を通して知見をためる • 対象とするシステムがシビア ◦ 要求が厳しいものについては、k8sにのせない ◦ 知見が貯まった際に再度検討 影響が低いシステム リカバリ手段 自信を持って運用 運用力がLv Upしたら再度挑戦!
構成詳細
システム構成詳細
システム構成詳細
Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob
Batch Namespace Daemon Set Data Dog
Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob
Batch • Kubernetes ◦ 運用負荷を下げる為にマネージド・ サービスを利用 ◦ 基盤としてAzureを利用していたので、 AKSを採用 ◦ 2018年6月末にGA ▪ 開発期間が5月〜7月だったので ギリギリGA間にあった Namespace Daemon Set Data Dog
Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob
Batch Namespace Daemon Set Data Dog • AKS(Azure Kubernetes Service ) ◦ マスターノードを管理 ◦ クラスタのアップグレード機能 ◦ クラスタのスケール機能 ◦ マスターノードには課金されない ▪ 懐に優しい ◦ Azure Kubernetes Service (AKS) virtual nodeでより便利に?
Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob
Batch Namespace Daemon Set Data Dog • Namespaces ◦ Prd環境・Stg環境のクラスタを分けてい る ◦ サービス毎に依存関係はないので、 Namespaceはサービス毎に切っている
Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob
Batch Namespace Daemon Set Data Dog • Deployment ◦ 入稿管理画面サービスはDeployment で管理 ◦ PodのReplica数の管理 ◦ ローリングアップデート ◦ オートヒーリングの実現
Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob
Batch Namespace Daemon Set Data Dog • CronJob ◦ バッチ系については、CronJobで管理 ◦ 定期的にバッチを実行
Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob
Batch Namespace Daemon Set Data Dog • Daemon Set ◦ 監視にはDatadogを利用 ◦ Datadogの課金体系から、ノード毎に1 つ用意したい ◦ ノード毎にdeployしたいので、Daemon Setを利用
マニフェスト管理(YAML管理) Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog
Batch
マニフェスト管理(YAML管理) Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog
Batch • Kubernetes クラスタ ◦ 本番環境 ◦ ステージング環境 ◦ 開発環境(各自のローカルPC) ◦ 3環境のKubernetesクラスタ
マニフェスト管理(YAML管理) Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog
Batch • 稼働サービス(コンテナ) ◦ Webサーバ ◦ アプリケーション(管理画面) ◦ バッチ ◦ 監視(Datadog) ◦ 4種類
マニフェスト管理(YAML管理) Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog
Batch • 管理しなければならないYAML(という か設定内容) ◦ 環境 × 稼働サービス数 ◦ 要するに一杯 ◦ 各環境に共通する項目は共通化し、差 分のみを効率良く管理したい
マニフェスト管理(YAML管理) • kustomize ◦ YAML管理ツール ◦ 将来的にはkubectlに統合予定 ◦ resource毎にYAMLを別管理できる 公式サイトより(https://github.com/kubernetes-sigs/kustomize)
マニフェスト管理(YAML管理) • kustomize ◦ overlayにより、複数の環境を別YAML に切り出すことができる ◦ 共通項目をbaseに定義し、差分部分 (本番環境、ステージング環境)を別 YAMLファイルに切り出す等
公式サイトより(https://github.com/kubernetes-sigs/kustomize)
監視(Datadog) • Datadog ◦ 監視はDatadogに全ておまかせ ◦ SaaSなので、すぐに利用可能 ◦ プラグインが豊富にある(Kubernetes 用のもあり)
◦ 社内がマルチクラウド(AWS, GCP, Azure)なので、監視系はクラウドベン ダーにロックインされたくない 公式ドキュメントより (https://www.datadoghq.com/ja/blog/monitoring-kubernetes-data dog/)
監視(Datadog) • Datadog ◦ 標準でKubernetesのテンプレートが存 在 ◦ 直ぐにDashboardを構築可能 ◦ Nodeの状態
◦ Podの状態 ◦ etc...
Kubernetes構成まとめ • 構成自体はシンプル ◦ Deployment、 CronJob、DaemonSetをそれぞれの役割にマッチした用途で利用 • マニフェスト管理もシンプル ◦ kustomizeで適切に環境毎のYAMLを管理
◦ 本当に必要になるまで、Helm等は入れない • 監視もシンプル ◦ Datadog(SaaS)を利用することにより、監視システムの構築工数を削減 ◦ インターフェースも分かりやすいので、キャッチアップも楽
Kubernetes構成まとめ • シンプル、分かりやすい構成からスタート => 知見がなくても、運用できそうな 攻めない!程良い構成とする => ステートレスな機能のみを利用 • マネージド
+ SaaSを活用 => マネージドでk8s自体の管理をお任せ => SaaSで知見がなくても、プリセットを利用して、必要最低限の監視は可能
導入した結果/感想
Kubernetesを導入した効果 • リリースサイクルの向上 ◦ deployが1 コマンドで可能なので、deployの準備に手間がかからない ◦ deployが簡単なので、deployに対する心理的障壁も下がる ◦ 初回リリース(9月初旬)から現在(12月中頃)までのリリース回数は30
弱回 ◦ スプリントが1週間なので、ほぼスプリント毎にリリースしている
Kubernetesを導入した効果 • リリース時間の短縮 ◦ 1 コマンドでdeployできるので、deployが数分で完了 ◦ リリース時間が短縮できるので、日々のスプリントに対する開発時間へ の影響も抑えられる ◦
手作業がないので、オペミスがほぼ起こらない
Kubernetesを導入した効果 • リリースメンバーの属人化が防げる ◦ deployが簡単なので、アプリケーションエンジニアでもできる ◦ Kubernetesに関する深い知識がなくてもdeploy可能 ◦ ローテでチームメンバー全員がリリース可能
Kubernetesを導入した効果 リリースがとても速く楽になった!
Kubernetes(というかAKS)を導入した効果 番外編 • 深刻な脆弱性が発見される ◦ 2018/12/4発表 ◦ 深刻度は9.8(最大10) ◦ 権限昇格の脆弱性
◦ 任意のユーザがノード及びポッドを自 由に操作できる Github Kubernetes Repoより (https://github.com/kubernetes/kubernetes/issues/71411)
Kubernetes(というかAKS)を導入した効果 番外編 • 簡単にアップデート ◦ Azure Consoleよりアップデート ◦ 所要時間数分 ◦
特にサービスダウンなく、アップデート 完了 ◦ 脆弱性情報を知ってから、その日の内 に対応完了
Kubernetesを導入した効果 番外編 • ポータビリティ性の良さを実感 ◦ 開発時、本番環境(AKS)でのみ、アプリケーションが正常に動作しない事象が発生 ◦ ローカルでは問題なく動く ◦ 切り分けの為、別のマネージドKubernetes環境で検証した際に再現
◦ アプリケーション側での問題だと分かり、速やかに原因特定できた ◦ 同じマニフェストファイルを適用するだけで、他のKubernetes環境でも動作する ◦ 他の環境に持っていくのに、ほぼノーコストですみ、ポータビリティの良さを実感
Kubernetes(AKS)を3ヶ月近く運用した感想 • 思っていたより、問題起きない ◦ とても安定している ◦ この3ヶ月、困った事象は特に発生しなかった • メンバーへのスキルトランスファーもスムーズに行えた ◦
ハンズオン形式のチーム内勉強会を2回程実施 ◦ 後はリリース作業を通して、実地で学ぶ • オートヒーリングは便利 ◦ Podが落ちたことがあったが、自動的に復旧してくれるので、やはり便利
今後の展望 • 配信系システムの移行検討 ◦ 配信系のシステムもリリース及びリソース管理が大変なので、Kubernetesへ移行したい • パフォーマンス検討 ◦ 配信系ではレイテンシが問題になるので、パフォーマンスに影響がないか検証が必要 •
カナリアリリース ◦ 現状、一括でアップデートしているので、カナリアリリースで問題がないことを確認したの ち、順次リリースするようにしたい
まとめ • 影響度の低いシステムから導入する • シンプルな構成を保つ • マネージド・SaaSを利用する • Kubernetesの基本的な機能のみでも導入するメリットは多数ある
まとめ • 影響度の低いシステムから導入する • シンプルな構成を保つ • マネージド・SaaSを利用する • Kubernetesの基本的な機能のみでも導入するメリットは多数ある 頑張らなくてもKubernetesは導入できる
弊社採用ページ https://hrmos.co/pages/fringe81/jobs/0000037 • 絶賛エンジニア募集中 ◦ AWS/GCP/Azure ◦ Kubernetes ◦ AdTech/HR
Tech/SaaS ◦ Scala/Go/Elm/TypeScript お約束の広告(We’re Hiring!)