---
title: クラウド時代のものづくり #seccamp #seccamp2021b3
tags:  #seccamp #cloud  
author: [NAKAYAMA Masahiro](https://convert.docswell.com/user/nekoruri)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/W4EZ8VV3J3.jpg?width=480
description: セキュリティ・キャンプ全国大会2021オンライン B3 分散アーキテクチャ時代におけるWebシステムの開発と運用  【本講義は以下の4つから構成されます】  イントロダクション https://www.docswell.com/s/nekoruri/5WGY1K-seccamp2021b3-introduction  クラウドシステムをセキュアに開発運用する勘所 https://speakerdeck.com/azara/sekiyuriteikiyanpuquan-guo-da-hui-2021-onrain-b3-fen-san-akitekutiyashi-dai-niokeruwebsisutemufalsekai-fa-toyun-yong-shi-qian-zi-liao-kuraudosisutemuwosekiyuanikai-fa-yun-yong-surukan-suo  クラウド時代のものづくり https://www.docswell.com/s/nekoruri/ZD3QDK-seccamp2021b3-cloudnative  ハッカソンについて https://www.docswell.com/s/nekoruri/KRY725-seccamp2021b3-hackathon
published: November 25, 21
canonical: https://convert.docswell.com/s/nekoruri/KLJ1G5-seccamp2021b3-cloudnative
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/W4EZ8VV3J3.jpg)

セキュリティ・キャンプ全国大会2021 オンライン
【B3】
分散アーキテクチャ時代における
Webシステムの開発と運用
クラウド時代のものづくり
講師 仲山 昌宏・齋藤 徳秀


# Page. 2

![Page Image](https://bcdn.docswell.com/page/KY76P55ZEV.jpg)

👀👀 この講義について
• Webシステムを分散アーキテクチャで作るのが当たり前の
時代
ここには、補足情報を書
いていきます。
• コンテナやサーバーレス（FaaS）によるソフトウェアの開発
• SaaSの活用
• 設計の基礎
• スケーラビリティ
• セキュリティ
• ハッカソン
#seccamp2021b3
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/5G75KYY9J4.jpg)

イントロダクションのおさらい
とにかくユーザーに
価値を早く届けたい
クラウドの活用
開発の
「アジリティ」を上げる
価値への注力
#seccamp2021b3
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/V9J2WGG5ER.jpg)

開発の主戦場の変化
すごいざっくり「データ
ベース」としていますが、
あくまで技術的な注力
先として捉えてください。
昔はデータベースが一番「かしこく」、
大変な処理はまとめてやっていた
ストアド
プロシージャ等
クライアント
アプリケーション
サーバーサイド
アプリケーション
データベース
#seccamp2021b3
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/5DEYLVV6JM.jpg)

開発の主戦場の変化
Ruby on Railsを代表
とするウェブアプリケー
ションの全盛期です。静
的なWeb 1.0から動的
なWeb 2.0へと発展し
てきました。
Webアプリ全盛期には、
サーバーサイドアプリケーションが
処理の中心
SQL
NoSQL
KVS
HTML
クライアント
アプリケーション
データベースがボトル
ネックとなってから、ア
プリケーションによる垂
直分割／水平分割など
の努力が試みられまし
た。
サーバーサイド
アプリケーション
データベース
#seccamp2021b3
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/2VJN4MG1E8.jpg)

開発の主戦場の変化
性能向上やUI/UXの重視により
クライアントアプリケーションが
開発の主戦場に変化
クラウド側は
データの最終責任を持つ
フロントエンド側のユー
スケースがAPI仕様に
おいて主導権を持つ
GraphQLの普及はひ
とつの技術的潮流です。
REST API
GraphQL
クライアント
アプリケーション
レンダリングがクライア
ントアプリケーション側
にシフトしたことで、
サーバーサイドは「ビジ
ネスロジック」をAPIと
して提供することに注力
できるようになりました。
その一方で、実際のユー
ザーに面するクライアン
トアプリケーションはよ
り高機能化・複雑化して
いきます。
サーバーサイド
アプリケーション
データベース
#seccamp2021b3
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GYE9QNWYE3.jpg)

サーバーサイドは最後の砦
究極的にはフロントエンドの
挙動は信頼できない
クラウド側は
データの最終責任を持つ
どこまでクライアントア
プリケーション側が高度
化したとしても、その挙
動が信頼できない以上、
最終的なデータの整合
性などを担保する責任
を持つのはサーバーサイ
ド、つまりクラウド側に
なります。
REST API
GraphQL
クライアント
アプリケーション
サーバーサイド
アプリケーション
データベース
#seccamp2021b3
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/5GE8GKNKED.jpg)

サーバーサイドは最後の砦
• セキュリティのCIA
• 整合性 Confidentiality
• 機密性 Integrity
• 可用性 Availability
機能そのものがAPIと
して単純化された一方
で、「最後の砦」として守
るべき視点は多岐にわ
たります。
• 情報を守るのはサーバーサイド
• 個人情報
• 組織の情報資産
#seccamp2021b3
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/MLELGZPP7R.jpg)

