VMとAWS ECSがメインのインフラにKubernetesを導入した効能

by Dorian

Slide 1

Slide 1 text

VMとAWS ECSがメインのインフラにKubernetesを導⼊した効能⽯⽥尭⼤

Slide 2

Slide 2 text

⽯⽥尭⼤ CyberZ, inc. 出向中メッセンジャーアプリのAPIおよびトーナメントサイトの開発に携わったあと、 OPENREC 事業部にてSREおよび CyberZ関連⼦会社のインフラエンジニアとして従事

Slide 3

Slide 3 text

1.OPENREC.tvの紹介 2.コンテナ及びサーバーレス技術の導⼊状況 3.Kubernetesを導⼊するモチベーション 4.既存との並⾏運⽤⽅法について 5.稼働しているサービスの紹介 6.直⾯した問題 7.今後の展望 8.まとめ

Slide 4

Slide 4 text

今回の発表の想定読者 • Kubernetesを業務で導⼊してみたいが踏ん切りがつかない⽅ • Kubernetesを使うからには特別なことをしないといけないと思ってる⽅ • Kubernetesを導⼊したいがどこからどこまで⼿を付ければいいか分からない⽅ • 古いインフラの移⾏先にKubernetesを選択したいと思ってる⽅

Slide 5

Slide 5 text

OPENREC.tvについて

Slide 6

Slide 6 text

国内最⼤規模のゲームコンテンツをメインとした動画配信PF 汎⽤性の⾼い専⽤スタジオを完備都内某所トータル1000平⽶以上内製オリジナルコンテンツや eスポーツ⼤会を多数配信国内最⼤規模のゲーム特化配信プラットフォーム次世代e-sportsイベント “RAGE” ゲームに特化配信端末コンテンツスタジオ

Slide 7

Slide 7 text

配信者や企業タイアップのスタンプ約500種類〜以上

Slide 8

Slide 8 text

様々な番組も配信中

Slide 9

Slide 9 text

コンテナ及びサーバーレスの導⼊状況

Slide 10

Slide 10 text

コンテナ及びサーバーレスの導⼊状況 • Java 8 • Python 3.x • Node 12.x • Go 1.x • Rust 1.43.x (coming soon!)

Slide 11

Slide 11 text

コンテナ及びサーバーレスの導⼊状況 • サムネイル画像⽣成 • タイムライン⽣成 • 配信基盤のECSイベント受信 • 監視および監視の有効無効切り替え • 配信基盤 • 低遅延プロキシ • サーバーサイドレンダリングバックエンド約100以上の関数ピーク時1Kコンテナ以上稼働

Slide 12

Slide 12 text

開発組織的には… サーバーレスOK︕ コンテナ開発OK︕ Kubernetesやってみたい︕

Slide 13

Slide 13 text

Kubernetesを導⼊するモチベーション

Slide 14

Slide 14 text

Kubernetesを導⼊するモチベーション OPENREC.tv リリース当初の使⽤技術 • CentOS 6.4 • PHP 5.6 • Node 0.10.36 • Apache HTTP Server 2.2 • MySQL 5.5 • Redis 2.0 • 固定ホストなEC2

Slide 15

Slide 15 text

Kubernetesを導⼊するモチベーション OPENREC.tv 現在の利⽤技術 • AmazonLinux1and2/CentOS7/CentOS6 • EC2 with AutoScale • ECS • Kubernetes • Docker19.03/18.03/17.03 • PHP7 • Apache HTTP Server 2.4 • Nginx1.14~1.17 • Node10~13(TypeScript2.x) • Java8 • Kotlin • golang 1.10~1.13 • Amazon Aurora • DynamoDB • Redis 2.0~4.0 • Redshift

Slide 16

Slide 16 text

Kubernetesを導⼊するモチベーション依存関係が分かりずらい。。思わぬところへのデプロイ影響などが出てくるようにコンポーネントが増えた結果…

Slide 17

Slide 17 text

Kubernetesを導⼊するモチベーション課題をまとめると… • APIやミドルウェア同⼠の依存関係に伴うリリース作業の煩雑化を抑制したい • 想定外の影響範囲によるバグおよびデグレーションを減らしたい • 新機能リリースに関わる他API・コンポーネント修正による開発スピードの低下を改善したい • デバッグの煩雑化を何とかしたい • 技術的挑戦にハードルがどんどん上がっている

