AWS X-RayでLambda→Athenaのアクセスを可視化してみた

以前こんなものを作りましたが、これをAWS X-Rayで可視化してみたら、何がわかるのか、実験してみました。

Amazon AthenaをAWS Lambdaから操作できるようにしてみた

AWS X-Ray デーモンの実行

AWS X-Ray SDK は、AWS X-Ray に Trace データを直接送信しないらしいので、送付用のEC2インスタンスを作成します。ユーザデータとして以下を登録してインスタンスを生成するだけなので、簡単です。

#!/bin/bash
curl https://s3.dualstack.us-east-1.amazonaws.com/aws-xray-assets.us-east-1/xray-daemon/aws-xray-daemon-2.x.rpm -o /home/ec2-user/xray.rpm
yum install -y /home/ec2-user/xray.rpm

システムログにxrayのインストールログが出力されていたのでOKでしょう。

Examining /home/ec2-user/xray.rpm: xray-2.0.0-1.x86_64
Marking /home/ec2-user/xray.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package xray.x86_64 0:2.0.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch              Version               Repository        Size
================================================================================
Installing:
 xray            x86_64            2.0.0-1               /xray            6.6 M

Transaction Summary
================================================================================
Install  1 Package

Total size: 6.6 M
Installed size: 6.6 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : xray-2.0.0-1.x86_64                                          1/1 
xray start/running, process 2576
  Verifying  : xray-2.0.0-1.x86_64                                          1/1 

Installed:
  xray.x86_64 0:2.0.0-1                                                         

Complete!

Lambdaアプリ側の準備

今回Javaアプリケーションを動かすわけですが、LambdaアプリケーションをX-Rayで監視したい場合は、Lambdaアプリケーションの「設定」タブの中で以下のチェックボックスをONにするだけで良いようです。

スクリーンショット 2017-04-23 22.21.44.png

参考:http://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-services.html

またX-Rayを操作するための権限をIAMで設定する必要もあります。今回は試験的な運用だったため「AWSXrayFullAccess」をつけてしまいましたが、実際の運用に合わせてこの辺りは慎重に選びたいですね。

アプリを起動して可視化してみる

ここまでできれば、普通にLambdaアプリを動かしてみてX-Rayでどのように見えるのか確認ができます。今回Lambdaアプリケーションには以下のJSONをインプットとして与えるようにしました。以前の記事でサンプルとしてAthenaのテーブルからデータを取得するようにした際の入力値です。

{
  "region": "us-east-1",
  "s3Path": "s3://ishida-athena-staging-dir/",
  "sql": "SELECT elbname, requestip,  requestport, backendip, backendport, requestprocessingtime, backendprocessingtime, timestamp FROM sampledb.elb_logs order by timestamp desc limit 10",
  "columnListStr": "elbname, requestip,  requestport, backendip, backendport, requestprocessingtime, backendprocessingtime,  timestamp"
}

実行後1分ほど待つと、以下のような表示がX-Rayで確認できました。無事可視化ができたようです。

スクリーンショット 2017-04-23 22.56.40.png

X-Rayの中身を確認してみる

表示されたService Mapの右側のオブジェクトをクリックすると以下のような表示がされました。
スクリーンショット 2017-04-23 22.56.51.png

それぞれの処理にどの程度時間がかかってレスポンスとして何を返しているのかが一覧でわかります。
表示されているIDをクリックすると、そのTraceの詳細が確認できました。

スクリーンショット 2017-04-23 22.56.58.png

