第9章 · テクノロジ

二台にしたのに、同時に止まる？

「止まりません」と言いたい葵。しかし、構成図には同じ電源につながる二台がありました。速さ、費用、故障と復旧を比べ、出荷便の締切に間に合わない場合も含めて、業務への影響を説明します。

4つのテーマ14項目10の図解

この章の目次・学習項目

この章も、新卒コンサルタントの葵と先輩の佐伯が、大手メーカー「アステラ製作所」の受注・生産・出荷をつなぐ案件に取り組みます。

会話と図解で読み進め、詳しい説明は各項目で開けます。

STEP 01

一台に集めるか、役割を分けるか

自分の端末を替えても、待ち時間は減らなかった

処理の場所を見分け、構成の選択肢を比較する。

負荷の確認｜試行前の合同テスト

複数の拠点を想定して操作すると、一覧の表示が遅くなった。葵は出荷現場端末の問題だと思い、新しい機種でも試した。しかし待ち時間はあまり変わらない。

井上

開発会社のPM

端末を替えても同じなら、サーバ側と通信も確認したいです。遅くなった操作と、同時に使った人数を教えてください。

葵

新卒ITコンサルタント

端末だけ見ていました。向こう側の処理と通信も分けて確かめないと、改善策を選べませんね。

佐伯

先輩ITコンサルタント

その切り分けを、井上さんと進めよう。速い機械を買う話から始めなくてよかった。

テーマ 01

集中処理・分散処理

一台へ集中させる処理と、複数へ分散する処理を、管理のしやすさや障害の影響から比較した。

中心のコンピュータへ処理を集めるか、複数へ分けるか。管理のしやすさや故障の影響が変わる。

01処理を、どこへ置く？

集中処理主要な処理を一台などの中心へ集める

分散処理複数のコンピュータで処理を分担する

P2P｜Peer to Peer: 端末同士が対等な立場で、機能やデータをやり取りする方式。
クライアントサーバーシステム: 利用側のクライアントと、サービスを提供するサーバーに役割を分ける方式。

詳しい説明・条件・具体例

集中処理は管理をまとめやすい一方、中心への負荷や障害の影響を考える必要があります。分散処理は仕事を分けられますが、通信、データの整合性、運用が複雑になる場合があります。

P2P｜Peer to Peer: 端末同士が対等な立場で、機能やデータをやり取りする方式。
クライアントサーバーシステム: 利用側のクライアントと、サービスを提供するサーバーに役割を分ける方式。

森川

事業部長

一台へまとめるより、分散したほうがよいのでしょうか。

葵

新卒ITコンサルタント

障害の影響を分けられる一方、連携やデータの整合性を管理する仕事も増えます。今回の規模と運用できる体制で比べたいです。

井上

開発会社のPM

集中と分散、それぞれで何が止まるかを図にしましょう。台数だけの比較にはしないようにします。

テーマ 02

リクエスト・レスポンス

画面から要求を送り、サーバが処理して結果を返す。葵は待ち時間が起きる場所を、その流れに沿って確認した。

クライアントが要求を送り、サーバーが処理して応答を返す。必ずプログラムそのものを送るわけではない。

02受注一覧を開くときの往復

クライアントの要求一覧を取得したい、とリクエストを送る

サーバーの処理権限を確認し、必要なデータを取得する

クライアントへの応答レスポンスを受け取り、画面に表示する

詳しい説明・条件・具体例

リクエストは必要なデータや操作を求めるメッセージであり、常に「実行するプログラム自体」を送るわけではありません。WebサーバーはWebコンテンツ、メールサーバーはメールの送受信、ファイルサーバーはファイルの保存・共有を支えます。

小野

生産管理責任者

この端末がサーバで、こちらがクライアント、という見分け方ですか。

葵

新卒ITコンサルタント

機器の見た目ではなく、要求をする側と、処理して返す側という役割の名前です。

井上

開発会社のPM

この操作では、画面から要求を送って、サーバの結果を待ちます。どこまで届いたかを追いましょう。

葵

