はじめに

本記事では、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/

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