SORACOM ArcとSORACOM Napter でDockerコンテナと通信してみる #SORACOM #docker #IoT

目次

前提

2021年に発表された SORACOM Arc(以下、Arc) を利用すると、SORACOM Air を利用した通信回線を利用していなくてもWi-Fi 経由でもSORACOMプラットフォームに接続できるようになります。

blog.soracom.com

users.soracom.io

これは、SORACOMプラットフォームを利用して開発したことある人はわかると思うのですが、手軽にSORACOMプラットフォームにアクセスできるのはめちゃくちゃありがたいです。

さらに Arc はバーチャル SIM(以下、vSIM) として扱われるため、SORACOM Napter(以下、Napter) を利用してリモートアクセスを行えます。

users.soracom.io

users.soracom.io

例えば、SORACOMプラットフォームとしか通信できない環境でもリモートアクセスできます。 安定のクラスメソッドさんのBlogでも紹介されてますね。

dev.classmethod.jp

というわけで、Arc+Napterはいろいろ試してみたいので、今回はArcをDockerコンテナ側に設定してNapterでアクセスしてみたいと思います。

準備

Docker の準備とSORACOM側の準備が必要です。普段使っている人は読み飛ばしてください。

Docker

Docker コンテナ側はubuntu 20.04 (Tag: focal)を利用しました。

hub.docker.com

インストールしたのは、もちろん必須の WireGuard

www.wireguard.com

www.wireguard.com

あと、接続確認にPythonを利用したので、Pythonが動作する環境を設定しています。 ホスト側はMacで、Rancher DesktopをインストールしてDockerを実行しています。

rancherdesktop.io

SORACOM Arc

SORACOMのサービスはドキュメントがとてもよく書かれているので、ドキュメントに沿って設定を行います

users.soracom.io

vSIM 発行時にWireGuardの設定に必要な情報が確認できますので、メモするなどしておいてください。

試してみる

Docker コンテナを起動して、vSiM発行時にメモした情報をWireGuardの設定ファイル /etc/wireguard/wg0.conf に記載します。 こちらもArc のドキュメントに記載があるので内容を確認してください。

users.soracom.io

あとは、Docker コンテナ側でWireGuardを起動して、SORACOMプラットフォームへの接続を確認します。

$ docker ps
CONTAINER ID   IMAGE        COMMAND                  CREATED              STATUS              PORTS     NAMES
c4c4884529f0   dev-garden   "/bin/sh -c 'echo Co…"   About a minute ago   Up About a minute             dev-garden

$ wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.248.37.231/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 100.127.0.0/16 dev wg0
[#] ip -4 route add 10.128.0.0/9 dev wg0

$ ping pong.soracom.io
PING pong.soracom.io (100.127.100.127) 56(84) bytes of data.
64 bytes from 100.127.100.127 (100.127.100.127): icmp_seq=1 ttl=64 time=10.9 ms
64 bytes from 100.127.100.127 (100.127.100.127): icmp_seq=2 ttl=64 time=11.5 ms
64 bytes from 100.127.100.127 (100.127.100.127): icmp_seq=3 ttl=64 time=10.9 ms
^Z
[1]+  Stopped                 ping pong.soracom.io

今回は接続確認するためにいろいろ設定するのが面倒だったので Dockerコンテナ側で、HTTPサーバーを立ち上げてNapterはこのHTTPサーバにアクセスしてみることにします。 HTTPサーバーも接続確認できるだけでいいので、Pythonのいつものやつで済ませます。

$ python -m http.server 8088
Serving HTTP on 0.0.0.0 port 8088 (http://0.0.0.0:8088/) ...
127.0.0.1 - - [18/Jun/2022 08:07:53] "GET / HTTP/1.1" 200 -

SORACOM Napter

これでローカルからDockerコンテナへの接続が確認できたので、続いてSORACOMユーザーコンソールからNapterの設定を行います。

users.soracom.io

バイスのポートはこのHTTPサーバーのポートを指定してください。今回は8088を使用しました。

払い出されたURLにブラウザでアクセスして、ローカルからアクセスしたものと同じ画面が見えれば成功です。 Dockerコンテナ側のターミナルにもアクセスログが出ているのを確認できるかと思います。

python -m http.server 8088
Serving HTTP on 0.0.0.0 port 8088 (http://0.0.0.0:8088/) ...
127.0.0.1 - - [18/Jun/2022 08:07:53] "GET / HTTP/1.1" 200 -
100.127.10.17 - - [18/Jun/2022 08:08:06] "GET / HTTP/1.1" 200 -
100.127.10.17 - - [18/Jun/2022 08:08:06] code 404, message File not found
100.127.10.17 - - [18/Jun/2022 08:08:06] "GET /favicon.ico HTTP/1.1" 404 -
100.127.10.17 - - [18/Jun/2022 08:08:35] "GET /Dockerfile HTTP/1.1" 200 -
100.127.10.17 - - [18/Jun/2022 08:08:41] "GET /memo.json HTTP/1.1" 200 -
100.127.10.17 - - [18/Jun/2022 08:08:58] "GET /README.md HTTP/1.1" 200 -
^Z
[2]+  Stopped                 python -m http.server 8088

Napter で接続できない時

Napterで接続できない時は、まずはNapter側の設定を再確認してください。 デバイス側ポートアクセス元IPアドレスレンジ など意図したものかどうか。

また、有償となりますが Napter 監査ログ を利用すると、接続の詳細を確認できます。

users.soracom.io

今回ちょっとハマったのが

  • Dockerコンテナ側からSORACOMへのPingは普通に通る
  • SORACOMユーザーコンソールからNapterを設定して、アクセスするとタイムアウトしてアクセスできない
  • なぜかDockerコンテナ側でSORACOMへPingしている間は、Napterでのアクセスも通る
  • 調べてみたらWireGuardの設定が足りなさそう

    www.wireguard.com

  • NAT越しの通信の場合は PersistentKeepalive の設定をしないとダメらしい

  • Arc のドキュメントにも記載がある

    users.soracom.io

  • 毎回書いている気がするが、ドキュメント特に公式のものをよく読んだ方が解決までが早いと思った

  • 同様の症状で悩んでる場合はドキュメントを確認してPersistentKeepalive の設定を追加してみてください

まとめ

  • SORACOM ArcとSORACOM Napter を利用してDockerコンテナにアクセスできた
  • ユースケースを考えると、Dockerで開発している画面を一時的に外部の人に見せるとかでワンチャン!
  • ngrok ほど自由はないけど時間制限やCIDRでの制限はかけられるので使えるかも? ngrok.com
  • Dockerコンテナ側は、WireGuardの設定と起動だけなので /etc/wireguard/wg0.conf をコンテナ作成するタイミングでコピーしても良さそう
  • ArcとNapterの組み合わせはいろいろ試せそうなので、今後も何かあれば試して書き留めようと思った
  • Wi-Fiで普通にSORACOMプラットフォームにアクセスできるのは本当に便利で助かる
  • SORACOMプラットフォームは従量課金なので、利用する前に料金の確認を忘れずに

以上になります。

ATOM Cam 2 を Amazon Kinesis Video Streams に繋げてみた #ATOMCam #aws

目次

前提

uchimanajet7.hatenablog.com

前回の最後でATOM Cam 2(以下、AC2)がRTSPに対応してるのがわかりました。 今回はこのRTSPサーバーで配信されている映像を、Amazon Kinesis Video Streams(以下、KVS)に流してみようと思います。

とは言っても、AC2-----> RTSPクライアント -----> KVS という感じで、途中に中継の役割を持ってもらうだけなんですけど。

RTSPとは?

そもそもRTSPとは?私自身も詳しくは知らなかったので調べてみました。

ja.wikipedia.org

Real Time Streaming Protocol(リアルタイム・ストリーミング・プロトコル、略称:RTSP)は IETF において標準化されたリアルタイム性のあるデータの配布 (ストリーミング) を制御するためのプロトコルである。ストリーミングデータ自体の配信を行なうためのプロトコルではない。1998年4月にその最初の版がRFC 2326として標準化されたが、様々な問題点があることが指摘され、改訂が続けられている。2016年にReal-Time Streaming Protocolバージョン2.0がRFC 7826として標準化された。

tex2e.github.io

実態としては rtsp:// で始まるURIで記載され、HTTPと同じようにクライアント側からのリクエストにサーバー側がレスポンスを返すという形で通信されているようです。

実際にAC2のRTSPサーバーの動作確認をしてみると

のような形でリアルタイムの映像を確認することができます。

動作確認ではFFmpeg をクライアントとして利用しています

ffmpeg.org

RTSPクライアントならなんでもOKなはずです。例えばVLC media playerでも再生可能でした

www.videolan.org

FFmpeg のインストールはHomebrewで行いましたが、公式にはMac用のStatic buildも用意されているようなので環境に合わせて利用してください。

trac.ffmpeg.org

中継機

中継機はなんでも良いのですが、AC2とセットで稼働してないとダメなので、PCで中継するよりは中継専用で動いているほうが都合がよさそう。

ということで、これも手元にあった Raspberry Pi 3 B+(以下、ラズパイ) を利用してみることにした

$ uname -a
Linux raspi 5.15.38-v7+ #1552 SMP Mon May 9 17:06:58 BST 2022 armv7l GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 11 (bullseye)
Release:    11
Codename:   bullseye

今現在、ラズパイを手に入れようとすると価格が高騰しているようなので、動作確認するだけなら手持ちの他の機器かPCを使うことも検討してください

Amazon Kinesis Video Streams

KVSに接続するにはラズパイをプロデューサーとして動作させれば良さそう。 そして、このプロデューサーがアップロードするメディアを、RTSPクライアントで受信した映像にすれば希望の形になりそう

aws.amazon.com

dev.classmethod.jp

www.youtube.com

いろいろ調べてみると、公式の情報がすごい充実していた。さすがAWSGitHubリポジトリにもいろいろあって、動作確認するぐらいの話なら作ったりしなくて良さそうな雰囲気

github.com

Producer Libraries なるSDKがあるらしく、これを利用するだけで良さそう

docs.aws.amazon.com

設定

実際にラズパイにKVSのProducerをセットアップしてみる。今回利用するのは以下。

github.com

Google先生に聞いてみると、いろいろな記事が出てきましたが、READMEに記載の通り進めれば問題なくセットアップできました。

github.com

cmake が入ってないとか、ビルドに必要なツール系が不足していることがあるので、その場合は以下を確認して追加でインストールしました。

github.com

GStreamer のplugin として動作させる必要があるみたいなのでcmake のオプションは以下で実行しました。

cmake -DBUILD_GSTREAMER_PLUGIN=TRUE ..

github.com

gstreamer.freedesktop.org

ラズパイだとcmakeは終了までにそこそこ時間がかかりました。気長に待ちましょう。 そしてcmakeが終了したら make の実行を忘れずに。。。。

github.com

実行

ビルドが終了したら、ドキュメント記載の通りビルドされたライブラリにパスを通して、動作を確認します。

github.com

To load this plugin set the following environment variables. This should be run from the root of the repo, NOT the build directory.

コマンドをコピペで試す場合には、カレントディレクトリの位置だけ注意が必要って感じですね。 ここまで来れば、あとは実際に映像の転送を開始するだけです。

gst-launch-1.0 -v rtspsrc location="rtsp://YourAC2RtspUrl" short-header=TRUE ! rtph264depay ! video/x-h264, format=avc,alignment=au ! h264parse ! kvssink stream-name="YourStreamName"

docs.aws.amazon.com

当然ながら、実行にはAWSへの権限と認証が必要です。 公式ドキュメントだと実行時引数に必要な access-key/ secret-key/ aws-region を渡しています。

今回はビルドしたライブラリにパスを通すタイミングでAWSの接続に必要な情報を環境変数に設定しています。

export AWS_DEFAULT_REGION=ap-northeast-1
export AWS_ACCESS_KEY_ID=YourAccessKey
export AWS_SECRET_ACCESS_KEY=YourSecretKey

映像の確認

最後にAC2の映像を確認します。KVSのWebコンソールに簡易的なプレーヤーがあるので、これを利用すれば映像が確認できます。 今回試した私の環境だと、遅延はおおよそ10秒以内という感じでした。 ネットワーク環境や転送している機器の性能にも依存しそうなのであくまでも目安で。

この簡易的なプレーヤーだとAWSにログインしないと確認できない状態です もう少しゆるく共有できると良さそうですが、作り込むところまでは。。。

そこはさすがのAWSサービスと言ったところで、探してみると以下がありました。

github.com

このWeb Viewerで利用する読み取り専用のAWS認証情報を作成し、ストリーム名ををはじめとした必要な項目を入力すればライブ映像を確認することができました。とても便利。

まとめ

  • ATOM Cam 2 の映像を Amazon Kinesis Video Streams に流し込んでみた
  • 中継機が必要となるが、ドキュメント通りに設定すれば簡単に始められる
  • Dockerイメージが用意されているようなので、こっちのほうがお手軽そう

docs.aws.amazon.com

  • AWS側に映像データがアップロードできるので、クラウド側のアセットが利用できるようになる
  • AC2単体でクラウド側への映像アップロードができると幸せになれそう
  • クラウドまで映像が上がってるので ソラカメ のサービス拡張に期待

soracom.jp

  • 長期安定運用を考えると中継機の部分は考慮が必要そう
  • KVS周辺のドキュメンとや、サンプルコードが充実していた
  • 公式ドキュメントやサンプルなど非常に助かった。ドキュメント大事。
  • 試すのは簡単だったので、AC2 とラズパイその他中継用の機器を持て余している人がいれば是非
  • Atom Cam Swing にはRTSPがなかったので、RTSPが目的の場合はAC2が必要かも

ATOM Cam Swingwww.atomtech.co.jp

  • あと、まさに同じことをしているAWS公式の動画があったので見ながらハンズオンするのが良さそう

www.youtube.com

以上になります。


Following is in English

medium.com

ATOM Cam 2 をオンラインミーティングの手元カメラとして利用する #ATOMCam

目次

前提

すっかり放置してましたがまたゆるーくメモ書いていこうかと。まずは小ネタから 手元にATOM Cam 2(以下、AC2)があるのですが本来の用途で使うところがないという。。。撮れるの木々の揺れだけだからなぁ

ATOM Cam 2www.atomtech.co.jp

小型 / 安価で画質も必要十分なので何かに利用できないかなーと そこで、オンラインミーティングでバーチャル背景を利用していると、人以外をカメラで撮したい時に背景に同化して見えなくなることありますよね? あれ地味に困る感じするので、AC2を物撮りようにしてオンラインミーティングで利用してみたいと思います

本来の用途

本来の用途でもワンチャン!と思ってる人がいるのであれば、ソラコム社からAC2を使ったサービスが発表されていましたので是非チェックを

soracom.com

AC2にもとも付随している、モーション検知録画だけではなく常時録画を行ってクラウド側で保存してくれるといったサービスになっているようです

soracom.jp

Q. 手元に ATOM Cam 2 があるのですが、ライセンスだけ購入して利用することはできますか?
A. 現時点では、ソラコムから購入いただいた ATOM Cam 2 のみサポートしております。

残念ながら、既存AC2はこのサービスは利用できないと記載があるので、このクラウド常時録画サービスを利用する場合には上記のソラコム版を購入する必要があるようです

我が家ではモーション検知でも常時録画でも撮るのは木々の揺れなのでw

設定

難しい設定とか、アプリを複数入れて連携するとかしません。 結論書くと、Android studio をインストールして、Android エミュレーターにてAC2をセットアップするだけです

これだけでPC画面上にエミュレータの画面がある状態となるので、オンラインミーティングの際に エミュレータの画面を画面共有することで、人物を撮しているカメラと別のカメラとして利用できるという感じになります

Android studio のダウンロードとかは以下から行えます

developer.android.com

公式のドキュメントが充実しているのでインストールやそのほか設定も ドキュメントに沿って進めていけば特に問題ないかと思います

developer.android.com

エミュレーターについては、Google Play ストア が初めからインストールされている エミュレーターを選択して実行します

developer.android.com

AC2のアプリは難しいことせずにPlay ストアから最新のアプリをダンロードして利用します こんな感じでエミュレーター画面が表示されてAC2のライブ映像が確認できれば終了です

まとめ

  • AC2を持っていたのでオンラインミーティングで物撮りカメラとして使えるようにしてみた
  • 特に手間はなく、Android エミュレーターでAC2アプリを普通に利用するだけ
  • カメラの特性上、接写はピントが合わない時があるが、他は画質も必要十分
  • Webカメラを追加で付けるよりは手軽にできたので良かった
  • Android エミュレーターが重いのか、使ってるPCが非力なのか若干動作が重いのが残念
  • AC2のアプリをちゃんと見たら RTSP プロトコル でカメラが映像ストリーミングしている模様

  • カメラ側がサーバとして配信してるようなので、これを利用したほうが楽そう予感がする
  • AC2を持て余している人で、オンラインミーティングで物撮りする様な人がいれば是非

以上になります。

AWS CDK を使って ランダム選択できる Slack Bot を作ってみた #aws #slack #cdk

f:id:uchimanajet7:20200928112946p:plain

目次

前提

9月に入って時間が取れたので AWS Cloud Development Kit (AWS CDK) を触ってみることにしました。というのも、TypeScriptでの実装例は結構な数見かけるのですがPythonの実装例は探し方が悪いのかあまり見当たらず・・・だったら自分で少し触ってみようかと。

aws.amazon.com

github.com

AWS CDKを利用するシーンを考えると、構築や運用に深く関わる可能性が高いため AWS CDKのroadmapが公開されており、今後も継続して更新が続けられていく様子が確認できるところが非常に素晴らしいです。

aws.amazon.com

github.com

というわけで、触れるタイミングで使ってみたので簡単にですがまとめてみました。

Slack bot を作ることにする

CDKを使ってみると言っても、何か動くもので継続的に使ってアップデートできるものが題材にあるといい感じなので、普段利用しているSlackのbotを作ることにしました。

作るのであれば楽しく作って、実際に使えるものが良いので Amazon API GatewayAWS Lambda の定番構成で、AWS SDK for Go でLambda関数を作成しました。

aws.amazon.com

aws.amazon.com

aws.amazon.com

Slackへのメッセージ送信は次のライブラリを利用しました

github.com

今回一番苦労したのは、このライブラリの利用でした。 SlackのAPI側と別名で定義されているメソッドや、APIで必須指定がないものが 必須になっていたりと、ちゃんと確認しながら進めないとダメな感じでした。

slack.com

qiita.com

作ったbotAWS Chatbot と同様に、botにメンションを行いコマンドを実行する仕様としています。

aws.amazon.com

コマンドの詳細はGitHubのReadmeファイルを確認してください

github.com

github.com

スクリーンショットで利用しているbotアイコンについては以下のサイトから取得しました。

stampo.fun

次項からは簡単にコマンドの紹介を行いたいと思います。

hit コマンドについて

f:id:uchimanajet7:20200928113149p:plain

hit コマンドは、Slackのチャンネルに参加しているメンバーからランダムで指定の人数を選択できます。

想定しているユースケースは、レビューメンバーの選出や会議のファシリテーターの選出になります。

実際に、リモートワークにシフトしてから ランダムに誰かを選択する と言ったことが必要になることも多く、Slackのデフォルトアプリでも良い感じがします。

抽選のために専用チャンネルを作るのが運用としては良さそうな感じですが、既存のチャンネルで使いたい時に抽選対象ではないメンバーを指定できるような仕組みも実装しています。

translate コマンドについて

f:id:uchimanajet7:20200928113226p:plain

translate コマンドは、Amazon Translate を利用して日本語を英語に、日本語意外を日本語に翻訳できます。

想定しているユースケースは、SlackでRSS Feed を確認している場合に手軽に翻訳を行えるようにすることになります。

uchimanajet7.hatenablog.com

実際に、SlackでRSS Feedを確認していると場合によっては大量にステータスが更新されることもあり、手軽に翻訳できれば少しは便利になる感じがします。

以前に作ったSlackの国旗絵文字で翻訳する方法でも対応できるのですが、Slackのイベント発火がワークスペース全体となり、特定のチャンネルや条件で絞れないためワークスペースの参加者が多い、絵文字リアクションの利用が多い場合は、翻訳と関係ないイベントが大半となり Amazon API GatewayAWS Lambda の実行回数が増えることになります。

uchimanajet7.hatenablog.com

link コマンドについて

f:id:uchimanajet7:20200928113301p:plain

link コマンドは、botにメンションする際にSlackに添付したファイルをS3にアップロードして、ファイル取得が可能となる署名付きURL(Pre-Signed URL)を発行します。

f:id:uchimanajet7:20200928113405p:plain

想定しているユースケースは、メールに添付できないサイズのファイルの受け渡しや、ローカル環境からEC2インスタンスへのファイル持ち込みなどです。

実際に、EC2インスタンスにファイルを持ち込む場合は、対象のファイルをS3に一度アップロードして、EC2インスタンスでS3からファイルを取得する方法を取ることが多いのですが、対象ファイルをアップロードする手間がなくなるのは良い感じです。

署名付きURLの期限は指定可能となっていますが、今回はLambdaの実行にIAMロールを利用しているので、最大値はこの制限に依存します。

uchimanajet7.hatenablog.com

また、ファイルの添付は複数可能ですが署名付きURLについては1ファイル1URLとなります。これはS3の署名付きURLがオブジェクトに対して発行されているためです。 複数ファイルで1URLとしたい場合は、ファイル自体を圧縮するなど工夫をお願いします。

short コマンドについて

f:id:uchimanajet7:20200928113447p:plain

short コマンドは、短縮URLを発行することができます。

想定しているユースケースは、前述の link コマンドで発行した署名付きURLを短縮URLで短いURLに変換することになります。

実際に、署名付きURLはかなりの長さがあり、コピーミスで表示できない問題が起こったりしてました。短いURLにすることにより、単純なミスが減るのは良いか感じです。

署名付きURLに有効期限はあるのですが、短縮URLでも有効期限を指定することができます。

この短縮URLを発行する仕組みについては、以下のワークショップを参考にしています。 AWS CDKのワークショップとなるためCDK側のコードも非常に参考になります。

youtu.be

github.com

cdkworkshop.com

作成中に悩んだ部分

セキュリテイについて

Lambdaレイヤーの利用

Slackからのリクエスト処理

  • Slackからイベント内容が投げ込まれるが、3秒以内に応答しないと再送される
  • 対応するためには、Slackからイベントを受け取ったらすぐに応答するか、1度投げ込まれたイベントには反応しないようにする
  • API Gateway + Lambdaが同期処理されているため、今回は後者を採用した

Lambdaの非同期呼び出し

Slack APIについて

  • Slackに参加しているメンバーを取得しようとすると、先に見つかるのがワークスペースに参加する全員を対象としたAPI
  • このAPIだとSlack利用者が多い場合には時間がかかることが想定される
  • 調べてみると会話の単位(チャンネル・DMなど)に参加しているメンバーが取得できるAPIがあった
  • しかし、上記のAPIで取得できるのはユーザーIDだけ
  • 加えてbotやワークフロー実行ユーザーが一覧に入っている模様
  • ユーザー情報の詳細が取得できるので、その情報で人なのかを判別できる
  • 今回はユーザーIDだけ必要だったので、一覧取得の時にbotユーザーをフィルタできる機能が欲しかった

テストコードについて

  • LambdaとAWS CDKのテストコードをどうするか
  • Lambdaの方はgoogle先生に聞いてみるといろいろ出てくるしMockでの対応でもなんとかできる
  • CDKの部分はどうするばいいのか悩む
  • と思ってたら、ちゃんと公式ドキュメントに記載があった
  • 現状はどちらもテストコードがない状態なので対応が必要

利用する場合に注意する部分

今回は所属するチーム内での利用を想定し、チームで管理されてAWSアカウントに対してデプロイを行っています。そのため仕様上で考慮する部分などは共有できている前提で利用を想定しています。

もし、ご自身の環境で利用していただける場合には以下の部分に注意をお願いします。

AWS Lambdaの仕様に依存

docs.aws.amazon.com

メモリ容量に依存

実行時間に依存

  • Lambdaの現時点での最大実行時間は15分
  • 現在の実行時間設定も15分
  • Slackチャンネルの参加メンバーが多数の場合は実行時間をオーバーする可能性がある
  • 添付ファイルが極端に大きい場合は実行時間をオーバーする可能性がある
  • 実行時間はこれ以上延長はできないので、内部の仕組みを改善して対応する必要がある

Amazon DynamoDBの仕様に依存

docs.aws.amazon.com

キャパシティユニットに依存

TTLの仕様に依存

その他

構築について

  • AWSリソースはAWS CDKで構築される
  • 事前にRoute 53ドメインと利用するゾーンは作成する必要がある
  • CDKで構築を実行する際にはゾーン名とゾーンIDを環境変数に設定する必要がある

削除について

  • AWSリソースはAWS CDKで削除される
  • 事前に作成したRoute 53ドメインのゾーンは削除されない
  • CloudWatch Logsに出力されたログは削除されない
  • S3はbucketが空でないと削除できないため、削除を行わない
  • その他の関連リソースは自動削除される
  • データを保持する必要がある場合には、事前にバックアップを取得するころ
  • 完全に削除するには。上記の削除されないリソースを手動で削除する必要がある

まとめ

  • AWS Cloud Development Kit (AWS CDK) を使ってみたかった
  • せっかくだから普段使っているSlackのbotを作った
  • 作ったbotは普段使えて、ちょっと便利になる感じを目標にした
  • ランダム選択はそこそこ出番がある感じ
  • CDKはとても便利で楽しい
  • CDKの実装例はTypeScriptが多い気がする
  • 個人的にはPythonで書きたいのでもう少し実装例を増やして欲しい
  • CDKで書いたコードをどうテストするか悩んだ
  • CDKを利用することで、今回のようなSlack bot開発もほとんどマネジメントコンソールにアクセスせずに進められて捗る
  • 今後も機会があれば積極的にCDKは使っていきたいと思った
  • やっぱり手を動かしているのは楽しいです

以上になります。


Following is in English

medium.com

AWS Service Health Dashboard のRSS Feed をSlack に自動登録する #aws #slack

f:id:uchimanajet7:20200617165853p:plain

目次

前提

AWS の障害情報を確認しようと思うと、まずは AWS Personal Health Dashboard の情報をAmazon SNS 経由でSlackに通知するという、確実でお手軽な方法を検討するかと思います。

aws.amazon.com

docs.aws.amazon.com

これはこれで設定を行い Design for Failure を意識して他の手段も用意してみたいと思います。

どこまで気にするかという部分はあるので、今回は誰でも確認できる AWS Service Health Dashboard の情報もSlackに通知されるようにしたいと思います。

status.aws.amazon.com

RSS Feed URLが分割されている

AWS Service Health Dashboard を確認するとわかるのですが、対象のリージョンとサービスの組み合わせでRSS FeedのURLが分割されています。

SlackにRSS Feedを登録するには、RSSアプリをワークスペースにインストールして /feed subscribe [RSS Feed URL] のスラッシュコマンドを入力する必要があります。

slack.com

この分割されたURLが数十個というレベルではないので、手動で登録するというのは非現実的な対応となります。

1つのURLに情報が集約されているものがあれば解決しそうなのですが.・・・調べてみると http://status.aws.amazon.com/rss/all.rss というURLが存在するようです。

Service Health DashboardRSSページについて
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で作ってみました。

github.com

やっていることは単純で AWS Service Health Dashboard のWebからRSSのURLをスクレイピングして、リージョン単位とサービス単位で整理した状態で ファイルに出力します。

ファイルの内容はSlackのRSS Feed登録用のリストとなっていて /feed subscribe [RSS Feed URL] の形式で1行単位で出力されています。

github.com

# 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エンドポイントがあるらしい。

stackoverflow.com

そのエンドポイントをレガシートークンを使って呼び出せば、スラッシュコマンドを送信でできるらしい。

api.slack.com

しかし、2020年5月5日以降はこのレガシートークンの作成が行えない。。。

api.slack.com

ということで、他の方法を考えるのですが今回はサーバーサイドで画面なしで登録したいという要件ではなく、手元のPCで自動登録ができれば必要十分という状態です。

そうなると、手軽にできるのはブラウザを操作して自動登録を行う方法で、Google Chromeなら手軽に実現出来そうです。

developers.google.com

スクレイピングに続き、Google Chromeの自動操作もgolangで作ってみました。

github.com

こちらもやっていることは単純で、前述した /feed subscribe [RSS Feed URL] 形式で記載されたファイルを読み込んで、Slackの指定チャンネルにメッセージを送信するだけです。

事前にGoogle Chromeのインストールが必要なことと、メッセージを送信したいSlackのチャンネルにアクセスできる準備は必要ですが、そのほか自動で実行できます。

実際に手元のMacAWS 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 によるログインが必須となるとめ、この部分も特化して作成しています。

まとめ

f:id:uchimanajet7:20200617170251p:plain

  • AWS Service Health Dashboard の情報をSlackで通知したかった
  • 調べてみたらRSS Feed URLがすごい数があった
  • 自動で登録しないと厳しいが、API経由で登録する術がなかった
  • 結果としてGoogle Chromeを操作して自動登録してみた
  • 自動登録に利用するためのファイルをAWS Service Health Dashboardスクレイピングして作成した
  • どちらもCLIだけで完結できそうですが、今回はgolangで作成してみた
  • 何とか自動登録できたので結果としては問題なし
  • Headlessモードでの対応とか今後確認していきたい

以上になります。

Following is in English

medium.com

S3の署名付き URLを利用する際に注意する3つのポイント #aws #s3 #lambda #python #serverless

f:id:uchimanajet7:20190329093949p:plain

今回は

みんな大好きAWS S3ですが、署名付き URL(Pre-Signed URL)という便利で素敵な機能が利用できます。

非常によく利用される機能なので、ここで稚拙な 説明を書くようなことは割愛しますが、公式ドキュメントだと以下 Amazon CloudFront のドキュメントに詳細が書かれています。

docs.aws.amazon.com

今回はこのS3の機能をPython AWS Lambda で利用する際にハマったポイントを共有します。

Boto3 ドキュメントの確認

今回利用したAWS SDK Python(Boto3)のドキュメントを確認してみると

boto3.amazonaws.com

generate_presigned_url(ClientMethod, Params=None, ExpiresIn=3600, HttpMethod=None) となっており ClientMethod に get_object や put_object と言った署名付き URLにて操作を許可したいメソッドを指定して、Paramsbucket namekey name を指定するだけで戻り値として署名付きのURLが得られる完結な作りになっています。

通常は特に気にせず利用すればハマることもないかと思います。 今回は短時間ではなく1週間程度の期限を想定したことと、AWS Lambdaを利用したことでハマるポイントを作ってしまった形になります。

また、これに加えて Amazon S3 における AWS 署名バージョン についても考慮する必要があったため解決まで色々試行錯誤することになりました。

Point.1 実行権限について

AWS Lambdaを利用する場合 IAM role を利用して実行時に必要最低限の権限を付与した IAM policy を利用する形になるかと思います。

今回も個人的に好きな Chalice (Python Serverless Microframework for AWS) を利用しています。詳細は以下をご確認ください。

github.com

uchimanajet7.hatenablog.com

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日間)でドキュメントには特に制限は書かれていないので原因が分からず困っていました。

boto3.amazonaws.com

しかしWebを検索してみると問い合わせが多い内容のようで以下の公式ドキュメントが展開されていました。

aws.amazon.com

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 は

docs.aws.amazon.com

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 パラメータストアを利用しました。

docs.aws.amazon.com

使う側からするとSTSの有効期限を7日までに伸ばす方法があるか、URL文字列にこの情報を含めずにURLを作ってくれる方が嬉しいんですが・・・そこは将来に期待しております。

あとは、以下のページにあるスニペットをそのまま使えば 問題なく7日間有効な署名付き URLが生成できます。

aws.amazon.com

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が指定した有効期限より前に失効する場合は、利用している認証情報一時トークンを使用していないかを確認することをお勧めします。

また、合わせて署名バージョンについても SigV4AWS 署名バージョン 4)を利用する必要があるため、確認することをお勧めします。

今回はIAM roleで取得した一時トークンを利用していたことと、署名がSigV2で行われていたことの2点が問題となっていました。 SigV4を利用していないだけかと思い、もう一つの認証情報の件にたどり着くのが遅くなりました。皆様はお気をつけください。 今回は最終的にAWSサポートに確認して作業を行いましたが、AWSサポートは対応が素晴らしいのでもっと早めに確認するべきだったと。

Point.3 署名バージョンについて

前述のSigV4AWS 署名バージョン 4)を利用する件については、ここ最近のSigV2 廃止の話題でご存知かもしれません。

