きそくただしいせいかつ

日々の生活のペースセッター

Athlon 200GE で PC を組んだ

今日は仕事っぽくないです。

去年の年末に PayPay 祭りやってたので、 PC を組みました。前々から AMDRyzen 系で一台と思いつつも、「会社の PC あればいらないしなー」とか先延ばしにしてたんですが、背中を押されてつい。

最初に自作 PC を組んでから15年ぶり (その当時は無印 Athlon の 900Mhz) だったので、秋葉原の TSUKUMOeX. で会話しつつパーツを一式選んでもらいました。余談ですが、資本がヤマダ電機になったとはいえ 15年前と同じ場所・姿で佇んでる TSUKUMOeX. すごい。そして PayPay 祭りで大混雑。

f:id:k_kane:20181209215624j:plain
TSUKUMOeX. で買ったパーツ一式

上記に Windows 10 Home つけて 57,726 円(税込)でした。 PayPay で 20% 帰ってくることを考えると安い。これに別途 Philips の 226E SoftBlue (21.5インチワイド) を NTT-X で 10,980円で買いました。

Athlon 200GE の場合、マザーボードとの組み合わせでグラフィック出力先に制限が出るので、そのあたり見てもらえて楽でした。 AB350 / B350 チップセットでもいいのかなとも思ったものの、結果的には Firmware 更新等で悩まなくて済んで B450 で結果オーライです。

ストレージ M2 接続にして、グラフィックもオンボードなので、組んでみたらガラガラでした。ケースとマザーボードのネジ穴が結構キツキツでそこだけ苦労しましたが2時間弱で組んで、起動。

f:id:k_kane:20181215170503j:plain
組んでみた

なんのエラーもなく Windowsインストーラー表示されて、こんなに簡単なのかイマドキ!と思うことしきり。

ただ、その後使ってると、一回目の起動で HDMI が出力されてこない(電源の LED とストレージのアクセスLED は点灯してるので起動してるっぽいが画面がでない。強制的に電源きって再度入れると出る)事象に遭遇し、起動オプションとか見てたんですが、改善せず。 とりあえずで、 APP Shop 入れてマザーボードFirmware を 1.1 -> 1.7 に更新したら再発しなくなりました。

この後で DeskMini A300 が出たので今ならそれ買うかもなーとはちょっと思いますが、そこそこ静かですし安定もしていて特にストレス感じることもないので、総じて満足です。今から Steam でゲームしてみようと思う次第。新しい PC を入れるとゲームしたくなりますね。

OCI Monitoring で CPU 監視して PagerDuty に投げる

OCI (Oracle Cloud Infrastructure) の監視について第2段です。

OCI の Monitoring 機能ではメールでの通知のほか、 PagerDuty に連携をすることができます。

PagerDuty については、インシデント管理の Cloud Service で、日本ではまだあまりユーザは多くないのかもしれませんが、ミクシィやスマートニュースで使われているようです。 PagerDuty導入事例 | PagerDuty by Digital Stacks

PagerDuty のよさげな部分としては、インシデントをスケジュールに基づいてアサインし、管理できるという基本的なところに加え、連携が豊富、という点があるように思います。以下の記事のように Slack / JIRA などのツールに連携するほか、 DataDog や AppDynamics から PagerDuty に投げる、AWS や Azure から PagerDuty に投げる、等他のツールと組み合わせて使うことができます。 thinkit.co.jp

OCI の Monitoring も、単に Alart を上げるというよりも、連携してうまくハンドリングできるところが、おいしい使い方だと思いますので、 PagerDuty に一通り登録までを試してみました。

Digital Stacks さんのページにも Integration の設定までの翻訳記事がありましたので、合わせてご参照ください! pagerduty.digitalstacks.net

PagerDuty のトライアルに登録

PagerDuty ですが Free Trial で 14日間利用できますので、そちらで試してみたいと思います。(商用アカウントは 1ユーザ 9$/月のようです)

PagerDuty | Real-Time Operations | Incident Response | On-Call | PagerDuty の右上の Try Now から試してみます。

PagerDuty のトップページ
PagerDuty のトップページ

Trial の申込画面はシンプルで、名前やメールアドレスなどを入れるだけです。

Trial の申込み画面
Trial の申込み画面

Trial 申し込むとそのままの流れで Setup に進みます。オンボーディングの障壁を下げるいまどきのクラウドサービスっぽい感じです。連携先(連携元?)が選べるようになっており、 Oracle Cloud Infrastructure Monitoring もばっちりあります。

