前の章では、インフラストラクチャのWebフロントエンドレイヤーに冗長性を追加して、ダウンタイムを削減する方法を示しました。 サービスがファイルとデータを処理する場合は、一元化されたバックエンドも必要になります。これは、単一障害点にならないように同様に冗長にする必要があります。
フロントエンドとバックエンドの両方で、負荷分散ソリューションを使用して、トラフィックを複数のサーバーに分散できます。 この構造は、ダウンタイムを発生させずにアプリケーションコードを更新する機能、A / Bテスト、カナリアデプロイメント、ブルー/グリーンデプロイメントなどをサポートするなど、バックエンドにいくつかのユニークな利点を提供します。 ただし、これにより、インフラストラクチャも多少複雑になります。 ロードバランサーの構成を維持する方法、アプリケーションとアプリケーションを実行するサーバーを管理する方法、ユーザーセッション、ファイルストレージ、データベースなどの一貫性を処理する方法などを考慮する必要があります。
DigitalOceanロードバランサーを使用するか、ロードバランサーの自己管理セットを使用するかに関係なく、構成の一貫性を維持する必要があります。 自己管理ロードバランサーのセットアップで構成管理ツールを使用して構成ファイルを管理することは、より実践的であり、事前の追加作業が必要です。一方、DigitalOceanロードバランサーは、ロードバランサーの冗長性を自動的に処理するマネージドサービスです。
DigitalOceanロードバランサーの場合、構成オプションは精選されますが、設定が正しく一貫性があることを確認する必要があります。 ドロップレットタグを使用してロードバランサーのバックエンドを決定することは、ドロップレットを自動的に追加および削除でき（個々のIPではなく）、AnsibleなしでTerraformのみで構成を処理できるため、成功への最も直接的な方法です。
負荷分散の要件がより複雑な場合は、独自の負荷分散装置を使用することを選択した可能性があります（前の章のHAProxyまたは他の負荷分散ソフトウェアを使用）。 この場合、複数のロードバランサードロップレットとDigitalOceanフローティングIPアドレスのセットを展開して、ロードバランシングレイヤーでの冗長性を確保する必要があります。
私たちのセットアップ
データの一貫性は、ロードバランサーの構成で対処する主な問題です。 複数のサーバーのいずれかからバックエンドを提供できる場合、各サーバーが同じ一貫したデータセットにアクセスできること、または特定のセッションが特定のサーバーに接続し続けることを確認する必要があります。
これを、構成管理ソフトウェアのより強力な使用方法を示す機会として使用します。 WordPressを実行しているWebサイトをホストする例では、クラスター内のすべてのノードに適切なデータを確保する方法を決定する必要があります。 エンドユーザーは、どのノードがリクエストを処理しているかに関係なく、一貫したエクスペリエンスを必要とします。 1つのノードがWordPressサイトの投稿または画像を知っているが、他のノードは知らない場合、エンドユーザーは散発的な結果を見ることがあります。
一貫性を確保するために構成を順を追って検討する3つの関連コンポーネントがあります：ユーザーセッション、ファイルストレージ、およびデータベースです。
構成を理解する
構成が完了した後のクラスターの実際のセットアップは比較的短いプロセスですが、構成とその中の決定を理解することは、これらのパターンを独自のインフラストラクチャに適用するための鍵となります。 少しずつ分解しましょう。
ロードバランサーの構成
DigitalOceanロードバランサー
前の章と同様に、Terraformを使用してロードバランサーの構成を管理します。 次のエントリはロードバランサーを作成し、バックエンドドロップレットタグ、転送ルール、使用するTLS証明書、およびロードバランサーが使用するヘルスチェックを提供します。 SSLおよびその他のセキュリティ設定はこの章の範囲外ですが、第13章で詳しく説明します。
以下は、 `+ example-code / 02-scale / ch05 / init_deploy / main.tf +`ファイルにあるリソースブロックです。
...
resource "digitalocean_loadbalancer" "public" {
name = "${var.project}-lb"
region = "${var.region}"
droplet_tag = "${digitalocean_tag.backend_tag.id}"
redirect_http_to_https = true
depends_on = ["digitalocean_tag.backend_tag"]
forwarding_rule {
entry_port = 80
entry_protocol = "http"
target_port = 80
target_protocol = "http"
}
healthcheck {
port = 80
protocol = "http"
path = "/"
check_interval_seconds = 5
response_timeout_seconds = 3
unhealthy_threshold = 2
healthy_threshold = 2
}
}ロードバランサーは不変のリソース（ドロップレットなど）ではなくサービスであるため、構成引数を変更してもロードバランサー全体が再作成されることはありません。更新されます。 サポートされている引数と出力属性の詳細については、https：//www.terraform.io/docs/providers/do/r/loadbalancer.html [Terraform documentation]をご覧ください。
DigitalOcean Load Balancerを使用して、WebサーバーへのパブリックWebトラフィックの負荷分散を処理しています。
HAProxyクラスター
下位レベルの負荷分散設定へのアクセスや複数のバックエンドサービスのサポートなど、より複雑な構成が必要な場合は、独自のロードバランサークラスターをセットアップできます。 前の章のHAProxyの例を続けます。
AnsibleはJinja2テンプレートシステムを使用します。これにより、構成ファイルの作成と更新のプロセスが簡素化されます。 Jinja2は、ifステートメント、ループ、数学演算、組み込みフィルターの大きなライブラリなど、プログラミング言語にある変数と制御構造の使用をサポートしています。 この要約は、Ansible内のテンプレートシステムを正当化するものではありません。 詳細については、https：//docs.ansible.com/ansible/2.6/user_guide/playbooks_templating.html#templating-jinja2 [Ansibleのドキュメント]を確認することをお勧めします。
構成が変更されたときに更新をトリガーする方法はいくつかあります。 サイトの需要があまり変動しない場合、または事前に変更がいつ行われるかがわかっている場合は、完全に自動化されたスケーリングを設定する必要はありません。 代わりに、Ansibleプレイブックを手動で実行するか、Terraformデプロイメントスクリプトへの変更をgitリポジトリにプッシュするときに実行するように設定できます。
もう1つのオプションは、Consulを使用してサービスを検出し、ロードバランサーで「+ consul-template a」を構成して、構成ファイルを自動的に更新することです。 これにより、インフラストラクチャ全体にドロップレットが追加されますが、他のサービスにもConsulを使用できます。
データベースクラスターの負荷分散を処理するためにHAProxyクラスターを使用しています。
ユーザーセッション
セッションレビュー
_ ユーザーがロードバランサーを介してホストされているサイトにアクセスする場合、次のリクエストが同じバックエンドサーバーによって処理されるという保証はありません。 単純な静的ページの場合、これは問題になりませんが、サービスがユーザーのセッションの知識を必要とする場合（ユーザーがログインしている場合など）、それを処理する必要があります。 これに対処するいくつかのオプションがあり、スタックのさまざまなポイントで実装できます。 _
ユーザーセッションを処理するために選択する方法は、ユースケースによって異なります。 ここにいくつかのオプションがあります：
-
IPソースアフィニティ*は、同じIPアドレスからのすべての要求を同じバックエンドに送信します。 ユーザーが同じIPアドレスを持っているため、ユーザーがNATを使用してルーターの背後から接続する可能性がある状況では、これは最良の選択ではありません。
*ロードバランサーセッション*と*アプリケーションセッション*オプションは似ています。 どちらもIPヘッダー情報を参照してリクエストを送信するバックエンドを決定するようにロードバランサーを構成します。 IPソースアフィニティ方式とは異なり、NATの背後のユーザーは個々のユーザーとして識別されます。 HAProxyロードバランサーにスティックテーブルを実装することで、さらに調整できます。これを使用して、複数の異なるデータポイントに基づいてユーザーIDを構成できます。
*ファイルシステムレプリケーション*は、セッションが保存されているファイルシステム内のパスを複製し、すべてのバックエンドがすべてのセッションにアクセスできるようにします。 考慮すべき重要な側面の1つは、複製が行われる速度です。 方法によっては、複製するセッションの数が多いバックエンドノード間の適度な遅延でも、エンドユーザーに問題を引き起こす可能性があります。
*データベース*または*メモリ内データストア*の使用も同様です。 どちらも、ユーザーセッションをデータベースまたはRedisなどのメモリ内キャッシュに保存する方法でアプリケーションを作成する必要があります。 データベースは、他のデータ要求のためにデータベースに接続するように既にセットアップされているため、データベースを使用すると便利です。 非常にアクティブなサイトの場合、これによりデータベース自体のオーバーヘッドが増加しますが、ほとんどの場合、追加の負荷は無視できます。 RedisやMemcachedなどのメモリ内キャッシュを使用すると、さらにいくつかのドロップレットを作成する必要がありますが、これらはパフォーマンスの向上のためにデータベースクエリ応答をキャッシュするために使用できる非常に高速で汎用性の高いソリューションです。
WordPressはすでにセッションにデータベースを使用するように設定されているため、これが使用するソリューションです。
ファイルストレージ
-
ファイルストレージレビュー： *
_ アプリケーションが使用するファイルは一貫している必要があります。すべてのサーバーが同じリソースのセットにアクセスする必要があります。 この問題に対する適切なアプローチの1つは、ストレージ機能をバックエンドアプリサーバーから分離し、代わりにファイルストレージに別のサービスを使用することです。 静的アセットの場合、オブジェクトストレージソリューションを使用できます。 DigitalOcean Spacesは、冗長性が組み込まれた高可用性オブジェクトストレージサービスです。 第7章で、ストレージオプション、特にスペースについて詳しく説明します。 _
セッションと同様に、アプリケーションノード間でローカルファイルシステムの複製を使用してファイルストレージを処理できます。 ただし、これにより、インフラストラクチャに別のサービスが追加され、構成が変更されます。
より簡単なソリューションは、特にWordPressに既にhttps://wordpress.org/plugins/do-spaces-sync/[DigitalOcean Spaces Sync]プラグインがあるため、DigitalOcean Spacesなどのオブジェクトストレージを使用することです。 セットアップは1つのプラグインのインストールと構成に限定されるため、この章で使用するソリューションです。
データベース
-
データベースレビュー *
_ _ ファイルストレージと同様に、データベースはすべてのバックエンドドロップレットにアクセスできる必要があります。 クラスター全体でデータベースの挿入と更新を複製する方法は、クラスター化されたデータベースソリューションを機能させるために不可欠です。
さらに、データベースは高可用性である必要があります。つまり、冗長性と自動フェールオーバーがあります。 異なるノードに対して競合する更新が行われた場合のように、システムはデータの一貫性を処理する必要があるため、これはロードバランサーの背後に置くよりも複雑になる可能性があります。
この例では、MariaDB Galeraクラスターを使用してこれらの問題を処理します。 Galeraはすべてのデータベースノードへの同期レプリケーションを処理します。各ノードは完全なプライマリデータベースサーバーとして機能します。 これは、クラスター内の各ノードの読み取りと書き込みが可能であり、すべての同期が維持されることを意味します。 特定のノードがプライマリ書き込みサーバーとして選択される、プライマリおよびセカンダリのレプリケーション形式を含むデータベースをクラスター化する他の方法があります。
各クラスターソリューションにはメリットがあります。 演習では、データの一貫性が自動的に処理され、クラスター内のすべてのノードがプライマリサーバーとして機能できるため、Galeraが最もメリットをもたらします。 フェールオーバーまたはフェールバックの手順は必要ありません。 _ _
WordPressはほとんどすべてのデータベースに依存しており、単一の外部データベースサーバーは単一障害点です。 データベースクラスターにはいくつかのオプションがあり、ケースに最適なものに基づいてさまざまな部分を組み合わせて一致させることができます。
この章では、MySQLのフォークであるMariaDBで実行されるGaleraクラスターを構築します。 これは、DigitalOcean Floating IPが接続されたいくつかのHAProxyノードの背後で実行されます。
このためのソースリポジトリ（https://github.com/DO-Solutions/galera-tf-mod）にアクセスできます。 デフォルトで3つのノードを持つクラスターへのTCPルーティングをセットアップします。 使用するノードが3つ未満の場合、スプリットブレインの状況を回避し、クラスターを稼働状態に保つために、http：//galeracluster.com/documentation-webpages/arbitrator.html [Galera Arbitrator]ノードが必要になります。 メインのterraformファイル_example-code / 02-scale / ch05 / init_deploy / main.tf_のモジュールコードブロックに次の行を追加することで、ノードの数を増やすこともできます。 クォーラム投票の実行時にクラスターが過半数になるように、ノードの数を奇数にする必要があることに注意してください。 たとえば、2つのノードがレコードが存在すると考え、他の2つのノードがレコードが存在すべきでないと判断した場合、決定投票を行うには追加のノードが必要です。
module "sippin_db" {
...
db_node_count = "5"
}WordPressクラスターのセットアップ
このプロジェクトでは、WordPressクラスターのセットアップに必要なコマンドはわずかです。 この章のサンプルコードが含まれるコントロールドロップレットの「+ / root / navigators-guide / example-code / 02-scale / ch05 / init_deploy +」から作業します。
そのディレクトリから、提供された初期化スクリプトを実行します。 設定する必要があるすべての設定と変数について説明します。
./bin/init_config初期化スクリプトのコードは、https：//github.com/digitalocean/navigators-guide/blob/master/example-code/02-scale/ch05/init_deploy/bin/init_config [GitHub]で表示できます。 スクリプトが非常に多くの機能を実行していることがわかります。 実際に必要なのは、必要なTerraformおよびAnsible変数ファイルを自動的に作成し、既知の問題が存在しないようにすることです。 スクリプトが最初に行うことは、有効なDigitalOcean APIトークンのプロンプトです。 その後、スクリプトはクラスターの作成に必要ないくつかの一意のキーを作成します。 次に表示されるプロンプトは、プロジェクトに名前を付け、地域を選択することです。 SSHキーが既に構成されている場合（第4章で行ったように）、スクリプトはTerraformにそれを使用するよう指示します。 SSHキーがまだ構成されていない場合は、SSHキーが作成され、DigitalOceanアカウントに自動的に追加されます。 最後に、スクリプトは必要なパスワードの入力を求めます。
スクリプトが完了したら、TerraformプランとAnsible Playbookを実行する準備が整います。 これは、第4章の例と非常に似ていますが、作成および構成するリソースがさらにあります。
すべてを手動で構成する場合、* terraform.tvfars ファイルでTerraformに入力した変数が必要になります。 Ansibleでは、 group_vars *フォルダー内の複数のフォルダー内に必要な変数があります。
初期化スクリプトは、終了する前にTerraformを続行する方法に関する指示を出力しますが、ここでも説明します。
まず、 `+ terraform plan +`を実行すると、DigitalOceanアカウントに次のアイテムが作成されます。
-
1つのロードバランサー。WordPressサイトへのアクセスを提供します。
-
WordPress Webノードとして使用される3つのドロップレット。
-
データベースノードとして使用される3つのドロップレット。
-
データベースクラスター用の2つのHAProxy Load Balancerノード。
-
データベースロードバランサー用の1つのフローティングIPアドレス。
terraform plan次に、計画ファイルとモジュールを解析して、 `+ init +`を使用してTerraformデプロイメントを準備します。
terraform init最後に、 `+ apply +`を使用してDigitalOcean APIを介して作成リクエストを実行します。
terraform applyTerraformがすべてのインフラストラクチャコンポーネントの作成を完了したら、Ansibleを使用してそれらを構成します。 実行するAnsibleロールは3つあります。1つはデータベースサーバーを構成し、1つはデータベースロードバランサーを構成し、1つはすべてのWebノードでWordPressをセットアップします。
1つのコマンドで3つの役割すべてを実行できます。
ansible-playbook -i /usr/local/bin/terraform-inventory site.ymlプレイブックが終了したら、WordPressのセットアップを完了する必要があります。
ブラウザでロードバランサーのIPアドレスにアクセスし、画面上の指示に従ってWordPressの設定を完了します。 第13章では、WordPressインストールをHTTPSで保護する方法について説明しています。
スペースの構成
WordPressアプリサーバーからオブジェクトストレージにメディアファイルを同期するために、https：//wordpress.org/plugins/do-spaces-sync/ [DigitalOcean Spaces Sync]プラグインを使用します。 スペースは、アップロードすることを選択したメディアを保存するための中心的な場所として機能します。
DigitalOcean Spaces Syncプラグインは、Ansibleプレイブックの一部として事前にインストールされていました。 このプラグインを使用するには、まずhttps://www.digitalocean.com/docs/spaces/how-to/create-and-delete/ [コントロールパネルを使用してスペースを作成]を行う必要があります。
スペースが作成されたら、コントロールパネルの[API]ページでhttps://www.digitalocean.com/docs/spaces/how-to/administrative-access/#access-keys [スペースアクセスキーを作成] 。 キーを生成すると、メインキーとシークレットが表示されます。 WordPressプラグインをセットアップするために必要になるため、これらをメモしてください。
ここで、WordPressに戻り、プラグインページにアクセスすると、AnsibleプレイブックのおかげでDigitalOcean Spaces Syncが既にインストールされています。 [アクティブ化]リンクをクリックして、このプラグインを有効にします。 有効にすると、「DigitalOcean Spaces Sync」という名前の設定に新しいリンクが表示されます。
この設定ページで、スペースキー、スペースシークレット、スペース名（この設定ページで「DOスペースコンテナ」とラベル付けされています）、およびエンドポイントを入力します。 エンドポイントは、スペース用に選択したデータセンターに依存することに注意してください。たとえば、NYC3は「https：//nyc3.digitaloceanspaces.com」になります。
接続を確認した後、「ファイルへの完全なURLパス：」の下にスペースの完全なURLを追加します。 NYC3のスペースの場合、これは“ https：//space-name.nyc3.digitaloceanspaces.com”（ `+ space-name +`はスペースの名前）です。 これを入力したら、設定を保存し、ファイルをアップロードしてプラグインをテストします。
[メディア]タブでファイルをアップロードすると、これが自動的にスペースに同期されます。 これを確認するには、DigitalOceanコントロールパネルでSpaceのファイルリストを表示します。
現在、デフォルトでは、このセットアップはCDNを使用しません。 実稼働環境では、これらのメディアファイルをすべての訪問者に迅速かつ確実に提供できるため、CDNの使用を絶対にお勧めします。
後でCDNを追加する場合、「ファイルへの完全なURLパス」をこの新しいCDNのアドレスにポイントする必要があることに注意してください。 また、Spacesと統合するCDNにも取り組んでいます。 これは現在ベータ版ですが、興味のある方は、アカウントマネージャーにアクセスを依頼してください。
セットアップの検証
ブラウザーでロードバランサーのIPアドレスにアクセスすると、次のようなデフォルトのWordPressサイトが表示されます。
image：https：//raw.githubusercontent.com/digitalocean/navigators-guide/master/book/02-scale/ch05-wordpress-screenshot.png [WordPressのデフォルトのインストールスクリーンショット]
最終結果は、完全に機能するWordPressサイトです。 ブログを構成するか、投稿を作成してテストできます。 2つのWebサーバー、1つのHAProxyサーバー、および1つのデータベースノードの電源を切ることができ、Webサイトは完全に機能するはずです。
テストが完了したら、1つのコマンドでこれらすべてのインフラストラクチャコンポーネントをDigitalOceanアカウントから削除できます。 これにより、クラスター全体が削除され、この章の作業がクリーンアップされます。
terraform destroy`+ apply +`を再実行してから、Ansibleプレイブックを再実行してクラスターを再生成できます。
次は何ですか？
高可用性の例を取り上げ、アプリケーションスタック全体にこの概念を適用しました。 この章の例は、完全に冗長でスケーラブルなWordPress Webサイトを作成するために使用されました。 これは、構成管理ツールを活用することで達成されました。 次の章では、展開をさらに自動化および改善する1つの方法を検討します。 本書の残りの部分では、ストレージ、監視、およびセキュリティに関連する概念について説明しますが、さらに重要なことは、それらがビジネスにどのように適用されるか、およびインフラストラクチャを計画する際の考慮事項です。