30 posts categorized "ソリューション・購買"

May 06, 2010

大規模システム構築と小規模システム構築の大きな違い(その2)

前回のエントリーからの続きです。今回は大規模システムと小規模システムでの負荷対策に対する考え方の違いについて述べてみたいと思います。

【小規模システムではパフォーマンスチューニング力が重要】
小規模システムではハードウェアリソースの追加が費用面で難しいので、負荷対策においては限られたハードウェアリソースを最大限活かす方向で頑張ることになります。つまりアクセスが増えてきた場合はパフォーマンスチューニングすることで乗り切ることとなります。

例えば1台のサーバ上にApacheとJAVAとTomcatとMySQLを入れた環境があったとします。最初の頃は特に問題がなくても、徐々にアクセス数が増えてだんだん応答速度が落ちてきたときは、ソースコードを改良したり、オープンソースの各パラメータを調整したり、もしくはmemcachedを入れて繰り返し問い合せられるものをメモリ上にキャッシュさせたりといった、パフォーマンスチューニングに労力を注ぐことになります。

【大規模システムではスケーラビリティの高いシステム設計が重要】
一方、大規模システムではアクセス数増大をパフォーマンスチューニングだけで乗り切るのが不可能な場合がほとんどなので、負荷対策においてはハードウェアリソースを増強することで対処することになります。つまりシステム設計の上で、ハードウェアリソースを増強することで容易にシステムキャパシティを増やすスケーラビリティの高いシステム設計が重要となります。

例えばWEBサーバ10台でアクセスをさばいている環境があったとします。ある日TV広告を打つことになりました。TV広告を打った直後アクセスが確実に100倍以上になることが予想されたときは、早急にハードウェアリソースを増やして乗り越えなければなりません。サーバを追加する、アクセス数が多すぎてキャパシティを超えた時のことを考えてSorryサーバに飛ぶようにネットワークを調整する、画像などの静的コンテンツはCDNなどを利用する、もしくはこの機会にクラウド環境に切り替えるなどなど、矢継ぎ早に作戦を練って対処していかなければなりません。

【結論】
同じインフラエンジニアであっても大規模システムを扱うか小規模システムを扱うかでこれだけ負荷対策が異なることがおわかりいただけたかと思います。

前回のエントリーでも書きましたが、大規模システムを扱う場合は技術力云々よりもとにかく次々と意思決定していくことがとても重要となります。次々と意思決定するためには幅広い技術的知識や経験がとても重要となります。インフラエンジニアを志したからにはそれらを身に付けつつ、是非ともいつかは大規模システムに挑戦してみていただければと思います。

| | Comments (0) | TrackBack (0)

May 03, 2010

大規模システム構築と小規模システム構築の大きな違い(その1)

「小規模システムの構築」と比べて「大規模システムの構築」はなんだかものすごく高度で難しい印象を持つかもしれません。しかしどちらが高度で難しいかと問われればそれぞれ作業内容が大きく異なりどちらとも言えない気がします。そこで今回は両者どのように作業内容が違うためどちらが高度で難しいと言い切れないのかを考えてみたいと思います。

【小規模システムは全てを自分でやらないといけないので難しい】
小規模サイトの場合は担当者が自分一人しかいないということがよくあります。しかし例え小規模であっても押さえなければならないポイントは大規模サイトのそれとは大きく差がないと言えるため、実は広く深い知識と経験が必要なのが小規模システムの構築と言えそうです。

例えばいわゆる一般的な2階層式(=WEB+DB)WEBサイトをリリースするとします。この場合に必要な知識は例えばサーバ、OS、WEBサーバ、セキュリティ、ネットワーク、SSL、メールなどなど。これらを一人だけで一通りこなすというのはある意味高度で難しいと言えます。

【大規模システムは全体の構成を考えるのが難しい】
一方、大規模サイトの場合は担当者が数名でかつ予算がそれなりに用意されている場合が多いです。この場合自分はある特定の部分だけ担当すればよいので気が楽です。また手厚いベンダーのサポートを受ける予算があるので、何か問題に突き当たったときにいちいち検索して調べなくてもベンダーに連絡しておけばすぐに回答が帰ってきます。このことは実は自分自身が高度な技術を持っていなくてもある程度なんとかなってしまうことを意味します。

