注：これは、DigitalOceanSolutionsEngineersが提供するナビゲーターガイドブックの内容の初期リリースバージョンです。 この本の目的は、ビジネス顧客がインフラストラクチャのニーズを計画し、その過程で実用的な例を提供し、技術的なニュアンスと、いくつかの決定を他の決定よりも優れたものにする「理由」を含めるのを支援することです。

この本と付随するコードは、GitHubリポジトリで公開されます。 これは初期のリリースであるため、この本はまだ完成しておらず、リポジトリはまだ公開されていませんが、ご期待ください。

前の章では、インフラストラクチャの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
  }
}

ロードバランサーは不変のリソース（ドロップレットなど）ではなくサービスであるため、構成引数を変更してもロードバランサー全体が再作成されることはありません。 その場で更新されます。 サポートされている引数と出力属性の詳細については、Terraformのドキュメントを参照してください。

DigitalOcean Load Balancerを使用して、WebサーバーへのパブリックWebトラフィックの負荷分散を処理しています。

HAProxyクラスター

低レベルの負荷分散設定へのアクセスや複数のバックエンドサービスのサポートなど、より複雑な構成が必要な場合は、独自のロードバランサークラスターを設定できます。 前の章のHAProxyの例を続けます。

AnsibleはJinja2テンプレートシステムを使用しており、構成ファイルの作成と更新のプロセスを簡素化します。 Jinja2は、ifステートメント、ループ、数学演算、組み込みフィルターの大規模なライブラリなど、プログラミング言語で見られる変数と制御構造の使用をサポートしています。 この要約は、Ansible内のテンプレートシステムを正当化するものではありません。 詳細については、Ansibleのドキュメントを確認することをお勧めします。

構成が変更されたときに更新をトリガーする方法はいくつかあります。 サイトの需要があまり変動しない場合、または変更がいつ行われるかが事前にわかっている場合は、完全に自動化されたスケーリングを設定する必要がないか、設定する必要がない場合があります。 代わりに、Ansibleプレイブックを手動で実行するか、Terraformデプロイメントスクリプトへの変更をgitリポジトリにプッシュしたときに実行するように設定できます。

もう1つのオプションは、サービス検出にConsulを使用し、構成することです。 consul-template ロードバランサーで構成ファイルを自動的に更新します。 これにより、インフラストラクチャ全体にドロップレットが追加されますが、他のサービスにもConsulを使用できます。

HAProxyクラスターを使用して、データベースクラスターの負荷分散を処理しています。

ユーザーセッション

セッションレビュー

ユーザーがロードバランサーを介してホストされているサイトにアクセスした場合、次のリクエストが同じバックエンドサーバーによって処理される保証はありません。 単純な静的ページの場合、これは問題にはなりませんが、サービスがユーザーのセッションの知識を必要とする場合（ユーザーがログインした場合など）、それを処理する必要があります。 これに対処するためのいくつかのオプションがあり、スタックのさまざまなポイントで実装できます。

ユーザーセッションの処理方法は、ユースケースによって異なります。 ここにいくつかのオプションがあります：

IPソースアフィニティは、同じIPアドレスからのすべてのリクエストを同じバックエンドに送信します。 これは、ユーザーがすべて同じIPアドレスを持っているため、NATを使用してルーターの背後から接続する可能性がある状況では最適な選択ではありません。

ロードバランサーセッションとアプリケーションセッションのオプションは似ています。 どちらも、リクエストを送信するバックエンドを決定するためにIPヘッダー情報を確認するようにロードバランサーを構成します。 IPソースアフィニティ方式とは異なり、NATの背後にいるユーザーは個々のユーザーとして識別されます。 複数の異なるデータポイントに基づいてユーザーIDを構成するために使用できる、HAProxyロードバランサーにスティックテーブルを実装することで、これをさらに調整できます。

ファイルシステムレプリケーションは、セッションが保存されているファイルシステム内のパスをレプリケートし、すべてのバックエンドがすべてのセッションにアクセスできるようにします。 考慮すべき重要な側面の1つは、レプリケーションが行われる速度です。 方法によっては、複製するセッションの数が多いバックエンドノード間のわずかな遅延でさえ、エンドユーザーに問題を引き起こす可能性があります。

データベースまたはメモリ内データストアの使用も同様です。 どちらの場合も、ユーザーセッションをデータベースまたはRedisなどのメモリ内キャッシュに保存する方法でアプリケーションを作成する必要があります。 データベースを使用すると、アプリケーションが他のデータ要求のためにデータベースに接続するようにすでに設定されているため、便利な場合があります。 非常にアクティブなサイトの場合、これによりデータベース自体のオーバーヘッドが増える可能性がありますが、ほとんどの場合、追加の負荷はごくわずかです。 RedisやMemcachedなどのメモリ内キャッシュを使用すると、さらにいくつかのドロップレットを作成する必要がありますが、これらは非常に高速で用途の広いソリューションであり、パフォーマンスを向上させるためにデータベースクエリ応答をキャッシュするためにも使用できます。

