特集・ブログ

ブログ

2020年08月18日

【やってみた】IBM Cloud Pak for Applications導入してみた:概要編

IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 こんにちわ。 てくさぽ BLOG メンバーの佐野です。 今回はIBM Cloud Pakシリーズの1つである「Cloud Pak for Applications」の導入を弊社内で検証してみたので3回シリーズで検証で得られた知見をお伝えします。 第1回目の本記事では、概要編として検証の目的・背景や環境周りをご紹介いたします。   *連載の続きはこちら 【やってみた】IBM Cloud Pak for Applications導入してみた:OpenShift導入編(第2回) 【やってみた】IBM Cloud Pak for Applications 導入してみた:Cloud Pak for Applications 導入編(第3回)   Cloud Pak for Applicationsの導入検証をした 背景・目的 以前のブログでCloud Pak for Dataの導入について紹介をしました。 その際はIBMの製品であるIBM Cloud Privateをコンテナ基盤としたCloud Pak for Data 2.1の導入であったため、インストーラを実行するとIBM Cloud PrivateとCloud Pak for Dataの両方を導入できました。 その後、Cloud Pakシリーズを導入するための基盤としてOpenShift Container Platform(以下OpenShift)に一本化となり、OpenShiftを導入した上でCloud Pakシリーズを導入する方式となりました。 Cloud Pakシリーズを導入するためにOpenShiftが前提となるなら、OpenShiftのスキル習得しなくては!ということでOpenShiftの導入スキルを習得することを主な目的として導入の検証をしてみることにしました。 OpenShiftだけを導入したのではCloud Pak導入までの確認ができないため、手順や製品の中身を確認した上で一番導入が簡単にできそうなCloud Pak for Applicationsの導入もしてみよう。ということになったのが今回の検証をすることになった背景です。   OpenShift/Cloud Pak for Applicationsを利用する メリット さて、何故Cloud Pakシリーズを動かすための基盤がOpenShiftに一本化されたのでしょうか? この説明のためにはIBMの戦略とRed Hatを買収した目的を理解する必要があります。 まず、IBMは企業向け(の中でも特に大企業向け)のソフトウェアソリューション提供を強みにしている会社です。 10年前であればサーバーといえば自社データセンターに置くものでしたがAWSやAzureといったパブリッククラウドが普及し、アプリケーションを稼働させる環境が自社データセンター内に留まらず、パブリッククラウドで動かすことも多くなってきています。 IBMとしても手をこまねいているわけではなく2013年にSoftLayer社を買収し本格的にパブリッククラウド市場へ参入していますが、2020年3月時点のシェアを見ても決して成功している状況ではありません。 そんな中2018年10月にRed Hat社を買収すると発表し、2019年7月に買収が完了しました。 これらの動きから見て取れるIBMの戦略は、どのクラウドであってもIBMソフトウェアを稼働させることができる「ハイブリッドクラウド・マルチクラウド化の推進」です。 それを実現するために、既にAWSやAzure上でもサービスとして提供されているOpenShiftを共通基盤として据えることが必要だったのです。 OpenShift上で稼働するCloud Pakシリーズであればお客様がクラウド上(自社データセンター含む)で動かしたい、といった場合であってもほとんど対応することができ、Cloud Pakのコンポーネントがコンテナ化されているため、単独で提供されている製品よりも可用性・拡張性にも優れます。 Cloud Pakシリーズの中でもCloud Pak for Applicationsはお客様が開発したアプリケーションのモダナイゼーションを支援するツールが含まれており、Cloud Pak for Applications上で現在のアプリケーションを動かしつつ、モダナイゼーション支援ツールを使ってアプリケーションのクラウドネイティブ化を進めることができます。 もちろん、企業として担保すべきガバナンスや品質を維持・向上させるための機能も含んでいます。 このCloud Pak for Applicationsを使うことでアプリケーションをモダナイゼーションし稼働させることができる、ということが大きなメリットです。   導入検証環境 導入検証で利用した環境ですが、今回はAWSを利用しました。 理由としては、IaaSとしてシェアが高いサービスであり、AWS上での知見を得ておくことで構築プロジェクトでも役立てることができると考えたためです。 導入方式 AWS上で検証することを決めたわけですが、AWS上での構築方法を調べると大きく2種類あることが分かりました。 1つはIPI(Installer Provisioned Infrastructure)と呼ばれる方法、もう1つがUPI(User-Provisioned Infrastructure)と呼ばれる方法です。 簡単に違いを上げると、IPIではドメイン名などの初期設定を定義してインストーラーを実行すると自動的にOpenShiftのノードが展開され、利用可能となります。 インストールが自動化されているので展開は楽ですが、設定がある程度固まった状態での展開となるため細かい変更ができません。また、最小のWorkerノード数もAWSの場合では3ノードであるため、導入検証するには少し勿体ないです。 UPIではユーザー自身がロードバランサーやOpenShiftのノードを導入・設定する必要がありますが、設定を自身で決められるので柔軟性が高いといえます。またOpenShiftとしての最小構成でWorkerノード2台の構成とするためには自身でインストール時に設定する必要があります。 今回は最小構成でCloud Pak for Applicationsの導入検証をするため、UPIでの導入検証をしています。 導入検証の環境 今回導入検証をする環境について簡単に説明をします。 環境・サーバー構成の概要図は以下となります。 簡単に構成を説明します。 OpenShift 4.2での導入検証を行うため、Masterノード(Control Plane)を3台が最小構成です(図の中央)。Workerノードは2台となります(図の右側)。 それ以外にはDNSのサービスであるRoute 53でOpenShift用のインターネットドメインを登録・管理しています。(図の左側中段) ユーザーからのアクセスを3台のMasterノードが受けるために外部ロードバランサーが必須で、MasterノードからWorkerノードへのトラフィック用に内部ロードバランサーも構成しています。(それぞれInternetGatewayとControl Planeの間、Control PlaneとWorkerの間) また、永続ストレージ用にNFSサーバーを構築し、OpenShift環境に割り当てすることでデータを保管します。(図の右下) 特長的なのは図の左下にあるBootstrapというサーバーで、OpenShiftのインストールコマンドをインストール作業用PCで実行した後はこのBootstrapサーバーから各ノードへOpenShiftのインストールを実行します。初期導入が完了した後にはこのサーバーを削除します。(図の左下) なので、Bootstrapサーバーは本番運用が始まった時には削除して稼働していない状態となります。インストール専用マシンですね。 インストールを実行するための作業用端末も別途必要となり、こちらはLinuxかMacがOS要件です。WindowsがNGなので用意するのが意外と大変かもしれません。(図の左端) 今回の検証ではVirtual Box上にCentOSを導入し、インストール作業を実施しています。   最後に 第1回目の本記事でCloud Pak for ApplicationsをOpenShift上に導入検証をする目的とその環境・構成がどのようになっているかがご理解頂けたと思います。 第2回ではOpenShiftを実際に導入した手順と苦労した点についてお伝えしますので次回のブログもご覧ください!   この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp   参考情報 (製品情報)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 今、デジタルサービスに求められる必須要件とは!? アプリケーションのコンテナ化で得られる5つのメリット

2020年07月13日

【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして予想する (その2)