サーバーサイドをたのしもう
「サービス」の一番の肝だけを
楽しめるのがサーバーサイド
レンダリングは
フロントエンドに押しつけちゃえ
#seccamp2021b3
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/54JMQV42EW.jpg)

クラウド上で「なにか」する技術のトレンド
• 大きく分けて3つ
• コンテナ
• サーバーレス（FaaS）
• SaaS
• 最重要キーワード『クラウドネイティブ』
#seccamp2021b3
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/ZPJR82W5E9.jpg)

クラウドネイティブ
• CNCFによる定義
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブ
リッドクラウドなどの近代的でダイナミックな環境において、スケーラブルな
アプリケーションを構築および実行するための能力を組織にもたらします。
このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イ
ミュータブルインフラストラクチャ、および宣言型APIがあります。
これらの手法により、回復性（resilient）、管理力（manageable）、および
可観測性（observable）のある疎結合システムが実現します。 これらを堅牢
な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限
の労力で頻繁かつ予測どおりに行うことができます。
https://github.com/cncf/toc/blob/main/DEFINITION.md
#seccamp2021b3
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/NPEX8DPX7X.jpg)

CNCF Cloud Native Landscape
https://landscape.cncf.io/
#seccamp2021b3
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/63EKKXD9ED.jpg)

CNCF Serverless Landscape
https://landscape.cncf.io/serverless
#seccamp2021b3
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4L73Z5R975.jpg)

クラウドネイティブ
• CNCFによる定義
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブ
リッドクラウドなどの近代的でダイナミックな環境において、スケーラブルな
アプリケーションを構築および実行するための能力を組織にもたらします。
このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イ
ミュータブルインフラストラクチャ、および宣言型APIがあります。
これらの手法により、回復性（resilient）、管理力（manageable）、および
可観測性（observable）のある疎結合システムが実現します。 これらを堅牢
な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限
の労力で頻繁かつ予測どおりに行うことができます。
https://github.com/cncf/toc/blob/main/DEFINITION.md
#seccamp2021b3
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/V87DRDY8EG.jpg)

クラウドネイティブ
回復性
Resilient
管理力
Manageable
可観測性
Observable
クラウドネイティブ技術
コンテナ
サービスメッシュ
イミュータブルインフラストラクチャー
マイクロサービス
宣言型API
#seccamp2021b3
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4VJPWX6WE8.jpg)

回復性 Resilient
• 障害があっても復旧しサービスを継続できること
• 障害が起きることを受け入れる
• 自己回復性
• シンプルな例：再起動したサーバできちんとサービスが起動する
• 「イントロダクション」のおさらい
• 「信頼性」を制御するSRE
• アベイラビリティゾーンやリージョンを踏まえた可用性設計
#seccamp2021b3
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/L2EV8L39EQ.jpg)

回復性の評価軸
• サービルレベル
• SLO：目標値
• SLA：「これ以上落ちたらお金を返す」
• 利用しているクラウドサービスの
SLAの上に成り立つ
• 復旧
• RTO：目標復旧時間
• RPO：目標復旧時点
（いつのバックアップがあるか）
30日での許容ダウンタイム
99%
7.2時間
99.9%
43.2分
99.99%
4.32分
99.999%
よく言われるSLAは契
約上の視点のものであ
り、真に重要となるのは
設計上の目標値である
SLOです。
このSLOの他にも、
様々な指標で回復性を
評価できます。
25.92秒
• 実績値
• MTTR：平均復旧時間
• MTBF：平均故障間隔
#seccamp2021b3
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/Z57G5X347L.jpg)

リアクティブシステム
• 目的：即応性
• システム全体として、素早く、かつ安定した応答時間を保つ
• 要件１：耐障害性
• 障害が発生しても、それをコンポーネント内部に影響を隔離する
ことで、システム全体としての即応性を保つ。
良く紹介される「The
Twelve Factor
App」がアプリケーショ
ン開発におけるベストプ
ラクティスならば、この
リアクティブ宣言はシス
テム全体のアーキテク
チャを考えるときのベス
トプラクティスです。
• 要件２：弾力性
• 負荷の増減があっても、ボトルネックを排除し、割り当てるリソー
スを調整することで、即応性を保つ。
• 手段：メッセージ駆動
• 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
#seccamp2021b3
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/V4EQZ85REP.jpg)

リアクティブシステム
• メッセージ駆動（手段）
• システム間をキューで非同期に接続する
• 複数のワーカプロセスがキューから取ってきて処理
• 弾力性（要件2）
• メッセージが増えてきたらワーカプロセスを増やせばよい
• 横並びのワーカプロセスに相互依存はないので気軽にスケール
アウト・イン
• 耐障害性（要件1）
• コンポーネントで異常が起きたら自爆して、別のワーカが実行
• ずっとおかしいメッセージはDead letter queueに積み替え
て例外処理
• 即応性（目的）
• 様々な状況に強いシステムが構築できる
#seccamp2021b3
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/DKJ4329Q71.jpg)

