###### tags: `cloudnative` `Cloud Native Days Tokyo 2019` `study`
# Cloud Native Days Tokyo Day 2
[スライド集](https://gist.github.com/isaoshimizu/e172ae184e23e4873df213dba5c28de7)
## 楽天モバイル
###
+ Oct 2019
+ 4G launch
+ 2020
+ 5G Launch

### 楽天モバイルでやること
+ Fully Virtualization
+ Software Centric
+ Automation

### Rakuten Cloud Platform
http://www.qct.io/ja-JP

CU, DU
[Docomo](https://www.nttdocomo.co.jp/corporate/technology/rd/tech/5g/5g05/03/index.html)
> 集約ノードをCU（Central Unit）、分散ノードをDU（Distributed Unit）と定義
>

+ 東京と大阪で冗長構成

### Distributed Telco Cloud
+ Regional DC
+ ~50
+ GC
+ ~4000

## 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
(@jakopen)人が関わる場所を減らしていくのがクラウドネイティブ
@suzukij

### SBペイメントサービス
+ 決済代行
+ キャリア決済
+ カード発行業務

入社当時サービス開発ベンダに任せておりエンジニア0人
### 効率化
+ 手作業が多い
+ 支援ツールを内製し運用作業を自動化
+ slack
+ cibfluence
+ jira
+ エンジニアが3名入社
+ サービス監視の質を高める
+ Elasticスタックを導入し監視用ダッシュボードをつくった
+ 開発プロジェクトの支援を開始
+ 古いアーキテクチャ
+ 開発・リリースのコスト
+ Springベースにしてモダンな開発・運用
+ Jekninsなどを導入

2016-17
+ エンジニアチームの立ち上げ
+ ツールの内製
+ エンジニア5人に

### 開発対象
+ オンライン決済サービス
+ 加盟店　-> 決済サービス

[Pivotal Cloud Foundry](https://pivotal.io/jp/platform)
### プラットフォームに求めるもの
+ リリースの改善
+ プラットフォーム

#### kubernetes or PaaS ?
+ 学習コスト・メンテナンスコストの高さ
+ システム構築までの時間
+ すでに確立された実績のあるプラットフォームをつかいたい
+ PaaS

### Circit Breaker
A,B,Cと連携先があった場合、A起因の障害が伝播して全部止まってしまうかも知れない
サーキットブレーカーがあると途中で打ち切ることができる
### CI/CD
[concourse](https://concourse-ci.org/)
### Observability
+ 開発者は意識することなくリリースしたら監視される仕組み
#### メトリクス
+ Grafana
+ platform
+ vmのメトリクス
+ コンテナ
+ コンポーネント
+ ミドルウェア
+ application
+ 全SpringBoot
#### Logging
+ Kibana
+ アクセスログ
+ アプリケーションログ
#### トレーシング
+ Zipkin
+ https://zipkin.io/
+ 複数のサーバにまたがる処理でもどこが遅いのかがわかる
#### ビジネス目線でのモニタリング

### まとめ
+ 外注に頼ったサービス開発を積み重ねてもプラットフォーム開発はできない
+ 堅牢、安全、一件一円間違えないサービスを目指す

## 金融領域におけるOpenStack導入事例の紹介(YJFX)
佐藤 優典 (Masanori Sato) 執行役員 ワイジェイFX株式会社
齋藤 光 (Hikaru Saito) Manger ワイジェイFX株式会社

### 外貨EX
+ トレーダーとシステム、システムと銀行の間で為替をする
+ トレーダーに卸す価格　- 銀行から買う価格　= 利益
### 値段
+ 要人の発言
+ 経済指標の発表
+ 一秒間に5000回値段が変わる
+ 5000 * 22通貨ペア　* 10+ 銀行　＝ 1000000 トランザクション / sec

### システム構成
+ Customer system
+ Front system (銀行とのやりとり)
+ Analyze system

### 背景・問題
+ 開発環境とStaging環境を複数面持っていた
+ それらをすべてパブリッククラウドで運用していた
+ コスト
+ 金融システムはやりたいことが増えるため要求リソースは増えるばかり
+ デリバリ
+ アプリチームがインフラを触れなかったためオーバーヘッドがあった
+ 権限・ノウハウ
+ クラウド使ってるのに決済が必要だった
+ 自分で買ってプライベートクラウドを作ろうと決心
+ 4月に移行完了

### 導入時
#### pros
+ Ansibleの活用
+ 100 servers in 30 min
+ クラウドに合わせた構築をしないとしんどくなる
+ サーバーはペットではなく家畜として扱え
+ Red Hat Summit 2019に登壇
+ 小さなチャレンジが認められた証左になった

#### cons
+ ansibleを活用できていないレガシーシステムの以降
+ トラブルシューティング
+ RedHatのサポートの回答はあんまりすぐ来ない
+ ソースコード読む

### 今後の課題
+ OpenStackの維持運用改善
+ パッチ適用
+ アップグレード対応
+ OpenStackは銀の弾丸ではない
+ 金融業界を取り巻く状況
+ インターネット企業の金融参入が加速
+ 各種規制・監査への対応
+ 不確実性への対応
+ デリバリパフォーマンスの向上

+ Cloud Nativeになる
+ 単にクラウドを使っている状況からの脱却
+ レガシーシステムのモダナイゼーション
+ 組織文化の醸成
+ デリバリパフォーマンスにおけるハイパフォーマンス組織へ
+ 競合優位性を保つためによりよいサービスとソフトウェアを早く提供する

## Change the Game, Change the
https://speakerdeck.com/shkitayama/change-the-game-change-the-world?slide=13

北山 晋吾(Kitayama Shingo) レッドハット株式会社 クラウドソリューションアーキテクト テクニカルセールス本部
### What's the "Platform"
他のプレイヤーが提供する「製品、サービス、情報」と一体になって、初めて価値を持つ製品やサービス
### Airbnb Business Model
空き家をもつホストと旅行者をつなぐマッチングサービス
### Network Effect
二つ以上の異なる集団の間をとりもち何らかの出会いを促すこと
**プラットフォームから得られる価値＞プラットフォームを利用するコスト」**

## OpenStackを用いたパブリッククラウドの国内事例と課題(GMO Internet)
中里 昌弘(Masahiro Nakazato) クラウドサービス開発部　マネージャ－ GMOインターネット株式会社

### OpenStackを活用したサービス
+ お名前.com
+ ConoHa
+ GMOアプリクラウド
+ Z.com Cloud
+
### OpenStackに携わったきっかけ
+ 既存業務のマンネリ化と物足りなさ
+ ある程度やると手順が決まってくる
+ OpenStackの流行
+ 社内の有能なエンジニアがOpenStackを触っていた
+ ジャンルの垣根を意識していない人たち
+ 枠にとらわれないで物事を扱う
+ うまく動かないものをどうやってサービスに使うか考える

## CNCF sandbox 17本ノック
[スライド](https://docs.google.com/presentation/d/1O9Q9E1hH6mBA5w8oDENnCYObZvij1-Dr_obvsY3X29k/edit#slide=id.g5c19003abb_0_14)
### [KubeEdge](https://github.com/kubeedge/kubeedge)
- Kubernetesをエッジコンピューティングに利用する。エッジノードの管理やアプリ（コンテナ）の配布を、1つのKubernetesクラスターと同様の感覚で透過的に行えるようにする
-
### [Virtual Kubelet](https://github.com/virtual-kubelet/virtual-kubelet)
- Kubernetesクラスターを他サービスのAPIに接続するための、kubelet互換の実装。Azure Container Instance, AWS Fargate等をバックエンドとして利用したNodeを実現する

### [Flux](https://github.com/fluxcd/flux)
- GitOpsによるCI/CDで、manifestをホストするリポジトリとKubernetesクラスターの同期を行うためのツール

### [Brigade](https://github.com/brigadecore/brigade/)
- Kubernetes上で展開されるCI/CDパイプライン
- タスクランナーっぽい？
- Javascriptで記述し、パイプラインをプログラマブルに管理

### [Network Service Mesh]()
- L2/L3レイヤーのIstioインスパイアなサービスメッシュ
- VNFの思想

### [Dragonfly]()
- P2P技術によるイメージ、ファイル配信
- 効率的なイメージやファイル配信、帯域コントロール

### [SPIFFE]()
- Secure Productuin Identify Framework For Everyone
- セキュアにサービス勘認証するための標準仕様

- https://spiffe-jp.connpass.com/event/126507/
- https://qiita.com/hiyosi/items/6e8d56b257c55a709b4d

## 実録！　CloudNativeを目指した230日
高石 諒 (TAKAISHI Ryo) / Principal Engineer, GMOペパボ

+ なぜKubernetesを選んだのか
### ペパボインフラの歴史と課題
#### Baremetal Era (2001-2015)
+ サーバ投入のリードタイム
+ エンジニアのアサインやキャパシティプランニング
+ サービスが多いので物理サーバの管理
#### Cloud Era (2015-)
+ OpenStackを用いたプライベートクラウド(Nyah)へ
+ 現在ベアメタルが必要な部分を覗いてNyah上でサービスを運用
+ 一部public cloudやPaaS
+ リードタイム削減
+ 物理サーバの管理を集約することで効率UP

#### しかし
+ 設計・構築には時間がかかる
+ エンジニアのアサインも引き続き課題
+ 構成ドリフト、スノーフレークサーバの発生
+ サーバーの構成・設定が時間とともにバラバラになる
#### 課題
+ **人が介在する箇所がボトルネック**

+ 十分に自動化出来ておらずオペレーションが発生している

#### 課題に対して打てる手は？
+ IaaSのまま自動化を進める
+ 初期段階のサーバー構築は必要
+ IaaSを隠蔽するようなプラットフォームを導入する
+ 管理対象となるレイヤーが増える

=> 技術的チャレンジのためにKubernetesの導入を決定
#### Kubernetes
+ IaaSより強制力の高いプラットフォーム
+ PaaSに比べると自由度が高い
+ サーバやソフトウェア追加のリードタイムを削減できる
+ 構成ドリフト、スノーフレークサーバーが発生しにくい仕組み

#### Kubernetesって運用大変なんでしょ
+ チャレンジではあるが無駄にならないはず
+ Kubernetesに乗せるためにコンテナ化する
+ ポータビリティの向上
+ 得た知見や実施した改善は活用できる

### CloudNative Era(2018-)
#### NKS(Nyah Kubernetes Service)
+ 社内向けシステムや検証用に使う**共用クラスタ**
+ 壊れても大丈夫なものだけ動かす
#### なぜ共用クラスタなのか
+ 新しいパラダイムに触れる
+ IaaSとKubernetesでは考え方がかなり違う
+ k8sは抽象化された概念を扱う
+ 学習して慣れていくしかない
+ 興味を持ったときに触れるようにする
#### 触りたいときにすぐ触れる工夫
+ GHE認証
+ owada
+ 基盤システム郡
+ *.pepablab.comで社内向けサービスをすぐに用意できる

#### minneへのkubernetes導入
+ 既存システムと並行で導入開始
+ 徐々にトラフィックを流す
+ 問題発生時にすぐ切り戻せるような体制

##### Consul Kubernetes Integration
+ ConsulをKubernetes上で動かす
+ ConsulのサービスとKubernetesのサービスを相互に同期する

##### ingress-controler

#### Cloud Native?
+ kubernetes自体もKubernetes上のアプリも人間がデプロイしている
+ 人の関るポイントが増えている?
+ 本当の戦いはこれから
+ まずは導入して動かしていけそうだという感触
+ 手作業で出来ないことを自動化するのは難しい
+ マインドセットを変えるための土台作りができた

#### 新しい課題
+ OpenStack側のノイジーネイバー問題
+ 原因の特定が更に難しくなった
+ サービスで発生し問題の調査が難しい
+ クラスターの数だけ運用がある
+ クラスタのアップデート
+ クラスターレイヤーでの障害対応
+ Observabilityの強化
+ 問題箇所の迅速な特定
+ Kubernetesに関心のあるメンバーを増やす
+ コードを書いて自動化する

マインドセットを変えていくための土台が整ってきた

## クラウドネイティブを作る技術
山下 和彦 (Kazuhiko Yamashita) / シニア・プリンシパル, GMOペパボ
[スライド](https://speakerdeck.com/pyama86/kuraudoneiteibuwochuang-ruji-shu)
### STNS
[GitHub](https://github.com/STNS/STNS)
Linuxユーザーと公開鍵を統合管理するサーバ、クライアント

### CloudNativeですか
[ロリポップマネージドクラウド](https://mc.lolipop.jp/)
### マネージドクラウドの魅力
+ DBが付属
+ インフラはロリポップにお任せ

### 要素技術
+ [FastContainer](https://hb.matsumoto-r.jp/entry/2016/11/11/234915)
+ まつもとりー さんが考えた
+ haconiwa
+ mruby製のコンテナランタイム
### マネージドクラウド
#### オートスケール
HTTPリクエストがきたタイミングでコンテナが起動する

### コンポーネント
Webフロントなどかるい処理はOpenStack上に
#### ngx_mruby
[GitHub](https://github.com/matsumotory/ngx_mruby)

### なぜKubernetesではないのか
1. ペパボはホスティング事業を提供
2. FastContainer
3. スクラッチが前提になった
4. 時代的な要因
5. 作り始めたのが2年前
6. 事業差別化
7. OSSを使うのではなく自分の土俵をつくる
8. ユーザビリティ

#### Node compornents
ngx_mrubyは結局nginxなので難しいことはしない
=> kubelet => ngx_mruby + skmr

#### Container Runtime
haconiwa

#### まとめ
+ マネージドクラウドはK8sほど柔軟ではないが、インフラに詳しくなくても使えるお手軽クラウド
+ 似てる部分もある

+ CoreAPIはKuberentesに載せてる

### コンテナオーケストレーションシステムはOSっぽい
+ スケジューラがプロセスをスケジューリングし、フィードバックを受けながら動き続けようとする挙動はOSっぽいと似ている
+ OSにおけるグッドプラクティスが役に立つ？

### ログのバッファリング
+ [Kafka](https://kafka.apache.org/)
+ いっぱいデータを持っているところが使う?

## Microservices を支える Infrastructure as Software
坂部広大 at wantedly @koudaii
### 解決した課題
+ データ更新によるイベント伝搬
+ [Cloud Pub/Sub](https://cloud.google.com/pubsub/docs/overview?hl=ja)を使った基盤を採用

+ 他から見てもわかりやすい成果
+ なぜこれをやっているのかを整理整頓する
+ あいつらなんでこれやってるの、って言われないように
+ ベストプラクティスを共有

### 事例
+ 分散トレーシング
+ RPC，レイテンシ, スループット可視化

なぜ、これを使うのかがちゃんと明文化できている

Istioの一部の機能だけをつかうなどして、minimumにはじめる
「何かあったらすぐにOFFにできる」というのも大事

## [ライブコーディング] Custom ResourceとControllerを作ろう!
### kubernetesのコントローラとは

### ライブコーディング
https://github.com/kubernetes-sigs/kubebuilder