Webアプリ開発向けゆるふわDocker使いがCloud Naive開発に必要そうなetc.

Webアプリ開発向け
ゆるふわDocker使いが
Cloud Naive開発に必要そうなetc.
Cloud Native Online #02
やっさん
@yassan168

#cnjp
はじめに
dockerやKubernetes(以下k8s)自身の話は、
ほぼしません（期待してたらスミマセン）。
k8sをベースとしたCloud Native(以下、CN)な開発に
必要な取っ掛かりについて話します。

#cnjp
とは言え、、、
Dockerやk8sについては、以下の本がオススメです。
もしくは、最後の資料スライドを参照。

#cnjp
想定している人
以下な開発者
• docker-composeを何となく使った事がある
• k8sとかCNな開発にピンと来ない
• それ美味しいの？

Cloud Nativeってなんだろう？

#cnjp
Cloud Native って何？
Cloud Native ＝ Kubernetes
Cloud Native ＝ Microservice

#cnjp
詳しくはこの辺を読むと分かります（ぁ
『コンテナ疲れ』と戦う、 k8s・PaaS・Serverlessの活用法
飛び込もう、Cloud Nativeの世界

#cnjp
Cloud Native って何？
Cloud Native ≠ Kubernetes
Cloud Native ≠ Microservice

#cnjp
Cloud Nativeって何?～　CNCFによるCloud Nativeの定義～
Cloud Native技術は、Public Cloud、Private Cloud、Hybrid Cloud等の
近代的でダイナミックな環境において、スケーラブルなアプリケーション
を構築及び実行する為の能力を組織にもたらします。
このアプローチの代表例に、コンテナ、サービスメッシュ、
マイクロサービス、イミューダブルインフラストラクチャ、
および宣言型APIがあります。
これらの手法により、回復性、管理力、および可観測性のある疎結合シス
テムが実現します。これらを堅牢な自動化と組み合わせる事で、
エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測通りに
行う事が出来ます。

#cnjp
Cloud Native技術がもたらすもの
Cloud Native技術により以下を実現。
→回復性、管理力、及び可観測性のある疎結合システム
更に、
　Cloud Native技術＋堅牢な自動化
　
　インパクトのある変更を
　最小限の労力で頻繁かつ予測通りに行う事が出来る

#cnjp
Cloud Native技術により以下を実現。
→回復性、管理力、及び可観測性のある疎結合システム
更に、
　Cloud Native技術＋堅牢な自動化
　
　インパクトのある変更を
　最小限の労力で頻繁かつ予測通りに行う事が出来る
ここ大事

#cnjp
Cloud Native技術により
近代的でダイナミックな環境(インフラ)で、
スケーラブルな開発が出来る能力を組織にもたらす。

#cnjp
Cloud Native技術により
近代的でダイナミックな環境(インフラ)で、
スケーラブルな開発が出来る能力を組織にもたらす。
これが前提
つまり、いわゆる、クラウド。
もしくは、それに相当するオンプレのインフラ。

#cnjp
つまり。。。
人間の関与を排除したクラウド(又はそれに近い)環境で
Cloud Native技術を用いる事で、
1日に10回20回リリース出来るようになります。

#cnjp
「人間の関与を排除する」？
Kubernetes 完全ガイド（P.424）でも以下の記述があります。
実際に運用を行う際には手動でのkubectlコマンドの実行は、可能な限り
避けるべきです。それは、ヒューマンエラーの発生や管理できる規模が
スケールしないといった課題があるからです。
そのため、一般的には自動でCD/CIを行う一連の流れ(パイプライン)を
構築する方法が推奨されてます。
ファイルベースで運用する時点でGitなどで管理が必要なのは自明だと思
います。

#cnjp
「人間の関与を排除する」？
例えば、Kubernetesは、YAMLで記述したmanifestファイルを元に
kubectlコマンド用いてAPIに登録する事でインフラ構成を更新します。
つまり、クラスタ構成をコードで管理する。
• バージョン管理して、更新履歴を追跡可能にする
• クラスタへのオペレーションはコードの変更により実施する事で環境
を一意に保つ
manifest
(YAML)
kubectl

#cnjp
例えば、GitOpsとか
• Weaveworks社が提唱するk8sの継続的デリバリ手法の一つ
• Gitでバージョン管理されたManifestをSingle Source Of Truth（信頼
できる情報源）とする
cf. Kubernetes anti-patterns: Let’s do GitOps, not CIOps!

GitOps？
Kubernetesで作るコンテナベース CI★CDの夕べ / ochacafe#1 - Speaker Deck
とても分かりやすい
のでオススメです！

