Fugu Log

げきょゎエンジニアの技術修行ブログ

Amazon SESの送信者評価通知まわりに少し詳しくなった話

こんにちは。
最近Amazon primeで劇場版クレヨンしんちゃんシリーズを一気見するのにハマっています。

割と泣けるんだよなぁ…

前提


今の現場ではスクラム開発をやっているのですが、最近開発メンバーの一部から問合せ対応専任を抜擢して
ローテーションするという試みを始めました。


2週間前からとうとう自分にもローテーションが回ってきて、
毎日ヒィヒィ言いながら問合せ対応をしています。


今日はその問合せ対応で、Amazon SESに関する質問の回答をする上で調査の必要があり、
サービスの送信者評価通知の仕組みをちょっと勉強したのでその話をします。
(間違った情報があったらスミマセン...)


Amazon SESってどんなサービスなの


f:id:siromamex:20191221135014p:plain
Amazon Simple Email Service


aws.amazon.com

Amazon Simple Email Service (Amazon SES) は、デジタルマーケティング担当者やアプリケーション開発者がマーケティング、通知、トランザクションに関するEメールを送信できるように設計された、クラウドベースのEメール送信サービスです。Eメールを利用してお客様とのつながりを維持するあらゆる規模の企業を対象とした、コスト効率の高い信頼できるサービスです。

Email"送信"に特化したサービスのようですね。(受信もできるみたいですが)
効率的に大量のメール送信を行うことができるらしいです。


例えば、新製品を開発したので宣伝したい!といったときにもAmazon SESを使えばお得意様先にシュシュっとメールを飛ばせちゃいます。
その他にも、製品のバージョンアップ連絡やライセンス更新のお知らせなど、
製品関係の通知に使ったりするというユースケースがあるみたいですね。


自分でメールサーバを立てたり運用する必要はなく、気軽に大量のメール送信ができる。
かかるコストもメールを送った分だけという素晴らしいサービスです。

送信者評価ってなに


こんな感じで気軽に大量のメール送信ができちゃう便利なAmazonSESですが、
その気軽さ故に悪意のある送信者が使用する危険性もあるわけです。


大量にスパムメールなんかを送ったりすることにも使えるということですね。
これをAmazonSESを使ってバンバンやられたら、Amazonとしても困ります。


そこで「送信者評価」の話になります。



例えば、送ったメールのうち、どのくらいの割合でメールが到達しないで返ってきてしまうのか。(バウンス率)
どのくらいの割合で送信したメールに対しての苦情がきているのか。(苦情率)


これらを常にAmazonから監視されており、この送信者は良い送信者か悪い送信者かということを評価されています。

あまりにもこの割合が高い=送信者評価が悪い場合は
AmazonからSESを使えないようにされてしまいます。


SESを健全に使うために


悪意のある人は、上記のAmazonが監視してくれる仕組みで野放しにされないようになっています。
しかし、特に悪意がなかったとしても、バウンス率や苦情率が高くなってしまうことがあるようです。


別に意図してなかったのに送信者としての質が悪い!とされ、ある日突然サービスが使えなくなったら困りますよね。


そこで、送信者としての質が悪い場合はAmazonから通知が行われます。
これがタイトルの「送信者評価通知」ってやつですね。

Amazon SES では、送信者としての評価にダメージを与える可能性のあるメトリクスや、メール配信率の低下を招く可能性のあるメトリクスなど、複数のメトリクスがアクティブに追跡されます。このプロセスで監視する 2 つの重要なメトリクスは、アカウントのバウンス率と苦情率です。アカウントのバウンス率や苦情率が高すぎる場合、アカウントを確認し、アカウントの E メール送信機能を一時停止することがあります。

https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/monitor-sender-reputation.html


具体的には、バウンス率が5%以上になったら一旦警告が行われ、
10%以上になったら一時的にSESサービスが利用停止になるそうです。
その後、改善活動を実施したということをAmazonに伝えればまた使えるようになる…らしい?(ソースは不明)


ちなみに、「送信者評価通知」という言葉は私が適当に考えた言葉なので、意味とかはあまり気にしないでください。


バウンス率が5%を超えた時点での通知は、
SESコンソールの評価ダッシュボードに届くようです。
コンソールの [Sending Statistics]ページではバウンス率や苦情率といったメトリクスの推移をグラフで見ることができます。


でもこれ、具体的な数値はダッシュボードに表示されて、メトリクスの推移は[Sending Statistics]ページに
表示されるんだよなぁ…どっちもダッシュボードで見れたらいいのに…
(グラフではなんとなく視覚的にこの辺かな?という割合は確認できるけど、具体的な数値は表示されない)


コンソールから直接モニタリングできるけど、そんなのいちいち見るのめんどくさい!という人は
CloudWatchでバウンス率が高騰した時にメールやSMSで通知を送ってくれるように設定できます。



バウンスメールが発生する原因を根本から分析して解決したいという人は、
Amazon SNSと連携してバウンスメールや苦情が発生した時にフィードバック返信をくれるように設定したり、
トピックを作成してバウンスや苦情の詳細情報をJSON形式で受け取ることができるみたいです。


なんかよくわからんがバウンス率や苦情率があがっとるな?と感じた場合は
この情報を使って配信設定を改善して、送信者評価の悪化を未然に防ぐということができますね。


https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/configure-sns-notifications.html

まとめ


2ヶ月前くらいにSAAの勉強をしていましたが、Amazon SESに関してはそこまで勉強してなかったので
今回、問合せ対応をきっかけにサービスをざっくり理解できてよかったです。
試験にSESってそんな出てきてなかったような気がするけど…^^;


