Google Cloud 認定資格の試験を遠隔監視オンラインで受けてみた

Google Cloud Platform(以下GCP)には、GCPを用いた職務遂行能力を評価し認定する資格があります。
資格を取得するには、規定の試験を受け、合格する必要があり、試験は、オンサイト試験または遠隔監視オンライン試験いずれかを選択できます。
オンサイト試験は、テストセンターに行き、私物等をロッカーに入れた上で隔離環境のPCから受講しますが、 遠隔監視オンライン試験は自宅やオフィスなど任意の場所で受講可能な一方、 テストセンターと同程度の環境で受験していること を要件にし、カメラなどで常に監視されています。
この要件から、オンサイト試験でテストセンター*1で実施する方が面倒は少ないのですが、昨今の状況を鑑みて、人と物理的に接触することのない遠隔監視オンライン試験を受講しました。

受験した資格

Google Cloud Certified - Professional Data Engineer (Japanese)

cloud.google.com

私の受験環境

  • 居住環境
    • 大通りから一本奥まった低層マンション(1K)
    • 一人暮らし
    • 騒音が聞こえてくることは通常ない。
    • PCはリビングに設置。 技術書などを詰めた大型本棚も同じ部屋にあり、カメラに映る位置。
  • PC
    • 私物Mac Miniにモニタ接続
    • カメラ: logicoolの安物をモニタ上部に取り付け
    • マイク: USB接続
    • ネット接続: 無線(上り下り200Mbps以上)
    • ブラウザはFirefox。 プライベートモードにしなくても良かった。
    • HHKBとMagic Trackpad2

受験前の準備と当日の流れ

前日まで

  • 受験ガイドExam Procedures を参考にチェック
  • 「Sentinel」という監視ツールをインストール
  • 「生体認証プロファイル」を取得(カメラで顔を映す)

当日

  • 試験開始15分前
    • 常駐させている各種アプリを終了。(Docker, Krisp, Google driveなどなど…。)
    • デスクからキーボードとポインティングデバイス以外をすべて撤去する。 撤去したものは視界に映らないようにした。
    • 本人確認のためのパスポートを準備
  • 試験開始10分前~試験開始まで
    • webassessorに受講開始のボタンが出現するのでクリック
    • Sentinelが全画面ウィンドウで起動する
    • 注意事項などが表示されるのでAccept, 受験環境についての確認が入るのでそれぞれチェック
    • 試験官とのテキストチャットが開始され、カメラとスマホを使ってもろもろ確認。
      • 本人確認
      • デスクと部屋をカメラで全体的に撮影
      • モニターとPCが接続されているケーブルを撮影
      • 撮影につかったスマホをデスクから遠ざけたことを撮影
    • この間、やりとりはテキストチャットのみ
  • 試験開始

トラブルや戸惑ったこと

  • 試験開始前のカメラ撮影で試験官のリアクションが少なく、撮し方が合ってるのかどうなのかわからなかったので、こちらから「いかがでしょうか」「以上です」などのメッセージを送ったりしてました。*2
  • 試験開始直後、問題文を小声でブツブツ読み上げていたところ、監視の要件に引っかかった?のか試験が中断した。 警告の文言を読んで理由がわかったのでOK押して再開した。
  • 試験が終わりSentinelのウィンドウが閉じたのでブラウザに戻ると「トラブルが発生したので~~」のような文言が表示されwebassessorからログアウトされていた。 すわ試験無効か!?と焦ったが、再ログインして結果を確認したら合格となっており、got kotonaki。

まとめ

GCPの遠隔監視オンライン試験についての体験レポートは以上です。 今回のケースではさほどトラブルもなく順調に進みましたが、普段テレビ会議のセッティングになれていない場合は事前準備をすることをオススメします。 コロナ禍においては外出せずに試験を受けられる仕組みは大変有用なので、今後(なんならコロナ禍が収まってから)も積極的に利用したいです。

*1:テストセンターは八重洲秋葉原など都心部にあることが多いです。

*2:試験官のメッセージはおそらく定型文

見知らぬGCPプロジェクトの利用状況を把握する方法あれこれ

前書き

管理者不在のGCPプロジェクトを渡され、何してるのかを調べて欲しいというタスクを振られたかわいそうな人向けにトリビアルなノウハウを共有します。