皆さま、こんにちは。 てくさぽBLOG メンバーの佐藤です。 前回の続きになります。 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1)   今回の目的 DriverlessAIによって予測した内容と実際の結果を照らしあわせ、予測の精度が有用かどうか検証します。 前回、回帰分析が終了したところまで、書きました。 回帰分析した内容を確認します。   回帰分析結果を確認 イテレーション検証スコア まず、左下の赤枠の中、イテレーション検証スコアから確認します。 こちらの内容はどのくらいの精度で的中するかになります。 0に近づくほど精度が高くなります。 スコアリングについては前回記載した通りMAEやRMSEをご確認ください。 スコアが、2.6021という値ですので、仮にスコアが1として1着予測としても3着程度までが平均精度になります。   特徴量の重要度 次に下中央の特徴量の重要度です。 こちらの内容はどのようなデータを用いて予測するのか?になります。どのデータを元にしどのような割合で利用するのか、予測の調合データです。 上に行くほど高い重要度になりますので、より着順に関係性が深い値ということになります。 一番上の CVTE とは Cross Validation Target Encoding の略で、着順が低いともう一方の数値の傾向があるという関連性を見つけており、CID調教素点は調教データを数値化した指数となります。 つまり、調教が良い状態であれば結果(着順)も良いという事になります。 2行目にご注目ください。 Freq とありますが、Frequency Encoding の略になります。Frequency Encoding とは、こういう条件のときにこうなりやすいという確率です。 例えば、"芝で1枠だと1着になりやすい" といった傾向分析になります。 このケースの場合、"情報指数" "条件" "距離適性" という3つのデータの特定条件が揃うと着順に対して傾向がある事を DriverlessAI が発見しています。 Driverless AI の特徴として個々の列データの特徴だけでなく、複数列のデータを組み合わせ新たな条件を作り出せます。 複数の列データの組み合わせ及び抽出条件を様々テストするというのは手作業でやるには大変な労力になります。また人間の目でみて関係なさそうな組み合わせからも有効な組み合わせを発見できる、これが Driverless AI の強味になります。   予測 回帰分析が完了しましたので次は予測してみます。 まずは予測したいファイルを用意します。 今回回帰分析したデータは2020年3月頭までになるため、それより後の日付のデータを用意します。 回帰分析したデータを予測データとして読み込むと予測は可能ですが、非常に高い精度で的中してしまいますので、回帰分析に用いたデータより未来の2020年4月~2020年5月16日までのデータを用意しました。 Experience 画面から他のデータセットを用いて予測を押し、データを選択します。 するとしばらく待った後ファイルダウンロードが始まりますので保存します。 DriverlessAI の内部では回帰分析で生成された条件式に従い計算するという作業しますが、答え合わせの処理ですので、回帰分析する時間よりはかなり短い時間で終わります。 少し待った後ファイルダウンロードが始まりますので保存します。 保存したファイルを開くと最終列に "着順.predicted" という列が追加されています。 これが DriverlessAI が予測した順位になります。 予測結果は小数点で表示されます。   検証 実際の結果と予測データを照らし合わせます。 的中率を算出します。 今回は3連複、ボックス6頭という DriverlessAI の結果の数字が低い順に6頭を選ぶと仮定して当たりはずれを検証しました。 3連複は任意の3頭が1着2着3着に入ることを予測する買い方になります。BOX は任意の数でのすべての組み合わせとなります。6頭BOX ですと20通りになります。 仮に12~18頭レースとすると三連複の組み合わせは220~816通りありますので、単純な確率ですと6頭BOX の場合の的中率は 2.5%~9% となります。 結果444レース中187レース的中しました。的中率約 41% となります。 純粋に的中率でいえば、完全なランダムと比較して圧倒的に高い数字ですので、予測は機能してるという事はわかります。   さらに精度を上げる ここからはもう少し結果に対して掘り下げを行います。根気よくデータを見ることによってさらに精度を上げることができます。 今回のケース、条件によって的中率に変化があるのか検証します。 エクセルで頑張りましたが、この作業の時に IBM SPSS のような BIツールがあれば便利ではないかなと感じました。 いくつか見方を試してみたところ、レース番号と距離よって的中率にばらつきがあることがわかりました。   レース番号と的中率の関係 レース番号 レース数 あたり はずれ 的中率 1 37 23 14 62% 2 37 17 20 46% 3 37 16 21 43% 4 37 19 18 51% 5 37 11 26 30% 6 37 16 21 43% 7 37 19 18 51% 8 37 12 25 32% 9 37 16 21 43% 10 37 17 20 46% 11 37 9 28 24% 12 37 10 27 27% レース距離と的中率の関係 レース距離 レース数 あたり はずれ 確率 1000 3 0 3 0.0% 1150 13 5 8 38.5% 1200 76 23 53 30.3% 1300 5 4 1 80.0% 1400 57 27 30 47.4% 1600 57 25 32 43.9% 1700 26 11 15 42.3% 1800 97 40 57 41.2% 1900 4 1 3 25.0% 2000 47 21 26 44.7% 2100 5 2 3 40.0% 2200 11 4 7 36.4% 2300 2 0 2 0.0% 2400 15 11 4 73.3% 2500 1 1 0 100.0% 2600 5 3 2 60.0% 2750 5 2 3 40.0% 2770 5 3 2 60.0% 2880 1 0 1 0.0% 2890 3 1 2 33.3% 3140 1 1 0 100.0% 3200 1 0 1 0.0% 3380 1 1 0 100.0% 3930 1 0 1 0.0% 4250 1 0 1 0.0% 第5レースと第11レースと第12が的中率が悪いため、外してみます。 次に20レース以上ある中で的中率が悪い距離を見てみます。 1200mが30%程で悪いので外します。 276レース中137的中で的中率49.6%という事でほぼ半分当てることができました。   払戻金傾向 払戻金に傾向があるか回帰分析してみます。 今度は配当金のデータを Driverless AI で解析してみます。 やり方は同じで Terget を配当金にします。 "このモデルを解釈" をクリックすると、データの傾向がわかります。 発走時刻で見ますと14:45以降が配当金が高い傾向がわかります。 14時45分以降ですと10R~12Rとなります。 こちらの条件で絞ると、狙い目のレースを絞ることができます。   AC922の優位性 最後に今回のデータを使って、AC922 と一般的な IAサーバとで DriverlessAI の回帰分析時間を比較してみました。 条件をそろえるためにどちらもGPUは "無効"、 AC922 については、"48スレッド(Power9は1Coreあたりのスレッド数4)" "メモリ128GB" に制限して実行しました。 【AC922(8335-GTH)】 Power9 2.4GHz~3.0GHz 40コア160スレッド →48スレッドに制限 メモリ1024GB →128GBに制限 GPU NVIDIA V100 16GB ×2 →GPU無効 960GB SSD ×2(RAID1) 回帰分析完了までの時間:2時間39分43秒 【IAServer】 Xeon E5-2680v3 2.5GHz~3.3GHz 12コア24スレッド メモリ128GB GPU Titan RTX ×1 →GPU無効 480GB SSD ×1 回帰分析完了までの時間:4時間23分54秒   まとめ AIで競馬予測のまとめに入ります。 今回、出た予測結果に対して内容を掘り下げることをによって、適用条件を絞ることによりさらに高い精度で運用できる事を確認できました。DriverlessAI の結果そのままではうまくいかない場合は範囲を絞って運用し、知見を貯め、追加のデータを用意し、徐々に適用範囲を広げていくのが良いと感じました。 また、AC922 Power9 の強力な演算性能により短時間で終わらせることも確認できました。

2020年06月29日

OpenShiftに代表されるコンテナ環境へのIBMストレージの対応

