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の様子
この記事が参加している募集
いつも応援していただいている皆さん支えられています。