AWS最新情報を呟くTwitter Botのアーキテクチャ紹介
はじめに
皆さんはAWSの最新情報は日々チェックしているでしょうか?
私は毎朝の日課としてWhat's New with AWS?を見て、AWSの最新情報をチェックしています。
What's New with AWS?はとても素晴らしいのですが、日本語へ翻訳されるのに1週間程度のラグがあります。
そのため、日本語に自動翻訳してTwitter Bot化すれば良いのでは?というモチベーションでBotを作成しました。
↓実際に作成したTwitter Bot ※リンクからフォローいただけると幸甚です
3行まとめ
本記事を読むと以下の情報が得られます。
- 実装時に考えた&工夫した点
- 今回のBotを動かすために実際に発生している月額AWS利用料
- Twitter Botの動作アーキテクチャ
実装時にまず考えたこと&工夫した点
まず考えたこと
- Better than Nothingの考えで、まずはローンチしてバグや改修は都度行う
- AWSのマネージドサービスを利用する
- 個人制作なのでなるべく低コスト&あまり運用したくない
まずは、1.
の観点から2,3日程度で作成&デプロイしたいと考え、
2.
の観点からざっくりとしたアーキテクチャーを頭の中に描き、
3.
の観点から海外リージョン利用&マネージドサービス利用&サーバーレスアーキテクチャにすることにしました。
工夫した点
-
Lambdaのアーキテクチャをx86_64ではなく、Arm64にした
ざっくり言うとArm64の方がコスパがいいです。
制限事項があるので、詳しくはAWS公式ドキュメントLambda 命令セットアーキテクチャを参照してください。 -
料金が安い海外リージョンを選択した
日本国内リージョン(東京, 大阪)は海外リージョンに比べ、全体的に利用料金が高いです。
(DynamoDBのストレージ料金を例に取ると、東京はオレゴンに比べて14%高いです)
今回は "日本国内にデータ保存する必要がない" & "レイテンシを考慮する必要がない"ため、海外のオレゴンリージョンを利用しました。
オレゴンリージョンを利用した理由としては、全リージョンの中で利用料金が安かったからです。
WHICH AWS REGION IS CHEAPEST? A COSTING REPORTにて利用料金についてまとめて下さっている方がいますが、(オハイオ|バージニア北部|オレゴン)リージョンが同率で一番コストが安いようです。 -
エラー時にすぐに対処できるようにSlackへ通知する実装とした
最近ではエラー時にSlackなどのチャットツールに通知することが多いかと思いますが、今回のBotも漏れなくSlackへの通知を行なっています。
今回はPython3でLambdaを記述したのですが、Slack公式のSlack SDKを利用することで、簡単にSlack通知を実装することができました。
今回のBotを動かすために実際に発生している月額AWS利用料
$2.33994/Month(2022年10月の実績値)
※無料利用枠と永久無料利用枠を考慮しない金額です。
今回動作させているアーキテクチャはほとんど永久無料枠にて賄えております。
唯一利用料がかかっている翻訳サービスのAmazon Translateも「利用開始から12ヶ月は200万文字/Monthまで無料」となっているので、現在は無料でTwitter Botを動かすことができています。
(現在はAmazon Translateを利用して翻訳していますが、200万文字/Monthの無料期間が終わったら別のサービスやライブラリに置き換えるかもしれないです)
無料利用枠内
サービス名 | 単価 | 利用量 | 利用料合計 |
---|---|---|---|
Amazon Translate | $0.000015/1Charactor | 155,996 | $2.33994 |
永久無料枠内
サービス名 | 単価 | 利用量 |
---|---|---|
Dyanamo DB(Standard Read Capacity) | $1.25/1,000,000Read | 2,595 Read Capacity |
Dyanamo DB(Standard Write Capacity) | $1.25/1,000,000Write | 2,595 Write Capacity |
Dyanamo DB(Standard Storage) | $0.25/GB | 0.000199 GB |
Lambda(Request) | $0.2/1,000,000Requests | 3,115 Requests |
Lambda(Compute) | $0.0000133334/GB-秒 | 869.228 秒 |
EventBridge(Rules) | $0 ※1 | 3,115 Requests |
CloudWatch Logs(ログ取り込み) | $0.50/GB | 0.001 GB |
CloudWatch Logs(ログアーカイブ) | $0.03/GB | 0.000095 GB |
KMS | $0.03/10,000Requests | 479 Requests |
※1 EventBridgeの料金がAWS Billingの明細に乗っていないので、Lambdaに紐づけてイベント発火している場合には料金計算対象外(無料)だと思います。詳細はAWSに問い合わせているので、判明次第追記します。
Twitter Botの動作アーキテクチャ
アーキテクチャ図
処理説明
アーキテクチャ図のオレンジ文字の説明です。
1. 定期実行
Amazon Event BridgeのRulesを用いて10分ごとにLambdaを実行。
2. RSS取得
What's New with AWS?のRSSを取得 &&
feedparserやPython標準のHTMLParserを利用してRSSをパース。
3. 秘匿情報取得
TwitterやSlackに投稿する際の秘匿情報は AWS Systems Manager Parameter Storeに格納してあるので、実行時に取得。
4. 重複チェック
以下の順で重複チェック(フィルター)。
1. 「RSS内のpubDate(公開日時)が5時間以内のもの」をチェック
↓
2. 「RSS内のguidを基に、DynamoDBにレコードがないこと」をチェック
最初はpubDate(公開日時)だけで重複チェックを考えたのですが、実行時間によっては最新情報をお漏らしする可能性があるのでDynamoDBを追加しました。
5. 英日翻訳
Boto3 translate_textを利用して翻訳(同期処理)。
6. Tweet
tweepyを利用してTweet。
7. Put Item
Tweet成功した "guid", "pubDate", "link", "translated_title" をDynamoDBにPut。
その他
-
Terraform
今回のアーキテクチャはTerraformでIaC化しています。
(イイネやコメントで要望多ければGitHubで公開します) -
エラー通知
Python内のTry-CatchでエラーメッセージをそのままSlackに投稿しています。
エラー発生頻度は1ヶ月に1,2回程度で、内容はほとんどTwitter APIから返却される↓ツイート重複エラー↓です。
-
ログ格納
CloudWatch Logsにログを格納。
ERROR以上のログを出力しており、ログの保持期間は2週間に設定。
おわりに
AWSをはじめとする技術は常に新しいものが出続けるので、全てをキャッチアップしていくのは大変かと思います。
皆様のキャッチアップの助けとなれば...と言う思いからTwitter Bot作成いたしましたので、興味を持った方は是非リンクからBotのフォローいただけると幸甚です。
コード見たい方が多ければ、Terraform/PythonのコードをGitHubで公開するのでイイネやコメントお待ちしております :D
この記事を見てくださった方が少しでもAWSに興味を持ち、世界が今より少しでもより良くなっていくことを心より望みつつ筆を置きます。
Discussion