[Machine Learning] Introducing GraphPipe

原文はこちら。
https://blogs.oracle.com/developers/introducing-graphpipe

Dead Simple Machine Learning Model Serving

ここ数年で機械学習は急速に進歩し、今日ではどれか一つのフレームワークを使って、オンラインチュートリアルに従い、動作する機械学習モデルを数時間で作成できるようになりました。しかし残念なことに、そのモデルを本番環境に展開する準備ができたとしても、まだ固有の課題に直面します。

第一に、モデルを提供するAPIに標準がないため、フレームワークで提供されるもので悩まされる可能性があります。これは、Protocol Buffersかもしれませんし、カスタムのJSONかもしれません。あなたのビジネスアプリケーションは、デプロイされたモデルと話すためだけに、特注のクライアントを必要とすることが一般的です。複数のフレームワークを使用している場合はさらに事態が悪化します。複数のフレームワークからモデルのアンサンブルを作成したい場合は、組み合わせるためのカスタムコードを記述する必要があります。

第二に、モデルサーバーの構築は非常に複雑です。デプロイはトレーニングほど注意を払う必要がないため、すぐに使えるソリューションはほとんどありません。例えば、TensorFlow ServingのGPUバージョンを構築してみてください。頭を数日間打ちつける準備をしておくべきでしょう。

最後に、既存のソリューションの多くはパフォーマンスに重点を置いていないため、特定のユースケースではパフォーマンスが不足します。Python-JSON APIを使えば複雑なモデルからtensorデータの束を取得できますが、パフォーマンスが重要なアプリケーションのためにそのデータの束をカットしてはくれません。

この3つの課題を解決するためにGraphPipeを作成しました。ネットワーク経由でtensorデータを送信するための標準的な高性能プロトコルと、あらゆるフレームワークの機械学習モデルを簡単にデプロイおよび照会するクライアントおよびサーバーの簡単な実装を提供します。GraphPipeの効率的なサーバーは、TensorFlow、PyTorch、MXNet、Microsoft Cognitive Toolkit (CNTK)、またはCaffe2で構築されたモデルに対応できます。
TensorFlow
https://www.tensorflow.org/
PyTorch
https://pytorch.org/
MXNet: A Scalable Deep Learning Framework
http://mxnet.ai/
Microsoft Cognitive Toolkit (CNTK)
https://www.microsoft.com/en-us/cognitive-toolkit/
Caffe2 - A New Lightweight, Modular, and Scalable Deep Learning Framework
https://caffe2.ai/
GraphPipeがOracleのGitHubからご利用いただけるようになったことを発表できうれしく思っています。ドキュメンテーション、サンプル、その他の関連コンテンツは、以下にあります。
GraphPipe -- Dead Simple ML Model Serving via a Standard Protocol
https://oracle.github.io/graphpipe

The Business Case

企業組織では、機械学習モデルは個別に訓練され、特注の技術を使用して導入されることがよくありますが、これは機械学習の取り組みから価値を引き出す組織の能力に影響を与えます。ファイナンスグループが作成したモデルをマーケティンググループが使用したい場合、モデルと対話するカスタムクライアントを作成する必要があります。モデルに人気が出て営業グループも利用したいと思った場合、カスタムクライアントが負荷に耐えられない可能性があります。

モデルが顧客が目にするモバイルアプリケーションやIoTアプリケーションに現れ始めると、悪化する一方です。多くのデバイスはモデルをローカルで実行できるほどの能力はないため、リモートサービスに要求する必要があります。このリモートサービスは、さまざまな機械学習フレームワークのモデルを実行しながら、効率的で安定していなければなりません。

標準があれば、研究者はお望みのツールを使って最良のモデルを構築し、特別なクライアントを使わなくてもユーザーはモデルの予測にアクセスできます。モデルを複数のサーバーにデプロイでき、共通のプロトコルを使ってより大きなアンサンブルに簡単に集約できます。GraphPipeは、ビジネスが機械学習の投資から価値を引き出すために必要なツールを提供します。

Implementation Details

GraphPipeは、リモートプロセス間の機械学習データの送信を簡素化し、標準化するために設計された効率的なネットワークプロトコルです。現在、深層学習アーキテクチャのコンポーネント間でtensorのようなデータの伝送方法に対する支配的な標準は存在しません。そのため、開発者にとっては、非常に非効率なJSONや、大規模で複雑なソフトウェアであるTensorFlowに付いてくるTensorFlow ServingのProtocol Buffersのようなプロトコルを使うことが一般的です。GraphPipeは、効率のよいバイナリのメモリマップフォーマットでありながら、シンプルかつ依存関係を少なくするように設計されています。

GraphPipeは以下のものを包含しています。
  • FlatBuffers定義のセット
  • FlatBuffers定義に従って一貫してモデルを提供するためのガイドライン
  • TensorFlow、ONNX、およびCaffe2からモデルを提供するサンプル
    ONNX
    https://onnx.ai/
  • GraphPipeを使って提供されるモデルを照会するためのクライアントライブラリ
要するに、GraphPipeリクエストはTensorFlow Servingの予測リクエストのように振る舞いますが、メッセージフォーマットとしてFlatBuffersを使用します。 FlatBuffersは、GoogleのProtocol Buffersと似ており、デシリアライズ時のメモリコピーを避けるという利点があります。FlatBuffers定義は、入力tensor、入力名、および出力名を含むリクエスト・メッセージを提供します。 GraphPipeリモートモデルはリクエスト・メッセージを受け取り、要求された出力名につき1個のtensorを返します。リモート・モデルは、サポート対象の入出力のタイプとシェイプに関するメタデータも提供する必要があります。

Performance