リアクティブアーキテクチャ
• ざっくり言うと、
• 小さなプログラムを
• メッセージ駆動で
• 繋いでいく
• という非同期型アーキテクチャが良い、という考え方
• もっと超ざっくり言うと
• メッセージキューを挟んで繋げ
#seccamp2021b3
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/PLE11MKLEG.jpg)

リアクティブアーキテクチャ
• 「ペットから家畜へ」を踏まえたアーキテクチャ
メッセージ
ワーカー
ワーカー
ワーカー
ワーカー
ワーカー
ワーカー
#seccamp2021b3
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/8GEW83DQJ2.jpg)

リアクティブアーキテクチャ
• 「ペットから家畜へ」を踏まえたアーキテクチャ
メッセージ
他の誰かが実行
ワーカー
ワーカー
ワーカー
ワーカー
ワーカー
ワーカー
#seccamp2021b3
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/W47Z8VG3E3.jpg)

回復性をテストする
• カオスエンジニアリング
• 「試しにどっか壊してみる」
• カオスエンジニアリングの原則
https://principlesofchaos.org/ja/
1. 定常状態における振る舞いの仮説を立てる
2. 実世界の事象は多様である
3. 本番環境で検証を実行する
4. 継続的に実行する検証の自動化
5. 影響範囲を局所化する
#seccamp2021b3
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/KYJ6P5YZ7V.jpg)

管理力 manageable
• Infrastructure as Code
• プログラミング技術をサービスインフラに適用
• AWS CloudFormation
※Serverless Frameworkの内部でも使用
• Azure Resource Managerテンプレート
• Terraform
• CI/CD/GitOps
• Kubernetes(後ほど）
#seccamp2021b3
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/5GJ5KYG9E4.jpg)

可観測性 observable
• Metrics
• システムメトリクス
• アプリケーションメトリクス
• ビジネスメトリクス
• Trace
• プロファイリイング
• 分散トレーシング
• Log
• ログ転送・集積
• 構造化ログ
#seccamp2021b3
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/V9E2WGY57R.jpg)

アプリケーションの実行モデル
• コンテナ
• FaaS
• SaaS
#seccamp2021b3
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/5D7YLVG6EM.jpg)

コンテナ技術
• （この講義ではDockerにはじまったアプリケーション
コンテナの話だけをします）
単に「コンテナ」と言った
場合、仮想化技術などを
使った様々なカプセル
化が含まれるため、
「Dockerコンテナ」と呼
んだりします。
• アプリケーションを動かすために必要なリソースを
パッケージングしたもの、およびそれを使うツール群
Linuxでは、ルートディ
レクトリを引っ越す
chrootを祖とする実行
環境の隔離技術が
Dockerにまで発展し
ました。
•
•
•
•
必要なファイル一式
実行するためのコマンド
外部に公開するポート番号
etc.
#seccamp2021b3
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/2VEN4M8178.jpg)

Dockerコンテナの例
FROM node:12
WORKDIR /usr/src/app
COPY package*.json ./
実行に必要な
ファイル環境の構築
RUN npm install --only-production
Dockerfileではもっと
いろいろなことができ
ますが、ここでは割愛し
ます。
COPY . .
EXPOSE 8080
CMD [&quot;node&quot;, &quot;server.js&quot;]
単にファイルシステムを
イメージとして固めるだ
けでなく、Dockerfile
の一行ごとに差分を重
ねていくスタイルなどの
工夫により、単なるファ
イルパッケージより大幅
に効率的に動作します。
外部に公開するポート番号
実行するためのコマンド
#seccamp2021b3
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/GY79QNKY73.jpg)

コンテナの標準規格
• Open Container Initiative(OCI)で標準化
• OCI Runtime Specification （下位ランタイム）
https://github.com/opencontainers/runtime-spec
もともとDockerが独
自に開発していた仕様
がOCIとして標準化さ
れました。
• OCI Image Specification （イメージ）
https://github.com/opencontainers/image-spec
• OCI Distribution Specification （レジストリ）
https://github.com/opencontainers/distribution-spec
• Kubernetes
• Container Runtime Interface （CRI：上位ランタイム）
• Container Storage Interface （CSI）
• Container Network Interface （CNI）
#seccamp2021b3
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/5G78GKRK7D.jpg)

DockerとKubernetes
• Docker
• 単一のプロセスの実行環境を定義
• Docker社が開発しOSS化
• コア部分（containerd / runC）はCNCFに寄贈
Kubernetesの日本語
表記は諸説ありますが、
Wikipediaによると、
・クバネティス
・クバネテス
・クーべネティス
あたりとのこと。
• Kubernetes（k8s）
• 複数のDockerコンテナを連携させてシステムを作る
オーケストレーションツール、とそのエコシステム
• Googleが開発しOSS化され、CNCFに寄贈
• CRIを経由してcontainerdなどのランタイムでコンテナを実行
#seccamp2021b3
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/ML7LGZKPJR.jpg)