dev.classmethod.jp

docs.aws.amazon.com

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で紹介したコードスニペットをみると分かりますが

aws.amazon.com

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の利用を宣言する必要があるためとなります。

コードとしては以下のあたりが該当するかなーと。

github.com

github.com

署名バージョンの確認については、S3のログを利用して確認しました。

docs.aws.amazon.com

最近のアップデートでログに署名バージョンが出力されるようになったようです。

dev.classmethod.jp

docs.aws.amazon.com

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時間程度経過したのちに配信されることになるかと思います。

docs.aws.amazon.com

ベストエフォート型のサーバーログ配信

サーバーアクセスログレコードの配信は、ベストエフォートで行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。

サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。

サーバーのログ作成機能はベストエフォート型であるため、AWS ポータルで利用できる使用状況レポート (AWS マネジメントコンソール でレポートされる請求およびコスト管理レポート) には、サーバーログに記録されていないアクセスリクエストが含まれる場合があります。

さらに今回はログを確認する手段としてDatadogを利用しました。 ログインテグレーションを行なっていれば検索も簡単に行えますし 他のAWS関連メトリクスと1箇所で確認できるのは非常に便利ですね。

docs.datadoghq.com

以上を踏まえて 署名バージョンについては、Boto3(Python)に関してはSigV4を使うために明示的にプログラム中でバージョン指定が必要であり、これを行わないとSigV2で通信されていることがわかりました。

