クラウド アプリケーション (SaaS) の設計方法

クラウド アプリケーション (SaaS) の設計方法

クラウド アプリケーション (SaaS) の設計方法
SaaS (Software as a Service) は、多くのソフトウェア ベンダーにとって主流のモデルとなっています。クラウドベンダーがインフラストラクチャサービスを提供するのと同様に、ソフトウェアの提供にも役立ちます。 SaaS アプリケーションは通常、Amazon Cloud (AWS)、Microsoft Azure、Google Cloud などのパブリック クラウドに導入されます。ただし、組織が自社のデータ センター (プライベート クラウドとも呼ばれます) を使用して SaaS アプリケーションをホストし、インフラストラクチャへの投資を活用することを選択する場合もあります。 SaaS アプリケーションを設計する場合、アプリケーション ビットをクラウドにデプロイするだけではありません。適切な設計上の考慮事項は、優れた設計を実現するだけでなく、コストを削減し、展開をより効率的に管理するのにも役立ちます。この記事では、私が長年にわたり役に立ってきた、SaaS アプリケーションの設計に関する重要な考慮事項とヒントをいくつか紹介します。

クラウド向けのアプリケーションの設計は、オンプレミス向けのアプリケーションの設計とどう違うのでしょうか?
モジュール性の向上: 大規模なモノリシック アプリケーションがある場合は、個別に展開できる論理コンポーネントに分割できるかどうかを確認するのが賢明です。これにより、モジュール性が向上するだけでなく、アプリケーションのフットプリントを削減するのにも役立ちます。バックグラウンド ジョブを使用してデータを更新するアプリケーションがあるとします。コア アプリケーションとバックグラウンド ジョブを 2 つ (またはそれ以上) のコンポーネントに分離し、個別にデプロイすることができます。これにより、コア アプリケーションのフットプリントが削減されます。したがって、より小さいリソース サイズを選択する必要があるかもしれません。さらに、必要に応じてこれら 2 つを個別にスケーリングすることもできます。したがって、バックグラウンドジョブの需要が増加した場合、その容量を増やすことができ、アプリケーション層の容量を増やすことができます。リソースあたりのリソース量が少ないため、必要なレイヤー/コンポーネントのみをスケーリングすると、リソース全体をスケーリングした場合よりも全体的なコストが低くなります。意味が分かりますか?

アプリは常に最新です。これは多くのネイティブ アプリにとって大きな変化です。クラウドでは、顧客は通常、アプリケーションが常に最新の状態であることを期待します。これをアーキテクトとして考えると、アプリケーション ビットを更新できるだけでなく、顧客を関与させずに顧客データをアップグレードできることを意味します。つまり、彼らにとっては完全に透明です。

これらは違いのほんの一部です。しかし、その考えは理解できるでしょう。

SaaS の設計上の重要な考慮事項
· 適切なクラウド サービスを選択する: もちろん、クラウドに展開します。しかし、どのサービスを利用したいですか? Infrastructure as a Service (IaaS) だけを使用するつもりですか?あるいは、Platform as a Service (PaaS) 機能を活用したいですか?答えは必ずしも単純ではないかもしれません。ここにいくつかのガイドラインを示します。

同じアプリケーションを複数のクラウドまたはオンプレミスにデプロイしますか?この場合、クラウド ベンダー固有のサービスは一切使用せず (または最小限に抑え)、IaaS サービスに固執することが合理的である可能性があります。

· サービスを選択する際には、コストを重要な考慮事項とする必要があります。たとえば、クラウド ベンダーによって管理されている一部の PaaS サービスは、コストを削減するためにチーム自身で管理できます。これはすべてのサービスに当てはまるわけではないかもしれませんが、検討する価値はあります。

· チームの専門知識を念頭に置いてください。クラウド サービスを利用するには何が必要ですか?また、チームがインフラストラクチャの保守も行う場合は、どのようなスキルが必要ですか?

