"クラウドアプリケーション 10の設計原則" をもっと楽しむ

by Toru Makabe

Slide 1

Slide 1 text

“クラウドアプリケーション 10の設計原則”をもっと楽しむ Toru Makabe Senior Cloud Solution Architect Microsoft

Slide 2

Slide 2 text

About me 著者です

Slide 3

Slide 3 text

お伝えしたいこと • これから読む人へ • 本書を読む補助線となる情報 • もう読んだ人へ • 内容を記憶に定着させるための刺激ネタ • 「そういう背景や意図があったのか」ネタ • 輪読会や感想戦で使えるネタ • 網羅的ではありません • ポイントや思い入れのあるところだけ

Slide 4

Slide 4 text

Agenda  本書を書いた背景  原則いじり  概要  重要ポイント  裏話  読者の反応  Q&A

Slide 5

Slide 5 text

本書を書いた動機

Slide 6

Slide 6 text

本書の「つかみ」「まずベストプラクティスを教えてください」筆者の嫌いな言葉です。 [まえがき]

Slide 7

Slide 7 text

ベストプラクティスそのものは素晴らしい  ベンダやユーザの思想、経験にもとづく、貴重な知識  ベンダの公開するベストプラクティス  製品の設計思想に沿った使い方  ユーザからのフィードバックを整理して還元  ユーザの公開するベストプラクティス  複数の選択肢があった中から、実践しうまくいった経験を紹介

Slide 8

Slide 8 text

ベストプラクティスの「負の側面」  特定の環境、条件下での「ベスト」である  いまのあなたとチームにとってベストかは、わからない  複数のベストプラクティスが衝突、矛盾することもある（例: A製品とB製品のベストプラクティスが矛盾）  変化する  製品はフィードバックを受けて変化する  使い手の環境も変化する  合わせて、ベストプラクティスも変化する  そのベストプラクティスが半年後にベストかは、わからない  鵜呑みにしてしまう  自分の頭で考えなくなってしまう

Slide 9

Slide 9 text

ベストプラクティスを鵜呑みにした結果  ベストプラクティスが現在の社内ルールに反していることが分かったが、その価値や妥当性を主張できない  複数のベストプラクティスを参考にしたが一貫性がなく、どれを優先すればよいか判断できない  トラブル対応ができない [まえがき]

Slide 10

Slide 10 text

とはいえ、すべてを吟味してもいられないベストプラクティスA ベストプラクティスB ベストプラクティスC ベストプラクティスD 言わんとすることを理解し他のベストプラクティスとの一貫性を確認し内容に変化がないか定期的に確認し自分たちの環境や条件に合うか議論し

Slide 11

Slide 11 text

原則を理解しよう!! ベストプラクティスA ベストプラクティスB ベストプラクティスC ベストプラクティスD 原則（+背景）

Slide 12

Slide 12 text

いいドキュメントがある、しかし  全体的に端折り気味  読み手の知識に期待している  翻訳がやや惜しい  もっと具体例がほしい  エピソードやサンプルコードなど  クラウド中立にできそう  Azureに限らない話が多い Azure アプリケーションの設計原則 - Azure Architecture Center | Microsoft Learn

Slide 13

Slide 13 text

そこで「解説本」とした  転載や翻訳、翻案ではなく、解説本という建付け  筆者の経験をもとに解説、要約、加筆  Azureではないパブリッククラウドでも参考になるよう意識  具体例（クラウドの内部構造やサンプルコードなど）はAzure中心

Slide 14

Slide 14 text

原則いじり

Slide 15

Slide 15 text

10の原則すべての要素を冗長化する自己復旧できるようにする調整を最小限に抑えるスケールアウトできるようにする分割して上限を回避する運用を考慮するマネージドサービスを活用する用途に適したデータストアを選ぶ進化を見込んで設計するビジネスニーズを忘れない

Slide 16

Slide 16 text

1. すべての要素を冗長化する

Slide 17

Slide 17 text