まず、カスタムujson APIを使うPython、TensorFlow Servingの予測リクエストを使用するProtocol Buffers、およびGraphPipeリモートリクエストでの、浮動小数点tensorデータのシリアライズ、デシリアライズの速度を比較します。リクエストは約1,900万の浮動小数点値(128個の224x224x3イメージで構成)で構成され、レスポンスは約320万の浮動小数点値(128の7x7x512畳み込み出力で構成)です。 縦軸の単位は秒です。

Flatbuffersではメモリコピーなしで基礎となるデータへアクセス可能なので、GraphPipeはデシリアライズ時の性能が特に顕著です。

次に、Python-JSON TensorFlowモデルサーバー、TensorFlow Serving、およびGraphPipe-Go TensorFlowモデルサーバーを使用して、エンドツーエンドのスループットを比較します。いずれの場合も、バックエンドモデルは同じです。に大きなリクエストを1個のスレッドを使用するサーバ、5個のスレッドを使用するサーバに投げています。縦軸の単位は、モデルによって計算された1秒あたりの行です。

このテストでは、Tensorflow Serving構築の推奨パラメータを使用していることにご注目ください。TensorFlow Servingの推奨ビルド・パラメータではあまり性能が出ませんが、最終的にはGraphPipe実装と同等のパフォーマンスを実現できるコンパイルパラメータを導き出すことができました。言い換えれば、最適化されたTensorFlow ServingはGraphPipeと同様のパフォーマンスを発揮しますが、TensorFlow Servingを最適に実行するためのビルド方法は文書化されておらず、そのビルドも容易ではありません。

Where Do I Get it?

ドキュメントやサンプルは以下の場所にたくさんあります。
GraphPipe -- Dead Simple ML Model Serving via a Standard Protocol
https://oracle.github.io/graphpipe
GraphPipeのFlatBuffersの仕様はPythonやGoの仕様を実装するサーバと共にGitHub上にあります。
GraphPipe - Dead Simple ML Model Serving via a Standard Protocol
https://github.com/oracle/graphpipe
Python、Go、Java(これはまもなくリリース予定)のクライアント、ローカルのTensorFlowグラフの中にリモートモデルを含めることができるTensorFlowプラグインも提供します。
GraphPipe for python
https://github.com/oracle/graphpipe-py
GraphPipe for Go
https://github.com/oracle/graphpipe-go
GraphPipe for Java (2018/08/16現在リンクはまだ有効ではありません)
https://github.com/oracle/graphpipe-java
GraphPipe helpers for TensorFlow
https://github.com/oracle/graphpipe-tf-py

[Database, Java] Java Scalability with Sharded Database

原文はこちら。
https://blogs.oracle.com/dev2dev/java-scalability-with-sharded-database

ユーザー数、トランザクション数、およびデータが指数関数的に増加しているため、スケーラビリティはJavaアプリケーションにとって非常に重要です。シャーディング(Sharding)は、ハードウェアやソフトウェアを共有しないデータベースのプール全体にデータを分散して複製する方法で、個々のデータベースはシャード(shard)と呼ばれます。Javaアプリケーションは、プールへのデータベース(シャード)の追加や削除により、リニアにスケールアップ・スケール・ダウンできます。

リニアなスケーラビリティを達成することに加えて、シャーディングには他にも多くの利点があります。単一障害点を排除し、故障したシャードを他の動作しているシャードから隔離することで、高いデータ可用性をもたらします。シャードのサイズが小さいほど、クラウドへの展開が容易になります。また、シャーディングは異なる国または地域に異なるデータを配置することができるため、データの主権(data sovereignty)とデータの近接性(data proximity)を可能にします。

シャーディングでは、シャードには同じ列で行のサブセットが異なる表が含まれる水平パーティショニングを使用します。このパーティショニングはシャーディングキー(sharding key)に基づきます。シャーディングでは、優れたパーティショニング戦略を選択することが非常に重要です。良いシャーディングキーは、すべてのシャード間でデータが一様に分散するため、DMLやクエリーがホットシャードを作成せずに公平な分配されます。通常の場合、ユーザーまたはアプリケーションのオブジェクトを一意に識別する表の主キーはシャーディング・キーとして適格ですが、シャーディングキーを複数持つ場合もあります。例えばCustomer_IDはシャーディングキー、REGIONはスーパーシャーディングキーといった具合です。下図は、データが3つのシャードにどのように分配されるのかを示しています。これらのシャードはあわせて1個の論理データベースです。

How to make your Java applications shard aware?

Javaアプリケーションでは、特定のシャードへの接続を確立するためシャーディングキーまたは(あれば)スーパーシャーディングキーが必要です。シャードへのセッションが確立すると、すべてのSQLクエリとDMLを指定されたシャードのスコープ内で実行します。JDK 9の標準Sharding APIは、シャード対応のJavaアプリケーションを開発するためのシャードキーとスーパーシャーディングキーを受け入れます。
ShardingKey (Java SE 9 & JDK 9)
https://docs.oracle.com/javase/9/docs/api/java/sql/ShardingKey.html
ShardingKey (Java SE 10 & JDK 10)
https://docs.oracle.com/javase/10/docs/api/java/sql/ShardingKey.html
例えば、シャードされたデータベースに接続する際にシャーディング・キーとスーパーシャーディング・キーを受け入れるよう、Oracle JDBCドライバとUniversal Connection Pool(UCP)(12.2.0.1以降)は拡張されました。