新卒ITコンサルタント

待ち時間の相談でも、その流れに沿って処理の担当を確認します。

テーマ 03

シンクライアント

出荷現場端末へデータをあまり置かない構成も候補に出た。葵は端末の管理負担と、通信が切れた場合の制約を並べた。

端末の機能を絞り、処理やデータの保管を主にサーバ側へ任せる。通信への依存も考える。

03端末とサーバーの分担

端末側入力・表示などを中心にする

サーバー側アプリ実行・データ保存を集中管理する

詳しい説明・条件・具体例

シンクライアントは、端末側の機能を絞り、多くの処理やデータ管理をサーバー側へ寄せる方式です。端末は主に入力や画面表示を担当します。

端末に重要なデータを残しにくくでき、紛失時の漏えいリスクを減らせます。ただし、端末の認証情報、画面表示、キャッシュなどの対策は必要で、「紛失しても絶対に漏えいしない」わけではありません。通信が使えないと業務に影響する点も考えます。

シンクライアントを「漏えいしない端末」と言い切らず、何を端末へ残し、何を中央で扱うかを確かめた。

テーマ 04

スケールアップ・スケールアウト

一台の能力を上げるか、台数を増やすか。葵はスケールアップとスケールアウトの違いを、負荷の場所へ対応させた。

スケールアップは1台の性能を上げる。スケールアウトは台数を増やす。

04二つの拡張方法

スケールアップ一台のCPUやメモリなどの能力を高める

スケールアウト台数を増やし、処理を分担させる

詳しい説明・条件・具体例

スケールアップは一台の能力の上限に影響されます。スケールアウトは、負荷分散やデータ共有など、複数台で動く設計が必要です。「台数を増やせば、どんなアプリでも自動的に速くなる」わけではありません。

高橋

経理担当

台数を増やす案のほうが、後から調整しやすそうですね。

葵

新卒ITコンサルタント

ただ、増やした台数へ処理を分けられる必要があります。そこは確認させてください。

井上

開発会社のPM

どこに負荷が集中しているかも見ましょう。一台を強くするスケールアップと、分けるスケールアウトのどちらが効くかは、その結果で考えます。

葵は端末、通信、サーバのどこで時間を使っているかを聞き、構成案ごとの効果と前提を整理した。買替えの提案を急がず、調べる順序を作れたことが、無駄な費用を防いだ。

ちょっと考えてみようサーバー一台のメモリを増やして処理能力を上げる。スケールアウト？考え方をひらく＋

スケールアップです。スケールアウトは、台数を増やして処理を分担する方法です。

STEP 02

速さだけでなく、使い続けられるかを見る

二つの会社が、違う測り方で「速い」と言う

品質と費用を、比較できる条件へそろえる。

構成案の評価｜ベンダーの回答を比較

二社とも「十分な性能」と書いていた。一社は一人での操作、もう一社は同時接続を含む測定だった。葵は速さの数字を、そのまま同じ列に並べていた。

佐伯

先輩ITコンサルタント

測り始めと終わり、データ量、同時利用数。そこが違えば、数字も違うよね。

葵

新卒ITコンサルタント

比較する条件を決めて、追加の確認を依頼します。

テーマ 05

レスポンスタイム・ベンチマークテスト

「応答時間」は、送信からなのか、クリックからなのか。葵は測定の始点と終点を具体化した。

利用者が待つ時間を測り、同じ条件のテストで性能を比べる。測る条件をそろえる。

レスポンスタイム: 要求を出してから応答が返るまでの時間。
ベンチマークテスト: 決めた処理や条件で測定し、性能を比較する方法。

詳しい説明・条件・具体例

システムの評価では、性能、信頼性、価格・費用などを合わせて見ます。すべてを最大にするのではなく、目的に必要な水準を決めます。

レスポンスタイム: 要求を出してから応答が返るまでの時間。最初の応答か処理完了かなど、測定の始点・終点を明確にします。
ベンチマークテスト: 決めた処理や条件で測定し、性能を比較する方法。実際の利用と負荷が近いかも確認します。

