コーソル DatabaseエンジニアのBlog へようこそ

コーソル DatabaseエンジニアのBlogでは、 コーソル所属のDatabaseエンジニアである 渡部と守田がOracle Databaseを中心としたDatabaseに関わる技術情報を発信しています。

コーソルでは、Oracle Databaseをはじめとするデータベース全般に関わるサービス(コンサルティング、設計、構築など)、オラクル製品のプロダクトサポートサービスを提供しています。 また、不定期で無償の技術セミナーを開催しています。


コーソルでは、Oracle Databaseスペシャリストになりたいエンジニア、 Oracle Database技術を活かして働きたいエンジニアを絶賛募集中です。

hiring.png

コーソルについて知るためには・・・

エンジニアのスキル向上を支援する各種施策については・・・

コーソルのエンジニアの多くが従事する、「Oracle Database サポートエンジニアの仕事」の利点について知るためには・・・。

コーソルで働くことに興味を持たれた方は・・・

2019年2月18日

Oracle Database 19c マニュアル(英語)公開

守田です。

Oracle Database 19c のマニュアル(英語)が公開されています。
Oracle Database 19c Manual
19ctop.PNG

「新機能」を確認したところ、19cでは、自動化やサイレントモードで実施可能な機能が多数実装されているように感じました。
一部抜粋して記載すると、

  • Root Scripts Automation Support for Oracle Database Installation
  • Automatic Resolution of SQL Plan Regressions
  • Ability to Create a Duplicate of an Oracle Database Using DBCA in Silent Mode
  • Ability to Create a PDB by Cloning a Remote PDB Using DBCA in Silent Mode
  • Ability to Relocate a PDB to Another CDB Using DBCA in Silent Mode
  • Simplified Image Based Oracle Database Client Installation
  • Automated PDB Relocation
  • Automated Transaction Draining for Oracle Grid Infrastructure Upgrades

といったところでしょうか。

また、

  • Automatic Indexing
  • Real-Time Statistics
  • High-Frequency Automatic Optimizer Statistics Collection

といった、パフォーマンスに影響を及ぼす可能性がある機能も要注目ですね。

そして注意が必要なのは、上記新機能もそうですが、「エンジニアドシステムまたはCloudのみ使用可能」という機能があるのも、要注意です。
19c1.PNG

2018年12月25日

無事完走!(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018

渡部です。つい(カッとなって)つくった (全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 ですが、25日分すべての日の記事を投稿し、無事完走できました :-)

ちなみに、(全部俺) XXX Advent Calendarは、 (全部俺) Oracle ACE Director Tanel Poder Advent Calendar 2013に 引き続き2回目となります :-)

集中的に一つのテクノロジーを触るのはよいですね。 とはいえ、こういう機会をつくらないと、時間を確保する決意ができないのも事実・・・。 (逆に言うと、宣言+〆切効果を作れば可能にはなる・・・)

25日間ご覧いただいた皆さま、お付き合いいただきありがとうございましたー :-)

サンタからのX'masプレゼント! 非公式OCIステッカー!

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の 25日目のエントリです。

Twitterのやり取りでOCIステッカーの存在を知って、「欲しいなぁ」とつぶやいていたら・・・ 青山方面のサンタさんからX'masプレゼントが届きました! :-)

ocistickers.jpg

どうやら、このかっこいいOCIステッカーはオラクル社員が独自に作成した「非公式」なステッカーのようです!

x401s_w_ocistickers.jpg

早速、愛用しているThinkpad X401sに貼り付け! これで"OCI Ready"な良い年を迎えられそうです :-)

2018年12月24日

OCI Audit

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の24日目のエントリです。

Oracle Cloud Infrastructureには、AWSのCloudTrailに似た監査サービスAuditが用意されています。 特徴は以下の通りです。

  • OCIに対するAPIレベルの操作を記録する。粒度としてはかなり細かく、人間が読むのはかなり辛い。
  • 事前の設定は不要で、自動的に監査ログが取得される。
  • 保存期間はデフォルト60日。変更も可能

