第１３回：【CURRENT DATA編】CURRENT DATA編のまとめ

Oracleアカウント

Keys to the Oracle Cloud
第１３回：【CURRENT DATA編】
CURRENT DATA編のまとめ

大塚紳一郎, 2020年4月

著者紹介

大塚　紳一郎（おおつかしんいちろう）

2003年、株式会社野村総合研究所に新卒で入社。ミッションクリティカルシステムにおけるOracle Databaseの構築、運用、コンサルティングに関して15年以上の経験を持つ。毎年サンフランシスコで開催される世界最大のテクノロジーイベント「Oracle OpenWorld」を含む各種イベントでの講演多数。Autonomous DatabaseがGAされた年にOracle ACE Associateになれたことに運命を感じており、Oracleデータベース管理者の今後のロールモデルの構築に携わりたいと考え日々活動中。最新の登壇タイトルは「Boosting your career through Oracle Cloud Infrastructure 2018 Certified Architect Associate.」

NRI認定ITアーキテクト
Oracle ACE Associate
Oracle MASTER Platinum10g,11g,12c(Platinum of the year 2016 in Japan)
Oracle MASTER Cloud Oracle Database Cloud Service
Oracle MASTER Cloud Oracle Java Cloud Service
Oracle Cloud Infrastructure 2018 Certified Architect Associate
Oracle Database Cloud Service 2019 Operations Certified Associate
Oracle Autonomous Database Cloud 2019 Certified Specialist

これからの内容はOracle Cloud Infrastructure (以下OCI)のサービスを前提としたものです。
検証時点(2019年3月末)のOCIのサービス内容に基づいて記載しているため、内容が一部異なる場合があります。
最新の情報については公式Webサイト（https://www.oracle.com/jp/cloud/）をご確認頂きたく思います。
本連載は私個人の理解に基づいており、事実と異なる可能性があることをご了承いただきたく思います。

こんにちは、NRIの大塚です。今回はCURRENT DATA領域の連載6回目です。

テーマとするPaaSはOracle Container Engine for Kubernetes（OKE）です。
CURRENT DATA領域の連載も６回目になりました。6回目ですので、まとめのお話しをしたいと思います。

CURRENT DATA、それは直近5年程度のサイズのデータを指しています。CURRENT DATA領域のデータは従来型の基幹系システムにおいて処理されています。このような従来型の基幹系システムのモダナイズは今後の価値であり、今回の連載でフォーカスしました。

従来型の基幹系システムで行われているデータ処理のモダナイズにおいて最も重要なキーワードは「生産性」だと考えます。
ホストコンピュータからOpen化された基幹系システムのインフラはいままで大きな進化を遂げてきました。
なかでも仮想化はエンジニアひとりあたりの管理台数を増やす技術として爆発的に普及しました。
その流れの最先端がコンテナであり、コンテナの集中管理を担うKubernetesであると考えています。

私がKubernetesで最も良いと思っている点は宣言的な管理による運用が行えることです。

宣言的な管理は私達の生産性に大きく寄与する機能だと思っています。従来型の基幹系システムで行われているデータ処理のモダナイズにおいて最も重要なキーワードは「生産性」だと考えます。コンテナは今、基幹系システムにおいて重要なCOBOLによるバッチ処理も稼働するようになりました。マイクロフォーカス様の最新版Visual COBOL 4.0ではDockerとKubernetesがサポートされているのです。Kubernetesは多くの環境でサポートされています。ですが、

・Cloud Native Computing Foundationにプラチナメンバーとして加盟し、サービス化されたOracle Container Engine for Kubernetes ・そしてコンテナ化が難しいとされるデータベースに対して、Oracle Autonomous Databaseという自動運用の解を持つOracle Cloudは基幹系システムのモダナイズを考える上で、最適な環境であると考え、Oracleデータベース管理者である皆さまへOracle Container Engine for Kubernetesをテーマに、連載を進めてきました。

まとめの回である今回は、障害試験を通じた「宣言的」と言われる挙動の確認の続きと、コンテナ活用に取り組む上での「Why Oracle Cloud？」をもう少し掘り下げてみたいと思います。以下の3つの観点でまとめていきます。
・その1：エンタープライズグレードの可用性とパフォーマンス
・その２：ユーザフレンドリーなサービス価格モデル
・その３：充実した周辺サービス

