2020-10-27

AWS SSO のユーザをSCIMでプロビジョニングする。

事前準備

SSOのための ENDPOINTとTOKENを取得しておく。

ユーザ作成

<Endpoint>/Users
 -H"Authorization: Bearer <Token>"
 -H"Content-type: application/json" -d'
    {  "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
      ],
"userName": "EmailAddress",
"displayName": "displayName",
      "name": {
        "familyName": "familyName",
        "givenName": "givenName"
      },
    "active": true
}'

グループ作成

<Endpoint>/Groups
 -H"Authorization: Bearer <Token>"
 -H"Content-type: application/json" -d'
{"schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:Group"
      ],
      "displayName": "GroupName",
      "members": []
}'

グループメンバー更新(メンバー一覧をreplaceする。)

グループ情報を拾っても、現在のメンバー一覧が取得できないため、メンバー一覧をreplaceでまるっと入れ替える。

<Endpoint>/Groups/<group-id>
-XPATCH
 -H"Authorization: Bearer <Token>"
 -H"Content-type: application/json" -d'
{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "path": "members",
      "value": [
        { "value": "<User-id>"},
        { "value": "<User-id>"},
        { "value": "<User-id>"},
        { "value": "<User-id>"}
      ]
    }
  ]
}'

2020-09-16

Prometheusのデータ長期保存にVictoriaMetricsを使う。

概要

Prometheus2.0にて、 remote write という、Prometheusで収集したデータを別のストレージにも書き込む機能ができています。

InfluxdbやThanosやM3など、remote write先はいくつかありますが、

Measuring vertical scalability for time series databases in Google Cloud | by Aliaksandr Valialkin | Medium

を読んだりして、VictoriaMetricsがよさそうだなと思い、導入した話

VictoriaMetrics

VictoriaMetrics | The best long-term remote storage

VictoriaMetricsの特徴はいくつかありますが、Prometheusのクエリ言語がそのままつかえる、というのがあります。

つまり、Grafanaなどで参照する先をPrometheusからVictoriaMetricsに切り替えられるということです。

これの何がいいかというと、Prometheusはデータの収集にのみ焦点を当てることができるということです。

また、VictoriaMetricsは、vmagent、vmalertなど、いくつかの周辺ツールも用意しています。

vmagentはPrometheusの設定ファイルを読んで、Proemtheusと同じようにデータを収集し、VictoriaMetricsにデータを送ることができます。

vmalertはPrometheusのアラート発砲と同じ機能があります。Alertmanagerと組み合わせ、アラート管理が行えます。

Prometheusを、さらに細かく機能ごとに分割したもの。というイメージです。

Prometheusがデータの永続化に興味がないのに対し、VictoriaMetrics can be used as long-term storage とうたっているように、長期間データを保存することが年頭におかれています。先に示したmediumの記事に書いてある中でもストレージ使用量はInfluxdbの半分程度です。

VictoriaMetircsにはclusterバージョンもありますが、ここでは触れません。

Prometheus から VictoriaMetricsにデータを送信する

これはとても簡単で、Prometheusのremote_rwite設定に、 VictoriaMetricsをセットアップしたノードを記載するだけです。

PrometheusとVictoriaMetricsでのデータ利用量比較

私の見ている環境では、Prometheus の標準設定 15日分保存で42GB程度のストレージを消費している環境で、同じくVictoriaMetricsへ15日分転送が終わった段階で、7.5GB程度のストレージ消費でした。

だいたい1/5 - 1/6 程度のサイズで済んでいます。つまり、同程度のストレージを用意すると、それだけで3か月分保存ができるということです。

また、Grafanaをたくさんの人が開いていると、クエリが処理しきれいず、Prometheusでのデータ収集が止まるということが度々起こっていましたが、VictoriaMetricsを利用することにより、データの取得元をVictoriaMetircsへ変更することができ、 Proemtheusのデータ収集が止まるということが起こらなくなりました。

これは大きな利点でした。

結論

VictoriaMetricsを利用して Prometheus+Grafanaの環境がとてもよくなりました。やっぱり長期保存、PromQL対応は良かったです。

2020-07-30

sonatype nexus3 の s3 blobstore は rubygems では遅くなった話

タイトルがすべてを物語っていますが、

sonatype nexus3 とは、パッケージマネージャです。

maven, rubygem, pypi, npm, docker など、各種言語などのパッケージマネージャを主に内部向けに公開するのに使えるものです。

最近だとgithubなどもパッケージを置けるようになって存在意義が薄れてきているのかな？というきもしますが。

で、各種パッケージを保管する場所が必要になりますが、通常、サーバ上のファイルシステムがその保管場所として利用されます。

nexus3では、サーバ上のファイルシステムのほか、AWS S3 も保管場所として利用できます。オフィシャルサイトにも、EC2でnexus3を動かすのでないかぎり、推奨しないと書かれていますが。

なにはともあれ、EC2でnexus3を動かしていたので、S3をストレージとして利用していたところ、

「bundle install すると前は10秒くらいで終わっていたのが2-3分かかるようになったんだけど」

などと連絡を受け、ストレージ変更のほかに構成変更を行っていたのでそこが原因かも、と疑い、いろいろ設定変更したりしたのですが、ファイルシステムをストレージとして利用したところ、高速化し、原因が判明したという流れです。

ではなぜS3にすると遅くなるのでしょうか。それはおそらく、依存関係解決のためです。

Gemfileには、まず、直接依存しているパッケージ群が記載されています。

まず、それらのパッケージについて、どのパッケージに依存しているのかをnexus3に問い合わせます。

すると、nexus3は、各パッケージの依存関係が記載されたファイルを取得します。結果、s3からのファイルダウンロードがパッケージの数だけ走ります。

nexus3から、依存先のパッケージ一覧が返ってきます。

新しく見つかったパッケージについて、またどのパッケージに依存しているのかをnexus3に問い合わせます。

というのを、全パッケージについて行いますので、s3からファイルをダウンロードする回数がそこそこ多くなり、そのぶん時間が余計にかかる。という話です。

EC2で運用してこれなので、AWSからネットワーク的に遠いところでS3をストレージとして利用すると、目も当てられないような遅さになるのではないかと推測できます。

なんかいろいろと

てきとう