概要 • クラウドの内部構造（障害を切り口に） • 冗長化がなぜ重要か • サービスレベルの考え方と実際 • 推奨事項 • ビジネス要件を考慮する • RTOとRPOを意識する • 正常性エンドポイントを実装する • など

Slide 18

Slide 18 text

意図的にこの章を先頭にした Azure アプリケーションの設計原則 - Azure Architecture Center | Microsoft Learn オリジナルでは2番目  本書を読み進めるにあたり、クラウドの内部構造を早めに解説しておきたかったため  障害に備えた冗長化、というピンときやすいテーマで解説するのが良いと考えた  いっぽうでこの章のボリュームが多めになってしまい、「いきなり疲れる」というフィードバックもあった

Slide 19

Slide 19 text

この章の重要ポイントアプリケーションに冗長性を組み込むと、コストと複雑さが増します。たとえば、複数リージョンへのデプロイは、単一リージョンへのデプロイよりもコストがかかり、管理も複雑です。手動でフェイルオーバーとフェイルバックを行うのであれば、判断する体制とプロセス、切り替え手順の確立はもちろん、訓練も必要です。本章は、すべての要素を冗長化「する」というタイトルです。しかし、冗長化で増えるコストと複雑さが妥当であるかは、ビジネス要件で判断します。すべての要素を冗長化「できる」能力を身に着けつつ、ビジネス要件に合わせて要否を決めてください。 [推奨事項 - ビジネス要件を考慮する]

Slide 20

Slide 20 text

かなり削った「トレードオフ」という言葉本書の原則のいくつかに、トレードオフの関係がみられます。たとえば本章の冗長化と、10章のビジネス要件で触れるコストです。実は本書は原稿段階で「”要はトレードオフおじさん”の本ね」と言われかねないほど、「トレードオフ」という単語が使われていました。くどいので、意図的に削っています。ただしアーキテクトや設計者に求められる重要な仕事のひとつは、トレードオフのどちらを優先するかを判断し、利害関係者に説明することです。これを意識して読むとさらに味わい深いでしょう。

Slide 21

Slide 21 text

あわせて読みたい  冗長化によって信頼性を上げることで、他の特性に影響する  コスト、運用の複雑性、性能、セキュリティなど  当然、逆パターンもある（コストを優先するなら、冗長化しないなど）信頼性のトレードオフ - Microsoft Azure Well-Architected Framework | Microsoft Learn

Slide 22

Slide 22 text

トレードオフの例  GitHubはシークレットをAzure Key Vaultに入れてローテーションしている  ローテーションのしくみにバグがあり、 Codespacesの作成に影響した  セキュリティ視点では有効な手法だが実装は複雑になりがちで、障害の原因になりやすい  セキュリティを重視し、信頼性も下げたくないので、さらなる投資を行う（プレイブックやドキュメントの整備含む設計、実装、運用の改善） GitHub Availability Report: December 2023 - The GitHub Blog

Slide 23

Slide 23 text

読者の反応「コスト削減ってSREの仕事だと思いますか?」 SREチームを組織した背景にもよるので（以下略。ただし、コスト削減のトレードオフとして信頼性が低下しうるのであれば、信頼性に関する専門家として、その緩和や解決で活躍の場はあると考えます。

Slide 24

Slide 24 text

（余談）本書の執筆、コラボレーション環境 • 執筆 • VS Code + Dev Container + GitHub • フォーマットはMarkdown & Mermaid • 環境をコンテナ化し、コードをGitHubに置き、どこでも執筆できるように • textlintとVS Code textlint拡張で、執筆しながらチェック • それでも揺れやtypoを量産（辞書やルールに入れにくい、新し目のクラウドやAzure関連用語) • 次はLLMの活用に挑戦したい（typoのチェック、単調さの改善など） • 技術者レビュー • GitHub Issue/Pull Request • 編集者、デザイナーとのコラボレーション • 基本はPDF • まずMarkdownをPDF化してスタート • 図はMermaidを手作業でパワーポイント化（後述） • PDFの共有、コメント入力ができるクラウドサービスでコラボレーション

Slide 25

Slide 25 text

