見出し画像

2019-07-22 CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019 Day1 #CNDT2019 #OSDT2019

2019/07/22 に開催された CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019 Day1 のイベントレポートです。

●イベント概要
2019年4月、ContainerDaysはCloudNative Daysに名称を変え福岡からスタートしました。そしていよいよ7月に東京に戻ってきます! 今年はOpenStack Days Tokyo 2019との共同開催が決定。日本最大級のクラウドネイティブとオープンインフラストラクチャーの祭典へようこそ。


■Argoによる機械学習実行基盤の構築・運用からみえてきたこと

河野 晋策さん [リクルートテクノロジーズ]
稲村 秀人さん [リクルートテクノロジーズ]

●Argoとは
・workflowだけでなくツール群
  workflows, CD, Events, Rollouts
・argo workflows
  コンテナネイティブのワークフローエンジン
  k8s のCRD
  workflowの定義の中でGPU指定などもできる
  各ステップをコンテナで実装できる
・argo workflows 基本機能
  yaml定義を
  argo submit
  進行状況はCLIでもwebでも見れます
・argo workflows example定義
  リソース定義
  リソースフロー名prefix
  workflow定義
    イメージ
    コマンド
  python:alpineイメージで定義にsourceも書ける
  steps.ステップ名.outputs.result で結果も取れる
  -> githubでexampleがたくさん

●リクルートの検索チーム
・リクルートの各事業を横断
・不確実性を低減したい
  -> 機械学習アプローチ
・共通の基盤で学習させる
  -> 属人性を排除
・digdagを使っていた
  自前でk8sとの連携をつくっていた
  できないことが増えてきた
  -> 卒業へ
・比較対象
  digdag, airflow, stackstorm, argo
・構成
  オンプレGitLab
  Drone
  ContainerRegistory
  GKE
    argo, argo events

●使用案件例 ETLとして使う
・ユーザがどんな検索をしたか、どんな行動を起こしたか?
・構成
  adobe analytics
  -> BigQuery
  -> argo
  -> BigQuery
・workflow
  stdout
  次ステップでstdoutを利用

●使用案件例 検索ロジック重みチューニング
・構成
  BigQuery
  -> argo
  <-> CloudStrage
・workflow
  paramで引き渡し
  artifact機能でcloud strageへ

●使用案件例 累積報酬最大化、最適ロジック識別
・バンディットアルゴリズム
・構成
  BigQuery
  -> argo
  <-> Cloud SQL
  -比較結果-> EC2
・workflow
  retryStrategy
  exit hookでslack通知

●使用例CI/CD Pipeline
・GitOps
  argo CDのベストプラクティスにまとまってます
・Argo CD
  複数クラスタへのデプロイに対応
  同期状況が画面から見れる

●Argoを使用する上でのTips
・1step 1transactionを心がける
  rerunしやすい
  切り分けしやすい
  ロールバックを見つけやすい
  -> podになるので、オーバーヘッドはかかる
・案件ごとにnamespaceを分ける
  kubectl get podsで大量のpodが返ってくる
  ハウスキープは書けるとしても、多すぎ
・CPUでクラスタ作成、default-poolとは別にGPUノードを作成
  STEPのresourcesでGPUを指定できる
  affinityなどで、明示的に指定もできる

●Argo Events tips
・概要
  k8sイベントベースの依存関係マネージャ
  依存解決後にworkflowをキック
  スケジュール
    ConfigMapで定義
    Sensorで指定
    Gatewayで依存解決&実行
・同じ名前でgatewayデプロイすると上書きされる
  -> 案件で分けておくとかぶりにくい
・yamlを3つも書く
  コピペで量産されてしまう
  -> helm chartで自動生成
    configmap, gateway, sensor, rbac

●Argo CI/CD tips
・承認フェーズ
  suspend機能
・別コンテナも合わせて起動
  dindするならsidecarsで定義
  initContainersもできる
・結果を利用した並列実行
  withParams
・設定の宣言的な管理
  Application Of Applications Pattern
・複数環境への同期
  helmで環境ごとに

●運用から見えてきたArgoのツラいポイント
・UI
  filter弱い
・Eventsのエラーハンドリング
  実行されるまでログが出ない
・workflowのテンプレート化が機能として提供されていない
・ワークフローの途中から引数を変えて実行ができない
  -> githubで議論中


■Kubernetes拡張を利用した自作Autoscalerで実現するストレスフリーな運用の世界

山本 まゆさん [CyberAgent]