これをみる限り、Lambdaアプリの初期化に230ms程度、実際のAthena接続部分に約3秒程度かかっている、という風にみればいいんですかね。この処理全体としては4.6秒かかっているので、実際にAthenaにアクセスするため以外に1.5秒ほどは時間が取られている、と理解すればいいんでしょうか。この辺はもっと勉強が必要だ(^^;

ちなみにエラーが出ている場合は、その例外の中身も確認することができるようです。

まとめ

それぞれの処理がどの程度時間にかかっていて、さらに呼び出し関係までこれほど簡単にセットアップしつつ可視化ができるのは強力ですね。これからMicroservicesなどで分散して処理をさせることが当たり前になることを考えると、必須の技術と言えると思います。Springで言えばZipkinとSleuthをAWS上で実現しているような感じですね。

続きを読む

AtlassianのLocalStackを使ってみてなんとなく理解するまでのお話

Atlassianが「LocalStack」なんてとても便利そうなものを出していたけど、なかなか使い方を解説しているページが見つからなかったので、とりあえず使いながらなんとなく中身を理解するまでのお話。

https://github.com/atlassian/localstack
スクリーンショット 2017-04-23 17.53.59.png

起動

いくつかGithubで利用方法が紹介されていますが、今回はdockerでの利用をしてみます。

$ docker run -it -p 4567-4578:4567-4578 -p 8080:8080 atlassianlabs/localstack
2017-04-23 08:50:15,876 INFO supervisord started with pid 1
2017-04-23 08:50:16,879 INFO spawned: 'dashboard' with pid 7
2017-04-23 08:50:16,885 INFO spawned: 'infra' with pid 8
(. .venv/bin/activate; bin/localstack web --port=8080)
. .venv/bin/activate; exec localstack/mock/infra.py
Starting local dev environment. CTRL-C to quit.
 * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
 * Restarting with stat
Starting local Elasticsearch (port 4571)...
Starting mock ES service (port 4578)...
Starting mock S3 server (port 4572)...
Starting mock SNS server (port 4575)...
Starting mock SQS server (port 4576)...
Starting mock API Gateway (port 4567)...
Starting mock DynamoDB (port 4569)...
Starting mock DynamoDB Streams (port 4570)...
Starting mock Firehose (port 4573)...
Starting mock Lambda (port 4574)...
Starting mock Kinesis (port 4568)...
Starting mock Redshift server (port 4577)...
 * Debugger is active!
2017-04-23 08:50:18,537 INFO success: dashboard entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2017-04-23 08:50:18,538 INFO success: infra entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
 * Debugger PIN: 844-652-544
Ready.

とりあえず起動はしたみたい。で、http://localhost:8080/にアクセスしてみたけど、こんな感じで何も表示されず。

スクリーンショット 2017-04-23 17.59.04.png

使ってみてわかりましたが、要は本当に各種サービスが以下のアドレスで利用できるようにしてくれたもののようです。

全部試すのもアレなので、とりあえず馴染み深いDynamoDBとS3を使ってみる。

DynamoDBのテーブル作成

全然関係ないですが、http://localhost:4569/にアクセスすると以下のレスポンスをもらえます。デフォルトはus-east-1で動いている想定のようで。(Githubページにも書いてあった。バインドすればいくつか設定を変更できるようですね。)

healthy: dynamodb.us-east-1.amazonaws.com 

では早速テーブルをCLIから作ってみます。一応作成前にlist-tablesをしてみますが、もちろん何も登録されていません。

$ aws --endpoint-url=http://localhost:4569 dynamodb list-tables
{
    "TableNames": []
}

こちらを参考にさせていただいて、create-tableコマンドを発行します。

$ aws --endpoint-url=http://localhost:4569 dynamodb create-table --table-name test --attribute-definitions AttributeName=testId,AttributeType=S --key-schema AttributeName=testId,KeyType=HASH --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1
{
    "TableDescription": {
        "TableArn": "arn:aws:dynamodb:us-east-1:000000000000:table/test", 
        "AttributeDefinitions": [
            {
                "AttributeName": "testId", 
                "AttributeType": "S"
            }
        ], 
        "ProvisionedThroughput": {
            "NumberOfDecreasesToday": 0, 
            "WriteCapacityUnits": 1, 
            "ReadCapacityUnits": 1
        }, 
        "TableSizeBytes": 0, 
        "TableName": "test", 
        "TableStatus": "CREATING", 
        "KeySchema": [
            {
                "KeyType": "HASH", 
                "AttributeName": "testId"
            }
        ], 
        "ItemCount": 0, 
        "CreationDateTime": 1492937089.534
    }
}

なんか作られたっぽいですね。もう一度list-tablesをしてみます。

$ aws --endpoint-url=http://localhost:4569 dynamodb list-tables
{
    "TableNames": [
        "test"
    ]
}

出来上がってますね。なるほど、本当にAWS上でやる操作をEndpointURLを変更するだけで操作できてしまうようです。これは思っていたよりも便利かも。

S3のバケットを作成してみる

S3のバケットも作成できるのか試してみます。まずバケットのリストを見てみますが、当然何もありません。

$ aws --endpoint-url=http://localhost:4572 s3 ls
(何も表示されず)

では作成してみます。

$ aws --endpoint-url=http://localhost:4572 s3 mb s3://kojiisd-test/
make_bucket: s3://kojiisd-test/
$ aws --endpoint-url=http://localhost:4572 s3 ls
2006-02-04 01:45:09 kojiisd-test

まじか、これは便利。ただdockerでサービス起動したら停止時に中身が消えてしまうから、できれば作成したものが残るような起動方法の方が色々試そうとしたら適していそうですね。
(作成時間がはちゃめちゃですが、とりあえずそこまで問題にはならないかな)

ちなみにDynamoDBのテーブルとS3のバケットを作成してから気づきましたが、http://localhost:8080/にアクセスしたら、作成したものが表示されていました。なるほど、そのためのDashBoardだったのか。素敵。

スクリーンショット 2017-04-23 18.20.02.png

まとめ

どれくらいどこまで何ができるのかは気になりますが、一般的なことであればだいたいローカルでできるような気がします。しかもEndpointURLを変更するだけで良さそうなので、これはかなり便利かも。今度作成したアプリを全てLocalStackで動かしてみるとかやってみようかな。

とりあえず、もっとこれは知られるべきと、思いました。

続きを読む

Amazon Lex でサンプルbotを試した

Amazon Lex

Lexがついに一般公開されました。
Alexa Voice Serviceで色々と頑張らなくても手軽にAlexaを使えそうです。

サンプルbotのモデル

公式ドキュメントのExercise2を通して、Lexの使い方を学んでいきたいと思います。

Pizza Ordering Bot

早速作っていきましょう。
※Lexはus-east-1(バージニア北部)のみで利用可能です。

1. lambda関数の用意

1-1: IAMロールの作成

マネジメントコンソールからIAMを選択し、サイドバーのロールから新しいロールの作成に進みましょう。
ロールタイプはAWSサービスロールのlambdaを選んでください。
ポリシーのアタッチ画面で検索窓に lex と入力し、
AmazonLexRunBotsOnlyを選択してロールを作成します。

スクリーンショット 2017-04-23 9.31.06.png

1-2: 関数の作成

ここを参考に作れば問題ないです。

ざっくり言うと lambda→ブランク関数→Node.js v4.3 を選択し、ドキュメントのコードをそのまま貼り付ければ問題ないです。
ロールについては、既存のロールを選択より先程作成したものをアタッチしてください。

2. Lex botの作成

コンソールの LexBotsCreate からbotを作成します。
名前は適当に(e.g. PizzaOrderingBot)、好きな声を選んで、Session timeout は5分で。Child-DirectedNo で大丈夫です。

3. SlotTypeとIntentの設定

3-1: Slotの追加

EditorタブのサイドバーからSlot typesにある+ボタンより新しいスロットを追加。
今回は以下のように追加します

  • Crusts というslotを作成し、valueに thickthin
  • Sizes というslotを作成し、valueに small, medium, large
  • PizzaKind というslotを作成し、valueに cheeseveg

※↓ではPizzaSizeになってますが、SizesでもPizzaSizeでも好きな名前をつけてください
スクリーンショット 2017-04-23 8.58.28.png

※ Slotとは

Alexaの質問に対して答えるべき単語のまとまり、といった感じです。
(Alexaが回答として期待している単語のまとまりと言うべきか。)
主要な都市や日時、空港や俳優などAmazonが用意しているものも利用可能です。
Amazonが用意したBuilt-in SlotはAMAZON.xxxで定義されており、インストールなどの必要もありません。

3-2: Intentの追加

EditorタブのサイドバーからIntentにある+ボタン、Create New Intentより作成しましょう。

3-2-1: Sample utterancesの編集

ここに入れた文章でAlexaに呼びかけると、反応して処理を開始します。
以下のような文章を追加します。

  • I want to order pizza please
  • I want to order a pizza
  • I want to order a {pizzaKind} pizza
  • I want to order a {size} {pizzaKind} pizza
  • I want a {size} {crust} crust {pizzaKind} pizza
  • Can I get a pizza please
  • Can I get a {pizzaKind} pizza
  • Can I get a {size} {pizzaKind} pizza
3-2-2: Slotsの編集

作成したslotを追加していきます。
Nameで登録した名前は、上のutterancesの文章や、lambdaの処理で利用する際のkeyとなります。
Slot typeは先程作成したものを選択、PromptにはAlexaから投げられる質問を入れます。
また、Requiredにはすべてチェックを入れましょう。

※ Promptの例
– pizzaKind: Do you want a cheese or veg pizza?
– size: What size pizza?
– crust: Thick or thin crust?

スクリーンショット 2017-04-23 9.37.54.png

3-3: その他設定

FulfillmentでAWS Lambda functionを選択し、先程作ったlambda関数を選択します。
Lambda initialization and validationConfirmation promptはとりあえずそのまま空白で問題ありません。

※ Intentとは

utterancesに追加した文章で我々が呼びかけるとAlexaが質問を投げかけてくるので、それに対してslotに入ってる単語で回答。また、promptでAlexaは別の質問を行いデータをさらに集める。それらのデータを用いてAlexaが回答、またはlambdaに処理が投げられる。
このような一連の流れをIntentとしてまとめています。

4. テスト

早速テストしましょう。画面上部の Build ボタンよりビルド完了後、画面右下のチャット欄からチェックできます。

スクリーンショット 2017-04-23 9.49.23.png

ビルド後はIntentが保存されて編集できなくなるのですが、画面上部でversionをLatestに変更すると再び編集が可能になります。

スクリーンショット 2017-04-23 9.37.39.png

5. おつかれさまでした😌

lambda関数の動きについては触れていませんが、今後何か書くかもしれません。
あとは音声入力などについても調べたいと思います。
(Alexa Voice ServiceのSkill Kitに追加できないのかしら…)

続きを読む

AWSのMFAの解除に日本語で挑戦した話

AWSのMFAの解除に日本語で挑戦した話

TL;DR

  • 最近だと「最初に日本人だって伝えると日本語の喋れるオペレーターから再度連絡してもらえるよ」って話を聞いたので挑戦してみた
  • Web上での申し込みやPINの入力については他の方が書かれているので割愛
  • 筆者の英語レベル
    • 読み

      • 公式ドキュメントやgithubの議論ぐらいなら読める
    • 書き
      • ほとんどしないしgoogle翻訳頼み
    • 聞き&喋り
      • 人と英語で会話するのは生まれて初めて

参考

流れと会話

  • Webで申し込み
  • 15分ぐらいして206からはじまる番号から電話がかかって来た

CSサポートから聞き取れた言葉 : “Amazon web service support desk”, “trouble” (多分AWSのサポートデスクです。トラブルとのことで電話しました。って言ってた)
俺 : “そーりー、あいきゃんとすぴーくいんぐりっしゅ。あいあむじゃぱにーず”
CSサポート : “contact”, “Japanese operator” (多分日本人オペレーターから折り返すって言ってた)
俺 : “おーけーおーけー”
CSサポート : “バーイ”
俺 : “ば、ばーい” (噛んだ)

  • 1時間後非通知の番号から電話かかってきて日本語でやりとりして完了

所感

  • 日本語でもイケた
  • 通話のノイズひどい
  • 外国人はフレンドリー、日本人はすごい丁寧

続きを読む

AWS の Ubuntu 16.04 で Etherpad as a service

AWS上でEtherpadを動かし、外からアクセスするようにできるまでのメモ書き。
DBはmysqlを使用。pluginはテーブルと画像挿入のをインストール。

前準備
AWS上のUbuntuパスワード変更
http://d.hatena.ne.jp/thata/20101116/1289890621

nodesインストール(次のに含まれているから不要?)
http://qiita.com/yuji_azama/items/45c0b413453534dba291

Ubuntu 16.04 に Etherpad をインストール
(コマンドを入力したら実行できる状態まで)
https://linuxconfig.org/install-etherpad-web-based-real-time-collaborative-editor-on-ubuntu-16-04-linux

起動時サービス
(サーバ起動時に自動でEtherpadが起動できるようにする)
http://pangency.hatenablog.com/entry/2015/05/08/111025

script の中身は

#! /bin/sh

case "$1" in
  start)
    /opt/etherpad/bin/run.sh
    ;;