（余談）本書の図はMermaidで書きました、が flowchart LR b[利用者のブラウザ] --> f[フロントエンド] f -- 意味不明なエラーメッセージ --> b subgraph s[Webサービス] f -- 接続断 --x ds[データベースサービス] subgraph ds[データベースサービス] pa[プロセスA] -. 切り替え .-> pb[プロセスB] end end （悩み）全体の左側に配置したいが、 Mermaidでレイアウトを指定できる? （反省）デザイナーにレイアウトを伝えるために別途パワーポイントを描いたので、二度手間だったかもしれない

Slide 26

Slide 26 text

2.自己復旧できるようにする

Slide 27

Slide 27 text

概要 • 自己復旧がなぜ重要か • 自己復旧の基本的なアプローチ • 推奨事項 • 失敗した操作を再試行する • リモートサービスを保護する（サーキットブレーカー） • リソースの消費や障害を閉じ込める (バルクヘッド) • など

Slide 28

Slide 28 text

質問所属する組織やチームで「再試行やタイムアウトの考慮が文化として根付いている」という人は挙手してください

Slide 29

Slide 29 text

この章の重要ポイント一過性の障害から回復する最も代表的な方法は、再試行です。アプリケーションに再試行ロジックを組み込みます。筆者の経験でもその効果は大きく、逆にいうと再試行しないアプリケーションは問題がおきやすいです。優先して検討してください。 [推奨事項 - 失敗した操作を再試行する] 経験的に、再試行の実装を当たり前とする、もしくは潔いタイムアウトの判断ができるチームが作るアプリケーションは、ライフライクル全体で問題がおきにくいです

Slide 30

Slide 30 text

3. 調整を最小限に抑える

Slide 31

Slide 31 text

概要 • クラウドに存在する様々な「調整」とは • スケールアウトや役割分担により、構成要素は多数、多様になる • 構成要素間の様々な調整が必要になりがち（リソースのロック、重複処理の回避など） • 推奨事項 • 結果整合性を受け入れる • CQRS（Command and Query Responsibility Segregation）やイベントソーシングパターンを検討する • 楽観的並行性制御を検討する • など

Slide 32

Slide 32 text

質問前章と本章で「べき等」という言葉は何回使われたでしょうか

Slide 33

Slide 33 text

この章の重要ポイント第2章自己復旧できるようにする - べき等にするで紹介したように、操作がべき等になるように設計します。べき等は本書で何度も触れられるキーワードですが、このしつこさからも、クラウドアプリケーションでは重要な考え方だとわかるでしょう。強く意識してください。 [推奨事項 - べき等にする] 前頁の答え: 15回べき等にできるかどうかで、調整のしくみは大きく変わります。そのしくみは、べき等、つまり「失敗したらシンプルに再試行」できますか？べき等ではない調整は、たいてい複雑でテストも困難です。

Slide 34

Slide 34 text

4. スケールアウトできるようにする

Slide 35

Slide 35 text

概要 • クラウドでスケールアウトが好まれる理由 • 拡張や縮小の際、サービスへの影響が小さい（スケールアップ/ダウンは一般的に、サービス停止や再起動を伴う） • 性能拡張に合わせて、可用性も高められる • スケールアップは限界に達すると、プロバイダのサービス拡充を待たなければならない • クラウドの中の事情（サーバの手に入りやすさとコスト、スケジューリングなど） • 推奨事項 • セッションアフィニティやスティッキーセッションに依存しない • 限界とボトルネックを把握する • 安全にスケールインする • など

Slide 36

Slide 36 text

この章の重要ポイント #1 本番で問題が発生してからインスタンスを追加しても、手遅れになりがちです。リリースする前に、スケールアウトで目標性能を達成できるか検証してください。また、目標性能を達成できたとしても、ビジネス成長に伴って後から目標が上がる可能性もあるでしょう。どれだけ拡張可能か、目標を超えた限界を探り、ボトルネックを把握しておくことをお勧めします。 [推奨事項 - 限界とボトルネックを把握する]

Slide 37

Slide 37 text

