🏗️

Azure Well-Architected Framework入門 - 信頼性とコスト最適化を中心に

に公開
Azure
コスト最適化
Well-Architected Framework
信頼性
クラウドアーキテクチャ
idea

はじめに

Azureでワークロードを設計する際、どのような指針に基づいて設計すればよいか悩んだことはありませんか？🤔

そんなときに役立つのが Azure Well-Architected Framework（W-AF） です。

本記事では、Azure Well-Architected Frameworkの概要を解説し、特に 信頼性（Reliability） と コスト最適化（Cost Optimization） の2つの柱にフォーカスして、実際のところどうなのかを探っていきます。

Azure Well-Architected Frameworkとは？

Azure Well-Architected Framework（W-AF） は、Azureでワークロードの品質を向上させるための設計フレームワークです。

Microsoftが提供する公式ドキュメントによると、W-AFは以下の目標を達成するための指針を提供します：

  • 🛡️ 回復力があり、利用可能で、復旧可能である
  • 🔐 必要なセキュリティレベルを確保する
  • 💰 十分な投資対効果（ROI）を提供する
  • 🔧 責任ある開発と運用をサポートする
  • ⏱️ 許容可能な時間内に目的を達成する

5つの柱（Pillars）

W-AFは5つの柱で構成されています。それぞれの柱が、ワークロードの品質を高めるための異なる観点を提供します。

柱 概要 関心事
信頼性（Reliability） 回復力、可用性、復旧 ビジネス要件に基づいた設計、レジリエンス、復旧、運用
セキュリティ（Security） データ保護、脅威検出、軽減 機密性、整合性、可用性の保護
コスト最適化（Cost Optimization） コストモデリング、予算管理、無駄の削減 使用量と利用率の最適化、コスト効率の維持
オペレーショナルエクセレンス（Operational Excellence） 包括的な可観測性、DevOpsプラクティス 標準化、包括的な監視、安全なデプロイメント
パフォーマンス効率（Performance Efficiency） スケーラビリティ、負荷テスト 水平スケーリング、早期テスト、ソリューションの健全性監視

今回の記事では、特に太字で強調した信頼性とコスト最適化に焦点を当てていきます！✨

フレームワークの構成要素

各柱には、以下の要素が含まれています：

要素 説明
🎯 設計原則 それぞれの目標を持つ優れた設計の基礎を提供します
✅ チェックリスト 主要な戦略と、Azureが推奨事項を達成するのにどのように役立つかについて説明する推奨事項ガイドが含まれています
🧩 設計パターン 関連するクラウド設計パターンが示されています
⚖️ トレードオフ それぞれのアーキテクチャーの決定には一連の考慮事項が伴います。また、トレードオフもあります
📈 成熟度モデル 基本的な推奨事項から始めて、Azure Well-Architected Frameworkを採用するための段階的なアプローチについて説明します

評価ツール：Azure Well-Architected Review

自分のワークロードがW-AFの原則に沿っているかを確認するために、Microsoftは Azure Well-Architected Review という評価ツールを提供しています。

🔗 評価ツールURL: https://learn.microsoft.com/ja-jp/assessments/azure-architecture-review/

このツールでは、約60の質問に回答することで、ワークロードの設計について信頼性・セキュリティ・コスト最適化・オペレーショナルエクセレンス・パフォーマンス効率の観点からカスタマイズされたガイダンスを受け取ることができます。🎄

なぜ信頼性とコストに焦点を当てるのか？

W-AFの5つの柱はすべて重要ですが、実際のプロジェクトではトレードオフとビジネス要件による制約の間で決定が行われます。

特に：

  • 💡 信頼性はサービスの根幹であり、ユーザー体験に直結する
  • 💡 コスト最適化はビジネスの持続可能性に不可欠

この2つは多くの場合、相反する関係にあります。高い信頼性を求めれば冗長構成が必要になりコストが増加し、コストを削減しようとすれば信頼性が低下するリスクがあります。

このトレードオフをどのようにバランスさせるかが、アーキテクトの腕の見せどころです！💪

信頼性（Reliability）の柱

信頼性とは何か？

信頼性とは、意図した機能を一貫して提供し続けることです。

公式ドキュメントによると、信頼性のあるワークロードは以下の特性を持ちます：

  • 🛡️ レジリエント（Resilient）: 障害を検出し、耐えながら動作を継続できる
  • 🔄 回復可能（Recoverable）: レジリエンス対策を超える障害が発生した場合でも、合意された回復目標内で復元できる
  • ✅ 可用性が高い（Available）: 約束された時間内に、約束された品質レベルでユーザーがアクセスできる