単純にSDKのアップデートでは対応できないことになるので、S3に対してアクセスを行なっているプログラムを確認する必要があります。

今後はSDK側のデフォルトがSigV4に変更というような方向で対応していただけると簡単で良いですが、影響範囲が大きそうなので無しの方向なのかなぁ

まとめ

  • Amazon Simple Storage Service (Amazon S3)

    aws.amazon.com

  • Simple って難しいなと思いました

  • AWSサポートは対応が相変わらず素晴らしいのでちゃんと利用しましょう
  • SigV2 がデフォルトなのは知らなかったです
  • STSの期限についてはworkaroundでもいいので延長できる方法が欲しいです
  • 権限がないのにURLが発行できるのもエラーで終わってもらえると良いきがします
  • Boto3側のドキュメントにSigV4の話とかリンクでいいので追加されていると親切だと思いました
  • Datadogはログインテグレーションして検索も簡単に!
  • 他のAWSメトリクスも合わせて1箇所で状態が確認できるので便利でした
  • 相変わらずドキュメントの読み込みが甘くて余計な手間が増えているなーと
  • ドキュメントはちゃんと読みましょう!

以上になります。

Following is in English

medium.com

AWS Lambda Go, Amazon Comprehend, Amazon Translate で作るSlack 翻訳Bot #aws #lambda #slack #golang #serverless

