AWS

AWSクライアントを使ってLocalStack上のSNSやSQSに対してコマンドライン操作する

以前まで、AWS の SNS や SQS のサービスを利用するには AWS の契約が必須だと思っていたのですが、LocalStack の存在を知り、ローカルの Docker 上でも擬似環境を構築できることが判明しました。

これにより、費用面で難色を示されて AWS のテスト環境をなかなか用意してもらえない職場でも、ローカルで AWS に近い環境を試すことができます。

EC2(AmazonLinux)は CentOS、Aurora(RDS)は MySQL サーバで代用できたとしても、その他多くの AWS のサービスの擬似環境を用意するのには限界がありますからね。

今回は、ローカルスタックの構築とアプリケーションサービスの操作について紹介したいと思います。

・LocalStack の Docker コンテナの構築
・SNS のトピック操作(awscli)
・SQS のキュー操作(awscli)

SNS や SQS がどのようなものか知らない人は下記も参考にしてください。

24時間でAWS認定ソリューションアーキテクト(アソシエイト)に合格するためのプロセス以下の記事で、AWS認定ソリューションアーキテクト(アソシエイト)について試験概要を調べてみました。 https://itneko...

LocalStackについて

LocalStack は、AWS のモックフレームワークを提供してくるアプリケーションです。

冒頭で SNS や SQS と書きましたが、以下のサービスを localhost のそれぞれのポートで起動してくれます。

API Gateway : 4567
Kinesis : 4568
DynamoDB : 4569
DynamoDB Streams : 4570
Elasticsearch : 4571
S3 : 4572
Firehose : 4573
Lambda : 4574
SNS : 4575
SQS : 4576
Redshift : 4577
Elasticsearch : 4578
SES : 4579
Route53 : 4580
CloudFormation : 4581
CloudWatch : 4582

よって、SNS であれば http://localhost:4575 のエンドポイントに対してトピック(topic)の操作ができますし、SQS であれば http://localhost:4576 が対象になります。

LocalStackをコンテナで動かす

LocalStack の利用方法はいくつかありますが、今回は冒頭でも書いた通り Docker で動かします。

DockerHub にイメージがあるので、それを利用してみましょう。

docker pull してもいいのですが、ローカルの Docker コンテナたちは docker-compose.yml で管理しているのでこちらに定義します。完全に自分都合ですが・・・。

docker-compose.yml を保存したら LocalStack を起動してみます。初回なので –build しておきますか。

AWS-CLIの実行環境を整える

これで LocalStack は使えるようになりましたが、実際に SNS や SQS の操作をするには以下の 2 つの作業が必要になります。

・awscliのインストール
・AWSの認証プロファイルの作成

Linux の場合は、AmazonLinux なら awscli が標準で組み込まれています。

CentOS の場合は以下で書きましたので参考にしてください。

CentOS7でawscliをセットアップしてS3に接続するAmazonLinux だと最初から AWS コマンドラインインターフェイス(CLI)が使えるのでいいですが、今回は CentOS7 を...

Mac の場合は brew でインストールすることになります。

コンテナの環境変数でデフォルトは東京リージョンとしましたが、別途、SNS や SQS などの各サービスを操作するためのプロファイルを用意する必要があり、ここでもリージョンは指定しておきます。

早速、作ります。「Access Key ID」や「Secret Access Key」はダミーの値で問題ないようなので、ここでは「dummy」としておきます。

プロファイル名は仮に「local」としておきます。

これで、各サービスを操作できる状態となりました。

LocalStackのSQSをコマンドラインから操作する

SQS の操作をする前に、以下を作成しておきます。

・SNSのトピックスの作成
・SQSのキューの作成
・SNSのトピックからキューにメッセージを送信する権限付与
・SNSのトピックとSQSのキューの連携設定(サブスクライバ)

必要に応じて「デッドレターキュー」の作成もしておくといいかもしれませんね。

ここでは仮に、それぞれ 1 個ずつ作成して SNS と SQS を連動させてみます。

トピック名もキュー名もリラックマ(rilakkuma)とします。ワンライナーで書かずにシェルスクリプトにした方がわかりやすかったですね。

途中 ¥(バックスラッシュ)で折り返していますが、少しコマンドが見にくいかも・・・。

SQSの操作をする

上記で作成したキューがキュー一覧に表示されるか確認してみます。

キューをたくさん登録している場合は、–queue-name-prefix をつけてプレフィックス指定で検索してみてください。

このキューに受信可能なメッセージが何件あるか確認します。

他で受信されて、一定時間アクティブではないキューの件数を確認します。

キューのメッセージを 1 件受信してみます。
(長いのでBody以降を省略します)

メッセージを受信して削除します。受信したメッセージの ReceiptHandle を指定して削除です。

以下の例では受信したメッセージを直接キューから削除していますが、特定のキューメッセージを削除したい場合は ReceiptHandle の値を確認してから、別途削除コマンドを実行してください。

SNS を経由してキューを登録する場合は、直接キューに対してメッセージを送ることはないですが、コマンドでは試しておきましょう。

SQS に対して、開発中に確認したいとしたらこのくらいでしょうか。

SNSの操作をする

今回はサブスクリプションの設定で、SNS のトピックにパブリッシュされたメッセージを SQS に登録するようにしました。

その際、attribute でフィルタ設定をしています。以下の部分ですね。

–attribute-value {“Type”:”KUMA”}

これを設定することで、トピックにパブリッシュされたものの中で、Type が KUMA 以外のものは SQS にキュー登録しないようにできます。

queue-rilakkuma 以外に queue-kiiroitori を作ったとしたら、以下のように Type の値によって別々のキューに振り分けすることもできるのです。

・TypeがKUMA: queue-rilakkuma
・TypeがTORI: queue-kiiroitori

リラックマをサンプルにしたので、知らない人はわかりませんね。もっと一般的なものを例にすれば良かったですね。すみません・・・。

リラックマ:KUMA:queue-rilakkuma

コリラックマ:KUMA:queue-rilakkuma

キイロイトリ:TORI:queue-kiiroitori

よって、SNS のパブリッシュは以下のようなコマンドになります。

topic-rilakkuma に対してパブリッシュしたものが、attribute の Type によってキューの振り分け先が決めれるということです。

仮に Type が PERSON だったとしたら、フィルタで弾かれるのでキューには登録されません。

SNS をコマンドから使うとしたら Publish くらいでいいでしょうか。