三流エンジニアの落書き帳

さあ、今日も未知という扉を開けてみよう

OCIの勉強メモ~コンピュート編~

OCIの勉強第4回目は、コンピュートサービスです。

コンピュートサービスはいわゆるIaaS(Infrastructure as a Service)と呼ばれるカテゴリですね。

最近はサーバレス*1というワードをよく聞きますが、コンピュートサービスはクラウドを支える最も基本的な構成要素と言えるでしょう。

シェイプ

OCPU*2の数やメモリサイズのセット、個人的にはインスタンスサイズと言われた方がしっくりくる。

例えば2OCPUで16GBメモリのシェイプといった具合に。

簡単に言えば、AWSにおけるt3.micro, m6i.largeみたいなやつ。

  • Fixedシェイプ

    • そのインスタンスのライフサイクル中にサイズ変更ができない
    • ベアメタルやVMで提供される
  • Flexibleシェイプ

    • サイズ変更可能
    • OCPU/Memory
    • VMのみ
    • CPU 1~64(AMD), 1~32(Intel), 1~80(Ampere)の間でOCPUが利用可能
    • メモリ 1~64GB/OCPU 1024GB(AMD), 512GB(Intel), 512GB(Ampere)

インスタンスの種類

  • VM

    • 最も基本的なインスタンスタイプ
    • 物理的なHWを複数のユーザーで共有する(マルチテナントモデル)
  • ベアメタル

    • ユーザーが占有できる物理的なHW、HWへ直接アクセスできる
    • シングルテナントモデル
    • ユースケースとしては次のようなものが考えられる
      • パフォーマンスが求められるワークロード
      • 仮想化できないワークロード
      • 特別なハイパーバイザーが必要なワークロード
      • BYOLが必要なワークロード
  • Dedicated VM Hosts

バーストインスタンス

EC2のt3インスタンスのようなもの

  • ベースラインパフォーマンスを保証
  • バーストは利用可能な容量に依存
  • たまに発生するCPU使用率のスパイクに備えて、より高いレバレッジでのバーストが可能
  • VM.Starndard.E3.Flexでのみ利用可能
  • メモリはバーストしない

VMインスタンスの購入タイプ

VMインスタンスの購入タイプには、稼働時間に応じて課金が発生する従量課金制の他にもタイプが存在する。*3

容量予約

OCI側のコンピュートインスタンスの在庫が無い場合、コンピュートインスタンスを起動してもできない コンピュートインスタンスの容量予約をしておくと、そういった問題を回避できる

シナリオケース

  • 災害復旧
  • キャンペーン
  • 予期せぬワークロード
  • 計画的な移行と新規立ち上げ
  • 長期プロジェクトのための容量予約

「起動したいときに起動できない」といった問題を解決するための機能と考えればいい。

制限

  • 特定のADに関連付けられる
  • ADから別のADへの移動は不可
  • 専用VMホストは利用不可
  • 容量の設定で定義されたシェイプに限定されたインスタンス
  • 容量の作成時にすでに在庫が無い場合は、容量の作成が失敗する

特に容量予約は特定のADに関連付けられ、別ADへの移動はできないというのは大事なポイント。

コンピュートイメージ

いわゆる起動ディスクというものでOSやソフトウェアが含まれている。

コンピュートイメージにはいくつか種類がある。

  • Oracle提供イメージ

  • カスタムイメージ

    • いわゆるAWSのAMI(Amazon Machine Image)のようなもの
    • 1回イメージを作っておけば、その後何度でも利用可能
    • カスタムイメージの上限サイズは300GB
    • Windowsのカスタムイメージは、テナントの外にエクスポートできない
  • マーケットプレース

  • 独自イメージ

    • いわゆるBring Your Own Imageというやつ
    • Lift&Shiftのクラウド移行(例: オンプレミスの環境のイメージを作成し、OCI Object Storageに保存)
    • Emulation Mode/Paravirtualized/Native Modeをサポート
    • 利用できるイメージには制限があるので事前にマニュアルを読んでおくとよい

インスタンス構成・プールと自動スケーリング

自動スケーリングを利用することで、負荷に応じてインスタンス数を自動で増減できる。

これにより、急な負荷の上昇時にインスタンスを増やす、負荷が落ち着いてきたら不要なインスタンスは削除する、といったことが可能となり伸縮性やコスト効率の良いサービスを構築することができる。

その時に必要となるテンプレートが、インスタンス構成で次のような情報を含んでいる。(AWS Auto Scalingにおける起動テンプレートのようなもの)

  • OSイメージ
  • メタデータ
  • シェイプ
  • vNICs
  • ストレージ
  • サブネット

インスタンス構成を作成したら、インスタンスプールを構成する。

インスタンスプールを作成することで、インスタンス構成で定義されたインスタンスを、設定したインスタンス数で自動的に起動されるようにできる。

インスタンスプールには、最小インスタンス数や初期のインスタンス数、最大インスタンス数を設定する。(Auto ScalingのAuto Scalingグループのようなものというイメージ)

スケーリングポリシー

  • メトリックスベース
    • CPUやメモリの使用率からスケーリングを行うか判断する
  • スケジュールベース
    • 予め決められたスケジュールに沿って、スケーリングを行う

自動スケーリングの構成の流れ

  1. 既存インスタンスからインスタンス構成を作成
  2. インスタンス構成を使用して、インスタンスプールを作成
  3. インスタンスプールを設定
  4. 自動スケーリング構成を作成

Oracle Cloudエージェント

コンピュートインスタンス上で実行されているプラグインを管理するプロセス 使用するにはOracle Cloud Agentソフトウェアをインストールし、プラグインを有効にする必要がある。*4Windows Serverに対してもOS管理サービスを利用できる。

機能

  • CVEの検索
  • パッケージ管理
  • マネージドインスタンスグループ(フリートマネジメント)の作成などが行える
  • ジョブのスケジューリング
  • OS監視のためのメトリクスとアラームの管理

使用例

実行コマンド(Run Command)

Oracle Cloudエージェントソフトウェアが管理するプラグイン管理対象のインスタンス上で、スクリプト内のコマンドを実行できる。

Linux*6スクリプトはデフォルトでBashWindowsスクリプトはバッチファイルとして実行される。

SSH接続をせずにスクリプトを実行したり、スクリプトの結果をObject Storageに送信できたりする。

使用するにはインスタンスにOCIダイナミックグループを作成し、ダイナミックグループを許可するポリシーを作成する必要がある。

まとめ

コンピュートサービスはそれ単体で完結するものではなく、他のサービスと連携されます。(前回のロードバランサもそう)

しっかり情報の整理をしていきたいですね。

*1:FaaS: Function as a Serviceとも呼ばれる.ユーザはサーバ管理をする必要がなく、処理を行うコードのみを管理すれば良い.AWSのLambdaが有名だが、OCIにもFunctionsというサービスが存在する

*2:OCIではvCPUではなくOCPUと呼ばれる物理コアのコア数を指定する.1OCPU=2vCPU

*3:ちょっと調べた感じだと、OCIにはAWSリザーブインスタンスのようなものは無いらしい

*4:別途、IAMポリシーも必要

*5:OS環境のパッチおよび更新の管理

*6:Ubuntuでは使用不可