Tweet
Tweet

Slide 1

Slide 1 text

頑張らない 株式会社 技術開発本部 森本　真一

Slide 2

Slide 2 text

Fringe81 ● 六本木の会社 ● Ad Tech系/HR Tech系の領域で様々なサー ビスを展開 ○ Ad Tech系: docomo Ad Network, GrowLio, etc ○ HR Tech系: Unipos ● 絶賛エンジニア募集中

Slide 3

Slide 3 text

Unipos ● ● ピアボーナスサービス ○ 組織風土の変革 ○ 従業員エンゲージメントの向上 ○ 若手・中間マネジメント層の育成 https://unipos.me/ja/

Slide 4

Slide 4 text

GrowLio ● ● アプリメディア向け広告サービス ○ 広告配信プラットフォームの開発～保守 運用まで含めた支援 ○ ナショナルクライアントを含む広告主や広 告代理店への営業活動支援 ○ 広告事業全般に関するオペレーション支 援

Slide 5

Slide 5 text

今日お話しすること 新規プロダクト（GrowLio）にてKubernetesを導入した経験を元に ● 導入した背景・経緯 ● 構成詳細 ● 導入した結果/感想

Slide 6

Slide 6 text

導入した背景・経緯

Slide 7

Slide 7 text

導入した背景 ● これまで経験した辛みを解消したい => 過去の経験を活かす的ななにかカッコいい言葉をイメージしてください ● 新規プロダクト開発なので、積極的に新技術を導入したい => 未来を見据えて的ななにかカッコいい言葉をイメージしてください

Slide 8

Slide 8 text

Kubernetes採用前（過去のプロダクトの構成） インスタンス/VM docker Web Server ● デプロイが大変 ○ 手順書に沿って、手動でデプロイ ○ オレオレ deploy shell scripts ● リソースマネージメントが大変 ○ 手動でスケールアップ or スケールア ウト ● 障害時の対応が大変 ○ 手動で復旧 App Server other インスタ ンス/VM docker C C C 同一セット …

Slide 9

Slide 9 text

Kubernetes採用後（イメージ） インスタンス /VM Kubernetes Web Server ● デプロイが大変 => YAML適用のみ => ローリングデプロイも可能 ● リソースマネージメントが大変 => Podのオートスケール ● 障害時の対応が大変 => 落ちても自動でPodが復旧する App Server other インスタンス /VM インスタンス /VM 同一 Pod

Slide 10

Slide 10 text

Kubernetes採用に関しての障壁 ● Kubernetesの知見がない ○ ほぼアプリケーションエンジニア ○ 全員k8s実運用経験なし！ ● 対象とするシステムがシビア ○ 後述

Slide 11

Slide 11 text

Kubernetes採用に関しての障壁 ● Kubernetesの知見がない ○ ほぼアプリケーションエンジニア ○ 全員k8s実運用経験なし！ ● 対象とするシステムがシビア ○ 後述 障害が起きたときに 対応できるか 不安 k8sにのせて、パ フォーマンス要求を 満たせるだろうか？ 不安

Slide 12

Slide 12 text

ざっくり配信プラットフォームの構成 広告配信システム 入稿管理システム 各種バッチ ユーザー 広告主

Slide 13

Slide 13 text

ざっくり配信プラットフォームの構成 ● 広告配信システム ○ 広告を配信する ○ 低レイテンシ（レスポンスがもの凄く速い 数十 ） ○ ミッションクリティカル（落ちると非常にまずい） ● 各種バッチ ○ 配信した結果を集計するバッチ等 ○ の単位で実行されるバッチ ● 入稿管理システム ○ 広告を入稿するシステム ○ 管理画面

Slide 14

Slide 14 text

ざっくり配信プラットフォームの構成 ● 広告配信システム ○ 広告を配信する ○ 低レイテンシ（レスポンスがもの凄く速い 数十 ） ○ ミッションクリティカル（落ちると非常にまずい） ● 各種バッチ ○ 配信した結果を集計するバッチ等 ○ の単位で実行されるバッチ ● 入稿管理システム ○ 広告を入稿するシステム ○ 管理画面 停止した際の影響度 少し大変 非常に大変！！

Slide 15

Slide 15 text

ざっくり配信プラットフォームの構成 ● 広告配信システム ○ 広告を配信する ○ 低レイテンシ（レスポンスがもの凄く速い 数十 ） ○ ミッションクリティカル（落ちると非常にまずい） ● 各種バッチ ○ 配信した結果を集計するバッチ等 ○ の単位で実行されるバッチ ● 入稿管理システム ○ 広告を入稿するシステム ○ 管理画面 停止した際の影響度 少し大変 非常に大変！！ k8sで稼働できそう

Slide 16

Slide 16 text