TL;DR

  1. Asset Inventoryでリソースの総量を把握する。
  2. 稼働状況をモニタリング、ログ、Billingなどから把握する。
  3. リソース同士の関連をIAMから探る。
  4. 引き継ぎはちゃんとやれ。たのむ。

前提

  • 読者は対象GCPプロジェクトへの少なくとも参照権限を持っている *1
  • 実際になにかを動かして検証することは現時点では許可されていない
  • GCPプロジェクトに関する有識者は不明

本文

本記事では、GCPが提供するコンソールをさっと眺めるだけである程度のざっくりとした構成を概観し、より詳細な調査をするための足がかりを得るノウハウを共有します。 各リソースの詳細までは踏み込みません。

利用するツール

この記事で触れるツールは以下です。 順番に説明しますが、実際はこれらのツールを相互に行き来しながら関連を探ることになります。

  1. Asset Inventory
  2. Cloud Monitoring
  3. Cloud Logging
  4. APIs & Services
  5. IAM

Cloud Asset Inventory

Cloud Asset Inventoryは、GCPプロジェクト内のリソースのメタデータ保有し、一覧化や検索が可能なサービスです。 利用は無料です。

cloud.google.com

Cloud Asset Inventoryを用いることで、どんなリソース(VM, GCS, BigQuery, VPN…)が作成されているのか、それらがどのlocationにあるのかを把握することができます。

Cloud Asset Inventoryは「IAM & Admin」配下から使用でき、以下のように、どのリソースがいくつ作成されているかを一覧できます。

f:id:usadamasa:20210726195437p:plain

上の画像では、少なくともGAEのサービスが1つ、BigQueryのデータセットが2つ、VPNが1つとサブネットが多数あるといったことが伺い知れます。

コンソールからCSVダウンロードも可能です。

f:id:usadamasa:20210726194657p:plain

注意点としては、Cloud Asset Inventoryはあくまでリソースがあるかないかの静的な状況で、「実際に使われているかどうか」は判別できません。 「実際に使われているかどうか」は別のツールが必要になります。

Cloud Monitoring, Cloud Logging, APIs & Services

「実際に使われているかどうか」を把握するためのツールとしてはMonitoringとLogging*2とAPIs & Servicesがあります。 これらはGCPのリソースの利用状況と、なにかしらのイベントが起きていることを詳細に把握できるツールです。

Cloud Monitoring

ここでも「Resource dashboards」という形でリソースの有無が把握できます。

f:id:usadamasa:20210726200016p:plain

Cloud Monitoringは代表的なプロダクトについてはGCPが予め作成したダッシュボードがあり、稼働しているプロダクトが表示されます。 また、気の利いた前任者であれば、カスタムダッシュボードとしてそのプロジェクトで把握したいメトリクスをまとめたダッシュボードを発見できるかもしれません。*3

Cloud Logging

CloudLoggingは、各コンポーネントが出力したログエントリが集約されていて、なんのプロダクトが活発に動いているかが把握できます。 画面上の「PageLayout」から「Log Field」および「Histogram」をペインに表示しておくことで、どのリソースが直近どのような時系列と頻度で動いているかを知ることができます。

f:id:usadamasa:20210726200405p:plain

APIs & Services

GCPはリソースの各種操作をAPIを利用して行っており、「APIs & Services」はそのAPIの利用状況がわかるダッシュボードです。

cloud.google.com

このダッシュボードを参照することで、ヘビーに呼び出されているAPIはなにか、そのプロダクトはなにかを把握し、ワークロードの傾向をつかむことができます。

IAM

IAMを参照することで、どのアイデンティティ*4が何の権限を持っているかを把握することができます。

cloud.google.com

前任者がキチンと設計したかどうかで、IAMが細かく作成されているか、おおざっぱになっているか、あるいはデフォルトサービスアカウント*5一本槍かは異なります。

付与されている権限だけでなく、Recommenderという機能により、付与された権限のうち、実際には使われていない権限を把握することができます。 裏を返せば、実際に使われている権限も確認できます。 f:id:usadamasa:20210726202426p:plain

cloud.google.com

これらの情報から、以下が把握できます。

  • あるユーザが何の権限を持っていて、いまもなおその権限を使ってなんらかのタスクを実行している。*6
  • あるサービスアカウントが付与された権限を用いて、GCPの何らかの機能を実行している。*7

