１．はじめに
こんにちは、NRIの大塚です。今回からCURRENT DATA領域になります（連載1回目）
　Oracle Container Engine for Kubernetesに取り組んでいきたいと思います。

 

CURRENT DATA、つまり直近5年程度のサイズのデータです。従来型の基幹系システムで行われているデータ処理のモダナイズが今後の価値であり、今回の連載でフォーカスする対象です。
ホストコンピュータからOpen化された基幹系システムのインフラはいままで大きな進化を遂げてきました。
なかでも仮想化はエンジニアひとりあたりの管理台数を増やす技術として爆発的に普及しました。
その流れの最先端がコンテナであり、コンテナの集中管理を担うKubernetesであると考えています。

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

 

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

本稿をお読みになられているOracleデータベース管理者である皆さまの中には、Oracle Programmerライセンスを用いたPro*COBOLによるOracle Databaseへの接続を行うバッチ処理稼働環境も担当されている方もいらっしゃるのではないかと思います。このようにコンテナ化の範囲は広がってきましたが、データベースのコンテナ化は難しいと一般に良く言われています（この件に関しては、他文献に論をお譲りします）。
そこで注目される最先端のデータベースの自動運用の解はOracle Autonomous Databaseです。
Oracle CloudにおいてはOracle Container Engine for KubernetesとOracle Autonomous Databaseを組み合わせることが出来、生産性を極限まで高めることができるのです。

 

今回から数回に渡り、本連載ではOracle Container Engine for Kubernetesに取り組んでいきたいと思います。
ですが、いきなり実装から入るのではなく、Oracle Blockchain Platform Cloud Serviceの時と同様にIaaS＋PaaSによるシステムデザインからご紹介したいと思います。そして次回から数回に分けて、そのシステムデザインを実装していきたいと思います。

 

１．システムデザイン

　従来のシステムがオンプレミスと呼ばれ、クラウド時代という名詞の違和感が無くなった今、オンプレミスで稼動中のエンタープライズシステムの要件がスポイルされたかのような錯覚がありますが、それは違います。むしろ、よりシビアに環境を選ぶ方向に進んでいると思っています。
　　高い可用性と、パフォーマンスが求められるエンタープライズ領域の中心はクラウド時代においてもOracle Databaseであり、Engineered Systemsです。Oracle Cloudはそれに最適化されたクラウドというだけでなく、高いアジリティ、拡張性、セキュリティそして、デザインした通りの実装を実現できる機能性を兼ね備えています。これらの点に関して、デザインの説明や実装を通じてお伝えしていきたいと考えています。
　　今回はOracle Container Engine for Kubernetesを中心に配置し、下図のようにデザインしました。
　　この内容であれば、Oracleデータベース管理者である皆さま各自がご所属の企業から、同様の検証を検討していただけるのではないかと思っております。しかも、良好な検証結果を得られたあとは、商用システムとしての基礎となれるようなグランドデザインにしたいと考え、作成いたしました。

 

２．詳細説明

　それでは図中①～⑧のそれぞれに関して説明をしていきたいと思います。

① VCN-PROXY
VCNはVirtual Cloud Network（仮想クラウド・ネットワーク）の略です。
つまり、Oracleデータセンタ―内で設定したプライベートネットワークを指します。VCNへはファイヤ・ウォール ルールを適用することが出来ます。また、各種ゲートウェイ・サービスに接続することが出来ます（図中ではインターネット・ゲートウェイが登場していることが確認できると思います）
この作業用の経路構築はMICRO DATA（Blockchain）の章で作成したものを再利用したいと思います。
構築に関する詳細はMICRO DATA（Blockchain）の章をご参照ください。
VCN-PROXYは特定企業からの通信のみ許可し、また、他のVCNへのアクセスへの基点に位置付けました。他のVCNは、VCN-PROXY経由のみの経路だけが作業用の通信として許可されます。
そのような役割を持つネットワーク区画をプロキシエリアと呼ぶことがありますので、「VCN-PROXY」と名付けました。
※VCNに関するマニュアル：
https://docs.oracle.com/cd/E97706_01/Content/Network/Concepts/overview.htm

 

