カテゴリー「[システム開発]」の記事

2008年5月20日 (火)

[雑誌] プログラミングを始めたい人にオススメ本

プログラミングなるものをしてみたい。でも何から始めればいいかわからない。
そんなとき、XAMPPをインストールすれば環境は一通り整います。
でも、具体的に何をするかで困りがち。

そんなときにこんな雑誌はどうでしょうか?
WEB+DB pressも日経ソフトウェアも、プログラマー向け雑誌の大御所です。
その雑誌の総集編。どちらも過去の記事をPDF化したCD-ROMが付いています。

XAMPP環境が動いて、ちょっとやってみたいことが出てきたとき、
参考になるサンプルソースは、この2冊(CD-ROM2枚?)があればOKでしょう。

現時点での総集編ムックではとてもオススメの2冊です。

20080520_QR-Web+DB press総集編(1ー36).jpg
Web+DB press総集編(1ー36)

20080520_QR-プログラミングまるごとパック(2007).jpg
プログラミングまるごとパック(2007)


| | コメント (0) | トラックバック (0)

2006年9月 6日 (水)

[PSU] アクセス過多の原因を考えてみる(2)

4Gamer.netでファンタシースターユニバースの稼動トラブルについて取り上げられていました。
それで気づいたんですが、発売前に開発者がカンファレンスで公開したシステム情報なんてのも載ってたんですね。

システム構成も公開されていて、先日の記事で予想した内容(予想したシステム構成はこちら)でも論理的には正解だったんですが、さらに詳しい情報が載っていたので、そちらを元に原因分析してみます。

続きを読む "[PSU] アクセス過多の原因を考えてみる(2)"

| | コメント (0) | トラックバック (1)

2006年9月 5日 (火)

[PSU] アクセス過多の原因を考えてみる

今日ファンタシースターユニバースでアナウンスされた「正式サービス開始延期」のアナウンスは、オンラインゲームとしてはこれまで前例のないものです。商用サービスとしては起こしてはいけないトラブルでしょう。

実際に自分が参加中に発生した現象や、見えている情報から、今回のトラブルの原因がどこにあるのか、また解決策は何なのか、ということを考えてみます。

続きを読む "[PSU] アクセス過多の原因を考えてみる"

| | コメント (0) | トラックバック (0)

2006年8月20日 (日)

[システム開発] PCIカード型SSLアクセラレータ

WebサーバでSSLアクセラレータを導入するなら、箱モノよりPCIカードのほうがずいぶん安いよ、という話。

Web屋のネタ帳:SSLアクセラレータはそれ用のPCIカードをWebサーバに仕込むほうが安価かも
アプライアンス型のSSLアクセラレータは1台100万から200万円をくだらないものが多い。一方でPCIカード型は20万円から30万円くらいのようだ。中小企業にとってこの差は大きい。
先日の記事でwebサイトの構成の例を示したが、ついでにリバースプロキシ側のWebサーバにPCIカード型のSSLアクセラレータをあらかじめ仕込んでおくという方法も一案だと思う。

 

ここで「先日の記事」として紹介されている記事も良かったですね。
こういうシステム構成図的なものって参考になります。

Web屋のネタ帳:DNSラウンドロビンとmod_proxy_balancerによるWebサイトの負荷分散(案)

 

| | コメント (0) | トラックバック (0)

2006年8月16日 (水)

[システム開発] ファイルサーバの導入に失敗しない方法

@ITで興味深い記事を見かけたのでメモ。

ファイルサーバの導入に失敗しない方法 - @IT情報マネジメント

筆者が経験した失敗事例を挙げ、その対応方法が紹介されています。

  • その1 サーバ機ではなくPCを使ったためにハードウェアトラブルが頻発する
  • その2 キャパシティ計画がずさんだったため、ディスク容量の需要に追いつかない
  • その3 部門サーバを統合したら権限管理がとても大変になった
  • その4 Windows以外のクライアントからつなげない
  • その5 NASを増設しようとしたら販売終了していた

