技術者でなくても知っておきたいIBM Cloudの基礎　～環境の構築、アカウントタイプ、作業者ユーザーIDの作成など、3つのポイントから考える

Text＝細野 晴海　日本アイ・ビー・エム　システムズ・エンジニアリング

IBM Cloudに限らず、クラウド利用に関する記事というと、クラウド上でのサービスやリソースの作成手順など、技術者向けの題材が大半である。

しかし実際のビジネスでは、クラウド利用を開始して、クラウド上でサービスやリソースの作成を開始する前に、技術者以外のロールメンバー（たとえばITベンダーの営業やプロジェクトマネージャー、ユーザー企業のクラウド利用部門の担当者など）のみで全体スケジュールや大まかな構成を計画するケースが多い。

このようなアプローチはクラウドが登場する以前から一般的ではあったが、昨今、クラウドの特性を活かした短期間での構築を求められることが多く、速やかに構築開始するにはその前段階で検討すべき内容や実施すべき作業を技術者以外のメンバーも理解しておくことが望ましい。

そこで本稿では、IBM Cloudの構築前に検討や実施が必要な以下の3つの項目について、技術者でなくても理解しておきたい基礎という形で紹介する（図表１）。

・IBM Cloud環境をどこにどのように構築するか？
・IBM Cloudのアカウントタイプは何を選択するか？
・構築前の作業者ユーザーIDの作成はどうするか？

図表1　構築フェーズと当記事の紹介範囲との関係

IBM Cloud環境の検討

IBM Cloud環境をどこにどのように構築するか？　

IBM Cloudにシステムを構築する際には、システムを構築する場所と、どのようなインフラストラクチャのタイプで構築するかを事前に決定しておく必要がある。

システムを構築する場所は、IBM Cloudでは「リージョン」と「ゾーン」という用語で呼ばれ、これは他のクラウドでも使われる一般的な概念である。

一方のインフラストラクチャのタイプはIBM特有で、クラシック・インフラストラクチャとVPCインフラストラクチャの2種類が存在する。

リージョン

リージョンとはデータセンターが存在している地域を指し、IBM Cloudの場合、たとえば日本国内には東京リージョンと大阪リージョンの2カ所のリージョンがある。どのリージョンにシステムを構築するか、単一のリージョンに構築するか、それとも複数のリージョンに構築するか、といった内容は最初に計画すべき検討項目である。

構築するリージョンを選択するにあたっての判断材料として、クラウドの利用料金や海外リージョンの場合は通信速度などが考えられるが、特に重要なのはシステムが扱うデータを国外のリージョンで保管可能かどうかである。

このような理由から、日本国内のリージョンを利用することが多く、さらに実績面から、比較的最近利用可能となった大阪リージョンよりも東京リージョンを利用するケースが多い。

続いて、通常は単一のリージョンにシステムを構築することが多いが、災害対策が必要な重要システムの場合は複数のリージョンにまたがって構築する必要がある。このような設計は、「クロスリージョン設計」や「マルチリージョン設計」と呼ばれる。

災害対策目的である場合はリージョン間の距離が重要で、たとえば東京と大阪の距離は約400kmと十分に離れていることから、同時に被災する可能性は非常に少ないとされている。

前述の実績面と合わせて、クロスリージョン設計の場合は東京リージョンが通常時用のシステムで、大阪リージョンが被災時用のシステム、というような設計が一般的である。

なお災害対策サイトは、通常１カ所で十分だとされており、IBM Cloudや、それ以外の主要クラウドベンダーでも日本国内のリージョン数は2つである（図表2）。

ゾーン

ゾーンとはリージョンの中に存在する独立したデータセンターを指し、一般的なクラウド環境では１つのリージョンに対して複数のゾーンが存在する。

１つのゾーンで電源障害や局地災害が発生しても、他のゾーンへ影響しないようになっており、局所的な障害発生への備えとして冗長化が必要なシステムについては、マルチゾーン設計が必要である。

マルチゾーン設計とは、主に冗長化のために、同一リージョン内の複数ゾーンに分割して構築することを指す。同一リージョン内のゾーンであれば、互いに高速通信が可能で、2つもしくは3つのゾーンで冗長化するのが一般的である。

この際、どのゾーンを利用するかの検討は不要である。またリージョン数と同じく、ゾーン数も主要クラウドベンダーでほぼ同じ。3つが最も多く、ごく一部が4つのゾーンを持つ（図表2）。

インフラストラクチャのタイプ

IBM CloudのIaaS環境のインフラストラクチャ・タイプには、「クラシック・インフラストラクチャ」と「VPCインフラストラクチャ」の2種類が存在し、これはIBM Cloudに特有なので注意が必要である。

クラシック・インフラストラクチャは、サーバーやネットワーク機器の選択肢が多いため、オンプレに近い環境を構築可能で、リフト＆シフトを実現しやすい。

また仮想やベアメタルなどのサーバーは、プライベート・ネットワークとパブリック・ネットワークを同時に持つことが可能で、利用者は無料で利用可能なVPNクライアント経由で、プライベート・ネットワークにセキュアにアクセスできる。

VPCインフラストラクチャは、2019年から新たに利用可能になったインフラストラクチャで、ネットワーク性能が高く、クラウドネイティブな設計が可能である。

サーバーの選択肢はまだ少なく、たとえばベアメタル・サーバーの場合は利用できるリージョンがごくわずかである。そのため、構築予定のサーバーがVPCインフラストラクチャで利用可能かどうか、事前の確認を推奨する。

