2008年10月のあいそるニュース
メールサーバの再送
2008-10-30 08:19
メールを送信する際に宛先のサーバに一時的な障害があった場合は、実は送信元のメールサーバはすぐにエラーメールを返さずに
「キュー」に一旦溜めて何回か再送を試みています。
※メールアドレスに誤りがあった場合は送信元にエラーメールがすぐに戻ってきますが、この場合の一時的な障害とは
ネットワークの障害であったり、宛先のメールボックスが溢れていたり、メールサーバそのものがダウンした場合等になります。
何回か再送を試みながらそれでもエラーが続き、それが一定期間繰り返されると ようやくエラーメールが送信元に送られます。
このメールキューに保存され再送が繰り返されるという期間は、サーバによって様々ですが
１週間とか２週間に設定されていることもあります。
一般の人はメールを送信した際に、すぐにエラーが返ってこなければ正常に相手にメールが送られたと思い込んでしまいます。 しかし、宛先のメールサーバの状態によっては実は再送を繰り返しているケースがあるので注意が必要です。
メールがビジネスで使用されている昨今では、１週間も遅れてメールが届くくらいなら送信元にすぐにエラーを返したほうがマシです。
そこで多くのメールサーバは、再送が繰り返される期間をデフォルトよりも短く設定しています。弊社のメールサーバも数時間に設定しております。
しかし、未だに世の中には数日や一週間という設定となっているメールサーバも存在します。
実際、数年前になりますが弊社が保守していたシステムで、 自動的にメールが送信される仕組みがあったのですが宛先のメールサーバに障害があり、 その間こちらのシステムが利用していたメールサーバは再送を繰り返し一週間後にユーザにメールが届いた事がありました。
メールを受け取ったユーザは、逆になぜ一週間前ものメールが今頃になって届いたのかと驚かれたと同時に システムの不具合と見なされて大変なクレームをいただきました。 根本原因は宛先のユーザが利用しているメールサーバに障害があったことが原因であるにもかかわらず、 送信するこちらのシステムの不具合とみなされてしまい、説明して理解を得るのに大変苦労しました。
上記のようなトラブルを招くだけではなく、キューの滞在時間が長いとそれだけ再送を繰り返す為、
再送メールがどんどん溜まりサーバに余計な負荷もかかります。
下図は以前弊社のメールサーバで、再送が繰り返される期間を２日から数時間に短く再設定した直後のメールサーバのキューの量です。
再設定した直後からメールサーバに溜まっていたキューの量が激減しています。
つまりこれだけ再送を繰り返していた余計なメールが溜まっていたことになります。
Posted by T.S
キャリアパス
2008-10-27 08:00
就職活動を迎えた大学生が「やりたいことが見つからない」という理由でフリーターを選択するケースが多いのは、 「自分が本当にやりたいことを見つけてから就職しなければならない」という固定観念が強すぎるからだと思います。
フリーターを選択するくらいなら、失敗を恐れずに少しでも興味がある職業に飛び込んで、経験して試してみることが何より重要です。
理想を言えば、学生時代に沢山の経験をして、失敗もして、本当に自分が向いていてやりたい職業を見つけられれば
それに越したことはありませんが、見つけられない人も少なくないでしょう。
フリーターを選択しないまでも、多くの学生は実際に就職してそこで働いて経験するまでは、 自分が就く職業に関して本当の理解は得ていないと思います。
私たちシステム開発者（ＳＥ）という職業も同様で、入社前から明確なビジョンを持って入社してくる新卒は少ないと思います。 無論、それなりのイメージは持っているでしょうが、経験もしていないのに私たちが具体的にどのような仕事をしているかを 細かく理解して入ってくる人は少ないでしょう。
それでも、Webに興味がある、システムを開発したい、チームでプロジェクトを進めたい、という熱い想いで入社してくる新卒は
可能性に溢れていると思います。
そのようにやる気は満ちているが自分の将来のビジョンがあやふやな新人にとって理想的な職場とは、
将来に向けてその職業に関する多くの選択肢があることと、素晴らしい先輩・素晴らしい上司がいることだと思います。
ある程度の方向は絞れても、自分はその中でどのような役回りに向いていて、何をしている時が楽しいかは、実際に経験してみないと絶対に分からないものです。 新卒は入社してから数年は、様々な仕事を経験しながら本当に自分に向いていて好きな役割（職種）を見つけていくものだと思います。 その為には、多くの経験が出来る環境でなければなりません。多くの経験が出来る職場ほど、その人の可能性は広がるのです。
入社して数年が経過し自分に向いている役割が少し理解できた頃、多くのＩＴエンジニアが次に悩むのがキャリアパスです。
数年のシステム開発の経験から自分の具体的な未来像を定め、そこに向かうキャリアパスを構築するのはそう簡単ではありません。
キャリアパスを定めるのはそれ専門のセミナーがあるくらい奥深いことですが、
自分の未来像を見つけるキッカケの一つのは素晴らしい先輩や上司に巡り合い「あのような人になりたい」と強く憧れることだと思います。
職種を見つけるのではなく、目指す人を見つけるのです。
どうすれば憧れの人のようになれるか、と思いを馳せることにより自然とその人なりのキャリアパスが形成される事もあります。
その為にも、憧れの対象となる人物が沢山いる職場は若手にとってはラッキーな事です。
最後に、キャリア採用のページでもご紹介している通り、弊社は
ＩＴエンジニアにとって沢山の選択肢があり、また多数のスペシャリストがそろった会社です。
新卒の方もキャリア採用の方も、少しでも弊社に興味を持っていただければ
気軽にお問い合わせいただければと思います。
Posted by T.S
MRTGによるリソース監視
2008-10-24 08:09
もはや定番ですが、サーバのリソース監視ツールはMRTGを使用しています。
MRTGとはサーバのリソース情報をグラフ化してくれるツールです。
サーバの状態を一時的ではなく継続的な視点で分析するには便利です。
ネットワークトラフィックやディスク容量、空メモリなど様々なリソースを監視していますが、
一番気になるのはなんといっても負荷（ロードアベレージ）です。
先日のことですが、あるサーバが上図のように負荷（ロードアベレージ）が一時間毎に一時的に高くなることが認められまして 少し調査してみました。まぁここまでハッキリ「一時間毎」という波形が出ると、原因は当然Cronによるなんらかの定期処理である事が疑われますので、そのセンで調べたらあっさり分かりました。
このサーバはとあるホスティング会社から借りている専用サーバなのですが、管理ツールからバーチャルホストを追加すると 自動的に様々な設定がなされます。その中の一つとしてAWStatsというログ解析ツールの設定も自動的にやってくれます。 このAWStatsのログ解析処理が一時間に一回、同じ時間に実行されるようにCronに設定されるわけです。
これでは例えばバーチャルホストを５つ追加すると、毎回同じ時間にログ解析処理が５プロセス同時に実行されることになります。 ログ解析はファイルＩ／Ｏと文字列解析の大量処理になりますので、これではロードアベレージが急上昇するのも当然です。
Cronの設定ファイルを手動で変更し、とりあえず各バーチャルホスト毎のAWStatsのログ解析処理を少しずつズラして実行するようにしたところ上記のように負荷が平準化されました。
今後このサーバでバーチャルホストを追加した場合は、Cronに自動的に出力されるログ解析の処理時間を手動でズラす必要がありますね。
というより、一時間に一回のログ解析処理が必要なのか？という疑問もあります。多くとも一日２回で十分なんじゃないか、と思いますが
その辺はサーバの負荷の様子を見て調整しようと思います。
最近のサーバ管理ツールはWeb上から設定が何でも出来てしまい、面倒な作業も全てやってくれて便利ですが、 今回の件に関してはバーチャルホストに追加したらCronにログ解析処理を直接追記するのではなく、 Cronから呼ばれるシェルスクリプトを一つ用意して、 そこに対してログ解析処理を追記するようにすればよかったのにと少々残念に思いました。
Posted by T.S
ドメインとFQDN
2008-10-22 08:00
インターネットの世界での「ドメイン」という言葉は、誰でも聞いたことがあると思いますが それを正確に説明できる人は少ないと思います。 「ドメイン」だけでなくＵＲＬやＦＱＤＮやＤＮＳなどの関連する用語も同様です。
ドメインの話になると、必ず階層構造となっているＤＮＳの仕組みから説明が始まってしまいますが 今回はそれは割愛して、まずは正しい用語を使っていただく事を目的に間違えやすいポイントを踏まえて簡単にご説明しようと思います。
上記は弊社のオフィシャルサイトのＵＲＬになります。 これを例にして各構造とその名称をそれぞれ説明します。
1.ドメイン
図で1の部分をドメインといいます。7をドメインを言う人もいますが、厳密には1までをドメインとして扱うのが一般的です。
2.トップレベルドメイン
2はドメインの中でもトップレベルドメインと呼ばれます。最も上位のドメインのことで、ＴＬＤと略されます。
因みに最も有名なＴＬＤはcomですが、これはCommercial（コマーシャル）の略なのだそうです。
現在ではＴＬＤの数は250以上(多くは国や地域をあらわすCountry Code Top-Level Domain)あります。
ちなみに最近、トップレベルドメインの自由化というニュースが流れました。
今まで、セカンドレベルドメイン以下は各団体に自由に申請できたりしましたが、トップレベルドメインも
自分で決められるようになるとは驚きです。その場合、例えば弊社（プロフェッサ）が"professa"という
トップレベルドメインを申請すれば、http://www.professaといったＵＲＬを作ることも可能ということになります。
早ければ来年にも運用が開始される予定とのことで、今後の動向が気になります。
3.セカンドレベルドメイン
3はセカンドレベルドメインと呼ばれます。文字通り２番目のレベルのドメインの事で、ＳＬＤと略されます。 基本的にＳＬＤはＴＬＤを管理する団体によって規定が異なります。 例えば、JPというトップレベルドメインは日本レジストリサービス（JPRS）という組織が管理しています。
4.サードレベルドメイン
サードレベルドメインは必ずあるとは限りません。 例えば、www.pros-access.jpは、"pros-access"がＳＬＤであり、"www"はホスト名に なりますので、サードレベルドメインは存在しません。
5.サブドメイン
5の部分は大きくまとめてサブドメインといいます。つまり、ＴＬＤとホスト名(後述)の間に存在する ドメインは、全てサブドメインと表現することが出来ます。
具体的にwww.pro-s.co.jpの例で言うとcoはjpのサブドメインであり、pro-sはcoのサブドメインという言い方をします。 ＳＬＤのことをあえてサブドメインと表現することはありませんが、言葉の定義で言うとサブドメインと表すこともできるということです。
6.ホスト名
少しドメインのことを知っている人が最も間違え易いのがホスト名です。 6は正確にはホスト名と言いますが、これをサブドメインと言ってしまう人が多いようです。
ホスト名というのは、そのドメインの中の論理的なサーバを表します。
そもそもドメインとは日本語では領域という意味ですので、ある領域の中に存在する
サーバの名前がホスト名です。
例えば弊社のpro-s.co.jpといドメイン（領域）の中にWebサーバ2台とFTPサーバ1台とDBサーバが あったとし、それぞれ以下のようなホスト名をつけたとします。（図参照）
Webサーバ1・・・web1
Webサーバ2・・・web2
FTPサーバ ・・・ftp
DBサーバ ・・・db
すると、ホスト名の後ろにドメインをつなげて以下のように表すというわけです。これをＦＱＤＮといいます（後述）。
web1.pro-s.co.jp
web2.pro-s.co.jp
ftp.pro-s.co.jp
db.pro-s.co.jp
弊社のオフィシャルサイトがwww.pro-s.co.jpであるように、Webサーバはwwwというホスト名をつけるのが一般的です。 しかし、必ずそうしなければならないという決まりはありません。 例えば、当Webサイトはisolというホスト名をつけています。 これは、弊社のオフィシャルサイトが一般的なwwwというホスト名を割り当ている為、 他のホスト名を割り当てざるを得なかったということです。
実際にはＤＮＳサーバの設定で、物理的に同じサーバに対して複数のホスト名を 割り当てたり、負荷分散を行っているシステムでは、一つのホスト名に実は 沢山の物理的なサーバが動いていたりと、ホスト名と物理的なサーバは一対一にならないことが 多いのですが論理的な考え方としては、上図の通りあるドメインに存在するサーバを特定するのが ホスト名になります。
7.ＦＱＤＮ
ホスト名とドメインをつなげたものをＦＱＤＮ(Fully Qualified Domain Name)といいます。
通常、インターネットＷｅｂサイトを現すＵＲＬはhttp://＋ＦＱＤＮとなります。
しかしここで一つ落とし穴があります。 例えば、有名なSNSのミクシィ(http://mixi.jp)の"mixi.jp"はＦＱＤＮでしょうか？ "mixi"はホスト名ではなくＳＬＤなので、答えとしては"mixi.jp"はＦＱＤＮではなくドメインです。
ＵＲＬはhttp://＋ＦＱＤＮ（＝http:// + ホスト名 + ドメイン）になるという説明をした際に 若手からhttp://mixi.jpはどうなのかと質問をされたことがあり、それを説明するのに苦労した経験があります。
技術的に言うと、ＤＮＳサーバのゾーンファイルにホスト名の無いAレコードを定義すると このような状態になります。実際、弊社のオフィシャルサイトはwww.pro-s.co.jpですが pro-s.co.jpでもWebサイトにアクセスできます。弊社のＤＮＳサーバにホスト名の無い Aレコードを設定にしているからです。
このようなＵＲＬを主として公開しているWebサイトも多数あります。 ただ、一般の方にホスト名の無いAレコードと言ってもよく分からないと思いますので このような設定に関して分かりやすい解釈の方法があります。
以下からは私の個人的な解釈であり、一般的な考えではありませんのでご注意ください。
この問題は、ホスト名として空文字("")を定義しているのだ、と考えると理解しやすいです。
例えば、先ほどの"mixi.jp"も解釈によっては空文字""のホスト名がついたＦＱＤＮと捕らえることが出来ます。
ホスト名＝""
ドメイン＝"mixi.jp"
ＦＱＤＮ＝"" + "mixi.jp" → mixi.jp
このように、Webサーバのホスト名を空の文字("")と捕らえれば、mixi.jpも
立派なＦＱＤＮと考えることも出来ると思うのです。
※技術的にはホスト名に空文字("")を付けるということは出来ないので、
あくまでも一つの考え方として捕らえてください。
8.ＵＲＩ
8も曲者です。上記のいままでの文章では、私は8の事をＵＲＬと表現してきました。
これはＵＲＬという言葉が非常に一般的で、読み手にとって分かり易いから使用しました。
ＵＲＩやＵＲＬに関して一般的な解釈は、右図のようにＵＲＩはＵＲＬを包括する概念であると 言われておりましたが、WWWの標準化団体であるW3Cでは今現在はＵＲＬは非公式な呼び方であるとしています。
これらの主張に則ると、8はＵＲＩと呼びます。
とはいいつつもやはり未だにＵＲＬという呼び方が一般的であり、論文等の学術的な文章でなければ 無理にＵＲＩと呼ぶ必要はないと思います。
Posted by T.S
ひらがな入力とローマ字入力はどちらが速いのか
2008-10-18 21:32
私（文の筆者）は、ひらがな入力で日本語を入力します。 仕事ではプログラム等のコーディングも行いますので、ローマ字入力もそれなりに出来ます。
ちなみに何故ひらがな入力なのか、とよく聞かれるのですが初めてキーボードに触れたのが小学生の頃だったので その頃はローマ字そのものを知らなかったからだと思っています。
では日本語を入力する場合、ひらがな入力とローマ字入力はどちらが速いのでしょうか。
ひらがな入力の方がキーを押す回数が少ないからひらがなの方が速いとおっしゃる方はよく聞きます。
何かで読みましたが、確かにローマ字入力はひらがな入力と比較してキーを押す回数は１．５倍くらいなのだそうです。
私の意見としては、ひらがな入力もローマ字入力も達人になると速さにそれほど違いが無いと思います。
確かにひらがな入力は押すキーは少ないですが、それだけキーボードで使用するキーの種類が物理的に多いです。 キーボードの一番上の段や右側まで広範囲に広がっている為、指がそこに移動するまで時間がかかります。
また、ひらがな入力はShiftキーや濁点（゛）や半濁点（゜）で、両手の小指を多用する為 それなりに小指が器用にならないと、速い入力は出来ません。
例えば「ホームページ」という単語はひらがな入力では非常に難易度が高いです。 6文字ですが、8回キーを押します。そして、そのうち7回は右手小指を使用するのです。
マスターするまでは難易度の高いひながな入力ですので、日本語の入力でひらがな入力をする人は圧倒的に少ないです。 実際私はこの業界に十年以上様々な現場で働きましたが、ひらがな入力が「出来る」という人ではなくそれを主として使っている人は 今まで一人か二人くらいしか出会っていません。
それ故、他人のキーボードを少し借りるときは必ず入力方式を切り替える必要があるし、借り終わった後にそれを元に戻すのを忘れて ぶーぶー言われたりして、正直あまりメリットを感じたことはありません。
Posted by T.S
システム開発と喫煙
2008-10-16 08:32
システム開発は頭を使いストレスが溜まりやすい仕事なので、一定のリズムで一定の時間だけ
頭を休めることが出来る「喫煙」を行う開発者は非常に多いと思います。
それ故、大規模システムの開発プロジェクトの現場では必ずと言っていい程喫煙室があります。
複数の会社が集まり、見ず知らずのエンジニアが共同で進める大規模なプロジェクトでは、
休憩という理由の他に、喫煙所が一つの交流の場でありまた意見交換の場としても使われているようです。
大規模プロジェクトでは喫煙室は根回しを行う場としてもよく使われます。「さっき喫煙室でネゴっといたよ」なんてのはよくある会話です。
重要な決定をおこなう会議でも、実はステークホルダーにより事前に喫煙室で結論が決められているなんてこともよくあります。
これは喫煙室は外から密閉された場所であったり、狭い部屋であることが多いため、ヒソヒソ話にはもってこいの空間だから
とも考えられます。
そのような風習に取り残されたくない為か、リーダークラス以上の人は全員タバコを吸っているような現場は沢山あります。
また職場によっては喫煙以外に合法的な休憩を取りづらい職場もあり、非喫煙者が定期的に休憩をしたいがために
喫煙を始める人もいるようです。
タバコそのものが昔から好きな人はともかく、仕事の環境や文化に影響されて体に害のあるタバコを吸い始める人がいるとすれば、
それは良いことではありません。そんな環境や風習は改善した方がよいでしょう。
さて弊社はどうかと言いますと、まず喫煙自体はまったく否定していません。
喫煙が好きな人は思う存分吸えるように、上の写真の通り小さな喫煙ルームが用意されています。
タバコ１本吸う事により、気分転換になり頭も整理され、仕事がはかどるのならば大いに結構なことです。
ただしそれだけでは非喫煙者にとって不公平になりますので、非喫煙者も喫煙者と同様に休憩が出来るように、
弊社の社長は色々と考えたようです。例えば社内にはダーツや卓球台が常備してあります。社員は好きなときに、これらの遊具を
使用して休息や気分転換を行って構わないことになっています。（さすがに仕事中に卓球を始める人はいません）
弊社は社内でお互いを知り尽くした社員だけで開発を進めているため、わざわざ喫煙室でヒソヒソ話をする必要はありません。 意見交換は自分達の席ですればよく、もちろん根回しなんかするよりは、会議で自分達の意見をぶつけます。 よって、本当に喫煙が好きな人意外はタバコを吸っている人はいないと思います。
ＩＴソリューション部の喫煙者の割合を計算してみましたが、喫煙者は28%ですね。同業他社から比較すると 少ないほうかもしれません。ちなみに、私たちの部長はかなりのヘビースモーカーです。
Posted by T.S
nagiosによる障害通知方法の検討
2008-10-12 11:15
弊社は多数のサイトを保守しておりますが、サービスの監視ツールはnagiosを使用しております。
nagiosは現在ではサーバ監視のスタンダードなツールであり、例えばWebサービスに異常があったり サーバに異常な負荷がかかったりハードディスクの容量が一定の閾値を越えたりした場合に、管理者に通知してくれます。
一般的には通知手段はメールなのですが、もっとシステマチックな通知方法はないものかと思い、 下図のパトランプを導入して障害が発生した場合はサイレンとランプが鳴りまくる仕組みを 取り入れようとかなり真剣に悩んだことがあります。
DN-1000R-3R 株式会社アイエスエイ http://www.isa-j.co.jp/product/keiko/keiko2/
しかし、弊社はいつくものサイトを24時間保守しており休日や夜間に障害が発生した場合は、社外からリモートアクセスにより 復旧作業を行うケースもあります。よって、会社に誰もいない時に障害が発生してもただ無人の会社がウルサイだけです。
上記のパトランプはそれなりの金額ですので、上司に稟議書を出す勇気さえ湧いてこず結局あきらめました。 よくよく考えるとやはり携帯電話へのメールがシンプルでコストがかからず効果的な 通知方法です。今のところ、一般人が24時間肌身離さず身近に持っているものといったらやはり携帯電話ですので、 結局弊社の場合も障害発生時にはサーバ管理者の携帯電話へメールが配信されるようになっています。
Posted by T.S
Radiant CMS
2008-10-07 21:11
当WebサイトはRuby on RailsベースのRadiantをCMSとして採用しております。Radiantはシンプルで余計な機能は含まれておらず、CMSだけの機能を追及した非常に使い勝手の良いツールです。
しかしながらRadiantはMovable Type等と比較するとメジャーとは言えず情報が少ないため最初は少し戸惑いました。
専門書があるわけでもなく、英語が得意ではない私たちはRadiant CMSの本家の英語サイトだけではなく、以下のWebサイトをよく拝見しました。
- Radiant CMS Japan ・・・ Radiant CMSの日本での普及を目的としたサイト
- AIRS Labs ・・・ Radiant CMS Japanを運営している会社エアーズの技術紹介サイト
- Radiantタグをまとめてくださったある方の日記
特に、AIRS LabsにあるRadiant CMSでGoogle sitemap.xmlに対応するというテクニックは素晴らしく、当Webサイトでそのまま利用してます。
ちなみに、当Webサイトの構成は下記の通りです。
- Red Hat Enterprise Linux ES3
- Apache HTTP Server 2.0.46 + mod_fastcgi 2.4.6
- Ruby 1.8.6
- Radiant CMS 0.6.9
- MySQL 4.1.11
RadiantはトップページのURLの後ろに/adminを付けると管理者のログインページが表示されます。そしてそのログインページの下部にはRadiantのバージョンが表示されますで。この方法でRubyのオフィシャルサイトのRadiantのバージョンを確認すると、0.5.2です。まだバージョンアップしないのかな、とかいつも気になっちゃってます。
尚、私たちは社内でRadiantを「らでぃあんと」と呼んでいましたが、ネットで調べると「れでぃあんと」とか「れいでぃあんと」と書かれていますね。そういえばnagiosがまだマイナーだった頃、正確には「なぎおす」なのに私たちは「ねいじうす」と呼んでいた時期がありましたが、そんな事を少し思い出しました。
Posted by T.S
恵比寿まで散歩
2008-10-02 13:15
弊社は白金台に位置しておりますが、昼休みの時間帯に恵比寿まで散歩をすることが出来ます。
といっても、12時に昼休みのチャイムが鳴ったら即弁当を食べ、12時15分に会社を出て競歩のようなフリフリ歩きで
散歩に出かけ、汗びっしょりでギリギリ12時57分に会社に戻って来るというチャレンジングなコースです。
そんな慌ただしい散歩を時間軸に沿って御覧ください。
Posted by T.S
