Kubernetes 特長と最新動向 IBM社員にも知って欲しいk8sの利用価値 日本アイ・ビー・エム株式会社 クラウド事業本部 高良 真穂 2018年1月30日 OSSユーザーのための勉強会 < OSS X Users Meeting > #22 Dockerとkubernetes https://www.scsk.jp/event/2018/20180130.html

高良 真穂 （たから まほ） 日本アイ・ビー・エム株式会社 クラウド事業本部 Watson & Cloud Platform テクニカルセールス お話する人 IBM社内のセールスからは IaaSのスペシャリストと見なされ事が多いのですが、 本来はソリューションを考えるITアーキテクトなので、 お客様にとっての価値を追い求めてフル・スタックで取り組んでいます。

今日はOSS勉強会ですから、 IBMのPRは少なく Kubernetes について 知識と利用価値の お話に努めたいと思います

Kubernetes とは • Google で 自社のため開発されたコンテナ・クラスタ管理ソフト Borg をベースにOSS化 • CNCFへ寄贈され、OSSプロジェクトとして、多数の企業が参加して推進中 • Apacheライセンス 2.0のもと配布 • 2014年7月7日に初版リリース､ 現在の最新版が1.9 (2017/12/15 GA) • ソースコード https://github.com/kubernetes ベースとなったBorgは10年以上に渡って、自社のサービスをコンテナ で提供してきており、毎週10億以上のコンテナを起動しているとされ ています。 ギリシャ語で「操縦士」や「パイロット」を表す Kubernetesのロゴ ネイティブ・スピーカの発音では、 クーベネティス や クベルネティス みたいです。

Kubernetes を一言で表現すると Kubernetesは、 コンテナの運用自動化のために開発されたOSS 主な機能 • コンテナ化したアプリをクラスタ運用する • 稼働中にアプリの実行基盤をスケール（拡大または縮小）する • 新機能をサービスをロールアウト（無停止でリリース）する • CPUやメモリなどハードウェアの利用量を制限する • ログ収集、負荷分散、ジョブ、監視などの運用機能を提供 特長 • 可搬性：パブリック、オンプレミス、ハイブリッド・クラウド、マルチ・クラウドでの動作 • 拡張性： モジュール化、追加／接続／構成が可能 • 自己修復：再配置、再起動、複製、スケーリング、リリースを自律的に実行

Kubernetes は長いので Kubernetes k8s 1 2 3 4 5 6 7 8 省略

階層の中でのKubernetesの概念的な位置づけ • DockerはSwarmとKubernetesの統合を発表 DockerCon EU 2017 Physical Infrastructure Layer 1 Virtual Infrastructure Layer 2 Operating System Layer 3 Container Engine Layer 4 Orchestration/Scheduling Service Model Layer 5 Development Workflow Layer 6 Docker Swarm IBM Cloud Bare Metal Network Storage IBM Private Cloud

Kubernetesのアーキテクチャ • https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/architecture.md

相模湖で悟ったKubernetesとDockerの関係 !? くじら丸(Docker) を操る操縦士(Kubernetes) 津久井振興株式会社 振興ボード くじら丸 http://sagamiko-boat.com/

メガクラウド各社 Kubernetes 対応状況

© IBM Corporation 11 Kubernetesを 広めて勢力図を 変えるぞ OSSなら参道して シェアを取りに 行くぞ！ 複合環境でも 便利♪ 豊富な資金力で 独走を維持するぞ ロックインから 解放だ！ チャンス♪

Kubernetesが 解決する課題

Kubernetesが解決する課題 1. コンテナを共通的な基盤で本番運用したい 2. 短いサイクルでリリースを繰り返したい 3. サーバー資源の無駄を減らし、効率を高めたい

