【Laravel & AWS】JavaScriptの自動ビルドとアプリケーションサーバのオートスケールを設定する【4日目】

AWSのサービス縛りでコスト最適で弾力性のあるLaravelアプリケーションのインフラを作ろうという企画の4日目です。
前回はstorageフォルダ周りの調整とHTTPSに対応しました。
今回はフロントのリソース(node, npm)の自動ビルドに対応して、アプリケーションサーバがオートスケールする様にします。
ちなみにやりたい事の一覧は以下の通り(破線は完了した物)

  • アプリケーションサーバの構築 (1日目)
  • ビルド・デプロイの自動化 (1日目)
  • RDBに接続できる (2日目)
  • cronを使える様にする(Laravelのタスクスケジュールのトリガー) (2日目)
  • HTTPS対応 (3日目)
  • storageフォルダにシンボリックリンクを作成する (3日目)
  • storageをEFSに置き換える (3日目)
  • フロントのリソースの自動ビルド(node, npm)に対応
  • アプリケーションサーバのオートスケール
  • テストの自動化
  • Redisに接続できる
  • リソースをCDNから配信する
  • RDSのバックアップ/リストア
  • RDSの容量のオートスケール
  • ビルド完了時のslack通知

環境を作り直すとドメインの名前解決ができなくなる問題

今日も作業しようと思って、環境を立ち上げたらアプリケーションに接続できなくなってました
どうやらロードバランサーが作り直されて名前が変わってAレコードのALIASが解決できなくなった模様。
Route53のAレコードを再設定した。
しかし、それでも接続できない。
ローカルのキャッシュが邪魔してるっぽいので以下のコマンドで削除する。
無事、接続できた。

sudo systemd-resolve --flush-caches

CodeBuildでフロントのリソースを自動ビルド(node, npm)できる様にする。

まずはローカルでscssを追加した。
確認するとこんな感じ。
文字が赤色になっていればscssがビルドできて、ちゃんと読み込めている事の証明になる。

トップページの表示を確認している図

とりあえずBeanstalk環境にデプロイする
まだscssのビルドの設定をしていないので、cssが存在せず、黒字のまま。

Beanstalkでトップページを表示している図。scssがビルドされていないので黒字のまま。

CodeBuildでフロントのリソースのビルドを行うために、buildspec.ymlnodeのランタイムとnpm関連のコマンドを追加する。
ランタイムを複数扱えるらしく、数行足すだけで出来ちまうんだ😎

phases:
  install:
    runtime-versions:
      php: 7.3
      nodejs: 12
  build:
    commands:
      - composer install
      - npm install
      - npm run prod
      - rm -rf node_modules
artifacts:
  files:
    - '**/*'

改めてBeanstalk環境で確認する。
無事、赤文字が表示された!(フロントのビルドが出来ている)

Beanstalkでトップページを表示している図。scssがビルドされたため赤文字になっている。

アプリケーションサーバをオートスケールさせる

Beanstalkの環境を負荷状況に応じて自動でスケールアウト(水平スケール)させたい
公式ドキュメントを参考に設定していく。
Beanstalkの環境の「設定」→「容量」からインスタンスの最大数を2に変更する。

Beanstalkの「容量」設定画面

トリガーを設定する

オートスケールがトリガーされる条件を設定する

  • 期間
    • メトリクスの計測頻度
  • 超過時間
    • メトリクスがこの時間以上、上限または下限を超えているとトリガーされる

試しに大量にリクエストされるとスケールアップする様にしてみる。

Beanstalkの「容量」設定画面のトリガーを設定している図

クールダウンって何?

クールダウンは、オートスケールが立て続けにトリガーされるのを防ぐための仕組みとの事。
オートスケールがトリガーされた後、この秒数の間は、次のオートスケールがトリガーされないらしい。
公式ドキュメントはこちら

Beanstalkの「容量」設定画面のクールダウンを設定している図

オートスケールをトリガーしてみる。

EC2インスタンスの状態を確認しておく。
今は1台しか起動していない

EC2インスタンスの一覧画面

Apache JMeterリクエストを投げ続けてみる

Apache jMeter

Beanstalkのモニタリングでリクエスト回数をモニタリングしてみる
リクエスト回数がガンガン増えてる

Beanstalkのモニタリング画面

あらためて、EC2のインスタンスを確認すると、インスタンスが生えてた!🤞

EC2インスタンスの一覧画面。インスタンスが増えている。

ちなみに、現状のインスタンス数を確認するには、Beanstalkの環境画面の「ヘルス」から確認するのが良さそう。
EC2で確認するとたまたま落ちている場合や、これから起動しようとしている場合などに正確な台数が分からないため。

Beanstalkのヘルス確認画面

トリガーを設定するコツ

実はトリガーの設定で結構ハマりました。
トリガーとして監視するメトリクスはモニタリング画面で閲覧できるので、どのぐらいの値で推移しているのか確認した方が良いですね。
メトリクスと観測方法の組み合わせによっては2枚目の様に意味を成してない物もあるので。

Beanstalkのトリガー設定とモニタリング画面の対応を表す図
メトリクス「RequestCount」を「最大」で集計した図。常に1なので使い道がない?

SSHしたらどうなる?

複数のインスタンスが起動している時にSSHすると、どちらに接続されるんだろう?
eb sshしてみる。
選択肢が表示されて接続するインスタンスが選べるみたい。神か。

複数インスタンスが起動している状態でsshした図。選択肢が表示される親切設計。

今日はここまで。
他にも試したい事が浮かんできたので以下メモを残しておく。

  • System Managerで可視化してみたい
  • Inspectorで脆弱性チェックを受けてみたい

コメントする