大企業で学習する多くのレッスンは、スタートアップ企業の最初のスタックにそのまま応用できるわけではありません。 製品の最初の探索ステージでは、スピード、コスト、"オプション性" を考慮してデプロイを最適化する必要があります。 オプション性とは、特定のアーキテクチャ内でどれだけ迅速に方向転換できるかを意味します。
製品開発の拡大または抽出フェーズの業務では、サービス指向アーキテクチャまたはマイクロサービス アーキテクチャを使用する場合があります。 この種類のデプロイ アーキテクチャは、プロダクト マーケット フィットや商業的けん引力がまだ見つかっていないスタートアップ企業にはあまり適していません。
コアなスタートアップ スタックには、単純なモノリシック設計が最適です。 この設計では、インフラストラクチャの管理に費やされる時間を制限し、スタートアップ企業が獲得する顧客が増えるにつれて十分なスケーリングを行えるようにします。
考えられるユース ケース
この記事では、単純でコアなスタートアップ スタックの例を紹介し、そのコンポーネントについて説明します。
Architecture
Contoso というスタートアップ企業では、TypeScript で記述された Ruby on Rails バック エンドと React フロント エンドを使用して、アプリケーション プロトタイプを構築しました。 Contoso チームは、ノート PC でデモを実行しています。 現在は、最初の顧客の販売会議用のアプリをデプロイしたいと考えています。
Note
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、MariaDB、MongoDB、Apache Cassandra、Gremlin、Redis 用のマネージド データベース サービスもあります。
- 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、Azure Database for MariaDB があります。 一部のユース ケースには、ドキュメント データベースまたは NoSQL データベース (MongoDB やAzure Cosmos DB など) が必要です。
ログの集計
アプリで問題が発生した場合は、できるだけ短い時間で問題を診断したいと考えます。 ログを集計し、最初からアプリケーション トレースを使用すれば、チームは問題自体に集中できます。 監視データを取得するために、アプリ サーバー上のファイルにアクセスしてログを収集する必要はありません。
CI/CD
反復可能で迅速なデプロイができないことは、製品を繰り返し使用する際のスピードを妨げる最も悪い障害の 1 つです。 適切に構成された CI/CD パイプラインにより、アプリ サーバー上でのコードのデプロイ プロセスが効率化されます。 すばやく簡単にデプロイできるので、作業の結果をすぐに確認できます。 頻繁に統合することで、マージの競合につながる異なるコード ベースを回避できます。 概念と手法は、Dockerfile を使用してビルドするほとんどのプロジェクトで同じです。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Andrew Harvey | CTO およびスタートアップ アドボケイト
その他の共同作成者:
- Nick Ward | クラウド ソリューション アーキテクト