Kubernetesが解決する課題 • コンテナを共通的な基盤で本番運用したい • docker-compose を利用したアプリ開発が定着、本番環境もコンテナでリリースしたい • 本番ではコンテナを再作成する事無く、DBの接続先を変えたい。 • SWスタックを気にせずに、アプリが安定して動作する不変のプラットフォームが欲しい OSカーネル ライブラリ SWパッケージ ミドルウェア アプリケーション OSカーネル 開発環境 OSカーネル ライブラリ SWパッケージ ミドルウェア アプリケーション OSカーネル 本番環境 工場の生産ラインの様に 自動化して連続的に ソフトウェアを生産する基盤 コンテナ コンテナ テスト完了した コンテナを K8sの本番環境へ 可用性＆クラスタ スケーラビリティ モニタリング

Kubernetesが解決する課題 • 短いサイクルでアプリのリリースを繰り返し、継続的に改善を進めるこ とで、他社より優位に立ちたい • スマホアプリでユーザー数が多いので止められない。変更を無停止でリリースしたい。 • リリース後に問題が発覚したら、前バージョンに無停止でロールバックしたい。 • A/Bテストとして一部のユーザーだけにリリースして、利用者の反応を確かめたい。 1～4 週間 毎日 デイリー スクラム スプリント サイクル リリース バックログ TARGET Devices 業務をシステム化で自動化したり 、改革するものではなく あらゆるデバイスを対象に市場の ニーズを発見するため試行錯誤で 洗練が最短パス アジャイル／スクラム に実行イメージ

Kubernetesが解決する課題 • コンピューティング資源の無駄を減らし、高効率な運用をしたい • 特定クラウドに縛られて、リスクを高め、技術者の存在価値を無くしたくない。 • オンプレとクラウドを自在に使い分け良い処取りしたい。 • アプリとサーバーの結合を減らし、理想的なアプリの稼働環境にしたい。 A社クラウド 仮想サーバ 抽象化 コンテナ化 実現したい事に対して 環境個別の事を 考えなくても良い 共通化された運用環境 アプリが依存するSW パケージをOSごと 一緒に持ち運べる 安定の不変の実行環境 B社クラウド 仮想サーバ 自社オンプレ プライベートクラウド ベアメタルサーバ

ココを抑えれば もう怖くない Kubernetesの要点

k8sの要点 k8sの三大構成要素 K8sの３大構成要素は３つ • マスターノード k8sクラスタの制御 パブリック・クラウドの場合はマネージド • ワーカーノード アプリのコンテナの動作、ノード数可変 • コンテナ・レジストリ コンテナ保管場所 Master Node Worker Node Public Network クライアント Container Registry コンテナ イメージ登録 クラスタ 操作 User IBM流では ワーカーノードと呼び k8sプロジェクトでは、単にノード

k8sの要点 Docker, k8sクラスタ, クラウドの関係 • ３系統のコマンドを利用して操作 • dockerコマンド コンテナのビルド、レジストリへの登録＆取出し • kubectlコマンド アプリのデプロイ、ロールアウト／ロールバック • gcloud/bluemixコマンド クラスタ構成、ノードの追加/変更/削除、FW/LB設定 Master Node Worker Node Public Network Container Registry Services Cloud Service Storage Service Load Balancer Firewall k8sクラスタ制御 kubectlコマンド User （オプション） Server Worker Nodeは 仮想サーバーを ベースに構成される

k8sの要点 アプリのデプロイ サービスを開始するまでの作業は３ステップ 1. アプリのコードを開発してコンテナ化 2. コンテナをコンテナ・レジストリへ登録 3. ３種のYAMLを利用してデプロイ • デプロイメント • レジストリのコンテナ・イメージの指定 • 起動するコンテナ数の指定 • サービス • クラスタIP作成 • 公開用ロードバランサ プライベート レジストリ パブリック レジストリ コンテナを ダウンロード アプリ開発者 サービス運用 技術者

k8sの要点 階層構造 • Node － デプロイメント － ポッド － コンテナ の階層構造の上で、コンテナ化したアプリを運用 • ポッドは複数のコンテナが動作でき、一つの内部IPアドレスを持つ、一つの仮想マシンの様な存在 • しかし、ポッド単位で起動と破棄され、永続データは保持できない一時的な存在 アプリ コンテナ ポッド デプロイメント Webサーバ コンテナ ポッド ポッド デプロイの基本単位 クラスタ・ネットワーク上に IPアドレスを持つ 実行単位 dockerやrktなど コンテナ Worker Node Worker Node Worker Node Nodeに分散してデプロイ ポッドの レプリカによって 高可用性構成 ポッド数を維持 その他資源との 接続を制御 コンテナ レジストリから 取得したイメージ 仮想サーバー ベアメタル

