本番Webアプリケーションサーバーのセットアップを改善する5つの方法

getdocs

4年前

序章

アプリケーションがクラウドサーバー環境で稼働し始めたら、サーバー環境を改善して「機能する」環境から本格的な本番環境に飛躍させるにはどうすればよいか疑問に思われるかもしれません。この記事は、クラウドサーバー環境のWebアプリケーションのコンテキストで「本番環境」の大まかな定義を作成し、既存のコンポーネントに追加できるいくつかのコンポーネントを示すことで、本番環境の計画と実装を開始するのに役立ちます。移行を行うためのアーキテクチャ。

このデモンストレーションの目的のために、 5 Common Server Setups で説明されているものと同様のセットアップから始めていると仮定しましょう。たとえば、Webアプリケーションを提供するだけの2サーバー環境です。

実際のセットアップはより単純またはより複雑かもしれませんが、ここで説明する一般的なアイデアとコンポーネントは、ある程度すべてのサーバー環境に適用されるはずです。

「本番環境」と言うときの意味を定義することから始めましょう。

本番環境とは何ですか？

Webアプリケーションのサーバー環境は、一般的な意味で、アプリケーションの動作を維持するために必要なハードウェア、ソフトウェア、データ、運用計画、および人員で構成されます。実稼働環境とは、通常、これらの要素の許容レベルを最大限に考慮して設計および実装されたサーバー環境を指します。

可用性：アドバタイズされた時間中に対象のユーザーがアプリケーションを使用できるようにする機能。重要なコンポーネントに深刻な影響を与える障害によって可用性が損なわれる可能性があります（例：バグが原因でアプリケーションがクラッシュしたり、データベースストレージデバイスに障害が発生したり、システム管理者が誤ってアプリケーションサーバーの電源を切ったりします）。

可用性を促進する1つの方法は、環境内の単一障害点の数を減らすことです。たとえば、静的IPと監視フェイルオーバーサービスを使用すると、ユーザーは正常な負荷バランサーにのみアクセスできます。詳細については、予約済みIPの使用方法のこのセクションとこのを参照してください。 ]負荷分散に関する記事。

回復可能性：システム障害またはデータ損失が発生した場合にアプリケーション環境を回復する機能。重要なコンポーネントに障害が発生し、回復できない場合、可用性は存在しなくなります。関連する概念である保守性を改善すると、障害が発生した場合に特定のリカバリプロセスを実行するために必要な時間が短縮されるため、障害が発生した場合の可用性を向上させることができます。
パフォーマンス：アプリケーションは、平均負荷またはピーク負荷で期待どおりに実行されます（例：適度に反応します）。ユーザーにとって非常に重要ですが、パフォーマンスはアプリケーションが利用可能な場合にのみ重要です

アプリケーションのコンテキストで、上記の各項目の許容レベルを定義するために時間をかけてください。これは、問題のアプリケーションの重要性と性質によって異なります。たとえば、ブログを回復できる限り、訪問者がほとんどいない個人のブログが時折のダウンタイムやパフォーマンスの低下に苦しむことはおそらく許容されますが、企業のオンラインストアは全面的に非常に高い評価を得る必要があります。もちろん、すべてのアプリケーションで、すべてのカテゴリで100 % i nを達成するのは良いことですが、時間とお金の制約のために、それはしばしば実現可能ではありません。

（a）ハードウェアの信頼性、特定のハードウェアコンポーネントが障害が発生する前に指定された時間だけ適切に機能する確率、または（b）セキュリティを要因として言及していないことに注意してください。これは、（a）使用しているクラウドサーバーは一般的に信頼できるが、（物理サーバー上で実行されているため）障害が発生する可能性があること、および（b）セキュリティのベストプラクティスを最大限に活用していることを前提としているためです。簡単に言えば、これらはこの記事の範囲外です。ただし、信頼性とセキュリティは可用性に直接影響する可能性のある要因であり、どちらも回復可能性の必要性に寄与する可能性があることに注意する必要があります。

すべてのアプリケーションのさまざまなニーズと性質のために不可能な、実稼働環境を作成するためのステップバイステップの手順を示す代わりに、既存のセットアップを実稼働環境に変換するために利用できるいくつかの具体的なコンポーネントを紹介します。

