Cloud Native Days Tokyo 2019 - 2019-07-22

next day

links

今からでも遅くない！アプリケーションエンジニアが知っておきたい、Dockerコンテナの基礎知識 / The Basic of Docker Container for Developers - Speaker Deck

理想的なマイクロサービスアーキテクチャを目指す継続的改善 / Re-architecturing of Microservices CNDT2019 - Speaker Deck

k8s - Kubernetes 8 Factors - Speaker Deck

Kubernetesクラスタの自動管理システムのつくりかた - Speaker Deck

Kubernetesを拡張して日々のオペレーションを自動化する - Speaker Deck

Rancherで始めるCloudNative!! Hands-on編 - Speaker Deck

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

KubernetesでJVMアプリを動かすための実践的ノウハウ集 / JVM on Kubernetes - Speaker Deck

Operator でどう変わる? これからのデータベース運用 / cndt2019_k8s_operator - Speaker Deck

Actor Model meets the Kubernetes - CNDT 2019 - Speaker Deck

CircleCI 2.0を支える2つの コンテナクラスターとSRE - Speaker Deck

CloudNative Days Tokyo2019 - Speaker Deck

Prometheus setup with long term storage - Speaker Deck

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

@CloudNative Days Tokyo / OpenStack Days Tokyo 2019 / cndt2019-ca-k8s-gpuaas - Speaker Deck

CNDT2019 Cloud Native Storageが拓くDatabase on Kubernetesの未来 - Speaker Deck

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

k3sで作る!軽量k8sエッジコンピューティング環境 - Speaker Deck

失敗しない！Kubernetes向けストレージ選び5つのポイント - Speaker Deck

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

ウエディングパークにおけるコンテナ化方針決定までの道のり - Speaker Deck

Bifrost standalone Ironic を使ったGPU基盤構築運用への適用についてGMOインターネット株式会社郷古直仁@naoto_gohko

Mackerelチームのコンテナ開発における戦略とこれから / 190722-cndt2019

OpenStackSDK with Ansible

※ ★はあとでよむ

K1基調講演／スポンサーセッション

Day 1 Keynote Opening / Collaboration Without Boundaries(OpenStack Foundation) / Performing Infrastructure Migrations at Scale(Airbnb) / The 10 new rules of open source infrastructure(Canonical) / Demand Less Choices!(IBM)

長谷川さんより

CloudNativeとは？

CloudNativeDefinition v1.0 (日本語訳)

→ スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらすこと

+ Native

→ クラウドをネイティブに使おうね

CloudNativeTrailMap

→ CloudNativeに進めるためのステップ

アンケート（1354人中）

46%の方が本番環境に利用している。

開発環境は85.8%。

Contributuion (StackAlytics)

Commit数 (過去180日)

→ Google 4148, Independent 3718, red hat 418, planetScale 287,

まだまだ足りない。

kubernetes, openstackのアップストリームトレーニングを開催

→ 知らなかった。

Statistics

クラウドネイティブ技術を導入している環境(n=1354)

AWS (577), GCP (335), Azure(163)

Onpremises (Openstack, VMWare)も増えてきている。（数字忘れたけど、数百程度）

Number

+1600 Registration

+ 50 Sponsors

+ 90 Session

多いな！スポンサー！

→ CloudNative Computing Foundation, OpenStack Foundation. の２つがコラボした点が大きいのかな？

Linux Foundation フクヤスさんの登壇

CNCF projects (40ものソフトウェアがホストされている）

Graduated (成熟)

Incubating (成長中)

sandbox (検証中)

CNCFを協賛している企業が400+もあるみたい。18企業はプラチナメンバー。

(アリババ,aws,applegoogleCloud,IBM,Azure,Oracle...)

CloudScapeLandScape

→ CloudNativeに関わるロゴがある。1000を超えるロゴがある。

日本だと、Fujitsu, NEC, Yahoo, SAKURA...etc (17の企業数。少ないね。)

どこの国が多いんだろ？

88 Certified Kubernetes Partners

kubernetesからcertificateした企業さん。

日本企業はない。

certified kubernetes administrator (8300), developer(2800) という開発者向けの資格もあるみたい。

certifiedされると、kubernetes certified service providers に登録される。

１企業に3人以上のエンジニアがいる。日本では３社。

KubeCon, CloudNativeCon (2019-11-18~21)

がある。行ってみようかな。英語勉強の締切が決まるし、頑張れる気がする。

フクヤスさんEnd〜

マックレオンさん？ OpenStack.

（翻訳準備中...)

