AWS/Azure 経験者がはじめる OCI 入門 ～ Compute編 ～

#はじめに
本記事では、AWS/Azure と言った パブリッククラウド に続いて Oracle Cloud Infrastructure (OCI) の 学習を始めた筆者が、同じく 第２、第３のパブリッククラウド として OCI の 学習を 始めた方 向けに、OCI の 特徴や、他のパブリッククラウド との相違点 などについて、ご紹介していく内容となっています。

第３弾となる今回は、Compute編 となります。

第１弾 概要編：https://qiita.com/Skogkatter112/items/98c6f815b4e0b6556b7e
第２弾 IAM/IDCS編：https://qiita.com/Skogkatter112/items/51b619026aa53a9c6069
第３弾 Compute編：https://qiita.com/Skogkatter112/items/540da610c7938cb74b55
第４弾 Storage編：https://qiita.com/Skogkatter112/items/200a1fe8c419fc9ee16e

#インスタンスの種類
AWS EC2 の「インスタンスタイプ」、Azure Virtual Machine の「仮想マシンのサイズ」のように、OCI の コンピュートには 様々な「シェイプ」があります。

上記のように、大きく分けて「VM インスタンス」と「ベアメタルインスタンス」があり、更にワークロードごとに「汎用」や「GPU」など、様々な種類が提供されています。（OCI 技術資料 より抜粋）

提供されるシェイプは 常に変化していくため、最新情報は マニュアル をご参照頂きたいのですが、2020/07/16 現在の具体例として 一部抜粋したものが 下記になります。

OCI の コンピュート・シェイプの特徴としては、１つの CPU に対して メモリが多く積まれている という点 です。（例として、「VM.Standard2.1」というシェイプ は 1 CPU、メモリ 15 GB となっています。）

###シェイプの表記
尚、インスタンスシェイプの表記は、下記のような見方をします。
それぞれ、"サーバの種類"、"CPU や ワークロードの種類"、"インスタンスのサイズ"を意味しています。

CPU 数については、Oracle では独自のCPU 単位として**「OCPU (ｵｰｼｰﾋﾟｰﾕｰ) 」という単位** が用いられ、1 OCPU = 1 CPU コア で換算されます。
他社クラウド では、マルチスレッドをサポートしている 1 CPU コア内 の 1 スレッド = 1 vCPU として表記 している場合 が ありますが、OCI では 純粋に コア単体を 1 CPU として換算しているのが特徴です。

※余談ですが、「1OCPU」と表記すると「10」と誤読しやすい為、間にスペースを空けたり、「1oCPU」などと表記するのがオススメです。

###特殊なインスタンス・シェイプ
提供されているシェイプの中には 少し他と異なる「Frexible E3」というシェイプがあります。
通常は インスタンスのサイズ、つまり CPU 数や メモリサイズ、それに伴うネットワーク帯域などは、固定された物 から 選択するほか 余地がありませんが、このシェイプでは、ユーザが 任意の CPU 数や メモリサイズ が選択可能 になっています。
従って、固定化された枠を取り払い、必要最小限のインスタンスを作成する、といった 柔軟な活用 が可能になります。

###シェイプの変更
一度作成したインスタンスした後も、運用していく中で スペックを 強化したい といったニーズが 出てくるケースも あるかと思います。

他社クラウドでも インスタンス作成後の スペック変更 が 行えますが、OCI でも、インスタンスの再作成をすることなく、シェイプの変更が行えます。

※ただし、シェイプの変更後は 再起動が必要 になります。

#仮想マシンのイメージ
イメージというのは、仮想マシンを起動する際の OS であったり、OS + アプリケーションが含まれた環境のことを指します。OCI 上で提供されているイメージは大きく分けて 下記の５種類あります。

• プラットフォーム・イメージ
  Oracle が OCI 上で提供している OS イメージになります。
  Windows Server や Oracle Linux、Ubuntu、Cent OS などがあります。
  詳細は マニュアル をご参照ください。

• Oracle イメージ
  Oracle が提供している イメージ という点で プラットフォーム・イメージと同じになりますが、こちらは Oracle が提供している アプリケーションなどが 予めインストールされている イメージ となります。例えば、E-Business Suit や Enterprise Manager などがあります。

• パートナ・イメージ
  パートナー様、つまり 3rd Party によって 提供される イメージ になります。
  日に日に増えているのですが、例としては Microsoft SQL 2016 Enterprise with Windows Server 2016 Standard や Blue Prism Robotic Process Automation などが 提供されています。

