Unyablog.

のにれんのブログ

Cloud Run で IAP が使いやすくなっていた

GCP Cloud Run

Cloud Run で内部ユーザーを認証する際は IAP を使うが、 今までは LB が必要だった。今月のアップデートで LB がなくても Cloud Run で IAP が使えるようになったので便利という話。

まえがき

Google Cloud は無料枠が多くコンソールも使いやすく個人クラウドカジュアルケチ勢にはありがたいサービスで、 GCE をはじめ GKE や Firestore など便利に使わせてもらっている。

とりわけ最近使ってるのは Cloud Run。コンテナを走らせるサービスなので一般的な Web app のコードを書くだけで使えるし、コストはアクセスした分だけなので激安。Service だけでなく Job を走らせるのにも割と安くすむし、 Lambda っぽいのがほしければ Cloud Run functions を使えば自動でビルドしてくれる。Cloud Scheduler や PubSub との連携も簡単。

デプロイすると自動的にドメインが生成されて外部からアクセスできるように簡単にできるし、内部用途でも IAM 認証をかけて特定の SA に絞れたりするのも嬉しい。Outbound についても、VPC / Subnet 内への通信とかできるようになって連携しやすくなった。

…と褒めまくっているが、案外ネックなのはユーザーの認証/認可だった。具体的には、適当な個人ツールを作って Google アカウントでアクセスを自分だけに絞りたいケース。

Cloud Run での内部ユーザー認証・認可

やりたいことは以下の「内部ユーザーを認証する」にあたり、IAP を利用してとのこと。

cloud.google.com

IAP 便利そうだしいいじゃんってなるのだけど、 IAP は（今まで）ロードバランサーが必須だった。なので、雑プロジェクトを運用にするには結構高い。ほとんど使わない LB に月3kくらいかかるのはちょっとね…

そうすると Sidecar としてコンテナごとに oauth2-proxy を立てるだとか、Firebase auth を利用して app に認証認可を組み込むとかがケチ的選択肢になるが、ちょっと気軽でない感じ。

ということで今までは同じプロジェクト内にある GKE に Cloud Run を向いた ExternalName Service を作って、その Service を向いた Ingress を作り、そこでクラスタ内ですでに使っている oauth2-proxy を利用しつつ認証・認可・Proxyするようにしていた。ただそれはそれで Cloud run 側で IAM 認証が使えなくなって境界ベースの防御になるのでイケてない前時代 SOHO セキュリティになっていた。

Cloud Run と IAP の組み合わせが LB 無しでできるようになった

という悩みを長年抱えていて新しい Service を作るたびにもにょっていたのだが、今月 Cloud Run で IAP が LB なしで使える機能が出ていたのに気付いた。

cloud.google.com

便利すぎる。 LB で立てるよりも保護の範囲も広がるらしい。ということで使ってみた。

Google Cloud Project を Organization 配下にする

今は Preview 版だからか Cloud IAP の制約なのか知らないが、Project が Organization 配下でないとこの機能は使えない。

なので、Organization 配下にないような個人アカウントのプロジェクトは、まず Cloud Identity または Google Workspace をセットアップして今使っている Project を Organization 配下に移動する必要がある。

ちょっと敷居が高く聞こえるが、Cloud Identity はドメインさえあれば無料ですぐ利用できるし、移動しても特にリソースや権限は今と変わらず使えるので作ってしまえば良い。

Project 移動の注意点としては、変更がすぐに反映されるとは限らないこと。IAM も Org 操作も、少し時間がかかることが多かった。

Cloud Run で IAP を有効にする

Project が Org 配下になって少し待つと、Cloud Run に IAP の設定項目が現れる。

あとは IAP を有効化し、Policy を編集して許可したいユーザーを設定し、保存する。そうすると IAP の保護下になるので、URL にアクセスすると Google 認証画面が出てきて、特定のアカウントでしかアクセスできなくなる。

注意点

いくつか引っかかりもあったので共有。

Org 配下にしてから IAP 有効化の操作をするべき

Org の配下にする前に IAP を API 経由で有効にしようとすると以下のエラーになる。

IAP is only available for projects that are part of an Organization.

