Developer Summit 2018 FUKUOKA プレゼンテーション資料 https://event.shoeisha.jp/devsumi/20180906/session/1777/ 関連記事: https://codezine.jp/article/detail/11098

1. Presentation Slides for Developer Summit 2018 Fukuoka

2. 川崎 庸市 / Yoichi Kawasaki
@yokawasa
https://github.com/yokawasa
Azureテクノロジースペシャリスト（専門: Cloud App Dev ）
Ventures → ヤフー → マイクロソフト
インターネットサービス企業にてソフトウェアエンジニア、エンタープライズ検索製品
フィールドエンジニア、Azureソリューションアーキテクトを経て現職
2017年～ Global Back Belt（黒帯）というグローバル組織に所属しクラウド開発分野
でお客様・パートナー様の プリセールス技術支援、イベント・セミナー登壇を通じて
クラウド技術の普及に従事

5. https://twitter.com/acloudguru/status/1004743691158933505

6. Why Containers?

8. • コンテナ技術によりIaaSとは違った仮想化レベルを提供
• ベンダーごとの言語やフレームワークなどの制約が比較的フリー
• 複数コンテナを管理するオーケストレーション機能が重要な役割を担う

9. From Docker.inc : https://docs.docker.com/get-started/#images-and-containers
ホストOS上に配置されたライトウェートで高速に動作する分離された層
最終的にホストOS上の1プロセスとして実行されているアプリ
コンテナ化仮想化

10. コンテナ年表
2013
Docker
登場
2008
LXC
2014 2015 2016 2017 2018
Google
k8s発表
CNCF
設立
2013.6
2014.6
k8s1.0
2015.7
Docker
Swam発表
2014.12
Mesosphere
DC/OS発表
2016.4
CRI (Container runtime interface)
Docker
k8sサポート
宣言
2017.10
k8s1.10
2018.3
EKS, AKS
がGA
2018.6
k8s標準時代
CSI ( Container storage interface)
CNI(Container network interface)
OCI(open container initiative)
仕様標準化
コンテナ群雄割拠
( Docker & Kubernetesフォーカス )

11. Kubernetes（クーバネティス）
Master VM Master VM
Master VM
Worker
Node
Worker
Node
Worker
Node
Worker
Node
Worker
Node
Worker
Node
kubectl apiserver
Web UI
etcd
scheduler
Controller
manager
kubelet
kube proxy
Container
LBCLIコマンド
ダッシュボード
永続化データ保持のためのKVS
認証、CRUD操作
Podのノード割り当て 各種コントローラー
ノードごとの
Pod管理
Service VIPアドレスのルーティング
外部からの
アクセス
全ての操作はapiserver経由
API
Container
runtime
kubelet
kube proxy
Container
ノードごとの
Pod管理
Service VIPアドレスのルーティング
Container
runtime
https://kubernetes.io/docs/concepts/overview/components/

12. Layer 1
Layer 2
Layer 3
Layer 4
Layer 5
Layer 6
Layer 7
参考: Gabe Monroy on Twitter: "Strata of the Container Ecosystem https://twitter.com/gabrtv/status/539805332432637952

13. Docker＆Kubernetesのモメンタム
IDC Japan社
2018年 国内クラウドインフラストラクチャに関するユーザー動向調査結果
https://www.idcjapan.co.jp/Press/Current/20180614Apr.html
Dockerの導入状況に関するユーザー調査結果（調査年別）
41%

14. 高い可搬性と再利用性
自由度・柔軟性の高さ
• ランタイム環境、ミドルウェアに対する支配力
• 言語やフレームワークの制限はほとんどなく基本的にコードに変更なく、アプリ
ケーションの実行が可能
標準化

15. 抽象度が低く管理範囲が広い

16. https://twitter.com/jbeda/status/993978919907770368
https://twitter.com/jbeda/status/993978924890640388
Kubernetesは複雑
https://thenewstack.io/has-kubernetes-already-become-too-unnecessarily-complex-for-enterprise-it/
“When we started with YAML we never intended it
to be the user-facing solution,” Beda wrote. “We
saw it as ‘assembly code.’ I’m horrified that we are
still interacting with it directly.

