このページの本文へ

前へ 1 2 次へ

AWSから移籍しOCIを作った理由、日本リージョンへの期待、MS Azureとの連携まで、現状と方向性

オラクルのIaaS担当VPに聞く“第2世代クラウド”の狙いとこれから

2019年09月16日 10時00分更新

文● 大塚昭彦/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 日本オラクルが2019年8月に開催した「Modern Cloud Day Tokyo」では、オラクルが提供するIaaS「Oracle Cloud Infrastructure(OCI)」担当VPのヴィナイ・クマー氏が来日し、記者説明会を行った。Amazon Web Services(AWS)からオラクルに移籍し、OCI開発の草創期から携わってきたクマー氏は、OCI立ち上げにおけるコンセプトから、サービスラインアップやグローバルなリージョンの拡張、さらに「Microsoft Azure」とのサービス連携、今後の市場戦略までを幅広く説明した。

 同日、TECH.ASCII.jpでは単独インタビューも行うことができたので、「Oracle OpenWorld 2019(OOW 2019)」の開催直前に、あらためてOCIの現状と戦略、東京リージョン開設に対する顧客の反応、今後の方向性などについて、クマー氏の言葉を軸にまとめてみたい。

Oracle Cloud Infrastructure(OCI)で現在提供されているサービスラインアップ

Oracle Cloud Infrastructure プロダクト・マネジメント担当バイス・プレジデントのヴィナイ・クマー(Vinay Kumar)氏

OCIの目標は「エンタープライズのための、完全かつ妥協のないクラウド」

 クマー氏はオラクル入社以前、AWSでストレージサービスのプロダクト・マネジメントを統括する役職に就いていた。そこからオラクルへ移籍した理由のひとつは、新しいクラウドサービスをまったくゼロから設計して作ることができるチャンスだと考えたからだという。

 「それまでAWSでサービスを開発していたグループが(クマー氏を含めて)集団で移籍した。オラクルでまったく新しいクラウドを作ろうと、皆のモチベーションは高かった」

 オラクルに移籍したもうひとつの理由は、4、5年前当時のAWSにはまだ、エンタープライズ向けのサービスが十分に整っていなかったからだという。「エンタープライズ向けクラウドを作るならば、エンタープライズの世界で何十年もやってきたオラクルがいいはずだ。また、それがオラクル自身のビジネスにもつながるだろう、と考えた」。

AWSもOCIの開発本拠地はシアトル。「われわれがOCIに移ったあと、シアトルのMicrosoft AzureやGoogle Cloud、Dropboxなどからも人が集まった。小さな街だからね」

 10年ほど前に登場した“第1世代”のクラウドは革新的であり、開発者(Developer)やスタートアップ向けのサービスとしては良いものだったと、クマー氏は語る。

 「初めて第1世代のクラウドに触れたときには、自由度が非常に高く『これまで不可能だったことが可能になった』と感じた。Webサイトでクレジットカード情報を入力すれば、わずか数時間後にはWebアプリケーションが立ち上げられたからだ」

 ただし、エンタープライズワークロードを載せるITインフラとしては不十分な点が多かった。高強度なセキュリティや一貫したガバナンス、コスト管理、さらに安定したパフォーマンスといった部分で、基幹業務アプリケーションやそのデータベースなどのワークロード要件は満たせていなかった。

“第1世代”クラウドサービスには革新的なメリットもあったが、エンタープライズワークロードの要件は満たせていなかった

 そこで、柔軟さや俊敏さといった第1世代の良い点は引き継ぎつつ、「エンタープライズのための、完全かつ妥協のないクラウドをゼロから構築する」ことを目指し、OCIの開発に取り組むことにした。それこそが、昨年のOOWで同社 会長兼CTOのラリー・エリソン氏も紹介した“第2世代のクラウド(Gen2 Cloud)”のビジョンである。

 第2世代クラウドとしてOCIを開発するうえでは、サービス基盤をなすインフラレイヤーから抜本的に設計を見直すことで、特にセキュリティとパフォーマンスの領域でてこ入れを行ったという。具体的に何をしたのかを尋ねると、クマー氏は大きな特徴として2つを挙げた。

 1つめの特徴が「オフボックス仮想化(Off-Box Virtualization)」の実現だ。具体的には、オラクル側がサービス制御を行う「クラウドコントロールコンピュータ」を、顧客のワークロードが稼働するベアメタルマシンの外(=オフボックス)に隔離している。顧客環境とサービス制御環境を隔離したことで、各種サービス制御の処理が顧客ワークロードのパフォーマンス劣化を引き起こすことがなく、また万が一サービス制御用コードに脆弱性があったとしても、それを踏み台として顧客環境には侵入できない高度なセキュリティを担保している。

第1世代では顧客環境が稼働するマシン上でサービス制御用のコードも動いていた。OCIでは、より高度なセキュリティとパフォーマンス劣化防止を担保するために、これをオフボックス化した(OOW 2018発表スライドより)

 もう1つが、クラウドサービスに適した「ネットワークの設計」だ。第1世代クラウドでは、特にネットワークリソースについては「オーバーサブスクライブ」が前提となっていたため、たとえ仮想ネットワークとして分離されていたとしても、他のユーザーのトラフィックによるパフォーマンス影響を受けるケースが多かった。こうしたパフォーマンスの不安定さは、エンタープライズワークロードにとっては禁物だ。

 そこで第2世代のOCIでは、物理ネットワークレイヤーでクロスネットワーク(ネットワークファブリック)を構成し、さらにオーバーサブスクライブもしないように制限することで、他のユーザートラフィックからの影響を受けない安定したパフォーマンスのネットワークを構築しているという。

 こうした新しい設計を背景として、他社クラウドにはない「3つのSLA(サービスレベル保証)」を実現しているとクマー氏は説明した。主要他社のクラウドでは「可用性」のSLAは提供しているが、OCIの場合はそれだけでなく、ネットワークやブロックストレージの「パフォーマンス」に対するSLA、また管理APIが確実に使えることを保証する「管理性」のSLAも定めている。

OCIでは単なるサービス可用性だけでなく「パフォーマンス」に対するSLAも定めている

 ちなみに東京リージョンなどのOCI第2世代インフラでは、可用性向上のために、従来のアベイラビリティドメイン(AD:Availability Domain)ではなく「フォールトドメイン(FD:Fault Domain)」という考え方を採用している。これは同一データセンター内で、電源/空調系統の異なる3つのハードウェア構成を稼働させ、顧客が高可用性(HA)構成をとれるようにする仕組みだ。

前へ 1 2 次へ

カテゴリートップへ