More Related Content Similar to LiBRA 06.2021 / 総集編 2/2
Similar to LiBRA 06.2021 / 総集編 2/2 (20) More from Masanori Saito (19) LiBRA 06.2021 / 総集編 2/211. 使 用
の現場 センサー コンピュータ ソフトウエア
モノ・製品
モノのサービス化の本質
ものづくり
の現場
開 発
製 造
保守
サポート
ソフトウェア
改修・更新
インターネット
直
結
・
連
係
14. 「モノのサービス化」ビジネス
コア・ビジネス
既存ビジネス
蓄積されたノウハウ
確実な顧客ベース
付加価値ビジネス
収益構造の多様化
既存ノウハウの活用
顧客ベースの囲い込み
新規ビジネス
顧客価値の拡大
ノウハウの創出
顧客ベースの拡大
製造・販売
製造・販売 製造・販売
走行距離に応じた
従量課金サービス
Pay by Mile
出力×時間に応じた
従量課金サービス
Pay by Power
工事施工
自動化サービス
Smart Constriction
建設機械
遠隔確認サービス
KOMTRAX
安全・省エネ運転
コンサルティング
予防保守・交換
燃料費節約
コンサルティング
予防保守・交換
19. ソフトウェア化するモノ
19
物理的・物質的なモノでしか実現できない部分
プログラムで制御または実現できる機能・性能
レンズ
シャッター
ボディなど
タイヤ
エンジン
車体など
機体・翼
ジェット・エンジン
燃料タンクなど
シャッタースピード
発色・感度
フォーカスなど
ブレーキ・タイミング
エンジン制御
機器のオンオフなど
姿勢や方向の制御
エンジンの制御
機内環境の制御など
ソ
フ
ト
ウ
ェ
ア
ハ
ー
ド
ウ
ェ
ア
製造コストの低減
故障要因の低減
保守容易性の実現
できるだけ
シンプルに
開発コストの低減
高機能化のしやすさ
保守容易性の実現
できるだけ
多機能に
IoT化
通信機能を組み込み
インターネットにつ
なげることでモノを
サービス化する
モジュラー化
機能を標準化・部品
化することで、生産
コストの低減と保守
性を向上させる
24. データとモノ/コト・ビジネスの関係
属性データ 商 品 販売代金
属性に最適化された
商品の作り込み
魅力的な商品を作る
属性理解→商品設計→商品開発
行動データ UX サブスク
従量課金
状況に最適化された
UXのアップデート
魅力的な体験を作る
状況理解→UX設計→UX開発
体験を継続したいという想いへの対価
商品を手に入れることへの対価
行動データ 商 品 販売代金
うまくいかないビジネス
行動データを取得する意味がない 商品の機能や性能を
アップデートできなければ意味がない
アップデートのコストをまかなえない
25. データ活用の前提はData Virtuous Cycle を実装すること
プロダクトやサービスを
提供する
プロダクトやサービスを
使用する
データを
収集する
データから
学ぶ
プロダクトやサービスを
改善する
IoT・Mobile・Web
AI(機械学習)
クラウド+デバイス
データ
生活データ
行動データ
属性データ
30. 学習と推論の役割分担
30
学習
推論
学習
推論
大規模な計算能力
専用プロセッサー
長時間演算
比較的小規模な計算能力
専用プロセッサー・省電力
短時間演算
学習モデル 学習モデル
学習
推論
学習モデル
学習モデル
クラウドでモデルを作り、
そのモデルをエッジのデバ
イスに送りリアルタイムの
現場のデータから予測や判
定を行う。
リアルタイム性が重要な処
理は、できるだけ現場に近
い場所で処理できたほうが
有利。また、機器の個体差
にも対処できる。
クラウドで完結するサービ
スに適用。
学習
推論
推論モデル(予測や分類などの
ルール)を大量のデータから作る
推論モデルを使って現場データ
から予測や分類、判断/判定を行う
AISing,HACURUS,
SOINN など
ARAYA,LEAPMIND,
IDENなど
ABEJA,Microsoft,Google,
Facebook,Amazon,
Preferred Networkなど
NVIDIA,Intelなど
32. 超分散の時代
32
インターネット
専用ネットワーク
インターネット
専用ネットワーク
専用ネットワーク
テキスト テキスト+ 画像 マルチメディア(テキスト×画像×動画) マルチメディア + センサー
全てのデータ保管・処理は集中
大規模なデータ保管・処理は集中
小規模なデータ保管・処理は分散
大規模なデータ保管・処理は集中
小規模なデータ保管・処理は分散
大規模なデータ保管・処理は集中
小規模なデータ保管・処理は分散
高速な処理・応答・制御は超分散
集中コンピューティング 分散コンピューティング クラウド・コンピューティング 超分散コンピューティング
通信経路上の
エッジサーバー
分散サーバー 分散サーバー ローカル
エッジサーバー
1960年代〜 1980年代〜 2000年代〜 2015年〜
組み込みコンピューター
34. IoT World Forumのリファレンス・モデル
34
物理的なデバイスとコントロー
Physical Devices &controllers
モノと設備・モノの周辺に配置される制御機器類
接続
Connectivity
ネットワークや機器との通信
エッジコンピューティング
Edge Computing
モノの周辺でのデータ分析や変換処理
データ抽象化
Data Abstraction
データ集約とアクセス
アプリケーション
Application
データ活用(業務処理・分析・レポート)
協働とプロセス
Corroboration & Processes
人と業務プロセス
データの蓄積
Data Accumulation
データの蓄積と管理
36. 1G 2G 3G 4G 5G
音声 テキスト データ 動画
あらゆるモノがつながることを前提とした
社会課題の解決
通信・コミュニケーションの性能向上
移動体通信システムの歴史
1979〜 1993〜 2001〜 2012〜
2020〜
9.6Kbps 28.8〜384Kbps 2.4〜14.4Mbps 0.1〜1Gbps
10Gbps〜
37. 5Gのビジネスの適用領域
データ量超増大 × 即時性向上
1通信あたりのデータの嵩が増える
リッチ化する:高精細や高音質になり臨場感、没入感
が増す
多角化する:同時に取り扱える情報の選択肢が増える
1通信あたりのデータの種類が増える
制御用の情報(センサーやカメラからの情報)が増え
る:自動○○が実現する
参考可能な情報(ログ情報)が増える:パーソナライ
ズのパターンが増える、レコメンドの精度が向上する、
対象への理解が深まる
タイムラグがほぼ無くなる
距離の制約が消える:各地に散らばる人たち同士で同
時に何かやる、今やった/起きたことをすぐに取り込
んですぐ活かす
社会(利便性)向上系
医療分野
超高信頼低遅延通信の実現で移動中や遠隔地の高度診療が可能になり、
医療格差が解消される
農林水産分野
超大量端末同時接続の実現で作物や家畜などの状況を把握するセン
サーと散水・薬剤散布や給餌を実施するロボットやドローンの制御が
可能になり、減少する従事人口を補える
土木建築分野
超大量端末同時接続と超高信頼低遅延通信の実現によって遠隔制御が
可能になり、危険度が高い高所・鉱山・災害地などの現場での安全な
作業が確保でき、またドローンの活用による高精度測量などの精度が
向上する
生活分野
自動運転と遠隔制御によって、細分化された公共交通が実現する
センサー情報を駆使して状況を把握する店舗運営が可能になる
遠隔授業や家庭教師の実現によって、学習格差が解消される
大量センサーと自動判定AIによって、防災・防犯・減災力が向上
VRオフィスとテレワークが実現する
コンテンツ向上系
スポーツの場合⇒体験が深くなる
自動制御が可能になってカメラ台数を一気に増やせることで、多地
点・ドローンなどによる多角度撮影ができるようになる
取得データの種類が増え分析できる情報が増えることで、選手のバイ
タルデータ・顧客のバイタルデータ・環境データが取得できるように
なる
AIが発達することでデータの有効活用レベルが上がり、多角的な分析
結果を提示できるようになる
エンタメの場合⇒現実を超える仮想実現へ
即時性が向上することで出演者の居場所を問わない制作環境を実現さ
せることや、同時多人数対応の参加型体験の提供ができるようになる
スポーツ&エンタメに共通
1通信あたりの送信データの嵩が増え、高画質・高音質・8K360°リ
アルタイムな高臨場感映像が提供できるようになり、また視聴者に合
わせた多種多様な映像・情報を提供できるようになる
生活者データ・ドリブン・マーケテイィング通信より https://seikatsusha-ddm.com/article/10129/
39. 第5世代通信の適用例
高速・大容量データ通信
10G〜20Gbpsのピークレート
どこでも100Mbps程度
大量端末の接続
現在の100倍の端末数
省電力性能
超低遅延・超高信頼性
1m秒以下
確実な通信の信頼性担保
5G
多様なサービスへの適用を可能にする
異なる要件のすべてを1つのネットワークで実現する。
各要件をに応じてネットワークを仮想的に分離して提供する(ネットワーク・スライシング)。
2020年代〜
2時間の映画を
3秒でダウンロード
ロボット等の
精緻な遠隔操作を
リアルタイムで実現
自宅内の約100個のモノ
がネットに接続
(現行技術では数個)
現在の移動通信システムより
100倍速いブロードバンドサー
ビスを提供
利用者がタイムラグを意識
することなく、リアルタイ
ムに遠隔地のロボット等を
操作・制御
スマホ、PCをはじめ、身の
回りのあらゆる機器がネッ
トに接続
49. 汎用型人工知能
AGI : Artificial General Intelligence
汎用的で自律的に拡張する
知的処理
AIとAGIの関係
特定の領域に特化した
知的処理
特化型人工知能
AI : Artificial Intelligence
何を知るべきを見つける
どうすればいいかを探す
55. 人工知能と機械学習の関係
55
人工知能 Artificial Intelligence/AI
機械学習 Machine Learning
ニューラル・ネットワーク
Neural Network
深層学習
Deep Learning
人間の”知能”を機械で
人工的に再現したもの
強いAI:コンピュー
タに人間と同様の知
能を持たせた仕組み
弱いAI:コンピュー
タに人間と同様の知
的な振る舞い・処理
をさせる仕組み
データからグループ分
けのためのルール(モ
デル)を作る仕組み
脳の仕組みを参考に作
られた機械学習の手法
従来よりも精度の高いモ
デルを作ることができる
ニューラル・ネットワー
クの手法
遺伝アルゴリズム、エキスパートシステム、音声認識、画像認識、感性処理、機械学習、
ゲーム、自然言語処理、情報検索、推論、探索知識表現、データマイニング、ニューラル
ネット、ヒューマンインターフェース、プランニング、マルチエージェント、ロボット
データ
プログラム
モデル
57. 第3次AIブームの背景とこれから
57
1960 1970 1980 1990 2000 2010 2020 2030
第1次AIブーム
推論・探査など
ゲームや迷路などに
用途は限られ実用性は
無かった
第2次AIブーム
ルールベースなど
エキスバーとシステムと
して実用化されたが汎用
性が無かった
第3次AIブーム
機械学習(統計確率論や深層学習など)
汎用性、実用性が高まり、様々な分野の適用
が期待されている
大型コンピューター
メインフレーム
パーソナル・コンピューター
スマート
フォン
IoT
ビッグデータ時代の到来
ARPAnet 米国・インターネット
商用利用開始
日本・インターネット
商用利用開始(IIJ)
World Wide Web
が開発され公開
画像が扱えるWWWブラウザー
Mozaicが開発され公開
Windows95発売
IEが付属し、ブラウザーでの
インターネット利用者が拡大
ISLVRCにて
ディープラーニング圧勝
1969 1990 1993
1995
2012
Googleによる
猫認識
2011
Jeopardyにて
IBM Watson勝利
電脳将棋
竜王戦 開始
1997
チェス・チャンピオンに勝利
IBM Deep Blue
2007
iPhone
発売
1981
IBM PC 5150
発売
汎用人工知能
Artificial General Intelligence
登場の可能性
ムーアの法則/コンピュータ性能の加速度的向上
1965〜
ムーアの法則の限界/新たな選択肢の登場
GPGPU、ニューロモーフィング・チップ
量子コンピュータ等
IBM S/360
メインフレーム
1964
ニューラル
ネットワーク
考案
Intel 404
マイクロプロセッサ
1971
データ流通量
1957
1956
ダートマス
会議
1982
第5世代
コンピュータ
プロジェクト
62. ルールベースと機械学習
62
Sheep Dog
を見分ける仕様
やルール
= if XX
Then XXX
else XXX
Mop
を見分ける仕様
やルール
= if XX
Then XXX
else XXX
Sheep Dog
を見分ける仕様
やルール
0101011101010
1110101001011
1110010101010
Mop
を見分ける仕様
やルール
0111100101010
1101010001010
1110100100101
人間が記述 データから生成
67. 一般的機械学習とディープラーニングとの違い
67
耳 27%
目 48%
口 12%
特徴量
「特徴量」とは、猫と犬を識別・分類するために着目すべき特徴
正しく認識 82%
誤った認識 18%
認識結果
耳 27%
目 48%
口 12%
特徴量
学習
ディープラーニング
学習
推論
ディープラーニング
推論
正しく認識 82%
誤った認識 18%
認識結果
人間が認識結果が
最適になる組合せを
見つける
機械が認識結果が
最適になる組合せを
見つける
学習データ
教師付きデータ 学習データの一部
評価データ
70. 自動化ツール
Google Cloud AutoML
Microsoft Azure ML
AWS SageMaker など
AIと人間の役割分担
データを準備
意志決定
学習方式の選択
パラメーターの調整
推論
問いを生みだす
解決したいこと・知りたいことを決める
膨大なデータの中から、人間
の経験に基づく先入観なしに
規則、相関、区分を見つける
新たな問いを生みだす
判断・制御
モデル
87. 機械学習とデータサイエンス
87
データ
アナログな現実世界の「ものごと」や「できごと」
学習
推論
識別
予測 判断
ゾウ or カバ? 正常 or 異常?
晴れ or 雨?
音声認識
顔認証
自動運転
創薬支援
天気予報 画像診断 人材採用
故障予測
機械翻訳 競技アドバイス
惑星探査 ヒビ割れ点検
製品品質検査
アプリケーション
機械翻訳 商品提案
モデルと
プロセスの設計
要件と課題
の設定
仮説の設定
学習
モデル
データ
の探査
データ
の収集
IoT、モバイル、Webなど
特徴が共通するグループに
分けるための基準/ルール
(学習モデル)を作る
学習モデルを使って
特徴が共通するグループに
分類する
機械学習
デジタル化された学習データ
データ・サイエンス
多くの学問領域にわたる科学的手法やシステ
ムなどを使い、様々なデータから知見や洞察
を引き出そうとする研究分野
何を知りたいか?
どのように知るかを
まずは明確にする
100. コード管理 コード確認 登録 構築 リリース
議事録・ガントチャートなど
情報はバラバラで
リアルタイムに進捗や状況が分からない
誰がやっているのかが分からない
伝言ゲームで現場の空気が伝わらない
タイムリーに検証ができない
リリースに時間かがかかる
開発と運用 現状
101. コード管理 コード確認 構築 リリース
開発と運用 これから
タスク
の共有
進捗や課題などのをリアルタイムに共有
開発する現場と利用する現場が一体となる
フィードバック・アップデート・リリース
のサイクルを高速で回す
105. アジャイル開発のプロセス
開発 開発 開発
イテレーション/反復#1 イテレーション/反復#2 イテレーション/反復#3
開発
イテレーション/反復#n
業務上の重要度に基づいて優先順位を決めて業務プロセスを積み上げてゆく。
リリースされるプロセスは実行可能であり、ユーザーがそれを使って検証できる。
現場のフィードバックを受け入れ、次のイテレーションで統合してリリースする。
リリース フィード
バック
最も重要度の高い
業務プロセス
業務上の成果があげられる
と判断されて完成とする
重要度の高い順番に
業務プロセスを追加
追加されたプロセスは既にリリースした
プロセスと統合し品質を確認する
ウオーターフォール開発
要
件
定
義
外
部
設
計
内
部
設
計
プ
ロ
グ
ラ
ム
設
計
プ
ロ
グ
ラ
ミ
ン
グ
統
合
テ
ス
ト
結
合
テ
ス
ト
リリース
109. ウォーターフォールとアジャイルの違い
ユーザーと開発者はプロジェクトを通して、日々一緒
に働く
ユーザの満足を優先し価値あるソフトウェアを早く継
続的に提供する
要求の変更はたとえ開発の後期であっても歓迎する
動くソフトウェアをできるだけ短い間隔( 2〜3週間
あるいは2〜3ヶ月)でリリースする
動くソフトウェアこそ進捗の最も重要な尺度
技術的卓越性と優れた設計に対する普段の注意が機敏
さを高める
シンプル(無駄なく作れる量)に作ることが基本
最良のアーキテクチャ・要求・設計は自己組織的な
チームから生み出される
チームが最も効率を高めることができるかを定期的に
振り返り、それに基づいて自分たちのやり方を最適に
調整する
アジャイルな思想
ユーザと開発者はいつもは別の場所にいてプロジェク
トを通して定例ミーティングを行う
ユーザーの満足や価値のあるなしではなく、とにかく
ソフトウェアを提供する
要求の変更を開発の後期に出すの勘弁して欲しい
パワポ、エクセル、ワードの仕様書を丁寧に清書して
( 2〜3週間あるいは2〜3ヶ月)納品する
動くソフトウェアこそ進捗の最も重要な尺度
技術的卓越性と優れた設計に対する普段の注意が機敏
さを高める
仕様書通り(間違っていようが)に作ることが基本
最良のアーキテクチャ・要求・設計は自己組織的な
チームから生み出される
チームがもっと稼働率を高めるように監視し、それに
基づいて自分たちへの批判や不満を回避するために、
念のため納期を厳しめに設定する
ウォーターフォールな思想
https://speakerdeck.com/kawaguti/flipped-agile-manifest
Yasunobu Kawaguchi氏 資料を参考に作成
117. アジャイル開発の目的・理念・手法
117
高品質で無駄がなく、変更要求に対応できるきるソフトウエアを作成する為
適切な一連の手順に従う
高い協調と自律的なプロジェクト関係者によって実施される
イタラティブ(反復/周期)、インクリメンタル(順次増加部分を積み上げていく)方式
ダイナミックシステムズ開発技法(Dynamic Systems Development Method) Dane Faulknerほか
アダプティブソフトウェア開発(Adaptive Software Development) Jim Highsmith
クリスタルメソッド(Crystal Methods) Alistair Cockburn)
スクラム(Scrum) Ken Schwaber、Jeff Sutherland
エクストリームプログラミング(XP/eXtreme Programing) Kent Beck、Eric Gammaほか
リーンソフトウェア開発(Lean Software Development) Tom and Mary Poppendieck
フィーチャ駆動開発(Feature-Driven Development) Peter Code、Jeff DeLuca
アジャイル統一プロセス(Agile Unified Process) Scott Ambler
反復(周期)的(Iterative) --- 定期的なリリース
漸進的(Incremental) --- 徐々に機能を増加
適応主義(Adaptive) --- 変化に対応(即応)
自律的(Self-Organized) --- 学習する組織
多能工(Cell Production) --- 一人多役(SE、プログラマー、テスター)
目的と理念
手 法
共通する要素
119. スクラム:特徴・3本の柱・基本的考え方
119
システム開発のフレームワーク(1995)/ Ken Schwaber & Jeff Sutherland
特徴
軽量
理解しやすい(シンプル)
会得するのは比較的難しい
三本の柱
Transparency (透明性)
Inspection (視察、検査)
Adaptation (適応、順応、改作)
基本的考え方
タイム・ボックス(Time Box)
時間を区切って、その時間内に目的を果たす仕事を行う仕事の仕方
機能横断的な固定化されたチーム
チーム内で役割分担を決めず、全員が必要な仕事をこなす多能工(T型人間のチームででき
るだけチームメ ンバーを固定化した方がよい
持続可能なペース
徹夜や残業を排除して安定した持続可能な一定のペースで開発し、定期的にリリースを行う
120. スクラム:スクラム・プロセス
120
イテレーション(反復) 4
1〜4週間
イテレーション(反復) 3
1〜4週間
イテレーション(反復) 2
1〜4週間
イテレーション(反復) 1
1〜4週間
納品 納品 納品 納品
プロダクト・オーナー
プロダクト・バックログ
1. --------------------
2. --------------------
3. --------------------
4. --------------------
5. --------------------
6. --------------------
スプリント・プラン
イテレーション毎の
内容区分
2時間程度の単位
スクラム・マスター
タスク・リスト
スプリント・バックログ
1. --------------------
2. --------------------
3. --------------------
4. --------------------
5. --------------------
開発チーム
バーンダウン
チャート
デイリー
スクラム
開発・テスト
インテグレーション
To Do On Going Done Keep
Problem
Try
スタンドアップミーティング & スプリント・レビュー・振り返り
121. スクラム:プロダクト・オーナー
121
ミッションと責任
プロダクトの完成図と方向性を示す
プロダクトに必要な機能の詳細を決める
リリースの内容と日程を決める
市場価値に基づくプロダクト・パックログの優先順位を決める
スプリント毎に優先順位を変更できる権限を持つ
プロダクトの収益性(ROI)の責任を持つ
プロダクト・オーナーが行う事
プロダクトのビジョンを作成し、関係者に示し、共有する
対象プロダクトのビジネス要求(ビジネス環境)の説明
エピック、ユーザーストーリーの確定とペルソナの作成
ユーザーストーリー毎の受け入れ基準の承認
プロダクト・バックログの優先順位付けとプロジェクト期間中の維持管理
開発チームへのユーザーストーリーの説明
開発チームのDoD(完了の定義)作成の支援
リリース計画の承認
稼働環境の定義
EOL(プロダクトの終焉)条件の設定
123. スクラム:開発チーム
123
自己組織的なチームである
自律性
メンバーが自ら日々の仕事を管理する
自己超越
常に目標を達成するように自らを追い込み、常に自身のプラクティスを改善する
相互交換作用
機能横断的かつ定めた役割がない
目標にコミットする義務がある
チームはスプリント計画ミーティングでコミットした目標を達成する責 任
を持つ
目標達成につながるならば方法を限定しない
チームは全ての決断を下す権限、必要なことを何でも行う権限、あらゆる障
害の除去を依頼する権限を持つ
争議はチーム内で解決する
作業規約を作る
124. エクストリーム・プログラミング(XP)
124
テスト駆動開発(Test-Driven Development:TDD)=テストファース
ト・プログラミング
実装する機能をテストするプログラムを書く
コードを書いてテストする
デザインを見直す
信号が青になる(テスト・コードが成功する)まで繰り返す
リファクタリング
完成したコードの見直し(実装された機能を変えずに、コードをシンプルに、
見やすくする)
任意の作業(全員が行う&時間が空いたら行う)
ペアプログラミング
ドライバー(コードを書く人)
ナビゲーター(コードをチェックする人、ナビゲーションをする人)
この役割を1日の中でペア間で、途中で交代する
ペアの組み合わせを毎日替える
10分間ビルド
自動的にシステム全体をビルドして、全てのテストを10分以内に実行させる
Kent Beck(1999年)によって提唱された開発手法
126. アジャイル開発で品質が向上する理由
126
タスクの粒度を小さくすることはTPSにおける小ロット化と同様
「流れ」を作り、負荷を平準化し、柔軟性を高める
タスクの粒度は小さいほど良い
1日以内、理想は1時間
責任を持って見積ができる
バグを作り込まない(簡単にテスト可能)
他のペアと同期がとれる
ダイナミックなプロジェクト運営が可能となる(チーム編成の増減、分散開発など)
タスクが小さくできないのは、作業対象の内容把握に問題が存在するのではないか?
タスクを小さく分割するという事は、作業指示書を作成する事。
Statements of Source
code
Test Cases Test Coverage
1 1 100.00%
10 2 100.00%
100 5 95.00%
1,000 15 75.00%
10,000 250 50.00%
100,000 4,000 35.00%
1,000,000 50,000 25.00%
10,000,000 350,000 15.00%
Application size, Test Cases, and Test Coverage. Logical source code statements
By Caper Jones
127. DoD (Definition of Done) 完了の定義
127
各作業の完了基準
閾値(標準値)を決める。
作業経過、結果を計測する。
自工程完結の基本的な姿勢(現場での意思決定)
仁=他人の努力を無駄にしない思いやり
検
査
検
査
検
査
発生防止
流出防止
プロセス プロセス プロセス 検
査
納入
検査 検査 検査
DoD
129. ビジネス 開発 運用
アジャイル開発 DevOps
アプリケーション開発環境
マイクロ・サービス、ルールエンジン、AI、APIなど
ITインフラストラクチャー
IaaSなどのクラウド
アプリケーション実行環境
コンテナ・オーケストレーション・ツール
サーバーレス・FaaS
Infrastructure as Code
運用の自動化
SRE
Site Reliability Engineer
アイデアの創発
デザイン思考
リーンスタートアップ
トライ・アンド・エラー
のサイクルを高速で回す
ビジネス・スピードを加速する方法
ビジネスの成果に貢献するコードのみ
現場のニーズにジャストインタイム
バグフリーと変更への迅速・柔軟な対応
開発されたコードを直ちに本番移行
安定稼働の維持
変更やスケールへの迅速・柔軟な対応
139. DockerとKubernetes の関係
139
コンテナの作成
コンテナの実行
コンテナ内でファイルシステ
ムとして使われるイメージの
作成および管理 など
関連するコンテナのグルーピング
コンテナに割り振られるIPアドレスの管理
コンテナ間ネットワークルーティング管理
複数のコンテナを利用した負荷分散
コンテナに割り当てるストレージの管理
コンテナの監視 など
ネットワークのルーティングや複数コンテナの
連携、複数台のサーバーを対象にコンテナを横
断的に管理する機能などは提供されていない。
クラスタ環境でDockerを利用する場合は別途何らかの管理手法を用意する必要がある。
Dockerと連携して利用できるデプロイ/オーケストレーションツールのひとつ
By Google
Manage a cluster of Linux containers as a single
system to accelerate Dev and simplify Ops.
Linuxコンテナのクラスタを単一のシステムとして管理して
開発を加速し、運用を簡素化します。
意味:ギリシャ語で「人生の道標」
読み方:クーベルネイテス(koo-ber-nay'-tace)
140. Twelve Factorsとの関係
140
Ⅰ. コードベース
バージョン管理されている1つのコードベースと複数のデプロイ
Ⅱ. 依存関係
依存関係を明示的に宣言し分離する
Ⅲ. 設定
設定を環境変数に格納する
Ⅳ. バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
Ⅴ. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
Ⅵ. プロセス
アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
Ⅶ. ポートバインディング
ポートバインディングを通してサービスを公開する
Ⅷ. 並行性
プロセスモデルによってスケールアウトする
Ⅸ. 廃棄容易性
高速な起動とグレースフルシャットダウンで堅牢性を最大化する
Ⅹ. 開発/本番一致
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
Ⅺ. ログ
ログをイベントストリームとして扱う
Ⅻ. 管理プロセス
管理タスクを1回限りのプロセスとして実行する
アジリティーの高いWebサービスを構築するための方法論
コンテナ Kubernetes
https://12factor.net/ja/