Setup 画面
Setup 画面

Service のセットアップが完了です。

Service のセットアップ完了
Service のセットアップ完了

次に通知のテストをします。 SMS / 電話 / Email で通知のテストができます。一通り試してみたのですが、 Phone Call を選ぶと、国際電話で電話がかかってきます。 ("This is PagerDuty" って電話してくる)

Notification (通知) のテスト
Notification (通知) のテスト

Notification (通知) のテスト
Notification (通知) のテスト

その後 Escalation Policy のセットアップをします。もし Incident が上がって、対処が必要な時に Escalation する先の Policy / ユーザのセットアップができます。後でも細かくセットアップできるので今回は Skip します。

Escalation Policy のセットアップ
Escalation Policy のセットアップ

これで Trial の申込みから、セットアップは完了です。

セットアップの確認画面
セットアップの確認画面

Oracle Cloud Infrastructure Monitoring との連携

ログイン後のトップ画面です。

ログイン後のトップ画面
ログイン後のトップ画面

Configuratuion -> Services と進みます。

Configuration -> Service と進む
Configuration -> Service と進む

登録時に Oracle Cloud Infrastructure Monitoring を追加しているので、 Services に表示されています。 Integrations の列にある、 Oracle Cloud Infrastructure のリンクをクリックします。

Service の一覧
Service の一覧

Oracle Cloud Infrastructure Monitoring の Integration Key が表示されます。 Monitoring から、 PagerDuty に連携するために必要になるので、コピーしておきます。

Integration Key の確認
Integration Key の確認

それでは OCI の画面に戻ります。前回作った CPU 使用率監視を PagerDuty に連携するように編集します。前回作った Alarm の定義をクリックします。

OCI の Alarm Definitions
OCI の Alarm Definitions

右上の Actions ボタンをクリックすると Edit Alarm ができます。

Alarm Definition の Edit
Alarm Definition の Edit

スクロールしていただいて Notifications の欄で Create a Topic をクリックします。

Create a Topic する
Create a Topic する

新しい Topic が作れますので Subscription Protocol 欄で HTTPS (PagerDuty) を選びます。先程 PagerDuty 側で確認した Integration Key を入れる欄がありますので、そこに Key を入力し Create topic and subscription (青いボタン) をクリックします。

PagerDuty へ通知する Topic を作る
PagerDuty へ通知する

TOPIC として新しく作った PagerDuty 連携の TOPIC が選ばれていれば OK ですので Save alarm をクリックします。

TOPIC の選択
TOPIC の選択

再度 Pager Duty 側に戻ります。 Configuration -> Service のサービス一覧画面で 1つ Incidents が Trigger されているかと思いますので Service の列の Oracle Cloud Infrastructure Monitoring Service のリンクをクリックします。

Incident が Trigger されている
Incident が Trigger されている

Title を確認すると、 OCI の Notifications の登録確認が Incident として登録されています。 SHOW DETAILS をクリックします。

通知の登録確認が Incident としてあがっている
通知の登録確認が Incident としてあがっている

CUSTOM DETAILS の欄に、確認用の URL が記載されているのでそれをクリックすると登録確認が完了します(このあたりメールでの通知でも一緒ですね)。

Incident の Detail を確認
Incident の Detail を確認

クリックすると JSON そのまんまの画面が表示されて確認が完了します。

確認されたことのメッセージ
確認されたことのメッセージ

同じ通知はメールにも届いていました。どちらで確認してもいいものと思います。

メールへの登録確認 Incident 通知
メールへの登録確認 Incident 通知

PagerDuty への Alarm の発報

最後に Alarm が発報されたらどのように見えるか確認しておきます。前回 と同じ Alarm を使っているので、人為的に CPU 使用率を張り付かせて Alarm を飛ばしました。

Incident としては一覧で表示される形になり、ここから、 Acknowledge したり Reassign したり、 Resolved にしたりできます。今回ユーザを一人しか入れていないので、全部私にアサインされてしまいますが、スケジュール等が組めるので、この時間に来たら誰、等細かく設定ができます。

Incident の確認
Incident の確認

Alarm の Detail を見ると、 Mail での通知と同じように JSON で詳細が連携されています。

Alarm の詳細
Alarm の詳細

まとめ

今回は PagerDuty の連携を試してみました。 OCI の Monitoring 機能だけですとメールと PagerDuty にしか現状飛ばせないのですが、 PagerDuty に連携すれば、その先既存のインシデント管理と連携したり Slack に飛ばしたりもできるのかなと思います。また PagerDuty 自体にモバイルアプリもあるので、そこで問題を Acknowledge したり、Incident の上がってる状況を確認したりもできそうです。

