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