それではOracle Container Engine for Kubernetes環境下に検証用のアプリケーションを稼働させ、障害試験を通じて「宣言的」と言われる挙動の確認からはじめていきたいと思います。前回は以下を実現するManifestを作成し、kubectl applyを行うことでservice化しました。
・サンプルアプリのコンテナを内包するPodを3つデプロイ(replicas: 3) ・クラスタがホストされているクラウドサービスのロードバランサを自動プロビジョニングし、そのロードバランサに来たトラフィックをコンテナに届ける～今回用いるManifest(My1stApp.yaml)～

Copy



apiVersion: apps/v1
kind: Deployment
metadata:
  name: <サンプルアプリ名>-deployment
spec:
  selector:
    matchLabels:
      app: <サンプルアプリ名>
  replicas: 3
  template:
    metadata:
      labels:
        app: <サンプルアプリ名>
    spec:
      containers:
      - name: <サンプルアプリ名>
        image: <リージョンコード>.ocir.io/<テナント名>/<リポジトリ名>/<サンプルアプリ名>:version1.0
        ports:
        - containerPort: 80
      imagePullSecrets: 
      - name: my1stsecret
---
apiVersion: v1
kind: Service
metadata:
  name: <サンプルアプリ名>-service
spec:
  type: LoadBalancer
  ports: 
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: <サンプルアプリ名>

Oracle Container Engine for Kubernetes環境下に展開された構成は以下のようになりました。

前回はPodを１つ強制的に停止させる障害試験を行い、Oracle Container Engine for Kubernetes環境下の挙動を確認しました。

現在は以下のような関係となっています。

可用性ドメイン	ワーカー・ノード	Pod
ASHBURNのAD-1	KKK.JJJ.21.2	<サンプルアプリ名>-deployment-68c45f7486-nzcld
ASHBURNのAD-2	KKK.JJJ.22.3	<サンプルアプリ名>-deployment-68c45f7486-z8xpj
ASHBURNのAD-3	KKK.JJJ.23.2	<サンプルアプリ名>-deployment-68c45f7486-59b88

今回はワーカー・ノードを2台停止させ障害試験を行い、Oracle Container Engine for Kubernetes環境下の挙動を確認したいと思います。停止させるワーカー・ノードはAD-1(KKK.JJJ.21.2)と、AD-2(KKK.JJJ.22.3)です。構成図としては以下となります。

それではワーカー・ノードの停止を行います。停止のさせ方はOracle Cloudの管理コンソールを用いて行います。

テナント管理者ユーザーとしてログインしてください（OKE-adminではありません。注意してください）さっそくOracle Cloud管理コンソールへログインしてみましょう。URLは以下です。
https://www.oracle.com/jp/cloud/sign-in.html

（注）２ステップ検証は以下の記事で実装しました。
「Keys to the Oracle Cloud第７回：【Tea break】 Oracle CloudにおけるMulti-Factor Authentication(多要素認証)の実装」
標準のログインシーケンスでは、２ステップ検証の画面には遷移しませんのでご注意ください。
上記の記事を参考に各自実装をお願いします。

Oracle Cloudの管理コンソールにログインしたら、「ハンバーガーボタン」→「コンピュート」→「インスタンス」を押下します。

コンパートメントが「OKE」であることを確認してください。
障害試験で停止させるインスタンスはASUBURN-AD-1と、ASUBURN-AD-2のインスタンスです。
まずASUBURN-AD-1から停止していきます。

インスタンの詳細が表示されますので、「停止」を押下してください。

確認ダイアログが表示されますので「OK」を押下してください。

表示が「停止中…」に遷移します。

ASUBURN-AD-1のインスタンスの停止が完了しました。続いてASUBURN-AD-2のインスタンスの停止です。

インスタンの詳細が表示されますので、「停止」を押下してください。

確認ダイアログが表示されますので「OK」を押下してください。

表示が「停止中…」に遷移します。

ASUBURN-AD-1のインスタンスおよびASUBURN-AD-2のインスタンスの停止が完了しました。

Oracle Container Engine for Kubernetes環境下の挙動をログで確認したいと思います。

まずK8sコントロールサーバにログインします。

Copy



[opc@プロキシサーバのhostname 鍵ファイル置き場]$ ssh -i myrsa opc@ K8sコントロールサーバのPrivateIPアドレス
[opc@K8sコントロールサーバのhostname ~]$

その後の確認手順は以下です。

●ワーカー・ノードの状態遷移を確認
　　　　kubectl get nodes
　　　　を、複数回実行

●Podの状態遷移を確認
　　　　kubectl get pods
　　　　を、複数回実行

