ナビゲーターガイド：高可用性

投稿日: 2019-11-08 2022-10-10
タグ: High Availability, Solutions

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

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

小さなブログ、大きなアプリケーション、またはAPIを実行しているかどうかは関係ありません。オフラインにしたくはありません。

単一障害点とは、障害が発生した場合にダウンタイムを引き起こすインフラストラクチャの一部です。例として、1つのサーバーを使用してWebサーバーとデータベースの両方をホストする場合があります。多くの場合、停止はこれらの単一障害点によって引き起こされるため、これらの状況を回避するようにインフラストラクチャを設計する必要があります。

高可用性インフラストラクチャには、単一障害点はありません。通常、これは、インフラストラクチャがサービスによって分割され、各サービスが複数のサーバーで実行されていることを意味します。 1つのサーバーに障害が発生した場合、要求を処理するために使用できる他のサーバーがあります。高可用性構成は、冗長性にとって重要であるだけでなく、インフラストラクチャの拡張もより高速で費用効果が高くなります。

ファイルをホストしているWebサービスを想像してみてください。次に、3つの独立したサーバーで実行されていることを想像してください。差し迫った問題がいくつかあります。ユーザーはこれらのサーバーにどのようにアクセスできますか？独立したサーバーごとにDNSレコードを追加できます。残念ながら、ユーザーはランダムにサーバーにルーティングされ、オフラインのサーバーに送信される可能性があります。

インフラストラクチャにロードバランサーを追加することで、これらの落とし穴を回避できます。ロードバランサーは、構成に含まれる各サーバーでヘルスチェックを実行します。サーバーがオフラインの場合、ロードバランサーはサーバーにユーザーリクエストを送信しません。ロードバランサーは、ユーザーを利用可能な最高のサーバーに効率的にルーティングすることでパフォーマンスを向上させます。

この追加を実行するときに発生するもう1つの懸念事項は、ロードバランサー自体が単一障害点にならないようにすることです。私たちはそれを考え、ロードバランサーレイヤーとバックエンドサーバーで高可用性を備えた2つの完全なソリューションを用意しています。

私たちのセットアップ

この章では、いくつかのWebサーバーで負荷分散ソリューションを展開する2つの方法を見ていきます。このセクション（第4章から第6章）の終わりまでに、Webおよびデータベースサービスの前に複数のロードバランサーを設定し、単一障害点がないようにします。

負荷分散を設定するには、さまざまな方法があります。 2つのセットアップ例を紹介します。どちらも、バックエンドでNginxWebサービスを提供します。

最初のソリューションは、 DigitalOceanロードバランサーを使用します。これは、フェイルオーバーリカバリを自動的に処理する高可用性サービスです。また、手動リストの代わりにタグに基づいてトラフィックをドロップレットに転送する機能も含まれているため、スケーリングが簡素化されます。

2番目のソリューションは、HAProxyと DigitalOcean Reserved IP を使用した、よりカスタムな負荷分散ソリューションです。これらは、コントロールパネルまたはAPIのいずれかを使用してリージョン内で自動的に割り当ておよび再割り当てできる静的IPアドレスです。これらを使用して、メインのロードバランサーに障害が発生した場合に、トラフィックをスタンバイロードバランサーに再ルーティングできます。

この本でTerraformとAnsibleを使用するのはこれが初めてなので、このセクションを手動で実行して、独自のプロジェクトを手動で作成する方法を説明します。次の章でより複雑なセットアップに進むと、ほとんどの構成が自動化されます。

DigitalOceanロードバランサーの使用

DigitalOceanロードバランサーのセットアップ

コントローラのドロップレットで、リポジトリのこの章のディレクトリに移動します。

cd /root/navigators-guide/example-code/02-scale/ch04/digitalocean_loadbalancer

このディレクトリには、terraform.tfvars.sampleファイルがあります。このサンプルファイルには、必要な情報を見つけるのに役立つコメントとメモが含まれています。コメントがない場合、ファイルは次のようになります。

do_token = ""

project = "DO-LB"

region = "sfo2"

image_slug = "debian-9-x64"

keys = ""

private_key_path = ""

ssh_fingerprint = ""

public_key = ""

これにより、Nginxを実行するいくつかのドロップレットとともにDigitalOceanロードバランサーが作成されます。各Webサーバーは、個々のDropletのホスト名を含む簡単なウェルカムメッセージを表示します。

