Event - CloudNative Days Tokyo 2019

wiki, tech, tech, event
Page content

CloudNative Days Tokyo 2019 の参加メモ

CNDT - Cloud Native Days Tokyo 2019

  • 日: 2019/07/22-23
  • 場所: 虎ノ門ヒルズ森タワー

overview

  • 公式サイト

    • スケジュールから詳細を見れる。リンクされている twitter アカウントから探すと資料公開されている率が高い。（スポンサー枠のプレゼンテーションは結構無いかも？）

  • google spreadsheet 版タイムテーブル

  • 事前にセッションも申し込みが必要だし、満席になるので早めの申込が必要

    • でも当日厳密に管理されているかというとそうでもなく、結構入れてしまいそう

  • 感想

    • openstack days のほうが先に始まったらしいが、今や cloudNative days のほうが活発な様子
    • k8s の話題だらけは辛い. k8s 自体のメンテをやる覚悟はないので…
    • cloud native 系の技術トレンドは CNCF landscape とかから追うと良さそうというのが分かったのは良かった。（というくらい体系的知識がなかった）
    • ストレージやDBの領域まで k8s 管理を試みる系の話題が意外と多く感じた (まだスタンダードが固まらないフェーズ)
    • Operator という概念が多く語られていた (k8s の運用管理を楽にする仕組み達の層)
    • よく引用されていた言葉:

      ‘Kubernetes is becoming the Linux of the cloud’ - Jim Zemlin, Linux Foundation #GoogleNext17

    • serverless は riotz works の方たちが相変わらず使い倒している様子をupdateしてくれるのと、 Knative の話題が出たくらい。 majority ではない。

  • 資料リンク集

day1 2019/07/22

K1: keynote

Collaboration Without Boundaries by openstack foundation

  • cncf projects: graduated, incubating, sandboxというカテゴリ
  • cloud native landscape
  • related events: kubecon, cncf summit

airbnb

  • 70% k8s.
  • migration strategy