esac

exit 0

とします。

ドメイン設定
https://ja.amimoto-ami.com/2013/11/29/elastic-ip-and-route-53/

nginxをリバースプロキシサーバとして使う。
(nodejs は80番ポートで起動できない?)
以下、Ethepadのデフォルトポートは9001 だが、settings.jsでポートを8080に変えた時の例。

upstream web-nodejs {
  server localhost:8080;
}
server {
  listen       80;
  server_name  etherpad.dslabgroup.com;

  location / {
    proxy_pass http://web-nodejs/;
  }
}

外からは80番ポートでアクセスするので、AWSのセキュリティの設定は、80番ポートに外からアクセスできるようにしていればいい。

nginx enableする (サーバ起動時にnginx起動)
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

plugins
https://static.etherpad.org/plugins.html # ここにPlugin一覧がある
https://help.ubuntu.com/community/Etherpad-liteInstallation#Plugins

cd /opt/etherpad-lite
npm install ep_tables2
npm install ep_copy_paste_images
# AWSでインスタンス再起動する
# (上記で自動でrun.shをするようにした場合の、サービスだけの再起動方法不明。。)

mysql 設定
デフォルトではjs製のDB DirtyDBを使うようになっている。データ毎(?)の容量の上限が1M?らしいので、mysqlに変える。
下記設定だけを行うと、create tableなどはetherpad 起動時に自動で行われる。
https://github.com/ether/etherpad-lite/wiki/How-to-use-Etherpad-Lite-with-MySQL
https://help.ubuntu.com/community/Etherpad-liteInstallation

