最初のAPIにリソース予算と復旧計画を用意しましょう。

これは独立した構築者向けの例示的な計画シナリオであり、顧客事例や測定された容量結果ではありません。このアプリケーションは小規模クラブの備品貸出を記録します：認証されたメンバーは利用可能な備品を確認し、貸出を作成して返却できます。派手なデプロイ図よりも記録が重要であるため、最初の設計では、書き込みの失敗やデータ損失を容易に調査できるようにするべきです。

最小限の有用なアーキテクチャを選択する

1つのAPIプロセス、1つのデータベース、パブリックなHTTPSエンドポイント用のリバースプロキシを使用します。データベースは意図されたローカルまたはプライベート経路を通じてのみ到達可能に保ちます。アプリケーションに独自のOSアイデンティティを与え、必要なファイルへのアクセスを許可します。デプロイファイルを永続データから分離し、リリースがデータベースやアップロードを置き換えないようにします。

インスタンスを共有すると、最初のデプロイメントでは構成と調査が管理しやすくなります。また、コンポーネントが同じ再起動、ディスク、障害の境界に結び付けられます。このトレードオフを意図的に受け入れてください。アプリケーションが独立したリカバリを必要とする場合、またはデータベースがAPIと常に競合する場合は、すべてを一度に増やす前に分離を検討してください。

ピーク時の予算を立てる

アイドル状態のプロセスだけでサイズを決めないでください。以下のワークシートでは、計算を示すために考案された計画許容量を使用しています。これらはこのアプリケーションの測定値、ベンチマーク、最小要件ではありません。代表的なデプロイメントを含め、ランタイムとデータベースからの観察値に置き換えてください。

「 Buildの初期計画 現在は2 vCPU、2 GB RAM、50 GB SSDを指定しています。これらの数値は、このワークシートで調査すべき構成とするものであり、スタックが適合する証明ではありません。カタログのGBとツールのMiB読み取り値は異なる単位です。実際のシステム合計を確認してください。Linuxの使用可能メモリ推定は関連する再利用可能メモリを考慮しているため、空きメモリが少ないだけではサイジングの判断にはなりません。参照： MemAvailableに関するカーネルの説明 および 測定ガイド.

CPUとディスクは別々に決定する必要があります。vCPUを追加する前に、リクエストの所要時間とデータベースの待ち時間を記録します。ディスクは、オペレーティングシステム、保持されるリリース、データベースの増加、ログ、一時的なリカバリ作業のために予算化します。アップロード機能は、小さな構造化レコードとは異なるストレージ問題を生じます。サイズ制限と保持の決定を与えてください。

前払いコストを把握する

以下の例では、デフォルトリソースと継続オプションなしのBuildを使用します。月額小計は$14.00 USDです。値は現在のコンフィギュレーターカタログから生成されるため、価格表はチェックアウトに従います。

半年払いまたは年払いの期間は、同じ月数分の割引なし月額小計を支払う場合と比較して、このカタログの前払い合計を下げます。リソースを追加したり、更新価格を確立したり、未テストのアーキテクチャを適切にしたりするものではありません。コミットできる期間を選択し、確認してください： サービスと請求の詳細、そしてドメイン、外部サービス、ネットワーク手数料のために別途予算を確保してください。

1つの完全なリクエストを検証する

アプリケーションを意図したユーザーに公開する前に、サーバーアクセスとリカバリアクセスを確認し、サポートされているランタイムをインストールし、デプロイするリリースを記録します。サービス定義では、実行可能ファイル、作業ディレクトリ、ランタイムユーザーを特定する必要があります。Systemdの Restart= 設定は指定された障害動作を制御します。再起動ループでも診断が必要です。参照： サービスマニュアル および デプロイのウォークスルー.

まずローカルでテストし、その後別の接続から実際の HTTPS 名でテストします。Caddy では、自動証明書管理は有効な名前設定と機能する検証方法に依存します。一般的な HTTP および TLS-ALPN チャレンジには、それぞれ到達可能な受信ポート 80 と 443 が必要です。参照： Caddy の HTTPS 前提条件。ローカルでの成功は DNS またはプロキシの問題を排除できません。 リクエストパスガイド で説明されています。

アプリケーションのチェックを具体的にします。使い捨ての備品アイテムを作成し、貸し出し、2 回目のリクエストで保存された結果が確認できることを確かめ、返却します。シンプルなヘルスエンドポイントだけでなく認可も確認します。テスト前に期待される応答を記録し、トラブルシューティングで共有するログに認証情報やメンバーデータを含めないようにします。

小規模なリカバリを証明する

データベースをエンジンとリカバリ目標に適した方法でバックアップします。PostgreSQL は論理、ファイルシステム、継続的アーカイブの各アプローチを個別に文書化しています。適切な選択はリカバリの必要性によって異なります。参照： バックアップの概要。備品の写真がアップロードされる場合は、それらのファイルとデータベースレコードとの関係を含めます。

別のテストデータベースとディレクトリへのリストア演習を実行します。既知のアイテムと対応するファイルを見つけ、アプリケーションが両方を読み取れることを確認します。選択したバックアップ、データのタイムスタンプ、必要な手順、実際の結果を書き留めます。 最初のリストアガイド でこの演習を発展させます。オプションのカタログバックアップ選択は、このアプリケーションレベルのリカバリが機能することを証明しません。

証拠から次の決定を下す

測定された動作とリカバリ要件が適合する間は、シンプルな設計を維持します。より大きなプランが答えであると仮定する前に、 停止したアプリケーション または リソース警告 を調査します。サーバーにはマレーシア、ルーマニア、スイスを選択し、リソース割り当て、バックアップ場所、サービスの範囲を確認します。このシナリオは施設、リクエスト容量、配信時間を確立しません。

Build を構成し、すべてのオプションを確認。リンクは開始プランを開きます。続行する前に選択した期間と保存された選択肢を確認してください。支払い詳細の取得は備品貸出アプリケーションをインストールしません。