ハイブリッドアプリの設計上の考慮事項

[アーティクル]
06/21/2023

Microsoft Azure は、一貫性のある唯一のハイブリッドクラウドです。これにより、開発への投資を再利用でき、グローバル Azure、Azure のソブリンクラウド、およびデータセンター内の Azure の拡張機能である Azure Stack にまたがるアプリを使用できるようになります。クラウドをまたぐアプリは "ハイブリッドアプリ" とも呼ばれます。

「Azure アプリケーションアーキテクチャガイド」には、スケーラブルで回復力がある高可用性のアプリを設計するための体系化された方法が示されています。「Azure アプリケーションアーキテクチャガイド」で説明されている考慮事項は、単一のクラウド向けに設計されたアプリや、クラウドをまたがるアプリにも同様に適用されます。

この記事は、Azure アプリケーションアーキテクチャガイドで説明されているソフトウェア品質の要点を補強するもので、特にハイブリッドアプリの設計に重点を置いています。また、ハイブリッドアプリは 1 つのクラウドや 1 つのオンプレミスデータセンターに限定されないため、要点として "配置" を追加しています。

ハイブリッドシナリオは、開発で使用できるリソースによって大きく異なり、地理、セキュリティ、インターネットアクセスなど、考慮事項は多岐にわたります。このガイドでは、特定の考慮事項を列挙することはできませんが、従うべきいくつかの重要なガイドラインとベストプラクティスを紹介します。ハイブリッドアプリアーキテクチャの設計、構成、展開、および保守を正常に行うには、本質的に知られていない可能性がある多くの設計上の考慮事項に対応する必要があります。

このドキュメントでは、ハイブリッドアプリを実装するときに発生する可能性のある課題を集約し、それらを扱うための考慮事項 (これらの要点) とベストプラクティスについて説明します。設計段階でこれらの課題に対処することで、運用環境で発生する可能性がある問題を回避できます。

基本的に、ハイブリッドアプリを作成する前に、次の課題について考慮する必要があります。開始するには、次のことを行う必要があります。

アプリコンポーネントを特定して評価する。
アプリコンポーネントを要点に照らして評価する。

アプリコンポーネントを評価する

アプリの各コンポーネントには、大規模なアプリ内での固有の役割があるため、設計上のすべての考慮事項を検討する必要があります。各コンポーネントの要件と機能は、アプリのアーキテクチャの決定に役立つように、これらの考慮事項に対応している必要があります。

アプリのアーキテクチャを調べ、その構成要素を確認することによって、アプリをコンポーネントに分解します。コンポーネントには、アプリが対話する他のアプリを含めることもできます。コンポーネントを識別する際には、次の質問を行い、その特性に従って、目的のハイブリッド操作を評価します。

コンポーネントの目的は何ですか?
コンポーネント間にはどのような依存関係がありますか?

たとえば、アプリではフロントエンドとバックエンドを 2 つのコンポーネントとして定義できます。ハイブリッドシナリオでは、フロントエンドは一方のクラウドにあり、バックエンドはもう一方のクラウドにあります。アプリは、フロントエンドとユーザーの間、およびフロントエンドとバックエンドの間の通信チャネルを提供します。

アプリコンポーネントは、さまざまな形式とシナリオで定義されます。最も重要なタスクは、それらとそのクラウドまたはオンプレミスの場所を特定することです。

インベントリに含める共通のアプリコンポーネントを表 1 に示します。

表 1 共通のアプリのコンポーネント

