nakanoshima.dev #34 - 開発しくじり先生 LT会 「Amazon SES のバウンス率が急上昇 〜Amazon SES を止めてしまった日〜」 の資料になります。 https://nakanoshima-dev.connpass.com/event/293381/
一休✕bitFlyer C#をつかったサービス開発の裏側 でお話しました。 speakerdeck.com この案件は主に @shibayan と一緒に進めていたもので、 最近キリのいいところまで終わったので社内向けの概要資料を兼ねてまとめました。 *1 内容に関しては概ね好評で参考になったという意見が多くてよかったです。 実際にあった質問は中井さんがツイートしてくれていたので引用します。感謝。 質問1 なぜSendGridをしたか? #ikyu_bitFlyer SendGridを選択した理由 ・ドキュメントしっかりしてた ・結構キャリア宛にも送る必要があった— Kansuke (@nakansuke) 2017年6月28日 昨日の一休さんのスライドが公開されてから、SendGridとSESどう違うの?ってツイートがちらほら。ぜひこちらをご確認をー| SendGridとAmazon SE
あの慣習 メールにパスワード付きzipを添付して「パスワードは別途お送りいたします」とする慣習、ありますよね。 自分からはやらないけど、相手に合わせてやらざるを得なかったりしてめんどくさい。 ここでは、このやり方の是非は問題にしません。 どんなに是非を説いても、この慣習があるという状況は変わらないので。 そして、この慣習を無くすことも考えません。 そういうのは巨大な力を持った何かにおまかせします。 昔のエラい人は言いました。「長いものには巻かれろ」と。 ただし、巻かれ方は考えたほうがいいと思うのです。 スマートな巻かれ方を考える 巻かれるにあたって、解決したいことはただ一つ。めんどくさくないこと。 このためにWebシステム作って、ブラウザ開いてどうのこうのなんてやってると本末転倒です。 可能な限り、普通のメール送信に近い形で実現したい。 というわけで、あれこれ考えた末、一部の制約を許容しつ
New — File Release for Amazon FSx for Lustre Amazon FSx for Lustre provides fully managed shared storage with the scalability and high performance of the open-source Lustre file systems to support your Linux-based workloads. FSx for Lustre is for workloads where storage speed and throughput matter. This is because FSx for Lustre helps you avoid storage bottlenecks, increase utilization of compute
ウィスキー、シガー、パイプをこよなく愛する大栗です。 先ほどAmazon SESのアップデートで、メール受信が可能になったので検証してみました。SESはメール送信専用のサービスでしたが、受信も出来るようになったので様々なユースケースに対応できるのではないかと思います。 2015/09/29 11:50 JST追記:Lambda Action、SNS Actionでメール本文が取得できないことを記述 SESでメール受信 先日SendGridを使ってAPI Gateway+Lambdaでメール受信を行う方法について紹介しましたが、AWSサービスで可能になりました(息の短いブログだった、、、でも、シンプルなWebhookだったらSendGridの方が良いかもしれません)。 以下の図のように、受信専用のSESのSMTPエンドポイントでメールを受信して、後続処理を行えます。 試してみる 実際にSES
Amazon Web ServiceでSESとSQSを使って、大量に高速に送ることが出来るメールマガジン配信システムを構築してみました。 もともと、別の開発者の人が開発していたものを、引き継いで受託していたサービスが、日々会員数が増えるたびにメールの配信時間が伸びていき、最終的に2万人に配信するのに6時間ほどかかるシステムになっていました。 システム システム構成はシンプルでAWSのEC2のインスタンス上でDBやアプリケーションが動いており、画像などのリソースの保存にS3を、メール送信にSESを使っています。 ちなみにアプリケーションはJavaEEです。最近ではちょっと珍しい?ですね。 問題点 もともとのシステムは、管理画面から登録されたメルマガ情報からメルマガを受診する対象のユーザーを取得し、名前などを埋め込んだスプールを作成する「スプール生成バッチ」と、DBに登録されたスプールを順番に
ども、大瀧です。 EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。 では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。 スパムメールとの闘いダイジェスト Eメールの歴史は、スパムメールとの闘いの歴史と言えます。 不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。 このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。 1. 送信メールサーバー側のネットワーク
とっても便利なのに、いまいちマイナーなサービス感が漂うAmazon SNS並びにSQSとSESの3兄弟。上手く使いこなせれば、下手なツールをインストールしたりプログラミングしなくても色々なことが出来る優れ物です。名前からしてイマイチどんな機能なのかよく解らないので、簡単に解説してみます。 Amazon Simple Notification(SNS) プッシュ型の通知サービスです。2013年1月現在では、HTTP/HTTPS、Eメール、SMSとSQSの4種類があります。つまりプッシュ通知するというところがこのサービスの本質で、通知方法は用途次第ということです。今は4種類ですが、そのうち増える可能性もあるでしょう。(例えば、iPhoneやAndroidへのプッシュ通知とか。) Amazon Simple Queue Service(Amazon SQS) その名の通りキュー・サービスです。前
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く