技術ブログ
技術ブログ
2018年05月24日
このエントリーをはてなブックマークに追加

アプリケーションのレスポンス低下をトリガにしたアプリケーションサーバのスケールアウト

今回は、New Rlicを使用した自動化の例をご紹介したいと思います。

皆様ご存知のようにNew Relic のAPMはアプリケーションのパフォーマンスを監視する事ができ、パフォーマンスの低下時に様々なチャネルを通して通知をすることが可能です。
(New Relicは通知チャネルとして、Campfire, Email, HipChat, OpsGenie, PagerDuty, Slack, VictorOps, Webhook, xMattersなど選択できます。)

今回はチャネルとしてWebhookを使用し、StackStorm(以下、ST2)と連携をさせてみたいと思います。大まかなシナリオは以下の内容となります。(Auto ScalingグループのスケーリングポリシだとCPU使用率やネットワークトラフィック、ALBリクエスト数などをトリガにすると思いますが、New Relicでアプリケーションのパフォーマンスが監視できますので、レスポンスの低下をトリガにサーバの自動追加をしてみたいと思います)

大まかな処理のフロー

  1. New Relic APMでアプリケーションサーバ(AWS上で動作)のパフォーマンスを監視。
  2. アプリケーションのレスポンスが悪化(Apdex scoreが閾値を下回る)。
  3. New Relic Alertsの機能でレスポンスが低下したことをST2にWebhookで通知。
  4. ST2はNew Relicからの通知を受け、通知の内容に基づいたActionを実行。
  5. ST2はAuto ScalingグループのDesired Capacityの数を増やすActionを実行。
  6. サーバが追加されNew Relic APM上で表示される。

上手くいけばアプリケーションのパフォーマンスが低下した際に、サーバを自動で追加するといったことが出来るはずです。それでは次に設定をしていきたいと思います。

1.New Relic APMのインストール
 まずは、New RelicのAgentをアプリケーションサーバにインストールします。インストール方法は以前同じチームのKUROPONさんが書いたブログがあるのでそちらを参考にしてみてください。評価版New Relicの入手先情報もこちらののブログに記載されています。

2.ST2のインストール
 次に、ST2をインストールします。インストール方法は少し前に同じチームのSomeyaMasahiroさんが書いたブログがありますので、そちらを参考にしてみてください。注意点としては、今回AWS packを使用する野ですがシステム要件のミニマム構成だと AWS Packのインストールでメモリが足りずにFailしてしまいます。その為、メモリは4GB以上のサーバリソースを準備して頂いた方が良いです。私は、最初にt2.smallで確認したのですがNGでした。。。今回私が使用したインスタンスは下記の通りです。
  ・AMI:Ubuntu Server 16.04 LTS (HVM), SSD Volume Type  インスタンスタイプ:t2.medium

3.packファイルのインストール
 ・AWS packのインストール
  ST2のインストール後にAWS packをインストールし、コンフィグファイルを編集します。インストール及びコンフィグファイルの編集手順はこちらのサイトを参考にしてみてください。

 ・New Relic packのインストール
  New Relic packのインストール方法に関しては、以前同じチームのKUROPONさんが書いたブログがあるので下記のサイトを参考にしてください。

4.Alertの設定
 3までの内容で必要機器の準備ができたと思いますので、次に機器連携の設定をします。まずはアプリケーションのレスポンスが悪くなった時にST2にWebhookで通知をする設定になります。
 ・Notification channelsの作成
  New RelicのWeb GUIより
  I. Alert⇒Notification channels⇒+New notification channelを選択
  II. Select a channel typeでWebhookを選択。
  III. Channel nameは任意の名前
  IV. Base Urlはhttp://<ST2のIP>:10001/st2/nrhook/
  V. Custom HeadersはContent-Type:application/jsonを追加
  VI. Use Custom Payload は下記の内容を追加   

図:New Relic 設定イメージ1

 ・Alert policiesの作成
  New RelicのWeb GUIより
  I. Alert⇒Alert oplicies⇒+New alert policyを選択
  II. ALERT POLICY NAMEは任意の名前を設定しCreate alert policyボタンを押す。
  III. Notification channelタブでAdd notification channelsボタンを押し、Webhook⇒先ほど作成したchannelを選択。
  IV. Alert conditionsタブからCreate a conditionボタンを押し、Next select entitiesボタンを押す。(Select a product:APM、Select a type of condition:Application metric、Select the condition scope:Scope to the applicationが選択されていると思います。)
  V. Select entitiesより監視するApplicationを選択しNext, define thresholdsボタンを押す。
  VI. Define thresholdsで閾値の設定を行う。今回はApdexを選択しCreate conditionボタンを押す。

 

図:New Relic 設定イメージ2

図:ST2設定イメージ

5.ST2の設定
  ST2でNew RelicからのWebhook通知を受信した時にAWS上でインスタンスを起動する設定をします。
  ST2のWeb GUIより
  I. RULESを選択した後+ボタンを押す。以下の項目を入力(今回は簡単な動作確認の為、必須項目のみの記載としています)しCREATEボタンを押す。
   Create rule
    name:任意の名前を入力
    pack:newrelic
   TRIGGER
    name:newrelic.ServerAlertTrigger
   ACTION
    name:aws.autoscaling_update_auto_scaling_group
    AutoScalingGroupName:AutoScaling対象とするグループ名を記載
    DesiredCapacity:起動希望サーバインスタンス数

これで一通りの設定は終了になりますので、早速アプリケーションのパフォーマンス低下をトリガにオートスケールするかどうか確認してみましょう。まずは、New RelicのWeb GUIよりスケール前のアプリケーションサーバのステータスを確認してみたいと思います。

図:アプリケーションサーバステータス(スケール前)

オートスケーリングループは下記のような状態です。最小台数:1、最大台数:4台、希望台数:1台となっています。

図:AutoScalingグループの設定1

ST2の状態は下記の様になっています。

図:ST2の履歴1

それでは負荷をかけて動作を確認します。今回の環境ではApdexをシビアにしてすぐアラートが出るようにしています。アラートが出ると下記の様にST2でActionが自動的に実行されます。

ST2の履歴2

AWSコンソールからもステータスを確認してみたいと思います。インスタンスの希望台数が2に変更され、インスタンスの数が2台になっていることが確認できました。

図:AutoScalingグループの設定2

New RelicのWeb GUIからもステータスを確認したいと思います。

図:アプリケーションサーバステータス(スケール後)

ちゃんとサーバの台数が2台になっているのが確認できました。New RelicとST2を連携させることでアプリケーションのパフォーマンス低下をトリガにサーバをAuto Scalingさせる事が可能である事が確認できました。
実環境で使用する場合にはもう少し工夫する必要がありますが、色々と組み合わせて自動化できることが分かりました。また機会があればその辺りもブログに書ければと思います。

それではまた。

New Relicの無料トライアルはこちらから

このエントリーをはてなブックマークに追加

PROプランのすべての機能を
14日間無料でお試し

新規無料登録いただくとPROプランのすべての機能を
14日間無料でお試しいただけます。
クレジットカードなど決済情報の登録は不要です。

各プランの詳細はこちらからご確認ください。