コンポーネント	ハイブリッドアプリのガイダンス
クライアント接続	アプリ (任意のデバイス上にあるもの) は、単一のエントリポイントから、次のような方法を含むさまざまな方法でユーザーにアクセスできます。 - アプリを操作するためにクライアントをインストールすることをユーザーに要求するクライアント/サーバーモデル。ブラウザーからアクセスされるサーバーベースのアプリ。 - クライアント接続には、接続が切断されたときの通知や、ローミング料金が適用される可能性がある場合のアラートを含めることができます。
認証	認証は、アプリに接続しているユーザー、または別のコンポーネントに接続しているコンポーネントに対して必要になる場合があります。
API	開発者に対し、API セットとクラスライブラリを使用したアプリへのプログラムによるアクセスを提供し、インターネット標準に基づく接続インターフェイスを提供できます。 API を使用して、アプリを独立して動作する論理ユニットに分解することもできます。
サービス	簡潔なサービスを使用して、アプリの機能を提供することができます。サービスは、アプリが実行されているエンジンである場合があります。
キュー	キューを使用して、ライフサイクルの状態とアプリのコンポーネントの状態を整理できます。これらのキューは、メッセージング、通知、およびバッファリング機能をサブスクライブ側に提供できます。
データストレージ	アプリは、ステートレスまたはステートフルにすることができます。ステートフルアプリには、さまざまな形式とボリュームで対応できるデータストレージが必要です。
データキャッシュ	設計のデータキャッシュコンポーネントは、待機時間の問題に戦略的に対処し、クラウドバースティングをトリガーする役割を果たします。
データインジェスト	データはさまざまな方法でアプリに送信でき、ユーザーが Web フォームで送信した値や、継続的な大量のデータフローなどがあります。
データ処理	データ処理タスク (レポート、分析、バッチエクスポート、データ変換など) は、ソースで処理したり、データのコピーを使用して別のコンポーネントにオフロードしたりできます。

要点に対してアプリコンポーネントを評価する

各コンポーネントについて、各要点に照らしてその特性を評価します。すべての要点を使用して各コンポーネントを評価すると、検討していなかった可能性がある課題を知ることができ、このことがハイブリッドアプリの設計に影響を与えます。これらの考慮事項に対応することによって、アプリを最適化する上で価値を高めることができる場合もあります。表 2 に、ハイブリッドアプリに関連する各要点の説明を示します。

表 2 要点

要点	説明
配置	ハイブリッドアプリにおけるコンポーネントの戦略的な位置づけ。
スケーラビリティ	増加した負荷を処理するシステムの能力です。
可用性	ハイブリッドアプリが動作し実際に使用可能である時間の割合です。
回復性	ハイブリッドアプリの回復能力です。
管理の容易性	運用環境でシステムを継続的に動作させる運用プロセスです。
セキュリティ	脅威からハイブリッドアプリとデータを保護することです。

配置

ハイブリッドアプリには、データセンターなど、配置に関する考慮事項が本質的にあります。

配置は、ハイブリッドアプリに最適なサービスを実行できるように、コンポーネントを配置する重要なタスクです。定義上、ハイブリッドアプリは、オンプレミスからクラウドや、異なるクラウド間など、さまざまな場所にまたがります。アプリのコンポーネントをクラウドに配置するには、次の 2 つの方法があります。

垂直ハイブリッドアプリ
アプリコンポーネントは、複数の場所に分散されます。個々のコンポーネントは、1 つの場所にのみ存在する複数のインスタンスを持つことができます。
水平ハイブリッドアプリ
アプリコンポーネントは、複数の場所に分散されます。個々のコンポーネントは、複数の場所にまたがる複数のインスタンスを持つことができます。

コンポーネントの中には、それぞれの場所を認識しているものもあれば、場所や配置について認識していないものもあります。この効果的なやり方は、抽象化レイヤーを使用して実現できます。このレイヤーは、マイクロサービスのような最新のアプリフレームワークを使用することで、クラウド全体のノード上で動作するアプリコンポーネントの配置によってアプリがどのように処理されるかを定義できます。

配置のチェックリスト

必要な場所を確認します。 アプリまたはそのいずれかのコンポーネントが、特定のクラウドで動作する必要があるか、または特定のクラウドの認定を必要としていないか確認します。これには会社や法律で定めるデータ主権要件が含まれる場合があります。また、特定の場所またはロケールに対してオンプレミスの操作が必要かどうかを確認します。

接続の依存関係を確認します。 必要な場所とその他の要因によって、コンポーネント間の接続の依存関係が決まります。コンポーネントを配置する際は、それらのコンポーネント間の通信に最適な接続とセキュリティを確認します。選択肢として、VPN、ExpressRoute、およびハイブリッド接続があります。