#cnjp
GitOps Tools
個人的には
Argo CD推し
Continuous Delivery | Argo
CI/CDツール
• Jenkins、CircleCI、Wercker、Concourse
manifestのテンプレートエンジン・manifest管理ツール
• Helm、Ksonnet、Kustomize
CD特化（差分検出と反映）
• ArgoCD、Weave Flux、Spinnaker

どうやって始めるか？

#cnjp
どこから始めるか？
Cloud Native Trail Map を
参考に段階的に始めていくと良いです。
一足飛びでk8sなんて無理です。
ダメ。絶対。
どんなものがあるかは以下を参照
cf. Cloud Native プロダクト 1000本ノック

#cnjp
アプリの実装はどうするか？
モノリシックなアーキテクチャのままDockerﬁleを書くと
巨大なDockerイメージが出来てしまい、デプロイやアプリの立ち上がり
に支障をきたします。
その為、
DockerのMulti-Stage Buildを使ってアプリの生成を分けたり、
ベースのイメージをより小さいものを選択する事でイメージの最小化に努
め、更にTwelve-Factor Appを参考にアプリ設計も作り変える必要があり
ます。

Twelve-Factor Appのおさらい
1. コードベース
バージョン管理されている1つのコードベースと複数のデプロイ
2. 依存関係
依存関係を明示的に宣言し分離する
3. 設定
設定を環境変数に格納する
4. バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱う
5. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
6. プロセス
アプリケーションを1つもしくは複数のステートレスなプロセスとし
て実行する
7. ポートバインディング
ポートバインディングを通してサービスを公開する
8. 並行性
プロセスモデルによってスケールアウトする
9. 廃棄容易性
高速な起動とグレースフルシャットダウンで堅牢性を最大化する
10. 開発/本番一致
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
11. ログ
ログをイベントストリームとして扱う
12. 管理プロセス
管理タスクを1回限りのプロセスとして実行する
The Twelve-Factor App （日本語訳）

#cnjp
Cloud Nativeな設計とは？
コンテナベースの開発向けデザインパターンがあります。
Designing Distributed Systems E-Book | Microsoft Azure
（無料でDL可能）
※日本語訳も書籍化されました！
　分散システムデザインパターン ―コンテナを使ったスケーラブ
ルなサービスの設計

#cnjp
Cloud Nativeな設計とは？
また、Brendan BurnsさんのGithubリポジトリ
brendandburns/designing-distributed-systems-labsに、
各パターンの一部をAzureでお試し出来る手引きまであります。

Designing Distributed Systems
• Single-Node Patterns
• The Sidecar Pattern
• Ambassadors
• Adapters
• Serving Patterns
• Replicated Load-Balanced Services
• Shared Services
• Scatter/Gather
• Functions and Event-Driven
Processing
• Ownership Election
• Batch Computational Patterns
• Work Queue Systems
• Event-Driven Batch Processing
• Coordinated Batch Processing
書籍で紹介されているパターンは以下

Single-Node Patterns

#cnjp
Sidecar Pattern
Sidecar Pattern は、共有Volumeを中継して、Sidecarが主コンテナを補
助する。
例えば、外部とSidecarが同期して
変更があれば、App側の更新をかける
利点：AppとSidecarで責務を分離
　　　AppはAppの責務だけに集中出来る
Config
Manager
Sidecar
Cloud
Config
Service
App
共有Volume
Config
File
1. 同期
3. シグナル
２. Update
４. Read

#cnjp
Ambassadors
主コンテナの代わりに通信を
肩代わりするコンテナを配置。
利点：
　Appは自分の責務に集中
　通信はAmbassadorに丸投げOK
MySQL
Service Broker
Ambassador
App
接続
localhost:3306
Service
Brocker
MySQL
Service Broker
Ambassador
App
接続
localhost:3306
MySQL
サービスへ
Service Brocker
MySQL
ｲﾝｽﾀﾝｽ
MySQL
Service Broker
Ambassador
App
接続
localhost:3306
接続

#cnjp
コンテナグループ
Adapters
Ambassadorとは違い、
Appに合わせたAdapterを用意し、
Adapterは共通の外部I/Fと橋渡しを行
う。
Adapterはモニタリングのみ行う。
モニタ対象となるAppは複数種類でも良
い。
利点：
• 外部I/Fを共通化
• Appは自分の責務に集中
外部
Consumer
Adapter
App
2
外部
I/F
AdapterApp
外部
I/F

Serving Patterns