OpenStackのSummitは、最初NTTの方が来ていただいた。

OpenStackのMeetUpも始めった。

→ ミドクラさん、スタートアップの企業でOpenstackに力を入れた人？

→ 仲良くなるため、Karaokeして、頭ネクタイ。（笑）

9years、色々な国に巡ってコミュニティ参加のお願いをしていた。(200万キロの移動）

→ 国境を超えてコラボレーションは可能。企業関係なしにコミュニティを参加できる。

→ 一番良いアイデアがつまったコミュニティになる。

国境を超えた開発の良い例の１つが、ヨーロッパのセルン。物理化学の研究でOpenStack,Kubernetesを使用。

研究で使用するデータが膨大すぎるため、ハードウェアに収まらず、クラウドにおくようにした。（？）

2015年でもOpenStackSummitをTokyoで開かれた。(?)

10万を超える人がOpenStackのコミュニティに参加している。

19回のOpenStackをリリースしている。

世界中で動いているので、今も誰かがコミットしている。

Top 3に入る。(コミュニティのことかな？）

openStackは、32% public, 35% HostedPrivate, 33% Internal Private.な環境で使っている。

へぇ。パブリックが多いと思ってた。

Cloud&Heat

→ サーバの熱を暖房（？）に活用している。面白い。

Open Design, Development, Community, Source.

OpenStackはKubernetes, Ceph, TensorFlow等のソフトウェアと連携しやすくなった。

例えば機械学習でも OpenStack,Kubernetes,TensorFlowの組み合わせで開発していることが多い。

マックレオンさん？ (End)

メアニーさん Airbnb

マイグレーションのスケービラリティ高くするためにはどうしたらよいか？

インフラエンジニア。

なぜマイグレーションが必要なの？

→ tech deptが悪化する。

セキュリティリスク、トラフィック、ユーザーが増える。つまり効率が悪くなる。TechDeptが増える。

上手くマイグレーションするのは？

→ 1.マイグレーションを分類する

→ component (SecurityPatch), system(CI/CD), infrastructure (Kubernetes)

マイグレーションをする際は、順番を考える必要がある。

→ 何がどう依存しているのか？

カスティーディングマイグレーション

k8s migration -> migration to cloud -> migration to containers

Airbnbの場合も同様。

マイグレーションの分類→順番→依存性の順。

Securityリスクが低いもの等並行して進めれるものもあると良いよね。

優先度も決めてね。

コードのリファクタリングもマイグレーションで解決する。

大規模なマイグレーションをする場合、数が多いので複雑で終わらない。

→ どれぐらい負荷や余裕を見て、検証＆仮説を長期的にする。

マイグレーションツールとして、サービスジェネレータを使って楽にした。

run, migration, maintenanceのオーバーヘッドがある。

理想は、90%のプロダクトコード開発、10％の技術的負債の解決。

現実は、10%のプロダクトコード開発、90%の技術的負債の解決。

むむ、終わらない。

service-manifestをabstractionとして、環境に応じて変えていきたい。

Validate Phase

本当に使える状態なのか検証するフェーズ。

prototype

stress test with early users

Enable Phase

大規模なシステムで使えるようにするフェーズ。

たくさんのドキュメントを作っている。

Finish Phase

マイグレーションを完了するフェーズ。

作業は終わっているが、ビジネス的にマイグレーションの終わりを決める。

不思議なエッジケースがある場合もある。

終わったら、ちゃんと褒めること！（大事）

メアニーさん End

stephan fabel. Canonical Companyの登壇

OSSのubuntuを使ったことで有名。

in public cloud

in cloud native

in openstack deployments

in hosted linux

それぞれで人気。

jp.ubuntu.comも解説。

the 10 new rules of open source infrastructure.

1. consume unmodified upstream

2. infrastructure-is-a-product

3. automate for day 1826

4. run at capacity on-prem. use public cloud for overflow.

5. upgradte, don't backport.

6. workload placement matters.

7. plan for transition.

8. security should not be special.

9. Embrace shiny objects.

10. be edgy, go micro

stephan fabel End.

Dougg Davisさん IBM 登壇

bare metal→vitual machines→containers→functions serverless

Platform as a Service. e.g. Cloud Foundry (PaaS)

Containers as a Service. e.g. kubernetes. (CaaS)

Function as a Service. (FaaS)

...

(疲弊したため終わる...）

1GL公募セッション

kubernetesを運用したことで学んだアンチパターン / コンテナ化に向けたクラウドベンダー比較選定のイロハ

資料は、あとで公開予定

1. これまでのPrivateCloudPlatform

1.1. BareMwtal + Servieという直乗せ

1.2. BareMetal + 内製クラウド + VM + Service

1.3. BareMetal + OpenStack Kilo + VM + Service

1.4. BareMetal + Kubernetes + OpenStack Queens + VM + Service

本日の話は、1.4。

2. kubernetesの必要性

1.3で課題があった。

→ DaemonSet, ConfigMap, etcで解決できるためKubernetesに。

→ Kunbernetesを導入して解決した！はずが....alertが鳴り止まない。

アンチパターンを紹介

★ 資料がわかりやすいので、メモ不要。

■ ウエディングパークのお話 西脇さん

ブライダルとITを組み合わせた事業をされている。

・約１５年のオンプレ運用があり、クラウドへの移行が必要に。

・ステップは「クラウド化、コンテナ化、マイクロサービス化」

クラウド化はAWSを選択

選んだポイントは、サービスの品質。

コンテナ化

EKS, ECSどちらを使おうかなと。

ECS + EC2/Fargate

→ 運用が用意で低コスト、大規模サービス向け。

→ コンテナ化をするだけなので、EKSはいらない。

EKS

→ kubernetesのエコシステムの上で運用できる。

学習コストが高いのをどうしたら良いのか。運用コストがこれまでの比じゃない。

・マイクロサービス化

準備中。。。

1B1公募セッション

Kubernetesを拡張して日々のオペレーションを自動化する

Z Labは、Yahooの子会社でインフラの研究をしている。

なぜ自動化が必要なのか？

→ SRE本より「手動で管理しないといけないのはバグだ。自動化しようね」

クラスタ50から400まで成長した。

これを小規模の人数で管理しきれない。

→ 人はミスをするのでコンピュータに任せよう

自動化ステップ

1. 何もしない

2. bashscriptで自動化

3. 2を共有

4. 3をmaintenance

5. 3のfailを自動検知＆復旧

プラットフォームの自動化は、従来のソフトウェアの自動化とは少し異なる。

テストがまず難しい。

↓

kubernetesは基盤をつくるための基盤

宣言的な設計で、自律的なシステム。

Procedural Model

手続き（script）

Reconciliation Model

Kubernetes

→ 障害時の復旧が自律的に発動する。これは手続き側では厳しい（検知は自動化しても復旧は手動）

CRD Development

Design

kubernetesが何をどこまで把握して、調整ループはどこまでなのか。

ex. ReplicaSet

・ 調整対象となるリソースの対象

・ 調整契機となる監視リソースの決定

・ リソースをどう調整していくか

CRDの設計では「調整するSpec/Status」を定義しないとk8sの恩恵が受けられない。

Tips

Calues for analysis and action

オプションは構造的に保持すると変更しやすい

Changeability Condition

変更が多いので配列にする

Reconciler Design tips

調整する対象はノードではなく、原則１つのリソースに限る。

How to delete resources correctly?

終了処理は.SpecではなくMetadataに応じて処理する

Implementation

開発環境の整備は揃っている。参考にkubernetesを見れば良い。

下記を使え（揃えれ）ば良いみたい。

client-go

controller-runtime

controller-tools

kubebuilder

なんかがっつりCRDの実装方法についてのお話。ちょっとついていけない感。

(Leader Election ?)

Syntax and semantic validation

単純なバリデーションから、意味的理解をしてからのバリデーションがある。

できるだけ、syntaxに寄せよう。

Test

Unit-Test FakeClient

※ kubebuilderはメンテのしづらさからFakeClient方式を非推奨。

テストを書くのはGoの方式にならえばよい。

環境構築が難しい。

Kindというものがある。

End-toEnd Test Ginkgo & gomega

あとで資料をじっくり読みたい。。。

1B2スポンサーセッション

Kubernetes拡張を利用した自作Autoscalerで実現するストレスフリーな運用の世界／adtech studioにおけるCRD〜抽象化したGPUaaSによる段階移行計画 & AKE Ingress v2〜(CyberAgent)

自作Autoscaler開発とは？

GCPの技術に偏った話。

■ 会社サービスで使う技術

Cloud Pub/Sub

Cloud Bigtable

Publisher -> cloud pub/sub -> subscriber -> grpc -> service.

Publisher -> cloud pub/sub -> subscriber -> bigtable

BigTableのscaleができなくて、人力で調整していた

-> publisher -> cloud pub/sub -> subscriber * 複数 -> cloud Bigtable. BigtableのNodeを人力調整。

→ 公式にあるそう。プログラマブルにできる。ただ、autoscaleがない。自作。

↓

bigtableのCPU使用率をトリガー

kubernetesのリソース状況（pub/sub）をトリガー

として、bigtableをscale。

↓

自作するため、CRDを作成。

SDKがあるKuberbuilderではなく、フルスクラッチで作成

→ 導入タイミングの問題

custom metricsを使えば解決できたがCRDを採用した。

■運用結果

CPUのピーク時とNode数がちょうどマッチした。

結果的には、問題解決できた。

ただ、導入が完成するまでスケールロジックを調整しないといけないから、そこが問題。

↓

かわって青山さんの出番

・What is Kubernetes

「コンテナ/アプリケーションの実行基盤」としてのkubernetes

「X as a Service 基盤」としてのkubernetes

Database, Queue, Serverless, ML

platform for platfom

-> kubernetesは小さなクラウドみたいに近い

「分散システムフレームワーク」としてのkubernetes

調整ループを通して、あるべき状態に収束する。

→ 継続して維持する。

kubernetesでは、たくさんのリソースがあり、CRDも流行ってきてる。

Kubernetesは「Decralative API」と「分散フレームワーク」がポイント。

→ 分散フレームワーク上でプラットフォームを作りやすい。

・GPUaaS abstraction

GPU上でMLを動かしたいけど、単純にKubernetesで用意すると100行yamlが生まれてしまう。

複雑になると理解できず、怖い。

↓

ML Task CustomResource for GPU aaS (CRD)を作る

→ helmやcustomでも良いのでは？

↓

cache機構を上手く使いたい要件があるので、CRDとcontrollerを採用。

※ kustomizeでもよいけど、S3とオンプレのファイルキャッシュなど考えることが増えるとControllerが必要

段階移行の序章

最初のstepでは、通常のインスタンスのように利用することを想定。

徐々に導入するために、チャットボットでユーザー要件を探っていく。

DataDogで管理している。

1E3公募セッション

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

Knativeについていろいろ聞ける

Knativeは「kubernetesにあるリソースを抽象化して使えるようになる」そう。

たとえば、kubernetesのserviceリソースを使えれば、デプロイしたサービスとURLを紐付けることが簡単にできる。

これをKnativeでも同様に機能を使えるようになる。（もちろんServiceというリソースじゃない。抽象化したもの）

resourceのTypeがServiceじゃなくてKnativeのリソースを指す感じか。

1F4スポンサーセッション

クラウド基盤を支えるスーパーマイクロのResource Savingアーキテクチャ(スーパーマイクロ）

スーパーマイクロさんは、ハードウェアの人。

（まさかのハードウェアの話だったのか！スーパーマイクロはマイクロサービスのすごい版と思ってたｗ）

ブレード、ラックマウント、SuperStorage、マルチノード、GPU SuperServer、エッジ・コンピューティング。

などなどを作っている。

1B5公募セッション

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

いきなりマイクロサービスをするんじゃなくて、Monolithでいこう。

マイクロサービスはいろいろ面倒を見ないといけないから。

じゃあ、なんでメルペイはいきなりマイクロサービスを進めたんだ？

→ 組織をスケールしやすく、マイクロサービスに集中でき、独立した開発・リリースサイクル。

良いね。

→ 決済はとても重要で、どこかが落ちたらすべて落ちるようなMonolithはだめ。

やってないこととして、言語やデータベースは同じものを使っている。（分けれるけど）

マイクロサービススターターキットを社内で用意していて、それを使いまわしているみたい。

OSSとして公開はしていないよね。

※ お絵かき

※ その他