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

Transcript

1. Cloud Nativeを なぜ 実践するのか？ CloudNative Nagoya #2 2019/7/30 山口 大地
2. 自己紹介 氏名：山口 大地（@dayamaguchi1） 所属会社：株式会社エイチームライフスタイル ［担当］ ・AWSインフラ全般 ［その他］ ・名古屋のIT界隈を盛り上げていきたい人
3. 資料は後で公開します
4. 今日は理想論ばかり話します 現実的には・・・ とネガティブにならず、 ワクワクを忘れずに！
5. CloudNative なんもわからん CloudNative わかってきた 本日のテーマ ※ネットスラング的な意味ではなく、文字通 りの意味で捉えてください
6. ゴール やりたくなってきた！
7. まずはまとめから • IT の驚異的な進化に立ち向かうため、必要になっていく • CloudNative が今後の IT における標準的な立ち位置になる • CloudNative やりたいけど、やっぱり色々と辛いこともある ◦ 新技術であり、新しく覚える事が多い ◦ 既存技術の理解も必要 ◦ アップデート早すぎ • 大きな可能性があり、既にパラダイムシフトが発生している
8. そもそもCloudNativeって何？
9. CloudNativeという単語を鵜呑みすると・・・ Cloud （事業者） Native （生まれたもの）だから、 IaaS 事業者の VirtualMachine を使ってれば、 CloudNative だよ ね！！！！！！
10. CloudNativeという単語を鵜呑みすると・・・ Cloud （事業者） Native （生まれたもの）だから、 IaaS 事業者の VirtualMachine を使ってれば、クラウドだよ ね！！！！！！ そんなわけない
11. CNCF (Cloud Native Computing Foundation) 定義 スケーラブルなアプリケーションを構 築および実行する能力を組織にもた らす
12. 回復性(Resilient) 管理力(Manageable) 可観測性(Observable) 堅牢な自動化 （robust automation） インパクトのある変更を最小限労力での頻度(high-impuct changes frequently) かつ 予測通り(predictably) に実行できる https://github.com/cncf/toc/blob/master/DEFINITION.md
13. CNCFによる定義の要点 • 代表的な技術として、コンテナ、マイクロサービス、イミュータブルインフラス トラクチャ、宣言型 API があげられる ◦ イミュータブルインフラストラクチャ＝構築してから変更を加えられないインフラ （変更したいなら作り直す） ◦ 宣言的 API ＝どういう状態が正常かを定義し、常にその状態を保つ ▪ 構築するための方法を書くのではなく、どういう状態にしたいかという目的 を書く手法
14. CNCF TrailMap Cloud Native Journey https://github.com/cncf/trailmap
15. CloudNative登場前についておさらい
16. 物理サーバを用意する（オンプレミス）
17. 物理サーバを用意する（オンプレミス） サーバをどこに置く？自社ビル？他社 DC？ どこに搭載する？ラックはおける？重量は？ 電源は？分電盤ある？ コンセント形状は？UPSは？ ネットワークは？機器ある？ポート数は？ サーバのパーツ構成は？スペックは？ 可用性は？ 商流は？どこから買う？ 保守契約はどうする？
18. 物理サーバを用意する（オンプレミス） サーバをどこに置く？自社ビル？他社 DC？ どこに搭載する？ラックはおける？重量は？ 電源は？分電盤ある？ コンセント形状は？UPSは？ ネットワークは？機器ある？ポート数は？ サーバのパーツ構成は？スペックは？ 可用性は？ 商流は？どこから買う？ 保守契約はどうする？ スムーズに決定できても、月単位で納品待ち 時間的コストが大きすぎる
19. 使いたいときに使いたいだけの リソースを データセンター管理からの解放 ↓ IaaS事業者を使おう！
20. IaaS事業者を利用する
21. IaaS事業者を利用する IaaS事業者が撤退したらどうする？ オンプレに戻せる？別事業者に切り替えれる？ OSのEOL対応は？ 採用したパッケージの脆弱性対応は？ 実行環境が多様すぎて把握できない デプロイは相変わらず煩雑なまま
22. IaaS事業者を利用する IaaS事業者が撤退したらどうする？ オンプレに戻せる？別事業者に切り替えれる？ OSのEOL対応は？ 採用したパッケージの脆弱性対応は？ 実行環境が多様すぎて把握できない デプロイは相変わらず煩雑なまま 物理環境からは解放されても、 OSより上は変わっていない
23. IaaS事業者を利用する IaaS事業者が撤退したらどうする？ オンプレに戻せる？別事業者に切り替えれる？ OSのEOL対応は？ 採用したパッケージの脆弱性対応は？ 実行環境が多様すぎて把握できない デプロイは相変わらず煩雑なまま 物理環境からは解放されても、 OSより上は変わっていない IaaS固有の管理オブジェクトが増大 マネージドサービスってどう管理するの？ 管理対象、増えてない？ Microservice使えば解決する？
24. Q: マネージドサービス使えば？
25. A: 性能やコストやチューニング機能やSLA が満たせれば使ってるよ！
26. IaaS事業者を利用するだけでは、 OSの恩恵（≒呪縛）から、 逃れられない
27. だから、CloudNativeを実践したい
28. CloudNativeの実践によって変わること 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション オンプレミス 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション IaaS
29. CloudNativeの実践によって変わること 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション オンプレミス 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション IaaS 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション CloudNative コンテナ オーケストレータ コ ン テ ナ
30. CloudNativeの実践によって変わること 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション オンプレミス 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション IaaS 物理環境 ハイパーバイザ OS ミドルウェア アプリケーション CloudNative コンテナ オーケストレータ コ ン テ ナ コンテナオーケストレータ(k8s)が共通なら、 下の階層を問わない パラダイムシフトが発生している ※データを代表に、まだまだ検討しなければならないポイントはあります
31. Kubernetesという共通点があるから、 Kubernetesには可搬性がある
32. Kubernetesの登場によって、 抽象度レイヤーが1UPした
33. では、改めて
34. CloudNativeを実践して、 本当に実現したいことは何か？
35. 「より早くサービスを顧客に提供する」 仮に上記をミッションに据えた場合、 デプロイの高速化が必要になる
36. Non CloudNativeな構成だと • 変更による影響が把握できず、変更前に調査が必要 ◦ Non predictably • ミュータブルな状態であり変更管理が出来ず、 OS 再構築時の再現性が難 しい ◦ Non Imutable Infrastructure • プロセスダウンした障害に対して、対応が手動オペレーション ◦ Non resilient • OS やマネージドサービス間の通信連携が把握できず、変更した際に予想 外の問題が生じてしまう ◦ Non observable
37. Non CloudNativeな構成だと • 変更による影響が把握できず、変更前に調査が必要（ Non predictably ） • ミュータブルな状態であり変更管理が出来ず、 OS 再構築時の再現性が難 しい（ Non Imutable Infrastructure ） • プロセスダウンした障害に対して、対応が手動オペレーション（ Non resilient ） • OS やマネージドサービス間の通信連携が把握できず、変更した際に予想 外の問題が生じてしまう（ Non observable ） これらの課題を解決し、 ミッションを完遂する この思想こそが、 CloudNativeのコアであると 私は考えます
38. 具体的にCloudNativeにすることで得られる恩恵 • オンプレ、クラウド問わず、 Kubernetes という共通のプラットフォームでアプリ ケーションを動かせる • yaml ファイルで定義化されたインフラストラクチャは、常にイミュータブル性 を保持できる • サービスメッシュによるトラフィック制御やトレース、可視化による可観測性の 取得 • 宣言的 API によるコンテナ停止時の自動回復
39. 具体的にCloudNativeにすることで得られる恩恵 • オンプレ、クラウド問わず、 Kubernetes という共通のプラットフォームでアプリ ケーションを動かせる • yaml ファイルで定義化されたインフラストラクチャは、常にイミュータブル性 を保持できる • サービスメッシュによるトラフィック制御やトレース、可視化による可観測性の 取得 • 宣言的 API によるコンテナ停止時の自動回復 ワクワクしませんか？
40. キラキラしすぎたので、辛い話もする
41. 辛いこと • オンプレ→ IaaS へ移管の場合、 OS より上の領域は変わらない ◦ スキルをそのままスライドできる領域が大きく、学習コストが低い ▪ もちろん IaaS 固有の学習は追加で必要 • この状態で Docker や Kubernetes が登場すると・・・ ◦ 定義ファイルの記述方法を新しく学ぶ ◦ Kubernetes オブジェクトで何ができるか理解するため、新しく学ぶ ◦ アプリケーションのステートレス化 → 学習コスト大 ＆ アプリケーションの設計変更が必須
42. まだまだ続くよ、辛いこと • Kubernetes を理解する上で、 Linux の理解は避けて通れない ◦ 今までよりももっと理解していく必要がある ◦ マネージド Kubernetes を利用すればある程度は軽減可能 • サービスメッシュやるなら TCP/IP への理解も必要 • ましてや Kubernetes を取り巻く大量のエコシステム群まで考えると・・・ ◦ 数多ある CI/CD 、 Monitoring 、 Service Mesh 、 Distributed DB のツール群 ◦ どれが自組織にとって最適なツールか、判断できるのか？
43. 辛い
44. それでも 辛くても やる
45. 辛くてもやる理由 • デジタルトランスフォーメーションにより、破壊的イノベーションは随所 に発生している • 自分が所属する組織がいつまで存続しているのか、誰も保証できない ◦ それにも関わらず・・・ ▪ デプロイするのに 1 日・・・ ▪ 脆弱性対策するためにパッチ適用するのに１週間・・・ ▪ OS や M/W の EOL 対応するのに 1 ヶ月・・・
46. 辛くてもやる理由 • デジタルトランスフォーメーションにより、破壊的イノベーションは随所 に発生している • 自分が所属する組織がいつまで存続しているのか、誰も保証できない ◦ それにも関わらず・・・ ▪ デプロイするのに 1 日・・・ ▪ 脆弱性対策するためにパッチ適用するのに１週間・・・ ▪ OS や M/W の EOL 対応するのに 1 ヶ月・・・ やめたいですよね？
47. CloudNativeを実現できると • 組織にとって ◦ より早くサービスを利用者に提供でき、競合他社と差別化できる • エンジニアにとって ◦ OS レイヤーより１歩上に前進した、新技術を学ぶ楽しさ ◦ もはや「流行り」「ブーム」ではない、成熟されてきた技術を取得す ることでの、エンジニアとしての市場価値向上
48. 勘違いしてはいけないこと • 全て CloudNative 化する必要はない ◦ 変更が少ないアプリケーションは恩恵が少ない ▪ 例えば社内インフラ。停止しても影響の少ないシステムなど ◦ CPU 、メモリといったリソースを大量消費するもの ▪ 集約率に影響する • モノリシック＝悪ではない ◦ 向き不向きがあるだけ ◦ モノリシック以外の選択肢として CloudNative が出てきたと捉える
49. 9.2% [ITmedia] 国内で Docker コンテナを本番利用している企業は 9.2 ％、 コンテナオーケストレーションツールは Kubernetes がデファクト https://www.itmedia.co.jp/news/articles/1907/22/news087.html
50. まだまだこれからです
51. 始めよう。CloudNative
52. まとめ • IT の驚異的な進化に立ち向かうために、必要になっていく • 今後の IT インフラにおける標準的な立ち位置になる • CloudNative やりたいけど、やっぱり色々と辛いこともある ◦ 新技術であり、新しく覚える事が多い ◦ 既存技術の理解も必要（ Linux,N/W,M/W ） ◦ アップデート早すぎ • 大きな可能性があり、既にパラダイムシフトが発生している
53. 辛い ＜ ワクワク １人でも上な状態にできたら最高です
54. お し ま い