IstioやEnvoyで発生するネットワーク系エラー - Carpe Diem
背景 マイクロサービス環境で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-
go-redisのtimeoutで気をつけること - Carpe Diem
概要 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
Workload Identity Federationを図で理解する - Carpe Diem
概要 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
Node.jsでGraceful Shutdown - Carpe Diem
概要 christina04.hatenablog.com のNode.js版です。 環境 Node.js v18.18.0 TypeScript v5.2.2 Express v4.18.2 課題 次のようなアプリケーションコードがあった際に import type { Express, Request, Response } from "express"; import express from "express"; const app: Express = express(); const port = process.env.port || 8000; app.get("/", (req: Request, res: Response) => { setTimeout(() => { res.end("Hello world"); }, 10000); }); const serv
Bazelを使ってみる その４（gRPCのビルド） - Carpe Diem
概要 Bazel解説第４弾です。 Bazelを使ってみる その１（Goのビルド） - Carpe Diem Bazelを使ってみる その２（protobufのビルド） - Carpe Diem Bazelを使ってみる その３（docker imageのビルド） - Carpe Diem 今回はgRPCをビルドしてみます。 gRPCは２通りの設定方法があります。 gazelleのやり方 grpcのruleをメンテしてるコミュニティのやり方 今回は簡単なgazelleのやり方で説明します。 環境 Bazel v4.2.2 準備 gRPCコード準備 まずgRPCのリポジトリを用意します。 ディレクトリ構造 以下のディレクトリ構造で、 ├── client │ └── main.go ├── go.mod ├── go.sum ├── proto │ └── helloworld.prot
structのメモリ割り当て - Carpe Diem
概要 Goにおけるstructのメモリ構造を知ることでフィールド順序に対する意識が変わったり、なぜunsafe.Sizeof(string)が16bytesでunsafe.Sizeof(slice)が24bytesになるかが理解できます。 環境 Go 1.15.6 darwin 20.1.0 x86_64 各型のメモリ割り当て unsafe.Sizeof()を使うとその変数がどれくらいメモリを割り振るかが分かります。 ※変数の分確保するメモリであり、参照先のメモリは含みません 型 unsafe.Sizeof() bool 1 int32 4 int 8 float64 8 string 16 []T 24 The Go Playground structのフィールドにそれぞれの型を付けると、その分メモリが割り振られます structのメモリ割り当て 例えばbool, float64, in
go modulesでコマンドラインツールのバージョン管理をする - Carpe Diem
概要 goはModulesでリポジトリのライブラリのバージョン管理を行えます。 ただコマンドラインツールに関してはgo getしてgo.modに追加されても、goファイルで扱っているわけではないのでgo mod tidyすると消えてしまいます。 しかしながら「この機能は最新のmasterにしかない。かと言ってgo get -uや@masterで常に最新にしてしまうと互換性が壊れるかもしれない。だからバージョン管理できないと困る」というシチュエーションはよくあります。 その対策としては現状tools.goにblank importするのがベストプラクティスとなっています。 環境 go 1.13.6 現状の問題 入ったはずのパッケージがgo mod tidyで消える $ mkdir hello $ cd hello $ go mod init example.com/hello としてから、s
gRPCのkeepaliveで気をつけること - Carpe Diem
概要 gRPCでは１つのHTTP/2コネクション上でstreamを多重化します。 しかしidleなコネクションは、LBなど間に介在するネットワーク機器によって気づいたら切断されているケースがあります。 そうならないよう、定期的にパケット（PINGフレーム）を流して「idleではないよ」とコネクションを維持しようとするのがいわゆるkeepaliveという仕組みです。 gRPCではデフォルトの設定では無効になっている＆地味に設定が細かいので１つ１つ説明します。 gRPCのkeepaliveの役割 大きく２つあります。 １つ目は先に述べたようにidleコネクションを維持するためです。 ２つ目は死んだコネクション（TCPハーフオープン）があったら切断し、再接続するためです。 例えばNLBでは350秒以上idleなコネクションが切断される仕組みがあり、これによって普段あんまりトラフィックの無いサービ
様々なrate limitアルゴリズム - Carpe Diem
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
CPU CFS Quotaを制限している場合の適切なGOMAXPROCS - Carpe Diem
概要 christina04.hatenablog.com 以前上の記事でGOMAXPROCSはCPU数程度が適切に動くという話をしました。 これはこれで正しいのですが、一方でdockerのようにcgroupsでCPU Quotaを制限するケースではこれに当てはまらなくなります。 Kubernetesでいうと Kubernetesのresource requests, limits - Carpe Diem のようにlimitsを設定した場合ですね。 今回はその検証と対応方法についてまとめます。 環境 go 1.14.2 docker 19.03.8 CPU Quotaを制限してベンチマーク 以下の素数を算出するというCPUバウンドなプログラムを使います。 gotutorials/concprime at master · embano1/gotutorials · GitHub PCのC
Goのnet/httpのkeep-aliveで気をつけること - Carpe Diem
概要 Idle connectionをプールするkeep-aliveの仕組みですが、Goで適切に使用するためにはいくつか注意があります。 環境 golang/go 1.13.1 TCP Keep-Aliveの挙動をパケットキャプチャで確認する 例えば以下のようにDefaultTransportの一部の設定（①、②）をイジってリクエストを送ると client = &http.Client{ Transport: &http.Transport{ DialContext: (&net.Dialer{ Timeout: 30 * time.Second, KeepAlive: 10 * time.Second, // ① DualStack: true, }).DialContext, ForceAttemptHTTP2: true, MaxIdleConns: 100, IdleConnTim
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
