インスタンスは単一のゾーンにデプロイされ、データは他のゾーンに自動的に複製されます。シームレスに連携します。シンプルでスケーラブルなインターフェースを使用してオブジェクト(通常はファイル)を保存、取得できます。アプリケーションにアップロードされたすべてのファイルを保存します。したがって、ステートフルな情報はどのインスタンスのディスクにも保存されません。アーキテクチャに復元力を持たせるには、障害が発生したインスタンスまたは利用不可になったインスタンスを自動的に置き換える必要があります。新しいインスタンスは、オンラインになった時点で次のことが必要になります。コンポーネントをまとめて使用できます。テンプレート起動スクリプトは、インスタンスの起動時または再起動時に実行されます。起動スクリプトを使用して、ソフトウェアや更新をインストールすること、仮想マシン内でサービスが実行されていることを確認できます。構成管理ツールをインストールすることも可能です。よってアプリケーションと連携するようにインスタンスを構成します。新しいインスタンスの追加をご覧ください。インスタンスを起動する前に定義しなければならない項目がいくつかあります。イメージ、接続するすべてのディスクを指定する必要があります。テンプレートを使用して定義します。アーキテクチャでの特定の役割を満たすようにそのインスタンスでソフトウェアを構成する方法が定義されます。テンプレートは単なるテンプレートです。インスタンスがオンラインになった時点で、そのインスタンスにテンプレートを適用する手段が必要になります。テンプレートは、ユーザーが決定します。マネージャーは、必要に応じてそれらのインスタンスを起動し、構成します。次の図では、以下の各コンポーネントがどのように連携するかを示しています。リソースにすることもできます。グループで再利用できます。テンプレートで一部のゾーンリソースを指定した場合、そのテンプレートを使用できるのは、それらのリソースがあるゾーンに限定されます。グループが揃ったので、正常でないインスタンスを新しいインスタンスで置き換えることができるシステムが構築されました。アプリケーションには、復元力を備えるのに必要なツールがほぼすべて揃いました。欠けているものは、正常でないインスタンスを特定し、そのインスタンスを置き換える必要があることを認識する方法です。ロードバランサを使用して、正常な状態の適切なインスタンスにユーザーを接続するように設計されています。つのサービスを使用して、リクエストに対応できるインスタンスを特定できます。ヘルスチェックは、各インスタンスに対してヘルスチェックを実行するためのポートとパスを指定します。レスポンスが返されることが想定されます。グループを定義します。ヘルスチェックが指定されます。グループとどのように関係しているのかを示します。大領域は、ネットワーキング、コンピューティング、ストレージです。コンポーネントにも対処する必要があります。データベースを提供します。レプリケーション、暗号化、パッチ管理、バックアップを自動的に管理します。データベースは、リージョン規模のデータベースです。データはリージョン内の各ゾーンに複製されます。これは、データが更新されるたびにバックアップが作成されるのと同じことです。つのゾーンの完全な障害というめったに起こらない事態が発生した場合でも、データは保持されます。つのタイプから選択できます。同期レプリケーション。同期レプリケーションでは、更新が複数のゾーンにコピーされてからクライアントに返されます。これにより、重大な問題が起きても信頼性と可用性が確保されますが、書き込みの処理速度は遅くなります。非同期レプリケーション。非同期レプリケーションでは、書き込みのスループットが上がります。書き込みがローカルのキャッシュに保存されると、他の場所にデータがコピーされる前に書き込みの確認応答が行われるためです。非同期レプリケーションでは、レプリケーションが完了するまで待つ必要がないためデータベースへの書き込み処理が速くなります。万が一、データベースの更新が行われる数秒の間にデータセンターでシステム障害が発生した場合、最新の更新が失われる可能性があります。アプリケーションでは、ワークロードでの書き込み頻度がさほど高くないため、同期レプリケーションを使用しています。同期レプリケーションと非同期レプリケーションのどちらを使用するかは、アプリケーションの書き込みパフォーマンスとデータ耐久性の要件に応じて選択してください。使用して、復元力を備えたアプリケーションを作成する方法を説明しました。復元力だけでは十分でありません。スケーラビリティも重要です。万人でも適切に機能する必要があります。ユーザー数に合わせてそのリソースを増減し、費用対効果を高めなければなりません。アプリケーションのリソースを増減できるようにするには、以下が必要になります。サービスのインスタンスを追加または削除する手段。インスタンスを追加する必要があるタイミングと、インスタンスを削除する必要があるタイミングを決定する手段も必要です。オートスケーラーが解決します。ステートフルなデータを保存する手段。インスタンスは稼働したり停止したりするため、ステートフルなデータをインスタンスに保存することはおすすめできません。インスタンスにデータを保存するという方法を取れます。その場合は、ユーザーがアップロードしたファイルについても考慮する必要があります。この要件を満たします。利用する方法を説明します。オートスケーラーを使用したスケーリングアプリケーションの使用量は増減するため、必要とされるリソースを動的に調整する必要があります。オートスケーラーです。トラフィックまたは負荷が増加すると、オートスケーラーは追加アクティビティを処理するためにリソースを追加します。トラフィックまたは負荷が低下すると、費用を削減できるよう、リソースを削除します。ルールに基づいて自動的に実行します。ルールはユーザーが定義しますが、その後の人的な介入は不要です。新しいインスタンスの追加をご覧ください。エクスペリエンスが実現する。需要が指定しきい値を下回ったときにオートスケーラーによってインスタンスが削除されるため、費用をより適切に抑制できる。指標に基づいて仮想マシンの数をスケールできます。インスタンスを追加または削除します。オートスケーラーを使用したバッチ処理をご覧ください。サービスについて説明しました。応じてバランスを取るよう指示します。未満に維持しようとすることを意味します。サービスに関するドキュメントをご覧ください。グループごとにオートスケーラーを作成する必要があります。グループはゾーン別のリソースであるため、ゾーンにオートスケーラーを作成する必要があります。プロパティが含まれています。オートスケーラーは、このプロパティで定義された、ロードバランサの最大処理容量の割合を維持します。グループをスケールアップします。グループをスケールダウンします。各オートスケーラーでは、そのオートスケーラーが違反できないインスタンスの最大数と最小数も定義します。グループでのみ使用できます。グループとインスタンスのグループの自動スケーリングをご覧ください。アプリケーションの機能の中には、ユーザーがログインするときにファイルをアップロードして保存できる機能があります。ディスクに直接保存されます。メカニズムを備えている場合には問題はありません。インスタンスがある場合、これは最適なアプローチとは言えません。ユーザーがファイルをアップロードした場合、そのファイルが保存されているマシンで次のリクエストが受信されるとは限らないためです。ファイルが保存されているインスタンスが、オートスケーラーにより不要なインスタンスとして終了されないという保証もありません。使用すれば、この問題をよりよく解決できます。アップロードを一元的に保存して、アクセスするのに最適な場所となります。プラグインと互換で、変更を加える必要はありません。ストアをサポートするプラグインが用意されています。使用してファイルを保管できます。使用してファイルをアップロード(青の矢印)し、そのファイルを取得(緑の矢印)するフローを示しています。図で示されているプロセスは、次のとおりです。ロードバランサが、リクエストを処理するインスタンスを選択する。内での場所など)を保存する。インスタンスにストリーミングされる。インスタンスが、ロードバランサを介してストリームを送信する。ファイルがユーザーに送信される。アップロードに対応できる、冗長性と耐久性を兼ね備えたストレージを提供します。ソリューションは、復元力を備えており、スケーラブルで費用対効果の高いソリューションです。容量計画を気にすることなく、使用したストレージに対してのみ料金を支払うことができます。データは自動的に、複数のゾーンに重複して保存されます。使用して復元力とスケーラビリティを備えたアプリケーションを作成する方法を説明しました。可能な限り費用対効果の高いアプリケーションを作成するには、それだけでは足りません。アーキテクチャが復元力を備えていてスケーラブルなだけでなく、費用対効果にも優れたものであることを説明します。アプリケーション使用の負荷と頻度について一般的な想定を行い、その想定を基本的な費用の見積もりに変換します。このような想定は単なる想定にすぎないということに留意してください。各数値を必要に応じて自由に調整して、独自のアプリケーションで予想される使用に合うように費用の見積もりを作成してください。アーキテクチャの主要な関心事は、サーバーを稼働しつづけるのにかかる費用です。この費用分析では、次の想定を使用しています。時までのピーク時にアプリケーションが受け取るページビュー数は、次のように求めることができます。リソースを用意する必要があります。インスタンスのタイプを明らかにする必要があります。使用してテストされました。インスタンスで十分であることがわかりました。インスタンスが実行されます。料金計算ツールで最新の料金の見積もりを確認してください。どちらのインスタンスにも、自動的に継続利用割引が適用されることがわかります。アドレスが単一の転送ルールとして使用されています。この転送ルールは、時間単位で課金されます。データ転送の見積もりでは、まず、最悪のシナリオを検討します。ロードバランサでは、処理した上りデータに対して課金されます。ロードバランサから送信されるトラフィックには、通常の下り料金が課金されます。ページの読み込みであると想定します。リクエストが発生します。リクエストが発生します。その結果、次のようになります。追加データが処理されます。超える下りトラフィックに対する料金がわかります。このデータ転送の見積もりは最悪の場合のシナリオです。インスタンスからの各リクエストで静的アセットも含めすべてのコンテンツを提供しており、かつキャッシュやコンテンツ配信ネットワーク(CDN)のメリットを享受せず、ロードバランサによりこれを行っているためです。千万回のページ読み込みに基づいていることを思い出してください。ホストされているライブラリに切り替えることで節約できるデータ転送料が示されています。