冗長化 - 版の履歴

153.220.40.143: /* 主な冗長化技術 */

2014-10-10T05:53:45Z

主な冗長化技術

← 古い版		2014年10月10日 (金) 05:53時点における版
33行目:		33行目:
	* [[スタッカブルスイッチ]]		* [[スタッカブルスイッチ]]
	* [[フェイルオーバークラスター]]		* [[フェイルオーバークラスター]]
			* [[事業継続計画]] - [[BCP (Business Continuity Planning)]] - [[BCP]]

	== 関連項目 ==		== 関連項目 ==

153.220.99.192: /* ソフトウェア */

2014-10-02T07:35:16Z

ソフトウェア

← 古い版		2014年10月2日 (木) 07:35時点における版
14行目:		14行目:
	昨今では、この点を説明しない[[IT企業]]、またはそもそも理解していない者が[[ソフトウェア]]の開発案件を受注するケース多く、そのようなケースでは主力[[プログラマー]]の事故病気や、[[デスマーチ]]の発生などにより[[IT土方]]不足に陥ると、緊急招集された追加人員への説明や指導なども時間的な制約で追いつかず破綻するという事も多い。いわゆる「[[人月の神話]]」に書かれているそのものな状況である。なお、リアル土方の世界では事故死する者が発生する前提で見積もりを出していることが多い。		昨今では、この点を説明しない[[IT企業]]、またはそもそも理解していない者が[[ソフトウェア]]の開発案件を受注するケース多く、そのようなケースでは主力[[プログラマー]]の事故病気や、[[デスマーチ]]の発生などにより[[IT土方]]不足に陥ると、緊急招集された追加人員への説明や指導なども時間的な制約で追いつかず破綻するという事も多い。いわゆる「[[人月の神話]]」に書かれているそのものな状況である。なお、リアル土方の世界では事故死する者が発生する前提で見積もりを出していることが多い。

	また、効率化を突き詰めるあまり、複雑な構成（[[密結合]]~~）にしすぎて天才的技術者がひとり抜けた後に発生したトラブルで誰も直せず崩壊した、などという目も当てられない事態に陥っている~~[[案件]]も非常に多いのも事実である。		また、効率化を突き詰めるあまり、複雑な構成（[[密結合]]）にしすぎて、天才的技術者がひとり抜けた後に発生したトラブルで誰も直せず崩壊した、などという目も当てられない事態に陥っている[[案件]]も非常に多いのも事実である。

	まっとうな企業の見分け方としては、例えば[[ペアプログラミング]]を実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。		まっとうな企業の見分け方としては、例えば[[ペアプログラミング]]を実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。

2014年8月4日 (月) 11:45にimported>Mono Bookによる

2014-08-04T11:45:19Z

← 古い版		2014年8月4日 (月) 11:45時点における版
1行目:		1行目:
	'''冗長化'''~~（じょうちょうか）とは、事故災害などのリスクに備え、~~[[冗長]]に予備機材や予備回線を用意しておくことである。		'''冗長化'''（じょうちょうか、[[英語]]：redundancy）とは、事故災害などのリスクに備え、[[冗長]]に予備機材や予備回線を用意しておくことである。

	== 概要 ==		== 概要 ==
10行目:		10行目:

	=== ソフトウェア ===		=== ソフトウェア ===
	~~また、冗長化は~~[[ハードウェア]]のみならず、[[ソフトウェア]]の開発時や[[システム]]~~の運用時の人的リソースについても同様である。~~		冗長化は[[ハードウェア]]のみならず、[[ソフトウェア]]の開発時や[[システム]]の運用時の[[人的リソース]]についても同様である。

	~~昨今では、この点を説明しないIT企業、またはそもそも理解していない者が~~[[ソフトウェア]]の開発案件を受注するケース多く、そのようなケースでは主力[[プログラマー]]の事故病気や、[[デスマーチ]]の発生などにより[[IT土方]]不足に陥ると、緊急招集された追加人員への説明や指導なども時間的な制約で追いつかず破綻するという事も多い。いわゆる「[[人月の神話]]~~」に書かれているそのものな状況である。~~		昨今では、この点を説明しない[[IT企業]]、またはそもそも理解していない者が[[ソフトウェア]]の開発案件を受注するケース多く、そのようなケースでは主力[[プログラマー]]の事故病気や、[[デスマーチ]]の発生などにより[[IT土方]]不足に陥ると、緊急招集された追加人員への説明や指導なども時間的な制約で追いつかず破綻するという事も多い。いわゆる「[[人月の神話]]」に書かれているそのものな状況である。なお、リアル土方の世界では事故死する者が発生する前提で見積もりを出していることが多い。

	また、効率化を突き詰めるあまり、複雑な構成（[[密結合]]）にしすぎて天才的技術者がひとり抜けた後に発生したトラブルで誰も直せず崩壊した、などという目も当てられない事態に陥っている[[案件]]も非常に多いのも事実である。		また、効率化を突き詰めるあまり、複雑な構成（[[密結合]]）にしすぎて天才的技術者がひとり抜けた後に発生したトラブルで誰も直せず崩壊した、などという目も当てられない事態に陥っている[[案件]]も非常に多いのも事実である。