クロスプロジェクトの権限付与

GCPは、プロジェクトをまたいだ権限付与が容易に可能な方式です。 異なるプロジェクトに属するサービスアカウントから、調査しているプロジェクトに対する権限*8はコンソールから容易に把握できますが、一方でそのプロジェクトのアカウントが他のプロジェクトへの権限を持っている*9ことを知ることは事前の知識がなければ困難です。 後者の権限はBigQueryのDWH/マートなどを集約したプロジェクトを参照する方式で頻発するため、DWH/マートを保有するプロジェクト側での統制が重要となります。

サービスアカウントキーが発行されている場合

GCPは、サービスアカウントキーのjsonを発行することで、GCPサービス外からGCPの機能を利用することができます。

cloud.google.com

調査の過程で、このサービスアカウントキーが発行されていることが発覚した場合は、構成の把握の難易度が格段に上がることを覚悟してください。 サービスアカウントキーは一般に、GCP外のオンプレミスシステム、SaaSAWSなどのパブリッククラウドで使われ、事前の知識がなければどこで利用されていることを把握することは困難です。

cloud.google.com

「少なくともまだ利用されているかどうか」は、使用状況のモニタリングから観測することができます。*10

cloud.google.com

まとめ

  1. GCPコンソールだけでも結構わかることはある。
  2. Cloud Asset Inventoryはここしばらく開発が活発なようなので要チェキ。
  3. いくら頑張っても知識が無い状態から要件定義、基本設計を導き出すことは基本的に不可能なので有識者を探すこと。*11

*1:roles/Viewer があればなんとかなります。

*2:ちょっと前までStackdriverと呼ばれていたもの

*3:期待しない方がいい

*4:ユーザアカウント、サービスアカウント、グループなど

*5:公式リファレンスではデフォルトサービスアカウントはプロダクションでは利用しないことを推奨しています。 https://cloud.google.com/iam/docs/service-accounts?hl=ja#default

*6:そのユーザとコンタクトを取り、ヒアリングすることで一気に道が開ける可能性はある。

*7:そのサービスアカウントがアタッチされているコンポーネントを簡単に知る方法はまだわかってない

*8:インバウンドって言えばいいのか?

*9:アウトバウンド?

*10:ロギングに接続元IPも出た気がする

*11:本当に運用に必要なドキュメントが何なのかを考える 近藤 誠司. 運用改善の教科書 ~クラウド時代にも困らない、変化に迅速に対応するためのシステム運用ノウハウ (Japanese Edition) (Kindle の位置No.837). Kindle 版.

argocdでSSOしたいときにclientSecretをSealedSecretで保持したい

忘れないうちに概要だけでもメモする。

Motivation

argocdでSSOするときにSSO先のcredential情報を平文でリポジトリにcommitしたくない。

解決方法

argocdのconfigmapからSecretを参照する機能を用い、 さらに参照先のSecretはSealedSecretで管理する。

段取り

  • argocdをシュッと立ち上げる。
  • argocd-secret から server.secretkey を採取する(A)。
  • 使いたいSSOの clientSecret からSecretを生成する(B)。
  • (A)と(B)をマージしたSecretからSealedSecretを生成する。
    • このとき、複合されるSecretの名前が argocd-secret となるように記述する。
  • argocdに元からある argocd-secret にpatchを当て、 sealedsecrets.bitnami.com/managed: "true" のannotationを付与する。
  • argocd-cmclientSecret の値の先頭に $ をつけて、Secretの値を参照できるようにする。
  • applyする。

ハマりポイント

sealedsecrets.bitnami.com/managed: "true" で勝つると思いきや生成タイミングの問題か server.secretkey が消えてしまい、 Unable to load data: server.secretkey is missing と怒られる。

Appendix

argocdのconfigmapからsecretsを参照する機能
https://github.com/argoproj/argo-cd/blob/6d44c4de413c2a5bbc6faf027a86d54a3e2ac8d0/docs/operator-manual/user-management/index.md#2-configure-argo-cd-for-sso

デフォルトで生成される server.secretkey について
https://github.com/argoproj/argo-cd/blob/v1.6.1/docs/operator-manual/argocd-secret.yaml#L21-L23

既存のSecretsを上書きしてSealedSecretでマネージする
github.com

分散型データメッシュ Distributed Data Mesh についての記事を列挙するだけ