• カスタム・イメージ
  Azure ユーザには 馴染みやすい言葉かと 思いますが、ユーザが 任意で 作成できる イメージ になります。AWS で言うところの AMI になります。
  例えば OS の言語設定を日本語に変更し、そのイメージで VM を複数作成したい、といった場合に、カスタム・イメージを作成することで複製が容易になったりします。

• ブート・ボリューム
  OCI の仮想マシンは、作成時に必ず ブート・ボリューム という領域が 付属して作成されます。ブート・ボリューム には、OS などの管理領域が含まれています。
  この ブート・ボリューム は、既存のインスタンスから接続解除し、別途保存しておくことが可能になります。保存された ブート・ボリューム は、仮想マシンのイメージとして利用することが可能です。

カスタム・イメージ と ブート・ボリューム については、「インスタンスのバックアップ」の 項目でも 詳しく説明します。

#仮想マシンへのアクセス
仮想マシンへのアクセス方法は、大きく分けて Linux ベースの イメージか、Windows ベースの イメージか、で異なります。

###Linux イメージ の 場合

• ユーザ
  自動で作成される OS ユーザを利用してアクセスします。
  • Oracle Linux / Cent OS の 場合 ： ユーザ名 opc
  • Ubuntu の 場合 ： ユーザ名 ubuntu
• 認証方法
  キー・ペアを用います。キー・ペアは コンピュートの作成時に OCI のコンソール画面からダウンロードしたものを利用するか、または、Tera Term などの 3rd Party ツールを用いて生成したものを登録し、利用します。
• ネットワーク設定
  ssh 接続を可能にするため、OCI の仮想ネットワークのファイアウォール設定 にて ポート 22 を開けておく必要があります。（OCI の デフォルトルールを変更していない場合は、特に設定は必要ありません。）

###Windows イメージ の 場合

• ユーザ
  自動で作成される ユーザを利用してアクセスします。
  • ユーザ名 opc
• 認証方法
  OTP (ワンタイムパスワード) を用います。OCI の コンソール画面より参照可能です。※ただし、ログイン時に OTP をコピー＆ペーストできない為、手入力になります。
• ネットワーク設定
  RDP 接続となります。そのため、OCI の仮想ネットワークのファイアウォール設定 にて ポート 3389 を開けておく必要があります。

###OS 側の ファイアウォール設定 について
仮想マシンのアクセスで もう一つ 気を付けて頂きたいポイントとして、OS 側の ファイアウォール設定 があります。
ここは、AWS/Azure 経験者は きっと陥りがちなポイントだと思うので、必ず押さえて頂きたいポイント です!!!! 他社クラウドでは、firewalld/iptables 等、ホストベースのファイアウォール設定が 初期状態では 設定されていないケースが多いかと思います。
OCI の コンピュート・インスタンスでは、Linux ベースであれば SSH アクセス するための ポート 22、Windows ベースであれば RDP接続するための ポート 3389 のみを許可する ファイアウォール設定が されています。

従って、例えば コンピュート・インスタンス を Webサーバ として、Apache や Nginx などをインストールした場合、適宜必要なポートをOS上で開放する必要があります。

ポート80・ポート443を解放する例

sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp

###パブリック IP アドレス について
仮想マシン に アクセスする際、パブリック IP アドレス を用いてアクセスすることも多いかと思います。この パブリック IP の 挙動が OCI 上では どのようになっているか？についても、触れておきたいと思います。

OCI の パブリック IP アドレス には 下記 ２種類 が 存在します。

• エフェメラル・パブリック IP アドレス：
  インスタンスの存続期間中のみ保持される、一時的なパブリック IP アドレスです。インスタンスの起動・停止で変更されることはありません。
• 予約済みパブリック IP アドレス：
  割り当てられているインスタンスの存続期間を超えて永続的に保持可能なパブリック IP アドレスです。割り当てを解除し、いつでも好きなときに別のインスタンスに再割り当てすることができます。取得に 追加費用は かかりません。

仮想マシン の 作成時に 付与する パブリック IP アドレス は、エフェメラル・パブリック IP アドレス となっています。予約済みパブリック IP アドレス が 必要な場合は、仮想マシンの作成後に別途アタッチする形になります。
いずれの パブリック IP アドレス であっても、仮想マシン が 終了（削除）されるまで、変動することなく 一貫して 同一 IP アドレスが 保たれる、という点が ポイントです。