17. Why Serverless?

18. サーバレス年表
2014 2015 2016 2017 2018
AWS Lambda
2014.11
Google Cloud
Functions
Azure
Functions
2016.2
2016.3
IBM
OpenWhisk
Serverless
Framework
2015.10
2016.12
OpenWhisk
(OSS) by IBM
Fn Project
(OSS) by Oracle
2017.10
CNCFが
Serverless
Whitepaper
を発表
2018.2

19. https://thenewstack.io/aws-lambda-still-towers-competition-much-longer/

21. Application
Application
Trigger/Binding
/Backend
Functions
(code)

22. イベントドリブンで
自動スケール
使った分だけ
細かく課金

23. 使った分だけ課金（Pay-as-you-go）
インフラ管理省力化
• インフラ 〜 アプリライフサイクルまで高いレベルで抽象化され、耐障害対策、
回復性設定がされているためインフラ管理リソースの省力化が可能
インスタンスの自動スケール
開発リソース省力化

24. 自由度・柔軟性の低さ
コールドスタート
実行時間や消費可能リソースの制約
ベンダーロックイン

26. 開発・デプロイの迅速性、生産性

27. https://trends.google.com/trends/explore?date=2016-01-01%202018-08-27&q=Kubernetes,Serverless,AWS%20Lambda

29. • Cloud Native Computing
Foundation（CNCF）の
Serverless Working Groupによるホ
ワイトペーパー
• Serverlessのみならず、CaaSやPaaS含め
た使い分け方などが分かりやすく解説
されている
CNCF Serverless Whitepaper Github
https://github.com/cncf/wg-
serverless/tree/master/whitepapers
【完訳】CNCF Serverless Whitepaper v1.0
http://www.atmarkit.co.jp/ait/series/9263/
https://www.slideshare.net/jacopen/k8spaasserverles
s

31. 要件 内容例
可用性 回復性、稼働率、RTO(目標復旧時間) 、RPO(回復ポイント目標)
性能・拡張性 ユーザ数、RPS、目標レスポンス速度、成長に応じた拡張
運用保守性 バックアップ、計画停止、運用監視、障害時対応、運用自動化
移行性 移行時期、並行稼働有無、システム展開方式、移行データ量
セキュリティ コンプライアンス、リスク分析、通信制御、認証、不正検知・追
跡・監視
情報処理推進機構（IPA）の非機能要件グレード 非機能項目（大項目）と、内容例

32. コンテナ / CaaS サーバレス / FaaS
コンテキスト依存
（ステートフル？レス？）
ステートフル・レス関わらず柔軟な対
応が可能。ただし、ステートフル対応
は比較的難易度が高い
ステートフルなワークロードには向い
ていない（もちろん対応は可能）
依存ライブラリ・
言語（自由度）
自由度が非常に高い プラットフォーム依存で自由度は低い
稼働パターン コンピュートリソースは常時稼働
アイドル時間もコスト発生
イベント発火による実行パターンで
アイドル時間のコスト不要
大量実行でコスト高となりうる
性能・拡張性 高速起動
オートスケール設定可能
設定責任高い
コールドスタート問題あり
ネイティブにオートスケール対応
設定責任低い
回復性 回復性設定可能
設定責任高い
ネイティブに回復性を持っている
設定責任低い
運用保守性 インフラ支配力高く監視・トレースの
自由度は高い
インフラ支配力が低く、監視・トレー
サビリティはプラットフォーム依存

33. • 開発運用体制の充実度
• スキルレベル・経験
• 納期までの時間
• 経済力
• 既存システム資産
• etc

34. アプリ特性/機能要件
• コンテキスト依存度
• 依存ライブラリ・言語
• 稼働時間
非機能要件
• 性能・拡張性
• 回復性
• 運用保守性
与えられた条件・制約
• 開発・運用体制
• スキルレベル・経験
• 納期までの時間
• 経済力
• 既存システム資産
選択を行う

35. 既存
アプリ
APP
モダン
マイクロサービス
モダン
メソッド
CI/CDの実装
自動化
モダン
インフラ
クラウド移行
VM / コンテナ
(Lift & Shift)
アプリの
コンテナ化
コンテナで
アプリ再設計