読者の反応「本にはこう書いてあるんですけど、みなさん限界やボトルネックを探るような検証やってます？」残念ながらわたしの把握する限り「みなさんが」実施されているとは言いがたいです。ですがみなさん、問題が起こってから「やっておけばよかった」とはおっしゃいます。

Slide 38

Slide 38 text

この章の重要ポイント #2 負荷の減少に合わせてスケールインする場合、インスタンスの削除、停止を安全に実行してください。いわゆる、グレースフルシャットダウンです。 [推奨事項 - 安全にスケールインする] 「スケールアウトしっ放し」は、たいていビジネス的に受け入れられません。処理量が落ち着いたら安全にスケールインできるようにしておきましょう。このしくみはメンテナンス時のローリングアップデートの安全性にもつながります。

Slide 39

Slide 39 text

この章の重要ポイント #3 グレースフルシャットダウンの有用性には疑いがありません。ですが、したくてもできないケースがあります。たとえばハードウェア障害です。また、インスタンスの削除、停止のシグナルを送らないサービスやプラットフォームソフトウェアもあります。～中略～「クラッシュオンリー設計」という言葉が出てきました。このアイデアは、USENIX HotOS IXで発表された論文「Crash-Only Software」がもとになっています。突然終了しても良いように、高度な終了処理を試みず、単に再起動するだけで障害から回復できるプログラムを指します。 [次頁へ続く]

Slide 40

Slide 40 text

この章の重要ポイント #3 [前頁の続き] 実現手段は、Twelve-Factor Appで紹介されているキューのほかにもあります。たとえばプログラムの終了時に限らず常にデータを永続化する、処理をアトミックにする、起動時に整合性チェックなど回復処理を行う、などです。クラッシュオンリー設計とグレースフルシャットダウンは、二者択一ではありません。いつクラッシュしても良いように作り、かつ、シグナルを受け取れる環境ではグレースフルシャットダウンする、という組み合わせもできます。 [（コラム）Crash-only Software] 備えよ常に

Slide 41

Slide 41 text

5. 分割して上限を回避する

Slide 42

Slide 42 text

概要 • クラウドサービスの上限を理解する • サービス全体の上限（例: サブスクリプションあたりのリソースグループ数） • サービスやリソース個別の上限（例: データベースの最大データサイズ） • 推奨事項 • データストアをパーティション分割する（水平的、垂直的、機能的） • 動かして把握する • デプロイスタンプパターンを検討する • など

Slide 43

Slide 43 text

この章の重要ポイントクラウドの進化によって、日々上限値は上がっています。筆者も始めは息苦しかったのですが、数年の間に多くの上限が緩和され、そこに達する機会は少なくなりました。今後も緩和は続くでしょう。ですが「大きな問題は分割して解決しよう」という「分割統治」のアイデアは、コンピュータの世界において問題解決の基本です。 [まとめ] 他者依存か、主体的かという姿勢の問題でもあります。とはいえ煽ってません。頑張りすぎも高コストにつながるので、ほどほどに期待し、クラウドプロバイダにおねだりしましょう。

Slide 44

Slide 44 text

“悲観主義は気分によるものであり、楽観主義は意志によるものである” アラン(フランスの哲学者) “上限拡大は期待によるものであり、分割は意志によるものである” トール・マカベッチ

Slide 45

Slide 45 text

6. 運用を考慮する

Slide 46

Slide 46 text

概要 • 運用しやすいアプリケーションとは • 判断や介入する機会が少なく自律的 • 必要な情報を得やすい • 導入や変更が容易 • 推奨事項 • 必要な情報を定義する • 利用者目線での監視を行う • テストを自動化する • など

Slide 47

Slide 47 text

この章の重要ポイントクラウドで「どのようなログやメトリクスを取っておけばよいか」「何を監視すべきか」という質問をいただくことがあります。これは経験上、危険なシグナルです。なぜなら、次のような状況にある可能性が高いからです。 [次頁へ続く] このような質問をいただくと、わたしの中のイージスシステムが起動します。

Slide 48

Slide 48 text

