特集・ブログ
20世紀後半から2度のブームを経て21世紀に入り、現在第3次ブームのなかにあるとされる AI（人工知能）。 技術的には、ビッグデータを用いた機械学習にはじまり特徴量をみずから習得するディープラーニングが登場し、現在に至ります。 こうしたなか、AI活用のハードルを下げデータサイエンティストがいない企業にも道を開くものとして期待されているのが、"AutoML"機能を搭載した最新の AIソリューションです。 AutoML は、時間と手間のかかる機械学習のモデル作成・調整・最適化などを自動化するプロセスです。 AutoML を利用することで劇的な業務効率化が期待できます。 そして、AIソリューションの代表であり、先駆的存在として知られる H2O Driverless AI（以下 DAI）は、グローバルでの知名度はもとより、最近は国内でも注目されつつあります。 そこで本記事では、DAI を取り扱う国内AIソリューションベンダーの1つである、日本アイ・ビー・エム株式会社 ハイブリッドクラウド＆AIシステムズセンターの河井 裕 氏に、DAI を用いた AutoML への取り組みについてお聞きしました。 Index 機械学習からのアーリーアダプターとDXで動き出したフォロワーが混在 OSSの先端AIソリューションであることが決め手 導入効果を最大化するハードウェアなど、多彩なオプションをフルスタックで取り揃え この記事に関するお問い合わせ 関連情報 機械学習からのアーリーアダプターとDXで動き出した フォロワーが混在 近年、拡大成長傾向にある国内 AIシステム市場は、コロナ禍の影響が懸念される2020年以降も引き続き大幅な高成長が続くと予想されています。 こうしたなか、河井氏によると、AI導入についての問い合わせや相談をしてくる企業は大きく2パターンに分かれると言います。 1つは「AI活用の効率化を求めるアーリーアダプター」で、以前から機械学習に取り組んでいて社内に知見を有する人材もおり、AutoML による効率化メリットも理解している企業。 もう1つは、「新規でAI活用を検討するフォロワー」で、DX を進めたいと焦るなかで AI活用に興味を持つが、知見を有する人材が少ない企業。 やりたいことと予算のギャップが大きく、導入にいたらないケースも多いとのことです。AutoML を搭載した AIソリューションの登場は、こうしたフォロワー企業にも AI活用の道を開くため、AIシステム市場の高成長を実現する上でもカギとなる存在と言えそうです。 OSSの先端AIソリューションであることが決め手 IBMコーポレートと DAI を提供する H2O.ai との間でパートナーシップが締結されたのは2017年7月。それを受け2018年7月からグローバルで DAI の販売を開始。日本国内でもはじめてとなります。 その後も日本アイ・ビー・エムからのリクエストが H2O.ai に採用され、日本語版の開発や Webマニュアルの日本語化など、同社が DAI の国内販売に大きく貢献しています。 ちなみに IBM の AIソリューションといえば「IBM Watson」が有名ですが、主としてオンプレミス環境で利用される DAI に対しこちらは主にクラウド型で提供されます。 特に国内企業の "情報セキュリティの観点から、手元で機械学習をおこないたい" というニーズに応えるにはオンプレミスの方が向いており、顧客企業に多様な選択肢を提供する上でも、DAI の取り扱いは自然な流れだったと言えそうです。 数ある AIソリューションのなかから DAI が選ばれたのには、以下の4つの理由がありました。 1. 知名度・実績 AutoML を搭載する AIソリューションの先駆けである DAI は、グローバルで圧倒的な知名度を誇ります。 データサイエンティストのスキルを必要とするモデル作成を自動化し、AI予測分析の効率を劇的に改善することから、FORTUNE 500 に名を連ねる企業222社を含む1万4000社以上が利用するなど、導入実績もトップクラスです。 2. オープンソースソフトウエア（以下OSS)として最先端を維持 DAI は OSS の機械学習エンジンを搭載し、そのソースはもちろん公開されています。 このため世界有数のデータサイエンティスト・コミュニティ「kaggle」との関係も深く、世界中のトップクラスのデータサイエンティストが開発に参加する形で日々ブラッシュアップされ、常に最先端を走りつづけています。 3. GPUを用いた高速性 AutoML で多数のモデルを効率よく作成する上で、ハードウェアの処理能力は高いにこしたことはありません。 DAI は他社の AIソリューションに先駆け、GPU の能力を最大限に引き出すことで処理を高速化することに成功。ビジネスのスピードアップを求める企業にとって最適なソリューションを提供します。 4. 説明性・納得性 特徴量加工やパラメータチューニングの自動化によるモデル開発の効率化とならぶ提供価値と言えるのが、生成されたモデルについての優れた説明性です。 その部分がブラックボックスとなってしまう AIソリューションも多いなか、学習結果をきちんと説明している DAI の場合、モデルの意味を理解してスキルアップを図っていくことが可能です。 導入効果を最大化するハードウェアなど、多彩なオプションをフルスタックで取り揃え DAI を取り扱うベンダとして日本アイ・ビー・エムならではの強みと言えるのが、ユーザー企業の多様なニーズに応える製品やサービスのポートフォリオです。 ハードウェアについては、高速 GPU に加え、NVLink 対応の Power CPU を搭載する「IBM Power Systems AC922（以下AC922）」を提供。トライアンドエラーをスピード重視で繰り返す必要がある DAI環境として抜群の相性の良さを発揮し、AI活用の効率の最大化を実現します。 これらは、ソフトウェア・ハードウェアからクラウド基盤、さらにはサポートを含むソリューションまで、フルスタックで取り揃える IBM ならではの強みと言えます。 加えて、環境構築はもちろん、活用フェーズにおいて個別企業のニーズにあわせた QAサービスを一定期間提供するなど、AI活用を確実に成功へと導く充実サポートについても提案します。 DAI on AC922を体験できる！セキュアなPoC環境をご用意 AC922 は、NVIDIA の高速 GPU「Tesla V100」を最大6枚搭載可能なほか、世界で唯一 NVLink2.0 のインターフェースを搭載する CPU Power9 を2基搭載。さらに、CAPI2.0＋PCIe Gen4 などにより、圧倒的なパフォーマンスを実現しています。 実際に AC922上で DAI を利用してそのパフォーマンスを試してみたい……という企業にぜひお勧めしたいのが、エヌアイシー・パートナーズの PoCサービスです。 下図スペックの環境を、インターネットVPN 経由でセキュアに利用できることから、製薬会社、製造業、通信会社など大手企業を中心に人気を集めています。 AIツールとして、ここで紹介した DAI に加え、IBM Maximo Visual Inspection （旧 IBM Visual Insights）も搭載。数値データ分析だけでなく、画像データ分析のトライアルも可能です。 ハイスペック環境を無料で2週間お試しできるので、大量のデータを保有し AI分析のための環境を検討中の企業は、お気軽にエヌアイシー・パートナーズに相談してみてはいかがでしょう。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1) (ブログ) - Driverless AI で競馬の予測 (回帰分析) に挑戦しました。 AIによる需要予測は、どこまで使えるのか？成功と失敗の分岐点を解説 (コラム) - 需要予測に成功したケースと失敗したケースの違いとともに、その分岐点がどこにあるのかを考えます。 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) - 機械学習の活用が進む現状。導入の課題とその解決策までをまとめて紹介します。 Driverless AI ご紹介資料 (資料) ※会員専用ページ - IBM i や AIX ユーザへの提案のポイントを取り纏めた資料です。 IBM AI ソリューションの事例ご紹介（IBM PowerAI Vison、Driverless AI）(事例) ※会員専用ページ - 業種毎の活用ケースや導入事例をはじめ、案件発掘事例についてご紹介しています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
数年前からその高速性が注目を集めていたオールフラッシュストレージですが、ここにきて大きく市場が伸びています。 以前は、特に高速な処理が必要なデータベースなどの特定用途に導入されるケースが多く見られましたが、SSD の低価格化とともに、より汎用的な用途で導入されるケースが増加。従来の HDDストレージとポジションが逆転し、「基本的にはオールフラッシュストレージを検討し、バックアップなど容量が大きく、アクセス頻度が少ないものに HDD を利用する」スタイルが一般的になりつつあります。 様々なベンダーがオールフラッシュストレージを展開するなかで、屈指の高いシェアと高い評価を誇るのが「IBM FlashSystem」です。 他製品との比較において、レイテンシ―が低く高速であることが最大の利点。加えて、データ圧縮などによるストレージ基盤の効率化やマルチベンダー・マルチクラウドへの対応…など、魅力の多い IBM FlashSystem について、その特長や活用シーンをまとめて解説します。 Index IBM FlashSystemの2大特長を支える独自技術 エントリーからハイエンドまで、幅広い要件に対応できるラインナップ IBM FlashSystem ならここまでできる！活用シーン別にみる導入メリット オールフラッシュストレージ選定の有力候補に この記事に関するお問い合わせ 関連情報 IBM FlashSystemの2大特長を支える独自技術 IBM FlashSystem の魅力は、大きく「壊れにくいこと」「性能が落ちないこと」の2つ。これらを主にハードウェアベースでの設計・制御によって実現していることが特長と言えます。 そしてその中核を担うのが、IBM が特許を持つ高速かつ長寿命のフラッシュモジュール「FlashCore Module（以下、FCM）」です。 FCM は、モジュール単位ではなく1つのモジュール内に搭載されているチップ単位で RAID を組むため、チップが障害を起こしただけではモジュール交換の必要なく、高可用性（＝壊れにくい）につながります。さらに FCM は、ハードウェアベースでのデータ圧縮を実現しており、コントローラに負荷をかけずに処理速度を維持したままデータ量を削減できます。 設計面でも様々な配慮がされています。 例えば、フラッシュストレージでは書き込み処理のための余剰領域が必要ですが、一般的には全体の数％程度にとどまるところ、IBM FlashSystem では全体の20％強をシステムで自動的に確保します。これにより、余剰領域不足のために突然性能が大きく下がる「Write Cliff（書き込み処理性能ダウンの崖）」を回避し、常に一定以上の性能が担保されます。 ベンチマークなどの検証環境だけでなく、実際の利用シーンの中でもしっかりスピードが出るような設計となっています。 オールフラッシュストレージは、製品ごとの「クセ」が強いものが多く、それぞれの特性を理解してチューニングしなければ「思ったような性能を得られない」「極端に遅くなってしまう」といったことも少なくありません。 IBM FlashSystem は、その特性をあまり意識しなくても「普通に使えば、一定以上の性能が出る」ことが大きなアドバンテージであり、使いやすい製品に仕上がっていると言えるでしょう。 エントリーからハイエンドまで、幅広い要件に対応できる ラインナップ IBM FlashSystem のラインナップは、エントリーモデル（5010/5030/5100）、ミッドレンジモデル（5100/7200）、ハイエンドモデル（9200）と幅広く展開され、様々な要件に対応できます。上述の FCM を選択できるのは5100以上のモデルとなりますが、そのほかはデータ圧縮や重複排除など必要な機能と、性能要件をベースに選定すれば問題ありません。 すべてのモデルが同じソフトウェア「IBM Spectrum Virtualize」をベースに動作するため、互換性が高く、移行・拡張時もスムーズです。 また、オールフラッシュストレージでは SSD の耐久性が問題になりますが、IBM FlashSystem では、エントリーモデルであっても耐久性が高いパーツを採用。「コストを抑えたモデルを選んだら、パーツの耐久性に問題があった」などのリスクがなく、どのモデルもパフォーマンスと耐久性を兼ね備えています。 IBM FlashSystem ならここまでできる！ 活用シーン別にみる導入メリット では、IBM FlashSystem のメリットについて活用シーンとあわせて紹介しましょう。 高速なデータ圧縮で、データベース・テキストのデータ量を大幅削減 上記で紹介した FCM のデータ圧縮が適しているのが、データベースやテキストデータの圧縮です。特にデータベースでは、データ量を7～8割削減※という試算もあり、大きな効果を期待できます。 ハードウェアベースで処理を行うため、データ量やモジュール数が増えても性能が落ちません。 ※出典：IBM 季刊誌「ProVISION No.77」より 仮想環境・リモートデスクトップ環境で効果大！重複排除機能も搭載 データ圧縮と似た機能と思われがちな重複排除ですが、その役割は大きく異なります。 こちらは、仮想サーバーを複数台立ち上げている仮想環境や、クライアントOS を大量に利用しているリモートデスクトップ環境などで有効です。サーバーやデスクトップを複数台稼働させたとしても OS のデータはほぼ同じため、重複排除によりデータを大幅に削減できるのです。 IBM FlashSystem は、データ圧縮と重複排除の両機能を搭載していることがメリット。用途にあわせて使い分けることができます。 複数ベンダーのストレージを一元管理できる「ストレージ外部仮想化」 「既存のストレージもそのまま使い続けたい、管理負荷は最小限に抑えたい」、そんな要望に応えるのが、IBM FlashSytem の「ストレージ外部仮想化」機能です。 スイッチを介して IBM FlashSystem に接続することで、他社のストレージであっても一元管理できます。重複排除やデータ圧縮など、IBM FlashSystem ならではの機能も同様に使えるようになります。 ストレージ間のデータ移動も容易になる上、データの自動階層化機能「EasyTier」を使えば「比較的古い・低速なストレージに利用頻度の低いデータを配置する」、また「比較的新しい・高速なストレージに利用頻度の高いデータを配置する」、といったことも簡単に設定できます。 オールフラッシュストレージ選定の有力候補に 2013年にリリースされた IBM FlashSystem ですが、リリース当初の性能面を重視したラインナップから、近年は上述したデータ圧縮や重複排除、ストレージ外部仮想化などの機能を搭載し、市場のニーズに応えるラインナップへと大きく変化を遂げています。 さらに、パブリッククラウド上で展開できる「IBM Spectrum Virtualize for Public Cloud」とあわせて利用すれば、ハイブリッド・クラウド環境として一元管理することも可能です。 ストレージ最適化やクラウド連携など、エンドユーザの目線でより活用しやすいストレージへと進化する IBM FlashSystem。今後のバージョンアップにも期待できます。 オールフラッシュストレージに必要な機能が揃い、クセのない設計でパフォーマンスを活かすことができる上、チューニング次第でさらに性能を伸ばすことも可能です。幅広いラインナップで、汎用的な用途からスピードを重視する構成、複数ストレージの一元化、クラウドとの連携まで、様々なシーンに対応。 オールフラッシュストレージを選定する際は、まず IBM FlashSystem を検討してはいかがでしょうか? この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM ストレージ製品 (製品情報) - ストレージ機能のソフトウェア化を実現した SDS製品 (Software Defined Storage) も含め、幅広いラインアップを取りそろえています。 全包囲網。。。最新 IBMストレージ 概要 (ブログ) - 今回は IBM の最新情報を交えつつ、IBM のストレージ製品の概要をご紹介させていただきます。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
IBM Power で基幹システムを運用する国内企業の多くは、ハードウェアの EOS やシステムを熟知した人材の退職といった課題に頭を悩ませていますが、ここ最近新たな悩みが加わっているようです。 データセンター事業者がビジネスの選択・集中を進めた結果、IBM i や AIX を扱うデータセンターが減少し、行き場を失うケースが増えているのです。 クラウドファーストが既定路線となるなか、コロナ禍も重なりオンプレミス廃止を検討する企業が増えていますが、いまさら自社内にオンプレミス構築することは考えづらい状況です。 こうした企業に向けて、末永く安心して利用し続けられる IBM i や AIX の環境をクラウド型で提供するのが、エヌアイシー・パートナーズ株式会社（以下 NI＋C P）の「Cloud Power」です。 以下では、IBM Power をオンプレミスで利用する企業や、こうした企業を支援するパートナー企業にとってのメリット（特長）にフォーカスしつつ、具体的な導入事例についても紹介します。 Index 事業者統合が進むなか、データセンターサービスの選択肢が限定される傾向に 国内企業のニーズに寄り添う人気の IaaS「Cloud Power」 実際の導入事例に見る「Cloud Power」活用シナリオ 再販パートナーと一体になって充実サポートを提供 この記事に関するお問い合わせ 関連情報 事業者統合が進むなか、データセンターサービスの選択肢が 限定される傾向に ここ数年の国内 IaaS/PaaS 市場規模（事業者売上高ベース）は大幅に拡大し、2021年以降も引き続きハイペースで拡大し続けるものと予測されています。直近では、これまで取り残されていた感もあった金融業の勘定系システムや一般企業の基幹系システムについても、クラウド移行を検討するケースが。 一方、データセンター市場においては大手データセンター事業者による中小規模事業者の買収が進み、AWS・Azure・Google Cloud など主要クラウドベンダ向けのハイパースケールデータセンターの開発・運営に資本が集中投下されています。 こうしたメガトレンドのなかで IBM i や AIX のデータセンタービジネスが縮小し、国内企業に影響がおよんでいるというのが、冒頭で解説した事象の背景です。 データセンター事業者のホスティングサービスが利用できなくなることも深刻ですが、オンプレミスで IBM Power の基幹システムを運用している企業にとっても、利用可能なサービスの選択肢が少なくなるという意味で影響は少なくありません。 国内企業のニーズに寄り添う人気の IaaS「Cloud Power」 今後データセンター事業者の統合やサービスの集約がさらに加速すると予測されるなか、IBM Power の基幹システムを運用している国内企業が安心して利用し続けられるクラウド移行先として、「IBM Cloud」を思い浮かべる方もいるかと思います。 2019年の RedHat 買収にともない、Linux や Kubernetes などのオープンソース・テクノロジーで構築されたハイブリッド・クラウド・プラットフォームを提供する IBM Cloud では、IBM i や AIX のプライベート IaaS「IBM Power Virtual Server」を2020年11月より国内で提供開始しています。 北米・ヨーロッパ・オーストラリアにリージョン展開しており、グローバルでビジネスを展開する国内のエンタープライズ企業などにとって有力な選択肢となるでしょう。 そんな中、情報システム部門のリソースが限定されていて導入（環境構築）から運用に至るまできめ細かなサポートを期待する企業には、IBM製品の国内ディストリビューターとして製品に関する豊富なノウハウを有する NI＋C P の「Cloud Power」をお勧めします。 同サービスは、グループ親会社である NI＋C のデータセンターにて IBM Power を基盤に、IBM i および AIX環境を提供するクラウドサービス（IaaS）で、2009年にサービスを開始。2020年6月現在、75社200区画にてサービス提供しており、ここ1年で70区画が新規導入。 クラウドサービスとして、ハードウェアの保守切れなどを気にすることなく常に最新のハードウェア環境を利用できるほか、以下のようなメリットを導入企業に提供します。 OSアップデートなど、システム基盤の維持・運用はおまかせ オンプレミスで IBM Power を運用する企業にとって、セキュリティ対策や OS/ファームウェアのアップデートなど定期的なメンテナンスは重荷ですが、Cloud Power では Q＆A 対応サービスを含め豊富な運用サービスのオプションメニューを用意。 リソースを投入し時間をかけて社内でスキルを習得することなく、OS のバージョンアップ、リソース監視、ライセンス管理など、ほとんどの作業をアウトソースでき、業務の自動化や効率化など戦略的な取り組みに注力できるようになります。 なお、メンテナンスは LPM※を利用することで OS を停止させることなく行われ、業務への影響を心配しなくて済みます。 ※Live Partition Mobility：稼働中の LPAR を別の筐体に移動する機能 ネットワークもワンストップ提供。設定や保守もおまかせ IaaS 利用では、クラウド環境に接続するネットワーク回線をどうするか?も問題となります。 特に、機密情報や個人情報などを扱うケースでは盗聴などのリスクを排除するため、専用線や閉域網などセキュアなネットワーク回線が必須となりますが、Cloud Power では「NMS Plus セキュアドネット」という独自の回線を提供。ワンストップで導入することが可能です。 ブロードバンド接続のベストエフォート型は5.5万円で、そのほか、リーズナブルなインターネットVPN型や、速度保証のある専用線型も用意され、ニーズや用途にあわせて選べます。 東西に堅牢なデータセンターを保有。DR/BCP 対策も可能 Cloud Power のデータセンターは関東と関西の2か所にあり、ミッションクリティカルなシステムを両データセンター間でレプリケーションすることで、万が一の際にもビジネス継続性を確保できます。 なお、Cloud Power は24時間365日体制の保守・運用により、被災以外の障害発生にも迅速対応が可能です。 実際の導入事例に見る「Cloud Power」活用シナリオ 以下、実際に Cloud Power を導入した3社の事例でその活用メリットを紹介します。 【事例 1】 Oracle SE2ライセンスの流用をハイブリッドクラウドで実現 アプリの検証環境を自社ビル内で運用する大手 SIer A社は、毎年の法定点検にともなう停電でシステム停止を余儀なくされ、そのたびに調整や事後の対応に追われていました。 こうした事態から脱却しより柔軟なリソース増減を実現するためクラウドへの移行を検討するも、Oracle SE2 はソケット数制限で利用できず、Oracle EE のコスト過大が判明。 そこで、NI＋C のデータセンター内に Oracle SE2 のサーバーをコロケーション設置。併せて Oracle SE2 以外のシステム（AIX）を Cloud Power に移行するハイブリッドクラウド構成により、既存の Oracle SE2 ライセンスを活かして、オンプレミス環境と同等のコストでクラウド移行すると同時に運用管理の工数削減を実現しました。 【事例 2】 新旧災対環境間の切り替えにより、システム停止を最小化してクラウド移行 利用していたデータセンター閉鎖が決まり、基幹システム（IBM i）の移行先を探すことになった大手運送業B社。 同社のビジネスを支えるクリティカルなシステムのため、いかにビジネスへの影響を最小化して移行できるかが重要なポイントに。 既存の DR環境を維持しつつ、Cloud Power を導入し東西データセンターの HA構成を採用することで、システム停止を最小限にとどめて切り替えを実施。本来数日を見越していたシステム停止が約1日で済み、データ移行についても、HAソフトウェアを採用することで物理テープを利用した場合の半分以下の期間で完了しました。 また、既存データセンターに設置していた多数の NW機器においてもホスティングサービスを新たに契約し、NI＋C のデータセンターに収容することで、基幹システム以外についてもクラウド移行を果たしました。 【事例 3】 IAサーバーや EDI通信を含むネットワーク基盤の移行も、ワンストップ化 ハードウェアの老朽化を理由に利用していたデータセンターを退去することになった商社C社。 IBM i のほか、AIXサーバーや IAサーバー、サービス終了が迫るベーシック手順の通信を利用する EDI やネットワーク基盤などを、必要に応じアップデートしつつ、移行するための工数が大きな負担に。 Cloud Power のオプションメニューや構築支援サービスを利用することで、自社の工数負担を最小化して、ネットワークを含むすべてのシステム基盤の移行をスムーズに進行中です。 再販パートナーと一体になって充実サポートを提供 Cloud Power は、再販パートナーを通じてエンドユーザーに提供されます。 長年にわたり顧客企業と良好な関係を築いてきた SIer などにとっては、お客様の IBM Power 環境の構築・運用で蓄積したノウハウを最大限活かすことができます。 これまでオンプレミス中心で、クラウドならではの扱いに少し不安を感じるというケースでは、NI＋C P が一体となり課題に対して1つひとつ対応するので安心して導入いただけます。 Cloud Power の導入検討についてはもちろん、IBM Power基盤をご利用のお客様は、ぜひ、NI+C P にご相談ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 Cloud Power (製品情報) - IBM i (AS400)、AIX を国内シェアNo.1 のクラウド環境でご提供します！ コロナ禍で基幹システムでもクラウド移行が急拡大！の背景を探る (コラム) - クラウド移行を検討する企業に向けて、お勧めのマネージド型クラウドサービスについて紹介します。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 現在、日本の多くの企業にとって「2025年の崖」をいかに克服するかが大きな課題となっている中で、レガシーシステムの抱える数々の問題が足かせになっています。 本コラムでは、"企業が抱えるレガシーシステム特有の課題を解決してデジタルトランスフォーメーション（以下：DX）を実現するためには、なぜ新しいアプリケーション開発や既存アプリケーションのモダナイゼーションが必要なのか？" について考察します。 Index DX実現にアプリケーションのモダナイゼーションが必要な理由 モダナイゼーションの事例 アプリケーションのモダナイゼーションを推進する「IBM Cloud Pak for Applications 」 この記事に関するお問い合わせ 関連情報 DX実現にアプリケーションのモダナイゼーションが必要な理由 レガシーシステムが抱える問題 2000年代に構築した基幹システムを現在に至るまで改修を繰り返しながら利用しているケースは珍しくありません。これらのシステムは今や15年〜20年が経過しており、レガシーシステムと呼ばれています。 既存のレガシーシステムは属人性が高く、さらに、レガシーシステムを運用・保守できるスキルを持った人員は不足しているので、それにともなう運用・保守コストの増大は大きな課題です。また、アプリケーションの改修に数ヵ月単位の工数がかかってしまうため、柔軟性や迅速性の低下も課題となっています。 レガシーシステムを抱える企業の問題 システム開発・管理の「属人化」による、弊害 運用・保守のコスト増大による、新規開発への投資不足 スキル要員の不足による、新規案件への対応の遅れ 「外部連携ができない」システムによる、デジタル・ビジネス創出の損失 アプリケーション構造による、業務の拡大や変化に対する制約 データへのアクセスの難しさによる、データ資産の利活用不足 ビジネススピードを左右する、「アプリケーションの開発サイクル」の遅れ 迅速性・柔軟性の低下による、新業務・新商品の投入の遅れ 複雑化した構造による、開発・保守の生産性・品質の低下 これらレガシーシステムを抱える企業の問題は、DX がめざすビジネス変革に対する制約となっており、差し迫った足元の課題としてこれを解決することが必要不可欠です。 「マイグレーション」と「モダナイゼーション」の違い レガシーシステム特有の課題を解決し DX を実現するために不可欠な手法として、「モダナイゼーション」があります。 モダナイゼーションを検討するにあたっては、まず「マイグレーション」と「モダナイゼーション」の違いを知っておくことが大切です。 マイグレーションとは、「TCO削減」を目的としたクラウド環境への移行 マイグレーションは、TCO（総所有コスト）の削減を主要な目的としたクラウド化のことをいいます。具体的には、既存のアプリケーションの構造を変えることなくクラウド環境に移行することです。 マイグレーションによる成果としては主に以下が挙げられます。 迅速にアプリケーションのクラウド化が可能 クラウド化による IT資源の効率的利用 運用効率化・自動化を取り入れた設計指向 モダナイゼーションとは、「ビジネス拡大」を目指すクラウド・ネイティブ化 モダナイゼーションは、マイグレーションによりコスト削減を狙う領域を見定めつつ、戦略領域についてはモダナイゼーションによりビジネス拡大を目指すクラウド・ネイティブ化のことをいいます。具体的には、クラウド・ネイティブ化することで既存アプリケーションのアプリケーション構造を変革し、最新技術を取り入れ最適化することです。 モダナイゼーションによる成果としては主に以下が挙げられます。 将来にわたってアプリケーションの保守・管理が継続できる環境を整備 API化によるビジネス機会の拡大 Agile/DevOps (アジャイル/デプオプス) によるビジネス要求への迅速な対応 クラウド・ネイティブ化のメリット このように、アプリケーション・モダナイゼーションは現行のアプリケーションを最新技術で更改し、「ビジネスの成長と拡大」を目的として「クラウド・ネイティブ化」することで新たな価値を生み出すよう変革することを意味します。 クラウド・ネイティブとは「クラウドの利点を徹底的に活用するシステム」を意味しており、様々なクラウドサービスを利用して開発・構築された、クラウドでの運用を前提としたシステムやサービスです。 そのメリットは、既に提供されているサービスを使うことによる開発期間の短縮や、アプリケーションを細分化することにより改修時の影響範囲が小さくなることによって修正期間・工数の削減ができる、などが挙げられます。昨今では、IaaS を用いて既存のシステムを最小限の改修でクラウドに移行し、その上で、PaaS や SaaS を活用してクラウド・ネイティブに作り替える「リフト＆シフト」と呼ばれる手法も広まっています。 つまり、アプリケーション・モダナイゼーションによってレガシーシステムを「クラウド・ネイティブ化（Shift）」することでアプリケーション開発および管理の場を最適化し、レガシーシステムの課題であった「可用性」「スケーラビリティ」「リリースまでの期間短縮」などの問題を解決することができるのです。 参考）「CNCF Cloud Native Definition v1.0」 モダナイゼーションの事例 2018年に経済産業省の DXレポートが公開されて以降、多くの企業がブラックボックス化したレガシーシステムを様々なレベルで刷新し、「2025年の崖」を克服するべく DX 実現のための IT基盤整備に取り組んでいます。 ここで、モダナイゼーションの事例を幾つか紹介しましょう。 サイロ化されたインターネットサービスを改善 この企業では、部分最適によってサイロ化され、利便性が低くなったインターネットサービスを改善する必要に迫られていました。 アプリケーションフレームワークに Struts* を採用していたためにセキュリティ上の問題も抱えており、そのほかにも、各種キャッシュレス決済の技術を採用することや、ソーシャルメディア連携を強化して新しいビジネス領域を開拓する必要もありました。 これに対して同社は、ToBe アーキテクチャとして、フレームワーク更改や PaaS化、コンテナ化/マイクロサービス化、DevOps 適用を採用。 最新のアプリケーションフレームワークを導入し、コンテナ化による保守性と拡張性の高いアプリケーション構造を実現しました。さらに、DevOps によって新しいサービスをタイムリーに実装・展開できるようになりました。 *Struts : Java Servlet API を拡張してMVC (Model, View, Controller) アーキテクチャを採用した、オープンソースのフレームワーク レガシーシステムに散在していた顧客データを収集・集約 またある企業では、顧客データが事業ごとに散在して再利用が困難になっており、ガバナンスにも課題がありました。また、システム構造がサイロ化していたため、アプリケーションのリリースサイクルが長期化していることも問題となっていました。 これに対して同社は、ToBe アーキテクチャとして UXモダナイゼーション、SoE/SoR分離、コンテナ化/マイクロサービス化、DevOps 適用を採用。 レガシーシステムに散在していた顧客データを収集し、IBM が提唱する、次世代アーキテクチャに従った変化に強いデジタルサービス層に集約しました。さらに、マイクロサービスのアプリケーションをコンテナで実装することで柔軟性の高いシステム構造を実現しています。 レガシーシステムのデータはそのままに、メインフレーム資産を API連携 メインフレームを利用していたある企業は、レガシーシステムのデータはそのままに、フロント側の各チャネルにデータを提供したいと考えていました。 これに対して同社は、ToBeアーキテクチャとして API化、SoE／SoR分離、コンテナ化／マイクロサービス化を採用。次世代アーキテクチャのデジタルサービス層にアプリケーション基盤、API管理基盤を設けることで、メインフレーム資産をシンプルに API連携させています。 アプリケーションのモダナイゼーションを推進する 「IBM Cloud Pak for Applications 」 モダナイゼーションとクラウド・ネイティブ・アプリケーション開発・実行を サポートする「IBM Cloud Pak for Applications 」 レガシーシステムの問題点を解決し、オープンなコンテナ技術によるアプリの可搬性向上と、オープンなオーケストレーションによる管理・運用の効率化を実現するのが IBM Cloud Paks シリーズです。 IBM Cloud Paks とは、Red Hat OpenShift 上で稼働するミドルソフトウェア群で、オープンなコンテナ技術によるアプリの可搬性向上と、オープンなオーケストレーションによる管理・運用の効率化を実現します。 Red Hat OpenShift とコンテナ化された IBMソフトウェアを含み、オンプレミス、プライベートクラウド、パブリッククラウド、エッジ・コンピューティングを同じアーキテクチャで提供。エンタープライズでは、オープンソースそのものだけでは難しく、運用の負荷も増大します。 IBM Cloud Paks は、他社の Kubernetesサービスと比べて、運用サービスがエンタープライズ用に共通化されており、ソフトウェアが最適化された形で提供されます。ユースケース別に６製品があり、そのなかで、アプリケーションのビルド、拡張、デプロイ・実行を支援する製品が、「IBM Cloud Pak for Applications」です。 IBM Cloud Pak for Applications の2つの優位性 IBM Cloud Pak for Applications は、既存のアプリケーションを最新化し、Red Hat OpenShift で実行するクラウド・ネイティブのアプリケーションを新規開発するための、エンタープライズ対応のコンテナ化されたソフトウェア・ソリューションとして提供されています。 CI/CD開発・実行環境である「Accelerators for Teams」とコードのモダナイゼーションをアドバイスする「Transformation Advisor」の2つの優位点があり、開発者、IT運⽤者、LOB (Line of Business) それぞれに、大きなメリットを与えます。 「IBM Accelerators for Teams 」は、従来型のアプリケーションのハイブリッドクラウド／マルチクラウドへの移行を支援するとともに、必要なツールとランタイムを使用して革新的なクラウド・ネイティブ・アプリケーションを開発できる基盤を提供します。 また「Transformation Advisor」は、既存のレガシーシステムのアプリケーションをコンテナ上で実行できるかを分析、必要な手順を教示しコンテナ環境への移行をサポートします。 IBM Cloud Pak for Applications の3つの価値 先程ご説明した2つの優位点は、いま必要なものから将来必要となるものまで、お客様にとって3つの価値を提供します。 既存アプリの実行 : 現在の環境で、従来どおりアプリケーションを実行 - パブリッククラウド、オンプレミス、プライベートクラウドのどこでもアプリケーションが 実行可能 - IBM Cloud Pak for Applications は、既存のアプリケーションが存在する場所で実行し、最新化されたアプリケーションと新しいクラウド・ネイティブのアプリケーションをコンテナ内のクラウドにデプロイします。そのため、パブリッククラウド、オンプレミス、プライベートクラウドのどこでも、ビジネスに最適な場所と方法でアプリケーションを実行できます。 また、既存のアプリケーションに対して、オープンソース標準に基づいて構築された統合 Kubernetesプラットフォームである Red Hat OpenShift に合わせたツールを提供するとともに、アプリケーションの実行場所にかかわらずそれらをサポートします。 既存アプリのモダナイズ : コンテナ環境へ移行が必要となったときに、それをサポートする ツール・知見を提供 - 既存システムのリフト&シフトを支援ツール「Transformation Advisor」を活用可能 - IBM Cloud Pak for Applications には、既存アプリケーションのモダナイゼーションを支援するツールとして、「Transformation Advisor」が用意されています。これは、オンプレミス環境で実行されていた Java EE のアプリケーションをコンテナ上で実行できるかを分析し、どういう手順が必要かをレポートするなど、既存システムのリフト & シフトを支援します。 また、「WebSphere Migration Toolkit」やローカル開発と連携する IDE 拡張機能などにより、コンテナ環境への移行をサポートします。 新規アプリの開発 : 新規アプリケーションをクラウド・ネイティブで作成するための 開発ツールや環境、各種オープンソースを統合して提供 -「Accelerators for Teams」フレームワークに含まれている各種オープンソースを サポート付きで開発可能 - IBM Cloud Pak for Applications には、複数のオープンソースを組み合わせてコンテナ上のアプリケーションを開発・テスト・管理できるようにした「Accelerators for Teams (旧 Kabanero) 」が含まれます。 ツールをひとつひとつ組み合わせて開発環境を構築するのは容易ではありませんが、「Accelerators for Teams」は開発者がすぐに使えるかたちで提供されており、しかも IBM のサポートが付いているので安心して利用することができます。 また、テンプレートや管理のためのアーキテクト・ツール、開発者向けツールなども充実。Accelerators for Teams で作成したアプリケーションをテスト・本番で実行するランタイムも各種用意されており、なかでも「Libertyランタイム」はスピーディーな開発に対応する軽量の次世代ランタイムです。これにより、自動化された環境で最小人数のエンジニアでの開発が可能となります。 このように、OpenShift ベースの基盤でコンテナ化することでハイブリッド・クラウド/マルチ・クラウド双方に対応し DX を加速させる IBM Cloud Pak for Applications は、これを利用することで既存アプリケーションの利用、モダナイゼーション、新たなネイティブ・アプリケーションの開発がスムーズに行えるようになります。 アプリケーション・モダナイゼーションを検討する上で、IBM Cloud Pak for Applications はエヌアイシー・パートナーズが自信をもってお勧めするソリューションです。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ 【やってみた】Cloud Pak for Applications 導入してみた：Cloud Pak for Applications 導入編 (ブログ) - 今回は、AWS 上に構築した Openshift 環境に Cloud Pak for Applications をインストールします！ IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
ERP、SFAツール、顧客管理システム、POSシステム・・・ 現在では、様々なシステムを活用してビジネスを展開することが当たり前となりました。それぞれのシステムを必要に応じて連携し利用することによって、組織全体としてシステムやデータをより有効に活用できます。 本コラムでは、システム連携の代表的な手法や課題などを解説します。 ▲ 欲しい製品・ソリューションが見つけやすくなりました！ 目次 システム連携とは？ システム連携の代表的な方法 幅広いシステム連携方法に対応するのはコストがかさみ、手間も増える・・・ 用途・目的に合ったシステム連携の方法を選べる統合プラットフォーム「IBM Cloud Pak for Integration」 お問い合わせ 関連情報 システム連携とは？ かつて、システムは一部の大企業だけのものであり、大型メインフレームの導入が主流でした。しかし、1990年代以降にダウンサイジングの波が押し寄せ、現在は大企業だけではなく幅広い規模・業種の企業が業務別・目的別に最適化された多種多様なシステムを導入しています。 こうした中で、すでに多くの企業が取り組み始めているのがシステム連携です。システム連携とは、異なるシステム間でデータを相互に共有・処理できるようにすることです。システム間で分断されていたデータの活用によって、より深い洞察を得たり、オペレーションエラーを減らしたりといった効果を得られます。 「データ活用に役立つ」ソリューション は こちら 例えば、SFA（Sales Force Automation／営業支援）ツールと MA（Marketing Automation）ツールを連携することで、営業担当者やマーケティング担当者は、見込み客の獲得から最終的な受注に至るプロセスを俯瞰的に把握できるようになります。その結果、マーケティング担当者はウェブサイトの流入数や見込み客の獲得数だけではなく、アポイントメント獲得数や最終的な受注数といった営業側の指標も見ながら、マーケティング施策の検証や効果改善に向けて精度の高い施策検討を行なえます。 また、勤怠管理システムと給与計算システムを連携すれば、勤務時間に応じた毎月の給与計算を自動化できます。Excel などの表計算アプリでの集計など、人による作業工数の削減に繋がり、勤務時間管理や給与計算でありがちな計算ミスや誤入力といったオペレーションミスの防止に役立ちます。 「自動化による効率化に役立つ」ソリューション は こちら 次項でシステム連携を実現するための具体的な方法を解説します。 システム連携の代表的な方法 現在よく使われている代表的なシステム連携の方法は、以下の3つです。 ファイル転送 メッセージキュー API １.ファイル転送 ファイル転送はファイル単位で1対1でのシステム連携を実現する方法です。長年にわたってシステム連携の代表的な手段として利用されてきました。 ファイル転送は FTP（File Transfer Protocol）、SMB（Server Message Block）、CIFS（Common Internet File System）といったプロトコルを用いて実現します。FTP はファイル転送で利用される代表的なプロトコルの1つです。後述する方法に比べ、FTPの利点は大容量データを高速でやり取りすることです。 データ連携は通信プロトコルである FTP を通じて行うので、連携するシステムそのもののプログラムに手を加える必要がありません。そのため、一方のシステムで障害が起きてももう一方のシステムへの影響範囲を限定できます。 一方、ファイル転送でシステム連携を実現する際にはファイルの静止点（※1）が必要です。 ファイル転送はデータを一括して転送するバッチ処理によって行われるので、全データの処理が完了しなければ結果がわからず、途中経過を把握できません。そのため、リアルタイム処理のようにすぐ結果を知りたい場合は、1回のデータ量を減らして転送時間を短くするなどの工夫が必要です。 ※1：ファイル内のデータが更新されていない状態のこと ２.メッセージキュー メッセージキュー（Message Queue）はメッセージ単位で N対1、または N対N でのシステム連携を実現する方法です。 送信側が送信したメッセージは受信側が取り出すまでデータ領域（キュー）に保管されます。キューはメッセージ指向ミドルウェア（MOM：Message Oriented Middleware）やメッセージブローカー（Message Broker）で管理するのが一般的です。 送信側の処理はキューにメッセージを送信することで完了します。直接受信側にデータが送信されるわけではないので、受信側のシステムの負荷やリソースなどを意識する必要はありません。受信側でシステムダウンやリソースの逼迫があったとしても、送信側は処理の完了を待つ必要がないのです。 メッセージキューにおける送信側のメリットは「送信側が意図したメッセージの順序を維持することができる」ことです。このような特性から、メッセージキューは非同期処理が必要なシステム連携に向いています。 ３.API API（Application Programming Interface）は、HTTP や HTTPS形式で実装されることが多い、N対1 でのシステム連携を実現する方法です。 API はシステムの外部仕様を定義して各機能を利用するためのインターフェースを提供します。そのため、多くの場合 API はシステムを構築する言語と同じ言語のライブラリと通信プロトコルで提供されます。 API を使用すると、そのシステムの実装方法を知らなくても他のシステムと連携可能です。Webアプリケーションの特定の機能のみ API として実装して公開することで「社外の一般ユーザーが利用できるようにする」といったことができます。 例えば、下図のように社外の一般ユーザー向けに自社の Webサーバー上にある Webアプリケーションを提供した上で、ゲートウェイ上でアクセス制御を行うことで、セキュリティを担保できます。 「データ連携で活躍する」ソリューション は こちら 幅広いシステム連携方法に対応するのはコストがかさみ、手間も増える・・・ 前項で紹介したように、システム連携といっても様々な方法があります。採用するべきシステム連携の方法は連携するシステムの仕様、やり取りするデータ量、データ形式などによって異なります。 例えば、CADデータをやり取りするといったようにシステム間で大容量データを送受信する場合には、FTP によるファイル転送が適しています。一方、SaaS型ソリューションの多くが API を公開しているように、「顧客や取引先といった外部のユーザーが任意に特定のシステムと連携するための方法を提供したい」という場合には API が適しています。従来のように個別にシステム連携のプログラムを開発することなく、ユーザー側で連携作業を完了できるからです。 しかし、用途に合わせて複数のシステム連携の方法に対応するとなると複数のソリューションを導入しなければならず、製品ごとのライセンス・導入コストがかさんでしまいます。また、利用するソリューションが多くなると運用管理の手間も煩雑化してしまいがちです。実情として、用途に応じてシステム連携の方法を使い分けるのはハードルが高いといえます。 一方、最近では様々なシステム連携の方法を統合的に運用管理できるプラットフォームが登場しています。 「コストを抑え、手間を省く」ソリューション は こちら 用途・目的に合ったシステム連携の方法を選べる統合プラットフォーム「IBM Cloud Pak for Integration」 IBM Cloud Pak for Integration は、IBM が提供している MQ（メッセージキュー）、App Connect（アプリケーション連携）、API Connect/DataPower（API連携）、Aspera（ファイル転送）といったシステム連携を実現する様々なソリューションを統合したプラットフォームで、システム連携をワンストップで実現できます。 また、IBM Cloud Pak for Integration は実績のある Red Hat OpenShift Container Platform で稼働し、コンテナ技術に最適化しているので、オンプレ、IBM Cloud、他社クラウドなど様々な環境にデプロイできます。 システム連携に課題を感じている方は、ぜひ、IBM Cloud Pak for Integration の検討をおすすめします。 詳細は［IBM Cloud Pak for Integration］でも紹介しています。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いします。お問い合わせ 関連情報 IBM Cloud Pak for Integration（製品情報）- アプリケーション、データ、クラウド・サービス、APIの統合を支援するハイブリッド統合プラットフォームです。 今、デジタルサービスに求められる必須要件とは！？アプリケーションのコンテナ化で得られる5つのメリット（コラム）- 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編（ブログ）- シリーズ第1回目の本記事では、概要編として検証の目的・背景や環境周りを紹介します。 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した（ブログ）- 全世界から9万人以上の参加者が！ ul#list li{ margin-top:10px; margin-bottom:10px; } ul#list a{ font-weight:bold; } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .btn_CTA{ height:30px; margin-bottom:40px; width:450px; } .btn_CTA a{ display:block; width:100%; height:100%; text-decoration: none; background:#6200f5; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #6200f5; transition: all 0.5s ease; } .btn_CTA a:hover{ background:#bf94ff; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #bf94ff; } .bigger { font-size: larger; }
近年、大規模な自然災害が増加していることから DR の重要性が高まっています。 DR は「Disaster Recovery」の略であり、文字どおり「災害時にどう復旧するか」という対策を指します。 ひと言で「災害からの復旧」と言っても対策は多岐にわたり、求める対策のレベルによって運用にかかるコストにも違いがあります。 どこまで対策をすればいいのか、悩む企業も多いのではないでしょうか。 今、改めて押さえておきたい DR の基本・指標と、実現するための方法について解説します。 Index DRの基本と、BCPとの違い DRで最初に検討すべき3つの指標 DRを実現する3つの方法 バックアップ製品などをうまく活用し、効率的なDR対策を この記事に関するお問い合わせ 関連情報 DRの基本と、BCPとの違い DR は、地震や台風などの自然災害などが発生した際にシステムをスムーズに復旧させるための対策のことです。 似たものとして「BCP（事業継続計画）」があり、どちらも緊急事態への対策を検討するものですが、BCP が事業全般を継続するための計画を策定するのに対し、DR は「システムを災害発生から復旧させること」に重点を置いています。 特に、自社オフィスやデータセンターなどが台風や地震といった災害により物理的に利用できなくなってしまった際に、どう復旧するかがポイントとなります。 DRで最初に検討すべき3つの指標 DR 対策を検討する場合は、システムを「いつまでに」「どの状態に」復旧すればよいのかをしっかり定めましょう。その際に、指標となるのが以下の3つです。 RTO（Recovery Time Objective/目標復旧時間）： 「いつまでに、システムを復旧すればよいか」の目標を定めた指標 RPO（Recovery Point Objective/目標復旧時点）： 「いつのデータに、復旧できればよいか」の目標を定めた指標 RLO（Recovery Level Objective/目標復旧レベル）： 「処理能力や品質などをどのレベルまで、復旧できればよいか」の目標を定めた指標 これらの指標は、例えば「災害発生から3日以内に（RTO）」「前日のデータで（RPO）」「通常の半数程度の処理に対応できる（RLO）」ように復旧する、といった形で目標を定めることを指します。 これらの指標を組み合わせて対策を検討することになりますが、その方法は「バックアップの頻度」「復旧方法（手動/自動など）」により大きく5つのレベルに分けられます。 レベル1：スタンバイなし/バックアップリストア（手動） レベル2：コールドスタンバイ/バックアップリストア（手動） レベル3：コールドスタンバイ/プログラムによるバッチコピー レベル4：ホットスタンバイ/ツールによる非同期コピー レベル5：ホットスタンバイ/ツールによるリアルタイムコピー レベルが上がるにつれ RPO・RTO を短くでき、システムダウンの時間を最小限に抑えられますが、コストも高くなります。すべてのシステムを高いレベルで運用すればよいわけではなく、システムごとに指標を定めどのレベルで運用するかを検討することが重要です。 例えば「更新頻度の低い、社内の人事データ」であれば、リアルタイムに同期をとる必要はなく、月1回のバックアップデータを別拠点に保存する形で十分対応できるかもしれません。一方「ECサイトの受注データ」は前日のデータが残っていても不十分で、極力 RPO・RTO を短くする対策が必要になります。 どのシステムをどこまで対策するのか、コストとのバランスを見ながら検討すべきでしょう。 DRを実現する3つの方法 次に、こういった DR 対策を具体的に実現する方法を解説します。DR では、大きく3つの方法が挙げられます。 バックアップメディアを遠隔地に保管 バックアップデータを保存したメディアを遠隔拠点に運搬することで、データを守ります。メディアの種類も様々ですが、大容量データを長期保管する場合などは、比較的コストを抑えられるテープメディアが有効です。 ネットワークを介した遠隔バックアップ、リストア ネットワークを経由し、クラウド（IaaS）や別拠点にバックアップデータを保存します。災害時には、バックアップ環境側で新たに環境を構築・リストアすることで、早期復旧が可能になります。 データレプリケーション データを2拠点間でリアルタイムに同期し、障害発生時には、フェイルオーバーすることでダウンタイムを最小限に留めることができます。レプリケーション先でも本番環境と同等の環境が必要になるため、コストが割高になる傾向があります。 上記のうちどの方法が適しているのか、バックアップ先はクラウド・オンプレミスのどちらがいいのか、などは企業によって異なります。 また、つい「データをどこにバックアップするか」ばかり考えがちですが、データだけバックアップしてもアプリケーションなど含めたシステム環境が揃わなければ、業務で利用できるようにはなりません。 復旧時の手順や環境まで含めて、あらかじめ確認しておきましょう。 バックアップ製品などをうまく活用し、効率的なDR対策を DR は運用コストなどを理由に二の足を踏む企業も少なくありませんが、ビジネスにおいてシステムやデータの重要度が高まり続けるなか、データを失うリスクを考えれば、コストをかける価値は大きいはずです。 DR 対策で活用するバックアップなどの製品は数多く登場していますが、特にネットワークを介したバックアップを行う場合は、データの転送効率も要チェック。 例えば、IBM Spectrum Protect は、「永久増分」という方法を採用し、転送するデータを最小限に留めます。さらに高速転送機能により、WAN 環境でも高品質回線並みの転送速度を実現します。 いざという時に、想定よりもバックアップ環境でリストアして利用できるまでに時間がかかり、大きな機会損失になった、なんていう事態を防ぐには最適なツールです。 DR 対策で大切なことは、保有するデータごとに自社の事業内容と優先度に合った環境を用意しておくことです。前述のとおり、3つの指標＜RTO・RPO・RLO＞を策定した上で、効率的な DR 対策を目指しましょう。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 今、BCPで求められるITシステム対策について解説。考えるべき基本は？最優先すべきポイントは？ (コラム) - 災害など緊急事態における対策を定める「BCP」。では、具体的にどうすればよいのか？ .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
災害など緊急事態における対策を定める「BCP」。新型コロナウイルスの感染拡大もあり、今、改めて注目を集めています。 ですが、「なんとなくわかっているけれど、システムごとに最適な対策をできているかは自信がない」「きちんと対策できているか不安」という企業も多いのではないでしょうか？ また、従来の自然災害やパンデミックは比較的短期間で収束することを想定していましたが、予想を超える大雨の頻発、さらに新型コロナウイルス感染も収束の兆しが見えず問題が長期化するなか、BCP 対策に求められるものも大きく変化しています。 では具体的にどうすればよいのか、BCP の基本から、今、企業がすべきことを解説します。 Index BCPの基本とは？策定までに検討すべきポイント BCP対策におけるシステムの役割 BCP観点で有効な「データ保全」の方法 この記事に関するお問い合わせ 関連情報 BCPの基本とは？策定までに検討すべきポイント BCP とは、Business Continuity Plan（事業継続計画）の略であり、自然災害やテロなどの緊急事態において、事業を継続するための方法などを取り決めた計画を指します。つまり、通常のオフィスやシステムが利用できない事態に陥っても、素早く体制を復旧し事業を続けるためにあらかじめ具体的な計画を定めておく、ということです。 事業継続と言っても、緊急事態ですからすべて通常と同じように復旧できるとは限りません。どの業務を優先して継続すべきかを判断し、体制を整えるのが基本。まずは以下の流れで検討し、BCP 策定を目指しましょう。 優先すべき中核事業や、ビジネスに影響が大きい業務を特定する 上記、事業・業務の目標復旧時間を決める 事業を継続するための代替案を用意する BCP を発動する基準や、体制を明確にする 具体的な対策が社会情勢や事業の変化によって変わっても、この基本は変わりません。自社が守るべき事業や業務をきちんと見極めることが大切です。 BCP対策におけるシステムの役割 BCP で検討すべきことは、オフィスや工場・店舗など “場所” の確保、取引先との連携、顧客へのフォローなど多岐に渡りますが、システムが担う役割も大きくなります。「業務システムをどう継続するか」「オフィスに出社できないなかで従業員と、どう連絡をとるのか」といった観点のほか、緊急時に在宅勤務できる体制の整備も必要になるでしょう。 特に、コロナ禍により緊急事態が長期化するなか、対策すべき範囲が拡大しています。 在宅勤務では、オフィスのファイルサーバなどにアクセスできないといった課題が浮き彫りになり、クラウド化を進める企業も増加。緊急避難的な対策に留まらず、業務プロセス自体の効率化やモバイル端末活用推進、さらにはオンライン研修など、根本的な見直しを行うケースも今後増えると予想されます。 しかし、これだけのことを一気に進めるのは難しいでしょう。こちらも優先度をつけ、順次進めることをお勧めします。 なかでも最初にやっておきたいのが、「データ保全」です。災害であれパンデミックであれ、データがなくなってしまっては事業の復旧・継続は困難になります。 データを異なる拠点やクラウドなどに保管し、万が一の事態にも損なわれないよう備えることが、BCP において基本中の基本と言えるでしょう。 BCP観点で有効な「データ保全」の方法 データ保全の方法は様々ですが、「事業を継続する」という観点からはデータやシステムの情報を異なる場所で同期する「レプリケーション」が有効です。 レプリケーションでは、決まった時刻のバックアップデータを取得・保管するのではなく最新の情報をリアルタイムに同期するため、本番環境が利用できなくなった際にはフェイルオーバーすることで即座にレプリケーション先の環境に切り替えることが可能。 これにより、データを複数個所で保存しながら、ダウンタイムを最小限にしてシステムを利用し続けることができます。 レプリケーション先はクラウド（IaaS）も有力候補にはなりますが、セキュリティなどの観点からオンプレミスの拠点同士で構成するケースも。例えば、東京と大阪の拠点間でレプリケーションすれば、災害時の対策としても十分有効です。 どこにレプリケーションするのがベストなのか、自社の状況やシステムの規模などを踏まえて検討しましょう。 もう1つ、レプリケーションを実現する製品を選ぶ際には、データ圧縮や転送速度などの基本スペックとあわせて緊急時における対応のしやすさも確認することをお勧めします。 ストレージ自体にレプリケーション機能を搭載するものもありますが、この場合、製品ごとにツールを使い分ける必要があります。「IBM Spectrum Virtualize」は、外部ストレージ仮想化機能を提供します。 「IBM FlashSystem」や「IBM SAN Volume Controller」に搭載することで、異なるベンダのストレージを一括管理することが可能です。 IBM Spectrum Virtualize は、異なるベンダのストレージも一元的にレプリケーションでき、復旧時にもまとめて対処できるのでスムーズです。 BCP は、「一度考えたらOK」というものではありません。社会情勢の変化だけでなく、自社の中核事業や業務が変わることもあるでしょう。 ですが、そのなかでもデータを守る仕組みは不可欠。基盤となるデータ保全を確実に行いつつ、随時対策を見直し、適切な計画を検討する姿勢こそが重要です。 BCP 対策の第一歩として、IBM Spectrum Virtualize などを活用したデータ保全対策を整備しておくことをお勧めします。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは？効率的な対策は？ (コラム) - 近年、大規模な自然災害が増加していることから DR の重要性が高まっています。今、改めて押さえておきたい DR の基本・指標と、実現するための方法とは？ .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
コロナ禍で売上が落ち込んでいる企業を中心に、IT投資を再検討する動きが広まっています。 オンプレミスのシステムを運用するケースでは、膨大な更改コストを回避するため初期費用を抑えて利用開始できるクラウドに移行する企業が増えており、コロナ禍を機に企業のクラウドシフトが一気に進みそうな予感です。 本コラムでは、ミッションクリティカルな領域である基幹システムにおける新たな課題について触れつつ、クラウド移行を検討する企業に向けて、お勧めのマネージド型クラウドサービスについて紹介します。 Index コロナ禍を機に、基幹システムのクラウドシフトが加速 コストだけじゃない！基幹システムクラウド移行の様々なメリット 「Cloud Power」の活用シナリオ この記事に関するお問い合わせ 関連情報 コロナ禍を機に、基幹システムのクラウドシフトが加速 コロナ禍で産業全体の売り上げが減少する中、IT 業界において売り上げを伸ばしている領域が「テレワーク関連」や「クラウドサービス」などです。 クラウドに対するニーズが高まっている背景には、コロナ禍で経済の先行きに不透明感が漂い、大規模な投資を避けたい（もしくは、投資ができない）企業の考えがあります。こうした動きは、これまでクラウド移行をためらうケースが多かった基幹系システムにも拡がっています。 実際、IBM Power Systems などのハードウェアに加え、IBM Power Systems ベースのマネージド型クラウドサービス「Cloud Power※」を販売するエヌアイシー・パートナーズ株式会社（以下 NI+C P）によれば、コロナ禍に突入して以降、オンプレミス更改とクラウド移行を並行して検討していた企業がクラウド一本に絞って進めるケースが増えており、同サービスの成約率が倍増していると言います。（下グラフ参照） ※NI+C P のパートナー、日本情報通信株式会社（以下 NI＋C）が自社データセンター上で提供するクラウドサービス コストだけじゃない！ 基幹システムクラウド移行の様々なメリット コロナ禍で企業が基幹システムのクラウド移行へ踏み切ることになった背景としては、もうひとつ "ヒトを守る" という直接的な要因もあります。 それは、オンプレミスの機器入れ替えや設定などの作業過程における情シス部門やパートナー企業の人間が、入り乱れる "密" 状態の発生を回避したいという、ヒトの生命・安全を守る観点です。 もちろん、クラウド移行に踏み切る理由はこうしたコロナ禍によるものだけではありません。 そのメリットをしっかり評価・認識して近い将来クラウドに移行しようと考えていた企業において、コロナ禍で前倒しして、あるいは、コロナ禍で "ふんぎり" がついた、というケースが多いようです。 そこで、「Cloud Power」の場合、IBM i/AIX などのオンプレミスシステムを「Cloud Power」に移行することで、下記のような数々のメリットを享受することができます。 システム運用保守のアウトソースで人材不足に対応 情シス部門は、OSアップデートやセキュリティパッチ適用など、作業工数のかかる不定期メンテナンスをクラウド提供ベンダーに一任することで、人員リソースをデータ活用などの競争力強化に向けた異なる業務に配分・専任できるようになります。 また、IBM i/AIX という特殊なスキルを持った SE の不足や、熟練者退職にともなう業務運用継続の不安など、情シス部門の課題解決に貢献します。 EOS を心配することなく、常に最新の環境を利用できる ハードウェア・ファームウェアのアップデートや機器の更新は、提供事業者である NI＋C によって適宜おこなわれるため、導入企業はハードウェアの EOS を心配することなく利用し続けることができます。IBM Power Systems の Live Partition Mobility※ 機能によって、メンテナンスにともなうシステム停止の影響もありません。 ※稼働中の論理区画を別の物理的システムに移動する事を可能にする IBM Power Systems の有料フィーチャー 堅牢＆高セキュリティの横浜 DC で安心 「Cloud Power」が提供される横浜データセンターは、東日本大震災の時にも稼働し続けた実績があります。 一般的なオフィスビルとは比較にならない、ファシリティの圧倒的な堅牢性とネットワークを含めたハイレベルのセキュリティにより、重要なデータを守り、安心して利用いただけます。 BCP オプションで、投資を抑えて簡単に BCP 対策 「Cloud Power」のデータセンターは関西にもあり、両データセンター間でデータを同期し万一の時に切り替える「BCP オプション」メニュー（DC 間回線も含む）も提供しています。 オンプレミスでは、大規模な投資が避けられない災害対策サイト構築を、コストを抑えて手軽に実現します。 IAサーバーを含めた全面クラウド移行も可能 「Cloud Power」では、IBM i（AS400）や AIX のほか、Linux や Windowsなどの IAサーバーも同一セグメントで提供でき、オンプレミスで運用する各種システムの全面クラウドも可能です。 この他、エクイニクス社との契約により、AWS など他社クラウドとの接続・連携も容易です。 「Cloud Power」の活用シナリオ Linux や Windows のクラウド型マネージドサービスは数多く存在するなか、「Cloud Power」は、IBM i や AIX などミッションクリティカルな領域における数少ないマネージドサービスの1つです。 クラウドインフラからオフィスとデータセンター/データセンター間をつなぐセキュアな回線まで、必要なモノ・コトをオールインワンで提供しています。オンプレシステムの更改先やオンプレミス本番サイトの災害対策サイトのほか、下記のようなシナリオにもお勧めです。 ハードウェア EOS にともなうシステム延命 IBM i や AIX の古いシステム（オンプレミス）を SaaS に移行するプロジェクトを進めているが、その前にハードウェアが EOS を迎えてしまう…といったケースで、EOS のタイミングで旧システムを「Cloud Power」に移行し、SaaS 移行までの期間を延命することができます。 一定期間の開発・検証用途 当面オンプレミスを維持し続ける計画だが、開発・検証のためのリソースを用意するのが大変！といったケースでは、必要な期間だけ利用できるクラウドのメリットを活かし、「Cloud Power」を一定期間だけ契約して開発・検証をおこなうことでムダを排除できます。 社外プロフェッショナルへの BPO 推進 ベテラン社員の退職を機に、オンプレミスの IBM i や AIX システムを「Cloud Power」に移行。高度なスキルが要求される運用管理を全面的にアウトソーシングすることで、限られたリソースを AI によるデータ分析や RPA での業務自動化などに振り向けることができるようになります。 IBM i × 3種類 / AIX × 5種類の基本メニューに加え、多彩なオプションが用意される「Cloud Power」。 ニューノーマルに向け ITインフラ投資の最適化をお考えの企業は、ぜひ、お気軽にお問合せください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 Cloud Power (製品情報) - IBM i (AS400)、AIX を国内シェアNo.1 のクラウド環境でご提供します！ IBM Power Systemsユーザーのクラウド移行ニーズに寄り添う「Cloud Power」の魅力に迫る (コラム) - IBM Power Systemsのメリット（特長）にフォーカスしつつ、具体的な導入事例についてもご紹介します。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
文字、音声、画像、位置情報など、私たちの身の回りには多種多様なデータが存在しています。 「ビッグデータ活用」や「データドリブン経営」といった言葉が旬なキーワードとなっていますが、理由の1つとして市場やニーズの変化が速い、ということがあります。 この変化の激しい時代において、大量データを市場環境の分析や顧客ニーズの把握などに活かしていくことは、今日の企業にとって競争を勝ち抜くための重要な経営課題となっています。 すでに一部の企業はデータ分析基盤を導入し、多種多様なデータを効率的に分析することで市場の変化を迅速に捉え、自社製品・サービスの改善に活用しています。 そこで本コラムでは、データ分析基盤の基本的な構成や選定ポイントなどを解説します。 Index データ分析基盤とは？ データ分析基盤選定で押さえるべき5つのポイント IBM Cloud Pak for Dataについて この記事に関するお問い合わせ 関連情報 データ分析基盤とは？ データ分析基盤は、多種多様なデータを統合した上で分析・活用するためのソリューションです。Excel や CSVファイルを数個利用してデータを分析するだけであれば、大がかりなデータ分析基盤を用意する必要はないでしょう。 しかし、「大量のデータを分析したい」「複数の担当者で分担して分析したい」といった場合には、効率よく分析を行うためにデータ分析基盤の構築が必要となります。 代表的なのは AI を利用する際です。定期的かつ繰り返し分析を行う必要があるので、データ分析基盤があるとスピーディーに手間をかけず結果を出すことができるようになります。 データ分析基盤は主に以下の機能があります。 データを貯める 貯めたデータを分析するために整形・加工・クレンジングする 分析ツールを実行するためにデータを保管する 1.データを貯める（データレイク） データレイク（Data Lake）は、業務システムやデータベースといったデータソースから収集したデータを保管する役割を担う、まさに「データの湖」のような存在です。 データレイクには、何ら加工を加えていない生データ（ローデータ）の状態でデータを保管します。データ分析の過程では、その目的や扱うデータの内容に応じて、非構造化データの構造化データへの変換、データ形式の変換、データクレンジングといった様々な加工を施します。 一方で、加工したデータを元の状態に戻さなければならない場合もあります。そのような場合にも、データレイクに生データを保管していれば、速やかに加工前の元データを手に入れることが可能です。 2.貯めたデータを分析するために整形・加工・クレンジングする （データウェアハウス） データウェアハウス（Data Warehouse）はデータレイクとは異なり、分析しやすいように加工したデータを保管する役割を担います。 データレイクや個別のデータソースに存在しているデータを ETL（Extract/Transform/Load）ツールで抽出し、分析用途に合わせて加工した上でデータウェアハウスに格納します。 幅広いデータソースから収集した多種多様なデータを用いて分析を行うという場合には、あらかじめ加工済みのデータをデータウェアハウスに集めておいた方が分析をスムーズに進めることができます。 3.分析ツールを実行するためにデータを保管する（データマート） データマート （Data Mart）は、特定の用途で必要となる加工済みのデータのみを保管する役割を担います。 データウェアハウスは、データレイクや個別のデータソースから取り出して加工したデータをすべて保管します。 一方でデータマートは、「売上分析」「顧客行動分析」といった用途に合わせたデータのみを格納します。用途が限られている分、データウェアハウスよりも小規模なサイズでコストを抑えて構築することが可能です。 そのため、データ分析の目的が限定的な場合にはデータウェアハウスを用いることなく、データマートのみでデータ分析基盤を構築する場合もあります。 データ分析基盤選定で押さえるべき5つのポイント 実際にデータ分析基盤を選定する際には、次の5つのポイントを押さえることが重要です。 1. 属人化を防止できること データ分析基盤の構築・運用には高い専門性が欠かせないため、専門スキルを持った一部のデータエンジニアだけが利用するといった形で属人化してしまいがちです。 属人化した状態では担当者の退職や異動にともなう引き継ぎがうまくいかず、データ分析の継続が困難になってしまう可能性があります。そのため、データ分析基盤選びでは属人化を防止できるかどうかが重要な選定ポイントになります。 例えば、分析用途に合わせたデータを管理画面上で簡単に抽出できるようなデータ分析基盤であれば、より幅広いメンバーがデータ分析を担うことができるようになり、属人化の防止につながるでしょう。 2. 一気通貫でデータ分析基盤を利用できること 前述のとおり、一般的にデータ分析基盤は、データレイク・データウェアハウス・データマートといった複数のソリューションを組み合わせて構築します。 この構築段階で設計を最適化することができず、「構築後の改修や別のソリューションの追加などで思わぬコストが発生してしまった…」というのはよく聞くところです。 さらに、ソリューション間でのデータ連携の不具合によるサイロ化も懸念されます。 このようなリスクを低減するには、複数のソリューションを組み合わせるのではなく、データエンジニアやデータサイエンティスト、ビジネスユーザーといった様々な役割の人が一気通貫で利用できるようなソリューションを選ぶ必要があります。 3. スピーディーに分析を開始できること 分析にあたってデータマートを作成することは珍しくありませんが、データウェアハウスからバッチ処理で物理的にデータを抽出してくるので、データ量が多い場合にはどうしても時間がかかってしまいます。 一方で、データをマッピングすることで仮想的なデータセットを作成できるソリューションも登場しています。このようなソリューションであれば、バッチ処理によって物理的にデータを抽出するよりも素早くデータ分析を開始することが可能です。 4. 非構造化データを扱えること 従来、企業が扱うデータの多くはリレーショナルデータベースや CSVデータのように、列と行の概念を持った構造化データでした。 一方で、最近では電子メール、会議を録音した音声ファイル、PDF形式の契約書といった列と行の概念を持たない非構造化データが多くなっています。 IoTやスマートデバイスの進歩によってさらに膨大な量の非構造化データが流通するようになっている状況を踏まえると、非構造化データにも対応したデータ分析基盤を選ぶことが重要です。 最近では、AIを活用することで非構造化データの分析を効率化しているデータ分析基盤も出てきています。 5. 拡張性が高いこと スマートデバイスや IoT の普及によってデータ流通量が急増。2022年の世界のデータ流通量は、2017年時点と比べて3倍以上に達すると予測されています（※1）。 このような状況を踏まえると、データ量の増大を見越してホストやリソースの追加が容易で拡張性の高いデータ分析基盤を選ぶ必要があります。 ※1：総務省「令和元年版 情報通信白書」 IBM Cloud Pak for Dataについて 本コラムは、データ分析基盤の構成要素や選定時のポイントについて解説しました。 IBM Cloud Pak for Data は、企業のデータ活用を強力に推進するデータ分析基盤です。Red Hat OpenShift Container Platform 上で稼働し、クラウド・自社データセンターなど環境を選ばずに利用することができます。 また、IBM Cloud Pak for Data はコンテナ化されているため、自社のデータ環境に合わせてリソース・可用性を柔軟に調整することができます。まさに企業で利用するためのデータ分析基盤として最適な製品です。 こちらのホワイトペーパーでは、今回ご紹介したデータ分析基盤選定のポイントと合わせて IBM Cloud Pak for Data が選ばれる理由を解説しています。データ分析基盤の導入をご検討中の方は、ぜひ、ご一読ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM Cloud Pak for Data (製品情報) - データを洞察へと変換する方法をよりシンプルにし、自動化します。 IBM Cloud Pak for Dataが企業のデータ活用に選ばれる3つの理由 (ホワイトペーパー) - データ分析基盤選定で押さえるべき5つのポイントもご紹介！ 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 アプリケーションを稼働させる環境として、コンテナに注目が集まっています。 デジタルサービスに対する顧客のニーズが多様化し、かつ加速度的に変化している中、その顧客ニーズに対応しようとしている企業にとって、DevOps によるアプリケーションの開発・運用と共にコンテナ化には様々なメリットがあるのがその理由です。 本記事では、そんなアプリケーションの迅速な開発・展開が可能となるコンテナ化について、従来の仮想マシン上でアプリケーションを稼働させる場合との違いやメリットを解説します。 Index コンテナとは？ コンテナと従来の仮想化技術との違い コンテナのメリット コンテナ化の注意点 今日のビジネスにおけるコンテナの活用シーン IBM Cloud Pak for Applications について この記事に関するお問い合わせ 関連情報 コンテナとは？ コンテナとは、アプリケーション本体やライブラリといったアプリケーションの実行環境をパッケージングした上で、ホスト OS のコンテナエンジン上でプロセスやネットワークといったリソースを切り離して仮想環境を構築する技術のことです。 コンテナの中核をなしているソフトウェアは、主に以下の2つです。 コンテナエンジン コンテナエンジンは、ホスト OS 上でのコンテナの作成、削除、実行などを担います。代表的なコンテナエンジンとしては Docker がよく知られています。 オーケストレーションツール 単に開発環境としてではなく本番環境もコンテナ化する場合には、コンテナの運用管理を徹底する必要があります。そこで登場したのが、オーケストレーションツールです。 オーケストレーションツールは、コンテナ起動中のロールアウトやロールバック、データを保持するための外部ストレージのマウント、クラスタの構成、各コンテナの管理やログといったコンテナの運用に関わる様々な役割を担います。 代表的なオーケストレーションツールとしては、Kubernetes や OpenShift がよく知られています。 コンテナと従来の仮想化技術との違い これまで、アプリケーション稼働環境の構築手法としては仮想マシン型が一般的でした。 仮想マシン型の場合、物理サーバー上にアプリケーションやライブラリのほかにゲスト OS を含む仮想マシンを複数実装することで仮想環境を構築し、リソースの効率的な利用を実現します。 一方でコンテナの場合、各コンテナはアプリケーション本体やライブラリなどで構成されており、ゲスト OS は含みません。コンテナエンジンがホスト OS からネットワークやリソースを切り離した上で、単一のホスト OS 上での複数アプリケーション（コンテナ）の実行を制御しているからです。 これにより、仮想マシン型と比べるとより小さなリソース（CPU・メモリ・ディスク）でアプリケーションを稼働させることができるようになります。 コンテナのメリット 前項で述べたコンテナと仮想マシン型の仮想環境の実装を比べると、コンテナには次のようなメリットがあります。 1. 起動が速い 仮想マシン型の場合、アプリケーションを起動するためにはゲスト OS の起動をともなうため、アプリケーションが利用可能となるまでに数分から数十分程度の待ち時間が発生します。 一方コンテナの場合、アプリケーションを実行するための各コンテナはゲスト OS を含まないので、ゲスト OS を起動する待ち時間が発生しません。そのため、コンテナ起動後は数秒から数十秒程度でアプリケーションの利用を開始できます。 2. 処理が速い 仮想マシン型の場合、各仮想マシンからハードウェアにアクセスする際にハイパーバイザーとホストOS を経由します。そのため、物理環境と比べると処理速度が低下する難点があります。 コンテナの場合には、各コンテナからハードウェアへのアクセスをホスト OS が直接制御します。そのため、仮想マシン型と比べて物理環境に近い処理速度で仮想環境を利用可能です。 3. ハードウェアのリソース消費を減らせる 仮想マシン型の場合、アプリケーションを実行するためのサーバーを増やす（スケールアウト）にはアプリケーションやライブラリのほかにゲスト OS を含む仮想マシンを追加しなければなりません。 特にゲストOS自身が多くのリソースを消費するので、スケールアウトすることによってハードウェアのリソースを消費し、アプリケーションで利用できるリソースが逼迫してしまいます。 繰り返しになりますが、コンテナの場合、各コンテナはゲストOS を含みません。 そのため、ハードウェアのリソース消費を抑えながらアプリケーションをスケールアウトすることができます。 4. 環境を選ばず実行できる ゲスト OS を含む OS 単位で構成された仮想環境の仮想マシン型とは異なり、コンテナはアプリケーション単位で構成された仮想環境です。 そのため、作成したコンテナは、パブリッククラウドやオンプレミスといったアプリケーションの配置場所や物理サーバー・仮想サーバーのようなサーバー環境の違いに依存せずに実行できます。 5. ほかのアプリケーションから分離された開発環境で作業できる エンジニアは、コンテナ上で開発したアプリケーションをほかのアプリケーションから分離された開発環境で扱えるようになります。 また、コンテナには特定のバージョンのプログラミング言語ランタイムやライブラリ、アプリケーションの実行に関わる依存関係などを組み込めるので、最終的にそのコンテナがどの環境にデプロイされてもアプリケーションとしての一貫性を保つことが可能です。 コンテナ化の注意点 前項で挙げたように、アプリケーションのコンテナ化には様々なメリットがあります。 一方で、コンテナ内でデータを保持する場合には注意が必要です。コンテナを削除すると、コンテナ内のデータも一緒に削除されるからです。 したがって、コンテナで扱うデータを保持する場合には、データを永続化させるための構成を検討する必要があります。 具体的な方法としては2つあります。 コンテナエンジンを稼働させているホスト OS 上にデータを保管する 外部（共有）ストレージにデータを保管する 1.では、コンテナ上で保存するデータをホストOS上の領域に保管する設定ができます。 しかし、サービスを提供する本番環境では可用性・拡張性を確保する必要があり、一般的には複数台のホストOS 環境を用意することになります。 この方法の問題点として一番大きいのは、アプリケーションのスケールアウトや、障害対応のために当初稼働していたホストOS とは別のホストOS でコンテナを稼働させるといった場合に、データの引き継ぎが行われず結果としてデータロストが発生してしまう可能性があります。 2.では、複数のホストOS からアクセス可能な共有ストレージにデータを保管します。 その場合は1.で実現できなかったホストOS をまたいだコンテナのスケールアウト・移動にも対応できるようになります。 また、コンテナを停止するとコンテナ内に保存していたデータが消えるという特性上、仮想マシン型のようなバックアップ取得は難しくなります。 そのため、アプリケーション内にバックアップ機能を追加する、データの保管先を意識した設計に変えるといった考慮が必要になります。 今日では、コンテナ化にあたっての懸念材料となるデータの永続化について、バックアップ機能を持ったオーケストレーションツールや NAS とのパッケージングなどによって解消できるソリューションも登場しています。 今日のビジネスにおけるコンテナの活用シーン ここまで解説したように、アプリケーションのコンテナ化には様々なメリットがあります。冒頭でも述べたように、これらのメリットは顧客ニーズの多様化に対して自社のデジタルサービスをスピーディーに適合させようとしている企業にとって大きなインパクトがあります。 今日のようにビジネス環境の変化が著しい中で、企業は顧客ニーズを自社サービスに素早く反映することが求められています。 とはいえ、これまでの「ウォーターフォール」型手法ではスピーディーな実現が難しくなります。「アジャイル開発」的な発想で自社のデジタルサービスを日々アップデートしていく必要があります。 これまで、デジタルサービスはモノシリックな形で作り上げるのが一般的でした。モノシリックとは、単一のアプリケーションとしてデジタルサービスを作り上げるソフトウェアのアーキテクチャのことです。 小規模なデジタルサービスの開発には適していますが、コードベースの拡大に伴って修正・テストに時間がかかる・コードのバージョン管理といったメンテナンスが煩雑化しやすいという難点があります。 そのため、サービスの改修や追加をスピーディーに実行することが難しく、高頻度でのアップデートを前提としたデジタルサービスを開発するアーキテクチャに適しているとは言えません。 こうした中で、多くの企業の関心を得ているのがデジタルサービスのマイクロサービス化です。 マイクロサービスとは、細分化された個々のサービスを連携させて1つのデジタルサービスを作り上げるというソフトウェアのアーキテクチャです。すでに一部の企業は、自社のデジタルサービスをマイクロサービス化した上で、それぞれを高頻度でアップデートすることにより顧客ニーズに素早く対応しています。 そして、前述したようにアプリケーションをコンテナ化することによって、開発者はほかのアプリケーションから分離された環境で開発を行うことができるようになります。 これはつまり、アプリケーションをマイクロサービス化・コンテナ化することによって、コンテナ上で開発したアプリケーションをマイクロサービス化した機能単位でスピーディーに開発できるようになるということです。 したがって、アプリケーションのコンテナ化・マイクロサービス化によってマイクロサービス単位のアップデートを繰り返すことが容易にになり、顧客ニーズを早期にキャッチアップした継続的なアップデートを行うことで顧客満足度を向上し企業価値を高めることができます。 IBM Cloud Pak for Applications について 本コラムは、アプリケーションのコンテナ化とそのメリットについて解説しました。 今日、デジタルサービスに求められる必須要件としてのアプリケーションのコンテナ化をスピーディーに実現できるツールの1つが、IBM Cloud Pak for Applications です。 IBM Cloud Pak for Applications は、Red Hat OpenShift を基盤としてアプリケーションのモダナイゼーションを支援する製品です。 Cloud Pak シリーズには他に、データ管理、システム連携、マルチクラウド管理、セキュリティといった様々な機能に特化した製品があります。 ユーザーは、IBM が築き上げたベストプラクティスとして提供されるコンテナ・イメージを活用できるので、オンプレミスやクラウドといった環境を問わず、IBM Cloud Pak for Applications を利用して既存アプリケーションのコンテナ化を実現できます。 アプリケーションのコンテナ化に関心をお持ちの方は、ぜひ、IBM Cloud Pak for Applications をご検討ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編 (ブログ) - シリーズ第1回目！概要編として検証の目的・背景や環境周りをご紹介します。 IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