Go Support for AWS Lambda

もう発表されて結構経ちますが、AWS Lambdaでgolangが利用できるようになりました。

aws.amazon.com

待ちに待ってたので嬉しいのですが、業務でgolangを使う機会もなく・・・

LTのネタに

そんな状態のところにLTどうですか?とのお声がけがあったので、これはネタにするしかない!

mastercloud.connpass.com

と、いろいろと作業はしてみたのですが・・・結局間に合わずw

uchimanajet7.hatenablog.com

以前に書いたblogを資料にするだけになってしまいました・・・

speakerdeck.com

せっかくなので

とは言え、LTのネタにしようと作業自体は行っていたので時間のあるときにチマチマと作ってみてました。

github.com

とは言っても、機能自体は特に変更なく実装をAWS Lambda Goで行ったという感じです。

github.com

また、翻訳する部分をこれを書いている時点ではプレビューのAmazon Translateで行っています。当然ですが利用するにはプレビュー利用の申請が必要となります。

aws.amazon.com

加えて Amazon Translate には翻訳元の言語自動判定を行える機能がこれを書いている時点ではないようです。これを補う手段としてAmazon Comprehendを利用しています。

aws.amazon.com

結果としてAWSのサービスのみで完結することができたので、外部APIを使う際に気になる翻訳文字列を外部に送信するところは気にせずに済むようになりました。