IBMの岡田です。前回の「全包囲網。。。最新 IBMストレージ 概要」はいかがでしたか? 今回は、今流行りのコンテナ環境とIBMのストレージがどのようにこれらの環境に対応しているのかに触れてみたいと思います。   コンテナって何? ある調査によると、クラウドファーストを掲げて次々とクラウド環境に IT を移していくといった流れは世界中の ITワークロードの5分の1ほど移ったところで一段落していると言われています。今日では従来型IT環境、仮想化環境、プライベートクラウド環境などのオンプレミス環境と、複数から成るパブリッククラウド環境を上手く使い分ける時代に入ってきたという人もいます。 何れにせよ、今後の IT はこう言った環境の種類に依存することなく、適材適所かつ必要に応じていかなる環境でも同じようにアプリケーション開発や検証ができ、完成されたアプリケーションをどこでも同じように作動させることができ、場合によってはそれぞれの環境で連携して動くと言った技術が必要になってきます。 この要求に応えることができるのがコンテナ技術です。 [caption id="attachment_90768" align="alignnone" width="600"] 図1. 仮想環境とコンテナの比較[/caption]   コンテナのメリット [caption id="attachment_90871" align="alignnone" width="600"] 図2.コンテナを使うことのメリット[/caption] どうしてコンテナ技術を用いるとこれらの要求を解決することができるのでしょうか? それはコンテナ技術を用いることで、動かすべき対象つまりアプリケーションと、動かすための環境つまりインフラストラクチャーを明確に分けることができ、前者は同じコンテナ基盤であればどこでも同じように動かすことができ、後者はどんなプラットフォームでもこのコンテナ基盤を使えばどこでも同じ動作環境をアプリケーションに提供することができるからです。 別の見方をすると、従来型IT環境では機能要件と非機能要件を分けて考えることが時には困難な場合もありましたが、コンテナ環境ではこれらを明確に分けることができるわけです(図3参照)。 [caption id="attachment_90771" align="alignnone" width="600"] 図3. 従来型IT環境とコンテナ環境での考え方の違い[/caption]   Red Hat OpenShift について このようなコンテナですが、その方式はいくつか存在し、ここ数年いろいろな方々が実際に触っていくうちに自然と多くの人に使われるものが絞られてきました。 また、その周りを司る管理機能についてもやはり幾つかの方式からここに至ってある程度代表的なものに絞られてきました。いわゆるデファクトという呼び方をしたりするものですが、恐らく現在デファクトのコンテナ用オーケストレーターと言えるものは Kubernetes ではないでしょうか? この Kubernetes についての詳しい話はネット上にも沢山出てくると思いますので、ここではこれ以上触れません。 ちなみに最近はよくこの Kubernetes を "K8s" と書くことがあります。この K8s の "8" は Kubernetes の頭の "K" と最後の "s" に挟まれた "ubernete" の8文字を表しています。 Ruby 関連で i18n が internationalization を指すのと同じことです。そもそも IT の根本は如何にシステムを使って楽するかという怠け者の発想ですのでこんな略し方もわかる気がしますね。 (以下このブログでは、"Kubernetes" を "K8s" と表記します。) さて本題に戻ります。 K8s 環境は実際にちゃんと作ろうとすると、周辺機能を選びつつ構築していくことが必要となります。 またこれらは通常 OSS で組むこととなるため、ミッションクリティカルな環境への適用は、何かあった際のクイックなサポート等の面から非常に難しくなります。 Red Hat OpenShift は、K8s を中心に置き、必要な周辺モジュールを全てパッケージ化した上で評価を完了させてある商用パッケージです。 そのため、要らぬところに労力を割くことなく、正しい K8s環境を短時間で構築することができます。しかも、商用であるがゆえに保守等もちゃんと付いています。 [caption id="attachment_90872" align="alignnone" width="600"] 図4.OpenShift について[/caption] IBM はこの OpenShift をベースに各用途向けにコンテナ化された IBMソフトウェアを搭載し、パッケージ化した6つの IBM Cloud Pak というソリューションを提供しています。 (※詳しくは「製品・ソリューション/ソフトウェア」内で紹介されている、各種 IBM Cloud Pak をご参照ください。)   コンテナ環境下でのストレージのあり方 コンテナのメリットは先程ご説明しましたが、その中でも特にポータビリティという点は十分に考えられたソリューションです。 しかし、果たしてそれだけで十分でしょうか? アプリケーションの作りにもよりますが、普通にコンテナ内のストレージを使いアプリケーションを動かすと、コンテナが不要となり消し去った際データも一緒に消えてしまいます。 複数のコンテナを並列に動かすような作りの場合にはデータを連携する必要があるかもしれません。 [caption id="attachment_90873" align="alignnone" width="450"] 図5.永続ストレージの必要性[/caption] つまり、コンテナから独立したデータの器が必要となります。 これが永続ストレージというものです(図5参照)。 最近の IT の記述書などでよく "PV" という文字を見かけます。それは "Persistent Volume" の略であり、永続ストレージはその PV を使って定義づけられます。 では、永続ストレージにはどのような接続形態があるのでしょうか?   永続ストレージの接続形態 図6で示す通り、永続ストレージにはいくつかの形態があります。ちなみに一番左は通常のコンテナでのストレージのあり方で、この方法だとコンテナと共にデータは消えることとなります。 [caption id="attachment_90773" align="alignnone" width="600"] 図6. K8s 環境でのストレージのあり方[/caption] ノード内の永続ストレージという点では OpenShift においては Red Hat OpenShift Container Storage が使われます。こちらはノード依存性がありますので複数ノードにまたがって連携することはできません。 それに対し、外部にストレージを保つ方法があります。ソフトウェア・デファインド・ストレージかハードウェア製品かに関わらず、K8s ノード外にあるストレージを使うため、仮にノードごとに何らかの理由で停止するようなことがあってもデータはキープされます。 (※どのような製品が対応可能かは後ほど触れます。) これらの接続方法は、実は K8s のバージョンによって変わってきます。 ここでは K8s を包含した OpenShift のバージョンでお話しします。 [caption id="attachment_90774" align="alignnone" width="600"] 図7. OpenShift のバージョンによる接続方法の違い[/caption]   CSI CSI とは Container Storage Interface の略です。K8s のストレージはこうあるべきという考えに基づき、K8s とは独立にプロトコルを標準化したものです。 よって、CSI を使うことで K8s ユーザーはストレージのメーカーや製品を意識することなく同じに使うことができるようになります。逆に言うと各メーカーの優位性を出すことが難しくなります。 とは言え、IBMストレージとしては後述の通りハードウェア製品とソフトウェア・デファインド・ストレージ製品との連携でより便利に使うことが可能です。   IBM のストレージ対応 さて、ここまではどちらかと言うとコンテナ側のお話をしてきましたが、いよいよ IBM のストレージの対応についてお話していきましょう。   ブロックストレージ編 [caption id="attachment_90775" align="alignnone" width="600"] 図8. IBM のブロックストレージの CSI 対応状況[/caption] IBM FlashSystem は、IBMストレージのブロックストレージにあたります。 FlashSystem はいち早く CSI にも対応しています。 もちろん FlashSystem 同様 IBM Spectrum Virtualize ファミリーのアプライアンス製品 SAN Volume Controller も、ソフトウェア・デファインド・ストレージとしてクラウド上にポーティング済みの IBM Spectrum Virtualize for Public Cloud も、対応済みです。 オンプレミスとパブリック・クラウド間でのデータ連携も永続ストレージ間で実施できるため、コンテナ上のアプリのポータビリティをオンプレミスとパブリック・クラウドの間でデータも含めて実現することができます。 実際、図2で示したコンテナのメリットは、ちゃんと永続ストレージを使ってどのプラットフォーム上でもできないと完璧にこなすことはできません。これが IBM のコンテナ対応のバリューです。 当然のことながら、フラグシップであるところの DS8000シリーズも CSI 対応済みです。   ファイルストレージ編 次にファイルストレージについて見てみましょう。 [caption id="attachment_90776" align="alignnone" width="600"] 図9. IBM のファイルストレージの CSI 対応状況[/caption] IBMのファイルストレージと言えば、IBM Spectrum Scale というソフトウェア・デファインド・ストレージ製品ですが、アプライアンス製品として IBM Elastic Storage Server という製品があります。(第一回目のブログでもご紹介しましたね。) この ESS についても CSI 対応済みということになります。 こちらも IBM Spectrum Scale の機能を使ってプラットフォーム間でデータを連携することができます(Active File Management 機能は後日別の回での解説を予定しています)。 IBM Spectrum Scale を用いると、ある面白いこともできます。 これも詳しくは後日解説しますが、少しだけお話すると、IBM Spectrum Scale は NAS、オブジェクトストレージを含むマルチプロトコル対応です。CSI で静的プロビジョニングを用いてコンテナからアクセスできるようにすると、既存で NAS 等で使っているボリュームを見せることも可能となります。 さらに IBM Spectrum Scale は Unified Access という機能で同じファイルを NAS としてもオブジェクト・ストレージとしても共有できる機能があるため、コンテナでも同一ファイルを使うことが可能となり、実質的に従来型IT とコンテナとの間でもデータが連携できることになります。 従来型のシステムとコンテナのアプリ間でデータ連携できることのメリットは、まさに最初に述べた環境を用途などで使い分ける現在の IT環境には無くてはならない機能です。 これも IBMストレージの大きなメリットです。 ハードウェア製品、アプライアンス製品、ソフトウェア製品を通じてブロックストレージ、ファイルストレージ共に IBM はコンテナ対応済みであると言えます。   オブジェクト・ストレージ編 オブジェクト・ストレージは基本的に RESTful API による HTTP 接続が使われます。 よってコンテナに限ったことではありませんが、ブロックやファイルストレージとは異なり、独自ドライバや CSI を介する必要はなく、アプリケーションから直接 I/O することが可能です。 IBM は IBM Cloud Object Storage というソフトウェア・デファインド・ストレージを扱っています。 また IBM Spectrum Scale もオブジェクト・ストレージとして使用可能です。 オブジェクト・ストレージについては AI&Bigデータの回で詳しくお話することにしましょう。   ソフトウェア・デファインド・ストレージのもう一つの対応 [caption id="attachment_90777" align="alignnone" width="600"] 図10. IBM Storage Suite for IBM Cloud Paks[/caption] 現在取り扱っているコンテナ対応済みソフトウェア・デファインド・ストレージを取りまとめて、IBM Storage Suite for IBM Cloud Paks という名前で IBM Cloud Paks 向けに提供を始めました。 ここには IBM の前述のソフトウェア・デファインド・ストレージ製品3つと、メタデータ、タグマネージメントといった機能を持った IBM Spectrum Discover、それに Red Hat OpenShift でネイティブなRed Hat OpenShift Container Storage と根強いファンの多い Red Hat Ceph Storage を加えた6つをワンパッケージにしました。 この Suite 製品の面白いところは、OCS(Red Hat OpenShift Container Storage)の契約 VPC数(契約対象の仮想プロセッサコア数)に応じた容量分を自由に何種類でも組合わせて使うことができるというところです(もちろん単体で全容量使うのもありです)。 この手のコンテナ環境・クラウド環境でストレージを使うことは、はじめは何をどのくらい使うべきかわかっていない状況だったりするものです。特にアジャイル、アジャイルと言われる昨今、「とにかくやってみよう」という傾向が強いのも事実です。 そんな時にこのパッケージを使うと、容量を超えない限りどのストレージをいくら使っても自由ですので、使ってみて決めていくということができます。 まさに現在のクラウド時代にふさわしいストレージパッケージと言えるでしょう。   今回のまとめ ここまで見てきた通り、IBM のストレージ製品は2020年7月現在取り扱っているものとしてはブロック、ファイル、オブジェクト・ストレージであり、これらすべてコンテナ対応が完了しています。 [caption id="attachment_90778" align="alignnone" width="600"] 図11. IBMストレージの OpenShift 対応状況[/caption] Red Hat OpenShift あるいは各種 IBM Cloud Pak においては、接続性も含めて検証済みであり安全にお使いいただけます。 もしコンテナ環境をご検討中であれば、ハードウェアもクラウド上のソフトウェア・デファインド・ストレージもあり上下のデータ連携が可能な IBM のストレージ製品を、ぜひご活用ください!   お読みいただきまして、ありがとうございます。 次回はハイブリッド・クラウド、マルチ・クラウドに適切なストレージについてお話する予定です。お楽しみに!     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考ページ IBMストレージ製品 全包囲網。。。最新 IBMストレージ 概要 ハイブリッド/マルチクラウド時代だからこそIBMのストレージ 最新のデータライフサイクル管理とは?(前編)、最新のデータライフサイクル管理とは?(後編) AI導入はどこまで現実的? 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している

2020年06月05日

全包囲網。。。最新 IBMストレージ 概要

