<< 11月 2016 | Home | 1月 2017 >>

これまで体験してきたメール送信の難しさ #SendGrid_jp

SendGrid Advent Calendar 2016の12月22日分です。

メールを送る際、プロトコルとしてSMTPが使われていてメールサーバにはPostfixやGoogleのメールサーバなどを使えば簡単というのは割と有名です。
が、送るのは簡単だけど何かと問題が発生するものです。

私のこれまでの経験をちょっとメモしておこうと思います。

メール配信周りの運用経験


1. 自宅サーバ運用の掲示板(James、2000年〜)
2000年くらいから自宅サーバで掲示板を運用していました。Tomcatで動くServlet + JSPのアプリケーションで、メールアドレスを登録しておくと新規書き込みがメールで通知されるというものです。
メールの配信にはPure JavaのメールサーバであるJamesを使っていました。
自宅サーバで運用してた(今も動いてるけど)のは勉強、練習みたいなもので特にサーバの運用が好きなわけではありません。なんかガラケーで届かないと訴える人が多いなーと思いながらなんとなく運用していました。

2. 自宅サーバ運用の掲示板(Google Apps、2007年〜)
たしか自宅サーバのマシンを更改するタイミングでJamesの運用が面倒になり、Google Apps for Domainからメールを送るようにしました。
なんとなくガラケーにも届きやすくなったような??

3. いくつかのドメインでのメール運用(Google Apps)
友人知人のWebサイトやドメインを運用する中、もちろんたいしてお金はもらっておらず責任はとれないということで自宅サーバでの運用ではなくGoogleでメールの送信をしていました。

4. 会社のメール運用(Google Apps、2013年〜)
会社のメールもやはりGoogle Apps(現G Suite?)を使ってます。

勉強不足で、ボンヤリと「メール配信はなんとなく自前でサーバを建ててもよいし、GoogleのSMTPサーバを使うも良いし、なんでも良い」と長年思っていました。時々配信に失敗しているなーと思いつつ。

起きたトラブル