また、PagerDuty 単体でも、スケジュールやエスカレーションのポリシーの設定ができるので、数人の小さいチームでのインシデント管理・運用に便利な印象を持ちました。一部のシステム、立ち上げたばかりのサービスをクラウドに持っていって少人数で回すのであれば PagerDuty に投げて見れる人で監視対応をしていく、というのはよさそうです。

OCI Monitoring で CPU 監視してメール通知

2月末のサービスアップデートで、 OCI に Monitoring 機能が追加されました。リリースの情報は以下の blog などもご参照いただくとして、実際に使ってみたいと思います。

Oracle Cloud Infrastructure Blog(翻訳): [OCI]2019... | Oracle Community

使ってみたレベルの確認として、 OCI Monitoring で CPU 使用率のアラートメールを飛ばすところまでやってみたいと思います。

最新の Oracle 提供のイメージでは、Monitoring の監視用のエージェントがデプロイされているため、特に考えることなく Monitoring が利用可能です。

Alarm の定義の作成

OCI メニューの Monitoring -> Alarm Definitions より Alarm の定義が可能です。

Alarm Definition の作成
Alarm Definition の作成

Create Alarm から Alarm を作成します。

Create Alarm により Alarm 作成
Create Alarm により Alarm 作成

Alarm の名前、 Alarm の重要度 (SEVERITY)、 Alarm Body (Alarm の説明) を入力します。

Create Alarm の画面
Create Alarm の画面

Create Alarm の画面(入力後)
Create Alarm の画面(入力後)

スクロールして、メトリックの定義を行います。画面をなんとなく見ていただけるとわかるかと思いますが、メトリックの対象 (NAMESPACE)、METRIC の名前、METRIC データをまとめる (Aggregate する) 間隔 (最短は 1分)、まとめる際の方法を選びます。また DIMENSION として、 resourceId を選択すると特定のインスタンスの指定が可能です。 Trigger Rule は Alarm を上げる際のルールになります。

Metric の定義
Metric の定義

あるインスタンスの CPU 使用率が 80% を超えたら、 Warning の Alarm を発報するルールとしました。 DIMENSION VALUE は OCID での指定になるのでマスクしています。(インスタンスのページに行って OCID を取ってくる必要があるので少し面倒です(ここは今後改善でしょうか)) 3/17 追記 : DisplayName という形で指定すれば Instance 名でも設定可能なようです(失礼しました)。

Metric の定義 (入力後)
Metric の定義 (入力後)

更にスクロールすると、先程の Trigger Rule の定義が確認できます。また、通知情報 (Notifications) を定義します。ここでは Notifications サービスの Topic を指定します。今回 Topic を予め作っていませんので Create a topic から作成します。

Notifications の指定
Notifications の指定

Create a topic すると、 TOPIC の名前、説明を入力できます。また通知先は PagerDuty もしくはメールが選択可能です。

Create a new topic
Create a new topic

今回は私のメールアドレスに通知するようにします。

Create a new topic (入力後)
Create a new topic (入力後)

作成した Topic を Notifications に指定します。これで一通りの Alarm 設定ができたので、 Save Alarm で定義します。

Topic の選択
Topic の選択

これで Alarm の定義が作成できました。

Alarm の定義
Alarm の定義

Notifications で指定したメールアドレスの確認

Notifications で Topic を作る際に、通知先メールアドレスを指定しましたが、自動的に確認用のメールが送信されています。このメール内のリンクをクリックしないと、 Notifications から通知が飛びませんので、先に確認しておく必要があります。

Notifications の確認メール
Notifications の確認メール

確認メール内のリンクをクリックすると、以下のような Web ページが開き、これで登録完了です。

Notifications への登録確認
Notifications への登録確認

CPU 使用率を上げ、Alarm と Notifications 通知の確認

監視対象にしたインスタンスにて、以下のコマンドにより CPU 負荷をかけます。 1 OCPU のインスタンスを利用していますので2並列で実施することにより、 mpstat での確認の通り負荷を 100% に近づけることができます。

[opc@kokane-ol7-01 ~]$ yes > /dev/null &
[1] 19270
[opc@kokane-ol7-01 ~]$ yes > /dev/null &
[2] 19272
[opc@kokane-ol7-01 ~]$ mpstat 1
Linux 4.14.35-1844.1.3.el7uek.x86_64 (kokane-ol7-01)    03/02/2019      _x86_64_        (2 CPU)

