はじめに CloudNative Days Tokyo 2019/OpenStack Day Tokyo 2019とは

CloudNative Days Tokyo 2019/OpenStack Day Tokyo 2019 とは、2019/7/22, 23に虎ノ門ヒルズで開催されたクラウド関連技術とOpenStackに関する技術イベントです。
スポンサーセッションや公募セッション等100弱の講演数の中から好きな講演を聞く形で、この中で私が聞いた講演に関する概要・参考をまとめて行きたいと思います。

各講演素晴らしかったのに加え、司会者の方が合間に話してくれたこんな言葉がとても印象的でした。

CloundNativeとは、kubernetesを使うことみたいなどんなツールを使うかという話ではない。
この技術を使う！じゃなくて、人間のやることを自動化していくこと。人の手をいかに無くすか、ボトルネックを如何に無くすか？を考えて実践するのがCloudNativeだ。

長いので、参考も先に貼っておきます。

参考

スライドまとめ。追って公式からもスライド集が出てくるそうです。
CloudNative Days Tokyo 2019 スライドまとめ
 CloudNative Days Tokyo 2019 / Open Stack Days Tokyo 2019 スライド資料リスト
 CNDT2019/OSDT2019行ってきたのでスライドリンクとメモ(更新中)
公式Twitter

Day 1, Opening Act

Opening

Cloud Native Computing Foundation (CNCF)の動向を簡単に紹介をされていました。