WordPressはセッションにデータベースを使用するようにすでに構成されているため、これが使用するソリューションです。

ファイルストレージ

ファイルストレージレビュー：

アプリケーションが使用するファイルは一貫している必要があります。 すべてのサーバーが同じリソースのセットにアクセスできる必要があります。 この問題への適切なアプローチの1つは、ストレージ機能をバックエンドアプリサーバーから切り離し、代わりにファイルストレージに別のサービスを使用することです。 静的アセットの場合、オブジェクトストレージソリューションを使用できます。 DigitalOcean Spacesは、冗長性が組み込まれた高可用性オブジェクトストレージサービスです。 ストレージオプション、特にスペースについては、第7章で詳しく説明します。

セッションと同様に、アプリケーションノード間でローカルファイルシステムレプリケーションを使用してファイルストレージを処理できます。 ただし、これにより、インフラストラクチャに別のサービスが追加され、構成が追加で変更されます。

より簡単な解決策は、特にWordPressに DigitalOcean Spaces Sync プラグインがすでにあるため、DigitalOceanSpacesなどのオブジェクトストレージを使用することです。 セットアップは単一のプラグインのインストールと構成に限定されるため、この章で使用するソリューションはこれです。

データベース

データベースレビュー

ファイルストレージと同様に、データベースはすべてのバックエンドドロップレットにアクセスできる必要があります。 クラスター全体でデータベースの挿入と更新を複製する方法は、機能的なクラスター化データベースソリューションにとって不可欠です。

さらに、データベースは高可用性である必要があります。つまり、冗長性と自動フェイルオーバーを備えている必要があります。 これは、ロードバランサーの背後に配置するよりも複雑になる可能性があります。これは、システムがデータの一貫性を処理する必要があるためです。たとえば、異なるノードに対して競合する更新が行われた場合に発生します。

この例では、MariaDBGaleraクラスターを使用してこれらの問題を処理します。 Galeraは、すべてのデータベースノードへの同期レプリケーションを処理します。各データベースノードは、完全なプライマリデータベースサーバーとして機能します。 これは、クラスター内の各ノードに対して読み取りと書き込みが可能であり、すべてが同期されていることを意味します。 特定のノードがプライマリ書き込みサーバーとして選択される、プライマリおよびセカンダリ形式のレプリケーションを含むデータベースをクラスター化する方法は他にもあります。

各クラスターソリューションにはメリットがあります。 この演習では、データの整合性が自動的に処理され、クラスター内のすべてのノードがプライマリサーバーとして機能できるため、Galeraが最大のメリットをもたらします。 フェイルオーバーまたはフェイルバックの手順は必要ありません。

WordPressはほとんどすべてをデータベースに依存しており、単一の外部データベースサーバーが単一障害点です。 データベースクラスターにはいくつかのオプションがあり、ケースに最適なものに基づいて、さまざまな部分を組み合わせて組み合わせることができます。

この章では、MySQLのフォークであるMariaDB上で実行されるGaleraクラスターを構築します。 これは、DigitalOcean予約済みIPが接続されたいくつかのHAProxyノードの背後で実行されます。

このためのソースリポジトリには、https://github.com/DO-Solutions/galera-tf-modからアクセスできます。 デフォルトで3つのノードを持つクラスターへのTCPルーティングを設定します。 使用するノードが3つ未満の場合、スプリットブレインの状況を回避してクラスターの動作を維持するには、 GaleraArbitratorノードが必要になります。 メインのテラフォームファイル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

初期化スクリプトのコードは、GitHubで確認できます。 スクリプトがかなりの数の機能を実行していることがわかります。 実際に行っているのは、必要なTerraformおよびAnsible変数ファイルを自動的に作成し、既知の問題が存在しないことを確認することです。 スクリプトが最初に行うことは、有効なDigitalOceanAPIトークンの入力を求めることです。 その後、スクリプトはクラスターの作成に必要ないくつかの一意のキーを作成します。 次に表示されるプロンプトは、プロジェクトに名前を付け、地域を選択することです。 SSHキーがすでに構成されている場合（第4章で行ったように）、スクリプトはTerraformにそれを使用するように指示します。 SSHキーがまだ構成されていない場合は、SSHキーが作成され、DigitalOceanアカウントに自動的に追加されます。 最後に、スクリプトは必要なパスワードの入力を求めます。

スクリプトが完了すると、TerraformプランとAnsibleプレイブックを実行する準備が整います。 これは第4章の例と非常に似ていますが、作成および構成されているリソースがさらにあります。

