2021年 手に入れてよかったものN選
年末恒例のやつです｡
家具家電編
電動昇降スタンディングデスクE7脚 + KANADEMONO 長良杉天板 140 * 70
THE BOARD / 長良杉kanademono.design
皆さん大好きなFlexiSpotとKANADEMONOの組み合わせ｡
太ももの圧迫感を軽減できるよう下限の低いE7にした｡
天板の幅は120と悩んだけど､広く使えてとても満足してる｡
蛇足だけど部屋をうろつきながらたまにPC触る状況でデスクを上げた状態にしておくといちいち座らなくてもよくて快適｡
ルミナスラック
キャンプギアを床に積んでいたが上のスペースが余りすぎて勿体なかったので導入｡
書類なども収められるようになったのでヨシ｡
Vivitek QUMI Q8 モバイルプロジェクター
もともと小さな10年モノの液晶テレビしか持っておらず､大画面が欲しいと思いつつも場所を取るのが嫌だったが､rentioさんの記事で天井ダクトレールにプロジェクター吊せばいいじゃん!と気づき導入｡ プロジェクター自体もrentioで借りている｡
Fire TV Stick､Nintendo Switch､PS3(Blu-ray再生用)を接続｡
DENON HOME SOUND BAR 550
プロジェクター導入に伴い音響が貧弱であることに気づき､奮発して購入｡
操作性もよくサブウーファーなくても重低音が十分に出てよい｡
ケーブル周りが難しくアンプまで導入するか??と検討したけど結局HDMIのマトリックス切替器で解決｡
https://www.biccamera.com/bc/item/7196567/
後付けでリアルサラウンド環境にもできるので来年導入したい｡
小物編
ペーパータオル
コロナ禍でこまめに手を洗うようになるとハンドタオルが湿りっぱなしになるのが気になり使い捨てできるペーパータオルを導入｡
コスパはちょっと悪いけどタオルを何枚も用意するよりはマシと割り切ってる｡
洗面台と台所に配置｡
ごはん保存容器 一膳用
2合炊ける土鍋を4つにラップに包んでにして冷凍していたが､均等に分けるのが難しかったり冷凍庫にうまく収められなかったり｡
容器があればいい感じになるかなと期待して導入｡解凍後のべちゃっと感も緩和されてよかった｡
優秀賞
視力(ICL手術)
レーシックと似てるけど､眼内コンタクトレンズと呼ばれるものを挿入して視力を矯正する方式｡
子供のころからずっとメガネとコンタクトレンズを行ったり来たりしてるうちに怠くなってきて一念発起｡
施術自体は30分程度で痛みもなく終わるが術後1週間シャワーを浴びれなかったり目薬を頻繁に注す必要があったりと､前後の生活スタイルを考慮しないとならない｡
その代わり効果は劇的で､メガネがないと外出るのも難しかったのがなんら困難なく生活できている｡目が覚めた瞬間視界がクリアなのは感動｡
まとめ
結構な散財をした1年だった気がするが来年はもっと散財したい｡
Google Cloud 認定資格の試験を遠隔監視オンラインで受けてみた
Google Cloud Platform(以下GCP)には､GCPを用いた職務遂行能力を評価し認定する資格があります｡
資格を取得するには､規定の試験を受け､合格する必要があり､試験は､オンサイト試験または遠隔監視オンライン試験いずれかを選択できます｡
オンサイト試験は､テストセンターに行き､私物等をロッカーに入れた上で隔離環境のPCから受講しますが､
遠隔監視オンライン試験は自宅やオフィスなど任意の場所で受講可能な一方､ テストセンターと同程度の環境で受験していること を要件にし､カメラなどで常に監視されています｡
この要件から､オンサイト試験でテストセンター*1で実施する方が面倒は少ないのですが､昨今の状況を鑑みて､人と物理的に接触することのない遠隔監視オンライン試験を受講しました｡
受験した資格
Google Cloud Certified - Professional Data Engineer (Japanese)
私の受験環境
- 居住環境
- 大通りから一本奥まった低層マンション(1K)
- 一人暮らし
- 騒音が聞こえてくることは通常ない｡
- PCはリビングに設置｡ 技術書などを詰めた大型本棚も同じ部屋にあり､カメラに映る位置｡
- PC
受験前の準備と当日の流れ
前日まで
- 受験ガイドExam Procedures を参考にチェック
- ｢Sentinel｣という監視ツールをインストール
- ｢生体認証プロファイル｣を取得(カメラで顔を映す)
当日
- 試験開始15分前
- 常駐させている各種アプリを終了｡(Docker, Krisp, Google driveなどなど…｡)
- デスクからキーボードとポインティングデバイス以外をすべて撤去する｡ 撤去したものは視界に映らないようにした｡
- 本人確認のためのパスポートを準備
- 試験開始10分前~試験開始まで
- 試験開始
トラブルや戸惑ったこと
- 試験開始前のカメラ撮影で試験官のリアクションが少なく､撮し方が合ってるのかどうなのかわからなかったので､こちらから｢いかがでしょうか｣｢以上です｣などのメッセージを送ったりしてました｡*2
- 試験開始直後､問題文を小声でブツブツ読み上げていたところ､監視の要件に引っかかった?のか試験が中断した｡ 警告の文言を読んで理由がわかったのでOK押して再開した｡
- 試験が終わりSentinelのウィンドウが閉じたのでブラウザに戻ると｢トラブルが発生したので~~｣のような文言が表示されwebassessorからログアウトされていた｡ すわ試験無効か!?と焦ったが､再ログインして結果を確認したら合格となっており､got kotonaki｡
まとめ
GCPの遠隔監視オンライン試験についての体験レポートは以上です｡ 今回のケースではさほどトラブルもなく順調に進みましたが､普段テレビ会議のセッティングになれていない場合は事前準備をすることをオススメします｡ コロナ禍においては外出せずに試験を受けられる仕組みは大変有用なので､今後(なんならコロナ禍が収まってから)も積極的に利用したいです｡
見知らぬGCPプロジェクトの利用状況を把握する方法あれこれ
前書き
管理者不在のGCPプロジェクトを渡され､何してるのかを調べて欲しいというタスクを振られたかわいそうな人向けにトリビアルなノウハウを共有します｡
TL;DR
- Asset Inventoryでリソースの総量を把握する｡
- 稼働状況をモニタリング､ログ､Billingなどから把握する｡
- リソース同士の関連をIAMから探る｡
- 引き継ぎはちゃんとやれ｡たのむ｡
前提
本文
本記事では､GCPが提供するコンソールをさっと眺めるだけである程度のざっくりとした構成を概観し､より詳細な調査をするための足がかりを得るノウハウを共有します｡ 各リソースの詳細までは踏み込みません｡
利用するツール
この記事で触れるツールは以下です｡ 順番に説明しますが､実際はこれらのツールを相互に行き来しながら関連を探ることになります｡
- Asset Inventory
- Cloud Monitoring
- Cloud Logging
- APIs & Services
- IAM
Cloud Asset Inventory
Cloud Asset Inventoryは､GCPプロジェクト内のリソースのメタデータを保有し､一覧化や検索が可能なサービスです｡ 利用は無料です｡
Cloud Asset Inventoryを用いることで､どんなリソース(VM, GCS, BigQuery, VPN…)が作成されているのか､それらがどのlocationにあるのかを把握することができます｡
Cloud Asset Inventoryは｢IAM & Admin｣配下から使用でき､以下のように､どのリソースがいくつ作成されているかを一覧できます｡
上の画像では､少なくともGAEのサービスが1つ､BigQueryのデータセットが2つ､VPNが1つとサブネットが多数あるといったことが伺い知れます｡
コンソールからCSVダウンロードも可能です｡
注意点としては､Cloud Asset Inventoryはあくまでリソースがあるかないかの静的な状況で､｢実際に使われているかどうか｣は判別できません｡ ｢実際に使われているかどうか｣は別のツールが必要になります｡
Cloud Monitoring, Cloud Logging, APIs & Services
｢実際に使われているかどうか｣を把握するためのツールとしてはMonitoringとLogging*2とAPIs & Servicesがあります｡ これらはGCPのリソースの利用状況と､なにかしらのイベントが起きていることを詳細に把握できるツールです｡
Cloud Monitoring
ここでも｢Resource dashboards｣という形でリソースの有無が把握できます｡
Cloud Monitoringは代表的なプロダクトについてはGCPが予め作成したダッシュボードがあり､稼働しているプロダクトが表示されます｡ また､気の利いた前任者であれば､カスタムダッシュボードとしてそのプロジェクトで把握したいメトリクスをまとめたダッシュボードを発見できるかもしれません｡*3
Cloud Logging
CloudLoggingは､各コンポーネントが出力したログエントリが集約されていて､なんのプロダクトが活発に動いているかが把握できます｡ 画面上の｢PageLayout｣から｢Log Field｣および｢Histogram｣をペインに表示しておくことで､どのリソースが直近どのような時系列と頻度で動いているかを知ることができます｡
APIs & Services
GCPはリソースの各種操作をAPIを利用して行っており､｢APIs & Services｣はそのAPIの利用状況がわかるダッシュボードです｡
このダッシュボードを参照することで､ヘビーに呼び出されているAPIはなにか､そのプロダクトはなにかを把握し､ワークロードの傾向をつかむことができます｡
IAM
IAMを参照することで､どのアイデンティティ*4が何の権限を持っているかを把握することができます｡
前任者がキチンと設計したかどうかで､IAMが細かく作成されているか､おおざっぱになっているか､あるいはデフォルトサービスアカウント*5一本槍かは異なります｡
付与されている権限だけでなく､Recommenderという機能により､付与された権限のうち､実際には使われていない権限を把握することができます｡ 裏を返せば､実際に使われている権限も確認できます｡
これらの情報から､以下が把握できます｡
クロスプロジェクトの権限付与
GCPは､プロジェクトをまたいだ権限付与が容易に可能な方式です｡ 異なるプロジェクトに属するサービスアカウントから､調査しているプロジェクトに対する権限*8はコンソールから容易に把握できますが､一方でそのプロジェクトのアカウントが他のプロジェクトへの権限を持っている*9ことを知ることは事前の知識がなければ困難です｡ 後者の権限はBigQueryのDWH/マートなどを集約したプロジェクトを参照する方式で頻発するため､DWH/マートを保有するプロジェクト側での統制が重要となります｡
サービスアカウントキーが発行されている場合
GCPは､サービスアカウントキーのjsonを発行することで､GCPサービス外からGCPの機能を利用することができます｡
調査の過程で､このサービスアカウントキーが発行されていることが発覚した場合は､構成の把握の難易度が格段に上がることを覚悟してください｡ サービスアカウントキーは一般に､GCP外のオンプレミスシステム､SaaSやAWSなどのパブリッククラウドで使われ､事前の知識がなければどこで利用されていることを把握することは困難です｡
｢少なくともまだ利用されているかどうか｣は､使用状況のモニタリングから観測することができます｡*10
まとめ
- GCPコンソールだけでも結構わかることはある｡
- Cloud Asset Inventoryはここしばらく開発が活発なようなので要チェキ｡
- いくら頑張っても知識が無い状態から要件定義､基本設計を導き出すことは基本的に不可能なので有識者を探すこと｡*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 版.
ローカル開発用Dockerでユーザアカウント認証済みのgcloudを使う
サービスアカウントのキーを発行する必要はない｡
version: "3.7" services: app: build: . volumes: - ~/.config/gcloud:/root/.config/gcloud:ro environment: - GCLOUD_PROJECT
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となるように記述する｡
- このとき､複合されるSecretの名前が
- argocdに元からある
argocd-secretにpatchを当て､sealedsecrets.bitnami.com/managed: "true"のannotationを付与する｡ argocd-cmのclientSecretの値の先頭に$をつけて､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月に投稿された原記事
↑について言及したInfoQの日本語訳
https://www.infoq.com/jp/news/2020/03/distributed-data-mesh/
反応記事
https://towardsdatascience.com/data-mesh-not-a-service-mesh-1a4a315193b3
原記事著者の講演動画
併せて読みたい
https://www.altoros.com/blog/data-federation-vs-data-integration/
リボンモデルの意義
プラットフォーム間のディスカバリ
個人情報保護の手段としてのリネージ
TL;DR
ここから本編
データ分析をするにあたり､そのデータがどこから来たものなのか､監査をするにあたり､不適切なデータの利用がされていないのか､知りたい人は多いと思います｡ とりわけ､上記のような動機をもってる人が所属する組織は､多数の部門に分かれ､それぞれの部門で採用している技術スタック､ミドルウェアが異なったりします｡
- データの由来を知るにも担当者はそもそも誰なのか､どこの誰に聞けばわかるかがわからない｡
- データ基盤を運用してるがあるデータセットの変更がどこにどう影響を与えるのかわからない｡
- 個人情報開示請求をユーザから受けたけど､いったいどこにどうデータが伝わっているのかわからない｡
そういった辛みを解決するための手法として､データリネージというものがあります｡
メタデータとリネージ
しんゆうさんやゆずたそさんの活動により､メタデータ管理､データマネジメントの重要性( メタデータ整備 )については徐々に認知されていると思います｡ しかしながら､単独のデータセットについてではなく､複数のデータセットを束ね､関連付けて整理する活動についてはいまだ言及が少ないように思えます｡
データリネージは､メタデータのうちの一領域で､情報の履歴･ライフサイクルをトラッキングすることです｡ トラッキングする要素は､データの入出力､処理を行うプロセス､データセット間でなにが伝わったかなどです｡
個人情報保護のためのリネージ
データ分析基盤を持ち運用している組織であれば､複数のサービスそれぞれのデータセットに管理者が存在し､個人情報の漏洩や目的外利用を監督していると思います｡ *1
分析基盤への流れが単純であれば､それぞれのサービス内容やデータセットの内容､また分析施策の内容を把握し､現実的なコストでリスクを抑えることができます｡
しかしながら､複数のデータ分析基盤があり､かつ連携がある場合､後続の分析基盤がそれぞれのデータセットの来歴を把握するコミュニケーションコストは指数関数的に増大します｡
稼働当初は分析基盤βが適切に管理していたとしましょう｡
しかしある日から分析基盤αへ､サービスCと一緒に扱ってはいけない､サービスXのデータが含まれてしまったとします｡
分析基盤βの管理者はそれを把握することができるでしょうか?
分析基盤βと分析基盤αの間で綿密な情報共有が行われていればαのほうからβへ連絡することで気付くことができるかもしれませんが､間に挟まるステークホルダーが増えるにつれて難しくなるでしょう｡
またデータ分析者があるデータセットを施策に使いたいと思ったとき､プライバシーポリシーとして問題ないかチェックするプロセスを取る組織もあると思いますが､この5営業日かかります､となるとデータ分析のプロセスは滞り､機会費用が発生します｡
このリードタイムを忌避しチェックを怠れば､よくて施策が世に出る直前でストップ･すべて台無しになるか､大体がサービスそのものが炎上し事業の継続性が損なわれます｡
データガバナンスツールApache Atlas
前置きが長くなりましたが､上記のような課題を避け､データの流れを可視化するツールとして､Apache AtlasというOSSがあります｡
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はメタデータを DataSet と Processの2つに大きく区別します｡ DataSetはあらゆるデータを含む抽象的な概念｡Processは､DetaSetとDataSetをつなぐ概念と捉えられます｡
下の画像は､Apache Atlasのオフィシャルサイトから拝借したもので､緑の丸､赤の丸がDataSet､青の歯車の丸がProcessを示しています｡
左のデータを出発とし､一度テーブルにロードした後､さらにViewによって複数のデータセットに分割しています｡
これだけでは特に面白くもないと思いますが､Apache Atlasの特徴的な機能としてClassification Propagation(分類の伝播)があります｡
下図のように､一番最初のデータに､PII(個人を識別できる情報)というClassificationを付与すると､Processを介して後続のテーブルにまでそのClassificationが伝播し､最後のDataSetに対しても､そのDataSetにはPIIが含まれているという情報を付与することができます｡
このClassificationは様々な値を定義することが可能で､複数のDataSetを入力とするDataSetについて､入力のDataSetそれぞれに別々のClassificationを付与した場合､出力のDataSetには両者のClassificationが付与されることとなります｡
この機能によりデータ分析基盤においての個人情報の目的外利用が可視化できると期待しています｡
データの収集について
Apache AtlasはREST APIを提供しており､任意の方法でデータを収集することができます｡ atlas.apache.org しかしながら､データソースにアクセスしメタデータを採取する具体的な実装は提供されていません｡
この部分に関しては､開発が必要です｡ たとえば@k1Lowさんの開発する tblsの出力データを利用することや､他のメタデータ管理ツールで収集したデータをAPIで連携するなどが考えられます｡
Apache Atlasの活用事例
Apache Atlasは､誤解を恐れずに言えば､メタデータ管理について低レイヤな基盤となる機能を提供しており､実際に組織で運用するには様々な工夫が必要と考えています｡ Apache Atlasをバックエンドとして､WebUIや周辺機能を実装したOSSを提供している事例として､ lyftが開発するamundsenや､ODPiが開発するegeriaがあります｡
まとめ
煩雑な文になってしまいましたが､データ整備､データガバナンスについては昨今議論が活発になってきたところです｡
具体的な実装方法についても情報共有できていけたらと思います｡
Appendix
- Apache Atlas – Data Governance and Metadata framework for Hadoop
- Amazon EMR で Apache Atlas を使用して、メタデータの分類、系統および発見を行う | Amazon Web Services ブログ
- "データリネージ"の把握が複雑な金融規制順守の鍵に | MarkLogic
- Amundsen — Lyft’s data discovery & metadata engine - Lyft Engineering
- Data Lineage and Metadata Management: An Innovative Approach - DATAVERSITY
*1:してますよね…??
*2:https://incubator.apache.org/projects/atlas.html
*3:https://jp.cloudera.com/products/open-source/apache-hadoop/apache-atlas.html
*4:InsightOut: The case for open metadata and governance | IBM Big Data & Analytics Hub
*5:jsonでスキーマ定義する https://github.com/apache/atlas/tree/master/addons/models
