January 29, 2020

Kubernetes Meetup Tokyo #27

はじめに

「Kubernetes Meetup Tokyo #27」のブログ枠です。
https://k8sjp.connpass.com/event/162343/

基本的に、meetupのまとめと出てきたキーワードのリファレンスです。

ハッシュタグ

#k8sjp

講演


1. Amazon EKSによるスケーラブルなCTR予測システムを導入した話 (30min) ysdtsy

やりたいこと

  • キャリア配信予約は、日次予約をする
  • その配信に合わせて日次で、CTRを予測をしたい。

課題

  • CTR処理は、1時間くらいで処理したいが、10億レコードで10時間程度かかってしまっていた。(1 instance)
  • 予測対象レコードは今後増え続ける

目標

  • 10億レコード、1時間。

そこで、なぜ、k8sを採用したのか。

  1. 機械学習システムの特有の問題があったため。
  • 環境の差異が大きい
    containerの高い再現性
  • 継続的な学習・デプロイが必要
    インフラ導入しやすさ(helm etc..)
  • 学習と推論の要求リソースを柔軟にしたい
    リソースを無駄なく、共有可能

処理の流れ

  • S3のNotificationでSNS->SQSへmesageを送る
  • SQS PodScalerで、SQSを監視して、Cluster AutoScalerがPodを配置する
    • Scale downはその逆。
  • 担当のパーティションとなっている特徴量ファイルをpodたちがそれぞれ処理し始める。

構成に関して

ノードグループ

ライフサイクル、要求リソースが異なる毎に、ノードグループを分けている。
e.g. 学習用, 推論用 etc…

構成検討
不採用

Kubernetes Job

  • クラスター外からjobをキックする必要がある
  • Parallelismがいまいち?
採用

pub/sub構成

  • jobのキックが受動的になる。
Auto Sacler

pod

  • Terminated Graceful Period Seconds
  • 勝手に終了すると、リスタートしてしまうので、SIGKILLを待つようにしている。

node(cluster)

  • 処理時以外は、capacity=0
  • ASGのmax nodeでチューニング
その他
  • Configは、外出ししてhelmで一元管理
  • どのようにModelを管理するか
    • 外部ストレージ管理にした
    • ただし、ビジネス要求次第で、コンテナ内に入れても良いかも。
  • EMRで前処理して、S3に特徴量データが吐き出される。

おわりに

再学習したモデルがヤバかったら、切り戻すみたいな感じになっている。事前にヤバイかどうかがわからないことが現在の課題。

2. Azure Kubernetes Serviceで実現する超低予算&(ほぼ)フルマネージド&本格的なWordPress環境 @noriyukitakei

概要

Azure Kubernetes Serviceで実現する超低予算&(ほぼ)フルマネージド&本格的なWordPress環境

上記ブログに関する講演でした。 ただのVMからAKSへ移行した話。

システム構成

移行前
  • VM x 2
移行後
  • Kubernetes
    • フロントエンド用node x 2
    • バックエンド用node x 2
    • NFS
    • Azure Database for MySQL

内容

  • WP Super cacheを使っている。
  • labelによって、配置するpodをどこのnodeに配置するか振り分けている
    • フロントエンド用node: label=user
    • バックエンド用node: label=admin
  • Azure Load Balancerを使っている
  • Azure Container Registoryを使っている。
    • 基本的には、Wordpressは公式docker imageを使えば良い。
    • しかし、一部pluginがpodが再起動すると消えていたので、docker の entrypoint を変更したものを使うため、ACRを使っている。
  • ライフサイクル
  • deployment.yamlには、Wordpressの環境変数がいっぱい。
  • Wordpressで使う画像・pluginは、mountしているNFSサーバーに格納している。
  • NFSが一番苦労した。
    1. Azure Filesを使ってみた。
    • レイテンシが高かった。1ページ開くのに、8s程度。
    • printデバッグしまくった。
    • phpのプラグインを読み取るところが原因だった。
    1. Azure NetApp Files
    • エンタープライズ向け。
    • レイテンシが低下して、よかった!
    • しかし、、、2日間で4万円かかっていた。。なぜ。。
    • 課金対象は、ボリュームではなく、容量プールだったことに気づく。
    • 最低4TiBから課金されるらしい。
    1. VM上にNFSサーバーを構築
    • 解決!(パフォーマンスもコストも)
  • 気になるお値段!?
    • 35,398円/月
    • 色々使っている割には、安いなと思っています笑

