特集・ブログ

コラム

2020年09月30日

DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは?効率的な対策は?

近年、大規模な自然災害が増加していることから DR の重要性が高まっています。 DR は「Disaster Recovery」の略であり、文字どおり「災害時にどう復旧するか」という対策を指します。 ひと言で「災害からの復旧」と言っても対策は多岐にわたり、求める対策のレベルによって運用にかかるコストにも違いがあります。どこまで対策をすればいいのか、悩む企業も多いのではないでしょうか。 今、改めて押さえておきたい 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 対策を目指しましょう。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 IBM Spectrum Archive IBM Spectrum Virtualize for Public Cloud IBM Spectrum Protect IBM Spectrum Protect Plus 今、BCPで求められるITシステム対策について解説。考えるべき基本は?最優先すべきポイントは?

2020年09月30日

今、BCPで求められるITシステム対策について解説。考えるべき基本は?最優先すべきポイントは?

災害など緊急事態における対策を定める「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 などを活用したデータ保全対策を整備しておくことをお勧めします。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 IBM Spectrum Archive IBM Spectrum Virtualize for Public Cloud IBM Spectrum Protect IBM Spectrum Protect Plus DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは?効率的な対策は?

2020年09月28日

コロナ禍で基幹システムでもクラウド移行が急拡大!の背景を探る

コロナ禍で売上が落ち込んでいる企業を中心に、IT 投資を再検討する動きが広まっています。 オンプレミスのシステムを運用するケースでは、膨大な更改コストを回避するため初期費用を抑えて利用開始できるクラウドに移行する企業が増えており、コロナ禍を機に企業のクラウドシフトが一気に進みそうな予感です。 本コラムでは、ミッションクリティカルな領域である基幹システムにおける新たな課題について触れつつ、クラウド移行を検討する企業に向けて、お勧めのマネージド型クラウドサービスについて紹介します。   コロナ禍を機に、基幹システムのクラウドシフトが加速 コロナ禍で産業全体の売り上げが減少する中、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 (ソリューション)Withコロナ時代の NI+C P お勧めソリューション (コラム)IBM Power Systemsユーザーのクラウド移行ニーズに寄り添う「Cloud Power」の魅力に迫る

2020年09月02日

データ分析基盤とは?基本から選定のポイントまで解説!

文字、音声、画像、位置情報など、私たちの身の回りには多種多様なデータが存在しています。 「ビッグデータ活用」や「データドリブン経営」といった言葉が旬なキーワードとなっていますが、理由の1つとして市場やニーズの変化が速い、ということがあります。この変化の激しい時代において、大量データを市場環境の分析や顧客ニーズの把握などに活かしていくことは、今日の企業にとって競争を勝ち抜くための重要な経営課題となっています。 すでに一部の企業はデータ分析基盤を導入し、多種多様なデータを効率的に分析することで市場の変化を迅速に捉え、自社製品・サービスの改善に活用しています。 そこで本コラムでは、データ分析基盤の基本的な構成や選定ポイントなどを解説します。   データ分析基盤とは? データ分析基盤は、多種多様なデータを統合した上で分析・活用するためのソリューションです。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つの理由 IBM Cloud Pak for DataのトライアルとCloud Pakシリーズアップデート情報【2020年8月更新版】 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット 全ての企業が AI カンパニーになる!「IBM THINK Digital 2020」に参加した IBM Cloud Paks シリーズ ご紹介資料 (IBM サイト)IBMデモ Cloud Pak for Data

2020年08月18日

今、デジタルサービスに求められる必須要件とは!? アプリケーションのコンテナ化で得られる5つのメリット

IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 アプリケーションを稼働させる環境として、コンテナに注目が集まっています。 デジタルサービスに対する顧客のニーズが多様化し、かつ加速度的に変化している中、その顧客ニーズに対応しようとしている企業にとって、DevOps によるアプリケーションの開発・運用と共にコンテナ化には様々なメリットがあるのがその理由です。 本記事では、そんなアプリケーションの迅速な開発・展開が可能となるコンテナ化について、従来の仮想マシン上でアプリケーションを稼働させる場合との違いやメリットを解説します。   コンテナとは? コンテナとは、アプリケーション本体やライブラリといったアプリケーションの実行環境をパッケージングした上で、ホスト 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 をご検討ください。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 (製品情報)IBM Cloud Pak for Applications 全ての企業が AI カンパニーになる!「IBM THINK Digital 2020」に参加した Cloud Pak for DataのトライアルとCloud Pakシリーズアップデート情報 IBM Cloud Paks シリーズ ご紹介資料 (IBM サイト)IBMデモ Cloud Pak for Applications 【やってみた】IBM Cloud Pak for Applications導入してみた:概要編

2020年08月17日

AIによる需要予測は、どこまで使えるのか?成功と失敗の分岐点を解説

