社長のブログ

20 件のうち、 1 件目から 10 件目を表示します。 1 2

drupal から symfony へ

2月の初めに、プロバイダのサーバーが更新されたのをきっかけに、drupalの調子が変になった。
drupalのバーションアップなども重なっていて、原因がいまひとつよく判らなかったので放置していたのだけれど、いつまでも放置していくわけにもいかないので、symfony で書き直してみた。

とりあえずは、元と同程度にはなったと思う。

年末・年始

去年は、あちこちでディスクが故障するトラブルがあって、余計な出張がいくつかあったけれども、今年は幸いそういうトラブルはまだない。
世間が休みに入ってしまうこの時期は、変なアクセスを試みようとする連中の一番活発な時期なわけで(なにしろ、少々ヘマをやっても3日から一週間くらいは無監視の状態のサーバーがいくらでもある)、サーバーの面倒を見ている側としては、少しばかり心落ち着かない時期でもある。

まあ、「何もないのがよい便り」というのを一番実感する時期だ。
よいお年を。

クラウドに移行しやすいものとそうでないものと

WEBなどは、最初から外部サーバーで運用するのが当たり前なように始まっているので、これを敢えてクラウドと呼ぶほどのこともないし、クラウド化しにくい部分が考えられるとすれば、社内システムと密に結合しているような形態の場合に限られる。
外に出したい部分と外に出したくない部分をうまく分離できない場合は、全部を外に出すか、全部を内製化するしかない。

もう一つのメジャーなアプリケーションであるところの、メールシステムとなると、ちょっと微妙になってくる。社内で運用しようと、外部で運用しようと、imapプロトコルと webmailの組み合わせのユーザーインターフェースに大した違いはない。外部に置けば多少レスポンスタイムが悪くなるけれども、最近のブロードバンドの状況を考えれば、まあ我慢できないほど遅いわけでもない。
外にメールサーバーを置くことの不安といえば、一つは機密性に関すること、もう一つは障害耐性に関すること、この二つに尽きる。データを外に置けば「誰かに読まれてしまうのでは」という不安を消すことはできないし、「データが無くなったらどうしよう」という不安も残る。
もちろん、セキュリティを高める工夫をすれば、社内と同程度の機密性を確保することは可能だけれども、それはすなわち運用の手間の増加を意味しているし、クラウド化のメリットを打ち消すことにもなる。データ紛失の可能性もおそらく数値的には外部に置いた方が小さいのだろうが、社内であればいくらでも作れるバックアップが、外部サーバーでは作成しにくいことと、無くす原因が自らであればあきらめも付くが、外部が原因では納得できないということだろう。これもバックアップ体制を別個に講じれば避けることはできるだろうが、それもまた運用費用の増加を招き、クラウド化のメリットを打ち消す結果となる。

結局は、何に重きを置くか、というごく当たり前の結論に達するわけだが、データ流出のリスクをどう評価するか... 限りなく 0% に近くなければいけないのか、それとも、0.1% ならダメで、0.01% ならよい、という話なのか... その辺を定量的に評価できないと、始まらない話だな。

局所最適化

よく陥りやすい落とし穴に、局所最適化 というのがある。
簡単に言えば、「今は、Aの状態で、Bの状態になると、Bの方がAよりこれだけメリットがある。だから、Bに移行しよう。」という決断の積み重ねで行く先は必ずしも最適な状態ではない、ということ。

目先を考える範囲では、Bに移ることには少なくともデメリットはないので、決断の期限が迫っているときには、エイヤっと実行してしまうことが多いし、それを非難する人も誰もいないわけだ。

卑近な話だと、こっちのプロバイダだと 500円/月の費用が掛かって、自社サーバーだと、電気代が 600円/月掛かる。メインテナンスの手間は大して変わらない。
なんてときに、もう自社サーバーなんて流行らないよ、クラウドの時代だよ、と自社資源を外部に移していくわけだ。

実際、当社のこのサイトも今は社内には置かないで外部に置いてあるわけだし。
( もう、サーバーを自社内で運用することが、技術的なステータスでも何でもなくなっているという事情もある。)

フリーになったPC-Unixを使ってサーバーを構築しようよ、と言っていた時期が過去にかなりあるので、傍からみると、まあ方針変換のようにも見える訳なのだけれど、インターネットそのものに掛かる費用が昔に比べれば随分と(他の費用に比べれば)安くなってきたこともあって、「もう何でも自社サーバーの時代ではないのかも」というのが最近の感覚だ。