#cnjp
Replicated Load-Balanced Services
LBを軸にして、
その先を縮退するよくあるやつ。
また、セッションを固定して
同じサーバにリクエストを固定させる
ことも可能。
レプリカ
LB
レプリカレプリカレプリカ・・・
Scaling Down
Scaling Up

#cnjp
Sharded Services
レプリカじゃなくて、
シャード、つまり、分割。
分割によって均等に分散。
偏ってきた場合は、
少ないリクエストのシャードはまとめ、
リクエストの多いシャードはレプリカを作成。
Shard A
LB
Shard B Shard C
Shard A
LB
Shard B Shard C
Shard A
LB
Shard A
Shard B
Shard C

#cnjp
Scatter/Gather
散布（Scatter）/収集（Gather）。
リクエストをRootNodeに投げ
RootNodeはLeafNodeに並列にリクエストを
送信（散布）。
LeafNodeはリクエストされた情報を
RootNodeに返し、RootNodeは返ってきた情
報を収集して、レスとして返す。
Leaf
Node
Root
Node
Leaf
Node
doc1,
doc2,
doc4
doc1,
doc3,
doc4
doc1,
doc3
犬と猫の
情報plz
猫plz 犬plz

#cnjp
Functions and Event-Driven Processing
≠ マイクロサービスアーキテクチャ
Functionは、FaaS（= Decorator Function）
と考えてOK（右図）
ただし、FaaS≠イベント駆動型
FaaS：
　リクエストに装飾しながら処理を加える
イベント駆動型：
　発火したイベントに合わせて、並列に処理が
発生する（例：新規ユーザのサインアップ）
Main Application Function
Decorator Function Arguments
Main Function
User Requests
Delegated requests

#cnjp
Ownership Election
オーナー選出のみを専門で行うコンテナを配置す
ることで、アプリは自分の責務だけを果たせば良
い。
いわゆるにPaxosやRAFTのような
分散合意アルゴリズムを使った実装。
（例：etcd、ZooKeeper、consul）
可用性が高まるので自動復旧やバージョンアップ
などが容易になる。
が、ライブラリを使うとかしない限り、
独自実装は非常に難しい...
Master #1
レプリカ
Master #2
レプリカ
Master #3
レプリカ
Master
Election
Protocol
Master #1
レプリカ
Master #2
レプリカ
Master #3
レプリカ
Master
Election
Protocol
Master #1
レプリカ
Master #2
レプリカ
Master #3
レプリカ
Master
Election
Protocol

Batch Computational Patterns

#cnjp
Work Queue Systems
並列に大量の処理を実行するパ
ターン。いわゆるバッチ。
キューを作成するマネージャが直
接キューを作成せずに、キュー出
し部分はAmbassador使って切り
分けると良い。
ワーカー側は2回以上実行したり悪
意のある操作をされないようにす
る為に、呼び出したら1回だけ実行
して役目を終える
Work Queue
Source
Container
(Ambassador)
Work Queue
Manager
Container
外部
Work Queue
Source
Workerコンテナグループ
Worker Container Implementation
K8s API
ConﬁgMap
Volume
Work Item
Data
ConﬁgMap

#cnjp
Event-Driven Batch Processing
前述のWork Queueではなく、
右図のように入力が派生したり、
Filterされるなどして出力が作成される、
いわゆるワークフローシステム。
ただ、それをそのまま実装すると複雑にな
りがちなので、Kafkaの様なPub/SubなAPI
またはサービスを利用する方が良い。
Copy Output to
Multiple Queues
Input
Copier
Stage #2a Stage #2b
Stage #3
Copyだけじゃなく
SplitterやShaderの
場合もある
途中でFilter
することも

#cnjp
Coordinated Batch Processing
分割した出力を一定のルールに基づいて、集
約するパターン。
例：Map/ReduceのReduce
Parallel Work
Distribution
Work
Queue
Result
Aggrecation
呼んだ？

#cnjp
Kubernetesで実装するには？
Kubernetes完全ガイドの以下の章が該当
第09章　リソース管理とオートスケーリング
第10章　ヘルスチェックとコンテナのライフサイクル
第11章　メンテナンスとノードの停止
第12章　高度で柔軟なスケジューリング
第13章　セキュリティ
もしくはKubernetes実践入門を丸っと。
本番環境のKubernetesマニフェストに最低限必要な 7 のこと
Kubernetes完全ガイドの方はダイジェスト版もあるよ

どっから情報集めるか問題

#cnjp
詳しい人雇うの大変ですよね
有償サポートと言う手も。
ただ、サポート範囲はどこを使うかで異なるので確認が必要です。
例えば
• Rancher Labs Support and Maintenance
• OpenShift Enterprise Support Policy - Red Hat Customer Portal
• VMware Enterprise PKS | FAQ | VMware Cloud
詳しい人雇ったと思えば安いし（月で割って考える）、
雇うのも大変なので検討の余地はあると思います。