AI 活用が期待される分野の1つが「需要予測」です。 工場での生産量や部材仕入れ、販売量から営業成績、不動産の価格変動など、従来はベテランスタッフの経験や勘に頼ることが多かった領域を AI で代替できれば大きな効果につながります。 AI・機械学習のなかでも導入が進んでいる需要予測ですが、いざ自社で導入するとなると懸念も大きいもの。 本記事では、需要予測に成功したケースと失敗したケースの違いとともに、その分岐点がどこにあるのかを考えます。   「需要予測」では、精度UPのための試行錯誤が必須 AI による「需要予測」では、過去のデータや気象情報、周辺市場といった変動要素などを学習し、変化のトレンドを導き出すことで次の変化を予測します。 「ベテランの経験や勘」と言われているものもこれらの情報をベースにしているはずですが、どの情報をもとに考えているのか明確になっていないケースが多く、「経験や勘」を別のメンバーに引き継ぐにはかなりの時間がかかってしまいます。AI を利用すれば「どの情報が関連しているか」「より影響が大きい情報がどれか」などが可視化され、データをもとにした需要予測が可能になります。 もちろん AI も最初から正確な予測ができるわけではなく、様々なデータを学習させ、試行錯誤しながら精度を改善する必要があります。一般的には、直近1年間について AI による予測データと実績データを突き合わせることで検証し、相関性の高いデータや結果への影響度が大きいデータを見極めながらチューニングを繰り返します。   成功・失敗の分岐点は「必要なデータが揃っているか」 AI による需要予測も、成功するケースと精度があがらず失敗に終わるケースがあります。両者の違いはどこにあるのでしょうか? 成功ケースを見ると、信用できるデータを大量に確保できており、その中から需要予測につながるデータを特定することで高い精度での予測を実現しています。 一方失敗したケースの要因としては、関連するデータの種類が少ない、データの精度が信用できない、予測モデルの設計に問題がある、などが挙げられます。 このように、成功と失敗の分岐点には「必要なデータが揃っているかどうか」が大きく関わってきます。 上述したとおり、AI にできるのは「大量のデータから相関関係を導くこと」です。そのために必要なデータがなければ、AI を導入しても期待する成果は得られません。 また、必要なデータといっても予測したい内容に直接関係するものばかりでなく、様々な観点から関連するデータが揃っていることも重要ですし、適切な予測モデルを採用したうえでデータごとに関連性・重みづけをチューニングする必要があります。 需要予測を成功させるためには、関連するデータの質と量を揃えるとともに、適切なモデルを設計できるデータサイエンティストの存在が不可欠と言えそうです。   データサイエンティストに代わるツールの登場で、AI導入のハードルは下がっている AI 導入を成功させるには必要なデータを揃えることが重要…とはいえ、データを用意するのは一筋縄ではいきません。 「社内にどのようなデータがあるのか分からない」「必要なデータがどこにあるか分からない」「手入力のためデータの精度が不安定」「部門間で連携できない」など様々なハードルがあるほか、そもそも「属人的な要素が強く、データ化できない」というケースも。まずはデータ連携を進め、データを統合管理できる環境を整備することも大切です。 予測モデルの設計やデータの重みづけに関しては、専門知識・スキルを持つデータサイエンティストが担っており、精度を上げるためにチューニングを繰り返し、かなりの時間がかかるのが一般的でした。 しかし、これらの作業を自動化する "H2O Driverless AI" のようなツールが登場したことでハードルが大きく下がっているのも事実。高い分析スキルを持つ人材がいなくても、短期間で一定の成果を導くことは十分可能になってきています。 これまで二の足を踏んでいた企業も、そろそろ本格的に AI 導入を検討するタイミングと言えるのではないでしょうか?   「H2O Driverless AI」をPoC環境でお試しいただけます 記事内で取り上げた「H2O Driverless AI」のPoC環境をご用意していますので、検証などの用途でご利用いただけます。ご利用いただき効果や使い易さなど、検証から導入の可否を判断できるのが大きなメリットです。 AIによる機械学習の導入をお考えの企業様には、要件定義前の検討段階でのご利用をおすすめしております。 PoC環境の利用をご希望の場合は、お取引のあるパートナー様経由での申請をお願いいたします。お取引のあるパートナー様が不明の場合はお問い合わせください。 *競合製品取り扱い企業様の申込については、お断りする場合がありますので予めご了承ください。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 Driverless AI ご紹介資料 IBM AI ソリューションの事例ご紹介(IBM PowerAI Vison、Driverless AI) 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1) 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その2) 【やってみた】超簡単データ分析!H2O Driverless AI を使ってみた H2O Driverless AI IBM Visual Insights(旧 IBM Power AI Vision) IBM Power System AC922 ”Newell” IBM Power System IC922 【コラム】普及が進む、機械学習による異常検知。導入の課題はここまで解決している AI導入はどこまで現実的? 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している

2020年08月03日

普及が進む、機械学習による異常検知。導入の課題はここまで解決している