まあ、プロバイダやレンタルサーバーの費用が数百円のオーダーにまで下がってきたとはいえ、ちゃんと運用するにはそれなりの手間と費用が掛かることに変わりはないわけで、その辺の需要はまだあるとは思っているけどね。

OpenOffice の XMLフィルタ

OpenOfficeが XMLベースになって、odf というオープンスタンダードなXML形式となっているということは、結構有名だし、XMLファイルの入出力にも対応しているという話も耳にしているので、さぞかしXMLとは相性がいいのだろう とは思っていたのだけれど。

実際に Calc に XMLデータを取り込もうとすると、あまり優しくない。( 難易度の 易しい・易しくない という話だと、まあ、易しい部類なのだとは思うけれど。)

まず、ドキュメントが不足している... というか、どこにドキュメントがあるのかわかりにくい。
結局、WEBで検索して、デベロッパ用のかなりまとまった文書と、メーリングリストの中のサンプルを見つけて、とりあえずの目的は達せられたけれど、結局は 700ページの ODF規格書を読まないと正確なところはわからないし。
規格書自体も、「詳細は実装依存」となっていて具体的なことは書いていなかったりする。具体的には、タイムスタンプの OOo内での具体的な表現などは、実装依存部分らしくてあまり書いていない。ISOの YYYY-MM-DDTHH:MM:SS を入力として受け入れるべきだとは書かれていても、もっと一般的な YYYY-MM-DDTHH:MM:SS+09:00 の形式が受け入れられるかどうかについては記載がないので、結局 OOo で作成されたファイルの中身を見て確認する破目になる。

Calc で XMLを読みたいと思う場合、通常のケースだと、表の特定の指定した場所に読み込みたいと思うことが多いはずだが、これができない。できるのはあくまで一枚のシートとして取り込むことだけで、シートの一部に埋め込むような読み込み方はできない(らしい)。
この辺は Excel の方が、ユーザーの期待に沿った実装をしているように思う。
( まあ、ExcelのXML規格書の 4000ページを読む気はさらさらないけどね.... )

IPv6対応

いろいろな情報を総合すると、アジアのIPv4アドレスは今年か来年の半ばくらいにはストックが底を尽き、日本に限っても再来年には新規の割り当てができない状況になるらしい。

そんなわけで、この2週間ほど、社内LANのIPv6対応を実施している。
とりあえず、内部から外部へのIPv6接続と、WEBサーバー周りのIPv6対応は一段落。
プロバイダがnativeなIPv6対応をしていないので、トンネルを使ってのIPv6対応なので、そんなに速くはない。


EPUB

Kindleの成功で、少し注目を集めている電子書籍フォーマットなので、仕様を少し調べて見た。
いろいろバージョンがあるようで、少し混乱があるようだけれど、まあ単純に言えば XHTML に ナビゲーションをつけただけのもので、DAISY書籍にくらべればずっとシンプル。

シンプルすぎて、じゃちょっとサンプルでも作ろうかという気分にもなれないくらい ... つまり、仕様書を読む手間さえ掛ければ、HTMLをきっちり書ける程度の能力があれば誰でも簡単に作れてしまうくらいのフォーマットなんだな。だからこそ、普及するのだけれどさ。

そんなわけなので、何かを epub 形式にしたい、なんて要望があれば、安価に請負ますよ(宣伝です)。
DAISY書籍は普通の値段をいただきます --- まあ、手間の量が格段に違うので。

貧乏人の○○○

かつて、linux が貧乏人のunix と呼ばれていたり、windows が 貧乏人の mac と呼ばれていたように、ローコストな代替品には貧乏くささが付き纏っていたと思う。

thin client もその一つ。最近では PC の価格そのものが暴落したこともあって、価格的なメリットはもうほとんど宣伝されることはなくなって、もっぱらセキュリティ的な面が強調されるようになってきている。 ( かつては、200万位のワークステーションの替りに、50万円程度のX端末を数台導入するというのは十分価格メリットがあった。)
最近見かけたものは、モニタの背中に貼り付けるタイプのCPUボード( 15cm角くらいか? )で一万円台の thin clientを見かけたが、さすがにこの大きさでこの値段なら試しに導入してみようかという気も興る。

iSCSI という、たぶんこれも、貧乏人のファイバーチャネル(FC) と呼ばれそうなストーレッジがある。Gigabitのネットワークでつないでも理論値として 125MB/secの速さしかでないわけで、どう頑張っても SCSIの速さやFCの速さには及ばない。USBに比べればそれでも倍以上の速さはあるので、値段的にも容量的にもその中間辺りがターゲットになる。

