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

Transcript

1. VMとAWS ECSがメインのインフラにKubernetesを 導⼊した効能 ⽯⽥尭⼤
2. ⽯⽥ 尭⼤ CyberZ, inc. 出向中 メッセンジャーアプリのAPIおよび トーナメントサイトの開発に携わったあと、 OPENREC 事業部にてSREおよび CyberZ関連⼦会社のインフラエンジニアとして従事
3. 1.OPENREC.tvの紹介 2.コンテナ及びサーバーレス技術の導⼊状況 3.Kubernetesを導⼊するモチベーション 4.既存との並⾏運⽤⽅法について 5.稼働しているサービスの紹介 6.直⾯した問題 7.今後の展望 8.まとめ
4. 今回の発表の想定読者 • Kubernetesを業務で導⼊してみたいが踏ん切りがつかない⽅ • Kubernetesを使うからには特別なことをしないといけないと思ってる⽅ • Kubernetesを導⼊したいがどこからどこまで ⼿を付ければいいか分からない⽅ • 古いインフラの移⾏先にKubernetesを選択したいと思ってる⽅
5. OPENREC.tvについて
6. 国内最⼤規模のゲームコンテンツをメインとした動画配信PF 汎⽤性の⾼い専⽤スタジオを 完備 都内某所トータル1000平⽶以 上 内製オリジナルコンテン ツや eスポーツ⼤会を多数配 信 国内最⼤規模のゲーム特化 配信プラットフォーム 次世代e-sportsイベント “RAGE” ゲームに特化 配信端末 コンテンツ スタジオ
7. 配信者や企業タイアップのスタンプ 約500種類〜以上
8. 様々な番組も配信中
9. コンテナ及びサーバーレス の導⼊状況
10. コンテナ及びサーバーレスの導⼊状況 • Java 8 • Python 3.x • Node 12.x • Go 1.x • Rust 1.43.x (coming soon!)
11. コンテナ及びサーバーレスの導⼊状況 • サムネイル画像⽣成 • タイムライン⽣成 • 配信基盤のECSイベント受信 • 監視および監視の有効無効切り替え • 配信基盤 • 低遅延プロキシ • サーバーサイドレンダリングバックエンド 約100以上の関数 ピーク時1Kコンテナ以上稼働
12. 開発組織的には… サーバーレスOK︕ コンテナ開発OK︕ Kubernetesやってみたい︕
13. Kubernetesを導⼊するモチ ベーション
14. 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
15. 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
16. Kubernetesを導⼊するモチベーション 依存関係が分かりずらい。。 思わぬところへのデプロイ影響 などが出てくるように コンポーネントが増えた結果…
17. Kubernetesを導⼊するモチベーション 課題をまとめると… • APIやミドルウェア同⼠の依存関係に伴うリリース作業の煩雑化を抑制したい • 想定外の影響範囲によるバグおよびデグレーションを減らしたい • 新機能リリースに関わる他API・コンポーネント修正による開発スピードの低下を改善 したい • デバッグの煩雑化を何とかしたい • 技術的挑戦にハードルがどんどん上がっている
18. Kubernetesを導⼊するモチベーション ビジネス • 競合他社の勃興 • 開発もっとスピードアップさせよう︕ • 新機能のリリースサイクルをもっと早く︕ 開発 • 今のままでは開発スピードが上がらない… • 今以上にパラレルで開発を進められる状態が必要︕
19. Kubernetesを導⼊するモチベーション マイクロサービスアーキテクチャを導⼊することで… • 各APIを疎結合で開発することにより責務を明確化すれば依存関係も⾃明に • 責務が明確になれば影響範囲も⾃明になるのでは︖ • 修正箇所は減らないが、責務が明確なので修正⾃体の⾒通しがつきやすい • APIが限られるのでデバッグも楽に • せっかくならKubernetesを採⽤してみよう
20. 導⼊するにあたっての条件 • ⼿段にこだわりすぎない (難易度が⾼ければECSなどKubernetes以外にスイッチすることも考える) • サービス開発がメインミッションであり、Kubernetes導⼊はサブミッションであること を忘れない • 新規開発を停⽌するような状況には陥らない • 新機能をリリースすることが最優先である
21. とは書きましたが… • 実際の所、他オーケストレーションにスイッチすることを考えながら進めていても 中途半端で効率が上がらないので、途中からKubernetes導⼊前提で振り切り プロジェクトを進めました • Kubernetesに限らずですが、性能的・仕様的に必要でない限り、 本当にリリースターゲットをずらせない機能に対しての技術的挑戦は やめておいた⽅が吉でしょう • 開発責任者とスケジュールや案件の温度感等綿密に認識合わせをしておくことが 必須です
22. 既存との並⾏運⽤⽅法について
23. 既存との共存について • 既存APIと同様のドメインにしたかったが、独⾃のBlue/Green⽅式を取っており、 ロードバランサーの設定的にもリリースフロー的にも既存APIと 同等の階層に並べることが難しかった • 既存APIサーバーをBFFのように扱いたかった • バックエンドサービスが死んでいたとしても 何らかのレスポンスを返せるようにしたかった
24. 最初考えていた構成 既存API 新規マイクロサービスAPI
25. 最初考えていた構成 既存API 新規マイクロサービスAPI サブドメインを統⼀したかったが、 うまく⾏かずに断念。 Service Meshは導⼊コストが⾼いので ⾒送り
26. バックエンド(BFF like)サービスとして構成 ネイティブクライアント⽤レスポンス PC(web)⽤レスポンス user api contents api auth api stamp api point api etc. Backends For Frontendsの略。 ここではクライアントに対して複数のAPIを束ねて 1つのAPIレスポンスとして返すサーバーという意味で使⽤ 既存API 新規API
27. user api contents api auth api stamp api point api etc. バックエンドサービスが死んでいたとしても BFF側で何らかのレスポンスを返せる バックエンド(BFF like)サービスの利点 レスポンスこないな。。 ひとまずデフォルト値を返そう
28. 既存API 新規マイクロ サービスAPI VPC内部に閉じた通信 最終構成
29. 稼働しているサービスの紹介
30. 稼働しているサービスの紹介 開発環境 本番環境 開発メンバー全員 ログインOK 本番権限所有者のみ ログイン可能 スポットインスタンス 100%で稼働 夜間帯はワーカーノード停⽌ スポットインスタンス 50%で稼働
31. 稼働しているサービスの紹介 最終的なインフラ構成全体概要
32. 稼働しているサービスの紹介 ココにKubernetes︕ 最終的なインフラ構成全体概要
33. 稼働しているサービスの紹介 構成管理など - インフラ構成管理: Terraform - マニフェスト管理: Kustomize(kubectlに内包) - CI: AWS CodeBuild - CD: ArgoCD
34. 稼働しているサービスの紹介 • バックエンドサービス3つ • ALB Ingress Controller • ExternalDNS • AgroCD • Fluentd • Fluent Bit • Kube-Prometheus • Horizontal Pod Autoscaler • Cluster Autoscaler • Metrics-server • Kubernetes Dashboard
35. 稼働しているサービスの紹介 バックエンドサービス • 使⽤⾔語: Kotlin • 使⽤フレームワーク: Ktor • メモリのlimit, requestは4096MiBで設定 • CPUは4000mCPU = 4コア割当 • application.ymlはdeployment.ymlのargsディレクティブで指定
36. Ktorとは • Kotlinのcoroutineを利⽤した⾮同期処理に最適化されたWebFramework • マイクロサービスと相性良さそうと判断し導⼊ • サーバーサイドKotlinに対する技術的好奇⼼ も導⼊を後押しした
37. 稼働しているKUBERNETES運⽤関連サービスを⼀部紹介 ALB Ingress Controller ⽂字通りAWSのALBをIngress Resourceにできるコントローラー アノテーションでヘルスチェックの設定はもちろんルーティング制御なども可能 CLBで良ければ必要ないが⼊れておくと吉 個⼈的には必須要素の1つだと思ってる internalLB, サブネット, セキュリティグループ, ヘルスチェックパス, SSL証明書, ALBのログ出⼒ を指定している例
38. 稼働しているKUBERNETES運⽤関連サービスを⼀部紹介 ExternalDNS DNSレコードをKubernetesのリソースとして管理出来る 特筆事項として対応しているDNSサーバーの豊富さが挙げられる ingressリソースにhostディレクティブで指定するだけでレコード作成される 個⼈的に⼀番好きなコントローラー
39. 稼働しているKUBERNETES運⽤関連サービスを⼀部紹介 ClusterAcutoscaler ワーカーノードをPodの配備状況によって⾃動的にスケールさせてくれる 最⼩・最⼤稼働台数を指定しておけば⾃動でスケールアウト・インしてくれる Horizontal Pod Autoscaler Pod(コンテナ)のスケールアウト・インを⾃動でやってくれる ⼤きく分けて、リソース使⽤率に基づくスケーリングとカスタムメトリクス(ネットワー クトラフィックとか)に基づくスケーリングポリシーが取れる
40. リリースフローについて developブランチにpush CodeBuildでJarビルド dockerビルド ECRにpush argoCDがgithubのイベントhookし 開発環境にタグがついたイメージをrollout アプリケーション開発者は基本的にKubernetesに触ることなく 開発環境にコードを反映可能 本番環境のみ⼿動でロールアウトを実施 → →
41. リポジトリにある状態と差分が無い状態を保とうとしてくれる 何もしなくても最新のコードがデプロイされる︕ 差分がない状態 差分がある状態
42. アプリケーションだけでなくALBIngressControllerや PrometheusもArgoCDで状態管理
43. 稼働しているサービスの紹介 受けられる恩恵をまとめると… • アプリケーション開発をするエンジニアは、 サーバー・インフラを意識することなく開発が可能 • 既存では不完全だったCI/CDフローをほぼ完全に実現 • 開発環境に今何がデプロイされているのか不明になるが無くなった
44. 直⾯した問題たち
45. 考慮しなきゃいけないこと • ネットワーク(VPC)設計 • 性能検証 • 構成管理 • デプロイ(CI/CD) • 障害対応など 当たり前だが⼀⼈で担当できる量ではない。。 SREチームで分担して担当
46. Issue総数160弱
47. 何⼊れてもおｋクラスタ(通称魔窟クラスタ)
48. 直⾯した問題たち(IPアドレス枯渇問題) 11アドレスしか各サブネットで在庫が無く、これ以上⽴ち上がらない状態に
49. 直⾯した問題たち(IPアドレス枯渇問題) サブネット単位でアプリケーションを管理する必要もないので、20bitで切ることで回避 現在は1クラスタ4091 x 6サブネット = 24546IPアドレス使⽤可能 2万アドレスあれば 今の使い⽅では 流⽯に枯渇しないはず
50. 直⾯した問題たち(DNSレコードの管理について) • DNSレコードは今まで⼿動で管理 • ExternalDNSは使いたいが、 ExternalDNSの不具合等で既存のレコード削除などの事故は防ぎたい • DNSの権限委任を利⽤し、ドメイン管理を階層化して 操作出来るDNSのスコープを絞って対応 • 更に不⽤意なレコード削除を防ぐためレコードの更新のみ出来る状態にして運⽤
51. 直⾯した問題たち(DNSレコードの管理について) Kubernetesからopenrec.tvの階層でサービス展開したい場合は、 上層のネームサーバーにCNAMEでsvc.openrec.tvのレコードを登録して向けばOK 新設(原則Kubernetesからのみ操作可能)
52. 直⾯した問題たち(SQL発⾏されすぎ問題) 1クエリのために5クエリ余分に発⾏されている
53. 直⾯した問題たち(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を⾒てしまうこともあるので、 あまりいい考えではないと思います。
54. 直⾯した問題たち(SQL発⾏されすぎ問題) 改善前 改善後 専⽤クラスを⽤意し、overrideして発⾏するSQLを抑制
55. (当たり前ですが)チューニングはちゃんとしましょう 弊社藤井が本⽇『EKS x locustで構築する⼤規模負荷試験環』という表題で LT予定なので是⾮ご覧下さい
56. 今後の展望
57. 今後の展望 リソース集約によるコスト削減を⽬的とした既存サービスの移⾏ →
58. 今後の展望 ⽐較的ステートフルな通信をするWebsocketサーバーの構築 →
59. まとめ
60. まとめ 2019年6⽉ プロジェクトスタート 2019年12⽉上旬 リリース完了 約6ヶ⽉弱でプロジェクト完了
61. まとめ Kubernetesじゃなくても⼗分実現できる内容なのでは︖ Custom ControllerやCustom Resourceを 使ってこそKubernetesなのでは︖
62. まとめ まず運⽤出来る形までもっていく (運⽤出来る程度は開発組織に寄って異なる) ⼀旦Kubernetesの⼟台を整備したらこっちのもの 新しい機能は徐々に⼊れていこう
63. まとめ • Kubernetesを利⽤して、今までになかったユーザー体験を どのように提供出来るか • 新たなユーザ体験を提供する基盤としてのKubernetes
64. まとめ • Kubernetesは(基本的に使うだけなら)もう難しくない(ただし導⼊コストが⾒合っている かは議論の余地あり) • CI/CDパイプラインの設定及びGitのブランチ運⽤は開発メンバーで⼗分に議論し決める 必要あり(ここを怠ると開発効率が致命的に下がる) • Kubernetesを使っていることを意識させない運⽤も⼤切 • Kubernetesを⽤いてどのようなユーザー体験を提供出来るのかを常に考える必要がある • 新しいものに抵抗が無い若⼿に任せると勝⼿にいい感じにしてくれるから思い切って ⾊々任せてみる
65. We Are Hiring︕