05:18:04 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:18:05 AM  all   99.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
05:18:06 AM  all   98.49    0.00    1.51    0.00    0.00    0.00    0.00    0.00    0.00    0.00

OCI の Monitoring のリリースに合わせ、各インスタンスの Metrics ページでも負荷が確認できます。上記負荷がけの直後から、 CPU 使用率(右上)のグラフが急上昇しています。

CPU Metrics
CPU Metrics

この後少し待ち、 Alarm Definitions を確認すると、先程定義した Alarm が Firing の状態になっていることが確認できます。また Alarm history の画面からも赤線 (Alarm の Trigger Rule のライン、 80%) を超えていることが確認できます。

Alarm の Firing の確認
Alarm の Firing の確認

また、 Monitoring -> Alarm Status の画面からも、 Alarm が Warning で上がっていることが確認できます。

Alarm Status の確認
Alarm Status の確認

メール通知のほうも確認しておきます。Alarm が上がった直後、以下のようなメールが届いていました。メールの件名は Alarm の名前になっています。本文としては JSON 形式で送信されますので、パーサー等で処理しやすい形になっています。

通知メール
通知メール

このあと、先程の CPU 負荷がけ Process を止めると、以下の通り Alarm の定義も OK ステータスに戻ります。

Alarm Definition が OK に戻る
Alarm Definition が OK に戻る

また、メールのほうにも、 FIRING_TO_OK という形で、解消した旨のメールが届きました。

FIRING_TO_OK のメッセージ
FIRING_TO_OK のメッセージ

まとめ

今回は、OCI Monitoring の Alarm 機能を試してみましたが、なんとなく画面を見ながら設定し通知を受け取ることができました。メール通知に関しても、処理の自動化に組み込みやすい JSON で送られてきますので、監視状況をトリガーとした処理等も実装可能かと思います。

今度は PagerDuty 連携を試してみたいと思います。

Oracle Linux Storage Appliance を使ってみる

Oracle Cloud Infrastructure (OCI) の File Storage Service (FSS) は NFSv3 なので、 Windows からもマウントできるといえばできるのですが、 CIFS 環境を用意したい場面もあるかと思います。

そんな需要に対して Oracle では Oracle Linux Storage Appliance という、Linux ベースの SAMBA サーバのイメージを提供しており、 Web UI 等もあるため、簡単に利用することができます。

最近まで OCI の画面からデプロイする方法がなく、若干めんどくさかったのですが、めでたく Oracle Provided Image としてプロビジョニングできるようになりましたので、試してみました。 ドキュメントは以下です。 Oracle® Linux Storage Applianceデプロイメントおよびユーザー・ガイド

Oracle Linux Storage Appliance インスタンスの作成

Oracle Linux Storage Appliance は、 Compute の Instance として立てます。 VM でも BM でも構成可能で、 BM で内蔵の NVMe ストレージがある場合はそちらが Volume として使われ、 NVMe がない場合は Block Storage をアタッチして使います。

Compute インスタンスを立てる
Compute インスタンスを立てる

OS イメージとして Linux Storage Appliance を選択する必要があります。

Change Image Source で OS イメージを変更
Change Image Source で OS イメージを変更

Oracle Images の中にあります。 (あっ、 EM のイメージもある…知らなかった)

Oracle Image として提供
Oracle Image として提供
その他の設定は普通に Compute インスタンスを立てるときと同じです。適宜ご設定ください。あとで ssh ログインするので key も設定しておいてください。

インスタンスが出来上がるまで待つ
インスタンスが出来上がるまで待つ

Oracle Linux Storage Appliance インスタンスへのアクセス

インスタンスができ、アクセスできるようになったら opc ユーザで ssh ログインしてください。

ssh アクセス
ssh アクセス

Web UI にアクセスするために、ローカルに ssh ポートフォワーディング設定をします。ターミナルソフトによって設定が違うかと思いますので、適宜設定ください (Tera Term でやっています)。

ssh ポートフォワーディング
ssh ポートフォワーディング

Web UI は 443 ポート (HTTPS) で公開されていますので、 443 をローカルの 8443 ポートにフォワードします。

リモートの 443 をローカルの 8443 にフォワード
リモートの 443 をローカルの 8443 にフォワード

ローカルのブラウザで 8443 ポートにアクセスします。最初に admin ユーザのパスワードを設定します。 大文字・小文字・特殊文字・数字の組み合わせが求められます。