コメントの指示に従って変数を入力し、ファイルの名前を次のように変更します terraform.tfvars.

mv terraform.tfvars.sample terraform.tfvars

この構成にはTLS証明書は必要ありませんが、1つをDigitalOceanロードバランサーに追加できます。 DigitalOceanロードバランサー機能は、Let’s Encryptと統合されており、無料で証明書を提供します。 Lets Encryptには、DigitalOceanアカウントに登録および追加されたドメイン名が必要です。

次に、Terraformデプロイメントを準備して実行します。まず、を使用して計画ファイルとモジュールを解析します terraform init. オプションで、実行できます terraform plan 実際のスクリプトを実行するとどうなるかを確認します。準備ができたら、実行します terraform apply DigitalOceanAPIを介して作成リクエストを実行します。

terraform init
terraform apply

次のように入力して実行を確認する必要があります yes、および適用が完了すると通知されます。

この時点で、ロードバランサーのパブリックIPアドレスにアクセスできます（ terraform show）ブラウザで、Webサーバーのサンプルコンテンツを表示します。

Terraformは、クラスターを自動的に削除することもできます。 destroy オプション。このワークフローを使用して迅速なテストを行うことができますが、クラスターに保存されたデータはすべて削除されることに注意してください。 破棄オプションはクラスターを削除します。これは、この章で行う作業からクリーンアップするための最速の方法です。再実行できます apply 新しいクラスターを生成します。

このサンプルクラスターを破棄する前に、期待どおりに実際に高可用性があることをテストしましょう。

クラスターの可用性のテスト

バックエンドWebサーバーの可用性をテストするために、ロードバランサーからの接続を継続的に要求しながら、1台のサーバーをオフラインにすることができます。接続が継続している場合は、サーバーに障害が発生してもサービスがオンラインのままであることがわかります。（ロードバランサー自体はサービスとして実行されるため、フェイルオーバー自体をテストすることはできません。つまり、個々のコンポーネントに直接アクセスする必要はありません。）

ターミナルで次のコマンドを実行します。これにより、1秒に1回ロードバランサーに接続されます。

while true; do curl -k load_balancer_ip; sleep 1; done

次のような連続出力が表示されます。

Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!

バックエンドドロップレットの1つをオフにしてみてください。ドロップレットをオフラインにしても、他のロードバランサーのバックエンドから有効な応答を返すテストが表示されるはずです。オフにしたドロップレットが応答しなくなったことに気付くでしょう。電源を入れ直すと、ロードバランサーの構成済みチェックに合格すると、自動的にローテーションに追加されます。

（実行中のテストを停止するためのヘルプが必要な場合は、ループを終了することができます CTRL-C キーボードコマンド）

クラスターのスケーリング

クラスタの初期設定では、3つのバックエンドドロップレットを使用します。バックエンドドロップレットの数の設定は、variables.tfファイルのデフォルトの変数宣言にあります。に行を追加することでオーバーライドできます terraform.tfvars 変数を使って node_count 5に設定します。行が追加されたら、Terraformプランを再適用する必要があります。

terraform apply

Terraformはここで本当に輝いています。この変数に基づいてドロップレットの数を変更するロジックを処理するため、ドロップレットを自動的に作成または破棄します。 node_count 変数は増加または減少します。

実行中のターミナルで curl ロードバランサーに出力を確認します。新しいドロップレットがプロビジョニングされると、それらが自動的に応答を開始するのがわかります。

Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-04!
Welcome to DO-LB-backend-05!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-04!
Welcome to DO-LB-backend-05!
Welcome to DO-LB-backend-01!

先に進む前に、このテストプロジェクトを破棄することをお勧めします。 Terraformは、プランの現在の状態を現在の作業ディレクトリに保持します。 Terraformを介してリソースを破棄すると、状態が自動的にクリアされます。

terraform destroy

HAProxyとDigitalOcean予約済みIPアドレスの使用

カスタムの負荷分散ソリューションを導入するのが正しい選択かもしれません。現時点でDigitalOceanロードバランサーがサポートしていないオプションがいくつかあります。この例としては、バックエンドとして複数のサイトまたはアプリケーションをホストすること、複数のTLS証明書、プロキシプロトコルのサポート、または特定のTCPパラメーターの調整があります。

この例では、フェイルオーバーにDigitalOcean予約済みIPを使用してクラスター化されたHAProxyv1.8ロードバランサーを使用します。

HAProxyの設定

コントローラのドロップレットで、リポジトリのこの章のディレクトリに移動します。