プラットフォームの機能を評価します。 アプリコンポーネントごとに、アプリコンポーネントに必要なリソースプロバイダーがクラウドで利用可能かどうか、および帯域幅が予想されるスループットと待機時間の要件を満たすことができるかどうかを確認します。

移植性を計画します。 コンテナーやマイクロサービスのような最新のアプリフレームワークを使用して、移行操作を計画し、サービスの依存関係を防ぎます。

データ主権要件を確認します。 ハイブリッドアプリは、ローカルデータセンターなどのデータの分離に対応するように調整されています。リソースの配置を確認して、この要件にうまく対応するように最適化します。

待機時間を計画します。 クラウド間の運用により、アプリコンポーネント間に物理的な距離が生じることがあります。待機時間に対応するための要件を確認します。

トラフィックフローを制御します。 パブリッククラウドのフロントエンドからアクセスされるときに、ピーク時の使用量に対応し、個人を特定できる情報データに対して適切かつ安全な通信を行います。

スケーラビリティ

スケーラビリティとは、アプリのサイズと範囲に加えて、他の要因や影響力が対象ユーザーのサイズに影響することが原因で時間の経過と共に変化することがあるアプリの負荷の増加に対処するための、システムの能力のことです。

この要点の主要な説明については、優れたアーキテクチャの 5 つの要素にある "スケーラビリティ" を参照してください。

ハイブリッドアプリの水平スケーリングアプローチを使用すると、需要を満たすためにインスタンスを追加し、需要が減った期間にそれらを無効にすることができます。

ハイブリッドシナリオでは、コンポーネントが複数のクラウドに分散している場合、個々のコンポーネントのスケールアウトには追加の考慮が必要です。アプリのある部分を拡大縮小するには、別の部分の拡大縮小が必要になることがあります。たとえば、クライアント接続数が増加しても、アプリの Web サービスが適切にスケールアウトされていない場合、データベースの負荷によってアプリが飽和状態になる可能性があります。

アプリコンポーネントの中には、直線的にスケールアウトできるものもあれば、スケーリング依存関係を持ち、拡張できる範囲が限られているものもあります。たとえば、アプリコンポーネントの場所にハイブリッド接続を提供する VPN トンネルでは、拡大縮小が可能な帯域幅と待機時間に制限があります。これらの要件を満たすようにするために、アプリのコンポーネントはどのようにスケーリングされるでしょうか?

スケーラビリティのチェックリスト

スケーリングしきい値を確認します。 アプリのさまざまな依存関係を処理するために、アプリを実行するための要件を満たしながら、異なるクラウド内のアプリコンポーネントが互いに独立してどの程度拡大縮小できるかを確認します。ハイブリッドアプリでは多くの場合、ある機能がアプリの他の部分と相互作用して影響を与えるため、その機能を処理するためにアプリの特定の領域を拡大縮小する必要があります。たとえば、フロントエンドインスタンスの数を超えると、バックエンドのスケーリングが必要になる場合があります。

スケールスケジュールを定義します。 ほとんどのアプリには使用量が多くなる期間があるので、最適なスケーリングを調整するには、ピーク時間を集約してスケジュールに入れる必要があります。

集中監視システムを使用します。 プラットフォームの監視機能は自動スケーリングを提供できますが、ハイブリッドアプリには、システムの正常性と負荷を集約する集中監視システムが必要です。集中監視システムでは、ある場所のリソースのスケーリングと、別の場所のリソースに応じたスケーリングを開始できます。さらに、中央監視システムは、どのクラウドがリソースを自動スケーリングし、どのクラウドが自動スケーリングしないかを追跡できます。

自動スケール機能を活用します (使用可能な場合)。 自動スケーリング機能がアーキテクチャの一部である場合は、アプリコンポーネントをスケールアップ、スケールアウト、スケールダウン、またはスケールインする必要があるタイミングを定義するしきい値を設定することによって、自動スケーリングを実装します。自動スケーリングの例としては、容量の増加に対応するために 1 つのクラウドで自動スケーリングされるクライアント接続が挙げられますが、異なるクラウドに分散されているアプリのその他の依存関係もスケーリングされる場合もあります。これらの依存コンポーネントの自動スケール機能を確認する必要があります。

