要点 

IFTTTとAWSのLambdaを利用し、外部サービスのWebAPIの結果を整形し、投稿するTwitterのBotを作成しました。

arch

はじめに 

ドラクエウォークどっぷりハマっていました。流石に飽きました。

閑話休題。

外部サービスのWebAPIから取得したデータを基に投稿するTwitterのBotを作成しようと考えました。そのためTwitter APIの利用申請をしようとしました。しかし以前のTwitter APIは申請に個人情報が不要でしたが、現在は電話番号の入力が必至となっています。またTextPlusのようなSMSを受信するために一時的に電話番号を発行するサービスも利用が出来ません。

そこでTwitter APIの利用目的がツイートを投稿する事であれば、IFTTTを利用する事でTwitter APIの申請は不要でBotを作成することが出来ます。以下ではTwitterのBotを作成する際に考えた案と、最終的な構成を紹介します。

ツイート投稿方法案 

プログラムでツイートを投稿する方法は主に4つの案がありました。

  • Twitter API
    • 審査と電話番号必至だが、自由度が高い
  • WebDriver(Selenium) on Lambda
    • デメリットが多いが、自由度が高い
    • 消費メモリーの容量が大きい
      • ブラウザを動かすため300MB~400MB程度
    • 実行時間が長い
      • レンダリング完了を待つ処理が必要
        • Angular用ならばProtoractorといった、レンダリングをライブラリ側で処理してくれるものもある
    • 成果物のアップロードサイズが大きい
      • ブラウザを同梱する必要があるため50MB程度に膨れ上がる
      • 50MBを超えるとS3経由でしかアップロードできない
    • HTMLの構造変更に追随する必要がある
      • Twitter APIと異なりHTMLは公式な仕様が発表されているわけでないので、リファクタリング等の影響で構造が変化し、DOM操作時にエラーが発生する可能性がある
  • IFTTT
    • 用意されたTwitterの機能しか使えないが、手軽に利用できる
  • その他外部サービス
    • TwitterBotなど色々あるが、定型文の投稿のような用途レベル

最初の候補であったTwitter APIは電話番号が必要だったため諦めました。

次にWebDriver on Lambdaですが、オーバーエンジニアリングで楽しかったのですが、Twitterから不正アクセスの心配をされ、下記のようにメールが鬼のように飛んできました。またブラウザを起動する関係上動作に必要な要求スペックが高くてMemory512MB, 実行時間20秒で、オーバーエンジニアリングというよりも、ただの無駄と感じたので素直に止めました。

warning

その他外部サービスは『外部サービスのWebAPIからデータを取得し、整形した結果をツイートする』の目的に応えるものが無さそうだったので早々に諦めました。

最終的には、IFTTTで『WebhookにHTTP Requestされたデータをツイートとして投稿する』アプレットを作成することにしました。

やり方 

『一定時間毎に外部サービスのWebAPIからデータを取得・整形し、ツイートとして投稿する。』をAWSとIFTTTを組み合わせて行いました。

今回のAWS役割はGoogle Apps Scriptで代用でき、AWSアカウントが必要ないのでそちらの方が敷居が低いと思います。ですがAWSJPの無料キャンペーン通知で用意した仕組みで、無事に無料キャンペーン中にAWSアカウントを作成したので、あえてAWSを利用しました。

AWSとIFTTTの役割は以下のとおりです。

AWS 

  • Lambda
    • 外部サービスのWebAPIからデータ取得
    • データ整形
    • IFTTTのWebhookにデータをPOST
  • CloudWatch
    • Cron役でLambdaの起動

IFTTT 

  • ツイート内容の受け口の用意(Webhook)
  • ツイッターに投稿
    • URLが含まれていると勝手に短縮URLに変換するので、設定から無効化

補足 

今回は外部サービスWebAPIからデータ取得する際、データ取得に失敗した場合は一定時間後にリトライをする処理は含めていません。

仮に処理を含めるとするならば、AWSを利用しているのでSQSを用いると、とても簡潔に実装できます。

料金 

参考までにLambdaの料金は下記のとおりですが、余裕で無料枠の範疇です。

単位変換

割り当てたメモリ量: 128 MB x 0.0009765625 GB in a MB = 0.125 GB

Pricing calculations

RoundUp (3000) = 3000 Duration rounded to nearest 100ms

90 requests x 3,000 ms x 0.001 ms to sec conversion factor = 270.00 total compute (seconds)

0.125 GB x 270.00 seconds = 33.75 total compute (GB-s)

33.75 GB-s - 400000 free tier GB-s = -399,966.25 GB-s

-399,966.25 GB-s x 0.0000166667 USD = -6.67 USD (monthly compute charges)

90 requests - 1000000 free tier requests = -999,910 monthly billable requests

Max (-999910 monthly billable requests, 0 ) = 0.00 total monthly billable requests

1 か月のコンピューティング料金 (monthly): 0.00 USD

https://aws.amazon.com/jp/lambda/pricing/

おわりに 

今回は、外部サービスのWebAPIを利用してTwitterのBotとして投稿する事について記載しました。ITFFFとLambdaを利用した場合は、特にハマりどころもなくすんなりと実装することが出来ました。

話としては殆ど触れませんでしたが、WebDriver on Lambdaは大変でした。手元で高速に試行錯誤する環境を用意しなかったのが悪かった事と、Lambda上では不正アクセスを疑われて本来のログインの遷移とは異なる、メールアドレスの入力確認画面に遷移させられた事など、時間が掛かる要因が多かったです。