1. ガラケーに配信されないことがある
ガラケーの、いわゆる「キャリアメール」については「届かないことがある」「全く届かない」という話がボチボチありました。自宅掲示板サーバは商用環境の運用ではないので大して調べもせず、ドメインのホワイトリストに入っていないからとか、リンク入りのメールは全部拒否する設定になっているとか、PCメールは受け付けない設定になっているから、といった理由だと思っていました。(それらの理由による不達も多いにあると思いますが
実感的にJamesからGoogle Appsにしてから到達率は少し増えたように感じます。

2. ガラケーじゃなくても配信されないことがある
Google Apps for Domainを使っていればガラケー以外は大丈夫だろうとたかをくくっていましたが、会社のメールもたまにとどいてないらしいことが分かりました。長い間、相手側のサーバの不具合だと決めつけていました。

3. 文字化けが起きる
メールのエンコーディングは日本語を送るのに一番無難(と思っている)ISO-2022-JPで送っていました。UTF-8に固定しているような人でないかぎり正常に読んでいただけます。
が、お客様のお名前で「山﨑」といった異体字が使われているとJavaのプログラム内では正常に扱えても、ISO-2022-JPに変換するタイミングで"?"に化けてしまいます。

4. 24時間メールが配信できなくなる
オフィスを移転した際、移転のお知らせをお客様にメールで一斉に送付しました。自作のプログラムで、顧客リストをグルグル回しながら順に送っていったのですが、途中から送信できなくなりました。エラーメッセージを調べると、どうやらGoogle Apps for Domainではメール配信数に上限があることがわかりました。(無料だと24時間で500、有料では2000件)
移転のお知らせを送れないのは全く困りませんが、受注の確認や、ライセンスが送付出来ないのは大問題です。

とった対策


1. / 2. SPFレコードを設定しました。知っている人からすればビックリでしょうが、なんと会社を立ち上げて2年もの間SPFレコードを設定していませんでした。

SPFレコードはDNSに設定するもので、「このドメインからはこのIPアドレスからメールを配信するよ」という宣言です。得体の知れない人(送信元IPアドレス)が「これが株式会社サムライズムからのメールです」と主張して手渡してきても確証が得られないので、「これは送信元ドメインを偽装しているのでは?」と疑われてしまうわけです。
SPFレコードを設定しておけば「弊社からのメールはGoogleのSMTPサーバから配信されますよ」と宣言できるので、疑われにくくなるという仕組みです。
「メール配信はPostfixでもなんでも、メールサーバがあれば送れるさ!」と思っているエンジニアは結構多いので気をつけましょう。

3. 「必要に応じて」UTF-8にする
異体字に対応すべく、ある時期からメールを全部UTF-8で配信するようにしました。イマドキさすがにUTF-8が読めないクライアントはないだろう、と踏んでのことです。
が、それなりの数のお客様から「化けていて読めない」という声を頂くようになりました。異体字が含まれるメール以上の数なので問題です。
そこで今では「基本的にISO-2022-JP、ISO-2022-JPで表せない異体字が含まれる場合はUTF-8」で送信するようにしています。以降文字化けは起きていません(聞く限りは)。

4. 大量配信しない
問題解決ではなく、消極的な回避ですがまとめて配信することは移転のお知らせで一回やっただけでやめにしました。

以上、SendGridとは間接的にしか関係ないけれども「メール配信をナメてかかると痛い目に遭うよ」という話でした。
文字だらけで申し訳ないですが、経験に学ぶのは愚か者なので、これからメール配信をする可能性のある方は歴史に学んでいるSendGridを初めとするメール配信サービスを利用することをお勧めします。
株式会社サムライズムでは少しずつ検証を重ねながら、今週から全面的にSendGridでメール配信をするように切り替えました

現状どのように使っているか、どういう点につまずいたのか、などはまた別途まとめたいと思います。

このエントリーをはてなブックマークに追加   

BPMエンジンとしてのJIRA #augj

TL;DR


JIRAでBPMとか考えるのはやめましょう。でもちょっとしたシステムと人間系ワークフローとの連携に使うのは良いアイディアです。

今更だけどJIRAって?


JIRAは一般的にバグトラッキング、または課題トラッキングシステムと分類される製品です。

良くあるのがソフトウエア製品の今後追加する機能やバグを課題として登録しておき、担当者を決めて、終わったら完了済課題としてマークしていく使い方ですね。

JIRAが導入されている企業、プロジェクトは非常に多く、そして様々な場面で利用できるようカスタマイズの幅も広いです。

ワークフロー


中でも便利なのが「ワークフロー」です。つまり、課題が登録されてオープン状態なのか、完了してクローズしている状態なのかだけでなく、課題が登録されてから完了するまでワークフローがたどる可能性のある状態をグラフで表せる機能です。例えば注文を頂いたら

・受注内容を確認する
・確認完了したら上長の決裁を待つ
・決裁が完了したら手配して終わり

というワークフローがあれば以下のように定義します


ちなみにこのグラフィカルに定義できる仕組みは元々サードパーティーのプラグインだったのが、出来が良いので買収の上取り込まれたという経緯があります。ステキ。

ワークフロー上で状態を遷移するタイミングで決まった人に担当を変えるとか、特定の条件が揃っていないと状態を遷移できないとか、遷移のタイミングでWebhookを呼び出すといったこともできます。

ビジネスプロセスマネジメントとワークフロー


エンタープライズ系のベンダに勤めていた私はワークフローと聞けばBPM(ビジネスプロセスマネジメント)を思い浮かべます。BPMはビジネスプロセスを分析/解析して、可視化・システム化して、監視、改善していくことです。

なんとなく口頭伝承されてきたプロセスは人によってブレがあったり、間違いがあったりします。必ずしも人間の作業をシステムで全部置き換えるところまでいかなくても、まずは作業の流れを統一してブレをなくすことが大事です。

その後は運用状態を監視して、どこにボトルネックがあるのか、手戻りが発生しやすいのはどこなのか、ここは自動化すべきなのでは、といったことを分析して改善していきます。

BPM用の製品として(自分的に)有名なのがAlfrescoや、jBPMです。

BPM製品では人間系がからむ承認といった手順とシステムで自動化させたフローを管理できます。

JIRAでBPM・・・に向かない


結論から言うと、JIRAでBPMを行うには制約が大きすぎます。理由はさくっと2つ思い付きます。(細かいこと考えるといくらでもあります)

1. フローの平行パスを定義出来ない
ビジネスプロセスを分析すれば、例えば
「課長と部長の承認がいるけれども順番は問わない」
「システムが集計しているのと平行して人間は請求書を投函する」
みたいな平行パスが現れてきます。JIRAのワークフローは2つ以上の状態を持つことができないので、フラグ用のフィールドを持たせるとか、サブタスクを定義するといった設計上の工夫が必要になります。「工夫」で回避できますが、ビジネスプロセスを俯瞰して監視、管理したいという点からするとちょっと辛いですね。

2. トランザクション管理ができない
エンタープライズシステムでは1にも2にもトランザクションです。特定の処理が失敗したら関連する処理はまとめてロールバックしたいところ。JIRAで、状態遷移するタイミングでWebhookで何らかの一連の処理を呼び出すことはできますが、処理が失敗したからといってまとめてロールバックしてくれるわけではありません。まぁHTTPを超えてトランザクションを管理しようとする試みは間違いだということは歴史が証明しているのでJIRAのワークフローとトランザクショナルな処理を絡めようという発想はやめましょう。

というわけでBPMをしたいならBPM製品を使うべきです。

JIRAでBPMができるパターン


本格的なBPMには向きませんが、ちょっとした人間系フローと、システムの連携にJIRAは便利です。ざっと2パターン紹介します。

・おい人間やっとけパターン
弊社=株式会社サムライズムで活用しているパターンです。ソフトウェアの販売をしているサムライズムですが、ご注文頂いたライセンスを手配する作業は*だいたい*システム化しています。*だいたい*というのが肝で、システムで自動化できていない部分があるのです。
具体的には一定の割合で請求書の書面を郵送して欲しいというお客様に対して
・請求書を印刷
・3つ折りにして封筒に入れる
・投函する
という作業が発生します。こちらはMisoca APIとかを使えば自動化できるのですが頻度、分量としては多くないので人間が運用でカバーしています。
人間がやるべき作業は忘れてしまいがちなので、システムから自動的に課題を登録して作業の完遂を促しています。システムから課題の作成するには公式のJavaライブラリを使っていますが、Atlassian独自醸造Apache HttpClientライブラリに依存しており数多くの他製品と競合しますので皆さんがんばってください。REST APIを直接叩くのがいいかも・・・。

郵送が必要な場合、機械が人間に依頼するコード(㍿サムライズムの本物のコード)

・人間も機械も仲良くパターン
ワークフローに平行パスがなく、一部システムで処理をしたい部分があればちょっとしたBPM的にJIRAのワークフローを使えます。そしてシステムが処理するのは遷移中にWebhookを呼び出すのではなく、状態として定義するのが良いです。(たぶん。でも場合による)。
システム用にユーザーを一人割り当て、状態遷移のタイミングで担当者をシステムに割り振るように設定しましょう。するとシステム処理中、人間には「担当している課題」として見えないので安心ですね。システム側で処理がうまくいかない場合、リトライを重ねることもできますし、リトライ試行回数を超えたら「失敗しました」、みたいな状態に遷移させてもokです。
(BPM製品だとビジネスプロセスとしてリトライ回数や例外系へのジャンプの定義が出来たりします。JIRAでやる場合は自前で)

いかがでしたでしょうか。長々と文字だけで書き連ねてしまいました。JIRAは主に人間系の課題の管理に使うのに向いていますが、工夫次第ではシステムと人間の連携にも使えます。
あまりにも工夫が必要な場合はJIRAを適用すべき場面ではないかもしれません。うまいことやってください。

このエントリーをはてなブックマークに追加   

JJUG CCC 2016 Fallに参加しました #jjug_ccc #ccc_l6 #ccc_cd7

日本Javaユーザーグループ(@JJUG)が年二回開催しているカンファレンス、JJUG CCCの秋版、JJUG CCC Fall 2016に参加しました。

CCCはTポイントとは関係なくて「クロスコミュニティカンファレンス」=「様々なコミュニティが交われれば、Javaだけにこだわらずにね」、みたいな意。

今回はスポンサーとして、そしてスピーカーとしての参加です。スポンサーとしては沢山の人に自慢の、お気に入りツールのご紹介が出来て大変有意義でした。

ご立派に出来上がった弊社ブース

・受験勉強経験も留学経験もない日本人がJavaOneで英語で講演できるようになるまで
セッション1つ目。外資系の勤務経験が長かったり、JavaOneで講演したり、海外のベンダと取引していて「割と英語出来る」立ち位置を獲得している自分。
でもハーフでもないし、留学経験もない。しかも多くの人がガッツリ英語を勉強するであろう大学受験もしていない自分がどうやってここまで頑張ってきたのかを説明して参考にして頂ければ、というセッションで話をしました。

小部屋で20分のセッションは立ち見(というか座り見)が沢山の満席。

英語の上達に王道はたぶんなく、あくまで自分の場合何をしてきたかということを参考情報としてお伝えしました。日頃より伝えたい話だったので、沢山の方々に前のめりで聞いていただけて良かった!
また機会があればこの話はもっとして伝えたいです。

感想を含んだブログ:
JJUG CCC 2016 Fallに参加してきました! #jjug_ccc - Challenge Java EE !
JJUG_CCC 2016 Fallに参加しました! #jjug_ccc - 僕はここだ!


JJUG CCC 2016 fall 参加報告 - エンターテイメント!!



ステッカーはいつもながら好評!

・Javaエンジニアのキャリアを考えるパネルディスカッション
大谷さん(@johtani)の(と?)応募したセッション。モデレータとして主に話を聞く側として参加させて頂きました。
Java界隈のエンジニアを経て現在はクックパッドで人事部長をしている(@yoshiori)さん、Java関連で調べ物をすると必ずヒットするHishidama's Java Memoの(@hishidama)さんを交えての4人で臨みました。
それぞれに違うキャリアを築いており、三者三様(私の話も交えたので四者四様?)の話が出て大変有意義でした。違うキャリアながらも共通項も大いに見いだせて私自身も参考になった点が多くあります。

感想を含んだブログ:
JJUG CCC 2016 fall 参加報告 - エンターテイメント!!

タグ :
このエントリーをはてなブックマークに追加