Org 配下でないときは仕様なので正しいのだが、自分が行ったときは Org 配下にした後もこのエラーが出ていた。これはおそらく Org 化前に試した際のキャッシュによるもので、1,2時間待てばこのエラーの頻度は減っていった（最初はガチャ性があるので何回か試すと良い）。 Org 配下にしてから有効化するとこんなことにはならなかったかもしれない（もっと別の場所のキャッシュかもしれないが）。

組織外のアカウントは Principal に追加しても認可されない

ドキュメントにもあるが、Cloud Run の IAP で Principal として設定できるのは組織に属するユーザーのみである（正確に言うと、他のユーザーも設定はできるが動作しない）。そのため、普段の gmail アカウントを Principal に入れてアクセスしても IAP のエラー画面が返ってくる。

Cloud Identity を作るときに組織のユーザーも作っているはずなので、それを使うようにすれば良い。

Ingress は All にする

Internal にしていると IAP 経由だろうが外からのアクセスは Not found が返ってくるので、IAP を有効化するときに All にしておく必要がある。

IAP の設定を変えた際は、Cloud Run の URL に紐付く Cookie は一旦消したほうが良い。そうすると認証が必ず再度走るので確実な挙動確認ができる。

…ということで Cloud Run で微妙だった点が解決した話だった。今後も積極的に使っていこうと思う。

Power Automate for Desktop を起動するショートカットが Task Scheduler 経由だと動かない対策

Windows

Power Automate for Desktop ではショートカットキーを設定することができるので、そのショートカットキーを押すスクリプトを Task Scheduler を経由して実行することで定期実行ができる。

「Power Automate for Desktop Task scheduler」とかで検索すると方法が出てくるが、Task Scheduler でタスクを作ってテスト実行してみるとなぜかうまく動かない。

どうやら、少なくとも Task Scheduler がアクティブなアプリケーションとなっているときは Power Automate for Desktop のショートカットが発動しないらしい。スクリプトでキーを送信する前にフォーカスを外しておく必要がある。

自分は一旦デスクトップをアクティブにしてからショートカットを押すようにした。

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName Microsoft.VisualBasic

[Microsoft.VisualBasic.Interaction]::AppActivate("Program Manager") # program manager = desktop
[Windows.Forms.SendKeys]::SendWait('^+{F1}') # フローに設定したショートカットキー

wsl.exe の出力を UTF-8 にして Powershell の Select-String や -match が動くようにする

Windows

Powershell で wsl.exe の出力をそのまま操作しようとするとうまく動かない。

PS C:\Windows\System32> wsl.exe --list --running | Select-String "U"

Windows Subsystem for Linux Distributions:
Ubuntu (Default)

PS C:\Windows\System32> wsl.exe --list --running | Select-String "Ubuntu"
（何も出ない）

これは wsl.exe の出力 (unicode) と Powershell の想定する文字コード (UTF-8) が合わないのが原因。

wsl.exe の出力は一見すると普通の文字列に見えるが、 Format-Hex すると ASCII でも後ろに 0x00 が入っていることがわかる。

PS C:\Windows\System32> wsl.exe --list --running | Format-Hex
...
          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
0000000000000000 00 55 00 62 00 75 00 6E 00 74 00 75 00 20 00 28  U b u n t u   (
0000000000000010 00 44 00 65 00 66 00 61 00 75 00 6C 00 74 00 29  D e f a u l t )
0000000000000020 00

この対策としては、 WSL_UTF8 環境変数を設定して wsl.exe の出力を UTF-8 にすれば良い。

PS C:\Windows\System32> $env:WSL_UTF8=1
PS C:\Windows\System32> wsl.exe --list --running | Select-String "Ubuntu"

Ubuntu (Default)

github.com

シームレスな植生図を作った

Map

日本の植生図を見るための Web ビューワー、「シームレス植生図」を作って公開した。

シームレス植生図: https://vg67.map.nonylene.net/

植生図の楽しさ

植生図というのは、それぞれの土地の植生（生えている植物の集団）を分類して地図に表示したもの。

日本では環境省の生物多様性センターが植生の調査を行っており、例えば森であれば「ブナ－ミズナラ群落」や「カラマツ植林」、水田であれば「水田雑草群落」、市街地であれば「市街地」や「緑の多い住宅地」などの分類がなされている。