利用者一人で速くても、昼休みの同時アクセスで遅くなるかもしれません。データ量、同時利用数、ネットワークなどの条件をそろえて比べます。

田中

物流担当

私が押してから待った時間と、報告の応答時間が違う気がします。

葵

新卒ITコンサルタント

測り始める場所が違うかもしれません。クリックからなのか、送信してからなのかを確かめます。

井上

開発会社のPM

終わりも、応答が届いた時点か、画面に表示された時点かで違いますね。

葵

新卒ITコンサルタント

始点と終点、それから操作や件数をそろえましょう。ベンチマークの数字にも、測った条件を添えます。

テーマ 06

RASIS

性能のよさだけで選ぶと、管理や保守の条件を見落とす。葵はRASISの五つの観点から、確認事項を整理した。

信頼性・可用性・保守性・完全性・安全性の5つから、システムの品質を見る。

Reliability｜信頼性: 障害を起こさず、正しく動作する能力。
Availability｜可用性: 使いたいときに利用できる能力。
Serviceability｜保守性: 故障時に修理・復旧しやすいこと。
Integrity｜完全性: データの正確さや整合性が保たれ、勝手に壊れたり改ざんされたりしないこと。
Security｜安全性: 不正な利用や情報漏えいなどを防ぐこと。

詳しい説明・条件・具体例

Reliability｜信頼性: 障害を起こさず、正しく動作する能力。
Availability｜可用性: 使いたいときに利用できる能力。
Serviceability｜保守性: 故障時に修理・復旧しやすいこと。
Integrity｜完全性: データの正確さや整合性が保たれ、勝手に壊れたり改ざんされたりしないこと。
Security｜安全性: 不正な利用や情報漏えいなどを防ぐこと。

壊れにくさと、壊れてもすぐ戻れることは別の性質です。どちらも利用可能な時間を増やすことにつながります。

森川

事業部長

少し速い案と、保守しやすい案なら、どちらを選びますか。

葵

新卒ITコンサルタント

工場で困る場面から優先順位を決めたいです。性能だけでなく、RASISの観点で、安定性や管理、保守などの条件も並べます。

小野

生産管理責任者

不具合が出たとき、業務部門だけで原因を調べるのは難しいです。そこは重視したいですね。

葵

新卒ITコンサルタント

分かりました。一つの合計点に隠さず、その条件が選定へどう効くかを示します。

テーマ 07

バスタブ曲線

新しい機器なら当分故障しない、と考えかけた。葵は初期故障、偶発故障、摩耗故障の考え方を確認した。

故障率は、使い始め・安定期・老朽化で変わる。時期に合う点検や交換を考える。

05故障率と時間の関係

初期故障期: 製造や設計の不具合などが現れ、対処で故障率が下がっていく時期。
偶発故障期: 故障率が比較的安定する時期。
摩耗故障期: 物理的な摩耗や劣化により、故障が増える時期。

詳しい説明・条件・具体例

初期故障期: 製造や設計上の問題などによる故障が初期に現れ、改善・選別で減少していく時期。
偶発故障期: 故障率が比較的安定する時期。
摩耗故障期: 物理的な摩耗や劣化により、故障が増える時期。

この形をバスタブ曲線と呼びます。装置の典型的な傾向を表すモデルで、すべての機器やソフトウェアが同じ曲線になるわけではありません。

設置直後の確認と、使い続けた後の交換計画は別に必要だった。構成の評価へ、導入後の時間軸が加わった。

テーマ 08

TCO

初期費用の安さが目立つ見積りにも、保守、教育、管理、停止による損失などの費用がある。

購入費だけでなく、運用・保守なども含めた総費用。使い続ける間の支出まで比べる。

TCO｜Total Cost of Ownership導入から運用、廃棄までの総費用

06初期費用と、使い続ける費用

イニシャルコスト機器・ソフト購入、初期設定、導入など

ランニングコスト人件費、保守、電気、継続ライセンスなど

詳しい説明・条件・具体例