この章の重要ポイント [前頁の続き] • アプリケーションが健全に動いていると判断する指標を議論、定義できていない • 運用中のサービスレベルや可用性の評価を軽視しており、その設計や実装も十分でない • 丸投げされた運用チームが、一般論やベストプラクティスを落とし所にしようとしている [推奨事項 - 必要な情報を定義する] つまり、監視の他にも問題が潜んでいる可能性が高いです。

Slide 49

Slide 49 text

7. マネージドサービスを活用する

Slide 50

Slide 50 text

概要 • クラウド≒マネージドサービス • IaaSもPaaSもマネージドサービス • トレードオフを理解する • 推奨事項 • IaaSとPaaSの垣根をなくす • メンテナンスに備える • 何を自ら作り運用すべきかを問う • など

Slide 51

Slide 51 text

この章の重要ポイント目的を達成できそうなPaaSが提供されていても、仮想マシンで自ら作り運用すべきケースは、3つあるでしょう。 1. 自ら作り運用することで、差別化できる 2. プロバイダよりも、うまく作り運用する能力がある 3. 既存のアプリケーションの作りや条件が、プロバイダの提供するしくみに合わない～中略～この3つのケースがすべてというつもりはありません。ですが、仮想マシンを選択した理由がどれにも当てはまらない場合は、PaaSを使えないか再検討することをお勧めします。ケース”3”を理由に、仮想マシンへ「リフト&シフト」する案件はとても多いですが、やるなら徹底しましょう

Slide 52

Slide 52 text

（余談）中途半端な「リフト&シフト」は失敗しがち • 既存アプリはそのまま… • たいていは再試行やタイムアウトなどエラーハンドリングが甘い • パターン①: アプリは仮想マシンへ、DBはPaaSを選択 • DBメンテナンスのたびに接続が切れ、エラーが頻発 • 「こんなはずじゃなかった」 • パターン②: アプリ基盤もDBもPaaSを選択（アプリだけリフト&シフト) • パターン①に加え • アプリ基盤のメンテナンスや挙動の違いに悩まされる • 「こんなはずじゃなかった」経験上、オンプレの仮想マシンで動くアプリケーションを「リフト&シフト」するなら、徹底して仮想マシンにこだわったほうが幸せになりやすいです。逆に言えば、PaaSを使うならアプリケーションを相応に作り変えましょう。

Slide 53

Slide 53 text

8. 用途に適したデータストアを選ぶ

Slide 54

Slide 54 text

概要 • 選択肢はリレーショナルデータベースだけではないことを理解する • もちろんリレーショナルデータベースは有力な選択肢 • 要件によっては非リレーショナルデータベースより向く選択肢があることを知っておく • 推奨事項 • 要件に適するデータストアを選ぶ • 一貫性に関するトレードオフを理解する • 開発チームの能力を考慮する • など

Slide 55

Slide 55 text

この章の重要ポイントクラウドへの移行においては、さまざまな新技術に出会うことでしょう。初めは誰でも初心者です。とにかく手を動かし、経験を積み、ものにするしかありません。その際のポイントは、特に重要でリスクの高いテーマから集中的に学ぶことです。そのひとつが、データストアへの永続化です。いくらポリグロット・パーシステンスに価値があるとしても、使ったことのないデータストアをいくつも並べるのは不安です。焦らず、特に採用効果が大きく、アプリケーションのコアになるデータストアから取り組むとよいでしょう。 [推奨事項 - 開発チームの能力を考慮する] アイコンを並べた「アーキテクチャ」図を作ることと、実際使うことの間には大きなギャップがあります。データストアは特に慎重に。未経験でも「使いたい」意欲が強い場合は、人と時間に投資しましょう。投資する価値があるデータストアは、きっとあります。

Slide 56

Slide 56 text

9. 進化を見込んで設計する

Slide 57

Slide 57 text

概要 • どうやって進化、変化に対応し続けるか • テストの自動化は重要ポイント • マイクロサービスアーキテクチャやその文脈で語られる手法には、学ぶべきところが多い • 推奨事項 • 高凝集と疎結合を徹底する • 非同期メッセージングを活用する • マイクロサービスアーキテクチャの設計パターンから学ぶ • など

