AWS Service Health Dashboard のRSS Feed をSlack に自動登録する #aws #slack
目次
前提
AWS の障害情報を確認しようと思うと、まずは AWS Personal Health Dashboard の情報をAmazon SNS 経由でSlackに通知するという、確実でお手軽な方法を検討するかと思います。
これはこれで設定を行い Design for Failure を意識して他の手段も用意してみたいと思います。
どこまで気にするかという部分はあるので、今回は誰でも確認できる AWS Service Health Dashboard の情報もSlackに通知されるようにしたいと思います。
RSS Feed URLが分割されている
AWS Service Health Dashboard を確認するとわかるのですが、対象のリージョンとサービスの組み合わせでRSS FeedのURLが分割されています。
SlackにRSS Feedを登録するには、RSSアプリをワークスペースにインストールして /feed subscribe [RSS Feed URL] のスラッシュコマンドを入力する必要があります。
この分割されたURLが数十個というレベルではないので、手動で登録するというのは非現実的な対応となります。
1つのURLに情報が集約されているものがあれば解決しそうなのですが.・・・調べてみると http://status.aws.amazon.com/rss/all.rss というURLが存在するようです。
Service Health DashboardのRSSページについて
https://forums.aws.amazon.com/thread.jspa?threadID=181220forums.aws.amazon.com
実際に http://status.aws.amazon.com/rss/all.rss を確認してみると
- 全リージョンの情報が配信されているように見える
- 直近15件の情報が配信されているように見える
という感じになっていそうなので、この情報で必要十分な場合には問題解決となります。
しかし、実際には利用しているリージョンが限られていて、全リージョンの情報よりも必要なものだけを選んで登録しておく方が使い勝手が良さそうです。
リージョンとサービスの組み合わせでURLが個別化されているので、整理する場合もリージョンとサービスを軸にして整理するとスッキリしそうです。
AWS Service Health Dashboard をスクレイピングして整理する
数の問題で手動は無理そうなのは分かったので、自動でどうにかする方法を考えます。 まずは、全部のRSS Feed URLを取得して必要な情報を選び出せるようにします。
ということで、久しぶりに手を動かせる機会なのでgolangで作ってみました。
やっていることは単純で AWS Service Health Dashboard のWebからRSSのURLをスクレイピングして、リージョン単位とサービス単位で整理した状態で ファイルに出力します。
ファイルの内容はSlackのRSS Feed登録用のリストとなっていて /feed subscribe [RSS Feed URL] の形式で１行単位で出力されています。
# GLOBAL /feed subscribe https://status.aws.amazon.com/rss/awsiotdevicemanagement.rss /feed subscribe https://status.aws.amazon.com/rss/awswaf.rss /feed subscribe https://status.aws.amazon.com/rss/billingconsole.rss /feed subscribe https://status.aws.amazon.com/rss/chatbot.rss /feed subscribe https://status.aws.amazon.com/rss/chime.rss /feed subscribe https://status.aws.amazon.com/rss/cloudfront.rss /feed subscribe https://status.aws.amazon.com/rss/globalaccelerator.rss /feed subscribe https://status.aws.amazon.com/rss/iam.rss /feed subscribe https://status.aws.amazon.com/rss/import-export.rss /feed subscribe https://status.aws.amazon.com/rss/interregionvpcpeering.rss /feed subscribe https://status.aws.amazon.com/rss/management-console.rss /feed subscribe https://status.aws.amazon.com/rss/marketplace.rss /feed subscribe https://status.aws.amazon.com/rss/organizations.rss /feed subscribe https://status.aws.amazon.com/rss/resourcegroups.rss /feed subscribe https://status.aws.amazon.com/rss/route53.rss /feed subscribe https://status.aws.amazon.com/rss/route53domainregistration.rss /feed subscribe https://status.aws.amazon.com/rss/supportcenter.rss /feed subscribe https://status.aws.amazon.com/rss/trustedadvisor.rss # # af-south-1 /feed subscribe https://status.aws.amazon.com/rss/apigateway-af-south-1.rss /feed subscribe https://status.aws.amazon.com/rss/autoscaling-af-south-1.rss /feed subscribe https://status.aws.amazon.com/rss/certificatemanager-af-south-1.rss ... more
これで情報が整理できたので、必要なものだけを選んで登録できるようになりました。 しかし、Slackへの登録も数が多ければ手動で行うのは難しい作業となるので可能な限り自動化を試みようと思います。
スクレイピングした結果をSlackに自動登録する
上記で作成したファイルを元にして、Slackへの自動登録を考えます。 まずSlackのAPIで登録できれば、それが簡単なので確認してみます。
Google先生に聞いてみると chat.command という公式ドキュメントに記載がないAPIエンドポイントがあるらしい。
そのエンドポイントをレガシートークンを使って呼び出せば、スラッシュコマンドを送信でできるらしい。
しかし、2020年5月5日以降はこのレガシートークンの作成が行えない。。。
ということで、他の方法を考えるのですが今回はサーバーサイドで画面なしで登録したいという要件ではなく、手元のPCで自動登録ができれば必要十分という状態です。
そうなると、手軽にできるのはブラウザを操作して自動登録を行う方法で、Google Chromeなら手軽に実現出来そうです。
スクレイピングに続き、Google Chromeの自動操作もgolangで作ってみました。
こちらもやっていることは単純で、前述した /feed subscribe [RSS Feed URL] 形式で記載されたファイルを読み込んで、Slackの指定チャンネルにメッセージを送信するだけです。
事前にGoogle Chromeのインストールが必要なことと、メッセージを送信したいSlackのチャンネルにアクセスできる準備は必要ですが、そのほか自動で実行できます。
実際に手元のMacで AWS Service Health Dashboard に記載されている全てのRSS Feed URLを登録した場合、以下のような結果になりました。
% ./cmd2s 2020/06/15 17:25:56 ------- start cmd2s ------- 2020/06/15 17:25:56 -> loadConfig(): 0.000103454 sec 2020/06/15 17:25:56 -> cmdCount: 1889 2020/06/15 17:25:56 -> readCommands(): 0.000439254 sec 2020/06/15 17:26:07 -> loginToSlack(): 10.781574362 sec 2020/06/15 17:56:02 -> sendCmdToSlack(): 1794.885672638 sec 2020/06/15 17:56:17 -> checkResultToSlack(): 14.794882938 sec 2020/06/15 17:56:17 -> writeCheckResult(): 0.000645365 sec 2020/06/15 17:56:17 ========================== 2020/06/15 17:56:17 -> total: 1820.464321942 sec 2020/06/15 17:56:17 ------- end cmd2s -------
1,889個もURLあったのかよ。。。という驚きの方がw Google Chromeを表示させて実行しているので、30分近く時間がかかったのかなぁーと。Headlessモードでも試してみましたが、うまく動かず。。。今後確認したいとおもいます。
また、今回は実行結果を確認する手段として最後に /feed list を実行して出力結果を取得しています。
Only visible to you Slackbot 8:28 PM ID: 1210548705408 - Title: Amazon Virtual Private Cloud (Osaka-Local) Service Status URL: https://status.aws.amazon.com/rss/vpc-ap-northeast-3.rss ID: 1186712303954 - Title: Amazon Simple Workflow Service (Osaka-Local) Service Status URL: https://status.aws.amazon.com/rss/swf-ap-northeast-3.rss ID: 1185333543893 - Title: Amazon Simple Queue Service (Osaka-Local) Service Status URL: https://status.aws.amazon.com/rss/sqs-ap-northeast-3.rss ... more
これは1実行単位で結果を取得していると、途中で止まったりさらに時間がかかったりしたためですが、最終的には実行されていることが確認できれば問題ないので今回はこれで必要十分でした。
また、仕組み的にはどんな文字列もSlackに送信できますが、今回は /feed subscribe [RSS Feed URL] に特化しています。
利用しているSlackが Azure AD によるログインが必須となるとめ、この部分も特化して作成しています。
まとめ
- AWS Service Health Dashboard の情報をSlackで通知したかった
- 調べてみたらRSS Feed URLがすごい数があった
- 自動で登録しないと厳しいが、API経由で登録する術がなかった
- 結果としてGoogle Chromeを操作して自動登録してみた
- 自動登録に利用するためのファイルをAWS Service Health Dashboard をスクレイピングして作成した
- どちらもCLIだけで完結できそうですが、今回はgolangで作成してみた
- 何とか自動登録できたので結果としては問題なし
- Headlessモードでの対応とか今後確認していきたい
以上になります。
Following is in English
S3の署名付き URLを利用する際に注意する3つのポイント #aws #s3 #lambda #python #serverless
今回は
みんな大好きAWS S3ですが、署名付き URL（Pre-Signed URL）という便利で素敵な機能が利用できます。
非常によく利用される機能なので、ここで稚拙な
説明を書くようなことは割愛しますが、公式ドキュメントだと以下 Amazon CloudFront のドキュメントに詳細が書かれています。
今回はこのS3の機能をPython AWS Lambda で利用する際にハマったポイントを共有します。
Boto3 ドキュメントの確認
今回利用したAWS SDK Python（Boto3）のドキュメントを確認してみると
generate_presigned_url(ClientMethod, Params=None, ExpiresIn=3600, HttpMethod=None) となっており ClientMethod に get_object や put_object と言った署名付き URLにて操作を許可したいメソッドを指定して、Params に bucket name と key name を指定するだけで戻り値として署名付きのURLが得られる完結な作りになっています。
通常は特に気にせず利用すればハマることもないかと思います。 今回は短時間ではなく1週間程度の期限を想定したことと、AWS Lambdaを利用したことでハマるポイントを作ってしまった形になります。
また、これに加えて Amazon S3 における AWS 署名バージョン についても考慮する必要があったため解決まで色々試行錯誤することになりました。
Point.1 実行権限について
AWS Lambdaを利用する場合 IAM role を利用して実行時に必要最低限の権限を付与した IAM policy を利用する形になるかと思います。
今回も個人的に好きな Chalice (Python Serverless Microframework for AWS) を利用しています。詳細は以下をご確認ください。
Chalice のメリットである IAM policy 自動生成は当然ながら利用するので generate_presigned_url(ClientMethod, Params=None, ExpiresIn=3600, HttpMethod=None) 関数するだけで問題ないと思っていました。
しかし、実際には自動生成で作成された IAM policy はClientMethod に記載したメソッドを 加味しない 状態で作成されていました。権限的には許可されていない状態となります。
この状態で generate_presigned_url を実行すると 権限不足で実行が失敗する と思っていましたが、実際には実行は問題なく終了して署名付きのURLが取得できます。
この取得したURLにアクセスすると、この段階で権限がないというエラーが表示され何も操作することができません。
だとしたらURL発行の段階で教えて欲しいのですが・・・ちょっと残念な仕様ですね。
以上を踏まえて generate_presigned_urlを利用して署名付きのURLを取得した場合で、アクセス権限が無い といったエラーでアクセスが行い時は、そもそも署名付きのURLを発行している IAM policy が必要な権限を持っているか確認することをお勧めします。
今回はIAM policyの自動生成を利用していたため、この部分に気がつくのが遅くなりだいぶ遠回りをして時間を無駄にした感が強いです・・・単純なところのなので見逃しがちですが、皆様はお気をつけください。
Point.2 有効期限について
IAM policy を追加して無事にアクセスはできるようになりました。 しかし今度は署名付きのURLが指定した有効期限より前に失効してしまう現象に遭遇しました。
この段階で指定していたのはExpiresIn=864000（10日間）でドキュメントには特に制限は書かれていないので原因が分からず困っていました。
しかしWebを検索してみると問い合わせが多い内容のようで以下の公式ドキュメントが展開されていました。
・AWS Identity and Access Management (IAM) インスタンスプロファイル: 最大 6 時間有効
・AWS Security Token Service (STS): 最大 36 時間有効 (AWS アカウントユーザーや IAM ユーザーの認証情報など、永続的認証情報を使用して署名した場合)
・IAM ユーザー: 最大 7 日間有効 (AWS 署名バージョン 4 を使用した場合)
という記述があることから最大 7 日間なのかーという部分しか確認せずにExpiresIn=604800を指定してみましたが、残念ながら有効期限より前に失効する状況は改善しませんでした。
それもそのはずで、よく読めば利用している認証情報で有効期限の最大値が決まり、その最大値で有効期限が失効するということになります。
AWS LambdaだとIAM role を利用しているので、AssumeRole アクションにてAWS STS から一時トークンを取得し、その一時トークンで認証を行なっていることになります。
そのため、上記ドキュメントに記載のSTS 利用時に合致し指定している7日を待たずに失効する形になっていました。
ちなみに AssumeRole は
By default, the temporary security credentials created by AssumeRole last for one hour. However, you can use the optional DurationSeconds parameter to specify the duration of your session. You can provide a value from 900 seconds (15 minutes) up to the maximum session duration setting for the role. This setting can have a value from 1 hour to 12 hours. To learn how to view the maximum value for your role, see View the Maximum Session Duration Setting for a Role in the IAM User Guide. The maximum session duration limit applies when you use the AssumeRole API operations or the assume-role CLI commands. However the limit does not apply when you use those operations to create a console URL. For more information, see Using IAM Roles in the IAM User Guide.
の記載があるので、有効期限が最大でも12時間となるので今回はこの制限でURLも同時に失効していたことになります。
で、修正するにはどうすればいいのかと言うと・・・
最大 7 日間有効な署名付き URL を作成するには、まず、使用する SDK への IAM ユーザー認証情報 (アクセスキーとシークレットアクセスキー) を指定します。次に、AWS 署名バージョン 4 を使用して署名付き URL を生成します。
の記載にあるように、IAM user を利用する必要があるのでアクセスキーとシークレットアクセスキーをAWS Lambda中で指定して署名付き URLを生成する必要があります。
AWS Lambdaのソースコード中にアクセスキーとシークレットアクセスキーを持たせるわけにはいかないので、今回は定番のAWS Systems Manager パラメータストアを利用しました。
使う側からするとSTSの有効期限を7日までに伸ばす方法があるか、URL文字列にこの情報を含めずにURLを作ってくれる方が嬉しいんですが・・・そこは将来に期待しております。
あとは、以下のページにあるスニペットをそのまま使えば 問題なく7日間有効な署名付き URLが生成できます。
import boto3 from botocore.client import Config # Get the service client with sigv4 configured s3 = boto3.client('s3', config=Config(signature_version='s3v4')) # Generate the URL to get 'key-name' from 'bucket-name' # URL expires in 604800 seconds (seven days) url = s3.generate_presigned_url( ClientMethod='get_object', Params={ 'Bucket': 'bucket-name', 'Key': 'key-name' }, ExpiresIn=604800 )
以上を踏まえて 署名付きのURLが指定した有効期限より前に失効する場合は、利用している認証情報が一時トークンを使用していないかを確認することをお勧めします。
また、合わせて署名バージョンについても SigV4（AWS 署名バージョン 4）を利用する必要があるため、確認することをお勧めします。
今回はIAM roleで取得した一時トークンを利用していたことと、署名がSigV2で行われていたことの2点が問題となっていました。 SigV4を利用していないだけかと思い、もう一つの認証情報の件にたどり着くのが遅くなりました。皆様はお気をつけください。 今回は最終的にAWSサポートに確認して作業を行いましたが、AWSサポートは対応が素晴らしいのでもっと早めに確認するべきだったと。
Point.3 署名バージョンについて
前述のSigV4（AWS 署名バージョン 4）を利用する件については、ここ最近のSigV2 廃止の話題でご存知かもしれません。
Amazon S3 における AWS 署名バージョン 2 の廃止
Amazon S3 における署名バージョン 2 は廃止され、署名バージョン 2 の最終サポートは 2019 年 6 月 24 日に終了します。2019 年 6 月 24 日以降、Amazon S3 は署名バージョン 4 を使用して署名された API リクエストのみを受けつけます。
ということで、上記のページを読んでみると利用しているBoto3（Python）については
| この SDK または製品を使用する場合 | この SDK バージョンにアップグレード | Sigv4 を使用するために、クライアントでコード変更が必要ですか。 |
|---|---|---|
| Boto3 | 1.5.71 (Botocore)、1.4.6 (Boto3) にアップグレード。 | はい |
との記載がありました。Boto3のバージョンアップだけではなくクライアントでコード変更が必要 という記載があります。
これはPoint.2で紹介したコードスニペットをみると分かりますが
import boto3 from botocore.client import Config # Get the service client with sigv4 configured s3 = boto3.client('s3', config=Config(signature_version='s3v4'))
S3のクライアントconfig=Config(signature_version='s3v4'))作成時に明示的に SigV4の利用を宣言する必要があるためとなります。
コードとしては以下のあたりが該当するかなーと。
署名バージョンの確認については、S3のログを利用して確認しました。
最近のアップデートでログに署名バージョンが出力されるようになったようです。
| Change | Description | Date |
|---|---|---|
| Added new fields to the server access logs | Amazon S3 added the following new fields to the server access logs: Host Id, Signature Version, Cipher Suite, Authentication Type, and Host Header. For more information, see Amazon S3 Server Access Log Format. | March 5, 2019 |
S3 サーバーアクセスのログはベストエフォートでの配信となるので 1時間程度経過したのちに配信されることになるかと思います。
ベストエフォート型のサーバーログ配信
サーバーアクセスログレコードの配信は、ベストエフォートで行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。
サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。
サーバーのログ作成機能はベストエフォート型であるため、AWS ポータルで利用できる使用状況レポート (AWS マネジメントコンソール でレポートされる請求およびコスト管理レポート) には、サーバーログに記録されていないアクセスリクエストが含まれる場合があります。
さらに今回はログを確認する手段としてDatadogを利用しました。 ログインテグレーションを行なっていれば検索も簡単に行えますし 他のAWS関連メトリクスと1箇所で確認できるのは非常に便利ですね。
以上を踏まえて 署名バージョンについては、Boto3（Python）に関してはSigV4を使うために明示的にプログラム中でバージョン指定が必要であり、これを行わないとSigV2で通信されていることがわかりました。
単純にSDKのアップデートでは対応できないことになるので、S3に対してアクセスを行なっているプログラムを確認する必要があります。
今後はSDK側のデフォルトがSigV4に変更というような方向で対応していただけると簡単で良いですが、影響範囲が大きそうなので無しの方向なのかなぁ
まとめ
Amazon Simple Storage Service (Amazon S3)
Simpleって難しいなと思いました- AWSサポートは対応が相変わらず素晴らしいのでちゃんと利用しましょう
- SigV2 がデフォルトなのは知らなかったです
- STSの期限についてはworkaroundでもいいので延長できる方法が欲しいです
- 権限がないのにURLが発行できるのもエラーで終わってもらえると良いきがします
- Boto3側のドキュメントにSigV4の話とかリンクでいいので追加されていると親切だと思いました
- Datadogはログインテグレーションして検索も簡単に！
- 他のAWSメトリクスも合わせて1箇所で状態が確認できるので便利でした
- 相変わらずドキュメントの読み込みが甘くて余計な手間が増えているなーと
- ドキュメントはちゃんと読みましょう！
以上になります。
Following is in English
AWS Lambda Go, Amazon Comprehend, Amazon Translate で作るSlack 翻訳Bot #aws #lambda #slack #golang #serverless
Go Support for AWS Lambda
もう発表されて結構経ちますが、AWS Lambdaでgolangが利用できるようになりました。
待ちに待ってたので嬉しいのですが、業務でgolangを使う機会もなく・・・
LTのネタに
そんな状態のところにLTどうですか？とのお声がけがあったので、これはネタにするしかない！
と、いろいろと作業はしてみたのですが・・・結局間に合わずw
以前に書いたblogを資料にするだけになってしまいました・・・
せっかくなので
とは言え、LTのネタにしようと作業自体は行っていたので時間のあるときにチマチマと作ってみてました。
とは言っても、機能自体は特に変更なく実装をAWS Lambda Goで行ったという感じです。
また、翻訳する部分をこれを書いている時点ではプレビューのAmazon Translateで行っています。当然ですが利用するにはプレビュー利用の申請が必要となります。
加えて Amazon Translate には翻訳元の言語自動判定を行える機能がこれを書いている時点ではないようです。これを補う手段としてAmazon Comprehendを利用しています。
結果としてAWSのサービスのみで完結することができたので、外部APIを使う際に気になる翻訳文字列を外部に送信するところは気にせずに済むようになりました。
AWS Lambda functions in Go
以下のリポジトリにAWSが用意してくれたサンプルコードがあるので、特に困らず利用できると思います。
個人的には楽しみに待ってたので非常に嬉しいです。 実際に使ってみると
- ビルド結果が1バイナリなので細かいことを気にしないで良い
- デプロイも1バイナリなので簡単
- AWS SAMとの相性も良さそう
- 個人的に好きな言語なので開発が楽しい
- イベントごとにハンドラーを用意すれば良さそう
- 普段使ってるgolangのライブラリが使えるのはやっぱり便利
kelseyhightower/envconfigはステキ
nlopes/slackを使ってSlackとのやりとりを簡単に
- Slack APIから
invalid_limitError が戻って来る - どうやらライブラリ側の問題っぽい
- せっかくだから Pull Request を出してみた
- このような場合でも
go getした手元のコードを修正するだけで動作させられるのは気軽で簡単で良いです
Amazon Translate
翻訳のためにAWSのサービスであるAmazon Translateを使ってみました。
- これを書いている時点ではプレビュー
- 利用には申請が必要
- プレビュー中なのもあってか対応言語が少なめ
- 基本の言語である英語と以下の6言語
- Arabic (ar)
- Chinese (Simplified) (zh)
- French (fr)
- German (de)
- Portuguese (pt)
- Spanish (es)
- 翻訳元の言語を自動判別する機能がない
- これもプレビュー中なのもあってなのか、翻訳元か翻訳先の言語のどちらか片方が英語でなければダメ
- SourceLanguageCode
- One of the supported language codes for the source text. If the TargetLanguageCode is not "en", the SourceLanguageCode must be "en".
- TargetLanguageCode
- One of the supported language codes for the target text. If the SourceLanguageCode is not "en", the TargetLanguageCode must be "en".
- 日本語への対応が待たれる
- 今後のアップデートに期待
Amazon Comprehend
言語自動判別のためにAWSのサービスであるAmazon Comprehendを使ってみました。
- 単純にSlackのメッセージを言語判定するAPIに渡しているだけ
- Comprehendにも対応言語がある
- 料金の設定で
100 文字を単位として計算されるため、今回のような使い方だと勿体無い感がある
自然言語処理 (NLP): Amazon Comprehend のエンティティ認識、感情分析、キーフレーズ抽出、言語検出のリクエストは、100 文字単位で計算され、各リクエストにつき 3 単位 (300 文字) が最低料金となります。
- 実際に今回の使い方だと思ったより料金がかかる印象
- Comprehend自体がもっと大量の文章を対象にしているためな気がする
- 複数の言語が混在している場合の自動判定結果
- 他のサービスでも同様だがこの辺の判定が思ってるものと違うと利用が難しい
- ComprehendはAWSマネジメントコンソールから簡単に試せるので触ってみるのが良い
AWS Serverless Application Model (AWS SAM)
デプロイのためにAWS Serverless Application Model (AWS SAM)を使ってみました。
- golangはビルド結果が1バイナリなので相性が良かった
- LambdaとAPI Gatewayしか設定してないのでテンプレートも簡単だった
- 複雑なことをしないなら手軽でいい感じ
- 環境変数を設定するのでオプションの設定が手軽にできると良い気がする
- せっかくのgolangなのにAWS CLIの利用が前提なのが若干残念
- 今後もLambda Goを使うなら一緒に使っていこうと思った
まとめ
- AWS Lambda を利用するならAWSのサービスで完結している方が楽
- 認証もIAMロールで行えるので色々気にする必要なし
- 外部のAPIにデータを送信することもないので、こちらも色々気にする必要なし
- SlackからのWebhookを受ける場合は、やっぱり非同期処理しないと複数回受信する（Lambdaのコールドスタートのため）
- この使い方だと粒度が小さすぎるのかComprehend の料金がちょっと気になる
- Translate 側で言語自動判別ができるようななれば、Comprehend は不要となるのでアップデートに期待したい
- 他の絵文字と合わせるためにSlackの国旗絵文字の文字列が変更になったっぽい
- 一部の絵文字国旗でflag−で始まらないものがある（:de: :jp: など）
- 絵文字文字列の変更を真面目にウォッチするのは大変そう
- ちゃんと使うならこの辺も考えないとだめそう
- あ、Lambda Goは楽しいのでおすすめです！
以上になります。
aws chaliceを使ってslackの翻訳botを作ってみた #aws #chalice #slack #bot
AWS Developers Meetup
先日開催された AWS Developers Meet Up という開発者向けのイベントに参加してきました。
AWS Developers Meet Up（2017 年 12 月 7 日開催）
https://pages.awscloud.com/DeveloperMeetup20171207.html
第1回目ということもあって、AWS SDKの紹介を交えつつ実際にAWS Cloud9を動かしてライブコーディングがあったりして、2回目以降の開催にも楽しみになる感じのイベントでした。
また、AWS AmplifyとAWS Mobile CLIを紹介するデモではちょっとしたトラブルもあったりしましたが、逆に参加者の皆さんがトラブル解消のためにすごい画面に集中して一体感が出るという一幕もw
個人的に楽しみに見に行ったのは Chalice(Python Serverless Microframework for AWS) のお話
すごい手軽に使えて、IAM ポリシーを自動生成してくれるのが素敵なのが気に入っているので、これまでも↓
な感じで使ってみています。
Slack Developer Meetup Tokyo
少し前に開催された Slack Developer Meetup Tokyo という開発者向けのイベントに参加してきました。
その中で紹介されていた、emojiリアクションでメッセージを翻訳するbotをつくるというのがちょー楽しそうだったんです。
www.slideshare.net
JavaScriptで作られたbotのコードは公開されていて、Herokuへのデプロイならデプロイボタンもあってちょー楽そう。
しかし、JavaScriptはこの前のServerlessconf Tokyo 2017 Workshopのコードを触った時にだいぶ苦労したので避けたい気持ちがw
ということで
slack 翻訳botも楽しそうだし久しぶりに chalice も触りたいということで、chalice を使って公開されているslackapi/reacjilatorと同じように動くものを作ってみました。
基本的には公開されている slackapi/reacjilatorをchalice利用して実装し直しただけになります。
変更点はGoogle翻訳は無料枠がないので、次の資料を参考にして無料の翻訳APIを利用するようにしてあります。
王道は Microsoft Translator API なんですが利用したことがあるのと、無料アカウントでも取得するのに多少手間があるので、使ったことのないYandex APIを使ってみました。
マイクロソフトアカウントの登録方法なんかは以前書いたAzureの記事をご覧ください。
コードは量も多くないので他の翻訳APIに変更するのも大変ではないと思います。 また、当然ですが翻訳APIを利用するということはAPIに文字列を送信するということなので、十分理解した上で翻訳APIの利用先と利用を決めてください。
Yandex API
無料で使えて登録も簡単な翻訳APIを調べていて初めて知りました・・・ ロシアでGoogleみたいなことやってるんですねー
翻訳APIの利用登録は非常に簡単で、GoogleアカウントがあればログインしてAPIキーを取得するだけで利用開始できます。
ドキュメントもAPIそのものも非常にシンプルなので、特に困るところはないかと思います。動作を確認するとかそういう用途では手軽で嬉しいですね。
実際に利用する際にはAPIに文字列が送信されるということを考えてお使いください。
準備
上記の翻訳API（yandex）の準備とSlackの公開されているスライドを参考に準備を行ったら、実行に必要なAPIキーなどの情報を書き足してchalice deployを実行すれば、API GatewayのエンドポイントとLambdaを利用できるようになります。
翻訳APIを他のものに切り替える場合は、APIを呼び出す部分を個別に実装すれば切り替えできると思います。
国旗絵文字の文字列から翻訳APIに渡すための変換は↓を参考にしてください。
Language Support | Translation API | Google Cloud Platform
https://cloud.google.com/translate/docs/languages?hl=en
Translator Language Codes
https://msdn.microsoft.com/en-us/library/hh456380.aspx
AWS Lambda はAPI Gatewayから呼び出されるものと、Amazon SNSから呼び出されるものがあります。
これはSlackのAPIがリクエストを受けてから、一定時間内にレスポンスを返さないとリクエストを再送する仕組みがあり、Lambdaのコールドスタート時に複数のリクエストが送信される可能性を低くするためです。
chaliceではAWS CloudFormationをサポートしているので、AWS CLIと組み合わせることでAmazon SNSなどの他リソースを同時に構築することができます。
AWS CloudFormation Support — Python Serverless Microframework for AWS 1.1.0 documentation
http://chalice.readthedocs.io/en/latest/topics/cfn.html
使ってみる
国旗絵文字をリアクションすると、その国の言葉に翻訳されます。 翻訳API側が対応してないとbotからの返答がないようにしてあります。
The message is translated in :flag-ca: (ja-en)
のように、翻訳元の言語と翻訳先の言語がわかるようにはしてあります。
上記の例だとja（日本語）からen（英語）となります。
翻訳APIからの戻り値ですが、基本的にはISO 639-1のコードと同等のようです。
List of ISO 639-2 codes - Wikipedia
https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
まとめ
- 勉強会やイベントに行くと知らないことや、やってみたいことのきっかけになるのはやっぱりいいな
- 入出力にSlackを使うのは手軽だし分かりやすい
- 今回みたいなBotだと全チャンネルではなく、特定のチャンネルにデプロイしたい。
- 外部APIに文字列を送るとなると予期せず動作するのは好ましくない気がする。
- 今回はプログラム側で許可するチャンネル一覧を持って対処した。
- slack側で設定できる場所があれば教えてほしい
- チャンネルリストもディスプレイ文字列ではだめで、チャンネルIDが必要だった
- チャンネルIDの取得の仕方については以下を参考にした
- chalice はやっぱり手軽でこういうちょっとした用途だと便利
- SNSを使って非同期にしてあるが単純にLambdaのinvokeでもよかったかもしれない
- その場合chalice側でLambda関数名が付与されるので、そのあたりをもうちょっとスマートにしてもらえるといいなーと
- 時間をみつけてchaliceのソースを見てみようと思った
- Lambdaなので外部APIとのやりとりもX−Rayを使えば可視化もできて便利
- 今回は利用してないが、他の翻訳APIも複数利用する場合とかあればX−Rayも使ってみたい
- やっぱりわくわくしながら作るのは楽しくて良いです
- やはり楽しいは正義ですね
以上になります。
SORACOM UG Tokyo #8 開催レポート #soracom #soracomug #iot
★この記事は「SORACOM Advent Calendar 2017」の 12/15 日分のエントリーになります
何を書くか・・・
IoT通信プラットフォーム SORACOM のAdvent Calendar 2017 です。 SORACOM を使った技術ネタでしたらなんでもOKです！
とあるので、本当は技術ネタの方が良いのでしょうが・・・せっかくSORACOM UG Tokyo #8が開催された当日なので、それをネタにゆるーく書いていこうと思います。
技術ネタと話題のWio LTE話は、これまでのSORACOM Advent Calendar 2017で色々と書かれているのでそちらを見てくださいw
久しぶりの開催
前回の第7回目の開催が2017/07/05(水)でSORACOM Conference 2017 “Discovery”のナイトイベントとして開催したので、半年近く経っての開催となりました。
久しぶりの開催ということで、前回の開催からのニュースリリースを確認して個人的に気になるものを見てみると
まず、みんなびっくりしたのはKDDIグループとなったことでしょうか？
あとは、チップ型SIMやeSIMの提供が開始との話
Wio LTEの機器販売のとWio LTE自体が気になりました
もちろんこの他にもいろいろとリリースされてますので、あくまでも個人的に気になったという話です。
当日レポート
では、本題のSORACOM UG Tokyo #8 / eSIMとre:InventとちょっとだけWio LTEの当日の様子を簡単ですがご紹介したいと思います。
当日の雰囲気は次のまとめをご覧ください。
会場
今回の会場はウイングアーク１ｓｔ株式会社 さんのセミナールームをお借りしました。
素晴らしいセミナールムで開催できて大変助かりました。ありがとうございました。
帳票とBI | ウイングアーク１ｓｔ
http://www.wingarc.com/
eSIM オーバービュー
1つ目のお話はSORACOM片山さんによるeSIMのお話。
SIM自体の基本的な話から、既存のSIMとeSIMがどう違うのか？
これからのSIMはどうなっていくのか？といった内容のお話でした。
資料と話の内容が非常に丁寧で、ぜんぜん詳しくない私でも理解できるような非常に素敵な発表でした。
資料は公開されましたが、是非SORACOMさんが開催しているオンラインセミナーSORACOM Bootcampにて再演していただけるといいなーと。
www.slideshare.net
あ、あとで #ソラコムサンタ ハッシュタグつけてTwitterにつぶやいておこうw
今年も#ソラコムサンタ開催中みたいなので、クリスマスが楽しみですねー
twitter.com今年もやります、 #ソラコムサンタ ！ #soracom に期待したいこんなサービスやこんな機能、商品やイベントなんでもご要望がある方は #ソラコムサンタ ハッシュタグでつぶやいてください😄2016年のサンタはこんな様子でした＾＾https://t.co/EiCVPgd6NG pic.twitter.com/az0eiN8osY
— ソラコム公式 (@SORACOM_PR) 2017年11月22日
Wio LTE の紹介
2つ目のお話はSORACOM松下さんによるWio LTEのお話。
WioとはWireless Input Output だそうなので、カタカナで表記するならワイオとなるそうな。
Wio LTE Cat.1 - Seeed Wiki
http://wiki.seeed.cc/Wio_LTE_Cat.1/
Wio Tracker (Wireless Input Output) is an open source gateway which enable faster IoT GPS solutions.
ラズパイやArduinoでGroveセンサーを使う場合に、ブレッドボードのさし間違えでセンサーを壊してしまったことがある人もいるかと思います。
Wio LTEでは直接コネクターにGroveセンサーをさせるので
上記のような悲しいことも起こらずw かつ手軽にセンサーを利用できるそうです。
また当然LTEモジュールも搭載しているので、SIMを刺せば通信も利用可能と。
SORACOMさんのサイトでは、Wio LTE単体からGroveセンサーをセットにしたものまで販売しているそうです。購入して年末年始にIoTを体験するのには手軽でいい感じかもですねー
最後に松下さんがWio LTEを使った実機デモを行い、クラウド側とデバイス側が双方向で通信している様子がわかる楽しいデモでした。
Wio LTEのハンズオンなんかは今後も予定されているようなので
そのハンズオン会場で同じデモが見られるかもしれないですねー
ソラコムが見てきたAWS re:invent 2017 話
3つ目のお話は再び登場のSORACOM片山さんによるAWS re:Invent 2017のお話。
SORACOMさんか参加されたのは片山さん１人とのこと。なので、自分が見てきた範囲でセッションの内容紹介をするとのことでスタートしました。
今年のre:InventではIoT関連のサービスが多数発表され、AWSがIoTに積極的に取り組む姿勢が感じられて嬉しかったとのこと。 また、会場では色々なIoTサービスやプロダクトの展示もあったそうです。
会場のハンズオンでAWS DeepLensを触ったお話もありました。
スライド中では画像認識している若干ドヤ顏気味の片山さんの写真も紹介されていましたw
SORACOMさんにはグローバル向けのSIMもあるので、早速現地でAWS DeepLensにUSBドングルをさして通信可能か試した話もされてました。
この中で話してのは画像？映像データはクラウドまで上がらずにどうやら機器内で判定がされ、結果のJSONだけが送信されてるとのこと。 これであれば、大容量の回線でなくても利用できるしかつ、画像や映像という色々な情報が入っているものの取り扱いを気にしなくてよくなるので、大変ありがたい感じですねー
AWS DeepLens を開けてみたそうで
カメラはUSBで刺さってるだけだったそうですw
発表後に実物のAWS DeepLensを開けていただけたので見てみましたが、確かに刺さってるだけっぽかったですw
日本ではまだ発売されませんが、他のデバイスでも代用可能そうなのでソフトの方を他のデバイスにもデプロイできるようになると楽しそうですねー
www.slideshare.net
ソラコム ビンゴ
最後は再び登場のSORACOM松下さんによるソラコム ビンゴ
去年の同じ頃に使う予定で作ったビンゴアプリが１年越しでやっと活躍だそうですw
しかし、１年はWebの世界では長かったようで使っているJSライブラリが大幅更新されていた＆SORACOMのアイコンセットがだいぶ増えたので、結構修正しないと動かなかったとかw
コード自体はGitHubで公開されているとのことなので、この時期にビンゴをお考えの方いかがでしょうか？
ビンゴの方は順調に進んでいきましたが、アイコンセットの数が多いからなのか・・・なかなかビンゴになる人が出ないという展開にw
ビンゴの景品はSORACOMさん、seeedさん、ウィングアークさんから提供していただきましたーありがとうございました。
Groveセンサーってすごい便利で使ったこともあったのに、seeedさんの製品だとは全然知らなかったです・・・
Grove System - Seeed Wiki
http://wiki.seeed.cc/Grove_System/
Seeed Studio Bazaar, Boost ideas, Extend the Reach
https://www.seeedstudio.com/
最後は
SORACOM UG 恒例の集合写真で締めでした。 いつも写真撮影ありがとうございます！！
まとめ
- 今回はSORACOMさんから色々話が聞けて勉強になった
- 知らないことが知れるのは楽しい
- たまにはこう言った感じで開催するのもいいなぁーと感じた
- Javaはすごい（らしい）
- 資料の公開は楽しみにしてますので、是非よろしくお願いします！
- あと、#ソラコムサンタ 期待していますw
- アドベントカレンダーは間に合わなくてゴメンナサイ。
- 次回も楽しく開催したいのでよろしくお願いします！
明日も楽しみ「SORACOM Advent Calendar 2017」
12/25 の最終日までいろいろなネタが投稿される 「SORACOM Advent Calendar 2017」 明日以降の投稿も楽しみです！
ユーザーグループの開催レポートなのでゆるーく書いてしまいましたが、少しでもSORACOM UGに興味を持っていただければ嬉しいです。
今後のSORACOM UG開催についての情報は、募集サイトやSORACOMさんの公式サイト、SNS等で発信されていますので気になった方は是非参加してみてください。
以上になります。
Cloud Automator について #cloudautomator #swx
★この記事は「Cloud Automator Advent Calendar 2017」の 12/1 日分のエントリーになります
何を書くか・・・
AWSの運用を自動化する Cloud Automator の知見・情報など、Cloud Automatorに関することであれば何でもOKです🙆
とあるので、なんでもOKらしいので初日＆AWSな方々はre:Invent 2017 でラスベガスだと思うので、ゆるーく書いていこうと思います。
技術的なこととか、深い話は今後のみなさんがきっと書いてくれるに違いないと信じておりますw
いつから
さて、Cloud Automatorはいつから提供が開始されたのか？調べてみると、次のニュースリリースが残っているのを発見しました。
これによると
となっており、今から約3年半ぐらい前からサービスとして提供されていたことがわかります。
200社を超えるAWS導入実績を持つ当社が、実環境で経験してきた様々な運用業務を「アクション」として実装しています。
となっていますが
を確認すると、現在は
600社4,000プロジェクト以上のAWS移行実績！
と記載があることをみても、時間の経過とAWSが利用されるスピードについて実感できるかと思います。
全然関係はないんですが、このニュースリリースなんでこんなにCloud Automator のロゴが大きいのかw Cloud Automatorのロゴを伝えたかったのか！？それとも何か秘密があるのか！？
今後の「Cloud Automator Advent Calendar 2017」で明らかになるのか楽しみですw
アップデート
次に大きな機能追加があったのは、「構成レビュー」自動化機能の追加でしょうか？サービス提供時と同じく調べてみると、次のニュースリリースが残っているのを発見しました。
これによると
「構成レビュー」自動化機能の提供を2016年6月1日（水）より開始いたします。
となっており、今から約1年半ぐらい前からサービスとして提供されていたことがわかります。意外と最近ですねw
どうしたら
Cloud Automator を使い始めるのはどうしたらいいのか？
公式サイトからサインアップしてもらえれば、構成レビュー⾃動化機能は対象外となりますが1ヵ⽉の無料トライアルを行えます。
もしくは、pieCeというサービスに加入いただいている場合には、すぐにすべての機能をお使いいただけます。
今後は
Cloud Automator の今後はどうなるの？という方は次のロードマップページをご覧ください。
こんな機能が欲しい！こんなことをしたい！との要望は
Cloud Automatorサポートページ
http://feedback.cloudautomator.com/
のサポートページで受け付けておりますので、フィードバックをお願いいたします。
また、単純にどんなことができるかドキュメントを確認したい場合は
Cloud Automator – 株式会社サーバーワークス サポートページ
https://support.serverworks.co.jp/hc/ja/categories/115001305127-Cloud-Automator
のマニュアルページをご確認ください。
明日も楽しみ「Cloud Automator Advent Calendar 2017」
12/25 の最終日まで今日からスタートの 「Cloud Automator Advent Calendar 2017」 明日以降の投稿も楽しみです！
初日なのでゆるーく書いてますが、これからはもっと中の詳しい話や便利な使い方なんかが出てくるのを期待ですね！
あと、埋まってないところがあるようなので我こそは！という方の参戦もお待ちしております！
宣伝
サーバーワークスでは積極採用中です。もちろんCloud Automatorの開発チームも採用中ですので、Cloud Automatorに興味がある方是非お声がけください！
以上になります。
#Serverlessconf Tokyo 2017 でやった Workshop に機能を追加してみた #serverless #ACG
今年の
今年も大盛況の開催だった Serverlessconf Tokyo 2017 の1日目に開催された pre-conference Workshop に参加しました。
幾つかの Workshop から選択できたのですが、私が選択したのは
Build your own serverless video sharing website with Lambda, API Gateway and Firebase
という、Youtubeクローンのようなものを作ってみるというWorkshopでした。
内容は上記のgithubの内容を見てもらえればわかるのですが、ドキュメントが非常によくできているので指示通りに進めて行くとサクサク進んでいきます。
さらに日本のServerlessconf Tokyo 2017のスタッフの方が、日本語訳したものまで用意してくれる素敵な対応。
実際に
当日は @sbarski の丁寧な説明を受けつつ、Workshopを進めて行く感じでした。
また、サポート役として @ijin と @toricls と @horike37 というクラウド界隈で有名な方々がなぜか参加しているという素敵な状況でした。
Workshop自体のできがよく、さらにサポートも充実しているので予想よりも全体的な進捗がよく終わってしまう人がかなりいました。
そこで、終わった人はWorkshopで完成したものに新規で機能を追加してPull Requestを送ってみてはどうか？という無茶ぶりがw
公開されているWorkshopが需実していくのはいいことなので、私も何かしよう！と思ったのですが、LambdaがNode.jsで書かれているというね・・・
結局
当日は不慣れなJavaScriptに苦戦して何も追加できずでしたので、せっかくだから空いた時間を使ってチマチマと機能を作ってみました。
Lesson 6として追加したのは、Webブラウザ上から動画ファイルを削除できる機能の追加です。
普通すぎる機能なんですが、アップロードがWebブラザ上からできるところでWorkshopが終了になっているので、まーあってもいいかなぁーと。
ただ、このWorkshop自体が @sbarski の著書 Serverless Architectures on AWS With examples using AWS Lambda をもとにしているらしいので、著書の中には既にある可能性が・・・
Manning | Serverless Architectures on AWS
https://www.manning.com/books/serverless-architectures-on-aws
こちらの著書も日本語版が出れば読みながら進めるのは良さそうですよねー日本語版に期待。
Pull Request
著書の中で既存の可能性が高いですが、せっかく作ったのでPull Requestを送ってみました。
他にも心配な点がいくつか・・・
- 手順書の英語がわからん。
- 日本語版を書いてそれをGoogle翻訳しただけw
- フロントエンド側のJavaScriptがわからん。
- 動くようには書いたけどスマートじゃない気がするけど力尽きたw
- Pull Request の英語がわからん。
- 空き時間でのんびり作ってたらすごい時間かかった
- 絶賛開催中の
AWS re:Invent 2017でWorkshopに使えそうなサービスが出そう。というか出てるきがするw
- 絶賛開催中の
ちなみに @sbarski はAWS re:Invent 2017 で登壇したみたいですよ！
that's awesome!
AWS re:Invent 2017
https://www.portal.reinvent.awsevents.com/connect/search.ww
私自身は今年も残念ながら参加できなかったので・・・・
上記のセッション検索サイトで @sbarski の名前を検索すると
DVC301 - Evolution of Serverless Architectures through the Lens of Community
https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=17198
と
SRV401 - Become a Serverless Black Belt: Optimizing Your Serverless Applications
https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=14199
の2つのセッションがヒットしますねー
DVC301 の方は残念ながら動画が非公開っぽいですねー
SRV401 の方は動画が公開されていて見ることができるようです！
この他のAWS re:Invent 2017 動画は順次公開されているようなので、私と同じく現地参加できなかった人にはありがたいですよねー
来年は参加したいなぁー去年もそんなこと言ってましたがw
まとめ
- 時間はかかったけどのんびり進められてなかなか楽しかった
- やっぱりJavaScriptはよくわからなくて難しい
- Workshopがシンプルなのでコード類もシンプルで素敵
- AWSを知っている人なら、本当にサクサク進められるのでオススメ
- サクサク進むけど出来上がるものは動きもあって達成感もある
- 良い機会を得られたのが良かった
- 他の参加者のかたも是非！新機能を！
Serverlessconf Tokyo 2017スタッフの皆さんありがとうございましたー
以上になります。