• Podは、なんの短縮形？ k8sうんちく

k8sの要点 クラスタ内部ネットワーク • ポッドはクラスタ・ネットワークに、ポッドが接続され、Worker Nodeの境界を越えて通信できるノード横断ネット • しかし、ポッドのIPアドレスでは外側と通信はできない内部専用、ポッド作成ごとにIPアドレスを自動付与 Node #1 User Private VLAN User Public VLAN Node #2 Node #3 Docker Container Pod 8c8lj Docker Container Pod dqbr2 Docker Container Pod t7jfh クラスタ・ネットワーク Node IP: 10.132.253.38 Node IP: 10.132.253.30 Node IP: 10.132.253.17 Pod IP: 172.30.11.51 Pod IP: 172.30.180.147 Pod IP: 172.30.170.233 ReplicaSet ID: 7f868cb77d パブリックは IBM Cloudの実装で 他社では異なる構造です

k8sの要点 内部ロードバランサー • k8sは、ポッドのクラスタの代表IPを作り要求を分配するサービスを提供 • kubectl コマンドからYAMLを投入して”サービス”を定義する • サービス作成時に、kube-dnsにサービス名を登録、クライアントからDNS名で参照可能 • フロントエンドの接続先バックエンドは、YAMLの定義 “セレクタ”で指定 Container express1:1.0 ポッド Pod IP: 172.30.11.58 ポッド Pod IP: 172.30.180.239 ポッド Pod IP: 172.30.170.159 Container ポッド Pod IP: 172.30.11.46 アプリケーション（デプロイメント） クライアント （クラスタ内） クラスタの代表IP Cluster IP: 172.21.127.174 Port: 3000 name: express-app-svc すべて、Cluster-NetworkのIPアドレスです。 Container express1:1.0 Container express1:1.0 デプロイメント レプリカ数 3 他のコンテナから要求 をポッド分散する フロントエンド バックエンド サービス • ポッドは起動と破棄で再起 動が無い • 起動時にIPアドレスが付与 • 起動のたびにIPが変わる サービスが必須な理由

• Kube-proxyはリクエストの振分け先を固定できるの？ （答えはNo） k8sうんちく pod pod kube-proxy pod pod kube-proxy pod pod kube-proxy Worker Node #1 Worker Node #2 Worker Node #3 リクエストはランダムにポッドへ割振られる PHPのアプリでセッションを維持するケースでは キャッシュやDBにセッション情報を保持する必要がある デフォルト kube-proxy mode: iptables のケース

k8sの要点 外部公開ロードバランサー • k8sクラスタから外へ公開するロードバランサのサービスを提供 • NodePort ノードのポート番号で公開、KubeProxyと連携して複数のポッドへアクセスを分配します • LoadBalancer クラウドプロバイダのロードバランサを使用して外部にサービスを公開 • Ingress 各社クラウドの実装でロードバランサーとHTTPSなどの機能で公開 ポッド 外部向け代表IP Container nginx インターネット上 フロントエンド サービス ポッド Container nginx ポッド Container nginx バックエンド 内部クラスタの代表IP Cluster IP: 172.21.127.174 Port: 3000 name: express-app-svc サービス Container express1:1.0 ポッド Pod IP: 172.30.11.58 ポッド Pod IP: 172.30.180.239 ポッド Pod IP: 172.30.170.159 Container express1:1.0 Container express1:1.0 NodePort LoadBalancer Ingress SW名で例えば ウェブサーバ nginx アプリ PHP + FPM Redis, MySQLなど キャッシュやデータベース デプロイメント デプロイメント