martinfowlerのブログで去年の5月に投稿された原記事

martinfowler.com

↑について言及したInfoQの日本語訳

https://www.infoq.com/jp/news/2020/03/distributed-data-mesh/

反応記事

https://towardsdatascience.com/data-mesh-not-a-service-mesh-1a4a315193b3

原記事著者の講演動画

www.youtube.com

併せて読みたい

データ統合*1とデータ連係の対比。*2

https://www.altoros.com/blog/data-federation-vs-data-integration/

リボンモデルの意義

yuzutas0.hatenablog.com

プラットフォーム間のディスカバリ

www.odpi.org

*1:原記事とはfederationのニュアンスが逆な気がする。

*2:2008年の記事ってまじか

個人情報保護の手段としてのリネージ

TL;DR

  • データガバナンスにおいてリネージが大事だよ。
  • Apache AtlasというOSSでリネージができるよ。
  • このへん情報が少ないのでもっと知りたいよ。

ここから本編

データ分析をするにあたり、そのデータがどこから来たものなのか、監査をするにあたり、不適切なデータの利用がされていないのか、知りたい人は多いと思います。 とりわけ、上記のような動機をもってる人が所属する組織は、多数の部門に分かれ、それぞれの部門で採用している技術スタック、ミドルウェアが異なったりします。

  • データの由来を知るにも担当者はそもそも誰なのか、どこの誰に聞けばわかるかがわからない。
  • データ基盤を運用してるがあるデータセットの変更がどこにどう影響を与えるのかわからない。
  • 個人情報開示請求をユーザから受けたけど、いったいどこにどうデータが伝わっているのかわからない。

そういった辛みを解決するための手法として、データリネージというものがあります。

メタデータとリネージ

しんゆうさんゆずたそさんの活動により、メタデータ管理、データマネジメントの重要性( メタデータ整備 )については徐々に認知されていると思います。 しかしながら、単独のデータセットについてではなく、複数のデータセットを束ね、関連付けて整理する活動についてはいまだ言及が少ないように思えます。

データリネージは、メタデータのうちの一領域で、情報の履歴・ライフサイクルをトラッキングすることです。 トラッキングする要素は、データの入出力、処理を行うプロセス、データセット間でなにが伝わったかなどです。

個人情報保護のためのリネージ

データ分析基盤を持ち運用している組織であれば、複数のサービスそれぞれのデータセットに管理者が存在し、個人情報の漏洩や目的外利用を監督していると思います。 *1
分析基盤への流れが単純であれば、それぞれのサービス内容やデータセットの内容、また分析施策の内容を把握し、現実的なコストでリスクを抑えることができます。

f:id:usadamasa:20200522215835p:plain
データ分析基盤への流れ_1

しかしながら、複数のデータ分析基盤があり、かつ連携がある場合、後続の分析基盤がそれぞれのデータセットの来歴を把握するコミュニケーションコストは指数関数的に増大します。

f:id:usadamasa:20200522220719p:plain
データ分析基盤への流れ_2

稼働当初は分析基盤βが適切に管理していたとしましょう。
しかしある日から分析基盤αへ、サービスCと一緒に扱ってはいけない、サービスXのデータが含まれてしまったとします。
分析基盤βの管理者はそれを把握することができるでしょうか?
分析基盤βと分析基盤αの間で綿密な情報共有が行われていればαのほうからβへ連絡することで気付くことができるかもしれませんが、間に挟まるステークホルダーが増えるにつれて難しくなるでしょう。

またデータ分析者があるデータセットを施策に使いたいと思ったとき、プライバシーポリシーとして問題ないかチェックするプロセスを取る組織もあると思いますが、この5営業日かかります、となるとデータ分析のプロセスは滞り、機会費用が発生します。

このリードタイムを忌避しチェックを怠れば、よくて施策が世に出る直前でストップ・すべて台無しになるか、大体がサービスそのものが炎上し事業の継続性が損なわれます。

データガバナンスツールApache Atlas

前置きが長くなりましたが、上記のような課題を避け、データの流れを可視化するツールとして、Apache AtlasというOSSがあります。

atlas.apache.org

Apache Atlasは2015年にApache Incubator入りし、2017年に昇格しました。現在のリリースバージョンは2.0で、現在3.0の開発が進められています。*2 主なコミッターはHadoopなどを開発するHortonworksのようです。
また、clouderaがソリューションとして提供しているようです。*3