AWS Lambda functions in Go

以下のリポジトリAWSが用意してくれたサンプルコードがあるので、特に困らず利用できると思います。

github.com

個人的には楽しみに待ってたので非常に嬉しいです。 実際に使ってみると

  • ビルド結果が1バイナリなので細かいことを気にしないで良い
  • デプロイも1バイナリなので簡単
  • AWS SAMとの相性も良さそう
  • 個人的に好きな言語なので開発が楽しい
  • イベントごとにハンドラーを用意すれば良さそう

github.com

  • 普段使ってるgolangのライブラリが使えるのはやっぱり便利
  • kelseyhightower/envconfig はステキ

github.com

  • nlopes/slack を使ってSlackとのやりとりを簡単に

github.com

  • Slack APIからinvalid_limit Error が戻って来る
  • どうやらライブラリ側の問題っぽい
  • せっかくだから Pull Request を出してみた

github.com

  • このような場合でもgo getした手元のコードを修正するだけで動作させられるのは気軽で簡単で良いです

Amazon Translate

f:id:uchimanajet7:20180223084357p:plain

翻訳のためにAWSのサービスであるAmazon Translateを使ってみました。

  • これを書いている時点ではプレビュー
  • 利用には申請が必要
  • プレビュー中なのもあってか対応言語が少なめ
  • 基本の言語である英語と以下の6言語

