Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

KubernetesでRedisを使うときの選択肢

1,068 views

Published on

CyberAgent社内Adtech Developer Conference発表資料

Published in: Technology
  • Be the first to comment

  • Be the first to like this

KubernetesでRedisを使うときの選択肢

  1. 1. KubernetesでRedisを使うときの 選択肢 2018年8月17日 Adtech Developer Conference 2018 アドテクスタジオ BrandAI 山田直行
  2. 2. 自己紹介 山田直行(やまだ なおゆき) 2011年6月入社 CAアメリカ、AMoAdで広告関連プロダクトに従事 2015年6月〜2017年5月 公務員として勤務するため休職 復職後、LiveDSPサーバーエンジニアを経て現在BrandAI開発責任者
  3. 3. 「簡単につかえる」 「スループット高い」 「レイテンシが低い」 「永続化もできる」 →Redisが候補になるが、GCP(東京)にはRedisのマネージドサービスは無い →どんな選択肢があるか検討 Kubernetesで手頃なKVSを使いたいときどうする?
  4. 4. BrandAIでのRedis ウェブAPIからのリクエストを受けて、セッションを読み書きする用途に利用 Kubernetes上で、Redis Clusterを組んでいる(1年ほど稼働中) Statefulsetとしてデプロイし、Master x 3, Slave x 3の6Pod構成 これでは冗長性が低いので、Slaveを倍にしてMaster x3, Slave x 6 (計9Pod)に変更 どれかのPodが落ちたときに再起動はするが自動でクラスタにジョインしてくれないという 問題があった(本来はそうではないので調査中)。 単なるキャッシュストレージにしては費用が高い印象もあったのと、障害時の運用も明確 でなかったので、Redisの使い方を再検討
  5. 5. 方針 ・GCPかつKubernetesを想定(AWSならElasticacheで決まり?) ・運用コストを減らしたい。学習コストが低く運用が楽であること ・HA構成をとりたい(深夜にノードが落ちたとしても自動で復旧してほしい。マネージド サービスライクに使える) ・BrandAIとしてはそこまでパフォーマンス最適化しなくてもよい。1万RPSぐらいさばけれ ばひとまず十分 ・ただし簡単なオペレーションでスケールアップまたはスケールアウトができる ・できれば費用を安く抑えたい
  6. 6. 選択肢の洗い出し (A)Compute Engine上にRedis専用のインスタンス (B)マネージドサービスのMemoryStoreを使う (C)SaaS/PaaSを使う (D)Kubernetes Engine上に作る
  7. 7. (A) Compute Engine上にRedis専用のインスタンス ・LiveDSPはこれだった。 ・ただしHA構成には未対応で、1インスタンスで1つのRedisプロセスがあっただけだった。 落ちたことは無かったが... ・SentinelとかClusterにする場合、どう組んで運用するかは別途考える必要がある。 Kubernetes中心の運用とは相容れない ・同一リージョンに置けば、レイテンシは無視できるレベル ・単体インスタンスのため、スループットのチューニングはしやすい
  8. 8. (B) Google Cloud MemoryStoreを使う ・待望のGCPのマネージドサービス。2018年5月から提供開始 ・ただし2018年8月現在、東京リージョン非対応 ・台湾リージョンにはあるが、指定したネットワーク内にPrivateIPでしかつなげないため、 東京リージョンで構築しているサービスからつなぐのは非現実的 ・monitor, saveなどを含むいくつかのコマンドが無効化されている。カスタムビルドか ・手動でフェイルオーバーさせる方法が見つからず、フェイルオーバーは試験できてない
  9. 9. (C) SaaSを使う ・今回は試してない ・Redis Enterprise(Hayabusaはこれ使ってるらしい), AWSのElastiCacheとか ・費用請求が別なのが地味に面倒 ・GCPのMarketplaceは将来的には選択肢に入ってくると思う。Bitnamiとか昔からある が、トラブったときにかえってめんどくさい。完全に任せられる(かつ実績もある)か、自分 自身で運用するか、のどっちかに振る必要がある
  10. 10. (D) Kubernetes Engine上に作る (1)単体構成 (2)Master-Slave構成 (3)Redis Sentinel (4)Redis Cluster の4パターンで検討
  11. 11. (1)単体構成 とりあえず仮って感じで一番手っ取り早い形 apiVersion: v1 kind: Pod metadata: name: some-redis labels: name: some-redis spec: containers: - image: launcher.gcr.io/google/redis4 name: redis これを kubectl apply する。 これにPersistentVolumeClaimを加えたりとか、Deploymentにしたりとかする ※シンプルすぎるようにも見えるが、GCE上に単体構成するとしたらこれと大して変わらない https://github.com/GoogleCloudPlatform/redis-docker/blob/master/4/README.md
  12. 12. (2)Master-Slave構成 https://github.com/helm/charts/tree/master/stable/redis Redis-Master (ClusterIP) Redis-Slave (ClusterIP) Redis Master (Stetefulset) Redis Slave (Deployment)Redis Slave (Deployment)Redis Slave (Deployment) Service Pod 落ちてもフェイル オーバーはしな い。再起動するだ けだが、PVCがあ るため永続化され たデータは復活す る
  13. 13. (3)Redis Sentinel Redis Sentinelとは: Master-Slave構成をとりつつ、SentinelというプロセスがMasterを監視していて、Masterの ダウンを検知するとSentinelが自動でSlaveをMasterに昇格させる https://github.com/helm/charts/tree/master/stable/redis-ha
  14. 14. Redis-Master (ClusterIP) Redis-Slave (ClusterIP) Redis (Deployment) Redis Sentinel (Deployment) Service Pod Redis-Sentinel (ClusterIP) Redis Sentinel (Deployment)Redis Sentinel (Deployment) Redis (Deployment)Redis (Deployment) selector redis-role=master selector redis-role=slave 3つのPodのうち、 1つがmaster、2つ がslave。動的に変 わる Sentinelは3台以 上で構成し、過半 数の投票でフェイ ルオーバーを判断 する 監視
  15. 15. Helmとは? Kubernetesのパッケージマネージャ service, deploymentなどのYAMLファイルとそのパラメータをパッケージ化したもの (チャートという) helm init # サーバー・クライアントでhelmを初期化 helm repo update # レポジトリを更新 helm search foo # fooチャートを検索 helm install foo # fooチャートをインストール helm delete foo # fooチャートを削除 ローカルにあるチャートの適用もできる
  16. 16. (4)Redis Cluster Master Slave構成を1セットとして、それを3Master以上で構成する Redis Cluster入門 - Qiita https://qiita.com/uryyyyyyy/items/fc767f7f41144e5f10a1 公式なソリューションはない。OSSからいくつか検証している状態 下記のChartは安定して動作するのを確認 https://github.com/sanderploegsma/redis-cluster
  17. 17. RedisCluster-0 (Stetefulset) Service (Headless) Pod master x 3, slave x 3の構成 どれか落ちても自 動でフェイルオー バーして自己復旧 する RedisCluster-1 (Stetefulset) RedisCluster-2 (Stetefulset) RedisCluster-3 (Stetefulset) RedisCluster-4 (Stetefulset) RedisCluster-5 (Stetefulset) どこに接続しても、Hash Slotに基づいて適切な masterノードにルーティ ングされる
  18. 18. Redis Clusterの課題 ・バックアップをクラスタ単位ではとれない。rdbファイルを各マスタで取得しておく形にな るが、リストアに関するベストプラクティスがまだなさそう? ・クラスタが自動でセットアップされるわけではない。デプロイ後、クラスタ初期化のとき や、ノードを増やす際には手動でコマンド実行が必要 ・こういった作業を自動化するKubernetesのフレームワークとしてOperatorがある
  19. 19. Operator Frameworkとは Kubernetes上で動くアプリケーションをパッケージ化し、デプロイ・管理をしてくれるフレー ムワーク Prometheus OperatorはBrandAIでも本番で使っている https://github.com/operator-framework
  20. 20. Redis Operatorを使ってみる https://github.com/spotahome/redis-operator helm install --name redisfailover charts/redisoperator kubectl create -f example/redisfailover/all-options.yaml 自動化されすぎて、ここまで来ると仕組みがわからず内部の実装を追うのもつらい。 ある程度実績が増えてきてこなれてこないと本番投入は難しい。
  21. 21. まとめ ・パフォーマンス要件の上限が見えているのであればSentinel (どうしても頭打ちになったら分割で頑張る) ・ひたすらスケールさせていきたいのであればCluster

×