購入価格が低くても、毎月の管理や保守に費用がかかればTCOは高くなります。データの移行や廃棄時の消去など、終わりの費用も含めて比較します。

高橋

経理担当

最初は安くても、毎月の作業が増えるなら、その時間も見ておきたいです。

葵

新卒ITコンサルタント

保守、教育、管理に加えて、止まった場合や利用を終える場合も含め、TCOで比較します。

高橋

経理担当

誰の作業時間を含めたかも、分かるようにしてください。工場の作業が抜けやすいので。

葵

新卒ITコンサルタント

はい。購入費の欄だけを太字にする資料は、もうやめます。

性能だけでなく、信頼性、保守、使う期間の総費用を並べた。初期費用が安い案の運用負担も見えた。

高橋

経理担当

導入時に安くても、毎月こちらで行う作業は増えるんですね。その時間も費用へ入れましょう。

森川

事業部長

これなら、長く使ったときの話ができます。買う日だけで終わるものではありませんから。

ちょっと考えてみよう壊れた後の復旧のしやすさは、RASISのどの観点？考え方をひらく＋

Serviceability、保守性です。故障しにくさを表す信頼性と区別します。

STEP 03

予備があれば安心。その予備は一緒に壊れない？

二つあるのに、一度に止まる構成だった

冗長化と故障時の振る舞いを確認する。

障害時の設計｜構成図レビュー

構成図にはサーバが二つ描かれていた。葵が安心したところで、井上が二つの箱を囲んだ。

井上

開発会社のPM

これは二つとも、同じ物理機の上にある仮想サーバです。この機械が止まると、両方に影響します。

葵

新卒ITコンサルタント

箱が二つあれば、別々に壊れると思っていました。共通して使うものを確かめます。

佐伯

先輩ITコンサルタント

電源や回線も同じだね。図の数だけじゃなく、どこが一緒に止まるかを見よう。

テーマ 09

デュアルシステム・デュプレックスシステム

同時に動かすデュアルと、待機系へ切り替えるデュプレックスを比べる。待機の状態によって復旧までの時間も変わる。

デュアルは二系統で同じ処理を行って照合する。デュプレックスは現用系の故障に待機系で備える。

07冗長化の二つの構成

デュアル二つの系で同じ処理を行い、結果を照合する

デュプレックス稼働系と待機系を用意し、障害時に切り替える

詳しい説明・条件・具体例

冗長化は、一部が故障しても必要な機能を維持できるよう、余分な装置や経路を用意することです。デュプレックスの待機系が起動済みならホットスタンバイ、停止状態から立ち上げるならコールドスタンバイと呼びます。

「予備あり」の一言では分からない切替え条件を、契約と運用へ落とし込んだ。

テーマ 10

仮想化・仮想マシン

仮想マシンが分かれていても、物理機の故障では同時に影響を受け得る。葵はホストと仮想マシンを分けて図を読み直した。

1台の物理機上で、複数のコンピュータがあるように動かす。物理機の故障は共通の弱点になり得る。

08分かれたVMが、同じ土台を共有する

一台の物理サーバー

VM Aアプリ・OS

VM Bアプリ・OS

詳しい説明・条件・具体例

仮想化は、一つの物理コンピュータ上などで、複数の独立したコンピュータのような環境を作る技術です。その環境が仮想マシン（VM）です。

一方のVMだけの障害なら他へ切り替えられる場合がありますが、土台の物理サーバーが壊れれば、上のVMも一緒に止まり得ます。物理故障に備えるには、別の物理ホストなどが必要です。

ライブマイグレーションは、動作中のVMを別の物理サーバーへ移す技術です。保守などで停止時間を抑えるのに役立ちますが、稼働中の環境や接続条件が前提です。壊れて停止した機械から、必ず無停止で移せるわけではありません。

葵

新卒ITコンサルタント

VMが二つあるので、一つ止まっても残ると説明しかけました。物理機は共通ですね。

井上

開発会社のPM

ホストが故障すれば、両方に影響する可能性があります。仮想化と、故障への備えは別に見ましょう。

