「Nextcloud 環境の構築を通じて AWS での環境構築を体験する」 の第 7 回 兼 最終回となります。
これまでの記事は下記からどうぞ。
- 【第 1 回】EC2 と RDS を利用した Nextcloud 環境の構築
- 【第 2 回】ElastiCache サービスの導入
- 【第 3 回】EFS ファイルサーバーへの移行
- 【第 4 回】ALB を利用したサーバー負荷分散、可用性向上に向けた取り組み
- 【第 5 回】分散した EC2 インスタンスのログの集約
- 【第 6 回】Cron の外部実行とメール送信の追加
はじめに
前回記事 までで、可用性も考慮した Nextcloud の構成がひととおり完了しました。
最終回は、 AutoScaling を追加して、何らかのトラブルで EC2 が死んだりアクセスできなくなっても勝手に新たな EC2 が起動されるようにします。AutoScaling っていかにもクラウドっぽいサービスで私が好きなサービスの一つです。
今回構築する Nextcloud on AWS 環境
次のような構成となります。基本的な構成は前回から変わりません。 EC2 の起動を AutoScaling で制御していきます。
今回追加で利用する AWS サービス
サービス名 | 役割 |
---|---|
AutoScaling | EC2 の稼働台数維持や、必要に応じて EC2 の自動スケールアウト/スケールインを行うことができるサービス。サービス自体は無料。今回は、稼働台数維持を目的として利用します。 |
設定手順
Nextcloud サーバーのマシンイメージ取得
Nextcloud サーバーの EC2 を停止し、現時点でののマシンイメージを取得します。
-
Nextcloud サーバーの EC2 インスタンスを選択し、「アクション」-「インスタンスの状態」-「停止」の順にクリックします。
※起動している Nextcloud サーバーの EC2 インスタンスすべてに対して同じように実施します。
-
Nextcloud サーバーの EC2 インスタンスを 1 つ選択し、「アクション」-「イメージ」-「イメージの作成」の順にクリックします。
-
「イメージ名」に適当なマシンイメージの名前を入力し、「イメージの作成」をクリックします。
# どうでもいいところですが、画面イメージでは "Snapshot-・・・" としていますが、スナップショットとはちょっと違いますね・・・
-
「ステータス」が「available」になったら作成完了です。引き続き、「AUTO SCALING」の「起動設定」をクリックします。
AutoScaling の起動設定
まず AutoScaling でどのような EC2 インスタンスを作成するのかを定義していきます。EC2 インスタンスの作成イメージによく似てるのでわかりやすいと思います。
-
AutoScaling で起動する際のインスタンスタイプを選択します。これまでは "t3.small" を利用していましたが、ここでは "t3.small" よりも時間単価が安い "t3a.small" を選択し、「次の手順: 詳細設定」をクリックします。
※ "t3.small" と "t3a.small" の違いは、CPU の種別となります。
-
セキュリティグループの設定です。「既存のセキュリティグループを選択する」をクリックし、これまで EC2 インスタンスに設定していたセキュリティグループを選択して、「確認」をクリックします。
-
AutoScaling の起動設定の作成が完了しました。引き続き「この起動設定を使用して Auto Scaling グループを作成する」をクリックします。
AutoScaling グループの作成
AutoScaling グループは、自動的にスケーリングしたり管理の目的で論理グループとして扱われる EC2 インスタンスの集合です。先ほど作成した起動設定の EC2 のインスタンスを「どこに」「いくつ」作成するかなどを定義します。
-
まずは下記のように設定します。
項目 設定内容 グループ名 AutoScaling グループ名を適当に入力。 グループサイズ 開始時にいくつの EC2 インスタンスを起動するか。ここでは 2 を入力。 ネットワーク これまで構築を行っている VPC を選択。 サブネット 選択した VPC のパブリックサブネットをすべて選択。 さらに「高度な詳細」をクリックすると追加の設定メニューが表示されますので、以下のとおり設定します。 項目 設定内容 ロードバランシング 「ひとつまたは複数のロードバランサーからトラフィックを受信する」をチェック。 ターゲットグループ ロードバランサ (ALB) 設定時に定義したターゲットグループを選択。 ヘルスチェックのタイプ 「 ELB 」を選択。 サブネット 選択した VPC のパブリックサブネットをすべて選択。 設定したら「次の手順: スケーリングポリシーの設定」をクリックします。 -
今回は、当初起動した EC2 の起動数をそのまま維持する形とするので「このグループを初期のサイズに維持する」を選択し、「次の手順: 通知の設定」をクリックします。
-
AutoScaling でインスタンスが起動した等のイベントが発生した場合の通知設定です。ここでは特に何も設定しないので「次の手順: タグの設定」をクリックします。
-
AutoScaling グループの作成が完了しました。引き続きこの設定に基づいて EC2 インスタンスが起動してきます。
7. しばらくして EC2 インスタンスの一覧画面を確認すると下の画面のように EC2 インスタンスが 2 つ起動されることが確認できます。
これまでの EC2 インスタンスをロードバランサから外す
-
先ほど選択したターゲットグループを選択し「ターゲット」タブをクリックすると「登録済みターゲット」にこれまで作成していた EC2 インスタンスと、AutoScaling で新たに作成された EC2 インスタンスの計 4 インスタンスが登録されています。これまで作成していた EC2 インスタンスは不要となりますのでこの登録を解除します。「編集」をクリックします。
-
削除対象とした EC2 インスタンスのステータスが「 draining 」となり登録解除処理が開始されます。しばらくするとこれらは登録済みターゲットからなくなります。
-
登録解除した EC2 インスタンスは不要となります。忘れずにインスタンスの「終了」をしておきましょう。
お疲れさまでした! これで完了です。
あとがき
今回の設定作業により、 万が一 EC2 インスタンスが障害などで終了しても自動的に新たな EC2 インスタンスが起動してくるようになります。またロードバランサののヘルスチェックと連動させておりますので、例えば、どちらかの EC2 インスタンスの Web サーバにアクセスできない状態 (=Nginx を停止するなど) となると、新たな EC2 インスタンスが起動し、アクセスできない EC2 インスタンスは自動的に終了します。また起動数も設定変更で簡単に制御できますのでいろいろ試してみてください。
7 回にわたって連載形式で様々な AWS サービスを試してきました。私自身、ほとんど触ってこなかったサービスをこの連載を通じて学ぶことができ、とても大きな収穫でした。
最後までお付き合いいただき、ありがとうございました!