コンポーネントを見てみましょう！

1. バックアップシステム

バックアップシステムは、データの定期的なバックアップを作成し、バックアップからデータを復元する機能を提供します。バックアップでは、人為的エラーなどのさまざまな理由で発生する可能性のある偶発的な削除や望ましくない変更が発生した場合に、データを以前の状態にロールバックすることもできます。すべてのコンピュータハードウェアは、ある時点で障害が発生する可能性があり、データ損失を引き起こす可能性があります。これを念頭に置いて、すべての重要なデータの最近のバックアップを維持する必要があります。

本番環境に必要ですか？はい。バックアップシステムは、リカバリ可能性を実現するために必要なデータ損失の影響を軽減できるため、データ損失が発生した場合の可用性を向上させますが、堅実なリカバリプランと組み合わせて使用する必要があります。次のセクションで説明します。 DigitalOceanのスナップショットベースのバックアップは、アクティブなデータベースやディスク書き込みI / Oの高い他のアプリケーションのバックアップを作成するのに適していないため、すべてのバックアップニーズに対応できない場合があることに注意してください。これらのタイプのアプリケーションを実行する場合、または、バックアップスケジュールの柔軟性を高めたい場合は、Baculaなどの別のバックアップシステムを使用してください。

上の図は、基本的なバックアップシステムの例です。バックアップサーバーは、初期バックアップが作成されるアプリケーションサーバーと同じデータセンターにあります。その後、バックアップのオフサイトコピーが別のデータセンターのサーバーに作成され、自然災害などの場合にデータが確実に保持されるようになります。

考慮事項

バックアップの選択：バックアップするデータ。最低限、別のソースから確実に再現できないデータをバックアップしてください
バックアップスケジュール：完全バックアップまたは増分バックアップを実行する時期と頻度。アクティブなデータベースなど、バックアップスケジュールに影響を与える可能性のある特定の種類のデータのバックアップについては、特別な考慮が必要です。
データ保持期間：バックアップを削除する前に保持する期間
バックアップ用のディスク容量：前の3つの項目の組み合わせは、バックアップシステムに必要なディスク容量に影響します。圧縮バックアップと増分バックアップを利用して、バックアップに必要なディスク容量を減らします
オフサイトバックアップ：特定のデータセンター内のローカル災害からバックアップを保護するために、地理的に離れた場所にバックアップのコピーを保持することをお勧めします。上の図では、この目的のためにNYC3のバックアップがSFO1にコピーされています
バックアップ復元テスト：バックアップ復元プロセスを定期的にテストして、バックアップが正しく機能することを確認します

2. 回復計画

回復計画は、実稼働環境内の潜在的な障害または管理エラーから回復するための一連の文書化された手順です。少なくとも、サーバーハードウェアの障害や偶発的なデータの削除など、必然的に発生すると思われる各障害シナリオの復旧計画が必要になります。たとえば、サーバー障害の非常に基本的な回復計画は、バックアップからアプリケーションデータを復元するための追加の手順を含む、最初のサーバー展開を実行するために実行した手順のリストで構成できます。より優れたリカバリプランは、優れたドキュメントに加えて、展開スクリプトと、Ansible、Chef、Puppetなどの構成管理ツールを活用して、リカバリプロセスの自動化と迅速化に役立てることができます。

本番環境に必要ですか？はい。リカバリプランはサーバー環境にソフトウェアとして存在しませんが、運用セットアップに必要なコンポーネントです。これらを使用すると、バックアップを効果的に利用でき、環境を再構築したり、必要に応じて目的の状態にロールバックしたりするための青写真を提供できます。

上の図は、障害が発生したデータベースサーバーの復旧計画の概要です。この場合、データベースサーバーは、同じソフトウェアがインストールされた新しいサーバーに置き換えられ、最後の適切なバックアップを使用してサーバーの構成とデータが復元されます。最後に、アプリサーバーは新しいデータベースサーバーを使用するように構成されます。

考慮事項