admin のパスワードを設定
admin のパスワードを設定

設定したらログインします。

admin ユーザでログイン
admin ユーザでログイン

Block Volume のアタッチと Storage Pool 作成

が、インスタンスを立てただけだと、ストレージがないと怒られます。

f:id:k_kane:20190302112433p:plain
ストレージがない、と怒られる

ので、 Block Volume を作ってアタッチします。

Block Volume を作る
Block Volume を作る

インスタンスと同じ AD に構成します。

Block Volume を作る
Block Volume を作る

インスタンスの画面に戻り、 Attache Block Volume します。

Block Volume を Attach
Block Volume を Attach

Block Volume を Attach
Block Volume を Attach

Attach すると自動的に認識するので、Web UI から Storage Pool を作ります。(認識しない場合はブラウザを再起動して、ログインし直していただくとよいかもです)

Storage Pool を作る
Storage Pool を作る

Volume をチェックして、 Add すると、自動的に Pool が作られます。 (Linux インスタンスで見てみると、このタイミングで LVM 作って、 XFS 作っているみたいです)

Storage Pool を作る
Storage Pool を作る

Pool ができると Dashboard で確認できるようになります。

Dashboard
Dashboard
画面上、いろいろと簡易な NAS っぽい画面が確認できると思うので、見てみていただけると雰囲気がつかめるかと思います。 Administration の画面に細かい設定は乗っています。
Administration の画面
Administration の画面

SMB での公開

SMB での公開は Storage の画面から可能です。 Add を押します。

Storage の画面
Storage の画面

公開設定は Share という呼ばれ方をしており、 Share の名前、サイズ、 SMB でアクセスするときのパスなどを設定します。 AD 連携等も設定可能なようですが、今回は Guest アクセスを許容します。

Share を作る
Share を作る

Oracle Linux Storage Appliance のインスタンス内で見てみると、/.lsa というパスに lsa.conf という設定ファイルがあります。 Share を作ると /shares/シェア名 というパスで公開されます。

[opc@kokane-lsa-01 smb]$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb             8:16   0    1T  0 disk
|-lsa-smbtest 252:1    0  200G  0 lvm  /shares/smbtest
`-lsa-__lsa   252:0    0   64M  0 lvm  /.lsa
sda             8:0    0 46.6G  0 disk
|-sda2          8:2    0    8G  0 part [SWAP]
|-sda3          8:3    0 38.4G  0 part /
`-sda1          8:1    0  200M  0 part /boot/efi
[opc@kokane-lsa-01 .lsa]$ ls /.lsa/etc/smb
lsa.conf  lsa.conf.bak
[opc@kokane-lsa-01 .lsa]$ more /.lsa/etc/smb/lsa.conf
[smbtest]
guest ok = False
strict sync = False
sync always = False
browsable = False
read only = False
path = /shares/smbtest
directory mask = 0770
create mask = 0770

Share の Actions のボタンから、各種設定が可能です。今回は Mount Information を確認します。

Share の確認
Share の確認

アクセスに必要な情報が表示されるので、 SMB File Explorer URL をコピーしておきます。

SMB / NFS のマウント情報
SMB / NFS のマウント情報

Windows Server 2016 からのアクセス

OCI 上に立てた Windows Server 2016 から Storage Appliance にアクセスしてみます。事前に VCN の Security List は適切に設定しておく必要があります。

先程コピーしたパスを Explorer でペーストすると、難なくアクセスできました。

Windows からのアクセス
Windows からのアクセス

当然ですが、ファイルもかけました。

test ファイルを書く
test ファイルを書く

まとめ

今回 Linux Storage Appliance を設定してみましたが、 OCI Console からプロビジョニングできるので簡単な印象を受けました。 AD 連携や Object Storage へのバックアップもできるようなので、簡易な CIFS 領域を用意したい場合には選択肢の一つになるかなと思います。ただし、マネージドサービスではないのでインスタンスの監視や管理は運用として考慮する必要があります。

Oracle Instant Client を docker 上で利用して、 ADW へ接続する

Autonomous Data Warehouse Cloud (ADW) を使っていると、ちょっとしたデータや環境の確認のため、 Oracle Instant Client (SQL*Plus など) が使いたい場面があるかと思います。 yum などからもインストール可能なので、入れるのは簡単なのですが、あんまりローカルになんでも入れたくないよな、というときのために、 docker イメージが用意されています。今回はそれを試して見ようと思います。

docker image のデプロイ

