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

概要 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では簡単にコマンドラインツールが作れますが、人によって引数やオプションといったインタフェースがバラバラになりがちです。 POSIX Utility Syntax Guidelinesというガイドラインがあるので、これに則るとUnixライクな統一されたインタフェースのCLIツールになります。 環境 golang/go v1.15.1 インタフェースのイメージ 例えば文字列の入ったファイルがあり $ cat sample.txt hogefuga 入力文字列をすべて大文字にするコマンドcapitalizeを作る場合、以下の３つのインタフェースをサポートするイメージです。 $ cat sample.txt | capitalize HOGEFUGA $ cat sample.txt | capitalize - HOGEFUGA $ capitalize sample.txt HOGE

概要 write: broken pipeといったクライアント側の強制的なコネクション切断でのエラーハンドリングをする際の知見まとめ。 環境 golang/go 1.13.3 事前知識 知っておくと良い知識を先に説明します。 そもそもpipeとは pipeはプロセス間通信をするための単方向のデータチャネルです。IOストリームを扱います。 読み出し側と書き込み側それぞれのfdを経由してプロセス間の通信を可能にします。 例えば親子プロセスで通信を行いたい場合、親プロセスでpipeを開きそれをforkして子プロセスを用意します。 ref: https://inzkyk.github.io/ocamlunix-jp/pipes.html そして親プロセスの書き込みfd・子プロセスの読み出しfdをそれぞれクローズすれば、以下のように子プロセス→親プロセスへ通信することができます。 pipeはシンプル

概要 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

概要 developers.cyberagent.co.jp こちらで 課金システムをマイクロサービス化した サービス自体の設計をDDDにした という対応をしました。 当時は試行錯誤の連続でしたが対応から１年程経ち、ある程度設計もfixされてきたので知見をまとめます。 知見 前提 Clean Architectureの図は多くの人が目にしているように以下の通りです。 今回話す内容は青色の部分を除いた ドメイン層：黄色の部分 ユースケース層：赤色の部分 インタフェース層：緑色の部分 です。 ディレクトリ構成 goのリポジトリの構成は以下のようにしています。 . ├── Dockerfile ├── Makefile ├── README.md ├── cmd/ ├── codes/ ├── config/ ├── docker-compose.yml ├── domain/ ├── go.m

概要 Webフロントのパフォーマンス診断 - Carpe Diem で指摘されたブラウザキャッシュの対応をするため調べてみました。 大きく分けて強いキャッシュと弱いキャッシュの２種類のキャッシュがあります。 強いキャッシュ ブラウザ側でリソースを保持し、期限が切れるまでサーバにHTTPリクエストを発行しません。 なので一度ブラウザにキャッシュされるとサーバ側からハンドリングすることができなくなります。 これを設定する方法は Cache-Controlヘッダー Expiresヘッダー の２つがあります。 Cache-Control: max-age サーバからのレスポンスで以下のようにCache-Controlヘッダーを付けます。 Cache-Control: max-age=3600 このヘッダーが付いたリソースはブラウザ上では強いキャッシュとして残ります。 max-ageは秒数なので、こ

概要 AngularなどのSPAをS3+CloudFrontで表示する方法についてです。 要件 SSL/TLSを使いたい https://example.com/hoge のようなサブディレクトリのようなパスで403にならないようにしたい ↑のようなパスでもOGPがきちんと表示される リロードしても404にならない S3バケットのファイルには直接アクセスできないようにしたい 以前のケースとの比較 過去に S3 + CloudFrontにした時にハマったこと - Carpe Diem Angularで作ったサイトでリロードすると404エラー - Carpe Diem で似たようなケースに対応しました。しかしこれらは先の要件である 3. ↑のようなパスでもOGPがきちんと表示される や 5. S3バケットのファイルには直接アクセスできないようにしたい を満たせていませんでした。今回はそちらを考

概要 インデックスに対して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と違って、データはリーフノードに持つの

概要 結論から言うと、Streamで扱っているものはStreamのまま扱うです。 具体的にはio.Readerを毎回ioutil.ReadAllで[]byteに変換せずにそのまま使いましょうです。 なぜStreamを使うべきか Node.jsの例ですが、こちらで非常に分かりやすく説明されています。 yosuke-furukawa.hatenablog.com それを踏まえて考えてみると、Goの場合以下の２つが大きいと思います。 1. メモリの効率化 ioutil.ReadAllなどで一旦全て[]byteに変換すると、その分メモリを消費しますし、アロケーションやGCに依る速度低下が起きます。 一方io.Readerやio.Writerは各chunkの処理に同じバイトを使いまわすので、メモリの効率が良いです。 2. 標準パッケージの多くがio.Readerをサポートしてる io.Reader、

概要 MongoDBでCPU使用率やロードアベレージが高くないのに処理が詰まっている現象が起きました。 その時間にbatchが動いていてアクセスが急に増えることが原因と言うのは分かっているのですが、負荷的には十分余裕があり不思議な状態でした。 そこでdstatで見るポイント - Carpe Diemでも述べたように、負荷の状態から判断する基準があります。 ロードアベレージを確認する １が高ければCPU、ディスクI/O、メモリにボトルネックがある １が低ければTCPコネクションにボトルネックがある 今回の現象から判断するに、TCPコネクションに原因がありそうです。 原因調査 Too many open filesは出ているか ファイルディスクリプタが足りない場合はコネクション数が足りずに処理が詰まってしまいます。 そしてその場合Too many open filesというエラーが出ます。 し

