クラウド時代のものづくり(分散アーキテクチャ時代におけるWebシステムの開発と運用) #seccamp

453 Views

September 30, 21

スライド概要

セキュリティ・キャンプ全国大会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

profile-image

NAKAYAMA Masahiro

@nekoruri

スライド一覧

秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。 0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、 SNSとCGMの力で世界を幸福にするのがライフワーク。 市民、幸福は義務です。 あなたは幸福ですか?

シェア

埋め込む »CMSなどでJSが使えない場合

各ページのテキスト
1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

回復性の評価軸 • サービルレベル • 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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

コンテナの標準規格 • 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

30.

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

31.

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

32.

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

33.

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

34.

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

35.

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

36.

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

37.

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

38.

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

39.

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

40.

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

41.

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

42.

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

43.

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

44.

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

45.

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

46.

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

47.

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

48.

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

49.

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

50.

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

51.

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

52.

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

53.

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

54.

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

55.

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

56.

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

57.

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

58.

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

59.

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

60.

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

61.
[beta]
61

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

#seccamp2021b3

61

62.
[beta]
62

Function as a Service
• AWS Lambda

入力は引数eventとして渡ってくる。
eventの中身は、例えばHTTPリクエスト
の場合、Amazon API Gatewayという
別サービス側の設定に依存

exports.handler = async event => {
return {
statusCode: 200,
body: ”Hello from Lambda!”,
}
};

#seccamp2021b3

62

63.
[beta]
63

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

63

64.
[beta]
64

Function as a Service
• Azure Functions

HTTPリクエストであればreqに中身が入ってくる

module.exports = async function (context, req) {
context.log('JavaScript HTTP trigger function processed a request.’);

ログはif (req.query.name || (req.body && req.body.name)) {
context.res = {
context.log

// status: 200, /* Defaults to 200 */
body: "Hello " + (req.query.name || req.body.name)

};
} else {
context.res = {
status: 400,
body: "Please pass a name on the query string or in the request body"
};
}
};
#seccamp2021b3

64

65.

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

66.

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

67.

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

68.

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

69.

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

70.

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

71.

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

72.

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

73.

様々な「キュー」 • たとえばキュー • 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

74.

メッセージキューと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

75.

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

76.

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

77.

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

78.

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

79.

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

80.

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

81.

巨人の肩に乗ろう • 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

82.

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

83.

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

84.

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