canonical (ubuntu): 10 rules to do for cloud native OSS

  1. consume unmodified upstream
  2. infra is a Product
  3. automate for day 1826 (= 5yrs) 先が予測できないからこそ. 事例DeNA: livepatchでリブートなしにパッチ当て
  4. run at capacity on-prem, use public cloud for overflow or DR etc.
  5. upgrade, don’t backport (tech debt). やるとそれはプロダクトではなくなってしまう、同じ使い方の人がいなくなってしまう、craftedになってしまう
  6. workload placement matters. 何か起こった時の分析はいつも難しい。app and infraの連携がわからないとむずい
  7. plan for transition. 必ず何かの移行が発生する。それを意識した設計をする. agilityを備えるとか
  8. security is not special. セキュリティを普段から設計に意識しておく。最初から作り込んでおかないと。後付けで考えてはダメ
  9. embrace shiny objects (新しいキラキラしたものはどんどん取り入れる努力を
  10. be edgy, go Micro!
    snap install microstack —beta —classic
snap install microk8s —classic

Serverless and kNative (IBM): demand less choices skip

1D1 OpenStack community の現在と今後

全般

  • 用途: 75% on-prem
  • current release version: Stein
  • openstack summit参加者数は落ち着いてきた。必要な数に落ち着いてきたという感触だそうです。
  • development: T
  • support ipv6-only deployments
  • project docs: enabling pdf generation
  • update py3 test support

有効メジャーバージョンのメンテナンス状況

  • maintained: QRS
  • extended maint: OP
  • release cycle: 6mth

Long Term Support について

  • LTS は upstream では行わず、 distributor に任せている
  • release cycle をゆっくりにしてくれとか要望はコンセンサスに至らず
  • Fast Forward Upgrade : skip upgrade はせず、早回しで N -> N+1 -> N+2 とupgradeとするようになった（どこが工夫点？）

その他キーワード

  • open infrastructure
  • upstream training では upstream へのコントリビュートの際のいろはを教えてくれるそうです

1D2: Circle CI 2.0 を支える2つのコンテナクラスター

一番話が面白かったというか、聞きたい内容・レベルだった。

  • 資料
  • ポイント: circleCI2.0: 完全コンテナベース (1.0 は巨大なモノリスだった)

2つのコンテナクラスター

  • services (k8s): frontend, billing, user administration, webhook, etc.
  • executions (nomad): docker pull, code checkout, build, artifact保存

k8s もともとclosure という言語で巨大なモノリスだった。2.0開発でmicroservice化した。 自前でEC2上でterraform使って作ってる, サービス間通信はgRPC, RabbitMQ

  • 通信は基本的に非同期にしている -> RabbitMQ
  • 同期的通信は gRPC でやってる. build log の streaming とか。
  • k8s on ec2 の問題点
    • master node mgmt (etd, coreOS管理)
    • 認証・セキュリティ (pub API endpoint safety, user administration)
    • アップグレード (coreOS, k8sのバージョン間依存やその検証)
  • いま Amazon EKS への移行を検討している
    • master は自分でアップグレードしないといけないのが現状の課題

Nomad (circleCIのほとんどのリソースはこちら）

  • hashiCorpが作ったもの
  • k8s の master, worker を server, client と呼ぶ
  • 採用理由: batchがk8sより得意だった, シンプルアーキテクチャ, hashicorp toolとの親和性, mesosは複雑で断念, bug少なめ
  • scaling: datadogモニタリング -> autoscalerサービス -> AWS AutoScaling Group

SRE チームの紹介

  • インフラ安定運用、問題調査等を担当。
  • 分散したチーム. boeing 777 製造のチームワークが似ていると思っている。時差の有効活用, 継続的なペアリング、障害対応
  • 障害対応体制: incident commander, communication commander, incident response team, note taker. 役割分担はほぼボランティアでその時に決まる。
    • communication commanderだけは大体決まっている（広報的仕事を求められるため）。 customer success engineers が担当
    • 20min に1度はupdateする
  • SRE clinic (≒病院) 始めた
    • 週ごとのローテーションでToil (雑務) を集中して潰す
    • 他の人は生産的な行為に集中できるようになる
    • toilじゃなくてもclinicに相談が集まりがち

8/21 circleCI webinar!

1B3: cloud native storage が拓く database on k8s の世界

psql on k8s を色々やっている人 資料

概要

  • Amazon Aurora DB を見ていると Kubernetes をDBクラスタリングにも応用できる可能性があると思っているのが今日の本旨.
  • コンテナは stateless にしてDBはマネージド等を使おうというのが定石だと思っているが、その先の世界への挑戦という感じ。 すぐ使うわけじゃないが、DBの深いところを理解する取っ掛かりになりそうで興味深かった。

memo

  • HAの中ででてきたfencing: 強制的にリソースを開放するための手段ぽい
  • replicationパターンの課題: マスターが複数になってしまう現象。対策はリーダー選出. リーダー選出のアルゴリズムは Paxos, Raft などが有名
    • 共有ストレージがないので好まれるパターン
  • shardingパターン: 対象外性を高めるのではなくスケーラビリティを高める目的のもの。 coordinator というのが手前に立って read/write を振り分けるぽい
  • productionではきっと sharding x replication の組み合わせが良いんだろうなぁ。

k8s 上での実装例

  • RookでHA: Cephむずい、ストレージとの通信がNW越しなので遅い
  • LinStor + DRBD: 構成はシンプル、性能面でも優れる, ただしスケールに限界
  • Stolonでreplication: 結構古い. proxyが振り分け、 sentinel がリーダー選出, 共有リソースなし,
  • DB on k8s のさらなる課題

今後の k8s 上のDBプラットフォーム

  • Software defined Storage や fencing などの部品が揃いつつ有り、DBクラスタリングが k8s native になってきた
  • aurora, azure hyperscale の兆候: WALのような transaction log をDBサーバはストレージサーバに投げる、分離されるのがトレンドぽい？
    • DBaaS と STaaS (storage) に分離されそれぞれが k8s cluster で管理される未来が来るかも。

1D4: k8s とアプリをつないだ可視化を実現しよう(new relic)

  • cloud native な時代の監視: いままでは対象appにリソースが足りているかの監視をしていたが、cloud native な世界ではどこで起動しているかもわからない、MSAでは対象が多い、などなど。各コンポーネント単体の状態を見ていてもダメで、コンポーネント間の関係性を見ないといけない（分散トレーシング）とか色々有る。
  • observabilityのことだね。
    • OSSでもできるでしょ？→yes, but それぞれ得意分野を持っている。統合的に見るのは難しいか一手間がある
      • prometheus であれば grafana を使って可視化するとか
    • だが「作るのではなく買う」という選択肢もある（see 書籍「入門 監視」）

new relic というソリューション

  • いろいろな指標・見るべきポイントを統合して把握できる。
  • 利用開始もとてもクイックらしい
  • 主なユーザ: IBM, paypay

Knativeで実現するKubernetes上のサーバーレスアーキテクチャ #CNDT2019 #1E3 / serverless architecture on the top of K8s with Knative

資料

Knative 概要:

  • Knative 徹底解説 概要編

    Knativeは、クラウドにおけるPaaSやFaaSのようなアーキテクチャを、Knativeがインストールされていれば(つまり、Kubernetesクラスタであれば)どこでも実現できるものです。

ほか

2019/07/23

K2 keynote

rakuten

  • フィールドトライアル中: 三木谷さんほか幹部が玉川沿い歩きながらviber使ってるところ紹介されてた
  • GC bldg (pre-aggregation): 4000,
  • AP Controller : 普通は手動、自分たちは OpenStack から API 叩いて自動で VLAN -L3 の設計・設定を行うようにしている
  • all ipv6 based
  • core: tokyo & osaka (DR)
  • HW選定: 従来10種類以上のHWで構成されるのを、1つにしている。オペレーションコスト削減
  • 10分で1個のサイトを論理的に組込完了できる
  • cisco の VNF manager を採用
  • test automation
    • Rakuten Innovation Lab で商用完全再現する。
    • ベンダーに試験させ、達成したら次のテストステージに進む

SB payment service 決済代行システム内製 by 鈴木さん

  • 内製化に至る道程
    • サービス開発は全部ベンダ任せ、コードを書く自社エンジニアは0
    • まず運用支援ツールの内製化
    • 3人メンバーがついて、その後監視ダッシュボードを elastic* x kibana で追加
    • 開発プロジェクトの支援を開始
      • Spring based のモダンな開発・運用を導入
      • 更に1人join -> エンジニアチームの立ち上げ、 …, そして本題の決済代行システムの内製を開始
    • 規模
      • 111,xxx店舗, xx億円, 加盟店ともAPI連携必要
      • +1 engineer joined
  • pivotal cloud foundry 選択の理由
    • k8s or PaaS … 学習コスト、メンテナンスコスト、少人数ではプラットフォームまで見るのは断念した. 実績あるプラットフォームがほしい
    • AP 4人, PF 2人の分担
    • metrics, logging, tracing の observability の話, dashboard 化
    • 加えてビジネス目線のダッシュボードも作成

YJFX

  • アプリケーション内製。
  • openstack supported by redhat
  • 変わることはリスクではなく、変わらないことは緩やかな死である。
  • すごく自分たちに響く話だった気がする

redhat 北山さん

Operator の話

  • 運用の知見をコード化し、アプリケーションの運用を自動化する

GMO の OpenStack, 外注なしの開発体制

  • 2012くらいからどんどん OpenStack を導入している

2B1 GMOペパボ cloud native を目指した230日

background

  • baremetal だった。
  • 仮想化しても人が介在していた
  • 人の介在をなくす仕組みが k8s 似合ったため、選択した

k8s 導入

  • まずは検証環境に作った

nginx-ingress ていうのが気になった。 L7 LB?

2B2 IBMのハイブリッド・マルチクラウドの未来

3 topics

  1. hoge (忘れた)
  2. k8s
  3. demo

2A4 zozotown の cloud native journey

https://www.slideshare.net/ToruMakabe/zozotowncloud-native-journey

zozoがクラウドジャーニーを歩み始めた件

  • 2004年からずっと同じアーキテクチャで規模を拡大してきた
    • 魚に例えて、出生魚のようだ。
  • これを更に強化するのではなく、！
    • Swimmyの世界（でたぁ）
  • 疎結合化、自立分散化プロジェクトが立ち上がった
    • scalable, MSA
    • multi-cloud, inter-cloud

現在は scalable monolith!

  • 3桁台のアプリケーションセット under the same LB
  • モノリスのメリットはある。
    • 少人数で立ち上げるには良い
    • パフォーマンスも上げやすい
    • 把握しやすい
  • しかし、 zozo の今の規模ではデメリットが多い
    • 障害, 運用作業 の影響範囲
  • oreilly new publication: monolith to microservice
    • これ1択！といえるパターン: Strangler Application Pattern

multi-cloud

  • 別クラウドで全く同じ環境、設定はあえてやらない
    • できないのも有るだろうが、やらないのは理由がある
    • ヒューマンエラーありきで、全部が同じ設定だと同じエラーで死ぬ可能性がある。だからあえて別にする。
  • 設計思想だけ同じにする
  • inter-cloud failover とか最後にやりたい。 inter-cloud load balancing もやりたい

いままで zozo は閉じてやってきた。これからはオープンにやっていく。

MSの人から answer song

  • gateway, frontend から作る。 k8s 使いたいとかはあと

  • OSS へのコミットメント: helm, open policy agent etc.

  • hashicorp, redhat との協業 … terraform!!

  • azure front door

    • cdn, ddos prot, waf 等を統合したもの. backend agnostic!

  • observability 標準化

    • 分散トレーシング: OpenCensus (OpenTelemetry)
    • Metric: prometheus exporter 向け agent

  • cost 一元管理: AWS も一緒に見れるらしい

まとめ

  • 個人的には multi cloud 歓迎
  • cloud native を盛り上げていきましょう。
  • 振り返りイベント有るらしいよ

2A5 microservice運用における最高のDX

https://speakerdeck.com/kenjiszk/microservices-vs-dx

  • DXは継続的な改善、取り組みが必要で、 街で割れたガラス窓が有るかどうかのようなもの（1個でも割れていると治安が悪いとみなされて結局全部割られていく、みたいな）