ナビゲーターガイド：高可用性
注：これは、DigitalOceanSolutionsEngineersが提供するナビゲーターガイドブックの内容の初期リリースバージョンです。 この本の目的は、ビジネス顧客がインフラストラクチャのニーズを計画し、その過程で実用的な例を提供し、技術的なニュアンスと、いくつかの決定を他の決定よりも優れたものにする「理由」を含めるのを支援することです。
この本と付随するコードは、GitHubリポジトリで公開されます。 これは初期のリリースであるため、この本はまだ完成しておらず、リポジトリはまだ公開されていませんが、ご期待ください。
小さなブログ、大きなアプリケーション、またはAPIを実行しているかどうかは関係ありません。 オフラインにしたくはありません。
単一障害点とは、障害が発生した場合にダウンタイムを引き起こすインフラストラクチャの一部です。 例として、1つのサーバーを使用してWebサーバーとデータベースの両方をホストする場合があります。 多くの場合、停止はこれらの単一障害点によって引き起こされるため、これらの状況を回避するようにインフラストラクチャを設計する必要があります。
高可用性インフラストラクチャには、単一障害点はありません。 通常、これは、インフラストラクチャがサービスによって分割され、各サービスが複数のサーバーで実行されていることを意味します。 1つのサーバーに障害が発生した場合、要求を処理するために使用できる他のサーバーがあります。 高可用性構成は、冗長性にとって重要であるだけでなく、インフラストラクチャの拡張もより高速で費用効果が高くなります。
ファイルをホストしているWebサービスを想像してみてください。 次に、3つの独立したサーバーで実行されていることを想像してください。 差し迫った問題がいくつかあります。 ユーザーはこれらのサーバーにどのようにアクセスできますか？ 独立したサーバーごとにDNSレコードを追加できます。 残念ながら、ユーザーはランダムにサーバーにルーティングされ、オフラインのサーバーに送信される可能性があります。
インフラストラクチャにロードバランサーを追加することで、これらの落とし穴を回避できます。 ロードバランサーは、構成に含まれる各サーバーでヘルスチェックを実行します。 サーバーがオフラインの場合、ロードバランサーはサーバーにユーザーリクエストを送信しません。 ロードバランサーは、ユーザーを利用可能な最高のサーバーに効率的にルーティングすることでパフォーマンスを向上させます。
この追加を実行するときに発生するもう1つの懸念事項は、ロードバランサー自体が単一障害点にならないようにすることです。 私たちはそれを考え、ロードバランサーレイヤーとバックエンドサーバーで高可用性を備えた2つの完全なソリューションを用意しています。
私たちのセットアップ
この章では、いくつかのWebサーバーで負荷分散ソリューションを展開する2つの方法を見ていきます。 このセクション（第4章から第6章）の終わりまでに、Webおよびデータベースサービスの前に複数のロードバランサーを設定し、単一障害点がないようにします。
負荷分散を設定するには、さまざまな方法があります。 2つのセットアップ例を紹介します。どちらも、バックエンドでNginxWebサービスを提供します。
最初のソリューションは、 DigitalOceanロードバランサーを使用します。これは、フェイルオーバーリカバリを自動的に処理する高可用性サービスです。 また、手動リストの代わりにタグに基づいてトラフィックをドロップレットに転送する機能も含まれているため、スケーリングが簡素化されます。
2番目のソリューションは、HAProxyと DigitalOcean Floating IP を使用したよりカスタムな負荷分散ソリューションです。これらは静的IPアドレスであり、コントロールパネルまたはAPIを使用してリージョン内で自動的に割り当ておよび再割り当てできます。 これらを使用して、メインのロードバランサーに障害が発生した場合に、トラフィックをスタンバイロードバランサーに再ルーティングできます。
この本で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ファイルのデフォルトの変数宣言にあります。 変数node_countを5に設定して、terraform.tfvarsに行を追加することでオーバーライドできます。 行が追加されたら、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パラメーターの調整があります。
この例では、フェイルオーバーにDigitalOceanFloatingIPを使用してクラスター化されたHAProxyv1.8ロードバランサーを使用しています。
HAProxyの設定
コントローラのドロップレットで、リポジトリのこの章のディレクトリに移動します。
cd /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancer
このディレクトリには、terraform.tfvars.sampleファイルがあります。 このサンプルファイルには、必要な情報を見つけるのに役立つコメントとメモが含まれています。 コメントがない場合、ファイルは次のようになります。
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デプロイメントを準備して実行します。 まず、terraform initを使用してプランファイルとモジュールを解析します。 オプションで、terraform planを実行して、実際のスクリプトを実行したときに何が起こるかを確認できます。 準備ができたら、terraform applyを実行して、DigitalOceanAPIを介して作成リクエストを実行します。
terraform init terraform apply
yesと入力して実行を確認する必要があり、適用が完了すると通知されます。
ここでterraform showを実行すると、デプロイしたリソースを確認できます。 リソースの各セット（つまり ドロップレット）は、Terraform構成ファイルのリソース名に従ってグループ名に配置されます。 この例では、haproxy.tfファイルのリソース宣言がこれらのグループを決定します。
3つのグループは、HAProxyの場合はload_balancer、Nginxの場合はweb_node、フローティングIPの場合はfipです。 terraform-inventory -inventoryを調べて、INI形式のAnsible invintoryを取得するか、-listオプションを使用してJSONを出力できます。
この時点で、必要なドロップレットが作成されて実行されていますが、それでも構成する必要があります。
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と[の値が割り当てられていることがわかります。 X135X]、それぞれ。 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を実行するか、テキストエディタを使用して手動でファイルを作成します。 非特権ユーザーがこのファイルにアクセスできないことを確認する必要があります。 /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancer/ansible.cfg構成ファイルのvault_password_file行のコメントを解除します。 これにより、プレイブックを実行するたびに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 floating_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キーボードコマンドを使用してループを終了できます）
クラスターのスケーリング
クラスタの初期設定では、3つのバックエンドドロップレットを使用します。 バックエンドドロップレットの数の設定は、variables.tfファイルのデフォルトの変数宣言にあります。 変数node_countを5に設定して、terraform.tfvarsに行を追加することでオーバーライドできます。
terraform apply
Terraformはここで本当に輝いています。 この変数に基づいてドロップレットの数を変更するロジックを処理するため、node_count変数が増減すると、ドロップレットが自動的に作成または破棄されます。
リソース数を変更するたびに、ドロップレットに対してAnsibleを再度実行して、バックエンドドロップレットを構成し、HAProxyの構成を変更する必要があります。
ansible-playbook -i /usr/local/bin/terraform-inventory site.yml
ロードバランサーに対してcurlを実行しているターミナルで、出力を確認します。 新しいドロップレットがプロビジョニングされると、それらが自動的に応答を開始するのがわかります。
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!
完了したら、destroyで作成されたTerraformのリソースをクリーンアップできます。 この方法でクラスターを破棄すると、すべてのデータが失われます。
terraform destroy
次は何ですか？
シンプルなWebアプリケーションを使用して、複数のドロップレットで実行し、2種類のロードバランサーを使用してトラフィックを操作可能なドロップレットに転送することで、高可用性を実現しました。 これらは、冗長性とダウンタイムの防止のための基本的な概念です。
次の章では、これらの概念を拡張して、ロードバランサーの構成を維持する方法、アプリケーションとアプリケーションが存在するドロップレットを管理する方法、およびユーザーセッション、ファイルストレージ、データベースを処理する方法について説明します。 引き続きTerraformとAnsibleを使用して、8つのドロップレットのクラスターで実行されているWordPressをデプロイします。