葵

新卒ITコンサルタント

ライブマイグレーションも、条件がそろって使えるものですね。便利な機能の名前だけで、止まらないとは約束しません。

テーマ 11

フォールトトレランス・フェールセーフ

故障しにくくする、故障しても続ける、影響を抑える、安全に止まる、誤操作を起こしにくくする。それぞれの狙いを、葵は工場の業務へ当てた。

故障しても動き続ける設計と、故障時に安全側へ移る設計。守りたいものに合う方法を選ぶ。

フォールトアボイダンス: 品質のよい部品や検証により、そもそも故障を起こしにくくする。
フォールトトレランス: 故障しても必要な機能を維持できるようにする。
フェールソフト: 一部機能を縮小・制限して、処理を継続する。
フェールセーフ: 故障したとき、安全な状態へ移るようにする。
フールプルーフ: 人が操作を誤っても、危険や故障を起こしにくくする。

詳しい説明・条件・具体例

フォールトアボイダンス: 品質のよい部品や検証により、そもそも故障を起こしにくくする。
フォールトトレランス: 故障しても必要な機能を維持できるようにする。
フェールソフト: 一部機能を縮小・制限して、処理を継続する。
フェールセーフ: 故障したとき、安全な状態へ移るようにする。
フールプルーフ: 人が操作を誤っても、危険や故障を起こしにくくする。

製造現場なら、故障を検知して加熱を停止するのはフェールセーフ、扉が開いていると加熱できないようにするのはフールプルーフの例です。何を守り、どこまで続けるかを先に決めます。

小野

生産管理責任者

取引先には、何も出ないより、受付できたと表示したほうが安心ではないでしょうか。

葵

新卒ITコンサルタント

実際には記録できていないのに、受け付けたと伝えるほうが、後で困らせてしまいます。

田中

物流担当

受け付けたはずの注文が消えたら、出荷の指示も出せなくなりますね。

葵

新卒ITコンサルタント

この場合は受付を止めて、理由と別の手段を伝えるほうが安全です。故障を防ぐ、耐える、影響を抑える、安全に止めることを、場面ごとに選びます。

葵は共通の故障点、切替え時間、止まったときに続ける業務を一覧にした。全部を止めないことが難しくても、影響を小さくする方法は選べる。

ちょっと考えてみよう二つのVMを一台の物理サーバーに置いた。物理サーバーの故障にも耐えられる？考え方をひらく＋

それだけでは耐えられません。同じ土台を共有しているため、両方が停止する可能性があります。

STEP 04

止まりにくさを、数字で確かめる

99％という数字の、残り1％を考える

故障間隔と復旧時間を分け、稼働率を説明する。

経営報告の準備｜サービスの継続性

葵は高い稼働率を大きく書いた。佐伯は「止まる時間が夕方の出荷に重なったら、どうする？」と聞いた。平均の数字だけでは、顧客の困り方は説明し切れない。

小野

生産管理責任者

始業前と、出荷便の締切直前では困り方が違います。止まったとき、今ある受注を確認する方法も残したいです。

葵

新卒ITコンサルタント

稼働率の計算と、工場が困る時間帯や復旧の手順は両方伝えます。

テーマ 12

MTBF・MTTR

故障が少ないことと、故障から早く戻ることを分けて見る。葵はMTBFとMTTRの時間の範囲を確認した。

MTBFは故障から次の故障までの平均稼働時間。MTTRは修理にかかる平均時間。

09稼働時間と修理時間の記録

回	稼働	修理
1	200時間	3時間
2	100時間	1時間
3	150時間	2時間

MTBF｜平均故障間隔: 故障と故障の間の、正常に稼働した時間の平均。
MTTR｜平均修理時間: 故障後の修理・復旧に要した時間の平均。

詳しい説明・条件・具体例

平均を計算する

稼働時間は200＋100＋150＝450時間。故障3回なので、MTBF＝450÷3＝150時間。
修理時間は3＋1＋2＝6時間。MTTR＝6÷3＝2時間。

