AWS麻雀のCDP:Job Observerパターン

JAWS-DAYS 2015 AWS麻雀体験企画
– AWS麻雀のCDP役を理解する –

5.Job Observerパターンを実践・理解する

AWS麻雀CDP役(1〜4ECU+7ECU+1〜SQS{中扱い})
01

今回のJob Observerパターンは、SQSのキュー(処理待ちリクエストなど、一時的な保管データ)と、CloudWatchというリソース情報管理する機能を利用します。
SQS内の処理待ちリクエストが一定量を超えてないかCloudWatchで監視し、超えた時点でAuto Scaling機能で、EC2のインスタンス(サーバ)を追加起動します。
これにより、バッチ処理(Webと違い、計算などの処理を黙々と行うこと)を行うサーバを自動で増減し効率良く処理する事ができます。

例えば、バックグラウンドで実施している動画のサムネイル画像作成処理などで、サムネイル作成指示用SQSのキューが増分した場合、自動で処理サーバを増やす事で一定の処理パフォーマンスを保つができるようになります。

今回はとりあえずt2.microEC2インスタンス(サーバ)と、AMI(サーバイメージ)を作成して、SQS内のキューをコンソールより追加して試してみます。
SQSのキューが5個を超えた時点でサーバの負荷大になると想定し、新しいインスタンス(サーバ)が追加されるよう設定し、処理が実施されるか試したいと思います。

参考情報は以下です。

Amazon SQS との組み合わせで素早く Auto Scaling
http://aws.typepad.com/aws_japan/2015/01/auto-scaling-with-sqs.html

“SQS”と”CloudWatch”と”Auto Scaling”(スズキさん)
http://blog.suz-lab.com/2011/06/sqscloudwatchauto-scaling.html

Amazon SQSとCloudWatchによる高速AutoScaling(横田あかりさん)
http://dev.classmethod.jp/cloud/amazon-sqs-cloudwatch-rapid-autoscaling/

Amazon SQS のディメンションおよびメトリックス
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/DeveloperGuide/sqs-metricscollected.html
先ずは好きなインスタンスで、サーバを立ち上げます。
今回は、Amazon Linux AMI 2015.03 (HVM) t2.micro を利用します。

余談ですが、今回から管理コンソールが日本語化表示です!
00

 

1.EC2のイメージ作成

今回は、バッチジョブと呼ばれる裏方作業のサーバをEC2で起動します。
但し、実際のバッチジョブのアプリ実装は大変ですので、あくまでサーバの起動までを試します。

管理コンソールでEC2の画面を表示します。
00A

インスタンスの作成を行います。
02

Amazon Linux AMI を選択します。
03

t2.micro を選択します。(試して課金はさけたいところ、くれぐれもお間違いなく!)
04

作成 します。
05

既存のキーペアーを選択するか、新しく指定して インスタンスを作成します。
06

以上で、新しいインスタンスが作成。
07

作成したインスタンスのイメージ(AMI)を作成します。
これはSQSの処理待ちキューが増えた場合に、サーバ(インスタンス)を増やす場合の元イメージになります。
本来はシステムを構築したインスタンスのイメージを使います。
が、今回は動きを確認するだけで、Amazon Linux AMI をそのまま使います。
08

インスタンス行の上で 右クリックで、イメージ、イメージの作成 を選択します。
09

イメージ名、説明を適当に設定し イメージの作成をします。
10

 

イメージ(AMI)が完成します。
11

作成したイメージ(AMI)を確認します。
12

 

2.SQSの設定

今回はSQSの処理待ちキューの数が一定量を超える事で、バッチ処理サーバを増やす想定です。
このSQSは、バッチ処理サーバとは別に、業務サーバや、Webサーバなどよりバックグラウンドで行う処理の指示と関連する情報を保管します。
バッチ処理サーバは、このSQSに蓄積されたキューの処理指示に従い、裏方処理を実施します。
SQSは複数のバッチ処理サーバからのアクセスを考慮した処理も実装可能です。

処理待ちを管理するのSQSのキューを作成します。
00B

 

新しいキューの作成 を行います。
13

キュー名、キューの設定 を行います。可視性、メッセージの消滅は短めに設定しました。
キューの作成 をします。
14

キューが出来上がりました。
キューの試験用データは他の設定完了後に行います。
15

 

3.AutoScallingの設定

