マルチスレッド・２

ネットワーク関係の例を出して説明してください

メール送信システムを用いて解説する。ＤＭやメルマガ，情報通知等、大量のメールを送信するシステムについて、実例を基にした話。


■ 概要

ネットワークのイメージをかなり単純化してみた。本質としてはこんな感じ。

４つの SMTP サーバは負荷分散のためでは無く「特定の携帯電話キャリアに特化したSMTP（＋普通の）」と考えて欲しい。実際には到達率を高めるために外部のサーバを利用している。

さて、例によって設計を描く前に調査。ここで言う「調査」とは分析結果を見て、軽くテストアプリを作ってみること。
いきなり設計書をバリバリ書く人もいるけどね。凄いな…自分には無理なので、先にこういうもので色々やってみる（それから設計する）。


■ セッションタイムアウト

設計前のテストアプリ開発スタート！

まずはWebサービスから。配信先リストをクライアントから受け取り、ドメイン名からPC用とキャリア毎のメールアドレスを分離。すぐに出来たね。テストデータを用意して送信！

[HttpException]: 要求がタイムアウトしました

あ、そうか。Webサービスと言っても、クライアントからリモートメソッドを実行しているだけで、完了を待っている間にタイムアウトした。スレッド化して、出来るだけ早くメソッドの完了を通知してやるべきか。


■ プロセス分離

そうそう。こういう要件があった。

深夜にメールが届くと困るという人がいる。
特定グループのユーザーは夜間帯のメールを保留し、朝にまとめて送信する。

それならスレッドよりも、別プロセスの方が向いている。送信リストを XML でローカルに保存し、.EXE に引数（パス）を渡す設計にしよう。遅延についてはOSのタスク機能を使えば良い。

SMTPサーバの数× 100件（計400件）のテストデータを作って、送信実行！

クライアントにはすぐに完了が通知されるし、タイムアウトしない。でも、延々テストメールが届く…送信ウェイトが原因だ。
「同一のSMTPサーバから、連続して○○件以上のメールが送信された場合は受け取りを拒否する」なんていうメールサーバもあり、数件送る毎に数秒間ウェイト（休憩）を入れている。


■ スレッド

やっぱりスレッドも使おう。先に各SMTP用のコレクションを作っているわけで、この送信メソッドをスレッドプールで実行。

取り合えず速くなった。でも、これで数万件を扱うのは問題がありそう。
これはもうアプリ側の改善よりも「多くのサーバに分散する」というアプローチが必要。ついでにアプリ側で分散用のコレクションを作る際に、宛先ドメインがばらける仕様にしておくと良いね。


ネットワーク関係の例として。こんな感じで。

　

マルチスレッド

スレッド（Thread, ThreadPool）って、どういう時に使うんですか？

新人SEに聞かれたことがある。良い質問。技術を学ぶには「何でこんなものが必要なんだろう？」という疑問が不可欠。

さて、業務系ソフト開発でスレッド（非同期処理）を使う場面といえば…適当な例が見当たらない。ぱっと浮かぶのは「大量の帳票出力処理をスレッド化しておくと、出力中もオペレーション出来る」なんて事くらい。

あとはタイマー処理かな。スレッドでカウントしておいて、一定時間毎に画面のリフレッシュとか。あまり良い例では無いね。

こういう時は実例で説明するのが一番。下記は実例を基にした話。


■ 要件と問題

製造業の「発注先選定システム 企業評価編」といったところ。

原材料の仕入先や加工等の外注先（見積依頼先）を絞り込むシステム。
諸条件から検索を行うが、この時、結果リストは評価点（X)の高いものが上位に表示される。X は品質評価（A)，納期評価（B)，価格評価（C）の立方根とする。A,B,C は過去数年間のデータを、X は各評価の結果を基に日次算出する。

要件を確認したとき「各評価の算出式だけ分かってしまえば楽勝！」と、簡単に考えていた。

ところが実際にテストアプリを作って分かったのが「各評価算出には非常に時間が掛かる」ということ。各１時間かかるとして大体３時間。夜間バッチとは言え、販売管理の集計等が終わってから評価処理を開始すると…始業に間に合わない。

DBバックアップの時間も関係してくるし、どうしよう。週次にしようか？


■ スレッド利用

とにかくロジックの見直し。個々の評価算出については後にして、取りあえず全体最適化に注力。あれ？ 各評価って、互いに関連していないね。非同期で算出しても良いのか。むむっ！

それから、ハードウェア仕様を確認すると、評価算出に使うアプリケーションサーバの CPU は Xeon（Irwindale）で Hyper-Threading 対応。「せっかくのHT。活かさないと勿体無い」ということで、設計を見直し。

A,B,C 個々の評価算出メソッドをスレッドプールで実行し、結果を DataTable に書き込む形に変更。
処理が全部終わった時点で、この DataTable の企業コードをループ（評価点の計算）し、結果全体を一度に書き戻すことにした。

この結果、評価算出処理は本当に 1/3 の時間で完了。始業に間に合う。