#cnjp
コンテナ関連コミュニティで出会う
挙がっている資料だけでも知見の塊。
コミュニティに参加してアンテナを張ったりネットワークを広げる！

#cnjp
Edgeな情報が欲しい人には、、
k8sのSIGを集約したリポジトリがあります。
kubernetes/community: Kubernetes community content
議事録も公開されているのでEdgeな情報の宝庫です。

#cnjp
資料：KubernetesやDocker
● Cloud Nativeの定義
● Cloud Native Trail Map
● CNCF Cloud Native Interactive Landscape
● Cloud Native プロダクト 1000本ノック
● CloudNative Days Fukuokaで、クラウドネイティブについて考え直してみた
● インフラエンジニアとしてのわたしの研究開発とこれから注目のコンテナ技術
● 今話題のいろいろなコンテナランタイムを比較してみた
● コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう
● Docker Compose 徹底解説
● Dockerﬁleを改善するためのBest Practice 2019年版
● やさしくわかる「Kubernetes基礎」/やさしくわかる「Docker基礎」
● 【翻訳】Operator の紹介：運用の知見をソフトウェアに入れる
● OperatorHub.io | The registry for Kubernetes Operators
● 7 best practices for building containers | Google Cloud Blog
● Best practices for writing Dockerﬁles | Docker Documentation
● Istio / What is Istio?
● Istioサービスメッシュ入門

#cnjp
資料：設計関連
● The Twelve-Factor App （日本語訳）
● Kubernetes、コンテナ技術を活用した開発アジリティー向上にインフラアーキテクトはどう貢献したのか
● 「Kubernetesで運用する」その前に　Kubernetesを本番環境で利用する際のポイント
● Brendan Burns, David Oppenheimerらの論文：Design Patterns for Container-based Distributed Systems
○ その書籍：Designing Distributed Systems E-Book | Microsoft Azure
○ 実装のお試しリポジトリ：brendandburns/designing-distributed-systems-labs
○ その日本語訳版：分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計
● コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を
読んだ - kakakakakku blog
● Web Developer も知っておきたい Kubernetes における Sidecar Pattern と Ambassador Pattern - Quipper
Product Team Blog
● I will tell you the passion of Kubernetes - Speaker Deck
● コンテナ・デザイン・パターンの論文要約　 - Qiita

#cnjp
GitOps関連
• Weaveworks社のGitOpsに関する記事一覧
• GitOps — Operations by Pull Request – gavin.zhou – Medium
• Kubernetesで作るコンテナベースCI★CDの夕べ / ochacafe#1
• GitOpsでKubernetesのManifest管理
• GitOpsではじめるKubernetes CI/CD Pipeline
• jenkinsci/jenkins
• Continuous Integration and Delivery - CircleCI
• wercker/wercker
• concourse/concourse
• Helm Docs | Helm
• Home ⋅ ksonnet
• Kustomize - Kubernetes native conﬁguration management
• Argo CD
• Weave Flux
• Spinnaker

#cnjp
資料：関連コミュニティ
● Cloud Native JP
● Cloud Native Meetup Tokyo
● Cloud Native Developers JP
● Rancher JP
● Container Build Meetup
● Kubernetes Meetup Tokyo
● JAZUG (Japan Azure User Group)
● GCPUG
● JAWS-UG（AWS Users Group – Japan）
● Oracle Cloud Hangout Cafe
● Docker Meetup Tokyo
● Docker Meetup Kansai

#cnjp
資料：k8sやdocker（書籍）
みんな観点が違うので全部読もう（1→２の順で読んで３・４を並列で読むと良さそう）
1. Docker/Kubernetes 実践コンテナ開発入門（段階的に理解できるのでむっちゃオススメ）
2. Kubernetes完全ガイド（k8sの説明書）
3. みんなのDocker/Kubernetes（事例や本番運用する際にありがちな疑問点の解説）
4. Kubernetes実践入門プロダクションレディなコンテナ&アプリケーションの作り方（副題の通り）

Webアプリ開発向けゆるふわDocker使いがCloud Naive開発に必要そうなetc.

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Webアプリ開発向けゆるふわDocker使いがCloud Naive開発に必要そうなetc.

Ähnlich wie Webアプリ開発向けゆるふわDocker使いがCloud Naive開発に必要そうなetc. (20)

Mehr von YASUKAZU NAGATOMI

Mehr von YASUKAZU NAGATOMI (15)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)