k8sの要点 オートスケール • CPUの使用率の閾値越えで、ポッド数を増加して処理能力を増強 • 反対に閑散な状態となれば、ポッド数を縮小 • ノードの増強は手動のケースありに注意、ノードは余裕をもって運用は必須 デプロイメント Worker Node Worker Node Worker Node デプロイメント Worker Node Worker Node Worker Node ポッド ポッド ポッドのCPU使用率 が閾値を超えると レプリカ数 を増やして増強 ポッド ポッド ポッド コンテナ コンテナ コンテナ コンテナ コンテナ 追加

k8sの要点 自己回復 ノード障害に対して、サービスは無停止で継続可能 • ワーカーノードの障害に対して、必要数のポッドを起動して処理能力を補う • N+1構成の様に能力的に余裕もった設計が必要であるが、ポッドの再配置は自動 デプロイメント Worker Node Worker Node Worker Node デプロイメント Worker Node Worker Node Worker Node ポッド ポッド ポッド ポッド コンテナ コンテナ コンテナ コンテナ 起動 喪失 障害 停止 障害 停止

k8sの要点 無停止ロールアウト （アプリ更新） • 無停止で安全にアプリケーションの更新（ロールアウト）を実行できる • ロールアウト 現行でサービスしているサービスの新バージョンをリリース • ロールオーバ 複数の更新を要求するケースで、無駄なステップを省く • ロールバック 何らかの理由でデプロイしたアプリを前のバージョンに戻す • スケール ポッドのCPU使用率の閾値超えでレプリカの数を増加 終了中 終了中 終了中 終了中 起動中 起動中 本番中 起動中 本番中 本番中 本番中 本番中 本番中 本番中 終了中 終了中 本番中 本番中 本番中 本番中 本番中 時間の流れ ポッド レプリカ数 アプリv1からアプリv2へ ロールアウトする時の k8sクラスタ内の動き 本番中のポッド数２個をキープしながら切替を進行 アプリ Ver 1.0 のポッド アプリ Ver 2.0 のポッド ポッドの中にコンテナの セットが格納されます

k8sに関する資料を読むと、稼働中のコンテナを更新する意味で、Rolling update と 書いてあることが多いのですが、Rolloutは間違いではありませんか？ • Rolling update （ローリング・アップデート） • ReplicationControllerとPodで更新を実行しますが、現在は Deployment の利用が推奨されています。 • kubectl rolling update • Rollout （ロールアウト） • Deploymentは現在推奨される方法で、ローリング・アップデートが完了した後でも、以前のリビジョ ンへ、ロールバックできるなどの優れた機能があります。 • kubectl apply –f deploy.yaml • kubectl rollout status k8sうんちく おすすめ (kubectl rolloutコマンドは無い) https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/

k8sの要点 永続ストレージの利用 • K8sのコンテナ環境ではデータをストレージに永続的に保管できます。 • クラウド・プロバイダのストレージ・サービスを利用できます。 • YAMLファイルに、”kind: PersistentVolume” や “kind: PersistentVolumeClaim” とすることで、既存 ボリュームをマッピングしたり、新規に作成するなどの永続ストレージの利用ができます。 • クラウド・プロバイダや既存ストレージ系プロトコルのための複数のプラグインが提供されています。 Master Node Worker Node Cloud Service API Storage Service ポッド Worker Node DBサービス コンテナ ポッド k8sクラスタ制御 kubectlコマンド User 参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes DBサービス コンテナ

k8sの要点 名前空間を利用したクラスタの区分利用 • ネームスペースを利用して、無停止で大幅なシステム更改ができます。 • 従来では無停止切替のために、同じ処理能力の環境を構築して、スイッチしていた。 • K8sはクラスタ内をネームスペースで分割できるので、無停止切替のコストや工数を大幅に削減 • アプリの更新だけであれば、ロールアウト／ロールバック機能を利用して安全に無停止切替 Worker Node Worker Node Worker Node 仮想 サーバ 仮想 サーバ （仮想サーバ） （仮想サーバ） （仮想サーバ） 本番機 Aグループ 本番機 Bグループ 仮想化 Hypervisor ロード バランサ スイッチ スイッチ Name Space : Blue Name Space : Green 従来の 無停止切替 k8sの 無停止切替 リクエスト リクエスト ワーカーノードの一時的な増強、ポッドの片寄せ可能

