Skip navigation
1 2 3 Previous Next

Oracle Cloud 公式ブログ

140 posts

皆様、こんにちは!

AnalyticsSC西門です。

 

Analytics Cloud(通称OAC)105.2、105.2.3がリリースされています。

Desktop版もバージョンアップされており、

もう既に新しい環境にアップデートされてお使いの方もいらっしゃると思います。

 

OACインスタンスの中止(Pause and resume services)機能やスケール(Scale service up and down)機能など要望の多かった機能

オンプレミス版のみ可能であったUsage Tracking(Track usage)機能、ライトバック(Modify data in tables)機能がOACでも可能になっています。

新機能の詳細は以下ご確認ください

 

■Oracle Analytics Cloud What's New

https://docs.oracle.com/en/cloud/paas/analytics-cloud/acswn/index.html#ACSWN-GUID-CFF90F44-BCEB-49EE-B40B-8D040F02D476

 

以下のブログ記事で各新機能の紹介をしています。

OAC v105.2.0 New Features

※本ページは、"Oracle Cloud Infrastructure Launches Tokyo Region"の翻訳です
日本オラクル・プレスリリースも合わせてご覧ください


オラクルは、企業が最も困難なビジネステクノロジー問題を解決するのを支援します。長年にわたり、オラクルは日本企業から高い信頼を得てきました。今回さらにお客様をサポートするため、東京でOracle Cloud Infrastructureデータセンター・リージョンを開設できたことを非常に嬉しく思っています。

 

日本の売上高上位50社は、自社のデータセンターでOracleソフトウェアを使用しています。その内32社はOracle Cloudを何らかの方法で使用しています(クラウドアプリケーションやサービスなどを含む)。オラクルの実績ある第2世代パブリッククラウドテクノロジに基づく、東京リージョンは、自信を持ってクラウドの採用を増やすために必要な、高性能、セキュリティ、回復力、およびローカルデータの常駐性に対するニーズに対応します。また、日本を拠点とする多くのお客様がグローバルに事業を展開しているため、東京リージョンは、グローバルな拡大とデータの普及を促進する出発点となります。当社の高速で安全なデータバックボーンを使用することにより、東京リージョンのお客様は、世界中のどこへでも安全かつ迅速にデータを配置することができます。

 

日本でのクラウド投資は劇的に成長しています。最新のIDC Japan株式会社発行「国内パブリッククラウドサービス市場予測」によると、2018年の国内パブリッククラウドサービス市場規模は、前年比27.2%増の6,688億円に達しています。同社では、2018年~2023年の年間平均成長率は20.4%で推移し、2023年の市場規模は2018年比2.5倍の1兆6,940億円になると予測しています*。オラクルは、オラクルの主要なデータベースおよびエンタープライズ・アプリケーション、そして企業がビジネスを推進するために使用するサード・パーティーおよびカスタムのワークロードに最適化されたクラウド・プラットフォームの東京リージョンにより、クラウドに対するこの高い需要を満たすことができます。

 