障害を考慮した設計: フォールト トレランスと高可用性を考慮したアプリケーションの設計は、クラウドの基盤です。アプリケーションに問題が発生することを想定して、ユーザーへのサービス提供を継続できるようにする方法を説明します。これらは、アプリケーション障害またはインフラストラクチャ障害である可能性があります。クラウドベンダーは、ユーザーを支援する便利な機能をいくつか提供しています。

ロード バランサーを使用する: 負荷分散の目的で、アプリケーション ノードをロード バランサーの背後に配置し、1 つ以上のノードがダウンした場合でも、他のノードによってアプリケーションが処理されるようにすることができます。

· 地理的に分散されたアプリケーション: 多くのクラウド プロバイダーは、複数の地理的領域にアプリケーションを分散する機能を提供しているため、1 つの領域が影響を受けた場合でも (たとえば、自然災害により)、他の領域からアプリケーションを提供できます。たとえば、AWS は複数のアベイラビリティーゾーンにわたるアプリケーションのデプロイをサポートしています。

アプリケーションをモジュール化します。前のセクションで説明したように、個別にデプロイおよび管理できるコンポーネントを分離すると、アプリケーションのフットプリントが削減され、インフラストラクチャ コストが削減されます。これらのコンポーネントの一部をマイクロサービスにすることも検討できます。マイクロサービス アプローチは、アプリケーションの外部に他の潜在的な消費者がいる場合に特に役立ちます。ただし、これは、不要なコンポーネントをすべて作成するという意味ではありません。したがって、1 つのアプローチは、個別にデプロイできるコンポーネント (コア アプリケーションとバックグラウンド ジョブなど) を作成することです。

セキュリティ: セキュリティは、インフラストラクチャの保護からアプリケーションまで、さまざまな側面をカバーします。重要な側面としては、必要なポートのみが開いていることを確認すること、リソースに対して可能な限り最小限の権限を使用すること、適切なロールベースのアクセス制御を実施すること、暗号化を使用することなどが挙げられます。セキュリティは、1 回限りの取引として考えるべきではありません。これは継続的なプロセスであり、時間の経過とともに改善および開発される必要があります。

マルチテナント: クラウドで実行する主な利点の 1 つは、同じアプリケーション インスタンスを使用して複数の顧客にサービスを提供できることです。これにより、セキュリティと規制上の目的で各顧客のデータが分離されることを保証するアプリケーション設計にいくつかの明らかな課題が生じます。一部のチームでは、顧客ごとに個別のデータベースを使用するなど、顧客ごとに異なる永続ストレージ インスタンスを使用することを選択します。また、行レベルの識別子を使用してデータを分離することを選択する人もいます。どのようなアプローチを採用する場合でも、アーキテクチャがスケーラビリティとセキュリティの要件を満たしていることを確認することが重要です。たとえば、顧客ごとに 1 つのデータベースを使用することを選択した場合、単一の RDS インスタンスで複数のデータベースをホストできます。また、容量が不足した場合は、別の RDS インスタンスを立ち上げることができます。

ゼロ/最小限のダウンタイムとシームレスなアップグレード: 信じられないかもしれませんが、多くの顧客は SaaS アプリケーションのダウンタイムがゼロまたは最小限であることを期待しており、これらのダウンタイムはアプリケーションを構築した同じ会社によって管理されることが多いため、アップグレードはシームレスである必要があります。問題は、特に SaaS アプリケーションに変換された場合、アプリケーションがアップグレードをスムーズに処理するように設計されていない可能性があることです。考慮すべき重要な側面は 2 つあります: a) アプリケーション ビットとファイルの展開、b) 永続ストレージのアップグレードの処理。アプリケーション ビット戦略を展開する場合、ブルー/グリーン展開などの戦略を使用できます。ブルー/グリーン展開では、展開が成功した場合、新しいバージョンが新しいスタックに展開され、テストされ、有効化されます。古いスタック リソースは廃止して後で再利用できます。シームレスなアップグレードを実現する 1 つの方法は、基盤となるデータ モデルを n_1 互換にすることです。つまり、展開するリリースにデータ モデル バージョン n がある場合、そのデータ モデルは以前のデータ モデル バージョン (n - 1) と下位互換性があり、アップグレードによってデータが壊れることはありません。それをどうやって保証するのですか?これには、開発サイクル全体を通じて規律を守り、列を削除しない、データ移行のニーズに対応するために必要なアップグレード スクリプトを提供するなどの特定のガイドラインに従うことが必要です。また、アップグレードが成功しなかった場合は、アップグレードのロールバックがサポートされます。これで、データの移行とロールバックが伴うため技術的に難しいだけでなく、展開が大幅に遅くなる可能性があることがおわかりいただけたと思います。したがって、アプリケーションのニーズに適したオプションを慎重に評価し、それに応じてソリューションを実装する必要があります。