Kubernetes採用に関しての障壁 => 導入 ● Kubernetesの知見がない ○ 影響がないシステムから導入する ○ 最悪落ちた際のリカバリ手段を用意 => docker on インスタンス（過去の構成）で動かせる用に準備しておく ○ 運用を通して知見をためる ● 対象とするシステムがシビア ○ パフォーマンス要求が厳しいものについては、k8sにのせない ○ 知見が貯まった際に再度検討

Slide 17

Slide 17 text

Kubernetes採用に関しての障壁 => 導入 ● Kubernetesの知見がない ○ 影響がないシステムから導入する ○ 最悪落ちた際のリカバリ手段を用意 => docker on インスタンス（過去の構成）で動かせる用に準備しておく ○ 運用を通して知見をためる ● 対象とするシステムがシビア ○ 要求が厳しいものについては、k8sにのせない ○ 知見が貯まった際に再度検討 影響が低いシステム リカバリ手段 自信を持って運用 運用力がLv Upしたら再度挑戦！

Slide 18

Slide 18 text

構成詳細

Slide 19

Slide 19 text

システム構成詳細

Slide 20

Slide 20 text

システム構成詳細

Slide 21

Slide 21 text

Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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でより便利に？

Slide 24

Slide 24 text

Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog ● Namespaces ○ Prd環境・Stg環境のクラスタを分けてい る ○ サービス毎に依存関係はないので、 Namespaceはサービス毎に切っている

Slide 25

Slide 25 text

Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog ● Deployment ○ 入稿管理画面サービスはDeployment で管理 ○ PodのReplica数の管理 ○ ローリングアップデート ○ オートヒーリングの実現

Slide 26

Slide 26 text

Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog ● CronJob ○ バッチ系については、CronJobで管理 ○ 定期的にバッチを実行

Slide 27

Slide 27 text

Namespace Namespace Kubernetes構成詳細 Deployment Kubernetes Web Server App Server CronJob Batch Namespace Daemon Set Data Dog ● Daemon Set ○ 監視にはDatadogを利用 ○ Datadogの課金体系から、ノード毎に1 つ用意したい ○ ノード毎にdeployしたいので、Daemon Setを利用

Slide 28

Slide 28 text

マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch

Slide 29

Slide 29 text

マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch ● Kubernetes クラスタ ○ 本番環境 ○ ステージング環境 ○ 開発環境（各自のローカルPC） ○ 3環境のKubernetesクラスタ

Slide 30

Slide 30 text

マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch ● 稼働サービス（コンテナ） ○ Webサーバ ○ アプリケーション（管理画面） ○ バッチ ○ 監視（Datadog） ○ 4種類

Slide 31

Slide 31 text

マニフェスト管理（YAML管理） Production Kubernetes Staging Kubernetes dev(Local) Kubernetes Web Application Datadog Batch ● 管理しなければならないYAML（という か設定内容） ○ 環境 × 稼働サービス数 ○ 要するに一杯 ○ 各環境に共通する項目は共通化し、差 分のみを効率良く管理したい

Slide 32

Slide 32 text