docs.aws.amazon.com

  • Arabic (ar)
  • Chinese (Simplified) (zh)
  • French (fr)
  • German (de)
  • Portuguese (pt)
  • Spanish (es)
  • 翻訳元の言語を自動判別する機能がない
  • これもプレビュー中なのもあってなのか、翻訳元か翻訳先の言語のどちらか片方が英語でなければダメ

docs.aws.amazon.com

  • 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

f:id:uchimanajet7:20180223084539p:plain

言語自動判別のためにAWSのサービスであるAmazon Comprehendを使ってみました。

  • 単純にSlackのメッセージを言語判定するAPIに渡しているだけ

docs.aws.amazon.com

  • Comprehendにも対応言語がある

docs.aws.amazon.com

  • 料金の設定で100 文字を単位として計算されるため、今回のような使い方だと勿体無い感がある

aws.amazon.com

自然言語処理 (NLP): Amazon Comprehend のエンティティ認識、感情分析、キーフレーズ抽出、言語検出のリクエストは、100 文字単位で計算され、各リクエストにつき 3 単位 (300 文字) が最低料金となります。

  • 実際に今回の使い方だと思ったより料金がかかる印象
  • Comprehend自体がもっと大量の文章を対象にしているためな気がする
  • 複数の言語が混在している場合の自動判定結果
  • 他のサービスでも同様だがこの辺の判定が思ってるものと違うと利用が難しい
  • ComprehendはAWSマネジメントコンソールから簡単に試せるので触ってみるのが良い