Oracle Cloud Infrastructureは、他のどのクラウドプラットフォームでも利用できない強力なデータソリューションを提供しています。これらのソリューションを日本国内で利用できるようになったことにわくわくしています。当社の最も重要なソリューションのいくつかは、Exadata Cloud Service、Autonomous Databaseサービス、および最先端のGPUおよびHPCコンピューティングシェイプを含むハイパフォーマンスコンピューティング(HPC)オプションです。

  • Exadataは、最高レベルのパフォーマンス、規模および信頼性でOracle Databaseを実行するために最適化されたハードウェア・プラットフォームです。日本の何百もの会社が彼らの最も重要なアプリケーションを動かすためにExadataが活用されてきました。ITインフラストラクチャの主要部分をクラウドに移行しているため、一歩後退することはできません。オラクルは、柔軟でオンデマンドのクラウドサービスとしてExadataの機能を提供する唯一のクラウドサービスです。これにより、これらの顧客は、ビジネスニーズを満たすために頼る機能を損なうことのないクラウドへの道を開くことができます。
  • Autonomous Transaction ProcessingとAutonomous Data Warehouseは、Oracle Databaseテクノロジの次の進化を表しており、クラウド・サービスとしてのみ利用可能です。これらは完全に自動化されたデータベースサービスであり、管理時間とエラーや設定ミスの可能性を劇的に削減します。このサービスは、操作を合理化し、設定と最適化のための手動タスクを排除するために高度な人工知能を使用することによって実現しています。東京リージョンでAutonomous Databaseを利用できることは、データを管理し、データから価値を引き出すという点で、より良い結果を求めている日本企業に大いに役立ちます。
  • GPUシェイプやHPCシェイプ(クラスタ化されたコンピューティングのためのRMDA相互接続ファブリック)など、Oracle Cloudの高速コンピューティングサービスも東京リージョンで利用可能になります。オラクルは、ベアメタルサーバー上でGPUとRDMAを提供する唯一の主要なクラウドベンダーです。また、ビッグコンピューティングとビッグデータの問題を解決するための最先端の製品を高いコストパフォーマンスで提供しています。高性能コンピューティング、特に高度な製造シミュレーションに対する需要が大きい日本にこれらの製品を提供することに興奮しています。

 

Oracle Cloudが日本にもたらす主な利点の1つは、ソリューションの総コストです。オラクルは、同じ価格設定を世界中で提供している点でユニークです。米国外での使用には追加料金はかかりません。そのため、これらのサービスを日本に導入したときに、すでに大幅な価格優位性が高まります。オラクルの標準仮想マシンは、米国のAmazon Webサービス(AWS)やMicrosoft Azure VMよりも49%安くなっていますが、日本では58%安くなっています。日本での当社のGPUインスタンスは、AWSよりも46%、Azureよりも61%低かったのに対し、米国では26%低でした。これらのメリットは、当社のポートフォリオ全体で見られるものであり、Oracle Cloudのお客様が一貫したグローバルな使用をサポートするのを支援するという当社の取り組みを表しています。

 

日本のお客様は、最も重要な企業ワークロードを実行するために、東京リージョンが開設されたことに興奮しています。 ※次のお客様から賛同コメントをいただきました、内容は日本オラクル・プレスリリースをご覧ください

  • エイベックス株式会社、全日本空輸株式会社、西日本電信電話株式会社、パーソルホールディングス株式会社、株式会社ベネッセホールディングス、マツダ株式会社、株式会社三越伊勢丹、株式会社リクルートテクノロジーズ、株式会社リコー、リコーITソリューションズ株式会社、ヤマハ株式会社、他パートナー各社様

 

東京リージョンで以下のサービスを製品を提供します(一部今後提供予定)。

  • コンピューティングサービス:Intel-based VM and bare metal compute instances, GPU instances, HPC bare metal instances, Container Engine for Kubernetes Engine and Registry
  • ストレージサービス:Block Volumes, File Storage, Object Storage, Archive Storage
  • ネットワークサービス:Virtual Cloud Network, Load Balancing, FastConnect, DNS
  • データベースおよび分析サービス:Oracle Database as a Service, Exadata Cloud Service, Autonomous Transaction Processing, Autonomous Data Warehouse, Analytics Cloud
  • 管理とセキュリティ:Identity and Access Management, Tagging, Audit, Key Management, Identity Cloud Service (for hybrid cloud and multicloud)
  • アプリケーションプラットフォームと統合サービス:Java Cloud Service, SOA Cloud Service

 

