頑張らないKubernetes/ Real World Kubernetes

Transcript

1. 頑張らない 株式会社 技術開発本部 森本　真一
2. Fringe81 • 六本木の会社 • Ad Tech系/HR Tech系の領域で様々なサー ビスを展開 ◦ Ad Tech系: docomo Ad Network, GrowLio, etc ◦ HR Tech系: Unipos • 絶賛エンジニア募集中
3. Unipos • • ピアボーナスサービス ◦ 組織風土の変革 ◦ 従業員エンゲージメントの向上 ◦ 若手・中間マネジメント層の育成 https://unipos.me/ja/
4. GrowLio • • アプリメディア向け広告サービス ◦ 広告配信プラットフォームの開発～保守 運用まで含めた支援 ◦ ナショナルクライアントを含む広告主や広 告代理店への営業活動支援 ◦ 広告事業全般に関するオペレーション支 援
5. 今日お話しすること 新規プロダクト（GrowLio）にてKubernetesを導入した経験を元に • 導入した背景・経緯 • 構成詳細 • 導入した結果/感想
6. 導入した背景・経緯
7. 導入した背景 • これまで経験した辛みを解消したい => 過去の経験を活かす的ななにかカッコいい言葉をイメージしてください • 新規プロダクト開発なので、積極的に新技術を導入したい => 未来を見据えて的ななにかカッコいい言葉をイメージしてください
8. Kubernetes採用前（過去のプロダクトの構成） インスタンス/VM docker Web Server • デプロイが大変 ◦ 手順書に沿って、手動でデプロイ ◦ オレオレ deploy shell scripts • リソースマネージメントが大変 ◦ 手動でスケールアップ or スケールア ウト • 障害時の対応が大変 ◦ 手動で復旧 App Server other インスタ ンス/VM docker C C C 同一セット …
9. Kubernetes採用後（イメージ） インスタンス /VM Kubernetes Web Server • デプロイが大変 => YAML適用のみ => ローリングデプロイも可能 • リソースマネージメントが大変 => Podのオートスケール • 障害時の対応が大変 => 落ちても自動でPodが復旧する App Server other インスタンス /VM インスタンス /VM 同一 Pod
10. Kubernetes採用に関しての障壁 • Kubernetesの知見がない ◦ ほぼアプリケーションエンジニア ◦ 全員k8s実運用経験なし！ • 対象とするシステムがシビア ◦ 後述
11. Kubernetes採用に関しての障壁 • Kubernetesの知見がない ◦ ほぼアプリケーションエンジニア ◦ 全員k8s実運用経験なし！ • 対象とするシステムがシビア ◦ 後述 障害が起きたときに 対応できるか 不安 k8sにのせて、パ フォーマンス要求を 満たせるだろうか？ 不安
12. ざっくり配信プラットフォームの構成 広告配信システム 入稿管理システム 各種バッチ ユーザー 広告主
13. ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ（レスポンスがもの凄く速い 数十 ） ◦ ミッションクリティカル（落ちると非常にまずい） • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面
14. ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ（レスポンスがもの凄く速い 数十 ） ◦ ミッションクリティカル（落ちると非常にまずい） • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面 停止した際の影響度 少し大変 非常に大変！！
15. ざっくり配信プラットフォームの構成 • 広告配信システム ◦ 広告を配信する ◦ 低レイテンシ（レスポンスがもの凄く速い 数十 ） ◦ ミッションクリティカル（落ちると非常にまずい） • 各種バッチ ◦ 配信した結果を集計するバッチ等 ◦ の単位で実行されるバッチ • 入稿管理システム ◦ 広告を入稿するシステム ◦ 管理画面 停止した際の影響度 少し大変 非常に大変！！ k8sで稼働できそう
16. Kubernetes採用に関しての障壁 => 導入 • Kubernetesの知見がない ◦ 影響がないシステムから導入する ◦ 最悪落ちた際のリカバリ手段を用意 => docker on インスタンス（過去の構成）で動かせる用に準備しておく ◦ 運用を通して知見をためる • 対象とするシステムがシビア ◦ パフォーマンス要求が厳しいものについては、k8sにのせない ◦ 知見が貯まった際に再度検討
17. Kubernetes採用に関しての障壁 => 導入 • Kubernetesの知見がない ◦ 影響がないシステムから導入する ◦ 最悪落ちた際のリカバリ手段を用意 => docker on インスタンス（過去の構成）で動かせる用に準備しておく ◦ 運用を通して知見をためる • 対象とするシステムがシビア ◦ 要求が厳しいものについては、k8sにのせない ◦ 知見が貯まった際に再度検討 影響が低いシステム リカバリ手段 自信を持って運用 運用力がLv Upしたら再度挑戦！
18. 構成詳細
19. システム構成詳細
20. システム構成詳細
21. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog
22. 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
23. 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でより便利に？
24. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog • Namespaces ◦ Prd環境・Stg環境のクラスタを分けてい る ◦ サービス毎に依存関係はないので、 Namespaceはサービス毎に切っている
25. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog • Deployment ◦ 入稿管理画面サービスはDeployment で管理 ◦ PodのReplica数の管理 ◦ ローリングアップデート ◦ オートヒーリングの実現
26. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog • CronJob ◦ バッチ系については、CronJobで管理 ◦ 定期的にバッチを実行
27. Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog • Daemon Set ◦ 監視にはDatadogを利用 ◦ Datadogの課金体系から、ノード毎に1 つ用意したい ◦ ノード毎にdeployしたいので、Daemon Setを利用
28. マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch
29. マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch • Kubernetes クラスタ ◦ 本番環境 ◦ ステージング環境 ◦ 開発環境（各自のローカルPC） ◦ 3環境のKubernetesクラスタ
30. マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch • 稼働サービス（コンテナ） ◦ Webサーバ ◦ アプリケーション（管理画面） ◦ バッチ ◦ 監視（Datadog） ◦ 4種類
31. マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch • 管理しなければならないYAML（という か設定内容） ◦ 環境 × 稼働サービス数 ◦ 要するに一杯 ◦ 各環境に共通する項目は共通化し、差 分のみを効率良く管理したい
32. マニフェスト管理（YAML管理） • kustomize ◦ YAML管理ツール ◦ 将来的にはkubectlに統合予定 ◦ resource毎にYAMLを別管理できる 公式サイトより(https://github.com/kubernetes-sigs/kustomize)
33. マニフェスト管理（YAML管理） • kustomize ◦ overlayにより、複数の環境を別YAML に切り出すことができる ◦ 共通項目をbaseに定義し、差分部分 （本番環境、ステージング環境）を別 YAMLファイルに切り出す等 公式サイトより(https://github.com/kubernetes-sigs/kustomize)
34. 監視（Datadog） • Datadog ◦ 監視はDatadogに全ておまかせ ◦ SaaSなので、すぐに利用可能 ◦ プラグインが豊富にある（Kubernetes 用のもあり） ◦ 社内がマルチクラウド（AWS, GCP, Azure）なので、監視系はクラウドベン ダーにロックインされたくない 公式ドキュメントより (https://www.datadoghq.com/ja/blog/monitoring-kubernetes-data dog/)
35. 監視（Datadog） • Datadog ◦ 標準でKubernetesのテンプレートが存 在 ◦ 直ぐにDashboardを構築可能 ◦ Nodeの状態 ◦ Podの状態 ◦ etc...
36. Kubernetes構成まとめ • 構成自体はシンプル ◦ Deployment、 CronJob、DaemonSetをそれぞれの役割にマッチした用途で利用 • マニフェスト管理もシンプル ◦ kustomizeで適切に環境毎のYAMLを管理 ◦ 本当に必要になるまで、Helm等は入れない • 監視もシンプル ◦ Datadog（SaaS）を利用することにより、監視システムの構築工数を削減 ◦ インターフェースも分かりやすいので、キャッチアップも楽
37. Kubernetes構成まとめ • シンプル、分かりやすい構成からスタート => 知見がなくても、運用できそうな 攻めない！程良い構成とする => ステートレスな機能のみを利用 • マネージド + SaaSを活用 => マネージドでk8s自体の管理をお任せ => SaaSで知見がなくても、プリセットを利用して、必要最低限の監視は可能
38. 導入した結果/感想
39. Kubernetesを導入した効果 • リリースサイクルの向上 ◦ deployが1 コマンドで可能なので、deployの準備に手間がかからない ◦ deployが簡単なので、deployに対する心理的障壁も下がる ◦ 初回リリース（9月初旬）から現在（12月中頃）までのリリース回数は30 弱回 ◦ スプリントが1週間なので、ほぼスプリント毎にリリースしている
40. Kubernetesを導入した効果 • リリース時間の短縮 ◦ 1 コマンドでdeployできるので、deployが数分で完了 ◦ リリース時間が短縮できるので、日々のスプリントに対する開発時間へ の影響も抑えられる ◦ 手作業がないので、オペミスがほぼ起こらない
41. Kubernetesを導入した効果 • リリースメンバーの属人化が防げる ◦ deployが簡単なので、アプリケーションエンジニアでもできる ◦ Kubernetesに関する深い知識がなくてもdeploy可能 ◦ ローテでチームメンバー全員がリリース可能
42. Kubernetesを導入した効果 リリースがとても速く楽になった！
43. Kubernetes（というかAKS）を導入した効果 番外編 • 深刻な脆弱性が発見される ◦ 2018/12/4発表 ◦ 深刻度は9.8（最大10） ◦ 権限昇格の脆弱性 ◦ 任意のユーザがノード及びポッドを自 由に操作できる Github Kubernetes Repoより (https://github.com/kubernetes/kubernetes/issues/71411)
44. Kubernetes（というかAKS）を導入した効果 番外編 • 簡単にアップデート ◦ Azure Consoleよりアップデート ◦ 所要時間数分 ◦ 特にサービスダウンなく、アップデート 完了 ◦ 脆弱性情報を知ってから、その日の内 に対応完了
45. Kubernetesを導入した効果 番外編 • ポータビリティ性の良さを実感 ◦ 開発時、本番環境（AKS）でのみ、アプリケーションが正常に動作しない事象が発生 ◦ ローカルでは問題なく動く ◦ 切り分けの為、別のマネージドKubernetes環境で検証した際に再現 ◦ アプリケーション側での問題だと分かり、速やかに原因特定できた ◦ 同じマニフェストファイルを適用するだけで、他のKubernetes環境でも動作する ◦ 他の環境に持っていくのに、ほぼノーコストですみ、ポータビリティの良さを実感
46. Kubernetes（AKS）を３ヶ月近く運用した感想 • 思っていたより、問題起きない ◦ とても安定している ◦ この3ヶ月、困った事象は特に発生しなかった • メンバーへのスキルトランスファーもスムーズに行えた ◦ ハンズオン形式のチーム内勉強会を2回程実施 ◦ 後はリリース作業を通して、実地で学ぶ • オートヒーリングは便利 ◦ Podが落ちたことがあったが、自動的に復旧してくれるので、やはり便利
47. 今後の展望 • 配信系システムの移行検討 ◦ 配信系のシステムもリリース及びリソース管理が大変なので、Kubernetesへ移行したい • パフォーマンス検討 ◦ 配信系ではレイテンシが問題になるので、パフォーマンスに影響がないか検証が必要 • カナリアリリース ◦ 現状、一括でアップデートしているので、カナリアリリースで問題がないことを確認したの ち、順次リリースするようにしたい
48. まとめ • 影響度の低いシステムから導入する • シンプルな構成を保つ • マネージド・SaaSを利用する • Kubernetesの基本的な機能のみでも導入するメリットは多数ある
49. まとめ • 影響度の低いシステムから導入する • シンプルな構成を保つ • マネージド・SaaSを利用する • Kubernetesの基本的な機能のみでも導入するメリットは多数ある 頑張らなくてもKubernetesは導入できる
50. 弊社採用ページ https://hrmos.co/pages/fringe81/jobs/0000037 • 絶賛エンジニア募集中 ◦ AWS/GCP/Azure ◦ Kubernetes ◦ AdTech/HR Tech/SaaS ◦ Scala/Go/Elm/TypeScript お約束の広告（We’re Hiring!）