あと、Developerガイドって調べたいことが明確な時はとても有用なんですね。
Amazon公式ドキュメントにしてはわりとわかりやすかった気がします。


問合せ対応って大変だなぁ…



おしまい

シェルスクリプトでかっこよく処理しようと思ったらつまづいた話

 

金曜から始めていろいろコケて困っていたけど今日解決した話です
先に言っておくと完全にしょーもないミスです

 

前提

会社から怒られない程度に現在やっているお仕事の内容をふんわり書いておくと、

IoT関連のインフラ基盤開発をやっています。

フェーズで言うと構築/運用/保守ですかね。

 

ごく最近(2ヶ月前)に唐突に配属が決まり、訳がわからないまま仕事が始まって、

今に至ります。

 

f:id:siromamex:20191216232619p:plain

 

やろうとしたこと

コンテナにのせたAPIゲートウェイcurlを投げて、DBからデータを取ってきて、

それをjson形式に変換!という作業をシェルスクリプトで書いて、実行しようとしました。

 

元々コマンドがドキュメントにずらずらと書いてあって、それを1行ずつ

ちまちま編集しながら投げていたのですが、

環境が代わるたびに同じ作業をやらなきゃいけないのが

めんどくさい&どうせなら勉強がてらシェルスクリプトで書いてみよう!

と思い至りちょちょっと調べて書いてみました。

 

以下がコード例です。

〜
#!/bin/sh
curl http://$1.$2.info/hoge? -H "AdminToken:${3}" -o hoge.json
curl http://$1.$2.info/huga? -H "AdminToken:${3}" -o fuga.json
curl http://$1.$2.info/poke? -H "AdminToken:${3}" -o poke.json
...
...
...
〜

コマンドライン引数を使って、環境によってURLとAdminTokenが変更できるようにしました。

これで何回も同じようなコマンドを叩かなくて済む!と意気揚々と実行した結果、



やっぱり初回はうまく行きませんでした。

1回目のミスは…

  • シングルクォートをダブルクォートに直すのを忘れてた

→シングルクォート内だと変数が変数として認識されないので、ダブルクォートで囲む必要があった


修正し、これでいけるだろ!と叩いてみるも、




また失敗。

今度はURLを間違えたかな?と思ってコンテナのyamlを見て、
routeとserviceがちゃんと設定されてることを確認。
そもそもcurl投げて応答があるかを確認したら、curlが帰ってこない。

確認したら、認証関連のミスでpodが立ってませんでした。てへぺろ



podもちゃんと立ったし、curlも通った!今度こそ!と思って実行してみると、


今度はちゃんとデータが取得できたっぽい。



…けど、jsonファイルの拡張子の後ろに?マークがついてる。
なんぞこれ?と思いながら中身を確認すると中身はおそらく大丈夫。
でも謎のエクスクラメーションマークが気になる。。

シェルスクリプトで実行することが原因なのかと思い、一つだけコマンドを抜き出して叩いてみると、
今度は普通に.jsonだけでファイルが取得できた。


??????と思いながらも、エクスクラメーションマークがついたファイルを削除しようとすると…


rmコマンド後の確認でエクスクラメーションマークが^Mと表示されているのに気付きました。

^Mってなんだよと思いながらググると、改行コードの話がずらっと出てきました。え?



もしやと思って編集していたサクラエディタの改行コードを見てみると、CRLFでした、、。
これがlinuxで化けて?になってたのね、、、


サクラエディタの改行コードをLFに変更して、実行してみると綺麗にjsonファイルが取得できました。
よかったよかった…


まとめ

いろいろつまづきましたが、めんどくさい取得処理を一気にできるようになりましたし、
シェルスクリプトを書く練習や改行コードの違いの勉強にもなったので結果オーライですね。
次はオプションとか使ってちゃんと文法チェックしていきたい。



おしまい

first log

 

自己紹介

はじめまして。

 

今年新卒でSIerの会社に入社し、インフラエンジニアとしてお仕事をしています。

毎日ヒーコラ言いながらインフラ技術の勉強兼業務をしています。

 

一応情報系学部卒なんですが、入社するまでネットワークとインターネットの違いがわかってませんでした。

エンジニアはみんなよくわからんことをスラスラやっているすげーつよい人だと思ってました。

 

そんな私が社会人になって、エンジニアとして毎日コマンドを叩いたりしているなんて学生の頃は思ってもみませんでした。

 

そんな感じのげきょゎ系エンジニアです。

 

 

このブログの内容

このブログでは勉強したことのアウトプットや備忘録として技術のことを書いていこうと思います。(すぐ忘れちゃうから)

 

たまに趣味×技術のことを書くかもしれません。

 

 

 今のところ興味のあること・勉強してること

  • Docker/k8s
  • Ansible

上記二つは業務関連です。仕事のために勉強しています。

 

こちらは趣味で作っているwebアプリケーションとか、っょぃエンジニアになりたくて始めた技術です。かじっているものは他にもありますがちゃんと勉強したのはこの辺です。

 

ゲームプログラミングはすごく興味があるけど今のところ手一杯で始められていません。一応Unityに興味があります。参考書ほしい…(高い)

 

 

好きなもの

ゲームが好きです。特に協力プレイができるものが大好きです。

最近はMHアイスボーン、human flat fallをクリアしました。

 

お酒が好きです。特に日本酒が好きです。社会人になってからよく飲むようになりました。辛め且つ香り高いやつが好きです。十四代飲んでみたい。

 

 

 

よろしくお願いします。