114.49.34.5: /* 価格的な側面 */

2014-02-07T11:00:03Z

価格的な側面

← 古い版		2014年2月7日 (金) 11:00時点における版
19行目:		19行目:

	== 価格的な側面 ==		== 価格的な側面 ==
	冗長化には非常にお金がかかる。たとえば[[~~RAID-1~~]]を用いて[[HDD]]を冗長化するにしても、[[HDD]]は2個必要であり、さらにそれを制御する機構も必要となるため、最低でも2倍3倍以上の出費を余儀なくされる。いわゆる冗長化を突き詰めれば費用は倍々ゲームで増えるのである。		冗長化には非常にお金がかかる。たとえば[[RAID1]]を用いて[[HDD]]を冗長化するにしても、[[HDD]]は最低2個必要であり、さらにそれを制御する[[RAIDコントローラー]]などの機構も必要となるため、最低でも2～3倍以上の出費を余儀なくされる。いわゆる冗長化を突き詰めれば費用は倍々ゲームで増えるのである。

	ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]~~などの登場で中小企業でも利用できる環境は整いつつあるが、それでも中小企業では金銭的に難しい話なのは変わりない。~~		ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]などの登場で中小企業でも利用できる環境は整いつつあるが、それでも[[中小企業]]では金銭的に難しい話なのは変わりない。

	なお、不毛な価格競争を行っている企業などでは目下の見積書を安くするため冗長化に関する部分が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者（利用者）側であり、ただ「安い」という理由で採用するのは非常に危険である。いわゆる「[[Write Once, Run Away]]」な「売り逃げ」が発生すること間違いなしである。		なお、不毛な[[価格競争]]を行っている企業などでは目下の[[見積書]]を安くするため冗長化に関する部分が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者（利用者）側であり、ただ「安い」という理由で採用するのは非常に危険である。いわゆる「[[Write Once, Run Away]]」な「売り逃げ」が発生すること間違いなしである。

	「なぜ冗長化が必要なのか？」「なぜバックアップが必要なのか？」を聞いてもいないのに熱く語ってくるくらいが丁度よく、「どの程度まで必要なのか？」を前もって徹底して話し合うこと重要であり、そのバランス感覚をしっかりと説明できるところに発注しよう。		「なぜ冗長化が必要なのか？」「なぜ[[バックアップ]]が必要なのか？」を聞いてもいないのに熱く語ってくるくらいが丁度よく、「どの程度まで必要なのか？」を前もって徹底して話し合うこと重要であり、そのバランス感覚をしっかりと説明できるところに発注しよう。

	== 主な冗長化技術 ==		== 主な冗長化技術 ==

114.21.208.57: /* 主な冗長化技術 */

2014-02-01T12:03:48Z

主な冗長化技術

← 古い版		2014年2月1日 (土) 12:03時点における版
31行目:		31行目:
	* [[リダンダント電源]] - [[コンピューター]]の[[電源]]に対する冗長化技術。		* [[リダンダント電源]] - [[コンピューター]]の[[電源]]に対する冗長化技術。
	* [[リンクアグリゲーション]] - [[LAN]]などの[[ネットワーク回線]]に対する冗長化技術。		* [[リンクアグリゲーション]] - [[LAN]]などの[[ネットワーク回線]]に対する冗長化技術。
			* [[スタッカブルスイッチ]]
	* [[フェイルオーバークラスター]]		* [[フェイルオーバークラスター]]

imported>GamerBook: /* 価格的な側面 */

2012-12-09T09:38:41Z

価格的な側面