自動スケーリングが使用できない場合は、集中監視システムのしきい値によってトリガーされる、手動スケーリングに対応するためのスクリプトやその他のリソースを実装することを検討してください。

場所別に予想される負荷を確認します。 クライアント要求を処理するハイブリッドアプリは、主に 1 つの場所に依存することがあります。クライアント要求の負荷がしきい値を超えると、別の場所にさらにリソースを追加して、受信要求の負荷を分散することができます。クライアント接続が増加した負荷を処理できるようにし、クライアント接続が負荷を処理する自動化された手順も確認します。

可用性

可用性とは、システムが動作し実際に使用可能である時間です。可用性は、アップタイムの割合として測定されます。アプリエラー、インフラストラクチャの問題、システムの負荷はすべて、可用性を低下させる可能性があります。

この要点の主要な説明については、優れたアーキテクチャの 5 つの要素にある "可用性" を参照してください。

可用性のチェックリスト

接続の冗長性を提供します。 ハイブリッドアプリでは、アプリが分散しているクラウド間の接続が必要です。ハイブリッド接続のためのテクノロジを選択できるため、主要なテクノロジの選択に加えて、主要なテクノロジに障害が発生した場合に備えて、自動フェールオーバー機能によって冗長性を提供する別のテクノロジを使用します。

障害ドメインを分類します。 フォールトトレラントなアプリでは、複数の障害ドメインが必要です。障害ドメインは、障害の発生点を特定するのに役立ちます。たとえば、オンプレミスの 1 つのハードディスクに障害が発生した、ラックの最上位スイッチがダウンした、またはデータセンター全体が使用できない、などがあります。ハイブリッドアプリでは、場所を障害ドメインとして分類できます。可用性の要件が増えるにつれて、1 つの障害ドメインを分類する方法を評価する必要性が高まります。

アップグレードドメインを分類します。 アップグレードドメインは、アプリコンポーネントのインスタンスが更新または機能アップグレードで処理されているときに、同じコンポーネントの別のインスタンスを使用できるようにするために使用されます。障害ドメインと同様に、アップグレードドメインは複数の場所への配置によって分類できます。アプリコンポーネントが、ある場所でアップグレードされる前に、別の場所でのアップグレードに対応できるか、または他のドメイン構成が必要かどうかを確認する必要があります。単一の場所に複数のアップグレードドメインを含めることができます。

インスタンスと可用性を追跡します。 高可用性アプリコンポーネントは、負荷分散と同期データレプリケーションを通じて利用できます。どれだけのインスタンスをオフラインにしたらサービスが中断されるかを確認する必要があります。

自己復旧を実装します。 問題によってアプリの可用性が中断される場合、監視システムによる検出によって、障害が発生したインスタンスのドレインや再デプロイなど、アプリに対する自己復旧アクティビティが開始される可能性があります。ほとんどの場合、これにはハイブリッド継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインと統合された中央監視ソリューションが必要です。アプリは、アプリコンポーネントの再デプロイが必要になる可能性がある問題を特定するために監視システムと統合されます。また、監視システムはハイブリッド CI/CD をトリガーして、アプリコンポーネントを再デプロイでき、場合によっては、同じ場所または他の場所にあるその他の依存コンポーネントを再デプロイすることもできます。

サービスレベルアグリーメント (SLA) を維持します。 可用性は、お客様と顧客の間にあるサービスとアプリへの接続を維持するために、どのような契約においても不可欠です。ハイブリッドアプリが使用する場所ごとに、独自の SLA が適用される場合があります。これらのさまざまな SLA は、ハイブリッドアプリの全体的な SLA に影響を与える可能性があります。

回復性

回復性とは、障害から回復して動作を続行する、ハイブリッドアプリおよびシステムの能力です。回復性の目的は、障害の発生後にアプリを十分に機能する状態に戻すことです。回復性戦略には、バックアップ、レプリケーション、ディザスターリカバリーなどのソリューションが含まれます。

この要点の主要な説明については、優れたアーキテクチャの 5 つの要素にある "回復性" を参照してください。

回復性のチェックリスト

