ソリューションとテクノロジーで成功への道筋をつけることができます。Cloudお客様のビジネス全体に役立つ、わかりやすい料金体系です。安全でインテリジェントなプラットフォームを使って今すぐ始めましょう。プロダクトをお試しいただけます。|.NETこのガイドでは、スタンダード環境に慣れているユーザーのためのフレキシブル環境を紹介します。それぞれの環境の類似点と重要な相違点を説明し、両方の環境を使用するアプリケーションにおすすめの一般的なアーキテクチャを紹介します。スタンダード環境で使用可能なサービスをフレキシブル環境の類似サービスにマッピングするには、スタンダード環境からフレキシブル環境へのサービスの移行をご覧ください。インフラストラクチャは、両方の環境で提供されます。重要な違いは、環境がアプリケーションを実行する方法、アプリケーションが外部サービスにアクセスする方法、アプリケーションをローカルで実行する方法、アプリケーションのスケーリング方法です。これらの違いの概要については、環境の選択でも確認できます。アプリケーションの実行スタンダード環境では、アプリケーションはサンドボックス内の軽量なインスタンスで実行されます。このサンドボックスでは、アプリケーションにできることが制限されます。ライブラリを使用したりすることはできません。メモリ量のオプションが制限されます。アプリケーションとなる傾向があります。コンテナで実行されます。任意のプログラミング言語の使用、ディスクへの書き込み、任意のライブラリの使用、さらに複数プロセスの実行が可能です。アクセスできるようにすることができます。サービスにアクセスします。ライブラリを使用します。ライブラリはどこでも使用できるので、アプリケーションのポータビリティが高まります。使用してローカルで実行します。サービスをエミュレートします。アプリケーションとして記述する必要があります。コンテナで実行されるだけです。ローカルでアプリケーションをテストするには、アプリケーションを直接実行することになります。実行すればよいのです。サービスを使用します。ローカルでのテストには別のプロジェクトを使用し、可能な場合にはエミュレータを使用してください。インフラストラクチャを使用しますが、スケーリングの方法は異なります。個のインスタンスから数千のインスタンスまで素早くスケーリングできます。なければならず、トラフィックに応じてスケーリングするのに時間がかかる場合があります。アルゴリズムが使用されます。オートスケーラーを使用します。オプションをサポートしているわけではありません。デベロッパーは、さまざまな条件下でアプリケーションの動作をテストする必要があります。バウンドになった場合、自動スケーリングがどのように応答するかを確認する必要があります。ヘルスチェックスタンダード環境では、インスタンスにトラフィックを送信するかどうかの決定にヘルスチェックは使用されません。ハンドラを作成できます。これはロードバランサによって、トラフィックをインスタンスに送信するかどうかや自動修復を行うかどうかの決定に使用されます。デベロッパーは、ヘルスチェックにロジックを追加する際に注意する必要があります。ヘルスチェックによって外部サービスを呼び出し、そのサービスで一時的な障害が発生すると、すべてのインスタンスが異常になり、カスケード障害が発生する可能性があります。過負荷時のリクエストのドロップカスケード障害を回避するための戦略の一環として、過負荷時にアプリケーションへのリクエストをドロップできます。レイヤに組み込まれています。非常に高いアプリケーションを開発する場合は、同時リクエストの数を制限して過負荷トラフィックをドロップする機能をアプリケーションに組み込むことをおすすめします。フレキシブル環境のアプリケーションがこのタイプの障害の影響を受けないことを確認するには、最大インスタンス数を制限したバージョンを作成します。その後、リクエストがドロップされるまで、トラフィックを徐々に増やします。アプリケーションが過負荷時にヘルスチェックに失敗しないことを確認する必要があります。フィルタを構成できます。アプリによって同時処理されるクエストの最大数と、この機能によってリクエストがキュー内に入っている時間の長さを設定できます。メモリの上限をスタンダード環境のインスタンスよりも高く設定できます。多く消費するアプリケーションを実行できます。単一インスタンス内のスレッド数が増加するため、同時実行に関するバグの発生する可能性が高くなります。接続してスレッドダンプを取得することで、このタイプの問題のトラブルシューティングを実施できます。秒のリクエスト期限が設けられています。プログラマーは、リクエストが無期限にハングアップして最終的にウェブサーバー上のすべてのスレッドが使い尽くされることを避けるために、外部サービスに対するすべての呼び出しでタイムアウトを確実に指定するように注意する必要があります。フィルタを実装できます。スレッドの強制終了時には、クリーンアップを適切に処理することが重要です。作成されたスレッドだけです。スレッドのライブラリを使用するように切り替える必要があります。非常に多くのスレッドを必要とするアプリケーションの場合、スレッドを明示的に作成するよりも、スレッドプールを使用したほうが効率的に実行される可能性があります。トラフィックの移行スタンダード環境には、レイテンシの急増を最小限に抑えるために、新しいバージョンへのトラフィックの移行を徐々に行うトラフィック移行機能が用意されています。トラフィックを新しいバージョンに切り替える際にレイテンシの急増を確実に回避する方法については、トラフィックの移行に関するドキュメントをご覧ください。単一ゾーンの障害スタンダード環境のアプリケーションはシングルホームです。アプリケーションのインスタンスはすべて、単一の可用性ゾーンに存在します。そのゾーンで障害が発生した場合、アプリケーションは新しいインスタンスを同じリージョン内の別のゾーンで起動し、ロードバランサはトラフィックを新しいインスタンスにルーティングします。フラッシュにより、レイテンシが一時的に急増します。グループを使用します。インスタンスはリージョン内の複数の可用性ゾーンに分散されます。単一のゾーンに障害が発生した場合、ロードバランサはそのゾーンへのトラフィックのルーティングを停止します。インスタンスを可能な限りホットな状態で実行するように自動スケーリングを設定している場合は、自動スケーリングによってインスタンスがさらに作成される前に、短時間の過負荷状態が発生します。費用の比較スタンダード環境とフレキシブル環境で実行されるワークロードの費用の比較には、さまざまな要因が関係します。ごとに支払われる料金。プラットフォーム機能。ごとに実施できる作業に影響します。インスタンスを各プラットフォームでどれだけホットな状態で実行できるか。プラットフォームごとに異なる可能性があり、またアプリケーションに継続的デプロイを使用している場合は高額になる可能性があります。実行時のオーバーヘッド。各プラットフォームでのワークロードの費用を決定するには、実験を行う必要があります。スタンダード環境では、アプリケーションのコスト効率に関するリアルタイム指標を取得できるメカニズムは用意されていません。日の請求サイクルが完了するのを待つ必要があります。ヘッダーを使用してアプリケーション間の安全な認証を行うことができます。フレキシブル環境にそのような機能はありません。使用をおすすめします。デプロイ一般に、スタンダード環境でのデプロイはフレキシブル環境でのデプロイよりも短時間で済みます。フレキシブル環境での既存バージョンのスケールアップは、新しいバージョンのデプロイよりも迅速に行えます。プログラミングは通常、フレキシブル環境でのデプロイにおけるボトルネックとなるためです。フレキシブル環境で迅速なロールバックを行うための戦略のひとつに、正常稼働した実績のあるバージョンを単一インスタンスにスケールダウンして維持しておく、という方法があります。しておけば、そのバージョンをスケールアップし、トラフィック分割を使用してすべてのトラフィックをそのバージョンにルーティングするだけで済みます。フレキシブル環境を使用する際の判断基準フレキシブル環境は、スタンダード環境を補完することを目的としています。既存のアプリケーションをスタンダード環境で実行している場合、通常、アプリケーション全体をフレキシブル環境に移行する必要はありません。ライブラリやプログラムを必要とする部分や、スタンダード環境では不可能な動作を必要とする部分を見極めてください。サービスを作成します。使用して他のサービスを呼び出すことができます。変換のみを処理する別個のマイクロサービスを作成し、それをフレキシブル環境で実行します。ハンドラだけが含まれたシンプルなプログラムにすることができます。)をインストールして使用できます。使用してこのマイクロサービスを直接呼び出すことができます。使用してリクエストをキューに追加できます。