LoginSignup
7
3

More than 3 years have passed since last update.

@S_Katzin株式会社スタイルズ

ALB を利用したサーバー負荷分散、可用性向上に向けた取り組み - Nextcloud 環境の構築を通じて AWS での環境構築を体験する④

Last updated at Posted at 2020-02-04

「Nextcloud 環境の構築を通じて AWS での環境構築を体験する」 の第 4 回となります。

「Nextcloud 環境の構築を通じて AWS での環境構築を体験する」 シリーズの記事は下記からどうぞ。

はじめに

今回は、前回記事 で作成した環境構成のうち、Web サーバーを複数台構成することにより負荷分散ならびに可用性の向上を図ります。これを実現するために AWS のロードバランシングサービスを利用します。

また、可用性向上対策にあわせて、 現在シングル AZ となっている RDS をマルチ AZ に変更し、こちらも可用性向上を図ります。

今回構築する Nextcloud on AWS 環境

次のような構成となります。EC2 を 1 つ増設し、これを AWS のロードランシングサービスである ALB (Application Load Balancer) で負荷分散する形となります。

今回は、RDS のマルチ AZ 対応もあわせて行います。

image.png

# Web サービスでロードバランサを運用するといかにも「運用してるなぁ」という気がするのは私だけでしょうか w

今回追加で利用する AWS サービス

サービス名 役割
Elastic Load Balancing (ELB) スケーラブル、従量課金で利用できるマネージド型の負荷分散システム。今回は Application Load Balancer (ALB) というロードバランサーを利用します。
AWS Certificate Manager (ACM) パブリックとプライベートの TLS/SSL 証明書を簡単に作成、またマネージドな更新などの管理機能。

# AWS のロードバランサーのサービスの総称は "Elastic Load Balancing" ですが、その中で提供されるアプリケーションロードバランサーは "Application Load Balancer" です。

変更手順

Nextcloud サービスの一時停止

  1. Nextcloud の EC2 仮想サーバーに SSH 接続します。

  2. Nextcloud の cron を停止します。

    sudo mv /etc/cron.d/nextcloud-cron-php /etc/cron.d/.nextcloud-cron-php

  3. Nginx を停止します。

    sudo systemctl stop nginx

  4. Nginx の設定ファイルを変更します。今回の構成変更により、Web サーバー内で TLS/SSL の解決は行わず、前段のロードバランサーで解決するようにするため、 Web サーバーは HTTP のみで動作する形とします。

    sudo cp -pi /etc/nginx/conf.d/nextcloud.conf{,.orig}

