ハイブリッド アプリの設計に関する考慮事項
Microsoft Azure は、一貫性のある唯一のハイブリッド クラウドです。 これにより、開発投資を再利用でき、グローバル Azure、ソブリン Azure クラウド、およびデータセンター内の Azure の拡張機能である Azure Stack にまたがるアプリを有効にすることができます。 クラウドにまたがるアプリは、ハイブリッド アプリとも呼ばれます。
Azure アプリケーション アーキテクチャ ガイド では、スケーラブルで回復性があり、高可用性を備えたアプリを設計するための構造化されたアプローチについて説明しています。 Azure アプリケーション アーキテクチャ ガイド で説明されている考慮事項は、単一のクラウド向けに設計されたアプリと、クラウドにまたがるアプリに対して同様に適用されます。
この記事では、
ハイブリッド シナリオは、開発に使用できるリソースと、地域、セキュリティ、インターネット アクセス、その他の考慮事項などのスパンに関する考慮事項によって大きく異なります。 このガイドでは特定の考慮事項を列挙できませんが、いくつかの重要なガイドラインとベスト プラクティスを提供できます。 ハイブリッド アプリ アーキテクチャを正常に設計、構成、デプロイ、および保守するには、本質的に知られていない可能性がある多くの設計上の考慮事項が含まれます。
このドキュメントでは、ハイブリッド アプリを実装するときに発生する可能性のある質問を集計し、それらを操作するための考慮事項 (これらの柱) とベスト プラクティスを示します。 設計フェーズ中にこれらの質問に対処することで、運用環境で発生する可能性のある問題を回避できます。
基本的に、これらはハイブリッド アプリを作成する前に考慮する必要がある質問です。 開始するには、次のことを行う必要があります。
- アプリ コンポーネントを特定して評価します。
- 柱に対してアプリ コンポーネントを評価します。
アプリ コンポーネントを評価する
アプリの各コンポーネントは、大規模なアプリ内で独自の特定の役割を持ち、すべての設計上の考慮事項を考慮して確認する必要があります。 各コンポーネントの要件と機能は、アプリのアーキテクチャを判断するのに役立つこれらの考慮事項にマップする必要があります。
アプリのアーキテクチャを調査し、何で構成されるかを判断することで、アプリをコンポーネントに分解します。 コンポーネントには、アプリが対話する他のアプリを含めることもできます。 コンポーネントを特定するときは、次の質問をして、その特性に従って目的のハイブリッド操作を評価します。
- コンポーネントの目的は何ですか?
- コンポーネント間の相互依存関係は何ですか?
たとえば、アプリでは、フロントエンドとバックエンドを 2 つのコンポーネントとして定義できます。 ハイブリッド シナリオでは、フロントエンドは 1 つのクラウドにあり、バックエンドはもう一方のクラウドにあります。 このアプリは、フロントエンドとユーザーの間、およびフロントエンドとバックエンドの間の通信チャネルを提供します。
アプリ コンポーネントは、多くのフォームとシナリオによって定義されます。 最も重要なタスクは、クラウドまたはオンプレミスの場所を識別することです。
インベントリに含める一般的なアプリ コンポーネントを表 1 に示します。
表 1. 一般的なアプリ コンポーネント
| コンポーネント | ハイブリッド アプリガイダンス |
|---|---|
| クライアント接続 | (任意のデバイス上の) アプリは、次の方法を含め、1 つのエントリ ポイントからさまざまな方法でユーザーにアクセスできます。 - ユーザーがアプリを操作するためにクライアントをインストールする必要があるクライアント/サーバー モデル。 ブラウザーからアクセスするサーバー ベースのアプリ。 - クライアント接続には、接続が切断されたときの通知や、ローミング料金が適用される可能性があるアラートを含めることができます。 |
| 認証 | 認証は、アプリに接続しているユーザー、または別のコンポーネントに接続しているコンポーネントから必要になる場合があります。 |
| API | 開発者は、API セットとクラス ライブラリを使用してアプリへのプログラムによるアクセスを提供し、インターネット標準に基づく接続インターフェイスを提供できます。 また、API を使用して、アプリを独立して動作する論理ユニットに分解することもできます。 |
| サービス | 簡潔なサービスを使用して、アプリの機能を提供できます。 サービスには、アプリを実行するエンジンを指定できます。 |
| キュー | キューを使用して、アプリのコンポーネントのライフ サイクルと状態の状態を整理できます。 これらのキューは、サブスクライブ側にメッセージング、通知、バッファリング機能を提供できます。 |
| データ ストレージ | アプリはステートレスでもステートフルでもかまいません。 ステートフル アプリには、さまざまな形式とボリュームで満たすことができるデータ ストレージが必要です。 |
| データ キャッシュ | 設計のデータ キャッシュ コンポーネントは、待機時間の問題に戦略的に対処し、クラウド バーストをトリガーする役割を果たすことができます。 |
| データ インジェスト | データは、Web フォームでユーザーが送信した値から、継続的に大量のデータ フローまで、さまざまな方法でアプリに送信できます。 |
| データ処理 | データ処理タスク (レポート、分析、バッチ エクスポート、データ変換など) は、ソースで処理することも、データのコピーを使用して別のコンポーネントにオフロードすることもできます。 |
重要な要素のアプリ コンポーネントを評価する
各コンポーネントについて、各柱の特性を評価します。 すべての柱で各コンポーネントを評価すると、ハイブリッド アプリの設計に影響を与える、考慮していない可能性のある質問が既知になる可能性があります。 これらの考慮事項に対処すると、アプリの最適化に価値が追加される可能性があります。 表 2 に、ハイブリッド アプリに関連する各柱の説明を示します。
表 2. 柱
| の柱の | 説明 |
|---|---|
| 位置付け | ハイブリッド アプリでのコンポーネントの戦略的配置。 |
| スケーラビリティ | 増加した負荷を処理するシステムの能力。 |
| 可用性 | ハイブリッド アプリが機能し、動作している時間の割合。 |
| 復元 | ハイブリッド アプリが回復する機能。 |
| 管理 | 運用環境でシステムを実行し続ける運用プロセス。 |
| 安全 | ハイブリッド アプリとデータを脅威から保護する。 |
位置付け
ハイブリッド アプリには、データセンターなど、本質的に配置の考慮事項があります。
配置は、ハイブリッド アプリに最適なサービスを提供できるようにコンポーネントを配置する重要なタスクです。 定義上、ハイブリッド アプリは、オンプレミスからクラウド、さまざまなクラウドの間など、さまざまな場所にまたがっています。 アプリのコンポーネントは、次の 2 つの方法でクラウドに配置できます。
垂直ハイブリッド アプリの
アプリ コンポーネントは、複数の場所に分散されます。 各コンポーネントには、1 つの場所にのみ複数のインスタンスを配置できます。水平ハイブリッド アプリの
アプリ コンポーネントは、複数の場所に分散されます。 各コンポーネントには、複数の場所にまたがる複数のインスタンスを含めることができます。コンポーネントによっては、その場所を認識できるコンポーネントもあれば、その場所と配置に関する知識がないコンポーネントもあります。 この好意は抽象化レイヤーで実現できます。 このレイヤーは、マイクロサービスなどの最新のアプリ フレームワークを使用して、クラウド間のノードで動作するアプリ コンポーネントの配置によってアプリがどのように処理されるかを定義できます。
配置チェックリスト
必要な場所を確認します。 アプリまたはそのコンポーネントが、特定のクラウドで動作する必要がある、または特定のクラウドの認定を必要としていることを確認します。 これには、会社からの主権要件や法律で定められた主権要件が含まれる場合があります。 また、特定の場所またはロケールに対してオンプレミスの操作が必要かどうかを判断します。
接続の依存関係を確認します。 必要な場所やその他の要因によって、コンポーネント間の接続の依存関係が決まります。 コンポーネントを配置するときに、それらの間の通信に最適な接続性とセキュリティを決定します。
プラットフォームの機能を評価します。 アプリ コンポーネントごとに、アプリ コンポーネントに必要なリソース プロバイダーがクラウドで使用できるかどうかを確認し、帯域幅が予想されるスループットと待機時間の要件に対応できるかどうかを確認します。
移植性を計画します。 コンテナーやマイクロサービスなどの最新のアプリ フレームワークを使用して、操作の移動を計画し、サービスの依存関係を防ぎます。
データ主権の要件を決定する。 ハイブリッド アプリは、ローカル データセンターなどのデータ分離に対応するために用意されています。 リソースの配置を確認して、この要件に対応するための成功を最適化します。
待機時間を計画します。 クラウド間操作では、アプリ コンポーネント間の物理的な距離が生じる可能性があります。 待機時間に対応するための要件を確認します。
トラフィック フローを制御します。 パブリック クラウドのフロントエンドからアクセスされた場合、ピーク時の使用状況と、個人を特定できる情報データに対する適切でセキュリティで保護された通信を処理します。
スケーラビリティ
スケーラビリティとは、アプリの負荷の増加を処理するシステムの機能です。これは、アプリのサイズとスコープに加えて、他の要因や強制が対象ユーザーのサイズに影響を与えるので、時間の経過と同時に変化する可能性があります。
この柱の主要な説明については、アーキテクチャの卓越性の 5 つの柱 スケーラビリティ を参照してください。
ハイブリッド アプリの水平スケーリングアプローチでは、需要に合わせてインスタンスを追加し、より静かな期間に無効にできます。
ハイブリッド シナリオでは、個々のコンポーネントをスケールアウトするには、コンポーネントがクラウド間に分散する場合に追加の考慮事項が必要です。 アプリの 1 つの部分をスケーリングするには、別の部分のスケーリングが必要な場合があります。 たとえば、クライアント接続の数が増えても、アプリの Web サービスが適切にスケールアウトされていない場合、データベースの負荷がアプリを飽和させる可能性があります。
一部のアプリ コンポーネントは直線的にスケールアウトできますが、他のコンポーネントにはスケーリングの依存関係があり、スケーリングできる範囲に制限される場合があります。 たとえば、アプリ コンポーネントの場所にハイブリッド接続を提供する VPN トンネルには、スケーリングできる帯域幅と待機時間に制限があります。 これらの要件が満たされるように、アプリのコンポーネントはどのようにスケーリングされますか?
スケーラビリティチェックリスト
スケーリングのしきい値を確認します。 アプリのさまざまな依存関係を処理するには、アプリを実行するための要件を満たしながら、異なるクラウド内のアプリ コンポーネントが互いに独立してスケーリングできる範囲を決定します。 多くの場合、ハイブリッド アプリは、アプリの他の部分と対話して影響を与える機能を処理するために、アプリ内の特定の領域をスケーリングする必要があります。 たとえば、多数のフロントエンド インスタンスを超えると、バックエンドのスケーリングが必要になる場合があります。
スケール スケジュールを定義します。 ほとんどのアプリにはビジー期間があるため、最適なスケーリングを調整するには、ピーク時間をスケジュールに集計する必要があります。
一元化された監視システムを使用します。 プラットフォーム監視機能は自動スケールを提供できますが、ハイブリッド アプリには、システムの正常性と負荷を集計する一元的な監視システムが必要です。 一元化された監視システムでは、ある場所でリソースのスケーリングを開始し、別の場所のリソースに応じてスケーリングを開始できます。 さらに、中央監視システムでは、どのクラウドがリソースを自動スケーリングし、どのクラウドが自動スケーリングしないかを追跡できます。
自動スケール機能を利用する (使用可能な場合)。 自動スケール機能がアーキテクチャの一部である場合は、アプリ コンポーネントをスケールアップ、スケールアウト、ダウン、またはスケールインする必要があるタイミングを定義するしきい値を設定して、自動スケールを実装します。 自動スケールの例として、容量の増加を処理するために 1 つのクラウドで自動スケーリングされるクライアント接続がありますが、異なるクラウドに分散されたアプリの他の依存関係もスケーリングされます。 これらの依存コンポーネントの自動スケール機能を確認する必要があります。
自動スケールを使用できない場合は、一元化された監視システムのしきい値によってトリガーされる手動スケーリングに対応するために、スクリプトやその他のリソースを実装することを検討してください。
場所によって予想される負荷を決定します。 クライアント要求を処理するハイブリッド アプリは、主に 1 つの場所に依存する場合があります。 クライアント要求の負荷がしきい値を超えた場合は、別の場所にリソースを追加して、受信要求の負荷を分散できます。 クライアント接続が増加した負荷を処理できることを確認し、クライアント接続が負荷を処理するための自動化された手順も決定します。
可用性
可用性は、システムが機能し、動作している時間です。 可用性は、アップタイムの割合として測定されます。 アプリのエラー、インフラストラクチャの問題、システム負荷はすべて可用性を低下させる可能性があります。
この柱の主要な説明については、アーキテクチャの卓越性の 5 つの柱 可用性 を参照してください。
可用性チェックリスト
接続の冗長性を提供します。 ハイブリッド アプリでは、アプリが分散しているクラウド間の接続が必要です。 ハイブリッド接続用のテクノロジを選択できます。そのため、主要なテクノロジの選択に加えて、別のテクノロジを使用して、プライマリ テクノロジが失敗した場合に自動化されたフェールオーバー機能を冗長性を提供します。
障害ドメインを分類します。 フォールト トレラント アプリには、複数の障害ドメインが必要です。 障害ドメインは、単一のハード ディスクがオンプレミスで障害が発生した場合、トップ オブ ラック スイッチがダウンした場合、完全なデータセンターが使用できない場合など、障害点を特定するのに役立ちます。 ハイブリッド アプリでは、場所を障害ドメインとして分類できます。 可用性の要件が多いほど、単一の障害ドメインを分類する方法を評価する必要があります。
アップグレード ドメインを分類します。 アップグレード ドメインは、アプリ コンポーネントのインスタンスが使用可能であることを確認するために使用され、同じコンポーネントの他のインスタンスは更新プログラムまたは機能のアップグレードで処理されます。 障害ドメインと同様に、アップグレード ドメインは複数の場所に配置することで分類できます。 アプリ コンポーネントが別の場所でアップグレードされる前に、ある場所でのアップグレードに対応できるか、または他のドメイン構成が必要かを判断する必要があります。 1 つの場所自体に複数のアップグレード ドメインを含めることができます。
インスタンスと可用性を追跡します。 高可用性アプリ コンポーネントは、負荷分散と同期データ レプリケーションを通じて利用できます。 サービスが中断される前にオフラインにできるインスタンスの数を決定する必要があります。
自己復旧を実装します。 問題によってアプリの可用性が中断された場合、監視システムによる検出によって、障害が発生したインスタンスのドレインや再デプロイなど、アプリへの自己復旧アクティビティが開始される可能性があります。 多くの場合、これには、ハイブリッド継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインと統合された中央監視ソリューションが必要です。 アプリは監視システムと統合され、アプリ コンポーネントの再デプロイが必要になる可能性がある問題を特定します。 監視システムでは、ハイブリッド CI/CD をトリガーして、アプリ コンポーネントと、同じ場所または他の場所にある他の依存コンポーネントを再デプロイすることもできます。
サービス レベル アグリーメント (SLA) を維持します。 可用性は、顧客との間のサービスとアプリへの接続を維持するための契約にとって重要です。 ハイブリッド アプリが依存している各場所には、独自の SLA が設定されている場合があります。 これらの異なる SLA は、ハイブリッド アプリの全体的な SLA に影響する可能性があります。
復元
回復性は、ハイブリッド アプリとシステムが障害から回復し、引き続き機能する機能です。 回復性の目標は、障害が発生した後、アプリを完全に機能する状態に戻することです。 回復性戦略には、バックアップ、レプリケーション、ディザスター リカバリーなどのソリューションが含まれます。
この柱の主要な説明については、アーキテクチャの卓越性の 5 つの柱 回復性 を参照してください。
回復性のチェックリスト
ディザスター リカバリーの依存関係を明らかにする。 あるクラウドでのディザスター リカバリーでは、別のクラウドのアプリ コンポーネントの変更が必要になる場合があります。 あるクラウドの 1 つまたは複数のコンポーネントが、同じクラウド内または別のクラウド内の別の場所にフェールオーバーされた場合、依存コンポーネントはこれらの変更を認識する必要があります。 これには、接続の依存関係も含まれます。 回復性には、クラウドごとに完全にテストされたアプリ復旧計画が必要です。
復旧フローを確立します。 効果的な復旧フロー設計では、バッファー、再試行、失敗したデータ転送の再試行、および必要に応じて別のサービスまたはワークフローにフォールバックする機能について、アプリ コンポーネントを評価しました。 使用するバックアップ メカニズム、その復元手順に関係する内容、およびテストされる頻度を決定する必要があります。 増分バックアップと完全バックアップの両方の頻度も決定する必要があります。
部分復旧をテストします。 アプリの一部を部分的に回復すると、すべてが使用できないユーザーに安心感を提供できます。 プランのこの部分では、部分的な復元に、バックアップが行われる前に正常にシャットダウンするためにアプリと対話するバックアップおよび復元サービスなどの副作用がないことを確認する必要があります。
ディザスター リカバリーの開始者を決定し、責任を割り当てます。 復旧計画では、バックアップと復元の対象に加えて、バックアップアクションと復旧アクションを開始できるユーザーとロールを記述する必要があります。
自己復旧のしきい値とディザスター リカバリーを比較します。 自動回復の開始に対するアプリの自己復旧機能と、アプリの自己復旧が失敗または成功と見なされるために必要な時間を決定します。 各クラウドのしきい値を決定します。
回復性機能の可用性を確認します。 各場所の回復性の機能の可用性を決定します。 場所で必要な機能が提供されない場合は、その場所を回復性機能を提供する一元化されたサービスに統合することを検討してください。
ダウンタイムを決定します。 アプリ全体とアプリ コンポーネントのメンテナンスによる予想されるダウンタイムを判断します。
ドキュメントのトラブルシューティング手順。 リソースとアプリ コンポーネントを再デプロイするためのトラブルシューティング手順を定義します。
管理
アーキテクチャの設計では、ハイブリッド アプリの管理方法に関する考慮事項が重要です。 適切に管理されたハイブリッド アプリは、共通の開発パイプラインに一貫性のあるアプリ コードを統合できるコードとしてのインフラストラクチャを提供します。 インフラストラクチャに対する一貫したシステム全体および個別の変更テストを実装することで、変更がテストに合格した場合に統合デプロイを確保し、ソース コードにマージすることができます。
この柱の主要な説明については、アーキテクチャの卓越性の 5 つの柱 DevOps を参照してください。
管理容易性のチェックリスト
監視を実装します。 クラウド全体に分散されたアプリ コンポーネントの一元的な監視システムを使用して、正常性とパフォーマンスの集計ビューを提供します。 このシステムには、アプリ コンポーネントと関連するプラットフォーム機能の両方の監視が含まれます。
監視が必要なアプリの部分を決定します。
ポリシーを調整します。 ハイブリッド アプリがまたがる各場所には、許可されているリソースの種類、名前付け規則、タグ、その他の条件をカバーする独自のポリシーを設定できます。
ロールを定義して使用します。 データベース管理者は、アプリ リソースにアクセスする必要があるさまざまなペルソナ (アプリ所有者、データベース管理者、エンド ユーザーなど) に必要なアクセス許可を決定する必要があります。 これらのアクセス許可は、リソースとアプリ内で構成する必要があります。 ロールベースのアクセス制御 (RBAC) システムを使用すると、アプリ リソースに対してこれらのアクセス許可を設定できます。 これらのアクセス権は、すべてのリソースが 1 つのクラウドにデプロイされているが、リソースがクラウド間に分散されている場合にはさらに注意が必要な場合に困難です。 あるクラウドで設定されたリソースに対するアクセス許可は、別のクラウドで設定されたリソースには適用されません。
CI/CD パイプラインを使用します。 継続的インテグレーションと継続的開発 (CI/CD) パイプラインは、クラウドにまたがるアプリを作成およびデプロイするための一貫したプロセスを提供し、インフラストラクチャとアプリの品質保証を提供できます。 このパイプラインにより、インフラストラクチャとアプリを 1 つのクラウドでテストし、別のクラウドにデプロイできます。 このパイプラインを使用すると、ハイブリッド アプリの特定のコンポーネントを 1 つのクラウドにデプロイし、他のコンポーネントを別のクラウドにデプロイすることも可能になり、基本的にハイブリッド アプリのデプロイの基盤が形成されます。 CI/CD システムは、データベースへの接続文字列を必要とする Web アプリなど、インストール時にアプリ コンポーネントが相互に持つ依存関係を処理するために重要です。
ライフ サイクルを管理します。 ハイブリッド アプリのリソースは複数の場所にまたがることができるため、各場所のライフ サイクル管理機能を 1 つのライフサイクル管理単位に集約する必要があります。 作成方法、更新方法、削除方法を検討します。
トラブルシューティング戦略を確認します。 ハイブリッド アプリのトラブルシューティングには、1 つのクラウドで実行されているのと同じアプリよりも多くのアプリ コンポーネントが含まれます。 クラウド間の接続に加えて、アプリは 1 つではなく 2 つのプラットフォームで実行されています。 ハイブリッド アプリのトラブルシューティングの重要なタスクは、アプリ コンポーネントの正常性とパフォーマンスの監視の集計を調べることです。
安全
セキュリティは、クラウド アプリの主な考慮事項の 1 つであり、ハイブリッド クラウド アプリにとってさらに重要になります。
この柱の主要な説明については、アーキテクチャの卓越性の 5 つの柱 セキュリティ を参照してください。
セキュリティ チェックリスト
侵害を想定します。 アプリの一部が侵害された場合は、同じ場所内だけでなく、複数の場所にまたがって侵害の拡散を最小限に抑えるための解決策が用意されていることを確認します。
許可されたネットワーク アクセスを監視します。 アプリのネットワーク アクセス ポリシー (特定のサブネットからのみアプリにアクセスすることなど) を決定し、アプリが正常に機能するために必要なコンポーネント間の最小ポートとプロトコルのみを許可します。
堅牢な認証を採用する。 堅牢な認証スキームは、アプリのセキュリティにとって重要です。 シングル サインオン機能を提供し、ユーザー名とパスワードのサインオン、公開キーと秘密キー、2 要素認証または多要素認証、信頼されたセキュリティ グループの 1 つ以上のスキームを使用するフェデレーション ID プロバイダーの使用を検討してください。 証明書の種類とその要件に加えて、アプリ認証用の機密データやその他のシークレットを格納するための適切なリソースを決定します。
暗号化を使用します。 データ ストレージやクライアント通信やアクセスなど、暗号化を使用するアプリの領域を特定します。
セキュリティで保護されたチャネルを使用します。 クラウド全体のセキュリティで保護されたチャネルは、クラウド全体でセキュリティと認証のチェック、リアルタイムの保護、検疫、およびその他のサービスを提供するために重要です。
ロールを定義して使用します。 クラウド間でリソース構成と単一 ID アクセスのロールを実装します。 アプリとそのプラットフォーム リソースのロールベースのアクセス制御 (RBAC) 要件を決定します。
システムを監査します。 システム監視では、アプリ コンポーネントと関連するクラウド プラットフォーム操作の両方からデータをログに記録および集計できます。
概要
この記事では、ハイブリッド アプリの作成と設計時に考慮する必要がある項目のチェックリストを示します。 アプリをデプロイする前にこれらの重要な要素を確認すると、運用環境の停止に関するこれらの質問が発生しなくなり、設計を見直す必要が生じる可能性があります。
事前に時間のかかる作業のように思えるかもしれませんが、これらの柱に基づいてアプリを設計すると、投資収益率が簡単に得られます。
次の手順
詳細については、次のリソースを参照してください。
- ハイブリッド クラウド の
- ハイブリッド クラウド アプリ の
- クラウド整合性 用の Azure Resource Manager テンプレートを開発する