gRPCのkeepaliveで気をつけること その２ - Carpe Diem
背景 以前gRPCのkeepaliveについて説明しました。 christina04.hatenablog.com keepaliveの目的は idleコネクションを維持するため 死んだコネクション（TCPハーフオープン）があったら切断し、再接続するため と書きましたが、どちらの検証もアクティブなRPCがなくなってからのkeepaliveの例であり、リクエストが続く中での挙動は検証できてなかったので今回はそれを行います。 環境 grpc-go v1.38.1 Ubuntu 18.04 (Linux Kernel 4.15.0-147-generic) PINGフレームはいつ送信される？ Client-side keepaliveのパラメータであるTimeで送信間隔は設定できますが、いつ条件を満たして発火する(タイマーが開始する)かについては説明していませんでした。 Proposalでは i
gRPCのkeepaliveで気をつけること - Carpe Diem
概要 gRPCでは１つのHTTP/2コネクション上でstreamを多重化します。 しかしidleなコネクションは、LBなど間に介在するネットワーク機器によって気づいたら切断されているケースがあります。 そうならないよう、定期的にパケット（PINGフレーム）を流して「idleではないよ」とコネクションを維持しようとするのがいわゆるkeepaliveという仕組みです。 gRPCではデフォルトの設定では無効になっている＆地味に設定が細かいので１つ１つ説明します。 gRPCのkeepaliveの役割 大きく２つあります。 １つ目は先に述べたようにidleコネクションを維持するためです。 ２つ目は死んだコネクション（TCPハーフオープン）があったら切断し、再接続するためです。 例えばNLBでは350秒以上idleなコネクションが切断される仕組みがあり、これによって普段あんまりトラフィックの無いサービ
gRPCでのLoad Balancing - Carpe Diem
背景 gRPCでは主に Proxy Model Balancing-aware Client External Load Balancing Service といったLBアプローチがあります。 それぞれの特徴や実装方法を調べてみました。 Load Balancingアプローチ こちらで定義されてます。 grpc/load-balancing.md at master · grpc/grpc · GitHub 主な負荷分散のアプローチとしては以下です。 Proxy Model LBと言われて最初に浮かぶイメージですね。 ref: https://grpc.io/blog/loadbalancing/ メリット クライアントと独立しているため、クライアントは自身のアプリケーション実装にのみ集中できます。シンプルでPolyglot向きでもあります。 またProxy側に様々な拡張ができます（メトリ
様々なrate limitアルゴリズム - Carpe Diem
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
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
goroutineはなぜ軽量なのか - Carpe Diem
概要 以前の記事で christina04.hatenablog.com Goはスレッドよりはるかに軽量なgoroutineでC10K問題を解決する、という話をしましたが、goroutineが軽量なのはなぜか？という理由を深掘りしたことがなかったのでしてみました。 環境 golang 1.11.1 Darwin 17.7.0 軽量と呼ばれる理由は２つ 大きく分けると以下の２つのポイントがあります スレッドに比べてメモリ使用量が低い スイッチングコストが低い それぞれ説明していきます。 goroutineがスレッドに比べてメモリ使用量が低いのはなぜか スタックとヒープのメモリの使い方を理解すると分かります。 ヒープはメモリの下層、プログラムコードのすぐ上にあり、上に向かって成長します。一方スタックは仮想アドレス空間の一番上にあり、徐々に下に成長していきます。 ref: イベントループなしでの
Golang 1.11 で導入された ListenConfig を使って SO_REUSEPORT を利用する - Carpe Diem
概要 先日リリースされた1.11でソケットオプションを設定できるようになりました。 これによってLinux 3.9から導入されたSO_REUSEPORTという、同じポートでbindすることが可能になる機能が利用可能になります。 環境 golang 1.11 macOS 10.13.6 (Darwin Kernel Version 17.7.0) Ubuntu 16.04 (4.4.0-87-generic) 何が嬉しい？ 一言で言うとGraceful Restartが可能になるという点です。 通常サーバプロセスを再起動するとその瞬間はリクエストを捌けなくなります。 Rolling updateのような事ができる環境であればいいですが、そうではない場合 a) Listenしているsocketのfile descriptorの複製 b) SO_REUSEPORTを使う といった手段でデプロイ時
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と違って、データはリーフノードに持つの
Node.jsでOpenID Connect認証 - Carpe Diem
概要 前回はOpenIDで認証を行いました。 ですが実はGoogleのOpenIDでの認証は2015/04までに廃止の予定らしいのでOpenIDConnectへの移行を勧めてるらしいです。 なので今回はOpenIDConnectでの認証を実装します。 環境 Node.js 0.10.22 Express 4.0 passport 0.2.1 GoogleDevelopersConsoleでアプリ作成 OpenIDConnect = OAuth for login なので、ディベロッパーコンソールでアプリを作成します。 https://console.developers.google.com/project/ プロジェクト作成 クライアントIDの作成 左メニューのAPIと認証の認証情報をクリックしてください。 クライアントIDの作成をクリック ウェブアプリケーションを選択して次へ進みます。
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
UnionFS で Docker のレイヤ構造を理解する - Carpe Diem
概要 DockerではAUFSという技術が使われています。 こちらはUnionFS(ディレクトリを重ね合わせることができる)の一つで、親のファイルシステムをすべてReadOnlyにして、その上に書き込み可能なレイヤを重ねて1つのファイルシステムのように扱います。 Dockerfileで作成する際も、各行がレイヤとして１つ前のコンテナとの差分を保持して作成されます。なので途中で失敗しても、実行中のレイヤのみ破棄するので再実行が非常に高速です。 今回はそのUnionFSについてまとめてみました。 環境 Ubuntu 14.04 unionfs-fuse 0.24 UnionFSとは 複数のファイルシステムを一つの場所にマウントすることができます。例としては以下のように複数のフォルダがある状態で ├── folder001 │ └── foo └── folder002 ├── bar └─
NginxのアクセスログをKibanaで可視化 - Carpe Diem
概要 Nginxのアクセスログを用いて可視化の流れをまとめます。 mappingは手動で設定します。 環境 Ubuntu 14.04 fluentd 0.12.19 fluent-plugin-elasticsearch 1.3.0 Nginx 1.4.6 Elasticsearch 2.1.1 Kibana 4.3.1 構成 IP 名前 役割 192.168.33.100 web Webサーバ。ログは転送 192.168.33.101 kibana Kibana。転送されたログをKibanaへ この構成のためにVagrantfileを以下のように編集します。 config.vm.define :web do |web| web.vm.network :private_network, ip: "192.168.33.100" web.vm.provider "virtualbox" do
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