← 古い版		2012年12月9日 (日) 09:38時点における版
23行目:		23行目:
	ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]などの登場で中小企業でも利用できる環境は整いつつあるが、それでも中小企業では金銭的に難しい話なのは変わりない。		ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]などの登場で中小企業でも利用できる環境は整いつつあるが、それでも中小企業では金銭的に難しい話なのは変わりない。

	なお、不毛な価格競争を行っている企業などでは目下の見積書を安くするため、冗長化が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者（利用者）側であり、ただ「安い」という理由で採用するのは非常に危険である。「なぜ冗長化が必要なのか？」「なぜバックアップが必要なのか？」を聞いてもいないのに熱く語ってくるくらいが丁度よく、「どの程度まで必要なのか？」を前もって徹底して話し合うこと重要であり、そのバランス感覚をしっかりと説明できるところに発注しよう。		なお、不毛な価格競争を行っている企業などでは目下の見積書を安くするため冗長化に関する部分が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者（利用者）側であり、ただ「安い」という理由で採用するのは非常に危険である。いわゆる「[[Write Once, Run Away]]」な「売り逃げ」が発生すること間違いなしである。

			「なぜ冗長化が必要なのか？」「なぜバックアップが必要なのか？」を聞いてもいないのに熱く語ってくるくらいが丁度よく、「どの程度まで必要なのか？」を前もって徹底して話し合うこと重要であり、そのバランス感覚をしっかりと説明できるところに発注しよう。

	== 主な冗長化技術 ==		== 主な冗長化技術 ==

imported>GamerBook: /* 価格的な側面 */

2012-12-09T09:36:43Z

価格的な側面

← 古い版		2012年12月9日 (日) 09:36時点における版
23行目:		23行目:
	ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]などの登場で中小企業でも利用できる環境は整いつつあるが、それでも中小企業では金銭的に難しい話なのは変わりない。		ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]などの登場で中小企業でも利用できる環境は整いつつあるが、それでも中小企業では金銭的に難しい話なのは変わりない。

	なお、不毛な価格競争を行っている企業などでは目下の見積書を安くするため、冗長化が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者（利用者）側であり、ただ「安い」という理由で採用するのは危険であり、そのバランス感覚をしっかりと説明できるところに発注しよう。「なぜ冗長化が必要なのか？」「なぜバックアップが必要なのか？」を聞いてもいないのに熱く語ってくるくらいが丁度よい。		なお、不毛な価格競争を行っている企業などでは目下の見積書を安くするため、冗長化が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者（利用者）側であり、ただ「安い」という理由で採用するのは非常に危険である。「なぜ冗長化が必要なのか？」「なぜバックアップが必要なのか？」を聞いてもいないのに熱く語ってくるくらいが丁度よく、「どの程度まで必要なのか？」を前もって徹底して話し合うこと重要であり、そのバランス感覚をしっかりと説明できるところに発注しよう。

	== 主な冗長化技術 ==		== 主な冗長化技術 ==

2012年12月9日 (日) 09:34にimported>GamerBookによる

2012-12-09T09:34:49Z

← 古い版		2012年12月9日 (日) 09:34時点における版
18行目:		18行目:
	まっとうな企業の見分け方としては、例えば[[ペアプログラミング]]を実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。		まっとうな企業の見分け方としては、例えば[[ペアプログラミング]]を実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。

	== 価格的な側面 =		== 価格的な側面 ==
	冗長化には非常にお金がかかる。たとえば[[RAID-1]]を用いて[[HDD]]を冗長化するにしても、[[HDD]]は2個必要であり、さらにそれを制御する機構も必要となるため、最低でも2倍3倍以上の出費を余儀なくされる。いわゆる冗長化を突き詰めれば費用は倍々ゲームで増えるのである。		冗長化には非常にお金がかかる。たとえば[[RAID-1]]を用いて[[HDD]]を冗長化するにしても、[[HDD]]は2個必要であり、さらにそれを制御する機構も必要となるため、最低でも2倍3倍以上の出費を余儀なくされる。いわゆる冗長化を突き詰めれば費用は倍々ゲームで増えるのである。

2012年12月9日 (日) 09:34にimported>GamerBookによる

2012-12-09T09:34:13Z

← 古い版		2012年12月9日 (日) 09:34時点における版
1行目:		1行目:
	'''冗長化'''~~とは、事故災害などのリスクに備え、~~[[冗長]]に予備機材や予備回線を用意しておくことである。		'''冗長化'''（じょうちょうか）とは、事故災害などのリスクに備え、[[冗長]]に予備機材や予備回線を用意しておくことである。

	== 概要 ==		== 概要 ==
