ソリューションの詳細：MongoDBとElk Stackを使用して、Web処理および保存機能を備えた高可用性Webアプリケーションを構築する

高可用性Webアプリケーションのセットアップは、単一障害点の排除とダウンタイムの最小化を目指す開発者に利点をもたらします。 ただし、この一般的なフレームワーク内には、さまざまなバリエーションがあります。 開発者は、アプリケーションの特定のニーズとパフォーマンス目標に基づいて選択を行います。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/full-diagram.png [高可用性Webアプリケーションの完全な図表]

この高可用性アプリケーションのセットアップは、以下を潜在的に提供する仮想ソリューションとして設計されました。

この記事では、このセットアップの特定の機能を検討し、より一般的なレベルでそのコンポーネントについて説明します。 各セクションの終わりに、方法論とベストプラクティスを検討する際に役立つトピックの追加リソースにリンクします。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-1.png [ステップ1：フロントエンドサーバーの図]

典型的な多層セットアップでは、プレゼンテーションレイヤーをアプリケーションロジックから分離します。 アプリケーション機能をレイヤーに分離すると、トラブルシューティングとスケーリングのプロセスが長期的に簡単になります。

サーバーとリソースを選択するとき、次の要因を考慮することができます。

私たちの監視ツールは、アプリケーションを拡張し、このレベルや他のレベルでリソースを構築するのに役立ちます。 コスト削減とセキュリティ対策のために行うことができる追加のステップは、フロントエンドサーバーを含むアプリケーションのリソースを共有プライベートネットワークに割り当てることです。 追加の帯域幅コストをかけたり、単一のデータセンターを離れることなく、サーバー間でデータを転送できます。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-2.png [ステップ2の図：ロードバランサー]

アプリケーションのリソースの高可用性とパフォーマンスを維持するために、ロードバランサーを作成してフロントエンドワークロードを管理できます。 これらのロードバランサーは、サーバーの障害または誤動作を管理するために、定期的なヘルスチェックとフェールオーバーメカニズムを使用して、着信トラフィックをリダイレクトします。 また、より一般的にトラフィックのバランスを取り、個々のサーバーが過負荷にならないようにします。

構成を最適化するために、次の要素を考慮することができます。

これらの要因により、構成に最適なアルゴリズムを選択できます。 ロードバランサーの動作には追加のセキュリティコンポーネントもあります。特定のポートでリッスンし、ポート間でトラフィックをリダイレクトするように構成できます。 それらを使用して、バックエンドサーバーのメッセージを復号化することもできます。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-3.png [ステップ3の図：バックエンドサーバー]

アプリケーションのバックエンドを作成するには、リソース計算の別のセットが必要です。 繰り返しますが、アプリケーションの動作の性質によって、サーバーのサイズとリソースが決まります。 考慮すべき要素には、このレベルでサーバーが行う処理作業の種類と量が含まれます。 これは、データ型と処理タスクの区別が関係するところです。 たとえば、画像アセットと消費者データを使用している場合、それぞれに適用される負荷と遅延の要件を考慮することができます。

このレベルでは、次のような問題に対処するためにも監視が重要になります。

共有プライベートネットワーク内でこのレベルのリソースを配置して、潜在的な帯域幅料金を計上できます。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-4.png [ステップ4：HAProxyの図]

ロードバランサーが外部リクエストを処理する方法と同様に、HAProxyはフロントエンドとアプリケーションレイヤー間の通信フローを管理します。 ロードバランサとしての機能では、特定のポートからのトラフィックをリッスンしてリダイレクトするようにHAProxyを構成できます。 これにより、アプリケーションの内部操作に別のセキュリティレイヤーを追加できます。 スケーリングする必要がある場合、ノードを自動的に追加および削除するようにHAProxyを構成できます。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-5.png [ステップ5の図：SQLデータベース]

アプリケーションデータの特定のセグメントでは、SQLデータベースを使用します。 これは、最新で正確かつ一貫性のあるデータである必要があります。 販売トランザクション、ログイン/ログオフ情報、パスワードの変更などの構造は統一されており、安全である必要があるため、SQLデータベースを使用する合理的なケースがあります。

繰り返しますが、メトリックスを検討する必要があります。処理中のトランザクションリクエストまたはセキュリティ保護されたリクエストの数。 負荷が高い場合は、ProxySQLなどのツールを使用して着信リクエストのバランスをとることを検討できます。 SQLデータベース間でレプリケーションを設定する場合、パフォーマンスを改善し、高可用性を確保するために追加の手順を実行できます。 これは、データ処理をスケーリングする必要がある場合にも役立ちます。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-6.png [ステップ6の図：NoSQLデータベース]