Kubernetesの機能
• サービスディスカバリーと負荷分散
• ストレージ オーケストレーション
• 自動化されたロールアウトとロールバック
• 自動ビンパッキング（リソース割り当ての調整）
• 自己修復
• 機密情報と構成管理
#seccamp2021b3
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/54EMQV227W.jpg)

NodeとPod
Node：
Podを動かすワーカーマシン
このNode、Podという
抽象化はとてもよく使
われる重要な概念です。
Pod：
コンテキストを共有する
コンテナのグループ
k8sにおける管理単位
https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/explore/explore-intro/
#seccamp2021b3
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/ZPER82M579.jpg)

Kubernetesマニフェスト
apiVersion: v1
kind: Pod
metadata:
メタデータ
name: nginx
spec:
containers:
- image: nginx:1.21
実行するコンテナ
name: nginx
※最もシンプルな例
実際はさらにServiceなど様々なリソースを定義していく必要があります。
#seccamp2021b3
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/NP7X8DVXJX.jpg)

Reconciliation Loop
延々と「あるべき状態」を実現するKubernetesの中心部
現在の状態
を確認
差分を
埋める
Kubernetesの巨大な
エコシステムは、平たく
言えばこのループにお
ける「状態」を様々な形
で実現したものです。
あるべき
状態と比較
#seccamp2021b3
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/637KKXQ97D.jpg)

CNCF Cloud Native Trail Map
コンテナのエコシステムは膨大
道しるべ（Trail Map）があります
https://github.com/cncf/trailmap
#seccamp2021b3
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/4LJ3Z5P9J5.jpg)

Function as a Service（FaaS）
• いわゆる「サーバーレス」技術の主役
• 今回のサンプルアプリもFaaS（AWS Lambda）を
使って動かしています
#seccamp2021b3
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/V8JDRDL87G.jpg)

「ペット」から「家畜」、その先へ……
• これまで：サーバ＝ペット🐕🐕🐈🐈
• 1台1台名前を付けて、手間を掛けて育てていく
• 少しおかしくなっても直して死ぬまで面倒を見る
• いま：サーバ＝家畜🐖🐖🐓🐓
• 集団の役割だけを見て、1台ずつの個別の面倒は見ない
• おかしくなったら殺す。慈悲は無い。
• これから：サーバーレス＝……？
#seccamp2021b3
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/4VEPWX2W78.jpg)

サーバーレス is 何
• 2015年あたりから広まりはじめた技術トレンド
• CNCFいわく……
サーバ管理を必要としないアプリケーションの
構築と実行の概念
• これだけでは「サーバーレス」というトレンドを
うまく表現できていない
#seccamp2021b3
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/L27V8LD97Q.jpg)

サーバーレス
＜運用面＞
フルマネージドサービスの活用
・FaaS
・Functional SaaS
＜開発面＞
イベントドリブンな
システムアーキテクチャ
・ナノサービス化
・疎結合化
「Serverless」の本質 ＝ 「サーバの抽象化」
#seccamp2021b3
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/Z5JG5XY4JL.jpg)

背景：サーバ・計算機の抽象化
• サーバ、もしくは「計算機」の抽象化
• サーバーレスという考え方の原点
• コンピュータサイエンスの進化の歴史そのもの
• 抽象化して再利用性を高める
• 分割して統治する
「自分でサーバーを管理
しない」というのがサー
バーレスの表層的な定
義ですが、ソフトウェア
実行環境としてのサー
バーを抽象化して「任意
に切り出して使える計算
機リソース」とみなす、と
いうのがそこに含まれ
た意味です。
でも、そもそも「クラウ
ド」ってそういうものを
目指したものでしたよね
（イントロダクション参
照）。要するに、理想のク
ラウドを目指して発展し
てきた技術に後付けで
名前を付けたものです。
#seccamp2021b3
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/V47QZ8MR7P.jpg)

背景：サーバ・計算機の抽象化
抽象化の度合い
設定
SQL
DSL（ドメイン固有言語）
プログラミング言語
コンテナ
上のレイヤーでは様々な
ものが抽象化されてい
るため、できることに制
約があります。
関数
コンテナ
OS
ベアメタル
開発
JSON
YAML
下のレイヤーでも頑張れ
ば何でもできます。
バイナリ
パッケージ
PCサーバー
自由度・制約の緩さ
#seccamp2021b3
41


# Page. 42