植生はその土地の風景を決定づけるかなり大きな要素だと思う。森か草原かといったレベルに限らない話で、北海道や長野の高原部は白樺が多くてスッキリとした雰囲気だし、沖縄では亜熱帯感のある濃い植物が多くてコントラストの高い風景になる。針葉樹と広葉樹でも明るさがぜんぜん違ったりする（ミズナラ林とかすき）し、秋や冬では常緑樹か落葉樹かで大きく変わる。

そういった身近な自然の違いは気候とともに街なかの雰囲気にも影響をあたえている、気がする。

山地の一般的な植生は地域によって変わってくる

植生図を見ると、そんな今いる風景を構成するのはどんな植物なのか、また同じようなものはどこで見れるのか、といったことを知ることができる。

山地だけでなく、平地に目を向けても楽しい。どこまで市街地が広がっていて、どこに公園があり、稲作・畑作が行われているのか、都市の特徴が植生図を見るとよく分かる。

名古屋の市街地の広がり

京都市街地の北端付近の様子

植生図のデータとビューワー

マップを開くと分かるとおり、植生調査はとても緻密に行われていて、特に直近進行している第6回・第7回調査はデータの使い勝手も良い。縮尺が1/25000にアップし、さらに凡例を全国で統一して6桁のコードにまとめてくれている。

一方、これを Web で気軽に見る手段は環境省公式の 自然環境調査 Web-GIS か、エコリスが配布しているエコリス地図タイルのビューワー くらいに限られる。どちらも基本的な植生情報の閲覧はできる（エコリスはサクサクしていて結構良い！）が、凡例をフィルタして分布を見たいし、生物多様性センターによる丁寧な解説 も表示したいし…、などなど自分のほしい機能が欠けていた *1 。

GIS やジオテクっぽいことを昔からやってみたかったこともあり、自分のほしい機能を備えた植生図ビューワーを作ることにした。

作る

ジオ周りの技術については全くの初心者（QGIS すら知らなかった！）なので、色々調べながら進めていった。全部書くと記事が終わらないので概要だけ書くと、以下のようなことをやっている。

github.com

  1. 全国の植生データ（Shapefile）を生物多様性センターからダウンロード
  2. 扱いやすくするため geojson に変換・データの整形（丸め込みや、不都合なデータの整形など）
  3. スケールごとに適した植生図 geojson データの生成（グループ化、小さなポリゴンのマージなど）
  4. スケールごとに適した凡例ラベルデータの生成
  5. tippecanoe を使ったベクトル地図タイルへの変換
  6. Shapefile のスタイルファイル（lyr）から凡例ごとの背景色を抽出・加工
  7. 生物多様性センターのサイトから凡例の解説を取得
  8. Mapbox を使った地図の表示、フロントエンドの作成

各種整形はライブラリ豊富な Python、フロントは Vanilla な JS で書いている *2。さまざまなスケールで見やすく使いやすい植生図にするためのデータの処理・パラメータ調整と Mapbox を使ったフロントの作成 *3 が特に大変で、楽しかった。

完成

ということで完成したのが以下。産総研の「シームレス地質図」をリスペクトして「シームレス植生図」という名前にした*4。

https://vg67.map.nonylene.net/

植生をクリックすると同じ植生の地域が強調表示され、生物多様性センターの解説が表示される。

沖縄のリュウキュウマツ群落

自然植生（人為的でない植生）のみを表示して、原生な風景がどこにあるかを見ることもできる。

白神山地やむつ周辺には自然植生が分布している

さらに細かく、凡例の検索・絞り込みもできる。

北海道のシラカバの分布

衛星写真と見比べることもできる。

郊外の市街地や田畑の分布

実は色を変えられる。

書かないと誰も気づかないであろう機能

Mapbox の力によって 3D の表示もできる…!

富士山

…すごくない？

なかなか良いものができたと思うので、ぜひ植生図の面白さに浸かってほしい。

各スクリーンショットのクレジット

1/2.5万植生図GISデータ(環境省生物多様性センター) 、「統一凡例（植生区分・大区分一覧表）」 (環境省生物多様性センター)を加工して作成 / © Mapbox / © OpenStreetMap / © Maxar Improve this map

