クラウド時代のものづくり(分散アーキテクチャ時代におけるWebシステムの開発と運用) #seccamp
•
0 gefällt mir•440 views
セキュリティ・キャンプ全国大会2021 オンライン B3 分散アーキテクチャ時代におけるWebシステムの開発と運用
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie クラウド時代のものづくり(分散アーキテクチャ時代におけるWebシステムの開発と運用) #seccamp
Ähnlich wie クラウド時代のものづくり(分散アーキテクチャ時代におけるWebシステムの開発と運用) #seccamp (20)
Mehr von Masahiro NAKAYAMA
Mehr von Masahiro NAKAYAMA (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
クラウド時代のものづくり(分散アーキテクチャ時代におけるWebシステムの開発と運用) #seccamp
- 1. 【B3】 分散アーキテクチャ時代における Webシステムの開発と運用 講師 仲山 昌宏・齋藤 徳秀 セキュリティ・キャンプ全国大会2021 オンライン クラウド時代のものづくり
- 2. 2 #seccamp2021b3 👀👀 この講義について • Webシステムを分散アーキテクチャで作るのが当たり前の 時代 • コンテナやサーバーレス（FaaS）によるソフトウェアの開発 • SaaSの活用 • 設計の基礎 • スケーラビリティ • セキュリティ • ハッカソン ここには、補足情報を書 いていきます。
- 5. 5 #seccamp2021b3 開発の主戦場の変化 Ruby on Railsを代表 とするウェブアプリケー ションの全盛期です。静 的なWeb 1.0から動的 なWeb 2.0へと発展し てきました。 データベースがボトル ネックとなってから、ア プリケーションによる垂 直分割／水平分割など の努力が試みられまし た。 サーバーサイド アプリケーション データベース クライアント アプリケーション Webアプリ全盛期には、 サーバーサイドアプリケーションが 処理の中心 SQL NoSQL KVS HTML
- 8. 8 #seccamp2021b3 サーバーサイドは最後の砦 • セキュリティのCIA • 整合性 Confidentiality • 機密性 Integrity • 可用性 Availability • 情報を守るのはサーバーサイド • 個人情報 • 組織の情報資産 機能そのものがAPIと して単純化された一方 で、「最後の砦」として守 るべき視点は多岐にわ たります。
- 10. 10 #seccamp2021b3 クラウド上で「なにか」する技術のトレンド • 大きく分けて3つ • コンテナ • サーバーレス（FaaS） • SaaS • 最重要キーワード『クラウドネイティブ』
- 12. 12 #seccamp2021b3 CNCF Cloud Native Landscape https://landscape.cncf.io/
- 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 リアクティブアーキテクチャ • ざっくり言うと、 • 小さなプログラムを • メッセージ駆動で • 繋いでいく • という非同期型アーキテクチャが良い、という考え方 • もっと超ざっくり言うと • メッセージキューを挟んで繋げ
- 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 • ログ転送・集積 • 構造化ログ
- 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の機能 • サービスディスカバリーと負荷分散 • ストレージ オーケストレーション • 自動化されたロールアウトとロールバック • 自動ビンパッキング（リソース割り当ての調整） • 自己修復 • 機密情報と構成管理
- 33. 33 #seccamp2021b3 Kubernetesマニフェスト apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:1.21 name: nginx メタデータ 実行するコンテナ ※最もシンプルな例 実際はさらにServiceなど様々なリソースを定義していく必要があります。
- 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 背景：サーバ・計算機の抽象化 • サーバ、もしくは「計算機」の抽象化 • サーバーレスという考え方の原点 • コンピュータサイエンスの進化の歴史そのもの • 抽象化して再利用性を高める • 分割して統治する 「自分でサーバーを管理 しない」というのがサー バーレスの表層的な定 義ですが、ソフトウェア 実行環境としてのサー バーを抽象化して「任意 に切り出して使える計算 機リソース」とみなす、と いうのがそこに含まれ た意味です。 でも、そもそも「クラウ ド」ってそういうものを 目指したものでしたよね （イントロダクション参 照）。要するに、理想のク ラウドを目指して発展し てきた技術に後付けで 名前を付けたものです。
- 43. 43 #seccamp2021b3 サーバーレス 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 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時間への課金は処理時間分のみ）
- 49. 49 #seccamp2021b3 サーバーレス 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 51. 51 #seccamp2021b3 開発面： イベントドリブンなシステムアーキテクチャ • モノリシックなアプリケーション • アプリケーションが外にあるものを呼び出す • 例：データベースサーバ、外部システム Client App Server 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
- 58. 58 #seccamp2021b3 サーバーレス 「Serverless」の本質 ＝ 「サーバの抽象化」 ＜運用面＞ フルマネージドサービスの活用 ・FaaS ・Functional SaaS ＜開発面＞ イベントドリブンな システムアーキテクチャ ・ナノサービス化 ・疎結合化
- 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. • クラウドによってきちんと設計されている • スケーラビリティやセキュリティ • クラウド毎の差異はここにある • 「ベンダーロックイン」と捉えるか、 「自分に向いたものを選択できる」と捉えるか
- 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 • クラウドが具体的な機能を提供 • これまでミドルウェアが担っていたような部品
- 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
- 83. 83 #seccamp2021b3 技術の目利き力を養う • サービスを提供するということ • ソフトウェアを生み出しただけで技術的資産であり技術的負債 • 継続して運用されていかなければ価値がない • どのような技術を選定するか • 開発における品質・効率 • ライフサイクル • 持続性のある開発体制 • 常にバランス感が問われる • 新しすぎても課題が多い • 枯れすぎても課題が多い