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

※リンクを効かせたい場合はダウンロードしてください

Transcript

1. “クラウドアプリケーション 10の設計原則”を もっと楽しむ Toru Makabe Senior Cloud Solution Architect Microsoft
2. About me 著者です
3. お伝えしたいこと • これから読む人へ • 本書を読む補助線となる情報 • もう読んだ人へ • 内容を記憶に定着させるための刺激ネタ • 「そういう背景や意図があったのか」ネタ • 輪読会や感想戦で使えるネタ • 網羅的ではありません • ポイントや思い入れのあるところだけ
4. Agenda  本書を書いた背景  原則いじり  概要  重要ポイント  裏話  読者の反応  Q&A
5. 本書を書いた動機
6. 本書の「つかみ」 「まずベストプラクティスを教えてください」 筆者の嫌いな言葉です。 [まえがき]
7. ベストプラクティス そのものは素晴らしい  ベンダやユーザの思想、経験にもとづく、貴重な知識  ベンダの公開するベストプラクティス  製品の設計思想に沿った使い方  ユーザからのフィードバックを整理して還元  ユーザの公開するベストプラクティス  複数の選択肢があった中から、実践しうまくいった経験を紹介
8. ベストプラクティスの「負の側面」  特定の環境、条件下での「ベスト」である  いまのあなたとチームにとってベストかは、わからない  複数のベストプラクティスが衝突、矛盾することもある（例: A製品とB製品のベストプラクティスが矛盾）  変化する  製品はフィードバックを受けて変化する  使い手の環境も変化する  合わせて、ベストプラクティスも変化する  そのベストプラクティスが半年後にベストかは、わからない  鵜呑みにしてしまう  自分の頭で考えなくなってしまう
9. ベストプラクティスを鵜呑みにした結果  ベストプラクティスが現在の社内ルールに反していることが分かったが、その価値 や妥当性を主張できない  複数のベストプラクティスを参考にしたが一貫性がなく、どれを優先すればよい か判断できない  トラブル対応ができない [まえがき]
10. とはいえ、すべてを吟味してもいられない ベスト プラクティスA ベスト プラクティスB ベスト プラクティスC ベスト プラクティスD 言わんとすること を理解し 他のベストプラクティスとの一 貫性を確認し 内容に変化がないか定期的 に確認し 自分たちの環境や条件 に合うか議論し
11. 原則を理解しよう!! ベスト プラクティスA ベスト プラクティスB ベスト プラクティスC ベスト プラクティスD 原則 （+背景）
12. いいドキュメントがある、しかし  全体的に端折り気味  読み手の知識に期待している  翻訳がやや惜しい  もっと具体例がほしい  エピソードやサンプルコードなど  クラウド中立にできそう  Azureに限らない話が多い Azure アプリケーションの設計原則 - Azure Architecture Center | Microsoft Learn
13. そこで「解説本」とした  転載や翻訳、翻案ではなく、解説本という建付け  筆者の経験をもとに解説、要約、加筆  Azureではないパブリッククラウドでも参考になるよう意識  具体例（クラウドの内部構造やサンプルコードなど）はAzure中心
14. 原則いじり
15. 10の原則 すべての要素を冗長化する 自己復旧できるようにする 調整を最小限に抑える スケールアウトできるようにする 分割して上限を回避する 運用を考慮する マネージドサービスを活用する 用途に適したデータストアを選ぶ 進化を見込んで設計する ビジネスニーズを忘れない
16. 1. すべての要素を冗長化する
17. 概要 • クラウドの内部構造（障害を切り口に） • 冗長化がなぜ重要か • サービスレベルの考え方と実際 • 推奨事項 • ビジネス要件を考慮する • RTOとRPOを意識する • 正常性エンドポイントを実装する • など
18. 意図的にこの章を先頭にした Azure アプリケーションの設計原則 - Azure Architecture Center | Microsoft Learn オリジナルでは2番目  本書を読み進めるにあたり、クラウド の内部構造を早めに解説しておきた かったため  障害に備えた冗長化、というピンと きやすいテーマで解説するのが良いと 考えた  いっぽうでこの章のボリュームが多め になってしまい、「いきなり疲れる」と いうフィードバックもあった
19. この章の重要ポイント アプリケーションに冗長性を組み込むと、コストと複雑さが増します。たとえば、複 数リージョンへのデプロイは、単一リージョンへのデプロイよりもコストがかかり、管理 も複雑です。手動でフェイルオーバーとフェイルバックを行うのであれば、判断する 体制とプロセス、切り替え手順の確立はもちろん、訓練も必要です。 本章は、すべての要素を冗長化「する」というタイトルです。しかし、冗長化で増え るコストと複雑さが妥当であるかは、ビジネス要件で判断します。すべての要素を 冗長化「できる」能力を身に着けつつ、ビジネス要件に合わせて要否を決めてくだ さい。 [推奨事項 - ビジネス要件を考慮する]
20. かなり削った「トレードオフ」という言葉 本書の原則のいくつかに、トレードオフの関係がみられます。たとえば本章の冗長 化と、10章のビジネス要件で触れるコストです。 実は本書は原稿段階で「”要はトレードオフおじさん”の本ね」と言われかねないほ ど、「トレードオフ」という単語が使われていました。くどいので、意図的に削ってい ます。 ただしアーキテクトや設計者に求められる重要な仕事のひとつは、トレードオフのど ちらを優先するかを判断し、利害関係者に説明することです。これを意識して読 むとさらに味わい深いでしょう。
21. あわせて読みたい  冗長化によって信頼性を上げること で、他の特性に影響する  コスト、運用の複雑性、性能、セ キュリティなど  当然、逆パターンもある（コストを優 先するなら、冗長化しない など） 信頼性のトレードオフ - Microsoft Azure Well-Architected Framework | Microsoft Learn
22. トレードオフの例  GitHubはシークレットをAzure Key Vaultに入れてローテーションしている  ローテーションのしくみにバグがあり、 Codespacesの作成に影響した  セキュリティ視点では有効な手法だ が実装は複雑になりがちで、障害の 原因になりやすい  セキュリティを重視し、信頼性も下げ たくないので、さらなる投資を行う （プレイブックやドキュメントの整備 含む設計、実装、運用の改善） GitHub Availability Report: December 2023 - The GitHub Blog
23. 読者の反応 「コスト削減ってSREの仕事だと思いますか?」 SREチームを組織した背景にもよるので（以下略。 ただし、コスト削減のトレードオフとして信頼性が低下しうるのであれば、信頼性に関する専門家として、その緩和 や解決で活躍の場はあると考えます。
24. （余談）本書の執筆、コラボレーション環境 • 執筆 • 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の共有、コメント入力ができるクラウドサービスでコラボレーション
25. （余談）本書の図はMermaidで書きました、が flowchart LR b[利用者のブラウザ] --> f[フロントエンド] f -- 意味不明なエラーメッセージ --> b subgraph s[Webサービス] f -- 接続断 --x ds[データベースサービス] subgraph ds[データベースサービス] pa[プロセスA] -. 切り替え .-> pb[プロセスB] end end （悩み）全体の左側に配置したいが、 Mermaidでレイアウトを指定できる? （反省）デザイナーにレイアウトを伝えるために別途パワー ポイントを描いたので、二度手間だったかもしれない
26. 2.自己復旧できるようにする
27. 概要 • 自己復旧がなぜ重要か • 自己復旧の基本的なアプローチ • 推奨事項 • 失敗した操作を再試行する • リモートサービスを保護する（サーキットブレーカー） • リソースの消費や障害を閉じ込める (バルクヘッド) • など
28. 質問 所属する組織やチームで「再試行やタイムアウトの考慮が文化として根付いてい る」という人は挙手してください
29. この章の重要ポイント 一過性の障害から回復する最も代表的な方法は、再試行です。アプリケーショ ンに再試行ロジックを組み込みます。筆者の経験でもその効果は大きく、逆にい うと再試行しないアプリケーションは問題がおきやすいです。優先して検討してくだ さい。 [推奨事項 - 失敗した操作を再試行する] 経験的に、再試行の実装を当たり前とする、もしくは潔いタイムアウトの判断ができるチームが作るアプリケーション は、ライフライクル全体で問題がおきにくいです
30. 3. 調整を最小限に抑える
31. 概要 • クラウドに存在する様々な「調整」とは • スケールアウトや役割分担により、構成要素は多数、多様になる • 構成要素間の様々な調整が必要になりがち（リソースのロック、重複処理の回避など） • 推奨事項 • 結果整合性を受け入れる • CQRS（Command and Query Responsibility Segregation）や イベントソーシングパターンを検討する • 楽観的並行性制御を検討する • など
32. 質問 前章と本章で「べき等」という言葉は何回使われたでしょうか
33. この章の重要ポイント 第2章 自己復旧できるようにする - べき等にするで紹介したように、操作がべき 等になるように設計します。べき等は本書で何度も触れられるキーワードですが、 このしつこさからも、クラウドアプリケーションでは重要な考え方だとわかるでしょう。 強く意識してください。 [推奨事項 - べき等にする] 前頁の答え: 15回 べき等にできるかどうかで、調整のしくみは大きく変わります。そのしくみは、べき等、つまり「失敗したらシンプルに 再試行」できますか？ べき等ではない調整は、たいてい複雑でテストも困難です。
34. 4. スケールアウトできるようにする
35. 概要 • クラウドでスケールアウトが好まれる理由 • 拡張や縮小の際、サービスへの影響が小さい （スケールアップ/ダウンは一般的に、サービス停止や再起動を伴う） • 性能拡張に合わせて、可用性も高められる • スケールアップは限界に達すると、プロバイダのサービス拡充を待たなければならない • クラウドの中の事情（サーバの手に入りやすさとコスト、スケジューリングなど） • 推奨事項 • セッションアフィニティやスティッキーセッションに依存しない • 限界とボトルネックを把握する • 安全にスケールインする • など
36. この章の重要ポイント #1 本番で問題が発生してからインスタンスを追加しても、手遅れになりがちです。リ リースする前に、スケールアウトで目標性能を達成できるか検証してください。また、 目標性能を達成できたとしても、ビジネス成長に伴って後から目標が上がる可能 性もあるでしょう。どれだけ拡張可能か、目標を超えた限界を探り、ボトルネック を把握しておくことをお勧めします。 [推奨事項 - 限界とボトルネックを把握する]
37. 読者の反応 「本にはこう書いてあるんですけど、みなさん限界やボトルネックを探るような検証 やってます？」 残念ながらわたしの把握する限り「みなさんが」実施されているとは言いがたいです。 ですがみなさん、問題が起こってから「やっておけばよかった」とはおっしゃいます。
38. この章の重要ポイント #2 負荷の減少に合わせてスケールインする場合、インスタンスの削除、停止を安全 に実行してください。いわゆる、グレースフルシャットダウンです。 [推奨事項 - 安全にスケールインする] 「スケールアウトしっ放し」は、たいていビジネス的に受け入れられません。処理量が落ち着いたら安全にスケールイン できるようにしておきましょう。このしくみはメンテナンス時のローリングアップデートの安全性にもつながります。
39. この章の重要ポイント #3 グレースフルシャットダウンの有用性には疑いがありません。ですが、したくてもでき ないケースがあります。たとえばハードウェア障害です。また、インスタンスの削除、 停止のシグナルを送らないサービスやプラットフォームソフトウェアもあります。 ～中略～ 「クラッシュオンリー設計」という言葉が出てきました。このアイデアは、USENIX HotOS IXで発表された論文「Crash-Only Software」がもとになっています。突 然終了しても良いように、高度な終了処理を試みず、単に再起動するだけで障 害から回復できるプログラムを指します。 [次頁へ続く]
40. この章の重要ポイント #3 [前頁の続き] 実現手段は、Twelve-Factor Appで紹介されているキューのほかにもあります。た とえばプログラムの終了時に限らず常にデータを永続化する、処理をアトミックに する、起動時に整合性チェックなど回復処理を行う、などです。 クラッシュオンリー設計とグレースフルシャットダウンは、二者択一ではありません。 いつクラッシュしても良いように作り、かつ、シグナルを受け取れる環境ではグレース フルシャットダウンする、という組み合わせもできます。 [（コラム）Crash-only Software] 備えよ常に
41. 5. 分割して上限を回避する
42. 概要 • クラウドサービスの上限を理解する • サービス全体の上限（例: サブスクリプションあたりのリソースグループ数） • サービスやリソース個別の上限（例: データベースの最大データサイズ） • 推奨事項 • データストアをパーティション分割する（水平的、垂直的、機能的） • 動かして把握する • デプロイスタンプパターンを検討する • など
43. この章の重要ポイント クラウドの進化によって、日々上限値は上がっています。筆者も始めは息苦し かったのですが、数年の間に多くの上限が緩和され、そこに達する機会は少なく なりました。今後も緩和は続くでしょう。 ですが「大きな問題は分割して解決しよう」という「分割統治」のアイデアは、コン ピュータの世界において問題解決の基本です。 [まとめ] 他者依存か、主体的かという姿勢の問題でもあります。 とはいえ煽ってません。頑張りすぎも高コストにつながるので、ほどほどに期待し、クラウドプロバイダにおねだりしま しょう。
44. “悲観主義は気分によるものであり、楽観主義は意志によるものである” アラン(フランスの哲学者) “上限拡大は期待によるものであり、分割は意志によるものである” トール・マカベッチ
45. 6. 運用を考慮する
46. 概要 • 運用しやすいアプリケーションとは • 判断や介入する機会が少なく自律的 • 必要な情報を得やすい • 導入や変更が容易 • 推奨事項 • 必要な情報を定義する • 利用者目線での監視を行う • テストを自動化する • など
47. この章の重要ポイント クラウドで「どのようなログやメトリクスを取っておけばよいか」「何を監視すべきか」 という質問をいただくことがあります。これは経験上、危険なシグナルです。なぜな ら、次のような状況にある可能性が高いからです。 [次頁へ続く] このような質問をいただくと、わたしの中のイージスシステムが起動します。
48. この章の重要ポイント [前頁の続き] • アプリケーションが健全に動いていると判断する指標を議論、定義できていな い • 運用中のサービスレベルや可用性の評価を軽視しており、その設計や実装も 十分でない • 丸投げされた運用チームが、一般論やベストプラクティスを落とし所にしようと している [推奨事項 - 必要な情報を定義する] つまり、監視の他にも問題が潜んでいる可能性が高いです。
49. 7. マネージドサービスを活用する
50. 概要 • クラウド≒マネージドサービス • IaaSもPaaSもマネージドサービス • トレードオフを理解する • 推奨事項 • IaaSとPaaSの垣根をなくす • メンテナンスに備える • 何を自ら作り運用すべきかを問う • など
51. この章の重要ポイント 目的を達成できそうなPaaSが提供されていても、仮想マシンで自ら作り運用すべ きケースは、3つあるでしょう。 1. 自ら作り運用することで、差別化できる 2. プロバイダよりも、うまく作り運用する能力がある 3. 既存のアプリケーションの作りや条件が、プロバイダの提供するしくみに合わな い ～中略～ この3つのケースがすべてというつもりはありません。ですが、仮想マシンを選択した 理由がどれにも当てはまらない場合は、PaaSを使えないか再検討することをお勧 めします。 ケース”3”を理由に、仮想マシンへ「リフト&シフト」する案件はとても多いですが、やるなら徹底しましょう
52. （余談）中途半端な「リフト&シフト」は失敗しがち • 既存アプリはそのまま… • たいていは再試行やタイムアウトなどエラーハンドリングが甘い • パターン①: アプリは仮想マシンへ、DBはPaaSを選択 • DBメンテナンスのたびに接続が切れ、エラーが頻発 • 「こんなはずじゃなかった」 • パターン②: アプリ基盤もDBもPaaSを選択（アプリだけリフト&シフト) • パターン①に加え • アプリ基盤のメンテナンスや挙動の違いに悩まされる • 「こんなはずじゃなかった」 経験上、オンプレの仮想マシンで動くアプリケーションを「リフト&シフト」するなら、徹底して仮想マシンにこだわった ほうが幸せになりやすいです。 逆に言えば、PaaSを使うならアプリケーションを相応に作り変えましょう。
53. 8. 用途に適したデータストアを選ぶ
54. 概要 • 選択肢はリレーショナルデータベースだけではないことを理解する • もちろんリレーショナルデータベースは有力な選択肢 • 要件によっては非リレーショナルデータベースより向く選択肢があることを知っておく • 推奨事項 • 要件に適するデータストアを選ぶ • 一貫性に関するトレードオフを理解する • 開発チームの能力を考慮する • など
55. この章の重要ポイント クラウドへの移行においては、さまざまな新技術に出会うことでしょう。初めは誰で も初心者です。とにかく手を動かし、経験を積み、ものにするしかありません。 その際のポイントは、特に重要でリスクの高いテーマから集中的に学ぶことです。 そのひとつが、データストアへの永続化です。いくらポリグロット・パーシステンスに価 値があるとしても、使ったことのないデータストアをいくつも並べるのは不安です。焦 らず、特に採用効果が大きく、アプリケーションのコアになるデータストアから取り組 むとよいでしょう。 [推奨事項 - 開発チームの能力を考慮する] アイコンを並べた「アーキテクチャ」図を作ることと、実際使うことの間には大きなギャップがあります。 データストアは特に慎重に。未経験でも「使いたい」意欲が強い場合は、人と時間に投資しましょう。 投資する価値があるデータストアは、きっとあります。
56. 9. 進化を見込んで設計する
57. 概要 • どうやって進化、変化に対応し続けるか • テストの自動化は重要ポイント • マイクロサービスアーキテクチャやその文脈で語られる手法には、学ぶべきところが多い • 推奨事項 • 高凝集と疎結合を徹底する • 非同期メッセージングを活用する • マイクロサービスアーキテクチャの設計パターンから学ぶ • など
58. 読者の反応 「マイクロサービスアーキテクチャの設計パターンで紹介されている、ゲートウェイルー ティングパターンとゲートウェイ集約パターンの違いがわかりにくいです」 確かに、例があったほうがわかりやすいですね
59. ゲートウェイルーティングとゲートウェイ集約の違い ゲートウェイルーティング ゲートウェイ集約 クライアント ゲートウェイ サービスA サービスB gateway.example.com/a • クライアントはサービスごとのホスト名を知らな くてよい（パスでルーティング） • サービスごとにリクエストする必要はある gateway.example.com/b クライアント ゲートウェイ サービスA サービスB gateway.example.com/all • /allなどの集約パスを指定することで、1度のリクエ ストで複数サービスからの結果をまとめて取得する • ゲートウェイにドメイン/ビジネスロジックがしみ出て しまいがちなので、注意が必要
60. 10. ビジネスニーズを忘れない
61. 概要 • ビジネスニーズは技術の現場から遠ざかりやすい • 「ビジネスニーズを忘れないなんて当たり前」、果たして本当にそうでしょうか • ちょっと気を抜くと、アプリケーション開発と運用の現場からビジネスニーズは遠ざかる • 推奨事項 • 企業、組織のニーズや戦略を確認し、文書化する • 具体的、現実的な目標を設定、文書化する • コストを最適化する • など
62. 読者の反応 「本にはSLOなど目標を数値化しようと書いてあるんですけど、みなさんやってま す？」 残念ながらわたしの把握する限り「みなさんが」実施されているとは言いがたいです。 「やぶへびになる」というシステム側の都合でそもそも議論に至らないというケースもありますが、目標をビジネス側が 理解、判断しにくいという背景もあります。
63. この章の重要ポイント #1 もちろん、リソースの使用率や死活状態も、アプリケーションを構成する要素の状 態を把握し、洞察を得る重要な指標です。 ですがビジネスとして合意し、目標に掲げる指標は、わかりやすいものに絞ったほ うがよいでしょう。非機能要件のチェックリストを広げて「合意しましょう」と迫っても、 混乱するだけです。 [推奨事項 - 具体的、現実的な目標を設定、文書化する - 利用者目線で指 標を選ぶ] ビジネス側の主な関心事は、応答成功率と応答時間など、利用者体験に関することでしょう。 非機能要件チェックリストは、使う場を考えましょう。なお、非機能要件チェックリストが形骸化している現場も多 いように感じます。作っても継続的に評価できていないのであれば、見直すタイミングかもしれません。
64. この章の重要ポイント #2 従量課金のクラウドで費用を最適化する基本戦略は、「使っていないリソースは 停止する、もしくは消す」です。毎日、夜間8時間は仮想マシンを停止すれば、 費用の3分の1を削減できます。「使用率に合わせて適したサイズへと変更する」 も有効です。仮想マシンの価格が搭載CPU数に比例するのなら、CPU使用率が 10％を超えない仮想マシンを維持するのは不経済です。半減を超えるコスト削 減の可能性があります。 当たり前のことを、と思われるでしょう。ですが筆者の経験では、当たり前と言え るほどは実行されていません。実行されない原因は、いくつかあります。 [次頁に続く]
65. この章の重要ポイント [前頁の続き] • 利用状況や使用率を測定していない（遊休リソースの存在に気付いていな い） • リソースのサイズを変更して、期待通りに再開できるか不安 • リソースを停止して、期待通りに再開できるか不安 • リソースを削除して、必要な時に再作成や再現できるか不安、作業コストも 不安 [推奨事項 - コストを最適化する - リソースの最適化ができない原因] 自己回復力、安全なスケールイン、監視や利用状況の分析、テスト、作業の自動化といった、本書で解説した 推奨事項ができていれば、コスト最適化もしやすいと言えます。
66. Q&A
67. Thank you