36. （＊）クラウドネイティブアプリ＝コンテナ、PaaS、サーバレスの適材適所の
活用で、アプリ構造とアーキテクチャが最適化されたアプリ

38. • 本当にマイクロサービス化する必要はありますか？
• 本当にKubernetesが必要ですか？
• それ全部Functionsで実現するのですか？
• もっとシンプルな方法はないですか？

39. • データ一貫性・整合性の維持
• 複雑なサービス間通信
• クライアント・アプリ間の通信
• 分散アプリケーションのモニタリング
• 継続的インテグレーションとデリバリ (CI/CD)

40. マイクロサービスの粒度を適正にしたい
• ドメインベース設計しっかりやる
• 長期運用を考えてメリットがあるのかを考える
マイクロサービス間通信の制御・監視
• サービスメッシュの導入を考える
• Istio / Linkerd / Conduit
マイクロサービス処理の見通しをよくしたい
• ワークフローの整理・管理
• クラウドFaaSだったら Logic App/Durable Functions (Azure), AWS Step
Functions, Google Composer, etc.

41. NoOps = No "Uncomfortable" Ops
エンドユーザー
サービス停止時間の最小化、レスポンスタイム
の安定化など、高いサービスレベルを安定して
享受できる
運用担当者
• システム運用作業の「非同期化」
• 障害解析などの運用業務がなくなることはないが、
「今すぐ急いで」から「後でゆっくり」へ業務特
性を転換することができる
• 空いた時間で「開発」することができる
→ 運用機能の開発やアプリケーションの開発

42. 当然ながら
回復性の実現は簡単ではありません
https://docs.microsoft.com/ja-
jp/azure/architecture/patterns/category/resiliency
生まれながらに回復性が実装されている PaaS
やサーバレスを可能な範囲で適材適所に活用
して負担をおフロードしていくことが得策
（時間・リソースは有限である）

43. https://www.slideshare.net/hiromasaoka/noops-88082246

44. 9月12日開催予定
NoOps Meetup Tokyo #1
https://noops.connpass.com/

48. k8s認定プログラム

50. • Events
• Workflows / Function Composition
• Event Orchestration / Chaining
• Function Signatures
CNCF Serverless WG / Proposals
https://github.com/cncf/wg-serverless/tree/master/proposals

51. CNCF Serverless WGを中心に進められている
イベントスキーマ標準化のための共通仕様
• 異なるシステム間でのイベントの相互運用性（”
interoperability”）確保が目的
• FaaSのポータビリティ、Event-Drivenシステム開発・テスト改善、etc.
• イベントはさまざまなプロトコルで配送可能にする
• 業界標準(HTTP, AMQP, MQTT, SMTP)、OSS(Kafka, NATS)、ベンダー
固有(AWS Kinesis, Azure Event Grid), etc.
https://cloudevents.io/
https://github.com/cloudevents/spec/blob/master/json-format.md
サンプル: CloudEvent JSON (data部分が文字列の例)

52. https://docs.microsoft.com/en-us/azure/event-grid/ https://serverless.com/event-gateway/

57. Cloud

60. Kubernetes
control pane
Application
architect
Infrastructure
architect
Azure Container Instances (ACI)
ACI
Connector
Pod
Pod Pod
Pod
Pod Pod
Pod
Pod Pod
Pod
Pod Pod
VM VM
VM VM
Deployment/
tasks
Pod Pod Pod Pod Pod
Pod Pod Pod Pod Pod
Pod Pod Pod Pod Pod
Pod Pod Pod Pod Pod
Pod Pod Pod Pod Pod
WasteWaste
WasteWaste PodPod
PodPod
Azure Container Instanceの例
ACI Connector for Kubernetes（VirtualKublet実装）を使用したKuberneteクラスタからの実行例

61. “observability is a measure of how well internal states of
a system can be inferred from knowledge of its external
outputs”
Wikipedia: https://en.wikipedia.org/wiki/Observability

63. https://landscape.cncf.io/grouping
=landscape&landscape=observabil
ity-and-analysis