オラクルは、エンタープライズ・ユーザーのニーズを満たす変革的なクラウド戦略に取り組んでいます。当社のクラウドは、オラクル、サードパーティ、およびカスタムのアプリケーションを含むあらゆる種類のエンタープライズワークロードにわたって、大規模で変動のないパフォーマンスを提供します。あらゆる用途で柔軟で、予測可能な低コスト。リスクを最小限に抑えながら、あらゆる種類のワークロードをクラウドに移行することができます。東京リージョンが利用可能になったことで、日本でのエンタープライズテクノロジの革新と変革の新しい章が始まることを楽しみにしています。今年後半には、大阪リージョンの開設を予定します。これにより、国内で最も要求の厳しい企業や公的機関の間で効果的なワークロードの展開がさらに可能になります。

 

* 出典:IDC Japan プレスリリース、「国内パブリッククラウドサービス市場予測を発表」(2019年3月27日)

こんにちは。AnalyticsSC Nishikadoです

Oracle Analytics Cloud のBIEEインスタンス ver105.2以降 では、オンプレミスのBIEEと同様、データベースへの「ライトバック」が実装できます

 

オンプレミスのBIEEではWriteback用にSQLをxmlファイルで記述し指定の箇所へ配置しますが、

OACではOSにログインできないので、コンソールメニュー サービス管理の「構成 システム設定」画面で入力します。

その他の「ライトバック」の実装ステップはオンプレミスのBIEEと同様です

 

参考マニュアル

https://docs.oracle.com/en/cloud/paas/analytics-cloud/acabi/deploying-write-back.html

Deploying Write-back

 

添付の資料をご確認ください

こんにちは。AnalyticsSC Nishikadoです

 

5/17以降 作成したインスタンス ver105.2-312 ではBI・DVおよびEssbaseともに中止/開始ができるようになりました。

インスタンス中止後にアクセスするとHTTP 403 (Forbidden)です

 

添付の資料をご確認ください

こんにちは。AnalyticsSC Nishikadoです

 

Oracle Analytics Cloud のインスタンスがスケールできるようになっています

 

スケールする手順自体はシンプルです

 

OCPUの増減数を指定します

 

スケール範囲は作成時のOCPU数で決まります

https://docs.oracle.com/en/cloud/paas/analytics-cloud/acsom/administer-services-analytics-cloud.html#GUID-ADAA5E4E-5725-…

ESSBASEで作成したインスタンスはスケール不可です

サービスダッシュボードでスケールを実行すると以下のメッセージが表示されます

Unable to submit the scaling request. Check additional validation errors for details. [Scale service is not supported for ESSBASE]

 

添付の資料をご確認ください

こんにちは。AnalyticsSC Nishikadoです

 

Oracle Analytics Cloud のインスタンスを作成する手順を紹介します

作成する手順自体はシンプルです。

インスタンス作成画面で名前、リージョン、インスタンス種別BI(BIEEとDV) or Essbase or DVのみ、OCPU数を指定するだけです。

 

 

Software Editionを選択したものによって、選択できるFeature Setが変わります

また、指定するOCPU数によってダウンロード件数やスケールの範囲(OCPU数の制限)があります

合わせて、参考ください。ver105.2-311以降

・ダウンロード件数

https://docs.oracle.com/en/cloud/paas/analytics-cloud/acsom/create-services-oracle-analytics-cloud.html#GUID-FC08583C-28…

・スケール範囲

https://docs.oracle.com/en/cloud/paas/analytics-cloud/acsom/administer-services-analytics-cloud.html#GUID-ADAA5E4E-5725-…

 

添付の資料をご確認ください

Oracle Analytics Cloud のDataVisualizationでOracle Cloud Infrastructure Database (以下、OCI DB)に接続を作成する手順についてご紹介します。

 

前提:OCI DBはPublic Subnetにプロビジョニング

 

OCI DBで下記設定/情報を取得します

1)OCI DBをプロビジョニングしたVCNでsecurity listを更新し TCP 1521ポートで通信できるようにします。

2)OCI DBのコンソールで、Public IP、管理用サービスのサービス名を取得します

3)SQL DeveloperやSQL Plusで管理サービスに接続し、PDBのGlobal Nameを取得します。

 