質疑応答

Q. nginx-controllerではなく、Azure Application Gateway ではダメか?
A. 乗り換えを実施していた前後に、Azure Application GatewayのUpdateがあって、改善された?ので、今後そうしようと思っています!

Q. NFSが障害発生した場合どうしようと考えていますか?
A. とりあえず、VM自体のバックアップをとって、何かあったらバックアップしようと思っています。

Q. Wordpressは攻撃対象になりがちですが、WAFとかの対応はどうしていますか?
A. 今後検討予定です。

LT大会


1. Kubernetes の Leader Election - @ponde_m

c.f. blog: Kubernetes Leader Election in Depth

  • リーダー選挙は分散システム内の、、、まぁよくわからないと。
  • 非同期のアーキテクチャ
    • Reconciliation Loop
      • 宣⾔した状態を維持するための仕組み。
      • e.g. Deployment Controller
  • 2つのcontrollerが動いている場合
    • もう一方が作ろうとすると、すでに作成しているので、AlreadyExistsとなる。
  • そこで、いずれかにLeaderを設ける。
    • それによって、競合を避けつつ、可用性を担保する
  • パターンは2つ
  • KubernetesではObjectで分散ロックをしている
    • Configmap, Endpoints

2. CloudRunが素敵すぎる件 - TakuyaTezuka

  • 色々なCloudが辛い件
    • k8s/istioのversion up問題が辛い
    • 稀に引くバグ
      • CNIとか。Istioとか。
    • セキュリティを考えると、Cloud Resourceをちゃんと面倒みないとダメ。
  • もう疲れてきました。(パトラッシュ!)
  • そこで、Cloud Run
    • Knativeのサーバーレス環境
  • 使い方
    1. GCRのイメージを選択
    2. プラットフォームとリージョン設定
    3. 認証設定
    4. リビジョン設定
  • メリット
    • インフラみなくて楽!
    • デプロイめっちゃ楽!
    • リクエストに応じて自動スケーリング!
      • 最小数が0になるので、そこだけ気をつける。
    • StackDriver Loggingも自動連携してくれる!
  • 課題
  • 最近の技術選定するときの優先順位
    • 1位: Cloud Run
    • 2位: GAE
    • 3位: GKE

3. AKSのDisk I/OのIssueの紹介とchaos-meshの紹介 - @genboku

  • 取り上げるAKSのIssueの説明。
    • AKSのワーカノードにユーザーが意図しない形でIOPSの上限値を「500」が設定されてしまう。
    • NotReadyになったり、、、
    • IstioやOperatorのパフォーマンス悪化と不安定
    • ワーカーノード-他のAzureサービス間のネットワークレイテンシの低下 etc…
  • Issueとしてあがっている解決策は
    • 札束で殴る or
    • Observabilityは重要という話。
  • とはいえ、複合的な原因の場合も多く、かつ、結果、プロバイダー側の問題ってなることがほとんどじゃね?
    • そんなのObservabilityを向上させたところで、解決できるわけないじゃないか。
  • そこで、Chaos-Mesh
    • TiDBと同じところが開発。PingCAP
    • カオスエンジニアリングのツール。
    • Pod-kill
    • Pod-failure etc…
    • Chaos Meshの紹介

4. 今から始めるオンプレミスk8s(Kind + IPv6) - @Kazushige_TAKEUCHI

5. Kubernetesを利用したエッジクラスタロボティクス分散システムの構築 - @FujitaTomoya

  • ロボットの話。
  • Robotics Operating System
    • ロボットやる人はだいたい知っているもの。OSSが盛ん。
  • 基本的な動きは、センシングデータをもらって、リフレクションする
  • ロボット間でダイナミックに繋がるようにしたい!?
  • node discovery
    • ロボット動くので、wifi圏外になったりするので、discoveryが必要。

さいごに

すいません。後半のLTちょいちょいわからないところもあって、うまくまとめられなかったです。。。特にSonyの方のROSのやつとかちゃんと理解したかったが、あまり理解できていないです。。笑
LTの方々の発表もどれもすごく面白かったです!スライドが公開されたら更新します。

(C) Jun Kitamura 2020

Powered by Hugo & Kiss.