CloudNativeをなぜ実践するのか？ / Why practive CloudNative

by Daichi Yamaguchi

Slide 1

Slide 1 text

Cloud Nativeをなぜ実践するのか？ CloudNative Nagoya #2 2019/7/30 山口大地

Slide 2

Slide 2 text

自己紹介氏名：山口大地（@dayamaguchi1）所属会社：株式会社エイチームライフスタイル［担当］・AWSインフラ全般［その他］・名古屋のIT界隈を盛り上げていきたい人

Slide 3

Slide 3 text

資料は後で公開します

Slide 4

Slide 4 text

今日は理想論ばかり話します現実的には・・・とネガティブにならず、ワクワクを忘れずに！

Slide 5

Slide 5 text

CloudNative なんもわからん CloudNative わかってきた本日のテーマ ※ネットスラング的な意味ではなく、文字通りの意味で捉えてください

Slide 6

Slide 6 text

ゴールやりたくなってきた！

Slide 7

Slide 7 text

まずはまとめから ● IT の驚異的な進化に立ち向かうため、必要になっていく ● CloudNative が今後の IT における標準的な立ち位置になる ● CloudNative やりたいけど、やっぱり色々と辛いこともある ○ 新技術であり、新しく覚える事が多い ○ 既存技術の理解も必要 ○ アップデート早すぎ ● 大きな可能性があり、既にパラダイムシフトが発生している

Slide 8

Slide 8 text

そもそもCloudNativeって何？

Slide 9

Slide 9 text

CloudNativeという単語を鵜呑みすると・・・ Cloud （事業者） Native （生まれたもの）だから、 IaaS 事業者の VirtualMachine を使ってれば、 CloudNative だよね！！！！！！

Slide 10

Slide 10 text

CloudNativeという単語を鵜呑みすると・・・ Cloud （事業者） Native （生まれたもの）だから、 IaaS 事業者の VirtualMachine を使ってれば、クラウドだよね！！！！！！そんなわけない

Slide 11

Slide 11 text

CNCF (Cloud Native Computing Foundation) 定義スケーラブルなアプリケーションを構築および実行する能力を組織にもたらす

Slide 12

Slide 12 text

回復性(Resilient) 管理力(Manageable) 可観測性(Observable) 堅牢な自動化（robust automation）インパクトのある変更を最小限労力での頻度(high-impuct changes frequently) かつ予測通り(predictably) に実行できる https://github.com/cncf/toc/blob/master/DEFINITION.md

Slide 13

Slide 13 text

CNCFによる定義の要点 ● 代表的な技術として、コンテナ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型 API があげられる ○ イミュータブルインフラストラクチャ＝構築してから変更を加えられないインフラ（変更したいなら作り直す） ○ 宣言的 API ＝どういう状態が正常かを定義し、常にその状態を保つ ■ 構築するための方法を書くのではなく、どういう状態にしたいかという目的を書く手法

Slide 14

Slide 14 text

CNCF TrailMap Cloud Native Journey https://github.com/cncf/trailmap

Slide 15

Slide 15 text

CloudNative登場前についておさらい

Slide 16

Slide 16 text

物理サーバを用意する（オンプレミス）

Slide 17

Slide 17 text

物理サーバを用意する（オンプレミス）サーバをどこに置く？自社ビル？他社 DC？どこに搭載する？ラックはおける？重量は？電源は？分電盤ある？コンセント形状は？UPSは？ネットワークは？機器ある？ポート数は？サーバのパーツ構成は？スペックは？可用性は？商流は？どこから買う？保守契約はどうする？

Slide 18

Slide 18 text

物理サーバを用意する（オンプレミス）サーバをどこに置く？自社ビル？他社 DC？どこに搭載する？ラックはおける？重量は？電源は？分電盤ある？コンセント形状は？UPSは？ネットワークは？機器ある？ポート数は？サーバのパーツ構成は？スペックは？可用性は？商流は？どこから買う？保守契約はどうする？スムーズに決定できても、月単位で納品待ち時間的コストが大きすぎる

Slide 19

Slide 19 text

使いたいときに使いたいだけのリソースをデータセンター管理からの解放 ↓ IaaS事業者を使おう！

Slide 20

Slide 20 text