OAC DVからOCI DBへは、OCI DBのPublic IPに接続します。

取得した情報をOAC DVの接続の作成で入力します

 

添付の資料をご確認ください

 

より詳しくは、マニュアルの以下を参照ください。

cloud/paas/analytics-cloud/acsom/administer-services-analytics-cloud.html#GUID-2ED88186-CA4B-…

こんにちは。AnalyticsSC Nishikadoです

 

Oracle Analytics Cloud のDataVisualizationでOracle Autonomous Transactoin Prosessing(以下、ATP)に接続を作成する手順についてご紹介します。

接続の作成手順は、Autonomous Data Warehouse への接続手順と同様です。

 

ATPで下記情報を準備します

1)ATPのDetails画面で、Wallet_<ATP名>.zip をダウンロードしておきます

2)ATPのDetails画面で、接続情報を書き留めておきます

3)ATPで、分析データが格納されているDBユーザーとパスワードを書き留めておきます

 

取得した情報をOAC DVの接続の作成で入力します

 

添付の資料をご確認ください

こんにちは。AnalyticsSC Nishikadoです

 

Oracle Analytics Cloud のDataVisualizationでOracle Autonomous Data Warehous Cloud(以下、ADWC)に接続を作成する手順についてご紹介します。

昨年12月にOAC 18.3.3版を紹介後、105.x から変更があります。

 

ADWCで、下記情報を準備します

1)ADWCのDetails画面で、クライアント資格証明 Wallet_<ADW名>.zip をダウンロードしておきます

2)ADWCのDetails画面で、接続情報を書き留めておきます

 ADWC名_MEDIUMなど

3)ADWCで、分析データが格納されているDBユーザーとパスワードを

 書き留めておきます

例えば、ユーザー SCOTT  、 パスワード TIGERなど

 

ADWCのDetails画面の「DB接続」をクリックすると、

Wallet_<ADW名>.zipや接続情報を取得する画面が表示されます

取得した情報をOAC DVの接続の作成で入力します

クライアント資格証明はWallet_<ADW名>.zipを選択すると、cwallet.soと表示されます

サービス名はWallet_<ADW名>.zipを選択後にリストが表されます

添付の資料をご確認ください

Autonomous Database (Autonomous Data Warehouse(ADW)/Autonomous Transaction Processing(ATP)) のライセンス・タイプを後から変更することが可能になりました。

 

・リリース・ノート : Updating License Type for Autonomous Databases

マニュアル : To change the license type of an Autonomous Database

 

はじめに

Autonomous Databaseをご利用の際に、選択可能なライセンス・タイプは2種類あります。

  • License Included  : 通常レートでPaaSを利用するタイプ
  • Bring Your Own License (BYOL) : 既に保持しているライセンスを移行・持ち込むことで通常レートから大幅に低いレートでPaaSを利用するタイプ

byol.PNG

(※上記は2019/04/19時点の情報です)

インスタンスを作成する際に、どちらのタイプで利用するかを選択するのですが、後から変更が必要になった場合に再作成することなく、変更することが可能です。

 

ライセンス・タイプの変更方法

対象のAutonomous Databases の管理コンソールを表示し、対象のインスタンスの詳細画面を表示します。

00.PNG

今のライセンス・タイプは、『Autonomous Database情報』の『ライセンス・タイプ』で確認できます。この環境では、"Bring Your Own License"になっているのが確認できます。

 

右上のほうにある、『Actions』をクリックし、『ライセンス・タイプの更新』をクリックします。

01.PNG

ポップアップで現在のライセンス・タイプが選択された状態で表示されます。

02.PNG

今回変更したいラインセンス・タイプのLicense Includedにあたる『SUBSCRIBE TO NEW DATABASE SOFTWARE LICENSES AND THE DATABASE CLOUD SERVICE』を選択して『更新』ボタンをクリックします。

03.PNG

 

"ライフサイクル状態"が"更新中"から"使用可能"になれば、更新完了です。