#インスタンスのバックアップ
コンピュート・インスタンスのバックアップ方法 としては、「仮想マシンのイメージ」という項目でも 少し触れましたが、カスタム・イメージ と ブートボリューム という ２つの方法 があります。

• カスタム・イメージの作成
  コンピュート・インスタンスのブートボリュームから カスタム・イメージ の作成が可能です。ブートボリュームから作成されるため、作成時点でインストール・カスタマイズされた設定が保存可能 です。

  • イメージを保持するための 追加費用 は かかりません。
  • イメージの作成中、インスタンスはシャットダウンされ、イメージ作成後に再起動されます。
  • コンピュート・インスタンスに 別途アタッチされたボリュームが存在する場合、その領域に関するバックアップは取得されません ので ご注意ください。

• ブート・ボリュームのバックアップ機能の利用
  ブートボリュームは、バックアップポリシー に従って、自動的にバックアップを取得することが可能です。ブートボリュームのバックアップから 再度ブートボリュームを復元 (作成) することで、インスタンスの再作成 が 可能です。

  • ダウンタイムなく バックアップ を 取得することが 可能です。
  • Crash-consistent な バックアップである為、静止点を設けることが推奨されます。（参考：クラッシュ・コンシステントとは）
  • バックアップは オブジェクト・ストレージ に 保存されるため、コストを必要とします。

上記の内容を見ると、他社クラウドにあるような、「インスタンスにアタッチされたボリュームも含めた 総合的な ポイントインタイム の バックアップは どうしたら良いのか？」と思われるかもしれません。
詳しくは 別途記事にしたいと思いますが、「ボリューム・グループ」というものを構成することで、グループに含まれる 全ボリュームの ポイントインタイム の バックアップが 取得できます。

###カスタム・イメージとブートボリュームの違い
それぞれ 下記資料 の通り、メリット・デメリット を踏まえ、いずれの方法かによる バックアップ をご検討ください。（OCI 技術資料 より抜粋）

#自動スケーリング
設定した条件に従って インスタンスを 自動的に スケールアウトさせるための機能 になります。自動スケーリング の コンポーネント には 下記のものがあります。

• インスタンス構成
  インスタンスを スケールアウト・スケールインさせる際の 元となるイメージ を意味します。既存のコンピュート・インスタンス から「インスタンス構成の作成」という操作を行うことによって作成できます。
  作成済みのインスタンス構成の変更は、API または CLI でのみ可能 です。
  AWS における 起動テンプレート に当たるイメージです。

• インスタンス・プール
  起動するインスタンスの集合体 を指します。インスタンス構成を選択して構成します。インスタンス・プール内で 管理されているインスタンスは、一括で 起動・停止・終了 を行うことが可能 です。
  作成済みのインスタンス・プールの変更（インスタンス数の変更を除く）は、API または CLI にて可能 です。
  AWS における グループ に当たるイメージです。

• 自動スケーリング構成
  インスタンスは、OCI の Monitoring というサービスによって CPUの使用率 や メモリの使用率 といった メトリック が取得されています。このメトリックを用いて、閾値など 条件を設定したものを 自動スケーリング・ポリシー と呼びます。また、それらの管理リソースを 自動スケーリング構成 と呼びます。
  これにより インスタンスの状態などに基づいた 自動的な スケールアウト・スケールイン が 可能になります。
  AWS における スケーリング・ポリシー に当たるイメージです。

自動スケーリング・ポリシーでは、「メトリクスに応じた動的なスケーリング」、「手動操作によるスケーリング 」に加え、「スケジュールベース の スケーリング」 が可能です。

AWS 経験者の方が OCI で 自動スケーリングを 構成する際に 特に 注意して頂きたいポイントとしては、「インスタンス構成」は、インスタンス作成時のコンピュートのイメージで作成される、ということです。
つまり、コンピュート作成後に 加えた変更（例えば ソフトウェアをインストールする等）は、インスタンス構成に含まれません。

変更を含めたインスタンス構成を作成するには、当該インスタンスから 一度 カスタム・イメージを作成 → カスタム・イメージからインスタンスを作成 → インスタンス構成の作成 という流れが必要になります。

#最後に
いかがでしょうか。コンピュートは、30日間の無償トライアル環境 が 終了した後も ずっと利用することが 可能なサービス となっていますので、是非 実際に 構築してみて 頂けると幸いです。無償トライアル環境 は 下記より お申し込み頂けます。

Oracle Cloud Free Tier：
https://www.oracle.com/jp/cloud/free/