![Page Image](https://bcdn.docswell.com/page/DKE432VQJ1.jpg)

背景：サーバ・計算機の抽象化
抽象化の度合い
設定
DSL（ドメイン固有言語）
実現したい価値に注力
するためには、抽象化の
ちからをうまく活用して
いかなければいけませ
ん。
価値への
注力
プログラミング言語
コンテナ
OS
PCサーバー
自由度・制約の緩さ
#seccamp2021b3
42


# Page. 43

![Page Image](https://bcdn.docswell.com/page/PL711M3L7G.jpg)

サーバーレス
＜運用面＞
フルマネージドサービスの活用
・FaaS
・Functional SaaS
＜開発面＞
イベントドリブンな
システムアーキテクチャ
・ナノサービス化
・疎結合化
「Serverless」の本質 ＝ 「サーバの抽象化」
#seccamp2021b3
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/8G7W83PQE2.jpg)

運用面：
フルマネージドサービスの活用
• 抽象化の「向こう側」をクラウドにお任せ
• 自分でサーバの面倒を見ない⇒サーバーレス
• おさらい：「所有から利用へ」
• 「フル」マネージドサービス
• クラウドによってうまく管理され詳細は隠蔽され、
使った分だけスケールし、その分だけ課金されるサービス
• スケーラビリティや冗長性の確保などまで踏み込んで、
クラウド側に運用の全てを委託
#seccamp2021b3
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/W4JZ8VK373.jpg)

運用面：
フルマネージドサービスの活用
• Function as a Service
• 自分の書いたプログラムを動かす実行環境の抽象化
• 「関数」という単位でソフトウェアを管理
※関数の代わりにコンテナを使うものもある
• （Functional） SaaS
• クラウドが提供するなんらかの具体的な機能
• クラウド時代のミドルウェアやライブラリに相当
• プログラムというよりは、設定やDSLで動作を決める
#seccamp2021b3
45


# Page. 46