IaaS事業者を利用する

Slide 21

Slide 21 text

IaaS事業者を利用する IaaS事業者が撤退したらどうする？オンプレに戻せる？別事業者に切り替えれる？ OSのEOL対応は？採用したパッケージの脆弱性対応は？実行環境が多様すぎて把握できないデプロイは相変わらず煩雑なまま

Slide 22

Slide 22 text

IaaS事業者を利用する IaaS事業者が撤退したらどうする？オンプレに戻せる？別事業者に切り替えれる？ OSのEOL対応は？採用したパッケージの脆弱性対応は？実行環境が多様すぎて把握できないデプロイは相変わらず煩雑なまま物理環境からは解放されても、 OSより上は変わっていない

Slide 23

Slide 23 text

IaaS事業者を利用する IaaS事業者が撤退したらどうする？オンプレに戻せる？別事業者に切り替えれる？ OSのEOL対応は？採用したパッケージの脆弱性対応は？実行環境が多様すぎて把握できないデプロイは相変わらず煩雑なまま物理環境からは解放されても、 OSより上は変わっていない IaaS固有の管理オブジェクトが増大マネージドサービスってどう管理するの？管理対象、増えてない？ Microservice使えば解決する？

Slide 24

Slide 24 text

Q: マネージドサービス使えば？

Slide 25

Slide 25 text

A: 性能やコストやチューニング機能やSLA が満たせれば使ってるよ！

Slide 26

Slide 26 text

IaaS事業者を利用するだけでは、 OSの恩恵（≒呪縛）から、逃れられない

Slide 27

Slide 27 text

だから、CloudNativeを実践したい

Slide 28

Slide 28 text

CloudNativeの実践によって変わること物理環境ハイパーバイザ OS ミドルウェアアプリケーションオンプレミス物理環境ハイパーバイザ OS ミドルウェアアプリケーション IaaS

Slide 29

Slide 29 text

CloudNativeの実践によって変わること物理環境ハイパーバイザ OS ミドルウェアアプリケーションオンプレミス物理環境ハイパーバイザ OS ミドルウェアアプリケーション IaaS 物理環境ハイパーバイザ OS ミドルウェアアプリケーション CloudNative コンテナオーケストレータコンテナ

Slide 30

Slide 30 text

CloudNativeの実践によって変わること物理環境ハイパーバイザ OS ミドルウェアアプリケーションオンプレミス物理環境ハイパーバイザ OS ミドルウェアアプリケーション IaaS 物理環境ハイパーバイザ OS ミドルウェアアプリケーション CloudNative コンテナオーケストレータコンテナコンテナオーケストレータ(k8s)が共通なら、下の階層を問わないパラダイムシフトが発生している ※データを代表に、まだまだ検討しなければならないポイントはあります

Slide 31

Slide 31 text

Kubernetesという共通点があるから、 Kubernetesには可搬性がある

Slide 32

Slide 32 text

Kubernetesの登場によって、抽象度レイヤーが1UPした

Slide 33

Slide 33 text

では、改めて

Slide 34

Slide 34 text

CloudNativeを実践して、本当に実現したいことは何か？

Slide 35

Slide 35 text

「より早くサービスを顧客に提供する」仮に上記をミッションに据えた場合、デプロイの高速化が必要になる

Slide 36

Slide 36 text

Non CloudNativeな構成だと ● 変更による影響が把握できず、変更前に調査が必要 ○ Non predictably ● ミュータブルな状態であり変更管理が出来ず、 OS 再構築時の再現性が難しい ○ Non Imutable Infrastructure ● プロセスダウンした障害に対して、対応が手動オペレーション ○ Non resilient ● OS やマネージドサービス間の通信連携が把握できず、変更した際に予想外の問題が生じてしまう ○ Non observable

Slide 37

Slide 37 text

Non CloudNativeな構成だと ● 変更による影響が把握できず、変更前に調査が必要（ Non predictably ） ● ミュータブルな状態であり変更管理が出来ず、 OS 再構築時の再現性が難しい（ Non Imutable Infrastructure ） ● プロセスダウンした障害に対して、対応が手動オペレーション（ Non resilient ） ● OS やマネージドサービス間の通信連携が把握できず、変更した際に予想外の問題が生じてしまう（ Non observable ）これらの課題を解決し、ミッションを完遂するこの思想こそが、 CloudNativeのコアであると私は考えます