*1:あと Web-GIS は https 対応が怪しくて Chrome で見れなかったり画面狭かったり...。エコリスは作り始めたころはまだ一部地域のデータがなかったというのもある。今ならエコリスタイルが第6,7回分を全国カバーしていてスーパー地形などでも見れるから、それで満足して作らなかったかも

*2:ライブラリ管理がめんどくさくてそうしたが、結果災害のようなコードになった…。Remix の記事を書いた nonylene はどこへ？

*3:要するに全てでは？

*4:産総研がシームレス植生図を作る場合は別の名前にします

ISUCON 14: ClickHouse と OpenTelemetry で ISUCON の計測環境を作ったら快適だった

isucon Grafana ClickHouse OpenTelemetry

ISUCON 14 に id:utgwkk, id:wass80 と「ミレニアムサイエンススクール」というチーム名で参加した。

結果は 28875 点で 22 位！去年は fail して最下位だったので反省を活かすことができたのでは？

一昨年に Kibana / Elasticsearch / Filebeat で解析環境を組んでサクセスしていたが、今年は OpenTelemetry (Otel) をベースにモニタリング環境を作り直し、バックエンドは ClickHouse、フロントは Grafana の構成でやってみた。これがなかなか良かったので紹介。

コンテスト当日のアプリ改善周りは utgwkk の記事を見てください。

blog.utgw.net

序: ISUCON で必要な計測

ISUCON ではパフォーマンスを継続的に確認してボトルネックを探しながら改善していくのが王道ルート。 インスタンスの CPU 使用率や RAM 利用量といった一般的なメトリクスについてはベンチ中に netdata なり htop なりを眺めていれば良いが、それだけではアプリケーション内部や各 API パスの具体的な負荷状況は把握できない。

そこで、 Nginx のアクセスログや MySQL のスローログ、さらにはアプリケーションの Trace を出力して集計することが重要になる。

有史以前からこの手のツールはいろいろあり、CLI だと kataribe、pt-query-digest あたりが有名なところ。

そんな中、Nginx のアクセスログや pt-query-digest を常時集計してメトリクス化し、ダッシュボードで一元的に表示できるようにしたのが一昨年の記事だった。

nonylene.hatenablog.jp

またこれで組んでもいいのだけど、 適当に投入しまくって適当に使うと若干重かったり、クエリが手でぱっと書けなかったり…といった Kibana / Elasticsearch 特有のめんどくささがある（あと飽きた）のも事実なので、今回は別の構成を試してみることにした。

ClickHouse と OpenTelemetry と Grafana でサクセス

Kibana は Elasticsearch と密に紐ついているので、Elasticsearch をやめるとなると Grafana など他の可視化ツールを使うことになる。

いろいろ探していたところ、Grafana と ClickHouse の組み合わせが良さそうということで使ってみた。

また、Nginx 公式の otel module があることを発見したので、これを機に Opentelemetry (Otel) を使って Trace も（Google Cloud Trace ではなく）自力で取り込んでみることにした。

ClickHouse

ClickHouse はもともと Yandex で作られていたものが OSS になり企業としてもスピンアウトしたものだそうで、カラム志向のデータ構造をした OLAP 向けデータウェアハウスとのこと。

clickhouse.com

Observability についても力が入っており（確かにモニタリングは OLAP の一種と言えそう）、Otel でログや Trace を ClickHouse に流し込み、Grafana の公式プラグインを使って Trace / Metrics / Timeseries の可視化ができる。

clickhouse.com

各種データの操作は SQL ベースの言語で行う。 Observability の文脈で SQL というのはなかなか珍しいが、Prometheus のわけのわからないクエリよりも100倍分かりやすくて良いと思う*1。

また、データウェアハウスらしくデータの様々な加工・集計・取り出しが高速に行えるので、 Otel の Processor で行うようなデータの前処理・ Grafana で行うような後処理を ClickHouse で完結できるのも良いポイント *2。

立てる

まずは ClickHouse を立てる。今回は公式 Docker image を Kubernetes 上で動かした。MySQL を動かすのと大体同じ感覚。

ユーザーを作る