例としてOracle Shardingをみてみましょう。
Oracle Sharding
http://www.oracle.com/technetwork/jp/database/database-technologies/sharding/overview/index.html
http://www.oracle.com/technetwork/database/database-technologies/sharding/overview/index.html
Oracle Database v12.2.0.1は、Global Data Services(GDS)を使ったシャーディングをサポートしています。シャード・ディレクター(Shard Director)またはGSMリスナー(GSM listener)が、接続要求中に渡されたシャーディングキーに基づいて適切なシャードに接続をルーティングします。シャード・トポロジ(特定のシャードに格納されているシャーディングキーのレンジ・マッピング)は最新にメンテナンスされます。クライアント・サイドの接続プールでは、シャード・トポロジーを取得し、クライアント・サイドにトポロジーをキャッシュするために、シャードへの接続を確立した1個の接続だけが必要です。その後、シャーディングキーを渡して接続を要求すると、接続プールはトポロジ内でそのキーが属するシャードを調べ、正しいシャードへの接続を返します。これが直接ルーティング(Direct Routing)です。例えば、Java接続プールはUCPはシャード・トポロジをキャッシュし、シャードディレクタとして機能します。そのため、UCPを使って構築されたアプリケーションは、シャードの高速パスを取得して、シャード・ディレクターへの追加ホップを節約します。

How to aggregate the data from all shards?

アプリケーションがすべてのシャード間でデータを集約する必要がある場合、シャード・カタログ(Shard Catalog)とも呼ばれるシャード・コーディネータ(Shard Coordinator)に接続して、クロスシャード・クエリ(cross-shard query)を実行できます。シャード・コーディネータまたはシャード・カタログを使用すると、ユーザーはシャーディングキーを指定せずにSQL文を発行できます。コーディネータのSQLコンパイラは、クエリを分析して、複数のシャードによって送信され実行されるクエリ・フラグメントに書き換えます。クエリ処理後、データはコーディネータが集約します。これがプロキシルーティング(Proxy Routing)です。

JDBC APIs for Sharding:

Sharding APIでは、データベースへの接続を確立するためにシャーディングキーを渡す必要があります。シャードされたデータベースに接続するには、次の手順が必要です。
  1. Build the sharding key(シャーディングキーの作成)シャーディングキーを作成して、シャーディングキー値とシャーディングデータタイプを渡してください。SQL DeveloperまたはSQLPlusを使用してシャードされたデータベースに接続し、テスト目的でシャーディング・キーのリストを取得できます。
  2. Build the super sharding key(スーパーシャーディングキーの作成)スーパーシャーディングキーはオプションです。シャードされたデータベースがスーパーシャーディングキーを使用していない場合は、この手順を無視してください。
  3. Getting a connection to the shard(シャードへの接続の取得)シャーディングキーとスーパーシャーディングキーを作成後、シャーディングキーに関連するデータを持つシャードへの接続に成功するために、これらのキーを渡す必要があります。
シャードされたデータベースをテストするためのサンプルコードは、JDBCShardingSample.javaを参照してください。

(訳注)
○○のコードを参照してください、とありますが、原文にもそのコードへのリンクがありません。

注意

JDBC driver 12.2.0.1は JDK9の標準Sharding API をサポートしていません。計画では、将来のデータベース・リリースでサポートする予定です。その代わりに、JDK 8やJDK 9を使うアプリケーションでSharding APIをサポートするため、Oracle JDBCドライバはoracle.jdbc.OracleShardingKeyを使います。

以下のコード・スニペットは、Oracle JDBCドライバを使ってシャードされたデータベースへの接続の確立する例です。
import oracle.jdbc.OracleShardingKey;
import oracle.jdbc.OracleType;
import oracle.jdbc.pool.OracleDataSource;

OracleDataSource ods = new OracleDataSource();
ods.setURL(url);
ods.setUser(user);
ods.setPassword(pwd);

// 1. Build the Sharding Key
Date shardingKeyVal = new java.sql.Date(0L);
OracleShardingKey shardKey = 
  ods.createShardingKeyBuilder()
     .subkey(shardingKeyVal, OracleType.DATE)
     .build();

