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の様子