こんにちは、IBM でストレージ・ソリューション・セールスのパートナー様向け技術支援を担当している岡田です。 今回は IBM の最新情報を交えつつ、IBM のストレージ製品の概要をご紹介させていただき、次回以降でその詳細に触れていきたいと思います。   はじめに 皆さんはどのくらい IBM のストレージ製品にご興味がおありでしょうか? 興味のあるなしに関わらず、多くの方は知らず知らずのうちに IBM や他のメーカー のストレージ上に様々なデータを書き込んでいることでしょう。ストレージの使用は、あえてデータを保管しようとせずとも無意識に行なっているものです。   例えば… 例えば、コンサートやイベントのチケットなどのケース。 発売当日は予想を超えるアクセス数がありますね。昔ならサーバーを増強してサーバーがパンクしないように対策し、それでもなおかつ処理能力を超えてしまいダウンしてしまったなどという話を聞いたことがあると思います。 しかし今では、クラウド上で一時的に仮想サーバーを増やして難なく対応するというように、時代とともにやり方は変化してきています。 でもその時データを貯めるストレージはどう扱うのでしょう? オンプレミスでもクラウドでも連携してハイブリッド・クラウド環境でデータをきちんと管理できるのが IBM のストレージです。 また、景品やポイント目当てで今日もスマホからアンケートに答えている方も多いことでしょう。 そのデータは、しばらくは価値のあるデータとして集計やいろんな解析に回されたりするかもしれません。少し時間が経過してもアンケートのコメント欄に書かれた内容を閲覧する人もまだちらほらといるかもしれません。 でもいずれは旬を過ぎたデータとしてどこかに保存だけされ、そのうち不要なデータとして削除しなければならなくなる。 これが、まさにデータのライフサイクルです。 しかし、実際はこのようなデータを正しく管理するのは非常に手間がかかります。場合によってはどこかでミスを起こし、まさかのデータ流出なんてことになりかねません。 データの「揺り籠から墓場まで」を実際にきちんと自動管理できるのが IBM のストレージです。 そして、さらに考えてみてください。そのデータはどうやって守られているのかを。 「守られている」というのには幾通りかの解釈があります。盗まれない・改ざんされないように守るセキュリティ、無くならないように守る信頼性、壊れないように守るインテグリティ、セキュアな移動に耐えうるポータビリティなど、これら「守る」をきちんと管理できる機能があるのも IBM のストレージです。 では、それらを実現する IBM のストレージの概要をみていきましょう。   IBMストレージ製品の紹介 IBM は現在、あらゆるお客様の規模・業種あるいはユースケースなどに対応するためにストレージ製品群を以下の4つのカテゴリーに分けて考えております。 図1. IBMストレージ製品カテゴリー これらのカテゴリーにはハードウェア製品のみならず、IBM Spectrum Storage ファミリーというソフトウェア・デファインド・ストレージ製品もマッピングされています。 IBM はいち早くソフトウェア・デファインド・ストレージに取り組み、今やストレージのみならず、バックアップ、マネージメントと幅広いカバレージで展開しております。 それでは一つ一つ見ていきましょう。   Hybrid Multi Cloud Storage ハイブリッド・マルチクラウド・ストレージに属するものとして、FlashSystem という FlashCore Module(以下 FCM)や SSD などの半導体メモリー系記憶デバイスを活用したストレージ製品群があります。 いわゆるオープン系と呼ばれていた分野は仮想化という過程を経てクラウド時代へ突入しており、コンテナ時代も本格化の兆しを呈しております。この分野で扱うのに適しているストレージ群という位置付けです。 IBM FlashSystem 9200 このラインアップはエントリークラスからハイエンド製品まで、お客様の規模等に合わせた製品を選択でき、なおかつ統一された操作性を実現する製品です。 またこれら FlashSystem の制御機能を外出しした IBM Spectrum Virtualize のパブリック・クラウド版と連携することで、オンプレミスや他のクラウド環境との容易なデータ連携を実現します。 (※詳細は第三回のブログで明らかにします。) 同じカテゴリーに位置する IBM Storage Insights は SaaS として提供される統合ストレージ管理サービスです。 複数の IBM ストレージを一括管理できるだけでなく、他のメーカー様のストレージも管理対象としています。世界中で培われた数多くの知見と AI により提供されるアドバイザリー機能は、ストレージの障害発生率の劇的削減につながります。   AI & Big Data Web Scale という言葉で代表される分野です。 特徴としては IoT のデータのように無限に増えていくデータに対応しうる拡張性、分散保管系、そして広いエリアでファイルやオブジェクトを一意的に扱えるグローバル・ネーム・スペースといったところが挙げられます。 製品で言うと IBM Cloud Object Storage や Elastic Storage System(ひとつ前のモデルまでは Elastic Storage Server と呼んでいました)がこれにあたります。 IBM Cloud Object Storage はオブジェクト・ストレージ機能に特化しており、ペタバイト級のデータを、高信頼性・高可用性・高安全性を保ちつつ扱うことができる分散保管型のストレージで、拡張性にも優れた製品です。業界ではデファクトとなっているオブジェクト・ストレージの AWS(Amazon Web Services)の S3 に準拠した API により、多くのサードパーティーのゲートウェイ・ソフト製品にも対応しております。 IBM Cloud Object Storage はアプラアンス製品としてハードとともに提供しておりますが、評価済みの汎用サーバーをお持ちであればソフトウェアのみでの提供も可能です。また IBM Cloud 上では IaaS としての IBM Cloud Object Storage が月額で使用可能です。 Elastic Storage System は IBM Spectrum Storage 製品のうち IBM Spectrum Scale という分散型ファイル・システムのアプライアンス製品です。GPFS(General Parallel File System)という Power 製品の分野で培った高度なファイル・システムをベースとしており、自動階層化機能、マルチプロトコル対応、拡張性といった特徴のみならず、分散ノードの並列度を上げることで高パフォーマンスな用途にも対応できます。 今日時点最新である2019年11月18日発表のスーパーコンピュータ性能ランキング「TOP 500」で、1位2位を独占する Summit という IBM のスーパーコンピュータにも搭載されている優れものです。 (※次回以降、階層化機能を中心に明らかにします。) また AI や BigData を扱うエリアでは、膨大なデータにおけるカテゴライズや検索といったことが重要になってきます。 通常はシステムにより自動付加される情報に頼ることが多いですが、メタデータ、タグ情報といったもので効率的にデータを扱える仕組みがあります。このメタデータやタグ情報を管理できるのが IBM Spectrum Discover で、上記2つの製品群と一緒に使われることでデータにより一層の価値を持たせることが可能となります。   Modern Data Protection 一番わかりやすいのがモダン・データ・プロテクションのエリア。災害や障害に耐えうるバックアップやディザスター・リカバリーに特化した製品群です。 いかに短い時間で効率的にバックアップを取得するかということは当然のことながら、いかにロス無く早くシステムを復旧できるかということが重要になってきます。 また、以前より障害やヒューマンエラー、災害対策、争乱と対象が発展し、今やサイバー攻撃にも対応する必要が出てきました。 さらに守るべき対象もオンプレミスだけではなく有機的にクラウドと結びついている場合もあり、これらに対応していくということが、まさにモダン・データ・プロテクションたる所以であります。 ここでの中心となるのはテープ製品群です。 現在の企業向けテープ規格のスタンダードと言えば LTO(Leaner Tape-Open)を思い浮かべる方が多いと思いますが、IBM は規格立案時代より中心的に関わっており、LTO および企業向けに発展させた 3592エンタープライズ向けテープ(IBM 独自フォーマット)の2本立てのテープカートリッジ規格に対応した製品群を扱っております。 IBM TS4500 Tape Library 同じカテゴリーの IBM Spectrum Storage ファミリー製品としては、IBM Spectrum Protect というバックアップ・ソリューション・ソフトウェアがあります。 これは Tivoli Storage Manger というバックアップ・ソフトを Spectrum ファミリーに統合したもので、長い歴史と実績を持っています。完全なる永久増分バックアップ機能と各種データ圧縮機能を用いることでバックアップ容量およびバックアップ時間を格段に削減することが可能です。 仮想サーバー環境に特化した IBM Spectrum Protect Plus という製品もあり、すでにいくつかのパブリック・クラウド上での月額使用も可能となっております。 昨今、テープ装置は物理的にシステムから切り離すことができるストレージとして、「エアー・ギャップ」という言葉のもと、サイバー攻撃にも耐えうるソリューションとして見直されつつあります。 (※詳細は第五回のブログで明らかにします。)   Storage for Z IBM のフラグシップとも言えるメインフレーム製品にも対応するハイエンド・ストレージ機器群となります。 技術の結晶とも言われるこの分野の製品は信頼性・可用性共に高いレベルにあり、過去から現在に至るまで世界中の経済を支えてきたと言っても過言ではありません。 DS8000 シリーズはホスト製品のみならず、オープン系の分野も含め 2000年代初頭から現在までの長い間、高可用性・高性能の分野で一役を担ってきました。 遠隔のストレージ同士をミラーリングするという考えは、もともとホスト系ストレージ・システムで行なっていた PPRC、XRC と呼ばれるミラーリングに始まり、現在の Metro Mirror、Global Mirror といった同期・非同期のミラーリングに受け継がれているもので、今ではエントリー製品にもあたりまえのように使われる技術となっています。 IBM DS8900F DS8000 シリーズは今でも進化しており、最新ラインアップ DS8900F シリーズではオール・フラッシュ製品に変化を遂げ、超低遅延・高可用性の他、クラウドとの連携やマルウェア・ランサムウェア対策など最新の技術を投入され、今後のIT環境にも活用いただけるフラグシップ製品です。   図2. IBMストレージ製品ポートフォリオ まだまだ説明したい製品がありますが、別の機会にご説明させていただきたいと思います。   おわりに 今後も、以下のようなテーマでブログを掲載させていただく予定ですのでお楽しみに! (もしかしたら突発的な話題や多少の変更はあるかもしれませんがご了承ください。) 第二弾:「OpenShiftに代表されるコンテナ環境へのIBMストレージの対応」 第三弾:「ハイブリッド/マルチクラウド時代だからこそIBMのストレージ」 第四弾:「最新のデータライフサイクル管理とは?(前編)」「最新のデータライフサイクル管理とは?(後編)」 第五弾:「データを守ることについて」 このブログで少しでも IBM のストレージ製品にご興味を抱いていただけると幸いです。     この記事に関するお問合せ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは、「こちら」からお願いします。   参考ページ IBMストレージ製品 OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 ハイブリッド/マルチクラウド時代だからこそIBMのストレージ 最新のデータライフサイクル管理とは?(前編)、最新のデータライフサイクル管理とは?(後編) AI導入はどこまで現実的? 5大ハードルとその解決策を解説 普及が進む、機械学習による異常検知。導入の課題はここまで解決している

2020年05月21日

全ての企業が AI カンパニーになる!「IBM THINK Digital 2020」に参加した

こんにちは。てくさぽBLOGメンバー 山田です。 2018年はラスベガス、2019年はサンフランシスコと、アメリカの主要都市で開催されていた「IBM THINK」ですが、2020年は COVID-19 の影響でデジタル開催となりました。 エンターテイメント的な高揚感や全世界から集まる参加者の熱気を体感できなかったものの、機械翻訳による日本語字幕やアジア地域の時間帯に合わせた配信などの新しい試みも随所にあり、2年連続して参加した私も今回は自宅から参加することになりました。 デジタル配信とはいえ9万人もの事前登録があり、現在もオンデマンドで100以上ものセッションが視聴可能です。 THINK2020 オンデマンドはこちら。(※IBM ID が必要となります) IBM サイト:「Think Digital Event Experience -On Demand Sessions-」   ハイブリッド・クラウド、AI、5G が DX を牽引する 4月に新たに CEO となったアービンド・クリシュナ氏は、以下のように語りました。 "ハイブリッド・クラウド、AI そして 5G といったテクノロジーが企業のデジタル変革を牽引し、このパンデミックな状況が重要な転換期となって適応スピードがさらに加速する。" クリシュナ氏の講演では、ハイブリッド・クラウドと AI が実現する新しいソリューションとして以下の3つの発表がありました。 IBM Watson AIOps エッジ・コンピューティング 金融サービス向け ISV提携 エッジ・コンピューティングについては後程ご紹介しますが、5G の活用や金融サービスの ISV提携など、この数年の発表としてはインダストリー色が少し強くなった印象があります。 IBM Watson AIOps は、2019年の Think で紹介されたテクノロジーやコンセプトが具現化された製品のように思えました。 2019年のThinkでは AI 関連のセッションは省力化についてフォーカスされたものが多く、Watson を手組で取り入れながら個別のプロジェクトで対応する、または PoC での評価段階だったように感じていたためです。 今年の THINK では、効率化に加えて "スピードと自動化" の重要性がより前面に出ていたように感じました。 COVID-19 発生のような、予測や分析が難しく人々が自由に動けなくなってしまうような事態であっても、事業は継続しなくてはなりません。そのためには業務プロセス全体の効率化を考えるとともに、AI による運用自動化のような取り組みが必要ということでしょう。 今回発表された IBM Watson AIOps  は、まさに AI を IT インフラのオペレーションに組み込んだソリューションです。既存の IT 運用ツールを置き換えるものではなく、それらをデータソースとして AI が働き、異変を検出、対処方法の診断・自動化が可能となります。 図1:IBM Watson AIOpsの概念 エンタープライズの世界では企業 IT の世界では予期しない IT ダウンタイムの発生によって、年間約2.8兆円規模の損失が発生していると言われています。予兆検知により早期にトラブルを予測できれば大きなアドバンテージとなりますし、IT オペレーションの自動化を促進することで、IT 人材不足の課題にも対応できます。 また、ユーザーインタフェースに Slack を採用することで "ChatOps" が実現され、同時に他システムとのプロセス連携/自動化のための API も提供されるなど、まさに "オペレータをスーパーマンにする" ソリューションと言えます。 図2のように、インシデントや緊急停止の件数、顧客のロイヤリティ(NPS:Net Promoter Score)や従業員の満足度といった CIO の指標を改善することで、CIO を支援するソリューションであることも強調していました。 図2:セッション "Keeping IT Costs Down While Still Delivering Impact" より抜粋 当製品は OpenShift ベースの IBM Cloud Pak for Data 上に構築されているため、ハイブリッド・クラウド環境のどこにでも展開でき、日本では2020年内に提供開始予定です。   エッジ・コンピューティングへの拡がり "一度作ったアプリケーションがどこでも動かせるというオープン性の価値と、それを実現する統合プラットフォームの IBM Cloud Paks、そして統合プラットーフォームの中心に RHEL と OpenShift がある。" これは、クリシュナ氏とともに4月に新社長に就任した 元 Red Hat 社 CEO のジム・ホワイトハースト氏のメッセージです。 またエッジ・コンピューティングについては、工場や空港などの現場(=エッジ)で生まれるワークロードに対してもデータや AI の取り組みが必要であり、コンテナベースでアプリケーションが構築されるようになると述べられました。 5G のテクノロジーと組み合わせて、ポリシーを使ったコンテナ・アプリケーションの自動配布やライフサイクルの自律的な管理を可能にするユニークなソリューション「IBM Edge Application Manager」の発表がありました。 図3:IBM Edge Application Manager 4.1 architecture   欠かせないパートナー様とのエコシステム 従来は IBM ビジネス・パートナーのエグゼクティブしか参加できなかった PW at Think も、今回はデジタル配信ということで視聴することができました。 興味深かったのは、パートナー様の収益の 58% は⾃社の知的財産から生じていることや、マネージドサービスに対するお客様の需要は伸びており、2019年にクラウドサービスの再販が 17% 以上増加した、という IDC データの紹介でした。 そういった分析結果を踏まえ、構築(Build)、サービス提供(Service)、販売(Sell)といったパートナー様のビジネス・モデルに合わせた支援サービスが発表されており、常に IBM が、顧客の多様化したニーズに応えるにはビジネス・パートナー様とのエコシステムが必須であるとメッセージし、エコシステムのための施策もしっかり打ち出していると改めて感じました。 図4:セッション "IBM Partner Ecosystem: The Power of Ecosystem" より抜粋   さいごに ほんの数年前にはあこがれのような存在だった AI が、「Watson Anywhere:どこでもWatsonが使える」、そして「全ての企業が AI カンパニーになる。それは必然だ。」と、更に身近で、かつ避けられない存在になったことを実感したイベントでした。 来年の THINK でどんな新しいメッセージが聞けるのか、今から楽しみです。