26行目:		26行目:

	== 主な冗長化技術 ==		== 主な冗長化技術 ==
	* [[RAID]] - ~~ストレージに対する冗長化技術。RAID~~-~~0は除く。~~		* [[RAID]] - [[ストレージ]]に対する冗長化技術。[[RAID-0]]は除く。
	* [[~~リタンダント電源~~]] - ~~コンピューターの電源に対する冗長化技術。~~		* [[リダンダント電源]] - [[コンピューター]]の[[電源]]に対する冗長化技術。
	* [[リンクアグリゲーション]] - ~~LANなどのネットワーク回線に対する冗長化技術。~~		* [[リンクアグリゲーション]] - [[LAN]]などの[[ネットワーク回線]]に対する冗長化技術。
	* [[フェイルオーバークラスター]]		* [[フェイルオーバークラスター]]

imported>GamerBook: ページの作成：「'''冗長化'''とは、事故災害などのリスクに備え、冗長に予備機材や予備回線を用意しておくことである。 == 概要 == === ハ...」

2012-12-09T09:32:49Z

ページの作成：「'''冗長化'''とは、事故災害などのリスクに備え、冗長に予備機材や予備回線を用意しておくことである。 == 概要 == === ハ...」

新規ページ

'''冗長化'''とは、事故災害などのリスクに備え、[[冗長]]に予備機材や予備回線を用意しておくことである。

== 概要 ==
=== ハードウェア ===
冗長化は主に[[ハードウェア]]に対して使われることの多い用語である。たとえば[[RAID]]による[[ストレージ]]中の[[データ]]の保護などがそれにあたる。また1台の[[コンピューター]]の内部でのみ冗長化をするのではなく、複数台の予備の[[コンピューター]]を用いて冗長化をする[[フェイルオーバークラスター]]など技術などもある。

とくに[[サーバーダウン]]などの緊急停止は連鎖的に[[システム]]を崩壊させることもあるため、個人や事務で使われる[[端末]]（≒[[パソコン]]）などよりも徹底した冗長化が求められることが多い。

ただし、ひたすら冗長化を追求しても[[単一障害点]]の排除は非常に難しいものであり、定期的な[[バックアップ]]こそが最も重要であると言われている。

=== ソフトウェア ===
また、冗長化は[[ハードウェア]]のみならず、[[ソフトウェア]]の開発時や[[システム]]の運用時の人的リソースについても同様である。

昨今では、この点を説明しないIT企業、またはそもそも理解していない者が[[ソフトウェア]]の開発案件を受注するケース多く、そのようなケースでは主力[[プログラマー]]の事故病気や、[[デスマーチ]]の発生などにより[[IT土方]]不足に陥ると、緊急招集された追加人員への説明や指導なども時間的な制約で追いつかず破綻するという事も多い。いわゆる「[[人月の神話]]」に書かれているそのものな状況である。

また、効率化を突き詰めるあまり、複雑な構成（[[密結合]]）にしすぎて天才的技術者がひとり抜けた後に発生したトラブルで誰も直せず崩壊した、などという目も当てられない事態に陥っている[[案件]]も非常に多いのも事実である。

まっとうな企業の見分け方としては、例えば[[ペアプログラミング]]を実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。

== 価格的な側面 =
冗長化には非常にお金がかかる。たとえば[[RAID-1]]を用いて[[HDD]]を冗長化するにしても、[[HDD]]は2個必要であり、さらにそれを制御する機構も必要となるため、最低でも2倍3倍以上の出費を余儀なくされる。いわゆる冗長化を突き詰めれば費用は倍々ゲームで増えるのである。

ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]などの登場で中小企業でも利用できる環境は整いつつあるが、それでも中小企業では金銭的に難しい話なのは変わりない。

なお、不毛な価格競争を行っている企業などでは目下の見積書を安くするため、冗長化が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者（利用者）側であり、ただ「安い」という理由で採用するのは危険であり、そのバランス感覚をしっかりと説明できるところに発注しよう。「なぜ冗長化が必要なのか？」「なぜバックアップが必要なのか？」を聞いてもいないのに熱く語ってくるくらいが丁度よい。

== 主な冗長化技術 ==
* [[RAID]] - ストレージに対する冗長化技術。RAID-0は除く。
* [[リタンダント電源]] - コンピューターの電源に対する冗長化技術。
* [[リンクアグリゲーション]] - LANなどのネットワーク回線に対する冗長化技術。
* [[フェイルオーバークラスター]]

== 関連項目 ==
* [[冗長]]
* [[IT土方]]
* [[ベンダーロックイン]]

== 参考文献 ==
{{reflist}}

{{stub}}