これを応用すれば各評価算出をWebサービス経由で別サーバに任せ、結果セットを受け取って処理する様なことも可能。10倍の規模なら、そうするかも。100倍規模なら企業コード単位で評価算出サーバに渡す形として、１評価につき複数台をロード・バランシング！ ふぅー…カッコイイ


何の話だっけ？ マルチスレッド？
新人SEにはこの例を解説し「複数の結果セットで集計を行う場合、過程は非同期で算出して良く、スレッド利用が適している」と回答したかな。

　

Windows Vista で DVD

Windows Vista Business で DVD 書込み環境を用意した際の話。

DVD-R ドライブが少し古いもので、付属の PowerDVD や Nero が Vista では動作しなかった。バージョンアップも面倒なので、何か適当なものが無いか探してみた。

【使用したソフトウェア】

　MPEG2 コーデック

GPL MPEG-1/2 DirectShow Decoder Filter

　プレーヤー

AVS DVD Player

　DVD ライティング

ImgBurn

非常に良い感じ。

ImgBurn は比較的新しいドライブや Windows-64bit に対応するため「サーバからログを直接 DVD-R に退避したいよ」なんて時にも使えそう。
　

Google Chrome

軽い！ 使いやすい！

未だ BETA ながら、完成度は非常に高い。Gmail もブログの更新も、軽くて作業しやすくなった。

もう、標準ブラウザもこれで。

http://www.google.co.jp/chrome/intl/ja/features.html
　

CYBERNET All-in-One PC

http://www.cybernetman.com/default.cfm?DocId=602


昔、PCと言えば大抵はこんな形をしていた。
Apple，Amiga，Commodore，MSX，NEC PC，富士通 FM…etc.

何だかその時代を感じさせる「古くて新しいデザイン」のPC。
　

モバイル機器

明日に備え、PC，電話，PDA等々の充電をセット！

冷静に考えてみると「殆ど同じで少しだけ用途の違うもの」を多数持ち歩いている気がする。最近、やたらとカバンが重い。

思い切って、ひとつにするとしたら何だろう？
電話も古くてボロボロ。いい加減、買い換えよう。

Vintage cell phones on eBay

　

※ 写真はイメージ
　

PCの将来象？

PCでいう「本体」が携帯電話に集約されてしまい、入出力デバイスの部分だけが家庭やオフィスに用意されるかも知れない。

「電話をトイレに落としてしまった！」という際に、何も出来なくなってしまうのは痛すぎるけど。

The Prada phone by LG

LG KE850
http://www.lge.com/products/model/detail/ke850.jhtml



日本では未発売。
「良く似たもの」の方が先に発売されるかも知れない。

Sun Fire

Sun Fire X2200 M2







早く導入したいな。
でも、何故 UltraSPARC IIIi では無く AMD Opteron 指定？
　

プロジェクトのコードネーム

ソフトウェア開発プロジェクトでは名称から内容を想像できない様、コードネームを付けておくのが一般的。例えば「○○社のリコール製品管理システムのプロジェクトでさ～」なんて事を外でうっかり喋ってしまうと…。
そう。コードネームをつけ、それで呼び合うことを習慣化するだけで、安全性が大幅に向上するのだ。素晴らしい！

しかし、コードネームを考えるのは大変な作業。命名者のセンスが問われるし、変な名前をつけると「プロジェクトに愛着を持てない」なんて言い出すメンバーも居る。

１つのプロジェクトを複数のサブプロジェクトに分割する際など、命名だけでノイローゼになりそうだ。何かこう「命名者のセンスに左右されず、良質なコードネームを生み出す方法は無いか」と悩んでいた。そして、思いついたのがこれだ！！

東京都中央卸売市場

肉。正確には肉の部位。これで、少なくともサブプロジェクトの問題は解決。
「情報系は今一番脂の乗った部位だから【ばら】だね」とか、「基幹部分は【サーロイン】と呼ぼう」など、各担当者も楽しみながらプロジェクトに取り組むことが出来るはず。

プロジェクトそのものについては何か、牛らしい名前を付けておき、部位（サブプロジェクト）とはネームスペースの要領でつないでおくと良いね。

例）　会計２号.リブロース.300g

部位名が分かれば豚や鶏，マグロでも良く、色々応用が利きそうだ。早速、あのプロジェクトに…でも、今回はやめておこう（ちょっと恥ずかしい）。
　

machine.config

Webサービスでパフォーマンスの低下、およびデッドロックが発生

http://support.microsoft.com/kb/821268/ja

ASP.NETアプリケーションの場合に限らず、Webサービスの開発をしていると似た現象に苦しめられるときがある。また、一台のサーバで大量のWebアプリケーションをさばく様なASP環境ではワーカー／ポート スレッドの数が常に気になるところ。

「○○のサーバも危ないよ。ちゃんと設定してるか？ してないだろ！」

と、どこかから声が（何度も）。不安に苛まれ、実際に machine.config を確認してみると

<processModel autoConfig="true" />

あれ？ autoConfig…Windows Server 2003だから？

ちゃんと計算して設定するべきか迷ったけど、やはり自動設定の方が信頼できそうな気が。実際に、このサーバでスレッドが不足したことは一度も無いので、そのままに。

取り合えず良かった。