cd /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancer

do_token = ""

project = "HAPROXY-LB"

region = "sfo2"

image_slug = "debian-9-x64"

keys = ""

private_key_path = ""

ssh_fingerprint = ""

public_key = ""

コメントの指示に従って変数を入力し、ファイルの名前を次のように変更します terraform.tfvars.

mv terraform.tfvars.sample terraform.tfvars

terraform init
terraform apply

次のように入力して実行を確認する必要があります yes、および適用が完了すると通知されます。

実行した場合 terraform show これで、デプロイしたリソースを確認できます。リソースの各セット（つまりドロップレット）は、Terraform構成ファイルのリソース名に従ってグループ名に配置されます。この例では、haproxy.tfファイルのリソース宣言がこれらのグループを決定します。

3つのグループは load_balancer HAProxyの場合、 web_node Nginxの場合、および fip 予約済みIPの場合。あなたはで見ることができます terraform-inventory -inventory AnsibleのinvintoryをINI形式で取得するか、JSONを出力するには -list オプション。

この時点で、必要なドロップレットが作成されて実行されていますが、それでも構成する必要があります。

Ansibleを使用したドロップレットの構成

Ansibleを使用してドロップレットの構成を自動化します。いくつかのAnsibleロールをダウンロードするように事前構成された基本のAnsibleプレイブックがあります。これらのAnsibleの役割は、requirements.ymlファイルにリストされています。それらを1つずつインストールする必要はありません。 AnsibleGalaxyで必要な役割をダウンロードできます。

このコマンドは、役割を roles ディレクトリ。

ansible-galaxy install -r requirements.yml

この役割に設定する必要のある変数は他にもいくつかあります。/root/Navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancer/group_vars/load_balancer/[に戻ります。 X192X]ディレクトリ。既存のvars.ymlファイルを表示すると、次のように表示されます。 do_token と ha_auth_key の値が割り当てられています vault_do_token と vault_ha_auth_key、それぞれ。 vault.yml という名前のセカンダリファイルを作成し、初期化します。 vault_ 変数。

変数を設定する前に、2つのことが必要になります。フェイルオーバーシナリオの予約済みIP割り当てを処理するために使用されるDigitalOceanAPIトークン、およびクラスターメンバーの認証に使用されるSHA-1ハッシュ。これを作成するのに役立つツールがあります。

cd /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancer/
./gen_auth_key

そのauth_keyが作成されたら、先に進んで group_vars / load_balancer /vault.ymlファイルを作成します。ファイルは次のようになります。

---
vault_do_token: "79da2e7b8795a24c790a367e4929afd22bb833f59bca00a008e2d91cb5e4285e"
vault_ha_auth_key: "c4b25a9f95548177a07d425d6bc9e00c36ec4ff8"

これらのキーのセキュリティと機密性は、インフラストラクチャにとって不可欠です。このvault.ymlファイルを表示または編集できるユーザーを制限したいと思います。 Ansibleには、という名前の暗号化システムが組み込まれています ansible-vault.

次のコマンドを使用して、ファイルを暗号化します。

ansible-vault encrypt vault.yml

このプロセスでは、パスワードの入力を求められます。 Ansibleプレイブックを実行するたびに、このパスワードの入力も求められます。暗号化されたファイルを編集する必要がある場合は、 ansible-vault. Ansible Vaultのドキュメントには、この機能のすべての機能の完全なリストがあります。

ansible-vault edit vault.yml

Ansibleは、プレイブックを実行するたびに復号化パスワードを要求しますが、これは自動化には理想的とは言えません。パスワードはシステムの別の場所に保存できるため、権限制御を追加することでパスワードを保護できます。パスワードを保存するファイルを作成するには、次のコマンドを実行できます echo 'password' > ~/.vaultpass.txt または、テキストエディタを使用してファイルを手動で作成します。非特権ユーザーがこのファイルにアクセスできないことを確認する必要があります。コメントを外す vault_password_file /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancer/ansible.cfg構成ファイルの行。これにより、プレイブックを実行するたびにAnsibleがボールトパスワードを要求するのを防ぐことができます。パスワードの保存に使用するファイルへのパスとファイル名を変更することもできますが、gitリポジトリに入れないようにしてください。パスワードやシークレットトークンを誤ってコミットしてプッシュしたくない。