2020年05月12日

クラウド環境へのOSの持ち込みって出来るの?

こんにちは。 てくさぽBLOGメンバーの瓜谷です。 最近、クラウド上のソフトウェアのライセンス購入に関して 「自社で購入して持ち込んでいいの?」 「オンプレミス環境と同じ種類のライセンスでいいの? 」 「いくつ購入すればいいの? 」 といったお問い合わせが増えてきています。 そこで、よくお問い合わせいただくIBM Cloud ベアメタルへのWindows ServerとRed Hat Enterprise LinuxのOSの持ち込みライセンスの考え方についてご説明したいと思います。 IBM Cloud ベアメタル環境への持ち込み可否 「IBM Cloud ベアメタル環境へOSのライセンスを持ち込めるの?」に関して、結論から申しますと “Yes” です。 ただし、持ち込むOSによっては、オンプレミスで使用しているエディションが使用できない場合があります。 では最初に、IBM Cloud ベアメタルで使用できるOSのエディションの種類を説明します。 Windows Serverのエディションには、下記の2つがあります。 Windows Server DataCenter Core 2ライセンス ⇒"持ち込み可" Windows Server Standard Core 2ライセンス     ⇒"持ち込み可" この2つのエディションに関しましては、両方ともIBM Cloud ベアメタルへ持ち込むことが出来ます。 Windows Serverの場合には、エディションの種類を考慮しなくてもよいことなります。 それでは、次にRed Hat Enterprise Linuxを見ていきましょう。 Red Hat Enterprise Linuxのエディションには、下記の2つあります。 Red Hat Enterprise Linux Server                                   ⇒"持ち込み可" Red Hat Enterprise Linux for Virtual Datacenters   ⇒"持ち込み不可" 残念ながらRed Hat Enterprise Linux for Virtual Datacenters(ゲストOS無制限)は、IBM Cloud ベアメタルへの持ち込みはできません。 Red Hat Enterprise Linuxの場合には、オンプレミスとクラウドでライセンスポリシーが違うので注意が必要です。 IBM Cloud ベアメタルへの持ち込み可能なOSのエディションの種類がわかったところで、次に「IBM Cloud ベアメタルへ持ち込むOSライセンスの考え方」を説明します。 IBM Cloud ベアメタルへ持ち込むOSライセンスの考え方 Windows Server とRed Hat Enterprise Linux Server は、IBM Cloud へ持ち込む場合でもオンプレミス環境と同じカウント方法になります。 【Windows Server を仮想OS上で使用する場合】 Windows Server のライセンスは、仮想OSが搭載されているサーバのCPUのソケット数とコア数やゲストOS数によってライセンスの数量が変わってきます。 ここでは、一番問い合わせが多い2CPU以下のサーバを例にとって説明します。 ■Windows Server DataCenter Core 2ライセンスの場合 このライセンスは、サーバにゲストOSを無制限に搭載することができます。 そして、ライセンスの数量を考えるには、2つのルールがあります。 2コアで1ライセンスとして算出します。 1.サーバのCPUの合計コア数が16コア以上の場合には、合計コア数必要 2.サーバのCPUの合計コア数が16コア未満の場合、16コアとして計算 上記1、2の説明に対する図を、下の図1に示しています(説明1は左側の図、説明2は右側の図です) ■Windows Server Standard Core 2ライセンスの場合 このライセンスは、サーバのCPUの合計コア数とゲストOS数によってライセンス数が変わってきます。 サーバのCPUの合計コア数分のライセンスで、ゲストOS2つまで使用できますが それ以上使用する場合には、サーバのCPUの合計コア数分のライセンスを加算することでさらにゲストOS2つ追加して使用することができます。 2コアで1ライセンスとして算出します。 ライセンスの数量の考え方の例を3つにまとめます。 1.サーバのCPUの合計コア数が16コア以上の場合には、合計コア数でゲストOSを2つまで使用可能 2.サーバのCPUの合計コア数が16コア未満の場合、16コアとしてゲストOSを2つまで使用可能 上記の1と2を式にて表現してみると次のようになります。 変数α  =  サーバのCPUの合計コア数(但し、16コア未満の場合には16コアとして計算します) 変数β  = ゲストOS数(但し、ゲストOS数が奇数の場合には+1にして偶数にします) ライセンス数 = 変数α ÷ 2(2コアライセンスのため) × 変数β ÷ 2(2ゲストOS毎のため) 3.サーバ毎に、最大ゲストOSを数えて計算(待機系であっても課金対象) 上記1、2、3の説明に対する図を、下の図2に示しています(説明1は左側の図、説明2は真ん中の図、説明3は右側の図です) 【Red Hat Enterprise Linux Serverを仮想OS上で使用する場合】 Red Hat Enterprise Linux Server は、仮想OSが搭載されているサーバのCPUのソケット数とコア数は関係なく、搭載するゲストOSの数量によってサブスクリプション数が決定されます。 ■Red Hat Enterprise Linux Serverの場合 ライセンスの数量を考えるには、3つのルールがあります。 1.サブスクリプション毎に、2ゲストまで使用可能 2.稼動するRed Hat Enterprise Linux Server のOSの数量の合計で課金 3.同時稼動するRed Hat Enterprise Linux Server OSの最大数で課金 上記1、2、3の説明に対する図を、下の図3に示しています(説明1は左側の図、説明2は真ん中の図、説明3は右側の図です) 最後に 皆様、 IBM Cloud ベアメタルへのWindows ServerとRed Hat Enterprise LinuxのOSの持ち込みライセンスの考え方は、ご理解いただけましたでしょうか? 「意外と簡単だった!」 「理解できたけど、数を数えるの間違えちゃいそう!」 人それぞれ感想が異なるかと思います。 ここで注意してほしいのは、クラウド業者やOSのメーカーによって、持ち込みの可否や購入する際のルールや考え方等は異なるということです。 また、バージョンが変わることでライセンスのポリシーが変更になることもありますので、その都度確認が必要です。 常にライセンス見積に携わっていない方は「調べるのが大変!面倒!」と思われるかもしれませんが、そんな時はNI+C Pに是非ご相談ください。 また、クラウドに関わらず、●●●のライセンスの考え方を掲載してほしい等のご要望等ありましたらご連絡ください。要望が多いものから掲載していきたいと思います。 この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp 商標帰属 すべての名称ならびに商標は、それぞれの企業の商標または登録商標です。 ※上記の記載は、2020/5/11現在の内容となります。

2020年04月10日

【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして予想する (その1)

