Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

0543d98c28c458480efab3153395ad0c?s=47 kanok
March 19, 2019

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

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

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

0543d98c28c458480efab3153395ad0c?s=128

kanok

March 19, 2019
Tweet

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/ サービスメッシュとは、サービス間のコミュニケーションをハンドルするための専用 インフラストラクチャー層です。 モダンなクラウドネイティブアプリケーションを構成する、複雑なトポロジを通して、信頼性の高い リクエストをデリバリする責任があります。

  36. None
  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. ご清聴ありがとうございました!