IBMの研究者は、メタデータ管理のOSSとして "Apache Atlas is the lead contender as the choice of such an open source project." と言及しています。*4

概要

Apache AtlasはREST APIとWebUI、そして主にHadoop関連のプロダクトをサポートするメタデータのコレクタで構成されます。
しかし、柔軟なスキーマ定義が可能なため、Hadoopに限らず、Oracle、Bigqueryなどの表形式構造化データはもちろん、s3、gcsなどの非構造化データを含めあらゆるデータセットを扱うことができます。 *5

リネージとClassification Propagation

Apache AtlasはメタデータDataSetProcessの2つに大きく区別します。 DataSetはあらゆるデータを含む抽象的な概念。Processは、DetaSetとDataSetをつなぐ概念と捉えられます。

下の画像は、Apache Atlasのオフィシャルサイトから拝借したもので、緑の丸、赤の丸がDataSet、青の歯車の丸がProcessを示しています。 左のデータを出発とし、一度テーブルにロードした後、さらにViewによって複数のデータセットに分割しています。

f:id:usadamasa:20200522223219p:plain
リネージ

これだけでは特に面白くもないと思いますが、Apache Atlasの特徴的な機能としてClassification Propagation(分類の伝播)があります。
下図のように、一番最初のデータに、PII(個人を識別できる情報)というClassificationを付与すると、Processを介して後続のテーブルにまでそのClassificationが伝播し、最後のDataSetに対しても、そのDataSetにはPIIが含まれているという情報を付与することができます。

f:id:usadamasa:20200522224115p:plain
classification

このClassificationは様々な値を定義することが可能で、複数のDataSetを入力とするDataSetについて、入力のDataSetそれぞれに別々のClassificationを付与した場合、出力のDataSetには両者のClassificationが付与されることとなります。

この機能によりデータ分析基盤においての個人情報の目的外利用が可視化できると期待しています。

データの収集について

Apache AtlasはREST APIを提供しており、任意の方法でデータを収集することができます。 atlas.apache.org しかしながら、データソースにアクセスしメタデータを採取する具体的な実装は提供されていません。

この部分に関しては、開発が必要です。 たとえば@k1Lowさんの開発する tblsの出力データを利用することや、他のメタデータ管理ツールで収集したデータをAPIで連携するなどが考えられます。

github.com

www.yasuhisay.info

Apache Atlasの活用事例

Apache Atlasは、誤解を恐れずに言えば、メタデータ管理について低レイヤな基盤となる機能を提供しており、実際に組織で運用するには様々な工夫が必要と考えています。 Apache Atlasをバックエンドとして、WebUIや周辺機能を実装したOSSを提供している事例として、 lyftが開発するamundsenや、ODPiが開発するegeriaがあります。

まとめ

煩雑な文になってしまいましたが、データ整備、データガバナンスについては昨今議論が活発になってきたところです。
具体的な実装方法についても情報共有できていけたらと思います。

Appendix

メタデータ管理OSS個人的まとめ

いろいろ触ったのでまとめる。(今後追記予定あり)

TL;DR

データガバナンスツールのOSSにおいて、世間的にデファクトスタンダード的なものも、個人的にこれは!というものも見た限りなかった。 テクニカルメタデータの収集はだいたいどこも同じな一方、ビジネスメタデータ、リネージへの取り組みには顕著な差がある。 お金があるなら有償製品を導入したほうがいいかもしれない。 1 データガバナンスツールは、JIRAみたいなビジネスツールとして捉えるべきという所感。

変更履歴

  • 2020-05-18
    • Egeriaを追加

前提と関心のある領域

  • ベンチャーではなく様々な領域の事業を扱う大きめの企業。
  • マルチクラウド、マルチベンダー、マルチプラットフォーム。データストアは数百以上。
  • ETL基盤、データ分析基盤はすでに存在し、内製のメタデータ管理ツールもある。
  • データ利活用よりもガバナンスを強化したい。

調べたOSS一覧と諸元

プロダクト名 開発元 ライセンス リポジトリ
Amundsen lyft Apache Licence 2.0 https://github.com/lyft/amundsen
datahub linkedin Apache Licence 2.0 https://github.com/linkedin/datahub
metacat Netflix Apache Licence 2.0 https://github.com/Netflix/metacat
Apache Atlas Apache Foundation Apache Licence 2.0 https://github.com/apache/atlas
Egeria ODPi Apache Licence 2.0 https://github.com/odpi/egeria