CNCFのlangscapeがこちら。ほんと色々な道具が用意されていますよね(こなみかん
規模を増やしていくとともに、各種サービスの品質基準を定めるために、例えばkubernetes certificationといった認証機関を用意したりもしているそうです。

Collaboration Without Boundaries(Mark Collier/OpenStack Foundation)

OpenStackの動向について。講演中のCollaboration without boundaries works!という言葉に集約されていた気がします。
OpenStack自体はプライベートクラウドとパブリッククラウドを構築・管理する為のオープンソースツールで、クラウド構築のために必要な様々な機能が網羅されています。
コードだけでなくOpenDesign、設計も含めたものをオープンにして、垣根を越えて広くOpenStackを使ってほしい、参加してほしいといった話を語っていました。

Performing Infrastructure Migrations at Scale (Melanie Cebula/Airbnb)

Airbnbという『空いてる部屋や家を貸したい人』と『借りたい人』とのマッチングサイト。こちらの開発を行っているエンジニアさんが語る、以下にソフトウェアをMigrationしていくかについての話。
Melanie Cebulaさんが別の場所で行っていた同じタイトルの講演動画があったので貼っておきます
Performing Infrastructure Migrations at Scale

Migrationしていくために大事なことのまとめ

行おうとしているMigrationのtypeを決める
- component
  - セキュリティパッチetc
- systen
  - CI/CD etc
- インフラ
  - k8s導入 etc
Migrationする順番、優先度を決める
設計、計画、習慣化
Migrationをやりきる、終わらせることが大事
ソフトウェア構造の抽象化、リファクタリングが大事
Migrationにもライフサイクルがあることを意識する。
- validation
- enable
- finish
イテレーション

講演メモ

マイグレをどうしていくか？

努力、大きさ、優先度を決める。
tech debtと呼ばれるセキュリティや効率などに関する負債を改善していくため、Migrationしないといけない。

Migrationの分類化。今は何をしようとしてるの？
- component
- セキュリティパッチetc
- systen
- CI/CD etc
- インフラ
- k8s導入 etc

複雑な場合は順序を定義しましょう。
→関連してる？目的あってる？複数互換対応は？
といったことが複雑にさせていくので、小さな課題に分けてtech debtをガンガンやっつけようぜ！みたいな話かな
複数互換対応が出てこないよう、関連する小さなところを潰して、そのあとそいつをやっつける。もしくは優先度をつけてやっつける

大型migrationの場合

影響に関する問題、スケールする上での問題
サービスの数が増えれば増えるほど、Migrationが複雑に

- 実際の負荷をかけて、長期的なプランニング
- まずは新しいシステムから少しずつ対応していく

Service Generator toolの導入が効果的だった

オーバーヘッドについて

マーグレーション時のオーバーヘッド

Migrationしてる人、メンテナンスする人それぞれへオーバーヘッドがかかる

途中は両対応しないといけない、Mix stateを管理しないといけない

- Migrationは時間がかかる！ここばかり取られることは避けたい
- Migrationを終わらせて正しいライフサイクルを作る

どうやって？

自動的にできるかの検討
abstruction layerを作ってマイグレしやすくする
リファクタ

abstruction layer

詳細を隠蔽。
今後はServiceの定義をしてあげて、setting fileからサービスをコントロールしたい

ライフサイクル

新規の使える技術、クラウドネイティブを取り入れるタイミング

validation フェーズ

テクノロジー評価は、高負荷でイテレーションを続けないといけないよ

- シンプルなプロトタイプものを作って、テストを作って、高負荷をかけて確認してあげる
ギャップがあったら分析

enable フェーズ

たくさんのドキュメンテーション
abstruction layerなどちゃんと設計してあげよう

finish フェーズ

開発して終わらせる。開発チームと、事業部と、etc
最後の2, 3割が難しい。あるある〜

The 10 new rules of open source infrastructure (Stephan Fabel/Canonical)

Open Source instastructureに携わるにあたっての10のルールの紹介。こちらの記事と同内容の講演をしてくれてたと思います。
ざっと自分なりの解釈を乗せますが、講演についていけてなかった部分も多いので本家記事を参照ください。

Consume unmodified upstream
1. OpenStackは、の話ですが、安定版リリースが出来てるのでそれを使うようにしよう。変に古いコード+セキュリティパッチで開発しても大変なこと多いよ
Infra is a Product
1. costは初年度に一番かかる。如何にcostを減らすかが大事だよね
Automate for day 1826(5年)
1. 自動化大事だよ。5年も立てばテクノロジも変わることも想定してね
Run at capacity on-prem. Use public cloud for overflow.
1. 使えるインフラ、ハードの中で最高な状態を！+適度にpublic cloudを活用しようぜ。
Upgrade, don't backport
1. 例えばk8sなら4回/year, OpenStackは1回/yearといったアップデートサイクルがあるので、そこでupgradeしましょう。決して古いものに対してbackportしてはいけない！
Workload placement matters
1. 一度問題が発生した際に、細かい原因究明をしたい。どこで何がどうなっているかの相関関係を理解しないといけない。どこに何があるのかをよく意識しましょう。
Plan for transition.
1. 時代はガンガン変わるので変更を適切にする必要がある。自動化についても関係する
Security should not be special.
1. セキュリティは特別じゃない。最後に別途設計するものではなく、最初から意識するもの
Embrace shiny objects.
1. 新しいものはどんどん導入しよう！イノベーションを取り入れる。container, VM, etc。ただし、これまで上げたポイントを押さえた上で
Be edgy, go Micro
1. 尖っていこうぜ！Stephan Fabelさんが気にされていたのは以下

snap install microstack --beta --classic
snap install microk8s --classic

Demand Less Choices! (Doug Davis/IBM)

IBMの方の講演で、ざっくりいうとknativeというツールの紹介。
https://github.com/duglin/helloworld

Cloudを利用した開発で何がいいのか？という話。既存のPaaS/CaaS(Container as a Service, ex:k8s)/Function as a Serviceで足りないものをKnativeなら解決出来るよ！って話でした。

講演メモ

CloudNativeをどう選択していくか？

CloudNativeになると何がいいの？

速さ、コスト、コードに集中、etc

Container as a service

- PaaS, ほぼ隠蔽
- Container as a Service - k8sのようにcontainerを管理
- Function as a Service - OpenWhisk

これらの特性

PaaS

シンプルUX
Containerもある、MicroService, stateless, endpoint/load balancing, build
なんでもできるけど、、、

Access to advanced feature、自由な拡張はできない

k8sの例

抽象化、kubernetesはできてないよね〜

- Knativeがリリースされた。コード部分だけでOK
kubernetes生もできるし、簡易的に使われてるものも使えるし

http://jaco.udcp.info/entry/2018/07/25/043415

Knativeの宣伝でした。良さげ
https://github.com/duglin/helloworld

Day 1, others

Re-architecturing of Microservices(Nao Minami/Wantedly)

wantedlyがモノリシックなサービスに対してマイクロサービスを導入した時の話。こちらもどういった思想で開発をしたのか、どうモノリシックなシステムを置き換えていったのかという話が聞けたのが良かったです。
特にPub/Sub Messagingの仕組みを取り入れた話が面白かったです。

非同期通信
publisher/subscriberを分けることで、モジュールの関心ごとが切り分けられて抽象化しやすくなる

講演メモ

問題

モノリスサービスの責務巨大化
マイクロサービス
- ユーザー情報の管理という責務が複数マイクロサービスに存在
- 取得ルートに対しても同様
- 依存関係の問題アーキテクチャの見直し ## 何が適切なアーキテクチャか？単一目的疎結合、高凝縮性(同じものは点在させない) ## どうやったか？問題に対する理想が見えてる状態、どうやって？ ### モノリスの分割
分割対象の責務毎にチームを組んで分割コンウェイの法則→組織とシステムって関係してくよ。 #### 有効だったアプローチ
モノリスシステムの中でも境界の明確化
- ユースケースを満たす最小のものを作る
共通のドメインロジックを持つマイクロサービス実行
境界のメソッド呼び出しをRPC化 ### 置き換え方
フラグを利用し、少しずつマイクロサービスのtrafficを増やす。一気に入れ替えるのではなくちょっとずつ
インターフェースはきっちり、でも実装は機能毎最小単位で ## 実装方法 ### Protocol Buffers IDLで自動生成インターフェースだけを意識する https://qiita.com/Hiraku/items/7c8f56e8564158c895f9 ###　MS間通信にPub/Sub Messagingを利用イベントドリブンで実施
非同期通信
publisher/subscriberで分けるので、関心ごとが切り分けられる 注意点
マイクロサービス間は結果整合になる。(いつデータ同期されるの？)
複雑性の増大。別の目線で複雑さが増していく

責務が複数になった件へのアプローチ
インターフェースの切り出し不足
責務が不明確だった

Re-architecturingについて

大変
やっていくと確実によくなる
計画的に改善しよう！

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

Dockerってなんなのか、コンテナ技術の何がいいのか？を滅茶苦茶わかりやすく説明してくれている良記事です。Dockerのアイコンかわいいよね！

講演メモ

Docker => もともとDot cloud社のPaasだった
コンテナとは？ =>

Dockerの得意なこと、苦手なこと

できること
- 環境の共通化

注意すること
- モノリシックな管理
- 秘匿情報の扱い(環境変数で注入)

できないこと
- ログ管理、監視

オーケストレーション

コンテナの数調整したり、再起動したりといったことがしたい。これらを管理するための仕組みがk8s

RancherではじめるCloudNative！！(Yutaka Ichikawa/エーピーコミュニケーションズ)

Kubernetes is becoming the Linux of the cloud という言葉が出てくるくらいContainer管理のスタンダートとなりつつあるk8s。でも管理が大変だよね。
IBMさんのKnativeも同じ発想でしたが、こちらはRancherというツールを使った管理について、ハンズオン形式で学んでいくセッションとなっていました。

UIが見やすくcontainterの稼働状況のモニタリングも出来る優れもの。残念ながら事前調査をちゃんとしていなかったため、必要なGCPアカウント等を用意していなかったのでハンズオン自体は出来ませんでしたが、動くものが見えると楽しいですね。

今さら聞けないOpenStack 〜クラウド基盤って何が嬉しいのかを再確認 (Noboru Iwamatsu/富士通, Tashiro Mitsuyoshi/NTTデータ, Tomoaki Nakajima/レッドハット株式会社)

3社のOpenStack導入事例の紹介。OpenStack自体に対するありがたみ以外に、OSSコミュニティに参加することで得られることについても語ってくれたのが興味深かったです。
PCのバッテリー切れでメモなし。富士通さんのスライドはありました。https://speakerdeck.com/r0ckpine/osdt2019-fjcsfoross-openstack-user-stories

k3sで作る!軽量k8sエッジコンピューティング環境(RYOMA FUJIWARA/Rancher JP)

軽量kubernetes、組み込みで使われるARMもターゲットにしたk3sの概要と、それらを利用したデモを紹介してくれました。k3sが如何に軽量化を行ったかの話もあって面白かったです。
デモについては、IoTのような感じでエッジ端末(Rasberry Piで代用)をばらまいた環境に対してアプリケーションをデプロイしていくための環境として、k3sは有効なのではないかという仮説に対するアプローチでした。
結論として、サクッとPoC作るには十分という話でした。

講演メモ

k3sで作る!軽量k8sエッジコンピューティング環境
Tea pod418藤原涼馬さん
会社員兼フリーランスエンジニア

k3sとは

軽量kubernetes

特徴

certified kubernetes Distribution
小さい
- 40MB only 512MB upstream
Armがターゲット

certified kubernetes Distribution

kubeの認証が取れているものの話。

リソース小さい、arm対応

エッジ(IoTなど)で動かすこと前提
基本そこそこ大きなリソースを要求されてるのが、マスターが512MB, ノード75MBのメモリでいい。
Diskも200MBでいい。
組み込みで動くレベル
- 当然使えなくなることもあるよ

軽量化方法

コード作成
- 軽量化の為に古いもの、アルファ版、プロバイダ&&ストレージ関連コード、Dockerの削減
プロセス作成
- 主要コンポーネントを単一プロセス化で、パワープレイでリソースを圧縮

軽量と言えば、Rasberry Piでどうなる？showk3sの取り組み

エッジコンピューティング

懸念点
- 上流ネットワーク不安定
- ネットワーク安定したら流す！
- 端末は壊れるもの
- 切り離す
- 数が多い
- 危機管理

事例

Goldwind Smart Energyの事例
- 風量発電の環境にて、無線で端末バラマキ
- 数千台のkubernetesクラスタ
- 壊れたら切り離して安全に交換

サンプル

写真撮影アプリ、
Github show3s
画像の取り込みは
ラズパイとk3sでサクッとPoC作るくらいならいい感じそう！
いい点
- k3sのデプロイが効率化できる。動かすのも簡単。(とっかかりはk3sがいいかもね)
- k3sのtraefikが便利
悪い点
- ARMは大変ですよね。
- CI with ARMって？
- CI更地だよね
いい点：ラズパイ
- RaspberryPi3, 性能不足を感じることもない。すごいねラズパイ
悪い点：ラズパイ
- 熱やべえ
- IoTに参加するにはハードがないといけないのが大変
20-30hくらいで実装できたらしいです。2万くらいでできる

Day 2, Opening Act

楽天モバイルの世界初完全仮想化クラウド型モバイルネットワーク(Ashiq Khan/ 楽天モバイル株式会社)

楽天モバイルが取り組んでいる、世界初のエンドツーエンドの完全仮想化クラウドネイティブネットワークに関する話。
基地局内のものをとにかくソフトウェア化し、アンテナを置いてソフトウェアをデプロイすればOKな環境を作ろうという発想でした。以下なんかは分かりやすい例で、Network周りのハードはサーバー1つ、基地局内に必要なハードもわずかなもので済むようになっています。

合わせてEnd to Endで行うことを全部自動化しようという考え。こんだけのことを自動化しあげたらしいです。

最後に「これ、本当に全て実現したと思いますか？信じられませんよね。でも全部実現したんです！」と語っていたのが印象的でした。

講演メモ

楽天モバイルの戦略、完全仮想化モバイル

完全仮想化
Software、新規
Automation

VLAN部分とかも共同開発、ガンガン新規開発してる面白そう
とにかくハードの絡まない部分はとことん仮想化、ソフトウェア化してる

VLAN周り

Baseband信号処理を仮想化、NTT datacenter上のサーバーに全部
→色々仮想化してるから、ものがいらないよって話(2枚目)

一人で簡単に設置工事可能

キャッシュとかはアプリケーション→ソフトウェア化

冗長化も東京と大阪というレベルでリージョン分け、50箇所以上に分散

冗長化、分散
ソフトウェア差し替えによる更新だからできること(いちいちその場に行かなくてもいいので)

OpenStack

サーバーの種類も少なくしてシンプルに

Operation System

(資料展開されてないかな。じっくりみたい)

理想のアーキテクチャの話を色々していて、実際に電波吹くまで言ってる。

LANまで仮想化、アンテナだけ立ててソフトウェアアップデートでOKな構成まで行った

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発(Junya Suzuki/SBペイメントサービス株式会社)

ベンダ任せのモノリシックなシステムだったSoft Bankの決済サービスをCloudNativeなサービスにした話。
Private PaaSであるPivotal Cloud Foundlyの導入事例というのも興味深かったです。
最後に言っていた「外注に頼りきらず、自分たちで内製化するからこそプラットフォームの構築・運用ができる」という言葉が良かったです。大きな企業こそ思うところがありそう

講演メモ

事業内容

SBペイメント、決済サービスについて

- 導入までと効果

history

ベンダ任せの開発、コードを各環境も整っていない。

Start

運用の効率化
- Spring Boot/ Selenium
- GitHubなども導入
サービス状況の把握、共有
- 監視用ダッシュボード
開発支援
- 古いアーキテクチャ、開発、リリースコスト
- Spring Boot
- Jenkins
- CIをきちんと回す。やりたい！

で準備完了。さあ内製化！

内製化

11マン以上に導入しているでかいwebシステム

スピード感
継続的な開発サイクル
監視

今までは見積もりがかかったりするので、内製化でスピードアップを！

PCFを導入

求めるもの
- リリース改善
- 速さ、品質
- クラウドの活用
- スケーラブル、オートスケール etcd

Kubernetes or Paasどっち？=> 実績のあるプラットフォームがいいな〜

Public PaaS or Private PaaS？→セキュリティ問題でPrivate PaaSを選択

Pivotal Cloud Foundly

cf pushでソースコードからコンテナを作ってくれる。Dockerfileを使わなくていい。

責任分界がはっきりする。 PlatformチームはPlatformに集中できるのがいいよね！

ソフトウェアの話

アプリケーション構成はスライド参照

改良できないシステムも絡むシステムに対するアーキテクチャ

ポイントはCircuit Breaker。
とある決済期間Aに障害がある=> Circuit Breakerが状況把握してくれる。いいよね

CIサーバー concourse

Observability

ロギング Kibana
開発者は標準出力にログ吐くだけでいい。楽っすね

Zipkin。サーバー負荷がかかる

サービスの可視化。決済のOK/NGを可視化してるみたい。ビジネス

アプリをリリースするだけで、プラットフォームが自動的に監視をしてくれる。か、いいな

最後に

ベンダにお任せじゃなく自分たちで開発するからこそ、プラットフォームが構築できる！いいセリフ

金融領域におけるOpenStack導入事例の紹介(Masanori Sato/ワイジェイFX株式会社, Hikaru Saito/ワイジェイFX株式会社)

YJFXというサービスでのOpenStack導入の話。FXなので瞬間の情報が取得できないといけない、理論値で5,000 transaction/sec x 単価数 x Bank数 = 1,000,000程度の負荷がかかることを想定しないといけない！
という大変なシステムに対してコスト、デリバリでの限界が来たためPrivate Cloudを構築しようという話でした。

OSSへの考え方(採用するなら、が安定しない・サポートが遅いといったことがあってもしょうがないという心意気)と、以下のような組織文化に関する考え方が非常に刺激になりました。

講演メモ

YJFXについて

Yahoo JapanのFX事業
銀行、投資家の間での為替両替をするためのなんやかんや
障害以外にスループットが大事。変動が瞬間的
- 瞬間的に大きく変動。5,000 transaction/sec程度の変動
- 5,000 transaction/sec x 単価数 x Bank数 = 1,000,000程度まで想定しないと！

この中での課題、解決方法

実際にどうしたのよ？の話

問題
- コスト。やりたいことが増えるけど、減っていくことがない。エラスティックじゃない
- デリバリ。アプリケーションチームがクラウドを触ることができなかった。
なのでPrivate Cloud基盤をやりたいよね
- RedhatさんのOpenStack Platformを導入

結果

Ansibleの活用
- 100以上のVMを30分でできるような環境を作る Cloudに合わせた考え方に切り替えないと、クラウド、サーバーをペットではなく、家畜のように扱え！
- 普段から活用してない環境では辛い
トラブルシューティング
- 動かなかった時どうするのよ？って時にサポート問い合わせ。回答を待てない
- ドキュメント読む。結局言ってることよくわからん
  - ソースを読むってことになる
- 環境導入は簡単なものではない。コードが全て！ってやる人がOpenStackを使うべき
- ですよね〜
導入による影響
- 少しずつ導入し、活動していくことで、チーム・会社からの見え方も変わってくる。

今後

Amazon銀行、LINE証券といったサービス事業者が参入してくる。
規制も強い

→パフォーマンスをあげないとね

Cloud Nativeを強めていこう。今はただクラウドにサーバー乗せてるだけだよね！
そうじゃなくてクラウドの性質を理解したアプリケーションの設計を進めていく必要がある。

技術負債の対応は課題解決。

Change the Game, Change the World(Shingo Kitayama/レッドハット株式会社)

Platformについての考え方についての講演。自分たちは創る側？活用する側？を考えて、そのうえで適切なことをやりましょうよって話だと認識してます。

講演メモ

はじめに

kubernetes => Platform on Platform. platformを作るためのツールなんすよ〜

プラットフォームについて

airbnbというplatformについて
ものの提供+どうしたら楽しいかのサービス、仲介先の人たちがみんな喜ぶものを作る

プラットフォームは、利用コストよりも得られる価値の方が高い、みんなが喜ぶものが大事ですよ
相互ネットワーク + 外部ネットワーク効果(Twitterみたいなコミュニティ)

システム観点、Kubernetes is the Linux of cloudなのか
- velocity
- Self Healing
- Abstraction
サービス観点、Kubernetes is a platform
- 早くデプロイできればアプリ管理者は嬉しい
- 運用管理者は設定だけで勝手に回復してくれる。といった嬉しさがあるよね
- でも、これってまだ足りんよね。コストの方が低いとはいえない状態

Cloud +Nativeとは？
- 運用工数を下げるためのポイントが、既存システム運用とは大きく変わるという意識改革がないといけんよね

Redhatの意識

Operator Container

https://qiita.com/shotat/items/4a60083fd20d11936860

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

OperatorHub.ioとOperatorの認定

Redhatがサポート。

Operatorを介してKubernetesを入れるのが楽になる

lean.openshift.comでOperatorを作れますよ

最後に

プラットフォームを創る側？活用する側？ってのを考えようぜ

OpenStackを用いたパブリッククラウドの国内事例と課題 (Masahiro Nakazato/GMOインターネット株式会社)

お名前.comなどを運営している会社の話。スライド探し中
メモが無くてすいません。難しいことをすると大変なことになる的なことを言ってたのが印象的でした。

Day 2, Others

100行のコードでDockerの基本を実現せよ！(Wenhan Shi/Canonical Japan k.k)

Dockerをshellで作ろうという試みを通じて、dockerの仕組みに触れようという話。
https://github.com/xibuka/bocker

実際のshellを通してファイルシステムやプロセス管理をどのように行っているかが分かる、面白い講演でした。

講演メモ

bashでdockerを実現してるやつ。これを最新にしている

やってることは、docker hubにアクセスして、imageを落としてきてなんやかんやする。
DockerHubのAPI仕様を理解しようぜ！って話

slideはtwitterにあるらしいので

docker hubと連携するため、認証を制御

- tokenを取得して、ヘッダー認証
組み込みのflash書き換えみたいなことをして、イメージを残しつつ書き込みができるようにしている。
BTRFS(バターFS)

どうやってDockerが構成されているかって話。面白い

Namespaceという仕組み。その中だけが参照できる

https://qiita.com/ryuichi1208/items/11b6bd3b0445fcf21aab

子供のプロセスは知ってはいるけど、Namespace毎に番号が変わる。
- コマンドでnamespace controll
chrootでルート変更
Network

snat, dnatを有効に

実録！CloudNativeを目指した230日(TAKAISHI Ryo/GMOペパボ)

kubernetesを本番環境に導入した実録。CloudNativeを目指し、人とオペレーションがボトルネックとなっていた部分を改善しようと取り組んでいた姿勢に、非常に共感を持ちました。
k8sを文化に馴染ませるためにすぐ触れる環境と作る、自動化を目指すにはまず手で出来る状態が必要といった地に足付いたコメントが印象的でした。