続きを読む

Kinesis Firehose から Amazon ElasticSearch Service(以下es)へstreamした indexの削除運用

esのindexはRBDでいうdatabaseというのはよく書かれているが、

パーティショニングできるdatabaseという感想

実際のindex名は hoge-index-2017-04-20 という風に年月日を入れることが出来き、
この年月日は削除する対象としてを指定できる

Kinesis Firehoseからesにデータをstreamする際

Kinesis Firehoseの設定画面は下記のような設定がある
Amazon_Kinesis_Firehose.png

index rotation* で OneMonthにするとindex名にプラスして -年-月 を入れてくれる

esのindex削除運用

Elasticさん的には Curator を提供してくれているので使うのが吉

もっと簡単に過去のindexを削除したいのであれば

$ curl -Xdelete https://your-elasticsearch-domain/hoge-index-yyyy-mm-dd

をJenkinsに仕込んで/dayで実行してもよさそう

参考URL

Curator 3 で Amazon Elasticsearch Service を扱う
curator で Kibana 用の elasticsearch のインデックスを定期的に削除する

続きを読む

AWS SQSの各設定値の意味 & Ansibleの書式

概要

AWS SQSの各設定値の意味と、Ansibleの書き方です。

設定値

47f65646afce1836703bd3b19ce5092d.png

