クラウド時代のものづくり #seccamp #seccamp2021b3

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

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

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

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

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

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

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

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

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

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

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

• https://github.com/cncf/toc/blob/main/DEFINITION.md

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

• https://landscape.cncf.io/

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

• https://landscape.cncf.io/serverless

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

• https://github.com/cncf/toc/blob/main/DEFINITION.md

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

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

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

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

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

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

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

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

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

• https://principlesofchaos.org/ja/

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

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

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

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

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

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

• https://github.com/opencontainers/runtime-spec
• https://github.com/opencontainers/image-spec
• https://github.com/opencontainers/distribution-spec

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

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

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

• https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/explore/explore-intro/

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

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

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

• https://github.com/cncf/trailmap

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

61

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

#seccamp2021b3

61

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• https://aws.amazon.com/jp/architecture/
• https://aws.amazon.com/jp/architecture/well-architected/
• https://docs.microsoft.com/ja-jp/azure/architecture/
• https://docs.microsoft.com/ja-jp/azure/architecture/framework/
• https://cloud.google.com/architecture?hl=ja
• https://cloud.google.com/architecture/framework?hl=ja

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

• https://docs.microsoft.com/ja-jp/azure/architecture/patterns/

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

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