●プロダクトの紹介
・GVA
  動画広告の配信プラットフォーム
・利用サービス
  Cloud Pub/Sub
    Topic, Subscriptionを登録してメッセージング
  Cloud Bigtable
    node単位でスケール
    Autoscaleはない
・アーキテクチャ
  publisher
  -> Cloud Pub/Sub
  -> Subscriber
  -gRPC-> service
  -> Bigtable

●自作AutoScalerが必要になった背景
・BigtableのNode数を人力でスケールイン・アウトさせていた
・起きていた問題
  Pub/Sub
  -大量-> Subscriber
  -大量-> Bigtable
・プログラムからBigtableをscaeする方法は公式にある
  が、自作が必要だった
・autoscale
  BigtableのCPU使用率でトリガ
  k8sリソース状況(subscriber)でトリガ
  リクエスト数からトリガ

●Geminiの概要と実装
・k8sのCRDを利用
・scale設定
  CRD
    ResourceTypeをj作
    独自のマニフェストファイルを使える様になる
  CustomController
    Custom Resourceと組み合わせて
    Reconciliation Loopを実装
・メトリクスの時系列データ取得
  stackdriver monitoringと連携
  アラートポリシーの値を取得
・スケールロジック
  スケールアウトは早く、インはゆっくり
  スパイク判定、前回スケールからの経過時間をコントロール
・時系列データの解析
  ノイズが多いので移動平均(SMA)でスムージング
  windowsサイズの調整
    前に偏るので、バランスを見る
・開発の詳細
  CustomControllerはSDK使用せずにフルスクラッチ
    2018/06当時、情報が少なかった

●実際の運用結果
・人力スケールはほぼゼロに
・良かった点
  スパイク判定、独自スケール判定基準の導入が柔軟
  スケールトリガーを追加できる
・苦労した点
  contollerのスケールロジックが複雑
  スケールロジックは改善に手間がかかる


■adtech studioにおけるCRD〜抽象化したGPUaaSによる段階移行計画 & AKE Ingress v2〜

青山 真也さん [CyberAgent]

●k8sの使いみち
・コンテナ/アプリ実行基盤
  何をどれだけ使うかを定義
・X as a Service基盤
  どんな構成でつくってほしいかを定義
    mysql-operatorなど
  小さなクラウドに近い
  エコシステムが強くなってきている
・分散システムフレームワーク
  Controller
    Reconcile Loop
      Observe -> Diff -> Act loop
  -> 運用ナレッジをプログラム化、自動化

●GPU as a Service
・動画の研究開発をしている
  4GPU on 1物理マシン
  -> k8s with nvidia-docker
    ちょっと100行くらいのyaml書いてくれれば動くよ
・MLTask CustomResource for GPUaaS abstraction
  どのイメージを使うか
  どのトレーニングデータ
  どこにモデルを出力するか
  -> 定義内容から StatefulSetを管理
    kustomizeとかでも作れるが
    S3とオンプレのファイルキャッシュなど
    考えることが増えるとControllerが必要
・段階移行
  StatefulSet + Headless Service

●AKE Ingress v2
・詳しくは明日のセッションで!
  OpenStack Heatを組み合わせたりしてます


■Knativeで実現するKubernetes上のサーバーレスアーキテクチャ

杉田 寿憲さん [メルペイ]

●Knativeとは?
・サーバーレスのワークロードをビルドでプロイする
・k8sのリソースを抽象化
・PaaS/FaaSを構築するパーツ
  knative自体でPaaS/Faasではない

●knativeの構成要素
・Serving
  コンテナのデプロイ、オートスケール
  Revision
    コードと設定のスナップショット
  Configuration
    最新のrevision
  Route
    Revisionへのルーティング
  Service
    Foute, Configurationを管理
  Autoscaler
    Revisionへのリクエストを管理調整
  Activator
    0のときに動く
  Glooも使えるが、全機能だとまだIstioだけ
・Build
  ソース->コンテナイメージ
  templateもたくさん
  teketon
    knative/build-pipeline -> teketon
  v1.0でknative/buildをアーカイブ予定
・Eventing
  イベントドリブンなアーキテクチャ
  Source
    event Source
  Broker
    eventを受け取る
  Trigger
    フィルタ
  現在のverだと Channel, Subscription は内部実装でいじれない

●k8sのコンセプト
・あるべきリソースの状態を、宣言的に定義
・あるべきリソースの状態を、維持し続ける

●Knativeの構成
・カスタムリソースとカスタムコントローラ
  k8sネイティブな拡張方法