項目 設定内容
デフォルトの可視性タイムアウト(Default Visibility Timeout) キューのメッセージは、自動では削除されない。
そのため、メッセージ取得バッチ(Lambdaなど)が複数ある場合、それぞれが同一のメッセージを取得してしまう可能性がある。
これを回避するために、あるバッチからメッセージが取得されたら、他のバッチからメッセージが取得できないように、一定時間メッセージを非表示にする時間の設定。デフォルト30秒。
メッセージ保持期間(Message Retention Period) メッセージ保持期間
最大メッセージサイズ(Maximum Message Size) 1メッセージの最大サイズ
配信遅延(Delivery Delay) メッセージが登録された後、Lambdaなどのバッチがメッセージが取得できるようになるまでの時間。
可視性タイムアウトが、メッセージ取得後なのに対し、こちらはキューに登録後、一定時間メッセージを非表示にする。
メッセージ受信待機時間(Receive Message Wait time) ロングポーリングの時間。Lambdaなどのバッチがメッセージを取得しに行った時にキューが空だった場合、ここで設定された時間だけ、キューにメッセージが入ってくるのを待つ。
再処理ポリシーの使用 下記の機能を使う場合はチェック
デッドレターキュー(Dead Letter Queue) 処理に失敗したキューを退避させる、別のSQSのキュー名(ベットSQSキューの作成が必要)
最大受信数(Maximum Receives) リトライ回数

Ansibleの書式

main.yml
- name: sqs
  become_user: '{{ username }}'
  sqs_queue:
    # キューの名前
    name: 'my_sqs'
    # リージョン
    region: 'ap-northeast-1'
    # デフォルトの可視性タイムアウト
    default_visibility_timeout: 30
    # メッセージ保持期間
    message_retention_period: '{{ 86400 * 4 }}'
    # 最大メッセージサイズ
    maximum_message_size: 204800
    # 配信遅延
    delivery_delay: 0
    # メッセージ受信待機時間
    receive_message_wait_time: 0
    # 再処理ポリシーの使用
    redrive_policy:
      # 最大受信数
      maxReceiveCount: 2
      # デッドレターキュー
      deadLetterTargetArn: 'arn:aws:sqs:ap-northeast-1:{{ account_id }}:my_sqs_dlq'

参考

AWS SQS(Amazon Simple Queue Service)の使い方
【AWS】SQSをただただ触ってみただけの話
SQSのロングポーリング機能を試してみた

続きを読む