マニフェスト管理（YAML管理） ● kustomize ○ YAML管理ツール ○ 将来的にはkubectlに統合予定 ○ resource毎にYAMLを別管理できる 公式サイトより(https://github.com/kubernetes-sigs/kustomize)

Slide 33

Slide 33 text

マニフェスト管理（YAML管理） ● kustomize ○ overlayにより、複数の環境を別YAML に切り出すことができる ○ 共通項目をbaseに定義し、差分部分 （本番環境、ステージング環境）を別 YAMLファイルに切り出す等 公式サイトより(https://github.com/kubernetes-sigs/kustomize)

Slide 34

Slide 34 text

監視（Datadog） ● Datadog ○ 監視はDatadogに全ておまかせ ○ SaaSなので、すぐに利用可能 ○ プラグインが豊富にある（Kubernetes 用のもあり） ○ 社内がマルチクラウド（AWS, GCP, Azure）なので、監視系はクラウドベン ダーにロックインされたくない 公式ドキュメントより (https://www.datadoghq.com/ja/blog/monitoring-kubernetes-data dog/)

Slide 35

Slide 35 text

監視（Datadog） ● Datadog ○ 標準でKubernetesのテンプレートが存 在 ○ 直ぐにDashboardを構築可能 ○ Nodeの状態 ○ Podの状態 ○ etc...

Slide 36

Slide 36 text

Kubernetes構成まとめ ● 構成自体はシンプル ○ Deployment、 CronJob、DaemonSetをそれぞれの役割にマッチした用途で利用 ● マニフェスト管理もシンプル ○ kustomizeで適切に環境毎のYAMLを管理 ○ 本当に必要になるまで、Helm等は入れない ● 監視もシンプル ○ Datadog（SaaS）を利用することにより、監視システムの構築工数を削減 ○ インターフェースも分かりやすいので、キャッチアップも楽

Slide 37

Slide 37 text

Kubernetes構成まとめ ● シンプル、分かりやすい構成からスタート => 知見がなくても、運用できそうな 攻めない！程良い構成とする => ステートレスな機能のみを利用 ● マネージド + SaaSを活用 => マネージドでk8s自体の管理をお任せ => SaaSで知見がなくても、プリセットを利用して、必要最低限の監視は可能

Slide 38

Slide 38 text

導入した結果/感想

Slide 39

Slide 39 text

Kubernetesを導入した効果 ● リリースサイクルの向上 ○ deployが1 コマンドで可能なので、deployの準備に手間がかからない ○ deployが簡単なので、deployに対する心理的障壁も下がる ○ 初回リリース（9月初旬）から現在（12月中頃）までのリリース回数は30 弱回 ○ スプリントが1週間なので、ほぼスプリント毎にリリースしている

Slide 40

Slide 40 text

Kubernetesを導入した効果 ● リリース時間の短縮 ○ 1 コマンドでdeployできるので、deployが数分で完了 ○ リリース時間が短縮できるので、日々のスプリントに対する開発時間へ の影響も抑えられる ○ 手作業がないので、オペミスがほぼ起こらない

Slide 41

Slide 41 text

Kubernetesを導入した効果 ● リリースメンバーの属人化が防げる ○ deployが簡単なので、アプリケーションエンジニアでもできる ○ Kubernetesに関する深い知識がなくてもdeploy可能 ○ ローテでチームメンバー全員がリリース可能

Slide 42

Slide 42 text

Kubernetesを導入した効果 リリースがとても速く楽になった！

Slide 43

Slide 43 text

Kubernetes（というかAKS）を導入した効果 番外編 ● 深刻な脆弱性が発見される ○ 2018/12/4発表 ○ 深刻度は9.8（最大10） ○ 権限昇格の脆弱性 ○ 任意のユーザがノード及びポッドを自 由に操作できる Github Kubernetes Repoより (https://github.com/kubernetes/kubernetes/issues/71411)

Slide 44

Slide 44 text

Kubernetes（というかAKS）を導入した効果 番外編 ● 簡単にアップデート ○ Azure Consoleよりアップデート ○ 所要時間数分 ○ 特にサービスダウンなく、アップデート 完了 ○ 脆弱性情報を知ってから、その日の内 に対応完了

Slide 45

Slide 45 text

Kubernetesを導入した効果 番外編 ● ポータビリティ性の良さを実感 ○ 開発時、本番環境（AKS）でのみ、アプリケーションが正常に動作しない事象が発生 ○ ローカルでは問題なく動く ○ 切り分けの為、別のマネージドKubernetes環境で検証した際に再現 ○ アプリケーション側での問題だと分かり、速やかに原因特定できた ○ 同じマニフェストファイルを適用するだけで、他のKubernetes環境でも動作する ○ 他の環境に持っていくのに、ほぼノーコストですみ、ポータビリティの良さを実感

Slide 46

Slide 46 text

Kubernetes（AKS）を３ヶ月近く運用した感想 ● 思っていたより、問題起きない ○ とても安定している ○ この3ヶ月、困った事象は特に発生しなかった ● メンバーへのスキルトランスファーもスムーズに行えた ○ ハンズオン形式のチーム内勉強会を2回程実施 ○ 後はリリース作業を通して、実地で学ぶ ● オートヒーリングは便利 ○ Podが落ちたことがあったが、自動的に復旧してくれるので、やはり便利

Slide 47

Slide 47 text

今後の展望 ● 配信系システムの移行検討 ○ 配信系のシステムもリリース及びリソース管理が大変なので、Kubernetesへ移行したい ● パフォーマンス検討 ○ 配信系ではレイテンシが問題になるので、パフォーマンスに影響がないか検証が必要 ● カナリアリリース ○ 現状、一括でアップデートしているので、カナリアリリースで問題がないことを確認したの ち、順次リリースするようにしたい

Slide 48

Slide 48 text

まとめ ● 影響度の低いシステムから導入する ● シンプルな構成を保つ ● マネージド・SaaSを利用する ● Kubernetesの基本的な機能のみでも導入するメリットは多数ある

Slide 49

Slide 49 text

まとめ ● 影響度の低いシステムから導入する ● シンプルな構成を保つ ● マネージド・SaaSを利用する ● Kubernetesの基本的な機能のみでも導入するメリットは多数ある 頑張らなくてもKubernetesは導入できる

Slide 50

Slide 50 text

弊社採用ページ https://hrmos.co/pages/fringe81/jobs/0000037 ● 絶賛エンジニア募集中 ○ AWS/GCP/Azure ○ Kubernetes ○ AdTech/HR Tech/SaaS ○ Scala/Go/Elm/TypeScript お約束の広告（We’re Hiring!）