手順ドキュメント：障害イベントで従う必要のあるドキュメントのセット。開始点としては、障害が発生したサーバーを再構築するためのステップバイステップのドキュメントを作成し、バックアップからさまざまなアプリケーションデータと構成を復元するための手順を追加することから始めます。
自動化ツール：スクリプトと構成管理ソフトウェアは自動化を提供し、展開と回復のプロセスを改善できます。ステップバイステップガイドは、多くの場合、障害から簡単に回復するのに十分ですが、人が実行する必要があるため、自動化されたプロセスほど高速または一貫性がありません。
重要なコンポーネント：アプリケーションが正しく機能するために必要なコンポーネント。上記の例では、アプリケーションサーバーとデータベースサーバーの両方が重要なコンポーネントです。どちらかが失敗すると、アプリケーションが使用できなくなるためです。
単一障害点：自動フェイルオーバーメカニズムを備えていない重要なコンポーネントは、単一障害点と見なされます。可用性を向上させるために、可能な限り単一障害点を排除するように努める必要があります
改訂：導入と復旧のプロセスが改善されたら、ドキュメントを更新します

3. 負荷分散

サーバー環境に負荷分散を追加して、ワークロードを複数のサーバーに分散することにより、パフォーマンスと可用性を向上させることができます。負荷分散されたサーバーの1つに障害が発生した場合、障害が発生したサーバーが再び正常になるまで、他のサーバーが着信トラフィックを処理します。クラウドサーバー環境では、負荷分散は通常、アプリケーションの特定のコンポーネントを実行する複数のサーバーの前に、ロードバランサー（リバースプロキシ）ソフトウェアを実行するロードバランサーサーバーを追加することで実装できます。

本番環境に必要ですか？必ずしも必要ではありません。負荷分散は、実稼働環境では必ずしも必要ではありませんが、正しく実装されていれば、システムの単一障害点の数を減らす効果的な方法になる可能性があります。また、水平スケーリングによって容量を追加することにより、パフォーマンスを向上させることもできます。

上の図は、負荷を共有するための追加のアプリサーバーと、両方のアプリサーバー間でユーザーリクエストを分散するためのロードバランサーを追加しています。この設定は、単一のアプリサーバーがトラフィックに追いつくのに苦労している場合にパフォーマンスに役立ち、アプリケーションサーバーの1つに障害が発生した場合にアプリケーションを利用できるようにするのにも役立ちます。ただし、データベースサーバーとロードバランサーサーバー自体に2つの単一障害点があります。

注： DigitalOceanロードバランサーは、フルマネージドで可用性の高いロードバランシングサービスです。 DigitalOceanでアプリケーションを実行している場合は、ロードバランサーサービスが環境に適している可能性があります。

考慮事項

負荷分散可能なコンポーネント：環境内のすべてのコンポーネントを簡単に負荷分散できるわけではありません。データベースやステートフルアプリケーションなどの特定の種類のソフトウェアについては、特別な考慮が必要です。
アプリケーションデータレプリケーション：負荷分散されたアプリケーションサーバーがアップロードされたファイルなどのアプリケーションデータをローカルに保存する場合、このデータはレプリケーションや共有ファイルシステムなどの方法で他のアプリケーションサーバーで利用できるようにする必要があります。これは、ユーザー要求を処理するために選択されたアプリケーションサーバーに関係なく、アプリケーションデータを確実に利用できるようにするために必要です。
パフォーマンスのボトルネック：ロードバランサーに十分なリソースがないか、適切に構成されていない場合、実際にアプリケーションのパフォーマンスが低下する可能性があります
単一障害点：負荷分散を使用して単一障害点を排除できますが、計画が不十分な負荷分散では、実際には単一障害点が増える可能性があります。負荷分散は、ペアの前に静的IPを備えた2番目のロードバランサーを含めることで強化され、可用性に応じて一方または他方にトラフィックを送信します。

4. モニタリング

監視は、サービスのステータスとサーバーリソース使用率の傾向を追跡することでサーバー環境をサポートできるため、環境の可視性が向上します。監視システムの最大の利点の1つは、スクリプトの実行や通知の送信などのアクションをトリガーするように構成できることです。サービスやサーバーがダウンした場合、またはCPU、メモリ、ストレージは、過剰に使用されます。これらの通知により、問題が発生するとすぐに対応できるため、アプリケーションのダウンタイムを最小限に抑えるか、防ぐことができます。