まずは docker image をデプロイします。 12.x の docker image は docker hub 上にあるようなのですが、最新のイメージは githubOracle のレポジトリ上にしかなさそうなのでそれを利用します。

Readme はこちらです。 docker-images/OracleInstantClient at master · oracle/docker-images · GitHub

docker とか git は入っている前提でスタートします。そのあたりの良記事はたくさんあると思うので!環境は Oracle Linux 7.6 で試しています。

とりあえず適当なディレクトリに、 Oracle が提要している docker image を git clone で持ってきます。

[opc@kokane-ol7-01 work]$ git clone https://github.com/oracle/docker-images.git

その上で、Oracle Instant Client の docker image のディレクトリに移動し、 docker build します。

[opc@kokane-ol7-01 work]$ cd docker-images/OracleInstantClient/dockerfiles/18.3.0/
[opc@kokane-ol7-01 18.3.0]$ docker build -t oracle/instantclient:18.3.0 .

その後、 docker images で確認すると、 oracle/instantclinent のイメージが確認できます。

[opc@kokane-ol7-01 work]$ docker images
REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
oracle/instantclient   18.3.0              e1ec5b52486e        12 days ago         362MB
oraclelinux            7-slim              c3d869388183        3 weeks ago         117MB

docker image の利用と ADW への接続

まずは接続先の ADW の接続用 Credential ファイルをダウンロードします。もし ADW のインスタンスを立ててみる場合には、システムエグゼさんのブログなどに詳しく記載いただいています。 www.system-exe.co.jp

現在は、 Console の ADW の Detail 画面から、DB Connection ボタンをクリックしてダウンロード可能です。

f:id:k_kane:20190211202427p:plain
ADWの詳細
f:id:k_kane:20190211202445p:plain
Credentialをダウンロード

ダウンロードしたファイルをどこか適当なディレクトリに展開頂き、 sqlnet.ora の DIRECTORY を Credential ファイルをおいた場所に変更します。 (ここでは /home/opc/credentials としました)

WALLET_LOCATION = (SOURCE = (METHOD = file) (METHOD_DATA = (DIRECTORY="/home/opc/credentials")))
SSL_SERVER_DN_MATCH=yes

これで docker run する準備が整いました。github の Readme を参考にしつつ、-e で環境変数 TNS_ADMIN、 -v で Credentials を格納したディレクトリを渡す形で実行します。 (-v の渡し方は冗長なので、もっといい書き方があるのかもしれません。。)

[opc@kokane-ol7-02 credentials]$ docker run -ti --rm -e TNS_ADMIN=/home/opc/credentials -v /home/opc/credentials:/home/opc/credentials oracle/instantclient:18.3.0 sqlplus admin/パスワード@kkadw01_low

SQL*Plus: Release 18.0.0.0.0 - Production on Sun Feb 17 05:29:43 2019
Version 18.3.0.0.0

Copyright (c) 1982, 2018, Oracle.  All rights reserved.

Last Successful login time: Sun Feb 17 2019 05:26:13 +00:00

Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0

SQL> 

まとめ

docker hub に 18.3 がないのが若干手間ですが、簡単に docker 上で sqlplus を動かすことができました。

とはいえ、Oracle Instant Client ぐらいローカルにいれてもいいんじゃない?という場合は、いまどきは yum からインストールできるそうです。 Oracle Instant Client RPMs Now Available on Oracle Linux Yum Server (yum.oracle.com) | Oracle Linux Blog

Autonomous DB を使う上では、このような形で管理用のインスタンスクラウド上に準備したほうがなにかと便利だなと思っている今日このごろです。

オラクルクラウドをラクに使いたい - Autonomous Data Warehouse (ADW) を CLI から作って、大きくする

タイトルのとおりなのですが、 Autonomous Data Warehouse (ADW) という Exadata が1時間単位で使えるクラウドがありまして(雑な説明)、こいつを作る時にもちろん画面から作っても簡単なのですが、記録が残る CLI から作ったほうがいい場合もあると思うので、作ります。 Autonomous Data Warehouse 自体は OCI (Oracle Cloud Infrastructure) に統合されているので、 OCI CLI から作成が可能です。

今回は、以下の記事の 3-4 まで設定ができている前提で、その後の作成操作だけやってみます。
community.oracle.com

インスタンスの作成

インスタンスの作成は非常に簡単で、 Oracle の知識自体も必要ないレベルなのですが、以下のコマンド一発です。

$ oci db autonomous-data-warehouse create 

オプションは以下のとおりです。

