Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クラウドネイティブとKubernetes(だいたいあってるクラウドネイティブ)

 クラウドネイティブとKubernetes(だいたいあってるクラウドネイティブ)

社内のウェビナーで使用した資料をほぼそのまま掲載しました。
クラウドネイティブをふわっとわかったつもりになる、考え方の入り口を見つけることを補助するための初心者向け資料です。
具体的な技術は一切解説しませんし、「良い」評価と「悪い」評価も真っ二つだったので人を選ぶ資料であることを先に述べておきます。

Hiro.Kamezawa

October 02, 2019
Tweet

More Decks by Hiro.Kamezawa

Other Decks in Technology

Transcript

  1. Copyright 2019 FUJITSU LIMITED  Cloud Nativeについて考えてみる コンテナの出自がわかる Cloud Nativeがなんとなくわかる

    Kubernetesがなんとなくわかる 目標 わかりにくいかもしれませんが 感じるところがあったり興味がわけばOK Kubernetes自体の使い方などはオンラインで探してください ※Cybozuさんの新人研修資料とかいいかもしれない https://blog.cybozu.io/entry/2019/09/05/080000 3
  2. 最初に 【この資料を見ても具体的な使い方は一切わかりません。】  私の見方では・・という話なのでCloud Nativeについて自身で考えるための材 料と捉えてください。所詮、後付けの作文です。・・・本質は実践にあるでしょう  動いているものを見て誰かが「クラウドネイティブ」と言い出しただけです。  コンテナもマイクロサービスも「理論に従い、狙って設計したらこうなった」のではなく、「試行

    錯誤していたら」こうなったということだろうと思います  “やればわかる”だと顧客に伝えたり、上司を説得する術がありませんので一遍の 戯言資料でも多少のヒントになればと存じます。  How To 資料は別途探してください。  今日の話は気楽に聞いて、実践し、自分なりに考えましょう。 Copyright 2019 FUJITSU LIMITED 4
  3. 目次  Ice Break  第一部:コンテナ  第二部:クラウドネイティブ  第三部:Kubernetes

     おまけ、あるいは宣伝  第四部:マイクロサービス Copyright 2019 FUJITSU LIMITED 大事なことなのでもう一度 【この資料を読んでも具体的な技術は一切わかりません】 5
  4. 寓話:手品師と魔法使い Copyright 2019 FUJITSU LIMITED 普段から世話している 鳩を訓練 呪文で指示すると 森から動物が集まって仕事 手品師

    魔法使い 育てて芸を仕込むのが手品師 寄せ集めの動物たちを呪文であやつるのが魔法使い 7
  5. 寓話:ヤマタノオロチとヒュドラ Copyright 2019 FUJITSU LIMITED 8本の首で ダイジョーブ 首を1本落とすと 2本増える ヤマタノオロチ

    ヒュドラ あらかじめ用意したリソースで耐えるのがヤマタノオロチ ストレスに対応して自動でスケールアウトするのがヒュドラ 8
  6. 寓話:鉄と生命 Copyright 2019 FUJITSU LIMITED ストレスに対し 堅くて頑丈 何時か壊れる ストレスに対し 環境に適応

    進化してゆく 鉄 生命 硬くて頑丈のが鉄 個々は脆く種として強いのが生命 9
  7. 【今まで】アプリを配備する  運用担当者がアプリケーションを配備する手番 1. 前提になるソフトウェアをインストールする 2. アプリケーションをインストールする 3. OSを含めたソフトウェアのコンフィグを調整する 4.

    手順を守って起動する Copyright 2019 FUJITSU LIMITED 頑張って自動化 自動化って腐りやすい ①アプリ毎の作り込み ②OSやランタイムのバージョン違い ③緊急パッチで挙動が変わる ④属人化する、人がいなくなる 12
  8. 腐らない自動化のために  自動化追求の過程で「常にクリーンインストールから開始」「アプリを共存させ ない」ことで自動化の保守が楽になることが発見される(Immutable Infrastructure)  わかってきたこと→周囲の影響を受けないアプリの配布・配備手法が鍵  Go言語のスタティックバイナリで共有ライブラリ無し 

    アプリを丸ごとtarで固めてぶん投げる(GoogleのBorgシステム)  1VMに1アプリだけ入れ、VMイメージを常に作り直す(一時期流行った) Copyright 2019 FUJITSU LIMITED ◦必要なモノは全て固め、共有しない ×貧乏根性で共有するとトラブルの元 (共有ライブラリとか発明するからあかんかったんや……..) 14
  9. 【新しい方法】コンテナでアプリを配備する  アプリに必要なものをコンテナフォーマットで固める ベースイメージをダウンロード 必要なランタイムは全てイメージ内にインストール 必要な設定はコンテナ作成時に仕込む •動的に決まるパラメータは環境変数などで渡す Copyright 2019 FUJITSU

    LIMITED ダウンロードするだけでアプリ配備  運用が統一的  開発でテストしそのままを運用に適用可能  環境の影響をうけず自動化負担は軽減  Version Up, Downは置き換えるだけ 現場での秘伝のタレ醸造を防止 例えばdockerのフォーマット 16
  10. 変更できない(Immutable)ことの強制  コンテナの実行結果は“コンテナ内”には保存できない 再起動したら消える(コンテナへの変更内容は破棄される) Copyright 2019 FUJITSU LIMITED app ….

    ….. write() app 再起動  残したいデータは外に保存  起動するたび常にクリーン 捨てる運用で テストは捗る Ver.Upは 丸ごと置き換え 変更できないことでコンテナは「秘伝のたれ」化しにくい 18
  11. 積み重ねでコンテナを作る Copyright 2019 FUJITSU LIMITED Rails公式イメージ Ruby公式イメージ Alpine Linux #docker

    pull rails でダウンロードされるイメージ 重ねて Rails公式イメージ Ruby公式イメージ Alpine Linux あなたのアプリ 自分のコンテナイメージを作る 積層化したtarやzipみたいなものと思ってよい OSのカーネルは コンテナ内 に含まない 20
  12. 中華食堂とファミレス  某中華食堂と某ファミレスは全く逆のモデルで同じ目標を達成している  目標:安い、早い、旨い  某中華食堂  チェーンとしては食材を手配、店舗側で調理(餃子などはセントラルキッチン) 

    現場マネージャーが責任者としてオリジナルメニューも作ることが可能  某ファミレス  セントラルキッチンで料理を配達、店舗では基本は温めて、並べるだけ  売り上げ責任は本部(料理と立地)。人とコストの責任はマネージャー。 Copyright 2019 FUJITSU LIMITED 22
  13. 某中華食堂モデル Copyright 2019 FUJITSU LIMITED 本社: 基本レシピ開発 仕入れ デリバリの手配 販促

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

    セントラルキッチン 配送センター 料理配送 セントラルキッチンで調理 店舗では温めるだけ メリット: • 現場に超人が要らない • 安定した品質 • 集中生産によるコスト低下 デメリット: • 地域毎のサービス • 緊急時の現場 24
  15. コンテナデリバリ  コンテナのデリバリはファミレスに近い  料理の味について、現場に責任なし  現場運用者の能力に任せず、セントラルキッチンの品質が料理の品質  何が言えるか? 

    アプリ品質は開発者、インフラ品質は運用者の責任  アプリ由来のサービス品質は運用者の影響をうけにくい  アプリ作成者がテストした品質が本番で再現しやすい  責任範囲が明確化できそう  某ファミレスの場合:売り上げは本部責任、運用・コストは店長責任  SIの場合:アプリはアプリ屋、インフラリソースはインフラ屋 Copyright 2019 FUJITSU LIMITED 25
  16. (脱線)良し悪しではない…好みの問題  職人を養成して地域に密着した店づくり  人に投資  確率的に事故やばらつきを織り込む  (人員が優秀なら)非常事態に強い 

    規格をそろえて全国一律の安定サービス  設備に投資  安定する  極端な有事のケースに弱い Copyright 2019 FUJITSU LIMITED 好き嫌い、ビジネスコンセプト や競争戦略の作り方の話 ※戦えてさえいれば良い悪い ではない 最終的には有事対応でそれ ぞれ工夫が必要 27
  17. クラウド:リソース調達方法の変化  計画的な調達 Copyright 2019 FUJITSU LIMITED  On Demand

    計画・発注 サーバ API サーバ I need ”必要な時に必要なだけ”リソースが取り出せる クラウド 32
  18. クラウドでの逆転 Copyright 2019 FUJITSU LIMITED HW OS MW App 

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

    OS コンテナは「アプリ+MW+OS」の取り扱いを共通化 下位レイヤへの宣言・要求の共通フォーマットが確立 コンテナ=アプリ層とインフラ層を分断し、従属関係を断ち切る技術 コンテナがアプリケーションファーストを加速 ランタイム 35
  20. 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
  21. リスクを躱す分散技術の例 (例) Client Side Load Balancer Copyright 2019 FUJITSU LIMITED

    分散DB等で実装 クライアント サービス ロードバランサ 接続先情報 弱点 アプリが自前でなんとかすることで 可用性やスケーラビリティ、インテリジェンスが増大 40
  22. クラウドネイティブでうれしいこと Copyright 2019 FUJITSU LIMITED  開発に強い  アプリ開発者はインフラ運用者に頼らずアプリを配備可能 

    リソースの仕込みが要らない(財布はいるが)  ストレスに強い  とっさのスケールアウトに強い  回復も自動的  ダイナミックな、短いジョブの繰り返しに強い  細粒度に必要なだけリソース割り当て  災対に強い  ダイナミックなスケジューリング  どこの環境でも動くことが期待できる 43
  23. 一応  Cloud Native Computing Foundation(CNCF)による定義  クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナ ミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、お

    よび宣言型APIがあります。  これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅 牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どお りに行うことができます。  Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを 育成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、 これらのイノベーションを誰もが利用できるようにします。 Copyright 2019 FUJITSU LIMITED https://github.com/cncf/toc/blob/master/DEFINITION.md 48
  24. 考察:クラウドネイティブの価値 Copyright 2019 FUJITSU LIMITED  学習コストが高いことは疑いない  エンジニアリングの成熟が可能性を生みやすい仕掛け なんせリソースはオンデマンド

    チーム育成が進めばこれまで異なるレベルで 素早く柔軟でしぶといシステムとエンジニアチームができあがる ビジネスの足を引っ張らないエンジニアチームが持てる トヨタ生産方式のような製品に直接反映されないが 他社との違いを生み出す仕掛け……と思う 49
  25. Kubernetes(K8s)  クラウドネイティブプラットフォームのデファクトスタンダード  Google発のオープンソース  Cloud Native Computing Foundation(CNCF)がホスト

     アプリ側からクラウド側のリソースを呼び出す仕掛け  6大クラウドが参加  富士通もCNCFの創設メンバーかつプラチナメンバー Copyright 2019 FUJITSU LIMITED AWS Azure GCP On-Premises Kubernetes App MW DB 51
  26. K8sのだいたいの仕組み Copyright 2019 FUJITSU LIMITED 計算ノード群 agent agent agent agent

    API Server 分散DB Controller Scheduler UI 1000台以上スケール docker network plugin コンテナ群 ホストの中 53
  27. K8sの説明を始めます  話の流れ 1. K8sのアプリ配備の基本構成要素の紹介 ① Pod ② Service 2.

    Kubernetesのいいところ 3. 経験者は語る 4. K8sを組み込んだフルセットのシステム 5. 注目のOSS Copyright 2019 FUJITSU LIMITED 54
  28. K8sの特徴的アイデア:Pod コンテナのグループを作る機能 Copyright 2019 FUJITSU LIMITED  同一のホストに配備される  Pod内のコンテナは生死を同じくする

     Pod内のコンテナは同じIPアドレスを持つ  お互いは127.0.0.1でアクセスできる  Pod内のコンテナではファイル共有可能 Podにより、1アプリ=1コンテナを実現しつつ同時配備が簡単に K8sスケジューラはコンテナではなくPodをスケジュール アプリと監視プロセスを同じPodで配備 アプリとログ転送を同じPodで配備 例えば 56
  29. Podをうまく使い、分割しつつグループ化 httpd メイン機能: Webサービス 生死監視 ログ監視 コンテンツ 付加要素 httpd 監視

    ログ コンテンツ 分割することでお互いの影響を排除できる 分割しないと一部を直したら全部再テストかも? “共有”せずにひとかたまりにすることで取り扱いを小さくできる Copyright 2019 FUJITSU LIMITED Pod 57
  30. Pod network Copyright 2019 FUJITSU LIMITED コンテナ Pod(同一ホストに同時配備されるコンテナの組) 同一Podのコンテナは同じIPアドレスを持つ VM内に複数の

    Podが配備される 全てのPodは一つのサブネットネットワーク上に展開される 各ホストにはエージェントが居て、API Serverからコントロールする API Server Agent Agent Agent 赤地に白 Kubernetesのコンポ Network内の ローカルDNSも K8sが提供 基本的に すべてのPodは お互いに通信できる 58
  31. K8sのサービス① Copyright 2019 FUJITSU LIMITED Service サービスという抽象概念を オブジェクトとして保持(JSONで定義)  サービス(概念)とPod(実装)

     サービスは実装(Pod)を追跡  サービスはLoadBalancerと連携  サービスはDNSと連携 PodとPodというよりは、 サービスとサービスを組み合わせて アプリケーションを作るようになる 59
  32. サービスはPodを追跡する  サービスはオーケストレーションの鍵 (例)ロードバランサやDNSとの連携 Copyright 2019 FUJITSU LIMITED Service 情報

    ロードバランサ DNS 情報 情報  サービスは紐づけられたPod を常に追跡  外からはサービスに問い合わ せするとPodの位置がわかる  ロードバランサやDNSが絶え ずサービスと同期することで 自動的に追跡できる  サービスがあることでDNS連 携や負荷分散が可能に 60
  33. サービスがK8sアプリの単位になる Copyright 2019 FUJITSU LIMITED Front Service KVS Recommend Service

    Gateway サービスとサービスを繋げてシステムを作る リソースとも分離  設計と実装を分離  疎結合化が自然と進む 61
  34. K8sのいいところ 1. 宣言的である 2. 自動的である 3. サービスの概念 4. ログや監視機能のビルトイン 5.

    エコシステム 6. K8sアプリケーション 7. マネージドサービス Copyright 2019 FUJITSU LIMITED 63
  35. 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
  36. 4.ログや監視機能のビルトイン ログ採取や監視をK8sのエージェントにお任せ Copyright 2019 FUJITSU LIMITED 標準出力 agent 分散DB UI/API/Plugin

    アプリ アプリ agent http probe 無応答を検知したら 再起動 ログ収集by K8s ヘルスチェック by K8s 67
  37. 6.アプリケーション  K8s向けの構築済ソリューションが配布中  例 Apache Spark GitLab Kubeflow Copyright

    2019 FUJITSU LIMITED https://www.kubeflow.org/ 構築が面倒な”システム”が 様々なクラウドで 一発でデプロイできる 70
  38. (おまけ)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
  39. 飛びつく前に知っておくべきこと  日進月歩で機能が増加  コンテナの配布をセキュアにする施策は別途必要  CI/CDやサービス監視機能、API管理等との組み合わせが必要  教育コストは高い 

    クラウドネイティブな特徴を生かせないと面倒なだけ  自前で運用するなら強い運用チームが必要 Copyright 2019 FUJITSU LIMITED マネージドサービスでスモールスタートがおすすめかなぁ 75
  40. K8sあるある  YAML/JSONがデバッグできない  OOM Killで殺される  リソース集約を目標にしていたが全く減らない  K8s+何かが必要

     一気に作ろうとしたら死ねる  自前でK8sを運用したらしんどい  Qiitaを信じたら古かった  意外とバッチジョブで使える Copyright 2019 FUJITSU LIMITED 76
  41. フルセットのアーキテクチャ 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
  42. 必要なエンジニアリング領域  VMやクラウドインフラの構築・運用  Web APIとLayer7(HTTP/HTTPS)の技術  自動化やCICD pipelineの技術 

    ログの収集と分析  モニタリングとページャーエスカレーションの技術(モニタリングの品質=サービスの品質!)  セキュリティの専門家  カナリアリリース等のリリースエンジニアリング  Web API経由の認証と認可技術  データベースやKey-Value Storeを使った分散処理の技術  パフォーマンス、施策の効果を測定するKPI、Kaizen技術 Copyright 2019 FUJITSU LIMITED 79
  43. 個人的なお勧め 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
  44. 注目OSS②  Open Policy Agent(OPA) https://www.openpolicyagent.org/ Copyright 2019 FUJITSU LIMITED

    宣言的な方法で APIの認可ポリシーを コントロールする フレームワークMW ソフトウェアから 認可処理を分離し 外部から制御 84
  45. 注目OSS③  Spinnaker  NETFLIX由来の強力なCD(ContinuousDelivery)エンジン Copyright 2019 FUJITSU LIMITED V2になって

    K8s親和性UP! • パイプライン • マルチクラウド対応 • Red/Black • カナリアリリース 85
  46. 注目OSS④  Knative 最強サーバレスプラットフォーム? Copyright 2019 FUJITSU LIMITED いわゆるサーバレス(FaaS)の中で 最もK8sと親和性が高そう

    ※Google Cloud Runの中身 単にFaaSではなく、PaaSやコンテナ っぽい使い方まで含めたフレームワーク  Knative Serving  Knative Eventing  Knative Building 86
  47. 実践しよう!:ニフクラ Hatoba(β)  ニフクラ上でKubernetesクラスターが作成できるサービス Copyright 2019 FUJITSU LIMITED  機能

     クラスター作成  ファイアウォール  スナップショット  現在はβ版で、審査に通れば 無料で利用可能 https://pfs.nifcloud.com/service/hatoba.htm 88
  48. マイクロサービス実践者の例  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
  49. マイクロサービス?  ここからの全ての説明は後付けです  サービスを構成するアプリケーションを巨大でモノリシックなものから分割された小 さなサービスの集合し、開発速度やメンテナンス性を上げるアーキテクチャ  ただ、言い出した Martin Fowlerも「必要じゃなければやるな」と言っている

     では、いつ必要なのか?大きくは戦略論である。  エライひとや顧客から言われることも多いだろうと思うので、理解するためのヒント について少し言及する……ただ、後付けなので注意 Copyright 2019 FUJITSU LIMITED 92
  50. モノリシックサービスとマイクロサービス Copyright 2019 FUJITSU LIMITED コンポA コンポB コンポC コンポD コンポE

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

    約 会 議 リ リ | ス 一番時間のかかるチームに律速 全体会議ですり合わせ ビルドに半日かかってCI/CDにならない A B C D 組織のMission リリース どんどん(勝手に)リリース 全体の方向性はMissionで整える リリース リリース リリース 94
  52. チームを分割するとは  各チームに判断の権限が委譲されることで同期コストを削減  チームは小さく分割する  機能や技術ではなく、ビジネスや影響範囲、同時に管理されるべきサービスで分割する  意思疎通がうまくいくチームのサイズはサッカーチームくらい。 

    チームは独立する  チームでの決定に際して他所のチームの承認が必要な状況ではチーム分割が失敗している  データベースは統合しない。それぞれで持つ。  チーム間はAPIで会話する  APIで明示されていること以外は仮定しない  他人が突然DOSアタッカーになることもある。自己防衛が重要  ポステルの法則:“送信するものはわかりやすく厳密に、受信するものは寛容に” Copyright 2019 FUJITSU LIMITED 95
  53. 米軍)ジョン・ボイド大佐のOODA Loop Copyright 2019 FUJITSU LIMITED Observe Orientation Act Decide

    観察 方向性の決定 分析と統合 遺伝的資質 文化的伝統 新しい情報 経験則 判断 仮説作成 行動 試行 再検討 試行結果報告 行動の結果報告 状況 事件 闘争における人間の基本行動パターン(※天才を除く) ショートカット ショートカット OODAループ戦術:味方のループを高速化、敵ループを遅延させ、一方的に勝利を得る 101
  54. 訓練による究極OODALoop高速形 Copyright 2019 FUJITSU LIMITED Observe 観察 状況 事件 Act

    行動 試行 反射行動 ワンアウト一塁 二塁に送ってゲッツー ある現象に対して対処が明らか⇒訓練で高速ループ化 ショートゴロ 102
  55. 混乱による敵OODALoop遅滞戦術 Copyright 2019 FUJITSU LIMITED Observe Orientation Act Decide 観察

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

    方向性の決定 分析と統合 遺伝的資質 文化的伝統 新しい情報 経験則 判断 仮説作成 行動 試行 再検討 結果報告 状況 事件 • 相手より早くループを回せばより早く行動段階に到達出来、相手がまだ考えている間にタコ殴りにできる • 相手より早くループを回せば直接攻撃を加えなくてもより多くの選択肢を敵に突きつけることになる。 相手は行動段階に移れないうちに敗北する OODAループの基本戦術:自分達を速くして相手を遅延させる 高速化 104
  57. AWSのOODA戦術 Copyright 2019 FUJITSU LIMITED 最初から100%ではないサービス 開発速度で圧倒する スモールチーム Jeff Bezos

    速度で圧倒し、 敵を混乱に陥れ何もさせない うちに勝つ戦術 分析して対策する戦術が通じない戦い方 105
  58. 高速化のカギ:small team  互いに阿吽で意思疎通できる人数には限界がある  Amazonでは “The two pizza rule”

    というらしい •「社内のすべてのチームは2枚のピザを食べるのにピッタリなサイズでなければいけない」 •米海兵隊も小隊が現場での意思決定権を持つ  人数が増えると「調整役」「アジェンダ担当」「代表が出席してメンバーに再度広報」などい ろんなコストが増え、情報が行き渡らなくなり、決断できなくなる。 Copyright 2019 FUJITSU LIMITED 速いチームを作ろうとすると人数は増やせない (おまけ)チームが最速の瞬間はコミュニケーションは最小限 例)サッカーのアイコンタクト、野球のダブルプレイ 阿吽の呼吸には濃密な関係性が重要。やっぱり人数は増やせない。 106
  59. Amazon vs. Walmart  実際何が起きているのか?  ヴァーチャルな世界での戦い (EC)のポイントは、リアルな 実装(倉庫と物流網)である ようにも見える

    Copyright 2019 FUJITSU LIMITED https://forbesjapan.com/articles/detail/29147 アマゾンの「制約なき成長」の時期は過ぎた? 最大手が形勢逆転 実際のところ、IT Systemは業務の一部に過ぎないのだから “実装”であるリアル業務も変革しないとダメ(当たり前だが) ヴァーチャルな世界での戦いを互角に持ち込んだあとどうするか? そういう意味で“会社全体が戦う”体制の中でどうITを位置づけるかで マイクロサービスの採用については決めていく必要がある(やはり当たり前だが) 108
  60.  MicroServices=紀元前から続く“素早い”戦略のITへの反映 業務変革にITがついていくための組織構造でもある コンサルするなら実業への実装まで含めてネ(対象ビジネスをよく知らないとつらい) 事例を見ると、漸進的にアプリを解体・対応するのが鉄板  Cloud Native ≠ MicroServices

     目的が決まればたぶん手段はついてくる Copyright 2019 FUJITSU LIMITED とりあえず 闇雲に適用しても大変なだけで恩恵はないが、 MicroServicesの中で語られる技術や考え方そのものは Cloud Native的に有用なので選んで使いたい 117