すべての工場は、製造ラインの安定稼働を望んでおり、突然、停止してしまうような事態は避けなければなりません。そのために、普段から製造ラインを支える各種機器や設備の保守点検を徹底しています。しかし、どんなに頻繁かつ入念に製造ラインの保守点検を行っても、ある日突然、製造ラインが止まってしまうことがあります。ラインそのものではなく、ITシステムやネットワークがダウンした場合です。これは二次的な障害ではありますが、近年は、むしろこちらが原因で製造ラインが止まることが増えています。
ITシステムの問題には、製造機器の保守点検とはまったく異なる方法で、対応しなければなりません。サーバー、ネットワーク、ストレージに障害が発生した際も、生産をストップさせるわけにはいきません。
では、どう対応すればよいのでしょうか。第一に、生産ワークフローがITインフラストラクチャのどの部分にどれだけ依存しているのかを細かく把握することから始めなければなりません。
製造業のITインフラは生産ワークフローをエンドツーエンドでサポート
製造業のITインフラストラクチャは、ビジネスシステム、製造現場のアプリケーション、オペレーション、設備機器を連携させ、製品の製造を可能にするための一連のテクノロジーチェーンです。たとえば、ERP（エンタープライズ リソース プランニング）システムを通じて発注があり、MES（マニュファクチャリング実行システム）に手順の指示が送られ、オペレータがHMI（ヒューマン マシン インターフェース）システムを通じて手順を確認し、SCADA（監視制御／データ取得）システムによって各種機器による製造工程が調整されます。これら一連の流れは、すべて前のステップから次のステップへのハンドオフによって遂行されます。
この一連のチェーンのどこでダウンタイムが生じても、チェーン全体に影響が広がります。MESが止まってしまったら、注文データのが先に送られず、データヒストリアン（時系列の稼働データ管理ソフトウェア）の記録に不備が生じて品質管理に影響します。ID管理やネットワークに不備が生じると、たとえ物理的にバッチに問題がなくて生産が完了しても、誰もログインできなくてラインの最終確認ができません。
生産ワークフローが落ちていても、それをサポートするサービスはオンラインでアクセスでき、MESのウェブページが表示されて、実際にはデータベースにつながっていないという状況も生じがちです。MESとデータヒストリアンの間のインターフェースがダウンして、両システムが別々のバッチステータスを理解してしまうこともあります。これらが個別のアラームを発信してくれればよいのですが、実際には製造ライン全体の異常と認識され、オペレータは問題の詳細を直ちに知ることはできません。
製造業のITインフラストラクチャを設計する際は、この依存関係のチェーンを保護しなければならず、個別のサーバーやアプリケーションを保護しても意味がありません。
産業ITインフラの構成
産業ITインフラストラクチャは、通常のデータセンターと同じレイヤーで構成されています。つまり、コンピューティング、ストレージ、仮想化基盤、ネットワーク、ID管理システム、モニタリング、バックアップと、それに加えた、クラウドやエッジ環境で稼働するシステムです。データセンターなどとの最大の違いは、各レイヤーの連携が生産ライン全体に影響し、どこに問題が生じてもラインがストップするリスクがあるという点につきます。
コンピューティングと仮想化基盤がMESとSCADAのコンポーネント、データヒストリアンおよびデータベースをホストし、ストレージがプロセスデータ、バッチレコード、手順などを保管します。これらのデータには、通常、フェイルオーバー用にローカルのレプリカと、リカバリ用に別のコピーが用意されます。工場内のネットワークは、コントローラ、HMI、各種サーバーのトラフィックを処理し、このネットワークはメールやファイル共有、その他の業務データトラフィックのネットワークとは分離されていなければなりません。ID管理システムは、誰がMESにログインできるかを制御し、検品を承認し、設定の変更リクエストをコントローラに送信ます。そして、モニタリングとバックアップによって障害の発生がいち早く検知され、リカバリが可能になります。
これらのスタックには、IT（インフォメーション テクノロジー）とOT（オペレーショナル テクノロジー）のコンポーネントが含まれ、それぞれの領域が厳密に区分されます。両者を分ける最大の理由は、障害に対する許容度（トレランス）が異なる点です。たとえば、ITは必要な場合はリブートして、再起動までの5分程度が許容されますが、OTには通常それが許されません。
上記の各システムがどのように連携するかの仕組みは、ITとOTを融合させるIT／OTコンバージェンスで変革することができますが、それでも、ITとOTのトレランスの違いを埋めることはできません。
工場の物理的な環境も、しばしばITインフラストラクチャの課題になることがあります。各種機器が狭い棚に詰め込まれ、熱や埃によって、ハードウェアの寿命が縮んだり、電力供給が不安定になったりすることがあります。また、夜間の障害に対応できるようなITスタッフの体制を組んでいる工場も稀です。
だからこそ、インフラストラクチャの各レイヤーは、生産ワークフローの特定の依存関係にのみリンクさせる必要があります。たとえば、品質評価で必要となるバッチレコードはストレージアレイでのみ保持し、HMIとコントローラをつなぐパスはスイッチのみにするなどにより、障害発生時に直ちにフェイルオーバーが必要か、あるいは通常のリカバリプロセスで対応可能かを判断できるようにする必要があります。
クラウド待ちが可能なワークロードと不可能なワークロード
工場には、データセンターやクラウドとの接続が途絶えても、稼働し続けなければならないワークロードがあります。MES、SCADA、HMI、データヒストリアン、工場のデータベースやログインのためのIDサービスなどが、それに当たります。QMS（品質管理システム）、LIMS（ラボラトリー情報管理システム）の一部も、ダウンタイムが許容されません。
その他のシステムは、接続の遅延をある程度は許容するはずです。たとえば、ERP、PLM（製品ライフサイクル管理）、AIモデルトレーニング、レポートシステム、長期アーカイブなどは、ミリ秒単位のレスポンスを必要としません。通常は、接続が復活するまでの間、更新をキュー保存できる仕組みになっています。
この区別は、システムごとではなく、ワークロードごとに分けられなければなりません。以下の問いに答えることで、分類がより明確になります。
● アプリケーションが許容できるレイテンシはどのくらいか？
● WANがダウンしても引き続き稼働できるか？どのくらい稼働できるか？
● どのくらいデータを生成するのか？そのデータはローカルで維持すべきか（容量や規制上の理由で）？
● 必要なRTO（目標復旧時間）とRPO（目標復旧時点）は？
● そのデプロイメント（使用方法）をアプリケーションベンダーはサポートするのか？
個々のワークロードに対して、これらの問いに答えることで、ローカルと中央管理の分類がより明確になります。
製造業のワークフローはどこで実行されるべきか
オンプレミス、クラウド、ハイブリッドの設計の違いに応じて、ワークロードは異なる障害ドメインに配置されます。そのため、個々の生産ワークフローのニーズに合ったモデルを選択しなければなりません。
オンプレミスでは、機械の操作に直接関わるサービスを設備機器の近くに配置し、WANへの依存をなくさなければなりません。停電などで接続が途絶えても止めるわけにはいかないワークフローがこれに当たります。
一方、クラウド プラットフォームは、工場の現場で稼働させなければならないローカル ハードウェアを削減してくれます。その代わり、接続性、IDサービス、プロバイダの可用性、データ配置要件などのすべてが、障害モデルの重要な要素となります。業種によっては、製造ワークロードのデータがどこでどう処理されているかが、コンプライアンスの対象にもなります。
オンプレミスとクラウドを組み合わせて双方の利点を得ようとするのがハイブリッド設計です。工場の現場に不可欠なシステムはローカルに、同期の遅延を許容するものはすべてクラウドの中央システムで実行します。
オンプレミス、クラウド、ハイブリッドのいずれかが、そのまま各サイトの最適解になるわけではありません。WANリンクのプロビジョニングが安定して信頼性のある工場では、中央システムやクラウドサービスに重心が移るものの、それに完全依存することはできません。個々のワークロードの実際のニーズを見極めることが重要で、デフォルトアーキテクチャをすべてに適用することは避けるべきです。
製造現場の環境を評価する際は、まず生産ワークフローを検証し、依存関係を明確にしてから、各コンポーネントが実行されるべき場所を決定すべきです。それが、高可用性（HA）、バックアップ、障害復旧（DR）プランといった、より高度なインフラストラクチャ設計の土台となります。
業種によって異なるインフラストラクチャ ニーズ
アップタイムの目標が同じでも、何を製造しているかによって、インフラストラクチャの優先順位は変わってきます。たとえば、部品製造と医薬品のバッチプロセスでは、製造ラインの停止（ダウンタイム）の影響する範囲が異なります。
この違いは、生産ワークフローを細かく見ていけば、より明確になってきます。継続的なプロセス制御に依存する環境もあれば、同期化された組み立て工程、バッチレコード、大量のデータ収集などに依存する環境もあります。この違いがインフラストラクチャのレジリエンスに反映されなければなりません。
| 業種 | 典型的なワークロード | ダウンタイムの影響 | インフラストラクチャの優先順位 |
| 自動車 | 同期化された組み立て工程、ジャストインタイムの継続プロセス、ロボット制御 | ラインの停止は製造工程後半へのしわ寄せを数分で増幅 | 低レイテンシのMES／SCADA、迅速なローカル フェイルオーバー、工場内ネットワークの冗長性 |
| 食品関係 | バッチ、調理手順管理、コールド チェーン モニタリング（温度管理）、クリーン イン プレイス（定置洗浄）サイクル | 製品の劣化／損壊、バッチ不良、食品安全基準違反 | 安定したローカル データヒストリアン、正確なバッチレコード、決定的リカバリ |
| 医薬品／ライフサイエンス | バッチ処理、電子バッチレコード、環境モニタリング | バッチの廃棄、検疫／隔離 | 検証済みで監査可能なフェイルオーバー、レコードステータスを保持するリカバリ |
| 電子機器／半導体 | 製造装置制御、歩留まり／計測システム、クリーンルーム環境制御 | ウエハの廃棄、ツール最適性評価、歩留まりエクスカーション | 超低レイテンシ、高IOPSストレージ、ツールとMESのの緊密な統合 |
| 化学／プロセス工学 | 継続的プロセス制御、分散制御システム、安全計装システム | 安全未確認の早期シャットダウン／リスタート、環境曝露 | OT（オペレーショナル テクノロジー）ネットワークの分離、安全システムの隔離、信頼性の高いデータヒストリアン |
| 産業機器 | 独自の製造工程、ERP主導の発注、品質検査 | 注文の不達成、作業のやり直し、 | ローカルと中央システムのバランス、適度なRTO許容値 |
| 航空／防衛 | 追跡可能な特殊製造工程、構成制御、サプライヤーのデータ品質確保 | 製品の不適合、監査リスク、プログラムの遅延 | 長期データ保持、厳格なアクセス制御、追跡可能なリカバリ |
サーバーのリカバリは1つのステップにすぎません。自動車メーカーの工場では、MESは数分でオンラインに復旧すべきですが、データヒストリアンは独自のスケジュールで再接続し、プロセスデータの品質をフォローアップする必要があります。一方、製薬工場では、サーバーの復旧に10分ほどかかるものの、バッチレコードがその遅れを検知してバッチの出荷前の完全検査をトリガーしなければなりません。つまり、ワークフローのリカバリ目標は、サーバーのリカバリ目標と同一ではなく、業種ごとに異なる独自のコンテクストに応じた設計が重要になります。
製造業IT環境の故障原因
製造ラインは、インフラストラクチャに決定的なダメージがなくても、些細なことで停止するリスクがあります。サーバーがダウンしたり、ストレージに接続不良が生じたり、WANリンクが落ちたり、ちょっとした停電でも冷却システムがオフラインになったりします。どこも故障していなくても、データベースが容量不足になったり、定期的なアップデートによって想定外の不備が生じたりします。
わかりにくい依存関係に原因が隠されている場合もよくあります。DNS、ディレクトリ サービス、ライセンス マネージャー、証明書サービス、ベンダーのリモート アクセス ツールなどは、生産アプリケーションの域外にあって、何か明らかな問題が生じるまで誰も気づかないケースがほとんどです。それらに不備が生じると、サーバーが稼働しているのにもかかわらず、依存するアプリケーションにエラーが発生し、全体に影響が広がってきます。
複数の健全なアプリケーションがDNSエラーだけでオフラインになることは珍しくありません。証明書が期限切れのために、通常の定期リブート後に監視アプリケーションが起動しないこともあり、それが次のシフトで誰かがログインしようとするまで気づかれない可能性があります。
その他のよくある障害原因には、ライセンス サーバーのダウンがあります。定期的なWindowsアップデートがスタンドアロンのサーバーをリブートし、短時間のオフラインのために特にアラートを発しないケースがあります。それでも、オペレータのMESセッションが認証されなかったり、必要なライセンスを取得できなかったりして、生産ラインが停止してしまいます。問題が表面化した後で依存関係のチェーンを逆方向にたどっていくと、スタンドアロン サーバーが起動していないことが判明したりします。
これらの障害が生産ラインに与える影響はさまざまです。すべてを一概に「サーバーのダウン」として扱ってしまうと、リカバリプランに支障をきたします。たとえば、ホストのフェイルオーバーはVMやストレージを復旧できますが、DNSレコードの不足や停止したライセンスサービスを修復してはくれず、期限切れの証明書の再発行も行いません。よって、障害モデルの設計にはワークロード全体の依存関係を考慮することが欠かせません。
ITとOTの区分を明確にしてネットワーク レジリエンスを高める
ネットワークのレジリエンスはパスの冗長性から始まります。現場によってニーズは異なりますが、プラント ネットワーク スイッチの冗長性やデュアル アップリンクを追加したり、WAN接続を多岐に分化したり、セルラーバックアップリンクを追加したりするのも、レジリエンスを高めるために有効です。
複数サイトに展開する製造環境では、主要パスの接続が途絶えた際に他のリンクにトラフィックを迂回させて接続を維持できるSD-WANがよく使用されています。WANが利用できなくなっても、工場システムは（ワークフローが許す限り）ローカルで稼働し続け、重要度の低いデータは接続回復後に同期されるようキューに入れられる仕組みです。これは、工場と本部の間のどこかで通信プロバイダの光ファイバーが切断された場合に工場を稼働し続けるために必ず導入しなければならない仕組みでもあります。
このような冗長性は、本部のエンタープライズ トラフィックと工場のトラフィックが適切に分離されていなければ、機能しません。OTネットワークとITネットワークの間には産業用DMZ（非武装地帯）を設け、その境界を越えるものすべてを制御する必要があります。このIT／OTセグメンテーションにより、一方の側で発生した問題がもう一方の側に波及するのを制限します。さらに、アクセス制御とQoS（Quality of Service）設定により、本部のエンタープライズシステムで行われる大容量ファイルの転送やセキュリティスキャンが、工場のMESやSCADAトラフィックの帯域を圧迫することを防ぎます。
同じ原則は工場内部にも当てはまります。ストレージのレプリケーション、クラスタ管理、バックアップのトラフィックと、生産ワークフローのトラフィックは、パスや制御が分離されている必要があります。これらが、帯域が制限されたリンクを共有している場合、大規模なバックアップやストレージの再同期が、生産ワークフローを維持するために必要なトラフィックと競合してしまいます。アラートが表示される前に、レイテンシ依存の高いワークロードで直ちにその影響を実感することになります。
デュアルWANやSD-WANを基盤とした設計は、工場のシステムを接続障害から保護します。ただし、これはローカルのMESサーバーをハードウェア障害から保護するものではなく、またローカル ストレージの高可用性を保証するものでもありません。これらには、また別のアーキテクチャ レイヤーが必要になります。
HA、バックアップ、DRは別もの
HA（高可用性）／同期レプリケーション、バックアップ、DR（障害復旧）は、それぞれ異なる障害に対応するジョブであり、それらを混同しないように気をつける必要があります。
HAは、ホストやストレージ、ローカル インフラストラクチャ パスにエラーが生じても、ワークロードを引き続き利用可能にするための仕組みです。同期レプリケーションによって、現行データの状態が別のノードでそのまま維持され、障害が発生しても通常のリストアプロセスを待たずにワークロードを実行し続けることができます。つまり、HAの目標は、障害発生から再稼働までのギャップをなくす（あるいは最小限に抑える）ことです。
この仕組みは完全無欠ではありません。レプリケーションは現行ステータスをそのまま保持するので、もし誤ったデータ更新があれば、当然それも保持します。誤削除やデータ破損から、ランサムウェアに暗号化されたファイルまで、二次ノードに直ちにレプリケートされるので、メインのノードに問題が発生すれば、同じ問題が二次ノードでも発生してしまう可能性が高いです。
バックアップは障害への対策を別の角度から補強します。製造環境には、本番環境とは別にリカバリ専用のコピーが必要であり、これはHAクラスタの認証からも独立している必要があります。管理者アカウントに不正アクセスがあった場合に、バックアップも同じアカウントに管理されていたのでは意味がありません。すべての組織は、個々のセキュリティ要件にもとづき、イミュータブル、オフライン、あるいは完全隔離のバックアップコピーを備える必要があります。
バックアップを取るスケジュールには、実際の生産ワークフローに合わせて計算されたRPOとRTOが反映させなければなりません。毎晩確実にバックアップを取れば、データがきちんとコピーされたことは保証されますが、アプリケーションがリストア後に正しく機能することまでは保証されません。リストア後に依存関係が維持されていない場合や、必要なRTO内で完全なワークフローを再稼働できない可能性もあります。これらの課題は、単にバックアップを取るだけでなく、リカバリテストを実践することで解決しなければなりません。
DRは、ローカルのHAドメインの範疇を超える障害への対策を補強します。たとえば、長期にわたる停電、火災被害、水害、大規模なネットワーク障害などは、メインクラスタと二次クラスタのどちらも同時にオフラインにしてしまう可能性があります。現場レベルでのリカバリとホストレベルのHAには別々のプランニングが必要です。現場レベルの二次クラスタはローカルで可用性を保証してくれますが、工場全体が災害に遭い、2クラスタが両方とも影響を受けた場合は何の役にも立ちません。
リカバリ戦略は以下の3つの課題を解決しなければなりません。
1．ワークロードはローカルのインフラストラクチャ障害に耐えるか（HAで十分対応できるか）？
2．直近の健全なバックアップに復元できるか（バックアップで十分対応できるか）？
3．サイト全体が利用不可になった場合、生産ラインを維持あるいはリストアできるか（DRで解決できるか）？
実際の要件は、業種、所在地（地理的要件）、規制要件によって異なります。規制要件は、組織が所属する地域や国によって、さまざまなレベルのガイドラインや法規制が適用される可能性があります。インフラストラクチャの冗長性を確保すると同時に、リカバリ手順やテスト結果などをきちんとドキュメント化しておくことが重要になります。
2ノードクラスタの高可用性
HA（高可用性）を確保するためのもっとも一般的な方法は、2ノードクラスタを活用することです。2ノードクラスタとは、2つのサーバー間でリアルタイムのレプリケーションを実行し、1つに障害が発生したら、もう1つがすぐに同じデータで稼働できるようにする仕組みです。
2ノードクラスタの実装方法は、両ノードが連携できなくなった場合にどちらがI/Oを受け持つか（クォーラム）を決定するメカニズムによって、次の2通りに分けられます。1つ目の方法は、小型のVMかクラウドインスタンスを軽量のウィットネス（仲裁役）として設置し、決選投票を仕切らせるやり方です。2つのノードのうち、このウィットネスと通信を維持していたほうがI/Oを引き継ぎます。この方法によって、両ノードが同じデータを書き込んでしまったり、スプリットブレインシナリオ（両方が同時に自己を正規ノードだと認識してしまう状況）を回避できます。
2つ目の方法は、ウィットネスを置かずに、両ノードが専用リンクを通じて相互に直接監視し合うハートビート方式です。この方法は、ウィットネス役として余計なコンポーネントを追加しなくて済む代わりに、相互リンクの安定した接続性に完全依存するので、どちらを選択するかは個々の環境や要件によります。どちらの方法も、StarWind VSANを使用して実装することができます（詳細はクライムにお問い合わせください）。
製造業のIT環境が、どのようなプラットフォームを基盤とすべきかは、リカバリ要件に拠るところが大きいです。具体的なソリューションの選択を決定する際は、環境の設計に関わる以下の重要な要素を事前に検討すべきです。
● 現場のWANの信頼性
● デプロイ対象となる工場／拠点数
● 既存のサーバー／ストレージ ハードウェア
● 社内スタッフのインフラストラクチャに関する専門知識
● アプリケーションのベンダーサポート
● 本番環境データの今後の拡大予測
● バックアップとリカバリの要件
● リモート管理とサポート要件
● マシンビジョンやAIワークロードの今後1、2年の成長予測
これらの評価によって、既存のハードウェアを再利用すべきか、それとも交換すべきかの判断も可能になります。
前述のStarWind Virtual SANのようなソフトウェア定義型ストレージと既存のサーバーを組み合わせるアプローチは、十分な性能を持つハードウェアと、それを運用するための社内の専門知識がすでに備わっている場合に有効です。これは、単一の工場や小規模な環境においてもっとも実用的です。
一方、複数拠点にわたる標準化が重要である場合、再利用価値のある既存のハードウェアがない場合、あるいはインフラとサポートを単一のベンダーに一元化することで運用が簡素化される場合は、StarWind HCIアプライアンスのような統合型プラットフォームが適しています。
このような選択は、工場の実際の運用状況にもとづいて行うべきです。単一の拠点では、ハードウェアの柔軟性がメリットとなる一方、複数拠点では、標準化された導入と一元化されたサポートの方が重要となる場合が多いと思われます。
プランニングはサーバーではなくプロセスを基準に
これまでの議論はすべて同じ要点に帰着します。つまり、稼働し続けなければならない本番プロセスを中心に計画を立て、サーバー、ネットワーク、ストレージ、WANの設計はそこから導き出すべきだということです。
間違ったワークロードを保護するクラスタ、あるいは正しいワークロードを保護していても再同期中に何が起こるかを考慮していないクラスタは、本来解決すべき問題を実際には解決できていないことになります。
HA（高可用性）、バックアップ、DR（障害復旧）は、それぞれ異なる角度から障害の対応するものであり、相互に補完こそすれ、代替できるものではありません。これらを、相互に代替可能なオプションとして環境を設計すると、隠れた問題が表面化するまで気づかない重大な抜け穴が生じてしまいます。
HA、バックアップ、DRはIT環境を守る「三本の矢」であり、それらを組み合わせて製造ラインのプロセスをいかに保護し続けていくかを考えることが重要です。
RSSフィードを取得する
