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
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
gRPCでFieldMaskを使う（更新編） - Carpe Diem
概要 christina04.hatenablog.com 前回はFieldMaskを使ってオーバーフェッチを避ける方法を説明しました。 今回はMutation（更新）におけるFieldMaskの活用方法を説明します。 環境 Go v1.18.3 protoc-gen-go v1.25.0 protoc v3.19.4 grpc-go v1.47.0 MongoDB 5.0.9 課題 前回サーバ側では以下の構造のデータを保持していました type User struct { ID string `bson:"_id"` Name string `bson:"name"` Email string `bson:"email"` Age int `bson:"age"` Address Address `bson:"address"` } type Address struct { Count
セキュアなトークン管理方法 - Carpe Diem
概要 クライアント↔サーバ間の認証・認可情報としてのトークン管理はWebサービスとしては必ずつきまとうものですが、一方できちんと実装しないとセキュアに管理はできません。 今回はそのトークン管理方法の一例を紹介します。 要件 今回の主な要件は以下です。 AuthサーバとResourceサーバは別で管理する（負荷特性が異なるので） 認証するとAuthサーバはrefresh tokenとaccess tokenを返す access tokenはJWT形式 access tokenはクライアントのオンメモリで管理する access tokenの期限は短く（１時間以内） refresh tokenを使ってaccess tokenを発行できる refresh tokenはrevoke可能である 認証情報に変更があれば（パスワード変更など）refresh tokenをrevokeできる Resource
Clean Architecture で実装するときに知っておきたかったこと - Carpe Diem
概要 developers.cyberagent.co.jp こちらで 課金システムをマイクロサービス化した サービス自体の設計をDDDにした という対応をしました。 当時は試行錯誤の連続でしたが対応から１年程経ち、ある程度設計もfixされてきたので知見をまとめます。 知見 前提 Clean Architectureの図は多くの人が目にしているように以下の通りです。 今回話す内容は青色の部分を除いた ドメイン層：黄色の部分 ユースケース層：赤色の部分 インタフェース層：緑色の部分 です。 ディレクトリ構成 goのリポジトリの構成は以下のようにしています。 . ├── Dockerfile ├── Makefile ├── README.md ├── cmd/ ├── codes/ ├── config/ ├── docker-compose.yml ├── domain/ ├── go.m
.proto ファイルの整形に clang-format を使う - Carpe Diem
概要 gRPCで通信しようとすると.protoファイルが沢山出てきます。 ただ人によってインデントが異なったりするのは良くないので、何かしらformatterが無いかなと探したら github.com こちらのissueで「Googleではclang-formatを使ってるよ」という回答があったのでそれを使ってみます。 環境 macOS Mojave 10.14.2 clang-format 8.0.0 設定 インストール brew でインストールできます。 $ brew install clang-format 使い方 $ xargs clang-format -i foo.proto で整形できます。ディレクトリ丸ごと実行したい場合は./proto/ディレクトリで定義しているとすると $ find ./proto/ -name "*.proto" | xargs clang-forma
goroutineはなぜ軽量なのか - Carpe Diem
概要 以前の記事で christina04.hatenablog.com Goはスレッドよりはるかに軽量なgoroutineでC10K問題を解決する、という話をしましたが、goroutineが軽量なのはなぜか？という理由を深掘りしたことがなかったのでしてみました。 環境 golang 1.11.1 Darwin 17.7.0 軽量と呼ばれる理由は２つ 大きく分けると以下の２つのポイントがあります スレッドに比べてメモリ使用量が低い スイッチングコストが低い それぞれ説明していきます。 goroutineがスレッドに比べてメモリ使用量が低いのはなぜか スタックとヒープのメモリの使い方を理解すると分かります。 ヒープはメモリの下層、プログラムコードのすぐ上にあり、上に向かって成長します。一方スタックは仮想アドレス空間の一番上にあり、徐々に下に成長していきます。 ref: イベントループなしでの
B TreeとB+ Treeの違い - Carpe Diem
概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう？と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは１ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
GoでJWTの具体的な実装 - Carpe Diem
概要 以前JWTを認証用トークンに使う時に調べたこと - Carpe Diemで紹介した内容の具体的な実装の紹介です。 環境 golang 1.8.1 署名アルゴリズムと鍵長は以下とします。 署名アルゴリズム 鍵長 RSA-SHA256 4096bit 成果物 今回の完成形はこちら github.com 公開鍵認証のためのキーペア作成 秘密鍵の生成 $ openssl genrsa 4096 > secret.key 秘密鍵から公開鍵の生成 $ openssl rsa -pubout < secret.key > public.key 今回は簡単のためソースコードに貼り付けます。 var ( rawPublicKey = []byte(`-----BEGIN PUBLIC KEY----- MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAw8eiDb
JWTを使ってGoogleAPIのアクセストークン取得する - Carpe Diem
概要 GoogleAPIを使う際、多くの場合は「ユーザごとに認証させてアクセストークンを発行し、リクエストに利用する」という流れですが、APIによってはわざわざユーザ個別にアクセストークンを発行させる必要がないケースもあります。 そんなケースでは「Service Accounts」という方式を使い、サービス側でアクセストークンを発行してAPIを利用します。以下の様な流れです。 今回は例としてGoogleDriveにアクセスしてみます。 手順 Developer Consoleでアプリ作成し、「Service Accounts」を選択して、秘密鍵を取得 秘密鍵で署名したJWTを作る Googleのトークンエンドポイントを叩いてアクセストークンを取得 取得したアクセストークンでAPIを叩く 環境 Node.js v0.12.0 Developer Consoleでアプリを作る プロジェクトの作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