Amundsen

  • フロント、バックエンドともにPython
  • 検索にElasticsearch、メタデータのストアにNeo4jを利用。
  • Pull型2

pros

  • マイクロサービス的に画面のサービス、検索のサービス、メタデータのサービスに別れている。
  • データ収集処理が抽象化されており再利用しやすそう。

cons

  • ビジネスメタデータを入れる余地は少ない。
  • メタデータのストアをNeo4jからApache Atlasに入れ替える改修が行われておりいまからの導入は不確実性が高いように思えた。

datahub

  • もともとWhereHowsというモノリシックなガバナンスツールのリプレイスで生まれた。
  • 検索にElasticsearch、メタデータのストアにNeo4jを利用。3
  • Push型で、kafkaを通じてCDCを処理できる。
  • Java

pros

  • テーブルレベルについてオーナーシップを細かく設定できる。
    • DB単位にはできない
  • avroでスキーマ管理されているので厳格な運用ができる。
  • データの上流下流を定義できる。(リネージ)
  • データセットが非推奨であることを明示的に設定可能。-> ライフサイクル管理の概念がある

cons

  • 画面からデータを投入することができない。すべてAPI経由。人間の手を入れないほうが管理が楽という割り切りかもしれない。
  • elasticsearchのバージョンが5系。ESの最新バージョンは8なので結構な遅れがある。(ES自体に破壊的変更が入ってる)

metacat

  • 画面のないAPIサーバ。UIは非公開か。
  • Java
  • Auditログ機能がある。

(とっつきが悪くあまり調べられなかった…)

Apache Atlas

pros

  • 強力な型システムにより、どんなミドルウェアにも対応できる。
  • ビジネスメタデータも型システムで表現すれば格納できる。
  • ClassificationとLineageを組み合わせて、Classificationの伝播を表現できる。
    • あるテーブルにPII(個人を識別できる情報)が入っるとフラグづけすると、 それをETLした先のテーブルにも自動的にPIIのフラグが設定される。
  • Lineageが強そう。

cons

  • 型システムが強力だが自分で設計する必要がある。概念の学習コストも高い。
  • その汎用性ゆえか、画面の動線がいまいちで、すべての情報がフラットに見える。
    • APIが公開されているので自分たちで実装したほうがよいと思った。

Egeria

https://cdn-ak.f.st-hatena.com/images/fotolife/u/usadamasa/20200531/20200531232005.png

pros

cons

  • コンポーネントがやたら多い。
  • webuiが見当たらない? どうやって動かすんだこれ。

まとめ

いずれのOSSも成熟してるとは言い難い。 metacatの記事でコメントされていたが、基本的に各社のビジネスにフォーカスした必要な分だけの機能となっており、再利用は難しい。 とりわけ、対応データソースにはムラがあり、実際の収集をする実装が公開されていないため、結局自分たちで実装する必要がある。また、ガバナンスの観点ではほぼカバーされておらず、いわゆる分析用途がフォーカスされている感がある。

メタデータストア部分と、データグラフ構築は再利用できるかもしれない。 APIを利用したWebUI、ワークフローなどはスクラッチするべきか。 いずれも各プロダクトの独自スキーマ定義を理解する必要があり、学習コストは高い。

未調査,非公開または有償製品

プロダクト名 開発元 有償製品 紹介記事
Dataportal AirBnb   Democratizing Data at Airbnb - Airbnb Engineering & Data Science - Medium
Alation Alation o https://www.alation.com/
Databook Uber   https://eng.uber.com/databook/
AWS Glue DataCatalog Amazon o https://docs.aws.amazon.com/ja_jp/glue/latest/dg/populate-data-catalog.html
GCP Data Catalog google o https://cloud.google.com/data-catalog
Collibra Collibra o https://www.collibra.com/
Ground UC Berkeley’s RISE Lab   http://www.ground-context.org/

Appendix

[^4] 2020-05-18 追記


  1. まだ基礎調査段階だが、有償製品はCollibraがよさそうに見える]

  2. To Push or Pull? That is the question. | SAP Blogs

  3. Neo4j人気だな。