ディザスターリカバリーの依存関係を明らかにします。 あるクラウドでのディザスターリカバリーに、別のクラウドのアプリコンポーネントへの変更が必要になる場合があります。あるクラウドの 1 つまたは複数のコンポーネントが同じクラウド内または別のクラウド内の別の場所にフェールオーバーされた場合、依存コンポーネントにこれらの変更を認識させる必要があります。これには接続の依存関係も含まれます。回復性を確保するには、各クラウドに対して完全にテストされたアプリの復旧計画が必要です。

復旧フローを確立します。 効果的な復旧フロー設計では、バッファーへの対応、再試行、失敗したデータ転送の再試行、および必要に応じて別のサービスまたはワークフローへのフォールバックを行う能力について、アプリコンポーネントを評価しました。使用するバックアップメカニズム、復元手順に含まれるもの、テストの頻度を確認する必要があります。また、増分バックアップと完全バックアップの両方の頻度を確認する必要があります。

部分的な回復をテストします。 アプリの一部の部分的な回復により、すべての部分が使用できないわけではないという安心感をユーザーに与えることができます。計画のこの部分では、部分復元に副作用がないことを確認する必要があります。たとえば、バックアップと復元サービスがアプリとやり取りし、バックアップを行う前にアプリを適切にシャットダウンすることなどがあります。

ディザスターリカバリーを開始する人を確認して責任を割り当てます。 復旧計画では、何をバックアップおよび復元できるかに加えて、バックアップおよび回復操作を開始できるユーザーとロールを記述する必要があります。

自己復旧のしきい値をディザスターリカバリーと比較します。 自動復旧を開始するためのアプリの自己復旧機能と、アプリの自己復旧が失敗または成功と見なされるまでに必要な時間を確認します。各クラウドのしきい値を確認します。

回復性機能の可用性を確認します。 各場所の回復性機能および能力の可用性を確認します。ある場所で必要な機能が提供されない場合、回復性機能を提供する集中管理されているサービスにその場所を統合することを検討してください。

ダウンタイムを確認します。 アプリ全体について、およびアプリコンポーネントとしての、メンテナンスに起因する予想されるダウンタイムを確認します。

ドキュメントのトラブルシューティング手順。 リソースおよびアプリンコンポーネントの再デプロイのトラブルシューティング手順を定義します。

管理の容易性

ハイブリッドアプリの管理方法に関する考慮事項は、アーキテクチャの設計に不可欠です。適切に管理されたハイブリッドアプリは、共通の開発パイプラインで一貫したアプリコードを統合できるようにするための、コードとしてのインフラストラクチャを提供します。インフラストラクチャの変更に対して一貫したシステム全体および個別のテストを実装することにより、変更がテストに合格した場合は統合されたデプロイを保証でき、それらをソースコードにマージすることができます。

この要点の主要な説明については、優れたアーキテクチャの 5 つの要素にある DevOps を参照してください。

管理容易性のチェックリスト

監視を実装します。 クラウドに分散されたアプリコンポーネントの集中監視システムを使用して、正常性とパフォーマンスの集約されたビューを提供します。このシステムには、アプリコンポーネントと関連するプラットフォーム機能の両方の監視が含まれています。

監視を必要とするアプリの部分を確認します。

ポリシーを調整します。 ハイブリッドアプリがまたがるそれぞれの場所には、許可されているリソースの種類、名前付け規則、タグ、およびその他の条件を網羅する独自のポリシーを設定できます。

ロールを定義して使用します。 データベース管理者は、アプリリソースにアクセスする必要があるさまざまなペルソナ (アプリ所有者、データベース管理者、エンドユーザーなど) に必要なアクセス許可を確認する必要があります。これらのアクセス許可は、リソースに対して、およびアプリ内で構成する必要があります。ロールベースのアクセス制御 (RBAC) システムを使用すると、これらのアクセス許可をアプリリソースに設定できます。これらのアクセス権は、すべてのリソースが 1 つのクラウドにデプロイされるときには困難ですが、リソースがクラウドをまたいで分散されている場合はさらに注意が必要です。あるクラウド内で設定されたリソースのアクセス許可は、別のクラウド内で設定されたリソースには適用されません。

