Tweet
Tweet

Slide 1

Slide 1 text

Copyright 2019 FUJITSU LIMITED 再編集版 Cloud NativeとKubernetes @hiro_kamezawa 0

Slide 2

Slide 2 text

レビューしていただいた全ての方に 感謝します Copyright 2019 FUJITSU LIMITED 1

Slide 3

Slide 3 text

免責事項  本ドキュメントは2019年9月に執筆されました  本ドキュメントに関する全ての責任は執筆者本人にあります  本ドキュメントは筆者の個人的な意見を表しており、組織・団体の公 式見解を示すものではありません  本ドキュメントは秘密情報は一切含みません  本ドキュメントの引用・改変・再配布はご自由に Copyright 2019 FUJITSU LIMITED 2

Slide 4

Slide 4 text

Copyright 2019 FUJITSU LIMITED  Cloud Nativeについて考えてみる コンテナの出自がわかる Cloud Nativeがなんとなくわかる Kubernetesがなんとなくわかる 目標 わかりにくいかもしれませんが 感じるところがあったり興味がわけばＯＫ Kubernetes自体の使い方などはオンラインで探してください ※Cybozuさんの新人研修資料とかいいかもしれない https://blog.cybozu.io/entry/2019/09/05/080000 3

Slide 5

Slide 5 text

最初に 【この資料を見ても具体的な使い方は一切わかりません。】  私の見方では・・という話なのでCloud Nativeについて自身で考えるための材 料と捉えてください。所詮、後付けの作文です。・・・本質は実践にあるでしょう  動いているものを見て誰かが「クラウドネイティブ」と言い出しただけです。  コンテナもマイクロサービスも「理論に従い、狙って設計したらこうなった」のではなく、「試行 錯誤していたら」こうなったということだろうと思います  “やればわかる”だと顧客に伝えたり、上司を説得する術がありませんので一遍の 戯言資料でも多少のヒントになればと存じます。  How To 資料は別途探してください。  今日の話は気楽に聞いて、実践し、自分なりに考えましょう。 Copyright 2019 FUJITSU LIMITED 4

Slide 6

Slide 6 text

目次  Ice Break  第一部：コンテナ  第二部：クラウドネイティブ  第三部：Kubernetes  おまけ、あるいは宣伝  第四部：マイクロサービス Copyright 2019 FUJITSU LIMITED 大事なことなのでもう一度 【この資料を読んでも具体的な技術は一切わかりません】 5

Slide 7

Slide 7 text

Ice Break Copyright 2019 FUJITSU LIMITED 6

Slide 8

Slide 8 text

寓話：手品師と魔法使い Copyright 2019 FUJITSU LIMITED 普段から世話している 鳩を訓練 呪文で指示すると 森から動物が集まって仕事 手品師 魔法使い 育てて芸を仕込むのが手品師 寄せ集めの動物たちを呪文であやつるのが魔法使い 7

Slide 9

Slide 9 text

寓話：ヤマタノオロチとヒュドラ Copyright 2019 FUJITSU LIMITED ８本の首で ダイジョーブ 首を１本落とすと ２本増える ヤマタノオロチ ヒュドラ あらかじめ用意したリソースで耐えるのがヤマタノオロチ ストレスに対応して自動でスケールアウトするのがヒュドラ 8

Slide 10

Slide 10 text

寓話：鉄と生命 Copyright 2019 FUJITSU LIMITED ストレスに対し 堅くて頑丈 何時か壊れる ストレスに対し 環境に適応 進化してゆく 鉄 生命 硬くて頑丈のが鉄 個々は脆く種として強いのが生命 9

Slide 11

Slide 11 text

Copyright 2019 FUJITSU LIMITED 寄せ集め 呪文で操る ストレスに自動で対応 部分は脆く全体は強い… ？ まずはコンテナの話から… 10

Slide 12

Slide 12 text

第一部：コンテナ Copyright 2019 FUJITSU LIMITED 11

Slide 13

Slide 13 text

【今まで】アプリを配備する  運用担当者がアプリケーションを配備する手番 1. 前提になるソフトウェアをインストールする 2. アプリケーションをインストールする 3. OSを含めたソフトウェアのコンフィグを調整する 4. 手順を守って起動する Copyright 2019 FUJITSU LIMITED 頑張って自動化 自動化って腐りやすい ①アプリ毎の作り込み ②OSやランタイムのバージョン違い ③緊急パッチで挙動が変わる ④属人化する、人がいなくなる 12

Slide 14

Slide 14 text

自動化の不都合な真実 Copyright 2019 FUJITSU LIMITED 最初はうまくいく バージョンを上げると死ぬ アプリ毎、ホスト毎にワンオフ 自動化でトラブル→手作業→わからない さわったら 動かなくなる 秘伝のタレ 「自動化の不都合な真実」 でぐぐってみよう 13

Slide 15

Slide 15 text

腐らない自動化のために  自動化追求の過程で「常にクリーンインストールから開始」「アプリを共存させ ない」ことで自動化の保守が楽になることが発見される(Immutable Infrastructure)  わかってきたこと→周囲の影響を受けないアプリの配布・配備手法が鍵  Go言語のスタティックバイナリで共有ライブラリ無し  アプリを丸ごとtarで固めてぶん投げる(GoogleのBorgシステム)  1VMに1アプリだけ入れ、VMイメージを常に作り直す(一時期流行った) Copyright 2019 FUJITSU LIMITED ○必要なモノは全て固め、共有しない ×貧乏根性で共有するとトラブルの元 （共有ライブラリとか発明するからあかんかったんや……..） 14

Slide 16

Slide 16 text

コンテナ化の発明  必要なものをすべて固め、展開するだけでインストール  PaaS業者のdotcloud社が自社課題の解決ツールをOSSとして出したのが”docker” Copyright 2019 FUJITSU LIMITED アプリ ライブラリ 設定 ランタイム FS ひとまとめ ※tarで固めるようなもの 必要なもの 全部入り アーカイブ コンテナ 15

