HCISとHCIは何が違うのか【第2回】

HCISとHCIを「システムの種類」と「情シスの気質」で比較する

HCIとHCISはどのように使い分ければいいのか。「システムの種類」と「情シスの気質」に注目し、企業の課題に沿った製品選定例を紹介する。

公開 2019年03月12日 05時00分

著者

森田晃章

[ネットワンシステムズ]

印刷する連載新着通知を受け取る

情シスの気質から考える「最適なHCIS／HCI」

　前回「HCIはなぜ誕生したのか　『統合』したからこそ起きた課題とその解決策とは」は、「ハイパーコンバージドインフラ」（HCI）の歴史を振り返りながら、狭義のHCIと「ハイパーコンバージドインフラシステム」（HCIS）の違いについて解説した。簡単におさらいすると、アプライアンスでの導入を前提とするシステムがHCIS、ソフトウェア定義ストレージ（SDS）を前提とする製品がHCIだ。

　第2回となる今回は、HCISとHCIについて企業の課題に沿った製品の選び方を解説する。本稿では、情報システム部門を思考／行動傾向別に、HCIS／HCIで稼働させるシステム（以下、利用システム）をデータの密集度別に分類し、それらの組み合わせごとにHCISとHCIのどちらの製品が適するかを示す。

併せて読みたいお薦め記事

製品を“買わない”選択肢もあるHCI

「HCIは万能」と過信せず、正しく理解しよう

情報システム部門と利用システムのタイプ別定義

情報システム部門のタイプ

　情報システム部門のタイプは、大まかに改革型と保守型に分かれる。タイプごとの優劣はなく、業務の内容や規模、利用ユーザー数（顧客数）などによってタイプが変わる。

改革型

新しい技術を積極的に取り入れ、システムの刷新への抵抗が少ない。運用負荷が減るのであれば、運用変更も受け入れる。仮にトラブルが発生した場合も迅速に対処できれば問題ない。

保守型

安定性を第一に考え、既存システムに継ぎ足して作り上げる。グループ会社や外部業者とのシステム連携に影響を与えないようにするため、できる限り運用は「塩漬け」する方針。トラブルは基本的に「発生してはいけない」。

利用システム（データ）のタイプ

　利用システムは2つのタイプに分けられる。データが基本的に分散しており、必要な時に必要な分だけデータを集める（または提供する）分散型と、一般的な基幹システムのように中心にデータを集めるデータベース（DB）中心型だ。

分散型

複数のシステムにデータを分散させて保持しており、システム同士がAPI（アプリケーションプログラミングインタフェース）などの標準的なインタフェースを通じて連携（疎結合）している。「できること」があらかじめ定義（カタログ化）されており、カタログの範囲であれば、自由にシステムを操作できる。データはシステムやサービス単位で管理していることが少なくない。一般的に運用やシステム変更の影響範囲は小さい。

DB中心型

RDB（リレーショナルデータベース）を中心にしたシステム。周辺システムがRDBを利用しており、RDBが止まらないことを何より重視する。基本的にデータを一元管理する。一般的に運用やシステム変更の影響範囲が大きい。このため「変更をしない」が基本的な考え方になる。仮に変更があってもできるだけ少なくする必要があり、作業も慎重に進めなければならない。

「運用を変えずに、HCIを導入したい」といった保守型の情シスに最適なHCIS／HCIは？

　次に「保守型の情シスがDB中心型システムに利用」など情シスの気質と利用システムの組み合わせごとに最適なHCIS／HCIを紹介する。

改革型　×　分散型

　改革型の情報システム部門が分散型システムを運用する場合には、HCISが向いている。一番のメリットはHCISの運用ツール（統合運用管理ツール）による情報システム部の運用負荷低減だ。統合運用管理ツールの役割は監視と管理の機能を集約し、サービスをカタログ化することにある。

