Cloud Native Days Tokyo 2019 - 2019-07-23
previous day
links
Change the Game, Change the World - Speaker Deck
Deep Environment Parity CDNT 2019 - Speaker Deck
そのコンテナ、もっと「賢く」置けますよ？ CNDT2019 / CloudNative Days Tokyo 2019 - Speaker Deck
実録！CloudNativeを 目指した230日 / cloud-native-days-tokyo-2019 - Speaker Deck
転職したら Kubernetes だった件 / That Time I Changed Jobs as a Kubernetes. - Speaker Deck
Spinnakerで実現する、クラウド開発者のためのデプロイパターン入門 / Introduction to deployment patterns with Spinnaker - Speaker Deck
歴史から紐解くLinuxカーネルのコンテナ機能 / CNDT2019 - Speaker Deck
OpenStack Preemptible Instance - Speaker Deck
How cgroup-v2 and PSI Impacts Cloud Native? - Speaker Deck
Challenging_Secure_Introduction_With_SPIFFE.pdf - Speaker Deck
サーバレス・ネイティブ が お伝えする、フルサーバレス開発の魅力！ | Slides | Riotz.works
Microservices を支える Infrastructure as Software / CloudNative Days Tokyo 2019 CNDT2019 OSDT2019 RoomB - Speaker Deck
CloudNative Days Tokyo 2019: Understanding Envoy - Speaker Deck
Kubernetes_Logging入門.pdf - Speaker Deck
マイクロサービスにおける 最高のDXを目指して / Microservices vs DX - Speaker Deck
CNDT2019_Kubernetes_audit_log - Speaker Deck
OCIv2？！軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう！
いつもニコニコあなたの隣に這い寄るカオスエンジニアリング！
CNDT 最近のDockerの新機能
ヤフーのクラウドネイティブへの取り組みとそれを支えるシステム開発
OpenStack上の環境構築自動化に向けたTerraform/Pulumiの活用
クラウドネイティブ時代のセキュリティの考え方とIstioによる実装
Kubernetes CNI 結局どれを使えばいいのか
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
※ ★はあとでよむ
K2基調講演／スポンサーセッション
Day 2 Keynote 楽天モバイルの世界初完全仮想化クラウド型モバイルネットワーク / 決済システムの内製化への旅 / 金融領域におけるOpenStack導入事例の紹介 /Change the Game, Change the World (Red Hat) / OpenStackを用いたパブリッククラウドの国内事例と課題(GMO Internet)
楽天モバイルさん カンさん
rakuten cloud platform
完全自動化。人の介入が一切ないオペレーション
fully virtualized
software centric
automation
うーむ、ネットワークよくわからないから困った。フロントエンジニアにとってきついっす...
ネットワーク構成や、ハードウェアの設定等、諸々をオペレーションなしに進んでいる。(?)
(テレコンオペレータ）
RANまで仮想化しているので、物理アンテナを立てるだけで良い。（ごめんなさい、用語が分からず...）
ハードウェアも仮想化されてソフトウェアに近づく...?
SB payment service
決済システムの内製化への旅 鈴木さん
・内製化に至る道のり
サービス開発は全てベンダに任せる。
↓
課題が山盛り
↓なんとかしなきゃ
支援ツール(git,elastic,...etc)を通して解決。
Architectureをモダンな開発(SpringBoot)やCI(Jenkins)を導入。
↓エンジニアチーム立ち上げ
内製の開発
チーム内で開発する！
スピード感を出すため！
↓
pivotal cloud foundry
Platform as a Service
Kubernetesをしたかったけど、導入コストが高いのとチーム内メンバが少ないことより、PaaSを選択
↓
Private PaaS
Pivotal Application Service
circuit breakerの導入。マイクロサービスのデザパタ。
CIサーバ
Concourse
→ ワンクリックでCI/CD
Metrics,Logging,Tracking等はOSSの有名なものを使用(grafana, prometheus, zipkin, elastic)
ユーザー目線でのメトリクスを監視。
ここの会社は、人が少ない中で、コストを考えた上で、Kubernetes!じゃなくて、
必要な技術スタックを選択している。これは素晴らしいな。
YJFX さとうさん、さいとうさん
OpenStack導入事例
FXの話。1秒間に最大100万(理論値)のトランザクションが発生するほど、レイテンシが重要になっている。
ここの会社も、同様開発を外注しているのでエンジニアがいない。
本番(オンプレ)、開発(PublicCloud)、STG(PublicCloud)
開発とSTGをPrivateCloudにしたい。
↓
OpenStackを採用
↓
本番は、壊れた場合ansibleで再構築できる状態になっていた。
→ ansibleがあればクラウド関係なく構築が簡単になる。(PublicだろうがPrivateだろうが）
↓
トラブルシューティング
→ ドキュメントとの戦い
→ ソースコードこそが全て (ドキュメントが頼りにならない)
↓
OpenStackを導入しようとするなら、こういうドキュメントがなくソースコード読まないといけないような問題がある。
Red Hat 北山さん
OpenShift.
KubernetesはPlatformを作るPlatformを作る技術になる。
Platformとは？
他のプレイヤーが提供するサービスを利用する場を提供するサービス。
提供者と受給者をなにかのアイテム（製品）でつながる場。
考えないといけないのは、「プラットフォームから得られる価値 > プラットフォームを利用するコスト」
Velocity, self-healing, abstraction
迅速で簡単なロールバック、望ましい状態に回復。クラウドプロバイダに依存しない。
システムの話になると
運用管理者、Kubernetes(プラットフォーム)、アプリケーション開発者。
↓
これ、運用コストの方が大きくなっているのでは？
↓
Kubernetesを使うことがCloudNativeじゃない。
↓
+Native
運用工数を下げるためには、既存のシステム運用とは大きく変える必要がある。
↓
運用コストを下げるために、Operatorを使うようになる。
Operator Hubというサイト、気になる。
この話は、有意義だった。よかった。
2GL公募セッション
そのコンテナ、もっと「賢く」置けますよ？
スケジューラの話。
PodをどのNodeに配置するのかを紹介。
Filter -> ベスト
filterでそもそも対象じゃないNodeを外す
ベストで残りのNodeでよいものを選択。
あと、Podはサービス系とバッチ系の２系統に分かれていて、
前者はちらしたい、後者は１つのNodeにつめこみたい。
Podごとにスケジューラの設定をかけるから、サービス系とバッチ系で分けていく。
複数のスケジューラ設定をかけるから、効率的。
バッチがいっぱいいっぱいでサービスPodを追加したい場合、Filterで外されてしまうので、
Preemptionを使って優先度を決めて変える。
ただ、いきなりBatch系のPodをどかしてしまうと、計算処理がすっ飛んでしまう。
そこで、preemptingPolicyをNeverにすることで、Batch系の処理を待ってくれる。
Resource Requestで余裕にとってるCPUを開放したい。
Vertical Pod Autoscalerでできる。
A-Nodeが死んでA-PodがB-Nodeに移動、A-Nodeが復活してもA-PodはB-Nodeのまま。
Descheduler
SchedulerExtenderというものがあって、これを使ってSchedulerをカスタマイズできる。
ただ、完全自作はテストの観点からやらない方が良い。
2C1公募セッション
A deep dive into service mesh and Istio
service mesh の機能
・Traffic management
・Observability
・Policies and security
→ これらを管理するのが複雑になってしまう。そこでservice meshを使って解決する。
Istio
envoyというOSSを使っている。
Mixer, Pilot, Citadel (certification management)
リクエストはMixer(istioのpolicyチェック)をうけて、proxyに流す→サービスに渡してレスポンスをもらってproxyに流す。
基本、proxy経由でやりとりをする。
間にproxyとistioを挟んでしまうので、パフォーマンスは悪くなる。これはトレードオフ。
Istioはアクセスを同期的に処理する、つまり他の処理が完了するまで待つ必要があるのでレイテンシが発生する。
そこで、cacheやturnOffをして早期に返すようにする仕組みが必要。proxyに含めてみた。 by songさん
パフォーマンス問題を解決するため、いくつかの取り組みをしたそう。
Istioはノード間のトラフィックが多いため高レイテンシーになる。
そこで、同じノード上にmixerを配置するようdaemonsetを作って、mixerとproxyとの通信の設定を行った。
※ ただ、proxyからserviceを集めてからmixerにリクエストすると、serviceが高負荷になる。
そこで、serviceを外した。（集めることによるメリットもあると思うけど、パフォーマンス目的なら不要か）
Istio Extensibility v2 - コミュニティで議論されているIstioの新しいアーキテクチャ
Mixerの機能がEnvoyに組み込まれ、WebAssemblyで動的にEnvoyの拡張ができる？
2C2スポンサーセッション
DX時代のアプリケーション基盤を支えるNEC(日本電気)
DX、デジタルトランスフォーメーションだったのか！developer experienceじゃないのか...。
2D3公募セッション
Understanding Envoy
envoyはネットワークごとの困りごとを解決するツール
envoyは、L3/L4 filterのArchitecture、HTTP L7のArchitectureもサポート。
HTTP/2もサポート。
observabilityは豊富で、stats,logging,tracingがある。
従来のネットワークツール（nginx)は、設定ファイルを書き換えてホットリロード。
envoyは、API経由(gRPC, JSON/YAML REST)で設定更新ができる。特徴。
xDSというDiscovery Serviceがある(xDS API)。難しそう。
Envoy Architecture
マルチスレッドアーキテクチャの単一プロセス。
詳しくは分からなかった。
Envoy use case:
なんでこんなにEnvoyは有名になった？
とある企業でEnvoyは使われていて、そこで十分に活用されていた。
→ 拡張性が優れている。
→ キャッシュサーバにも転用できる。
Envoyは、オンプレ(VM)でも動かすことができるので、(コンテナじゃなくて良い）
VMからクラウドへマイグレーションする場合でも、Envoyを使ったサービスメッシュの恩恵が受けられる。
（サードパーティがある）
2B4公募セッション
Microservices を支える Infrastructure as Software
マイクロサービスでは、データベース周りでボトルネックになることがある。
ここはスケールアップをする手を考える必要がある。
スパイクしたとき、スケールアップが間に合わずkube-dnsの名前解決ができなかったことがある。
どこも聞くけど、スケールアップ時の課題がどこもあるな〜って思う。
課題に対して計測できるようにするのは、大切。
デザインドキュメントというもので、どういった課題に対してどう設計したのかというドキュメントが必要。
★ 例えば、「ここの動作はわかるけど、なんでこう作ったのかはわからない」をなくしたい。
なにか問題があれば、それは企業特有のものか？一般的な問題にないか？（抽象化する）
→あれば、解決策があるかもしれない。
2A5公募セッション
マイクロサービス運用における最高のDXを目指して
やべ、何も書いてない。（ちがうことしてた。）
※ links
「Lift and Shift」
「zookeeper」