Auditで取得視された監査ログは、管理コンソールまたはCLI/SDKから確認できます。

管理コンソールからの表示イメージは以下です。

1224_audit01.png

監査ログの右端の記号をクリックすると、詳細なJSONを表示できます(その意味が分かるかどうかはさておき・・・)。

1224_audit02.png

若干の検索機能がついてはいますが、これでアドホックな分析をするのは辛いです。(もともと監査ログの粒度が細かすぎて、 人間が読むのはかなり辛いこともありますが) AWSのCloudTrailの場合は、監査ログは指定したS3バケットにJSONドキュメントとして出力されるため、AthenaなどのS3上のデータを分析ツールを使用できたのですが、OCI Auditは渡部が調べた限り、そのような方法はできないようでした(ご存知の方がいれば、教えてください!)

このため、複雑な分析を行いたい場合は、CLI/SDKで監査ログをローカルにダウンロードしてから、各種分析ツールを使う必要があります。(OCIの監査ログをAWS S3にアップロードしてAthenaを使うのも手ですが ;-p)

Auditの監査ログは、OCL CLIを使ってダウンロードできます。

$ oci audit event list --start-time=2018-08-12 --end-time=2018-08-14
{
  "data": [
    {
      "compartment-id": "ocid1.compartment.oc1..aaa(略)gqa",
      "compartment-name": "test_comp01",
      "credential-id": "",
      "event-id": "ffb1fd3c-120a-4898-a7f0-37f630668353",
      "event-name": "ListDbSystems",
      "event-source": "DbaaSApiService",
      "event-time": "2018-08-13T04:43:01.043000+00:00",
      "event-type": "ServiceApi",
      "principal-id": "ocid1.user.oc1..aaa(略)sxq",
      "request-action": "GET",
      "request-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0",
      "request-headers": {},
      "request-id": "6631a0f8-9ded-4b2c-8d96-dd93158a/F3A0A526A01895CE9E37B6CF9AED5BD4/8B00FE2F3DDA260D6238C7A6E726C528",
      "request-origin": "10.192.99.7",
      "request-parameters": {},
      "request-resource": "/20160918/dbSystems",
      "response-headers": {},
      "response-payload": {},
      "response-status": "200",
      "response-time": "2018-08-13T04:43:01.080000+00:00",
      "tenant-id": "ocid1.tenancy.oc1..aaa(略)faa",
      "user-name": "ryota.watabe@(略)"
    },
    {
      "compartment-id": "ocid1.compartment.oc1..aaa(略)gqa",
      "compartment-name": "test_comp01",
      "credential-id": "",
        :

2018年12月23日

サービスゲートウェイ

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の23日目のエントリです。

意図しない外部への/外部からのアクセスを防ぐことができるという観点で Privateなサブネットは便利ですが、以下の状況がありがちです。

  • インターネットへのアクセス/インターネットからのアクセスはできないようにしたい
  • でも、VCN外部のOracle Cloudのサービスは利用したい。

上記のような状況にサービスゲートウェイを使えます。 サービスゲートウェイは、Privateなサブネット内のインスタンス(VM)から、 VCN外部のOracle Cloudのサービスを利用できるようにする機能です。

1223_svgw01.png

Oracle Cloudのサービスゲートウェイは、ひらたく言うと、AWSにおける「VPCエンドポイント」に相当します。 (ネーミングはOracle Cloudの「サービスゲートウェイ」の方がわかりやすいと思う :-) )

ただし、現状対応しているサービスはObject Storageのみです。 検証したところ、Privateなサブネット内のインスタンス(VM)でOCI CLIを実行すると、Object Storageの機能は使えましたが、 Object Storage以外の機能は使えませんでした。

サービスゲートウェイは、Databaseインスタンスに有用です。 Databaseインスタンスは、通常Privateなサブネットに配置します。サービスゲートウェイを使用することで、DatabaseインスタンスのデータベースバックアップをObject Storageに出力することができるようになります。(もちろんNATゲートウェイでもOK)

サービスゲートウェイとNATデートウェイを比較した表を以下に示します。

1223_svgw02.png

なお、現状ではサービスゲートウェイの設定項目はほとんどなく、有効(Allow Traffic)/無効(Block Traffic)のみです。 中継するOracle Cloudサービスを追加可能にはなっていますが、そもそも現状対応しているサービスはObject Storageのみですから、実質的に意味がありません。

また、サービスゲートウェイは、ユーザーによる管理は一切不要なmanangedサービスとして提供されています。NATゲートウェイと同様に、名称には"ゲートウェイ"が含まれますが、Computeインスタンスのような実体はなく、実体は仮想ルーターの設定だと思われます。

2018年12月22日

NATゲートウェイ

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の22目のエントリです。

Oracle Cloud Infrastructureに最近(2018年10月)、NATゲートウェイが導入されました。 これは、Privateなサブネット内のComputeインスタンス(VM)から、インターネットへの通信を可能にする機能です。 AWSのVPCにも、同様の機能を持ち、同じ名前のNATゲートウェイがあります。

1222_natgw01.png

Privateなサブネット内のComputeインスタンスであっても、ソフトウェアのアップデートなどでインターネット上のサーバに接続したいケースはあるでしょうから、このような場合は有効な機能と思います。(とはいえ、インターネット上の全てのサーバへの接続を許可するのもセキュリティの観点で気になりますから、用途に応じた特定のサーバーのみ接続を許可するようにセキュリティルールを構成することになるでしょう)

さて、インターネット通信というと、インターネットゲートウェイ(IGW)との違いが気になりますが、両者を比較したのが以下です。NATデートウェイは、あくまでもVCN(=Oracle Cloud)からインターネット方向への接続(片方向、外方向)にのみ使用可能な点に注意してください。

1222_natgw02.png

また、NATゲートウェイは、ユーザーによる管理は一切不要なmanangedサービスとして提供されています。 名称には"ゲートウェイ"が含まれますが、Computeインスタンスのような実体はなく、実体は仮想ルーターの設定だと思われます。

NATゲートウェイの構成手順は以下に記載されています。

構成手順の概要は以下の通りです。

  • NATゲートウェイを作成する
  • サブネットのルートテーブルにNATゲートウェイへのルートルールを追加する
    • 通常 0.0.0.0/0のトラフィックを作成したNATゲートウェイへルートする
  • サブネットのセキュリティルールにインターネット向けのトラフィックを許可するegressルールを追加する
    • 通常 0.0.0.0/0のアウトバウンドトラフィックを許可する

インターネットゲートウェイを使用する場合と異なり、ComputeインスタンスにPublic IPアドレスを割り当てる必要はありません。

なお、現状ではNATゲートウェイの設定項目はほとんどなく、有効/無効のみです。

NATゲートウェイ導入前は、NATインスタンス(NATを構成したComputeインスタンス)を用いてNATを実現していました。 NATインスタンスでは、パッチ適用や可用性確保などを利用者の責任で行う必要がありましたから、managedサービスであるNATゲートウェイを利用すると、これらの作業から解放されます。

2018年12月21日

OCIとTerraform / サンプルvcn_full.tfで構成されるVCN

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018Oracle Cloud Advent Calendar 2018 の21日目のエントリです。

クラウドインフラの利点の1つに、CLIなどを駆使するとプログラミングのような感覚でインフラを構成できる点があります。 しかし、技術的に可能であることと、適切であるかは別問題です。

Oracle Cloudやクラウドに限った話ではありませんが、インフラは多くの種類の要素(リソース)から構成され、それぞれが整合している必要があります。このような状況において、構成要素(リソース)を1つ1つCLIで作成し、それぞれを繋ぎ合わせてゆくことは非常に大変な作業です。

Terraformを使用すると、この問題を解決することができます。

Terraformは、定義ファイルに従い、インフラを構成する複数のリソースを一括で構築してくれるツールです。 リソースの相互関係の整合性も維持してくれます。ひらたく言うと、多数のリソースIDをうまい具合に管理してくれるため、あるリソースのリソースIDを取得して、そのリソースが依存する別のリソースにそのリソースIDを設定して・・・という作業から解放されます。

1221_terraform01.png

1221_terraform02.png

率直にいって、Terraformによるインフラ構築を経験すると、CLIによるインフラ構築には戻れません。もちろん、CLIが有効なケースもあるとは思いますが、複数種類のリソースを組み合わせてインフラを構築する場合(たいていの場合はそうでしょう)、Terraformが圧倒的に楽です。例えば、一般的な用途のVCNを構築することを考えると、最低でも以下のリソースを作成する必要があります。これらをCLIで1つ1つ作成してゆくのはかなり大変です・・・が、Terraformを使えば、"terraform apply"コマンド一発で作成できるのです :-)

  • VCN (あたりまえ!)
  • サブネット : おそらく最低6つ(3可用性ドメイン x (Web+DB))
  • セキュリティリスト : たいてい最低2つ(Web用、DB用)
  • ルートテーブル: 最低1つ(デフォルト)
  • インターネットGW: 1つ

(作った後の話もありますが、とりあえずは作る話に限定してます・・・)

このような便利なTerraformなのですが、Terraformを用いてOracle Cloud Infrastructureインフラ構築を行うためには、Terraform Provider for Oracle Cloud Infrastructureを導入する必要があります。これはTerraformのプロバイダの1つで、OCI固有の処理をつかさどる役割を持っています。

インストール方法などは以下のURLなどを参考にしてください。

リソースの構成を定義するファイル(*.tf)のOCI向けサンプルは以下に用意されています。

かなり多くのサンプルファイルが用意されているので、初めて学ぶときの参考になるかと思います。

個人的には、TerraformはVCN構築から使い始めるのが良いと考えています。上記の通り、VCNの構成要素が多いため、整合性をもって構成するのが大変だからです。TerraformでVCNを構築するには、vcn_full.tfが参考になります。

1221_terraform04.png

1221_terraform05.png

(理想を言うなら、Terraformで定義した内容が自動的に↑のような図で出力される機能があると最高なのですけどねぇ;-p)

参考) 最近(2018年7月)にOCI用のAnsibleモジュールが提供されました。AnsibleもTerraformに似た位置づけのツールですが、渡部はまだこのAnsibleモジュールを試すことができていません。