皆さま、こんにちは。 てくさぽBLOG メンバーの佐藤です。 前回「【やってみた】超簡単データ分析!H2O Driverless AI を使ってみた」にて、H2O DriverlessAI (以降DriverlessAI) のご紹介をしました。 今回は、DriverlessAI の第二弾として競馬の予測 (回帰分析) に挑戦しました。 *連載の続きはこちら(2020年7月13日公開) 「【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして予想する (その2)」   背景 AIは社会的に非常に注目されています。 AIを利用するためにはデータを元に学習させて、学習モデルを元に予測精度がどの程度なのかをテストすることになります。 サンプルデータはGit等たくさんあるので、学習と”予測できた”という結果は確認できます。 予測結果が実用性があるレベルなのか?何か具体的なデータで予測と実際の結果と照らし合わせて検証してみたいと考えました。 尚、弊社ではDriverlessAI PoC環境として、IBM Power System AC922 がありますので今回はこちらの環境を利用して、テストしてみたいと思います。 こちらのブログを読んでぜひ試してみたいという方は以下リンク先よりお申込みください。(要会員登録) IBM AIソリューション PoC環境ご利用ガイド   今回の目的 回帰分析(データに基づいた予測)の機能を備えるDriverlessAIを使って、予測が有用かどうか検証します。 何を予測するか 予測に適したデータは何か?を探したところ競馬についてはかなりしっかりしたデータが公開されておりかつ実際に順位という結果が出るため、テスト対象に向いていることがわかりました。 AIの検証ネタとしても複数の方が挑戦されていますし、過去に競馬AIコンテストも開かれたようです。 データを探す まず、予測に用いるための競馬データについて調査しました。 競馬のデータについて配信を行っているのは主に3つあります。 1.JRA-VAN DataLab. JRA公式のデータ 30年分のデータがある為、データ量は一番豊富 2.netkeiba.com 競馬ファンのための情報サイト 人が使うためのコンテンツが多く、動画配信等も充実 まとまったデータでの配布はない模様で、今回の用途には向いていない。 3.JRDB 基本的に競馬に関するデータを提供しているサイト 調教データ等、データの種類は一番豊富 詳細は割愛しますが、JRA-VANはデータの変換に手間がかかるため、JRDBを使用することにしました。 手順 DriverlessAIで回帰分析をするには5つのSTEPがあります。 十分な結果が得られれば1回で終わりますし、もう少し精度が必要の場合は再び1に戻ります。 順を追って説明します。 1.データの準備 2.回帰分析 3.予測 4.検証 5.考察(考察結果をもとに必要であれば1へ) 1.データの準備 DriverlessAIが受付られるデータはテキストデータになります。 データの受け渡しについてはクラウド連携が可能です。 詳細は以下のURLを確認ください。 https://dai-doc-jp.au-syd.mybluemix.net/datasets.html#supported-file-types DriverlessAIとして受付られるテキストファイルは複数ありますが、今回はCSVファイルを準備することにします。 アップロードについても一番簡単なローカルからのドラッグアンドドロップで行います。 JRDBはlzhファイル形式で配布されていますが、T#というツールを使うとCSVに吐き出してくれますのでこちらを利用します。 T#は日付毎にCSVファイル出力されますので連結して解析するデータを作成します。 CSVの連結についてはコマンドプロンプトでtypeコマンドを利用しました。 今回は2010年1月5 日~2020年1月5日までのデータを連結して分析元のデータとします。 抽出するデータの項目ですが、私自身競馬に詳しくないこともあり項目については何が有効なデータか不明ですので集められるだけ集めました。 データとしては99列、50万行の規模です。 CSVファイルで340MB程あります。 データ自体はこのような感じです。 DriverlessAIのメリット 回帰分析するデータについてDriverlessAIのメリットを挙げておきます。 関係ないデータを回帰分析にかけても大丈夫 予測したいデータに関係ないデータは自動的に解析の対象から外します。 DriverlessAIの場合、予測に有用なデータかそうでないかを選別する必要はありません。 とにかくよくわからなくても入れておけば大丈夫です。 データに歯抜けがあっても大丈夫 DriverlessAIはデータがすべてそろってなくても実行することができます。 ただし歯抜けがあまりにも多いと自動的に除外されます。 自動で判断してくれますので手作業は不要です。 データの型を指定しなくて大丈夫 一般的にデータを読み込ませるという事をする場合は文字列なのか、整数なのか、日付なのか、データの型を指定する作業が必要になるケースが多いです。 DriverlessAIはデータの型を自動判別してくれますので、型指定する必要はありません。 また、手動での指定も対応しています。 項目が自動認識となっています。 データの注意点 解析元データの注意点を上げます。 予測は1項目のみ DriverlessAIの予測は一度に1列、1項目のみとなります。 複数項目を同時に予測はできません。 予測以外のデータは埋まっている必要がある 予測をする場合は予測項目以外の列は基本的に埋まっている必要があります。 今回のケースの場合、分析元データにレースをしないとわからないデータ、レース走行タイム系は含めることができません。 レース前に判明する調教時のタイムは使うことができます。 文字コードはUTF-8のみ DriverlessAIは文字コードがUTF-8でないと文字化けします。 JRDBの配布データはS-JISのため、テキストエディタやエクセルを使用してUTF-8で保存しなおす必要があります。 S-JISだとこのように文字化けしてしまいます。   2.回帰分析 DriverlessAIにログインし、データのアップロードが済んだら、回帰分析をします。 DriverlessAIのパラメーターですが、自動的にスコアラーがRMSE選択されますが今回はMAEに変更します。 スコアラーは評価指標と呼ばれるもので、どういう指標で回帰分析してほしいか?で選択をします。 例としてRMSEとMAEの違いを挙げます。 数式や細かい説明については、いろいろなサイトで詳細な解説があるので、今回はかなり簡単に説明します。 MAE MAEは単純な当たりはずれ精度になります。 比較的精度がでます。 一方はずれ度合いについては評価しないため、当たりはずれの落差が激しい傾向が出ます。   RMSE RMSEは当たり、外れの差分をできる限り減らす評価となります。 単純な当たりはずれの精度だけでなく、外れた場合の外れ度合いも評価します。 例えば売り上げ予測といった数値予測の場合、精度が80%であっても、売り上げが100と予測したのに実際は1だった という大きな外れが発生しては困るといった場合に利用します。 当たりはずれの幅が少ない評価となります。 傾向としてMAEより精度が落ちます。 RMSEは データと結果の相関が強いデータでないと精度が出ないため、今回は予測する値がよりはっきりしやすいMAEに設定します。 どちらが正解という事もないため、このブログを参考に試される方は両方試して比較されるのもよいかと思います。 MAEを選択した状態 回帰分析をしてみてDiriverlessAIについて印象的なポイントをあげます。 全自動 とにかく全自動で解析してくれることです。 何もしなくてもとりあえずとにかくやってくれるというのが非常にメリットです。 傾向分析 傾向分析なんてエクセルでもできるじゃないかと思われる方もいらっしゃると思います。 DriverlessAIのなにがすごいか? 99列の中から相関関係がある列を自動的に抽出し、相関のないデータは除外します。 次に、x列がy%の影響度があるという、具体的な数値で相関を出してくれます。 さらには、x列のデータのうち、外れ値を除く数値の範囲だけ相関があるといった一部だけ抜き出して有用といったものも判断してくれたり、それら複数を組み合わせたりして予測したい値に対する相関を様々な組み合わせやアプローチで試してしてくれます。 同じことをエクセルでやってみることを想像してみてください。 負荷が高い 自動で処理してくれるかわりに、非常にCPU負荷が高いです。 データ量にもよりますが、高い負荷が長時間続きます。 負荷状況を見ますと、DriverlessAIはGPUも利用しますが、基本はCPUでの処理となりますので、優先度としてはまずはとにかく高速なCPU、次にGPUとなります。 今回、PCやクラウド環境とも比較しましたが結果はどの環境でも出ますが、処理能力が少ないと完了までの時間がとてもかかりますので、やはり運用するのであれば専用機が1台欲しいところです。 今回テストする環境のスペック 8335-GTH Power9 40Core 2.4GHz~3.0GHz 160スレッド メモリ1024GB NVIDIA V100 16GB ×2 960GB SSD ×2(RAID1) というシステム構成となっております。 x86CPU(Intel/AMD)は1Coreあたり2スレッドになりますが IBM Powerの優れたポイントとして、1Core当たりのスレッド数が”4”となります。 やみくもに増やしているわけではなく、1Coreあたりのパフォーマンスが高いため実現しているテクノロジーとなります。 160Core(!)の画面ショット(DriverlessAIはスレッド数=Core数と認識) 今回のデータの場合、テスト環境ではパラメーターをデフォルト設定で約50分で終了します。 完了するとこのような画面になります。 これで予測の準備が整いました。   長くなりましたので、次回、予測をして内容について検証します。

2020年03月04日

【やってみた】IBM CloudでAI(機械学習)を体験してみた