ビジネス要件が信頼性設計を決定する

信頼性の設計は、技術的な最適解ではなく、ビジネス要件によって決定されます。

考慮すべき主要なポイント：

観点 考慮事項
📊 サービスの制限 選択したサービスの制限・クォーターなどの制限事項を考慮
🔗 依存関係 依存関係があるサービス・APIなどの影響を考慮
📈 稼働率要件 システムの重要度に応じた稼働率・稼働とみなす要件の設定
⏱️ 復旧時間 障害発生時にどの程度の時間で復旧するか
💾 データリストア データリストアが必要な場合どの程度の時間で復旧するか

何をもって「障害」とみなすか？

ここが信頼性設計の核心部分です。「障害」の定義自体がビジネスの継続要件によって決まります。

例えば、ECサイトで考えてみましょう：

  • 🛒 決済機能が停止 → これは明確に障害
  • 📝 商品レビュー機能が停止 → ビジネスによっては許容できるかも？
  • 🔍 検索の応答が5秒以上かかる → 障害とみなす？パフォーマンス劣化とみなす？

同じ事象でも、ビジネスによって「障害」と定義するかどうかが変わってきます。

信頼性を測る主要な指標

信頼性を定量的に把握するために、以下の指標が使われます：

指標 説明
SLO（Service Level Objective） ワークロードのパフォーマンスと信頼性の目標値。顧客が期待するサービス品質に基づいて設定
SLI（Service Level Indicator） サービスパフォーマンスの特定の側面を測定する定量的な指標。SLOの達成度を測定するために使用
SLA（Service Level Agreement） サービス提供者と顧客の間の契約上の合意。未達成の場合は金銭的な影響がある場合も
RTO（Recovery Time Objective） インシデント後にアプリケーションが利用不可となる最大許容時間
RPO（Recovery Point Objective） インシデント中のデータ損失の最大許容期間
MTTR（Mean Time To Recover） 障害検出後にコンポーネントを復旧するのにかかる平均時間
MTBF（Mean Time Between Failure） ワークロードが期待される機能を中断なく実行できる期間

信頼性設計の原則

W-AFでは、信頼性のための5つの設計原則が提唱されています：

  1. 📋 ビジネス要件に基づいた設計（Design for business requirements）

    • ワークロードの期待される使用に焦点を当てて、ビジネスニーズを収集し理解する
    • 「サイトは常に稼働している必要がある」のような漠然とした要件ではなく、現実的で達成可能な期待値を設定

  2. 🛡️ レジリエンスのための設計（Design for resilience）

    • ワークロードが障害に対応し、完全または縮退した機能で動作し続けることができるように設計
    • 障害を許容し、グレースフルに処理できるシステムを構築

  3. 🔄 復旧のための設計（Design for recovery）

    • ユーザー体験とビジネス目標への影響を最小限に抑えながら、ほとんどの障害から復旧できるように設計
    • 構造化され、テストされ、文書化された復旧計画を持つ

  4. 👁️ 運用のための設計（Design for operations）

    • ワークロードは観測可能であり、開発チームは障害から学ぶことができる必要がある
    • 監視をワークロードに組み込み、障害発生時にサポートチームに通知するアラートを構築

  5. ✨ シンプルに保つ（Keep it simple）

    • アーキテクチャ設計、アプリケーションコード、運用の過剰なエンジニアリングを避ける
    • ビジネス要件に焦点を当て、不要な機能やコンポーネントを削除する

信頼性を作り込むための設計

信頼性を高めるための設計において、重要なポイントがあります：

信頼性設計のアプローチ：

  • 🎯 重要なコンポーネントにリソースを割り当てる
  • 🧩 設計パターンを正しく使用する
    • リトライ（再試行）
    • サーキットブレーカー
    • イベントソーシング
    • レート制限
  • 🏗️ 様々なアプリケーション層での冗長性と回復性を構築する

代表的な設計パターン

信頼性を向上させるための代表的な設計パターンを紹介します：