② インターネット・ゲートウェイおよびセキュリティ・リスト
インターネット・ゲートウェイは、VCNに追加するとインターネットに直接接続できる仮想ルーターです。
Oracleデータベース管理者である皆さま各自がご所属の企業からインターネット経由で検証作業用の通信を接続するデザインとしました。検証のために専用線や、Internet VPN環境を構築するのは大変だと考え、このようにしています。そのかわりに、しっかりとファイヤ・ウォール ルールを設定し、接続元の制限を実装します。
それを実現するのがセキュリティ・リストです。セキュリティ・リストは仮想ファイヤ・ウォールを提供します。
おそらく皆さま各自がご所属の企業は、インターネットに直接通信する際には社内プロキシサーバ経由であることが想定されます。その社内プロキシサーバが外部に公開するIPアドレスが送信元であること。かつ、通信プロトコルがSSH(鍵ファイルを用いる)であることを条件としたファイヤ・ウォール ルールを設定することでセキュリティと、
俊敏な検証環境の立ち上げを両立したデザインとしたいと思います。
こちらもMICRO DATA（Blockchain）の章で作成したものを再利用したいと思います。
構築に関する詳細はMICRO DATA（Blockchain）の章をご参照ください。

※インターネット・ゲートウェイに関するマニュアル：
https://docs.oracle.com/cd/E97706_01/Content/Network/Tasks/managingIGs.htm

 

③ K8sコントロールサーバ
Oracle Container Engine for Kubernetes(OKE)へ命令を送信するサーバをMICRO DATA（Blockchain）の章で作成したCOMPARTMENT BlockchainのVCN-PROXY内に作成します。
OKEのマスターへの命令送信は管理用CLI（kubectlと言います）を用いて行います。
OCIへの命令送信はOracle Cloud Infrastructure コマンドラインインターフェース（CLI）を用いて行います。OCI CLIはOKEのIaaS部分の操作（例えばワーカー・ノードのスケーリングやOKEへの接続情報の取得）に使用します。Oracle Container Engine for Kubernetes用のkubectlは以下のようなソフトウェアスタックです。

 

このサーバは今回の章において重要な役割を担います。
ここで一般的なKubernetesのアーキテクチャと、今回の実装をマッピングしてみたいと思います。
一般的なKubernetesのアーキテクチャの要素としては「管理サーバ」、「マスター」、「ワーカー・ノード」の3つがあり、 今回のシステム構成図とのマッピングは下図のようになります（処理の流れと合わせて全体を俯瞰します）。

 

※コンピュート・サービスに関するマニュアル：
https://docs.oracle.com/cd/E97706_01/Content/Compute/Concepts/computeoverview.htm

※Oracle Cloud Infrastructure コマンド・ライン・インタフェース (CLI)に関するマニュアル：
https://docs.oracle.com/cd/E97706_01/Content/API/Concepts/cliconcepts.htm

※kubectlを使用したクラスタへのアクセス：
https://docs.oracle.com/cd/E97706_01/Content/ContEng/Tasks/contengaccessingclusterkubectl.htm?Highlight=kubectl

 

④ PaaS　～Oracle Container Engine for Kubernetes～
CURRENT DATAデータ領域のメインテーマです。
直近5年程度のサイズのデータ処理を担う従来型の基幹系システムは、生産性の向上が最重要課題です。
宣言的な設定による自律的な稼働を実現できるKubernetesは、課題解決の重要な役割を担います。
2017年9月の「Cloud Native Computing Foundation」への最上位プラチナメンバーとして加盟を経てGAされたOracle Container Engine for Kubernetesはエンタープライズ利用として最適です。
Oracle Cloudは機能面だけでなく、コストの面でも強みがあります。
Oracle Container Engine for Kubernetesはマスターとワーカー・ノードの大きく２つにまとめられますが、マスターに関してはコストがかからないのです。
Oracleデータベース管理者の皆さまにおかれましてはデータの価値を高めるひとつの潮流と捉えて、 ぜひ体験して頂きたいと思っています。

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

 