Slide 58

Slide 58 text

読者の反応「マイクロサービスアーキテクチャの設計パターンで紹介されている、ゲートウェイルーティングパターンとゲートウェイ集約パターンの違いがわかりにくいです」確かに、例があったほうがわかりやすいですね

Slide 59

Slide 59 text

ゲートウェイルーティングとゲートウェイ集約の違いゲートウェイルーティングゲートウェイ集約クライアントゲートウェイサービスA サービスB gateway.example.com/a • クライアントはサービスごとのホスト名を知らなくてよい（パスでルーティング） • サービスごとにリクエストする必要はある gateway.example.com/b クライアントゲートウェイサービスA サービスB gateway.example.com/all • /allなどの集約パスを指定することで、1度のリクエストで複数サービスからの結果をまとめて取得する • ゲートウェイにドメイン/ビジネスロジックがしみ出てしまいがちなので、注意が必要

Slide 60

Slide 60 text

10. ビジネスニーズを忘れない

Slide 61

Slide 61 text

概要 • ビジネスニーズは技術の現場から遠ざかりやすい • 「ビジネスニーズを忘れないなんて当たり前」、果たして本当にそうでしょうか • ちょっと気を抜くと、アプリケーション開発と運用の現場からビジネスニーズは遠ざかる • 推奨事項 • 企業、組織のニーズや戦略を確認し、文書化する • 具体的、現実的な目標を設定、文書化する • コストを最適化する • など

Slide 62

Slide 62 text

読者の反応「本にはSLOなど目標を数値化しようと書いてあるんですけど、みなさんやってます？」残念ながらわたしの把握する限り「みなさんが」実施されているとは言いがたいです。「やぶへびになる」というシステム側の都合でそもそも議論に至らないというケースもありますが、目標をビジネス側が理解、判断しにくいという背景もあります。

Slide 63

Slide 63 text

この章の重要ポイント #1 もちろん、リソースの使用率や死活状態も、アプリケーションを構成する要素の状態を把握し、洞察を得る重要な指標です。ですがビジネスとして合意し、目標に掲げる指標は、わかりやすいものに絞ったほうがよいでしょう。非機能要件のチェックリストを広げて「合意しましょう」と迫っても、混乱するだけです。 [推奨事項 - 具体的、現実的な目標を設定、文書化する - 利用者目線で指標を選ぶ] ビジネス側の主な関心事は、応答成功率と応答時間など、利用者体験に関することでしょう。非機能要件チェックリストは、使う場を考えましょう。なお、非機能要件チェックリストが形骸化している現場も多いように感じます。作っても継続的に評価できていないのであれば、見直すタイミングかもしれません。

Slide 64

Slide 64 text

この章の重要ポイント #2 従量課金のクラウドで費用を最適化する基本戦略は、「使っていないリソースは停止する、もしくは消す」です。毎日、夜間8時間は仮想マシンを停止すれば、費用の3分の1を削減できます。「使用率に合わせて適したサイズへと変更する」も有効です。仮想マシンの価格が搭載CPU数に比例するのなら、CPU使用率が 10％を超えない仮想マシンを維持するのは不経済です。半減を超えるコスト削減の可能性があります。当たり前のことを、と思われるでしょう。ですが筆者の経験では、当たり前と言えるほどは実行されていません。実行されない原因は、いくつかあります。 [次頁に続く]

Slide 65

Slide 65 text

この章の重要ポイント [前頁の続き] • 利用状況や使用率を測定していない（遊休リソースの存在に気付いていない） • リソースのサイズを変更して、期待通りに再開できるか不安 • リソースを停止して、期待通りに再開できるか不安 • リソースを削除して、必要な時に再作成や再現できるか不安、作業コストも不安 [推奨事項 - コストを最適化する - リソースの最適化ができない原因] 自己回復力、安全なスケールイン、監視や利用状況の分析、テスト、作業の自動化といった、本書で解説した推奨事項ができていれば、コスト最適化もしやすいと言えます。