●生き残ったASHABURNのAD-3で稼働しているワーカー・ノードの詳細状況を確認
　　　　kubectl describe node <ASHABURNのAD-3で稼働しているワーカー・ノードのIPアドレス>
　　　　を実行

以下に実行ログを記載いたします。

Copy



[opc@K8sコントロールサーバのhostname ~]$ kubectl get pods
NAME                                     　　    READY   STATUS   RESTARTS     AGE
<サンプルアプリ名>-deployment-68c45f7486-59b88     1/1     Running    0          12m
<サンプルアプリ名>-deployment-68c45f7486-nzcld     1/1     Running    0          72m
<サンプルアプリ名>-deployment-68c45f7486-z8xpj     1/1     Running    0          72m

[opc@K8sコントロールサーバのhostname ~]$ kubectl get nodes
NAME        　 STATUS       ROLES   AGE   VERSION
KKK.JJJ.21.2   Ready      　node    72d   v1.13.5
KKK.JJJ.22.3   Ready      　node    72d   v1.13.5
KKK.JJJ.23.2   Ready      　node    72d   v1.13.5

[opc@K8sコントロールサーバのhostname ~]$ kubectl get nodes
NAME        　 STATUS       ROLES   AGE   VERSION
KKK.JJJ.21.2   NotReady   　node    72d   v1.13.5
KKK.JJJ.22.3   Ready      　node    72d   v1.13.5
KKK.JJJ.23.2   Ready      　node    72d   v1.13.5

[opc@K8sコントロールサーバのhostname ~]$ kubectl get nodes
NAME        　 STATUS       ROLES   AGE   VERSION
KKK.JJJ.21.2   NotReady   　node    72d   v1.13.5
KKK.JJJ.22.3   NotReady   　node    72d   v1.13.5
KKK.JJJ.23.2   Ready      　node    72d   v1.13.5

[opc@K8sコントロールサーバのhostname ~]$ kubectl get pods
NAME                                     　  　　READY     STATUS       RESTARTS        AGE
<サンプルアプリ名>-deployment-68c45f7486-59b88     1/1     　Running       　0          　18m
<サンプルアプリ名>-deployment-68c45f7486-lkp8c     1/1     　Running       　0          　56s
<サンプルアプリ名>-deployment-68c45f7486-nzcld     1/1     　Terminating   　0          　78m
<サンプルアプリ名>-deployment-68c45f7486-z8xpj     1/1     　Running       　0          　78m

[opc@K8sコントロールサーバのhostname ~]$ kubectl get pods
NAME                                     　  　　READY     STATUS       RESTARTS        AGE
<サンプルアプリ名>-deployment-68c45f7486-59b88   　1/1     　Running       　0          　25m
<サンプルアプリ名>-deployment-68c45f7486-888c4   　1/1     　Running       　0          　108s
<サンプルアプリ名>-deployment-68c45f7486-lkp8c   　1/1     　Running       　0          　7m44s
<サンプルアプリ名>-deployment-68c45f7486-nzcld   　1/1     　Terminating   　0          　85m
<サンプルアプリ名>-deployment-68c45f7486-z8xpj   　1/1     　Terminating   　0          　85m

[opc@K8sコントロールサーバのhostname ~]$ kubectl describe node KKK.JJJ.33.32
Name:               KKK.JJJ.23.2
Roles:           　   node
～中略～
Namespace                  Name                              CPU Requests     CPU Limits     Memory Requests      Memory Limits     AGE
---------                  ----   　　　　　　　               ------------  　　----------  　　---------------  　　-------------  　　---
default     <サンプルアプリ名>-deployment-68c45f7486-59b88        0 (0%)          0 (0%)             0 (0%)             0 (0%)         25m
default     <サンプルアプリ名>-deployment-68c45f7486-888c4        0 (0%)          0 (0%)             0 (0%)             0 (0%)         2m6s
default     <サンプルアプリ名>-deployment-68c45f7486-lkp8c        0 (0%)          0 (0%)             0 (0%)             0 (0%)         8m2s
～以下略～

ワーカー・ノードの状態遷移をまとめます。

可用性ドメイン	ワーカー・ノード	STATUS	STATUS	STATUS
ASHBURNのAD-1	KKK.JJJ.21.2	Ready	→NotReady	→NotReady
ASHBURNのAD-2	KKK.JJJ.22.3	Ready	→Ready	→NotReady
ASHBURNのAD-3	KKK.JJJ.23.2	Ready	→Ready	→Ready

