皆さま、こんにちは！ShiinaKです。
今回も、Oracle Cloud 公式ホームページに最近掲載されたリリース情報をご紹介します。
前回同様に日本では未対応のものもあり全てが日本のリージョンで使える訳ではありませんが、海外の最新情報をGETできるチャンスですので是非ご覧ください！
本記事の目次
- 7/8 E3 Compute shapesがインド西部（ムンバイ）リージョンで利用可能に
- 7/10 コンピュートシェイプのサービス制限を、コアごとの制限とクォータに置き換える
- Oracle NoSQL Database Cloudが新しいリージョンで利用可能に
- 7/13 コンピュートインスタンス用のSSH鍵ペアを自動的に生成
- 7/14 ベアメタルと仮想マシンDBシステムは秒単位の課金を利用するようになった
- 7/15 Oracle Cloud Infrastructure Auditサービスを利用したKubernetes APIサーバーの監視に対応
7/8 E3 Compute shapesがインド西部（ムンバイ）リージョンで利用可能に
VM.Standard.E3.Flex shape と BM.Standard.E3.128 shape がインド西部（ムンバイ）リージョンで利用可能になりました。
詳しくは、Flexible Shapesをご覧ください。
7/10 コンピュートシェイプのサービス制限を、コアごとの制限とクォータに置き換える
コンピュートインスタンスのサービス制限が、個々のシェイプレベルではなく、シェイプシリーズのOCUレベルで適用されるようになりました。
また、Computeシェイプのコアベースのコンパートメントクォータが利用可能になりました。
これらのアップデートにより、Computeリソースが課金されるのと同じ方法で、OCPUとGPUに基づいてComputeリソースを管理できるようになりました。
サービス制限
以前は、Compute インスタンスのサービス制限は、各シェイプに適用されていました。
例えば、VM.Standard2.1シェイプ、VM.Standard2.2シェイプ、BM.Standard2.52シェイプでは、サービス制限が個別に設定されていました。
これにより、Computeインスタンスのサービス制限は、シェイプシリーズ内のすべてのシェイプのOCPUまたはGPUの合計数をカバーするようになりました。
さらに、サービス制限は、類似の仮想マシン（VM）シリーズとベアメタルシリーズについて集計されます。
たとえば、新しいコアごとのサービス制限の1つは、VM.Standard2とBM.Standard2シリーズのすべてのシェイプのOCPUの合計数をカバーしています。
既存のサービス制限は、Oracle Cloud Infrastructure によって同等のコアごとの制限に移行されます。
たとえば、 SeriesA.ShapeX.5cores という仮想シェイプのサービス制限が 1 で、 SeriesA.ShapeY.10cores という別の仮想シェイプのサービス制限が 2 であるとします。
新しいシリーズAのサービス制限は合計25 OCPU（5 OCPU×1 ShapeX、10 OCPU×2 ShapeY）で、この制限をシリーズA.ShapeX.5coresとシリーズA.ShapeY.10coresの両方のシェイプに割り当てることができます。
シェイプベースのサービス制限は引き続き使用できますが、これらの制限はコアごとの等価な値に変換されます。
非推奨のシェイプベースのサービス制限を表示するには、コンソールの［制限、クォータ、および使用状況］ページで［非推奨の制限を表示］チェックボックスを選択します。
新しいサービス制限の詳細については、Service Limitsを参照してください。
コンパートメントクォータ
コンピュートシェイプにコンパートメントクォータを設定して、シェイプシリーズ内のすべてのシェイプのOCPUsまたはGPUの合計数をカバーし、類似のVMおよびベアメタルシリーズについて集計できるようになりました。
コアごとのコンパートメントクォータは、アベイラビリティ ドメイン スコープで利用できます。
個々のシェイプをカバーする既存のコンパートメントクォータに変更はありません。
新しいコンパートメント クォータの詳細については、Compartment Quotasを参照してください。
Oracle NoSQL Database Cloudが新しいリージョンで利用可能に
Oracle NoSQL Database Cloudは以下のリージョンで利用できるようになりました。
・韓国北部（春川）
7/13 コンピュートインスタンス用のSSH鍵ペアを自動的に生成
コンソールを使用してコンピュートインスタンスを作成する際に、Oracle Cloud Infrastructure が生成する Secure Shell (SSH) キーペアを使用できるようになりました。
これにより、Linux インスタンスを起動する前に自分で SSH 鍵を作成する必要がなくなりました。
このキーペアは OpenSSH と互換性があり、UNIX ベースのシステム (Linux および OS X を含む)、Windows 10、Windows Server 2019 にインストールする必要があります。
詳細については、Creating a Linux Instanceの作成を参照してください。
Autonomous Exadata Infrastructureリソースは、毎秒の課金を使用するようになりました
Autonomous Exadata Infrastructure リソースは、最低使用期間を48時間とした秒単位の課金を使用するようになりました。
これにより、Infrastructure リソースの1時間ごとの課金が廃止されました。
OCPU リソースは秒単位で課金され、最低使用期間は 1 分です。
7/14 ベアメタルと仮想マシンDBシステムは秒単位の課金を利用するようになった
ベアメタルDBシステムと仮想マシンDBシステムでは、秒単位の課金が採用されるようになりました。
これは、OCPUとストレージの使用量が秒単位で課金されることを意味し、仮想マシンDBシステムでは最低使用時間が1分、ベアメタルDBシステムでは1時間となっています。
これにより、これらのリソースに対する1時間単位の課金が廃止されました。
Oracle Java Cloud ServiceアプリケーションをOracle WebLogic Server for Oracle Cloud Infrastructureインスタンスに移行する
Application Migration を使用して、Oracle Java Cloud Service アプリケーションを Oracle WebLogic Server for Oracle Cloud Infrastructure インスタンスに移行できます。
詳細については、Manage Migrationsを参照してください。
Exadata Cloud@Customer：OCPU使用量の秒単位の課金
Exadata Cloud@Customer Gen2では、OCPUに秒単位の課金を採用しています。
つまり、OCPUの使用量は秒単位で課金され、最低使用期間は1分です。
GitLabによるTerraform設定ファイルの保存をサポート
configuration source providers を使えば、Terraform の設定ファイルを GitLab に保存することができます。
GitLabでファイル用の設定ソース・プロバイダを作成する手順については、 To create a configuration source providerを参照してください。GitLabで設定からスタックを作成する手順については、To create a stack from a fileを参照してください。
Autonomous Data Guardを使用して、共有 Exadata Infrastructure上のスタンバイ Autonomous データベースをプロビジョニングする
Autonomous Data Guard を使用して、データ保護とディザスタリカバリのために、共有 Exadata Infrastructure上のスタンバイ (ピア) Autonomous Database をプロビジョニングできるようになりました。
詳細については、 Using a Standby Database with Autonomous Databaseを参照してください。
韓国中部（ソウル）リージョンでData Integrationが可能に
データ統合は、韓国中部（ソウル）リージョンで利用できるようになりました。
詳細については、 Data Integrationと Data Integration APIを参照してください。
7/15 Oracle Cloud Infrastructure Auditサービスを利用したKubernetes APIサーバーの監視に対応
現在、Container Engine for Kubernetes で実行された操作が表示されているのと同様に、Oracle Cloud Infrastructure Audit サービスを使用して、Kubernetes API サーバーで実行されたすべての操作をログイベントとして表示できるようになりました。
Kubernetes API サーバーは、サービスの作成など、kubectl などのツールを使用してクラスタに管理上の変更を加えた場合に監査イベントを発行します。
Kubernetes API サーバーのイベントは、2020年7月15日以降に作成されたクラスタの Oracle Cloud Infrastructure Audit サービスにのみ表示されることに注意してください。
詳細については、Monitoring Container Engine for Kubernetes and the Kubernetes API Serverを参照してください。
※上記はOracle Cloudの公式ホームページよりOracle Cloud Infrastructureのリリースノートを参照し一部引用しています。