背景 gRPCにはクライアントとサーバとの通信を抽象化したChannelという仕組みがあります。 GRPC_GO_LOG_SEVERITY_LEVEL=infoを有効にした際に出てくる [core] Channel Created [core] parsed scheme: "" [core] scheme "" not registered, fallback to default scheme [core] ccResolverWrapper: sending update to cc: {[{localhost:8080 <nil> 0 <nil>}] <nil> <nil>} [core] Resolver state updated: {Addresses:[{Addr:localhost:8080 ServerName: Attributes:<nil> Type:0 Meta

概要 gRPCでは１つのHTTP/2コネクション上でstreamを多重化します。 しかしidleなコネクションは、LBなど間に介在するネットワーク機器によって気づいたら切断されているケースがあります。 そうならないよう、定期的にパケット（PINGフレーム）を流して「idleではないよ」とコネクションを維持しようとするのがいわゆるkeepaliveという仕組みです。 gRPCではデフォルトの設定では無効になっている＆地味に設定が細かいので１つ１つ説明します。 gRPCのkeepaliveの役割 大きく２つあります。 １つ目は先に述べたようにidleコネクションを維持するためです。 ２つ目は死んだコネクション（TCPハーフオープン）があったら切断し、再接続するためです。 例えばNLBでは350秒以上idleなコネクションが切断される仕組みがあり、これによって普段あんまりトラフィックの無いサービ

概要 以前 christina04.hatenablog.com でMacrotasksとMicrotasksについて触れました。 ただこの時使ったのがPromise、setTmeout()だけで、他の種類の非同期関数を使った場合どうなるのだろう、と気になり検証してみました。 環境 Node.js v8.9.0 各キューの種類と優先度 図 以下の図が非常に分かりやすいです。 ref: Promises, Next-Ticks and Immediates— NodeJS Event Loop Part 3 Event Loop（Macrotasks）のキュー 大きく以下の３つを覚えてください 種類 実行順 Timer(setTimeout, setInterval) 1 I/O event 2 setImmediate 3 Microtasksのキュー 大きく以下の２つを覚えてください 種

概要 Angularで出てきたfakeAsyncやwhenStableを使う時に、microtasksの話が出たのでちゃんと理解しようと調べてみました。 実験 以下のjsのログ順はどうなるでしょうか？ console.log('script start'); setTimeout(function() { console.log('setTimeout'); }, 0); Promise.resolve().then(function() { console.log('promise1'); }).then(function() { console.log('promise2'); }); console.log('script end'); MicroTask1 結果 このようになります。 script start script end promise1 promise2 setTime

概要 gRPCを用いた負荷分散ではEnvoyを使ったL7のバランシングが最近の主流になっています。 ただEnvoyが各Podに振り分けるためにPodのIPを知る必要があります。 ECSはService Discoveryを持っていないので自前でたてるか、control planeを用意してそれをService Discoveryにする必要がありますが、Kubernetesはheadless serviceがあります。 headless serviceはServiceに対してDNSリクエストをすると、動いているPodのIPアドレス一覧を返してくれるのでこれをService Discoveryとして使うことが可能です。 今回はheadless serviceとして動かすところだけ検証しました。 環境 minikube v0.26.1 kubernetes 1.8.6 設定 Deployment