簡素化と効率性を実現するための設計に関する推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:01 | ビジネス目標に合わせてワークロードを設計し、不要な複雑さやオーバーヘッドを回避します。 実用的でバランスの取れたアプローチを使用して、目的の結果を提供する設計上の決定を行います。 非効率性と潜在的な問題を減らすために、必要に応じて設計を含める。 |
|---|
このガイドでは、ワークロードをシンプルかつ効率的に保つために不要な複雑さとオーバーヘッドを最小限に抑えるための推奨事項について説明します。 ワークロードの信頼性を最適化するために必要なワークロード タスクを実行するのに最適なコンポーネントを選択します。 開発と管理の負担を軽減するために、プラットフォーム提供のサービスが提供する効率性を活用します。 この設計は、回復性、反復性、拡張性、管理性を備えたワークロード アーキテクチャを作成するのに役立ちます。
定義
| 期間 | 定義 |
|---|---|
| ワークロード | 他のタスクから論理的に分離できる個別の機能またはコンピューティング タスク。 |
主要な設計戦略
信頼性のための設計の重要な理性は、物事をシンプルかつ効率的に保つことです。 不要な複雑さまたは過剰なオーバーヘッドのリスクを軽減するために、ビジネス要件を満たすことにワークロード設計を集中させます。 この記事の推奨事項を検討して、無駄のない、効率的で信頼性の高いワークロードを作成するための設計に関する決定を下すのに役立ちます。 ワークロードが違えば、可用性、スケーラビリティ、データ整合性、およびディザスター リカバリーの要件も違ってくる可能性があります。
ビジネス要件を持つすべての設計上の決定を正当化する必要があります。 この設計原則は明らかなように見えるかもしれませんが、ワークロードの設計には非常に重要です。 アプリケーションは何百万人ものユーザー、または数千人をサポートしていますか? 大量のトラフィック バーストが生じていますか。またはワークロードは安定していますか。 どのレベルのアプリケーション停止を許容できますか。 ビジネス要件によって、これらの設計上の考慮事項が促進されます。
トレードオフ: 複雑なソリューションでは、より多くの機能と柔軟性を提供できますが、コンポーネントの調整、通信、管理が必要になるため、ワークロードの信頼性に影響する可能性があります。 または、より単純なソリューションがユーザーの期待を完全に満たしていない場合や、ワークロードの進化に伴ってスケーラビリティと拡張性に悪影響を及ぼす可能性があります。
コラボレーション設計の演習
利害関係者と協力して、次の作業を行います。
ワークロードのユーザー フローとシステム フローに重要度レベルを定義して割り当てます。 必要なコンポーネントと、必要な回復性レベルを達成するための最適なアプローチを決定するのに役立つ 重要なフロー に設計を集中します。
機能要件と非機能要件を定義する。 機能要件を検討して、アプリケーションがタスクを実行するかどうかを判断します。 非機能要件を検討して、アプリケーションがタスクをどの程度適切に実行するかを決定します。 スケーラビリティ、可用性、待機時間などの非機能要件を理解していることを確認します。 これらの要件は、設計に関する意思決定とテクノロジの選択に影響します。
ワークロードをコンポーネントに分解します。 設計のシンプルさ、効率性、信頼性に優先順位を付けます。 フローをサポートするために必要なコンポーネントを決定します。 一部のコンポーネントでは、複数のフローがサポートされています。 コンポーネントが概念的に対処する課題を特定し、完全な機能を提供しながら全体的な設計を簡素化するために、個々のフローからコンポーネントを削除することを検討します。 詳細については、「 エラー モード分析を実行するための推奨事項」を参照してください。
障害モード分析を使用して 、単一障害点と潜在的なリスクを特定します。 可能性の低い状況 (リージョン内のすべての可用性ゾーンに影響を与える大規模な自然災害が発生する地理的な地域など) を考慮する必要があるかどうかを検討します。 コストがかかり、これらの一般的でないリスクを軽減するために重要なトレードオフが伴います。 リスクに対するビジネスの許容範囲を明確に理解します。 詳細については、「 エラー モード分析を実行するための推奨事項」を参照してください。
フローの可用性と復旧のターゲットを定義して、ワークロードのアーキテクチャを通知します。 ビジネス メトリックには、サービス レベル目標 (SLO)、サービス レベル アグリーメント (SLA)、平均復旧時間 (MTTR)、平均故障間隔 (MTBF)、目標復旧時間 (RTO)、回復ポイント目標 (RPO) が含まれます。 これらのメトリックのターゲット値を定義します。 この演習では、各チームの目標がビジネス目標を達成し、現実的であることを確認するために、テクノロジチームとビジネス チーム間の妥協と相互理解が必要になる場合があります。 詳細については、「 信頼性ターゲットを定義するための推奨事項」を参照してください。
その他の設計上の推奨事項
利害関係者の関与なしに、次の推奨事項を実行できます。
デザインのシンプルさとわかりやすさに努めます。 コンポーネントとサービスに適した抽象化と粒度を使用します。 ソリューションのオーバーエンジニアリングやアンダーエンジニアリングは避けてください。 たとえば、コードを複数の小さな関数に分割すると、理解、テスト、保守が困難になります。
バグの修正、新しい機能やテクノロジの実装、既存のシステムのスケーラビリティと回復性の向上など、すべての成功したアプリケーションが時間の経過とともに変化することを認めます。
可能な場合は、サービスとしてのインフラストラクチャ (IaaS) ではなく、サービスとしてのプラットフォーム (PaaS) オプションを使用します。 IaaS は部品箱のようなサービスです。 何でも構築できますが、自分で組み立てる必要があります。 PaaS オプションの方が構成や管理が簡単です。 仮想マシン (VM) や仮想ネットワークを設定する必要はありません。 また、パッチや更新プログラムのインストールなどのメンテナンス タスクを実行する必要はありません。
非同期メッセージングを使用して 、メッセージ プロデューサーをコンシューマーから切り離します。
抽象インフラストラクチャをドメイン ロジックと分離する。 ドメイン ロジックが、メッセージングや永続化などのインフラストラクチャ関連の機能に干渉しないようにします。
複数のサービスにまたがる機能を専用のサービスにオフロードする。 さまざまな関数間でコードを複製する必要性を最小限に抑え、さまざまなコンポーネントで簡単に使用できる適切に定義されたインターフェイスを使用してサービスを再利用することをお勧めします。 たとえば、複数のサービスで要求を認証する必要がある場合は、この機能を独自のサービスに移動できます。 その後、認証サービスを進化させることができます。 たとえば、それを使用するサービスに触れることなく、新しい認証フローを追加できます。
ニーズに合った一般的なパターンとプラクティスの適合性を評価 します。 コンテキストや要件に最適ではない可能性がある傾向や推奨事項に従わないでください。 たとえば、マイクロサービスは、複雑さ、オーバーヘッド、依存関係の問題が発生する可能性があるため、すべてのアプリケーションに最適なオプションではありません。
十分なコードを開発する
シンプルさ、効率性、信頼性の原則は、開発プラクティスにも適用されます。 疎結合のコンポーネント化されたワークロードで、コンポーネントが提供する機能を決定します。 フローを開発して、その機能を活用します。 開発プラクティスに関する次の推奨事項を検討してください。
ビジネス要件を満たすプラットフォーム機能を使用します。 たとえば、開発と管理をオフロードするには、クラウド プロバイダーが提供するローコード、コードなし、またはサーバーレス ソリューションを使用します。
ライブラリとフレームワークを使用します。
開発プラクティスとして、ペア プログラミングまたは専用のコード レビュー セッションを導入します。
デッド コードを識別するアプローチを実装します。 自動テストでカバーされていないコードに懐疑的である。
データに最適なデータ ストアを使用する
かつて多くの組織では、すべてのデータを大規模なリレーショナル SQL データベースに格納していました。 リレーショナル データベースは、リレーショナル データ トランザクションに対してアトミック、一貫性、分離、持続性 (ACID) の保証を提供します。 ただし、これらのデータベースには欠点があります。
クエリには、費用のかかる結合が必要になることがあります。
データを正規化し、スキーマ オン ライトのために再構築する必要があります。
ロックの競合がパフォーマンスに影響を与える可能性があります。
リレーショナル データベースの代替策
大規模なソリューションでは、1 つのデータ ストア テクノロジですべてのニーズが満たされない可能性があります。 リレーショナル データベースの代替策として、以下があります。
キーと値のストア
ドキュメント データベース
検索エンジンのデータベース
タイム シリーズ データベース
列ファミリのデータベース
グラフ データベース
各オプションには長所と短所があります。 異なるデータ型は、異なるデータ ストアの種類に適しています。 データとその使用方法に最適なストレージ テクノロジを選びましょう。
たとえば、製品カタログを、柔軟なスキーマをサポートする Azure Cosmos DB などのドキュメント データベースに格納することが考えられます。 各製品の説明は自己完結型のドキュメントです。 カタログ全体のクエリの場合は、カタログのインデックスを作成し、Azure Cognitive Search にインデックスを格納することがあります。 そのデータには ACID の保証が必要なため、製品インベントリが SQL データベースに入る場合があります。
Recommendations
他のデータ ストアを検討してください。 リレーショナル データベースは必ずしも適切ではありません。 詳細については、「 データ ストア モデルについて」を参照してください。
データに含まれるのは、永続化されたアプリケーション データだけではないことに注意してください。 アプリケーション ログ、イベント、メッセージ、およびキャッシュも含まれています。
ポリグロット永続化またはデータ ストア テクノロジの組み合わせを使用するソリューションを採用します。
持っているデータの種類を考えてみましょう。 たとえば、次のように格納します。
SQL データベース内のトランザクション データ。
ドキュメント データベース内の JSON ドキュメント。
時系列データベースのテレメトリ。
Azure Cognitive Searchのアプリケーション ログ。
Azure Blob Storage内の BLOB。
一貫性よりも可用性に優先順位を付けます。 CAP 定理は、分散システムの可用性と整合性のトレードオフを行う必要があることを意味します。 CAP 定理の他のコンポーネントであるネットワーク パーティションを完全に回避することはできません。 ただし、最終的な整合性モデルを採用して、可用性を高めることができます。
あなたの開発チームのスキル セットを検討する。 多言語パーシステンスを利用することにはメリットがありますが、過度になることがあります。 新しいデータ ストレージ テクノロジを採用するには、新しいスキル セットが必要です。 テクノロジを最大限に活用するには、開発チームは次の作業を行う必要があります。
クエリを最適化します。
パフォーマンスを調整します。
適切な使用パターンを操作します。
ストレージ テクノロジを選択するときは、次の要因を考慮してください。
補正トランザクションを使用する。 ポリグロット永続化では、1 つのトランザクションが複数のストアにデータを書き込む場合があります。 エラーが発生した場合は、補正トランザクションを使用して、完了した手順を元に戻します。
ドメイン駆動型の設計概念である境界付きコンテキストを検討してください。 コンテキスト境界は、ドメイン モデルの周囲の明示的な境界です。 境界付きコンテキストは、モデルが適用されるドメインのどの部分を定義します。 コンテキスト境界がビジネス ドメインのサブドメインにマッピングされるのが理想です。 システム内の境界付きコンテキストのポリグロット永続化を検討してください。 たとえば、製品が製品カタログ サブドメインと製品インベントリ サブドメインに表示される場合があります。 しかし、ほとんどの場合、この 2 つのサブドメインは、商品の保管、更新、クエリについて異なる要件を持っています。
Azure ファシリテーション
Azure には、次のサービスが用意されています。
Azure Functionsは、最小限のコードでオーケストレーションを構築するために使用できるサーバーレス コンピューティング サービスです。
Azure Logic Apps は、GUI を使用してオーケストレーションを構築したり、構成ファイルを編集したりするために使用できるサーバーレス ワークフロー統合プラットフォームです。
Azure Event Gridは、MQTT および HTTP プロトコルを使用する柔軟なメッセージ消費パターンを提供する、非常にスケーラブルでフル マネージドのパブリッシュ/サブスクライブ メッセージ配信サービスです。 Event Grid を使用すると、デバイス データを使用してデータ パイプラインを構築し、イベントドリブン サーバーレス アーキテクチャを構築し、アプリケーションを統合できます。
詳細については、次を参照してください。
例
要件に基づいてコンポーネントとその機能を決定するワークロードの例については、「 Reliable Web App パターン」を参照してください。
関連リンク
信頼性チェックリスト
推奨事項の完全なセットを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示