Slide 17

Slide 17 text

【新しい方法】コンテナでアプリを配備する  アプリに必要なものをコンテナフォーマットで固める ベースイメージをダウンロード 必要なランタイムは全てイメージ内にインストール 必要な設定はコンテナ作成時に仕込む •動的に決まるパラメータは環境変数などで渡す Copyright 2019 FUJITSU LIMITED ダウンロードするだけでアプリ配備  運用が統一的  開発でテストしそのままを運用に適用可能  環境の影響をうけず自動化負担は軽減  Version Up, Downは置き換えるだけ 現場での秘伝のタレ醸造を防止 例えばdockerのフォーマット 16

Slide 18

Slide 18 text

実際に使うとわかるスピード感  コンテナの起動は早い ３秒くらいで起動する  以下、とっても楽になる テストの繰り返し こけたら再起動 スケールアウト Version Up. Down. Copyright 2019 FUJITSU LIMITED 17

Slide 19

Slide 19 text

変更できない(Immutable)ことの強制  コンテナの実行結果は“コンテナ内”には保存できない 再起動したら消える（コンテナへの変更内容は破棄される） Copyright 2019 FUJITSU LIMITED app …. ….. write() app 再起動  残したいデータは外に保存  起動するたび常にクリーン 捨てる運用で テストは捗る Ver.Upは 丸ごと置き換え 変更できないことでコンテナは「秘伝のたれ」化しにくい 18

Slide 20

Slide 20 text

コンテナ作成スクリプト(Dockerfile) Copyright 2019 FUJITSU LIMITED (例)Railsの公式イメージhttps://hub.docker.com/_/rails この部分がベースになる コンテナイメージ。 サポートのほしいひとは ベースイメージの出どころに注意 依存パッケージのインストール ビルド Portの公開と実行 19

Slide 21

Slide 21 text

積み重ねでコンテナを作る Copyright 2019 FUJITSU LIMITED Rails公式イメージ Ruby公式イメージ Alpine Linux #docker pull rails でダウンロードされるイメージ 重ねて Rails公式イメージ Ruby公式イメージ Alpine Linux あなたのアプリ 自分のコンテナイメージを作る 積層化したtarやzipみたいなものと思ってよい OSのカーネルは コンテナ内 に含まない 20

Slide 22

Slide 22 text

詳細に調べたわけではないので勝手なイメージに基づく デリバリのモデル Copyright 2019 FUJITSU LIMITED 21

Slide 23

Slide 23 text