●サーバーレス
・定義はバラバラ
  BaaSやFaaS上で一時的なコンテナで実行されるアプリ
  どの様に構築されるかのアプローチ
  など
・開発者、運用者がビジネス価値に集中できるようになる は共通

●ユースケース
・1: コンテナのデプロイ
  URLでアクセスできるサービスをより楽に
・2: オートスケール
  リクエスト数に応じてオートスケール
  スケール具合を可視化
  demo
    heyでリクエストを並走
    デフォルトのwindowは60sec
    パニックモードで柔軟に
・3: トラフィック分割
  新実装へのトラフィックを徐々に増やし、影響を見ながらデプロイ
  demo
    Configurationで制御
    Routeで、Revisionを指定
    Configuration変更で、新たなRevisionを作成
    Routeで、新しいRevisionを追加
      ※traffic 0% でエンドポイントをつくるならtagを指定
  -> 手順が複雑なのでCI/CDなどで
・4: イベントエコシステム
  特定のイベントが発生したときに処理を実行
  cloudevents すでにSDKが出ている
・5: ビルドパイプライン
  tektoncd
・6: FaaS イベントpull型
  serving + build template
  AWS LambdaのCustom Runtimesを実装
・7: FaaS イベントpush型
  OpenFaaS
  revisionの中にwatchdog
  リクエストをfunctionにわたすサーバは準備
・8: コンテナサーバーレス
  Dockerfileは書いてもらう


■RELEASE FAST OR DIE: DevOpsを加速させる Universal Artifact "JFrog Artifactory Platform"のご紹介

田中 克典さん [JFrog]

●JFrog
・概要
  2008 イスラエルで立ち上げ
  DevOpsのリーディングカンパニー
  Liquid Software
  DevSecOps 7コンポーネント
  社員 450+
  拠点 6ヶ国
・ミッション
  新しい技術がでて利用者は増えるが
  つくる側の人が足りない
  ここをサポートする
・Liquid Software
  予想不可能な状況に対応するには
  継続的に小さな変更を加えていく
  日本語翻訳中!

●Enterprise+
・Artifactory
・Xray
・Disribution
・Access
・Insight
・MissionControl
・Pipelines ※プレビュー

●伸びている理由
・Cloud, Muti-Cloud, Hybridに対応
  GCP, Azure, AWS
・出てきた技術すべてをサポートする

●強み
・Enterpsise Grade HA
・DevSecOps
・24/7 Support
・DevOps Consulting

●DEMO: Artifactory, Xray, Pipelinesの連携
・eclipse artifactory maven plugin
  artifactoryにmvn deploy
  直後に Xrayで脆弱性とライセンス違反を検出
  artifactoryの画面から検知できる
・pipelines
  yamlで定義
    fork, joinも定義できる
    docker build, tag, push
  直後に Xrayで脆弱性とライセンス違反を検出
  artifactoryの画面から検知できる

●今後の活動
・マクニカグループと連携
・jfrog.co.jp で情報発信中
・8月からwebinar開始
・10/15 JFrog Japan Meetupを開催


■メルペイのマイクロサービスの構築と運用

高木 潤一郎さん [メルペイ]

●メルペイ
・コンビニなど外のお店で決済できます
  iD、QRコードなど
・サービス規模
  40+のマイクロサービス
  クォータで1444億円

●なぜマイクロサービス?
・はじめはモノリスではじめましょうと言われる
  複数のサービスを短期間で立ち上げたかった
  組織の拡大、機能を並列で開発
  依存関係も見えていた
・メリット
  リソース管理がスケーラブルで柔軟
  障害が局所化するので可用性が高まる
・サービスごとの技術選択はしていない
  共通のツール・ライブラリ
  全体の品質を上げたい
  情報共有や、人の異動を可能に

●アーキテクチャ
・共通のGKEクラスタ
  全部のマイクロサービスが載っている
・個別のProject
・レイヤーアーキテクチャ
  API Gateway -> API Service -> それぞれのロジックへ
・GKE
  Cluster
    Platform Teamが構築、運用
  Namespace内
    Project Teamが構築、運用
・1サービス : 1GCP Project
  Project内にSpanner, Pub/Sub
・階層構造
  Client
  -> API Gateway
  -> API Service
  -> BackendService
・API Gateway
  Goのマイクロサービス
  リクエストをルーティング
  Cloud Load Balancerと組み合わせて実現

●開発組織とマイクロサービス
・機能を実現するマイクロサービス開発チーム
  1チームが関わるサービスをまとめてみる
