Amazon SQS の初期設定パラメータメモ | iret.media好きなサービスは SQS ですけど、そんなに知りません、かっぱ（@inokara）です。 これ キューの Details に書かれている項目を日本語に訳してみた。 以下、オレオレ翻訳とググった。
朝の 3 分ハッキング（2） Supervisor で Amazon SQS のキューをポーリングするスクリプトをデーモン閣下してメッセージに応じて Apache を非同期で起動したり停止したりする… | iret.media
朝の 3 分ハッキング（2） Supervisor で Amazon SQS のキューをポーリングするスクリプトをデーモン閣下してメッセージに応じて Apache を非同期で起動したり停止したりする… 長いタイトルすいません。かっぱ（@inokara）です。 やること SQS をポーリングする Ruby スクリプト作ります Supervisor で上記のスクリプトをデーモン閣下します メッセージを適当に SQS に投げます Apache が起動するでしょう… SQS をポーリングする Ruby スクリプト 以下のような感じ。メッセージを JSON で投げると start / stop / status を実行出来るようにしてます。 #!/usr/bin/env ruby require 'aws-sdk' require 'json' AWS.config( :access_key_id
fluentd を Amazon SQS の Consumer として利用しつつ exec アウトプットプラグインと組み合わせて非同期に Apache を起動してみる | iret.media
fluentd を Amazon SQS の Consumer として利用しつつ exec アウトプットプラグインと組み合わせて非同期に Apache を起動してみる どうも、AWS で好きなサービスは SQS と言いたいけど、言える程に修行が足りてないかっぱ（@inokara）です。 はじめに fluentd にログを捌かせる仕事ではなく Amazon SQS の Consumer として利用してみたいと思います。そして、メッセージがキューインされたことをトリガーにしてインスタンス上の Apache を起動してみたいと思います。 やりたいこと Amazon SQS のキューにメッセージをキューイング（今回は Amazon SNS から通知） fluentd + fluent-plugin-sqs でキューをポーリング キューにメッセージがあったら out_exec で別のコマンドを実行（
AWS 白帯シリーズ(4) Hello SQS !!(3) | iret.media
cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 お詫び 以前にアップしていた記事を手違いにより削除してしまいましたので、改めてアップ致しました。 はじめに AWS 白帯シリーズ第四弾として前回、前々回に引き続き SQS を取り扱っていきたいと思います。 今回は AWS SDK for Ruby と AWS CLI から SNS から届いたメッセージを取り出してみたいと思います。 準備するもの AWS SDK for Ruby AWS CLI 白帯とは言え、上記のツールは道着のようなものですので道場に入る前に準備しておきましょう。 AWS SDK for Ruby Ruby が既にインストールされていてる環境にて以下を実行します。
AWS 白帯シリーズ(2) Hello SQS !!(2) | iret.media
cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 はじめに AWS 白帯シリーズ第二弾として前回に引き続き SQS を取り扱っていきたいと思います。 今回は AWS の他のシステム（SNS）との連携を試してみたいと思います。 他のシステム（SNS）との連携 AWS や他のクラウド環境において他のシステムとの連携がとても簡単に行えるというのはオンプレ環境では享受出来ないメリットだと考えています。もちろん、SQS も同様で AWS にて提供されているシステムと連携出来るようになっています。（オンプレ環境で同じようなことが出来ないわけではないと思いますが…） 今回はその中でも SNS との連携について試してみたいと思います。 SNS とは ソーシャルネットワークだと思った方は一旦、パソコンを閉じて顔を洗ってから戻って来て下さい。私も当初は AWS
AWS 白帯シリーズ(1) Hello SQS !! | iret.media
どうも、AWS 白帯の かっぱ（@inokara）です。黒帯目指して頑張ります。 はじめに とりあえず SQS を触ってみたメモです。数クリックで Hello World 的なことが出来るのは素晴らしいですね。 SQS とは 以下の資料は必読です。 [AWSマイスターシリーズ] Amazon SQS / SNS SQS とは以下のような特徴があります。 分散メッセージ・キューサービス アプリケーション間の非同期通信が可能にすることで疎結合な環境が構築出来てスケールアウトし易い AWS ならではの高い信頼性とスケーラブルな環境 ということで、スクリーンショット + 駆け足で SQS を使ってみたいと思います。 SQS の利用開始 キューの作成 Create New Queue をクリックする Queue Name を指定する キュー出来ました 簡単ですね。 メッセージをキューに送ってみる メ
SQSをIAMで制御してfogも使ってみる | iret.media
cloudpack の がみさんです。 こんばんは さてSQSの操作をIAMで制御してみました。 ドキュメントにSQSをIAMで制御するための説明が書かれています。 いつもありがとうIAM. Sendだけ許可するポリシーを作成してみました。 { "Version": "2012-10-17", "Statement": [ { "Action": [ "sqs:SendMessage" ], "Effect": "Allow", "Resource": "arn:aws:sqs:::" } ] } CLIでテスト CLIを使ってメッセージを送信してみます。 [default]がAWSリソースへFull Accessできるプロファイルで、 [profile sqs_user]は先ほど作成した特定のキューに送信だけ許可するプロファイルです。 CLIはprofileの切り替えが楽です。頼りすぎる
SQSのアクセス制限がうまくいかない | iret.media
cloudpack の がみさんです。 ※FAQにAWSアカウントはOKって書いてあった。 匿名の場合はIP見たりするってことのような感じがする。 http://aws.amazon.com/jp/sqs/faqs/ 前回作成したメッセージキューのアクセス制限をかけてみたいと思いました。 参考ドキュメント SQS Poh3cy { "Version": "2012-10-17", "Id": "cd3ad3d9-2776-4ef1-a904-4c229d1642ee", "Statement": [ { "Sid": "", "Effect": "Deny", "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:ap-northeast-1:075069182505:myque",
読まずに食べるSQSとDynamoDB 作成編 | iret.media
orenomac$ aws dynamodb create-table --table-name test --attribute-definitions AttributeName=DataA,AttributeType=S AttributeName=DataB,AttributeType=S --key-schema AttributeName=DataA,KeyType=HASH AttributeName=DataB,KeyType=RANGE --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "DataA", "AttributeType": "S" }, {
SQSってなんじゃ？（supervisordでSQS） | iret.media
memorycraftです。 いまさらですが、SQS＋supervisordです。 supervisorはプログラムの起動監視と、自動起動/復帰などを行ってくれるツールです。 これをつかってSQSの受信処理プログラムをワーカーとして管理してみます。 ■受信テスト用のスクリプトを作成 メッセージの受信は、一度に最大の10件まで、ポーリング20秒で受信したメッセージをログファイルに出力するようにします。 また、今回はログの出力タイミングがわかりやすいように、1回のポーリング後10秒間sleepしています。 $ vim /home/ec2-user/svsqs.rb #!/usr/local/bin/ruby require 'aws-sdk' require 'logger' access_key = 'XXXXXXXXXXXXXXXX' secret_key = 'YYYYYYYYYYYYY
cloudpackブログ - NagiosでSQSの(メッセージ数の)監視
SQSのメッセージ数の監視をNagiosで実施しています。 キュー内のメッセージ数(ApproximateNumberOfMessagesVisible)を監視するのですが、メッセージ数が閾値を 超えていなくても、処理数(NumberOfMessagesReceived )が、ある一定の期間0であった場合、 アプリケーションの方で障害があって処理できてないと見なし、アラート通知するようにしてみました。 実際のNagiosプラグインは下記となります。 # cat check_sqs #!/bin/sh . `dirname $0`/utils.sh set -e trap 'echo "UNKNOWN: $?"; exit $STATE_UNKNOWN' ERR WARN=0 CRIT=0 REVERSE=false while getopts c:w:q:p: OPTNAME; do ca
cloudpackブログ -SQSのロングポーリング機能を試してみた
先日、SQSに関して下記の機能がリリースしました。 Amazon SQSに新機能が追加! ロングポーリング、リクエストバッチ処理/クライアントサイドでのバッファリング ということで、さっそく、ロングポーリングに関して試してみました。 すでに、SQSに関しては、下記でいろいろと試しており、そこでのスクリプトをブラッシュアップしたもの実験しています。 PHPでSQS 実際の実験用スクリプト(キューからメッセージを取得)は次のものです。 #!/usr/bin/php require_once("../php/default/sdk.class.php"); $url = "https://sqs.ap-northeast-1.amazonaws.com/811118151095/suz-lab-queue"; $sqs = new AmazonSQS(array( "key" => "ACCES
cloudpackブログ - SQSってなんじゃ？（遅延送信、一括送信機能が追加）
SQSに新機能が登場しました。 今回追加されたのは、大きく分けて下記のの２つになります。 メッセージの一括送信、削除 キューとメッセージの遅延送信 先程発表されたので、早速試してみました。 ○キューとメッセージの遅延送信 遅延送信機能はコンソールから確認することができます。 はじめに、キューの遅延送信設定を確認してみます。 コンソールのSQSから「Create New Queue」ボタンでキューを作成します。 キューを作成すると、下記のキュー設定ダイアログが表示されます。 赤枠の部分に「Delivery Delay」という項目があり、ここで最大１５分まで遅延時間を設定することができます。 例として、遅延時間を45秒に設定すると、このキューで送信したメッセージはデフォルトで 送信後45秒後から受信可能になります。 次に、そのキューで「SendMessage」をしてみると、下記のようなメッセー
cloudpackブログ - SQSってなんじゃ？（AWSコンソールにSQS登場）
Amazon SQSがAWSコンソールから利用可能になりました。 これまでは、キューに入ったメッセージを確認する手段はプログラム経由でしたが、 これによりメッセージの状態がわかりやすくなると思います。 AWSコンソールを開いてみると、SQSのタブが増えているのがわかります。 そして、SQSタブをクリックするとSQSのキュー一覧画面が表示され、今までに作ったキューが表示されます。 はじめに、キューの作成をしてみます。 「Create New Queue」ボタンをクリックします。 すると、キュー作成のダイアログが開きます。 ここで、下記を指定して、「Create Queue」ボタンをクリックすると、 キュー一覧画面に戻り、キューのメッセージ数が1つ増えているのがわかります。 Queue Name：キュー名 Default Visibility Timeout：読み込み後、他のクライアントから秘
cloudpackブログ - SQS & CloudWatch & Auto Scaling、その後
SQSとCloudWatchとAuto ScalingのようにSQSとAuto Scalingを使って、 複数インスタンスでクロールする仕組みを運用しています。 はじめは、SQSのキューのサイズをCloudWatchに登録のようにCloudWatchのカスタムメトリクスを使って、 SQSのキューのサイズ(メッセージ数)とAuto Scalingの連携を取っていたのですが、 CloudWatchでSQSのメトリクスが取得可能にのように、 SQSのメトリクス自体が標準でサポートされるようになりました。 上記より、現在はAuto Scalingのトリガーとなるメトリクスはカスタムメトリクスではなく、 標準のSQSのメトリクス(ApproximateNumberOfMessagesVisible)を利用するように変更しました。 現状、下記のような仕組みで処理をしています。 SQSにクロールしたい対
cloudpackブログ - SQSのキューのメッセージが処理されなくなったら通知(CloudWatch)
キューのメッセージが0になったときに通知することは、よくやると思いますが、ここでは、キューのメッセージが処理されなくなったときの通知に関して紹介します。 当然、CloudWatchを利用するわけですが、キューのメッセージが処理されなくなった状態の確認は、アプリケーションが受信したメッセージ数を表す下記のNumberOfMessageReceivedを確認することで可能です。 キューのメッセージが処理されなくなった場合は、NumberOfMessageReceivedが「0」になるはずです。 そして、このNumberOfMessageReceivedに対して、下記のようにアラームを作成します。 ここでは値が「0」になったら(メッセージが処理されなくなったら) アラーム状態になるように設定しています。 メールは下記のように、状態が「ALARM」、「OK」、「INSUFFICIENT_DATA」
cloudpackブログ - CloudWatchでSQSのメトリクスが取得可能に
SQSのキューのサイズがCloudWatchで見れますように。(カスタムメトリクスじゃなくて) #AWS77 #jawsugless than a minute ago via Tweet-Watch Favorite Retweet Replysuz-lab suz_lab AWS Management ConsoleのCloudWatchタブを見ると、 左のメニューの下部にSQSの項目があることが確認できます。 クリックすると、下記のメトリクスが取得できていることがわかります。 NumberOfMessagesSent SentMessageSize NumberOfMessagesReceived NumberOfEmptyReceives NumberOfMessagesDeleted ApproximateNumberOfMessagesVisible ApproximateNu
cloudpackブログ - SQSのメッセージの処理状態をSimpleDBで管理
とても稀にですが、下記のFAQにもある通りSQSのメッセージは、同じものが複数回配信される可能性があるようです。 Q: How many times will I receive each message? それぞれのメッセージは何回受信しますか? Amazon SQS is engineered to provide “at least once” delivery of all messages in its queues. SQSはキュー内の全てメッセージを”少なくても一回”配信するように処理しています。 Although most of the time each message will be delivered to your application exactly once, それぞれのメッセージは、ほとんどの場合、使用しているアプリケーションに対してちょうど一回配信されます
cloudpackブログ - SQSとCloudWatchとAuto Scaling
今回は、SQSのメッセージ数をCloudWatchにカスタムメトリクスとして登録し、そのカスタムメトリクスでAuto Scalingします。 仕様としては、一日一回の頻度でSQSに一気にメッセージを登録して、それを複数インスタンスで処理するものです。 メッセージ数が1以上になれば、10インスタンス立ち上げ、メッセージ数が0になったら、全てのインスタンスをターミネートするようにしています。 SQSのメッセージ数をCloudWatchにカスタムメトリクスとして登録する部分は、SQSのキューのサイズをCloudWatchに登録で、SQSのメッセージを処理するインスタンスは、SQSのキューのメッセージがなくなたらEC2インスタンスをシャットダウン下記で紹介しています。 (ちなみにここでは、シャットダウンはしないようにしています。) そして、今回もいつも通りPHP(AWS SDK)で実現してみました
cloudpackブログ - SQSのキューのメッセージがなくなたらEC2インスタンスをシャットダウン
タイトルからだと分かり難いかもしれませんが、SQSのキューのメッセージを処理し続けて、メッセージがなくなったらシャットダウンするようなインスタンスを作ってみたいと思っています。 ※ OSはCentOS(5.6)です。 はじめに、下記のようなPHPスクリプトを用意します。 ▼ common.php define("AWS_KEY" , "AAAAAAAA"); define("AWS_SECRET_KEY" , "SSSSSSSS"); define("CP_SQS_URL_CRAWL", "https://sqs.ap-northeast-1.amazonaws.com/000000000000/crawl"); ▼ receive-message require_once("/opt/cloudpack/bin/common.php"); require_once("/opt/aws/p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