パターン 概要
🔄 再試行（Retry） 特定の操作を制御された方法で再試行することで、一時的または断続的な障害に対処します。分散システムの一時的な障害を軽減することは、ワークロードの回復性を向上させる重要な手法です。
⚡ サーキットブレーカー ワークロードの正常な低下をトリガーするパターン。多くの場合、自己保存と自己復旧の両方を提供するために自動回復と組み合わせています。
📨 イベントソーシング 状態変更を一連のイベントとして扱う。ビジネスプロセスで信頼性の高い変更履歴が重要な場合に使用できる。
🚦 レート制限 無制限の再試行オンエラーシナリオを回避するために、クライアント要求の速度を制御します。サービスが指定された制限に達しないように設計されている場合に、クライアントを保護します。
💓 正常性エンドポイント システムの正常性または状態を監視する方法を提供するために、特別に設計されたエンドポイントを公開します。

それぞれのパターンについて詳しく見ていきましょう！✨

再試行（Retry）パターン

クラウド環境では、一時的な障害が予想できるため、一定の遅延時間を置いて一定回数呼び出すことが一般的です。

一定回数のエラーののち、最終的にエラーとして扱います。

再試行戦略

アプリケーションがリモートサービスに要求を送信しようとして障害が検出された場合、次の方法を使用して障害を処理できます：

戦略 説明 適用ケース
❌ キャンセルする 障害が一時的でないか操作を繰り返しても成功する可能性が低い場合、操作をキャンセルして例外を報告する必要があります。 429以外の4xxエラーなど
🔁 すぐに再試行 報告された障害が、ネットワークパケットの破損など異常またはまれなものである場合は要求をすぐに再試行することが最善である場合があります。 ネットワークの一時的な問題
⏰ 時間をおいて再試行する 障害の原因がより一般的な接続またはビジー状態の障害いずれかである場合は時間をおいて再試行することでうまくいく場合が多いです。 5xxのステータスコードの多く
Azure Container Appsの再試行戦略（Preview）

Container Appsでは、そのContainer Appsに対して行われた要求に対してリトライポリシーを適用できます。

注意点として、Container Appsから行われた要求ではなく、Container Appsに対して行われた要求に対してルールが適用されます。

サーキットブレーカーパターン

再試行パターンは一時的な障害から回復するのに有効な手段です。

しかしながら、インフラの状態によっては再試行することでリソースを使い果たす可能性があり、ほかの関係のないところで失敗する可能性があります。🔥

これを避けるために一時的に再試行を一時停止することをサーキットブレーカーパターンと呼びます。

サーキットブレーカーの状態遷移：

状態 説明 遷移条件
🟢 Closed（閉） 通常の状態。リクエストを通過させる 障害が閾値を超える → Open へ
🔴 Open（開） 障害が多発している状態。リクエストを即座に失敗させる タイムアウト後 → Half-Open へ
🟡 Half-Open（半開） 回復を確認するためにいくつかのリクエストを通過させる 成功 → Closed へ / 失敗 → Open へ

イベントソーシングパターン

従来のアプローチの問題

通常、アプリケーションがデータを更新しようとするとき：

  1. 📝 データをロックするトランザクションを使用
  2. 📖 データを読み取り変更を加え新しい値で状態を更新

このアプローチには以下の問題があります：

  • ⚠️ 負荷の高いシステムではリソースの競合とロックによってパフォーマンスが低下する
  • ⚠️ データの最新の状態のみが格納される
  • ⚠️ 各操作の詳細を個別にログ記録する監査メカニズム（REDOログのような）がない限り履歴は失われる

イベントソーシングの解決策

イベントソーシングでは、状態変更を一連のイベントとして記録します。

  1. プレゼンテーション層から書き込み要求を受け取る
  2. Command Handlers/Business Objectsで処理
  3. イベント（Cart created, Item 1 added, Item 2 added...）としてEvent Storeに保存
  4. Event Handlerがイベントを処理
  5. Read-only storeや外部システムにデータを反映

正常性エンドポイントパターン

Webアプリケーションが正しく動作しているのか監視するために監視用のエンドポイントを設置します。

監視用のエンドポイントにアクセスすることで、アプリケーション側はデータベース・ストレージなどの構成要素が正しく動作していることのチェックをして、その状態を返します。

正常性エンドポイントの実装例

GET /health

レスポンス例：

{
  "status": "healthy",
  "checks": {
    "database": "healthy",
    "storage": "healthy",
    "cache": "healthy"
  },
  "responseTime": {
    "total": "50ms",
    "storage": "5ms",
    "database": "20ms"
  }
}

