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

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

Toru Makabe
January 19, 2024
8k

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

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

Toru Makabe

January 19, 2024
Tweet

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