Slide 18

Slide 18 text

Kubernetesを導⼊するモチベーションビジネス • 競合他社の勃興 • 開発もっとスピードアップさせよう︕ • 新機能のリリースサイクルをもっと早く︕ 開発 • 今のままでは開発スピードが上がらない… • 今以上にパラレルで開発を進められる状態が必要︕

Slide 19

Slide 19 text

Kubernetesを導⼊するモチベーションマイクロサービスアーキテクチャを導⼊することで… • 各APIを疎結合で開発することにより責務を明確化すれば依存関係も⾃明に • 責務が明確になれば影響範囲も⾃明になるのでは︖ • 修正箇所は減らないが、責務が明確なので修正⾃体の⾒通しがつきやすい • APIが限られるのでデバッグも楽に • せっかくならKubernetesを採⽤してみよう

Slide 20

Slide 20 text

導⼊するにあたっての条件 • ⼿段にこだわりすぎない (難易度が⾼ければECSなどKubernetes以外にスイッチすることも考える) • サービス開発がメインミッションであり、Kubernetes導⼊はサブミッションであることを忘れない • 新規開発を停⽌するような状況には陥らない • 新機能をリリースすることが最優先である

Slide 21

Slide 21 text

とは書きましたが… • 実際の所、他オーケストレーションにスイッチすることを考えながら進めていても中途半端で効率が上がらないので、途中からKubernetes導⼊前提で振り切りプロジェクトを進めました • Kubernetesに限らずですが、性能的・仕様的に必要でない限り、本当にリリースターゲットをずらせない機能に対しての技術的挑戦はやめておいた⽅が吉でしょう • 開発責任者とスケジュールや案件の温度感等綿密に認識合わせをしておくことが必須です

Slide 22

Slide 22 text

既存との並⾏運⽤⽅法について

Slide 23

Slide 23 text

既存との共存について • 既存APIと同様のドメインにしたかったが、独⾃のBlue/Green⽅式を取っており、ロードバランサーの設定的にもリリースフロー的にも既存APIと同等の階層に並べることが難しかった • 既存APIサーバーをBFFのように扱いたかった • バックエンドサービスが死んでいたとしても何らかのレスポンスを返せるようにしたかった

Slide 24

Slide 24 text

最初考えていた構成既存API 新規マイクロサービスAPI

Slide 25

Slide 25 text

最初考えていた構成既存API 新規マイクロサービスAPI サブドメインを統⼀したかったが、うまく⾏かずに断念。 Service Meshは導⼊コストが⾼いので⾒送り

Slide 26

Slide 26 text

バックエンド(BFF like)サービスとして構成ネイティブクライアント⽤レスポンス PC(web)⽤レスポンス user api contents api auth api stamp api point api etc. Backends For Frontendsの略。ここではクライアントに対して複数のAPIを束ねて 1つのAPIレスポンスとして返すサーバーという意味で使⽤既存API 新規API

Slide 27

Slide 27 text

user api contents api auth api stamp api point api etc. バックエンドサービスが死んでいたとしても BFF側で何らかのレスポンスを返せるバックエンド(BFF like)サービスの利点レスポンスこないな。。ひとまずデフォルト値を返そう

Slide 28

Slide 28 text

既存API 新規マイクロサービスAPI VPC内部に閉じた通信最終構成

Slide 29

Slide 29 text

稼働しているサービスの紹介

Slide 30

Slide 30 text

稼働しているサービスの紹介開発環境本番環境開発メンバー全員ログインOK 本番権限所有者のみログイン可能スポットインスタンス 100%で稼働夜間帯はワーカーノード停⽌スポットインスタンス 50%で稼働

Slide 31

Slide 31 text

稼働しているサービスの紹介最終的なインフラ構成全体概要

Slide 32

Slide 32 text

稼働しているサービスの紹介ココにKubernetes︕ 最終的なインフラ構成全体概要

Slide 33

Slide 33 text

稼働しているサービスの紹介構成管理など - インフラ構成管理: Terraform - マニフェスト管理: Kustomize(kubectlに内包) - CI: AWS CodeBuild - CD: ArgoCD