すべてを手動で構成する場合は、terraform.tvfarsファイルにTerraform用に入力された変数が必要になります。 Ansibleには、group_varsフォルダー内の複数のフォルダー内に変数が必要です。

初期化スクリプトは、終了する前にTerraformを続行する方法の説明を出力しますが、ここでも説明します。

まず、ランニング terraform plan DigitalOceanアカウントに次のアイテムが作成されます。

  1. WordPressサイトへのアクセスを提供する1つのロードバランサー。
  2. WordPressWebノードとして使用される3つのドロップレット。
  3. データベースノードとして使用される3つのドロップレット。
  4. データベースクラスター用の2つのHAProxyロードバランサーノード。
  5. データベースロードバランサー用の1つの予約済みIPアドレス。
terraform plan

次に、プランファイルとモジュールを解析して、を使用してTerraformデプロイメントを準備します。 init.

terraform init

最後に、を使用してDigitalOceanAPIを介して作成リクエストを実行します apply.

terraform apply

Terraformがすべてのインフラストラクチャコンポーネントの作成を完了したら、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アプリサーバーからオブジェクトストレージにメディアファイルを同期するために、 DigitalOcean SpacesSyncプラグインを使用します。 スペースは、アップロードすることを選択したメディアを保存するための中心的な場所として機能します。

DigitalOcean Spaces Syncプラグインは、Ansibleプレイブックの一部としてプリインストールされています。 このプラグインを使用するには、最初にコントロールパネルを使用してスペースを作成する必要があります。

スペースが作成されたら、コントロールパネルの[API]ページでスペースアクセスキーを作成します。 キーを生成すると、メインキーとシークレットが表示されます。 WordPressプラグインを設定するために必要になるため、これらに注意してください。

ここで、WordPressに戻り、プラグインページにアクセスすると、AnsibleプレイブックのおかげでDigitalOceanSpacesSyncが既にインストールされていることがわかります。 このプラグインを有効にするには、[アクティブ化]リンクをクリックします。 有効にすると、「DigitalOceanSpacesSync」という名前の新しいリンクが設定に表示されます。

この設定ページで、スペースキー、スペースシークレット、スペース名（この設定ページでは「DOスペースコンテナ」とラベル付けされています）、およびエンドポイントを入力します。 Keep in mind the endpoint will depend on which datacenter you’ve chosen for your Space: for example, NYC3 would be “https://`nyc3`.digitaloceanspaces.com”.

接続を確認した後、「フルURL-ファイルへのパス：」の下にスペースのフルURLを追加します。 For a Space in NYC3, this would be “https://`space-name`.nyc3.digitaloceanspaces.com” (where space-name スペースの名前です）。 これを入力したら、設定を保存し、ファイルをアップロードしてプラグインをテストします。

「メディア」タブでファイルをアップロードすると、これが自動的にスペースに同期されるのがわかります。 これは、DigitalOceanコントロールパネルでSpaceのファイルリストを表示することで確認できます。

現在、デフォルトでは、このセットアップはCDNを使用しません。 実稼働環境では、CDNを使用することを強くお勧めします。これにより、すべての訪問者にこれらのメディアファイルを迅速かつ確実に提供できるようになります。

後でCDNを追加する場合は、「ファイルへの完全なURLパス」がこの新しいCDNのアドレスを指す必要があることに注意してください。 Spacesと統合するCDNにも取り組んでいます。 これは現在ベータ版ですが、興味がある場合はアカウントマネージャーにアクセスを依頼してください。

セットアップの確認

ブラウザでロードバランサのIPアドレスに移動すると、次のようなデフォルトのWordPressサイトが表示されます。

最終的には、完全に機能するWordPressサイトになります。 ブログを構成するか、投稿を作成することでテストできます。 2つのWebサーバー、1つのHAProxyサーバー、および1つのデータベースノードの電源を切ることができます。Webサイトは引き続き完全に機能するはずです。

テストが完了したら、1つのコマンドでこれらのインフラストラクチャコンポーネントをすべてDigitalOceanアカウントから削除できます。 これにより、クラスター全体が削除され、この章の作業がクリーンアップされます。

terraform destroy

再実行できます apply 次に、Ansibleプレイブックを再実行して、クラスターを再生成します。

次は何ですか？

高可用性の例を取り上げ、アプリケーションスタック全体にこの概念を適用しました。 この章の例は、完全に冗長でスケーラブルなWordPressWebサイトを作成するために使用されました。 これは、構成管理ツールを活用することで達成されました。 次の章では、展開をさらに自動化および改善する1つの方法について説明します。 この本の残りの部分では、ストレージ、監視、およびセキュリティに関連する概念について説明しますが、さらに重要なのは、それらがビジネスにどのように適用されるか、およびインフラストラクチャを計画するときに考慮すべきことです。