![Page Image](https://bcdn.docswell.com/page/KYE6P5QZJV.jpg)

Functional SaaS
• 個別の機能を提供
•
•
•
•
データベース
メッセージキュー（待ち行列）
メール送信
etc.
• Backend as a Service（BaaS）と呼ばれる
• 「機能の提供」に重きを置いて、ここではFunctional SaaSにて
統一
#seccamp2021b3
46


# Page. 47

![Page Image](https://bcdn.docswell.com/page/5GE5KYR974.jpg)

47
Function as a Service
• 自分の書いたプログラムを動かす実行環境の抽象化
• プログラムをクラウドに展開
• 決められたハンドラ関数が直接呼び出される
• 実際の動作マシン台数などはクラウドが管理
• 需要に応じて増減してくれる
• ステートレスなどの制約が課される
#seccamp2021b3
47


# Page. 48

![Page Image](https://bcdn.docswell.com/page/V972WGD5JR.jpg)

サーバーレス＋コンテナ
• Google Cloud Run
• 関数ではなくコンテナをデプロイ
• HTTPSやgRPCのリクエストを実際に処理した時間に課金
• アイドル状態では課金されない（ゼロスケール）
• AWS App Runner
• だいたいCloud Runと近い
• ゼロスケールせず最低1インスタンス分のメモリ確保が必要
（CPU時間への課金は処理時間分のみ）
#seccamp2021b3
48


# Page. 49

![Page Image](https://bcdn.docswell.com/page/5DJYLV267M.jpg)

サーバーレス
＜運用面＞
フルマネージドサービスの活用
・FaaS
・Functional SaaS
＜開発面＞
イベントドリブンな
システムアーキテクチャ
・ナノサービス化
・疎結合化
「Serverless」の本質 ＝ 「サーバの抽象化」
#seccamp2021b3
49


# Page. 50

![Page Image](https://bcdn.docswell.com/page/2V7N4MW1J8.jpg)

開発面：
イベントドリブンなシステムアーキテクチャ
• 非同期・疎結合な分散システムとして設計する
• リアクティブシステム
#seccamp2021b3
50


# Page. 51

![Page Image](https://bcdn.docswell.com/page/GYJ9QNXYJ3.jpg)

開発面：
イベントドリブンなシステムアーキテクチャ
• モノリシックなアプリケーション
• アプリケーションが外にあるものを呼び出す
• 例：データベースサーバ、外部システム
DB
Client
App
Server
App
外部
システム
#seccamp2021b3
51


# Page. 52

![Page Image](https://bcdn.docswell.com/page/5GJ8GK2KJD.jpg)

開発面：
イベントドリブンなシステムアーキテクチャ
• イベントドリブンなアプリケーション
• アプリケーションは外にあるものから呼び出される
認証システム
DBにファイル送信
非同期
処理
Client
App
外部
システム
非同期
処理
外部
システム
#seccamp2021b3
52


# Page. 53

![Page Image](https://bcdn.docswell.com/page/MLJLGZ2PER.jpg)

ピタゴラ装置的な例
• Amazon S3に動画ファイルをアップロード
• ⇒それをトリガにしてフォーマット変換を起動
• ⇒変換が終わったら動画一覧を再生成
• ⇒生成できたらCDNのキャッシュをクリア
• ⇒全部終わったら投稿者にメール
• 複雑な機能を、連鎖させて作りあげる
#seccamp2021b3
53


# Page. 54

![Page Image](https://bcdn.docswell.com/page/547MQV82JW.jpg)

開発面：
イベントドリブンなシステムアーキテクチャ
• クラウド時代の制御の反転（Inversion of Control）
• アプリケーション開発において、ライブラリを呼ぶのでは
無く、フレームワークから呼ばれるビジネスロジックに注力
• 例：Webアプリで GET / で呼ばれるハンドラメソッド
• 自分のプログラムは必要な時だけ呼ばれる存在へ
#seccamp2021b3
54


# Page. 55

![Page Image](https://bcdn.docswell.com/page/ZP7R8255J9.jpg)

55
権限管理の重要性
• これまで
• アプリケーションプロセスが処理の中で利用者を認証・認可
• 脆弱性はアプリケーションの実装方法によるもの
DB
Client
App
Server
App
ユーザを識別・認証
そのユーザに許される操作
をアプリケーション内で
判断（認可）し実行
外部
システム
#seccamp2021b3
55


# Page. 56

![Page Image](https://bcdn.docswell.com/page/NPJX8DKXEX.jpg)

56
権限管理の重要性
• これから
• 小さなアプリケーション⇒実装レベルの脆弱性は減少してほしい…
• 脆弱性は設計や呼出し方法によるもの
• ID管理に基づいたコンポーネント単位の認可がより重要に
#seccamp2021b3
56


# Page. 57

![Page Image](https://bcdn.docswell.com/page/63JKKX59JD.jpg)

57
ID管理とセキュリティ
• 認証（ID基盤）と認可（クラウドサービス）の分離
IDやパスワード、証明書など
を使ってユーザを「認証」
認証トークンを返す
認証システム
認証トークン内の
属性などを見て
操作を「認可」
認証トークン
非同期
処理
Client
App
外部
システム
非同期
処理
外部
システム
#seccamp2021b3
57


# Page. 58

![Page Image](https://bcdn.docswell.com/page/4LE3Z5K9E5.jpg)

サーバーレス
＜運用面＞
フルマネージドサービスの活用
・FaaS
・Functional SaaS
＜開発面＞
イベントドリブンな
システムアーキテクチャ
・ナノサービス化
・疎結合化
「Serverless」の本質 ＝ 「サーバの抽象化」
#seccamp2021b3
58


# Page. 59

![Page Image](https://bcdn.docswell.com/page/V8EDRD38JG.jpg)

Function as a Service
• 関数と呼ばれる小さなコードを動かすクラウドサービス
• 各社「サーバーレス」の中心人物
• AWS Lambda
• Azure Functions
• Google Cloud Functions
• アプリのプロセス起動・終了をクラウドに任せる
• ⇒ プロセス内にデータを保存することができない（Stateless）
• 「Stateless」という制約を受け入れることで、
「フルマネージド」というメリットが得られる
#seccamp2021b3
59


# Page. 60

![Page Image](https://bcdn.docswell.com/page/4V7PWX4WJ8.jpg)

Function as a Service
• 「フルマネージドなPaaS」の発展系
• 利用者にとって「サーバ」という管理単位をなくしたい
• その筋のプロである「クラウド事業者」が、それぞれの方法で適切
に管理してくれる＝フルマネージド
• 使う量（確保量）から使った量（使用量）へのシフト
• 事前に「台数」の確保が不要
• 短時間で起動し、必要なだけ拡張
• 実際の実行時間（たとえば100ms単位）で課金される
#seccamp2021b3
60


# Page. 61

![Page Image](https://bcdn.docswell.com/page/L2JV8LX9JQ.jpg)

61
Function as a Service
• AWS Lambda
exports.handler = async event =&gt; {
return {
statusCode: 200,
body: ”Hello from Lambda!”,
}
};
#seccamp2021b3
61


# Page. 62

![Page Image](https://bcdn.docswell.com/page/Z5EG5XV4EL.jpg)

62
Function as a Service
• AWS Lambda
入力は引数eventとして渡ってくる。
eventの中身は、例えばHTTPリクエスト
の場合、Amazon API Gatewayという
別サービス側の設定に依存
exports.handler = async event =&gt; {
return {
statusCode: 200,
body: ”Hello from Lambda!”,
}
};
#seccamp2021b3
62


# Page. 63

![Page Image](https://bcdn.docswell.com/page/V4JQZ86RJP.jpg)

63
Function as a Service
• Azure Functions
module.exports = async function (context, req) {
context.log(&#039;JavaScript HTTP trigger function processed a request.’);
if (req.query.name || (req.body &amp;&amp; req.body.name)) {
context.res = {
// status: 200, /* Defaults to 200 */
body: &quot;Hello &quot; + (req.query.name || req.body.name)
};
} else {
context.res = {
status: 400,
body: &quot;Please pass a name on the query string or in the request body&quot;
};
}
};
#seccamp2021b3
63


# Page. 64

![Page Image](https://bcdn.docswell.com/page/DK74324QE1.jpg)

64
Function as a Service
• Azure Functions
HTTPリクエストであればreqに中身が入ってくる
module.exports = async function (context, req) {
context.log(&#039;JavaScript HTTP trigger function processed a request.’);
ログはif (req.query.name || (req.body &amp;&amp; req.body.name)) {
context.res = {
context.log
// status: 200, /* Defaults to 200 */
body: &quot;Hello &quot; + (req.query.name || req.body.name)
};
} else {
context.res = {
status: 400,
body: &quot;Please pass a name on the query string or in the request body&quot;
};
}
};
#seccamp2021b3
64


# Page. 65

![Page Image](https://bcdn.docswell.com/page/PLJ11M4LJG.jpg)

65
Function as a Service
• このように少しずつ関数のインターフェースが異なる
• けど、受け渡す内容はだいたい一緒
• 自前で抽象化レイヤーを挟んでおくのがよい
• 対応言語の壁もあるものの、標準化されて欲しい
• FaaSに関してベンダーロックインを怖がる必要はあまりない
#seccamp2021b3
65


# Page. 66

![Page Image](https://bcdn.docswell.com/page/8GJW83XQ72.jpg)

66
Function as a Service
• Azure Functionsの入出力バインディング
• 関数を実行する「トリガー」と別に入出力を行う
• 例:
• トリガーの値を元にDBクエリ
• 関数の返り値を別のキューやDBに保存
• 単純な処理をより単純に実装可能
• 副作用の無い素直な「関数」として書ける
• そもそも保存処理やエラーハンドリングを自分で書かなくて良い
#seccamp2021b3
66


# Page. 67

![Page Image](https://bcdn.docswell.com/page/W4EZ8V63J3.jpg)

SaaS
• 様々な個別の機能を提供するクラウドサービス
•
•
•
•
•
•
•
メール送受信
データベース（PostgreSQL、MySQL、DynamoDB、etc.）
オンメモリキャッシュ（Redis、memcached）
メッセージキュー
ID管理、認証基盤
監視、システムログ管理
etc.
• クラウドによってきちんと設計されている
• スケーラビリティやセキュリティ
• クラウド毎の差異はここにある
• 「ベンダーロックイン」と捉えるか、
「自分に向いたものを選択できる」と捉えるか
#seccamp2021b3
67


# Page. 68

![Page Image](https://bcdn.docswell.com/page/KY76P52ZEV.jpg)

AWSのサービスカタログ
2021-08-12時点
#seccamp2021b3
68


# Page. 69

![Page Image](https://bcdn.docswell.com/page/5G75KY29J4.jpg)

Azureのサービスカタログ
2021-08-12時点
#seccamp2021b3
69


# Page. 70

![Page Image](https://bcdn.docswell.com/page/V9J2WG45ER.jpg)

NoSQLデータベースの例
• AWS DynamoDBやAzure CosmosDB
• 共通
• 性能を数値で指定して確保
• 「パーティションキー」で複数の物理サーバに分散される
• 更新された時にFaaSを起動（Streams / Change Feed）
• 違い
• DynamoDB：KVS的インターフェースのみ、ミニマム課金額小
• CosmosDB：SQLやグラフDB等複数のデータモデルに対応
#seccamp2021b3
70


# Page. 71

![Page Image](https://bcdn.docswell.com/page/5DEYLVM6JM.jpg)

NoSQLのデータ分散
• データ保存先を分散したい
• パーティションキーで振り分け
• 実際はハッシュ値など
Key:
1-10
Key:
41-50
Key:
11-20
Key:
31-40
Key:
21-30
#seccamp2021b3
71


# Page. 72

![Page Image](https://bcdn.docswell.com/page/2VJN4M31E8.jpg)

NoSQLのデータ分散
• データ保存先を分散したい
Key:
1-10
• パーティションキーで振り分け
• 実際はハッシュ値など
• ホットスポット厳禁
Key:
41-50
Key:
11-20
負荷の
偏り
Key:
Key:
Key:
Key:
Key:
11
Key:
15
Key:
15
15
15
15
15
Key:
31-40
Key:
21-30
#seccamp2021b3
72


# Page. 73

![Page Image](https://bcdn.docswell.com/page/GYE9QN9YE3.jpg)

様々な「キュー」
• たとえばキュー
• AWSで3種類
• SQS、SNS、Kinesis Data Streams
• Azureで4種類
• Storageキュー、Service Bus、Event Hubs、Event Grid
• 特性が異なる
• メッセージキュー or Pub/Sub
• at-least-once or at-most-once or exactly-once
• 一件ずつ or 一度にまとめて取得
#seccamp2021b3
73


# Page. 74

![Page Image](https://bcdn.docswell.com/page/5GE8GK9KED.jpg)

メッセージキューとPub/Sub
受信側
Consumer
＜メッセージキュー＞
4
送信側
6 5
4 3 2
1
5
1
2
Producer
6
受信側
Consumer
3
受信側のどれかに届く
受信側
Consumer
受信側
＜Pub/Sub＞
送信側
Subscriber
6 5
4 3 2
1
6 5 432 1
受信側
Subscriber
Publisher
受信側全員にすべてが届く
受信側
Subscriber
#seccamp2021b3
74


# Page. 75

![Page Image](https://bcdn.docswell.com/page/MLELGZWP7R.jpg)

Functional SaaS
• キューも中身はデータベース
• スケーラビリティの確保も同じ
Kinesis Data Streams
Shard
パーティションキーで
別のShardに振り分け
Shard
Shard
Shard
#seccamp2021b3
75


# Page. 76

![Page Image](https://bcdn.docswell.com/page/54JMQV92EW.jpg)

Functional SaaS
• FaaSとの連携も様々
• 2種類の連携方法（ポーリングとプッシュ）
定期的にポーリング
FaaS
※関数がDBへのアクセス権限を持つ
関数を呼び出し
FaaS
※DBが関数の実行許可を持つ
#seccamp2021b3
76


# Page. 77

![Page Image](https://bcdn.docswell.com/page/ZPJR82G5E9.jpg)

mobile BaaS
• たとえばmBaaS
• Google FirebaseやAWS Cognito
• モバイルアプリ向けの機能を一体化して提供
• 他のFacebookやTwitterと連携できるID基盤とか
• リアルタイムでスマホ側とクラウド側を同期するDBとか
• DB更新時にFaaS呼び出したりだとか
• ロックインリスクと開発効率どっちを取るのか？
開発効率の向上がある
段階を超えると、一から
再開発するコストがロッ
クインのリスクを下回っ
てしまうようになります。
このあたりは、例えばコ
ンテナなど移植性のあ
る技術を組み合わせる
ことで、うまくバランス
を取っていく設計力が
必要になるポイントです。
• 当然ながらケースバイケース
• でもほとんどは開発効率では……？
#seccamp2021b3
77


# Page. 78

![Page Image](https://bcdn.docswell.com/page/NPEX8DXX7X.jpg)

アプリケーションの実行モデル
• コンテナ
• アプリケーションの実行環境パッケージ
• 公開したポート番号で待ち受け
• 最近はKubernetesでオーケストレーション
• FaaS
• 関数としてプログラムを記述
• リクエストが来ると関数が呼ばれる
• SaaS
• クラウドが具体的な機能を提供
• これまでミドルウェアが担っていたような部品
#seccamp2021b3
78


# Page. 79

![Page Image](https://bcdn.docswell.com/page/63EKKXW9ED.jpg)

おさらい：クラウドネイティブな設計とは
様々な手法でこの3つがある疎結合システムを実現
回復性
Resilient
管理力
Manageable
可観測性
Observable
そのために様々な技術を組み合わせていく
#seccamp2021b3
79


# Page. 80

![Page Image](https://bcdn.docswell.com/page/4L73Z51975.jpg)

クラウドネイティブ技術とは
• CNCFにプロジェクトがある技術だけが
クラウドネイティブを実現するものではない
• CNCFは割とコンテナ技術に寄りがち
• サーバーレスはクラウドベンダー依存
どちらも実現したいこと
はクラウドネイティブな
システムであるとうのを
踏まえた上で、どのよう
な技術スタックを選択す
るかは、一種の「宗教」や
「投資」の側面があり、コ
ンテナにもサーバーレス
にも向いている場合、向
かない場合があります。
CNCFの定義によるクラウドネイティブ技術群
コンテナ
サービスメッシュ
イミュータブルインフラストラクチャー
マイクロサービス
宣言型API
#seccamp2021b3
80


# Page. 81

![Page Image](https://bcdn.docswell.com/page/V87DRDX8EG.jpg)

巨人の肩に乗ろう
• AWSアーキテクチャセンター
https://aws.amazon.com/jp/architecture/
• AWS Well-Architected フレームワーク
https://aws.amazon.com/jp/architecture/well-architected/
• Azureアーキテクチャセンター
https://docs.microsoft.com/ja-jp/azure/architecture/
• Microsoft Azure Well-Architected Framework
https://docs.microsoft.com/ja-jp/azure/architecture/framework/
• Google Cloud アーキテクチャ センター
https://cloud.google.com/architecture?hl=ja
• Google Cloudアーキテクチャフレームワーク
https://cloud.google.com/architecture/framework?hl=ja
#seccamp2021b3
81


# Page. 82

![Page Image](https://bcdn.docswell.com/page/4VJPWXPWE8.jpg)

アーキテクチャパターン（例）
https://docs.microsoft.com/ja-jp/azure/architecture/patterns/
#seccamp2021b3
82


# Page. 83

![Page Image](https://bcdn.docswell.com/page/L2EV8L29EQ.jpg)

技術の目利き力を養う
• サービスを提供するということ
• ソフトウェアを生み出しただけで技術的資産であり技術的負債
• 継続して運用されていかなければ価値がない
• どのような技術を選定するか
• 開発における品質・効率
• ライフサイクル
• 持続性のある開発体制
• 常にバランス感が問われる
• 新しすぎても課題が多い
• 枯れすぎても課題が多い
#seccamp2021b3
83


# Page. 84

![Page Image](https://bcdn.docswell.com/page/Z57G5XR47L.jpg)

ソフトウェアの力で
世界を変えていこう
#seccamp2021b3
84