デフォルトで作られる default ユーザーは権限最強で危険なので、Grafana と OpenTelemetry Collector (otelcol) 用のユーザーをそれぞれ用意する。

-- Grafana user
CREATE USER IF NOT EXISTS grafana IDENTIFIED BY 'password' SETTINGS max_execution_time CHANGEABLE_IN_READONLY, PROFILE `readonly`;
GRANT SELECT, SHOW ON *.* TO grafana;

-- otel_collector
CREATE USER IF NOT EXISTS otel_collector IDENTIFIED BY 'password';
CREATE DATABASE IF NOT EXISTS otel;
GRANT CREATE, INSERT, SELECT, dictGet ON otel.* TO otel_collector;

otelcol 経由でデータを投入する

otelcol-contrib は Exporter（送信先）として ClickHouse を設定できる。以下を参考にして otelcol-contrib の設定を行う。

clickhouse.com

設定して otelcol-contrib を立ち上げると、otel 用の Table を自動的に ClickHouse 側に作成してくれる。

SHOW TABLES

Query id: 4a180332-e499-492d-917b-b61ea8e342bb

    ┌─name──────────────────────────────────┐
 5. │ otel_logs                             │
 6. │ otel_metrics_exponential_histogram    │
 7. │ otel_metrics_gauge                    │
 8. │ otel_metrics_histogram                │
 9. │ otel_metrics_sum                      │
10. │ otel_metrics_summary                  │
11. │ otel_traces                           │
16. │ otel_traces_trace_id_ts               │
17. │ otel_traces_trace_id_ts_mv            │
    └───────────────────────────────────────┘

その後 otelcol で journald やファイルを読んだり、Trace を受信すると Clickhouse に各種データが投入され、Grafana で確認できる。

Explore で見るログ

Trace も Nginx から送ってみる。Nginx 公式 apt repo から Nginx と otel module を入れ、 otelcol に送るように設定することで簡単に Trace を見ることができた。

Nginx リクエストの Trace

スクリーンショットに Trace を取得するための SQL クエリが見えているが、このクエリは Grafana の流儀に合わせてデータを取り出す必要があるのでちょっと複雑。

ただ、基本的なクエリは Grafana ClickHouse Plugin の Query Builder で十分対応できるので直接 1 から書くことはない。Percentile など混み入った関数を使った集計やフィルタをしたくなったら、クエリを適宜編集することになる。

Materialized view を作成する

ドキュメントにも書いてあるが、otelcol によって自動的に作られた Table をそのまま利用することは推奨されていない。というのも、データ構造や貼られている Index は最低限のものであり、実際の利用に適したものにしたほうが効率が良いため。

これは前処理をしっかりしてから入れましょうね、という話ではなく、ClickHouse ではデータはそのまま入れて ClickHouse 側で処理を行うことが推奨されており、その処理を自分に都合の良い Schema でやりましょう、という話である。

We recommend users avoid doing excessive event processing using operators or transform processors. These can incur considerable memory and CPU overhead, especially JSON parsing. It is possible to do all processing in ClickHouse at insert time with materialized views and columns with some exceptions - specifically, context-aware enrichment e.g. adding of k8s metadata. For more details see Extracting structure with SQL.
...
We recommend users disable auto schema creation and create their tables manually. This allows modification of the primary and secondary keys, as well as the opportunity to introduce additional columns for optimizing query performance. For further details see Schema design.

Integrating OpenTelemetry | ClickHouse Docs

自分で Otel 用の Table から再定義してもいいが、今回は 面倒なので 自動作成される otel_* Table 自体は取り込んだ Trace / ログをそのまま保存する Table として触らずにしておき、 Nginx trace / pt-query-digest log / App trace / App log を集計する際はそれぞれ専用の Table を作成して利用することにした*3。これは ClickHouse の Materialized View 機能を使うことで実現できる。

clickhouse.com

ClickHouse で Materialized view を使うと、ソースとなるテーブルに Insert があった時にそれを元に加工した行を別の Table に Insert することができる。実質的にデータの前処理の役割を果たし、参照時は高いパフォーマンスで参照することができる。

たとえば Nginx の Trace 専用の Table (nginx_accesses テーブル) を作り、取り込んだデータ (otel_traces テーブル) を元にしてその Table に Insert するには以下のように設定する。

