序章

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

この高可用性アプリケーションのセットアップは、以下を提供する可能性のある架空のソリューションとして設計されました。

  • 保存、取得、および連結に重点を置いた、画像、ドキュメント、およびビデオの処理ソリューション。
  • スケーリング、変更、またはeコマースソリューションとの統合が可能なスコアキーピング、リーダーボード、または購入ソリューション。
  • eコマースソリューションと統合することもできるブログソリューション。

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

ステップ1：プライベートネットワークを使用してフロントエンドサーバーを作成する

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

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

  • メディアと画像アセットでどのような種類の作業を行いますか？
  • コンピューティング要件はどのようになりますか？
  • どのような種類と量のトラフィックが予想されますか？
  • それを監視する私たちの計画は何ですか？

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

ステップ2：フロントエンドサーバー用のロードバランサーを作成する

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

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

  • リクエストとユーザーに関する状態情報を保存しますか？
  • CPU負荷に基づいてリクエストをリダイレクトする必要がありますか？

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

ステップ3：プライベートネットワークを使用してバックエンドサーバーを作成する

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

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

  • 画像とメディアのアセットでどのような処理を行っていますか？
  • これらの資産から情報を引き出しているのでしょうか、それとも単にそれらを取得または再結合しているのでしょうか。
  • どのような量と種類の消費者取引がありますか？

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

ステップ4：HAProxyをインストールする

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

ステップ5：SQLデータベースを作成する

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

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

  • Ubuntu16.04に最新のMySQLをインストールする方法。
  • Ubuntu16.04でMySQLグループレプリケーションを構成する方法。

ステップ6：NoSQLデータベースを作成する

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

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

  • Ubuntu16.04にMongoDBをインストールして保護する方法。
  • Ubuntu16.04にOrientDBをインストールして構成する方法。

ステップ7：ブロックストレージを追加する

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

  • DigitalOceanでブロックストレージを使用する方法。
  • オブジェクトストレージと ブロックストレージサービス 。

ステップ8：Elastic/ELKスタックを作成する

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

ステップ9：オブジェクトストアを作成する

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

ステップ10：DNSレコードを構成する

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

ステップ11：復旧戦略の計画

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

結論

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

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