このエンドポイントを以下のような用途で活用できます：

  • 🔍 ロードバランサーのヘルスチェック
  • 📊 監視システムからのポーリング
  • 🚨 アラート発報のトリガー
  • 🔄 オートスケーリングの判断材料

🔗 参考: 正常性エンドポイント監視パターン

信頼性と他の柱とのトレードオフ

信頼性を高めることは重要ですが、他の柱とのトレードオフが発生することを理解しておく必要があります。

ここでは特にセキュリティとコストの観点からトレードオフを見ていきましょう。⚖️

セキュリティと信頼性のトレードオフ

信頼性を高めようとすると、ワークロードの攻撃可能領域が増加するという問題があります。

信頼性施策 セキュリティへの影響
🌍 地理的な分散 信頼性確保のために複数リージョンにデプロイすると、攻撃可能なポイントが増加
🔄 リカバリーソリューション バックアップサイトやDRサイトも攻撃対象になりうる
🏗️ 追加コンポーネント 信頼性確保のために追加のコンポーネントが必要になり、攻撃可能な領域が増える
📚 追加のコードとライブラリ 信頼性パターンを確保するために追加のコードとライブラリーが必要になり、脆弱性のリスクが増加

コストと信頼性のトレードオフ

信頼性を高めるためには、実装の冗長性が増加します。これは直接的にコスト増につながります。

信頼性施策 コストへの影響
📦 レプリカ数の増加 信頼性を確保するにはレプリカ数を増やす必要があり、その分のコンピューティングコストが発生
🌐 地理的な分散 複数リージョンへのデプロイは、リソースコストが倍増以上に
🆘 ディザスターリカバリー DR環境の維持には、本番環境とは別のコストが継続的に発生

稼働率とコストの関係

稼働率を上げるほど、コストは指数関数的に増加します：

稼働率 年間ダウンタイム 必要な対策
99%（2ナイン） 約3.65日 基本的な冗長構成
99.9%（3ナイン） 約8.76時間 可用性ゾーン活用
99.99%（4ナイン） 約52分 マルチリージョン＋自動フェイルオーバー
99.999%（5ナイン） 約5分 高度なアクティブ-アクティブ構成

トレードオフの考え方

信頼性を最大化することが必ずしも正解ではありません。以下の観点でバランスを取ることが重要です：

  1. 📊 ビジネスインパクトの評価

    • ダウンタイムによる損失額を試算する
    • その損失額と信頼性向上のコストを比較する

  2. 🎯 コンポーネント単位での最適化

    • すべてを同じ信頼性レベルにする必要はない
    • クリティカルな機能に投資を集中する

  3. ⚖️ 他の柱とのバランス

    • セキュリティを犠牲にしすぎていないか
    • 運用の複雑さが許容範囲か
    • コストは予算内に収まるか

次のセクションでは、コスト最適化の柱について詳しく見ていきます。

コスト最適化（Cost Optimization）の柱

コスト最適化とは？

アーキテクチャー設計は常にビジネス目標に基づくものであり、ROI（投資対効果）と財務上の制約に基づくものです。

コスト最適化を考える際に重要なポイント：

  • ⚖️ 一般的に、セキュリティ・スケーラビリティ・回復性・運用性などとはトレードオフが発生する
  • ⚠️ ビジネス要件の利点を正当化できない場合、より安価なソリューションを選ぶという危険な選択をしてしまう
  • 🎯 その結果、組織のビジネス目標を達成できない、またはその評判に影響を与えてしまう

コスト効率を考えた設計

投資に対する最高の収益を達成するために必要なものだけに費やします。

コスト効率を高めるための設計ポイント：

観点 説明
📏 最適なサイジング 必要以上に大きなリソースを選ばない。実際の負荷に見合ったサイズを選択
🎚️ 最適な機能レベル 使わない機能を含む高価なSKUを避ける
🏭 環境ごとの最適化 運用環境と非運用環境に求められる機能差を考慮する

環境ごとの最適化例

環境 最適化のポイント
🚀 本番環境 信頼性・パフォーマンス重視のSKU選択
🧪 開発/テスト環境 低コストSKU、使用しない時間帯は停止
📊 ステージング環境 本番に近い構成だが、常時稼働は不要な場合も

使用レベルに合わせた設計

リソースの使用を最大化します。