こんにちは。 てくさぽ BLOG メンバーの高村です。 いきなりですが、AIと聞いてどのようなイメージをお持ちでしょうか? "人間と同じ様に意識や思考を持ったロボット"や"質問に対して答えてくれる製品”など、様々に思いつかれるのではないでしょうか。 AIの定義は定まっておりませんが、最近は大きく2つに分けることができると言われています。 1つ目は「強いAI 」と言われ、前述に挙げた人間と同じ意識や思考をもつ人工知能です。現在のAI製品はこの「強いAI」に まだ至っていないと言われています。 2つ目は「弱いAI」です。「強いAI」に対して意識や思考を持たず、人間の知能の一部に特化した機能を実現します。視覚による画像処理や質問に対する回答、分類が該当します。昨年11月に掲載された「てくさぽブログ【やってみた】H2O Driverless AIを使ってみた」のH2O Driverless AIは「弱いAI」になります。 今回のブログはこの「弱いAI」に分類される、機械学習(Machine Learning)をIBM Cloud上でデモを体験しましたのでリポートしたいと思います。 機械学習 -Machine Learning- AIの話をしていると"ML"や"DL"という単語を耳にします。"ML"とはMachine Learningの略(以下ML)、”DL"はDeep Learningの略(以下DL)になります。どちらも冒頭で説明した「弱いAI」に分類されますが、簡単に説明します。 MLとは沢山のデータを基にアルゴリズムを使用してパターンや特徴を見つけ予測を行います。図1の様に、分析するデータの状況によってMLは大きく「教師あり学習」「教師なし学習」「強化学習」の3種に分けられます。 図1:機械学習の分類 (出典:クラウドオンライン道場資料 Cloud Online dojo_WatsonStudio_20191209.pdf  P12) 「教師あり学習」「教師なし学習」は統計学に基づいた「統計的機械学習」が一般的です。よって回帰分析、分類分析、クラスター分析など統計の知識が必要になります。一方「強化学習」は入力されたデータから何らか行動し、それに対して報酬(評価)が与えられ試行錯誤し、より良い行動の選択をしていく学習方法になります。(参考資料:総務省 ICTスキル総合習得教材 [コース3]データ分析 3-5:人工知能と機械学習) これから行うMLデモはIBM Cloud Watson Studioの機能の一つ「機械学習用GUI ツール(以下Auto AI)」を使用します。Auto AIは「教師あり学習」になり、「回帰」「分類」をプログラミング無しで実行することができます。 一方DLはMLと別のものと思われがちですが、MLで使用するアルゴリズムの1つを指します。人間の脳神経の仕組みを応用して作られたアルゴリズムにより非構造化データ(画像やスピーチなど)を処理するようコンピューターを訓練します。製品化の例を挙げると、公共施設での顔認証システムなどがDLを応用したシステムとなっています。図2はAI,ML,DLの関係を表したものです。DLはMLの一部であることがわかります。 図2:AI,ML,DLの関係図 IBM CloudでMLデモを体験してみた  1.MLデモの概要 IBM Cloud Watson StudioのAuto AIを使用してデモを行います。Auto AIはデータの前処理、機械学習モデル(以下Auto AIモデル)の選定、特徴量の最適化などを自動的に行うことができます。 今回のデモは図3の流れで行います。まずWatson Studioでプロジェクト、サービスを作成します。次にcsvファイルのデータをアップロードします。サービスを実行するとAuto AIが自動でAuto AIモデルを作成します。最後に作成されたモデルをデプロイし、テストを行います。 図3:MLデモの流れ 2.IBM Cloudのアカウント取得 今回のデモはIBM Cloudのライトアカウント(無料)で行うことができます。まずライトアカウントを取得しましょう。ライトアカウントならクレジットカード不要で、期間無制限でWatson含めた多数のAPIとサービスが無料で使用できます。取得方法はこちらのIBM Cloudのライトアカウントを作成しよう- IBM Developer チャンネル-をご参照ください。 3.デモの実行 3-1.データ準備 デモで使用する架空の電話会社の顧客データ「customer_churn.csv」をURLからダウンロードし、自分の 作業端末 に保存します。このデータは顧客の属性と契約を解約したかしないか(CHURN)があります。このデータから顧客の属性とCHURNを予測するモデルを作成します。 3-2.Watson Studioプロジェクト、サービス作成 それでは、デモをやってみます。 まずIBM Cloudにログインします。「カタログ」から地域をダラスにし、「Watson Studio Lite」を選択します。左上のダッシュボードのサービスからWatson Studioのサービスを選択、「Get Started」をクリックしてWatson Studioを起動します。 次にプロジェクトを作成します。「Create a Project」「Create an empty project」をクリックします。任意のプロジェクト名を入力します。「Select Storage Service」の「Add」をクリックし、Cloud Object Storageの画面に入ります。Liteが選択されていることを確認して「Create」をクリックします。これでプロジェクトが作成できました。 次にサービスを作成します。Settingから「+Add Services」をクリックしてWatsonを選択します。Machine Learningの「Add」をクリックし、Liteが選択されていることを確認、「Create」をクリックします。Confirm画面でダラスが選択されていることを確認して「Confirm」をクリックします。Settingの画面に戻り、追加したサービスのインスタンスが追加されていることを確認します。 3-3.Auto AIモデルの作成 いよいよAuto AIモデルを作成します。「Add to Project」をクリックし、「Auto AI experiment」をクリックします。Asset nameに”Churn Analysis”と入力し、自分のWatson Machine Learning Service Instance がセットされているのを確認して「Create」 をクリックします。 ダウンロードした「customer_churn.csv」をドラッグ&ドロップしてデータをアップロードします。「Select column to predict 」から予測したい項目で「CHURN 」を選択します。「Run experiment 」をクリックして、モデル作成を開始します。 モデルは複数のステップを経て4つのモデルを生成します。「Run Finished」が表示されるまで待ちます。1、2分でしょうか。下にスクロールするとモデルが作成されています。一番上のモデルが最もよいモデルとなっています。 このモデルの評価基準は変更でき画面は”ROC AUC”という基準で「1」に近いほど判別能が高いことを示しています。 一番上のモデル「Pipeline1」を保存します。「Save as model」をクリックし、Model name を "Churn Analysis Model "に変更して、「 Save 」ボタンをクリックします。 3-4.モデルのデプロイとテスト 最後に出来上がったモデルをデプロイして、テストを行います。先ほど保存したChurn Analysis Modelの画面から「Deployments」タブをクリック、「Add Deployment+」をクリックします。Name に”Churn model deployment ”と入力後、「 Save 」ボタンをクリックします。 STATUS が Initializing からready に変わったら「 Churn model deployment 」をクリックします。 「Test」タブをクリックします。今回のテストはJSONで入力します。テキストのマークをクリックして右画面のJSON構文を入力します。この構文は記された属性が契約を解約したかしないかをモデルに判別させます。入力後「Predict」をクリックします。 「Predict」をクリックすると右側に予測結果が表示されます。この場合はF(解約しない)と表示されました。 今回はJSON構文の入力で分析を試みましたがフォーム欄(ID,Genderなどの欄)に直接データを入れても分析できます。JSON構文の経験が無い方でも簡単に操作できますね。 MLデモを体験してみて はじめてIBM CloudでMLを体験してみました。複雑な作業なんだろうな…と思っていたのですが、準備するものは作業端末と分析したいデータ(csvファイル)で難しいインストールや設定作業はありませんでした。任意のファイル名の入力と「Add」や「Start」を押すだけでAuto AIモデルが作れてしまいます。 作業もサクッと進みこんなに簡単でいいのかと思ってしまいましたが、この容易さがIBM Cloudサービスの良いところだと思います。オンプレミス製品ではH2O DriverlessAIやIBM製品のPowerAI Visionなどがありますが環境準備、インストール、設定作業が発生します。もちろんオンプレミス製品の良いところもありますが、作業工数に余裕が無い、技術者が不足しているなどの課題がございましたら是非IBM Cloud Watson Studioをお試しください。 まとめ 今回はIBM Cloud Watson Studioの機能の一つであるAuto AIを体験しました。上述しましたが操作の容易さ、便利さに驚きました。 ところでWatson StudioはAuto AIの他にも多くの機能が提供されています。Auto AIは「データ分析」のフェーズで使用する機能ですが、その前段階の「データベースアクセス、データ蓄積」、「データ加工」のフェーズにおいても複数の機能が提供されています。また「データ分析」の機能ではAuto AIの他、SPSS ModelerやCognos Serviceなどのラインナップがあり、目的にあったツールを使用することができます。 分析プロセスの「データベースアクセス、データ蓄積」「データ加工」「データ分析」は、少し前まではフェーズ毎に使用ツールが分かれ異なる環境で作業しなければいけませんでした。図4の通り、Watson Studioではこの3フェーズを1つの環境上で使用することができ、作業効率の向上が期待できます。 図4:Watson Studio 概念図 (出典:クラウドオンライン道場資料 Cloud Online dojo_WatsonStudio_20191209.pdf P17) 「時間が無い、技術者も不足している」「CloudでAIなんて難しい!」と思っている方がいらっしゃいましたら是非一度IBM CloudでAIを体験してみてください。「思った以上に簡単、便利!これならお客様の要件にマッチするかも」と感じて頂ければ幸いです。   この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp    

2019年11月29日

Cloud Pak for DataのトライアルとCloud Pakシリーズアップデート情報

こんにちわ。 てくさぽ BLOG メンバーの佐野です。 前回の記事ではCloud Pak for Data(ICP4D)の導入について書きました。 いろいろな方々とお話する機会があり、「ICP4Dを使ってみませんか?」ということをお話するのですが「うちにはそんな大きな環境が無いよ」ということをおっしゃる方が結構多く、ICP4Dを試してみることすらできない環境であることが多そうだと感じています。 そこで、IBMが提供している環境を利用してICP4Dを試しに使ってみることができるのでそのご紹介と、Cloud Pakシリーズのアップデート情報を共有します。 1.Cloud Pak Experiences IBMが提供しているトライアル環境としてCloud Pak Experiencesがあります。このサイト上から、ICP4Dや他のCloud Pakシリーズ製品の実際の画面を利用することができます。 ※ICP4D以外はリンクをクリックすると「IBM Demos」というサイトに飛ばされ、ICP4Dとは違う環境・操作方法となります。 Cloud Pak Experiences環境を使うために必要なものは以下になります。 ・Webブラウザ(ChromeやFirefoxでOK) ・IBM ID ※本サイトではIBM IDの新規登録は完了していることを前提とします また、この環境を使う上でいくつか注意が必要です。 ・トライアルの期間は7日間 ※ケースによって延長できるようですが条件が定かではありません ・共有環境であるため、重要なデータを載せない方が良い ・時々繋がらない時がある ※集合研修などで同一環境から複数が同時にアクセスをすると繋がらなくなることがあるようです 繋がらない時には数日おいてアクセスすることをお勧めします。自宅からだったので複数人でアクセスしたわけではないのですが、私も何回か発生しました。 ・11/28時点ではICP4D v2.1の環境 具体的な利用手順を見ていきましょう。 1.ログイン 用意したIBM IDを利用してログインをします 画面左にある「Log in」をクリックします。 IBM IDとパスワードを入力しログインします。 ログイン後の画面。画像では何日か使った後だったのでトライアル期限は残り1日であることが画面左上に表示されています。 2.実際のICP4Dの画面を利用する 実際の製品の画面を利用するために、まずはデータを収集する機能のデモ(トライアル)を行います。 ログイン後の画面の右側を下にスクロールし、「Collect」欄の下側にある「Learn more」をクリックします。 「Launch path」をクリックします しばらく時間がかかりますが、環境のプロビジョニングが行われ、ICP4Dの画面にアクセスできるようになります。 最初の画面は以下になります。 ブラウザの言語設定にあわせて、ICP4Dの画面表示は日本語表示となっています。 英語ですがチュートリアルもついてくるので、チュートリアルに従って操作をすることでどういう使い方ができるのか?を確認しながらICP4Dを使ってみることができます。 チュートリアルで示された操作以外も試してみることができますので、トライアル期間中に他の機能やメニューの操作感や実際の業務でどういう使い方ができるのか?も確認することができます。 いろいろと試すことができるので、本格的な検討を始める前に自社の利用シーンと合うのか?を確認するためには最適な環境かと思います。 2.IBM Cloud Pakシリーズアップデート情報 IBM Cloud Pak for Data 2.5が出荷開始になりました 10月に発表済みでしたが、2019/11/22にCloud Pak for Data 2.5が出荷開始となりました。 2.5からはOpenShiftのみのサポートとなり、2.1で導入したようなICPベースのものは無くなっているため、導入手順が変更となります。 具体的には、前回の記事で書いたようなOSを用意してインストーラを実行することでICP4Dまで導入される、という手順ではなく自分で用意したOpenShift環境上に、ICP4Dのインストールを実施する、という手順になっています。 具体的な手順や準備が必要なものについてはKnowledge Centerをご参照ください。 また、2.1と比べてベースコンポーネントで利用できる機能・製品が変更となっております。詳細は弊社またはお取引のあるIBMパートナー様までご確認下さい。 IBM Cloud Pak for Securityが発表になりました 前回の記事では5つのCloud Pakシリーズというご紹介をしていますが、6つ目になる「Cloud Pak for Security」が発表になりました。 IBMの製品サイトはこちらになりますが、企業内のセキュリティーに対する脅威の迅速な把握と解決を支援するための製品となります。 具体的にはSIEMやアンチウィルスのような企業内のセキュリティを守るための製品ではなく、発生したインシデントを調査するためのフェデレーション検索(Data Explorer)とインシデントレスポンス(Resilient)が主な機能となります。 3.まとめ Cloud Pakシリーズの製品ラインナップも強化され、個々のCloud Pak製品も随時アップデートがかかっています。 現時点ではCloud PakシリーズとしてはOpenShift 3.11のサポートとなっていますが、今後OpenShift 4もサポート予定なので、アップデートが楽しみです。   この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp

2019年11月19日

【やってみた】超簡単データ分析!H2O Driverless AI を使ってみた

こんにちは。 てくさぽ BLOG メンバーの河野です。 突然ですが、「Driverless AI」ってご存知ですか? 近年データ量はますます増加の一途をたどっていますが、このいわゆるビッグデータを AI を利用して分析・予測をするソリューションが、この Driverless AI です。 Driverless AI は、汎用的な AI(強い AI)ではなく、特化型の AI(弱い AI)の位置づけです。つまり、機械学習が欠かせない AI になります。 「機械学習ってすごく大変だ…」と、つい先日まで私もそう思っていました。 しかしこの Driverless AI は、なんと機械学習の自動化ツールが備わっており、高度な知識やスキルを持たずともいとも簡単に扱えるのです! とはいえ、「本当に初心者でもできるのかな?」 ということで、今回実際にその Driverless AI を試してみました!(ちなみに私はデータ分析は未経験です)   H2O社が開発したDriverless AI Driverless AIという製品は米国の AI エリート集団、「 H2O.ai 」が開発したソリューションです。 今までデータ分析や予測といった業務は専門家が行っていましたが、Driverless AI は その専門家に成り代わり、業務の一部を引き受けてくれます。そのため、スキル面での人材確保でもう頭を抱える必要はありません! 専門的な知識がなくても Driverless AI を使ってデータ分析や予測業務等、日々増加するデータを活用することができるため、ますますビジネスチャンスを広げられるでしょう。   Driverless AIを使った不動産売買価格のシミュレーションモデル作成 今回の環境 ノートPC(CPU : i5-8350U 1.7GHz、メモリ : 8GB、HDD:238GB、OS : Windows10) 分析データ(今回はREINS のウェブサイト「REINS Market Information」を検索して入手した不動産売買データ) Driverless AI の導入環境については、H2O.ai 社 Web ページ「Driverless AIのインストールとアップグレード」に記載されています。 Linux X86_64、IBM Power、Mac OS X、Windows10 Pro の環境をサポートしています。 Windows10Pro 版は GPU のサポートがありませんが、今回はすぐに試したかったので、普段業務で使っている自分のノート PC に導入してみました。仕様としては、最小メモリが 16GB 以上となっていますが、使っている PC のメモリは 8GB しかありません。これも「普段使いの自分の PC で動くかどうか」というの1つの実験です。   Driverless AI の導入手順 1. Driverless AIのアプリケーションのダウンロード・導入 H2O.ai 社のホームページを読みますと、Driverless AI の導入パッケージは、それぞれの環境ごとに docker、RPM、DEB 等、複数用意されております。Windows10Pro のガイドを読むと、docker と DEB イメージの2種類用意されていました。 ここに docker イメージ利用は推奨しない、と書かれていますので、素直に DEB イメージで導入することにします。 ただし、DEB インストールをする場合でも、普段使いの Windows10 を若干カスタマイズしないと使えません。それは、Windows に Linux(Ubuntu)を導入してその上で Driverless AI が動くのです。ただその設定は、比較的簡単で、Windows10 の設定画面を呼び出して「Windows Subsystem for Linux(WSL)」を ON して、この環境にUbuntu 18.04 LTS(Microsoft Storeから無償で入手)を導入するだけです。 この導入に関しては、YouTube を参考にすると誰でもセッティングできます。素晴らしい世の中になりました。 Ubuntu を WSL に導入した後は、H2O.ai のホームページから DEB イメージの導入パッケージを自分の PC へダウンロードするだけですが、このサイズが半端ない(3GB以上)ので、ネットワーク環境によっては少々時間がかかります。 ダウンロードが完了した後、DEBイメージからインストールを実施しました。 DEB からの導入については、Linux である Ubuntu のプロンプト画面からコマンドで実施します。詳細は割愛しますが、H2O.ai 社のホームページ通りにコマンドを実行すると Ubuntu に詳しくない人でも知らずに導入ができますので、ぜひお試しください。 さあ、さっそく Driverless AI を使ってみたいところですが、その前に、H2O.ai 社が許可している21日間有効なトライアル・ライセンスを取得しておきます。 このトライアル・ライセンスの取得がとても簡単でした。H2O.ai 社のホームページから Web 申請をすると10分ほどでライセンス・キーがメールで送付されます。 [caption id="attachment_71208" align="alignnone" width="650"] 図1:トライアルキーの申請書画面[/caption] すでに稼働しているDriverless AIですが、使う時はブラウザ(Google Chrome を使いました)からポート番号を呼び出して実行します。これはどのオペレーティングシステムの環境でも同じ手順になります。今回は、自分の PC で動いているので "http://localhost:12345" を指定しました。 [caption id="attachment_71294" align="aligncenter" width="650"] 図2:検索バーでlocalhost:12345 を指定[/caption] [caption id="attachment_71296" align="aligncenter" width="650"] 図3:サインイン画面に遷移[/caption] 図3のサインイン画面に任意のユーザー ID とパスワードを入力して Driverless AI の GUI 画面を立ち上げました。ライセンスを要求してきますので、入手済みのトライアル用ライセンス・キー(かなり長い)をコピペで適用して、すぐに使えるようになりました。 この間サイズが大きいのでダウンロードに時間がかかりましたが、そのほかの設定や導入は至ってシンプルな印象です。慣れていない方には、ややこしいと感じられるかもしれませんが、YouTube などでも説明されていますし、「何とかなる」と感じました。     2.分析モデル作成 今回の検証では、現実にある業務として、不動産の売り出し価格を機械学習させて適切な(売れ残らず、利益もとれる)販売価格の推論モデルを作成しました。 Driverless AI で以下の3つのステップを実行します。 データアップロード: 不動産売買データを Excel で表にし、そのExcelファイルを Driverless AI へドラッグ&ドロップ。 ターゲットを選択: GUI メニューを使って列名をクリック。 Experiment -モデル作成実行-: GUI 画面の赤枠のボタンをクリック。 [caption id="attachment_71210" align="alignnone" width="650"] 図4:不動産価格情報を検索したのち、画面のコピーから作成したファイル[/caption] [caption id="attachment_71169" align="alignnone" width="560"] 図5:Driverless AI実行画面[/caption] 以上の処理はすぐ終わりましたが、検索画面コピーだけで作った図4のデータはテキスト・データだけのため(例えば価格は、150万円という表示であって、1,500,000という数字ではない)、回帰解析は作成されませんでした。 統計解析のプロから見ると当たり前のことなのでしょうけれども、初心者には、ファイルを与えてみて、試して、目で見れた結果が大事なのです。 そこで、最初に使ったデータの ”単価”、”専有面積”、”駅からの徒歩時間”など、数値であるべきものは数値に変換してみました。(図6参照) [caption id="attachment_71211" align="alignnone" width="650"] 図6:価格等を数値データ変換したファイル[/caption] この図6の Excel ファイルを使って再度 Driverless AI の機械学習ステップ1から3を実行したところ、今度はモデルが作成されました。 「本当に初心者でもできたー!」   ただし、GPGPU を持たないWindows10Pro版 のため、Driverless AI のデフォルト値ではなかなか機械学習が終わらず…途中で実行をキャンセルし、パラメーターを操作して低い精度に変更してから(といっても操作はマウスでクリックするだけです)、ステップ3を実行したところ予測モデルが完成しました。 こんなところも GUI オペレーションでやりながら対応していけるのは、ありがたい。   納得のすごさ!Driverless AI 今までのツールでは、学習データを作った後もデータ欠損やどのパターンで推論するのか等のデータ整備作業を行わないと予測モデルが作成できなかったり、データ整備後もどのような分析を行うかをデータ・サイエンティストが試行錯誤する、というプロセスが必要でした。 が、この Driverless AI は、ある程度のデータ欠損には自動対応してくれます!さらに推論パターン(推論モデル)もデータから自動判断して予測モデルを作成してくれるのです! そのため、本当に AI や機械学習の初心者でも推論モデルを作成することができてしまいました! 完成した予測モデルの精度は、実際の販売価格と比較することでわかります。 また、さらに性能アップをしたい場合は、インプットするファイルのデータの数を増やしたり、精度パラメーター (GUI から簡単に増減できます)を上げるなどしてとても簡単に実施できそうです。次は、こうしたチューニングをやってみたいと思います。 ※ノート PC での実行では、データ数を増やすと演算負荷増大に繋がり、相当時間がかかる可能性があります。このような場合は、機械学習計算性能を最大化する GPGPU 演算が可能なサーバー環境(IBM PowerAC922 のように NVIDIA TeslaV100GPU を搭載するサーバー)で実行すれば、推論モデルは、より高速で作成できます。 ※弊社では、AC922 で Driverless AI の実行環境(PoC 環境)の貸出しをしています。是非こちらもご活用ください! 「IBM AIソリューション PoC環境ご利用ガイド」   まとめ ビジネスで利用する AI で重要なことは、ビジネス課題の解決に役立てるということです。 例えば、製品生産計画策定のために統計解析ツールや AI を使った生産予測をすでに行っている企業においてスムーズに業務が遂行されているケースはいいのですが、解析課題が多すぎて現状体制ではこなせなくなっている場合は、なにかしらの対策をしなければなりません。 しかし、通常の統計解析ツールや AI を使いこなすためにはかなりの勉強と経験を必要とするため、すぐに解決できないことが多いようです。育成ではなく外から人材確保するにも、企業間での採用競争が高まっており、なかなか優良な人材を確保できていないのが実情ではないでしょうか。 また、たとえ技術者がいたとしてもその人材が退職してしまうと途端に業務が滞ってしまう、という懸念もあります。 業務の AI 化というのはこれらの課題を補ってくれるツールである一方、使いこなすのもとても大変です。そのような状況において、AI を使った分析業務を簡略化したり既存の業務の補足をしてくれる Driverless AI は、まさに今の時代に待ち望まれていたソリューションだと言えるでしょう!   この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail:nicp_support@NIandC.co.jp

1 2 3 4 9
back to top