ただし大規模システムの場合、システムを構成する要素が多くて何をどう組み合わせるのか設計するのが難しいと言えます。また小規模システムと比べて購入するハードウェアが非常に高価な場合が多いので、何を購入するかの選定が非常に難しいです。例えばネットワーク機器を購入する場合、メーカー毎にどのような違いがあり、どのような機能差があり、パフォーマンスはどうで、実績はどうで、拡張性はどうで・・・等々、気にすべき要素が多くて非常に悩みます。

【結論】
思うに、小規模システムの構築は職人技の世界なのに対して大規模システムの構築は意思決定の世界な気がします。つまり、小規模システムの構築では担当者の知識と経験が全てなのに対して、大規模システムの構築では担当者を誰にしてどのベンダーを選定してどの機器を採用して等々、大半の時間を選ぶという作業に費やすことになります。

この機会にインフラエンジニアである皆さんがどちらの世界を目指そうとしているのかをちょっと考えてみても良いかもしれません。

| | Comments (0) | TrackBack (0)

May 20, 2009

SharePoint Server2007について思うこと

Microsoft社のマーケティングのせいか、SharePoint ServerはNotesやサイボウズのように使えるグループウェアであると勘違いしている人も多いと思います。でも実際は「HTMLを知らなくてもサイトを構築できるWebベースのコラボレーションツール」という言い方が正しい気がします。

SharePointの概要はこうです。システム管理者から1枚のWEBサイトが提供されると、そこにWEBパーツと呼ばれる様々なパーツ(掲示板、スケジュール管理、ドキュメントライブラリ、Wiki、アンケート等々)を自由に貼り付け自分達が使いたいようなサイトを構成することができるというものです。そう、Google Sitesのようなものです。SharePointを使うとグループ内の情報共有が進み業務効率化が図れます。

ただしSharePointには大きな弱点が3つほどある気がします。

1.マーケティング戦略のせいかありとあらゆる機能を盛り込みすぎで、概念や用語が難解です。本を読んで全貌を理解してから取り組もう、なんて思っているとすぐに挫折します。しばらく使ってみてようやくなんとなく概念がわかってくる、というツールが気がします。

2.バグなのか仕様なのかわからないが、とにかく変な挙動が多いです。システム管理者から見て、当然こうなってこうやればいいだろうという勘がことごとく裏切られることが多いです。修正パッチも多いですが、機能が多いためか修正パッチを適用すると今度は他の問題が出てくるなんてことも。とにかくシステム管理者泣かせです。

3.InternetExplorerやOfficeと組み合わせると出来ることが増えますが、それ以外の環境だとできることが制限されます。例えば掲示板にupされたドキュメントをOutlookでメールのように読み込むことができたり、Explorer ViewというモードにするとWEB画面がExplorerのようなデザインになり大量のファイルをDrug&Dropできるようになったります。


総評。ユーザから見たらそれなりに使いやすいツールだと思います。しかしシステム管理者は地獄を見るツールです。次回バージョンアップ時はもっとシンプルで扱いやすいシステムに生まれ変わることを期待したいと思います。

| | Comments (2) | TrackBack (2)

May 11, 2009

Exchange Server2003と2007の比較

以前Exchange Server2003と2007を比較検証してみたことがあります。その結果、当時の私はExchange2003を選定しました。無論現在は状況が変わっているかもしれませんが、今回はその当時の状況を思い出しながら記してみたいと思います。

【パフォーマンスは概してExchange2007が上】
Exchange Serverは概してメモリをたくさん積めるほうがパフォーマンス的に有利です。そういう意味で、32bit CPUしか対応していない2003より、64bit CPUに対応している2007のほうが概してパフォーマンスが上です。

【管理のしやすさは断然Exchange2003が上】
管理のしやすさというと漠然としてますが、個人的な印象では2003は管理画面が直感的でシンプルなのに対して、2007は凝りに懲りすぎて何が何だかわからないという印象を受けました。2003だとある程度サーバ管理に慣れている人であればマニュアルを読まなくてもなんとなく設定でき、かつ運用時に内部の挙動もなんとなく把握できます。

それに対して2007はマニュアルを読み込んでも何がなんだかさっぱりわからないところから始まります。設定する箇所もよくわからないし、運用時の内部の挙動把握もどうやったらいいのかよくわかりません。2003と比べて無論使いこなせればものすごい管理ツール群なのでしょうが、使いこなせなかったので宝の持ち腐れでした。そう、2007は2003とまるっきりアーキテクチャーやGUIが異なるのです。

こう書くとわけがわからないかもしれませんが、試しに評価版を入手してご自身でインストールしてみたら違いがすぐにわかるので納得してもらえると思います。

