つれずれなるままの開発日記(最近はFlexばかり..)

Archive for 2010/2/27

今回は、airxmailのちょっと変わった使い方とでもいうのでしょうか？
（airxmailの説明はこちらをご覧ください。）

まあ、技術的にはSMTPでメールを送っているだけですが、こんなこともできますよーという一例の紹介です。

最近、Google バズというものがあるらしく、そこにAirxmailを使ってバズって（っていうの？）見ました。

と実は、これ簡単。
前回、「airxmailでGmailを使ってメールを送信する」の応用です。

といってもほとんど同じ、変わるところは以下の２つ。

１）宛先を buzz@gmail.comにすること。
２）メールのヘッダの文字コードをUTF-8にすること。

さて、

sender = new SMTPSender();
sender.setParameter(SMTPSender.HOST,"smtp.gmail.com");
sender.setParameter(SMTPSender.PORT,465);

//  SMTP-AUTHの使用
sender.setParameter(SMTPSender.AUTH,true);
sender.setParameter(SMTPSender.USERNAME,username);
sender.setParameter(SMTPSender.PASSWORD,password);

// STARTTLSの使用
sender.setParameter(SMTPSender.SOCKET_OBJECT,new com.hurlant.crypto.tls.TLSSocket());

は前回と一緒。
ここからが、ちょっと違う。

AirxMailConfig.setDefaultBodyCharset("UTF-8");
AirxMailConfig.setDefaultHeaderCharset("UTF-8");

var mimeMsg:MimeMessage = new MimeMessage();

var from:INetAddress = new INetAddress();
from.personal = "おれじゃ";  //  特に何も反映されないようですが・・・
from.address = this.fromEmail;

mimeMsg.setFrom(from);
var toAddr:INetAddress = new INetAddress("buzz@gmail.com","buzz");
mimeMsg.addRcpt(RecipientType.TO,toAddr);
// set mail subject
mimeMsg.setSubject("初めてのBuzzzzzzz! From airxmail");
mimeMsg.setTextBody("");  //  ここで、本文はなくても、空で設定が必要。現在、airxmailのバグ

sender.send(mimeMsg);
sender.close();

ということです。

AirxMailConfig.setDefaultBodyCharset("UTF-8");
AirxMailConfig.setDefaultHeaderCharset("UTF-8");

の２つで、本文とヘッダのデフォルトの文字コードを変えることができます。

もしくは、サブジェクトだけの文字コードを変えるのであれば、

mimeMsg.setSubject("これでもだいじょうぶだよー。Buzzzzzzz! From airxmail","UTF-8");

でも、問題ありません。

今日は、クラウドの構成、事例を聞いてきた。

そこで、あれ、ちょっと待てよ、「そもそもクラウドになったらロードバランサーって必要か？」
ということを思った。
っていうか、必要になるようにしか構成を結局組めないのか？というのが本音だ。

ただ、WEBのコンテンツを提供しているようなメディアは除外していただきたい。
対象は、いわゆるSIerにハード構築を依頼するようなレベルの話だ。

（ただ、自社ですべてやっている場合なら、必要であれば、自分たちでロードバランサーもどきなんて作ってしまえとも思ったりもする。それで充分なのだから。）

あくまでもこれからの前提は私が見てきたサーバ構成ですが、たいていはネットワーク構成の教科書にあるような構成なので、
多くのケースが当てはまるのではと思う。

さて本題にもどり、なぜ私たちのサービスにはロードバランサーが必要なのだろうか？
冗長性を・・・・２重化を・・・・

と、こんな感じの答えが聞こえやしないだろうか？

じゃ、クラウドでハードが壊れることをあまり考慮しなくても？やっぱり？いる？

ロードバランサーがあれば、高負荷にも耐えられるじゃないか？

でも、じゃ、高負荷でボトルネックになるDBは、それ以上にロードバランスができるようなDB設計になってるの？
っていうか、DBは１つしかないですよ。
あっても、故障時に切り替えられるようになっているだけじゃないですか。
（わたしは、サービスをやるときにはテーブルを移動できるようにするため、基本的にリレーションははらないが・・・・、
昔、遊びで、１つのシステムのコンテンツのDBがDB2と、MySQLとPostgreSQLに分割してって遊んだことがあるなー。
いや、遊びといってもテストですよ。テスト。）

じゃ、WEBも故障時に切り替えられればいいんじゃないの？そのレベルでいいのでは？
これは思えば、「TOC：チェンジ・ザ・ルール」で言っていたケースだ。

クラウドにより制約がなくなった。もしくは、無視してもいいようになってきた。
にも関わらず、相変わらず、構成は昔のままなので、その対策であったポリシー自体が今度はボトルネックになってしまうのだ。

（というか、個人的には、ロードバランサがあり、また、WEBの多段層化のおかげで、
その後工程でとまどっているにも関わらず、次から次へとリクエストを受け付けて中間層でパンクしてどうにもならない。というケースをよく見た。
まあ、要するにアプリがバグっているのだが・・・ApacheやDBにほぼバグは発生しないことを考えればしょうがないが・・・
ただ、だったら、WEBでリクエストを絞って受け付けないほうがまだ顧客のためだ！という思いもある・・・）

私の今のクラウドの理解が正しければの話ですが・・・・・
いやー、このあたりが本当かどうかを実際にためしてみたいものですが・・・・