データが不均一またはスケマティックでない場合、NoSQLデータベースを使用できます。 たとえば、写真、ビデオ、またはブログの投稿の場合、NoSQLデータベースは、アイテムのメタデータを非概略的な方法で保存する機能を提供します。 このタイプのソリューションを使用すると、データの可用性が高くなり、その一貫性が最終的に得られます。 パフォーマンスについて考えるとき、これらのデータベースに予想されるリクエストの種類と量を検討したいと思います。

要求の負荷と種類に応じてパフォーマンスを最適化できる要因には、負荷分散ソリューションを使用してデータベース間のトラフィックを管理する、データベースとストレージソリューションにデータを分散する、データベースを複製または複製するのではなく追加または破棄するなどがあります。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-7.png [ステップ7の図：ストレージのブロック]

このセットアップは、データベースストレージ機能をアプリケーションの他の操作から分離します。 目標は、データのセキュリティとアプリケーションの全体的なパフォーマンスを強化することです。 この分離プロセスの別の部分として、SQLデータベースファイルのバックアップソリューションを作成できます。 DigitalOceanのBlock Storageボリュームなどのブロックストレージソリューションは、低レイテンシI / Oと回路図ファイルシステム構造のおかげで、この仕事をうまく行うことができます。 また、簡単に破棄、サイズ変更、または乗算できるため、スケーリングのオプションも提供します。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-8.png [ステップ8の図：ELKスタック]

アプリケーションのパフォーマンスを監視することで、セットアップをスケーリングおよび改良する際に下した決定がわかります。 この作業を行うには、Elastic / ELKスタックなどの集中ログソリューションを使用できます。 スタックには、ログを収集して視覚化するコンポーネントが含まれています。ログを処理するLogstash。それらを保存するElasticsearch。 Kibanaを使用すると、検索して視覚的に整理できます。 このスタックをフローティングIPの背後に配置すると、静的IPを使用してリモートでアクセスできます。 さらに、共有プライベートネットワークにスタックを含めると、別のセキュリティ上の利点があります。レポートエージェントは、インターネット経由でスタックに情報を転送する必要がありません。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-9.png [ステップ9の図：オブジェクトストレージ]

アプリケーションの静的アセットを保存する場合、高いパフォーマンスを維持しながら可用性を確保したいと考えています。 DigitalOcean Spacesのようなオブジェクトストレージソリューションは、このニーズを満たすことができます。 具体的には、データベースに大きなオブジェクトを保存することにした場合、データの流入でパフォーマンスの問題が発生し、バックアップが非常に大きくなる可能性があります。 このシナリオでは、データをオブジェクトストレージに移動できます。 データベースにURLを保存することで、ストレージ容量に影響を与えることなくデータベースからリソースを指定できます。 これは、静的なままであると予想されるデータの最適なソリューションであり、スケーリングの追加オプションを提供します。

image：https：//assets.digitalocean.com/articles/solutions/highly-available-web-app/step-10.png [ステップ10の図：DNSレコード]

高可用性の設定が完了したら、DNSを使用してアプリケーションのドメイン名をロードバランサーにポイントできます。 ラウンドロビンアルゴリズムを使用すると、アプリケーションの分散リソース間でクエリ応答のバランスを取ることができます。 これにより、これらのリソースの可用性が最大化されると同時に、リソースクラスター全体にワークロードが分散されます。 さらに、地理的ルーティングを使用して、リクエストを近接リソースに一致させることができます。

リカバリ戦略には、管理上の障害やその他の障害が発生した場合にデータをバックアップおよび復元するツールと機能が含まれます。 各Dropletについて、DigitalOceanスナップショットを活用および自動化して、Dropletの画像をDigitalOceanサーバーにコピーして保存できます。 さらに、Percona、Restic、Baculaなどの専用ツールとサービスを、DigitalOcean Backups and Spacesなどのストレージデバイスとともに使用して、データをコピーできます。 これらのツールを評価して戦略を作成する際に、アプリケーションの各レイヤーのデータと、アプリケーションの機能を復元するための合理的なポイントを得るためにバックアップする必要がある頻度を検討します。

この記事では、高レベルの運用パフォーマンスを提供するために、Droplet、Load Balancer、Spaces、Block Storageなどのインフラストラクチャコンポーネントに依存する高可用性Webアプリケーションの潜在的なセットアップについて説明しました。 このセットアップは、eコマースソリューションと統合できる購入、スコアキーピング、またはブログ機能だけでなく、ストレージと検索に焦点を当てた画像やその他のメディアの処理ソリューションをサポートする可能性があります。

最終的に、開発者は、高可用性を維持しながら特定のニーズとユースケースを満たすために取ることができる多くの方向性があり、各アプリケーションのセットアップは、アーキテクチャの特異性におけるこれらの違いを反映します。