中華食堂とファミレス  某中華食堂と某ファミレスは全く逆のモデルで同じ目標を達成している  目標：安い、早い、旨い  某中華食堂  チェーンとしては食材を手配、店舗側で調理（餃子などはセントラルキッチン）  現場マネージャーが責任者としてオリジナルメニューも作ることが可能  某ファミレス  セントラルキッチンで料理を配達、店舗では基本は温めて、並べるだけ  売り上げ責任は本部(料理と立地）。人とコストの責任はマネージャー。 Copyright 2019 FUJITSU LIMITED 22

Slide 24

Slide 24 text

某中華食堂モデル Copyright 2019 FUJITSU LIMITED 本社： 基本レシピ開発 仕入れ デリバリの手配 販促 食材供給元 配送センター 食材配送 配送された食材と基本レシピ を元に店舗で調理 ※一部はセントラルキッチン メリット： • 店長の裁量 • 地域毎のサービス • 有事対応力 デメリット • 良くも悪くも店長次第 • 店舗に(超人)料理人必須 • コストを下げにくい 23

Slide 25

Slide 25 text

某ファミレスモデル Copyright 2019 FUJITSU LIMITED 本社： レシピ開発 仕入れ デリバリの手配 販促 セントラルキッチン 配送センター 料理配送 セントラルキッチンで調理 店舗では温めるだけ メリット： • 現場に超人が要らない • 安定した品質 • 集中生産によるコスト低下 デメリット： • 地域毎のサービス • 緊急時の現場 24

Slide 26

Slide 26 text

コンテナデリバリ  コンテナのデリバリはファミレスに近い  料理の味について、現場に責任なし  現場運用者の能力に任せず、セントラルキッチンの品質が料理の品質  何が言えるか？  アプリ品質は開発者、インフラ品質は運用者の責任  アプリ由来のサービス品質は運用者の影響をうけにくい  アプリ作成者がテストした品質が本番で再現しやすい  責任範囲が明確化できそう  某ファミレスの場合：売り上げは本部責任、運用・コストは店長責任  SIの場合：アプリはアプリ屋、インフラリソースはインフラ屋 Copyright 2019 FUJITSU LIMITED 25

Slide 27

Slide 27 text

ただし…道具も運用も変わる Copyright 2019 FUJITSU LIMITED 26

Slide 28

Slide 28 text

（脱線）良し悪しではない…好みの問題  職人を養成して地域に密着した店づくり  人に投資  確率的に事故やばらつきを織り込む  （人員が優秀なら）非常事態に強い  規格をそろえて全国一律の安定サービス  設備に投資  安定する  極端な有事のケースに弱い Copyright 2019 FUJITSU LIMITED 好き嫌い、ビジネスコンセプト や競争戦略の作り方の話 ※戦えてさえいれば良い悪い ではない 最終的には有事対応でそれ ぞれ工夫が必要 27

Slide 29

Slide 29 text

コンテナによるアプリ配備 Copyright 2019 FUJITSU LIMITED アプリはコンテナにすべて詰め込み 運用はダウンロードして並べるだけ コンテナアプリはVM上で同居しても互いに干渉しない セントラルキッチンのようにアプリを配備 28

Slide 30

Slide 30 text

経験者は語る  良いところ アプリを知らない人でも立ち上げられる(Railsを知らずにRedmineとか) 開発元でのテスト済アプリがそのまま立ち上げられる バージョン変更が一瞬  悪いところ Dockerだけだとイマイチ足りない Networkのデバッグが大変 現場でいじりづらい Copyright 2019 FUJITSU LIMITED 入門するところとしては “docker”運用は 総じてポジティブに とらえてよいと思う 29

Slide 31

Slide 31 text

コンテナあるある  コンテナ化しようとしたがIPアドレス構成が固定でないと動かない  ベースイメージのOS版のせいでサポートが受けられない  ビルドのたびにapt-getしてたらバージョンがわからなくなった  カーネルに影響を受ける挙動があり、ホストOSで動きが変わる  PROXYのせいでビルドがくそ重たい  コンテナ化したが配れない  案外コンテナ化はできちゃう Copyright 2019 FUJITSU LIMITED 30

Slide 32

Slide 32 text

第二部：Cloud Native Copyright 2019 FUJITSU LIMITED 31

Slide 33

Slide 33 text

クラウド：リソース調達方法の変化  計画的な調達 Copyright 2019 FUJITSU LIMITED  On Demand 計画・発注 サーバ API サーバ I need ”必要な時に必要なだけ”リソースが取り出せる クラウド 32

Slide 34

Slide 34 text

Copyright 2019 FUJITSU LIMITED ではクラウドネイティブとは何か？ 33

Slide 35

Slide 35 text

クラウドでの逆転 Copyright 2019 FUJITSU LIMITED HW OS MW App  非クラウド  クラウド HW OS MW App 組み上げ 呼び出し 宣言(要求)すれば下位レイヤが自動的に割り当たる アプリケーションファースト 発想を変えよう 34

Slide 36

Slide 36 text

アプリケーションファーストとコンテナ Copyright 2019 FUJITSU LIMITED HW ライブラリ App 呼び出し コンテナ OS コンテナは「アプリ+MW+OS」の取り扱いを共通化 下位レイヤへの宣言・要求の共通フォーマットが確立 コンテナ＝アプリ層とインフラ層を分断し、従属関係を断ち切る技術 コンテナがアプリケーションファーストを加速 ランタイム 35

Slide 37

Slide 37 text

アプリケーションファースト まずアプリのコンテナがあり リソースを要求すると リソースが割り当たる Copyright 2019 FUJITSU LIMITED リソースを意識せず アプリをつくるのが Cloud Native??? もう一声 36

Slide 38

Slide 38 text

インフラの脆さ  クラウドではインフラ運用を基本的に他者に委ねる ⇒インフラは他力本願と考えるしかない ⇒ユーザー(アプリ)は自前で防御を考える ⇒信頼できないリソースを使うシステムの組み方が新たな価値を生む Copyright 2019 FUJITSU LIMITED 各々のリソースは脆い アプリ側で束ねることで しぶとさを獲得 37

Slide 39

Slide 39 text

99.9%の世界 99.9%安全なシステム 0.999^10=0.99, 0.999^100=0.90, 0.999^200=0.81…… 1000台ぐらいになると毎日どこか壊れる。確率的に安定させないとダメ。 また  99.9%の確率で安全なジェット機  99.9%の確率で正しく動く自動販売機 は同列には扱えない。 何をどう組み合わせ、どうやってリスクヘッジするのか？ Copyright 2019 FUJITSU LIMITED 38

Slide 40

Slide 40 text

リスク分散技術と新しい特性  脆いことにより分散技術が発展、スケールアウト性能などを獲得する Copyright 2019 FUJITSU LIMITED 39

Slide 41

Slide 41 text

リスクを躱す分散技術の例 (例) Client Side Load Balancer Copyright 2019 FUJITSU LIMITED 分散DB等で実装 クライアント サービス ロードバランサ 接続先情報 弱点 アプリが自前でなんとかすることで 可用性やスケーラビリティ、インテリジェンスが増大 40

Slide 42

Slide 42 text

分散技術の見方  「想定外の事態への対応能力」を補う技術とツールのセット スケールアウトやロードバランシング 統一的な見える化 統一的なモニタリングとロギング まさかの時の切り戻し Copyright 2019 FUJITSU LIMITED 現場の対応力を失いがちな 自動化やコンテナ型デリバリモデルの弱点を補完 41

Slide 43

Slide 43 text

クラウドネイティブ 以下の要素をもつシステムとそのための構成技術、それを利用すること  アプリケーションファーストであり、呼び出すとリソースが割り当たる  リソースについてあらかじめ仕込みが不要  クラウドの脆さを克服でき、自動的かつ分散的な性質を持つ  一部が欠損しても動作し、ストレスに自動的に対応する  想定外の事態に対し、アーキテクチャとして免疫系を持つ Copyright 2019 FUJITSU LIMITED 42

Slide 44

Slide 44 text

クラウドネイティブでうれしいこと Copyright 2019 FUJITSU LIMITED  開発に強い  アプリ開発者はインフラ運用者に頼らずアプリを配備可能  リソースの仕込みが要らない(財布はいるが)  ストレスに強い  とっさのスケールアウトに強い  回復も自動的  ダイナミックな、短いジョブの繰り返しに強い  細粒度に必要なだけリソース割り当て  災対に強い  ダイナミックなスケジューリング  どこの環境でも動くことが期待できる 43

Slide 45

Slide 45 text

Cloud Nativeとは？ Copyright 2019 FUJITSU LIMITED アプリケーションファーストを実現し、 インフラ層を脆いものと見なした上で 脆くないアプリケーションを作り出す技術の総称 副次効果として開発速度の加速、対障害性やスケールアウト性などの ダイナミックなアプリケーション特性が得られる 44

Slide 46

Slide 46 text

Copyright 2019 FUJITSU LIMITED 寄せ集める 呪文で操る ストレスに自動で対応する 部分は脆く全体は強い… ？ Ice Break再掲 45

Slide 47

Slide 47 text

リソースは用意しない コードとAPIで操り ストレスに自動で対応し 一部が壊れても、復活する Copyright 2019 FUJITSU LIMITED Ice Breakの答えあわせ Cloud Native 諸説あります 46

Slide 48

Slide 48 text

究極？の姿  Netflix社では絶えずインフラ障害を人為的に起こす本番テストを繰 り返して、運用を含めて脆さに対応、圧倒的な“しぶとさ”を実現 https://medium.com/netflix-techblog/chaos-engineering-upgraded-878d341f15fa Copyright 2019 FUJITSU LIMITED 北米のAWS大クラッシュでも サービスに影響無し サービス全体 西海岸 東海岸 47

Slide 49

Slide 49 text

一応  Cloud Native Computing Foundation(CNCF)による定義  クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナ ミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、お よび宣言型APIがあります。  これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅 牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どお りに行うことができます。  Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを 育成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、 これらのイノベーションを誰もが利用できるようにします。 Copyright 2019 FUJITSU LIMITED https://github.com/cncf/toc/blob/master/DEFINITION.md 48

Slide 50

Slide 50 text

考察：クラウドネイティブの価値 Copyright 2019 FUJITSU LIMITED  学習コストが高いことは疑いない  エンジニアリングの成熟が可能性を生みやすい仕掛け なんせリソースはオンデマンド チーム育成が進めばこれまで異なるレベルで 素早く柔軟でしぶといシステムとエンジニアチームができあがる ビジネスの足を引っ張らないエンジニアチームが持てる トヨタ生産方式のような製品に直接反映されないが 他社との違いを生み出す仕掛け……と思う 49

Slide 51

Slide 51 text

第三部：Kubernetes ～de facto standard Cloud Native Platform～ Copyright 2019 FUJITSU LIMITED 50

Slide 52

Slide 52 text

Kubernetes(K8s)  クラウドネイティブプラットフォームのデファクトスタンダード  Google発のオープンソース  Cloud Native Computing Foundation(CNCF)がホスト  アプリ側からクラウド側のリソースを呼び出す仕掛け  ６大クラウドが参加  富士通もCNCFの創設メンバーかつプラチナメンバー Copyright 2019 FUJITSU LIMITED AWS Azure GCP On-Premises Kubernetes App MW DB 51

Slide 53

Slide 53 text

Kubernetes  Kubernetes(K8s)はコンテナのオーケストレーションエンジン 計算機クラスタにコンテナをダウンロードして配備 計算機クラスタの各ノードの管理・監視 コンテナのライフサイクル（起動・停止・・・）の自動管理機能 コンテナ間の仮想ネットワークの構築 コンテナのグループ化機能 様々なクラウドリソースの自動割り当て機能 コンテナの監視・ロギング、コンソール…… Copyright 2019 FUJITSU LIMITED 計算ノードをまたがる コンテナ環境 52

Slide 54

Slide 54 text

K8sのだいたいの仕組み Copyright 2019 FUJITSU LIMITED 計算ノード群 agent agent agent agent API Server 分散DB Controller Scheduler UI 1000台以上スケール docker network plugin コンテナ群 ホストの中 53

Slide 55

Slide 55 text

K8sの説明を始めます  話の流れ 1. K8sのアプリ配備の基本構成要素の紹介 ① Pod ② Service 2. Kubernetesのいいところ 3. 経験者は語る 4. K8sを組み込んだフルセットのシステム 5. 注目のOSS Copyright 2019 FUJITSU LIMITED 54

Slide 56

Slide 56 text

K8sの基本構成要素 Copyright 2019 FUJITSU LIMITED 55

Slide 57

Slide 57 text

K8sの特徴的アイデア：Pod コンテナのグループを作る機能 Copyright 2019 FUJITSU LIMITED  同一のホストに配備される  Pod内のコンテナは生死を同じくする  Pod内のコンテナは同じIPアドレスを持つ  お互いは127.0.0.1でアクセスできる  Pod内のコンテナではファイル共有可能 Podにより、1アプリ＝1コンテナを実現しつつ同時配備が簡単に K8sスケジューラはコンテナではなくPodをスケジュール アプリと監視プロセスを同じPodで配備 アプリとログ転送を同じPodで配備 例えば 56

Slide 58

Slide 58 text

Podをうまく使い、分割しつつグループ化 httpd メイン機能： Ｗｅｂサービス 生死監視 ログ監視 コンテンツ 付加要素 httpd 監視 ログ コンテンツ 分割することでお互いの影響を排除できる 分割しないと一部を直したら全部再テストかも？ “共有”せずにひとかたまりにすることで取り扱いを小さくできる Copyright 2019 FUJITSU LIMITED Pod 57

Slide 59

Slide 59 text

Pod network Copyright 2019 FUJITSU LIMITED コンテナ Pod(同一ホストに同時配備されるコンテナの組） 同一Ｐｏｄのコンテナは同じＩＰアドレスを持つ ＶＭ内に複数の Podが配備される 全てのPodは一つのサブネットネットワーク上に展開される 各ホストにはエージェントが居て、API Serverからコントロールする API Server Agent Agent Agent 赤地に白 Kubernetesのコンポ Network内の ローカルDNSも K8sが提供 基本的に すべてのPodは お互いに通信できる 58

Slide 60

Slide 60 text

K8sのサービス① Copyright 2019 FUJITSU LIMITED Service サービスという抽象概念を オブジェクトとして保持(JSONで定義)  サービス(概念)とPod(実装)  サービスは実装(Pod)を追跡  サービスはLoadBalancerと連携  サービスはDNSと連携 PodとPodというよりは、 サービスとサービスを組み合わせて アプリケーションを作るようになる 59

Slide 61

Slide 61 text

サービスはPodを追跡する  サービスはオーケストレーションの鍵 （例）ロードバランサやDNSとの連携 Copyright 2019 FUJITSU LIMITED Service 情報 ロードバランサ DNS 情報 情報  サービスは紐づけられたPod を常に追跡  外からはサービスに問い合わ せするとPodの位置がわかる  ロードバランサやDNSが絶え ずサービスと同期することで 自動的に追跡できる  サービスがあることでDNS連 携や負荷分散が可能に 60

Slide 62

Slide 62 text

サービスがK8sアプリの単位になる Copyright 2019 FUJITSU LIMITED Front Service KVS Recommend Service Gateway サービスとサービスを繋げてシステムを作る リソースとも分離  設計と実装を分離  疎結合化が自然と進む 61

Slide 63

Slide 63 text

K8sのいいところ Copyright 2019 FUJITSU LIMITED 62

Slide 64

Slide 64 text

K8sのいいところ 1. 宣言的である 2. 自動的である 3. サービスの概念 4. ログや監視機能のビルトイン 5. エコシステム 6. K8sアプリケーション 7. マネージドサービス Copyright 2019 FUJITSU LIMITED 63

Slide 65

Slide 65 text

1.宣言的である  YAML/JSONで宣言し、 APIを通しK8sに登録する  手順ではなく“求める結果”を書く  手順を書かず、最終形をハッキリ書く  人によって差がでにくい  K8sは現状と指定された結果の差 分を抽出し、差分を減らすように動 作する(次ページに続く) Copyright 2019 FUJITSU LIMITED apiVersion: apps/v1 kind: Deployment metadata: name: conduit-fe-deployment spec: replicas: 3 selector: matchLabels: app: conduit-frontend template: metadata: labels: app: conduit-frontend spec: containers: - image: localhost:5000/com.conduitapp/frontend imagePullPolicy: Always name: conduit-frontend ports: - containerPort: 80 種類 複製の数 ラベル コンテナイメージ名 名前 公開するポート 64

Slide 66

Slide 66 text

2.自動的である  設定と実装の差を検知し自動的にコンテナを起動/終了  計算ノードがダウンした際に他所で立ち上げなおすなど、自動 再起動などは勝手にやってくれる Copyright 2019 FUJITSU LIMITED replica=3 １ replica=3 agent 元に戻す！ ３ replica=4 設定を変更 ４ replica=4 agent 設定を反映 ５ 一つコケる ２ 65

Slide 67

Slide 67 text

3.サービスの概念 Copyright 2019 FUJITSU LIMITED 名前で実装を隠蔽  APIを介したサービスの分割が自然に強制される（はず）  モジュール性が高まり、変更に強くなる MyService httpd httpd MyService httpd httpd httpd MyService nginx nginx nginx 増やしても 変更しても 66

Slide 68

Slide 68 text

4.ログや監視機能のビルトイン ログ採取や監視をK8sのエージェントにお任せ Copyright 2019 FUJITSU LIMITED 標準出力 agent 分散DB UI/API/Plugin アプリ アプリ agent http probe 無応答を検知したら 再起動 ログ収集by K8s ヘルスチェック by K8s 67

Slide 69

Slide 69 text

5.エコシステム①  Cloud Native Landscape Copyright 2019 FUJITSU LIMITED https://landscape.cncf.io/ K8sをコアにして 多数のOSSが勃興 68

Slide 70

Slide 70 text

5.エコシステム②  多数のユーザ事例がオープンに https://www.cncf.io/projects/case-studies/ Copyright 2019 FUJITSU LIMITED 58事例 69

Slide 71

Slide 71 text

6.アプリケーション  K8s向けの構築済ソリューションが配布中  例 Apache Spark GitLab Kubeflow Copyright 2019 FUJITSU LIMITED https://www.kubeflow.org/ 構築が面倒な”システム”が 様々なクラウドで 一発でデプロイできる 70

Slide 72

Slide 72 text

7.マネージドサービス  多くのパブリッククラウドがマネージドサービスを提供中 Copyright 2019 FUJITSU LIMITED 使ってみると差はあるみたいですが 71

Slide 73

Slide 73 text

K8sを使いこなすとCloud Nativeになる Copyright 2019 FUJITSU LIMITED アプリ開発者は リソースはあらかじめ用意しない コードで呼び出し ストレスに自動で対応し 一部が壊れても自動で復活する 72

Slide 74

Slide 74 text

(おまけ)Cloud Native Computing Foundation Copyright 2019 FUJITSU LIMITED https://www.cncf.io/  KubernetesをホストするOSS団体  K8sを中心に22のCloud Native なOSSを支援  世界最大規模のOSS団体  プラチナメンバは、AWS,Azure,Google,IBM,Oracle,Huawei,Alibaba Fujitsu, Intel, Red Hat, SUSE等…  2019年の7月にはAppleもプラチナメンバ―で参加 73

Slide 75

Slide 75 text

経験者は語る Copyright 2019 FUJITSU LIMITED 74

Slide 76

Slide 76 text

飛びつく前に知っておくべきこと  日進月歩で機能が増加  コンテナの配布をセキュアにする施策は別途必要  CI/CDやサービス監視機能、API管理等との組み合わせが必要  教育コストは高い  クラウドネイティブな特徴を生かせないと面倒なだけ  自前で運用するなら強い運用チームが必要 Copyright 2019 FUJITSU LIMITED マネージドサービスでスモールスタートがおすすめかなぁ 75

Slide 77

Slide 77 text

K8sあるある  YAML/JSONがデバッグできない  OOM Killで殺される  リソース集約を目標にしていたが全く減らない  K8s+何かが必要  一気に作ろうとしたら死ねる  自前でK8sを運用したらしんどい  Qiitaを信じたら古かった  意外とバッチジョブで使える Copyright 2019 FUJITSU LIMITED 76

Slide 78

Slide 78 text

K8sを組み込んだフルセットシステム Copyright 2019 FUJITSU LIMITED 77

Slide 79

Slide 79 text

フルセットのアーキテクチャ Copyright 2019 FUJITSU LIMITED Orchestration SDN DNS API Gateway Tracing Circuit Braker API mgmt. Load Balancer Logging Monitoring Visualization Ops Quality Analysis Mobile Mail Chat Web Console Big Data Service Analysis Internet Deploy Control B/G deployment Canary Continuous Integration Ticket System Registry PipeLine Source/Artifacts repo. Chat Control Value Stream Mapping Kanban Development Process Quality Analysis Workflow Management User Demand Access Analysis Fault Injection SDS CI/CD Dev Kaizen Service Kaizen Ops UI Service Composition VPN Ops Kaizen Kubernetes User Interface CA mgmt. ID mgmt. Auth mgmt. ServiceMesh 全部イキナリは無理 78

Slide 80

Slide 80 text

必要なエンジニアリング領域  VMやクラウドインフラの構築・運用  Web APIとLayer7(HTTP/HTTPS)の技術  自動化やCICD pipelineの技術  ログの収集と分析  モニタリングとページャーエスカレーションの技術（モニタリングの品質＝サービスの品質！）  セキュリティの専門家  カナリアリリース等のリリースエンジニアリング  Web API経由の認証と認可技術  データベースやKey-Value Storeを使った分散処理の技術  パフォーマンス、施策の効果を測定するKPI、Kaizen技術 Copyright 2019 FUJITSU LIMITED 79

Slide 81

Slide 81 text

個人的なお勧め 1. まずはコンテナに慣れよう(Docker/Docker-composeを使う) 2. CIを通してコンテナを自動ビルドする仕掛けを作ってみよう 3. コンテナが増えたらK8sに運用を任せてみよう。小さい機能からワンオフで進めても良い。 4. クラウドネイティブな考え方に慣れよう。K8s前提の開発・運用プロセスを一旦固めよう。 5. K8sに対応したログ収集やモニタリング・デバッグの方法論を確立しよう 6. パッケージングをテンプレート化してみよう(Helm等) 7. Service Mesh等を検討しながらL7 API networkを見直そう アプリをコンテナ化するところでgRPCやGraphQLも見てみよう。 ServiceMesh等を始める前にConsulとか見たほうがいいかも。 Message Queue製品(KafkaやSQS等)を見るのもよい。 Copyright 2019 FUJITSU LIMITED 80

Slide 82

Slide 82 text

Kubernetesとは Copyright 2019 FUJITSU LIMITED クラウドネイティブに向かう仕掛け 脆いシステムの上でアプリを組む ための世界共通プラットフォーム ユーザはK8sの作法にのっとり、 エコシステムを使いこなすことで クラウドネイティブな特性を得る 81

Slide 83

Slide 83 text

個人的に注目の若いプロジェクト Copyright 2019 FUJITSU LIMITED 82

Slide 84

Slide 84 text

注目OSS①  Grafana/Loki GrafanaのLog分析プラグイン、強力な検索とタグベースのログ分析エンジン Copyright 2019 FUJITSU LIMITED 83

Slide 85

Slide 85 text

注目OSS②  Open Policy Agent(OPA) https://www.openpolicyagent.org/ Copyright 2019 FUJITSU LIMITED 宣言的な方法で APIの認可ポリシーを コントロールする フレームワークMW ソフトウェアから 認可処理を分離し 外部から制御 84

Slide 86

Slide 86 text

注目OSS③  Spinnaker  NETFLIX由来の強力なCD(ContinuousDelivery)エンジン Copyright 2019 FUJITSU LIMITED V2になって K8s親和性UP! • パイプライン • マルチクラウド対応 • Red/Black • カナリアリリース 85

Slide 87

Slide 87 text

注目OSS④  Knative 最強サーバレスプラットフォーム？ Copyright 2019 FUJITSU LIMITED いわゆるサーバレス(FaaS)の中で 最もK8sと親和性が高そう ※Google Cloud Runの中身 単にFaaSではなく、PaaSやコンテナ っぽい使い方まで含めたフレームワーク  Knative Serving  Knative Eventing  Knative Building 86

Slide 88

Slide 88 text

注目OSS⑤: Pulumi, Brigade  PythonやJavascriptでインフラ自動化  YAML/JSONではなくプログラミング言語で 自動化を書く ロジックが書ける  Pulumi // Terraformの対抗  Brigade // K8s用自動化 Copyright 2019 FUJITSU LIMITED 87

Slide 89

Slide 89 text

実践しよう！：ニフクラ Hatoba（β）  ニフクラ上でKubernetesクラスターが作成できるサービス Copyright 2019 FUJITSU LIMITED  機能  クラスター作成  ファイアウォール  スナップショット  現在はβ版で、審査に通れば 無料で利用可能 https://pfs.nifcloud.com/service/hatoba.htm 88

Slide 90

Slide 90 text

第４部 マイクロサービス Copyright 2019 FUJITSU LIMITED  マイクロサービスってほんとにいるの？  Cloud Native ≠ MicroServices ?  何なの？ 89

Slide 91

Slide 91 text

マイクロサービス実践者の例  Netflix Copyright 2019 FUJITSU LIMITED アプリが大きすぎて ビルドに半日かかる ようになってしまった  Cookpad Railsが100万行を超 え、Ver Upに一年か かるようになった https://employment.en- japan.com/engineerhub/entry/2019/09/17/103000 少しずつ解体し、結果的にマイクロサービスに ちょっとわかりやすい資料 https://www.graat.co.jp/blogs/ck0nwv2m3ctzj0830xweica5d 90

Slide 92

Slide 92 text

完 Copyright 2019 FUJITSU LIMITED もう少し続きます 91

Slide 93

Slide 93 text

マイクロサービス?  ここからの全ての説明は後付けです  サービスを構成するアプリケーションを巨大でモノリシックなものから分割された小 さなサービスの集合し、開発速度やメンテナンス性を上げるアーキテクチャ  ただ、言い出した Martin Fowlerも「必要じゃなければやるな」と言っている  では、いつ必要なのか？大きくは戦略論である。  エライひとや顧客から言われることも多いだろうと思うので、理解するためのヒント について少し言及する……ただ、後付けなので注意 Copyright 2019 FUJITSU LIMITED 92

Slide 94

Slide 94 text

モノリシックサービスとマイクロサービス Copyright 2019 FUJITSU LIMITED コンポA コンポB コンポＣ コンポＤ コンポＥ コンポB コンポD コンポA コンポE コンポC 全て同じ技術で作る 一か所の変更が全てに影響 ビルドが大変 スケールアウトしにくい 全てAPIで結合 互いの項からは防御される デバッグが大変 スケールアウトしやすい API 開発・変更が大変 運用が大変 モノリシック＝一枚岩 マイクロサービス 93

Slide 95

Slide 95 text

マイクロサービスは組織の待ち合わせを無くす Copyright 2019 FUJITSU LIMITED A B Ｃ D 集 約 会 議 リ リ ｜ ス 一番時間のかかるチームに律速 全体会議ですり合わせ ビルドに半日かかってCI/CDにならない A B Ｃ D 組織のMission リリース どんどん(勝手に)リリース 全体の方向性はMissionで整える リリース リリース リリース 94

Slide 96

Slide 96 text

チームを分割するとは  各チームに判断の権限が委譲されることで同期コストを削減  チームは小さく分割する  機能や技術ではなく、ビジネスや影響範囲、同時に管理されるべきサービスで分割する  意思疎通がうまくいくチームのサイズはサッカーチームくらい。  チームは独立する  チームでの決定に際して他所のチームの承認が必要な状況ではチーム分割が失敗している  データベースは統合しない。それぞれで持つ。  チーム間はAPIで会話する  APIで明示されていること以外は仮定しない  他人が突然ＤＯＳアタッカーになることもある。自己防衛が重要  ポステルの法則：“送信するものはわかりやすく厳密に、受信するものは寛容に” Copyright 2019 FUJITSU LIMITED 95

Slide 97

Slide 97 text

 なぜ大変な目にあってまで速くしなければいけないのか？ 目的は？オイシイの？ Copyright 2019 FUJITSU LIMITED そもそも…… Why? ビジネス上の理由は何か どう勝つのか？ 96

Slide 98

Slide 98 text

こういう時は「孫子」 Copyright 2019 FUJITSU LIMITED 97

Slide 99

Slide 99 text

百戦百勝  孫子： 百回戦って、百回勝利を収めたとしても、それは最善の策とは言えない。 実際に戦わずに、敵を屈服させるのが最善の策である Copyright 2019 FUJITSU LIMITED 98

Slide 100

Slide 100 text

兵之情主速  孫子：第十一 九地篇 戦いの第一義は迅速にある。敵の用意していないところにつけ込み、思いも よらない奇計を行い、敵が警戒していない所を攻撃すべきである Copyright 2019 FUJITSU LIMITED 敵を混乱させて戦う前に勝負をつけろという意味 99

Slide 101

Slide 101 text

孫子は実は現代の米海兵隊の現代の戦術に影響を与えている Copyright 2019 FUJITSU LIMITED 100

Slide 102

Slide 102 text

米軍）ジョン・ボイド大佐のOODA Loop Copyright 2019 FUJITSU LIMITED Observe Orientation Act Decide 観察 方向性の決定 分析と統合 遺伝的資質 文化的伝統 新しい情報 経験則 判断 仮説作成 行動 試行 再検討 試行結果報告 行動の結果報告 状況 事件 闘争における人間の基本行動パターン（※天才を除く） ショートカット ショートカット OODAループ戦術:味方のループを高速化、敵ループを遅延させ、一方的に勝利を得る 101

Slide 103

Slide 103 text

訓練による究極OODALoop高速形 Copyright 2019 FUJITSU LIMITED Observe 観察 状況 事件 Act 行動 試行 反射行動 ワンアウト一塁 二塁に送ってゲッツー ある現象に対して対処が明らか⇒訓練で高速ループ化 ショートゴロ 102

Slide 104

Slide 104 text

混乱による敵OODALoop遅滞戦術 Copyright 2019 FUJITSU LIMITED Observe Orientation Act Decide 観察 方向性の決定 分析と統合 遺伝的資質 文化的伝統 新しい情報 経験則 判断 仮説作成 行動 試行 再検討 結果報告 情報の飽和 嘘の情報 予測外し 判断できない 例） • フェイント攻撃 • 子供が泣いて、電話がなり、玄関のチャイムが鳴り、お腹が痛い • 奇策 103

Slide 105

Slide 105 text

米軍のOODA戦術 Copyright 2019 FUJITSU LIMITED Observe Orientation Act Decide 観察 方向性の決定 分析と統合 遺伝的資質 文化的伝統 新しい情報 経験則 判断 仮説作成 行動 試行 再検討 結果報告 状況 事件 • 相手より早くループを回せばより早く行動段階に到達出来、相手がまだ考えている間にタコ殴りにできる • 相手より早くループを回せば直接攻撃を加えなくてもより多くの選択肢を敵に突きつけることになる。 相手は行動段階に移れないうちに敗北する OODAループの基本戦術：自分達を速くして相手を遅延させる 高速化 104

Slide 106

Slide 106 text

AWSのOODA戦術 Copyright 2019 FUJITSU LIMITED 最初から100%ではないサービス 開発速度で圧倒する スモールチーム Jeff Bezos 速度で圧倒し、 敵を混乱に陥れ何もさせない うちに勝つ戦術 分析して対策する戦術が通じない戦い方 105

Slide 107

Slide 107 text

高速化のカギ：small team  互いに阿吽で意思疎通できる人数には限界がある  Amazonでは “The two pizza rule” というらしい •「社内のすべてのチームは2枚のピザを食べるのにピッタリなサイズでなければいけない」 •米海兵隊も小隊が現場での意思決定権を持つ  人数が増えると「調整役」「アジェンダ担当」「代表が出席してメンバーに再度広報」などい ろんなコストが増え、情報が行き渡らなくなり、決断できなくなる。 Copyright 2019 FUJITSU LIMITED 速いチームを作ろうとすると人数は増やせない （おまけ）チームが最速の瞬間はコミュニケーションは最小限 例）サッカーのアイコンタクト、野球のダブルプレイ 阿吽の呼吸には濃密な関係性が重要。やっぱり人数は増やせない。 106

Slide 108

Slide 108 text

戦略としてのマイクロサービス  素早く、同時多発的に次々アップデートを投入し、相手の足を止める  強力な少人数チームを複数編成し、同時多発的にサービス展開  相手を降ろす（フォールドさせる）のが目的の場合は強力に作用  ただし、マイクロサービスはただのＩＴ。ヴァーチャルな世界で完結しない。 会社全体で勝負になる →次ページ Copyright 2019 FUJITSU LIMITED 107

Slide 109

Slide 109 text

Amazon vs. Walmart  実際何が起きているのか？  ヴァーチャルな世界での戦い (EC)のポイントは、リアルな 実装(倉庫と物流網)である ようにも見える Copyright 2019 FUJITSU LIMITED https://forbesjapan.com/articles/detail/29147 アマゾンの「制約なき成長」の時期は過ぎた？ 最大手が形勢逆転 実際のところ、IT Systemは業務の一部に過ぎないのだから “実装”であるリアル業務も変革しないとダメ（当たり前だが） ヴァーチャルな世界での戦いを互角に持ち込んだあとどうするか？ そういう意味で“会社全体が戦う”体制の中でどうITを位置づけるかで マイクロサービスの採用については決めていく必要がある(やはり当たり前だが) 108

Slide 110

Slide 110 text

クラウドの機略戦：マイクロサービス Copyright 2019 FUJITSU LIMITED 多面的展開とスピードで圧倒し 敵を場から降ろす “実業”の実装・カイゼンとワンセットなことも注意 攻めのIT戦略 あるいは対応する守りのIT戦略 109

Slide 111

Slide 111 text

以上を踏まえつつ Copyright 2019 FUJITSU LIMITED 110

Slide 112

Slide 112 text

マイクロサービスのポイント①  ビジネス境界で分割する ビルドを分けるというのもあるが、チーム間の会議や余計な会話を減らすのが 一つの目的。分割しすぎて打ち合わせが増えたら元も子もない。 承認プロセスを減らす 変に分割して余計な会話や打ち合わせを増やさない Copyright 2019 FUJITSU LIMITED バランス感は難しい 業務プロセスをよく知ること 111

Slide 113

Slide 113 text

マイクロサービスのポイント②  モノリシックな状態から少しずつ分ける そもそもモノリシックなほうが作りやすい •モジュール間の連携がわかりやすい •通信レイテンシで困ることがない みんな一斉に始めると機能がそろわない •チームごとに出来上がり時期がバラバラ •先にできても通信相手がいない •崩壊する ビジネス的に効果のあるところから分割する DBなども最初は共有していたほうがいいかも・・・・ Copyright 2019 FUJITSU LIMITED 少しずつ 112

Slide 114

Slide 114 text

マイクロサービスのポイント③  レイテンシには注意する 分けたらレイテンシが増加する。そこは本当に分けていいのか？  隣のサービスを信用しない 隣からいきなりDOSアタック。サーキットブレーカーについて学ぼう  モニタリングは工夫する 「生きてまーす」と空返事はするが動いてないことはよくある  デバッグに対処する トレースやログを仕込み、チームをまたがった原因分析ができるようにする Copyright 2019 FUJITSU LIMITED 113

Slide 115

Slide 115 text

マイクロサービスのポイント④  キーテクノロジーは共通化する 基本的には各チームが独立して技術を選択すべき ただし、チーム全体でコアになるテクノロジーは技術を合わせる •特にDBや分散KVSまわり •認証・認可・ロギング・モニタリングあたりは基盤チームで共通化すべきかもしれない •超重要技術は合わせないと人が異動したときに話が合わない、知見がたまらない  開発はアジャイルで 各チームの中にビジネスオーナーがいること SIの場合、対象ビジネスを知る顧客をちゃんと巻き込もう Copyright 2019 FUJITSU LIMITED 114

Slide 116

Slide 116 text

マイクロサービスのポイント⑤  連携(同期・非同期)とデータの持ち方が結局難しい RDBで共有するパターン Blobで何とかするパターン 分散ＤＢを使うパターン サービスメッシュなパターン Message Queueで非同期連携するパターン イベントとWatchで連携するパターン ……… Copyright 2019 FUJITSU LIMITED 答えは現場にしかない 115

Slide 117

Slide 117 text

とはいえ 実際は、素早いビジネスが先にあり、そこにＩＴシステムが追い付く必 要があっただけじゃないか…という気もするのでマイクロサービスだけを考 えても仕方ないのは注意 目的があれば手段はついてくるんじゃないかな？ ※たいていの場合は分割しても“マイクロ”というレベルまでいかないかも Copyright 2019 FUJITSU LIMITED 116

Slide 118

Slide 118 text

 MicroServices=紀元前から続く“素早い”戦略のITへの反映 業務変革にITがついていくための組織構造でもある コンサルするなら実業への実装まで含めてネ（対象ビジネスをよく知らないとつらい） 事例を見ると、漸進的にアプリを解体・対応するのが鉄板  Cloud Native ≠ MicroServices  目的が決まればたぶん手段はついてくる Copyright 2019 FUJITSU LIMITED とりあえず 闇雲に適用しても大変なだけで恩恵はないが、 MicroServicesの中で語られる技術や考え方そのものは Cloud Native的に有用なので選んで使いたい 117

Slide 119

Slide 119 text

Q.中華食堂はファミレスになれるか A. 中華食堂も餃子だけはセントラルキッチンのようである 課題と要件があれば手段はついてくる Copyright 2019 FUJITSU LIMITED 118

Slide 120

Slide 120 text

No content