Slide 38

Slide 38 text

具体的にCloudNativeにすることで得られる恩恵 ● オンプレ、クラウド問わず、 Kubernetes という共通のプラットフォームでアプリケーションを動かせる ● yaml ファイルで定義化されたインフラストラクチャは、常にイミュータブル性を保持できる ● サービスメッシュによるトラフィック制御やトレース、可視化による可観測性の取得 ● 宣言的 API によるコンテナ停止時の自動回復

Slide 39

Slide 39 text

Slide 40

Slide 40 text

キラキラしすぎたので、辛い話もする

Slide 41

Slide 41 text

辛いこと ● オンプレ→ IaaS へ移管の場合、 OS より上の領域は変わらない ○ スキルをそのままスライドできる領域が大きく、学習コストが低い ■ もちろん IaaS 固有の学習は追加で必要 ● この状態で Docker や Kubernetes が登場すると・・・ ○ 定義ファイルの記述方法を新しく学ぶ ○ Kubernetes オブジェクトで何ができるか理解するため、新しく学ぶ ○ アプリケーションのステートレス化 → 学習コスト大＆アプリケーションの設計変更が必須

Slide 42

Slide 42 text

まだまだ続くよ、辛いこと ● Kubernetes を理解する上で、 Linux の理解は避けて通れない ○ 今までよりももっと理解していく必要がある ○ マネージド Kubernetes を利用すればある程度は軽減可能 ● サービスメッシュやるなら TCP/IP への理解も必要 ● ましてや Kubernetes を取り巻く大量のエコシステム群まで考えると・・・ ○ 数多ある CI/CD 、 Monitoring 、 Service Mesh 、 Distributed DB のツール群 ○ どれが自組織にとって最適なツールか、判断できるのか？

Slide 43

Slide 43 text

辛い

Slide 44

Slide 44 text

それでも辛くてもやる

Slide 45

Slide 45 text

辛くてもやる理由 ● デジタルトランスフォーメーションにより、破壊的イノベーションは随所に発生している ● 自分が所属する組織がいつまで存続しているのか、誰も保証できない ○ それにも関わらず・・・ ■ デプロイするのに 1 日・・・ ■ 脆弱性対策するためにパッチ適用するのに１週間・・・ ■ OS や M/W の EOL 対応するのに 1 ヶ月・・・

Slide 46

Slide 46 text

Slide 47

Slide 47 text

CloudNativeを実現できると ● 組織にとって ○ より早くサービスを利用者に提供でき、競合他社と差別化できる ● エンジニアにとって ○ OS レイヤーより１歩上に前進した、新技術を学ぶ楽しさ ○ もはや「流行り」「ブーム」ではない、成熟されてきた技術を取得することでの、エンジニアとしての市場価値向上

Slide 48

Slide 48 text

勘違いしてはいけないこと ● 全て CloudNative 化する必要はない ○ 変更が少ないアプリケーションは恩恵が少ない ■ 例えば社内インフラ。停止しても影響の少ないシステムなど ○ CPU 、メモリといったリソースを大量消費するもの ■ 集約率に影響する ● モノリシック＝悪ではない ○ 向き不向きがあるだけ ○ モノリシック以外の選択肢として CloudNative が出てきたと捉える

Slide 49

Slide 49 text

9.2% [ITmedia] 国内で Docker コンテナを本番利用している企業は 9.2 ％、コンテナオーケストレーションツールは Kubernetes がデファクト https://www.itmedia.co.jp/news/articles/1907/22/news087.html

Slide 50

Slide 50 text

まだまだこれからです

Slide 51

Slide 51 text

始めよう。CloudNative

Slide 52

Slide 52 text

まとめ ● IT の驚異的な進化に立ち向かうために、必要になっていく ● 今後の IT インフラにおける標準的な立ち位置になる ● CloudNative やりたいけど、やっぱり色々と辛いこともある ○ 新技術であり、新しく覚える事が多い ○ 既存技術の理解も必要（ Linux,N/W,M/W ） ○ アップデート早すぎ ● 大きな可能性があり、既にパラダイムシフトが発生している