「冗長化」の版間の差分
imported>GamerBook 細 (→価格的な側面) |
|||
(5人の利用者による、間の5版が非表示) | |||
1行目: | 1行目: | ||
− | '''冗長化''' | + | '''冗長化'''(じょうちょうか、[[英語]]:redundancy)とは、事故災害などのリスクに備え、[[冗長]]に予備機材や予備回線を用意しておくことである。 |
== 概要 == | == 概要 == | ||
10行目: | 10行目: | ||
=== ソフトウェア === | === ソフトウェア === | ||
− | + | 冗長化は[[ハードウェア]]のみならず、[[ソフトウェア]]の開発時や[[システム]]の運用時の[[人的リソース]]についても同様である。 | |
− | + | 昨今では、この点を説明しない[[IT企業]]、またはそもそも理解していない者が[[ソフトウェア]]の開発案件を受注するケース多く、そのようなケースでは主力[[プログラマー]]の事故病気や、[[デスマーチ]]の発生などにより[[IT土方]]不足に陥ると、緊急招集された追加人員への説明や指導なども時間的な制約で追いつかず破綻するという事も多い。いわゆる「[[人月の神話]]」に書かれているそのものな状況である。なお、リアル土方の世界では事故死する者が発生する前提で見積もりを出していることが多い。 | |
− | また、効率化を突き詰めるあまり、複雑な構成([[密結合]] | + | また、効率化を突き詰めるあまり、複雑な構成([[密結合]])にしすぎて、天才的技術者がひとり抜けた後に発生したトラブルで誰も直せず崩壊した、などという目も当てられない事態に陥っている[[案件]]も非常に多いのも事実である。 |
まっとうな企業の見分け方としては、例えば[[ペアプログラミング]]を実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。 | まっとうな企業の見分け方としては、例えば[[ペアプログラミング]]を実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。 | ||
== 価格的な側面 == | == 価格的な側面 == | ||
− | 冗長化には非常にお金がかかる。たとえば[[ | + | 冗長化には非常にお金がかかる。たとえば[[RAID1]]を用いて[[HDD]]を冗長化するにしても、[[HDD]]は最低2個必要であり、さらにそれを制御する[[RAIDコントローラー]]などの機構も必要となるため、最低でも2~3倍以上の出費を余儀なくされる。いわゆる冗長化を突き詰めれば費用は倍々ゲームで増えるのである。 |
− | ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]] | + | ちなみに金融機関などの絶対に万が一が許されない分野では、[[データセンター]]まるごと冗長化されているのが一般的である。この[[データセンター]]レベルの冗長化の技術的な敷居は[[Amazon EC2]]などの登場で中小企業でも利用できる環境は整いつつあるが、それでも[[中小企業]]では金銭的に難しい話なのは変わりない。 |
− | + | なお、不毛な[[価格競争]]を行っている企業などでは目下の[[見積書]]を安くするため冗長化に関する部分が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者(利用者)側であり、ただ「安い」という理由で採用するのは非常に危険である。いわゆる「[[Write Once, Run Away]]」な「売り逃げ」が発生すること間違いなしである。 | |
+ | |||
+ | 「なぜ冗長化が必要なのか?」「なぜ[[バックアップ]]が必要なのか?」を聞いてもいないのに熱く語ってくるくらいが丁度よく、「どの程度まで必要なのか?」を前もって徹底して話し合うこと重要であり、そのバランス感覚をしっかりと説明できるところに発注しよう。 | ||
== 主な冗長化技術 == | == 主な冗長化技術 == | ||
29行目: | 31行目: | ||
* [[リダンダント電源]] - [[コンピューター]]の[[電源]]に対する冗長化技術。 | * [[リダンダント電源]] - [[コンピューター]]の[[電源]]に対する冗長化技術。 | ||
* [[リンクアグリゲーション]] - [[LAN]]などの[[ネットワーク回線]]に対する冗長化技術。 | * [[リンクアグリゲーション]] - [[LAN]]などの[[ネットワーク回線]]に対する冗長化技術。 | ||
+ | * [[スタッカブルスイッチ]] | ||
* [[フェイルオーバークラスター]] | * [[フェイルオーバークラスター]] | ||
+ | * [[事業継続計画]] - [[BCP (Business Continuity Planning)]] - [[BCP]] | ||
== 関連項目 == | == 関連項目 == |
2014年10月10日 (金) 05:53時点における最新版
冗長化(じょうちょうか、英語:redundancy)とは、事故災害などのリスクに備え、冗長に予備機材や予備回線を用意しておくことである。
概要[編集 | ソースを編集]
ハードウェア[編集 | ソースを編集]
冗長化は主にハードウェアに対して使われることの多い用語である。たとえばRAIDによるストレージ中のデータの保護などがそれにあたる。また1台のコンピューターの内部でのみ冗長化をするのではなく、複数台の予備のコンピューターを用いて冗長化をするフェイルオーバークラスターなど技術などもある。
とくにサーバーダウンなどの緊急停止は連鎖的にシステムを崩壊させることもあるため、個人や事務で使われる端末(≒パソコン)などよりも徹底した冗長化が求められることが多い。
ただし、ひたすら冗長化を追求しても単一障害点の排除は非常に難しいものであり、定期的なバックアップこそが最も重要であると言われている。
ソフトウェア[編集 | ソースを編集]
冗長化はハードウェアのみならず、ソフトウェアの開発時やシステムの運用時の人的リソースについても同様である。
昨今では、この点を説明しないIT企業、またはそもそも理解していない者がソフトウェアの開発案件を受注するケース多く、そのようなケースでは主力プログラマーの事故病気や、デスマーチの発生などによりIT土方不足に陥ると、緊急招集された追加人員への説明や指導なども時間的な制約で追いつかず破綻するという事も多い。いわゆる「人月の神話」に書かれているそのものな状況である。なお、リアル土方の世界では事故死する者が発生する前提で見積もりを出していることが多い。
また、効率化を突き詰めるあまり、複雑な構成(密結合)にしすぎて、天才的技術者がひとり抜けた後に発生したトラブルで誰も直せず崩壊した、などという目も当てられない事態に陥っている案件も非常に多いのも事実である。
まっとうな企業の見分け方としては、例えばペアプログラミングを実践しているなどの複数のチェックポイントはあるのだが、それらの現場レベルは発注者側からは見えにくいのも事実である。
価格的な側面[編集 | ソースを編集]
冗長化には非常にお金がかかる。たとえばRAID1を用いてHDDを冗長化するにしても、HDDは最低2個必要であり、さらにそれを制御するRAIDコントローラーなどの機構も必要となるため、最低でも2~3倍以上の出費を余儀なくされる。いわゆる冗長化を突き詰めれば費用は倍々ゲームで増えるのである。
ちなみに金融機関などの絶対に万が一が許されない分野では、データセンターまるごと冗長化されているのが一般的である。このデータセンターレベルの冗長化の技術的な敷居はAmazon EC2などの登場で中小企業でも利用できる環境は整いつつあるが、それでも中小企業では金銭的に難しい話なのは変わりない。
なお、不毛な価格競争を行っている企業などでは目下の見積書を安くするため冗長化に関する部分が省かれていることが多い。冗長化を怠った末に最終的に被害を受けるのは発注者(利用者)側であり、ただ「安い」という理由で採用するのは非常に危険である。いわゆる「Write Once, Run Away」な「売り逃げ」が発生すること間違いなしである。
「なぜ冗長化が必要なのか?」「なぜバックアップが必要なのか?」を聞いてもいないのに熱く語ってくるくらいが丁度よく、「どの程度まで必要なのか?」を前もって徹底して話し合うこと重要であり、そのバランス感覚をしっかりと説明できるところに発注しよう。
主な冗長化技術[編集 | ソースを編集]
- RAID - ストレージに対する冗長化技術。RAID-0は除く。
- リダンダント電源 - コンピューターの電源に対する冗長化技術。
- リンクアグリゲーション - LANなどのネットワーク回線に対する冗長化技術。
- スタッカブルスイッチ
- フェイルオーバークラスター
- 事業継続計画 - BCP (Business Continuity Planning) - BCP