効率的なリソース活用のためのポイント：

  • ❌ 不要な機能を含むSKUを選択することを避けます

    • 例：Premium機能が不要なのにPremium SKUを選んでいないか？

  • 📈 動的にスケールさせる

    • 固定のリソースサイズではなく、需要に応じてスケールアウト/スケールインする
    • オートスケーリングを活用して、ピーク時以外のコストを削減

スケーリング戦略の比較

戦略 メリット デメリット
📦 固定サイズ 予測可能なコスト、シンプルな運用 ピーク時に不足、閑散時に無駄
📊 スケジュールベース 予測可能なパターンに対応 予期せぬ負荷変動に弱い
🔄 メトリクスベース 実際の負荷に応じて最適化 設定の複雑さ、スケーリングの遅延

レート最適化の設計

機能要件または非機能要件を犠牲にすることなく効率を向上させます。

Azure特有のコスト最適化オプション：

オプション 説明
🔄 Azure ハイブリッド特典 既存のWindows Server/SQL Serverライセンスを活用してAzureのコストを削減
🧪 非運用環境の低コストSKU 開発・テスト環境では本番と同じスペックは不要
💳 従量課金 vs 予約 コスト効率が高い場合は従量課金ベースも検討

予約インスタンス vs 従量課金の判断

利用パターン 推奨オプション
📅 24時間365日稼働 Reserved Instance（1年/3年）
🌙 夜間・週末停止可能 従量課金 + 自動停止
📈 負荷変動が大きい 従量課金 + オートスケール
🎲 スポット利用可能 Azure Spot VMs（最大90%割引）

コスト最適化のデザインパターン

コスト最適化を実現するための代表的なデザインパターンを紹介します。

パターン 概要
🏢 コンピューティングリソース統合 密度を高めることでコンピューティングリソースを最適化および統合する
🌐 静的コンテンツホスティング 静的コンテンツ配信に最適化されたプラットフォームを使用してコストを削減

コンピューティングリソース統合

複数のアプリケーションを1つのコンピューティングリソースに統合します。

このパターンは、共有インフラストラクチャ上でワークロードの複数のアプリケーションまたはコンポーネントを組み合わせます。

メリット

  • 📦 プールされたインフラストラクチャ上のコンポーネントまたはワークロード全体を集約
  • 🚫 使用されていないプロビジョニングされた容量を回避
  • 💻 コンピューティングリソースの利用率を最大限に高める

具体例：App Service Plan

1つのApp Service Plan (P1v3) に複数のApp Serviceをホストすることで、コンピューティングリソースを効率的に活用できます。

App Service 役割
🌐 Web App A フロントエンド
🔧 Web App B 管理画面
📡 Web App C API

静的コンテンツホスティング

静的コンテンツのみを配信する目的であれば、高額なコンピューティングインスタンスを持つリソースを使う必要がありません。

動的アプリケーションホストは、通常、コード化されたビジネスロジックを実行できるため、静的ホストよりもコストが高くなります。静的コンテンツの配信にアプリケーションプラットフォームを使用することは、コスト効率が良くありません。

推奨サービス

サービス 用途 月額目安
🌐 Azure Static Web Apps SPAや静的サイトのホスティング Free～
📦 Azure Blob Storage（静的Webサイト） シンプルな静的サイト 数百円～
🚀 Azure CDN グローバル配信の高速化 従量課金

比較：静的サイトのホスティングコスト

選択肢 月額コスト（概算） 適用ケース
❌ App Service (B1) 約¥2,000～ 過剰（静的サイトには不要）
❌ VM (B1s) 約¥1,500～ 過剰（管理コストも発生）
✅ Static Web Apps (Free) ¥0 最適！
✅ Blob Storage + CDN 数百円 大量アクセス時も低コスト

コスト最適化の設計原則

W-AFでは、コスト最適化のための5つの設計原則が提唱されています：

  1. 💰 コスト管理の規律を確立する（Develop cost-management discipline）

    • 予算、経費、報告、コスト追跡に対する意識を持つチーム文化を構築する
    • コストモデルを開発し、財務追跡システムを設定する

  2. 🎯 コスト効率を意識した設計（Design with a cost-efficiency mindset）

    • 投資に対する最高のリターンを達成するために必要なものだけに費やす
    • 過剰なプロビジョニングを避け、コストガードレールを設計に組み込む

  3. 📊 使用量の最適化を設計（Design for usage optimization）

    • リソースの使用率を最大化する
    • アイドル状態のリソースを削減する

  4. 💳 レートの最適化を設計（Design for rate optimization）

    • 割引オプション（予約インスタンスなど）を活用する
    • 適切な課金モデルを選択する

  5. 📈 継続的な監視と最適化（Monitor and optimize over time）

    • ワークロードの進化に合わせて継続的に投資を適正化する
    • 支出が予算に近づいたときのコストアラートを実装する

