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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29. 29 #seccamp2021b3 コンテナの標準規格 • Open Container Initiative(OCI)で標準化 • OCI Runtime Specification （下位ランタイム） https://github.com/opencontainers/runtime-spec • 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）もともとDockerが独自に開発していた仕様がOCIとして標準化されました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

63. 63 #seccamp2021b3 Function as a Service • Azure Functions 63 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" }; } };

64. 64 #seccamp2021b3 Function as a Service • Azure Functions 64 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" }; } }; HTTPリクエストであればreqに中身が入ってくるログは context.log

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

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

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

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

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

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

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

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

73. 73 #seccamp2021b3 様々な「キュー」 • たとえばキュー • 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 一度にまとめて取得

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

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

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

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

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

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

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

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

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

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

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

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

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

Recommandé

Contenu connexe

Tendances

Tendances(20)

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

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

Plus de Masahiro NAKAYAMA

Plus de Masahiro NAKAYAMA(20)

Dernier

Dernier(8)

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