シンプルさと効率性を実現するための設計に関する推奨事項
この 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 データベースに格納されます。
推奨事項
その他のデータ ストアを検討します。 リレーショナル データベースは、常に適切とは限りません。 詳細については、「データ ストア モデルを理解する」を参照してください。
データに含まれるのは、永続化されたアプリケーション データだけではないことに注意してください。 アプリケーション ログ、イベント、メッセージ、およびキャッシュも含まれています。
ポリグロットな永続化、つまりさまざまなデータ ストア テクノロジを組み合わせて使用するソリューションを使用します。
持っているデータの種類を考えてみましょう。 たとえば、次の情報を保存します。
SQL データベース内のトランザクション データ。
ドキュメント データベース内の JSON ドキュメント。
時系列データベース内のテレメトリ。
Azure Cognitive Search 内のアプリケーション ログ。
Azure Blob Storage 内の BLOB。
一貫性よりも可用性を優先します。 CAP 定理では、分散システムにおいては可用性と一貫性のトレードオフをしなければならないことが示されています。 完全に回避することができないネットワークの分断は、CAP 定理のもう 1 つの要素です。 しかし、最終的な一貫性モデルを採用すると、より高い可用性を得ることができます。
あなたの開発チームのスキル セットを検討する。 多言語パーシステンスを利用することにはメリットがありますが、過度になることがあります。 新しいデータ ストレージ テクノロジを採用するには、新しいスキル セットが必要です。 テクノロジを最大限に活用するために、開発チームは、次を実行する必要があります。
クエリを最適化します。
パフォーマンスを調整します。
適切な使用パターンで作業します。
ストレージ テクノロジを選択するときは、次の要因を考慮してください。
補正トランザクションを使用する。 ポリグロットな永続化を使用する場合、1 つのトランザクションが複数のストアにデータを書き込む可能性があります。 失敗した場合は、終了しているすべての手順を元に戻す補正トランザクションを使用します。
ドメイン駆動型の設計概念である境界付きコンテキストを検討します。 コンテキスト境界は、ドメイン モデルの周囲の明示的な境界です。 コンテキスト境界は、ドメインのどの部分にモデルが適用されるかを定義します。 コンテキスト境界がビジネス ドメインのサブドメインにマッピングされるのが理想です。 ご利用のシステムにおけるコンテキスト境界のポリグロットな永続化を検討します。 たとえば、製品が製品カタログ サブドメインと製品インベントリ サブドメインに出現することが考えられます。 しかし、ほとんどの場合、この 2 つのサブドメインは、商品の保管、更新、クエリについて異なる要件を持っています。
Azure ファシリテーション
Azure には次のサービスが用意されています。
Azure Functions は、最小限のコードでオーケストレーションを構築するために使用できるサーバーレス コンピューティング サービスです。
Azure Logic Apps は、GUI を使用して、または構成ファイルを編集することで、オーケストレーションを構築するために使用できるサーバーレス ワークフロー統合プラットフォームです。
Azure Event Grid は、MQTT および HTTP プロトコルを使用する柔軟なメッセージ消費パターンを提供する、スケーラブルでフル マネージドのパブリッシュ/サブスクライブ メッセージ配信サービスです。 Event Grid を使用すると、デバイス データを使用したデータ パイプラインの構築、イベントドリブン サーバーレス アーキテクチャの構築、アプリケーションの統合を行うことができます。
詳細については、以下を参照してください:
例
要件に基づいてコンポーネントとその機能を決定するワークロードの例については、「信頼性の高い Web アプリ パターン」を参照してください。
関連リンク
信頼性チェックリスト
レコメンデーションの完全なセットを参照してください。