Slide 34

Slide 34 text

稼働しているサービスの紹介 • バックエンドサービス3つ • ALB Ingress Controller • ExternalDNS • AgroCD • Fluentd • Fluent Bit • Kube-Prometheus • Horizontal Pod Autoscaler • Cluster Autoscaler • Metrics-server • Kubernetes Dashboard

Slide 35

Slide 35 text

稼働しているサービスの紹介バックエンドサービス • 使⽤⾔語: Kotlin • 使⽤フレームワーク: Ktor • メモリのlimit, requestは4096MiBで設定 • CPUは4000mCPU = 4コア割当 • application.ymlはdeployment.ymlのargsディレクティブで指定

Slide 36

Slide 36 text

Ktorとは • Kotlinのcoroutineを利⽤した⾮同期処理に最適化されたWebFramework • マイクロサービスと相性良さそうと判断し導⼊ • サーバーサイドKotlinに対する技術的好奇⼼も導⼊を後押しした

Slide 37

Slide 37 text

稼働しているKUBERNETES運⽤関連サービスを⼀部紹介 ALB Ingress Controller ⽂字通りAWSのALBをIngress Resourceにできるコントローラーアノテーションでヘルスチェックの設定はもちろんルーティング制御なども可能 CLBで良ければ必要ないが⼊れておくと吉個⼈的には必須要素の1つだと思ってる internalLB, サブネット, セキュリティグループ, ヘルスチェックパス, SSL証明書, ALBのログ出⼒を指定している例

Slide 38

Slide 38 text

稼働しているKUBERNETES運⽤関連サービスを⼀部紹介 ExternalDNS DNSレコードをKubernetesのリソースとして管理出来る特筆事項として対応しているDNSサーバーの豊富さが挙げられる ingressリソースにhostディレクティブで指定するだけでレコード作成される個⼈的に⼀番好きなコントローラー

Slide 39

Slide 39 text

稼働しているKUBERNETES運⽤関連サービスを⼀部紹介 ClusterAcutoscaler ワーカーノードをPodの配備状況によって⾃動的にスケールさせてくれる最⼩・最⼤稼働台数を指定しておけば⾃動でスケールアウト・インしてくれる Horizontal Pod Autoscaler Pod(コンテナ)のスケールアウト・インを⾃動でやってくれる⼤きく分けて、リソース使⽤率に基づくスケーリングとカスタムメトリクス(ネットワークトラフィックとか)に基づくスケーリングポリシーが取れる

Slide 40

Slide 40 text

リリースフローについて developブランチにpush CodeBuildでJarビルド dockerビルド ECRにpush argoCDがgithubのイベントhookし開発環境にタグがついたイメージをrollout アプリケーション開発者は基本的にKubernetesに触ることなく開発環境にコードを反映可能本番環境のみ⼿動でロールアウトを実施 → →

Slide 41

Slide 41 text

リポジトリにある状態と差分が無い状態を保とうとしてくれる何もしなくても最新のコードがデプロイされる︕ 差分がない状態差分がある状態

Slide 42

Slide 42 text

アプリケーションだけでなくALBIngressControllerや PrometheusもArgoCDで状態管理

Slide 43

Slide 43 text

稼働しているサービスの紹介受けられる恩恵をまとめると… • アプリケーション開発をするエンジニアは、サーバー・インフラを意識することなく開発が可能 • 既存では不完全だったCI/CDフローをほぼ完全に実現 • 開発環境に今何がデプロイされているのか不明になるが無くなった

Slide 44

Slide 44 text

直⾯した問題たち

Slide 45

Slide 45 text

考慮しなきゃいけないこと • ネットワーク(VPC)設計 • 性能検証 • 構成管理 • デプロイ(CI/CD) • 障害対応など当たり前だが⼀⼈で担当できる量ではない。。 SREチームで分担して担当

Slide 46

Slide 46 text

Issue総数160弱

Slide 47

Slide 47 text

何⼊れてもおｋクラスタ(通称魔窟クラスタ)

Slide 48

Slide 48 text

直⾯した問題たち(IPアドレス枯渇問題) 11アドレスしか各サブネットで在庫が無く、これ以上⽴ち上がらない状態に