【必須のオプション】

  • db-name : DB 名
  • cpu-core-count : CPU 数、最小 1 OCPU(1物理コア)
  • data-storage-size-in-tbs : ストレージ容量、最小 1TB
  • admin-password (管理用パスワード)

【任意のオプションで設定しておいたほうがよさそうなもの】

  • license-model : ライセンスモデル、指定しないと BYOL (保有ライセンスのクラウドへの持ち込み)になるので、新しく ADW を使う場合は指定したほうがいいです
  • display-name : インスタンスの表示名、指定しないと自動生成されて長いので指定したほうがいいです

実際やってみると以下のような感じです。

[opc@kokane-ol7-01 .oci]$ oci db autonomous-data-warehouse create --db-name "adwcli01" --cpu-core-count 1 --data-storage-size-in-tbs 1 --admin-password "XXXXXXXXXXXX" --license-model "LICENSE_INCLUDED" --display-name "adwcli01"
{
  "data": {
    "compartment-id": "ocid1.compartment.oc1..aaaaaaaacdxn6dygelp7ckmxkjkp5ofpjirlay5jbtaizds3hwevcikbl3ua",
    "connection-strings": null,
    "cpu-core-count": 1,
    "data-storage-size-in-tbs": 1,
    "db-name": "adwcli01",
    "db-version": null,
    "defined-tags": {},
    "display-name": "adwcli01",
    "freeform-tags": {},
    "id": "ocid1.autonomousdwdatabase.oc1.iad.abuwcljtemt6oxmbkpgzyqstizl6oihunejtdmm7sjm2voay5x7g55nl2vrq",
    "license-model": "LICENSE_INCLUDED",
    "lifecycle-details": null,
    "lifecycle-state": "PROVISIONING",
    "service-console-url": null,
    "time-created": "2019-01-16T07:27:08.872000+00:00"
  },
  "etag": "67ea59d6"
}

暫く待つと以下のコマンドで、接続名やコンソールの URL が確認できる用になります。

[opc@kokane-ol7-01 .oci]$ oci db autonomous-data-warehouse list
{
  "data": [
    {
      "compartment-id": "ocid1.compartment.oc1..aaaaaaaacdxn6dygelp7ckmxkjkp5ofpjirlay5jbtaizds3hwevcikbl3ua",
      "connection-strings": {
        "all-connection-strings": {
          "HIGH": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_high.adwc.oraclecloud.com",
          "LOW": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_low.adwc.oraclecloud.com",
          "MEDIUM": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_medium.adwc.oraclecloud.com"
        },
        "high": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_high.adwc.oraclecloud.com",
        "low": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_low.adwc.oraclecloud.com",
        "medium": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_medium.adwc.oraclecloud.com"
      },
      "cpu-core-count": 1,
      "data-storage-size-in-tbs": 1,
      "db-name": "adwcli01",
      "db-version": "18.4.0.0",
      "defined-tags": {},
      "display-name": "adwcli01",
      "freeform-tags": {},
      "id": "ocid1.autonomousdwdatabase.oc1.iad.abuwcljtemt6oxmbkpgzyqstizl6oihunejtdmm7sjm2voay5x7g55nl2vrq",
      "license-model": "LICENSE_INCLUDED",
      "lifecycle-details": null,
      "lifecycle-state": "AVAILABLE",
      "service-console-url": "https://adb.us-ashburn-1.oraclecloud.com/console/index.html?tenant_name=OCID1.TENANCY.OC1..AAAAAAAA3MB7WRCY2LS3U3JSY2SOQ5CK3LC3Q4MCZITPDAYMBUAZC5TKGUCA&database_name=ADWCLI01&service_type=ADW",
      "time-created": "2019-01-16T07:27:08.872000+00:00"
    }
  ]
}

画面上でも確認できるようになりました。

f:id:k_kane:20190116165005p:plain
スケール前

ADW をスケールアップする

次に作った ADW をスケールアップしてみたいと思います。再び、以下のコマンドで一発です。

$ oci db autonomous-data-warehouse update

オプションは以下のとおりです。
【必須のオプション】

  • autonomous-data-warehouse-id : 先程作った Autonomous Data Warehouse の OCID を指定します (list コマンドで確認できます)
  • cpu-core-count : CPU 数、最小 1 OCPU(1物理コア)

実際やってみると以下のような感じです。