Podの状態遷移をまとめます。

ワーカー・ノード	PodのSTATUS	PodのSTATUS	PodのSTATUS
KKK.JJJ.21.2	<サンプルアプリ名>-deployment-68c45f7486-nzcld	→Terminating	→Terminating
KKK.JJJ.22.3	<サンプルアプリ名>-deployment-68c45f7486-z8xpj	→Running	→Terminating
KKK.JJJ.23.2	<サンプルアプリ名>-deployment-68c45f7486-59b88	→Running	→Running
	-	<サンプルアプリ名>-deployment-68c45f7486-lkp8c	→Running
	-	-	<サンプルアプリ名>-deployment-68c45f7486-888c4

今回用いたManifest（/home/opc/My1stApp.yaml）
において「replicas: 3」と、宣言しているので、kubectl delete podでPodを１つ停止させても、すぐに全Podの数が３になるようにOKEが調整します(ログから、別名のPodで起動していることが分かります)。実際の動きは以下のようになります。

障害試験を通じて「宣言的」と言われる挙動の確認が出来たので、serviceを停止したいと思います。
確認手順は以下です。

●service停止
kubectl delete -f /home/opc/My1stApp.yaml
を実行

以下に実行ログを記載いたします。

Copy



[opc@K8sコントロールサーバのhostname ~]$ kubectl delete -f /home/opc/My1stApp.yaml

deployment.apps "<サンプルアプリ名>-deployment" deleted
service "<サンプルアプリ名>-service" deleted

[opc@K8sコントロールサーバのhostname ~]$

Oracle Cloudの管理コンソールでservice停止時の動きを見てみたいと思います。

kubectl delete -f /home/opc/My1stApp.yaml
を実行した直後のOKEコンパートメント内のロードバランサの状況です。
状態が「削除中」に遷移します。

しばらくすると、削除が完了し、アイテムがなくなったことが分かります。

それではまとめとしてコンテナ活用に取り組む上での「Why Oracle Cloud？」をもう少し掘り下げてみたいと思います。以下の3つの観点でまとめていきます。

・その1：エンタープライズグレードの可用性とパフォーマンス
・その２：ユーザフレンドリーなサービス価格モデル
・その３：充実した周辺サービス

Why Oracle Cloud? その1：エンタープライズグレードの可用性とパフォーマンス

Oracle Cloudは高速SSDを搭載したベアメタルサーバ(仮想化されていないサーバ)による高いパフォーマンスで有名ですが、私がさらに着目しているのではマルチ可用性ドメイン(AD)による高い可用性と、それを支える低レイテンシー、広帯域のネットワークです。

今回のシステムにおいてDockerイメージのPullやPodsの展開など、様々な作業をOracleデータベース管理者である皆さまに体験頂きました。ネットワークのパフォーマンス関して不足を感じることは無かったと思います。
Oracle Cloudのネットワークは以下のようなパフォーマンスを保有しています。このレベルは特筆すべきであると考えます。

・可用性ドメイン間：バンド幅1Tb/s, レイテンシーは500マイクロ秒
・可用性ドメイン内：バンド幅25Gb/s, レイテンシーは100マイクロ秒

ワーカー・ノードの障害試験を通じた可用性の高さの体験に加えてOracle Container Engine for Kubernetesのマスターもデフォルトで冗長化されており、かつ、内包しているetcdも自動で定期バックアップされます。

３つの可用性ドメイン(AD)で冗長化されたエンタープライズグレードの可用性とパフォーマンスは「Why Oracle Cloud？」のアンサーの1つであると考えます。

Why Oracle Cloud? その2：ユーザフレンドリーなサービス価格モデル

今回の連載では、Oracle Container Engine for Kubernetesに加えて、OCI Registryを稼働させています。
加えて３つの可用性ドメイン(AD)で冗長化したワーカー・ノード環境の実装も行いました。
そして障害試験まで体験頂いたのが今回のCURRENT DATA編の連載内容です。

Oracle Cloudのマネージド環境は如何でしたでしょうか？すべてが合理的に設計されていて、とても美しいと思います。ロードバランサの制御まで含めたserviceの立ち上げ、障害時の動作、そしてservice停止時の動き。
どれを取ってもOracleデータベース管理者の皆さまに響く、Oracleデータベースに感じる、あの感覚があると思います。
障害試験中に、皆さまにおいてはOracleデータベースへ、もし接続があったらどうなるか？まで、思いを馳せながら検証された方もいらっしゃると思います。クラウド時代におけるシステム構成のひとつのパターンとして皆さまのご記憶に残ることができたら、これにまさる喜びはありません。