【文字化けはExchange2003のほうが少ない】
メールといえば文字化けはとても重要です。通信する全てのMTA&MUAがRFCに準拠しているだとか、送受信する相手とは日本語しかやり取りしないという状況であれば文字化けは起きにくいのでしょうが、残念ながら平気でRFC違反しているMTA&MUAは多いし、送受信する相手は日本人だけとは限りません。そんなわけでいろいろなパターンを検証したのですが、当時はQuoted-Printable問題のためかExchange2007のほうが文字化けが起きやすいようでした。今は違うかも。

当時いろいろ検証したときのメモ書きがあったので載せてみます。(詳細は忘れました。間違ってたらごめんなさい)

・2007では送信時SubjectのEncode方式をQuoted-Printableにされてしまう。このためWILLCOM PHSにメールを送ると化ける。(注: SP1で解消されたという噂あり)

・2007ではHeaderのCharsetと本文の文字コードが一致しないメールを受信すると化ける。(明らかに送信側の問題だが2003では何故か化けない)

・2003ではUnicodeの処理が正しくないため文字化けが起こることがある。(詳細不明)

・2003/2007共Subjectの長さが76byte以上のメールを受信すると化ける。(RFCでは本来Subjectが75byte以下としているので問題なし)

・2003/2007共①㈱㎝などベンダー固有文字に対応していないメールを送受信すると化けることがある。(仕方ないのかも)

・2003/2007共送信時中継するMTAによって化けることがある。(古いMTAだと7bitが基本なので、8bitが前提のUTF-8などでメール送受信すると8bit目が失われてメールが化けることがある。JISで送れば問題なし)

【まとめ】
2003は素直な作り、2007はいろいろ高度なことをやろうとしたがうまくまとめきれなかった、という印象を受けました。そういった意味ではサポート切れ期間が2007より短いことを除けば2003のほうがお勧めです。

ただマイクロソフト製品の場合、技術革新を起こした直後の製品は使いづらいものの次のバージョンで問題点を解決してくるので、多分Exchangeの次のバージョンは高性能でかつ使いやすいものになることでしょう。

| | Comments (0) | TrackBack (0)

October 15, 2007

本当に出た!(家庭にはPCの代わりにThinClientを)

先日こんなエントリーを書いたわけですが、なんとこれを本当に実現したソリューションが登場しました。

→こちら

Panoの本体価格は300ドル、それに年間20%程度のサポート保守費用がかかる。またサポート保守を含めた月額20ドルのサブスクリプション方式も用意され、どちらかを選ぶことができる。とのこと。価格設定も僕の想定に近くて驚きました。

小飼弾さんはこのビジネスモデルに否定的みたいなんですが、個人的にはどの程度ユーザを集めるかとても興味深いです。

| | Comments (6) | TrackBack (1)

July 06, 2007

社内ブログを導入しよう

最終回の@IT連載記事が掲載されました。タイトルは「社内ブログを導入しよう」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/16/01.html


さて、この連載では16ヶ月に渡り社内情報システム担当者が遭遇する一通りのことを身を削って書いてきました。ご興味のある方はバックナンバーもご覧ください。皆さんの業務の参考になれば幸いです。

| | Comments (0) | TrackBack (0)

May 28, 2007

情シス業務アウトソーシングの秘訣

今月分の@IT連載記事が掲載されました。タイトルは「情シス業務アウトソーシングの秘訣」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/15/01.html

ちなみにこの連載は来月最終回の予定です。

| | Comments (0) | TrackBack (0)

May 01, 2007

会議室を効率的かつ便利な空間にする

今月分の@IT連載記事が掲載されました。タイトルは「会議室を効率的かつ便利な空間にする」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/14/01.html

| | Comments (0) | TrackBack (0)

March 22, 2007

ワークフローシステムの賢い導入法

今月分の@IT連載記事が掲載されました。タイトルは「ワークフローシステムの賢い導入法」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/13/01.html

| | Comments (0) | TrackBack (1)

February 12, 2007

WEBサイトの重さを調べる方法

サイトの重さ・軽さというのは、ブロードバンド時代となってからはあまり気にされなくなりましたが、それでもgoogleやYahooのような軽いサイトはユーザにとって嬉しいものです。

というわけで私がWEBサイトを作るときは下記のサイトでWEBサイトの重さをよく調べています。

http://www.kaipara.net/cgi-bin/size_check.cgi

他にも似たサイトはたくさんありそうですが、とりあえず私がたまに使っているものということでご紹介してみました。

| | Comments (1) | TrackBack (0)