04.PNG

05.PNG

ちなみに、この変更の最中はサービスへの影響はなく情報の更新のみなので、更新作業中もサービスはご利用いただけます。

(今回試してみた時には数秒で切り替わりました)

 

関連リンク

Oracle Autonomous Data Warehouse Cloud(ADWC):データウェアハウス(DWH)・クラウド - 概要/価格/マニュアル/トライアル/事例

Autonomous Data Warehouse (ADW)と Autonomous Transaction Processing (ATP) でクローン機能がリリースされました。

これにより、テスト/検証/分析用途の環境複製を、すぐに簡単に作成することができるようになります。

 

新機能マニュアル

マニュアル

 

早速試してみたので、作成方法を簡単にご紹介します。

 

クローン環境の作成方法

1. ソースのインスタンスを選択して「Create Clone」をクリック

ソースのインスタンスの詳細情報(Autonomous Database > Autonomous Database Detail ) の画面の「Actions」、もしくはインスタンス一覧の画面(Autonomous Database) でソースのインスタンスの右側をクリックし、『Create Clone』をクリックします

  • ソースのインスタンスの詳細情報(Autonomous Database > Autonomous Database Detail ) の画面の「Actions」> 「Create Clone」
    createclone01

もしくは

  • インスタンス一覧の画面(Autonomous Database) でソースのインスタンスの右側のマークをクリック > 「Create Clone」
    createclone02

2.クローン環境の情報を入力

クローン環境の情報を入力していきます。

  • Clone Type
    2種類のクローン形式が用意されているので、FULL CLONE もしくは METADATA CLONE のいずれかを選択します
    • FULL CLONE :  メタデータとデータ
    • METADATA CLONE : メタデータのみ
  • Database Information
    下記の情報をそれぞれ入力します
    • COMPARTMENT :
    • DISPLAY NAME : デフォルトで"Clone of <ソースのインスタンスの表示名>"が自動入力されているので、任意の名前を入れてください
    • DATABASE NAME : デフォルトでデータベース名が自動入力されているので、任意の名前を入れて下さい
    • CPU CORE COUNT : 1~128で割り当てるCore数を入力します
    • STORAGE(TB) : 1~128(TB)で割り当てるストレージサイズを入力します。FULL CLONEの場合は、ソースのインスタンスに割り当てているサイズと同じもしくはそれ以上である必要があります
  • Administrator Credentials
    ADMINユーザーのパスワードを入力します
  • License Type
    License Type(BYOLかSubscription)を選択します
    • MY ORGANIZATION ALREADY OWNS ORACLE DATABASE SOFTWARE LICENSES(デフォルト)
    • SUBSCRIBE TO NEW DATABASE SOFTWARE LICENSES AND THE DATABASE CLOUD SERVICE

3. 「Create Autonomous Database Clone」をクリックして作成

createclone04

 

4.確認

ソースと同じWorkload Type(今回はATPのインスタンスのクローンを作成したので、Transaction Processing)で作成されています。

created01

 

クローン環境の作成も簡単にできますね。

詳細情報は、前述したドキュメント等をご参照ください。

先日、Oracle Cloud InfrastructureのService Gatewayの機能がエンハンスされました。

Service Gatewayとは、「Public IPアドレスを持つサービスに対して、プライベートアクセスを行うためのネットワークの設定」です。
以前は本機能の対象サービスがオブジェクトストレージのみだったのですがその他のサービス(特にPaaS系サービス)も対象となりました。

クラウドのネットワーク設計を行う上で大きな意味を持ち、地味に重要です。

 

VCN内のインスタンスからOCIのパブリックサービスにアクセスする際、そのネットワーク経路上にService Gatewayを挟むだけでセキュアに、

かつ無駄なルートを経由しないアクセスが可能になる便利な機能ですが、この「Service Gateway自体がボトルネックになることはないのか?」とか

「Internet Gatewayと比較して性能はどうなるのか?」など、いざ設計をする際に疑問に思ってしまいそうです。

 

