Details.md

実装詳細

構成要素

AWS Lambda, SQS, DynamoDB, S3からなる。S3以外の要素はCloudFormationで一括作成できる。

Lambda

Lambda関数4つが全ての処理を担う。コードは4つの関数で共通で、呼び出すハンドラを変えて処理を変えている。

1. Twitter-TL-Tracker-HomeTimeline （ホームTL取得）

• ハンドラ: index.homeTimeline
• 自動実行: 2分おき
• メモリ: 256MB
• ホームTLを取得し、S3に格納する
  • 規定では2分ごと。1分ごとでもいいけど、呼び出しレートは15分あたり15回なので同じAPIキーを何か他のことにも使い回しているなら2分おきが無難
• 前回どこまで取得したかはDynamoDBで管理

2. Twitter-TL-Tracker-QueueFiller （スケジュール作成）

• ハンドラ: index.hourlyTask
• 自動実行: 30分おき
• メモリ: 320MB
• 自分のフォロイーを一定時間（規定では30分）おきに1回取得し、巡回するユーザーのリストを作成してSQSに突っ込む
  • フォロイーだけではなく、フォロワーを取得対象に加えることも可（ストーカー気質の人向け）
• これがユーザーTL取得のスケジュールとなる
• SQSには常時たくさんメッセージが入っているようにする

3. Twitter-TL-Tracker-userTL （ユーザーTL取得）

• ハンドラ: index.userTL
• 自動実行: 2分おき
• メモリ: 320MB
  • 時間帯にもよるが、128MBだと大抵メモリが溢れて強制終了する。特に初回は全ユーザーの数日前からのツイートを取得しようとするため320MB程度があたりがオススメ。稼働を始めたら128MBにして多分大丈夫
• 2分おきにSQSのキューからメッセージ（ユーザーIDが書いてある）を取得し、その人のユーザーTLを取得してS3に格納する
• 呼び出しレート（15分で900回）を守るように適当に回数調整をする
• 前回どこまでツイートを取得したかはDynamoDBで管理

4. Twitter-TL-Tracker-merger （マージ）

• ハンドラ: index.archive
• 自動実行: 1日1回
• メモリ: 1GB
• 1と3が吐いた全てのファイルを結合し、ソートして重複を排除して1個のファイルに書き出す。

SQS

上述の通りユーザーTL取得のスケジュール管理に使っている。

DynamoDB

primary keyは id_str で、ユーザーの簡単な情報と、取得済みの最新ツイートのID(sinceId)を保存している。 ホームTLでも同様の目的で使っていて、そのレコードは id_str が TIMELINE の固定文字。 RCU/WCUは1にしている。

S3

• ホームTLは s3://YOUR-BUCKET-NAME/raw/2020-12-31/20201231.235959.999.json のような名前
• ユーザーTLは s3://YOUR-BUCKET-NAME/raw/user/2020-12-31/20201231.235959.999_123456789012345678.json のような名前
  • どちらも時刻をミリ秒までつけてキーがユニークになるようにしている。時刻そのものにあまり意味はない

IAM Role

• Lambdaに割り当てるためのロール。最低限必要な権限だけを設定してある。
• S3へのアクセス権限はCloudFormationのパラメーターで指定したS3バケットのみに絞っている。途中で保存するS3バケットを変えたくなった場合はLambdaの環境変数とIAM RoleのIAM Policyの両方を変更する必要がある。

なぜなに

暗号化しろ

やりたくない

• 暗号化したいキーは最低2つ、できれば4つ
• ホームTLは2分おき＆ユーザーTLは5分おきに起動（＝1時間に合計42回）
• これをかけると1ヶ月あたり12万回でKMSの無料枠をはみ出す（キー1個分の料金とあわせて$1.3ぐらい）
• ログを取るためだけのものに出したくない気持ち

Todo

• likeの定期取得＆差分抽出
• フォロワー＆フォロイーの定期取得＆差分抽出
  • UserStreamのEvent通知の代わりにしたい