運用においても、Oracle Container Engine for Kubernetes、そしてOCI Registryにおけるパッチ管理(適用)、可用性は皆さまのシステムインフラの維持管理コスト削減に貢献します。この重要な2つのサービスに対するOracle Cloudの価格モデルを下表にまとめます。すばらしいオファー価格だと考えます。
・Oracle Container Engine for Kubernetes、そしてOCI Registryは無料。IaaSだけが課金対象
　- Oracle Container Engine for Kubernetes：Compute、Block Storage、ロードバランサ、ネットワーク
　- OCI Registry：Object Storage、ネットワーク
・ネットワークはリージョン内転送無料、月10TBまでのデータ持ち出し無料
・100GBのIOPS(6000IOPS)のストレージが月306円（※価格は今後変動の可能性があります）
検証中のコストを見てみてください。驚くと思います。このユーザフレンドリーなサービス価格モデルは「Why Oracle Cloud？」のアンサーの1つであると考えます。

Why Oracle Cloud? その3：充実した周辺サービス

Oracle CloudにおけるOracle Container Engine for Kubernetesの周辺サービスを表にまとめます。
とても充実した周辺サービスであると考えております。

データマネジメント	Database, Exadata, Autonomous DataWarehouse Cloud, Autonomous Transaction Processing, Database Backup, Bigdata他
運用・管理	IT Analytics, Log Analytics, Orchestrations, Application Performance Monitoring, Infrastructure Monitoring他
セキュリティ	CASB, Configuration and Compliance, Security Monitoring and Analytics, Identity他
コンテンツ＆エクスペリエンス	Content and Experience他
ビジネスアナリティクス	Analytics Cloud, Data Visualization, Business Intelligence, Essbase他
インフラストラクチャ(IaaS)	Compute, Networking, Storage, Governance, Load Balancing, Ravello, Edge Services, Cloud at Customer他
インテグレーション	Oracle Integration Cloud, Data Integration, Internet of Things, Self-Service Integration, Process Automation, SOA他
アプリケーション開発	Java, Mobile and ChatBots, Messaging, AI Platform, Blockchain, Developer, Visual Builder他

※2019年9月時点のラインナップです

今回着目したいのはアプリケーション開発です。Oracle CloudはCloud Nativeアプリの開発者をEnd to Endで支えることに注力していて、さまざまなマネージドサービスの開発に取り組んでいます。そのアプローチは大きく３つ。

- Open：Oracleはコミュニティ主導の開発を尊重しています。オープンで可搬性のある開発環境を目指し、Cloud Native Computing Foundationに2017年からプラチナメンバーとして加盟。Cloud Nativeテクノロジーの進化の促進、安定・高機能なソフトウェアの普及に貢献しています。Java/MySQL/Linuxに関しては先駆者としての立場を継続しつつ、さらなる実績としてFn Project(Function as a Serviceフレームワーク)、railcar(コンテナ・ランタイムのRUST実装)、smith(rpmパッケージからマイクロコンテナを作成)をはじめとしてCloud Native領域で多数のオープンソースをリリースしています。

- Managed：エンタープライズグレードOracle Cloudを最大限に活かしたエンタープライズなマネージドサービスとして安定したCloud Nativeテクノロジーをユーザーに提供しています。考え抜かれた開発者エクスペリエンスを今回の連載で皆さまもご体験頂けたのではないかと考えています。

- Inclusive：コンテナ・レジストリ、CI/CDビルドパイプライン、Kubernetesプラットフォーム、運用監視・通知サービスといったコンテナベースのアプリケーション開発のためのEnd to Endなサービスを提供しています(詳細は下表をご参照ください)。コンテナとKubernetes の登場によりCI/CD、つまり継続的インテグレーション/継続的デリバリーは昨今とても注目されています。ソースコードの変更から本番環境へのリリースまでの流れを極力省力化し、人手を介さないテスト＆リリースにより、システムの品質と安全な高頻度リリースが実現できるようになりました。Oracle Cloudにおける実現方法は、日本オラクル様の以下の記事をご参照ください。
記事名：OKEとWerckerによるCI/CD

アプリケーション開発を加速させるサービス