Slide 49

Slide 49 text

直⾯した問題たち(IPアドレス枯渇問題) サブネット単位でアプリケーションを管理する必要もないので、20bitで切ることで回避現在は1クラスタ4091 x 6サブネット = 24546IPアドレス使⽤可能 2万アドレスあれば今の使い⽅では流⽯に枯渇しないはず

Slide 50

Slide 50 text

直⾯した問題たち(DNSレコードの管理について) • DNSレコードは今まで⼿動で管理 • ExternalDNSは使いたいが、 ExternalDNSの不具合等で既存のレコード削除などの事故は防ぎたい • DNSの権限委任を利⽤し、ドメイン管理を階層化して操作出来るDNSのスコープを絞って対応 • 更に不⽤意なレコード削除を防ぐためレコードの更新のみ出来る状態にして運⽤

Slide 51

Slide 51 text

直⾯した問題たち(DNSレコードの管理について) Kubernetesからopenrec.tvの階層でサービス展開したい場合は、上層のネームサーバーにCNAMEでsvc.openrec.tvのレコードを登録して向けばOK 新設(原則Kubernetesからのみ操作可能)

Slide 52

Slide 52 text

直⾯した問題たち(SQL発⾏されすぎ問題) 1クエリのために5クエリ余分に発⾏されている

Slide 53

Slide 53 text

直⾯した問題たち(SQL発⾏されすぎ問題) Issue: https://github.com/JetBrains/Exposed/issues/306 I'm not sure that using Exposed's transactions with auto-commit is a good idea because in that case, we shouldn't use built-in Entity cache or we can see the wrong state of entities. Exposedのトランザクションをオートコミットで使うのは、その場合は組み込みの Entityキャッシュを使うべきではないし、間違った状態のEntityを⾒てしまうこともあるので、あまりいい考えではないと思います。

Slide 54

Slide 54 text

直⾯した問題たち(SQL発⾏されすぎ問題) 改善前改善後専⽤クラスを⽤意し、overrideして発⾏するSQLを抑制

Slide 55

Slide 55 text

(当たり前ですが)チューニングはちゃんとしましょう弊社藤井が本⽇『EKS x locustで構築する⼤規模負荷試験環』という表題で LT予定なので是⾮ご覧下さい

Slide 56

Slide 56 text

今後の展望

Slide 57

Slide 57 text

今後の展望リソース集約によるコスト削減を⽬的とした既存サービスの移⾏ →

Slide 58

Slide 58 text

今後の展望⽐較的ステートフルな通信をするWebsocketサーバーの構築 →

Slide 59

Slide 59 text

まとめ

Slide 60

Slide 60 text

まとめ 2019年6⽉プロジェクトスタート 2019年12⽉上旬リリース完了約6ヶ⽉弱でプロジェクト完了

Slide 61

Slide 61 text

まとめ Kubernetesじゃなくても⼗分実現できる内容なのでは︖ Custom ControllerやCustom Resourceを使ってこそKubernetesなのでは︖

Slide 62

Slide 62 text

まとめまず運⽤出来る形までもっていく (運⽤出来る程度は開発組織に寄って異なる) ⼀旦Kubernetesの⼟台を整備したらこっちのもの新しい機能は徐々に⼊れていこう

Slide 63

Slide 63 text

まとめ • Kubernetesを利⽤して、今までになかったユーザー体験をどのように提供出来るか • 新たなユーザ体験を提供する基盤としてのKubernetes

Slide 64

Slide 64 text

まとめ • Kubernetesは(基本的に使うだけなら)もう難しくない(ただし導⼊コストが⾒合っているかは議論の余地あり) • CI/CDパイプラインの設定及びGitのブランチ運⽤は開発メンバーで⼗分に議論し決める必要あり(ここを怠ると開発効率が致命的に下がる) • Kubernetesを使っていることを意識させない運⽤も⼤切 • Kubernetesを⽤いてどのようなユーザー体験を提供出来るのかを常に考える必要がある • 新しいものに抵抗が無い若⼿に任せると勝⼿にいい感じにしてくれるから思い切って⾊々任せてみる

Slide 65

Slide 65 text

We Are Hiring︕