飛び込もう、Cloud Nativeの世界

飛び込もう、Cloud Nativeの世界

CloudNative Days Fukuoka 2019のKeynoteで発表した資料です。
『クラウドネイティブとは?』と、改めて意味を考えてみました。 その上で、どうやってクラウドネイティブを取り入れていくべきかを解説します。

(CC BY-SA 2.0)

Cbc297b07593321e52c75a9ebcc0f843?s=128

Kazuto Kusama

April 16, 2019
Tweet

Transcript

  1. 飛び込もう Cloud Nativeの世界

  2. 『クラウドネイティブ』 出来てますか?

  3. ▶ 出来てない そもそもクラウドネイティブとは? ▶ 出来てる! 是非、これからの発表を聞いてください。 何かヒントが得られるかもしれません。 是非、これからも続けてください。 これからの発表は、クラウドネイティブの良さを他の人に 伝えるための『表現のひとつ』になるかも

  4. KAZUTO KUSAMA @jacopen 4 Solutions Architect @

  5. 5

  6. Cloud Native is... クラウドネイティブとは何でしょう?

  7. Cloud Native is... クラウドネイティブとは、コンテナです。みな さん、Docker使ってますか?

  8. Cloud Native is... 次に、Kubernetesです。コンテナをうまい ことスケジュールしていい感じに扱ってくれ ます。

  9. Cloud Native is... あと、マイクロサービスにするのも大事です。 コンテナ・Kubernetes・マイクロサービスで作って いくこと。これがクラウドネイティブなのです。

  10. っていう説明を読んだことありませんか?

  11. 間違ってはいない・・・のだけど 11 もしあなたがPHPやRuby on Railsで 小規模アプリを開発しているとして・・・ クラウドネイティブとはMicroservicesである と言われて、どう思うか?

  12. 間違ってはいない・・・のだけど 12 もしあなたがPHPやRuby on Railsで 小規模アプリを開発しているとして・・・ クラウドネイティブとはMicroservicesである と言われて、どう思うか? 俺には 関係ないや

  13. クラウドネイティブは『大規模』でしか 必要が無いのだろうか?

  14. 伝えたいこと 14 クラウドネイティブは規模に関係なく 実践してくべき

  15. Definition クラウドネイティブ技術は パブリッククラウド プライベートクラウド ハイブリッドクラウドなどの 近代的でダイナミックな環境において スケーラブルなアプリケーションを 構築および実行するための能力を 組織にもたらします。 https://github.com/cncf/toc/blob/master/DEFINITION.md

    より引用
  16. Definition クラウドネイティブ技術は パブリッククラウド プライベートクラウド ハイブリッドクラウドなどの 近代的でダイナミックな環境において スケーラブルなアプリケーションを 構築および実行するための能力を 組織にもたらします。 https://github.com/cncf/toc/blob/master/DEFINITION.md

    より引用 要はクラウド
  17. クラウドって何だっけ?

  18. Definition オンデマンド・セルフサービス 幅広いネットワークアクセス リソースの共用 スピーディーな拡張性 計測可能なサービス NISTによるクラウドコンピューティングの定義 https://www.ipa.go.jp/files/000025366.pdf より抜粋

  19. Benefit オンデマンド・セルフサービス 幅広いネットワークアクセス リソースの共用 スピーディーな拡張性 計測可能なサービス NISTによるクラウドコンピューティングの定義 https://www.ipa.go.jp/files/000025366.pdf より抜粋 使った分だけ

    課金 初期費用が 少ない リソースの 調達が早い スケール しやすい 運用を 肩代わり
  20. クラウド移行 クラウドファースト これらクラウドのメリットは魅力ですよね。なので、過去 10年に渡って、クラウド移行やクラウドファーストが持て はやされてきたのです。

  21. 使った分だけ 課金 初期費用が 少ない リソースの 調達が早い スケール しやすい 運用を 肩代わり

    クラウドの 本質? これってクラウドの本質って言えるんでしょう か? ・・・言えなくは無いんですが、一言でいう なら僕はこう言います。
  22. クラウドは人間を 強化する

  23. サーバーの調達 OS・ミドルウェアの 設定 ソフトウェアの デプロイ ストレージ・ ネットワークの 設定 その他いろいろ これまでの世界

    クラウドファーストな世界 かつてはオンプレで、全て手作業でやってました。
  24. サーバーの調達 OS・ミドルウェアの 設定 ソフトウェアの デプロイ ストレージ・ ネットワークの 設定 その他いろいろ これまでの世界

    クラウドファーストな世界 クラウドになって、サーバーやネットワークなどインフラの 準備はだいぶ楽になりましたよね。
  25. クラウドは人間を 強化する なので、クラウドという便利な道具で人間は強化されたわ けです。でも、僕はこう思ったんです。

  26. サーバーの調達 OS・ミドルウェアの 設定 ソフトウェアの デプロイ ストレージ・ ネットワークの 設定 その他いろいろ これまでの世界

    クラウドファーストな世界 ここには問題点がある
  27. L1キャッシュ参照 分岐予測ミス L2キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで1KB送る メモリから1MB連続で読む 同一のデータセンタ内のマシンと通信1往復 HDDシーク

    HDDから1MB読み出し カリフォルニアとオランダ間で通信1往復 0.5 ns 5 ns 7 ns 25 ns 100 ns 3,000 ns 10,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 150,000,000 ns かかる時間 Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832 こういう数字があります。 言いたいのは、コンピュータ の世界はμs、msの単位で動 いているってこと。
  28. L1キャッシュ参照 分岐予測ミス L2キャッシュ参照 Mutexのlock/unlock メモリ参照 1KBをZIP圧縮 1Gbpsで1KB送る メモリから1MB連続で読む 同一のデータセンタ内のマシンと通信1往復 HDDシーク

    HDDから1MB読み出し カリフォルニアとオランダ間で通信1往復 上司の許可取ってサーバー1台構築 0.5 ns 5 ns 7 ns 25 ns 100 ns 3,000 ns 10,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 150,000,000 ns 259,200,000,000,000 ns かかる時間 Latency Numbers Every Programmer Should Know https://gist.github.com/jboner/2841832 ところが人間が関わった 瞬間、こうなっちゃう。 桁が違う。それも6桁。
  29. サーバーの調達 OS・ミドルウェアの 設定 ソフトウェアの デプロイ ストレージ・ ネットワークの 設定 その他いろいろ これまでの世界

    クラウドファーストな世界 ボトルネック
  30. μs, msの世界で人間が介在すること自体が ボトルネック

  31. サーバーの調達 OS・ミドルウェアの 設定 ソフトウェアの デプロイ ストレージ・ ネットワークの 設定 その他いろいろ これまでの世界

    クラウドファーストな世界 『クラウドに置き換えて効率化』 という思考から脱却しなければ 根本的な変革にはならない
  32. クラウドは人間を 強化する クラウドを便利な道具って考えちゃ駄目なんです。 クラウドの能力を、最大限に享受するのです。 なので、こうじゃなくて

  33. クラウドは人間を 強化する Yoshizumi Endo https://www.flickr.com/photos/yendo0206/5041788308/ (CC BY-SA 2.0)

  34. CLOUD これこそが、クラウドに

  35. CLOUD NATIVE + これこそが、クラウドにネイティブになるってこと。 人間が最大限に強化されるために、 生身の人間の関与を減らすのがポイントです。

  36. Coding Test Build Delivery Monitoring Analyze でも、モビルスーツのような未 来テクノロジーは必要ないん です。 サービスのライフサイクルで、

    人間が関与しているところを 変えていけばいいんです。 そのためのアプローチを 紹介します。
  37. 37 Continuous Integration 繰り返し必要になるテストから人間を排除の関与を 無くす (排除っていうと治安が悪い感じになるんで、関与を 無くすって言いましょうか)

  38. 38 Continuous Delivery 繰り返し必要になるデリバリーから人間をの関与を 無くす

  39. 39 Infrastructure as Code インフラの構築から人間の関与を無くす

  40. 40 Orchestration ワークロード配分の作業から人間の関与を無くす

  41. 41 運用についてはどうか?

  42. 42 NoOps https://www.slideshare.net/hiromasaoka/noops-meetup-tokyo-2-opening

  43. なぜ運用は “嬉しくない” のか 43 運用をしていると、沢山の問題が発生する - サーバーのダウン、NWの障害、ストレージの・・・ - 溢れ出るログへの対処 -

    昼夜問わずの対応・・・
  44. なぜ運用は “嬉しくない” のか 44 運用をしていると、沢山の問題が発生する - サーバーのダウン、NWの障害、ストレージの・・・ - 溢れ出るログへの対処 -

    昼夜問わずの対応・・・ それを人が対応するから『嬉しくない』気持ちになる
  45. “ボールを走らせろ。ボールは疲れない。” ヨハン・クライフ

  46. クラウドを走らせろ。クラウドは疲れない。

  47. 47 復元力の高いプラットフォーム Self Healing In-Flight Renewing Adaptive Scale 『嬉しくない』ところを自動化=人間の関与を無くす

  48. 48 Continuous Integration Continuous Delivery Infrastructure as Code Orchestration Resiliency

    コンテナで高速に、 効率よくテスト コンテナイメージで 環境差分のないデプロイ Manifestで構成情報の 定義 コンテナオーケストレーターで高 速かつ高効率な配置 コンテナオーケストレーターで迅 速な回復性を持たせる
  49. 49 Continuous Integration Continuous Delivery Infrastructure as Code Orchestration Resiliency

    コンテナで高速に、 効率よくテスト コンテナイメージで 環境差分のないデプロイ Manifestで構成情報の 定義 コンテナオーケストレーターで高 速かつ高効率な配置 コンテナオーケストレーターで迅 速な回復性を持たせる
  50. 50 • 確かに、Kubernetesが欲しい要素を上手く満たしている • しかし目的は、人の関与を減らし出力を向上させること ◦ Kubernetesに限る必要は無い ◦ Serverless ◦

    PaaS ◦ マネージドサービス • Cloud Native = Kubernetes は誤解。規模に合わせて、 適したプラットフォームを選べば良い。
  51. 51 Microservicesは?

  52. 52 Microservices 人間がボトルネックになると言ってきたが 価値を生み出すのは人間にしか出来ない ⇒ よいサービスを生み出せるのは人間だけ ・・・しかし、ある程度の規模を超えると、システム的にも 組織的にもスケールしなくなってくる。 そこを乗り越える方法論がMicroservices

  53. 53 Microservices そしてそのMicroservicesを支えるために、Observabilityという概念 やService Mesh、分散トレーシングといったツールが注目されてい る 詳細はこの後に続くセッションで!

  54. Microservices = クラウドネイティブではない 導入によってボトルネックが解消される ⇒クラウドで強化されるなら、やるべき 導入によってかえって手間が増えるの ならば、無理にやる必要は無い。 必要になったとき改めて試せば良い

  55. 重要なこと

  56. 56 Docker=クラウドネイティブ Kubernetes=クラウドネイティブ ではない。 ツールやプラットフォームの導入が クラウドネイティブになるわけじゃない クラウドによって最大限に強化されるという マインドセットを持つこと=クラウドネイティブ

  57. 57 『クラウドネイティブが注目されているから、うちも Kubernetesを取り入れてみる』 ⇒マインドセットが変わらない限り、ツールの置き換えで終 わってしまう 社内の承認プロセスでリリースが1週間出来ないとか アプリ書き換えの度に手動でdocker buildとか リリース作業を手動でkubectl applyでポチポチとか

  58. 58 マインドセットが重要 = 一朝一夕では得られない ちゃんとテストを書くこと ちゃんとCIすること 無駄な手作業はせず、常に自動化の意識を持つこと ⇒ クラウドのGUIでポチポチも無駄作業の一つ こういった、地に足のついた積み重ねがあって、

    はじめてクラウドネイティブの恩恵が得られる
  59. Cloud Native Trail Map https://github.com/cncf/trailmap CNCFがTrail Mapというものを出しています。 ひとつひとつ、クラウドネイティブになるための道しる べが示されています。

  60. 事例に学ぶのも大事です。先駆者達が拓いた道を辿ることで近道になるでしょ う。ただ、マインドセットを変えていく意識は忘れずに !

  61. 7/22-23のCloudNative Days Tokyo 2019でも、皆様の役に立つセッションを沢山 揃えてあります。是非お越しください!