CREATE TABLE IF NOT EXISTS nginx_accesses (
    Timestamp DateTime64(9) CODEC(Delta, ZSTD(1)),
    TraceId String CODEC(ZSTD(1)),
    Operation LowCardinality(String) CODEC(ZSTD(1)),
    Duration UInt64 CODEC(ZSTD(1)),
    HTTPStatusCode LowCardinality(String) CODEC(ZSTD(1)),
    HTTPMethod LowCardinality(String) CODEC(ZSTD(1)),
    HTTPPath String CODEC(ZSTD(1)),
) ENGINE = MergeTree()
PARTITION BY toDate(Timestamp)
ORDER BY (HTTPMethod, Operation, toDateTime(Timestamp));

CREATE MATERIALIZED VIEW IF NOT EXISTS nginx_accesses_mv
TO nginx_accesses
AS SELECT
    Timestamp,
    TraceId,
    concat(SpanAttributes['http.method'], ' ', dictGet("path_regexp_dict", ('normalized'), SpanName)) AS Operation, # パス正規化用
    Duration,
    SpanAttributes['http.status_code'] as HTTPStatusCode,
    SpanAttributes['http.method'] as HTTPMethod,
    SpanAttributes['http.target'] as HTTPPath
FROM otel_traces
WHERE ServiceName = 'nginx';

注: Materialized view は、作成に既にあるデータは反映されない（反映してくれる POPULATE オプションがあるが、上記のようなケースでは使えない）。そのため、既存のデータを使うには Materialized view と同等のクエリを使って SELECT し、宛先 Table に既存のデータを Insert する必要がある。
Materialized view を変更するたびに宛先の Table の内容を変更しなおすのも面倒なので、変更時は Table / View ごと作り直すようにした。

構文としては SQL 的なので一度慣れたら簡単で、コンテスト中も App（Go で書いていたので Chi）のログに合わせて App ログ用のテーブルを作って otel_logs テーブルから流し込んだりしていた。

Grafana で可視化する

こうして Log も Trace も全部 Otel で ClickHouse に突っ込んで、ClickHouse 内で使いやすい形に整形し、Grafana でクエリして表示できるようになった。

Nginx モニタリングダッシュボード

例えばパスごとの p90 を上位から集計してテーブルで表示する（↑における右下のパネル）ためのクエリは以下のようになる。

SELECT Operation, quantile(0.9)(Duration)
FROM "otel"."nginx_accesses"
WHERE ( Timestamp >= $__fromTime AND Timestamp <= $__toTime )
GROUP BY Operation
ORDER BY quantile(0.9)(Duration) DESC
LIMIT 10000;

注: 上のクエリを最適化するにはここまでで紹介した Schema からさらに Index を追加する必要があると思います

（ClickHouse とは少しずれるが） 今回は Nginx の層で Otel を有効にして Trace id をつけているので、 Nginx のダッシュボードから Trace を辿ると App の Trace も一緒に確認できて便利だった。

Nginx と App の Trace

前回同様、pt-query-digest も30 秒ごとに結果を集計してリアルタイムで出すようにした。下の記事では Filebeat などで前処理を頑張っているが、今回は Otel から ClickHouse に生ログを流し、ClickHouse 側で JSON をパースするようにしている。

nonylene.hatenablog.jp

pt-query-digest モニタリングダッシュボード

otelcol 側で処理を行わないので、競技インスタンスの負荷も少なく、ベンチマーク中もリアルタイムでリクエストの状況を見ることができた。また、リクエストパスの正規化など前処理の変更があっても各インスタンス上の otelcol を触る必要がないのも楽だった。

Trace もログも同じ Datasource に統一された形で入っているので、それぞれ ClickHouse でパースしてメトリクス的に利用しやすいのも良いポイント。今回はやっていないが、 Trace と Logs を関連づけるのもできそう。

パフォーマンスも申し分なく、時間を広げたり変更してもキビキビ動いてくれた。 Elasticsearch / Kibana のときよりも少ないリソースだったがより快適なモニタリング環境ができたと思う。

