コアなスタートアップ スタックのアーキテクチャ
大企業で学習する多くの教訓は、スタートアップの最初のスタックには直接適用されません。 製品の最初の 調査 段階では、速度、コスト、 およびオプションのためにデプロイを最適化する必要があります。 オプションとは、特定のアーキテクチャ内で方向を変更できる速度を指します。
製品開発の 展開 フェーズまたは 抽出 フェーズのビジネスでは、サービス指向アーキテクチャまたはマイクロサービス アーキテクチャが使用される場合があります。 この種のデプロイ アーキテクチャは、まだ製品/市場に適していないスタートアップ企業や商用の牽引力をまだ見つけない場合に適していることはほとんどありません。
コア スタートアップ スタックの場合は、単純なモノリシック設計が最適です。 この設計により、インフラストラクチャの管理に費やす時間が制限される一方で、スタートアップ企業がより多くの顧客を獲得するにつれてスケーリングする十分な機能が提供されます。
考えられるユース ケース
この記事では、単純なコア スタートアップ スタックの例を示し、そのコンポーネントについて説明します。
アーキテクチャ
スタートアップの Contoso は、Ruby on Rails バックエンドと TypeScript で記述された React フロントエンドを使用して、アプリケーション プロトタイプを構築しました。 Contoso チームは、ノート PC でデモを実行しています。 次に、最初の顧客営業会議用にアプリをデプロイしたいと考えています。
注
Ruby、React、TypeScript のテクノロジの選択肢は説明にすぎません。 このスタートアップ アーキテクチャは、他の多くの言語やフレームワークにも同様に適用されます。
このアプリは野心的ですが、マイクロサービス駆動型の複雑なアーキテクチャはまだ必要ありません。 Contoso は、推奨されるスタートアップ スタック コンポーネントを含む単純なモノリシック設計を選択しました。
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
このコア スタートアップ スタック アーキテクチャでは、次の手順を実行します。
Azure App Service には、サーバー、ロード バランサー、またはその他のインフラストラクチャを構成せずにスケーラブルなアプリケーションをデプロイするためのシンプルなアプリ サーバーが用意されています。 App Service は、次の例のようにコンテナーデプロイをサポートし、ASP.NET、ASP.NET Core、Java、Ruby、Node.js、PHP、または Python のコンテナーレスデプロイもサポートしています。
Azure Database for PostgreSQL は、最先端のオープンソース リレーショナル データベース管理システム (RDBMS) 用の Azure データベース サービスです。 データベース サーバーを管理するのではなく、アプリケーションの開発に集中できます。
Azure には、 SQL、 MySQL、 MongoDB、 Apache Cassandra、 Gremlin、 Redis 用のマネージド データベース サービスもあります。
Azure Marketplace には、マネージド オファリングに加えて、スタートアップ アーキテクチャで使用されるデータベース ( CockroachDB、 Neon Serverless Postgres、 SQLite など) も含まれています。
Azure Virtual Network は ネットワーク トラフィックをセグメント化し、内部サービスをインターネットの脅威から保護します。 アプリ サーバーは 、仮想ネットワーク統合 を使用して、インターネットに触れることなくデータベースと通信します。
GitHub Actions は、 ソース コード管理への継続的インテグレーションと継続的デプロイ (CI/CD) を構築します。 GitHub Actions には、さまざまな言語に対する広範なサポートと、Azure サービスとの強力な統合が用意されています。
Azure Blob Storage は静的資産を格納し、アプリ サーバーから負荷を移動します。
WAF を使用した Azure Front Door は、グローバル コンテンツ配信ネットワーク (CDN) と Web アプリケーション ファイアウォールを介してユーザーへのコンテンツ配信を高速化し、セキュリティで保護します。
Azure Monitor は 、アプリケーションのインフラストラクチャ全体で何が起こっているかを監視および分析します。
コア スタートアップ スタック コンポーネント
複雑なスタックでは、常に注意が必要なバグが発生する可能性があります。 高度なアーキテクチャでは、製品の構築が損なわれる可能性があります。 バグは複雑さによって引き起こされるわけではありませんが、複雑なスタックにより、バグの発送が容易になります。 すべての洗練されたアーキテクチャがエネルギーの無駄であるわけではありませんが、まだ製品/市場に適合していない場合はリソースを無駄にしています。 最初のスタートアップ スタックはシンプルで、すぐに使用でき、製品開発に集中できます。
次の単純な図は、推奨されるコア スタートアップ スタックを示しています。 これらのコンポーネントは、製品を地面から外し、顧客の手に入れるのに十分です。 スタートアップの 80% の場合、このスタックは、製品に組み込まれている基本的な仮説をテストするために必要なすべてです。 機械学習、モノのインターネット (IoT)、または高度に規制された環境で作業するスタートアップには、より多くのコンポーネントが必要になる場合があります。
CDN
開始時の顧客が少ない場合、CDN は時期尚早に見える可能性があります。 ただし、運用環境に既に存在する製品に CDN を追加すると、予期しない副作用が発生する可能性があります。 CDN を前もって実装することをお勧めします。 CDN は、顧客に近い静的コンテンツをキャッシュし、API とアーキテクチャを反復処理できるファサードを提供します。
アプリ サーバー
コードはどこかで実行する必要があります。 理想的には、このプラットフォームを使用すると、最小限の運用入力を必要としながら、デプロイを簡単にする必要があります。 アプリ サーバーは水平方向にスケーリングする必要がありますが、探索段階にいる間は手動によるスケーリングの介入で問題ありません。
このスタックのほとんどと同様に、アプリ サーバーは基本的にそれ自体を実行する必要があります。 従来、アプリ サーバーは仮想マシンか、ベア メタル サーバーで実行されている Web サーバー インスタンスでした。 これで、上記の App Service やコンテナーなどのサービスとしてのプラットフォーム (PaaS) オプションを確認して、運用上のオーバーヘッドを取り除くことができます。
静的コンテンツ
アプリ サーバーから静的コンテンツを提供すると、リソースが無駄になります。 CI/CD パイプラインを構成したら、リリースごとに静的資産をビルドしてデプロイする作業は簡単です。 ほとんどの運用 Web フレームワークでは、CI/CD を使用して静的資産をデプロイするため、このベスト プラクティスに沿って開始する価値があります。
データベース
アプリが実行されたら、データベースにデータを格納する必要があります。 ほとんどの場合、リレーショナル データベースが最適なソリューションです。 リレーショナル データベースには、複数のアクセス方法と、時間テスト済みソリューションの速度があります。 リレーショナル データベースには、 Azure SQL Database と Azure Database for PostgreSQL が含まれます。 一部のユース ケースでは、 MongoDB や Azure Cosmos DB などのドキュメント データベースまたは NoSQL データベースが必要です。
ログの集計
アプリで問題が発生した場合は、できるだけ少ない時間で問題を診断する必要があります。 ログを集計し、最初からアプリケーション トレースを使用することで、チームが問題自体に集中できるように支援します。 監視データを取得するために、アプリ サーバー上のファイルにアクセスし、ログをポアする必要はありません。
CI/CD
繰り返し可能で迅速なデプロイの欠如は、製品を繰り返す際に速度を低下させる最悪の障害の 1 つです。 適切に構成された CI/CD パイプラインにより、アプリ サーバーでのコードデプロイ プロセスが合理化されます。 迅速かつ簡単なデプロイは、作業の結果をすばやく確認することを意味します。 頻繁に統合すると、マージの競合につながる異なるコード ベースが回避されます。 概念と手法は、 Dockerfile を使用してビルドするほとんどのプロジェクトで同じです。
貢献者達
この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。
主要著者:
- Andrew Harvey |CTO とスタートアップ アドボケイト
その他の共同作成者:
- ニック・ウォード |クラウド ソリューション アーキテクト