ということで今回もクイックにテストしてみたいと思います。

PaaS系のサービスがサポートされたのでAutonomous DatawarehousやAutonomous Transaction Processingを使ってみたいところなのですが、

以前実施した「オラクルのオブジェクトストレージの性能は?」の結果と比較を目的としたいので

シンプルにオブジェクトストレージへのアップロード、ダウンロード処理でテストしてみたいと思います。

 

つまり、「Internet Gateway vs. Service Gateway」をオブジェクトストレージへのアップロード・ダウンロードのスループットで比較しようと思います。

 

テスト概要

繰り返しになりますが、以前実施した「オラクルのオブジェクトストレージの性能は?」と全く同じインスタンスから全く同じワークロードを実行してみたいと思います。

下記図のようにVCN内のBare Metal ComputeインスタンスからService Gateway経由でObject Storageにガンガンに負荷をかけてゆきます。

 

 

因みに以前実施したテストの構成を同じ図にすると下記のようになります。

当然、違いは「GatewayがService GatewayかInternet Gatewayか」だけです。

 

 

以下、早速結果です。

 

単一ラージファイル(1GB x1個)のアップロードとダウンロード性能


下記グラフからアップロードピーク時、150MB/sec程度、ダウンロードピーク時、60MB/sec弱のスループットだということがわかります。。

 

 

複数ラージファイル(1GB x50個)のアップロードとダウンロード性能

 

下記グラフからアップロードピーク時、3.1 GB/sec程度、ダウンロードピーク時、2.6GB/sec程度のスループットだということがわかります。

 

 

比較してみる(Internet Gateway vs. Service Gateway)

 

下記グラフのように単一ファイル(1GB x1個)のアップロード、ダウンロードともにService Gateway経由のほうが高いスループットがでていることがわかります。

特にアップロード時の性能差が顕著ですね。

 

 

纏めると下記のような感じでしょうか。

 

     アップロードピーク
          Service Gateway経由:約150MB/sec

          Internet Gateway経由:約70MB/sec
     ダウンロードピーク

          Service Gateway経由:約58MB/sec

          Internet Gateway経由:約42MB/sec

 

 

下記グラフのように、複数ラージファイル(1GB x50個)のアップロード、ダウンロードともにService Gateway経由のほうが高いスループットがでていることがわかります。

こちらもアップロード時の性能が顕著、かつ、Service Gatewayのほうがスループットが安定しているように見えます。

 

 

こちらもまとめると下記のような感じです。

 

     アップロードピーク
          Service Gateway経由:約3.1GB/sec

          Internet Gateway経由:約2.9GB/sec
     ダウンロードピーク

          Service Gateway経由:約2.6GB/sec

          Internet Gateway経由:約2.5GB/sec

 

 

考察

全体的にService Gateway経由のほうが性能がよく、特にアップロード時は特にその差が顕著となっています。

また、全てのケースではないがスループットのブレが少ない傾向がみられるのもメリットかと思います。

所感として、性能の劣化なく、セキュアアクセスができるService Gatewayは今のところ利用に際するデメリットは見当たらず、積極的に利用してよいように思います。

 

しかし、クラウドってほんと便利ですよね。このテスト作業は20分程度で完了しました。

最後に、賢明な読者の方々にはご理解いただいていると思いますが、上記は参考値ですのでくれぐれもこの値をベースに実システムのサイジングをすることは避けてくださいね。

 

参考情報

Service Gatewayが利用可能なサービスのリスト

Service Gateway: Supported Cloud Services in Oracle Services Network

 

Service Gatewayのマニュアル

Access to Oracle Services: Service Gateway

 

Service Gatewayエンハンスのブログ

Access Oracle Services Privately with a Service Gateway

皆様、こんにちは! Analytics SC高橋です。

 

さて、先日、Analyticsのパートナー様向けに定期技術アップデートセミナーを開催させていただきました。