sudo vi /etc/nginx/conf.d/nextcloud.conf
※以下のように一部行を削除と修正をします。
sudo diff /etc/nginx/conf.d/nextcloud.conf.orig /etc/nginx/conf.d/nextcloud.conf
10,23d9
<     # enforce https
<     return 301 https://$server_name:443$request_uri;
< }
< 
< server {
<     listen 443 ssl http2;
<     listen [::]:443 ssl http2;
<     server_name aws-nc.nextcloud.biz;
< 
<     # Use Mozilla's guidelines for SSL/TLS settings
<     # https://mozilla.github.io/server-side-tls/ssl-config-generator/
<     # NOTE: some settings below might be redundant
<     ssl_certificate /etc/letsencrypt/live/【Nextcloud を動かすサーバーの FQDN】/fullchain.pem;
<     ssl_certificate_key /etc/letsencrypt/live/【Nextcloud を動かすサーバーの FQDN】/privkey.pem;
65c51
<       return 301 $scheme://$host:$server_port/remote.php/dav;
---
>         return 301 https://【Nextcloud を動かすサーバーの FQDN】/remote.php/dav;
68c54
<       return 301 $scheme://$host:$server_port/remote.php/dav;
---
>         return 301 https://【Nextcloud を動かすサーバーの FQDN】/remote.php/dav;

  5. Nginx の設定ファイルを変更します。今回の構成変更により、ロードバランサがリバースプロキシとなるため、ロードバランサ経由でも問題なく Nextcloud にアクセスできるように設定を追加します。

    sudo cp -pi /var/www/html/nextcloud/config/config.php{,.orig3}

sudo vi /var/www/html/nextcloud/config/config.php
※以下のように一部行を追加をします。
sudo diff /var/www/html/nextcloud/config/config.php.orig3 /var/www/html/nextcloud/config/config.php
31a32,37
>   'trusted_proxies' => 
>   array (
>     0 => '【VPC のネットワークアドレス帯】',
>   ),
>   'overwriteprotocol' => 'https',
>   'overwritehost' => '【Nextcloud を動かすサーバーの FQDN】',

    # trusted_proxies は、構築している VPC のネットワークアドレス帯をすべて指定しておきます (デフォルト VPC だと 172.31.0.0/16)。これは、 ALB がマネージドサービスのため一意の IP アドレスで固定されないためです。
    ※もう少し厳しくするのであれば、下の設定例のようにパブリックサブネットのIPアドレス帯を 1 つずつ array に追加していく感じでしょうかね。

    (複数の IP アドレス帯を指定する場合の設定例)
  'trusted_proxies' => 
  array (
    0 => '192.168.100.0/24',
    1 => '192.168.102.0/24',
    2 => '192.168.104.0/24',
  ),

  6. EC2 サーバーをシャットダウンします。

    sudo shutdown -h now

RDS のマルチ AZ 対応

  1. AWS マネジメントコンソールにログインし、RDS サービスを選択します。「DB インスタンス」をクリックします。
    image.png

  2. 以前作成した Nextcloud のデータベースを選択し「変更」をクリックします。
    image.png

  3. 「インスタンスの仕様」の「マルチ AZ 配置」を「はい」に変更します。
    image.png

  4. さらに下にスクロールして「次へ」をクリックします。
    image.png

  5. 変更内容を確認し、変更スケジュールは「すぐに適用」を選択し「DB インスタンスの変更」をクリックします。
    image.png

  6. データベース一覧に戻るので、変更した DB インスタンスの DB 識別子をクリックします。
    image.png

  7. 「情報」が「変更中」となっている場合はもう少し待ちましょう。
    image.png

  8. 「情報」が「利用可能」となったら変更完了です。
    image.png

EC2 サーバーの追加

作成済みの EC2 の Web サーバーを複製して同じサーバーをもう 1 つ追加作成します。

  1. AWS マネジメントコンソールから EC2 サービスを選択します。「インスタンス」をクリックします。
    image.png

  2. EC2 のマシンイメージ (Amazon Machine Image : AMI) を作成していきます。Nextcloud の EC2 インスタンスを選択し、「アクション」－「イメージ」－「イメージの作成」の順にクリックします。
    image.png

  3. AMI イメージ名、イメージの説明を適当に設定して「イメージの作成」をクリックします。
    image.png

  4. マシンイメージの作成が開始されます。「保留中のイメージ xxxx の表示」のリンクをクリックします。
    image.png

  5. ステータスが「available」となっていたらマシンイメージの作成が完了しています。引き続きこのマシンイメージで EC2 インスタンスの複製を作成していきます。「起動」をクリックします。
    image.png

  6. ここ以降は、前回の EC2 インスタンスの作成と要領は同じです。ただし、サーバーが 2 つに増えるので、インスタンスタイプは前回作成のものより 1 ランク下げてみます (前回: t3.medium → 今回: t3.small)。インスタンスタイプを選択して「次のステップ: インスタンスの詳細の設定」をクリックします。
    image.png

  7. 「インスタンスの詳細の設定」では、「サブネット」を、前回作成した EC2 インスタンスとは異なるアベイラビリティゾーン (AZ) を選択します。これにより、AZ、すなわち AWS のデータセンター機能停止レベルの障害があってもサービス継続できるようにします。その他前回と同様に設定をして「次のステップ: ストレージの追加」をクリックします。
    image.png

  8. 「ストレージの追加」では特に変更はありません。そのまま「次のステップ: タグの追加」をクリックします。
    image.png

  9. 「タグの追加」では、前回同様に Name タグを追加します。前回の EC2 インスタンスと区別がつくように値を設定します。引き続き「次のステップ: セキュリティグループの設定」をクリックします。
    image.png

  10. 「セキュリティグループの設定」では、前回 EC2 インスタンスを作成した際に設定したセキュリティグループを選択し、「確認と作成」をクリックします。
    image.png

  11. これまで設定した内容を確認し、「起動」をクリックします。
    image.png

  12. SSH で使用するキーペアは、前回 EC2 インスタンスを作成したサイト同じものを選択しておくと後で管理しやすいと思います。キーペアの選択をして「インスタンスの作成」をクリックします。
    image.png

  13. EC2 インスタンスの作成が開始されます。「i-xxxx」のリンクをクリックします。
    image.png

  14. 「インスタンスの状態」が「running」、「ステータスチェック」が「2/2 のチェックに合格しました」となったら作成完了です。「search : i-xxxx」の右にある「×」をクリックします。
    image.png

  15. 引き続き、一時停止している EC2 インスタンスを起動しますが、起動前にインスタンスタイプを今回作成したものにそろえておきます。「アクション」－「インスタンスの設定」－「インスタンスタイプの変更」の順にクリックします。
    image.png

  16. インスタンスタイプを選択して「適用」をクリックします。
    image.png

  17. 設定変更したインスタンスを起動します。「アクション」－「インスタンスの状態」－「開始」の順にクリックします。
    image.png

  18. 「開始する」をクリックして起動を開始します。
    image.png

ロードバランサーの追加

引き続き今回のメイン、ロードバランサーの設定です。

  1. AWS マネジメントコンソールから EC2 サービスを選択します。左ペインをスクロールして「ロードバランサー」をクリックします。
    image.png

  2. 「ロードバランサーの作成」をクリックします。
    image.png

  3. 「Application Load Balancer」の「作成」をクリックします。
    image.png

  4. 以下のとおりロードバランサーの設定をしていきます。すべて設定したら「次の手順: セキュリティ設定の構成」をクリックします。

    項目 内容
    名前 ロードバランサーの名前
    スキーム インターネット向け
    ロードバランサーのプロトコル HTTPS (セキュア HTTP)
    VPC Nextcloud を構築している VPC を選択
    アベイラビリティゾーン 選択できる全てのアベイラビリティゾーンにチェックし、サブネットは、インターネット外部と通信できるサブネット(パブリックサブネット)を選択
    タグ "Name"キーとしてロードバランサーの識別名を設定

    image.png

  5. 「セキュリティ設定の構成」ではすべてデフォルトで OK です。ロードバランサーに設定する TLS/SSL 証明書は、ACM が発行する証明書を利用します。「次の手順: セキュリティグループの設定」をクリックします。
    image.png

  6. 「セキュリティグループの設定」では「新しいセキュリティグループを作成する」を選択します。その他はデフォルトで OK です。「次の手順: ルーティングの設定」をクリックします。
    image.png

  7. 「ルーティングの設定」は「ターゲットグループ」の「名前」にターゲットグループの名称を設定します。その他はデフォルトで OK です。「次の手順: ターゲットの登録」をクリックします。
    image.png

  8. 「ターゲットの登録」では、ALB でロードバランシングする EC2 インスタンスを登録します。画面下のインスタンス一覧から先に準備した Nextcloud の EC2 インスタンス 2 つをチェックし「登録済みに追加」をクリックします。そうすると「登録済みターゲット」にこれらのインスタンスが追加されます。追加したら「次の手順: 確認」をクリックします。
    image.png

  9. これまで設定した内容を確認して「作成」をクリックします。
    image.png

  10. ロードバランサーの作成が開始されます。「閉じる」をクリックします。
    image.png

  11. 状態が「provisioning」となっていたらロードバランサーを作成中です。しばらくお待ちください。
    image.png

  12. 状態が「active」となったら設定完了です。Nextcloud のドメイン (FQDN) はこのロードバランサーのサービスの DNS 名で解決するようになるので、DNS 名を記録しておきます。
    image.png

TLS/SSL 証明書の作成

ALB に設定する TLS/SSL 証明書を作成します。今回作成する証明書はAWS 自社認証局による「ドメイン認証 (DV)」のタイプとなります (これまで Web サーバーで設定していた Let's Encrypt の証明書も「ドメイン認証 (DV)」タイプです)。

「組織認証 (OV)」や「拡張認証(より厳格な組織認証) (EV)」の証明書は、別途取得したうえでインポートする必要があります。

  1. AWS マネジメントコンソールから Certificate Manager サービスを選択します。「証明書のリクエスト」をクリックします。
    image.png

  2. 「証明書のリクエスト」をクリックします。
    image.png

  3. 「ドメイン名」には Nextcloud を動かすサーバーの FQDN を設定して「次へ」をクリックします。
    image.png

  4. 「検証方法の選択」では「 DNS の検証」を選択して「次へ」をクリックします。
    image.png

  5. 作成する証明書にタグを付与します。 "Name" タグで名称を追加するなど行い、「確認」をクリックします。
    image.png

  6. 設定内容を確認して「確定とリクエスト」をクリックします。
    image.png

  7. 作成が開始されますが、証明書を作成するにあたって検証が必要です。対象ドメインの左にある三角マークをクリックすると、検証に必要となる DNS に追加登録する CNAME の情報が表示されます。以下の情報を DNS サーバー (もしくは Route 53 )に登録します。終わったら「続行」をクリックします。

    名前 タイプ 値
    【Nextcloud を動かすサーバーの FQDN名】 CNAME 作成した ALB の DNS 名
    (検証に必要な CNAME の名前) CNAME (検証に必要な CNAME の値)

    image.png
    以下は Route 53 での登録例です。
    image.png

  8. 対象ドメインの状況が「発行済み」となったら検証を含めて作成完了となります。これを先に作成した ALB に適用します。
    image.png

ALB に TLS/SSL 証明書を適用

  1. AWS マネジメントコンソールから EC2 サービスを選択します。左ペインをスクロールして「ロードバランサー」をクリックします。作成したロードバランサーを選択し、「リスナー」タブをクリック、「証明書の表示/編集」をクリックします
    image.png

  2. 「証明書」の右にある丸囲いの「＋」をクリック、 ACM で作成した証明書をチェックして「追加」ボタンをクリックします。
    image.png

  3. 「証明書は正常に追加されました」と表示されたら適用完了です。
    image.png

動作確認①

ここでいったん動作確認します。 "https://【Nextcloud を動かすサーバーの FQDN名】/" で Nextcloud にアクセス、ログイン/ログアウト、ファイルのアップロード/ダウンロードを試して問題ないことを確認します。

HTTP → HTTPS リダイレクト設定

前回までの環境では、 Nginx の設定で HTTP → HTTPS のリダイレクト設定が入っておりましたが、今回 Nginx では HTTP アクセスのみの設定となったため、ロードバランサーにて HTTP → HTTPS のリダイレクト設定を行う必要があります。
# Nginx 側で設定するやり方もありますがこちらのほうが簡単で分かりやすいです。

  1. AWS マネジメントコンソールから EC2 サービスを選択します。左ペインをスクロールして「ロードバランサー」をクリックします。作成したロードバランサーを選択し、「リスナー」タブをクリック、「リスナーの追加」をクリックします
    image.png

  2. 「プロトコル:ポート」はデフォルトで「HTTP : 80」が設定されます。「アクションの追加」－「リダイレクト先」の順にクリックします。
    image.png

  3. リダイレクト先として「HTTPS : 443」を設定します。あとはデフォルトで OK です。設定できたら「保存」をクリックします。
    image.png

  4. 「ポート 80 でリスナーが正常に作成されました」が表示されたのを確認して左上の「 < 」をクリックします。
    image.png

  5. 追加された「HTTP : 80」のリスナーに警告マークがつくのでクリックしてみます。
    image.png

  6. ロードバランサーに設定されているセキュリティグループで HTTP : 80 ポートの通信が許可されていないとのメッセージが表示されるのでこれを追加していきます。橙色で表示されているセキュリティグループ名のリンクをクリックします。
    image.png

  7. 「インバウンド」タブをクリックし「編集」をクリックします。
    image.png

  8. 「ルールの追加」をクリックし、タイプ「HTTP」のルールを追加して「保存」をクリックします。
    image.png

  9. HTTP のルールが追加されたことを確認します。
    image.png

動作確認②

HTTP → HTTPS リダイレクトが正しく動作するかを確認します。 "http://【Nextcloud を動かすサーバーの FQDN名】/" でアクセスすると "https://【Nextcloud を動かすサーバーの FQDN名】/" にリダイレクトされることを確認します。

動作確認③

EC2 インスタンスが 1 つダウンしても引き続きサービスが継続されることを確認してみます。

  1. EC2 サービスでインスタンスの一覧を表示します。今回は "Nextcloud-test-01" の EC2 インスタンスを停止してみます。「アクション」－「インスタンスの状態」－「停止」の順にクリックします。
    image.png

  2. 「停止する」をクリックします。
    image.png

  3. シャットダウン処理中です。処理が完了したら左ペインを下にスクロールして「ターゲットグループ」をクリックします。
    image.png

  4. ALB 作成の際に設定したターゲットグループを選択し、「ターゲット」タブをクリックします。 停止した "Nextcloud-test-01" サーバーが停止していることが表示されています。
    image.png

  5. この状態でサーバーは 1 基で運用されています。 Nextcloud にアクセスし、問題なく利用できることを確認します。

  6. 停止した EC2 インスタンスを再度起動します。 EC2 サービスでインスタンスの一覧を表示し、「アクション」－「インスタンスの状態」－「開始」の順にクリックします。
    image.png

  7. 「開始する」をクリックします。
    image.png

  8. EC2 起動処理中です。起動したら左ペインの「ターゲットグループ」をクリックします。
    image.png

  9. 起動した EC2 インスタンスが ALB のヘルスチェックに合格していることが確認できます。
    image.png

Cron の復活

  1. Nextcloud の EC2 仮想サーバーのうちの 1 つに SSH 接続します。

  2. Nextcloud の cron を復活します。

    sudo mv /etc/cron.d/.nextcloud-cron-php /etc/cron.d/nextcloud-cron-php

★両方のサーバーの Cron を復活させると、Cron が二重起動してしまいますので、片方のみ復活させてください

お疲れさまでした！　これですべての設定が完了です。

あとがき

ELB サービスについては、今回は利用しなかった Classic Load Balancer (CLB) を軽くお試し程度で 1 度構築したことある程度、ACM は CloudFront を利用したサービスで数度設定したことある程度で、今回のようにしっかりしたシステムで設定するのは初体験、うまく設定できるか不安でしたが、Nginx の設定変更以外はあまり迷わずに設定から動作まで実現することができました。
この状態で、前回よりもはるかに可用性の高い構成となっております。

現在の状態では Web サーバーを複数に分散したため、サーバーのログがそれぞれに分散してしまい、運用していくにはとても管理しづらい状況となっております。次回はこれらを集約し管理しやすくする設定を行ったりしていきます。

# 画面キャプチャでの説明は流れが把握しやすい反面、記事書くのは結構大変・・・AWS CLI とか CloudFormation のほうが楽かも。

7
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
3