SQSのキューが閾値を超えた際にバッチ処理サーバを増やします。
これはコンソールのEC2内にある、AutoScalling という機能を利用します。
AutoScalling は今回の例の他に、AWSのロードバランサーと組み合わせて、自動スケールアウト・無停止Webサーバの設定などによく用いられます。

Auto Scalling グループの作成 を行います。
16

起動設定の作成 を行います。
17

マイAMI を選択します。
18

先に作ったイメージ(AMI)を選択します。
19

t2.micro を選択します。(試して課金はさけたいところ、くれぐれもお間違いなく!)
次の手順 に進みます。
20

起動設定を作成します。
名前 を設定し、確認画面にスキップ します。
21

起動設定の作成 を行います。
22

先のEC2のインスタンス作成と同じ設定にします。
23

グループ名 の設定、サブネット を選択します。
次の手順 に進みます。
24

スケーリング範囲を 1 および 2 に設定します。
本来範囲は処理量に応じて設定しますが、今回は試験なので1台の増分で止めます。
名称 、アクションを設定します。
アクションは、今回は試験なので1インスタンス(サーバ)づつ追加にしています。
確認 します。
25

AutoScalling グループの作成 を行います。
26

作成されました。
27

以下のように表示されます。
28

 

4.CloudWatchの設定

CloudWatchはAWSの各サービスの状況を監視し、アラームによる通知・処理などを行います。
その他のサービスと連携し、今回のようなSQSのキュー数の閾値によるインスタンス(サーバ)起動なども行えます。

SQSのキュー数を監視するためのCloudWatchのアラームを作成します。
00C

アラームの作成 を行います。
29

SQSメトリックス を選択します。
30

ApproximateNumberOfMessagesVisible をチェックし、次へ 進みます。
ApproximateNumberOfMessagesVisible はSQS内の有効なキューの数です。
31

名前、説明 を設定します。
ApproximateNumberOfMessagesVisible の値が5以上でアクションを実施するよう設定します。
通知 アクションを削除し、Auto Scalling アクション を追加します。
32


追加した アクション に、アラーム 警告 を選択します。
グループ他には、先に設定した Auto Scalling の設定を選択し、アラームの作成 を行います。

33

作成されたばかりの状態です。
34
以上で設定は終わりです。

 

5.試験の実施

設定が完了しましたが、SQSにキューを登録しない限りインスタンス(サーバ)の数はそのままです。
SQSにデータを5件登録、そして削除した場合のインスタンス(サーバ)の数を確認してみます。

EC2のインスタンスの画面で、稼働しているのは先に作成したインスタンス(サーバ)1個のみです。
40

SQSの画面でキューのメッセージを追加(メッセージの送信)します。
41

5件ほど適当なメッセージを入れて、メッセージの送信 します。
42

43

メッセージの表示 で確認します。
44

メッセージのポーリングを開始します。
45

キュー内に5件のメッセージがあります。
46

CloudWatchの画面で、早速 アラーム が発生しています!
47

最初EC2のインスタンス(サーバ)画面に戻って、起動数が変わらず、、、。
先の赤書きの部分を間違えて設定して、、、最大数を2に変更しました。
48

EC2の画面で、もう1つ同じイメージ(AMI)のインスタンス(サーバ)が起動し始めました。
49

ステータスチェックも合格し、無事起動です!
50

では、意地悪くインスタンス(サーバ)のトラブルを想定し、起動したインスタンス(サーバ)を削除してみます。
51

52

terminatedとは削除された状態で、削除されています!
53

少し待つと、再度アラームの処理で、新しいインスタンス(サーバ)が起動を始めます!
54

これは サーバ管理者の眠れない夜! 撲滅に効果大ですね!(^^)v

では、SQSのキュー内のメッセージを削除してみます。
55

56

SQSキュー内のメッセージが4個になりました。
57

SQSのアラートが消えて正常になっています!
58

EC2のインスタンス(サーバ)が自動で削除(terminated)されています!
59

今回のCDPパターンは地味ですが、この機能は
・ソフト会社で基幹系システムのSI屋さん
・Webサービスでバックグランド処理をかかえるIT屋さん
などには必須の機能ですね!

このブロッグでは触りの部分のみ紹介しましたが、もっと突き詰めて設定すると素晴らしいパフォーマンスの停止しないシステムを構築可能でしょう!!

JAWS-DAYS 2015 AWS麻雀体験企画 に戻る

広告

About Yukihito Kataoka
@ykataoka

現在コメントは受け付けていません。

%d人のブロガーが「いいね」をつけました。