CI/CD パイプラインを使用します。 継続的インテグレーションと継続的開発 (CI/CD) パイプラインを使用すると、クラウド全体にまたがるアプリを作成およびデプロイするための一貫したプロセスを提供し、インフラストラクチャとアプリの品質を保証できます。このパイプラインにより、あるクラウドでインフラストラクチャとアプリをテストし、別のクラウドにデプロイできるようになります。また、このパイプラインを使用すると、ハイブリッドアプリの特定のコンポーネントをあるクラウドにデプロイし、別のコンポーネントを別のクラウドにデプロイでき、基本的にハイブリッドアプリ展開の基盤を形成することもできます。 CI/CD システムは、データベースへの接続文字列が必要な Web アプリなど、インストール中にアプリコンポーネントが相互に持つ依存関係を処理するために不可欠です。

ライフサイクルを管理します。 ハイブリッドアプリのリソースは複数の場所にまたがる可能性があるため、それぞれの場所のライフサイクル管理機能を 1 つのライフサイクル管理単位に集約する必要があります。それらの作成、更新、および削除の方法を検討してください。

トラブルシューティング戦略を検討します。 ハイブリッドアプリのトラブルシューティングには、1 つのクラウドで実行されている同じアプリよりも多くのアプリコンポーネントが含まれます。クラウド間の接続に加えて、アプリは 1 つではなく 2 つのプラットフォームで実行されます。ハイブリッドアプリのトラブルシューティングにおける重要なタスクは、アプリコンポーネントの正常性とパフォーマンスの総合的な監視を調べることです。

セキュリティ

セキュリティは、クラウドアプリの主要な考慮事項の 1 つであり、ハイブリッドクラウドアプリにとってはさらに重要になります。

この要点の主要な説明については、優れたアーキテクチャの 5 つの要素にある "セキュリティ" を参照してください。

セキュリティチェックリスト

セキュリティ侵害を想定します。 アプリの一部が侵害された場合は、同じ場所だけでなく、複数の場所にわたる侵害の拡散を最小限に抑えるためのソリューションが用意されていることを確認します。

許可されたネットワークアクセスを監視します。 アプリのネットワークアクセスポリシーを決定します。たとえば、特定のサブネットからのみアプリにアクセスし、アプリが正常に機能するために必要なコンポーネント間の最低限のポートとプロトコルのみを許可するなどです。

堅牢な認証を採用します。 堅牢な認証方式は、アプリのセキュリティにとって重要です。シングルサインオン機能を提供し、ユーザー名とパスワードでのサインオン、公開キーと秘密キー、2 要素認証または多要素認証、信頼されたセキュリティグループのうち 1 つ以上のスキームを使用するフェデレーション ID プロバイダーを使用することを検討してください。証明書の種類と要件に加えて、アプリ認証のための機密データやその他のシークレットを格納するための適切なリソースを決定します。

暗号化を使用する。 データストレージやクライアントの通信やアクセスなど、アプリのどの領域で暗号化を使用するかを特定します。

セキュリティで保護されたチャネルを使用します。 セキュリティで保護されたクラウドをまたがるチャネルは、セキュリティと認証のチェック、リアルタイム保護、検疫、およびその他のサービスをクラウド全体で提供するために不可欠です。

ロールを定義して使用します。 リソース構成とクラウド間での単一 ID アクセスのためのロールを実装します。アプリとそのプラットフォームリソースに対するロールベースのアクセス制御 (RBAC) の要件を決定します。

システムを監査します。 システムの監視では、アプリコンポーネントと、関連するクラウドプラットフォーム操作の両方からデータをログに記録し、集計できます。

まとめ

この記事では、ハイブリッドアプリの作成および設計時に考慮する必要がある重要な項目のチェックリストを示しています。アプリをデプロイする前にこれらの要点を確認することで、運用の停止時にこれらの課題に直面して、設計を再検討する必要が生じる事態を回避することができます。

これは時間のかかる事前の作業のように思えるかもしれませんが、これらの要点に基づいてアプリを設計すれば、投資に見合う価値を簡単に得ることができます。

次のステップ

詳細については、次のリソースを参照してください。

ハイブリッド アプリの設計上の考慮事項

アプリ コンポーネントを評価する