特集・ブログ
文字、音声、画像、位置情報など、私たちの身の回りには多種多様なデータが存在しています。 「ビッグデータ活用」や「データドリブン経営」といった言葉が旬なキーワードとなっていますが、理由の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となります。 1.本記事について 本記事は「IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編）」の コマンドの詳細を掲載したものです。 本編をご覧頂きながら、詳しいコマンドや実行結果を本記事でご確認ください。 2. 事前準備 2-1. 作業用Linux環境準備 （１）Cent OSインストールとディレクトリ作成 今回はCent OS 7をインストールし、ルート配下に以下の3つのディレクトリを作成します。 /work ※作業用スペース /os42 ※OpenShift インストールプログラム置き場 /os42/conf ※yamlやjsonなどの設定ファイル置き場 （２）AWS CLIインストール 前提ソフトウェアを確認し、AWS CLI をインストール・設定します。 <前提バージョン（2.7または3.4以上）の python が導入されていることを確認します。> # python --version Python 3.6.8 <aws cliをインストールし、バージョンを確認します。> rootユーザーで実行する場合の手順を行いました。 # curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip" # unzip awscli-bundle.zip # export PATH=~/.local/bin:$PATH # source ~/.bash_profile # pip3 install awscli --upgrade --users # aws --version aws-cli/1.18.31 Python/3.6.8 Linux/4.18.0-147.5.1.el8_1.x86_64 botocore/1.15.31 <aws cli設定> AWSアカウント情報・利用するリージョンを元にAWS CLIを設定します。 # aws configure AWS Access Key ID: ※利用するAWSアカウントのAccess Keyを入力 AWS Secret Access Key: ※利用するAWSアカウントのSecret Access Keyを入力 Default region name [None]: ap-northeast-1 Default output format [None]: json （３）jqパッケージのインストール <CentOS 7 の標準リポジトリには jq が含まれていないので、EPELリポジトリを yum コマンドでインストールし、その後 jqパッケージをインストールします。> # yum -y install epel-release # yum -y install jq 2-2. インターネットドメインの取得とRoute53への登録 ＜インターネット上から OpenShift クラスターにアクセスするためにインターネットドメインを利用できるようにします。＞ 今回は AWS Route53で独自ドメインを取得・登録しました。 インターネットドメイン名：example.com（仮称） 2-3. インストールファイルの取得 インストールに利用するファイルを用意します。 <作業用Linuxマシンにて、Red Hat OpenShift Cluster Manager サイトの「Infrastructure Provider」ページから「AWS」－「User-Provisioned Infrastructure」を選択し、（１）OpenShift installer と（２）Pull secret をダウンロードし "oc42ディレクトリ" に配置します。> 以下、配置後の確認結果です。 # ll drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf -rw-r--r--. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz -rw-r--r--. 1 root root 2763 3月 4 13:15 pull-secret.txt 3. OpenShift 導入手順 3-1.AWS 環境構築 （１）SSH プライベートキーの生成およびエージェントへの追加 <作業用 Linuxマシン上で以下コマンドを実行し SSHキーを作成します。> # ssh-keygen -t rsa -b 4096 -N '' -f ~/.ssh/id_rsa Generating public/private rsa key pair. Created directory '/root/.ssh'. Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:jyTeAdzo1xi7bZh7+EK+r6j7y5rVDT5Jus8U9JDX8vs root@rpa-20 The key's randomart image is: +---[RSA 4096]----+ | | | . o . . | | + * o . | | . o O o | | o S o . | | . X.& . | | +o%.= . | | + =++. . | | ==*o*Bo E | +----[SHA256]-----+ <ssh-agent プロセスをバックグラウンドタスクとして開始します。> # eval "$(ssh-agent -s)" Agent pid 13552 <SSH プライベートキー（id_rsaファイル）を ssh-agent に追加します。> # ssh-add ~/.ssh/id_rsa Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa) （２）AWS のインストール設定ファイルの作成 <install-config.yaml ファイルを取得します。> 以下を実行すると install-config.yaml ファイルが作成されます。 # ./openshift-install create install-config --dir=/os42 プロンプト上で選択または入力 SSHキー：/root/.ssh/id_rsa ※”（１）SSH プライベートキーの生成およびエージェントへの追加”で作成したSSHキー ターゲットプラットフォーム：aws AWSアクセスキーID： ※利用するAWSアカウントのAccess Keyを入力 AWSシークレットキー： ※利用するAWSアカウントのSecret Keyを入力 AWSリージョン：ap-northeast-1 (tokyo) Route53のベースドメイン名：example.com ※AWS Route53に登録したドメイン名 クラスター名：nicptestcluster ※任意の名前 Pull Secret：※"/os42/pull-secret.txt"の内容をコピー＆ペースト ※特に完了のメッセージは表示されませんのでご注意ください。 <install-config.yaml ファイルを編集し、コンピュートレプリカ の数を 0 にします。> #vi install-config.yaml compute: - hyperthreading: Enabled name: worker platform: {} replicas: 3 ← ここを0に変更 <install-config.yaml ファイルはインストール実行時に消去されてしまうので、別名でバックアップしておきます。> #cp install-config.yaml install-config.yaml.org （３）インフラストラクチャー名の抽出 ＊インストールプログラムが生成する Ignition 設定ファイルには、24時間が経過すると期限切れになる証明書が含まれます。 <クラスターの Kubernetes マニフェストを生成します。> #./openshift-install create manifests --dir=/os42 <openshiftフォルダが作成されるのでフォルダ内を確認します。> # ll openshift -rw-r-----. 1 root root 219 3月 18 09:49 99_cloud-creds-secret.yaml -rw-r-----. 1 root root 181 3月 18 09:49 99_kubeadmin-password-secret.yaml -rw-r-----. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-0.yaml -rw-r-----. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-1.yaml -rw-r-----. 1 root root 1530 3月 18 09:49 99_openshift-cluster-api_master-machines-2.yaml -rw-r-----. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_master-user-data-secret.yaml -rw-r-----. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-0.yaml -rw-r-----. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-1.yaml -rw-r-----. 1 root root 2027 3月 18 09:49 99_openshift-cluster-api_worker-machineset-2.yaml -rw-r-----. 1 root root 2713 3月 18 09:49 99_openshift-cluster-api_worker-user-data-secret.yaml -rw-r-----. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_master.yaml -rw-r-----. 1 root root 1207 3月 18 09:49 99_openshift-machineconfig_worker.yaml -rw-r-----. 1 root root 222 3月 18 09:49 99_role-cloud-creds-secret-reader.yaml <クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐために、コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。> #rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml <同様に、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。> #rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml </oc42/manifests/cluster-scheduler-02-config.yml を変更し、Pod がコントロールプレーンマシンにスケジュールされないようにします。> # vi /oc42/manifests/cluster-scheduler-02-config.yml "mastersSchedulable"パラメーターの値を False に設定、保存します。 <Ignition 設定ファイルを取得します。> #./openshift-install create ignition-configs --dir=/os42 <コマンド実行後、作成されたファイル・ディレクトリを確認します。> # ll -rw-r--r--. 1 root root 706 3月 9 20:16 README.md drwxr-x---. 2 root root 50 3月 18 09:52 auth ←あることを確認 -rw-r-----. 1 root root 291635 3月 18 09:53 bootstrap.ign ←あることを確認 drwxr-xr-x. 2 root root 4096 3月 18 09:39 conf -rw-r-----. 1 root root 4045 3月 18 09:49 install-config.yaml.org -rw-r-----. 1 root root 1837 3月 18 09:52 master.ign ←あることを確認 -rw-r-----. 1 root root 267 3月 18 09:53 metadata.json ←あることを確認 -rwxr-xr-x. 1 root root 323536416 3月 9 20:16 openshift-install -rw-r--r--. 1 root root 80468756 3月 16 10:18 openshift-install-linux-4.2.23.tar.gz -rw-r--r--. 1 root root 2763 3月 4 13:15 pull-secret.txt -rw-r-----. 1 root root 1837 3月 18 09:52 worker.ign ←あることを確認 # ll auth/ -rw-r-----. 1 root root 23 3月 18 09:52 kubeadmin-password ←あることを確認 -rw-r-----. 1 root root 8972 3月 18 09:52 kubeconfig ←あることを確認 <インフラストラクチャー名を抽出します。> Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出・表示します。ここで事前に準備したjqコマンドが必要になるのですね。 # jq -r .infraID /os42/metadata.json nicptestcluster-w8r8h ←インフラストラクチャー名が出力されることを確認 （４）AWS での VPC の作成 </os42/confディレクトリに以下のファイルを作成します。> なお、これ以降の手順の中で作成した yamlファイル、jsonファイルともファイル名は任意です。 CloudFormation Template："cf_newvpc.yaml"ファイル CloudFormation Templateのパラメーター："cf_newvpc.json"ファイル ＊cf_newvpc.yaml、cf_newvpc.jsonファイルの中身はRed Hatマニュアルページの”1.5.7. AWS での VPC の作成”に書かれている内容をコピー・アンド・ペーストします。今回はマニュアル記載の値のままで作成しました。 ParameterKey ParameterValue 備考 VpcCidr 10.0.0.0/16 VPC の CIDR ブロック。 AvailabilityZoneCount 1 VPC をデプロイするAZの数 SubnetBits 12 各AZ内の各サブネットのサイズ <VPC 作成の CloudFormation 展開コマンドを実行します。> --stack-name の後のスタック名（以下のコマンドでは createvpc）は任意の名前です。 ＊ここで本検証で初めて CloudFormation を実行しました。 （５）AWS でのネットワークおよび負荷分散コンポーネントの作成 <VPC作成時と同様に、マニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。> CloudFormation Template："cf_network.yaml"ファイル CloudFormation Templateのパラメーター："cf_network.json"ファイル <cf_network.jsonファイルを編集します。> ここがポイントです。 以下の cf_network.jsonファイル内の7つの ParameterKey に指定する ParameterValue を、これまで実行したコマンドや情報からの値に更新します。 ParameterKey ParameterValue 備考 ClusterName nicptestcluster install-config.yaml ファイルを生成した時に入力したクラスター名 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 HostedZoneId ZMxxxxxxxxxxx Route53 パブリックゾーン ID（事前にAWSコンソールで確認します） HostedZoneName example.com nstall-config.yaml ファイルを生成した時に使用した Route53 ベースドメイン名 PublicSubnets subnet-0306b9ca39a3a00bd VPC の CloudFormation テンプレートの出力より PrivateSubnets subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より <更新した cf_network.jsonファイルを用いて CloudFormation 展開コマンドを実行します。> # aws cloudformation create-stack --stack-name createnetwork --template-body file:///os42/conf/cf_network.yaml --parameters file:///os42/conf/cf_network.json --capabilities CAPABILITY_NAMED_IAM <出力を確認します。> # aws cloudformation describe-stacks --stack-name createnetwork ParameterKey ParameterValue 備考 PrivateHostedZoneId Z0xxxxxxxxxxxxxxxxxxxx プライベート DNS のホストゾーン ID ExternalApiLoadBalancerName net/nicptestcluster-w8r8h-ext/9a604677bb972af0 外部 API ロードバランサーのフルネーム InternalApiLoadBalancerName net/nicptestcluster-w8r8h-int/a277ca3a4501369a 内部 API ロードバランサーのフルネーム ApiServerDnsName api-int.nicptestcluster. example.com API サーバーのFQDN RegisterNlbIpTargetsLambda arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 これらのロードバランサーの登録/登録解除に役立つ Lambda ARN ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 外部 API ターゲットグループの ARN InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 内部 API ターゲットグループの ARN InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc 内部サービスターゲットグループの ARN （６）AWS でのセキュリティーグループおよびロールの作成 <これまでと同様にマニュアルの該当ページの内容を含んだファイルをそれぞれ”/os42/conf”に配置します。> CloudFormation Templateのパラメーター："cf_security.json"ファイル CloudFormation Template："cf_security.yaml"ファイル <cf_security.jsonファイルを編集します。> 以下の4箇所のParameterValueに値をセットします。 ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 VpcCidr 10.0.0.0/16 VPCのサブネットアドレス値 PrivateSubnets subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より <CloudFormation展開コマンドを実行します。> # aws cloudformation create-stack --stack-name createsecurity --template-body file:///os42/conf/cf_security.yaml --parameters file:///os42/conf/cf_security.json --capabilities CAPABILITY_NAMED_IAM <出力を確認します。> # aws cloudformation describe-stacks --stack-name createsecurity ParameterKey ParameterValue 備考 MasterSecurityGroupId sg-0ca008469442d0702 マスターセキュリティーグループ ID WorkerSecurityGroupId sg-0fcaab02eeb63b716 ワーカーセキュリティーグループ ID MasterInstanceProfile createsecurity-MasterInstanceProfile-JAFR521FJOOL マスター IAM インスタンスプロファイル WorkerInstanceProfile createsecurity-WorkerInstanceProfile-1320LLA579623 ワーカー IAM インスタンスプロファイル （７）AWS インフラストラクチャーの RHCOS AMI <利用するRHCOS AMIのAWSゾーンとAWS AMIをマニュアルページの”1.5.10. AWS インフラストラクチャーの RHCOS AMI”にて確認します。> 今回は aws configure でも指定した ap-northeast-1 ですので、該当ゾーンの AWS AMI を確認します。 AWSゾーン：ap-northeast-1 AWS AMI：ami-0426ca3481a088c7b 3-2. OpenShift導入 （１）Bootstrapノード作成 OpenShiftクラスターの初期化で使用するBootstrapノードをAWS上に作成します。 <Ignition 設定ファイルを S3バケットに配置します。> まずS3バケットを作成します # aws s3 mb s3://nicptestcluster-infra 続いてIgnition 設定ファイル（bootstrap.ign ）をS3バケットにアップロードします。 # aws s3 cp bootstrap.ign s3://nicptestcluster-infra/bootstrap.ign 最後にファイルがアップロードされたことを確認します。 # aws s3 ls s3://nicptestcluster-infra/ 2020-03-27 10:08:33 291635 bootstrap.ign </os42/confディレクトリに以下のファイルを作成します。> CloudFormation Template："cf_bootstrap.yaml"ファイル CloudFormation Templateのパラメーター："cf_bootstrap.json"ファイル <cf_bootstrap.jsonファイルを編集します。> ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI AllowedBootstrapSshCidr 0.0.0.0/0 デフォルトのまま PublicSubnet subnet-0306b9ca39a3a00bd VPC の CloudFormation テンプレートの出力より MasterSecurityGroupId sg-0ca008469442d0702 セキュリティーグループおよびロールの CloudFormation テンプレートの 出力より VpcId vpc-00a56e4c475a50da8 VPC の CloudFormation テンプレートの出力より BootstrapIgnitionLocation s3://nicptestcluster-infra/bootstrap.ign ブートストラップファイルの場所 AutoRegisterELB yes ネットワークロードバランサー (NLB) を登録するかどうか RegisterNlbIpTargetsLambdaArn arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 ネットワークのCloudFormationテンプレートの出力より ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 ネットワークのCloudFormationテンプレートの出力より InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 ネットワークのCloudFormationテンプレートの出力より InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc ネットワークのCloudFormationテンプレートの出力より <CloudFormation 展開コマンドを実行します。> # aws cloudformation create-stack --stack-name bootstrap --template-body file:///os42/conf/cf_bootstrap.yaml --parameters file:///os42/conf/cf_bootstrap.json --capabilities CAPABILITY_NAMED_IAM <出力を確認します。> # aws cloudformation describe-stacks --stack-name bootstrap ParameterKey ParameterValue 備考 BootstrapInstanceId i-0a68a104e8a04ae08 Bootstrapインスタンス ID BootstrapPublicIp 13.112.188.xxx Bootstrapノードのパブリック IP アドレス BootstrapPrivateIp 10.0.0.xxx Bootstrapのプライベート IP アドレス （２）コントロールプレーン（Masterノード）の作成 </os42/confディレクトリに以下のファイルを作成します。> CloudFormation Template："cf_controlplane.yaml"ファイル CloudFormation Templateのパラメーター："cf_controlplane.json"ファイル <cf_controlplane.jsonファイルを編集します。> ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI AutoRegisterDNS yes yesまたはno PrivateHostedZoneId Z0xxxxxxxxxxxxxxxxxxxx ネットワークのCloudFormationテンプレートの出力より Master0Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より Master1Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より Master2Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より MasterSecurityGroupId sg-0ca008469442d0702 セキュリティーグループおよびロールの CloudFormation テンプレートより IgnitionLocation https://api-int.nicptestcluster.example.com:22623/ config/master 生成される Ignition 設定ファイルの場所を指定 CertificateAuthorities data:text/plain;charset=utf-8;base64,LS0tLS1・・・ インストールディレクトリーにあるmasiter.ignファイルから値を指定 MasterInstanceProfileName" createsecurity-MasterInstanceProfile-JAFR521FJOOL セキュリティーグループおよびロールの CloudFormation テンプレートより MasterInstanceType m5.xlarge 利用するEC2インスタンスタイプを指定 AutoRegisterELB yes yesまたはno RegisterNlbIpTargetsLambdaArn arn:aws:lambda:ap-northeast-1:359962000209:function:createnetwork-RegisterNlbIpTargets-1M2PEFJK0J2C3 ネットワークのCloudFormationテンプレートの出力より ExternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Exter-RH5R6UUT2ULX/80f9d95fe136b5e3 ネットワークのCloudFormationテンプレートの出力より InternalApiTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-B5IB5RST56XN/4cfdcc5ae595e3f9 ネットワークのCloudFormationテンプレートの出力より InternalServiceTargetGroupArn arn:aws:elasticloadbalancing:ap-northeast-1:359962000209:targetgroup/creat-Inter-NEZL8AMZ4W1X/5a6cce34822ca9dc ネットワークのCloudFormationテンプレートの出力より <今回、"MasterInstanceType" に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_controlplane.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。> 途中、省略 MasterInstanceType: Default: m4.xlarge Type: String AllowedValues: - "m4.xlarge" - "m4.2xlarge" - "m4.4xlarge" - "m4.8xlarge" - "m4.10xlarge" - "m4.16xlarge" - "m5.xlarge" ←追加 - "m5.2xlarge" ←追加 - "m5.4xlarge" ←追加 - "m5.8xlarge" ←追加 以下、省略 <CloudFormation 展開コマンドを実行します。> # aws cloudformation create-stack --stack-name controlplane --template-body file:///os42/conf/cf_controlplane.yaml --parameters file:///os42/conf/cf_controlplane.json <状況を確認します。> # aws cloudformation describe-stacks --stack-name controlplane （３）Workerノードの作成 ※CloudFormation テンプレートは、1 つのWorkerマシンを表すスタックを作成します。今回はWorkerノードを2台作成するので、それぞれのWorkerマシンにスタックを作成する必要があります。 </os42/confディレクトリに以下のファイルを作成します。> CloudFormation Template："cf_worker.yaml"ファイル CloudFormation Templateのパラメーター："cf_worker.json"ファイル <cf_worker.jsonファイルを編集します。> ParameterKey ParameterValue 備考 InfrastructureName nicptestcluster-w8r8h Ignition 設定ファイルから抽出したインフラストラクチャー名 RhcosAmi ami-0426ca3481a088c7b 確認したAWS AMI Subnet subnet-0407cf93524961fb4 VPC の CloudFormation テンプレートの出力より WorkerSecurityGroupId sg-0fcaab02eeb63b716 セキュリティーグループおよびロールの CloudFormation テンプレートより IgnitionLocation https://api-int.nicptestcluster.example.com:22623/ config/worker 生成される Ignition 設定ファイルの場所を指定 CertificateAuthorities data:text/plain;charset=utf-8;base64,LS0tLS1・・・ インストールディレクトリーにあるworker.ignファイルから値を指定 WorkerInstanceProfileName createsecurity-WorkerInstanceProfile-1320LLA579623 セキュリティーグループおよびロールの CloudFormation テンプレートより WorkerInstanceType m5.xlarge 利用するEC2インスタンスタイプを指定 <cf_controlplane.yamlと同様に、"MasterInstanceType" に m5 インスタンスタイプを指定するので、そのインスタンスタイプを cf_worker.yaml ファイルの MasterInstanceType.AllowedValues パラメーターに追加します。> CloudFormation 展開コマンドを実行。 今回ワーカーノードは2台作成するので、stack-name を「worker1」「worker2 」と分けて2回実行します。 # aws cloudformation create-stack --stack-name worker1 --template-body file:///os42/conf/cf_worker.yaml --parameters file:///os42/conf/cf_worker.json # aws cloudformation create-stack --stack-name worker2 --template-body file:///os42/conf/cf_worker.yaml --parameters file:///os42/conf/cf_worker.json <出力を確認します。> # aws cloudformation describe-stacks --stack-name worker1 # aws cloudformation describe-stacks --stack-name worker2 （４）Bootstrapノードの初期化 <Bootstrapノードの初期化コマンドを実行し、FATAL エラーなどが出ずに終了することを確認します。> # ./openshift-install wait-for bootstrap-complete --dir=/os442 --log-level=info INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.14.6-152-g117ba1f up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources （５）CLI のインストール <OpenShift Installer、Pull secretをダウンロードしたページにて、「Command-line interface」項目からOSとして「Linux」を選択し、「command-line tools」をダウンロードします。> <CLIツールの展開 - ダウンロードした圧縮ファイルを展開します 。> ※OS42ディレクトリにダウンロードしたファイルをコピーし、展開します。 # cp tar xvf openshift-client-linux-4.2.23.tar.gz /os42/tar xvf openshift-client-linux-4.2.23.tar.gz # tar xvf openshift-client-linux-4.2.23.tar.gz ※パスに/oc42を追加します。 # export PATH="$PATH:/os42" ※ocコマンドのテスト # oc help （６）クラスターへのログイン ※kubeadmin 認証情報をエクスポートします。 # export KUBECONFIG=/os42/auth/kubeconfig ※oc コマンドを正常に実行できることを確認 # oc whoami system:admin （７）マシンの CSR の承認 <クラスターがマシンを認識していること（今回Masterノード3台、Workerノード2台が表示されること）を確認します。> # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-48-xxx.ap-northeast-1.compute.internal Ready worker 57s v1.14.6+8fc50dea9 ip-10-0-49-xxx.ap-northeast-1.compute.internal Ready worker 42m v1.14.6+8fc50dea9 ip-10-0-50-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-58-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-59-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 （８）Operator の初期設定 5秒ごとに実行される oc get clusteroperators の結果をモニタリングし、クラスターコンポーネントがオンラインになることを確認します。 <”Available" が ”True”、”DEGRADED” 列が ”False” になることを確認します。> # watch -n5 oc get clusteroperators NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.2.23 True False False 44m cloud-credential 4.2.23 True False False 22h cluster-autoscaler 4.2.23 True False False 22h console 4.2.23 True False False 46m dns 4.2.23 True False False 22h image-registry 4.2.23 True False False 50m ingress 4.2.23 True False False 50m ・ ・ 以下、省略 本検証では、（７）マシンの CSR の承認の手順で全ノードが Ready となった後に確認するとすべての Operator コンポーネントがオンライン（AVAILABLE 列が True）になっていましたが、image-registry Operator がオフライン（AVAILABLE 列が False）である場合はマニュアルページの「1.5.17.1. イメージレジストリーストレージの設定」の章をご確認ください。 （９）Bootstrapノードの削除 クラスターの初期 Operator 設定を完了した後に Bootstrapリソースを削除します。 <CloudFormation コマンドで"（１）Bootstrapノード作成"手順で作ったbootstrap という名前の Stack を削除します。> これにより、ブートストラップノードが削除されます。 # aws cloudformation delete-stack --stack-name bootstrap （１０）クラスターのインストールを完了 <クラスターのインストール完了を確認します。> 以下のコマンドでインストール状況をモニターします。 #./openshift-install --dir=/os42 wait-for install-complete （中略） INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/os42/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.nicptestcluster.example.com INFO Login to the console with user: kubeadmin, password: XXXXX 上記のように ”Install complete!" となり、「コンソールのURL」「ユーザー名」「パスワード」が表示されればインストール完了で OpenShift 環境が利用可能となります。 ！！重要！！ インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになる証明書が含まれます。 Ignition ファイルは 24 時間有効であるため、この時間内に OpenShift デプロイメントを実行する必要があります。 作成から24時間過ぎた場合はIgnition ファイルを再生成する必要があります。 <動作確認 - OpenShiftのコンソールにアクセスします。> Webコンソールの場合： https://console-openshift-console.apps.nicptestcluster.example.com CLI の場合： oc login -u kubeadmin -p XXXXX https://api.nicptestcluster.example.com:6443 以上で OpenShift インストールは完了となります。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 こんにちは。 てくさぽBLOGメンバーの岡田です。 全3回「IBM Cloud Pak for Applicationsを導入してみた」シリーズの、"OpenShift導入編" です。 IBM Cloud Pak for Applicationsを導入してみた（概要編） IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編） ← 今回 IBM Cloud Pak for Applicationsを導入してみた（ICP4 Applications導入編） 本記事では、我々が実際にやってみてつまづいたポイントや AWS 特有の注意事項も記載していますので、ぜひ最後までお読みください。 1. はじめに 概要編でも述べていますが、IBM Cloud Paks（以下 Paks）は OpenShift 上で稼働するアプリケーションのため、Paks を利用するためには OpenShift の構築が必要となります。 今回の検証では最小構成での検証を実施するために、以下の環境で実施しました。 AWS 上での構築 OpenShift バージョン4.2（検証時最新） User-Provisioned Infrastructure（UPI）方式・・・ユーザーがインフラ環境を事前に用意してインストールを行う方法 CloudFormation テンプレートの使用 さて、以下が今回インストールする全体構成になります。Masterノード3台、Workerノード2台の構成です。 また本検証では、以下の Red Hat 社マニュアルページを利用しました。 インストールで利用する jsonファイル、yamlファイルの中身はこのマニュアル内の記載からコピー・アンド・ペーストして作成します。 「1.5. CLOUDFORMATION テンプレートの使用による、AWS でのユーザーによってプロビジョニングされたインフラストラクチャーへのクラスターのインストール」 2. 事前準備 2-1. 作業用Linux環境準備 OpenShiftのインストール作業に必要なLinux(Cent OS)環境を準備します。 詳細な手順はリンク先を参照ください。 （１）Cent OS インストールとディレクトリ作成 （２）AWS CLI インストール （３）jqパッケージのインストール 2-2. インターネットドメインの取得とRoute53への登録 インターネット上から OpenShift クラスターにアクセスするためにインターネットドメインを利用できるようにAWS Route53で独自ドメインを取得・登録しました。 インターネットドメイン名：example.com（仮称） 2-3. インストールファイルの取得 OpenShiftのインストールに利用するファイルをRed Hatサイトからダウンロードします。 3. OpenShift 導入手順 3-1.AWS 環境構築 まずは AWS 環境を構築します。 今回は以下の全7項目を順番に実施しました。 詳細な手順はリンク先を参照ください。 （１）SSH プライベートキーの生成およびエージェントへの追加 （２）AWS のインストール設定ファイルの作成 （３）インフラストラクチャー名の抽出 （４）AWS での VPC の作成 ※つまづきポイントをこの後ご紹介 （５）AWS でのネットワークおよび負荷分散コンポーネントの作成 （６）AWS でのセキュリティーグループおよびロールの作成 （７）AWS インフラストラクチャーの RHCOS AMI 「（４）AWSでのVPCの作成」でのつまづきポイント VPC作成のCloudFormationコマンドを実行した際にエラーが発生したので、原因と解決方法をご紹介します。 ↓このコマンドでエラーが出ていますが、どこが間違っているか分かりますか？ # aws cloudformation create-stack --stack-name createvpc --template-body conf/cf_newvpc.yaml --parameters conf/cf_newvpc.json Error parsing parameter '--parameters': Expected: '=', received: 'EOF' for input: conf/cf_newvpc.json パッと見、おかしいところが無さそうなのですがエラーとなっています。 検証メンバーで調査＆トライ・アンド・エラーすること小一時間。。。原因は単純でした。 ファイル名を”file://”で指定していなかったのでyamlファイルやjsonファイルが読み込めなかったのです。以下が正しいコマンドになります。”file://”の後ろはフルパスで指定しているので"/"が3つ並んでます。 # aws cloudformation create-stack --stack-name createvpc --template-body file:///os42/conf/cf_newvpc.yaml --parameters file:///os42/conf/cf_newvpc.json 3-2. OpenShift導入 今回は以下の全10項目を順番に実施しました。 こちらも詳細な手順はリンク先を参照ください。 （１）Bootstrapノード作成 （２）コントロールプレーン（Masterノード）の作成 （３）Workerノードの作成 （４）Bootstrapノードの初期化 （５）CLI のインストール （６）クラスターへのログイン （７）マシンの CSR の承認 ※つまづきポイントをこの後ご紹介 （８）Operator の初期設定 （９）Bootstrapノードの削除 （１０）クラスターのインストールを完了 「（７）マシンの CSR の承認」でのつまづきポイント "oc get nodes"コマンドを実行してもマスターノードのみを認識しワーカーノードを認識しなかったので、その解決方法を紹介します。 下記のとおり、oc get nodes を実行してもマスターノードしか認識していません。 # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-50-xxx.ap-northeast-1.compute.internal Ready master 21h v1.14.6+8fc50dea9 ip-10-0-58-xxx.ap-northeast-1.compute.internal Ready master 21h v1.14.6+8fc50dea9 ip-10-0-59-xxx.ap-northeast-1.compute.internal Ready master 21h v1.14.6+8fc50dea9 保留中の証明書署名要求 (CSR) を確認するとPending になっています。 # oc get csr NAME AGE REQUESTOR CONDITION csr-485lx 22m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-9qjqw 18m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ・ ・ 以下、省略 そこでまずは個々のCSRを承認していきましたがコマンド実行してもすぐに反映されない、また保留状態のCSRが増えていくという状態になりました。 # oc adm certificate approve csr-9qjqw certificatesigningrequest.certificates.k8s.io/csr-9qjqw approved # oc get csr NAME AGE REQUESTOR CONDITION csr-9qjqw 53m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-485lx 22m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ・ ・ 以下、省略 CSRが増える一方で状況が悪化しており、出てきたCSRを個別に処理するのもキリがないためこの時点で一度諦めました。 翌日にまとめて CSR を承認するコマンドを探して実行すると、ワーカーノードが認識できました。 # oc get csr -ojson | jq -r '.items[] | select(.status == {} ) | .metadata.name' | xargs oc adm certificate approve certificatesigningrequest.certificates.k8s.io/csr-2fn5z approved certificatesigningrequest.certificates.k8s.io/csr-4cj8b approved certificatesigningrequest.certificates.k8s.io/csr-4lpv7 approved ・ ・ 以下、省略 ※少しタイムラグがあるので、何回か状況確認・Approve処理を行う必要がありました。10分ぐらい間隔をあけた方がよかったです。 oc get nodesコマンドで全ノードの STATUSがReady であることを確認できます。 # oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-48-xxx.ap-northeast-1.compute.internal Ready worker 57s v1.14.6+8fc50dea9 ip-10-0-49-xxx.ap-northeast-1.compute.internal Ready worker 42m v1.14.6+8fc50dea9 ip-10-0-50-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-58-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 ip-10-0-59-xxx.ap-northeast-1.compute.internal Ready master 22h v1.14.6+8fc50dea9 まとめて承認するコマンドが見つからなかったら、と思うとゾッとします。読者の方は事前に調べておきましょうね。 4. AWS特有の注意事項 AWSネットワークの理解は必須 Red Hat社のマニュアルページの内容を利用して jsonファイルと yamlファイルを用意し、CloudFormationコマンドを実行すれば AWS コンポーネントや OpenShift ノードなど必要なコンポーネントが自動的に作成されますが、自動的に作成されるが故に、ロードバランサー、サブネット、EC2インスタンスなどのコンポーネント間の接続の関係性が分かりづらいと思いました。 AWS マネージメントコンソールでなにが作成されたかを確認できますが、AWS のネットワークを理解していないと全体像の把握が難しくその点が苦労しました。 CloudFormation 特有のインストール時のクセを理解し慣れる CloudFormation でのインストールでは、それ以前に実行して出力された値を次の CloudFormation コマンドで用いる jsonファイルに転記して利用する、という操作を繰り返します。特に UPI方式では転記する項目も回数も多かったので、Excel でどの項目がどのフェーズの jsonファイルに転記するのかを整理してインストールを進めました。 またそのような CloudFormation の特徴から、事前に設定ファイルをすべて用意して順番に実行する、ということができませんのでインストール作業は時間に余裕を持って行いましょう。 5. まとめ 本記事で OpenShift を AWS 上で UPI インストールする流れを確認いただけましたでしょうか。 必要なインフラのコンポーネントをインストーラが自動的に作成してくれる IPI (Installer Provisioned Infrastructure) 方式と比べると作業工程が多くなりますが、本番環境のお客様要件に対し常に IPI方式で構築できるとは限らないと想定し、UPI方式を学んでおくことは大変有用だと思いますので参考になれば幸いです。 本記事の内容で構築した環境に、この後 Paks をインストールすることが可能となります。Paks の種類によって必要リソースは異なりますが UPI方式での手順は同じです。 次回は、この OpenShift の環境に Cloud Pak for Application をインストールしてみた内容をお伝えします。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp 関連情報 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編 (ブログ) - シリーズ第1回目！概要編として検証の目的・背景や環境周りをご紹介します。 【やってみた】Cloud Pak for Applications 導入してみた：Cloud Pak for Applications 導入編 (ブログ) - AWS 上に構築した Openshift 環境に Cloud Pak for Applications をインストールしてみました。 今、デジタルサービスに求められる必須要件とは!? アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 【外部ページ】 IBM Cloud Pak for Applications (IBMサイト)
スマートデバイスや IoT の進歩によって、企業は多様なデータを手にできるようになりました。そして、それらを有効に活用していくためにデータ分析基盤を構築する企業が増えています。 (さらに…)
こんにちは。 てくさぽBLOGメンバーの佐野です。 およそ9か月前にCloud Pak for Dataのトライアルに関する記事を書きましたが、その後「触ってみてどういうものか理解できた！」「機能が豊富すぎて全部を理解するのは難しい」などの反響も頂きました。 この9か月の間にいくつかCloud Pak for Data関連のアップデートがありましたのでその情報をお届けします。 大きなトピックとして2点あります。 ・トライアルだけでなくビデオでの説明・紙芝居のような操作確認をIBM Demosでご提供 ・Cloud Pak for Data v3.0の出荷開始 まずはIBM Demosに関することから共有します。 １．IBM Demos 「Cloud Pak ExperienceというサイトでCloud Pak for Dataのトライアルができますよー」と利用方法含めて前回の記事で記載しました。 しかし、チュートリアルに従って簡単な利用方法を確認できるとはいえ、環境だけあっても「具体的にどんな機能があるんだ？」「こういう使い方できるんだろうか？」というところは自力で探して理解するしかありませんでした。 そこに対しての解決策の一つとなるのが”IBM Demos”です。 IBM Demosのサイトにアクセスをするといろいろな製品のデモや概要説明ビデオなどを探すことができます。 この中にCloud Pak for Dataもありますので、Cloud Pak for Dataに関する内容を閲覧することができます。 下の図の赤枠で括った箇所をクリックすると、IBM Demos内のCloud Pak for Dataサイトに飛びます。 サイトの表示は英語ですが、URLの最後の「?lc=en」を「?lc=ja」に変えることで日本語表示に変更することができます。ただ、一部違和感がある表現があったり、日本語字幕入りのビデオしか表示されないため、本記事では英語表示のままで説明をします。 IBM Demosはいくつかのパートに分かれています。Cloud Pak for Dataでは以下の3つです。 ・Video ・Product Tour ・Hands on Lab Videoでは概要を把握できるような説明ビデオが流れます。一部は日本語字幕有なので、英語が分からなくても内容が理解できるようになっています。 私のお勧めは「Overview of IBM Cloud Pak for Data」です。このビデオではCloud Pak for Dataの概要を理解することができます。他にはCloud Pak for Dataの特長の一つであるデータ仮想化の機能について説明している「IBM Cloud Pak for Data - Intro to Data Virtualization」も（英語ですが）見ておいた方がよいと思います。 Product Tourでは特定の機能を製品画面の操作をすることでより深く把握することができます。ただし、自由な操作はできずに、シナリオに沿った操作を紙芝居のようにできるぐらいです。 本記事の執筆時点では4つのみですが、ご自身が使いたい機能がこの中にあるようでしたら操作方法が分かりますので確認した方がよいでしょう。 Hands on Labsではトライアル用マシンを使って実際の操作を体験することができます。ここから先はIBM idが無いと操作ができません。「Experience IBM Cloud Pak for Data」ではIBM Demosから離れてCloud Pak Experienceへ移動します。 Cloud Pak Experience Cloud Pak Experienceですが、Cloud Pak for Dataのトライアル環境です。画面が前のブログと若干異なりますが、画面左側に表示されているHands-on Learning項目のCloud Pakシリーズのリンクを押すとIBM Demosに遷移する動作は変わっていません。 トライアルを始めるといっても、いくつかの基本的なシナリオの操作をすることがベースなので、まずはデータを収集するための”Collect”から始めましょう。 画面を少し下に移動して「Log in to explore」を押します。 IBMidを持っている人はIBMidとパスワードを入力し先に進みます。お持ちでない人はIBMidを作成します。画面の真ん中に「IBMid の作成」というリンクがあるのでこちらから作成してください。 こんな画面が出ることもあるようですが、問題なければ「次に進む」を押します。 デモ環境へアクセスするために、利用条件やプライバシーに関する同意を求められますので、内容を読んだうえで「次へ」を押します。 Cloud Pak Experienceのサイトにログインした状態で戻ってきました。「Explore」を押して早速Cloud Pak for Dataを体験してみましょう。 Exploreを押すと「しばらく待て」というメッセージがでるので、少し待ちます。 しばらく待つと自動的に画面が遷移します。 ここで自分自身で操作するか、ガイド付きかを選択できます。今回は「Let's go!」を押します。 ここから先は詳細を飛ばしますが、画面表示が日本語になっているのがうれしいですね。日本語で操作ができるなら見た目でも何が書いてあるのか理解しやすいですし、自力でなんとかなりそうな気もしてきます。 ただ、ガイド文は英語なので、どういうことをしようとしているのか？を読むのが大変かもしれません。 本ブログを書いている時点で、Cloud Pak Experience環境で使っているCloud Pak for Dataのバージョンは「3.0.1 enterprise」という最新バージョンでした。 なので、導入を検討しているようなステップにある場合でも画面や操作感が変わらない状態で確認できます。 是非、データ分析基盤の導入を検討する際にはCloud Pak Experienceを使ってみて下さい。 ２．Cloud Pak for Data v3アップデート情報 Cloud Pak for Data v3が2020/6/19に出荷開始となりました。主なアップデート内容は以下になります。 DataOps機能拡張 Watson Knowledge Catalog機能拡張およびデータ仮想化連携強化 セキュリティ強化 ⾮構造化データ管理の拡張（InstaScan) AIの機能拡張 ML Ops Auto AIの機能拡張 コンポーネントの拡張 Planning Analytics、Virtual Data Pipeline、Master Data Managementを含む新たなサービス群の追加 運用機能拡張 監査、バックアップといった運用機能強化 OpenShift v4.3対応 UIの変更 Cloud Pak for Dataライセンス名称の変更（Cloud Native→Standardへ変更）及びnon-productionライセンスの提供（Enterpriseのみ） 紙面の関係上、具体的な機能のアップデートは省略してコンポーネント拡張とライセンスについてご説明します。 Cloud Pak for Data v3で利用できるコンポーネントの一覧を図にまとめました。 ベースコンポーネント列にある製品(機能)はCloud Pak for Dataを購入すれば利用できます。追加サービス列にある製品(機能)はCloud Pak for Dataライセンスには含まれず、個別にライセンスを購入する必要があります。 表の中でも青文字で書かれた製品が今回のv3の提供に伴って追加となっています。この提供形態はv2.5からですが、追加サービスはどんどん増えているので今後の拡張にも期待できます。 追加サービスを購入する場合、例えばDataStageは個別の製品ライセンスとしても販売していますので既にDataStage自体をご利用になられているお客様もいらっしゃるのではないかと思います。 そういったお客様がCloud Pak for Dataへ移行しやすくなるように、一部の追加サービス製品においては既存環境のライセンスをCloud Pak for Dataの追加サービスに置き換えることで既存環境・Cloud Pak for Data環境どちらでも利用可能となるものもあります。 具体的な例を図に表しました。 この例では既に2,800PVU（40VPC相当）のDataStage環境をお使いのお客様がCloud Pak for Data DataStage追加サービス×40VPCへ置き換えたケースです。 図に示しているいずれのシーンにおいても、ライセンスを追加購入する必要がないため、Cloud Pak for Dataへ移行している最中であっても、もちろんCloud Pak for Dataへ移行した後であっても追加のライセンス費用はかかりません。 また、単体製品としてのDataStageからCloud Pak for Data DataStage追加サービスへのトレードアップもできますので、ゼロからライセンス買い直しをせずにCloud Pak for Dataを利用することができるようになり、非常にお得です。 注：ライセンス情報・コンポーネント情報は更新される場合がありますので最新情報を必ずご確認下さい。 ３．まとめ Cloud Pak for Dataはまだまだ発展しており、更新情報も全部ご説明ができていませんが情報てんこ盛りになってしまいました。 データ分析基盤をご検討頂いている方には自社のデータ分析をどのように効率できるのか、是非ともCloud Pak for Dataを体験頂き、その体験をするためにこの記事がお役に立てれば幸いです。 また、別のコラムやホワイトペーパーでデータ分析基盤について解説していますので、そちらもあわせてご確認下さい。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
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 関連情報 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編 (ブログ) - シリーズ第1回目！概要編として検証の目的・背景や環境周りをご紹介します。 【やってみた】Cloud Pak for Applications 導入してみた：Cloud Pak for Applications 導入編 (ブログ) - AWS 上に構築した Openshift 環境に Cloud Pak for Applications をインストールしてみました。 今、デジタルサービスに求められる必須要件とは!? アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 【外部ページ】 IBM Cloud Pak for Applications (IBMサイト)
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; }
AI 活用が期待される分野の1つが「需要予測」です。 工場での生産量や仕入れ、販売量から営業成績、不動産の価格変動など、従来はベテランスタッフの経験や勘に頼ることが多かった領域を AI で代替できれば大きな効果につながります。 AI・機械学習のなかでも導入が進んでいる需要予測ですが、いざ自社で導入するとなると懸念も大きいもの。 本記事では、需要予測に成功したケースと失敗したケースの違いとともに、その分岐点がどこにあるのかを考えます。 Index 「需要予測」では、精度UPのための試行錯誤が必須 成功・失敗の分岐点は「必要なデータが揃っているか」 データサイエンティストに代わるツールの登場で、AI導入のハードルは下がっている 「H2O Driverless AI」をPoC環境でお試しいただけます この記事に関するお問い合わせ 関連情報 「需要予測」では、精度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環境の利用をご希望の場合は、お取引のあるパートナー様経由での申請をお願いいたします。お取引のあるパートナー様が不明の場合はお問い合わせください。 ※競合製品取り扱い企業様のお申し込みについてはお断りする場合がありますので、予めご了承ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM Maximo Visual Inspection (旧 IBM Visual Insights) (製品情報) - D/L の経験とノウハウを、誰もが使いやすい GUI でのツールとして画像・動画に関するディープラーニングに特化して提供します。 AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) - よく聞かれるAIの5つのハードルについて、解決策とあわせて解説します。 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1) (ブログ) - Driverless AI で競馬の予測 (回帰分析) に挑戦しました。 【やってみた】超簡単データ分析！H2O Driverless AI を使ってみた (ブログ) - 「本当に初心者でもできるのかな？」ということで、今回実際にその Driverless 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; }
様々な用途への活用が進む機械学習。なかでも実用化が進んでいる分野の1つが異常検知です。 従来は人がチェックしていた異常を機械学習で検知することにより、負担軽減・精度向上などにつながると期待を集めています。 また、モデル生成などを自動化する機械学習ソリューションが登場、導入のハードルが大きく下がったことも後押しとなり、普及が本格化しつつあります。 本記事では、活用が進む現状とともに、導入の課題とその解決策までをまとめて紹介します。 Index 機械学習の異常検知では、何を検知できるのか？ 人材・データ・インフラ、異常検知導入を阻む3つのハードル 導入のハードルを大きく下げる、最新ツール・ソリューションとは 「H2O Driverless AI」をPoC環境でお試しいただけます この記事に関するお問い合わせ 関連情報 機械学習の異常検知では、何を検知できるのか？ 機械学習の異常検知はセンサーデータや画像データなどを学習させ、正常として定義したデータとマッチしないデータパターンを検知することで実現します。 大きく、期待されるデータと異なるデータが現れたときに検知する「外れ値検知」、異常が起きているタイミングを部分的に検知する「異常部位検出」、データの急激な変化を検知する「変化点検知」の3つの手法があります。 これらの手法や機械学習のモデルなどを用途にあわせて選択、チューニングすることで、精度を高めていくのです。 実際に活用が進んでいる事例として、製造業における検品作業があります。設備から出力されるセンサーデータから問題発生を検知するのとあわせ、画像データからキズや欠陥がないかを検知することで高い精度を実現。ベテランスタッフのスキル継承、検品作業の負担軽減、人件費削減など大きな効果につながっています。 ほかにも、小売業では店舗における人の振る舞いの異常検知や、売り場の状態（欠品や位置ずれなど）を監視・分析することで売り場メンテナンスの効率化につなげる事例、金融業における不正検知など様々なシーンで導入されています。 人材・データ・インフラ、異常検知導入を阻む3つのハードル このように活用が進む異常検知ですが、いざ自社で取り入れるとなるとハードルが高いもの。なかでもまず挙げられるのが「人材」です。 機械学習の手法やモデルから自社の目的にあったものを適用し、精度を上げるには専門知識が欠かせません。 これらの知識・スキルを持つデータサイエンティストが、自社にそろっている企業は少ないのではないでしょうか。 また、もう1つ課題となるのが「データ」。 機械学習を行うには適切なデータがそろっていることが前提であり、データ量が多ければ多いほど精度が上がります。ですが、「機械学習に使える適切なデータがない」「データ量が少ない」といったケースは多く、この準備に機械学習のワークロードのうち大半を費やすとも言われています。 最後に検討が必要なのがインフラです。 クラウドファーストが当たり前になった今、特に機械学習のような最新技術はクラウド上に構築するケースも多く見られます。 しかし、利用するデータは機密レベルが高いことが多く、精度を上げるためにデータ量を増やすとネットワークのコスト増にもつながります。また、機械学習では様々なデータで試行錯誤し精度を上げるため、その都度、大量のデータをクラウドにアップロードする必要があります。 予算・パフォーマンス・セキュリティのバランスを考慮すると、オンプレミスでの導入が有力候補に。オンプレミスでどのように機械学習の環境を構築するかも大きなハードルとなるのです。 導入のハードルを大きく下げる、最新ツール・ソリューションとは 上記の状況の解決策として今注目されているのが、モデル生成など従来データサイエンティストが担っていた部分を自動化し、コーディング不要で機械学習を開発できるツールです。 なかでも「H2O Driverless AI」は使いやすいUIで、精度の高いモデルを作成できることが強み。「どのデータが結果への影響が大きいか」といった重みづけも自動でおこなうため、データサイエンティストのような専門家がいなくても自社で導入することが可能になります。 もちろん「期待する結果を得るために、どういったデータが影響するか、そのデータはどこにあるのか」といったツールを活用する前段階の作業が必要なことは変わりません。ただし、これらは自社業務に密接にかかわるもの。社内業務に精通した人材で対応できるケースも多いでしょう。 こういったソリューションを利用することで、環境構築のハードルは大きく下がるはずです。オンプレミスでの導入が容易になれば、クラウドにはあげられなかったデータを分析できるなど活用の幅も広がります。 従来、人が手作業でしていた異常のチェックを機械学習で自動化することにより、業務効率化・コスト削減・負担軽減・品質向上など得られる効果は大きいもの。すでにこのようなツールを駆使し、機械学習による異常検知を導入している企業も増えています。「業務に活用するとしたら、どこに取り入られるのか」をまずは検討してみてはいかがでしょうか。 「H2O Driverless AI」をPoC環境でお試しいただけます 記事内で取り上げた「H2O Driverless AI」のPoC環境をご用意していますので、検証などの用途でご利用いただけます。ご利用いただき効果や使い易さなど、検証から導入の可否を判断できるのが大きなメリットです。 AIによる機械学習の導入をお考えの企業様には、要件定義前の検討段階でのご利用をおすすめしております。 PoC環境の利用をご希望の場合は、お取引のあるパートナー様経由での申請をお願いいたします。お取引のあるパートナー様が不明の場合はお問い合わせください。 ※競合製品取り扱い企業様のお申し込みについてはお断りする場合がありますので、予めご了承ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM Maximo Visual Inspection (旧 IBM Visual Insights) (製品情報) - D/L の経験とノウハウを、誰もが使いやすい GUI でのツールとして画像・動画に関するディープラーニングに特化して提供します。 AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) - よく聞かれるAIの5つのハードルについて、解決策とあわせて解説します。 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1) (ブログ) - Driverless AI で競馬の予測 (回帰分析) に挑戦しました。 【やってみた】超簡単データ分析！H2O Driverless AI を使ってみた (ブログ) - 「本当に初心者でもできるのかな？」ということで、今回実際にその 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; }
皆さま、こんにちは。てくさぽBLOGメンバーの佐藤です。 前回の続きになります。 【てくさぽBLOG】H2O Driverless AIをIBM Power System AC922で動かして競馬予想する（その1） 今回の目的 Driverless AIによって予測した内容と実際の結果を照らしあわせ、予測の精度が有用かどうか検証します。 前回、回帰分析が終了したところまで、書きました。 回帰分析した内容を確認します。 回帰分析結果を確認 イテレーション検証スコア まず、左下の赤枠の中、イテレーション検証スコアから確認します。 こちらの内容はどのくらいの精度で的中するかになります。 0に近づくほど精度が高くなります。 スコアリングについては前回記載した通りMAEやRMSEをご確認ください。 スコアが、2.6021という値ですので、仮にスコアが1として1着予測としても3着程度までが平均精度になります。 特徴量の重要度 次に下中央の特徴量の重要度です。 こちらの内容はどのようなデータを用いて予測するのか？になります。どのデータを元にしどのような割合で利用するのか、予測の調合データです。 上に行くほど高い重要度になりますので、より着順に関係性が深い値ということになります。 一番上の CVTE とは Cross Validation Target Encoding の略で、着順が低いともう一方の数値の傾向があるという関連性を見つけており、CID調教素点は調教データを数値化した指数となります。 つまり、調教が良い状態であれば結果(着順)も良いという事になります。 2行目にご注目ください。 Freq とありますが、Frequency Encoding の略になります。Frequency Encoding とは、こういう条件のときにこうなりやすいという確率です。 例えば、"芝で1枠だと1着になりやすい" といった傾向分析になります。 このケースの場合、"情報指数" "条件" "距離適性" という3つのデータの特定条件が揃うと着順に対して傾向がある事を Driverless AI が発見しています。 Driverless AI の特徴として個々の列データの特徴だけでなく、複数列のデータを組み合わせ新たな条件を作り出せます。 複数の列データの組み合わせ及び抽出条件を様々テストするというのは手作業でやるには大変な労力になります。また人間の目でみて関係なさそうな組み合わせからも有効な組み合わせを発見できる、これが Driverless AI の強味になります。 予測 回帰分析が完了しましたので次は予測してみます。 まずは予測したいファイルを用意します。 今回回帰分析したデータは2020年3月頭までになるため、それより後の日付のデータを用意します。 回帰分析したデータを予測データとして読み込むと予測は可能ですが、非常に高い精度で的中してしまいますので、回帰分析に用いたデータより未来の2020年4月～2020年5月16日までのデータを用意しました。 Experience 画面から他のデータセットを用いて予測を押し、データを選択します。 するとしばらく待った後ファイルダウンロードが始まりますので保存します。 Driverless AI の内部では回帰分析で生成された条件式に従い計算するという作業しますが、答え合わせの処理ですので、回帰分析する時間よりはかなり短い時間で終わります。 少し待った後ファイルダウンロードが始まりますので保存します。 保存したファイルを開くと最終列に "着順.predicted" という列が追加されています。 これが Driverless AI が予測した順位になります。 予測結果は小数点で表示されます。 検証 実際の結果と予測データを照らし合わせます。 的中率を算出します。 今回は3連複、ボックス6頭という Driverless AI の結果の数字が低い順に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サーバとで Driverless AI の回帰分析時間を比較してみました。 条件をそろえるためにどちらも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で競馬予測のまとめに入ります。 今回、出た予測結果に対して内容を掘り下げることをによって、適用条件を絞ることによりさらに高い精度で運用できる事を確認できました。Driverless AI の結果そのままではうまくいかない場合は範囲を絞って運用し、知見を貯め、追加のデータを用意し、徐々に適用範囲を広げていくのが良いと感じました。 また、AC922 Power9 の強力な演算性能により短時間で終わらせることも確認できました。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