#OCIではAnsibleとTerraformをどう使い分けるのがよいのだろうか??

2018年12月20日

[番外編] OCI社内セミナーやりました

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の20日目のエントリです。

今週の東京滞在中にたまった仕事を片づけようとしたら時間が無くなってきたので・・・ 今日は軽め+視点を少し変えて・・・

コーソルではほぼ月に1回社内セミナーを開催しています。 もちろんエンジニアのスキル向上が主たる狙いですが、 エンジニアが1つの部屋に集まり、コミュニケーションする機会を設けられるという意味でも有用であると 考えています。

今月は私が講師になってOCIのセミナーを実施しました :-)

1220_inhouse_seminar.jpg

聴講者はOCIの技術の先進性に大きな関心を示してくれましたよ :-)

2018年12月19日

JMESPATH式

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018 の19日目のエントリです。

OCI CLIやAWS CLIは戻り値としてJSONデータを返すため、JSONデータの操作ができる必要があります。

OCI CLIやAWS CLIでは、JSONデータの操作にJMESPATH式を使います。 しかし、JSONデータの構造や操作は、データベースエンジニアが慣れ親しんでいるリレーショナルモデルと大きく異なるため、理解しにくい部分があります。OCIそのものの内容ではありませんが、OCI実務には必要であるため、また自分で明確に理解するため、JMESPATH式について整理してみました。 (実は(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の記事で一番時間をかけて書いた記事!)

JSONデータの論理構造

まず、そもそもJSONデータがどのような構造をしているのかを整理しておきます。

1217_jmespath01.png

特徴は以下です。

JSON論理操作の処理ステップ

このような形式のJSONデータを、JMESPATH式で処理していくわけですが、処理内容は以下の2つの論理的な操作に分解されると渡部は整理しました。(これは渡部の考えであり、一般的に認められたものではありません(たぶん))

1217_jmespath02.png

  1. rootからパスを辿り、JSONデータから「部分JSONデータ」を抜き出す
  2. (変換が必要な場合、)パスを辿って抜き出した「部分JSONデータ」を欲しい形式のJSONデータに変換する

スライドの「JSON論理操作」および「部分JSONデータ」という用語は、渡部が独自に考えたもので一般的な用語ではありません。

1. rootからパスを辿り、与えられたJSONデータから「部分JSONデータ」を抜き出す

JSONデータのツリー構造のrootからパスを辿り、与えられたJSONデータから「部分JSONデータ」を抜き出します。 これは比較的直観的にわかりやすいと思います。

1217_jmespath03.png

1217_jmespath04.png

ただし、抜き出した「部分JSONデータ」をこの後の変換ステップで使用しますので、 辿るパスの「深さ」は適度なレベルにしておき、変換に必要な全てのデータを含む「部分JSONデータ」が得られるようにしておく必要があります。

2. (変換が必要な場合、)パスを辿って抜き出した「部分JSONデータ」を欲しい形式のJSONデータに変換する

抜き出された「部分JSONデータ」が欲しい形式のデータであれば、そこで処理を終了してよいのですが、 抜き出された「部分JSONデータ」が欲しい形式のデータでない場合、欲しい形式に変換する必要があります。

「部分JSONデータ」が、objectの場合とarrayの場合で変換に使える方法が異なるため、それぞれについて説明します。

2-a. 部分JSONデータがobjectの場合

部分JSONデータがobjectの場合は、比較的わかりやすいと思います。objectに含まれるデータを指定すれば、直観的に欲しい形式に変換できるはずです。

1217_jmespath07.png

1217_jmespath08.png

2-b. 部分JSONデータがarrayの場合

部分JSONデータがarrayの場合、arrayには複数の要素(element)が含まれるため、以下のステップで変換を行います。

  1. どの要素を処理対象にするかを選ぶ
  2. それぞれの要素をどのように変換するかを決める
  3. 変換したそれぞれの要素をarrayにまとめる

1217_jmespath09.png

1217_jmespath10.png

1217_jmespath11.png

1217_jmespath12.png

1217_jmespath13.png

パイプ

以上が基本的なJSON論理操作です。ただし、JSON論理操作を実行した結果得られたJSONデータに対して、さらにJSON論理操作を適用したい場合もあります。その場合はパイプを使用できます。

1217_jmespath14.png

上記以外にもファンクションや、データのソートなどの操作がありますが、これらについては概念的に難しいものではないので説明は割愛します。ここまで理解できれば、あとは大丈夫なはず!

2018年12月18日

Oracle Autonomous Data Warehouse CloudとRedShiftの価格比較

渡部です。これは、(全部俺) Oracle Cloud Infrastructure Advent Calendar 2018の18日目のエントリです。

最近のOracle OpenWorldではお約束気味になっていますが、今年のOracle OpenWorld 2018でもラリーエリソン氏からAWSを意識(挑発?)した発言がたくさんありました。 以下は Oracle OpenWorld 2018 のキーノートスピーチで Oracle Autonomous Data Warehouse Cloud(以下ADWC)とAmazon Redshift(以下Redshift)の価格性能比を比較していた箇所です。 ( https://www.oracle.com/database/autonomous-database.html より)

1218_adwc_redshift.png

Oracle Autonomous Data Warehouse Cloudがリリースされてしばらく時間がたっていますが、 個人的に気になっていた部分でもあるので、Advent Calendarの機会を生かして Oracle Autonomous Data Warehouse CloudとRedShiftの価格体系と実際の価格について調べてみようと思います。

ADWCの価格体系

まず、ADWCの価格体系についてです。

  • https://cloud.oracle.com/en_US/datawarehouse/pricing

上記を参考にポイントをまとめます。

  • ストレージ(データを保管する部分)とインスタンス(起動する部分)が別々に課金されます。
  • ストレージは TB・月 単位で課金されます。
    • 検証の観点(自分の観点!)ではもう少し粒度の細かい単位で課金してほしいところですが、いろいろ事情があるのでしょう・・・
  • インスタンスは OCPU・時間 単位で課金されます。

Redshiftも含めて、表形式でまとめたのが以下です。Redshiftは課金やスケールアップがノード単位である点がとても特徴的です。

1218_adwc_redshift2.png

価格比較

では価格比較すべく、いざ計算!と思ったところ、ちょうど良いレポートを見つけました :-)

  • Fast and Furious Analytics - A Head to Head Cloud Data Warehouse Solutions Comparison
    Viscosity North America released their findings today, from a series of benchmark tests that compare Amazon's Redshift (Redshift) and Oracle's Autonomous Data Warehouse Cloud (ADW).
    http://viscosityna.com/data-warehouse-comparison-redshiftadw/
    ※:要メールアドレス登録

なお、比較対象としているスペックは、Oracle OpenWorld 2018 のキーノートスピーチでの比較とほぼ同じです。 (もしかしてこれが元ネタなのだろうか・・・)

  • ADWC : 16 OCPU
  • Redshift : ds2.xlarge 8ノード(= 8 x 4 vCPUs = 32 vCPUs)

このレポートを見る限り、以下が言えそうです。

  • 性能 : ADWCがRedshiftの4倍程度の処理速度
  • 価格 : 割引なしでADWCがRedshiftの7倍程度、ただし、割引(Monthly Flex)を使用すると4倍強程度まで差が縮まる。さらにオンプレミスのライセンスをBYOLすると、同程度になる
    • もちろん、オラクルの場合、これ以外にいろいろ正規以外の割引もあるでしょうから、;-p この数字は参考程度に考えるべきかもしれません。
    • ADWCの費用にはいわゆるテクニカルサポートの費用が含まれます。Redshiftの費用には含まれません。
    • Redshiftにも、リザーブドインスタンスという割引がありますが(1年分先払いで40%OFF)、ノードタイプとリージョンに紐づいており、Monthly Flexに比べると柔軟性がとても低いです。

いわゆる正価ベースで単純に価格を比較すると、どうしてもADWCの費用が大きくなってしまいますが、 割引を適用すると差は縮まり、性能を考慮するとADWCの方が優れている! というのがレポートの主張のようです。

トータルでどう考えるか

価格や価格性能比は正直インパクトがありキャッチーな論点ですが、データウェアハウスの1面にすぎません。 実際のサービス選定ではトータルで評価することになるでしょう。

そもそも、従来のデータウェアハウスシステムと比べるとADWCは非常に低コストです。 ADWCをRedshiftと比較する形をとると、どうしてもコスト面のアピールが弱くなりますが、 Oracle Databaseのこれまでの歴史で培ってきた以下の利点も含めて総合的に判断するべきでしょうね。

  • 高度なSQLサポート
  • ゼロダウンタイム パッチ適用
  • 多ユーザー使用時の優先制御(リソースマネージャ)
  • きめ細やかなセキュリティ制御

#ADWC評価したいなぁ、どなたかPoCやらせてくれる方いらっしゃいませんかね・・・(自腹だと月額最小で$222の縛りがキツイ・・・)

投稿内容は個人の意見であり、所属企業・部門見解を代表するものではありません。

プロフィール

Ryota WATABE / 渡部 亮太

100x100.jpg

  • Oracle ACE
  • AWS Certified Solutions Architect - Associate
  • ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数

Norio Morita / 守田 典男

Norio Morita

  • 新しもの好きな Oracle Fighter。
  • 保有資格 : ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数