これで、メインのAnsibleプレイブックを実行する準備が整いました。リポジトリのルートに戻って実行します ansible-playbook -i /usr/local/bin/terraform-inventory site.yml. ここでも、現在実行中の役割、役割が現在実行中のタスク、および変更またはエラーが検出されたかどうかを示すテキストのストリームが画面に表示され始めます。プレイの最後に、ホストごとの合計が次のようになっているプレイの要約が表示されます。

PLAY RECAP *********************************************************************
138.68.50.232              : ok=1    changed=0    unreachable=0    failed=0   
159.65.78.225              : ok=1    changed=0    unreachable=0    failed=0   
165.227.9.176              : ok=40   changed=38   unreachable=0    failed=0   
178.128.128.168            : ok=1    changed=0    unreachable=0    failed=0   
178.128.3.35               : ok=40   changed=38   unreachable=0    failed=0   
206.189.174.220            : ok=1    changed=0    unreachable=0    failed=0

これで、予約済みIPアドレスにアクセスしてサイト（この場合は単純なHTMLページ）にアクセスするか、予約済みIPアドレスを指すドメインを追加できます。

クラスターの可用性のテスト

バックエンドWebサーバーの可用性をテストするために、ロードバランサーからの接続を継続的に要求しながら、1つをオフラインにすることができます。接続が継続している場合は、サーバーに障害が発生してもサービスがオンラインのままであることがわかります。

ターミナルで次のコマンドを実行します。これにより、1秒に1回ロードバランサーに接続されます。

while true; do curl -k reserved_ip; sleep 1; done

次のような連続出力が表示されます。

Welcome to HAPROXY-LB-backend-01!
Welcome to HAPROXY-LB-backend-02!
Welcome to HAPROXY-LB-backend-03!
Welcome to HAPROXY-LB-backend-01!
Welcome to HAPROXY-LB-backend-02!
Welcome to HAPROXY-LB-backend-03!

バックエンドドロップレットの1つをオフにしてみてください。ドロップレットをオフラインにしても、curlが他のロードバランサーのバックエンドから有効な応答を返すのを確認できます。オフにしたドロップレットが応答しなくなったことに気付くでしょう。電源を入れ直すと、ロードバランサーの構成済みチェックに合格すると、ローテーションに追加されます。

テストを実行したまま、メインのHAProxyドロップレットの電源をオフにすると、いくつかのリクエストがドロップされた後、予約済みIPアドレスがセカンダリのHAProxyドロップレットにリダイレクトされることがわかります。セカンダリHAProxyドロップレットが自動的に取得され、テストが実行され続けます。

（実行中のテストを停止するためのヘルプが必要な場合は、ループを終了することができます CTRL-C キーボードコマンド）

クラスターのスケーリング

terraform apply

リソース数を変更するたびに、ドロップレットに対してAnsibleを再度実行して、バックエンドドロップレットを構成し、HAProxyの構成を変更する必要があります。

ansible-playbook -i /usr/local/bin/terraform-inventory site.yml

Welcome to HAPROXY-LB-backend-02!
Welcome to HAPROXY-LB-backend-03!
Welcome to HAPROXY-LB-backend-01!
Welcome to HAPROXY-LB-backend-02!
Welcome to HAPROXY-LB-backend-03!
Welcome to HAPROXY-LB-backend-04!
Welcome to HAPROXY-LB-backend-05!
Welcome to HAPROXY-LB-backend-01!
Welcome to HAPROXY-LB-backend-02!
Welcome to HAPROXY-LB-backend-03!
Welcome to HAPROXY-LB-backend-04!
Welcome to HAPROXY-LB-backend-05!
Welcome to HAPROXY-LB-backend-01!

完了したら、Terraformで作成されたリソースをクリーンアップできます。 destroy. この方法でクラスターを破棄すると、すべてのデータが失われます。

terraform destroy

次は何ですか？

シンプルなWebアプリケーションを使用して、複数のドロップレットで実行し、2種類のロードバランサーを使用してトラフィックを操作可能なドロップレットに転送することで、高可用性を実現しました。これらは、冗長性とダウンタイムの防止のための基本的な概念です。

次の章では、これらの概念を拡張して、ロードバランサーの構成を維持する方法、アプリケーションとアプリケーションが存在するドロップレットを管理する方法、およびユーザーセッション、ファイルストレージ、データベースを処理する方法について説明します。引き続きTerraformとAnsibleを使用して、8つのドロップレットのクラスターで実行されているWordPressをデプロイします。

getdocs

13036