様々な用途への活用が進む機械学習。なかでも実用化が進んでいる分野の1つが異常検知です。 従来は人がチェックしていた異常を機械学習で検知することにより、負担軽減・精度向上などにつながると期待を集めています。また、モデル生成などを自動化する機械学習ソリューションが登場、導入のハードルが大きく下がったことも後押しとなり、普及が本格化しつつあります。 本記事では活用が進む現状とともに、導入における課題とその解決策までをまとめて紹介します。   機械学習の異常検知では、何を検知できるのか? 機械学習の異常検知はセンサーデータや画像データなどを学習させ、正常として定義したデータとマッチしないデータパターンを検知することで実現します。大きく、期待されるデータと異なるデータが現れたときに検知する「外れ値検知」、異常が起きているタイミングを部分的に検知する「異常部位検出」、データの急激な変化を検知する「変化点検知」の3つの手法があります。 これらの手法や機械学習のモデルなどを用途にあわせて選択、チューニングすることで、精度を高めていくのです。 実際に活用が進んでいる事例として、製造業における検品作業があります。設備から出力されるセンサーデータから問題発生を検知するのとあわせ、画像データからキズや欠陥がないかを検知することで高い精度を実現。ベテランスタッフのスキル継承、検品作業の負担軽減、人件費削減など大きな効果につながっています。 ほかにも、小売業では店舗における人の振る舞いの異常検知や、売り場の状態(欠品や位置ずれなど)を監視・分析することで売り場メンテナンスの効率化につなげる事例、金融業における不正検知など様々なシーンで導入されています。   人材・データ・インフラ、異常検知導入を阻む3つのハードル このように活用が進む異常検知ですが、いざ自社で取り入れるとなるとハードルが高いもの。なかでもまず挙げられるのが「人材」です。 機械学習の手法やモデルから自社の目的にあったものを適用し、精度を上げるには専門知識が欠かせません。これらの知識・スキルを持つデータサイエンティストが、自社にそろっている企業は少ないのではないでしょうか。 また、もう1つ課題となるのが「データ」。 機械学習を行うには適切なデータがそろっていることが前提であり、データ量が多ければ多いほど精度が上がります。ですが、「機械学習に使える適切なデータがない」「データ量が少ない」といったケースは多く、この準備に機械学習のワークロードのうち大半を費やすとも言われています。 最後に検討が必要なのがインフラです。 クラウドファーストが当たり前になった今、特に機械学習のような最新技術はクラウド上に構築するケースも多く見られます。 しかし、利用するデータは機密レベルが高いことが多く、精度を上げるためにデータ量を増やすと、ネットワークのコスト増にもつながります。また、機械学習では様々なデータで試行錯誤をしながら精度を上げるため、その都度、大量のデータをクラウドにアップロードする必要があります。 予算・パフォーマンス・セキュリティのバランスを考慮すると、オンプレミスでの導入が有力候補に。オンプレミスでどのように機械学習の環境を構築するかも大きなハードルとなるのです。   導入のハードルを大きく下げる、最新ツール・ソリューションとは 上記の状況の解決策として今注目されているのが、モデル生成など従来データサイエンティストが担っていた部分を自動化し、コーディング不要で機械学習を開発できるツールです。 なかでも「H2O Driverless AI」は使いやすいUIで、精度の高いモデルを作成できることが強み。「どのデータが結果への影響が大きいか」といった重みづけも自動でおこなうため、データサイエンティストのような専門家がいなくても自社で導入することが可能になります。 もちろん「期待する結果を得るために、どういったデータが影響するか、そのデータはどこにあるのか」といったツールを活用する前段階の作業が必要なことは変わりません。ただし、これらは自社業務に密接にかかわるもの。社内業務に精通した人材で対応できるケースも多いでしょう。 こういったソリューションを利用することで、環境構築のハードルは大きく下がるはずです。オンプレミスでの導入が容易になれば、クラウドにはあげられなかったデータを分析できるなど活用の幅も広がります。 従来、人が手作業でしていた異常のチェックを機械学習で自動化することにより、業務効率化・コスト削減・負担軽減・品質向上など得られる効果は大きいもの。すでにこのようなツールを駆使し、機械学習による異常検知を導入している企業も増えています。「業務に活用するとしたら、どこに取り入られるのか」をまずは検討してみてはいかがでしょうか。   「H2O Driverless AI」をPoC環境でお試しいただけます 記事内で取り上げた「H2O Driverless AI」のPoC環境をご用意していますので、検証などの用途でご利用いただけます。ご利用いただき効果や使い易さなど、検証から導入の可否を判断できるのが大きなメリットです。 AIによる機械学習の導入をお考えの企業様には、要件定義前の検討段階でのご利用をおすすめしております。 PoC環境の利用をご希望の場合は、お取引のあるパートナー様経由での申請をお願いいたします。お取引のあるパートナー様が不明の場合はお問い合わせください。 *競合製品取り扱い企業様の申込については、お断りする場合がありますので予めご了承ください。   この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考情報 Driverless AI ご紹介資料 IBM AI ソリューションの事例ご紹介(IBM PowerAI Vison、Driverless AI) 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1) 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その2) 【やってみた】超簡単データ分析!H2O Driverless AI を使ってみた H2O Driverless AI IBM Visual Insights(旧 IBM Power AI Vision) IBM Power System AC922 ”Newell” IBM Power System IC922 【コラム】AIによる需要予測は、どこまで使えるのか?成功と失敗の分岐点を解説 AI導入はどこまで現実的? 5大ハードルとその解決策を解説

1 2
back to top