1~4はともかく、その5は厳しいですね。
サーバ用途だと長期間、使い続けることになりますが、IT関連機器の販売サイクルはそれに比べると短いです。
買い替えや買い足しで全く同じ機種を購入できるとは限らない。
名の通ったメーカーだから安心できる、とは言い切れないんですよね。

ちなみにこの筆者さん、自身のブログで同じくファイルサーバの導入について、さらに技術的なまとめ記事を公開されていました。
経験を基にした話なので、参考になります。

sanonosa システム管理コラム集: 信頼性の高いファイルサーバについて考える


 

| | コメント (0) | トラックバック (0)

2006年4月 4日 (火)

[システム開発] SEに必要な「臆病さ」と「大胆さ」

@ITより気になった記事。

一志達也のSE、魂の叫び 第10回:臆病なベテランSEと大胆な新人SE未満
(記事の新人たちは)非常に大胆で、「とにかくやってみよう」という意識にあふれていた。これが2年目や3年目になると、「これは何に使うんですか」だの「もう少し細かい設定情報をください」だのと、理屈を先に持っていきたがる。5年目や6年目になると、「そんなのは自分の仕事ではない」という風潮が先立ってみたりする。あるいは、完全を期すことが使命のように感じるのか、「ひとまず動けばいいや」というような発想にはならなくなる。

ベテランSEの臆病さは、経験からくるもの。
「こういうことをやると失敗の可能性が高い」「前回、成功した方法を踏襲しよう」
こういう経験やノウハウは、仕事を効率よくこなすには重要なことです。
会社が追求しようとするのは「利益を上げること」ですから、仕事をする上で効率を上げることは常に求められます。

でもそういうことを考えるあまり、仕事の内容が守りに入りすぎているんじゃないだろうか・・・。

失敗のリスクを考慮しつつ、できる範囲で冒険してみること。
冒険しつつも、仕事の品質を保つこと。

バランスが難しそうですが、忘れないようにしたいものです。

一志達也のSE、魂の叫び 第10回:つぶやき:OSインストール未経験者が増えている
別にインストール作業を知っているからといってどうということもないのだろうが、やはり何ごとにおいても基礎を身に付けることが重要だと思う。そういった意味で、理屈をある程度理解する必要のあるOSインストール作業は重要ではないだろうか。
それらを知っているのと知らないのとでは、技術者として大きな違いがある。プリインストールされているPCであっても、あえてOSパッケージを購入して、自分でインストールしてみるのはいかがだろうか。

同じ記事内のつぶやき。同感です。

自分でOSインストールして変わるのは、何かPCに不具合が起こっても「再インストールできるから大丈夫」と落ち着いて対処できること。
インストール経験がなければ、1回できただけでもちょっと自信が持てたりするものですが、何度か繰り返すうちに「OSを動かすのに最低限、必要な設定」の理解が深まります。
1回もやったことがないと、何度か繰り返すチャンスも見逃しちゃいますから、機会があればやらなきゃ損ですよね。

 

| | コメント (0) | トラックバック (0)

2006年4月 1日 (土)

[システム開発] RAIDのレベル比較、RAID5/6の書込み方式

RAIDレベルの比較まとめと、RAID5/6の記録方式まとめ。

 

■代表的なRAIDレベルの比較(カッコ内は項目ごとの順位)

  価格  耐障害性  読込性能  書込性能  最低Drive数 
RAIDなし 

 ◎(1) 

 ×(4)

 ×(4)

 ×(4) 

 (1)

RAID0+1

 ×(4)

 ◎(1)

 ◎(1) 

 ◎(1)

 (2)

RAID5

 △(2)

 ○(3)

 ◎(2)

 ○(2) 

 (3)

RAID6

 △(3) 

 ○(2) 

 ◎(3)

 ○(3)

 (4)




■RAID5/6のディスク台数について
RAID5は (n-1)台のディスクに分散書き込み。1台にパリティを記録。
RAID5の実装には最低3台のディスクが必要。

RAID6は (n-2)台のディスクに分散書き込み。2台にパリティを記録。
RAID6の実装には最低4台のディスクが必要。