概要 Dockerのネットワーク周りを勉強していると、 docker0 仮想ブリッジ VXLAN link機能 など色んな要素が出てくるのですが、ちゃんと理解していないとすぐ忘れるため一度しっかり学んでみました。 今回はその時に疑問に思ったことをまとめてみました。 環境 docker 1.11.2 構成 マシン IP 役割 ホスト 192.168.33.10 Dockerホスト docker0 172.17.0.1 仮想ブリッジ nginx1 172.17.0.2 コンテナ１ nginx2 172.17.0.3 コンテナ２ 事前知識 以下の知識があると学ぶ上で非常に助かります。 ブリッジ 第２層でMACアドレスで判別して転送 3 Minutes Networking No.17 ルータ 第３層でIPで判別して転送 3 Minutes Networking No.28 NAT、NAPT、IP

概要 JWTを認証用トークンに使う時に調べたことをまとめます。 JWTとは JWTはJWSやJWEの構造の中にエンコードして埋め込まれるJSON形式のclaimのセットです。 一般的にはJWS形式のJWTが使われるのでそれを前提に進めます。 JWS形式のJWTは以下のフォーマットです。 {base64エンコードしたheader}.{base64エンコードしたclaims}.{署名} 以下の特徴があります。 発行者が鍵を使ってJSONを署名（or HMAC）し、トークンとして扱う。 暗号化ではないので、JSON の中身は誰でも見られる。 発行者は鍵を使ってメッセージの検証ができるので、改竄を検知できる。 以上の点からトークンとして向いているため、認証トークンとして用いられるようになってきました。 Cookieとの認証フロー比較 ref: Cookies vs Tokens. Getting

概要 GitHubを使った開発で使ってるツールを紹介していきます。 どれもあると無いとでは開発スピードが大きく変わります。 Fork GUIのGitクライアントです。 git-fork.com 以前はSourcetreeを使っていましたが管理するファイルが増えると非常に重くなったのでリプレースしました。 メリット とにかく軽い タブ型なので複数リポジトリ見ても散乱しない 対話型のリベース・コンフリクト修正機能がある リポジトリの追加しやすい 無料 複数ブランチ扱ってる時に、取り込んでないコミットが非アクティブだから見やすい デメリット まだ開発途上でバグがいくつかある（コンフリクト解決したら別の変更ファイルが消えたり、など） ghq + fzf リポジトリ管理ツールのghqと github.com インクリメンタルサーチを可能にするfzfです。 github.com 以前はpecoを使って

概要 Goの良いところってなんだろう？と思ってまとめます。 多分新しいことを知ったら追記していきます。 よく言われるところ コンパイルが速い JavaやC++に比べてかなり高速です。 メモリ安全 GoはC言語に近いですが、C言語で問題になっていたメモリ周りは言語側でちゃんとカバーして使う側が意識する必要がなくなってます。 型安全性 LL言語に比べれば。 標準ライブラリの充実 外部ライブラリを使わずとも標準ライブラリでほぼ何でもできます。 学習コストが低く、可読性が高い 言語の仕様がシンプルなので、他の言語に比べてすぐに一通り理解できます。 gofmt 先程の可読性に関連しますが、フォーマッターがデフォルトで付いているので読みやすくなります。 タブかスペースかといった宗教論争をせずに済みます。 標準ツールの充実 pprofでプロファイリング race detectorでgoroutineによ

概要 インスタンスのヘルスチェックに失敗したり、リクエストが届かなかったりするケースの調査のためにネットワークの疎通を確認する機会は多々あります。 今回はその中でよく使うコマンドをまとめてみました。 環境 Ubutnu 16.04 コマンド ping pingはICMPのエコー要求/応答機能を使った診断コマンドです。 疎通確認 $ ping google.com PING google.com (216.58.200.206): 56 data bytes 64 bytes from 216.58.200.206: icmp_seq=0 ttl=54 time=2.329 ms 64 bytes from 216.58.200.206: icmp_seq=1 ttl=54 time=2.744 ms ちなみにICMPはL3のプロトコルなのでポートは関係ありません。 確認できないケース pi

概要 以前の記事で christina04.hatenablog.com Goはスレッドよりはるかに軽量なgoroutineでC10K問題を解決する、という話をしましたが、goroutineが軽量なのはなぜか？という理由を深掘りしたことがなかったのでしてみました。 環境 golang 1.11.1 Darwin 17.7.0 軽量と呼ばれる理由は２つ 大きく分けると以下の２つのポイントがあります スレッドに比べてメモリ使用量が低い スイッチングコストが低い それぞれ説明していきます。 goroutineがスレッドに比べてメモリ使用量が低いのはなぜか スタックとヒープのメモリの使い方を理解すると分かります。 ヒープはメモリの下層、プログラムコードのすぐ上にあり、上に向かって成長します。一方スタックは仮想アドレス空間の一番上にあり、徐々に下に成長していきます。 ref: イベントループなしでの

概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token