　既存システムを全てHCISに置き換えることで、統合運用管理ツールによるシステム全体の管理を実現できる。これにより情報システム部は運用負荷を低減でき、働き方改革を進めやすくなる。空いたリソースを使ってこれまで忙しくて取り組めなかった、企業の成長につながる施策を進めることも可能になる。デジタル時代に適応するために組織やビジネスの在り方を再構成する「デジタルトランスフォーメーション」（DX）を意識したインフラ構築の検討が、その一例だ。

　システムの視点では、サービスをカタログ化することで少人数による大規模なインフラの管理が可能になる。

改革型　×　DB中心型

　改革型の情報システム部門がDB中心型システムを運用する場合にはHCIが向く。HCISにするとコストが増える可能性があるからだ。

　DB中心型システムで利用するRDBは、CPU数に応じたライセンス形態となっていることが少なくない。複数サーバの内部ディスクを共有して利用する方式の一般的なHCISの場合、サーバの数だけ課金対象が増える可能性がある。CPUとメモリ、ストレージをある程度自由に組み合わせられるHCIや、「VMware vSAN」「Dell EMC ScaleIO」などのSDSを利用するといいだろう。NetAppであれば「NetApp HCI」が該当する。

　システムの視点では、HCIの導入によって既存資産を使った新しい仕組みの構築がスムーズになる。例えば「IBM Spectrum Copy Data Management」をはじめ、バックアップやスナップショットなどで取得したデータを管理するコピーデータ管理ツールで、DB内の情報をアプリケーション開発者へ提供する。DBがどのような使われ方をしているか開発者自身が把握できるため、実態に即した効果的なアプリケーション開発につなげられる。

保守型　×　分散型

　保守型の情報システム部門が分散型システムを運用する場合にも、HCIが向く。運用を大きく変えることなく、HCI導入によるメリットを享受できるからだ。これまでと同じツールで既存システムを運用しつつ、HCIによってSDSなど「ソフトウェア定義型」システムへの切り替えを進めることができる。将来的に統合運用管理ツールと「AIOps」（AIによる運用自動化）のツールを併せて導入することで「従来の運用を維持しつつ、最新のテクノロジーを取り込む」といった対処ができるだろう。

　HCISを選ぶと、既存システムによる運用ツールと統合運用管理ツールで運用が分断されてしまう恐れがあるため、避けた方が無難だ。

保守型　×　DB中心型

　保守型の情報システム部門がDB中心型システムを運用している場合は、HCISでもHCIでもなく、「コンバージドインフラ」（CI）をお薦めする。CIは情報システム部門の負担を減らすために、ベンダーやシステムインテグレーター（SIer）が、複数社のサーバとストレージ、ネットワークの推奨製品について「製品の組み合わせ」「検証」「サイジングの設計」を実施した仕組みだ（連載第1回「HCIはなぜ誕生したのか　『統合』したからこそ起きた課題とその解決策とは」を参照）。

　CIであれば従来の運用を変えずにインフラ環境を整えられる。ベンダーが各インフラ製品の整合性を保証するので、ユーザー企業側での事前検証作業は不要だ。ソフトウェアのバージョンを固定して運用する「塩漬け」運用も問題ないだろう。会社のガバナンスとして、どうしてもクラウドにデータを出せなかったり、規制の関係上どうしても1つのシステムにデータを保持する必要があったりする場合もCIが向く。

HCIS、HCIによって違う「最終的なゴール」

　HCISとHCIは目指すゴールがそれぞれ異なる。

　HCISはそれ単体で完結したシステムであり、全てのインフラをHCISに置き換えるのが最終的なゴールといえる。運用負担低減のメリットを最大限享受できるが、単一ベンダーに統一せざるを得なくなる（ロックインされてしまう）リスクが発生する。他システムと連携していない（サイロ化した）システムを多く持つ企業の場合は、そもそも情報システム部門がサイロ化をやめさせる行動を起こす必要がある。

　HCIは、従来型の運用にできる限り沿った形で導入できるメリットがあるが、HCISほど運用は楽にはならない。運用の負担低減そのものは別の手段が必要になる。

　HCISもしくはHCIを入れればそれで解決ではない。そのことに注意し、自社に最適な製品を選択してほしい。