SCメンバーでセミナー時にご紹介させていただきました新機能の資料を一部公開させていただきます。

 

今回のアップデートのメインテーマは、”移行”です。

よりたくさんのコンテンツをスナップショットの機能で簡単に移行することが可能になりました。

 

詳しい内容は資料に記載させていただいておりますので、ぜひご確認ください。

オンプレミスからクラウドストレージ(オブジェクトストレージ)へのアップロード、ダウンロード性能を見積もることはなかなか難しいですよね。

 

  • 対象ファイルサイズは小さいのか、大きいのか?
  • ファイル数は?
  • サーバーのNICの帯域はどれくらいあるのか?
  • サーバーの上位スイッチはどの程度の帯域があるのか?
  • 契約しているインターネット回線の帯域はどの程度なのか?
  • そもそもクラウドベンダーのオブジェクトストレージサービスってどの程度の性能がでるんだろ?

 

など、ぱっと思いつくだけでもいろいろと考えなければいけないなぁという感じです。上記ほとんどが、そのときそのときの状況によって変わってくるので事前に性能テストをしてもあまり意味がなさそうです。ただ、「そもそもクラウドベンダーのオブジェクトストレージサービスってどの程度の性能がでるんだろ?」は事前のテストデータは参考になりそうです。なので簡単な性能測定をしてみようと思います。

 

テスト概要

オラクルクラウド内に作成したComputeインスタンスからオブジェクトストレージにラージファイルをアップロードダウンロードした際のスループットを計測。つまりインターネット回線のボトルネックの影響を気にせず純粋にオブジェクトストレージの性能(特にスループット)を計測してみます。

 

環境情報

以下のような環境でテストしてみました。リージョンはPhoenixです。

 

スペック的には以下のようになっており、特筆すべきは、物理コア52コア104スレッド、かつNICは25Gbpsという大規模なベアメタルのインスタンスでオブジェクトストレージに負荷をかけいく点です。NICの限界までスループットが伸びればいいなぁという思いがあります。

 

  • Computeインスタンス:BM.Standard2.52
    • CPU : 52コア(104スレッド)
    • メモリ : 768 GB
    • NIC : 25 Gbps
  • Bucket : Standard Bucket

 

単一ラージファイルのアップロードとダウンロード性能

まずはラージファイル一つをアップロード、ダウンロードしてみます。

1GBのラージファイルをメモリ上(/dev/shm)に作り、これをアップロード、ダウンロード用のテストデータにします。ストレージ上にテストデータを作ると、ストレージIOまで考慮しなければならず面倒です。一般的なシステムですと、ストレージIOよりもネットワークIOが速くなる構成はあまりありませんが、今回は何といっても25 GbpsのNICを搭載しているインスタンスを使いますのでストレージIOに引っ張られないようにメモリにテストデータを置きます。パフォーマンスログもストレージIOを見る必要がなくなるので一石二鳥です。

 

アップロード、ダウンロードはocicliというoracle cloud用のツールを使います。ocicliとはなんだろ?という方はこちら

下記のようなコマンドでアップロードしてゆきます。コマンドの簡単な説明としては、-nsでテナント名を指定、-bnでバケット名を指定、--fileでアップロード対象のファイルを指定という感じです。このコマンドはマルチパートアップロードとなり、下記ログからわかるように1GBのラージファイルを8つのパーツに分けて並列アップロードを行います。

 

$ oci os object put -ns OracleSonoda -bn SonodaBucket --file /dev/shm/data_1GB

Upload ID: b6156b09-7eb4-ae1c-617b-9c9bd3a5a37d

Split file into 8 parts for upload.