⑤ VCN-OKE
構成図において、VCN-OKEを囲むCOMPARTMENT OKEの存在にお気づきの方も多いと思います。
コンパートメントは、クラウド・リソースを整理して、隔離するための概念（機能）です。
他テナントからアクセスされることなく、また、同一テナント内においては、ユーザ毎の統制を行うことができます。
いままでお話ししてきたクラウド・リソースは、必ずどこかのコンパートメントに所属することになります。
コンパートメント化する単位はプロジェクト単位であったり、リソース種別単位であったり、組織単位であったりと 様々なユースケースが考えられます。今回はOracle Container Engine for Kubernetesのワーカー・ノード環境を収容するコンパートメントを実装します。それが「COMPARTMENT OKE」です。

次に「VCN-OKE」です。
これはOracle Container Engine for Kubernetesのワーカー・ノード環境を実装する仮想クラウド・ネットワークです。
Ashburnリージョンは Oracle Cloudの特徴である３つの可用性ドメインで構成されています。
今回は３つのデータセンタを最大限に活かす設計としてみたいと思います。
このVCN-OKEには３つの可用性ドメインに分散したワーカー・ノードと、２つの可用性ドメインに分散したロード・バランサを収容したいと思います。

2019年10月にOracle Container Engine for Kubernetesはリージョナル・サブネットに対応しました。
リージョナル・サブネットに対応したことにより複数の可用性ドメインをまたいだサブネット、ロード・バランサの構成が可能となっています。

構成図に記載されている可用性ドメイン（Availability Domain１，２，３）は、いわゆる近距離間で
建設されたデータセンタそのもの。と、ご理解頂いて差し支えないかと思います。可用性ドメインに関する紹介のURLを掲載しておきますので、そちらの図をご参照頂くと非常に分かりやすいかと思います。
Oracle Cloudが、いかにミッションクリティカルを考え抜いて作りこまれているか、とても良く伝わってきます。

※コンパートメントに関するマニュアル：
https://docs.oracle.com/cd/E97706_01/Content/Identity/Tasks/managingcompartments.htm

 

⑥ ロード・バランサ
ワーカー・ノードへの処理を分散するロード・バランサです。

Oracle Cloudのロード・バランシング・サービスは、VCN内にパブリックまたはプライベートのロード・バランサという2つの種類があり、用途の応じて使い分けを行います。
パブリック・ロード・バランサは、インターネットからアクセスできるパブリックIPアドレスを持つことができます。
一方のプライベート・ロード・バランサは、VCN内でIPアドレスを持つことになります。
双方共にトランスポート・レイヤー4およびレイヤー7 (TCPおよびHTTP)トラフィックのロード・バランシングを行うことができます。

アプリケーションはインターネット経由での接続ですのでパブリック・ロード・バランサを選択します。
パブリック・ロード・バランサは2つの可用性ドメインに冗長化することができますので、冗長性を確保したいと思います。
それぞれの可用性ドメインに1つずつ、パブリック・ロード・バランサを収容するためのサブネットを作成します。

※ロード・バランサに関するマニュアル：
https://docs.oracle.com/cd/E97706_01/Content/Balance/Concepts/balanceoverview.htm

 

⑦ ワーカー・ノード
Oracle Container Engine for Kubernetesのワーカー・ノードは3つの可用性ドメインに分散配置し
最大可用性を実装したいと思います。
各コンピュート・インスタンスは、サブネット内に存在することになりますので
構成図のように、各可用性ドメイン内にワーカー・ノード収容用のサブネットを、それぞれ作成したいと思います。

補足となりますが、先ほど「各コンピュート・インスタンスは、サブネット内に存在する」という表現をしました。
ですが正確には、各インスタンスは実際には「仮想ネットワーク・インタフェース・カード(VNIC)」にアタッチされています。「仮想ネットワーク・インタフェース・カード(VNIC)」はサブネットに存在し、そのインスタンスのネットワーク接続を可能にします。ということです。補足させて頂きます。

※サブネットに関するマニュアル：
https://docs.oracle.com/cd/E97706_01/Content/Network/Tasks/managingVCNs.htm

 

今回は以上となります。次回から実装に関してお話ししていきたいと思います。

---

Keys to the Oracle Cloud indexページ▶▶