この記事では、コンピューティング、ネットワーク、ストレージ、コンテナー、データという5つの基盤となるプラットフォームの柱について、スタートアップの視点から簡潔に紹介します。 各柱について、状況を既定のサービスにマップする短い意思決定テーブルに加えて、スタートアップのスケールに合わせてその選択を再検討するタイミングに関するメモを取得します。
この記事では、次の方法について説明します。
- ステージに適したAzureコンピューティング、ネットワーク、ストレージ プリミティブを選択します。
- Azure Kubernetes Serviceがステージに適したコンテナー プラットフォームであるかどうかを判断し、そうでない場合は代わりに何を使用するかを決定します。
- リレーショナル、ドキュメント、ベクター、分析の各ワークロードにわたる最初のデータ プラットフォームを選択します。
- 成長しても通用する、コスト、信頼性、セキュリティに関する少数の標準設定を適用します。
- 既定の選択肢がその有用性を上回っていることを示すシグナルを認識します。
前提条件
- 有効な Azure サブスクリプション。
- Azure CLIがインストールされ、サインインされています。 サインインするには、
az loginを実行します。 - 少なくとも 1 つのリソース グループに対する所有者または共同作成者アクセス。
- Azure ポータルのランディング ページに関する知識は役に立ちますが、必須ではありません。
- Azureの基礎 (リージョン、サブスクリプション、リソース グループ) に関する基本的な知識。
スタートアップ企業にとってこれが重要な理由
初期段階のスタートアップでは、間違ったインフラストラクチャの選択のコストは課金されません。 間違ったサービスを前提に構築してしまった後でそこから移行することになり、1週間を無駄にすることです。 この記事の 5 つの柱は、既定の選択が不適切に複合する傾向がある要素です。間違ったコンピューティング プラットフォームによってデプロイ パイプラインが構成されます。間違ったデータベースによってデータ モデルが制約されます。間違ったネットワーク トポロジによって、最初のエンタープライズ顧客がブロックされます。 これらの選択を適切に行うために、プラットフォーム チーム、サイト信頼性エンジニア、または財務運用スペシャリストは必要ありません。 出荷するのに十分な既定値と、再訪するタイミングを示す明確なシグナルが必要です。 スタートアップが Microsoft for Startups プログラムに含まれている場合、同じ既定値でクレジットがさらに拡張され、後で高度な特典を受けることができます。
コンピューティング: コードが実行される場所
Azureには、12 を超えるコンピューティング サービスがあります。 良いニュース:ほとんどの初期段階のワークロードでは、そのうちの3つが必要なものをカバーしています。
| あなたの状況 | 既定のAzure サービス | なぜでしょうか | 再確認するタイミング |
|---|---|---|---|
| Web アプリまたは HTTP API(1 つまたは 2 つのサービス)、マネージド ランタイムが必要 | Azure App Service (Linux) | コンテナーのビルドは必要ありません。 組み込みの TLS、カスタム ドメイン、デプロイ スロット、自動スケーリング。 Free プランと Basic プランはステージング環境を運用するのに十分安価ですが、スロットと自動スケールを利用するには Standard 以上が必要です。 | 少数を超える数のサービスを実行する必要がある場合、サービスごとのスケーリングが必要な場合、またはサイドカーが必要な場合。 |
| イベント駆動型関数、スケジュールされたジョブ、またはWebhookハンドラー | Azure Functions (従量課金プラン) | 実行ごとに支払います。 0 にスケーリングします。 バインドにより、キュー、BLOB、および HTTP トリガーのほとんどのグルー コードが削除されます。 | コールドスタートは、ユーザー向けの待機時間に悪影響を及ぼすか、従量課金プランの制限を超えることになります。 |
| コンテナー化されたマイクロサービス。Kubernetes を管理せずに、承認されたランタイムが必要です | Azure Container Apps | KEDA ベースの自動スケーリングを使用して Kubernetes 上に構築されていますが、クラスターは管理しません。 Dapr はオプションの統合として使用できます。 ゼロスケール、リビジョン、HTTPS イングレス機能が含まれます。 | クラスター レベルの制御、カスタム スケジューラ、または高度なネットワークが必要です。 |
| 実行時間の長いバッチ、GPU トレーニング、または既存の仮想マシン ワークロードのリフト アンド シフト | Azure 仮想マシン | オペレーティング システムの完全な制御。 水平スケールが必要な場合は、仮想マシン スケール セットを使用します。 | 修正プログラムの適用とイメージ管理の運用上のオーバーヘッドにより、出荷が遅くなり始めます。 |
| Kubernetes が必要であることを確認します (これを想定する前に、セクション 4 を参照してください) | Azure Kubernetes サービス | マネージド コントロール プレーン。 Kubernetes のエクスペリエンスまたは特定のプラットフォーム要件を既に持っているチームに適しています。 | AKS の決定基準については、「コンテナー」セクションを参照してください。 |
Tip
最初のユーザー向け Web アプリには App Service を、イベント駆動のものすべてには Azure Functions を使いましょう。 アプリケーションをステートレスに保ち、環境変数に構成を書き込む場合は、アプリケーション コードを変更せずに後でAzure Container AppsまたはAzure Kubernetes Serviceに移動できます。
Container Apps と App Service の選択
Container Apps と App Service が重複しています。 正直なタイブレーカー:アプリケーションが既にコンテナー イメージとして実行されており、サービスごとのスケール (worker と比較して Web 層の異なるレプリカ) が必要な場合は、Container Apps が優先されます。 アプリケーションが単一の Web プロセスであり、Dockerfile を維持したくない場合は、App Service が優先されます。
Caution
より単純なオプションで満たされていない明確な要件がある場合は、Azure Kubernetes Serviceを検討してください。 強力な柔軟性と制御を提供しますが、追加の運用上の考慮事項 (アップグレード、ノード プールのサイズ設定、イングレス構成、証明書管理など) も導入されています。 採用が早すぎる場合、多くの場合、チームは製品機能を構築するよりもプラットフォーム管理に時間を割きます。
ネットワーク: 1 日目に設定する内容
初期段階のほとんどのAzureワークロードでは、1 日目に仮想ネットワークは必要ありません。 App Service、Functions、Container Apps、およびほとんどのマネージド データベースでは、認証を正しく設定している限り、公開しても安全な TLS を使用するパブリック エンドポイントが提供されます。 理由を持つ前にネットワークの複雑さを追加することは、Azureの最も一般的な早期最適化です。
| あなたの状況 | 既定のアプローチ | なぜでしょうか | 再確認するタイミング |
|---|---|---|---|
| まったく新しいアプリ、パブリック Web トラフィック、コンプライアンス要件がまだない | TLS でパブリック エンドポイントを使用します。 仮想ネットワークがありません。 | 運用上のオーバーヘッドが最も少ない。 App Service、Container Apps、およびマネージド データベースが TLS を処理します。 認証には Microsoft Entra ID を使用します。 | 最初のエンタープライズ顧客は、プライベート接続を要求します。 |
| アプリとマネージド データベースの間にプライベート接続が必要です | コンピューティング側の仮想ネットワーク統合、データベース側のプライベート エンドポイント | トラフィックはMicrosoftのバックボーンにとどまります。 データベースの公開なし。 同じマネージド サービス。アプリケーションは変更されません。 | 保護されたデータを処理する場合は 1 日目。それ以外の場合は、監査または顧客が要求したとき。 |
| ルーティング、TLS 終了、および Web アプリケーション ファイアウォールで複数のバックエンドの前に配置する 1 つのパブリック エントリ ポイントが必要です | Azure Front Door (グローバル) または Azure Application Gateway (地域) | Front Door は、グローバル コンテンツ配信ネットワークとエッジ キャッシュを追加します。 Application Gateway は、リージョンの仮想ネットワークネイティブ オプションです。 | App Service に組み込まれた TLS とルーティングでは足りなくなりました。 |
| 送信静的 IP アドレス (支払プロセッサの許可リストなど) が必要です | 仮想ネットワークに接続されている NAT ゲートウェイ | 予測可能な送信 IP。 多くのサードパーティ API に必要です。 | ベンダーがそれを必要としています。 投機的に追加しないでください。 |
| マルチリージョントポロジまたはマルチアカウント トポロジ | 仮想ネットワーク ピアリング または Azure Virtual WAN | 実際のネットワーク アーキテクチャはここから始まります。 ほとんどの Explore-stage チームの対象外です。 | マルチリージョンは、願望ではなく、実際の要件です。 |
Important
ネットワークの分離を心配する前に、Microsoft Entra ID とサブスクリプションのロール割り当てを厳格に保護してください。 小規模企業のAzureセキュリティ インシデントのほとんどは、ネットワークの露出ではなく、過剰に許可された ID から発生します。 エンジニア向けアクセスには Microsoft Entra ID グループを使用し、サブスクリプション スコープでは Owner ロールを付与しないでください。
ストレージ: BLOB、ファイル、ディスク
Azure Storageは、BLOB、ファイル、キュー、テーブルの 4 つのデータ サービスを公開する単一のリソースの種類 (ストレージ アカウント) です。 アプリケーション ストレージの決定では、ほとんどの場合、BLOB (オブジェクト ストレージ)、ファイル (マネージド ファイル共有)、およびマネージド ディスク (仮想マシンに接続されているブロック ストレージ) を選択します。
| 保存する内容 | 既定のAzure サービス | なぜでしょうか | 再確認するタイミング |
|---|---|---|---|
| ユーザーがアップロードしたファイル、生成されたレポート、ログ、モデル成果物、バックアップ | Azure Blob Storage (ホット 層) | オブジェクト ストレージ。 安価で耐久性があり、ペタバイト単位でスケーリングできます。 あまり読まないデータには、後でクール層またはアーカイブ層を使用します。 | POSIX ファイル セマンティクスまたは複数のマシンから 1 つのファイルへのランダムな読み取り/書き込みが必要です。 |
| 複数の仮想マシンまたはコンテナーによってマウントされた共有ファイル システム | Azure Files (Standard) または Azure NetApp Files (高スループット) | サーバー メッセージ ブロック (SMB) またはネットワーク ファイル システム (NFS) 共有ボリューム。 BLOB モデルに適合するコンテンツには、これらを使用しないでください。 | ファイル共有をキューまたはデータベースとして使用し始めます。 右のプリミティブに移動します。 |
| 仮想マシンのディスク | プレミアム SSD v2 マネージドディスク | 調整可能なパフォーマンス、アプリケーション ディスクの優れた価格パフォーマンス。 Premium SSD v2 を OS ディスクとして使用することはできません。は、OS 用の Premium SSD (v1) または Standard SSD とペアリングします。 Standard SSD は、スループットの低いワークロードでも許容されます。 | 仮想マシン間で共有ブロック ストレージが必要です (Azure Elastic SAN または Azure NetApp Files を使用します)。 |
| 静的な Web サイト資産 (シングルページ アプリケーション バンドル、マーケティング サイト、ドキュメント) | Azure Storage 静的 Web サイト ホスティング + Azure Front Door | Static Web Appsは最新の既定値です。組み込みのカスタム ドメイン、無料のマネージド TLS、グローバル配布、GitHub Actions CI/CD、組み込み認証です。 ストレージ静的 Web サイト + Front Door は、非常に低コストのセットアップでは引き続き機能しますが、カスタム ヘッダーや認証はネイティブでサポートされません。 | サーバーでレンダリングされたページを追加します。 App Service またはコンテナー アプリに移動します。 |
Note
ストレージ アカウントのソフト制限は、サブスクリプションあたりリージョンあたり 250 です (要求によって 500 に設定できます)。 これは、初期段階のチームには十分です。 回避する間違いは、マイクロサービスごとに 1 つのストレージ アカウントを作成することです。代わりに、環境 (運用、ステージング、開発) およびアクセス パターン (ホット、コールド、アーカイブ) ごとにグループ化します。
バックアップに関するメモ
Azure Backup ストレージ アカウントの冗長性オプション (ローカル冗長ストレージ、ゾーン冗長ストレージ、geo 冗長ストレージ) は、アカウントごとおよびディスクごとに調整可能です。 ローカル冗長ストレージ (LRS) は、開発とステージングに適しています。 運用データにはゾーン冗長ストレージ (ZRS) を使用します。 geo 冗長ストレージではコストが追加され、アプリケーション レベルのディザスター リカバリーの代わりではありません。
コンテナーとAzure Kubernetes Service
Azureには、運用環境でコンテナーを実行する方法として、Azure Container Apps、Azure Container Instances、Azure Kubernetes Serviceの 3 つがあります。 それらは、異なるチーム規模や運用上の許容度に対応しています。
| あなたの状況 | 既定のAzure サービス | なぜでしょうか | 痛み始めるとき |
|---|---|---|---|
| コンテナー イメージがあり、HTTPS イングレス、ゼロへのスケール、リビジョンを含むマネージド ランタイムが必要です | Azure Container Apps | KEDA 自動スケーリングを使用する Kubernetes 上のサーバーレス プラットフォームですが、クラスターは表示または管理されません。 実行内容に対して支払います。 クラスター レベルの要件に達するまでは適しています。 Dapr はオプトイン統合として利用できます。 | カスタム スケジューラ、高度なネットワーク (複数のネットワーク インターフェイス カード、カスタム Container Network Interface プラグイン)、または特定の Kubernetes オペレーターが必要です。 |
| 単一のコンテナーを単発ジョブまたは短時間のバッチ処理として実行したい場合 | Azure Container Instances | イメージから実行中のコンテナーへの最速のパス。 オーケストレーションなし。 ランタイムの 1 秒あたりに課金されます。 | 単一コンテナーを超えて、サービスメッシュやオートスケーリングのようなものが必要です。 |
| すでに他の環境で Kubernetes を運用している、またはアプリケーション アーキテクチャがそれを本当に必要としている | Azure Kubernetes サービス | マネージド コントロール プレーン。 独自のノード プール、ネットワーク プラグイン、イングレス コントローラー、および可観測スタックを持ち込みます。 | 1 日目。 継続的なアップグレード (4 か月ごとにリリースされるマイナー バージョン)、ノード プールのチューニング、および証明書の管理を計画します。 |
| Kubernetes が必要かどうかわからない | 現時点では Container Apps | 必要に応じて、後でAzure Kubernetes Serviceでリビルドできます。 ステートレスコンテナー化されたアプリケーションの持ち上げは、数週間ではなく数日の作業です。 | 具体的なニーズ (オペレーター エコシステム、クラスター レベルのポリシー) に名前を付けることができます。 「将来の実証」は具体的なニーズではありません。 |
AKS を卒業するタイミング
Azure Kubernetes Service (AKS) に移動します(これらのうち少なくとも 2 つが該当する場合)。
- 共有ライフサイクルとネットワークに関する懸念がある 10 を超えるサービスを実行している。
- Container Apps で公開されていないカスタム コントローラー、サイドカー、またはカスタム リソース定義 (CRD) が必要です。
- 厳密なポリシー適用を使用して、仮想ネットワークを深く統合する必要があります。
- Kubernetes ベースのオープンソース エコシステム (Argo、Istio、KEDA など) を標準化しています。
AKS を採用する場合は、AKS ベースライン アーキテクチャに従います。 Microsoft Azure Well-Architected Framework と AKS ベースラインリファレンスは、必要なセキュリティ、スケーリング、アップグレードの既定値をまとめたものになっています。
小規模なチーム向けの AKS の既定設定
| Setting | Default | なぜでしょうか |
|---|---|---|
| ノード サイズ | Standard_D4s_v5 システム プール、Standard_D8s_v5 ユーザー プール | 一般的なワークロードの予測可能な価格対パフォーマンス |
| クラスターオートスケーラー | 有効 | 未使用のノードへの課金を避ける |
| ワークロードアイデンティティ | 有効 | ポッド ID を置き換え、Microsoft Entra IDと統合します |
| Azure Policy アドオン | 有効 | フリー ガードレール (特権コンテナーなし、必要なラベル) |
| コンテナーの分析情報 | 有効 | Azure Monitorのファーストクラスのメトリックとログ |
| プライベート クラスター | 運用環境の場合はオン | VNet からのみ到達可能なコントロール プレーン |
Azure Container Registry
選択したコンピューティング プラットフォームに関係なく、イメージを Azure Container Registry に格納します。 Basic レベルは、初期段階のチームには十分です。 ハード分離が必要な場合は、環境ごとに個別のレジストリ (運用環境、ステージング) を使用し、シンプルにする場合は個別のリポジトリとロールベースのアクセス制御を備えた 1 つのレジストリを使用します。
データ プラットフォーム: リレーショナル、ドキュメント、ベクター、分析
データ プラットフォームの決定は、永続的である可能性が最も高い決定です。 最初の1か月目にリリースするスキーマは、その後2年間のあらゆる機能を形作ります。 製品と共に成長するのに十分な柔軟性を備えた既定値を選択し、まだ構築していない機能の特殊なデータベースを事前に選択する誘惑に抵抗します。
| ワークロード | 既定のAzure サービス | なぜでしょうか | 再確認するタイミング |
|---|---|---|---|
| 既知のリレーショナル スキーマを持つトランザクション アプリケーション データ (ユーザー、注文、コンテンツ) | Azure Database for PostgreSQL (フレキシブル サーバー) | 成熟した、広く理解されている強力な拡張エコシステム (埋め込み用の pgvector を含む)。 バースト可能な階層は、開発環境とステージング環境には十分安価です。 | マルチリージョン書き込みまたはハイパースケール読み取りパターン。 PostgreSQL のAzure Cosmos DBを検討してください。 |
| スキーマに柔軟な運用データ、グローバル分散、予測可能な 1 桁ミリ秒の読み取り | Azure Cosmos DB (NoSQL API) | 既定では複数リージョン。 サーバーレスのプランは、使い始めるのに十分安価です。 パーティションの設計が重要です。発送する前に、パーティション キーのガイダンスをお読みください。 | アプリケーション レイヤーを介してリレーショナル結合を強制します。 PostgreSQL はおそらく正しい答えです。 |
| 検索拡張生成を含む、構造化されたコンテンツと非構造化コンテンツを検索する | Azure AI 検索 | ハイブリッド キーワードとベクター検索。 Azure OpenAI Serviceおよび Cosmos DB と統合されます。 プロトタイプ作成用の Free レベルが存在します。 | レベルごとのインデックス制限を超えています (Standard 1 は一般的なアップグレード ポイントです)。 |
| 検索拡張生成機能のベクター埋め込み | PostgreSQL または Azure AI 検索 で pgvector から始める | 取得機能の最初のバージョンでは、別のベクター データベースを使用しないでください。 実際に必要なもの (フィルター処理、ハイブリッド検索、スケーリング) を実際の使用状況から学習します。 | 読み取りパターンを明確にしたうえで、制約から専用エンジンの採用が妥当だと判断しました。 |
| 運用データに対する分析、レポート、およびアドホック クエリ | Azure Database for PostgreSQL の読み取りレプリカ (参照)、Microsoft Fabric (拡張と抽出) | ほとんどの探索ステージ分析には、読み取りレプリカで十分です。 Microsoft Fabricは、その拡張後の最新の分析プラットフォームです。 | 読み取りレプリカが負荷に追いつけない、あるいはビジネス部門の関係者がセルフサービス型の分析基盤を必要としている。 |
| データベースの前のキャッシュ レイヤー | Azure Cache for Redis (Basic レベル) | 標準キャッシュ プリミティブ。 後で追加するのが安い。投機的に追加しないでください。 | データベースを飽和状態にしている明確なホット読み取りパターンが表示されます。 追加する前に測定します。 |
Important
既定のデータベースを 1 つ選択し、可能な限りそのデータベースを維持します。 PostgreSQL、Cosmos DB、Redis、AI Search、キュー、グラフ データベースを 15 人のエンジニアで実行するチームが、プラットフォーム チームの価値のある作業を誤って購入しました。
Azure OpenAI Serviceが適合する場所
Azure OpenAI Serviceはデータ プラットフォームではありませんが、同じ決定のリズムを共有します。 生成型 AI 機能を構築するほとんどのスタートアップは、1 つのリージョンに 1 つのモデル デプロイ (最近のチャット完了モデル) に加えて、取得用の AI Search または pgvector から始まります。 実際の利用状況から追加が必要だと分かるまでは、専用の微調整パイプライン、モデルゲートウェイ、または複数のデプロイメントを用意する必要はありません。
この記事で扱う内容 (および取り扱わないもの)
| トピック | この記事で | 追加するタイミング |
|---|---|---|
| 基本以外の ID とアクセスの管理 | いいえ | Microsoft Entra IDセットアップの 1 日目。 情報セキュリティ レビュー時の条件付きアクセスと特権 ID 管理 |
| コードとしてのインフラストラクチャ (Bicep、Terraform) | いいえ | ポータルへの手動変更によって、環境間でずれが生じ始める場合。 通常、ステージングを追加する時間の前後です。 |
| 継続的インテグレーションと継続的デプロイメント パイプライン | いいえ | 1 日目。 GitHub ActionsまたはAzure DevOpsパイプラインはどちらも問題ありません。 |
| 可観測性 (ログ、メトリック、トレース) | いいえ | 最初から Application Insights。 アラートの疲労が発生したときにブックをAzure Monitorします。 |
| コスト管理 | いいえ | 1 日目にサブスクリプション レベルの予算を設定します。 最初からリソースに環境と所有者をタグ付けします。 |
| コンプライアンス (SOC 2、ISO 27001、HIPAA) | いいえ | 顧客が要求したとき。 Microsoft Defender for Cloudには、コントロールをAzure リソースにマップするコンプライアンス ダッシュボードがあります。 |
| ディザスター リカバリーとマルチリージョン | いいえ | 1 時間のダウンタイムのコストが、2 番目のリージョンのエンジニアリング コストを超えた場合。 |
プラットフォームの既定値が足りなくなった場合
これらの増加シグナルは、特定の既定値に、より意図的な置換が必要であることを示しています。
- App Service または Container Apps に 5 つ以上の異なるサービスをデプロイしており、サービスごとのスケールが日々の懸念事項になっています。 Azure Kubernetes Serviceを見てください。
- 毎月のAzure請求書は、2 か月連続で毎月の収益よりも速く増加しています。 Cost Management の見直しと、リザーブド インスタンスまたは Savings Plan の分析を行う時期です。
- 仮想ネットワークが複数のサブスクリプションまたはリージョンにまたがるようになりました。 Azure Virtual WANとハブ アンド スポーク トポロジを見てください。
- 1 つの PostgreSQL インスタンスがワーキング セットをメモリに保持できないので、読み取りレプリカはギャップを埋められません。 Cosmos DB for PostgreSQL またはシャード化されたアーキテクチャを調べてみます。
- 運用データベースに対する分析クエリは、アプリケーションの待機時間に大きく影響しています。 分析をMicrosoft Fabricに移動します。
- 同じアクセス パターンに対して、環境ごとに 2 つ以上のストレージ アカウントを実行しています。 統合。
- 有料の顧客が含まれた第 3 の国を追加しました。 次は、第2リージョン、地理冗長ストレージ、Front Door のルーティング戦略を評価する段階です。
Note
エンタープライズ プラットフォーム ツールを早期に導入する誘惑に抵抗します。 前述のパターン（サービスメッシュ、複数リージョンのアクティブ/アクティブ、FinOpsツール、カスタム Kubernetes オペレーター）のほとんどは、運用の複雑さを増すものであり、そのコストに見合うのは大規模運用になってからです。 それらを維持できるチームが整ってから追加してください。それまでは追加しないでください。
参照チェックリスト
これは、Azureの最初の 6 か月間、月に 1 回実行されます。 これは、最も一般的なドリフトを検出します。
- 環境ごとに 1 つのサブスクリプション (運用、ステージング、開発)、または環境ごとに厳密なリソース グループを持つ 1 つのサブスクリプション。 混在しないでください。
- すべてのリソースには、環境、所有者、コスト センターがタグ付けされます (コスト センターが現在のすべてに同じ値である場合でも)。
- Cost Management の月次目標の 50%、80%、100% のアラートを含むサブスクリプション レベルの予算。
- リソース グループに対するロールの割り当ては、個人ユーザーではなく、Microsoft Entra ID グループに付与されます。 サブスクリプション スコープに永続的な所有者は存在しません。
- Application Insights またはAzure Monitorは、すべての運用コンピューティング リソースで有効になります。
- 運用データベースのバックアップは、文書化された復元テスト (少なくとも 1 回) によって検証されます。
- シークレットは、アプリケーション構成ではなく、Azure Key Vaultにあります。 コンピューティング先のKey-Vault パスにはマネージド ID を使用します。
- コンテナー イメージがスキャンされます (Microsoft Defender for Containers またはレジストリの組み込みスキャナー)。