その他の点

  • ClickHouse
    • CLI の出来が良い。補完機能や履歴検索機能などよくある Shell にある機能が充実している。
    • エラーログがわかりやすい。 CLI でクエリを打っているときもそうだし、otel でデータを投入するときも権限の不足などエラーの原因がすぐにわかった。
    • 概念周りのドキュメントが分かりやすくて充実している。例えば上記に挙げた otel の記事を読むと otel の概要も把握できて便利。ただリファレンス部分は若干機能の追加に追いついてない部分があったりした。
    • Elasticsearch でも Ingest pipeline で同じような前処理ができるが、設定のやりやすさがかなり違うと思う
    • もちろん万能ではなく、何も考えずに数百万件のログをスキャンして Order by するようなクエリを打つと時間がかかったり RAM が 4GB でも不足したりする。ほとんど困ることはなかったが、適度に Schema / クエリ設計は行うことが求められる。
  • Nginx が Otel を吐き出してくれるのがかなり楽だった。ログを解析すると regexp を頑張って書かないといけないので。

なかなか良いものができたと思うので、来年も活用していきたい。Grafana に感じていた壁も解消された気がする。

ISUCON 14 当日の動き

  • いつもようにサーバー周りを色々やっていた。 MySQL の isucon user のホスト部がはじめから % になっていて感動した。
  • プロファイリングは今までと同様 Google Cloud Profiler を利用した。無料で優秀。
  • アプリはあまり手を入れていなかったが、終盤に GET /api/owner/charts のキャッシュ改善やクエリ改善を少し行っていた。数千点上がったのでヨシ!
  • デプロイスクリプトで ISUCON_MATCHING_INTERVAL 周りをちゃんとケアすることができずにトラブってしまったので反省。
  • 終了 20 分ほど前にほどほどにいい感じのスコアが出たので、フリーズしてあとはチームメイトに ClickHouse の紹介などをしていた余裕のある回だった。なおスローログもアクセスログも切り忘れたし Nginx の Otel 出力もそのままにしていました。

ということで今回の ISUCON も楽しかった。最近は Observability 関連の知らない技術を触ってみる機会にもなっていて、 Otel 自体もほぼ初めてちゃんと触ることができたのでよかった（Trace しかできないと思っていた）。

問題もしっかり作り込まれていて良かったです。ベンチなどの環境も非常に快適でした。チームのメンバー、そして運営のみなさん、ありがとうございました！

*1:自分の Grafana への忌避感は PromQL によるものが大きい

*2:Prometheus だとそもそもクエリが遅かったり、Grafana 側で Transform する羽目になってめっちゃ重くなったりするよね

*3:正確には Trace 自体についても Materialized view を利用して正規化している。長くなるので別の記事に書くかも

kubectl の wrapper を作る際の tips （ZSH 補完など）

Kubernetes

kubectl に自動で namespaceや context を付与するような wrapper を作るとする。

そんなコマンドのインターフェースとして、

$ kubewrapper [...wrapper flags] [kubectl args / flags]
（例） $ kubewrapper -p staging describe pod ...

とすると

$ kubectl --context foo --namespace bar [kubectl args / flags]
（例） $ kubectl --context foo --namespace bar describe pod ...

といったコマンドが exec される、すなわちいくつかの flags を受け取って kubectl 用に変換しつつ args としては kubectl の引数をまるまる受け取るといったものが考えられる。

こういったコマンドを作るためには、補完をはじめとしていくつか注意点があるのでメモ。

外部 plugin 対応

通常の kubectl サブコマンド（get、 logs など）では、 --context や --namespace といった flag はサブコマンドの前に置いても動作する。

しかし、外部プラグインを呼ぶサブコマンドでは動作せず、サブコマンドのあとに flag をつける必要がある。

$ kubectl --context foo awesome-plugin
Error: flags cannot be placed before plugin name: --context

get, logs などは後置でも動作するので、常に後置にする（args 1つ目の直後）ように作ると良い。

上述の例でいうと、以下のようになる。

$ kubectl [kubectl 1st arg] --context foo --namespace bar [kubectl remaining args / flags]
（例） $ kubectl describe --context foo --namespace bar pod ...

kubectl の補完を利用する

kubectl では強力な補完機能を備えており、

source <(kubectl completion zsh)

すると _kubectl 関数が ZSH にインストールされて、kubectl の呼び出し時に補完用関数として呼び出されるようになる。