Oracle Container Engine for Kubernetes	エンタープライズグレードのコンテナのプロビジョニングと管理
OCI Registry	エンタープライズグレードののコンテナレジストリ
Container Piplines(Wercher)	CI/CDパイプラインによるコードの構築とテスト
Resource Manager	TeraformをベースとしたIaCの機構
Functions	Fn Projectをベースとしたサーバーレスサービスコード開発

アプリケーション開発を支えるサービス

Monitoring	リソース、サービスのメトリクス利用状況のレポート
Notifications	ユーザーへの通知
Streaming	ストリーミング情報をスケーラブルに収集
Events	リソース等の変更に基づくイベント発行

現行システムで多く稼働しているJavaアプリケーションについてお話しをしたいと思います。OracleはJavaの先駆者としての立場から、Javaアプリケーションのモダンな開発を支援する最先端の取り組みを行っています。キーワードはProject HelidonとGraalVMです。Project HelidonはJavaのマイクロサービス・フレームワークであり、オラクルがホストするOSSプロジェクトです。マイクロサービスアプリケーションが必要とする機能(Webサーバ、コンフィギュレーション、セキュリティ)を提供するJavaライブラリの集合体です。そしてGraalVMとは、Oracleがホストするオープンソースです。アプリケーションとランタイムをセットにしたシングルバイナリを生成できます（GraalVM Native Imageと呼ばれます）。このGraalVM Native Imageを活用することによりHelidon SEアプリケーションを高速起動かつ、省メモリで稼働させることができます。新規に作成するアプリケーションはぜひOracle Cloudでクラウドネイティブ開発にチャレンジしてみてください。一方、既存のJavaアプリケーションのクラウドシフトも手厚くサポートされています。マーケットプレイスにはOracle Weblogic Serverがあり、迅速な環境構築が実現されています。このように新旧の環境を混在させ、段階的に新しいアプリケーションやサービスに機能を置き換えていく設計手法はStrangler Pattern（ストラングラー・パターン）と呼ばれています。Oracle Cloudは、このような包括的な考えのもと、我々ユーザーに新しい選択肢を与えてくれているのです。

「フィルタ」で検索条件を設定します。

以上がCURRENT DATAのお話となります。いかがでしたでしょうか？
Oracleデータベース管理者の皆さまに、データベースへのトランザクション発行元であるアプリケーションレイヤにおいて大きな変革が起こっていることをお伝えしたく、いろいろとお話しさせて頂きました。新しい時代のシステム構築も引き続き牽引していってください。

CURRENT DATA編はここまでといたします。読んで頂きありがとうございました。

謝辞
　Oracle Container Engine for Kubernetesの検証を支えてくださった日本オラクルの茂さん、早川さん、古手川さん、瀬尾さん、五嶋さん、金本さん、そして、私達Oracleデータベース管理者の憧れであるOracle Technology Networkへの執筆機会をくださった日本オラクルの豊竹さん、鈴木さんに、この場をお借りして深く感謝申し上げます。ありがとうございました。

※OKEとWerckerによるCI/CD
※Oracle CloudでDevOps!?Javaアプリケーションのモダン開発を支援するOracle Cloudサービスのご紹介
https://www.oracle.co.jp/campaign/moderncloudday/2019/pdfs/mcd19_e-1.pdf
日本オラクル株式会社茂こと

※Cloud Nativeアプリケーションに最適!Oracle Cloud Infrastructureの魅力!
https://www.slideshare.net/oracle4engineer/devsumi2019cloud-native-oracle-cloud-infrastructure
日本オラクル株式会社丸川祐考、茂こと

※Container Engine for Kubernetesの概要
https://docs.oracle.com/cd/E97706_01/Content/ContEng/Concepts/contengoverview.htm

※Oracle Cloud Infrastructureドキュメント～レジストリの概要～
https://docs.oracle.com/cd/E97706_01/Content/Registry/Concepts/registryoverview.htm

Keys to the Oracle Cloud indexページ▶▶

Keys to the Oracle Cloud 第１３回：【CURRENT DATA編】 CURRENT DATA編のまとめ

著者紹介

大塚 紳一郎（おおつか しんいちろう）

Why Oracle Cloud? その1：エンタープライズグレードの可用性とパフォーマンス

Why Oracle Cloud? その2：ユーザフレンドリーなサービス価格モデル

Why Oracle Cloud? その3：充実した周辺サービス

Keys to the Oracle Cloud
第１３回：【CURRENT DATA編】
CURRENT DATA編のまとめ

大塚　紳一郎（おおつかしんいちろう）