■RAID5のパリティ書き込み方式
(例)ディスクA,B,C,D(RAID5)にB(1)~B(10)のデータを書き込み。B=ブロック、P=パリティ

 ディスクA  B(1)  B(4)  P(5)(6)
 ディスクB  B(2)  P(3)(4)  B(7)
 ディスクC  P(1)(2)  B(5)  B(8)
 ディスクD  B(3)  B(6)  P(7)(8)


 

■RAID6のパリティ書き込み方式
(参考: ■ストレージ ETERNUS > 用語解説 > RAID機能 > RAID 5 : 富士通
(例)ディスクA,B,C,D(RAID6)に(1)~(10)のデータを書き込み。

 ディスクA  B(1)  B(3)  P(5)(6)  P(7)(8)
 ディスクB  B(2)  P(3)(4)  P(5)(6)  B(7)
 ディスクC  P(1)(2)  P(3)(4)  B(5)  B(8)
 ディスクD  P(1)(2)  B(4)  B(6)  P(7)(8)


 

■RAID6の書込み方式詳細(2D-XOR方式とP+Q方式)

■RAID5/6の性能について
ディスクからの読み出し時には、複数のディスクから同時並行読み出しが可能なので高速化される。
しかしデータのパリティ処理のオーバーヘッドが大きいため、書き込み性能は決して高くはない。

■参考記事


| | コメント (0) | トラックバック (0)

2006年3月30日 (木)

[システム開発] サーバ搭載ストレージの最新トレンド(RAID6とSAS)

サーバ内蔵ハードディスクの最新トレンド(2006年版) - @IT

より、サーバに搭載されるストレージの変化について、記事のポイント。

1.IDE/SCSI⇒SATA/SAS

従来、IDE/SCSIで使われてきたパラレル・インターフェイスの性能が限界に近づいている。
同時にディスクコントローラの処理能力向上により、SATA(シリアルATA)やSAS(シリアル・アタッチドSCSI)などのシリアル・インタフェースの使用が現実的になった。
一般向けデスクトップマシンではSATAの使用が広がっているが、サーバ用途でもSASが普及しそう。
SASでは、SATAと互換性を持つコネクタを採用しているため、サーバ用途により、コスト重視ならSATA、性能・耐障害性重視ならSAS、という選択が可能になるというメリットもある。

2.3.5インチ⇒2.5インチ

2.5インチHDDは3.5インチに比べて、本体容積が70%以上小さく、消費電力も40%ほど低い。
スペースに制限のあるブレード・サーバでサーバ用途でも使われるようになり、1Uラックマウント型サーバへも積載容量を増やすために導入が始まった。
ディスク容量の小ささ、バイト単価の高さというデメリットもあるが、普及すれば差は縮まりそう。

3.RAID5⇒RAID6

元々RAID導入では、同じ時期に製造した同じ型番の製品を利用することが多い。
これがシステム規模の拡大によってハードディスク台数も増加し、2台同時に故障する可能性が無視できなくなってきた。
RAID5に比べてRAID6は「パリティ計算のタイムロスが大きい」「実効ディスク容量が少なく、構成に必要なディスク台数が多くなる」といったデメリットもあるが、前者はCPUやRAIDコントローラの性能向上、後者はHDDの単価下落によって導入が容易になった。

以上3つの要因により、サーバ用途では2006年後半に向けて「SASによる2.5インチHDDのRAID6ストレージ」の導入が進むだろう。

さらにもう一つ、「2台同時に故障する可能性が無視できなくなってきた」 ことについて理由を指摘した記事。

安価&大容量ディスクサブシステムに欠かせないデータ保護技術「RAID 6」
SANNASを通じて1台のディスクサブシステムを複数のサーバーから共有する形が一般化しており、ディスクサブシステムのデータ損失が複数のサーバーに影響を与えてしまう。

(参考記事:低価格SAN低価格NAS

| | コメント (0) | トラックバック (0)

2006年3月29日 (水)

[システム開発] Perl/PHP+MySQL vs Java+Oracle

先日、SEの友人と話していたとき。
Webサーバみたいなオープン系のシステム開発はいわゆるSIerのシステム開発に比べて品質管理がアバウト・・・というと語弊があるな・・・品質管理にかける時間や労力が少ないんじゃないか、という話になった。

その流れで友人が言った言葉、「Webサーバはニッチだもんね」

この言葉を聞いたとき、初めは「あぁ、そうだよなぁ」と思う反面、「ニッチ」という単語に違和感が残った。
Webサーバ開発って、システム開発全体で見ると隙間産業・・・っていうほど小さくはない気がする。
少なくともサーバ数とかシステム数で見れば、逆に多数派になるじゃなかろうか。

予算規模で1システム同士を比べれば、その差は歴然。
でも、それぞれが小粒でも数が多い。全体で見れば意外と差はなくなるかもしれないな。
しかもこの差は、今後縮まっていくんじゃないだろうか。

つまり、ニッチというより単純に担当範囲が違うといったほうがいいかもなぁ。

なんてことをこのところ考えていた。

そんなタイミングでこのような記事を発見。

2006年1月 - Walrus, Visit.:なぜ「業務にPerlは使えない」のか?

F's Garage:Java圏とPHP,Perl圏の断絶について。

ともに、冒頭で比較した2ジャンルをPerl/PHP+MySQLとJava+Oracleといったグループに分けて、「使う技術の違い」「開発する企業の違い」という切り口で比較している。

そもそも企業文化も違うし、基盤の技術が違う、と。
ついでにもう一つ、対象のユーザも違うだろうか。(企業相手と一般ユーザ相手)

しかもどの違いも完全に分断されているわけじゃない。
かぶる部分もあるから一見「同じシステム開発」とひとくくりにしてしまいそうだけれども、この2つのジャンルは目指す方向が違う。
文化が違うんだと割り切って、それぞれの長所・短所を見極めるのが良さそう。

 

| | コメント (0) | トラックバック (1)

2006年3月17日 (金)

[システム開発] スケジュールの「見える化」とスケジュールバッファ

開発スケジュール管理について、興味深く感じた記事を2本。

■.NET+アジャイルなら本当に幸せになれるのか? - @IT
http://www.atmarkit.co.jp/fdotnet/nagile/nagile01/nagile01_02.html

この記事から、開発成果物・スケジュールの「見える化」について、
オフショア開発での問題を指摘。

> 見える化の重要な特徴の1つが、「いつも見える」ことです。
> いつも目に入ってくることがとても大切なんです。
> なぜかというと、それがコミュニケーションの基本だからです。
> すべての状況は何らかの形で常に目に見えるようにしておかないと、
> それについて(問題が顕在化するまで)なかなかコミュニケーションが
> 図られないことになるからです。
(中略)
>  いまはオフショア開発が全盛期ですが、
> 特にそのような開発現場ではまったく何も見えないことの方が多い。
> そして、実際にプログラムが手元に来ていざ結合してみると、
> とんでもない問題を抱えていることにそこでやっと気付く。
> そういうことが多々あるわけです。

この解決策として記事で説明されてるのがアジャイル型開発だけど、
大規模プロジェクトで導入するのは難しい。
そもそも、プロジェクト途中から始めるものでもない。
なので、活用に踏み切るタイミングが難しいかも知れない。

あと、
> そして、実際にプログラムが手元に来ていざ結合してみると、
> とんでもない問題を抱えていることにそこでやっと気付く。
について、思い当たったのが次の記事。

■クリティカルチェーン・プロジェクトマネジメント
- @IT情報マネジメント用語事典
http://www.atmarkit.co.jp/aig/04biz/ccpm.html

> ゴールドラットは、「プロジェクトバッファ」「合流バッファ」という
> 概念を導入した。
> バッファとは個々の作業者ではなく、
> プロジェクトマネージャが管理する余裕時間である。

作業を依頼するときは、遅れたことを想定しておく。
プラス、受け入れチェックの時間を忘れずに見積もる。
当たり前のことだけども、忙しくなると忘れがち。

クリティカルチェーンという考え方にも納得。
実際にどう活用するか、となると試行錯誤が必要だけれども、
その考え方は忘れないようにしたい。

 

| | コメント (0) | トラックバック (0)