【てくさぽBLOG】IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編 – 手順詳細） | 特集・ブログ

一覧に戻る

2020年09月

【てくさぽBLOG】IBM Cloud Pak for Applicationsを導入してみた（OpenShift導入編 – 手順詳細）

ブログ

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パッケージのインストール

# 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 のインストール

<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

2024年04月08日

特集一覧 (ブログ、コラム他) [2024年度]

コーポレートサイトに掲載している2024年度のブログやコラムの一覧です。ハードウェアやソフトウェア製品に関するコラムやソリューション情報、それらの製品を使った弊社エンジニアのブログやホワイトペーパーなど皆様のビジネスにお役立てください。コラム・ブログ一覧カテゴリタイトル公開日ブログ【てくさぽBLOG】watsonx Assistant + Watson Discovery + watsonx.aiを連携してみた 24/04/08 アーカイブ 2023年度 2022年度 2021年度 2020年度 2019年度

コラム

ブログ

2024年04月08日

【てくさぽBLOG】watsonx Assistant + Watson Discovery + watsonx.aiを連携してみた

こんにちは。てくさぽBLOGメンバーの高村です。ビジネスへの生成AI の取り込みに注目が集まっている今日、watsonx.ai をどう活用すればいいのか、多くのお客様からお問い合わせ頂いています。そこで前回の「【てくさぽBLOG】IBM watsonx.aiを使ってみた（Part2）」では、watsonx.ai のユースケースとして Retrieval-Augmented Generation（以下 RAG）をご紹介しました。今回は、RAG の仕組みを利用し AIチャットボットを提供する「watsonx Assistant（以下 Assistant）」と検索エンジン機能を提供する「Watson Discovery（以下 Discovery）」、「watsonx.ai」を組み合わせた連携ソリューションをご紹介します。目次 AssistantとDiscoveryの連携 watsonx.aiを取り入れた連携 Assistant + Discovery + watsonx.aiを連携してみたさいごにお問い合わせ AssistantとDiscoveryの連携本来なら各製品を一つのブログで詳しくご説明したいところですが、今回は連携した結果についてのご紹介となりますので、Assistant と Discovery については今後のブログであらためてご紹介したいと思います。 Assistant は watsonx の大規模言語モデルが搭載され、自然言語の問い合わせを理解し、適切な回答を返すことができるチャットボット機能を提供する製品です。一方 Discovery はドキュメントから適切な情報を検索する検索エンジン機能、パターンや傾向を読み取る分析エンジンとしての機能を備えた製品です。 Assistant と Discovery を組合わせたユースケースでは Assistant にあらかじめ回答を用意してルールベースで回答させ、答えることが難しい問い合わせに対しては Discovery の検索結果を利用して回答します。 watsonx.aiを取り入れた連携上記の連携では Discovery の検索結果がユーザーに表示される仕組みとなっていますが、watsonx.ai を介して回答を提供することでDiscovery が得た検索結果をさらに整理し、より理解しやすい形での返答が実現できます。 Assistant + Discovery + watsonx.aiを連携してみた Assistant、Discovery、watsonx.ai を連携してみます。事前準備利用環境今回は IBM Cloud で提供される SaaS を利用して検証します。なお、Assistant と Discovery の Plusプランは30日間無償期間が付属されていますので、是非ご活用ください。 watsonx Assistant：Plusプラン（30日間無償期間あり、以降は有償） Watson Discovery：Plusプラン（30日間無償期間あり、以降は有償） watsonx.ai：Essentialプラン（有償）検証の目的検証では構築手順の他、以下の点を確認します。「Assistant + Discovery + watsonx.ai」と「Assistant + Discovery」の連携による回答の違いを比較言語モデルを変えて問い合わせを行い、回答の違いの比較実施手順以下の流れで検証を実施します。 Assistantのプロビジョニング Discoveryのプロビジョニング、検索対象とするデータの取り込み※取り込むデータは「IBM Power S1014 データシート」のS1014のPDF watsonx.aiのプロビジョニング Assistantの初期設定 Assistantのカスタム拡張機能からDiscoveryを繋げる Assistantのカスタム拡張機能からwatsonx.aiを繋げる Assistantアクションの作成、問い合わせの検証言語モデルを変えて問い合わせの検証検証実施 1. Assistantのプロビジョニングはじめに Assistant のプロビジョニングを行います。 IBM Cloud にログインし、カタログ画面から "Assistant" を選択します。ロケーションとプランを選択し「作成」をクリックします。しばらくすると以下の画面の様に、Assistant がプロビジョニングされます。 2. Discoveryのプロビジョニング次に Discovery をプロビジョニングします。カタログ画面から "Discovery" を選択します。ロケーションとプランを選択し「作成」をクリックします。しばらくすると以下の画面の様に、Discovery がプロビジョニングされます。※ここで、資格情報内にある「API鍵」と「URL」をメモに控えます「Watson Discoveryの起動」をクリックし「New Project +」をクリックします。 Project name に任意の名前を入力、Project type では「Conversational Serch」を選択し「Next」をクリックします。作成されたプロジェクトをクリックします。「Integration Deploy」をクリックします。「API Information」タブをクリックし「Project ID」をメモに控えます。次に検索対象の PDF を Discovery に取り込みます。「Manage collections」から「New collection +」をクリックし、「Collection name」に任意の名前を入力、「Select language」を「Japanese」に設定します。 Upload files の領域に PDF をドラッグアンドドロップして「Finish」をクリックします。アップロードが完了しました。次に、Smart Document Understanding機能（以下 SDU）を利用して PDF内のヘッダーやテキストなどのフィールドを定義します。 SDU は、PDFをはじめとする非構造化データの文書構造を理解して検索や分析の精度を向上させる機能です。例えばタイトルと定義した箇所を検索キーとしたり、検索対象をテキストと定義した箇所のみとするなど可能になります。「Identify Field」タブをクリックします。取り込んだ PDF が表示されるので右側の Field labels からヘッダー箇所やタイトル箇所などをドラッグアンドドロップして指定していきます。ページの定義が終わったら「Submit page」をクリックして次の頁を定義していきます。 SDU では数ページ指定すると自動的にヘッダー箇所やテキスト箇所を認識してくれるので、何ページもあるドキュメントには便利な機能です。今回は SDU を使って PDF の文書構造を定義しました。SDU以外の Discovery の機能については、また別の機会にご紹介したいと思います。 3. watsonx.aiのプロビジョニング ※watsonx.ai のプロビジョニング方法は「【てくさぽBLOG】IBM watsonx.aiを使ってみた（Part1）」をご参照ください。 4. Assistantの初期設定 Assistant の初期設定を行います。 Assistant を起動します。起動後、以下の項目を入力します。 Assistant name：任意の名前を入力 Assistant Language：「English」を選択※日本語を選択することが可能ですが、Assistant のスターターキットは英語での利用を想定しているため今回はEinglishを選択します Assistant の公開先を「web」に設定します。※"Tell us about your self" 以降はご自身の情報を入力ください入力後「Next」をクリックします。デフォルトのチャットUI を利用するため「Next」をクリックします。プレビュー画面が表示されるので「Create」をクリックします。（以下の画面は「Create」が隠れてしまっています）「Congratulations!」と表示されたら初期設定は完了です。 5. Assistantのカスタム拡張機能からDiscoveryを繋げる「Githubのassistant-toolkit」から "watson-discovery-query-openapi.jsonファイル" をダウンロードします。 Assistant のメニューから「Integration」をクリックします。下にスクロールし「Build custom extension」をクリックします。以下の画面が表示されるので「Next」をクリックします。「Extension name」に任意の名前を入力し「Next」をクリックします。先程ダウンロードした watson-discovery-query-openapi.jsonファイルをドラッグアンドドロップでアップロードします。以下の画面が表示されるので「Finish」をクリックします。追加した Extension の「Add +」をクリックします。以下の画面が表示されるので「Next」をクリックします。以下の画面が表示されるので、選択および入力します。 Authentication type：「Basic auth」を選択 Username：「apikey」と入力 Password：メモに控えたWatson DiscoveryのAPI鍵 discovery_url：メモに控えたWatson DiscoveryのURLから"http://"を除いた値 ※以下の画面ショットは discovery_url入力箇所が切れてしまっていますが、実際は「Servers」の下に discovery_url の項目があります以下の画面が表示されるので「Finish」をクリックします。 Extension が「Open」となっていることを確認します。これで watsonx Assistant と Watson Discovery が連携できました。 6. Assistantのカスタム拡張機能からwatsonx.aiを繋げる次に、Assistant のカスタム拡張機能から watsonx.ai を利用できるように設定します。設定には IBM Cloud の APIキーと watsonx.ai のプロジェクトID が必要です。取得方法は「【てくさぽBLOG】IBM watsonx.aiを使ってみた（Part2）」をご参照ください。なお、今回は東京リージョンで watsonx.ai をプロビジョニングします。 Github の「assistant-toolkit」から "watsonx-openapi.json" をダウンロードします。 Visual Studio Code などで東京リージョンの URL に編集し保存します。 Discovery の連携と同様に、Assistant のメニューから「Integration」「Build custom extension」をクリックします。以下の画面が表示されるので、任意の Extension name を入力して「Next」をクリックします。編集した watson-discovery-query-openapi.jsonファイルをドラッグアンドドロップでアップロードして「Next」をクリックします。以下の画面が表示されるので「Finish」をクリックします。追加した Extension の「Add +」をクリックします。以下の画面が表示されるので、選択および入力します。 Authentication type：「Oauth 2.0」を選択 Grant type：「Custom apikey」を入力 apikey：取得済みのIBM CloudのAPIキー Client authentication：「Send as Body」を選択 Header prefix：Bearer（デフォルト） Servers：https://jp-tok.ml.cloud.ibm.com（自動入力）以下の画面が表示されるので「Finish」をクリックします。 Extension が「Open」となっていることを確認します。これで Assistant と watsonx.ai が連携できました。 7. Assistantアクションの作成、問い合わせの検証 Github の「assistant-toolkit」から "discovery-watsonx-actions.json" をダウンロードします。 Assistant の「Actions」から「Global Setting」をクリックします。「Upload/Download」タブをクリックし、Uploadスペースに discovery-watsonx-actions.json をドラッグアンドドロップしてアップロードします。以下の画面が表示されるので「Upload and replace」をクリックします。以下の画面の通り、3つのアクションが作成されます。メニューから「Variables」「Created by you」をクリックします。「discovery_project_id」の値をメモに控えていた Discovery のプロジェクトID を入力し「Save」をクリックします。「watsonx_project_id」の値をメモに控えて置いた watsonx.ai のプロジェクトID を入力し「Save」をクリックします。「model_id」の値で watsonx.ai で使用する言語モデルを指定します。2024年2月29日に GA された日本語で訓練された Granite-japaneseモデルを使用するため、「ibm/granite-8b-japanese」を入力し「Save」をクリックします。（その他変数はデフォルト値とします）「Actions」から「Generate Answer」を選択し、「model_input」の値を以下の例の様に日本語に変更します。例： ("<s>[INST] <<SYS>>\nあなたは親切で、礼儀正しく、誠実なアシスタントです。常に安全を保ちながら、できるだけ役立つように答えてください。答えは簡潔に日本語で回答してください。回答には、有害、非倫理的、人種差別的、性差別的、有毒、危険、または違法なコンテンツを含めてはいけません。回答が社会的に偏見がなく、本質的に前向きであることを確認してください。\n\n質問が意味をなさない場合、または事実に一貫性がない場合は、正しくないことに答えるのではなく、その理由を説明してください。質問の答えがわからない場合は、誤った情報を共有しないでください。\n<</SYS>>\n\n質問に答えることで、次のエージェントの応答を生成します。タイトルが付いたいくつかの文書が提供されます。答えが異なる文書から得られた場合は、あらゆる可能性について言及し、文書のタイトルを使用してトピックまたは領域を区切ってください。与えられた文書に基づいて回答できない場合は、回答がない旨を記載してください。\n\n").concat(passages).concat("\n\n[question]: ").concat(query_text).concat("[/INST]") 以上で設定は完了です。さっそく Assistant から問い合わせをしてみます。右下の「Preview」をクリックします。チャットから S1014 の特徴について問い合わせしてみます。約18秒後に以下の回答が返ってきました。「Inspect」をクリックすると、Discovery の検索結果が以下の通り watsonx.ai に渡されていることがわかります。 <s>[INST] <<SYS>> あなたは親切で、礼儀正しく、誠実なアシスタントです。常に安全を保ちながら、できるだけ役立つように答えてください。答えは簡潔に日本語で回答してください。回答には、有害、非倫理的、人種差別的、性差別的、有毒、危険、または違法なコンテンツを含めてはいけません。回答が社会的に偏見がなく、本質的に前向きであることを確認してください。質問が意味をなさない場合、または事実に一貫性がない場合は、正しくないことに答えるのではなく、その理由を説明してください。質問の答えがわからない場合は、誤った情報を共有しないでください。 <</SYS>> 質問に答えることで、次のエージェントの応答を生成します。タイトルが付いたいくつかの文書が提供されます。答えが異なる文書から得られた場合は、あらゆる可能性について言及し、文書のタイトルを使用してトピックまたは領域を区切ってください。与えられた文書に基づいて回答できない場合は、回答がない旨を記載してください。[title]: IBM Power S1014 柔軟かつセキュアなハイブリッドクラウド・インフラストラクチャーで俊敏性を実現[document]: 1 コア当たり 4 つの M a t r i x Math Acceleratorによる迅速なAI推論のために洞察と自動化を合理化業界標準のDIMMより2倍優れたメモリーの信頼性と可用性を提供 IBM® Power® S1014 は、1ソケット、4U Power10プロセッサーをベースにしたサーバーで、IBM AIX®、IBM iまたは Linux®上のビジネス・クリティカルなワークロード向けに設計されています。Power S1014を使用することで、ワークロードはより少数のサーバーに統合され、ソフトウェア・ライセンスの数、電力と冷却のコストを削減します。Power S1014サーバーは、プロセッサー上でのメモリー暗号化を使用してエンドツーエンドからデータを安全に保護し、ラック型またはタワーフォーム・ファクターで購入できます。プロセッサー・レベルでのメモリー暗号化と、POWER9 と比較してすべてのコアで4倍の暗号化エンジンによりコアからクラウドまでのデータを保護ますます高度に分散した環境に存在するデータには、もはや境界線を設定することは不可能です。 [question]: S1014の特徴は?[/INST] Assistant と Discovery のみの連携で検索した結果は以下の通りです。watsonx.ai を使用した方がより簡潔で分かりやすい回答を得られることが分かります。 8. 言語モデルを変えて問い合わせの検証言語モデルを "llama-2-70b" にして同様の問い合わせをしたところ、約24秒後に回答が返ってきました。箇条書きで丁寧な印象です。言語モデルを "elyza-japanese" にした際は10秒ほどで回答がありました。主語として「S1014の特徴は」とあることで、問いに対する回答が分かりやすくなっています。言語モデルを変えて試した結果、llama-2-70B は箇条書きで回答し丁寧な印象を受けましたが、回答が得られるまでに24秒かかりました。一方 Granite-japanese や elyza-japanese はシンプルな回答を生成し、Granite-japanese は18秒、elyza-japanese は10秒というより短い時間で回答を得られました。 Watson Discovery の検索結果に基づき watsonx.ai で回答を生成するので、ある程度時間がかかると予想していましたが、elyza-japanese は速い回答で主語を添えてわかりやすく回答してくれました。また、llama-2-70B は汎用的で使いやすいモデルですが、プロントで「日本語で回答して」と指示をしても問い合わせ内容によっては英語で回答することがありました。日本語の回答精度を求める場合は、Granite-japanese や elyza-japanese を使用した方が精度の高い回答を得ることができます。モデルを変えて問い合わせてみると、モデルごとに得意なタスクが異なることがわかりました。数百億のパラメータで訓練された大規模言語モデルを一概に選択するのではなく、言語やタスクの特性に合わせて最適なモデルを選定することが重要になりそうですね。さいごにいかがでしたでしょうか。Github から提供されているスターターキットを使って Assistant、Discovery、watsonx.ai を繋げてみましたが、ほどんど躓くことなく UI から簡単に設定することができました。接続自体に高度な難しさは感じませんでしたが、問い合わせに対して正確な情報を得るためには Assistant の検索設定を調整する必要があります。今回は1つの PDFファイルの検索を行いましたが、複数の PDFファイルから情報を引き出す際には Assistant で query を設定することで特定の PDFファイルからの検索が可能です。このように PDF などの非構造化データを検索対象として精度の高い回答を得るには、Discovery において文書の構造を明確に定義し、Assistant の検索設定を調整することが必要です。実際にヘルプデスクなどの Webチャットで利用する場合は、Assistant にあらかじめ用意した回答をルールベースで回答させ、それでも解決できない問い合わせについては Discovery を通じて検索を行い、watsonx.ai を用いて回答を生成するという流れが効果的です。ただし、生成AI　によって生成される回答は常に”100%正確な回答”ではないので、より高い精度の回答を追求するためにはプロンプトの調整などチューニングを施すことが必要です。その結果、より使いやすい Webチャットの実現が期待できます。お問い合わせエヌアイシー・パートナーズ株式会社E-Mail：nicp_support@NIandC.co.jp .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A 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_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }

ブログ

2024年01月16日

特集一覧 (ブログ、コラム他) [2023年度]

コーポレートサイトに掲載している2023年度のブログやコラムの一覧です。 (さらに…)

コラム

ブログ

2024年01月16日

【イベント開催レポート】IBM watsonx.ai ハンズオンセミナー

こんにちは。ソリューション推進部です。 2023年12月12日に、エヌアイシー・パートナーズ株式会社として初めてのハンズオンセミナー『「IBM watsonx.ai 」を利用したRAGのハンズオンセミナー』を開催しました。今回のハンズオンセミナーは、以下の2つのことを目的として行いました。パートナー様に製品の紹介とハンズオンを合わせて体験いただくことで、製品をより深く知っていただくこと製品を活用したビジネスの新たな応用の可能性を見つけ出していただくこと私たちのチームでは、パートナー様にご紹介・ご説明する製品を「実際に触ってみること」を大切にしています。これは私たち自身の技術力の向上という目的もありますが、パートナー様に私たちのリアルな経験を交えながら製品のご説明をすることが、お客様の具体的な課題発掘や案件創出に繋がっていると考えているためです。今回のハンズオンを通して、パートナー様ご自身が製品の価値を体感しご理解いただくことで、新しいビジネス展開のイメージを創出するお役に立ちたいと考えました。それでは、今回実施したセミナーの内容について簡単にご紹介いたします。目次レポート watsonx.ai紹介講義ハンズオン実施 IBMさまによる最新情報紹介・講義さいごにお問い合わせレポート 1. watsonx.ai紹介講義ハンズオンを実施する前に、watsonx.ai と RAG についての講義を行いました。国内では生成AIビジネスが加速し、競争力やセキュリティなどの課題が増えています。これらの課題を解決する製品として、IBM watsonx をご紹介しました。 watsonx は「watsonx.ai」「watsonx.governance」「watsonx.data」という3つの製品から成り立っています。watsonx.ai は、基盤モデルをベースとした AI開発スタジオです。ここでは、IBM が信頼できるデータを用いて事前に学習した基盤モデルや Hugging Face, Inc.* と連携したオープンソースの基盤モデルが利用可能で、ビジネスの状況や要件に応じて最適な基盤モデルを選択することが可能です。また、RAG についての概念や利点、活用が期待されるシーンもご説明しました。RAG を用いた具体的なユースケースとしては、IBM Watson Speech to Text や Watson Discovery、watsonx.ai を活用したコールセンター業務の事例や、watsonx Assistant や Watson Discovery、watsonx.ai を活用した ECサイトの問い合わせの事例を取り上げました。時間の制約からこれら2つの事例しかご紹介できませんでしたが、今後、watsonx.ai を活用した多様な事例を私たち自身も理解し、パートナーさまと共に議論を深めていきたいと思います。 *Hugging Face, Inc.：機械学習アプリケーションを作成するためのツールを開発しているアメリカの企業。 2. ハンズオン実施ハンズオンでは、受講者の方々に「RAG」を活用した watsonx.ai の Foundation Model（LLM）への問い合わせを体験していただきました。 RAG とは「Retrieval-Augmented Generation」の略で、LLM への問い合わせをする際に、事前に用意したベクターストアへデータ（今回はPDF）を取り込んでおき、問い合わせプロンプトをもとにベクターストアを検索し、その結果を付与して LLM へ問い合わせを行う、というテクノロジーです。 RAG を使うことで、一般公開されていない社内情報を活用して LLM を利用することが可能となるため、自社での利用やお客様の課題を解決するための方法として有効であると考えています。ハンズオンの環境につきましては、準備に時間をかけずスムーズに始められるよう、事前に弊社にて PC や RAG を利用するための Jupyter Notebook を用意いたしました。また、watsonx.ai では複数の Foundation Model を利用できるため、複数のモデルを使って挙動の違いを確認してみたり、取り込む PDFファイルを追加することで回答がどう変わるのか、など、ご自身で自由に検証をする時間を多く設けました。皆さまそれぞれに前提スキルは異なっていたかもしれませんが、「体験の時間が足りない…」ということはなかったかと思います。今回ベクターストアへ取り込むのは PDF のみとしましたが、テキストファイルや PowerPoint なども取り込むことができるので、応用できる使い方が非常に広いということを理解いただけたのではないかと感じています。 3. IBMさまによる最新情報紹介・講義日本アイ・ビー・エムデータ・AI・オートメーション事業部四元さまに「watsonx」に関して、最新事例と製品アップデート情報の2本立てで講義をしていただきました。事例においては、IBM社内の watsonx活用事例（AskIT）は特筆すべきと言えるでしょう。 AskIT は、IBMの自然言語処理（NLP）能力を活かし、30万件を超えるサポートチケットから抽出された知見をもとに、重要なサポートトピックに迅速に対処する AIアシスタントとして開発されたそうです。このツールは4ヶ月で133,000人の IBM社員に利用され、問い合わせの75%以上が AI によるチャットで解決されるなど、非常に大きな成果を上げています。製品アップデート情報のメインは、12月に発表された「watsonx.governance」でした。 AI を組織として採用するためには倫理感のある意思決定が必須であり、watsonx.governance は AIガバナンスとして以下の3つの機能を提供する製品である、というご説明をいただきました。 AIライフサイクルを通してAIモデルの実態を把握するための「モデル・インベントリ」 AIの性能や課題の管理などを行う「評価・モニタリング」総合監視画面を提供しリスクを可視化する「モデル・リスクガバナンス」モデル・インベントリでは、他社の AI商品である「Amazon SageMaker」「Azure Machine Learning」などの AIモデルも合わせて管理・監視できることが非常に興味深いです。 watsonx は、AIワークフローを一貫してサポートすることで倫理的かつ透明性の高い AI利用を可能にしています。これらの技術革新は私たちが直面している数多くの課題に対する解決策を見出し、先進的なビジネス環境を促進していく上での重要なステップと言えるでしょう。日本アイ・ビー・エム株式会社データ・AI・オートメーション事業部四元さまさいごにセミナー後には、参加いただいたパートナーさまとご支援いただいた IBMさまとの懇親会を開催いたしました。当懇親会を通してパートナー様の生成AI に対する取り組みや課題を直に伺うことができ、大変有意義な場となりました。 2023年12月18日に弊社は10周年を迎えました。10年間で培った経験を糧にし、今後さらに新しい取り組みにチャレンジしていきたいと考えております。本年も、ブログを通してパートナーの皆さまへ様々な情報をお届けさせていただきます！今後ともどうぞよろしくお願いいたします。懇親会会場お問い合わせエヌアイシー・パートナーズ株式会社E-Mail：nicp_support@NIandC.co.jp .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A 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_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }

ブログ