Uploading object  [####################################]  100%

{

  "etag": "fac242b7-28ca-429b-9a10-de1eb5835d2a",

  "last-modified": "Wed, 27 Feb 2019 06:40:08 GMT",

  "opc-multipart-md5": "KKRDS43OuPhjAwVlwXJM+A==-8"

}

 

ダウンロードは以下のように実行します。アップロード違う点は、--nameでオブジェクトストレージ上のオブジェクト名を指定し、--fileでダウンロードしたときにつけるファイル名を指定するところくらいです。

 

$ oci os object get -ns OracleSonoda -bn SonodaBucket --name data_1GB --file /dev/shm/down_1GB

Downloading object  [####################################]  100%

 

結果としては以下のようなグラフになりました。まあ、こんなもんでしょうか。スループットとしてはアップロード時、ピークで80MB/s、ダウンロード時、ピークで40MB/sしか出ていません。CPUの使用率も1.5%以下と非常に低い。予想通り、負荷が低すぎて、スループットはあまり伸びないですね。

 

アップロードの結果

 

ダウンロードの結果

 

 

複数ラージファイルのアップロードとダウンロード性能

せっかく25 GbpsのNICがついているインスタンスなので、これで終わってはもったいない。もっと負荷を上げていきたいと思います。NICの限界が先か、オブジェクトストレージサービスの限界が先か。

 

負荷を上げるアプローチは単純です。要は複数ファイルを同時並行でアップロードすればよいだけ。本来はmulti processingのライブラリを使って行儀よくやったほうがいいのですが、少し面倒ですね。。。しょうがない、アレをやります。。。クイック・パラレル・プロセッシング!(ただ単にアップロードコマンドに「&」をつけてfor文でブン回すだけ。)

 

ということでメモリ上に1GBのファイルをとりあえず50個作りました。

↓こんな感じ。

for i in `seq 1 50`; do

dd if=/dev/zero of=/dev/shm/data/data_1GB_${i} bs=1G count=1

done

 

で、この1GB x50個のファイルを50多重で一気にアップロードします。

↓こんな感じ。

for i in `seq 1 50`; do

oci os object put -ns OracleSonoda -bn SonodaBucket --file /dev/shm/data/data_1GB_${i} &

done

 

当然、ダウンロードも50多重で一気にダウンロード。

↓こんな感じ。

 

for i in `seq 1 50`; do

oci os object get -ns OracleSonoda -bn SonodaBucket --name data_1GB_${i} --file /dev/shm/data/down_1GB_${i} &

done

 

で、結果のグラフがこちら。

アップロードはピーク時、約3GB/sec(=約24Gbps)も出ました。CPU使用率もだいぶ上がりました。

 

 

ダウンロードもピーク時、約2.5GB/sec(=約20Gpbs)まで上がりました。

 

 

しかし、クラウドって本当に便利ですね。。。簡単なテストとは言えオンプレミスでテストしようとするとそれなりに手間と時間がかかりますが、クラウドだとわずか30分足らずで完了です。

 

考察

  • 今回のテストケース(ラージファイル50多重)ではオブジェクトストレージはボトルネックとならず、NICの限界性能に近い値がでているといっていいと思います。
    • アップロードに関しては25Gbps NICに対して24Gbpsと95%も帯域を使えている
    • ダウンロードに関しては25Gbps NICに対して20Gbpsと80%の帯域を使えている
  • ダウンロードに関してはもうちょっとでてもいいかなと思います。おそらくファイル数がもっと多くて同時ダウンロード数が多い場合はスループットがもっと伸びるのだろうと思います。
  • つまり、この程度ではオブジェクトストレージがボトルネックになることはないということがわかりました。
  • 今回は一つのインスタンスから負荷をかけましたが、複数インスタンスから同時に負荷をかけるともっとスループットが伸びそうですね。(また機会がありましたら実施したいと思います。)

 

しかし、CPUを使い切ってくれるツールってなかなかないですよね。。。

どなたかいいツールをご存知でしたらコメント欄で教えていただけると幸甚です。。。

 

最後に、賢明な読者の方々にはご理解いただいていると思いますが、上記は参考値ですのでくれぐれもこの値をベースに実システムのサイジングをすることは避けてくださいね。