AWS Serverless Application Model (AWS SAM)

デプロイのためにAWS Serverless Application Model (AWS SAM)を使ってみました。

docs.aws.amazon.com

  • golangはビルド結果が1バイナリなので相性が良かった
  • LambdaとAPI Gatewayしか設定してないのでテンプレートも簡単だった
  • 複雑なことをしないなら手軽でいい感じ
  • 環境変数を設定するのでオプションの設定が手軽にできると良い気がする
  • せっかくのgolangなのにAWS CLIの利用が前提なのが若干残念

docs.aws.amazon.com

  • 今後もLambda Goを使うなら一緒に使っていこうと思った

まとめ

  • AWS Lambda を利用するならAWSのサービスで完結している方が楽
  • 認証もIAMロールで行えるので色々気にする必要なし
  • 外部のAPIにデータを送信することもないので、こちらも色々気にする必要なし
  • SlackからのWebhookを受ける場合は、やっぱり非同期処理しないと複数回受信する(Lambdaのコールドスタートのため)
  • この使い方だと粒度が小さすぎるのかComprehend の料金がちょっと気になる
  • Translate 側で言語自動判別ができるようななれば、Comprehend は不要となるのでアップデートに期待したい
  • 他の絵文字と合わせるためにSlackの国旗絵文字の文字列が変更になったっぽい

get.slack.help

www.webpagefx.com

  • 一部の絵文字国旗でflag−で始まらないものがある(:de: :jp: など)

f:id:uchimanajet7:20180223091838p:plain

  • 絵文字文字列の変更を真面目にウォッチするのは大変そう
  • ちゃんと使うならこの辺も考えないとだめそう
  • あ、Lambda Goは楽しいのでおすすめです!

以上になります。