SaaS における DevOps の考慮事項
DevOps は SaaS にとって非常に重要なので、それについて別途議論する価値があります。重要な考慮事項をいくつか示します。

継続的デリバリー: DevOps パイプラインは、チェックインされたコードを取得してビルドを生成し、さまざまな段階 (QA、パフォーマンス、最終的な合否チェック、本番環境への展開) を自動的に実行できる必要があります。これには、複数のパイプライン (通常はステージごとに 1 つ) と、各ステージにビルドをプッシュするためのスーパー パイプラインが必要になる場合があります。これらのパイプラインの開発には多少時間がかかるかもしれませんが、ユーザー パイプラインが詳細を気にしなくても済むように、各パイプラインの契約の定義を開始することをお勧めします。最終的な目標は、手を邪魔するものから完全に解放するか、できる限り邪魔するものに近づけることです。

DevOps の変更を含むすべてのリリースにバージョン管理を使用します。アプリケーション コードの場合、通常はソース管理のマスター ブランチを使用するのが最適です。ただし、DevOps の変更についても同様に同じことを行うことが重要です。たとえば、インフラストラクチャの変更を展開する場合、それらの変更もソース管理にチェックインし、テストしてから、本番環境にプッシュする必要があります。

アジャイル インフラストラクチャ: SaaS で成功するには、インフラストラクチャがアジャイルであり、需要の変化に対応できることを確認する必要があります。需要が増加すると適切な層をスケールアップし、需要が減少すると不要なリソースを解放します。適切なバランスをとるには、ある程度の実験とテストが必要です。たとえば、AWS の自動スケーリングを使用して、インフラストラクチャを自動的にスケールアップ/スケールダウンできます。

SaaSに関するその他の考慮事項
計画と優先順位付け: 他の成功するプロジェクトと同様に、SaaS プロジェクトには計画と優先順位付けが必要です。誰もが「すべてのチェックを本番環境に導入する」などの目標を達成したいと考えていますが、何が最も意味のあることかを理解し、重要なことを優先することが重要です。もちろん、ストレッチゴールを設定することは何も悪いことではありません。ただし、まずは重要なことを正しく理解することが重要です。たとえば、適切なユニット テストと自動化の範囲がなく、すべてのコード変更を本番環境にプッシュしようとすると、変更が完了したとしても、その有用性は疑わしいものになります。これが逆効果になる理由は、生産中のものがすぐに壊れ始め、R&D チームが消耗してしまう可能性があるためです。

· 収益化モデル: SaaS は収益化モデルにも影響します。オンプレミスでは、一定数のライセンスに対してペナルティが課せられる可能性がありますが、SaaS では、ビジネスに最適なモデルを再考する必要があるかもしれません。サブスクリプションベースのモデル、利用ベースのモデル、ハイブリッド モデル、それともまったく別のモデルを使用する予定ですか?

クラウドベースまたは SaaS アプリケーションの設計について理解が深まったと思います。さまざまな関係者が関与するアプリケーションが実稼働状態になるのを見るのは、確かに充実した経験です。私がいつも言っているように、「クラウドは目的地ではなく旅なのです」。だから学び続けて、進化し続けてください。