k8sの要点 外部資源の名前空間別の割当て • IBM Cloud の マネージドDBサービスやWatson APIサービスを利用する場合 • コンテナのレベルでは、環境変数として、接続先や認証情報を提供（起動順序制約あり） • ポッドのレベルでは、ボリュームとして接続先情報が読み取り可能 • k8sクラスタの外にあるサービスを利用する場合 • External サービスを定義することで、DNSでアドレス解決が可能 Worker Node Worker Node Worker Node （仮想サーバ） （仮想サーバ） （仮想サーバ） スイッチ Name Space : Blue Name Space : Green リクエスト 新環境用外部サービス Watson API インスタンス マネージド データベース インスタンス Watson API インスタンス マネージド データベース インスタンス Bare metal Server GP-GPU Optane 外部 リソース 現用外部サービス Bare metal Server GP-GPU Optane 外部 リソース アプリコードと 外部サービスの 対応を 名前空間で変更

• ダウンタイムを最小にする技術 k8sうんちく https://martinfowler.com/bliki/BlueGreenDeployment.html ソフトウェアをテストの最終段階からプロダクションへともって いくカットオーバーそれ自体にある。 通常はこの作業を迅速に行うことで、ダウンタイムを最小化しな ければならない。blue-green deploymentはこれを、可能な限り同 じにした2つの本番環境によって確実に行うようにしている。 http://www.publickey1.jp/blog/14/blue-green_deployment.html Blue-Greenデプロイ https://martinfowler.com/bliki/CanaryRelease.html カナリア・リリース https://www.asahi.com/articles/ASK3Q4DBZK3QUZOB004.html サリン事件 カナリアを 手にする 捜査員 一部にリリースして様子を確認しながら段階的に範 囲を拡大するリリース手法で、変更に伴う様々なリ スクを軽減する。 流量の割合で決める方法、クライアントの種類で限 定する方法など、目的に沿った使い分けがある。 鳥は効率良く酸素を吸収 できるので、微量な 毒ガスでも敏感に反応する

k8sの要点 ジョブ • Kubernetes はスケジューラとも呼ばれるが、ジョブネットは書けない。 • YAMLで定義してバッチ処理を実行 • K8sはスケジューラーと言われるが、ジョブ・スケジューラの様なジョブネットは作れない • ジョブのタイプ • 一個のポッドで順次に業務ステップを実行するバッチはポッド内で動くシェルで実現 • 並列度を大きくして、一度に複数のポッドで並列処理はYAMLで定義 • でもMPIの様なタイプには不向き • ジョブの終了 • シェルやコマンドが終了コード０以外は異常終了とみなす • 異常終了時の取り扱いは選択できる • 成功するまで繰り返す • どれか一個でも成功したら成功として完了する • 指定回数だけリトライして、閾値を超えたら失敗とする • ポッドが終了後もジョブは残り続けログを保持し参照できる。 • リトライのタイプ • 失敗したポッドを破棄して、ポッドを作成する方法 • ポッドは維持しながら、コンテナだけを再実行する方法

k8sの要点 分散環境のモニタリングと洞察 • 大量のポッドを運用するには、モニタリングが課題 • 二つのレベルの監視 • アプリケーション・レベル • Kubernetes クラスタ・レベル 時系列データベース 可視化ツール 全文検索エンジン 通知ツール アプリケーション Node Cloud Master Node / Deployment / Pod / Service 情報発生源 監視対象 メトリクス・コレクタ 把握＆洞察 発報 コンテナ・クラスタ監視 基本的アーキテクチャ

k8sの要点 分散環境のモニタリングと洞察 • 主流となっている分散システムのモニタリング・ツール telegraf Diamond Python-daemon influxdb-python mtail node_exporter opentsdb-goclient td-agent リアルに近い モニタリング ログ分析 と監視 時系列データベース メトリクス・コレクタ 可視化ツール 可視化ツール 全文検索エンジン 情報 発生源