本番環境に必要ですか？必ずしもそうとは限りませんが、本番環境のサイズと複雑さが増すにつれて、監視の必要性が高まります。重要なサービスとサーバーリソースを追跡する簡単な方法を提供します。次に、監視により回復性が向上し、セットアップの計画と保守に情報を提供できます。

上の図は、監視システムの例です。通常、監視サーバーは、アプリケーションサーバーとデータベースサーバーで実行されているエージェントソフトウェアにステータスデータを要求し、各エージェントはソフトウェアとハードウェアのステータス情報で応答します。その後、システムの管理者は、監視コンソールを使用してアプリケーションの全体的な状態を確認し、必要に応じてより詳細な情報にドリルダウンできます。

考慮事項

監視するサービス：監視するサービスとソフトウェア。少なくとも、アプリケーションが正しく機能するためには、正常に実行されている状態である必要があるすべてのサービスの状態を監視する必要があります
監視するリソース：監視するリソース。リソースの例には、CPU、メモリ、ストレージ、ネットワーク使用率、およびサーバー全体の状態が含まれます
データ保持：監視データを破棄する前に保持する期間。これは、監視する項目の選択とともに、監視システムが必要とするディスク容量に影響します。
問題検出ルール：サービスまたはリソースがOK状態にあるかどうかを決定するしきい値とルール。たとえば、サービスまたはサーバーは、リクエストを実行して処理している場合は正常であると見なされる可能性がありますが、ストレージなどのリソースは、その使用率が特定の時間にわたって特定のしきい値に達すると警告をトリガーする可能性があります
通知ルール：通知を送信するかどうかを決定するしきい値とルール。通知は重要ですが、受信する数が多すぎないように通知ルールを調整することも同様に重要です。警告やアラートでいっぱいの受信トレイは無視されることが多く、通知がまったくないのと同じくらい役に立たなくなります。

5. 一元化されたロギング

一元化されたログは、ログを表示および検索する簡単な方法を提供することにより、サーバー環境をサポートできます。ログは通常、環境全体の個々のサーバーに1か所でローカルに保存されます。ログを読み取るために個々のサーバーにログインする必要がないという便利さのほかに、集中ログを使用すると、特定の時間枠でログとメトリックを相互に関連付けることにより、複数のサーバーにまたがる問題を簡単に特定できます。また、ローカルログをアプリケーションサーバーから独自の独立したストレージを持つ一元化されたログサーバーにオフロードできるため、ログの保持に関してより柔軟性があります。

本番環境に必要ですか？いいえ。ただし、監視と同様に、集中ログは、サーバー環境のサイズと複雑さが増すにつれて、サーバー環境に関する貴重な洞察を提供できます。従来のログ記録よりも便利であることに加えて、サーバーログを迅速に監査して可視性を高めることができます。

上の図は、集中型ロギングシステムの簡略化された例です。ログ配布エージェントは各サーバーにインストールされ、重要なアプリとデータベースのログを集中ログサーバーに送信するように構成されています。システムの管理者は、単一のコンソールからすべての重要なログを表示、フィルタリング、および検索できます。

考慮事項

収集するログ：サーバーから集中ログサーバーに送信する特定のログ。すべてのサーバーから重要なログを収集する必要があります
データ保持：ログを破棄する前にログを保持する期間。これは、収集するログの選択とともに、集中ログシステムが必要とするディスク容量に影響します。
ログフィルター：プレーンログを構造化ログデータに解析するフィルター。ログをフィルタリングすると、意味のある方法でデータをクエリ、分析、グラフ化する機能が向上します
サーバークロック：サーバーのクロックが同期され、同じタイムゾーンに設定されていることを確認してください。これにより、ログのタイムラインが環境全体で正確になります。

結論

すべてのコンポーネントをまとめると、本番環境は次のようになります。

本番サーバーのセットアップをサポートおよび改善するために使用できるコンポーネントについて理解したので、それらを独自のサーバー環境に統合する方法を検討する必要があります。もちろん、すべての可能性を網羅しているわけではありませんが、これにより、どこから始めればよいかがわかります。利用可能なリソースと本番環境の目標のバランスに基づいて、サーバー環境を設計および実装することを忘れないでください。

上記のような環境のセットアップに興味がある場合は、次のチュートリアルを確認してください：本番用のビルド：Webアプリケーション。