MTBF｜平均故障間隔: 故障と故障の間の、正常に稼働した時間の平均。大きいほど故障しにくいと評価できます。
MTTR｜平均修理時間: 故障後の修理・復旧に要した時間の平均。小さいほど復旧が速いと評価できます。

森川

事業部長

故障が少ないものを選べば、復旧の準備は減らせますか。

葵

新卒ITコンサルタント

壊れにくさと、壊れた後に早く戻せることは別です。MTBFとMTTRを分けて確認します。

井上

開発会社のPM

予備部品や連絡体制を整える対策は、戻るまでの時間にも関わります。

葵

新卒ITコンサルタント

どちらを改善する費用なのかを示して、ご相談します。

テーマ 13

稼働率

稼働率の分母から修理時間を抜かしてしまわないよう、葵は稼働時間と停止時間を並べた。

動ける時間の割合。MTBFを、MTBFとMTTRの合計で割る。故障を減らすことと、早く直すことが効く。

稼働率MTBF ÷（MTBF ＋ MTTR）

詳しい説明・条件・具体例

150時間動き、2時間修理する例

平均の一周期は150＋2＝152時間。
利用できる割合は150÷152≒0.9868。
百分率では約98.7％。全体の記録でも450÷（450＋6）で同じです。

このモデルでは、故障しにくくしてMTBFを大きくすることと、復旧を速くしてMTTRを小さくすることの両方が、稼働率の改善につながります。

高い割合を示すだけでなく、何を停止と数え、どの期間の数字かを説明する。第5章で学んだ、数値の前提を確かめる習慣が戻ってきた。

テーマ 14

直列システム・並列システムの稼働率

直列では両方が必要、並列では少なくともどちらかが動けばよい。葵は図の経路を、故障する場合でたどった。

直列は全部が動く必要がある。並列は少なくとも一つが動けばよい。計算では故障の独立性などが前提。

10「両方必要」と「どちらかでよい」

葵

新卒ITコンサルタント

二台にすれば、どちらかが動く確率で計算できますね。

佐伯はサーバの四角ではなく、その下にある電源の線を示した。

佐伯

先輩ITコンサルタント

この電源が止まったら？

葵

新卒ITコンサルタント

二台とも止まります。同じ原因で壊れる部分が残っていますね。

葵

新卒ITコンサルタント

構成図の台数だけでは足りません。電源、回線、保存先も含めて、一緒に止まる場所を確認します。

佐伯

先輩ITコンサルタント

その確認があって初めて、計算の前提と実際の構成を比べられる。

直列：AもBも動く確率A × B

並列：両方とも止まる確率を除く1 −（1 − A）×（1 − B）

詳しい説明・条件・具体例

AもBも稼働率90％なら

直列は0.9×0.9＝0.81、81％。
並列では各装置の停止確率が0.1。両方停止は0.1×0.1＝0.01。
どちらかが動く確率は1−0.01＝0.99、99％。

葵

新卒ITコンサルタント

独立という前提で計算した値ですね。同じ電源で一緒に止まる構成へ、そのまま当てはめません。

数字の根拠と、現場の代替手順を一緒に説明できた。

小野

生産管理責任者

止まることがある前提で、何を続けるかまで決められたのは助かります。工場の訓練にも入れます。

次は、止まらず動いている間にもデータが正しいかを確かめる。移行テストで、葵たちは別の問題に出会うことになる。

ちょっと考えてみよう稼働率0.9と0.8の装置を並列にし、故障は独立。全体の稼働率は？考え方をひらく＋

1−（1−0.9）×（1−0.8）＝1−0.02＝0.98、98％です。

この章、おつかれさまでした！

安心という言葉に、条件を添えられた。

処理の分担、障害に備える構成、復旧するまでの運用を整理しました。けれど、システムが動いていても、記録が正しいとは限りません。データ移行と、在庫の同時引当のテストへ進みます。

この章を読み返す ↑

NEXT CHAPTER / 公開中10 データベース

前の章へ · 第8章ソフトウェア