本稿を執筆した時点（2022年11月25日）では、ベアメタル・サーバーを除いて、クラシック・インフラストラクチャとVPCインフラストラクチャとで構築できるシステムに大きな差はない。

敢えて差を挙げるとすると、VPCインフラストラクチャにはIPアドレスやサブネットなどのネットワーク設計の自由度と通信速度などのネットワーク性能が高いという特徴があり、クラシック・インフラストラクチャには無料のVPNクライアント経由でサーバーにアクセス可能であることから、セキュアな環境を簡単に用意できるという特徴がある。

なお、サーバーなどのIaaSリソースを利用せず、PaaSやSaaSだけ利用する場合は、インフラストラクチャ・タイプの検討は不要である。

IBM Cloudのアカウントタイプは何を選択するか？　

従量課金アカウントとサブスクリプション・アカウント　

IBM Cloudの利用を開始するには、アカウントタイプを選択して契約する必要がある。

アカウントタイプとはIBM Cloudの利用料金を支払う際の種類を指しており、「従量課金」と「サブスクリプション」の2種類が存在している。従量課金のみを用意しているクラウドサービスが多いが、IBM Cloudではサブスクリプションというもう1つの選択肢があり、どちらを採用するかの選択が必要である。

従量課金がリソースの使用量に応じて請求される一方、サブスクリプションは事前に利用期間と最小利用料を定めて契約することで割引を受けられる（図表3）。

なお、このほかにもアカウントタイプや割引方法にはバリエーションが存在する。

＜参考＞
IBM Cloudアカウントタイプ

サブスクリプション・アカウント利用時の注意事項

注意事項としてまず、サブスクリプション・クレジットの残量がなくなったり、有効期限が切れたりすると、自動的に従量課金に切り替わることに注意が必要である。

仮にIBM Cloudの利用が停止されると勘違いすると、思わぬ費用が発生することになる。なお、従量課金に切り替わったあとでも、サブスクリプションに戻して契約を延長することは可能である。

注意事項として次に、IBM Cloudのコンソールに表示されるサブスクリプション・クレジットの残量はリアルタイムで反映されるとは限らないことにも注意が必要である。

利用しているリソースによっては、たとえば月末に反映されるなど、時間差でクレジット残量に反映されるため、クレジット残量の表示金額だけでなく、事前に利用しているリソースの利用料金の見積もりを念頭に入れて計画すべきである。

このことから、サブスクリプション・アカウントを利用する場合は、サブスクリプション管理担当者を設けて、有効期限の把握、クレジット残量の定期的な確認、リソース利用料金の見積もりの事前確認などを推奨する。

＜参考＞
IBM Cloudサブスクリプションの管理

構築前の作業者ユーザーIDの作成はどうするか？　

構築作業開始前のユーザーID作成について知っておくべきこと

IBM Cloudに限らず、クラウドの利用を開始した直後は、マスターとなるユーザーIDが１つだけある状態となるが、当然構築作業を実施するには作業者ごとにユーザーIDが必要である。つまり構築作業の開始前には、このマスターとなるユーザーIDの所有者が作業者用のユーザーIDを作成する必要がある。

IBM Cloudの場合、利用契約時に指定したメールアドレスが最初のユーザーIDとなる。そのため、このメールアドレスの所有者が最低１つの作業者用ユーザーIDを作成する必要があることを踏まえて、契約時に指定するメールアドレスを決めなくてはならない。

また、作業者ユーザーIDの作成スケジュールの考慮も必要である。IBM Cloudの利用契約が完了した直後に構築作業を開始するスケジュールを組むことがあるが、構築作業開始前に作業者ユーザーIDの作成のスケジュールもきちんと組み込むべきである（図表4）。

 

ユーザーID作成のTIPS

作業者用ユーザーIDの作成は、作業代表者のユーザーIDを１つだけ作成すれば十分で、必ずしもマスターとなるユーザーIDの所有者が作業者全員のユーザーIDを作成する必要はない。作業代表者にユーザーIDの作成権限を与えれば、この代表者が残りの作業者たちのユーザーIDを作成できる。

また上記の代表者など、作業者の中に最低１人にでも高い権限を付与しておくと、構築時に急遽作業者の追加や構成変更などが必要となった場合に素早く対応できる。

このほか、リソースの削除にはリソースに関する管理者権限だけでなく、請求やCaseといったアカウント管理に関する権限が必要となるため注意が必要である。

＜参考＞
IBM Cloud のアクセス管理

多要素認証（補足）

IBM Cloud環境にアクセスする際に、ユーザーIDとパスワードだけでなく、Eメールに送信されるパスコードや、スマートフォンのアプリケーションなどで生成されるワンタイム・パスコードを併用することを二要素認証や多要素認証などと呼ぶ。

より安全にIBM Cloud環境を利用するためにも、多要素認証を実施するケースが増えている。構築開始前に、多要素認証の実施の有無を決定し、実施する場合はアカウント全体に多要素認証を有効化しておくのが望ましい。

＜参考＞
IBM Cloud多要素認証のタイプ

以上本稿では、技術者でなくても知っておきたいIBM Cloudの基礎として、構築を開始する前に押さえておくべきポイントを紹介した。

クラウド環境は技術者だけで作るのではなく、さまざまなロールの人たちが協力して構築・運用していく必要がある。

今回は3つに絞って紹介したが、実際のクラウド構築には関わらないという人々にも、クラウドの基礎について興味を持ってもらえれば幸いである。