Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for Toru Makabe Toru Makabe
January 19, 2024
8.8k

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

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

Avatar for Toru Makabe

Toru Makabe

January 19, 2024
Tweet

More Decks by Toru Makabe

Transcript

  1. お伝えしたいこと • これから読む人へ • 本書を読む補助線となる情報 • もう読んだ人へ • 内容を記憶に定着させるための刺激ネタ •

    「そういう背景や意図があったのか」ネタ • 輪読会や感想戦で使えるネタ • 網羅的ではありません • ポイントや思い入れのあるところだけ
  2. ベストプラクティスの「負の側面」  特定の環境、条件下での「ベスト」である  いまのあなたとチームにとってベストかは、わからない  複数のベストプラクティスが衝突、矛盾することもある(例: A製品とB製品のベストプラクティスが矛盾)  変化する

     製品はフィードバックを受けて変化する  使い手の環境も変化する  合わせて、ベストプラクティスも変化する  そのベストプラクティスが半年後にベストかは、わからない  鵜呑みにしてしまう  自分の頭で考えなくなってしまう
  3. とはいえ、すべてを吟味してもいられない ベスト プラクティスA ベスト プラクティスB ベスト プラクティスC ベスト プラクティスD 言わんとすること

    を理解し 他のベストプラクティスとの一 貫性を確認し 内容に変化がないか定期的 に確認し 自分たちの環境や条件 に合うか議論し
  4. いいドキュメントがある、しかし  全体的に端折り気味  読み手の知識に期待している  翻訳がやや惜しい  もっと具体例がほしい 

    エピソードやサンプルコードなど  クラウド中立にできそう  Azureに限らない話が多い Azure アプリケーションの設計原則 - Azure Architecture Center | Microsoft Learn
  5. 概要 • クラウドの内部構造(障害を切り口に) • 冗長化がなぜ重要か • サービスレベルの考え方と実際 • 推奨事項 •

    ビジネス要件を考慮する • RTOとRPOを意識する • 正常性エンドポイントを実装する • など
  6. 意図的にこの章を先頭にした Azure アプリケーションの設計原則 - Azure Architecture Center | Microsoft Learn

    オリジナルでは2番目  本書を読み進めるにあたり、クラウド の内部構造を早めに解説しておきた かったため  障害に備えた冗長化、というピンと きやすいテーマで解説するのが良いと 考えた  いっぽうでこの章のボリュームが多め になってしまい、「いきなり疲れる」と いうフィードバックもあった
  7. トレードオフの例  GitHubはシークレットをAzure Key Vaultに入れてローテーションしている  ローテーションのしくみにバグがあり、 Codespacesの作成に影響した  セキュリティ視点では有効な手法だ

    が実装は複雑になりがちで、障害の 原因になりやすい  セキュリティを重視し、信頼性も下げ たくないので、さらなる投資を行う (プレイブックやドキュメントの整備 含む設計、実装、運用の改善) GitHub Availability Report: December 2023 - The GitHub Blog
  8. (余談)本書の執筆、コラボレーション環境 • 執筆 • 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の共有、コメント入力ができるクラウドサービスでコラボレーション
  9. (余談)本書の図はMermaidで書きました、が flowchart LR b[利用者のブラウザ] --> f[フロントエンド] f -- 意味不明なエラーメッセージ -->

    b subgraph s[Webサービス] f -- 接続断 --x ds[データベースサービス] subgraph ds[データベースサービス] pa[プロセスA] -. 切り替え .-> pb[プロセスB] end end (悩み)全体の左側に配置したいが、 Mermaidでレイアウトを指定できる? (反省)デザイナーにレイアウトを伝えるために別途パワー ポイントを描いたので、二度手間だったかもしれない
  10. 概要 • 自己復旧がなぜ重要か • 自己復旧の基本的なアプローチ • 推奨事項 • 失敗した操作を再試行する •

    リモートサービスを保護する(サーキットブレーカー) • リソースの消費や障害を閉じ込める (バルクヘッド) • など
  11. 概要 • クラウドに存在する様々な「調整」とは • スケールアウトや役割分担により、構成要素は多数、多様になる • 構成要素間の様々な調整が必要になりがち(リソースのロック、重複処理の回避など) • 推奨事項 •

    結果整合性を受け入れる • CQRS(Command and Query Responsibility Segregation)や イベントソーシングパターンを検討する • 楽観的並行性制御を検討する • など
  12. この章の重要ポイント 第2章 自己復旧できるようにする - べき等にするで紹介したように、操作がべき 等になるように設計します。べき等は本書で何度も触れられるキーワードですが、 このしつこさからも、クラウドアプリケーションでは重要な考え方だとわかるでしょう。 強く意識してください。 [推奨事項 -

    べき等にする] 前頁の答え: 15回 べき等にできるかどうかで、調整のしくみは大きく変わります。そのしくみは、べき等、つまり「失敗したらシンプルに 再試行」できますか? べき等ではない調整は、たいてい複雑でテストも困難です。
  13. 概要 • クラウドでスケールアウトが好まれる理由 • 拡張や縮小の際、サービスへの影響が小さい (スケールアップ/ダウンは一般的に、サービス停止や再起動を伴う) • 性能拡張に合わせて、可用性も高められる • スケールアップは限界に達すると、プロバイダのサービス拡充を待たなければならない

    • クラウドの中の事情(サーバの手に入りやすさとコスト、スケジューリングなど) • 推奨事項 • セッションアフィニティやスティッキーセッションに依存しない • 限界とボトルネックを把握する • 安全にスケールインする • など
  14. 概要 • クラウドサービスの上限を理解する • サービス全体の上限(例: サブスクリプションあたりのリソースグループ数) • サービスやリソース個別の上限(例: データベースの最大データサイズ) •

    推奨事項 • データストアをパーティション分割する(水平的、垂直的、機能的) • 動かして把握する • デプロイスタンプパターンを検討する • など
  15. 概要 • 運用しやすいアプリケーションとは • 判断や介入する機会が少なく自律的 • 必要な情報を得やすい • 導入や変更が容易 •

    推奨事項 • 必要な情報を定義する • 利用者目線での監視を行う • テストを自動化する • など
  16. 概要 • クラウド≒マネージドサービス • IaaSもPaaSもマネージドサービス • トレードオフを理解する • 推奨事項 •

    IaaSとPaaSの垣根をなくす • メンテナンスに備える • 何を自ら作り運用すべきかを問う • など
  17. この章の重要ポイント 目的を達成できそうなPaaSが提供されていても、仮想マシンで自ら作り運用すべ きケースは、3つあるでしょう。 1. 自ら作り運用することで、差別化できる 2. プロバイダよりも、うまく作り運用する能力がある 3. 既存のアプリケーションの作りや条件が、プロバイダの提供するしくみに合わな い

    ~中略~ この3つのケースがすべてというつもりはありません。ですが、仮想マシンを選択した 理由がどれにも当てはまらない場合は、PaaSを使えないか再検討することをお勧 めします。 ケース”3”を理由に、仮想マシンへ「リフト&シフト」する案件はとても多いですが、やるなら徹底しましょう
  18. (余談)中途半端な「リフト&シフト」は失敗しがち • 既存アプリはそのまま… • たいていは再試行やタイムアウトなどエラーハンドリングが甘い • パターン①: アプリは仮想マシンへ、DBはPaaSを選択 • DBメンテナンスのたびに接続が切れ、エラーが頻発

    • 「こんなはずじゃなかった」 • パターン②: アプリ基盤もDBもPaaSを選択(アプリだけリフト&シフト) • パターン①に加え • アプリ基盤のメンテナンスや挙動の違いに悩まされる • 「こんなはずじゃなかった」 経験上、オンプレの仮想マシンで動くアプリケーションを「リフト&シフト」するなら、徹底して仮想マシンにこだわった ほうが幸せになりやすいです。 逆に言えば、PaaSを使うならアプリケーションを相応に作り変えましょう。
  19. 概要 • どうやって進化、変化に対応し続けるか • テストの自動化は重要ポイント • マイクロサービスアーキテクチャやその文脈で語られる手法には、学ぶべきところが多い • 推奨事項 •

    高凝集と疎結合を徹底する • 非同期メッセージングを活用する • マイクロサービスアーキテクチャの設計パターンから学ぶ • など
  20. ゲートウェイルーティングとゲートウェイ集約の違い ゲートウェイルーティング ゲートウェイ集約 クライアント ゲートウェイ サービスA サービスB gateway.example.com/a • クライアントはサービスごとのホスト名を知らな

    くてよい(パスでルーティング) • サービスごとにリクエストする必要はある gateway.example.com/b クライアント ゲートウェイ サービスA サービスB gateway.example.com/all • /allなどの集約パスを指定することで、1度のリクエ ストで複数サービスからの結果をまとめて取得する • ゲートウェイにドメイン/ビジネスロジックがしみ出て しまいがちなので、注意が必要
  21. この章の重要ポイント #1 もちろん、リソースの使用率や死活状態も、アプリケーションを構成する要素の状 態を把握し、洞察を得る重要な指標です。 ですがビジネスとして合意し、目標に掲げる指標は、わかりやすいものに絞ったほ うがよいでしょう。非機能要件のチェックリストを広げて「合意しましょう」と迫っても、 混乱するだけです。 [推奨事項 - 具体的、現実的な目標を設定、文書化する

    - 利用者目線で指 標を選ぶ] ビジネス側の主な関心事は、応答成功率と応答時間など、利用者体験に関することでしょう。 非機能要件チェックリストは、使う場を考えましょう。なお、非機能要件チェックリストが形骸化している現場も多 いように感じます。作っても継続的に評価できていないのであれば、見直すタイミングかもしれません。
  22. この章の重要ポイント [前頁の続き] • 利用状況や使用率を測定していない(遊休リソースの存在に気付いていな い) • リソースのサイズを変更して、期待通りに再開できるか不安 • リソースを停止して、期待通りに再開できるか不安 •

    リソースを削除して、必要な時に再作成や再現できるか不安、作業コストも 不安 [推奨事項 - コストを最適化する - リソースの最適化ができない原因] 自己回復力、安全なスケールイン、監視や利用状況の分析、テスト、作業の自動化といった、本書で解説した 推奨事項ができていれば、コスト最適化もしやすいと言えます。
  23. Q&A