// 2. Build the Super Sharding Key (Optional)
OracleShardingKey superShardKey =
  ods.createShardingKeyBuilder()       
     .subkey("Customer_Location_US”,oracle.jdbc.OracleType.VARCHAR2) 
     .build();

// 3. Get a connection from the specific shard
Connection conn = ods.createConnectionBuilder()
                     .shardingKey(shardKey)
                     .suerShardingKey(superShardKey)
                     .build();

UCP APIs for Sharding:

UCP Sharding APIはシャードされたデータベースへの接続を確立するためにシャーディング・キーを渡す必要があります。シャードされたデータベースをテストするためのサンプルコードは、UCPShardingSample.java を参照してください。

以下のコード・スニペットは、Oracle Universal Connection Pool (UCP)を使ってシャードされたデータベースへの接続を確立する例です。
import oracle.jdbc.OracleShardingKey;
import oracle.jdbc.OracleType;
import oracle.ucp.jdbc.PoolDataSourceFactory;
import oracle.ucp.jdbc.PoolDataSource;

PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");
pds.setURL(DB_URL);
pds.setUser(DB_USER);
pds.setPassword(DB_PASSWORD);
pds.setConnectionPoolName("UCP_POOL");
pds.setInitialPoolSize(5); //Initial connections when the pool is created
pds.setMinPoolSize(5); // Minimum number of connections
pds.setMaxPoolSize(20); // Set the maximum number of connections

// 1. Build the Sharding Key
String email= "test@test.com";
OracleShardingKey shardKey =  
  pds.createShardingKeyBuilder()                
     .subkey(email, OracleType.VARCHAR2)                 
     .build();

// 2. Build the Super Sharding Key (Optional)
OracleShardingKey superShardKey = 
  pds.createShardingKeyBuilder()      
     .subkey("Location_US”,oracle.jdbc.OracleType.VARCHAR2) 
     .build();

// 3. Get a connection to the specific shard
Connection conn = pds.createConnectionBuilder()
                     .shardingKey(shardKey)
                     .suerShardingKey(superShardKey)
                     .build();

Appendix:

シャーディングの解説、シャーディング・キーとしてサポートされるデータ型、新しいシャーディングAPIの詳細は、以下のドキュメントを参照してください。
Oracle® Database JDBC開発者ガイド 12c リリース2 (12.2)
データベース・シャーディングのJDBCによるサポート
https://docs.oracle.com/cd/E82638_01/jjdbc/database-sharding.html
Oracle® Database JDBC Developer's Guide 12c Release 2 (12.2)
JDBC Support for Database Sharding
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjdbc/database-sharding.html
Oracle® ユニバーサル接続プール開発者ガイド 12c リリース2 (12.2)
データベース・シャーディングのUCP共有プールの概要
https://docs.oracle.com/cd/E82638_01/jjucp/ucp-database-sharding-overview.html
Oracle® Universal Connection Pool Developer's Guide 12c Release 2 (12.2)
Overview of UCP Shared Pool for Database Sharding
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjucp/ucp-database-sharding-overview.html

[Cloud] Did you know you can access reports, logs, screenshots, etc., from your build?

原文はこちら。
https://blogs.oracle.com/wercker/did-you-know-you-can-access-reports%2C-logs%2C-screenshots%2C-etc%2C-from-your-build

ビルド中に作成したさまざまなデータに、ビルド完了後にアクセスしたいことがよくあります。例えばログ、テスト結果、もしかするとスクリーンショットも含まれるかもしれません。こうした情報は、ビルド失敗時に特に重要になります。
Werckerには、Web UIからこうしたデータを簡単に利用できるようにするための機能があります。ビルド中に発生したデータを特定のディレクトリ
$WERCKER_REPORT_ARTIFACTS_DIR
に配置すると、Werckerはそのデータを保存します。そのデータは、データを作成したステップの下にある"Download artifact"ボタンをクリックすると、(Tar形式で)ダウンロードできます(下図参照)。

以前は、この機能はステップが成功した場合に利用できましたが、失敗した場合にはデータ収集しませんでした。ユーザーからのリクエストに応え、この機能をアップデートし、ステップが失敗した場合にもデータ収集するようにしました。これで、ステップ中にデータをレポートディレクトリに書き込むことができるようになり、ステップが失敗した場合、簡単にそのデータにアクセスできるようになりました。これはステップで発生した問題のトラブルシューティングに非常に有用です。

この機能を利用するには、wercker.ymlでデータをそのディレクトリに配置するように設定するだけです。以下はその例です。
build:
  steps:
    # Run the test and save the output
    - script: 
      name: Run my test
      code: |
        run_test.sh > $WERCKER_REPORT_ARTIFACTS_DIR/some-output.txt
    # Take a screenshot of the application's home page
    - screenshot:
      url: https://www.myapp.com
      filename: myapp.png
ステップが完了すると、Web UIからアーティファクトをダウンロードできます。tar形式で当該ディレクトリに書き出された任意のデータを取得できます。上記の例では、some-output.txtとmyapp.pngというスクリーンショットが含まれているはずです。

[Docker, Cloud] Announcing new built-in steps for building, testing and pushing docker images in your Wercker pipelines

原文はこちら。
https://blogs.oracle.com/wercker/announcing-new-built-in-steps-for-building%2C-testing-and-pushing-docker-images-in-your-wercker-pipelines

Werckerに3つの新しい組み込みステップが追加されました。これにより、Dockerイメージの作成、テスト、イメージ・レジストリへのPushが簡単になり、全てWerckerパイプラインで可能になりました。

Dockerfileを作成してソースコードリポジトリに追加するだけでイメージをビルドできます。DockerfileはDockerイメージを作成する標準的な方法です。そのため、既存のプロジェクトをWerckerに移動する場合は、すでにDockerfileを作成済みのことでしょう。

この internal/docker-build ステップを使って、DockerfileをWerckerで直接実行できます。 単に以下の記述をwercker.ymlに追加するだけです。
- internal/docker-build:
    dockerfile: Dockerfile 
    image-name: my-new-image
Dockerイメージを作成したら、イメージを始動してテストを実行したいと思うことでしょう。そんなときは、この新しい internal/docker-build  というステップを使って新しいイメージを始動できます。
- internal/docker-run:
    image: my-new-image
image-name は後のステップでイメージを参照するために使用する一時的な名前です。

このコマンドで先ほど作成したイメージを使って新しいコンテナを起動します。パイプラインはコンテナに接続し、やりたいテストを実行できます。

作成したイメージが”Hello World”を返すWebサーバを実行すると仮定しましょう。以下はコンテナに接続し、 curl コマンドを使って期待するレスポンスが戻ることを検証するシンプルなスクリプトのステップです。
Using Wercker to build an image from a Dockerfile
https://github.com/wercker/docker-build-golang
- script: 
    name: Test the container
    code: |
        if curlOutput=`curl -s myTestContainer:5000`; then 
            if [ "$curlOutput" == "Hello World!!" ]; then
                echo "Test passed: expected response"
            else
                echo "Test failed: unexpected response" 
                exit 1
            fi   
        else 
            echo "Test failed: container did not respond"
            exit 1
        fi        
テストが成功すると、他者がそのイメージを利用できるよう、Docker HubのようなレジストリへのイメージのPushをパイプラインにさせたいと思うことでしょう。

既存の internal/docker-push ステップを拡張し、その前の internal/docker-build ステップで作成したイメージを任意のレジストリにPushできるようにしました。:
- internal/docker-push: 
    image-name: my-new-image
    username: $USERNAME # You can configure user and password     
    password: $PASSWORD # securely in wercker.com  
        repository: docker.io/$USERNAME/docker-build-golang
        tag: latest
すごく簡単ですね。
ドキュメントをご覧いただき、GitHubのサンプルをお試しください。
Building an Image
https://devcenter.wercker.com/administration/containers/building-an-image/
Using Wercker to build an image from a Dockerfile
https://github.com/wercker/docker-build-golang

[Cloud] Foundational Oracle Cloud Infrastructure IAM Policies for Managed Service Providers

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/foundational-oracle-cloud-infrastructure-iam-policies-for-managed-service-providers

このエントリでは、Oracle Cloud Infrastructureのパートナおよびマネージド・サービス・プロバイダ(MSP)が、エンド・ユーザーに代わってOracle Cloud Infrastructureサービスを管理するための基盤として利用可能なアイデンティティ・アクセス管理(IAM)ポリシーについて説明します。
Identity and Access Management
https://cloud.oracle.com/en_US/governance/identity/features
特にこのエントリでは、MSPがエンド・ユーザーのテナント全体を管理し、それぞれのコンパートメントの管理のセルフサービス化のためにさまざまなエンド・ユーザー管理者グループの資格をプロビジョニングするために活用できる、初期IAMポリシーのユースケースに焦点を当てています。

Oracle Cloud InfrastructureのIAMのベスト・プラクティスについては、以下のブログエントリと、筆者のChangbin Gongが作成したホワイト・ペーパーをご覧ください。
Best Practices for Identity and Access Management Service on Oracle Cloud Infrastructure
https://blogs.oracle.com/cloud-infrastructure/best-practices-for-identity-and-access-management-service-on-oracle-cloud-infrastructure
Best Practices for Identity and Access Management (IAM) in Oracle Cloud Infrastructure
https://cloud.oracle.com/opc/iaas/whitepapers/best-practices-for-iam-on-oci.pdf

Use Case Overview

このエントリでは以下のようなIAMのユースケースを紹介します。
  1. テナント管理者として、MSPはテナント(customer enterprise)の全てのOracle Cloud Infrastructureのアセットを管理して、MSPは(顧客の要求に沿って)コンパートメントを作成し、顧客の管理者グループから上がってくる問題のトラブルシューティングできるようにしたい。
  2. テナント管理者として、MSPは非ルート・コンパートメントの管理を対応する顧客の管理者に委譲し、顧客の管理者がそれぞれのコンパートメントのリソースに対する資格を持つようにしたい。
  3. テナント管理者として、MSPはテナント用にロール固有の資格を作成し、MSP管理者グループの責務分担を明確にしたい。具体的には、特定のロール、例えばサーバ管理者にコンピューティングに関するサービスの資格を持たせたり、ネットワーク管理者に顧客のテナントのコンパートメント間のネットワークリソースに関する資格を持たせる。
  4. 運用管理者(Operations Admin)として、OPSチームが顧客やユーザーグループの作成や管理を望んでいるが、無制限のアクセスのためにTenant Adminグループへのアクセスは避けたい。

Requirements

  • MSPは、顧客の要求に応じてテナントとコンパートメントを作成する。この例では以下の通り。
    • MSP
      • ACME_Cloud_provider(略してACP)
    • テナント
      • ACP_Tenant
    • コンパートメント
      • Root
      • ACP_Client_Prod
      • ACP_Client_Dev
  • MSP管理者グループ
    • ACP_OPS_Admin
    • ACP_Server_Admin
    • ACP_Network_Admin
  • 顧客管理者グループ
    • ACP_Prod_Admin
    • ACP_Dev_Admin
    • (必要であれば)ACP_Customer_Admin:ユーザープロビジョニングのための顧客管理者グループ
  • ポリシー
    • ACP_Tenant_Policy
    • ACP_Prod_Policy
    • ACP_Dev_Policy
    • ACP_Customer_Policy.

Steps

各ユースケースについて、必要なグループを作成し、ユーザをグループに追加し、以下の手順でOracle Cloud Infrastructureコンソールでポリシーを作成します。詳細手順のリンクは以下の通りです。
  1. グループの作成
    1. To create a group
      https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managinggroups.htm#three
  2. グループへのユーザ追加
  3. ポリシーの追加

Use Case 1

テナント管理者として、MSPはテナント(customer enterprise)の全てのOracle Cloud Infrastructureのアセットを管理して、MSPは(顧客の要求に沿って)コンパートメントを作成し、顧客の管理者グループから上がってくる問題のトラブルシューティングできるようにしたいと思っています。

Key Policy:

  • ALLOW GROUP ACP_OPS_Admin to manage all-resources IN TENANCY

注意 
このポリシーはMSP Operationsチーム用です。管理者グループと同じアクセスが必要になることがあります。

Use Case 2

テナント管理者として、MSPは非ルートコンパートメントの管理を対応する顧客の管理者に委譲して、顧客の管理者がそれぞれのコンパートメントのリソースに関する資格を有するようにしたいと思っています。このユースケース例では、MSPは顧客の本番、開発コンパートメント用のポリシーを作成します。

Key Policy(本番コンパートメント用)
  • Allow group ACP_Client_Prod to manage all-resources in compartment ACP_Client_Prod


Key Policy(開発コンパートメント用)
  • Allow group ACP_Client_Dev to manage all-resources in compartment ACP_Client_Dev


Use Case 3

テナント管理者として、MSPはテナントのロール固有の資格を作成することを望んでいます。そのため、例えばコンピューティング関連サービスの資格を持つサーバー管理者、顧客のテナント内のコンパートメント間のネットワークリソースに関する資格を持つネットワーク管理者、というように、MSP管理者グループは明確に責務を分離します。

Key Policies(ネットワーク管理者用)

  • Allow group ACP_Network_Admin to manage virtual-network-family in tenancy
  • Allow group ACP_Network_Admin to manage load-balancers in tenancy
  • Allow group ACP_Network_Admin to read instances in tenancy
  • Allow group ACP_Network_Admin to read audit-events in tenancy

Key Policies(サーバ管理者用)

  • Allow group ACP_Server_Admin to manage instance-family in tenancy
  • Allow group ACP_Server_Admin to manage volume-family in tenancy
  • Allow group ACP_Server_Admin to use virtual-network-family in tenancy
  • Allow group ACP_Server_Admin to read instances in tenancy
  • Allow group ACP_Server_Admin to read audit-events in tenancy

Key Policies(セキュリティ管理者用)

  • Allow group ACP_Security_Admin to read instances in tenancy
  • Allow group ACP_Security_Admin to read audit-events in tenancy

Key Policies(データベース管理者用)

  • Allow group ACP_DB_Admin to manage database-family in compartment Prod
  • Allow group ACP_DB_Admin to manage database-family in compartment Dev
  • Allow group ACP_DB_Admin to read instances in tenancy

Use Case 4

運用管理者(Operations Admin)として、OPSチームが顧客やユーザーグループの作成や管理を望んでいますが、無制限のアクセスのためにTenant Adminグループへのアクセスは避けたいと考えています。

Key Policies

  • Allow group ACP_OPS_Admin to use users in tenancy where target.group.name != 'Administrators'
  • Allow group ACP_OPS_Admin to use groups in tenancy where target.group.name != 'Administrators'
注意
IAM動詞は、次のようにより詳細なものからより粗いもの、またはより限定的なものからより限定的でないもの、といった順序に並びます。

今後も、マネージド・サービス・プロバイダ向けのOracle Cloud Infrastructure IAMポリシーを取り上げるブログとホワイト・ペーパーを追加していく予定です。

IAMの詳細情報はドキュメントをご覧ください。
Overview of IAM
https://docs.cloud.oracle.com/iaas/Content/Identity/Concepts/overview.htm?TocPath=Services|IAM|_____0

[WLS, Docker] Make WebLogic Domain Provisioning and Deployment Easy!

原文はこちら。
https://blogs.oracle.com/weblogicserver/make-weblogic-domain-provisioning-and-deployment-easy

Oracle WebLogic Deploy Tooling(WDT)を使うと、WebLogic Serverドメインのプロビジョニングとアプリケーションのデプロイ自動化が容易になります。WDTでは、メンテナンスが必要なWLSTスクリプトを作成するのではなく、ドメインやアプリケーション、そしてアプリケーションが使用するリソースを記述する宣言的なメタデータモデルを作成します。このメタデータモデルを使って、プロビジョニング、デプロイメント、およびドメインライフサイクル操作の実行を繰り返し実行することができ、アプリケーションのContinuous Deliveryに最適です。
Oracle WebLogic Server Deploy Tooling
https://github.com/oracle/weblogic-deploy-tooling
WDTは10.3.6から12.2.1.3までの幅広いWebLogic ServerのバージョンならびにWindowsとUNIXの両方のOSをサポートするという柔軟性を有しており、次の利点があります。
  • WebLogicドメインを観察してメタデータモデル(JSONまたはYAML)に抽出する
  • 新規WebLogic Serverドメインをメタデータモデルを使って作成、ドメイン構成のバージョン管理が可能
  • 既存のWebLogic Serverドメインの構成を更新し、アプリケーションやリソースをドメインに展開
  • ランタイムへの変更を実施する前に、メタデータモデル(モデルとも呼ばれる)へのランタイム変更が可能
  • 別のプロパティファイルで値を提供できるようプレースホルダを設定でき、同じモデルを複数の環境に適用可能
  • モデルやプロパティファイルで直接パスワードを暗号化可能
  • スパースモデル(疎性モデル)をサポート、他のアーティファクトを記述しなくてもモデルは特定の操作に必要なものを記述するだけでよい
  • モデルの内容を簡単に検証し、関連する成果物がフォーマット上問題ないことを検証
  • 自動化とデプロイのContinuous Deliveryが可能
  • DockerイメージやKubernetesのような環境へのドメインのLift & Shiftを容易に


現在、このプロジェクトでは5個の専用ツールを提供しており、全てシェルスクリプトとして公開しています。
  • Create Domain Tool(ドメイン作成ツール、createDomain)ドメインの作成方法と、モデルに指定されているすべてのリソースとアプリケーションをドメインに移入する
  • Update Domain Tool(ドメイン更新ツール、updateDomain)
    既存のドメインを更新し、モデルに指定されているすべてのリソースとアプリケーションをオフラインモードまたはオンラインモードでドメインに移入する
  • Deploy Applications Tool(アプリケーション展開ツール、deployApps)オフラインまたはオンラインモードのいずれかで、既存ドメインにリソースとアプリケーションを追加する
  • Discover Domain Tool(ドメイン探索ツール、discoverDomain)既存のドメインを観察し、ドメインとそのドメインにデプロイされたバイナリのアーカイブファイルを記述したモデルファイルを作成する
  • Encrypt Model Tool(モデル暗号化ツール、encryptModel)ユーザーが入力したパスフレーズを使用して、モデル(またはその変数ファイル)のパスワードを暗号化する
  • Validate Model Tool(モデル検証ツール、validateModel)モデル作成や編集に役立つよう、モデルのスタンドアロン検証とモデル使用情報を提供
WebLogic on Docker and Kubernetesプロジェクトでは、WDTを利用してWebLogicドメインをプロビジョニングし、DockerイメージまたはKubernetes永続ボリューム(PV)内にアプリケーションをデプロイします。Discover Domain ToolとCreate Domain Toolのおかげで、Docker/Kubernetes以外の環境で動作するドメインを、これらの環境にLift & Shiftできます。 Docker/Kubernetes環境では特定のWebLogic構成(ネットワークなど)が必要ですが、Validate Model Toolは、WebLogicの構成を検証し、これらの環境で実行できるようにするためのしくみを提供します。

Dockerイメージ内にWebLogic Server 12.2.1.3のドメインをプロビジョニングする方法を説明するために、GitHub WebLogic Dockerプロジェクトでサンプルを作成しました。
Example Image with a WLS Domain
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/12213-domain-wdt
WebLogicドメインは、WebLogic動的クラスタ、1個のシンプルなアプリケーションがデプロイ済みで、コンテナ内で実行されるOracle Databaseに接続するデータソースで構成されます。このサンプルには、基本的なWDTモデルのsimple-topology.yamlが含まれており、このモデルにはDockerイメージ内のドメイン構成が記述されています。GitHubのWDTプロジェクトのREADMEファイルに記載の形式と規則に従って、WDTモデルをテキストエディタで作成および変更できます。また、WDTのDiscover Domain Toolを使用して既存のWebLogicドメインからモデルを作成することもできます。
Oracle WebLogic Server Deploy Tooling README
https://github.com/oracle/weblogic-deploy-tooling/blob/master/README.md
ドメイン作成には、アプリケーションとライブラリのデプロイメントが必要になることがありますが、これは、特定の構造を持つZIPアーカイブを作成し、モデル内でそれらのアイテムを参照することによって実現できます。このサンプルでは、小さなアプリケーションWARを含むシンプルなZIPアーカイブを作成してデプロイします。アーカイブは、Dockerイメージを作成する前にサンプルディレクトリに作成されています。


How to Build and Run

イメージはdocker-imagesリポジトリのWebLogic Server 12.2.1.3イメージをベースにしています。以下のREADMEに従って、ローカルリポジトリにWebLogic Serverインストールイメージをビルドします。
Oracle WebLogic Server on Docker
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/12.2.1.3
(訳注)
Dockerfile(https://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/<WLSのバージョン>のDockerfile.developerもしくはDockerfile.generic)の30行目でPullしているServer JREイメージを変更しないとうまく動作しない場合があります。
Docker Storeの場合
oracle/serverjre:8  --> store/oracle/serverjre:8
Oracle Container Registryの場合
oracle/serverjre:8  --> container-registry.oracle.com/java/serverjre:8
WDTインストーラを使って、このサンプルのWebLogicドメインイメージをビルドします。

このサンプルでは、Zipアーカイブ(archive.zip)に含まれているシンプルな1ページのWebアプリケーションをデプロイします。このアーカイブを、ドメインのDockerイメージを構築する前に作成する必要があります。
$ ./build-archive.sh
ドメインイメージを作成する前に、WDTモデル(simple-topology.yaml)も必要です。 このWebLogicドメインサンプルをカスタマイズする場合は、エディタでモデル(simple-topology.yaml)を変更するか、WDT Discover Domain Toolを使用して既存のWebLogicドメインから構成を取得できます。

以下のイメージは、サンプルのWDTモデル(simple-topology.yaml)のスニペットです。ここで、データベースパスワードが暗号化され、WebLogicドメインコンテナ実行前に,提供されるプロパティファイルの値で置換されます。



このサンプルをビルドするには以下のコマンドを実行します。
$ docker build \
    --build-arg WDT_MODEL=simple-topology.yaml \
    --build-arg WDT_ARCHIVE=archive.zip \
    --force-rm=true \
    -t 12213-domain-wdt .
ローカルリポジトリにWebLogicドメインができあがっているはずです。


How to Run

このサンプルでは、WebLogicドメインの各管理対象サーバにデータソースがデプロイされています。コンテナ内で実行されているOracle Databaseにデータソースを接続する必要があるため、Oracle DatabaseイメージをDocker StoreもしくはOracle Container RegistryからローカルリポジトリにPullします。
$ docker pull container-registry.oracle.com/database/enterprise:12.2.0.1
WebLogic ServerとOracle Databaseのコンテナが動作するよう、Dockerネットワークを作成します。
$ docker network create -d bridge SampleNET

Run the Database Container

データベースコンテナを作成するには、以下の環境ファイルを使用して、データベース名、ドメイン、および機能バンドルを設定します。以下は環境ファイル(properties/env.txt)の例です。
DB_SID=InfraDB
DB_PDB=InfraPDB1
DB_DOMAIN=us.oracle.com
DB_BUNDLE=basic
以下のDockerコマンドを実行してデータベースコンテナを実行します。
$ docker run -d --name InfraDB --network=SampleNET  \
    -p 1521:1521 -p 5500:5500  \
    --env-file /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties/env.txt  \
    -it --shm-size="8g"  \
    container-registry.oracle.com/database/enterprise:12.2.0.1
データベースが問題なく動作していることを確認します。docker psコマンドの出力にあるSTATUSフィールドに(healthy)と表示されていればOKです。



データベースはデフォルトのパスワード(Oradoc_db1)で作成していますが、パスワードを変更するには、SQL*Plusを使う必要があります。SQL*Plusを実行するには、Oracle Instance ClientをOracle Container RegistryもしくはDocker StoreからPullし、以下のコマンドを使ってsqlplusコンテナを実行します。
$ docker run -ti --network=SampleNET --rm \
    store/oracle/database-instantclient:12.2.0.1 \
    sqlplus sys/Oradoc_db1@InfraDB:1521/InfraDB.us.oracle.com AS SYSDBA

SQL> alter user system identified by dbpasswd container=all;
新たなデータベースパスワード(dbpasswd)をプロパティファイル(properties/domain.properties)のDB_PASSWORDに追加して、データベースに接続できることを確認してください。
$ docker exec -ti InfraDB  \
    /u01/app/oracle/product/12.2.0/dbhome_1/bin/sqlplus \
    system/dbpasswd@InfraDB:1521/InfraPDB1.us.oracle.com

SQL> select * from Dual;

Run the WebLogic Domain

domain.properties (properties/domain.properties)ファイルを編集し、データベースのパスワードを含む、WebLogicドメイン実行に必要な全てのパラメータを設定する必要があります。



コンテナ化された管理サーバを開始するには、以下のコマンドを実行します。
$ docker run -d --name wlsadmin --hostname wlsadmin \
    --network=SampleNET -p 7001:7001 \
    -v /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties:/u01/oracle/properties  \
    12213-domain-wdt
コンテナ化された管理対象サーバ(ms-1)を起動して上記の管理サーバに自動登録する場合、以下のコマンドを実行します。
$ docker run -d --name ms-1 --link wlsadmin:wlsadmin \
    --network=SampleNET -p 9001:9001 \
    -v /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties:/u01/oracle/properties  \
    -e MS_NAME=ms-1 12213-domain-wdt startManagedServer.sh
追加の管理対象サーバ(この例ではms-2)を起動する場合、以下のコマンドを実行します。
$ docker run -d --name ms-2 --link wlsadmin:wlsadmin  \
    --network=SampleNET -p 9002:9001 \
    -v /Users/mriccell/Docker/docker-images/OracleWebLogic/samples/12213-domain-wdt/properties:/u01/oracle/properties  \
    -e MS_NAME=ms-2 12213-domain-wdt startManagedServer.sh
上記のシナリオでは、単一のホスト環境に動的クラスタを設定したWebLogicドメインを作成します。サーバーが実行中で、データソースがコンテナ内で実行されているOracle Databaseに接続していることを確認しましょう。ブラウザでhttp://localhost:7001/console にアクセスしてWebLogic Server管理コンソールを起動します。このとき、domain.propertiesファイルで指定した資格情報を使用してログインします。



WebLogic Deploy Toolingを使うと、WebLogicドメインのプロビジョニング、アプリケーションやアプリケーションに必要なリソースのデプロイが簡単になります。WebLogic on Docker/Kubernetesプロジェクトでは、これらのツールを利用して、イメージ内のドメインのプロビジョニングを簡素化したり、Kubernetes永続ボリュームに永続化したりしています。 我々は、KubernetesでのWebLogicドメインの管理を簡素化するWebLogic Kubernetes Operatorの一般提供しましたが、WebLogicドメインの管理機能を強化したWebLogic Kubernetes Operator ver 2.0をまもなくリリースする予定です。幅広い場所でこれらのドメインが動作可能になるよう、WebLogicドメインのプロビジョニング、デプロイ、および管理を容易にするためのツールを引き続き提供していきます。このサンプルが、WebLogic Deploy Toolingを使ってWebLogic Serverドメインのプロビジョニングとデプロイメントを行いたい全ての方々にお役に立つことを願っています。皆さんのご意見をお待ちしております。

[Cloud] Introducing Fault Domains for Virtual Machine and Bare Metal Instances

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/introducing-fault-domains-for-virtual-machine-and-bare-metal-instances

アベイラビリティ・ドメイン内のOracle Cloud Infrastructure仮想マシンおよびベアメタルコンピューティング・インスタンスの可用性の管理と向上のための新しい方法である障害ドメイン(fault domains)が導入されました。

現在、アベイラビリティ・ドメインを使用して、仮想マシン(VM)やベアメタル・インスタンスを単一のリージョン内の複数のアベイラビリティ・ドメインドメインに分散することにより、アプリケーションの高可用性を保証しています。アベイラビリティ・ドメインは物理的に分離されており、リソース(電力、冷却装置、ネットワーク)を共有していないため、リージョン内の複数のアベイラビリティ・ドメインが障害を起こすことはほとんどありません。複数のアベイラビリティ・ドメインを使用することで高可用性が保証されるのは、いずれかのアベイラビリティ・ドメインの障害が他のアベイラビリティ・ドメインで実行されているリソースに影響を与えないためです。

単一のアベイラビリティ・ドメイン内でアプリケーションの可用性をより細かく制御したい場合に、障害ドメインを使用して可用性を達成できるようになりました。障害ドメインを使用すると、単一のアベイラビリティ・ドメイン内の異なる物理ハードウェア上にコンピューティング・インスタンスを分散できます。これにより、別のフォールトトレランス(耐障害)レイヤーが導入されます。障害ドメインは、予期しないハードウェアの障害やベースのコンピュータ・ハードウェアのメンテナンスによるアプリケーションの停止を防ぐことができます。さらに、障害ドメイン内ですべてのシェイプのインスタンスを起動できます。

Oracle Cloud Infrastructureは、通常、リージョンごとに3個のアベイラビリティ・ドメインが設計されており、各アベイラビリティ・ドメインには3個の障害ドメインがあります。ベースのコンピュータ・ハードウェアのメンテナンスを実行する場合、Oracle Cloud Infrastructureでは、残りの障害ドメインでのインスタンスの可用性を保証するため、あるタイミングで影響を受けるのは1個の障害ドメインのみです。

簡単に使い始めることができます。API、CLI、またはコンソールで新しいコンピューティングインスタンスを作成すると、インスタンスを配置する障害ドメインを指定できます。障害ドメインを指定しない場合、インスタンスはそのアベイラビリティ・ドメイン内の3個の障害ドメインのどれか1個に自動的に配置されます。インスタンス作成後に障害ドメインを変更するには、そのインスタンスを終了して再作成する必要があります。すべての既存のVMインスタンスとベアメタルインスタンスは、アベイラビリティ・ドメイン内の3つの障害ドメイン間に自動的に分散されています。

インスタンスの詳細ページを見ると、障害ドメインの情報がインスタンスの別のメタデータと共に表示されていることがわかります。

Oracle Cloud Infrastructureで障害ドメインを開始するには、以下のページへどうぞ。
Oracle Cloud
https://cloud.oracle.com/ja_JP/home
障害ドメインは、すべてのパブリック・リージョンで利用でき、追加費用は不要です。詳細は以下のリソースをご覧ください。
Oracle Cloud Infrastructure Getting Start Guide
https://docs.us-phoenix-1.oraclecloud.com/Content/GSG/Concepts/baremetalintro.htm
Cloud Computing Service - Oracle Cloud Infrastructure
https://cloud.oracle.com/ja_JP/compute
Cloud Computing FAQs - Oracle Cloud Infrastructure
https://cloud.oracle.com/compute/faq
Fault Domains
https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm#fault