NASというソリューションであれば、sambaを使えば数テラバイトであれば10万円以下で構築できるし、sambaが嫌い( やっぱり、Windowsと完全互換が取れているわけではないので) という向きには、Windows Storage Server が 20万円位で売られている。
一方で、iSCSI となると、同じ容量であれば、Windows Storage Server と同等程度かそれより少し上の価格帯にならざるを得ない( もちろん、信頼性の高い部品を使わないとか、ホットスワップしないとか条件が付けば、無料のsamba並みの価格でできるけれど)。
NASがファイルレベルのソリューションなのに比べると、iSCSIはデバイスブロックレベルのソリューションなので、OSを問わないといった利点ももちろんあるのだけれども、iSCSIブートに対応しているNICはまだまだ高価だし、PXEブートで、NFSマウントするという旧来のやり方に比べて、価格に見合うだけのメリットがあるか というと、かなり微妙だ。

たぶん、この中途半端さにちょうどぴったり合うような用途はあるのだと思うが、どんな用途になるのだろう。

多重化と仮想化と

一つの籠に卵を盛ってはいけない という諺があるけれど、サーバーの仮想化というのはまさに、サーバーを一つの籠に盛る技術のわけで、これにさらに冗長化の要求が加わると、小さなオフィスにとっては「何もそこまでしなくても...」というくらいに大げさな話になってしまう。
もともとサーバーが5台なり10台なり存在していたような環境ならともかく、一台か2台ですべて賄えてしまうような環境では、「仮想化?それなに?」となってしまうのが正直なところ。

弊社でも、比較的最近まで常時電源の入っている機械は(ルータなどを除けば)1台しかなかったが、ふと気が付けば3台が常時ONの状態になっている。一台は仮想化されているので実質10台位の仮想機械が常時稼動している計算だ。
ネームサーバーが2台、DHCPサーバーが2台、メールサーバーが2台、、、小さなオフィスでそこまでする必要があるのだろうか、と、つい思ってしまう。

台数が増える理由は、一つには、実際の要求があって増えてしまった面もあるし、お客さんの環境に似た環境を用意しておかないといざというときに対応できない(お客さんの実機でテストする訳にもいかないのでトラブルの再現のためにはどうしても似た環境が必要になる)ので、敢えて大げさにしてある面もある。
一方で、月々の消費電力が気になるような用途もあるので、一台にどれだけ詰め込めるか、という環境も無視するわけにはいかないので、結局3台が同時稼動しているという結果になっている。
結局どんなに工夫をしても、たぶん今の3台が2台になることはあっても、1台に状態に戻ることはもうないのだろう。

結局、社内サーバーとして minimal な構成は、ディスクをミラーリングした上での1台構成。これ以下ではトラブル時に対処できないし、特別な信頼性が要求されるのでなければそれ以上は(オフィスの規模にもよるが)大げさすぎる。これが、今行っているキャンペーンで「ハードウェア込み」と書かれているサーバー構成の基本になっている。
[ 本当は、最悪の緊急時用にあと0.5台くらいあった方がいい ... それこそおもちゃのような機械でも ... のだけれどね。 ]

まあ、機能ごとに機械が分散していたほうがメインテナンスが楽というのもあるし、最初からすべての機能が必要なわけでもないので、台数はややもすると増加しがちなもの。ある程度増えたところで枯れた部分を少ない台数に集約させるということの繰り返しかな。

動機付け

たまに、ちょっと目新しい分野でたまたま顧客の要望にも沿った分野のプログラムの需要が見込めそうなときに、普段なら50万くらいの見積もりを出すところを、予算度外視で 20万くらいで打診してみることがある。
最近の例だと、XMLを使ったDBで、リレーショナルなデータベースだとちょっとデータを保存しにくいタイプの、(つまり、あまりきっちりデータ構造が決まっていないタイプのデータ)データ検索絡みのプログラムがあった。
こちらとしては、その値段なら即決だろうと思って提案しているのだが、「アルバイトに人海戦術でさせたほうが安い」なんて返事が返ってくると、がっかりしてしまう。

その予算だと、なにか出来合いのものをもってきて、それにちょこちょこっと手を加えてできる範囲のことしかできないけれど、そんな都合のよいできあいのものなんて、今のところ存在しないですよ。

1 2