特集・ブログ
ERP、SFAツール、顧客管理システム、POSシステム・・・ 現在では、様々なシステムを活用してビジネスを展開することが当たり前となりました。それぞれのシステムを必要に応じて連携し利用することによって、組織全体としてシステムやデータをより有効に活用できます。 本コラムでは、システム連携の代表的な手法や課題などを解説します。 ▲ 欲しい製品・ソリューションが見つけやすくなりました！ 目次 システム連携とは？ システム連携の代表的な方法 幅広いシステム連携方法に対応するのはコストがかさみ、手間も増える・・・ 用途・目的に合ったシステム連携の方法を選べる統合プラットフォーム「IBM Cloud Pak for Integration」 お問い合わせ 関連情報 システム連携とは？ かつて、システムは一部の大企業だけのものであり、大型メインフレームの導入が主流でした。しかし、1990年代以降にダウンサイジングの波が押し寄せ、現在は大企業だけではなく幅広い規模・業種の企業が業務別・目的別に最適化された多種多様なシステムを導入しています。 こうした中で、すでに多くの企業が取り組み始めているのがシステム連携です。システム連携とは、異なるシステム間でデータを相互に共有・処理できるようにすることです。システム間で分断されていたデータの活用によって、より深い洞察を得たり、オペレーションエラーを減らしたりといった効果を得られます。 「データ活用に役立つ」ソリューション は こちら 例えば、SFA（Sales Force Automation／営業支援）ツールと MA（Marketing Automation）ツールを連携することで、営業担当者やマーケティング担当者は、見込み客の獲得から最終的な受注に至るプロセスを俯瞰的に把握できるようになります。その結果、マーケティング担当者はウェブサイトの流入数や見込み客の獲得数だけではなく、アポイントメント獲得数や最終的な受注数といった営業側の指標も見ながら、マーケティング施策の検証や効果改善に向けて精度の高い施策検討を行なえます。 また、勤怠管理システムと給与計算システムを連携すれば、勤務時間に応じた毎月の給与計算を自動化できます。Excel などの表計算アプリでの集計など、人による作業工数の削減に繋がり、勤務時間管理や給与計算でありがちな計算ミスや誤入力といったオペレーションミスの防止に役立ちます。 「自動化による効率化に役立つ」ソリューション は こちら 次項でシステム連携を実現するための具体的な方法を解説します。 システム連携の代表的な方法 現在よく使われている代表的なシステム連携の方法は、以下の3つです。 ファイル転送 メッセージキュー API １.ファイル転送 ファイル転送はファイル単位で1対1でのシステム連携を実現する方法です。長年にわたってシステム連携の代表的な手段として利用されてきました。 ファイル転送は FTP（File Transfer Protocol）、SMB（Server Message Block）、CIFS（Common Internet File System）といったプロトコルを用いて実現します。FTP はファイル転送で利用される代表的なプロトコルの1つです。後述する方法に比べ、FTPの利点は大容量データを高速でやり取りすることです。 データ連携は通信プロトコルである FTP を通じて行うので、連携するシステムそのもののプログラムに手を加える必要がありません。そのため、一方のシステムで障害が起きてももう一方のシステムへの影響範囲を限定できます。 一方、ファイル転送でシステム連携を実現する際にはファイルの静止点（※1）が必要です。 ファイル転送はデータを一括して転送するバッチ処理によって行われるので、全データの処理が完了しなければ結果がわからず、途中経過を把握できません。そのため、リアルタイム処理のようにすぐ結果を知りたい場合は、1回のデータ量を減らして転送時間を短くするなどの工夫が必要です。 ※1：ファイル内のデータが更新されていない状態のこと ２.メッセージキュー メッセージキュー（Message Queue）はメッセージ単位で N対1、または N対N でのシステム連携を実現する方法です。 送信側が送信したメッセージは受信側が取り出すまでデータ領域（キュー）に保管されます。キューはメッセージ指向ミドルウェア（MOM：Message Oriented Middleware）やメッセージブローカー（Message Broker）で管理するのが一般的です。 送信側の処理はキューにメッセージを送信することで完了します。直接受信側にデータが送信されるわけではないので、受信側のシステムの負荷やリソースなどを意識する必要はありません。受信側でシステムダウンやリソースの逼迫があったとしても、送信側は処理の完了を待つ必要がないのです。 メッセージキューにおける送信側のメリットは「送信側が意図したメッセージの順序を維持することができる」ことです。このような特性から、メッセージキューは非同期処理が必要なシステム連携に向いています。 ３.API API（Application Programming Interface）は、HTTP や HTTPS形式で実装されることが多い、N対1 でのシステム連携を実現する方法です。 API はシステムの外部仕様を定義して各機能を利用するためのインターフェースを提供します。そのため、多くの場合 API はシステムを構築する言語と同じ言語のライブラリと通信プロトコルで提供されます。 API を使用すると、そのシステムの実装方法を知らなくても他のシステムと連携可能です。Webアプリケーションの特定の機能のみ API として実装して公開することで「社外の一般ユーザーが利用できるようにする」といったことができます。 例えば、下図のように社外の一般ユーザー向けに自社の Webサーバー上にある Webアプリケーションを提供した上で、ゲートウェイ上でアクセス制御を行うことで、セキュリティを担保できます。 「データ連携で活躍する」ソリューション は こちら 幅広いシステム連携方法に対応するのはコストがかさみ、手間も増える・・・ 前項で紹介したように、システム連携といっても様々な方法があります。採用するべきシステム連携の方法は連携するシステムの仕様、やり取りするデータ量、データ形式などによって異なります。 例えば、CADデータをやり取りするといったようにシステム間で大容量データを送受信する場合には、FTP によるファイル転送が適しています。一方、SaaS型ソリューションの多くが API を公開しているように、「顧客や取引先といった外部のユーザーが任意に特定のシステムと連携するための方法を提供したい」という場合には API が適しています。従来のように個別にシステム連携のプログラムを開発することなく、ユーザー側で連携作業を完了できるからです。 しかし、用途に合わせて複数のシステム連携の方法に対応するとなると複数のソリューションを導入しなければならず、製品ごとのライセンス・導入コストがかさんでしまいます。また、利用するソリューションが多くなると運用管理の手間も煩雑化してしまいがちです。実情として、用途に応じてシステム連携の方法を使い分けるのはハードルが高いといえます。 一方、最近では様々なシステム連携の方法を統合的に運用管理できるプラットフォームが登場しています。 「コストを抑え、手間を省く」ソリューション は こちら 用途・目的に合ったシステム連携の方法を選べる統合プラットフォーム「IBM Cloud Pak for Integration」 IBM Cloud Pak for Integration は、IBM が提供している MQ（メッセージキュー）、App Connect（アプリケーション連携）、API Connect/DataPower（API連携）、Aspera（ファイル転送）といったシステム連携を実現する様々なソリューションを統合したプラットフォームで、システム連携をワンストップで実現できます。 また、IBM Cloud Pak for Integration は実績のある Red Hat OpenShift Container Platform で稼働し、コンテナ技術に最適化しているので、オンプレ、IBM Cloud、他社クラウドなど様々な環境にデプロイできます。 システム連携に課題を感じている方は、ぜひ、IBM Cloud Pak for Integration の検討をおすすめします。 詳細は［IBM Cloud Pak for Integration］でも紹介しています。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いします。お問い合わせ 関連情報 IBM Cloud Pak for Integration（製品情報）- アプリケーション、データ、クラウド・サービス、APIの統合を支援するハイブリッド統合プラットフォームです。 今、デジタルサービスに求められる必須要件とは！？アプリケーションのコンテナ化で得られる5つのメリット（コラム）- 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編（ブログ）- シリーズ第1回目の本記事では、概要編として検証の目的・背景や環境周りを紹介します。 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した（ブログ）- 全世界から9万人以上の参加者が！ ul#list li{ margin-top:10px; margin-bottom:10px; } ul#list a{ font-weight:bold; } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .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; } .btn_CTA{ height:30px; margin-bottom:40px; width:450px; } .btn_CTA a{ display:block; width:100%; height:100%; text-decoration: none; background:#6200f5; 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 #6200f5; transition: all 0.5s ease; } .btn_CTA a:hover{ background:#bf94ff; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #bf94ff; } .bigger { font-size: larger; }
近年、大規模な自然災害が増加していることから DR の重要性が高まっています。 DR は「Disaster Recovery」の略であり、文字どおり「災害時にどう復旧するか」という対策を指します。 ひと言で「災害からの復旧」と言っても対策は多岐にわたり、求める対策のレベルによって運用にかかるコストにも違いがあります。 どこまで対策をすればいいのか、悩む企業も多いのではないでしょうか。 今、改めて押さえておきたい DR の基本・指標と、実現するための方法について解説します。 Index DRの基本と、BCPとの違い DRで最初に検討すべき3つの指標 DRを実現する3つの方法 バックアップ製品などをうまく活用し、効率的なDR対策を この記事に関するお問い合わせ 関連情報 DRの基本と、BCPとの違い DR は、地震や台風などの自然災害などが発生した際にシステムをスムーズに復旧させるための対策のことです。 似たものとして「BCP（事業継続計画）」があり、どちらも緊急事態への対策を検討するものですが、BCP が事業全般を継続するための計画を策定するのに対し、DR は「システムを災害発生から復旧させること」に重点を置いています。 特に、自社オフィスやデータセンターなどが台風や地震といった災害により物理的に利用できなくなってしまった際に、どう復旧するかがポイントとなります。 DRで最初に検討すべき3つの指標 DR 対策を検討する場合は、システムを「いつまでに」「どの状態に」復旧すればよいのかをしっかり定めましょう。その際に、指標となるのが以下の3つです。 RTO（Recovery Time Objective/目標復旧時間）： 「いつまでに、システムを復旧すればよいか」の目標を定めた指標 RPO（Recovery Point Objective/目標復旧時点）： 「いつのデータに、復旧できればよいか」の目標を定めた指標 RLO（Recovery Level Objective/目標復旧レベル）： 「処理能力や品質などをどのレベルまで、復旧できればよいか」の目標を定めた指標 これらの指標は、例えば「災害発生から3日以内に（RTO）」「前日のデータで（RPO）」「通常の半数程度の処理に対応できる（RLO）」ように復旧する、といった形で目標を定めることを指します。 これらの指標を組み合わせて対策を検討することになりますが、その方法は「バックアップの頻度」「復旧方法（手動/自動など）」により大きく5つのレベルに分けられます。 レベル1：スタンバイなし/バックアップリストア（手動） レベル2：コールドスタンバイ/バックアップリストア（手動） レベル3：コールドスタンバイ/プログラムによるバッチコピー レベル4：ホットスタンバイ/ツールによる非同期コピー レベル5：ホットスタンバイ/ツールによるリアルタイムコピー レベルが上がるにつれ RPO・RTO を短くでき、システムダウンの時間を最小限に抑えられますが、コストも高くなります。すべてのシステムを高いレベルで運用すればよいわけではなく、システムごとに指標を定めどのレベルで運用するかを検討することが重要です。 例えば「更新頻度の低い、社内の人事データ」であれば、リアルタイムに同期をとる必要はなく、月1回のバックアップデータを別拠点に保存する形で十分対応できるかもしれません。一方「ECサイトの受注データ」は前日のデータが残っていても不十分で、極力 RPO・RTO を短くする対策が必要になります。 どのシステムをどこまで対策するのか、コストとのバランスを見ながら検討すべきでしょう。 DRを実現する3つの方法 次に、こういった DR 対策を具体的に実現する方法を解説します。DR では、大きく3つの方法が挙げられます。 バックアップメディアを遠隔地に保管 バックアップデータを保存したメディアを遠隔拠点に運搬することで、データを守ります。メディアの種類も様々ですが、大容量データを長期保管する場合などは、比較的コストを抑えられるテープメディアが有効です。 ネットワークを介した遠隔バックアップ、リストア ネットワークを経由し、クラウド（IaaS）や別拠点にバックアップデータを保存します。災害時には、バックアップ環境側で新たに環境を構築・リストアすることで、早期復旧が可能になります。 データレプリケーション データを2拠点間でリアルタイムに同期し、障害発生時には、フェイルオーバーすることでダウンタイムを最小限に留めることができます。レプリケーション先でも本番環境と同等の環境が必要になるため、コストが割高になる傾向があります。 上記のうちどの方法が適しているのか、バックアップ先はクラウド・オンプレミスのどちらがいいのか、などは企業によって異なります。 また、つい「データをどこにバックアップするか」ばかり考えがちですが、データだけバックアップしてもアプリケーションなど含めたシステム環境が揃わなければ、業務で利用できるようにはなりません。 復旧時の手順や環境まで含めて、あらかじめ確認しておきましょう。 バックアップ製品などをうまく活用し、効率的なDR対策を DR は運用コストなどを理由に二の足を踏む企業も少なくありませんが、ビジネスにおいてシステムやデータの重要度が高まり続けるなか、データを失うリスクを考えれば、コストをかける価値は大きいはずです。 DR 対策で活用するバックアップなどの製品は数多く登場していますが、特にネットワークを介したバックアップを行う場合は、データの転送効率も要チェック。 例えば、IBM Spectrum Protect は、「永久増分」という方法を採用し、転送するデータを最小限に留めます。さらに高速転送機能により、WAN 環境でも高品質回線並みの転送速度を実現します。 いざという時に、想定よりもバックアップ環境でリストアして利用できるまでに時間がかかり、大きな機会損失になった、なんていう事態を防ぐには最適なツールです。 DR 対策で大切なことは、保有するデータごとに自社の事業内容と優先度に合った環境を用意しておくことです。前述のとおり、3つの指標＜RTO・RPO・RLO＞を策定した上で、効率的な DR 対策を目指しましょう。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 今、BCPで求められるITシステム対策について解説。考えるべき基本は？最優先すべきポイントは？ (コラム) - 災害など緊急事態における対策を定める「BCP」。では、具体的にどうすればよいのか？ .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; }
災害など緊急事態における対策を定める「BCP」。新型コロナウイルスの感染拡大もあり、今、改めて注目を集めています。 ですが、「なんとなくわかっているけれど、システムごとに最適な対策をできているかは自信がない」「きちんと対策できているか不安」という企業も多いのではないでしょうか？ また、従来の自然災害やパンデミックは比較的短期間で収束することを想定していましたが、予想を超える大雨の頻発、さらに新型コロナウイルス感染も収束の兆しが見えず問題が長期化するなか、BCP 対策に求められるものも大きく変化しています。 では具体的にどうすればよいのか、BCP の基本から、今、企業がすべきことを解説します。 Index BCPの基本とは？策定までに検討すべきポイント BCP対策におけるシステムの役割 BCP観点で有効な「データ保全」の方法 この記事に関するお問い合わせ 関連情報 BCPの基本とは？策定までに検討すべきポイント BCP とは、Business Continuity Plan（事業継続計画）の略であり、自然災害やテロなどの緊急事態において、事業を継続するための方法などを取り決めた計画を指します。つまり、通常のオフィスやシステムが利用できない事態に陥っても、素早く体制を復旧し事業を続けるためにあらかじめ具体的な計画を定めておく、ということです。 事業継続と言っても、緊急事態ですからすべて通常と同じように復旧できるとは限りません。どの業務を優先して継続すべきかを判断し、体制を整えるのが基本。まずは以下の流れで検討し、BCP 策定を目指しましょう。 優先すべき中核事業や、ビジネスに影響が大きい業務を特定する 上記、事業・業務の目標復旧時間を決める 事業を継続するための代替案を用意する BCP を発動する基準や、体制を明確にする 具体的な対策が社会情勢や事業の変化によって変わっても、この基本は変わりません。自社が守るべき事業や業務をきちんと見極めることが大切です。 BCP対策におけるシステムの役割 BCP で検討すべきことは、オフィスや工場・店舗など “場所” の確保、取引先との連携、顧客へのフォローなど多岐に渡りますが、システムが担う役割も大きくなります。「業務システムをどう継続するか」「オフィスに出社できないなかで従業員と、どう連絡をとるのか」といった観点のほか、緊急時に在宅勤務できる体制の整備も必要になるでしょう。 特に、コロナ禍により緊急事態が長期化するなか、対策すべき範囲が拡大しています。 在宅勤務では、オフィスのファイルサーバなどにアクセスできないといった課題が浮き彫りになり、クラウド化を進める企業も増加。緊急避難的な対策に留まらず、業務プロセス自体の効率化やモバイル端末活用推進、さらにはオンライン研修など、根本的な見直しを行うケースも今後増えると予想されます。 しかし、これだけのことを一気に進めるのは難しいでしょう。こちらも優先度をつけ、順次進めることをお勧めします。 なかでも最初にやっておきたいのが、「データ保全」です。災害であれパンデミックであれ、データがなくなってしまっては事業の復旧・継続は困難になります。 データを異なる拠点やクラウドなどに保管し、万が一の事態にも損なわれないよう備えることが、BCP において基本中の基本と言えるでしょう。 BCP観点で有効な「データ保全」の方法 データ保全の方法は様々ですが、「事業を継続する」という観点からはデータやシステムの情報を異なる場所で同期する「レプリケーション」が有効です。 レプリケーションでは、決まった時刻のバックアップデータを取得・保管するのではなく最新の情報をリアルタイムに同期するため、本番環境が利用できなくなった際にはフェイルオーバーすることで即座にレプリケーション先の環境に切り替えることが可能。 これにより、データを複数個所で保存しながら、ダウンタイムを最小限にしてシステムを利用し続けることができます。 レプリケーション先はクラウド（IaaS）も有力候補にはなりますが、セキュリティなどの観点からオンプレミスの拠点同士で構成するケースも。例えば、東京と大阪の拠点間でレプリケーションすれば、災害時の対策としても十分有効です。 どこにレプリケーションするのがベストなのか、自社の状況やシステムの規模などを踏まえて検討しましょう。 もう1つ、レプリケーションを実現する製品を選ぶ際には、データ圧縮や転送速度などの基本スペックとあわせて緊急時における対応のしやすさも確認することをお勧めします。 ストレージ自体にレプリケーション機能を搭載するものもありますが、この場合、製品ごとにツールを使い分ける必要があります。「IBM Spectrum Virtualize」は、外部ストレージ仮想化機能を提供します。 「IBM FlashSystem」や「IBM SAN Volume Controller」に搭載することで、異なるベンダのストレージを一括管理することが可能です。 IBM Spectrum Virtualize は、異なるベンダのストレージも一元的にレプリケーションでき、復旧時にもまとめて対処できるのでスムーズです。 BCP は、「一度考えたらOK」というものではありません。社会情勢の変化だけでなく、自社の中核事業や業務が変わることもあるでしょう。 ですが、そのなかでもデータを守る仕組みは不可欠。基盤となるデータ保全を確実に行いつつ、随時対策を見直し、適切な計画を検討する姿勢こそが重要です。 BCP 対策の第一歩として、IBM Spectrum Virtualize などを活用したデータ保全対策を整備しておくことをお勧めします。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは？効率的な対策は？ (コラム) - 近年、大規模な自然災害が増加していることから DR の重要性が高まっています。今、改めて押さえておきたい DR の基本・指標と、実現するための方法とは？ .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; }
コロナ禍で売上が落ち込んでいる企業を中心に、IT投資を再検討する動きが広まっています。 オンプレミスのシステムを運用するケースでは、膨大な更改コストを回避するため初期費用を抑えて利用開始できるクラウドに移行する企業が増えており、コロナ禍を機に企業のクラウドシフトが一気に進みそうな予感です。 本コラムでは、ミッションクリティカルな領域である基幹システムにおける新たな課題について触れつつ、クラウド移行を検討する企業に向けて、お勧めのマネージド型クラウドサービスについて紹介します。 Index コロナ禍を機に、基幹システムのクラウドシフトが加速 コストだけじゃない！基幹システムクラウド移行の様々なメリット 「Cloud Power」の活用シナリオ この記事に関するお問い合わせ 関連情報 コロナ禍を機に、基幹システムのクラウドシフトが加速 コロナ禍で産業全体の売り上げが減少する中、IT 業界において売り上げを伸ばしている領域が「テレワーク関連」や「クラウドサービス」などです。 クラウドに対するニーズが高まっている背景には、コロナ禍で経済の先行きに不透明感が漂い、大規模な投資を避けたい（もしくは、投資ができない）企業の考えがあります。こうした動きは、これまでクラウド移行をためらうケースが多かった基幹系システムにも拡がっています。 実際、IBM Power Systems などのハードウェアに加え、IBM Power Systems ベースのマネージド型クラウドサービス「Cloud Power※」を販売するエヌアイシー・パートナーズ株式会社（以下 NI+C P）によれば、コロナ禍に突入して以降、オンプレミス更改とクラウド移行を並行して検討していた企業がクラウド一本に絞って進めるケースが増えており、同サービスの成約率が倍増していると言います。（下グラフ参照） ※NI+C P のパートナー、日本情報通信株式会社（以下 NI＋C）が自社データセンター上で提供するクラウドサービス コストだけじゃない！ 基幹システムクラウド移行の様々なメリット コロナ禍で企業が基幹システムのクラウド移行へ踏み切ることになった背景としては、もうひとつ "ヒトを守る" という直接的な要因もあります。 それは、オンプレミスの機器入れ替えや設定などの作業過程における情シス部門やパートナー企業の人間が、入り乱れる "密" 状態の発生を回避したいという、ヒトの生命・安全を守る観点です。 もちろん、クラウド移行に踏み切る理由はこうしたコロナ禍によるものだけではありません。 そのメリットをしっかり評価・認識して近い将来クラウドに移行しようと考えていた企業において、コロナ禍で前倒しして、あるいは、コロナ禍で "ふんぎり" がついた、というケースが多いようです。 そこで、「Cloud Power」の場合、IBM i/AIX などのオンプレミスシステムを「Cloud Power」に移行することで、下記のような数々のメリットを享受することができます。 システム運用保守のアウトソースで人材不足に対応 情シス部門は、OSアップデートやセキュリティパッチ適用など、作業工数のかかる不定期メンテナンスをクラウド提供ベンダーに一任することで、人員リソースをデータ活用などの競争力強化に向けた異なる業務に配分・専任できるようになります。 また、IBM i/AIX という特殊なスキルを持った SE の不足や、熟練者退職にともなう業務運用継続の不安など、情シス部門の課題解決に貢献します。 EOS を心配することなく、常に最新の環境を利用できる ハードウェア・ファームウェアのアップデートや機器の更新は、提供事業者である NI＋C によって適宜おこなわれるため、導入企業はハードウェアの EOS を心配することなく利用し続けることができます。IBM Power Systems の Live Partition Mobility※ 機能によって、メンテナンスにともなうシステム停止の影響もありません。 ※稼働中の論理区画を別の物理的システムに移動する事を可能にする IBM Power Systems の有料フィーチャー 堅牢＆高セキュリティの横浜 DC で安心 「Cloud Power」が提供される横浜データセンターは、東日本大震災の時にも稼働し続けた実績があります。 一般的なオフィスビルとは比較にならない、ファシリティの圧倒的な堅牢性とネットワークを含めたハイレベルのセキュリティにより、重要なデータを守り、安心して利用いただけます。 BCP オプションで、投資を抑えて簡単に BCP 対策 「Cloud Power」のデータセンターは関西にもあり、両データセンター間でデータを同期し万一の時に切り替える「BCP オプション」メニュー（DC 間回線も含む）も提供しています。 オンプレミスでは、大規模な投資が避けられない災害対策サイト構築を、コストを抑えて手軽に実現します。 IAサーバーを含めた全面クラウド移行も可能 「Cloud Power」では、IBM i（AS400）や AIX のほか、Linux や Windowsなどの IAサーバーも同一セグメントで提供でき、オンプレミスで運用する各種システムの全面クラウドも可能です。 この他、エクイニクス社との契約により、AWS など他社クラウドとの接続・連携も容易です。 「Cloud Power」の活用シナリオ Linux や Windows のクラウド型マネージドサービスは数多く存在するなか、「Cloud Power」は、IBM i や AIX などミッションクリティカルな領域における数少ないマネージドサービスの1つです。 クラウドインフラからオフィスとデータセンター/データセンター間をつなぐセキュアな回線まで、必要なモノ・コトをオールインワンで提供しています。オンプレシステムの更改先やオンプレミス本番サイトの災害対策サイトのほか、下記のようなシナリオにもお勧めです。 ハードウェア EOS にともなうシステム延命 IBM i や AIX の古いシステム（オンプレミス）を SaaS に移行するプロジェクトを進めているが、その前にハードウェアが EOS を迎えてしまう…といったケースで、EOS のタイミングで旧システムを「Cloud Power」に移行し、SaaS 移行までの期間を延命することができます。 一定期間の開発・検証用途 当面オンプレミスを維持し続ける計画だが、開発・検証のためのリソースを用意するのが大変！といったケースでは、必要な期間だけ利用できるクラウドのメリットを活かし、「Cloud Power」を一定期間だけ契約して開発・検証をおこなうことでムダを排除できます。 社外プロフェッショナルへの BPO 推進 ベテラン社員の退職を機に、オンプレミスの IBM i や AIX システムを「Cloud Power」に移行。高度なスキルが要求される運用管理を全面的にアウトソーシングすることで、限られたリソースを AI によるデータ分析や RPA での業務自動化などに振り向けることができるようになります。 IBM i × 3種類 / AIX × 5種類の基本メニューに加え、多彩なオプションが用意される「Cloud Power」。 ニューノーマルに向け ITインフラ投資の最適化をお考えの企業は、ぜひ、お気軽にお問合せください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 Cloud Power (製品情報) - IBM i (AS400)、AIX を国内シェアNo.1 のクラウド環境でご提供します！ IBM Power Systemsユーザーのクラウド移行ニーズに寄り添う「Cloud Power」の魅力に迫る (コラム) - IBM Power Systemsのメリット（特長）にフォーカスしつつ、具体的な導入事例についてもご紹介します。 .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の岡田です。 前回の「OpenShiftに代表されるコンテナ環境へのIBMストレージの対応」でも触れた通り、ここ数年の傾向として何でもかんでもクラウドに移行するという時代は過ぎ、従来型の IT インフラとクラウド環境とを上手く使い分け、あるいは連携しながら、目的の業務アプリケーションを動かしていく方向になりつつあります。いわゆるハイブリッドクラウドというものです。 そして、パブリッククラウド自体もそれぞれのサービスにより使い分ける風潮があり、今やパブリッククラウド・ユーザー企業の半分以上が、複数のパブリッククラウドを使っているのではないかと思われます。いわゆるマルチクラウドと呼べるものですね。 しかし、なかなか統合的に管理するというところにまでは至っておらず、クラウドを含めたサイロ化が起こっている状況です。 このような運用ではアプリケーションの適材適所はおろか、データさえ十分に使えていないことは明白です。 今回はこのようなハイブリッド/マルチクラウドの状況の中でデータを上手く連携し活用していくために、IBMのストレージにできるソリューションを紹介しましょう。 ハイブリッド/マルチクラウドの位置づけ 以下の図は、ハイブリッドクラウド、マルチクラウドを模式的に表したものです。 オンプレ環境のプライベートクラウドまで含んでマルチクラウドという人もいますし、従来型の物理サーバーや仮想化された VM 環境もハイブリッドクラウドのオンプレミス部分の一部と考える人もいます。人によっても会社によっても捉え方は色々ですが、ここでは敢えて従来型 IT もハイブリッドクラウドの一部として話をしたいと思います。 図1. ハイブリッドクラウドとマルチクラウド IBM Spectrum Virtualize for Public Cloud とは！？ IBM Spectrum Virtualize for Public Cloud（SV4PC）は、第一回目、第二回目のブログでも登場した IBM のメインストリームとなるブロックストレージ、FlashSystem にも搭載されている管理機能ソフトウェア、これをパブリッククラウドでも使えるようしたものです。 つまり、SV4PC はハイブリッドクラウドやマルチクラウドに対応したストレージ製品です。 SV4PC を知れば FlashSystem を知ることができますので、SV4PC の機能を紐解いていきましょう。 外部仮想化機能 2003年、この Spectrum Virtualize ファミリーの元となる製品が生まれました。SAN Volume Controller、通称 SVC です。 今でもこの製品は最新のテクノロジーを装備してファミリーの一員です。（IBM Spectrum Virtualize for Public Cloud も Spectrum Virtualize ファミリー製品です。） そこから脈々と受け継がれた外部仮想化という機能は、IBM および他社ストレージ製品約500種類を配下に接続可能で、これを仮想化して自身のストレージとして扱うことができるものです。 図2 外部仮想化機能 もちろん、既存で使われているストレージのボリュームや保存されたデータを生かしたまま配下に収めることができるため、オンライン・データ移行はもちろん、コピーサービス（スナップショット等の機能）を持たないストレージにそういった機能を与える事もできます。 この機能を使う事で、FlashSystem では他社製品を含めた古い製品から簡単に最新のテクノロジーにデータを引っ越すことが可能です。 パブリッククラウド上では、SV4PCがプロバイダーが提供する基本的な機能しか持たないブロックストレージを配下に置くことができます。 これにより、最新のデータ削減機能の他、ブロックレベル自動階層化のEasy Tier（補足参照）、FlashCopyや筐体間コピーを含むコピーサービス（補足参照）、といったテクノロジーも使用可能となるわけです。 図3. データ移行のイメージ 様々なデータ削減機能 FlashSystem 5010 を除く Spectrum Virtualize ファミリーには、いくつかのデータ削減機能があります。 これらは DRP（Data Reduction Pool）というデータ削減にはなくてはならない機能を実装した Spectrum Virtualize ファミリー特有のストレージプール上で実現されます。また DRP での各処理単位はフラッシュ系デバイスに最適化されています。 図4.Data Reduction Pool 具体的には「リアルタイムデータ圧縮機能」「重複排除機能」「シン・プロビジョニング機能」がサポートされています（一部組合せによりサポートできないデバイスがあります）。 ※詳しくは補足をご覧ください。 Spectrum Virtualizeファミリーのハイブリッドクラウド/マルチクラウド対応 触れてきた通り IBM の Spectrum Virtualize ファミリーであれば、オンプレミスの FlashSystem あるいは SVC とパブリッククラウド上の SV4PC とでデータ連携できるので、データの観点でハイブリッドクラウド対応ができます。 また、パブリッククラウド同士でデータ連携することもそれぞれに SV4PC を置くことで可能となり、マルチクラウド対応もできます（2020年7月時点、IBM Cloud と AWS に対応）。 図5. ハイブリッド/マルチクラウドのデータ連携 さらにこの方法を使えば、他社の既存データも活かすことができます。外部仮想化機能が使えるからです。 つまり IBM の Spectrum Virtualize ファミリーを使うと、他社ストレージ製品も含めてハイブリッドクラウド対応できる事になります。 では、データをハイブリッド/マルチクラウド連携できると何が嬉しいのでしょうか。 ハイブリッドクラウド/マルチクラウドの利点 グローバルでは、一番広く使われているのが災害対策用途です。 被災時に本番環境が使えなくなった際も、パブリッククラウド側で仮想サーバー、コンテナなどを使い業務を継続できるからです。 今求められるデータ活用としては AI/アナリティクスなどと言うものもあります。 オンプレミスで使えるものもありますが、手軽にやろうとすると各パブリッククラウド上で提供している AI サービスを使うのが早いですね。最初に触れた通りサイロ化されたデータをパブリッククラウドと連携するにもハイブリッドクラウドは有効です。 バックアップ先としてパブリッククラウドを使うと、いらぬ投資をすることなく遠隔保管が可能となります。 通常テープを使った遠隔保管ですと保管場所である拠点、定期的な搬送といった固定費が発生します。最悪の場合、本番業務側が被災した場合にもデータをリストアしなければならないことを考えると、保管場所にリストアする仕組みが必要となります。これも大きな投資となるでしょう。 パブリッククラウドをバックアップ先とした場合それだけで遠隔保管が実現でき、必要な場合のみ仮想サーバーも立てることができるため DR としての役割も果たせるのです。 また、クラウドに業務を移行するというケースもまだまだ発生しますね。 この際クラウドプロバイダーが提供している方法もありますが、移行対象となるデータが多量にあると、なかなか与えられた方法を用いて計画通りに移行することは困難な場合があります。特にプロバイダーから送られたハードウェアを仲介して行う方法は、移行の間は業務を止めて対応する必要があります。これではビジネス的なインパクトが発生します。 ハイブリッドクラウド形態でのクラウド・オンプレミス間のデータ同期であれば業務を止めずに対応でき、万が一クラウドに移行したことで何らかの不具合を生じた場合にも即座に元の環境に戻すことができます。 これらの有益なハイブリッドクラウドのデータ連携にマルチクラウドのデータ連携要素が加わると、更に有益なことがあります。 最近の風潮としては、パブリッククラウド上にデータを置く場合でもミッションクリティカルなものの場合には、AZ（アベイラビリティーゾーン）を跨ってレプリケーションを取ることが一般的になってきています。冗長性を保つという意味では、異なるパブリッククラウドにコピーを持つことも有効でしょう。 このような用途にもマルチクラウド・データ連携は役に立ちます。 またメジャーなパブリッククラウドは、基本的にグローバル展開をしております。 自身で海外にサイトを立ち上げる必要なく、容易に海外展開できるといった利点や、国内でも東阪の災対環境も手軽に築くことも可能です。 図6. ハイブリッド/マルチクラウドで実現できるソリューション ハイブリッドクラウド・データ連携の具体例：クラウドへのデータ移行 パブリッククラウドに業務を移行する際に、ハイブリッドクラウドの接続形態を使うことで既存の業務を止めないオンラインデータ移行が可能です。（ただし既存ストレージの仮想化のための接続変更時は短時間ですが止める必要があります。） 図7. ハイブリッドクラウド活用例・クラウドへのデータ移行 オンプレミスとパブリッククラウド、あるいはパブリッククラウド同士でのレプリケーションは方向を変えることも可能ですので、もししばらく使ってみて移行先で業務がうまくいかないなどの不具合が生じた場合は、データをオンプレミス側に戻すことも可能です。 他の活用例も結局はこのレプリケーションを使って双方を連携させることによりますので、アイディア次第でお客様の用途に合わせて色々な活用方法が見つかるかもしれません。 クラウド上ではこんな使い方も SV4PC だけでも面白い使い方ができます。 多くのパブリッククラウドの環境下では、その環境内で使える仮想ブロックストレージが用意されています。 プロバイダーにもよりますが、大雑把に言ってしまえばクラウドは大規模な物理リソースを小出しにして使っている都合上、様々な制約があったり、性能の低いリソースを使わないとコストがかかりすぎるなど難しい局面も持っています。 例えば一つの仮想ブロックストレージの上限容量です。あるプロバイダーでは 16TB までしか使えなかったり、IOPS の上限にひっかかったりします。 このように、デフォルトのままではパフォーマンス要件をこなせないような場合でも、SV4PC で仮想ブロックストレージを複数束ねることで、仮想サーバー側に提供するストレージをスケールアウトすることができるので解決できたりもします。 また、データがホットな時期は SSD、旬が過ぎると HDD レベルで充分なデータを扱う場合、そもそも一時的なパフォーマンスのために全データを同じ SSD に置いておくのは無駄があります。 このような場合、最小限必要な SSD と充分な HDD を SV4PC で束ねつつ、前述の Easy Tier のような自動階層化機能を使うと、意識することなくホットデータは SSD で処理、その後は HDD へ配置されるので、クラウド上のストレージコストを全体的に減らすことができたりもします。 さらに、SV4PC のシン・プロビジョニング機能を使えば効率の良いコスト削減が可能となります。 通常の場合、仮想ブロックストレージの払い出しは見込み容量を先に決めてからその分払い出すことになり、運用後の拡張の手間を考えると、あらかじめ余裕を持った容量を払い出しがちです。この場合、実際に使用していなくとも払い出した容量は課金対象となります。 これに対しシン・プロビジョニングは、実際に存在する容量以上のストレージ空間を切り出すことができるのと、後から不足しそうな容量分の仮想ブロックストレージをストレージプールに加えることもできるので、最小限の容量から始めることができ、容量課金を削減することができます。 図8. パブリッククラウド上でのSV4PCの活用 なお何度も言いますが、SV4PC は今後のコンテナ環境にも対応しております。 ここまで見てきた通り、SV4PC はクラウド全盛の今だからこその機能を備えた Software Define Storage ソリューションであることが分かると思います。 いかがでしたか？ ハードウェアはもちろん技術の塊ですが、ソフトウェアのみでも十分に使える IBM Spectrum Virtualize ファミリー、少しは興味を持っていただけたのではないでしょうか？ 次回は「最新のデータのライフサイクル管理」ということで ESS、Sepctrum Scale、オブジェクトストレージ、そして Spectrum Discover といった製品に触れてみたいと思います。 乞うご期待！ 補足 1）リアルタイムデータ圧縮 バッチ処理で圧縮するのではなく、データの書き込み時に圧縮処理をして記憶域に書き込む圧縮方法です。FlashSystem 5030 と SV4PC を除きハードウェア・アクセラレータを活用できます。 もちろん 5030 および SV4PC もコントローラのリソースのみの処理ですが暗号化機能を実現しています。 圧縮率は、対象となるデータの種類によって異なりますが、一般にデータベース、メール、仮想サーバーイメージなどのファイルが高いと言われています。 以前はオフィスデータなども高かったのですが、最近はすでにオリジナルのオフィスファイル自体で圧縮済みですので、あまり効果は期待できなくなっていると言われます。 更に DRP の機能とは別に、IBM 特有の FlashCore モジュール（略して FCM。FlashSystem 5100, 7200, 9200/R で使用可能）であれば、モジュールそのものにインライン・ハードウェア圧縮機能があります。これはモジュール内のハードウェア的なデータの通り道にワイヤードロジックによる圧縮機能を設けているため、性能に影響を与えません。 ちなみにこのワイヤードロジックには暗号化機能も盛り込まれており、同様に性能に影響のない暗号化を実現しています。 2）重複排除 データのなかに同じパターンを見つけて、冗長なデータを削減することで容量を節約する機能です。特に仮想サーバーイメージなどには有効な手法です。 以前は非常に負荷がかかる作業だったため、バックアップなどに限定して使われていた技術ですが、昨今は性能の向上により、通常のストレージでも当たり前に使われる技術となりました。 以下は非常に単純化したインラインで扱われる重複排除のイメージです。バックアップ等での処理はこの限りではありません。 図9. 重複排除 実際はこう単純ではありません。 書かれたデータのパターンに応じたフィンガープリントと呼ばれる代替え値をハッシュ関数により導き、新たに書かれるデータのハッシュ値がすでに存在するフィンガープリントと一致している場合は、データそのものは書き込まず、参照するフィンガープリントのポインターのみを管理テーブルに記録する。これによりデータを間引くことができ、書き込み容量を削減することができるのです。 DRP 上での重複排除の特徴はフィンガープリントを同一ボリューム内のみならず、同じ DRP で定義された別のボリュームも含めて参照していることです（※図4参照）。同じプール内でバックアップなどのボリュームが定義された場合などに効果を発揮できるからです。 図4.Data Reduction Pool 3）シン・プロビジョニング こちらは、データ削減と言うよりはサーバーから見た際の話になります。 通常、ストレージ装置側で定義したボリュームをそのまま OS で認識させ使用することになります。その際の容量は、ストレージ装置のボリューム定義そのままの容量となります。 図10. シン・プロビジョニング シン・プロビジョニングを使うと、その容量定義を物理的に存在しない容量も上乗せして定義することができます。この場合消費されるストレージ装置の容量は実際に書き込みが起こった時にそのデータ容量分ずつとなります。 もちろんその存在しない容量分に書き込みが発生するとエラーになりますので、そうなる前に物理容量を追加する必要があります。同じストレージプール内の複数のボリュームで、実際に存在する実効容量を共有して消費するといった使い方が効果的です。が、OS 側からは何も意識することがありません。 この方法は、実はパブリッククラウドのように払い出し容量で月額課金されるようなサービスでは、より有効な節約方法となります。 4）Easy Tier Spectrum Virtualize ファミリーには、もう一つ特徴的な機能として自動階層化機能があります。 通常データの階層管理というと、ファイルレベルで実装するものをイメージされる方が多いのではないでしょうか？ Easy Tier はブロックレベルでありながらストレージの負荷情報を自ら学習し、アクセスの集中するホットなデータは Flash系のデバイス、アクセス頻度の低いデータは容量単価に優れる大容量・低速の HDD といった階層にデータを AI を使ってストレージの機能で動的に移動させる機能です。 図11. EasyTierの動作イメージ この機能を使うと高価な半導体系のストレージデバイスの容量を節約し、安価なハードディスクを増やすことで、パフォーマンスを下げずに全体の容量単価を下げることができます。 オンプレミスの FlashSystem はもちろん、払い出し容量で月額課金されるパブリッククラウドでも有効な節約手段となります。 5）コピーサービス 今や多くの廉価なストレージ装置もスナップショット、レプリケーションといった機能は当たり前になっています。 図12. 様々な用途に使えるコピーサービスの数々 スナップショットなどの瞬間のボリュームイメージを切り取る機能は、一般的にポイント・イン・タイム・コピーと呼び、IBM の場合は FlashCopy と言われる機能になります。 こちらは通常ストレージ装置内で使われる機能です。バックアップを取るときなどアプリケーションや RDB などと連携して、静止点をとるのに有効な機能です。 これに対して、ストレージ装置間で関連づけたボリューム同士で同期を取り、それぞれのボリュームを常に同じデータで満たす方法がレプリケーションです。 スナップミラー、ボリュームミラー、リモート・ミラーあるいはリモート・コピーなど、メーカーによって呼び方は様々ですが、基本的には時間的ズレのない同期型のものと、多少の時間的ズレを容認する非同期のものとに大別されます。 前者は銀行など災害などでのデータ損失を認めないような要件で使われ、拠点を跨ぐ場合、それなりの高価な設備（ネットワーク設備であったり拠点設備であったり）と共に使われます。後者はデータの多少の損失は容認するか、または別の方法（ログデータとかとの併用など）で補うかして、むしろ、より遠隔にデータを退避することを優先するなどの目的で使われます。広域災害などへの対策が多いですね。 考慮すべき事項に、特にレプリケーションは同じストレージ装置同士であると言う大前提があります。メーカーごとに使っている技術が異なるからです。 IBM の場合、Spectrum Virtualize ファミリーであれば相互接続が可能です。つまりオンプレミスのFlashSystem または SVC とパブリッククラウド上の SV4PC との接続が可能なのです。これが IBM ストレージがハイブリットクラウドに対応できると言う一つの根拠です。 もちろん前回触れた通り CSI（Container Storage Interface）にも対応していますので、コンテナ環境にも対応可能です。 接続方法について以前は、ストレージ機器同士の同期ということでより早く安全な FCP（Fibre Channel Protocol）に頼っていましたが、今日では非同期を前提に充分に IP 接続でも対応できるようになりました。 また、帯域以上のデータ転送を余儀無くされる初期同期が問題になりますが、前述のシン・プロビジョニング・ボリュームを対象とすることでボリューム全転送を必要とせず差分だけで可能となったり、データそのものも効率的な圧縮・重複排除の活用で小さくなったというのも大きいですね。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連ページ IBMストレージ製品 (製品情報) 全包囲網。。。最新 IBMストレージ 概要 (ブログ) OpenShiftに代表されるコンテナ環境へのIBMストレージの対応 (ブログ) 最新のデータライフサイクル管理とは？（前編）(ブログ) 最新のデータライフサイクル管理とは？（後編）(ブログ) AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) .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つとして市場やニーズの変化が速い、ということがあります。 この変化の激しい時代において、大量データを市場環境の分析や顧客ニーズの把握などに活かしていくことは、今日の企業にとって競争を勝ち抜くための重要な経営課題となっています。 すでに一部の企業はデータ分析基盤を導入し、多種多様なデータを効率的に分析することで市場の変化を迅速に捉え、自社製品・サービスの改善に活用しています。 そこで本コラムでは、データ分析基盤の基本的な構成や選定ポイントなどを解説します。 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 の進歩によって、企業は多様なデータを手にできるようになりました。そして、それらを有効に活用していくためにデータ分析基盤を構築する企業が増えています。 (さらに…)
