AWSのSimpleな話(仮) 社内勉強会 2014/10/16 @saisa6153 

近況報告 

引っ越しました 荏原中延 → 北品川 

アルトサックス始めました 朝に品川埠頭で吹いています 

明日で24歳です 危うく深夜作業で歳を重ねるところだった 

本題 

メールを送りたい 

でもMTAは何かアレ 主に運用面 

No content

No content

No content

ドメイン/メアドの設定 ● 送信にあたり、ドメイン所有権を証明する ○ 指定のTXTレコードを設定 ○ TTLが切れ次第確認される ○ SPFに相当(?) ● 同時にDKIM認証を設定 ○ 指定のCNAMEレコードを設定 ○ 必須ではないが行ったほうが良い ○ ここらへんはRoute53なら2クリックなので良い ● Sandbox環境では送信先メアドに制限 ○ コンソールから設定したverifiedなものに制限 ○ Production移行時に申請すると制限解除 

SPF / DKIM ● SPF(Sender Policy Framework) ○ 送信元IPに紐づく認証 ○ 送信元の情報をDNSで公開 ● DKIM(Domain Keys Identified Mail) ○ 送信元による署名に基づく認証 ○ メールに署名し、公開鍵をDNSで公開 ● オンプレなら面倒だけどSESは超簡単 ● 詳しくはAWS Black Belt Tech 

SMTP Endpoint用IAM ● SESのコンソールから作成する ● 開発段階ではARNを広く取る ○ “ses:*” 

最初の一歩 >>> import boto.ses >>> conn = boto.ses.connect_to_region( ... 'us-east-1', ... aws_access_key_id='XXXXXXXXXXXXXXXXXXXXX', ... aws_secret_access_key='XXXXXXXXXXXXXXXXXXXXXXXXXXXX') >>> conn SESConnection:email.us-east-1.amazonaws.com 

最初の一歩 >>> conn.list_verified_email_addresses() {'ListVerifiedEmailAddressesResponse': { 'ResponseMetadata': { 'RequestId': 'XXXX-YYYY-ZZZZ-AAAA’}, 'ListVerifiedEmailAddressesResult': { 'VerifiedEmailAddresses': ['[email protected]']}}} >>> conn.send_email( ... ‘[email protected]', ... 'Testmail subject', ... 'Here is body', ... ['[email protected]']) {'SendEmailResponse': { 'ResponseMetadata': { 'RequestId': 'XXXX-YYYY-ZZZZ-AAAA'}, 'SendEmailResult':{ 'MessageId': '0000000000-11111111111111-22222222222-333333333'}}} 

Sender ● 一斉送信は非同期に並列処理したい ● workerをガッツリ立てていく戦略 ● 同AZ内のSession用RedisをBrokerに利用 ● 最初に送信対象リストをDynamoDBに作成 ○ 送信中にAZ障害が起きてもfailover先でリトライ可能 ● 送信ステートをDynamoDBに保存 ○ 送信中: workerが送信に着手 ○ 送信完了: workerが送信を完了した 

Bouncer ● 正月など特殊な場合はBounceの増加が懸念さ れる ● Sender同様、非同期workerを並列に ● SQSの有効期限(24h)で全てDequeueするた め並列度を適宜上げる ● DynamoDBにBounceアドレスを記録しMySQL のカウントを更新する ● 複数回Hard Bounceするなら削除する 

No content

DynamoDB ● Multi-AZでリトライを可能にしつつworkerを並 列させるために必要 ● メール送信時はstateのUPDATEが走るため Strong Consistency ● Bounce処理時はPUTだけなのでEventual Consistency ● 良い感じに2iが必要(多分) ● テーブルは使い捨て(DROPもするか？) ○ UPDATEコストの方が高いっぽい ○ UUIDかDATETIMEでテーブル作れば良いのでは 

SES / SNS / SQS ● 超シンプル!! ○ Simple Email Service ○ Simple Notification Service ○ Simple Queue Service ● Bounceが発生したら ○ SESがBounceを検知 ○ SESがSNSを発生 ○ SNSがSQSへEnqueue 

No content

No content

おしまい Happy Sending!