上述した kubewrapper での補完でも、 kubewrapper のオプションの補完もしつつ、kubectl の補完も使えるようにしたら便利だが、どうすればよいのか？

_kubectl は何をするのか

_kubectl は cobra を通じて生成されているが、その中では type されたコマンドの __complete サブコマンドが呼ばれている。

($ kubectl completion zsh の結果より)
requestComp="${words[1]} __complete ${words[2,-1]}"

色々細かい処理を省略すると、$words には今まさに打ち込んでいるコマンドの配列となっており、ZSH は 1-index なので words[1] は実行しようとするコマンド、 ${words[2,-1} は残りの引数ということになる。

すなわち、 $ kubectl get po<tab> を打っているとき、裏では _kubectl 内で $ kubectl __complete get po が呼ばれている。

_kubectl をカスタムコマンドで使う

ここで上述の kubewrapper の補完関数として _kubectl を設定するとどうなるのか。

_kubectl はあくまで今打ち込まれているコマンドを打つので、

$ kubewrapper -p staging get po<tab>

と打ったときは

$ kubewrapper __complete -p staging get po

が呼ばれることになる。

ここで kubectl の補完結果を流用するには、 wrapper 独自のオプションを消し、namespace や context flag を付加して kubectl の __complete コマンドを exec する、すなわち kubewrapper が以下を exec すれば良い。

$ kubectl __complete --context foo --namespace bar get po

※ __complete の前に namespace や context をつけると plugin 同様エラーになる

これを実現するには、wrapper の argv で __complete が 2 つめに来ていたら、$ kubectl __complete を打とうとしていると解釈すれば良い。wrapper で必須の引数が __complete の後にくることになるので、順序を入れ替えて解釈すると楽。

$ kubewrapper __complete -p staging get po
-> wrapper 内部では以下のように解釈する
$ kubewrapper -p staging __complete get po
-> そうすると wrapper の機能で自然と __complete が打たれる
$ kubectl __complete --context foo --namespace bar get po

wrapper のオプション補完

ここまで話した通り kubectl 関係の補完は _kubectl を通じて wrapper を呼び出して $ kubectl __complete に変換すればいい感じになるが、 その前に wrapper の必須 flag を埋めてもらう必要がある。

wrapper の必須 flag がなければそれを補完、満たされていれば kubectl の補完を発動させたい。

これは気合でいい感じに補完関数を書くことになる。

How do I check whether a zsh array contains a given value? - Unix & Linux Stack Exchange を参考にしつつ、以下のようにした:

if [[ $words[(Ie)-p] == 0 ]]; then
  # _arguments に wrapper の補完のみを記載する
  _arguments ...
else
  # _arguments に kubectl の補完も加える
  _arguments ... \
    '(-)*:kubectl args: _kubectl'
fi

(-)* は kubectl の args が現れた後は全てのハイフンの補完を無視するという意味。

zsh.sourceforge.io

こうすると、最初は wrapper に必須の flag のみが補完され、全て埋まったら wrapper の他の flags とともに kubectl の補完も表示されるようになる。

WSL2 を Windows 11 で起動させ続ける

Windows

この方法は使えなくなりました

Windows 11 からかはわからないが、WSL2 がしばらく放置していると自動でシャットダウンされるようになった。

ターミナルや VS code を全て閉じるとシャットダウンされる傾向にあるようで、例えば ssh-agent や systemd の service が動いていてもいつの間にかシャットダウンされるので厳しい。

調べてみると init にぶら下がっているプロセスがなくなると死ぬのでは？ということだった。 vmIdleTimeout の情報も出てくるが、これは WSL2 が乗っている VM を起動させ続ける話で、WSL2 で動いている Ubuntu などは関係なく終了する。

qiita.com

対策として、Powershell 側から wsl.exe を発行し続けるなど色々あるみたいだが、 /etc/wsl.conf に起動コマンドを設定することで回避ができたのでメモ。

learn.microsoft.com

/etc/wsl.conf で以下のように設定すると sleep コマンドが init にぶらさがって起動してくれる。

[boot]
command=sleep infinity

これで設定してから数日経ったが、起動し続けてくれていそう。