・共通基盤とサービス全体をみる横串チーム
  SRE、アーキテクチャなど

●気をつけていること
・一貫性
  分散システムでデータ一貫性の担保は難しい
  どこでエラーが起きてリトライしても冪等に
  -> 詳しくはメルカリtech blogの記事で
  リコンサイル
    データの整合性が取れているか?
    不整合を見つけて修正する
  -> バッチ処理、非同期な結果イベント通知でキック
・信頼性
  ほとんどのサービスがGo (一部 Node.js)
  マイクロサービステンプレート
    gracefulシャットダウンなど
  共通ライブラリ
    分散トレーシングなど

●レビュー
・DesignDoc
  作る前に、各ロールの人が集まって検討
・Production Readiness Checklist
  リリース前に設定、運用の準備などをチェック
  HPA, PDBなど

●開発を加速する共通のしくみ
・Microservices platform
  starte-kit で初期化
  protocol buffersでIF定義
  terraformでGCPのリソース管理
  など
・アプリのデプロイ
  Spinnakerでgitopsライク

●マイクロサービスの運用は大変
・サービスの数だけ要素が増える
  アプリ、リソース、通信
・手間を減らすしくみ
  構成をできるだけ揃える
  k8sのオートスケール、自己修復
  managedなサービス
・各マイクロサービス担当が運用
  運用経験があるエンジニアは少ない

●気をつけていること
・SLOを設定する
  今正常なのか?
  遅い?
  一瞬跳ね上がったCPUは問題ない?
  -> 基準が必要
    99.99%のリクエストが 5xx 以外を変えている など
    alertするか?すぐ直す必要があるか?
    などの判断基準になる
・Observability
  どこでどれだけ時間がかかっているか?
  なぜ時間がかかっているのか?
  SLOを満たしているか?
  -> 統一が必要
    バラバラだと、調査方法もバラバラ
・監視体制
  Datadogに集約
    Timeboard、APM、Monitor
  クリティカルは pagerduty
  そうでもなければ slack

●出てきた課題
・一部のサービスがモノリス化する
  楽なところにロジックが集まりがち
・QAが難しい
  サービスのバージョンの組み合わせ
  いつもどこかのサービスが壊れている
・運用と開発のリソース調整
  落ち着いたサービスと、これから活発になるサービス

●今後
・サービスの信頼性を高めて運用負荷を下げる改善中

●遭遇したトラブル紹介
・Deploy時にリクエストの一部がエラーになる
  新しいサービスをデプロイしたときだけタイムアウト
  対応
    graceful shutdown
    readness/libeness probeの適切な設定
  他にも
    k8s、GKEでの設定を調整
・Ingressの再作成に失敗
  Ingress-GCEを使っている
  開発環境のIngressを作り直したら
    External-IPが当たらないなど
  GKE v1.10.6 のバグだった
  -> たくさん作って、うまくいくのを使っていたw
・Ingressを追加したら、既存のIngressが壊れた
  設定していた証明書と別の証明書が設定されている
  調べても、サポートに聞いてもわからず
  2つのIngressがHTTPS proxyを交互に更新
  Namespace名 + Ingress名 の先頭55文字で決まる
  -> 短い名前に & バリデーション
・Podが減っていく
  5のハズが3、他はrestartを繰り返している
  リスタートしたら全部壊れてしまうかも
  起動時に必要なGCPのAPIがdisableされていた
・SpannerへのLatencyがときどき大きくなる
  クライアントライブラリ、k8sクラスタのDNSなど
  原因は複数
  tech blogにまとまってます


■感想

knativeなどのOSSや情報が揃ってきたからか、CRDの敷居下がってきた印象を受けました。k8sの用途として、分散システムのフレームワークというのも選べるようにしておきたいですね!

最近、機械学習とセットでargoの事例を聞ける機会が増えてきました。GPUをゴリゴリ使う案件は周りにないですが、k8sと連携するworkflowとして自由度が高そうなので使いはじめてみようと思います。

ライクも含めてGitOpsが普及してきましたね!
CI/CDの話になると
・リポジトリを app/config で分割
・app の image push -> configポジトリへPR
・config のgit pushで実行環境に反映
はセットで聞くことが多い気がします。git flow, github flow, gitlab flowでどれが良いか議論していたのは遠い昔に感じますね。。。

登壇者の皆さん、運営の皆さん ありがとうございました!
明日も楽しみです!!


■Day2の様子



この記事が参加している募集

いつも応援していただいている皆さん支えられています。