信頼性とコスト最適化のバランス

信頼性とコスト最適化は、しばしば相反する関係にあります。このバランスをどう取るかが、アーキテクトの腕の見せどころです！💪

バランスを取るためのアプローチ

  1. 📋 ビジネス要件の明確化
  2. 🎯 必要な信頼性レベルの決定
  3. 💰 コスト試算と予算との照合
  4. ⚖️ トレードオフの検討・調整
  5. ✅ 最終的なアーキテクチャ決定

実践的なヒント

シナリオ 推奨アプローチ
💼 ミッションクリティカル 信頼性優先、コストは二の次
🏢 一般的なビジネスアプリ バランス重視、99.9%程度の稼働率
🧪 内部ツール/開発環境 コスト優先、必要最低限の信頼性

コスト最適化と他の柱とのトレードオフ

コスト最適化を追求すると、他の柱とトレードオフが発生します。ここでは特に信頼性とパフォーマンス効率との関係を見ていきましょう。

コスト最適化と信頼性のトレードオフ

コスト最適化と信頼性のバランスを取るには、以下の観点で比較検討が必要です：

比較項目 説明
💸 損失コスト システムが停止することでの損失するコストと頻度
🛡️ 信頼性コスト 信頼性設計のためのコスト（冗長構成、DR環境など）

判断のフレームワーク

条件 判断
損失コスト > 信頼性設計コスト さらに信頼性設計のために投資する必要がある ✅
損失コスト < 信頼性設計コスト 現状の信頼性レベルで十分かもしれない 🤔

コスト最適化とパフォーマンス効率のトレードオフ

コスト最適化とパフォーマンス効率は、両方ともワークロードの最大化に優先順位を付けるという点で共通しています。

しかし、以下のようなトレードオフが存在します：

コスト優先の施策 パフォーマンスへの影響
💰 コスト制限 パフォーマンス不足になる可能性
📉 スケーリングの制限 需要を満たすのに十分なリソースが得られない
⏰ スケーリングの遅延 ピーク時に応答が遅くなる

具体例

コスト優先でスケーリング制限した場合の影響：

  1. 💰 コスト優先でスケーリング上限を3インスタンスに制限
  2. 📈 予期せぬトラフィック急増
  3. ⚠️ リソース不足でレスポンス遅延
  4. 😢 ユーザー体験の悪化

このように、コストを優先しすぎると、ビジネスに悪影響を及ぼす可能性があります。

バランスを取るためのアプローチ

アプローチ 説明
📊 負荷テスト 実際の負荷パターンを把握してから最適化
🔔 アラート設定 コストとパフォーマンスの両方を監視
🎚️ 段階的な最適化 一気に削減せず、影響を見ながら調整
📈 バッファを持つ ある程度の余裕を持ったスケーリング設定

まとめ

Azure Well-Architected Frameworkの信頼性とコスト最適化について見てきました。

W-AFが提供するもの

Azure Well-Architected Frameworkでは、ワークロードをより高品質にするための設計原則を提供します。

しかしながら、ビジネス的な制約、それぞれのトレードオフをみながら、それぞれのビジネス目標にあった選択をすることが重要になってきます。

キーポイント

  1. 📋 信頼性はビジネス要件によって決まる

    • 障害の定義自体がビジネスによって異なる
    • SLO/SLA/RTO/RPOを明確に設定する

  2. 🛠️ 設計パターンを活用して信頼性を作り込む

    • 再試行、サーキットブレーカー、イベントソーシングなど
    • すべてのコンポーネントに同じ信頼性は不要

  3. ⚖️ 信頼性と他の柱にはトレードオフがある

    • セキュリティ：攻撃可能領域の増加
    • コスト：冗長性によるコスト増

  4. 💰 コスト最適化は「安い」ことではない

    • 投資対効果の最大化
    • ビジネス要件を満たしながら無駄を削減

  5. 🎯 トレードオフを理解した上でバランスを取る

    • コスト vs 信頼性：損失コストと信頼性コストを比較
    • コスト vs パフォーマンス：制限しすぎない
    • ビジネス目標に立ち返って判断する

参考リンク

GitHubで編集を提案

Discussion