はてなブックマーク

背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと

背景 マイクロサービス環境でIstio(Envoy sidecar)を使っていると、いくつかのエラーに遭遇します。 それぞれどういった状況で発生しているエラーなのかを区別できないと、適切な対応にならないため各種エラーをまとめます。 環境 Envoy 1.22.0 Go 1.21 構成 次のようにclient appやserver appにsidecarが挟まるようにします。 エラー dial tcp 172.20.0.4:8001: connect: connection refused connection error: desc = "transport: Error while dialing: dial tcp 172.20.0.4:8001: connect: connection refused が発生するパターンです。 周辺ログも含めると次のようになります。 timeout-

背景 最近GitHubでページ内検索を使ってると、たまに次のような表示崩れが発生します。 スクロールしても前のコードがずっとそこに残っています。 このときのコンソールログとしては決まって次のエラーで、 content.js:1 Uncaught DOMException: Failed to execute 'getRangeAt' on 'Selection': 0 is not a valid index. at du (chrome-extension://cofdbpoegempjloogbagkncekinflcnj/build/content.js:1:214647) cofdbpoegempjloogbagkncekinflcnjでchrome拡張を検索すると DeepLのChrome拡張ということだったので拡張をOFFにしたところ、表示崩れが起きることがなくなりました。 ま

概要 Go言語でRedisを使う際に選択肢に挙がるのがgo-redisです。 今回はgo-redisでTimeoutを設定する際に注意すべきことをまとめました。 手前味噌ですがBlast Radius of Failureを最小にするためにTimeoutを短くすることを１つのテクニックとしても紹介しています。 W杯全64試合無料生中継で「落ちない」を実現。「小さく壊れる」ために行った負荷・障害・セキュリティ対策とは？【ABEMA DEVELOPER CONFERENCE 2023#3】 | レバテックラボ（レバテックLAB） しかし短すぎるとそれはそれで問題が発生することになるので、その理由を説明します。 環境 redis/go-redis v9.0.5 go-redisのTimeoutの種類 go-redisではtimeoutとして以下があります。 種類 説明 デフォルト値 DialTi

背景 gRPCを利用していると、デプロイを含む一時的なネットワーク断で以下のようなエラーが発生することがあります。 rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp xxx: connect: connection refused" rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup xxx: i/o timeout" これはgRPCがfail fastの思想になっており、ChannelがTRANSIENT_FAILUREの状態だとRPCを即座に失敗させるようにして

概要 OpenTelemetryはObservabilityの三本柱であるLogs、Metrics、Tracesをベンダーに依存せず実装するための仕様＆実装です。 今回はそのうちのTracesをGoで試してみます。 環境 Go v1.20.2 go.opentelemetry.io/otel/trace v1.14.0 前提知識 登場人物 OpenTelemetryでは以下の要素があります。 登場人物 役割 Tracer Provider Tracerを提供する。またトレース情報のExport先を管理したり、トレースに共通で付けたい属性データを管理する Tracer Spanを生成する Span 各操作におけるトレース情報 Trace Exporter トレース情報の出力先。標準出力だったり、Jaegerのような分散トレース可視化ツールなど Trace Context Spanの関連付け（

概要 RedisのPipeline, Multi, Watchの区別をする上であまりシーケンス図を用いた説明がなかったので図示してみました。 解説 Pipeline 課題 通常複数の処理を実行しようとすると以下のような流れになります。 シンプルではありますが都度サーバ通信が入るところに無駄があります。 解決策としてのPipeline パイプライン処理は複数の処理を１つにまとめてRTT(Round Trip Time)を改善します。 先程3回サーバ通信が必要でしたが、Pipelineを用いることで1回で済むようになっています。 Multi 課題 先程のPipelineは複数の処理をバッチ化できるというメリットがありましたが、途中で他のクライアントからの処理が割り込む可能性もあります。 上図ではまだGETなので大丈夫ですが、途中割り込んでしまうとデータ整合性が壊れてしまうケースももちろんありま

背景 Prometheusでメトリクスを可視化する際にPromQLを使います。その中で最もよく使うのがrate()関数ですが、 window, interval, resolutionの違い irate()関数との違い など疑問に思ったので一度きちんと整理してみます。 環境 Prometheus v2.40.5 range ventor rate関数を理解する上でまずrange vectorの概念を理解する必要があります。 windowとintervalとresolution こちらの図が非常に分かりやすいです。 ref: https://iximiuz.com/en/posts/prometheus-functions-agg-over-time/ 言葉で表現すると以下です。 用語 説明 window rate関数で平均化する際の期間。上図のrange duration。sliding

概要 KubernetesのPodを安全に終了する際に気をつけるべき事前知識と設定方法について説明します。 あらかじめまとめると 新規リクエストのルーティングがなくなるまでpreStopでPodのアプリケーションコンテナの終了開始を待たせる 既存リクエストが全て処理されるまでアプリケーション側でGraceful Shutdownをする SIGKILLで強制終了されないように1, 2が完了するまでterminationGracePeriodSecondsを長くする の３つを実施することになります。 環境 Kubernetes v1.21.14 前提知識 Podが終了すると何がトリガーされるか Podが終了するとまずdeletionTimestampがPodリソースに設定され、Terminating状態になります。 そしてその次に以下の３つの処理がそれぞれ独立（並行）して実施されます。 Pod

概要 CircleCIのDynamic Configでconfig.ymlを分割管理する - Carpe Diem ↑ではファイルを分割管理する方法を説明しました。 今回はpath filteringを使って差分ビルド（変更のあるディレクトリのみビルド）する方法を説明します。 環境 CircleCI 2.1 circleci/path-filtering 0.1.2 以下のようなモノリポ環境だったとします。 $ tree . ├── LICENSE ├── README.md ├── go │   ├── pkg │   │   └── uuid │   │   └── uuid.go │   └── services │   ├── service1 │   │   └── cmd │   │   └── main.go │   └── service2 │   └── cmd │  

概要 GCPのWorkload Identity連携はサービスアカウントで秘密鍵を作らずともGCPリソースへのアクセス権を他の環境（オンプレ、別パブリッククラウド）に付与することができます。 これにより AWSからGCPリソースにアクセスする GitHub ActionsからGCRにDocker imageをpushする CircleCIでGKEのデプロイを行う といった連携が鍵なしで実現できます。 ただ実装だけだとイメージしづらいので今回は図示してみました。 Workload Identity Federation Workload Identity連携における登場人物は以下です。 左のWorkloadsがGCPリソースにアクセスしたいアプリケーションに当たります。 準備 Workload Identity Poolの作成とサービスアカウントの作成 まずはWorkload Identit

概要 クライアントデバイスが多様化する中、UIに必要なデータもそれぞれ異なるためAPIのオーバーフェッチ（不要なデータの取りすぎ）が課題になってきます。 またマイクロサービス間の通信でも、例えばマスタ系データのうち必要なデータだけ取得して利用したいケースは多々あります。 かと言ってその度に必要最低限のデータを取得するメソッドを用意するのは開発が大変ですし、逆に細かいデータばかりのgRPCを用意すると今度はアンダーフェッチ（データが足りなくて複数回コールが必要になる）が発生します。 GraphQLでは欲しいデータをクライアント側が明示的に要求するのでオーバーフェッチが発生しないというメリットがありますが、gRPCではFieldMaskという機能があります。 今回はFieldMaskを使って余分なデータを返さない方法を説明します。 環境 Go v1.18.3 protoc-gen-go v1.

概要 Conventional Commits というコミットメッセージの規約があります。 これを守ることで 意味のあるコミット粒度＆メッセージになる あとから振り返りやすい Change Logsなどで自動化ツールを活用しやすい といったメリットを享受できます。 しかし新しいメンバーなど、Conventional Commitsを知らない人が加わるとルールを守られないコミットが含まれるため、PR時などで機械的にチェックしたいです。 今回はGitHub Actionsでそれをチェックするようにします。 環境 commitlint v16.0.0 設定 commitlint commitlint - Lint commit messages というConventional Commitsを守っているかどうかチェックするツールがあります。こちらを利用します。 インストール 以下の２つのパッケー

概要 Envoyのyamlは非常に長大で初めて読む人からするととても分かりにくいです。 しかし実際は各要素の役割を理解するととてもシンプルに構成されていることが分かります。 そのための手助けとしてこちらで図を交えながら説明します。 環境 Envoy 1.22.0 要素の説明 まずは各要素を理解します。 downstreamとupstream 要素 説明 downstream Envoyからみたクライアント upstream Envoyがサービスに対するリクエストを転送する際に接続するエンドポイント（ネットワークノード） よくあるパターンで図示してみると以下です。 front proxyモデル sidecarで外部からリクエストを受ける sidecarでローカルアプリケーションからのリクエストを転送する このようにsidecarモデルのローカルアプリケーションは、downstreamにもup

背景 FastAPIでは以下のようにデコレータ関数を使うことでHTTPサーバのpathを設定することができ、これをPath Operationと呼びます。 from fastapi import FastAPI app = FastAPI() @app.get("/") async def read_root(): return {"Hello": "World"} @app.get("/items/{item_id}") async def read_item(item_id: int, q: str = None): return {"item_id": item_id, "q": q} このPath Operationでdefを使うべきかasync defを使うべきかの方針を説明します。 環境 Python 3.9.11 FastAPI 0.74.1 方針 結論から言うと以下の方針で

概要 以下のような購入時のドメインイベントをメッセージング基盤に非同期で渡してから順番通りに実行したい、となった時に便利なのが順序保証をしてくれるPubSubのordering keyです。 購入処理 各マイクロサービスへの状態変更リクエスト 行動ログ追記 購入完了メールの送信 ただordering keyを使う上での注意点はあまり見かけなかったのでこちらにまとめようと思います。 結論から言うとordering keyの粒度はなるべく細かくしないとスケールしないという話です。 環境 cloud.google.com/go/pubsub v1.19.0 考慮すべき点 同じordering keyのメッセージは同じパーティションにpublishされる Cloud PubSubはメッセージング基盤の概念であるパーティション（Kinesisでいうシャード）をカプセル化しており、ユーザが意識しなくて

背景 CircleCIを使っているのですが 多数のリポジトリを管理している config.ymlが肥大化している。けれど殆どは似たような記述 といった背景がある上で、新しいjobやworkflowを各リポジトリに適用していく際に コピペ漏れが起きやすい レビューがつらい といった課題を持っていました。 そんな時にCircleCIがDynamic Configという新機能を出していたので、これを使って 各リポジトリで変更が不要な共通処理のファイル リポジトリ毎に修正が必要なファイル を分割して管理することで、 前者はファイル自体をコピペすれば良い レビューは後者だけ注視すれば良い という対応をします。 環境 CircleCI 2.1 circleci/continuation 0.2.0 yq 4.24.2 Dynamic Configとは Dynamic Configを使うと動的にconf

背景 依存するモジュールのメジャーバージョンがv2以上の場合に、以下のようにバージョン指定すると $ go get github.com/xxx/[email protected] 次のように怒られます。 require github.com/xxx/yyy: version "v2.0.1" invalid: should be v0 or v1, not v2 今回はこの対応方法について説明します。 環境 go 1.16.3 version "vX.X.X" invalid: should be v0 or v1, not v2 原因 go modulesは複数の依存モジュールA, Bが同じ依存モジュールCに依存している場合、AとBのgo.modでより新しいバージョンのCを使おうとします。 メジャーバージョンアップのように後方互換性を持たない場合はどうなるでしょう？ そうなると古いメジャーバージョン

概要 これまでデフォルトのTerminal.appを使っていましたが たまに重い 設定をファイルで管理したい True Color対応してない などの不満が出てきたので、上記課題を解決できるRust製のAlacrittyに移行してみました。 環境 Alacritty + tmux + vimの環境です。 macOS 11.6.2 Alacritty 0.10.1 tmux 3.2a vim 8.2.4450 インストール〜設定 インストール brew caskかdmgでインストールできます。 caskの場合 $ brew install --cask alacritty dmgの場合 Releases · alacritty/alacritty · GitHub からダウンロードしてインストール。 基本的な設定 公式のyamlを参考に~/.config/alacritty/alacritt

背景 Yubikeyを新しくしたのでGPGの運用もYubikeyに寄せようと思ったのがきっかけです。 環境 GPG 2.2.32 前提知識 主鍵と副鍵 GPGには主鍵と副鍵の関係があります。またそれぞれ秘密鍵と公開鍵のペアになっています。 これは鍵が漏洩した際にローテーションしやすくするための仕組みです。 主鍵の秘密鍵は副鍵を生成したら基本的にPCなどのデバイスからは削除し、必要な時以外は紙やUSBなどでインターネットから隔離して管理しておくのが安全です。 鍵の種類 鍵には以下の４つの役割があります。 Certify（証明） Sign（署名） Authenticate（認証） Encrypt（暗号化） 主鍵は自動的にCertifyが付きますが、それ以外は組み合わせは自由です。 Certify以外を全て副鍵で管理したケース よく見る設計はこのパターンです。 今回はこちらのパターンで作成します

背景 Bazelは優れたビルドツールである一方で、導入したチームには１人はBazel職人が必要と言われるほどキャッチアップコストが高くハマったときに開発が止まると言われます。 そのためKubernetesからも削除されるほどです。 しかしながら導入の善し悪しを判断する上で最低限の知識は必要なので、一通りのことはできるようにとキャッチアップしてみます。 ちなみに発音は公式サイトでは「ベイゼル」とのこと。 How do you pronounce “Bazel”? The same way as “basil” (the herb) in US English: “BAY-zel”. It rhymes with “hazel”. IPA: /ˈbeɪzˌəl/ ref: FAQ  |  Bazel Bazelの特徴 Bazelの特徴として以下があります。 ビルドの再現性が保たれる サンドボッ

概要 ローカルからGCPにアクセスする際に使う gcloud auth login gcloud auth application-default login について区別できるようまとめます。 環境 gcloud v340.0.0 gcloud auth login 用途 こちらはローカルで以下のようなGCP系CLIを実行する際の認証を得るために使います。 gcloud (GCPのAPI全般) bq (BigQuery) gsutil (Cloud Storage) cbt (Bigtable) etc... 認証情報の場所 ~/.config/gcloud/credentials.dbにあります。 これはsqlight3のデータベースなので、データを見たい場合は以下のようにコマンドを実行します。 $ sqlite3 credentials.db sqlite> SELECT * fro

概要 zapを使っていて 書き込み先をio.Writerで自由に設定したい テストで時刻を固定値にしたい ログレベルによって標準出力、標準エラー出力を分けたい GCP Cloud Loggingのフォーマットでログ出力したい 全ログに付けたいフィールドがある 独自logパッケージでラップしたらcallerがおかしい とちょっとカスタマイズしたいケースのTipsです。 環境 Go 1.17 go.uber.org/zap v1.19.1 Tips 書き込み先をio.Writerで自由に設定したい zapのデフォルトの出力先は標準エラー出力ですが、期待通りのフォーマットでログが出力されているか確認したい時にio.Writerを渡してそこに書き込んでほしい場合です。 そんなときはzapcore.AddSyncを使います。 func NewWithWriter(w io.Writer) *zap.

概要 GCPのCloud PubSubはメッセージング基盤として非常に有用です。 ただし利用する上で考慮すべきことも多々あるのでまとめておきます。 パラメータに関しては主にGoのクライアントライブラリをベースに説明します。 環境 Go 1.15.2 google-cloud-go v0.72.0 SLO/SLA Cloud PubSubのSLOは99.95%です。 自身が提供するサービスのSLOを満たすかはこれを元に利用しましょう。 それを満たせなかったときのSLAとしては以下のように決められています。 各月の稼働率 対象サービスが SLO を満たさなかった場合、お客様の翌月以降の請求書に対して返金される月次請求額の割合 99%～99.95% 未満 10% 95%～99% 未満 25% 95% 未満 50% ref: Pub/Sub Service Level Agreement (SLA