[opc@kokane-ol7-01 .oci]$ oci db autonomous-data-warehouse update --autonomous-data-warehouse-id "ocid1.autonomousdwdatabase.oc1.iad.abuwcljtemt6oxmbkpgzyqstizl
6oihunejtdmm7sjm2voay5x7g55nl2vrq" --cpu-core-count 2
{
  "data": {
    "compartment-id": "ocid1.compartment.oc1..aaaaaaaacdxn6dygelp7ckmxkjkp5ofpjirlay5jbtaizds3hwevcikbl3ua",
    "connection-strings": {
      "all-connection-strings": {
        "HIGH": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_high.adwc.oraclecloud.com",
        "LOW": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_low.adwc.oraclecloud.com",
        "MEDIUM": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_medium.adwc.oraclecloud.com"
      },
      "high": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_high.adwc.oraclecloud.com",
      "low": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_low.adwc.oraclecloud.com",
      "medium": "adb.us-ashburn-1.oraclecloud.com:1522/p36dah33ehxmnrf_adwcli01_medium.adwc.oraclecloud.com"
    },
    "cpu-core-count": 1,
    "data-storage-size-in-tbs": 1,
    "db-name": "adwcli01",
    "db-version": "18.4.0.0",
    "defined-tags": {},
    "display-name": "adwcli01",
    "freeform-tags": {},
    "id": "ocid1.autonomousdwdatabase.oc1.iad.abuwcljtemt6oxmbkpgzyqstizl6oihunejtdmm7sjm2voay5x7g55nl2vrq",
    "license-model": "LICENSE_INCLUDED",
    "lifecycle-details": null,
    "lifecycle-state": "SCALE_IN_PROGRESS",
    "service-console-url": "https://adb.us-ashburn-1.oraclecloud.com/console/index.html?tenant_name=OCID1.TENANCY.OC1..AAAAAAAA3MB7WRCY2LS3U3JSY2SOQ5CK3LC3Q4MCZITPDAYMBUAZC5TKGUCA&database_name=ADWCLI01&service_type=ADW",
    "time-created": "2019-01-16T07:27:08.872000+00:00"
  },
  "etag": "243aef71"
}

おおよそ1、2分でスケールアップされます。同じ構文 (オプション違い)でストレージのスケールアップも可能です。 (OCI CLI は比較的、足りないオプションがあると適切に返してくれるので、簡単です(ただ、事前にドキュメント確認したほうがベターですが、、、))

画面上でもスケールアップが確認できました。

f:id:k_kane:20190116165010p:plain
スケール後

まとめ

OCI CLI はコマンドもわかりやすいのでラクだなーというのと、 ADW はあんまり設定する項目がないので、ラクだなーと思いました。同じ方法で Autonomous Transaction Processing (Exadata (OLTP 用)が1時間単位で使える(雑な説明))も利用可能で、autonomous-data-warehouse が autonomous-database に変わります。OCI CLI のリファレンスは以下です。
Oracle Cloud Infrastructure CLI Command Reference — OCI CLI Command Reference 2.4.41 documentation

DWH みたいな用途ですと、バッチの前だけスケールして、その後落としたい、みたいな要件があるかと思うので、そんなときには CLI でジョブの頭に実装しておければ、なるべく安く使えるのかなと思いました。また、英語の blog 記事ですが、スケジューリング含めたサンプルスクリプトもあります。
Automatic (Scheduled) Scaling for ADW and ATP – Oracle Cloud Blog

カスタマーサクセス

カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則

カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則

 

冬休みに読んだ本。 本書の内容は、サブスクリプションビジネスを進めていく上では、必要な考え方かなと思いました。ある程度インストールベースができたら、新規の営業よりもカスタマーサクセスのほうが重要視されるという考え方が打ち出されており、顧客側がいつでも止められるサブスクリプションにおいては確かにそのとおりかなと思いました。カスタマーサクセスを重視する上でじゃあ実際にどうすべきなの?という点も書かれています。

従来から、ロイヤルカスタマーを確保することの重要性はあったと思うのですが、契約や取引が容易になった昨今、すぐ使える・すぐ止められるので、本当に顧客のロイヤリティをつないでおくのは大変だと思われます。

製品のクオリティやその後のアフターサービスなど製品を提供する側に撮っては大変ではあると思うのですが、製造業者にとってはサブスクリプション型で直接契約のチャンスも広がっていると思われます。一方で、製品を仕入れてきめ細やかな要望に答えることで価値を出していた、代理店・販売店は、どこで価値を見出すのか難しい時代になってきているなと思います。

いずれにしても作る側に回らないとしんどいかなという印象を受けました。