• KibanaとGrafanaはブラウザで閲覧する視覚化ツール k8sうんちく Kibana Grafana ・Elasticsearchの視覚化ツール ・ログ分析など、対話的に操作しながらの発見に向く ・豊かな表現形式に対応 ・時系列DB (time series database)の視覚化ツール influxDB, Prometheus, Graphiteなどの時系列データを視覚化 ・設定を保存して繰り返し利用するダッシュボードに向く ・シンプルな操作 特徴 特徴

k8sの要点 分散環境のモニタリングと洞察 • k8sクラスタ・レベルのモニタリング リアルに近い モニタリング ログ分析 と監視 時系列データベース メトリクス・コレクタ 可視化ツール 可視化ツール 全文検索エンジン Master Node Worker Node Heapster kubelet cAdvisor kubelet cAdvisor kube-state-metrics

k8sの要点 分散環境のモニタリングと洞察 • Kubernetesのアプリケーション・レベルのモニタリング アプリ コンテナ ポッド デプロイメント コレクタ用 コンテナ Worker Node Worker Node Worker Node リアルに近い モニタリング ログ分析 と監視 時系列データベース 可視化ツール 可視化ツール 全文検索エンジン 共有ボリューム Sidecar ✓ 監視項目を収集して転送するためのコン テナを同一ポッド上で稼働させる ✓ このコンテナはサイドカーと呼ばれる レプリカセット

k8sの要点 分散環境のモニタリングと洞察 Web UI (Dashboard) • K8sクラスタ状態を把握 • 異常停止のポッド発見 • 名前空間 • CPU,RAM利用状態 • クラスタ状態 • デプロイメント • ポッド／レプリカ • サービス • ジョブ • ストレージなど • 全クラウドで共通なユーザーI/F • GCP/AWS/Azure/IBM

k8sの要点 PCで動作するミニ環境 minikube Minikubeは、ローカル環境で動作するKubernetesクラスタ Kubernetesプロジェクトの元で提供され、最新バージョン https://github.com/kubernetes/minikube 動作要件 • kubectlコマンド • Operating System • macOS Hyperkit driver, xhyve driver, VirtualBox, or VMware Fusion • Linux VirtualBox or KVM • Windows VirtualBox or Hyper-V • VT-x/AMD-v virtualization must be enabled in BIOS • Internet connection on first run １Nodeのクラスタを作成 学習、検証、開発、実験などに利用できる minikube のロゴ Minikube uses libmachine for provisioning VMs, and localkube (originally written and donated to this project by Redspread) for running the cluster.

まとめ

まとめ • Kubernetes は、 • コンテナ・オーケストレーションのOSS • CNCFがプロジェクト運営 • 2017年 メガ・クラウド各社がKubernetesに対応 • 様々なOSSツールと組み合わせて高効率運用を実現できる • 解決する課題 • コンテナ本番環境、クラスタ化、冗長化、オートスケール • クラウド各社＆オンプレで共通オペレーション、IT基盤を抽象化して共通化 • アプリ無停止のロールアウト＆ロールバックを提供 • CD/CI､DevOpsの実践環境 • モノシリックなアプリでも、コンテナ化することで、k8sの価値に与れる

本講演および資料は、セッション発表者によって準備され、独自の見解を反映したものです。それらは情報提供の目的のみで提供されてお り、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。 本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にか かわらずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかな る損害が生じた場合も、IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセ ンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条 項を変更することを意図したものでもなく、またそのような結果を生むものでもありません。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であ ることを暗示するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づい てIBM独自の決定権をもっていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約するこ とを意図したものではありません。本講演資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、または その他の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもありません。 パフォーマ ンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスルー プットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処 理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているも のと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例と して示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、 Bluemix、およびIBM Watsonは、世界の多くの国で登録されたInternational Business Machines Corporationの 商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストにつ いては、www.ibm.com/legal/copytrade.shtmlをご覧ください。 おことわり