ポッケにおけるKubernetesへの挑戦

ポッケがどの様にKubernetesへ挑戦したのか

モノリシックなアプリケーションから、マイクロサービス化した背景をふまえ
Kubernetes導入の軌跡を紹介。
また、マイクロサービス化する上で、Kubernetesだけでは足りない機能を
サービスメッシュを導入することにより解決しようと試みた話。

Transcript

1. ポッケにおける Kubernetesへの挑戦 @kano_k6a
2. about me twitter：@kano_k6a 職業：SRE的なことをやってます。
3. 今日話すこと ポッケがどのようにKubernetesに挑戦したか
4. スタートは社内アプリの老朽化によるリプレースプロジェクト。
5. 10年以上続いているシステムなので課題をたくさん抱えていた
6. - リファクタされないコード - 返されることのない技術的負債 - 肥大化し、増え続ける機能
7. 新しく生まれ変わるシステムにこれらを継承したくない
8. monolithからの脱却
9. マイクロサービス化
10. マイクロサービス化で実現したいこと - デリバリーを容易にしたい - 変更に強いシステムにしたい - 障害に強い仕組みにしたい - 価値あるサービスに集中したい
11. そもそもこの時アプリケーションエンジニアだったし・・・ というのもあり、全部 javaでなんとかなるスタックでとりあえず MSA始め てみることにしました！
12. マイクロサービスを実現するために必要なパーツを少しづつ検証し た。 まずはnetflix oss - サービスディスカバリー　 →　eureka - API Gateway　→　zuul - circuit breaker　→　Hystrix
13. やりたいことは実現できそう でも、コード書くのしんどい .... ビジネスロジックに集中したい！
14. なんかいい感じに実現できるミドルないの ....
15. Kubernetes
16. 何故Kubernetesに挑戦したのか
17. マイクロサービス実行基盤って書いてあるし。 https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
18. マイクロサービス化されたアプリケーションを なんかいい感じでサポートしてくれそうだったから
19. 最初のモチベーションはこんなもんでした！
20. あくまでマイクロサービス化が中心だったから
21. Kubernetesが提供してくれること - ローリングアップデート - ロードバランシング - セルフヒーリング - スケーリング＆オートスケーリング
22. Kubernetesの特徴 - 宣言的な構成管理 - インフラ、ネットワークの抽象化 - ポータビリティ（諸説あり） - オープンである
23. Kubernetesに期待できること - 拡張性 - エコシステム
24. （再掲）マイクロサービス化で実現したいこと - デリバリーを容易にしたい - 変更に強いシステムにしたい - 障害に強い仕組みにしたい - 価値あるサービスに集中したい
25. （再掲）マイクロサービス化で実現したいこと - デリバリーを容易にしたい　 →　宣言的な構成管理　 - 変更に強いシステムにしたい　 →　拡張性、エコシステム - 障害に強い仕組みにしたい　 →　セルフヒーリング - 価値あるサービスに集中したい　 →　導入することにより、アプリケー ションのコードに集中できる！
26. Kubernetes環境の構築
27. Azure Container Serviceを利用した k8s環境自体はサクッと構築できたが、問 題あり Vnetがカスタム出来なかった ↓ k8s環境とセットでデフォルトのVnetがも れなく付いてきた
28. acs-engineによりtemplate file(json)を 作成 ↓ ARM templateをもとにk8s環境を構築 ↓ acsでは出来なかったVnetのカスタマイ ズが可能に
29. サービス開始時はユーザー数が少ない ため最小構成にしたかった ユーザー数は徐々に増えていくため、柔 軟にスケールできる仕組みに変える必要 があった - クラスタオートスケール - 水平Podオートスケール
30. 昨年末、acs-engine開発中止のアナウンスが・・・ 時間軸的に移行するの無理・・・・ https://github.com/Azure/acs-engine
31. 色々あったがk8s導入することにより マイクロサービス化も形になってきた！
32. ただ、マイクロサービス化を実現する上 で、 k8sが提供してくれないものも多くあった。 https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/
33. 我々のマイクロサービス化で残った課題 - サービスの入り口（ingress） - サービス間通信のトレース - サービス間通信のロギング - 障害の切り出し - カナリア
34. 課題を解決するためにサービスメッシュの導入を試みた
35. サービスメッシュとは？ https://www.cncf.io/blog/2017/04/26/service-mesh-critical-component-cloud-native-stack/ サービスメッシュとは、サービス間のコミュニケーションをハンドルするための専用 インフラストラクチャー層です。 モダンなクラウドネイティブアプリケーションを構成する、複雑なトポロジを通して、信頼性の高い リクエストをデリバリする責任があります。
37. - ingress モチベーション k8sのingressを手軽に扱いたい ある程度のpath routingができれば良い ※istio version 0.8のingressを導入して いる version 0.8+のingress gatewayは未導 入 https://preliminary.istio.io/docs/tasks/telemetry/distributed-tracing/overview/
38. - 分散トレーシング モチベーション 分散環境の宿命でもある、複雑に絡み合 うトレース情報を楽に扱いたい https://preliminary.istio.io/docs/tasks/telemetry/distributed-tracing/jaeger/
39. - logging モチベーション 「x-request-id」などの分散トレースを識別 するidを特定したい 業務固有のhttp headerをログにはきた い https://preliminary.istio.io/docs/tasks/telemetry/logs/collecting-logs/
40. 我々のマイクロサービス化で残った課題 - サービスの入り口（ingress）　→　解決！ - サービス間通信のトレース　 →　解決！ - サービス間通信のロギング　 →　解決！ - 障害の切り出し　→　未解決 - カナリア　→　未解決
41. 課題 - カナリア - 機能をGAする前にメンテナーで触りたい - より安全にデプロイしたい - circuit breaking - まだ見ぬカスケード障害に備えたい - rate limitting - まだ見ぬカスケード障害に備えたい - スレッド過多問題を解決したい
42. まとめ マイクロサービス化を実現するために Kubernetesを選んだ。 Kubernetes単体だけでは機能が足りない。 だからサービスメッシュを導入した。
43. 最後に所感的なやつ k8sに挑戦してよかった。 結構今でも幸せだけど、ユーザーが爆発的に増えても何か頑張らなく てもいける感がある。
44. ご清聴ありがとうございました！